All btrfs does is manage a B-tree filesystem. All grep does is apply a regular expression to a string.

However, the UNIX way is not always even a good thing.

It is also the UNIX way to duplicate a single thing a hundred times for each little feature variation (grep, egrep, fgrep, most of Perl.) That can also be unpleasant for the end user (xterm, gnome-terminal, kterm, gterm, LXterm, terminator, editing Perl.) Great for a system administrator who is expert at their particular tool and only that tool but horrible for everyone else.

That's without getting into the UNIX Way for (lack of) documentation. Or how that one thing is so often the wrong thing so it doesn't matter how well that one tool does it.

btrfs is famously called a rampant layering violation. The roll-up of filesystem-management features in one place actually lets the developers avoid duplicating code (which may actually be about as non-UNIXy as you can get in some ways.) Code that now knows about certain information normally hidden from it can do things differently. This is sometimes better (rapid mkfs) or worse (fsck tool was apparently hard to write.)

In my opinion, if your enterprise system depends on fsck and not good backups then you don't have an enterprise system. Yes, xfs_repair can do amazing things to mostly trashed disks. But one day your data will take a good fscking where only surviving copy will be the backup copy.

RAID5 implementation from Intel is in the tree, but waiting until after the fsck is done. And btrfsck has been around since, oh, February? And the btrfs-progs you should be using with the 3.4 kernel have btrfsctl included?

I was hoping the RAID5 code was going to land in 3.4, actually. Reading the pull request says that RAID5/6 should be in 3.5. Oh, well.

Of course, if you have enough money to buy an "enterprise" solution, your SAN/NAS should do the thing doing RAID for you anyway.

My major criticism of btrfs is the horrid sync performance. Hosting virtual machines tends to require lots of small writes to disk that make btrfs incredibly non-performant.

btrfs has many sexy, sexy features for a world of enterprise SAN storage and virtual machine hosting. It has thin disks, balanced meta-data, flexible storage, SSD optimized modes, multiple snapshot layers, checksummed data on disk. All of this just because it does one thing and does it well: manage a B-Tree database.

Today it's is just not there in the I/O department, sadly. Probably good for inside the virtual machine guests, though. Only testing will tell.

Wow, speaking of niche file systems. Log file systems have quite a long history. Of horrible performance and fragmentation. But if we all end up on SSDs, that won't matter. Underlying any file system you put on it, an SSD implements storage as a circular log and performance is fast enough to not depend on huge uncommitted disk caches.

Well, to be fair most the webcomics linked in the Funnies slashbox stopped updating somewhere around the middle of Bush, Jr.'s second term in office.

Having been around to participate in the comic vs. news debate back in the day and seeing a lot of full-of-themselves trolls leave just over that, I would have liked to see some spiffing of it up. But not quite as sexy as a fresh coat of CPU chewing javascript, of course. Or ads in the whitespace on the left which run up under the top left logo in chrome and firefox creating a colorful 'slashdot' title where the white one was.

Just pay my friend over there. Then you can have the stuff.

Criminals have been using third party pay as long as money has existed. No way you can trace it to him. Just some random guy.

Nobody *pays* Fat Tony. They just do him favors. See, when he goes somewhere his money is no good. Love the kids and the place, hope nothing bad happens to them. But he'll have one on the house.

Traceable currency has only one use: collecting marketing statistics. For every other use there are trivial loopholes and, as you very clearly mention, unintended consequences for the poor. But marketing doesn't really care about the poor. Your target demographic is people who can afford to pay. Even if it would ruin them.

Today people who use paypal, debit and credit cards should be aware that they trade free marketing data for convenience. Tomorrow it may not be a choice. To riff off Ghostbusters: "there is no search, there is only Google."

$30USD 'crappy' inkjets or $70USD multi-function fax/printer/scanner are not what you or I would call a printer. Or a fax, scanner, et cetera.

These are Windows OS accessories.

This hardware may not be made by Microsoft or a Microsoft subsidiary, but they are for all intents and purposes just an add on to their existing software product(s). Using a standard does not enter into the design consideration, unless one means MSDN documents.

If Linux, and I do mean the kernel, wants to interact with this type of hardware it has to replicate the functions of the Windows OS the device requires. The observant will be making comments about user-space drivers talking to raw hardware connections at this point. The bitter will mumble about "it's Linux, not ReactOS."

The funny people will just make jokes about dialogs for root access being the distribution equivalent of an IE pwn-my-system pop-up. However, many traditional UNIX user-space processes that talk to hardware have had permissions problems like Linus is complaining about.

Getting lots of little bits of software, each running under their own users and groups, to talk together is annoying at best and horridly bad most the time. Add various users into the mix and the UNIX groups-are-how-you-share model just falls over. Bad permissions, for lp and printer software in particular, appear to be the norm. In one system you have SETUID executables and SETGUID directories spreading like kudzu in the filesystem. Others with equivalent-to-god accounts (oracle anyone?) plus the yellow-sticky with the password getting passed around the office. In another, everything pretty much just runs as root, bypassing any Discretionary Access Controls and screaming at users to put in their keys to the kingdom just to get a photo to spit out of the damn laserjet.

It almost makes one pine for an implementation of Capabilities.

But that still won't solve the winmodem hole. Fuse for printers, perhaps?

Bleeding-edge users who know what they are doing and don't care about data loss are being offered the chance to test a new and interesting filesystem

Amen.

fsck's only job is to make that junk that was a filesystem look something like a filesystem again. Nothing in there about making it look like the particular filesystem you used to have. fsck is not backups. fsck will not (necessarily) get your data back. fsck may eat kittens on a bad day. What fsck does hand back to you should not be trusted and should certainly be verified.

If you think that pulling most of what was /home, /var, /srv or /opt out of lost+found is fun, just remember that corrupted directory and filenames get named after their inodes. Nothing like trying to figure out of 1234567 or 1234568 was the start of the quarterly financials report.

If you are relying upon a fsck to get your data back after a power outage, you have more faith in your filesystem than you should. It's a nice validation tool, with the caveat that a False Negative means you go back to using a damaged filesystem for more fun later, rather than now.

BUT if you have backups, please do test. Having talked to the BTRFS team directly at LINUXCON, Mr. Chacon and folks are pretty cool about getting feedback. And you can do nifty things like snapshots for backups on RAID10 or thin disks on virtual machines which don't inflate during formatting.

For many filesystems, failing a fcsk means reaching for the format tools and the last (verified) backup. You are backing up everything, right?

$7.8 billion

Think of the science NASA could do with that cash being wasted to frisk old people for their pill bottles!

Or, if you're one of the NASA haters, think of all the children who won't get an adequate education/vacination/lunch/foodstamps for that money.

But damn tootin' if one of them grandmas thinks she can pass off a bottle of Midol, our Skies Are Safe(tm)*

* (For values of safe equal to We Covered Our Butts come election time. Deal not available in major markets, near large cities or in New York state. Remember: you only need to give up a little freedom or the terrorists win. Vote TSA again, next election.)

These types of arguments tend to run on one of two lines: people trusting that which they shouldn't and examples of simple broken systems.

There is nothing you can do about people trusting systems they shouldn't. Houses have many ways in that are usually easier to open with tools than the doors. Windows are used for entry because you only need a fist to break most. Walls are just as easy with power tools. It's the social contract between people that prevents this type of security problem. Locks on your doors only keep out lazy opportunists checking doors for easy access. Sadly, the Gabriel's Greater Internet F*ckwad Theory implies that online the contract fails.

All security mechanisms suffer from this. Reference: http://xkcd.com/538/

The obvious is to just use a tool that can attach things to doors. Even a harmless looking sharpened thumbtack defeats the 'handle-less' door yet is stymied by the presence of a lock.

I think the equivalent in computer security is pop-up phishing. Such as putting up a webpage popup AD with a similar password requirement and appearance, hoping that some people will try their existing passwords from their existing systems. Or a fake screensaver overlay that kicks in after one minute of idle.

It is a simple matter of application of non-obvious force: smack the door with your fist. One that is easier to do than even smashing windows. It not only leaves no trail, but makes it look like you know what you are doing so unaware bystanders will think you should be using that door. Unless it is badly fit to the frame and actually stuck to it, if pushed on such a door will bounce open. Materials are elastic to some degree and forces between joints will be partially reflected just due to the difference in material (the gap that comprises the joint between door material and frame.)

To translate into security speak, this is shoulder-surfing someone who uses the same password everywhere.

Fundamentally, security is about psychology and not technology. The lock should be the hardest part of the door to deal with so attackers focus on it and waste their time. This gives you time to discover and deal with them manually assuming the attacker just doesn't give up and go check other doors. Most people are dumb - well average or bellow - so this works well. You cannot keep the smart ones out - even if they ignore the window you left open they know how to use a battery-powered chain saw to make their own doors.

Now, the human race has been expanding exponentially at the historic average of 2% per year.

No, the human race - and all other breeding populations bellow any limited threshold - is on a logisic curve. Historically it just looks looks exponential because we have been near the origin. It's also a much scarier curve when you consider the growth period is the 'good times.'

In a natural population the number of breeders explodes until it hit some limit and loss suppresses any more gains. It is a simple consequence of reality. With the ever changing environment that is the natural world, any species able to rapidly expand when one of their limits is removed becomes numerically dominate. Since evolutionary success is simply having more grandkids than the other guy, leveraging these opportunities is built into just about every living thing from bacteria to Redwoods. You breed and spread during the happy times until the limit. Then you replace spreading with horrible churn: for each who is born, someone must die.

The unanswered question is: what limit will keep human population from growing? Very poor economists and armchair sociologists trot out the 'limited space' arguments based on totally unrealistic understanding of not only 3D space and what 'food' is, but also territorial needs of humans and how they can overlap. People who have looked into the matter discovered an amazing thing.

Give education and rights to women and your population grown slams to a standstill.

Why?

It's simple: you have most if not all your children surviving to adulthood and educated, wealthy women women able to tell their man/cleric/priest/culture NO to unprotected sex. There is less successful coercion of women into walking-baby-factories for men by accident or purpose. The world is long past the need for huge families to keep the farm running or fight that war. (Starvation is a logistics and distribution problem.) Also, consider the improved access to medicine available to educated, non-poor mothers. Birth is no longer a lottery in which both the future adult and its mother gamble their lives. There is a lot behind this topic and Google is your friend.

It turns out that humans are more than dumb animals. At least some of us. And by definition what people do is unnatural. Long before starvation or disease limits human growth we do it ourselves. Cut the mechanism behind rapid population growth and it stops. Long before you need government mandates, starvation lotteries, colony ships, O'Neil colonies or Logan's Run our women stand up and conveniently have a headache tonight.

We won't over populate this planet let alone the solar system if we can just do one thing: raise women out of poverty.

It's basic humanity.

(And if that doesn't work in the end, just putting all the women on the ship and forcing the men to stay at home will. Motes we are not.)

RPM having all the packaging written on a single file, mixing both shell scripting, changelog, dependency, you name it... is simply a horrible idea.

Why?

Having actually packaged other people's software with and without patches, the specfile method keeps meta information, the phases of pre-installation, setup, post-installation and your dependency information synchronized nicely. Of course, if you really need separate files you can just use the %include macro on recent rpmbuild versions. Put meta info in a header file, changelog in changelog.txt, dependency in another file, you name it.

You could argue that building an RPM is actually a little, too easy. Low barrier to entry means you get plenty of crappy RPMs (looking at yours, Skype) and flavor of the day naming. This is also a problem for Ubuntu PPAs. If the specfile looks horrible because the packager cannot script well, that has nothing do to with rpm's quality.

It could be worse. Like .deb's numerous mandatory directories. All the extra control files needed even if you don't use deb feature XYZ. And control files that are white space sensitive. Not good Python-style sensitive but I'll-kill-your-cat and get-off-my-lawn-80-column-punchcard Pascal sensitive.

But having built both types of package I can say that I prefer the apt-tools and front-ends which yum (and things like software.opensuse.org) is certainly catching up too. On the other side rpmbuild is quite nice, being pretty much make for packages. I've gotten better packages out of running alien on rpms than what the deb tools do with some native control file configurations.

IMNSHO, the debian package format is over-engineered (or poorly engineered...white space, bleh.) But the debian developers are in their right to be very anal about how packages are built, even if the specifics of it are masochistic to the poor distro folk having to make the package. The higher barriers means that packagers just cannot fart out a crappy package. They have to build something that is intended to be used within a greater system, apt. That apt ecosystem can then be built on that more stable ground.

But I'm betting like with apt vs yum, it's the superior end user interface which will win out here. The devs, packagers, icon makers and what not will continue to toil on the backside with the tools at hand, scratching those itches or raking in that corporate pay. And maybe someone's manager (or UI 'designer') will figure out that desktop and mobile devices just might need different UIs.

Although in the end, after enough customization does your original distribution even matter?

Earth-bound Humans are currently better at many impomptu, lightweight manual tasks than Earth-bound robots -- but are they still better when encumbered in a 200-pound spacesuit, with gloves like oven mitts?

Quite simply: yes.

The exact quote escapes me, but one geologist said that if you combine all the works of all the mars landers in history, it amounts to about a good day for an average geology student.

While it is inconvenient to have to send into space all the arms, legs and guts meant for living at around 1 atmosphere of pressure and not that much far from 24 C, it is really hard to beat having a working human brain when it comes to exploring.

Our global reach is proof enough of that.

We marvel at what our robotic tools can do, but mustn't forget they are but longer, sharper hammers today. There is still a human behind them.

But then, I'm biased. Like whalers who used to leave their families for years at a time, today I wouldn't mind being one of those stuck on a rock seeing things noone has ever seen before. Learning things noone knew before. And yes, probably dying for that chance like people die every day for less. In the meantime my battle.net ping times might suck, but then there's always [rock] porn right out the window.

To quote Albert Szent-Györgi (1893-1986) U. S. biochemist: "If any student comes to me and says he wants to be useful to mankind and go into research to alleviate human suffering, I advise him to go into charity instead. Research wants real egotists who seek their own pleasure and satisfaction, but find it in solving the puzzles of nature."

What will happen to the CmdrTaco's Links slashbox?

Will the Funnies change?

Now watch as the low UIDs to take over the discussion on this post.

Hesitation means a higher ID for those who asked: to register or not to register? Back in the day that was a serious question.

Long time reader, only one time submitter (I still have to remind people I'm not associated with any of the sites I linked, talk about obscure references.) Been coming to this little site since randomly typing slashdot.org into a url bar back in '98 or so. I don't recommend doing that today with DNS hijacking and domain squatters. But I did get sent to some funky Chip'n'Dips site with the most ugly color scheme outside of geocities. It kinda grows on you though, that green glow.

So, for next job ideas how about opening a restaurant?

I hear 'The Commander Taco' is a good name.

I can't believe a person as big of a publicity hound as Lady Gaga would every have a problem with a Weird Al parody.

Perhaps her PR agents know about the Streisand effect and are meta-meme hacking the culture for a little publicity? Certainly wouldn't be the first time someone started a fight just to get a little bit more famous.

-- Joe Haldeman,"Colonizing Other Worlds."

While he was discussing closed cultures on Interstellar Travel and Mutli-Generation Space Ships, Spaceship Earth also has some of the issues with having real live people trying to keep it together for the whole voyage. And we just go 'round and 'round with nowhere in particular as the course.

it's that we're taking genes and modifying them without knowing the exact changes made. We can make many permutations of the potato via GM, and have no idea what they'll end up as

Funny, sounds an awful lot like mutation. You know, that variation a breeder looks for to create the next great thing.

Oh, I get it: if 'mother nature' aka 'God' aka 'not a guy in a lab coat with a gene gun' does it, then the new genes are good. But if humans did it, then it's bad.

Bacteria have been performing this trick of inserting new/random genes for longer than we've been around. Humans are just applying it to plants and animals. And eventually our kids.

. Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object', and it's pretty cool.

It is pointing out the obvious that a file is kind of object, with a certain defined behavior, strong namespaces and associated methods?

Systems like Plan9, where everything literally is a file make the painfully obvious. The only changes would be to make file properties be just more files that appear to live bellow the filename as if it were a directory and get rid of completely foreign namespaces like the network interfaces.

There is some extra syntatic sugar with object systems. The 'object' systems use dot delimited dereferencing for system enforced sub-classing - runtime resolution of the thingy being talked about. The file system's path separators are only meaningful on the filesystem meta-level for object...er...file isolation. Otherwise we are dithering over path separators to namespaces: /path/to/thingy instead of container.subelement.thingy.

Of course, PowerShell has the advantage of an actual design and uniform implementation. Even the traditional Unix utilities produce completely unique output formats that often require regular expressions to pull out meaningful data or at least massage the pipe. This is a possible consequence of unregulated organic growth.

Now, the author of TermKit has a valid point in his article on the sofware's design: not enough file handles are used by traditional Unix utilities. STDOUT and STDERR are both used to produce human-readable and machine-readable output. Instead make STDOUT,STDERR (FD 1 and FD 2) machine-only and FD 3 and 4 be used for human-consumable output. This could be much more flexible. (Of course, like most standards, nobody would have used it in the sake of rolling the next great thing.)

But this highlights that trivially parsable output combined with pure file semantics gives you the benefits pure 'object' environments like Powershell gives to users. So it appears the inconsistency between terminal applications is the real issue, not some mythical object-ness that Powershell proponents claim files don't have. And TermKit's plugins / adapters "fix" that.

After all, what are programing languages but syntactic sugar in our heads, mere mental layers on top of high and low voltages running through some hardware?