On 13.10.14 12:13, Brian May wrote:
On 13 October 2014 11:57, Peter Ross <Petros.Listig@fdrive.com.au> wrote:
Your mistake is to think that we need to convince you.
Hmmh. Apologies but this does not sound exactly right.
How many times do you expect the developer's to do this?
Just once. The wikipedia page is a good start, but might usefully be expanded. Granted, if current, it already addresses the concern that many have over the "binary logs", given that it states: "Among systemd's auxiliary features are a cron-like job scheduler called systemd Calendar Timers, and an event logging subsystem called journald.[6] The system administrator may choose whether to log system events with systemd or syslog. Systemd's logfile is a binary file." If still true, then no host running systemd need ever use binary logs, if aversion is universal. And the presence of an integrated job scheduler should not impinge in any way on whether we run cron or anacron. However, that page does indicate that systemd has no expressed rational reason for integrating networkd. The link to http://boycottsystemd.org/ brings a strong quote: » systemd is a replacement for the sysvinit daemon used in GNU/Linux and Unix systems, originally authored by Lennart Poettering of Red Hat. It represents a monumental increase in complexity, an abhorrent and violent slap in the face to the Unix philosophy, and its inherent domineering and viral nature turns it into something akin to a "second kernel" that is spreading all across the Linux ecosystem. This site aims to serve as a rundown and a wake-up call to take a stand against the widespread proliferation of systemd, to detail why it is harmful, and to persuade users to reject its use. « But the clearest signal that the goals of Poettinring and his cronies lack rational bounds is this: "By default, systemd saves core dumps to the journal, instead of the file system. Core dumps must be explicitly queried using coredumpctl4" Such pointless moronic stupidity achieves only one goal: Obfuscation and sequestration of previously accessible debug data. The clowns clearly are driven by denying users access, and making themselves guardians of an M$-style monolith. It is _quite_ clear why Redhat and Canonical are keen on it - it makes linux their property by deception, since only big teams can support the bug-ridden mess. I think this is right: " systemd .. reinvents the flat tire, and just a huge anti-pattern in general. If your goal is to pander to the lowest common denominator, so be it. We will look for alternatives, however." ...
Nor is it surprising that some legitimate concerns might not be getting addressed to everyone's satisfaction.
No, when they don't give a flying ferret for Linus and the LK team, then what chance do users concerns have? Erik -- (5) It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea. RFC-1925