I frankly think its dangerous reliance on wishful thinking...
I don't even think that it's being thought of even at that level; it's not clear to me whether the advocates of BMD even care if it's possible. The goal is to spend a big chunk of cash on an expensive military project, and the prospects of developing a useful system out of it are secondary. Spending money on expensive military projects like this has three big benefits from the point of view of its advocates:
It shovels lots of money into the pockets of their friends in the Military/Industrial complex. You know that some of that money is going to find its way back into somebody's campaign fund.
It siphons money away from other potential uses, like social programs. I'm not sure why these people hate social programs so much, but it clearly isn't a general distaste for the government given how much they like using government money and power to further their own agendas
It gives them a big flag to wave at the next elections. There's nothing like blasting your opponent for not wanting to protect motherhood and apple pie to garner a few votes.
To meet these goals a project must be emotionally compelling, expensive, and far enough from being successful that you can keep throwing money at it for a long time. I'd say that BMD meets them pretty well. There's nothing like the threat of a city or two being blasted to provide emotional appeal (and forget about other ways that a bomb could be transported to them). Anything having to do with space is going to be god-awful expensive. BMD is also great in that you can almost always show some results (See! We were able to hit a missile when we knew when and where it was coming and it didn't have countermeasures.) but a system that can handle realistic threats will likely remain out of reach for the forseeable future. It's a big hole that you can keep shoveling money into forever while bashing anyone who complains that doing so it pointless.
I certainly agree that the CDC should be the responsible agency; it makes sense for the reasons you point out. The point is that as it currently stands nobody is officially in charge. AFAIK there isn't even a simple policy that says that the CDC is in charge and can ask for manpower help from the military if things get really hairy. That's indicative of the general level of planning and thought that's gone into defense against biological weapons, and I find that scary.
Let's be realistic, folks. Biological terrorism is the newest scare tactic. While the potential for serious danger is obviously there... frankly this _does_ sound like the prep work for asking for more defense money.
As somebody who's worked in the field (I did some work on detection systems) I can say that bioterrorism scares the shit out of me. It's something that's much more easily within the reach of a private organization than nuclear weapons, can cause a lot of damage, and would be very tough to stop once it got underway. It's also something that has not been adequately planned for, IMO, to the point that there's not even a reasonable idea about who would be in charge of dealing with it if it did happen.
OTOH, reasonable contingency planning and research into detection systems are not terribly expensive; my guess is that they're currently spending substantially less every year on bioterrorism than on one of those stupid anti-missile tests (as if a "Rogue" state would use a missile instead of smuggling a warhead into the country on a ship). Some simple precautions would not cost much, on the grand scale of things, while substantially helping the current woeful situation.
So, instead of having a script kid hacking into your site to download MP3, leaving lots of logs where you can pick you the flaw and fix it, you make certain that only the super hacker who will try stealing your CC number, putting a stealth module into your kernel, and don't leave you any trace of his presence will get into your system.
But it's not like leaving your system open to script kiddies is going to make it somehow less succeptible to super crackers- at least not if the super crackers have some motivation to go after you. So instead of getting rooted by a super hacker, the less obscured system will get rooted by the super hacker and a bunch of script kiddies. Not much of an improvement in my book.
I agree, but buffer overflows and format strings are the most common ones, and the ones which most easily lead to exploits.
This is exactly backward. Those particular exploits are the most common because there are so many system programs written in languages where they're the exploits of choice, and because exploit writers have lots of practice taking advantage of them. If you switched to a different language with a different set of pitfalls, you'd find that the exploits would be different but not necessarily any less damaging or less common. There might be something of a reprieve while the exploit writers got used to the taking advantage of a new set of problems, but there might very well be more errors to find because software authors were less used to the new pitfalls they're facing.
Security and usability are at the opposite ends of the computing spectrum.
That may be somewhat true, but it doesn't mean that there's necessarily a linear tradeoff between security and usability. For instance, turning off by default services that only advanced users will want to have available is a pretty good idea. Ordinary users aren't going to notice that they're missing anything, while the advanced users will be smart enough to know which things to turn on to get the services they want. The tradeoff there is a tiny bit of usability for a lot of increased security, which is a good deal.
Similarly, switching from a well designed single-user to a well-designed multi-user system should increase security quite a bit without excessive difficulty for the users. Users will still be able to do the kinds of things that they want without risk of their files being read/clobbered by another user. When they try to shoot themselves in the foot, though, the system kindly steps in and tells them that they need help from a sysadmin to do that. I find that this is nice even on my personal system that I don't share with anyone else; I've probably saved myself more grief by having a safety mechanism there to prevent stupid errors than the time wasted by suing to root.
One problem with this study, is that these people have had previous exposure to other platforms (MS Windows for example), so they have preconceived notions of how the interface should work. When something is not in the `right' place, they will be confused. This can explain a lot of the odd comments.
I don't see this as a problem but as an important condition of the test. After all, people with previous exposure to either Windows or Macs represent an important segment of the people who are likely to be trying out GNOME. The developers must make it possible and preferably easy and intuitive for people with previous non-*nix computer experience to switch to GNOME. That may very well mean bending the design to be closer to the way that other existing computer systems work.
I think that the argument is that by putting closely related functions together in a DLL they can minimize DLL memory consumption. If you separate code according to which MS program needs it, then programs that need code for both Windows and IE will need to load both the windows and IE DLLs. If, OTOH, you break the code down into different DLLs by functionality, you can load only the DLL containing the functions you need. This presumes that MS can predict which functions are likely to be used in the same program, though. Of course there's no reason that they couldn't do it both ways and break up the Windows specific and IE specific code into DLLs by functionality and Win/IE, so that you could load only some really small DLLs if you needed only a few functions.
The courts would actually use something much simpler than this. They would appoint a "Special Master" (I think that's the right term) who is basically someone who the court thinks is both knowledgable enough to tell if the code may have been swiped and honest enough not to blab any trade secrets. He is then given access to both codebases and looks them over to see if there's any evidence of wrongdoing. If he thinks that there's enough evidence to go forward, then the lawyers are allowed to subpoena the code and let their experts go over it with a fine toothed comb to find obviously snagged chunks of code. The code would probably remain under seal, though, which means that there would be very harsh penalties for letting anything slip (at least until after a determination that the code had been lifted and must be made available). If the final decision is that copyright violation has not taken place, anyone who did leak the trade secrets would be in deep trouble.
This brings up an even larger issue: if there is something that can only be accomplished one way, and people are likely to find the solution independently, should such a thing even be copyrightable (if that's a word)?
IANACRL (IANA Copyright L) but I think that this is misconstrues current copyright law. Copyright applies to a work and derived works, not to works that happen to be similar incidentally. IOW it would be a valid copyright defense to show that you came up with your idea independently even if it did look very similar to somebody else's implimentation. You could probably do with good record keeping. CVS entries, memos about design discussions, etc. could be used as evidence that your solution came from your own decision to approach the problem in a particular way and not from copying the other guys' code. It would eventually be up to a jury to decide wether the evidence favored you, and my gut feeling is that if you actually did come up with the idea independently and had documentary evidence to prove it that you could convince a jury.
The problem with the "your browser remembers everything" system is that it assumes that you always use the same browser. That just isn't the case, though. I have several browsers on my home computer- I dual boot, for instance, so I can't always use the same browser, even if I had a specific favorite- so I'd need to have the information stored in each browser. I also sometimes browse at work, where we have several shared computers, and I'd need information on each of those computers. The latter is particularly scary, since it would be comparatively easy for a coworker/ITS person to get my information from the computer. This kind of thing is not atypical, either. It might very well be more practical to have a networked server of some type that I could log onto from any browser for data storage and authentication.
If you can find a search engine that says "search for the top sites on the web that paid us money", then that would be honest and nothing to complain about.
You're looking for GoTo.com. They quite clearly and honestly state that their criterion for listing is the amount that the companies pay them. They even show exactly how much the company pays for each click-through! For some kinds of search it actually even makes sense; if you want to find a business, it's quite possibly reasonable to look at the ones that are willing to pay the most to attract your attention. It certainly helps to guarantee that they're being honest in the categories they're listed in, so they won't have to pay extra for erroneous click-throughs.
Your comment isn't quite right, either. It is true that the presumption of innocence is purely a legal concern; private citizens are allowed to believe whatever they please. But at some level the presumption of innocence applies in both civil and criminal cases. In both cases, the accuser (either prosecution or plaintiff) must present evidence that the accused has actually done something wrong before the case is allowed to proceed. It's true that after that point the burden of proof is lower in civil cases, but the plaintiff must still make a prima facie case before any real action can take place. That's a big part of what this ruling is about; the court is saying that the prima facie case must be made before the plaintiff can get court help in unmasking the identity of the anonymous speaker(s).
And in the Rio case, the appeals court rejected the RIAA argument that people have no right to copy music onto hard drives, saying that Fair Use applies to all media, not just AHRA-restricted ones.
Actually, that's not exactly what the court ruled in the Rio case. As I comment elsewhere, the Rio ruling was actually pretty narrow in scope. The court ruled that the Rio did not infringe the serial copy management provisions of the AHRA, and they did so for interesting but fairly narrowly legalistic reasons. Essentially, the AHRA requires serial copy managment protection only for devices that are designed primarily as recording devices. The Rio downloads songs only from computer hard drives, which are not covered by the copy managment provisions, so music can effectively be laundered by transfering it temporarily onto a hard drive. The court actually noted that this was odd but clearly the intent of the bill's authors. They did mention the Betamax precedent, though, and comment that the Rio's function was actually directly in line with the intent of the AHRA's intent of encouraging personal, non-commercial use.
If you look at the definition of digital audio recording device/medium, you will see that hard drives do not fall under that definition. Monkeydo is perfectly right that the Audio Home Recording Act does not protect against copying which doesn't occur on AHRA media or devices.
But you can argue the flip side as well. The requirement for copy protection schemes mentioned in the same section also applies only to digital audio recording devices/media, so one is not legally required to implement them on computers. IOW, making MP3s on your computer is either specifically protected because they're for non-commercial private use or is specifically exempted from the need for protections altogether because the computer isn't an audio recording device.
This is the essential issue in the Diamond Rio case. By copying music onto a hard drive, it ceases legally to be a digital audio recording because it is no longer stored on a digital audio recording medium! While this seems to be ridiculous, that is exactly what the Appeals Court ruling concluded:
The district court concluded that the exemption of hard drives from the definition of digital music recording, and the exemption of computers generally from the Act's ambit, "would effectively eviscerate the [Act] " because "[a]ny recording device could evade [ ] regulation simply by passing the music through a computer and ensuring that the MP3 file resided momentarily on the hard drive." RIAA I, 29 F. Supp. 2d at 630. While this may be true, the Act seems to have been expressly designed to create this loophole.
Thus, it appears that there is a specific legal precedent that allows circumvention of serial copy managment just by copying the data onto a computer hard drive, as it then ceases to be legally considered to be a digital audio recording. And the Appeal Court ruled that this was not only true by the language of the law but also by its legislative history:
In fact, the Rio's operation is entirely consistent with the Act's main purpose -- the facilitation of personal use. As the Senate Report explains, "[t]he purpose of[the Act] is to ensure the right of consumers to make analog or digital audio recordings of copyrighted music for their private, noncommercial use." S. Rep. 102-294, at *86 (emphasis added). The Act does so through its home taping exemption, see 17 U.S.C. S 1008, which "protects all noncommercial copying by consumers of digital and analog musical recordings, " H.R. Rep. 102-873(I), at *59. The Rio merely makes copies in order to render portable, or "space-shift," those files that already reside on a user's hard drive. Cf. Sony Corp. of America v. Universal City Studios, 464 U.S. 417, 455 (1984) (holding that "time-shifting" of copyrighted television shows with VCR's constitutes fair use under the Copyright Act, and thus is not an infringement). Such copying is paradigmatic non-commercial personal use entirely consistent with the purposes of the Act.
That appears to me to be a pretty strong argument that making MP3s so that you can take them with you is legally protected.
Making MP3's for you own use of CDs you own is also of dubious legality. Although no one would care if you weren't trading them on Napster, a digital copy of a digital work is ONLY legal if it made using media for which royalties have been paid and on a device that implements SCMS.
If you believe I am wrong please read this before flaiming.
Perhaps you should read it in depth youself, particularly the part right here where it says:
Sec. 1008. Prohibition on certain infringement actions
No action may be brought under this title alleging infringement of copyright based on the manufacture, importation, or distribution of a digital audio recording device, a digital audio recording medium, an analog recording device, or an analog recording medium, or based on the noncommercial use by a consumer of such a device or medium for making digital musical recordings or analog musical recordings.
That certainly seems to suggest that there is a loophole written into the law that says that personal, non-commercial use of such devices is specifically allowed. There is also no mention that the rule is changed if the recording is switched from one format to another, so this applies not only to copying from one CD to another but also to converting CDDA tracks to MP3s so that you can play them on your portable MP3 player.
Non-root installs may not be totally effective, but they're better than nothing. They may be able to steal your data, but as long as you don't run the package as root they shouldn't be able to add trojans to your system utilities, and that means that cleaning up your system should be a lot easier. And that's assuming the worst case of an actively malicious piece of software, rather than just a badly written one. If you're running a program with a serious security problem as root, you whole system can be compromised and (since it's binary only) you won't be able to fix the problem short of pulling the software. If it's running as a non-priviledged user then the damage from it being cracked will at least be somewhat contained.
I think that this is slightly off the mark. The difference in packaging formats is, IMO, a comparatively trivial complaint. It should be comparatively straightforward for just about any software supplier to provide both DEBs and RPMs for their software. It's not even a matter of recompiling, just repackaging. This shouldn't be enough to slow things down much at all, and the number of projects that allready do so is evidence of the fact. IMO the difference in package management needs to be resolved eventually, but I think that it's small enough that this is not the time for one side to ram it down the other side's throat.
OTOH, the lack of a standard desktop environment has the potential to be more of a problem. It's not trivial to make a package that plays nice with both KDE and GNOME, not to mention all of the people who will want to skip desktop environments alltogether and use just a lightweight window manager. IMO, though, the long term solution is not going to be forcing people to choose one or the other. Instead, GNOME and KDE will develop to the point that they interoperate smoothly, and disk space will get cheap enough that people won't complain about needing to keep both on their boxes to run arbitrary software. You can already run KDE apps on a GNOME desktop and vice versa (so long as you have both installed), so I'm not sure whether this is a really serious flaw, anyway.
If your system is really that valuable, though, you should invest some money in better security than passwords. Try as you may, passwords are never going to be really, really secure because users tend to subvert them. If you want real security you're going to need to add an extra level to the system, like smart cards or biometrics. Doing otherwise is like locking up your valuables with a skeleton key.
This is a reasonable point. I guess that I just didn't think about that because I can touch type and can use moderately long passwords that contain upper and lower case and punctuation without too much trouble. I can see that it might be a problem for other people, though. OTOH, I think that it's probably easier to type in a whole sentence blind than it is to remember a jibberish password- and I think of myself as having a pretty good memory. Of course if you're really serious about security you'll just give everyone a personalized smart card that generates time sensitive passwords anyway.
Of course on a modern system that uses MD5 passwords, it would be fine to use the whole sentence as the password (passphrase) instead of abbreviating it. Typing out something that long could get really annoying after a while, but if you're really interested in security it would be worth it. If the goal is to increase the keyspace, the simplest way to do it is to allow longer but still memorable passphrases, not to force people to remember gibberish.
The currently accepted theory about mad cow disease (and other transmissible spongiform encephalopathies like scrapie in sheep and kuru in humans) is that they don't involve DNA at all. They're transmitted by things called prions, which are a variant form of a naturally existing protein. The prion form of the protein causes the normal form to re-fold into the prion form, which keeps it from woring right and causes the condition to spread further. That means that the prion can be transmitted by eating the tissue from an infected organism. The prions are apparently somewhat resistant to transmission across species but much less so within a species. That's why the most famous form of transmissible spongiform encephalopathy in humans (kuru) was found in cannibals.
The problem with this argument is that the farm on which the plants are growing is nothing like a natural ecosystem anymore. We've already trashed the ecosystem by cutting down all of the plants and driving away most of the animals that would naturally live there and replacing them with a synthetic monoculture. Switching from a conventional strain of a plant to a GMO strain is a minor change compared to switching to a whole new species of plant. But people switch from growing, say, corn to sunflowers all the time without anyone bleating about how it's going to disrupt the fragile ecosystem.
Realistically, though, you can get something similar from Linux. If you stick to the most commonly used hardware, rather than trying the oddball stuff you describe, you can get very good support for it under Linux. In some cases it may be better than what you can get under a proprietary Unix like AIX because there are so many more people banging on the hardware and drivers and finding out what the problems are. And all of the big-name Linux vendors will know about it and its quirks. At the same time, you are less likely to be completely screwed if you happen to want or need some hardware that's a bit off the wall.
Slashdot Mirror
I don't even think that it's being thought of even at that level; it's not clear to me whether the advocates of BMD even care if it's possible. The goal is to spend a big chunk of cash on an expensive military project, and the prospects of developing a useful system out of it are secondary. Spending money on expensive military projects like this has three big benefits from the point of view of its advocates:
To meet these goals a project must be emotionally compelling, expensive, and far enough from being successful that you can keep throwing money at it for a long time. I'd say that BMD meets them pretty well. There's nothing like the threat of a city or two being blasted to provide emotional appeal (and forget about other ways that a bomb could be transported to them). Anything having to do with space is going to be god-awful expensive. BMD is also great in that you can almost always show some results (See! We were able to hit a missile when we knew when and where it was coming and it didn't have countermeasures.) but a system that can handle realistic threats will likely remain out of reach for the forseeable future. It's a big hole that you can keep shoveling money into forever while bashing anyone who complains that doing so it pointless.
I certainly agree that the CDC should be the responsible agency; it makes sense for the reasons you point out. The point is that as it currently stands nobody is officially in charge. AFAIK there isn't even a simple policy that says that the CDC is in charge and can ask for manpower help from the military if things get really hairy. That's indicative of the general level of planning and thought that's gone into defense against biological weapons, and I find that scary.
As somebody who's worked in the field (I did some work on detection systems) I can say that bioterrorism scares the shit out of me. It's something that's much more easily within the reach of a private organization than nuclear weapons, can cause a lot of damage, and would be very tough to stop once it got underway. It's also something that has not been adequately planned for, IMO, to the point that there's not even a reasonable idea about who would be in charge of dealing with it if it did happen.
OTOH, reasonable contingency planning and research into detection systems are not terribly expensive; my guess is that they're currently spending substantially less every year on bioterrorism than on one of those stupid anti-missile tests (as if a "Rogue" state would use a missile instead of smuggling a warhead into the country on a ship). Some simple precautions would not cost much, on the grand scale of things, while substantially helping the current woeful situation.
But it's not like leaving your system open to script kiddies is going to make it somehow less succeptible to super crackers- at least not if the super crackers have some motivation to go after you. So instead of getting rooted by a super hacker, the less obscured system will get rooted by the super hacker and a bunch of script kiddies. Not much of an improvement in my book.
This is exactly backward. Those particular exploits are the most common because there are so many system programs written in languages where they're the exploits of choice, and because exploit writers have lots of practice taking advantage of them. If you switched to a different language with a different set of pitfalls, you'd find that the exploits would be different but not necessarily any less damaging or less common. There might be something of a reprieve while the exploit writers got used to the taking advantage of a new set of problems, but there might very well be more errors to find because software authors were less used to the new pitfalls they're facing.
That may be somewhat true, but it doesn't mean that there's necessarily a linear tradeoff between security and usability. For instance, turning off by default services that only advanced users will want to have available is a pretty good idea. Ordinary users aren't going to notice that they're missing anything, while the advanced users will be smart enough to know which things to turn on to get the services they want. The tradeoff there is a tiny bit of usability for a lot of increased security, which is a good deal.
Similarly, switching from a well designed single-user to a well-designed multi-user system should increase security quite a bit without excessive difficulty for the users. Users will still be able to do the kinds of things that they want without risk of their files being read/clobbered by another user. When they try to shoot themselves in the foot, though, the system kindly steps in and tells them that they need help from a sysadmin to do that. I find that this is nice even on my personal system that I don't share with anyone else; I've probably saved myself more grief by having a safety mechanism there to prevent stupid errors than the time wasted by suing to root.
I don't see this as a problem but as an important condition of the test. After all, people with previous exposure to either Windows or Macs represent an important segment of the people who are likely to be trying out GNOME. The developers must make it possible and preferably easy and intuitive for people with previous non-*nix computer experience to switch to GNOME. That may very well mean bending the design to be closer to the way that other existing computer systems work.
I think that the argument is that by putting closely related functions together in a DLL they can minimize DLL memory consumption. If you separate code according to which MS program needs it, then programs that need code for both Windows and IE will need to load both the windows and IE DLLs. If, OTOH, you break the code down into different DLLs by functionality, you can load only the DLL containing the functions you need. This presumes that MS can predict which functions are likely to be used in the same program, though. Of course there's no reason that they couldn't do it both ways and break up the Windows specific and IE specific code into DLLs by functionality and Win/IE, so that you could load only some really small DLLs if you needed only a few functions.
Shouldn't that be:
The courts would actually use something much simpler than this. They would appoint a "Special Master" (I think that's the right term) who is basically someone who the court thinks is both knowledgable enough to tell if the code may have been swiped and honest enough not to blab any trade secrets. He is then given access to both codebases and looks them over to see if there's any evidence of wrongdoing. If he thinks that there's enough evidence to go forward, then the lawyers are allowed to subpoena the code and let their experts go over it with a fine toothed comb to find obviously snagged chunks of code. The code would probably remain under seal, though, which means that there would be very harsh penalties for letting anything slip (at least until after a determination that the code had been lifted and must be made available). If the final decision is that copyright violation has not taken place, anyone who did leak the trade secrets would be in deep trouble.
IANACRL (IANA Copyright L) but I think that this is misconstrues current copyright law. Copyright applies to a work and derived works, not to works that happen to be similar incidentally. IOW it would be a valid copyright defense to show that you came up with your idea independently even if it did look very similar to somebody else's implimentation. You could probably do with good record keeping. CVS entries, memos about design discussions, etc. could be used as evidence that your solution came from your own decision to approach the problem in a particular way and not from copying the other guys' code. It would eventually be up to a jury to decide wether the evidence favored you, and my gut feeling is that if you actually did come up with the idea independently and had documentary evidence to prove it that you could convince a jury.
The problem with the "your browser remembers everything" system is that it assumes that you always use the same browser. That just isn't the case, though. I have several browsers on my home computer- I dual boot, for instance, so I can't always use the same browser, even if I had a specific favorite- so I'd need to have the information stored in each browser. I also sometimes browse at work, where we have several shared computers, and I'd need information on each of those computers. The latter is particularly scary, since it would be comparatively easy for a coworker/ITS person to get my information from the computer. This kind of thing is not atypical, either. It might very well be more practical to have a networked server of some type that I could log onto from any browser for data storage and authentication.
You're looking for GoTo.com. They quite clearly and honestly state that their criterion for listing is the amount that the companies pay them. They even show exactly how much the company pays for each click-through! For some kinds of search it actually even makes sense; if you want to find a business, it's quite possibly reasonable to look at the ones that are willing to pay the most to attract your attention. It certainly helps to guarantee that they're being honest in the categories they're listed in, so they won't have to pay extra for erroneous click-throughs.
Your comment isn't quite right, either. It is true that the presumption of innocence is purely a legal concern; private citizens are allowed to believe whatever they please. But at some level the presumption of innocence applies in both civil and criminal cases. In both cases, the accuser (either prosecution or plaintiff) must present evidence that the accused has actually done something wrong before the case is allowed to proceed. It's true that after that point the burden of proof is lower in civil cases, but the plaintiff must still make a prima facie case before any real action can take place. That's a big part of what this ruling is about; the court is saying that the prima facie case must be made before the plaintiff can get court help in unmasking the identity of the anonymous speaker(s).
Actually, that's not exactly what the court ruled in the Rio case. As I comment elsewhere, the Rio ruling was actually pretty narrow in scope. The court ruled that the Rio did not infringe the serial copy management provisions of the AHRA, and they did so for interesting but fairly narrowly legalistic reasons. Essentially, the AHRA requires serial copy managment protection only for devices that are designed primarily as recording devices. The Rio downloads songs only from computer hard drives, which are not covered by the copy managment provisions, so music can effectively be laundered by transfering it temporarily onto a hard drive. The court actually noted that this was odd but clearly the intent of the bill's authors. They did mention the Betamax precedent, though, and comment that the Rio's function was actually directly in line with the intent of the AHRA's intent of encouraging personal, non-commercial use.
But you can argue the flip side as well. The requirement for copy protection schemes mentioned in the same section also applies only to digital audio recording devices/media, so one is not legally required to implement them on computers. IOW, making MP3s on your computer is either specifically protected because they're for non-commercial private use or is specifically exempted from the need for protections altogether because the computer isn't an audio recording device.
This is the essential issue in the Diamond Rio case. By copying music onto a hard drive, it ceases legally to be a digital audio recording because it is no longer stored on a digital audio recording medium! While this seems to be ridiculous, that is exactly what the Appeals Court ruling concluded:
Thus, it appears that there is a specific legal precedent that allows circumvention of serial copy managment just by copying the data onto a computer hard drive, as it then ceases to be legally considered to be a digital audio recording. And the Appeal Court ruled that this was not only true by the language of the law but also by its legislative history:
That appears to me to be a pretty strong argument that making MP3s so that you can take them with you is legally protected.
Perhaps you should read it in depth youself, particularly the part right here where it says:
That certainly seems to suggest that there is a loophole written into the law that says that personal, non-commercial use of such devices is specifically allowed. There is also no mention that the rule is changed if the recording is switched from one format to another, so this applies not only to copying from one CD to another but also to converting CDDA tracks to MP3s so that you can play them on your portable MP3 player.
Non-root installs may not be totally effective, but they're better than nothing. They may be able to steal your data, but as long as you don't run the package as root they shouldn't be able to add trojans to your system utilities, and that means that cleaning up your system should be a lot easier. And that's assuming the worst case of an actively malicious piece of software, rather than just a badly written one. If you're running a program with a serious security problem as root, you whole system can be compromised and (since it's binary only) you won't be able to fix the problem short of pulling the software. If it's running as a non-priviledged user then the damage from it being cracked will at least be somewhat contained.
I think that this is slightly off the mark. The difference in packaging formats is, IMO, a comparatively trivial complaint. It should be comparatively straightforward for just about any software supplier to provide both DEBs and RPMs for their software. It's not even a matter of recompiling, just repackaging. This shouldn't be enough to slow things down much at all, and the number of projects that allready do so is evidence of the fact. IMO the difference in package management needs to be resolved eventually, but I think that it's small enough that this is not the time for one side to ram it down the other side's throat.
OTOH, the lack of a standard desktop environment has the potential to be more of a problem. It's not trivial to make a package that plays nice with both KDE and GNOME, not to mention all of the people who will want to skip desktop environments alltogether and use just a lightweight window manager. IMO, though, the long term solution is not going to be forcing people to choose one or the other. Instead, GNOME and KDE will develop to the point that they interoperate smoothly, and disk space will get cheap enough that people won't complain about needing to keep both on their boxes to run arbitrary software. You can already run KDE apps on a GNOME desktop and vice versa (so long as you have both installed), so I'm not sure whether this is a really serious flaw, anyway.
If your system is really that valuable, though, you should invest some money in better security than passwords. Try as you may, passwords are never going to be really, really secure because users tend to subvert them. If you want real security you're going to need to add an extra level to the system, like smart cards or biometrics. Doing otherwise is like locking up your valuables with a skeleton key.
This is a reasonable point. I guess that I just didn't think about that because I can touch type and can use moderately long passwords that contain upper and lower case and punctuation without too much trouble. I can see that it might be a problem for other people, though. OTOH, I think that it's probably easier to type in a whole sentence blind than it is to remember a jibberish password- and I think of myself as having a pretty good memory. Of course if you're really serious about security you'll just give everyone a personalized smart card that generates time sensitive passwords anyway.
Of course on a modern system that uses MD5 passwords, it would be fine to use the whole sentence as the password (passphrase) instead of abbreviating it. Typing out something that long could get really annoying after a while, but if you're really interested in security it would be worth it. If the goal is to increase the keyspace, the simplest way to do it is to allow longer but still memorable passphrases, not to force people to remember gibberish.
The currently accepted theory about mad cow disease (and other transmissible spongiform encephalopathies like scrapie in sheep and kuru in humans) is that they don't involve DNA at all. They're transmitted by things called prions, which are a variant form of a naturally existing protein. The prion form of the protein causes the normal form to re-fold into the prion form, which keeps it from woring right and causes the condition to spread further. That means that the prion can be transmitted by eating the tissue from an infected organism. The prions are apparently somewhat resistant to transmission across species but much less so within a species. That's why the most famous form of transmissible spongiform encephalopathy in humans (kuru) was found in cannibals.
The problem with this argument is that the farm on which the plants are growing is nothing like a natural ecosystem anymore. We've already trashed the ecosystem by cutting down all of the plants and driving away most of the animals that would naturally live there and replacing them with a synthetic monoculture. Switching from a conventional strain of a plant to a GMO strain is a minor change compared to switching to a whole new species of plant. But people switch from growing, say, corn to sunflowers all the time without anyone bleating about how it's going to disrupt the fragile ecosystem.
Realistically, though, you can get something similar from Linux. If you stick to the most commonly used hardware, rather than trying the oddball stuff you describe, you can get very good support for it under Linux. In some cases it may be better than what you can get under a proprietary Unix like AIX because there are so many more people banging on the hardware and drivers and finding out what the problems are. And all of the big-name Linux vendors will know about it and its quirks. At the same time, you are less likely to be completely screwed if you happen to want or need some hardware that's a bit off the wall.