Pointer arithmetic and lack of bounds checking are the ways in which programmers in languages other than C traditionally did casts. Consider the equivalent of (I have seen these in old Fortran and Pascal code):
struct Cast { int x[1]; float y; }; int float_bits_as_int(float f) { Cast c; c.y = f; return x[1]; }
Here is another example:
int float_bits_as_int(float f) { float *p = new float; *p = f; delete p; int *ip = new int; int v = *ip; delete ip; return v; }
These "logic errors" are related to type errors: they allow the bits of an object of one type to be interpreted as the bits of an object of another type. A system that's type safe guarantees that that doesn't happen.
In any case "type safety" doesn't just mean compile time type safety. Java has a lot of runtime type safety, where type errors are caught at runtime, not by the compiler. That's still fine for many purposes. C++ has neither.
The problem is not the presence of unsafe constructs in C++, the problem is that the unsafe constructs are indistinguishable from the safe constructs.
In C++, this might look like:
char *p = unsafe::allocate(char,100); char c = unsafe::ref(p,10); float f = unsafe::castref(float,p,0);
Of course, C++ would also need to eliminate the unsafe constructs it has outside namespace "unsafe", and in some cases add safe constructs to replace them. Then, you could limit the use of unsafe constructs to only the few places where you actually need them. That greatly reduces the probability of making errors. Languages that do this exist: Modula-3, Oberon, and others. There are no such languages in widespread use yet that look like C or C++, unfortunately.
Other potentially unsafe constructs in C/C++ are pointer dereferencing, calling a function pointer, array subscripting, and call-by-reference. Even for casts, neither a compiler nor a reader can tell whether the cast is safe or not.
So, if you don't use pointers, address-of, array subscripting, call-by-reference, or any library functions that do, yes, then you can write type-safe C++ programs. Too bad that you also can't do much in that subset of C++.
There is no problem with providing those unsafe constructs in a systems programming language. In fact, lots of languages do, just like C/C++. The problem with C/C++ is that the safe constructs and the unsafe constructs are indistinguishable, and that means that even the 99.9% of a program that can be written nicely with the safe constructs use the unsafe ones, and as a result are much more likely to crash.
Well, first of all, you seem to agree as far as C is concerned since you advocate wrapping all those unsafe C interfaces into better C++ interfaces.
Yes, C++ is somewhat better than C because it does allow you to build abstractions that perform more checking and automatic resource management. But even if you do that C++ is fundamentally unsafe. Why?
C++ still uses the C pointer model and adds a similar reference model. And C++ still uses manual memory management for dynamic allocation. You cannot, in general, address those problems by creating safe abstractions. If you try, you end up severely limiting language semantics, and as soon as you face any outside library, you have to convert to raw pointers anyway.
And C++ still does not guarantee fault isolation among modules or any way of determining from the source code of a module whether that module is safe or not. That is, any piece of code you link with can cause arbitrary problems in any other piece of code, and you have no way of telling. Perhaps you think that's inevitable, but it is not. None of the other languages that I mentioned have that misfeature.
Arguing that one should not bother fixing those problems because there are lots of other ways in which people can make mistakes is wrong. The problems C/C++ creates for programmers are easily avoided, without performance penalty or other drawbacks. A day lost trying to chase some avoidable pointer bug in a C/C++ program is a day that could have been spent on testing and fixing some conceptual security bug.
I have been using C for 20 years and C++ since before its first public release (nearly 15 years?). I still use them a lot because that's what interfaces best with the software that's out there. At the time, they were reasonably good tradeoffs. But this is the year 2000, and tradeoffs that were good then are not good anymore.
The same is true for Modula-3, Oberon, Sather, Eiffel, and other languages. Yes, they don't have the support or user community that C has, but on technical grounds alone, they are fast, small, have no overhead, etc.
And in such systems, you pay a lot of overhead if you try to generate code at runtime, because it always involves a system call. That may be fine for 1960's style COBOL and C/C++ code, but it is not acceptable for 2000's style languages and programming.
Oh, you found me out: I'm stupid and careless. And there are a lot more people like me around, at Microsoft, Sun, and even some (I hear) in the free software community.
And to help half-wits like us still do something useful with software, it might be nice to give us tools we don't hurt ourselves with too much. You know, scissors instead of a Samurai sword. A Toyota Camry instead of a Formula 1 race car. 110V household current instead of 50KV "professional" power.
The fact is, C/C++ is too powerful for me. Oh, I understand it just fine, and with enough time and effort, I can make something work semi-reliably in it. But what's the benefit I get for that self-flagellation? Should I spend all that extra time because finding the bugs "hurts so good"?
The fact is: writing code in C/C++ is a lot of unnecessary work. The only reason why people put up with it is because everybody else does it, so it's the path of least resistance if you want to use the "standard" compiler on your platform, use a language other people are likely to understand, and use other people's C/C++ libraries. But make no mistake about it: C/C++ is successful these days in spite of its cumbersome design, not because of it.
There are lots of ways in which you can create security holes. Many of them are shared between Java and C++. But buffer overruns are a huge risk in C/C++ because the language forces programmers to use unsafe constructs at every turn. And, an even bigger problem than the lack of security is just the lack of reliability of C/C++-based systems. C was a great design in the 1970's when it needed to run on 64k PDP-11's. In 2000, it's an anachronism. And the C/C++ family is not fixable without serious incompatible changes.
In part, people like you are the problem who view this as an issue of "being forced" by "bondage and discipline-style languages". In fact, languages like Modula-3 don't "force" you to do anything. You can cast, convert, and crash as much as you want. But unlike C/C++, when you do, you use different constructs from those you use for normal programming. By default, Modula-3 checks, and that's by far the more useful case. The same is true for most other system programming languages: they provide both safe and unsafe constructs, but you can actually do something useful staying within the safe constructs. It is only C/C++ that forces programmers to use unsafe constructs and makes it impossible for compilers or lint-like tools to do checking.
Languages like C/C++ only hang around because they have a user community. They are entrenched in the same way the Windows 3.1 architecture or other bad, outdated standards are entrenched. It's hard to break out of that because all the tools and APIs are created for C/C++, so that anything else is at a disadvantage and appears cumbersome in comparison.
But realistically, if you want to write reliable, safe programs without expending a huge amount of time and effort on tracking down bugs, you need to dump C/C++ and switch to one of the many alternative, existing, high quality systems programming languages. The sooner we make the change for the industry as a whole, the better.
Buffer overflow exploits don't necessarily require you to be able to run code from the stack segment. Often, it's sufficient just to change the return address (which necessarily is stored on the stack) to some useful routine, or to change a bunch of bits that are used for a security check.
The underlying problem is that C/C++/Objective-C do not have mechanisms to protect against these kinds of problems. In fact, it's impossible to write substantial programs in those languages that use only "safe" constructs. This is a peculiar and fundamental bug in the C-family language design.
There are excellent alternatives around. Modula-3, Oberon, Ada, Sather, and Eiffel all have efficient, free, open source implementations around, they all provide access to unsafe features when needed, and one of them should satisfy anybody's programming needs. Java is an excellent applications and server programming language, although it has a bit more overhead and no access to low-level features.
So, folks, get with the program and stop writing servers and other applications in C/C++.
With all the hoopla over the glitzy commercial games, most people forget that many of those games are functionally derivatives of much older games: Rogue, Zork, dungeon, xconquest, etc. I can't think of a single commercial genre that didn't start that way. Furthermore, having played both, I think the gameplay on the older, less glitzy games is still better than on most of the current graphics-rich commercial stuff.
And I think that may be a clue as to where to start developing more interesting games. If you are going to spend a lot of time on fancy graphics, you aren't going to be able to experiment with good gameplay; at best, you can tinker around the edges. Those older games also got tuned because lots of people were using them and lots of people had access to the source.
So, keep the graphics minimal, experiment, and share. You can still dumb it down and make it look pretty for the mass market later.
While I agree with the gist of Katz's argument, I think it's too early to view this issue as closed. The ruling is not final, and whatever the outcome, it may be appealed.
More importantly, however, you still have a choice in the media you consume. Nobody is forcing you to become a consumer to the products of a large, commercialized media conglomerate. Don't buy commercial music, don't read big commercial newspapers, don't watch TV, etc. Most of those media are increasingly laden with advertising, harmful social messages, violence, and psychological trickery. We can help build an alternative media culture, both by contributing and by consuming outside the corporate media wasteland.
That numbering is pretty funny, if somewhat confusing. 4.1 BSD for the VAX was probably the first "real", "modern" version of BSD UNIX. 4.2 then incorporated much of the networking code. The PDP-11 versions of BSD UNIX at around the same time had 2.x version numbers.
A text mode console is useless for desktop use, but that's only one of many applications of computers. Text mode consoles are very useful for server farms and other applications. The problem with Aqua, for that matter, isn't its appearance, it's its lack of remotability.
Apple has designed a good client machine for non-technical users. It may also work in some server and engineering applications. But let's not pretend that it is something that it isn't. Different people and applications have different needs, and if you optimize a design for one application, it will often be suboptimal for others.
Porting of most UNIX applications to Mac OS X won't happen unless Mac OS X gets a free X11 server or X11 compatibility library. A commercial X11 implementation won't provide sufficient incentive because it means that people have to buy and install another, separate product just in order to use free software.
The simplest way of getting X11 on Mac OS X (or Windows, for that matter) may be to port the UNIX VNC server. It implements an X11 server and frame buffer completely in software.
If Apple is smart and wants to go for this market, they should start including X11 compatibility in their base system.
Security is expensive. The threat of massive "script kiddie" attacks and the threat of public embarrassment is the economic incentive that can convince vendors to actually address security problems.
Without disclosure and actual attacks, security is not an economic incentive. It can't be demonstrated to customers, and it doesn't become a product differentiator. The occasional problem that might happen in a world without disclosure are not sufficient to affect the bottom line, in particular since software vendors are usually not liable.
We tried hushing up security holes for decades and it didn't work. In fact, it gave us the Morris worm--the exploits it used had all been well known for years without any vendor bothering to fix them--and VMS pseudo-security. Arguably, the current sorry state of computer security is still the aftermath of that approach.
I see nothing problematic about disclosure of security problems, whether by competitors or anybody else: it's the only policy that objectively makes sense from the point of view of the customers in order to create a market that supports secure products. "Script kiddies", far from being an annoying side effect, are the very mechanism that makes disclosure effective: without the economic threat from their activities, vendors would still have no incentive to fix their security problems.
In the long run, I hope that these kinds of economic pressures will get rid of the snake oil and tinkering around the edges (and that includes Ranum's own intrusion detection systems) and will force companies and developers to adopt tools, methodologies, languages, and cryptographic approaches that address security problems correctly. (Yes, this also means Linux needs to change.)
Of course, UNIX can handle it, probably better than just about anything else out there. Linux isn't UNIX, of course, and whether Linux can handle it is a different question. It probably can if you find the right software (I'd give DB2 a try).
But why ever would you replicate a database to a different kind of server? If the original database runs on Sybase SQL on whatever, then the obvious answer is to replicate it to an identical setup. Anything else, whether mission critical or not, is just going to be a lot more work, training, and maintenance.
I believe people recently found a meteorite that contained droplets of water enclosed within rock salt. Given the melting point of salt and other properties, I think that makes it unlikely that the interior of the meteorite got too hot. Of course, if the bacteria were on the outside to begin with, they might simply "come off" during reentry and then drift down harmlessly through the atmosphere.
I think the Apple desktop keyboards and mice are OK, but if you don't like them, you can always replace them (it's just USB).
One Apple hardware design I find absolutely awful is the trackpad on the laptops, and there is nothing one can do about that. It would be great if they offered a choice of trackball, trackpad, and trackpoint.
An iMac starts at $800, including monitor, and it's a pretty powerful machine. Last I tried to price out PC/104 or SBC-based PC systems, I couldn't even come close to building a high performance system for that kind of money. Not to mention the fact that fiddling with those components is a lot of work.
I think there is a need for the kind of hardware Apple produces: quiet, fanless, and small desktop machines with single-cable monitor connections and built-in wireless antennas.
I haven't found anything quite comparable in the PC world (iPaq, Sony's machines, and Dell tried but all fall short).
I don't care much for Apple styling, Apple software, or Apple corporate politics. But PC hardware vendors should take notice and deliver something similar. The value of the iMac and the cube is not in the translucent plastic, it's in the ergonomics of the hardware.
People can copy stuff to DiVX from tapes or through an analog output. That is neither a reason to outlaw DeCSS or DiVX or any other technology.
Implicit in your argument is that a technology should be outlawed if it allows pirating. That's nonsense and it was never the stated intent of lawmakers. The stated intent was to outlaw technology whose exclusive purpose was to allow pirating. If some otherwise useful technology also enables pirating, then the industry should have to figure out how to deal with the consequences, not society as a whole.
Besides, if the industry wanted to make cryptographically secure DVDs, they could. DeCSS is a consequence of either technical incompetence or a deliberate attempt to test the laws on the part of its developers.
Determining whether their actions were "legal" or not is the whole point of the lawsuit. I don't read the law the way the MPAA suggests and neither do a lot of other people. Furthermore, there is the question of what lawmakers actually intended, and what we as citizens want to happen, something that needs to be resolved legislatively. Legal challenges are an intrinsic part of the US system of law and government; this case had to be brought.
And you can bet that this episode will be used as the basis for more punitive legislation by a US government already dedicated to eliminating all vestiges of freedom on the net as it is.
What kind of government do you think operates in the US? Your kinds of arguments might be applicable in fascist or autocratic societies, but in a democratic society that is governed by the rule of law, court challenges and political participation are essential. That may annoy some lobbyists and legislators with vested financial interests, but it still needs to be done.
I find your arguments both dangerous and naive. Similar arguments have been made throughout history, and I suggest you read up on the consequences. Issues of corporate control of the media are of fundamental importance to our society, and this is not only a good cause, it's an essential cause.
Indeed, Microsoft employees are not all alike. Some came to Microsoft as part of acquisitions and some are in research. But the largest part appears to be long time employees whose stock options have vested and who stay because they believe in what they are doing, and new, often inexperienced, hires who stay because Microsoft gives them great opportunities, gives them a lot of responsibility, and promises riches through stock options.
It's the latter two categories of employees that give Microsoft its Borg-like quality: they haven't seen much of the industry, they truly believe that Microsoft is doing innovative stuff, and they aren't part of a professional community that spans companies (other than, perhaps, Microsoft spin-offs). Their lack of breadth and experience and the "learning on the job" shows in their products. Microsoft hires them early and molds them their way (just like previous monopolies and the military). Those people truly believe in the "Microsoft way" and they truly believe that Microsoft is bringing something valuable to the masses.
In order to agree with the overall vision, people don't have to agree with the company in each and every way. And it is Microsoft's overall vision and pretense that is at issue, not a few glitches in execution. People stay at Microsoft, despite having lots of other good jobs available to them, and that tells us pretty much all we need to know about their views and ethical choices.
Could ChatScan/eNow just be an inconspicuous way for law enforcement to connect to IRC networks? I think without such a pretext, it would actually be non-trivial to connect to IRC networks on a large scale (for indexing/logging) without being detected or arousing suspicions.
Why worry about law enforcement listening in? After all, people shouldn't have an expectation of privacy on IRC. But I think a big concern is that law enforcement may be unfamiliar with the social conventions on IRC and will misinterpret phantasy and bragging as reality.
In Plan 9, programs communicate through the file system. Unlike UNIX, where most files are just static arrangements of bytes, that kind of communication in Plan 9 is much more dynamic. For example, the window system itself corresponds to a number of entries in the file system (somewhat like/proc). That makes it much easier than in UNIX for different applications to talk to one another while they are running, as well as to create building blocks that do fancy stuff with information that flows between programs. Plan 9 also borrowed from the Oberon system when it comes to interaction; adding new functionality to the GUI can actually be as simple as just creating a useful command string on the screen somewhere. You can activate it later by just pointing to it.
Slashdot Mirror
struct Cast { int x[1]; float y; };
int float_bits_as_int(float f) {
Cast c;
c.y = f;
return x[1];
}
Here is another example:
int float_bits_as_int(float f) {
float *p = new float;
*p = f;
delete p;
int *ip = new int;
int v = *ip;
delete ip;
return v;
}
These "logic errors" are related to type errors: they allow the bits of an object of one type to be interpreted as the bits of an object of another type. A system that's type safe guarantees that that doesn't happen.
In any case "type safety" doesn't just mean compile time type safety. Java has a lot of runtime type safety, where type errors are caught at runtime, not by the compiler. That's still fine for many purposes. C++ has neither.
In C++, this might look like:
char *p = unsafe::allocate(char,100);
char c = unsafe::ref(p,10);
float f = unsafe::castref(float,p,0);
Of course, C++ would also need to eliminate the unsafe constructs it has outside namespace "unsafe", and in some cases add safe constructs to replace them. Then, you could limit the use of unsafe constructs to only the few places where you actually need them. That greatly reduces the probability of making errors. Languages that do this exist: Modula-3, Oberon, and others. There are no such languages in widespread use yet that look like C or C++, unfortunately.
So, if you don't use pointers, address-of, array subscripting, call-by-reference, or any library functions that do, yes, then you can write type-safe C++ programs. Too bad that you also can't do much in that subset of C++.
There is no problem with providing those unsafe constructs in a systems programming language. In fact, lots of languages do, just like C/C++. The problem with C/C++ is that the safe constructs and the unsafe constructs are indistinguishable, and that means that even the 99.9% of a program that can be written nicely with the safe constructs use the unsafe ones, and as a result are much more likely to crash.
Yes, C++ is somewhat better than C because it does allow you to build abstractions that perform more checking and automatic resource management. But even if you do that C++ is fundamentally unsafe. Why?
C++ still uses the C pointer model and adds a similar reference model. And C++ still uses manual memory management for dynamic allocation. You cannot, in general, address those problems by creating safe abstractions. If you try, you end up severely limiting language semantics, and as soon as you face any outside library, you have to convert to raw pointers anyway.
And C++ still does not guarantee fault isolation among modules or any way of determining from the source code of a module whether that module is safe or not. That is, any piece of code you link with can cause arbitrary problems in any other piece of code, and you have no way of telling. Perhaps you think that's inevitable, but it is not. None of the other languages that I mentioned have that misfeature.
Arguing that one should not bother fixing those problems because there are lots of other ways in which people can make mistakes is wrong. The problems C/C++ creates for programmers are easily avoided, without performance penalty or other drawbacks. A day lost trying to chase some avoidable pointer bug in a C/C++ program is a day that could have been spent on testing and fixing some conceptual security bug.
I have been using C for 20 years and C++ since before its first public release (nearly 15 years?). I still use them a lot because that's what interfaces best with the software that's out there. At the time, they were reasonably good tradeoffs. But this is the year 2000, and tradeoffs that were good then are not good anymore.
The same is true for Modula-3, Oberon, Sather, Eiffel, and other languages. Yes, they don't have the support or user community that C has, but on technical grounds alone, they are fast, small, have no overhead, etc.
And in such systems, you pay a lot of overhead if you try to generate code at runtime, because it always involves a system call. That may be fine for 1960's style COBOL and C/C++ code, but it is not acceptable for 2000's style languages and programming.
And to help half-wits like us still do something useful with software, it might be nice to give us tools we don't hurt ourselves with too much. You know, scissors instead of a Samurai sword. A Toyota Camry instead of a Formula 1 race car. 110V household current instead of 50KV "professional" power.
The fact is, C/C++ is too powerful for me. Oh, I understand it just fine, and with enough time and effort, I can make something work semi-reliably in it. But what's the benefit I get for that self-flagellation? Should I spend all that extra time because finding the bugs "hurts so good"?
The fact is: writing code in C/C++ is a lot of unnecessary work. The only reason why people put up with it is because everybody else does it, so it's the path of least resistance if you want to use the "standard" compiler on your platform, use a language other people are likely to understand, and use other people's C/C++ libraries. But make no mistake about it: C/C++ is successful these days in spite of its cumbersome design, not because of it.
In part, people like you are the problem who view this as an issue of "being forced" by "bondage and discipline-style languages". In fact, languages like Modula-3 don't "force" you to do anything. You can cast, convert, and crash as much as you want. But unlike C/C++, when you do, you use different constructs from those you use for normal programming. By default, Modula-3 checks, and that's by far the more useful case. The same is true for most other system programming languages: they provide both safe and unsafe constructs, but you can actually do something useful staying within the safe constructs. It is only C/C++ that forces programmers to use unsafe constructs and makes it impossible for compilers or lint-like tools to do checking.
Languages like C/C++ only hang around because they have a user community. They are entrenched in the same way the Windows 3.1 architecture or other bad, outdated standards are entrenched. It's hard to break out of that because all the tools and APIs are created for C/C++, so that anything else is at a disadvantage and appears cumbersome in comparison.
But realistically, if you want to write reliable, safe programs without expending a huge amount of time and effort on tracking down bugs, you need to dump C/C++ and switch to one of the many alternative, existing, high quality systems programming languages. The sooner we make the change for the industry as a whole, the better.
The underlying problem is that C/C++/Objective-C do not have mechanisms to protect against these kinds of problems. In fact, it's impossible to write substantial programs in those languages that use only "safe" constructs. This is a peculiar and fundamental bug in the C-family language design.
There are excellent alternatives around. Modula-3, Oberon, Ada, Sather, and Eiffel all have efficient, free, open source implementations around, they all provide access to unsafe features when needed, and one of them should satisfy anybody's programming needs. Java is an excellent applications and server programming language, although it has a bit more overhead and no access to low-level features.
So, folks, get with the program and stop writing servers and other applications in C/C++.
And I think that may be a clue as to where to start developing more interesting games. If you are going to spend a lot of time on fancy graphics, you aren't going to be able to experiment with good gameplay; at best, you can tinker around the edges. Those older games also got tuned because lots of people were using them and lots of people had access to the source.
So, keep the graphics minimal, experiment, and share. You can still dumb it down and make it look pretty for the mass market later.
More importantly, however, you still have a choice in the media you consume. Nobody is forcing you to become a consumer to the products of a large, commercialized media conglomerate. Don't buy commercial music, don't read big commercial newspapers, don't watch TV, etc. Most of those media are increasingly laden with advertising, harmful social messages, violence, and psychological trickery. We can help build an alternative media culture, both by contributing and by consuming outside the corporate media wasteland.
That numbering is pretty funny, if somewhat confusing. 4.1 BSD for the VAX was probably the first "real", "modern" version of BSD UNIX. 4.2 then incorporated much of the networking code. The PDP-11 versions of BSD UNIX at around the same time had 2.x version numbers.
Apple has designed a good client machine for non-technical users. It may also work in some server and engineering applications. But let's not pretend that it is something that it isn't. Different people and applications have different needs, and if you optimize a design for one application, it will often be suboptimal for others.
The simplest way of getting X11 on Mac OS X (or Windows, for that matter) may be to port the UNIX VNC server. It implements an X11 server and frame buffer completely in software.
If Apple is smart and wants to go for this market, they should start including X11 compatibility in their base system.
Without disclosure and actual attacks, security is not an economic incentive. It can't be demonstrated to customers, and it doesn't become a product differentiator. The occasional problem that might happen in a world without disclosure are not sufficient to affect the bottom line, in particular since software vendors are usually not liable.
We tried hushing up security holes for decades and it didn't work. In fact, it gave us the Morris worm--the exploits it used had all been well known for years without any vendor bothering to fix them--and VMS pseudo-security. Arguably, the current sorry state of computer security is still the aftermath of that approach.
I see nothing problematic about disclosure of security problems, whether by competitors or anybody else: it's the only policy that objectively makes sense from the point of view of the customers in order to create a market that supports secure products. "Script kiddies", far from being an annoying side effect, are the very mechanism that makes disclosure effective: without the economic threat from their activities, vendors would still have no incentive to fix their security problems.
In the long run, I hope that these kinds of economic pressures will get rid of the snake oil and tinkering around the edges (and that includes Ranum's own intrusion detection systems) and will force companies and developers to adopt tools, methodologies, languages, and cryptographic approaches that address security problems correctly. (Yes, this also means Linux needs to change.)
But why ever would you replicate a database to a different kind of server? If the original database runs on Sybase SQL on whatever, then the obvious answer is to replicate it to an identical setup. Anything else, whether mission critical or not, is just going to be a lot more work, training, and maintenance.
I believe people recently found a meteorite that contained droplets of water enclosed within rock salt. Given the melting point of salt and other properties, I think that makes it unlikely that the interior of the meteorite got too hot. Of course, if the bacteria were on the outside to begin with, they might simply "come off" during reentry and then drift down harmlessly through the atmosphere.
One Apple hardware design I find absolutely awful is the trackpad on the laptops, and there is nothing one can do about that. It would be great if they offered a choice of trackball, trackpad, and trackpoint.
An iMac starts at $800, including monitor, and it's a pretty powerful machine. Last I tried to price out PC/104 or SBC-based PC systems, I couldn't even come close to building a high performance system for that kind of money. Not to mention the fact that fiddling with those components is a lot of work.
I haven't found anything quite comparable in the PC world (iPaq, Sony's machines, and Dell tried but all fall short).
I don't care much for Apple styling, Apple software, or Apple corporate politics. But PC hardware vendors should take notice and deliver something similar. The value of the iMac and the cube is not in the translucent plastic, it's in the ergonomics of the hardware.
Implicit in your argument is that a technology should be outlawed if it allows pirating. That's nonsense and it was never the stated intent of lawmakers. The stated intent was to outlaw technology whose exclusive purpose was to allow pirating. If some otherwise useful technology also enables pirating, then the industry should have to figure out how to deal with the consequences, not society as a whole.
Besides, if the industry wanted to make cryptographically secure DVDs, they could. DeCSS is a consequence of either technical incompetence or a deliberate attempt to test the laws on the part of its developers.
Determining whether their actions were "legal" or not is the whole point of the lawsuit. I don't read the law the way the MPAA suggests and neither do a lot of other people. Furthermore, there is the question of what lawmakers actually intended, and what we as citizens want to happen, something that needs to be resolved legislatively. Legal challenges are an intrinsic part of the US system of law and government; this case had to be brought.
What kind of government do you think operates in the US? Your kinds of arguments might be applicable in fascist or autocratic societies, but in a democratic society that is governed by the rule of law, court challenges and political participation are essential. That may annoy some lobbyists and legislators with vested financial interests, but it still needs to be done.
I find your arguments both dangerous and naive. Similar arguments have been made throughout history, and I suggest you read up on the consequences. Issues of corporate control of the media are of fundamental importance to our society, and this is not only a good cause, it's an essential cause.
It's the latter two categories of employees that give Microsoft its Borg-like quality: they haven't seen much of the industry, they truly believe that Microsoft is doing innovative stuff, and they aren't part of a professional community that spans companies (other than, perhaps, Microsoft spin-offs). Their lack of breadth and experience and the "learning on the job" shows in their products. Microsoft hires them early and molds them their way (just like previous monopolies and the military). Those people truly believe in the "Microsoft way" and they truly believe that Microsoft is bringing something valuable to the masses.
In order to agree with the overall vision, people don't have to agree with the company in each and every way. And it is Microsoft's overall vision and pretense that is at issue, not a few glitches in execution. People stay at Microsoft, despite having lots of other good jobs available to them, and that tells us pretty much all we need to know about their views and ethical choices.
Why worry about law enforcement listening in? After all, people shouldn't have an expectation of privacy on IRC. But I think a big concern is that law enforcement may be unfamiliar with the social conventions on IRC and will misinterpret phantasy and bragging as reality.
In Plan 9, programs communicate through the file system. Unlike UNIX, where most files are just static arrangements of bytes, that kind of communication in Plan 9 is much more dynamic. For example, the window system itself corresponds to a number of entries in the file system (somewhat like /proc). That makes it much easier than in UNIX for different applications to talk to one another while they are running, as well as to create building blocks that do fancy stuff with information that flows between programs. Plan 9 also borrowed from the Oberon system when it comes to interaction; adding new functionality to the GUI can actually be as simple as just creating a useful command string on the screen somewhere. You can activate it later by just pointing to it.