SCO Linux???
Dirk Hart
Rumours abound this morning at slashdot.org that SCO will be producing
it's own Linux distribution. One maven seemed to think it was to be
Turbo Linux repackaged.
I imagine SCO is targeting this at the desktop and will be wanting to
keep OS & UW on the server.
Hmmm. Anything to displace Windoze from the desktop is OK with me.
Michael Green
handle at once? Could this be the cuckoo elbowing OS out of the
nest?
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
Mike Kenyon
> Hmm SCO Linux. How many operating systems can one organisation
> handle at once? Could this be the cuckoo elbowing OS out of the
> nest?
If SCO start supporting Linux then they'll have to support Samba as well. It
wouldn't do to support three operating systems but only VisionFS and AFPS!
--
Mike Kenyon <mi...@davidaustinroses.fsbusiness.co.uk>
Toby Darling
Yes and no. If you mean they are the same piece of software, then yes you
are wrong. If you mean they perform a similar function, then no you
are not wrong
Zbigniew Sienkiewicz
Mike Kenyon <mi...@davidaustinroses.fsbusiness.co.uk> wrote in message
news:39473D8F...@davidaustinroses.fsbusiness.co.uk...
an...@tipas.lt
Dirk Hart <dh...@ultranet.com> wrote:
>
>
> Rumours abound this morning at slashdot.org that SCO will be producing
Look at http://www.nwfusion.com/news/2000/0612sco.html
Andrey Bondar, SysAdmin,
T.I.P.A.S. Ltd, Lithuania
Sent via Deja.com http://www.deja.com/
Before you buy.
Warren Young
>
> Michael Green wrote:
> > Hmm SCO Linux. How many operating systems can one organisation
> > handle at once? Could this be the cuckoo elbowing OS out of the
> > nest?
>
> If SCO start supporting Linux then they'll have to support Samba as well. It
> wouldn't do to support three operating systems but only VisionFS and AFPS!
Watch me be surprised when they offer VisionFS on SCO Linux, just so
they can charge per-seat client license fees for it. But watch only if
you're bored and have a lot of time to kill.
I guess it's a given that they'll integrate the UDI patches that the
core Linux kernel development team refuses to use.
I can deal with all that, just don't let them feed us SAF and the pkg*
utilities. Pleeeze no!
It occurs to me that this entire post is nothing but speculation. I
guess that's what happens when I can only read about SCO's plans in
trade rags, rather than on SCO's site. Then when they do put something
about the future on the site, it reads like a mission statement instead
of a technical briefing. (Go read the Monterey pages if you disagree.)
Sigh....
--
= Warren -- See the *ix pages at http://www.cyberport.com/~tangent/ix/
=
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
Robert Lipe
>I guess it's a given that [SCO will] integrate the UDI patches that the
>core Linux kernel development team refuses to use.
Ahem, the UDI work has not yet been submitted to the core Linux kernel
development team. They haven't had the opportunity to refuse it based
on the actual code. Some such developers (one in particular) have
expressed a predisposed distaste for it becuase they don't understand
it, haven't read the spec, or just plain don't like the idea, but those
folks haven't seen the code.
Signed,
One Who Has Read the Spec and the Code.
(oh, and happens to be Development Team Lead, UDI)
Tony Lawrence
>
> In article <39464418...@ultranet.com>,
> Dirk Hart <dh...@ultranet.com> wrote:
> >
> >
> > Rumours abound this morning at slashdot.org that SCO will be producing
>
> Look at http://www.nwfusion.com/news/2000/0612sco.html
A particularly compelling paragraph from that:
>
> Observers say SCO has a big opportunity to
> make a splash in the Linux market, but needs
> to be more vocal about it. Dan Kusnetsky,
> program manager at IDC, a Framingham,
> Mass., market research firm, notes that SCO
> owns more than a quarter of the Unix market,
> but that hardly anyone knows it.
--
Tony Lawrence (to...@aplawrence.com)
SCO/Linux articles, help, book reviews, tests,
job listings and more : http://www.pcunix.com
fred smith
: Warren Young <war...@etr-usa.com> writes:
:>I guess it's a given that [SCO will] integrate the UDI patches that the
:>core Linux kernel development team refuses to use.
Pardon my ignorance, what is UDI, and what would its presence do for/to
Linux?
: Ahem, the UDI work has not yet been submitted to the core Linux kernel
: development team. They haven't had the opportunity to refuse it based
: on the actual code. Some such developers (one in particular) have
: expressed a predisposed distaste for it becuase they don't understand
: it, haven't read the spec, or just plain don't like the idea, but those
: folks haven't seen the code.
: Signed,
: One Who Has Read the Spec and the Code.
: (oh, and happens to be Development Team Lead, UDI)
--
---- Fred Smith -- fre...@fcshome.stoneham.ma.us ----------------------------
But God demonstrates his own love for us in this:
While we were still sinners,
Christ died for us.
------------------------------- Romans 5:8 (niv) ------------------------------
Robert Lipe
>Robert Lipe <rober...@usa.net> wrote:
>: Warren Young <war...@etr-usa.com> writes:
>:>I guess it's a given that [SCO will] integrate the UDI patches that the
>:>core Linux kernel development team refuses to use.
>Pardon my ignorance, what is UDI, and what would its presence do for/to
>Linux?
UDI is the Uniform Driver Interface. You can learn about it in great
detail at http://www.projectudi.org/.
Put simply, it's a standardized interface between drivers and the OS.
Write a UDI driver on any processor and it'll run on any UDI environment
that conforms to the ABI bindings for that processor. It's great fun to
build a driver on UnixWare, run it on Linux and OpenServer, then take
that same source to a completely different processor, type 'udisetup'
and watch it Just Work with zero code changes.
You can get development and runtime environments for UnixWare right now.
Other OSes are coming.
RJL
Warren Young
>
> Robert Lipe <rober...@usa.net> wrote:
> : Warren Young <war...@etr-usa.com> writes:
>
> :>I guess it's a given that [SCO will] integrate the UDI patches that the
> :>core Linux kernel development team refuses to use.
>
> Pardon my ignorance, what is UDI, and what would its presence do for/to
> Linux?
It's a standardize device driver interface. The idea is for all Unixes
to support it, allowing a device driver to be ported to new versions of
Unix with just a recompile.
(See http://www.projectudi.org/ for more details.)
The current sentiment among the Linux kernel people is that they don't
want UDI in the kernel. I've heard several reasons for this:
1. UDI -- being an extra layer of indirection -- slows the device driver
down with respect to a "native" device driver.
2. The Linux kernel people would rather see native drivers than UDI
drivers for particular hardware. If UDI remains an add-on that Linux
distributors have to add themselves, there will be more pressure on
hardware vendors to avoid UDI, at least for Linux.
3. Since UDI is a standardized interface, it should also be an ABI, at
least for a particular platform. (UDI doesn't promise a cross-platform
ABI.) An ABI means that a device driver could work with multiple
versions of the Linux kernel without needing to be recompiled.
If Linux had a driver ABI, hardware vendors would start shipping
binary-only drivers: there are few binary-only Linux drivers right now
because of the threat of interface changes. Obviously, binary-only
drivers go totally against the grain of Open Source.
4. There's concern that UDI would create a drag on kernel innovation:
that UDI would either make some kernel changes impossible because of the
way it thinks device drivers should work, or that the UDI component
might not be able to benefit from improvements made to the native driver
interface. The latter would make Linux look bad if UDI became the de
facto Linux driver interface, because the improvements would not show up
on systems using UDI drivers. The Linux kernel folk would then have to
petition the UDI standards body to make a change: Open Source and
bureaucracies do not mix.
5. Accepting UDI into the kernel would require the kernel folk to find
someone to keep the Linux UDI component in synch with the rest of the
kernel. Since UDI is already unpopular for the above reasons, there's
skepticism as to whether someone can be found that's willing to synch
UDI up every time the native driver interface changes.
6. ABIs are good in one sense, but they also stifle innovation. Just
look at UnixWare: their DDI is at version 8 right now, implying that
they've changed the interface 7 times since they created DDI. Linux
changes its device interface as often as every point release. Is Linux
out of control and chaotic, or is it continually being refined? It
depends on your point of view, but the fact is, the Linux kernel folk
refuse to give up this ability to change the device driver interface at
will.
Robert Lipe
>The current sentiment among the Linux kernel people is that they don't
>want UDI in the kernel. I've heard several reasons for this:
Some don't. Others do.
>1. UDI -- being an extra layer of indirection -- slows the device driver
>down with respect to a "native" device driver.
It isn't indirection and it isn't necessarily an extra layer. UDI
drivers can, in many cases run _faster_ than a native driver becuase of
the instance independence and implicit locking which allows the OS more
freedom to schedule the services.
>2. The Linux kernel people would rather see native drivers than UDI
>drivers for particular hardware. If UDI remains an add-on that Linux
>distributors have to add themselves, there will be more pressure on
>hardware vendors to avoid UDI, at least for Linux.
Funny how when the UNIX guys said this same thing in the '80's and '90's
they were evil for promoting proprietary systems...
>3. Since UDI is a standardized interface, it should also be an ABI, at
>least for a particular platform. (UDI doesn't promise a cross-platform
>ABI.)
For each architecture there is a set of ABI bindings for UDI. So a
driver built on UW7 (which supports the IA32 UDI bindings) drops right
into Linux or OpenServer which also support those bindings. No, your
Sparc/64 object isn't going to work on your Alpha system.
>An ABI means that a device driver could work with multiple
>versions of the Linux kernel without needing to be recompiled.
It also means it can work on the same version of the Linux kernel
without needing to be recompiled. Is your Linux kernel built with
BIGMEM? How about MP? With or without versioning? _Each_ of those
options results in different interfaces which raises testing costs.
>If Linux had a driver ABI, hardware vendors would start shipping
>binary-only drivers: there are few binary-only Linux drivers right now
>because of the threat of interface changes. Obviously, binary-only
>drivers go totally against the grain of Open Source.
It's odd how this argument was never raised against tools like RPM. RPM
made binary distributions _practical_ but it hardly mandated them. UDI
is both a source and a binary standard; the decision to open source
or not is a different decision than the one to do UDI drivers or
proprietary drivers.
>4. There's concern that UDI would create a drag on kernel innovation:
>that UDI would either make some kernel changes impossible because of the
>way it thinks device drivers should work, or that the UDI component
>might not be able to benefit from improvements made to the native driver
>interface. The latter would make Linux look bad if UDI became the de
>facto Linux driver interface, because the improvements would not show up
>on systems using UDI drivers. The Linux kernel folk would then have to
>petition the UDI standards body to make a change: Open Source and
>bureaucracies do not mix.
Actually, UDI _promotes_ kernel innovation. Right now, you just cannot
make wild and crazy changes in the underlying OS without breaking all
the drivers. Different OSes place different costs on this. Commercial
OSes place a high cost on it. Remember when Linux changed the lock
primitives and how all the drivers broke? By providing an architected
interface between the driver and the kernel each is free to change
independently of the other. Just like the C libary and underlying
system calls provide a contract to the application that a given service
is always present and always has the same characteristics regardless of
underlying implementation, UDI does the same.
>5. Accepting UDI into the kernel would require the kernel folk to find
>someone to keep the Linux UDI component in synch with the rest of the
>kernel. Since UDI is already unpopular for the above reasons, there's
>skepticism as to whether someone can be found that's willing to synch
>UDI up every time the native driver interface changes.
There is already a group that is developing the UDI port and have
expressed interest in long-term maintenance of it. I chip in code and
testing, too.
>6. ABIs are good in one sense, but they also stifle innovation. Just
>look at UnixWare: their DDI is at version 8 right now, implying that
>they've changed the interface 7 times since they created DDI.
That covers a 12 year period of source and binary compatibility (UW7
will still run DDI5 drivers which covers the 4.2MP stuff from '92 or
so). Proposed changes to that interface are scrutinized very carefully.
>Linux changes its device interface as often as every point release.
>Is Linux out of control and chaotic, or is it continually being
>refined? It depends on your point of view, but the fact is, the Linux
>kernel folk refuse to give up this ability to change the device driver
>interface at will.
Not all folks doing drivers *like* interfacess that change at whim.
Some would prefer to program to documented and stable interfaces that
are the same across OSes so they can spend their time/money refining one
driver instead of continually playing catch-up with someone gratituously
tinkering with interfaces.
Also, UDI and "native" aren't mutually exclusive. (We aren't going
to rip out support for non-UDI drivers in the SCO OSes.) If you like
writing drivers for 20 different OSes, feel free.
fred smith
: fred smith wrote:
:>
:> Robert Lipe <rober...@usa.net> wrote:
:> : Warren Young <war...@etr-usa.com> writes:
:>
:> :>I guess it's a given that [SCO will] integrate the UDI patches that the
:> :>core Linux kernel development team refuses to use.
:>
:> Pardon my ignorance, what is UDI, and what would its presence do for/to
:> Linux?
Thanks to both Warren and Robert, both of whom answered my question!
Fred
--
---- Fred Smith -- fre...@fcshome.stoneham.ma.us ----------------------------
The Lord detests the way of the wicked
but he loves those who pursue righteousness.
----------------------------- Proverbs 15:9 (niv) -----------------------------
Robert Lipe
>A real fear of the Linux community is a takeover of Linux by stealth.
>One way to achieve this is to enable binary only facilities. Then anyone
>with the money could dominate the business by suppling superior binary
>only code and lock out other developers. Eventually making industry
>dependant on the private facilities.
I really don't get this argument. It seems to go to "Let's change the
interfaces rapidly and show blatant disregard for compatibility so we'll
have more drivers."
>SCO should make a sweeping statement to the extent that any drivers they
>supply will include full source. This would disarm most of the anti UDI
>camp. How much competition is there now that SCO has to keep the Scroog
>mentality on the source code. (How much of the drivers come from SCO
>anyway? How much comes directly from the hardware manufacturers?)
SCO is but one partner in UDI. SCO has currently contributed
the majority of the sample drivers that will be in the reference
implementation and are available now in the UW UDI Developer's Kit from
our web page. They are available as source. But statistically, the
majority of the interesting drivers on the planet will not be ours so I
don't know what good such a sweeping statement would really make.
>How many hardware manufactures hate developing UNIX drivers. My guess is
>most of them. Why not use the army of willing linux slaves to maintain
>the drivers.
I don't think any serious hardware vendor depends on "willing slaves" to
support their product.
>Linux desperately needs this interface and the related facilities to run
>it. I have hacked kernels for 20 years. Looking at linux is like being
>transported back to the begining of time.
In more ways than one. Yeah, there's the obvious absence of things
liek strongly versioned interface, but more interesting (to me) is the
mentality time-warp. The "we like our proprietary interface that we
will change at will just to force you to buy into our system" seems so
very 1980's to me. There are certainly folks that won't put up with
that.
>Veritas will never release the code to their file system. Many other
>companies have great things to offer that they cannot, because of the
>gross version dependancies that not having facilities like UDI cause.
Precisely. That's a good example of the above.
>With UDI you can have your cake and eat it too. If you want the source
>badly enough reengineer it. Having the UDI gives you the possibility of
>binary only drivers that can last many years without modification.
Yes.
>The performacne issues are a complete furphy. UW drivers can be slower
>but not so much much that last months processor upgrade does not blow
>away the difference. Use the X philosophy: design it properly because
>the performance will ALWAYS be here very much sooner than you think.
They can also be faster. For example, on a two-processor system let's
say you have two SCSI adapters controlled by the same UDI driver.
Becuase of the instance independence, the OS is free to schedule each
driver region at the same time on each processor. The driver doesn't
know it's happening and doesn't have _any_ locks in it. All the
necessary locking is done in the UDI environment where they're easy to
inspect for lock contention and correctness.
They can be more reliable. UDI drivers can run in independent domains.
So if you wanted to plumb a driver on this system to that system via a
TCP connection, that can happen. If you wanted to a UDI driver in user
space (with no changes to the driver) during driver developmet, that can
actually be done within a UDI environment that supports such things. If
your driver instance does something fatally naughty, the UDI environment
has all the information it needs to deallocate all the resources you had
allocated and notify everyone that's connected to you that you've been
shown the door. (Thus potentially making it impossible for a driver to
panic the system!)
RJL
>--
>Geoff Johnson
Geoff Johnson
One way to achieve this is to enable binary only facilities. Then anyone
with the money could dominate the business by suppling superior binary
only code and lock out other developers. Eventually making industry
dependant on the private facilities.
SCO should make a sweeping statement to the extent that any drivers they
supply will include full source. This would disarm most of the anti UDI
camp. How much competition is there now that SCO has to keep the Scroog
mentality on the source code. (How much of the drivers come from SCO
anyway? How much comes directly from the hardware manufacturers?)
How many hardware manufactures hate developing UNIX drivers. My guess is
most of them. Why not use the army of willing linux slaves to maintain
the drivers.
Linux desperately needs this interface and the related facilities to run
it. I have hacked kernels for 20 years. Looking at linux is like being
transported back to the begining of time.
Veritas will never release the code to their file system. Many other
companies have great things to offer that they cannot, because of the
gross version dependancies that not having facilities like UDI cause.
With UDI you can have your cake and eat it too. If you want the source
badly enough reengineer it. Having the UDI gives you the possibility of
binary only drivers that can last many years without modification.
The performacne issues are a complete furphy. UW drivers can be slower
but not so much much that last months processor upgrade does not blow
away the difference. Use the X philosophy: design it properly because
the performance will ALWAYS be here very much sooner than you think.
--
Geoff Johnson
Tony Lawrence
>
> Geoff Johnson <g...@saki.com.au> writes:
> >SCO should make a sweeping statement to the extent that any drivers they
> >supply will include full source. This would disarm most of the anti UDI
> >camp. How much competition is there now that SCO has to keep the Scroog
> >mentality on the source code. (How much of the drivers come from SCO
> >anyway? How much comes directly from the hardware manufacturers?)
>
> SCO is but one partner in UDI. SCO has currently contributed
> the majority of the sample drivers that will be in the reference
> implementation and are available now in the UW UDI Developer's Kit from
> our web page. They are available as source. But statistically, the
> majority of the interesting drivers on the planet will not be ours so I
> don't know what good such a sweeping statement would really make.
While it certainly wouldn't prevent binary only drivers, I
think such a policy could do nothing but good for SCO. It's
not that 99% of the people will ever even care about the
source; they absolutely will not. But psychologically it
feels good to know you have it. The chances are
infinitesimal that I'd ever even look at it, but given a
choice between with source/no source in otherwise equal
products, I and everyone else will choose with source every
time.
...
> They can be more reliable. UDI drivers can run in independent domains.
> So if you wanted to plumb a driver on this system to that system via a
> TCP connection, that can happen. If you wanted to a UDI driver in user
> space (with no changes to the driver) during driver developmet, that can
> actually be done within a UDI environment that supports such things. If
> your driver instance does something fatally naughty, the UDI environment
> has all the information it needs to deallocate all the resources you had
> allocated and notify everyone that's connected to you that you've been
> shown the door. (Thus potentially making it impossible for a driver to
> panic the system!)
Where's the fun in drivers if the system won't panic?
Warren Young
>
> SCO should make a sweeping statement to the extent that any drivers they
> supply will include full source.
That'd be grand, but there are a few flaws in your vision:
1. SCO doesn't develop drivers worth talking about. (Drivers "not worth
talking about" are those for generic PC components like chipset support,
IDE, VESA video, etc. Such drivers are the ante for having an OS.
Digiboard drivers, for a counterexample, are "worth talking about".)
2. For such a promise to matter, SCO would also have to promise to take
in changes made by the community. (Assuming the quality is suitably
high, of course.) I'm not sure SCO's liability model allows this. SCO
could disclaim liability in its license agreement, but SCO is in
business largely to sell the illusion of single-point accountability.
An OS developed by the community -- if only partly -- tears the illusion
of single-source liability apart.
3. Even if they provided driver source, it couldn't be under the GPL,
else they'd have to give their whole kernel away. All other open source
licenses give SCO the ability to take contributed changes and refuse to
distribute them. SCO would always have the option of taking everything
back closed source, including contributed changes. <conspiracy>Maybe
they'd kill off Linux, then close everything back up
again.</conspiracy> Sure, that's a paranoid statement, but if you're
not paranoid in business and law, you're just foolish.
Linux people don't trust each other out of the goodness of their
hearts. They trust each other because the GPL does not allow
selfishness to operate freely.
> How many hardware manufactures hate developing UNIX drivers. My guess is
> most of them. Why not use the army of willing linux slaves to maintain
> the drivers.
It'd be better if they developed the initial driver for the native Linux
driver interface instead: even more of the free Linux labor pool will
chip in to to help maintain that than a UDI one.
All the evidence points to Linux being the Unix consolidator. SGI will
adopt Linux, if they don't annihilate themselves first. Linux fits into
IBM's M.O. just fine: a dozen OSes, each for a particular purpose. HP
is an OS whore: they'll stump for any OS that sells hardware (they've
done it with Win9x and NT in the past). Compaq/Digital, well, Tru64
Unix isn't exactly going great guns, is it? They'll jump to Linux as
soon as it duplicates Tru64's higher-end features, unless Alpha dies
first. SCO's just told us it's hedging its bets with Linux -- they'll
hack the kernel of any *ix variant as long as it keeps bringing in the
cash, else OpenServer would be dead by now. That leaves Sun, the
company that is ALWAYS RIGHT. Hubris may yet kill them. :)
I think it's time to stow all the cross-vendor "standards": we seem to
always end up with wonky contraptions like Xenix, NetBIOS, PL/1, Open
Systems Interconnect, X.400..... UDI flies in those same circles: the
Project UDI site says that they've been at it now for 7 years.
"Interoperability" is a Costco bulk-size joke. It's time to pick one
strong vision and go with it. Isn't that how Unix got started?
Robert Lipe
>Tony Lawrence wrote:
>>
>> Robert Lipe wrote:
>> >
>> > Geoff Johnson <g...@saki.com.au> writes:
>>
>> > >SCO should make a sweeping statement to the extent that any drivers they
>> > >supply will include full source.
>> >
>> > SCO is but one partner in UDI. SCO has currently contributed
>> > the majority of the sample drivers [... as source ]
>>
>> While it certainly wouldn't prevent binary only drivers, I
>> think such a policy could do nothing but good for SCO. It's
We hear you. We intend to release the source for all the UDI drivers
that we've done in the reference implementation and have released the
ones we legally can so far in the current DK. Can I make a promise that
all the future ones will be there? Of course not. Can I promise this
for drivers I don't own? Of course not.
>I agree with Tony in the main effect is psychological (one day I won't
>need a dictionary, unfortunately that day was ten years ago!) Surely a
>wealth of device drivers will benefit everyone far more than any petty
>inter UNIX rivalry.
By allowing that wealth to be amortized across OSes we're building the
GNP of the industry instead of continuing to build the same road we've
been bulding for the last 20 years for the next 20 years.
>The problem for the anti UDI camp is that for amature kernel hackers,
>the UDI is a steep learning cure that can be hard to master with only a
>few hours a week to learn and refresh your memory. It also gets in the
It's different, for sure. I don't know that it's really that much
harder. You don't have to fret, for example, about placement of mutexes
or calling contexts. (Quick: can you call kmalloc from an interrupt
handler? How about while you're holding a sleep lock? Are the answers
the same or different for kmem_alloc?) You do have to get used to a
model with strongly modeled inter-module communications and extensive
use of callbacks.
>way of that warm and fuzzy feeling of getting your hands directly on a
>juicy piece of hardware. Remember that most of the linux community are
>doing this for the love of it.
If you are driver-curious and want to knock down a 100 line driver for
your own use, UDI is probably the wrong tool for the job. If you're in
the driver business and you actually have development and support costs
associated with it, it looks really good.
>If SCO wants to make its money from linux then this is one of the best
>ways of paying back the hard work that the linux community has done to
>make this possible.
While I'd love to sprinkle the earth with thousands of drivers for all
the interesting hardware ever built, the reality remains that SCO just
doesn't own all of them. We can't release what we don't have. Yes, I
understand the merits of placing source in the hands of the public and
promote it when I get a chance.
>Just supplying a few prehistoric QIC and NIC drivers is not going to cut
>the mustard.
Do you know what drivers are in the development kit? Do you know what
drivers are slated to be in the reference implementation?
>SCO seems to take forever to fix trivial bugs that can cripple some
>systems. It took weeks to fix the interrupted tape driver bug where you
>had to shut the server down to be able to reopen the tape (This is not
>the poxy proprietary product bug). Any half decent kernel programer
>could have fixed this in a few hours, so the real problem was for SCO
The decision of providing source for a driver remains a different
decision choosing to use a documented, performant, stable programming
interface to do it. So please distinguish between the two decisions.
UDI provides the interface. It allows either source or binary
distributions.
RJL
Robert Lipe
>I think it's time to stow all the cross-vendor "standards": we seem to
>always end up with wonky contraptions like Xenix, NetBIOS, PL/1, Open
>Systems Interconnect, X.400..... UDI flies in those same circles: the
>Project UDI site says that they've been at it now for 7 years.
We also end up with things like TCP/IP from the IETF, ISO C, and UNIX
95/98.
Each of those has improved the quality of my life as a developer.
Geoff Johnson
> > >supply will include full source. This would disarm most of the anti UDI
> > >camp. How much competition is there now that SCO has to keep the Scroog
> > >mentality on the source code. (How much of the drivers come from SCO
> > >anyway? How much comes directly from the hardware manufacturers?)
> >
> > SCO is but one partner in UDI. SCO has currently contributed
> > the majority of the sample drivers that will be in the reference
> > implementation and are available now in the UW UDI Developer's Kit from
> > our web page. They are available as source. But statistically, the
> > majority of the interesting drivers on the planet will not be ours so I
> > don't know what good such a sweeping statement would really make.
>
> think such a policy could do nothing but good for SCO. It's
> source; they absolutely will not. But psychologically it
> feels good to know you have it. The chances are
> infinitesimal that I'd ever even look at it, but given a
> choice between with source/no source in otherwise equal
> products, I and everyone else will choose with source every
> time.
>
I am definitley in the pro UDI camp as the rest of my email previous
shows.
I agree with Tony in the main effect is psychological (one day I won't
need a dictionary, unfortunately that day was ten years ago!) Surely a
wealth of device drivers will benefit everyone far more than any petty
inter UNIX rivalry.
The problem for the anti UDI camp is that for amature kernel hackers,
the UDI is a steep learning cure that can be hard to master with only a
few hours a week to learn and refresh your memory. It also gets in the
way of that warm and fuzzy feeling of getting your hands directly on a
juicy piece of hardware. Remember that most of the linux community are
doing this for the love of it.
If SCO wants to make its money from linux then this is one of the best
ways of paying back the hard work that the linux community has done to
make this possible.
Just supplying a few prehistoric QIC and NIC drivers is not going to cut
the mustard.
One of the major UNIX liabilities is the lack of hardware suport. Its
important that given the oportunity to catch up slightly, that it is not
wasted.
Robert wrote:
> I don't think any serious hardware vendor depends on "willing slaves" > to support their product.
I did not mean that vendors pass off THEIR support obligations
completely or even substantially, let the thousands of people like me
who have their own balls on the line have the source so that we can say
that the bug is at file F line X. Rather than the current lame "it
does'nt work".
SCO seems to take forever to fix trivial bugs that can cripple some
systems. It took weeks to fix the interrupted tape driver bug where you
had to shut the server down to be able to reopen the tape (This is not
the poxy proprietary product bug). Any half decent kernel programer
could have fixed this in a few hours, so the real problem was for SCO
just to find someone to look at it. Well there are thousands of us
willing and able to do just that.
Don't just sell linux: embrace its philosophy!
--
Geoff Johnson
Geoff Johnson
>
> 1. SCO doesn't develop drivers worth talking about. (Drivers "not worth
> talking about" are those for generic PC components like chipset support,
> IDE, VESA video, etc. Such drivers are the ante for having an OS.
> Digiboard drivers, for a counterexample, are "worth talking about".)
There are the very most interesting drivers. Any amature can write a low
performance serial port driver. Understanding of the inner workings of
very little known chips is very hard to get.
> 2. For such a promise to matter, SCO would also have to promise to take
> in changes made by the community. (Assuming the quality is suitably
> high, of course.) I'm not sure SCO's liability model allows this. SCO
> could disclaim liability in its license agreement, but SCO is in
> business largely to sell the illusion of single-point accountability.
> An OS developed by the community -- if only partly -- tears the illusion
> of single-source liability apart.
Driver development is not like that. Bugs are completely crippling,
extreemly hard to find but bleeding obvious when yo do. So you only have
to point the finger at the offending line of code and its consequences
and the fix are usually easy. ie SCO could take advice and have their
insurers laughing all the way to the bank and happy customers who get
fixes immediately that they can do themselves or wait for a week or two
and get SCO certified fixes. Bug finding is the time consuming bit, not
bug fixing.
>
> 3. Even if they provided driver source, it couldn't be under the GPL,
> else they'd have to give their whole kernel away. All other open source
> licenses give SCO the ability to take contributed changes and refuse to
> distribute them. SCO would always have the option of taking everything
> back closed source, including contributed changes. <conspiracy>Maybe
> they'd kill off Linux, then close everything back up
> again.</conspiracy> Sure, that's a paranoid statement, but if you're
> not paranoid in business and law, you're just foolish.
>
> Linux people don't trust each other out of the goodness of their
> hearts. They trust each other because the GPL does not allow
> selfishness to operate freely.
>
> > How many hardware manufactures hate developing UNIX drivers. My guess is
> > most of them. Why not use the army of willing linux slaves to maintain
> > the drivers.
>
> It'd be better if they developed the initial driver for the native Linux
> driver interface instead: even more of the free Linux labor pool will
> chip in to to help maintain that than a UDI one.
I never said that the linux community should do the original
development. I said they should do SOME of the support.
> All the evidence points to Linux being the Unix consolidator. SGI will
> adopt Linux, if they don't annihilate themselves first. Linux fits into
> IBM's M.O. just fine: a dozen OSes, each for a particular purpose. HP
> is an OS whore: they'll stump for any OS that sells hardware (they've
> done it with Win9x and NT in the past). Compaq/Digital, well, Tru64
> Unix isn't exactly going great guns, is it? They'll jump to Linux as
> soon as it duplicates Tru64's higher-end features, unless Alpha dies
> first. SCO's just told us it's hedging its bets with Linux -- they'll
> hack the kernel of any *ix variant as long as it keeps bringing in the
> cash, else OpenServer would be dead by now. That leaves Sun, the
> company that is ALWAYS RIGHT. Hubris may yet kill them. :)
>
> I think it's time to stow all the cross-vendor "standards": we seem to
> always end up with wonky contraptions like Xenix, NetBIOS, PL/1, Open
> Systems Interconnect, X.400..... UDI flies in those same circles: the
> Project UDI site says that they've been at it now for 7 years.
>
> "Interoperability" is a Costco bulk-size joke. It's time to pick one
> strong vision and go with it. Isn't that how Unix got started?
Its also how UNIX fragmented about five minutes after it was invented.
Linux kernel design is a "weak" element. It is fast reaching the stage
that gcc reached where a "private (but still open)" group will have go
away into a corner and clean it up. UDI or its equivalent in terms of
driver design strength ia absolutley necessary if Linux wants to get
into the multi CPU systems as a real contender. Dead lock avoidance is
not a job for amatures with third rate design tools.
>
> --
> = Warren -- See the *ix pages at http://www.cyberport.com/~tangent/ix/
> =
> = ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
--
Geoff Johnson
Warren Young
>
> > It'd be better if they developed the initial driver for the native Linux
> > driver interface instead: even more of the free Linux labor pool will
> > chip in to to help maintain that than a UDI one.
>
> I never said that the linux community should do the original
> development. I said they should do SOME of the support.
You misunderstood my comment: "they" refers to the hardware company.
The hardware company develops the original driver as a native Linux
driver, which the Linux community can maintain.
Obviously that vision only works if you also buy my argument that Linux
will eventually make all the commercial Unixes obsolete.
> > "Interoperability" is a Costco bulk-size joke. It's time to pick one
> > strong vision and go with it. Isn't that how Unix got started?
>
> Its also how UNIX fragmented about five minutes after it was invented.
Unix fragmented because every vendor started with one of the two
original Unix flavors, and then wanted to add feature FOO, but they
never shared code or even designs for that feature, so every
implementation of FOO was different. Add in features BAR, QUX, BIFF and
GARPLY and you arrive at the current mess in commercial Unixes.
If FOO et al. had been in the original version of Unix, Unix wouldn't
have fragmented. No one has renamed grep or cat or creat(), no matter
how much people have complained that they're stupid names. These
commands and functions are Standard. They're Standard because they
existed in the common code base, not because Ken Thompson or AT&T or the
IEEE said they should be The Standard.
POSIX was a vaguely successful attempt to get vendors to share designs.
POSIX didn't actually create much of anything, though: they just
standardized the existing designs everyone already had in common.
The places where POSIX tried to do something original or standardize on
one vendor's implementation have almost all been withdrawn from
consideration by the IEEE. The POSIX print administration committee --
just as one example -- died of squabbling, so there is now no standard
way to admin print jobs. Other failures include POSIX security
extensions, removable media handling, multiprocessing extensions, and
user interfaces.
The GPL is the path out of the trap. It enforces code sharing between
vendors.
In a way, the Single Unix Specification is the a standard of the same
kind I'm proposing Linux should become: a bunch of people that use a
common code base stand up and say, "We're a Standard now! If you want
to be Standard, too, license a copy of the common code base." No
fragmentation, no multivendor compromises, no slightly-nonstandard
variations for a certification committee to accidentally overlook.
So why Linux and not Single Unix? Bear with me and I'll explain my
logic.
I think SCO's Linux division will make money: it won't need to be
subsidized by their commercial offerings. If that happens, it follows
that they could give away UnixWare's code and continue making money.
I seem to recall that Sun paid a lump "forever and ever license fee" to
SCO right after SCO bought Unix from Novell. IBM probably won't pay
royalties to SCO after the Monterey merge finishes. HP....I guess
they're still paying Unix royalties, but it probably doesn't amount to
much, and it's got to be declining. Compaq/DEC and SGI are busy trying
to beat each other to the "Our Unix doesn't matter any more" finish
line.
Even if Unix vendor licenses still matter to SCO, how much longer can
they be a useful revenue stream?
Let's say SCO no longer derives a useful amount of money from vendor
licenses. Why not give the code away to kill Linux? It would work,
without question, immediately. OK, not so much "kill" as "permanently
maim". But SCO didn't do that: instead they came out with their own
Linux. Why?
The remaining UnixWare revenue streams are end-user license fees and
support contracts.
Support is a given. SCO could fire its development staff tomorrow and
live for years on support contracts. (ESIX still exists for that very
reason.)
Conclusion: SCO won't GPL the core UnixWare code because it needs the
license fees.
Final conclusion: if you think a free OS is a good idea, UnixWare won't
be it. That's why I give Linux the nod.
> Linux kernel design is a "weak" element. It is fast reaching the stage
> that gcc reached where a "private (but still open)" group will have go
> away into a corner and clean it up. UDI or its equivalent in terms of
> driver design strength ia absolutley necessary if Linux wants to get
> into the multi CPU systems as a real contender. Dead lock avoidance is
> not a job for amatures with third rate design tools.
Tools are never the most important element of a development effort.
There are no silver bullets. Human ingenuity is far more important than
magic tools, and all the evidence points to the Linux community as
having plenty of that.
I don't dispute your GCC comment: all open source projects of any
complexity have to have a focused design team. GCC lost its team when
RMS decided to stop hacking and start politicking full time. Linux
still has its original designer. Even if Linus should go away some day,
there are several benevolent-dictators-in-training.
Cygnus picked up the GCC mantle. Cygnus is now part of Red Hat. Red
Hat is a company that employs several of the "amatures" that work on the
Linux kernel.
No amateurs, no missing design team, and no one gives a damn about the
tools. What other fatal flaws do you see with Linux?
Bill Vermillion
Warren Young <war...@etr-usa.com> wrote:
>I think SCO's Linux division will make money: it won't need to be
>subsidized by their commercial offerings. If that happens, it follows
>that they could give away UnixWare's code and continue making money.
If SCO's Linux is profitable it will be one of the first to do so.
Red Hat expects to be profitable by the end of 2002 - so SCO has 18
months to become one of the first profitable Linux distributions.
Break even point is projected for the November quarter of 2002.
(www.zdnet.com/enterprise/stories/main/0,10228,2588854,00.html)
[that's typed in and I hope I didn't screw it up]
Corel is having a very hard time. Just lost $23 million dollars
this quarter as sales fell 48 percent.
Is any Linux vendor profitable? I can't remember where I saw the
figures but one of the largest volume units is the Mandrake
distribution of MacMillan - and it's one the distributions seen in the
big discount outlets - though doesn't get very good press in the
Linux community.
I wish SCO luck. Based on the performance of others it's a very
hard arena in which to make money. I've only looked at the
finacials on a few so let me ask this question. Is any Linux
distribution making money?
--
Bill Vermillion bv @ wjv.com