-----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 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/53b6a1c2.9000...@fastmail.fm
