Hacker News Reader

Comment by Santosh83 | Hacker News Reader

So many interesting/fascinating concepts and ideas that will remain relegated to niche communities because of basically one problem: lack of drivers. This is the problem that must be solved if we ever want to move away from the dominance of a few OSes "too big to fail" and their million compromises to a thriving field where competent programmers can create new OSes as easily as now they can create new apps.

View on HN

Unfortunately this will likely continue, as hardware vendors sacrifice both the environment and human rights (quasi-slavery in the mines/factories, as well as user freedoms) in the quest for profit.

On the topic of drivers and specifications, I strongly recommend a talk entitled "It's time for the OS to rediscover hardware" [0]. If you prefer a written form, "OK Lenovo, we need to talk" is a great article on the same topics. [1]

[0] https://www.usenix.org/conference/osdi21/presentation/fri-ke...

[1] https://www.haiku-os.org/blog/mmu_man/2021-10-04_ok_lenovo_w...

If you write your operating system to use the paravirtual devices and run inside a hypervisor then you don’t need to worry about drivers for all the physical devices you might find.

By the time you have attracted enough users that those few percent of performance you are losing on the paravirtual drivers is an issue, the extra code for some performance critical native drivers will be a small part of your OS.

This used to be the case but, nowadays, there is a second problem, which is lack of web browser. Now, in addition to deal with present and future hardware, you need to deal with present and future web technologies, or your OS will not succeed. This makes it more difficult for amateur OS designers.

All this said, it makes me very happy that some people are brave enough to keep trying.

Mozilla should finance something like this and make an OS. Call it Firefox OS. Oh, wait

But in all seriousness I would use a Chrome OS made by Mozilla with a daring new interface (tabs everywhere!), unixy with a brand new text shell, etc.

Sure, you need to keep up with it the rest of the world. You used to have to include a C compiler with your OS. When was the last time Windows came with a C compiler?

...or you can go the other route and make a very deliberate decision that there is one specific piece of hardware that you're going to support and not be sidetracked into developing drivers for a huge array of hardware.

For example, I bought a used Sony Xperia X that was several years out of date when Sailfish OS was released. I also bought a half-decade old Think Pad because it was one of the few machines that LibreBoot supports. I actually care way more about software than about having the latest hardware or the broadest array of hardware options to choose from.

I wonder if this could be solved by picking a widely available but fairly stable platform for it - like a Raspberry Pi, and making sure it works there. Atm, it seems like it's an x86-based OS, so I'm not sure how difficult would it be to port it to ARM.

> I wonder if this could be solved by picking a widely available but fairly stable platform for it.

For buses and basic IO it might be a solution. For a broader picture, it may be not.

For example: your favorite USB device that requires a custom driver won't work (like a USB-to-Serial FTDI chip). Starting from there, now imagine giving support for every printer in existence.

This is a really good idea. If I was making a hobby OS (someday!), this is the route I would choose.

I wonder if there are any workarounds to this, such as some compatibility layer that allows a new OS to reuse Mac or Windows drivers.

I have no experience in operating systems, so may be proposing a naive solution.

Anyone here with more experience that could share some ideas?

I am not an expert at all, but such compatibility layers exist. For example Captive [0] was able to reuse Windows XP binary NTFS drivers on Linux. At that time there was no Linux NTFS driver with writing capability.

As Linux's driver model is incompatible with Windows XP's driver model, Jan Kratochvil has to code a Linux driver implementing a Corba interface [1] to dialog with a remote piece of code implementing the other end of Corba.

This remote code itself was in two parts, one was a driver sub-system borrowed from Reactos 2.3 (its kernel was similar to Windows 3.51 kernel at the time) that piloted a binary Microsoft native NTFS driver.

[0] https://www.jankratochvil.net/project/captive/doc/Details.pm

[1] https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

We already see this to a certain extent, Linux has NDISWrapper to use some Windows drivers, but my understanding is that it isn't so straightforward for most other classes of driver because the way they work has a lot to do with the way the target OS kernel works and it's hard to map from one to the other.

Windows XP drivers used messages for communication between the kernel and the drivers, so it was quite straightforward.

A driver has to filter the messages it receives, process the one that were addressed to itself and pass on the other messages to the next driver.

I keep wondering if this is as bad as it looks. Compared to the old days where there seems to be infinite combination of drivers, these days GPU, Sound and Network vendors are fairly limited.

Now that Intel has finally been forced to change its mindset. I hope they will see the need to Open Source their IP and Drivers as competitive advantage. I am not even an avid Open Source supporter, but if they need or want to balance the power between Operating System competition. That is what will be needed.

This will require a complete pivot to Fabless and IP model.

It is sort of strange to see how thing plays out, I could see the possibility of Intel and Microsoft releasing x86 ISA and Windows kernel as open source in the future.

I'm not sure having a million OSes is necessarily better than having a handful...

This will never change, it has always been like this since computers exist.

Reply on news.ycombinator.com