SouthEast LinuxFest will take place June 20–22 at the Sheraton Charlotte Airport in Charlotte, NC. Registration for this event is free.
There will be a BSD booth in the expo area on both Friday and Saturday from 9:00–17:00. As usual, we’ll be giving out a bunch of cool swag, PC-BSD DVDs, and FreeNAS CDs, as well as accepting donations for the FreeBSD Foundation. Ken Moore will present “PBI v10: Application Management Made Easy” at 13:30 on Friday and Dru Lavigne will present “ZFS 101″ at 13:30 on Saturday. The BSDA certification exam will also be held at 11:00 On Sunday.
PC-BSD 10.0.2-RC2 images are now online for testing from our download site.
This will (hopefully) be our last RC before releasing 10.0.2 officially sometime on or around the 23rd. We have addressed or fixed most tickets related to the 10.0.2 release, so if you are still running into any issues, please report them using our Trac database.
Users running EDGE or earlier 10.0.2 images can upgrade their packages to the RC2 versions via AppCafe or Package Manager.
Thanks for all your help testing, and the issues reported so far!
There will be a BSD booth at Texas LinuxFest to be held June 13 and 14 at the Austin Convention Center in downtown Austin, Texas. Several members of the PC-BSD team will be at the booth and will be giving out cool swag, PC-BSD DVDs, FreeNAS CDs, and accepting donations for the FreeBSD Foundation. Registration for this event is $30 or $60 and the expo area is open on Friday from 12:00–18:00 and on Saturday from 10:00 to 18:00.
The BSDA certification exam will also be available on Friday at 10:00. The cost of the exam is $75.
The next 10.0.2-PRERELEASE ISO is now available for testing and can be downloaded from
If you have a spare system or virtual machine, consider testing this image. If you find any bugs, report them at https://trac.pcbsd.org so we can take a look at fixing them before 10.0.2 is released later this month.
NOTE: if you plan to use AppCafe in this image, go to Configure -> Repository Settings and change it to “Edge”. Do this before attempting to upgrade within AppCafe; otherwise, if you reboot or logout, you will not be able to successfully log back in again.
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:
- 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)
- 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.
- 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
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.