The last contact I had with microwave data transmission, the engineers had big plans (regrettably never acted upon) to put a turkey on a strong post, and put this in front of the transmitter.
Expectations were that this could, quite quickly, result in a hot and tasty bird, even in the cool temperatures of Ottawa autumn.
I suspect the station manager nixed the idea; if it interrupted Max Keeping doing the news, there would doubtless be thousands of complaints...
Certainly the emergence of these systems, and you missed FluxOS/OSKit, is helpful to experimentation.
Unfortunately, I'm not sure it's as simple as some people going out and installing Plan 9, and seeing about porting Perl and Python and GNOME over.
To the contrary, actually developing new things means taking these systems, perhaps trying them out to see what insights fall out of them, and then developing further systems.
I guess I'd argue that the result of the availability of these systems is that of improved system diversity, and not necessarily the creation of new abstractions.
As for the "everything a file" notion, I suspect that if it had taken off in the early '80s, we might have a windowing system now that could be manipulated as a filesystem. Possibly a mite slower than X, but doubtless rather powerful, and easier to customize...
If you're interested in seeing anything "new" come along, I'd think you need to research the systems yourself.
I'm not trying to be unkind in that; explaining in a manner more useful than a drive-by flaming (that one's like UNIX; that one's not; that one is...) just won't do justice to them. Even the most "UNIX-like" provide some interesting extensions.
As for the quote, it's a quote. If you want to change it, you'll have to take it up with Henry Spencer. And it risks this strange thing known as historical revisionism.
(Comments about seemingly squandered talent elided...)
So where is the beef? Did they buy up the talent to do something good with it or simply to neutralize possibly dangerous competition? In general MS ticks me off because all that wealth is being used for so very little to really advance the state of the programming art.
I think there's likely a bit of both.
If Microsoft could turn the high-powered talent into products to make Gates a trillionaire, that would be a "good thing" (from his perspective, at least). And if Microsoft can deny others from benefiting from their talent, thus preserving the "hegemony," that is worth a lot too, at least to them.
The notion of "Everything A File" is something that Linux doesn't do.
Network interfaces are not files
While /proc provides access to pieces of processes as if they were files, that's largely read-only
Graphical device drivers don't provide a file-oriented abstraction
And there are probably some other things here.
I agree that introducing more better asynch processing would be a Good Thing; that doesn't forcibly mean moving to a different OS, when there are such options as:
CORBA Messaging Service
Message Queueing systems like MQSeries
Isect
I guess the point here is that if it is an effective strategy to add an additional interface to UNIX, then that's likely to be more productive than starting from scratch.
I disagree somewhat that C++ has provided substantial improvement (I could disagree more strongly, but will avoid flame wars on this!), as it has the problem that there is no ABI definition for it. I agree that moving to a different language, providing additional abstractions, is a direction towards innovation.
The problem, as I see it, is that, if you use C++ (or C), what you've got is a hammer, and everything looks like a thumb.
I'd rather see an attempt to build those "bigger and better applications" atop more dynamic languages, whether:
Lisp (or variants thereof)
Modula 3
ML (or variants thereof)
I've been doing some CORBA programming, primarily targeted at the C mapping. It is a quite horrible mapping; I'm prototyping in Python, and finding that works generally acceptably, and the mapping is vastly cleaner to work with. I expect the same would be true for Lisp, Scheme, and ML mappings, all of which considerably simplify the frightening amount of effort surrounding memory management that both C and C++ thrust upon the gentle programmer.
I'm not resisting "non-UNIX" things for the sake of them not being UNIX. Your conclusion that I am promoting "doctrinaire orthodoxy" comes from only half-reading the signature.
The point of the signature is that if you don't know the "orthodox," you are unlikely to do anything better than to merely replicate many of its features, badly.
It is also pretty fair to say that:
Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. -- Philip Greenspun
I think there should be a richer set of systems software research going on; people should be trying out EROS. People should be trying out And Hurd.
There should be work going on to provide OS environments supporting:
Persistent data structures
Garbage collected operating environments
Filesystems with semantics going beyond the UNIX "bags of bytes."
Security management using capabilities
Some of them will surely fail, and that's OK. Some of them may succeed, and that's a good thing.
One of the steps to allow people to actually learn from getting into system designs is to actually understand the systems that have come before.
In that light, it is not doctrinaire orthodoxy to consider that...
There is certainly value and merit in having made UNIX more accessible to "mere mortals."
But that isn't systems research.
Pike is observing that there isn't effort going into finding the abstractions and combinations thereof that can provide systems that might be downright better than UNIX.
Making Linux more "user friendly" may be a worthy enough goal, but that falls into the category of "Development," not "Research."
Linux is not a particularly good example of innovation; while there are some interesting bits of social innovation, there isn't all that much that isn't either a replication of what already existed, or a "tuning" of functionality.
ReiserFS may be pretty cool stuff, but it hasn't led to really new things. There is the offer that it may allow constructing data structures reasonably efficiently via "hordes of tiny files," but nobody is really using that yet, and the "research" side of that is already reasonably well-understood.
For there to be real research out of something like ReiserFS would require that people start studying different ways of constructing (say) DBMSes by using the abstractions provided by the new FS.
It isn't really systems research for someone to construct a Linux emulation system to run atop EROS; what would be innovative would be to see what kinds of cool things that may have nothing to do with UNIX as we know it can be done with it.
The problem that he doesn't comment on, which seems to be an important flip side to the notion that Microsoft is a source of innovation, is that, during the 1990s, Microsoft did an impressive job of buying up top researchers, virtually closing down major systems software research groups:
Hiring David Cutler and other VMS folk eliminated much of Digital's OS efforts
Hiring Mach folk, notably Rich Rashid, essentially eliminated CMU and IBM's Mach-related OS efforts
Similar "pulls" have taken place with databases ( Paul Larson ), compilers (folks who worked on AST Toolkit ), amongst others
If people started doing some substantial work on exploring how to powerfully connect applications together using CORBA, that could represent some new work; unfortunately, the tools are still maturing, and the mappings to C and C++ kind of suck, at least for the purposes of generating dynamic applications.
Remember, Pike's criticisms aren't based on some vague notion that Linux is useless or bad; they are based on the notion that it's not particularly innovative, from a systems software research perspective.
If 90% of your effort represents dealing with the same old ordinary UNIX stuff, that would be largely familar to a UNIX hacker of the 1970s, then whatever you're doing can't be more than 10% innovative. Note his comment that around 90% of the effort in Plan 9, which was one of the more innovative systems of the last decade, represented efforts to honor external standards. That's a problem.
If you look at the number of times the word "Open" is used, in different contexts, and with substantially different meanings, on the OpenMotif web pages, it's quite blatant that there's a big spin job going on.
They use the word "open" just so many times, and in association with the term "Open Source," that an uncareful reader could draw the conclusion that they are producing something that is, in fact "OpenSource."
Fortunately, they do acknowledge on the page that this isn't the case, and even indicate in what ways OpenMotif does not conform.
The blizzard of uses of "Open" for something that isn't is nonetheless richly amusing. (I mentioned this to RMS, and he agreed that it was amusing.)
Apparently quite a few companies have spent quite a lot of money on Motif development and they'd like to see that investment continue to be worth something. If everyone universally starts writing GTK or QT apps, Motif will lose its value.
The problem is that "value," in this situation, is a distinctly ambiguous thing.
Are we talking about the value of the cash flows from selling Motif license?
If so, OpenMotif diminishes this, and the only way they'd be likely to be able to improve the situation would be if something like BX-Pro was readily available for free, thus encouraging people to use and pay for licenses for Motif.
That's not happening, and I don't think the value comes in increased Motif licensing fees.
Are we talking about the value of license fees from existing software that uses Motif?
If so, then the "OpenMotif" strategy makes it easier to deploy that software more widely, particularly on Linux/BSD systems.
I think this is the actual merit to OpenMotif, by the way.
Note that the software that gets deployed as a result is likely not "free software," and that TOG and its sponsors thus couldn't care less what RMS says.
Another possibility is that the companies want to produce more new Motif software.
I'm really not sure where the value lies in that case; perhaps others can theorize more usefully.
ReiserFS was proposed to go into 2.3.x a while ago; it was held off then because it didn't "play well enough" with VFS. VFS then went into flux, as Alexander Viro was making fairly extensive changes.
The understanding then was that if the code audit (against VFS) went well, ReiserFS might be ready to go in.
Dust from the VFS work, from both the Viro and ReiserFS perspectives, seems to have settled, which would now permit Linus to evaluate whether or not this is the time for ReiserFS to go in.
Unfortunately, Linus is "out" for three weeks. (Vacation, I think? See last week's LWN...)
And as Alan Cox has observed, "breaking the usual rule" is Linus' prerogative, not Alan's.
Hans Reiser has observed, and perhaps too-loudly-commented, that there seems to be a correlation between:
People being associated with RHAT (like Alan Cox and Stephen Tweedie) and seeming to oppose ReiserFS inclusion, and
People being associated with SuSE, and supporting ReiserFS inclusion.
Unfortunately, if he saysSmells like Red Hat Conspiracy! enough times, it could irritate people enough to make them stand steadfastly against having a "conspiracy theorist" in their midst, and create, if nothing else, a conspiracy against him. Which would be pretty counterproductive on all parts...
At this time of year, Victoria "suffers" from the "Boy, they've got a LOT of flowers!" problem.
Not great for the hyper-allergenic.
And adding 20K people to the island would still be a rather costly process. They'd probably need an army of 1000 immigration lawyers to handle immigration...
Mind you, they'd be able to stock Nanaimo bars and avoid US drafts, which might make it all worthwhile!
I considered a move to Vancouver a few years ago; negatives included:
Very high cost of living
Notably including the cost of real estate. Perhaps not quite as bad as Silly Valley, but real estate prices got bid up by folks from Hong Kong that were concerned about having a haven from the Communists.
Heavy traffic.
Decent locations to work tend to be in the downtown, and access is controlled by about half a dozen bridges. Not exactly a good thing for commute times.
Throw an extra 20,000 people into the mix, and you'll see the traffic get worse, as well as watching a nice real estate price "bump" up, as something around $10B gets spent on real estate.
The choices are limited; MSFT would need a full-service airport nearby, which, in BC, forces them to try to stay near Richmond.
And remember, Gates loses, in such a move, his massive advantage, namely a state legal system that he apparently understands quite intimately as a result of growing up in a "legally oriented" family. BC law is not the same as Washington law, and that is likely to prove to be a jarring problem.
Of course, that provides another cost issue; MSFT would incur the costs of creating a sizable new "law stable" to deal with the local regulations.
Most entertainingly, this comes along with the demerit that a bunch of the former MSFT lawyers get discarded due to not being "Canadian-law-compliant."
Those lawyers are going to be none too happy about the change, and remember, they're lawyers. They're likely to sue Microsoft for whatever they can, and mutter things about "wrongful dismissal."
With the other threads around on the cost of living in Silicon Valley, I don't think it's too likely that there would be many California-based employees making a mere $50K.
And remember that the $80K salary that brings them up to the "poverty line" isn't the only expense that the company has. The company gets to pay:
Payroll taxes of one sort or another
Medical benefits, Dental Subsidies
Company costs for 401(k)
Whatever other "HR stuff" gets thrown in the mix
Rent on the real estate that the individual occupies
The cost of the PC at programmer's desk
The costs of adding programmer to LAN (running cabling and such)
The latter items may not be big ticket items, but it all adds up. I would find it unshocking if, to the $90K required to attract the staff member, there would be another $90K per year of costs to "house and service" the employee.
It's not obvious that nuking an employee will instantly save all of these costs, but I'd think it quite realistic that each employee costs well over $100K/annum in the California market...
Functional languages do have some attractive properties, as they behave in quite regular ways, to the point of being "mathematically predictable." (At least, until it comes time to take out the trash... )
Unfortunately, notable ones like ML and Haskell head very quickly into the arcania of type theory, which may be a bit more math than you want to push at youngsters that are still working on getting used to the notion of abstract ideas.
In contrast, the arcaneness of "pointer twiddling" in the C descendants is rather nasty.
Contrast with the arcania of "program structure" in Pascal, where a single semicolon out of place causes great contortions...
Lisp-like systems have irritating quantities of parentheses. (At least, for the first month that you use Lisp...)
Which all goes to say that all the languages out there have some strengths and some weaknesses.
C++ and Java are the "obvious" choices, even to illiterate Pointy-Haired Bosses, but unfortunately have a need for considerable runtime systems, particularly Java. A JVM requires a memory manager, which leaves you having to lift yourself by your own bootstraps if you write the JVM in Java, and thereby require a JVM and a memory manager, which leaves you recursing infinitely...
Or perhaps Oberon, which has been used to construct several OS-like environments.
Or perhaps even Eiffel, whose Design By Contract approach makes claims that C++ can provide anything describable as rock solid look very silly.
Based on the number of language compilers being built using ML, I'd think it to perhaps be a candidate. The ability to do heavy-duty static type inference would, not unlike with Eiffel, make claims of C++ being "rock solid" look pretty sad.
Yes, these languages don't have syntax that slavishly resembles C. But it's not as if the actual semantics of C++ or Java are actually that much like C...
The problem that there always was with Alpha, at least for "home" purposes, is that it never had the population of software to "power" it.
Consider:
Microsoft never ported MS Office to Alpha.
On Linux, there is a severe paucity of "commercial" applications for Alpha, and some of the critical applications for "desktop" use are not available.
Notably, Netscape is not readily available. (I know that the Digital UNIX version can be hacked into submission, but it is not an easy rpm -i netscape.rpm away...)
On the server side, Oracle for Linux is not available. Ditto for Informix, Sybase, DB/2,...
More critically, Linux/Alpha is a considerably more "brittle" platform than Linux/IA-32.
Linux may not be the rats-nest of spectacularly nonportable software that Windows NT is, but getting things like KDE, GNOME, GIMP, and such has been a fairly slow process.
Hardware compatibility lists are similarly "brittle."
I've tried running the Diamond Rio package, rio on my Alpha box; it gets quite confused, probably due to some 32-bit-ism in the "driver."
More critical is the paucity of graphics cards supported by XFree86 on Alpha. It is probably similar for other 64 bit platforms; you're restricted to whatever there are "open" drivers for, and there are some cards (Cirrus comes to mind) that have architectures that are distinctly unfriendly to 64 bit operations.
All of this adds up to Alpha not being a particularly consumer-friendly platform. People that "just want it to work" will find it somewhat challenging in this regard.
This is presently the case for Linux/Alpha; it was the case for Windows NT/Alpha.
The same will likely be true for IA-64, for a goodly while, by the way. The pains that Alpha has had may help IA-64 porting efforts to be less painful, but what "cramps" persist are likely to be irritants to adopters of IA-64.
In short, I don't think this was a likely niche, except amongst "daft hobbyists," which doesn't represent all that "nice" a niche...
I certainly agree that SPARC may not be the best choice for CPU-intensive task. That's basically what I said; Sun's strength is with I/O-bound systems.
Getting into issues of RISC versus CISC gets us away from the point.
The point is that those that are preferring Sun systems to Intel-based systems today are doing so not out of being focused on how much stronger SPARC used to be for CPU-intensive processes, but rather (most likely) because they've got I/O-bound processes.
The result is that the announcement doesn't scare Sun:
Those that used Sun for I/O-intense processing see nothing in this announcement that would cause them to prefer Intel to Sun.
Those that had CPU-intensive processes weren't running Sun, and thus the preference might involve them moving from SGI/MIPS to SGI/Intel, or from Compaq/Alpha to "something Intel."
But as there weren't Origin/Crays running SPARCs (I don't think there...), while this may represent a threat to MIPS or Alpha, it's not particularly one to SPARC.
Overall point: The article suggests that the threat was to Sun. A "threat tree" shows that this is not strongly the case.
Intel may want everyone to believe that this release will be heavily injurious to Sun. If people believe that, it will thereby become true.
But it's not necessarily the truth.
The truth is that for a whole lot of the applications for which people are installing big UltraSPARC boxes, the applications are not CPU-bound, but rather I/O bound.
DBMSes are dependent on having big memory caches to improve performance;
DBMS applications need arrays of big, fast disks, with hefty cacheing.
Having a better, faster Xeon Pentium III processor doesn't help with either of these things.
What helps with such applications are:
Faster disk drives.
Which Seagate and Quantum and IBM are responsible for...
Faster RAID controllers.
Think Adaptec, maybehaps?
Huge memory spaces.
Which means more than the 8GB that appears to be supported at this point.
The relevant thing from Intel would be to see vastly better I2O controllers. THAT is what would fill Sun's heart with fear...
... Is that it is by no means the first term to "lay claim" to the word Open.
The Open Group recently released OpenMotif, with mention of "Open Source," and even the Raymond/Perens/Debian definition thereof. As well as mentioning that
By the way, OpenMotif
isn't Open Source.
The number of occurances of the word "Open" in the press release should be a good tip-off that it's marketing-speak time.
OpenVMS, which hearkens from the days of "Open Systems," is one of the cases of there being a fiction of openness. "Open Systems" are ones where the APIs are disclosed. And generally this means using some UNIX variation or some simulation thereof.
In the case of OpenVMS, they provide a POSIX-compatible API, as well as most of the components defined as part of the UNIX95 specification. You can pretend it's UNIX, if you hold your nose. (VMS aficionados would say the same thing, but mean something else...:-) )
With OpenVMS, you can probably compile some POSIX C code, and perhaps run some UNIX shell scripts. That's what "Open" means, in this case.
You decidedly don't get source code to the system.
What appears to have happened is that Apple lost many of the developers of the Newton, laid off some more, and then (if rumor had it correct) lost a lot of the development notes and such when the remaining bits of the development group moved from one building to another.
Throw in the politics that Steve Jobs came back, and really didn't want anything that wasn't MacOS, and it pretty much turns into a situation of having no way of being able to support the product.
You might find some Newtons out there; there may be some useful things to learn from it. Practically speaking, it's now more a curiosity than anything important. Which is fairly regrettable...
Slashdot Mirror
Expectations were that this could, quite quickly, result in a hot and tasty bird, even in the cool temperatures of Ottawa autumn.
I suspect the station manager nixed the idea; if it interrupted Max Keeping doing the news, there would doubtless be thousands of complaints...
Unfortunately, I'm not sure it's as simple as some people going out and installing Plan 9, and seeing about porting Perl and Python and GNOME over.
To the contrary, actually developing new things means taking these systems, perhaps trying them out to see what insights fall out of them, and then developing further systems.
I guess I'd argue that the result of the availability of these systems is that of improved system diversity, and not necessarily the creation of new abstractions.
As for the "everything a file" notion, I suspect that if it had taken off in the early '80s, we might have a windowing system now that could be manipulated as a filesystem. Possibly a mite slower than X, but doubtless rather powerful, and easier to customize...
I'm not trying to be unkind in that; explaining in a manner more useful than a drive-by flaming (that one's like UNIX; that one's not; that one is...) just won't do justice to them. Even the most "UNIX-like" provide some interesting extensions.
As for the quote, it's a quote. If you want to change it, you'll have to take it up with Henry Spencer. And it risks this strange thing known as historical revisionism.
Things people should be trying out include:
- VSTa
- Hurd
- MIT Exokernel
- SpinOS
- OSKit
- EROS
- Some variation on Wirth's Oberon systems
Several of these are pretty UNIX-like, albeit taking some extra "twists," while others are distinctly not like UNIX.Even if you look at these, and go back to a UNIX-like system, there is benefit to seeing the extra abstractions they offer.
(Comments about seemingly squandered talent elided...)
I think there's likely a bit of both.
If Microsoft could turn the high-powered talent into products to make Gates a trillionaire, that would be a "good thing" (from his perspective, at least). And if Microsoft can deny others from benefiting from their talent, thus preserving the "hegemony," that is worth a lot too, at least to them.
- Network interfaces are not files
- While
/proc provides access to pieces of processes as if they were files, that's largely read-only - Graphical device drivers don't provide a file-oriented abstraction
And there are probably some other things here.I agree that introducing more better asynch processing would be a Good Thing; that doesn't forcibly mean moving to a different OS, when there are such options as:
- CORBA Messaging Service
- Message Queueing systems like MQSeries
- Isect
I guess the point here is that if it is an effective strategy to add an additional interface to UNIX, then that's likely to be more productive than starting from scratch.I disagree somewhat that C++ has provided substantial improvement (I could disagree more strongly, but will avoid flame wars on this!), as it has the problem that there is no ABI definition for it. I agree that moving to a different language, providing additional abstractions, is a direction towards innovation.
The problem, as I see it, is that, if you use C++ (or C), what you've got is a hammer, and everything looks like a thumb.
I'd rather see an attempt to build those "bigger and better applications" atop more dynamic languages, whether:
- Lisp (or variants thereof)
- Modula 3
- ML (or variants thereof)
I've been doing some CORBA programming, primarily targeted at the C mapping. It is a quite horrible mapping; I'm prototyping in Python, and finding that works generally acceptably, and the mapping is vastly cleaner to work with. I expect the same would be true for Lisp, Scheme, and ML mappings, all of which considerably simplify the frightening amount of effort surrounding memory management that both C and C++ thrust upon the gentle programmer.I'm not resisting "non-UNIX" things for the sake of them not being UNIX. Your conclusion that I am promoting "doctrinaire orthodoxy" comes from only half-reading the signature.
The point of the signature is that if you don't know the "orthodox," you are unlikely to do anything better than to merely replicate many of its features, badly.
It is also pretty fair to say that:
I think there should be a richer set of systems software research going on; people should be trying out EROS. People should be trying out And Hurd.
There should be work going on to provide OS environments supporting:
Some of them will surely fail, and that's OK. Some of them may succeed, and that's a good thing.
One of the steps to allow people to actually learn from getting into system designs is to actually understand the systems that have come before.
In that light, it is not doctrinaire orthodoxy to consider that...
But that isn't systems research.
Pike is observing that there isn't effort going into finding the abstractions and combinations thereof that can provide systems that might be downright better than UNIX.
Making Linux more "user friendly" may be a worthy enough goal, but that falls into the category of "Development," not "Research."
ReiserFS may be pretty cool stuff, but it hasn't led to really new things. There is the offer that it may allow constructing data structures reasonably efficiently via "hordes of tiny files," but nobody is really using that yet, and the "research" side of that is already reasonably well-understood.
For there to be real research out of something like ReiserFS would require that people start studying different ways of constructing (say) DBMSes by using the abstractions provided by the new FS.
It isn't really systems research for someone to construct a Linux emulation system to run atop EROS; what would be innovative would be to see what kinds of cool things that may have nothing to do with UNIX as we know it can be done with it.
The problem that he doesn't comment on, which seems to be an important flip side to the notion that Microsoft is a source of innovation, is that, during the 1990s, Microsoft did an impressive job of buying up top researchers, virtually closing down major systems software research groups:
If people started doing some substantial work on exploring how to powerfully connect applications together using CORBA, that could represent some new work; unfortunately, the tools are still maturing, and the mappings to C and C++ kind of suck, at least for the purposes of generating dynamic applications.
Remember, Pike's criticisms aren't based on some vague notion that Linux is useless or bad; they are based on the notion that it's not particularly innovative, from a systems software research perspective.
If 90% of your effort represents dealing with the same old ordinary UNIX stuff, that would be largely familar to a UNIX hacker of the 1970s, then whatever you're doing can't be more than 10% innovative. Note his comment that around 90% of the effort in Plan 9, which was one of the more innovative systems of the last decade, represented efforts to honor external standards. That's a problem.
They use the word "open" just so many times, and in association with the term "Open Source," that an uncareful reader could draw the conclusion that they are producing something that is, in fact "OpenSource."
Fortunately, they do acknowledge on the page that this isn't the case, and even indicate in what ways OpenMotif does not conform.
The blizzard of uses of "Open" for something that isn't is nonetheless richly amusing. (I mentioned this to RMS, and he agreed that it was amusing.)
If so, OpenMotif diminishes this, and the only way they'd be likely to be able to improve the situation would be if something like BX-Pro was readily available for free, thus encouraging people to use and pay for licenses for Motif.
That's not happening, and I don't think the value comes in increased Motif licensing fees.
If so, then the "OpenMotif" strategy makes it easier to deploy that software more widely, particularly on Linux/BSD systems.
I think this is the actual merit to OpenMotif, by the way.
Note that the software that gets deployed as a result is likely not "free software," and that TOG and its sponsors thus couldn't care less what RMS says.
I'm really not sure where the value lies in that case; perhaps others can theorize more usefully.
The understanding then was that if the code audit (against VFS) went well, ReiserFS might be ready to go in.
Dust from the VFS work, from both the Viro and ReiserFS perspectives, seems to have settled, which would now permit Linus to evaluate whether or not this is the time for ReiserFS to go in.
Unfortunately, Linus is "out" for three weeks. (Vacation, I think? See last week's LWN...)
And as Alan Cox has observed, "breaking the usual rule" is Linus' prerogative, not Alan's.
Hans Reiser has observed, and perhaps too-loudly-commented, that there seems to be a correlation between:
- People being associated with RHAT (like Alan Cox and Stephen Tweedie) and seeming to oppose ReiserFS inclusion, and
- People being associated with SuSE, and supporting ReiserFS inclusion.
Unfortunately, if he says Smells like Red Hat Conspiracy! enough times, it could irritate people enough to make them stand steadfastly against having a "conspiracy theorist" in their midst, and create, if nothing else, a conspiracy against him. Which would be pretty counterproductive on all parts...Not great for the hyper-allergenic.
And adding 20K people to the island would still be a rather costly process. They'd probably need an army of 1000 immigration lawyers to handle immigration...
Mind you, they'd be able to stock Nanaimo bars and avoid US drafts, which might make it all worthwhile!
Notably including the cost of real estate. Perhaps not quite as bad as Silly Valley, but real estate prices got bid up by folks from Hong Kong that were concerned about having a haven from the Communists.
Decent locations to work tend to be in the downtown, and access is controlled by about half a dozen bridges. Not exactly a good thing for commute times.
Throw an extra 20,000 people into the mix, and you'll see the traffic get worse, as well as watching a nice real estate price "bump" up, as something around $10B gets spent on real estate.
The choices are limited; MSFT would need a full-service airport nearby, which, in BC, forces them to try to stay near Richmond.
And remember, Gates loses, in such a move, his massive advantage, namely a state legal system that he apparently understands quite intimately as a result of growing up in a "legally oriented" family. BC law is not the same as Washington law, and that is likely to prove to be a jarring problem.
Of course, that provides another cost issue; MSFT would incur the costs of creating a sizable new "law stable" to deal with the local regulations.
Most entertainingly, this comes along with the demerit that a bunch of the former MSFT lawyers get discarded due to not being "Canadian-law-compliant."
Those lawyers are going to be none too happy about the change, and remember, they're lawyers. They're likely to sue Microsoft for whatever they can, and mutter things about "wrongful dismissal."
And remember that the $80K salary that brings them up to the "poverty line" isn't the only expense that the company has. The company gets to pay:
- Payroll taxes of one sort or another
- Medical benefits, Dental Subsidies
- Company costs for 401(k)
- Whatever other "HR stuff" gets thrown in the mix
- Rent on the real estate that the individual occupies
- The cost of the PC at programmer's desk
- The costs of adding programmer to LAN (running cabling and such)
The latter items may not be big ticket items, but it all adds up. I would find it unshocking if, to the $90K required to attract the staff member, there would be another $90K per year of costs to "house and service" the employee.It's not obvious that nuking an employee will instantly save all of these costs, but I'd think it quite realistic that each employee costs well over $100K/annum in the California market...
Unfortunately, notable ones like ML and Haskell head very quickly into the arcania of type theory, which may be a bit more math than you want to push at youngsters that are still working on getting used to the notion of abstract ideas.
In contrast, the arcaneness of "pointer twiddling" in the C descendants is rather nasty.
Contrast with the arcania of "program structure" in Pascal, where a single semicolon out of place causes great contortions...
Lisp-like systems have irritating quantities of parentheses. (At least, for the first month that you use Lisp...)
Which all goes to say that all the languages out there have some strengths and some weaknesses.
Not involving huge quantities of "line noise" or other such punctuation
More reasonable alternatives would include:
Yes, these languages don't have syntax that slavishly resembles C. But it's not as if the actual semantics of C++ or Java are actually that much like C...
Consider:
Notably, Netscape is not readily available. (I know that the Digital UNIX version can be hacked into submission, but it is not an easy rpm -i netscape.rpm away...)
Linux may not be the rats-nest of spectacularly nonportable software that Windows NT is, but getting things like KDE, GNOME, GIMP, and such has been a fairly slow process.
I've tried running the Diamond Rio package, rio on my Alpha box; it gets quite confused, probably due to some 32-bit-ism in the "driver."
More critical is the paucity of graphics cards supported by XFree86 on Alpha. It is probably similar for other 64 bit platforms; you're restricted to whatever there are "open" drivers for, and there are some cards (Cirrus comes to mind) that have architectures that are distinctly unfriendly to 64 bit operations.
All of this adds up to Alpha not being a particularly consumer-friendly platform. People that "just want it to work" will find it somewhat challenging in this regard.
This is presently the case for Linux/Alpha; it was the case for Windows NT/Alpha.
The same will likely be true for IA-64, for a goodly while, by the way. The pains that Alpha has had may help IA-64 porting efforts to be less painful, but what "cramps" persist are likely to be irritants to adopters of IA-64.
In short, I don't think this was a likely niche, except amongst "daft hobbyists," which doesn't represent all that "nice" a niche...
Getting into issues of RISC versus CISC gets us away from the point.
The point is that those that are preferring Sun systems to Intel-based systems today are doing so not out of being focused on how much stronger SPARC used to be for CPU-intensive processes, but rather (most likely) because they've got I/O-bound processes.
The result is that the announcement doesn't scare Sun:
But as there weren't Origin/Crays running SPARCs (I don't think there...), while this may represent a threat to MIPS or Alpha, it's not particularly one to SPARC.
Overall point: The article suggests that the threat was to Sun. A "threat tree" shows that this is not strongly the case.
But it's not necessarily the truth.
The truth is that for a whole lot of the applications for which people are installing big UltraSPARC boxes, the applications are not CPU-bound, but rather I/O bound.
Having a better, faster Xeon Pentium III processor doesn't help with either of these things.
What helps with such applications are:
Which Seagate and Quantum and IBM are responsible for...
Think Adaptec, maybehaps?
Which means more than the 8GB that appears to be supported at this point.
The Open Group recently released OpenMotif, with mention of "Open Source," and even the Raymond/Perens/Debian definition thereof. As well as mentioning that
The number of occurances of the word "Open" in the press release should be a good tip-off that it's marketing-speak time.
OpenVMS, which hearkens from the days of "Open Systems," is one of the cases of there being a fiction of openness. "Open Systems" are ones where the APIs are disclosed. And generally this means using some UNIX variation or some simulation thereof.
In the case of OpenVMS, they provide a POSIX-compatible API, as well as most of the components defined as part of the UNIX95 specification. You can pretend it's UNIX, if you hold your nose. (VMS aficionados would say the same thing, but mean something else... :-) )
With OpenVMS, you can probably compile some POSIX C code, and perhaps run some UNIX shell scripts. That's what "Open" means, in this case.
You decidedly don't get source code to the system.
Throw in the politics that Steve Jobs came back, and really didn't want anything that wasn't MacOS, and it pretty much turns into a situation of having no way of being able to support the product.
You might find some Newtons out there; there may be some useful things to learn from it. Practically speaking, it's now more a curiosity than anything important. Which is fairly regrettable...
In contrast, the point of Transmeta is to design a family of microprocessors. They don't build the boxes to put them in.