"We are at war with System V, we have always have been at war with System V" - George Orwell, paraphrased from 1984.

Selected quotes from the online Perl manual:[0]

$ man peripc
...
sub REAPER {
$waitedpid = wait;
# loathe sysV: it makes us not only reinstate
# the handler, but place it after the wait
...
$SIG{CHLD} = \ # still loathe sysV
...

In the beginning ...
Ken Thompson[1] had a wonderful flash of brilliance, "if I fully swap out a process, change the in-core process id in the kernel structures of the in-core copy, then I have implemented a new process function with only a handful of lines of code". Thus was fork(2) born.

Unix and its descendants have always had the philosophy that process creation should be and is cheap, and it certainly is compared to its competitors. But the main primitive, fork(2) did not scale up too well. What works on a PDP 11/70 may not work so well on a VAX.

Basing the idea that fork(2) is nearly always followed by exec(2), which essentially throws away the entire state of the child process, the inherently sinful vfork(2) was born in Berkeley in a predecessor O/S that not inappropriately uses a demon as its mascot.

vfork(2) got away with being, much, much faster than traditional fork(2) by doing away with much of the copying of process state that fork(2) does. The major drawback is that the child process shares full virtual memory state with the parent. Extremely careful programming was required if one was using the nominally faster vfork(2) over fork(2).

Consider it the predecessor of threads programming on Unix without any of the forethought of modern threads libraries.

For many years, Linus resisted introducing vfork into Linux. Linus being Linus, it was usually, "I'm not about to put that kind of crap into my kernel." Sometime after 2.0, I think in the 2.1 time frame, the VM in Linux had firmed up enough that he could implement a decent vfork using COW (copy on write) for shared writable pages, and thus vfork(2) entered the Linux kernel, *safely*[2].

The mindset that most of us guys who value engineering principles have is that much of the "innovation" brought forward by the BSD guys was a cheap hack. That includes /bin/csh which is perhaps the worst engineered language ever and has caused untold cost in damages to developers writing interactive programs (like Emacs) because users ended up being recommended to put interactive `stty's in their ~/.cshrc that would always execute and puke if sub shells were being invoked from a containing program without a control terminal.

The worst aspects of System V are gone. Sadly, the worst aspects of BSD 2 and BSD 4.x appear that they will live forever.

[0] I hate the way formatting works differently here and sucks harder than in regular mode.

[1] May peace and blessings be upon him.

[2] It did not last long as an independent system call and was fairly quickly replaced with clone(2) that is primitive to both fork(2) and vfork(2).

I received the following SPAMmy email that somehow made it through all the SPAM filters between my email box and me. The questions are interesting enough so I will take the time to answer them here, but I never respond in kind to unsolicited email of this sort.

Sorry. I am never going to trust email sent from a gmail address and claiming to be originating in Hong Kong, even if it is only the next island away.

I find it entertaining and sometimes insightful. I have found it most useful in training my bullshit filter in order to obtain reliable information from unreliable sources.

There was a better sense of community in FreeRepublic.com, but only for the True Believers. As that community drifted towards neoconservatism and continued to blast the so-called "fringe" supporters such as libertarians, I drifted away from it.

Technologically speaking, the software on FreeRepublic wins hands down over the software on Slashdot.

The software driving Slashdot is irritating much of the time, but often does not get in the way of enjoying discussions. Of recent concern, it used to be easy to mostly write free text (in a message like this) with an occasional HTML tag, but they are deprecating that. It used to be easy to read article titles before clicking on an article to read, but they deprecating that as well in favor of an unreadable color scheme.

I am a "disciple" of uber cypherpunk Timothy May and believe most strongly in the principle of - if you do not like the quality of discussion, contribute higher quality discussion yourself.

Of sites worthy of spending time on, as this one (including FreeRepublic) the value of the discussion is at least 10:1 over the value of the actual articles.

I've wasted too much time editing stupid HTML tags that I would not have been forced to insert in the default editing mode. Begone!

Interesting in how a post that includes a broad sweeping generalization that more or less reads Microsoft Windows has so litle value, they have to pay people to get their first fix and an observation that my spouse learned to hate it because of its instability gets turned into "says M$ sucks because Emacs sucks."

I've been using Emacs (and forks like Epoch and XEmacs) for longer than many of you have been alive. And Earth to twitter (via his mother or someone else who will read this to him), I'm not about to stop. Ever.

The full thread is around a flame directed at twitter.

See: http://wcbstv.com/national/Jury.Finds.Goof.2.849689.html

The pertinent bit in there is:

So let's see, we prohibit felons (most of them convicted on recreational drug charges) from even voting, ever again in their lives, but one can withstand a felony conviction and be voted into and/or remain in the Senate?

Sigh.

I am neither Republican nor Democrat so I'll add that Barney Frank and Chris Dodd can loot the country for billions of dollars and not so much as face a trial.

The Republic is doomed. (I did not know that bit about convicted felons being allowed to hold office, but not to vote).

Microsoft is to blame for the malware explosion and here's why.

I wrote the following[edited for context] in response to someone who was attempting to blame "the idiot behind the keyboard":
Offering to execute pieces of email should never have been an option, let alone an unprompted default. Offering a prompt is a total misunderstanding of the real issue.

I can't think of an appropriate car analogy, so how about a rake analogy? Prompting before executing a file received in email is like attaching a notice to a rake laying on the ground with the tines facing up that reads, "if you step on this rake you could do serious damage to your face, proceed?" That is intended to sound dumb because it is every bit as dumb as executing things received via email.

There were good solid reasons why shar messages were distrusted and so somebody wrote unshar so one could unpack such things without executing it directly in the Unix shell. This was all standard industry knowledge about a decade before the release of Microsoft Windows 95.

Only idiots execute code received in email, but only an interface done by worse idiots gives them that option. Microsoft popularized the misfeature and made it a feature that some people cannot live without. It should never been a feature in the first place. And for that, you most certainly can lay blame to the management chain at Microsoft that signed off on the idea. The US tobacco industry was successfully sued for billions over much less.

I'll go after the creeping evil Javascript in a future journal entry, never fear.

I wish to document a statement I made in good faith, but perhaps without sufficient information and provide clarification that I am not trolling.

My intention at this time, is to gain information as to whether Apple resellers are selling tainted product in Asia, or someone is tainting their product in Asia, or I am just an idiot and hit the wrong key somewhere. I've been a Unix user at home for over two decades and so I was shocked when I clicked a button on a login screen to see my password displayed.

I originally wrote:

This comment was based on direct experience and apparently unique to me. So, after being pounded over the head with a clue hammer, I wrote the following:

I posted the summary because as I was googling for other pages that might have been appropriate to my query, I found Slashdot. It is only fair to Apple that I attempt to rectify the situation. I have no wish to harm Apple. As an Open Source programmer from way back, when I see something go wrong in software, I want to fix it. In Linux, I can, but not in OS X. So, I'll provide as much information as I can so that if I have run across some wierd corner case, they can fix it.

Since that was posted, I remembered two other things I should have mentioned:

The account in question was created in 10.4 at the first system boot.

I used a program downloaded from apple.com called OnyX to clear caches in order to get the machine to boot out of Safe Mode when the bad airport driver was insmod'ed at boot. This might be an artifact of the 10.4 -> 10.5 upgrade.

I offer my apologies to Apple if this was something one off due to impending mother board failure or something like that. And if someone in Asia is selling tainted 10.5 CDs, maybe they would like to know about that.

I wrote this entry in a recent article:

And now, I want to expand on it.

The Blue and Green books, which were published around 1980, were critical for the success of Unix. They documented every system call, every library call and did not leave anything out. This was the true start of Open Systems. No longer would you have to have huge support contracts with your O/S/Equipment manufacturers to figure out how to do things[1]. This was underscored by the fact that the crucial user interface to the system that every user had to endure, /bin/sh was just an ordinary program and many people who were unsatisified could and did (/bin/csh being the first) reimplement it.

* Open Interface, interchangable parts.

Unix has long been criticized for its cryptic commands. Well, it was until certain people decided the command line had gone out of fashion. The small, but numerous included commands with Unix emphasized a philosophy of Small is Beautiful and Do One Thing and Do it Well. While maybe being difficult to remember at first (but the Blue Book had all the manpages in nice, removable and 3-hole punched pages), were easy to type. But, let's face it, whether you are working at a 110 baud hardcopy teletype, or an Xterm, it's easier to type `ls' than `directory' or something like that. Later advances in Unix shell technology made that rather moot with user-defined aliases and bound function keys as in zsh. The point to remember is that the later advances were enabled by the fact that /bin/sh, wonderful innovation that it was at the time, was an interchangeable part.

The original Unix guys were proud of the pipeline, and indeed, it is a useful concept, but I doubt many folks today take much use of it. Programs like Richard Stallman's Emacs, XEmacs, Expect handle most of the complicated cases in greatest usage today and the rest are things like <some command that will produce a lot of output> | less.

As multicore systems become prevalent, we may see someone take advantage of that to make really wonderful pipelines possible, I'm not optimistic. But hey, I'll be happy to hack at zsh, with all of its wonderful pipeline primitive extensions if someone throws money at me, but on second thought, I'd rather the zsh guys be the target (of the money).

* Flexible design methodology.

Unix has been multiuser since the very beginnning. Well, after they got the bugs out that caused people to shout "a.out" when they were running programs they had just compiled. For historical perspective, the original PDPs had similar amounts of memory as the first IBM PCs. Separated I & D space (for a whopping 128k of address space) was a huge win in the days.

* Multiuser/multiprocessing because no one needs to be administrator on a computer to use it and no one does just one thing at a time.

The Unix file system has simplicity at its core. Files are just files and handled as a stream of data. Encoding a file's purpose as part of the file name or as metadata had been the norm and Unix broke that. RMS was the complete opposite and older folks remember the shelves of bookcase space VMS programmers routinely kept near by filled with programming manuals. Open, read, write, close. It doesn't get any simpler than that.

* Files are just files[2].

Over the years, kruft has crept in, as it will with any going[3] software project but not enough to invalidate what Ken & Dennis started almost 4 decades ago. Certainly the lack of an rmdir(2) system call was an oversight[4], but not a crippling one. My number one criticism of Unix is the short-sightedness of using only 32 bit signed integers for time computation that make the End Of The World coming around January 17, 2037. Fortunately, modern Unix-derivatives use 64 bit time and I guarantee you, many of the ones you see today will still be in use 3 decades from now.

Unix. Live Free, or die.

Footnotes:
[1] I am pointing the finger at the former Digital Equipment Corporation here. In the mid 1980s, I was employed at one of the first 100 .coms with all the associated huge defense contracts of the time, and was trying to code for myself a feature that was in one of the DEC supplied standard VMS utilities. I could not make it behave the same way as the DEC program. I spent many hours trouble shooting the problem, many hours on the phone with a DEC consultant who claimed to be reading the source of the program that implemented the feature I was trying to implement, but no luck. Just Say No! to undocumented interfaces.

[2] Yes, at times I have read mail with cat(1).

[3] As in "going concern" an accounting term referring to businesses with a future.

[4] Which causes the command `/bin/rm -rf /' run as root to fail after removing the /bin/rmdir program (do not try that at home unless you know what you are doing).