Something tells me that his article makes alot of use of the fine art of sarcasm (see the bit about 23x6 reliability and how NT overpowers Linux for this reason). But, for sarcasm to work it needs to have a kernel of truth (pun intended) at its core.
Wake up. Smell the coffee. And everyone, let's start giving Linux the image it deserves: Not the OS for the techno-nerds, but rather the OS for people that actually need to do something, rather than watch the nifty 3-D Accelerated, alpha blended, animated hourglass cursor that comes with the latest "Plus!" pack for Windows.
While RMS may claim to not be a communist and not be anti-profit, he certainly does a tremendous job convincing people otherwise.
It's too bad that many in the world view Linux as the latest way for college kids to hold their ideological protests. Rather than marching around with "Make Love, Not War" signs, we're painted as marching around with "Boot Linux, Not Windows" signs.
And let us not forget the Nixon-esq "silent majority" of happy Windows users.
*sigh*
It's all too creepy. Fortunately, I doubt the Linux movement's leaders are going to start keeling over from drug abuse. :-). Also, given that Linux users AREN'T just your average hippies and freaks, but rather are extremely pragmatic people trying to get things done (how come people always forget that tidbit), I think Linux has alot more chance to survive.
That bit about the Open Sores movement was fairly clever. I'm sure somebody's going to get alot of toasty flames that can be hand picked with asbestos oven mitts for next week's column: Linux: Where The Zealots Go Today.
The Internet was a lot smaller and a lot more trusting back then. It was growing up from a small community of highly trusting academic collaborators into the highly paranoid "trust no-one, not even yourself" culture of today.
It's just like contrasting the small country town, where nobody locks their doors and everyone knows everyone else, and the big city, in which even junker cars have car alarms apartments have intrusion alarms, and nobody knows anyone else.
In the case of Morris' worm, it relied on a couple security holes that were replicated exactly on a large number of machines. Whenever you have the exact same software widely deployed, you run this same risk. Software diversity is good for preserving and protecting computers the same way that genetic diversity is good for preserving and protecting life.
The reason Morris' worm was so effective is that it was released in an effectively mono-cultured environment. The Windows viruses and security holes of today are testament to the fact that source code access != system access. Rather, it's more like "if all the systems are the same, I only need to crack one to crack them all."
The primary bug that Morris' worm relied on, if I recall correctly, was a buffer overrun in the VAX version of finger, not in SENDMAIL. The finger daemon effectively did a system("/bin/finger luser") to get the local user's finger info, and the worm overwrote the/bin/finger bit with his own commands. (I think it just called "/bin/sh".) Since the finger daemon called this command with the network connection hooked to stdin and stdout, it could easily download itself to the new machine once it had a shell prompt.
From what I recall (though I could be recalling incorrectly), most accounts of Morris' worm development note that its development was more of an intellectual curiosity than a malicious "Gee, lets take down ARPANET today."
There are plenty of Unix-related trojan horses and exploits out there, and as Unix-based and Linux-based platforms become more common, we are likely to see a surge in the number of Unix-related viruses going around. But, since Unix and Linux still have a very large, diverse application base (rather than one dominant "Office Suite" that might as well be burned on the CD with the OS), the idea that a single VBScript prank like Melissa* and her friends could take down a whole corporation's email in an hour or two seems absurd. (After all, how are you going to infect vi, emacs, WordPerfect, etc. etc. etc...)
Also, there's the small fact that with the source code in-hand for the affected programs, the fix can be put together in those same couple of hours and deployed over the following couple days, rather than the virus making headlines on CNN for a week.
(* Note: No offense to the lovely ladies of the world named Melissa. It's a pity there's a virus that shares your name.:-) )
The Heisenberg Uncertainly Principle is inside the box, at least. If you believe in multiple, parallel divergent time lines (a sort-of "anything that could possibly happen does happen"), then time travel does not present a paradox or logical contradiction.
Time travel causes logical contradictions if you belive that the progression of time is rigidly forwardly linear and that there is a well defined, fixed cause and effect relationship between all causes and effects.
A different way of looking at the universe is that all of the particles in it, along with their motions, interactions, etc. form a gigantic system of equations. Within the bounds of the Heisenberg Uncertainty Principle, there exists the region of space-time states which solves this system of equations. You can think of this region as the "set of allowable time-lines," for lack of a better term. A given element of the set corresponds to one possible complete "existance of the Universe," which includes all time-space points of that Universe. Quite simply then, any time-line which would represent a logical inconsistency is outside of this set, because it is not a solution for the constraints of the system!
It is logical to presume that the proposed logical inconsistency simply would not happen, because it could not exist. That doesn't mean that time-travel is impossible; it means simply that it could never cause a logical inconsistency.
--Joe
--
Modules can have any license. FS's are modules.
on
SGI open-sourcing XFS
·
· Score: 2
If SGI so desired, they could actually release a binary-only module which implements XFS (complete with GRIO (*drool*) if they really wanted to), and do so without GPL or anything that resembled an Open Source license. (Ick.) With that in mind, it stands to reason that a filesystem module could be distributed under any license, since it could be built separately from the kernel and modprobe'd in.
A different question is whether or not code that is part of the kernel source tree proper (eg./usr/src/linux, also known as "everything in the linux-X.Y.ZZZ tarball") must be GPL'd, and I believe that said code does inherit the GPL from the rest of the kernel's GPL-ness. (Any license lawyers out there care to expound on this point for us?) If this is the case, then if SGI wants this to be part of the Linux kernel source tree, they'll have to jump on the GPL bandwagon.
I think "kernel patches", if they're distributed separately from the official kernel and must be applied manually by the users of the patch, are also exempt from being GPL'd, although this is a significantly greyer area. Kernel patches distributed in this fashion act very similarly to programs that #include GPL'd header files. eg. If I #include a GPL'd foo.h in my program, but I don't distribute my code with said foo.h, I don't believe my code becomes GPL'd -- even if foo.h is under GPL rather than LGPL -- although I'm not 100% certain. Anyone care to clarify on that particular grey area?
--Joe
--
My definition of "approximate" is more precise
on
Black Holes...Pink?
·
· Score: 1
When I said about and approximate, I mean +/- a much smaller delta than a factor of three. eg. The speed of light in a vacuum is 3e8 m/s +/- 1e7 m/s (a far cry from saying its between 1e8 and 1e9). Same for the 9.5e15 (+/- 1e14). It's called significant figures.
The issue is that they used the exact same (incorrect) conversion for each place that they mentioned a light-year to kilometer conversion.
Now, on the other hand, if I were approximating with logarithms, and took an exponent (either that, or I looked at a slide rule with a severe astigmatism), I could expect a factor of 3 error very easily, because that's a linear error of only 0.5 in the log10 domain.
When I took all of my science courses, I was taught that 1 light-year == the distance light travels in one year in a vacuum. In the article, they mention the following:
This quasar is about one billion light-years away (30,000,000,000,000,000,000,000 kilometres).
In other words, one billion light-years is 3e25 meters. Interpreting one billion as 1e9, this implies that one light year is 3e16 meters.
Now, if I recall correctly, the speed of light in a vacuum is approximately 3e8 meters/second. There are approximately 3.16e7 seconds in a year (365.24 * 24 * 60 * 60). Multiplying these together gives me a light-year of about 9.5e15.
So, is it just me, or are their light-years off by about a factor of 3?
Yeah, I used to tease my brother when he'd say "millihertz" (meaning megahertz, of course). Now, I'm going to his college graduation this weekend. Hopefully he learned something. ;-)
At the risk of sounding like a "Me Too!" loser, the same thing happened to me. In my case, Internet Junkbuster was clipping the cookies. (Netscape was still asking whether I wanted to accept the cookies, but IJB was keeping them from going out.)
The Apple ][ drives were pretty low density as well. I heard rumors that you could format and get at least 70K of usable space on the cardboard spacer that they put in the drive when they ship it.
According to the announcement, the presentation is for employees and their families. Are there any Fermilab people here that care to adopt me for a day? ;-)
Because new drivers may have a slightly different set of state transitions. Also, the state of the hardware may change while the kernel is being reloaded. (Think "masked interrupts".)
Maybe your hardware is defective, perhaps substandard, or unstandard.
A defective Zip drive that's isolated from the CPU bus by a parallel port should not kernel panic the system. The Zip drive itself should simply not work, and not take the system down with it.
(It's a different story when you have defective hardware on either the CPU bus, or even on the SCSI chain, because it can affect the computer's ability to operate correctly at all. The parallel port, though, is a pretty effective means to isolate hardware from the rest of the system.)
My personal (un)favorite are variables named such things as numberval (Hey, it's a number, oh, and guess what? It's a value!), and half a dozen variables named temp that I've seen in one particular coworker's code.
And English isn't his native tongue. sigh Some people just don't understand the value of consistent, concise, mnemonic variable names.
From reading the other comments here, it seems that several readers agree that this book isn't truly necessary if you've already "been around the block", so to speak. That may be true.
However, I am still seriously considering getting this book so that when people ask me "what's a good book on programming", I can reach over to my shelf and grab a good book before they accidentally pick up the latest boat-anchor by some dubious author such as Herbert Schildt* or the like. All too often, people buy books based on size or weight, and not on the solidity of the content. (Even K&R2's latest reprinting is twice as thick as the one I bought, but with the same number of pages.)
If you're a good, professional coder in any reasonable organization, you will eventually be asked to mentor, tutor, or otherwise assist less-experienced programmers. Make sure you can make the best of the opportunity by having appropriate resources ready.
(*Note: I realize that my comments regarding Schildt might be slightly inflammatory to some, but they're not without some forethought. See the comp.lang.c FAQ for more information. And no, I don't let the FAQs think for me -- I've actually seen Schildt's work and found it atrocious. I reference the FAQ since it points out most of the same things I would and more.)
Slashdot Mirror
Hmmm... sounds sorta like a certain OS that's being poo-pooed.
--Joe--
Something tells me that his article makes alot of use of the fine art of sarcasm (see the bit about 23x6 reliability and how NT overpowers Linux for this reason). But, for sarcasm to work it needs to have a kernel of truth (pun intended) at its core.
Wake up. Smell the coffee. And everyone, let's start giving Linux the image it deserves: Not the OS for the techno-nerds, but rather the OS for people that actually need to do something, rather than watch the nifty 3-D Accelerated, alpha blended, animated hourglass cursor that comes with the latest "Plus!" pack for Windows.
--Joe--
Or maybe that should be make vmlinuz instead of "Boot Linux"?
--Joe
--
While RMS may claim to not be a communist and not be anti-profit, he certainly does a tremendous job convincing people otherwise.
It's too bad that many in the world view Linux as the latest way for college kids to hold their ideological protests. Rather than marching around with "Make Love, Not War" signs, we're painted as marching around with "Boot Linux, Not Windows" signs.
And let us not forget the Nixon-esq "silent majority" of happy Windows users.
*sigh*
It's all too creepy. Fortunately, I doubt the Linux movement's leaders are going to start keeling over from drug abuse. :-) . Also, given that Linux users AREN'T just your average hippies and freaks, but rather are extremely pragmatic people trying to get things done (how come people always forget that tidbit), I think Linux has alot more chance to survive.
That bit about the Open Sores movement was fairly clever. I'm sure somebody's going to get alot of toasty flames that can be hand picked with asbestos oven mitts for next week's column: Linux: Where The Zealots Go Today.
--Joe--
Heh. 15% wider, eh? As fellow Grand Prix owners might attest, Wider is Better.
(Ok, so I drive a GTP, and I couldn't help but chime in with a joke.)
--Joe--
You want to read mail sent to root.
You do not want to read mail as root.
It's called a "mail alias."
--Joe--
The Internet was a lot smaller and a lot more trusting back then. It was growing up from a small community of highly trusting academic collaborators into the highly paranoid "trust no-one, not even yourself" culture of today.
It's just like contrasting the small country town, where nobody locks their doors and everyone knows everyone else, and the big city, in which even junker cars have car alarms apartments have intrusion alarms, and nobody knows anyone else.
In the case of Morris' worm, it relied on a couple security holes that were replicated exactly on a large number of machines. Whenever you have the exact same software widely deployed, you run this same risk. Software diversity is good for preserving and protecting computers the same way that genetic diversity is good for preserving and protecting life.
--Joe--
The reason Morris' worm was so effective is that it was released in an effectively mono-cultured environment. The Windows viruses and security holes of today are testament to the fact that source code access != system access. Rather, it's more like "if all the systems are the same, I only need to crack one to crack them all."
The primary bug that Morris' worm relied on, if I recall correctly, was a buffer overrun in the VAX version of finger , not in SENDMAIL. The finger daemon effectively did a system("/bin/finger luser") to get the local user's finger info, and the worm overwrote the /bin/finger bit with his own commands. (I think it just called "/bin/sh".) Since the finger daemon called this command with the network connection hooked to stdin and stdout, it could easily download itself to the new machine once it had a shell prompt.
From what I recall (though I could be recalling incorrectly), most accounts of Morris' worm development note that its development was more of an intellectual curiosity than a malicious "Gee, lets take down ARPANET today."
There are plenty of Unix-related trojan horses and exploits out there, and as Unix-based and Linux-based platforms become more common, we are likely to see a surge in the number of Unix-related viruses going around. But, since Unix and Linux still have a very large, diverse application base (rather than one dominant "Office Suite" that might as well be burned on the CD with the OS), the idea that a single VBScript prank like Melissa* and her friends could take down a whole corporation's email in an hour or two seems absurd. (After all, how are you going to infect vi, emacs, WordPerfect, etc. etc. etc...)
Also, there's the small fact that with the source code in-hand for the affected programs, the fix can be put together in those same couple of hours and deployed over the following couple days, rather than the virus making headlines on CNN for a week.
(* Note: No offense to the lovely ladies of the world named Melissa. It's a pity there's a virus that shares your name. :-) )
--Joe--
The Heisenberg Uncertainly Principle is inside the box, at least. If you believe in multiple, parallel divergent time lines (a sort-of "anything that could possibly happen does happen"), then time travel does not present a paradox or logical contradiction.
Time travel causes logical contradictions if you belive that the progression of time is rigidly forwardly linear and that there is a well defined, fixed cause and effect relationship between all causes and effects.
A different way of looking at the universe is that all of the particles in it, along with their motions, interactions, etc. form a gigantic system of equations. Within the bounds of the Heisenberg Uncertainty Principle, there exists the region of space-time states which solves this system of equations. You can think of this region as the "set of allowable time-lines," for lack of a better term. A given element of the set corresponds to one possible complete "existance of the Universe," which includes all time-space points of that Universe. Quite simply then, any time-line which would represent a logical inconsistency is outside of this set, because it is not a solution for the constraints of the system!
It is logical to presume that the proposed logical inconsistency simply would not happen, because it could not exist. That doesn't mean that time-travel is impossible; it means simply that it could never cause a logical inconsistency.
--Joe--
If SGI so desired, they could actually release a binary-only module which implements XFS (complete with GRIO (*drool*) if they really wanted to), and do so without GPL or anything that resembled an Open Source license. (Ick.) With that in mind, it stands to reason that a filesystem module could be distributed under any license, since it could be built separately from the kernel and modprobe'd in.
A different question is whether or not code that is part of the kernel source tree proper (eg. /usr/src/linux, also known as "everything in the linux-X.Y.ZZZ tarball") must be GPL'd, and I believe that said code does inherit the GPL from the rest of the kernel's GPL-ness. (Any license lawyers out there care to expound on this point for us?) If this is the case, then if SGI wants this to be part of the Linux kernel source tree, they'll have to jump on the GPL bandwagon.
I think "kernel patches", if they're distributed separately from the official kernel and must be applied manually by the users of the patch, are also exempt from being GPL'd, although this is a significantly greyer area. Kernel patches distributed in this fashion act very similarly to programs that #include GPL'd header files. eg. If I #include a GPL'd foo.h in my program, but I don't distribute my code with said foo.h, I don't believe my code becomes GPL'd -- even if foo.h is under GPL rather than LGPL -- although I'm not 100% certain. Anyone care to clarify on that particular grey area?
--Joe--
When I said about and approximate, I mean +/- a much smaller delta than a factor of three. eg. The speed of light in a vacuum is 3e8 m/s +/- 1e7 m/s (a far cry from saying its between 1e8 and 1e9). Same for the 9.5e15 (+/- 1e14). It's called significant figures.
The issue is that they used the exact same (incorrect) conversion for each place that they mentioned a light-year to kilometer conversion.
Now, on the other hand, if I were approximating with logarithms, and took an exponent (either that, or I looked at a slide rule with a severe astigmatism), I could expect a factor of 3 error very easily, because that's a linear error of only 0.5 in the log10 domain.
--Joe--
Actually, more like a factor of 1000.
--
When I took all of my science courses, I was taught that 1 light-year == the distance light travels in one year in a vacuum. In the article, they mention the following:
In other words, one billion light-years is 3e25 meters. Interpreting one billion as 1e9, this implies that one light year is 3e16 meters.
Now, if I recall correctly, the speed of light in a vacuum is approximately 3e8 meters/second. There are approximately 3.16e7 seconds in a year (365.24 * 24 * 60 * 60). Multiplying these together gives me a light-year of about 9.5e15.
So, is it just me, or are their light-years off by about a factor of 3?
--Joe--
Yeah, I used to tease my brother when he'd say "millihertz" (meaning megahertz, of course). Now, I'm going to his college graduation this weekend. Hopefully he learned something. ;-)
--Joe--
At the risk of sounding like a "Me Too!" loser, the same thing happened to me. In my case, Internet Junkbuster was clipping the cookies. (Netscape was still asking whether I wanted to accept the cookies, but IJB was keeping them from going out.)
--Joe--
At least we don't have lead plumbing for bringing us drinking water. :-)
(Of course, I can't pronounce half the ingredients in half my meals these days... Maybe I should start shopping at Whole Foods or something.)
--Joe--
I don't think so. They're a long-standing Usenet tradition. I'd hate to see all my favorite Usenet-isms go away in the World of the Web.
--Joe
--
The Apple ][ drives were pretty low density as well. I heard rumors that you could format and get at least 70K of usable space on the cardboard spacer that they put in the drive when they ship it.
--Joe--
According to the announcement, the presentation is for employees and their families. Are there any Fermilab people here that care to adopt me for a day? ;-)
--Joe--
Because new drivers may have a slightly different set of state transitions. Also, the state of the hardware may change while the kernel is being reloaded. (Think "masked interrupts".)
--Joe--
A defective Zip drive that's isolated from the CPU bus by a parallel port should not kernel panic the system. The Zip drive itself should simply not work, and not take the system down with it.
(It's a different story when you have defective hardware on either the CPU bus, or even on the SCSI chain, because it can affect the computer's ability to operate correctly at all. The parallel port, though, is a pretty effective means to isolate hardware from the rest of the system.)
--Joe--
$1 for the chalk, $49,999 for knowing where to mark.
--
And English isn't his native tongue. sigh Some people just don't understand the value of consistent, concise, mnemonic variable names.
--Joe
--
Is the service pack shrink wrapped? Oh, and how much does it cost?
--
From reading the other comments here, it seems that several readers agree that this book isn't truly necessary if you've already "been around the block", so to speak. That may be true.
However, I am still seriously considering getting this book so that when people ask me "what's a good book on programming", I can reach over to my shelf and grab a good book before they accidentally pick up the latest boat-anchor by some dubious author such as Herbert Schildt* or the like. All too often, people buy books based on size or weight, and not on the solidity of the content. (Even K&R2's latest reprinting is twice as thick as the one I bought, but with the same number of pages.)
If you're a good, professional coder in any reasonable organization, you will eventually be asked to mentor, tutor, or otherwise assist less-experienced programmers. Make sure you can make the best of the opportunity by having appropriate resources ready.
(*Note: I realize that my comments regarding Schildt might be slightly inflammatory to some, but they're not without some forethought. See the comp.lang.c FAQ for more information. And no, I don't let the FAQs think for me -- I've actually seen Schildt's work and found it atrocious. I reference the FAQ since it points out most of the same things I would and more.)
--Joe--