Re: GR - collecting proposals (was Re: systemd is here to stay, get over it now)
t...@debian.org wrote: Steve McIntyre wrote: with this constant bickering and sniping. If you must do it, start the GR and see how that goes. I even offer to second it just to help get Can you help formulate? I do not feel my English skills are up to that. I'm sorry, I don't really have time to do this right now. I'm already say too stretched with my current workload. -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- 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/e1x4t0j-0004pc...@mail.einval.com
Re: GR - collecting proposals (was Re: systemd is here to stay, get over it now)
On Fri, Jul 4, 2014 at 3:28 PM, Thorsten Glaser t...@debian.org wrote: - existing installations of older (pre-jessie) Debian may be upgraded to our new standard init system systemd, but only after the user has been suitably warned, e.g. via a debconf propmpt at priority medium (i.e. not shown to novices) (maintenance burden is on the package maintainers, plus a possible team of volunteers, for the init scripts; maintenance burden for the upgrade scenario is with the maintainers of the affected packages (sysvinit and systemd, AIUI)) = we promote our new default, but permit our users to choose for themselves, if they feel they are technically skilled enough to make this choice and live with the limitations of a non-standard system; switching back and forth between the two supported systems is always possible I appreciate this as it is about freedom of choice. I think that it would be valuable for our users to keep the non-default init system working on Jessie for those who do neither intend nor need to switch to systemd. Cheers. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- 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/CAMHuwozJ+FMBSDczUYw9=+thycs93f2fthp+2acb_t39pag...@mail.gmail.com
Re: GR - collecting proposals (was Re: systemd is here to stay, get over it now)
On Jul 09, Alessio Treglia ales...@debian.org wrote: I think that it would be valuable for our users to keep the non-default init system working on Jessie for those who do neither intend nor need to switch to systemd. I suggest less thinking and more coding then, because an updated systemd-shim still has not magically appeared. -- ciao, Marco signature.asc Description: Digital signature
Re: GR - collecting proposals (was Re: systemd is here to stay, get over it now)
Quoting Marco d'Itri (m...@linux.it): On Jul 09, Alessio Treglia ales...@debian.org wrote: I think that it would be valuable for our users to keep the non-default init system working on Jessie for those who do neither intend nor need to switch to systemd. I suggest less thinking and more coding then, because an updated systemd-shim still has not magically appeared. I'm working on a systemd-shim update to do the cgroup setup on login. However if someone with a better understanding of all the slices and scopes and sessions has an interest please let me know and don't let me hold you back! -- 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/20140709172957.GT1132@ubuntumail
Re: systemd is here to stay, get over it now
Norbert Preining wrote: On Mon, 07 Jul 2014, Josselin Mouette wrote: If they donât need any of the systemd features, I guess they donât need any of its reverse dependencies either. Rubbish. I want network-manager, but I don't want systemd. I donât, but I want most KDE packages, so I installed the relevant metapackage (now removed, soâ¦). bye, //mirabilos -- 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/lpgauv$3mh$1...@ger.gmane.org
Re: systemd is here to stay, get over it now
Le mardi 08 juillet 2014 à 08:13 +0900, Norbert Preining a écrit : On Mon, 07 Jul 2014, Josselin Mouette wrote: If they don’t need any of the systemd features, I guess they don’t need any of its reverse dependencies either. Rubbish. I want network-manager, but I don't want systemd. NM was working long time without systemd. NM was working with ConsoleKit. ConsoleKit is no longer maintained. I’m starting to get a feeling of déjà vu. Don't spread wrong information. Stop making a fool of yourself. -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1404810180.14436.865.camel@dsp0698014
Re: systemd is here to stay, get over it now
Le vendredi 04 juillet 2014 à 15:09 +0200, Stephan Seitz a écrit : But if they don’t want the systemd features why should they write software to replace systemd? If they don’t need any of the systemd features, I guess they don’t need any of its reverse dependencies either. So why do they complain about “stealth installation” of systemd? -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1404751377.14436.849.camel@dsp0698014
Re: systemd is here to stay, get over it now
On Mon, 07 Jul 2014, Josselin Mouette wrote: If they don’t need any of the systemd features, I guess they don’t need any of its reverse dependencies either. Rubbish. I want network-manager, but I don't want systemd. NM was working long time without systemd. Don't spread wrong information. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- 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/20140707231306.gj23...@auth.logic.tuwien.ac.at
Re: GR - collecting proposals (was Re: systemd is here to stay, get over it now)
On 07/04/2014 10:28 PM, Thorsten Glaser wrote: 4) all init systems currently in Debian are supported in jessie; We don't need a GR to support this option. Of course, all init systems are supported, to the best of our efforts, and I don't see why someone would refuse a patch. I haven't seen such a behavior so far. Please don't start a GR with such foolish choice as 1) to 3), where we may decide to stop supporting alternative init systems. This isn't the current situation, we just have decided for a default init system, and that's enough (for now). Instead, wouldn't you help with alternatives? Like for example, help with porting upstart to kFreeBSD and Hurd, or help with OpenRC to detach the parser from the boot system would help (and I haven't found the time to work on that so far, unfortunately). Cheers, Thomas -- 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/53b79b39.4080...@debian.org
Re: systemd is here to stay, get over it now
* Juliusz Chroboczek j...@pps.univ-paris-diderot.fr [140704 23:00]: (I did find his comment funny -- actually, I find the CoC ifself pretty funny --, but I realise that this is an international mailing list and that Austrian-Japanese humour is not necessarily obvious to everyone.) I'd suggest you stop with the country-labeling/-generalization, because to me (myself an Austrian) this reads like quite the insult. -- ,''`. Christian Hofstaedtler z...@debian.org : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- pgphaPNuabYJC.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)
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: systemd is here to stay, get over it now
me: (I did find his comment funny -- actually, I find the CoC ifself pretty funny --, but I realise that this is an international mailing list and that Austrian-Japanese humour is not necessarily obvious to everyone.) Tollef Fog Heen: Humour [...] does not work very well on large lists. Christan Hofsteadler: I'd suggest you stop with the country-labeling/-generalization, because to me (myself an Austrian) this reads like quite the insult. It appears that you've been proven right, Tollef ;-) -- Juliusz -- 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/87pphj99yk.wl@pps.univ-paris-diderot.fr
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: systemd is here to stay, get over it now
OdyX wrote: 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 I was not even aware of that proposal. This may also indicate lack of, marketing or whatever. Russ Allbery wrote: systemd is open source. Every line of code is available to you to read. If you think the NSA has hidden some strange back-door in systemd, please You know, backdoors are not only code vulnerabilities. systemd is a backdoor in that, like the availability of Steam games for DDs, it has a chance to hinder the progress of all projects done in the spare time of the people affected. systemd is a backdoor in that, by means of vendor lock-in, it will make future subversing a system easier, because there will be no alternative implementation of * init * syslog * ntpd * dhcp, IIUC * udev * dbus * and whatever else systemd is going to ship or push into the kernel any more, to which people could switch in case of a fatal emergency with the systemd-provided code. For example, systemd has support for its own (S)NTP client, but also supports xntpd (rudely leaving OpenNTPD out already). The commit message explains that the xntpd support will eventually go away. This is the best example of, hm, there's no English idiomatic expression I'm told in IRC... an entry drug (provided for free, and making you dependent on getting even more of that fix). Similar to MSDNAA except worse yet. Yes, I just compared systemd to a drug. This feels strangely right in so many ways. This means that systemd not will but already has severely compromised the OSS ecosystem. Heterogenous systems are the enemy of agencies, after all, you know? bye, //mirabilos -- 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/lp66ju$mhj$1...@ger.gmane.org
Re: systemd is here to stay, get over it now
The problem is that some people bitch endlessly abut how evil systemd is _instead_of_ producing software (not just patches) to replace what systemd offers. Abstracting away from your somewhat offensive choice of language, that's a good point. As far as I'm aware, the only major distribution that has been doing the right thing is OpenWRT, which has recently switched to procd, a locally developed init replacement. git clone git://nbd.name/luci2/procd.git -- Juliusz -- 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/87bnt5i9rw.wl@pps.univ-paris-diderot.fr
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: systemd is here to stay, get over it now
Hi, Thorsten Glaser: systemd is a backdoor in that, like the availability of Steam games for DDs, it has a chance to hinder the progress of all projects done in the spare time of the people affected. Yeah. It has a chance. It also has a chance to give people a big chunk of spare time back, because they can find and fix their daemon startup bugs a whole lot faster (and more consistently) than with SysVinit. Your chance is pure speculation. My chance is personal experience. systemd is a backdoor in that, by means of vendor lock-in Which vendor are you talking about, exactly? any more, to which people could switch in case of a fatal emergency with the systemd-provided code. I'd assume that switching from systemd to something_else in an emergency is a whole lot easier than switching from Linux to something_else. The solution to any grave bug will be, like with any piece of userland software, to fix that bug and restart systemd. You can't do that with the kernel yet (reboot required), yet I don't hear a lot of people complaining about vendor lock-in by the Linux kernel. Yes, I just compared systemd to a drug. This feels strangely right in so many ways. One might want to counter this argument by comparing systemd-bashing to a drug. That feels also strangely right in many ways. Again: You want diversity and a non-systemd Debian? Fine. Then shut up and help with the work required to get there, instead of complaining on -devel. We have all heard the arguments. And the arguments. Multiple times. Enough said. I, for one, will now *plonk* this thread. -- -- 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/20140704130433.gi23...@smurf.noris.de
Re: systemd is here to stay, get over it now
Juliusz Chroboczek wrote: The problem is that some people bitch endlessly abut how evil systemd is _instead_of_ producing software (not just patches) to replace what systemd offers. Abstracting away from your somewhat offensive choice of language, that's a good point. As far as I'm aware, the only major distribution that has Eh, why would I need to write anything? BSD init WFM. SYSV init with file-rc WFM unless someone breaks it again. I can live with SYSV init with sysv-rc, if it must be (but then, please, no parallel boot). I believe I could live with runit as init. been doing the right thing is OpenWRT, which has recently switched to procd, a locally developed init replacement. procd⦠ubus⦠*shudder* but at least they're consistent. OpenWrt has been doing their own way for some time already. bye, //mirabilos -- 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/lp6908$sp4$1...@ger.gmane.org
Re: systemd is here to stay, get over it now
Dominik George dixit: systemd, in its nature as an init system, starts what you tell it to start. There is nothing that can prevent it from starting openntpd if you want that. If you through a service file at it, or even an LSB init script, then systemd has no choice but to start it. No, this is about something else. This is about… I think it’s called “services” and it is something other packages require, and I believe it has to do something with dbus. This is not just about running an NTP dæmon, but, AIUI, some APIs to manage and query it (just like hostnamed, timezoned, etc). Of course I can start OpenNTPD now (and cause e.g. xntpd’s start to fail, with that), but some software will complain then. I have *no* idea for what people will want to use this, but… I cannot cite my sources as I got most of this from a private IRC channel. But there was some commit message in a systemd- or related git repository hinting at this. I did not save the link. bye, //mirabilos -- “ah that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good humour, much less German admin-style humour” -- 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/pine.bsm.4.64l.1407041310230.17...@herc.mirbsd.org
Re: systemd is here to stay, get over it now
Hi Thorsten, while I tend to basically acknowledge your points here, there is still one thing you obviously did not get until now, if I followed along correctly. For example, systemd has support for its own (S)NTP client, but also supports xntpd (rudely leaving OpenNTPD out already). The commit message explains that the xntpd support will eventually go away. systemd, in its nature as an init system, starts what you tell it to start. There is nothing that can prevent it from starting openntpd if you want that. If you through a service file at it, or even an LSB init script, then systemd has no choice but to start it. That said, dropping support for service foo in systemd means that service foo dropped both their service file and their init script, _not_ systemd doing anything. If you have sources proving that systemd is planning to do antivirus-like signature checking on binaries to detect openntpd or something, then please provide such. I tend to not believe that! Cheers, Nik -- 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/dea96464-5991-42f2-8433-fad892d19...@email.android.com
Re: systemd is here to stay, get over it now
On Thu, Jul 03, 2014 at 08:40:59PM +0200, Matthias Urlichs wrote: The problem is that some people bitch endlessly abut how evil systemd is _instead_of_ producing software (not just patches) to replace what systemd offers. But if they don’t want the systemd features why should they write software to replace systemd? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: systemd is here to stay, get over it now
On Fri, 04 Jul 2014, Matthias Urlichs wrote: Then shut up and help with the work required to get there, Please stop this inpoliteness, or I request a ban on all mailing lists due to permanent breaking of Code of Conduct. (Long live the CoC - I am *so* happy to have it!! - hope someone got the sarcasm) Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- 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/20140704132502.gw19...@auth.logic.tuwien.ac.at
Re: systemd is here to stay, get over it now
Thorsten Glaser wrote: You know, backdoors are not only code vulnerabilities. systemd is a backdoor in that, like the availability of Steam games for DDs, it has a chance to hinder the progress of all projects done in the spare time of the people affected. Thorsten, you're too late. The argument is lost and Debian is moving to systemd. We followed our rules and the TC chose that route. I won't pretend to be happy about this - I'm *seriously* not a fan of either systemd or its main developers myself. But sometimes you just have to accept things you don't like and move on. Right now *you* and others are hindering progress and wasting time of other developers with this constant bickering and sniping. If you must do it, start the GR and see how that goes. I even offer to second it just to help get the issue resolved. If you don't want to go the GR route, then please quit whining. You're achieving nothing but making yourself look bad. We're 4 months from the Jeesie freeze and we all have better stuff to be doing than posting repetitive crap on the lists like this. -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- 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/e1x33b7-0001p1...@mail.einval.com
Re: systemd is here to stay, get over it now
Matthias Urlichs wrote: Thorsten Glaser: systemd is a backdoor in that, like the availability of Steam games for DDs, it has a chance to hinder the progress of all projects done in the spare time of the people affected. Yeah. It has a chance. Yes. (I was more or less referring to this discussion as time killer, though.) It also has a chance to give people a big chunk of spare time back, ... maybe... because they can find and fix their daemon startup bugs a whole lot faster (and more consistently) than with SysVinit. In SYSV init, I can just use set -x. That just rocks. (But anyway, I do not wish to discuss this here - there are more suitable places/threads.) systemd is a backdoor in that, by means of vendor lock-in Which vendor are you talking about, exactly? vendor lock-in is an atomic expression, meaning the mechanism to have one thing from vendor X depend on one other thing from vendor X, which depends on just another thing from vendor X, without being able to exchange components against those from another vendor. Good example here is autoconf 2.62 and later, which depend on GNU m4, although previous versions also worked with BSD m4. (There are patches, so 2.62 works but 2.63 doesn't, now.) GNU software in general is the most prominent example of vendor lock-in I know. The vendor in this case is the GNU project. In the systemd case, it's systemd, obviously. The solution to any grave bug will be, like with any piece of userland software, to fix that bug and restart systemd. You can't do that with the If you can fix the bug, sure. If not... or not in time... Again: You want diversity and a non-systemd Debian? Fine. Then shut up and help with the work required to get there, With Debian as it is now, there is nothing needed (except to upload the prevent-systemd package in its next iteration). Debian as it is now works just fine without systemd. If *you* want to change that, it's *you* who are breaking it. bye, //mirabilos -- 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/lp6a5v$sp4$2...@ger.gmane.org
Re: systemd is here to stay, get over it now
Hi, Norbert Preining: Then shut up and help with the work required to get there, Please stop this inpoliteness, or I request a ban on all mailing lists due to permanent breaking of Code of Conduct. *what* Seriously?!? One of us seems to harbor a severe misconception or two about what kind of behavior the CoC is supposed to sanction, and I sure hope it's not me. -- -- 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/20140704140238.gj23...@smurf.noris.de
GR - collecting proposals (was Re: systemd is here to stay, get over it now)
Steve McIntyre wrote: with this constant bickering and sniping. If you must do it, start the GR and see how that goes. I even offer to second it just to help get Can you help formulate? I do not feel my English skills are up to that. Also, what options do we need? 1) systemd is the only init system supported in jessie (for Linux) = we accept the change and require all users to follow our new default 2) systemd and sysvinit are both supported in jessie, but sysvinit is only supported for systems upgraded from older Debian installs; package maintainers have to at least not actively break existing sysvinit support and should accept patches to keep sysvinit with sysv-rc working = we accept the change but do not enforce it on all users; we intend to keep the old way working for as long as reasonably possible, even though it means degraded operation for some (maintenance burden is on the package maintainers, plus a possible team of volunteers) 3) systemd and sysv are both supported in jessie (for all ports, probably - Hurd in any case, I don't know what the kFreeBSD people have); package maintainers have to at least not actively break existing sysvinit support and must accept patches to keep sysvinit with sysv-rc working - new installations must either offer a choice of init system, or install systemd and offer switching the init system to sysvinit later (e.g. via apt-get install, possibly with the famous Yes I know what I am doing prompt) (maintenance burden is on the maintainers of d-i and systemd and sysvinit, for this; the way is to be decided by CTTE if those do not find a suitable one by themselves) - existing installations of older (pre-jessie) Debian may be upgraded to our new standard init system systemd, but only after the user has been suitably warned, e.g. via a debconf propmpt at priority medium (i.e. not shown to novices) (maintenance burden is on the package maintainers, plus a possible team of volunteers, for the init scripts; maintenance burden for the upgrade scenario is with the maintainers of the affected packages (sysvinit and systemd, AIUI)) = we promote our new default, but permit our users to choose for themselves, if they feel they are technically skilled enough to make this choice and live with the limitations of a non-standard system; switching back and forth between the two supported systems is always possible 4) all init systems currently in Debian are supported in jessie; maintainers must support sysvinit at least as in 3) and are encouraged to accept patches for file-rc, upstart, possibly OpenRC and runit - new installations operate as in 3) except support for all init systems that are not either the old default (sysv-rc) or the new default (systemd) may use a more complicated path (e.g. switch from systemd to sysvinit first, then to the other init system) (maintenance burden for sysvinit is on the package maintainers; maintenance burden for the other init systems is on the maintainers of those init systems; the path to switch between init systems is to be decided by CTTE if the maintainers of the init systems do not find a suitable way by themselves) - existing installations can keep running, although we may migrade existing installations of the old default to the new default as in 3) above (e.g. debconf medium) = we promote freedom of choice, and our new default is the preselected choice, but users who feel they can cope with it are free to choose differently; switching back and forth between init systems is subject to whatever the maintainers come up, or CTTE if they don't, but switching should be possible and defined but not necessarily easy You may note I agree, in all of these proposed options, that we can change the default init system to our new default which CTTE has decided on, for both new and existing installations; I just require that the user is to be informed about it and can abort the upgrade if they do not wish the change (at debconf medium priority; I think about something like the linux-image packages do to prevent removal of the running kernel), and that the user has a defined way to switch between init systems. Thanks in advance, //mirabilos -- 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/lp6dlk$tvc$1...@ger.gmane.org
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: systemd is here to stay, get over it now
Matthias, On Fri, Jul 04, 2014 at 04:02:38PM +0200, Matthias Urlichs wrote: Norbert Preining: Then shut up and help with the work required to get there, Please stop this inpoliteness, or I request a ban on all mailing lists due to permanent breaking of Code of Conduct. *what* Seriously?!? One of us seems to harbor a severe misconception or two about what kind of behavior the CoC is supposed to sanction, and I sure hope it's not me. While Thorsten's unconstructive mails evoke much the same reaction from me, I think you've been very aggressive in this thread (not to mention dismissive of the legitimate perspectives of those who don't agree that a move to systemd is an improvement), and shut up is an impolite thing to say. While I have no interest in joining Norbert in calling for your ban, I would like to ask you to consider taking a step back from this thread, and evaluating whether such messages are actually contributing to bringing these discussions to a conclusion. -- 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
Re: systemd is here to stay, get over it now
While I have no interest in joining Norbert in calling for your ban, Having had the pleasure to meet Norbert in person, I have no doubt that he was joking when appealing to the CoC. (I did find his comment funny -- actually, I find the CoC ifself pretty funny --, but I realise that this is an international mailing list and that Austrian-Japanese humour is not necessarily obvious to everyone.) Coming back to the subject at hand, this thread has been pretty productive in showing that I'm not alone in wanting my servers and my netbook to run Debian without systemd (I've given up on my full-fledged desktops, for better or worse), and in showing that it can be achieved with the existing mechanisms (apt pinning). I have good hope that the systemd maintainers will take this minority of users into account in their further development. -- Juliusz -- 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/87zjgoyhwl.wl@pps.univ-paris-diderot.fr
Re: systemd is here to stay, get over it now
]] Juliusz Chroboczek While I have no interest in joining Norbert in calling for your ban, Having had the pleasure to meet Norbert in person, I have no doubt that he was joking when appealing to the CoC. I have yet to find mr Preining funny in any of his mails sent to any of the lists I read. Humour, except when accompanied with explicit tags of HERE BE HUMOUR does not work very well on large lists. I have good hope that the systemd maintainers will take this minority of users into account in their further development. I (and I believe I speak for all the systemd maintainers) bear no ill will against non-systemd users and will try to avoid breaking stuff for them, but it's also a use case we don't hit, so breakage there is less likely to be seen by us. We'll do our best to fix it when reported, of course. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m2mwcoajxz@rahvafeir.err.no
Re: systemd is here to stay, get over it now
I have yet to find mr Preining funny in any of his mails sent to any of the lists I read. Humour, except when accompanied with explicit tags of HERE BE HUMOUR does not work very well on large lists. Well, because I don't write WARNING HUMOUR COMING and then some people don't get it bad for them ... good for me .. gives me more laughs. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- 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/20140705003821.gc23...@auth.logic.tuwien.ac.at
Re: systemd is here to stay, get over it now
Tollef Fog Heen tfh...@err.no wrote: I [...] will try to avoid breaking stuff I expect no less from a Debian Developer. but it's also a use case we don't hit, so breakage there is less likely to be seen by us. We'll do our best to fix it when reported, of course. That is good to hear. It would be even better if actions followed. I'll remind you that this thread started with systemd breaking my system, and a systemd maintainer summarily closing my bug report. Not once, but twice. Summarily dismisisng non-systemd issues, unfortunately, is the kind of attitude that we've come to expect from many (not all) systemd supporters. -- Juliusz -- 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/87d2dky5nl.wl@pps.univ-paris-diderot.fr
Re: systemd is here to stay, get over it now
Hi, Steve Langasek: While I have no interest in joining Norbert in calling for your ban, I would like to ask you to consider taking a step back from this thread, and evaluating whether such messages are actually contributing to bringing these discussions to a conclusion. Thanks for the honest feedback. -- -- 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/20140705012101.gl23...@smurf.noris.de
Re: systemd is here to stay, get over it now
Juliusz Chroboczek j...@pps.univ-paris-diderot.fr writes: I'll remind you that this thread started with systemd breaking my system, and a systemd maintainer summarily closing my bug report. Not once, but twice. Because the bug was already fixed in a newer version of systemd. While we're reminding people of things. Summarily dismisisng non-systemd issues, unfortunately, is the kind of attitude that we've come to expect from many (not all) systemd supporters. I believe the description of what happened as summarily dismissing is factually inaccurate. In fact, he investigated and confirmed that the bug was already fixed and closed it accordingly. You have a legitimate cause for complaint, which I think has already been heard and registered, that the response was too terse and that you didn't realize this is what the response meant, but the problem was not dismissed. -- 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/87k37stwv6@windlord.stanford.edu
Re: systemd is here to stay, get over it now
also sprach Stephan Seitz stse+deb...@fsing.rootsland.net [2014-07-04 15:09 +0200]: But if they don’t want the systemd features why should they write software to replace systemd? Because there are better ways to implement it, including more granular approaches and less of a desktop focus. And you could be a better upstream. -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems it isn't pollution that's harming the environment. it's the impurities in our air and water that are doing it. - dan quayle digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
systemd is here to stay, get over it now (was: Re: Pinning vs. conflicting)
Folks, Le jeudi, 3 juillet 2014, 14.20:24 Juliusz Chroboczek a écrit : Isn't the proper solution to add blacklisting support to dpkg, then? The proper solution is to stop trying to hide ourselves from to the fact that some sort of systemd interfaces have been made unavoidable in modern desktop environments (fact which is rightfully reflected in our dependencies tree). Many of the interfaces of systemd are here to stay and will make their way through our stack (like it or not); fact is they already made it quite far in at least Gnome and KDE. As developers of Debian (which this list is about afterall), our proper solution is not to forbid systemd on our various systems while hoping that not too many things will end up depending on its interfaces and that our working setup for so long that I can't even remember will magically keep working while the underlying stack keeps evolving (with 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 this behavior (and its flaming counterpart) is actively hurting the project. The proper solution is to fix (or help fix) all use-cases that became broken with the arrival of systemd and/or make sure that the dependencies tree allows the systemd shim to be installed and working, as well as making sure this shim stays relevant and a working and transparent replacement to systemd itself. We are collectively developing an operating system, not only assembling a set of packages for our own benefit. Our priority is our users and they rightfully expect a rocking Jessie release, which will happen with systemd as default init system. Will we make this happen or will we just end up having gone through an endless bikeshedding discussion about a package that forbids the installation of the default init system!? Can we get over this now and start making Jessie the most awesome stable release we've ever prepared together? Cheers, OdyX signature.asc Description: This is a digitally signed message part.
sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
On Thu, 3 Jul 2014, Didier 'OdyX' Raboud wrote: The proper solution is to stop trying to hide ourselves from to the fact that some sort of systemd interfaces have been made unavoidable in modern desktop environments (fact which is rightfully reflected in our Eh… you know… these are not all that Debian runs. A lot of Debian systems even run without dbus! As developers of Debian (which this list is about afterall), our proper solution is not to forbid systemd on our various systems while hoping Why not? 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. This is absolutely not what I’d call a project(!) decision. Also… see below. We are collectively developing an operating system, not only assembling Yes… a universal one. 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. And alone the fact that the systemd issue *continuously* pops up shows you that it is nowhere even near solved. Furthermore, the TC(-chairman) decision only was on the default init system for the Linux ports of jessie. 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. (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.) 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… bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- 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/alpine.deb.2.11.1407031652560.4...@tglase.lan.tarent.de
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: systemd is here to stay, get over it now (was: Re: Pinning vs. conflicting)
Didier, Hello. The proper solution is to stop trying to hide ourselves from to the fact that some sort of systemd interfaces have been made unavoidable in modern desktop environments (fact which is rightfully reflected in our dependencies tree). Can we get over this now and start making Jessie the most awesome stable release we've ever prepared together? For some of us there will never be an awesome Debian release that at it's core contains systemd. It's core developers, Lennart Poettering and Kay Sievers, work for a company that has multi-billion dollar contracts with NSA. It is your choice to assume good faith on their part. It is our choice not to. Please respect our decision to stay away from systemd and still be Debian users. If possible, please, don't resist changes that make our lives easier. -- For shame deny that thou bear'st love to any, Who for thy self art so unprovident. Grant, if thou wilt, thou art beloved of many, But that thou none lov'st is most evident: For thou art so possessed with murderous hate, That 'gainst thy self thou stick'st not to conspire, Seeking that beauteous roof to ruinate Which to repair should be thy chief desire. O! change thy thought, that I may change my mind: Shall hate be fairer lodged than gentle love? Be, as thy presence is, gracious and kind, Or to thyself at least kind-hearted prove: Make thee another self for love of me, That beauty still may live in thine or thee. W. Shakespeare
Re: systemd is here to stay, get over it now
Alexander Pushkin alex904...@mail.ru writes: For some of us there will never be an awesome Debian release that at it's core contains systemd. It's core developers, Lennart Poettering and Kay Sievers, work for a company that has multi-billion dollar contracts with NSA. It is your choice to assume good faith on their part. It is our choice not to. I'm mildly curious how you managed to assemble a Debian system that does not have libselinux1 installed. It was originally written by the NSA, you know. Or, for that matter, how you assembled a Debian system without glibc, or the Linux kernel, or gcc, or numerous other packages to which Red Hat, and Google, and other companies with multi-million dollar US defense and NSA contracts contributed substantially to or were primary developers of. Put another way, to quote a recent US federal ruling on a different ideological topic, these are not the arguments of serious people. Please respect our decision to stay away from systemd and still be Debian users. If possible, please, don't resist changes that make our lives easier. systemd is open source. Every line of code is available to you to read. If you think the NSA has hidden some strange back-door in systemd, please go discover it. You would make front-page headlines around the world, and do a great service to the open source community. Nothing is standing in your way. If the NSA are going to hide back-doors in open source projects (a rather dubious idea to start with, given how difficult it is and how much social blowback there would be when such a thing was inevitably discovered), they would focus on highly-opaque code that cannot be easily audited except by experts. That's why people are very worried about crypto libraries and particularly crypto algorithms that involve special magic numbers. That's an obvious place to conceal such a thing. systemd is not highly opaque code that can only be audited by experts. It's not doing particularly complex things; its appeal instead lies in the architectural model, developed after a few previous attempts to do similar things and based on lessons learned from them. The code itself is similar in readability and complexity to many, many other programs in our distribution, and considerably *easier* to audit than, say, the Linux kernel (which would be a more fruitful place for embedding back-doors). I have no respect for bizarre conspiracy theories, and don't think Debian is well-served by having respect for such things either. We're trying to build the best free software distribution we can, not trying to run a divestiture campaign from Red Hat or some other company based on who they do business with. If you feel that's an appropriate political response, more power to you, but you are going to find it very, very hard to entirely avoid Red-Hat-developed free software in the Linux ecosystem. -- 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/87wqbuz4db@windlord.stanford.edu
Re: systemd is here to stay, get over it now (was: Re: Pinning vs. conflicting)
Hi, Alexander Pushkin: It's core developers *Its. I think we can do without (quite unfounded, IMHO) insinuations that systemd is somehow infected with an NSA-sponsored backdoor or two, thank you very much. Please respect our decision to stay away from systemd and still be Debian users. If possible, please, don't resist changes that make our lives easier. *Sigh*. The problem is not that anybody resists such changes. The problem is that some people bitch endlessly abut how evil systemd is _instead_of_ producing software (not just patches) to replace what systemd offers. For thou art so possessed with murderous hate, Three words do come to mind … which I'll not write down here, in order not to escalate this discussion. You may mail me your guesses privately. ;-) -- -- 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/20140703184059.ge23...@smurf.noris.de
Re: systemd is here to stay, get over it now
On Thu, Jul 03, 2014 at 11:25:36AM -0700, Russ Allbery wrote: [snip] If the NSA are going to hide back-doors in open source projects (a rather dubious idea to start with, given how difficult it is and how much social blowback there would be when such a thing was inevitably discovered), they would focus on highly-opaque code that cannot be easily audited except by experts. That's why people are very worried about crypto libraries and particularly crypto algorithms that involve special magic numbers. That's an obvious place to conceal such a thing. An obvious pick that'd be both opaque and hard-hitting against a saddening amount of open source systems would be the non-free NVidia driver. Why would the NSA take even the slightest risk of discovery when they could put a backdoor in a driver for a piece of hardware that has full access to your system? Kind regards, David -- /) David Weinehall t...@debian.org /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- 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/20140703205053.gc16...@hirohito.acc.umu.se
Re: systemd is here to stay, get over it now (was: Re: Pinning vs. conflicting)
Hi, Matthias Urlichs matth...@urlichs.de writes: Please respect our decision to stay away from systemd and still be Debian users. If possible, please, don't resist changes that make our lives easier. *Sigh*. The problem is not that anybody resists such changes. I disagree. People *do* in fact resist changes that makes the live of other people considerable easier. Sorry to say so, but this is effectively what all this FUD and useless discussion about packages depending on systemd is about -- resisting a change, that makes the live of the maintainers and developers of said packages considerable easier. I find it deeply funny and ironic that this is actually used to defend the very same behaviour, that is critized. So, if possible, please, systemd haters, don't resist changes that make our lives easier. Best, Merovius -- 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/87bnt610ws.fsf@rincewind.i-did-not-set--mail-host-address--so-tickle-me
Re: systemd is here to stay, get over it now
On 03/07/14 22:50, David Weinehall wrote: Why would the NSA take even the slightest risk of discovery when they could put a backdoor in a driver for a piece of hardware that has full access to your system? Or on the firmware of your HDD/SDD: http://s3.eurecom.fr/~zaddach/docs/Recon14_HDD.pdf signature.asc Description: OpenPGP digital signature
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
