Is it really alive? No SMP, no stable x64 port. No ARM port.
> * APIC, SMP, and 64bit support was improved a lot: they now do boot a complete Debian system, but some bugs remain to be fixed.
61–70 of 273 posts
Is it really alive? No SMP, no stable x64 port. No ARM port.
> * APIC, SMP, and 64bit support was improved a lot: they now do boot a complete Debian system, but some bugs remain to be fixed.
Earlier quoted context omitted.
Could one not make the case that maybe device driver support doesn't belong in the kernel itself?
Isn't this this mono vs micro kernel debate all over again?
Earlier quoted context omitted.
I agree, it's odd. I don't have anything recent, but back in 2004, the majority of the Linux kernel code was in its drivers: https://dwheeler.com/essays/linux-kernel-cost.html I expect that most of the current Linux kernel code is also for handling hardware (that is, drivers + the code to handle various architectures).
Could one not make the case that maybe device driver support doesn't belong in the kernel itself?
An idea from the 'Crossing the Chasm' book is to find a niche where whatever characteristics of the product you're working on can win. You are not going to win going head to head with the entrenched competitors. What does that look like for Hurd?
Linux, (not big and professional like gnu), is not going to win but could find a niche somewhere. Hm, ok.
An idea from the 'Crossing the Chasm' book is to find a niche where whatever characteristics of the product you're working on can win. You are not going to win going head to head with the entrenched competitors. What does that look like for Hurd?
>You are not going to win going head to head with the entrenched competitors. Linux, (not big and professional like gnu), is not going to win but could find a niche somewhere. Hm, ok.
Linux has a large, large established user base at this point. If you want to attract people to a different platform, you need a compelling reason.
For people just looking to look/experiment/learn/play, 'something new' that's more easily understood because it's small might be enough, but that's unlikely to be a large user base.
> The GNU Hurd’s hardware support is poor, so trying to run it on modern physical machines is suicide. > ...one reason for using GNU/Hurd is that the Linux kernel has become too huge By any chance, are these two statements related? Is it smaller because it lacks the drivers?
I also recall it having some ridiculously low limit for partitions, like 1GB or something. Apparently because it mmaps the entire disk, and under 32 bit CPUs there's not enough address space. Which is a ridiculous technical limitation. You could have bigger disks than that by the mid 90s. Come think of it, my Ryzen 9 3950X supports 43 bits of address space which works out to 8TB. So if that limit applies, even the 64…
Kind of weird to see linux called out as too big, and then the ack that writing a ton of device drivers is hard and will take time. Isn't that a large part of the source tree? Realizing I haven't even tried compiling a kernel in a long long time. Feels oddly sad to say.
I understand what you're saying, but both are true. 1. Linux is too big. Even if we exclude the drivers, which are a majority of the kernel codebase, linux is still a massive kernel. Most microkernels are small enough to fit in the L3 cache, some are small enough to fit in the L2 cache. Linux, even if we could exclude the drivers, doesn't even come close. This inability to fully cache the kernel ends up negating the…
Is that important, though? As soon as you start processing any meaningful amount of data, won't your OS be evicted from the cache anyway?
> unless you are compiling your kernel specifically for your machine, your kernel is going to be a bloated compromise of the set of drivers that your system is most likely to see. That means that you will have dozens, if not hundreds of drivers compiled into your kernel which will never need to be used.
I'm not sure this is true. Device drivers are typically compiled as modules, which are only loaded into the kernel if needed. Common wisdom among Linux power users for the last decade or so has been that compiling your own kernel for any tangible performance/memory improvement is basically futile.
Are there exceptions to this that you are aware of, and can elaborate on?
GNU/Hurd is legendary, but not for good reasons.
Earlier quoted context omitted.
I understand what you're saying, but both are true. 1. Linux is too big. Even if we exclude the drivers, which are a majority of the kernel codebase, linux is still a massive kernel. Most microkernels are small enough to fit in the L3 cache, some are small enough to fit in the L2 cache. Linux, even if we could exclude the drivers, doesn't even come close. This inability to fully cache the kernel ends up negating the…
> Most microkernels are small enough to fit in the L3 cache Have you looked at the size of L3 caches lately? You could fit a whole ‘nother OS in one of those.
Earlier quoted context omitted.
Things are perhaps a bit different now than when Torvalds and Tanenbaum debated the issue on comp.os.minix over thirty years ago.
What, specifically, is different?
In short, hardware is more capable, and so perhaps now we can afford to take more opportunities to trade a little bit of overhead for abstractions that are more modular and robust.