Debian are also very important events because it influences all of its descendants like ubuntu, armbian and raspbian.
Since I use nearly exclusively open source software I tend to trust it. I see the extra security benefits of snap and want that for sure, but all the trouble I had using it was simply not worth it for me.
I'll come back in 10 years with snap and wayland have actually matured :)
Gotten used to it (first Debian), has decent desktop and server game, kinda "just works" and if not there more people stuck and solutions are published.
I'm a bit of a hypocrite, though, as I use a Mac for daily use. I do run Debian Stable for my servers, though! With Bullseye nearing completion, it looks like it's about time to bake some new VMs.
I also really found myself missing the Arch wiki, and ending up back there anyway. And customizing Debian so much, I might as well just ran Arch.
So back to Arch I went.
Now, is it super fast? (No.) Is it (or any other COW FS) the right choice for an SSD or database? (Probably not.) Is it the right choice for data that get read much more often than written and you'd like to be sure 10 years from now that you haven't lost any of it? (There's a pretty good argument to be made there, I think.)
I should have known better since during my initial evaluation in search of a better llvm for Linux, I set up a root non-raid btrfs volume comprised of multiple dissimilar disks and lost all the data after an unsafe shutdown (a kernel panic that may have been caused by btrfs in the first place) even though all the disks were still functioning fine. I was an early adopter of ZFS - first under OpenSolaris, then under OpenIndiana, then (and now) under FreeBSD, so I thought I understand what "initial stable release" meant but it is clear that what ZFS devs consider to be stable and what btrfs devs consider to be stable are leagues apart.
* I was able to use forensic tools and low-level fs-agnostic recovery methodologies to get some of the important stuff back, but the btrfs volumes were completely lost.
Either way very few workloads get anywhere near wearing out an SSD, and the upsides of CoW features are almost always much higher than the risk of wearing out a drive. I'd say they fit just fine on an SSD.
I personally use btrfs raid-1 setups and have survived actual device failures without data loss. However, I also perform regular backups so I'm not overly concerned about "eat my data" bugs in a filesystem either.
The kernel wiki says the following :
RAID56
Some fixes went to 4.12, namely scrub and auto-repair
fixes. Feature marked as mostly OK for now.
Further fixes to raid56 related code are applied each
release. The write hole is the last missing part,
preliminary patches have been posted but needed to be
reworked. The parity not checksummed note has been
removed.Edit: the main risk with Sid is with proprietary software, such as Zoom. There's always a fix somewhere, but fiddling around can be distracting.
(I.e. things like LXC and multipass)
I am pleasantly surprised by how cleanly Snaps uninstall though.
> I am pleasantly surprised by how cleanly Snaps uninstall though.
These two things are connected :)
(mainly because of better security and that I use Ubuntu and debian images instead of alpine anyway)
(In increasing order of effort)
Sandboxing user applications is a completely orthogonal topic.
You can sandbox OS-installed applications or other applications. With the same tools.
Both options equally require custom configuration depending on what files and directories you want to allow or restrict access to (and syscalls and so on).
Fine grained permission are a personal choice and both firejail and nspawn make it quite easy to configure.