Upstream packages will start breaking? - The future of TrueOS


This title may seem a bit dramatic, but I just would like to continue the discussion from Developer Blog Entries:

As stated there, as packages are expected to start breaking in future updates - because of upstream decisions - some default applications must better be abandoned and replaced by others, or must be rewritten to follow the path. This makes me think about the future of our beloved applications in TrueOS.

My path from Windows to Linux was something like: almost every application in Windows has a matching one in Linux - and it works.

Then, my path from Linux to FreeBSD was something like: almost every application in Linux has a port in FreeBSD - and it works better.

In the end, I didn’t need Linux or Windows for almost anything. I could to almost anything in FreeBSD and TrueOS - and do it better.

I still can.

But now it seems that FreeBSD is forced upstream to break compatibility with linuxisms which are turning ports unmaintainable. Some ports won’t be supported anymore, while some components have to be written from scratch (talk about Lumina). In the end, it seems we are walking a path that leads to having some applications written specifically for FreeBSD working fine - and taking a time to mature - while a lot of components written for Linux won’t work anymore for good. That’s sad.

Is this how it is? These are may impressions. Feel free to comment. Thanks!


Linux apps suck… We are very lucky to have people like Ken Moore that decided to build a FreeBSD DE from scratch instead of putting up with the Sucky Linux ones and they suck because they were made for Linux not BSD. If we can get more people like that will put in the time and effort to make something native to FreeBSD we would be okay.

I downloaded Audacity (from the AppCafe) and it wouldn’t let me save any files…It wouldn’t let me save anything no matter what I tried it always gave me an “invalid filename” error. It wasn’t built for BSD it was built for Linux and that means that It’s already broken on anything other than Linux.

I installed “PlayOnBSD” thinking someone had made a BSD version of “PlayOnLinux” but after I installed “PlayonBSD” I noticed on the left of it in big letters it said “PlayOnLinux” I never installed PlayOnLinux only PlayOnBSD so why doe it say in big letters “PlayOnLinux?” I uninstalled it because if they got the small stuff (like the name) wrong they are more than likely going to get the bigger stuff wrong.

So for me I think this is a good thing. Let FreeBSD and by extension (TrueOS) cleanse itself of all the Linux baggage and take this opportunity to have BSD native apps.

Just my humble opinion.


I came to FreeBSD/PC-BSD because of ZFS. And even though ZFS support in Linux has improved, it still sucks in various ways (e.g. zfs allow doesn’t actually work, forcing you to do everything as root, and aside from Ubuntu, no linux distro puts the ZFS drivers in the kernel, making root on zfs incredibly risky). So, I would hate to have to go back to Linux. That being said, KDE is my DE, and my normal workflow relies on the functionality and programs that it provides (e.g. you’re pretty much going to have to pry konqueror from my cold dead fingers). So, if KDE stops working in FreeBSD/TrueOS, I will be forced to switch back to Linux and deal with the pain that comes with that - and that will not be fun.

The fact that KDE 5 is not supported by FreeBSD yet is problematic from a support standpoint, but KDE 5 also lost some functionality in comparison to KDE 4 (at least for some of what I do), so I’m not all that heartbroken about using KDE 4 for now as long as it works.

Regardless, while I think that it’s great that something like Lumina exists and am sure that it will work quite well for many folks, I’m just too invested in KDE and its ecosystem to switch away from it unless I have no other reasonable choice.

Honestly, from where I sit, no OS is really a good solution. It’s question of tradeoffs and which sets of pain you want to deal with right now. I much prefer FreeBSD/TrueOS’ approach to the OS, but Linux is much better supported in that many projects target Linux (with some working on FreeBSD but many not), whereas relatively few target FreeBSD. So, I’m forced to have a Linux box to do certain things just like I’m forced to have a Windows box to do certain things. None of the OSes do everything that I’m looking to do, and it sucks.

Right now, I’m able to use TrueOS as my primary OS in spite of the problems that I have with it, but while I think that it’s great that we have some projects targeting FreeBSD, what I really want to see more of is programs just working everywhere. And unfortunately, it seems like a number of the choices being made in the Linux ecosystem really don’t jive well with that at all.


I run windows in a VirtualBox under TrueOS because some programmers decided that making DirectX a dependency of their program was a good idea. even on windows that program will not run unless you are using Internet Explorer and an older version of it also. Everything else works with Firefox on Windows, but not this no It’s IE or the highway… :sob:

Also quite a few of the programs we use here are written in VisualBasic and (for some unknown reason) will not work with WINE.

For the servers we have a combination of OS’s Windows, Linux and FreeBSD because some things will work better on one than the other. But on my computer I’ve only seen it once where something that ran on Linux didn’t run on TrueOS and that was Mathematica which BSDdriven figured out how to do

So I agree with you @jmdavis in that we need to run several OS’s because nothing works on a single one. But I also see the value in, if it doesn’t work get rid of it and build or find a replacement. I wish we could find a replacement for the program I just mentioned but we are stuck with it for the foreseeable future. :sweat:


OSX also has these problems… If everyone decides to turn TrueOS into Linux or Windows I’ll be forced to dump it. Having a distribution of FreeBSD that just works like OSX before the Steve died is a wonderful idea. So if some Linux support is lost I’m not offended. I am running TrueOS as my primary OS now and very happy with it. As long as there are apps which are native to FreeBSD even if cross compiled (NOT ported to some Linux libraries) I’ll be happy. Personally I’m a big fan of VirtualBox. If you really need Windows, or Linux I understand. So run it in a VM and keep BSD clean. If you properly design your machine with enough CPU and Memory then this works great. I’m not a gamer but if you are you’ll just need 2 machines I guess. Linux apps run best on Linux. Windows apps run best Windows. So run the VM and keep thing native. This is far superior than emulators and ported libraries. Not to mention much more secure. PLEASE PLEASE do not turn TrueOS into Linux.
Ok I’m off my soapbox.


It’s always about the applications you need to run, almost never about what you’re running them on.
Packages come from ports, ports are the applications and come from outside the project. Someone (ports maintainer) takes the source code and creates a port so that it builds on FreeBSD. Non trivial work, but what do you do when application A has a bunch of dependencies? And then those dependencies have other dependencies? Snowball, rolling down a hill, gaining speed.
If things are written against the standard C/C++ libraries, it’s usually just a rebuild.
Yes, there are a lot of things in the ports tree that pull in a lot of Linux-isms but that is different from having the FreeBSD kernel provide “Linux support” (Linuxulator, changes for the Linux KPI needed by video drivers). To me, kernel provided support for native Linux executables is not turning FreeBSD into Linux.
Now trying to make systemd the init system in FreeBSD would be a step in the wrong direction.


Just to interject with the TrueOS stance on external applications:

As far as TrueOS is concerned, it is not our responsibility to ensure that Linux-based apps and such are available in the package repository and how well they work - this falls under the perview of the FreeBSD community and ports committers. What we are most concerned with is the reliability/stability/dependencies of the “base” applications that we pre-install on systems so that all the general use-cases can function reliably.

The types of application functionality we are most interested in are:
- General Applications -

  1. File Manager (can you browse/open files graphically?)
  2. Terminal (can you get a virtual CLI?)
  3. Web Browser (can you get to the internet?)
  4. Email Client (since we are old fashioned and don’t generally care for the web-based email portals)

- File Support Applications

  1. PDF Viewer (can you download/view/print official documents and/or give presentations?)
  2. Text editor (both CLI and graphical)
  3. Multimedia Player

Note that these applications don’t need to be massive or cover every possible file type or use-case, they just need to hit the basics (an office workstation or web-user) and be functional all the time.

By the same token though, there is also the “desktop” functionality which must be considered and reliable as well:

  1. Can you login with an arbitrary user account (AD/LDAP/Local)?
  2. Can you launch/manage applications easily?
  3. Can you see system notifications/status easily? (battery status, network connectivity, etc)
  4. Can it run on low-end systems or systems without GPU acceleration?

This is what we consider the “core” functionality of TrueOS - all other use cases (audio/video production, graphic design, radio broadcasting, [your-usage-here]) are not the responsibility of the TrueOS team itself, but rather the FreeBSD community-at-large to ensure that “Application X” is available and functional.


@beanpole135 this is a good list of what is considered essential.
How about C compiler/LLVM? I ran into an oddity around the xrdb command trying to define .Xresources. It’s probably using the C preprocessor and without llvm installed (or at least linked to /usr/bin/cc correctly) the command appears to run but no changes are merged.
A system with the last unstable updates has /usr/bin/cc referencing clang40, but llvm39 is installed as a dependency of libEGL and dri.
Email: should be text and mutt or pine/alpine sufficient.


The LLVM stuff is actually hitting FreeBSD itself right now too (no way to register the “default” version of llvm yet - so some ports are requiring different versions and such). Once they determine the best way to resolve that issue we will adjust here as well.


Thanks. I keep an eye on the FreeBSD mailing lists (some fun churn going on with the bootloader right now) just figured I’d ask.