Public elections are an aristocratic practice, not democratic.

Maybe he meant that if as in this case the "speed of light" is modified, then light travelling at the normal rate would in fact be traveling faster than the speed of the before-mentioned light.

I'm also wondering if this mean c will continue to be a constant?

Come on, this is like a trillion times more interesting than "Ubuntu releases new version of the same thing they did last month" or "Security hole found in Windows!"

This is so cool, a modern day Babels tower!

Ever heard of Google? took me one try, top hit.
http://www.math.kth.se/matstat...

You don't get to call someone a liar without rudimentary research on your own part.

Ah, the nostalgia of Windows ME

Such a radical change, like binary logs should at least require a couple of years of maturement time as an RFC, while it gets implemented by all relevant tools across the board. And even then, it should always be optional, and support multiple formats.

Text parsing isn't all rosy either, there are large amounts of security/performance problems that are neatly hidden.

But will the system be systemd-free in the future?

Systemd is the main reason NOT to use gnome, another reason is that it sucked long before the other *DEs started sucking.
Seems to me like a good reason not to use Debian, if they won't cater for power users.

Surely you can see that idea is a disaster to begin with. I mean, heavy traffic running on and wearing down expensive PV equipment...
Those regions where it would work well are already sparsely populated, and could easily install more efficient PV units next to the road.

Exactly, it's great if you've got a house to risk. By the time people pay off their mortgage nowadays their bones will have turned to dust.

The baby boomers are sitting on most of the money, or act as VCs or angels to rip people off, so of course things'll have to be done differently by younger generations.

As I said, they are just unnecessary bloat. The problem you are trying to solve is self-serving and endless. let's say you need to update glibc, then you add containers, now you need to update your container software so you add container-containers, then next you need to update your container-container software, so you need container-container-containers. No matter how long you keep up, you're still going to end up with the same problem and additional ones. But by now, the system has devolved into a slow mess that no one wants to touch. So you go and buy a new server and hope things are different this time.

Memory protection is a basic requirement for security in a multi-user environment.

Assuming there even is such a config setting in systemd, and that it works.

Problem is, for the most part people want to get rid of behaviour in systemd, which doesn't work for them or is otherwise useless. And in many cases it simply isn't possible.

Not really, both would work, but fewer people are good at declarative which means it's bad for system tools. I'm arguing flexible design over monolithic when it comes to something like init. You never want to reboot for minor system changes, so init needs to be as flexible as possible, to accomodate any kind of change. Systemd, the monolithic binary that links all the way up to GUI layers. You'll need to reboot for just about every software update.
It really is the worst solution anyone could ever come up with for a problem that never existed in the first place. I'm not sure I could come up with something more stupid.

You may look at things differently and therefore my response may sound harsh, but the way any normal *nix person sees these "improvements":

>1. Doesn't support being run in a container (though this is being worked on).
Apparently it now does. But I couldn't care less since containers and virtualization are an exercise in bloated pointlessness. Most operating systems can already run multiple processes simultaneously.
>2. Is slow to start up, which is important for containers.
Slow startup is a result of huge scripts and their interpreters. You really can't have it both ways.
>3. The network setup scripts could use improvement.
No idea, never used the default ones.
>4. It tends to leave orphaned processes lying around.
Haven't seen this except in faulty scripts.
>5. It doesn't care about exit status for anything.
What should it do with it? It's a config issue.
>6. It can't shut down without leaving read-only filesystemd mounted.
This might be a bug
>7. It takes quite a while to actually shut down.
Again a config issue.
>8. It lacks support for service monitoring.
I assume you mean respawning? It's usually not a good idea, but openrc supports it.
>9. Doesn't support minor tweaks to init script configuration like adding ionice without merging changes on every package update.
Don't know what you mean, all the files are editable, and you're not supposed to just blindly replace config with defaults.

The point is, openrc (just like sysVinit) is a generic tool that doesn't make unnecessary assumptions about what you're trying to do with it and due to its scripted nature has no imaginary boundaries.

I can imagine using something similar but much less bloated than systemd for simple embedded devices, but not if it's made by Mr. Poettering & co. who have a long history of bad (and anti-unix) design decisions at every corner.

The question is what was wrong with OpenRC?
It's flexible enough to do just about all the useful tasks that sysV and that systemd does.

We really don't want a kernel in user space unless you want Linux to become infected with the finder syndrome of MacOSX.

No, it's just *your* definition of what easy to use is. Most of us don't agree, which is reflected in your unhappiness with the software.

I'm not saying free software GUIs are perfect, far from it, but they are in general a lot better and more usable than proprietary ones.