Of course you could say 'stick to stable and you won't have those problems', but debian stable is not something most people will want. [...] I have yet to do an apt-get upgrade where there weren't broken packages. Knoppix sets apt to 'testing', but it appears that they mix 'unstable' in the distro.
Actually, I'd say "stick to unstable" and immediately replace whatever is in Knoppix's apt sources with the Debian unstable sources, then update and dist-upgrade your system.
If you are having problems with KDE, a simple way of fixing them is to do an "apt-get remove --purge libqt", followed by an "apt-get install kde" (since I don't use KDE, I usually omit the second step).
but I have never gotten a usuable install from pure Debian.
Well, I haven't either, but in some cases, that has just been because I gave up in frustration.
To be clear, Knoppix could be improved as a Debian installer, but I think it is already so useful for that purpose by accident that Debian should really build on that success. Maybe they could work with Knoppix to iron out any problems with package naming/dependencies.
For specific games: nethack, netrek, conquest, omega, xconq, FreeCiv, and versions of mazewar come to mind. There have also been tank simulations, MUDs, flight simulators, and several other conquest/strategy games.
And, of course, there are lots of little puzzles that have been around forever (the UNIX equivalents of minesweeper, I suppose).
I'm curious as to why they are using Neural Networks for this application? In the last 10 years or so, most machine learning applications have moved away from Neural Networks to more mathematically based models such as Support Vector Machines, a generative model (e.g. Naive Bayes), or some kind of Ensemble Method (e.g. Boosting).
I challenge you to give a mathematical justification of why you think that support vector machines would be better in this application than neural networks. While SVM papers fill their pages with even more mathematical drivel than neural network papers, ultimately, I have never seen such a justification.
Both methods are, in effect, closely related heuristic methods with little connection to the underlying problem being solved, and you pick one or the other based on which one works best with the amount of hassle you are willing to put up with for training and validation.
I'd look for a paper to come out soon that improves the accuracy by using SVM.
Sure, there will be such papers. If enough monkeys apply enough methods to enough problems, they'll always come up with something that proves that their pet method is better than anybody else's.
I suspect they used NN because the Matlab toolkit made it easy or someone in research hasn't kept up.
While I won't comment any more on the SVM/NN issue, where it is hard to call a winner on theoretical grounds and all we have to rely on is the fervor with which different people have applied them, your recommendation of Naive Bayesian methods really reveals how shallow your view of the world is. Not only are Naive Bayesian statistical models old (probably more than a century old), they just don't work well on many real-world problems, and the reasons why they don't are easy to understand theoretically. People used to use them as a straw man against which to compare other methods. The only reason Naive Bayesian methods have received positive coverage at all recently is because they happen to work well on the spam problem. And, as I was saying, they are actually equivalent to single layer neural network models, so portraying them as a "more modern" alternative to neural networks makes no sense.
People like you should "keep up" on the basics of statistics and pattern recognition, do some thinking of their own, and stop judging things by labels that happen to be currently fashionable. Unfortunately, as shallow as your view is, it is also very common.
What matters is that he and his companies designed software that way. Whether he actually uttered those exact works or not makes little difference.
What this is really about is the question of whether the man and the company reached their current position through technical competence or through business acumen and luck. I think it's pretty clear that it's the latter.
Sure there is another way: sustained, long-term open source game development. A number of very successful games have been developed that way.
You get different games that way from the commercial stuff, of course: because these kinds of games are developed over many years, they only survive if they are replayable. Because developers are also players, the games get improved and problems get eliminated over time.
Oh, and, of course, it's not a career choice. Open source games are for fun, both fun playing them and fun developing them.
We know how to make WiFi secure: with secure protocols and encryption. When the responsible standards bodies don't screw up badly (as they did with 802.11), it works fine. A somewhat directional antenna may or may not increase security slightly, but not at an interesting cost/performance ratio. If you really want additional security at the physical level, use laser or even quantum communications.
This company has a solution in search of a problem, and they are trying to drum up businesses. Plasma antennas are interesting for 1960's style radio transmissions and stealth, but they have little significance to 21st century wireless communications.
What's ironic about all of this is that there is nothing innovative or novel about either XAML or WinFS. Those are old ideas that have been tried over and over again.
Sure, Microsoft may keep taking patents out on their specific implementations. Sure, they may even sue people for building compatible implementations. What difference does that make?
When I write Linux code, I already can't interoperate with Microsoft GUIs on Windows and NTFS access from Linux still hasn't been declared reliable.
Stop worrying about this stuff publicly--it only elevates Microsoft's long term strategy to a level of importance it doesn't deserve.
I'm pretty sure all of the major UNIX source level C debuggers (sdb, dbx, gdb) have supported watchpoints since early on. UPS (also from the 1980's) had a complete C interpreter in it, which you could not only use for watch points, but to insert arbitrary C code. Purify let you set data breakpoints using memory management hardware since early on. The feature is somewhat hard to support in C/C++ because it is either slow or requires hardware support.
But C is really so far behind technologically that it took it a long time to catch up. Systems like Smalltalk-80, CommonLisp, and Prolog, all commercially available in the early 1980's, not only let you set arbitrary data-dependent breakpoints, they let you change your source code while debugging and have your changes reflected in the running program. With the rise of C/C++, all that was forgotten, and people like you now think that it was all invented yesterday.
You bet it would be forked by Tuesday. And those forks would survive in the real world if and only if they are actually more useful to users than Sun's version. That's, of course, what Sun is afraid of: they know they can't compete if they are forced to compete freely.
Of course, Java has already forked: that's what Kaffe, gcj, and C# are. C# will probably take over from Java in the open source world: it's less restrictive and it's technically superior.
I am all for buying hardware where the vendor guarantees Linux compatibility. I think the main reason people claim that Windows is "easier to maintain" these days is because they compare laptops with Windows pre-installed to oddball laptops on which Linux needs to be installed by hand.
But there are plenty of laptops that run Linux well, and there are plenty of companies that pre-install those laptops with Linux (your choice of distribution) and guarantee that it works. So, I wouldn't really put too much stake in this one review either way.
You mean you didn't carefully look at it, and then you didn't see where the problems were, don't you?
No, I mean that I have installed half a dozen machines that way, used them extensively, and never experienced any problem due to Knoppix. Installs using the Debian installer have always been much more of a headache.
do you really think any of those packages are going to be upgraded on a dist-upgrade? Do you really think anyone of them is going to be deleted due to an asked dependency (pointing to "real" Debian) on an upgrade? What do you think will happen when both foo and foo-knoppix are installed in the same machine?
The right thing seems to be happening normally. After all, the Knoppix installer is there for installing this thing. If you really need to get rid of a knoppix package by hand, it's easy to find them all and replace them with their Debian equivalents, automatically even if you like.
Besides, if there were problems, then Debian could work with Knoppix to solve them to make Knoppix an even better installer for Debian.
I think the fact that the best test case the ODB writer could come up with was running it on itself suggests that he actually hasn't tested it on a lot of real-world software.
I also disagree with your assertion that all situations where experienced programmers need a debugger involve lots of code and large amounts of data. The former is most of the time true, but latter isn't necessarily.
I didn't exactly say "all situations". But tools that only work occasionally are also just not worth bothering with: it's more work to learn the tool and keep it working than just to solve the problem the old-fashioned way.
My point is simply the following: don't expect too much from this. I have used systems with this capability for many years, and I have never found it to be more than a curiosity.
Then where is the state of the art, if not in commercial apps (or commercially-backed ones like Eclipse)?
Sorry, you're right, taken literally, what I said doesn't make much sense.
What I meant was that the currently big and commercial platforms (Windows, Macintosh, Java) are still behind what was already available commercially 10-20 years ago, although it wasn't very successful back then.
The reason why it's successful now and wasn't back then is because programmers in industry didn't understand they needed it back then. Programmers in industry have slowly been learning: object-oriented programming, garbage collection, dynamic loading, reflection, etc. The development of popular platforms simply reflects the state of education and understanding of the great mass of programmers. But the state of the art represents what is actually available if you only know that you need it.
That sounds cool, but it isn't all that useful in practice. Debuggers that support stepping backwards usually end up keeping a lot of state around, which limits them to fairly small, well-defined problems or modules. But the problems where an experienced programmers need a debugger are just the opposite: they involve lots of code and large amounts of data.
Usually, it's best to avoid going back and forth through the code altogether; insert assertions and see which ones fail.
There has been almost nothing new in programming environments or debuggers over the last 10-20 years.
Almost those features you see in Visual C++, Visual Studio.NET, Eclipse, NetBeans, etc. have been around in IDEs since the 1980's. Debuggers have allowed you to step forwards and backwards, see the source code, examine data structures graphically, and modify the running source code for about as long.
If anything, current commercial IDEs and debuggers still haven't caught up to the state of the art.
Comparing the "state" of multiple implementations or versions of code is an old technique. You don't need a special debugger for it--you can use a regular debugger and a tiny bit of glue code. Alternatively, you can insert the debugging code using aspects (aspectj.org).
However, like many programming techniques, most real world programmers won't know about them unless they can shell out $1000 for a tool; reading a paper or book just would be too much intellectual challenge, right?
This news item seems to be a thinly veiled attempt to drum up business for that company.
Only if you have been living under a rock. Most languages and compilers other than C and C++ have been doing that forever. Even C and C++ allowed you to get a complete backtrace and inspect the complete program state from a core file (software bloat has made more and more people turn off that feature, however).
I have seen someone doing a knoppix hd install only to get lots of package dependency problems because (I think) some important packages are not standard debian packages. Better use some time on the real debian installer.
I have not seen any serious problems. There are some small differences, but they don't seem to hurt anything, at least not after dist-upgrading the machine. Overall, Knoppix-based installs have been much less work than "real" Debian installs in my experience, and that's ultimately what counts.
The problem with Knoppix is that it doesnt fit the "Universal Operating System" style of Debian.
And what does that mean? Does that make Knoppix any less of an excellent installer?
With Knoppix it would take me a lot of time just to uninstall packages I wouldn't use.
As with many other Linux desktop installations. However, with apt, it's easy to get rid of large chunks of functionality at once; for example, to remove KDE, just get rid of Qt. To get rid of the GUI, get rid of xlib and the X server.
Knoppix is great for desktops but it's not the best for everyone.
There is no "best" solution for everyone. Debian should recognize that and live with multiple installers.
A good choice would be to work with Knoppix or Gnoppix to make it an even better installer for desktop users, and separately develop a text-based "universal" installer.
fail to meet Debian's strict standards. The installer must operate on all of Debian's supported architectures.
Yes, Debian has some strict standards. Yes, it is good if they work on a universal installer that conforms to strict standards.
None of that makes Knoppix any less of an excellent installer for Debian. The Debian project should be announcing Knoppix and other live CDs prominently on their home page, rather than creating the impression that there are no finished installers.
If i386 with a CD drive is what you've got then Knoppix is for you.
Yes, like 95% of Debian users.
But don't ever think that it can be the installer for Debian. It just isn't up for the challenge.
The notion that there should be "the installer" is itself flawed. Many different people need many different kinds of installers.
MPEG-4 Part 10 (AVC or H.264) is in no way mediocre or obsolete. It just hasn't got any implementations:(
H.264 is just more of the same stuff: limited choices of block sizes, DCT, and all that. It's incrementalism. Nothing wrong with that, but that shouldn't keep us from moving into the future. Codecs like Dirac promise to give us capabilities that you simply can't squeeze out of the MPEG line (not the least of which is that it may be patent-free).
Actually, there is an excellent Debian installer out, and it's been out for a while. It's called Knoppix. You can test compatibility at the store by booting into it, get a live preview of everything, and install a complete system with a recent set of packages with one command. While it uses KDE by default, it's easy to switch to Gnome.
Something else? What would you suggest that runs on virtually all platforms? No, "just use linux" is not an answer. Linux is way too X86 centric.
If you need cross-platform tools, there are plenty of excellent languages and libraries you can use. None of them provide single-stop shopping for cross-platform computing, but neither does Java, despite Sun's marketing claims to the contrary.
But Java's dirty little secret is that most people really don't have much use for Java-style cross-platform computing. If they need to develop cross-platform apps, something like C++ with Qt or C++ with wxWindows (which require recompilation but otherwise give you identical source code across platforms) satisfies all their requirements and yields applications that actually work better on each platform.
In any case, C# is an excellent replacement for Java. Technically, it is just like Java only with some annoyances fixed. And you can write cross-platform code in it, or you can write platform specific code in it--it's your choice.
It's pretty clear what Sun didn't like about standards bodies.
While those standards bodies don't necessarily require a standard to be freely implementable, they usually require reasonable-and-non-discriminatory (RAND) licensing, and they require disclosure of all intellectual property by members. That mean that compatibility testing by Sun would have been out. And Sun would either have had to state a schedule of licensing fees for Java, which would have demonstrated immediately that the standard is not open, or put their intellectual property in the public domain, which they didn't want.
Sun couldn't work with any of those standards bodies because the whole purpose of a standards body is to guarantee precisely what Sun didn't want: the purpose of standards bodies is to transfer control of a standard away from the company that created it.
If sun DOES go out of business, they will not simply disappear one morning, with all their code and contracts and such gone. This ain't a rug seller store on main st. And parts will be spun off or sold before they entirely tank.
Yes, and it is anybody's guess who will be the new owner of Java. Will it be IBM? Well, that wouldn't be bad--they'll probably just do what Sun should have done from the start.
But it could be Microsoft, or some Microsoft-friendly company, or it could be some company like SCO that starts suing everybody who has ever downloaded Sun's source code or one of Sun's "unpublished specifications" (JCP), or it could get spun off into some small company that jacks up the consulting fees.
We wouldn't even have to think about that possibility if Java were an open standard and there were independent implementations of it (commercial and/or free, it doesn't matter).
This is not about open source, it's about a failing company trying to keep control of a proprietary standard for their own gain, and that's a dangerous combination for users.
recall too that SGI, Apple and BSD have been going away for well over 10 years.
Well, you are kind of making my point for me: SGI's own software can hardly be called a future-oriented platform and Apple threw out their old OS and is supporting it only through a compatibility layer.
With BSD, on the other hand, people don't have to worry because it is open source.
Slashdot Mirror
Of course you could say 'stick to stable and you won't have those problems', but debian stable is not something most people will want. [...] I have yet to do an apt-get upgrade where there weren't broken packages. Knoppix sets apt to 'testing', but it appears that they mix 'unstable' in the distro.
Actually, I'd say "stick to unstable" and immediately replace whatever is in Knoppix's apt sources with the Debian unstable sources, then update and dist-upgrade your system.
If you are having problems with KDE, a simple way of fixing them is to do an "apt-get remove --purge libqt", followed by an "apt-get install kde" (since I don't use KDE, I usually omit the second step).
but I have never gotten a usuable install from pure Debian.
Well, I haven't either, but in some cases, that has just been because I gave up in frustration.
To be clear, Knoppix could be improved as a Debian installer, but I think it is already so useful for that purpose by accident that Debian should really build on that success. Maybe they could work with Knoppix to iron out any problems with package naming/dependencies.
For specific games: nethack, netrek, conquest, omega, xconq, FreeCiv, and versions of mazewar come to mind. There have also been tank simulations, MUDs, flight simulators, and several other conquest/strategy games.
And, of course, there are lots of little puzzles that have been around forever (the UNIX equivalents of minesweeper, I suppose).
I'm curious as to why they are using Neural Networks for this application? In the last 10 years or so, most machine learning applications have moved away from Neural Networks to more mathematically based models such as Support Vector Machines, a generative model (e.g. Naive Bayes), or some kind of Ensemble Method (e.g. Boosting).
I challenge you to give a mathematical justification of why you think that support vector machines would be better in this application than neural networks. While SVM papers fill their pages with even more mathematical drivel than neural network papers, ultimately, I have never seen such a justification.
Both methods are, in effect, closely related heuristic methods with little connection to the underlying problem being solved, and you pick one or the other based on which one works best with the amount of hassle you are willing to put up with for training and validation.
I'd look for a paper to come out soon that improves the accuracy by using SVM.
Sure, there will be such papers. If enough monkeys apply enough methods to enough problems, they'll always come up with something that proves that their pet method is better than anybody else's.
I suspect they used NN because the Matlab toolkit made it easy or someone in research hasn't kept up.
While I won't comment any more on the SVM/NN issue, where it is hard to call a winner on theoretical grounds and all we have to rely on is the fervor with which different people have applied them, your recommendation of Naive Bayesian methods really reveals how shallow your view of the world is. Not only are Naive Bayesian statistical models old (probably more than a century old), they just don't work well on many real-world problems, and the reasons why they don't are easy to understand theoretically. People used to use them as a straw man against which to compare other methods. The only reason Naive Bayesian methods have received positive coverage at all recently is because they happen to work well on the spam problem. And, as I was saying, they are actually equivalent to single layer neural network models, so portraying them as a "more modern" alternative to neural networks makes no sense.
People like you should "keep up" on the basics of statistics and pattern recognition, do some thinking of their own, and stop judging things by labels that happen to be currently fashionable. Unfortunately, as shallow as your view is, it is also very common.
What matters is that he and his companies designed software that way. Whether he actually uttered those exact works or not makes little difference.
What this is really about is the question of whether the man and the company reached their current position through technical competence or through business acumen and luck. I think it's pretty clear that it's the latter.
Sure there is another way: sustained, long-term open source game development. A number of very successful games have been developed that way.
You get different games that way from the commercial stuff, of course: because these kinds of games are developed over many years, they only survive if they are replayable. Because developers are also players, the games get improved and problems get eliminated over time.
Oh, and, of course, it's not a career choice. Open source games are for fun, both fun playing them and fun developing them.
We know how to make WiFi secure: with secure protocols and encryption. When the responsible standards bodies don't screw up badly (as they did with 802.11), it works fine. A somewhat directional antenna may or may not increase security slightly, but not at an interesting cost/performance ratio. If you really want additional security at the physical level, use laser or even quantum communications.
This company has a solution in search of a problem, and they are trying to drum up businesses. Plasma antennas are interesting for 1960's style radio transmissions and stealth, but they have little significance to 21st century wireless communications.
What's ironic about all of this is that there is nothing innovative or novel about either XAML or WinFS. Those are old ideas that have been tried over and over again.
Sure, Microsoft may keep taking patents out on their specific implementations. Sure, they may even sue people for building compatible implementations. What difference does that make?
When I write Linux code, I already can't interoperate with Microsoft GUIs on Windows and NTFS access from Linux still hasn't been declared reliable.
Stop worrying about this stuff publicly--it only elevates Microsoft's long term strategy to a level of importance it doesn't deserve.
I'm pretty sure all of the major UNIX source level C debuggers (sdb, dbx, gdb) have supported watchpoints since early on. UPS (also from the 1980's) had a complete C interpreter in it, which you could not only use for watch points, but to insert arbitrary C code. Purify let you set data breakpoints using memory management hardware since early on. The feature is somewhat hard to support in C/C++ because it is either slow or requires hardware support.
But C is really so far behind technologically that it took it a long time to catch up. Systems like Smalltalk-80, CommonLisp, and Prolog, all commercially available in the early 1980's, not only let you set arbitrary data-dependent breakpoints, they let you change your source code while debugging and have your changes reflected in the running program. With the rise of C/C++, all that was forgotten, and people like you now think that it was all invented yesterday.
You bet it would be forked by Tuesday. And those forks would survive in the real world if and only if they are actually more useful to users than Sun's version. That's, of course, what Sun is afraid of: they know they can't compete if they are forced to compete freely.
Of course, Java has already forked: that's what Kaffe, gcj, and C# are. C# will probably take over from Java in the open source world: it's less restrictive and it's technically superior.
I am all for buying hardware where the vendor guarantees Linux compatibility. I think the main reason people claim that Windows is "easier to maintain" these days is because they compare laptops with Windows pre-installed to oddball laptops on which Linux needs to be installed by hand.
But there are plenty of laptops that run Linux well, and there are plenty of companies that pre-install those laptops with Linux (your choice of distribution) and guarantee that it works. So, I wouldn't really put too much stake in this one review either way.
You mean you didn't carefully look at it, and then you didn't see where the problems were, don't you?
No, I mean that I have installed half a dozen machines that way, used them extensively, and never experienced any problem due to Knoppix. Installs using the Debian installer have always been much more of a headache.
do you really think any of those packages are going to be upgraded on a dist-upgrade? Do you really think anyone of them is going to be deleted due to an asked dependency (pointing to "real" Debian) on an upgrade? What do you think will happen when both foo and foo-knoppix are installed in the same machine?
The right thing seems to be happening normally. After all, the Knoppix installer is there for installing this thing. If you really need to get rid of a knoppix package by hand, it's easy to find them all and replace them with their Debian equivalents, automatically even if you like.
Besides, if there were problems, then Debian could work with Knoppix to solve them to make Knoppix an even better installer for Debian.
I think the fact that the best test case the ODB writer could come up with was running it on itself suggests that he actually hasn't tested it on a lot of real-world software.
I also disagree with your assertion that all situations where experienced programmers need a debugger involve lots of code and large amounts of data. The former is most of the time true, but latter isn't necessarily.
I didn't exactly say "all situations". But tools that only work occasionally are also just not worth bothering with: it's more work to learn the tool and keep it working than just to solve the problem the old-fashioned way.
My point is simply the following: don't expect too much from this. I have used systems with this capability for many years, and I have never found it to be more than a curiosity.
Then where is the state of the art, if not in commercial apps (or commercially-backed ones like Eclipse)?
Sorry, you're right, taken literally, what I said doesn't make much sense.
What I meant was that the currently big and commercial platforms (Windows, Macintosh, Java) are still behind what was already available commercially 10-20 years ago, although it wasn't very successful back then.
The reason why it's successful now and wasn't back then is because programmers in industry didn't understand they needed it back then. Programmers in industry have slowly been learning: object-oriented programming, garbage collection, dynamic loading, reflection, etc. The development of popular platforms simply reflects the state of education and understanding of the great mass of programmers. But the state of the art represents what is actually available if you only know that you need it.
That sounds cool, but it isn't all that useful in practice. Debuggers that support stepping backwards usually end up keeping a lot of state around, which limits them to fairly small, well-defined problems or modules. But the problems where an experienced programmers need a debugger are just the opposite: they involve lots of code and large amounts of data.
Usually, it's best to avoid going back and forth through the code altogether; insert assertions and see which ones fail.
There has been almost nothing new in programming environments or debuggers over the last 10-20 years.
Almost those features you see in Visual C++, Visual Studio.NET, Eclipse, NetBeans, etc. have been around in IDEs since the 1980's. Debuggers have allowed you to step forwards and backwards, see the source code, examine data structures graphically, and modify the running source code for about as long.
If anything, current commercial IDEs and debuggers still haven't caught up to the state of the art.
Comparing the "state" of multiple implementations or versions of code is an old technique. You don't need a special debugger for it--you can use a regular debugger and a tiny bit of glue code. Alternatively, you can insert the debugging code using aspects (aspectj.org).
However, like many programming techniques, most real world programmers won't know about them unless they can shell out $1000 for a tool; reading a paper or book just would be too much intellectual challenge, right?
This news item seems to be a thinly veiled attempt to drum up business for that company.
Java Exceptions *were* a revolution in debugging.
Only if you have been living under a rock. Most languages and compilers other than C and C++ have been doing that forever. Even C and C++ allowed you to get a complete backtrace and inspect the complete program state from a core file (software bloat has made more and more people turn off that feature, however).
I have seen someone doing a knoppix hd install only to get lots of package dependency problems because (I think) some important packages are not standard debian packages. Better use some time on the real debian installer.
I have not seen any serious problems. There are some small differences, but they don't seem to hurt anything, at least not after dist-upgrading the machine. Overall, Knoppix-based installs have been much less work than "real" Debian installs in my experience, and that's ultimately what counts.
The problem with Knoppix is that it doesnt fit the "Universal Operating System" style of Debian.
And what does that mean? Does that make Knoppix any less of an excellent installer?
With Knoppix it would take me a lot of time just to uninstall packages I wouldn't use.
As with many other Linux desktop installations. However, with apt, it's easy to get rid of large chunks of functionality at once; for example, to remove KDE, just get rid of Qt. To get rid of the GUI, get rid of xlib and the X server.
Knoppix is great for desktops but it's not the best for everyone.
There is no "best" solution for everyone. Debian should recognize that and live with multiple installers.
A good choice would be to work with Knoppix or Gnoppix to make it an even better installer for desktop users, and separately develop a text-based "universal" installer.
fail to meet Debian's strict standards. The installer must operate on all of Debian's supported architectures.
Yes, Debian has some strict standards. Yes, it is good if they work on a universal installer that conforms to strict standards.
None of that makes Knoppix any less of an excellent installer for Debian. The Debian project should be announcing Knoppix and other live CDs prominently on their home page, rather than creating the impression that there are no finished installers.
If i386 with a CD drive is what you've got then Knoppix is for you.
Yes, like 95% of Debian users.
But don't ever think that it can be the installer for Debian. It just isn't up for the challenge.
The notion that there should be "the installer" is itself flawed. Many different people need many different kinds of installers.
MPEG-4 Part 10 (AVC or H.264) is in no way mediocre or obsolete. It just hasn't got any implementations :(
H.264 is just more of the same stuff: limited choices of block sizes, DCT, and all that. It's incrementalism. Nothing wrong with that, but that shouldn't keep us from moving into the future. Codecs like Dirac promise to give us capabilities that you simply can't squeeze out of the MPEG line (not the least of which is that it may be patent-free).
Actually, there is an excellent Debian installer out, and it's been out for a while. It's called Knoppix. You can test compatibility at the store by booting into it, get a live preview of everything, and install a complete system with a recent set of packages with one command. While it uses KDE by default, it's easy to switch to Gnome.
Something else? What would you suggest that runs on virtually all platforms? No, "just use linux" is not an answer. Linux is way too X86 centric.
If you need cross-platform tools, there are plenty of excellent languages and libraries you can use. None of them provide single-stop shopping for cross-platform computing, but neither does Java, despite Sun's marketing claims to the contrary.
But Java's dirty little secret is that most people really don't have much use for Java-style cross-platform computing. If they need to develop cross-platform apps, something like C++ with Qt or C++ with wxWindows (which require recompilation but otherwise give you identical source code across platforms) satisfies all their requirements and yields applications that actually work better on each platform.
In any case, C# is an excellent replacement for Java. Technically, it is just like Java only with some annoyances fixed. And you can write cross-platform code in it, or you can write platform specific code in it--it's your choice.
It's pretty clear what Sun didn't like about standards bodies.
While those standards bodies don't necessarily require a standard to be freely implementable, they usually require reasonable-and-non-discriminatory (RAND) licensing, and they require disclosure of all intellectual property by members. That mean that compatibility testing by Sun would have been out. And Sun would either have had to state a schedule of licensing fees for Java, which would have demonstrated immediately that the standard is not open, or put their intellectual property in the public domain, which they didn't want.
Sun couldn't work with any of those standards bodies because the whole purpose of a standards body is to guarantee precisely what Sun didn't want: the purpose of standards bodies is to transfer control of a standard away from the company that created it.
If sun DOES go out of business, they will not simply disappear one morning, with all their code and contracts and such gone. This ain't a rug seller store on main st. And parts will be spun off or sold before they entirely tank.
Yes, and it is anybody's guess who will be the new owner of Java. Will it be IBM? Well, that wouldn't be bad--they'll probably just do what Sun should have done from the start.
But it could be Microsoft, or some Microsoft-friendly company, or it could be some company like SCO that starts suing everybody who has ever downloaded Sun's source code or one of Sun's "unpublished specifications" (JCP), or it could get spun off into some small company that jacks up the consulting fees.
We wouldn't even have to think about that possibility if Java were an open standard and there were independent implementations of it (commercial and/or free, it doesn't matter).
This is not about open source, it's about a failing company trying to keep control of a proprietary standard for their own gain, and that's a dangerous combination for users.
recall too that SGI, Apple and BSD have been going away for well over 10 years.
Well, you are kind of making my point for me: SGI's own software can hardly be called a future-oriented platform and Apple threw out their old OS and is supporting it only through a compatibility layer.
With BSD, on the other hand, people don't have to worry because it is open source.