Re: Is systemd a benefit or a liability? [Was: btrfs :(]
Hi Russell, thanks for your answer. From: "Russell Coker" <russell@coker.com.au>
Your mistake is to think that we need to convince you.
Hmmh. Apologies but this does not sound exactly right. An unconvinced public makes every project irrelevant. http://boycottsystemd.org makes some points which seem to be relevant. Just to say: "Well, we know better and do not care" is not exactly great communication. If you have time, maybe write a few of your thoughts related to the criticism. (No, you do not have to. I am simply curious and value your opinion. Really.) Have a look at Gnome 3 and FreeBSD. There is still no official support because "Linuxalisation" and especially "Systemdlization" make it difficult to maintain a Gnome 3 port "beyond systemd". If you want a logind to run Gnome 3 - just knock yourself out! But to require a change of the init process to get Gnome 3 running is a bit "overreaching" I would think. FreeBSD (as an example of another Open Source "Unix") may have (besides of technical qualities and different licensing) a role to play to keep as a reference check. If your "default desktop" does not work with another Unix - is it really that good? The IETF is describing their approach (http://www.ietf.org/tao.html) here: "To become an Internet Standard, an RFC must have multiple interoperable implementations and the unused features in the Proposed Standard must be removed" It served us well. Just look at the well-described world of TCP/IP standards and their implementation under Unix/Linux, and compare it with Microsoft networking and the efforts of the Samba team to implement a second open source implementation, and especially a modular Samba 4. Paul McCartney and John Lennon were most successful as The Beatles. Someone said something along the lines: John got Paul to rock and not just to write sweet melodies, and Paul could stop John if he went over the top. People are rarely good in many areas. As an example, a potentially corrupt binary logging file is not great design - maybe they just should have left this part to someone else. To make it an integrated part of an init process sounds silly. I would prefer a focused project which has a well-described functionality it is aiming to implement, and works nicely with other parts. This kind of modular approach created a successful Unix/Linux ecosystem so far. Regards Peter
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? What is happening is as more and more people are becoming aware of systemd, people are raising the similar concerns over and over again. I don't think it is surprising that the developers might be getting tired of having the same discussions over and over again. They could be spending their time better fixing these problems rather then arguing the same thing for the x millionth time. Nor is it surprising that some legitimate concerns might not be getting addressed to everyone's satisfaction. -- Brian May <brian@microcomaustralia.com.au>
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
On 13/10/2014 9:52 PM, Erik Christiansen wrote:
On 13.10.14 12:13, Brian May wrote: ...
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?
*Exactly* -- there's plenty more users and sysadmins that are being completely ignored; such users, btw, are now known as "the rebellion" amongst the systemd "invaders" and "supporters" ... more disrespect for users' views, needs and requirements. A.
On Mon, 13 Oct 2014, Erik Christiansen <dvalin@internode.on.net> wrote:
"By default, systemd saves core dumps to the journal, instead of the file system. Core dumps must be explicitly queried using coredumpctl4"
I doubt that would be a mandatory feature. While it sounds like an extreme thing to do, there are many systems out there which have a problem of managing core dumps. It's a particular problem when running proprietary software. Some years ago when 9G SCSI hard drives were common in servers (and 46G was the biggest hard drive I owned) I managed a number of Solaris systems that had CA Unicenter installed. Unicenter was total rubbish like all CA software. I wrote a script to gather the core dumps from the ~10 servers that ran Unicenter and collected about 500M of core dumps per day. The volume of core files was great enough that systems were at risk of running out of disk space from core files. If I was to run low quality proprietary software on a number of Linux servers then it would be useful to send core dumps to the systemd journal and then limit the journal size to something that won't cause problems. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 13.10.14 23:20, Russell Coker wrote:
On Mon, 13 Oct 2014, Erik Christiansen <dvalin@internode.on.net> wrote:
"By default, systemd saves core dumps to the journal, instead of the file system. Core dumps must be explicitly queried using coredumpctl4"
I doubt that would be a mandatory feature.
Even their "default" claim is not true, according to: http://www.freedesktop.org/software/systemd/man/coredump.conf.html which seems to be for systemd 216 (sounds recent, IIUC), that: Storage= Controls where to store cores. One of "none", "external", "journal", and "both". ... When "external" (the default), cores will be stored in /var/lib/systemd/coredump. ####### And if we've been cautious with the partition on which /var lives, then even that should not be able to crash through overflow. I'll ask them to correct their webpage. Erik -- On the basis of evidence we may be sure that we are wrong but we can never be sure that we are right. - Richard Feynman
On Mon, Oct 13, 2014 at 11:20:52PM +1100, Russell Coker wrote:
If I was to run low quality proprietary software on a number of Linux servers then it would be useful to send core dumps to the systemd journal and then limit the journal size to something that won't cause problems.
or you could just use 'ulimit -c 0'. or a coredump reaper script like you already wrote. systemd and journald with a binary logfile seems overkill for that. systemd seems like overkill for all of the tiny little problems it solves. craig -- craig sanders <cas@taz.net.au>
Russell Coker writes:
If I was to run low quality proprietary software on a number of Linux servers then it would be useful to send core dumps to the systemd journal and then limit the journal size to something that won't cause problems.
Why not just limit the size of core dumps?
On 13 October 2014 21:52, Erik Christiansen <dvalin@internode.on.net> wrote:
However, that page does indicate that systemd has no expressed rational reason for integrating networkd.
Maybe because the alternatives have serious problems in certain use cases? e.g. ifupdown easily gets confused as to what state the interface is in, and network-manager has a lot of unnecessary overhead for server use. I have no problems with people wanting to make things better. If you don't want to use system-networkd however, you can continue using one of the alternatives. I think network-manager will be a better solution for desktops/laptops, for example, as I suspect system-networkd may not have the GUI interface network-manager does (I haven't checked that recently though). -- Brian May <brian@microcomaustralia.com.au>
On 14.10.14 09:50, Brian May wrote:
On 13 October 2014 21:52, Erik Christiansen <dvalin@internode.on.net> wrote:
However, that page does indicate that systemd has no expressed rational reason for integrating networkd.
Maybe because the alternatives have serious problems in certain use cases? e.g. ifupdown easily gets confused as to what state the interface is in, and network-manager has a lot of unnecessary overhead for server use.
I have no problems with people wanting to make things better.
OK, granted, it is doubtful that _anything_ could be worse than network-manager, so replacing that is de facto an improvement, until proven otherwise. Every time I forget to zap it during an install, it prevents networking operating properly, and has to go before the host becomes useful. If only all fixes were so easy. On the other hand, in the last quarter century, I've found traditional networking 100% reliable and easy to use, on HP-UX, Solaris (Sparc & x86), and several linux distros, both domestically and administering up to a dozen workstations. It is possible that I have never suffered ifup state confusion simply because I always use "ifconfig -a" to check interface state, simply through habit. (And if I'm not sure what I'm facing, then "/etc/init.d/networking restart" is zero risk in 99% of cases - a server with a single interface, which is in need of TLC.) So, after more than a quarter century in industry, I find that there is really nothing requiring fixing.
If you don't want to use system-networkd however, you can continue using one of the alternatives. I think network-manager will be a better solution for desktops/laptops, for example, as I suspect system-networkd may not have the GUI interface network-manager does (I haven't checked that recently though).
Ah, if system-networkd is genuinely just an alternative separate daemon, fully interchangeable with current services, then the new offering isn't harmfully integrated, and can freely be received on its merits. And if it supplants network-manager, then it is certain to be well received after it has been tried, I expect. Unfortunately, the Wikipedia page says "In version 209, networkd was integrated", so the "monolithic monster" raises its ugly head, perhaps due to nothing more than misleading wording? If the developers are working to even a couple of pages of product specification, listing even the architectural goals and subsystem interfaces, then not only would developers have a clear view of the intended outcome, but prospective users could share in the clarity, and fear would abate if the architecture is unix compatible. I found little enlightenment here: http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.htm... Erik -- Nigeria's toll remained unchanged at eight dead from 20 cases. WHO has said it will be declared Ebola-free on October 20 if it has no further cases. - http://www.abc.net.au/news/2014-10-11/ebola-death-toll-passes-4000-who-says/...
On 14 October 2014 20:32, Erik Christiansen <dvalin@internode.on.net> wrote:
Unfortunately, the Wikipedia page says "In version 209, networkd was integrated", so the "monolithic monster" raises its ugly head, perhaps due to nothing more than misleading wording?
Depends what you mean by "integrated". My understanding is that systemd in no way requires systemd-networkd. I am not using systemd-networkd on any of my boxes. It is possible that systemd-networkd requires systemd. If this is the case, it will be because it requires services that have not been implement elsewhere - I would assume systemd-shim is the correct place to implement these services. In Debian, the systemd-networkd is provided by the systemd package. Maybe this is what the wikipedia page calls "Integrated"? I think it is possible to install the systemd package and not use systemd, however this isn't something that interests me personally. I am not a systemd developer however, so don't take my word for it. -- Brian May <brian@microcomaustralia.com.au>
Erik Christiansen <dvalin@internode.on.net> writes:
On the other hand, in the last quarter century, I've found traditional networking 100% reliable and easy to use, on HP-UX, Solaris (Sparc & x86), and several linux distros, both domestically and administering up to a dozen workstations. It is possible that I have never suffered ifup state confusion simply because I always use "ifconfig -a" to check interface state, simply through habit. (And if I'm not sure what I'm facing, then "/etc/init.d/networking restart" is zero risk in 99% of cases - a server with a single interface, which is in need of TLC.)
My impression is that Brian's talking about laptops that go walkies and have multiple ifaces on the same net, which I guess is harder to magic than a server, where you connect it up and then leave it alone forever. ifupdown's codebase is certainly ugly and unloved -- until recently it was still written in noweb!
On 15 October 2014 10:28, Trent W. Buck <trentbuck@gmail.com> wrote:
My impression is that Brian's talking about laptops that go walkies and have multiple ifaces on the same net, which I guess is harder to magic than a server, where you connect it up and then leave it alone forever.
There are a number of cases where it can get confused, not just laptops. For example, if you edit the network config and change a dhcp address to a static address, ifupdown won't kill the dhcp daemon for you. Or if you change the static address to a dhcp address - ifup will complain the interface is already up, and IIRC ifdown will complain that the daemon is not running. You are expected to shutdown the interface first, edit the configuration, then bring it up again. Which in turn increases the downtime. Or there are plenty of times I have encountered where "ifup" fails while half complete, meaning "ifup" will no longer work (those tasks are already done), and "ifdown" won't work either (the interface isn't marked as up). If you are working on a remote server, you want things to just work the first time, without fiddling around to try and ensure that ifup/ifdown are happy. Having said this, I haven't installed/configured systemd-networkd yet, so I can'[t be certain it will fix these problems. Would be surprised if it doesn't however. -- Brian May <brian@microcomaustralia.com.au>
Brian May wrote:
For example, if you edit the network config and change a dhcp address to a static address, ifupdown won't kill the dhcp daemon for you. Or if you change the static address to a dhcp address - ifup will complain the interface is already up, and IIRC ifdown will complain that the daemon is not running.
Excellent example, thanks.
On 15 October 2014 10:46, Brian May <brian@microcomaustralia.com.au> wrote:
Having said this, I haven't installed/configured systemd-networkd yet, so I can'[t be certain it will fix these problems. Would be surprised if it doesn't however.
For a real life account of somebody trying systemd-networkd, see the following blog post: http://www.joachim-breitner.de/blog/664-Switching_to_sytemd-networkd -- Brian May <brian@microcomaustralia.com.au>
Erik Christiansen writes:
» systemd [...]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. «
ITYM *third* kernel. Linux tarball is 60MB; chromium tarball is *600MB*. And GUI browsers are monolithic -- even down to little things like doing DNS resolution themselves because gethostbyname is "too synchronous".
On 14/10/14 11:42, Trent W. Buck wrote:
Erik Christiansen writes:
» systemd [...]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. «
ITYM *third* kernel. Linux tarball is 60MB; chromium tarball is *600MB*.
ITYM fourth kernel. X.org borders on an entire operating system.
On Tue, 14 Oct 2014 05:12:08 PM Jeremy Visser wrote:
ITYM fourth kernel.
Fifth..
X.org borders on an entire operating system.
*cough* emacs *cough*.. :-) (cue Monty Python - amongst our many kernels are such diverse elements as...) -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
2014-10-14 12:40 GMT+02:00 Chris Samuel <chris@csamuel.org>:
On Tue, 14 Oct 2014 05:12:08 PM Jeremy Visser wrote:
ITYM fourth kernel.
Fifth..
X.org borders on an entire operating system.
*cough* emacs *cough*.. :-)
(cue Monty Python - amongst our many kernels are such diverse elements as...)
Please, try to find an agreement at list about the sorting... :-D -- Mick
Chris Samuel <chris@csamuel.org> writes:
On Tue, 14 Oct 2014 05:12:08 PM Jeremy Visser wrote:
ITYM fourth kernel.
Fifth..
X.org borders on an entire operating system.
*cough* emacs *cough*.. :-)
Nah, Emacs doesn't have drivers to talk to hardware. You can use emacs as init, though. Works better than LiCE under Movitz...
"Peter Ross" <Petros.Listig@fdrive.com.au> writes:
It served us well. Just look at the well-described world of TCP/IP standards and their implementation under Unix/Linux, and compare it with Microsoft networking and the efforts of the Samba team to implement a second open source implementation, and especially a modular Samba 4.
Or just compare it to OSI ;-)
participants (11)
-
Andrew McGlashan -
Brian May -
Chris Samuel -
Craig Sanders -
Erik Christiansen -
Jeremy Visser -
Michele Bert -
Peter Ross -
Russell Coker -
Trent W. Buck -
trentbuck＠gmail.com