I like Mark, but he made some terrible hubristic mistakes. Most notably, telling the press that Netscape was going to be the next Microsoft. And that with Java, Windows was just a set of poorly debugged device drivers. Great headlines, but just stupid. You don't poke a sleeping giant. You wait till you have your hand firmly around his nuts. Gates had the wisdom to do that with IBM.
--LinuxParanoid, (paranoid of Microsoft, not Linux, just to be clear)
I was initially suspicious that lawyer's son Bill Gates was being evasive in not distinguishing between the statements "640K of memory should be enough for anybody." and "No one involved in computers would ever say that a certain amount of memory is enough for all time." Well, nobody's saying you said "all time", Bill. But in Bill's defense, he also said "I did not say that", and one would hope that he's not being Clintonesque in word-niggling.
I did a little poking around to see if there was a more authoritative articulation of what the exact original quote supposedly was, and while I didn't find that, I found a better (and more recent) reference than that Katz Wired article.
Check out a fuller rebuttal including a long and moderately technical Gates email concerning the matter in this New Yorker article by James Fallows. It also touches on "dumb tech statements", the more general topic of this thread.
Eschewing the patent issue for a moment and focusing on the question of whether poetry consitutes artificial intelligence, the question is: whose intelligence?
I read Kurzweil's book, The Age of Spiritual Machines and he had various samples of computer poetry there. I remember thinking that one of them was stunningly good, at least to my taste.
But I also found myself wondering... how many (hundreds of? thousands of?) poems were discarded by humans in an attempt to find a couple good ones, and is this vaunted computer poetry really mostly a product of human selection from reams of pseudo-sensical word combinations? I never saw any disclosure or discussion of these sorts of factors in Kurzweil's writings. Keep your eye out for this.
I found the technical section of the Switch article didn't fully explain the encoding. After thinking that I should code up the RFC to figure it out (and perhaps gain a name for myself on CPAN), I found to my mixed delight that someone had already beaten me to it: IDNA::Punycode and Encode::Punycode.
I didn't get the audio... are those "agents" who are interrogating Balmer/Neo supposed to be CIO suit-wearing customers? The customers are the bad guys?
One subtle problem with online voting is that it's much easier for a third-party to coerce your vote and to check that you voted "correctly". The third-party (an employer, union official, local mob boss, etc) can "encourage" you to make sure you vote at an online facility where they are watching... and there goes the privacy of the polling place and the anonymity of the ballot box.
Of course, in earlier times this was recognized as an issue with absentee voting. The solution that traditional voting systems adopted was to allow the voter to vote in person later at a real polling place, and that vote, (presumably more free of coercion), would invalidate their earlier vote.
I wonder if CanVote provided a similar "vote override" option for Ontario citizens? A polling place vote should always override an alternative-mechanism vote. I hope in the move to online voting we don't lose the non-obvious protections that have been added to our current electoral system over time.
Two problems with oil substitutes:density and cost
on
The End of the Oil Age
·
· Score: 2, Interesting
I've done hobbiest-class research into the topic of oil substitutes and here are two oft-neglected issues to keep in mind:
1) Energy density. It's hard to improve upon oil/gasoline's energy-per-unit-volume with economical substitutes. Hydrogen fuel cells don't have nearly the energy density of gasoline. (Fuel cells tend to be far bulkier for this reason, or you can't travel as many miles with equivalent space.) I suspect consumers would accept a car with a smaller range; I dunno about other applications though. Technology and mass-production may drop fuel cell costs, but improving energy density takes some serious physics/chemistry.
2) Saudi Arabia (and other low-cost oil producers) have plenty of room to drop the price. Sure, it's not hard to see plenty of economical substitutes showing up at $30/barrel (today's price, historically well above average.) And even matching the long-term average price of oil at $15/barrel is conceivable. But the Saudis can produce oil at costs of $1-$2/barrel. Now I'm comparing end-prices to costs here which is a bit unfair (so add a 50% margin to $1-$2), but even if a energy substitute could produce power matching today's oil prices, it'd have to reduce in cost 30-fold in order for us to long-term wean ourselves completely off oil. And that's assuming the Saudi's don't get more efficient in the meantime. At least from an economic standpoint, ignoring costs of externalities like security/pollution.
So I see alternative fuel use increasing, but I don't see oil vanishing from the picture in my lifetime (or my kids'). Heck, I'd be delighted if we just cut our oil usage in half in my lifetime; that'd be a stunning success in my book.
I suspect the Saudi's are just talking down their influence for current political reasons.
--LP, probably posting a bit too late to get mod points
I used to read Steve Milunovich's research fairly regularly.
One of the advantages of reading Steve was that he did his own surveys of Fortune 100 (500?) CIOs, asking about budgets (ie future system vendor revenues) and various topics of the day (ERP deployments, etc). So I found his comments that Sun should make contrarian bets but "do so in ways palatable to conservative CIOs" interesting. Steve may have some unique insight into that.
What's a little odd to me about Steve's advice is the contradictions in it. At least based on the admittedly summary article linked here. On the one hand, he seems to advocate a "batten-down-the-hatches"-type strategy: cut R&D, dump SPARC (eventually), don't make waves, be more Linux friendly. And on the other hand he seems to say "make contrarian bets". It may be that Sun is just doomed due to volume economics (although in fairness, they have always been *way* more focused on that than every other Unix vendor in my past discussions with management I met in my past life), but the "batten-down-the-hatches" strategy seems more likely, not less likely to lead them down the "DEC, Data General, Compaq" path. Sure Sun needs to be shrewd and somewhat conservative in cutting excess spending. Maybe that *is* what they need to do to stabilize their stock a bit. But that isn't how they're going to avoid the 'computing graveyard'.
Although if you are doomed to the computing graveyard (something I thought was true of Sun in 1995 but Sun did stunningly well the following five years), it is true that the most prudent thing to do is spend your remaining strength as conservatively as possible. I don't have any easy answers myself for Sun. I can't fault Milunovich for trying, but the advice doesn't look particularly helpful to me.
"We're being as inclusive as we can", Gates said...
I.e. inclusive enough to give away 15% of the market to rivals and keep antitrust guys off our backs, but not inclusive enough to risk losing customers to any web services running on alternative OSes?
--LinuxParanoid, who doesn't yet believe Gates's philanthroipc altruism extends to other software companies
P.S. Note Gates's observation that "Standards are always a give-to-get bargain" and ask yourself "what does Gates think he is getting?" There are a variety of possible answers.
Pardon me, but a lot of you guys are missing the point of this comparator.
1) There are people out there with legit source licenses to SVR5 source trees. And not just Unix OEMs. Various people in large companies with SVR4/5 source licenses etc.
2) Such people cannot release the source code, and may (if paranoid of how they interpret 'derived works') not want to publish hashed MD5 codes of SVR5.
3) However, it should be possible for a legit SVR5 source licensee to publish openly a list of areas of code that are similar across trees, without that list being either A) a derived work, B) violating their NDAs (um, do check the fine print first though) and C) spending tons of their own, presumably expensive time, digging through stuff.
Then Linux advocates can then sift through the resulting large pieces of code and doublecheck/crosscheck the origins of it. At the very least, we'd have a public list of suspicious areas of Linux and could determine that certain parts are A) BSD-licensed, B) are verified as original by a known Linux coder, and C) don't fall into the above categories and remain 'suspicious'. This presumably is what ESR is referring to by "various persons will apply it in useful ways. Yes, I'm being deliberately vague and tantalizing". Let's say that its likely the percentages in A and B will be large.
Of course it's true that there could be code that this primitive tool doesn't catch. But SCO probably started their analysis by using tools like this also. Looking through millions lines of code by hand is no cakewalk, so one will inevitably start with code like this in such an investigation. (Unless one is concerned about one specific predetermined critical/sensitive piece of code.)
Oh, and the other thing about this tool that is nice IMHO? It demonstrates a "good faith" effort on the part of Linux advocates and coders to correct the problem -- despite the barriers raised by SCO (no code release except via NDA).
Finally, running this tool across a Linux and a BSD release should turn up some data that is both interesting and relevant for this dispute. I'm almost tempted to try that myself.
--LP
Did the RIAA get the 12-year-old's name? Doubtful.
on
RIAA Sues 12-Year Old Girl
·
· Score: 4, Insightful
Although it *does* beg the question: if a 12 year can't assume debt, then how exactly did they get her name in the first place?
I've not seen anyone confirm or deny the following scenario, but I was thinking about this question this morning.
I suspect the mom, who was likely the owner of the ISP account (billed to the mom's credit card) is the one who actually had her name on the suit since the RIAA got her name through subpoena'ing the ISP. But in a brilliant PR move, the mom is telling the press that the RIAA is suing her daughter (since the mom had nothing to do personally with the copying.)
This is the only scenario that makes logical sense to me, but I'd note that it is 100% speculation.
Three or four years ago, UnixWare was actually functionally superior to Linux
Clearly Linux was/is a superior webserver and has been for some time. Furthermore, if you were running a single-CPU standard-hardware PC and your app ran on Unix, it was on par or perhaps in some sense you can articulate, superior. (For my purposes 10 years ago, Linux was superior because of its price, although I would be somewhat hesitant to consider that a "functional" feature of Linux except in the broadest sense.)
By functionally superior, I mean in the high-end Unix sense. For example, UnixWare had pretty good support for 4-8 way SMP with finer-grained locking when Linux had locks around huge chunks of the kernel. UnixWare had extensive reliability features used more for big-iron systems: clustering features, journaled filesystems (ext3/reiser were in development and still too buggy for production) and the ability to hot-swap CPUs and other things that weren't available on Linux. Etc.
It's a rational move for them.
I agree with all the arguments you make here that JFS/XFS/RCU/NUMA are components, ie distinguishable/distinct and separable (although NUMA less so) from the originating SVR4/5 OS owned by SCO. Presuming there is no overlapping copyright claim, rationally they should not be considered as derivative in a legal sense imho. I wouldn't go so far as to say SCO's legal argument is *irrational,* but I would consider it tenuous and novel.
I was trying to make a distinction between a rational business strategy versus a rational legal argument. As an x86 Unix vendor, SCO has never had an adequate answer to Linux/BSD, and after five years of trying various things (be a high-end complementary product, embrace and resell Linux) their revenues continue to drop. In light of that, a tenuous legal argument is a rationally (note: not ethically) better business strategy than doing the same old thing trying to sell UnixWare/OpenServer. "Hmm, we can't get customers, but perhaps we can convince a judge/jury to give us money." For better or worse, I think the odds are much higher of SCO getting $100 million from a judge or jury or settlement than by getting $100 million in new x86 Unix customers. From this vantage point, perhaps the lawsuit was inevitable whatever the merits were.
If your point is that without a convincing legal argument, they don't have a strong business strategy, I'd also agree. Having your success dependent on a judge/jury is not a good place to me. It's not a strong strategy either way.
--LP
It's not MS targetting SGI, it really *is* SCO
on
SCO's Next Target: SGI?
·
· Score: 5, Interesting
You are right, but MS has already crushed SGI.
MS has obtained a cross-license to all SGI's graphics patents, and OpenGL is no longer a threat. A mild concern perhaps. MS buried their joint "Farenheit" high-level graphics API effort with SGI, killing it. MS has announced dropping support of OpenGL on future OSes. Development of OpenGL 2.0 is really the baby of 3Dlabs (or whoever bought them out; I forget), not SGI, which shows you how behind the curve SGI is on pushing OpenGL these days. OpenGL's survival depends more on John Carmack pushing IHVs to keep using it than SGI, and other than OpenGL, SGI has not presented MS with a platform threat.
MS may want to crush Linux and/or IBM, but SGI? Not even in the same ballpark.
The reason SCO is picking on SGI is because of NUMA.
SGI has been dumping their NUMA scalability crown jewels into Linux (unlike all other conventional Unix vendors who are keeping that stuff in their high-end proprietary OS+hardware combos) and this is a significant impediment to selling UnixWare as "the premier scalable x86 Unix". Off the shelf UnixWare supports up to 8 processors today and SCO made a stab at doing NUMA stuff once upon a time, but SGI's NUMA-Linux has tons more R&D behind it and is going 64-way.
Three or four years ago, UnixWare was actually functionally superior to Linux (I know, I know, hard to believe but it's true.) But any margin of superiority then has greatly diminished or been overtaken. This is a real problem if SCO can't keep up with the R&D dumped into Linux by the open source community plus IBM plus SGI, etc. So SCO has gone legal. It's a rational move for them. Their vacillating arguments and tenuously-novel notion of derivative works don't bode well for their long term success however.
--LP
Further confirmation SGI had IP concerns re: XFS
on
SCO's Next Target: SGI?
·
· Score: 4, Insightful
Six months after its announcement it would release XFS, IP issues were still a concern. A Slashdot thread refers to comments made by Dave McAllister, SGI's Directory of Technical Strategy in a (now-linkdead) article, saying:
"SGI will devolve elements of its proprietary software and operating system Irix, such as its XFS journalling file system,to Linux as soon as it clears the legal roadblocks surrounding the intellectual property.... 'As the code is cleaned, we will release it,' [McAllister] said."
That said, I'm at a loss to explain how SGI stuffed things like that ancient malloc.c into Linux. Perhaps things got sloppy or it was never noticed because someone had previously removed copyright notices? (Apparently this has been a problem at SCO as well, removing BSD license notices internally...)
You know, the ironic thing about this whole SCO uproar is that people have long bitched that the GPL was so viral... well look how viral the closed source SVR4/5 license apparently was!
--LP
P.S. A short history of XFS and Linux, Slashdot-style:
I wrote a paper on the subject of SGI donating XFS after interviewing someone there at the time they made their announcement (~May 20, 1999). I just looked up the paper and found the following quote:
"Currently, SGI is clearing the source code of any legal restrictions; it expects to be able to make the code openly available by the end of the summer. "
Ensuring they were free-and-clear to donate XFS under an open source license was *not* an afterthought for SGI. There was concern among all the major UNIX vendors of IP entanglement with Linux, and SGI was the first to openly pledge to donate a chunk of their core UNIX technology. (IBM donated some non-core stuff earlier, and core stuff like JFS later.)
SCO's claim that XFS or JFS are derivative works of SVR4/5 remains, to me, highly dubious.
Too bad for SGI, the last thing they need these days is lawsuits. SCO can't hope for a lot of money, but maybe they're hoping for weaker resistance?
I looked into this and skimmed the documentation. It didn't appear to have a way for me to make sure that the management-folks who bring in laptops every morning get updated. It seemed to be more oriented to updating desktops in the middle of the night (or in the middle of the day but that'd be a tad disruptive around here anyway.)
Is there something that lets me insure when the laptop users plugin to our network, they are asked/forced, first thing, to get the new updates? Maybe I missed it?
Your humble author suggests that SCO found themselves requiring a multithreaded web server, and as SCO UNIX is based on an ancient version of The UNIX spec it just couldn't cope;-).
Well, there's a smiley so I know you're kidding.
But there are also some inaccurate facts and presuppositions buried in those comments.
First, your comment appears to ignore SCO's ability to use SCO UnixWare. SCO has two UNIX products, SCO UnixWare, and SCO OpenServer. SCO OpenServer is a Xenix descendent that is singlethreaded and probably as you suggest, couldn't cope. This is what most of SCO's installed base uses, and yeah it's old cruddy technology. SCO UnixWare uses pretty-sophisticated SVR5 technology that is really the core SVR kernel descended from AT&T & Novell days. It's pretty slick functionally (imho), is quite multithreaded running on 8-way (and NUMA I believe) systems, and conforms to UNIX 95 (although not UNIX 98 or the new UNIX 03 tweaks.) SCO is really suing over technology and rights allegedly derived from UnixWare/SVR4-5, not the older OpenServer technology you'd find in 90% of SCO installations.
Second, having a multithreaded webserver that can cope has little or nothing to do with whether one conforms to the latest UNIX specs from the Open Group. But I know you probably know that and are just trying to toss that in there, right?
--LP, not a UnixWare fan, just trying to reduce misinformation on the subject of SCO UNIXes
Poor SCO pointy-haired-bosses... I can see it now (names omitted to protect the guilty):
-------------------
PHB1: "Hey PHB2, I'm putting together this PowerPoint. I suppose I should slap some code in there to make this suit look more legit." PHB2: "Yeah, good idea." (PHB2 goes to Etrade to dump a bit more stock) PHB1: "I've got this copied code the IPI [Intellectual Property Investigative --ed] Team passed on to me, but Legal says we can't release it." PHB2: "Yeah, $600 an hour to tell us we can't disclose it to the press and claim it's top-secret priceless intellectual property at the same time." PHB1: "No kidding." (pause) "You ever seen code like this?" PHB2: "Linux hippies. I dunno, it's all greek to me." PHB1: "Genius! What a brilliant idea, I'll show those hackers the code in Greek!" PHB2: "Hey, you're good..." (peck, peck, peck)
You all know that phone system conveys its own power so phones stay working when power is down.
But did you know that also hold true for DSL service?
It does in my area (north of NYC). Power has been down for seven hours, but I just hooked up my DSL modem through an extension cord to my car (which has an cig-lighter-to-AC-adapter) and DSL is working fine and that's how I'm posting this.
Oh, and my laptop is running off a battery which, using the above mechanism, I can recharge in my car as needed.
Quite handy. I'm not positive if this works for cable modems but I don't think so. I'd be curious if someone could confirm/deny that.
You want the former for weapons, the latter for commercial energy production.
(Although in the case of fuel substitutes for cars, both are actually quite important. No matter how much you improve the efficiency and cost of hydrogen or fuel cells, its hard to beat oil's energy density.)
Anyway, based on that article, it appears to me that it takes a heck of a lot of energy to make and "energize" the halfnium with protons (or eventually photons). A lot more than you get out when you eventually shoot the X-Ray in and get that 60-fold increase out. That 60-fold increase is just releasing energy you put in the substance gradually earlier. So it isn't necessarily energy efficient, just energy-dense. Of course, as they make the substance cheaper, that is a sign that they're improving the energy efficiency of the manufacturing process, so who knows how good they'll get at that. Clearly they have a long way to go in any case. Particle accelerators aren't cheap, either dollar-wise or energy-wise.
The effect of a nuclear-isomer explosion would be to release high-energy gamma rays capable of killing any living thing in the immediate area. It would cause little fallout compared to a fission explosion, but any undetonated isomer would be dispersed as small radioactive particles, making it a somewhat "dirty" bomb. This material could cause long-term health problems for anybody who breathed it in.
I'm wondering how big a problem this "dirty bomb characteristics" issue is. How much of the isomer really doesn't detonate (and why?) Is this a 1% of the substance doesn't detonate (decay suddenly when hit with an X-ray) problem or a 50% doesn't detonate? And if the amount of the material is small enough (e.g. a gram), perhaps this falls below injurious-in-practice threshholds? I.e. how close to conventional low-yield nuclear really is it?
OpenBSD is pretty stable. I currently have half a dozen systems running with an uptime of 50 days, and I've had 200+ days on multiple boxes. It goes down for major system maintenance and that's about it. I've used it for internet-facing webservers and for mailservers.
IBM got a special amendment to the contract stating that they owned any changes they made to AIX.
I hadn't heard this before. Are you sure it's true? It easily could be, but that brings up a point which you skipped. If IBM does own it's modifications to UNIX (but not Sequent's), how can SCO complain about contract violations relating to JFS?
RCU and some NUMA work came from Sequent, but JFS is pure IBM-developed code (AFAIK) dating back to the original release of AIX in 1991 or so. It was pioneering at the time if I recall correctly.
It's a nice piece of analysis. Someone could have done it 8 years ago when Java came out; the facts are not significantly different (The values are different of course but the ratios involved are pretty similar. I did some thinking along these lines back then, and then in 2000 when considering working for a "hot P2P company" that an old acquaintance of mine was running.)
My thinking went something like this: There are only a few, "niche" applications which need more compute power and which people pay for (distributed rendering, CFD, FEA, maybe a couple others). Maybe you could build that into a 10-30 million dollar business if you overcame a zillion obstacles but it didn't look like a billion or multi-billion dollar business. The applications for which people buy beefy servers, and which have a monetary payback, are mostly database applications. For those, you need to move the entire database near to the number-crunching PC, and that's not really feasible due to the cost of transporting Gigabytes of data or the unlikelihood that the PC's hard disk can store all the giga/terabytes of information potentially relevant for the computation. Not to mention the security problem.
And Jim Gray's analysis lays out in more precise economic terms why it doesn't make sense. I like how he even calculated the relative merits of a Beowulf-like cluster of PCs versus P2P which I never really analyzed (I lumped them together as basically similar.)
That said, has anybody even made a stab at designing or implementing a relational database with a P2P architecture? I know that there's Oracle Cluster Server, but I'm thinking of something more low-end and more distributed.
Slashdot Mirror
I like Mark, but he made some terrible hubristic mistakes. Most notably, telling the press that Netscape was going to be the next Microsoft. And that with Java, Windows was just a set of poorly debugged device drivers. Great headlines, but just stupid. You don't poke a sleeping giant. You wait till you have your hand firmly around his nuts. Gates had the wisdom to do that with IBM.
--LinuxParanoid, (paranoid of Microsoft, not Linux, just to be clear)
I was initially suspicious that lawyer's son Bill Gates was being evasive in not distinguishing between the statements "640K of memory should be enough for anybody." and "No one involved in computers would ever say that a certain amount of memory is enough for all time." Well, nobody's saying you said "all time", Bill. But in Bill's defense, he also said "I did not say that", and one would hope that he's not being Clintonesque in word-niggling.
I did a little poking around to see if there was a more authoritative articulation of what the exact original quote supposedly was, and while I didn't find that, I found a better (and more recent) reference than that Katz Wired article.
Check out a fuller rebuttal including a long and moderately technical Gates email concerning the matter in this New Yorker article by James Fallows. It also touches on "dumb tech statements", the more general topic of this thread.
--LP
Eschewing the patent issue for a moment and focusing on the question of whether poetry consitutes artificial intelligence, the question is: whose intelligence?
I read Kurzweil's book, The Age of Spiritual Machines and he had various samples of computer poetry there. I remember thinking that one of them was stunningly good, at least to my taste.
But I also found myself wondering... how many (hundreds of? thousands of?) poems were discarded by humans in an attempt to find a couple good ones, and is this vaunted computer poetry really mostly a product of human selection from reams of pseudo-sensical word combinations? I never saw any disclosure or discussion of these sorts of factors in Kurzweil's writings. Keep your eye out for this.
--LP
I found the technical section of the Switch article didn't fully explain the encoding. After thinking that I should code up the RFC to figure it out (and perhaps gain a name for myself on CPAN), I found to my mixed delight that someone had already beaten me to it: IDNA::Punycode and Encode::Punycode.
--LP
I didn't get the audio... are those "agents" who are interrogating Balmer/Neo supposed to be CIO suit-wearing customers? The customers are the bad guys?
Confused,
LP
One subtle problem with online voting is that it's much easier for a third-party to coerce your vote and to check that you voted "correctly". The third-party (an employer, union official, local mob boss, etc) can "encourage" you to make sure you vote at an online facility where they are watching... and there goes the privacy of the polling place and the anonymity of the ballot box.
Of course, in earlier times this was recognized as an issue with absentee voting. The solution that traditional voting systems adopted was to allow the voter to vote in person later at a real polling place, and that vote, (presumably more free of coercion), would invalidate their earlier vote.
I wonder if CanVote provided a similar "vote override" option for Ontario citizens? A polling place vote should always override an alternative-mechanism vote. I hope in the move to online voting we don't lose the non-obvious protections that have been added to our current electoral system over time.
--LP, a programmer who also supports voter-verified paper trails
I've done hobbiest-class research into the topic of oil substitutes and here are two oft-neglected issues to keep in mind:
1) Energy density. It's hard to improve upon oil/gasoline's energy-per-unit-volume with economical substitutes. Hydrogen fuel cells don't have nearly the energy density of gasoline. (Fuel cells tend to be far bulkier for this reason, or you can't travel as many miles with equivalent space.) I suspect consumers would accept a car with a smaller range; I dunno about other applications though. Technology and mass-production may drop fuel cell costs, but improving energy density takes some serious physics/chemistry.
2) Saudi Arabia (and other low-cost oil producers) have plenty of room to drop the price. Sure, it's not hard to see plenty of economical substitutes showing up at $30/barrel (today's price, historically well above average.) And even matching the long-term average price of oil at $15/barrel is conceivable. But the Saudis can produce oil at costs of $1-$2/barrel. Now I'm comparing end-prices to costs here which is a bit unfair (so add a 50% margin to $1-$2), but even if a energy substitute could produce power matching today's oil prices, it'd have to reduce in cost 30-fold in order for us to long-term wean ourselves completely off oil. And that's assuming the Saudi's don't get more efficient in the meantime. At least from an economic standpoint, ignoring costs of externalities like security/pollution.
So I see alternative fuel use increasing, but I don't see oil vanishing from the picture in my lifetime (or my kids'). Heck, I'd be delighted if we just cut our oil usage in half in my lifetime; that'd be a stunning success in my book.
I suspect the Saudi's are just talking down their influence for current political reasons.
--LP, probably posting a bit too late to get mod points
I used to read Steve Milunovich's research fairly regularly.
One of the advantages of reading Steve was that he did his own surveys of Fortune 100 (500?) CIOs, asking about budgets (ie future system vendor revenues) and various topics of the day (ERP deployments, etc). So I found his comments that Sun should make contrarian bets but "do so in ways palatable to conservative CIOs" interesting. Steve may have some unique insight into that.
What's a little odd to me about Steve's advice is the contradictions in it. At least based on the admittedly summary article linked here. On the one hand, he seems to advocate a "batten-down-the-hatches"-type strategy: cut R&D, dump SPARC (eventually), don't make waves, be more Linux friendly. And on the other hand he seems to say "make contrarian bets". It may be that Sun is just doomed due to volume economics (although in fairness, they have always been *way* more focused on that than every other Unix vendor in my past discussions with management I met in my past life), but the "batten-down-the-hatches" strategy seems more likely, not less likely to lead them down the "DEC, Data General, Compaq" path. Sure Sun needs to be shrewd and somewhat conservative in cutting excess spending. Maybe that *is* what they need to do to stabilize their stock a bit. But that isn't how they're going to avoid the 'computing graveyard'.
Although if you are doomed to the computing graveyard (something I thought was true of Sun in 1995 but Sun did stunningly well the following five years), it is true that the most prudent thing to do is spend your remaining strength as conservatively as possible. I don't have any easy answers myself for Sun. I can't fault Milunovich for trying, but the advice doesn't look particularly helpful to me.
--LP
"We're being as inclusive as we can", Gates said...
I.e. inclusive enough to give away 15% of the market to rivals and keep antitrust guys off our backs, but not inclusive enough to risk losing customers to any web services running on alternative OSes?
--LinuxParanoid, who doesn't yet believe Gates's philanthroipc altruism extends to other software companies
P.S. Note Gates's observation that "Standards are always a give-to-get bargain" and ask yourself "what does Gates think he is getting?" There are a variety of possible answers.
Pardon me, but a lot of you guys are missing the point of this comparator.
1) There are people out there with legit source licenses to SVR5 source trees. And not just Unix OEMs. Various people in large companies with SVR4/5 source licenses etc.
2) Such people cannot release the source code, and may (if paranoid of how they interpret 'derived works') not want to publish hashed MD5 codes of SVR5.
3) However, it should be possible for a legit SVR5 source licensee to publish openly a list of areas of code that are similar across trees, without that list being either A) a derived work, B) violating their NDAs (um, do check the fine print first though) and C) spending tons of their own, presumably expensive time, digging through stuff.
Then Linux advocates can then sift through the resulting large pieces of code and doublecheck/crosscheck the origins of it. At the very least, we'd have a public list of suspicious areas of Linux and could determine that certain parts are A) BSD-licensed, B) are verified as original by a known Linux coder, and C) don't fall into the above categories and remain 'suspicious'. This presumably is what ESR is referring to by "various persons will apply it in useful ways. Yes, I'm being deliberately vague and tantalizing". Let's say that its likely the percentages in A and B will be large.
Of course it's true that there could be code that this primitive tool doesn't catch. But SCO probably started their analysis by using tools like this also. Looking through millions lines of code by hand is no cakewalk, so one will inevitably start with code like this in such an investigation. (Unless one is concerned about one specific predetermined critical/sensitive piece of code.)
Oh, and the other thing about this tool that is nice IMHO? It demonstrates a "good faith" effort on the part of Linux advocates and coders to correct the problem -- despite the barriers raised by SCO (no code release except via NDA).
Finally, running this tool across a Linux and a BSD release should turn up some data that is both interesting and relevant for this dispute. I'm almost tempted to try that myself.
--LP
Although it *does* beg the question: if a 12 year can't assume debt, then how exactly did they get her name in the first place?
I've not seen anyone confirm or deny the following scenario, but I was thinking about this question this morning.
I suspect the mom, who was likely the owner of the ISP account (billed to the mom's credit card) is the one who actually had her name on the suit since the RIAA got her name through subpoena'ing the ISP. But in a brilliant PR move, the mom is telling the press that the RIAA is suing her daughter (since the mom had nothing to do personally with the copying.)
This is the only scenario that makes logical sense to me, but I'd note that it is 100% speculation.
--LP
Three or four years ago, UnixWare was actually functionally superior to Linux
Clearly Linux was/is a superior webserver and has been for some time. Furthermore, if you were running a single-CPU standard-hardware PC and your app ran on Unix, it was on par or perhaps in some sense you can articulate, superior. (For my purposes 10 years ago, Linux was superior because of its price, although I would be somewhat hesitant to consider that a "functional" feature of Linux except in the broadest sense.)
By functionally superior, I mean in the high-end Unix sense. For example, UnixWare had pretty good support for 4-8 way SMP with finer-grained locking when Linux had locks around huge chunks of the kernel. UnixWare had extensive reliability features used more for big-iron systems: clustering features, journaled filesystems (ext3/reiser were in development and still too buggy for production) and the ability to hot-swap CPUs and other things that weren't available on Linux. Etc.
It's a rational move for them.
I agree with all the arguments you make here that JFS/XFS/RCU/NUMA are components, ie distinguishable/distinct and separable (although NUMA less so) from the originating SVR4/5 OS owned by SCO. Presuming there is no overlapping copyright claim, rationally they should not be considered as derivative in a legal sense imho. I wouldn't go so far as to say SCO's legal argument is *irrational,* but I would consider it tenuous and novel.
I was trying to make a distinction between a rational business strategy versus a rational legal argument. As an x86 Unix vendor, SCO has never had an adequate answer to Linux/BSD, and after five years of trying various things (be a high-end complementary product, embrace and resell Linux) their revenues continue to drop. In light of that, a tenuous legal argument is a rationally (note: not ethically) better business strategy than doing the same old thing trying to sell UnixWare/OpenServer. "Hmm, we can't get customers, but perhaps we can convince a judge/jury to give us money." For better or worse, I think the odds are much higher of SCO getting $100 million from a judge or jury or settlement than by getting $100 million in new x86 Unix customers. From this vantage point, perhaps the lawsuit was inevitable whatever the merits were.
If your point is that without a convincing legal argument, they don't have a strong business strategy, I'd also agree. Having your success dependent on a judge/jury is not a good place to me. It's not a strong strategy either way.
--LP
You are right, but MS has already crushed SGI.
MS has obtained a cross-license to all SGI's graphics patents, and OpenGL is no longer a threat. A mild concern perhaps. MS buried their joint "Farenheit" high-level graphics API effort with SGI, killing it. MS has announced dropping support of OpenGL on future OSes. Development of OpenGL 2.0 is really the baby of 3Dlabs (or whoever bought them out; I forget), not SGI, which shows you how behind the curve SGI is on pushing OpenGL these days. OpenGL's survival depends more on John Carmack pushing IHVs to keep using it than SGI, and other than OpenGL, SGI has not presented MS with a platform threat.
MS may want to crush Linux and/or IBM, but SGI? Not even in the same ballpark.
The reason SCO is picking on SGI is because of NUMA.
SGI has been dumping their NUMA scalability crown jewels into Linux (unlike all other conventional Unix vendors who are keeping that stuff in their high-end proprietary OS+hardware combos) and this is a significant impediment to selling UnixWare as "the premier scalable x86 Unix". Off the shelf UnixWare supports up to 8 processors today and SCO made a stab at doing NUMA stuff once upon a time, but SGI's NUMA-Linux has tons more R&D behind it and is going 64-way.
Three or four years ago, UnixWare was actually functionally superior to Linux (I know, I know, hard to believe but it's true.) But any margin of superiority then has greatly diminished or been overtaken. This is a real problem if SCO can't keep up with the R&D dumped into Linux by the open source community plus IBM plus SGI, etc. So SCO has gone legal. It's a rational move for them. Their vacillating arguments and tenuously-novel notion of derivative works don't bode well for their long term success however.
--LP
"SGI will devolve elements of its proprietary software and operating system Irix, such as its XFS journalling file system,to Linux as soon as it clears the legal roadblocks surrounding the intellectual property.
That said, I'm at a loss to explain how SGI stuffed things like that ancient malloc.c into Linux. Perhaps things got sloppy or it was never noticed because someone had previously removed copyright notices? (Apparently this has been a problem at SCO as well, removing BSD license notices internally...)
You know, the ironic thing about this whole SCO uproar is that people have long bitched that the GPL was so viral... well look how viral the closed source SVR4/5 license apparently was!
--LP
P.S. A short history of XFS and Linux, Slashdot-style:
Here's a LinuxToday article and the original Slashdot thread covering that May 20, 1999 announcement.
Three months later, in August 1999, Slashdot covered that the XFS donation would be GPL (not just 'open source')
A year after that, the XFS beta arrived on Slashdot (September 2000), and
After two more years, XFS was merged into the Linux 2.5 kernel September 2002.
I wrote a paper on the subject of SGI donating XFS after interviewing someone there at the time they made their announcement (~May 20, 1999). I just looked up the paper and found the following quote:
"Currently, SGI is clearing the source code of any legal restrictions; it expects to be able to make the code openly available by the end of the summer. "
Ensuring they were free-and-clear to donate XFS under an open source license was *not* an afterthought for SGI. There was concern among all the major UNIX vendors of IP entanglement with Linux, and SGI was the first to openly pledge to donate a chunk of their core UNIX technology. (IBM donated some non-core stuff earlier, and core stuff like JFS later.)
SCO's claim that XFS or JFS are derivative works of SVR4/5 remains, to me, highly dubious.
Too bad for SGI, the last thing they need these days is lawsuits. SCO can't hope for a lot of money, but maybe they're hoping for weaker resistance?
--LP
I looked into this and skimmed the documentation. It didn't appear to have a way for me to make sure that the management-folks who bring in laptops every morning get updated. It seemed to be more oriented to updating desktops in the middle of the night (or in the middle of the day but that'd be a tad disruptive around here anyway.)
Is there something that lets me insure when the laptop users plugin to our network, they are asked/forced, first thing, to get the new updates? Maybe I missed it?
--LP
Your humble author suggests that SCO found themselves requiring a multithreaded web server, and as SCO UNIX is based on an ancient version of The UNIX spec it just couldn't cope ;-).
Well, there's a smiley so I know you're kidding.
But there are also some inaccurate facts and presuppositions buried in those comments.
First, your comment appears to ignore SCO's ability to use SCO UnixWare. SCO has two UNIX products, SCO UnixWare, and SCO OpenServer. SCO OpenServer is a Xenix descendent that is singlethreaded and probably as you suggest, couldn't cope. This is what most of SCO's installed base uses, and yeah it's old cruddy technology. SCO UnixWare uses pretty-sophisticated SVR5 technology that is really the core SVR kernel descended from AT&T & Novell days. It's pretty slick functionally (imho), is quite multithreaded running on 8-way (and NUMA I believe) systems, and conforms to UNIX 95 (although not UNIX 98 or the new UNIX 03 tweaks.) SCO is really suing over technology and rights allegedly derived from UnixWare/SVR4-5, not the older OpenServer technology you'd find in 90% of SCO installations.
Second, having a multithreaded webserver that can cope has little or nothing to do with whether one conforms to the latest UNIX specs from the Open Group. But I know you probably know that and are just trying to toss that in there, right?
--LP, not a UnixWare fan, just trying to reduce misinformation on the subject of SCO UNIXes
Poor SCO pointy-haired-bosses... I can see it now (names omitted to protect the guilty):
-------------------
PHB1: "Hey PHB2, I'm putting together this PowerPoint. I suppose I should slap some code in there to make this suit look more legit."
PHB2: "Yeah, good idea." (PHB2 goes to Etrade to dump a bit more stock)
PHB1: "I've got this copied code the IPI [Intellectual Property Investigative --ed] Team passed on to me, but Legal says we can't release it."
PHB2: "Yeah, $600 an hour to tell us we can't disclose it to the press and claim it's top-secret priceless intellectual property at the same time."
PHB1: "No kidding." (pause) "You ever seen code like this?"
PHB2: "Linux hippies. I dunno, it's all greek to me."
PHB1: "Genius! What a brilliant idea, I'll show those hackers the code in Greek!"
PHB2: "Hey, you're good..."
(peck, peck, peck)
--LP
Those were the 10 questions?
Sheesh, how about "How would you cut California's $35 billion budget deficit?" (i.e. spending cuts or tax increases or both, and in which areas?)
--LP
P.S. For the curious, dselect is the Debian package manager, documented here.
You all know that phone system conveys its own power so phones stay working when power is down.
But did you know that also hold true for DSL service?
It does in my area (north of NYC). Power has been down for seven hours, but I just hooked up my DSL modem through an extension cord to my car (which has an cig-lighter-to-AC-adapter) and DSL is working fine and that's how I'm posting this.
Oh, and my laptop is running off a battery which, using the above mechanism, I can recharge in my car as needed.
Quite handy. I'm not positive if this works for cable modems but I don't think so. I'd be curious if someone could confirm/deny that.
--LP
You raise a good point, but...
Energy density != Energy efficiency.
You want the former for weapons, the latter for commercial energy production.
(Although in the case of fuel substitutes for cars, both are actually quite important. No matter how much you improve the efficiency and cost of hydrogen or fuel cells, its hard to beat oil's energy density.)
Anyway, based on that article, it appears to me that it takes a heck of a lot of energy to make and "energize" the halfnium with protons (or eventually photons). A lot more than you get out when you eventually shoot the X-Ray in and get that 60-fold increase out. That 60-fold increase is just releasing energy you put in the substance gradually earlier. So it isn't necessarily energy efficient, just energy-dense. Of course, as they make the substance cheaper, that is a sign that they're improving the energy efficiency of the manufacturing process, so who knows how good they'll get at that. Clearly they have a long way to go in any case. Particle accelerators aren't cheap, either dollar-wise or energy-wise.
The effect of a nuclear-isomer explosion would be to release high-energy gamma rays capable of killing any living thing in the immediate area. It would cause little fallout compared to a fission explosion, but any undetonated isomer would be dispersed as small radioactive particles, making it a somewhat "dirty" bomb. This material could cause long-term health problems for anybody who breathed it in.
I'm wondering how big a problem this "dirty bomb characteristics" issue is. How much of the isomer really doesn't detonate (and why?) Is this a 1% of the substance doesn't detonate (decay suddenly when hit with an X-ray) problem or a 50% doesn't detonate? And if the amount of the material is small enough (e.g. a gram), perhaps this falls below injurious-in-practice threshholds? I.e. how close to conventional low-yield nuclear really is it?
--LP
OpenBSD is pretty stable. I currently have half a dozen systems running with an uptime of 50 days, and I've had 200+ days on multiple boxes. It goes down for major system maintenance and that's about it. I've used it for internet-facing webservers and for mailservers.
--LP, ignoring the 'do not feed the trolls' sign
IBM got a special amendment to the contract stating that they owned any changes they made to AIX.
I hadn't heard this before. Are you sure it's true? It easily could be, but that brings up a point which you skipped. If IBM does own it's modifications to UNIX (but not Sequent's), how can SCO complain about contract violations relating to JFS?
RCU and some NUMA work came from Sequent, but JFS is pure IBM-developed code (AFAIK) dating back to the original release of AIX in 1991 or so. It was pioneering at the time if I recall correctly.
Interesting anyway.
--LP
It's a nice piece of analysis. Someone could have done it 8 years ago when Java came out; the facts are not significantly different (The values are different of course but the ratios involved are pretty similar. I did some thinking along these lines back then, and then in 2000 when considering working for a "hot P2P company" that an old acquaintance of mine was running.)
My thinking went something like this: There are only a few, "niche" applications which need more compute power and which people pay for (distributed rendering, CFD, FEA, maybe a couple others). Maybe you could build that into a 10-30 million dollar business if you overcame a zillion obstacles but it didn't look like a billion or multi-billion dollar business. The applications for which people buy beefy servers, and which have a monetary payback, are mostly database applications. For those, you need to move the entire database near to the number-crunching PC, and that's not really feasible due to the cost of transporting Gigabytes of data or the unlikelihood that the PC's hard disk can store all the giga/terabytes of information potentially relevant for the computation. Not to mention the security problem.
And Jim Gray's analysis lays out in more precise economic terms why it doesn't make sense. I like how he even calculated the relative merits of a Beowulf-like cluster of PCs versus P2P which I never really analyzed (I lumped them together as basically similar.)
That said, has anybody even made a stab at designing or implementing a relational database with a P2P architecture? I know that there's Oracle Cluster Server, but I'm thinking of something more low-end and more distributed.
--LP