291–300 of 902 posts
Earlier quoted context omitted.
> Systemd is DESIGNED to be an all or nothing deal. ^[Citation needed]
Again and again people in this thread have told me that the great thing about systems is that it delivers integrated tools.
Earlier quoted context omitted.
SSH being linked to XZ doesn’t.
My Ubuntu /usr/sbin/sshd already links to libz, liblzma, liblz4 and libzstd. I don't see why linking to libxz would be so outrageous. All-in-all, ldd reports 26 libraries. They attacked the weakest link, and systemd was just a small pawn in that game. Sure, a smaller attack surface is better, but it's not like OpenSSHd has a small attack surface even without libsystemd. Not even in projects with a similar possibility…
Overall, this seems great. However... > [...] by default it will tint your terminal background in a reddish tone while you are operating with elevated privileges ?!! ouch ... seems orthogonal to the actual important parts. Disclaimer: I didn't try it.
I like the idea, but I don't think it should be on by default. The rest of us have just used root-specific shell prompts for the last few decades or so.
[flagged]
You're always welcome to write an alternative if you don't think systemd's direction is correct. Frankly with the number of detractors you could likely form a much larger team to "do it properly" instead! Love or hate Pottering and his team, they're at least writing code instead of postulating on internet forums. systemd's adoption and popularity among many is proof of that
They actually exist. Namely OpenRC and s6 as the main competitors to the core systemd functionality (init). There exist other alternative projects for the other components of systemd as well.
My complaint is that they are adding another tool that depends on their core software in an attempt to replace a portable, well established tool in a non-drop-in way.
This is a consistent pattern with systemd that feels very embrace-extend-extinguish-y and it does nothing but increase the cost involved in keeping code portable between different platforms.
> One could say, "run0" is closer to behaviour of "ssh" than to "sudo", in many ways. This is an interesting offhand comment. You could implement a very similar tool by SSHing to localhost.
Technically `sudo -u` can switch to any user on the system while only a limited few would be allowed as ssh targets. Even root might not be allowed as an ssh target if `PermitRootLogin` is set to `no`, which I do on all my systems.
sudo -H -u user bash
Earlier quoted context omitted.
The follow argument is identical to tail `-f`. `sudo journalctl -f -u `
And what would be the equivalent to, "Oh, I don´t know the name of the log for this process I can see in 'ps aux', let me cd into /var/log and see what filenames I can find ... or grep everything until I can find a couple of words that make some sense so I can keep digging further"? The lack of explorability in journalctl, the "need" to keep everything locked behind their own flavor of tools and magic file types, is…
Systemd and Journald are less opaque than I used to think. Even if you don't want to learn the commands, all of its unit files (and the relationships between them) are available through the filesystem. Most of your unit files will be in `/etc/systemd/system`, and the active relationships between units are expressed through soft links.
Earlier quoted context omitted.
> I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there. > I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar created by logrotate with a date in the filename. My memory of thi…
> journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there Yeah, this is a bit of an odd complaint. If I were this bothered by having to type those, I'd just make an alias to "journalctl --follow --nopager"` and would have forgotten about it years ago.
Which involves glob’ing. I assume it allows to monitor several services at the same time.
Can systemd do that?
systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it? nowadays it's a unit file (basically just an ini file) away with relatively straightforward API. and you can actually declare startup dependencies and other useful relationships past just "prepend a number signifying when it should run…
> remember when you had to write bash scripts to start, stop, restart services This was a really big pain, yes, but I also remember how I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. I knew where the files were, what they were called. I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar cr…
systemd-resolved is the only way I've ever been able to get dockerd to play nice with Tailscale DNS; it's also the best way that I've found to get a system to pick different upstream DNS servers depending on domain. The alternative is hand-rolling it with dnsmasq or something similar.
I admit I haven't really seen a huge advantage to using systemd-networkd over NetworkManager yet, but for servers with relatively static network configurations, I greatly prefer systemd-networkd over any of the various implementations of ifupdown.
Earlier quoted context omitted.
> remember when you had to write bash scripts to start, stop, restart services This was a really big pain, yes, but I also remember how I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. I knew where the files were, what they were called. I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar cr…
> I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there. > I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar created by logrotate with a date in the filename. My memory of thi…
With regular logs, I can go to /var/log, ls the dir, and get a nice list of what's being logged. There will be, for example, an `apache.log` file that has all the logs relevant to apache.