8 ms·

Kernel updates probably need a restart (or use kexec), but most other updates only require a service to be restarted, right?

• sagischwarz 11y ago
  That's right. But updating everything except the kernel also seems strange.
  • krylon 11y ago
    Well, on Linux distros it is not uncommon for individual packages to be updates as updates become available. So if there is an update to, say, the web server, it is sufficient to restart the web server. On BSD systems, kernel and userland are developed in lock step, so it's usually a good idea to reboot to be sure they are in sync.
    • laumars 11y ago
      Usually you'd be running the same userland daemons on FreeBSD that you might on Linux. Web servers, databases, OpenSSHd, file networking protocols (FTP, SMB, NFS, etc), and so on aren't generally tied to a particular kernel version since ABIs are not subject to frequent changes (it would be very bad if they were). So with that in mind, you can update your userland on FreeBSD without updating your kernel in much the same way as you can do with Linux. Though it is recommended that you update the entire stack on either platform.
      • floatboth 11y ago
        Updating the FreeBSD base (to the next major release) without updating the kernel is Not a Good Idea. Backward compatibility is there, down to version 4.x, but no one guarantees forward compatibility! Applications will usually work, but the base system will likely break in some places.
        • laumars 11y ago
          Yes, but 'freebsd-update' is akin to an 'apt-get dist-upgrade'. Regular updates from 'pkg' or ports should be fine.
  • drummer32 11y ago
    It's not at all strange. Security updates to publicly-facing services should be applied as fast as possible. Kernel vulnerabilities are a whole different attack surface
    • laumars 11y ago
      Kernel vulnerabilities can be combined with user space vulnerabilities. eg a buggy web script might allow an attacker shell access under a restricted UID. The attacker could then use a kernel vulnerability to elevate their permissions to root.
• krylon 11y ago
  Generally speaking, yes. Although, if there is an update to glibc, which tends to affect most processes, I tend to reboot the system, anyway. (On Windows, a lot more updates require a reboot, though, because one cannot replace/delete a file that is opened.)
  • pjmlp 11y ago
    > because one cannot replace/delete a file that is opened. Which is a good thing and I bet a model in all other OSes, besides UNIX. UNIX flock model is just flawed. How many times I crashed something just because I rmed a file that was being used.
    • joosters 11y ago
      If you rm a file that someone else is reading, they can happily keep reading it for as long as they like. It's only when they close the file that the data becomes unavailable.
      • pjmlp 11y ago
        I know how inodes work, thank you. My first UNIX was Xenix. Applications do crash when they make assumptions about those files. For example, when they are composed by multiple parts and give the filename for further processing via IPC, or have another instance generating a new file with the same name, instead of appending, because the old one is now gone. Another easy way to corrupt files is just to access them, without making use of flock, given its cooperative nature. I surely prefer the OSes that lock files properly, even if it means more work.
        • zeveb 11y ago
          > For example, when they are composed by multiple parts and give the filename for further processing via IPC Of course, the proper way to do this in POSIX is to pass the filehandle. POSIX is actually a pretty cool standard; the sad thing is that one doesn't often see good examples of its capabilities being used to their full extent. For this, I primarily blame C: it's so verbose and has such limited facilities for abstraction that it's often difficult to see the forest for the trees. Combine that with a generation of folks whose knowledge of C dates back to a college course or four, in which efficient POSIX usage may not have been a concern, and one finds good, easy-to-read examples of POSIX harder to find than they really should be.