24 ms·

In my opinion, there is never a good time to restart. That is simply an artifact of the sad historical circumstances that led to the current state of operating

by Decade 10y ago

In my opinion, there is never a good time to restart. That is simply an artifact of the sad historical circumstances that led to the current state of operating systems. I don’t particularly enjoy waking up to all my programs are closed because Windows decided that tonight was the night that it restarted. It’s slightly better on MacOS, where programs using MacOS-specific APIs can restore their state on startup, but that doesn’t include most of the third-party applications. But MacOS doesn’t force the reboot. Yet.

fapjacks 10y ago
For the record, Linux does not do this, and it is an operating system.
- notalaser 10y ago
  On the other hand, many/most distributions have major releases every 6-12 months, and the upgrade process is a lot more hit and miss. I have Debian and (unexpectedly enough...) Fedora services that I've managed to drag along two and, respectively, three major releases. On the other hand, I can't remember ever managing to get a clean upgrade on Ubuntu after 8.04 or so. My latest attempt has been miserable, I spent half a day nursing my Ubuntu station at work back to health. Besides, it's a trend that I expect to see reversed soon enough, given the direction in which Linux desktop is heading nowadays. Edit: empirically, what has greatly simplified my life in this matter is being old-fashioned about partitioning. I keep /home and /opt separate, so upgrading typically consists of saving a list of packages, wiping everything but /home and /opt, doing a fresh install and reinstalling the packages. Depending on what I'm installing (OpenBSD on my laptop, Debian on my desktop) it takes about five minutes of accepting defaults and waiting for progress bars to fill, then another ten minutes until the packages installs (most of those ten minutes is spent on LaTeX, to be honest).
  - fabianhjr 10y ago
    > many/most distributions have major releases every 6-12 months, and the upgrade process is a lot more hit and miss. You might want to try a rolling release distro, something like Antergos (Arch + Tweaks)
    - notalaser 10y ago
      I used Gentoo for a very long time (2005-ish to 2009 or so) and tried Arch, too, both back then (after I, uh, toasted a power supply compiling packages for five days straight) and more recently, about a year ago. It's a very good approach, but far too high-maintenance for my taste. During my (latest) short stint with Arch, I became a walking bug tracker. Stick to Adwaita because everything else breaks, don't do that in a KDE app because it crashes, try to reboot my computer only to find out it's stuck in a loop because some process can't notify some other process through D-Bus... There's a bunch of stuff that doesn't work on Debian, either, but at least it's the same stuff for about a year or so. Nowadays I get to write Linux software at work so I get all the bleeding-edge stuff there, and dealing with the latest and greatest breakage is part of my everyday job. I have no desire to do it at home, too. Edit: plus, to put it bluntly, it's really no longer fun. When I said goodbye to Windows, back in nineteen-ninety-something, I did it to get away from the mind-boggling complexity and uncustomizable blackbox blurb on my hard drive. Nowadays, it's an order of magnitude more complex; some of it is unwarranted and much of it just isn't reliable. Windows' and OS X's isn't, either, but at least it's nicely tucked away behind an interface that works, so you're not exposed to the crap underneath. I spend a lot more time wrestling with my computer than I'd like to. I can mostly navigate through this whole maze of thisandthatkit and systemd-everything, largely because I'm exposed to it for eight hours a day, whether I want it or not, and have seen it being developed. But I don't think it's sustainable, and I have a feeling I'm going to call it quits one day.
      - digi_owl 10y ago
        Best i can tell the complexity comes from a misguided idea that if just the DEs simplify and automate common tasks, Linux on the desktop will happen. End result is that the DE people keep pushing ever deeper in the stack, violating long standing layering, that made it easier to reason about why something broke, in the process.
    - cptskippy 10y ago
      This type of grass is always greener answer is why the Linux desktop experience is so poor. If someone follows that advice they may fix one issue they have but in return they get a whole new set of problems to discover and troubleshoot or run away from.
- deleted 10y ago
  [deleted]
- stinos 10y ago
  If with this you mean requiring a restart then arent' you wrong? Ubuntu is linux, right, so it's an operating system, and it has stuff like /var/run/reboot-required.pkgs so it's not like all linux flavors out there don't ever require reboots. If you meant forced restarts at a given time (or whatever windows 10 does) then you're right. For now, and hopefully forever.
  - fapjacks 10y ago
    No, you're wrong. Ubuntu will not ever force you to reboot your machine. The most it will do is recommend a restart.
- blakeyrat 10y ago
  Microsoft restarts because updates are in files that are "locked" and can't be switched-out until the system is rebooted. After you install the update, but before you reboot, your system is still running the old known-buggy code. Linux doesn't lock files; instead it creates in-memory copies of them. So the updater can update the on-disk version without any troubles. But if you think about it, it has the exact same problem: until you reboot, your Linux box is still running the known-buggy code. So there's absolutely no technical reason Windows needs to reboot more than Linux. The only difference is that Linux developers decided "meh, the user can reboot when they want". But unless you reboot after installing your Linux updates, your computer still has the bugs.
  - jameskegel 10y ago
    > But if you think about it, it has the exact same problem: until you reboot, your Linux box is still running the known-buggy code. This has not been true for some time, and not in any mainstream distributions currently that come to mind.
    - blakeyrat 10y ago
      How do they solve the problem without requiring, at minimum, closing all of the user's applications and restarting them, then closing all system services and restarting them? (At which point, you've basically done a de-facto OS restart.)
      - jameskegel 10y ago
        >How do they solve the problem without requiring, at minimum, closing all of the user's applications and restarting them, then closing all system services and restarting them? (At which point, you've basically done a de-facto OS restart.) But this is not what you suggested, is it?
        blakeyrat 10y ago
        I don't understand this answer, and I don't recall "suggesting" anything.
WorldMaker 10y ago
One of the things I thought Windows 8 did really right was trying to instill into applications the lifecycle that they could be force closed/rebooted at any time and should be good at saving and restoring state across application starts. This is good beyond just system restarts and good in general to know that applications would typically come back to where you left off after the system losing connectivity or going to sleep or unloading an application to save memory/CPU while you aren't actively using it. The complaints about this lifecycle model from app developers is that is hard to program for. Windows 8 was also strict enough forcing this lifecycle (closing out applications sometimes seconds after minimizing and attempting to restore them quickly on window restore) that it showed how bad developers can be at programming hard things like proper app lifecycle management, so they begged Windows to be less strict about it. (That was one of the magic things about Windows 8 that Windows 10 doesn't quite replicate: minimizing a properly built application and watching the application's memory and CPU usage quickly drop to zero.)
- fake-name 10y ago
  The problem with this lifecycle assumption is that there is no way to opt out. I have a "metro" style SSH application, and windows regularly decides it should close it, which kills my active SSH sessions. I understand that they removed the ability to opt-out to force developers to change to a more appropriate model, but there are cases where a task cannot be suspended (because, for example, it's interacting with another computer). Having to re-log-in to my ssh session the 4th or 5th time in an hour is absolutely infuriating.
  - WorldMaker 10y ago
    You can opt out by creating a background process. The thing that makes that part complicated is that there is a background process lifecycle to learn (including interactions between a UI process and background process). Also, Windows wants a bit more of an explicit knowledge than say classic Win32 about what the background process is for so it can best manage it. The support for background processes continues to improve. Windows 10, for instance, now supports a "single instance" background processing model where background processes can be seen as an invocation of the UI app (if already running) and vice versa (the UI app is presented as an invocation to the background process if that is already running) with hand-offs from one to the other, simplifying the programming of some of the interactions between background and UI for some apps.

by Decade 10y ago

fapjacks 10y ago

For the record, Linux does not do this, and it is an operating system.

notalaser 10y ago
On the other hand, many/most distributions have major releases every 6-12 months, and the upgrade process is a lot more hit and miss. I have Debian and (unexpectedly enough...) Fedora services that I've managed to drag along two and, respectively, three major releases. On the other hand, I can't remember ever managing to get a clean upgrade on Ubuntu after 8.04 or so. My latest attempt has been miserable, I spent half a day nursing my Ubuntu station at work back to health. Besides, it's a trend that I expect to see reversed soon enough, given the direction in which Linux desktop is heading nowadays. Edit: empirically, what has greatly simplified my life in this matter is being old-fashioned about partitioning. I keep /home and /opt separate, so upgrading typically consists of saving a list of packages, wiping everything but /home and /opt, doing a fresh install and reinstalling the packages. Depending on what I'm installing (OpenBSD on my laptop, Debian on my desktop) it takes about five minutes of accepting defaults and waiting for progress bars to fill, then another ten minutes until the packages installs (most of those ten minutes is spent on LaTeX, to be honest).
- fabianhjr 10y ago
  > many/most distributions have major releases every 6-12 months, and the upgrade process is a lot more hit and miss. You might want to try a rolling release distro, something like Antergos (Arch + Tweaks)
  - notalaser 10y ago
    I used Gentoo for a very long time (2005-ish to 2009 or so) and tried Arch, too, both back then (after I, uh, toasted a power supply compiling packages for five days straight) and more recently, about a year ago. It's a very good approach, but far too high-maintenance for my taste. During my (latest) short stint with Arch, I became a walking bug tracker. Stick to Adwaita because everything else breaks, don't do that in a KDE app because it crashes, try to reboot my computer only to find out it's stuck in a loop because some process can't notify some other process through D-Bus... There's a bunch of stuff that doesn't work on Debian, either, but at least it's the same stuff for about a year or so. Nowadays I get to write Linux software at work so I get all the bleeding-edge stuff there, and dealing with the latest and greatest breakage is part of my everyday job. I have no desire to do it at home, too. Edit: plus, to put it bluntly, it's really no longer fun. When I said goodbye to Windows, back in nineteen-ninety-something, I did it to get away from the mind-boggling complexity and uncustomizable blackbox blurb on my hard drive. Nowadays, it's an order of magnitude more complex; some of it is unwarranted and much of it just isn't reliable. Windows' and OS X's isn't, either, but at least it's nicely tucked away behind an interface that works, so you're not exposed to the crap underneath. I spend a lot more time wrestling with my computer than I'd like to. I can mostly navigate through this whole maze of thisandthatkit and systemd-everything, largely because I'm exposed to it for eight hours a day, whether I want it or not, and have seen it being developed. But I don't think it's sustainable, and I have a feeling I'm going to call it quits one day.
    - digi_owl 10y ago
      Best i can tell the complexity comes from a misguided idea that if just the DEs simplify and automate common tasks, Linux on the desktop will happen. End result is that the DE people keep pushing ever deeper in the stack, violating long standing layering, that made it easier to reason about why something broke, in the process.
  - cptskippy 10y ago
    This type of grass is always greener answer is why the Linux desktop experience is so poor. If someone follows that advice they may fix one issue they have but in return they get a whole new set of problems to discover and troubleshoot or run away from.
deleted 10y ago
[deleted]
stinos 10y ago
If with this you mean requiring a restart then arent' you wrong? Ubuntu is linux, right, so it's an operating system, and it has stuff like /var/run/reboot-required.pkgs so it's not like all linux flavors out there don't ever require reboots. If you meant forced restarts at a given time (or whatever windows 10 does) then you're right. For now, and hopefully forever.
- fapjacks 10y ago
  No, you're wrong. Ubuntu will not ever force you to reboot your machine. The most it will do is recommend a restart.
blakeyrat 10y ago
Microsoft restarts because updates are in files that are "locked" and can't be switched-out until the system is rebooted. After you install the update, but before you reboot, your system is still running the old known-buggy code. Linux doesn't lock files; instead it creates in-memory copies of them. So the updater can update the on-disk version without any troubles. But if you think about it, it has the exact same problem: until you reboot, your Linux box is still running the known-buggy code. So there's absolutely no technical reason Windows needs to reboot more than Linux. The only difference is that Linux developers decided "meh, the user can reboot when they want". But unless you reboot after installing your Linux updates, your computer still has the bugs.
- jameskegel 10y ago
  > But if you think about it, it has the exact same problem: until you reboot, your Linux box is still running the known-buggy code. This has not been true for some time, and not in any mainstream distributions currently that come to mind.
  - blakeyrat 10y ago
    How do they solve the problem without requiring, at minimum, closing all of the user's applications and restarting them, then closing all system services and restarting them? (At which point, you've basically done a de-facto OS restart.)
    - jameskegel 10y ago
      >How do they solve the problem without requiring, at minimum, closing all of the user's applications and restarting them, then closing all system services and restarting them? (At which point, you've basically done a de-facto OS restart.) But this is not what you suggested, is it?
      - blakeyrat 10y ago
        I don't understand this answer, and I don't recall "suggesting" anything.

WorldMaker 10y ago

One of the things I thought Windows 8 did really right was trying to instill into applications the lifecycle that they could be force closed/rebooted at any time and should be good at saving and restoring state across application starts. This is good beyond just system restarts and good in general to know that applications would typically come back to where you left off after the system losing connectivity or going to sleep or unloading an application to save memory/CPU while you aren't actively using it. The complaints about this lifecycle model from app developers is that is hard to program for. Windows 8 was also strict enough forcing this lifecycle (closing out applications sometimes seconds after minimizing and attempting to restore them quickly on window restore) that it showed how bad developers can be at programming hard things like proper app lifecycle management, so they begged Windows to be less strict about it. (That was one of the magic things about Windows 8 that Windows 10 doesn't quite replicate: minimizing a properly built application and watching the application's memory and CPU usage quickly drop to zero.)

fake-name 10y ago
The problem with this lifecycle assumption is that there is no way to opt out. I have a "metro" style SSH application, and windows regularly decides it should close it, which kills my active SSH sessions. I understand that they removed the ability to opt-out to force developers to change to a more appropriate model, but there are cases where a task cannot be suspended (because, for example, it's interacting with another computer). Having to re-log-in to my ssh session the 4th or 5th time in an hour is absolutely infuriating.
- WorldMaker 10y ago
  You can opt out by creating a background process. The thing that makes that part complicated is that there is a background process lifecycle to learn (including interactions between a UI process and background process). Also, Windows wants a bit more of an explicit knowledge than say classic Win32 about what the background process is for so it can best manage it. The support for background processes continues to improve. Windows 10, for instance, now supports a "single instance" background processing model where background processes can be seen as an invocation of the UI app (if already running) and vice versa (the UI app is presented as an invocation to the background process if that is already running) with hand-offs from one to the other, simplifying the programming of some of the interactions between background and UI for some apps.