Reviews were quite positive of Apple implementation. Has anybody tried the linux version ?
The install procedure is a little rough around the edges, so I'm looking forward to having that more polished.
> It allows for applications with no capabilities to use multiple uids and to implement privilege separation. I certainly see user namespaces like this as having the potential to make linux systems more secure.
This can be used in two ways: Application security, in general, would benefit from this practice, and if you are creating a Linux that can be both a traditional "desktop Linux" as well as running the Android environment, this is a useful feature for enabling Android app security to remain secure, which it wouldn't if you did user namespace separation merely by convention.
About an year or so ago, it was something like 2.6.x. Then, it jumped to 3.0 and now it is at 3.9.
EDIT: For those who do not remember the 2.x stuff when x was a odd number the version was unstable, when it was an even number the version was stable and basically was what distributions used.
Anyone know of any reason for this?
Since 2004, the kernel team has aimed to release every 2-3 months, and current releases are still within that timeline.
“makes me suspect [...] people were gaming the system and had timed some of their pull requests for just before the release”.
Does anyone know what Linus means by that?
There's ways to free up space for real but you have to manually use some tools to do it from what I understand.
Pity I can't report these really, tainted (AMD) kernel.
The ability to make daily snapshots effortlessly is godsent on my tinkering computer (so I can rollback whatever stupid idea I came up with), and on a slow laptop with a even slower 2.5" PATA harddisk, I at least have the illusion of a performance improvement by LZO compression causing less disk-accesses.
 mentions that RAID5 never checks parity on read, which is not an issue with ZFS/zpool (and, I think, the proposed BTRFS/raid5) because they verify all read blocks' check sum. Also the creeping multiplication of bit-errors on parity rebuild is a non issue because of this.  only mentions ZFS, but attributes copy-on-write as the remedy against distribition of bad data over the RAID volume.
And, yes, I see this silent corruption problem, and the inabilty to identify the "wrong" drive in case of parity mismatch as a big deficit of block-level RAIDs, and I share their view on the abysmally bad performance of some degraded/rebuilding arrays. But that is mainly what the filesystem-integrated redundancy mechanism try to address with their "blatant layering violation".
I wasn't sure what btrfs (or the parent) meant by 'raid5'. I think zfs was wise to call it something else.