I thought Professor Nash killed the wholly Free Market idea some time back. After which, Black Friday (the digitization of the stock markets) killed it again. The BCCI scandal poured holy water on the grave. The global collapse due to Reaganomics/Thatcherism drove a stake through what would have been a heart, but might really have been a deformed liver. The current collapse did the bell, book and candle routine.
Setuid is mostly a vulnerability when you've the notion of a superuser. Linux has some/all of what's needed to do this. I'd consider the requirements to be:
A user can be assigned access to a specific set of capabilities within the kernel
A program can be assigned access to a specific set of capabilities within the kernel
Privileged programs would have access to the union of the two sets of capabilities, unprivileged programs would have access to the intersection of the two sets
Certain capabilities can be mutually exclusive so that if one is present then others are automatically filtered out regardless of privilege
Users have access to only a well-defined subset of programs according to mandatory access controls
There exist certain pseudo-users who can never be used by actual users but which can be assigned tasks/threads by the kernel and/or bootstrap process so that everything is run using the same mechanism, no special exceptions
It should never be possible for an OS kernel thread to bypass the security kernel
It should never be possible for an OS kernel thread even control the security kernel - the security kernel should instigate control activity independently
The idea of all this is that you should be able to have a ping program that has access to raw sockets (so you can do ICMP) such that specified users can call the program to perform the ping, but where bugs in ping have exceedingly limited scope for breaking out. Ideally, it shouldn't have any.
In the above scenario, the ping program would have the union of capabilities to add the raw sockets, where raw sockets was mutually exclusive of many normal user capabilities (which then get dumped as a result) and where anything spawned by ping gets owned by an "unreachable" user, so a bug in ping allowing you to run user-supplied code would run that code in a way the user could then do nothing with.
If you think the headaches of SELinux are bad, the pain of running a system outlined above would be exponentially worse. Literally. On the other hand, you can have only two out of the three of "completely secure", "easy to use" and "easy to administer".
The idea of having the security kernel's administration on kernel threads that are internal to the security kernel is that bugs in policy should have only limited ways to allow users who should be unauthorized to change policy. The only way to do that is to have policy actions and almost any other kernel activity mutually exclusive by hardcoding it in. Since policy has got to be settable by something, have a pseudouser and kernel thread that is only entitled to do that and access the necessary files, and nothing else.
Now we're getting to the stage where complexity would make the OS unusable, but if you could use it, it would require compatible vulnerabilities at multiple levels for an attacker to do anything.
It depends on what the three digit code represents. It's too short to be a hash and since the ballot isn't printed by a computer, it can't be any form of error-correction or tamper-proofing code. And although there's not going to be 1000 candidates in a given district, there's probably going to be in the hundreds in some cases, so there's a limit to the number of codes that could equal an individual.
Personally, I'd have gone for a 5 or 6 digit code. I'd also have the ballot papers printed by an electronic voting machine, so that the codes could contain error-correcting information and thus prevent alterations to the ballot.
I'm going to argue that for electing Senators, they'd do better by doubling the size of the Senate and allowing both first- and second-place candidates a seat with voting power equal to their percentage in the election.
(That way, a person who wins 50.1% of the vote has 50.1% of a vote. Proportional representation that's proportional.)
It's not KISS, it would be a bugbear to administer, but it would stop a lot of the razor-edge fiascos we've seen in past elections. Winning an extra few votes wouldn't win you enough extra voting power to be worth a damn, as opposed to the current system of winner-takes-all. That would all but eliminate the court challenge except in gross situations.
It would also get people what they actually wanted, which (hopefully) would rapidly teach them to stop wanting stupid things.
It is cool. I proposed something similar, albeit electronic voting, in the past on Slashdot but I'm thinking their approach has many advantages - not least that it reduces the number of attack vectors.
A three digit code is probably adequate, but I'd have probably opted for a longer value. It depends on how the code is used and what it represents. I'm assuming it represents a given candidate, as you're unlikely to have more than 1000 candidates for a given district but will likely have more than 1000 voters in a given voting station.
Regardless, a larger code would allow for easier detection of ballot-stuffing or ballot-concealing, so long as it wasn't too much larger. I presume 3 digits was picked as a compromise value.
The damn pity of it is that IBM and DARPA tend not to sponsor small-scale efforts in DSM and parallel languages. Otherwise, I'd be doing that rather than working where I am. (I'm being paid less now than I was 12 years ago, for longer hours.)
The greater pity is that the grants tend to go to large-scale corporations that are going to make money off their compilers anyway and don't need the grants, but whose work is so locked up in IP that nobody really sees the benefit other than said corporations.
(I'll excuse projects like Cilk++, as they're not opposed to the community and they only charge for support and source. That's fair enough. It's the $15,000 per seat compilers - and there's plenty of them - that get to me.)
I think we're pretty much saying the same thing, as I'd consider what you describe as the ecosystem as being essentially what I call the support system, only I included non-tech examples and you included tech examples.
The original Itanium had some serious design flaws, but the Itanium 2 seems to be a perfectly good chip and I'm reasonably sure that's what you're referring to.
Sure, there isn't a good compiler for the Itanium 2 yet. C compilers are only just now approaching the code-generation quality of Fortran compilers, and they've been out how long? And with Fortran stagnating for how much of that? It took something like a decade for the first BASIC compilers of any worth for the 6502 to emerge, PETSpeed being infinitely more memorable than things like the Dragon compiler.
If - and it's a big if - the Itanium family continues, I don't expect to see compilers for it to reach anything like the true potential of the chip for between 10-15 years. The Itanium 2 will have been replaced with the Itanium 4 or 5 by then.
Mind you, the Itanium Linux developers are producing some great stuff. There's a C-to-C compiler which optimizes the source, leaving it as source. Makes GCC produce far better output, as a rule. It's not well-known stuff, sure, and that means fewer people eyeball the code and contribute, which slows development, but I like a lot of what's being done.
First, the HPC world has a lot of commodity computers, but it also has a lot of very special-purpose computers.
Second, the odds of someone buying an HPC machine and then running pre-compiled generically-optimized code on it is virtually zero.
Third, HPC computers (as compared to loosely-clustered "pile-of-PCs" systems) are expensive and almost invariably use components that aren't "run-of-the-mill" (such as Infiniband or SCI for the interconnect).
In consequence, not only is the ix86 not "entrenched", it can't be "entrenched". It can only be popular in specific segments of the HPC market and even then only until something better comes along.
If HPC was tied that firmly to Intel, they'd all be using Windows Cluster Edition rather than Beowulf or MOSIX. Why? Because Beowulf and MOSIX require engineers who think, Windows does not. If thinking was superfluous to requirements, they'd be using an OS to suit. They aren't.
Now, will MIPS/MIPS64 ever do well in HPC as a whole? Probably not. MIPS is great for the embedded market, which means most MIPS engineers understand the embedded terrain. That's not a skill you can readily migrate to other areas. I do expect, however, MIPS/MIPS64 to do extremely well in some HPC domains. It's low-power (which is why it's popular in embedded systems) which is great when you can't cart around huge generators, can't dispose of the heat easily or have to minimize the radio noise. Plenty of markets there.
The Cell processor is an interesting design and seems to do great, but problems tend not to split 6-ways very often. I'd have preferred them to have a 4-way grouping of number-crunchers and have the other 2 cores really good at something else entirely. Perhaps as the manufacturing scale gets smaller, they'll be able to increase the variety of cores.
But sooner or later, someone is going to build a chip that is absolutely just what the HPC world needs. The Gnu C compiler is easily enough extended and although it's not quite as good as Green Hills or some of the other high-end compilers, the gap isn't so great that HPCers won't use it.
My guess is that such a chip will be very easily reconfigured through microcode and that it'll really be not much more than a bunch of core operations on silicon, a block of largely unsegmented memory and enough networking logic to allow the operator to fully exploit what's there. Oh, and a hell of a lot of internal bandwidth. To pull this off, you'd need to do for CPU internal buses what Infiniband and SCI have done for machine-level networking. That's the only truly hard part.
Such designs have been attempted before, where CPUs have no registers but just a block of memory you can use as you will. This idea goes a little further, since it replaces both Intel's notion of hyperthreading and the modern idea of multiple cores with the idea that hyperthreads x cores would be fixed with the microcode deciding the values. The compiler for the program can then section the CPU according to the needs of the program, rather than sectioning the program according to the needs of the CPU.
Could Intel borrow this? No. The above has no architecture, per-se, and no real instruction set. Just processor elements. There's nothing to copy, nothing to patent, and with no fixed instruction set, nothing to lock customers in with. The only thing they could really steal would be the faster internal bus. Which would keep them on desktops for decades to come, but because general-purpose is ALWAYS slower than special-purpose, it wouldn't keep them in the HPC market.
We've seen the same with other components of computers, of course. Long-gone are the days of proprietary floppy drives (yes, some companies really tried to tie customers to their brand of floppy disk), proprietary printers, proprietary tape drives, proprietary hard disk interfaces, even proprietary RAM (Got RAMBUS?).
Transmeta came close, but didn't go all the way (their CPU had an architecture of some sort) and were far too interested in the secrets busines
Low-power CPUs could be useful if you've the bandwidth. Ultimately, though, you're limited to how parallelizable the problem is - a fundamentally sequential problem will remain a fundamentally sequential problem, for example.
If the problem can be parallelized, you're then limited by the nature of the CPU vs. the nature of the problem. A problem that is essentially SIMD is going to do great on a cluster of identical processors. A problem that is essentially MIMD is not. MIMD problems will always do better on heterogeneous systems, where each CPU is best suited for the work it is being asked to do.
(Ideally, you'd have extremely low-level hardware that ran an emulated instruction set, essentially what Transmeta did. The difference would be that instead of compiling programs for the CPU, you'd compile the CPU for the programs.)
Even that is still too much of a simplification. Some Intel chips parallelize at the CPU element level. The University of Manchester, in 1978, had a compiler that parallelized at the single instruction level. Most modern parallel languages parallelize at the code block level. Most modern message-passing libraries (like MPI) parallelize at the thread level. Some cluster patches for Linux will parallelize at process level or even coarser-grain.
I honestly think all of these different levels of granularity have value and that the "ideal" parallel environment would be one in which you could mix-and-match freely, depending on the nature of the problem.
(Actually, the "ultimate" would be to have a language and compiler such that the compiler analyzed the cost/benefit of each method on each parallelizable unit and generated all necessary CPU microcode and program object files to run optimally.)
I dislike intensely saying bad about companies I've worked for, but it's not bad to simply say outright that Lightfleet is (for all practical purposes) clinically dead. It is possible that it could be revived, I suppose. Some of the early design work was ingenious and has a lot of merit. At this time, though, Count Dracula has better vital signs.
Having worked in one HPC startup (Lightfleet), I can say that one of the biggest dangers any startup faces is its own management. Good ideas don't make themselves into good products or turn themselves into good profits by selling. Good ideas don't even make it easier - you only have to look at how many products that are both defective by design AND sell astronomically well to see that.
I can't speak for SiCortex' case, but it looks to me like they had a great idea but lacked the support system needed to get very far in the market. It's not a unique story - Inmos didn't fail on technological grounds. Transmeta probably didn't, either.
Really, it would be great if there could be some effort into examining the inventions of the past to see what ideas are worth trying to recreate. For example, would there be any value in Content Addressable Memory? Cray got an MPI stack into RAM, but could some sort of hardware message-passing be useful in general? Although SCI and Infiniband are not extinct, they're not prospering too well either - could they be redone in a way that didn't hurt performance but did bring them into the mass market?
Then, there's all sorts of ideas that have died (or are dying - Netcraft confirms it) that probably should be dead. Bulk Synchronous Processing is fading, distributed shared memory is now only available in spiritualist workshops, CORBA was mortally wounded by its own specification committee and parallel languages like PARLOG and UPC are not running rampant even though there are huge problems with getting programs to run well on SMP and/or multicore systems.
Meh. Most of the list is bunk. The few valid points made are flawed heavily by them being largely points about how they were marketed to the masses, rather than in whether the technology actually delivered on what it actually promised.
I agree with you, but CASE as CASE is most certainly not "bunk". Think about the languages we use these days and compare them to back in the days when people actually used terms like CASE. PHP, Java and Ruby might not be "specification languages" in the purest Comp Sci sense, but they're miles closer than 68040 assembly, Fortran 77 and K&R-dialect C.
You're absolutely right about RAD tools, but since we still use stub-based networking code like RPC, it's a fair bet lots of people are using tools to generate code from some sort of spec. (Hell, for that matter, what are autoconf and autogen but tools that turn specifications into routines?)
Of course, CASE didn't stop at code generation. If it did, it would never have advanced beyond "The Last One" (a laughably-titled code generator from the late 1970s). It had a lot to do with looking for correctness. Klokwork and Coverity are the rightful heirs to that side of CASE. Sure they're not perfect, no tool ever is. I said heirs, not evolutionary dead-ends.
Traditional CASE is monolithic and it is monolithic that doesn't work so well. The elements, in and of themselves, seem to work fine. The smaller the grain, the better. Large-grained elements, like CORBA, don't seem to have been so successful.
Mind you, with ADA re-emerging and a real effort towards higher-quality code per iteration, I'm not going to write CORBA off so quickly. Grid computing tools like Globus aren't so fast either, but they're extremely good at what they do, which is why they're thriving..Net is "easy" but I regard it as easy for all the wrong reasons. I don't think you could ever write sustainable high-quality code with it. With something like TAO, on the other hand, I think you probably could.
As for why the big giants haven't got any good examples of successful CASE (or indeed ADA) projects - well, if a giant can't sort out feet from meters from nautical miles (yes, NASA has actually tried to find mountains 22,000 nautical miles high on Earth) then said giant probably couldn't produce anything even if it had a store of magic pixie dust and an army of fairy godmothers. Poor workmen blame the tools, and I think CASE has been blamed by some exceptionally cruddy workmen for the exceptionally cruddy work produced.
If you use a hollowed-out silver bullet that's filled with holy water and has an explosive tip, you kill the zombie and the silver fragments'll get any nearby werewolves.
Have you looked into Avahi, Zeroconf, the Router Discovery Protocol, IPv6's RADV, or anycasting? You should be able to whip up a self-configuring network fairly easily. You don't tell anyone, of course. That way, you "massively improve" (and get a performance bonus) whilst doing less work.
Nah. Actually, Microsoft discovered the X.25 specs during an archaeological dig and are thinking the full X.400 and X.500 specifications are really neat ideas.
Slashdot Mirror
Even if it hit a very unlucky ship, nobody would notice for very long.
I thought Professor Nash killed the wholly Free Market idea some time back. After which, Black Friday (the digitization of the stock markets) killed it again. The BCCI scandal poured holy water on the grave. The global collapse due to Reaganomics/Thatcherism drove a stake through what would have been a heart, but might really have been a deformed liver. The current collapse did the bell, book and candle routine.
You patent reality TV and soap operas, then wait for the riots to begin.
Setuid is mostly a vulnerability when you've the notion of a superuser. Linux has some/all of what's needed to do this. I'd consider the requirements to be:
The idea of all this is that you should be able to have a ping program that has access to raw sockets (so you can do ICMP) such that specified users can call the program to perform the ping, but where bugs in ping have exceedingly limited scope for breaking out. Ideally, it shouldn't have any.
In the above scenario, the ping program would have the union of capabilities to add the raw sockets, where raw sockets was mutually exclusive of many normal user capabilities (which then get dumped as a result) and where anything spawned by ping gets owned by an "unreachable" user, so a bug in ping allowing you to run user-supplied code would run that code in a way the user could then do nothing with.
If you think the headaches of SELinux are bad, the pain of running a system outlined above would be exponentially worse. Literally. On the other hand, you can have only two out of the three of "completely secure", "easy to use" and "easy to administer".
The idea of having the security kernel's administration on kernel threads that are internal to the security kernel is that bugs in policy should have only limited ways to allow users who should be unauthorized to change policy. The only way to do that is to have policy actions and almost any other kernel activity mutually exclusive by hardcoding it in. Since policy has got to be settable by something, have a pseudouser and kernel thread that is only entitled to do that and access the necessary files, and nothing else.
Now we're getting to the stage where complexity would make the OS unusable, but if you could use it, it would require compatible vulnerabilities at multiple levels for an attacker to do anything.
"I'm so very sorry" - isn't this what the 10th Doctor would say when he knew someone was about to die?
It depends on what the three digit code represents. It's too short to be a hash and since the ballot isn't printed by a computer, it can't be any form of error-correction or tamper-proofing code. And although there's not going to be 1000 candidates in a given district, there's probably going to be in the hundreds in some cases, so there's a limit to the number of codes that could equal an individual.
Personally, I'd have gone for a 5 or 6 digit code. I'd also have the ballot papers printed by an electronic voting machine, so that the codes could contain error-correcting information and thus prevent alterations to the ballot.
I'm going to argue that for electing Senators, they'd do better by doubling the size of the Senate and allowing both first- and second-place candidates a seat with voting power equal to their percentage in the election.
(That way, a person who wins 50.1% of the vote has 50.1% of a vote. Proportional representation that's proportional.)
It's not KISS, it would be a bugbear to administer, but it would stop a lot of the razor-edge fiascos we've seen in past elections. Winning an extra few votes wouldn't win you enough extra voting power to be worth a damn, as opposed to the current system of winner-takes-all. That would all but eliminate the court challenge except in gross situations.
It would also get people what they actually wanted, which (hopefully) would rapidly teach them to stop wanting stupid things.
It is cool. I proposed something similar, albeit electronic voting, in the past on Slashdot but I'm thinking their approach has many advantages - not least that it reduces the number of attack vectors.
A three digit code is probably adequate, but I'd have probably opted for a longer value. It depends on how the code is used and what it represents. I'm assuming it represents a given candidate, as you're unlikely to have more than 1000 candidates for a given district but will likely have more than 1000 voters in a given voting station.
Regardless, a larger code would allow for easier detection of ballot-stuffing or ballot-concealing, so long as it wasn't too much larger. I presume 3 digits was picked as a compromise value.
I doubt they'd sue. Not effective. Much better to bribe the elected officials. Proven technique and all that.
The damn pity of it is that IBM and DARPA tend not to sponsor small-scale efforts in DSM and parallel languages. Otherwise, I'd be doing that rather than working where I am. (I'm being paid less now than I was 12 years ago, for longer hours.)
The greater pity is that the grants tend to go to large-scale corporations that are going to make money off their compilers anyway and don't need the grants, but whose work is so locked up in IP that nobody really sees the benefit other than said corporations.
(I'll excuse projects like Cilk++, as they're not opposed to the community and they only charge for support and source. That's fair enough. It's the $15,000 per seat compilers - and there's plenty of them - that get to me.)
I think we're pretty much saying the same thing, as I'd consider what you describe as the ecosystem as being essentially what I call the support system, only I included non-tech examples and you included tech examples.
The original Itanium had some serious design flaws, but the Itanium 2 seems to be a perfectly good chip and I'm reasonably sure that's what you're referring to.
Sure, there isn't a good compiler for the Itanium 2 yet. C compilers are only just now approaching the code-generation quality of Fortran compilers, and they've been out how long? And with Fortran stagnating for how much of that? It took something like a decade for the first BASIC compilers of any worth for the 6502 to emerge, PETSpeed being infinitely more memorable than things like the Dragon compiler.
If - and it's a big if - the Itanium family continues, I don't expect to see compilers for it to reach anything like the true potential of the chip for between 10-15 years. The Itanium 2 will have been replaced with the Itanium 4 or 5 by then.
Mind you, the Itanium Linux developers are producing some great stuff. There's a C-to-C compiler which optimizes the source, leaving it as source. Makes GCC produce far better output, as a rule. It's not well-known stuff, sure, and that means fewer people eyeball the code and contribute, which slows development, but I like a lot of what's being done.
First, the HPC world has a lot of commodity computers, but it also has a lot of very special-purpose computers.
Second, the odds of someone buying an HPC machine and then running pre-compiled generically-optimized code on it is virtually zero.
Third, HPC computers (as compared to loosely-clustered "pile-of-PCs" systems) are expensive and almost invariably use components that aren't "run-of-the-mill" (such as Infiniband or SCI for the interconnect).
In consequence, not only is the ix86 not "entrenched", it can't be "entrenched". It can only be popular in specific segments of the HPC market and even then only until something better comes along.
If HPC was tied that firmly to Intel, they'd all be using Windows Cluster Edition rather than Beowulf or MOSIX. Why? Because Beowulf and MOSIX require engineers who think, Windows does not. If thinking was superfluous to requirements, they'd be using an OS to suit. They aren't.
Now, will MIPS/MIPS64 ever do well in HPC as a whole? Probably not. MIPS is great for the embedded market, which means most MIPS engineers understand the embedded terrain. That's not a skill you can readily migrate to other areas. I do expect, however, MIPS/MIPS64 to do extremely well in some HPC domains. It's low-power (which is why it's popular in embedded systems) which is great when you can't cart around huge generators, can't dispose of the heat easily or have to minimize the radio noise. Plenty of markets there.
The Cell processor is an interesting design and seems to do great, but problems tend not to split 6-ways very often. I'd have preferred them to have a 4-way grouping of number-crunchers and have the other 2 cores really good at something else entirely. Perhaps as the manufacturing scale gets smaller, they'll be able to increase the variety of cores.
But sooner or later, someone is going to build a chip that is absolutely just what the HPC world needs. The Gnu C compiler is easily enough extended and although it's not quite as good as Green Hills or some of the other high-end compilers, the gap isn't so great that HPCers won't use it.
My guess is that such a chip will be very easily reconfigured through microcode and that it'll really be not much more than a bunch of core operations on silicon, a block of largely unsegmented memory and enough networking logic to allow the operator to fully exploit what's there. Oh, and a hell of a lot of internal bandwidth. To pull this off, you'd need to do for CPU internal buses what Infiniband and SCI have done for machine-level networking. That's the only truly hard part.
Such designs have been attempted before, where CPUs have no registers but just a block of memory you can use as you will. This idea goes a little further, since it replaces both Intel's notion of hyperthreading and the modern idea of multiple cores with the idea that hyperthreads x cores would be fixed with the microcode deciding the values. The compiler for the program can then section the CPU according to the needs of the program, rather than sectioning the program according to the needs of the CPU.
Could Intel borrow this? No. The above has no architecture, per-se, and no real instruction set. Just processor elements. There's nothing to copy, nothing to patent, and with no fixed instruction set, nothing to lock customers in with. The only thing they could really steal would be the faster internal bus. Which would keep them on desktops for decades to come, but because general-purpose is ALWAYS slower than special-purpose, it wouldn't keep them in the HPC market.
We've seen the same with other components of computers, of course. Long-gone are the days of proprietary floppy drives (yes, some companies really tried to tie customers to their brand of floppy disk), proprietary printers, proprietary tape drives, proprietary hard disk interfaces, even proprietary RAM (Got RAMBUS?).
Transmeta came close, but didn't go all the way (their CPU had an architecture of some sort) and were far too interested in the secrets busines
Low-power CPUs could be useful if you've the bandwidth. Ultimately, though, you're limited to how parallelizable the problem is - a fundamentally sequential problem will remain a fundamentally sequential problem, for example.
If the problem can be parallelized, you're then limited by the nature of the CPU vs. the nature of the problem. A problem that is essentially SIMD is going to do great on a cluster of identical processors. A problem that is essentially MIMD is not. MIMD problems will always do better on heterogeneous systems, where each CPU is best suited for the work it is being asked to do.
(Ideally, you'd have extremely low-level hardware that ran an emulated instruction set, essentially what Transmeta did. The difference would be that instead of compiling programs for the CPU, you'd compile the CPU for the programs.)
Even that is still too much of a simplification. Some Intel chips parallelize at the CPU element level. The University of Manchester, in 1978, had a compiler that parallelized at the single instruction level. Most modern parallel languages parallelize at the code block level. Most modern message-passing libraries (like MPI) parallelize at the thread level. Some cluster patches for Linux will parallelize at process level or even coarser-grain.
I honestly think all of these different levels of granularity have value and that the "ideal" parallel environment would be one in which you could mix-and-match freely, depending on the nature of the problem.
(Actually, the "ultimate" would be to have a language and compiler such that the compiler analyzed the cost/benefit of each method on each parallelizable unit and generated all necessary CPU microcode and program object files to run optimally.)
I dislike intensely saying bad about companies I've worked for, but it's not bad to simply say outright that Lightfleet is (for all practical purposes) clinically dead. It is possible that it could be revived, I suppose. Some of the early design work was ingenious and has a lot of merit. At this time, though, Count Dracula has better vital signs.
Having worked in one HPC startup (Lightfleet), I can say that one of the biggest dangers any startup faces is its own management. Good ideas don't make themselves into good products or turn themselves into good profits by selling. Good ideas don't even make it easier - you only have to look at how many products that are both defective by design AND sell astronomically well to see that.
I can't speak for SiCortex' case, but it looks to me like they had a great idea but lacked the support system needed to get very far in the market. It's not a unique story - Inmos didn't fail on technological grounds. Transmeta probably didn't, either.
Really, it would be great if there could be some effort into examining the inventions of the past to see what ideas are worth trying to recreate. For example, would there be any value in Content Addressable Memory? Cray got an MPI stack into RAM, but could some sort of hardware message-passing be useful in general? Although SCI and Infiniband are not extinct, they're not prospering too well either - could they be redone in a way that didn't hurt performance but did bring them into the mass market?
Then, there's all sorts of ideas that have died (or are dying - Netcraft confirms it) that probably should be dead. Bulk Synchronous Processing is fading, distributed shared memory is now only available in spiritualist workshops, CORBA was mortally wounded by its own specification committee and parallel languages like PARLOG and UPC are not running rampant even though there are huge problems with getting programs to run well on SMP and/or multicore systems.
According to "Red Dwarf", that's because it's so important.
Meh. Most of the list is bunk. The few valid points made are flawed heavily by them being largely points about how they were marketed to the masses, rather than in whether the technology actually delivered on what it actually promised.
I agree with you, but CASE as CASE is most certainly not "bunk". Think about the languages we use these days and compare them to back in the days when people actually used terms like CASE. PHP, Java and Ruby might not be "specification languages" in the purest Comp Sci sense, but they're miles closer than 68040 assembly, Fortran 77 and K&R-dialect C.
You're absolutely right about RAD tools, but since we still use stub-based networking code like RPC, it's a fair bet lots of people are using tools to generate code from some sort of spec. (Hell, for that matter, what are autoconf and autogen but tools that turn specifications into routines?)
Of course, CASE didn't stop at code generation. If it did, it would never have advanced beyond "The Last One" (a laughably-titled code generator from the late 1970s). It had a lot to do with looking for correctness. Klokwork and Coverity are the rightful heirs to that side of CASE. Sure they're not perfect, no tool ever is. I said heirs, not evolutionary dead-ends.
Traditional CASE is monolithic and it is monolithic that doesn't work so well. The elements, in and of themselves, seem to work fine. The smaller the grain, the better. Large-grained elements, like CORBA, don't seem to have been so successful.
Mind you, with ADA re-emerging and a real effort towards higher-quality code per iteration, I'm not going to write CORBA off so quickly. Grid computing tools like Globus aren't so fast either, but they're extremely good at what they do, which is why they're thriving. .Net is "easy" but I regard it as easy for all the wrong reasons. I don't think you could ever write sustainable high-quality code with it. With something like TAO, on the other hand, I think you probably could.
As for why the big giants haven't got any good examples of successful CASE (or indeed ADA) projects - well, if a giant can't sort out feet from meters from nautical miles (yes, NASA has actually tried to find mountains 22,000 nautical miles high on Earth) then said giant probably couldn't produce anything even if it had a store of magic pixie dust and an army of fairy godmothers. Poor workmen blame the tools, and I think CASE has been blamed by some exceptionally cruddy workmen for the exceptionally cruddy work produced.
If you use a hollowed-out silver bullet that's filled with holy water and has an explosive tip, you kill the zombie and the silver fragments'll get any nearby werewolves.
Harvard Law School was investigating the correct legal interpretation of criminally insane. Darl was exhibit A.
What about thick-wire ethernet?
Depends on which Terminator they used.
Have you looked into Avahi, Zeroconf, the Router Discovery Protocol, IPv6's RADV, or anycasting? You should be able to whip up a self-configuring network fairly easily. You don't tell anyone, of course. That way, you "massively improve" (and get a performance bonus) whilst doing less work.
Microsoft is a fungus, and therefore is technically alive.
So that's why the death rate in hospitals per capita is twice that of the UK! I was wondering.
Nah. Actually, Microsoft discovered the X.25 specs during an archaeological dig and are thinking the full X.400 and X.500 specifications are really neat ideas.