Actually, from a dynamical systems viewpoint, the Earth-Moon system is probably better viewed as a compound planet revolving around the Sun that it is as a primary (the Earth) with a satellite body (the Moon). Unlike a true moon, Earth's moon's orbit is always concave towards the Sun. (Contrast this with the Galilean satellites of the plant Jupiter. Their orbits are always concave towards Jupiter, and frequently concave away from the Sun.)
Of course, that's a little like saying that the Sun doesn't rise in the morning. I don't know about you, but I certainly saw today's sunrise...
I am a Microsoft employee, and more than that, I am a shareholder in said corporation. I stongly support the actions that the corporation has taken to protect our intellectual property.
You, and Emmett, and that rest of the creeps here, are acting like a bunch of spoiled and petulant children. There is no issue of free speech here; there is merely an issue of gross theft and corporate malfeasance.
You don't own Kerberos. My tax dollars payed for it, too, you know, under a set of rules that were in force at the time. If you want to change those rules, fine; you may have a public case in support of that, and I am prepared to listen to it. That doesn't matter for Kerberos, though; those rules are well established.
A Microsoft architect, acting within those established rules, designed an extension to that protocol. A Microsoft employee (probably a program manager) wrote that spec. A group of other employees (probably developers) wrote the W2K code that implements that spec. That extension, that spec, that code -- it isn't yours. It's theirs, and, by assignment, Microsoft's.
If you want to write software and distribute it under GPL, that's fine, and it is your right. If Taco believes that he should distribute Slahs for others to use, more power to him. I disagree. I will not live by those rules.
Live with it.
And stop posturing. What you're arguing about is not all that important. It is not a first amendment issue. You are not being censored. Nobody has tried to blacklist you. Go look at what happened to the Weavers, or to other Communists who were blacklisted during the McCarthy era -- you don't have a clue what they really faced, and it is disgusting to see spoiled little children like you trying to pretend you are going through the same thing. Go look at what Martin Luther King did and faced. Hell -- have crosses burned on your own front yard, as I HAVE, and then come back and tell me about how you're being "censored".
I have broken the law in acts of civil disobedience in the past, and I fully expect to do it again in the future. I have faced down the Man, and I know why and where and what for. But the consequence of that is this, Robin: I know what is worth fighting for, because I have genuinely fought for those things.
The right to steal other people's work, whether Microsoft does it or you do it -- that's not worth fighting for. That's worth spitting on.
Actually, the picture is a lot more complicated than that.
If I produce something that costs $1, and I ship it out the door immediately, and my customer receives it, and pays $10 plus shipping, then I profit $9. If I produce something that costs $1, and I store it in a warehouse for three months, and I pay for an inventory control system to keep track of it, and, and, and...then I quickly eat up my profit. Needless to say, the latter is a more realistic model of a business that sells atoms.
Ironically, if the RIAA could get a vig on each mp3 that was traded, they'd make a lot more money, because it is much cheaper to store bits than it is to store atoms. This is why I'm startled by the MP3.com case -- the RIAA members could make a lot of money by supporting a "free" ad-supported site that doled out MP3's for a nominal charge while paying a small royalty.
But nobody has ever said that the recording labels were smart, merely right. Obviously, they aren't smart...
I recently purchased a new USB device for one of my computers. As far as I know, it's functionality is unique.
Unfortunately, there's no stable driver for it under W2K -- and there are no drivers as at for FreeBSD or Linux. So I'm stuck with the vendor's late beta. The vendor is clearly dropping this product line, and I'd be willing to write a driver for it, just to get it working. (To be honest, given what I want this device for, the vendor probably won't want some parts of my final driver, since it will support a single-use protocol that...well the company certainly doesn't care about. No matter. Most of the driver would be useful.)
I understand the vendor's concern, mind you -- this device also has some features that they are using for competitive advantage for other items in the product line, and they really don't want their competitors stealing those advantages. I'd be willing to not be given those parts of the spec, though; I just want access to two features. I wonder if there's a well to get part of a spec without getting the whole thing.
Not quite. The original model ran javascript and vbscript, just like the current version does. Those are safe, in Outlook, Outlook Express, Netscape Navigator, whatever.
It did not run scripts under WSH. (WSH didn't even exist when O97 was released.) What you're talking about the ability of IE (and Outlook, all versions) to download and run ActiveX controls. That trust model has not yet been violated.
Outlook autoruns Javascript, yes. It autoruns ActiveX controls on your system that you have marked "Safe for scripting". But, once again, ask yourself a question: where did those controls come from? How did they get on your system?
You put them there yourself, of course. By installing them. Or disable the feature; it's a standard checkbox. (And, frankly, because I don't trust code on my system, I disable everything that my Administrator hasn't explicitly enabled.)
how many users know what a VBS icon is supposed to look like?
Doesn't matter. The WRONG icon showed up, and any user should recognize that. You see, to launch a file on the desktop, you click on the icon next to the file. All plain text files show the Notepad icon, not the "blue S in a box" icon of the scripting engines. Users should never ever launch an application with an unknown icon, just as they should never run a file with an unknown #! line at the front in Unix.
It's like all computing environments -- if you don't know what it's going to do, and you can't protect yourself from any conceivable harm it might cause, just don't do it.
No. Outlook does not autorun scripts. As I've said on a number of occasions, the only MUA that does that is Gnu Emacs -- and then, only if the user has configured it in a really stupid fashion.
1. A "malicious" bash script can not make itself run as root.
2. I believe (may be wrong on this) that the thing "looks" like a text file if you have "known extensions hidden" as per default
Actually, you're wrong on both counts. If you hide file extensions, then the item shows up with the vbs icon, not the text icon. Second, a malicious bash script can certainly run as root...if you're logged on as root. If you never read your mail as root (good for you!), then all the thing could do is send mail to everyone you've ever received mail from and trash your personal files...which is bad enough, I'd think. If you're logged in as root, though, a bash script could trash your system.
(That's why you shouldn't ever log in as root on a *n*x box, and why you shouldn't make your main account an Administrator in NT.)
All I can say is "God, if only!" Our state supremes are elected -- although if you look at what the state of Washington has elected in the last few years, I don't think you'll see a lot of political influence from Microsoft, frankly.
What you need to realize is that the state of Washington, and the city of Seattle in particular, have a love-hate relationship with Microsoft. They're vaguely proud of us, in the same way that you might be proud of your dog after it turned over the picky neighbor's trash...on the one hand, you're glad to see the neighbor humiliated, but, on the other hand, you still think the mutt stinks.
To read the local press, we're the source of all evils locally. We're blamed for the "sudden" rise in housing prices in the city, for traffic on the 520 bridge, for the rise in crime, and for social injustice. Sometimes I'm surprised that we haven't been accused of having a role in the 1980 eruption of Mt. St. Helens!
The truth is that Microsoft is a small part of a very large city. Certainly, many of the company's employees are wealthy, but Seattle is still the center of the circles of power in the state. There just aren't enough of us to really throw our weight around.
I honestly think the safest policy for GPLware would be to ship it as source code only, saying "Here's some code you might be able to make an application out of."
Seriously? That's interesting. Is that because you think that shipping it as source with such a license would reduce liability, or because you think it would increase liability? Or is there some other reason?
Well, first, you need to keep in mind that most people are running 56K modems or worse, and that this patent was filed for in 1997. So your asymetry argument is weak to begin with.
But even considering ADSL, your argument fails. When Debian sends down the package list, it doesn't know what packages you've got, much less what their build versions are. So it's got to send the whole batch down. Now, I don't care how cheap each one is (and they aren't; you're actually sending a fair amount of data) -- that's a lot of data when there are thousands of packages available. Microsoft's solution needs to send only a tiny amount of data; properly optimized (and how's not obviousness; I can think of a number of ways, and only experience would determine which), it should be possible to send only a small number of dates and program ids. Moreover, that data should be compressible; at worst, it's 128 bits per PROGID and 64 bits/NT time stamp. That's, what, 24 bytes for a small number of exceptions, plus an 8 byte header field for the time of the last complete update.
And your second objection doesn't work either: somewhere along the line, the server needs to get a list of which packages to send, whether you compute that list locally or on the server itself. Kind of defeats "privacy" right there, right?
That leaves the "overloaded server" argument. You're right, of course: written badly, this would swamp the server. Do you think that it can't be written well and cleverly? It isn't obvious how one would do that, but I can think of a lot of optimization hacks that might make it much faster. It'd take quite a bit of work to actually balance them all to get a high-throughput, robust system to handle the calls, clearly, but my experience suggests that it could be done.
But, either way, this is a non-obvious, useful invention. That's the basis of a valid patent.
apt gets the latest package list, checks it against what's on your system, and downloads all the needed packages and installs them
There's a key distinction here, and it's why the system really is an improvement. On a slow wire, the amount of data transmitted needs to be restricted. So, what? So you absolutely DO NOT want to send the entire package list to the client! Instead, you want to send an encoded date to the server, and let it send you the updates that *might* apply. (It's not enough to send the date when you last did an update; as might choose not to take a component of that update. You might need to send an exceptions list, too.)
Hmmm...doing that well's not going to be easy; it's going to take some fairly clever design (what about losing connectivity? How do you keep the applications database in sync? The registry is transacted...hmm, gotta think about this.)
Solving these problems isn't trivial; it's non-obvious. And that's what the patent is about -- not how to send updates; clearly, that's got prior art. It's how to do it fast with limited bandwidth.
Two words: Gnu Emacs. There's a really cool thing which Emacs does: it allows you to read e-lisp out of any buffer before opening it. And, unlike Outlook, it allows you to select a configuration in your.emacsrc which would execute that lisp code without any user intervention. (Yes, the use of that particular feature is deprecated, but it's still there.)
Now...since e-lisp is really a reasonably powerful scripting language, don't you think that constitutes a security hole a lot bigger than the one which people keep pretending is in Outlook?
I'll bet that you had an email named "Virus" open on your screen. The front panel of the task manager shows only the titles of active, visible windows. Since this particular darling doesn't open a window, it couldn't have spawned the effect you saw.
You were right to begin with: you can't spawn the virus unless you execute the attachment. Windows Scripting Host scripts are not part of standard HTML.
Actually, it is a real piece of security...for the world.
The idea of putting the weapon development work under DoE but the deployment work under DoD, is to diffuse the power over the weapons themselves. The people who make the weapons have to give them up to somebody else. The somebody else doesn't know how to make them. That way, if one group goes rogue, the other one can stand in their way.
It goes back to the end of the Second World War: the AEC (one of the main precursors to the DOE) controlled LANL (now LASL), LLL, Hanford and Oak Ridge; that control has since passed to DoE. The DoD controls deployment facilities. To this day, it is very hard to get access to both the development facilities and the deployment plans.
How about _Kerberos: Escape from Hades_ (goal is to reverse engineer the access control to the three-headed dog that imprisons you.) Some other possibilities:
_Obfuscate_, along with its sequel _Obfuscate II: Return of the Fud_.
Of course, everybody loves _DeadRat_ (goal is to make lots of money selling dead rats that you got for free, or, better still, by not selling the dead rats, but convincing others that you can make money selling life support systems for them)
_Johnny takes a Napster_ (derived from the board game of the same name, a thrilling game about toddlers who badly need some sleep.)
Hey, these are stupid games, remember? You don't know whether his posting was a parody of Janet Reno, or of somebody's view of Janet Reno. Either way, it was clever -- it just would have been cleverer if it were the second, instead of the first.
You know, even a month ago, I'd a have disagreed with Jon violently about this. But now, a month later, I've had my eyes opened. I'd never really experienced the joy and convenience that free and ready access to music outside my collection brought.
But then I found a source of free and easy-to-obtain music, so that I can stand in my kitchen and listen to stuff I wouldn't ever buy without testing it first. I found some of Robert Palmer's solo stuff -- really good -- and an a capella group called _The Blenders_ -- musically better than The Bobs, but not as intellectually challenging. I got a bunch of old Elvis Costello CD's, with their bonus tracks; by God, I'm updating my vinyl.
And I'm confident that the RIAA won't be coming after me. They'll never find me, and even if they did, they wouldn't dare bother me.
BECAUSE I BORROWED THESE CD'S FROM MY LOCAL LIBRARY. What a lot of this debate misses is one key fact: there are ways of getting the good parts of MP3 and Napster without breaking the law. That's why the music industry wants you to be tied to a physical object, and that is why they're right. I have to return these CD's, but I'll buy some of them. And I won't be able to keep the ones I don't buy. And that's a perfectly reasonable compromise: I can listen to stuff that I don't own, without taking the artist's and the companies legitimate right to make money.
Now why is that so hard, Jon? Why is it so hard to distinguish between "borrowing" and "stealing", and why is it so hard to understand that there are middle grounds between the purely anarchistic attitude of/. and the purely corporate attitude of the straw-man that you would propose the music idustry to be...and that there are already solutions in place, on the ground, that provide that?
There's an important subtlety here. Although MP3.com got nailed for copyright violation, they've not yet been assessed damages, and it isn't clear what damages could be assessed against them. Although their storage system was illegal, a consumer was required to provide evidence that he or she had the right to access a given item in the conglomerate store before he or she could access it.
IANAL -- but doesn't that mean that the total lost revenue and lost profit to the record companies is 0?
I am not aware of any users who have modified the Red Hat installer to take out the offensive code requiring entry of a root password. I haven't even heard any complaints about it.
What about people who make a single image of their default install and then blast it out onto many computers in their installation? That's not quite the same thing, but everyone that I've ever asked about it says "Of course I don't change the root password after I install a new box. If I did, I'd have to enter it by hand!" (Let's have a moment of silence for these future victims of accelerated evolution, shall we?)
That, however, requires a genuine installation routine, so that the source can't be installed without the defaults being changed. That, in turn, makes it impossible to have a truly secure open source solution.
I don't think that follows. Clearly, RH didn't do it here, but is it truly impossible for OSS?
Depends. Under the GPL, it is technically impossible. That portion of my code which enforces the user-defined password is subject to modification by any user, and the license gives people free rein to do just that. Since anything like that is considered a hassle by most developers, how long do you think it would remain in the code? Under BSD? Of course; the limits there are even lighter. Under some kind of Artistic license? (E.g. You may view the contents of this file, but the license is void if you modify them, or attempt to subvert their interface with the balance of this package...etc.) maybe -- but how would *you* personally feel if *I* tried to ship software with such a restriction, keeping in mind that I work for MS?
I hate to agree with Black Parrot on anything, but he's right. There's no such thing as a safe default password.
However, I'd do a little further. Safety lies in writing the original code so that the password is guaranteed to be user-dependent. True security lies in requiring the password be set on install. You can blame the user for not changing the password, but systems administrators are busy people, and they aren't generally going to do so unless they're forced to. That being the case, a developer who merely says "do this" when it's important, and doesn't mandate that it happen, is acting negligently.
That, however, requires a genuine installation routine, so that the source can't be installed without the defaults being changed. That, in turn, makes it impossible to have a truly secure open source solution.
Slashdot Mirror
Actually, from a dynamical systems viewpoint, the Earth-Moon system is probably better viewed as a compound planet revolving around the Sun that it is as a primary (the Earth) with a satellite body (the Moon). Unlike a true moon, Earth's moon's orbit is always concave towards the Sun. (Contrast this with the Galilean satellites of the plant Jupiter. Their orbits are always concave towards Jupiter, and frequently concave away from the Sun.)
Of course, that's a little like saying that the Sun doesn't rise in the morning. I don't know about you, but I certainly saw today's sunrise...
Here it is:
I am a Microsoft employee, and more than that, I am a shareholder in said corporation. I stongly support the actions that the corporation has taken to protect our intellectual property.
You, and Emmett, and that rest of the creeps here, are acting like a bunch of spoiled and petulant children. There is no issue of free speech here; there is merely an issue of gross theft and corporate malfeasance.
You don't own Kerberos. My tax dollars payed for it, too, you know, under a set of rules that were in force at the time. If you want to change those rules, fine; you may have a public case in support of that, and I am prepared to listen to it. That doesn't matter for Kerberos, though; those rules are well established.
A Microsoft architect, acting within those established rules, designed an extension to that protocol. A Microsoft employee (probably a program manager) wrote that spec. A group of other employees (probably developers) wrote the W2K code that implements that spec. That extension, that spec, that code -- it isn't yours. It's theirs, and, by assignment, Microsoft's.
If you want to write software and distribute it under GPL, that's fine, and it is your right. If Taco believes that he should distribute Slahs for others to use, more power to him. I disagree. I will not live by those rules.
Live with it.
And stop posturing. What you're arguing about is not all that important. It is not a first amendment issue. You are not being censored. Nobody has tried to blacklist you. Go look at what happened to the Weavers, or to other Communists who were blacklisted during the McCarthy era -- you don't have a clue what they really faced, and it is disgusting to see spoiled little children like you trying to pretend you are going through the same thing. Go look at what Martin Luther King did and faced. Hell -- have crosses burned on your own front yard, as I HAVE, and then come back and tell me about how you're being "censored".
I have broken the law in acts of civil disobedience in the past, and I fully expect to do it again in the future. I have faced down the Man, and I know why and where and what for. But the consequence of that is this, Robin: I know what is worth fighting for, because I have genuinely fought for those things.
The right to steal other people's work, whether Microsoft does it or you do it -- that's not worth fighting for. That's worth spitting on.
Grow up.
Actually, the picture is a lot more complicated than that.
If I produce something that costs $1, and I ship it out the door immediately, and my customer receives it, and pays $10 plus shipping, then I profit $9. If I produce something that costs $1, and I store it in a warehouse for three months, and I pay for an inventory control system to keep track of it, and, and, and...then I quickly eat up my profit. Needless to say, the latter is a more realistic model of a business that sells atoms.
Ironically, if the RIAA could get a vig on each mp3 that was traded, they'd make a lot more money, because it is much cheaper to store bits than it is to store atoms. This is why I'm startled by the MP3.com case -- the RIAA members could make a lot of money by supporting a "free" ad-supported site that doled out MP3's for a nominal charge while paying a small royalty.
But nobody has ever said that the recording labels were smart, merely right. Obviously, they aren't smart...
I recently purchased a new USB device for one of my computers. As far as I know, it's functionality is unique.
Unfortunately, there's no stable driver for it under W2K -- and there are no drivers as at for FreeBSD or Linux. So I'm stuck with the vendor's late beta. The vendor is clearly dropping this product line, and I'd be willing to write a driver for it, just to get it working. (To be honest, given what I want this device for, the vendor probably won't want some parts of my final driver, since it will support a single-use protocol that...well the company certainly doesn't care about. No matter. Most of the driver would be useful.)
I understand the vendor's concern, mind you -- this device also has some features that they are using for competitive advantage for other items in the product line, and they really don't want their competitors stealing those advantages. I'd be willing to not be given those parts of the spec, though; I just want access to two features. I wonder if there's a well to get part of a spec without getting the whole thing.
Netscape Navigator. Eudora. Mozilla.
Not quite. The original model ran javascript and vbscript, just like the current version does. Those are safe, in Outlook, Outlook Express, Netscape Navigator, whatever.
It did not run scripts under WSH. (WSH didn't even exist when O97 was released.) What you're talking about the ability of IE (and Outlook, all versions) to download and run ActiveX controls. That trust model has not yet been violated.
Outlook autoruns Javascript, yes. It autoruns ActiveX controls on your system that you have marked "Safe for scripting". But, once again, ask yourself a question: where did those controls come from? How did they get on your system?
You put them there yourself, of course. By installing them. Or disable the feature; it's a standard checkbox. (And, frankly, because I don't trust code on my system, I disable everything that my Administrator hasn't explicitly enabled.)
how many users know what a VBS icon is supposed to look like?
Doesn't matter. The WRONG icon showed up, and any user should recognize that. You see, to launch a file on the desktop, you click on the icon next to the file. All plain text files show the Notepad icon, not the "blue S in a box" icon of the scripting engines. Users should never ever launch an application with an unknown icon, just as they should never run a file with an unknown #! line at the front in Unix.
It's like all computing environments -- if you don't know what it's going to do, and you can't protect yourself from any conceivable harm it might cause, just don't do it.
No. Outlook does not autorun scripts. As I've said on a number of occasions, the only MUA that does that is Gnu Emacs -- and then, only if the user has configured it in a really stupid fashion.
1. A "malicious" bash script can not make itself run as root.
2. I believe (may be wrong on this) that the thing "looks" like a text file if you have "known extensions hidden" as per default
Actually, you're wrong on both counts. If you hide file extensions, then the item shows up with the vbs icon, not the text icon. Second, a malicious bash script can certainly run as root...if you're logged on as root. If you never read your mail as root (good for you!), then all the thing could do is send mail to everyone you've ever received mail from and trash your personal files...which is bad enough, I'd think. If you're logged in as root, though, a bash script could trash your system.
(That's why you shouldn't ever log in as root on a *n*x box, and why you shouldn't make your main account an Administrator in NT.)
All I can say is "God, if only!" Our state supremes are elected -- although if you look at what the state of Washington has elected in the last few years, I don't think you'll see a lot of political influence from Microsoft, frankly.
What you need to realize is that the state of Washington, and the city of Seattle in particular, have a love-hate relationship with Microsoft. They're vaguely proud of us, in the same way that you might be proud of your dog after it turned over the picky neighbor's trash...on the one hand, you're glad to see the neighbor humiliated, but, on the other hand, you still think the mutt stinks.
To read the local press, we're the source of all evils locally. We're blamed for the "sudden" rise in housing prices in the city, for traffic on the 520 bridge, for the rise in crime, and for social injustice. Sometimes I'm surprised that we haven't been accused of having a role in the 1980 eruption of Mt. St. Helens!
The truth is that Microsoft is a small part of a very large city. Certainly, many of the company's employees are wealthy, but Seattle is still the center of the circles of power in the state. There just aren't enough of us to really throw our weight around.
I honestly think the safest policy for GPLware would be to ship it as source code only, saying "Here's some code you might be able to make an application out of."
Seriously? That's interesting. Is that because you think that shipping it as source with such a license would reduce liability, or because you think it would increase liability? Or is there some other reason?
Well, first, you need to keep in mind that most people are running 56K modems or worse, and that this patent was filed for in 1997. So your asymetry argument is weak to begin with.
But even considering ADSL, your argument fails. When Debian sends down the package list, it doesn't know what packages you've got, much less what their build versions are. So it's got to send the whole batch down. Now, I don't care how cheap each one is (and they aren't; you're actually sending a fair amount of data) -- that's a lot of data when there are thousands of packages available. Microsoft's solution needs to send only a tiny amount of data; properly optimized (and how's not obviousness; I can think of a number of ways, and only experience would determine which), it should be possible to send only a small number of dates and program ids. Moreover, that data should be compressible; at worst, it's 128 bits per PROGID and 64 bits/NT time stamp. That's, what, 24 bytes for a small number of exceptions, plus an 8 byte header field for the time of the last complete update.
And your second objection doesn't work either: somewhere along the line, the server needs to get a list of which packages to send, whether you compute that list locally or on the server itself. Kind of defeats "privacy" right there, right?
That leaves the "overloaded server" argument. You're right, of course: written badly, this would swamp the server. Do you think that it can't be written well and cleverly? It isn't obvious how one would do that, but I can think of a lot of optimization hacks that might make it much faster. It'd take quite a bit of work to actually balance them all to get a high-throughput, robust system to handle the calls, clearly, but my experience suggests that it could be done.
But, either way, this is a non-obvious, useful invention. That's the basis of a valid patent.
No! And in a very key way...
apt gets the latest package list, checks it against what's on your system, and downloads all the needed packages and installs them
There's a key distinction here, and it's why the system really is an improvement. On a slow wire, the amount of data transmitted needs to be restricted. So, what? So you absolutely DO NOT want to send the entire package list to the client! Instead, you want to send an encoded date to the server, and let it send you the updates that *might* apply. (It's not enough to send the date when you last did an update; as might choose not to take a component of that update. You might need to send an exceptions list, too.)
Hmmm...doing that well's not going to be easy; it's going to take some fairly clever design (what about losing connectivity? How do you keep the applications database in sync? The registry is transacted...hmm, gotta think about this.)
Solving these problems isn't trivial; it's non-obvious. And that's what the patent is about -- not how to send updates; clearly, that's got prior art. It's how to do it fast with limited bandwidth.
Two words: Gnu Emacs. There's a really cool thing which Emacs does: it allows you to read e-lisp out of any buffer before opening it. And, unlike Outlook, it allows you to select a configuration in your .emacsrc which would execute that lisp code without any user intervention. (Yes, the use of that particular feature is deprecated, but it's still there.)
Now...since e-lisp is really a reasonably powerful scripting language, don't you think that constitutes a security hole a lot bigger than the one which people keep pretending is in Outlook?
I'll bet that you had an email named "Virus" open on your screen. The front panel of the task manager shows only the titles of active, visible windows. Since this particular darling doesn't open a window, it couldn't have spawned the effect you saw.
You were right to begin with: you can't spawn the virus unless you execute the attachment. Windows Scripting Host scripts are not part of standard HTML.
Actually, it is a real piece of security...for the world.
The idea of putting the weapon development work under DoE but the deployment work under DoD, is to diffuse the power over the weapons themselves. The people who make the weapons have to give them up to somebody else. The somebody else doesn't know how to make them. That way, if one group goes rogue, the other one can stand in their way.
It goes back to the end of the Second World War: the AEC (one of the main precursors to the DOE) controlled LANL (now LASL), LLL, Hanford and Oak Ridge; that control has since passed to DoE. The DoD controls deployment facilities. To this day, it is very hard to get access to both the development facilities and the deployment plans.
_Obfuscate_, along with its sequel _Obfuscate II: Return of the Fud_.
Of course, everybody loves _DeadRat_ (goal is to make lots of money selling dead rats that you got for free, or, better still, by not selling the dead rats, but convincing others that you can make money selling life support systems for them)
_Johnny takes a Napster_ (derived from the board game of the same name, a thrilling game about toddlers who badly need some sleep.)
Hey, these are stupid games, remember? You don't know whether his posting was a parody of Janet Reno, or of somebody's view of Janet Reno. Either way, it was clever -- it just would have been cleverer if it were the second, instead of the first.
You know, even a month ago, I'd a have disagreed with Jon violently about this. But now, a month later, I've had my eyes opened. I'd never really experienced the joy and convenience that free and ready access to music outside my collection brought.
/. and the purely corporate attitude of the straw-man that you would propose the music idustry to be...and that there are already solutions in place, on the ground, that provide that?
But then I found a source of free and easy-to-obtain music, so that I can stand in my kitchen and listen to stuff I wouldn't ever buy without testing it first. I found some of Robert Palmer's solo stuff -- really good -- and an a capella group called _The Blenders_ -- musically better than The Bobs, but not as intellectually challenging. I got a bunch of old Elvis Costello CD's, with their bonus tracks; by God, I'm updating my vinyl.
And I'm confident that the RIAA won't be coming after me. They'll never find me, and even if they did, they wouldn't dare bother me.
BECAUSE I BORROWED THESE CD'S FROM MY LOCAL LIBRARY. What a lot of this debate misses is one key fact: there are ways of getting the good parts of MP3 and Napster without breaking the law. That's why the music industry wants you to be tied to a physical object, and that is why they're right. I have to return these CD's, but I'll buy some of them. And I won't be able to keep the ones I don't buy. And that's a perfectly reasonable compromise: I can listen to stuff that I don't own, without taking the artist's and the companies legitimate right to make money.
Now why is that so hard, Jon? Why is it so hard to distinguish between "borrowing" and "stealing", and why is it so hard to understand that there are middle grounds between the purely anarchistic attitude of
There's an important subtlety here. Although MP3.com got nailed for copyright violation, they've not yet been assessed damages, and it isn't clear what damages could be assessed against them. Although their storage system was illegal, a consumer was required to provide evidence that he or she had the right to access a given item in the conglomerate store before he or she could access it.
IANAL -- but doesn't that mean that the total lost revenue and lost profit to the record companies is 0?
All very fine and good -- but the Chief Software Architect for Microsoft Corporation lives in Medina.
I am not aware of any users who have modified the Red Hat installer to take out the offensive code requiring entry of a root password. I haven't even heard any complaints about it.
What about people who make a single image of their default install and then blast it out onto many computers in their installation? That's not quite the same thing, but everyone that I've ever asked about it says "Of course I don't change the root password after I install a new box. If I did, I'd have to enter it by hand!" (Let's have a moment of silence for these future victims of accelerated evolution, shall we?)
- That, however, requires a genuine installation routine, so that the source can't be installed without the defaults being changed. That, in turn, makes it impossible to have a truly secure open source solution.
Depends. Under the GPL, it is technically impossible. That portion of my code which enforces the user-defined password is subject to modification by any user, and the license gives people free rein to do just that. Since anything like that is considered a hassle by most developers, how long do you think it would remain in the code? Under BSD? Of course; the limits there are even lighter. Under some kind of Artistic license? (E.g. You may view the contents of this file, but the license is void if you modify them, or attempt to subvert their interface with the balance of this package...etc.) maybe -- but how would *you* personally feel if *I* tried to ship software with such a restriction, keeping in mind that I work for MS?I don't think that follows. Clearly, RH didn't do it here, but is it truly impossible for OSS?
I hate to agree with Black Parrot on anything, but he's right. There's no such thing as a safe default password.
However, I'd do a little further. Safety lies in writing the original code so that the password is guaranteed to be user-dependent. True security lies in requiring the password be set on install. You can blame the user for not changing the password, but systems administrators are busy people, and they aren't generally going to do so unless they're forced to. That being the case, a developer who merely says "do this" when it's important, and doesn't mandate that it happen, is acting negligently.
That, however, requires a genuine installation routine, so that the source can't be installed without the defaults being changed. That, in turn, makes it impossible to have a truly secure open source solution.