Have you considered other distros? I’ve had lots of success with the immutable fedora variants, which offer great stability and NVIDIA drivers in the base system. If you need apt, you create a new Debian container in the box buddy and make that container be your default when opening a terminal.

Gnome variant: https://projectbluefin.io/

KDE variant: https://getaurora.dev/

Gaming variant: https://bazzite.gg/

They are all the same distro with different desktop setup and default apps. You can install one of them and seamlessly switch to another one without losing any data.

Graphene only works on Pixel phones. Graphene is more private and secure, but might be too many issues for people who do not care about such things that much. Lineage has better support for different phone models, and you can make it just like a normal Android OS, that just happens to provide updates for your phone years after the manufacturer stops sending them.

Neither of them is better than the other, it’s just about your priorities. Get Graphene if you have a Pixel and you value privacy and are willing to tinker with it a bit if some apps don’t work.

Not a sysadmin, but a programmer. My work machines have been:

• 2003-2008 Windows 7
• 2008-2011 Ubuntu
• 2011-2019 Arch
• 2019-2024 NixOS

Probably going to keep using NixOS. This is a very cool OS.

That is correct.

https://www.phoronix.com/review/amd-ryzen-9950x-9900x

His job is to not get the maintainers to agree, but his job definitely is to bark a bit if somebody behaves like Ted.

It might even be Rust is not meant for Linux kernel and it will never happen. Or it happens in the driver layers, but stays out from the core. We do not know yet. The concern Ted is raising is definitely valid: if the C APIs change, people who work daily in the C code cannot spent cycles fixing the Rust APIs. These people have their day jobs which pays them to maintain these subsystems, and it is at least not yet clear will these employers fund rewriting anything in Rust. There are tens of filesystems in Linux, with lifetimes passing around that are not documented and might not work in Rust.

Note: I’m a Rust dev for the past 10 years, and I follow this discussion with high interest.

Yeah. Isn’t it funny that the most popular file system in the world has such a codebase, and it is not even well documented how it works!

I have my reasons to choose XFS or bcachefs with my machines.

Yes and no. Linus can yell to people and he does, he can force his say as he has been recently doing by expecting sched_ext to land in 6.12. BUT. Linux is a bazaar, it’s so big and there are so many different factions forcing them to do anything is going to take a long time. Lots of different teams are working on Linux, with their own priorities.

The borrow checker is exactly what the kernel needs.

Ted is the maintainer of ext4 and there are not many people in the world who understand this code.

For Rust to succeed, it has to get the subsystem maintainers to agree. It is going to be many years of petting very angry bobcats…

And that is not even the worst I’ve heard, makes you a bit numb if you follow LKML.

Me neither, but the risk is there and well documented.

The point was, ZFS is not great as your normal laptop/workstation filesystem. It kind of requires a certain setup, can be slow in certain kinds of workflows, expects disks of same size and is never available immediately for the latest kernel version. Nowadays you actually can add more disks to a pool, but for a very long time you needed to build a new one. Adding a larger disk to a pool will still not resize it, untill all the disks are replaced.

It shines with steady and stable raid arrays, which are designed to a certain size and never touched after they are built. I would never use it in my workstation, and this is the point where bcachefs gets interesting.

But scrub is not fsck. It just goes through the checksums and corrects if needed. That’s why you need ECC ram so the checksums are always correct. If you get any other issues with the fs, like a power off when syncing a raidz2, there is a chance of an error that scrub cannot fix. Fsck does many other things to fix a filesystem…

So basically a typical zfs installation is with UPS, and I would avoid using it on my laptop just because it kind of needs ECC ram and you should always unmount it cleanly.

This is the spot where bcachefs comes into place. It will implement whatever we love about zfs, but also be kind of feasible for mobile devices. And its fsck is pretty good already, it even gets online checks in 6.11.

Don’t get me wrong, my NAS has and will have zfs because it just works and I don’t usually need to touch it. The NAS sits next to UPS…

It is only in TLS where you have to disable compression, not in HTTP.

https://security.stackexchange.com/questions/19911/crime-how-to-beat-the-beast-successor/19914#19914

Could you explain how a CRIME attack can be done to a disk?

I mean… If you have a ton of raw photos in one directory, you can enable the highest compression rate with zstd to it. Every other directory has lz4 with the fastest compression. Your pics take much less space, but the directory will be slower to read and write.

For me the reason was that I wanted encryption, raid1 and compression with a mainlined filesystem to my workstation. Btrfs doesn’t have encryption, so you need to do it with luks to an mdadm raid, and build btrfs on top of that. Luks on mdadm raid is known to be slow, and in general not a great idea.

ZFS has raid levels, encryption and compression, but doesn’t have fsck. So you better have an UPS for your workstation for electric outages. If you do not unmount a ZFS volume cleanly, there’s a risk of data loss. ZFS also has a weird license, so you will never get it with mainline Linux kernel. And if you install the module separately, you’re not able to update to the latest kernel before ZFS supports it.

Bcachefs has all of this. And it’s supposed to be faster than ZFS and btrfs. In a few years it can really be the golden Linux filesystem recommended for everybody. I sure hope Kent gets some more help and stops picking fights with Linus before that.

One of the best filesystem codebases out there. Really a top notch file system if you don’t need to resize it once it’s created. It is a write through, not copy on write, so some features such as snapshots are not possible using XFS. If you don’t care about features found in btrfs, zfs or bcachefs, and you don’t need to resize the partition after creating it, XFS is a solid and very fast choice.

Ext4 codebase is known to be very complex and some people say even scary. It just works because everybody’s using it and bugs have been fixed years ago.

It kind of fails with certain protocols. I once wrote an async MSSQL client for Rust, and some data doesn’t say its size in the headers. So this kind of forced the business logic to be async too.

Never had one, just partied in the uni and dropped out :D

So basically your typical network protocol is something that converts an async stream of bytes into things like Postgres Row objects. What you do then is you write a synchronous library that does the byte conversion, then you write an asynchronous library that talks with the database with async functions, but most of the business logic is sync for converting the data coming from the async pipe.

Now, this can also be done in a higher level application. You do a server that is by nature async in 2024. Write the server part in async, and implement a sync set of mapping functions which take a request coming in and returns a response. This can be sync. If you need a database, this sync set of functions maps a request to a database query, and your async code can then call the database with the query. Another set of sync functions maps the database result into http response. No need to color everything async.

The good part with this approach is that if you want to make a completely sync version of this library or application, you just rewrite the async IO parts and can reuse all the protocol business logic. And you can provide sync and async versions of your library too!

That’s why you write your protocol as a sync library, then implement the async IO separately and mapping the data over the protocol modules.

Yep, windows kernel has a ton of Rust code already, even some of its syscalls are made in Rust. Linux kernel is getting a new GPU driver for NVIDIA written in Rust, and GPU driver for removed M-series also written in Rust. removed is hiring Rust devs, so is Amazon, Meta, Google…

In the startup space it’s been quite good with Rust for some time. I’ve been writing production code with it for almost a decade. It is not a fad anymore.

A productive, safe and fun language to write with excellent tooling, and we are just getting started.