How is it different?
1. Modifying a car requires tools and skills very different in nature from modifying software
2. Modifying software requires tools and skills very different in nature from moidyfing a car
It is much more reasonable and simple to modify software than it is to modify hardware, to any given level of complexity. Put another way, it's easy to make cosmetic changes to both, but it's much harder to make nontrivial changes to hardware (where hardware could be cars or solid state electronics or the genetic code of a tree) than it is to make nontrivial changes to software.
When we consider the original topic, the difficulty of fixing problems in a defective item should certainly be taken into account when deciding on liability for the defect. If, as I do, I have a car with a component that is being recalled by the manufacturer because it occasionally bursts into flame, and if I were able to fix the problem because my neighbor with the same car and the same problem fixed hers (and I simply copied the fix in a few seconds by pressing a few keys on a keyboard), then the analogy would hold. Such is the case with software; such is not the case with hardware.
Part of the problem with the meta-problem (whether or not to put liability on free software authors) is the idea that my culture holds that in general, people should not be penalized for altruism. I'm all for people writing better software, but I don't at all like the idea of forcing people do change their hobby out of fear of litigation, when that hobby is as simple and altruistic as writing computer programs and giving them away. And what about people who write Free Software and then sell it as part of their business?
Unfortunately, I haven't come up with a good (enough) reason to justify exempting free software authors to myself yet.
The presumption could be that releasing source code allows the user to take responsibility for the correct operation of the software.
That's a bit like saying a car company shouldn't be held responsible for putting faulty brakes on a car, since after all, the car owner could have replaced the brakes with something that worked.
Modifying software is very different from modifying a car. There is no equivalent to open source software in the car world; modifying a car requires tools and skills that are very different in nature from modifying software.
As for me, I'm not sure which way I lean yet on this issue. It's quite possible that my bias against closed-source software is unfairly influencing my desire to see closed-source, but not open-source, software makers able to be held liable for major flaws or gross negligence.
On the other hand, if somebody claims that something will do something, and I give them money in order that it may do that thing, and it does not do that thing, then I should at least be able to get my money back, and if the failure of that thing to perform causes me damages, I should be compensated for those too. But by whom? How much of the fault is the supplier who lied to me and how much of the fault is mine for not checking out the supplier better?
Object Orientation is a programming style, not a set of language features. Some languages (e.g. C++ and Java) attempt to encourage object-oriented programming, but the world is full of non-object-oriented programs that use this languages.
Using object oriented programming techniques in C is not a sign of delusion, it's an attempt to do more with less.
Last time they tried this, the major roadblock was that no one could figure out how to build a server fast enough to stream multiple, unique video streams. Even assuming you're using conventional televisions and the stream size is limited to 500kB/s, you've maxed out Fibre Channel bus at 40 users under ideal conditions - and for each such group of 40 users, you need a complete copy of all the video material available, at perhaps a terabyte. There's just no way, using today's technology, to get more data on to the network - so the cable company will be stuck with tens of thousands of VoD servers, all reading information off their hard drives at the maximum rate for 24 hours a day.
It is true that one choke point are the hard drives. One DVB stream takes half a megabyte a second of bandwidth, and so a single hard drive is probably going to be able to source only 50 or so streams. (The fact that there is probably going to be lots of seeking involved limits the practical speed of the drives to a fraction of their theoretical maximums.) But hard drives are getting cheaper every day, and the real bottleneck is the cost of the Fibre Channel SAN that you'd need to hook all of these disks to your pool of VOD servers.
Initially I noted what you point out, but I removed it from my post because I have no guarantees that a user that's connected to some other part of the network I use can't remotely connect to the part of the network that I'm using. Hopefully that makes sense.
For example, somebody could send malformed packets that exploit telnetd (which was the original point of this conversation) from their host, through the ethernet switch and to the server in question.
If I'm lucky enough to (correctly!) trust everybody who is physically connected to my ethernet network, then I can run telnetd, etc. without worries. In practice, people aren't this conservative; they usually "trust" a firewall to filter out everybody they don't trust. It's also possible to have machine that's connected to an outside network, but the outgoing connection does not have any protocols or programs running on it that are able to be exploited.
Since Telnet and Rlogin are insecure by design, they should only be allowed to be used in environments where you implicitly trust all parties.
What "parties" are you talking about exactly? I assume you mean the network infrastructure between the client and the server?
Plus all users on all clients that use any part of the network infrastructure.
Obviously, this is only possible in isolated and well-controlled networks, but it is possible. Example: a Beowulf cluster that's not connected to an outside network.
Volcanic eruptions can be so great as to cause the birth of islands. There was a well-studied one in the Pacific in 2000, i believe.
I don't disagree with the literal meaning of your words, but it's worth noting that the reason why islands forming this way tend to be well-studied is because it's so infrequent, non-geologically-speaking.
He didn't say that Wolfenstein 3D was the original. He said that this game will be judged against the original version of Wolfenstein 3D, which this is the sequel to.
I don't think there's much similarity between the Apple II version of Wolfenstein and this new Wolfenstein except for the name and possibly the plot.
"Fair" is an interesting word. If I make a product that is specifically designed to compete with my competitor's Product X, it's not accurate to say that my product is a failure if my competitor's Product X+2 is better than my product. Is it "fair" to judge something using criteria that it was never intended to consider?
For example, the K6 was designed to compete with Pentium MMX and early Pentium II chips. There should be few surprises presented by a study that compares the performance of the K6 to the performance of the Pentium IV.
But that's the whole point. Unless you've vetted the compiler you don't know what's been hacked into it!
Yes, exactly. I don't know about you, but it's much easier for me to vet my compilers than it is for me to write them from scratch.
The process is greatly simplified by the fact that you can often use the same compiler to compile itself; yes, you have to start with a precompiled one, but simply compare the vetted one with the precompiled one to determine if the precompiled one has been compromised.
In fact, I would go so far as to claim that most people vet their compilers already. Their standards simply vary quite a bit in thoroughness from our own.
No, but you do need to use a compiler that hasn't been hacked in the manner described by your link. I submit that it is possible to do this without building the compiler myself.
The best feature of Linux is its stability; considering my uptime is 134 days, I could care less about the boot process.
I agree. When booting so infrequently, it's often difficult to remember quite how to operate that confusing LILO thing. A graphical boot loader would help immensely with this problem and help make Linux palatable for elite, yet forgetful sysadmins with months of uptime - an important demographic that we linux advocates should not overlook.
I think you're making a fundamental mistake here: war is a glorious, righteous and honorable thing. Killing starving peasants is a great way to show patriotism to one's country and to stand up for one's ideals. I know that this is true, because I saw it on tv.
Actually, there's some truth to his point. Say a process makes a system call and the kernel code for that call hangs in a loop. Since the scheduler won't preempt the kernel code, that process will run forever and the machine will hang. If the kernel can be preempted, the user can get to a shell and kill the stuck process. I have no idea how often this situation would happen in the real world, though.
Will the linux kernel allow a user process to be killed that is blocked in a kernel call? In my experience, Solaris and Tru64 do not: a user program that is blocked in a kernel call will stay blocked until the kernel call returns, regardless of any action (short of rebooting the machine) that a user can take. I assume that there is some well-thought-out reasoning behind this, but sometimes (e.g. during device driver development) I wish it were somehow a configurable behavior.
I'd think that infinite loops would be too much of a newbie bug.
Lots of times, the most junior person gets stuck writing device drivers. And even experienced programmers can have brain farts.
One thing I really hope we learned first from Vietnam and second from the Russian attack on Afghanastan is that you cannot fight unconventional forces with conventional forces.
Today, though, the definition of "conventional forces" is much more blurry than it was in the past. Are the U.S. Marines conventional forces? They are certainly capable of fighting in a very flexible manner, and they consider themselves to be elite forces. Any ground war in Afghanistan is going to involve actions, performed by regular units, that in past wars would have been considered "unconventional."
I don't advocate it, but I believe that if the US decided to invade Afghanistan and fight a ground war, we would be more successful than the British and Soviets, for three main reasons:
1. The Taliban doesn't have outside support, and the US does
2. The US has the benefit of hindsight, has been practicing and refining non-conventional war for the last decade in a variety of countries around the world.
3. The technological advantage
lets see you maintain at least 60MPH on the tollways and highways around Chicago. this is what would happen: you could/wound not and we would kill you. or some jackass would die trying to avoid killing you (he would probably be from Wisonsin, they are very sweet people there)
Or, even more likely, you'd run into the person from Wisconsin, because they're driving 10 mph below the speed limit.
Slashdot Mirror
1. Modifying a car requires tools and skills very different in nature from modifying software
2. Modifying software requires tools and skills very different in nature from moidyfing a car
It is much more reasonable and simple to modify software than it is to modify hardware, to any given level of complexity. Put another way, it's easy to make cosmetic changes to both, but it's much harder to make nontrivial changes to hardware (where hardware could be cars or solid state electronics or the genetic code of a tree) than it is to make nontrivial changes to software.
When we consider the original topic, the difficulty of fixing problems in a defective item should certainly be taken into account when deciding on liability for the defect. If, as I do, I have a car with a component that is being recalled by the manufacturer because it occasionally bursts into flame, and if I were able to fix the problem because my neighbor with the same car and the same problem fixed hers (and I simply copied the fix in a few seconds by pressing a few keys on a keyboard), then the analogy would hold. Such is the case with software; such is not the case with hardware.
Part of the problem with the meta-problem (whether or not to put liability on free software authors) is the idea that my culture holds that in general, people should not be penalized for altruism. I'm all for people writing better software, but I don't at all like the idea of forcing people do change their hobby out of fear of litigation, when that hobby is as simple and altruistic as writing computer programs and giving them away. And what about people who write Free Software and then sell it as part of their business?
Unfortunately, I haven't come up with a good (enough) reason to justify exempting free software authors to myself yet.
That's a bit like saying a car company shouldn't be held responsible for putting faulty brakes on a car, since after all, the car owner could have replaced the brakes with something that worked.
Modifying software is very different from modifying a car. There is no equivalent to open source software in the car world; modifying a car requires tools and skills that are very different in nature from modifying software.
As for me, I'm not sure which way I lean yet on this issue. It's quite possible that my bias against closed-source software is unfairly influencing my desire to see closed-source, but not open-source, software makers able to be held liable for major flaws or gross negligence.
On the other hand, if somebody claims that something will do something, and I give them money in order that it may do that thing, and it does not do that thing, then I should at least be able to get my money back, and if the failure of that thing to perform causes me damages, I should be compensated for those too. But by whom? How much of the fault is the supplier who lied to me and how much of the fault is mine for not checking out the supplier better?
Object Orientation is a programming style, not a set of language features. Some languages (e.g. C++ and Java) attempt to encourage object-oriented programming, but the world is full of non-object-oriented programs that use this languages.
Using object oriented programming techniques in C is not a sign of delusion, it's an attempt to do more with less.
It is true that one choke point are the hard drives. One DVB stream takes half a megabyte a second of bandwidth, and so a single hard drive is probably going to be able to source only 50 or so streams. (The fact that there is probably going to be lots of seeking involved limits the practical speed of the drives to a fraction of their theoretical maximums.) But hard drives are getting cheaper every day, and the real bottleneck is the cost of the Fibre Channel SAN that you'd need to hook all of these disks to your pool of VOD servers.
It's called sarcasm.
He was trying to be funny.
Initially I noted what you point out, but I removed it from my post because I have no guarantees that a user that's connected to some other part of the network I use can't remotely connect to the part of the network that I'm using. Hopefully that makes sense.
For example, somebody could send malformed packets that exploit telnetd (which was the original point of this conversation) from their host, through the ethernet switch and to the server in question.
If I'm lucky enough to (correctly!) trust everybody who is physically connected to my ethernet network, then I can run telnetd, etc. without worries. In practice, people aren't this conservative; they usually "trust" a firewall to filter out everybody they don't trust. It's also possible to have machine that's connected to an outside network, but the outgoing connection does not have any protocols or programs running on it that are able to be exploited.
What "parties" are you talking about exactly? I assume you mean the network infrastructure between the client and the server?
Plus all users on all clients that use any part of the network infrastructure.
Obviously, this is only possible in isolated and well-controlled networks, but it is possible. Example: a Beowulf cluster that's not connected to an outside network.
Likewise, most non-creationists believe that at one time the continents were together.
I don't disagree with the literal meaning of your words, but it's worth noting that the reason why islands forming this way tend to be well-studied is because it's so infrequent, non-geologically-speaking.
Actually, there are already large dust storms on the surface. Which supports your point, so I don't know what the goal of disputing it was...
He didn't say that Wolfenstein 3D was the original. He said that this game will be judged against the original version of Wolfenstein 3D, which this is the sequel to.
I don't think there's much similarity between the Apple II version of Wolfenstein and this new Wolfenstein except for the name and possibly the plot.
An entire hour in the airlock is needed for rubbing antibacterial creme on each other's half-naked bodies.
These technologies are years away from living up to the claims of their adherents. HIPPI-6400 (aka GSN) is here now.
"Fair" is an interesting word. If I make a product that is specifically designed to compete with my competitor's Product X, it's not accurate to say that my product is a failure if my competitor's Product X+2 is better than my product. Is it "fair" to judge something using criteria that it was never intended to consider?
For example, the K6 was designed to compete with Pentium MMX and early Pentium II chips. There should be few surprises presented by a study that compares the performance of the K6 to the performance of the Pentium IV.
Yes, exactly. I don't know about you, but it's much easier for me to vet my compilers than it is for me to write them from scratch.
The process is greatly simplified by the fact that you can often use the same compiler to compile itself; yes, you have to start with a precompiled one, but simply compare the vetted one with the precompiled one to determine if the precompiled one has been compromised.
In fact, I would go so far as to claim that most people vet their compilers already. Their standards simply vary quite a bit in thoroughness from our own.
No, but you do need to use a compiler that hasn't been hacked in the manner described by your link. I submit that it is possible to do this without building the compiler myself.
Can developers work in a completely locked-down environment? It depends:
Is an ssh client installed?
Is an X server installed?
I agree. When booting so infrequently, it's often difficult to remember quite how to operate that confusing LILO thing. A graphical boot loader would help immensely with this problem and help make Linux palatable for elite, yet forgetful sysadmins with months of uptime - an important demographic that we linux advocates should not overlook.
I think you're making a fundamental mistake here: war is a glorious, righteous and honorable thing. Killing starving peasants is a great way to show patriotism to one's country and to stand up for one's ideals. I know that this is true, because I saw it on tv.
The same is true even if you don't know its pharmacology...
Will the linux kernel allow a user process to be killed that is blocked in a kernel call? In my experience, Solaris and Tru64 do not: a user program that is blocked in a kernel call will stay blocked until the kernel call returns, regardless of any action (short of rebooting the machine) that a user can take. I assume that there is some well-thought-out reasoning behind this, but sometimes (e.g. during device driver development) I wish it were somehow a configurable behavior.
I'd think that infinite loops would be too much of a newbie bug.
Lots of times, the most junior person gets stuck writing device drivers. And even experienced programmers can have brain farts.
It does help if you have in-state license plates.
Today, though, the definition of "conventional forces" is much more blurry than it was in the past. Are the U.S. Marines conventional forces? They are certainly capable of fighting in a very flexible manner, and they consider themselves to be elite forces. Any ground war in Afghanistan is going to involve actions, performed by regular units, that in past wars would have been considered "unconventional."
I don't advocate it, but I believe that if the US decided to invade Afghanistan and fight a ground war, we would be more successful than the British and Soviets, for three main reasons:
1. The Taliban doesn't have outside support, and the US does
2. The US has the benefit of hindsight, has been practicing and refining non-conventional war for the last decade in a variety of countries around the world.
3. The technological advantage
Or, even more likely, you'd run into the person from Wisconsin, because they're driving 10 mph below the speed limit.
Is it really collateral damage if it's the primary goal (or, at least, plan of attack) of one of the sides?