• 1 Post
  • 7 Comments
Joined 1 year ago
cake
Cake day: June 19th, 2023

help-circle
  • 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…



  • 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…