Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BlueOS Kernel – Written in Rust, compatible with POSIX

github.com

Post reply on HN
Print view View original

21–30 of 70 posts

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#21

Post by notepad0x90 »

It would be neat if there was a standard interface for device drivers, similar to what POSIX does for user-space. That way, interesting kernels like this one can just comply with that and the enormous amounts of Linux modules can be ported to comply with that standard so that they can also be loaded by redox, blueos,etc..

But the complication I suppose is data-structures being accessed by drivers that reside in the core kernel and other assumptions that come with linking against a monolith program like the Linux kernel. It would be momentous to simply get Linux drivers to comply with a kernel-agnostic ABI.

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#22

Post by jervant »

notepad0x90 wrote: post #21

It would be neat if there was a standard interface for device drivers, similar to what POSIX does for user-space. That way, interesting kernels like this one can just comply with that and the enormous amounts of Linux modules can be ported to comply with that standard so that they can also be loaded by redox, blueos,etc.. But the complication I suppose is data-structures being accessed by drivers that reside in the c…

Maybe hardware should start offering virtio interfaces

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#23

Post by dc396 »

Beijinger wrote: post #11
mrbluecoat wrote: post #7

From their website (translated): Blue River Operating System 2 is the industry's first operating system written in the Rust language from the kernel to the system framework. A series of security features of the Rust language can detect security vulnerabilities caused by improper memory use during the compilation stage, making it inherently more secure from the source.

Wasnt Harvey OS written in Rust?

And https://www.redox-os.org?

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#24

Post by lmm »

Mr_Minderbinder wrote: post #18
AlecSchueler wrote: post #6

Earlier quoted context omitted.

> development happening in China but I find it very hard to find resource in English about what’s actually happening. For years I've had this issue with pretty much everything happening in China, from business to politics to culture. For me personally, getting a window into China has been the number one game changer with LLMs. It's easier than ever to find and digest Chinese sources.

I feel like this a problem in general for topics outside “the West” or even just the Anglosphere. There is a tantalising amount of information that is siloed away in other languages. I was reading a Wikipedia article on one of the campaigns waged by the Ottomans in Europe and the English version was threadbare (and poorly written) in comparison to the Hungarian Wikipedia equivalent which was three times longer and ha…

> the fact that the ones “closest” to the event in question will generally be the ones most qualified and ready to report upon it.

Or are the most motivated to push a narrative in relation to it.

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#25

Post by Ericson2314 »

notepad0x90 wrote: post #21

It would be neat if there was a standard interface for device drivers, similar to what POSIX does for user-space. That way, interesting kernels like this one can just comply with that and the enormous amounts of Linux modules can be ported to comply with that standard so that they can also be loaded by redox, blueos,etc.. But the complication I suppose is data-structures being accessed by drivers that reside in the c…

Yes, we really really need to do this. It would be what LLVM was for compiler frontends (and thus languages) starting 15-20 years ago: a Cambrian explosion enabler.

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#26

Post by Ericson2314 »

kllrnohj wrote: post #17
StopDisinfo910 wrote: post #2

I regularly see articles pop in here about OS development happening in China but I find it very hard to find resource in English about what’s actually happening. Could anyone give an overview of what Huawei and Vivo are doing? I understand it’s mostly RTOS to use on phone. How does it compare to QNX and Linux? Is it as ambitious as Fuchsia? Apparently they are shipping. It’s weird that we have reached a point where t…

It's even harder to get an accurate picture of what Chinese companies are actually doing. Like the wiki page for Huawei's OS Next is pretty incredible. By which I mean, rather actually unbelievable. https://en.m.wikipedia.org/wiki/HarmonyOS_NEXT They created a brand new microkernel with Linux ABI and driver support in containers? Or... did they just slightly fork Linux and pretend they invented it?

Seeing Illumos lx-branded zones and WSL1, I think it is plausible that this actually does that. It is less research-level hard then simply requiring a lot of person-hours to slavishly reproduce an underdefined interface.

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#27

Post by usamoi »

kllrnohj wrote: post #17
StopDisinfo910 wrote: post #2

I regularly see articles pop in here about OS development happening in China but I find it very hard to find resource in English about what’s actually happening. Could anyone give an overview of what Huawei and Vivo are doing? I understand it’s mostly RTOS to use on phone. How does it compare to QNX and Linux? Is it as ambitious as Fuchsia? Apparently they are shipping. It’s weird that we have reached a point where t…

It's even harder to get an accurate picture of what Chinese companies are actually doing. Like the wiki page for Huawei's OS Next is pretty incredible. By which I mean, rather actually unbelievable. https://en.m.wikipedia.org/wiki/HarmonyOS_NEXT They created a brand new microkernel with Linux ABI and driver support in containers? Or... did they just slightly fork Linux and pretend they invented it?

They published a paper for it, which includes more details. https://www.usenix.org/conference/osdi24/presentation/chen-h...

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#28

Post by pjmlp »

notepad0x90 wrote: post #21

It would be neat if there was a standard interface for device drivers, similar to what POSIX does for user-space. That way, interesting kernels like this one can just comply with that and the enormous amounts of Linux modules can be ported to comply with that standard so that they can also be loaded by redox, blueos,etc.. But the complication I suppose is data-structures being accessed by drivers that reside in the c…

Besides any technical issues, the issue in the Linux world is FOSS religion.

Most other OSes have had driver ABIs throughout all their existence.

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#29

Post by heavyset_go »

notepad0x90 wrote: post #21

It would be neat if there was a standard interface for device drivers, similar to what POSIX does for user-space. That way, interesting kernels like this one can just comply with that and the enormous amounts of Linux modules can be ported to comply with that standard so that they can also be loaded by redox, blueos,etc.. But the complication I suppose is data-structures being accessed by drivers that reside in the c…

IMO, the reason we have a sea of open source drivers available now is because of the lack of a standard driver interface.

If one existed, companies would not be compelled to release their drivers' source, and would just release closed source drivers. As it stands, kernel drivers must be open source because the kernel API/ABI changes, and drivers must be recompiled against new kernel releases. It's infeasible to release a compiled driver .ko and have it work with new kernel releases.

Similarly, companies will not be incentivized to mainline their drivers for hardware outside of hobbists' interests. We're blessed with a plethora of drivers for enterprise, cloud and industry hardware that would otherwise have never been released beyond vendors' customers' deployments.

What would happen to the Linux driver ecosystem is what happened with Nintendo, Sony, Apple and FreeBSD. You get closed source drivers siloed away in proprietary systems that will never be released. The deployed drivers will come with restrictions on use and distribution, as well, so it wouldn't be like you could pluck out compatible drivers to use elsewhere.

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#30

Post by Mr_Minderbinder »

lmm wrote: post #24
Mr_Minderbinder wrote: post #18

Earlier quoted context omitted.

I feel like this a problem in general for topics outside “the West” or even just the Anglosphere. There is a tantalising amount of information that is siloed away in other languages. I was reading a Wikipedia article on one of the campaigns waged by the Ottomans in Europe and the English version was threadbare (and poorly written) in comparison to the Hungarian Wikipedia equivalent which was three times longer and ha…

> the fact that the ones “closest” to the event in question will generally be the ones most qualified and ready to report upon it. Or are the most motivated to push a narrative in relation to it.

Paradoxically (or not) this is precisely what makes their scholarship better than that of a “distant” observer. The problem is that truly neutral authors are also often indifferent ones. Since the Ottomans had such a large influence on the history of Hungary, the scholars of that nation are far more interested in that topic and therefore will study and research it to a much greater level of detail than a scholar working in English from the Anglo cultural sphere where that history is less relevant to them. Also “distant” observers will lack a lot of the context necessary to interpret the events and topics in question. The best books on the American Civil War will be written by American scholars working in English, their biases notwithstanding. To make matters worse there is a natural human bias rooted in in-group vs out-group psychology where information provided by an out-group (information in a foreign language) is viewed with more scepticism than that provided by an in-group, even when the topic at hand concerns the out-group.
Post reply on HN