# To upgrade or not to upgrade...



## decuser (Dec 18, 2022)

Today, I'm feeling a little curmudgeonly. Should I bother upgrading or not?

Bare with me as I set up the background - this really is about FreeBSD... in the end . If it's too long for you - run away, or skip to the end and make your way backwards...

I have a Lenovo Thinkpad T430, a Dell Optiplex 755, a Mac Pro, and MacBook Pro that are getting older by the day. One's 12 years old, one's 14 years old, another one's12 years old, and the other is coming up on 10. They have served me quite well and seem satisfactorily endowed for daily use. At work, I have a cutting edge laptop with the absolute latest hardware running the latest software and honestly, I can't tell much difference... other than the modern system completely lacking in useful ports . 

I don't do much that's computationally expensive outside of data analytics and video editing. Mind you, that's more than 90% of the folks I know, but it's not massively parallel computing or visual gaming or anything that intense. It's just more than browsing, editing files, and such. I also do a lot of virtual machines doing the same analytics and such, so I guess I'd say, I tax the machine about like a programmer, video editor, and data geek would and not like a dedicated gamer or full time professional video editor would.

Lately, the Macs have been challenging on the upgrade front, softwarewise - Apple decided, in their infinite wisdom, that they should no longer receive updates. The Mac Pro is upgradable to Mojave and the MacBook Pro, to Catalina. Over the last several years, I've gone back and forth between Mojave and Catalina on the MacPro and the decision lies with Mojave as being the better choice - faster, less invasive privacy-wise, and supportive of 32 bit programs. I really like Mojave - it appears to be the last version of MacOS that holds on to any semblance of human factor engineering consideration and it's stable and fast.

But... Up to this point, I have enjoyed living near the edge, if not on it, with my choice of software, and not updating continuously has been irksome to say the least. I have felt exposed and potentially vulnerable. I have been socially engineered to fear the idea of not having the latest, up to the minute, patch, and it's made me uncomfortable. So, like any good techie, I looked around the internet for a way to run the latest on my old hardware and was not disappointed to
find OCLP, dortania's open core legacy patcher. A day researching the approach and notes later, and lo and behold, both my Mac Pro and MacBook Pro were running MacOS Monterey (at the time Ventura support was beta with OCLP and while I might be willing to run a beta Ventura, I wasn't willing to run a beta OCLP on a nascent Ventura). Everything pretty much just worked... Apparently, Apple's forced inability to upgrade was not related to reality. Similarly, I read about how to modify the installation process on Windows 11 and installed it on the T430 and Dell - no issues really. However, neither MacOS Monterey, nor Windows 11 were pleasant experiences. Both suffered from similar human computer interface issues and neither was quick or responsive as I'd grown used to with Mojave and Windows 10. So I reverted these to the older OSes and live happily with my aging OSes...

It's interesting to note that both Mojave and Windows 10 are well supported in the applications area, though I expect that to slowly drop off over the coming years as folks get too lazy to build for those targets. I have found that this is not a huge issue as truly new (innovative) apps are few and far between. XP still runs the a large majority of software capability (not latest apps, but apps that perform the function) and much more quickly than it's more modern descendants, even in a virtual environment.

Sure, these systems are "vulnerable" and "exposed" as they aren't patched anymore. But, they sit behind a firewall router that's done its job for ages and don't appear to get infections, viruses, malware or anything else. I do run zonealarm/wfc and little snitch in alert mode, so I know what's connecting when, to and from what, and adblocking in the browsers, but otherwise, not much special.

What's this got to do with FreeBSD you say? Just this, I have been running FreeBSD for ever and I've dutifully upgrade to latest whenever it's been released and folks opined that it's not bug ridden... or, when I've needed some hardware related capability that it provided. I've been running 13 since it was first released, and before that I went to 12, as soon as. If I remember correctly, 12 had some radeon support drm-kmod or some such that was part of the install rather than needing to be built from ports. I've never been burned with a FreeBSD upgrade that I know of.  I generally just freebsd upgrade, run it a while, then wipe and clean install after I'm convince things are working.

With ZFS and boot environments, things have gotten ridiculously simple (relative term, ymmv). I run the main os on it's own drive and my important files on a mirrored set. Upgrading the OS just requires changes to the main drive and exporting the mirror and importing it after the upgrade is painless and seemingly without much risk.

A week or so ago, FreeBSD 12.4 was released and it appealed to me to think about going the other direction. I remember fondly running 12. 13 is an ugly number and lately, my fossil commits have seemed slower than I'd like them to be, so I thought I'd see about downgrading - I'm running on ZFS and I've never lost a bit doing this, so why not. I did a bit of prep work to be sure I wouldn't blow things up (backed up remotely, just to be certain) and proceeded.

I immediately ran into a problem - the zfs version on the pool was ahead of the installed version (of course, duh). I asked on the forum and the advice was helpful in reminding me that I'd run into a similar problem going from FreeBSD to Linux and back again with a pool. I resurrected the notes and was able to reconstruct the pool in 12.4. 

After running 12.4 for a bit, I like it. My fossil commits are snappy, as I would hope, and things are as stable as I remember 12 being from when I ran it. 13 is plenty stable too, don't flame me . So, I'm sticking with it for the time being.

But, as I do, I feel guilty... I don't feel "vulnerable" or "exposed" yet, since it's still supported, but as a good product the the socially engineered gotta run the latest security patched os person should, I wonder if I'm being naughty.

I have to admit that I'm tired of being on the hamster wheel of upgrades. Do we really have to live like this - upgrade or die? My experience and gut tell me that my un-upgradable and therefore unpatched systems seem to work ok and that they seem safe, but this is not consistent with what authority has to say on the subject.

So, what do y'all think? 12.4 is currently supported, but it won't be in due time. Will I be taking my technical life into my own hands and risking life, limb and liberty if I persist in running the old stuff or will I just step off of the hamster wheel and kick it back in a hammock watching the sunset swinging left to right, right to left. All the while happily serving my fossil repo and bc, and whatnot with little concern for the outrage of sysops and security folks everywhere?

I know what my choice is with the Macs - Mojave until it croaks, with an occasional test run of whatever I can coax onto it having the sneaking suspicion that Mojave is as far as they go. But with FreeBSD, I can probably upgrade to latest until the cows come home. I think we dropped 386 support in 13? Sheesh . It's a matter of should I, or why bother, rather than can I.


----------



## chrbr (Dec 18, 2022)

I will keep my computers on the FreeBSD-12.* as long as supported.


----------



## smithi (Dec 19, 2022)

chrbr said:


> I will keep my computers on the FreeBSD-12.* as long as supported.



That's been my intention too.

Note however that on November 2nd, the published Stable-12 EoL was reduced by 6 months from 30th June 2024 to 31st December 2023.

Still a year away, fine by me, but noticing that change made me wonder enough to chase it down:






						doc - FreeBSD documentation tree
					






					cgit.freebsd.org


----------



## CuatroTorres (Dec 19, 2022)

Focusing on the value of the data you're handling and how the box subdues the rest of the network devices, even smartphones. Breaches happen in the cloud most of the time. There are still other i386 open systems supported.


----------



## mer (Dec 19, 2022)

Interesting, thoughtful, thanks decuser 
For me it has always been about the applications and failing hardware driving most of my upgrades.  Security  upgrades take precedence, failing hardware pretty much demands replacement.
Staying on 12.x because it works and has the versions of applications you need is reasonable.


----------



## zirias@ (Dec 19, 2022)

Why not reduce it to the hard and simple facts? Upgrading makes sense for mainly two reasons (unless you're either developer or tester):

End of support for the version you're currently running
A real need for features the new version offers
(1) is a must, but doesn't apply for FreeBSD 12 as of now, it is still supported, receiving security updates etc.
(2) is a very personal decision that should be based on _your_ needs.

Having said that, I'm using FreeBSD for a while now, and personally started with `11-CURRENT`, because back then, `10.x-RELEASE` had no support for my GPU, and having that was a must for me, I wanted to use it on both server and desktop from the beginning. Since `11.0-RELEASE`, there was always a reason for me to quickly move to the latest major. For 13, there were e.g. the performance improvements with virtual networking (using epair(4) and if_bridge(4) for VNET jails) I really wanted to have.

If you don't find anything you really want to have, sticking with an older (still supported!) major makes sense for sure. There's a reason it's still supported. FreeBSD gives you nice flexibility about when exactly you're doing a major upgrade.

Just one thing to also consider: You're potentially helping the project if you test new majors early (preferably even `BETA` and `RC` builds, but be aware they're definitely not production ready). Some issues can only be found through "field testing", and the more people test early on, the better the chances for high-quality `*.0` releases


----------



## cracauer@ (Dec 19, 2022)

I am very aggressive with updates. I want all updates that are upcoming anyway in small increments at a high frequency.

You have to deal with the changes at some point anyway. Taking them in small increments makes it easier to fix upcoming issues (because hopefully issues come one at a time and don't crowd you) and in extreme cases makes it easier to restore the previous state or even backing out a single change. For that reason some of my important stuff is on -STABLE, not RELEASE+patches.

Now, on the other hand, let's talk about mysql updates...


----------



## mer (Dec 19, 2022)

cracauer@ said:


> I want all updates that are upcoming anyway in small increments at a high frequency.


This makes it easier to find out what broke.  That's one thing I've always detested about Windows updates:  huge massive things that may or may not break anything.


----------

