22

Like many people, I run dual systems on my computer. Important updates require constant reboots on Windows, while I don't think this ever happened to me on Linux. What properties of each OS decides whether or not this is possible?

Benjamin Lindqvist
  • 371
  • 1
  • 4
  • 5
    I still have to reboot my Linux systems to install a kernel update. I know there are ways around even that, but I don't require such extreme uptime. While there's rarely a kernel update for my servers or long-term-support installations, I do get occasional kernel updates on my more bleeding edge systems – I don't see much of a difference between Linux and Windows here. However, Linux updates are way less obstructive than Windows updates, since they don't turn rebooting into a waiting game. – amon Oct 14 '15 at 18:40
  • 1
    [Well, actually](http://well.actually.cat/images/well_actually_trollcat.jpg)... 1. This is less of a problem with Windows today than it used to be. When it does happen, it's usually because someone forgot to close an application that's locking some files that Windows needs to update, and rather than failing the install, Windows simply registers those file changes for the next boot. 2. A cold restart on my current machine running Windows 10 takes about 15 seconds, half of which is POST time. – Robert Harvey Oct 14 '15 at 20:09
  • @Robert-What is your definition of finishing startup? Getting to the login/desktop screen isn't so bad, it's waiting for all those services to get started so you can actually use the computer that is a pain. If your time includes starting the services then what is your setup? Granted I don't have the latest and greatest but I do have decent enough computers and my work computer takes about 3 minutes and my home about 2 1/2 before I can start working on them. – Dunk Oct 14 '15 at 20:15
  • @Dunk: Buy an SSD. – Ben Voigt Oct 14 '15 at 20:58
  • @Ben-I am not next in line at my house for a new computer but my son is. So I'll be building him one for Christmas and will check it out first hand. However, benchmark test reports that I've read show about 50% speed improvements, not 1000% like Robert sees over my systems. 1000% is definitately worth the hassle of an upgrade. 50% not so much. – Dunk Oct 14 '15 at 21:05

2 Answers2

51

It's a consequence of engineering decisions.

On a Linux system, it's possible to delete a file that's still in use; the file system uses what's essentially a form of reference counting, and having the file open is simply another reference to it. When you close it, the file will be cleaned up. As a consequence of this, it's possible to replace core OS code and data files without needing to shut them down and restart them (aka reboot).

On Windows, opening a file locks it in the file system, and it can't be deleted. This means that currently-running code can't be updated without a reboot. But this also means that you can always know exactly what version is running on your system; under the Linux model, it's possible to receive an important system software update, successfully apply it, and still not have it operational on your system, because the old, un-updated version is still running.

It's an engineering tradeoff, like most things in computing.

Mason Wheeler
  • 962
  • 2
  • 14
  • 22
  • " Linux model, it's possible to receive an important system software update, successfully apply it, and still not have it operational on your system" So a reboot is still needed to be safe..... – Ian Ringrose Oct 14 '15 at 19:07
  • @Ian: yup, pretty much... – Mason Wheeler Oct 14 '15 at 19:10
  • 6
    @Ian No, you can restart your services to apply the updates. Or, in the case of the kernel, you can use ksplice, kpatch, etc., or the new features in Linux 4.0. – nanny Oct 14 '15 at 19:13
  • It is perfectly possibly to deploy executables when they are in use without a reboot. In fact for deployment of web applications it is commonplace. – Robbie Dee Oct 14 '15 at 19:29
  • I think this is slightly oversimplified. On Windows, there's FILE_SHARE_DELETE which "[Enables subsequent open operations on a file or device to request delete access.](https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx)", essentially allowing to remove or rename files that are opened. I'm sure it's possible to forbid the deletion or renaming of an opened file in Linux. **It's just not the default in both cases.** – krlmlr Oct 14 '15 at 19:36
  • @Ian, ...it's easy to look at which processes have handles on unlinked files, so it's trivial to detect which services need to be restarted in this case. A reboot is overkill. Also, there's support for passing open FDs between processes, so for well-written daemons, a restart doesn't even need to require dropping open connections. (Off the top of my head, this is supported by nginx, haproxy, uWSGI, and I'm sure many others). – Charles Duffy Oct 14 '15 at 19:48
  • @CharlesDuffy: systemd probably makes it even more widespread... – Deduplicator Oct 14 '15 at 20:17
  • @Deduplicator, ...eh. Just being supervised by systemd doesn't mean one magically gets all the features it can potentially support, and this is one of the ones that takes development effort to take advantage of. – Charles Duffy Oct 14 '15 at 20:48
  • @CharlesDuffy: Sure, I just meant that existence and wide-spread use of systemd means that ability gets more widely implemented *as a side-effect* of optimizing use with it. – Deduplicator Oct 14 '15 at 20:51
  • 2
    @Deduplicator, sure; I'm just pessimistic about adoption rate. One development team I work with has announced that they're no longer going to accept any patches adding support for optional systemd features after a bug in sufficiently ancient systemd releases' notify-socket-based-watchdog support resulted in a new copy of their daemon being spun up (in addition to the old ones!) once a second. – Charles Duffy Oct 14 '15 at 20:53
  • 1
    @krlmlr: That doesn't allow you to delete a file that's open. From [the documentation](https://msdn.microsoft.com/en-us/library/windows/desktop/aa363915(v=vs.85).aspx): "The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed" You can still replace it, using `MoveFile` to get the old one out of the way. – Ben Voigt Oct 14 '15 at 21:02
  • @CharlesDuffy, by "trivial" do you mean that my mother can do it with no more then 5 minutes training? If not then it can be considered a safe way to update a PC! – Ian Ringrose Oct 14 '15 at 21:52
  • @krlmlr: Furthermore when opening files to run programs, the OS doesn't open them with FILE_SHARE_DELETE set. – Joshua Oct 14 '15 at 21:53
  • 1
    @Ian, by "trivial" I mean anyone responsible for building a Linux distribution's update system will know how to make it happen off the top of their head, so the question becomes whether it's a good idea to run automatically (or how to expose it to the user), not whether it's possible. – Charles Duffy Oct 14 '15 at 21:55
  • 1
    @Ian, ...that said, I could certainly put the logic into a script your mother could run, yes. – Charles Duffy Oct 14 '15 at 21:56
  • @CharlesDuffy, not good enough, in the real world outside of a datacenter updates must work without needing skilled person to write a script. – Ian Ringrose Oct 14 '15 at 21:58
  • @Ian, I said well above that it's trivial *for someone maintaining a Linux distribution*, and by that, I meant -- and thought I was communicating clearly -- that this should be the distribution's job, if it's a thing that customers really want (I actually doubt that it is, by default; I'd expect customers to be damned angry about having momentary downtime while their services restart without explicit configuration to that effect). Thus: if it's really a good idea (TBD), having a skilled person write a script to restart daemons as needed on update is your distribution's job, not yours. – Charles Duffy Oct 14 '15 at 22:41
  • @Ian, ...so: If you want to complain about some specific Linux distribution not providing features you need, complain to them, not me. (I maintain a distribution [for an embedded appliance, *including* its update mechanism], and we don't have that feature... but that's because we require reboots on updates; no customers have complained yet -- when they do complain loudly enough, I'll write that script). – Charles Duffy Oct 14 '15 at 22:41
  • (Basically: Filter lsof for unlinked files; when any open, unlinked file has a name that still exists on the filesystem with a different inode, and the process holding that file open is in a cgroup that indicates that it's part of a systemd service, tell systemd to restart that service. Might filter for packaged files, just to be safe. Easy peasy, in any event). – Charles Duffy Oct 14 '15 at 22:46
  • 2
    @CharlesDuffy I don't know how it works under the hood, but the Debian [needrestart](https://packages.debian.org/sid/needrestart) package does the job you are describing, i.e. automatically restart services whose executables/libraries have just been updated. – zwol Oct 14 '15 at 23:38
  • 1
    Have in mind that, even when updates *should* be followed by a reboot on Linux even uf just in case, you probably can reboot a Linux system a few times *in the time it takes Windows to shutdown after updates are installed*. More so if you run them on SSDs. – Darkhogg Oct 14 '15 at 23:47
  • Note that Windows does support (and use!) [hot patching](http://blogs.msdn.com/b/oldnewthing/archive/2013/01/02/10381672.aspx). It is not possible to use it always, but it is certainly used. – Sebazzz Oct 15 '15 at 06:10
4

It's a consequence of view of predicted user expectations.

Linux systems are modeled after unix run on servers. Uptime was a bragging point in these communities. Anything that reduced up time was bad. And this is a side effect of the expectation that the computer had multiple users and that scheduling downtime had to be coordinated with multiple users.

Windows was designed for the pc market. At the time that it was introduced the knowing that you could quit one program and start another without rebooting was the sign of an experienced computer user. Because of this there was no reason to not use filenames as the primary identifier when designing ntfs.

hildred
  • 526
  • 4
  • 12