Right if you have applications with rt constraints, you’ll obviously need a rt-capable OS but that’s more a matter of it being available as a feature, rather than being performant enough.

Uh no, they have like 4 or 5 different naming schemes in currently relevant CPUs. The one you explained isn’t even the most current one and most of them aren’t even unambiguous.

For someone not intimately familiar with AMD’s line-up, the only good way to figure out the CPU core IP used in any given processor is to look it up for that specific processor.

Nerds like you and I have followed it over the years and can immediately tell that a 5300g is zen2 while the 5400g is clearly zen3 and that Ryzen AI 300 or whatever awful name they thought of is Zen5 but by the time someone unfamiliar followed a flow chart to figure that out, they might as well look up the specific CPU.

The kernel is one of the least important components when it comes to performance.

Kernel tweaks can eek out a couple percent here or there for your specific task (while likely regressing in others) but nothing really significant.

FWIW though, we have lqx and rt variants in NixOS (though rt is mainline now with 6.12).

Oh, I know; I have commit access to Nixpkgs ;)

I was just commenting on the way they’ve styled their Nix code here.

That looks very lispy, is that intentional?

Having a record which defines exactly what to fetch is the necessary condition, not the sufficient condition.

The actual artifacts fetched to disk must be stable, not just the record.

That’d hit the source fetcher just as much. That’s an issue on a different layer.

That will only work if it is reproducible. Given that it downloads random shit from the internet, that’s unlikely.

To package this properly, you need to build a derivation that can use a lock file to bundle the deps into some sort of stable format. This is how go’s vendoring works.

As always, stable releases are about how frequently breaking changes are introduced. If breaking changes potentially happening every day is fine for you, you can use unstable. For many use-cases however, you want some agency over when exactly breaking changes are introduced as point releases a la NixOS provide you with a 1 month window to migrate for each release.

With efficient cpus and lack of dedicated gpus I doubt the 4W of RAM is really that much of a battery drain.

What? If anything, it’d be more drain relatively speaking.

4W is quite a lot if you consider that a decently efficient laptop should draw 5-8W at idle max.

This should allow averagenon-technical users to keep up with development, without reading Github comments or knowing how to program.

;)

https://nixos.org/manual/nixpkgs/stable/#part-stdenv

robust stop and resume of download

You can stop/resume downloads via HTTP too. That’s up to the client to implement.

increased download speed with using several http and torrent sources at the same time

Again, this is a commercial CDN. Speed is practically infinite. Without the rather long ramp-up time too.

downloading from peers from within the same network

That sounds like a micro-optimisation for an edge-case.

automatic checksum calculation and redownlaod if needed

Not really necessary for an installer ISO downloaded via HTTPS.

Sorry that I asked. Seems that you feel very offensed by my question.

???

As mentioned, one of the reasons torrents don’t make sense here is that the ISOs change quite frequently. I don’t have exact numbers here but there’s nothing preventing them from changing every single day. The current ISO is only two days old.

Every seeder would have to discard the old ISO and re-download an entirely new ISO every few days or so.

Given that we need the CDN anyways, torrents just simply don’t make sense.

It doesn’t really make sense to use torrents here. We’ve got a commercial CDN serving these files for us and they change basically every day or so.

furry anime girl

Welcome to the Nix community I guess :D

Not physical unfortunately but I know of https://leanpub.com/nixos-in-production by @GabriellaG439@tech.lgbt.

https://openbenchmarking.org/ for performance on Linux but it’s nowhere near as usable.

You gotta commend UB for their data presentation, it just sucks that the data is completely worthless.

I’ve heard that the original Linux kernel binaries+blobs are pretty huge

The kernel is <10MB and the initrd <20MB. “Pretty huge” is relative here.

You could override your kernel and strip stuff out of the initrd and I can assure you that it’s going to be a lot of pain but it’s easier to just make a 1GB boot partition these days and pretty much never worry about bloat again.

No, the actual issue was an impurity (not working in Nix’ pure model). Impurity is a bug; it was fixed years ago.

That being said, the statement that symbol conflicts do not exist on other distros is plainly not true.

I have never claimed such a thing.

Classical distros have exactly one instance of a library ABI’s .so in most cases which is usually the only place where any given symbol is defined.

You could technically provoke a symbol conflict using LD_PRELOAD and the like but it’s not something you commonly run into because package upgrades always replace the previous version entirely.

You could technically have multiple conflicting sos on classical distros too by prefixing a more detailed version but you don’t; doing such things kinda what differentiates Nix from classical package management.

This QT issue in particular was an impurity (working outside of Nix’ pure model; not as intended) caused by “installing” qt libraries into your environment imperatively (which isn’t something you should do anyways) that was solved a couple years ago.