I wonder if there could be some way to sign a dynamic library to allow it to create direct system calls and then pass that as a kernel command line argument at boot?
That sounds like an additional knob to tweak. The OpenBSD project is famously opposed to such knobs.
It is not the only operating system in the "unstable kernel interface" group though. Linux is actually the only one with a stable system call interface.
I've written somewhat at length about this:
And that's just the platforms which technically enforce it. Linux is essentially the only platform which actually supports raw syscalls, in the sense that it's considered a normal system API.
Something they wouldn't have to do if they'd heeded the warnings they got since they first started going raw syscalls on non linux systems.
But as usual, go is uniquely american, only doing the right thing after it has tried everything else.
That doesn't seem like anything common to an American way of doing things. What an odd statement.
No, you could not.
On pretty much every system but linux the libc (or equivalent) is the officially supported API to the kernel. Bypassing it is not supported and thus definitionally can not be sane, that's like declaring that doing the sane thing is avoiding hardcoding against the front door and entering your home through the roof instead. The front door is what you're supposed to use, do hardcode against it. Same with libc.
And Go has been going "ouch" then putting its fingers straight back in the socket from the start, as it keeps trying to work around libcs on all the platform where it is not supported.
Which is a reasonable thing, given that the libc interface is defined by a widely used IEEE standard while the kernel interface is not.
It's wrong to say that Linux stands alone in having a stable syscall interface. FreeBSD [0] and NetBSD [1] both retain syscall compatibility for old binaries (the former apparently with some exceptions permitted); DragonFly BSD also appears to keep old syscalls in place. In fact, I only know of Windows, OpenBSD, and presumably macOS as mainstream desktop OSes without mostly-stable syscalls.
[0] https://wiki.freebsd.org/AddingSyscalls#Backward_compatibily
[1] https://www.netbsd.org/docs/internals/en/chap-processes.html...
Edit: NT with its split OS API dll and separate libc is its own can of worms. You can have multiple instances of libc in the same address space, which among other things implies that you cannot safely malloc() in one module and free() in another, and don't even think about passing FILE* around.
Perhaps this is why most innovations are American. We don't automatically fall for the bully pulpit of the gnostic class.
> Something they wouldn't have to do
Yea, but they'll get it done anyways, and the language will continue to be excellent. I'm sure Google can absorb the engineering challenge without subtracting anything from us or other languages.
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.
It can dynamically link the system32 DLLs in Windows and probably could OpenBSD's crt, but dynamic linking in general doesn't work. `dlopen` is no-op, and this has made Cosmo graphics extremely difficult so far.
https://forums.freebsd.org/threads/what-is-meant-by-abi.8622...
> I keep reading that the ABI of FreeBSD is constantly changing.
> Someone's system has random crashes and someone else says it's that pesky ABI changing again.
It seems FreeBSD has a reputation of changing binary interfaces. Even when they clarified that they meant the kernel-userspace interface, it was pointed out they're only stable for current releases. There seems to be some emulation but I can't figure out how hard of a guarantee that is.
https://docs.freebsd.org/en/books/handbook/kernelconfig/#ker...
> If the kernel version differs from the one that the system utilities have been built with
> for example, a kernel built from -CURRENT sources is installed on a -RELEASE system
> many system status commands like ps(1) and vmstat(8) will not work.
> To fix this, recompile and install a world built with the same version of the source tree as the kernel.
> It is never a good idea to use a different version of the kernel than the rest of the operating system.
How could the ABI be stable if you have to recompile user space when you update the kernel? Linux is said to be able to run binaries from the 90s.
https://old.reddit.com/r/BSD/comments/8vysxg/a_question_abou...
> FreeBSD breaks syscall ABI compatibility with some regularity.
> Like Windows and unlike Linux, the compatibility layer is considered to be libc, rather than the syscall interface.
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".)
Forcing usage of libc is actually an effort towards type safety. `syscall` just takes a syscall number and an unspecified amount of arguments of unconstrained type. It's the opposite of being type safe.
> 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.
Forcing libc has absolutely nothing to do with type safety. How do you think they invoke syscalls in libc? There's no more type checking of syscalls there than there is in Go's standard library. From a user's point of view it's identical, except you don't have to worry about endless glibc version errors with Go.
> 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?
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.
That might be your new point after having yeeted the goalposts out, but it's definitely not your original statement.
> and appeals to tradition don't make it less insane.
This is not an appeal to tradition, it's how things work. If the authors and maintainers of the system tell you something is the supported API, wilfully bypassing that supported API is not "the sane thing", especially when you complain that your bypass blows your face off down the line, then you're an asshole too.
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.
I had assumed you needed permission or else you'd be blocked for posting on a mailing thread, or something like that, so I perceived everyone there except the asker of the question as an OpenBSD developers.
I'm sorry; I didn't realize I was spreading borderline libel.
It's pretty much on-brand for them. The OpenBSD project started when the founder was kicked off of the NetBSD core team, allegedly for being rude and abrasive to users. At one point, both the FreeBSD[0] and NetBSD[1] mailing lists blocked traffic from this individual because they claimed he threatened to aggressively spam their mailing lists.
0 - https://mail-archive.freebsd.org/cgi/getmsg.cgi?fetch=56044+... 1 - http://mail-index.netbsd.org/current-users/1996/10/20/0004.h...
The libc can enforce some minimal sanity checks on the syscall arguments. For example the number of arguments and some early validation to avoid entering the kernel if failure can be foreseen. But the main utility is to make it more difficult to use Return Oriented Programming to build exploits.
I appreciate the feedback. My intention was to maximize the use of space with big fonts even on the desktop but there's no point if the resulting text is unreadable.