Because it means that file name equality translates into file identity; not having that guarantee complicates software in subtle ways. Besides, how do you propose to generalize that to other languages? Are file names written in katakana and hiragana identical? What about file names written in kanji and the same file name spelled out in hiragana? File names using the same Chinese and Japanese character?
Furthermore, yes, software does rely on it. Even just untarring a UNIX archive on OS X can break it, like if it contains "Makefile" and "makefile".
A journaling file system is actually primarily useful for laptop users: it insulates laptops and external devices on laptops from power failures and other things that happen to laptops.
On servers, despite its popularity, journaling makes much less sense: there are better ways to recover from failures, and the performance hit really does matter.
I'm sorry, I can't get particularly excited about the fine differences between these different systems or these claims of "innovation". We are talking "digital video recorder"--a box with a hard disk and a frame grabber/buffer. It takes video in, stores it in a file, and plays it back when you like. When the Gods are merciful, you can even do the two simultaneously. You can easily put one together yourself if you like. TiVo wasn't the first to figure this one out either, they were just the first to market when declining prices made a consumer product possible.
In the long run, this will (or at least should) be replaced by IP-based multicast and video-on-demand anyway.
So how do you propose to do this? Details, please. Armchair developers aren't appreciated.
There is nothing to develop--the functionality is already there. It's a source reorganization: break up the kernel source tree and move almost all of the drivers and file systems out of the kernel and maintain them separately. Also, make a commitment that interface changes only happen between major kernel versions and that all kernel modules and kernels for the same major kernel version work together.
Hacking a huge monolithic kernel and being able to twiddle interfaces at will worked fine in the beginning, but now that Linux is maturing, its development should as well.
Given that the Linux kernel is much newer than the Hurd yet has matured faster don't you think Linus got something RIGHT in his development process?
What Linus got right was that he created a kernel that's easy to start hacking on. That attracted lots of developers and caused the Linux kernel to get lots of modules added quickly. But what's good for attracting lots of developers initially isn't necessarily good in the long run. (Incidentally, I didn't raise the Hurd as an alternative, you did)
Combine an interface change with the maintainer adding functionality while a kernel janitor cleanes up random portions of code? In each case the code changes are only on a single driver yet you have 3 people making changes.
I think your question already contains the presumption of a poorly modularized development process.
If drivers, file systems, and kernel were all separate projects, we'd have dozens of small projects. There would be no "kernel janitor" going around hacking all of them. Each project would make their own maintenance changes. And interface changes would need to be agreed on and then implemented separately--most likely by keeping both the old and the new interface for several releases.
The BugTraq reports on Linux and Windows cover very different amounts and kinds of software, so comparing systems by their number is not meaningful.
In any case, the issue is not how many bugs there are in either system, but how easy it is to secure and audit either system. For example, it's much easier to stript down a Linux system to a tiny set of well-understood processes and services because it's all open. With Windows, much less of that is documented, and I can't figure it out from sources; it also changes with every release.
Atari also screwed up a lot and was also a too small single supplier.
As opposed to Microsoft, which not only was a small supplier and had inferior technology? Microsoft was clearly a poor and irrational choice for companies. In fact, the technically and economically sensible thing for corporations in the 1980s would have been to deploy thin X-based clients and UNIX servers. PCs and Macs were, and still are, a waste of money and an IT nightmare in any corporate environment.
However, I suppose it is good that all that wasted money has driven hardware costs way down so that the people who really need it now can get $1000 supercomputers on their desks. It's kind of silly that the beancounters at various businesses didn't figure it out; the same people wasting 90% of their IT budget on junk would have screamed bloody murder if their taxes had gone up by as much as 1% to support R&D in information technologies. Go figure.
Neither have the magnitude of Developers or incoming patches that the Linux kernel has
Yes, and that's perhaps at the root of the problem: the Linux kernel is a huge, monolithic project. If it were broken up into smaller, independent subprojects, for example, then each subproject would have fewer developers and fewer patches coming in.
Nobody has really tried so far- even RMS is too stubborn to ask "Well, what is it that bitkeeper does
There are plenty of open source systems for version control and configuration management. Furthermore, they way open source works, if you need an unusual tool for your project, you create it yourself and share it.
It's funny how much people will bitch when they're not the ones that have to deal with the inadequacies of $OSS_SM_TOOL when it comes to kernel development.
There are plenty of huge open source projects, and they work fine with CVS. GNU Hurd is being developed with CVS. BSD is. To me, the real question is: what is going wrong with Linux kernel development that CVS is not sufficient?
"And resource management in Objective-C and Cocoa is a lot more work and a lot more error prone than in Java or C++."
Not really. Objective C has no built in memory management (neither does C++), but it uses a reference counting system that works well enough that you rarely have to manually allocate or free memory.
Objective-C/Cocoa's reference counting scheme requires manual intervention--if you forget a step, it either leaks or crashes. Furthermore, its strategy often hangs on to memory longer than it needs to. And Objective-C does not have the language constructs to let library implementors automate memory management.
C++, in contrast, does let you automate memory management: you can build class libraries that automatically reference count or garbage collect with no user intervention. They also behave correctly automatically in the presence of exceptions.
Java, of course, automates this completely.
"I don't see much of a future for Cocoa, at least in its current form."
Apple does.
Yes, and I think they are wrong. I mean, come on, do you really think that the world is going to switch to a proprietary widget toolkit from the 1980's? Even if it were every bit as great as Apple marketing claims it is, I don't see that happening.
Let's hope they come to their senses before this really hurts them--it would be nice to have at least one alternative to Windows in the commercial world.
Well, I took you at your word. Maybe you should have described it better.
As for being a real UNIX, ACL's are supported in most commercial UNIXes and file attributes come directly out of IRIX.
I have no idea what "real UNIX" is. All I'm saying that the original designers of UNIX didn't act out of ignorance; they excluded ACLs and attributes from the design by choice. I think that choice is still the right one.
Extensions are an anarchronism. Just because they're popular doesn't mean they don't suck.
Actually, it seems to me that BeOS is the anachronism, because it doesn't exist anymore. Certainly, reviving decades old ideas like attributes and ACLs didn't make BeOS modern.
What I can't figure out about Be zealots like you is--why don't you just use Windows? Windows has all the features you pretend to like so much: it has a fully attributed file system, it supports ACLs, and it has a library-based graphics API, just like BeOS.
Sticking attributes in a directory is a bad idea. Giampalo, in his book about the Be file system. [...] his original implementation (each file has an associated atttribute directory)
Well, no wonder that he wasn't satisfied with that: that's a lousy implementation because the two can become disassociated. A better implementation is to stick both the content and the attributes into a single directory and treat the directory itself as a single document in the GUI.
For my day job, I work with millions of files, each having dozens of attributes. A set of special-purpose APIs would be an enormous headache. I run into this occasionally when I use platforms that do have attributes.
Linux will support [attributes] through a common API
A lot of junk has been dumped into Linux, much of it not very widely used. If the majority of Linux software ever started relying on such features, Linux would cease to be a UNIX-style operating system. UNIX was designed by people rebelling against nonsense like ACLs, file attributes, etc.; it was a deliberate choice.
Most files have no detectable fingerprint and this will only become more common as more text-based formats (XML) proliferate.
XML files are supposed to identify what the XML represents. Dumping bits of XML into a file and determining its type through file attributes is contrary to everything XML stands for. Other text files encode their type as part of their file name (usually, an extension).
My 2 GHz P4 running KDE 3.x (Gentoo, uber-tricked out) still doesn't match the responsiveness of my 300 MHz PII running BeOS (dead stock, no tweeking), though its getting close thanks to 6x the processor and 10x the RAM.
Linux doesn't try to optimize interactive responsiveness--and most of its users wouldn't want it to. Linux aims for having a compromise between good interactive performance, good batch performance, and good multiuser performance.
However, with the new kernel thread implementation (run 100000 threads if you like) and the preemptible kernel, I suspect that Linux actually would match BeOS if you chose to configure it that way.
BeOS stored the MIME type of a file in an attribute
The designers of UNIX chose 25 years ago to keep the file system as simple as possible, and their choice has proven to be the right one for UNIX and Linux applications. If you want something like an attributed file system under UNIX, you stick the content and the attributes together into a directory; a UI can treat the directory as a single entity. That's what Mac OS X does, and it works very well.
For files in particular, file type identification based on fingerprints, as used in UNIX, is more robust and, if anything, simpler from the application programmer's point of view.
I would not be scared of learning Objective-C--it is a very simple language and easy to learn, and its object model is very convenient. But in other ways, Cocoa using Objective-C is a somewhat outdated programming environment: the GUI design tools were great in the 1980's, but they are pretty dated by today's standards. And resource management in Objective-C and Cocoa is a lot more work and a lot more error prone than in Java or C++. On the plus side, Cocoa is what Apple really wants you to use, and that's where they seem to be putting a lot of their efforts.
Cocoa using Java is probably in a certain sense "the best" programming environment for the Mac: it's modern, easy to develop in, and mostly safe. It's also pretty well supported. But it retains many of the warts of the Cocoa APIs and, as you observed, is not all that well documented.
With either Cocoa-based solution, you also have to ask yourself whether you believe that Cocoa has a future and whether it's worth learning it. I don't see much of a future for Cocoa, at least in its current form. Apple has made no moves to standardize it or open it up, so it is Mac only. Even if Apple pushed for more widespread adoption, they'd have to make big changes to make it palatable to industry, like adding precise garbage collection and better error checking to Objective-C, with the resulting changes to the APIs. An example of work in that direction can be found here (yes, that is "gerbil.org", but it's a site about programming, really).
Swing Java is probably the least hassle: it's well documented, it works very well on Macintosh, and you still get the native look-and-feel. It has modern resource management and modern layout management. Knowing Swing is useful and helps you on other platforms as well. And its object system is fairly similar to that of Objective-C. But some of the more advanced features have been buggy in the past (e.g., audio input, etc.). You can, however, combine Swing and Cocoa APIs, using Swing for the GUI and dropping down into native APIs only when Sun's cross-platform APIs fail you.
If you use one of the Java-based solutions but find the Java type system too constraining, you can use Jython, a Java-based implementation of Python. You can choose to run it interactively or compiled. It's great for exploring the Cocoa APIs (or the Swing APIs).
Another choice you may want to consider is wxWindows. Recent versions run very well on MacOSX and look native. If you want to see an example of an application written in wxWindows, take a look at Audacity.
I tried all these different approaches, and I ended up doing most of my Mac programming in Java/Swing and wxWindows.
That's the idea. If it becomes a major PITA (and this is) to buy products that require a EULA, then people won't. They will prefer to buy products covered by basic copyright law
That is, if the industry heavyweights don't collude to standardize on a set of restrictive terms, to the disadvantage of customers. That's what has happened in many other areas, e.g., banking, mortgages, etc. Furthermore, many EULAs are only available after purchasing and opening the products.
It would really make a lot of sense for the government to define standard terms of sale for computer software. If companies want different terms, they should be required to present a written contract prior to purchase and have it signed by both parties.
I've already explained the solution, and just because you can't think up of other solutions doesn't mean that they don't exist.
That's like saying that "1+1=2" only because I can't think of other solutions.
Just because MS is cooperating doesn't mean they are the RIAA's Yes Men.
I have no idea what "being the RIAA's Yes Men" is supposed to mean. To Microsoft, the RIAA and MPAA are convenient allies for monpolizing markets further: if DRM becomes mandatory, Microsoft will hold the keys to digital media. That's why Microsoft would really like to see DRM become ubiquitous. However, because there is a possibility of a sharp consumer and legislative backlash against DRM, they are still keeping some options open.
Overall, this means that Microsoft should be considered a potent adversary to anybody interested in fair use and consumer rights.
For people who want a small, quiet PC for their desktop, I think they need to put it into a nicer-looking case and make it quieter (I didn't see anything in the review about noise so I assume it's not particularly quiet). Also, something like a DeskNote (search on Google)--a laptop form factor with desktop components--is cheap and space saving. For gamers, it really needs a PCI+AGP slot so that they can put in their favorite graphics cards. For lab equipment and other uses, you probably don't need such a high-end processor--a min-ITX board is cheaper, quieter, and generates less heat. Overall, I think this is a real niche product. But it shows that more small PCs are on the horizon.
Taiwan relies on the US to avoid being absorbed by China--that gives the US a lot of leverage in any negotiations. This is probably no coincidence: if the US can apply leverage to make the first Asian country cave in, the others will follow more easily.
In different words: don't expect Taiwanese opposition to last long. They know who they need to defend them and they are probably just using this as a bargaining chip in other negotiations.
The notion that running "anti-virus software" equals security is just stupid. If you keep your system up-to-date and run a reasonable mail reader, you don't need it. Anti-virus software is like taking antibiotics prophylactically: it's expensive and not good for you. And anti-virus software breaks a lot more than just making your computer slower.
because there is no factual basis for your speculation (or, at least none presented).
Ummm--those are the things a company would have to do to "plug the analog hole".
this means that I can't even make an Mp3 of a CD that _I_ created
First, you argue at length that Microsoft's DRM restrictions amount to nothing and leave users the choice, then you yourself point out that Microsoft is likely goig to restrict even operations that involve copying non-DRM content into a non-DRM format. I'm sorry, but I think you have no idea yourself what point you are actually trying to make.
But how many game owners make backup copies of his game CDs ? And do people really want to argue that the majority of game CDs burned are for legitimate reasons ?
Game CDs and DVDs can suffer a lot of abuse, they do break with some regularity, and they aren't cheap. It makes a lot of sense to back them up.
True, when you've booted in DRM-mode there is no analog hole. And when you are booted in "insecure" mode you can't access the DRM'd files. However, you are still making a choice.
What that amounts to is that you agree with me: Microsoft intends to fully support and enforce DRM on their operating system. You are just trying to spin the situation favorably for Microsoft.
In fact, most likely, there will be very little you will be able to do in any non-DRM mode: most media players, video input, and audio input drivers will likely refuse to work. Video playback and high-quality audio output may stop working, too. Probably, even most commercial application software will refuse to work because they will consider DRM a convenient copy protection mechanism. If Microsoft even bothers with a non-DRM mode, it will quickly fall into disuse because it will be useless.
Also, this has to do with Palladium only peripherally. Palladium itself doesn't force anything on anybody, it's the uses that Palladium is put to. Palladium is, among other things, the mechanism by which Microsoft enforces the use of their DRM software, and that's where you lose your choice.
People used to do something similar with floppy disks: they'd punch a bunch of holes into some track and they could measure their presence and location by seeing where they couldn't write. It's a property that cannot be copied by a regular floppy disk drive.
It turned out to be futile. People just disabled whatever code depended on it. And if the locations of the holes were used as a cryptographic key, people would just recover the key and hack the executable to supply it.
On current operating systems, where applications can't talk directly to the hardware anyway, you can do something even simpler: you just emulate whatever that special track contains by recording it on the source disk and replaying it through the driver on the destination drive. And if the drivers ever were to become secure, a small FPGA inserted into the ATA cable between the CD-ROM and the controller would give you the same capability completely transparently.
But the biggest problem with these approaches turned out to be that consumers just didn't like them and preferred software that didn't have such annoying mechanisms built in.
Overall, copy protection is a losing battle. The cost software vendors suffer in usability and customer good will is apparently higher than the losses from piracy that they stop.
Slashdot Mirror
Furthermore, yes, software does rely on it. Even just untarring a UNIX archive on OS X can break it, like if it contains "Makefile" and "makefile".
On servers, despite its popularity, journaling makes much less sense: there are better ways to recover from failures, and the performance hit really does matter.
In the long run, this will (or at least should) be replaced by IP-based multicast and video-on-demand anyway.
I don't really see much advantage of this over the Terapin Mine or the Archos player. Sure, it looks nice, but doesn't functionally matter more?
There is nothing to develop--the functionality is already there. It's a source reorganization: break up the kernel source tree and move almost all of the drivers and file systems out of the kernel and maintain them separately. Also, make a commitment that interface changes only happen between major kernel versions and that all kernel modules and kernels for the same major kernel version work together.
Hacking a huge monolithic kernel and being able to twiddle interfaces at will worked fine in the beginning, but now that Linux is maturing, its development should as well.
What Linus got right was that he created a kernel that's easy to start hacking on. That attracted lots of developers and caused the Linux kernel to get lots of modules added quickly. But what's good for attracting lots of developers initially isn't necessarily good in the long run. (Incidentally, I didn't raise the Hurd as an alternative, you did)
Combine an interface change with the maintainer adding functionality while a kernel janitor cleanes up random portions of code? In each case the code changes are only on a single driver yet you have 3 people making changes.
I think your question already contains the presumption of a poorly modularized development process.
If drivers, file systems, and kernel were all separate projects, we'd have dozens of small projects. There would be no "kernel janitor" going around hacking all of them. Each project would make their own maintenance changes. And interface changes would need to be agreed on and then implemented separately--most likely by keeping both the old and the new interface for several releases.
In any case, the issue is not how many bugs there are in either system, but how easy it is to secure and audit either system. For example, it's much easier to stript down a Linux system to a tiny set of well-understood processes and services because it's all open. With Windows, much less of that is documented, and I can't figure it out from sources; it also changes with every release.
As opposed to Microsoft, which not only was a small supplier and had inferior technology? Microsoft was clearly a poor and irrational choice for companies. In fact, the technically and economically sensible thing for corporations in the 1980s would have been to deploy thin X-based clients and UNIX servers. PCs and Macs were, and still are, a waste of money and an IT nightmare in any corporate environment.
However, I suppose it is good that all that wasted money has driven hardware costs way down so that the people who really need it now can get $1000 supercomputers on their desks. It's kind of silly that the beancounters at various businesses didn't figure it out; the same people wasting 90% of their IT budget on junk would have screamed bloody murder if their taxes had gone up by as much as 1% to support R&D in information technologies. Go figure.
Yes, and that's perhaps at the root of the problem: the Linux kernel is a huge, monolithic project. If it were broken up into smaller, independent subprojects, for example, then each subproject would have fewer developers and fewer patches coming in.
There are plenty of open source systems for version control and configuration management. Furthermore, they way open source works, if you need an unusual tool for your project, you create it yourself and share it.
It's funny how much people will bitch when they're not the ones that have to deal with the inadequacies of $OSS_SM_TOOL when it comes to kernel development.
There are plenty of huge open source projects, and they work fine with CVS. GNU Hurd is being developed with CVS. BSD is. To me, the real question is: what is going wrong with Linux kernel development that CVS is not sufficient?
Not really. Objective C has no built in memory management (neither does C++), but it uses a reference counting system that works well enough that you rarely have to manually allocate or free memory.
Objective-C/Cocoa's reference counting scheme requires manual intervention--if you forget a step, it either leaks or crashes. Furthermore, its strategy often hangs on to memory longer than it needs to. And Objective-C does not have the language constructs to let library implementors automate memory management.
C++, in contrast, does let you automate memory management: you can build class libraries that automatically reference count or garbage collect with no user intervention. They also behave correctly automatically in the presence of exceptions.
Java, of course, automates this completely.
"I don't see much of a future for Cocoa, at least in its current form."
Apple does.
Yes, and I think they are wrong. I mean, come on, do you really think that the world is going to switch to a proprietary widget toolkit from the 1980's? Even if it were every bit as great as Apple marketing claims it is, I don't see that happening.
Let's hope they come to their senses before this really hurts them--it would be nice to have at least one alternative to Windows in the commercial world.
Well, I took you at your word. Maybe you should have described it better.
As for being a real UNIX, ACL's are supported in most commercial UNIXes and file attributes come directly out of IRIX.
I have no idea what "real UNIX" is. All I'm saying that the original designers of UNIX didn't act out of ignorance; they excluded ACLs and attributes from the design by choice. I think that choice is still the right one.
Extensions are an anarchronism. Just because they're popular doesn't mean they don't suck.
Actually, it seems to me that BeOS is the anachronism, because it doesn't exist anymore. Certainly, reviving decades old ideas like attributes and ACLs didn't make BeOS modern.
What I can't figure out about Be zealots like you is--why don't you just use Windows? Windows has all the features you pretend to like so much: it has a fully attributed file system, it supports ACLs, and it has a library-based graphics API, just like BeOS.
Well, no wonder that he wasn't satisfied with that: that's a lousy implementation because the two can become disassociated. A better implementation is to stick both the content and the attributes into a single directory and treat the directory itself as a single document in the GUI.
For my day job, I work with millions of files, each having dozens of attributes. A set of special-purpose APIs would be an enormous headache. I run into this occasionally when I use platforms that do have attributes.
Linux will support [attributes] through a common API
A lot of junk has been dumped into Linux, much of it not very widely used. If the majority of Linux software ever started relying on such features, Linux would cease to be a UNIX-style operating system. UNIX was designed by people rebelling against nonsense like ACLs, file attributes, etc.; it was a deliberate choice.
Most files have no detectable fingerprint and this will only become more common as more text-based formats (XML) proliferate.
XML files are supposed to identify what the XML represents. Dumping bits of XML into a file and determining its type through file attributes is contrary to everything XML stands for. Other text files encode their type as part of their file name (usually, an extension).
Linux doesn't try to optimize interactive responsiveness--and most of its users wouldn't want it to. Linux aims for having a compromise between good interactive performance, good batch performance, and good multiuser performance.
However, with the new kernel thread implementation (run 100000 threads if you like) and the preemptible kernel, I suspect that Linux actually would match BeOS if you chose to configure it that way.
BeOS stored the MIME type of a file in an attribute
The designers of UNIX chose 25 years ago to keep the file system as simple as possible, and their choice has proven to be the right one for UNIX and Linux applications. If you want something like an attributed file system under UNIX, you stick the content and the attributes together into a directory; a UI can treat the directory as a single entity. That's what Mac OS X does, and it works very well.
For files in particular, file type identification based on fingerprints, as used in UNIX, is more robust and, if anything, simpler from the application programmer's point of view.
http://simh.trailing-edge.com/.
However, if it's not open sourced, obviously, it can't evolve much further, so in that sense, operating systems do die.
I would not be scared of learning Objective-C--it is a very simple language and easy to learn, and its object model is very convenient. But in other ways, Cocoa using Objective-C is a somewhat outdated programming environment: the GUI design tools were great in the 1980's, but they are pretty dated by today's standards. And resource management in Objective-C and Cocoa is a lot more work and a lot more error prone than in Java or C++. On the plus side, Cocoa is what Apple really wants you to use, and that's where they seem to be putting a lot of their efforts.
Cocoa using Java is probably in a certain sense "the best" programming environment for the Mac: it's modern, easy to develop in, and mostly safe. It's also pretty well supported. But it retains many of the warts of the Cocoa APIs and, as you observed, is not all that well documented.
With either Cocoa-based solution, you also have to ask yourself whether you believe that Cocoa has a future and whether it's worth learning it. I don't see much of a future for Cocoa, at least in its current form. Apple has made no moves to standardize it or open it up, so it is Mac only. Even if Apple pushed for more widespread adoption, they'd have to make big changes to make it palatable to industry, like adding precise garbage collection and better error checking to Objective-C, with the resulting changes to the APIs. An example of work in that direction can be found here (yes, that is "gerbil.org", but it's a site about programming, really).
Swing Java is probably the least hassle: it's well documented, it works very well on Macintosh, and you still get the native look-and-feel. It has modern resource management and modern layout management. Knowing Swing is useful and helps you on other platforms as well. And its object system is fairly similar to that of Objective-C. But some of the more advanced features have been buggy in the past (e.g., audio input, etc.). You can, however, combine Swing and Cocoa APIs, using Swing for the GUI and dropping down into native APIs only when Sun's cross-platform APIs fail you.
If you use one of the Java-based solutions but find the Java type system too constraining, you can use Jython, a Java-based implementation of Python. You can choose to run it interactively or compiled. It's great for exploring the Cocoa APIs (or the Swing APIs).
Another choice you may want to consider is wxWindows. Recent versions run very well on MacOSX and look native. If you want to see an example of an application written in wxWindows, take a look at Audacity.
I tried all these different approaches, and I ended up doing most of my Mac programming in Java/Swing and wxWindows.
That is, if the industry heavyweights don't collude to standardize on a set of restrictive terms, to the disadvantage of customers. That's what has happened in many other areas, e.g., banking, mortgages, etc. Furthermore, many EULAs are only available after purchasing and opening the products.
It would really make a lot of sense for the government to define standard terms of sale for computer software. If companies want different terms, they should be required to present a written contract prior to purchase and have it signed by both parties.
That's like saying that "1+1=2" only because I can't think of other solutions.
Just because MS is cooperating doesn't mean they are the RIAA's Yes Men.
I have no idea what "being the RIAA's Yes Men" is supposed to mean. To Microsoft, the RIAA and MPAA are convenient allies for monpolizing markets further: if DRM becomes mandatory, Microsoft will hold the keys to digital media. That's why Microsoft would really like to see DRM become ubiquitous. However, because there is a possibility of a sharp consumer and legislative backlash against DRM, they are still keeping some options open.
Overall, this means that Microsoft should be considered a potent adversary to anybody interested in fair use and consumer rights.
For people who want a small, quiet PC for their desktop, I think they need to put it into a nicer-looking case and make it quieter (I didn't see anything in the review about noise so I assume it's not particularly quiet). Also, something like a DeskNote (search on Google)--a laptop form factor with desktop components--is cheap and space saving. For gamers, it really needs a PCI+AGP slot so that they can put in their favorite graphics cards. For lab equipment and other uses, you probably don't need such a high-end processor--a min-ITX board is cheaper, quieter, and generates less heat. Overall, I think this is a real niche product. But it shows that more small PCs are on the horizon.
In different words: don't expect Taiwanese opposition to last long. They know who they need to defend them and they are probably just using this as a bargaining chip in other negotiations.
The notion that running "anti-virus software" equals security is just stupid. If you keep your system up-to-date and run a reasonable mail reader, you don't need it. Anti-virus software is like taking antibiotics prophylactically: it's expensive and not good for you. And anti-virus software breaks a lot more than just making your computer slower.
Ummm--those are the things a company would have to do to "plug the analog hole".
this means that I can't even make an Mp3 of a CD that _I_ created
First, you argue at length that Microsoft's DRM restrictions amount to nothing and leave users the choice, then you yourself point out that Microsoft is likely goig to restrict even operations that involve copying non-DRM content into a non-DRM format. I'm sorry, but I think you have no idea yourself what point you are actually trying to make.
Game CDs and DVDs can suffer a lot of abuse, they do break with some regularity, and they aren't cheap. It makes a lot of sense to back them up.
What that amounts to is that you agree with me: Microsoft intends to fully support and enforce DRM on their operating system. You are just trying to spin the situation favorably for Microsoft.
In fact, most likely, there will be very little you will be able to do in any non-DRM mode: most media players, video input, and audio input drivers will likely refuse to work. Video playback and high-quality audio output may stop working, too. Probably, even most commercial application software will refuse to work because they will consider DRM a convenient copy protection mechanism. If Microsoft even bothers with a non-DRM mode, it will quickly fall into disuse because it will be useless.
Also, this has to do with Palladium only peripherally. Palladium itself doesn't force anything on anybody, it's the uses that Palladium is put to. Palladium is, among other things, the mechanism by which Microsoft enforces the use of their DRM software, and that's where you lose your choice.
It turned out to be futile. People just disabled whatever code depended on it. And if the locations of the holes were used as a cryptographic key, people would just recover the key and hack the executable to supply it.
On current operating systems, where applications can't talk directly to the hardware anyway, you can do something even simpler: you just emulate whatever that special track contains by recording it on the source disk and replaying it through the driver on the destination drive. And if the drivers ever were to become secure, a small FPGA inserted into the ATA cable between the CD-ROM and the controller would give you the same capability completely transparently.
But the biggest problem with these approaches turned out to be that consumers just didn't like them and preferred software that didn't have such annoying mechanisms built in.
Overall, copy protection is a losing battle. The cost software vendors suffer in usability and customer good will is apparently higher than the losses from piracy that they stop.