Announcement
Collapse
No announcement yet.
Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
Collapse
X
-
Originally posted by Scias View PostNot only you can still use grep and all the other beloved tools you want with journalctl's output, but journalctl gives the ability to quickly filter specific fields without needing to spend a night on grep and regex patterns.
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.
Comment
-
I like Gentoo, and I'm very happy to see that reason is winning and now systemd is on equal footing with OpenRC there. It probably won't ever be the default, yes ? but neither is OpenRC, because Gentoo doesn't have defaults I also have two Gentoo systems I maintain, both use systemd, one of them uses Btrfs with Snapper. So I'm happy that not all Gentoo developers are like ryao...
Comment
-
-
Originally posted by schmidtbag View Posty'know what I'd really like to see? systemd get divided among separate packages. No need to fork the project, just simply split it. There should be a systemd-core, which contains only the necessities of an init system (basically the same thing as sysvinit, with a few other things here and there like parallelization) and then separate packages that include these other bloat features that some people may sincerely care about or want, but aren't vital to the infrastructure of the OS. This should be much easier to maintain and make everyone happy. I don't think anyone would dislike systemd if it were designed like this.
1.) systemd arch full install in x86_64 is less than 20mb, for arm is lot smaller. so i don't see size been a problem specially since any toolkit you use is prolly 20 times bigger
2.) systemd only start PID1 by default(your definition of init system)and journald for logging everything else start and stop ondemand from c/c++/DBUS/etc API, so it doesnt use memory or CPU at all unless is really needed
now the answer will be people won't like it for one simple reason, you break standarization and add an extra step to verify that all submodules are installed in runtime, just to save 10mb tops of hardrive space is just plain crazy
Comment
-
Originally posted by mhogomchungu View PostIt comes from a unix philosophy[1] and Most if not all of them are well documented[2]
[1] http://en.wikipedia.org/wiki/Everything_is_a_file
[2] https://www.kernel.org/doc/Documenta...stems/proc.txt
Comment
-
Originally posted by prodigy_ View PostDisabling components at the level where init operates means you'll have your own distro to maintain. So you either accept the wholesale deal or switch to another distro that doesn't use systemd. Having alternatives is little comfort when you can't really use them because their role is hijacked by the init system.
Comment
-
Originally posted by nslay View PostThe stupid part is parsing strings for system information and that is not part of the Unix philosophy.
Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
Comment
Comment