Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!paladin.american.edu!gatech!swrinde!newsfeed.internetmci.com!in2.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc,comp.os.linux.advocacy
Subject: Re: Historic Opportunity facing Free Unix (was Re: The Lai/Baker paper, benchmarks, and the world of free UNIX)
Date: Sun, 14 Apr 1996 16:48:35 -0700
Organization: Me
Lines: 730
Message-ID: <31718ED3.555EB900@lambert.org>
References: <4ki055$60l@Radon.Stanford.EDU> <jdd.829261293@cdf.toronto.edu>
<yfglok14n5r.fsf@time.cdrom.com> <31702487.420C2193@lambert.org> <yfg3f67giw7.fsf@time.cdrom.com>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:21506 comp.unix.bsd.386bsd.misc:622 comp.unix.bsd.bsdi.misc:3241 comp.unix.bsd.netbsd.misc:3059 comp.unix.bsd.freebsd.misc:17462 comp.os.linux.advocacy:45795
Jordan K. Hubbard wrote:
]
] In article <31702487.420C2193@lambert.org> Terry Lambert
<terry@lambert.org> writes:
]
] This is hard; this is a political question. My personal answer:
] Motif. It is the only standard GUI ratified by a UNIX standards
] body, and it meets the additional requirement of being nearly
]
] Sorry, Terry, but Motif (unlike X) is not free, and none of the clones
] are anywhere close to taking the place of the OSF distribution.
]
] Yes, Motif can be had at a relatively low cost but it's still not
] something we can standardise on for the free operating systems when
] we've got the OSF sticking their hands out at the toll-booth saying
] "$60 royalty please!" every time someone downloads a copy of one of
] these OSs from their friendly neighborhood FTP server.
This is only true if you intend to distribute the build environment
or unlinked (or shared) libraries.
If you only distribute binaries, then there isn't a problem.
It's a relatively trivial exercise to thwart the intent of the
OSF license while upholding the spirt; like the GPL, one can
use an oblique approach to subvert it.
The easiest approach would be to establish a link server, where
you package up objects and local libaries, send them off to
someone with a license, and recieve linked images back. You
could even automate the thing. The binaries would be statically
linked and distributed by the person with the license to someone
who would redistribute them.
OSF couldn't stop this without damaging their revenue stream,
since it would require prohibiting commercial distribution
through resellers to effectively stop reapplication of the
technique. Even then, they could only do it with new, not
existing, licensees.
] I'm sure that the distinction between a freely available
] windowing system and a non-freely available GUI standard
] isn't lost on you, and you yourself later say:
]
] standard that requires a buy-in to OSF to let you play. Motif
] is proprietary technology, and as such, should never have been
] ratified by a standards body. Either bench-packing or buyoffs
I myself also say that WIN32 shouldn't be a standard; what is
your point? 8-).
[ ... more irrelevent stuff, in the face of a link server ... ]
] This one is easier; it is completely technical, and I have
] tried to push it in a large number of commercial organizations,
] including Novell USG (the former USL) without success:
]
] This is NOT easy! Easy-er, maybe, but all the stuff you outline blow
] has a tremendous development cost associated with it! Maintaining DDX
] code for per-card drivers in the kernel? YIKES! Even assuming that
] we could find someone craz^H^H^H^Hmotivated enough to yank this
] screaming out of XFree86 and into the kernel (unless you have the
] temerity to suggest that all such development should be done from
] scratch!), it would be a never-ending responsibility as each new
] generation of cards came out, and some popular current-generation
] cards like the Matrox would probably never be supported. This just
] moves the problem onto the one group of people (the OS hackers) who
] are the least motivated to solve it, rather than leaving it more
] comfortably with the graphics hackers who already populate the
] various X groups.
I guess that would depend on the approach used to "rip the code
out", and whether or not you could just take the XFree86 code
as it is generated and vendor-branch it.
] 2) Implement "fallback drivers". Such a driver is a
] standard driver implemented on BIOS calls. For
] video, this is INT 10. This will be sufficient
]
] That's probably not such a bad idea for a wide variety of things (like
] disk drivers also), but as yet the work remains to be done and there
] isn't even anyone currently taking it up, AFAIK. It's been on the
] wish list for almost 3 years now.
Yep. I agree. It's been long outstanding. Like the lead of
commercial OS's in the potential market for desktop systems.
] Do bear in mind that my postings were attempting to describe the
] situation as it stands today, leavened with a healthy dose of realism
] about what we might hope to accomplish in the next 12 months or so.
A full 12 months? With how many people with tree commit
priviledges, and how many more who submit code?
It's possible, it's just not probable because of the issue of
what motivates volunteer efforts. People can complain about
things, but it's obvious that they don't *want* it badly
enough.
Like governments, which are also subject to change, people get
the dsoftware they deserve. 8-).
] No offense, but your postings always have a large element of the
] surreal to them (were you Franz Kafka in a previous life?) where you
] gesture wildly in all directions about highly theoretical solutions
] and many "if we just virtualize the frammis and re-implement the
] frotch code as a multi-layered, stackable protocol breemitch, it'll be
] trivial to..." sorts of suggestions. Left unanswered for me at the
] end of each reading is the rather bemused question of "Yeah, but WHO
] is going to do all that work? Who?!"
So commit my patches and get out of the way. 8-|. I'll be more
than happy to work on this sort of thing instead of working on
reintegrating my patches into -current on a daily basis because
of the inability of SUP or CTM to correctly integrate changes
without destroying the ability to maintain several local venodr
branched simultaneously.
The major bitch has always been "code maintenance" (of what should
only be considered intermediate code -- not final code) or "ability
to import future code from CSRG" (which happens to be a now-defunct
argument).
] One type of applied resource without the other is quite useless
] if it's your intention to actually produce a working prototype.
I have provided full header files and library stubs for a Motif
library, written from scratch from published documentation,
which is not a Motif replacement, since it can only run the first
3 chapters of the Young book examples. It would, however, provide
sufficient information to someone about to submit a job to a link
server as to whether the link would be successful and the submission
should take place.
If you want to take the legally risky route and use Lesstif, which
was engineered with promiscuous knowledge of Motif itself, well,
it's nearing usability for a number of applications. Otherwise,
a link server is an easy workaround.
I wrote a Sun shared library, which my employer deemed a competing
product and prevented me from releasing under my non-competition
agreement... but Jeffrey Hsu's work that helped me do that became
the basis if the GCC PIC capability, and forms the basis of the
current shared library code in BSD and Linux -- so I think I had
something to do with that.
I wrote the original LKM system for loading kernel modules in
BSD, even though the NetBSD camp picked up the code long before
the FreeBSD camp.
I fixed the file system instance initialization code (patches
yet to be integrated) so that file system interface extension
will actually work (instead of leaving off all VOP's after the
VOP's supported by UFS -- look at the current code initialization
and see if it traverses the vnode_if.c declared structure
elements or the ufs structure elements for initialization, if
you don't believe me).
I fixed the layering abstraction for namei() (which is still
broken in several fundamental but non-obvious ways, despite
my fixes) to enable multibyte character set support -- such as
is required for proper support of VFAT and NT file systems,
which use 16 bit Unicode for directory information.
I fixed the vfs_syscalls.c code to enable lock state recovery
for kernel reeentrancy for kernel multithreading and high grain
parallelism for SMP (also yet to be integrated because some people
don't want SMP changes in the main line code because they buy
into the *incorrect* idea that SMP must add overhead that can't
be compiled away to nothing).
I have participated in *countless* design and interface
discussions; I believe my participation has had positive
impact.
I put forth the framework for system state recovery on restart
(my first complaint about memory overcommit was over three years
ago) long ago.
I'd have to say I've done a bit more than "wave my hands".
] Now let's talk about "magic install images". Such an image is
] a non-memory-overcommit (fd's are not strictly recoverable for
] executables) APM save image of a sytem "just about to be
] installed".
]
] I'd need to see a prototype of this before I could even begin to
] believe there weren't 500 different "gotchas" still waiting to spring
] on the unwary implementor.
Nate Williams already has a prototype. It's called the APM code
from the "BSD Nomads" group in Japan, and his own contributions
to the APM code and source integration.
Fundamentally, there is no difference betwen restoring machine
state from a disk image of saved state of the same machine, and
that of a different machine.
The difference is entirely in the abstraction of the save state
information from the processor-specific hardware methods that
must be used to implement the recovery on various systems.
Not having looked at the APM code, I can only say that from past
experience with Nate's code, I find it highly unlikely that he
has built his state-recovery code to be machine specific.
] You yourself well know that with the implementation of every
] new idea you have 10% of the development time spent in a
] frenzied blitz on the proof-of-concept ("Yay! It's possible!
] It sort of works!") and 90% trying to actually make it work
] in enough cases to become a truly general solution.
I do *NOT* know that. I *design* before I code. The *one*
exception to which you can point is the hastily integrated
modular system startup code which I provided, which had too
many "goto"'s for some people who don't understand control
flow if they don't have to get into "vi" and use "%" to match
braces to see where a "break" will leave them instead of looking
for a goto label target. I have *NOT* made the mistake of
offering prototype code for public inspection since that time;
the code I presented was *NOT* intended to be integrated.
[ ... ]
] Yeah, but you need to write this, first. There *is* no easy to use
] control panel application for X, hence it's an education problem and
] will STAY an education problem until someone implements it.
FVWM has one. FVWM is the MWM replacement you must use to avoid
royalty problems with use of Motif. Two birds with one stone.
] Terry, again, you can't just explain every problem away with a glib
] "well, that's simple - just write a control panel and a nice paint
] program and a word processor and a device configuration utility and
] maybe one of those nifty event log display programs like NT has and
] and.. Geeze, what's your problem, Jordan? The problems you raise are
] _trivial_ to solve!" :-)
I have been working on prototype control panel item code since
I discussed it in regard to fixing the damn "add disk" problem,
once and for all.
I have an account management tool that operates from a grammar
and provides a grammar-driven user interface that is a specific
instance of a class of interfaces, of which a disk management
tool is a member. I also have a disk management tool that
operates from a grammar and is also an instance of the interface
class.
The same GUI front-end should be able to operate each using a pty
to interactively communicate with both tools.
The tools are also usable from the command line.
The tools are also usable as "one-shot" command line tools, which
is to say that the same shell-script front end should be usable
with both of them.
When the tools are done, I'll publish them. Obviously, there may
need to be extensions to the GUI input grammar as more tools are
greated, but it is a good start.
] X is a windows system, not a user interface. Just like Unicode
]
] Bingo! Thank you, Terry. Now that we've both agreed on that, we can
] try to find some nice non-proprietary solutions to the problem and
] hope that everyone is willing to sit patiently for the 2-5 man-years
] it will take to implement them? You say my estimate is too long?
] Fine - prove me wrong, please! :-)
Your estimate is too long, if you start counting from today instead
of when the FreeBSD project started... and you promise not to
actively oppose progress in this direction.
[ ... ]
] Judges say:
] SMTP != MAPI. SMTP is a different level of interface,
] and the presence of SMTP alone does very little to give
] an application which "just wishes to send some mail" an
] *easy* way of doing it.
Feel free to argue with Garrett about whether UNIX needs a common
mailbox interface; I don't seem to be getting anywhere. For that
matter, feel free to argue with yourself about the POSIX print
interface (Athena Palladium) I wanted to have integrated for an
application that "just wishes to print s document".
] If you'd read the MAPI spec there would be no way in
] heck you'd even have tried to compare them - it's like
] saying the Flintstones' cars have an ABS braking system
] because they can always just lift their feet up if the
] cars start skidding! :-)
If you'd ever used MAPI... you wouldn't be trying to sell it as a
"must have" checkbox line item.
] SQL != ODBC. SQL is a query language and ODBC is a set
] of standard API calls that an application can make
] directly to an underlying database. Creating SQL queries
] programmatically, or even using embeded SQL and a
] precompiler, is a whole 'nother bear and not even
] close to the ODBC API.
1) An ESQL precompiler is downloadable as sample code for
the O'REilly "lex & yacc" book. Source is on ftp.uu.net.
2) A UNIX implementation of ODBC was posted to the group
comp.unix.sources last year. You can pick it up from
ftp.uu.net whenyou pick up the ESQL precompiler.
] I won't even try to refute your contention that OLE has
] anything which merits a direct comparison to standard
] IPC or even a language like REXX (which is hardly a
] UNIX standard to the degree that OLE is for Windows
] - only AREXX for the Amiga ever even came close to
] this degree of wide acceptance).
[ rrrt rrrt -- specious argument alert "It's not a standard NOW!
We can't ever use it!" -- rrrt rrrt ]
OLE is an IPC facility which requires OLE servers to be written
for each type of IPC. If you had ever been on a project that
needed to communicate information to the Windows95 system
monitoring agent, or be controlled by the scheduling agent,
you'd know that it wasn't as simple as "call this API with the
magic arguments".
] UNIX has two types of standards: good ones (defacto) and bad ones
] (industry mandated for the purposes of competitive advantage).
]
] Maybe we just have a highly different definition of the word
] "standard" here. I define a standard as something that's widely
] embraced by vendor, user and application provider alike - not merely
] something published as a white paper and widely agreed to be a good
] idea by all the programmers and perhaps a couple of the ISVs who read
] it.
A mandated standard is one which has been ratified by a standards
body. A defacto standard is one which may or may not have been
ratified, but which has achieved common usage on technical merit.
If you want to argue technical merit of some defacto standards, I
will, but be warned that we are already dangerously close to being
off-topic already.
Standards embraced by vendors are, by definition of "embraced by
vendors", something whose only purpose is to increase the vendors
income.
In general, a vendor is likely to embrace a proprietary standard
(ie: Novell's "POSIX compliant printing... with extensions", or
Motif, or streams, etc.) if they believe it cuts someone out of
the market.
From a vendors perspective, it is better to lock someone into
buying your product than it is to be selling a commodity. The
UNIX vendors have traditionally fought *hard* to prevent the
commoditization of their market. Once commoditized, a market
operates on who can provide the commodity at the lowest margin
to themselves. Standards are used by vendors as tools to prevent
commoditization.
] Motif is only a "standard" because the users were so tired of the
] bitter infighting ("the GUI wars") that they would have sold their
] souls to the devil if he'd only come along with a contract promising
] to lead them out of the combat zone and give them ONE set of UI
] guidelines to follow. As history shows, that's also exactly what
] they did.
So what are you planning on charging them, now that the credit
balance on their souls is dangerously low?
] I don't really see any other standards worth talking about in
] the UNIX world today (Unix95? Oh great, *another* standard
] that you have to pay a lot of money for the privilege of
] adopting!) so this will be a very short argument.
I agree with that particular statement (no surprise; I've made
the same statement myself re: standardization of proprietary
technology).
] ] The fact is that it's already too late for UNIX on the desktop.
]
] You sound like Kanwahl Rheki in a meeting I attended at Novell
] right before he (ahem) "left Novell to pursue other opportunities".
]
] Hah, he's not the only one! Lotus' director of UNIX development
] started his keynote address at the Irish Unix User's Group with those
] very same words. I'm sure Kanwahl left because he didn't much like
] the role of Cassandra - right and despised for it nonetheless.
Oh yes, these people must be right... that's why Excel is eating
Lotus for lunch and Word is eating Word Perfect, and NT Server
is eating Novell. Because it's a lost cause, and there is no
room in the market for anyone but Microsoft, so we all might
as well atttend their developer conferences and let them tell us
what software the deign beneath their dignity to write.
Sorry, but Fuedal lordship went out in the middle ages, and I'll
be damned if I'll play serf or grant Microsoft ownership of the
table.
] I remember him making a similar statement about UNIX on the
] desktop, after which I raised my hand and asked "What *NOVELL*
] operating system will people be running on their desktop, then,
] if not UnixWare?". To which he replied Novell USG would be
] concentrating on application servers.
]
] I don't understand that statement at all. Novell didn't *have* a
] desktop operating system, so what? You raising your hand and saying
] "I see an orange, a drugged hamster and a pound of Earl Grey tea here
] on the table - which are we going to use in our fight against crime?"
] would have made just about as much surrealistic sense. Novell didn't
] have a desktop strategy, never had a desktop strategy (that they ever
] showed the world in any significant way, anyway, and their brief,
] aborted affair with UNIX hardly counts) and probably never WILL have
] a desktop strategy. They made their money selling network servers
] and that's really the only market they understand. Duh. You groom
] a whole legion of executives to go out and try to dominate the
] network connectivity market, it's hardly a surprise that their
] vision becomes narrowed.
The meeting was an announcement of a press release that Novell
was getting out of the UNIX desktop market. Contextually, the
question was supposed to read as "so you are bending over for
Bill without a fight?"
I think if I were a Microsoft empoyee, and I saw something
stupid happening, I'd be *obligated* to yell "Hey! Something
stupid is happening! Come see the stupidity inherent in the
system!".
I think it's pretty obvious that DR-DOS was an attempt to
play "spoiler" for the DOS market -- it's what led to Windows95.
If you can't buy Windows 3.1, then you can't use DR-DOS.
It's not surrealism to say that opportunity to dethrone Microsoft
existed, or even that it still exists.
Your picture of Novell as "the monolithic well-oiled machine with
galley slaves who only know how to row in one direction, making
it a formiddable juggernaut, but only if you are in its path" is
absurd.
Novell has always operated via shotgun -- at least under Ray
Noorda -- shoot a lot of bullets in a direction, and market the
one that hits the target.
Novell under Noorda was the Menlow Park of the software industry;
internal competition was rampant.
Microsoft, on the other extreme, is the Japan of software. They
are "the first to be second". Bill, unlike most management, has
obviously read Demming, and profitted mightily by it.
All you have to do is look at their products: those that they
produced as improved versions of what was "there first" have
flourished: Word, Excel, etc.. Those that have been original
to them, or developed simultaneously without knowledge of their
competition have languished... Money being the most recent example.
People who say Bill was "lucky" and "at the right place at the
right time" are correct. He *was* he got a goot break. Those
who blame all of his success on that, though, are sadly mistaken.
Netscape has followed the same formula: it's a better Mosaic.
It's easy to make money with that formula, if that's where your
head is at.
This whole discussion of a desktop UNIX is predicated on the idea
of being abetter desktop than the existing desktop.
Look at a partial cash-in chain for Microsoft:
Lucky break -> DOS
MacOS -> Windows, a better MacOS than MacOS
(better because of commodity
hardware, not technology)
OS/2 Warp -> Windows95, a bettter Warp than Warp
UNIX -> NT, a better UNIX than UNIX
NetWare -> NT, a better server than NetWare
Excel -> A better Lotus than Lotus
Word -> A better WordPerfect than WordPerfect
...
] Hmmmmmmm... Ray Noorda left after that statement, and less than
] a month later the group that later broke away to become Caldera
] came into existance... hmmmmmmmm.
]
] Naw, that was the Bavarian Illuminati at work, Terry! They contacted
] Ray and threatened to show him compromising pictures of Ross Perot's
] daughter if he didn't resign - it's a conspiracy, I tell you! :-)
Left the meeting, not the company. Caldera was an internal Novell
group for a *long* time.
] With due respect, anyone who portrays a technical market as
] "impenetrable" or "already won by the competition" is a jackass
] who is going to drive your product into the toilet.
]
] And anyone who tries to make a silk purse out of a sow's ear will find
] themselves holding a bloody scrap of flesh with little resale value.
] Can we stop spouting the meaningless aphorisms now? :-)
I will if you will.
] Porting cost is a function of developmental architecture and
] approach to implementation.
]
] Most modern GUI builders are causing this gap to widen, but it
] boils down to programmers who don't understand portability
] issues, and attempts to salvage sales from legacy markets.
]
] Thanks for the engineering lesson, Terry. However, we still have to
] live in the real world and if you strongly think that you have any
] chance of re-educating the world-wide base of programmers then I can
] only suggest that you start a training company and give seminars!
] You'll make a bloody fortune. Until then, certain mistakes will
] continue to be made and we'll be faced with the limitations that come
] out of same.
Is this the same advice you gave Stallman? 8-).
] ] I worked for Lotus's UNIX porting group (where I worked on
] ] the ports of AmiPro [now Lotus Word] to the Sun and SCO
] ] platforms) and I can
]
] You mean "making Intel/DOS/Windows-centric code run"? 8-).
]
] Of course. You think a company that makes $2 billion dollars a year
] off the Windows market and $300K off the UNIX market (real figures
] from when I worked there) is going to pervert their code base at the
] request of a few UNIX weenies? Get real! The windows weenies will be
] the star programmers with their gold plated keyboards and $10K
] development bonuses and the UNIX development weenies will be happy to
] have jobs at all and take whatever they can get. No amount of
] up-front pleading for "porting awareness" will help, either, as
] market forces will simply take over and feature after feature will
] creep into the Windows product, making it a harder and harder
] target for portability. Even if the Windows programmers are best
] friends with the UNIX programmers and utterly sympathetic, this
] will happen with any substantial code base. Market and deadline
] pressures will out every time!
This is short term thinking at its worst.
It may or may not be desirable to "appease the UNIX weenies", but
the issues of "portability awareness" are exactly what murdered
WordPerfect when Microsoft released "Word for Windows". And before
that, what murdered "WordStar" when "WordPerfect for DOS" was
released.
And the same issues are exactly what's murdering NT on non-Intel
platforms.
If you are an app developer who has read this far, take note! WIN32
is *not* the last API you will see in your product's life cycle!
] I'd argue that the original code base was flawed.
]
] I've worked probably 50 different contracts in my 18 year career (and
] some 10 full-time positions) and I've yet to see a code base that
] wasn't. Reality striketh.
Work on a new product (even if its spec is copied from a spec for
a competitors product), and you'll only see that happen if the
people in charge are screwups.
People like that don't stay in charge long; either they are found
out, and not placed in control of future products, or their company
comes deflating around their ears. Either way, they are out of
there.
] You can bet Microsoft is suffering the same problems on transition
] to Windows NT. The main reason that Windows programs aren't
] running on all the NT platforms instead of just the Intel ones
] is that Microsoft has their share of programmers that think:
]
] Oh, I know. I've even heard that Win95 suffers from a considerable
] defection rate in the OS group from programmers who desperately want
] to escape a 10 year old ball of mutant fur and get into the NT group
] where at least things were more-or-less designed. My heart bleeds for
] them, really! :-)
Funny; that's just what the former NT 3.x release manager I was
talking to Thursday night said...
] "Microsoft's problems" is another way of saying "competitor's
] opportunities".
]
] Aw, they've got enough money that they merely need skim the cream off
] the top of another 2 or 3 year's worth of CS graduate classes to get
] through this temporary setback ("Come work for Microsoft, little boy!
] It'll look great on your resume' and we'll give you nice this sack of
] money, too! C'mon, hop in the car! It's just a short ride from
] here!")
Please see above; the NT problem is endemic. It is not "just a
slump" to be worked through. THe problem will lessen (on Intel,
anyway), as Windows95 forces the move to WIN32 API's in replacements
for legacy apps. Given that the average life-cycle of a computer
in a business is just over 2 years, I expect that to be sooner than
you might think.
] You can't generalize about the possibility to create a successful
] UNIX desktop simply because UnixWare failed to do so (and not for
] technical reasons, at that).
]
] I wasn't generalizing ONLY because UnixWare failed to do so, but you
] have to admit that there aren't very many existing examples *to* point
] to!
That's because success displaces competition. It's the same
rationale at work that prevents everyone from going to a GNU
paradigm: there is only room for one Cygnus-type-business for
each GPL'ed "product". Just so in the regular marketplace,
if all you consider is majority marketshares.
The only examples I could point to are all refutable at some
later date because the marketshare is about equal only because
that particular market is still in flux. Check back in 6 to 9
months (guaranteeing 2 quarterly reports) for a clear winner
in any market currently in flux.
] I thought I was being rather fair in not even mentioning SCO's
] Open DeathTrap! :-)
ODT was more than usable on Xenix. SCO's Federal Systems
Division threw away all of SCO's performance gains in Xenix
when they switched to SVR3 in order to meet the SVID compliance
CLIN's on AFCAC 451 and Desktop III (I was there for the bidding
process on those contracts as a subcontracted company with a
product for bundling to satisfy some unrelated CLIN's). ODT
was strangled by SCO, not SCO's competition in the desktop
market, or the inherent inpenetrability of the desktop market
itself. They underestimated the time required for hardware
to speed up and thus speed their software. It was a risk
cut too close to the edge of the performance balloon. ODT's
failures make no commentary on the desktop market as a whole.
You take risks, and sometimes you pay dearly for the attempt.
ODT was "one of thsoe times".
] Oh, I'm not. The UNIX industry's problem was never one of
] discouragement from lack of success, and I was only citing some
] examples of how other attempts had gone south. No, the UNIX
] industry's problem was that they never even could agree on which
] direction to point the rocket, much less how to build one, and a
] jury-rigged and unfinished prototype sat on the launching pad for a
] decade while groups of white coated engineers rolled around on the
] grass, pulling one another's hair and screaming "The Moon?! NO, NO,
] Mars you idiot! The rocket's going to Mars or I'm outta here! Mars?!
] Venus, you utter moron! That's where the women are!"
A cute analogy, but hardly apt. You might as well claim the
"8088 OS industry" to be a single lump, and claim it never got
anywhere because Microsoft is successful and Digital Research
isn't.
There is no intrinsic barrier to a single competitor taking over
the market; the nature of the universe does not impose such a
limitation. NeXT failed because of technical errors and adherence
to the "proprietary hardware, proprietary OS" philosophy that was
so successful for Jobs at Apple. He was attempting "formula
innovation", and it failed because Apple was in the "lucky break"
category for Jobs, the same as DOS was for Gates. Apple lucked
out by getting their foot in the door before the IBM PC was
a usable machine. They haven't had more than their lower leg
inside the door since. Now they are relaxing (not dropping)
the proprietary hardware requirement -- saying "Telegram!" instead
of "Landshark!".
Gates would have been just as unsuccessful at introducing another
product based on mistaking his DOS success for a successful formula
(it's only fantastic effort on the post-facto bridge product
Windows 95, and NT's positioning as a NetWare and UNIX competitor
that has kept NT from falling down that slope).
In any case I agree with Mary. Opportunity exists, even if the
free (or even the commercial) UNIX implementations refuse to
recognize it as such.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.