Hacker News Reader

Comment by eimrine | Hacker News Reader

Is this really possible in a real device? I would like to have a typewriter which really can not run anything except of vim.

View on HN

I did something similar years ago, though it may have been under NetBSD.

The important thing to remember is that init is just a program. It is an important program since it does some setup and starts some services, but any other program can take its place as long as it doesn't depend upon the initialization performed by init. For example: the article mentions statically linking Vim. That is because most systems place shared libraries in /usr/lib, with /usr being on a separate partition. Mounting other partitions is part of the setup stage, so programs that use shared libraries are unlikely to work. That is no longer a concern with static linking. (If I recall correctly, shared libraries will still work in such a scenario if the required libraries are on the root partition. Yet that takes much more effort to setup.)

The kernel proper provides enough to run generic programs up to and including a terminal emulator. If you want to run programs with dependencies, you could still bypass init by writing a script that only does the necessary initialization.

> most systems place shared libraries in /usr/lib, with /usr being on a separate partition

It’s not 1995 any more.

I would however say that the justification for using /usr/bin is to simplify the possibility of having most of the system on a separate partition. Merged mounts and namespaces à la Plan9 would be an elegant alternative

Definitely possible but IMHO I would go a teeny bit further and setup a lightweight WM like XFCE or openbox and configure X11 to run FocusWriter on boot (could even configure a systemd user service to ensure it always stays running): https://gottcode.org/focuswriter/ Search around for Linux kiosk mode and you'll see tons of options for booting full screen to an exclusive X11 app. FocusWriter looks amazing and can even turn on typewriter sound effects with every keypress.

Just keep in mind that vim is capable enough to execute other binaries, even start a shell as a subprocess.

I wonder, if processes started in those subshells, even normally terminated, would accumulate without normal init program? I forgot if "reaping" is something special to do.

Pid1 must reap, yes

Really? I think the processes would just accumulate and after some time you require a reset. Imho the same way as WSL-1 (unfortunately WSL-2 is still a no go if using citrix hypervisor) works in Windows.

Okay, not really fair. It mostly works but I till get such on reaped, unkillable processed way more often than in a normal linux.

I think they were agreeing with you that it's a problem.

I don't know if it is or not myself, just saying how I read that comment.

A visual editor might be a bit too much for a typewriter, so clearly we need boot-to-ed.

Maybe it should not support something as progressive as letters as well? Let it be some analog of MS Paint instead of text editor, a rock painting simulator. Fits greatly to a modern smartphone.

Even if it is possible, you still have to wait for your system to boot.

The slowest part of booting these days is waiting on stuff like networking. If you're just loading a graphical or console app, don't care about networking and are on a SSD you can easily boot in a couple seconds.

It's pretty fast though. I experimented with minimal sysv init setups a bit about 15-20 years ago. I got boot times of like 10-15 seconds. This was off mechanical hard drives. Your average system took minutes to boot back then. I'd guess modern hardware would boot basically in a second (after POST).

I wonder when we finally get lazy booting. I.e., services get initialized when they are actually being used.

Pretty much every distro does this now, at least big distros like Ubuntu. Systemd did a ton of work to allow the entire init process to happen as lazily as possible with on demand socket, file and other unit activation. I don't think systemd gets enough respect for just how much it has massively improved booting into a ready machine.

Yeah, all systemd distros do this unless they for some reason are disabling it for specific services.

It makes a big difference too! I have used openrc and systemd on my desktop machine, and openrc by default is synchronous, it starts services one at a time and has to wait for each one to start before moving along. With systemd, it can start services asynchronously and in parallel! The difference in boot time is significant!

Openrc does support parallel startup but it's disabled by default because it can cause dead locks.

I agree. I spent a lot of time working with systemd for work and was perfectly happy with it.

Thats how agents / daemons startup on iOS / macOS. They don't for the most part-up start up on boot or when a user-session is created -- but rather launchd will spawn them when it has to deliver the first message.

I question whether there's any point to that. Would just make the system randomly and inexplicably sluggish until everything been fully initialized. That's a pretty miserable experience.

Why?

The system can still boot stuff in the background, even if it's not needed yet.

That makes stuff sluggish though. I have a laptop that does that. A full minute after it's at the desktop, it can't even render the mouse cursor smoothly, it's so busy doing stuff in the background.

I'd rather wait until its responsive than have this.

Anything is possible with enough work!

Reply on news.ycombinator.com