Yeah, the Write Once, Run Anywhere thing doesn't work quite as advertised. Therefore we should throw sense to the winds and deliberately write code which will have to be completely rewritten if we want to run on another platform. Java is one example, and a particularly poor one. Perl, python, ruby, scheme, TeX, etc, etc, etc, actually do work quite close to write once run anywhere. Not quite, of course, as you can almost always still do things that depend on the hardware at hand, but nearly always, barring bugs in the implementation of the language on the target platform.
No, the whole point of the higher-level approach is maintainability, portability, and writeability. As I quite clearly said. Funny. I feel like I'm writing for your benefit, not my own. I've been down the low-level optimize the hell out of it road, and I've been down the high level let the compiler optimize the hell out of it road. The end result is nearly always that the high level approach is better on all counts (often including performance, as with any reasonably complex program, a decently smart compiler can do much more, much safer, and much better optimization than a human).
As far as endless tweaking goes, no, I do realize that nearly nobody does that in assembler anymore. But doing it in C is almost as bad.
Game console programming is completely sheltered from the concerns of portability. You know exactly what hardware your code will run on, and you know it will never ever run on any different hardware. This allows you to make assumptions about the hardware that nobody else gets to make, and it turns out that relying on the details of the hardware actually makes for worse (unreadable, and thus unmaintainable, and thus far more fragile) code. Also, your development team is the only group of people that will ever see your code, much less work on it. Thus as long as all of you understand the horrible crufty nonsense that results, you don't have to worry about it. In the Real World, other people see, work on, and use the code that you write. So if it isn't nice and readable and understandable, you ain't gonna get very far. So, in game console programming, you are sheltered from readability concerns as well. Finally, with most console games, once they are released, that is it. You never have to come back a year later and fix some obscure bug. So you are sheltered from the concerns of maintainability as well.
You might read this: http://www.cs.indiana.edu/~jsobel/c455-c511.update d.txt. It points out quite clearly that writing in a high level language often results in much faster (and less buggy!) code than writing in a low level language.
If so, you've just found an "out" for anyone who wants to copy anything - just surround it with enough original, informative commentary that using the entire original is necessary.
Good job, Watson! You've just rediscovered the entire idea behind why we have a "fair use" doctrine in the first place! What you describe is precisely what fair use was intended to cover.
Now, perhaps your fundamental goal is the copying, and not the commentary. However, you still do have to produce the commentary, or you don't get to copy. So, in the end, it works out the same as if your fundamental goal were the commentary.
That approach works just fine if you know exactly what hardware your code is going to be running on, and you know that it will never have to run on any other hardware, and you know that you won't have to ever work on it again once it is released.
In the Real World (ie not game consoles), programs must be portable. They must be maintainable. They must be writeable in a short time. Your approach completely ignores these requirements which enormously outweigh the tiny performance gains that you can get by tweaking for the hardware.
High level languages remove the portability problem entirely, by shifting it to the shoulders of the language implementors. If I implement a language on one platform, and you implement the same language on a completely different platform, any program written in that language will now run just fine on both platforms. Sure, unless your compiler or interpreter is incredibly smart, programs written in that language won't run as fast as endlessly hand-tweaked assembly programs written for that platform. But if your compiler or interpreter is even just passingly not bloody stupid, then programs in that language will run pretty close to as fast.
Higher level languages allow the programmer to express more directly exactly what he means. Suppose I have a very very low level language that manipulates bits (ie logic gates). I want an addition routine for arbitrary length sequences of bits. Implementing this in logic gates is not only very difficult and very very time consuming, but the end result doesn't look like addition at a glance. Now suppose I use a high level language. I can just write (a + b). It is clear to anyone who made it through elementary school that this code adds two things, a and b. Of course, I could abuse this, and actually make the language so that (a + b) deletes all files on the hard disk, but a realistic high level language is essentially self documenting. This means that 5 years down the road, when I've forgotten why I even wrote this bit of code, I can pull it up in a text editor and remember that it adds two numbers very easily. Suppose I then need it to add three numbers. Well, now that's a very easy change to make. The code is immensely more maintainable, not only by the original author, but by anyone, than code in a low level language.
Many of the extremely high level languages that are disparagingly referred to as "research languages" have an extremely high information density. That is, I can express in 1 line of code what it might take you perhaps as many as hundreds of lines of code to express in a low level, close-to-the-metal language. This also contributes to the maintainability, because there is a lot less room for mistakes in one line of code than in 20 lines of code. More importantly, this very high expressiveness means that I can write code in a high level language much more quickly. When you're trying to compete with other companies, or trying to finish a PhD thesis in less than 10 years, or pretty much anything at all, being able to code 20 times faster is a very important thing.
If you make a career outside of the very sheltered world of Xbox and PS3 programming, you'll see that endless performance tweaking in very low level languages is not only useless, but it is wastefully stupid.
So do you think then that everyone who thinks they are ill is in fact ill? That is, there are no illnesses that are purely psychosomatic? I don't think that this is at all obvious, and as such it would require fairly substantial proof (ie of the mathematical variety, because of the nature of the claim) before I would believe it.
So, let's stipulate that I am right. Then there exists at least one illness that really is "all in the patient's head". Now, what should the medical community do about that patient? Should they tell them that they are curing them, while really doing nothing of any consequence (for instance sugar pills that they tell the patient are a new breakthrough drug)? This is lying, and I for one would rather not have the medical community lying to patients unless the patient requests it (eg "Don't bother explaining the background that I would need to understand what you are going to say but which would require umpteen years of medical school to comprehend, just tell me a lie that is moderately close to the truth and which I can understand.").
Should they spend enormous amounts of money (hundreds of research doctors' entire salaries) chasing after cures that they know do not exist? I don't like that idea. I think it is much better to spend money on things that actually have some reasonable chance of succeeding. OTOH, I don't play the lottery.
Or should they try to convince their stubborn and pigheaded patients that their illnesses are imagined? If a patient comes to believe that his/her illness really is imagined, perhaps they will seek psychological care or therapy of some sort, and actually get better. If a patient persists in believing that this nonexistent illness is real (remember, we stipulated that the illness isn't real), then sure, they'll go for alternative mumbo jumbo, and perhaps that will cure them, just as the sugar pills might have. But the alternative treaters are lying to them just as surely as a doctor prescribing sugar pills would be.
OTOH, just to play the devil's advocate, you might say that the closed nature of Apple allows them more freedom to innovate with new modes of operation. If there were more transparency in Apple and its competitors, then certain things that Apple might do would be considered trustworthy. If they tried to branch out into new territory business-model and software-management-model wise, then we would be able to see that, and since most people don't trust change, they would lose market- and mind-share. With a closed system, they are evaluated entirely on their end results, so they are more free to innovate internally, and might well find some new internal mode which turned out to be better than anything done before.
In short, in a totally open system, things might tend to get locked up by process.
I don't think it actually works out to be better, on balance, to have a closed system, but going to an open system is not purely beneficial to the market. In order to demonstrate that an open system is better overall, you not only have to show that it has benefits, but that those benefits outweigh the costs.
Three breaths, huh? He must be a really slow breather. I could hold my breath for longer than it would take any normal person to take three breaths, with absolutely no danger of passing out, much less dying. N2 is inert. It is not poison. The worst it will do is displace oxygen, giving about the same effect as holding your breath. Since your brain can survive for I believe about 7 minutes without oxygen (although anything over what, 2 minutes I think, tends to cause some brain damage), you'd have to remain in a very low oxygen or oxygen free environment for that long before you'd have really serious problems.
The laptop came with a 17 inch widescreen, and the 128 MB ATI card driver suggested that I use the maximum resolution, but I opted instead for 1024x768 since everything would be easier to see. The owner changed that right off, and all I could do was point out the very small text, and the reasoning for my resolution choice.
You do realize that font sizes are not fixed permanently set in stone forever by edict from on high? If the text is too small, make it bigger by increasing the font size. Don't compromise the resolution of everything on the system just to make the text bigger. Geez... when all you have is a hammer......
Interestingly, at the Ohio State physics prospectives grad students weekend a while back, of the two women who attended (out of 19 total), one was primarily interested in biophysics. Of the women in physics I know at my undergrad, one is going into physics education research, one is going to teach high school physics, one is going to go to med school, and the remaining one, I don't know what she's planning on doing. There are a couple of others who I don't know very well. Women make up about half of our undergraduate physics department, but almost none of them are going into physics research proper. By contrast, most of the men seem to want to go on to research. Not all, but most.
Normally I tell people to grow up (or at least think it at them). In this case though, you should grow back down a little bit. This was not a correction to the story, but a (successful) attempt at a little bit of humor. Perhaps your particular sense of humor doesn't veer this direction, but there are a lot of us who find things like "how big is a golf?" after a minor typo like that in the summary to be moderately humorous. Sorry if you think that's dumb. Deal with it.
Of course, depending on how many people were using those machines on a Saturday morning, the total amount of people-time lost might have been less if you had spent an hour manually restarting all the daemons. Then again, it was a saturday morning...
Also, if the machines are sufficiently similar to one another, you might have been able to use one of the ssh clients which logs into several machines at once and issues the same commands to all of them. I can't remember the names of any such projects at the moment, and a bit of googling didn't turn up anything... I wish I could give you a link, as the things looked to be useful on occasion.
Really? I always thought it meant something like, oh, I don't know, "found in nature"... Lots of things found in nature are quite harmful to us. Most of them are even well known and have been for quite some time now. But they still kill us just as dead. Let's cut the hippy bs. Nature is nasty and dangerous stuff. There's a lot of nice good stuff in it too, but nature is not all fuzzy bunnies and food that makes us thin and sexy and healthy. Not even close.
Saturated fat is found in nature, and we certainly understand its effects on the body, right? Same with carbohydrates (Atkin's diet anyone?), and many varieties of proteins, and minerals, and vitamins, and on and on and on. We definitely understand the effects of all of these things pretty well, right. That's why we have a nice stable and well-working healthful diet plan that doesn't change absolutely wildly every five years or so. </sarcasm>
Or did you mean that all the things found in nature that we don't yet understand well are in fact not natural? Because in that case, pretty much everything we eat is not natural.
Wow... you go too far. I am not dismissive of huge wastes of money. I think almost our entire government is a huge waste of money, and I would be perfectly happy to do away with most of it. Scratch off the NSA, the CIA, the TSA, the Dept of Homeland Security, Medicare, Medicaid, Social Security, etc. etc. etc. etc. etc. and strip the government back down to the parts of it that are actually necessary. Then you get rid of a huge waste of money. Naturally, you can't get rid of all of these things all at once, because we as a society have become addicted to them. Addicts have to be weaned off of things slowly, or nasty bad things happen. But the government shouldn't be full of almost nothing but pork, and it shouldn't be robin hood either.
Then, if there are still the problems that you think the government should be spending billions of dollars on, we can maybe fix some of them.
I'm impressed. You have managed to find an engineering program that actually cares whether or not you understand at a deep level what you are doing, rather than only caring that you can get something done. Also, you are (in my experience) nearly unique among engineering students in that you have some grasp of real Math.
"Natural" does not and never has meant "perfectly safe, non-toxic, and actually miraculously good for you!!!!!". Vitamin C, for instance, is natural. Furthermore, it is necessary to human life. In large doses, Vitamin C is highly toxic. Same goes for really everything else that your body needs. Even water.
Now, I also doubt that it is the genetic modification process itself. However, thinking that the use of natural enzymes automagically makes the process non-toxic and non-dangerous is foolish and misinformed.
Proteins are almost certainly altered by genetic modification... if no proteins were modified at all, then the modification would have clearly failed. However, most proteins are not going to be altered. But nonetheless there are some proteins which are altered, and those could be altered in such a way as to become toxic. Or even, they could be modified in such a way as to react oddly with other chemicals in the corn (say the fats and sugars and starches) to produce toxic chemicals.
Containing the same amino acids as the proteins in other foods is in no way a guarantee of non-toxicity. You do realize that most of the components of venoms, eg rattlesnake venom, are proteins which (gasp!) contain the exact same amino acids as foods?
Modifying the gene sequence (that is, genetic modification) is a modification of the biochemistry of the organism. That is precisely what it is. It is not a side effect; it is the entire point of genetic modification. The specific way in which it modifies the biochemsitry is by changing the sequence of amino acids that make up particular proteins produced by the cells. If you change that sequence, you can make any protein you want to, including toxic ones.
Yes, in the vast majority of cases, genetic modification will be benign. But this is no guarantee that it cannot produce toxins. All of the possibilities that you dismissed as "Certainly it cannot be..." are in fact "Certainly it could be..., although it is unlikely that genetic modification would cause this to become toxic."
Indeed. And if anyone doesn't know, having a particular bandgap structure is what makes semiconductors semiconductors. Note: Having a bandgap structure does not make a material a semiconductor, rather certain characteristics of the bandgap structure make a semiconductor.
You keep wifi settings in xorg.conf? That's pretty weird and no mistake, man. Do you also store your log files in/usr/bin and keep shared libraries together with man pages in/tmp?
For the last dadgum time, Computer Science is distinct from Programming. CS is to Programming as Math is to Engineering. Computer Science is about things like computability theory, Turing machines, complexity theory, languages, lambda calculus, etc. Programming is about getting something out the door that doesn't break too often. Worlds apart!
None of the jobs you describe require actual CS skills. Heck, programming doesn't really require much at all in the way of CS skills, just as engineering doesn't really require much at all in the way of math skills. (Put an engineering graduate, heck put an engineering ph.d. in a real analysis (simple stuff!) class, and watch them squirm...) Epistemology requires more real CS skills than programming does.
Yes, most universities have a programming curriculum which has been given the name "Computer Science" either because earlier in history it was a real CS department (for older programs) or because the name CS lends a false gravitas to it (for younger programs). This does not mean that programming and CS are actually the same thing. </rant>
Absolutely you can claim analogy. The essential feature of having some means of support, paid or not, is there. The analogy is comparison of the various means of support. The analogy shows that Linux without a support contract, if our only means of comparison is the existence of at least one nasty incident, is just as good (or just as bad) as a number of things with support contracts. So it also shows (since the analogy is clearly a little bit ridiculous) that using the existence of at least one nasty incident as our only means of comparison is kind of dumb.
That was in Waco, TX. Niiiice and warm most of the year. The summer is a bit unbearable (to most people... not me), but I actually quite like it. And yet I'm moving to Ohio for grad school in June. I'm going to freeze my $BODY_PART off.
Wow, you tell people not to use Linux without a support contract based on one nasty incident? Has it really never occurred to you just how ridiculous that is? I've heard of one nasty incident regarding verizon, and I'm sure I could quickly find one nasty incident for every other major cell phone company. Does that mean I shouldn't have a cell phone? I'm quite certain that I could easily find one nasty incident involving Microsoft's and Apple's tech support as well.
You've blown one bad apple entirely out of proportion. Now I'm not saying that we should sweep it under the rug, either, but surely a broader picture, including the myriad uneventful, unnoticed except by those few directly involved, and extremely helpful support threads, would be far more accurate. Yes, the failure to provide reliable support does hurt the image of linux and techies in general. However, your constant rehashing of this single incident hurts those images much much more.
How well will Linux run without a shell? Just fine, thank you. Since we are currently discussing the feasibility of referring to the kernel alone when we say Linux, we should keep ourselves consistent. The Linux kernel will chug along quite happily with no command shell whatsoever. But even that is somewhat beside the point. There are plenty of other shells. There are even other sh compatible shells. If bash has a terminal flaw, then everybody will just switch over to using something else or get hax0r3d!!1one.
It is certainly not Linux's fault if bash has a security flaw. You might argue that it is ubuntu's or redhat's or suse's fault if they continue to ship bash with an unfixed major flaw, but Linux as a kernel has nothing to with bash or fixing its flaws. You are absolutely right there. You are wrong in (apparently) suggesting that this leaves a blame vacuum. Bash and the GNU project are most directly at fault, and indirectly, the distributors are at fault.
IF, on the other hand, a flaw in bash allows a Linux box to really be completely owned by an attacker, then that most likely is Linux's fault. Here is a case where comparing the Linux kernel to the Windows kernel is certainly useful. A bug in bash is not very useful to an attacker unless it corresponds with a Linux bug, say by allowing bash to overwrite memory it isn't supposed to touch, or whatnot. In most of the Windows kernels, however, a bug in one application could very easily allow privilege escalation, or arbitrary memory access, or all kinds of other very bad stuff. In that regard, Linux absolutely is more secure than Windows (I don't know about Vista).
So, in short, yes, speaking of Linux as solely the kernel is useful. Comparing the Linux kernel to the Windows kernel is useful. Speaking of Linux as a distro, or even as all distros, is useful. Comparing Linux distros to Windows distros (oh wait, there's only one of those for each version of the Windows kernel) is useful.
In a significant and large portion of the country, March is the heart of spring. I saw people studying out under trees yesterday because the weather was beautiful. It is 64F right now. I turned on my air conditioning briefly because my apartment got uncomfortably hot yesterday.
If you don't live in Maine, this makes a heck of a lot more of a difference than you apparently realize. (Yes, restricting to only Maine is an exaggeration, too. Deal with it. You know what I mean by it anyway.)
Slashdot Mirror
Yeah, the Write Once, Run Anywhere thing doesn't work quite as advertised. Therefore we should throw sense to the winds and deliberately write code which will have to be completely rewritten if we want to run on another platform. Java is one example, and a particularly poor one. Perl, python, ruby, scheme, TeX, etc, etc, etc, actually do work quite close to write once run anywhere. Not quite, of course, as you can almost always still do things that depend on the hardware at hand, but nearly always, barring bugs in the implementation of the language on the target platform.
e d.txt. It points out quite clearly that writing in a high level language often results in much faster (and less buggy!) code than writing in a low level language.
No, the whole point of the higher-level approach is maintainability, portability, and writeability. As I quite clearly said. Funny. I feel like I'm writing for your benefit, not my own. I've been down the low-level optimize the hell out of it road, and I've been down the high level let the compiler optimize the hell out of it road. The end result is nearly always that the high level approach is better on all counts (often including performance, as with any reasonably complex program, a decently smart compiler can do much more, much safer, and much better optimization than a human).
As far as endless tweaking goes, no, I do realize that nearly nobody does that in assembler anymore. But doing it in C is almost as bad.
Game console programming is completely sheltered from the concerns of portability. You know exactly what hardware your code will run on, and you know it will never ever run on any different hardware. This allows you to make assumptions about the hardware that nobody else gets to make, and it turns out that relying on the details of the hardware actually makes for worse (unreadable, and thus unmaintainable, and thus far more fragile) code. Also, your development team is the only group of people that will ever see your code, much less work on it. Thus as long as all of you understand the horrible crufty nonsense that results, you don't have to worry about it. In the Real World, other people see, work on, and use the code that you write. So if it isn't nice and readable and understandable, you ain't gonna get very far. So, in game console programming, you are sheltered from readability concerns as well. Finally, with most console games, once they are released, that is it. You never have to come back a year later and fix some obscure bug. So you are sheltered from the concerns of maintainability as well.
You might read this: http://www.cs.indiana.edu/~jsobel/c455-c511.updat
Now, perhaps your fundamental goal is the copying, and not the commentary. However, you still do have to produce the commentary, or you don't get to copy. So, in the end, it works out the same as if your fundamental goal were the commentary.
That approach works just fine if you know exactly what hardware your code is going to be running on, and you know that it will never have to run on any other hardware, and you know that you won't have to ever work on it again once it is released.
In the Real World (ie not game consoles), programs must be portable. They must be maintainable. They must be writeable in a short time. Your approach completely ignores these requirements which enormously outweigh the tiny performance gains that you can get by tweaking for the hardware.
High level languages remove the portability problem entirely, by shifting it to the shoulders of the language implementors. If I implement a language on one platform, and you implement the same language on a completely different platform, any program written in that language will now run just fine on both platforms. Sure, unless your compiler or interpreter is incredibly smart, programs written in that language won't run as fast as endlessly hand-tweaked assembly programs written for that platform. But if your compiler or interpreter is even just passingly not bloody stupid, then programs in that language will run pretty close to as fast.
Higher level languages allow the programmer to express more directly exactly what he means. Suppose I have a very very low level language that manipulates bits (ie logic gates). I want an addition routine for arbitrary length sequences of bits. Implementing this in logic gates is not only very difficult and very very time consuming, but the end result doesn't look like addition at a glance. Now suppose I use a high level language. I can just write (a + b). It is clear to anyone who made it through elementary school that this code adds two things, a and b. Of course, I could abuse this, and actually make the language so that (a + b) deletes all files on the hard disk, but a realistic high level language is essentially self documenting. This means that 5 years down the road, when I've forgotten why I even wrote this bit of code, I can pull it up in a text editor and remember that it adds two numbers very easily. Suppose I then need it to add three numbers. Well, now that's a very easy change to make. The code is immensely more maintainable, not only by the original author, but by anyone, than code in a low level language.
Many of the extremely high level languages that are disparagingly referred to as "research languages" have an extremely high information density. That is, I can express in 1 line of code what it might take you perhaps as many as hundreds of lines of code to express in a low level, close-to-the-metal language. This also contributes to the maintainability, because there is a lot less room for mistakes in one line of code than in 20 lines of code. More importantly, this very high expressiveness means that I can write code in a high level language much more quickly. When you're trying to compete with other companies, or trying to finish a PhD thesis in less than 10 years, or pretty much anything at all, being able to code 20 times faster is a very important thing.
If you make a career outside of the very sheltered world of Xbox and PS3 programming, you'll see that endless performance tweaking in very low level languages is not only useless, but it is wastefully stupid.
So do you think then that everyone who thinks they are ill is in fact ill? That is, there are no illnesses that are purely psychosomatic? I don't think that this is at all obvious, and as such it would require fairly substantial proof (ie of the mathematical variety, because of the nature of the claim) before I would believe it.
So, let's stipulate that I am right. Then there exists at least one illness that really is "all in the patient's head". Now, what should the medical community do about that patient? Should they tell them that they are curing them, while really doing nothing of any consequence (for instance sugar pills that they tell the patient are a new breakthrough drug)? This is lying, and I for one would rather not have the medical community lying to patients unless the patient requests it (eg "Don't bother explaining the background that I would need to understand what you are going to say but which would require umpteen years of medical school to comprehend, just tell me a lie that is moderately close to the truth and which I can understand.").
Should they spend enormous amounts of money (hundreds of research doctors' entire salaries) chasing after cures that they know do not exist? I don't like that idea. I think it is much better to spend money on things that actually have some reasonable chance of succeeding. OTOH, I don't play the lottery.
Or should they try to convince their stubborn and pigheaded patients that their illnesses are imagined? If a patient comes to believe that his/her illness really is imagined, perhaps they will seek psychological care or therapy of some sort, and actually get better. If a patient persists in believing that this nonexistent illness is real (remember, we stipulated that the illness isn't real), then sure, they'll go for alternative mumbo jumbo, and perhaps that will cure them, just as the sugar pills might have. But the alternative treaters are lying to them just as surely as a doctor prescribing sugar pills would be.
OTOH, just to play the devil's advocate, you might say that the closed nature of Apple allows them more freedom to innovate with new modes of operation. If there were more transparency in Apple and its competitors, then certain things that Apple might do would be considered trustworthy. If they tried to branch out into new territory business-model and software-management-model wise, then we would be able to see that, and since most people don't trust change, they would lose market- and mind-share. With a closed system, they are evaluated entirely on their end results, so they are more free to innovate internally, and might well find some new internal mode which turned out to be better than anything done before.
In short, in a totally open system, things might tend to get locked up by process.
I don't think it actually works out to be better, on balance, to have a closed system, but going to an open system is not purely beneficial to the market. In order to demonstrate that an open system is better overall, you not only have to show that it has benefits, but that those benefits outweigh the costs.
Three breaths, huh? He must be a really slow breather. I could hold my breath for longer than it would take any normal person to take three breaths, with absolutely no danger of passing out, much less dying. N2 is inert. It is not poison. The worst it will do is displace oxygen, giving about the same effect as holding your breath. Since your brain can survive for I believe about 7 minutes without oxygen (although anything over what, 2 minutes I think, tends to cause some brain damage), you'd have to remain in a very low oxygen or oxygen free environment for that long before you'd have really serious problems.
Interestingly, at the Ohio State physics prospectives grad students weekend a while back, of the two women who attended (out of 19 total), one was primarily interested in biophysics. Of the women in physics I know at my undergrad, one is going into physics education research, one is going to teach high school physics, one is going to go to med school, and the remaining one, I don't know what she's planning on doing. There are a couple of others who I don't know very well. Women make up about half of our undergraduate physics department, but almost none of them are going into physics research proper. By contrast, most of the men seem to want to go on to research. Not all, but most.
awwww, common sense is no fun, mommy!
Normally I tell people to grow up (or at least think it at them). In this case though, you should grow back down a little bit. This was not a correction to the story, but a (successful) attempt at a little bit of humor. Perhaps your particular sense of humor doesn't veer this direction, but there are a lot of us who find things like "how big is a golf?" after a minor typo like that in the summary to be moderately humorous. Sorry if you think that's dumb. Deal with it.
Of course, depending on how many people were using those machines on a Saturday morning, the total amount of people-time lost might have been less if you had spent an hour manually restarting all the daemons. Then again, it was a saturday morning...
Also, if the machines are sufficiently similar to one another, you might have been able to use one of the ssh clients which logs into several machines at once and issues the same commands to all of them. I can't remember the names of any such projects at the moment, and a bit of googling didn't turn up anything... I wish I could give you a link, as the things looked to be useful on occasion.
Really? I always thought it meant something like, oh, I don't know, "found in nature"... Lots of things found in nature are quite harmful to us. Most of them are even well known and have been for quite some time now. But they still kill us just as dead. Let's cut the hippy bs. Nature is nasty and dangerous stuff. There's a lot of nice good stuff in it too, but nature is not all fuzzy bunnies and food that makes us thin and sexy and healthy. Not even close.
Saturated fat is found in nature, and we certainly understand its effects on the body, right? Same with carbohydrates (Atkin's diet anyone?), and many varieties of proteins, and minerals, and vitamins, and on and on and on. We definitely understand the effects of all of these things pretty well, right. That's why we have a nice stable and well-working healthful diet plan that doesn't change absolutely wildly every five years or so. </sarcasm>
Or did you mean that all the things found in nature that we don't yet understand well are in fact not natural? Because in that case, pretty much everything we eat is not natural.
Wow... you go too far. I am not dismissive of huge wastes of money. I think almost our entire government is a huge waste of money, and I would be perfectly happy to do away with most of it. Scratch off the NSA, the CIA, the TSA, the Dept of Homeland Security, Medicare, Medicaid, Social Security, etc. etc. etc. etc. etc. and strip the government back down to the parts of it that are actually necessary. Then you get rid of a huge waste of money. Naturally, you can't get rid of all of these things all at once, because we as a society have become addicted to them. Addicts have to be weaned off of things slowly, or nasty bad things happen. But the government shouldn't be full of almost nothing but pork, and it shouldn't be robin hood either.
Then, if there are still the problems that you think the government should be spending billions of dollars on, we can maybe fix some of them.
I'm impressed. You have managed to find an engineering program that actually cares whether or not you understand at a deep level what you are doing, rather than only caring that you can get something done. Also, you are (in my experience) nearly unique among engineering students in that you have some grasp of real Math.
"Natural" does not and never has meant "perfectly safe, non-toxic, and actually miraculously good for you!!!!!". Vitamin C, for instance, is natural. Furthermore, it is necessary to human life. In large doses, Vitamin C is highly toxic. Same goes for really everything else that your body needs. Even water.
..." are in fact "Certainly it could be ..., although it is unlikely that genetic modification would cause this to become toxic."
Now, I also doubt that it is the genetic modification process itself. However, thinking that the use of natural enzymes automagically makes the process non-toxic and non-dangerous is foolish and misinformed.
Proteins are almost certainly altered by genetic modification... if no proteins were modified at all, then the modification would have clearly failed. However, most proteins are not going to be altered. But nonetheless there are some proteins which are altered, and those could be altered in such a way as to become toxic. Or even, they could be modified in such a way as to react oddly with other chemicals in the corn (say the fats and sugars and starches) to produce toxic chemicals.
Containing the same amino acids as the proteins in other foods is in no way a guarantee of non-toxicity. You do realize that most of the components of venoms, eg rattlesnake venom, are proteins which (gasp!) contain the exact same amino acids as foods?
Modifying the gene sequence (that is, genetic modification) is a modification of the biochemistry of the organism. That is precisely what it is. It is not a side effect; it is the entire point of genetic modification. The specific way in which it modifies the biochemsitry is by changing the sequence of amino acids that make up particular proteins produced by the cells. If you change that sequence, you can make any protein you want to, including toxic ones.
Yes, in the vast majority of cases, genetic modification will be benign. But this is no guarantee that it cannot produce toxins. All of the possibilities that you dismissed as "Certainly it cannot be
Indeed. And if anyone doesn't know, having a particular bandgap structure is what makes semiconductors semiconductors. Note: Having a bandgap structure does not make a material a semiconductor, rather certain characteristics of the bandgap structure make a semiconductor.
You keep wifi settings in xorg.conf? That's pretty weird and no mistake, man. Do you also store your log files in /usr/bin and keep shared libraries together with man pages in /tmp?
$1B on a $1T scale is chump change. Simple.
For the last dadgum time, Computer Science is distinct from Programming. CS is to Programming as Math is to Engineering. Computer Science is about things like computability theory, Turing machines, complexity theory, languages, lambda calculus, etc. Programming is about getting something out the door that doesn't break too often. Worlds apart!
None of the jobs you describe require actual CS skills. Heck, programming doesn't really require much at all in the way of CS skills, just as engineering doesn't really require much at all in the way of math skills. (Put an engineering graduate, heck put an engineering ph.d. in a real analysis (simple stuff!) class, and watch them squirm...) Epistemology requires more real CS skills than programming does.
Yes, most universities have a programming curriculum which has been given the name "Computer Science" either because earlier in history it was a real CS department (for older programs) or because the name CS lends a false gravitas to it (for younger programs). This does not mean that programming and CS are actually the same thing. </rant>
Absolutely you can claim analogy. The essential feature of having some means of support, paid or not, is there. The analogy is comparison of the various means of support. The analogy shows that Linux without a support contract, if our only means of comparison is the existence of at least one nasty incident, is just as good (or just as bad) as a number of things with support contracts. So it also shows (since the analogy is clearly a little bit ridiculous) that using the existence of at least one nasty incident as our only means of comparison is kind of dumb.
Nice analogy. One correction, though. Only one guy sees the canyon. The others hear that he saw the canyon and freak out.
Climate scientists make up a tiny portion of the total population, after all.
That was in Waco, TX. Niiiice and warm most of the year. The summer is a bit unbearable (to most people... not me), but I actually quite like it. And yet I'm moving to Ohio for grad school in June. I'm going to freeze my $BODY_PART off.
OMGWTFBBQ!!1 YAETLA! (Yet Another Extended Three Letter Acronym!) NWDIM? (Now What Does It Mean?)
Wow, you tell people not to use Linux without a support contract based on one nasty incident? Has it really never occurred to you just how ridiculous that is? I've heard of one nasty incident regarding verizon, and I'm sure I could quickly find one nasty incident for every other major cell phone company. Does that mean I shouldn't have a cell phone? I'm quite certain that I could easily find one nasty incident involving Microsoft's and Apple's tech support as well.
You've blown one bad apple entirely out of proportion. Now I'm not saying that we should sweep it under the rug, either, but surely a broader picture, including the myriad uneventful, unnoticed except by those few directly involved, and extremely helpful support threads, would be far more accurate. Yes, the failure to provide reliable support does hurt the image of linux and techies in general. However, your constant rehashing of this single incident hurts those images much much more.
How well will Linux run without a shell? Just fine, thank you. Since we are currently discussing the feasibility of referring to the kernel alone when we say Linux, we should keep ourselves consistent. The Linux kernel will chug along quite happily with no command shell whatsoever. But even that is somewhat beside the point. There are plenty of other shells. There are even other sh compatible shells. If bash has a terminal flaw, then everybody will just switch over to using something else or get hax0r3d!!1one.
It is certainly not Linux's fault if bash has a security flaw. You might argue that it is ubuntu's or redhat's or suse's fault if they continue to ship bash with an unfixed major flaw, but Linux as a kernel has nothing to with bash or fixing its flaws. You are absolutely right there. You are wrong in (apparently) suggesting that this leaves a blame vacuum. Bash and the GNU project are most directly at fault, and indirectly, the distributors are at fault.
IF, on the other hand, a flaw in bash allows a Linux box to really be completely owned by an attacker, then that most likely is Linux's fault. Here is a case where comparing the Linux kernel to the Windows kernel is certainly useful. A bug in bash is not very useful to an attacker unless it corresponds with a Linux bug, say by allowing bash to overwrite memory it isn't supposed to touch, or whatnot. In most of the Windows kernels, however, a bug in one application could very easily allow privilege escalation, or arbitrary memory access, or all kinds of other very bad stuff. In that regard, Linux absolutely is more secure than Windows (I don't know about Vista).
So, in short, yes, speaking of Linux as solely the kernel is useful. Comparing the Linux kernel to the Windows kernel is useful. Speaking of Linux as a distro, or even as all distros, is useful. Comparing Linux distros to Windows distros (oh wait, there's only one of those for each version of the Windows kernel) is useful.
In a significant and large portion of the country, March is the heart of spring. I saw people studying out under trees yesterday because the weather was beautiful. It is 64F right now. I turned on my air conditioning briefly because my apartment got uncomfortably hot yesterday.
If you don't live in Maine, this makes a heck of a lot more of a difference than you apparently realize. (Yes, restricting to only Maine is an exaggeration, too. Deal with it. You know what I mean by it anyway.)