I do not see the word “albedo” in this article. This is worrying. A lot of ecologist militant consider solar and wind energy as free energy just there for the taking. This is mostly true, but not entirely true.
Covering a large area of land with solar panels (even assuming they are thermal panels, not too fragile and with not too much fabrication byproducts) would change the albedo of that area, i.e. the proportion of solar light that is reflected by the ground. This will in turn change the climate of the area, and if the area is large enough, change the climate of the whole planet by changing the trade winds. It is entirely possible that in this particular instance the change would be for the good, but it is very hard to predict.
The same applies to large farms of wind turbines: they capture energy from the wind, and therefore weaken prevailing winds. Any large-scale localized change to elements of the climate has very complex consequences.
My user experience is that they threw something that worked for something that does not always (systemd does not work for me; failures to handle NFS mounts, etc, many little crap that does not matter that much expect: it worked before, correcting them was ununderstandably painy).
Basically, you found a bug in systemd, or possibly a bug in your distribution's use of systemd caused by a misfeature in systemd. That happens, especially with new versions that present major evolutions. Software can not be bug-free out of the box, it needs thousands, millions of users to explore all the corner cases. You had the correct reflex: you fixed the bug. Well done (no sarcasm intended)! But did you also report the bug upstream, so that the next person will find it less ununderstandably painful?
Unfortunately, that is not what some people do. Some people find a bug in systemd, or just hear rumors that there are bugs in systemd that may affect them, and so they decide to stick th SySV init. Fine. But they also demand support for their choice. They demand that new versions of distributions allow using SySV init, they demand that new versions of unrelated software, like KDE in this topic, work without systemd.
I will now be addressing these people: you, from now on, does not mean yeupou but these people.
First of all, you can not demand anything: you are users of Libre Software, probably gratis. You take it or leave it. You can make suggestions, express wishes, preferably politely, but in the end, you take what is offered and hopefully say “thank you”. Or you leave it, switch to proprietary commercial software, become a paying customer and find out that unless you are a major paying customer you still can not make demands, they will just be more unctuous about it.
There are a lot of bugs in systemd, there is no doubt about it. Most young software have a lot of bugs, and systemd is still very young. Or you can consider it as a new version of the software called “init system” that is a full rewrite: full rewrites also have a lot of bugs. But full rewrites are necessary in the lifetime of software, otherwise they are stuck with antiquated design flaws. As a full rewrite, systemd has a much better design than SySV init. This is not saying much: SySV init is made of a bunch of shell scripts; anything would be a better design. A better design means that in the long run, it will have much less bugs, much more features.
In the meantime, there are bugs. If one affects you, it is bad luck, because a new version is not released as stable unless it works for most people. Bad luck happens, we can only make the best of it.
If it is urgent, you can stick to the old version, the one that did work for you, of course. But that is only a temporary solution. Sticking to an old version of one software possibly implies the same for any software that depends on it. With a core component such as the system monitoring infrastructure, that will eventually mean everything, including the hardware. That is not sustainable.
As a user of gratis Libre Software, you are supposed to give back to the community. The first and foremost way to do that is to help fixing bugs. So if there a bug in systemd that forces you to temporarily stick to an older version, you are expected to file a good bug report. Otherwise, the bug may never get fixed. And if it takes too much time to your taste, then you install a virtual machine, you fire up your text editor and your compiler and you get to work fixing it yourself.
People who only whine and insult and never give back to the community only deserve to be mocked or ignored. People who help, as much as their means allow however small that is, deserve to be helped back.
There is a basic principle that drives the evolution of Libre Software, or at least the majority of it that is developed by a community:
Developers have the final say.
Developers make technical decisions based on technical merits and usability decisions based on their own use of the software, because they usually use their own software. They do not kowtow to the whims of a client or a commercial director.
Arguably, systemd itself is developed under the aegis of a single company, not a community. But KDE is undoubtedly a community project, and so are Debian and the other distributions that chose to switch to systemd. They did so not because they were compelled nor because Lennart Poettering brainwashed them them, but because, from the height of their technical expertise, they consider that systemd makes their task easier while respecting, or possibly even furthering, their usability goals.
As for the anti-systemd crowd Well, I know a few that develop and promote radically different system monitoring architectures, and they have valid arguments against systemd. As for the others, show us the code.
Absolutely not. My argument is that the TLS authentication architecture is broken beyond repair.
The SSH authentication system does not scale, but it is sound, and it could be made to scale without changing the base principle. The TLS authentication can not be repaired without changing it from the core.
Sorry, but it does not work. People who manage SSH servers know what a private key is, they treat it as a precious file and keep it when, for example, restoring from a hardware failure. Only when the key is compromised do they change it. If they are really serious about it will even distribute the fingerprint along with other necessary information when opening new accounts. You can verify it carefully, and then it is once and for all in the known_hosts file.
People who manage HTTPS sites, on the other hand, do not know what a private key is, or act like it. Websites change their keys every other day, have dozens of AJAX servers all with different keys, and sometimes even have different keys for different servers acting as round-robin for the same domain name. Checking all of them manually utterly impractical. And browsers do not even have an interface to manage that easily. Worse: IIRC, browsers do not even have an interface to check certificates for AJAX requests, they just fail silently.
The universe seems neither benign nor hostile, merely indifferent. -- Sagan