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.)

That's the very reason I didn't use any Metro apps on my work computer. They would get swapped out of memory and killed whenever I ALT+TABbed from them. Not joking. Every time I wanted to switch to a normal app for a second and then back to the Metro one, the latter would have to "restore" itself (and guess what, it never restored to the point I last left it).

Of course I know the reason - that's because my machine is memory constrained, I routinely run on ~90% RAM usage. But hey, that 8GB of RAM isn't here for vacation, it's to be used.

Personally, I find the mobile app lifecycle - which is where they took the idea from - to be incredibly annoying. I like to have control both when applications die and when they start up (which, on Android, is utterly unpredictable).

Oh, but it's great! I can't browse most sites on my android because the LMK for some reason starts with the damn browser. I love it! /s

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.

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.

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

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).

> 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)

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.

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.

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.

They say that using Linux is constantly solving some problems, only for the solutions to produce more problems for you to tackle. You stop when the next problem you face is not annoying enough to care.

There was a point, somewhere between 2009ish and 2011ish, when that was really no longer true, except for the distributions that hopped on the PulseAudio boat really early and had audio broken for a few releases.

I have no idea what happened after that but it's really screwed up.

What happened in 2011ish that made everything go to hell again?

I wish I knew.

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.

> 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.

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.)

On Windows, once in a while there is a Patch Tuesday when the only update is Internet Explorer, a program that I neither wanted, nor installed, nor opened since I got tired of it years ago. Clearly, I need to reboot my computer for this.

On Ubuntu, certain packages are labeled as needing a reboot, and when you update them the control menu thing with a gear in the upper-right corner turns red, and the Update utility says you should reboot. Then you know you should, but it doesn’t force you to.

EDIT: There’s also Ksplice, which was going be a standard until Oracle bought it, and Red Hat kpatch. Those allow you to update a kernel without rebooting. Most other programs still require restarting, but Linux benefits from a saner architecture, where the web browser isn’t an “integral part of the operating system,” and the font renderer for the GUI and for printing is not part of the kernel. You need to reboot less.

Your answer doesn't really address the question.

Jameskegel said that in any "mainstream distributions", after you run an update but before you reboot, the OS is running the updated libraries. I honestly don't understand how that is possible.

It's really quite simple: http://unix.stackexchange.com/a/74172/28974

Right but that very answer says:

> Newly created processes will use the updated contents, running applications will access the old version.

In other words, currently running code is still running the known-buggy version, exactly what I said originally that kicked-off this whole discussion.

No, what you said was: "until you reboot, your Linux box is still running the known-buggy code"

And then later in the same post (just so we're clear about what you said): "But unless you reboot after installing your Linux updates, your computer still has the bugs."

Linux does not require a reboot to update.

>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?

I don't understand this answer, and I don't recall "suggesting" anything.

Settle down. You seem to be taking some heat in the comments, so I'll recuse myself from this discussion, as I feel we are no longer making progress in an intellectual context.

It would help to "make progress in an intellectual context" if you'd deign to back-up the claim you made, which I now strongly suspect was simply incorrect from the start.

But hey, suit yourself.

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.

No, you're wrong. Ubuntu will not ever force you to reboot your machine. The most it will do is recommend a restart.