BSDCan Trip Report: Michael Dexter

The next trip report is from Michael Dexter:

BSDCan 2014 was an amazing experience as always but one theme characterized this year more than any other: Coordination.

Never in my dozen years in the community have I seen such an active dialog between the BSD projects with attention being given to what each project is up to. From praise to constructive criticism, developers from all of the projects engaged each other in sessions and in the priceless hallway track. Beginning with a project that is close to my heart, Peter Grehan announced at the FreeBSD DevSummit that the bhyve hypervisor would soon support NetBSD, rounding out its support for OpenBSD, NetBSD and Linux virtual machines. I can think of no better way for developers to see first hand how each operating system works and to cross-validate code. Kudos to Peter, Neel Natu, John Baldwin and everyone else who has helped bhyve become such a useful feature in FreeBSD.

Continuing in the spirit of coordination, Abhishek Gupta of Microsoft's Hyper-V group was on hand to discuss with developers how to guarantee that FreeBSD is a first-class Hyper-V guest OS. From the sound of it, Microsoft appears to have more developers focusing on FreeBSD than Intel! Together, bhyve and Hyper-V represent compelling OS-native hypervisors and rest assured, Windows virtual machine support in bhyve is under active development.

Matt Ahrens of the OpenZFS project gave his annual update on what new ZFS features are making their way into FreeBSD in order to keep FreeBSD a first-class ZFS platform. Of these features, ZFS "bookmarks" will enable ZFS replication without relying on snapshots as a unit of history. Just how quickly the OpenZFS project transitioned from post-Sun Microsystems confusion to solid, OS-agnostic contributions is remarkable. We all owe Matt our gratitude for his active participation in the BSD community at events like BSDCan and AsiaBSDCon.

Other DevSummit highlights included a clarification of FreeBSD's "long term support" policy with the comforting recognition that the project had in fact been more or less adhering to the proposed 5-year policy. A formal affirmation of such a policy is a valuable marketing tool for everyone from vendors to end users. The idea was also raised about separating the FreeBSD base into packages to allow for modular updating and deployment. Done right, this could be of great value to embedded FreeBSD efforts.

Two notable highlights of the FreeBSD Doc Sprints were the participation of Ingo Schwarze of the mandoc project who committed FreeBSD's Igor documentation proofing tool to OpenBSD ports, and Allan Jude's formal entrance into the FreeBSD project with a documentation commit bit. Allan and Kris Moore have done a great job raising awareness of FreeBSD and other BSD projects with the BSDNow podcast and are demonstrating just how seamless community and code participation can be.

Though many of us were already exhausted from all-day discussions and late-night coding, it was finally time for the conference proper to begin. This saw an infusion of yet more wonderful people and continued engagement and coding. Security was a key topic this with the FreeBSD Address-space layout randomization (ASLR), Capsicum and LibreSSL talks standing out as must-see. Each talk was highly cross-pollinated by developers from different BSD projects with almost a sense of obligation to the Internet community as a whole, given BSD's key role in the development of the Internet.

The Embedded track comprised of ARM, MIPS64 and NAND flash storage talks and was also very timely given the changing nature of computing. Warner Losh went into great detail about how NAND flash storage works and how broad a range of reliability is available from the various flash technologies. This track even extended to a lunch time MIPS router hacking BOF lead by Sean Bruno. It is great that we have real Unix on really-affordable hardware.

The closing auction was fun as always and the clouds broke on Sunday, allowing quite a few attendees to walk around Ottawa and Parliament before heading home. Some brave systems administrators opted to take the first BSD Certification Group BSD Professional exam and the feedback I heard was very positive. The BSD Professional exam is a hands-on exam designed to compliment the BSD Associate exam that the BSDCG has offered for several years. This is an exciting development and is testament to the continued growth of the BSD community.

I would like to thank Dan and his team for putting on another great BSDCan and the FreeBSD Foundation for helping me attend this year.

FreeBSD 9.3-BETA1 Available

The first BETA build for the FreeBSD-9.3 release cycle is now available. ISO images for the amd64, i386, ia64, powerpc, powerpc64 and sparc64 architectures are available on most of our FreeBSD mirror sites.

Weekly Feature Digest 30

Hey PC-BSDers!  This week we’ve been gearing up for the next release of PC-BSD version 10.0.2.   In preparation for the next release we have been fine tuning some of the new features and making sure the loose ends are tied up.   We were also able to close out a good amount of trac tickets this week and commit the fixes for 10.0.2.

In other news / updates this week:

AppCafe

  • Fix a bug where the orphan package filter was also filtering out some base apps.
  • Randomize the browser home page so that it only show 10 random “recommended” and “highlighted” applications.
  •  Add a ton more recommended/highlighted applications to the repo file.
  • Fix some minor display bugs
  • Add menu option to view the recent vulnerability information for ports through freshports.
  • Fix the sizing information for installed meta-pkgs (will show the combined sizes of the direct dependencies instead)
  • Fix the sizing information for available applications (will now show the combined size of all the packages that need to be downloaded/installed for that app)

EasyPBI

  •  Add the ability to fetch/read the pkg-plist for a given pkg.
  • Add a “bulk” module creation side to EasyPBI which allows for creating PBI modules for an entire FreeBSD category at a time (with all sorts of filters and options)
  • Make EasyPBI automatically create up to 5 desktop/menu entries for graphical applications.
  • Make the application binaries detected/usable within the module editor for creating new desktop/menu entries.

Lumina

  • Quick fix for filenames that have spaces in them
  • Quick fix for making sure that when launching an app it is in the same general system environment. This allows apps like firefox/thunderbird to see other instances of themselves and act appropriately.
  • lumina-config - Make sure the menu options actually work

Miscellaneous Fixes / improvements

  • Fixed several warden bugs relating to new jail creation / package management
  • Imported the latest ports and Gnome3 / Cinnamon for 10.0.2
  • Fixed some issues prompting for GELI password from GRUB and then mountroot
  • Fixed a critical bug with new CUPS 1.7.0 breaking foomatic-rip and associated print drivers
  • Imported the latest PEFS code into 11-CURRENT and backported it to our 10-STABLE branches
  • Fixed bugs with system update tray notifier not showing freebsd-update” notifications
  • Migrated one of my build systems to 11-CURRENT and got it setup for doing PKG/ISO builds
  • Misc other trac tickets fixed / closed in cleanup process
  • Many other cosmetic / doc bugs fixes as Dru submitted them
  • Started investigating bug with BE/GRUB failing if the first dataset is destroyed

BSDCan Trip Report: Warren Block

BSDCan 2014 was held earlier this month and the Foundation provided travel grants to several committers. The first trip report is from Warren Block of the doceng@ team:

Every year, BSDCan is preceded by a developer summit, where FreeBSD committers and invited guests can get together to discuss proposals, difficulties, and plans.  Registration this year was at the intriguingly-named "Goat BOF".  There are stories behind this, but I'll just point you to https://twitter.com/GroffTheBSDGoat and https://plus.google.com/109575245711252585947/photos.

For the documentation developer summit group, Benedict Reuschling made the case for helping documentation translators from our outdated manual system to using gettext-based PO files.  These systems eliminate much of the manual work translators are forced to do with the current setup, allowing them to concentrate on translating. They also provide "translation memory", remembering phrases and sentences that have already been translated so it is not necessary to retranslate them when they appear in different documents.  The room had been fairly quiet up until Benedict began demonstrating this, at which point there was a loud "oooh!" from the back of the room.  There is still a bit of work to be done to fit these tools into our translator workflow, but the research is mostly done and the rest is just pounding it into a shape that can be used with our existing documents and setting up the first translation team to use it.

Each night, we had a "doc lounge", where people were welcome to come to learn about or work on documentation.  We split up the individual time with a few short presentations.  I showed how I used textproc/igor to proofread documentation changes, and it surprised me at how others were using it, and surprised them at how I was using it.  This in-person communication with a crowd of differing experience and viewpoints is one of the best features of BSDCan.

BSDCan itself began on Friday with a keynote session from Karl Lehenbauer, CTO of FlightAware.  This was one of the best presentations I've yet seen at any BSDCan, and worth the time to watch.   As in previous years, the FOSSLC group was there, making high-quality recordings of the presentations.  Compared to videos taken with a traditional camera, screens in the FOSSLC videos are easy to see and the speakers can be heard.

There were talks aimed at using FreeBSD on embedded hardware, with Warner Losh speaking about using NAND flash memory (apparently no video available, but an associated video is here) and Sean Bruno describing installation of FreeBSD on wireless routers with MIPS processors.

John-Mark Gurney showed how he had improved geli(8) encryption performance from less than 150MB/second to greater than 900MB/second.

Daichi Goto gave a talk called "Shellscripts and Commands", which was an interesting combination of traditional shell-based tools and fast hardware to process huge datasets.

Saturday morning, Ingo Schwarze from the OpenBSD project talked about "New trends in mandoc", the excellent full-text search abilities developed for this OpenBSD replacement for groff(1).  Ingo also attended several of our doc lounge
sessions, and we had some interesting comparisons between the document checking provided by igor and that in mandoc.

Vsevolod Stakhov talked about the new solver in pkg (no video available yet).  What I find particularly encouraging about this and other aspects of the new package system is the amount of research into other systems. That is the "good kind of lazy": the problem is difficult, and rather than jumping in and hacking together a solution that partly works, doing the research to find how other groups have done it.

FreeNAS is becoming increasingly popular, and John Hixson talked about how to add custom applications to it (no video yet).  Later, Fabio Balzano described a FreeBSD-driven ROV (remotely operated vehicle) using a Beaglebone Black ARM single-board computer.

At another doc lounge session, we covered the complete process to fix an error in the FreeBSD documentation, from installing the tools, to editing, checking, and build-testing the document, through to submitting a patch.  It's very good to note that some of the people we worked with have already had patches submitted and accepted since then.

FreeBSD developer Li-Wen Hsu was at several of the doc lounge sessions, and one night asked about integrating igor with the Jenkins continuous improvement framework.  I was skeptical about using igor for this, but we talked about some tests that would avoid false positives.  The next night, he returned.  Not only had he modified igor to produce the required output, he'd already set up a Jenkins test! It showed just how useful this continous automated testing can be, even if the test tool is not perfect.  In hindsight, I should have realized that this sort of thing is just an extended use of automation, which is the point behind igor: we have these nice computers, let's use automation to help us accomplish our goals.

Finally, Allan Jude of BSD Now (and many other FreeBSD-related things) had clearly been in line for a commit bit for some time now.  Benedict had a plan to keep it a secret and surprise him with the announcement during an interview. The full interview will be seen on a future episode of BSD Now.

This was all just a tiny part of BSDCan 2014.  There were numerous other talks that you should watch, like the already-famous one by OpenBSD's Bob Beck on LibreSSL, their fork of OpenSSL: http://www.youtube.co/watch?v=oM6S7FEUfkU, or http://www.youtube.com/watch?v=GnBbhXBDmwU.

All of the FOSSLC videos are here.

All the presentations and informal talks are still just a small part of BSDCan.  There is the "hallway track", where it is common to start talking with another person about something that's important to both of you... and then getting so caught up that you miss a presentation or two.  There are before- and after-hours talks with others on things that seem to have been overlooked, but it turns out were important to them also.  Lots of people you may only know by email address will be there, almost always looking completely unlike imagined.  At one point or another, almost everyone is drafted by Dan Langille to help carry boxes or set up power strips. There's lots of caffeine and more than a little sleep deprivation. Conferences like these help provide the motivation that drives projects throughout the rest of the year.

A big thanks goes to the FreeBSD Foundation for sponsoring my trip this year.  Thanks also to Dru Lavigne, Benedict Reuschling, Allan Jude, Dan Langille, and everyone who came to the developer summit, doc lounge, and BSDCan.  Your time and attention are appreciated.  Thank you all for helping to improve FreeBSD!

bsdtalk241 – Bob Beck

Interview at BSDCan 2014 with Bob Beck from the OpenBSD Project and the OpenBSD Foundation.

File Info: 26Min, 12MB.

Ogg Link: http://cis01.uma.edu/~wbackman/bsdtalk/bsdtalk241.ogg

BSDCam 2014

BSDCam 2014 (http://bsdcam.cl.cam.ac.uk/), University of Cambridge, Cambridge, United Kingdom 9 - 12 July, 2014. The Cambridge FreeBSD Developers Summit is an annual invite-only event focused on bringing together developers and vendors to discuss and build the future of the FreeBSD project. This years topics will include the desired feature set of FreeBSD 11, implementing the new release strategy for the 9 and 10 branches, packaging the base system, and building the infrastructure and tools to attract more embedded vendors to FreeBSD.

Frederic Culot takes over as portmgr-secretary@

It is with great pleasure that the FreeBSD Ports Management Team announces that Frederic (culot@) Culot will take over responsibilities of team secretary effective immediately.

Frederic became a ports committer in October 2010, and joined the ranks of portmgr-lurkers@ in March 2014 as the shadow secretary.

Please drop him a note and congratulate him (or offer condolences).

 

Thomas
on behalf of portmgr@

 

Weekly Feature Digest 29 — PBING

We’ve been seeing a lot of confusion and questions about the PBI changes that were recently pushed out those of you running the Edge package sets, and Ken Moore was nice enough to break the changes down in this week’s PC-BSD weekly digest.

First, a little history about the PBI system.
It was initially created when the only/primary application distribution method for FreeBSD was the ports system — meaning that any FreeBSD user who wanted frequent updates to their applications needed to manually compile/install any application through the FreeBSD ports tree on a fairly regular schedule. The PBI system was designed as an alternative to provide simple application packages that could easily be downloaded and installed without the need for the user to compile any source code at all. As an added benefit, the PBI system installed these applications into a seperate container on the system — leaving all the “complicated” system configuration and integration to still be run through the FreeBSD ports system. This allowed PC-BSD to have a stable base system for a release (because the base system packages would almost never get touched/updated), while at the same time provide the ability to keep the main end-user applications up to date between releases.

Now fast-forward a bit to the PC-BSD 10 series.
At this time the FreeBSD ports system, while still existing for the “hardcore” users, has mainly been replaced by the pkgng distribution system for general system/application usage. This has provided quite a bit of confusion for PC-BSD users, because they now had two different ways to install applications, and each application on the system would behave differently depending on how that particular application was installed. To make the distibution model simpler for PC-BSD, the PBI files were already being created from pkgng packages (ensuring that there was a lot less compiling done on the build servers), and those packages were simply being collected into “fat files” with a few compatibility scripts and such thrown in for good measure.This meant that there was a lot of duplication between the pkg and PBI systems, resulting in a lot of effort to maintain compatibility between the two systems. The main problem however, was that the special PBI runtime container itself was causing all sorts of system stability issues. Since the release of PC-BSD 10.0 we have actually tried 3 or 4 different types of application runtime containers, each of which was designed to solve a critical flaw in the previous version, but always kept running into large limitations/problems with each new type of container.

At this point we decided to take a step back and refocus on what the PBI system was originally intended to do — provide a “Push Button Installer” to install and run applications while keeping things as simple as possible for the end user. With this definition for the PBI system, it makes perfect sense that the pkgng system should be chosen  as our default application installation method for a couple reasons:
1) Integration with the system environment for things like setting up and running default applications works a lot better (mimetype integration/use).
2) Startup/runtime speed. Applications installed to the base system simply startup and run a lot faster than the ones that are installed into the containers.
3) User Confusion. Lots of people simply did not understand that the “contained” application libraries/files were not installed to the normal location on the system, and that an application in a container could not easily see or use the system-installed applications.

The next-generation PBI system.
This re-implementation is designed so that it no longer uses the “PBI Containers” exclusively and instead returns to its original goal — to provide a simple interface for the end user to install/use applications of all types and in all ways. This means that it is now a system that uses the pkgng packages as it’s basis — but provides all sorts of other information/functionality that the pkgng system does not fully support yet (such as mimetype integration, desktop/menu entries, and graphical information like icons for applications). Additionally, it also provides a number of enhancements to how the user can utilize the different pkgng packages, mainly through how the packages get installed.

1) Standard pkgng installation to the base system.
This allows the user a simple interface to install/remove application on the base system while providing a number of additional safety checks to prevent random “foot-shooting”.

2) Jail management.
By running the AppCafe on the base system, you can now manage all the applications/packages in any of the running jails on your system. Combined with the Warden for creating/managing different kinds of jails, the user now has a simple way to manage and run applications that (for security reasons) should never be installed/used from the base system (such as web servers or network-facing services).

3) Application containers with plugins!
By using the “portjail” creation options in the Warden, you now have a method to safely contain a graphical application while also allowing for a system of installing/removing optional packages into that jail for plugin support without touching your base system packages (very similar to our previous container system, but with a few more layers of separation between the jail and the system).

4) Other installation methods.
Because the PBI system is now installation-method agnostic (almost), we can provide support for alternate types of installation methods (such as into specialized containers like our previous PBI versions have had). While we do not have any other installation methods included at the moment, we can add new methods relatively easy in the future if those installation methods do not break system stability.

So what does this mean for a PC-BSD user?
1) Access to thousands more applications and plugins by default through the AppCafe. The “PBI” applications will show up with things like screenshots, available plugins, nice looking icons, user ratings/tips, and more while you also have the ability to install and use the “raw packages” (which will always have the icon of a box/package) even if the nicer recommendations and information is not available for that raw package.

2) Less confusion about application installations. Since applications will always be installed/integrated into the local system by default, this will prevent a lot of confusion in people who are used to the standard FreeBSD/Linux/Unix installation methods and file locations for applications.

3) Greater flexibility for different installation methods to suite your specific needs. System installation, traditional jail installation, portjail installation, additional future types of installations, it give the user freedom to truly run the system as you need, rather than forcing you to use a particular system that might not be what you were looking for.

Weekly Feature Digest 28 — Photos of the new AppCafe re-design.

Hey everyone just a quick update tonight as much of the work has been the same as last week :).   I’ve uploaded a couple of pics to show how the new AppCafe integration with pkgng will look.  In the first picture below you’ll see a similar looking app information screen with some sweet new features.  The biggest thing you might notice right away is the 5 star rating system in the top left corner under “Firefox”.  In the new AppCafe clicking the stars will immediately pop-up the app’s wiki page allowing you to rate the program.  We are also looking into the ability to add comments as well that will also populate into AppCafe.  Also many programs (especially GUI based applications) will have screenshots in AppCafe to allow you to check them out before you download them to your system.

Notice below right this is the main “installed applications” screen.  Here you’ll be able to view all of your installed apps and also filter them based on a few presets built into AppCafe.   Similar to the package manager, the new AppCafe will pull more information from the package repository about installed packages for you to review.

Important Correction:  I realized after talking with Kris and Ken that I was slightly confused over the new role of pkgng and how it will affect PC-BSD going forward.  pkgng is replacing the PBI system in future versions of PC-BSD and AppCafe.  PBI’s will be immediately  & automatically converted over to use pkgng instead once users update to the next big PC-BSD release.  If you have any further questions we will be glad to answer them for you, and I aplogize for the information discrepancy!

appcafe1       appcafe2

 

 

FreeBSD Foundation Newcons Project Highlight

Spring Fundraising Campaign - Newcons Project Highlight

Our Spring Fundraising Campaign is in full swing, and we couldn't be more grateful for all your support! We are honored to be the stewards of your donations for the FreeBSD Project and community. Around half of our funding goes towards project development to help keep FreeBSD an innovative, reliable, and high-performance operating system

During our Spring Fundraising Campaign, we are highlighting the projects we are funding to show our commitment to helping FreeBSD. Please take a moment to read about the Newcons project.

What is the Newcons project?
The Newcons project provides a replacement system console for directly-attached displays, keyboards, and mice.  It replaces the legacy syscons driver, sc(4), and is short for “new console.”  Because it won’t be “new” forever and will become just “the console,” it is more correctly known by the name of the device driver, “vt.”

Why does FreeBSD need a new console?
Newcons provides a number of benefits, including support for Unicode and UTF-8, and double-width characters.  This eliminates the historical text-mode limit of 256 characters, and allows for Chinese, Japanese and Korean (CJK) and other character set support on the console.

Without Newcons it’s not possible to switch back to the console after starting the X graphical environment.  Newcons allows this by integrating with Kernel Modesetting (KMS), the method of changing graphics modes used by current display hardware drivers and X.org releases.  This integration also enables high-resolution consoles.

Newcons also provides an improved infrastructure that is not user-facing, but enables simplified support for new hardware.

What work is the Foundation sponsoring?
The Foundation awarded a development grant to Aleksandr Rybalko to implement missing functionality, and finish integration tasks.  Completed tasks include history buffer improvements, kernel mode setting integration, and additional hardware device support.  This work is already available in FreeBSD-CURRENT.

Documentation and performance improvements are the main outstanding tasks; font setting and other user interface features are also in progress.  The “vt” driver is expected to be available in the FreeBSD 10.1 release.


Donate today to help us continue and increase our support of the FreeBSD Project and community worldwide! To make a donation go to: http://www.freebsdfoundation.org/donate/.

Weekly Feature Digest 27 — Software System Redesign

PC-BSD has long been very flexible about how you can install software. You have PBI’s, packages, and ports available with just a couple clicks or via a couple of simple terminal commands. For a long time the PBI format has served as an excellent solution for people who may need an offline package install, or just simply prefer the ease and simplicity the PBI format has to offer especially via the AppCafe. Perhaps the “Achilles’ Heel” of this situation is that we have also been severely limited on the amount of software that the AppCafe has to offer as packages had to first be converted into the PBI format.

This week we are announcing a radical change that we think will benefit all PC-BSD users in ways that were previously unthinkable. The PC-BSD team has begun work during the last couple of weeks redesigning our PC-BSD utilities (AppCafe, Update Center) to work with our pkgng software repository that we are currently building to contain detailed information about all the software available through packages and PBIs. What this means for you is that in the near future PC-BSD will have a much broader software pool to pull from, and will not be limited anymore by only having a small subset of PBI’s. You will now be able to install packages and PBI’s in one place, while also being able to update and manage both in one place.

You may be asking yourself “why the change?”. Over the last several months we have noticed a considerable amount of our time has been going into compatibility and fixes for PBIs. So much time in fact that other important development had to be postponed and / or sidelined while we worked on bringing PBIs up to speed. We are hoping by adopting appcafe and the PBI format to work in tandem with pkgng, that we will be able to refocus our efforts on other important endeavours.

We will have more information available soon as development continues on how you can get involved with testing out the new features and submitting ideas to help the project along. Let us know what you think about the changes. Are we headed in the right direction? Do you have ideas related to the redesign that you’d like to contribute? Let us know!

Key Features:

Much larger software library. Instead of 800 available appcafe applications think more like 10000+
Detailed information on all the software available including packages in one place
Ability to search and filter your results to show
Improved compatibility across desktop environments
New rating system is being developed for grading the quality of packages in the AppCafe library

FreeBSD Foundation Spring Fundraising Campaign – Funding Highlights

Spring Fundraising Campaign - Funding Highlights
As we embark on our 15th year of serving the FreeBSD Project and community, we are proud of what we've done to help FreeBSD become the most innovative, reliable, and high-performance operation system. During our Spring Fundraising Campaign, we are going to highlight where some of our funds are going to show our commitment to helping FreeBSD.

The first project we are highlighting is the UEFI Boot Support. Please take a moment to read about the work going on in this area.

What is UEFI and why is the FreeBSD Foundation sponsoring this work?
UEFI is the Unified Extensible Firmware Interface, a new standard for boot firmware -- the software that runs from the time a computer powers on, until the main operating system is loaded.  It was originally developed for Intel’s “Itanium” CPU many years ago, with x86 and ARM support arriving later. 

Many desktops and servers sold today provide the option to choose between UEFI and legacy BIOS boot modes, but some support only UEFI. UEFI-only systems will become increasingly common in the future, so supporting UEFI boot is a requirement for FreeBSD to remain viable on contemporary hardware.

Why did we need a new boot firmware?
The PC BIOS is over three decades old, and was designed with different goals than are relevant today. It was responsible not only for booting, but for providing runtime services like reading files or printing characters on the screen.  As operating systems evolved from 16-bit code to 32- and 64-bit, the BIOS was relegated to providing only the initial boot functionality, but limitations of 16-bit code from the 1980s persisted.  BIOS boot does not inherently support features like large disks, multiple operating systems, or network booting that are now standard.

These issues have all been worked around with various add-ons, but often in a vendor-specific or inconsistent way.  UEFI replaces the workarounds and layers of complexity with a consistent and powerful set of boot services.

What work is the Foundation sponsoring?
In 2013 the Foundation sponsored Benno Rice to perform some initial investigation and infrastructure work for amd64 UEFI booting, which resulted in a working proof of concept.  Ed Maste later refined that work and brought it to the main FreeBSD development branch, giving FreeBSD-CURRENT the ability to boot via UEFI.

Ed and Foundation staff members Glen Barber and Konstantin Belousov will continue with work to build snapshot images, fix bugs, address hardware compatibility issues.  We’re committed to finishing UEFI boot integration, documentation, and installer support, and appreciate the support of the FreeBSD community’s collaboration on some of these pieces.  Initial UEFI support will appear in the FreeBSD 10.1 release, due later this year.

Donate today to help us continue and increase our support of the FreeBSD Project and community worldwide! To make a donation go to: http://www.freebsdfoundation.org/donate/.

Quick Lumina Desktop FAQ

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!