The inventors of the transistor would have predicted it. The transistor was quite explicitly intended as a replacement for bulky vacuum tubes with inconvenient power requirements, and that's how we are using them.
As far as I can tell, MOSIX is still freely downloadable from mosix.com. However, the statement on the download page does seem kind of odd (you acknowledge "THAT MOSIX IS THE PROPERTY OF AMNON BARAK").
I really appreciate the work that Barak has done with and on Mosix. But I also find it kind of odd that Mosix could be the "property" of one individual. I would assume that it was developed with public research grants and while the author was employed at a university. Graduate students probably have also contributed, and there probably have been bug fixes as well. So, maybe it isn't bad if there is a GPL'ed distribution of Mosix after all. The GPL regulates issues of ownership rather well.
As for a user-space implementation of Mosix, I think that makes sense, although it has its drawbacks as well. One of the problems with user-space implementations is that they tend to be less than transparent in practice. It also strikes me as somewhat redundant, since Condor has already gone the user space route. A userland Mosix would only make sense if it were free and open source (as opposed to Condor).
Altogether, I hope people won't get too upset at each other over this. Mosix is great stuff and Barak and his university have been generous in making it available freely up to this point.
Slavery and conquest aren't Western inventions. While Europeans were still hunter-gatherers, civilizations in Africa did what civilizations tend to do: bash in each other's heads, steal each other's resources, and enslave each other. Long before the West came to power, lots of societies killed themselves through ecological disaster. And long before the West came up with the concept, other societies committed ethnic cleansing and genocide. The only thing that has reined in other societies in the past is their limited technological capabilities.
Yes, the West needs to do more, in particular since Western culture and Western politics are so dominant now. Yes, the harm that the West is doing is probably bigger in magnitude than that of any society before it because it has been magnified by technology. But, in terms of corruption and goals, Western society isn't any worse than most other societies have been traditionally. In fact, if anything, the West is more aware of the problems and actively, rationally, and consciously trying to address them, something that cannot be said of most of the societies that preceded Western societies.
Writing user interfaces in C or C++ is an absolutely dreadful process (although C and C++ are good for other applications). But if you use the right languages and toolkits, it becomes a lot easier. I like Python with Tk or wxWindows. Smalltalk (Squeak) is also quite nice, but a bit hard to deliver. Java/Swing is almost as tedious as C++, but at least the toolkit is very complete and there are lots of third party libraries that help you and that all work together.
Have people forgotten Watergate? In the US, every political party has been spying on the other, and if they happened to be in power, they were using the powers of the state to do so. Now, do you really believe that that has stopped? I suspect it has just gotten more sophisticated (I mean, Nixon was just plain stupid). And there are so many more possibilities now: a lot of intelligence work has been "privatized" and therefore has been freed of many pesky government regulations, and the US government can always outsource to foreign intelligence services and say "the French did it".
Sure, it looks like it's statically typed. But it has a real, full-blooded dynamic type system underneath the veneer of static type checking. Java's reflection, security, and runtime code generation are also better specified than Lisp's ever were.
Much of Lisp lives on in Java (and its clone, C#). Sure, Java syntax can be a bit pedestrian at times, but look a bit deeper.
Fortran is somewhat more efficient than C++ in many applications. OTOH, Fortran's support (even in the latest versions) for genericity is very limited compared to C++.
However, there is no intrinsic reason for this to be so, as far as I can tell. Fortran's efficiency depends on aliasing restrictions, which could be added to C++ (there have been attempts) without otherwise disturbing C++'s abstraction facilities. Conversely, there is no reason why Fortran's type system couldn't be extended to include C++ templates.
You want a very expressive object system? Great, but you don't get static type checking anymore. You want overloading? Great, but type inference goes out the window. You want fast executables? Sure, but expect to have to tell the compiler in excrutiating detail what you are doing and how you are doing it.
Still, given your feature list, CommonLisp may be your best bet (the CMU CommonLisp implementation for Linux is pretty good). It's a very expressive language and compiles into reasonably good code, although it doesn't have much static type checking, the language definition is messy, C-like performance can be hard to achieve, its C interface is a bit cumbersome, its libraries are less than stellar, and its user community is tiny. Bigloo, a compiler for Scheme, interfaces more nicely with the rest of the world and generates reasonably good code, but lacks threads and has a less expressive object system.
If you want something statically typed, O'Caml is a great language, combining object oriented and functional programming. It generates good code and interfaces reasonably well with C. However, you don't get overloading.
For great libraries, reasonable performance, and good standardization, Java can't be beat, but the language itself can be a little tedious. C# fixes some of the tedium of Java, but its libraries and performance are nowhere near as good yet, and it's pretty much Microsoft-only for now.
And don't forget about C++. For complicated numerical algorithms that need to run fast, there is nothing better than C++. For complicated GUIs, and interactive applications there is almost nothing worse, however.
So, overall, there just isn't a single answer. Every language is an engineering tradeoff. Learn many of them, and you will benefit both from the experience and the choices you have.
Those are probably hyperlinks to resources within the same computer. BT may be claiming hyperlinks among resources distributed across a network. That should be an obvious extension, but "obviousness" is a much harder defense against patent infringement than prior art.
"If I patented a flying machine the patent could equally apply to helicopters and aeroplanes even though they are completely different," explains Stephen Probert deputy director of the Patent Office.
I think this tells you how out of touch the patent office is with the intent of patents. A patent on a "flying machine" should be written in such a way that someone of ordinary skill in the art can build one based on the patent. If the patent teaches you how to build a flying machine, you'll know whether you end up with an airplane or a helicopter (the patent may, of course, contain explicit descriptions of both, in which case you'd know as well).
The notion that a patent can teach someone of ordinary skill how to build the patented invention, yet be so vague that it covers all flying machines is ludicrous, and it's symptomatic of what is wrong with the patent office. You get it here in Probert's own words.
I suspect taht the major cost of providing wired Internet access is the rights-of-way. I don't think that routing data around transformers, even at a cost of a few hundred dollars per transformer, would be a big deal in comparison. Those transformers probably require more maintenance than that over a few years.
Note that the laid off workers seem to be people whose credentials are mostly MBAs, marketing, film-school, "certifications", positions as product managers, etc. Maybe I missed it, but I didn't see one hard-core techie (you know, engineering degree, several years real-world experience in a software/hardware development position) in the article. The closest was a QA person.
That doesn't mean other people aren't qualified or smart, but when jobs are tight, people with lots of experience and credentials get the jobs. Think of it this way: during the dot-com bubble, companies desparately retrained and attracted workers from anywhere they could, but these are likely the first ones to go again.
SprintPCS has a second generation device available, the Samsung SPH-I300. Color display, virtual Grafitti, dual-mode, external connection for hooking up your laptop, full HTML browser, voice recognition, second LCD (for Caller ID), among other features. It's also pretty compact. They also still offer the Kyocera. The Treo isn't bad, it may be "always on-line", and maybe you want GSM for one reason or another, but it doesn't look "revolutionary" to me.
Well, "open code" could mean several things. If it means free software, or Free Software, there is no procurement at all: people inside the government just use it; there is no procurement. By the time procurement happens, most likely, the government IT people have already ruled out free software. Procurement then involves two sides: the government and vendors. The vendors could, of course, involve companies like RedHat.
I don't see a contradiction. The fact that some people refer to some free software as "open source" doesn't imply that all open source software is free software.
Let me try and get this point across again: writing compilers for the Itanium architecture will be a lot harder than writing compilers for other architectures. The reason is that the compilers need to make even more guesses about what kind of parallelism is possible and what instructions can be scheduled together. The programmer can't really help either, since trying to hand-optimize code for VLIW is just too tedious. This will mean that Intel will make the investment, and we will likely get, decent compilers for C/C++, Fortran, Java/JVM, and C#/CLR, but for any other language, it will be even more of an up-hill struggle. And even in those languages where good compilers exist, if you do something that the compiler doesn't quite understand, it may make the wrong assumptions and generate poor code.
Altogether, that can't be good for the industry in the long run. We need more, not less, support for new software architectures and languages. Instruction scheduling and parallelization are things that a processor can handle much easier than a static compiler because the processor can efficiently keep runtime statistics on what a program actually does.
Potentially a better approach to me appears to be hyperthreading, which redefines the problem. No, individual threads won't get very high performance, but code generation is pretty easy, and (unlike VLIW) the programmer can take explicit control of parallelism at a higher level through threads. To me, that seems like an overall better approach.
The main bottleneck of modern microprocessors is, in fact, the extra space and heat produced by the complex logic you defend.
The problem doesn't magically go away by shifting it into software. A static compiler cannot do instruction scheduling and parallelization correctly--you need runtime instrumentation and JITting. The end result is something that likely performs more poorly than if you had let the processor do this.
Nowadays a CISC processor waste more time translating the bytecode and executing the microcode that anything else
CISC vs. RISC has nothing to do with it.
But think : how many compilers was written in the computer history, and how many applications was written with these compilers?
Not nearly enough compilers have been written.
This ratio will prove that it's worth the trade. Of course compilers will be more complex and hard to code, but once that damn thing was done, it was done.
Yes, if you are happy muddling through with C and C++. Itanium will further cement the dominance of languages that we already know to be absolutely lousy from a software engineering point of view, because almost nobody will be able to make the investment to write a competitive compiler for any other language.
The issue is not with Microsoft making available technology and web services that lets people upgrade their machines. The issue is not even with Microsoft turning this on by default. The issue is that Microsoft claims a legal right to do this unconditionally, whether you want it or not, whether you have disabled it or not. And they don't just claim that right for security-related updates but also for verifying license compliance.
Besides, one might well ask why Microsoft is shipping software with gaping security holes in the first place. In 2002, there is no excuse for any company or group to ship software with buffer overrun-related security problems (yes, this also means open source software).
Itanium is built around the notion that many of the hard decisions about how to execute code efficiently should be handled in software (mostly, by compiler back-ends). I think this is not the right direction to go into. It means that every single compiler back-end will have to re-invent the wheel. Most likely, there will only be a small number of compilers that will do a decent job, and a lot of languages won't even try. That's fine if you think the world consists only of a bunch of SPEC benchmarks implemented in C/C++, Fortran, and Java, but it will make life even harder for non-standard languages or non-standard applications. And Itanium's implementation of VLIW seems particularly complex.
Software is by far more costly and complex than processors these days, and we just don't need extra complications in the form of processors that shift even more complexity into software.
I can't pretend to know what a "good" 64bit architecture should look like. But for the time being, something like Alpha or AMD Hammer seems like a better choice to me. And even Intel seems to be reconsidering and keeping a 64bit version of the Pentium as a backup strategy.
It doesn't matter how good it is, it matters whether you can get trained developers for it. Tcl is just not very popular anymore.
Beyond that, in terms of theoretical hits-per-second, that's an overrated metric, of little relevance to real web sites, and most embedded scripting languages will do about the same anyway.
Microsoft needed something like Java to cope with the numerous safety, security, and portability problems they had due to their use of C/C++. Since Microsoft clearly couldn't use Java anymore after the lawsuit, they made their own closest copy and tweaked it in some small ways.
The two languages and runtimes are very similar, and for most applications, the decision which one to use probably depends on whether you are a Microsoft or a Sun shop. For some applications, C# is a little nicer.
In the long run, I hope we won't get stuck with either of these runtimes for too long. Both of them are still fairly limited compared to what modern languages can do. In particular, lack of support for parameterized types and lack of support for efficient functional programming languages, mean that these are clearly not ultimate solutions. Sun is perhaps a bit more honest about this: it's a Java runtime, but if you can make Python or Smalltalk run on it, more power to you. Microsoft is overpromising by calling their runtime "common" or "universal".
C#/.NET is not an open standard either. Microsoft only standardized a small part of C#/.NET, and their actual implementation will be that small, standard core with a vast number of extensions. That means that Microsoft's implementation is the de-facto, proprietary standard, with ECMA being nothing more than a fig leaf.
I don't think we have to wonder much why this company ran into trouble, like so many others. ArsDigita apparently worked reasonably well, and it was one of the first complete systems of its kind. But the company apparently was largely about consulting, and there just isn't that much demand right now. Furthermore, Tcl+Oracle isn't exactly cutting edge technology (I know--it was later converted to Java and other databases). The Internet bubble burst, and it's hard to survive now as a large Internet software vendor even if you have a unique product. And standards have moved on--there are dozens of popular solutions for dynamic database-backed web sites available now. The soap opera we hear about seems more like a symptom than a cause. I suspect, though, that when all is said and done, the founders probably made out alright.
Slashdot Mirror
The inventors of the transistor would have predicted it. The transistor was quite explicitly intended as a replacement for bulky vacuum tubes with inconvenient power requirements, and that's how we are using them.
I really appreciate the work that Barak has done with and on Mosix. But I also find it kind of odd that Mosix could be the "property" of one individual. I would assume that it was developed with public research grants and while the author was employed at a university. Graduate students probably have also contributed, and there probably have been bug fixes as well. So, maybe it isn't bad if there is a GPL'ed distribution of Mosix after all. The GPL regulates issues of ownership rather well.
As for a user-space implementation of Mosix, I think that makes sense, although it has its drawbacks as well. One of the problems with user-space implementations is that they tend to be less than transparent in practice. It also strikes me as somewhat redundant, since Condor has already gone the user space route. A userland Mosix would only make sense if it were free and open source (as opposed to Condor).
Altogether, I hope people won't get too upset at each other over this. Mosix is great stuff and Barak and his university have been generous in making it available freely up to this point.
Yes, the West needs to do more, in particular since Western culture and Western politics are so dominant now. Yes, the harm that the West is doing is probably bigger in magnitude than that of any society before it because it has been magnified by technology. But, in terms of corruption and goals, Western society isn't any worse than most other societies have been traditionally. In fact, if anything, the West is more aware of the problems and actively, rationally, and consciously trying to address them, something that cannot be said of most of the societies that preceded Western societies.
Writing user interfaces in C or C++ is an absolutely dreadful process (although C and C++ are good for other applications). But if you use the right languages and toolkits, it becomes a lot easier. I like Python with Tk or wxWindows. Smalltalk (Squeak) is also quite nice, but a bit hard to deliver. Java/Swing is almost as tedious as C++, but at least the toolkit is very complete and there are lots of third party libraries that help you and that all work together.
Have people forgotten Watergate? In the US, every political party has been spying on the other, and if they happened to be in power, they were using the powers of the state to do so. Now, do you really believe that that has stopped? I suspect it has just gotten more sophisticated (I mean, Nixon was just plain stupid). And there are so many more possibilities now: a lot of intelligence work has been "privatized" and therefore has been freed of many pesky government regulations, and the US government can always outsource to foreign intelligence services and say "the French did it".
Much of Lisp lives on in Java (and its clone, C#). Sure, Java syntax can be a bit pedestrian at times, but look a bit deeper.
However, there is no intrinsic reason for this to be so, as far as I can tell. Fortran's efficiency depends on aliasing restrictions, which could be added to C++ (there have been attempts) without otherwise disturbing C++'s abstraction facilities. Conversely, there is no reason why Fortran's type system couldn't be extended to include C++ templates.
Still, given your feature list, CommonLisp may be your best bet (the CMU CommonLisp implementation for Linux is pretty good). It's a very expressive language and compiles into reasonably good code, although it doesn't have much static type checking, the language definition is messy, C-like performance can be hard to achieve, its C interface is a bit cumbersome, its libraries are less than stellar, and its user community is tiny. Bigloo, a compiler for Scheme, interfaces more nicely with the rest of the world and generates reasonably good code, but lacks threads and has a less expressive object system.
If you want something statically typed, O'Caml is a great language, combining object oriented and functional programming. It generates good code and interfaces reasonably well with C. However, you don't get overloading.
For great libraries, reasonable performance, and good standardization, Java can't be beat, but the language itself can be a little tedious. C# fixes some of the tedium of Java, but its libraries and performance are nowhere near as good yet, and it's pretty much Microsoft-only for now.
And don't forget about C++. For complicated numerical algorithms that need to run fast, there is nothing better than C++. For complicated GUIs, and interactive applications there is almost nothing worse, however.
So, overall, there just isn't a single answer. Every language is an engineering tradeoff. Learn many of them, and you will benefit both from the experience and the choices you have.
Those are probably hyperlinks to resources within the same computer. BT may be claiming hyperlinks among resources distributed across a network. That should be an obvious extension, but "obviousness" is a much harder defense against patent infringement than prior art.
I think this tells you how out of touch the patent office is with the intent of patents. A patent on a "flying machine" should be written in such a way that someone of ordinary skill in the art can build one based on the patent. If the patent teaches you how to build a flying machine, you'll know whether you end up with an airplane or a helicopter (the patent may, of course, contain explicit descriptions of both, in which case you'd know as well).
The notion that a patent can teach someone of ordinary skill how to build the patented invention, yet be so vague that it covers all flying machines is ludicrous, and it's symptomatic of what is wrong with the patent office. You get it here in Probert's own words.
I suspect taht the major cost of providing wired Internet access is the rights-of-way. I don't think that routing data around transformers, even at a cost of a few hundred dollars per transformer, would be a big deal in comparison. Those transformers probably require more maintenance than that over a few years.
That doesn't mean other people aren't qualified or smart, but when jobs are tight, people with lots of experience and credentials get the jobs. Think of it this way: during the dot-com bubble, companies desparately retrained and attracted workers from anywhere they could, but these are likely the first ones to go again.
SprintPCS has a second generation device available, the Samsung SPH-I300. Color display, virtual Grafitti, dual-mode, external connection for hooking up your laptop, full HTML browser, voice recognition, second LCD (for Caller ID), among other features. It's also pretty compact. They also still offer the Kyocera. The Treo isn't bad, it may be "always on-line", and maybe you want GSM for one reason or another, but it doesn't look "revolutionary" to me.
Well, "open code" could mean several things. If it means free software, or Free Software, there is no procurement at all: people inside the government just use it; there is no procurement. By the time procurement happens, most likely, the government IT people have already ruled out free software. Procurement then involves two sides: the government and vendors. The vendors could, of course, involve companies like RedHat.
I'm pretty sure there were several free, real-time strategy games for UNIX workstations before 1989, some of them even multiuser.
I don't see a contradiction. The fact that some people refer to some free software as "open source" doesn't imply that all open source software is free software.
Altogether, that can't be good for the industry in the long run. We need more, not less, support for new software architectures and languages. Instruction scheduling and parallelization are things that a processor can handle much easier than a static compiler because the processor can efficiently keep runtime statistics on what a program actually does.
Potentially a better approach to me appears to be hyperthreading, which redefines the problem. No, individual threads won't get very high performance, but code generation is pretty easy, and (unlike VLIW) the programmer can take explicit control of parallelism at a higher level through threads. To me, that seems like an overall better approach.
The problem doesn't magically go away by shifting it into software. A static compiler cannot do instruction scheduling and parallelization correctly--you need runtime instrumentation and JITting. The end result is something that likely performs more poorly than if you had let the processor do this.
Nowadays a CISC processor waste more time translating the bytecode and executing the microcode that anything else
CISC vs. RISC has nothing to do with it.
But think : how many compilers was written in the computer history, and how many applications was written with these compilers?
Not nearly enough compilers have been written.
This ratio will prove that it's worth the trade. Of course compilers will be more complex and hard to code, but once that damn thing was done, it was done.
Yes, if you are happy muddling through with C and C++. Itanium will further cement the dominance of languages that we already know to be absolutely lousy from a software engineering point of view, because almost nobody will be able to make the investment to write a competitive compiler for any other language.
Besides, one might well ask why Microsoft is shipping software with gaping security holes in the first place. In 2002, there is no excuse for any company or group to ship software with buffer overrun-related security problems (yes, this also means open source software).
Software is by far more costly and complex than processors these days, and we just don't need extra complications in the form of processors that shift even more complexity into software.
I can't pretend to know what a "good" 64bit architecture should look like. But for the time being, something like Alpha or AMD Hammer seems like a better choice to me. And even Intel seems to be reconsidering and keeping a 64bit version of the Pentium as a backup strategy.
Beyond that, in terms of theoretical hits-per-second, that's an overrated metric, of little relevance to real web sites, and most embedded scripting languages will do about the same anyway.
The two languages and runtimes are very similar, and for most applications, the decision which one to use probably depends on whether you are a Microsoft or a Sun shop. For some applications, C# is a little nicer.
In the long run, I hope we won't get stuck with either of these runtimes for too long. Both of them are still fairly limited compared to what modern languages can do. In particular, lack of support for parameterized types and lack of support for efficient functional programming languages, mean that these are clearly not ultimate solutions. Sun is perhaps a bit more honest about this: it's a Java runtime, but if you can make Python or Smalltalk run on it, more power to you. Microsoft is overpromising by calling their runtime "common" or "universal".
C#/.NET is not an open standard either. Microsoft only standardized a small part of C#/.NET, and their actual implementation will be that small, standard core with a vast number of extensions. That means that Microsoft's implementation is the de-facto, proprietary standard, with ECMA being nothing more than a fig leaf.
I don't think we have to wonder much why this company ran into trouble, like so many others. ArsDigita apparently worked reasonably well, and it was one of the first complete systems of its kind. But the company apparently was largely about consulting, and there just isn't that much demand right now. Furthermore, Tcl+Oracle isn't exactly cutting edge technology (I know--it was later converted to Java and other databases). The Internet bubble burst, and it's hard to survive now as a large Internet software vendor even if you have a unique product. And standards have moved on--there are dozens of popular solutions for dynamic database-backed web sites available now. The soap opera we hear about seems more like a symptom than a cause. I suspect, though, that when all is said and done, the founders probably made out alright.
Well, if you had bought it, you wouldn't have tripped the alarm, now would you? :-)