TV networks are about the easiest thing there is to government-control; it's both more efficient and more reliable to control the broadcaster. The Chinese gov't has also displayed a dismaying abundance of good sense when censoring their citizens' internet access: They filter the transmissions at well-chosen choke points, which is (again) efficient and reliable. The MS/RIAA route of controlling the individual computers/TVs is inefficient and unreliable, and it seems like they know it. I doubt they're interested in DRM-enabled TVs.
No...if you're joining two tables, and a column is NULL, then it doesn't match the join. NULL only would equal NULL. So in your example, only if a customer_pictures row had a NULL eventid and a transactions row had a NULL eventid would these be joined. They join because neither one is associated with any event.
Correct -- the given query will return every NULL-event picture if any selected transaction has a NULL event. Saying "only" and explaining why it happens doesn't make it right:-).
It's easy in this case to append 'and eventid != NULL' if you also want to filter these out.
If you're using NULL correctly, then you always want to filter these out, which is why the SQL semantics are what they are.
Hmm -- I've maintained SQL code for a few years at least, and my head's never exploded from the giant boolean contradiction that is NULL comparison semantics. Do you also hate IEEE NaN?
SQL isn't really code; this thing you say about throwing exceptions has no meaning within a "SELECT WHERE" statement. Returning FALSE is about the closest you get the throwing an exception in SQL; it's just sort of a "these aren't the droids you're looking for" answer, which is generally precisely what you want when you're dealing with a null row.
For example, I really wouldn't want "SELECT customer_pictures.imageblob FROM customer_pictures, transactions WHERE customer_pictures.eventid = transactions.eventid AND transactions.value > 10000 to return every picture that wasn't associated with an event for whatever reason (if there was a >$10000 transaction that wasn't associated with an event). The kind of problem you're talking about is only true if you're using NULL to mean something (in another post I mentioned using NULL in a userid column to mean "guest user", which is totally wrong and will cause problems, yes). If you use it to mean nothing, though, then the semantics you describe would be the ones that would cause problems, whereas the ones that actually exist are trouble-free.
(Yes, the example is wierd, but it gets my point across I think.)
Yes, that was in the post I replied to. I finally took a look at it, and I was right: it advocates something which is effectively special "null" rows, which it justifies by referring to a situation where multiple NULL values are meaningful. I'd handle the "salary" example with a combination of an enum and an integer (something like salary_type enum ('salaried', 'unemployed', 'unknown'), and salary_amount integer) -- that's informationally equivalent to what he proposes and a hell of a lot simpler. His solution is overengineered.
Most uses of NULL aren't even that complicated -- you'll just have something like an "end date" row, with NULL meaning that the thingy isn't ended yet. You might also have one general "what state is this in" enum (e.g. 'unstarted', 'started', 'ended', 'aborted') per row, and that defines which data is valid and which is NULL. In that case, what he proposes is way overengineered, with one state per variable and extra syntax and wierdness.
I agree that his criticisms are valid for the situation of using NULL as an actual value (like in a userid column to mean "guest user"). That'll get you in trouble sooner or later, but that's bad design anyway; teach the designer, don't fuck up the system.
While you're at it, check out this tripe (from the article):
The relational model is predicate logic applied to databases. Predicate logic is the real-world's two-valued logic (true/false)... logic guarantees correctness -- defined as consistency -- of query results. It is to preserve logical correctness, therefore, that Codd's Information Principle requires that all information in relational databases be represented as values in relations. The term "NULL values" suggests that Chamberlin does not realize that part of the problem with NULLs is that they are not values -- indeed, they are supposed to be markers for the absence of values. Whatever a database table with NULLs is, neither is it a relation, nor do NULLs represent anything in the real world and, consequently, correctness and the rest of the relational benefits are lost.
Incidentally, "inapplicable values" are a red herring. They are an artifact of bad database design. There is only one kind of missing value -- unknown -- and as I demonstrate in the above-mentioned chapter, it can be handled relationally, without the huge problems of SQL's NULLs.
I read this and pretty much gave up getting anything of value out of this article -- I hadn't understood much that went before it, though my distrust of all things XML had led me to believe this guy might know what he's talking about.
If you removed NULLs from relational database design, people would reinvent them (poorly) -- probably by using IDs of -1 or 0, or IDs to a special magic "null" row, which I suspect is what he's talking about by "it can be handled relationally." To suggest that missing or inapplicable values are not part of "the real world" is so wrong it's... well... wrong. Anyone who's actually done database work (or programming work, for that matter) knows this.
[chops@blenching/tmp]$ apt-get source pam Reading Package Lists... Done Building Dependency Tree... Done Need to get 536kB of source archives. Get:1 http://http.us.debian.org unstable/main pam 0.76-19 (dsc) [806B] Get:2 http://http.us.debian.org unstable/main pam 0.76-19 (tar) [425kB] Get:3 http://http.us.debian.org unstable/main pam 0.76-19 (diff) [111kB] Fetched 3B in 0s (69B/s) dpkg-source: extracting pam in pam-0.76 [chops@blenching/tmp]$ cd pam-0.76 [chops@blenching/tmp/pam-0.76]$ grep -ri 'sun.*micro'. ./Linux-PAM/doc/pam_appl.sgml:Thanks are also due to Sun Microsystems, especially to Vipin Samar and ./Linux-PAM/doc/pam_modules.sgml:Thanks are also due to Sun Microsystems, especially to Vipin Samar and ./Linux-PAM/doc/pam_source.sgml:Thanks are also due to Sun Microsystems, especially to Vipin Samar and ./Linux-PAM/doc/specs/rfc86.0.txt: Sun Environment", Sun Microsystems Technical Paper, [chops@blenching/tmp/pam-0.76]$
PAM was pretty much the same situation as Java -- Sun invented something good and released it under a non-free license, and the GNU/Linux people (in this case, it really was the Linux people specifically) reimplemented it. The full quote from that documentation is:
Thanks are also due to Sun Microsystems, especially to Vipin Samar and Charlie Lai for their advice. At an early stage in the development of Linux-PAM, Sun graciously made the documentation for their implementation of PAM available. This act greatly accelerated the development of Linux-PAM.
GNU tar is not the same as standard UNIX tar (i.e., UNIX tar is missing the -z switch in your case) as another reader has pointed out. You should know that before complaining.
Right, and some people find the standard Unix tools so incomplete and irritating that at least one Solaris admin I know installs GNU tools on his Solaris machines so he'll have a workable environment. This guy got his start on UNIX, and he likes GNU's tools better because they're more featureful (among other reasons). I've heard this is fairly common, and one out of two real UNIX admins I know personally does it.
I was interested in SFU specifically for its properties as a GNU/Linux-like environment; if it's lacking features I expect from that environment, I really don't care whether the explanation is "That's the historical behavior of a system you've never used" or "We felt like getting high that day, and didn't implement it."
Additionally, defaulting to/dev/rmt8 instead of stdin, on a system that doesn't have/dev/rmt8, is simply a bug IMO, regardless of the historical behavior.
This message is bitter enough to look like a flame, but really it isn't; you should imagine:-)s sprinkled liberally among it until it looks like I'm more tolerant of non-GNU cultures than I really am.
SFY 3.5 is a deficient product, and probably made so.
I'll second that. I installed SFU to try it out, and found it to be so bad as to be endlessly entertaining. The high points of my interaction with it were this (the first line indicates my discovery that tab completion didn't work):
$ tar xfz../mutt usage: tar -{txru}[cevfbmopwBHLPX014578] [tapefile] [blocksize] file1 file2... $ tar xfz../mutt* usage: tar -{txru}[cevfbmopwBHLPX014578] [tapefile] [blocksize] file1 file2... $ zcat../mutt* | tar x tar: Failed open to read on/dev/rmt8: No such file or directory zcat:../mutt-1.4.1i.tar.gz.Z: No such file or directory $ cd.. $ gunzip mutt* $ cd src $ tar xf../mutt*
... and the time I typed
vi `which startx`
... only to have vi attempt to open
C:\SFU\X11R6\bin\startx^M
... which, as you might guess, didn't work (it choked both on the C:\ and the ^M).
Good times, good times. Also it broke cygwin's emacs-style line editing (presumably by changing some terminal-related DLL) and WinCVS (by setting EDITOR=vi systemwide). Fortunately both of these problems went away when I uninstalled it.
Get in trouble. Long, laborious litigation. What was solved? Nothing. Consumers don't have more rights. It's still a pain in the ass to decode DVDs, and now he's on a bunch of corporate sharks' bad sides.
Maybe he just has the courage of his convictions. Certainly I think that both DeCSS and this should be legal, I just don't have the skills to make them, the time or inclination to try, or the stones to do it knowing I'll get shit on for it.
Good for him.
Let's see, which of the following choices would've had the best effect:
* Immediately releasing a hack just after litigation. * Releasing it anonymously. * Waiting until the temperature settled, then quietly sneaking this past Apple and opening a bunch of doors in the process.
I vote the last one.
Are you kidding? He's telling these cocksuckers that he's not afraid of them. No given DRM scheme will last forever, which is why the fear of breaking the ??AA's expensive new laws is what they're mainly counting on. Seems to me he's got quite a good handle on what the best effect is.
Just a reminder from your friendly neighborhood armchair political scientist: "Both sides are wrong, both sides have blood on their hands, everyone's about equally guilty," is sometimes just as much a cop-out as "they did it, it's all them, we're a bunch of boy scouts, yer honor."
Personally, I believe that this particular case of middle-eastern mutual slaughter is a case of one party which is massively in the wrong, and one party which is only a little bit in the wrong. I'm not saying which is which; that's not really relevant to what I'm saying, which is:
It is better to look at the facts and opinions and dig out the truth, or your version of it, than to go by an interpretation because it's "fair" or "in the middle." Sometimes, the factual situation isn't "fair" or symmetrical, which means a "fair" description is a filthy lie. The SCO situation, and the damn weasel analysts who take a weighted average of the SCO press releases and groklaw to get the truth, are a good example of this.
(I haven't even read the grandparent; please don't assume I'm defending it against the parent and decide my beliefs accordingly.)
So my understanding of the state of the art, as understood by real UI people, is that windows should tile on the screen instead of overlapping. If your windows don't all fit on the screen, you need a new screen.
This is the way I do it: Have 9 virtual screens (natively in GNU/Linux or via Altdesk on Windows), with each screen bound to one of the keys in the 3x3 square defined by Q-E-C-Z (Ctrl-Shift-q for screen 1, C-S-e for screen 3, C-S-a for screen 4, etc.)
Rows are for machines: Q-W-E is the local machine, Z-X-C is shells and windows on my home machine, A-S-D is shells and windows on other machines. Columns are applications: Q-A-Z is random shells and small applications, W-S-X is full-screen apps (e.g. web browser & email client), E-D-C is programming (Studio or emacs + shells depending).
I've found that hitting C-S-whatever becomes pretty much automatic when I want to get to a particular app; there are a couple of overlaps (sometimes I'll have email and web both open at home, so I'll have to say C-S-x then click in the taskbar), but on the whole I can juggle quite a few programs without ever having to hunt through the taskbar.
Just for the same reason why my brand new Linux box has a "nobody" account. Which, admittedly, cannot log on.
This is wrong -- the 'nobody' account is horribly misnamed. It's just a regular account like any other, which means that if (for example) you've got httpd and ftpd both running as 'nobody', then anyone who cracks your web server can also muck with your ftp server, and vice versa.
Basically, you should never use "nobody" for anything; create individual unpriveleged users for each service you're trying to quarantine (ftpguest, smbguest, etc.)
Re:Comments on today's SCO conference call
on
SCO News Roundup
·
· Score: 2, Interesting
(Yes, I know, I'm replying to a Groklaw comment via Slashdot. Well, Slashdot is where I saw it.)
3. I wanted Boies to explain how the USL v. BSDI lawsuit gave them any legal standing. It doesn't, and seems to weaken it (IANAL).
There's this bit from the article header (also on Groklaw):
Catch that? ". ..our UNIX System V source code and our copyrights that were reaffirmed as a result of the BSDI settlement agreement." "without authorization or appropriate copyright notices".
... indicating that they may plan on arguing that some of the BSD-licensed code in SysV is "theirs", and that if it's included in Linux without proper attribution (which isn't entirely implausible) then they deserve damages. This isn't entirely valid (especially now that SGI has removed any duplication, infringing or not, between SysV and Linux), but it's better than what they have currently, which as far as I can tell is... well... nothing.
I use a net-connected Linux machine that offers several non-trivial public services. Its uptime currently stands at a bit over 400 days.
You should schedule some downtime for that machine. If you don't cold-boot your machines periodically (once a year is a good rule of thumb), you may find after the next power outage that they don't boot anymore (generally because a dying disk is willing to continue to spin long after it's decided never to spin up again).
Once I noticed that an acquaintance of mine's Win2k machine had no password on the "Administrator" account. I began to lecture him on the dangers of SMB, C$, and such, and the fact that his machine was basically freely usable by anyone who had (a) the internet and (b) some semblance of clue and maliciousness.
He laughed and said, "Yeah, but who would think that the administrator account wouldn't have a password?"
This is an LKML FAQ. The short answer is, "Yes, it would be cool, but it's much harder than you think. We're busy doing kernel code; you're welcome to do it yourself if you wish. People would thank you profusely."
Firstly, why two seperate lists? are they saying there are as many unix security violations and windows? I wonder what colour the sky is in their world.
Probably, they're trying to avoid touching off exactly this sort of religious flaming... maybe they judge that "mine is bigger than yours" is a poor addition to any discussion of security, even if (or maybe even especially if) there is some discernible difference in size between the... er.. security records in question.
Windows's poor security track record is irrelevant to the approach a skilled Unix admin needs to take to securing a network, and vice versa.
FWIW, the discussion of (lack of) ARM merging in 2.6 can be found (in summarized form) here. Linus is quoted therein:
I don't think it's a failure. Why _should_ one tree have to try to make everybody happy? We want to try to make it easier to keep the couplings in place by striving for portable infrastructure etc, but we would only be hampered by a philosophy that says "everything has to work in tree X", since that just means that you can't afford to break things.
I'd much rather keep the freedom to break stuff, and have many separate trees that break _different_ things, and let them all co-exist in a friendly rivalry.
I've got it figured out. SCO is trying to throw out so many baseless accusitions, and fill the air with so much nonesense, that we simply become numb, unable to deal with it, or respond in a coherent manner.
This is actually a viable arguing strategy if the point you're arguing is wholly wrong. If you say things that are wrongly based, confusing, or self-contradictory, you raise the bar for people unfamiliar with the reality of the situation to make sense of it. People who understand the SCO situation, or are willing to take half an hour to examine it, are going to think SCO's full of shit in any case; that's not who this is aimed at.
I've read many comments here and in other forums complaining about clients and bosses citing the SCO mess as a reason to put off Linux implementations/rollouts/development. All one needs to do is look through all the SCO articles posted in the past month or so.
I guess that goes to show you - 56.2% of all statistics are untrue.
You're missing the point. It's annoying to have to constantly remember to refer to "GNU/Linux" because fanatics jump on you for not "giving respect" and for "spreading this lie."
These things you put in quotes are true descriptions of the situation. If being corrected about them annoys you, perhaps you should start making correct statements:-).
Linux is running all my drivers, talking to all my hardware, managing my memory and my processes. It is controlling my computer as an operational system.
Yep, that's what a kernel does.
I choose to use Linux. It just so happens GNU tools are included on the distros I use, but I'm not choosing to use Linux for those GNU tools, I'm choosing to use it for the kernel, its hardware support, and so forth. If all of GNU was replaced, I'd still be using that Linux kernel. That's the difference, my motivation for using it.
Okay, this sounds like pure cognitive dissonance. You're so fond of iptables and/proc that you're accepting bash, Gnome, printf, and all the other extraneous GNU "tools" that you're forced to install as well?
When Linux started out, the goal was to build a hobbyist OS. Linus used to ship a C library, shell, and most of the other parts of a real and complete OS. People started getting sick of the duplication of effort, though, and one by one replaced the non-kernel parts with their GNU equivalents (or just used them in the first place), until now we have a system which is mixed GNU and Linux, with GNU predominating. Because of this bizarre history, though, it's still called "Linux," and the old references to "Linux the OS" are still in use, even though they're no longer accurate.
I used to be aware of this and not care; after hearing some of the distortions, irrelevancies, and outright falsehoods ("Gnome is not part of GNU") that people come up with to explain why the GNU people don't deserve much credit for "Linux," I've decided that RMS is right and calling the OS "Linux" is misleading.
You guys are like religious fundies, I swear. Loosen up. I can already hear your responses now.
I'm sorry you feel that way. It seems to annoy some people even to mention GNU (I'm not sure why), but this stuff about "Linux" being mostly GNU is actually true.
Heh -- it happens that I use non-GNU versions of some things you mention (zsh & blackbox), and I share your dim view of info for standard commands (though stuff like 'info mysql' rocks) and the GNU "all things can be done with a long enough --option" philosophy. I seek merely to educate those misguided folk who aren't aware how much of the software they're currently running was written by the FSF.
Speaking of which, you still need to clear out that pesky C library. I wonder if Linux libc is still available...:-)
Hmm... a look through the "required" packages installed on my Debian system shows this from BSD:
bsdutils (logger, renice, replay, script, and wall)
Berkeley DB (1, 2, and 3)
... this from Linux:
e2fsprogs
hostname
PAM
makedev
mbr
modutils
mount
procps
util-linux (fdisk, mkswap, dmesg, etc.)
libblkid1
libcap1
... and this from GNU:
bash
coreutils (ls, rmdir, etc.)
diff
findutils (find & locate)
grep
gzip
libc6 & libstdc++
sed
tar
I ignored Debian-specific stuff (init scripts, dpkg, etc.) Most of the Linux stuff consists of small packages tightly bound to the kernel, whereas the GNU stuff is pretty much a list of "what Unix is." The stuff up above the real core OS is indeed mostly a hodgepodge of different projects, yes.
Slashdot Mirror
TV networks are about the easiest thing there is to government-control; it's both more efficient and more reliable to control the broadcaster. The Chinese gov't has also displayed a dismaying abundance of good sense when censoring their citizens' internet access: They filter the transmissions at well-chosen choke points, which is (again) efficient and reliable. The MS/RIAA route of controlling the individual computers/TVs is inefficient and unreliable, and it seems like they know it. I doubt they're interested in DRM-enabled TVs.
Correct -- the given query will return every NULL-event picture if any selected transaction has a NULL event. Saying "only" and explaining why it happens doesn't make it right
If you're using NULL correctly, then you always want to filter these out, which is why the SQL semantics are what they are.
Hmm -- I've maintained SQL code for a few years at least, and my head's never exploded from the giant boolean contradiction that is NULL comparison semantics. Do you also hate IEEE NaN?
SQL isn't really code; this thing you say about throwing exceptions has no meaning within a "SELECT WHERE" statement. Returning FALSE is about the closest you get the throwing an exception in SQL; it's just sort of a "these aren't the droids you're looking for" answer, which is generally precisely what you want when you're dealing with a null row.
For example, I really wouldn't want "SELECT customer_pictures.imageblob FROM customer_pictures, transactions WHERE customer_pictures.eventid = transactions.eventid AND transactions.value > 10000 to return every picture that wasn't associated with an event for whatever reason (if there was a >$10000 transaction that wasn't associated with an event). The kind of problem you're talking about is only true if you're using NULL to mean something (in another post I mentioned using NULL in a userid column to mean "guest user", which is totally wrong and will cause problems, yes). If you use it to mean nothing, though, then the semantics you describe would be the ones that would cause problems, whereas the ones that actually exist are trouble-free.
(Yes, the example is wierd, but it gets my point across I think.)
Yes, that was in the post I replied to. I finally took a look at it, and I was right: it advocates something which is effectively special "null" rows, which it justifies by referring to a situation where multiple NULL values are meaningful. I'd handle the "salary" example with a combination of an enum and an integer (something like salary_type enum ('salaried', 'unemployed', 'unknown'), and salary_amount integer) -- that's informationally equivalent to what he proposes and a hell of a lot simpler. His solution is overengineered.
Most uses of NULL aren't even that complicated -- you'll just have something like an "end date" row, with NULL meaning that the thingy isn't ended yet. You might also have one general "what state is this in" enum (e.g. 'unstarted', 'started', 'ended', 'aborted') per row, and that defines which data is valid and which is NULL. In that case, what he proposes is way overengineered, with one state per variable and extra syntax and wierdness.
I agree that his criticisms are valid for the situation of using NULL as an actual value (like in a userid column to mean "guest user"). That'll get you in trouble sooner or later, but that's bad design anyway; teach the designer, don't fuck up the system.
I read this and pretty much gave up getting anything of value out of this article -- I hadn't understood much that went before it, though my distrust of all things XML had led me to believe this guy might know what he's talking about.
If you removed NULLs from relational database design, people would reinvent them (poorly) -- probably by using IDs of -1 or 0, or IDs to a special magic "null" row, which I suspect is what he's talking about by "it can be handled relationally." To suggest that missing or inapplicable values are not part of "the real world" is so wrong it's... well... wrong. Anyone who's actually done database work (or programming work, for that matter) knows this.
Tee hee.
Right, and some people find the standard Unix tools so incomplete and irritating that at least one Solaris admin I know installs GNU tools on his Solaris machines so he'll have a workable environment. This guy got his start on UNIX, and he likes GNU's tools better because they're more featureful (among other reasons). I've heard this is fairly common, and one out of two real UNIX admins I know personally does it.
I was interested in SFU specifically for its properties as a GNU/Linux-like environment; if it's lacking features I expect from that environment, I really don't care whether the explanation is "That's the historical behavior of a system you've never used" or "We felt like getting high that day, and didn't implement it."
Additionally, defaulting to
This message is bitter enough to look like a flame, but really it isn't; you should imagine
I'll second that. I installed SFU to try it out, and found it to be so bad as to be endlessly entertaining. The high points of my interaction with it were this (the first line indicates my discovery that tab completion didn't work):... and the time I typed
Good times, good times. Also it broke cygwin's emacs-style line editing (presumably by changing some terminal-related DLL) and WinCVS (by setting EDITOR=vi systemwide). Fortunately both of these problems went away when I uninstalled it.
Maybe he just has the courage of his convictions. Certainly I think that both DeCSS and this should be legal, I just don't have the skills to make them, the time or inclination to try, or the stones to do it knowing I'll get shit on for it.
Good for him.
Are you kidding? He's telling these cocksuckers that he's not afraid of them. No given DRM scheme will last forever, which is why the fear of breaking the ??AA's expensive new laws is what they're mainly counting on. Seems to me he's got quite a good handle on what the best effect is.
Why did you put freedom in quotes like that?
Just a reminder from your friendly neighborhood armchair political scientist: "Both sides are wrong, both sides have blood on their hands, everyone's about equally guilty," is sometimes just as much a cop-out as "they did it, it's all them, we're a bunch of boy scouts, yer honor."
Personally, I believe that this particular case of middle-eastern mutual slaughter is a case of one party which is massively in the wrong, and one party which is only a little bit in the wrong. I'm not saying which is which; that's not really relevant to what I'm saying, which is:
It is better to look at the facts and opinions and dig out the truth, or your version of it, than to go by an interpretation because it's "fair" or "in the middle." Sometimes, the factual situation isn't "fair" or symmetrical, which means a "fair" description is a filthy lie. The SCO situation, and the damn weasel analysts who take a weighted average of the SCO press releases and groklaw to get the truth, are a good example of this.
(I haven't even read the grandparent; please don't assume I'm defending it against the parent and decide my beliefs accordingly.)
So my understanding of the state of the art, as understood by real UI people, is that windows should tile on the screen instead of overlapping. If your windows don't all fit on the screen, you need a new screen.
This is the way I do it: Have 9 virtual screens (natively in GNU/Linux or via Altdesk on Windows), with each screen bound to one of the keys in the 3x3 square defined by Q-E-C-Z (Ctrl-Shift-q for screen 1, C-S-e for screen 3, C-S-a for screen 4, etc.)
Rows are for machines: Q-W-E is the local machine, Z-X-C is shells and windows on my home machine, A-S-D is shells and windows on other machines. Columns are applications: Q-A-Z is random shells and small applications, W-S-X is full-screen apps (e.g. web browser & email client), E-D-C is programming (Studio or emacs + shells depending).
I've found that hitting C-S-whatever becomes pretty much automatic when I want to get to a particular app; there are a couple of overlaps (sometimes I'll have email and web both open at home, so I'll have to say C-S-x then click in the taskbar), but on the whole I can juggle quite a few programs without ever having to hunt through the taskbar.
This is wrong -- the 'nobody' account is horribly misnamed. It's just a regular account like any other, which means that if (for example) you've got httpd and ftpd both running as 'nobody', then anyone who cracks your web server can also muck with your ftp server, and vice versa.
Basically, you should never use "nobody" for anything; create individual unpriveleged users for each service you're trying to quarantine (ftpguest, smbguest, etc.)
There's this bit from the article header (also on Groklaw):
You should schedule some downtime for that machine. If you don't cold-boot your machines periodically (once a year is a good rule of thumb), you may find after the next power outage that they don't boot anymore (generally because a dying disk is willing to continue to spin long after it's decided never to spin up again).
Once I noticed that an acquaintance of mine's Win2k machine had no password on the "Administrator" account. I began to lecture him on the dangers of SMB, C$, and such, and the fact that his machine was basically freely usable by anyone who had (a) the internet and (b) some semblance of clue and maliciousness.
He laughed and said, "Yeah, but who would think that the administrator account wouldn't have a password?"
I gave up and said no more.
This is an LKML FAQ. The short answer is, "Yes, it would be cool, but it's much harder than you think. We're busy doing kernel code; you're welcome to do it yourself if you wish. People would thank you profusely."
Probably, they're trying to avoid touching off exactly this sort of religious flaming... maybe they judge that "mine is bigger than yours" is a poor addition to any discussion of security, even if (or maybe even especially if) there is some discernible difference in size between the... er.. security records in question.
Windows's poor security track record is irrelevant to the approach a skilled Unix admin needs to take to securing a network, and vice versa.
Don't forget another classic: reprint the last two weeks' worth of logs, minus the part where the machine's broken into.
This is actually a viable arguing strategy if the point you're arguing is wholly wrong. If you say things that are wrongly based, confusing, or self-contradictory, you raise the bar for people unfamiliar with the reality of the situation to make sense of it. People who understand the SCO situation, or are willing to take half an hour to examine it, are going to think SCO's full of shit in any case; that's not who this is aimed at.
Okay, this sounds like pure cognitive dissonance. You're so fond of iptables and /proc that you're accepting bash, Gnome, printf, and all the other extraneous GNU "tools" that you're forced to install as well?
When Linux started out, the goal was to build a hobbyist OS. Linus used to ship a C library, shell, and most of the other parts of a real and complete OS. People started getting sick of the duplication of effort, though, and one by one replaced the non-kernel parts with their GNU equivalents (or just used them in the first place), until now we have a system which is mixed GNU and Linux, with GNU predominating. Because of this bizarre history, though, it's still called "Linux," and the old references to "Linux the OS" are still in use, even though they're no longer accurate.
I used to be aware of this and not care; after hearing some of the distortions, irrelevancies, and outright falsehoods ("Gnome is not part of GNU") that people come up with to explain why the GNU people don't deserve much credit for "Linux," I've decided that RMS is right and calling the OS "Linux" is misleading.
I'm sorry you feel that way. It seems to annoy some people even to mention GNU (I'm not sure why), but this stuff about "Linux" being mostly GNU is actually true.Heh -- it happens that I use non-GNU versions of some things you mention (zsh & blackbox), and I share your dim view of info for standard commands (though stuff like 'info mysql' rocks) and the GNU "all things can be done with a long enough --option" philosophy. I seek merely to educate those misguided folk who aren't aware how much of the software they're currently running was written by the FSF.
:-)
Speaking of which, you still need to clear out that pesky C library. I wonder if Linux libc is still available...
I ignored Debian-specific stuff (init scripts, dpkg, etc.) Most of the Linux stuff consists of small packages tightly bound to the kernel, whereas the GNU stuff is pretty much a list of "what Unix is." The stuff up above the real core OS is indeed mostly a hodgepodge of different projects, yes.