Even if you misused the API you wouldn't ever get the problem that is "windows 9*", that kind of string is not available using the API and instead one have to create that string yourself by knowing that major=4 is 95 and so on.
What dizzlying pile of config files with non-descript names. In SysVinit we have openssh and in systemd we have openssh.service . apache vs apache.service and so on. Where are the non-descript names and if so how do they differ from their SysVinit counterparts?
They are not wrong, What is wrong however is the claim that systemd somehow should be anti the Unix philosophy, actually last I checked, systemd contained of a lot of binaries that each did one thing. Even claiming that SysVinit does one thing, or that it does it good, is bending reality.
So you volunteer to manage unit files, upstart files, init scripts etc for all the tens of thousands of packages in say Debian in order to support all the different init systems out there?
Or we just go back to reality where you realise that systemd is in fact not a massive program running at pid 0 doing 100 different jobs. The systemd binary that runs as pid 0 is not massive, it does not to all these things that you claim. That the systemd developers have created a breadth of applications that creates a common ground for things like setting time, managing dns, logging etc has nothing what so ever to to with what runs as pid 0.
In fact what you complain about is that we shouldn't allow this new GNU thing since the GNU tools handle everyting from listing directories to compiling whole programs!!!
That udev is placed in the same source tree as systemd does not make systemd eat it and also doesn't mean that packages needing udev also suddenly needs systemd.
Anyone who complains over overcomplexity or security have never ever really tried to understand just how SysVinit works or read it's source to begin with. If anything systemd makes it much less complex (a single unit file in a single place vs tons of links and overcomplex bash scripts all over/etc).
What if someone attacking you by crashing sshd so you cannot ssh to it? And honestly if you are afraid of any of the things that you wrote, then simply disable the restart altogether. It's not like it's mandatory, systemd even has it disabled by default, it has to be enabled in the unit file for each service.
So you just do not have a clue do you? If you even bothered to do any form of search you would have found out that it works exactly like I wrote. There is no httpd server in the systemd binaries, none in the journald binaries. But in a very specific binary called the journald gateway daemon, which have a single function (i.e expose the local logs via http). If you don't run that daemon (which is the default) then you won't run any http server at all no matter how much you cry about it. And if an attacker could start this daemon to get acccess to your holy log files, then you have other security issues with your set up that is way way worse. But don't let reality get in your way pal.
The init system is not not a part of it at all. The journald gateway deamon is a separate binary that does one thing and only one thing: it allows http access to the local log files. If the daemon does not run, which it doesn't unless it's manually activated, then it has no impact what so ever. So NO, the init system or even journald does not contain a web server.
Even if you misused the API you wouldn't ever get the problem that is "windows 9*", that kind of string is not available using the API and instead one have to create that string yourself by knowing that major=4 is 95 and so on.
You forgot to bold the most important part of that quote: but those are details, not big issues
What dizzlying pile of config files with non-descript names. In SysVinit we have openssh and in systemd we have openssh.service . apache vs apache.service and so on. Where are the non-descript names and if so how do they differ from their SysVinit counterparts?
How is systemd not the Unix way? Please explain.
They are not wrong, What is wrong however is the claim that systemd somehow should be anti the Unix philosophy, actually last I checked, systemd contained of a lot of binaries that each did one thing. Even claiming that SysVinit does one thing, or that it does it good, is bending reality.
actually you can still edit /etc/resolv.conf even when resolvconf is installed. I use that on all our Ubuntu servers with no problem.
So you volunteer to manage unit files, upstart files, init scripts etc for all the tens of thousands of packages in say Debian in order to support all the different init systems out there?
Or we just go back to reality where you realise that systemd is in fact not a massive program running at pid 0 doing 100 different jobs. The systemd binary that runs as pid 0 is not massive, it does not to all these things that you claim. That the systemd developers have created a breadth of applications that creates a common ground for things like setting time, managing dns, logging etc has nothing what so ever to to with what runs as pid 0.
In fact what you complain about is that we shouldn't allow this new GNU thing since the GNU tools handle everyting from listing directories to compiling whole programs!!!
That udev is placed in the same source tree as systemd does not make systemd eat it and also doesn't mean that packages needing udev also suddenly needs systemd.
How can it be both monolithic and have many components? How in hell can you compare encryption with binary logs.
"offers only itself as a way to read them.": So that is why the format is fully described in detail?
And what the hell is "it encourages non-kernel systems to rely on it"?
Anyone who complains over overcomplexity or security have never ever really tried to understand just how SysVinit works or read it's source to begin with. If anything systemd makes it much less complex (a single unit file in a single place vs tons of links and overcomplex bash scripts all over /etc).
Perhaps all the "good technical complaints" are drowning in all the trolling, hatred and death treats? It sure looks that way anyway.
You do realise that Ubuntu haven't switched to systemd yey, so the troubles that you experience with sleep there have nothng to do with systemd.
What if someone attacking you by crashing sshd so you cannot ssh to it? And honestly if you are afraid of any of the things that you wrote, then simply disable the restart altogether. It's not like it's mandatory, systemd even has it disabled by default, it has to be enabled in the unit file for each service.
Performance wise, FreeBSD still maintains the fastest network stack on the planet
Proof to that?
Exactly which liberties does MariaDB take with your data?
Ah, that makes sense. I was referring to Swedish law since it was about the Pirate Bay case.
And the maximum for copyright infringement is 2 years.
You got that kind of backwards. The _minimum_ jail sentence for rape is 2 years, the maximum is 10.
Since exactly when is Skype FOSS?
So you just do not have a clue do you? If you even bothered to do any form of search you would have found out that it works exactly like I wrote. There is no httpd server in the systemd binaries, none in the journald binaries. But in a very specific binary called the journald gateway daemon, which have a single function (i.e expose the local logs via http). If you don't run that daemon (which is the default) then you won't run any http server at all no matter how much you cry about it. And if an attacker could start this daemon to get acccess to your holy log files, then you have other security issues with your set up that is way way worse. But don't let reality get in your way pal.
The init system is not not a part of it at all. The journald gateway deamon is a separate binary that does one thing and only one thing: it allows http access to the local log files. If the daemon does not run, which it doesn't unless it's manually activated, then it has no impact what so ever. So NO, the init system or even journald does not contain a web server.
And when does this happen? I haven't experienced it.
It's more like the 10 people who hates LP have a way of sounding like 10 million.
Are you sure the "open source" trolls who spead all this hate about LP doesn't work for Microsoft?