Bug#727708: On diversity
Uoti Urpala dixit: They have had an overall negative effect on people working on Linux within Debian and people creating derivatives. Besides what Russ said: Debian isn’t about Linux. Debian is the universal operating system. bye, //mirabilos -- 18:47⎜mirabilos:#!/bin/mksh well channels… you see, I see everything in the same window anyway 18:48⎜xpt:#!/bin/mksh i know, you have some kind of telnet with automatic pong 18:48⎜mirabilos:#!/bin/mksh haha, yes :D 18:49⎜mirabilos:#!/bin/mksh though that's more tinyirc – sirc is more comfy -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1401170846190.9...@herc.mirbsd.org
Bug#727708: init system thoughts
On 31 December 2013 12:55, Colin Watson cjwat...@debian.org wrote: The criticisms of Upstart's event model in the systemd position statement simply do not make sense to me. Events model how things actually happen in reality; dependencies are artificial constructions on top of them, and making them work requires the plethora of different directives in systemd (e.g. Wants, which is sort of a non-depending dependency) to avoid blocking the boot process on a single failing service. Riffing off this more than replying to it. I tend to think dependencies and events are both useful ways of describing when to start up parts of the system. In particular, it seems like: - when a network is connected, start web server - when a usb disk is connected, mount it - when a VPN is started, sync various things are best described by an event model, while: - in order to run GNOME, logind must be started - in order to run logind, dbus must be available - as part of making the system ready for a user, network-manager should be running make the most sense when described by dependencies. In particular, in many of those cases, the reverse might not be true: For debugging, I might want to start the web server manually without connecting the network; or I might want logind running without GNOME, or network-manager running without the other parts of my desktop environment. Events and dependencies aren't that different; an event essentially lets a service X say that: whenever Y happens, X happens whenever Y happens, X stops happening while a (systemd'ish) dependency says either: when X happens, Y happens as well[X Requires: Y] before X happens, Y happens as well [X Requires: Y, After: Y] after X happens, Y happens as well [X Requires: Y, Before: Y] (with Wants and Requisite and Overridable variants as well; also RequiredBy and WantedBy variants) If you look at Y, there are a few phases it could go through: no-Y Y-starts-starting Y-started Y-begins-ending no-Y If you wanted to emulate upstart events with dependencies, you'd need to do four things, I think: * create a dummy Y-started-event unit [network-is-available, usb-is-available] * invoke systemctl start Y-started-event when Y is finished starting * invoke systemctl stop Y-started-event when Y begins ending * add RequiredBy: Y-started-event and PartOf: Y-started-event to X's unit file That seems reasonably straight forward to me? If the event is something systemd already knows about, you might only need to do something equivalent to the last step. I don't think invoking systemctl start/stop is any better or worse than whatever would be needed to notify upstart of the same events. To emulate systemd dependencies in an event model (ie, X depends on Y), you'd need to do either: * change Y's job to say start on starting X * add stop on stopping Y to X's job description or * add a pre-start script to X in order to start Y first * add stop on stopping Y to X's job description The latter looks like it's the documented way of doing things. Neither of those seem particularly great -- I think that's due to upstart not letting you reverse event descriptions in the same way that systemd has Requires/RequiredBy statements. If you could say: * on starting start Y * stop on stopping Y in X's job description, by contrast, I think that would be a fine way of declaring a dependency from X to Y without leaving the event model. Not having a simple way of specifying this sort of dependency seems pretty weak on upstart's behalf. It would probably also be nice to have a way of saying when a new network comes up, reload/refresh service X -- so that it could bind to new ports or whatever even if it was already running; that seems like the sort of thing that would be easier to specify in an event model (on new-network-interface-started reload or start), than in a dependency model. Cheers, aj -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJS_LCUGaM6JS8Ec-73z30+_h8yW+HqSqfqVvHVh=ykpqn+...@mail.gmail.com
Bug#727708: On diversity
On Fri, Jan 17, 2014, at 1:45, Uoti Urpala wrote: On Thu, 2014-01-16 at 17:52 +, Ian Jackson wrote: * Debian is a forum for cooperation and technical development. * Debian, as a piece of software, tries to be all things to all people (within reason). This flexibility and tolerance for divergence has made Debian an extremely attractive target for everyone to work within, work on, and derive from. I think it has been key to the success of the project. I think the divergence has gone too far in things like non-Linux ports. They have had an overall negative effect on people working on Linux within Debian and people creating derivatives. Could you please state your affiliation with Debian and the real work you have done on Linux within Debian? All I have seen and can find from you is the flaming in the lists. So I suggest that unless you do a work within Debian you should not voice your opinions for other Debian Developers. E.g. speak about yourself and not about people. You are not the voice of the people and definitely not a voice of Debian people. Preferably just refrain from adding more of *your* opinions into this bug report. Thank you, -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1389950502.25931.71910613.5d55a...@webmail.messagingengine.com
Bug#727708: piuparts sadly does not test init scripts^w^wdaemon starting (Re: Bug#727708: Bits from linux.conf.au)
Hi, On Donnerstag, 16. Januar 2014, Anthony Towns wrote: it's not realistic for a porter to continously test startup scripts for thousands of packages. It's reasonable to semi-continuously test installation scripts for thousands of packages -- that's what piuparts does, and we have sponsored cloud resources to support that. It seems like that would be fairly straightforward to duplicate for testing packages with alternative init systems. piuparts has /sbin/policy.rc.d in place with the content of exit 0, IOW, it does not execute init scripts at all. Running, monitoring and killing arbitrary daemons is not trivial. Help and patches welcome! :-) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#727708: piuparts sadly does not test init scripts^w^wdaemon starting (Re: Bug#727708: Bits from linux.conf.au)
On Fri, Jan 17, 2014 at 12:05:22PM +0100, Holger Levsen wrote: Hi, On Donnerstag, 16. Januar 2014, Anthony Towns wrote: it's not realistic for a porter to continously test startup scripts for thousands of packages. It's reasonable to semi-continuously test installation scripts for thousands of packages -- that's what piuparts does, and we have sponsored cloud resources to support that. It seems like that would be fairly straightforward to duplicate for testing packages with alternative init systems. piuparts has /sbin/policy.rc.d in place with the content of exit 0, IOW, it does not execute init scripts at all. Running, monitoring and killing arbitrary daemons is not trivial. Indeed. Early on in my original development of piuparts I realised that testing, in a chroot, code that starts arbitrary daemons is a bad idea in oh so many ways. I haven't followed piuparts development in recent years, so I don't know if it still uses chroot, but unless it's started using containers or virtual machines, it should continue to NOT allow init.d scripts to run. At all. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140117111506.gd5...@mavolio.codethink.co.uk
Bug#727708: init system thoughts
On Fri, Jan 17, 2014 at 12:50 AM, Anthony Towns a...@erisian.com.au wrote: On 31 December 2013 12:55, Colin Watson cjwat...@debian.org wrote: The criticisms of Upstart's event model in the systemd position statement simply do not make sense to me. Events model how things actually happen in reality; dependencies are artificial constructions on top of them, and making them work requires the plethora of different directives in systemd (e.g. Wants, which is sort of a non-depending dependency) to avoid blocking the boot process on a single failing service. Riffing off this more than replying to it. I tend to think dependencies and events are both useful ways of describing when to start up parts of the system. In particular, it seems like: - when a network is connected, start web server - when a usb disk is connected, mount it - when a VPN is started, sync various things are best described by an event model, while: - in order to run GNOME, logind must be started - in order to run logind, dbus must be available - as part of making the system ready for a user, network-manager should be running You could express that as an event because GNOME and logind communicate with logind and dbus (respectively) through IPC. So you can say when GNOME tries to use logind's dbus interface, start logind, or you can say when //anything// tries to use logind's dbus interface, start logind and have that done for. Same for starting dbus, just change a dbus interface to dbus's port. make the most sense when described by dependencies. In particular, in many of those cases, the reverse might not be true: For debugging, I might want to start the web server manually without connecting the network; or I might want logind running without GNOME, or network-manager running without the other parts of my desktop environment. With the above method, this problem is avoided because GNOME does not start when logind starts, it just starts whenever the runlevel is right and then logind is started automatically. So if GNOME is stopped/waiting, you can start logind without GNOME starting. -- Cameron Norman
Bug#727708: Init system resolution open questions
Tollef Fog Heen writes (Bug#727708: Init system resolution open questions): [Ian Jackson]: As I mentioned on IRC, I think we need to get some clear answers to certain questions from everybody. It's not clear to me that the CTTE is allowed to rule on a bunch of those questions, especially the RC bug ones seem to directly contradict both 6.3.5 and 6.3.6 in the constitution. The release team is the team that sets RC policies and I'm not aware of any failed attempts at arriving at a consensus with them or that they've delegated the decision to the CTTE. Under the circumstances I think it would be appropriate for the committee to give appropriate advice. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21209.9915.754706.115...@chiark.greenend.org.uk
Bug#727708: Init system resolution open questions
Adrian Bunk writes (Re: Bug#727708: Init system resolution open questions): (Only as a PM since I am repeating myself.) Thanks for your mail. I think it deserves wider consideration. One question you should consider adding: * What switching between init systems has to be supported? Should it be possible for the user to switch from one supported init system to another supported init system at any point (it is OK if that requires a reboot), or is it acceptable if that is not possible in all cases or even not at all? It seems obvious to me that if multiple ones are supported that there has to be some way to get from using one to using a different one. So the question is more one of how difficult it is. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21209.10085.305.266...@chiark.greenend.org.uk
Bug#727708: OpenRC now works on GNU/Hurd! :)
On 2014-01-17 20:41:59 +0800, Thomas Goirand wrote: On the Thu, 16 Jan 2014 17:18:24 +0100, Josselin Mouette j...@debian.org wrote: This assumes that OpenRC can be fixed to have parallel boot, otherwise this is a big regression from the current insserv setup. This is just plain wrong, OpenRC perfectly supports parallel booting, it's just that the output on the screen is very ugly for the moment (that as well can be fixed, I suppose). Parallel booting also breaks output with sysv-rc. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140117125119.gc4...@ypig.lip.ens-lyon.fr
Bug#727708: Init system resolution open questions
]] Ian Jackson Tollef Fog Heen writes (Bug#727708: Init system resolution open questions): [Ian Jackson]: As I mentioned on IRC, I think we need to get some clear answers to certain questions from everybody. It's not clear to me that the CTTE is allowed to rule on a bunch of those questions, especially the RC bug ones seem to directly contradict both 6.3.5 and 6.3.6 in the constitution. The release team is the team that sets RC policies and I'm not aware of any failed attempts at arriving at a consensus with them or that they've delegated the decision to the CTTE. Under the circumstances I think it would be appropriate for the committee to give appropriate advice. You're of course free to give advice. My point was that it's not binding (you can't rule on it). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874n52raeu@qurzaw.varnish-software.com
Bug#727708: Spotify position in support of systemd in the default init debate
Friends, Spotify, an online streaming music service, is a significant user of Debian GNU/Linux. We have some 5000 physical servers and well over a thousand virtual servers using both public and private clouds running Debian GNU/Linux serving millions of songs to our users every day. We would like to take this opportunity to endorse systemd as our preferred init system and we would like to see it as default on Debian GNU/Linux moving forward. Our main reasons for this preference: - We believe that the dependency model of systemd is easier to understand, explain and work with than the event based counterpart of upstart. - We believe that the various features built on top of the way systemd uses cgroups, notably mechanisms for resource limitations, would be very useful in a highly scalable highly available environment such as ours. - We believe that systemd will have the stronger community momentum moving forward when it comes to seeing close integration between modern init system features and upstream projects. With kind regards Spotify infrastructure and operations via Noa Resare, Free Software ombudsman
Bug#727708: On diversity
Uoti Urpala wrote: Even the upstart proponents do not seem to have significant arguments about upstart having better functionality, and there don't seem to be all that many people who would have a reasonably informed opinion that upstart would be technically better even for just their particular use. I followed the discussion from the beginning and I'd like to comment on that. My own comparison of systemd vs. upstart (Fedora 20 vs. Ubuntu 13.10) is still fresh in my memory. Though I do not have strong personal preference for one or another, the Ubuntu (as an OS based on upstart) left much much better impression than the Fedora (as an OS based on systemd). Looking at the both of them over period of two days showed several cardinal differences. I'll narrow it down to three, first one addressing what's better in upstart?. 1. upstart is a highly configurable init system, while systemd hardcodes most of the nuts and bolts in the 32 shipped executables. I spent one days going through the upstart's setup on Ubuntu: lots of stuff, lots of non-trivial inter-connections. I needed only two hours to review systemd setup. Because every interesting and important bit was just a call of the special systemd binary. Most (but not all) of the special binaries have man pages, but only few of the helper binaries actually provide any customization capability. Again: systemd on Fedora 10 is compromised of more than *30* binaries (not counting: systemd binary itself, the generators and the admin utilities). So here you go. The advantage of the upstart, is that if you need to tweak the boot of your system, you can do it right there, with the text editor, by changing the .conf files or the shell scripts. While with the systemd, you have to patch the sources, recompile and reinstall. Because literally everything is hardcoded in some special systemd binary. (Coming from the embedded systems, to me personally that is a biggie.) 2. upstart was not designed or intended to be a SMF (service management facility), while systemd was. I think it is insincere of upstart proponents to even advertise it as such. On Ubuntu, upstart effectively ends its work by calling the `/etc/init.d/rc $RUNLEVEL`. (What IMO means it might make sense to look into integration of upstart with OpenRC. Orthogonality of the two should mean few conflicts.) On the other side of the fence. As I see it, it is only a coincidence that systemd is also an init system. To me it was clearly designed from ground up as SMF: boot and initialization were only afterthought. That's why the magic binaries, because the initialization, an event driven process, simply doesn't fit into the systemd everything is a service model. 3. Boot times. Though systemd was supposed to improve the boot time, Fedora 20 VM on my rig needs 1m5s-1m15s to start - while Ubuntu 13.10 VM always timed flat 0m35s. That was pretty dumbfounding realization, especially after finding that Fedora has only few sysvinit scripts - and Ubuntu has almost all services started by the sysvinit shell scripts. Summary. Since the discussion about the init system choice IMO went on for too long, I can only recommend to repeat my experiment: create two VMs - VirtualBox is available right from the Debian repos ;-) - and install Fedora 20 and Ubuntu 13.10. See the differences for yourself. Experience the differences for yourself. Regards, and good luck reaching the decision. P.S. bugs.debian.org doesn't seem to let my e-mails through. Two attempts to subscribe to the bug went nowhere. Let's see if this message is luckier. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cad08gxk9dvnr3gr_nlzxwjvnagnk1jxyje+uca9o++rxuty...@mail.gmail.com
Bug#727708: On diversity
Le vendredi 17 janvier 2014 à 08:47 +, Thorsten Glaser a écrit : Besides what Russ said: Debian isn’t about Linux. Debian is the universal operating system. Just because you don’t understand that sentence doesn’t mean you can use it to justify whatever convoluted position of yours. An operating system is universal if it can be used for all purposes. An operating system that supports several kernels and init systems, but all incompletely, letting the user choose between different ways of failing to boot, is not universal. It is irrelevant to any serious use case. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1389971621.21140.4.camel@tomoe
Bug#727708: Init system resolution open questions
On Thu, Jan 16, 2014 at 01:01:51PM -0800, Russ Allbery wrote: I think that major packages that would be considered release blockers, which probably includes GNOME, KDE, and Xfce, need to support the default Linux init system in the sense that, if they don't, I don't think we can release. I think a substantial degredation of functionality when running on an init system other than the Linux default would be okay for for jessie+1. For jessie, I think it depends greatly on how feasible making them work with sysvinit is (and I suspect sysvinit support would be sufficient for all other purposes). I think we should move away from them target that the non-Linux ports should build the entire archive. FreeBSD upstream isn't a desktop OS and never will be, there're just too many deficiencies (e.g. lack of dbus, limited hardware support, only OSS sound drivers, limited KMS/3D support in Xorg etc. pp). So why should the Debian port with it's minimal porters achieve what upstream doesn't deliver? And for Hurd it's even more obvious. All the use cases mentioned for Debian kfreebsd are server-based (e.g. pf or NAS using ZFS). Why not focus on a useful subsection of Debian and get that right instead of fighting an uphill battle? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140117150548.ga6...@inutil.org
Bug#727708: personal views of Debian users
Hey. Well not sure whether this is actually welcomed or not,... but since some people have already started to share their personal feelings about the debate, I want to do so as well. I've been using sysvinit for countless years (as most of us)... and I've tried both, systemd and upstart when the recent discussion began (which was, I guess, actually sparked indirectly by a post of mine, when I asked whether systemd was now mandatory due to GNOME depending on it))... I haven't really looked in depth at OpenRC or other solutions, since from the descriptions made by other people, I think it's not comparable to systemd/upstart. I'm maintaining a large Tier-2 for the LHC Computing Grid... so I guess I do have some ;) experience in what is useful in real life (like most other people here have of course as well). Now I guess it doesn't make much sense to repeat all technical arguments people have already brought up over and over again in this bug, so to make it short: From a technical POV, I'd clearly go for systemd. Not only are (IMHO) it's core concepts and design superior... it also seems to provide much more and better features. Speaking only about Debian GNU/Linux... I'd even go as far, that I'd say we should in the long term, think about integrating the other features of systemd, like the Journal replacing rsyslog, or perhaps even having it in the initramfs (well, that is of course something one would really need to investigate closely)... In any case we should try to get something like the un-initramfs at shutdown, which systemd seems to support quite well. I think however, that a main part (50%) of the question systemd vs. upstart vs. something-else is not a technical one. Code, design and features can be improved or added. I think there is a strong political part in this decision. - At most upstream projects (the kernel, wayland, X, etc. pp.) people seem to at least think first about systemd... if they support upstart at all. Just look at recent developments like kdbus, which are clearly strongly influenced/triggered by systemd. So I fear that when going for upstart, Debian might sooner or later sit on a lone island (next to *buntu's island), having to spend a lot time to keep things working and adapted to upstart. - Most other major distros (except *buntu) have decided for systemd,... so again here,... with upstart we'd sit on a lone island, which ultimately would lead to many problems for sure. - In my opinion (and I'm sure some people will agree and others will contrary): RedHat has proven to be more neutral to projects it governs than Canonical. Actually, many people seem to think,... that Canonical has recently gone some strange paths, which somehow seem to lead them away from the community and classical open source ecosystem (just think about the whole Mir-story). - With upstart there is the contributor license agreement issue... which I think is a major political problem. - Last but not least... there are people (including myself, I guess),... which are concerned about the Debian/*buntu relationship in several ways... so having upstart the default init system, would give Canonical for sure some bit more of influence on Debian (and if it was just by technical decisions they make upstream). Of course one can argue, that this kind of influence might now be taken by RedHat. As another side note (which is not really a reason against upstart), but has also some political impact, I guess... I really wonder what the decision systemd vs. upstart in Debian means to upstart? systemd for sure wouldn't bother much, if Debian decides for upstart. But it seems to me, that if Debian decides for systemd, this could be the end of upstart itself. Why? - *buntu would then permanently be completely alone on the upstart-island. - And since Debian packages would then focus on systemd, *buntu would get proper support for that for free - so why continuing to spend much efforts just for having an own init-system, which even provides no real technical benefits? Actually Canonical *is* known for dropping support or at least active development for their praised products,... think about bzr. Some last things: - While I think there should be a default init-system which all packages MUST support (which I'd want to be systemd)... others should be allowed as well. - I do have a big problem with projects (especially like GNOME) which sometimes seem to have an agenda of enforcing people to use the techniques they want. IMHO, open source IS about choice. But reality is probably, that one cannot do much about it. - I strongly like the idea of having k/freebsd and other non-Linux Debians,... and if it is just for diversity. Whatever decision is taken in the end,...care should be taken, that these ports can continue to exist. Best wishes, Chris. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:
Bug#727708: On diversity
On Fri, 2014-01-17 at 16:13 +0100, Josselin Mouette wrote: Just because you don’t understand that sentence doesn’t mean you can use it to justify whatever convoluted position of yours. I wonder who really doesn't understand here... An operating system is universal if it can be used for all purposes. An operating system that supports several kernels and init systems, but all incompletely, letting the user choose between different ways of failing to boot, is not universal. It is irrelevant to any serious use case. ... since which king is then,... who decides which way/init system/kernel/etc... is the right, the universal, for all people? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Bug#727708: Init system resolution open questions
Moritz Muehlenhoff dixit: FreeBSD upstream isn't a desktop OS and never will be, there're just too many deficiencies (e.g. lack of dbus Eh, excuse me! It’s obviously possible to run a desktop without dbus! In fact, this is a feature, in my eyes. limited hardware support Oh c’mon. Linux does not support any and all hardware either. only OSS sound drivers I fail to see where the problem is with this. limited KMS/3D support in Xorg As if that were not the case in Linux. Its support may be a bit broader but still limited. Sorry, but this is FUD. bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1401171627270.23...@herc.mirbsd.org
Re: Bug#727708: personal views of Debian users
Christoph Anton Mitterer dixit: - At most upstream projects (the kernel, wayland, X, etc. pp.) people seem to at least think first about systemd... Only those that have strong ties to Poettering, Red Hat, GNOME. if they support upstart at all. Right, upstart is, right now, a Canonical solution. But upstreams in general support SYSV init scripts (especially since LSB), whereas systemd is rarely seen across all upstreams (not just those already poettering’d’. But if Debian were to support Upstart, I could see this change. (And I never thought I’d see the day where something from *buntu can rescue Debian.) Just look at recent developments like kdbus, which are clearly strongly influenced/triggered by systemd. Or by people abusing the “message bus” for things it never was intended. And also, the kdbus “movement” comes from the Poettering crowd. - Most other major distros (except *buntu) have decided for systemd,... so again here,... with upstart we'd sit on a lone island, which ultimately would lead to many problems for sure. Yes, but this is a very good reason to *not* join others, so we do not share their deficiencies either. - In my opinion (and I'm sure some people will agree and others will contrary): RedHat has proven to be more neutral to projects it governs than Canonical. […] - With upstart there is the contributor license agreement issue... which I think is a major political problem. Mh. This clearly is a problem, unless they’d be willing to open up this thing. But there’s also sysv-rc and OpenRC still as contenders. (I think file-rc – sadly – left the train.) - Last but not least... there are people (including myself, I guess),... which are concerned about the Debian/*buntu relationship in several ways... so having upstart the default init system, would give Canonical for sure some bit more of influence on Debian (and if it was just by technical decisions they make upstream). I consider myself as one of these people too, but they’re influencing enough already, yet still the danger from Canonical (when balanced by the rest of the Debian mass) is perceived as much less than the danger from Poettering and Co. Of course one can argue, that this kind of influence might now be taken by RedHat. This is something I have been seeing more and more recently. The RedHat, “freedesktop”, GNOME people *are* trying to force everyone to do things, and not just some but everything, their way *only*. With *buntu, other things are at least just not supported commercially, modulo sponsoring the spin-offs to some degree. They try to promote their way, which may work well for a large percentage of the “average user”, but do not cut off experts entirely (granted, it becomes harder and harder to run a *buntu in a nōn-default configuration, but it’s not impossible, plus, Debian is not to become another *buntu just for supporting upstart.) Note I’m still in favour of supporting multiple init systems. (And there is absolutely *zero* reason anything like *kit (console, policy, package or whatever) or logind to use a system as a desktop. This is only used by some fancy additional optional and rarely used features. And never in your typical centrally-managed company desktops, for example.) - I do have a big problem with projects (especially like GNOME) which sometimes seem to have an agenda of enforcing people to use the techniques they want. IMHO, open source IS about choice. But reality is probably, that one cannot do much about it. And that’s where Debian is stong: ensuring the freedom of its *users* from people wanting to prescribe them things. Honestly, sometimes, the GNOME people are worse than Microsoft®… bye, //mirabilos -- 22:59⎜Vutral glaub ich termkit is kompliziert | glabe nicht das man damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil zuviel bilder │ wie ein spiel | 23:00⎜Vutral die meisten raffen auch nicht mehr von windows | 23:01⎜Vutral bilderbücher sind ja auch nich wirklich verbreitet als erwachsenen literatur ‣ who needs GUIs thus? -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1401171641050.23...@herc.mirbsd.org
Re: Bug#727708: Spotify position in support of systemd in the default init debate
On Fri, Jan 17, 2014 at 04:37:45PM +, Thorsten Glaser wrote: - We believe that systemd will have the stronger community momentum moving forward when it comes to seeing close integration between modern init system features and upstream projects. I believe that this is precisely a reason *against* choosing systemd, as it leads to monoculture, vendor lock-in (even more than we already have), replacement of UNIX with FLOS, and caters to Poettering fans. Debian's job is delivering a spot-on OS. Diverging with everyone else means we have to spend time and effort doing stuff that doesn't matter, namely, maintaining our own patches and changes to make software run in Debian, rather then spending effort on ensuring everything's stable. I know some folks enjoy this work, but I sure don't. Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Bug#727708: On diversity
On Fri, 2014-01-17 at 16:01 +, Ian Jackson wrote: The universal operating system phrase is a slogan. Sure it is, but that slogan actually stands for some important principles in the open source world... like not to force stuff upon users... and allowing many different things to happily co-exist. Open source is also a lot about freedom (not only that of developers but also that of users) Now looking at the GNOME-background,... there are surely people who'd say that these folks have sometimes forgotten a bit those ideals. Anyway... I guess that's off topic to this discussion (sorry for that)... except perhaps that part,... that neither choice for an init-system should restrict the freedom of others (k/freebsd, hurd, the guys who like another init-system more) more than absolutely necessary. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1389974931.7103.5.ca...@heisenberg.scientia.net
Bug#727708: On diversity
Christoph Anton Mitterer cales...@scientia.net writes: On Fri, 2014-01-17 at 16:01 +, Ian Jackson wrote: The universal operating system phrase is a slogan. Sure it is, but that slogan actually stands for some important principles in the open source world... like not to force stuff upon users... and allowing many different things to happily co-exist. It does for you. It doesn't necessarily for everyone, and since there's no meat to the slogan beyond that one sentence, there's nothing there to persuade anyone that your interpretation is correct and someone else's is incorrect. I agree with Ian: there's no real point in using this as a basis for an argument, since it's not going to convince people. I think there are other, better arguments in favor of supporting a variety of goals and projects in Debian. Now looking at the GNOME-background,... there are surely people who'd say that these folks have sometimes forgotten a bit those ideals. Again, please extend to your fellow developers the courtesy of assuming that they understand all of this background just as well as you do. People can disagree with each other without one of them being forgetful, or disagreeing with freedom, or possessing some other character flaw. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738kmecll@windlord.stanford.edu
Bug#727708: OpenRC now works on GNU/Hurd! :)
Andrew Shadura and...@shadura.me writes: It is actually fairly easy to write an initscript which uses native OpenRC facilities if they're available. While this serves little practical use, I tried to play with this, and this is the result: Thanks for sharing that. Bdale pgpRO75eKg_7I.pgp Description: PGP signature
Bug#727708: On diversity
On Fri, Jan 17, 2014 at 05:08:51PM +0100, Christoph Anton Mitterer wrote: On Fri, 2014-01-17 at 16:01 +, Ian Jackson wrote: The universal operating system phrase is a slogan. Sure it is, but that slogan actually stands for some important principles in the open source world... like not to force stuff upon users... and allowing many different things to happily co-exist. Open source is also a lot about freedom (not only that of developers but also that of users) ... This is a common misconception: There is no such principle, and Open Source does not turn the developers who (often in their spare time) work on the software into slaves of their users. The exact opposite is true, and the developers who do the work have the freedom to force whatever they want on the users of their software. Among the freedoms Open Source gives to all users the relevant one is actually the right to fork: If you don't like a policy decision of an Open Source project, you can always create a fork that works exactly the way you envision it. This is quite fair in giving the power of making decisions not to the users who scream loudest, but to the people who actually do the work. And for Debian the Technical Committee is the instance to make such decisions on behalf of the whole project. Cheers, Chris. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140117174137.ga30...@bunk.dyndns.info
Bug#727708: OpenRC now works on GNU/Hurd! :)
Thomas Goirand z...@debian.org writes: It's with great joy that I can announce here that OpenRC now supports GNU/Hurd. I have just added a few patches which were worked out with upstream (you can look at them, it's really trival FTBFS fixing...), tested it, and I can happily say it works. Congratulations, Thomas! That's great news. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txd2cxha@windlord.stanford.edu
Bug#727708: On diversity
On Fri, 2014-01-17 at 16:08 +0100, Ihar Filipau wrote: Uoti Urpala wrote: Even the upstart proponents do not seem to have significant arguments about upstart having better functionality, and there don't seem to be all that many people who would have a reasonably informed opinion that upstart would be technically better even for just their particular use. I followed the discussion from the beginning and I'd like to comment on that. My own comparison of systemd vs. upstart (Fedora 20 vs. Ubuntu 13.10) is still fresh in my memory. Your comparison does not look very informed, see below. 1. upstart is a highly configurable init system, while systemd hardcodes most of the nuts and bolts in the 32 shipped executables. I spent one days Your hardcodes is wrong: systemd ships with helper executables and a default boot setup which uses those, but they're not hardcoded and you can use something else if you have a reason to. So here you go. The advantage of the upstart, is that if you need to tweak the boot of your system, you can do it right there, with the text editor, by changing the .conf files or the shell scripts. While with the systemd, you have I strongly disagree that using shell more as an implementation language would be a good thing. But out of the things in your post I think this is the closest to a not-factually-incorrect personal preference someone could have for upstart: some people could prefer working in shell only. However, this isn't really a comparison of the init systems themselves so much as a comparison of the default boot setups shipped with the inits. Even if you decide that almost every program running on your system should be implemented in shell only, you could still use systemd to start those programs, though you'd need to change more of the default configuration if you wanted to avoid starting anything non-shell at boot. 2. upstart was not designed or intended to be a SMF (service management facility), while systemd was. I think it is insincere of upstart proponents to even advertise it as such. On On the other side of the fence. As I see it, it is only a coincidence that systemd is also an init system. To me it was clearly designed from ground up as SMF: boot and initialization were only afterthought. That's why the magic binaries, because the initialization, an event driven process, simply doesn't fit into the systemd everything is a service model. This is nonsense. Technically, the choice of implementation language for the binaries/scripts and the event/dependency model are completely orthogonal. This means your last sentence is completely wrong. It's also not plausible as a historical fact that boot would have been an afterthought. 3. Boot times. Though systemd was supposed to improve the boot time, Fedora 20 VM on my rig needs 1m5s-1m15s to start - while Ubuntu 13.10 VM always timed flat 0m35s. That was pretty dumbfounding realization, especially after finding Other people have Fedora booting a lot faster. There are lots of reasons that could make boot slow other than inherent problems with the init system, so if you haven't done any analysis of the causes of the slowness, this does not really tell anything. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1389981988.4304.154.camel@glyph.nonexistent.invalid
Bug#727708: personal views of Debian users
On Fri, Jan 17, 2014 at 04:46:43PM +0100, Christoph Anton Mitterer wrote: Well not sure whether this is actually welcomed or not,... but since some people have already started to share their personal feelings about the debate, I want to do so as well. I don't think this is necessary or helpful (regardless of which init system someone is in favor of). The TC members each need to make up their own mind about what is technically best for Debian, and in a thread that's already over 1000 messages long, these personal testimonials are very unlikely to introduce any genuinely new technical arguments. I don't think that adding to the TC's incoming mail load is going to help the process of reaching a sound decision. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: init system thoughts
Anthony Towns a...@erisian.com.au writes: To emulate systemd dependencies in an event model (ie, X depends on Y), you'd need to do either: * change Y's job to say start on starting X * add stop on stopping Y to X's job description or * add a pre-start script to X in order to start Y first * add stop on stopping Y to X's job description The latter looks like it's the documented way of doing things. But maybe not the working and/or recommend one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#3150 (the quoted parts are important). Best, Nikolaus -- Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874n52atz4@vostro.rath.org
Bug#727708: Init system resolution open questions
Steve Langasek vor...@debian.org writes: I don't believe we need to know the answer to these questions to know that Ian's requirement is a correct one. If we are saying that packages cannot drop their sysvinit scripts in jessie in order to ensure smooth upgrades, then the same requirement should apply to desktop environments, even if we don't know at the moment precisely how the maintainers of the affected packages will solve this - because having smooth upgrades between releases is a *baseline* for the quality of Debian integration, and we should not vacillate merely because some people fear it will be hard in this particular case. I believe it is reasonable to allow GNOME to require systemd as the init system if that's the only way to get a working logind with the software that we release with jessie, and I don't believe holding systemd to pre-206 in order to make that possible makes sense. 204 will be getting pretty long in the tooth by the time we get to the jessie release. So, basically, I disagree with this. Now, obviously, hopefully logind will work fine in the jessie release without requiring systemd as the init system, and this will all be theoretical, but I'm worried that we're going to paint ourselves into an unreasonable corner by stating a hard and fast rule about this before we know what the shape of the software will be at the time of the release. The consequences of a desktop environment having a hard dependency on a particular init system in jessie are that a desktop system becomes unusable partway through the upgrade. If a user tries to open a new login session while the upgrade is in progress, or if for whatever reason the user running the upgrade logs out (or gets logged out due to a bug) and tries to log back in, this will in all likelihood fail. I don't think that's an acceptable outcome; so the requirement not to hard-depend on systemd follows directly from this. Clearly the release team and the GNOME team will need to look at proper behavior during the upgrade, including aborted upgrades, but I think this is a separate issue that they would be looking at regardless. If the dependency causes separate RC issues around upgrades, obviously those issues will need to be addressed, but I'm dubious about simply *assuming* it will without looking at how the actual system could be assembled or letting people try to find good solutions to the problem. In other words, it's not that I want to say the *opposite* of what Ian stated as consensus. Rather, I want to make sure that we don't rule on things that we don't need to be ruling on, and make sure that we don't write a decision that effectively ends up telling the GNOME team that they have to get the version they target for jessie working without logind or have it removed from the archive. Separately, I don't agree that it's actually hard to support logind on non-systemd for jessie. This already works for v204, and the work to support v205 is in progress. In this case, omitting this requirement from our ruling won't actually make any difference, since it will be easy to support and hence uncontroversial. So, either way, I think we should make sure the statement we make permits packages to depend on logind. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ha92hqqd@windlord.stanford.edu
Bug#727708: Init system resolution open questions
On Thu, Jan 16, 2014 at 12:08:41PM -0800, Russ Allbery wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: AFAICT we are all agreed that: * Applications which aren't part of the init system must not require a particular init to be pid 1. (So in particular a desktop environment may not require a particular pid 1.) I still have concerns about this. This position seems to be predicated on the assumption that applications will be able to depend on a working logind for jessie, and that a working logind will be provided for systems using sysvinit. This apparently works today with systemd-shim but will stop working with post-205 systemd. I want to understand whether setting this requirement means that we're intending to require that jessie ship with systemd 204, or, if not, what level of certainty we have that post-205 logind will work with sysvinit for jessie. I don't believe we need to know the answer to these questions to know that Ian's requirement is a correct one. If we are saying that packages cannot drop their sysvinit scripts in jessie in order to ensure smooth upgrades, then the same requirement should apply to desktop environments, even if we don't know at the moment precisely how the maintainers of the affected packages will solve this - because having smooth upgrades between releases is a *baseline* for the quality of Debian integration, and we should not vacillate merely because some people fear it will be hard in this particular case. The consequences of a desktop environment having a hard dependency on a particular init system in jessie are that a desktop system becomes unusable partway through the upgrade. If a user tries to open a new login session while the upgrade is in progress, or if for whatever reason the user running the upgrade logs out (or gets logged out due to a bug) and tries to log back in, this will in all likelihood fail. I don't think that's an acceptable outcome; so the requirement not to hard-depend on systemd follows directly from this. There may be other failure modes if the system is rebooted partway through the upgrade, but that's always the case, and doesn't speak against declaring a dependency on an init system. Separately, I don't agree that it's actually hard to support logind on non-systemd for jessie. This already works for v204, and the work to support v205 is in progress. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: Thoughts on Init System Debate
First off, I'd like to apologize again for taking so long to figure out and write up my opinion. I still feel a little bit swamped with all of the information that I've reviewed to come to my opinion, and I certainly don't yet completely understand the full architecture of either upstart or systemd even though I've been working with them both for a while now From the information which I have reviewed, and seen, either upstart or systemd are viable choices for Debian, but we must choose between them. Upstart has much clearer documentation than systemd, but systemd's documentation is sufficient.[1] Systemd's declarative style has the advantage of being directly parsable, but the disadvantage of forcing logic out into daemons... though that's probably where it should be in the first place.[2] Upstart's CLA is problematic, and coupled with the fact that the rest of the non-Debian distributions appear to be standardizing on systemd gives me pause. I'm not sure if this is actually a major concern, though, as long as Ubuntu continues using upstart. Systemd's socket-based activation and cgroup based tracking are technically superior to upstart, even though the latter causes problems with portability to non-linux systems. However, if we were to decide on upstart, we could have just a single init system everywhere, which would be beneficial.[3] Writing non-complicated unit or job files for systemd or upstart is fairly straightforward, and should be easy for the vast majority of packages. [A strong argument could be made that packages like spamass-milter which it isn't so straightforward are deficient.] With all that said, I think all of these considerations give me a slight preference for systemd over upstart, though I believe that whatever the committee decides on will be a great improvement over venerable SysV. I should point out that I have not extensively examined openrc, nor have I taken into account planned features and development in either systemd or upstart which could sway my opinion. Finally, thanks to everyone who has participated in this massive thread, writing position statements, and putting up with all of the questions that the CTTE has had. 1: For example, systemd could have much better introductory documentation for unit file writers than it currently has. It also describes many of its features in blog posts which are not written into a cohesive manual which flows. I suspect these will be rectified in the future, but I found it fairly frustrating to deal with. It would also be super-nice, since almost all of systemd's configuration is in /lib/systemd/system for there to be a manpage or similar which had all of them and pointers to documentation what they did, etc. 2: It's sort of annoying that systemd's declarative syntax has knobs like CondtionPathExists= etc, but doesn't have methods of then wrapping segments of the unit file in conditionals. Instead, the solution appears to be writing multiple unit files with the correct sets of Condition...= But perhaps I'm missing something. (This matters to be because of http://svn.donarmstrong.com/deb_pkgs/spamass-milter/trunk/debian/spamass-milter.init ) 3: Frankly, I don't want to support more than one set of init files; if the other architectures are to be release architectures, they really should get whatever the CTTE decides is the default init system ported to them, and the maintainers of that init system in Debian should accept patches to do so, even if it means that the default init system is less functional on those architectures than it would otherwise be. [Even without cgroups, it'll be superior to sysv, after all.] -- Don Armstrong http://www.donarmstrong.com Clothes make the man. Naked people have little or no influence on society. -- Mark Twain -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140118044132.gd12...@teltox.donarmstrong.com
Bug#727708: Thoughts on Init System Debate
On Fri, Jan 17, 2014 at 8:41 PM, Don Armstrong d...@debian.org wrote Upstart's CLA is problematic, and coupled with the fact that the rest of the non-Debian distributions appear to be standardizing on systemd gives me pause. I'm not sure if this is actually a major concern, though, as long as Ubuntu continues using upstart. If you have the time, I must ask: if Upstart had no CLA, would you prefer it over systemd? -- Cameron Norman
Bug#727708: Thoughts on Init System Debate
On Sat, 18 Jan 2014, Cameron Norman wrote: If you have the time, I must ask: if Upstart had no CLA, would you prefer it over systemd? No, but it would certain close the gap even more. Wildly Off-Topic: I should note that I think if upstart did not have the CLA that it does, the rest of the FOSS world might have just improved it, and systemd might never have shown up. I suspect that the fate of bzr might be similar. These should serve as a cautionary tale for for-profit companies requiring CLAs. [Or everyone, even.] -- Don Armstrong http://www.donarmstrong.com Live and learn or die and teach by example -- a softer world #625 http://www.asofterworld.com/index.php?id=625 -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140118050823.gf12...@teltox.donarmstrong.com
