Emacs standing alone on a Linux Kernel(informatimago.free.fr)
informatimago.free.fr
Emacs standing alone on a Linux Kernel
http://informatimago.free.fr/i/linux/emacs-on-user-mode-linux.html
120 comments
2023 is finally the year of the Emacs operating system on the desktop.
Does it come with a text editor ?
Sure but it's a real bitch to learn though
I literally only opened this article to make sure someone made sure this got asked. Kudos.
Yes, and as a bonus, you develop RSI and carpal tunnel syndrome when using it.
Only if you don’t shell out a couple grand for the space cadet keyboard!
[deleted]
Whoa, desktop?
We're running these on refrigerators.
We're running these on refrigerators.
Nice try but Emacs is actually GNU Emacs and so in the end it's GNU Emacs/Linux.
sorry if i'm out of the loop, but i've heard what you describe as GNU/Linux, not Emacs/Linux. did emacs change to be the branding label of things like the compiler, the ----
just saw that you're probably making a joke, as i just found this :) https://www.gnu.org/gnu/linux-and-gnu.en.html
just saw that you're probably making a joke, as i just found this :) https://www.gnu.org/gnu/linux-and-gnu.en.html
The original joke has been discussed by RMS: https://www.gnu.org/gnu/incorrect-quotation.html
Absolutely genius.
You joke, but an Emacs with framebuffer support and with everything statically build would be Stallman's dream: a next-gen LISP Machine.
Even better - compile Emacs as a kernel module, and run it in ring 0. ELisp would give it memory safety, so memory protection would not even be necessary. System calls have never been so cheap!
Then we could finally live the dream and run Emacs in kernel mode sandboxed inside QEMU.
“Next-gen” is too generous. Such a poor-man’s Lisp machine would be a step back in many ways.
Mine, too!
Before GRUB, (i.e. with LILO), you could easily do this at any time by just booting with the added kernel parameter “init=/usr/bin/emacs”.
I mean, that works and always worked, bootloader really have nothing to do with it (as commandline can be baked into kernel image even if bootloader wouldn't support setting it)
True; what I was thinking of was not GRUB or LILO, but the fact that setting the init process from a kernel command line is less useful for hacks like these if the initial root file system is only an initramfs images from /boot, and does not contain Emacs.
I can't believe nobody posted this quote yet:
"Emacs is a great operating system, lacking only a decent text editor"
"Emacs is a great operating system, lacking only a decent text editor"
It has evil-mode now, so that problem is solved :)
It probably was not posted because it’s untrue. No point in posting inaccuracies. Emacs is a great text editor.
As an Emacs user, I have always hated that joke. It's not funny, because, as you said, it is untrue. Emacs is not only a great editor, but it's also a terrible operating system, lacking multitasking and error recovery in particular (although it's getting better).
Jokes are the unit tests of our understanding. Sure, the gag "fails", but it makes the point of the general usability of the infamous Lisp-machine-in-editor-drag.
It's a joke, it doesn't need to be true, only to have a kernel of truth like all good jokes. And as a recent Emacs convert after years of vim I must say that kernel is there. The breadth and scope of Emacs is extreme. Talking seriously it's obviously not an OS, but it's not an editor either. It's a framework for people to build their editors on. While vim for example is a great editor right out of the box and even the best evil integrations are not 100% up there with it.
[deleted]
What are you talking about, I never use vim any other way!
We need to upgrade this jokes
Emacs on seL4kernel with Plan9userspace and remote desktop to disposable Mac or Linux shortlived desktopui should be very secure for the researcher.
unless you have a hankering for benson&hedges cigarettes.
/me (from outside the loop): "huh?"
Sounds like a reference to The Cuckoo's Egg (fun read).
In 1989 when I was part-time IT staff at Århus University, CS. Dept. we had to turn down a professor who requested doing exactly this with his Sun workstation (it might have been possible, but we didn't have the resources to support it).
My only requirement for my first personal PC (T1800, 386/sx, 4 MiB, monochrome) was that it could run True Emacs (on Linux) - I could certainly have used this, but `exec emacs` achieves nearly the same.
My only requirement for my first personal PC (T1800, 386/sx, 4 MiB, monochrome) was that it could run True Emacs (on Linux) - I could certainly have used this, but `exec emacs` achieves nearly the same.
Fortunately I don't work at universities much any more, but I found IT to be even less accommodating than at a megacorps. My department luckily realised this early on and classed all computers as "experiment equipment" and had our own techs to any necessary admin.
We had to add emacs to /etc/shells because we had users who really did chsh to it.
Well, back in the day you could run Emacs and a Scheme interpreter (MIT Scheme) as a textinfo format under an i386 just fine. No X, of course.
I used to run Emacs on a 386SX, not with X, but with OS/2 Presentation Manager. Had 8MB of RAM, though.
DAIMI! Did you code in TRINE?
This is getting pretty off-topic, but for the record:
I think I was taught that 1st year, or perhaps the predecessor. It's was MIS' first year teaching. IIRC, Trine's array started at 1 and there was much debate over the merits of that vs. starting at zero like C but other than that it was a reasonable language for the time.
I think I was taught that 1st year, or perhaps the predecessor. It's was MIS' first year teaching. IIRC, Trine's array started at 1 and there was much debate over the merits of that vs. starting at zero like C but other than that it was a reasonable language for the time.
I guess in such configuration 8 MB should be enough.
It would be constantly swapping though
> Another, more realistic, alternative would be to use a Common-Lisp implementation with a FFI and portable Hemlock.
Now there is an intriguing idea...
Now there is an intriguing idea...
Fortunately, FFI is fairly well supported in CL: https://cffi.common-lisp.dev/manual/html_node/Implementation...
Yes, using CL+Hemlock as the init process is very doable. That's what makes it an intriguing prospect!
What would be impressive would be exposing a mechanism to make sysctl() and ioctl() work, and control device driver dynamic load. Or, introspect the FS state from the binary.
"just install the command you need in /bin" is cheating.
"just install the command you need in /bin" is cheating.
Actually, you can embed emacs inside of the kernel binary itself.
https://wiki.gentoo.org/wiki/Custom_Initramfs
Then just drop the kernel image onto your EFI partition, and you have a single-binary Linux/emacs system!
https://wiki.gentoo.org/wiki/Custom_Initramfs
Then just drop the kernel image onto your EFI partition, and you have a single-binary Linux/emacs system!
> Typically, an initramfs is not needed, but may be necessary for:
Mounting an encrypted, logical, or otherwise special root partition Providing a minimalistic rescue shell (if something goes wrong) Customize the boot process (e.g., print a welcome message) Load modules necessary to boot (e.g., third party storage drivers) Anything the kernel can't do that's usually handled in user space
So a lot of things which are not emacs.
Mounting an encrypted, logical, or otherwise special root partition Providing a minimalistic rescue shell (if something goes wrong) Customize the boot process (e.g., print a welcome message) Load modules necessary to boot (e.g., third party storage drivers) Anything the kernel can't do that's usually handled in user space
So a lot of things which are not emacs.
But can be used for emacs
Think lua in BSD kernels probably gets what people want
Been a long time since I used emacs (had to stop, it was hurting my pinky) but I did use M-x shell a lot, I always thought it ran bash but from this description I understand emacs has its own shell?!
M-x shell does run bash (or whatever is your user’s shell)
M-x eshell is a shell implemented completely in Emacs Lisp and integrates with Emacs really nicely
M-x eshell is a shell implemented completely in Emacs Lisp and integrates with Emacs really nicely
Did you try swapping or replacing capslock w/ ctrl? Something like this...
setxkbmap -option ctrl:nocaps
xmodmap -e "keycode 107 = Control_R"
This is a useful guide to the different shells in emacs:
https://www.masteringemacs.org/article/running-shells-in-ema...
(the whole site has lots of information about emacs)
https://www.masteringemacs.org/article/running-shells-in-ema...
(the whole site has lots of information about emacs)
While this is a bit silly, I'd love to emacs as a DE option alongside KDE, Gnome etc.
Next: Emacs on bare metal.
Or a CPU that executes e-lisp as it's machine code.
We have had lisp machines, but I don't know of any that run e-lisp specifically.
They did not run Lisp as machine code. They either ran a machine code, which Lisp was compiled to, and/or they ran a Lisp interpreter, which ran Lisp source code. The machine often was kind of a stack machine, with microcode implementing the instruction set.
Correct. But for all practical purposes they were lisp machines, you turned them on and got a lisp prompt, not a basic prompt which was the more common language to boot into back then.
That's right.
What them made Lisp Machines was a mix of things:
* the command interface is based on the Lisp REPL (read eval print loop)
* the operating system itself is written in Lisp
* the instruction set of the CPU is optimized for Lisp (for example via microcode)
* the CPU itself might have hardware support for Lisp (for example for efficient GC)
* the hardware itself (console, keyboard, system bus, extension cards, memory, ...) is used directly from Lisp and might be optimized for it (like special keyboards, special memory cards, special fronted computers, ...)
What's OTOH rarely is the case, that they run Lisp directly in Hardware -> which would mean that the CPU itself is a Lisp interpreter.
What them made Lisp Machines was a mix of things:
* the command interface is based on the Lisp REPL (read eval print loop)
* the operating system itself is written in Lisp
* the instruction set of the CPU is optimized for Lisp (for example via microcode)
* the CPU itself might have hardware support for Lisp (for example for efficient GC)
* the hardware itself (console, keyboard, system bus, extension cards, memory, ...) is used directly from Lisp and might be optimized for it (like special keyboards, special memory cards, special fronted computers, ...)
What's OTOH rarely is the case, that they run Lisp directly in Hardware -> which would mean that the CPU itself is a Lisp interpreter.
Yeesh, reading the top comments, HN really has become the Slashdot I remember. Good times ahead.
Anyway, one thing this brings to mind is how much of Linux is encapsulated within the kernel itself. This is why distros feel so... similar.
Anyway, one thing this brings to mind is how much of Linux is encapsulated within the kernel itself. This is why distros feel so... similar.
I had Emacs running as PID 1 inside of an initramfs roughly around 2010. Had a part of sysvinit reimplemented in Emacs Lisp, for things like ALSA and networking. Kernel + initramfs was roughly 200MB IIRC.
Eight megabytes and constantly swapping
I don't get it. It's Emacs installed on Linux. So what?
The Linux kernel, when it boots, will perform all its setup, then launch a program.
That program has traditionally been `/sbin/init` which launches all background things that need to be running, including your `getty`'s for console login, your `sshd` for SSH login, and your `gdm`'s or what not for GUI login.
Lately it's `systemd` which does the same in a less simple but more flexible/featureful manner.
Here, there is literally no other process running but Emacs - it's your "login shell."
This is the first step in replacing `systemd` with `emacs`, and it will take less space and be easier to use. /s
That program has traditionally been `/sbin/init` which launches all background things that need to be running, including your `getty`'s for console login, your `sshd` for SSH login, and your `gdm`'s or what not for GUI login.
Lately it's `systemd` which does the same in a less simple but more flexible/featureful manner.
Here, there is literally no other process running but Emacs - it's your "login shell."
This is the first step in replacing `systemd` with `emacs`, and it will take less space and be easier to use. /s
Finally, I get to write my init scripts in Emacs Lisp!
You know, .emacs bankruptcy is a thing...
https://www.emacswiki.org/emacs/DotEmacsBankruptcy
https://www.emacswiki.org/emacs/DotEmacsBankruptcy
This is the only actually helpful comment, thank you.
Other than emacs, the only available command on that Linux system is mount. Not even a shell.
Then how are the commands in the code listings executed?
Emacs' `dired` mode might or might not be able to produce a directory listing by itself. However, the author admits that
> Of course, quite a number of syscalls are missing from emacs (not available as elisp primitives), so as it is, it would be hard enough to do EVERYTHING with emacs, but this is a starting point.
> Of course, quite a number of syscalls are missing from emacs (not available as elisp primitives), so as it is, it would be hard enough to do EVERYTHING with emacs, but this is a starting point.
People joke about emacs being an operating system, here emacs is the whole userland
IIRC a single-thread, slow userland that is. Emacs is the only CLI program I've ever run that would take a second or two to render when quickly switching tmux panes. I'll never get the "use emacs for everything" mantra.
I'll tell you I would love if emacs could take over text box input for firefox.
This goes double for crufty enterprise apps that use editor-in-the-browser panes that get in the way or lose data.
This goes double for crufty enterprise apps that use editor-in-the-browser panes that get in the way or lose data.
Have you tried anything from this page? https://www.emacswiki.org/emacs/Mozilla
Weird, I haven't used Emacs for that long and I really feel why I'd want to use Emacs for everything. I don't mostly because it seems annoying to setup the slack integration + SSO and that kind of thing. But I'd definitely want to write all my texts in (evil) Emacs, have all my to-do/Gitlab task/slack reminder /etc in org mode and review Gitlab PRs without ever opening a browser, etc
I absolutely get not wanting to leave the terminal, I'm the same. And I wanted to like Emacs for that. But it's just really slow, and the moment you have a number of buffers with lots of content it's hardly usable. And don't get me started on its terminal emulators, anything with lots of outputs will show on screen at x0.5 speed. I compare with tmux for changing context and it's night and day.
I use the latest versions with native compilation and gave up on terminals and curses codes in favor of plain M-x shells. I tend to accumulate hundreds of buffers, some of them GB size, and all is super snappy. I am very sensitive to latency and can’t stand slow pings, avoid wireless for that reason, and have tuned my keyboards over the years to reduce input latency and errors. Emacs out of the box is super fast. The plain text input loop is in microseconds so not perceptible. And there is hardly ever a need for terminal emulators but when there absolutely is (say htop) then you can use vterm.
With eat I can even run htop. This means I have the typical char, semi-char, emacs-mode while the terminal application is active but as soon as I exit it I'm returned to normal eshell where I can treat it as a mostly normal buffer and evaluate elisp.
It really feels like the best of all worlds.
It really feels like the best of all worlds.
On the terminal emulator front, emacs-eat[1] is also worth mentioning.
[1] - https://codeberg.org/akib/emacs-eat
[1] - https://codeberg.org/akib/emacs-eat
> And I wanted to like Emacs for that. But it's just really slow, and the moment you have a number of buffers with lots of content it's hardly usable.
Do you mean vanilla emacs or a bespoke configuration?
Number of buffers should not slow emacs down and never has across many versions and platforms for me on vanilla emacs.
I would find it hard to believe vanilla emacs was slow switching between lots of buffers. Perhaps if you had 6 windows (as emacs refers to panes) evenly split of minified javascript on a single line it would be slow?
However an issue in my bespoke configurations that has caused the buffer switching issue you mention before is adding a call to the modeline and not debouncing.
Do you mean vanilla emacs or a bespoke configuration?
Number of buffers should not slow emacs down and never has across many versions and platforms for me on vanilla emacs.
I would find it hard to believe vanilla emacs was slow switching between lots of buffers. Perhaps if you had 6 windows (as emacs refers to panes) evenly split of minified javascript on a single line it would be slow?
However an issue in my bespoke configurations that has caused the buffer switching issue you mention before is adding a call to the modeline and not debouncing.
> Emacs is the only CLI program I've ever run that would take a second or two to render when quickly switching tmux panes. I'll never get the "use emacs for everything" mantra.
If you were using tmux, you weren't using emacs for everything!
Emacs for everything also includes replacing terminal with eshell/eat and eventually even frequently curses applications with emacs variations.
If you were using tmux, you weren't using emacs for everything!
Emacs for everything also includes replacing terminal with eshell/eat and eventually even frequently curses applications with emacs variations.
because it does what i want my computer to do.
sure, VI would be faster, but i would have to use vi.
sure, VI would be faster, but i would have to use vi.
vim is also pretty slow these days.
Even after I did the usual toil of analyzing startup times and trimming my vimrc, its speed/responsiveness correlates inversely with the size of the text file that's open. And we're not talking about some artifically-constructed benchmark — just an extra-long ordinary text file (or log file, or code file) sitting around will be enough to make vim start to feel slow.
Maybe we're all just getting old, and the dream of "one text editor for everything" is becoming one of those quaint old notions of yesteryear.
Even after I did the usual toil of analyzing startup times and trimming my vimrc, its speed/responsiveness correlates inversely with the size of the text file that's open. And we're not talking about some artifically-constructed benchmark — just an extra-long ordinary text file (or log file, or code file) sitting around will be enough to make vim start to feel slow.
Maybe we're all just getting old, and the dream of "one text editor for everything" is becoming one of those quaint old notions of yesteryear.
> Maybe we're all just getting old, and the dream of "one text editor for everything" is becoming one of those quaint old notions of yesteryear.
I mean, that's only ever been a dream in the emacs community. Vim might have toy plugins for other stuff, but by and large people use it to edit period. As it should be, isn't the whole UNIX philosophy to do one thing well? If I want email or a text browser in the CLI (I don't) I'll use dedicated, better, faster programs, each on a tmux pane that I can use instantly with a keyboard shortcut, rather than wait for a slow emacs buffer to load.
I mean, that's only ever been a dream in the emacs community. Vim might have toy plugins for other stuff, but by and large people use it to edit period. As it should be, isn't the whole UNIX philosophy to do one thing well? If I want email or a text browser in the CLI (I don't) I'll use dedicated, better, faster programs, each on a tmux pane that I can use instantly with a keyboard shortcut, rather than wait for a slow emacs buffer to load.
> I mean, that's only ever been a dream in the emacs community.
That's not true and not something you could really accurately guess at.
I have exclusively used one text editor for everything (emacs) for many years.
I also know others that have done the same.
That's not true and not something you could really accurately guess at.
I have exclusively used one text editor for everything (emacs) for many years.
I also know others that have done the same.
The problem is one of context. When editing a programming language buffer, the editor needs to be aware of the entire buffer, because a { on the first line could match to a } on the 1235987th line and affect hilighting as well as editing commands like indentation, or sexp navigation. Meanwhile, ideally, in a log buffer the only information needed to nicely render a single line is contained on that line. Or perhaps the log unit is multiline, but still somehow boundable. In that case the editor should be able to do presentation in constant time based on the segment of the buffer that's visible.
Unfortunately, what with logging in JSON and so on, these two cases aren't really distinct anymore. But if I did want to use one editor for both log viewing and coding, I'd pick the one that was the most easily and interactively customizable.
Unfortunately, what with logging in JSON and so on, these two cases aren't really distinct anymore. But if I did want to use one editor for both log viewing and coding, I'd pick the one that was the most easily and interactively customizable.
Wouldn't that be kind of bloated?
This is actually smaller: https://busybox.net
https://re-ws.pl/2020/11/busybox-based-linux-distro-from-scr...
https://re-ws.pl/2020/11/busybox-based-linux-distro-from-scr...
Uhm. On the 2.4 era, you could boot a Linux floppy to play Nethack on it: NeHaBoDi.
https://nehabodi.sourceforge.net/
I wonder if I could do the same with Slashem.
https://nehabodi.sourceforge.net/
I wonder if I could do the same with Slashem.
> Compile mount statically
This is cheating. Why not use also bash when you claim you only use emacs ?
This is cheating. Why not use also bash when you claim you only use emacs ?
RMS essentially uses emacs as his "OS", so this seems a natural conclusion.
this is both cool and exactly why i don’t want to use emacs.
Also, nobody wanted to run the old Firefox-based distro where the userspace (from X up) was in XUL.
Do you actually need mounted rootfs to run emacs though?
Now do Linux standing alone on top of Emacs.
Many computer users run a modified version of the Emacs system every day, without realizing it. Through a peculiar turn of events, the version of Emacs which is widely used today is often called Linux, and many of its users are not aware that it is basically the Emacs system, developed by the Emacs Project.
There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the Emacs operating system: the whole system is basically Emacs with Linux added, or Emacs/Linux. All the so-called Linux distributions are really distributions of Emacs/Linux!