Email support was the bain of my existence. I forgot how many misconfigured system I came across decades ago that would fill up their filesystem with logs from crons in the root mail dir. Such a stupid default setting. We have vastly better methods for monitoring systems these days then firing off an email when a cron runs.

The attack is known as the evil maid attack. It requires repeated access to the device. Basically if you can compromise the bootloader you can inject a keylogger to sniff out the encryption key the next time someone unlocks the device. This is what secure boot is meant to help protect against (though I believe that has also been compromised as well).

But realistically very few people need to worry about that type of attack. Encryption is good enough for most people. And if you don't have your system encrypted then it does not matter what bootloader you use as anyone can boot any live usb to read your data.

Trump is supposed to be in office for only 4 years, at best,

That assumes America is still a democracy in 4 years. We are only a few months in and it is already not looking great.

Consistency as a means to correctness still means correctness is the more important aspect. Far too many projects and people that go hard on some methodologies and practices lose sight of their main goal and start focusing on the methods instead. Even to the point were the methods are no longer working toward the goal they originally set out to accomplish.

Always have the goal in mind, once your practices start to interfere with that goal then it is time to rethink them.

My point is the different levels of just working are subjective, not objective. I personally have spent far more time fixing bugs or just reinstalling ubuntu systems then I have over the same period for Arch systems. So many of my ubuntu installs just ended up breaking after a while where I have had the same Arch install on systems for 5+ years now. Could never get a Ubuntu system to last more then a year.

Everyone has different stories about the different OSs. It is all subjective.

I disagree. It is more than just a nitpick. Saying black holes suck things in implies that they are doing something different than any other mass. Which they are not. Would you say a star sucks in stuff around it? Or a planet? Or moon? No. That sounds absurd. It makes it sound like blackholes are doing something different to everything else - which is miss-leading at best. They way things are described matter as it paints a very different picture to the layman.

The article calls that out explicitly:

When installing on unsupported hardware, Microsoft will push a small disclaimer that effectively cancels your warranty in case of compatibility-related mishaps. Likewise, you won't be entitled to receiving updates - including security updates - so we're back to square one.

What is the point in upgrading if you wont get security upgrades either way. Just more spyware and ads in the newer version.

I am not sure which is worst. The ones that don't care at all or the ones that outright lie about caring. :(

Except desktop environments - they are far from a simple loosely collection of simple stuff. They coordinate your whole desktop experience. Apps need to talk to them a lot and often in ways specific to a single DE. Theming applications is done differently for every toolkit there is, startup applications (before systemd) is configured differently, global shortcuts are configured differently by each one... If anything it is something you interact with far more than systemd and has far more inconsistencies between each one. Yet few people complain about this as much as they complain about systemd.

Systemd is a giant mess of weirdly interdependent things that used to be simple things.

They used to be simple things back when hardware and the way we use computers were much simpler. Nowadays hardware and computers are much more dynamic and hotplugable and handle a lot more state that needs to persist and be kept track of. https://www.youtube.com/watch?v=o_AIw9bGogo is a great talk on the subject and talks about why systemd does what it does.

Someone getting sued does not mean they are wrong or that they lost the case. Each case needs to look at the works in question and decide if that perceptual case violates copy write. Lots of things are taken into account here, and even is small elements might have been used or be similar does not automatically win the case.

There is also a difference between some implementation and the overall feature in question. For instance, APIs are not copy writeable, nor are cords in music, nor what something does overall. Only specific implementations are copy writeable.

The same can apply to AI - if it generates a work that if a human did it it would violate copy write then it does - if not then it does not. But AI shows a different problem. That of scale. There is only a limited amount of work that a human can do. But an AI can produce vastly more content - enough that a case by case evaluation of infringement might not be viable. And if that becomes the case then AI works might need to be treated differently from human created works - or maybe how the models are created and how they can use copy writed works. The current laws were never designed with the speed at which AI can work in mind.

Lots of people equate OOP with inheritance, and I think that does a disservice to OOP code style in general. The original definitions of OOP had nothing to do with inheritance at all and this relationship was only popularized by a few languages (which others then copied due to aggressive marketing).

IMO the more important parts of OOP that are still useful are encapsulation and message passing which can be done in languages without inheritance.

I would caution against throwing out a paradigm before of one aspect of of that languages added onto it after the fact.

You must have a different version of rm then I do:

$ rm -i a
rm: remove regular empty file 'a'? y
$ rm -ir f
rm: descend into directory 'f'? y
rm: remove regular empty file 'f/a'? y
rm: remove regular empty file 'f/b'? y
rm: remove regular empty file 'f/c'? y
rm: remove regular empty file 'f/d'? y
rm: remove regular empty file 'f/e'? y
rm: remove directory 'f'? y

Never really had an issue with cp or mv overwriting files where I didnt mean to. Possibly because I don't default recursive on all the time. So they tend to error when accidentality copying folders. And I tend to tab complete paths to see what is in them. I also tend to use rsync for copying large directories rather than just cp when the directories might not be empty to start with.