Hacker News Reader

Comment by simion314 | Hacker News Reader

Still makes no sense to me to spend energy into pushing Rust into Linux instead of creating some new better kernels, I mean having some of this big companies paying a few experts to do such a kernel and keep compatibility with user applications. If Rust is much better then C and adding on top the fact you start fresh with no baggage you should get a better Linux and everyone would use it since is safer and faster especially on servers.

I don't know of such a Rust kernel being worked on that is not some hobby side project but something more like Servo was, where you have paid experienced in domain developers.

View on HN

Sorry for the snark in advance. Do you have an idea how many man years of work are in Linux? The estimated cost of developing it was 1.4 billion dollars in 2008.

https://www.linuxfoundation.org/press-release/linux-foundati...

Not that I do not have respect for Linux, but that doesn't sound like much in an age when we're reading about modern aristocracy buying up useless microblogging platforms for forty-plus billions. :)

So... a patronized kernel from a wealthy kernel enthusiast?

I think the point is that if the Linux kernel "costs" say 4 billion to make, that it's perfectly within the capabilities of a company if they would see the value in doing so - which has been greatly reduced because Linux works so well for so many people and companies.

But if Walmart needed a kernel for some reason, and it would provide value to them, they could afford it, it's about a quarter's worth of profit. But, again, Linux would likely do anything they needed, and if it was missing something they could add it.

the monetary cost is misleading. you can't take 4 billion dollars and use it to hire developers for a year and then expect something equivalent to the linux kernel after a year. money doesn't actually translate on its own into valuable things - people have to actually do work to make that possible. and not every task is infinitely divisible such that it can be worked on in parallel by many hands.

the actual cost is in person-years of work, not dollars, and even then you can only speed up the time it takes so much by throwing money at the problem.

>money doesn't actually translate on its own into valuable things - people have to actually do work to make that possible.

This is highly unintuitive. I don't understand how Windows's Explorer (the file manager) has been for many years and is still to this day vastly inferior to Dolphin, a Linux file manager made for free by five Dutch guys or whatever. I can think of many other examples.

If anything, it seems like more money results in less quality, by way of some tragic sociological paradox. :p

when people make things because they want to, they make things that other people actually want to use. when capital directs people to make things, they do so for the purpose of creating more capital. we pretend that "making money" and "making something useful" are synonymous but they're not. look at advertising - an entire industry where nothing useful is produced but billions of dollars are spent simply manipulating people's wants and needs. at some scale, people stop being able to self-fund these projects - it's when that threshold is crossed that people start making what seem like truly bizarre decisions to hamstring the use-value of their own products, because they're instead trying to maximize their exchange value instead.

Why not, if it's released under a good open license?

Elon Musk is not in the OS business.

Sure , but that all those years of work are not of creating new stuff, there is a lot of work on just modifying existing code and not breaking stuff.

You do not need to get all Linux features at start, I would focus on the server stuff, support the popular server hardware and popular server work so filesystems and networking. I would hope some competent developers would write a new kernel from scratch then getting 10% of some Linux rustiffied. When you edit shit you need to make sure not break shit, so you are limited, you move slow and you have to implement backwards compatibility. Amazon,Google,Facebook could work on this if they care for security but probably using VMs is cheaper for them.

That sounds pretty cheap actually.

Of course the Linux Foundation would say that the cost of developing Linux is a cool billion. They make money from Linux training after all. They want you to know: You're getting your money's worth.

"starting fresh with no baggage" also means starting fresh with no drivers. Having drivers for a wide range of hardware is a major factor in operating system adoption.

Didn't FreeBSD incorporated an interface that allow to use Linux drivers?

Not that I think it would make the point of having a bright new kernel easily compete with such a huge and firmly grounded project as Linux though.

All the more, there already are multiple projects using Rust to build OSes out there, if I'm not mistaken.

I was not suggesting this kernel to be used on laptops, it would be a server kernel, if it would actually be faster and safer then Google and Amazon will use it on their servers and they will make sure there are drivers, Google could use it in some mobile devices too if they care for safety. AMD has an open source driver so if desired that could be ported to Rust to also make sure the GPU is safe.

Things work the opposite way. In order to get companies to adopt things you need to get people working their interested in it. Which means they need to be able to run it on their PCs. There's a reason why x86 ate the world.

The exception to this is when you can develop something and have a good case to use it yourself, like Google and Fuchsia. But I doubt Fuchsia will gain wide organic adoption because of the same factors.

>Things work the opposite way. In order to get companies to adopt things you need to get people working their interested in it.

This would mean that the only OSes are first created by hobbyists, then fanboys use it then a company adopts it. But there are commercial OSes and commercial software that are created by a company to solve a problem and not by random dudes and companies then adopts it.

IMO is sad that we the tech industry are stuck with old OSes and old architecture while you have this giants that use open source software to make billions and they could find researching and creating of a few new revolutionary OSes like it happened in the past. And I don't mean desktop OS that will defeat Windows.

Name a single successful (non-niche, stuff like INTEGRITY doesn't count) OS kernel created post-Windows NT 3.1 that's commercial. Even Mac OS X still runs Mach as a kernel. The model is dead, because of the internet. OSes have MASSIVE network effects.

There's several proprietary RTOSes in most every computer. There's one in the baseband on your phone, though it might be an L4 fork.

I don't think you understand the scope of what you're talking about. Linux is tens of millions of lines of code, most of which is drivers that have to be written by vendors.

Vendors aren't going to write drivers for your hobby kernel. No one is using your hobby kernel. Bootstrapping a new kernel without billions of dollars to invest in development time is almost impossible, and anyone who is investing billions of dollars is likely going to have dubious proprietary reasons for doing so.

A successful kernel is Rust is probably the worst thing that could happen to the open source community.

Could a new kernel implement a compatibility layer of some kind for Linux drivers? Or just expose the same API?

Not very easily: Linux quite deliberately does not have any stable internal driver interface, so any such compatibility layer would have a very fast moving target to keep up with.

>I don't think you understand the scope of what you're talking about. Linux is tens of millions of lines of code, most of which is drivers that have to be written by vendors.

But if you are Google and you believe that this Rust kernel is super safe and fast and has clean code, and parallelism,async and candy ... how many drivers do google Data centers use ?

After you prove the kernel is real good by using it in data centers and devices that need security you can slowly expand, for most devices you could create soem compatibility layer. Who knows if there are soem competent developeres hired to work on it they might use some better architecture, like keep the drivers outside the kernel.

We simply don't have better kernels. POSIX is the epitome of infrastructure. That's it. We did it. It's like asking for something more than Turing completeness - we have everything, just optimise the existing code. To that end, introducing Rust is a pessimization.

It would be good if APIs like open and creat existed that took something safer than null-terminated strings.

Even if kernel devs are careful to avoid the usual pitfalls, it's just a bad API that encourages use of null-terminated strings elsewhere. If you're using other, better string types elsewhere, you often need to make copies to then make system calls (the article hints at that with the addition of a CString type).

What's wrong with null termination? No, seriously. It's much cleaner than wasting an argument, hence CPU register, for a second pointer. Or heavens forbid, two size_t length and capacity counters.

Other than the usual arguments [1], I just said that it causes contamination of other APIs. That's a big problem because string is a "vocabulary type". It is passed around across various libraries within a given process constantly. There should be a lot of convergence on vocabulary types to avoid copying string data around incessantly.

Null terminated strings are a poor choice to converge on for high level application code in particular. It's just an inefficient (expensive substrings, redundant length calculation, unclear ownership) and unsafe default for too many use cases.

I don't mind certain performance sensitive applications using C strings to avoid extra registers, though even that is a premature optimization in certain situations.

[1] See Limitations: https://en.m.wikipedia.org/wiki/Null-terminated_string

How do I pass a sub-slice of a source string to a function that expects a null terminated string without copying or modifying the source string?

I don't understand the question. Sub-slices are not sub-strings. They are partially constructed objects. But I do get the problem.

The question is the problem: how do you do zero-copy sharing of data contained within a string. You can’t unless you couple it with the length. In rust parlance a slice is a well defined type.

There are also other reasons why having the length embedded in a string (or a string slice) is a good thing. You might want your “str_contains” function to do something different with different sized inputs: doing some vectorised lookup might only be worth it at a certain point, or if the length of the needle is greater than the haystack itself then there isn’t much point doing anything.

NULL terminated strings are a huge mistake that brings in security issues, needless copying and inefficient code that might contain several redundant strlen calls at different levels.

Copying is almost always the right answer here.

- you can't assume inline storage of the substring, which is more efficient, because that'd mean overwriting the parent string with a size field

- you might free the parent string early unless you keep around a reference to it, which is more expensive

- usually strings (esp. substrings) aren't that long, and for very long ones you can use a different data structure

Except Cloud as OS doesn't care about POSIX at all, only type 1 hypervisors.

The basic POSIX interface works, but it's hardly optimal. It has a lot of weird built-in assumptions that we're just so used to working around that it's hard to imagine it being any other way.

As an example: why can a process only have one current working directory? Wouldn't it be nice to be able to have a process maintain pointers to two or more locations in the filesystem at once? Wouldn't it make software more modular if a library could "chdir" into some directory without worrying about breaking the application that depends on it? The filesystem APIs could be extended with a "CWD" handle argument that can be passed around sort of like a file descriptor instead of having one implicit CWD for the whole process.

The same could be done with UIDs. Why not have processes that can use multiple UIDs? Again, you could have UID parameters to API functions that require authorization.

POSIX is pretty good by the standards of 80's computers, but in a lot of ways it's showing its age. We can do better. But it's kind of depressing that OS interface design is treated as a solved problem, and so those interfaces stagnate.

It's a consequence of living in a society where everything is about money. You absolutely could build a better operating system, but doing so wouldn't make you any money, so nobody can afford to do it.

> The filesystem APIs could be extended with a "CWD" handle argument that can be passed around

Why would you even want a working directory at that point?

What's the alternative? To use absolute paths for everything? That seems kind of tedious, and may be slightly less performant if the kernel has to do more dentry lookups.

I think the idea of a current working directory is a reasonable one, it's just that the limitation that a process can only have one CWD at a time is kind of arbitrary when you think about it.

I could even see having commands that take multiple CWDs. Like a move operation could take a source and a destination CWD as an alternative to specifying source and destination paths.

Directory file descriptors already exist. I wouldn't call them "current working" directories though. Are you suggesting an expansion of those, or something different from those?

Reply on news.ycombinator.com