I've seen enough 1000ms+ pings to know what useless service looks like.
Pings to where? I've never seen pings over 100ms to machines in the UK, and even ones above 50ms usually indicate problems at the far end. 20-30ms (including a wireless hop at my end) is about normal.
I will never understand how someone so apparently disconnected from the reality that normal people face can actually manage to get elected, but whatever the reason, it seems a sad indictment of our "representative" democracy.
The problem is that we don't vote nationally for cabinet posts. Someone may be a perfectly competent local MP, in touch with local issues and understanding their constituents' interests, but have absolutely no idea about whatever department they're put in charge of.
Virgin "Throttle you back to dial-up speeds" Media
No, Virgin 'throttle you to 25% for a few hours when you go over the caps' Media. On their cheapest plan, 25% is still fast enough to stream iPlayer HD and the maximum amount that you can download within the caps is several TBs/month, so it's not really something I've felt the need to worry about.
Virgin "What is infrastructure investment" Media
It's probably the thing that they've done to allow them to bump the speeds that they offer every few years. I was an early adopter for their 1Mb/s and 10Mb/s services and stayed on 10Mb/s as it moved from their most expensive tier to the cheapest. It then moved to 30Mb/s and is now I think 50Mb/s (might be 60Mb/s, not sure).
Like, for example, UFS actually has a repairing FSCK. ZFS fanatics will argue to the ends of the earth that ZFS doesn't need fsck repair because it has built-in raid. Riiiggght.
That's not the argument. fsck is not magic. It is designed around a number of possible kinds of error. It verifies on-disk structures and will attempt to reconstruct metadata if it finds that it is corrupted. Equivalent logic to fsck is built into ZFS. Every ZFS I/O operation runs a small part of this, validating metadata and attempting to repair it if it is damaged. You could pull this logic out into a separate tool, but why bother? zpool scrub will do the same thing, forcing the zpool to read (and therefore repair) everything using the fsck-like logic in the kernel.
Bottom line is, ZFS is groovy and all (though no speed daemon) until it breaks
The same is true of any filesystem. If a filesystem is corrupted to the extent that the self-healing logic in ZFS can't recover, it's also corrupted to the extent that a fsck tool would not be able to recover it.
All of the CDDL stuff in our tree is in a separate cddl directories. You can get a copy of the tree that does not include them and you can build the system without them. This is a requirement for a number of downstream consumers of FreeBSD.
That said, we do enable DTrace by default and the installer lets you choose UFS or ZFS. I'd recommend ZFS over UFS for anything with a reasonable amount of RAM (not your Raspberry Pi, but anything with a few GBs).
"All the people are so happy now, their heads are caving in. I'm glad they are a snowman with protective rubber skin" -- They Might Be Giants