181–190 of 273 posts
Earlier quoted context omitted.
Maybe I’m missing the joke, but in or out of kernel context is orthogonal to how the source code is stored.
The author is the same (Linus), so it makes sense that he would design a source control system that supported the monorepo he created over the prior 15-ish years.
Earlier quoted context omitted.
> 1. Linux is too big. Too big for what exactly? Because it's clearly not too big to run. It's been running very well for decades, and Hurd has not. I've known for decades that on paper, microkernels and Hurd should be superior, and I've wondered for nearly as long why then they aren't taking off. If they're so good, they should at least be thriving in some niche where that performance matters, shouldn't they? And no…
> I've known for decades that on paper, microkernels and Hurd should be superior, and I've wondered for nearly as long why then they aren't taking off. If they're so good, they should at least be thriving in some niche where that performance matters, shouldn't they? They (microkernels) thrive in Automobiles, Aircraft, Spacecraft, Security systems (such as hardware encryption devices), Defense Munitions, Embedded Devi…
Or could they work if only people would stop focusing on Hurd? Is Hurd a dead end? Or is GNU the real problem and should we abandon that?
In the commercial world the first release a new OS with GUI only takes about 4 years, depending. Hurd has exceeded that by a huge margin.
Honestly, what's Hurd doing wrong to flounder so hard?
[0] https://github.com/redox-os/redox/releases/tag/0.0.3
Earlier quoted context omitted.
> To add to this, 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. These days most Linux distros build pretty much any driver as a module that can be built as one. Bo…
>I agree that Linux is still larger than a microkernel, but very few users have a bloated kernel in RAM due to lack of customizations. Most users run the distribution's kernel.
The rest is in the modules and they're not loaded unless they're actually used. The parts baked into the kernel are mostly display, storage and various buses, which you would need to have immediately loaded in Hurd anyway to load the rest of services.
Earlier quoted context omitted.
Filesystems tend not to be all that complex to implement.
Simple filesystems - those oriented at speed, without integrity checking, compression, encryption and raid-like features. Which are extremely useful and desirable in a filesystem. When people tried to do a full-featured filesystem, with a remarkable exception (ZFS) it's either a disappointing unfinished mess (btrfs) or a promising, but a long-term project taking years (bcachefs). Making a filesystem with strong suppo…
Medium is such a hostile platform.
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?
Earlier quoted context omitted.
NetBSD has architectured their drivers to be basically static archives reusable anywhere. It's part of the NetBSD rump kernel.
What do you mean by "reusable everywhere"? I mean, where could they be used other than in a NetBSD kernel?
Earlier quoted context omitted.
Could one not make the case that maybe device driver support doesn't belong in the kernel itself?
The Linux kernel driver API/ABI isn't stable so there's no permanent/versioned interface you can program against that would make out-of-tree drivers non-headache inducing: https://www.kernel.org/doc/Documentation/process/stable-api-... > You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in…
Earlier quoted context omitted.
>I agree that Linux is still larger than a microkernel, but very few users have a bloated kernel in RAM due to lack of customizations. Most users run the distribution's kernel.
Which distribution kernel specifically? If you're running on a VM, you get a cloud kernel in many distros, which is very stripped down for example. On other systems - the modules part still applies - how much are you actually trying to save on the kernel RAM usage? I've got a very average kernel from a distro at 20MB and initramfs at 35MB. They could be twice the size and I would never notice. I appreciate they could…
What could possibly go wrong.