LemmyHead

You can set the space limit for journals logs really low then, to avoid double space usage. As for the last argument, that also was an issue for me years ago because not all tools were compatible with the journald format, but that's since long fixed now and I've not experienced any issue for a long time. Journal logs provide a standard format for all applications, so third party tools don't need to be compatible with every log format of your applications. And it also comes with great additional features like -b or --since etc. So I still don't get the issue here

You can still forward to text syslog or to a central logging server like Loki if working with multiple hosts. I still don't get the issue with binary logs.

Why do you consider it as poisoning? I've heard the argument about not doing things the traditional Linux way (binary logs for example). But if the alternative provides so many benefits, why is it an issue? Systemd is a piece of cake for all parties compared to sysvinit and alternatives, so why is it bad when it solves so many issued, and makes it super easy to use by just adding e.g. a new option to a Unit?

Another example: timers are more complex than cronjobs, but timers offer additional needed features like dependencies, persistence, easy and understandable syntax, and more. So although more complex, once you get the hang of them, they're a very welcomed feature imo

I can understand that it makes it easier to add changes that would benefit systemd and distros in general. I read that they introduced run0 to solve long shortcomings of sudo (I'm not aware of which). That sounds logical.

Actually no. The thing is just that systemd handles so many things that makes the lives both developers/distro maintainers and users easier, but most of it happens in the background. You can forget about having to learning complexer tools, just do it all via systemd

Here's some more examples:

Systemctl edit: create an extension for the unit file and add some changes
S edit --full: edit the full unit file (and timer too iirc)
S enable --now: enable + start
S disable --now: disable + stop

Arch could use better standard MAC security applied to systemd units like Debian does.
Arch could have an easy few clicks installer, something like a default modern setup.
Live kernel patching.

I'm not a supporter of the approach of blocking sudo access from capable people (non tech yes), because they can still download and execute binaries as their user. Or go to rescue mode to make modifications. I had to do that myself because of a micro managing IT team. Allowed? No. Allows me to focus on my work and let me be efficient? Yes. Usually this approach also requires a backdoor tool on your device that they install, which is just ridiculous.

Just communicate setup requirements (drive encryption, firewall, AV,...) And have some tool to check the security requirements and rating and this way you can apply proper security policies in the company and respect the user's privacy

Tbf you only need iwd, as systemd can take care of the rest. But it's not an option for me on desktop anyway because signal and vpn connection visibility are important for me and that's not possible without a GUI running

While I'm all for OSS, I'm also objective enough to know where it's not a good idea. And I think this is one of them. They have commercial one available in their own country called softmaker, which comes with support which is really important for a business or organization. I've been using it for many years because the OSS where just not right for me. Also liked WPS more but Linux dev was slow, but now I found my match

It can also be used very simply though. It works out of the box with any changes necessary. The issue I find with gnome is that its simplicity quickly became a bottleneck for me. E.g. Konsole is just so great and I couldn't live without it anymore

Ok mandalorian