Let me see. I started using Slackware back in '94. I remember spending whole saturdays switching floppies and praying that none of them had read errors. So that makes more than 15 years of continuous use of Slackware both at home, and in a production environment (for one of the top 20 software company in the world, mind you). I think you can keep your lame patronizing to yourself kiddo, coz it just came around to take a bite right up your ass...

As to more important things to do than spend the 5 minutes it takes to build an initrd in Slack (which is not necessary 95% of the time), I guess that reading explicit readmes and actually experiment with the stuff in order to provide knowledgeable advice is not one of them...

I think the statement about the generic kernel only refers to installation on nonstandard drives (eg. dmraid with various fakeRAIDs). If you stay in the realm of /dev/hd# /dev/sd# and common controllers interfaces like Compaq Smart Array for instance, you won't need an initrd to boot your kernel.

And if you find the Slackware way (which, IMO is the most generic approach) cumbersome, pray explain how to boot an nVidia MediaShield fakeRAID RAID5 partition without an initrd for instance, as I would be very interested to hear it. I recently had to do the latter, and I found that using initrd with good old Slack was a breeze, since Slackware leaves everything you need at your fingertips, along with a *detailed* README of how to do it. Didn't even have to google to figure out how to craft an initrd.

That's the problem I have with userland based solutions. They require precognition-like ability so that you setup the scripts/cron jobs that will save your life in advance. Unfortunately, when you go around a large number of systems, or, as I mentionned above, use an application UI rather than the commandline for file manipulation, this kind of "I'll do some additional work against the very rare case where I really might need to undelete a file" doesn't really cut it (did I mention I was also lazy?)
What I am saying is, a crude undelete is so simple to implement at the FS level, it should be a part of any modern filesystem, so that lazy bums like myself can get it at the flick of a switch when creating a new FS (mkfs --allow-undelete ...).
But don't worry: I never blame anybody but myself when I inadvertently delete something (which hasn't happened that often, fortunately). I'm just annoyed that, as far as the end user is concerned, some of the native capabilities of filesystems seem to have regressed in the past 20 years. 20 years ago, I could easily undelete a file on my favorite O/S. Today I cannot...

You, sir, hit the nail on the head.
That would be my preferred solution as well, but then it needs to be implemented in the FS, and all the discussions I've seen on recent and future filesystems tend to indicate that the developers see little value in adding that kind of undelete future ("not worth it", "too complex", "undelete belongs in userspace"...), which brings us back to the original point...

Alright, I'll bite some more:

The "don't be careless" position would be fine, but it's akin to never making any mistake, which, considering the amount of background cursing noise experienced in any IT profession, is the exception rather than the rule. If you've never been careless when working with computers then kudos to you, but I don't think that's the general rule. Oh, and I don't think I mentionned using rm as root (but of course, you want to be root to umount the filesystem and revent further writes after you realized your mistake).
For the sake of what follows, let's consider that I, stupidly or not, as a non root user, innadvertently deleted that 10 GB worth of irreplaceable data I just generated (eg that 10 GB HD video file of an UFO landing on my front lawn). This was my only copy. Now let's consider the options:

- 'rm' alias, a.k.a. as the Windows-like trashcan: That solution would be fine if I didn't (usually) want to have that file space freed straight away. If I remvove a 10 GB file from my system, I want 10 GB more disk space available => not the best option. Plus what if that file just got deleted from an UI (eg. the video editing app I was using under X) rather than from an 'rm' command. Also defuses the careless argument with "what if I am the most careful person in the world, but I am using an application (which I carefully picked), that has a bug, which noone foresaw, that deletes large files using system calls"

- snaphots: This looks like the best compromise at the moment, but for that to work, snapshots would need to occur in real time. I might be wrong, but I don't think this is the case on ZFS right now => if I recorded that UFO landing video and lost it in the interval between snapshots, it doesn't really solve my problem

- undelete in userspace through something different than aliases: I've seen this advocated again and again, and it is my layman's opinion that undeletion does indeed belongs to the filesystem rather than userspace. All undeletion takes is a chained list of blocks (so let's say 8 bytes for 64 bit block addressing of the partition, to be safe). Give me 8 bytes/block of file data, and I can now scan the whole partition, retrieve all data that has not been overwritten, and recover it. If I umounted my partition right after I realized my UFO video was deleted, it won't be much of a problem to recover it. Don't care much about filenames and perms as long as I can peek into recovered files (or parts of files), but if you insist, I'll be creative an flip a single bit instead of 64 for blocks that are sequential, so that I can use the remaining 63 bits, over multiple sequential blocks, for stuff like unique ID, original filename, perms, etc. Won't do much for small files, or if a lot of write operations have intervened in the meantime, but if that wasn't the case, there's a good chance you'll be able to rebuild it almost in full, even with a few missing blocks here and there
Now, I'll agree that not everybody wants to lose 8 bytes/block, but then mkfs could give undelete as an option on FS creation, and as long as people have a choice, everybody's happy...

Allow me, if I may, to open the can of worms here.

Why is it that in 2009 we can't get a filesystem that allows easy undeletion? It all happened to us one time or another: You typed that 'rm' command you shouldn't have, and now your work of the past few hours is gone. If only there was a simple way to undelete those few recent removed files...
We all know that the data is not zeroed on deletion, so why can't we have a File System that (preferably after fs umount) can scan the blocks and retrieve any file whose data blocks have not been overwritten yet, even if it takes a lengthy whole disk surface scan.
Hell, in 1989, I could do just what I described above very easily on the Amiga (granted, it was floppy based, but still...), and I never lost a single file apart from disk errors. I can even do that fairly easily with external tools on NTFS. So Why are all the UNIX filesystems I know (and btrfs is apparently not going to be an exception) such a pain in the butt for undeletion?

I know that 12 is no stranger to coverage troubles, but this had to be one of the most exciting sites, with Pete Conrad and his team gratifying us all with the very first precision landing on the Moon, right next to the good old Surveyor III probe. With a LEM descent stage and a probe sitting close-by on the same picture, it's bound to be a winner.

Come on NASA; we have now come to accept that the good 11 footage has been destroyed forever - don't deprive us of 12 too!

Indeed, these flashes have pretty much already been identified as the result of Cerenkov radiation.

Your post advocates a

( ) technical (x) legislative ( ) market-based ( ) vigilante

approach to introducing IPv6. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)

( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
(x) We'll be stuck with it
(x) Users of the internet will not put up with it
(x) Microsoft will not put up with it
( ) The police will not put up with it
(x) Requires immediate total cooperation from everybody at once
(x) Many internet users cannot afford to lose business or alienate potential employers
(x) The general public doesn't care about IPv6
( ) Anyone could anonymously destroy anyone else's career or business

Specifically, your plan fails to account for

( ) Laws expressly prohibiting it
(x) Lack of centrally controlling authority for the internet
( ) Open relays in foreign countries
( ) Asshats
(x) Jurisdictional problems
(x) Unpopularity of new protocols
( ) Public reluctance to accept weird new forms of money
(x) Huge existing hardware investment in IPv4
( ) Susceptibility of protocols like IPv4 to attack
(x) Willingness of users to install OS patches
( ) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
( ) Joe jobs and/or identity theft
(x) Technically illiterate politicians
(x) Extreme stupidity on the part of internet users
( ) Dishonesty on the part of spammers themselves
(x) Bandwidth costs that are affected by ISPs having to switch to a new protocol
( ) Windows

and the following philosophical objections may also apply:

( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
( ) Any scheme based on opt-out is unacceptable
(x) IP protocol should not be the subject of legislation
(x) Cutoff dates suck
( ) We should be able to talk about Viagra without being censored
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
(x) Managing dual v4 and v6 addresses is inconvenient
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough

Furthermore, this is what I think about you:

(x) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!