Looks far more like a smarter version of Sonos, at the same price point.

They are only cutting the subsidies.

The market has established itself: subsidies are not needed anymore.

Just like the article says in the third paragragh.

I do not know about Hungary, but Germany is heavily investing in the renewable energy.

Or you expected them to immediately cut the pipes? halt production and transportation? cut the forests to heat the homes?

I recently updated my LinkedIn settings to say "don't contact me about job opportunities." I like my current job and don't expect to find a better deal anywhere else (decent salary, great coworkers, WFH).

As soon as I put up the "don't contact me" marker, the number of pings I get from recruiters doubled. Still offering the same depressing-sounding jobs with long commutes. I guess saying you're not interested piques their interest.

systemd 204 is the last systemd release where some of its services can be used with the systemd-shim and without systemd as pid 1.

Ubuntu ships 204 for some time too, since GNOME requires the services.

I haven't used Plasma, but from the screenshots it appears to be as dysfunctional and castrated as the GNOME.

I hope Kubuntu would keep the full-blown KDE as an option.

If you want to know the impetus behind systemd, why not go to source. Lennart lays out the problems he was trying to solve and the design process on his blog. Specifically, the intro post and biggest myths rundown would a solid positive case for the approach and technology.

I find it ironic that on one side they deny climat change, on the other - almost the same people build the ark.

Hey! My past employer willingly bought it!

...Oh. That's probably why they are "past".

HP rep - a HP-UX sales guy - once told me that their kernel doesn't support loadable modules to prevent even the remote possibility of a malicious driver.

But why OpenBSD choose to do it, I have no idea. Frankly, I was under impression that OpenBSD didn't support loadable kernel modules at all.

To some the kernel drivers might seem a norm, but even 15 years ago they were still considered a novelty. And everybody was still making jokes about Microsoft's Plug-n-Play.

Sounds like a phrase from a western movie.

After living for so long in Germany, it also sounds absurd. (N.B. I've never lived in the US.)

That makes sense only with this prepended:

But I feel you put those two far too apart.

Faith is something all people have naturally. People just have it.

Religion is simply a parasite which attaches to it. And that can make the faith toxic.

My point wasn't that Debian is being developed too slow. QA has never been fast.

My point is that Debian nearly always distances itself from the development and the developer community.

In other comment I also mentioned the APT. If Debian was today debating a packaging system, they would never ever opt to *develop* the APT like they did in the past, but they would take the RPM and try to live with it.

Otherwise, just look at two good examples of distros evolving: SUSE Studio and Ubuntu Launchpad. Lots of things which happen there rarely see the daylight - but they allow distro to play proactive role in bringing together the developers and users. (But of course, SUSE Studio and Launchpad are targeted at two different kinds of "developers" - first is for developers of distros and second is for the developers of the software.) That might seem superficial, but it allows distro to actually learn about the new trends and things people are doing with the software. They need much less guessing what/how to do in the next release. OTOH Debian, beside the heavily unreliable popcon, is very very much closed and unto itself.

That distance also plays role in how Debian's decisions are made. You can't roll-out something new and experimental in Debian and expect later it being adopted in Debian main. No. Because Debian wants to have a project with proven track record. And you can't get the "proven track record" *in* Debian - because the project will not be accepted without "proven track record". That is why the development happens in the Fedora, Ubuntu and SUSE. Rarely in Debian.

And why is this on-topic? Because Debian with migration to systemd would in some aspects become Red Hat, which is not something I'm particularly happy about. Because, though RH doesn't develop much of the systemd itself, it does quite a lot of work on systemd integration. Because they played role in its development. They gave the project fighting chance. And all it took for them was to say the developers: OK. At the same time, if you check history of attempts to bring upstart into Debian (which is much longer than the vs systemd discussion), Debian wasted literally years discussing, and mostly dismissing upstart because it was used by only one distribution, despite Canonical's pledge. Result? Red Hat has nurtured the systemd - and Debian has strangled the upstart.

That has nothing to do with the init system. That performance largely depends on the performance of the applications, and to some extent on the performance of the DE. The init system, after start-up, is mostly idle. The "biggest" job it has then is the reaping of the zombie processes.

Yes and no. Mostly no.

Ubuntu uses upstart only to manage the early boot sequence. Majority of everything is still started by the traditional /etc/init.d scripts, with runlevels and whatnot. There are some services which have upstart jobs - but out-of-box they are minority.