Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
From: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl That mostly applies to people who actually don't use systemd and are commenting from the peanut gallery. Actual *users* when they are unhappy are unhappy about bugs. That is not entirely true. I'm a user (because systemd is in Fedora 19), and I've complained that if I mark an /etc/fstab entry as nofail, some part of systemd will wait *forever* to see if the partition becomes available, whereas the behavior that I want (which was provided in earlier Fedora releases) is that once the system gets to the point of user logins, it will give up on automatic booting (and leave it to manual control). I've not received any useful feedback on how to customize my system to behave that way, and no indication that there is any intention to add it as a feature. So it is clear that this is not a bug, as it is the behavior intended by the designers, but I'm still not happy. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On 28/10/14 16:28, Dale R. Worley wrote: From: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl That mostly applies to people who actually don't use systemd and are commenting from the peanut gallery. Actual *users* when they are unhappy are unhappy about bugs. That is not entirely true. I'm a user (because systemd is in Fedora 19), and I've complained that if I mark an /etc/fstab entry as nofail, some part of systemd will wait *forever* to see if the partition becomes available, whereas the behavior that I want (which was provided in earlier Fedora releases) is that once the system gets to the point of user logins, it will give up on automatic booting (and leave it to manual control). I've not received any useful feedback on how to customize my system to behave that way, and no indication that there is any intention to add it as a feature. So it is clear that this is not a bug, as it is the behavior intended by the designers, but I'm still not happy. What you write above is not entirely true either: On 22/10/14 20:55, Lennart Poettering wrote: On Fri, 12.09.14 15:25, Dale R. Worley (wor...@alum.mit.edu) wrote: From: Tobias Geerinckx-Rice tobias.geerinckx.r...@gmail.com Step back, and define exactly what it is you actually need^Wwant to do. For a certain entry in /etc/fstab (which will in practice always have the option nofail), if the device is not available until booting is over (which I'm willing to denote with a specified period of time), after that, it will not be automatically mounted if it becomes available. This is currently not available, and it sounds very special and racy to support it upstream I think. Sorry! If you want to hack something up like this, I'd recommend writing a timer unit/cronjob that creates a file $PATH after $SECONDS after boot. Then, add a drop-in file to /etc/systemd/system/$MOUNTUNIT.d/foobar.conf, and write into it: [Unit] ConditionFileExists=!/the/file/you/create That way the mount unit will always be queued, but will actually be conditionalized out $SECONDS after boot, if you follow what I mean. Hope this is helpful. Lennart Cheers, Daniele ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, 28.10.14 11:28, Dale R. Worley (wor...@alum.mit.edu) wrote: From: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl That mostly applies to people who actually don't use systemd and are commenting from the peanut gallery. Actual *users* when they are unhappy are unhappy about bugs. That is not entirely true. I'm a user (because systemd is in Fedora 19), and I've complained that if I mark an /etc/fstab entry as nofail, some part of systemd will wait *forever* to see if the partition becomes available, whereas the behavior that I want (which was provided in earlier Fedora releases) is that once the system gets to the point of user logins, it will give up on automatic booting (and leave it to manual control). I have already replied to this, and pointed out that such a scheme is inherently racy, and that this is something we will unlikely support natively in systemd. Sorry for that. And please don't make this a but it worked fine in sysvinit! thing, because it was racy there as well. I've not received any useful feedback on how to customize my system to behave that way, and no indication that there is any intention to add it as a feature. http://lists.freedesktop.org/archives/systemd-devel/2014-October/024325.html I am sorry, if this reply doesn't make you happy, but I guess we will not be able to mke everybody happy. But please be fair enough to admit that you did get a response from us, and a clear explanation that we will not support this upstream, and why we won't do so. So it is clear that this is not a bug, as it is the behavior intended by the designers, but I'm still not happy. I am sorry for that, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Oct 28, 2014 5:05 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 28.10.14 11:28, Dale R. Worley (wor...@alum.mit.edu) wrote: That is not entirely true. I'm a user (because systemd is in Fedora 19), and I've complained that if I mark an /etc/fstab entry as nofail, some part of systemd will wait *forever* to see if the partition becomes available, whereas the behavior that I want (which was provided in earlier Fedora releases) is that once the system gets to the point of user logins, it will give up on automatic booting (and leave it to manual control). I have already replied to this, and pointed out that such a scheme is inherently racy, and that this is something we will unlikely support natively in systemd. Sorry for that. I think the actual issue here is the behavior of Type=idle, which delays the gettys for an annoying amount of time. Maybe launching the getty should shut off boot messages instead. Or maybe this should happen after a configurable IdleTimeout instead of having Type=idle always wait until end of transaction. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, Oct 28, 2014 at 05:16:38PM +0100, Jan Alexander Steffens wrote:
On Oct 28, 2014 5:05 PM, Lennart Poettering lenn...@poettering.net
wrote:
On Tue, 28.10.14 11:28, Dale R. Worley (wor...@alum.mit.edu) wrote:
That is not entirely true. I'm a user (because systemd is in Fedora
19), and I've complained that if I mark an /etc/fstab entry as
nofail, some part of systemd will wait *forever* to see if the
partition becomes available, whereas the behavior that I want (which
was provided in earlier Fedora releases) is that once the system
gets to the point of user logins, it will give up on automatic booting
(and leave it to manual control).
I have already replied to this, and pointed out that such a scheme is
inherently racy, and that this is something we will unlikely support
natively in systemd. Sorry for that.
I think the actual issue here is the behavior of Type=idle, which delays
the gettys for an annoying amount of time.
Maybe launching the getty should shut off boot messages instead. Or maybe
this should happen after a configurable IdleTimeout instead of having
Type=idle always wait until end of transaction.
You mean like the code in execute.c does?
#define IDLE_TIMEOUT_USEC (5*USEC_PER_SEC)
...
r = fd_wait_for_event(idle_pipe[0], POLLHUP, IDLE_TIMEOUT_USEC);
if (idle_pipe[3] = 0 r == 0 /* timeout */) {
/* Signal systemd that we are bored and want to continue. */
;)
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
El mar, 28-10-2014 a las 17:05 +0100, Lennart Poettering escribió: [...] http://lists.freedesktop.org/archives/systemd-devel/2014-October/024325.html Looks interesting. Have you think in having some kind of wiki or page listing this kind of tricks to solve things like that. That way we prevent people from applying many different solutions that could have different drawbacks and also have them in a place a bit more easily accessible Thanks a lot ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
From: Lennart Poettering lenn...@poettering.net Please, let's discuss this elsewhere. Let's keep a strict technical focus on this ML! I believe that you mean that outsiders are welcome here to provide assistance to systemd as it has already been implemented. One difficulty is that outsiders are usually not able to provide such assistance. It would be useful if there was a mailing list where outsiders could come with problems -- systemd does not implement what I need as it is provided by the distro. I would expect such a mailing list to be named systemd-users. But no such list seems to exist. (And thus, they show up in systemd-devel.) This leaves users with the sense that they are expected to use systemd as it is provided, and it makes it hard for them to customize systems that do what they need. This reminds them of Microsoft products and makes them unhappy. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, 27.10.14 18:25, Dale R. Worley (wor...@alum.mit.edu) wrote: From: Lennart Poettering lenn...@poettering.net Please, let's discuss this elsewhere. Let's keep a strict technical focus on this ML! I believe that you mean that outsiders are welcome here to provide assistance to systemd as it has already been implemented. One difficulty is that outsiders are usually not able to provide such assistance. It would be useful if there was a mailing list where outsiders could come with problems -- systemd does not implement what I need as it is provided by the distro. I would expect such a mailing list to be named systemd-users. But no such list seems to exist. (And thus, they show up in systemd-devel.) Well, systemd is a suite of components that people build OSes from. As such it isn't really an app you install on top of your OS, it's more a toolset for distro and device builders. Now, if end users have questions about details how they can uses these devices and distros, then I figure they should always contact the manufacturers of these devices, and the distro developers first. Or in other words: we are not the final product that people should interface with, we just provide a set of components where other people can build final products out, and by doing so they also need to take the responsibility for providing a first level of help for it. Now, of course, the more technical things get, sometimes its better to ask upstream, and we currently do not have a separate ML for questions like that, we use systemd-devel for that, which of course is primarily used for development. But I think it's still OK that way, as the amount of technical user question we get is still managable, and by not making the distinction between the group of developers and the group of users too strict I guess our community can only win. systemd-devel is the place for *technical* discussions only though. If you have a technical point to make, a technical question to ask, a patch to send, a technical suggestion to make, a technical feature request to post, it's the right place. However, it's not the place for UNIX philosophy discussions, about discussions what we should be and what we shouldn't be. Now we could open a new ML for that philosphical kind of stuff, but I have serious doubts that many of us developers would subscribe there, hence I think it would be better to do those discussions elsewhere, maybe on blogs, g+ posts, on twitter, on lwn, on reddit... The discussions are being had there anyway, and that's OK that way. Some of the systemd developers scan and post on these forums anyway[1], regularly, hence I really don't see the need for a new ML. Lennart [1] I scan and sometimes post on LWN. I think Tom does the same on g+ and lwn. Daniel on twitter, and so on... -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, Oct 27, 2014 at 06:25:56PM -0400, Dale R. Worley wrote: From: Lennart Poettering lenn...@poettering.net Please, let's discuss this elsewhere. Let's keep a strict technical focus on this ML! I believe that you mean that outsiders are welcome here to provide assistance to systemd as it has already been implemented. One difficulty is that outsiders are usually not able to provide such assistance. No really, people do feature requests here and on the bug trackers all the time [1]. Nevertheless, systemd is a low level compenent, and not really directed at *users* as such, more at os developers, packagers, etc. So the distinction between development and use is not clearly cut. Questions and bug reports often lead directly to changes in the codebase. Creating a split into two lists would only slow things down here. Creating a separate systemd-users list was discussed, but who would answers the questions there? If you expect the developers do it, then there isn't much difference than simply answering those questions on -devel. If you expect other people to do it, then wiki style distribution-specific documentation is better in the long run, since systemd is a fast moving target and the best practice often changes over time. What I think you're really thinking about is systemd-advocy to discuss lofty ideals and deep motivaitions. But nobody has time for that ;) [1] https://bugs.freedesktop.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=NEEDINFObug_status=PLEASETESTcomponent=generalknown_name=systemd%20RFEslist_id=485720product=systemdquery_based_on=systemd%20RFEsquery_format=advancedresolution=---short_desc=^RFEshort_desc_type=regexp It would be useful if there was a mailing list where outsiders could come with problems -- systemd does not implement what I need as it is provided by the distro. I would expect such a mailing list to be named systemd-users. But no such list seems to exist. (And thus, they show up in systemd-devel.) This leaves users with the sense that they are expected to use systemd as it is provided, and it makes it hard for them to customize systems that do what they need. This reminds them of Microsoft products and makes them unhappy. That mostly applies to people who actually don't use systemd and are commenting from the peanut gallery. Actual *users* when they are unhappy are unhappy about bugs. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, 21.10.14 11:25, Martin Steigerwald (mar...@lichtvoll.de) wrote: The scopes and slices concept does not exist elsewhere, and there's nothing comparable around, so even if we wanted we couldn't make logind work on anything else. Then why in the first hand are the scopes and slices concepts within systemd *tightly* coupled when it is functionality that makes sense to be utilitizes in a component that provides a different functionality. It's how people generally build systems: the lower layers provide basic functionality, the upper layers then make use of. To keep our code small and simple we do things that way. We don't reimplement all functionality all the time on all levels, because we don't want to make any assumptions about what the layers below us provide us with. I wonder what functionality systemd provides right now in one more or less tightly coupled package: - early boot process - managing kernel drivers and device files (via coupled udev) - resource control for process groups - logging - core dumping - network while I think a distro-unified way to approaching network that replaces the current distro specific ways like ifupdown and so on, why does it have to be coupled with systemd? We maintain this stuff in one repository, and release it with simultaneous release cycles. We can share tons of code that way, and easily give it a uniform, integrated feel from the outside. Things like the core dumping or networkd are purely optional. If you don't like them, don't use them. - cron, although that at least in Debian is separate as systemd-cron Hmm? not sure what that is supposed to be. We have no cron in systemd, only timer units. Way more than traditonal sysvinit covered. yeah, systemd is a basic toolbox to build an OS from, sysvinit was just a minimal init system, and nothing else. What of this actually *needs* to be coupled with systemd? What of this needs to be coupled tightly to Linux kernel? No, nothing needs to be coupled. But it makes development for us vastly simpler and the system altogether more uniform and smaller. systemd is driving a road where its all of this functionality by default is only available for Linux and where upstream said they just won´t accept patches – is that still true? – for portability. systemd provides more and more functionality that desktops like to use, that other tools like to use. We take portability patches for other archs, but not for other kernels. It's also really a pointless excercise, the BSDs or Solaris would never adopt systemd anyway, I am not sure why you'd think otherwise. They all have their own (unportable) service management logic they don't make portable either. Most prominent is Solaris' SMF which is tied closely do their contract ids, which is not portable. Moreover note that the BSDs at least actually are much stricter then we are. We *just* put the moszt basic bits of the OS glue into one repository and apply one common release cycle to it. On FreeBSD they also maintain the libc and the kernel in the same framework and schedule. When Microsoft back then did something like this it was called Embrace, Extend and Extinguish¹… Oh come on. You are just being a dick now. a) Embrace: systemd provides functionality that is mostly compatible or similar with what sysvinit and other components provided b) Extend: systemd extends on that functionality and makes it more and more difficult for desktops and apps to ignore that kind of functionality offers c) Extinguish: The scope of systemd becomes so broad, the functionality it offers in a – admittedly – convenient package to often needed and used, that other ways of providing the functionality are extinguished. Really… it matches quite closely. No it doesn't. We provide you something for free. We don't care if you use it or you don't. We don't take your freedom away by offering this to you for free. Show some respect, man! I don´t think this was your plan. But… when looking at the currently visible outcome this is quite exactly what is happening here. Please, instead of making up your weird theories, actually do something about things. I'd welcome any competition. It's really not my fault if the people who actually like systemd appear to do almost all work and thus adopt it. And the people who don't just sit around and talk. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Wed, 22.10.14 15:54, Dale R. Worley (wor...@alum.mit.edu) wrote: From: Lennart Poettering lenn...@poettering.net We are always interested in technical feedback. We are not very interested in FUD mails that tell us how we'd force people, how we'd behave like microsoft and so on. That's not useful, that's pretty much only hurtful. I haven't read this full thread, and it probably isn't useful for me to do so. But it seems that the first question to be answered by the developers is: Are they concerned that uptake is not as fast as they'd like? No. We are not concerned. Within three years all most major distros opted for systemd as default. That's way more and way quicker than what we could ever hope for. and if the answer to that is Yes, then: Would they like to hear feedback from users as to what they might do about it? Yes, we always ask for good feedback. Much of what systemd is today is the result of getting and incorporating feedback. However, we are not really interested in constantly repeated claims of forcing and being like microsoft, because that's neither original, nor true, nor interesting, nor technical, nor relevant. Also, note that while we care a lot for useful feedback we will not implement everything people ask for, and even deny patches. Saying no to patches and suggestions is necessary to keep the project on track. We will continue to do so. If figure by average though, we probably implement two suggestions we got through feedback for every one suggestion we refuse. And if we say no to a suggestion or patch you'll at least get an explanation why. hence, please keep the feedback coming, we appreciate it, but please stay relevant, and please don't be put off if we say no to something. if we say no to some thing, try again with something else. Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
That is fine and your choice. It doesn't seem like there is anything similar to an RFC process for systemd, so say that the General Development and Discussion Mailing List is changed to a new ML. The name of this list is changed to Developer and Technical question but remains the same list, systemd-devel@lists.freedesktop.org, so that no one needs to re-subscribe. There doesn't seem to be anything like an RFC process for systemd, so all the people who want to discuss changes in scope, changes in implementation strategy have a place to vent. If you want to listen in you can, if you don't you don't have to see the emails in this list. -Original Message- From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On Behalf Of Tomasz Torcz Sent: Thursday, October 23, 2014 12:14 PM To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance On Thu, Oct 23, 2014 at 05:00:04PM +, dennis.mur...@wipro.com wrote: One thing I would like to point out, on the project website there is NO mailing list for advocacy. The comment this is for technical email only use a different ML is for all purposes just a brush off. If the project would create an advocacy mailing list it would go a long way toward segregating the email. Who would participate in such list? I wouldn't, personally. I prefer technical discussions. -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Thu, Oct 23, 2014 at 05:00:04PM +, dennis.mur...@wipro.com wrote: One thing I would like to point out, on the project website there is NO mailing list for advocacy. The comment this is for technical email only use a different ML is for all purposes just a brush off. If the project would create an advocacy mailing list it would go a long way toward segregating the email. Who would participate in such list? I wouldn't, personally. I prefer technical discussions. -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am 23.10.2014 um 19:14 schrieb Tomasz Torcz: On Thu, Oct 23, 2014 at 05:00:04PM +, dennis.mur...@wipro.com wrote: One thing I would like to point out, on the project website there is NO mailing list for advocacy. The comment this is for technical email only use a different ML is for all purposes just a brush off. If the project would create an advocacy mailing list it would go a long way toward segregating the email. Who would participate in such list? I wouldn't, personally. I prefer technical discussions. that is fine, but than use a different ML means use one which we don't read signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Hi Martin, If you were to phrase your complaints/questions in terms of technical issues, we could probably have a much more useful debate. What is clear is that the systemd project will not do or change anything merely based on some bystanders gut feeling (which is basically what you have argued from). If you are concerned about portability, go ahead, follow the advice given here, start the port and once you hit issues come back and ask questions. Until someone does this, I think we should consider the whole portability issue closed. Same for modularity, make a fork (in the sense Colin used) of the parts of systemd you want to use in isolation, and come back when you run into problems (there surely will be some, but maybe you can still do the things you want). On Wed, Oct 22, 2014 at 2:13 AM, Martin Steigerwald mar...@lichtvoll.de wrote: I will make an effort to reply to your mail and then most likely unsubscribe, cause for me I feel like being in an hostile environment. When you ignore technical answers, and more than insinuate that we use the same vile practices as Microsoft once did (despite you claiming you don't mean to accuse anyone, the way it comes out is a quite strong accusation), you should expect some less than friendly responses. That said, I think Lennart and Colin both went after your arguments not your person (if you bother reading carefully what they wrote). No. I am concerned about both. The functionality that is stuffed inside PID 1 which is more than 1,3 MiB and also sports user session functionality. And what is coupled inside on project, more or less tight. I already answered the issue with user sessions (and so have others), I'm disappointed that you would bring it up again without seeming to have read our replies. As to the size of PID1, why don't you go and study why this is so? The code is there, there are tools to study the binary. Then hopefully you would either agree that the size is unproblematic, or you would come up with some constructive suggestions/patches to change things. It also increases the test matrix. If logind v300 has to work with libsystemd v300 and all future versions then the testing side of things increases in complexity *massively*. Again this causes problems that translate to time and effort of developers that could better be allocated to building a better overall set of building blocks. I do think that the easiest way to do something is not necessarily the best. If you think there is a better way to do things, go ahead, do it. Vaguely complaining that we should have done this or that differently is not going to change any minds. It is worth noting (again) that the way we manage our repository does not mean that others could not make replacements for parts of systemd, the stuff is very modular. But don't take my word for it, start coding and when you run into problems come back with questions. You are probably not getting out of this discussion what you hoped for (I assume). Sorry about that. If you come back with bug reports, feature requests or patches, you will have a much easier time influencing things. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Hello Martin, Firstly, I apologise if you took what I said as a personal insult. It was not my intention to do so (and I did try to make that explicitly clear in a footnote). I will certainly admit that some of my wording was more directed than I had intended. This is something I would normally edit out and soften on a read over, but time constraints didn't allow me that luxury. That said, I do stand by my general comments. I will attempt a briefer reply below [Spoiler: I failed!] Martin Steigerwald wrote on 22/10/14 01:13: I received this twice on this mailing list. Once from Lennart (being a dick now) and now from you calling me a troll. For the avoidance of doubt, I didn't directly call you a troll. I was trying to point out that even well intentioned discussions, like yours, cat at times become indistinguishable from a trolling discussion. Not deliberate (which trolling is), but because no matter what reply is sent, the participants will not be satisfied with the answers and will continue the discussion. It would appear that this discussion has reached that stage. Over various points, there have been answers given and corrections made, and yet still no acceptance is really given to those decisions - it's at a time like this where further discussion is counter productive to your goal and just serves to alienate people rather than get them any closer to sharing your opinion. I will make an effort to reply to your mail and then most likely unsubscribe, cause for me I feel like being in an hostile environment. I disagree that this is a hostile environment. It's just that people here will (by definition) generally just disagree with you. I apologise if my reply was worded in an overly-hostile way (I'll try better in this email), but ultimately you're going to get replies here that will generally disagree with your stance. Thats rather much. Really rather much. Way more than traditonal sysvinit covered. This is because traditional sysvinit covered PID 1 and performing it's job (if you consider e.g. killall5 and friends). You seem to be conflating systemd as PID 1 and systemd as a project. These are two completely different things. No. I am concerned about both. The functionality that is stuffed inside PID 1 which is more than 1,3 MiB and also sports user session functionality. You use the term stuffed which is preloaded with negativity. Your wording here would be better if you'd used the more neutral term included in rather than stuffed inside. By using this phrasing you're already building up a barrier and will be polarising upstream developers and will be reflected in their replies. As another technical correction, PID 1 does NOT sport user session functionality. It sports a general resource management concept (scopes and slices) that is a userspace abstraction of the kernel cgroups concept used for resource management. This is seen as core functionality as it's PID1's job to fundamentally fork off other processes. I don't think this is a point of contention. Some people have argued that resource management should NOT be PID1's job, and it should handled by a separate daemon. The argument thus far from the systemd side is that doing this out of process would create a chicken and egg problem. It's PID1's job to fork of processes and configure their resources, but the resource manager processes' forking would have to be special cased as there would be no resource manager available when it was forked. If this sub component fails, then PID1 fails too. It's so tightly coupled that the arguments for doing it out of process are simply not sufficiently compelling, so this special casing is not something systemd developers are comfortable with technically due to both startup and runtime requirements. The user session functionality you speak of is implemented outside of PID1 in logind. Because it also needs to manager resources, it has to work with the resource manager which, as described above, is PID1 in systemd. If other init systems want to do this differently they are welcome to do so. An alternative would be to make the utility functions API stable and export the shared library publicly and give API guarantees, but that puts a lot of pressure and it's a difficult thing to provide and it has long term maintenance overhead. This is something that *costs*. It costs in time/man hours and therefore it carries real overheads. Doing this for the convenience of splitting things out is simply not worth it - especially so as the main people working on these things are the same people. I don´t think it would be just for the convenience of splitting things. It would also be to address the concerns I summarized and that have been made elsewhere. You may heard these concerns often, you may not agree to them. Yet, if you say later that some of these concerns were made 5 years ago already… If those concerns are still there… either… its due to Debian adopting
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
- Original Message - From: Lennart Poettering lenn...@poettering.net We are always interested in technical feedback. I have seen this comment several times from the systemd devs, and I don't doubt it. But I think much of the criticism of systemd is not technical. It has a more social/political nature, and I think you should be interested in that feedback as well (even if it is technically un-interesting). Here is an example of what I consider a social/political problem stemming from technical decisions: Say you are a housing developer. After many calculations, you have decided that the best design for housing is a cube. It has a high volume-to-surface-area ratio, which allows it to house the most people with minimal heating/cooling loss to the outside environment. It is easier to build than a sphere (which would have a higher volume-to-surface-area ratio). To further maximize efficiency, each building will be a multi-unit dwelling. Interior units will have very little heat transfer to the outside, because the surrounding units help insulate them. However, I don't want to share walls with another family, so I decide to buy a standalone house even though it is technically less efficient. That's my choice, and choice is great, right. But then I try to buy an air conditioner (cooling unit), and I find out that it is only compatible with your multi-dwelling cube house. Why? Because you have integrated some wonderful sensor technology into your buildings that the air conditioner manufacturer wants to take advantage of. So now I have a choice: live in the house of my choice with no air conditioner, or live in your building with an air conditioner. If you had designed your sensor system to be a separate piece, rather than integrating it directly into the building, I could buy any house I want and still have an air conditioner. But because of your design choices (as well as the choices of the air conditioning manufacturer), my choice of housing is limited or even eliminated. Tightly integrating the sensor system into the building may have been the technically best solution, but it has negative consequences in non-technical areas. I hope you will give consideration to the non-technical as well as the technical when making your design decisions. In case anybody's having trouble with the analogy: The cube house is systemd. The sensor technology is logind. The air conditioner is pretty much any Gnome application. The non-cube house is any other init system besides systemd. -Rob ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Wed, 22.10.14 12:11, Rob Owens (row...@ptd.net) wrote: We are always interested in technical feedback. I have seen this comment several times from the systemd devs, and I don't doubt it. But I think much of the criticism of systemd is not technical. It has a more social/political nature, and I think you should be interested in that feedback as well (even if it is technically un-interesting). Please, let's discuss this elsewhere. Let's keep a strict technical focus on this ML! Thank you for your understanding! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
- Original Message - From: Lennart Poettering lenn...@poettering.net On Wed, 22.10.14 12:11, Rob Owens (row...@ptd.net) wrote: We are always interested in technical feedback. I have seen this comment several times from the systemd devs, and I don't doubt it. But I think much of the criticism of systemd is not technical. It has a more social/political nature, and I think you should be interested in that feedback as well (even if it is technically un-interesting). Please, let's discuss this elsewhere. Let's keep a strict technical focus on this ML! Thank you for your understanding! Lennart It is your ML, so I will oblige. But I think it is a mistake to not consider a broader view of your project than just the strictly technical aspects. -Rob ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
From: Lennart Poettering lenn...@poettering.net We are always interested in technical feedback. We are not very interested in FUD mails that tell us how we'd force people, how we'd behave like microsoft and so on. That's not useful, that's pretty much only hurtful. I haven't read this full thread, and it probably isn't useful for me to do so. But it seems that the first question to be answered by the developers is: Are they concerned that uptake is not as fast as they'd like? and if the answer to that is Yes, then: Would they like to hear feedback from users as to what they might do about it? There's no point in jabbering about it unless the answer to the second question is Yes. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
El 22/10/14 a las #4, Rob Owens escribió: It is your ML, so I will oblige. But I think it is a mistake to not consider a broader view of your project than just the strictly technical aspects. It is not *his* mailing list..but it is the place where *technical* discussions about the systemd project take place. I can only speak for myself but if you have been subscribed for a reasonable amount of time, you will see the concurrence is mostly if not completely only in the technical aspect and does not seem to have any interest on the topic of philosophical wanking. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am Sonntag, 21. September 2014, 15:31:15 schrieb Martin Steigerwald: Hello! I know this is a daring post. I just have one question. In the light of http://boycottsystemd.org/ http://uselessd.darknedgy.net/ developing some systemd compatible services for BSD: http://undeadly.org/cgi?action=articlesid=20140915064856 in the light of Debian Bug report logs - #727708 tech-ctte: Decide which init system to default to in Debian. https://bugs.debian.org/727708 Debian Bug report logs - #746715 the foreseeable outcome of the TC vote on init systems https://bugs.debian.org/bug=746715 in the light of the ongoing discussions on linux-kernel, debian-devel, debian- user and other mailing lists more than some dozens threads meanwhile: In my long years of using Debian and also doing some packages for it in the last years I never saw that any introduced changed caused a serious we may need to fork like announcement like this: http://debianfork.org/ Also the upcoming GR decision about whether to require that packages may not depend on PID 1 it refers to. I think I never saw that kind of uproar in Debian. In my view its worrying and damaging. And I think it points at a real problem. There is a dire problem with the acceptance of systemd in Debian (and not only there). In Debian this is not only with users, but also with developers. Wherever I look systemd triggers a split into pro and contra. Even here at work. I still use it, I test it, it seems to work. But I am concerned. Some co-workers dislike it highly. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Hi Rob, Am Montag, 6. Oktober 2014, 14:56:22 schrieb Rob Owens: - Original Message - From: Martin Steigerwald mar...@lichtvoll.de Heck, I started a thread here and then didn´t manage to take time to carefully read it and reply here and there as I see fit. But I challenged people on debian-user mailing list to constructively voice their concerns upstream, and even pointed them to this mailing list. As far as I saw *no one* of the posters in debian-user took up on that challenge. Which I view as a pity. Cause now actually you invited constructive feedback. I wonder whether I may forward your answer to debian-user so they see your statement of inviting constructive feedback. I am here from debian-user, due to Martin's suggestion. So now that he's calling me out, I guess I'll post my questions :) For the record, I'm a sysadmin and not a developer. I imagine my questions and opinions will reflect that. Thank you for voicing your concerns as one of the many users who where not so hesitant to voice their concerns on the debian-user mailing list. Here the feedback I read over and over again is that you and RedHat basically forced the systemd decision onto other distributions. While I do not see how you actually can be powerful enough to do that, as we live in a free will zone. I do see tendencies that more and more stuff *depends* on systemd cause it needs features only available there. On of the most talked on things on debian-user is the logind thing. GNOME actually depends on it, as far as I know. While KDE in Debian still uses ConsoleKit, as it seems to me when looking at the process list and finding: On Debian, I came across an unusual dependency. Installing a cd burner (brasero) required me to change my init system to systemd. Sounds kind of ridiculous, I think. The dependency chain went like this: brasero - gvfs - gvfs-daemons - udisks2 - libpam-systemd - systemd-sysv I really find this kind of chain quite ridiculous. But if its breakable at least as Martin told… still. I think its important to make sure that installing brasero does not accidentally switch a sysvinit system to systemd. As it would be the least a user would expect here and from common sense it does not even make sense. It may make sense technically as explained, but from a user and sysadmin point of view it does not make any sense at all and is quite disruptive. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, Oct 21, 2014 at 10:53 AM, Martin Steigerwald mar...@lichtvoll.de wrote: Am Montag, 6. Oktober 2014, 21:53:04 schrieb Zbigniew Jędrzejewski-Szmek: Systemd-shim provides some functionality that systemd-sysv provides, and allows admins to use init systems other than systemd while still installing things like brasero. I think this is a great thing, except I wonder why the systemd project didn't separate this functionality from the init system in the first place. Systemd-shim is a duplication of effort. Not only that, but it must time its releases with the releases of systemd-sysv. That's no big deal for Debian's stable release, but it can be problematic in Debian's unstable and testing branches. Because it's additional work and complications. Apparently providing systemd functionality without systemd running is not a trivial undertaking, as the lag between systemd and systemd-shim releases shows. I could spend my time for open source development on a (technically) pointless (from my vantage point) split, but I prefer to improve systemd instead. Debian as a project already paid significant to support systemd as an alternative, when systemd version was held back for a year waiting for systemd-shim to catch up. This is certainly not the last time. [snip] I think exactly this kind of attitude is what triggers most of the polarity around systemd. Its like We don´t force systemd on anyone, but we provide as lots of functionality tightly coupled with it and if you do not implement it elsewhere, i.e. catch up, you need systemd anyway. While I believe it is *extra* work to separate functionality, I think it is *important* work. It would raise the acceptance of systemd, it would reduce the polarity it triggers. And it would make it more interoperable. Right now people are duplicating systemd stuff in several other areas. The reluctance to adopt systemd with certain distributions creates friction. Other implementations need to catch up and at any point in time may not be compatible. So, aside from it being additional work, is there any *solid* or even *unavoidable* technical reason to couple functionality that tightly? Wherever I look free software projects do great extra work to modularize and separate out functionality that can be separate. For a reason. See KDE community for example. They spend years of development work into separating things out into separate packages and have a clear ruling on what may depend on what. There are other examples for sure, OpenStack for example, while I do not yet know it in detail consists of a ton of separate packages in Debian. So or so… I think its this kind of attitude that triggers most of the polarity and split. Most of the modules in systemd do not depend on eachother. However, logind does depend on the cgroups dbus API of systemd (PID1). In the past logind interacted with the cgroups fs directly, but this had to be changed as the kernel is moving to a model where only one process may be in charge of cgroups. On systemd systems that one process is PID1 (why that is so has been discussed elsewhere so won't repeat that), so anything needing to deal with cgroups needs to go through the systemd API. I hope that explains why logind has to depend on systemd (or at least something implementing the systemd API). Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am Dienstag, 7. Oktober 2014, 23:40:45 schrieb Uoti Urpala: On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote: My question really isn't why are the Debian dependencies the way they are. I understand that. I was trying to highlight the strange situation of a desktop application requiring a particular init system. I *think* this is a result of the init portion of systemd being bundled together with the logind portion of systemd. To me (unfamiliar with the systemd code) those two functions seem distinct enough to merit being separate. Debian can't easily separate what the systemd devs have developed as a single binary, so we end up with these strange dependency chains. Single binary is false of course. Logind is developed as a separate program, which is why systemd-shim is possible at all. AFAIK the actual relevant dependencies go as follows: First, there's a good reason why logind requires cgroup functionality. And there's a good reason why cgroup functionality is best implemented together with init (see http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ for more info). So it's not quite directly logind has to depend on systemd as init, but logind has to depend on the system having cgroup support, and there's no equally good cgroup support available for inits other than systemd. It is possible to provide the relevant cgroup interfaces in or on top of another init, as the systemd-sysv + cgmanager combination attempts to do. But it is not trivial to do, as bugs and implementation delays with that combo have shown, and it's quite likely that there will be more problems in the future. It's not a particularly good idea to use the less-tested and less-reliable systemd-shim instead of the more reliable systemd. Thus the overall result is that yes, it does make sense to switch machines to systemd when you add certain functionality, even if that functionality does not appear to be directly tied to the init system at first glance. I can´t point my finger at it why… but I really feel uncomfortable with this tight coupling. I think that the systemd-shim + cgmanager combination may have bugs does not *prove* that such a think isn´t workable. But due to the design choice of you systemd developers to have it all in one people who do believe that separating different functionality is for the long term benefit of interoperability and avoiding what I´d call vendor lock in, although I clearly see that systemd upstream community isn´t a single vendor as in one company who produces a comercial product. In other areas where the Linux kernel requires user space helpers things initially have been separated. The whole do it all in once hald daemon was split into udev, libudev, udisks and upower… yet now, systemd and udev is in one upstream again. What speaks against putting the cgroup functionality and other stuff from systemd into shared libraries with clearly defined APIs – which are documented and where the documentation is the reference, not the source code – and allowing it to be used elsewhere? Then systemd may use it as PID 1, but if someother wants to use it in own project, can use it as well. I consider cgroups as part of the kernel API and I highly dislike the battle on which of the available solutions will get control over it. Actually I still think the API is broke if it cannot allow for mutiple processes accessing it. I don´t know an easy way to fix it, but I think such a kind of API as kernel interface… anyone can read a file, mount a filesystem, open a network socket, set a nice value depending on permissions but when it comes to control groups it is down to one to rule them all. I can´t help it, but this just seems utterly broke to me. I can´t help it but I don´t consider this to be a sane operating system API. I never thought much about my init system until recently. I never really had any complaints with SysV init, although I do recognize that systemd provides real improvements for some use cases. So for me as a sysadmin the wisest thing to do is stick with what I already know, as long as it's working well enough (and for me, it is). The issue with I should be able to stay with sysvinit because it worked fine for me is that keeping sysvinit working is COSTLY. The reason sysvinit used to mostly work was not that it would have been a reliable system - it mostly worked because people kept using a lot of effort to work around and paper over various issues that kept popping up. And there's no justification to keep up that effort for the minority who wants to stay with sysvinit. So, you can keep running your old systems unchanged if you want, but you shouldn't expect to be able to upgrade them or install new software without switching to systemd. What you write here basically comes down to a forced adoption. At least this is how I receive what you write. I know understand much more clearly on why
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, 21.10.14 10:53, Martin Steigerwald (mar...@lichtvoll.de) wrote: So, aside from it being additional work, is there any *solid* or even *unavoidable* technical reason to couple functionality that tightly? Yes, there always is. For logind for example we need to be able to group the processes of a session, so that we can keep track of them, list them, kill them, get notifications about them, and so on. For that we need the scope concept of PID1. That's why logind talks to PID 1. You know, it really annoys me if you imply that we just made these choices because we are assholes. We use the APIs we use because we need their technical functionality. It's that simple. It would be great if you'd grant us the benefit of the doubt at least, instead of implying anything else. Wherever I look free software projects do great extra work to modularize and separate out functionality that can be separate. For a reason. See KDE community for example. They spend years of development work into separating things out into separate packages and have a clear ruling on what may depend on what. There are other examples for sure, OpenStack for example, while I do not yet know it in detail consists of a ton of separate packages in Debian. Well, we are not KDE, and not OpenStack. We provide a basic toolbox to build an OS from. Compare us with Busybox if you must. I don't hear you complaining about busybox all the time! So or so… I think its this kind of attitude that triggers most of the polarity and split. Well, our priority is to solve technical problems in a way we perceive elegant and minimal. Your priority appears to be appeasing people who prefer religious reasoning over technical reasoning. I am pretty sure you cannot appease those, and we will not compromise our technical necessesities for that. Anyway, can we please end this discussion on this ML please? Please continue this somewhere else, this ML is really for technical discussions. Sorry, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am Mittwoch, 8. Oktober 2014, 10:54:00 schrieb Lennart Poettering: On Tue, 07.10.14 23:40, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote: My question really isn't why are the Debian dependencies the way they are. I understand that. I was trying to highlight the strange situation of a desktop application requiring a particular init system. I *think* this is a result of the init portion of systemd being bundled together with the logind portion of systemd. To me (unfamiliar with the systemd code) those two functions seem distinct enough to merit being separate. Debian can't easily separate what the systemd devs have developed as a single binary, so we end up with these strange dependency chains. Single binary is false of course. Logind is developed as a separate program, which is why systemd-shim is possible at all. AFAIK the actual relevant dependencies go as follows: First, there's a good reason why logind requires cgroup functionality. And there's a good reason why cgroup functionality is best implemented together with init (see http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ for more info). So it's not quite directly logind has to depend on systemd as init, but logind has to depend on the system having cgroup support, and there's no equally good cgroup support available for inits other than systemd. It is possible to provide the relevant cgroup interfaces in or on top of another init, as the systemd-sysv + cgmanager combination attempts to do. But it is not trivial to do, as bugs and implementation delays with that combo have shown, and it's quite likely that there will be more problems in the future. It's not a particularly good idea to use the less-tested and less-reliable systemd-shim instead of the more reliable systemd. Thus the overall result is that yes, it does make sense to switch machines to systemd when you add certain functionality, even if that functionality does not appear to be directly tied to the init system at first glance. Also note that the systemd concepts logind makes use of are also exported in its own API. The scopes and slices that logind uses are exposed on its bus objects, and they are used by tools like loginctl to do their work. The scopes and slices concept does not exist elsewhere, and there's nothing comparable around, so even if we wanted we couldn't make logind work on anything else. Then why in the first hand are the scopes and slices concepts within systemd *tightly* coupled when it is functionality that makes sense to be utilitizes in a component that provides a different functionality. I wonder what functionality systemd provides right now in one more or less tightly coupled package: - early boot process - managing kernel drivers and device files (via coupled udev) - resource control for process groups - logging - core dumping - network while I think a distro-unified way to approaching network that replaces the current distro specific ways like ifupdown and so on, why does it have to be coupled with systemd? - cron, although that at least in Debian is separate as systemd-cron Thats rather much. Really rather much. Way more than traditonal sysvinit covered. What of this actually *needs* to be coupled with systemd? What of this needs to be coupled tightly to Linux kernel? systemd is driving a road where its all of this functionality by default is only available for Linux and where upstream said they just won´t accept patches – is that still true? – for portability. systemd provides more and more functionality that desktops like to use, that other tools like to use. When Microsoft back then did something like this it was called Embrace, Extend and Extinguish¹… a) Embrace: systemd provides functionality that is mostly compatible or similar with what sysvinit and other components provided b) Extend: systemd extends on that functionality and makes it more and more difficult for desktops and apps to ignore that kind of functionality offers c) Extinguish: The scope of systemd becomes so broad, the functionality it offers in a – admittedly – convenient package to often needed and used, that other ways of providing the functionality are extinguished. Really… it matches quite closely. I don´t think this was your plan. But… when looking at the currently visible outcome this is quite exactly what is happening here. So if you can follow this just a tiny bit: Do you start to understand why systemd triggers the uproar, polarity and split so obvious that one needs to have hands before both eyes for not seeing it? So as I see it: there are *real* concerns. And if systemd is meant to be a tool for users and admins, I *highly* and *strongly* recommend that you as systemd closely look at these concerns. Unless you are willing to trigger the polarity, the split and the uproar that it
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, Oct 21, 2014 at 11:08 AM, Martin Steigerwald mar...@lichtvoll.de wrote: Then systemd may use it as PID 1, but if someother wants to use it in own project, can use it as well. I consider cgroups as part of the kernel API and I highly dislike the battle on which of the available solutions will get control over it. Actually I still think the API is broke if it cannot allow for mutiple processes accessing it. I don´t know an easy way to fix it, but I think such a kind of API as kernel interface… anyone can read a file, mount a filesystem, open a network socket, set a nice value depending on permissions but when it comes to control groups it is down to one to rule them all. I can´t help it, but this just seems utterly broke to me. I can´t help it but I don´t consider this to be a sane operating system API. Note that the maintainers of the kernel-side cgroup API (primarily Tejun Heo, AFAIK) consider the current interface insane. In the future, the kernel will expect a single userspace process to control a single hierarchy. Systemd has already been adapted to provide this schema using the current API. See http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html . ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am Dienstag, 21. Oktober 2014, 11:07:01 schrieben Sie: On Tue, Oct 21, 2014 at 10:53 AM, Martin Steigerwald mar...@lichtvoll.de wrote: Am Montag, 6. Oktober 2014, 21:53:04 schrieb Zbigniew Jędrzejewski-Szmek: Systemd-shim provides some functionality that systemd-sysv provides, and allows admins to use init systems other than systemd while still installing things like brasero. I think this is a great thing, except I wonder why the systemd project didn't separate this functionality from the init system in the first place. Systemd-shim is a duplication of effort. Not only that, but it must time its releases with the releases of systemd-sysv. That's no big deal for Debian's stable release, but it can be problematic in Debian's unstable and testing branches. Because it's additional work and complications. Apparently providing systemd functionality without systemd running is not a trivial undertaking, as the lag between systemd and systemd-shim releases shows. I could spend my time for open source development on a (technically) pointless (from my vantage point) split, but I prefer to improve systemd instead. Debian as a project already paid significant to support systemd as an alternative, when systemd version was held back for a year waiting for systemd-shim to catch up. This is certainly not the last time. [snip] I think exactly this kind of attitude is what triggers most of the polarity around systemd. Its like We don´t force systemd on anyone, but we provide as lots of functionality tightly coupled with it and if you do not implement it elsewhere, i.e. catch up, you need systemd anyway. While I believe it is *extra* work to separate functionality, I think it is *important* work. It would raise the acceptance of systemd, it would reduce the polarity it triggers. And it would make it more interoperable. Right now people are duplicating systemd stuff in several other areas. The reluctance to adopt systemd with certain distributions creates friction. Other implementations need to catch up and at any point in time may not be compatible. So, aside from it being additional work, is there any *solid* or even *unavoidable* technical reason to couple functionality that tightly? Wherever I look free software projects do great extra work to modularize and separate out functionality that can be separate. For a reason. See KDE community for example. They spend years of development work into separating things out into separate packages and have a clear ruling on what may depend on what. There are other examples for sure, OpenStack for example, while I do not yet know it in detail consists of a ton of separate packages in Debian. So or so… I think its this kind of attitude that triggers most of the polarity and split. Most of the modules in systemd do not depend on eachother. However, logind does depend on the cgroups dbus API of systemd (PID1). In the past logind interacted with the cgroups fs directly, but this had to be changed as the kernel is moving to a model where only one process may be in charge of cgroups. On systemd systems that one process is PID1 (why that is so has been discussed elsewhere so won't repeat that), so anything needing to deal with cgroups needs to go through the systemd API. I hope that explains why logind has to depend on systemd (or at least something implementing the systemd API). Thanks, Tom. As explained in another post – I didn´t read all the new answers… but it makes sense to do so – actually I feel uncomfortable about the new cgroup API. Its a kernel API. The Linux Kernel is a kernel supporting preemptive multitasking. Yet the new cgroup API requires or at least strongly recommends that only one process uses it. And… additionally to that that is a change that has been proposed by developers that to me oppinion are quite near or even working for systemd upstream. To me a single-process-usable API in the kernel seems broke. It may be hard to get the locking right… but still… I think the current cgroup API is still as broke as it can get. The unified hierarchy approach makes some sense to me, but requiring that only one process modifies it, instead of providing an API mutiple processes can use just seems plain broke to me. And I know, thats probably something to raise on LKML. And I may be inclined to do so. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, 21.10.14 11:08, Martin Steigerwald (mar...@lichtvoll.de) wrote: systemd as init, but logind has to depend on the system having cgroup support, and there's no equally good cgroup support available for inits other than systemd. It is possible to provide the relevant cgroup interfaces in or on top of another init, as the systemd-sysv + cgmanager combination attempts to do. But it is not trivial to do, as bugs and implementation delays with that combo have shown, and it's quite likely that there will be more problems in the future. It's not a particularly good idea to use the less-tested and less-reliable systemd-shim instead of the more reliable systemd. Thus the overall result is that yes, it does make sense to switch machines to systemd when you add certain functionality, even if that functionality does not appear to be directly tied to the init system at first glance. I can´t point my finger at it why… but I really feel uncomfortable with this tight coupling. I think that the systemd-shim + cgmanager combination may have bugs does not *prove* that such a think isn´t workable. Well, you can do tons of things, that simple fact doesn't really make all of them a good idea. PID1 is supposed to start and maintain services. In our eyes this is best done with cgroups, because that allows us to keep track of the service processes, label them, list them, kill them, get notifications about them. All this functionality is implicitly done by the kernel for us, we just need to make use of it, with a few mkdir()s and open()+write()s, awesome! That's why we use it. Now, of course you can split that out in multiple daemons, but then you have to do IPC between these daemons. That's already bad enough, for complexity and stability reasons. However, what's worse is that it creates a chicken and egg problem: if PID forks of a service like cgmanager in order to *manage* a service like cgmanager, then you have a cyclic dependency. You can of course hackishly work around this, but this would mean to exclude cgmanager from service supervision. And moreover: for what even? For executing a few mkdir()s and write()s out-of-process? Really? Hence: while these things are certainly possible I am strongly of the opinion that they would be a systematically bad design, and we will hence not do such a fuckup in systemd. Sorry. But due to the design choice of you systemd developers to have it all in one people who do believe that separating different functionality is for the long term benefit of interoperability and avoiding what I´d call vendor lock in, although I clearly see that systemd upstream community isn´t a single vendor as in one company who produces a comercial product. We are open source. There is no such thing as vendor lockin. You are just fudding around now. I really don't appreciate what you are writing here. This has been discussed a million times before. If you want to discuss this again then find another forum. In other areas where the Linux kernel requires user space helpers things initially have been separated. The whole do it all in once hald daemon was split into udev, libudev, udisks and upower… yet now, systemd and udev is in one upstream again. I think you misunderstand the history of hal really. What speaks against putting the cgroup functionality and other stuff from systemd into shared libraries with clearly defined APIs – which are documented and where the documentation is the reference, not the source code – and allowing it to be used elsewhere? See above. Our APIs are actually pretty well documented, in documentation, not source code. You seem to imply otherwise. What do you want more documentation for? Can you be more explicit please? Then systemd may use it as PID 1, but if someother wants to use it in own project, can use it as well. I consider cgroups as part of the kernel API and I highly dislike the battle on which of the available solutions will get control over it. Actually I still think the API is broke if it cannot allow for mutiple processes accessing it. I don´t know an easy way to fix it, but I think such a kind of API as kernel interface… anyone can read a file, mount a filesystem, open a network socket, set a nice value depending on permissions but when it comes to control groups it is down to one to rule them all. I can´t help it, but this just seems utterly broke to me. Well, if you think the cgroup interface is broken, please bring this up with the kernel folks not us. I can´t help it but I don´t consider this to be a sane operating system API. Maybe instead of criticising the kernel folks and us for technical choices you should really get your hands dirty and try to make it better? The issue with I should be able to stay with sysvinit because it worked fine for me is that keeping sysvinit working is COSTLY. The reason sysvinit used to mostly work was not that it would have been a
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am Dienstag, 21. Oktober 2014, 11:26:16 schrieben Sie: On Tue, Oct 21, 2014 at 11:08 AM, Martin Steigerwald mar...@lichtvoll.de wrote: Then systemd may use it as PID 1, but if someother wants to use it in own project, can use it as well. I consider cgroups as part of the kernel API and I highly dislike the battle on which of the available solutions will get control over it. Actually I still think the API is broke if it cannot allow for mutiple processes accessing it. I don´t know an easy way to fix it, but I think such a kind of API as kernel interface… anyone can read a file, mount a filesystem, open a network socket, set a nice value depending on permissions but when it comes to control groups it is down to one to rule them all. I can´t help it, but this just seems utterly broke to me. I can´t help it but I don´t consider this to be a sane operating system API. Note that the maintainers of the kernel-side cgroup API (primarily Tejun Heo, AFAIK) consider the current interface insane. In the future, the kernel will expect a single userspace process to control a single hierarchy. Systemd has already been adapted to provide this schema using the current API. See http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html Well I concur with that. I think the mutiple hierarchy API is inconsistent and insane. I see the point of having a unified hierarchy. But I never understand the requirement of one process controlling it and then having a battle over which process it will be. Whereever else we had something like this, it was tightly reduced to one functionality and available separate. Like udev, but still tightly coupled with the kernel and free to anyone to use – *just* this part of the functionality. Just like the Performance Events with the perf tools. Or iproute. Or you name it: Everyone providing one functionality. And… in its part being replacable. But with systemd it appears to be an all or nothing approach. I don´t only get control groups, but everything else… or else I need to duplicate the functionality myself. That just doesn´t make any sense to me. For udev I had the impression it was some quite approved part of the Linux kernel userspace utility. So while I think the old mutiple hierarchy API is broke, and heck I teached it in my Linux Performance analysis and tuning courses… I do think the new API is broke as well. Sometimes I think better ditch it all and redo it from scratch. Anyone can open a file, mount a fs, set a nice value, but only one process can do resource control of process groups via cgroups. This doesn´t make any sense to me. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, Oct 21, 2014 at 11:35 AM, Martin Steigerwald mar...@lichtvoll.de wrote: Am Dienstag, 21. Oktober 2014, 11:07:01 schrieben Sie: On Tue, Oct 21, 2014 at 10:53 AM, Martin Steigerwald mar...@lichtvoll.de wrote: Am Montag, 6. Oktober 2014, 21:53:04 schrieb Zbigniew Jędrzejewski-Szmek: Systemd-shim provides some functionality that systemd-sysv provides, and allows admins to use init systems other than systemd while still installing things like brasero. I think this is a great thing, except I wonder why the systemd project didn't separate this functionality from the init system in the first place. Systemd-shim is a duplication of effort. Not only that, but it must time its releases with the releases of systemd-sysv. That's no big deal for Debian's stable release, but it can be problematic in Debian's unstable and testing branches. Because it's additional work and complications. Apparently providing systemd functionality without systemd running is not a trivial undertaking, as the lag between systemd and systemd-shim releases shows. I could spend my time for open source development on a (technically) pointless (from my vantage point) split, but I prefer to improve systemd instead. Debian as a project already paid significant to support systemd as an alternative, when systemd version was held back for a year waiting for systemd-shim to catch up. This is certainly not the last time. [snip] I think exactly this kind of attitude is what triggers most of the polarity around systemd. Its like We don´t force systemd on anyone, but we provide as lots of functionality tightly coupled with it and if you do not implement it elsewhere, i.e. catch up, you need systemd anyway. While I believe it is *extra* work to separate functionality, I think it is *important* work. It would raise the acceptance of systemd, it would reduce the polarity it triggers. And it would make it more interoperable. Right now people are duplicating systemd stuff in several other areas. The reluctance to adopt systemd with certain distributions creates friction. Other implementations need to catch up and at any point in time may not be compatible. So, aside from it being additional work, is there any *solid* or even *unavoidable* technical reason to couple functionality that tightly? Wherever I look free software projects do great extra work to modularize and separate out functionality that can be separate. For a reason. See KDE community for example. They spend years of development work into separating things out into separate packages and have a clear ruling on what may depend on what. There are other examples for sure, OpenStack for example, while I do not yet know it in detail consists of a ton of separate packages in Debian. So or so… I think its this kind of attitude that triggers most of the polarity and split. Most of the modules in systemd do not depend on eachother. However, logind does depend on the cgroups dbus API of systemd (PID1). In the past logind interacted with the cgroups fs directly, but this had to be changed as the kernel is moving to a model where only one process may be in charge of cgroups. On systemd systems that one process is PID1 (why that is so has been discussed elsewhere so won't repeat that), so anything needing to deal with cgroups needs to go through the systemd API. I hope that explains why logind has to depend on systemd (or at least something implementing the systemd API). Thanks, Tom. As explained in another post – I didn´t read all the new answers… but it makes sense to do so – actually I feel uncomfortable about the new cgroup API. Its a kernel API. The Linux Kernel is a kernel supporting preemptive multitasking. Yet the new cgroup API requires or at least strongly recommends that only one process uses it. And… additionally to that that is a change that has been proposed by developers that to me oppinion are quite near or even working for systemd upstream. To me a single-process-usable API in the kernel seems broke. It may be hard to get the locking right… but still… I think the current cgroup API is still as broke as it can get. The unified hierarchy approach makes some sense to me, but requiring that only one process modifies it, instead of providing an API mutiple processes can use just seems plain broke to me. And I know, thats probably something to raise on LKML. And I may be inclined to do so. The systemd project does not have much (any?) influence over what interfaces the kernel provides, so I suggest you take your concerns up with them. That said, you will likely get further with technical arguments, and preferably an alternate implementation, than just claiming you have a bad feeling. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am Dienstag, 21. Oktober 2014, 11:21:36 schrieb Lennart Poettering: On Tue, 21.10.14 10:53, Martin Steigerwald (mar...@lichtvoll.de) wrote: So, aside from it being additional work, is there any *solid* or even *unavoidable* technical reason to couple functionality that tightly? Yes, there always is. For logind for example we need to be able to group the processes of a session, so that we can keep track of them, list them, kill them, get notifications about them, and so on. For that we need the scope concept of PID1. That's why logind talks to PID 1. You know, it really annoys me if you imply that we just made these choices because we are assholes. We use the APIs we use because we need their technical functionality. It's that simple. It would be great if you'd grant us the benefit of the doubt at least, instead of implying anything else. Lennart, I didn´t imply that, and I didn´t say that. Wherever I look free software projects do great extra work to modularize and separate out functionality that can be separate. For a reason. See KDE community for example. They spend years of development work into separating things out into separate packages and have a clear ruling on what may depend on what. There are other examples for sure, OpenStack for example, while I do not yet know it in detail consists of a ton of separate packages in Debian. Well, we are not KDE, and not OpenStack. We provide a basic toolbox to build an OS from. Compare us with Busybox if you must. I don't hear you complaining about busybox all the time! Lennart, I get the impression you feel being accused. Yet I tried honestly to keep my mails to be polite and respectful. I tried to discuss about systemd and attitudes, not about persons. Busybox is highly more optional than systemd. I can use bash and coreutils, or mksh and BSD commands or whatnot. So or so… I think its this kind of attitude that triggers most of the polarity and split. Well, our priority is to solve technical problems in a way we perceive elegant and minimal. Your priority appears to be appeasing people who prefer religious reasoning over technical reasoning. I am pretty sure you cannot appease those, and we will not compromise our technical necessesities for that. Anyway, can we please end this discussion on this ML please? Please continue this somewhere else, this ML is really for technical discussions. Sorry, Well… actually I tried to discuss the concerns I and others have openly. I went through the hassle to provide the feedback where it matters… upstream… instead of joining the flamefests elsewhere or calling you names… … but it seems to me you are so sensitive to feedback that I don´t have the impression you even relate to the concerns I voiced here, which in part is a summary of the part of concerns I read elsewhere I see as being founded. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, 21.10.14 11:47, Martin Steigerwald (mar...@lichtvoll.de) wrote: So or so… I think its this kind of attitude that triggers most of the polarity and split. Well, our priority is to solve technical problems in a way we perceive elegant and minimal. Your priority appears to be appeasing people who prefer religious reasoning over technical reasoning. I am pretty sure you cannot appease those, and we will not compromise our technical necessesities for that. Anyway, can we please end this discussion on this ML please? Please continue this somewhere else, this ML is really for technical discussions. Sorry, Well… actually I tried to discuss the concerns I and others have openly. I went through the hassle to provide the feedback where it matters… upstream… instead of joining the flamefests elsewhere or calling you names… … but it seems to me you are so sensitive to feedback that I don´t have the impression you even relate to the concerns I voiced here, which in part is a summary of the part of concerns I read elsewhere I see as being founded. We are always interested in technical feedback. We are not very interested in FUD mails that tell us how we'd force people, how we'd behave like microsoft and so on. That's not useful, that's pretty much only hurtful. Sorry, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am Dienstag, 21. Oktober 2014, 11:52:50 schrieb Lennart Poettering: When Microsoft back then did something like this it was called Embrace, Extend and Extinguish¹… Oh come on. You are just being a dick now. For now just this: Thats a personal accusation. I didn´t attack you personally. Please refrain from attacking me personally. Thats not the way of discussing I am willing to lower my communication into. I shared my thoughts and observations… thats all. To me what I perceive has similarities regarding the outcome. I didn´t say that it was your intention to create this. I specifically wrote: I don´t think this was your plan. But… when looking at the currently visible outcome this is quite exactly what is happening here. So I didn´t say anything about your intention. And how could I? I don´t know them. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am Dienstag, 21. Oktober 2014, 11:59:09 schrieb Lennart Poettering: On Tue, 21.10.14 11:47, Martin Steigerwald (mar...@lichtvoll.de) wrote: So or so… I think its this kind of attitude that triggers most of the polarity and split. Well, our priority is to solve technical problems in a way we perceive elegant and minimal. Your priority appears to be appeasing people who prefer religious reasoning over technical reasoning. I am pretty sure you cannot appease those, and we will not compromise our technical necessesities for that. Anyway, can we please end this discussion on this ML please? Please continue this somewhere else, this ML is really for technical discussions. Sorry, Well… actually I tried to discuss the concerns I and others have openly. I went through the hassle to provide the feedback where it matters… upstream… instead of joining the flamefests elsewhere or calling you names… … but it seems to me you are so sensitive to feedback that I don´t have the impression you even relate to the concerns I voiced here, which in part is a summary of the part of concerns I read elsewhere I see as being founded. We are always interested in technical feedback. We are not very interested in FUD mails that tell us how we'd force people, how we'd behave like microsoft and so on. That's not useful, that's pretty much only hurtful. Sorry, I didn´t intend to hurt you. I am sorry if you used what I wrote to hurt yourself. I just compared regarding the outcome. And to me there are similarities regarding the outcome. I never said you intended this. I never said you behaved intently in this way. That is *where* I differ from any of the personal accusation stuff. I am not assuming bad intent. Not at all. But I see similarities in the outcome. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Martin Steigerwald wrote on 21/10/14 10:25: Am Mittwoch, 8. Oktober 2014, 10:54:00 schrieb Lennart Poettering: On Tue, 07.10.14 23:40, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote: My question really isn't why are the Debian dependencies the way they are. I understand that. I was trying to highlight the strange situation of a desktop application requiring a particular init system. I *think* this is a result of the init portion of systemd being bundled together with the logind portion of systemd. To me (unfamiliar with the systemd code) those two functions seem distinct enough to merit being separate. Debian can't easily separate what the systemd devs have developed as a single binary, so we end up with these strange dependency chains. Single binary is false of course. Logind is developed as a separate program, which is why systemd-shim is possible at all. AFAIK the actual relevant dependencies go as follows: First, there's a good reason why logind requires cgroup functionality. And there's a good reason why cgroup functionality is best implemented together with init (see http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ for more info). So it's not quite directly logind has to depend on systemd as init, but logind has to depend on the system having cgroup support, and there's no equally good cgroup support available for inits other than systemd. It is possible to provide the relevant cgroup interfaces in or on top of another init, as the systemd-sysv + cgmanager combination attempts to do. But it is not trivial to do, as bugs and implementation delays with that combo have shown, and it's quite likely that there will be more problems in the future. It's not a particularly good idea to use the less-tested and less-reliable systemd-shim instead of the more reliable systemd. Thus the overall result is that yes, it does make sense to switch machines to systemd when you add certain functionality, even if that functionality does not appear to be directly tied to the init system at first glance. Also note that the systemd concepts logind makes use of are also exported in its own API. The scopes and slices that logind uses are exposed on its bus objects, and they are used by tools like loginctl to do their work. The scopes and slices concept does not exist elsewhere, and there's nothing comparable around, so even if we wanted we couldn't make logind work on anything else. Then why in the first hand are the scopes and slices concepts within systemd *tightly* coupled when it is functionality that makes sense to be utilitizes in a component that provides a different functionality. I wonder what functionality systemd provides right now in one more or less tightly coupled package: - early boot process PID 1 - managing kernel drivers and device files (via coupled udev) Not PID 1 - resource control for process groups PID 1. - logging Not PID 1 - core dumping Not PID 1 - network while I think a distro-unified way to approaching network that replaces the current distro specific ways like ifupdown and so on, why does it have to be coupled with systemd? Not PID 1 - cron, although that at least in Debian is separate as systemd-cron Partly PID 1 Thats rather much. Really rather much. Way more than traditonal sysvinit covered. This is because traditional sysvinit covered PID 1 and performing it's job (if you consider e.g. killall5 and friends). You seem to be conflating systemd as PID 1 and systemd as a project. These are two completely different things. There are many related things here and a lot of the sub components obviously use a lot of the same functionality and utility functions. This is achieved via a shared library with a private API. The only reason that all these separate parts are developed as part of the systemd project is that it's *easier*. It's just the easiest way to develop. An alternative would be to make the utility functions API stable and export the shared library publicly and give API guarantees, but that puts a lot of pressure and it's a difficult thing to provide and it has long term maintenance overhead. This is something that *costs*. It costs in time/man hours and therefore it carries real overheads. Doing this for the convenience of splitting things out is simply not worth it - especially so as the main people working on these things are the same people. It also increases the test matrix. If logind v300 has to work with libsystemd v300 and all future versions then the testing side of things increases in complexity *massively*. Again this causes problems that translate to time and effort of developers that could better be allocated to building a better overall set of building blocks. The other option would be to just split out the git repos but keep the API a private one - with releases still in lockstep. This is ultimately
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Colin, I had the feeling that is a bad idea to read your mail before I go to sleep. But I was interested in what you have to say since you made quite an effort in your reply to me. And now I can´t sleep since my head if full of thoughts and I am full of emotions as well. With that I perceive starts an answer on a technical matter ends with what I received as a dire personal attack: I.e. calling me names. I received this twice on this mailing list. Once from Lennart (being a dick now) and now from you calling me a troll. I will make an effort to reply to your mail and then most likely unsubscribe, cause for me I feel like being in an hostile environment. Am Dienstag, 21. Oktober 2014, 22:14:48 schrieb Colin Guthrie: Martin Steigerwald wrote on 21/10/14 10:25: Am Mittwoch, 8. Oktober 2014, 10:54:00 schrieb Lennart Poettering: On Tue, 07.10.14 23:40, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote: My question really isn't why are the Debian dependencies the way they are. I understand that. I was trying to highlight the strange situation of a desktop application requiring a particular init system. I *think* this is a result of the init portion of systemd being bundled together with the logind portion of systemd. To me (unfamiliar with the systemd code) those two functions seem distinct enough to merit being separate. Debian can't easily separate what the systemd devs have developed as a single binary, so we end up with these strange dependency chains. Single binary is false of course. Logind is developed as a separate program, which is why systemd-shim is possible at all. AFAIK the actual relevant dependencies go as follows: First, there's a good reason why logind requires cgroup functionality. And there's a good reason why cgroup functionality is best implemented together with init (see http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ for more info). So it's not quite directly logind has to depend on systemd as init, but logind has to depend on the system having cgroup support, and there's no equally good cgroup support available for inits other than systemd. It is possible to provide the relevant cgroup interfaces in or on top of another init, as the systemd-sysv + cgmanager combination attempts to do. But it is not trivial to do, as bugs and implementation delays with that combo have shown, and it's quite likely that there will be more problems in the future. It's not a particularly good idea to use the less-tested and less-reliable systemd-shim instead of the more reliable systemd. Thus the overall result is that yes, it does make sense to switch machines to systemd when you add certain functionality, even if that functionality does not appear to be directly tied to the init system at first glance. Also note that the systemd concepts logind makes use of are also exported in its own API. The scopes and slices that logind uses are exposed on its bus objects, and they are used by tools like loginctl to do their work. The scopes and slices concept does not exist elsewhere, and there's nothing comparable around, so even if we wanted we couldn't make logind work on anything else. Then why in the first hand are the scopes and slices concepts within systemd *tightly* coupled when it is functionality that makes sense to be utilitizes in a component that provides a different functionality. I wonder what functionality systemd provides right now in one more or less tightly coupled package: - early boot process PID 1 - managing kernel drivers and device files (via coupled udev) Not PID 1 - resource control for process groups PID 1. - logging Not PID 1 - core dumping Not PID 1 - network while I think a distro-unified way to approaching network that replaces the current distro specific ways like ifupdown and so on, why does it have to be coupled with systemd? Not PID 1 - cron, although that at least in Debian is separate as systemd-cron Partly PID 1 Thats rather much. Really rather much. Way more than traditonal sysvinit covered. This is because traditional sysvinit covered PID 1 and performing it's job (if you consider e.g. killall5 and friends). You seem to be conflating systemd as PID 1 and systemd as a project. These are two completely different things. No. I am concerned about both. The functionality that is stuffed inside PID 1 which is more than 1,3 MiB and also sports user session functionality. And what is coupled inside on project, more or less tight. There are many related things here and a lot of the sub components obviously use a lot of the same functionality and utility functions. This is achieved via a shared library with a private API. The only reason that all these separate parts are developed as part of the systemd project is
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Wed, 2014-10-22 at 02:13 +0200, Martin Steigerwald wrote: With that I perceive starts an answer on a technical matter ends with what I received as a dire personal attack: I.e. calling me names. I think it was a mostly justified criticism of your posting style here. I will make an effort to reply to your mail and then most likely unsubscribe, cause for me I feel like being in an hostile environment. If you post such strongly worded criticism of people's work (which I don't consider really justified criticism either) then IMO you should tolerate that level negative response without starting to complain about hostile environment. Upstream systemd has a very high development speed. Which you may view as good. And heck, yes, it has its advantages I agree. But to me it also seems that this speed partly come due to what you wrote above as the easy way of developing things. And that easy way to develop things, I argue now, makes it more difficult for people wanting to port to different platforms, people only wanting a subset of systemd and people who want to adapt systemd. Those latter are much smaller groups than the number of people who just need a well-working init system for their Linux machine. It wouldn't make sense to sacrifice the functionality of init just to make porting easier. systemd provides more and more functionality that desktops like to use, that other tools like to use. When Microsoft back then did something like this it was called Embrace, Extend and Extinguish¹… Really… it matches quite closely. Oh come on! This is just an attack and FUD. You make repeated claims of coming in good faith etc. and seem to dismiss any technical defence being made with vague references and then you bring out a aggressive and argumentative statement like the above. That is the impression you get. I think I replied to technical arguments as well. The above does not match the definition of Embrace, extend and extinguish (see for example the Wikipedia definition at http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish ). It's a lot more specific than just a product manager to push competing ones out of the market, and pretty much requires intentional malice to apply. IMO it was quite accurate to call your claim attack/FUD. What I tried to achieve is to describe and interpret what I see regarding the state of systemd as I understand it now, and granted my understanding may not be complete, sure, and also describe and interpret behavior I have seen. And also summarize some of this from the feedback I read elsewhere. What I didn´t try to achieve was attacking persons. Yet, I interpret your reaction to me as if I attacked you. So I am obviously not producing the outcome I wanted to produce. And thats one reason why I think I will stop doing what I am doing after this mail and unsubscribe from this list for a while. Actually I think I made my point. I tried to channel some of the dire concerns and uproar and polarity and split tendencies upstream. I see this happening to my beloved distribution Debian and I am not happy about it. The systemd debates and polarity within Debian I consider as being harmful. And it was my intention to address some of this upstream in order to discuss what can be done to first *understand* why it triggers this polarity and what can be done to address this. Maybe your *intention* was to address reasons for controversy in a constructive manner, but I do not think you succeeded very well. Several of your points had already been made by others before - many, many times. You bring up little that systemd authors would not have already addressed before. Things like your Embrace, extend and extinguish comparison above are attacks with little constructive content. And when presented with technical justification to develop certain things in the same project, or keep certain functionality in PID 1, you seem to largely ignore it. Yes, it is a tradeoff, and you can always find some negative side. But you won't achieve anything by ignoring the answers and talking about the negative sides, if you can't make a better argument why the tradeoff would be wrong overall. Of course this criticism is listened to and often actions are taken because of it, but what do you expect the outcome to be? Do you expect all the repos to be split up? Stable APIs exported and supported? What outcome do you actually *want* here? You seem to be doing lots of complaining, but very little in the actual suggesting what could be done different that has not already been addressed technically. You may disagree about that end decision but that's just the way it is sometimes? The people doing the work ultimately get to make the decisions. Yeah, thats the do-ocracy aspect of things. Still if what I do again and again and again triggers much of polarity and resistance, I´d ask myself whats going
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
The system project seems to have made great strides to the point that now there are definite philosophical differences. The people on both sides have their own opinions of what the direction should be given how much progress has occurred. I think this would a very good time for a fork of the project. The systemd developers have rightly pointed out that this is free ware and if there is disagreement as has happened in the past, fork the project. The people who disagree with the current direction have a solid base to build on, fork the project take it in the direction you feel it should go. It will be interesting to see how the two sides progress. -Original Message- From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On Behalf Of Martin Steigerwald Sent: Tuesday, October 21, 2014 7:13 PM To: Colin Guthrie Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance Colin, I had the feeling that is a bad idea to read your mail before I go to sleep. But I was interested in what you have to say since you made quite an effort in your reply to me. And now I can´t sleep since my head if full of thoughts and I am full of emotions as well. With that I perceive starts an answer on a technical matter ends with what I received as a dire personal attack: I.e. calling me names. I received this twice on this mailing list. Once from Lennart (being a dick now) and now from you calling me a troll. I will make an effort to reply to your mail and then most likely unsubscribe, cause for me I feel like being in an hostile environment. Am Dienstag, 21. Oktober 2014, 22:14:48 schrieb Colin Guthrie: Martin Steigerwald wrote on 21/10/14 10:25: Am Mittwoch, 8. Oktober 2014, 10:54:00 schrieb Lennart Poettering: On Tue, 07.10.14 23:40, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote: My question really isn't why are the Debian dependencies the way they are. I understand that. I was trying to highlight the strange situation of a desktop application requiring a particular init system. I *think* this is a result of the init portion of systemd being bundled together with the logind portion of systemd. To me (unfamiliar with the systemd code) those two functions seem distinct enough to merit being separate. Debian can't easily separate what the systemd devs have developed as a single binary, so we end up with these strange dependency chains. Single binary is false of course. Logind is developed as a separate program, which is why systemd-shim is possible at all. AFAIK the actual relevant dependencies go as follows: First, there's a good reason why logind requires cgroup functionality. And there's a good reason why cgroup functionality is best implemented together with init (see http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInter face/ for more info). So it's not quite directly logind has to depend on systemd as init, but logind has to depend on the system having cgroup support, and there's no equally good cgroup support available for inits other than systemd. It is possible to provide the relevant cgroup interfaces in or on top of another init, as the systemd-sysv + cgmanager combination attempts to do. But it is not trivial to do, as bugs and implementation delays with that combo have shown, and it's quite likely that there will be more problems in the future. It's not a particularly good idea to use the less-tested and less-reliable systemd-shim instead of the more reliable systemd. Thus the overall result is that yes, it does make sense to switch machines to systemd when you add certain functionality, even if that functionality does not appear to be directly tied to the init system at first glance. Also note that the systemd concepts logind makes use of are also exported in its own API. The scopes and slices that logind uses are exposed on its bus objects, and they are used by tools like loginctl to do their work. The scopes and slices concept does not exist elsewhere, and there's nothing comparable around, so even if we wanted we couldn't make logind work on anything else. Then why in the first hand are the scopes and slices concepts within systemd *tightly* coupled when it is functionality that makes sense to be utilitizes in a component that provides a different functionality. I wonder what functionality systemd provides right now in one more or less tightly coupled package: - early boot process PID 1 - managing kernel drivers and device files (via coupled udev) Not PID 1 - resource control for process groups PID 1. - logging Not PID 1 - core dumping Not PID 1 - network while I think a distro-unified way to approaching network that replaces the current
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, 07.10.14 23:40, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote: My question really isn't why are the Debian dependencies the way they are. I understand that. I was trying to highlight the strange situation of a desktop application requiring a particular init system. I *think* this is a result of the init portion of systemd being bundled together with the logind portion of systemd. To me (unfamiliar with the systemd code) those two functions seem distinct enough to merit being separate. Debian can't easily separate what the systemd devs have developed as a single binary, so we end up with these strange dependency chains. Single binary is false of course. Logind is developed as a separate program, which is why systemd-shim is possible at all. AFAIK the actual relevant dependencies go as follows: First, there's a good reason why logind requires cgroup functionality. And there's a good reason why cgroup functionality is best implemented together with init (see http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ for more info). So it's not quite directly logind has to depend on systemd as init, but logind has to depend on the system having cgroup support, and there's no equally good cgroup support available for inits other than systemd. It is possible to provide the relevant cgroup interfaces in or on top of another init, as the systemd-sysv + cgmanager combination attempts to do. But it is not trivial to do, as bugs and implementation delays with that combo have shown, and it's quite likely that there will be more problems in the future. It's not a particularly good idea to use the less-tested and less-reliable systemd-shim instead of the more reliable systemd. Thus the overall result is that yes, it does make sense to switch machines to systemd when you add certain functionality, even if that functionality does not appear to be directly tied to the init system at first glance. Also note that the systemd concepts logind makes use of are also exported in its own API. The scopes and slices that logind uses are exposed on its bus objects, and they are used by tools like loginctl to do their work. The scopes and slices concept does not exist elsewhere, and there's nothing comparable around, so even if we wanted we couldn't make logind work on anything else. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
- Original Message - From: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl On Mon, Oct 06, 2014 at 02:56:22PM -0400, Rob Owens wrote: On Debian, I came across an unusual dependency. Installing a cd burner (brasero) required me to change my init system to systemd. Sounds kind of ridiculous, I think. The dependency chain went like this: brasero - gvfs - gvfs-daemons - udisks2 - libpam-systemd - systemd-sysv I don't know enough about this stuff to comment very intelligently, which is why I haven't said anything up until now. But my research shows that each of these dependencies is indeed valid in the sense that each dependency represents some real requirement for functionality. The issue, I think, is that some of these packages provide very broad functionality. As I put it in a Debian bug report: Brasero needs X functionality, which can be found in package W. Package W also provides Y functionality, which depends on systemd-sysv. So therefore brasero depends on systemd-sysv, even though it doesn't *need* it. I gather that this has something to do with logind and/or cgroups. I can appreciate the benefits (on some systems) of giving only the local user access to removable media. But I don't understand why this functionality requires the use of systemd-sysv (the init system), particularly if my understanding is correct that this functionality used to be separate from the init portion of systemd. I'll assume that this is a serious question, despite being rather elementary... My question really isn't why are the Debian dependencies the way they are. I understand that. I was trying to highlight the strange situation of a desktop application requiring a particular init system. I *think* this is a result of the init portion of systemd being bundled together with the logind portion of systemd. To me (unfamiliar with the systemd code) those two functions seem distinct enough to merit being separate. Debian can't easily separate what the systemd devs have developed as a single binary, so we end up with these strange dependency chains. I am trying to demonstrate the drawbacks of the decision to combine logind with the init portion of systemd. I'm giving you an outsider's point of view. I realize that most of the folks on this list probably love all of systemd and couldn't imagine why anyone would want to have just bits and pieces of it. But I think my previous email gave some good reasons. If not, let me know and I'll try to be more clear about it. The second option requires someone to step up and provide an alternative implementation. So far, systemd-shim is one candidate, but it took months to appear and still has occasional problems. (I don't follow the situation quite closely, but Michael seems to find serious bugs with very light testing). At some point, systemd-shim might become a viable replacement. This work should be done by people who want the alternatives, not the maintainers of systemd, who happily use the existing stack. So if the alternatives are not in the shape you would like them to be, inquire with the maintainers of the said alternatives. But even assuming that an alternative is functional, using it is not without costs for the maintainers of dependent packages. Let's say that we have some systems with systemd, some with systemd-shim. It is likely that a bug report for udisk2 might require the maintainer to ask which of the alternatives is used. For such basic functionality that influences the whole OS, if the maintainer uses a different init, it is like being on a different architecture. It makes things hard to debug, hard to test, and greatly distracts from the time the maintainer has available to really fix bugs. It is not free, and diminishes the appeal of the whole distribution. It might be that this alternative dependency has advantages which outweigh this cost. I think everything you said in these two paragraphs could be used to support the argument of keeping logind separate from init. Then everybody would be using your logind code, and there would be no need for systemd-shim. There still would be the issue for package maintainers of supporting multiple init systems, but that's Debian's decision to do so. But seriously, is SysV init that great? I never thought much about my init system until recently. I never really had any complaints with SysV init, although I do recognize that systemd provides real improvements for some use cases. So for me as a sysadmin the wisest thing to do is stick with what I already know, as long as it's working well enough (and for me, it is). Systemd-shim provides some functionality that systemd-sysv provides, and allows admins to use init systems other than systemd while still installing things like brasero. I think this is a great thing, except I wonder why the systemd project didn't separate this functionality
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote: My question really isn't why are the Debian dependencies the way they are. I understand that. I was trying to highlight the strange situation of a desktop application requiring a particular init system. I *think* this is a result of the init portion of systemd being bundled together with the logind portion of systemd. To me (unfamiliar with the systemd code) those two functions seem distinct enough to merit being separate. Debian can't easily separate what the systemd devs have developed as a single binary, so we end up with these strange dependency chains. Single binary is false of course. Logind is developed as a separate program, which is why systemd-shim is possible at all. AFAIK the actual relevant dependencies go as follows: First, there's a good reason why logind requires cgroup functionality. And there's a good reason why cgroup functionality is best implemented together with init (see http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ for more info). So it's not quite directly logind has to depend on systemd as init, but logind has to depend on the system having cgroup support, and there's no equally good cgroup support available for inits other than systemd. It is possible to provide the relevant cgroup interfaces in or on top of another init, as the systemd-sysv + cgmanager combination attempts to do. But it is not trivial to do, as bugs and implementation delays with that combo have shown, and it's quite likely that there will be more problems in the future. It's not a particularly good idea to use the less-tested and less-reliable systemd-shim instead of the more reliable systemd. Thus the overall result is that yes, it does make sense to switch machines to systemd when you add certain functionality, even if that functionality does not appear to be directly tied to the init system at first glance. I never thought much about my init system until recently. I never really had any complaints with SysV init, although I do recognize that systemd provides real improvements for some use cases. So for me as a sysadmin the wisest thing to do is stick with what I already know, as long as it's working well enough (and for me, it is). The issue with I should be able to stay with sysvinit because it worked fine for me is that keeping sysvinit working is COSTLY. The reason sysvinit used to mostly work was not that it would have been a reliable system - it mostly worked because people kept using a lot of effort to work around and paper over various issues that kept popping up. And there's no justification to keep up that effort for the minority who wants to stay with sysvinit. So, you can keep running your old systems unchanged if you want, but you shouldn't expect to be able to upgrade them or install new software without switching to systemd. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Sun, 05.10.14 12:20, Martin Steigerwald (mar...@lichtvoll.de) wrote: However, I also believe that the change we are making is for the good, and even though it might not be obvious to many immediately, it brings major benefits when administering machines, and they massively outweigh the disadvantage of changing things. And apparently I am not entirely alone with this, as the folks who make technical decision for the various distributions ended up deciding in favour of systemd in most cases. Why do you believe so? What key points make you believe so? Believe what precisely? Why I believe systemd is better than sysvinit? Well, that's a big question, and I am pretty sure already well enough discussed elsewhere, that we really do't have to repeat this here. Here the feedback I read over and over again is that you and RedHat basically forced the systemd decision onto other distributions. While I do not see how you actually can be powerful enough to do that, as we live in a free will zone. I do see tendencies that more and more stuff *depends* on systemd cause it needs features only available there. Well, we provide good APIs. We provide them for a reason, because applications benefit from them. App developers see that, so they adopt them. That's pretty natural and obvious, no? If you want to know more, about why they do that, then ask them. What I find so puzzling about certain aspects of the criticism is that some people apparently assume that logind and similar things were entirely redundant, and that the APIs that it provides were so redundant, that one could trivially write the same app, but not make use of them... This idea that logind had exactly no merits, and was little more than just an evil tool to drive systemd adoption... Dependencies like this actually create some force to adopt systemd. Well, I certainly don't force anybody. We provide APIs for technical reasons, and because we believe that people might benefit from them, even need them. And apparently I am not too wrong with that, after all they tend to adopt them... Now I know ConsoleKit isn´t developed anymore, but also I never got why a logind implementation needs to depend on systemd base package in such a way that at least in Debian systemd package has to be installed if someone wants to use GNOME. Well, logind talks to systemd to manage user sessions and user processes in cgroups. That's why it depends on systemd. And since only systemd implements that, we couldn't even support anything else even if we wanted. Our intention with systemd is to provide a strong platform. One platform. If people want to use our code in other contexts, then that's totally fine, but please understand that I am not going to do any work for that, I am not going to maintain it, and I don't want to see that in my code. Much of the feedback is related to that. Many would appreciate something like systemd if it just did *services* stuff. That is also what seemed to have motivated the dev behind the use less d fork. Well, I am sorry, but systemd is more than that. If systemd is no what people want, they can roll their own thing, can continue to use sysvinit, or even fork systemd, That's completely OK. But for what we have in mind for systemd it's definitely a goal to make Linux more attractive for developers, by providing a good set of core OS APIs that people can just make use of, instead of a zoo of things that are combined in wild combinations. The current increase noised level around systemd adoption I attribute to three things: the fact that RHEL7 is out now, the fact that due to the adoption of systemd as default by Debian and Ubuntu the folks who ignored the discussion so far now are faced with this change, and also to a big part to certain columnists who in the interest of generating traffic to their sites try to create a hubbub out of very little. Anyway, long story short: we knew what we did, and yeah, I read feedback, even if it is written in a hateful style, and we learn from it. Well, I for myself have been concerned and surprised by *such an mount* of uproar. Not even GNOME 3 triggered anywhere near that amount of threads and mails. Well, I am not sure this is really that way. GNOME 3 noise was pretty bad too, maybe you just weren't involved so closely... But even if it wasn't, our stuff touches most of the Linux community, which is larger than the GNOME community. And I worry regarding various attempts to replace systemd functionality (by systembsd services) and by use less d or using different inits. I think quite some of them are based on solid technical arguments. I wonder whether systemd might be missing out on something here. Well, some competition would be great. I am pretty sure that uselessd is not based on solid technical arguments though, and pretty sure it's maintainer will figure that out pretty soon too... Anyway, more power to him, at least he
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, Oct 06, 2014 at 02:57:17PM +0200, Lennart Poettering wrote: systemd does a lot. And an 1,3 MiB binary is a hug binary size for something that started out as managing services and sessions via control cgroups. Well, it does a lot more these days. The Linux kernel also started out pretty small too. Nowadays it does a lot more, which makes it so unversially applicable. I figure systemd goes a similar path. (Though hopefully will never grow as massive, complex and monolithic as the kernel...) This is an interesting question, where this 1.3 MB comes from. objdump -t ./systemd|sed -r -n 's/([0-9a-z]+).*(\.text|\.data\.[a-z.]*|\.rodata\.[a-z.]*)[ \t]*([0-9a-z]+)[ \t]*(\.hidden[ \t]+|)(.*)/\3 \5 -- \2/p'|sort|tail 0a13 service_deserialize_item -- .text 0a6e cgroup_context_apply -- .text 0ae2 socket_apply_socket_options -- .text 0b00 rtnl_types -- .data.rel.ro.local 0b32 exec_context_dump -- .text 0d50 bus_exec_vtable -- .data.rel.ro 0d62 transaction_add_job_and_dependencies -- .text 0e40 bus_unit_vtable -- .data.rel.ro 11d7 bus_cgroup_set_property -- .text 1410 bus_manager_vtable -- .data.rel.ro 1453 exec_child -- .text 1470 wordlist.7848 -- .data.rel.ro.local 2b90 main -- .text e1c0 wordlist.14097 -- .data.rel.ro wordlist.14097 is a generated table for all configuration options in load-fragment-gperf.c. wordlist.7848 is for errno_from_name (5k for this is a bit of a stretch though). There's pretty complex code (main is 11k), combined with a large number of configuration and reporting code (the wordlists, vtables, exec_context_dump). This shows that splitting the binary into two would not be really effective: this code would essentially have to be duplicated, once for communication between PID 1 and the helper, and second time for communication between the helpers and the rest, i.e. the existing code. -- I think this hasn't been mentioned in this thread, but PID1 is shrinking at least a bit, because a bunch of things which used to be implemented in PID1 have been outsourced to generators. ./systemd-sysv-generator, ./systemd-fstab-generator are relatively recent and significant. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, 06.10.14 16:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Mon, Oct 06, 2014 at 02:57:17PM +0200, Lennart Poettering wrote: systemd does a lot. And an 1,3 MiB binary is a hug binary size for something that started out as managing services and sessions via control cgroups. Well, it does a lot more these days. The Linux kernel also started out pretty small too. Nowadays it does a lot more, which makes it so unversially applicable. I figure systemd goes a similar path. (Though hopefully will never grow as massive, complex and monolithic as the kernel...) This is an interesting question, where this 1.3 MB comes from. objdump -t ./systemd|sed -r -n 's/([0-9a-z]+).*(\.text|\.data\.[a-z.]*|\.rodata\.[a-z.]*)[ \t]*([0-9a-z]+)[ \t]*(\.hidden[ \t]+|)(.*)/\3 \5 -- \2/p'|sort|tail 0a13 service_deserialize_item -- .text 0a6e cgroup_context_apply -- .text 0ae2 socket_apply_socket_options -- .text 0b00 rtnl_types -- .data.rel.ro.local 0b32 exec_context_dump -- .text 0d50 bus_exec_vtable -- .data.rel.ro 0d62 transaction_add_job_and_dependencies -- .text 0e40 bus_unit_vtable -- .data.rel.ro 11d7 bus_cgroup_set_property -- .text 1410 bus_manager_vtable -- .data.rel.ro 1453 exec_child -- .text 1470 wordlist.7848 -- .data.rel.ro.local 2b90 main -- .text e1c0 wordlist.14097 -- .data.rel.ro wordlist.14097 is a generated table for all configuration options in load-fragment-gperf.c. wordlist.7848 is for errno_from_name (5k for this is a bit of a stretch though). I wonder if any of these tables might have holes in them? i.e. some enums skip a few numbers in the middle, and are thus not really appropriate for the usual DEFINE_STRING_TABLE() stuff we do? I think this hasn't been mentioned in this thread, but PID1 is shrinking at least a bit, because a bunch of things which used to be implemented in PID1 have been outsourced to generators. ./systemd-sysv-generator, ./systemd-fstab-generator are relatively recent and significant. And I'd be willing to split out more, but I am not sure currently what could be a good candidate. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, Oct 06, 2014 at 05:14:17PM +0200, Lennart Poettering wrote: On Mon, 06.10.14 16:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Mon, Oct 06, 2014 at 02:57:17PM +0200, Lennart Poettering wrote: systemd does a lot. And an 1,3 MiB binary is a hug binary size for something that started out as managing services and sessions via control cgroups. Well, it does a lot more these days. The Linux kernel also started out pretty small too. Nowadays it does a lot more, which makes it so unversially applicable. I figure systemd goes a similar path. (Though hopefully will never grow as massive, complex and monolithic as the kernel...) This is an interesting question, where this 1.3 MB comes from. objdump -t ./systemd|sed -r -n 's/([0-9a-z]+).*(\.text|\.data\.[a-z.]*|\.rodata\.[a-z.]*)[ \t]*([0-9a-z]+)[ \t]*(\.hidden[ \t]+|)(.*)/\3 \5 -- \2/p'|sort|tail 0a13 service_deserialize_item -- .text 0a6e cgroup_context_apply -- .text 0ae2 socket_apply_socket_options -- .text 0b00 rtnl_types -- .data.rel.ro.local 0b32 exec_context_dump -- .text 0d50 bus_exec_vtable -- .data.rel.ro 0d62 transaction_add_job_and_dependencies -- .text 0e40 bus_unit_vtable -- .data.rel.ro 11d7 bus_cgroup_set_property -- .text 1410 bus_manager_vtable -- .data.rel.ro 1453 exec_child -- .text 1470 wordlist.7848 -- .data.rel.ro.local 2b90 main -- .text e1c0 wordlist.14097 -- .data.rel.ro wordlist.14097 is a generated table for all configuration options in load-fragment-gperf.c. wordlist.7848 is for errno_from_name (5k for this is a bit of a stretch though). I wonder if any of these tables might have holes in them? i.e. some enums skip a few numbers in the middle, and are thus not really appropriate for the usual DEFINE_STRING_TABLE() stuff we do? I think it's like a hash table, i.e. approx %50 empty on purpose. At least in case load load-fragment-gperf, we are trading a bit of space for speed in an important code path, so I'm sure it is worth it. The errno stuff isn't probably that important, because iiuc we won't even load this page until it is used, so again, this seems fine. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
- Original Message - From: Martin Steigerwald mar...@lichtvoll.de Heck, I started a thread here and then didn´t manage to take time to carefully read it and reply here and there as I see fit. But I challenged people on debian-user mailing list to constructively voice their concerns upstream, and even pointed them to this mailing list. As far as I saw *no one* of the posters in debian-user took up on that challenge. Which I view as a pity. Cause now actually you invited constructive feedback. I wonder whether I may forward your answer to debian-user so they see your statement of inviting constructive feedback. I am here from debian-user, due to Martin's suggestion. So now that he's calling me out, I guess I'll post my questions :) For the record, I'm a sysadmin and not a developer. I imagine my questions and opinions will reflect that. Here the feedback I read over and over again is that you and RedHat basically forced the systemd decision onto other distributions. While I do not see how you actually can be powerful enough to do that, as we live in a free will zone. I do see tendencies that more and more stuff *depends* on systemd cause it needs features only available there. On of the most talked on things on debian-user is the logind thing. GNOME actually depends on it, as far as I know. While KDE in Debian still uses ConsoleKit, as it seems to me when looking at the process list and finding: On Debian, I came across an unusual dependency. Installing a cd burner (brasero) required me to change my init system to systemd. Sounds kind of ridiculous, I think. The dependency chain went like this: brasero - gvfs - gvfs-daemons - udisks2 - libpam-systemd - systemd-sysv I don't know enough about this stuff to comment very intelligently, which is why I haven't said anything up until now. But my research shows that each of these dependencies is indeed valid in the sense that each dependency represents some real requirement for functionality. The issue, I think, is that some of these packages provide very broad functionality. As I put it in a Debian bug report: Brasero needs X functionality, which can be found in package W. Package W also provides Y functionality, which depends on systemd-sysv. So therefore brasero depends on systemd-sysv, even though it doesn't *need* it. I gather that this has something to do with logind and/or cgroups. I can appreciate the benefits (on some systems) of giving only the local user access to removable media. But I don't understand why this functionality requires the use of systemd-sysv (the init system), particularly if my understanding is correct that this functionality used to be separate from the init portion of systemd. Dependencies like this actually create some force to adopt systemd. Based on Lennart's and others' comments in this thread, forced adoption does not seem to be a goal. But forced adoption is a reality due to dependencies like the one above. I think there would be a lot less skepticism about systemd if the perception of forced adoption weren't so strong, and I'd love to see something done about this situation. Now I know ConsoleKit isn´t developed anymore, but also I never got why a logind implementation needs to depend on systemd base package in such a way that at least in Debian systemd package has to be installed if someone wants to use GNOME. Is this what Debian's systemd-shim is for? If not, well I'm going to talk about that anyway... Systemd-shim provides some functionality that systemd-sysv provides, and allows admins to use init systems other than systemd while still installing things like brasero. I think this is a great thing, except I wonder why the systemd project didn't separate this functionality from the init system in the first place. Systemd-shim is a duplication of effort. Not only that, but it must time its releases with the releases of systemd-sysv. That's no big deal for Debian's stable release, but it can be problematic in Debian's unstable and testing branches. Wouldn't the systemd developers prefer to have their implementation of this functionality be used, regardless of the chosen init system? Let me stress this: constructive feedback is *always* welcome! The following may not concern you personally, but Debian is attempting to support multiple kernels (Linux, BSD and Hurd I think). As I understand it, systemd is Linux-only. Defaulting to a Linux-only init system makes supporting non-Linux kernels more work, because an alternate init system must be maintained, as well as init scripts for that init system. If functionality was separated as I described above, and the systemd project provided a very basic init-only package, would that be portable to non-Linux kernels? Users can also decide to help test the alternatives. Unlike other distros Debian still supports them. But systemd's approach of incorporating additional non-init
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Hello Rob, this is higly Debian specific (doesn't even apply to Ubuntu) and thus a bit off-topic, but as the question already is on the upstream ML.. sorry! Rob Owens [2014-10-06 14:56 -0400]: brasero - gvfs - gvfs-daemons - udisks2 - libpam-systemd - systemd-sysv You can break it up after libpam-systemd, as this has dependency alternatives to systemd-shim. With that you can use sysvinit or upstart. But currently systemd-sysv is the preferred alternative, so if you don't specify anything else it will pick systemd-sysv. You can do e. g. apt-get install brasero systemd-shim to select another (or install -shim first). I gather that this has something to do with logind and/or cgroups. That's correct; in fact most desktop-y software talks to logind only, but logind is a crucial component on a modern desktop. Systemd-shim is a duplication of effort. It's a looong story/history, but systemd-shim itself is actually fairly small. It's mostly glue to provide systemd's D-BUS API and implement it in terms of other components like cgmanager and pm-utils. And its development was quite inevitable at least from Debian's/Ubuntu's perspective as it is just practically impossible to do a SysV/upstart → systemd migration on a flag day. Not only that, but it must time its releases with the releases of systemd-sysv. Mostly not. That needs to happen for D-BUS API changes like they happened around version 209, but that happens fairly seldomly. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, Oct 06, 2014 at 02:56:22PM -0400, Rob Owens wrote: - Original Message - From: Martin Steigerwald mar...@lichtvoll.de Heck, I started a thread here and then didn´t manage to take time to carefully read it and reply here and there as I see fit. But I challenged people on debian-user mailing list to constructively voice their concerns upstream, and even pointed them to this mailing list. As far as I saw *no one* of the posters in debian-user took up on that challenge. Which I view as a pity. Cause now actually you invited constructive feedback. I wonder whether I may forward your answer to debian-user so they see your statement of inviting constructive feedback. I am here from debian-user, due to Martin's suggestion. So now that he's calling me out, I guess I'll post my questions :) For the record, I'm a sysadmin and not a developer. I imagine my questions and opinions will reflect that. Here the feedback I read over and over again is that you and RedHat basically forced the systemd decision onto other distributions. While I do not see how you actually can be powerful enough to do that, as we live in a free will zone. I do see tendencies that more and more stuff *depends* on systemd cause it needs features only available there. On of the most talked on things on debian-user is the logind thing. GNOME actually depends on it, as far as I know. While KDE in Debian still uses ConsoleKit, as it seems to me when looking at the process list and finding: On Debian, I came across an unusual dependency. Installing a cd burner (brasero) required me to change my init system to systemd. Sounds kind of ridiculous, I think. The dependency chain went like this: brasero - gvfs - gvfs-daemons - udisks2 - libpam-systemd - systemd-sysv I don't know enough about this stuff to comment very intelligently, which is why I haven't said anything up until now. But my research shows that each of these dependencies is indeed valid in the sense that each dependency represents some real requirement for functionality. The issue, I think, is that some of these packages provide very broad functionality. As I put it in a Debian bug report: Brasero needs X functionality, which can be found in package W. Package W also provides Y functionality, which depends on systemd-sysv. So therefore brasero depends on systemd-sysv, even though it doesn't *need* it. I gather that this has something to do with logind and/or cgroups. I can appreciate the benefits (on some systems) of giving only the local user access to removable media. But I don't understand why this functionality requires the use of systemd-sysv (the init system), particularly if my understanding is correct that this functionality used to be separate from the init portion of systemd. I'll assume that this is a serious question, despite being rather elementary... You describe a dependency chain. First of all, it is important to note that it does not matter if brasero actually uses the part of gvfs that uses the part of udisk2 that uses the part of libpam-systemd that requires systemd to be running. Possibly not, and maybe brasero would still function correctly w/o systemd. But dependencies are expressed on package level, so if systemd is required for some functionality of libpam-systemd, which is used by any package depending on libpam-systemd, then libpam-systemd must depend on systemd-sysv, and transitively so must brasero. To break this chain at some point, it is necessary replace the strict dependency with recommends/suggests or provide a different different package which satisfies the dependency. The first option is only possible if the functionality provided by the dependent package is not essential. In some cases it is really clear, e.g. a binary requires a library to be installed to be able to run, but in other cases it's a judgment call by the maintainers, whether some part of functionality is important enough to add a dependency. In this case brasero, gvfs, udisks2, and systemd maintainers decided that yes, it is. The second option requires someone to step up and provide an alternative implementation. So far, systemd-shim is one candidate, but it took months to appear and still has occasional problems. (I don't follow the situation quite closely, but Michael seems to find serious bugs with very light testing). At some point, systemd-shim might become a viable replacement. This work should be done by people who want the alternatives, not the maintainers of systemd, who happily use the existing stack. So if the alternatives are not in the shape you would like them to be, inquire with the maintainers of the said alternatives. But even assuming that an alternative is functional, using it is not without costs for the maintainers of dependent packages. Let's say that we have some systems with systemd, some with systemd-shim. It is likely that a bug
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Hi Lennart, Am Mittwoch, 1. Oktober 2014, 23:33:43 schrieb Lennart Poettering: On Sun, 21.09.14 15:31, Martin Steigerwald (mar...@lichtvoll.de) wrote: I just have one question. In the light of [...] Heck, I started a thread here and then didn´t manage to take time to carefully read it and reply here and there as I see fit. But I challenged people on debian-user mailing list to constructively voice their concerns upstream, and even pointed them to this mailing list. As far as I saw *no one* of the posters in debian-user took up on that challenge. Which I view as a pity. Cause now actually you invited constructive feedback. I wonder whether I may forward your answer to debian-user so they see your statement of inviting constructive feedback. in the light of the ongoing discussions on linux-kernel, debian-devel, debian- user and other mailing lists more than some dozens threads meanwhile: Did you ever ask yourself why your project provokes that amount of resistance and polarity? Did you ever ask yourself whether this really is just resistance against anything new from people who just do not like new or whether it contains *valuable* and *important* feedback? That's already two questions... But anyway. Let me turn your question around: we swapped out one of the most central pieces of Linux systems, one of the pieces that is probably the most core of what administrators interface with every day. How could this change ever have gone *without* any noise? Yet… I think it is not just noise. Administrators probably are a generally more conservative bunch, anything that interferes with their day-to-day workflow that they are used to is a distraction. That's quite understandable. In fact, I used to be an admin myself a long time ago, and I still administer a couple of machines. I have similar feelings when I update them, and in particular when some component I don't want to spend the time to relearn changes I end up being annoyed (dovecot config file changes!). Oh, I know this one. I moved all the gazillion config files away and told it to use my old single file config. And for my setup using a ton of config files just adds immensively to my maintenance overheard, when I can write down the configuration in a page of text. Moreover, init systems are just an auxiliary tool to run things. Nobody starts a computer up to run systemd on it. People start up a computer to run a web app or database server software on it. Because of that, systemd is just a tool to make something else work, and the focus is always on that other thing, and any time spent on systemd or relearning it feels like wasted time to many. I totally and absolutely understand these feelings. Well I do see advantages. I am one of the early adopters of systemd. And I would need to hold hands before my eyes to not see the advantages. But I can also resonate with some of the concerns. However, I also believe that the change we are making is for the good, and even though it might not be obvious to many immediately, it brings major benefits when administering machines, and they massively outweigh the disadvantage of changing things. And apparently I am not entirely alone with this, as the folks who make technical decision for the various distributions ended up deciding in favour of systemd in most cases. Why do you believe so? What key points make you believe so? Here the feedback I read over and over again is that you and RedHat basically forced the systemd decision onto other distributions. While I do not see how you actually can be powerful enough to do that, as we live in a free will zone. I do see tendencies that more and more stuff *depends* on systemd cause it needs features only available there. On of the most talked on things on debian-user is the logind thing. GNOME actually depends on it, as far as I know. While KDE in Debian still uses ConsoleKit, as it seems to me when looking at the process list and finding: /usr/bin/ck-launch-session /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde Dependencies like this actually create some force to adopt systemd. Now I know ConsoleKit isn´t developed anymore, but also I never got why a logind implementation needs to depend on systemd base package in such a way that at least in Debian systemd package has to be installed if someone wants to use GNOME. Also some parts of KDE seem to depend on systemd meanwhile in Debian – basically udisks related parts and Network-Manager: merkaba:~ LANG=C apt-get purge systemd Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: amor analitza-common blinken cantor cantor-backend-kalgebra filelight kaccessible kalgebra kalgebra-common kalzium kalzium-data kanagram kbruch kcharselect kcolorchooser kde-config-cron kde-icons-mono kdeaccessibility
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am Sonntag, 5. Oktober 2014, 12:20:01 schrieb Martin Steigerwald: Well… I may post much more in this thread. not post much more -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am Mittwoch, 1. Oktober 2014, 23:33:43 schrieb Lennart Poettering: (What I didn't expect though is how awful the Linux community can actually be. That people collect Bitcoins to hire a hitman on me, that people start petitions to make me stop working, and all that other really hateful, personal stuff is really apalling. I guess I have a thick skin, because I don't care too much, but jeezus christ, it's really disgusting sometimes.) I just filed an abuse complaint about some personal attacks to you and systemd supporters in general with Debian listmasters. They were way out of bounds of netiquette. I am not willing to tolerate such abuse. Also went to LKML, but I am not aware of any netiquette reporting for it. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Hi Jóhann, Am Sonntag, 21. September 2014, 22:15:32 schrieb Jóhann B. Guðmundsson: On 09/21/2014 01:31 PM, Martin Steigerwald wrote: in the light of the ongoing discussions on linux-kernel Could you provide a link to that ongoing discussion that is taking place in the kernel community regarding systemd? I think this is the one I meant: OT: Open letter to the Linux World https://lkml.org/lkml/2014/8/12/459 It seems to have ceased meanwhile. Also on some other occasion a kernel developer agreed on my concerns regarding binary size of PID 1 with systemd. Did you ever ask yourself why your project provokes that amount of resistance and polarity? Did you ever ask yourself whether this really is just resistance against anything new from people who just do not like new or whether it contains*valuable* and*important* feedback? I'm not sure why you are under the assumption that we do not consider and have not and are not gathering feedback from individuals, communities or companies for that matter but I'm going to address your questions anyway. Have we ever asked ourselves why our project provokes that amount of resistance and polarity? The answer to that question is yes, yes we have and yes we will continue to do so since resistance and polarity provides with the valuable information amongst other things if the implementation is bad and alternative approach is better ( which often reveals itself at the same time those friction take place ). Dont get me wrong we will not do so when those discussion involve nothing but personal attack on our community member(s) which more often than not happens to be Lennart, Lennart is and never has been the sole person behind this effort, he's part of ever growing community. I am not willing to tolerate personal attacks on Debian user. I just remembered that I can act on it and filed an abuse complaint about some of those. Nor when it involves us having to implement somekind of hack as opposed to have the problem properly fixed where it belongs ( which could be us or not ) or when those discussion criticizes that we have chosen to tightly integrate ourselves specifically to the linux kernel it's ecosystem and with glibc in mind just like bsd based distribution as well as solaris and other nixes are tightly integrating their components to their kernels but for some dumbfound reason people on the internet are under the assumption that they have the authority of refusing us the freedom of doing the same o_O and the answer to those individuals we dont care about their opinion on this matter. Now alot of the resistance and polarity that is taking place like in the url you pointed at is hiding itself behind their misinterpretation of the so called Unix philosophy and claiming that we somehow fall short on the guidelines originates from few things Doug McIlroy,Rob Pike,Ken Thompson said sometime in the 70's or rather the Unix philosophy was implied not by what these individuals said but rather by what they did which more or less boils down to this.. 1. Write simple parts connected by clean interfaces. Well, I for one wonder what is all in that 1,3 MiB binary of systemd running as PID 1? In my estimation it can´t be just some services handling and control groups management. As that would be much smaller I believe. There is systemd --user running just a fraction of code of this binary as Lennart explained. To me, this is a huge binary and to me its not clear what things it does and how they operate with one another via a clean interface if packed all into one binary. 2. Clarity is better than cleverness. Using debug commands was needed to diagnose a fstab syntax error: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755506#25 As I pointed out (with wrong bug link, sorry). Its arguable whether to fail hard on syntax errors in fstab, but if systemd fails hard, I expect put me a *big fat* error message on the screen explaining the issue at hand. Except expecting me to use debug commands to find out whats wrong. 3. Design programs to be connected to other programs. Well we appear to have quite some binaries. But according to binary size, very much of the functionality appears to be in systemd main binary. But even other binaries are quite large for what they do. merkaba:~ ( for FILE in $( dpkg -L systemd | egrep lib|bin ); do test -f $FILE test -x $FILE stat --format %s %n $FILE ; done ) | sort - rn 1309064 /lib/systemd/systemd 538904 /bin/systemctl 522480 /lib/systemd/systemd-networkd 506096 /lib/systemd/systemd-logind 366856 /usr/bin/systemd-nspawn 325872 /lib/systemd/systemd-machined 309488 /bin/loginctl 297192 /lib/systemd/systemd-localed 293096 /lib/systemd/systemd-timedated 289000 /lib/systemd/systemd-hostnamed 288992 /lib/systemd/systemd-bus-proxyd 280816 /bin/machinectl 276712 /usr/bin/busctl 272616 /usr/bin/systemd-analyze 260328 /usr/bin/timedatectl 256232 /usr/bin/localectl 256224
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Sun, 21.09.14 15:31, Martin Steigerwald (mar...@lichtvoll.de) wrote: I just have one question. In the light of [...] in the light of the ongoing discussions on linux-kernel, debian-devel, debian- user and other mailing lists more than some dozens threads meanwhile: Did you ever ask yourself why your project provokes that amount of resistance and polarity? Did you ever ask yourself whether this really is just resistance against anything new from people who just do not like new or whether it contains *valuable* and *important* feedback? That's already two questions... But anyway. Let me turn your question around: we swapped out one of the most central pieces of Linux systems, one of the pieces that is probably the most core of what administrators interface with every day. How could this change ever have gone *without* any noise? Administrators probably are a generally more conservative bunch, anything that interferes with their day-to-day workflow that they are used to is a distraction. That's quite understandable. In fact, I used to be an admin myself a long time ago, and I still administer a couple of machines. I have similar feelings when I update them, and in particular when some component I don't want to spend the time to relearn changes I end up being annoyed (dovecot config file changes!). Moreover, init systems are just an auxiliary tool to run things. Nobody starts a computer up to run systemd on it. People start up a computer to run a web app or database server software on it. Because of that, systemd is just a tool to make something else work, and the focus is always on that other thing, and any time spent on systemd or relearning it feels like wasted time to many. I totally and absolutely understand these feelings. However, I also believe that the change we are making is for the good, and even though it might not be obvious to many immediately, it brings major benefits when administering machines, and they massively outweigh the disadvantage of changing things. And apparently I am not entirely alone with this, as the folks who make technical decision for the various distributions ended up deciding in favour of systemd in most cases. Yes, we knew exactly we'd be getting a lot of heat for all this. We have been getting it from the day on we announced the project. And I am pretty sure it will continue this way for a while still. (What I didn't expect though is how awful the Linux community can actually be. That people collect Bitcoins to hire a hitman on me, that people start petitions to make me stop working, and all that other really hateful, personal stuff is really apalling. I guess I have a thick skin, because I don't care too much, but jeezus christ, it's really disgusting sometimes.) I monitor the feedback posted on the Internet regularly. I browse reddit and the debian and gentoo mailing list archives sometimes, and try to distill the useful bits out of all the noise and hate dumped there. This actually used to be very productive for quite some time, and much of the polishing that systemd got over the years was a result of the feedback I read through this way, even if I had to read between the lines of all the hateful mails. Today, it's much less useful, I figure partially because the worst usability issues with systemd have long been fixed, but also because the crowd commenting changed from folks who were genuinely interested (early adopter folks) to a more general audience which also includes a lot of haters. The current increase noised level around systemd adoption I attribute to three things: the fact that RHEL7 is out now, the fact that due to the adoption of systemd as default by Debian and Ubuntu the folks who ignored the discussion so far now are faced with this change, and also to a big part to certain columnists who in the interest of generating traffic to their sites try to create a hubbub out of very little. Anyway, long story short: we knew what we did, and yeah, I read feedback, even if it is written in a hateful style, and we learn from it. For now I use systemd. I like quite some features. But on the other hand I am vary about it myself. I look at a 45 KiB binary for /sbin/init as PID1 and a 1,3 MiB binary in systemd 215 and wonder myself. I see systemd --user processes running and wonder: Well, note that systemd used for user services actually saves you resources, as the systemd binary only needs to be mapped into memory once and then is shared between all user instances and the system instance. Is it really all just nay-sayers for the sake of nay-saying? No, it's not that simple. Or do they – at least partly – provide *valuable* and *important* feedback. Well, some is valuable and important, but much certainly isn't. The 200nd complaint that systemd was monolithic or so is something I am genuinely not interested in anymore, for example... I will continue to scan reddit and the mailing list archives for stuff I find, but of
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, 22.09.14 10:16, Dale R. Worley (wor...@alum.mit.edu) wrote: 1. Systemd has some very large binaries, each of which implements many aspects of the system. Conversely, the typical Un*x approach is to separate functions into many executablels, many of which are scripts. The latter approach makes customization easier, especially for sysadmins who aren't deeply familiar with the system. We split up things into 80+ binaries. 2. Systemd includes a tremendous number of features and behaviors, but a lot of them aren't documented very well. That's not so unusual in Un*x, but if you're introducing something new, nobody has any prior knowledge of it, and the lack of documentation becomes visible. Please let us know where documentation is missing. I know a couple of areas where documentation is lacking (such as the too muc hof the C APIs we expose currently), but at least the user-facing stuff should be pretty comprehesively documented. If you are missing docs for something I'd be quite interested to know for which parts so that we can actually fix it. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, 23.09.14 15:13, Dale R. Worley (wor...@alum.mit.edu) wrote: Again, this seems rather ignorant of the status quo. Between the blog posts and wiki documentation and the 164 man pages, systemd is rather copiously documented. Not to say that things can't be improved, but by Linux standards we are at least making an effort. Bugs for missing or unclear documentation and usually handled, and any patches for documentation are applied fairly quickly. OK, I'd like to modify systemd's handling of mounts. I've been told only that the units that are created from /etc/fstab are created and handled by the main systemd binary. What documentation do I look at that explains how systemd actually does that, what the relevant source is, etc.? With init scripts, I know it's somewhere in a script in /etc/rc.d/init.d; searching for mount probably reveals a couple of hundred lines of shell script within which the functionality is hiding. As mentioned on this thread systemctl help on a unit is a really easy way to get more information about it. Pretty much all units we ship with systemd upstream contains the necessary meta information to link it up directly with its docs. mount units for /etc/fstab entries are nowadays generated from a so called generator, see systemd-fstab-generator(8). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Let me offer this as a suggestion of what might be the root of some issues: One of the lessons in Fred Brooks' The Mythical Man-Month is that it takes three times more effort to produce a *program product* as it does to produce the *program*. That is, 2/3 of the effort is not to make the software do what it is supposed to, but rather to adjust the software to work in the (software and human) environment that it must work in, interacting with customers, etc. It might be worth examining the project and asking whether the non-software part of the work has been carried out with the same care as the software part of the work. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, Sep 22, 2014 at 10:16:36AM -0400, Dale R. Worley wrote: From: Jóhann B. Guðmundsson Did you ever ask yourself why your project provokes that amount of resistance and polarity? Did you ever ask yourself whether this really is just resistance against anything new from people who just do not like new or whether it contains*valuable* and*important* feedback? I'm not sure why you are under the assumption that we do not consider and have not and are not gathering feedback from individuals, communities or companies for that matter but I'm going to address your questions anyway. I've brought a complaint about one of systemd's behaviors here. I have gotten useful feedback allowing me to refine what I think would be a good solution to the problem. What I *haven't* gotten is any useful feedback on how to implement a solution. I suspect others have had similar experiences. One metric that might be useful is to ask: Of the people who complain about one or another aspect of systemd, what fraction ultimately consider their complaint to be satisfactorily resolved? Hm, if you looked at any of the bugtrackers, most systemd issues are resolved (e.g. on bugs.freedesktop.org we have about 140 of of 950 issues still opened). Most of the time they are actually fixed, and the ones that are left open are either RFEs or more complicated issues. There are also architectural issues about systemd that I've noticed. I don't know to what degree these indicate quality control problems with the code, or whether they are just a matter of things being done in ways that are not common in the Un*x universe. But they do seem to me to be things that are going to inhibit adoption. 1. Systemd has some very large binaries, each of which implements many aspects of the system. Conversely, the typical Un*x approach is to separate functions into many executablels, many of which are scripts. The latter approach makes customization easier, especially for sysadmins who aren't deeply familiar with the system. Actually, based on what I've read e.g. in the UNIX haters' handbook, the idea of separating into many separate binaries wasn't all that common in UNIX. Also, historically programs used to be real binaries, not scripts. More seriously, the idea of having shell scripts which you're going to modify to customize your setup is simply crazy. How robust would your changes be? How would you ever handle upgrades? How would more than one admin manage a machine without sitting in the same room? I don't know where you get the idea that systemd has big binaries. Existing source code compiles to ~140 binaries and a few libraries. Many of them are really tiny, a few that do more complicated things are bigger. And things are very much separated by function between daemons. 2. Systemd includes a tremendous number of features and behaviors, but a lot of them aren't documented very well. That's not so unusual in Un*x, but if you're introducing something new, nobody has any prior knowledge of it, and the lack of documentation becomes visible. Again, this seems rather ignorant of the status quo. Between the blog posts and wiki documentation and the 164 man pages, systemd is rather copiously documented. Not to say that things can't be improved, but by Linux standards we are at least making an effort. Bugs for missing or unclear documentation and usually handled, and any patches for documentation are applied fairly quickly. Ultimately, writing e-mail messages saying They're wrong is useless, even if they *are* wrong. If there is a substantial body of people out there who dislike systemd, it's going to prevent its adoption. The fix is adjusting systemd (or the project surrounding it) so that people like it better. Sometimes, sometimes not. Doing everything that is requested, especially by newcomers to the project, would quickly cause the project to lose focus and consistency and turn into an unmaintainable mess. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
From: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl More seriously, the idea of having shell scripts which you're going to modify to customize your setup is simply crazy. How robust would your changes be? How would you ever handle upgrades? How would more than one admin manage a machine without sitting in the same room? I've been editing init scripts since around 1992, and I'll bet that a lot of other people have, too. It's reasonably robust, since you know where the edits are and what they're for. You upgrade by bringing forward the edits into each new release you load. But there's no way around that. Suppose I'd like to adjust systemd's behavior regarding mounting devices (as I do). Is that going to be *easier* to do if I have to download the C, modify it, and recompile? I still have the same problems with upgrading, etc. In the end, what wins is usually what makes it easiest to accomplish the tasks people have at hand. E.g., in many ways, C is an inferior language to Pascal, but there are enough things that Pascal makes hard or impossible that C won out. Similarly with customizations. Again, this seems rather ignorant of the status quo. Between the blog posts and wiki documentation and the 164 man pages, systemd is rather copiously documented. Not to say that things can't be improved, but by Linux standards we are at least making an effort. Bugs for missing or unclear documentation and usually handled, and any patches for documentation are applied fairly quickly. OK, I'd like to modify systemd's handling of mounts. I've been told only that the units that are created from /etc/fstab are created and handled by the main systemd binary. What documentation do I look at that explains how systemd actually does that, what the relevant source is, etc.? With init scripts, I know it's somewhere in a script in /etc/rc.d/init.d; searching for mount probably reveals a couple of hundred lines of shell script within which the functionality is hiding. Another more generically useful pointer would be something that explains what the algorithm that does the sequencing between units *really* is. I've heard breezy descriptions of what the various dependency types mean, but I'm certain that there's a bunch of tricky details which a lot of thought has been spent on. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, Sep 23, 2014 at 9:13 PM, Dale R. Worley wor...@alum.mit.edu wrote: OK, I'd like to modify systemd's handling of mounts. I've been told only that the units that are created from /etc/fstab are created and handled by the main systemd binary. What documentation do I look at that explains how systemd actually does that, what the relevant source is, etc.? With init scripts, I know it's somewhere in a script in /etc/rc.d/init.d; searching for mount probably reveals a couple of hundred lines of shell script within which the functionality is hiding. Try systemctl status home.mount (or some other mount unit generated from your fstab), then there will be pointers to the relevant documentation there (Doc:). To be dropped directly into the man pages, just do systemctl help home.mount. Another more generically useful pointer would be something that explains what the algorithm that does the sequencing between units *really* is. I've heard breezy descriptions of what the various dependency types mean, but I'm certain that there's a bunch of tricky details which a lot of thought has been spent on. I do not understand this question. Could you give an example of what you are struggling with? I mean, the gist is that the After/Before orderings are respected and everything else is done in parallel. To get the precise orderings applied to a unit try systemctl show bar.service. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson: The reason for increased log entries in the journal is that more things are happening now since this is what happening when a job is run. that don't change the fact that a user not acting as systemd-developer and not debugging his system don't need that flood you need to distinct between users and developers users want to have *abnormal* things logged and not burried inside noise Those that have cron job that send email that notifies every time that it ran ( to know it ran ) and those that do not send an email unless the job it was running failed and rely on logwatch to inform them if the cron job ran or not. If you dont like it filter it and retrieve only the information you want/need with journalctl if they would have a prefix i would filter them to nowhere in rsyslog please understand that not everybody is using journalctl Well this is upstream that ships nothing but journalctl whether they use it or not then add at least *prefixes* to write filter rules what you say is we don't ship nothing but and we don't care about nothing but that is the reason for the polarity we are upstream and don't care just give journald.conf a verbosity option and all are happy honestly the messages about reaching target are nonsense without a prefix pointing out that it is about a *user session* because it looks like a bootlog every minute Mar 4 13:01:01 rawhide systemd[1559]: Starting Paths. Mar 4 13:01:01 rawhide systemd[1559]: Reached target Paths. Mar 4 13:01:01 rawhide systemd[1559]: Starting Timers. Mar 4 13:01:01 rawhide systemd[1559]: Reached target Timers. Mar 4 13:01:01 rawhide systemd[1559]: Starting Sockets. Mar 4 13:01:01 rawhide systemd[1559]: Reached target Sockets. Mar 4 13:01:01 rawhide systemd[1559]: Starting Basic System. Mar 4 13:01:01 rawhide systemd[1559]: Reached target Basic System. Mar 4 13:01:01 rawhide systemd[1559]: Starting Default. Mar 4 13:01:01 rawhide systemd[1559]: Reached target Default. Mar 4 13:01:01 rawhide systemd[1559]: Startup finished in 9ms. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On 09/22/2014 11:40 AM, Reindl Harald wrote: Am 22.09.2014 um 13:28 schrieb Jóhann B. Guðmundsson: On 09/22/2014 09:23 AM, Reindl Harald wrote: Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson: The reason for increased log entries in the journal is that more things are happening now since this is what happening when a job is run. that don't change the fact that a user not acting as systemd-developer and not debugging his system don't need that flood I guess we have different meaning of message flood again: we talk about rsyslog, like it or not Then file a bug report against rsyslog and provide a patch which fixes the default log filtering in Fedora to your expectation but leave systemd out of it. what you filter below is what i have in /var/log/cron and /var/log/secure but the other messages spit to the log are a lot more here you have a simple calculation https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c8 why don't you look at https://bugzilla.redhat.com/show_bug.cgi?id=1072368 and the workaround loginctl enable-linger leads to another bugreport open for months: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54 so what we have now is log flooding or hanging shutdowns why don't upstream just what users would help and reduce logging in a non-debug mode to a minimum so one can see without filter if something unusal happens on a system? if the developers would accept the need of their users then likely the users would also be more positive, just don't explain me how to maintain my servers i am fine with distribute-command.sh cat /var/log/messages all they years because the general log is silent until something bad happens you can't do that if systemd floods it for 30 machines # journalctl -f Sep 22 11:13:01 localhost.localdomain systemd[1]: Starting Session 59 of user johannbg. Sep 22 11:13:01 localhost.localdomain systemd[1]: Started Session 59 of user johannbg. Sep 22 11:13:01 localhost.localdomain CROND[7336]: (johannbg) CMD (/bin/systemd-cat -t CROND /bin/echo Systemd journal cron job log test every minute ) Sep 22 11:13:01 localhost.localdomain CROND[7336]: Systemd journal cron job log test every minute Hey let's filter this even further # journalctl -f SYSLOG_IDENTIFIER=CROND -- Logs begin at Thu 2013-10-24 11:47:22 GMT. -- Sep 22 11:14:01 localhost.localdomain CROND[7401]: (johannbg) CMD (/bin/systemd-cat -t CROND /bin/echo Systemd journal cron job log test every minute ) Sep 22 11:14:01 localhost.localdomain CROND[7401]: Systemd journal cron job log test every minute Anything regarding an text file and local and or remote logging using either rsyslog or syslog-ng is and it's default is not relevant to us and usually set by distribution maintainers. For remote logging I would assume administrator would create an cron filter which has the syslog identifier crond or CROND, the syslog facility 9 and an priority 6 and send that to the remote server So if systemd output is too much in any text file -- file a bug against rsyslog or syslog-ng depending on which the distribution and have *them* fix their default filtering JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am 22.09.2014 um 13:45 schrieb Jóhann B. Guðmundsson: On 09/22/2014 11:40 AM, Reindl Harald wrote: Am 22.09.2014 um 13:28 schrieb Jóhann B. Guðmundsson: On 09/22/2014 09:23 AM, Reindl Harald wrote: Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson: The reason for increased log entries in the journal is that more things are happening now since this is what happening when a job is run. that don't change the fact that a user not acting as systemd-developer and not debugging his system don't need that flood I guess we have different meaning of message flood again: we talk about rsyslog, like it or not Then file a bug report against rsyslog and provide a patch which fixes the default log filtering in Fedora to your expectation but leave systemd out of it. wow - in any other case the systemd developers saying that they don't workround things because problems has to be solved at the root-cause - practice what you preach and make the log-verbosility configureable! * rsyslog is *not* responsible for the message flood produced by systemd * systemd is the one producing it without prefixes produce 8 loglines noise on a small infrastructure is insane that's the same all other services produce together is it really that hard to accept that this level of informations is only helpful for debugging, produces overhead if it could be filtered away and anyways has the bad impact that journald in rsyslog envoironments has the whole day to do with rotate [Journal] Storage=volatile Compress=yes RateLimitInterval=10s frankly i have seen more or less idle machines where journald is one of the top ressource consumers what you filter below is what i have in /var/log/cron and /var/log/secure but the other messages spit to the log are a lot more here you have a simple calculation https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c8 why don't you look at https://bugzilla.redhat.com/show_bug.cgi?id=1072368 and the workaround loginctl enable-linger leads to another bugreport open for months: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54 so what we have now is log flooding or hanging shutdowns why don't upstream just what users would help and reduce logging in a non-debug mode to a minimum so one can see without filter if something unusal happens on a system? if the developers would accept the need of their users then likely the users would also be more positive, just don't explain me how to maintain my servers i am fine with distribute-command.sh cat /var/log/messages all they years because the general log is silent until something bad happens you can't do that if systemd floods it for 30 machines # journalctl -f Sep 22 11:13:01 localhost.localdomain systemd[1]: Starting Session 59 of user johannbg. Sep 22 11:13:01 localhost.localdomain systemd[1]: Started Session 59 of user johannbg. Sep 22 11:13:01 localhost.localdomain CROND[7336]: (johannbg) CMD (/bin/systemd-cat -t CROND /bin/echo Systemd journal cron job log test every minute ) Sep 22 11:13:01 localhost.localdomain CROND[7336]: Systemd journal cron job log test every minute Hey let's filter this even further # journalctl -f SYSLOG_IDENTIFIER=CROND -- Logs begin at Thu 2013-10-24 11:47:22 GMT. -- Sep 22 11:14:01 localhost.localdomain CROND[7401]: (johannbg) CMD (/bin/systemd-cat -t CROND /bin/echo Systemd journal cron job log test every minute ) Sep 22 11:14:01 localhost.localdomain CROND[7401]: Systemd journal cron job log test every minute Anything regarding an text file and local and or remote logging using either rsyslog or syslog-ng is and it's default is not relevant to us and usually set by distribution maintainers. For remote logging I would assume administrator would create an cron filter which has the syslog identifier crond or CROND, the syslog facility 9 and an priority 6 and send that to the remote server So if systemd output is too much in any text file -- file a bug against rsyslog or syslog-ng depending on which the distribution and have *them* fix their default filtering signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On 09/22/2014 12:07 PM, Reindl Harald wrote: Am 22.09.2014 um 13:45 schrieb Jóhann B. Guðmundsson: On 09/22/2014 11:40 AM, Reindl Harald wrote: Am 22.09.2014 um 13:28 schrieb Jóhann B. Guðmundsson: On 09/22/2014 09:23 AM, Reindl Harald wrote: Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson: The reason for increased log entries in the journal is that more things are happening now since this is what happening when a job is run. that don't change the fact that a user not acting as systemd-developer and not debugging his system don't need that flood I guess we have different meaning of message flood again: we talk about rsyslog, like it or not Then file a bug report against rsyslog and provide a patch which fixes the default log filtering in Fedora to your expectation but leave systemd out of it. wow - in any other case the systemd developers saying that they don't workround things because problems has to be solved at the root-cause - practice what you preach and make the log-verbosility configureable! Serves no purpose whatsoever doing that. * rsyslog is*not* responsible for the message flood produced by systemd No but it is responsible for the filtering -- of log messages. * systemd is the one producing it without prefixes This is simply untrue as journalctl -o export will show you. I suggest you stop blaming systemd for your own administrative incompetence and broken implementation of rsyslog and syslog-ng in Fedora ( I tried to get it fixed before we defaulted to journal YES IT WAS BROKEN BEFORE AND STILL IS but was not allowed to do so thank those Red Hatters in the governing body's of Fedora ( FESCO/FPC ) for it's brokeness ) and write an rsyslog template suited for your environment which will filter things to your liking and expectation or better yet complain to those FESCO/FPC members since they need to learn a hard lesson of accepting responsibility for their own actions in the distribution. You can find how to write an rsyslog template in the upstream rsyslog documentation using it's powerful filtering capabilities and by looking at for example the one spice-vdagentd /etc/rsyslog.d/spice-vdagentd.conf in Fedora. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am 22.09.2014 um 14:44 schrieb Jóhann B. Guðmundsson: Then file a bug report against rsyslog and provide a patch which fixes the default log filtering in Fedora to your expectation but leave systemd out of it. wow - in any other case the systemd developers saying that they don't workround things because problems has to be solved at the root-cause - practice what you preach and make the log-verbosility configureable! Serves no purpose whatsoever doing that. * rsyslog is *not* responsible for the message flood produced by systemd No but it is responsible for the filtering -- of log messages. * systemd is the one producing it without prefixes it is ridiculous to have the need of filtering This is simply untrue as journalctl -o export will show you. where is it in the message? the process is systemd how to distinct between user sessions and systemn boot? :programname don't work and :msg, startswith don't work Mar 18 23:01:01 rawhide systemd[577]: Stopped target Default. Mar 18 23:01:01 rawhide systemd[577]: Stopping Basic System. Mar 18 23:01:01 rawhide systemd[577]: Stopped target Basic System. Mar 18 23:01:01 rawhide systemd[577]: Stopping Paths. ... I suggest you stop blaming systemd for your own administrative incompetence i suggest you get rid of that arrogance and some other developers too because it's the reason for the subject and proves that you *do not* care about users as long you have not the same opinion you are the one demanding a friendly tone from me, well, than practice what you preach or stop whining if someone calls you names the next time who do you think you are to assess others incompetence? and broken implementation of rsyslog and syslog-ng in Fedora (I tried to get it fixed before we defaulted to journal YES IT WAS BROKEN BEFORE AND STILL IS but was not allowed to do so thank those Red Hatters in the governing body's of Fedora ( FESCO/FPC ) for it's brokeness) just don't create messages the majority of users don't want and need to see until debugging and even systemd needs to realize that the world is not turning around it and write an rsyslog template suited for your environment which will filter things to your liking and expectation or better yet complain to those FESCO/FPC members since they need to learn a hard lesson of accepting responsibility for their own actions in the distribution who do you think you are? that arrogance and pure ignorance is the reason for subject and related websites as well as for users from time to time not complaining as nice as you would like it hence fedora devel CC'ed __ here the relevant links you decided to strip out and replace with your arrogant abuse as you always do if someone has a differnt opinion but demand from others not act the same way here you have a simple calculation https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c8 why don't you look at https://bugzilla.redhat.com/show_bug.cgi?id=1072368 and the workaround loginctl enable-linger leads to another bugreport open for months: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Hi, On 22/09/14 15:58, Reindl Harald wrote: Am 22.09.2014 um 14:44 schrieb Jóhann B. Guðmundsson: Then file a bug report against rsyslog and provide a patch which fixes the default log filtering in Fedora to your expectation but leave systemd out of it. wow - in any other case the systemd developers saying that they don't workround things because problems has to be solved at the root-cause - practice what you preach and make the log-verbosility configureable! Serves no purpose whatsoever doing that. Could you elaborate? As generating 8 lines of log seems a bit excessive (seems in one bug which is linked it is rather a calculationg). I would definitly classify that as a bug. (It could for example keep a cpu or system from sleeping, thus draining more power). Anyway usually less debug is better as it is more obvious where a problem might be imho. Of course it is always a question about finding a balance. * rsyslog is *not* responsible for the message flood produced by systemd No but it is responsible for the filtering -- of log messages. * systemd is the one producing it without prefixes it is ridiculous to have the need of filtering This is simply untrue as journalctl -o export will show you. where is it in the message? the process is systemd Instead of blaming someone for being incompetent you could just have given the solution. Especially as you mentioned you knew something like that might happen but blamed Red Hat for not implementing a potential fix. Which you could have even documented and somebody could have found googling for it. That would have saved time for everybody involved. Although from what I know I rather agree there is a bug in systemd. You also seem to forget systemd adds a lot of layers of complexity that just did not exist with the old init. It makes it a lot harder to find out what is going on (despite all the available documentation). So if the prefix does not show in an obvious manner I could categorize that as a bug too. In this case it might actually make sense to have a different prefix as it will clearly indicate user vs system session. Also despite the loglevels available in journald. It is unclear from the documentation how the classification gets done http://www.freedesktop.org/software/systemd/man/journald.conf.html Maybe for our problem MaxLevelSyslog=err might work? But how do we know it won't suppress certain messages we would like to see and actually suppresses the one we don't want? Regards, Philippe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On 09/22/2014 12:58 PM, Reindl Harald wrote: i suggest you get rid of that arrogance and some other developers too because it's the reason for the subject and proves that you *do not* care about users as long you have not the same opinion you are the one demanding a friendly tone from me, well, than practice what you preach or stop whining if someone calls you names the next time who do you think you are to assess others incompetence? I think I'm the one based on your own actions as in after you cant even take your time to a read upstream rsyslog documentation then insert a single line of filtering in rsyslog, similar or equivalent of :programname, isequal, systemd -/var/log/systemd.log to filter out systemd message from /var/log/message or fine tune the filtering through the use of rsyslog templates and submit that as a patch against rsyslog in Fedora so the distribution can improve it's default filtering in rsyslog based on your input but instead choose to file gazillion bug reports against systemd which has nothing to do with the text file filtering in the distribution, clutter the comment sections with useless output in those bug reports to prove your point over and over again and call the lead developer of the project an idiot in one of those reports then show up upstream cursing and demanding fixes saying that systemd message cant be filtering even thou I pointed to journalctl -o export which shows all the messages fields each log contains including all the syslog entries which should provide an capable administrator pleathora of ideas how to filter message in conjunction with rsyslog powerful filtering capabilities and all that rant for something that is not our to fix in the firstplace. 1. https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
From: Jóhann B. Guðmundsson Did you ever ask yourself why your project provokes that amount of resistance and polarity? Did you ever ask yourself whether this really is just resistance against anything new from people who just do not like new or whether it contains*valuable* and*important* feedback? I'm not sure why you are under the assumption that we do not consider and have not and are not gathering feedback from individuals, communities or companies for that matter but I'm going to address your questions anyway. I've brought a complaint about one of systemd's behaviors here. I have gotten useful feedback allowing me to refine what I think would be a good solution to the problem. What I *haven't* gotten is any useful feedback on how to implement a solution. I suspect others have had similar experiences. One metric that might be useful is to ask: Of the people who complain about one or another aspect of systemd, what fraction ultimately consider their complaint to be satisfactorily resolved? There are also architectural issues about systemd that I've noticed. I don't know to what degree these indicate quality control problems with the code, or whether they are just a matter of things being done in ways that are not common in the Un*x universe. But they do seem to me to be things that are going to inhibit adoption. 1. Systemd has some very large binaries, each of which implements many aspects of the system. Conversely, the typical Un*x approach is to separate functions into many executablels, many of which are scripts. The latter approach makes customization easier, especially for sysadmins who aren't deeply familiar with the system. 2. Systemd includes a tremendous number of features and behaviors, but a lot of them aren't documented very well. That's not so unusual in Un*x, but if you're introducing something new, nobody has any prior knowledge of it, and the lack of documentation becomes visible. Ultimately, writing e-mail messages saying They're wrong is useless, even if they *are* wrong. If there is a substantial body of people out there who dislike systemd, it's going to prevent its adoption. The fix is adjusting systemd (or the project surrounding it) so that people like it better. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On 22/09/14 10:23, Reindl Harald wrote: honestly the messages about reaching target are nonsense without a prefix pointing out that it is about a *user session* because it looks like a bootlog every minute You can tell this is not the system instance of systemd (init) because its process ID is 1. systemd[1] indicates the system instance, systemd[anything else] is a user instance. This might be a useful basis for a filter. Configuring a higher (more severe) LogLevel in /etc/systemd/user.conf would probably also help in your situation. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am 22.09.2014 um 16:41 schrieb Simon McVittie: On 22/09/14 10:23, Reindl Harald wrote: honestly the messages about reaching target are nonsense without a prefix pointing out that it is about a *user session* because it looks like a bootlog every minute You can tell this is not the system instance of systemd (init) because its process ID is 1. systemd[1] indicates the system instance, systemd[anything else] is a user instance. This might be a useful basis for a filter. first: thank you for a normal answer instead shut up and go away if you take that as decision for drop messages you have several problems * drop anything from systemd with PID != 1 will also affect future things nobody knows now and not related to user-sessions and so not happening every minute caused by cron * it is wasting of ressources for produce *and* filter the messages Configuring a higher (more severe) LogLevel in /etc/systemd/user.conf would probably also help in your situation why is it refused with such a vehemence to consider make default loggings not that verbose in general and act like many other software packages: configured log levels with non verbose defaults * informational * warning * error * fatal error the goal should not be produce a growing amount over the time and then force users how to filter it away - it should not be produced (produce and filter both taking ressources) the relevant information New session started was already produced by systemd-logind before introduce the new verbose log and that was easy to direct to /var/log/secure because the process name the normal user cares about * started * no error logged * ended but not about more details until something needs debugging which is unusual as long you are not a systemd-developer signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, Sep 22, 2014 at 2:44 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 09/22/2014 12:07 PM, Reindl Harald wrote: Am 22.09.2014 um 13:45 schrieb Jóhann B. Guðmundsson: On 09/22/2014 11:40 AM, Reindl Harald wrote: Am 22.09.2014 um 13:28 schrieb Jóhann B. Guðmundsson: On 09/22/2014 09:23 AM, Reindl Harald wrote: Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson: The reason for increased log entries in the journal is that more things are happening now since this is what happening when a job is run. that don't change the fact that a user not acting as systemd-developer and not debugging his system don't need that flood I guess we have different meaning of message flood again: we talk about rsyslog, like it or not Then file a bug report against rsyslog and provide a patch which fixes the default log filtering in Fedora to your expectation but leave systemd out of it. wow - in any other case the systemd developers saying that they don't workround things because problems has to be solved at the root-cause - practice what you preach and make the log-verbosility configureable! Serves no purpose whatsoever doing that. * rsyslog is *not* responsible for the message flood produced by systemd No but it is responsible for the filtering -- of log messages. * systemd is the one producing it without prefixes This is simply untrue as journalctl -o export will show you. I suggest you stop blaming systemd for your own administrative incompetence and broken implementation of rsyslog and syslog-ng in Fedora Please let's not stoop to this level of name-calling. I haven't followed this debate in detail, so I don't know how this should be solved, but it seems fair to say that Harald's experience is suboptimal, so let's focus on making constructive suggestions for how journald/rsyslog or the local/distro config could be improved, rather than who is to blame. Anyway, I think this is decidedly off-topic for this thread, so please move this elsewhere. Cheers, Tom ( I tried to get it fixed before we defaulted to journal YES IT WAS BROKEN BEFORE AND STILL IS but was not allowed to do so thank those Red Hatters in the governing body's of Fedora ( FESCO/FPC ) for it's brokeness ) and write an rsyslog template suited for your environment which will filter things to your liking and expectation or better yet complain to those FESCO/FPC members since they need to learn a hard lesson of accepting responsibility for their own actions in the distribution. You can find how to write an rsyslog template in the upstream rsyslog documentation using it's powerful filtering capabilities and by looking at for example the one spice-vdagentd /etc/rsyslog.d/spice-vdagentd.conf in Fedora. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On 22 September 2014 15:16, Dale R. Worley wor...@alum.mit.edu wrote: 2. Systemd includes a tremendous number of features and behaviors, but a lot of them aren't documented very well. That's not so unusual in Un*x, but if you're introducing something new, nobody has any prior knowledge of it, and the lack of documentation becomes visible. It's maybe not so unusual in *nix, globbed to include Linux and starting in the past decade, but is unusual in Unix. When I started on Linux it was still possible to use all that documentation (http://www.opengroup.org/ was massively useful) and I spent quite some time understanding Posix standards and how things fitted together. You could teach yourself how to programme, use cron, administer the system, from man pages. -- imalone http://ibmalone.blogspot.co.uk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Sun, Sep 21, 2014 at 3:31 PM, Martin Steigerwald mar...@lichtvoll.de wrote: I just have one question. In the light of http://boycottsystemd.org/ Please note that this is just (to the best of my knowledge), the misinformed rants of an anonymous individual (despite it appearing a lot more serious due to the guy buying a domain). http://uselessd.darknedgy.net/ Hm, missing content? Debian Bug report logs - #746715 the foreseeable outcome of the TC vote on init systems https://bugs.debian.org/bug=746715 this package no longer exists ? Did you ever ask yourself why your project provokes that amount of resistance and polarity? Did you ever ask yourself whether this really is just resistance against anything new from people who just do not like new or whether it contains *valuable* and *important* feedback? We occasinoally got some very critical feedback that is also very good. However, when you look at the various debates in other forums (such as the ones you mentioned), my impression is that it is almost entirely useless noise. I.e., either people are complaining about things that are based entirely on misconceptions, or they are complaining about things that had a root in something reasonable once upon a time, but have long since been either explained or fixed. I am taking this upstream with you, cause I think too much of this is resignately been discussed elsewhere, discussed elsewhere for as I got the feedback on various occasions where I recommended to take feedback upstream that people have no hope in having their feedback considered at all. If people bring useful and at least moderately civil feedback upstream (i.e., technical feedback in terms of bug reports, questions, RFE's or similar, not rants amounting to please stop what you are doing and go away), we do take it very seriously, and answer them to the best of our abilities. That does not mean that every patch is accepted, nor every request is adhered to, but at least you should get an answer with an explanation. The only way to find out is to try though. For now I use systemd. I like quite some features. But on the other hand I am vary about it myself. I look at a 45 KiB binary for /sbin/init as PID1 and a 1,3 MiB binary in systemd 215 and wonder myself. systemd is a lot more powerful than sysvinit, and does take up more space. We are not really optimizing the size of the binary, so if you are interested in looking into making it smaller that's certainly possible. I see systemd --user processes running and wonder: Why does the user related stuff need to be in the systemd binary. This is rather the other way around: the problem solved by PID1, is almost entirely the same as the problem that needs to be solved by the user session manager, so we allow the same code to be reused. The amount of code specific to user sessions in PID1 is really very small. I had it that it didn´t mount an NFS export and while in the end it was a syntax error in fstab that sysvinit happily ignored, I needed a bug report and dev help to even find that cause. I wonder about the complexity involved in one single large binary. PID1 does not parse your fstab, it is done by an external binary. That said, if there is a lack of output when a malformed entry is found, we should probably improve on that (I don't have the bug report in front of me, but please open an RFE if you think this is still not ideal). The reason we reject invalid fstab entries, is that we think it is safer to fail hard if we cannot know for certain what the admin intended to do. It is regrettable that this means that the transition is not as smooth as it otherwise would be, but overall we believe it is the correct thing to do. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, Sep 22, 2014 at 12:52 AM, Tom Gundersen t...@jklm.no wrote: On Sun, Sep 21, 2014 at 3:31 PM, Martin Steigerwald mar...@lichtvoll.de wrote: http://uselessd.darknedgy.net/ Hm, missing content? Apparently someone attacked and wiped their website. It's mostly a trimmed-down systemd fork: https://bitbucket.org/bcsd/uselessd (or slashdot, phoronix, etc.) Debian Bug report logs - #746715 the foreseeable outcome of the TC vote on init systems https://bugs.debian.org/bug=746715 this package no longer exists ? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746715 -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
2014-09-21 23:52 GMT+02:00 Tom Gundersen t...@jklm.no: On Sun, Sep 21, 2014 at 3:31 PM, Martin Steigerwald mar...@lichtvoll.de wrote: I had it that it didn´t mount an NFS export and while in the end it was a syntax error in fstab that sysvinit happily ignored, I needed a bug report and dev help to even find that cause. I wonder about the complexity involved in one single large binary. PID1 does not parse your fstab, it is done by an external binary. That said, if there is a lack of output when a malformed entry is found, we should probably improve on that (I don't have the bug report in front of me, but please open an RFE if you think this is still not ideal). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755506#25 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On 09/21/2014 01:31 PM, Martin Steigerwald wrote: in the light of the ongoing discussions on linux-kernel Could you provide a link to that ongoing discussion that is taking place in the kernel community regarding systemd? Did you ever ask yourself why your project provokes that amount of resistance and polarity? Did you ever ask yourself whether this really is just resistance against anything new from people who just do not like new or whether it contains*valuable* and*important* feedback? I'm not sure why you are under the assumption that we do not consider and have not and are not gathering feedback from individuals, communities or companies for that matter but I'm going to address your questions anyway. Have we ever asked ourselves why our project provokes that amount of resistance and polarity? The answer to that question is yes, yes we have and yes we will continue to do so since resistance and polarity provides with the valuable information amongst other things if the implementation is bad and alternative approach is better ( which often reveals itself at the same time those friction take place ). Dont get me wrong we will not do so when those discussion involve nothing but personal attack on our community member(s) which more often than not happens to be Lennart, Lennart is and never has been the sole person behind this effort, he's part of ever growing community. Nor when it involves us having to implement somekind of hack as opposed to have the problem properly fixed where it belongs ( which could be us or not ) or when those discussion criticizes that we have chosen to tightly integrate ourselves specifically to the linux kernel it's ecosystem and with glibc in mind just like bsd based distribution as well as solaris and other nixes are tightly integrating their components to their kernels but for some dumbfound reason people on the internet are under the assumption that they have the authority of refusing us the freedom of doing the same o_O and the answer to those individuals we dont care about their opinion on this matter. Now alot of the resistance and polarity that is taking place like in the url you pointed at is hiding itself behind their misinterpretation of the so called Unix philosophy and claiming that we somehow fall short on the guidelines originates from few things Doug McIlroy,Rob Pike,Ken Thompson said sometime in the 70's or rather the Unix philosophy was implied not by what these individuals said but rather by what they did which more or less boils down to this.. 1. Write simple parts connected by clean interfaces. 2. Clarity is better than cleverness. 3. Design programs to be connected to other programs. 4. Separate policy from mechanism; separate interfaces from engines. 5. Design for simplicity; add complexity only where you must. 6. Write a big program only when it is clear by demonstration that nothing else will do. 7. Rule of Transparency: Design for visibility to make inspection and debugging easier. 8. Robustness is the child of transparency and simplicity. 9. Fold knowledge into data so program logic can be stupid and robust. 10. In interface design, always do the least surprising thing. 11. When a program has nothing surprising to say, it should say nothing. 12. When you must fail, fail noisily and as soon as possible. 13. Programmer time is expensive; conserve it in preference to machine time. 14. Avoid hand-hacking; write programs to write programs when you can. 15. Prototype before polishing. Get it working before you optimize it. 16. Distrust all claims for “one true way”. 17. Design for the future, because it will be here sooner than you think. Now after you have read these more of an guidelines than actual philosophy I would like to hear from you where you think systemd has and is falling short of them during it's development phase and lifetime so I can better understand why people seem to be claiming it's not following these guidelines? That being said acceptance and approval are outweighing resistance and polarity in the Linux ecosystem as things currently stand ( otherwise we would not be so widely accepted and adopted ) because we are and continue to solve real problems through close collaboration with wide variety of upstream and distribution, In the long run freeing up contributors time while doings so through the consolidation that takes place while we are at it. If you are wondering as well if we are against emerging alternative init system like the one you refereed to, the answer to that question is no we are not. We welcome and embrace them and hope they evolve to the point they become competing solution so we can continue to evolve ourselves ( or advance beyond us and eventually replace us ) but being frank that wont happen anytime soon. Systemd has been what ca 7 years in the making now with what 5 of those years being direct integration with wide variety of components and
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am 22.09.2014 um 00:15 schrieb Jóhann B. Guðmundsson: Now alot of the resistance and polarity that is taking place like in the url you pointed at is hiding itself behind their misinterpretation of the so called Unix philosophy and claiming that we somehow fall short on the guidelines originates from few things Doug McIlroy,Rob Pike,Ken Thompson said sometime in the 70's or rather the Unix philosophy was implied not by what these individuals said but rather by what they did which more or less boils down to this.. 11. When a program has nothing surprising to say, it should say nothing then flood logs with nothing relevant should not happen https://bugzilla.redhat.com/show_bug.cgi?id=1072368 https://bugzilla.redhat.com/show_bug.cgi?id=1053315 appeared the first time: 2014-01-14 reported: 2014-03-04 refused to fix: 2014-03-24 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On 09/21/2014 10:23 PM, Reindl Harald wrote: Am 22.09.2014 um 00:15 schrieb Jóhann B. Guðmundsson: Now alot of the resistance and polarity that is taking place like in the url you pointed at is hiding itself behind their misinterpretation of the so called Unix philosophy and claiming that we somehow fall short on the guidelines originates from few things Doug McIlroy,Rob Pike,Ken Thompson said sometime in the 70's or rather the Unix philosophy was implied not by what these individuals said but rather by what they did which more or less boils down to this.. 11. When a program has nothing surprising to say, it should say nothing then flood logs with nothing relevant should not happen https://bugzilla.redhat.com/show_bug.cgi?id=1072368 https://bugzilla.redhat.com/show_bug.cgi?id=1053315 ? I dont see the connection here systemd is informing you what start/stopped when these cron job ran. If you dont like it filter it and retrieve only the information you want/need with journalctl. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Am 22.09.2014 um 00:48 schrieb Jóhann B. Guðmundsson: On 09/21/2014 10:23 PM, Reindl Harald wrote: Am 22.09.2014 um 00:15 schrieb Jóhann B. Guðmundsson: Now alot of the resistance and polarity that is taking place like in the url you pointed at is hiding itself behind their misinterpretation of the so called Unix philosophy and claiming that we somehow fall short on the guidelines originates from few things Doug McIlroy,Rob Pike,Ken Thompson said sometime in the 70's or rather the Unix philosophy was implied not by what these individuals said but rather by what they did which more or less boils down to this.. 11. When a program has nothing surprising to say, it should say nothing then flood logs with nothing relevant should not happen https://bugzilla.redhat.com/show_bug.cgi?id=1072368 https://bugzilla.redhat.com/show_bug.cgi?id=1053315 ? I dont see the connection here systemd is informing you what start/stopped when these cron job ran with *that many* lines? that information already exists in /var/log/secure and /var/log/cron these lines are completly useless for a non-developer consider that not refuse that often what a user wants to see or not to see *as default* because as developer you have other needs is one of the reasons *endusers* get sometimes really angry If you dont like it filter it and retrieve only the information you want/need with journalctl if they would have a prefix i would filter them to nowhere in rsyslog please understand that not everybody is using journalctl and if it is only because using centralized logs in databases since long before systemd was introduced signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On 09/21/2014 11:09 PM, Reindl Harald wrote: Am 22.09.2014 um 00:48 schrieb Jóhann B. Guðmundsson: On 09/21/2014 10:23 PM, Reindl Harald wrote: Am 22.09.2014 um 00:15 schrieb Jóhann B. Guðmundsson: Now alot of the resistance and polarity that is taking place like in the url you pointed at is hiding itself behind their misinterpretation of the so called Unix philosophy and claiming that we somehow fall short on the guidelines originates from few things Doug McIlroy,Rob Pike,Ken Thompson said sometime in the 70's or rather the Unix philosophy was implied not by what these individuals said but rather by what they did which more or less boils down to this.. 11. When a program has nothing surprising to say, it should say nothing then flood logs with nothing relevant should not happen https://bugzilla.redhat.com/show_bug.cgi?id=1072368 https://bugzilla.redhat.com/show_bug.cgi?id=1053315 ? I dont see the connection here systemd is informing you what start/stopped when these cron job ran with *that many* lines? The reason for increased log entries in the journal is that more things are happening now since this is what happening when a job is run. that information already exists in /var/log/secure and /var/log/cron these lines are completly useless for a non-developer Irrelevant to us what is stored in text files so that needs to be handled downstream. consider that not refuse that often what a user wants to see or not to see *as default* because as developer you have other needs is one of the reasons *endusers* get sometimes really angry Depends on personal preference and practices Cron users already are divided into two religious notification groups. Those that have cron job that send email that notifies every time that it ran ( to know it ran ) and those that do not send an email unless the job it was running failed and rely on logwatch to inform them if the cron job ran or not. If you dont like it filter it and retrieve only the information you want/need with journalctl if they would have a prefix i would filter them to nowhere in rsyslog please understand that not everybody is using journalctl Well this is upstream that ships nothing but journalctl whether they use it or not. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Sun, 2014-09-21 at 15:31 +0200, Martin Steigerwald wrote: Did you ever ask yourself why your project provokes that amount of resistance and polarity? Did you ever ask yourself whether this really is just resistance against anything new from people who just do not like new or whether it contains *valuable* and *important* feedback? I think that in general the existence of significant amounts of resistance is explained by opposition to anything new. Systemd changes many things, and as distros won't keep support for sysvinit at the same time, people can't easily keep using the old stuff they're used to. That's enough to explain complaints, and their existence does not by itself mean there would be anything wrong with systemd. For now I use systemd. I like quite some features. But on the other hand I am vary about it myself. I look at a 45 KiB binary for /sbin/init as PID1 and a 1,3 MiB binary in systemd 215 and wonder myself. Sysvinit as PID 1 lacks many essential things, so that is not a valid size comparison (and just having the code running with a PID other than 1 is not an improvement). In general, any complaints about the size/bloat of PID 1 are rather silly if you still use it with the Linux kernel, which contains a lot more code in a more central role than PID 1. I had it that it didn´t mount an NFS export and while in the end it was a syntax error in fstab that sysvinit happily ignored, I needed a bug report and dev help to even find that cause. I wonder about the complexity involved in one single large binary. I think this works as an example of how change leads to people complaining, completely unrelated to the existence of any actual quality issues. Sysvinit behavior or debuggability wrt mount issues was not better than systemd is, much less by so much that this would illustrate any general issue with systemd (that's not to say that systemd diagnostics could not be improved). Yet because you were first familiar with sysvinit and had created dubious configuration which happened to work with it, you now feel this is a problem in systemd, just because things have changed. Someone who started with systemd and used it for years before encountering sysvinit would hit a lot more problems. Well… its not about my thoughts about systemd, it is about my perception that I never seen any free software upstream project creating this amount of polarity and discussion in a decade or more. I don't think the reactions to systemd are in any way unique. I've seen similar reactions to other changes. The difference in the systemd case is that a lot of developers interact with the init system at least on a superficial level, and init system choice is mostly done on the distro level, so people can't easily ignore systemd and keep using their old software. That increases the volume of the complaints. Is it really all just nay-sayers for the sake of nay-saying? Or do they – at least partly – provide *valuable* and *important* feedback. nay-sayers as in people who oppose the adoption of systemd because they think that some alternative is less flawed tend to have no clue. You're more likely to get *valid* criticism from people who are at least competent enough to recognize that whatever problems systemd has, the alternatives are worse. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
