This makes me wonder if Guix is ready for the real world.
ML and GPUs are a smallish subset of the real world, and a subset that's particularly plagued by proprietary software (especially the GPU side); I don't think it's a good litmus test for "is guix useful for real work".
The stance on non-free stops me from using it. Amdgpu is open source down to and including the Linux kernel. But each card has a couple of kilobytes of binary firmware file, so no deal.
That firmware could literally ship on the card totally invisibly and that would be fine for guix, but because it can be patched in the field, no.
That's just.. so counterproductive. They are ok with proprietary software, but only if they come builtin.
But there are some spectre and meltdown mitigations that comes with CPU microcode, right? It's probably not a great idea to not apply microcode updates in this case
Ok, s/k/m. I remembered small and didn't check. Doesn't change the underlying point though - so what? The same guys who shipped the silicon also shipped some magic numbers with it. If you trust one, may as well trust the other, since they're equivalent.
There are a bunch of things that come up regularly on HN that aren’t particularly relevant to the real world so I don’t think this logic is good. Though I think you are correct that ML is relevant to the real world. However when you wrote ‘the real world’ you didn’t mean the thing for which ML is relevant but rather ‘being a general purpose operating system that is useful [to software developers]’ and for this I think the lack of hardware-accelerated PyTorch isn’t great but I don’t think training/running ML models is particularly relevant to being a general purpose OS (even for software developers). I’m not sure it’s even relevant to ML practitioners as I would expect they’d be farming out training to a dedicated compute cluster.
One needs to jump through a bunch of hoops to get hardware-accelerated PyTorch on Apple’s latest computers. Does that mean they aren’t ready for the real world?
I mean, to run the software developed by ML practitioners, you basically end up in dependency hell every time you try out something new. This is exactly where an autobuild/package system such as Guix is supposed to shine.
ML is also increasingly relevant for OSes, think OCR and speech recognition, but also painting programs. Image classification and segmentation are used in industrial systems; lots of ML happens on servers. And this is where Linux shines, and thus support from Guix would be great. Categorically excluding this group of GPU users is a mistake.
One needs to jump through a bunch of hoops to get hardware-accelerated PyTorch on Apple’s latest computers. Does that mean they aren’t ready for the real world?
Comments
ML and GPUs are a smallish subset of the real world, and a subset that's particularly plagued by proprietary software (especially the GPU side); I don't think it's a good litmus test for "is guix useful for real work".
The stance on non-free stops me from using it. Amdgpu is open source down to and including the Linux kernel. But each card has a couple of kilobytes of binary firmware file, so no deal.
That firmware could literally ship on the card totally invisibly and that would be fine for guix, but because it can be patched in the field, no.
I don't get it.
They shouldn't ship at all on any CPU arch that uses microcode since it's also just closed firmware blobs!
I'm a little confused how x64 gets away with this. Do they just stubbornly use whatever microcode was on it when the system switched on?
Unfortunately yes. The nonfree channel linked in this thread does/has microcode updates but mainline guix doesn't.
That's just.. so counterproductive. They are ok with proprietary software, but only if they come builtin.
But there are some spectre and meltdown mitigations that comes with CPU microcode, right? It's probably not a great idea to not apply microcode updates in this case
For the record, vega10 has almost 2 MiB worth of firmware after extracting:
# du -bs gpu/
2053094 gpu
Ok, s/k/m. I remembered small and didn't check. Doesn't change the underlying point though - so what? The same guys who shipped the silicon also shipped some magic numbers with it. If you trust one, may as well trust the other, since they're equivalent.
One is immutable, one isn't.
ML and GPUs are on HN's front page almost every day ...
There are a bunch of things that come up regularly on HN that aren’t particularly relevant to the real world so I don’t think this logic is good. Though I think you are correct that ML is relevant to the real world. However when you wrote ‘the real world’ you didn’t mean the thing for which ML is relevant but rather ‘being a general purpose operating system that is useful [to software developers]’ and for this I think the lack of hardware-accelerated PyTorch isn’t great but I don’t think training/running ML models is particularly relevant to being a general purpose OS (even for software developers). I’m not sure it’s even relevant to ML practitioners as I would expect they’d be farming out training to a dedicated compute cluster.
One needs to jump through a bunch of hoops to get hardware-accelerated PyTorch on Apple’s latest computers. Does that mean they aren’t ready for the real world?
I mean, to run the software developed by ML practitioners, you basically end up in dependency hell every time you try out something new. This is exactly where an autobuild/package system such as Guix is supposed to shine.
ML is also increasingly relevant for OSes, think OCR and speech recognition, but also painting programs. Image classification and segmentation are used in industrial systems; lots of ML happens on servers. And this is where Linux shines, and thus support from Guix would be great. Categorically excluding this group of GPU users is a mistake.
They are. But their packaging systems are not.
You can use this channel to get non-GNU sanctioned software, including kernels and drivers: https://gitlab.com/nonguix/nonguix
Furthermore, you can install Nix in Guix: https://guix.gnu.org/packages/nix-2.5.1
then why not just install Nix in the first place??
You prefer using guix but want a package Nix has already packaged and don't have the time and knowledge to package it yourself.
I use NixOS, but GuixSD users might find this option useful.
So aren't articles about developers and work-life balance.