Re:Integrating “safe” languages into OpenBSD?
by renox on Monday December 04, 2017 @06:10PM
(#15848446)
I find your post quite funny in the context of the topic..
Re:Integrating “safe” languages into OpenBSD?
by ansible on Tuesday December 05, 2017 @10:31AM
(#15852293)
I totally respect (and have donated to) the OpenBSD project, and ran it for years for my firewall machines. Though these days I'm running containerized Linux firewalls for ease of upgrades. Anyway...
I do understand OBSD's objections to using a new implementation language for their core utilities. And I understand their philosophy for what they're doing and how they're doing it in the general case.
But the fact remains that POSIX, as it has evolved (or not, in some cases) makes writing correct programs harder than necessary. Especially modern multi-threaded programs.
I'd like to see something better and simpler. And maybe written in something other than C.
Re:Integrating “safe” languages into OpenBSD?
by erikj on Monday December 04, 2017 @05:32PM
(#15848172)
Were there any successful attempts to design a brand new and complete OS API in the last decade?
Re:Integrating “safe” languages into OpenBSD?
by pjmlp on Monday December 04, 2017 @05:50PM
(#15848299)
UWP, slow and steady, will eventually get there.
ChromeOS, the OS APIs are the web platform.
iOS, almost everything that matters is done via Cocoa
Android, Java reigns. There is very little UNIX exposed to userspace, less so since Google started clamping down NDK since version 7.
Re:Integrating “safe” languages into OpenBSD?
by 0xcde4c3db on Monday December 04, 2017 @10:48PM
(#15849561)
Not really, but POSIX itself is almost 30 years old (and primarily standardized interfaces that were considerably older), and a lot of interesting stuff happened ca. 1995-2005. See e.g. BeOS or Inferno.
I acknowledge the strong pull to go and re-implement existing standards like POSIX in a new language like Rust.
But, having had to again deal with all the corner cases of signal handling and threads for a Linux application, I encourage any prospective Rust OS developers to pick a different path.
Please, please, let's move beyond POSIX. Give me a sane set of operating system API calls that work in a reasonable way together. And that can compose easily.
So that future developers don't have to deal with file read calls that may (or may not) be interrupted by a signal, and all that.