You are partially right. I miss the good old dump/restore tools for ZFS, but zfs send/receive do their job (in a limited fashion) well.

I see ZFS as the best option to run larger systems. I've had some problems with it when it was still experimental on FreeBSD, but at the moment it is running fine. I had to replace 2 faulty drives recently. It was painless and has not cost me any bit of lost data. I cannot complain, because there is one administrative problem less that I have to care about.

It is not the task of a filesystem to recover data, but to keep the data as consistent as possible. UFS does not have any protections against bit rot or against hardware failures, so you'll never know if data is broken.

Data recovery is done with backups (which you'll always have, if the data is important for you). There is no way around it.

How exactly does fsck help, if it shows structural inconsistencies to you? It says "blabla... CLEAR [y/n]?" and when you press "y" something is lost and when you say "n"... the filesystem is still broken. And second thing is that when data is gone, it is gone on UFS and if you cannot describe (reliably!) in 5 lines on a display what is gone/affected, the user should always assume that a restore from backup is needed. And how exactly will UFS know if/what data is gone when it even cannot check its consistency? When you are lucky, you'll notice that libc is gone right after a reboot. When have bad luck, your system will notice a lot later that you valuable data is gone and your backups have been already overwritten because the backup tapes/disks are reused after a month or so.

ZFS has got "self-healing" and does not need fsck. It will probably destroy more data while a user cannot give hints with "y" or "n" during self-healing, but the filesystem will become stable and available. ZFS can of course become unrecoverable, like UFS can be un-fsck-able, because essential meta data might have become destroyed. You'll always need backups for important filesystems, no matter if it is UFS or ZFS, everything can get FUBAR.

Hard disks recover sectors with ECC all the time. There is nothing special about it.

I once had 2 drives having 2047 reallocated sector count (buggy firmware, but drive ok).

Also, generally you don't need to panic over this attribute. You should panic when it increases steadily.

Best indicator for failures is not SMART but a reasonable filesystem like ZFS, optionally protected by raidz (if you want to recover from failures, usually you want). zpool status shows very reliably errors. SMART sometimes can lie to you or can have bugs.

Reallocated_Sector_Count

sectors that the drive successfully replaced

Reported_Uncorrectable_Errors

errors that could not be recovered by ECC

Command_Timeout

controller hanging and had to be resetted

Current_Pending_Sector_Count

sectors to be replace by the next write access

Offline_Uncorrectable

sectors that the drive tried to repair, but failed (try offline test, maybe it is not dead yet)

First... Arch is ok (probably for many people). But it is not good. In my opinion, Debian is still the best option as universal solution.

Why NOT Arch? I quit because of the early adoption of systemd (yeah, sorry, please read on... this is not the only reason... it was the last thing that annoyed me much). My system could not boot up and shut down anymore (could not power off, ATX switch behind my PC was the only option; 5 secs power switch holding was not switching off, but rebooting... don't ask me how this is possible!! I always thought that this is hardware power-off, but I confirmed that booting init on Arch made everything work again). Arch followed the systemd path and did not let anyone decide, because of complexity reduction. I was forced to quit, because there was a dangerous tendency that my system would not work anymore (there are still race conditions that affect me in random patterns on systemd; I try it sometimes!).

The more important reason are the packagers. This is a unholy mess with them! I posted a bug report for a piece of software which was auto-assigned. The person did not want to care about it and unassigned. A core developer assigned him again and once again was unassigned. I mean I posted a FULL PATCH! Very trivial and it was confirmed that it solved many problems with the package by 2 people. I wondered wtf they were doing there. I never have seen such weird behavior. The small fix that takes about 5 mins to integrate was for several months unsolved.

I also looked at AUR, because Arch itself is lacking many packages that are interesting for me. AUR is a security catastrophe, of course, you need to take a look what you compile and install there (basically everyone can distribute anything without supervision). But it's not that bad, because you have at least an idea how to install something you need. The most annoying thing is that it is a mess. Old stuff that does not work, packages installing binary distribution from servers without any guarantees. AUR is a very dangerous facility and highly unstable.

Haha! But it's pretty entertaining to watch all the people panic.

- A happy FreeBSD user

... because it can never be early enough to buy some apps.

What if someone who privately knows about the vulnerability gets the idea to exploit various installations of competitors (or even common users!) during the embargo period? Do you trust large enterprises not to misuse their knowledge to their own advantage?

Market share is difficult to describe and mostly is not interesting. How do you feel that there is a lot of BSD in Mac OS X (mostly in Darwin) and Android? Or about Playstation's OSes being a BSD-derivative? That's just to remind people that BSD is a part in many largely successful products. Especially people coming from Linux world are a bit arrogant by playing down BSDs. It is always a small reminder that they are wrong.

It must really hurt you that one of the small little peace that is known to Linux (GNU/GPL) world more than BSD (bash was imported to Mac OS X in 10.3 as standard shell) is vulnerable.

And btw... who the hell cares? It's getting fixed and everyone will forget it. All in all bash is a good peace of software, even it is quite complex. You don't see it have problems all the time. I am not making any bash scripts and I am a huge friend of tcsh as interactive shell, but when I did, I still would not panic. If you understand what a tool is and when a tool is working right for you, you will not throw it away just because it has temporarily a problem which is solved within a few days. Do you see a problem? I don't see any... it is gone, because it is supported well. What the hell do you want more from a piece of software?

My "studies" show that users will bitch about everything that has changed and where they need to rethink their workflows.

On the other hand, I don't think that systemd is useful, but I also don't care about what nightmares Linux gets from the administrative point of view (because I am a FreeBSD user). I also left the Gnome world after I noticed how it the software project is being handled (getting more and more unportable and dependent on Linux) and gradually found my way to Openbox and now to Xmonad where the UX is only limited by my imagination capabilities.

As you can see, UX is highly dependent on the user. The common desktop environments have a really shitty UX (from my point of view), because I cannot get them to do what I easily can do with Xmonad. Other users will get confused by Xmonad and think that it has a terrible UX (which will be mostly "true", also for you as a researcher, because you think that UX is not something that you are responsible to develop, but the desktop environment should provide it for the average dumb user out there).

What's the problem with trying a BSD without sharing files from a different operating system?

You are thinking too complicated, in my opinion.

Is managing light bulbs something worthy to write to a system log file? Isn't an application log suitable for this? And why should any application want to spam log files in high volumes?

Give me an example why you need a DB format for logs when you have trouble booting the system and most of the system actually does not work and you try to find the cause with tail/cat (whatever there is left that might still be executable). If your system log is high-troughput ... your system is broken. It should contain all necessary messages to understand in which state a system is (or was, when it is not coming up), give understandable warnings and to be easy to grep and compare with previous states the system had.

Many people (also from the BSD world) actually like Wayland, because it is actually not useless but replacing really awful X APIs. I don't know if you have ever written a program for raw X API. It is even worse than Win32 (which already is a total mess!), in my opinion. X is even more than just mess, it is bloat, full of things you will never need and uses quite old concepts that are not compatible with sane minds of today's programmers. It is a real improvement to graphical desktops on all systems. Wayland will be ported, because it is something many have waited for long time.

systemd is different. It makes a generic API unportable and provides users with functionality (mainly for desktops), but which is also totally weird and seems to workaround all the failures in software design that have been introduced a while ago. It does not solve them, it makes them even worse and more complex. The worst about it is that there are still people want to use these APIs and break portability. And for what? For something you don't even need and never expected to change.