Remove systemd from the following versions of DeepinOS
Esta petición conseguió 10 firmas
systemd is an init system used in Linux distributions to bootstrap the user space and manage all processes subsequently, instead of the UNIX System V or Berkeley Software Distribution (BSD) init systems. It is published as free and open-source software under the terms of the GNU Lesser General Public License (LGPL) version 2.1 or later. One of systemd's main goals is to unify basic Linux configurations and service behaviors across all distributions
SystemD goes against the Unix philosophy: "do one thing and do it right," representing a complex collection of dozens of tightly coupled binaries. Your responsibilities grossly exceed those of a boot system as you go about power control, device management, mount points, cron, disk encryption, inetd and API for sockets, syslog, network configuration, login management And sessions, readahead, GPT partitions, container logging, hostname / locale / time management, and so on. Keep it simple, stupid.
SystemD journal files (manipulated by journald) are stored in a complicated binary format, and should be queried using journalctl. This returns to potentially corruptible journal logs because they do not have ACID transactions. Surely you do not want this to happen to your syslogs. The advice of the SystemD developers? Ignore the problem. Not seriously. Oh, and it also has integration with an embedded HTTP server (libmicrohttpd). And QR codes are served through libqrencode.
The SystemD team is notably chauvinistic and anti-Unix, due to its open disregard for non-Linux software and the subsequent incompatibility of SystemD with all non-Linux systems. Because SystemD is very strongly coupled with the Linux kernel API, this causes the different versions of SystemD to be incompatible between different versions of the Linux kernel. It is an isolationist policy that essentially solves the Linux ecosystem in its own cage, and serves as an obstacle to software portability (translator's note: one of the greatest desirable qualities in every piece of software).
Udev and dbus are forced dependencies. In fact, udev merged with SystemD long ago. The integration of the device manager that was once part of the Linux kernel is not a decision to be made lightly. The political implications of this are high, and makes many packages that depend on udev, in turn depend on SystemD, beyond the existence of forks, such as eudev. Starting with systemd-209 developers now have their own, non-standard and poorly documented sd-bus API that replaces much of libdbus's work, and further decreases transparency.
By default, SystemD saves the core dumps in the journal, instead of the filesystem. Core dumps should be explicitly queried using coredumpctl. Beyond going against all reasoning, this also creates complications in multiuser environments (good luck running gdb on the core dump of your program if you dump in the journal and do not have root access), since SystemD requires root access to control it . It assumes that users and administrators are silly alike, but more critically, the essentially corruptible nature of journal logs make it a severe deterrent.
The complicated nature of SystemD makes it difficult to extend and go beyond its limits. While it is more or less possible to start trivial scripts with files, it is more difficult to implement behavior that leaves the box. Many users will likely need to write more complicated programs that directly interact with the SystemD API, or directly need to parse SystemD. One should be concerned with a greater number of execution paths and behavior in a critical system program, including the possibility that SystemD does not synchronize well with the dbus message queue at boot time, freezing the system. This is in opposition to the traditional init, which is deterministic and predictable by nature, since it mostly only executes scripts.
Ultimately, SystemD parasitism is the symbol of something more than SystemD itself. It shows a radical change of thinking in the Linux community. Not necessarily positive. But vehemently postmodern, monolithic, strongly-oriented desktop systems, limiting possibilities, isolationist, wheel reinventor, and a large anti-pattern in general. If your goal is to please the lowest common denominator, so be it. We will however seek alternatives.
Being DeepinOs a self-sustaining system by the community should be able to develop its own bootstrap the user space and manage all processes subsequently
Las peticiones más importantes
Hoy: Roberto cuenta con tu ayuda
Roberto Vargas necesita tu ayuda con esta petición «www.facebook.com/deepinlinux: Remove systemd from the following versions of DeepinOS». Súmate a Roberto y 9 persona que han firmado hoy.