NixOS needs what is IMO the killer feature of Arch: the wiki.

Comprehensive documentation on not only the OS but the additional packages that we use is what drew me to Arch, and the thing that makes me swear in frustration whenever I have to use Ubuntu/Debian.

NixOS is an excellent OS that has the promise of being every bit as hackable as Arch, but far more stable. Problem is, configuration is very different and needs extensive documentation to reduce that friction point.

One of our engineering teams who normally builds our products in-house was made to bid against contractors who promised the moon.

Them and multiple other teams then had to spend a total of 18 months getting the contractor's shoddy work up to scratch. When they were done, the lead engineers from three teams left, as well as their manager.

This is actually a feature that enterprise SAN solutions have had for a while, being able choose your level of redundancy & performance at a file level is extremely useful for minimising downtime and not replicating ephemeral data.

Most filesystem features are not for the average user who has their data replicated in a cloud service; they're for businesses where this flexibility saves a lot of money.

Yes, but also from an implementation perspective: if I'm making code that might kill somebody if it fails, I want it to be as deterministic and simple as possible. Under no circumstances do I want it:

1. checking an external authentication service.
2. connected to the internet in any way.
3. have multiple services which interact over an API. Hell, even FFIs would be in the "only if I have to" bucket.

1. Get kicked from freedesktop for fostering a toxic community.
2. Ditch wlroots for your own compositor.
3. Shit on other compositors in your spare time.
4. Tell people they should just be plugging into Hyprland instead of rolling their own compositor.

Man if I was concerned about sinking the time to make a configuration for the compositor with a bus factor of 1 man-child, and a toxic community; I can't imagine anybody investing the time to make a compositor is going to want to hitch themselves to that cart.

The compositor is really solid and makes for a great user experience but I'll be fucked if every word vaxry writes doesn't make me want to move to sway or niri.

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

Memory safety is likely to prevent a lot of bugs. Not necessarily in the kernel proper, I honestly don't see it being used widely there for a while.

In third party drivers is where I see the largest benefit; there are plenty of manufacturers who will build a shitty driver for their device, say that it targets Linux 4.19, and then never support/update it. I have seen quite a few third party drivers for my work and I am not impressed; security flaws, memory leaks, disabling of sensible warnings. Having future drivers written in rust would force these companies to build a working driver that didn't require months of trawling through to fix issues.

Now that I think about it, in 10 years I'll probably be complaining about massive unsafe blocks everywhere...

I build Linux routers for my day job. Some advice:

• your firewall should be an appliance first and foremost; you apply appropriate settings and then other than periodic updates, you should leave it TF alone. If your firewall is on a machine that you regularly modify, you will one day change your firewall settings unknowingly. Put all your other devices behind said firewall appliance. A physical device is best, since correctly forwarding everything to your firewall comes under the "will one day unknowingly modify" category.

• use open source firewall & routing software such as OpenWRT and PFSense. Any commercial router that keeps up to date and patches security vulnerabilities, you cannot afford.

• bcachefs; I currently use zfs and am not a huge fan of btrfs. Having another filesystem mainlined will be fun.

• eBPF, particularly if somebody picks up after the presumably abandoned bpfilter.

• Improved/matured support for rust written drivers. I'm not so fussed about in-tree work, but future third party drivers being written in a safer language would be a nice benefit.

• long term: the newly introduced accelerator section of the kernel might make SoCs with NPUs and the like have better software support.

• very hyped for plasma 6, and Cosmic both. I've got a lot of confidence in KDE devs, and Cosmic previews look very nice.

• NixOS has been a really cool distro for a while, but it also looks to have a solid build system from which interesting derivatives will show up.

Blaming the creation of a new law on anybody except the lawmakers is a pretty shit take, but blaming it on 150 year old colonialism is actually infantilistic.

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.

Any government which makes caffeine illegal must be prepared to enforce that law with mass violence, or let it be ignored.

Given how unlikely your average cop is going to enforce a law they regularly brea... Oh, nevermind. Yeah it'd be a shit show. Demonstrations, arrests, black markets, the whole nine yards.

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.

While I think the cynicism is well-earned, we should pay attention to when we're proven wrong and highlight when companies do something right. Bitwarden's fuck-up gave them an opportunity to signal that they're not intending to build a wall for their garden, and they took it.

Just finished my third co-op campaign with my partner, I think she may enjoy the game more than I do. It is pretty great having shared hobbies ☺️

hat's a bad faith interpretation of "the people control the means of production".

I want you to consider the difference between the work needed to complete a task, and the work needed to manage a workplace: for one of those tasks, only the experts in that task can meaningfully contribute to the outcome, whereas for the other, everybody who is part of the workplace has meaningful input.

I don't know about your experience, but everywhere I've worked there have been people "on the ground" who get to see the inefficiencies in the logistics of their day to day jobs; in a good job a manager will listen and implement changes, but why should the workers be beholden to this middleman who doesn't know how the job works?

I've also had plenty of roles where management have been "telling me where to cut".

America isn't even the most democratic country in the Americas, but that's clearly not the point they're making.

If the title was "...end of world democracy" you'd have a point but given how much fascistic rhetoric and policy has increased around the world since trunpism it's fair to say many countries are following the US lead here.

Likely a combination of 4 things:

1. They have third party firmware in their blobs that they are under NDA regarding the source code.

2. They believe in the source code is a large part of their success and don't want to reveal it.

3. They believe giving out the source code will allow many inferior variants of the software, impacting their brand.

4. Control; the more source code they have in mesa the more of their code can be rejected by mesa. Keeping their stuff as blobs allows them to put in whatever hacks they want.

I used nushell for a good 6 months, it was nice having structured data, but the syntax difference to bash which I use for my day job was just too jarring to stick with.

Fish was (for me) the right balance of nice syntactic sugar and being able to reasonably expect a bash idiom will work.

For the same reason spoken languages often have semantic structures that make a literal translation often cumbersome and incorrect, translating nontrivial code from one language into another without being a near expert in both langauges, as well as being an expert in the project in question, can lead to differences in behaviour varying from "it crashes and takes down the OS with it", to "it performs worse".