[mythtv-users] Recommended Linux Distro post CentOS

[Stephen Worthington]

On Wed, 16 Dec 2020 04:25:09 +0000 (UTC), you wrote:

>----- Original Message -----
>> From: "David King" <dave at daveking.com>
>
>>> Here is my issue with it - when it fails, it fails in really stupid
>>> ways that can be hard to figure out and fix.
>>>
>>> For example, say you have a second non-system disk that you store
>>> recordings or random things on (to keep the MythTV link).  Nothing on
>>> the OS or even the users truly depend on, and it's mounted under /mnt
>>> or /media.
>>>
>>> Disk fail?  You remove it to copy the data onto another computer?
>>> Systemd will prevent the whole system from booting. It'll just hang
>>> forever.  You need to boot a usb stick or figure out how to you
>>> systemrescue to comment out the offending disk in fstab and reboot the
>>> system.  Assuming you figure out that the disk failed.
>>>
>>> Systemrescue (or whatever it's called) isn't as intuitive as one might
>>> think - and if you don't have a computer to search the right commands
>>> on, you are toast.
>> 
>> Google finds this at https://wiki.archlinux.org/index.php/fstab. This
>> article is also cited as a solution on multiple other web sites:
>> 
>> External devices that are to be mounted when present but ignored if
>> absent may require the|nofail|option. This prevents errors being
>> reported at boot. For example:
>> 
>> /etc/fstab
>> 
>> /dev/sdg1        /media/backup    jfs    nofail,x-systemd.device-timeout=1ms
>> 0  2
>> 
>> The|nofail|option is best combined with
>> the|x-systemd.device-timeout|option. This is because the default device
>> timeout is 90 seconds, so a disconnected external device with
>> only|nofail|will make your boot take 90 seconds longer, unless you
>> reconfigure the timeout as shown. Make sure not to set the timeout to 0,
>> as this translates to infinite timeout.
>
>Sure.
>
>But you know what's even better?
>
>Not trashing 40 years of Linux/Unix SA training for gratuitous crap put in
>there for 1% or (way) less of running Linux systems.  I to this day cannot
>imaging what Lennart had on the 6 major distribution release managers that
>he got them to bake that crap into them.
>
>Me?  Bitter?
>
>No, why should I be bitter, just because some random out of nowhere obsoleted 
>in about 3 years what I'd spent 30 years getting good at?  No motivation there
>at all...

You might want to reconsider that a little.  I started out very
sceptical about systemd.  And I still not a fan of the "one systemd to
rule them all" concept.  But I have now used systemd quite a bit and
so far I have found that using systemd to run things is dramatically
better than init scripts.  When you had to write an init script, that
was a mini-project on its own getting it to do everything needed - it
took ages.  Using systemd to start a program is usually easy - just
add the options you want and it often works first time.  And a huge
plus is that the program does not need to be written with a daemon
mode - in fact, running it as a daemon takes more effort with systemd
than running it as a normal program.  I do not like the logs going
into journals so much though - that makes it difficult to access them
when booted from a live USB or PXE image to do repairs or discover why
things went wrong.

Over time systemd has got better too, with some of the niggly little
things fixed by new options.  I really like just being able to now do
"systemctl edit" to create a new override file.  And some things I
hate are things I can fix myself.  Why on earth they thought that
having to type "systemctl" and "journalctl" all the time was a good
idea I have no clue.  Commands that are used often should be short. So
I have aliased them to "sc" and "jc".

The option to have an early start / late shutdown root debug shell is
also extremely valuable when debugging startup and shutdown problems.