The most interesting work I know of from VPRI is the STEPS project, which aims to design an OS that fits in less than 20000 lines of code:
You may also be interested in unikernel operating systems. The designs vary, but the three points below describe the general idea:
* Existing virtualisation technologies (KVM, Xen, etc...) used to manage hardware.
* OS images run on top of this virtualised base.
* OS images consist of a single software application + a minimal kernel that is customised for the needs of the application.
Unikernel-based software has many potential advantages over traditional OS designs, including increased performance (especially compared to other VM approaches), reduced size, better security (though hacks like Blue Pill would probably still apply). The most active unikernel projects are almost all based on functional languages, so you get the benefits associated with functional development too.
The Xen Project Wiki has a decent introduction to Unikernels:
If you wanted an easy way to get started, this guide on the MirageOS website walks you through setting up a simple web server that can be hosted on Xen:
Is serial port login even enabled by default any more on Linux?
Yes. systemd even provides it automatically if the kernel's console is configured to be a serial port terminal.
In nosh, one simply enables/starts a serial GeTTY service such as mgetty@ttyS1 . There's an example of what such a run script would look like in the "Terminals" chapter of the nosh Guide. It's 2 lines long.
The boot image may be in ROM, and on small embedded devices, it usually is. For QNX, disks and file systems are optional. If disk support is desired, some disk drivers and an init program are included in the boot image, and the later phases of startup are somewhat UNIX-like.
It's possible to build a QNX boot image so that networking comes up before the file system, which is useful for headless embedded systems. It's also possible to build a classic system for x86-type BIOS-controlled boot from disk, and run QNX on the desktop, but that's not done much any more.
How realistic is this on a monolithic kernel like Linux, though? On QNX all drivers - not just the serial ports - are in user-space. QNX has a microkernel.
User-space drivers on Linux are always a special case - like FUSE. Someone always has to write bespoke infrastructure to make it happen.
(If only QNX, the company, weren't so screwed up. They were sold twice, once to Harmon (car stereos) and once to Blackberry. They went open source, closed source, open source, and closed source again. Most developers got fed up and went to other platforms. QNX powers most of Boston Dynamics's robots; when you need coordinated control of all those actuators at 1KHz, you need something at least as good as QNX.)
Moving the line discipline out of kernel mode into application mode does not necessitate that every program have an individual copy of the code. As already pointed out, in operating systems that do this the line discipline analogue is encapsulated within a daemon that presents the terminal character devices (or analogues thereto) to the rest of the system. The programs using the terminal think that they are talking to a terminal device in the ordinary (usually, but not necessarily) POSIX-General-Terminal-Interface-like way. As mentioned, in the Hurd this daemon is the /hurd/term daemon. In Windows NT it is the CSRSS daemon, or a CONHOST.
That's basically how it works now. Kernel's line discipline is awful and nobody wants to use it so they build with readline or something equivalent.
You'll notice a program is using the line discipline when the arrow keys print weird characters instead of working cor rectly, rlwrap has been invented for those programs.
The clean/logical/plan9-style solution is having the terminal implement line editing. But that alone would preclude autocompletion and history search from working.
Only reason its in the kernel is that you couldn't patch a VT-100. Virtual terminals are a lot easier to extend than a web browser, and yet they haven't seen a widely adopted extension in more than 20 years.
Working on it. :-)
Not full readline, but libtinfo, or a similar library that reads a terminfo database. And the standard C library could handle this by default for "cooked" input devices.
That's a distribution choice, but often not. Last I checked on a Debian system, it was just a matter of uncommenting the getty on /dev/ttyS0 in /etc/inittab. Dunno how it's done with systemd nowadays.
systemctl enable serial-getty@ttyS0.service
systemctl start serial-getty@ttyS0.service
As you can see, it followed quite a lot of others.
And, as mentioned, it's not what's under discussion here. It (like the others) uses pseudo-terminal devices, with the line discipline code in the kernel.
I see those often in similar old photos, but nothing in modern electronics looks like that afaik so I wonder :)
I would pay good money for just the his code that transposing/modulating live MIDI loop sequences (e.g. from the bass line).
Why is it called 8-bit music?
> Great article.
Seriously, I don't understand. If I find an article that I find interesting I can just post it multiple times under different URL's?
Is that now acceptable on HN?
> Are reposts ok?
> If a story has had significant attention in the last year or so, we kill reposts as duplicates. If not, a small number of reposts is ok.
It was posted 3 months ago with 31 comments though so looks like that doesn't apply. It's possible that mods didn't see the post (due to the different URL) or that the rules have been relaxed.
As for the downvotes, people in general don't like remarks about reposts because they're off topic and always come off as complaining. It's more likely that most users are seeing something for the first time or if they have already seen it, might not make mind because they like the content.