Live data from Hacker News

BlueOS Kernel – Written in Rust, compatible with POSIX

github.com

61–70 of 70 posts

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

#61

Earlier quoted context omitted.

Very cool, but I think that points to the impracticality of releasing drivers like that when it comes to distributing them to end users.

End users having to connect to the Internet to download the right drivers seems impractical?

Vendors running build farms into perpetuity so that end users can use their hardware with new kernels does seem impractical from where I'm standing, yeah.

I don't see vendors supporting their hardware for more than a few years if new kernels need new module builds regularly.

Am I misunderstanding what you were talking about?

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

#62
post #41

Earlier quoted context omitted.

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.

LLVM might be the most sucessful one, but it hardly the first of its kind. Here one famous one from early 1980s, there others to read about, for anyone into compiler tooling history, https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit

Thanks, that is some nice history

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

#63
post #38

Earlier quoted context omitted.

China's emergence was inevitable - they have the numbers. Last one I heard was 200 million people in STEM careers alone. That's more than the entire US workforce. I expect technological development to explode and my advice is for anyone interested in it to learn Mandarin. Including myself.

> I expect technological development to explode and my advice is for anyone interested in it to learn Mandarin. Including myself. My father said the exact same thing in the 80's but it was Japanese.

China’s prospects are mic better - like I said, they have the numbers to outperform everyone else. Japan was a completely different case.

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

#64

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…

> It would be neat if there was a standard interface for device drivers, similar to what POSIX does for user-space. Plan 9 does this but instead of a binary interface that exposes machine details it hides them behind 9P, a simple RPC file tree protocol. This same protocol is also served by user space programs so it's universal. The benefit of all this is the system is small and very light weight. Its an OS a single h…

I was always fascinated by plan 9 ever since finding out about it and only ever having heard of the movie referenced in Seinfeld. Way back then I didn’t think it would keep seeing use and development, I’m glad I’m wrong :)

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

#65
post #53

Earlier quoted context omitted.

I’m confused. That fact that you had to recompile for each new kernel reinforces the quote you are seeking to challenge.

What definition of "infeasible" are you using?

I’m using the definition that something can’t be done. The comment you responded to was regarding releasing a compiled ko and having it supported by newer kernels. Your response was we solved this by recompiling it.

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

#66

Earlier quoted context omitted.

End users having to connect to the Internet to download the right drivers seems impractical?

Vendors running build farms into perpetuity so that end users can use their hardware with new kernels does seem impractical from where I'm standing, yeah. I don't see vendors supporting their hardware for more than a few years if new kernels need new module builds regularly. Am I misunderstanding what you were talking about?

Yeah I guess we just don't agree on what's practical. For a million dollars over the course of, let's say, five years for support, you could get someone to do this job.

AMD, Nvidia, Broadcom, Virtualbox, VMware, Dell, and Realtek using DKMS for their closed source drivers today, is also where I'm coming from.

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

#67
post #65

Earlier quoted context omitted.

What definition of "infeasible" are you using?

I’m using the definition that something can’t be done. The comment you responded to was regarding releasing a compiled ko and having it supported by newer kernels. Your response was we solved this by recompiling it.

A specific .ko file can't work against arbitrary kernels, no. The customer problem of I have a kernel and this hardware and need a .ko file for it is solvable.

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

#68
post #65

Earlier quoted context omitted.

I’m using the definition that something can’t be done. The comment you responded to was regarding releasing a compiled ko and having it supported by newer kernels. Your response was we solved this by recompiling it.

A specific .ko file can't work against arbitrary kernels, no. The customer problem of I have a kernel and this hardware and need a .ko file for it is solvable.

That’s great but not what the comment you responded to was regarding.

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

#69

Earlier quoted context omitted.

Having used HarmonyOS, it feels totally like Android. Even the back buttom behavior and the app lifecycle feels the same. Some might argue that this is intentional, but to me, this more likely shows that HarmonyOS is just a hard fork of Android without sources released and, likely, with their own virtual machine implementation (ARK instead of ART).

Harmony OS 1-4 were openly Android-based. It's Harmony OS 5 that supposedly is this new thing. Which did you use?

HarmonyOS Next (which I guess is 5). A chinese guy I met at the airport showed to me very proudly how amazing Chinese-made tech was. I will say the software looked polished enough and surprisingly good, yet it felt totally just like a hard android-based OS (which I bet it is).

Some might argue that the software has enough changes in it to be considered a distinct OS, but I'd rather just call it a hard fork as I had the impression that this was a more accurate depiction of what's really going on behind the scenes.

Post reply on HN