It keeps the riff-raff away.

Trickle-down, baby. Trickle-down.

Work smarter, not harder. That's the way it has been going for thousands of years of civilization and social advancement. We still need low-skilled work, but those will be fewer and lower paying the more people compete for those jobs. And skilled jobs will grow and wages will increase as employers compete for those skills. The intelligence and education required to stay in the middle class will continue to increase.

There will be incentive to create tools and technology to use those lower-skilled, less expensive workers just as there are today. You don't need a comp sci degree to work on an automotive computer system to repair cars. The same gear-heads (I use that term affectionately) that worked on cars in the '70s do so today. Tools will make today's high-tech jobs require less skill to do more advanced work.

Who would have thought in 1970 that, 40 years later, functional literacy would require understanding of how to use computers? Or that we would all carry those computers in our pockets. In 40 years, who knows what "functional literacy" will look like? Everyone able to program a computer? Probably, but "programming" won't look much like it does today. The only thing that matters in the end is how fast an individual can learn and adapt to a changing world.

zfsonlinux has less testing than Btrfs? Really?

I think you mean *THE LINUX SHIM* has less testing. However, there's this *HUGE* portion of the code, as a wild ass guess I'd say 80%, which is the internal algorithms, data structures, and other internal parts of the file-system that are shared by the Linux and Solaris versions and those have been quite seriously tested for ZFS.

My experience with ZFS under Linux via FUSE was that there were some bugs in the integration layer, but they tended to be fairly shallow and never lead to data loss. This is over around 3 years of ZFS+FUSE on Linux serious use (~30TB of backup storage, home storage server). I tested the heck out of ZFS+FUSE before we deployed it, found some issues, worked with the developers (who were amazing!), and eventually got to a point where the stress test I was running on it was more stable than it was under our OpenSolaris systems a few years prior (and the reason I built the stress test).

Based on my experience with ZFS, ZFS+FUSE, and btrfs, I'd personally trust ZFSonLinux over btrfs. My experimentation with btrfs the last few years has been that it still needs a lot of work.

Please explain it to me, because I really don't see any reason not to rely on an "out of tree FS". My system won't boot without tons of stuff that is outside of the kernel tree, including things like init but also things like graphics drivers on my desktop.

It seems to me that the ZFS license issue is only with the kernel, and can be solved by distributors. Distributions deal with wrapping up things under multiple licenses *ALL THE TIME*. And Ubuntu seems to be pretty close to having this integration done, based on what a friend reported with his experiments with zfsonlinux as a root device.

With all due respect to those involved, I think the pronouncement that it must be in the kernel and that it must be in the kernel, and that it is a "rampant layering violation" have set Linux back a long ways. FreeBSD, DragonFly BSD, OpenSolaris, have all had "advanced filesystems" for years now. Linux is basically stuck with a feature-set from Berkeley FFS and isn't really showing that that is going to change for several years... It's kind of a shame, especially since at the time of the "layering violation" comment it was clear to me that the violation came with significant compelling reasons for it, and now btrfs seems to be realizing that and implementing the same features...

Hindsight and all that, but it's a damn shame. ZFS is insanely awesome, I have a number of systems running it under FUSE and it has proven very reliable over the years.

If you are "trusting your data" to *ANY* file-system, you are likely to be disappointed.

I have run btrfs off and on for maybe 3 or 4 years because I don't *HAVE* to trust my data to it. I have good backups that run daily. If btrfs screws the pooch, I'm not really out that much.

Note though, my backup servers run ZFS. :-)

Honestly, it seems to me that btrfs has gotten worse over the last few years rather than better. 4 years or so ago when I first started using it, it actually worked pretty well and I was fairly happy with it, including taking automatic snapshots, but I never had a data loss. ISTR that I switched away from it because I upgraded to a new distro and had to reformat, for various reasons. Newer versions I've tried have been barely usable and I've had brtfs wedge itself a few times. Some of the issues were distro integration issues I think, like 12.04 seemed to *ALWAYS* run a full fsck on boot, and I think it took a snapshot when I tried to do an upgrade to 12.10, which somehow caused it to think that it had space available when it didn't and it ran out of disc space during the upgrade...

I really want btrfs to get production ready, but I'm half thinking that by the time it is HAMMER2 will be out and I'll be infatuated with it. Note that btrfs and HAMMER started around the same time, maybe HAMMER had a 6 month lead. HAMMER has been "production stable" and has been the default Dragonfly BSD filesystem for several years. Dillon seems to know how to build a file-system...

Same here. 2ms from work (Loop). 11ms from home (NW side).

Has become? Back in the day HTML was a mish-mash of tags and (eventually) DOM models that were abhorrent and incompatible across browsers.

As soon as you standardize one thing, then the big boys are on to the next big thing. You still have a myriad ways to generate web content, all of which should shield the developer from most of the madness. Standards are good for taking a snapshot of the state of the art at a point in time, allowing developers to say "I support this version" and browsers to guarantee they will render standardized versions correctly. I expect every browser on the market today to correctly render all standardized versions of HTML.

Citation required...

People have no appreciation for the amount of power it takes to run a fully armed and operational battle station.

My goal is to discourage copyrights extending that length of time. Only if one really thought the content was worth many billions would one choose to extend it that long. And society would get reimbursed for the loss to the public domain.

Copyright terms should not be limited to fixed terms. First 14 year term is free + one time unlimited extension costing $50 * (1.7^years). Paid up front after year 14. No further extensions. Indexed to inflation.

That's not entirely in the public domain. I release stuff under many licenses, as well as putting them in the public domain. I usually have a very clear idea of what I choose to do and why I do it. And my views have certainly evolved in the past 14 years since that statement was initially attached to that website. Besides, people have made (and continue to make) fair use of code and images published on that site.