> For years I've had it drummed into my head that you always have to keep your systems patched, if you aren't running the latest security fixes, the script kiddies will eat you alive, running a six month old OS is like leaving your front door wide open, blah blah blah. Well you know what? Fuck that noise. I'm done upgrading anything ever. The next time I get this shit into a state that seems even remotely stable, I'm never touching it again. If we get hacked, oh well. I have backups. It has got to be less work to recover from than constantly dealing with this kind of nonsense.
Or possibly this CodingHorror blog entry that summarizes a few other instances of jwz saying this:
I try to instill in people the idea that their judgement is compromised at the end of the day and especially the end of the week. If you don't fight the urge to 'finish' something before going home, then what you're doing is dropping code that isn't up to your normal standards on your coworkers and then leaving the building. If you are the sort who comes in late and leaves late, you're painting a giant target on your head doing this, because everyone has had time to stew about anything you broke (possibly before their morning coffee has kicked in).
I mention this because the alternative is to have a cutoff of 90 minutes before you leave, and then have a lot of days where you end up with 45+ minutes to kill before it's acceptable to go home. What can you do in this time that makes sense? Basic maintenance is one thing. Rebooting your machine, restarting that IDE, clearing up disk space, upgrading things. Documentation is another. Cleaning up the Wiki is a good thing, especially on that odd day when you finish a project 1pm on Friday and starting something new makes no sense.
But for upgrading software? I think the best option is to look at your team and think, "who would I go to if my code/machine is behaving like the magic smoke got out?" Those people should be doing all of the upgrades, and then reporting their success/failures to everyone else.
I think what Jamie is seeing here though is the downside of open source. Nobody is getting paid to care as much about your use case as you care about it. Sometimes that's empowering, but it's also a huge responsibility. People who pay a lot for software are trying to delegate that responsibility. Win, lose, or draw, that's why they do it.
And what Jamie is missing here is hackers with a vendetta. "If we get hacked, oh well. I have backups." They know you have backups. If they just want to count coup, then your backups will be fine. But I've known of two different services where a slighted user hacked them and made it hurt.
In the first case it was something I hadn't used for a year or two, but I knew a guy who knew a guy who got banned. Found out through my friend that this guy put a time bomb in the backups, and managed to kill their server and all of the backups on the same day. That site was down for months, and almost didn't come back at all.
In the second case, the hackers didn't even take down the site. They exploited a kernel bug and logged all of the private conversations of the administrators, then cherry picked all of the worst bits and some spoilers and posted them online. That site was supposed to be down for a month+, and I think was down for almost 3.
https://www.dnalounge.com/backstage/log/2006/04/
> For years I've had it drummed into my head that you always have to keep your systems patched, if you aren't running the latest security fixes, the script kiddies will eat you alive, running a six month old OS is like leaving your front door wide open, blah blah blah. Well you know what? Fuck that noise. I'm done upgrading anything ever. The next time I get this shit into a state that seems even remotely stable, I'm never touching it again. If we get hacked, oh well. I have backups. It has got to be less work to recover from than constantly dealing with this kind of nonsense.
Or possibly this CodingHorror blog entry that summarizes a few other instances of jwz saying this:
https://blog.codinghorror.com/let-that-be-a-lesson-to-you-so...