Comment by trealira

2 years ago

What do you mean when you say "fat kernel"?

Also, FYI, OpenBSD is never going to stop being written in C, and is never going to introduce a language like Rust into the kernel [1], so there's little point in wishing for this.

If you wish to rid yourself of legacy of C (and therefore that of Unix), then OpenBSD, which is Unix (or derived from it) and will always be written in C, is not a good operating system for you.

Edit: Changed to be less rude; it wasn't my intention to be rude.

[1]: https://marc.info/?t=151233221700001&r=1&w=2

10 comments

trealira

Reply
arp242  2 years ago

I'm not the person you're replying to, but I don't really mind the kernel (or anything else) being written in C as such, but interacting with C from $other_language can be rather painful for various reasons. In Go the reason they do what they do is because integrating it with how the Go scheduler works is tricky, and getting rid of libc makes cross-compilation a lot easier.

So in short, it's a pragmatic thing more than anything else.

(Aside: that thread is a little bit outdated by the way, as I do believe there's a reasonably complete Rust coreutils implementation now. Not that I think Rust is a good fit for OpenBSD though – I wish people would stop conflating "safety" with "Rust".)

  • trealira  2 years ago

    I understand. I don't actually like it, and I wouldn't want Linux to adopt the same practice; exposing raw syscalls in assembly rather than libc functions allows for a more flexible runtime, since C is a lot more limited (although that in itself invites greater security risk). I was saying that because, if you're asking for more type-safe kernel interfaces and frown upon uses of C, then the OpenBSD team seems like the last people you'd want to talk to. They're true Unix believers, love writing C and assembly, and dislike modern programming languages.

    > Aside: that thread is a little bit outdated by the way, ...

    Yeah, that thread was more to show that they really dislike the idea of replacing C with memory safe language, and instead say that people who can't program safely in C shouldn't be programming.

    bytevolcano:

    > I've always subscribed to the idea that too much safety results in too may idiots, and the same is true for all these "safe" programming languages. "Oh I don't have to write any form of bounds-checking, because the language will do it for me."

    Nick Holland:

    > Idiots who shouldn't be coding, coding. "safe" languages being trusted to be safe when in the hands of idiots. Like you said.

    > The more I see of "safe" languages, the more I love assembly. Most people who call themselves programmers...shouldn't.

    bytevolcano again (in the context of memory safe languages):

    > A good programmer won't even need these languages in the first place. Case in point, the entire OpenBSD dev team. :)

    They'd probably be fine if Go dropped support for OpenBSD altogether; they don't seem to have a high opinion of managed languages or their users.

    • arp242  2 years ago

      Right, I didn't read all messages in that thread before (why don't these archives just present the entire thread in one page?)

      In the end it's just random people posting stuff; you see that on HN as well, but also "it should literally be forbidden to use non-safe languages" on the other extreme end. bytevolcano seems to have just a few posts to the mailing list. Nick Holland is more involved (nick@), but mostly in documentation and that kind of stuff. There are no actual code commits beyond "add fstab example" and that kind of thing.

      I happen to know tedu@ (actual OpenBSD developer) does a lot of Go stuff. I don't want to put words in his mouth, but I'd be surprised if he would come close to agreeing with that kind of stuff.

      Unfortunately OpenBSD has always attracted its share of "ima very smart for using openbsd unlike poor dumb linux penguins!11" type of people.

      In general I don't think OpenBSD people in general would be against safer languages. I mean, they did a lot of work to make a "safer libc" and it includes Perl in base.

      1 reply →

    • bentley  2 years ago

      I recommend against attempting to divine opinions of “the OpenBSD team” from mailing list randos. Theo is the only OpenBSD developer in that thread.

      > They … dislike modern programming languages.

      You based this statement on the words of random commenters. And yet OpenBSD maintains packages for these modern programming languages, and OpenBSD developers spend their free time actively sending patches and bug reports to these language projects to keep them running on OpenBSD. Why not look up the opinions of those people before writing sentences like that?

      1 reply →

MrJohz  2 years ago

Wow, that discussion does not warm me at all to OpenBSD. A lot of those responses seemed way more abrasive than they needed to be.

It's interesting, though, that at least initially, the only examples of memory-safe languages were ones like Java or Python, which are both very high-level and come with a lot of runtime tradeoffs that would practically make them unsuitable to tools like ls or cat that need to be run quickly and a lot. (Also interesting: this never seems to be given as a reason not to use memory-safe languages.) Later on Rust and Ada are discussed, but it feels much more cursory, except in the final comment.

The big reason to use C seems to be that it provides a signal that the developer is competent - you need to be at least good enough to learn C in order to contribute to OpenBSD. And more specifically, if you would rather write code in a non-C, memory-safe language, you are probably a bad developer who should not contribute to OpenBSD. To me, this intuitively feels like quite a weak argument (are there so many people clamouring to contribute to OpenBSD that they need this kind of gatekeeping mechanism?) but it's pretty much the main one that gets repeated. The more convincing argument at the end is that, practically speaking, most of the benefits of memory-safe, low-level languages like Rust or Ada can be provided by static C linters/checkers, and so they don't add much value overall. This seems very much the opposite of what some other companies are saying, e.g. Google and Microsoft, which is that even with static analysis of C/C++, Rust is still dramatically reducing the number of memory safety issues they're running into.

I find it interesting that they don't bring up what seems to be the more obvious reasons not to bring in memory-safe languages, which are mainly the classic "rewrites are hard, here be dragons" arguments - the existing tools have been hardened through years of use, and rewriting them is more likely to add new bugs than remove old ones; new languages/tools means new knowledge which means having people on hand familiar with the new languages to understand what's going on; reimplantation tends to be slow initially, which eats resources and prevents ongoing maintenance and development; etc.

My main takeaways from that discussion are (a) I really hope I never have to work with the OpenBSD maintainers, and (b) their main arguments seem more about maintaining the exclusivity of their club than about the technical details of any transition.