Developer Blog Entries


I’ve been using TrueOS with Lumina as my primary OS since just prior to the rebrand and am loving it :slight_smile:
I’m constantly checking the TrueOS and Lumina-Desktop sites for any info on up coming features/releases.

Unfortunately the Lumina-Desktop site seems to seldom get updated with new news.
Is there any chance of getting some more news on the site such as developer entries (weekly/monthly) where we can be made aware not only of what’s been worked on but possibly insights into some of the problems that have been experienced and why certain design decisions were made. I think this could help encourage new development as the project will appear more active. It would also help prospective contributors get a feel for the direction of the project and get an idea of if they’d be a good fit for the project.

Also, on a slightly related note… Does anyone know if we are nearing a 1.3.0 release given the recent release cadence?

Keep up the good work!!!


not exactly what you want. Do you have the desktop RSS feed installed on your desktop?

It gives updates on Lumina, TrueOS, and FreeBSD


Not currently but that only seemed to pull through what was announced on the website anyway.
+1 for convenience but updates still lacking (sorry Ken I know you’re probably pretty busy).


Yeah, it has been on my list to start doing weekly updates to the Lumina blog (kind of like @mrt134 does for the TrueOS blog), I just have not been able to find the time recently.

I am planning on a 1.3.0 update for Lumina sometime here in the near future - I just need to finish up a couple things first:

  1. New default icon theme (almost done). With the oxygen icon theme which Lumina has been using getting moved/changed to require some new KF5 (KDE) dependencies which are causing interesting dependency/build issues on FreeBSD, the new icon theme was bumped up to URGENT priority and should be finished here really soon.

  2. Decide what to do with a couple new utilities in Lumina:

  • lumina-pdf
    Simple Qt5 PDF viewer using the poppler-qt5 library. This already works mostly (the printing support could get a bit more work), but I am trying to decide if I should continue working on this or just recommend something like qdfpviewer (the Qt5 version) for TrueOS instead. I am leaning toward backburner-ing this until the new PDF support backend lands in Qt5 (coming soon from what I have read) and re-implement this using that functionality instead. This gets rid of the possible pollution of the Lumina source tree with the GPL license (poppler library), and also lets lumina-pdf be something different than all the “other” poppler-based PDF viewers out there.

  • lumina-mediaplayer
    Simple media player for local audio/video files as well as support for streaming music from the “Pandora” online radio service (using the pianobar utility). All the Pandora streaming support is finished and seems to be working quite well, but I still need to finish up the local file playlist functionality. (Basically, I finally got fed up with how lousy the pithos pandora streaming app is, and decided to implement a replacement in Qt5 so that I can continue to listen to music while I work…)


Will lumina-mediaplayer be replacing vlc? if so great. First thing I do is uninstall VLC and use mpv for everything on each fresh install.


Thanks for such a thorough response.

Great news on the upcoming release of 1.3.0 and the aim to provide weekly updates.

Curious to hear more about the mediaplayer such as will it support for dvds etc.
Will it have any plugin support so that users can extend it to support new services/codecs so that licensing is at the plugin maintainers discretion? A plugin system also allows users to keep it as light or as feature laden as they desire.

Hopefully I’ll find time to contribute to the GB translations pre-1.3.0 release (I was responsible for a lot of the translations that happened just prior to 1.0.0 :slight_smile: )


lumina-mediaplayer is not designed as a full replacement for VLC. I would still consider VLC to be the standard for multimedia applications, and lumina-mediaplayer will be nowhere near ready to replace a full-featured utility like that.

I am taking lumina-mediaplayer in a slightly different direction, in that it will be used primarily for multimedia streams (with the local file playlist stuff as the “base” functionality so there is always something it can do). Pandora radio was the first stream I wanted to get implemented, but there are tons of other types of streaming formats/services which would be nice to support as well (“” for example). I do not have any plans for adding optical media support into lumina-mediaplayer right now (that is a huge mess of pitfalls and special situations) - so VLC will continue to be installed/recommended for things like that.


out of curiosity, why vlc over mpv?

so lumina-mediaplayer is more for internet radio then?


Why use vlc instead of mpv?
Well, there are a few reasons I guess…

  1. I am more familiar with VLC and all the functionality of it - so I and the other TrueOS devs tend to prefer it.
  2. The latest VLC[1] is based on Qt5 (just like the rest of the TrueOS/Lumina tools), and pulls in a lot fewer dependencies than mpv[2] (FYI: I really hate the perl programming language too, although that was not a factor in this particular decision)
  3. Since mpv relies on a lot of X11 libraries and such, I fully expect that it will no longer work once we start trying to roll a version of TrueOS which is using Wayland…

As you can see, nothing particularly special about the decision, so by all means you are free to switch from VLC to mpv as you like - just because TrueOS pre-installs a particular application does not mean that you are forced to use it - feel free to replace apps with alternate ones on your particular system… :slight_smile:



Thanks for the info, that makes a lot of sense.


Well, by popular demand (and a bunch of co-workers harassing me about it) I just posted a “Developer Preview” for Lumina 1.3.0 on the website:


FYI: TrueOS will be getting these new themes with the next round of package updates (before 1.3.0 is released) - just another bonus for all of you… :slight_smile:


I hit the heart like a thousand times, but it just kept canceling the previous one. I guess I can only do one heart, but if I could give more this post would have got a thousand hearts.


you could buy the trueos devs pizza for lunch one day. :innocent:


I could… Tell me what kind of toppings and what kind of crust you guys want on your Pizzas, and hopefully there is a pizzahut near you guys that I can order from (with a credit card) and send them your way. :smiley:


Just have to ask about lumina-pdf and lumina-mediaplayer.

I can’t get it why you people seem to insist to reinvent the wheel?
There are tons of great open source PDF-viewers like e.g. Okular and as you your self stated VLC is a great mediaplayer that can handle almost all media formats. The only format it can’t handle AFAIK is mid, but I guess most people can live without that.

Why not concentrate all resources on fixing the limping TrueOS and its base FreeBSD 12 and make the system flawless?

As I can read out from the posts in this discourse there are a lot of bugs in it, last I read it knocked out NVIDIA. So it seems that I’ve made a good decision to await and not install it over my fully functional PC-BSD 10.3 installation, specially since I use it as my primary system and it would be really bad if I lost data in it.

Otherwise, what’s the next.step? That you’ll develop a Lumina Office suit? I use Okular, VLC, LibreOffice etc. several times every day and it’s great programs and I and I think most others don’t need any alternatives to it. So I don’t really understand this developing-mania. Or is it just because you can?

BTW, I gave up on the ASUS I had and sent it back to the shop and got a refund since I didn’t think anymore it would run with TrueOS ever, at least not with the present development rate. Correct me if I’m wrong, but I think TrueOS have been around for almost a year now, haven’t it?

I still believe FreeBSD/PC-BSD/TrueOS is way better than any Linux distribution, but I really would like everything to work again as in the good old PC-BSD days :slight_smile:
I remember everybody was excited for PC-BSD 11, but then somebody came up with the “brilliant idea” to trash PC-BSD and put all efforts on the new untested TrueOS.

I’m sure TrueOS will be great when it eventually works, but what in the meantime?

It’s like if GM would close all its factories and say: “We came up with this fantastic idea to develop a flying car. Well, it’s not ready yet, but you can use the cars you have in the meantime, but we don’t ship any spare parts since we have put all our resources on the new flyer as well as a new fantastic car stereo since we think that Pioneer, Clarion etc. needs a competitor.” :rolling_eyes:

I’m sorry if I sound rude, but I just don’t understand this :thinking:


I think you are starting with a fundamental misunderstanding of how software flows with time. Let me point out some of the underlying principals of software development and then discuss how these impact Lumina/TrueOS afterward.

  1. No project is an island
    Every single project needs/uses some other external utility, library, communications format, standards compliance, etc in order to be useful. This is especially true with graphical applications, since they need to utilize the current: display system (X11/Wayland), audio system (OSS, ALSA, PulseAudio, SNDIO, etc), and more.

  2. A static project is typically a dead project.
    Even if a project has no considerable changes to it’s codebase or feature set, it still needs regular upkeep and maintenance to ensure that it continues to build/run with the current ecosystem of libraries and utilities (because the entire ecosystem is always moving forward - stop too long and your project will no longer build/run).

  3. “Upstream” decisions can have drastic consequences on your project.
    From no fault of your own - your project can be rendered obsolete/broken by changing standards in the global ecosystem and how they effect your project’s dependecies. Case-in-point, the audio subsystem “wars”. ALSA vs PulseAudio is the fight that people are more familiar with (ALSA lost), but do you remember the “JACK” audio system? That one lost in a big way to ALSA (even though Jack was/is better at low-latency functionality), and nearly all development/support for Jack has disappeared in the meantime. This means that all those audio recording/mixing utilities which used Jack have been rendered “in-operable” by an upstream decision.

  4. Operating system focus is key
    What OS is the project originally designed for? This determines what the “upstream” dependencies will look like and which “heartbeat” you should monitor at all times. For Linux-based utilities like Okular/Firefox, this means that the only audio subsystem to be supported is PulseAudio (even if we have OSS on FreeBSD which works 10,000x better), the only OS-subsystems which are used are based around SystemD/DBUS. For FreeBSD/TrueOS this presents a massive challenge to continue to support Okular/Firefox since those applications are essentially incompatible with the subsystems used on our OS (it takes a lot of work/time to “port” those apps over to work with FreeBSD - and this often introduces bugs and other issues as well).

With these principals in mind - lets look at the Lumina/TrueOS/PC-BSD projects.

PC-BSD) This was designed/based around KDE on FreeBSD. KDE/Plasma5 has been available for Linux OS’s for well over a year now, but we still do not have it available on FreeBSD yet (it is still in the experimental “area51” repository where people are trying to get it working first).
What about KDE4 on FreeBSD? This runs into principal #2 above - it is basically a dead project (replaced by version 5) and is continuing to accumulate security vulnerabilities (hald anyone?), OS-incompatibilities (gotten your screenlocker working yet?), and is relying on other dead projects for critical functionality (policykit/consolekit - both replaced by systemd on Linux). For PC-BSD 10.x we tried to mitigate a lot of the changes in KDE by making our OS-configuration utilities DE-agnostic, but that only gave us a short reprieve from the underlying decay and started to result in a “split-brain” framework where our (functional) tools were available at the same time as the DE’s disfunctional tools.

As a developer with PC-BSD for a long time (and involved with testing it from nearly the beginning), I was keenly aware of the “winds of change” that were blowing in the open-source ecosystem (especially in the desktop-environment subsystem, way back before systemd was even announced) and so I started working on a FreeBSD-based desktop environment which did not rely on all these Linux-based subsystems and frameworks so that we could ensure a FreeBSD-based desktop OS would outlast these other Linux-based desktop implementations which were having their fundamental frameworks ripped-out from under them and replaced so frequently.

All of these ecosystem changes finally came to a head for us near the beginning of 2016. We could see KDE4 really starting to deteriorate out from under us, we could see that FreeBSD’s “Release” branch would never allow us to compete with the rate of graphics driver/standard changes that were coming out of the Linux camp. We started rolling monthly “snapshots” of PC-BSD based on FreeBSD’s “Current” branch (ostensibly in preparation for FreeBSD 11.0) and quickly discovered that the “rolling” release model for the monthly snapshots was solving a lot of our longstanding issues with PC-BSD. We had newer drivers. We had bugfixes in a timely manner. We had a single “supported version” of our project which made better use of our limited developer hours. The list goes on. At the same time, we started switching over to Lumina instead of KDE by default and discovered that everything we had been working towards started “clicking” together. The interface was stable. There was only a single set of OS-configuration utilities. The number of “upstream” bugs from the Linux camp which affected us dropped considerably. Was Lumina as “finished” as KDE? - definitely not - but we could tackle the critical issues one at a time and ensure that once something was fixed it was fixed for good.

With all of these changes (and the lack of a clear “upgrade” path from PC-BSD to the new systems), we decided that we needed to change the project itself (name and all). That was the only way to ensure that people were aware of the differences, and that TrueOS really was a different kind of project from PC-BSD. Note that this was not a “hostile takeover” of the PC-BSD project by rabid FreeBSD fanatics. This was a simply a rebranding/refocus of the PC-BSD project into something that could ensure longevity and reliability for the forseeable future.

Does TrueOS have some problems? Of couse! That is the nature of “rolling” with upstream changes all the time - not only do you always get the latest version of something (a good thing), you also find yourself on the “front-line” for finding/reporting bugs in those same applications (a bad thing if you like consistency). What you are also being exposed to is just how much “churn” is really going on in the open-source ecosystem at any given time (although I do think the churn is a bit more aggressive right now than normal). Because the changeover to a rolling model was still not that long ago, we are still adjusting to some of these new realities and working on implementing contingency frameworks and/or automated QA tests to help mitigate some of the churn - but it takes time.

So just bear with us right now. We are devoted to a stable/reliable/secure experience for our users (and ourselves - don’t forget that we also use TrueOS every single day) - and you can be assured that we will continue striving toward this goal in the best way possible - not just for the moment, but also for the long-term future of the project.

Now for the Lumina “desktop-utilities”: These small utilities are developed for a few reasons:

  1. Missing functionality in TrueOS.
    Sometimes, we just cannot find an open-source application which fits the criteria for inclusion into the TrueOS base install, but the functionality it considered critical and must be filled. The Insight file manager (lumina-fm) and lumina-archiver are two good examples of tools developed to “fill a hole” in TrueOS.

  2. Future-proofing TrueOS.
    Sometimes a utility that we have been using for a long time starts losing functionality, or the upstream project starts expecting more dependencies that are either not available on FreeBSD and/or bring along a ton of other garbage dependencies for the ride. If we cannot find an alternate replacement for this utility (see #1) then it comes down to us to write a replacement.
    Note that this process will sometimes be started quite a while in advance of the current app completely breaking. We try to be proactive and anticipate the way development trends are going for any utility that we tend to rely on for TrueOS, so that when the time comes we are not left with glaring holes in our project.
    lumina-pdf is a utility that falls into this camp. okular might work for now, but we don’t anticipate that lasting for very much longer. While qpdfviewer is a valid replacement for okular, when we start looking at the move to Wayland down the road we see that even that utility will become unfunctional. Since the Wayland transformation is still a ways off though - we are fine with putting lumina-pdf on the backburner for now (but at least the majority of the interface/functionality is already done).

  3. Developer “Fun Time”.
    As a developer it is very useful to take a small bit of extra time (usually on my days off or when I only have a small timeslot where nothing is scheduled) to just do something different. This provides a “playground” (so to speak) to take a step back and re-think an application, experiment with new libraries/features, and generally learn/grow as a developer. If one of these projects turns into something useful, then we will devote a bit more “official” time to it to polish it up and release it - but not everything makes the cut.
    lumina-mediaplayer is a utility that would fall under this category. It started out as a weekend/hobby project to replace pithos as my normal Pandora radio application (after I got fed up with how fragile Pithos is with regards to LibreSSL versions, GNOME3 integrations, etc…) and has gradually become something useful to more people than just myself. The local-file playback functionality within it is really just to provide a baseline level of functionality for the user if they don’t want/use Pandora radio, and fills a niche as a “fallback” utility in case somebody really doesn’t need the breadth of functionality that VLC or another “full featured” media player provides.

Bleh - I just realized I wrote a small book here… sorry for abusing your eyes like that. :wink:

I will finish up mentioning that if you have additional questions about anything I talked about here, feel free to open up a new thread here on discourse about it or similar. While TrueOS is technically a “benevolent oligarchy” - we really don’t try to keep secrets about our reasons for development decisions and such. More often than not, if you just ask we will gladly answer any questions.

Upstream packages will start breaking? - The future of TrueOS

Item 3, Developer Fun Time. That is more important than most people realize. It’s similar to “why climb a mountain”, there’s an itch to scratch, a technique or tool kit you want to learn, you don’t like existing alternatives. It’s just writing code, mostly “because we can”.

Licensing and “stuff pulled in” is a bigger concern than a lot of folks realize. Grep around for how much stuff is pulled in with KDE.


Regarding the “benevolent monarchy” concerns:

I think that it’s a huge failing of the wider open source ecosystem to brand design, vision and direction as some sort of boys club or cabal.

Projects live or die on direction, and the lack of it is what causes many of the problems with linux. Direction in the BSDS and TrueOS is one of my largest draws to them. I know what I’m getting into – the promises have inertia, and if I choose to contribute, I know that it won’t be invalidated as soon as Mark or Lennart or whoever else decides to pivot on a whim.

Linux is an ecosystem designed by committee to the point of lacking design. It’s toxic to people who want to do things right, because doing things how everyone else is doing them is a prerequisite of operating in the environment, engendered by copyleft and ideological activism.

At least you (The TrueOS Devs) have the freedom to be right (or wrong) in your own way.


Yep - that is why we decided to go with a “core team” model (benevolent oligarchy) for TrueOS. It keeps the project a bit more secure from random accidents (car crash, etc), as well as provides a larger pool for innovation/direction without going the “group-think” way and stagnating.


Just read the latest blog entry from April 21’st (today). It’s sound interesting, but what came to mind on the next stable update is this:

We’ve removed Firefox and Thunderbird from the default desktop installation. These have been replaced with Qupzilla and Trojita. Note you can replace Qupzilla and Trojita with Firefox and Thunderbird via the SysAdm Appcafe after completing the TrueOS install.

Probably no big deal, but what will happen by updating from an already installed version? Will that remove Firefox and Thunderbird so you have to reinstall them again?