3 ms·

A server whose uptime goes to X years is a server that wasn't updated in X years. I'm proud of my old XigmaNAS (FreeBSD) ~15 months uptime years ago that only a

A server whose uptime goes to X years is a server that wasn't updated in X years. I'm proud of my old XigmaNAS (FreeBSD) ~15 months uptime years ago that only a blackout did interrupt (yep, I had no UPS), and I write this as a mostly Linux user, but I'm not sure it's a good thing to aim for in production or in anything connected to the Internet.

HL33tibCe7 2y ago
Yeah, the article links another post which talks about a machine with a 9 year uptime as if it's a good thing. 9 years without a NetBSD release update (or kernel upgrade) is not something to be proud of.
- BSDobelix 2y ago
  >9 years without a NetBSD release update (or kernel upgrade) is not something to be proud of. Not every system has to be connected to the internet....imagine that ;)
  - nonrandomstring 2y ago
    Whether something is connected to the internet or not wouldn't be my objection to the parents personal notion of "pride". I believe they're saying it would be irresponsible - in the current climate - to leave a system without upgrades and attention for so long. We can agree on that. That really only reflects the "current climate"; which is one of colossal dereliction and reckless engineering amounting to a total abandonment of cybersecurity. Cybersecurity is presently such a circus because of endemic poor software engineering, a worship of expedience, convenience, efficiency and plain old greed. These are all the reasons that good engineering and big business do not intersect in modern times. A couple of weeks ago Jen Easterly called out current industry practices as enabling cybercrime and harming society [0]. So not all unattended code is equal. I think there is a great deal of pride to be taken in building and using stable and reliable systems. That shows up in smaller groups, non-profits, and volunteer networks that are strongly focused on a smaller set of goals and who eschew giddy neophyte values in favour of a more sedate and responsible stance. But those are rather different flavours of "pride". I would characterise what the parent said as more an "absence of shame" for leaving what are evidently cheap-ass vulnerable systems that are "pwned out of the box" in a hostile environment. [0] https://www.cisa.gov/about/leadership/jen-easterly https://www.cisa.gov/about/leadership/jen-easterly
  - viraptor 2y ago
    In the post describing that server: > They required a dhcp, an internal DNS, an Apache + PHP server for some internal (and a couple of external) websites, a file server accessible via both NFS and Samba (as Windows PCs needed access), an internal SMTP connecting to an external relay to ensure faster email dispatches for employees given their unstable connectivity, and a few other nuances. It's running basically everything. But even if it was exposed only internally, that's usually only one other issue or misconfiguration away from being fully exposed again.
    - BSDobelix 2y ago
      I don't talk about this case, but the automatic assumption that every system is connected to a common network.
      - deleted 2y ago
        [deleted]
- mst 2y ago
  The fact that the system accidentally got neglected isn't, no. The fact having having been neglected nobody realised because it Just Kept Working for close to a decade is still a testament to the software running on it.
kleiba 2y ago
Why do updates necessarily require reboots though?
- jiggunjer 2y ago
  I suppose it's about kernel and driver packages mostly.
  - viraptor 2y ago
    If you pay enough, you can also get live patches which don't require a restart. This some to other software too - I've done some upstart live-patching in the past to save a cluster. But yeah, if you can afford to just restart part of your service like a normal person, your restarts will come from the kernel update.
eru 2y ago
There's another reason to restart all your stuff (computers, server processes, etc) every so often: In case something goes wrong, you might have to restart anyway. So you better exercise that process to know it works. Also, I'd rather get really good at dealing with the first day of uptime of a system, then discover what the n-th day brings for ever larger values of n for the first time ever.

HL33tibCe7 2y ago

Yeah, the article links another post which talks about a machine with a 9 year uptime as if it's a good thing. 9 years without a NetBSD release update (or kernel upgrade) is not something to be proud of.

BSDobelix 2y ago
>9 years without a NetBSD release update (or kernel upgrade) is not something to be proud of. Not every system has to be connected to the internet....imagine that ;)
- nonrandomstring 2y ago
  Whether something is connected to the internet or not wouldn't be my objection to the parents personal notion of "pride". I believe they're saying it would be irresponsible - in the current climate - to leave a system without upgrades and attention for so long. We can agree on that. That really only reflects the "current climate"; which is one of colossal dereliction and reckless engineering amounting to a total abandonment of cybersecurity. Cybersecurity is presently such a circus because of endemic poor software engineering, a worship of expedience, convenience, efficiency and plain old greed. These are all the reasons that good engineering and big business do not intersect in modern times. A couple of weeks ago Jen Easterly called out current industry practices as enabling cybercrime and harming society [0]. So not all unattended code is equal. I think there is a great deal of pride to be taken in building and using stable and reliable systems. That shows up in smaller groups, non-profits, and volunteer networks that are strongly focused on a smaller set of goals and who eschew giddy neophyte values in favour of a more sedate and responsible stance. But those are rather different flavours of "pride". I would characterise what the parent said as more an "absence of shame" for leaving what are evidently cheap-ass vulnerable systems that are "pwned out of the box" in a hostile environment. [0] https://www.cisa.gov/about/leadership/jen-easterly https://www.cisa.gov/about/leadership/jen-easterly
- viraptor 2y ago
  In the post describing that server: > They required a dhcp, an internal DNS, an Apache + PHP server for some internal (and a couple of external) websites, a file server accessible via both NFS and Samba (as Windows PCs needed access), an internal SMTP connecting to an external relay to ensure faster email dispatches for employees given their unstable connectivity, and a few other nuances. It's running basically everything. But even if it was exposed only internally, that's usually only one other issue or misconfiguration away from being fully exposed again.
  - BSDobelix 2y ago
    I don't talk about this case, but the automatic assumption that every system is connected to a common network.
    - deleted 2y ago
      [deleted]
mst 2y ago
The fact that the system accidentally got neglected isn't, no. The fact having having been neglected nobody realised because it Just Kept Working for close to a decade is still a testament to the software running on it.

kleiba 2y ago

Why do updates necessarily require reboots though?

jiggunjer 2y ago
I suppose it's about kernel and driver packages mostly.
- viraptor 2y ago
  If you pay enough, you can also get live patches which don't require a restart. This some to other software too - I've done some upstart live-patching in the past to save a cluster. But yeah, if you can afford to just restart part of your service like a normal person, your restarts will come from the kernel update.

eru 2y ago

There's another reason to restart all your stuff (computers, server processes, etc) every so often: In case something goes wrong, you might have to restart anyway. So you better exercise that process to know it works. Also, I'd rather get really good at dealing with the first day of uptime of a system, then discover what the n-th day brings for ever larger values of n for the first time ever.