Pulseaudio was also replaced relatively quickly by pipewire.
I really wouldn’t say that… PulseAudio has been around since like 2004, and PipeWire’s initial release was in 2017 (13 years later). I don’t think PulseAudio was incorporated into most distros by default until like 2007 or so, but that’s still 10 years before PipeWire was even released. PipeWire is only recently becoming the default in popular distros. We’ve had to deal with Pulse for a long time.
Oh man you reminded me of bad init scripts that would prevent you from getting to multi-user login. I hope you remembered your root password so you can get into single user mode!
They weren’t that bad. You had to look in like 3 places, depending on the distro, but you could find them. And you could see exactly what they were doing once you found them.
systemd gets a job done but I’d much prefer something simpler.
pulseaudio, an powerful but complex audio management daemon in Linux whose name you only recognize because it’s caused you no end of trouble. Pulseaudio was also replaced relatively quickly by pipewire.
PulseAudio never gave me trouble but I guess I’m just lucky or some shit. Also PipeWire took forever to come out.
In games after I press button to shoot, animation plays and then eternity later comes shooting sound when animation ends. JACK compared to PA is super responsive in games, direct ALSA reduces lag by additional 15ms.
init scripts were so simple they could be understood just by looking at the name: the computer is Initialized by Scripts. Systemd was much more complex and allowed many more tools to interact with the different parts of the computer, but people had to learn these tools. Previously all a person had to understand to deal with the computer was how to edit a text file and what various commands and programs did.
It’s complex because it solves a complex problem. before people had to hack that together with complex init scripts, now they can let systemd do the hard work.
Yep, to add on as well as summarized this… Linux has historically had a design methodology of “everything is a file”. If your not familear with the implications of this, it means your command line tools just kind of work with most things, and everything is easy to find.
For instance, there’s no “registry / regedit” on Linux… There’s just a folder with a config file that the application stores settings in. There’s no control panel application to modify your network settings… Just a text file on your OS. Your system logs and startup tasks were also (you guessed it) sinole filea on the system. Sure there might be GUI apps to make these things easier for users, but under the hood it reads and writes a file.
This idea goes further than you might assume. Your hard drive is a file on the file system (a special file called a block device). You can do something like “mount /dev/sda1 /home/myuser/some_folder” to “attach” the drive to a folder on the system, but that special block device (dev/sda1 in this case) can be read and written to byte by byte if you want with low level tools like dd.
Even an audio card output can show as a file in dev (this is less the case now with pipewire and pulse), but you used to be able to just echo a raw audio file (like a wav file) and redirect the output to your audio device “file” and it would play out your speaker.
Systemd flipped this all around, and now instead of just changing files, you have to use applications to specify changes to your system. Want to stop something from starting? Well, it used to be that you just move it out of the init directory, but now you have to know to “systemctl disable something.service”, or to view logs " journalctl -idk something.service" I dont even remember the flags for specifying a service, so I have to look it up, where it used to just be looking at a file (and maybe use grep to search for something specific)
Want to stop something from starting? Well, it used to be that you just move it out of the init directory, but now you have to know to “systemctl disable something.service”,
That is still the case, nothing stops you from manually moving a file and its dependencies into or out of /etc/systemd/system/
Systemd flipped this all around, and now instead of just changing files, you have to use applications to specify changes to your system. Want to stop something from starting? Well, it used to be that you just move it out of the init directory, but now you have to know to “systemctl disable something.service”, or to view logs " journalctl -idk something.service" I dont even remember the flags for specifying a service, so I have to look it up, where it used to just be looking at a file (and maybe use grep to search for something specific)
not true, SystemD still uses files for this very reason…
and what is the last time you used the text version of a syslog.8.xz file?
you are basically complaining that you need to learn how your system works… before you can use it. and there is nothing preventing you from making your own distro that doesn’t uses SystemD, or using rSyslog instead of systemd-journal for logging.
want to see the status of a daemon : systemctl status want it for the system systemctl status
want to see the logs of only a specific daemon journalctl -xefu. this all, means that its easier to find the logs for diffrent services since there not scattered somewhere in the /var/log dir… (is it in the syslog, does it have its own log file, is it in the kernel log)…
You are free to setup your system in whatever way you like… but whining about that something works differently is “Microsoft mentality”… lets leave that with them.
Systemd flipped this all around, and now instead of just changing files, you have to use applications to specify changes to your system. Want to stop something from starting? Well, it used to be that you just move it out of the init directory…
Enable and disable just create symlinks of the “just changing files” files in your example. It tells you this every time you install something that enables a service.
Want to do it manually? ln -s (or rm the link to “disable” it).
Want it to happen later in the init sequence? Put the link in a different .target directory.
All “systemctl enable” does is put the symlink in the target directory that’s specified in the Install section of the unit file.
As for “specifying a service”… Everything is a unit file (yes, file), journalctl -u just means “only show me logs for this unit”.
There’s no flag for “specifying a service”, you just type in the service name. If there’s any ambiguity (eg. unit.service and unit.socket), you type the service name followed by .service
A flag you might find useful is -g, which means “grep for this string”. You can combine this with -u to narrow it down.
Not the really the point of your post but I personally tend to use journalctl -fu something.service. That brings you to the end of the logs for that unit and I get to smile about flipping off systemd.
so “relatively quickly” is a time span of 13 years in your idea… or the difference between 2004 and 2017.
if that’s your level of detail… your whole “rant” is worthless…
But lets be generous and look into it,
init scripts were so simple they could be understood just by looking at the name
this is blatantly false, for the old system you need to know about runlevels, what they mean, how the half backed init annotations work, and its dependency check works.
### BEGIN INIT INFO# Provides: myrec# Required-Start: $all# Required-Stop:# Default-Start: 2 3 4 5# Default-Stop:# Short-Description: your description here### END INIT INFO
you needed special tools to watch if an application actually was running and not crashed, and to keep it running.
add to that that the difference between systemd.service file and a sysv / init / initd script is more or less the same complexity (just different standards).
the universal format for log files was plain text
false, the universal format for logging was plain text…
which is currently (slowly) getting replaced with structured logging. (which is objectively better, imho).
there are a number of different log formats, most use a binary (compressed) format. logging to plain text was generally only used for the most recent log entries.
a binary format for logging, as long as there’s is tooling to get it to a (structured) textual output, is better than a pure text log. I mean, if its good enough for MySQL / MariaDB it ought to be good enough for you…
The log files only have binary markers within the text. You could run the raw log files through strings and get the plain log files with everything important intact.
To ask a different question… what was wrong with initd? I’m the better part of a decade stale at this point but I don’t know that I ever ran into an edge case that initd couldn’t handle with a little massaging
Pottering is also the person behind pulseaudio, an powerful but complex audio management daemon in Linux whose name you only recognize because it’s caused you no end of trouble. Pulseaudio was also replaced relatively quickly by pipewire.
Powerful? No, JACK is more powerful and was created 2 years before pulseaudio.
For context back then OSS was primary audio api, and unlike ALSA it did not have software mixing. So sound servers were created. Lots of sound servers, so it was and still it yet another sound server without extra functionality. Meanwhile dmix existed since at least 2001 and JACK allowed route output of one application to input of another.
At least pottering is working for Microsoft, ruining windows now…
Removed by mod
I really wouldn’t say that… PulseAudio has been around since like 2004, and PipeWire’s initial release was in 2017 (13 years later). I don’t think PulseAudio was incorporated into most distros by default until like 2007 or so, but that’s still 10 years before PipeWire was even released. PipeWire is only recently becoming the default in popular distros. We’ve had to deal with Pulse for a long time.
Removed by mod
Init scripts were simple? Man you haven’t seen a bunch of shitty init scripts then.
Oh man you reminded me of bad init scripts that would prevent you from getting to multi-user login. I hope you remembered your root password so you can get into single user mode!
Simple doesn’t mean well done. Badly written code can be simple but still bad
gayHitler420 taught me something today. thank you for this informative comment
Except it is clearly written by someone who just despises it, and doesn’t really know what they are talking about.
Init scripts were awful… they varied by distro and frequently were the source of odd problems.
There’s a good reason the Linux industry moved away from them to other ways to handle initialisation of the system and service management.
They weren’t that bad. You had to look in like 3 places, depending on the distro, but you could find them. And you could see exactly what they were doing once you found them.
systemd gets a job done but I’d much prefer something simpler.
PulseAudio never gave me trouble but I guess I’m just lucky or some shit. Also PipeWire took forever to come out.
In games after I press button to shoot, animation plays and then eternity later comes shooting sound when animation ends. JACK compared to PA is super responsive in games, direct ALSA reduces lag by additional 15ms.
Lennart Poettering
Removed by mod
It’s complex because it solves a complex problem. before people had to hack that together with complex init scripts, now they can let systemd do the hard work.
A comment from an Arch Linux’ init script maintainer: https://www.reddit.com/r/archlinux/comments/4lzxs3/comment/d3rhxlc/
Yep, to add on as well as summarized this… Linux has historically had a design methodology of “everything is a file”. If your not familear with the implications of this, it means your command line tools just kind of work with most things, and everything is easy to find.
For instance, there’s no “registry / regedit” on Linux… There’s just a folder with a config file that the application stores settings in. There’s no control panel application to modify your network settings… Just a text file on your OS. Your system logs and startup tasks were also (you guessed it) sinole filea on the system. Sure there might be GUI apps to make these things easier for users, but under the hood it reads and writes a file.
This idea goes further than you might assume. Your hard drive is a file on the file system (a special file called a block device). You can do something like “mount /dev/sda1 /home/myuser/some_folder” to “attach” the drive to a folder on the system, but that special block device (dev/sda1 in this case) can be read and written to byte by byte if you want with low level tools like dd.
Even an audio card output can show as a file in dev (this is less the case now with pipewire and pulse), but you used to be able to just echo a raw audio file (like a wav file) and redirect the output to your audio device “file” and it would play out your speaker.
Systemd flipped this all around, and now instead of just changing files, you have to use applications to specify changes to your system. Want to stop something from starting? Well, it used to be that you just move it out of the init directory, but now you have to know to “systemctl disable something.service”, or to view logs " journalctl -idk something.service" I dont even remember the flags for specifying a service, so I have to look it up, where it used to just be looking at a file (and maybe use grep to search for something specific)
That is still the case, nothing stops you from manually moving a file and its dependencies into or out of
/etc/systemd/system/not true, SystemD still uses files for this very reason…
and what is the last time you used the text version of a syslog.8.xz file?
you are basically complaining that you need to learn how your system works… before you can use it. and there is nothing preventing you from making your own distro that doesn’t uses SystemD, or using rSyslog instead of systemd-journal for logging.
incidentally, to just view the logs its
journalctl -xef(see https://man7.org/linux/man-pages/man1/journalctl.1.html for what that means) it will be like the syslog you know.want to see the status of a daemon :
systemctl statuswant it for the systemsystemctl statuswant to see the logs of only a specific daemonjournalctl -xefu. this all, means that its easier to find the logs for diffrent services since there not scattered somewhere in the /var/log dir… (is it in the syslog, does it have its own log file, is it in the kernel log)…You are free to setup your system in whatever way you like… but whining about that something works differently is “Microsoft mentality”… lets leave that with them.
Enable and disable just create symlinks of the “just changing files” files in your example. It tells you this every time you install something that enables a service.
Want to do it manually? ln -s (or rm the link to “disable” it).
Want it to happen later in the init sequence? Put the link in a different .target directory.
All “systemctl enable” does is put the symlink in the target directory that’s specified in the Install section of the unit file.
As for “specifying a service”… Everything is a unit file (yes, file), journalctl -u just means “only show me logs for this unit”.
There’s no flag for “specifying a service”, you just type in the service name. If there’s any ambiguity (eg. unit.service and unit.socket), you type the service name followed by .service
A flag you might find useful is -g, which means “grep for this string”. You can combine this with -u to narrow it down.
Not the really the point of your post but I personally tend to use journalctl -fu something.service. That brings you to the end of the logs for that unit and I get to smile about flipping off systemd.
so “relatively quickly” is a time span of 13 years in your idea… or the difference between 2004 and 2017.
if that’s your level of detail… your whole “rant” is worthless…
But lets be generous and look into it,
this is blatantly false, for the old system you need to know about runlevels, what they mean, how the half backed init annotations work, and its dependency check works.
### BEGIN INIT INFO # Provides: myrec # Required-Start: $all # Required-Stop: # Default-Start: 2 3 4 5 # Default-Stop: # Short-Description: your description here ### END INIT INFOyou needed special tools to watch if an application actually was running and not crashed, and to keep it running.
add to that that the difference between systemd.service file and a sysv / init / initd script is more or less the same complexity (just different standards).
which is currently (slowly) getting replaced with structured logging. (which is objectively better, imho). there are a number of different log formats, most use a binary (compressed) format. logging to plain text was generally only used for the most recent log entries. a binary format for logging, as long as there’s is tooling to get it to a (structured) textual output, is better than a pure text log. I mean, if its good enough for MySQL / MariaDB it ought to be good enough for you…
The log files only have binary markers within the text. You could run the raw log files through strings and get the plain log files with everything important intact.
Removed by mod
What is the systemd replacement you mention?
Removed by mod
dont forget OpenRC
Removed by mod
and openrc too, i tried it once in artix
To ask a different question… what was wrong with initd? I’m the better part of a decade stale at this point but I don’t know that I ever ran into an edge case that initd couldn’t handle with a little massaging
Removed by mod
Powerful? No, JACK is more powerful and was created 2 years before pulseaudio.
For context back then OSS was primary audio api, and unlike ALSA it did not have software mixing. So sound servers were created. Lots of sound servers, so it was and still it yet another sound server without extra functionality. Meanwhile dmix existed since at least 2001 and JACK allowed route output of one application to input of another.
You know what? I wich him luck.
Simple fails when complex problem arrives. Declarative approach of systemd daemons allows for more versatile solutions in unified format.