3 ms·

Unless you get up for work on Wednesday (Tuesday?) night at 3am you're fine. >now system startup is delayed half an hour or more to configure a new batch of pa

by Nadya 11y ago

Unless you get up for work on Wednesday (Tuesday?) night at 3am you're fine. >now system startup is delayed half an hour or more to configure a new batch of patches. The default is that there is no configuration. The OS downloads the patches by default, installs them, then waits for the user to restart the computer to finalize things. The user can simply not restart the computer if they are in a hurry.

mintplant 11y ago
I'm talking about a cold boot here. As in: (1) the OS downloads and installs patches (2) at some point I turn off my computer for the night (3) I turn it on again in the morning and have to wait for this finalization before I can use my system.
- Nadya 11y ago
  This can occasionally be an issue for people unaware of the update schedule - I agree. A small learning curve of "reset before turning off for the night on Tuesdays" alleviates that problem and I feel Microsoft made that trade off for user security with their general user (read: non-tech savvy people) as the primary users. Personally I have automatic updates turned off and vet which patches get installed. But I'm more involved than the typical Windows users. I'd use a Linux distro if I could find suitable replacements for certain programs I rely on for my workflow.
  - simoncion 11y ago
    > This can occasionally be an issue for people unaware of the update schedule - I agree. > A small learning curve of "reset before turning off for the night on Tuesdays" alleviates that problem... No. The problem remains. This just time-shifts the problem. In recent memory, I've had two Patch Tuesdays that sent Windows into a 5+ deep post-boot-but-pre-login reboot loop while Windows tried to figure out how to apply several patches that would just not apply. (Spoiler alert: It never figured out how, but just -eventually- gave up.) It doesn't matter what technical decisions and constraints lead to this post-boot-but-pre-login configuration process being the way things work, it's still awful. Every Linux distro I use seems to have figured out how to apply and configure updates before you reboot a system, rather than during the next boot cycle.
    - Nadya 11y ago
      >No. The problem remains. This just time-shifts the problem. The time was the problem in the example, so time-shifting is a legitimate fix to the problem here. "In a rush for work, turn on computer, 30 minutes of updates." was the problem. >Every Linux distro I use seems to have figured out how to apply and configure updates before you reboot a system, rather than during the next boot cycle. There are tradeoffs for doing things that way. Such as when everything eats shit and you regret updating. For example: pacman -Syu Can be a complete nightmare.
      - tdkl 11y ago
        > There are tradeoffs for doing things that way. Such as when everything eats shit and you regret updating. For example: pacman -Syu Knowing that you're on a rolling release distro is one thing, but being used to a "LTS" system (Windows 7,8x) then "upgrading" to a rolling release (Windows 10) is something else. The trust in MS for being capable and responsible for handling the updates is broken.
      - simoncion 11y ago
        > There are tradeoffs for doing things that way. Such as when everything eats shit and you regret updating. Bad updates are bad updates, regardless of whether you do the configuration after a reboot (rendering the computer useless while you configure), or while the system is still running. Not that it matters, but I've had far more bad updates on my Windows systems than I have on any of my Linux systems. :) > ...time-shifting is a legitimate fix to the problem here. It's not a fix. It's a band-aid that fails to address the root of the problem.
      - yo-code-sucks 11y ago
        Yeah it can! Try pacman -Syyu instead. Oh yeah be sure to read what's changing. Arch user since the early days, never had an issue I couldn't fix in minutes. Rule #1 read.

by Nadya 11y ago

mintplant 11y ago

I'm talking about a cold boot here. As in: (1) the OS downloads and installs patches (2) at some point I turn off my computer for the night (3) I turn it on again in the morning and have to wait for this finalization before I can use my system.

Nadya 11y ago
This can occasionally be an issue for people unaware of the update schedule - I agree. A small learning curve of "reset before turning off for the night on Tuesdays" alleviates that problem and I feel Microsoft made that trade off for user security with their general user (read: non-tech savvy people) as the primary users. Personally I have automatic updates turned off and vet which patches get installed. But I'm more involved than the typical Windows users. I'd use a Linux distro if I could find suitable replacements for certain programs I rely on for my workflow.
- simoncion 11y ago
  > This can occasionally be an issue for people unaware of the update schedule - I agree. > A small learning curve of "reset before turning off for the night on Tuesdays" alleviates that problem... No. The problem remains. This just time-shifts the problem. In recent memory, I've had two Patch Tuesdays that sent Windows into a 5+ deep post-boot-but-pre-login reboot loop while Windows tried to figure out how to apply several patches that would just not apply. (Spoiler alert: It never figured out how, but just -eventually- gave up.) It doesn't matter what technical decisions and constraints lead to this post-boot-but-pre-login configuration process being the way things work, it's still awful. Every Linux distro I use seems to have figured out how to apply and configure updates before you reboot a system, rather than during the next boot cycle.
  - Nadya 11y ago
    >No. The problem remains. This just time-shifts the problem. The time was the problem in the example, so time-shifting is a legitimate fix to the problem here. "In a rush for work, turn on computer, 30 minutes of updates." was the problem. >Every Linux distro I use seems to have figured out how to apply and configure updates before you reboot a system, rather than during the next boot cycle. There are tradeoffs for doing things that way. Such as when everything eats shit and you regret updating. For example: pacman -Syu Can be a complete nightmare.
    - tdkl 11y ago
      > There are tradeoffs for doing things that way. Such as when everything eats shit and you regret updating. For example: pacman -Syu Knowing that you're on a rolling release distro is one thing, but being used to a "LTS" system (Windows 7,8x) then "upgrading" to a rolling release (Windows 10) is something else. The trust in MS for being capable and responsible for handling the updates is broken.
    - simoncion 11y ago
      > There are tradeoffs for doing things that way. Such as when everything eats shit and you regret updating. Bad updates are bad updates, regardless of whether you do the configuration after a reboot (rendering the computer useless while you configure), or while the system is still running. Not that it matters, but I've had far more bad updates on my Windows systems than I have on any of my Linux systems. :) > ...time-shifting is a legitimate fix to the problem here. It's not a fix. It's a band-aid that fails to address the root of the problem.
    - yo-code-sucks 11y ago
      Yeah it can! Try pacman -Syyu instead. Oh yeah be sure to read what's changing. Arch user since the early days, never had an issue I couldn't fix in minutes. Rule #1 read.