Is managing light bulbs something worthy to write to a system log file? Isn't an application log suitable for this? And why should any application want to spam log files in high volumes?

Give me an example why you need a DB format for logs when you have trouble booting the system and most of the system actually does not work and you try to find the cause with tail/cat (whatever there is left that might still be executable). If your system log is high-troughput ... your system is broken. It should contain all necessary messages to understand in which state a system is (or was, when it is not coming up), give understandable warnings and to be easy to grep and compare with previous states the system had.

Many people (also from the BSD world) actually like Wayland, because it is actually not useless but replacing really awful X APIs. I don't know if you have ever written a program for raw X API. It is even worse than Win32 (which already is a total mess!), in my opinion. X is even more than just mess, it is bloat, full of things you will never need and uses quite old concepts that are not compatible with sane minds of today's programmers. It is a real improvement to graphical desktops on all systems. Wayland will be ported, because it is something many have waited for long time.

systemd is different. It makes a generic API unportable and provides users with functionality (mainly for desktops), but which is also totally weird and seems to workaround all the failures in software design that have been introduced a while ago. It does not solve them, it makes them even worse and more complex. The worst about it is that there are still people want to use these APIs and break portability. And for what? For something you don't even need and never expected to change.

And don't forget to mention that systemd still does not work properly. I haven't had a single systemd-based system that would not show non-deterministic behavior.

I started on Arch where it lead to a system that could not boot sometimes and was impossible to shut down (ACPI broken, even with the 5sec power-switch trick, it just rebooted! I don't even know how the hell this was possible... the system was like possessed! the only way to power off was the switch on the ATX power supply during reboot).

The other Arch system could not mount NFS shares at boot. Race condition with network interface initialisation. Googled up some really exotic fstab flags, but systemd-based boot ignored them completely. ACPI was also broken, of course and there have been some other problems with services not starting properly.

Now on Debian (in Virtualbox), I have the problem that every 4th or 5th boot slim is starting but I cannot type anything. It looks like the keyboard is not initialized and slim is already started. At least ACPI works, so I can send Virtualbox Hotkey+H to make it shut down cleanly.

I am mostly pro-Google and against many weirdnesses we have here against companies with our laws. I try to explain what is going on here.

In Germany a company which has a web presence needs to have a so-called "Impressum" with essential business data and a way to contact them in a reasonable time. When there is a phone number, it needs to be answered. Emails need to be answered soon, too, when there is only email address as contact possibility. The impressum is regulated very stricty to prevent fraud and anti-competetive practices. So it is generally not that bad, except that it abolishes anonymity.

My opinion here: In fact, Google is avoiding its users. Have you ever tried to contact them? In this case it might be a good idea to give people the possibility to contact Google somehow.

And to the people joking about Slashdot. Yes, also Slashdot would need to have an Impressum page when it had a subsidiary in Germany.

Of course the clock is monotonic. This is also written very clearly in the ntpd man pages that the clock should slow down or tick faster to adjust time without any jumps. Humans should only touch the clock if it is awfully wrong (hours difference). But this is a critical system operation. It can even lead to aborts of important daemons which depend on monotonic clocks. You should avoid changing time at any cost and make sure that the clock is always in a sane state instead.

I am happy that Linux users have chosen systemd. First, it separates people who like Unix from those who want Linux to be like Windows. And then it's also good for me, because I have always seriously considered Linux distributions to be serious systems, occasionally trying several just to fail after some months. Now I know that since this whole mess is going on on the Linux platforms, I don't need to care about Linux anymore.

The choice is much simpler now. Thank you, Mr. Poettering.

Only if you have it configured in this way. The default configuration writes ntp.drift and logs the drifting behavior to correct the clock adequately without time skipping (or worse: moving backwards), which should never happen on a server.

You can use ntpdate of course, but don't use it regularly.

Locale settings are fine without system-level settings. What is wrong with application-specific LC_xxx settings? And why should I be interested in changing locale in the middle of a desktop session?

What?! Who the hell changes time on computers? This is not a $5 digital watch! Every reasonable system has got ntpd installed and is set to UTC. The rest is done by selecting the time zone you are in. And stay away from changing time zones by adjusting time! We are not in Windows world where time handling has been fucked up entirely.

Why do I need a daemon to log out from a session?

when you don't need them.

Probably he has been replaced by a systemd component named stevensd.

Point is, the only CA I trust is the one I created myself. And by this I mean: self-signed certificates are the most reliable. And by this, I imply: "net of trust" type trust is generally the best solution. And that's why I conclude that CAs are generally shitty, because I don't know who signs what there and I consider PGP as the best solution for handling of trust.

The only way, I "text" people.

This is true.

Since then, I've been searching for window managers (I've already given up with full desktop environments, because they install much crap I never need and are slow). I used OpenBox quite long, because it was easy to manage.

One day being bored not trying out anything new, I installed Xmonad for fun. It was a good laugh because of the simplicity... I could not write Haskell code. I found some interesting configurations online and began to learn Haskell. After learning some basics about the functional language, I extended an existing configuration, made it more abstract and now... ... ...

I am still sitting here and have Xmonad on my desktop. I think it's the longest time I've ever used a single window manager as my personal choice. Absolutely stunning. ...

No, it won't be awesome.

A while ago... the common init startup procedures have been ignored by the Linux community and they developed their own Unix-incompatible way to start the system and even pollute many common applications with it so incompatibilties will be everywhere soon. And it keeps going on with KDBUS and so on..

Now when OpenBSD touches a central library it is ultimately bad for everyone, even when they don't destroy compatibility as much as it seems. Who uses VMS or pre-Windows-2000 systems today? Most of those people don't care about a new version of SSL anyway.