Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Re:Too little, too late (Score 4, Insightful) 262

Apple doesn’t “send down” any updates. You’re free to take or leave any OS update you like. They’re remind you a bit, but nobody is forced to upgrade the OS they have on their phone right now.

And do you *seriously* think Apple releases updates to “actively try to fuck up older but functioning hardware”? Paranoid much? Yes, some updates have made older hardware work less well. Other updates have improved long standing issues on older hardware. That’s the nature of software development. It’s not a good thing, but it’s a far distance between “didn’t test it as much on three-year-old hardware” and “let’s intentionally add this bug to make the old phone flake out.”

Comment Re:BTRFS is getting there (Score 1) 270

The value of "very good chance" is up for significant debate. I've replaced failing drives in RAID-X (for X >1) arrays a few dozen times. Haven't had that second loss happen yet. I'm not saying it's not possible, but it's not something that keeps me awake at night given the other compensating controls I have in place.

Among those compensations:
1) ZFS resilver != MD resync. If I lose a 4TB drive that had 2TB of stuff actually on it, I'm only copying 2TB worth of blocks. 50% less wear & tear on the other array members, less liklihood of a getting shot a second time while the Doctor's regenerating...

2) ZFS self-healing on read. Every time blocks are read, any individual device read problems get detected (by checksum), repaired (by block relocation), and signaled to userland (by the `zpool status` command, and also as picked up by my system monitoring solution (Zabbix) and alerted to me via email & phone push).

3) `zfs scrub` which is an on-demand, read the entire drive & apply (2). Scheduled to run weekly, I know if there are issues starting to occur long before a device fails.

4) Freaking backups. On another machine. Maybe on tape if you've got the $$$. In my case, "last year's" (or 3-4 years's...) disks go in another server which gets powered weekly for zfs send/receive, then powered down again. Also RAIDz, also subject to maybe failing at the same time as the others, but we're well past lottery odds at that point I think...

Any errors signaled by 2 or 3 get a couple of shots at the reseat the device, retry game. After that, the drive gets subbed out. Sometimes the reseat is enough for months or years of additional error free operation, sometimes the device was really going. Either way, ZFS has warned me far enough in advance to remediate before a second failure.

Comment Re:BTRFS is getting there (Score 1) 270

Basically it is just the combination of the three into an integrated stack.

Basically just, that's exactly why it excels. The benefits from the integration are very significant in real world use. Zero overhead snapshots, resilver only used blocks instead of blindly copying an entire device block by block, scrubbing only used blocks in pool to ensure all copies are consistent across devices & no bit rot has occurred (and FIXING it if it has).

You dismiss the checksumming, but that's how ZFS detects bit rot, even on a RAID-1 mirror. Mirror a device without checksums, one device has a bad write but still readable (IE no device-level read error). Without checksumming, you have no way of knowing which is correct. ZFS can detect and recover from this during a scrub or automatically and transparently on read.

The integration really does make ZFS a superior system.

Comment Re:BTRFS is getting there (Score 1) 270

For me, lack of RAID-5 is enough reason to consider BTRFS deficient. The glowing accolades as to the reliability and accuracy of fsck tools for BTRFS leave a bit to be desired: https://btrfs.wiki.kernel.org/...

I looked long & hard at BTRFS about four months ago and was considering migrating from ZFS. It blew my mind how much was lacking in BTRFS in comparison and that anyone would consider it superior in any way other than that it's in-tree.

Comment Re:ZFS is nice... (Score 1) 270

You've over-simplified what is & isn't a derivative work. Linus himself has written about the distinction specifically as it applied to the Andrew Filesystem:


According to Linus, a driver that was originally written independently of Linux for another system and simply ported *to* Linux is not a derivative work. That's exactly the case for what ZoL is.

You've also misrepresented what the ZFS modules do in terms of their contact with kernel internals:

touches unexported APIs of the kernel

Neither ZoL or the SPL layer that it depends on touch any non-public or GPL-only symbols of the kernel. If they did, you'd be correct in there being an issue. They don't, and there isn't.

Comment Re:ISO (Score 1) 178

That requirement would be in conflict with a lot of existing standards that require that no one except the employee know their password. PCI for one has a line item that forbids any kind of credential sharing. Wouldn't surprise me if SOx and others had similar. There's no accountability if anyone knows (or could know) your password. Administrative reset capability is different since it leaves an audit trail.

Comment Re:Work Issued (Score 1) 178

Absent a secondary access mechanism, the company very likely doesn't have the ability to unlock the phone. The worst penalty available would be to terminate the employee, which one would assume happened about the time charges were filed, if not before.

Looking through the iOS docs as of 8.x, it looks like passcode reset isn't an option for MDM any more. It was at least in iOS 6. Makes sense considering how much vital key material in the Secure Enclave is derived from the passcode at power on. Resetting the passcode would be very close to a device wipe in terms of the data that would become un-decryptable. With the (very good) direction Apple's been going, the idea of key escrow or something on the MDM server would be unthinkable.

So no secondary access mechanism available, at least on a recent iOS device. Fire their ass and sort it out in court...

Comment Re:But your finger prints is not protected (Score 1) 178

The nice thing is that once precedent is set in a federal court, all cases in that district and *usually* similar cases in other districts are ruled the same.

So the upper class fought for their rights, but they trickle down to the little guy.

Could of course be decided differently in another district & need to go to SCOTUS for a final ruling, but for now it stands. Also possibility of direct appeal to SCOTUS.

Comment Re:I have other prints (Score 1) 178

I've tried other parts. (Just for science, mind you!) TouchID looks for ridge detail and won't enroll anything but a finger. Haven't tried toes, though.

(It was my nose, you perverts... Ever tried to use your phone on a cold winter day with gloves on? You can at least poke the Next Track button with your nose, but not unlock the phone.)

You are in a maze of UUCP connections, all alike.