Thanks for the mirror, too bad/. clipped the end of it there.
All I can say is that I share Mr. Goldstein's shock and dismay, and I'm spreading the word about this travesty of justice to everybody I know. Most non-hackers that I talk to are amazed that such a thing can go on in the land of the free. We need to get out and tell real people about this - tell your brother, your Mom, your boss, and try to explain that justice has not been served. Mr. Goldstein covers this territory more eloquently than I could ever hope, so I'll close with another exhortation to get the word out about this.
...posted from behind a firewall that keeps out those "evil 2600 hackers"...
I don't know about the rest of you but i don't have enough bandwidth for the text based internet as it is.(It really suck
living at the end of a copper line, Max = 26.4 kbps)
Maybe you should get a PIII to make the Internet faster:)
They charge a fee for the service of assisting in the commission of what
is - with very high probability - a crime. This can be construed as criminal behavior.
They charge a fee? I'm not a Napster user because I generally respect copyright laws, but my impression was that it was free. Sure, they sell ads, but it's not like they're charging users a fee. You can hardly say they're profiting since they're losing money hand-over-fist.
I think they are a good example of intellectual freedom - they're pointing out the dirty little secret that the recording industry has been trying to hide all along: their customers don't agree with copyright restrictions and are happy to work around them. Since the recording industry can't really go after their customers (it worked so well for Metallica), they have to go after the middleman before the public at large figures out how useless the RIAA really is.
Napster's service is no different from Google's, except that the interface is nicer (not a crime), the subject matter is more specialized (mp3s are legal, so again not a crime) and the majority of their users use it to commit copyright infringement. Should Napster be penalized for providing a tool for a purpose that apparently has huge public support, from which they do not profit, and which remains within the letter of the law?
The question is, if such a rate can't be guaranteed, why did SBC guarantee it? Or did they? If they said they would provide it but have not, the fact that it is impossible for them to provide such connection speeds doesn't matter.
This case will just resolve whether they baited and switched their subscribers or not. If there was never a possibility that they could provide the promised service, then maybe they should have written a different contract.
But to get back to the topic, OSS isn't always the solution. Many of the projects I've worked on
couldn't be open sourced... too many proprietary issues, government content, or built to work with
expensive, proprietary, third-party systems almost no OSS developer would have experience with,
let alone have a personal copy of to test the software.
That's really true - especially if you work in the embedded world (not i-opener embedded, where it's really a PC motherboard - I'm talking custom HW all the way) it's going to be tough to get enough developer mindshare in the open source community, since development requires expensive hardware, tools to load the SW into the HW (eeprom programmer, etc), expensive emulators for non-standard (read non-x86) processors, etc. And if gcc doesn't support your processor, you're dead in the water. ESR said something about this in the Magic Cauldron - if there aren't a ton of people out there who already own the hardware to try your software on, and if there isn't a real interest in running your SW (besides just "let's get linux/X to run on this new handheld"), then you're going to have a tough time open sourcing it. Open source software is user-centered in that the users are developers who scratch their itches, but with embedded systems it's a lot harder to scratch that itch.
Not that it's going to be a bad idea to open your code on general principles, as long as you're sure you won't give away HW details or expose how lax your security practices have been in the past. But that doesn't give you much of an argument to take to management.
It's amazing how many otherwise rational adults don't understand that you can't gain immense productivity today without accepting significant costs in the future. I'm not opposed to working on internet time for V1.0 of a product, as long as customers, marketing, etc. realize that the cost of "internet time" is that the cycle time for V2.0 will be about four times as long, as we fix all the mistakes from the first release.
OK, I lied - I personally would be opposed to working like that, because I'd rather do things right once than half-right n times, but as long as you're not easily bored it might work for you:)
The embedded marketplace (where I'm at) is a little nicer right now - since you're more closely tied to the HW which doesn't change instantly, there's not as much push to turn the accompanying SW on a dime. Really, until the world at large understands that building quality SW requires the same sort of overhead as building a bridge, we'll never really have the time to do things right. Software is magic to most people, and magic just takes a wave of the wand, right?
You need management support pronto, because what you have to do is get enough time to understand what you already have done, look for big architectural flaws that will force you to work around them for the rest of your life, and think about where you're going. If you don't control your schedule (and it sounds like you don't) you have to convince the folks who do that there is a benefit to proper planning.
If this is more than a one-off project, if somebody will have to maintain it, you should try to get some more time to document your architecture and design decisions and write some tests. You can get tools that make generating test & test drivers a lot easier. You can save time now by not documenting and not producing test cases, but you will lose two or three times that much time in the long run. If you know there will never be any maintenance on your product, then you can't make as good of an argument for these things.
Tailor your process. You don't have to do line-by-line Fagan reviews of your code if the extra attention to detail isn't finding more bugs, for example.
Contrariwise, if you find that you're using code to paper over serious architecture flaws, then you know to have more complete architecture reviews next time. But your time in peer reviews has to be well spent - if you're on a deadline, have everyone review ahead of time and just hit the biggest issues at a meeting, with minor issues discussed over email. If you make peer reviews a hell to conduct and attend, you won't gain anything from them. If you make reviews easy to attend, you will generally get good comments. Invite subject matter experts if you have 'em; even if they aren't on your exact project (or sometimes because they aren't) they often bring up vital issues that you'd never think of.
Document how you've tailored things, so that everyone knows what steps they have to take their code through to get it in. Enforce some sort of policy so that there is at least one peer review of everyone's code before it goes into the product, because once it's in you may never come back to look at it until it's too late to fix it.
You really need management support or ownership of your schedule in order to make time to do these things. Once you have time to do these things you will find yourself worrying less about bits of code and more about architectural issues up front. This is good because anybody can write code, but not everybody can take the larger view of the product as a software system and pinpoint the weak links or missed requirements in your plans.
Marketing owning the user interface isn't necessarily a bad thing. What's bad is if they are allowed to dictate your schedule so that you end up using poor design or bad code to make up the time. Again, you need management support so that you can tell marketing there will be a cost for any new/changed requirements, and the cost will include time to fully document those requirements (including peer review if possible), time to implement them, and time to test them. Marketing isn't automatically bad, they just don't have any SW engineering experience to know what is possible and what the costs of things are. You have to reiterate this to them until they realize that their actions have consequences. It's sort of like training a puppy.
If you're spending most of your time coding, trying to get it to compile, or debugging, then you didn't spend enough time up front. Aim to spend most of your time testing, because you'll need it. The worse your development process, the more test time you'll need unless you want to compromise product quality. This is another good topic to bring up to management.
Adding staff to a late project makes it later - but not always. If you divide up responsibilities, you can have new staff do coding from your design documents while the more experienced staff write test cases or look into design/architecture problems. It sounds like your project might be in that sort of situation - you can get coders fairly cheaply (in terms of time, although maybe not in terms of salary) but people who understand the SW system as a whole and are conversant with the design philosophy have better things to do than generate code or test.
If you have really good requirements and/or test cases, you can hand off testing to an outside group entirely, but that requires more time up front and more budget. It is a good way to find a lot of bugs quickly, though.
Wow, that got long. Hopefully some of it was useful.
I work for probably the most process-heavy, Dilbert-inspired corporate monolith around. We do have an intricate process involving frequent peer reviews of code, documentation, and architecture, combined with gate-keeping by senior designers who determine what is good enough to go into the final product. And y'know what, correct application of the correct process really does make our lives as software engineers easier. Reviews of requirements and architecture up front reduce the amount of re-coding we have to do at coding time, so much so that our time breakdown is something like 40% up-front documentation (including test cases), only 10-20% coding, and we have the rest of the time left to exhaustively test the thing. Sure, things aren't always so rosy for every single project and feature, but overall my impression is that you can get a lot of gain out of your process if you invest in it up front.
Some of the gains aren't evident right away, but full test case suites, requirements, and architecture documents make your results more maintainable. We still have 10 year old code in our product; because it was documented, we know that it still works, and we have tests to prove it. We're not in a situation of "don't change this magic code or the product will never work again".
The most important thing, though, is management support. It's true, we could turn around our product three times as fast without all of the process overhead, and I think sometimes management is tempted to go that way. But without documentation, etc., we wouldn't be able to keep up that pace for 10-15 years on a single product. Our release dates would gradually slip more and more, as the combination of all of our earlier shortcuts came back to hurt us. I see this happening to a lot of PC software companies (I'm in embedded systems) and it's painful to watch.
You really have to have a corporate-wide committment to software quality, up-front design and documentation, and a repeatable process, but if you're really in the software business to stay, I think it's worth it. SW engineering process is the stuff that was both tremendously boring and incredibly obvious in school, but it does work well if you take the time to use it.
You need to read this: http://www.negativland.com/minidis.html to get an idea of how fast a format can go away when big money gets behind the new thing. I'm not saying it's a done deal, since consumers effectively deep-sixed DivX, but I don't think CD's are nearly as permanent as you think they will be.
Copyright law are built around the concept of
preventing other people from creating.
That is so backwards - copyright was originally intended to reward creativity by providing authors a limited opportunity to be the sole beneficiary of the profit from their work. Copyright law doesn't prevent creating at all, it just specifies who has the right to copy (i.e. distribute) a work that has already been created.
Napster is providing an index of users who may be (probably most are) violating current copyright law. My opinion is that the copyright holders should go after those who are infringing on their copyrights, not after an indexing service. Under the DMCA service providers (common carriers) are exempt from prosecution as long as they remove infringing users when notified. Napster has done so and has followed the letter of the law with regard to copyright as far as I know.
The real issue is that the recording industry is too lazy to go after millions of copyright violators, and would rather shoot the messenger instead. I don't blame them for being lazy (tracking down and prosecuting all of those users would be essentially impossible) but that doesn't make their actions ethical or right. The sooner they realize that the world has moved on, the fewer people will be hurt by their reflexive legal lashing out at all and sundry.
The important phrase is "small-scale". Downloading music continues to be legal AFAIK, but distributing it to millions of others over Napster or Gnutella is probably not exempt. Small-scale is aimed at making a tape for your friend, not for a million of your friends.
This is much like making it legal to own and smoke pot, merely illegal to be a
pot dealer.
Speaking of smoking, in some states it is illegal for a minor (under 16, usually) to purchase cigarettes, but not illegal to possess them. I have no idea why, but it's sort of the same situation. IMHO pot smokers shouldn't be tossed in prison just for smoking, since they're not violent or dangerous to society. If pot needs to be illegal, a stiff fine and/or community service would be more appropriate as far as I'm concerned. Now if they were knocking over convenience stores for cash to feed their monkey, that would be different.
Sure, KMail is a separate application. However, it is distributed with KDE, it requires KDE libraries and won't function without them, its bugs are tracked through bugs.kde.org, and so forth. As far as a user could tell, it is pretty intertwined with KDE the environment. Sure I could just use Netscape - my complaint is not necessarily about a bug in KMail, because Lord knows Netscape has plenty of bugs too. My complaint is that the KDE team in my very limited experience doesn't practice good user/developer relations. Part of this opinion I draw from the KDE developer that I corresponded with, and most of it I draw from the fact that the KDE 1.1.2 release hasn't had many bug fixes rolled into it due to work on KDE 2.0.
The relative merits of patches to KDE 1.1.2 versus new development for KDE 2.0 are up to the KDE development team, not to me. But since I as a user prefer to get bug fixes now for the desktop environment that I use, rather than wait a year or two for a whole new and improved environment, IMHO Gnome currently has a better development model.
So no, installing Gnome will probably replace some niggling unhappinesses that I have with KDE with equivalent Gnome ones, resulting in the total number of outstanding bugs remaining the same. But my impression as a user is that the Gnome development model is more open, more willing to accept bug fixes and features contributed by users such as myself, and more willing to turn around those fixes back to the population of other users. That's probably why I now use mostly Gnome apps on my KDE desktop.
As I said before, these are just my opinions based on my limited experiences. You're quite welcome to have other opinions based on your experiences; I don't want to convert anybody, I just wanted to bring out my thoughts (although I note that you didn't really have any contrary experiences to relate, you just provided some flamage of my opinions, which is exactly what I didn't want to provoke, but oh well).
According to the ruling (as described on C|Net this morning), part of the reason the judge ruled against 2600 was that they linked directly to the files on the other sites. So maybe you would be safe to just say "well, we can't provide DeCSS, but please patronize these other sites in the save DeCSS webring", and when you go to those other sites they have a big DeCSS link on the front page?
I think that ruling against linking is a slippery slope - where do you draw the line that 2600 is no longer distributing something? If they can be liable for something that is stored on a machine they don't control, they really can be held liable for a lot of things. Especially since as a hacker site they usually have the first links to projects that are pushing the envelope.
This ruling is a strong blow against the underpinnings of the Web, no matter how the judge says that it wouldn't affect other circumstances. Linking is no more illegal than the phone books are if they publish the phone numbers of known criminals. Unfortunately, rulings like this may seriously cripple the 'net before we can get some people who really "get it" into positions of authority.
Qt scroll bars (or at least the ones that most KDE apps use) don't let you middle-click to position them. That is a major pain, since it is a big departure from standard *nix look-and-feel (well, Motif, but in some regards it is a good standard). Since this causes me to run mostly Gnome apps under KDE, I feel a lot more pull to just switch to Gnome entirely.
OK, I'll bite. I installed Mandrake+KDE on my home desktop machine because I promised my wife that Linux would look almost exactly like windows. That's more-or-less what I got with KDE (I have some different themes that I use but she's sticking to plain vanilla KDE look and feel). The only bugs that cause us real trouble are the usual Netscape 4.x problems (hopefully soon to be a thing of the past), and some minor issues with kmail and the KDE biff program. However, if I had to do it all over again, at this point I'd probably install Gnome. Here's why:
Gnome seems to be under active development more right now. I know that KDE 2.0 is sucking up all of the KDE development team's time right now, but for a long time their efforts weren't publicized and it seemed like they were resting on their laurels. Gnome on the other hand suffered some bad PR for going 1.0 a little early, but has more than made up for that since then. Gnome seems to have taken more of an evolutionary path whereas KDE 2.0 is going to be revolutionary, but I would have liked to see some of the improvements from KDE 2.0 rolled back into the 1.x line for those of us who have been using 1.1.2 for a while. I prefer gradual incremental changes to major disruptions.
The KDE team hasn't been real responsive to user-submitted bug fixes. I had some problems with kmail, found and fixed a bug, and sent it in to bugs.kde.org. I heard nothing. Two or three months later I got an email saying that although it was a good fix, few people would ever see the bug and thus it would not be applied. I consider this bad user relations - I see this particular bug often (it concerns date handling for emails you receive from other email clients with broken date handling) and it wouldn't hurt the other 99% of users to pick up such a bug fix, but it would help the 1% who do see the problem. So that sort of left a bitter taste in my mouth. I was corresponding with one person and not with the whole KDE project, so I don't want to tar the whole team with this brush, but it really was a different response than the other open source projects to which I've sent bug fixes.
At the time that I installed Mandrake+KDE, I hadn't had any real experience with Gnome. After having looked at it some more and seen the neat things that the Helixcode and Eazel groups are doing, I'm much more interested in trying Gnome. This, combined with the fact that I'm not liking Mandrake so much any more, means that my next install will probably be Debian+Gnome. The biggest reason that I picked KDE in the first place was so that it would look like windows for my wife, but Gnome has a task bar, a desktop, etc. like she's become used to in KDE, so I don't think switching to Gnome will be too tough for her now.
Note that these are all my personal opinions and perceptions based on my experiences, not a flame directed at any of the development groups. I appreciate the efforts of the many desktop environment hackers out there and am happy to be able to make use of their efforts at home.
I dunno, in this case it seems more like (assuming that violating the DMCA is a crime) 2600 is committing a crime, and other sites are committing a crime, and 2600 is pointing out that other sites are committing a crime. Then the plaintiffs went after 2600 for committing a crime and for pointing out others who are doing so, rather than just going after everyone who is committing a crime.
I'm not sure if linking to those other sites is actually encouraging them to commit a crime, though. Distributing DeCSS is a crime but possessing it is not, so the only criminals would be the hosting sites. And presumably they were already hosting it before 2600 linked to them, otherwise 2600 wouldn't have linked to them. So I don't think the linking encouraged the crime; any crime that was committed by those mirror sites was already under way before they were linked from 2600.
The only way that I could see it as encouraging would be from an PR standpoint - if you wanted to get known in the hacker community, serving as a mirror for 2600 in this case would probably raise your standing. But that's a pretty tenuous connection IMHO.
I posted originally before reading the section which you quoted - it does explain a few things, thanks. I still don't agree with it, but oh well:)
Well, in the U.S. the principle of Judicial Review allows the judiciary to strike down laws that they find are inconsistent with the U.S. Constitution. It is the duty of the judiciary (as codified by precedent although not really by the Constitution) to disagree with the philosophy of a law if that law is wrong. So technically no judge is "merely an executor", although in practice I'm sure that only a fairly high-level court would overturn such a federal law. I don't know if Judge Kaplan was high-level enough.
We need to get the law changed.
Judicial review is the best way to get it overturned - the judiciary is not beholden to the recording industry the way that Congress is. There are plenty of Sonny Bonos (OK, that was a little bit of an oblique reference) in Congress who are happy to support the DMCA; it is not likely to be overturned by the legislature.
It looks like this judge is ruling merely on the merits of the DMCA as passed by Congress, rather than considering the larger question of whether the law is constitutional. Perhaps at this level of the legal system the judiciary is unwilling (or unable, IANACS (constitutional scholar)) to overturn a federal law as unconstitutional. I think it was pretty clear on the basis of the past few months activities that this case would go against the defendants.
The DMCA itself is bad enough, but the upholding of an injunction against the defendants linking to freely available information (well, at least until the hosting sites are also sued) is really troubling. I hope that facet of the case is an important part of the appeal as well; otherwise the New York Times and other major news venues will have to watch what they link to. If linking to a site with controversial content is prohibited, how about linking to a site that does the linking? For that matter, how about linking to AltaVista?
This ruling represents an unconscionable attack on the underpinnings of the Internet. The powers-that-be have won the first battle to halt the changes that are coming to the world they own; I hope that the EFF, Mr. Garbus, and other people of good will are able to win the war for freedom of information and the right to free speech online, even if it does hurt someone's bottom line.
Wow, sounds like all we need are CSS-style region codes for the broadcasts and we're all set, right? Oh, wait - region codes are a bad thing.
Not that it's your fault, but one-day-delayed clips still don't address the real problem: for U.S. audiences, there will be no live coverage of the Olympics by any means - no TV, radio, or 'net broadcasts.
IOC: Aim carefully at foot, and gently pull the trigger.
I do turn them off, but unfortunately there are still some knobs who apparently paste them into the main comment box specifically to torque me. The cadfu guy is particularly annoying about this.
You hit the nail on the head - having a variety of clients does help those users avoid the most common, average attacks, because the most-used attacks will be the attacks that can do a lot of damage and hit a lot of machines. So while there is no intrinsic security increase in the actual code of any one email client, overall a system of users with heterogenous clients will have a lower overall amount of problems than a system of users with homogenous clients. So while my Netscape mail might not be intrinsically more secure than Outlook (although it is, but that's another story) the fact that I use a non-standard client with respect to the rest of my company means that I haven't had any downtime due to email worms this year, whereas some of my coworkers have.
The fact that there are ten flavors of Unix doesn't make each one any more secure. But the fact that a computer network is composed of many different OSes rather than just one does increase higher overall security for the entire network, because attacks are usually targeted for a very specific OS+hardware combo.
Slashdot Mirror
I am Emmanuel Goldstein.
I am Emmanuel Goldstein.
I am Emmanuel Goldstein.
I am Emmanuel Goldstein, and regardless of recent legal precedent, I see four lights.
Thanks for the mirror, too bad /. clipped the end of it there.
All I can say is that I share Mr. Goldstein's shock and dismay, and I'm spreading the word about this travesty of justice to everybody I know. Most non-hackers that I talk to are amazed that such a thing can go on in the land of the free. We need to get out and tell real people about this - tell your brother, your Mom, your boss, and try to explain that justice has not been served. Mr. Goldstein covers this territory more eloquently than I could ever hope, so I'll close with another exhortation to get the word out about this.
...posted from behind a firewall that keeps out those "evil 2600 hackers"...
...for those of us behind overzealous (I could say more, but I'm trying to be positive) corporate firewalls.
Maybe you should get a PIII to make the Internet faster :)
They charge a fee? I'm not a Napster user because I generally respect copyright laws, but my impression was that it was free. Sure, they sell ads, but it's not like they're charging users a fee. You can hardly say they're profiting since they're losing money hand-over-fist.
I think they are a good example of intellectual freedom - they're pointing out the dirty little secret that the recording industry has been trying to hide all along: their customers don't agree with copyright restrictions and are happy to work around them. Since the recording industry can't really go after their customers (it worked so well for Metallica), they have to go after the middleman before the public at large figures out how useless the RIAA really is.
Napster's service is no different from Google's, except that the interface is nicer (not a crime), the subject matter is more specialized (mp3s are legal, so again not a crime) and the majority of their users use it to commit copyright infringement. Should Napster be penalized for providing a tool for a purpose that apparently has huge public support, from which they do not profit, and which remains within the letter of the law?
The question is, if such a rate can't be guaranteed, why did SBC guarantee it? Or did they? If they said they would provide it but have not, the fact that it is impossible for them to provide such connection speeds doesn't matter.
This case will just resolve whether they baited and switched their subscribers or not. If there was never a possibility that they could provide the promised service, then maybe they should have written a different contract.
That's really true - especially if you work in the embedded world (not i-opener embedded, where it's really a PC motherboard - I'm talking custom HW all the way) it's going to be tough to get enough developer mindshare in the open source community, since development requires expensive hardware, tools to load the SW into the HW (eeprom programmer, etc), expensive emulators for non-standard (read non-x86) processors, etc. And if gcc doesn't support your processor, you're dead in the water. ESR said something about this in the Magic Cauldron - if there aren't a ton of people out there who already own the hardware to try your software on, and if there isn't a real interest in running your SW (besides just "let's get linux/X to run on this new handheld"), then you're going to have a tough time open sourcing it. Open source software is user-centered in that the users are developers who scratch their itches, but with embedded systems it's a lot harder to scratch that itch.
Not that it's going to be a bad idea to open your code on general principles, as long as you're sure you won't give away HW details or expose how lax your security practices have been in the past. But that doesn't give you much of an argument to take to management.
It's amazing how many otherwise rational adults don't understand that you can't gain immense productivity today without accepting significant costs in the future. I'm not opposed to working on internet time for V1.0 of a product, as long as customers, marketing, etc. realize that the cost of "internet time" is that the cycle time for V2.0 will be about four times as long, as we fix all the mistakes from the first release.
OK, I lied - I personally would be opposed to working like that, because I'd rather do things right once than half-right n times, but as long as you're not easily bored it might work for you :)
The embedded marketplace (where I'm at) is a little nicer right now - since you're more closely tied to the HW which doesn't change instantly, there's not as much push to turn the accompanying SW on a dime. Really, until the world at large understands that building quality SW requires the same sort of overhead as building a bridge, we'll never really have the time to do things right. Software is magic to most people, and magic just takes a wave of the wand, right?
Some random thoughts:
Wow, that got long. Hopefully some of it was useful.
I work for probably the most process-heavy, Dilbert-inspired corporate monolith around. We do have an intricate process involving frequent peer reviews of code, documentation, and architecture, combined with gate-keeping by senior designers who determine what is good enough to go into the final product. And y'know what, correct application of the correct process really does make our lives as software engineers easier. Reviews of requirements and architecture up front reduce the amount of re-coding we have to do at coding time, so much so that our time breakdown is something like 40% up-front documentation (including test cases), only 10-20% coding, and we have the rest of the time left to exhaustively test the thing. Sure, things aren't always so rosy for every single project and feature, but overall my impression is that you can get a lot of gain out of your process if you invest in it up front.
Some of the gains aren't evident right away, but full test case suites, requirements, and architecture documents make your results more maintainable. We still have 10 year old code in our product; because it was documented, we know that it still works, and we have tests to prove it. We're not in a situation of "don't change this magic code or the product will never work again".
The most important thing, though, is management support. It's true, we could turn around our product three times as fast without all of the process overhead, and I think sometimes management is tempted to go that way. But without documentation, etc., we wouldn't be able to keep up that pace for 10-15 years on a single product. Our release dates would gradually slip more and more, as the combination of all of our earlier shortcuts came back to hurt us. I see this happening to a lot of PC software companies (I'm in embedded systems) and it's painful to watch.
You really have to have a corporate-wide committment to software quality, up-front design and documentation, and a repeatable process, but if you're really in the software business to stay, I think it's worth it. SW engineering process is the stuff that was both tremendously boring and incredibly obvious in school, but it does work well if you take the time to use it.
You need to read this: http://www.negativland.com/minidis.html to get an idea of how fast a format can go away when big money gets behind the new thing. I'm not saying it's a done deal, since consumers effectively deep-sixed DivX, but I don't think CD's are nearly as permanent as you think they will be.
That is so backwards - copyright was originally intended to reward creativity by providing authors a limited opportunity to be the sole beneficiary of the profit from their work. Copyright law doesn't prevent creating at all, it just specifies who has the right to copy (i.e. distribute) a work that has already been created.
Napster is providing an index of users who may be (probably most are) violating current copyright law. My opinion is that the copyright holders should go after those who are infringing on their copyrights, not after an indexing service. Under the DMCA service providers (common carriers) are exempt from prosecution as long as they remove infringing users when notified. Napster has done so and has followed the letter of the law with regard to copyright as far as I know.
The real issue is that the recording industry is too lazy to go after millions of copyright violators, and would rather shoot the messenger instead. I don't blame them for being lazy (tracking down and prosecuting all of those users would be essentially impossible) but that doesn't make their actions ethical or right. The sooner they realize that the world has moved on, the fewer people will be hurt by their reflexive legal lashing out at all and sundry.
The important phrase is "small-scale". Downloading music continues to be legal AFAIK, but distributing it to millions of others over Napster or Gnutella is probably not exempt. Small-scale is aimed at making a tape for your friend, not for a million of your friends.
Speaking of smoking, in some states it is illegal for a minor (under 16, usually) to purchase cigarettes, but not illegal to possess them. I have no idea why, but it's sort of the same situation. IMHO pot smokers shouldn't be tossed in prison just for smoking, since they're not violent or dangerous to society. If pot needs to be illegal, a stiff fine and/or community service would be more appropriate as far as I'm concerned. Now if they were knocking over convenience stores for cash to feed their monkey, that would be different.
Only if you're in my company's IT department. Don't forget to get something from Microsoft that implements all of the hot new standards, too!
OK, I think I'm done now.
Thanks for the tip - I will try "Draw widgets as Motif" tonight and see what happens.
Windows style is indeed pretty sucky.
Sure, KMail is a separate application. However, it is distributed with KDE, it requires KDE libraries and won't function without them, its bugs are tracked through bugs.kde.org, and so forth. As far as a user could tell, it is pretty intertwined with KDE the environment. Sure I could just use Netscape - my complaint is not necessarily about a bug in KMail, because Lord knows Netscape has plenty of bugs too. My complaint is that the KDE team in my very limited experience doesn't practice good user/developer relations. Part of this opinion I draw from the KDE developer that I corresponded with, and most of it I draw from the fact that the KDE 1.1.2 release hasn't had many bug fixes rolled into it due to work on KDE 2.0.
The relative merits of patches to KDE 1.1.2 versus new development for KDE 2.0 are up to the KDE development team, not to me. But since I as a user prefer to get bug fixes now for the desktop environment that I use, rather than wait a year or two for a whole new and improved environment, IMHO Gnome currently has a better development model.
So no, installing Gnome will probably replace some niggling unhappinesses that I have with KDE with equivalent Gnome ones, resulting in the total number of outstanding bugs remaining the same. But my impression as a user is that the Gnome development model is more open, more willing to accept bug fixes and features contributed by users such as myself, and more willing to turn around those fixes back to the population of other users. That's probably why I now use mostly Gnome apps on my KDE desktop.
As I said before, these are just my opinions based on my limited experiences. You're quite welcome to have other opinions based on your experiences; I don't want to convert anybody, I just wanted to bring out my thoughts (although I note that you didn't really have any contrary experiences to relate, you just provided some flamage of my opinions, which is exactly what I didn't want to provoke, but oh well).
According to the ruling (as described on C|Net this morning), part of the reason the judge ruled against 2600 was that they linked directly to the files on the other sites. So maybe you would be safe to just say "well, we can't provide DeCSS, but please patronize these other sites in the save DeCSS webring", and when you go to those other sites they have a big DeCSS link on the front page?
I think that ruling against linking is a slippery slope - where do you draw the line that 2600 is no longer distributing something? If they can be liable for something that is stored on a machine they don't control, they really can be held liable for a lot of things. Especially since as a hacker site they usually have the first links to projects that are pushing the envelope.
This ruling is a strong blow against the underpinnings of the Web, no matter how the judge says that it wouldn't affect other circumstances. Linking is no more illegal than the phone books are if they publish the phone numbers of known criminals. Unfortunately, rulings like this may seriously cripple the 'net before we can get some people who really "get it" into positions of authority.
Woops, I forgot one thing:
OK, I'll bite. I installed Mandrake+KDE on my home desktop machine because I promised my wife that Linux would look almost exactly like windows. That's more-or-less what I got with KDE (I have some different themes that I use but she's sticking to plain vanilla KDE look and feel). The only bugs that cause us real trouble are the usual Netscape 4.x problems (hopefully soon to be a thing of the past), and some minor issues with kmail and the KDE biff program. However, if I had to do it all over again, at this point I'd probably install Gnome. Here's why:
Note that these are all my personal opinions and perceptions based on my experiences, not a flame directed at any of the development groups. I appreciate the efforts of the many desktop environment hackers out there and am happy to be able to make use of their efforts at home.
Now, aren't you sorry you asked?
I'm not sure if linking to those other sites is actually encouraging them to commit a crime, though. Distributing DeCSS is a crime but possessing it is not, so the only criminals would be the hosting sites. And presumably they were already hosting it before 2600 linked to them, otherwise 2600 wouldn't have linked to them. So I don't think the linking encouraged the crime; any crime that was committed by those mirror sites was already under way before they were linked from 2600.
The only way that I could see it as encouraging would be from an PR standpoint - if you wanted to get known in the hacker community, serving as a mirror for 2600 in this case would probably raise your standing. But that's a pretty tenuous connection IMHO.
I posted originally before reading the section which you quoted - it does explain a few things, thanks. I still don't agree with it, but oh well :)
Well, in the U.S. the principle of Judicial Review allows the judiciary to strike down laws that they find are inconsistent with the U.S. Constitution. It is the duty of the judiciary (as codified by precedent although not really by the Constitution) to disagree with the philosophy of a law if that law is wrong. So technically no judge is "merely an executor", although in practice I'm sure that only a fairly high-level court would overturn such a federal law. I don't know if Judge Kaplan was high-level enough.
Judicial review is the best way to get it overturned - the judiciary is not beholden to the recording industry the way that Congress is. There are plenty of Sonny Bonos (OK, that was a little bit of an oblique reference) in Congress who are happy to support the DMCA; it is not likely to be overturned by the legislature.
It looks like this judge is ruling merely on the merits of the DMCA as passed by Congress, rather than considering the larger question of whether the law is constitutional. Perhaps at this level of the legal system the judiciary is unwilling (or unable, IANACS (constitutional scholar)) to overturn a federal law as unconstitutional. I think it was pretty clear on the basis of the past few months activities that this case would go against the defendants.
The DMCA itself is bad enough, but the upholding of an injunction against the defendants linking to freely available information (well, at least until the hosting sites are also sued) is really troubling. I hope that facet of the case is an important part of the appeal as well; otherwise the New York Times and other major news venues will have to watch what they link to. If linking to a site with controversial content is prohibited, how about linking to a site that does the linking? For that matter, how about linking to AltaVista?
This ruling represents an unconscionable attack on the underpinnings of the Internet. The powers-that-be have won the first battle to halt the changes that are coming to the world they own; I hope that the EFF, Mr. Garbus, and other people of good will are able to win the war for freedom of information and the right to free speech online, even if it does hurt someone's bottom line.
</soapbox>
Wow, sounds like all we need are CSS-style region codes for the broadcasts and we're all set, right? Oh, wait - region codes are a bad thing.
Not that it's your fault, but one-day-delayed clips still don't address the real problem: for U.S. audiences, there will be no live coverage of the Olympics by any means - no TV, radio, or 'net broadcasts.
IOC: Aim carefully at foot, and gently pull the trigger.
I do turn them off, but unfortunately there are still some knobs who apparently paste them into the main comment box specifically to torque me. The cadfu guy is particularly annoying about this.
You hit the nail on the head - having a variety of clients does help those users avoid the most common, average attacks, because the most-used attacks will be the attacks that can do a lot of damage and hit a lot of machines. So while there is no intrinsic security increase in the actual code of any one email client, overall a system of users with heterogenous clients will have a lower overall amount of problems than a system of users with homogenous clients. So while my Netscape mail might not be intrinsically more secure than Outlook (although it is, but that's another story) the fact that I use a non-standard client with respect to the rest of my company means that I haven't had any downtime due to email worms this year, whereas some of my coworkers have.
The fact that there are ten flavors of Unix doesn't make each one any more secure. But the fact that a computer network is composed of many different OSes rather than just one does increase higher overall security for the entire network, because attacks are usually targeted for a very specific OS+hardware combo.