I am seeing lots of interest and questions about Lumina since it was mentioned in the PC-BSD weekly update last week, so I am just going to try and answer some of the big questions that I have been seeing.
(1) What is Lumina?
Answer: Lumina is a lightweight, BSD licensed, standards-compliant desktop environment based upon Qt and Fluxbox. It is being developed on PC-BSD, and is being packaged for distribution on the PC-BSD package repository as well (although I believe the FreeBSD port is going to be submitted to the FreeBSD ports tree by the PC-BSD project as well).
(2) How complete is it?
Answer: It is currently alpha version 0.1, so lots of things are still unfinished. It has full backend XDG-compliance through the “lumina-open” utility for launching applications or opening files/URLs, but the graphical interface is still being fleshed out. It also has a plugin framework for toolbars, toolbar plugins, and desktop plugins already written, even though there is not many plugins written to actually use yet.
(3) Since it is an alpha, is it usable?
Answer: Yes, if you are used to very minimalistic desktops. I would currently label it a step above pure Fluxbox for usability, since it uses the XDG compatibility to provide access to system applications and desktop files, and is tied in to xdg-open on PC-BSD so that individual applications can open files/URLs using the current system default for that type of file/URL. The main thing is that the interface is extremely bare at the moment (no desktop icons/plugins yet), so you just end up with a background and toolbar(s). It is also still missing some configuration utilities, so you might be stuck with the current defaults for the moment.
(4) Why create a new desktop environment? Whats wrong with KDE/GNOME/XFCE/<other>?
Answer: There are many reasons for needing a new desktop environment instead of using the existing ones, mainly because all the major existing DE’s are developed on/for Linux, not BSD. This causes all sorts of problems on BSD, and I am going to try and list a few of the big ones here:
(4-a) Porting time
Since the DE’s are written on/for linux, they have to be ported over to BSD, and this introduces a (sometimes significant) time-delay before updated versions are available (GNOME 3 anyone?).
(4-b) Porting quality
It takes quite a bit of time/effort to port a DE over to BSD, and I have to give lots of thanks to the people who volunteer their time and energy to make them available. The problem is that quite often “linuxisms” still bleed through the porting process and cause system instability, desktop/X crashes, and loss of usability on the part of the user. This is particularly true when you start looking at KDE/GNOME/XFCE because of the large number of individual pieces/applications/plugins that have to be checked during the porting process, and it gets quite difficult to check everything while doing the port.
(4-c) Linux development trends
As Linux trends continue to diverge from BSD through reliance on Linux kernel functions or Linux-specific systems/daemons, the porting process over to BSD is going to get even more difficult and take longer to accomplish. This means that if we want to have a reliable/stable desktop on BSD going forward, we have to have one designed specifically for the BSD’s.
(4-d) Linux dependency bloat.
If you look at current DE dependency lists, it is easy to see that when you install a desktop, you might be getting a lot more than you bargained for (such as additional compilers/programming languages, network libraries/daemons, audio/video daemons/applications, etc). While there might be some debate on this, my opinion is that it comes from the Linux distro mentality. Just as a Linux distribution is the Linux kernel + the distro’s favorite packages, the desktop environment is becoming the graphical interface for the system + all the favorite applications/libraries of the developers, whether or not they are actually necessary for satisfying the actual purpose of a desktop environment.
I feel like the approach on BSD is quite different because the OS is a complete entity, independent of the packages that get added later, and simply provides the framework for the user to do whatever they want with system. By this same approach, a desktop environment should simply provide the graphical framework/interface for the user to easily interact with the system, independent of what applications are actually installed on the system. Now, I understand that at this point in time a user expects that certain types of applications are expected to be available out-of-box (such as a file manager, audio/video player, pdf viewer, text editor, photo viewer, etc..), but is that really the realm of the DE to decide what the defaults are, or should it be left to the distributor of the OS? I think a point can be made that the file manager is considered essential to integrate with the DE appropriately, but I think that things like audio/video applications, text editors, pdf viewers and such are really up to the preferences of the distributor, not the DE. The DE just needs to provide a simple framework to setup those initial default applications for the distributor, not require a ton of additional applications by default. Because of this, I am taking the approach that Lumina will have a very limited number of applications included by default (there are only about 2–3 that I can think of, all written from scratch for Lumina), and will try to include basic user-level functionality within these few applications to try and cover 90% of standard user needs (at a basic level) without any additional dependencies. For example, the Lumina file manager will have basic audio/video playing and image viewing capabilities built-in because those types of abilities are available through the Qt framework without many/any additional dependencies.
(5) What kind of graphical appearance are you planning for Lumina?
Answer: Highly configurable…
By default, I am planning for Lumina to have a single toolbar on the top of the primary screen with the following item (from left to right): UserButton, DesktopBar, TaskManager, SystemTray, and Clock. This toolbar can be configured as the user desires (or completely removed), and other toolbars can also be added as well (only two per screen at the moment, one on top and one on bottom).
I do *not* plan on having the desktop be covered with the traditional desktop icons (that is taken care of with the DesktopBar toolbar plugin). Instead, it is simply a graphical canvas for the user to place all sorts of desktop plugins (directory viewers, picture viewers, notepads, application launchers, and other “stuff”). I have not decided on any default desktop plugins yet, simply because I have not written any yet.
(6) What is the “User Button”?
Answer: This is what would correspond to the “Start” button on other desktops. This provides a central place for the user to do things like launch an application, open up one of their directories, configure their desktop settings, or close down their desktop session. Basically, an easy way for the user to interface with the system.
(7) What is the “Desktop Bar”?
Answer: This is a toolbar plugin that takes the place of the traditional system of desktop icons. The original purpose of desktop icons was to provide quick shortcuts for the user to open applications or put links to commonly-used files/directories, but quickly became abused with people putting everything on the desktop — destroying the intended purpose of the desktop by forcing the user to spend a lot of time trying to find the particular item they need in the chaos that became the desktop (I am sure you have all seen this many times). The desktop bar takes the original purpose of the desktop, and refines it to provide the quick access the user needs even if there is tons of “stuff” in the ~/Desktop folder. It does this by an intelligent system of sorting/categorization, splitting up the desktop items into three main categories: application shortcuts, directories, and files. Each of these three categories gets it’s own button on the toolbar with items sorted alphabetically (if there is anything in that category), so that it is easily accessed by the user at any time, even if you have the desktop covered with open windows, or you have a lot of that type of item. Additionally, it also separates out the actual files in the desktop folder by type: audio files, video files, pictures, and “other”. This should also help people find “that one file” that they need with a minimum of effort.
(8) Is Lumina the new default desktop for PC-BSD?
Answer: NO!!! While Lumina is now available on the PC-BSD package repository, it is by no means the new default desktop.
(9) Will it become the default desktop for PC-BSD eventually?
Answer: Possibly, it really depends on how well the development on Lumina goes and if the PC-BSD development team decides to make the switch to it at a later date.
(10) Will it become the *only* supported PC-BSD desktop?
Answer: Definitely not!! PC-BSD will continue to support multiple desktop environments and window managers through both the installer and the post-installation package manager.
I hope this help to clear up some of the questions you have!
Kris just posted a call for testers for a new methodology for major system upgrades (such as 9.2 -> 10.0 -> 10.1, etc..) and we are looking for people who are still running 9.2 to try it out. The full text of the call for testers is at the bottom of the post, but to give a bit of background we have been generally unimpressed with the reliability of the “standard” FreeBSD update tools (freebsd-update and pkg) when it comes to fetching uncorrupted update files through the internet. This new methodology takes those two utilities out of the general preparations for an update (download/verification of files), as well as a couple other upgrade steps so that there should no longer be an issue with starting an upgrade when only some of the upgrade files were actually retrieved successfully.
Please test it out and let us know how it goes!
Remember, always backup your data before doing any major upgrade like this! The new methodology should automatically create a boot environment for you before doing the upgrade, but better safe than sorry!
Here is the full text of request from Kris to the developer mailing list:
I've just finished up some work on a major re-write of our updating system when "upgrading" between major releases, I.E. 9.2 -> 10.0, 10.0 -> 10.1. https://github.com/pcbsd/pcbsd/commit/b95e8a83c73511568ae4291a54e0f93f6c67ef30 https://github.com/pcbsd/pcbsd/commit/9a8b3d1945fa67db8e99b0e4e82280b5626aa895 It seems to work well here, but it needs some additional testing from any users still running 9.2 who want to update to 10. To test this, first grab the latest from git: # git clone https://github.com/pcbsd/pcbsd.git pcbsd # cd pcbsd/src-sh/pc-updatemanager # make install Then run: # pc-updatemanager install fbsd-10.0-RELEASE This should start the download / upgrade process. If anything fails during the process, logs are kept in /root, which will assist me in debugging. Thanks!
Hey everyone, I just wanted to let you know that the recent issues with package updates should be corrected with the new package set that just came out.
The graphical package manager will not be able to update to the new package set, instead you will need to run the following command manually:
sudo pkg upgrade
If this fails because of a package conflict, you will need to remove the offending package before trying the upgrade again. For instance, a number of user’s have had to run this command first:
sudo pkg remove –f py27-distribute-0.6.35
Once you have updated to the new package set, the graphical package utility will work perfectly fine again (since it got updated itself).
General background on the problem:
With the update of the new FreeBSD package utility (pkg) from 1.1.x ->1.2.x, there were a number of errors due to a bunch of backwards compatibility being missing in the new version. This meant that once you updated to the newer version you no longer had access to the packages on the PC-BSD repository (due to the changes in the repo format). Since our new 1.2.x packages were just released on the PC-BSD repo, you should now be able to continue changing your packages again. Another issue that came with 1.2.x was that a number of the utility flags all got changed suddenly — causing our graphical utility to need updating as well. We got that utility updated fairly quickly, but the updated package was in the new 1.2.x format — meaning that you have to use the command line to perform this one upgrade.
We are terribly sorry for the inconvenience. Please let us know here or on the forums if you run into any other issues.
Calling all creative PC-BSD users! The developers at PC-BSD would like your help in designing a brand new theme for the PCDM login manager. The winning entry will see their own customized skin as the default theme in the next official release of PC-BSD! In addition, we would like to present the winner and runner-ups with these awesome prizes:
1st Prize: A PC-BSD Isotope T-shirt, PC-BSD stickers, BSD wristbands, plus misc FreeBSD swag items.(Total ARV: $40)
Honorable mentions: PC-BSD schwag package (ARV: $15)
Contest start:11:00am PST on June 19th, 2013
Contest end:11:00am PST on July 8th, 2013
Please submit your entries in an email to the PC-BSD developers mailing list along with your email contact information. The format we require is a *.tar.gz archive containing all the image files as well as *.theme file. Please title the subject heading “Entry for PCDM Theme Contest” in order to be considered.
A sample theme can be found on the PC-BSD GitHub account, with additional information about PCDM theming available on the PC-BSD wiki. General icons should be 128 pixels square or smaller, with background images large enough to be automatically scaled/trimmed to the appropriate screen resolution where possible (for sample purposes consider 1024x768 to be the smallest supported screen resolution).
Have fun everyone, and good luck!
Standard disclaimers apply. iXsystems and PC-BSD team members are encouraged to submit entries, but will not be eligible for prizes. Void where prohibited.
Greetings! With EasyPBI 2.0 now available in the FreeBSD ports tree and as a PBI in the AppCafe, I was asked to highlight some of the new features in EasyPBI 2.0, and why you should want to start using it now.
The first new feature that comes to mind is relatively minor, but saves a fair amount of time if you use EasyPBI with any regularity. This is the ability to check when the last time you updated your system ports tree was, and to use portsnap (or svn if appropriate) to update it to the current version. This is easily available from the “System → Get FreeBSD Ports” menu option.
The second new feature is more of a significant overhaul rather than a brand new feature, and that is making the module editor a complete front-end to editing PBI modules. Previously, the editor allowed the user to view and change the most common options for PBI’s, and trying to use smart defaults for the rest. Now, while still recommending smart defaults, it makes all the settings and options for the module available to the user. The is extremely useful for loading modules from other people, as you can now see everything that the module has inside it, with nothing being “hidden” from EasyPBI inside any of the configuration files. This is easily shown with the new “Scripts” tab in the module editor that lets you read through or edit any custom installation scripts that might be in the module. Another example of this is the new functionality in the “XDG Entries” tab that lets you view/edit any of the desktop/menu entries without having to guess what is inside based upon the file name as with the previous versions. Oh, EasyPBI is also able to set up MIME type file associations for menu entries now, making that whole process very simple and no longer requiring that the user know how to write XML files for the different MIME types.
The last new feature that I want to highlight is one that will not be used very often, but has some very powerful possibilities associated with it. This feature is the ability to package non-port programs in the PBI format. What this option does is basically shift the burden of compiling the program and all its dependencies onto the user instead of using the FreeBSD ports framework. To make this work, the user will first have to setup a directory on his system in the exact format that he wants it to have inside the PBI (with lib/ bin/ share/ etc/ sub-directories as appropriate), as if the program got installed into this directory instead of on the base system. Once that is ready, you can then point EasyPBI at that directory, give it a version number and other program information, then have it all be packaged up as a PBI. This will require a bit more “advanced” usage since you will have to setup external-links and desktop/menu entries for the application yourself (since EasyPBI relies on the FreeBSD ports framework for recommendations), but this ability has a lot of very powerful implications. For instance, it should now allow program developers who wish to distribute special closed-source versions of their software to still make use of the PBI format for simple installations and consistent runtime dependencies by their clients. While this next example was not what the PBI format was originally designed for, I could also see this also being used by device manufacturers to release additional closed-source drivers or FreeBSD kernel modules for their devices. This would provide a simple way to distribute and install these drivers without requiring the system users to have extensive knowledge of the FreeBSD system structure or go through the pain of compiling and loading kernel modules on their own.
These are just some of the new features of EasyPBI 2.0 that I think users will appreciate the most. If you have some “killer” feature that you would like to see in the upcoming versions of EasyPBI, please let me know! I can be found on the PC-BSD PBI developers mailing list, or you can send me an email directly.
 ken (at) pcbsd (dot) org
There are a large number of new games available for PC-BSD 9.0, spanning game types such as action, arcade, card, educational, strategy, online RPG, puzzle, first person shooter, and party games. As mentioned with the desktop utilities, the PBI’s for these games should work in all the desktop environments available with PC-BSD, not just the one(s) mentioned in the game description.
Some of the new games are (in alphabetical order):
AfternoonStalker, AlienArena, Amoebax, Atomix, Barrage, Bomns, Briquolo, BrainParty, BubBros, Burgerspace, Chromium-BSU, Cosmosmash, Crimson, Cuyo, DJgame2, Dopewars, EasySok, Enigma, FreeDink, Gbrainy, GCompris, Gno3DTet, GnomeBreakout, GnomeChess, GnomeKiss, GnomeMemoryBlocks, GnomerMind, GNUDoku, GTetrinet, GtkTetcolor, gTuring, Gweled, Hedgewars, Hexalate, Instead, Kanatest, KDEGames4, Klavaro, KFreeRings, kMancala, KPicFramer, Kpictorial, KPuzzle, KSudoku, KTritoc, KWappen, LBreakout2, Legends, LianLianKan, LMarbles, LordsAWar, LucidLife, MonkeyBubble, MonsterMasher, MudMagic, nPush, OpenCity, OpenYahtzee, Peg-E, Pink-Pony, Pioneers, Pipewalker, Plee-The-Bear, PokerTH, PPRacer, py-Mnemosyne, py-Pychess, QNetWalk, Six, SuperTux, SolarWolf, TaxiPilot, TEG, Tetzle, TheManaWorld, Toppler, Trackballs, TuxType, WarMUX, Xpuyopuyo, XQF, Zaz
Thanks to Jesse Smith for many of these PBI modules.