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.

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 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.

Pulseaudio was also replaced relatively quickly by pipewire. lets check that, shall we:

PipeWire: Initial release 20 June 2017; 6 years ago source: https://en.wikipedia.org/wiki/PipeWire

PulseAudio: Initial release 17 July 2004; 19 years ago source: https://en.wikipedia.org/wiki/PulseAudio

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....

how is this any diffrent from SysV scripts hanging and preventing a reboot that way....

you are blaming SystemD for an issue not part of SystemD, but a generic computing issue...

and yes, you can still just hard reboot your system with SystemD as @elscallr@lemmy.world has point out....

even worse offenders are the ones with tick boxes for "Legitimate Interest", since legitimate interest is another grounds for processing (just ads freely given consent is one), the fact you got a "tick" box for it makes it NOT legitimate interest within the confines of the GDPR.

it also doesn't matter what technology you use whether its cookies / urls / images / local storage / spy satellites. its solely about how you use the data..

now if only there was a universal definition and cut off point for CSAM world wide... but sadly the only valid option is indeed to disable images...

Lets hope https://github.com/LemmyNet/lemmy/issues/3920 gets a proper implementation or other fix so we can atleast vet before we allow an images.

A trick to "learn" routes.. put the GPS in your pocket, and only listen to it... this way you start to spot the landmarks we used to use to navigate by.

Saved you a click:

REJECTED CVE has been marked "REJECT" in the CVE List. These CVEs are stored in the NVD, but do not show up in search results.

even when: @jerry and @shellSharks are working on the servers. and I have nothing but praise for them.

I also think there should be some (small) group of people able to help & assist with the task of maintenance and support of the backend.

(and i don't mean getting root access to anyone's hardware, especially not without vetting)

and I would also think it would be a good idea to have some (open) scenario / manual / strategies for different standard actions, preferably with a script to also fix the issue.

(just some ideas running through my brain)

ouch,,, you know its bad when a infosec Admin asks you to switch off 2fa...

I always use dangerzone.rocks to read any suspicious PDF file.

it automates the full process and can run in a container.

thats partly why I started this post. it yielded a few option I was completely unaware off already.

but you cant beat there update schedule... there has been like 10 versions in 3 days...

sadly Jerboa is Android, and I am stuck on iOS due to "regulations"...