Boot to Vim, Vim as Pid 1 (2014)
raymii.org
raymii.org
/worth a shot?
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.
Boot to Vim, Vim as Pid 1 - https://news.ycombinator.com/item?id=8335226 - Sept 2014 (5 comments)
https://news.ycombinator.com/item?id=35500297
https://news.ycombinator.com/item?id=35461648
https://news.ycombinator.com/item?id=34527279 (Jan 2023)
https://news.ycombinator.com/item?id=33269207 (Oct 2022)
https://news.ycombinator.com/item?id=30535024 (March 2022)
https://news.ycombinator.com/item?id=29370676 (Nov 2021)
https://news.ycombinator.com/item?id=28441182 (Sept 2021)
https://news.ycombinator.com/item?id=27726982 (July 2021)
https://news.ycombinator.com/item?id=27284079 (May 2021)
https://news.ycombinator.com/item?id=27236708 (May 2021)
https://news.ycombinator.com/item?id=26886074 (April 2021)
https://news.ycombinator.com/item?id=26245003 (Feb 2021)
https://news.ycombinator.com/item?id=26158300 (Feb 2021)
(and yes of course I used the same software to find these)
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 don't know if it is or not myself, just saying how I read that comment.
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.
It’s not 1995 any more.
The system can still boot stuff in the background, even if it's not needed yet.
I'd rather wait until its responsive than have this.
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.
See here for examples of ~100 ms of local latency: https://www.lkhrs.com/blog/2022/07/terminal-latency/
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.
Kitty is so fast compared to anything else I've tried.
Really?
That's a fatal flaw. Skipping lines is never ever OK for a terminal emulator.
Not keeping up can also be a fatal flaw of course!
https://man.archlinux.org/man/urxvt.1
> -ss|+ss
> Turn on/off skip scrolling (allow multiple screens per refresh); resource skipScroll.
> […]
> skipScroll: boolean
> 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.
I'll accept that it is a design feature to get around another failure mode, and that it might even be preferable sometimes.
But it's a serious flaw. Terminal emulators should never drop output, that's what control flow signaling is for!
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.
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.
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!
It might sound silly at first, but it actually makes a pretty big difference!
Even something is simple as drawing text is not that fast on a CPU, a GPU can do it not only faster but much more efficiently too.
I’m guessing you’re amazed positively, given how much everything else has grown/bloated in the last 30 years!
Ha! Old school. It's boring now that we're all pals.
People die, people are suffering. Whole ecosystems are collapsing and you're using VScode...
- Among the stars aboard the Evil flagship (vim)
- On the planet Emacs in the Holy control tower (emacs)
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
You gotta love nerds being tongue in cheek!
This is like exception handling code with the comment:
// this will never happen
I love it.