Again, wrong. RAID-2 might have ECC, but mdadm doesn't support it. You got RAID-1, 5 and 6 (4 is identical to 5 with parity being distributed rather than on a single disk). But that's not a checksum, it's parity. It recovers from a drive outright failing, not from errors returning incorrect data but not detected as bad. I have seen it happen. RAID-5 can only tell you there's an inconsistency, not which disk has the bad data. The RAID controller's consistency check usually just updates the parity under the assumption that parity is at fault if that happens.

Oh it can be "checked" by RAID controllers. The question is, how do you know which copy is correct? In the case of a RAID-1, if the 2 disks don't have identical data, which do you assume is the right data? ZFS has checksums to figure out which is right. MDADM doesn't.

And if there is an API to allow you to ask for data from a specific disk rather than letting the RAID driver pick one, I'm interested.

Yes, there is a lot of duplicated code in ZFS for Linux, such as an SHA256 implementation, RAID parity, compression, and lately a whole crypto library.

The reason is either the kernel doesn't reliably support this natively or the implementation isn't usable. Linux doesn't allow non-GPL modules to access a lot of features (eg: the crypto library) or some features are version-specific (eg: LZ4 (de)compressor). The simplest solution is to import the Solaris versions.

But they've improved. SSE and AVX instructions are available for many of the above. And if ZFS does get re-licensed to GPL, then sure maybe we can make use of some of that stuff natively. Until then, ZFS on Linux has to deal with the reality of a non-GPL non-Linux driver on a GPL Linux kernel.

That last bit is important. If ZFS doesn't have a way to put its hands into the RAID, it can't attempt to rebuild known corrupted data. Until mdadm and hardware RAID controllers allow you to issue a "read, but try to give a different result" operation you can't do this. (Said operation would attempt to use parity even on a healthy array in an attempt to give a different block content by pretending a disk is dead). BTRFS does the same thing as ZFS - handles the RAID internally, and can repair corruption all on its own.

And yes, "first priority" means exactly that. ZFS has some design decisions that negatively affect performance in the name of data protection.

Muting's not good enough. As someone with a slow(-ish) internet connection with a meter on it, why am I being forced to download and play a video I clearly don't want?

As a tendency hardware H.264 encoding is inferior in terms of quality and bitrate compared to software encoding, even when comparing high quality hardware settings to medium quality software. H.265 will likely continue this trend, especially this early in its life relative to H.264.

I expect that big names like Netflix, Apple, etc are going to want to serve video in high quality and are willing to put up the resources for that quality improvement, which is what this article is talking about.

No, logs are preserved by shipping them off to another system over the network. Binary logs are harder to forge, but not impossible. Faking wtmp entries is a thing, for example.

The original question I replied to stated they were thinking about IoT devices and embedded systems like routers. There tends to not be many officially supported distros for those kinds of markets, rendering everyone's discussion on distro support policies moot.

If the password in question is required to login to the system in the first place, you have a chicken-and-egg problem. External devices like cellphones and post-its are the workaround, sure, but look which one people choose.

I'm running ZFS on Linux, so that's got me RAID and snapshots.

For "cloud" backup I have a remote system I also have access to running ZFS and use the "send/recv" feature to replicate incremental snapshots.

And finally, that remote system does the same thing in reverse, backing up to my home PC.

I've been using unix (ie. only Linux but we'll pretend that counts) for over 15 years now. Not quite the "old" you may think of but old enough.

I gave systemd a try. It actively fought me and I cannot accept that. It has too much of a "my way or the highway" mentality that you just can't fix without major C hacking and recompiling. If you don't like its way of doing things then too bad.

sysvinit scripts may be slower to boot and have fewer automatic/behinds-the-scenes features you want, but I can make any arbitrary change to them with minimal effort. I can run them with line-by-line tracing using "set -x" and find out exactly why it's hanging. I can rescue it with *any* install media even if it doesn't have systemd and '/etc/init.d/servicename start' will actually work.

systemd is fine for desktops run by people who think Firefox is the only app they really need to Surf The Net. sysvinit is designed for people who want control of their systems and want to be able to inspect what it's doing. And I'm sorry, I NEED the latter to do my job properly.

Remember back when IE 6 refused to die because corporations had ActiveX stuff that prevented upgrading? NPAPI has become like that as well. I can't upgrade because I have apps that run as Java applets and I'll lose them. I already can't use Chrome...

So, here's to vendors migrating away from Java and issuing updates I guess...

(And I find it ironic that Flash gets some kind of exception even though even Adobe wants it dead.)

It does require root if you want it to run a private port 80/443 service to do the authentication for you and/or to install the certificate into your apache config on your behalf. A nice feature for less capable users (ain't that a scary though)

But if you are using an existing web server and are okay with manual certificate installation/configuration and have a long command-line full of path overrides (eg. no using /etc for storing the generated certs) then it runs just fins as a normal user. I did it during the closed beta.

There's a few other little kinks to worry about like reloading apache on an updated certificate but I think you're capable of dealing with that.