I've spent the most part of today getting rid of Mac OS X on my Mac Pro, which was occupying two disks in mirrored RAID, for good, and installing Void… on ZFS!
And now, when I'm almost there — at least I can run Lagrange under Sway, I attempt to install my carefully crafted Firefox 124 without WebPee support and come to a painful realisation: "Architecture not supported"😱
Damn, I always forget not only the fact that GLibC flavour of Void exists, but that e.g. x86_64 without -musc is IT!!!🤬
I didn't put too much time into configuring it, much more into getting familiar with how zfs is managed, and most of what I did is under /home anyway — I've put that on a separate volume in accordance with the handbook.
Hopefully, it won't take much time to redo the base system re-installation — it seems to me that it's a matter of clearing the volume that is used as root — but I'm just not sure how to do that with zfs😅
Turned out it's even easier than I have anticipated — I just renamed the zroot/ROOT/void volume to zroot/ROOT/void-glibc, created a new one — zroot/ROOT/void-musl, bootstrapped it and copied some of the old config files over — literally in matter of minutes.
It turns out zfs isn't supported by linux6.10 — at least in Void, but… who cares 🤷
Otherwise, zfs so far is pretty good! Pretty pretty good 😏
Nvidia with Wayland — not so much, even though mine is a pretty old GTX680-based card.
Now I can see what you guys are talking about, with Intel it was seamless — I've never had such issues.
What makes matters even worse, the video card of mine has Mac firmware, no PC one — the one that supports EFI booting on legacy Macs. I suspect it somehow contributes to the issues I have — I still haven't found a way to enable the second display post OS boot.
So, Nvidia's closed-source thing simply doesn't exist for musl-based systems: https://forums.developer.nvidia.com/t/provide-driver-for-muslc-to-install-it-in-musl-distros/219586
Not unexpected, but still kinda disappointing 😩
@hyc
Yeah, usually gcompat does the trick.
But in this case I'm not even sure — this driver thing is supposed to be rather complex with part of it in the kernel.
Worth a try I suppose, but it's strange that it wasn't even suggested in the linked thread — most probably doesn't work. On the other hand, such a configuration is rather exotic — maybe no one just invested enough time to make it work 🤷
@m0xee the kernel interface is just that - which user level libraries call it is irrelevant.
@m0xee you can't just make a shim library to load musl's libc for a module linked against glibc?