The following remarks are the result of my internal thought processes, not of any policies we have in place at work.:)
As others here have pointed out better than I, there are two compelling reasons for an ISP that's looking out for its long-term interests to not suspend a user account in a situation like this. 1) Suspending the account won't have an effect on the DDoS while it's in progress. 2) It gives the attackers what they want.
A lot of posters have assumed that the goal of the attack was to take out the user's homepage, but there's nothing in the original article to suggest that. In fact, since the ISP was able to figure out who the target was, it most likely was not a web page they were after, but the user's dialup account instead. (After all, how would the ISP link the attack it to a specific user account on the web server?) So there's no easy way for the attackers to tell that the user's been disabled, which means the attack will probably continue for some time no matter what. The other customers' connections will suffer even if you suspend the targeted user.
So at this point, you might as well do the moral thing and prosecute the snot out of the little twerps.
Of course, if you leave the user's account on, you'll want to have a chat with him to make sure he understands his responsibilities in this situation, as well--such as not doing stupid things to let his attackers find his IP in the future...
You're correct in saying that an ISP is under no obligation to provide service in this kind of situation. And, the victim probably can't sue the ISP.
But he sure as hell can make it known in the community that this ISP won't stick up for its customers.
As an administrator at an ISP, I'm well aware of the need to watch the bottom line, but I would think twice before suspending a user's account on the grounds that they were being attacked. That's not good customer service, and it's definitely a bad precedent to set. Let it be known that you'll suspend your users' accounts if they come under attack, and suddenly a lot more of your users' enemies will come out of the woodwork. Suddenly, DDoS is a very, *very* effective tool for getting rid of people you disagree with.
Now, the ISP may have suspended the user to protect their other customers while they pursued prosecution of the offenders; but that's not the impression I get here. If that were the case, I doubt anyone would've had cause to object to the ISP's behavior. A modem line that's being DDoSed probably isn't going to be all that useful to the user anyway...
Then again, this story is based on hearsay and second-hand quotes, so who knows what really happened. If the Slashdot editors are interested in our reaction to a hypothetical situation, then yes--an ISP which suspends the users' account instead of prosecuting the culprits should get all the bad press we can muster. But if we're talking about a real ISP, then things probably aren't so cut and dried.
Even though the arrival of a legal Linux DVD player on the scene now won't affect the current DeCSS trial, it could definitely affect the future legal status of DeCSS: if everyone's innocence is upheld in this case because there was no existing DVD player for Linux when DeCSS was published, then once MPAA-sanctioned, commercial DVD offerings are available, we may not be able to continue using DeCSS. Instead, we'll be stuck using the closed-source offerings provided to us by the MPAA's cronies... Not what I call an ideal situation.
You're right, circumventing the EULA is not demonstrably illegal.
However, that doesn't stop Microsoft from taking the question to court, and like all big bad corporations, they have the pocket change to keep the question in court for quite some time if they choose to. And the issue of circumventing the EULA is murky enough that the judge won't immediately throw the suit out as frivolous.
IANAL, but one doesn't have to be a lawyer to be able to predict the behavior of corporate lawyers in these troubled times.
1. Record the whole reverse engineering process on video to use as proof of actually rev.eng'ing, not following specs in court.
Trouble is, reverse engineering sometimes involves a lot of guesswork and intuition, which is difficult to document.
2. Publishing a "trade secret" obviously isn't "reasonable effort to protect", is it? Even with oxymoronish "by reading this..." comments.
According to the terms of the DMCA, it can be argued that Microsoft *has* tried to protect its trade secret, because they've published a document in a format that requires an individual to agree to a legally binding license before proceeding. If you click 'yes' and then redistribute it or use it for reverse-engineering purposes, then you've violated the license; if you circumvent the technical protection (which is flimsy, but of course the DMCA doesn't care), then you're in violation of the DMCA, and we all know how good that law's been for the rights of the citizen. Either way, under no circumstances is it *clearly* legal to use information gained by way of this document for creating a competing implementation. That fact alone is enough to make life difficult for those working on reverse-engineering the MS PAC.
Glad that they did this? Not really. It's a strategic move on their part designed to make them look like good guys (look, we're publishing a spec! We're open!), when in fact what they've given us is completely useless to the Community (unless you really/prefer/ to use Microsoft's server products and are only interested in making them more secure). It's worse that useless, really: anyone who touches the documentation MS has put out can wind up in legal trouble with Microsoft if they later work on any project involving the reverse-engineering and reimplementation of the PAC.
I'm sure the anonymous coward who posted the contents of the contents of Microsoft's PAC specification here thought he was doing the world a favor and sticking it to the Evil Empire in the process. But the truth is that what the poster has done is illegal in the US thanks to the DMCA, whether we like it or not. Moreover, making the contents of the file widely available in this manner threatens to taint the efforts of those who need to get this information legally!
The Samba team, and others who want Kerberos compatibility with Microsoft's PAC bastardization, need to come by this information legitimately -- either by reverse-engineering it, or by twisting MS's arm until they start behaving themselves and release the information openly. If anyone uses the above code to implement Win2k compatibility, Microsoft can take them to court for using stolen trade secrets.
Even if the Samba team *doesn't* use this information, if it becomes widely available then it becomes very difficult to prove that those who did the reverse-engineering didn't read Microsoft's document... in which case Microsoft can still take people to court for it and keep them there for a very long time because of the difficulty of proving guilt or innocence. The last thing we want is for future Samba development to be caught up in a legal gray area for years on end.
And don't be too sure that Microsoft wouldn't take the Samba team to court for something like that, even if they knew the Samba team was innocent. They're playing dirty here, milking the gullibility of the US legislature for all it's worth. Microsoft promised open documentation, and instead they've given us a legal boobytrap. Please, let's not play into their hands.
Bug reports on security issues tend to be a lot different than other kinds of bug reports, partly because the kinds of people who find security holes are a lot different from those who find, say, problems with menu rendering.
Fixing security holes is not a time consuming issue because most of the time, the submitter includes a fix for it with the bug report! When this is not the case, the nature of the fix is almost always obvious based on the description of the problem.
The vast majority of security exploits can be fixed with a one- or two-line change to the code. If the Mozilla developers don't have time to make a one-line security fix to their code in a timely fashion, they have much bigger problems to deal with than security.
And *no one*, commercial or open, discloses information about their security bugs until they have a fix. It would be foolish to do so, not because it's bad for PR but because it's a disservice to the users. If that puts them in the same boat as Microsoft, then so be it--Microsoft can't be wrong all the time.
OTOH, if the Mozilla team tried to delay release of the fix until Netscape also had a chance to get theirs out, that would be wrong. It also wouldn't do them much good, since the person reporting the bug is going to post it to BUGTRAQ sooner or later anyway...
Many consider it bad form to post to BUGTRAQ without first giving a software vendor a chance to address the problem.
It's also considered bad form for a vendor to sit on a security bug instead of dealing with it promptly.
Up to this point, Mozilla has actually been somewhat unique in that, not only does the public have full access to the current source code, it also has access to all bug reports. While this is a commendably open attitude, it's not the best way to protect the end user.
All this policy change really means is that, in the short time between when the bug is first reported and when a fix is issued (or it shows up on BUGTRAQ without a fix), it's not posted in BugZilla for all the world to see. Effectively, what this means is that there are going to be fewer people out there trying to write exploits based on the bug report. This is no different from the policy in use by any other team I've ever encountered.
If they publish information about the security bug while their product is still vulnerable, what do they gain? It will cause the userbase to worry more. Some may stop using the product until the fix is available, but what about those who don't have that option? What if you've deployed Mozilla in 30 public labs on campus, on 5 different platforms, you're the only one who can do anything about it, you have to be on campus to fix it, and you're reading about the problem while on vacation in Cancún?
The above scenario is extreme, but not atypical. For most end users, the only real difference will be that it's suddenly become much more likely that someone will brew up an exploit for the security hole.
So there's a security hole in the browser. So what? Do you really think the software you use is secure? There are a *lot* of free software programmers out there who write the kind of code which would spell "instant root shell" if it was ever run suid root. Even if none of the programmers working on Mozilla are like this, there are still a lot of things that can go wrong just because of the sheer complexity of the application.
If you think the programs you're using are secure, you're kidding yourself. The most security-conscious development team I've ever had the pleasure of observing is the Samba team, and even they've had a security hole or two over the past few years. There are always going to be problems, and if they're security problems, I'd much prefer that only the program maintainers know about it, instead of publishing it for all the crackers of the world to see.
I for one commend the Mozilla team for keeping the user's best interest in mind with this decision.
While I'll agree that American corporations and the US government are unethical in the methods they use, I don't see why you're blaming Americans for the fact that your politicians are being bought out. If Sweden's politicians are corrupt, it's the Swedes' responsibility to get rid of them, isn't it?
If America is so evil, why don't the governments in the rest of the world fight back? Why did so many European countries sign the Wassenaar agreement?
Incidentally, although the (thrice-damned) Church of Scientology started in the USA, it's international in scope, and its operations have been largely based out of England, IIRC.
Even if the license wasn't GPL, everyone who has already downloaded the code (and/or binaries) was granted permission to use it, and transferring the copyright does not allow Mattel to take away that license after the fact.
However, because no license is included in the source code as originally made available, it could be argued in court that no permission to distribute was ever granted. Perhaps this is Mattel's angle.
In the short term, your proposal is likely to be successful. However, arguing this point shoots past the real problem entirely.
If vendors of censorware programs receive negative press because they've failed to block some material that "should" be blocked, then they're going to do the logical, responsible thing (from their business's point of view): they're going to expand their filters so that they block more material.
And the censorware advocates will argue that blocking some of it is better than blocking none of it.
The only way to effectively defeat the censorware movement is by raising awareness of how efforts to "protect" children are in fact cutting off their access to legitimate--perhaps even essential--information resources.
They're not trying to scam the OSS community, they're trying to scam uninformed stock buyers, many of whom are old retirees who invest their life savings.
I'm sorry, but any uninformed stock buyer, old retiree or not, deserves what they get if they invest their life savings in an IPO solely on the basis of a buzzword. As far as I'm concerned, LinuxOne can scam any fools they want to--but not if it means tarnishing the good name of the Free Software community, which is precisely what they mean to do.
Just what exactly Jon would want the brains and energy of flamers for, I don't understand. Perhaps he has a good stew recipe that he plans to share with us in part 4 of this series?
Playing the devil's advocate, I have to point out that there are very, very few clues to the gender of a speaker on-line. Given that this is the case, it can only be said that most violent and aggressive posters *seem* to be male because these are perceived as male behaviors.
I'm not saying that most of the flamers *aren't* males, I just don't think this is very concrete evidence.:)
The point of patents is not to protect the little guy. They're not there to *protect* anyone. The reason US patent law came into existence was out of a desire to foster scientific/technological development and the *sharing* of information.
A patent is a deal between an inventor and the US government that grants the inventor a monopoly for a limited period of time in exchange for information about an invention. That is why patents were established. People (particularly those in the government) seem to forget that a lot when talking about patents.
Under the current policy of the US patent office, the public is getting the shaft. If there are half a million people in the country who can reverse-engineer your invention just by looking at the model they bought on the market, then whoopie--you get a monopoly, and we the public get... a piece of paper telling us that we'll be sued if we try to do the same thing, even though it's a perfectly obvious thing to do.
And then a corporation buys up the patent, and all the money eventually funnels to the faceless giant that hires marketroids and middle management... hmm.
IIRC, this works out-of-the-box and lets you use the RWIN key (assuming you have a 105-key keyboard) as a 'compose' key: all accented characters can be typed using the compose key and a combination of two letters (a + " => ä).
It may not be a more ergonomic solution if you type in a language other than English, but if you type mostly in English and use other characters only sparingly (like I do, typing occasionally in Spanish AND French), it's a great general solution...
As one who switched to Dvorak roughly 20 months ago, I can assure you that the investment I made to learn it was no mistake.
If your goal is to be able to type faster, then switching may not be a great idea; I don't type any faster now than I did on QWERTY. But how important is speed, anyway? If I can type 100 wpm, but can only think at around 80 wpm, then the only time the extra speed would do me any good is when I'm typing up a written document. Since I'm a sysadmin, not a secretary, that's not a problem I'm often faced with. I suspect that the circumstances of many Slashdot readers are similar.
Speed wasn't my motive for switching, though. Last spring, I left the US to study abroad. I left behind my natural keyboard, taking with me a laptop (complete with a suitably cramped laptop keyboard). After a few months of typing QWERTY on that beast, the pain was intense. So when a discussion popped up here on Slashdot last spring recommending Dvorak as an alternative, I gave it a shot. The pain went away, and with luck I've gained a few more years of CTS-free typing.
If the question is whether retraining existing QWERTY typists to use Dvorak is economically advantageous, I don't have an answer. But I'm not an economist, and economic arguments don't interest me anyway. I'm an individual with first-hand experience of the *personal* benefits of switching.
Re:ZDNet doesn't want to admit its mistake
on
Jesux is a Bad Pun
·
· Score: 1
chmod typically takes its argument as an octal mode, because it's a natural fit (there are three permission bits for each access group on a normal file). However, this usually means a three-digit octal number, and when you're dealing with three-digit numbers in base 8, the number '666' pops up rather frequently. The humor is that, by changing your number base, you could eliminate this Satanic occurence (at the same time, you would make it hard as hell to use...).
The Qwest dialup is still a PPP connection. PAP is the *authentication* method used during session setup to identify the user, but PAP is incorporated into PPP (and well-supported under Linux, although it may take a little work to get it set up). The difference isn't that Qwest doesn't use PPP, it's that some ISPs use traditional scripted logins (text-based prompts) whereas Qwest only uses PAP.
It's certainly true that RH 6.0 as released has its share of problems, but take a look at the historical patterns here: both RH4.0 and RH5.0 were equally unstable, to the point that I know people who avoid RedHat's major revision releases and wait for the x.1 releases to come out before they upgrade.
Truth be told, I've found RH6.0 to be the most stable release of RH that I've used to date. And by this I mean that I consider it very stable, although I have a cache of my own update rpms nearby that I add immediately to all new installs.
Despite the bad reputation Red Hat is acquiring within the community, their distro/is/ still free, and it's a distro that I find very useful, both at home and at work. I certainly keep my eye on them to see what direction they're headed, but all the accusations of dirty dealing and over-commercialization have not convinced me that Red Hat is hurting the Free Software community.
I think many people forget, in their eagerness to criticize anyone making a profit, that the concept of open source software is more widely accepted now than at any previous moment in history, and that Red Hat is actively gaining us even more mindshare through their commercially viable distribution. They are a business, yes, and like all businesses their ultimate goal is to make money. But we as a community have much to gain from being cautiously optimistic about Red Hat's role in the grand scheme.
Why the UF hoax concerned me
on
Slashdot:Mark 2
·
· Score: 2
Mr. Bill, you suggest that many of us may be mad about the UF April Fool's Day prank because we couldn't see through it. I didn't see through it until today, because until today all the data suggested that we were looking at a genuine Legal Problem.
Microsoft taking legal action against UF, while braindead and destined to backfire, is not inconceivable. The joke took so long to play out that I'm afraid I can't find much humor in it now that I know it for what it is. All I feel is a profound sense of relief that we aren't going to have to beat down Microsoft after all to get our cartoons back.:)
Sorry to rain on anyone's parade. For the most part I've enjoyed the 1Apr posts--the Katz parody had me rolling. I have no problem with news sites playing along with April Fools'--my only caveat is that it should be clear to anyone reading with half an eye open that they're being had.:)
Having TCP/IP listed first isn't sufficient to guarantee good behavior on behalf of the Windows clients. Unless there is an unavoidable reason for having NetBEUI on the network (namely, old clients with no TCP/IP stack), NetBIOS-over-NetBEUI (or over IPX, for that matter) should be disabled.... This isn't only for Samba's sake, Windows networking becomes very fragile any time you have NetBIOS packets traveling around on more than one type of stack...
An NT domain is a complex system used to create trust relationships between NT machines, so that accounts which exist on one machine will also automatically exist on the others, so that you don't have to create an account a la Win95 every time you use a different machine in the domain (workplace, lab, whatever), and so that there's better security for network transactions (although it still has its flaws). The PDC is the core of an NT domain; it's the server that all the workstations authenticate against, and is for the most part the single point of configuration for the domain. All of this naturally means that Microsoft charges an arm and a leg for the license.
Now imagine dropping a Unix box into place that can handle running your NT domain. Oh, the convenience... Sweet, happy penguins dancing in the cubicles...
(In my defense, I don't use NT either--I just spend too much time tracking Samba development.:)
I personally find that I tend to skip over posts by Anonymous Cowards (of whose secret society I was a member until a short while ago--hurray for laziness) based on past observations of the quality of their posts. Malda can use the label of his choice when referring to them, but as long as the posts come from the people that they currently do, I'll keep skipping them.
(Understand that I don't favor eliminating the privilege; I simply don't personally have time to weed through all comments, and AC posts are among the first to go.)
However, since I/do/ judge posts by content, rather than by the name I see at the top, I would be perfectly willing to accept anonymous insiders, cowardly or otherwise, based on the quality of their arguments. I think their goals would be better met if they didn't hide behind the monolithic AC collective, given the flexibility of Slashdot's registration requirements. It's no more difficult to create an email account that can't be traced to you than it is to make anonymous postings to a web site...
Slashdot Mirror
The following remarks are the result of my internal thought processes, not of any policies we have in place at work. :)
As others here have pointed out better than I, there are two compelling reasons for an ISP that's looking out for its long-term interests to not suspend a user account in a situation like this.
1) Suspending the account won't have an effect on the DDoS while it's in progress.
2) It gives the attackers what they want.
A lot of posters have assumed that the goal of the attack was to take out the user's homepage, but there's nothing in the original article to suggest that. In fact, since the ISP was able to figure out who the target was, it most likely was not a web page they were after, but the user's dialup account instead. (After all, how would the ISP link the attack it to a specific user account on the web server?) So there's no easy way for the attackers to tell that the user's been disabled, which means the attack will probably continue for some time no matter what. The other customers' connections will suffer even if you suspend the targeted user.
So at this point, you might as well do the moral thing and prosecute the snot out of the little twerps.
Of course, if you leave the user's account on, you'll want to have a chat with him to make sure he understands his responsibilities in this situation, as well--such as not doing stupid things to let his attackers find his IP in the future...
You're correct in saying that an ISP is under no obligation to provide service in this kind of situation. And, the victim probably can't sue the ISP.
But he sure as hell can make it known in the community that this ISP won't stick up for its customers.
As an administrator at an ISP, I'm well aware of the need to watch the bottom line, but I would think twice before suspending a user's account on the grounds that they were being attacked. That's not good customer service, and it's definitely a bad precedent to set. Let it be known that you'll suspend your users' accounts if they come under attack, and suddenly a lot more of your users' enemies will come out of the woodwork. Suddenly, DDoS is a very, *very* effective tool for getting rid of people you disagree with.
Now, the ISP may have suspended the user to protect their other customers while they pursued prosecution of the offenders; but that's not the impression I get here. If that were the case, I doubt anyone would've had cause to object to the ISP's behavior. A modem line that's being DDoSed probably isn't going to be all that useful to the user anyway...
Then again, this story is based on hearsay and second-hand quotes, so who knows what really happened. If the Slashdot editors are interested in our reaction to a hypothetical situation, then yes--an ISP which suspends the users' account instead of prosecuting the culprits should get all the bad press we can muster. But if we're talking about a real ISP, then things probably aren't so cut and dried.
Even though the arrival of a legal Linux DVD player on the scene now won't affect the current DeCSS trial, it could definitely affect the future legal status of DeCSS: if everyone's innocence is upheld in this case because there was no existing DVD player for Linux when DeCSS was published, then once MPAA-sanctioned, commercial DVD offerings are available, we may not be able to continue using DeCSS. Instead, we'll be stuck using the closed-source offerings provided to us by the MPAA's cronies... Not what I call an ideal situation.
You're right, circumventing the EULA is not demonstrably illegal.
However, that doesn't stop Microsoft from taking the question to court, and like all big bad corporations, they have the pocket change to keep the question in court for quite some time if they choose to. And the issue of circumventing the EULA is murky enough that the judge won't immediately throw the suit out as frivolous.
IANAL, but one doesn't have to be a lawyer to be able to predict the behavior of corporate lawyers in these troubled times.
1. Record the whole reverse engineering process on video to use as proof of actually rev.eng'ing, not following specs in court.
Trouble is, reverse engineering sometimes involves a lot of guesswork and intuition, which is difficult to document.
2. Publishing a "trade secret" obviously isn't "reasonable effort to protect", is it? Even with oxymoronish "by reading this..." comments.
According to the terms of the DMCA, it can be argued that Microsoft *has* tried to protect its trade secret, because they've published a document in a format that requires an individual to agree to a legally binding license before proceeding. If you click 'yes' and then redistribute it or use it for reverse-engineering purposes, then you've violated the license; if you circumvent the technical protection (which is flimsy, but of course the DMCA doesn't care), then you're in violation of the DMCA, and we all know how good that law's been for the rights of the citizen. Either way, under no circumstances is it *clearly* legal to use information gained by way of this document for creating a competing implementation. That fact alone is enough to make life difficult for those working on reverse-engineering the MS PAC.
Glad that they did this? Not really. It's a strategic move on their part designed to make them look like good guys (look, we're publishing a spec! We're open!), when in fact what they've given us is completely useless to the Community (unless you really /prefer/ to use Microsoft's server products and are only interested in making them more secure). It's worse that useless, really: anyone who touches the documentation MS has put out can wind up in legal trouble with Microsoft if they later work on any project involving the reverse-engineering and reimplementation of the PAC.
So thanks, Microsoft, but no thanks.
I'm sure the anonymous coward who posted the contents of the contents of Microsoft's PAC specification here thought he was doing the world a favor and sticking it to the Evil Empire in the process. But the truth is that what the poster has done is illegal in the US thanks to the DMCA, whether we like it or not. Moreover, making the contents of the file widely available in this manner threatens to taint the efforts of those who need to get this information legally!
The Samba team, and others who want Kerberos compatibility with Microsoft's PAC bastardization, need to come by this information legitimately -- either by reverse-engineering it, or by twisting MS's arm until they start behaving themselves and release the information openly. If anyone uses the above code to implement Win2k compatibility, Microsoft can take them to court for using stolen trade secrets.
Even if the Samba team *doesn't* use this information, if it becomes widely available then it becomes very difficult to prove that those who did the reverse-engineering didn't read Microsoft's document... in which case Microsoft can still take people to court for it and keep them there for a very long time because of the difficulty of proving guilt or innocence. The last thing we want is for future Samba development to be caught up in a legal gray area for years on
end.
And don't be too sure that Microsoft wouldn't take the Samba team to court for something like that, even if they knew the Samba team was innocent. They're playing dirty here, milking the gullibility of the US legislature for all it's worth. Microsoft promised open documentation, and instead they've given us a legal boobytrap. Please, let's not play into their hands.
Bug reports on security issues tend to be a lot different than other kinds of bug reports, partly because the kinds of people who find security holes are a lot different from those who find, say, problems with menu rendering.
Fixing security holes is not a time consuming issue because most of the time, the submitter includes a fix for it with the bug report! When this is not the case, the nature of the fix is almost always obvious based on the description of the problem.
The vast majority of security exploits can be fixed with a one- or two-line change to the code. If the Mozilla developers don't have time to make a one-line security fix to their code in a timely fashion, they have much bigger problems to deal with than security.
And *no one*, commercial or open, discloses information about their security bugs until they have a fix. It would be foolish to do so, not because it's bad for PR but because it's a disservice to the users. If that puts them in the same boat as Microsoft, then so be it--Microsoft can't be wrong all the time.
OTOH, if the Mozilla team tried to delay release of the fix until Netscape also had a chance to get theirs out, that would be wrong. It also wouldn't do them much good, since the person reporting the bug is going to post it to BUGTRAQ sooner or later anyway...
Many consider it bad form to post to BUGTRAQ without first giving a software vendor a chance to address the problem.
It's also considered bad form for a vendor to sit on a security bug instead of dealing with it promptly.
Up to this point, Mozilla has actually been somewhat unique in that, not only does the public have full access to the current source code, it also has access to all bug reports. While this is a commendably open attitude, it's not the best way to protect the end user.
All this policy change really means is that, in the short time between when the bug is first reported and when a fix is issued (or it shows up on BUGTRAQ without a fix), it's not posted in BugZilla for all the world to see. Effectively, what this means is that there are going to be fewer people out there trying to write exploits based on the bug report. This is no different from the policy in use by any other team I've ever encountered.
If they publish information about the security bug while their product is still vulnerable, what do they gain? It will cause the userbase to worry more. Some may stop using the product until the fix is available, but what about those who don't have that option? What if you've deployed Mozilla in 30 public labs on campus, on 5 different platforms, you're the only one who can do anything about it, you have to be on campus to fix it, and you're reading about the problem while on vacation in Cancún?
The above scenario is extreme, but not atypical. For most end users, the only real difference will be that it's suddenly become much more likely that someone will brew up an exploit for the security hole.
So there's a security hole in the browser. So what? Do you really think the software you use is secure? There are a *lot* of free software programmers out there who write the kind of code which would spell "instant root shell" if it was ever run suid root. Even if none of the programmers working on Mozilla are like this, there are still a lot of things that can go wrong just because of the sheer complexity of the application.
If you think the programs you're using are secure, you're kidding yourself. The most security-conscious development team I've ever had the pleasure of observing is the Samba team, and even they've had a security hole or two over the past few years. There are always going to be problems, and if they're security problems, I'd much prefer that only the program maintainers know about it, instead of publishing it for all the crackers of the world to see.
I for one commend the Mozilla team for keeping the user's best interest in mind with this decision.
While I'll agree that American corporations and the US government are unethical in the methods they use, I don't see why you're blaming Americans for the fact that your politicians are being bought out. If Sweden's politicians are corrupt, it's the Swedes' responsibility to get rid of them, isn't it?
If America is so evil, why don't the governments in the rest of the world fight back? Why did so many European countries sign the Wassenaar agreement?
Incidentally, although the (thrice-damned) Church of Scientology started in the USA, it's international in scope, and its operations have been largely based out of England, IIRC.
Even if the license wasn't GPL, everyone who has already downloaded the code (and/or binaries) was granted permission to use it, and transferring the copyright does not allow Mattel to take away that license after the fact.
However, because no license is included in the source code as originally made available, it could be argued in court that no permission to distribute was ever granted. Perhaps this is Mattel's angle.
In the short term, your proposal is likely to be successful. However, arguing this point shoots past the real problem entirely.
If vendors of censorware programs receive negative press because they've failed to block some material that "should" be blocked, then they're going to do the logical, responsible thing (from their business's point of view): they're going to expand their filters so that they block more material.
And the censorware advocates will argue that blocking some of it is better than blocking none of it.
The only way to effectively defeat the censorware movement is by raising awareness of how efforts to "protect" children are in fact cutting off their access to legitimate--perhaps even essential--information resources.
I'm sorry, but any uninformed stock buyer, old retiree or not, deserves what they get if they invest their life savings in an IPO solely on the basis of a buzzword. As far as I'm concerned, LinuxOne can scam any fools they want to--but not if it means tarnishing the good name of the Free Software community, which is precisely what they mean to do.
<howl>Brains, BRAAAAAIIINS!</howl>
Just what exactly Jon would want the brains and energy of flamers for, I don't understand. Perhaps he has a good stew recipe that he plans to share with us in part 4 of this series?
Playing the devil's advocate, I have to point out that there are very, very few clues to the gender of a speaker on-line. Given that this is the case, it can only be said that most violent and aggressive posters *seem* to be male because these are perceived as male behaviors.
:)
I'm not saying that most of the flamers *aren't* males, I just don't think this is very concrete evidence.
The point of patents is not to protect the little guy. They're not there to *protect* anyone. The reason US patent law came into existence was out of a desire to foster scientific/technological development and the *sharing* of information.
A patent is a deal between an inventor and the US government that grants the inventor a monopoly for a limited period of time in exchange for information about an invention. That is why patents were established. People (particularly those in the government) seem to forget that a lot when talking about patents.
Under the current policy of the US patent office, the public is getting the shaft. If there are half a million people in the country who can reverse-engineer your invention just by looking at the model they bought on the market, then whoopie--you get a monopoly, and we the public get... a piece of paper telling us that we'll be sued if we try to do the same thing, even though it's a perfectly obvious thing to do.
And then a corporation buys up the patent, and all the money eventually funnels to the faceless giant that hires marketroids and middle management... hmm.
I use the following commandline, which should work on any system running XFree86 3.3.3.1 or better (may work with older versions, I dunno):
/usr/X11R6/bin/setxkbmap -symbols 'en_US(pc_universal_nodeadkeys)+dvorak'
IIRC, this works out-of-the-box and lets you use the RWIN key (assuming you have a 105-key keyboard) as a 'compose' key: all accented characters can be typed using the compose key and a combination of two letters (a + " => ä).
It may not be a more ergonomic solution if you type in a language other than English, but if you type mostly in English and use other characters only sparingly (like I do, typing occasionally in Spanish AND French), it's a great general solution...
As one who switched to Dvorak roughly 20 months ago, I can assure you that the investment I made to learn it was no mistake.
If your goal is to be able to type faster, then switching may not be a great idea; I don't type any faster now than I did on QWERTY. But how important is speed, anyway? If I can type 100 wpm, but can only think at around 80 wpm, then the only time the extra speed would do me any good is when I'm typing up a written document. Since I'm a sysadmin, not a secretary, that's not a problem I'm often faced with. I suspect that the circumstances of many Slashdot readers are similar.
Speed wasn't my motive for switching, though. Last spring, I left the US to study abroad. I left behind my natural keyboard, taking with me a laptop (complete with a suitably cramped laptop keyboard). After a few months of typing QWERTY on that beast, the pain was intense. So when a discussion popped up here on Slashdot last spring recommending Dvorak as an alternative, I gave it a shot. The pain went away, and with luck I've gained a few more years of CTS-free typing.
If the question is whether retraining existing QWERTY typists to use Dvorak is economically advantageous, I don't have an answer. But I'm not an economist, and economic arguments don't interest me anyway. I'm an individual with first-hand experience of the *personal* benefits of switching.
chmod typically takes its argument as an octal mode, because it's a natural fit (there are three permission bits for each access group on a normal file). However, this usually means a three-digit octal number, and when you're dealing with three-digit numbers in base 8, the number '666' pops up rather frequently. The humor is that, by changing your number base, you could eliminate this Satanic occurence (at the same time, you would make it hard as hell to use...).
The Qwest dialup is still a PPP connection. PAP is the *authentication* method used during session setup to identify the user, but PAP is incorporated into PPP (and well-supported under Linux, although it may take a little work to get it set up). The difference isn't that Qwest doesn't use PPP, it's that some ISPs use traditional scripted logins (text-based prompts) whereas Qwest only uses PAP.
It's certainly true that RH 6.0 as released has its share of problems, but take a look at the historical patterns here: both RH4.0 and RH5.0 were equally unstable, to the point that I know people who avoid RedHat's major revision releases and wait for the x.1 releases to come out before they upgrade.
/is/ still free, and it's a distro that I find very useful, both at home and at work. I certainly keep my eye on them to see what direction they're headed, but all the accusations of dirty dealing and over-commercialization have not convinced me that Red Hat is hurting the Free Software community.
Truth be told, I've found RH6.0 to be the most stable release of RH that I've used to date. And by this I mean that I consider it very stable, although I have a cache of my own update rpms nearby that I add immediately to all new installs.
Despite the bad reputation Red Hat is acquiring within the community, their distro
I think many people forget, in their eagerness to criticize anyone making a profit, that the concept of open source software is more widely accepted now than at any previous moment in history, and that Red Hat is actively gaining us even more mindshare through their commercially viable distribution. They are a business, yes, and like all businesses their ultimate goal is to make money. But we as a community have much to gain from being cautiously optimistic about Red Hat's role in the grand scheme.
Mr. Bill, you suggest that many of us may be mad about the UF April Fool's Day prank because we couldn't see through it. I didn't see through it until today, because until today all the data suggested that we were looking at a genuine Legal Problem.
:)
:)
Microsoft taking legal action against UF, while braindead and destined to backfire, is not inconceivable. The joke took so long to play out that I'm afraid I can't find much humor in it now that I know it for what it is. All I feel is a profound sense of relief that we aren't going to have to beat down Microsoft after all to get our cartoons back.
Sorry to rain on anyone's parade. For the most part I've enjoyed the 1Apr posts--the Katz parody had me rolling. I have no problem with news sites playing along with April Fools'--my only caveat is that it should be clear to anyone reading with half an eye open that they're being had.
Having TCP/IP listed first isn't sufficient to guarantee good behavior on behalf of the Windows clients. Unless there is an unavoidable reason for having NetBEUI on the network (namely, old clients with no TCP/IP stack), NetBIOS-over-NetBEUI (or over IPX, for that matter) should be disabled.... This isn't only for Samba's sake, Windows networking becomes very fragile any time you have NetBIOS packets traveling around on more than one type of stack...
An NT domain is a complex system used to create trust relationships between NT machines, so that accounts which exist on one machine will also automatically exist on the others, so that you don't have to create an account a la Win95 every time you use a different machine in the domain (workplace, lab, whatever), and so that there's better security for network transactions (although it still has its flaws). The PDC is the core of an NT domain; it's the server that all the workstations authenticate against, and is for the most part the single point of configuration for the domain. All of this naturally means that Microsoft charges an arm and a leg for the license.
:)
Now imagine dropping a Unix box into place that can handle running your NT domain. Oh, the convenience... Sweet, happy penguins dancing in the cubicles...
(In my defense, I don't use NT either--I just spend too much time tracking Samba development.
I personally find that I tend to skip over posts by Anonymous Cowards (of whose secret society I was a member until a short while ago--hurray for laziness) based on past observations of the quality of their posts. Malda can use the label of his choice when referring to them, but as long as the posts come from the people that they currently do, I'll keep skipping them.
/do/ judge posts by content, rather than by the name I see at the top, I would be perfectly willing to accept anonymous insiders, cowardly or otherwise, based on the quality of their arguments. I think their goals would be better met if they didn't hide behind the monolithic AC collective, given the flexibility of Slashdot's registration requirements. It's no more difficult to create an email account that can't be traced to you than it is to make anonymous postings to a web site...
(Understand that I don't favor eliminating the privilege; I simply don't personally have time to weed through all comments, and AC posts are among the first to go.)
However, since I