DistroWatch Weekly, Issue 700, 20 February 2017

Feature Story (by Jesse Smith)

RaspBSD



RaspBSD is a FreeBSD-based project which strives to create a custom build of FreeBSD for single board and hobbyist computers. RaspBSD takes a recent snapshot of FreeBSD and adds on additional components, such as the LXDE desktop and a few graphical applications. The RaspBSD project currently has live images for Raspberry Pi devices, the Banana Pi, Pine64 and BeagleBone Black & Green computers.



I decided to give the RaspBSD operating system a try on my Raspberry Pi 2 computer. The download images vary a good deal in size, for example the Raspberry Pi B download is 267MB while my compressed Raspberry Pi 2 image was a 746MB download. Once the compressed file was downloaded, I unpacked it and the result was a 2384MB (2.3GB) image file I could write to my SD card.



Inserting the card into my Pi booted the RaspBSD operating system which, for all practical purposes, is FreeBSD 12.0-CURRENT. When the operating system finishes booting, we can sign into the Pi over secure shell using the account name raspberry and the password raspberry. There is a root account on the system which is, by default, not protected by a password. However, the root account cannot be accessed remotely. Signing into the Pi gives us a command line interface and the login message provides links to FreeBSD's documentation and helpful resources.



Running RaspBSD on an 8GB SD card provided me with a fairly standard FreeBSD installation on a 7GB root partition. Of that 7GB, 1.9GB of space is used by the base operating system, utilities and the LXDE desktop. This leaves us with 4.5GB of free space, once reserved space is taken into account. RaspBSD does not set up swap space for us.



The default RaspBSD system is quite minimal, running a mere 16 processes when I was logged in. In the background the operating system runs cron, OpenSSH, syslog and the powerd power management service. Other than the user's shell and terminals, nothing else is running. This means RaspBSD uses little memory, requiring just 16MB of active memory and 31MB of wired or kernel memory.



One of the first things I did with RaspBSD was to see if I could attach a ZFS volume I had stored on an external drive. RaspBSD ships with ZFS modules enabled by default and this allowed me to import my external drive's ZFS pool as RaspBSD's root user. From there, I was able to check the ZFS pool's status, look at snapshots and copy files to and from the external drive. With my 2TB storage pool attached to the system, RaspBSD used about an extra 25MB of memory (16MB active, 56MB wired).



About a year and a half ago I experimented with FreeBSD on my Raspberry Pi and had to compile my own ZFS kernel modules. I also ran into a series of stability issues when transferring files between the root UFS partition and external ZFS partition. I was pleased to find ZFS is now included by default and the stability issues I encountered previously have been resolved.



Should we wish to add extra software to our copy of RaspBSD, we can use the pkg command line package manager. RaspBSD connects to the FreeBSD's software repositories and this gives us access to several thousand pre-compiled packages. We can then upgrade existing packages or install new software. I found unpacking and installing new software happened slowly and any effort to access files on the SD card while pkg was working took a long time. The week I was running RaspBSD, I downloaded 51 upgraded packages, totalling 114MB in size.



On the subject of software updates, I checked to see if I could update the core operating system using FreeBSD's freebsd-update utility. The freebsd-update program was unable to find a server with the files it needed, which means binary software updates are probably not available for RaspBSD's core operating system. The RaspBSD does not included FreeBSD's source code in the root file system, probably in an effort to save space on small SD cards. We could download the code and build or patch our operating system from source, but this is likely to be a long and tedious process. Disk access on RaspBSD was quite slow and accessing the disk tended to be a severe bottleneck when performing tasks.



Earlier I mentioned RaspBSD ships with the LXDE graphical environment and a small collection of desktop applications. The operating system does provide these tools, though during my trial I was focused entirely on using the RaspBSD operating system remotely over secure shell. I did try running a handful of desktop applications remotely via OpenSSH's X11 forwarding capability. This worked and I was able to remotely run desktop applications on RaspBSD, though performance was somewhat sluggish.



I made note of a few practical differences between running RaspBSD on the Pi verses my usual Raspbian operating system. One minor difference is RaspBSD turns off the Pi's external power light after booting. Raspbian leaves the light on. This means it looks like the Pi is off when it is running RaspBSD, but it also saves a little electricity.



When running the shutdown -r command on RaspBSD to restart the computer, the Pi would power off and not come back on-line. If I ran reboot though the Pi would restart as expected. On the subject of rebooting, I noticed that RaspBSD would not automatically re-mount my external ZFS volume when the system booted. I could add a start-up command to handle this, but it is something FreeBSD (on x86 servers) and Raspbian both do automatically.



Conclusions



Apart from these little differences, running RaspBSD on the Pi was a very similar experience to running Raspbian and my time with the operating system was pleasantly trouble-free. Long-term, I think applying source updates to the base system might be tedious and SD disk operations were slow. However, the Pi usually is not utilized for its speed, but rather its low cost and low-energy usage. For people who are looking for a small home server or very minimal desktop box, RaspBSD running on the Pi should be suitable.



I am definitely pleased to see ZFS support improved in recent builds of FreeBSD/RaspBSD and I like that RaspBSD users have access to FreeBSD's massive collection of pre-built binary packages. This should make setting up a Pi with a FreeBSD-powered web server or NAS much more appealing than it was a year ago.





Miscellaneous News (by Jesse Smith)

Debian swaps out Icedove for Thunderbird, GParted Live to support LUKS, Fedora's licensing guidelines, Mint's new features, FreeBSD's Status Report, DragonFlyBSD works to update video card support



For some time now the Debian distribution has shipped a re-branded version of the Mozilla Thunderbird e-mail application, called Icedove. The Icedove package contained no trademarks of the Mozilla organization and could be patched or modified as Debian's developers wished. However, times change and Debian is planning to return to packaging the Thunderbird application and will be phasing out Icedove. Christoph Goehre writes: " Hi Debian Developers and followers. Thunderbird is back in Debian! We also renamed other related packages to use official names, e.g. iceowl-extension -> lightning. For now, we need testers to catch existing issues and things we haven't seen until now. What happens the first time you start Thunderbird? With the change to the official Mozilla branding the user's profile will also be changing from '$HOME/.icedove' to '$HOME/.thunderbird' so we need to migrate the profile folder. " Details on the transition and things which still need to be tested can be found in this mailing list post. * * * * * Fans of LUKS encrypted file systems received some good news this week. The GParted partitioning management software (commonly used through GParted Live) now supports working with LUKS encrypted volumes as of version 0.28.0. " This release adds partial read-write support for LUKS encrypted file systems. GParted can't create, open or close LUKS encryption volumes; however it can copy, resize and manipulate file systems inside open LUKS volumes and move closed LUKS volumes. (Resizing requires Linux kernel >= 3.6 and libparted >= 3.2 for online partition resizing). " The GParted project included a reminder that people who use these features should first create backups of any important files as manipulating partitions and volumes can result in data loss. * * * * * The Fedora distribution has one of the more strict licensing requirements in the Linux community. The project attempts to ship only free software on its installation media and provides only free software in its software repositories, with a few rare exceptions such as binary firmware. There are good reasons for this and Tom Callaway has laid them all out in a talk, covered by LWN. Callaway presented the history of Red Hat Linux and Fedora, some of the legal concerns Red Hat has faced and efforts to simplify the licensing guidelines for the distribution. " Licensing was the next problem. Red Hat Linux used to have a "contrib" repository, where people put all sorts of stuff that had been built against Red Hat Linux so that it could be more widely used. When Fedora opened up, busy volunteers took nearly everything in contrib and threw it into Fedora. Unfortunately, much of this effort happened with no particular concern for licenses. There was a "license" field in the database of packages, but instead of "GPLv3" or "MIT", it often said things like "distributable", or in one memorable case, simply "ok". Callaway went through Fedora and found over 350 different licenses, including 16 BSD variants and 34 MIT variants (there were still more of those, but he stopped counting at 34). " The LWN article is an interesting read and covers some of the legal and practical concerns surrounding distributing open source software. * * * * * The Linux Mint team has been hard at work recently, preparing updated media for both the project's main editions (which are based on Ubuntu) and Linux Mint Debian Edition. Some of the features Mint users can expect to see include better Bluetooth support and Bluetooth file transfers through the Blueberry utility. " OBEX file transfers are now supported out of the box, so you can send files very easily over Bluetooth to your computer from any remote device. An option was added also so you can change the Bluetooth name of your computer. That name usually defaults to your hostname or to mint-0 and many people don't know how to change it via the command line. Last but not least, in addition to its cross-desktop system tray, Blueberry now provides a Cinnamon applet which uses symbolic icons and looks similar to other status applets, such as the power, sound or network applets. When this applet is present, the tray icon is hidden. " Mint's Xed text editor is gaining the ability to sort lines of text as well as quickly change the size of text in the editor. Mint's Xplayer video player is also getting some new features, including a more compact interface and short-cut keys for handing subtitles and language support. Further details can be found in this Mint Monthly News post. * * * * * The FreeBSD project has posted a new Quarterly Status Report which summarizes the progress and on-going tasks of the various FreeBSD teams. The latest Quarterly Report offers insight into the project's progress on ARM boards, updates to the WINE ports, efforts to make the LLVM linker (LLD) the default linker on FreeBSD and updates to the GNU Compiler Collection. The report also talks about efforts to make builds of FreeBSD reproducible: " Reproducible builds are a set of software development practices which create a verifiable path from human readable source code to the binary code used by computers. A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-for-bit identical copies of all specified artifacts. Baptiste Daroussin and Ed Maste attended the second Reproducible Builds Summit last December, in Berin. We discussed issues of common interest to operating system providers, including other BSDs and Linux distributions. Following the summit, changes were committed to the FreeBSD base system to address outstanding sources of non-reproducibility. It is now possible to build the FreeBSD base system (kernel and userland) completely reproducibly, although it currently requires a few non-default settings. Approximately 80% of the ports tree builds reproducibly, with a few work-in-progress patches. Now that the base system can be built reproducibly, focus will move on to the ports tree. " The Quarterly Status Report has further details. * * * * * Following some of the changes being worked on by the FreeBSD team to improve video driver support, including importing video drivers from Linux, the DragonFlyBSD team is now playing catch-up with the many changes happening in the FreeBSD ports tree. Rimvydas Jasinskas explains: As some of you are aware there were some recent developments regarding the DragonFly ports collection and FreeBSD-ports in general. Huge graphics stack update (including but not limited to dri, gbm, libdrm, libEGL, libGL, clang39, xorg-server and its drivers) was just pushed without giving us a any heads up to prepare for it or perform an early testing. This came as a surprise since last time we were notified about upcoming developments that allowed us could construct, patch and test the new stack. This is how RadeonSI card support was added to Xorg for the Radeon owners to enjoy running their desktop machines with accelerated graphics. We pushed ours and later FreeBSD pushed theirs since we have a different level of GPU support in kernel DRM drivers yet we share the same ports tree. However, this time it was not the case and we are trying to understand what has happened. We are aware that there is huge ongoing effort to finally import the DRM 4.9 GPU drivers from Linux using linux-kpi emulator layer allowing to copy/paste Linux drivers almost without modifications including the OFED. We understand this is quite an achievement that FreeBSD users will finally be able to run their desktop machines without a need to buy expensive NVIDIA cards and use binary blobs. " The post goes on to explore some of the challenges the DragonFlyBSD ports team is facing as they try to test the new changes before releasing DragonFlyBSD 4.8. * * * * * These and other news stories can be found on our Headlines page.





Tips and Tricks (by Jesse Smith)

Shell switching, battery charge, getting the system's IP address and dealing with stubborn processes



Part of what makes Linux a flexible and powerful system is the wide range of command line tools. This week I would like to cover some useful tips and address questions I have received concerning the Linux command line.



First, I want to address a question I received that asked how a person can go about changing which command line shell they are using. The shell is the process which interprets your commands and runs programs. Most Linux distributions default to using the bash shell, but there are several others. Different shells use different syntax and some have handy features to make navigating the file system or running commands easier.



To get a list of available shells on your system, look in the /etc/shells file. This will list the available shells with their complete path names. We can see the list of shells by running cat /etc/shells Additional shells may be available in your distribution's software repositories. Performing a search for the term "shell" in your package manager should provide you with a list of alternative command line shells.



If we want to experiment with a shell, just for now, we can launch a shell from within our existing shell. For example, if I want to run the tcsh shell, I can run tcsh When I am finished exploring tcsh I can type exit to return to my default shell. Once we have found a shell we want to continue using we can switch our default shell by running the chsh command. For example, if I want to switch to using the tcsh shell, I can run chsh -s /usr/bin/tcsh Please note that I provided the full directory path to the new shell. When we change our shell we should always provide its full path, as specified in the /etc/shells file. * * * * * Have you ever wanted to check the status of your laptop's battery from the command line? If you have the ACPI package installed, this is an easy task. From the command line, simply run the command acpi The acpi command will show you whether your battery is charging or discharging, the percentage of the charge remaining and an estimate of how long your battery will continue to run your laptop. The acpi command can be made to show additional information. acpi -V The above command will not only display battery charge information, but also the temperature of the CPU and other information acpi can gather from your computer's sensors. * * * * * In case you are wondering what your address is on the local network or Internet, there are a few ways to get this information. You can get your local network IP address by running either the ifconfig or ip commands, depending on your distribution. The grep command can be used to filter out the extra networking information we do not need. Here we see an example with ifconfig: ifconfig | grep inet And here we get the same information from the ip command: ip address show | grep inet You may notice multiple addresses being displayed. Usually, you will see one address which is listed as 127.0.0.1 or as ::1. These addresses are special values which your computer can use as a quick way to reference itself. A connection to the address 127.0.0.1 simply accesses services on your own computer. The other address you see is how other computers and devices on the same network can identify you.



The above commands are useful for getting your IP address on the local network, but if you are wondering what your address is from the point of view of other people on the Internet, you need to ask another computer how they identify you. This can typically be done with the curl command and any number of public services which will send you back your address when contacted. As an example, the ifconfig.me server will send us back our Internet address when we contact it: curl ifconfig.me * * * * * Sooner or later we all run into misbehaving desktop applications which lock-up or refuse to close. Some desktop environments will handle situations like this for us, offering to terminate applications which are no longer responding. Other desktop environments are less proactive and leave us to deal with the problem program ourselves. There are a few ways to handle a desktop application which is not responding. On most desktop Linux systems we can run the xkill program. The xkill program, when run, turns the mouse cursor into an X and the next window we click on gets immediately terminated.



Another approach we can take, which should work for any application whether it is an application running on the X display server or not, is to run the pkill command and provide it with the name of the program we want to stop. The pkill command finds applications with matching names and terminates them. As an example, let us assume the gedit text editor has stopped responding to input. We can terminate it using the following command: pkill gedit The only problem with this approach is pkill could find multiple programs with the name and shut them all down. To avoid this interrupting your work, I recommend saving anything you have open in similarly named programs before running the pkill command. * * * * * These tips, along with other tutorials, can be found in our Tips and Tricks archive.





Released Last Week

Torrent Corner

Upcoming Releases and Announcements

Opinion Poll

Time spent on the command line



Many of us, who have either been using Linux for a long time or used command line driven systems (such as DOS) previously, tend to grow comfortable with typing commands. Some of us keep a virtual terminal open at all times because quickly switching to it to fire off a command can be faster than opening a new window to deal with a situation in a graphical interface.



This week we would like to find out approximately how much of your time do you spend using a virtual terminal. Are you typing commands all day, perhaps a few times a day, or do you prefer to use graphical applications exclusively?



You can see the results of our previous poll on archive formats here. All previous poll results can be found in our poll archives.



Time spent on the command line



I use the command line almost exclusively: 220 (10%) I use the command line multiple times per day: 1125 (51%) I use the command line about once per day: 278 (12%) I use the command line weekly: 249 (11%) I rarely use the command line: 319 (14%) I never use the command line: 36 (2%)

DistroWatch.com News