I just want a diversity of architecture styles to be common, I love areas that are an eclectic mix of styles; it makes me feel like so many different people care about the area.

C because it’s what is used for low-end linux & embedded work.

Shell scripts because they’re the caulk that holds a Linux distro together.

Rust when possible because it’s how I wish systems programming could be.

It feels like no matter where I move to, a communist seems to move in at the exact same time… It’s uncanny.

Tailscale edits /etc/resolv.conf, since your DNS isn’t working start by making sure that file is how the archwiki suggests rather than what tailscale changes it to.

An uninstalled tailscale may still have left that file modified.

The specifics matter, but generally no.

When an actual fraud investigation is being done into something major like a casino laundering money, my government tends not to turn it into a media circus until after investigations are underway.

When a politician tells me they want to ‘tackle fraud’, especially welfare fraud, I hear “I want to arrest people for being poor”. It sounds like a dog-whistle to me, because every time I hear it used, it’s by people bearing a “the cruelty is the point” mindset.

I wish.

It was a bcachefs array with data replicas being a mix of 1,2 & 4 depending on what was most important, but thankfully I had the foresight to set metadata to be mirrored for all 4 drives.

I didn’t get the good fortune of only having to do a resilver, but all I really had to do was fsck to remove references to non-existent nodes until the system would mount read-only, then back it up and rebuild it.

NixOS did save my bacon re: being able to get back to work on the same system by morning.

A few months ago I accidentally dd’d ~3GiB to the beginning of one of the drives in a 4 drive array… That was fun to rebuild.

It seems a lot of new developers want to do some things differently; old guard devs can either make some compromises, or accept that fewer new devs will want to be part of upstream.

Dunno man, when what the dev of 30+ years said was more or less “fuck off”, it seems that advice was in fact heeded

It’s a chicken and egg problem; manufacturers aren’t going to care to upstream drivers if not enough of their users are on Linux, which slows new hardware. It’s much better than it was, but still ongoing.

Amd’s 7000 series amdgpu driver was busted in several ways for like a year post launch, and is still missing tunables for many GPU features.

Manufacturers are capable of making out of tree and unfree modules, but honestly I prefer the slow progress if it means most driver work stays in-tree.

I actually think this is more an attempt to exploit Trump’s worldview; he’s well-known to view inter-state relationships as purely transactional, and from that lens it seems like a good deal.

Thing is, depending on how the war goes either Russia or the US will take everything they possibly can from Ukraine; it may well be that offering Trump something the US was probably going to try to take anyway is just about the smartest way to turn somebody who was initially hostile to continued aid into someone personally invested in the outcome.

Either Linus or Greg K-H, likely after feedback from many others.

We should be looking at his given reasons, not making assumptions based on some ineffable set of considerations that he might have.

Christof’s given reason of complexity is sensible, it’s also one already considered when allowing R4L in the first place; adding rust language support has been deemed worth the additional complexity.

~/.config is probably a poor comparison on my part; it’s management is actually done by home-manager rather than Nixos proper, and I can’t think of another OS that fills this same role.

Nixos generates (for example) /etc/systemd/network to a path in /nix/store and symlinks it to it’s appropriate locations. After the files are generated the appropriate /nix/store paths are (re-mounted? Over-mounted? I’m not sure the implementation) made read-only (by default), but anything that isn’t generated is absolutely both mutable and untracked, and that “not tracking everything in /etc” is more what I’m going on about.

If you use Nixos as intended (when you find that a package is lacking a config option you want, create your own nix option internally) the distro is effectively immutable, but if you use Nixos for anything moderately complex that changes frequently e.g. a desktop os, you eventually run into the choice: become competent enough to basically be a nixpkgs contributor, or abandon absolute immutability.

I think the first option is worth it, and did go down that route, but it is unreasonable to expect the average Linux consumer to do so, and so something like fedora atomic is going to remain more “immutable” for them than nixos.

This need to git gud is thankfully lessening with every commit to nixpkgs, and most people can already get to most places without writing their own set of nix options or learning how to parse //random markup language// into nix, but you’ll eventually run into the barrier.

I’d argue it’s closer to a mutable distro than an immutable one.

Nixos tends to lean on the term reproducible instead of immutable, because you can have settings (e.g files in /etc & ~/.config) changed outside of nix’s purview, it just won’t be reproducible and may be overwritten by nix.

You can build an ‘immutable’ environment on nix, but rather than storing changes as transactions like rpm-ostree, it’ll modify path in /nix/store and symlink it. Sure, you can store the internal representation of those changes in a git repo, but that is not the same thing as the changes themselves; if the nixpkgs implementation of a config option changes, the translation on your machine does too.

Is that why they prevented it from being open sourced? I thought I read a while back that they just wanted to keep the code in-house.

It definitely has its roots in Debian, but when you need to use that weird closed source application for work, if it has a “supported” (for a given value of support) Linux distro it’ll be Ubuntu.

I personally prefer straight Debian myself, or something entirely different but when asked for a recommendation by friends it’s Ubuntu.

Cost to manufacture is not more than wages, but cost to purchase a good is always more than the total cost of labour needed to produce it, so long as profit exists.

The money isn’t free so much as redistributed from taxation elsewhere, think of it as the same as subsidising industry except only to the workers of that industry (instead giving it to owners and expecting the savings to trickle downwards). You could also consider it an income tax rebate with more fine-grained control of who gets it.

It doesn’t seem particularly ground-breaking of a concept; I see the value in investing money into necessary but unprofitable industry though my concern is that if you subsidise wages of a business with a profit incentive, management may lower wages to compensate.

I disagree about rejecting funding from intelligence agencies. I hate the concept of their existence, as well as what orgs like the CIA have done (and proceed to do) but given the fact of their existence, they do have legitimate reasons (in this case I mean reasons that align with Signal’s current goals rather than in order to change them) to fund Signal, and if that results in funding secure software, all the better.

I used ZFS with Arch for a while, the volume manager was what I’d call the largest benefit; in my opinion nothing else comes close to being as useful and well integrated.

I stopped because ZFS incompatibility with recent kernels (which I needed for GPU reasons) made me have to rescue my system more often than was ideal.

Some other minor downsides:

• boot can take ages due to ZFS using udev-settle.
• deduplication status is… Complicated.
• you’re kind-of stuck with the performance of your slowest vdev; L2ARC & a metadata device don’t really compensate well for a zpool that is predominantly a raid-z2 of spinning rust.