You should maybe read about the use cases for deduplication before using it. Here’s one recent article:

https://despairlabs.com/blog/posts/2024-10-27-openzfs-dedup-is-good-dont-use-it/

If you mostly store legit Blu-ray rips, the answer is probably no, you should not use zfs deduplication.

Yeah… So I’m in Berlin, and in Germany the internet operators finally are building fiber everywhere. The provider who lays the fiber to our street is Deutsche Telekom, and they promise to pay everything: laying the fiber, bringing it to our house and bringing the fiber to every apartment for a two year monopoly on fiber internet after which it’s up for competition using their cables. What needs to happen next is our landlord (a Swiss company) and house management company to agree on these guys to come in, put little fiber dividers to every floor and drill a hole to the walls so we get the fiber cable to our apartment.

Of course this being Germany, they are very slow on agreeing on that, we might need to go to court and for sure we need to talk to our neighbors who own their apartments to push them a bit. I’d expect us to get the connection maybe before end of 2025. But eventually it will happen…

I am doing exactly the same as what the OP is doing. In addition to that, I will unify my beelink mini PC proxmox server and our old Intel atom NAS into one rack server with AMD EPYC, proxmox and truenas in a VM.

I sure hope our landlord and the Internet operator can agree on the operator finally bringing fiber cables to all apartments. Then I would have fast enough uplink to my homelab.

Linux kernel updated to 64 bit time quite recently. In 2038 I can guarantee somebody in a very serious business is still using an ancient RHEL and will have issues.

And not using 32-bit integers to calculate time. Which is still a thing in many many many codebases written in C or C++…

I can validate this. I work as the IT ops guy for every Fortune 500 company and we only use RAID-0 for backups.

Yeah, I’m also one of these people silently enjoying systemd and wayland. Every now and then there’s fuzz on one of these. I shrug, and move on still enjoying both of them.

Rust and Cargo enters the room.

128 GB here which runs out if I compile the complete project at work with -j32. And this sucks because 128 GB right now means the RAM cannot run super fast, meaning it is a bottleneck to any modern Ryzen…

We’ve been using Linear in my latest company and it is actually quite good. No bullshit fast UI, boards, issues linking with Git, a support that can take a feature request that is often implemented in a week or two after asking it.

In my experience, nix works exceptionally well with Rust. Python and JavaScript are nastier, especially if the libraries use C extensions.

Zenarmor ftw.

Musl can be a bit annoying compilation target sometimes. Usually it works but I’ve debugged bugs a few times that were due to musl target.

I prefer my distro with glibc…

But do not run Linux, the kernel.

I’m too old to rant about systemd :D

Wtf is run0

https://www.freedesktop.org/software/systemd/man/devel/run0.html

Edit: Is that nyx flake made by the same guys as the Chaotic AUR repo for arch?

Looks like it if you check from GitHub.

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.