Originally posted by prodigy_
View Post
Announcement
Collapse
No announcement yet.
Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
Collapse
X
-
Originally posted by prodigy_ View PostFanboys will never learn. Systemd holds no real advantage over sysvint and all its perceived advantages are either superfluous daemons that re-invent things better implemented somewhere or pure cosmetics like slightly faster boot times. Are those worth all the trouble we have to put up with and all the freedom we stand to lose? In my opinion - absolutely not. But fanboys will never learn.All opinions are my own not those of my employer if you know who they are.
Comment
-
Originally posted by prodigy_ View PostI'm listening. In case if you have something to say.
First up, systemd provides a more sane and generic method of daemon startup to reduce boilerplate that was found in sysvinit. As a side effect, this also allows a bit of consistency when it comes to things like what the console actually says whenever a daemon is successfully started.
Systemd works fine for thousands if not hundreds of thousand. It's good enough to be adopted by the currently most popular distributions (Ubuntu, CentOS, Fedora) along with the lesser used (Gentoo, Arch Linux come to mind).
Even if systemd is a flop, what it does right now is more productive and consistent than what sysvinit was able to provide us. A replacement would look closer to systemd or upstart than it would to sysvinit.
I personally think systemd is doing fine. If things go sour, the nature of open-source will have its way like it always does.
EDIT: Also, it's generally not good to use something that's marked as deprecated, even if it does work.
Comment
-
Originally posted by nslay View PostA tangent thought: /proc sure is great for scripting, but I'm still dumbfounded that native applications have to parse strings to get system information on Linux. Even the awful Windows API got it right here ... It's really awkward to see someone declare a character buffer or string, open a file, read the file into a buffer and then use <string> or <cstring> operations to get the information ... I mean, frankly, it's really stupid and the format of these files isn't always straightforward or even documented. Some of them are just space delimited numbers with no obvious meaning - I wouldn't even call that human-readable - at least a struct can have named members and comments.
It isn't that difficult or even very slow to parse the files.
From a developer point of view it is much nicer to have them in text. Imagine if it was done like the Windows API. The code would need to look for the size of the output struct and run it through a switch or if/else to figure out which of the many versions of /proc/pid/stat were requested. With the current system new data fields are added to the end and it is the responsibility of the code reading them to ignore fields it doesn't understand.
For some kernel information there are netlink socket APIs to get the data in binary form.
Comment
-
Originally posted by prodigy_ View PostFanboys will never learn. Systemd holds no real advantage over sysvint and all its perceived advantages are either superfluous daemons that re-invent things better implemented somewhere or pure cosmetics like slightly faster boot times. Are those worth all the trouble we have to put up with and all the freedom we stand to lose? In my opinion - absolutely not. But fanboys will never learn.
Comment
-
Originally posted by computerquip View PostSo, let's start with some obvious ones. What does sysvinit do better over systemd?
Originally posted by computerquip View PostFirst up, systemd provides a more sane and generic method of daemon startup to reduce boilerplate that was found in sysvinit.
Originally posted by computerquip View PostSystemd works fine for thousands if not hundreds of thousand.Last edited by prodigy_; 03 April 2014, 04:40 AM.
Comment
Comment