[HN Gopher] Boot to Vim, Vim as Pid 1 (2014)
       ___________________________________________________________________
        
       Boot to Vim, Vim as Pid 1 (2014)
        
       Author : jandeboevrie
       Score  : 140 points
       Date   : 2023-04-22 01:53 UTC (21 hours ago)
        
 (HTM) web link (raymii.org)
 (TXT) w3m dump (raymii.org)
        
       | grugagag wrote:
       | 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?
        
         | DaiPlusPlus wrote:
         | hexdump files to console and take photos of each page of the
         | screen, then use OCR to read the hex and output raw binary
         | data?
        
           | grugagag wrote:
           | Yeah, that'll do I guess
        
       | zadler wrote:
       | Whenever I have to do something in a TTY I kinda wish my normal
       | terminal experience was that crisp and snappy.
        
         | quesera wrote:
         | It should be, unless you're running too much bash/zsh plugin
         | stuff.
        
           | miniupuchaty wrote:
           | 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.
        
           | petepete wrote:
           | And a terminal emulator with low latency definitely helps.
        
             | arcanemachiner wrote:
             | I can only hope you're referring to network latency...
        
               | codetrotter wrote:
               | 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.
        
               | petepete wrote:
               | I had this discussion with someone on here the other day
               | who flat out believed I'd invented the problem.
               | 
               | Kitty is so fast compared to anything else I've tried.
        
               | zamnos wrote:
               | 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.
        
               | [deleted]
        
               | Rufbdbskrufb473 wrote:
               | Probably not. There are terminals with surprisingly high
               | latency, even on modern hardware.
               | 
               | See here for examples of ~100 ms of local latency:
               | https://www.lkhrs.com/blog/2022/07/terminal-latency/
        
           | zadler wrote:
           | Nah it's probably gnome terminal and the rest of the UI
           | stack, schedulers etc.
           | 
           | See eg https://lwn.net/Articles/751763/
        
             | quesera wrote:
             | 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!
        
         | AlecSchueler wrote:
         | Try different terminals. rxvt is way faster than xterm for
         | example.
        
           | loeg wrote:
           | Enlightenment's terminology is pretty snappy if you don't
           | want to give up too many of the fancier term features.
        
       | theK wrote:
       | > The above statement is ment to start a flamewar. Please do so,
       | see the contact page to contact me.
       | 
       | You gotta love nerds being tongue in cheek!
        
       | Lindby wrote:
       | "If you exit vim, it will restart."
       | 
       | This is like exception handling code with the comment:
       | 
       | // this will never happen
        
       | dang wrote:
       | Discussed at the time:
       | 
       |  _Boot to Vim, Vim as Pid 1_ -
       | https://news.ycombinator.com/item?id=8335226 - Sept 2014 (5
       | comments)
        
         | hsbauauvhabzb wrote:
         | Is this comment automated? If not could it be?
        
           | dang wrote:
           | Nope, but I wrote some software to make it fast for me to
           | find things using HN Search and keyboard shortcuts. This
           | comes up a lot!
           | 
           | 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)
        
           | jojobas wrote:
           | No, but you could bind a key to do it.
        
       | etaioinshrdlu wrote:
       | I bet it wouldn't be too extremely hard to port Vim to
       | https://github.com/jart/cosmopolitan and run it without an OS
       | (BIOS mode in cosmopolitan).
        
         | matheusmoreira wrote:
         | Wouldn't that require implementing a terminal emulator inside
         | vim?
        
           | nixpulvis wrote:
           | https://vimhelp.org/terminal.txt.html
        
             | extinctpotato wrote:
             | 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.
        
         | jandeboevrie wrote:
         | As we say in Dutch, u vraagt wij draaien (your request is my
         | command, roughly translated) :
         | https://raymii.org/s/blog/Bare_Metal_Boot_to_Vi.html
        
       | samwillis wrote:
       | Try exiting Vim when there is nothing to exit to...
        
         | [deleted]
        
         | xwdv wrote:
         | 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.
        
           | CapstanRoller wrote:
           | vim cannot display cat pictures and therefore is, by core web
           | standards, unfit for purpose
        
         | mftb wrote:
         | ...but then the difficulty of quitting Vim becomes a feature.
         | Can't crash the system by exiting, if you can't exit (taps head
         | meaningfully). /s
        
           | goalieca wrote:
           | Execute tmux using vim shell command. Kill -9 vim
           | 
           | /worth a shot?
        
             | xorcist wrote:
             | PID 1 is special and can not be killed with signal 9 for
             | security reasons. See kill(2).
        
             | mftb wrote:
             | lol, the nuclear option. You don't mess around, but really,
             | I think the answer is, never quit Vim.
        
         | BuildTheRobots wrote:
         | It's less effort, but I've been changing `init=/usr/bin/vim` in
         | grub to mess with people...
        
       | duskwuff wrote:
       | 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.)
        
       | mftb wrote:
       | > As we all know, nobody uses emacs.
       | 
       | Ha! Old school. It's boring now that we're all pals.
        
         | unixhero wrote:
         | Everybody uses Vscode, even Carmack. That war is over.
        
           | alpaca128 wrote:
           | What war?
        
             | voidz7 wrote:
             | editor wars!
        
           | krylon wrote:
           | But it's not the standard editor! (SCNR)
        
           | mftb wrote:
           | That's the spirit! (but I can't help it if you've mistaken a
           | cleverly disguised web browser for a text editor.)
        
           | the_third_wave wrote:
           | 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...
        
           | divan wrote:
           | Until they discover AstroVim (:
        
       | eimrine wrote:
       | Is this really possible in a real device? I would like to have a
       | typewriter which really can not run anything except of vim.
        
         | bschwindHN wrote:
         | Anything is possible with enough work!
        
         | graypegg wrote:
         | A visual editor might be a bit too much for a typewriter, so
         | clearly we need boot-to-ed.
        
           | eimrine wrote:
           | 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.
        
         | theK wrote:
         | Just keep in mind that vim is capable enough to execute other
         | binaries, even start a shell as a subprocess.
        
           | codesnik wrote:
           | 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.
        
             | guipsp wrote:
             | Pid1 must reap, yes
        
               | mike256 wrote:
               | 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.
        
               | Brian_K_White wrote:
               | 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.
        
         | qbasic_forever wrote:
         | 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.
        
         | II2II wrote:
         | 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.
        
           | midasuni wrote:
           | > most systems place shared libraries in /usr/lib, with /usr
           | being on a separate partition
           | 
           | It's not 1995 any more.
        
             | ObscureScience wrote:
             | 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 a la Plan9 would be an elegant alternative
        
         | amelius wrote:
         | Even if it is possible, you still have to wait for your system
         | to boot.
        
           | qbasic_forever wrote:
           | 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.
        
           | marginalia_nu wrote:
           | 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).
        
             | amelius wrote:
             | I wonder when we finally get lazy booting. I.e., services
             | get initialized when they are actually being used.
        
               | marginalia_nu wrote:
               | 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.
        
               | amelius wrote:
               | Why?
               | 
               | The system can still boot stuff in the background, even
               | if it's not needed yet.
        
               | marginalia_nu wrote:
               | 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.
        
               | qbasic_forever wrote:
               | 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.
        
               | [deleted]
        
               | ktm5j wrote:
               | I agree. I spent a lot of time working with systemd for
               | work and was perfectly happy with it.
        
               | pmalynin wrote:
               | 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.
        
       | hestefisk wrote:
       | I'd rather boot to ed because ed is the standard editor.
        
         | schoen wrote:
         | 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).
        
           | mtrower wrote:
           | Actually, he's talking about vi, not vim. You're a whole
           | 'nother rung up the ladder with vim.
        
             | schoen wrote:
             | That's fair, since I could still run various more
             | traditional vis and they'd be significantly smaller.
        
           | plugin-baby wrote:
           | > my copy of vim is about twice as big as Patrick's alleged
           | absurdly large copy of vim in 1991
           | 
           | I'm guessing you're amazed positively, given how much
           | everything else has grown/bloated in the last 30 years!
        
       | [deleted]
        
       ___________________________________________________________________
       (page generated 2023-04-22 23:02 UTC)