> Professional level 3D vector math

I'm always suspicious of "Professional" in descriptions like this as it is a meaningless word you add to make it sound impressive.

Also, in this case it means a 900 line math library with 78 lines of tests...

The library is mostly a wrapper around intrinsics, so it's not doing much that would necessitate testing if the author is experienced enough.

The fact that invert_safe() isn't actually safe isn't the greatest look here though.

self grandstanding is what it is.

That would be perfect. There is so much good about Rust, and if it could compile to C in that way it would have been amazing for this game

That looks really interesting, I'll experiment with swapping to it!

> global belligerence will make itself felt in our community

Sadly this has already happened. The Israel/Palestine situation was frequently referenced during the bitterest arguments in the NixOS community governance issues last year

> That's not what technical debt means

Undoubtedly, I'm not sure why technical debt is in the title

> this is vapid clickbait

This seems unfair. It is a well written discussion of the difference between kqueue on BSDs and epoll on linux, and a historical overview of predecessor APIs. It just has nothing to do with technical debt, which, given the title, is admittedly odd

I'm curious: What would be the difference between suboptimal decisions made earlier in the history of a code base and technical debt?

> I liken Nix to source control in the time of CVS

I think this is my favourite comment about Nix ever. I'm not going to stop using Nix until a genuinely better alternative arrives, but that day can't come soon enough

Probably nothing, but then this feature isn't aimed at people who have used emacs for years, and who like and effectively work with elisp.

I on the other hand, am very familiar with guile, I don't particularly care for elisp, and I would like to be able to customise my editor more comfortably. For me this is great.

Nix works well on mac, very similar to Nix/Linux for the most part. There are some missing packages, but the common ones tend to be fine. Its worth using the Determinate Systems installer to avoid reinstalling Nix on every macOS update though.

Nix-darwin is good, and I use it, but it is nowhere close to NixOS. I think there are some options I've set through it that macOS keeps overriding, so the declarative configuration drifts from the real one eventually

I think the only real issue with Nix on macOS is that Nix can eat through storage quite quickly, and storage upgrades are pretty expensive on Macs. This might push the balance back to an fanless ryzen build

> I think the only real issue with Nix on macOS is that Nix can eat through storage quite quickly, and storage upgrades are pretty expensive on Macs. This might push the balance back to an fanless ryzen build

Only if you want to be able to roll back multiple versions. Otherwise, I think it is fine.

Indeed I've been liberally using nix-collect-garbage -d after every darwin-rebuild switch without issues for years.

> Its worth using the Determinate Systems installer to avoid reinstalling Nix on every macOS update though.

I've had Nix installed from the traditional installer since the very first M1 and never had to reinstall nixpkgs across OS updates.

I guess some people have been addressing the clobbering of /etc/bashrc with full reinstalls?

Because minis are very commonly racked in bulk, and its both very irritating for that use case, and entirely unnecessary

Minis are rarely racked in bulk unless you're running a server farm, which is not the use case they design for. The MacMini is first and foremost a desktop computer for non-professional people or at least not sysadmins. If people want to rack them, go ahead, but in that case how often are you hard rebooting a machine vs soft reboot anyways? Macs aren't known for freezing up too much.

Either way, it works for the use case its designed for.

Some of the rackmount kits for previous generations already reroute the power button and connectors to the front, like this https://racknex.com/wp-content/uploads/2023/04/with-power-bu.... (Though why not just install it backwards?) I guess they will be able to run a little lever under the M4 model the same way.

Actually, the M4 model is a little taller so it no longer fits in a 1U rack mount. Whereas before you could fit 2 horizontally in 1U, now you'd possibly fit 8 or 9 vertically in 3U. (Edit: This company says 10 per 2U https://www.racksolutions.com/m4-mac-mini-apple-hypershelf.h....)

I think the airflow for more than 3 per 1.33u, or 8-9 per 3u will necessarily suck.

I have designed for both, I think both have great use cases. 2 x 8 in 6u is really neat and tidy, I just don't love the concept of sitting the fans on their side, though I think they'll still last 5 years.

In that case wouldn't you rather have a managed power switch / iDRAC / restart over ssh, than send someone to go press buttons in person?

(I've only ever racked things remotely, so don't know if this is common.)

Can't do idrac of course but you can do managed power port, kvm and ssh.

The most efficient is managed power + serial + ssh and probably the best to go for.

Why not just rack them upside down then?

In that case then they should be on switched pdu ports and plugged into permanent kvm.

I'm sorry but this is nonsense, if you're really racking them in bulk the above is obvious.

Yes, the most concrete issue the article mentions is losing data on Btrfs, but that is well known to be a flaky, semi-experimental file system, the operating system has very little to do with it. The equivalent would be running Debian on ext4

Also, the article mentions Kubernetes a few times, which quite fairly has a reputation for massive complexity, but is again entirely optional, and a piece of software entirely separate from the operating system.

I agree with the basic point of achieving reliability by using the simplest technology available, but the focus on the operating system for me is misguided here, and at best a temporary fix. If BSD were to catch on for that reason, Kubernetes would be ported to BSD, and the same problem would arise there

It's also a 10 years out of date complaint. Btrfs has been stable for fucking ages. That meme needs to die.

Yes and not a single one of them can quote someone from this decade because it's a shitty internet myth that won't die.

Hi. Article author here.

I worked for SUSE from 2017 to 2021. Because of that, I ran openSUSE on my work computer. Btrfs self-destructed on me, on 3 different PCs, about twice a year in that 4-year period.

Not myth. Not from t'Internet. Direct personal experience.

Btrfs `df` lies. You, and programs, can't get an accurate estimate of free space. OS snapshots fill the volume, volume corrupts, new install time. Over and over again.

I do not trust Btrfs and since the Btrfs zealots are in denial and will not confront the very real problems, I don't think it will ever get fixed.

Yah well. Do some housekeeping then? I mean if the Distro delivers automagically snapshotting in intervals, during installation of packages, or whatever they fancy?

It's not like you'd need those for all eternity. By housekeeping I meant deleting them from time to time, with easily clickable tools, which exist(now/meanwhile), and DO give an overview. Maybe have to 'rebalance' afterwards, which can go wrong if the 'housekeeping' was too late, or something. OTOH the 'rebalancing' can be automated, from the beginning.

I'm sure similar haphazards (regarding common tools like df/du not being able to give an exact overview of remaining capacity) exist under ZFS, at least when your'e using compression.

No. That is the simple answer. I refuse.

I will clean up my own mess. If I take snapshots, it's my job to clean them up.

If the OS does its own then the OS can do the work and clean up its own mess.

More to the point, if the OS's developers thought this was a good idea, then complete the work, finish the job, track the space usage and never ever do operations needing lots of space without checking that space is available or making it available.

This is bad design and bad implementation. It is not my job to fix their omissions.

Yah. Maybe (or even probably, given the history and all the (not even that anecdotical) evidence of all the gotchas and oopsies that happended so far) I'll eat chalk.

But so far I'm really enjoying my new hot technotoy, in combination with some other 'crazy' tools, like zram, profilesync-deamon for the browser, a really 'riced' kernal...err kernel with all sorts of powerful patches, and even most parts of the userland compiled with optimizations to the limits of my cpu, even the browser!

ISTR you mentioned the crappy default partioning suggestions from another OS in another thread, which seem inflexible because of the potential waste of space for different directories like /usr/var/serv/somecrap/whatnotelse/GO/HOME!, which really can't be known in advance for casual desktop-use, and I concure.

But with BTRFS-subvolumes that shit doesn't matter anymore! Whee! :)

I'll wait and see, and will abuse the really unexpectedly well working combination of components and their versions and settings to the max, not having experienced hitches, glitches, or even crashes so far.

But anything which could get lost is backed up incrementally to elsewhere anyways, just in case.

OK, that's perfectly fair. Enjoy! Seriously!

My take is just that, in the 21st century, I do not expect a Linux distro in normal routine use to crash and corrupt its disk. Not _ever._ That was acceptable in the '90s when it was new, but not now.

For the SUSE folks to complain that "U R doin it wrong" doesn't wash.

E.g. for an OS that takes a single-digit number of gigabytes of disk space, a 32GB disk partition should be plenty and it should never fill that up.

I note that recent releases of openSUSE disable Snapper if given a root volume of <= 20GB. Maybe that was due to me and my bug reports. I don't know. It's a rotten answer, though: "OK, this dude's weird usage breaks our snapshot system, so what we'll do is turn it off."

The correct answer is to fix the snapshot system. A better one is to fix the filesystem.

Also everyone ignores the publicly visible zfs repo/issues. Corruption https://github.com/openzfs/zfs/issues/16631 crash/corruption https://github.com/openzfs/zfs/issues/16626 crash https://github.com/openzfs/zfs/issues/16623 just from this week. One of those filesystems is likely more stable than the other, but the image of perfect zfs is tiring.

> One of those filesystems is likely more stable than the other, but the image of perfect zfs is tiring.

I didn't say perfect, I just said, querying for FS to use, everyone recommends ZFS, over Btrfs. Even if not perfect, it seems to have left a better impression than Btrfs.

I've had btrfs loose my laptops root filesystem, it just wouldn't mount anymore for no apparent reason. This was ~6 or 7 years ago. Reading the fs with some rescue command worked fine, the ssd continued to work for a few more years after formatting.

I've also had a weird situation after that where a micro SD formatted with btrfs on my desktop PC wouldn't mount on a raspberry pi, and vice-versa the same micro SD formatted on the pi wouldn't mount on the desktop. This was apparently caused by a difference in the used block sizes, which were mutually incompatible.

So I'll quote myself on this.

But also, my server is running a btrfs raid 1 due to the flexibility for resizing and that has been just fine for a few years now. It's not black and white and with backups I am not really worried.

fill your btrfs with "dd if=/dev/urandom of=./testfile" as a normal user then "rm ./testfile && sync" then reboot. 6 month ago i could brick btrfs with that "trick".

I have a broken (parent transid verify failed on logical) btrfs RAID5 here that I can't mount anymore even with the recovery commands and google shows many results about it from less than a decade ago.