DesktopBSD 1.6 released

After playing and working with DesktopBSD and PC-BSD I have developed a soft spot for both desktop-oriented *BSD’s. Hence, it is good news to see that Desktop 1.6 final has been released. Take a look at the release notes and you will agree that this is an up to date and stable release with a lot to offer to people who are interested in trying *BSD.

You can download three different sets: a dvd iso for i386, a dvd iso for AMD64 and 2 cd iso’s for i386. Try it! It’s one of the best things you can do this early in 2008.

Tags: DesktopBSD

DesktopBSD day 30 – The Verdict

On November 1st I started with this series about DesktopBSD and we are now six weeks later. Six weeks in which I played, wrestled and worked with DesktopBSD almost every day. If there was only one conclusion I was allowed to draw it would be this: after a while I kind of forgot I was working with a FreeBSD-based operating system. Yes, there have been quirks. Yes, there were problems with my hardware but I seem to be one of the few to have those problems, which indicates it can’t be blamed on DesktopBSD. Yes, it took some more time to install new software. But the overall conclusion has to be that I could do everything I needed to do on a day to day basis. Let’s review DesktopBSD with twenty-twenty hindsight.

What is DeskopBSD about?

DesktopBSD started as idea in the heads of two students who were working with FreeBSD every day. The key question could be described as: “What does it take to create a userfriendly open source desktop based on FreeBSD?” The first release of DesktopBSD reached 1.0 status in March 2006 and the team is now working towards the 1.6 version. Their goals is:

DesktopBSD’s main goal is to provide a desktop operating system that’s easy to use, but still has all the functionality and power of BSD. In the long term, DesktopBSD wants to build an operating system that meets most requirements desktop users have, like easy installation of software, configuring power management on mobile devices or sharing an internet connection.

The foundation: FreeBSD

DesktopBSD uses the FreeBSD 6.2-STABLE operating system as it’s foundation. This means that it is completely compatible with FreeBSD and provides maximum access to the packages and ports collection. DesktopBSD adds a graphical installer, a live desktop, the DesktopBSD tools and a pre-configured KDE desktop in order to achieve it’s goal of being more userfriendly.

The live desktop

The DesktopBSD cd provides -when booting from it- the option to either install the operating system or boot into a live desktop. This was one of the first charming features, since it usually takes quite some time to boot a live desktop. I don’t always want to take that route when I know I want to install the operating system. After selecting the live option, DesktopBSD probes the system and tries to configure X. My nVidia N6200 graphics card was detected and the live desktop was booted in a 1280 x 1024 resolution, which is quite good.

From here the desktop is a great showcase. The KDE desktop looks sharp and the system is extremely responsive. The default applications are well-chosen. You can’t fault the decision to select Firefox, Thunderbird and Pidgin as these are well-known applications available for multiple platforms. With Amarok, VLC, K3b and Noatun there is a good basic set of multimedia applications. The only thing liking is a good Office suite. However, the final release for 1.6 will be on dvd and that will include OpenOffice.org.

Easy to install

The graphical installer is the next tool to make a friendly open source desktop. As Peter Hofer said in our interview:

The installation routine is very easy to use and thus probably the most important feature for most desktop users. They don´t want to know about blocks and cylinders, mounts points of network services. Most users just want to get their systems up and running and the DesktopBSD installer does just that. The graphical installer gives the new users a first taste of a fully featured and easy to use FreeBSD system. We believe that once they have experienced this, it makes them more willing to learn to work with it and get to know FreeBSD.

The installer starts with probing your system in order to determine the proper resolution for the wizard. It suggest a resolution and then asks you for your keyboard layout. The next three steps gather necessary information like whether it is a new installation or an upgrade/recovery, which hard disk you wish to use and whether you need a bootloader or not.

Disk partitioning is again taken care off by selecting the disk and adding partitions and slices. The option “Use entire disk” is the easiest to use of course. There is no option to customize a suggested layout and changing the layout is less friendly than I would have liked.

DesktopBSD now commences by installing itself on your hard drive. After reboot you can add additional language support, the files of which are on the second ISO, as part of the Initital Setup Wizard. You can provide a new name for your system. The next step requires you to set a system password and add a user. This step is broken down in smaller steps, each taken care of in popup windows.

With this the installation routine is almost finished. There is just the matter of allowing your system to report back to bsdstats and to read the introduction to DesktopBSD. It’s only a few screens and for new users highly recommended.

However, this doesn’t complete a full installation. In order to get a complete and working FreeBSD-based desktop you do need the ports collection. Clicking on the icon “Software” launches the Package Manager. The Package Manager is a graphical frontend that takes care of various tasks. When you run it for the first time it explains that it needs the ports collection and requests your permission to download it (portsnap). This takes quite some time. Once this is done, it then tells you it needs to do a check for possible vulnerabilities on the installed packages (portaudit).

The KDE desktop

Playing with DesktopBSD meant another month playing with the KDE desktop as well (after working with PC-BSD the month prior to this series). DesktopBSD delivers a clean and well-looking KDE desktop. It is delivering quality here. Some might be able to find fault with the default icon set, which is more than reminiscent of the Mac OS X and Microsoft Vista icon sets (thanks to the NuoveXT set), but overall it has an air of style, of stability. The desktop could have been somewhat cleaner, but having the various shortcuts to the network, to the documentation, the home folder, the systems menu and to software management at hand is actually a good thing for novice users. Having two menu entries called “Settings” is a bit confusing though.

I have fooled around a few days with the options to change the look and feel of the KDE desktop and liked the flexibility those options provided me. As a software glutton I installed quite a large collection of applications. The GNOME desktop doesn’t allow me half the flexibility to edit the menupanel in order to get some structure as the KDE desktop does.

This didn’t stop me from installing a GNOME desktop on DesktopBSD, of course. Using the Package Manager I was not only succesful in installing GNOME, but it was fuly functional as well. I couldn’t get a working GNOME desktop during the PC-BSD series, but under DesktopBSD it worked out-of-the-box. Yes, it looked horrible but changing the GNOME theme is a matter of downloading the right package.

Still, I used the KDE desktop most of the time and enjoyed it.

The DesktopBSD tools

The fourth additional to your basic FreeBSD-based operating system consists of the DesktopBSD tools. The Package Manager takes care of software management and is a graphical frontend to both the packages and the ports collection. This is one of the places where you can see the DesktopBSD team made the effort to look at the system from an end-user perspective. You are provided with quite a lot of explanation and feedback in the windows that you are using. In a few clear and concise lines you get the proper instructions.

The default settings of Package Manager only allow packages to be installed and not ports. In some cases this results in failed installations. The more experienced user will check Freshports and find out why it couldn’t be installed. Package Manager could use a bit of polish here and provide somewhat more feedback. The settings could be changed in order to select the port when no package is available or when the port is more recent, but that usually results in even lengthier installations. Despite a few quirks here and there I have found Package Manager to be a great tool for software management. There were only a few instances I needed to use the command line #pkg_add -r to get what I wanted. Those few instances do point to one problem I prefer to see ironed out. Sometimes the package manager shows you a more recent package is available, but won’t install it. This appears to be related to the ftp server from DesktopBSD being not completely in sync with the FreeBSD servers.

DesktopBSD also created some smaller tools that you hardly notice when they are there, but which you would miss once they are gone. For instance, it is very useful for a laptop user to see what the status of your battery life is. You wouldn’t want your laptop to go down without a warning. Same thing for providing information about the network you are attached to. It’s one of the things I enable on any Windows desktop I have to work with. I want to see a network icon in my taskbar. Double-clicking the network icon in the panel launches the network manager. Through the network manager you can set up your local network, your wireless connections and your DSL connection.

Two other tools are meant to make life easy for external drives and sticks: Hardware Notifications and Tray Mounter/ Mount Control. The first tool simply reports whether new hardware is attached or detached. The second tool makes it possible to mount or unmount partitions and devices. With Mount Control it becomes a matter of clicking on the right partition entry. When it isn’t mounted it will get mounted and vice versa. It’s so simple you almost forget to appreciate it, but it is much simpler and easier to use than similar tools under Windows and Linux.

Adding, removing and locking users isn’t something most of us do every day. Still, it is nice to have a graphical tool at hand that does the job. With Settings (2) -> Security & Privacy -> User Management you can launch the DesktopBSD specific tool. With a few clicks new users are added. Permissions have been kept simple with only three groups: system administrator, extended device access and user.

The DesktopBSD tools collection might not appear earth-shakingly innovative, but it contains the tools to simplify some key areas of software and systems management. The Package Manager is the most visible tool, but the smaller applets in the panel make day-to-day working with the system easy. They make the difference between a powerful, solid platform and an easy to use open source desktop.

Expanding and working with the system

One of the first things I tested out were the multimedia abilities of DesktopBSD. MP3-files were no problem for Amarok and my collection of AVI-files were handled by VLC. The only problems were with flash-based websites, but that is a known problem with various solutions.

During the month I tried out a collection of applications. I couldn’t test gaming under DesktopBSD due to my hardware problems. I looked a bit deeper into various personal information managers and project management programs. At one point I realized I wasn’t writing about DesktopBSD proper anymore as it had become “simply” the platform for other experiments. DesktopBSD gives a complete access to the 17.000+ software collection for FreeBSD and thus gives a complete freedom to do with your system whatever you like.

Conclusions

This series was started with defining the key requirements for any open source desktop that wants to be a serious contender on the market for end-users, both at home and in organizations. I will repeat them here:

1. the open source desktop needs to a recognizable and easily understandable graphical work environment;
2. the open source desktop should have a complete set of graphical tools for systems- and software management that can be used intuitively;
3. the open source desktop should support multimedia activities and peripheral devices without too much hassle, even if this can only be achieved by a pragmatic approach towards non-free software components;
4. the users of the open source desktop should have access to business-grade professional support if that is desired;
5. maintaining and developing the open source desktop should not be dependent on a single person or a relatively small group of developers and maintainers;
6. migration to the open source desktop will require re-training of end users and some level of real time support during the process. This means that good and accessible documentation should be at hand as well as easy access to end user support;
7. the open source desktop should have a solid track record for quality, stability and solid progress over the last few years.

DesktopBSD easily meets requirements 1, 2, 3 and 7. I know that work has commenced on providing a DesktopBSD handbook that no doubt complements the excellent FreeBSD handbook. When looking at the feedback provided on-screen, the team is really making an effort to provide the user with the information he/she needs at the time of actually using a specific function.

Both the team and the community are quite small. Support for novice users leans heavily on a small group of very active people. At this stage this isn’t such a bad thing, but it will get complicated if and when a new group of novice users without prior experience in BSD starts to use DesktopBSD.

Though -at the time of writing- DesktopBSD is still working towards it’s final version of 1.6, I can only conclude that this is a stable and mature operating system that really lowers the threshold to get started with FreeBSD on the desktop. I am still in doubt whether DesktopBSD has progressed far enough to be accessible for end-users with Windows-only experience right now. Linux users should have little or no problems getting off with DesktopBSD and do whatever they used to do with their Linux desktop. I can only encourage them to do so, as it would expand the user base of DesktopBSD and provide the team with more feedback and assistance to make the final leap. The strong focus on stability for the operating system, the development and maturity of the current set of DesktopBSD tools and the clear and concise on-screen information are solid building blocks for a future DesktopBSD release that will be easy to use for people with Windows-only experience.

Shortcuts to the 30 days with DesktopBSD series

DesktopBSD Day 1 – Getting started (part 1)
DesktopBSD Day 1 – Getting started (part 2)
DesktopBSD Day 2 – First impressions
DesktopBSD Day 3 – Getting started with software management
DesktopBSD Day 4 – Software management snags
DesktopBSD Day 5 – Extending the system
DesktopBSD Day 6 – the live desktop
DesktopBSD Day 7 – Fooling around
DesktopBSD Day 8 – What’s the community like?
DesktopBSD day 9 – Fine tuning the desktop
DesktopBSD day 10 – Customizing the desktop
DesktopBSD Day 11 – Where to go from here?
DesktopBSD day 12 – What are the DesktopBSD Tools?
DesktopBSD day 13 – Installing on a real hard drive
DesktopBSD day 14 – Emulation and virtualization
DesktopBSD day 15 – Getting the GNOME desktop
DesktopBSD day 16 – Setting up my personal information managers
DesktopBSD day 17 – Flock and Freshports
DesktopBSD day 18 – Exploring Kontact
DesktopBSD day 19 – Evolution
DesktopBSD day 20 – Planning and Project Management (I)
DesktopBSD day 21 – Planning and Project Management (II)
DesktopBSD day 22 – Setback
DesktopBSD day 23 – Accessing Network Shares
DesktopBSD day 24 – Removing software
DesktopBSD day 25 – ee, the commandline editor
DesktopBSD day 26 – Printing
DesktopBSD day 27 – Getting spiritual, sort of
DesktopBSD day 28 – Going back and forth
DesktopBSD day 29 – Comparisons

DesktopBSD day 29 – Comparisons

I have tried to avoid comparing my experiences while working with DesktopBSD with PC-BSD or Ubuntu. Today may be a good day to at least do a formal comparison between DesktopBSD and PC-BSD. I guess it can’t be avoided. Two FreeBSD-based open source desktops with similar goals, but finding different solutions.

The similarities between PC-BSD and DesktopBSD are there of course. Both use a graphical installer to assist the new user with getting FreeBSD on his/her system and both have chosen for the KDE desktop. DesktopBSD allows to boot into a live environment before actually dedicating it to your harddrive, while PC-BSD ships with Compiz Fusion.

The default software collections are different as well. DesktopBSD has chosen for Firefox, Thunderbird and Pidgin. A choice that makes sense as these applications are well-known and used on Windows and Linux. PC-BSD seems to stick more to KDE-based programs like Konquerer, Kontact and Konversation. However, these are minor differences.

DesktopBSD sets itself apart through the DesktopBSD tools and particularly the Package Manager. This graphical frontend for the packages and ports collection provides an easy tool for installing, upgrading and managing the software on your system. Working with Package Manager shouldn’t be a problem for Linux users that have experience with similar tools (Synaptic, Adept, Portage).

For PC-BSD the PBI’s are unique. The work on the PBI Build Server is progressing and that will result in a far larger collection of packages. This should contribute to a wider adoption of PC-BSD among people who used to work under Windows, since the PBI system emulates their “double-click-and-install” experience the most.

There is no need to try to figure out which one is better. I just marvel at both developments and I can see they both provide an answer to the needs of different groups of users. I can imagine a future where the DesktopBSD tools are enhanced to allow installing and managing PBI’s for FreeBSD-based systems, even if only for PC-BSD systems.

DesktopBSD day 28 – Going back and forth

After working two months with desktop oriented BSD’s I have more than enough material to write about. A lot of it was written down in the two 30 day series, but -fortunately- it will also end up in some real life publications. In this period I am working on two articles about PC-BSD and DesktopBSD. One article will be published in a new BSD-related magazine and one article is meant for a Dutch computer user group with it’s own bimonthly magazine. Maybe there will also be a third article about both BSD’s.

I reinstalled both DesktopBSD and PC-BSD for the articles and read up on all the material I gathered over the last two months. It was an affirmation that these two BSD’s are solid candidates for the open source desktop and deserve far more attention than they are receiving now. Once I have finished writing the various article I will use all the building blocks to write a book about migrating from Windows and Linux to BSD-based open source desktops. I have no idea whether a publisher is interested in it or not, but there are various ways of publishing. This the Web 2.0 era.

DesktopBSD day 27 – Getting spiritual, sort of.

This 30 day series is nearing it’s end and basically I find myself being able to work with DesktopBSD without a lot of problems. I tend to look more at the available applications and whether they work properly or not. Two applications I keep an eye on are BibleTime and GNOMESword, two programs I use as bible study tools.

Both programs could be installed easily. BibleTime is KDE based and GNOMESword… well, the name is telling. They both use the bible translations and books that are available via de Crosswire download servers. They even share the same folder on the hard drive to access the downloaded materials.

I know choice is a good thing and that KDE-based and GNOME-based applications are programmed differently, but BibleTime and GNOMESword are so similar in use and appearance that I wonder why there have to be two projects. There are some differences, features that are available in one, but lacking in the other. And -no doubt- you can think of many other open source applications in multiple categories that suffer from the same problem: same functionality as other programs, similar look and feel, just a different name.

Anyway, while browsing through the Crosswire directory I found a bible in Klingon. Klingon? Yep, from Star Trek. If someone can take the time to translate the bible into a non-existing, hardly spoken language, then maybe I shouldn’t worry too much about people re-creating similar applications in the open source world after all.

DesktopBSD day 26 – Printing

The advent of computer technology was once accompanied by the vision of the paperless office. When everything would be available digitally, there wouldn’t be any need for paper. ICT boomed, but so did paper consumption. Instead of producing less paper, it became easier to make extra copies or make highly insignificant semantic adjustments in documents “because another printout” wasn’t a problem. Hence the need for any open source desktop to be able to connect to printers, both locally and in networks.

In all honesty, I haven’t had a printer connected to my box for almost two years now. On average I have to print something once a month at home. The rest is taken care of in digital form. At work it is a completely different matter, but I don’t have an open source desktop there. I write this to explain that I didn’t test printing under DesktopBSD, just checked how it was organized.

KDEPrint

You can access the print management tool -KDEPrint- via Settings (II) -> Peripherals -> Printers. The new window shows you which printers are already installed.

As you can see a couple of pseudoprinters are already installed like the ability to print a document to a PDF-file, send it as a fax or as a PDF attachment to an e-mail. “Add” gives access to the wizard to add a new printer (guess you didn’t see that coming ). It’s one of the first functions a new user might want to use.

The list of connection types is impressive, a bit overwhelming even. Apart from your local printer (connected via parallel, serial or USB connections) there are various options for networked printers.

The KDEPrint manual is a good document to understand more about printing using open source tools, an important one being CUPS.

CUPS

I remember playing with CUPS when I had a ClarkConnect box in my network and a USB-connected Apollo 2100 printer. I had to alter the CUPS settings via a webbased interface. KDEPrint makes it somewhat easier. You access the CUPS settings via Print Server -> Configure Server.

Once you are here it requires quite some background knowledge to do anything useful with it. Maybe it’s best for novice users to leave it as it is.

Will my printer work?

From experience (though a few years ago) I can tell that you can come a long way, but there are still printers out there that simply aren’t supported yet. One good starting point is the OpenPrinting database (which tells me that my wife’s Lexmark X7170 is a paperweight). Chapter 9 of the FreeBSD Handbook should also be compulsory reading as it explains the FreeBSD print spooler. If anything, it prevents any complaints like “*BSD s***s because it doesn’t support my printer”.

Once you migrate to an open source desktop (in this case DesktopBSD) and decide to stick with it, it is a sane practice to first check hardware compatibility lists before buying new hardware. Or make the final step and stop printing altogether.

DesktopBSD day 25 – ee, the commandline editor

One of the running gags in the realm of Linux is “vi or emacs?”. Apparently there once was a time this question could turn a room into cinders. Now, it may be a good example of the freedom of choice open source software provides and that it is useless to become dogmatic or zealously fanatic about either choice. Still, the type of discussion still comes up now and then. One day I noticed a post in a Linux forum, where someone got the suggestion to use gedit to edit a file. Immediately another jumped on the thread, stating that nano was a much better tool for the job. Who cares? As long as it get’s the job done for you.

Why the need for a commandline editor?

Open source desktops have progressed to a point that an average user will often not need commandline tools. Ubuntu 7.10 now even has a graphical tool to channge xorg.conf settings and as time progresses most open source desktops will often graphical tools for most, if not all tasks a user has to do. For the time being there will be times an editor comes in handy and maybe it isn’t such a bad thing to educate users in commandline tools and troubleshooting anyway. Part of the charm of open source is the freedom it provides to grow and learn.

ee

The FreeBSD handbook mentions ee as an easy to use editor.

The easiest and simplest editor to learn is an editor called ee, which stands for easy editor. To start ee, one would type at the command line ee filename where filename is the name of the file to be edited. For example, to edit /etc/rc.conf, type in ee /etc/rc.conf. Once inside of ee, all of the commands for manipulating the editor’s functions are listed at the top of the display. The caret ^ character represents the Ctrl key on the keyboard, so ^e expands to the key combination Ctrl+e. To leave ee, hit the Esc key, then choose leave editor. The editor will prompt you to save any changes if the file has been modified.

Without desiring to start a new editor war, I have to admit the handbook is right. ee is a very accessible editor. It reminds me of Wordstar, back in the late 1980s.

With ^[ (Ctrl + [ ) a menu appears, where you can find various other functions, but basically you can start editing a file without learning any obscure key combinations (like in Vi). The fact that you have undelete and restore options right in front of you should be comforting to quite a group of novice users. I liked ee so much I installed it on my Ubuntu box as well.

DesktopBSD day 24 – Removing software

Running into the problem of limited harddisk space made me take a closer look at the deinstall option in Package Manager. Again, it may only be a tiny feature, but when it’s made as easy as possible it does contribute to a good end-user experience. Clicking on the deinstall icon launches a wizard.

Next you will see a list of installed applications and it is now a matter of ticking the proper boxes. Be careful, because it is now quite simple to completely remove your desktop environmnent or the X server.

The final step of the wizard gives you a list of applications that will be removed. You can calculate how much free space you get as a result of this operation.

Since my laptop drive had about 300 Mb left due to all the software on my virtual DesktopBSD box I went out on a ‘hack-and-slash’ and removed all software that was already discussed in this series. Good! Almost 700Mb of extra free space

DesktopBSD day 23 – Accessing Network Shares

I know, I promised to write about America’s Army. Well, installing that didn’t work out. The only hard disk that actually agrees with *BSD is 6+ Gb and installing America’s Army on that one via ports was a bit too much. I am still looking for a solution.

In the mean time I moved on to the next experiment: trying to access network shares. It’s not uncommon to find small networks in the homes of end-users. Sharing files in a Windows-only network is very simple. A nice wizard helps you to set it up. In a mixed network of Windows and Linux or *BSD it requires a little bit more. What tools does DesktopBSD provide to help you access the network shares?

The swiss army knife: Konquerer

Konquerer is a very versatile tool and very powerful. When you launch it you find a hyperlink to Network Folders. This in turn reveals a new page with three icons: Network Services, Samba Shares and Add a Network folder.

Here’s where you need the extra knowledge. If you want to access network shares on Windows computers, those are mounted via the SMB-protocol. Double-clicking on Samba Shares brings up a new windows. First you will only notice the Mshome icon. MSHome is the default name Windows uses for it’s workgroups. Of course, it should be one of the first steps to alter that. Security has to start somewhere. It takes some seconds for the other network shares to appear, in my case a shared folder on the Ubuntu laptop.

The network shares are now accessible and ready for use.

The icon Add a Network folder launches a wizard with which you can add various types of network drives: WebDAV, FTP, Microsoft Windows network drive or SSH.

Of course you have the needed information to fill in the blanks and you are ready to go.

Conclusions

This experiment was very simple, but it does show how much progress has been made in the open source world. There is no need to hack obscure text files in order to share folders and files. Yes, you do need some background information, but that is supposed to be part of education and/or training during a migration strategy.

The future? Dolphin

Kubuntu 7.10 comes with a “new” filemanager, Dolphin. On it’s website it clearly states it is not meant as a replacement for Konquerer:

Dolphin is not intended to be a competitor to Konqueror: Konqueror acts as universal viewer being able to show HTML pages, text documents, directories and a lot more, whereas Dolphin focuses on being only a file manager. This approach allows to optimize the user interface for the task of file management.

I have played with it under Kubuntu and was looking forward to installing it under DesktopBSD. However, both the package and the port failed to install. I can only encourage to keep an eye out for Dolphin.

DesktopBSD day 22 – Setback

I wanted to write the coming articles about gaming under DesktopBSD. Of course I explored gaming under PC-BSD already, but most of those games were installed via PBI’s and not everything was succesful. This time I would have to install the software via packages or a port. A few weeks ago I installed DesktopBSD on a regular box, instead of a virtual one, and that was the proper computer for gaming.

Sadly, I couldn’t use this box anymore. For whatever reason it wouldn’t give me a graphical interface, just the message “Input not supported”. The problem lies with the X server, no doubt, but it wasn’t a problem I could fix. Yes, I know how to fix problems with the X server, but when a screen turns up blanks again and again it becomes a bit hard.

Most of today was spent installing DesktopBSD again -a job finished in less than 45 minutes- and then updating the whole system, which took another four hours. Once that was done I decided to get going with America’s Army. Apparently there is no native FreeBSD port for this game, but there is a Linux package in the collection. Both the Package Manager and the commandline # pkg_add -r linux-americasarmy failed. Ouch, this means it has to be installed via ports. That’s going to be an all-nighter again. While I am writing this, the 750+ Mb source is being downloaded. The rest will have to wait until tomorrow.