When I was using EXWM it felt like the closest I have ever been to an Emacs as an Operating System. But why would I want something like that in the first place?
It’s not just being able to control my desktop in a keyboard driven matter with shortcuts I’m familiar with. Because from what I hear, Gnome desktops are pretty keyboard driven. It’s the idea of being able to control my entire Operating System, from programming in it, navigating it, interacting with it, and running the shell through it, all seamlessly with minimal context switching through one interface.
It’s fun to try to get there with Emacs sometimes, even if in my heart I know it’s not what it was meant to do.
Might also suggest looking at GNU Guix (as a packager manager or full distro). Then the whole system will be build on Guile Scheme too! I'm a recent convert and have been loving it.
Edit: and yes, their installer lets you select EXWM as your window manager right from the get go.
GNU Guix package manager is very interesting - https://guix.gnu.org/en/videos/2020/everyday-use-of-gnu-guix... ... Thanks for rec. There are so many interesting GNU projects that remain unpopular due to lack of publicity and / or poor UI / UX that it's sad when you consider the amount of man hours went into developing these projects.
Looks like they only serve webm video without fallback. So now when you aren't using a browser with webm it doesn't play the video and doesn't show any helpful message either. One could argue "but freedom!" and then we'd still have a terrible UX.
In my Emacs config I redefined one of internal Emacs functions which is responsible for creating new windows (panes in more common parlance), which I think is superior, and I'm working more efficiently, rearranging windows less frequently than before (not to mention with other window managers)[1]. That's something I don't get outside of Emacs.
[1]: Efficiency is probably second priority though to getting rid of the annoyance of windows showing up in weird places making everything around hardly legible. Prior to the customization I felt as if I was pair-programming with an angry gremlin who would keep making a mess on my desk. Now I have more peace of mind.
For something more serious, there's GNU Shepherd [1] which is written in Guile (a Scheme) [2] and uses Guile as it's configuration language [3]. It is used as the init system for the Guix System (which is based on the Guix [4] package manager, similar to Nix.)
I find BusyBox init perfectly acceptable and small. I use it extensively as init for lightweight containers. It supports just enough init to handle complex or simple config.
Does tini offer something better? On quick glance it seems rather limited.
More seriously, it would be great to have the good parts of systemd (logind, ability to control containers, the runner of unit files) implemented independently and without the "invasive" parts like control of DNS or binary logging.
Reverting to a different resolver isn’t difficult on something like Fedora and even manually editing on other distributions wouldn’t be that bad. Logging is a per application basis and I’ve found most things easily support syslog. So, both wishes granted.
It is trivial to disable systemd-resolved on any distribution, as well as making systemd-journald disable its logging to forward everything to syslog. I wonder what the GP post's difficulty was?
Just the usual gripes about systemd which get perpetuated by people who don't bother understanding the thing they're annoyed about. Sadly you could say the same thing about pretty much any topic on the internet these days.
> who don't bother understanding the thing they're annoyed about
This is the root cause of the problem. Regular initd + rc scripts are simple enough to be understood by everybody, which systemd is too complex to understand in the limited time we have. There is no "systemd senior developer" or "systemd solutions architect" positions for systemd developers, to adjust investment into systemd ecosystem.
We can easily replace initd by something much more powerful, like perl, javascript, python, java + spring, Emacs, or even Firefox or Eclipse in headless mode. They all are able to read configuration files and launch new processes. But (almost) nobody does so, because they are hard to debug and have very large surface.
>Regular initd + rc scripts are simple enough to be understood by everybody, which systemd is too complex to understand in the limited time we have
On a modern distro, I wouldn't say so, there is so much you would need to add on top of an rc script to get it to work correctly. Once you start trying to make use of the same capabilities it becomes just as complex as systemd, if not moreso. This is beyond just turning it into perl or javascript, I'm talking about OS-level features: for example even a basic Linux feature like mount namespaces is non-trival to do in an rc script and have everything get mounted and cleaned up correctly with all the right settings, whereas this is one or two lines in a systemd unit, and you know it's always going to work. It doesn't help much if you implement it in a shell script or in python versus having it in a systemd unit, this is code someone has to write, and if you say "it's too complex I don't understand it" then that would be limiting you because you're not using the intended security features of the OS. Does that explain it?
IMO there's a huge gap for an init that does process management in a container using systemd files without needing the SYS_ADMIN privilege.
I've wanted this for some scenarios where I'm bridging the gap between VM/OVAs and containers, and would like a single rootfs to be able to serve in both capacities. Basically all the current options are not great:
* Make invasive changes to move the container-relevant stuff to another init system.
* Make invasive changes to run a systemd instance in user mode in the container.
* Run the container as privileged.
* Something something podman (not an option for k8s).
What is the problem with binary logging? Would you prefer the ordinary text files and the great pain of properly filtering through something like only this services’ output, from this date to that, only warnings, etc? But that is only one part, what about the performance/stability of the whole thing? Afaik continuously appending to a file is not the greatest thing, especially if you have to move files around from time to time.
It’s also not like journald uses some secret format.
One problem I can think of with binary logging would be catastrophe. I have had to pull HDs, go through the logs, line by line and piece together what happened in those final moments.
Text logs are easy to get at, I don’t need a special program to read, I just need something to display a raw byte on the screen.
Also, I wonder what the actual performance benefits are. I remember back when most protocols were text and/or binary. Usually binary was slower when messing about with stringy stuff. For example, using memcached to cache strings. Why encode/decode strings in a binary protocol when you can just use strings all the way down? I don’t know if that premise is still true, but for us older people, it makes sense to keep inherently stringy stuff stringy to avoid overhead.
>Text logs are easy to get at, I don’t need a special program to read
I've seen this type of comment a lot on reddit and I don't understand why people say this. You do not really need a special program to read the systemd logs either, in the event that journalctl doesn't work you can easily use `strings` to read the logs. Feel free to try it right now just for fun, the binary format of journald is actually extremely simple and well-documented and just stores the logs sequentially, it's not "encoding" the strings at all. Why would it need to? It's all fulltext data.
Re the failure part: you can just plug in any USB stick with a normal linux distro and it will read it out just fine.
Re performance: Strings are most defintely worse than some fixed size format. It’s not an accident that FPGAs were used to serialize/deserialize XMLs, why Google made a whole new binary protocol, etc. Just think about it, you have to parse a string character by character (yeah some clever vector magic can make some string processing go a few chars at a time), while a binary format with fixed layout will be practically random access. You can query the nth entry, etc.
I'd prefer it to be a separate independent component, the way syslogd is. (Yes, I know that in systemd the binary logging can be switched off, or even replaced with a different implementation.)
I care mostly about having an independent implementation with a different internal architecture, narrower scope, and a separate governance.
The reason it is not “independent” is that it logs even during boot.
Something which simply was not solved with the previous generation of init systems and is greatly important. During booting the file system may not even be mounted, it could hardly be done by a separate process.
>I'd prefer it to be a separate independent component [...] with a different internal architecture [...] and a separate governance
Not sure I understand this, do you mean you would use something that had the exact same feature set, if the internal architecture was different and if someone else was maintaining it? What would be the point of that? Are there some performance or security improvements to the architecture that were suggested upstream that they aren't doing?
>narrower scope
Not sure I understand this either, the scope of journald is actually quite small, there are many syslog implementations that are bigger and have a lot more features.
Not necessarily exact same, and maybe not necessarily having the same problems (such as corruption).
There is a reason that certain things have multiple implementations compatible at the level of key interfaces but different inside. Examples: cron and anacron, more, less, and bat, different NTP implementations, different syslogd implementations, to say nothing of the variety of DNS, SMTP, and HTTP servers.
I'm not sure what you mean corruption, journald logs should actually fare better in terms of dealing with corruption and tampering versus text logs, if you use the log sealing feature. You could also already easily plug any of the syslog implementations in.
Perhaps he is talking about modularity - systemd is a bit all or nothing, it is a pluggable system yes but (AFAIK) it is not modular so you can't write arbitrary software and have it adhere to some standard, instead you have to use the systemd libraries and link against systemd calls.
So it is another layer on top of the kernel in that sense.
The old alt was to put the shell in charge and bash or sh talked to a bunch of random programs. Which is in some ways more modular but also a bit of a nightmare...
I'm not certain anything like that exists, you would have to define some data architecture almost, maybe involve hardware like ACPI and UEFI...
But that goes back to nobody basing their career over how a computer boots...overly complex. Maybe better just to improve systemd instead.
They corrupt easily and there's no repair method built into journalctl (or anywhere else, really).
The format also does not have any kind of indexing or cache and this is the reason `systemctl status <service>` can take 15s to show the last 10 log lines if you have a few GBs worth of logs.
Well, if you are asking for every log of a given service no matter when was it made, it sure will take time - and I don’t see how indexing or cache would help it (create one specific for each service? That would in practice multiple the size of the logs)
Specify that you only want to last day or so (which is quite likely what you actually want), but I do agree that the default could be something sane like only the last week.
For me, it's less that it's binary and more that it's some bespoke format specific to journald instead of, say, an SQLite database or something else similarly widely-used and well-known.
Does it enjoy good support from the apps? IIRC every app has to be compiled with support for a particular audio system (e.g. OSS, ALSA or PulseAudio). Do many apps provide PipeWire-compatible versions already?
And yet, most who have tried Pipewire and commented about the experience online report that Pipewire via PulseAudio APIs does the job better and with less bugs than PulseAudio.
Latency is measurably better than PulseAudio even via pipewire-pulse.
edit: I think the confusion is over my use of the word "shim". Pipewire doesn't route through PulseAudio, it replaces PulseAudio but includes an implemenation of the same API. There's no increase in latency or complexity because there's no extra steps.
What was the problem being solved by choosing such a strange stack? Can someone explain why this generation(of which I am part of) builds weird things? "Show HN: ARM16 kernel built using brainf*ck compiled on PDP-11", "Show HN: Lisp inspired language that uses the Chinese character for monkey instead of parentheses".
There are a lot of useful things to be build, but does everything has to be quirky in some form? Are we so limited in our imagination, that we decided the ultimate artistic achievement is to be "different", not good different, just weird different? I don't find it funny, I don't find this creative, it's just different for the sake of being different. We are, if I may use the term, in a baroque era of software development. Instead of going for efficiency, simplicity and extracting the essential, we go for the unusual, uncalled for, uncanny and unconventional.
RMS also created GNU which is used by billions today. Neither Linus, nor RMS, nor anyone who ever started these well known "hacker" project in their basement/university did things just for fun. Despite all the downvotes, I think it's useful to remember that.
I think I see what you mean: There's a lot of potential for better (free) software, especially outside the "software for software developers" domain. Compared to that, a "quirky thing" seems insignificant. But consider the following: The author of a quirky thing probably learned a lot about the tech and working around the constraints they put on themselves which is, in a way, education. Plus, quirky stuff probably attracts other people to learn about its tech more than something "serious".
Apart from that, I think a lot of commercial software development is even more "useless". In the sense that, a lot of software is reinvented without any real improvements or much "educative benefits" for its developers.
I would argue that if the comercial software authors manage to convince someone to pay money for it, it means that someone is extracting some value which allows them to pay for said software. It also means that someone is investing time to learn, to install, and finally to use that product.
It's not just about the products themselves (although some products are probably also just clones of something that already existed with better marketing) but rather about everything a software company does in general. Think websites, random general-purpose code and development processes. I think there's a lot of repeated effort in those areas that could be avoided if we all magically knew about each other's problems and worked on common solutions. (Note: I don't think that will ever really happen.) Publicly available frameworks and libraries are sort of that although there's still a lot of "grunt work" overall.
My point wasn't that commercial software is actually useless though. More like, in the grand scheme of things, even something that's just quirky for the sake of being quirky is kinda useful.
It’s not just being able to control my desktop in a keyboard driven matter with shortcuts I’m familiar with. Because from what I hear, Gnome desktops are pretty keyboard driven. It’s the idea of being able to control my entire Operating System, from programming in it, navigating it, interacting with it, and running the shell through it, all seamlessly with minimal context switching through one interface.
It’s fun to try to get there with Emacs sometimes, even if in my heart I know it’s not what it was meant to do.