In <39323E5D.A32C1B2A@cyberport.com> Warren Young (tangent@cyberport.com) wrote:
>> "pretty admin tools" is entirely a religious issue.
> Um, okay. :) If you doubt that it matters, well, it's a good thing
> you're not calling the shots.
> What do you think would happen if Red Hat stopped including Emacs with
> the distro? Let's say the top brass goes and decides vi is better. All
> else being equal, their market share would probably drop to a _tenth_
> what it is now, even though Emacs "only" accounts for roughly half the
> market vis a vis vi. Why? Linux installed on a multiuser machine has
> to make all those users happy. If half the users on the machine want
> Emacs, they're gonna give this hypothetical Red Hat distro a miss.
> The same applies to pretty admin tools.
Huh ? How ??? You allow EVERY user to use "pretty admin tools" ? Are you even
sane ? "Linux installed on a multiuser machine has to make all those
users happy". Even if it's true (and it's not - see cite below) it does not
issue for admin tools - they are for admins, not "all users" anyway.
-- cite --
"If users are made to understand that the system administrator's job is to
make computers run, and not to make them happy, they can, in fact, be made
happy most of the time. If users are allowed to believe that the system
administrator's job is to make them happy, they can, in fact, never be made
happy."
- -Paul Evans (as quoted by Barb Dijker in "Managing Support Staff", LISA '97)
-- cut --
>> forget about UDI. it's toast.
> I don't agree. UDI might suck like a tornado, but once the drivers
> start coming out, there _will_ be pressure to move UDI support into the
> main kernel. No doubt the distro makers will do it as an add-on like
> pcmcia-cs is in 2.2, but Monterey could make UDI a reality. Given that,
> it's important that Linux be able to use those drivers.
We'll wait and see. So far there are MUCH more native linux drivers then
there are UDI drivers. If UDI drivers will be common linux will support them
via third-party addons (and instead of currently usual lklm's "please
reproduce it without VMWare modules, then come back" you'll see "please
reproduce it without VMWare modules and UDI drivers, then come back" :-)
BTW initially all was planned the other way around: UDI drivers will be
created by linux community to be used by SCO :-)
>> so, why does lack of "extremely tight platform integration" cost Linux?
>> I can think of no case where there's any performance or maintenance hit
>> for ia32.
> Hot swap PCI, multipath I/O, HBA/NIC failover, ccNUMA on IBM/Sequent and
> Unisys boxes.... Enough?
No. Most of it (if not all) is in development/developed. They are not included
in 2.4 though. It's not lack of "extremely tight platform integration". It's
just "platform immaturity" - quite a different thing.
> As for binary interfaces stifling improvements, sorry, it isn't true.
> All of SCO's kernel ABIs are versioned, which lets them change the
> interfaces at will: old drivers can ask for and get the old interfaces
> while newer drivers use the new interfaces. What this _does_ cause, and
> I do mention it, is bloat and complexity: there are now eight different
> versions of SCO's device driver interface, for example. I don't know if
> UnixWare supports all eight still, but it does support several of them.
Simple sample: in linux drivers all unneeded on locks in driver are nullified
and on SMP they are inlined. You CAN NOT do this with binary interface. Thus
if you need good support for 8-way (16-way 32-way) system you INEVITABLE
not only getting more complex source (it's inevitable with or without binary
interface) but you are losing speed on uniprocessor or dual-processor systems.
You can not introduce deep change in VFS like dcache in 2.2 (not even 3.0 !)
and so on. Or you can with addition of VERY complex emulation layer. "Stifling
improvements" is almost the same as "bloat and complexity": if small
improvement can be done to get 1% of speedup or just to make some things
possible (like Viro's VFS changes) with binary interface you'll need A LOT OF
manpower to do emulation of old version. Thus your small change is not "minor
improvement" anymore but "major incompatibility chnage to be discussed with
top management".
> I'll consider exploring the sourcing issue in more depth, but at the
> moment I think I'm satisfied with just pointing it out.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:21 EST