sortie

Author here. Sortix is Sortix. MINIX is MINIX. I think each project has different goals and that's fair.

Some thoughts though, for my os-test project I went and installed every free software Unix-like OS and ran a lot of tests on each of them and got experience with each of them.

I don't really consider MINIX a relevant OS. It doesn't have a 64-bit port. The site doesn't offer HTTPS and only has MD5 checksums, so there clearly isn't an attention to security. Sortix offers HTTPS downloads with SHA256 checksums and is up front about its lack of security (next release will do release signing). The latest MINIX release is from 2014, which is a bad project health sign. My latest release is from 2016 (been a bit busy since I got a full time job, but the next release is still being made if at a slower pace, and nightly builds are available and supported). The stable Minix 3.3.0 was pretty buggy and things got better after I upgraded to the Minix 3.4.0 prerelease. The os-test data revealed a bit of a lack of attention to detail in the UDP stack.

I don't think MINIX is really trying to be a more generally used system. It used to be more of an education system, which lead to Linux. I have no plans to make Sortix widely used either, but I avoid making mistakes that prevent adoption as part of the general good work. I want to make a good OS that I personally like.

I'm happy to be compared to systems like MINIX, Haiku and GNU/Hurd. The ideal reaction to someone mentioning Sortix support should be "Eh, Sortix is cool but who cares? I guess I can do it if trivial". And that's fine, at least they heard of it. I'm a one person project with a small community but I think I'm competing reasonably in this space. I don't really consider Minix that usable. GNU/Hurd is alright but the GNU project is notoriously bad at actually releasing an OS themselves with any sort of technical vision and quality. Haiku is pretty interesting, though it seems to be focusing more on being BeOS than being a general purpose system (it doesn't have a multi user support for instance, which Sortix does have, though with a few security vulnerabilities). They're all different projects with different goals and strengths and I try to make Sortix better whenever I can do it.

I want Sortix to have a really good and inclusive community. I enjoy the coding but I really enjoy putting the whole OS together and building a whole project and community.

Yep. I already have an issue about virtio filed at <https://gitlab.com/sortix/sortix/issues/473>. Not too high priority to implement but something I'd love to get to. Feel free to post additional hints there if you have additional tips for when I get around to doing it.

Author here. Like in Linux, libc provides errno on Sortix. The difference is that glibc does "#define errno (*__get_errno_location())" while Sortix libc does "__thread int errno;". linux syscalls return a negative value containing the negated errno, while Sortix system calls use two output registers: The return value register and the errno register. That allows Sortix system calls to legitimately return -42 if they want, which is not possible on Linux. Sortix libc assigns the errno register to the thread local errno if the errno register is non-zero.

Author here. POSIX requires errno to be thread local, but with few requirements. Commonly libc's #define errno (*__get_errno_location()). Why? It's because the thread local storage isn't online very early on. The libc literally has to open its own program executable and locate the the thread local storage and mmap a copy of it for each thread. Thread level storage comes online late in Linux, which bloats statically linked executables with code to parse their own executable.

In Sortix, I just have the kernel set up the TLS for statically linked executables and just declare errno as:

__thread int errno;

That means errno is online from the very first instruction in _start in statically linked executables, without the need to parse the program file in early libc. There's no error conditions between _start and main. This is the kind of implementation quality I want to have in Sortix and part of why I develop Sortix.

Author here. I'll probably omit the word 'modern' in the next release. Not for the reasons listed here, but because a bunch of stuff purports to be modern while forgetting the lessons of the past.

I implement POSIX not for the sake implementing POSIX, but because it allows me to port a lot of the software that's already written. The core POSIX specification is fairly alright and not that intrusive in my design, the worst parts of POSIX are in optional sections like XSI that I simply omit implementing. I implement a lot of extensions found in Linux and BSD that enhance upon POSIX, while also providing a few of my own. POSIX doesn't say anything about the ABI and doesn't prevent other languages. Atomic file operations are dear to my heart and something I'd like to extend upon in Sortix. Note that POSIX does specify rename(2) is atomic. I implement POSIX when it's convenient and omit doing so when not.

I'm happy to acknowledge the limitations of Sortix up front. It's important to establish this level of honesty early on to set the right expectations and establish trust. I warn up front about the security problems in Sortix (that exist at this time). If you follow the documentation, you should get predictable results with no nasty surprises.

I think Sortix is suitable for education projects. There's some more clean ups that can make it better. But it's of a reasonable size, it doesn't have that many dirty hacks, and it's fairly well organized.

Author here. Yep, though the network stack hasn't yet been merged to the master branch (but that's next and it'll be in the next stable release).

Author here. Yep, I don't want to force a particular bootloader on anyone. The bootloader is a piece of software owned by the system administrator, not necessarily by any of the several operating systems installed side by side. If I force a bootloader on the user, that makes dual boot configuration harder, and it's important to allow that. I happen to follow GRUB's multiboot specification, which has the advantage that a lot of bootloaders implement it. It's not perfect though and I'll probably invent and adopt my own bootloader protocol in the future, but the sysadmin's choice of bootloader continues to be important on my mind.

Thanks! Be sure to let me know what you think.

I used to start new coding projects weekly to play with one thing or another, not getting anywhere. With Sortix, there's now so many interesting areas to work on that I can work on whatever I fancy, and then still slowly accumulate useful changes. It's fun working on the components, but it's also fun putting a whole system together, and you learn a lot in the process.

Thanks! You shouldn't, but it could be an addition if you want something to tinker with. I've been dogfooding with it, for instance completing my functional programming university course using just it and a scheme port. I discourage comparisons because it sets unrealistic expectations rather appreciating it for what it is. This release is a base for future work and to be something that can benefit me in other ways.

Thanks! As Zikes say, a little competition is good and gitlab is working out fine for me. I used to be on gitorious and it got bought by gitlab so I moved. I prefer being on a platform I can theoretically port.

This is entirely undesirable. First of all, char16_t and char32_t are kinda useless as there's no standard interfaces using them, and there's no conversion functions to and from wchar_t.

Secondly, no, you're asking for a massive addition of 2 new versions for every interface that mentions wchar_t. That's a huge addition to standard libraries. That's error prone and bloats things up. Then additionally you're asking for a rewrite of all software using wchar_t. And only until everything is transitioned, which isn't going to happen, the standard libraries will be much larger.

The solution is rather to embrace wchar_t and fix it. All sensible and modern platforms, which is a premise of this article on modern POSIX functions, have a 32-bit wchar_t type. That's excellent. It's only Windows, which due to historical short-sightedness that have 16-bit wchar_t. But writing portable C for native Windows is a losing game, the winning move is not to play. (Do see midipix which is upcoming and will provide a new POSIX environment for Windows with musl and 32-bit wchar_t). In fact, 16-bit wchar_t violates the C standard. That moment you give up broken platforms with 16-bit wchar_t, wchar_t works as intended, and this is a non-problem. Embracing char16_t and char32_t is a worse problem and isn't solving anything.

I deliberately didn't write that to avoid the page going stale when OS X adds it. But OS X is behind the times and that's harmful. POSIX 2008 has been out for years and most of the lacking features are trivial to add. They're being actively harmful to Unix software by not having modern interfaces, forcing portable software to be worse. The purpose of the article is to highlight the interfaces, and when they're suited, rather than being a replacement for your system manual page or a portability guide. Since OS X isn't a free software Unix (though its libc is), I don't really consider it among the relevant modern Unix systems. Linux, the BSDs, and so on all have the POSIX 2008 features mentioned here.

As in the article, strncpy has valid uses, but it's widely misunderstood due to the poor name. strlcpy is what the name suggests. People are also surprised by the zero padding.

mbtowc isn't necessarily thread safe, it's better to recommend mbrtowc.

Just use setlocale(LC_ALL, "") in main, and use mbrtowc to translate from whatever the system encoding is into the wchar_t type. There's no need to bake assumptions about the system encoding into most programs.

char16_t and char32_t are useless. The C standard declares functions in <uchar.h> for converting them to and from char, but not wchar_t. The conversion to char may be lossy depending on the platform. No other interfaces uses those types. There's no portably lossless path converting them to and from wchar_t.

No, it's important to understand the distinction between char and wchar_t. Both are relevant, but in different contexts. char should be considered a byte type to pass around UTF-8 with. This is the appropriate level for the large majority of common string operations, such as concatenation, outputting strings directly, parsers that only handle ascii characters specially, and so on.

Those applications don't really care about the actual unicode codepoints besides ASCII. If you start to deal with visual representation of strings, calculating the column for error messages, advanced unicode-aware parsing, font rendering, and so on, then you do want to convert on the fly to wchar_t. mbsrtowcs and such are kinda bad, because they convert the whole string at once, which means an allocation that can fail in the unbounded case. It's usually sufficient to decode one wchar_t at a time with mbrtowc.

This way, char and wchar_t are not replacements for each other, but complement each other by being better abstractions for various purposes. Now, the wide stdio functions is where things start to get a bit useless, because the regular stdio char functions are perfectly fine and those functions don't really appeal well to the strengths of wchar_t.

gnulib is atrocious beyond belief though. I hear GLib tends to abort your process on OOM, though I haven't done my research on this library, so I would be careful using these to develop reliable software.

Whether C is appropriate is highly depending on the project and context. Higher level languages offer a lot and should be used when appropriate.

But when C is appropriate, and these problems arise, which they will in any C codebase of appreciable complexity, these string creation interfaces are waiting for you, and will help you write correct code. It's usually a worthwhile effort to reconstruct higher level abstractions in C, in a good manner, for the same reasons you use them in higher level languages.

Note that statically allocating everything is hardly always possible. See the distinction between bounded and unbounded in the article, the unbounded case is really common.

I use that POSIX 2008 edition myself, and the PDF edition that I got through my university library subscriptions. I simply look up interfaces and headers in it. It's not a gentle introduction though to POSIX programming. But if you know the basics, it's useful to look up in. I generally use the http://wiki.osdev.org/Cross-Porting_Software method when porting new stuff, that is, I just cross-compile it. I see what doesn't compile, look it up in POSIX, and implement it.

I appreciate you actually trying my OS and leaving a comment. chvideomode really should work under VirtualBox. If there's a bug on my end, I would really like to fix it. Could you show up in #sortix on Freenode IRC for a debugging session?

I assure you there are plenty of room for designing your own operating system even if you implement POSIX. POSIX is a pretty reasonable minimal system interface for C programs. I osdev for fun and to challenge myself and I find a very ample supply of interesting things to work on. If I went and did something different, perhaps in another language, it would likely be equivalent to the POSIX system concepts largely, except custom and probably worse. If I really wanted a custom design, I would want it to be at least a magnitude better.

Also to get your OS into space. That's definitely on the bucket list.

I'm not trying to gain users. Sortix 0.9 is not permanently installable on real hardware from itself. The upcoming release will contain an installer for permanent installation, however. You are quite simply not my audience. Even if I did aggressively market myself, my OS will not be useful to most. If you installed it, you would quickly want feature X, such as networking or a GUI, and feel disappointed it does not live up to your unrealistic expectations. This is a small hobbyist operating system. The people I want to attract are capable developers and power users willing to actually put Sortix to use.

My utility function is to write a good operating system that I like. Any effort towards that goal is not wasted. If I can use it on my computers, which I can, I'm happy. Note the existence of secondary benefits. Sortix libz is a cleaner fork of zlib, and other portable replacement libraries are underway. Other hobbyist OS developers learn from my work and advise. I make third party projects more portable and file upstream bugs. These things benefit all of us, regardless of the market share of my OS.

Who ate the Apple logo?

Sortix is because I want to write a good operating system that I like myself. I do like if it's generally useful.