What do you want to exit for? There’s only two reasons for a software engineer to use a computer: web browsing and Vim.
Since you can already run commands and create files within Vim, there is nothing else to do.
And soon, the web browsing part can be eliminated by running a GPT query to fetch answers to questions, right in your Vim terminal. GPT can dump pages of text right into a new buffer for manipulation.
All roads lead to Vim. You don’t need anything else. Developers used vim 30 years ago and they’ll use it 30 years from now in 2053.
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.
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.
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.
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.
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.
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).
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.
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.
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.
Yes that's important too, but the magnitude of difference is relevant.
A local shell with a non-pathological shell config and a reasonable terminal emulator is snappy-ish.
Most sluggishness can be fixed in shell config. If that isn't working, some terminal emulators are definitely faster than others, especially on Linux with its wide variety of modern and historical choices! And of course tty will always be faster still, but far less convenient.
When all is said and done and properly optimized, it's all probably still slower than the ProDOS prompt on an Apple //e (1MHz 6502 CPU), which can't help but make you wonder what we've all been doing for the last 40 years!
I have all the same config in TTY as in emulated terminal and emulated is nowhere near as snappy and smooth as TTY. Even with GPU accelerated terminals like alacritty, it's a lot better, but still far. If I wasn't working mostly on graphical applications I would just work from TTY.
I remember that urxvt used to be much more comfortable to use than some other terminal emulators whenever a process was spewing out thousands and thousands of lines of text. Some other terminal emulators at the time were very slow because they printed each and every line. urxvt on the other hand would skip printing lines to keep up. This was much preferable. If I intended to look at thousands of lines of text I would do so through a pager. So printing out thousands of lines of text directly into the terminal was almost always by accident.
I have since gotten better at not accidentally printing a bunch to my terminal, so I am no longer using urxvt these days. But for a period of time urxvt was my preferred terminal emulator for that reason.
> True: (the default) specify that skip scrolling should be used. When receiving lots of lines, urxvt will only scroll once in a while (around 60 times per second), resulting in far fewer updates. This can result in urxvt not ever displaying some of the lines it receives; option -ss.
> False: specify that everything is to be displayed, even if the refresh is too fast for the human eye to read anything (or the monitor to display anything); option +ss.
It’s not a flaw. It’s a different kind of use-case than you have in mind.
It’s fine. No one is telling you to use urxvt. You can continue to use whatever terminal emulator you prefer. That’s the power of choice we have. Different programs that do the same kind of things but in different ways.
So there is no reason to insist that urxvt is flawed.
So, yes this has veered strongly into preferences and semantics.
But the job of a terminal emulator is to act as a terminal. Terminals don't drop output in normal operation. That's a failure mode, and maybe it's reasonable or even acceptable.
But the output is imperfect. Imperfections are flaws.
I'm not trying to convince anyone of anything here. Horses for courses, of course.
I'm just surprised to learn that any terminal emulator developer decided that "giving up" is OK. I am sure the other options I can think of were also all considered by the developers, but I'm still surprised.
Nope. Alacrity is probably the terminal emulator that revealed this, but terminal emulation itself is sometimes there bottleneck and GPU acceleration is required to get around the problem.
Amazingly, compared to the joke in https://www.gnu.org/fun/jokes/ed-msg.html, my copy of vim is about twice as big as Patrick's alleged absurdly large copy of vim in 1991 (plus it uses 17 times more space in support files).
This is a terminal emulator within vim. I believe that they meant that a terminal emulator for Vim would be required so that it could handle ANSI escape codes, etc. This is something that a VGA graphics card couldn't handle on its own.
Everybody who takes climate change and environmental protection seriously uses vi or - if they have to - emacs. Every time a VScode session is started the average global temperature goes up by %NaN degrees. Every time a new version is launched the smoldering heaps of electronic waste on faraway beaches rise by a few metres.
People die, people are suffering. Whole ecosystems are collapsing and you're using VScode...
There's an old UNIX hacker trope of Vim vs Emacs "editor wars", where Vim users complain about RSImacs and Emacs users complain about Vimscript. It's a meme that goes very deep (Church of Emacs anyone?), and I'm sure that the Vim bindings for Emacs being called "evil-mode" was done at least partially on purpose. In Spacemacs, the setup option for which keybindings you want even makes it sound like you're choosing a side in a video game:
- Among the stars aboard the Evil flagship (vim)
- On the planet Emacs in the Holy control tower (emacs)
Not the same, but I really dig using vim (neovim) as my terminal multiplexer. Vim has tools for managing windows, splits, all the things, and it felt redundant having two separate tools.
The one thing I needed was a way to attach/detach it, and have it survive across ssh disconnects. I struggled for a while trying to use things like reptyr or others. Eventually I remembered/rediscovered dtach, which is a very thin very simple proxy, as opposed to a full on terminal emulator / multiplexer. https://github.com/crigler/dtach
I like the idea of making self sufficient
app systems like this, especially on old hardware. But I have a dumb question: how do you get the files out of it if you have no networking/drivers?
The addition of :terminal in vim8 makes this surprisingly viable. (If that works properly in this context? There might be some issues with running as pid1.)
