First of all, ignore their stated business model. It's obvious gibberish and will never work. Relax.
However, the software tools that they'll develop to do the matching are going to be fairly useful. At some point (probably when they come down off the crack cocaine they were smoking when they came up with their original business plan) they'll realize that there's probably a lot more money in making a useful product for consumers; namely, something that plugs into systems like Napster clients and helps you sort out what music is what. I hate messing around with weirdly-named mp3s (missing track numbers, incorrect titles, etc) off these kinds of services.
I think it's sort of funny; a better name for it might be "Am I female or not?". I noticed that the men were consistently low-rated, and that there were really high ratings for things like upskirt shots and the like. My suspicion is that almost all of the raters are straight men (I suspect there are far more focussed sites for gay men who want to do this sort of thing - and more!). Of course, they don't gather data on this.
... at least, not in the medium run (and in the long run, of course, we are all dead). Why do I think this?
1. Well, speed problems often scale to the size of the task, even in the OS. 10 years ago, I was sure that "just a bit more cpu speed and context switch speed" would solve most major OS bottlenecks. If you had told me 10 years ago that OS's were going to have to handle real-time video decoding off gigabit networks and similar horrors, I might have sung a different tune. Of course, eventually we'll run out of cool, ever-more-cycle hungry things to throw at our machines - but I think that's a fair way away.
Secondly, not all parts of CPU architecture follows Moore's law at quite the same rate. Architectures are optimized for SPEC, not context switches - which, in some ways, get more and more expensive (in cycle terms, not in real terms, of course) as register files and various other forms of per-process and per-thread get larger.
The advantage that you describe in for PDAs seem kind of sketchy.
Learning about a "single daemon's" message passing protocol with the rest of the system is no harder and no easier than learning about the method calls that call the equivalent module in a operating system.
As for microkernels being able to dump things like device support - how long have we been able to build custom UNIX kernels now? Granted, you can't dump support for (say) processes, but I put it to you, that if you're really pruning back your system to bare bones, then the microkernel probably won't be a very good match for the PDA either. I doubt that the same microkernel can be (a) a great building block for building fully-featured systems on top of it, and (b) a fine base for a completely minimal PDA os. There are just too many competing demands, here.
I agree with the people who pointed out that all these perks are well and good, but money is better than nearly all the others. If they're worried about tax, how about upping the amount they'll pay into a 401(k) or whatever you folks call it over there (posting from Australia, where we have a similar system).
Certain things, in my mind, don't even count as perks at all: anything involving caffeine, anything that makes it more efficient to get to/from work or easier to stay there (like a cafeteria that serves dinner until late..) - these aren't perks. They might be good or bad, but no-one should feel that these kind of services are some sort of gift. These services exist to make working really long hours seem normal.
The problem with a lot of the other perks is that they're often inflexible (what if I want to train at Igor's Horrid Iron Basement rather than YuppiePump Gym?) and essentially amount to subsidizing certain lifestyles (why should the company effective pay people with kids/gym habits/ interests in dance/etc. more?)
Actually, I've heard of theorists working to prove that P=NP is unprovable (given a particular framework for proof). That was years ago, and I haven't seen anyone beating down their door to hand out awards, so I can only assume that these attempts have been a futile as attempts to decide the actual problem.
Anyone know what's going on with this kind of work these days?
Transmeta is a technically exciting company, but I can't say that I think much of their business plan. Essentially, they've got a very complex solution to a single part of the power-consumption problem. The problem is, that CPU power consumption is their _only_ edge (oh, that and Linus).
So even if your CPU is burning 50% of the power, their best case is going to be doubling battery life. That's good, but is it good enough? Against Intel, who can take an existing design and throw a bunch of process shrinks and clever EE tricks at it?
I, for one, don't think that Transmeta has a chance of keeping up against Intel. I give them a year.
I haven't really followed this debate since '95, so I may be completely off-base here. I recall at the time, there were a couple big problems with micro-kernel rhetoric:
1) The performance generally stunk. This may have changed, but I recall seeing user-level network protocol stacks get completely clobbered by monolithic kernels. There were a whole bunch of ways of getting around this (including moving entire protocol stacks into the applications!), but most seemed to fall into the category of "making microkernels run faster by making them not really microkernels anymore".
2) The assumption that complexity just vanishes if you break everything up into a whole bunch of little servers. If you compare a microkernel to a modern, multi-threaded OS written in a OO language, then the thing you get from having a microkernel is protection from memory-smashing bugs in one service taking down other services. That's good, but not revolutionary.
A monolithic OS can die because the file system code runs amok. A microkernel-based system with the same class of bug might still be "up", only you can't get to any files, or run any programs. A user won't really care either way.
A lot of the advantages of microkernels seemed to be predicated on OS development and debugging staying exactly as godawful as it was back in the late 80s and early 90s. I hacked on an Ultrix kernel, so I have vivid memories of how gruesome the whole process is. I am assure by OS guys that things have come a long way since then.
Also, I should point out that Mach is a pretty huge for a microkernel. It's got everything in it but the kitchen sink. I think the Plan 9 monolithic kernel was smaller than just the Mach microkernel (not even counting all of the stuff you have to pile on top of it to make it actually work).
Not necessarily. For a start, it's unlikely that all 100 people would want high-bandwidth internet access, and as people start bailing out, your $10 figure goes up.
More importantly, the service providers aren't going to charge the same for a 100-apartment service (that will probably saturate its conection pretty constantly) as they will for a 1-house deal (which won't). Even if the service providers optical network has effectively limitless capacity, they have to pay for network traffic off their own network.
What? Why would you go on about microprogrammability in connection to IA-64? This is an important issue for high-end RISC processors since when, exactly?
In case you missed every conceivable opportunity to find any information on IA-64, I'd fill in the novelty as follows. Among general-purpose CPUs that hit the mainstream (please remember this bit before flaming me about Multiflow or your favorite DSP or graphics chip), the first implementations of IA-64 will be:
First VLIW-type chip, with at least some potential of avoiding the standard pitfalls of VLIW.
First CPU with extensive support for control and data speculation.
First CPU with register rotation for overhead-free software pipelining of loops.
These may or may not be good ideas. I suspect that some of the stuff that is in the IA-64 architecture will turn out to be a bad idea. Not so much because it's inherently stupid; more because some of the features are going to be hard for compiler writers to exploit, and may become underutilized.
However, no-one who knows anything about computer architecture would deny that the IA-64 is novel.
Have you ever read this kind of patent? Since my last post, I headed over to the patent database, and sure enough, it's another one of those dull and windy patents about a specific prediction technique. After skimming one of the patents mentioned in the article, I had to skip "LOADRS instruction and asynchronous context switch," lest I go into a coma.
Yes, they are patenting ideas, albeit mindnumbingly specific ones (something for which we should be grateful; the specificity and dullnes s of the patent application is a bit hint at how little new stuff is introduced with one of these patents). I don't think that they _should_ be able to do this. I didn't say that I thought Intel having these patents is good, I said that they were possibly legitimate, in the sense of all the other CPU architecture patents out there. Personally, I think most of these patents are utter drivel; a mountain of prior art with a tiny cairn of original work perched on top of it.
I don't know what you mean by "how certain instructions impact data flow throughout the IC". Ummn, don't all instructions affect data flow throughout the IC? This is so vague as to be meaningless. Can you give an example of how you think such a patent could restrict a whole class of other implementations?
Despite all this, I'm mostly in agreement with you here. I do think they are laying a legal minefield for other IA-64 implementers. I wouldn't call it cloning, as one clones a chip, not an instruction set. I am pessimistic about the USPTO doing anything; most of those other patents at the back of MPR went through without any problems that I heard of. The fun starts later, when two deep-pocketed companies get into it.
Firstly, I would suggest that anyone who hasn't read the IA-64 architecture book, or at least a decent summary of the contents, should turn the volume down a few notches. Thank you.
This article is sort of silly. "In effect, trying to patent the instruction set itself" is a fairly vague notion; in fact, what Intel is doing is patenting some of their software techniques (expressed usually in small groups of instructions) for prefetching and control/data speculation. Right or wrong, this happens all the time. If some company has a nifty new caching algorithm, they will patent the idea; not the gatelist and implementation.
For example, if you could implement a IA-64 clone by (say) ignoring all prefetch instructions, and just fetching the data when it was needed (effectively turning the chk instructions into the actual loads, for those who are aware of this stuff - you could do it with binary translation). While this may not be a very good idea, it wouldn't infringe their prefetching patent, even if you used the same instruction mnemonics and produced a chip that could run the same binaries.
Personally, I think these patent are potentially disturbing, but put it in perspective with common practice. Read the back of Microprocessor Report sometimes; there are lists upon lists of patents being granted for techniques in exactly the same fashion as above.
As for the patents, I haven't read them, but I suspect that they'll have a tough time with them. IA-64 didn't spring out of nowhere, and a lot of the ideas that went into it follow a fairly predictable (no pun intended) path of development in academia and industry. A fairly stacatto summary of these paths can be found at Historical background for HP/Intel EPIC and IA-64 - if you don't already know something about computer architecture, don't expect to be illumined. The point is, Intel (or more accurately Idea or whatever the Intel/HP collab. is called) hasn't necessarily added that much to prior art here, so the patent may be too broad and subject to either legal attack, or too narrow and easily worked around.
Oh, and to the people cheering on the failure of IA-64, I beg to differ. Some of us write compilers and binary optimizers and code generators, and the death of the x86 architecture would make us very, very happy. The fact that the first IA-64 is going to be a dog isn't really that suprising - it's a huge engineering task and the first chip was always going to be a reference chip more than a serious performance model.
I read this a while ago; not that impressed, alas
on
Look to Windward
·
· Score: 1
I'm a big admirer of Iain Banks, but it seems like
he's starting to run out of ideas as far as the
Culture books go. The Culture, while one of the
most impressive SF backgrounds ever dreamed up by
anyone (way more impressive, IMHO, than the Foundation or the background to Dune), has a basic
problem: not enough death and suffering and Bad Stuff for someone like Banks to write about. So his stuff is always on the periphery, about the rough edges where the Culture meets the rest of the galaxy (usually primitive, nasty and militarized).
Unfortunately, this has started to get old. It was done very well in the first few books, but doesn't really bear repetition very well. The Culture always seems to hold too many of the cards (both in terms of power and morality), and there are always big Minds from Contact or SC willing to jump out and play "deus ex machina" to wind up the plot (Player of Games, Excession, Look to Windward).
Iain Banks hasn't written a bad sf novel, but as far as the Culture ones go, once you've read Use of Weapons, Player of Games and Consider Phelebas, you're going to be in serious diminishing-returns territory.
My problem with those "moulded perfectly to your grip" sort of products is that they don't fit anyone with unusually shaped hands (long/short, wide/thin). So your fingers wind up (in my case, having long fingers) sitting all curled up, well outside those cool ergonomic grooves.
They should just send the buttons, the circuitry, and the clay.
I think that a lot of Slashdotters went off their meds simultaneously, today. There's no other possible way to explain the weird paranoia that crops up every time this source code theft is mentioned.
Conspiracy theory #1 - Microsoft faked it
Come on. Microsoft does not possess an oracle that tells them things like "if you fake being hacked, your stock will stay high, people will not abandon your products (quite the possibility at the server end), and you'll get lots of clout in drafting new anti-hax0r legislation". And if you don't have that kind of oracle, you're not going to go out and pretend that you got hacked so that you can score some political points against the free software movement.
They stand to lose far more business from 10% of their potential server market shifting to Sun/IBM/whoever (or deciding to stay with Sun) than they stand to gain from slightly helping the cause of some vague, unenforcable laws directed at reverse engineering.
Yes, Microsoft will try to get as much advantage as they can from this. That's no suprise.
Conspiracy theory #2 - Free software people did it
If free software types (or supporters of same) were behind it, don't you think that someone would have seen the sources on freenet or some random ftp site by now? Or at least heard a couple of well-substantiated stories to that effect? ("I saw a huge tarball called microsoft-sources.tar.Z on ftp://....").
Far more likely, it's either some script kiddiez, who probably didn't even get it together to the point where they could get the source in any useful form, or some low-level industrial espionage people who are discreetly shopping around their product to various shady firms.
Incidentally, if it's the latter case, I wouldn't anticipate seeing the source showing up anywhere for free; why would the people who stole the source for profit give it away for free?
I, too, have often thought it would be an honorable and worthwhile goal to get a bunch of us off this rock, permanently, and I could name a few names.
Seriously, though, the idea that any kind of permanent manned off-earth presence would be useful in case of an extinction-level event is entirely ridiculous.
Firstly, it's not like the current generation of systems that we build are self-contained. You'd be talking about a far more difficult task to have bases with the capacity to transfer their entire population and cargo back to Earth. This has to happen in one shot, too, as a post-ELE Earth won't have the resources to send further missions to the base.
Secondly, what happens then? How many people are you envisioning up there in such a base? A few hundred? You're going to be sharply limited by the number of women available to bear children. Do you really suppose that you'll be able to find a big bunch of young, nubile female astronauts who are willing to sign on as possible broodmares to "restock the Earth"? We're talking 4 or 5 pregnancies each, in what will be quite primitive conditions.
And if you don't have the technology to store and implant eggs (which is pretty likely; how much specialized medical equipment are you going to be able to bring back on the re-entry shuttle) then that set of women is _it_, for earth's future gene pool. You can do sperm, of course, because that's a little easier.
And yes, I've heard of "mitochondrial Eve". However, even if there was a common female ancestor or tiny group of ancestors at one stage, doesn't mean that any particular tiny group of females has the capacity to engender a healthy human species.
A great deconstruction of this kind of silly-assed fantasy is in the science fiction book "We Who Are About To..." by Joanna Russ. It's an appallingly grim book, but its a good look at the thoughtless assumptions of the little boys who read and write science fiction about what happens to women in these rosy little recolonization fantasies.
Instead of having Transmeta go off and build a new style of (no doubt self-serving) benchmark practice, how about emulating the SPEC benchmarks with their "train" and "ref" benchmark runs.
For those of you who aren't SPECheads, "train" benchmark runs are used to profile and optimize your code for the final, measured "ref" benchmark set (although I think this only occurs for reporting of peak numbers, as there's a lot of opportunity for benchmark-specific compiler skullduggery here).
This is a well-known practice. It models well the fact that while there is a fair bit of common coverage between different runs of a program, it's not perfect. It affords opportunities for the "other camp" (IA-32) to do their own optimizations.
Granted, there's a difference between standard profile-driven optimization and on-the-fly optimization, but there's a lot less difference than you'd think in many applications.
A bit off my topic, here, but by the way: locality is typically much worse in real applications than it is in SPEC-style benchmarks, even the more realistic ones. Don't be too optimistic about all of that 90%/10% stuff you learned in undergrad CS; sometimes it applies, but a lot of bigger apps are not nearly as tidy as xlisp and m88ksim - or, god help us, the long-departed eqntott ("I think I'm an 8-line microbenchmark").
While this is an interesting set of ideas, I can't help but think that it's a bit like a lottery winner pondering what unique personal attributes made him a lottery-winning kind of person ("perhaps the world is designed so that I must succeed!"). If he hadn't won, he'd be the same person, but he would never have occasion to think those same thoughts; instead someone else would ponder their own "unique qualities".
If the universe didn't have exactly this kind of six-number setup, then we wouldn't be here to talk about it.
In 1995-1996, I worked with my former advisor, Steve Lucco, on a similar idea called, forgettably,
Omniware .
Omniware was a RISC-like VM, with 16 registers and a instruction set that would not surprise anyone familiar with the MIPS or Alpha. We used a gcc backend to generate this code, and guaranteed against misbehaviour in network-downloaded code by inserting bounds-checking for loads and stores in our VM. We would translate from the VM into native code, doing it on the fly. Translation time was trivial - the translation process was pretty much a 1:1 thing, without complicated optimizations. Our code ran well within the 20% of native code; 10-20% overheads were typical (not counting translation time, of course:-) ).
The protection model was pretty simplistic - we could essentially build our own paging model (read permission, read/write permission) in software, but it was nowhere near as sophisticated as the mechanisms that Java uses to ensure good behaviour in unsafe code.
The project never went anywhere; Lucco & Wahbe formed a start-up (Colusa) which was acquired by Microsoft. Microsoft presumably bought the company as a hedge against Java and for the (ick) software patents that Colusa holds in this area (chiefly relating to the software-inserted-checking page protection model).
I wouldn't be suprised to hear that C# has some common ground with Omniware.
The most important lesson, IMO, that Omniware held was that it's quite possible, and maybe even desirable, to do heavy optimization (global and interprocedural) on a low-level intermediate representation. This gets most of the possible optimization done _before_ you start shipping code around the net.
Of course, your optimizations are limited by the virtual machine - a 16-register machine results in register use that is profligate by x86 standards (we had a simple reallocator, very fast) and parsimonious by RISC standards.
Java takes quite a different tack. Java's IR is comparatively high-level. Thus, if you want to heavily optimize Java code, you have to do it everywhere, on each VM. This is despite the fact that there will be much in common with the optmization process across many of these different machine types - even between the RISC and x86 families. Of course, Java was solving a quite different set of problems.
Of course, it's all hogwash. We need to ship random snippets of untrusted code around the net the same way that we need an icepick in the head. What can I say? It was 1995, and we'd all drunk the "mobile code Kool-aid".
Slashdot Mirror
First of all, ignore their stated business model. It's obvious gibberish and will never work. Relax.
However, the software tools that they'll develop to do the matching are going to be fairly useful. At some point (probably when they come down off the crack cocaine they were smoking when they came up with their original business plan) they'll realize that there's probably a lot more money in making a useful product for consumers; namely, something that plugs into systems like Napster clients and helps you sort out what music is what. I hate messing around with weirdly-named mp3s (missing track numbers, incorrect titles, etc) off these kinds of services.
I think it's sort of funny; a better name for it might be "Am I female or not?". I noticed that the men were consistently low-rated, and that there were really high ratings for things like upskirt shots and the like. My suspicion is that almost all of the raters are straight men (I suspect there are far more focussed sites for gay men who want to do this sort of thing - and more!). Of course, they don't gather data on this.
... at least, not in the medium run (and in the long run, of course, we are all dead). Why do I think this? 1. Well, speed problems often scale to the size of the task, even in the OS. 10 years ago, I was sure that "just a bit more cpu speed and context switch speed" would solve most major OS bottlenecks. If you had told me 10 years ago that OS's were going to have to handle real-time video decoding off gigabit networks and similar horrors, I might have sung a different tune. Of course, eventually we'll run out of cool, ever-more-cycle hungry things to throw at our machines - but I think that's a fair way away. Secondly, not all parts of CPU architecture follows Moore's law at quite the same rate. Architectures are optimized for SPEC, not context switches - which, in some ways, get more and more expensive (in cycle terms, not in real terms, of course) as register files and various other forms of per-process and per-thread get larger. The advantage that you describe in for PDAs seem kind of sketchy. Learning about a "single daemon's" message passing protocol with the rest of the system is no harder and no easier than learning about the method calls that call the equivalent module in a operating system. As for microkernels being able to dump things like device support - how long have we been able to build custom UNIX kernels now? Granted, you can't dump support for (say) processes, but I put it to you, that if you're really pruning back your system to bare bones, then the microkernel probably won't be a very good match for the PDA either. I doubt that the same microkernel can be (a) a great building block for building fully-featured systems on top of it, and (b) a fine base for a completely minimal PDA os. There are just too many competing demands, here.
I agree with the people who pointed out that all these perks are well and good, but money is better than nearly all the others. If they're worried about tax, how about upping the amount they'll pay into a 401(k) or whatever you folks call it over there (posting from Australia, where we have a similar system).
Certain things, in my mind, don't even count as perks at all: anything involving caffeine, anything that makes it more efficient to get to/from work or easier to stay there (like a cafeteria that serves dinner until late..) - these aren't perks. They might be good or bad, but no-one should feel that these kind of services are some sort of gift. These services exist to make working really long hours seem normal.
The problem with a lot of the other perks is that they're often inflexible (what if I want to train at Igor's Horrid Iron Basement rather than YuppiePump Gym?) and essentially amount to subsidizing certain lifestyles (why should the company effective pay people with kids/gym habits/ interests in dance/etc. more?)
Actually, I've heard of theorists working to prove that P=NP is unprovable (given a particular framework for proof). That was years ago, and I haven't seen anyone beating down their door to hand out awards, so I can only assume that these attempts have been a futile as attempts to decide the actual problem.
Anyone know what's going on with this kind of work these days?
Transmeta is a technically exciting company, but I can't say that I think much of their business plan. Essentially, they've got a very complex solution to a single part of the power-consumption problem. The problem is, that CPU power consumption is their _only_ edge (oh, that and Linus). So even if your CPU is burning 50% of the power, their best case is going to be doubling battery life. That's good, but is it good enough? Against Intel, who can take an existing design and throw a bunch of process shrinks and clever EE tricks at it? I, for one, don't think that Transmeta has a chance of keeping up against Intel. I give them a year.
I haven't really followed this debate since '95, so I may be completely off-base here. I recall at the time, there were a couple big problems with micro-kernel rhetoric:
1) The performance generally stunk. This may have changed, but I recall seeing user-level network protocol stacks get completely clobbered by monolithic kernels. There were a whole bunch of ways of getting around this (including moving entire protocol stacks into the applications!), but most seemed to fall into the category of "making microkernels run faster by making them not really microkernels anymore".
2) The assumption that complexity just vanishes if you break everything up into a whole bunch of little servers. If you compare a microkernel to a modern, multi-threaded OS written in a OO language, then the thing you get from having a microkernel is protection from memory-smashing bugs in one service taking down other services. That's good, but not revolutionary.
A monolithic OS can die because the file system code runs amok. A microkernel-based system with the same class of bug might still be "up", only you can't get to any files, or run any programs. A user won't really care either way.
A lot of the advantages of microkernels seemed to be predicated on OS development and debugging staying exactly as godawful as it was back in the late 80s and early 90s. I hacked on an Ultrix kernel, so I have vivid memories of how gruesome the whole process is. I am assure by OS guys that things have come a long way since then.
Also, I should point out that Mach is a pretty huge for a microkernel. It's got everything in it but the kitchen sink. I think the Plan 9 monolithic kernel was smaller than just the Mach microkernel (not even counting all of the stuff you have to pile on top of it to make it actually work).
Not necessarily. For a start, it's unlikely that all 100 people would want high-bandwidth internet access, and as people start bailing out, your $10 figure goes up. More importantly, the service providers aren't going to charge the same for a 100-apartment service (that will probably saturate its conection pretty constantly) as they will for a 1-house deal (which won't). Even if the service providers optical network has effectively limitless capacity, they have to pay for network traffic off their own network.
What? Why would you go on about microprogrammability in connection to IA-64? This is an important issue for high-end RISC processors since when, exactly?
In case you missed every conceivable opportunity to find any information on IA-64, I'd fill in the novelty as follows. Among general-purpose CPUs that hit the mainstream (please remember this bit before flaming me about Multiflow or your favorite DSP or graphics chip), the first implementations of IA-64 will be:
First VLIW-type chip, with at least some potential of avoiding the standard pitfalls of VLIW.
First CPU with extensive support for control and data speculation.
First CPU with register rotation for overhead-free software pipelining of loops.
These may or may not be good ideas. I suspect that some of the stuff that is in the IA-64 architecture will turn out to be a bad idea. Not so much because it's inherently stupid; more because some of the features are going to be hard for compiler writers to exploit, and may become underutilized.
However, no-one who knows anything about computer architecture would deny that the IA-64 is novel.
Have you ever read this kind of patent? Since my last post, I headed over to the patent database, and sure enough, it's another one of those dull and windy patents about a specific prediction technique. After skimming one of the patents mentioned in the article, I had to skip "LOADRS instruction and asynchronous context switch," lest I go into a coma.
Yes, they are patenting ideas, albeit mindnumbingly specific ones (something for which we should be grateful; the specificity and dullnes s of the patent application is a bit hint at how little new stuff is introduced with one of these patents). I don't think that they _should_ be able to do this. I didn't say that I thought Intel having these patents is good, I said that they were possibly legitimate, in the sense of all the other CPU architecture patents out there. Personally, I think most of these patents are utter drivel; a mountain of prior art with a tiny cairn of original work perched on top of it.
I don't know what you mean by "how certain instructions impact data flow throughout the IC". Ummn, don't all instructions affect data flow throughout the IC? This is so vague as to be meaningless. Can you give an example of how you think such a patent could restrict a whole class of other implementations?
Despite all this, I'm mostly in agreement with you here. I do think they are laying a legal minefield for other IA-64 implementers. I wouldn't call it cloning, as one clones a chip, not an instruction set. I am pessimistic about the USPTO doing anything; most of those other patents at the back of MPR went through without any problems that I heard of. The fun starts later, when two deep-pocketed companies get into it.
This article is sort of silly. "In effect, trying to patent the instruction set itself" is a fairly vague notion; in fact, what Intel is doing is patenting some of their software techniques (expressed usually in small groups of instructions) for prefetching and control/data speculation. Right or wrong, this happens all the time. If some company has a nifty new caching algorithm, they will patent the idea; not the gatelist and implementation.
For example, if you could implement a IA-64 clone by (say) ignoring all prefetch instructions, and just fetching the data when it was needed (effectively turning the chk instructions into the actual loads, for those who are aware of this stuff - you could do it with binary translation). While this may not be a very good idea, it wouldn't infringe their prefetching patent, even if you used the same instruction mnemonics and produced a chip that could run the same binaries.
Personally, I think these patent are potentially disturbing, but put it in perspective with common practice. Read the back of Microprocessor Report sometimes; there are lists upon lists of patents being granted for techniques in exactly the same fashion as above.
As for the patents, I haven't read them, but I suspect that they'll have a tough time with them. IA-64 didn't spring out of nowhere, and a lot of the ideas that went into it follow a fairly predictable (no pun intended) path of development in academia and industry. A fairly stacatto summary of these paths can be found at Historical background for HP/Intel EPIC and IA-64 - if you don't already know something about computer architecture, don't expect to be illumined. The point is, Intel (or more accurately Idea or whatever the Intel/HP collab. is called) hasn't necessarily added that much to prior art here, so the patent may be too broad and subject to either legal attack, or too narrow and easily worked around.
Oh, and to the people cheering on the failure of IA-64, I beg to differ. Some of us write compilers and binary optimizers and code generators, and the death of the x86 architecture would make us very, very happy. The fact that the first IA-64 is going to be a dog isn't really that suprising - it's a huge engineering task and the first chip was always going to be a reference chip more than a serious performance model.
I'm a big admirer of Iain Banks, but it seems like
he's starting to run out of ideas as far as the
Culture books go. The Culture, while one of the
most impressive SF backgrounds ever dreamed up by
anyone (way more impressive, IMHO, than the Foundation or the background to Dune), has a basic
problem: not enough death and suffering and Bad Stuff for someone like Banks to write about. So his stuff is always on the periphery, about the rough edges where the Culture meets the rest of the galaxy (usually primitive, nasty and militarized).
Unfortunately, this has started to get old. It was done very well in the first few books, but doesn't really bear repetition very well. The Culture always seems to hold too many of the cards (both in terms of power and morality), and there are always big Minds from Contact or SC willing to jump out and play "deus ex machina" to wind up the plot (Player of Games, Excession, Look to Windward).
Iain Banks hasn't written a bad sf novel, but as far as the Culture ones go, once you've read Use of Weapons, Player of Games and Consider Phelebas, you're going to be in serious diminishing-returns territory.
My problem with those "moulded perfectly to your grip" sort of products is that they don't fit anyone with unusually shaped hands (long/short, wide/thin). So your fingers wind up (in my case, having long fingers) sitting all curled up, well outside those cool ergonomic grooves.
They should just send the buttons, the circuitry, and the clay.
I think that a lot of Slashdotters went off their meds simultaneously, today. There's no other possible way to explain the weird paranoia that crops up every time this source code theft is mentioned.
Conspiracy theory #1 - Microsoft faked it
Come on. Microsoft does not possess an oracle that tells them things like "if you fake being hacked, your stock will stay high, people will not abandon your products (quite the possibility at the server end), and you'll get lots of clout in drafting new anti-hax0r legislation". And if you don't have that kind of oracle, you're not going to go out and pretend that you got hacked so that you can score some political points against the free software movement.
They stand to lose far more business from 10% of their potential server market shifting to Sun/IBM/whoever (or deciding to stay with Sun) than they stand to gain from slightly helping the cause of some vague, unenforcable laws directed at reverse engineering.
Yes, Microsoft will try to get as much advantage as they can from this. That's no suprise.
Conspiracy theory #2 - Free software people did it
If free software types (or supporters of same) were behind it, don't you think that someone would have seen the sources on freenet or some random ftp site by now? Or at least heard a couple of well-substantiated stories to that effect? ("I saw a huge tarball called microsoft-sources.tar.Z on ftp://....").
Far more likely, it's either some script kiddiez, who probably didn't even get it together to the point where they could get the source in any useful form, or some low-level industrial espionage people who are discreetly shopping around their product to various shady firms.
Incidentally, if it's the latter case, I wouldn't anticipate seeing the source showing up anywhere for free; why would the people who stole the source for profit give it away for free?
I, too, have often thought it would be an honorable and worthwhile goal to get a bunch of us off this rock, permanently, and I could name a few names.
Seriously, though, the idea that any kind of permanent manned off-earth presence would be useful in case of an extinction-level event is entirely ridiculous.
Firstly, it's not like the current generation of systems that we build are self-contained. You'd be talking about a far more difficult task to have bases with the capacity to transfer their entire population and cargo back to Earth. This has to happen in one shot, too, as a post-ELE Earth won't have the resources to send further missions to the base.
Secondly, what happens then? How many people are you envisioning up there in such a base? A few hundred? You're going to be sharply limited by the number of women available to bear children. Do you really suppose that you'll be able to find a big bunch of young, nubile female astronauts who are willing to sign on as possible broodmares to "restock the Earth"? We're talking 4 or 5 pregnancies each, in what will be quite primitive conditions.
And if you don't have the technology to store and implant eggs (which is pretty likely; how much specialized medical equipment are you going to be able to bring back on the re-entry shuttle) then that set of women is _it_, for earth's future gene pool. You can do sperm, of course, because that's a little easier.
And yes, I've heard of "mitochondrial Eve". However, even if there was a common female ancestor or tiny group of ancestors at one stage, doesn't mean that any particular tiny group of females has the capacity to engender a healthy human species.
A great deconstruction of this kind of silly-assed fantasy is in the science fiction book "We Who Are About To..." by Joanna Russ. It's an appallingly grim book, but its a good look at the thoughtless assumptions of the little boys who read and write science fiction about what happens to women in these rosy little recolonization fantasies.
Instead of having Transmeta go off and build a new style of (no doubt self-serving) benchmark practice, how about emulating the SPEC benchmarks with their "train" and "ref" benchmark runs.
For those of you who aren't SPECheads, "train" benchmark runs are used to profile and optimize your code for the final, measured "ref" benchmark set (although I think this only occurs for reporting of peak numbers, as there's a lot of opportunity for benchmark-specific compiler skullduggery here).
This is a well-known practice. It models well the fact that while there is a fair bit of common coverage between different runs of a program, it's not perfect. It affords opportunities for the "other camp" (IA-32) to do their own optimizations.
Granted, there's a difference between standard profile-driven optimization and on-the-fly optimization, but there's a lot less difference than you'd think in many applications.
A bit off my topic, here, but by the way: locality is typically much worse in real applications than it is in SPEC-style benchmarks, even the more realistic ones. Don't be too optimistic about all of that 90%/10% stuff you learned in undergrad CS; sometimes it applies, but a lot of bigger apps are not nearly as tidy as xlisp and m88ksim - or, god help us, the long-departed eqntott ("I think I'm an 8-line microbenchmark").
If the universe didn't have exactly this kind of six-number setup, then we wouldn't be here to talk about it.
Omniware was a RISC-like VM, with 16 registers and a instruction set that would not surprise anyone familiar with the MIPS or Alpha. We used a gcc backend to generate this code, and guaranteed against misbehaviour in network-downloaded code by inserting bounds-checking for loads and stores in our VM. We would translate from the VM into native code, doing it on the fly. Translation time was trivial - the translation process was pretty much a 1:1 thing, without complicated optimizations. Our code ran well within the 20% of native code; 10-20% overheads were typical (not counting translation time, of course :-) ).
The protection model was pretty simplistic - we could essentially build our own paging model (read permission, read/write permission) in software, but it was nowhere near as sophisticated as the mechanisms that Java uses to ensure good behaviour in unsafe code.
The project never went anywhere; Lucco & Wahbe formed a start-up (Colusa) which was acquired by Microsoft. Microsoft presumably bought the company as a hedge against Java and for the (ick) software patents that Colusa holds in this area (chiefly relating to the software-inserted-checking page protection model). I wouldn't be suprised to hear that C# has some common ground with Omniware.
The most important lesson, IMO, that Omniware held was that it's quite possible, and maybe even desirable, to do heavy optimization (global and interprocedural) on a low-level intermediate representation. This gets most of the possible optimization done _before_ you start shipping code around the net.
Of course, your optimizations are limited by the virtual machine - a 16-register machine results in register use that is profligate by x86 standards (we had a simple reallocator, very fast) and parsimonious by RISC standards.
Java takes quite a different tack. Java's IR is comparatively high-level. Thus, if you want to heavily optimize Java code, you have to do it everywhere, on each VM. This is despite the fact that there will be much in common with the optmization process across many of these different machine types - even between the RISC and x86 families. Of course, Java was solving a quite different set of problems.
Of course, it's all hogwash. We need to ship random snippets of untrusted code around the net the same way that we need an icepick in the head. What can I say? It was 1995, and we'd all drunk the "mobile code Kool-aid".