Software to allow partitioning gpu resources among multiple virtual machines instead of just assigning the one PCIe device to a single VM. Very useful for having a single GPU do 3D acceleration on a host and multiple guests at the same time.

Your personal files e.g. ~/Documents are not recreated, you’ll still need backups of those.

caveats are you’ve got to use:

• home-manager to generate your dotfiles.
• something akin to sops to generate and securely store your private keys and secrets.

But all this can be written in the one flake, so yes nixos-install --flake <GIT URL>#<HOSTNAME> Is sufficient for me to rebuild my desktop, laptop or server from the same repository.

I’ve never used Gentoo, and I’m sure there are other methods of achieving the same level of reproducibility but I don’t know what they are.

Nixos can be as modifiable as Gentoo with the caveat being it’s a massive pain in the ass to do some things. I have a flake for making aarch64-musl systems which has been an endeavour, and… It works? I have a running system that works on 2 different SoCs. I do have to compile everything quite often though.

There are efforts to recreate Nixos without systemd, but that’s a huge effort; because it’s very “infrastructure as code”, you have to change a lot of code where editing a build script would’ve sufficed on arch/Gentoo.

As for nix vs guix, guix was described to me as “if you only ever want to write in scheme”, whereas nix feels much more like a means to an end with practical compromises spattered throughout.

Perhaps, but when I accidentally nuked my system by dd’ing to one of the hard drives, being able to install the exact same system back onto it by pointing the installer to my git repository was an excellent experience.

• Lisp is responsible for most of the parts of programming widely considered enjoyable.

• Fortran is still often used in some of our most performant libraries.

• POSIX shell was one of the most important parts of unix-like systems becoming how they are today, and it’s compatibility is still an invaluable glue for tying programs written in the 90’s to programs written today.

Statically linking is absolutely a tool we should use far more often, and one we should get better at supporting.

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.

Apparently the tested interface that wasn’t suitable was CAMM2.

Hopefully either the interface or the manufacturing process improves so that future products can use CAMM2 for this kind of bandwidth.

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.

I’m concerned that the effect would be less of “having a controlling share in many companies” and more “having your fund be deeply tied to the success of these companies”.

If the size of the fund becomes a metric of success, whoever is in charge of it is going to be disinclined to force a company to make an unprofitable choice, even if it’s the right thing to do.

A wealth fund on its own doesn’t create wealth; like any other tax, it’s a redistribution mechanism. it’s the implementation details that matter.

Take three revenue sources:

1. Tariffs & VAT: extract wealth on a per purchase basis, so the primary payer is somebody who spends most of their revenue on stuff; normal people & businesses with relatively high OPEX (small business that make physical stuff rather than services) or have overseas suppliers.

2. Land value tax: a rent on owning land based on its value, primary payer are people and companies who own lots of expensive land; often rent-seekers themselves.

3. Resource revenue tax: typically large companies as they’re the only ones that can afford the scale to profitably extract resources.

And some potential expenses:

1. Retirement pension fund: tends to benefit pensioners (duh). Can also benefit workers, whos taxes tend to pay for the pensions of their (gran)parents. whether that actually will translate into less taxes, or those taxes just go elsewhere is another matter.

2. Government CAPEX: benefits are spread pretty evenly over everyone who uses govt services (depending on the purchase; a school is more useful than a cop shop). A lesser-known beneficiary are politicians; periodic infrastructure projects get more consistent positive press than e.g. a well funded pension system.

3. Recurring helicopter money: I won’t call it a UBI, because that would require a truly massive fund; but a stipend for every resident human would primarily benefit parents who’s wealth doesn’t normally grow when they have kids. Other than that, it’s hard to say how this would play out; will it put less pressure on low wage workers? Will it just be gobbled up by rent-seekers? A flat tax is considered a burden on the poor, so it makes some sense that what is basically a negative flat tax would have the primary beneficiary be the poorest among us. It may harm the transient, undocumented or otherwise unregistered workers by omission though.

4. Musk’s pocketbook: if it gets full enough surely some will trickle down, right?

One thing that it will definitely do is swell up rich people’s yacht money the stock market since that’s where it’s stored. This directly benefits capital as a means of wealth creation over labour but considering how many yachts are already there the impact wouldn’t be substantial.

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.