this is imo required experience if you want to say you understand/know linux: knowing how most distros handle/run processes & services & user sessions. systemd defines the modern linux experience.
I am running quite some stuff for multiple customers on systemd on arch. And I must say that generally the ride has been smooth and pleasant, and we have been doing that for years.
I for one is not looking back at the sysv script spaghetti with fondness...
>Thought it managed to standardise the linux ecosystem on one behaviour: nothing works by default
Except that in reality, everything works, all the time, and most of the reason that it does is due to all the hard work and good design put into systemd.
> 1.5k bugs, with a dozen showstopper blockers at any time
If you look at successful open source projects, you will see that all of them have thousands of bug reports open, and most of them will never be even touched by a developer. You simply can not imply anything about the quality of an open source software project by that metric, only that it's a successful.
I've been using Linux since 1996, and compared to the mess that was before systemd, I'm very happy about it. My remaining hopes are that wayland would finally kick xorg to the ditch where it should've been 10 years ago and that pipewire (or whatever) sorts out the audio problems (like they should've been sorted out 20 years ago).
I'm on linux since y2k, and I attest. "Nothing works by default" is the default system behaviour of systemd distros on anything, but the most standard x86 system.
I worked with laptop makers, and systemd manages to brick the system in ways not even imaginable on regular init. No HDA codec, and pulseaudio hangs DBUS? Brick. Systemd's agetty analog not seeing serial port? Brick...
> xorg to the ditch where it should've been 10 years ago and that pipewire (or whatever) sorts out the audio problems (like they should've been sorted out 20 years ago).
I would argue that Pipewire can make a decent display server, way better than what Wayland currently offers for just the way it manages IPC.
> If you look at successful open source projects, you will see that all of them have thousands of bug reports open, and most of them will never be even touched by a developer. You simply can not imply anything about the quality of an open source software project by that metric, only that it's a successful.
Proper open source projects fix their bugs bugs. GNOME had millions of users at the peak, and it's core projects seen under 100 bugs. And that's for a major C codebase. SystemD on other hand, manages to go through several major releases with unfixed memleaks. I can only have unflattering words about its quality, and project maintenance practices. I have simply no other words: It's garbage, utter garbage.
> brick the system in ways not even imaginable on regular init
Init before systemd didn't do dependencies in most distros (or at least not in a serious way), so this goes both ways. Systemd can get stuck waiting for something, but initd broke by YOLOing the startup and hopeing things work. There are good points for either approach.
The issue count though really doesn't mean much. What's the boundary of core even? gnome-shell has 1.1k open issues right now while systemd pid1 has 404 of them. Where does the 100 come from? Then the tagging, auto-closing, project management style, etc. come into play. It's a silly metric.
I am surprised and confused this isnt a wrapper of systemd 'machinectl'. The functionality seems similar except the port forwarding automation as far as I can tell. Really nice tool to have for development though!
WARNING! I just tried installing debian/bullseye with this. Networking inside the distro was not working. Even worse, when I tried using my main WSL2 Ubuntu distro to do work, networking broke there too. BAD. I'm on Windows 11.
UPDATE: rebooting seems to have fixed the issue on my default distro. (wsl -t Ubuntu was not enough)
Hi! Thanks for trying Distrod! I've reproduced the problem except the part that it affects other distros. As a workaround, restarting the distro you installed should solve the problem.
`wsl --terminate Distrod`
The problem was caused by the fact that /etc/resolv.conf was not initialized during installation. Updated the README.md about the workaround. I'll publish the proper fix soon.
Thanks for trying Distrod again!
Alpine is not a systemd-based distro, so Distrod will not implement Alpine-specific initialization. However, try `$ echo '' | sudo tee /etc/network/interfaces` and `> wsl --shutdown`. It will fix the network of Alpine. For network issues on other distros, the document to fix network will help. https://github.com/nullpo-head/wsl-distrod/blob/main/docs/re...
While this is useful, shouldn't we fix the main problem instead?
Unlike the original WSL, WSL2 uses virtuaization. Then why does Microsoft feel they have to do such major changes to Linux instead of letting it run as-is?
On WSL2, Microsoft has their own init with another container launched for multiple reasons:
- That other container, the WSL system distribution has a Wayland and a PulseAudio server for graphics integration.
- in a regular WSL config, the VM completely closes 60 seconds after the last terminal is. If you have daemons running, that cannot be guaranteed to work anymore.
- compatibility of distributions across WSL1 and WSL2, the former which has a significantly lower feature set.
Cool but I wonder what the use case for this is. People who run services like nginx or mysql on their WSL? My understanding of systemd (and init systems in general) is they're not really useful for much beside launching daemons and keeping them going.
25 comments
[ 3.0 ms ] story [ 36.4 ms ] threadIts strangler pattern is real, but the landscape is so much greener as a result.
Very happy to see support for it on WSL2.
After many years of systemd, I truly believe it has made Linux significantly worse.
Thought it managed to standardise the linux ecosystem on one behaviour: nothing works by default
1.5k bugs, with a dozen showstopper blockers at any time
Although, during that era, the same issues were hella common on Ubuntu systems etc as well.
I for one is not looking back at the sysv script spaghetti with fondness...
Except that in reality, everything works, all the time, and most of the reason that it does is due to all the hard work and good design put into systemd.
> 1.5k bugs, with a dozen showstopper blockers at any time
If you look at successful open source projects, you will see that all of them have thousands of bug reports open, and most of them will never be even touched by a developer. You simply can not imply anything about the quality of an open source software project by that metric, only that it's a successful.
I've been using Linux since 1996, and compared to the mess that was before systemd, I'm very happy about it. My remaining hopes are that wayland would finally kick xorg to the ditch where it should've been 10 years ago and that pipewire (or whatever) sorts out the audio problems (like they should've been sorted out 20 years ago).
I worked with laptop makers, and systemd manages to brick the system in ways not even imaginable on regular init. No HDA codec, and pulseaudio hangs DBUS? Brick. Systemd's agetty analog not seeing serial port? Brick...
> xorg to the ditch where it should've been 10 years ago and that pipewire (or whatever) sorts out the audio problems (like they should've been sorted out 20 years ago).
I would argue that Pipewire can make a decent display server, way better than what Wayland currently offers for just the way it manages IPC.
> If you look at successful open source projects, you will see that all of them have thousands of bug reports open, and most of them will never be even touched by a developer. You simply can not imply anything about the quality of an open source software project by that metric, only that it's a successful.
Proper open source projects fix their bugs bugs. GNOME had millions of users at the peak, and it's core projects seen under 100 bugs. And that's for a major C codebase. SystemD on other hand, manages to go through several major releases with unfixed memleaks. I can only have unflattering words about its quality, and project maintenance practices. I have simply no other words: It's garbage, utter garbage.
Init before systemd didn't do dependencies in most distros (or at least not in a serious way), so this goes both ways. Systemd can get stuck waiting for something, but initd broke by YOLOing the startup and hopeing things work. There are good points for either approach.
The issue count though really doesn't mean much. What's the boundary of core even? gnome-shell has 1.1k open issues right now while systemd pid1 has 404 of them. Where does the 100 come from? Then the tagging, auto-closing, project management style, etc. come into play. It's a silly metric.
https://www.freedesktop.org/software/systemd/man/machinectl....
UPDATE: rebooting seems to have fixed the issue on my default distro. (wsl -t Ubuntu was not enough)
Unlike the original WSL, WSL2 uses virtuaization. Then why does Microsoft feel they have to do such major changes to Linux instead of letting it run as-is?
- That other container, the WSL system distribution has a Wayland and a PulseAudio server for graphics integration.
- in a regular WSL config, the VM completely closes 60 seconds after the last terminal is. If you have daemons running, that cannot be guaranteed to work anymore.
- compatibility of distributions across WSL1 and WSL2, the former which has a significantly lower feature set.
Anyway, I feel a much better solution would be to "fix" systemd.