Stronger compartmentalization

Yeah, this one is on Kent… again.

He posted on Patreon that there’ll be a DKMS module. In my opinion, this should have been the option from the very beginning and upstreaming at a later point in time. It would have avoided a lot of drama. And now bcachefs is kind of tainted. The only way I ever see it back in mainline is there is an independent downstream of Kent’s kernel that has no connection to him whatsoever.

Shame because I had very good experience with the filesystem. Definitely better than when btrfs was new. But Linus is unfortunately right; Kent is unable to follow agreed collaboration rules.

Unfortunate situation that could have been avoided entirely. Though I don’t want to be too harsh on Kent. He spent a lot of time and work on bcachefs and it’s his most important project. As such, he’s more passionate about all of this. But the same can be said for Linus and the kernel on the other side.

PipeWire my beloved 😍

LFS is a distro in the sense that a cookbook is a buffet

I think it can be assumed that of a machine has sudo, it also has touch.

Plex has better security, federates and shares with other plex servers and generally is less hands-on for transcoding.

Regarding security, it’d be interesting to see how secure it actually is. Yeah, the individual endpoints might be protected better, but is Plex the company maybe a single point of failure?

Why?

Allows you to scroll through / view a text file in the terminal.

All the good stuff available and you choose a POSIX shell? To each their own I guess.

Granted, I still prefer it to PowerShell, but only in how it feels, not conceptually.

I don’t agree with your assessment really as I don’t see the core experience declining.

But also, it’s a free project and people are putting in their time wherever they want; I don’t think the project would reject a submission for something based on “we’re doing too much” if it’s within the scope of a desktop environment.

Admirable dedication to the cause

Godspeed, keep the hacking spirit alive

Either my Ansible knowledge is too limited which is entirely possible, or you can’t do stuff there that’s possible with Nix. Let’s stay go with my example that you have something that requires changes in PAM. So you write an Ansible file installing the package (which is distribution-specific, so you’re losing one advantage you had over NixOS), enable the service and add your entries to the respective PAM file (e.g. login because you want to enable user authentication against kanidm on your machine). The ordering in these files matter. Sure you have insertbefore and insertafter for lineinfile and blockinfile, but this basically requires you to know the rest of the file in advance… not a problem if your system is always the same, but you don’t have the flexibility and composability that Nix offers.

I dunno man. I spent way less time configuring my machines on NixOS because it just works. But in fairness, that is after I have spent a lot of time learning it (compared to classic systems that is, not a lot compared to NixOS maintainers who write way better module than I do). Now that there is a foundation, I just run the updates. It’s almost scarily stable. And the ability to group related settings together is such a bliss because you no longer wonder about “what did I do to enable X”, just open the file, it’s all in one place. Stuff that could be three completely different things (e.g. a service specific config file, a PAM entry and the service activation itself in effectively 5 lines. Want to do something for multiple services? Just map over their list. Etc

I happily used Arch for 15 years and after trying NixOS on a decommissioned machine for one day I switched over everything as fast as possible. And I did try out Ansible on Arch, so it’s not like I didn’t try management via a tool. But using a system like NixOS just solves sooo many potential issues.

It obviously comes with downsides, for example there is no quick configuration change. Changing something small requires another evaluation. Still worth it

Yup just need to pick it up from your local rescue shelter

Did you know that the suffix for nix documentation files is, coincidentally, .nix?

The issue is not only complexity, though it does play a role. You can also run into issues with pure text parsing, especially when whitespace is involved. The IP thing is a very classic example in my opinion, and while whitespace might not be an issue there (more common with filenames), the queries you find online in my opinion aren’t less complex.

Normal CLI output is often meant to be consumed by humans, so the data presentation requirements are different. Then you find out that an assumption you made isn’t true (e.g. due to LANG indicating a non-English language) and suddenly your matching rules don’t fit.

There are just a lot of pitfalls that can make things go subtly wrong, which is why parsing general CLI output that’s not intended to be parsed is often advised against. It doesn’t mean that it will go wrong.

Regarding Python, I think it has a place when you do what I’d call data set processing, while what I talk about is shell plumbing. They can both use JSON, but the tools are probably not the same.

It’s a cool shell, I like ita lot more since I found out you can use ? to mark a field optional

It’s true that compared to the other utilities, it’s rather new. First release was almost 13 years ago. awk, which I think is the closest comparison, on the other hand turns 50 in 2027… though new awk is only 40.

Thanks, I never used it and had forgotten about it until now.