3 ms·
Based on your comment and this question [1] I wonder how well GNU Hurd runs the open source stack and what problems you will find in the road (e.g. GPU support)
by wslh 2y ago
Based on your comment and this question [1] I wonder how well GNU Hurd runs the open source stack and what problems you will find in the road (e.g. GPU support).
I really like the approach of separating, in some way, the kernel, from the user space and interchange them but why you would do that, except for playing and research, if the kernel doesn't give you an advantage and it just an alternative?
[1] https://unix.stackexchange.com/questions/282046/can-gnu-linux-software-run-on-gnu-hurd https://unix.stackexchange.com/questions/282046/can-gnu-linu...
- RobotToaster 2y ago> what problems you will find in the road (e.g. GPU support). My understanding is it can't really run on actual hardware at all in it's current state, it's mostly run virtualized.
- yjftsjthsd-h 2y agoOn the software side, it's passable; as that post notes, there's a Debian spin on HURD that's basically functional. In practice, though, GPUs are the least of its concerns; AFAIK, HURD still doesn't support USB:( > I really like the approach of separating, in some way, the kernel, from the user space and interchange them but why you would do that, except for playing and research, if the kernel doesn't give you an advantage and it just an alternative? Well I think a lot of it is that we thought it would be easier; in theory, separating concerns and putting drivers in userspace sounds like it should make it a lot easier to write the OS. That didn't really turn out, but it seemed like a good idea at the time. On the more practical side, microkernels can have security and reliability benefits (if drivers run in userspace, they have less access to exploit, and crashing a driver doesn't crash the whole machine). I mean, diversity is also useful for its own sake, but there are more immediate benefits.