Second hand market also drives demand.

No, you misunderstood me I think. I’m happy to throw money at Jolla, and I have done so.

I’m not impressed about people complaining that Sailfish is ”proprietary” while handing money over to Google.

The Graphene team are probably fantastic people.

The toenail-slingers are usually not writing that much code.

Oh shut up.

This is why we can’t have nice things. Everytime something took a step in the right direction the past two decades in open source, someone started throwing toenails around, scaring off people.

And while you throw ”proprietary” around with the toenails, you are the one here telling people to throw money at Google to buy a pixel. At least put your money where your mouth is and buy libre hardware.

They most likely run smaller pools and have their redundancy and replication provided by the application layers on top, replicating everything globally. The larger you go in scale, the further up in the stack you can move your redundancy and the less you need to care about resilience at the lower levels of abstraction.

ZFS is fairly slow on SSDs and BTRFS will probably beat it in a drag race. But ZFS won’t loose your data. Basically, if you want between a handful TB and a few PB stored with high reliability on a single system, along with ”modest” performance requirements, ZFS is king.

As for the defaults - BTRFS isn’t licence encumbered like ZFS, so BTRFS can be more easily integrated. Additionally, ZFS performs best when it can use a fairly large hunk of RAM for caching - not ideal for most people. One GB RAM per TB usable disk is the usual recommendation here, but less usually works fine. It also doesn’t use the ”normal” page cache, so the cache doesn’t behave in a manner people are used to.

ZFS is a filesystem for when you actually care about your data, not something you use as a boot drive, so something else makes sense as a default. Most ZFS deployments I’ve seen just boot from any old ext4 drive. As I said, BTRFS plays in the same league as Ext4 and XFS - boot drives and small deployments. ZFS meanwhile will happily swallow a few enclosures of SAS-drives into a single filesystem and never loose a bit.

tl;dr If you want reasonable data resilience and want raid 1 - BTRFS should work fine. You get some checksumming and modern things. As soon as you go above two drives and want to run raid5/6 you really want to use ZFS.

Look, there is a reason everyone who actually knows this stuff use ZFS. A good reason. ZFS is really fucking good and BTRFS has absolutely nothing on it. It’s a toy in comparison. ZFS is the gold standard in this class.

You have four sane options:

• mdraid raid5 with BTRFS on top. Raid5 on BTRFS still isn’t stable as far as I know, not even in 2026.
• Mirror or triple mirror with mdraid. Have the third drive in the pool as more redundancy or outside the pool as separate unraided filesystem.
• Same as above, but BTRFS. Raid1 is stable.
• ZFS RaidZ1 (=raid5)

(Not sure about bit rot recovery when running BTRFS on mdraid. All variants should at least have bit rot detection.)

To reiterate, every storage professional I know has a ZFS-pool at home (and probably everywhere else they can have it, including production pools). They group BTRFS with Ext3, if they even know about it. When I built my home server, the distro and hardware was selected around running ZFS. Distros without good support for ZFS were disregarded right away.

I can only offer you garbage specs along with really shitty build quality for 1kEUR. It’s certified as ”not a direct fire hazard”. Take it or leave it. (/s)

I have high hopes for framework, but last time I was in the market they still had some things to resolve.

The M-series hardware is locked down and absofuckinglutely proprietary and locked down and most likely horrible to repair.

But holy shit, every other laptop I’ve ever used looks and feels like a cheap toy in comparison. Buggy firmware that can barely sleep, with shitty drivers from the cheapest components they could find. Battery life in low single digits. The old ThinkPads are kinda up there in perceived ”build quality”, but I haven’t seen any other laptop that’s even close to a modern macbook. Please HP, Dell, Lenovo, Framework or whoever , just give me a functional high quality laptop. I’ll pay.

Moving people from closed commercial offerings onto something self hosted is enough work without gatekeeping US open source projects, even if they are flawed. If we want to move normal people away from the commercial offerings onto something better, we can’t do things like that. Better save such warnings for when they are actually needed (”Project X has been dead for five years and is full of security holes, you should migrate to project Y instead”). Keep the experience positive regardless.

You do you, but different people have differing requirements and preferences. Don’t scare them away please.

Because dockers record with regards to security is questionable, and some people like to get automatic updates from their distro. For me personally, I think the design of Docker is absolute garbage. Containers are fine, but Docker is not the correct mechanism for it. (It’s also nothing new, see BSD jails and Solaris zones.)

Immich on Nixos works perfectly, and I also get automatic updates.

Software compatibility is a problem on X as well, so I’m extrapolating. I don’t expect the situation to get better though. I’ve managed software that caused fucking kernel panics unless it ran on Gnome. The support window for this type of software is extremely narrow and some vendors will tell you to go pound sand unless you run exactly what they want.

I’m no longer working with either educational or research IT, so at least it’s someone else’s problem.

As for ThinLinc, their customers have asked about what their plan is for the past decade, but to quote them: ”Fundamentally, Wayland is not compatible with remote desktops in its core design.” (And that was made clear by everyone back in 2008)

Edit: tangentially related, the only reasonable way to run VNC now against Wayland is to use the tightly coupled VNC-server within the compositor (as you want intel on window placements and redraws and such, encoding the framebuffer is just bad). If you want to build a system on top of that, you need to integrate with every compositor separately, even though they all support ”VNC” in some capacity. The result is that vendors will go for the common denominatior, which is running in a VM and grabbing the framebuffer from the hypervisor. The user experience is absolute hot garbage compared to TigerVNC on X.

It’s great that most showstoppers are fixed now. Seventeen years later.

But I’ll bite: Viable software rendered and/or hardware accelerated remote deskop support with load balancing and multiple users per server (headless and GPU-less). So far - maybe possible. But then you need to allow different users to select different desktop environments (due to either user preferences or actual business requirements). All this may be technically possible, but the architecture of Wayland makes this very hard to implement and support in practice. And if you get it going, the hard focus on GPU acceleration yields an extreme cost increase, as you now need to buy expensive Nvidia-GPUs for VDI with even more expensive licenses. Every frame can’t be perfect over a WAN link.

This is trivial with X, multiple commercially supported solutions exist, see for example Thinlinc. This is deployable in literally ten minutes. Battle tested and works well. I know of multiple institutional users actively selecting X in current greenfield deployments due to this, rolling out to thousands of users in well funded high profile projects.

As for the KDE showstopper list - that’s exactly my point. I can’t put my showstoppers in a single place, I need to report to KDE, Gnome and wlroots and then track all of them, that’s the huge architectural flaw here. We can barely get commercial vendors to interact with a single project, and the Wayland architecture requires commercial vendors to interact with a shitton of issue trackers and different APIs (apparently also dbus). Suddenly you have a CAD suite that only works on KDE and some FEM software that only runs on a particular version of Gnome, with a user that wants both running at the same time. I don’t care about how well KDE works. I care that users can run the software they need, the desktop environment is just a tool to do that. The fragmentation between compositors really fucks this up by coupling software to display manager. Eventually, this will focus commercial efforts on the biggest commercial desktop environment (i.e. whatever RHEL uses), leaving the rest behind.

(Fun story, one of my colleagues using Wayland had a postit with ”DO NOT TURN OFF” on his monitor the entire pandemic - his VNC session died if the DisplayPort link went down.)

Oh no, people wrote lists like that 17 years ago. That’s the fun part. We have been complaining all along.

It’s hilarious that all of this was foreseen 17 years ago by basically everyone, and here is a nice list providing just those exact points. I’ve never seen a better structured ”told ya so” in my life.

The point isn’t that the features are there or not, but how horrendously fragmented the ecosystem is. Implementing anything trying to use that mess of API surface would be insane to attempt for any open source project, even when ignoring that the compositors are still moving targets.

(Also, holy shit the Gnome people really wants everyone to use dbus for everything.)

Edit: 17 years. Seventeen years. This is what we got. While the list is status quo, it’s telling that it took 17 years to implement most of the features expected of a display server back in the last millenium. Most features, but not all.

That list is hilarious. I especially love how gnome just gives up on Wayland protocols and wants everyone to run a sidechannel over dbus instead.

This is why we can’t have nice things.

Because instead of just using a common well defined API, every developer is supposed to ”work together with Wayland compositors”, of which there are many, none of which are up to feature parity with X. Working together with the (at least) three major compositors is far top much work for most projects, if you can even get them on board.

Every compositor must reimplement everything previously covered by third party software, or at least define and reimplement APIs to cover that functionality. We have been screaming about this obvious design fuckup since Wayland was first introduced, but nooo, every frame is perfect.

Take a look at https://arcan-fe.com/ for what a properly architected display server could look like instead of the mess we currently have with Wayland. I’m holding off on moving to Wayland for many reasons, and it wouldn’t surprise me if Arcan becomes mature and fully usable before Wayland. If I get to place a bet on either on Wayland or a few guys in a basement with a proper architecture, I know what I’ll put my money on.

Last I tried, foobar worked well under Wine

Friends don’t let friends run erasure coding on BTRFS.

Personally, I don’t run anything on BTRFS. I like having my data intact and I also want two parity drives in my pools.

Oh, have they started working on aviation grade test harnesses?

SQLite will rule our world for a long time, far after we are gone.

SQLite is one of the very few open source projects with a reasonable plan for monetisation.

• Do you want to use one of the proprietary extensions? Fork up a few thousand. No biggie.
• Do you operate in a regulated industry (aviation) and need access to the 100% coverage test suite along with a paper trail? Fork up ”Call us”.
• Is your company insisting that you only use licensed or supported software? Well, you can apparently pay them for a licence to their public domain software.

Basically, squeeze regulated industries, hard.

I’m all for open source, but at some point developers should stop acting surprised when people use their work at the edges of the licence terms (Looking at you Mongo, Redis and Hashicorp). As for developers running projects on their free time, maybe start setting boundaries? The only reason companies aren’t paying is because they know they can get away withholding money, because some sucker will step up and do it for free, ”for the greater good”. Stop letting them get it for free.

Looks like RedHat is kinda going in this direction (pay to get a paper trail saying a CVE-number is patched), and basically always have been squeezing regulated industry. Say what you want about that strategy, it’s at least financially viable long term. (Again, looking at you Hashicorp, Redis, Mongo, Minio and friends)