DistroWatch Weekly, Issue 582, 27 October 2014

Feature Story (by Jesse Smith)

Initial Impressions of GhostBSD 4.0



The GhostBSD project is a desktop oriented operating system which uses FreeBSD as a base. The project's website sums up GhostBSD by saying, " GhostBSD is built on top of the FreeBSD project. However, being a GTK desktop oriented OS, GhostBSD takes the FreeBSD system and pre-configures the most common software choices, fine-tunes the selection of applications for optimal performance, and provides an intuitive work environment without the need for extensive additional configuration. "



GhostBSD 4.0 is available in just one edition as of the time of writing and this edition ships with the MATE desktop environment. I found GhostBSD is available in 32-bit and 64-bit builds for the x86 hardware architecture and the project offers separate downloads for people using optical media and USB thumb drives. I chose to download the 64-bit build for USB drives and found the image file was 1.2GB in size.



Booting from the GhostBSD media brings us to the MATE desktop. The background is a soft shade of blue and the theme features bright icons and dark borders. On the desktop is an icon for launching the project's system installer. Shortly after logging in a window appears offering to switch our desktop to one of three different layouts. The available options are Classic, Enlightenment or Purity. Clicking these options alters the layout of the MATE desktop, moving the application menu, task switcher and optional quick-launch bar. The window that allows us to change the desktop's layout stays open after we make our selection and we can experiment with the three layouts as long as we like.







GhostBSD 4.0 - adjusting MATE desktop settings

(full image size: 166kB, screen resolution 1280x1024 pixels)



GhostBSD's graphical system installer appears to be unique to the project. The application starts by asking us to select our preferred language from a short list of European languages. We are then asked to select our keyboard's layout from a list and then we are asked to find our time zone in another list. Next, we come to disk partitioning and we are given the choice of manually dividing up our hard drive or handing over the entire drive to GhostBSD. The first time through I tried manual partitioning. I found the installer's partition manager a bit awkward and I was unable to find a way to re-size partitions. I also found it strange that a deleted partition would result in a block of free space that could not be reclaimed. There is a guided option on the manual partitioning screen that will make suggestions for us.



The first time through I created a root partition and swap space. When I attempted to proceed the installer claimed I had not created a root partition, though one was displayed on the screen. I took the guided option next which created almost an identical arrangement and moved to the next stage. I feel it worth mentioning GhostBSD's installer does not support ZFS, though the underlying FreeBSD operating system does. GhostBSD only supports UFS and extended features of UFS. The installer then asks us to set a password on the root account and we have the option of installing a boot loader. We are next asked to create a user account for ourselves. The system installer then begins copying its files to the local hard drive. The first time I went through the installer it failed, though the reason the installation process failed was not clear. I went back through the installer, this time giving it access to my entire hard drive and the installation completed cleanly. Once the installer finishes its work we are asked to reboot the computer.



GhostBSD boots to a graphical login screen with an attractive, wavy blue background. Signing into the account we created at install time brings us back to the MATE desktop in whichever layout we selected for it while we were using the live media. Or at least that is what happened when I ran GhostBSD in VirtualBox. I tried getting GhostBSD to run on my desktop computer and, when working directly with the physical hardware, GhostBSD would not boot. Even when asked to run in safe mode GhostBSD wouldn't start on my desktop machine.



In the virtual environment GhostBSD would boot, but I found the operating system wouldn't take full advantage of my display's resolution, even with VirtualBox's guest add-ons in place. This was in interesting contrast to PC-BSD 10.0.3 which I installed a few weeks previous to this trial. While I had to select an alternative video driver for PC-BSD, the operating system would run on this same hardware. On the other hand, while PC-BSD consumed a great deal of my host operating system's CPU cycles while running inside VirtualBox, I found GhostBSD required very little of my CPU's resources when it was run as a VirtualBox guest. I also found GhostBSD required relatively little memory, using just 160MB of active memory when logged into the MATE desktop environment.



GhostBSD ships with a small, but useful collection of desktop applications. We can find the Firefox web browser in the application menu along with the XChat IRC client, the Pidgin instant messaging software, the Thunderbird e-mail client and the Transmission bittorrent software. The LibreOffice productivity suite is installed for us along with an image viewer, a document viewer and the Shotwell photo manager. GhostBSD features the Cheese webcam utility and the Xfburn optical disc burning software. I found MPlayer was available for playing videos and the Exaile audio player is included too. GhostBSD ships with popular multimedia codecs, allowing us to play most media files out of the box. There is, however, no Flash support by default. Digging through the application menu further we find an archive manager, calculator, text editor and system monitor. The Midnight Commander file manager is installed for us too. Network Manager is included with GhostBSD and the operating system includes the FreeBSD 10.0 kernel and command line utilities.



GhostBSD uses the pkg command line package manager for updating software and for installing or removing packages. GhostBSD pulls software from the FreeBSD package repositories. Adding or removing packages worked well for me, but I ran into trouble when it came time to upgrade existing packages. Shortly after I installed GhostBSD I found 219 upgrades waiting in the repositories and these totalled 411MB in size. The package manager downloaded and installed these items for me without any problems, but when I rebooted the machine, I was dropped at a text console login screen. I was no longer able to launch the X display software and I could not get back to a graphical login screen. After trying to boot in safe graphics mode and trying to manually correct the problem with X I re-installed GhostBSD. The operating system worked well for me again until I performed another software update a few days later. Once again, installing updates disabled X, reducing GhostBSD to a command line only operating system.



Conclusions



Going into this review I truly wanted to like GhostBSD. I like what they are trying to do and I appreciate the idea of providing the world with an easy, home user, desktop oriented flavour of FreeBSD. While PC-BSD aims at businesses and workstations more than home users and PC-BSD is exclusive to 64-bit machines and offers every desktop environment under the sun, I feel there is a place for a streamlined, one-desktop, lightweight operating system built on the foundation of FreeBSD. GhostBSD is working with a good idea and strives to fill a niche that is mostly uncontested these days.



Unfortunately, I ran into several problems with this release of GhostBSD. The installer gave me some problems when I tried to manually partition my disk and I ran into some errors when I didn't take the automated partitioning option. Like PC-BSD, the GhostBSD operating system had trouble working with my video card. Unlike PC-BSD, I found GhostBSD didn't have an easy work around and that meant I spent all my time with the operating system running it in a virtual machine. To top it off, upgrading the operating system caused the graphical user interface to stop working, which was a frustrating turn of events.







GhostBSD 4.0 - running the Midnight Commander file manager

(full image size: 157kB, screen resolution 1280x1024 pixels)



There are aspects of GhostBSD I did enjoy. I like that the project is still supporting both 64-bit and 32-bit machines and I like the developers make it easy to transfer their images to both optical media and USB thumb drives. I appreciate the streamlined system installer, even if I did run into some problems with it. I like that the MATE desktop has a small helper problem that will let us change the layout so MATE can be easily customized to suit the user.



I suspect most of my problems with GhostBSD boil down to problems with video drivers, particularly where my desktop computer is concerned. Hopefully, people with different hardware will enjoy a better experience than I did. Lately I've heard a lot of people taking an interest in FreeBSD-based operating systems and I like to think GhostBSD could be a good fit for people who want to get up and running with a FreeBSD desktop system with as little effort as possible.



* * * * * Hardware used in this review



My physical test equipment for this review was a desktop HP Pavilon p6 Series with the following specifications Processor: Dual-core 2.8 GHz AMD A4-3420 APU

Storage: 500 GB Hitachi hard drive

Memory: 6 GB of RAM

Networking: Realtek RTL8111 wired network card

Display: AMD Radeon HD 6410D video card

Miscellaneous News (by Jesse Smith and Ladislav Bodnar)

Switching to openSUSE from another distro, Tumbleweed and Factory merge, road to Unity 8, Ubuntu celebrates 10th birthday, Debian says good-bye to valued team member



Hack Week is a time for developers to share ideas and propose interesting, strange or useful projects. One interesting idea to come out of SUSE's Hack Week this year is a project which attempts to take an existing installation of a distribution which uses the RPM package manager and convert that distribution into a functional openSUSE installation. The project's page explains: " A number of experiments suggest that it may be feasible to run zypper from an openSUSE 'live' media against a 'foreign' RPM based OS installation (eg. CentOS) and then 'zypper dup' to openSUSE. Thanks to satsolver, openSUSE's heavy use of pkgconfig, and our sometimes 'excessive' recommends, zypper always seems able to suggest a viable upgrade solution, replacing the foreign CentOS/RHEL packages with appropriate openSUSE ones. " If successful, the project would make it easier for curious users to switch to openSUSE without losing their existing applications and configuration.



Back in August we reported openSUSE's Factory repository was being turned into an official rolling release distribution. This caused some confusion among openSUSE users as the openSUSE Tumbleweed repositories were already being used by many as a rolling release platform. The project has decided to merge its Tumbleweed and Factory branches to make one rolling release repository. The official, unified rolling release branch will be called Tumbleweed while the name Factory will be used to identify a repository of development packages. The announcement reads: " With the release of openSUSE 13.2 in November, two of openSUSE's open-source projects, the 'Tumbleweed' and 'Factory' rolling releases will be merging, and offered as a single openSUSE rolling release under the name 'Tumbleweed'. Factory will remain the name of the development process where openSUSE's new developments are integrated, with the tested, user-ready rolling release assuming the name Tumbleweed from November 4. * * * * * Canonical, the company behind the Ubuntu distribution, is working on a new version of the Unity desktop, Unity 8. While the current Unity interface, Unity 7, is designed for desktops, the new Unity 8 interface is expected to run on phones, tablets, laptops and desktops. Unity 8 has a long development cycle ahead of it and, while it is available for testing, Canonical currently doesn't plan to push out Unity 8 to desktop users until October 2015. Will Cooke, the Desktop Team Manager at Canonical, reports: " What we've decided to do this time is to keep the same, stable Unity 7 desktop as the default while we offer users who want to opt-in to Unity 8 an option to use that desktop. As development continues the Unity 8 desktop will get better and better. It will benefit from a lot of the advances which have come about through the development of the phone OS and will benefit from continual improvements as the releases happen. "



Along with the new version of Unity, Canonical plans to provide application isolation and a separation between operating system versions and application versions. Cooke explains: " Traditionally a given release of Ubuntu has shipped with the versions of the applications available at the time of release. Important updates and security fixes are back-ported to older releases where required, but generally you had to wait for the next release to get the latest and greatest set of applications. The new desktop packaging system means that application developers can push updates out when they are ready and the user can benefit right away. Application isolation: Traditionally applications can access anything the user can access; photos, documents, hardware devices, etc. On other platforms this has led to data being stolen or rendered otherwise unusable. Isolation means that without explicit permission any Click packaged application is prevented from accessing data you don't want it to access. "



The Ubuntu operating system, along with its related community distributions, is probably the most widely used GNU/Linux operating system in the world. When Ubuntu appeared on the scene ten years ago it immediately began raising the bar for ease of use and newcomer friendliness. Canonical started a free live CD program where people all around the world could order and give away Ubuntu discs and this did a lot to promote desktop Linux and expose new people to free software. Last week Ubuntu celebrated its tenth birthday and Scott James Remnant, one of the project's first team members, takes a walk down memory lane: " The surprising thing to me now, looking back, is how modest our goals were and how lofty they seemed at the time. Our goal was to be one of the top three Linux distributions after two years. I don't remember Ubuntu ever leaving the #1 spot for the duration that I worked on it. I don't think any of us really realized how popular Ubuntu was at first, since heads were back down working on fixing all the problems of 4.10 and getting 5.04 out of the door a ridiculously short six months later - the first hurdle being merging all of our changes with those made in Debian again. "



To conclude the roundup of the Ubuntu news last week, here is the announcement about the project's next release, as published on Mark Shuttleworth's blog, written in typical mysterious, humorous and language-twisting fashion by the explorer of the cosmos: " This verbose tract is a venial vanity, a chance to vector verbal vibes, a map of verdant hills to be climbed in months ahead. Amongst those peaks I expect we’ll find new ways to bring secure, free and fabulous opportunities for both developers and users. This is a time when every electronic thing can be an Internet thing, and that’s a chance for us to bring our platform, with its security and its long term support, to a vast and important field. In a world where almost any device can be smart, and also subverted, our shared efforts to make trusted and trustworthy systems might find fertile ground. So our goal this next cycle is to show the way past a simple Internet of things, to a world of Internet things-you-can-trust. In my favourite places, the smartest thing around is a particular kind of monkey. Vexatious at times, volant and vogie at others, a vervet gets in anywhere and delights in teasing cats and dogs alike. As the upstart monkey in this business I can think of no better mascot. And so let’s launch our vicenary cycle, our verist varlet, the Vivid Vervet! "



* * * * * It comes a decade too late, but it is finally here - the ridiculous "Microsoft tax" is finally gone - at least if you are lucky enough to live in Italy: " The Italian Supreme Court (Corte di Cassazione) issued a judgment1 that bans the 'Microsoft tax', a commercial practice that discourages users from converting their PCs to GNU/Linux or other free operating systems by forcing them to pay for a Windows license with their PCs. PC producers in Italy now cannot refuse to refund the price of the license to purchasers that will not run Windows. The ruling definitively concludes the case filed in 2005 against a hardware producer by Marco Pieraccioli,2 with the support of the Consumer Association ADUC,3 and affirms Marco Pieraccioli's right to a refund for the price of the Microsoft Windows license. " Of course, it's hardly surprising that it took more than a decade to grant a consumer the right to choose his/her operating system. Nevertheless, it's a victory, albeit a small one - maybe some Italian readers can tell us if anything has really changed in their local computer shops. Still, it's great to see that some countries do understand our frustrations. (Editor's comment: in all my years of travelling around the globe, I've only ever seen ONE instance where a computer shop offered the same hardware with different operating systems (Linux and Windows) side by side. It was in a small computer shop in Brunei. Given the hardware prices today, the Linux system was, surprise, surprise, substantially cheaper. Never mind the "freedom" part of the deal....)



* * * * * Finally, we are sorry to share some sad news this week. The Debian project learned recently that contributor Peter Miller passed away earlier this year. Mr Miller had long been a contributor to open source, working on various free software projects for over twenty years. The Debian website reports: " Peter Miller died on July 27th after a long battle with leukemia. Peter was a relative newcomer to the Debian project, but his contributions to Free and Open Source Software go back the late 1980s. Peter was significant contributor to GNU gettext as well as being the main upstream author and maintainer of other projects that ship as part of Debian, including, but not limited to srecord, aegis and cook. Peter was also the author of the paper "Recursive Make Considered Harmful". The Debian Project honours his good work and strong dedication to Debian and Free Software. Peter's contributions will not be forgotten, and the high standards of his work will continue to serve as an inspiration to others. "





Questions and Answers (by Jesse Smith)

Debian, systemd and forks



In the past we have touched on the systemd init technology. The systemd project is an attempt to revolutionize the way Linux starts up and manages services. In theory, systemd allows computers to get up and running faster and the technology offers some new methods for controlling system services. The project doesn't stop there though, systemd has also expanded to add binary logging, a userland text console and several other features. Some people see systemd as a unifying force that will reduce distribution fragmentation while decreasing boot times. Others see systemd as a project that is expanding unnecessarily outside of its scope while reducing flexibility and transparency.



Until the start of 2014 most of the Linux distributions that had adopted systemd as their default init technology had been relatively cutting edge projects. It was natural to see Fedora, always an early adopter of open source software, embrace systemd. Arch Linux, being a cutting edge distribution, also adopted systemd quickly. It was a little surprising to see Debian, a famously conservative distribution, vote to adopt systemd earlier this year. Fans of the Debian project usually prefer tried and true technologies to the latest and greatest. Fans of Debian are often also fans of choice. Debian claims to be the "universal operating system" and its many branches, architectures and ports speak to people who value flexibility. Last week we talked about a proposal to keep choice alive in the Debian project by enabling users to select their preferred init technology when setting up Debian. The proposal suggests systemd may remain the default init system, but administrators should be able to swap out systemd for another init technology.



But what happens if Debian not only adopts systemd, but also insists on making systemd a dependency, one which cannot be easily removed? Some people will adapt, learn the new init technology and continue on using Debian. Others have expressed an interest in migrating to more conservative projects. Another group has suggested Debian should be forked if systemd becomes a fixed part of the Debian GNU/Linux operating system. The Veteran Unix Admins (VUA) group has declared that they like Debian, want to continue using Debian and they hope systemd will remain a removable option. However, if systemd is here to stay, the VUA has declared their intention to fork Debian.



I had a chance to exchange e-mails with one of the VUA members and here is what they had to say about Debian, systemd and a potential fork of the project.



DW: Would this be a complete fork of the distribution with entirely separate repositories? Or would you mostly use Debian's existing repositories and just fork the low level components relating to start-up/init? VUA: We are still evaluating the possibilities and analyzing dependencies of systemd and related components (d-bus for instance) to understand the span of this fork, which we still hope won't be necessary.



The majority of us involved in this early phase see it as a fork taking distance from Debian repositories, cutting down on packages maintained and eventually optimizing the governance model thanks to the fact we will start smaller.

DW: How many contributors does this potential fork have? VUA: VUA is a group counting little less than 1,000 subscribers on private fora, obviously the VUA is a group counting little less than 1,000 subscribers on private fora, obviously the debianfork.org initiative doesn't involve all of us. We are receiving an overwhelming quantity of e-mails with offers to help, about half of them are by people that seem to know well the issues at stake and to be well capable to give a hand.

DW: Popular projects like Debian need a lot of storage space, code repositories, mirrors, etc. How can people help with providing hardware/mirrors/donations? What resources do you have already? VUA: Many of us are senior IT professionals and also considering our targets are sysadmins, infrastructure shouldn't be a problem. Of course we will not start big, but grow as needed. Having said that, this would be a challenging adventure for many reasons and we still hope it won't be necessary.

DW: Your website mentions the people involved in this potential fork do not have time to get involved with Debian's governance. What sort of governing body will the fork have? VUA: It will be a governing body that puts the benefits of the users first, not the mystification of a "doacracy" delivering all the power to the package maintainers.



Originally, Debian was created as a universal operating system for the users. The Free Software movement itself is there to defend users' rights. Sgryphon explains it well in



We will likely reproduce the governing body of Debian to follow its original mandate, with the advantage of starting small and more focused, hopefully with less pressure from the interest of commercial developers. It will be a governing body that puts the benefits of the users first, not the mystification of a "doacracy" delivering all the power to the package maintainers.Originally, Debian was created as a universal operating system for the users. The Free Software movement itself is there to defend users' rights. Sgryphon explains it well in this thread We will likely reproduce the governing body of Debian to follow its original mandate, with the advantage of starting small and more focused, hopefully with less pressure from the interest of commercial developers.

DW: If Debian is forked, how long do you think it will take before we see a stable release of the fork? VUA: Those that could be in need of a fork are in such a situation because they need well known and tested technology on production servers and cannot face such a big overhaul as a dist-upgrade to a systemd based Debian 8, also considering the quantity of customization on top of sysvinit that in many cases has to be dealt with. It is foreseeable that the majority of people in such a situation will likely rely on the long term support of Debian 7 even if a sysvinit updated fork is available.



The stable release of the fork should be in place at least as an installer alternative to Debian 8 and available in the same period: it should be an environment familiar to sysvinit Debian users who are doing a fresh install.

DW: Thank you and good luck.



* * * * * When we talk about systemd one of the advantages often mentioned with regards to the new init technology is that it is fast. In the Debian debate two key points were raised in systemd's favour: systemd makes the boot process much simpler.

systemd is incredibly fast. It was not designed with speed in mind, but doing things correctly avoids all the delays currently incurred by the boot process. The Fedora project mentions boot times too as an advantage of systemd, stating: " Note that in the long run systemd will provide quicker boot up. "



I've always found this argument interesting as I try out a different distribution every week and, to date, had not noticed a big gap in boot times between projects running SysV, Upstart and systemd init. After getting into yet another discussion about systemd recently I decided to experiment a little for myself to see what would happen if a person swapped out systemd for SysV init, leaving everything else the same. As our discussion this week concerns Debian, I decided to use Debian to test these two init systems.



First, I created an installation of Debian Jessie and booted it up a few times. My timer showed that, putting aside a brief pause at the boot menu, Debian running with systemd on my test system consistently took exactly 30 seconds to boot to the login screen. I then removed systemd and installed SysV init using the following commands: apt-get remove --purge systemd libpam-systemd systemd-sysv

apt-get install sysvinit sysvinit-core sysvinit-utils I then booted Debian again, without making any further configuration changes. When booting using SysV init my test machine consistently brought me to the login screen in exactly 30 seconds.



Fans of systemd will correctly point out my test isn't entirely fair. After all, I'm forcing systemd to use SysV init scripts rather than native systemd configuration files. I suspect systemd will be able to bring Debian up faster once Debian developers put new configuration files in place. However, the purpose of my test was not to find out which init technology is faster in theory or in the future. I am interested in the practical differences here, today. Strictly looking at start-up times and the practical aspects of managing services, SysV init and systemd are identical on my system running Debian.



Which I feel raises the question of how systemd performs on a distribution which ships with native systemd configuration files. Arch Linux adopted systemd quite early and, at this time, the start-up process has been switched over from SysV scripts to systemd configuration files. Arch is well known for having a clean and simple configuration where nothing unnecessary will get in the way. I happened to have a copy of an Arch ISO sitting around from my rolling release trial and so I wiped Debian Jessie and installed Arch. I set up Arch to have a fairly minimal feature set, with just a desktop environment and booted the distribution a few times. Arch, with systemd running a native systemd configuration, consistently booted in 40 seconds, 10 seconds slower than Debian running SysV init.



Obviously distributions are complex creations and your results may vary from one computer or distribution to another. However, based on my tests so far it appears as though systemd does not offer better performance than SysV init.



Have another test you would like me to run, comparing systemd and SysV init? Drop me an e-mail and put "systemd vs sysv trial" in the subject line.





Rolling-release trial (by Jesse Smith)

Rolling release testing - week 3



I am now in the third week of my trial with rolling release operating systems. The first two weeks were interesting and a few minor issues crept into my experiences. However, all three operating systems continue to function and my updating and testing processes have slipped into a rhythm.



Before getting into my experiences with running and updating my installation of rolling releases this week, I'd like to acknowledge the wonderful support and feedback I have received with regards to this trial. Several readers contacted me via e-mail or followed this experiment on Twitter and it's been great hearing suggestions and getting into discussions regarding this test. One aspect of this trial I especially wanted feedback on was the tests I should apply to each distribution after an update. Some people suggested testing wi-fi connectivity, 3-D video driver support and other hardware related activities. Unfortunately, to level the playing field and to save me from rebooting my test machine frequently, I installed these test distributions in virtual machines. This means testing hardware related features, such as 3-D video and wi-fi, aren't really practical. However, I did take the suggestion of testing multimedia support and added it to my list of tests. I also plan to list the version numbers of some key components, including the kernel, X, KDE, Firefox and LibreOffice.



Many people messaged me to suggest adding more distributions to the trial. Due to my limited time, this trial will remain fixed at five operating systems (Arch, Debian, openSUSE, PCLinuxOS and PC-BSD). That being said, many people suggested rolling releases or development branches of popular distributions and I think these would be interesting experiments. I am seriously considering running another rolling release trial next year. So, please keep your suggestions in mind and when I do another experiment like this I will run a poll ahead of time where people can vote for their favourite distributions.



Next, I appreciate people providing feedback on this experiment and other articles here, in the comments section. I like that it can get discussions going and spread available information. That being said, if you want to make sure I receive your suggestions, please also send me an e-mail at jessefrgsmith@yahoo.ca. I sometimes miss comments directed at me and don't always have time later in the week to check back. Thank you.



* * * * * This week Debian, PC-BSD and PCLinuxOS all had entirely smooth upgrades, which is always nice to experience. All three of these operating systems also come with multimedia support enabled by default which meant I did not need to add any extra packages in order to test multimedia applications. Of these three projects, Debian shipped the most updates last week and I upgraded 164 packages, totalling 123 MB in size. The PCLinuxOS distribution provided me with 32 packages, which came to 60 MB in size. The PC-BSD package manager indicated no new software upgrades were made available this past week.



* * * * * The openSUSE project provided me with plenty of new packages this past week. At first I tried to upgrade packages using the YaST graphical front end. Unfortunately when I asked to begin downloading the software upgrades, the YaST update module crashed. I next turned to the zypper command line package manager. Using zypper I was able to upgrade the waiting 83 packages which required 155 MB of my bandwidth.



Adding multimedia support to openSUSE Factory turned out to be a challenge. The openSUSE distribution does not ship with multimedia support by default and attempting to play an audio or video file brings up a window that offers to hunt down the codecs for us. However, multimedia codecs are not in the default repositories either and this automated search fails. When this happens openSUSE provides us with a link to documentation on enabling third-party support for codecs. Here I ran into another problem. The documentation claims that we can simply click a button and have this extra repository added to our system, the documentation specifically claims openSUSE Factory is supported. When I clicked the button to add the extra repository YaST reported the repository did not match the local distribution's version number and could not be used. I tried to manually add third-party community repositories through YaST, but none of the ones supported contained multimedia codecs. I determined that, short of bypassing YaST and configuring zypper's repositories via the command line I would have to consider multimedia not supported by openSUSE Factory.



Further on the topic of openSUSE, I mentioned during my initial week with the distribution that openSUSE does not support booting into Btrfs snapshots from the GRUB boot menu. One reader wrote to me to report they are also running openSUSE Factory and can, in fact, boot into old Btrfs snapshots, effectively rolling back their operating system in case it breaks. I double-checked and my installation does not include this feature. Perhaps this is because the snapper utility was not properly configured when I installed openSUSE. I checked the documentation for Btrfs snapshots and it says, at the time of writing: " The bootloader on openSUSE currently does not support booting from a Btrfs partition. " So some people may have found a way to enable booting into Btrfs snapshots, but it seems the feature is not officially supported.



* * * * * Arch Linux was the last distribution to get updated this week. I installed 55 new packages, totalling 140 MB, using the pacman package manager. These updates applied smoothly and there were no problems. I feel it is worth noting, for other users, Arch posted a notice letting people know the latest Java update requires manual attention. Something to keep in mind if you are running Arch.



When I checked multimedia support on Arch I found mp3 audio files played out of the box. Video files did not and so I added video codecs and a video player. During this time I found just how quickly Arch updates sometimes. The video player package could not be found at first and I determined that was because my local package database had fallen out of date just two days after my latest upgrade. Refreshing the package database allowed me to download a video player. Incidentally, I transferred media files to my test systems using the OpenSSH secure file transfer software. Arch Linux was the only operating system in my trial which did not ship with OpenSSH installed by default.



* * * * * Below I have included the version numbers for some key packages on each operating system. I think it is worth noting PC-BSD uses the FreeBSD kernel, not the Linux kernel, which is why its version information is so different. I feel it is also worth mentioning different distributions report the versions of X differently. I suspect this is due to the way X is packaged, where components and general releases can be assigned different version numbers. For now I am including the version number of the X server (or the Xorg server "core" package, where applicable) rather than the release version of the Xorg meta package or other sub-components. (I am open to suggestions on how to maintain version number consistency with X across all distributions.) For that matter, each operating system uses different package names and different parts of X or KDE can ship with different version numbers.



This means there can be some variance between reported version numbers depending on which package we check. As an example, KDE's runtime package may report a different version than the KDE Dolphin package. The Xorg-server-core package may report a different version than Xorg-server. Each distribution bundles and names their software differently so it is difficult to make a true apples-to-apples comparison of version numbers. Finally, package versions can vary a little between what is reported by the package manager and by the application itself due to versioning conventions. In short, do not invest in version numbers, they may not reflect accurately on the status of the software and they do not give insight into what patches have been backported from upstream releases.



Package versions



Package Arch Debian Sid openSUSE PCLinuxOS PC-BSD Kernel 3.16.4 3.16.2 3.16.3 3.15.9 10.0-RELEASE-p17 X Server 1.16.1 1.16.1 1.16.1 1.14.6 1.12.4 KDE 4.14.1 4.14.1 4.14.1 4.13.3 4.12.5 LibreOffice 4.3.2.2 4.3.2.2 4.3.1.2 4.3.0.4 4.2.5.2 Firefox 32.0.3 31.1.0 32.0.2 32.0.3 32.0.3



Released Last Week

Upcoming Releases and Announcements

DistroWatch.com News