My problems with FreeBSD

[mariourk]

Hi,

Lately I've developed some frustration towards FreeBSD. Mainly how it handles upgrades and updates. So, I want to give my two cents. This is by no means intended as an anry rant or anything. The FreeBSD community has always been kind to me and I don't mean to offend anyone. I just want to give some honest and (hopefully) contructive criticism.

I've been using Linux since the late nineties. Around 2011, I started using FreeBSD on several of my servers. The reason I jumped ship, was because of the excellent ZFS support FreeBSD offers. And how nicely it is integrated into the system itself. I absolutely love ZFS. I also found that the FreeBSD community is very helpfull and friendly overall. (In all fairness, I never had any negative experience with the Linux community either)

However, in recent years FreeBSD has managed to render itself completely unusable to run on production servers. Well, in my case, anyway. Let me explain what I mean.

When I run an LTS release of Ubuntu, I can be pretty certain that the OS and it packages remain pretty much the same throughout it's 5-year life cycle. Updates will be, for the most part, just security patches. Nothing fancy. Which is exactly what I expect from a server OS. I can install patches and updates without really worrying about breaking anything. Which, again, is exactly what I expect from a server OS.

The same goes for Windows. I can even install service packs (more or less what FreeBSD calls a minor upgrade) and be fairly certain that everything will work just fine, after the reboot.

But when it comes to FreeBSD, updates are rarely smooth. And to make things worse, FreeBSD pretty much forces you to upgrade. Wether you want it, or not. Because if you don't, you're going to run into a whole lot of problems later on. And it makes you do this at least once a year. On all your servers.

And this is my biggest complaint about FreeBSD. FreeBSD happily roles out a new minor release about once a year, or so. And when that happens, you have three months to upgrade your servers. After that, it becomes really difficult to maintain your server. To the point where it becomes downright impossible. You have to upgrade. And you know what, I can actually understand that. Security reasons and all. And I would happily go along. The problem is that FreeBSD tends to break things. Even between minor releases. And that is what bugs me the most. FreeBSD shouldn't do that between minor releases. It's fine between major releases. Unavoidable, even. That I understand. And that shouldn't be a problem, because major releases are years apart. When that time comes, it's a good moment to upgrade the entire server altogether and start from scratch.

The irony is that people usually praise FreeBSD for being consistent, easy and predictable. Take for example this thread on Reddit:

In general, the BSDs are cleaner and much more consistent than the GNU/Linux distros.

Things are built to last instead of the wheel being reinvented weekly.

I'm no stranger to Linux and I have a favorite distro, but I often go for BSD when I can because I usually find it easier to manage, more lightweight and simple, but just as powerful. In other words, it's most convenient.

The result for the end user is a more stable system that behaves predictably and works the way you expect.

The thing is, that my experience is actually the complete opposite.

Let me give a few examples.

I needed to install Python-3 on one of my servers. This server was still running FreeBSD-11.1. When installing Python-3, pkg warned me that I was running an outdated version of FreeBSD, which was no longer supported. But what was I going to do? I needed Python-3. So, I installed it anyway. And it installed fine. But when I tried to run any script, it complained about libdl.so.1 not being found. It turned out that the newer versions of several packages now depend on this library, because of a change between FreeBSD-11.1 and FreeBSD-11.2. So much for consistency.

Another example is when I needed to install a website. This website needed php-gd. It installed, but now libpng complained about libz. This led me to this blogpost. Notice how he writes:

In fact, there were a lot of threads indicating this issue. And pretty much all answers were the same as in this thread: “stop whining and upgrade your OS”. Yes, that’s how FreeBSD works these days, which is one of the main reasons why I’m in the process of switching back to Linux. I fail to see how a three-month support period on a release would work in production. So screw you, FreeBSD.

I wouldn't go as far as saying: "Screw you, FreeBSD!". But it's certainly nice to know I'm not alone in this.

And a final example is when I finally bit the bullet to upgrade a mailserver, still running FreeBSD-11.0. After the ugrade itself was done, freebsd-update told me to reinstall all installed packages. Obviously because of breakages as mentioned above. And that on it's own it already pretty ridiculous, when you think about it. I don't want to do risky stuff like this on a production server. And low and behold, when I tried to update Dovecot, I got errors. So I turned to pkg updating to find out this:

Now that dovecot1 has been removed from the ports tree, dovecot2 and dovecot2-pigeonhole have been renamed to simply dovecot and dovecot-pigeonhole.

Why? Why would anyone rename a package? That isn't consistent at all. It can only create all kinds of potential problems, that could easily be avoided by not renaming the package in the first place.

To be fair, it goes on by saying:

pkg should handle the rename automatically, but if you run into trouble, you can point pkg at the new origin via:

Notice the reservation, how it should handle the rename automatically. But in my case, of course it didn't. First of all I never used pkg to install Dovecot. I had to compile it with ports, because I needed PostgreSQL support, which wasn't included in the binary pkg. So, I used postmaster, as suggested by pkg updating. After the update, email stopped working, despite Dovecot seemed to run. I quick glance in the logs learned that there was no PostgreSQL support.

So, I go to the ports directory, run make config, enable PostgreSQL support and run make reinstall. Only to run into error 70, at the end of the compilation. Sigh... What now? So I fired up Google to find out what was going on. It more or less came down to: "Oh yeah, we removed make reinstall. That doesn't work anymore".

Which brings me to another complaint about FreeBSD. As far as I know, it's not possible to see wether I used pkg to install an unaltered binary package, or ports, to compile it myself. And if I used ports, I also can't see why I used ports. I other words, what options did I change, before building the package?

Maybe someone reading this thinks: "Well, you could just run grep /to/some/obscure/path | sed --obscure --flags | more --black --magic and you would get what you want." But stuff like that isn't really intuitive, isn't it? I could also keep a log. But that is messy and shouldn't be necessary in the first place. FreeBSD should provide tools to do this in a convenient and straightforward way. And if FreeBSD happens to have such tools, feel free to correct me. I'd be very happy to know.

Anyway, back to the mailserver. FreeBSD also informed me that support for PostgreSQL 9.3 will end after january 2019, pretty much forcing me to do messy upgrades between versions. Which I obviously want to avoid, as long as this server is in production. Knowing myself, when I installed FreeBSD-11.0, I went with PostgreSQL-9.3, because it was the default version. And I would expect it to be supported throughout the entire 11.X life cycle. But no, FreeBSD janks it away and forces you to perform risky migrations on production servers.

I also ran into problems with automake-wrapper. I got complaints from pkg about conflicting files. Apparently automake-wrapper is obsolete now and merged with something else. Another breakage. Granted, fixing this one was easy. But still, it's one of those non-consistency problems you keep running into.

In the case of this mailserver, things got so messy, that after wasting hours of tackling one breaking package after another, I just pulled the plug and rolled back a snapshop (thank God for virtualization). Screw this! It's easier and less risky to just create a new VM, start from scratch and migrate all email(accounts).

When I perform (minor!) FreeBSD upgrades, I run into all kinds of trouble, way too often. And I have to use Google way too often, to figure out what went wrong. I have to keep track of a plethora of changes, merges, splits and whatnots of packages, via pkg upgrading. I constantly have to be on my guard and on my toes, to make sure it all goes well. Which is, to be honest, pretty nerve wracking. And it keeps coming back, every year! And most of the time it's pretty much just for the sake of upgrading. I don't gain anything from the newer versions. It offers me nothing but trouble. This is not how I want to manage my servers. I should be able to just install updates, perform the minor upgrades and be done. But sadly, that is not how FreeBSD works.

If I was running one or two servers, I could live with this. But when you're running multiple servers, stuff like this is getting on your nerves pretty quickly. Especially concidering when upgrades are usually done in the evenings and weekends.

FreeBSD should keep consistent throughout the entire life cycle of a release, including all minor upgrades. Don't remove features like make reinstall, or change dependencies like you did with libdl.so.1. Save that for major upgrades. Also, keep ports consistent throughout all minor releases. Don't suddenly rename packages. Or break stuff like libpng complaining about libz. This makes upgrading much easier and way less stressfull. And it leaves the option to just... well... not upgrade (and still be able to use ports). Or at least put it off to a more convenient time, because catching up is easy. As it should be.

I'm still concidering my options. But it's certain that I won't go on like this. Which is a shame, because I still concider FreeBSD to be a very good OS. If only it was truely consistent, like people say it is.

So, to summarize, I think the problem I have with FreeBSD can be condensed into the following statement: "FreeBSD isn't as consistent as people want you to believe. And as a result of that, it breaks way too fast, if you don't keep up. And the further you fall behind, the harder it is to catch up."

The forced minor upgrades and the changes between them, are the bane of my work. I can't do it anymore.

 

[Minbari]

1. Don't mix ports with packages.
2. Always read /usr/ports/UPDATING before perform any updates.
3. If you want to have custom packages use poudriere or synth and create your own repository, at least this is what I do on my machines and this way I can avoid a lots of problems which as you mention exists. As for the "support" cycle, yeah it sucks.

 

[shkhln]

And when that happens, you have three months to upgrade your servers. After that, it becomes really difficult to maintain your server. To the point where it becomes downright impossible. You have to upgrade. And you know what, I can actually understand that. Security reasons and all.

No, it's not related to security best practices, server management philosophy or whatever. The project doesn't have enough resources to support your servers for free (for an extended period of time). The new support schedule simply reflects available manpower better.

So, I go to the ports directory, run make config, enable PostgreSQL support and run make reinstall. Only to run into error 70, at the end of the compilation. Sigh... What now? So I fired up Google to find out what was going on. It more or less came down to: "Oh yeah, we removed make reinstall. That doesn't work anymore".

I'm not sure what you have found, but that sounds ridiculous.

 

[drhowarddrfine]

my biggest complaint about FreeBSD
You have to upgrade.
I can actually understand that.

Sounds like a contradiction in your feelings. On top of that, if FreeBSD didn't upgrade, we'd hear all kinds of complaints about that, too. The reason for "forced upgrades" is to provide consistency but I'm not sure "forced upgrades" is true. I ran two servers on PIII boxes until about five years ago. fwiw, I run a web dev company and we have a large number of servers we've been running FreeBSD on for 15 years without issue other than the occasional quirk. But every OS, Linux and Windows included, has problems with upgrades far worse than anything I've encountered.

I see you mixed ports with packages and now you've shot yourself in the foot as the warning not to do that is everywhere.

When I perform (minor!) FreeBSD upgrades, I run into all kinds of trouble

And we don't. Most of us don't. And whenever anyone says this I automatically red flag the comment because it must be remembered that there are thousands and thousands of daily users of FreeBSD who don't. So my first thought is that they/you have a misconfigured system and/or are confused about the proper installation. Occasionally one comes here, we see their config files, and it looks like they just slapped anything in there they read on a forum somewhere (especially reddit. Please NEVER use reddit as a reference!!).

I see myself starting to pile on so I'm going to stop now. I don't know your situation or use but remember what I said. There are thousands of us running this professional operating system without any of the issues you bring up.

 

[ShelLuser]

Now, I went over your profile before writing this because, I'll be honest, my first impression was: "Here we go again, why FreeBSD isn't more like Linux". Now, the reason why I'm giving you the benefit of the doubt with regards to my response (taking the time for it) is because you don't have a history of complaining and I think you're being honest here. Also: I somewhat shared some concerns myself as well, wrt. the 3 month cycle. Still...

When I run an LTS release of Ubuntu, I can be pretty certain that the OS and it packages remain pretty much the same throughout it's 5-year life cycle. Updates will be, for the most part, just security patches. Nothing fancy. Which is exactly what I expect from a server OS. I can install patches and updates without really worrying about breaking anything. Which, again, is exactly what I expect from a server OS.

True. And while you're enjoying your 5 year life cycle the underlying development continues so when your LTS version runs at an end you're now looking at an upgrade which will span multiple major releases which can, depending on your setup, end in total drama. Especially when you come across bugs somewhere along the way and you'll end up installing each and every major version individually because there's no other way to upgrade.

You don't safe time with Ubuntu LTS; you're only postponing the inevitable and most of the times making things much worse over time.

But when it comes to FreeBSD, updates are rarely smooth.

Then you're doing something wrong.

And to make things worse, FreeBSD pretty much forces you to upgrade. Wether you want it, or not.

True, but not fully. I'm not happy with it but I still maintain a 10.4 server and a 11-RELEASE server, I just installed a new version of GPG onto the 11-RELEASE last week even though it's not officially supported anymore.

However, you're also not being fully honest here because most updates are minor releases: from 11.0 to 11.1 to 11.2. Even freebsd-update can handle those and they won't have much impact on your system at all. Also noteworthy is that even though I do agree that the 11 branch changed a lot it's not that bad either.

You do realize that 11 got released in 2017 and it said to be supported to 2021? That is 4 years of continuous support.

Once again: a minor version upgrade doesn't have to be that much intrusive at all.

Because if you don't, you're going to run into a whole lot of problems later on. And it makes you do this at least once a year. On all your servers.

Actually the planning is at least twice a year (every 6 months). You should look into PkgBase though, I just confirmed that it's already doing "something" on 11.2 (but not fully). That's going to make future upgrades even easier than before!

And this is my biggest complaint about FreeBSD. FreeBSD happily roles out a new minor release about once a year, or so. And when that happens, you have three months to upgrade your servers. After that, it becomes really difficult to maintain your server. To the point where it becomes downright impossible.

No offense intended (seriously) but I cannot help but wonder how the heck you upgrade and maintain your servers. As mentioned before I still maintain a 10.4 (long time EOL) and 11.0 (EOL by a few months) and it's hardly as difficult as you make it sound.

Sure you have to pass a few (documented) failsaves and you might also have to perform the building of some ports on a different server and "push them backwards" as I like to call it, but it's easily doable. Worst case scenarios is jails for the win.

Of course what you can't do is ask on the forum for help, and although I don't have much experience with them I'd assume the same for the mailinglists. IMO rightfully so because it's already difficult enough trying to help people with problems on supported versions.

But it's doable. If you know what you're doing. And you need to know what you're doing because in most cases those upgrades are for security reasons (coincidence has it that I'm in the process of updating my server as we speak):

P4
        Fix regression in IPv6 fragment reassembly. [EN-18:09.ip]
        Fix NULL pointer dereference in freebsd4_getfsstat. [EN-18:10.syscall]
        Fix DoS in listen syscall over IPv6 socket. [EN-18:11.listen]

P3
        Fix improper elf header parsing. [SA-18:12.elf]
        Fix regression in Lazy FPU remediation. [EN-18:08.lazyfpu]

P2
        Revise manual pages. [SA-18:08.tcp]
        Fix L1 Terminal Fault (L1TF) kernel information disclosure.
        [SA-18:09.l1tf]

        Fix resource exhaustion in IP fragment reassembly. [SA-18:10.ip]

        Fix unauthenticated EAPOL-Key decryption vulnerability.
        [SA-18:11.hostapd]

P1
        Fix resource exhaustion in TCP reassembly.

Notice the mention of DoS & a vulnerability up there? Maybe you enjoy working on broken systems and taking the risk for attacks, but I sure don't.

(edit)

Changes between minor versions? What changes? I'm looking at the Makefile right now, it's only fixes, no (drastic) changes at all. Heck, I'll copy P1 too then, IMO you're not being very honest there. I can definitely understand that it may seem like a massive drag, but it is still important to stick to the facts.

 

[olli@]

I think many of the problems described here are ultimately caused by mixing ports and packages. Dependency problems and library version mismatches are a typical symptom of that. Sooner or later it causes all kinds of trouble. So don't do that.

If you can't use binary packages only, because you need to build some ports with non-default configuration, then it's better to not use any packages at all, but build everything from ports yourself. There are frameworks like Poudriere that help in building your own package repository from ports with your own configuration – this is very helpful if you maintain a larger number of machines.

At home I do without Poudriere because it's not worth the effort: There are only three FreeBSD machines, and two of them don't need many packages. So I just build from ports on my workstation, and then do pkg create; scp; pkg add manually for those packages that I need on the other two machines. Ok, I have a few little scripts that automate that, but it's not a big deal.

 

[jb_fvwm2]

I thought production server/S/ were meant to update AFTER the non-production TEST server machine(s) did ??? As a best practice...

 

[ShelLuser]

Apologies for a double post, but as I said you do sound sincere in my opinion so other than sharing my opinion I'd also like to address some of your problems in hopes that it might help you run things more smoothly in the future.

But what was I going to do? I needed Python-3. So, I installed it anyway. And it installed fine. But when I tried to run any script, it complained about libdl.so.1 not being found. It turned out that the newer versions of several packages now depend on this library, because of a change between FreeBSD-11.1 and FreeBSD-11.2. So much for consistency.

Easily circumvented by building your own packages using the ports collection.

This is not merely a concern with outdated versions but binary packages as a whole. Heck, only today did I learn that the devel/git binary package isn't build with GUI support, even though the git(8) manualpage still contains a reference to git-gui(8)! My personal (biased) opinion on this is simple: stupid.

But it doesn't bother me because on my main working environments (my servers/workstations) I use ports, and Git (and all other software) contains exactly what I need of it.

Heck, we're still using PHP 5.6 instead of 7.2.

But you need to understand 2 things: Binary packages aren't being maintained by the FreeBSD foundation but individual enthusiasts, who will obviously make sure that those packages support the latest supported version. They come with pre-determined settings which sometimes (most often for me) may not reflect your ideas of a working package. The solution is simple: the ports collection. THAT is the thing which makes those people rant about FreeBSD's flexibility & consistency because you're in control with the ports collection.

Another example is when I needed to install a website. This website needed php-gd. It installed, but now libpng complained about libz. This led me to this blogpost. Notice how he writes:

That seems to cover FreeNAS and FreeNAS is not the same as FreeBSD.

After the ugrade itself was done, freebsd-update told me to reinstall all installed packages. Obviously because of breakages as mentioned above. And that on it's own it already pretty ridiculous, when you think about it.

I have to disagree with you on that one. Also note that re-installing ports/packages is only required with major version upgrades.

I don't want to do risky stuff like this on a production server. And low and behold, when I tried to update Dovecot, I got errors. So I turned to pkg updating to find out this:

Why? Why would anyone rename a package? That isn't consistent at all. It can only create all kinds of potential problems, that could easily be avoided by not renaming the package in the first place.

Sometimes there is no choice, simple. I agree that some changes could probably have been avoided but then it is also important to keep in mind that the maintainers are simply volunteers who are trying their best to give us the best experience. And sometimes mistakes are made.

This is why, despite my passion for FreeBSD, I never blindly rely on the system. I don't use packages on production servers because I need to know exactly up-front what I can expect with regards to functionality. And I also don't upgrade servers "just like that". I have a staging server which is used for internal (LAN) production work and which always gets updates first.

Once a package runs smoothly for 1 week then it'll get installed onto other servers using a private package repository ("compile once, install many"). Once an OS upgrade runs smoothly for 2 - 4 weeks then I'm planning an upgrade of the remote servers.

Back to package renames: usually all it takes is one pkg command.

And it's not as if you can't see these changes coming either. This is why pkg-updating(8) exists after all. Never perform an upgrade 'just like that'.

Now, this is a crude example but even so:

#!/bin/sh

for a in $(pkg version -qol\< | cut -w -f1); do pkg updating $a >> updating.log; done

This goes over your packages for which an update is available and then it'll check the packages database, and if there's something available that gets logged into updating.log. It's a bit of a crude script but should be of some help to overcome these annoyances.

Note: this is just a quick setup from mind, probably needs tuning.

First of all I never used pkg to install Dovecot. I had to compile it with ports, because I needed PostgreSQL support, which wasn't included in the binary pkg. So, I used postmaster, as suggested by pkg updating.

And now we unraveled the cause of all your problems.

Don't mix ports and packages!

And here is why:
https://forums.freebsd.org/threads/guide-about-ports-and-binary-packages.62126/

The best way to do this is to build your own repository.

Here I explain how to do that with only Portmaster & the pkg tool:

https://forums.freebsd.org/threads/guide-building-a-package-repository-with-portmaster.68179/

And here our own KPA explains how to set this up using Poudriere (Poudriere is also used to build all those binary packages in the main repositories):

https://forums.freebsd.org/threads/...rts-mgmt-poudriere-with-or-without-zfs.38859/

When I perform (minor!) FreeBSD upgrades, I run into all kinds of trouble, way too often. And I have to use Google way too often, to figure out what went wrong. I have to keep track of a plethora of changes, merges, splits and whatnots of packages, via pkg upgrading.

No offense intended but those are all self-inflicted problems. Even the handbook explicitly warns you against mixing ports and packages.

So the solution is to fully convert and either build everything using the ports collection or revert back to binary packages and then accept that some things won't work.

To revert back to packages you'd run: pkg upgrade -f (after ensuring your package repository of course, see /etc/pkg and /usr/local/etc/pkg) and then you should be back to normal.

Or stop using packages all together and rely on ports. You don't really have to fully convert right away but it will be important to stop using pkg install entirely from this point on.

And I strongly suggest that you build yourself your own private package repository. It's honestly extremely easy (the only reason my tutorial is so long is because I tried to explain all details, including Portmaster and the issue with packag dependencies) and this can also be very satisfying (not to mention save plenty of time!).

In my previous post I mentioned how I still maintained EOL servers? This is how I did that: my own package repository. (just make sure to honor ${ABI} or else you'll run into issues ).

I hope this post can be more helpful than my previous one which basically boils down to "I think you're wrong" and that's it

 

[Deleted member 30996]

Sigh... What now? So I fired up Google to find out what was going on. It more or less came down to: "Oh yeah, we removed make reinstall. That doesn't work anymore".

Yes it does. Here's my post from 10-21-18 documenting the recent use of make reinstall clean.

https://forums.freebsd.org/threads/installing-firefox.61998/#post-404196

 

[mariourk]

I'm giving you the benefit of the doubt

Well, thank you for giving me the benefit of the doubt

You are correct that upgrading between LTS-releases is much more messier. Which is why I don't do it. 5 years is a long time to run a server. So I usually use this as an opportunity to decommission a server entirely and start from scratch on a new one. Virtualization made this even easier. It might involve some more work as a whole, but it's a lot less risky. And the majority of the work, I can do during the day, without bothering anyone with downtime. FreeBSD's 1 year life cycle (more or less) makes this a bit... less obvious.

When I wrote my post, I was fully aware that at least some of the problems would be my own fault. But I figured that the worst that could happen was someone pointing out my mistakes. Which would be a good thing. Apparently my biggest mistake was mixing ports with packages. Somehow I missed that. In my mind it wasn't preferable, but sometimes unavoidable. Apparently it's simply not done.

When I talk about forced upgrades, I mean you pretty much have no choice but to go along. Because if you don't, it will cause problems later on. At least, in my experience. I agree that minor upgrades shouldn't be that intrusive. But in my experience, they are. It's always something. Which makes me hesitant to do the upgrades at all. Going over the replies to my original post, I obviously do have some wrong habits, I should look into. But overall, I always aim to run my servers as clean as possible. I hate bloat and I try to avoid it where I can. The less dependencies, the better. I also aim to strickly use packages. But in some cases that just isn't possible. At least now I know, I should fall back on ports entirely. Not just one or two packages.

Compiling packages on another server is something I have never done. And I don't think I'm on "that level", so not really an option for me, I'm afraid. But who knows, maybe I should look into this. But for now, I rely on ports. Which forces me to move along. Which sadly causes some stress and frustation for me.

Changes between minor versions? What changes?

Like the one I pointed out with Python-3, suddenly relying on libdl.so.1. Apparently this is some confusion on my part and this is more a problem with packages and not perse FreeBSD itself. But still, the newer packages suddenly need different dependencies, which an older system doesn't have. Which is what I mean you're more or less forced to keep up, when you're relying on packages.

Maybe I should stop using packages as a whole and from now on only use ports. Which is kind of a shame, because I was hoping to reduce the whole compiling business, when switching to FreeBSD. You see, before I started using FreeBSD, I used Gentoo Linux a lot. But eventually, all the compiling got the better of me and I started looking for something else. I thought FreeBSD's pkg system was kind of neat and exactly what I was looking for. But hey, CPU's have gotten a lot faster since then. So... Who knows. Let's start small.

As for pkg updating, I still think it's a messy solution. On the one hand, it's good that there is a central source to keep track of all the changes. But on the other hand, it can be pretty nerve wracking to make sure every update is going to be ok. I feel the whole merging, splitting and renaming business involving packages could be reduced a lot, as I mentioned with my Dovecot example. But it is what it is, I'm afraid. I'll look into your pitch to streamline the information a bit more to my personal situation, though. So, thanks!

The things I take from this is that I should look into running and maintaining my own private package repository. And I should avoid pkg and use ports instead. I also want to invest even more in virtualization. Since it provides a nice safety net

Thanks!

 

[drhowarddrfine]

Maybe I should stop using packages as a whole and from now on only use ports.

Ports aren't going to protect you from changes requiring new dependencies. Many people use packages versus ports all the time. The only reason we use ports is because some of our software runs on the bleeding edge and we don't want to wait. But packages are only ports that have been pre-compiled with default settings so, again, I'm not sure switching to ports is going to solve anything for you.

 

[Max212]

I am no expert in FreeBSD, but I am running several servers and one laptop as a Desktop
What I have learned during my time with FreeBSD is that updating software regularly helps maintain working system as a whole. When there is a new release of FreeBSD usually I wait 6 months before I do an upgrade. For now I had no issues with FreeBSD upgrades. One of the servers was deployed years ago (version 9.1) and I am regularly updating it and now runs version 11.2.

my 2 cents...

 

[blackhaz]

mariourk, you're definitely not alone. The same breakage happens to FreeBSD desktops as well. I have been vocal around the forum a few times about this. Not every desktop user wants to upgrade all their packages every X months. The way the default repositories are structured, the upgrades are forced onto users. I am a huge proponent of using application bundles, like on Mac OS, as quite often those upgrades break complex desktop apps too. I don't mind upgrades but sometimes I need to stick with a specific version of software, or roll back after something went wrong, and if it came as a bundle with its own dependencies, it wouldn't have to depend on other stuff that is being "force-upgraded" periodically.

 

[bds]

1. If you build ports then I definitely recommend doing so in a dedicated jail, then creating a repo to push pkgs to consumers. Use pkg check -dan, pkg check -Ban to make sure dependencies, shared libs etc are all square. If you're not prepared to put in the work to do this, you may be better off sticking to packages. Control freak or lazy, the choice is yours.
2. If you're using ZFS you can back out of a pkg upgrade more quickly and reliably than using the package system. Make sure /usr/local and /var/db/pkg have dedicated ZFS datasets (possibly /boot/modules and /boot/firmware too), and snapshot them every time you update.
3. If a particular package is problematic, you can prevent that package being upgraded until it is resolved using pkg lock/unlock.
4. Before deploying changes to production servers, test your applications against them on a different host first.
5. Treat the FreeBSD kernel/userland and the ports/packages system as separate (albeit closely related) beasts - as opposed to Linux distributions that deliver everything as packages.

 

[Deleted member 30996]

[TR][TD]

The same breakage happens to FreeBSD desktops as well. I have been vocal around the forum a few times about this. Not every desktop user wants to upgrade all their packages every X months. The way the default repositories are structured, the upgrades are forced onto users.

Not knowing the value you set for X, who does that?

I usually only upgrade 3rd party programs if there is a vulnerability, port-mgmt/portmaster recommends doing so when updating another program or it's port-mgmt/portmaster that needs updating. Doing so periodically, in my experience, can end up being more trouble than it's worth.

I am taking into account my desktops aren't critical to a business operation and that I have the time and experience to fiddle with something like ports, where someone else might not do so as easily.
[/TD][/TR]

 

[ShelLuser]

I can't help but wonder if some people seem to forget the kind of OS they're on. If you don't want to update a certain port then don't. You're not forced to use the package system; you can just as easily run make extract to grab the original (unpatched) source code, then install that yourself. Sure, won't work for 'trunk' nor 'branch' ports (=software which is required by other software) but that's usually not what you'd refer to when it comes to 'having to upgrade to a new version'.

Also noteworthy is that it's not necessarily the port/package maintainer which decides that an upgrade is needed. A port (thus its package) is after all merely software which follows the original source tree as maintained by its author(s). In my opinion games/nethack36 is a good example of this: that game stayed 'active' within the ports collection for over 6 or so years without any updates..

 

[drhowarddrfine]

I can't help but wonder if some people seem to forget the kind of OS they're on.

I say it often. FreeBSD is a professional operating system for professionals and computer enthusiasts. "Enthusiasts" need to remember the professional part and what they are delving into. Some professionals don't think about that part sometimes, too.

 

[blackhaz]

Trihexagonal, I can come up with myriads of reasons why one may prefer to run an old version of software. I think my MacBook still runs El Capitan. If you're working on a scientific project, you want to make sure absolutely nothing changes in your lab. Many of research apps aren't even exposed to the Internet so they are not of a security concern whatsoever. Would running an old version of R or TeX be considered a threat? How about, say, an observatory control software, or a software pipeline to process scientific data coming from a telescope? How about a FreeBSD machine that is monitoring solar activity? I imagine there could be many similar situations across many environments and industries. As a typical desktop user with thousands of packages installed, sometimes those upgrades break stuff, and I simply have to get back to the previous version to continue working.

I think it's wrong to address security with forced upgrades. This strips the liberty of choice from the end user. If someone opts to run specific software version, why should OS interfere? If there's a security concern, the user should be allowed to address it with the way he pleases, e.g. firewalls.

EDIT: I've just re-read your post and understood I'm answering the wrong question. Whoops. The way upgrades are forced is through the quarterly repo. Install FreeBSD, get happy, then the quarterly repo gets updated, you want to add a package and then it hauls dependencies, and those dependencies haul other dependencies, so if you, almighty forbids, want to upgrade Firefox, you end up upgrading TeX and the whole 1200 packages along with it. You can't selectively upgrade application X, if it has a complex network of dependencies, without upgrading the whole theatre. In other words, I think shared libraries suck on desktop machines. Sorry if I hijacked the thread with this.

 

[yuripv]

The answer for all issues raised here: lack of manpower. Support model adopts to what we have available, it's that simple.

 

[Deleted member 30996]

Many of research apps aren't even exposed to the Internet so they are not of a security concern whatsoever.

I have an X61 that serves as my dedicated .mp3 player that is still at FreeBSD 11.1-RELEASE-p10. It's never connected to the net and since it couldn't be running better I don't update it. It just passed 6 months uptime.

Something like www/youtube_dl I update every time I see one is available. I do read what's downloaded when I run portsnap fetch update. I'm still at GIMP 2.8.22 on the machine I'm on now, it's at GIMP 2.10.6.2 in ports. That's something I use every day but haven't felt the need to update it.

I've been watching to see if www/seamonkey will ever be fixed and sometime update everything ports-mgmt/portmaster recommends even though it's not going to install the Monk. Will that break something else? Maybe. I can fix it but sometimes it's just not worth messing with.

 

[wolffnx]

like the gurus tell you,dont mix ports and packages, i'am pretty new to FreeBSD but i learned that in the hard way
only in the desktop, for example my last instalation was everything from the ports(even X), so the "base" packages for
call it some way in X,like gtk2,etc , compiles all together, and only install from a package when is someting "small"
like nano a file manager..some terminal emulator..etc
and for the servers that run beastie, the same, without X of course

 

[sidetone]

I was thinking that's the administrator's responsibility.

Then, I updated a few xorg, video drivers and desktop dependencies. It didn't work on the reboot. I removed all ports, and tried to install llvm70 from packages, and its dependency, python27 wouldn't install due to some size mismatch. Python's dependencies wouldn't install through packages either, because those couldn't be found, even though they showed up through pkg search. If I'm not mistaken, the packages system is messed up, but something like this would probably be my system. I don't care for people repeating over and over about mixing ports and packages. If you keep track of what you're doing, it's not a problem. Also, with a clean slate on ports/packages, basic packages aren't working for me.

I'm going to try both quarterly ports and packages.

I remember how to set packages for quarterly, and ports to quarterly through svnup, but I forgot how to set ports through portsnap. I see the file /etc/portsnap.conf, and the manpage doesn't help with that.

 

[VladiBG]

portnsap is for HEAD only if you need the quarterly branch you can use svn.
When you update a program from the ports which previous was installed from the packages you will break all other programs (unless you rebuild all of them) which share the same dependences. For that reason i use only the ports and build everything from them. Yes it's very time consuming process and from time to time you will need to make some adjustments according the /usr/ports/UPDATING.

 

[sidetone]

For svn, they changed the quarterly tag to branches, then the year and quarter.

So you would use a long term EOL release, as others have said, and perhaps one of the quarterly branches. Do 2018Q4 or the latest port branches get security updates?

 

[VladiBG]

https://svn.freebsd.org/ports/branches/