Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
The Wanderer dijo [Thu, Jul 03, 2014 at 11:18:12PM -0400]: It must work without systemd well enough to be able to cleanly reboot the system from the GUI, after upgrading. Anything beyond that is nice-to-have, but definitely NOT required. I, for one, would be highly displeased if a routine dist-upgrade to testing required me to reboot to avoid having things break. Of course. But then again, how much is routine a change that implements a long-discussed decision that took so many months and flames to reach and settle. Settle. The decision is taken and settled. Yes, we must find a way to harmonize it with the different init systems existing in the archive, and the non-Linux ports of Debian. But the decision is taken. I generally dist-upgrade my primary computer to testing about once a week, give or take, but I don't reboot it more often than once a month - more commonly three to six months, and I'd prefer that to be longer if possible. (And often when I do reboot, it's due to a power outage that overwhelms my UPS.) FWIW, my unstable system didn't break or anything after I upgraded it to systemd. Yes, I rebooted within a week, but it was not a reboot is needed to keep this system operational in any way. I would argue that in order for Jessie to be the most awesome stable release [...] ever prepared, it must work without systemd well enough to let everything that worked before the upgrade to Jessie continue to work equally well until the user decides to reboot - whether that's immediately, or six months down the line. Previous releases could successfully be used that way, after all; I've done it with at least one of them. Hate mails rehashing the arguments that should have already died months ago won't make Jessie any more awesome. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140705135714.gb103...@gwolf.org
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
The Wanderer wande...@fastmail.fm writes: ... particularly because I use rather fewer things than many other people, and don't use most fancy GUI elements. (For example, I don't have a graphical power button at all; I shut down by exiting my window manager, logging out of the console where I had originally run startx, logging in as root, and running 'shutdown -h'.) So, let me get this straight: You're saying that if, having decided to postpone rebooting after an upgrade where any reasonable person would expect to reboot, you hear rumours that features you don't use would have been broken if you had them installed, you'll be highly displeased -- is that right? and this is on a laptop, where you run testing, and which generally gets rebooted by power outages, rather than any UI component that may or may not be working at the time. and you're inflicting this nonsense on the thousands of readers of this list for what reason? If it's to gain our gratitude and respect, I'm afraid it's not working on me. Cheers, Phil. P.S. I'm yet to install systemd, but when I do switch to systemd, which I will do despite being a bit of a stick in the mud, I'll expect to reboot at least once. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://ftp.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpAQVhFR2SKI.pgp Description: PGP signature
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
On Thu, Jul 3, 2014, at 16:59, Thorsten Glaser wrote: Besides, it’s not that the TC made a decision. Rather, the TC was split, and the chairman threw in his weight. This is absolutely not what I’d call a project(!) decision. No! The TC has made the decision with full adherence to Debian Constitution. If you disagree, perhaps you should go re-read the Constitution, and if you disagree with our Constitution then perhaps it's time for you to step down as a Debian Developer, since you are bound by the Constitution and Social Contract and you are doing hard to the project by making claims like this one. O. -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404466044.32693.138025825.706c6...@webmail.messagingengine.com
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
That will be my last contribution to this pointless discussion. Le jeudi, 3 juillet 2014, 16.59:25 Thorsten Glaser a écrit : or without systemd btw). Given that the technical committee has made a decision which stayed unchallenged (so far), I've now come to think that No, there just has not been any challenge that met the form and other requirements… and I am at a bit of loss at what to do here. Besides, it’s not that the TC made a decision. Rather, the TC was split, and the chairman threw in his weight. Sorry, but this is plain wrong (and you know it); the TC followed its decision-making process (outlined in the project's constitution [0,1]) which led to what is now a TC decision. The detail of the votes doesn't change the outcome. Quoting [2]: The committee decided that the default init system for Linux architectures in jessie should be systemd. There are no possible weak or strong decisions; the outcome of a TC or GR decision is either resolution accepted or further discussion. Giving importance to the winning majority is your choice but doesn't change the decision itself. This is absolutely not what I’d call a project(!) decision. I was careful enough to not say it was a project decision, mind you. That said, our technical decision body took a decision that stayed unchallenged (so far); this fact makes it a /de facto/ project decision. Can we get over this now and start making Jessie the most awesome stable release we've ever prepared together? To do that, it MUST work without systemd, if alone for upgrade scenarios. That's wrong: as far as the default init is concerned, it only MUST work without systemd-as-init until the first post-dist-upgrade reboot. I don't think any work outside of that scope should be imposed on the package maintainers [3]. And alone the fact that the systemd issue *continuously* pops up shows you that it is nowhere even near solved. I don't think that's true. From my (most-certainly) biased point of view, the issue continues to pop up because some very vocal systemd opponents keep vocally insisting that other fellow project volunteers ensure that their pet use-cases keep working with a non-default init system (or even without a specific non-init package). As far as I am concerned, I'm putting my energy to make sure my packages (and my setup) work as good as possible with the _default_ init that was picked for jessie. The rest is best-effort. Furthermore, the TC(-chairman) decision only was on the default init system for the Linux ports of jessie. Please stop spreading the FUD that the default init decision was a TC- chairman decision. This is plain wrong, as our constitution outlines. This means that • installing jessie with other init systems • switching between init systems • default init system for kFreeBSD ports • default init system for Hurd port • which non-default init systems are there? are still on the table. Sure. They are on the we want Debian Jessie to work with other inits than the default persons' table, they have no reason to be on everyone's. As mentioned above: if you want this to work, make sure it does, propose patches, test scenarios, etc. Pushing for a package conflicting with systemd is not helping any of this. (Due to Debian’s requirements for sane upgrades, running a jessie system that was upgraded from an older release with sysvinit MUST be fully supported, anyway.) Wrong, see above. I’m a bit torn between throwing it all (which is a bad idea ofc), writing a GR myself (which is also a bad idea due to my lack of language skills), packaging BSD init for my own repo, joining the (currently unheard) runit-as-init crowd… Frankly, if voting on a default init GR would ensure we'd finally stop these bikeshed discussions (after few other weeks of mudslinging), by all means, go for it. That said, as far as I remember, the latest GR proposal [4] on this subject failed to gather the mandatory K seconds though. For me, this indicates that not even K=5 DDs were interested in having that discussion. We currently need half a percent of DDs to trigger a GR and it has not happened; could we get over this now? OdyX [0] https://www.debian.org/devel/constitution [1] Which you agreed to. [2] https://www.debian.org/devel/tech-ctte [3] It doesn't mean they should not accept patches for adaptations for other init systems though. [4] https://lists.debian.org/debian-vote/2014/03/msg0.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1627463.lsrZH6mOqL@gyllingar
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
In other news for Thu, Jul 03, 2014 at 04:59:25PM +0200, Thorsten Glaser has been seen typing: No, there just has not been any challenge that met the form and other requirements… and I am at a bit of loss at what to do here. Besides, it’s not that the TC made a decision. Rather, the TC was split, and the chairman threw in his weight. This is absolutely not what I’d call a project(!) decision. FFS. The chairman didn't Throw in his weight. He used his tiebreaker vote to break a tie. Which is exactly what he was *supposed* to do. Stop pretending you're concerned about procedural propriety when your actual problem is that the committee, working by the established procedures, produced an outcome you didn't want. Who do you think you are, the senate GOP? -- Rens Houben |opinions are mine Resident linux guru and sysadmin | if my employers have one Systemec Internet Services. |they'll tell you themselves PGP key at http://proteus.systemec.nl/~shadur/shadur.key.asc -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140704100615.ga30...@proteus.systemec.nl
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/04/2014 04:52 AM, Philip Hands wrote: The Wanderer wande...@fastmail.fm writes: ... particularly because I use rather fewer things than many other people, and don't use most fancy GUI elements. (For example, I don't have a graphical power button at all; I shut down by exiting my window manager, logging out of the console where I had originally run startx, logging in as root, and running 'shutdown -h'.) So, let me get this straight: You're saying that if, having decided to postpone rebooting after an upgrade where any reasonable person would expect to reboot, This part is precisely what I'm objecting to. I don't consider being expected to reboot *in order to maintain existing functionality* after an upgrade to be reasonable. (Being expected to reboot in order to use the new functionality, for a sufficiently low-level component of the system, is of course entirely reasonable.) At the very least, in the very rare case that rebooting is actually required, a prominent pre-install this install will require you to reboot ASAP notification would be appropriate. The situation is different in Windows (where such please reboot now notifications are very common post-install, including with ordinary programs rather than low-level components), of course, but I've considered that to be an example of one of the advantages of *nix over Windows. you hear rumours that features you don't use would have been broken if you had them installed, you'll be highly displeased -- is that right? No. I'm saying that if something I do use is broken during that period between upgrade and reboot, I'll be highly displeased. It's possible that nothing I do use will be affected, but it's also possible that something I use will indeed be affected. It's not remotely clear yet (at least to me) what features will be broken, or indeed even which of the many systemd-related packages is expected to potentially cause such breakage. I would not be in the least bit surprised if I were not the only one who would be displeased at a continuing to use your computer indefinitely after upgrading and before rebooting is not a scenario which is expected to work situation, given the historical tendency for people to chase their own personal uptime records. and this is on a laptop, where you run testing, and which generally gets rebooted by power outages, rather than any UI component that may or may not be working at the time. No. This is on both a laptop and a desktop; the desktop generally gets rebooted by power outages, and the laptop by the battery died because I left it suspended for too long without plugging it in. This also isn't about reboot methods which may or may not get broken; it's about *other* things which may get broken. Nothing has been said to narrow down what other things those might be, AFAIK, only that GUI-based reboot methods must *not* get broken. and you're inflicting this nonsense on the thousands of readers of this list for what reason? If it's to gain our gratitude and respect, I'm afraid it's not working on me. (Why on Earth would anyone think that someone would raise an objection in order to get gratitude from those to whom the objection is being presented?) I spoke up because I consider a scenario of everything works, a routine upgrade occurs, now something is broken until a reboot is performed to be undesirable and unacceptable, for pretty much any reason, and I had never previously encountered a suggestion that such a scenario might be considered normal and expected in any *nix environment. If it were guaranteed that the systemd upgrade would *not* be a routine upgrade, but a special one done with full knowledge of what is happening, that might mitigate the problem somewhat - but we've already seen that systemd can easily be pulled in without the user realizing that it's going to happen, or indeed noticing that it *has* happened until after the fact. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTtqHCAAoJEASpNY00KDJrpFMP/RL75yk3WEZTHWkI13GafeLb /p27WzuKm8QLnoxY8uZn4VKtEsSufBPDTrZMHBIZYzdh4Llu+TqEbtd38Q6XoUwe 8lEvDZL4bWY1pCM3fFl/FuFLQDHPribwDkV/jqBQzS38OfQWcuS/f7oetNcG+dvi rX3dw5VFbraNERLjHaADMk0fDVaSt87ItbSg00LnWsFnCjCbRSZl7wlexMhKQCMi hbtApZL9JBXkiMJV5uNDcTuNeoYG72UeBD4S0+Z3j/Rsqdsrv8nLe5v2HdkExawF Ck/NeSQsoh88Ltz1tBK/eYX7gR3Rcx5T6Gd3No+c5fxzxR2ggxA+VSLVg+EMV/fr ZMfunGMJsXDsyLl2qG45meV230cL0+X1rABb/EdMozZgWrrhLGyLJAFnio6bRJeU JwHT0WdmM/OiGj8z7WApjV0BEfzfJnsdZ/TnIviBBasZptlBxcNuVgF1eEagn8Gy XoaJRPyuAem96MCKegbamFzKDD8ysnZe2yrDrfvZH68GXinCNI6oi4xp1YwFU62L ZqOhwYi8utCvW7s/zXrzgeu5U7B/rkADtAA7Yt9Bg9kA5Mv0bfGksc1by6fNIrR9 OOdrPL4DE0xjNj6/2yHVzWB8MRoFVVSDHZLVpKTVnWsv6oZozz00JroA9i6NcBeZ Y2PhDSKFwnjTV0LKWWmb =gETV -END PGP
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
On Fri, Jul 04, 2014 at 09:52:07AM +0100, Philip Hands wrote: So, let me get this straight: You're saying that if, having decided to postpone rebooting after an upgrade where any reasonable person would expect to reboot This is Debian, not Windows or Red Hat, forced reboots are not acceptable. There was enough trouble when udev needed an in-lockstep upgrade with the kernel a few releases back. If systemd components are going to need such forced reboots on a repeated basis, I don't like where this is going. -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140704144228.ga10...@angband.pl
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
On Fri, Jul 4, 2014, at 16:42, Adam Borowski wrote: On Fri, Jul 04, 2014 at 09:52:07AM +0100, Philip Hands wrote: So, let me get this straight: You're saying that if, having decided to postpone rebooting after an upgrade where any reasonable person would expect to reboot This is Debian, not Windows or Red Hat, forced reboots are not acceptable. Yes, this is Debian and not a magic world. There was enough trouble when udev needed an in-lockstep upgrade with the kernel a few releases back. If systemd components are going to need such forced reboots on a repeated basis, I don't like where this is going. Nobody said that. But I am sure you can understand that some changes might require a reboot to have all functionality. I think it's unreasonable to require that all components must work in every combination of partial upgrade. And still this is unstable/testing and some inconveniences are allowed, we just must be sure that the stable release upgrade process is smooth. O. -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404486367.14427.138117277.67a2e...@webmail.messagingengine.com
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/04/2014 10:42 AM, Adam Borowski wrote: On Fri, Jul 04, 2014 at 09:52:07AM +0100, Philip Hands wrote: So, let me get this straight: You're saying that if, having decided to postpone rebooting after an upgrade where any reasonable person would expect to reboot This is Debian, not Windows or Red Hat, forced reboots are not acceptable. There was enough trouble when udev needed an in-lockstep upgrade with the kernel a few releases back. If systemd components are going to need such forced reboots on a repeated basis, I don't like where this is going. To be fair, I don't think anyone has suggested that reboots would be required on a repeated basis - only on the initial transition. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTtsSDAAoJEASpNY00KDJr0KgP/0d/BnwUhqZxdcP6+UWewIKu O6QSfy+kffDVt6crNyVg7qYFN5ny1piWFVDuwHZpJIOlNW5/PKfWlL9wyehWFnJq pBAU5bVRj6mnnMr3iWUf2N3O3afBWOnLqYGTnMbGB0tzWZdlaSXPN3rPdQpx7yOF uXiy7h+RzV/eoF//U+ihEUI50hBG+c6Qe0RncbOEvoRvZv2fwJtBZU4MXeVH3Ga0 ilQGDA28X19AChTvcUuy7RRKXLYYGZlRcgxsSMvSlDZQNz9f7j+MHJbKGOLtD0nN 3caQVVk4evxxcliBKPjCgzpmnK2aqI+XZTrH4qDGnNF7KJzBWPtB692srtcukmb9 SwwXWfC6bIUMGT7CW1MUB6/JmGJbF+CGNduUcqZxi/Hpe+MN1FzPgij9YVRJtu8/ 6TiZBoSn0JnqcFfjaRKp6Ex8SAqgEdWt/7Eya9xzoP+s5tyo3CpB2450vbkWIjOA RLbvYZglzpZVRI3uZs8xRdi/4pxSYIYrWCz26VU0j+mxLA1AmgpKLrjSVMTDjJBO WmtOJ8fcPK7VF77v7hj1ymswvyzAlnPk6w26cVqeRvBoCjFktWwUDiQCoqRbJzYC mFo7cX+01Z0WDQXpbO1M3oklo/bgNo7ArAbWrhEOBdv31WDM0lKNWYYV21Uczgyh +MT/Km1XQvz06VJDRxsv =qkRr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b6c483.4040...@fastmail.fm
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
Hi, Adam Borowski: There was enough trouble when udev needed an in-lockstep upgrade with the kernel a few releases back. If systemd components are going to need such forced reboots on a repeated basis, I don't like where this is going. systemd and its components can re-exec themselves, that's not the problem. The problem is that along with systemd we're changing a lot of the supporting infrastructure (we here is Upstream, for the most part). Keeping old low-level interfaces around just to avoid logging out or rebooting may or may not be something we can do easily. While I'll certainly be happy to be able to dist-upgrade without a subsequent reboot, if it turns out that this is not going to be easy to achieve then so be it. For Zurg (Jessie+1), we're likely to switch to Wayland. How do you plan to do *that* without forcing at least a re-login? -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140704152805.gk23...@smurf.noris.de
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
On Friday, July 04, 2014 17:28:05 Matthias Urlichs wrote: Hi, Adam Borowski: There was enough trouble when udev needed an in-lockstep upgrade with the kernel a few releases back. If systemd components are going to need such forced reboots on a repeated basis, I don't like where this is going. systemd and its components can re-exec themselves, that's not the problem. The problem is that along with systemd we're changing a lot of the supporting infrastructure (we here is Upstream, for the most part). Upstream of what? Keeping old low-level interfaces around just to avoid logging out or rebooting may or may not be something we can do easily. While I'll certainly be happy to be able to dist-upgrade without a subsequent reboot, if it turns out that this is not going to be easy to achieve then so be it. For Zurg (Jessie+1), we're likely to switch to Wayland. How do you plan to do *that* without forcing at least a re-login? Just because it can't be avoided completely, doesn't mean it shouldn't be minimized. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/9964234.g258putz8I@scott-latitude-e6320
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/04/2014 11:28 AM, Matthias Urlichs wrote: Hi, Adam Borowski: There was enough trouble when udev needed an in-lockstep upgrade with the kernel a few releases back. If systemd components are going to need such forced reboots on a repeated basis, I don't like where this is going. systemd and its components can re-exec themselves, that's not the problem. The problem is that along with systemd we're changing a lot of the supporting infrastructure (we here is Upstream, for the most part). Keeping old low-level interfaces around just to avoid logging out or rebooting may or may not be something we can do easily. While I'll certainly be happy to be able to dist-upgrade without a subsequent reboot, if it turns out that this is not going to be easy to achieve then so be it. For Zurg (Jessie+1), Has that name actually been formalized in any way? I still like it, but last I heard it wasn't officially anything more than a misunderstanding and a joke. we're likely to switch to Wayland. How do you plan to do *that* without forcing at least a re-login? It seems unlikely that that switch will involve removing X entirely, since many things will still rely on X, even if the X they rely on ends up getting run nested inside of Wayland (as I believe is a supported scenario, exactly for backwards-compatibility reasons). As such, anything that relies on X should still be able to keep working, as long as the existing X session continues running. It's just that anything that relies on Wayland won't be able to work until the restart is done. - From my perspective, that's perfectly acceptable; everything that was working before continues to work, but you don't get the new functionality until you restart. If that's *not* the case - if things that rely on X will break, or (more likely) if some of the things which people use will be upgraded from versions which rely on X to versions which rely on Wayland - then at the very least a pre-upgrade warning should be provided, with the opportunity to cancel / postpone the upgrade. One of the things people have been asking for, when it comes to systemd, is such a warning in the form of a debconf prompt; however, there seems to be resistance to that idea, and indeed I'm not sure it hasn't been outright rejected. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTts+yAAoJEASpNY00KDJru+oP/jmer/NUQ46fexoIW3n2D9BR fsAaPAIZdh8MciNtdyrxRksev5f5nrCuP8g9Pw8jV9XbXZh2cuS4sJWKwLpqupc5 nl1e2NVAiGu16J74zVrUd97haAPYQ80Vg7D5LXKDH5wqojbXZQ+w44GY3oNbmNG8 oYKArEFgSoIXIR9MWCOz4pMLUegeeS93keZqdQ7I+TPPZc5keif3EZzoib4uDp9v r3F4L4kvSlSmjvKfZq+DyVrwgSPRMtyoxTK8tXdhLxcUZvlQV6TSFsD9iTGY3piZ Jja+mVZicFGtBt5iQ/WeC3KGjkyao0/wfmgn26IiIsvPoRIB8a/RKHVmHIi7R+uK cs/wFCS6jzs1Z5r1QZpT3Bo4smgtAPkSKGhF1ldYBZqZlrn362BN+plSLi1fhQtw 7QOzdl+JI9sbMxWw/WtXqpBlaGKTUJiPoom7oUg+Y+K21AWUNw/ygWbzpB3SHjK8 EGvuSeAFr3E8d9U1tUHNT+Msca9L23aGsreXAh4xnUQOQj60brJLUBodlTVSapGs DRaNSOE0l/JEn3mQ1tpx0C9b263V4uVf/cOpXpyLBdOpCukSs6UunZ/IgVwUoG7U 3DTuVyKidG2SvGeyQ8nKZyJ2kMbj548+0MGQR9Tvqn/65tklu8tsxnxIK0r/lMlH IxRJHxEqa+q+4iP1wsvv =fPU6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b6cfb2.6030...@fastmail.fm
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
On Jul 04, The Wanderer wande...@fastmail.fm wrote: This part is precisely what I'm objecting to. I don't consider being expected to reboot *in order to maintain existing functionality* after an upgrade to be reasonable. Tough luck for you then, I fear that this is a perception issue. At the very least, in the very rare case that rebooting is actually required, a prominent pre-install this install will require you to reboot ASAP notification would be appropriate. This is reasonable and udev used to do this when appropriate, but it may be hard to determine in complex cases like the one being discussed. -- ciao, Marco signature.asc Description: Digital signature
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
* The Wanderer wande...@fastmail.fm, 2014-07-04, 12:00: Zurg (Jessie+1), Has that name actually been formalized in any way? No. But no worries, if RT chooses a different name, we'll have a GR to override them. :-P -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140704162226.ga1...@jwilk.net
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
Hi, Thorsten Glaser: A lot of Debian systems even run without dbus! Yeah. So? systemd doesn't force you to run a dbus daemon. No, there just has not been any challenge that met the form and other requirements… and I am at a bit of loss at what to do here. You get to do the same thing the Hurd and k*BSD people get to do – develop viable alternatives. I don't see *them* bitch about systemd, not here anyway; given the fact that it won't even run on their systems (and likely never will) I'd say they'd have more cause for doing that than you. Besides, it’s not that the TC made a decision. Rather, the TC was split, and the chairman threw in his weight. This is absolutely not what I’d call a project(!) decision. It's been a few months and nobody has filed a GR yet – and IMHO the most probable reason for *that* is that one would be very unlikely to succeed anyway. A few people complaining about systemd does not a project decision make. Or unmake, for that matter. Can we get over this now and start making Jessie the most awesome stable release we've ever prepared together? To do that, it MUST work without systemd, if alone for upgrade scenarios. It must work without systemd well enough to be able to cleanly reboot the system from the GUI, after upgrading. Anything beyond that is nice-to-have, but definitely NOT required. split, and the chairman threw in his weight. This is absolutely not what I’d call a project(!) decision. The *project* decision happened afterwards, by force of everybody (or, as it turns out, almost everybody) heaving a sigh of relief that, no matter the actual decision, the continus debate would *finally* be over and we could get on with releasing jessie instead of talking about it. Fat chance, as it turns out. Oh yes, and there was also the sigh of relief from people like me – people who want Debian to have systemd, because its features are so effing damn *useful*, and who'd rather switch distros than use upstart. Seriously. And alone the fact that the systemd issue *continuously* pops up shows you that it is nowhere even near solved. Wrong. A couple of people repeat again and again that they dislike systemd, quite intensely, and for reasons one might consider to be non-technical – if one were so inclined(*). (*) … it is not always easy not to violate our CoC … By and of itself, this says nothing whatsoever about systemd's quality. […] are still on the table. However, it is NOT the rest of the project's responsibility to make whatever work seamlessly without systemd. It's yours. An inhibit-systemd package (by whatever name) will not help you (or anybody else for that matter) achieve that goal. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140703174017.gd23...@smurf.noris.de
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/03/2014 01:40 PM, Matthias Urlichs wrote: Hi, Thorsten Glaser: Can we get over this now and start making Jessie the most awesome stable release we've ever prepared together? To do that, it MUST work without systemd, if alone for upgrade scenarios. It must work without systemd well enough to be able to cleanly reboot the system from the GUI, after upgrading. Anything beyond that is nice-to-have, but definitely NOT required. I, for one, would be highly displeased if a routine dist-upgrade to testing required me to reboot to avoid having things break. I generally dist-upgrade my primary computer to testing about once a week, give or take, but I don't reboot it more often than once a month - more commonly three to six months, and I'd prefer that to be longer if possible. (And often when I do reboot, it's due to a power outage that overwhelms my UPS.) Yes, this means that I don't get the benefit of some of the upgraded packages (e.g. new kernels) until I do reboot - but nothing breaks, either. Given the inconvenience of needing to shut down everything I'm doing (including dozens of xterms, many with running programs) to reboot, and manually bring up what parts of it I can afterwards, I'm entirely willing to live without those benefits in the interim. Regardless of how I feel and what I've argued in the past about systemd et al., I wasn't previously planning to actively avoid letting systemd get installed on my system. However, if letting it get installed will mean things will thereafter be broken until I reboot, I don't see much choice in the matter; I'll have to block it from installing until I'm ready for a *planned* reboot, which are vanishingly rare for me. I would argue that in order for Jessie to be the most awesome stable release [...] ever prepared, it must work without systemd well enough to let everything that worked before the upgrade to Jessie continue to work equally well until the user decides to reboot - whether that's immediately, or six months down the line. Previous releases could successfully be used that way, after all; I've done it with at least one of them. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTthz0AAoJEASpNY00KDJrUYYQAK5mLMWhN/Q0Zo0z+fhwjDKt bqHSguTMpACHe+K3PrwpayjtXA7y4ySHf2BoXJuLmEbR7WGRUcnY3rQLJEArtN1h M6bH9bxZu03SeMiagcY4M8prhTQ3dAN7CYX+vCBAuVi5l2oQD0yi2JgMIIGBLEmy 5wzSFX/zKtKHQuvUHS+oNLI5BALcD4T/ItBOZryl9jCh7vnW5GFQe8IDneyt7sXs 1wBgFaMZkNtQQtwxZ5Ug6LEh2ydXRG1RPrqVntNbRGNNWipKHjBcI8k5jVbj21sC 1FUkcvXvC2uV0RhOg+aCc+cilLqheYobHyDHnDZEsxnMpaamM5aW/DbpJmwmKMv5 jOTTifQuieyhmxHcUlMPjS/mTTZLxDZpHDVn2V1AZ6IIb7u4AS+03cDhB8aEfQOA 8JOHcuJKi+LTdkSOozxXbO8uxLCN310MKye/51/EMSlZmbm+8LND/+bSHUL4mBtl CTwBWqUHuDfGi+/HV1GAglz0ZSAXGE1HFR2678niIByfUA+vPa2uq6hklRnmBthX bi26AdRIwF3xD9Q/eJKTdoFLMp3YjcmKks1igEV8wsacQg9XgABkfIBqgbkMw5+L w3N9mB7rGyxxFdv0KbqkT4TcXOG8Du6XVqtbndN0MUOOex2jDuv2YPyu4kHEQFCe Wb/VaBf2qLJXDGx8Wx9w =QG8/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b61cf4.6010...@fastmail.fm
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
The Wanderer wande...@fastmail.fm writes: I, for one, would be highly displeased if a routine dist-upgrade to testing required me to reboot to avoid having things break. I generally dist-upgrade my primary computer to testing about once a week, give or take, but I don't reboot it more often than once a month - more commonly three to six months, and I'd prefer that to be longer if possible. (And often when I do reboot, it's due to a power outage that overwhelms my UPS.) Yes, this means that I don't get the benefit of some of the upgraded packages (e.g. new kernels) until I do reboot - but nothing breaks, either. Given the inconvenience of needing to shut down everything I'm doing (including dozens of xterms, many with running programs) to reboot, and manually bring up what parts of it I can afterwards, I'm entirely willing to live without those benefits in the interim. Speaking as someone who runs unstable on his laptop, power management has not worked across a dist-upgrade many times in unstable during both the current development cycle and the wheezy development cycle. Usually it's just that suspend functions don't work without a reboot (which in many cases, such as a new Linux kernel version, makes obvious sense, but I've had it not work a bunch of times when there wasn't a new kernel version), but I've had the power button in the Xfce bar not work at all in the past. So this is already the current state of play in Debian based on my personal experience, and has been for quite some time. If you haven't noticed, I suspect that you don't have as high of a sensitivity to things breaking than you might think. Or, at least, things you care about have not broken. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87iondpyo9@windlord.stanford.edu
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
Hi, The Wanderer: I, for one, would be highly displeased if a routine dist-upgrade to testing required me to reboot to avoid having things break. We're talking about an upgrade from one release to the other here, with many intrusive changes (not just systemd). If you do that upgrade not in one fell swoop but in many baby steps, at least one of these will be the one that ends up killing off a feature or two. I would argue that in order for Jessie to be the most awesome stable release [...] ever prepared, it must work without systemd well enough to let everything that worked before the upgrade to Jessie continue to work equally well until the user decides to reboot - whether that's immediately, or six months down the line. Previous releases could successfully be used that way, after all; I've done it with at least one of them. It'd be awesome if that is / will be possible, but I for one wouldn't be annoyed if it isn't, for one reason or another. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140704035436.gf23...@smurf.noris.de
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/03/2014 11:53 PM, Russ Allbery wrote: The Wanderer wande...@fastmail.fm writes: I, for one, would be highly displeased if a routine dist-upgrade to testing required me to reboot to avoid having things break. I generally dist-upgrade my primary computer to testing about once a week, give or take, but I don't reboot it more often than once a month - more commonly three to six months, and I'd prefer that to be longer if possible. (And often when I do reboot, it's due to a power outage that overwhelms my UPS.) Yes, this means that I don't get the benefit of some of the upgraded packages (e.g. new kernels) until I do reboot - but nothing breaks, either. Given the inconvenience of needing to shut down everything I'm doing (including dozens of xterms, many with running programs) to reboot, and manually bring up what parts of it I can afterwards, I'm entirely willing to live without those benefits in the interim. Speaking as someone who runs unstable on his laptop, power management has not worked across a dist-upgrade many times in unstable during both the current development cycle and the wheezy development cycle. Usually it's just that suspend functions don't work without a reboot (which in many cases, such as a new Linux kernel version, makes obvious sense, but I've had it not work a bunch of times when there wasn't a new kernel version), but I've had the power button in the Xfce bar not work at all in the past. So this is already the current state of play in Debian based on my personal experience, and has been for quite some time. Suspend - or, rather, resume from suspend - hasn't worked on this (desktop) computer ever, that I've seen. Given the symptoms, I suspect the problem lies in fglrx, which is why I haven't bothered reporting it. On my laptop (which gets a similar upgrade pattern), by contrast, the only times I've ever seen suspend fail have been from an uninterruptable running task - most commonly updatedb trying to access an inaccessible NFS share. For whatever little or nothing that may be worth. If you haven't noticed, I suspect that you don't have as high of a sensitivity to things breaking than you might think. Or, at least, things you care about have not broken. That's entirely possible, though I think the latter is a bit more likely than the former - particularly because I use rather fewer things than many other people, and don't use most fancy GUI elements. (For example, I don't have a graphical power button at all; I shut down by exiting my window manager, logging out of the console where I had originally run startx, logging in as root, and running 'shutdown -h'.) I'll also note that I specifically track testing, not unstable. I used to track unstable, but I had far too many problems (not all of which I could find a practical way to fix without a from-scratch reinstall) as a result, quite possibly including some of the sort of problems you're talking about. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTtiyNAAoJEASpNY00KDJrhzQP/3aLzEQVIffSgBls3G4Zp//F aiZmruScHxSap/yypJALEq1rvh+3IGSLAAvS0m1F/Aw51GtnMcog2f9dQrDG1Pr7 rP3QnqE+hFA2BiioZ/TaOwXdjC/ROydkShSYE43xkXgI1QHMmtdA4K5u2Yc4nJxv muNfXSDE5eaZ1ThUOslzC5uDrPPxi3x3hKtU309kv0CG2EJutOtKWWZZ8shMx0rD 5XeRy5PME1FzGsS2JXHbbnLJ4nU/VqXaJU08gIZJrlSMzMf42TB0ju/h2LakZ9BQ DzlHoNPA2mBH+dHE+OH2HVJxfQciAplQF6xKUuTItgMbs5/CAZH7hevgI4/Ku16M dyIWcTYR4XdBOX9VISpeqKRmdRGas+pSUgX2mErEifk8ExM5nA3umpce2pKD5sJ3 TPqmeZtrHDfZitsbIHGIUCvydRwDCKVZ0rge3ABX6g8Sgitib00aTaA7+o62M5ox mA7HN8U3DB+ychfZTJu8nrXRmsNJKTjW4yQFcmiMbgwoITusLAUs8CdRIvNs0xbf wPcgfJRH9hxX+2Z9aVM1KqlKRuGHToU8NRqekE9PH441/KXPmRHlT9OMBxmxEWTX TuPD5hpzSN/qyC7KQICnmg2YabJKACLNWaWYnuegsFAIFbrI2MZX81YP+C1AB7vP PV73sSfcywvv7ldNkoXi =Vplc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b62c8d.5010...@fastmail.fm
