DistroWatch Weekly, Issue 776, 13 August 2018

Feature Story (by Jesse Smith)

NomadBSD 1.1 One of the most recent additions to the DistroWatch database is NomadBSD. According to the NomadBSD website: " NomadBSD is a 64-bit live system for USB flash drives, based on FreeBSD . Together with automatic hardware detection and setup, it is configured to be used as a desktop system that works out of the box, but can also be used for data recovery.



The latest release of NomadBSD (or simply "Nomad", as I will refer to the project in this review) is version 1.1. It is based on FreeBSD 11.2 and is offered in two builds, one for generic personal computers and one for Macbooks. The release announcement mentions version 1.1 offers improved video driver support for Intel and AMD cards. The operating system ships with Octopkg for graphical package management and the system should automatically detect, and work with, VirtualBox environments.



Nomad 1.1 is available as a 2GB download, which we then decompress to produce a 4GB file which can be written to a USB thumb drive. There is no optical media build of Nomad as it is designed to be run entirely from the USB drive, and write data persistently to the drive, rather than simply being installed from the USB media.



Initial setup



Booting from the USB drive brings up a series of text-based menus which ask us to configure key parts of the operating system. We are asked to select our time zone, keyboard layout, keyboard model, keyboard mapping and our preferred language. While we can select options from a list, the options tend to be short and cryptic. Rather than "English (US)", for example, we might be given "en_US". We are also asked to create a password for the root user account and another one for a regular user which is called "nomad". We can then select which shell nomad will use. The default is zsh, but there are plenty of other options, including csh and bash. We have the option of encrypting our user's home directory.



I feel it is important to point out that these settings, and nomad's home directory, are stored on the USB drive. The options and settings we select will not be saved to our local hard drive and our configuration choices will not affect other operating systems already installed on our computer. At the end, the configuration wizard asks if we want to run the BSDstats service. This option is not explained at all, but it contacts BSDstats to provide some basic statistics on BSD users.



The system then takes a few minutes to apply its changes to the USB drive and automatically reboots the computer. While running the initial setup wizard, I had nearly identical experiences when running Nomad on a physical computer and running the operating system in a VirtualBox virtual machine. However, after the initial setup process was over, I had quite different experiences depending on the environment so I want to divide my experiences into two different sections.



NomadBSD in VirtualBox



When running Nomad in a virtual environment, the operating system offered slightly different results almost every time it booted. The first time, Nomad booted to a blank graphical environment with a working mouse pointer. There were no desktop elements and both left- and right-clicking produced no results. I could switch to a text console which showed a stream of messages saying "pushing table, processing notify events, popping table" over and over. The text consoles did not respond to keyboard input.



On the second boot, Nomad loaded a minimal desktop environment. A panel at the bottom of the screen presented me with a logout menu and a system tray. Right-clicking on the desktop brought up an application menu. Trying to open more than one application caused the system to lock up.





NomadBSD 1.1 -- The default desktop and application menu

(full image size: 634kB, resolution: 1280x800 pixels)



On the third boot, the desktop was displayed again, but the mouse pointer did not work at all.



The fourth time I launched Nomad the system booted and displayed the desktop. The graphical environment worked for about a minute, then the operating system froze and would not respond to any input.



I eventually found that Nomad would never run for more than a few minutes before locking up. Trying to run more than one application at a time would also bring the system immediately to a halt.



Despite the project's website mentioning VirtualBox integration, and the existence of a display configuration tool in the application menu, I could not get Nomad to display a desktop at a resolution above about 800x600 pixels. I noticed that when Nomad was displaying its minimal desktop, my host computer's CPU was always running at 100%, but when Nomad was displaying a text console my host's CPU idled around 5%.



Physical desktop computer



At first, Nomad failed to boot on my desktop computer. From the operating system's boot loader, I enabled Safe Mode which allowed Nomad to boot. At that point, Nomad was able to start up, but would only display a text console. The desktop environment failed to start when running in Safe Mode.



Networking was also disabled by default and I had to enable a network interface and DHCP address assignment to connect to the Internet. Instructions for enabling networking can be found in FreeBSD's Handbook. Once we are on-line we can use the pkg command line package manager to install and update software. Had the desktop environment worked then the Octopkg graphical package manager would also be available to make browsing and installing software a point-n-click experience.



Had I been able to run the desktop for prolonged amounts of time I could have made use of such pre-installed items as the Firefox web browser, the VLC media player, LibreOffice and Thunderbird. Nomad offers a fairly small collection of desktop applications, but what is there is mostly popular, capable software.



When running the operating system I noted that, with one user logged in, Nomad only runs 15 processes with the default configuration. These processes require less than 100MB of RAM, and the whole system fits comfortably on a 4GB USB drive.



Conclusions



Ultimately using Nomad was not a practical option for me. The operating system did not work well with my hardware, or the virtual environment. In the virtual machine, Nomad crashed consistently after just a few minutes of uptime. On the desktop computer, I could not get a desktop environment to run. The command line tools worked well, and the system performed tasks very quickly, but a command line only environment is not well suited to my workflow.



I like the idea of what NomadBSD is offering. There are not many live desktop flavours of FreeBSD, apart from GhostBSD. It was nice to see developers trying to make a FreeBSD-based, plug-and-go operating system that would offer a desktop and persistent storage. I suspect the system would work and perform its stated functions on different hardware, but in my case my experiment was necessarily short lived. * * * * * 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.8GHz AMD A4-3420 APU

Storage: 500GB Hitachi hard drive

Memory: 6GB of RAM

Networking: Realtek RTL8111 wired network card

Display: AMD Radeon HD 6410D video card * * * * * Visitor supplied rating



NomadBSD has a visitor supplied average rating of: 7.8/10 from 32 review(s).

Have you used NomadBSD? You can leave your own review of the project on our ratings page.





Miscellaneous News (by Jesse Smith)

Debian tackles bugs, openSUSE extends life of 42.3 release, update on the Librem 5 phone, NAS4Free renamed to XigmaNAS The Debian team has become very good at finding bugs and potential problems in their software packages. While discovering these issues is good, it means that more effort is required to get the distribution fixed up and ready for release. There is some concern this will delay the release of Debian 10 "Buster" unless volunteers put more effort into squashing bugs. A post titled Buster is headed for a long hard freeze states: " We are getting better and better accumulating RC bugs in testing. This is unfortunate because the length of the freeze is strongly correlated with the number of open RC bugs affecting testing. If you believe that Debian should have short freezes, then it will require putting effort behind that belief and fix some RC bugs - even in packages that are not maintained directly by you or your team and especially in key packages. " Some statistics on the current list of known bugs are also provided. * * * * * The openSUSE team is extending the life cycle of their distribution's 42.3 release. openSUSE 42.3 was originally scheduled to reach the end of its supported life in January 2019, but this date has been pushed back to June 2019. A post on the openSUSE News page reads: " The last minor version of the Leap 42 series was scheduled to be maintained until January 2019, but that has changed thanks to SUSE committing to additional months of maintenance and security updates. Leap 42.3 is based on SUSE Linux Enterprise Server 12 Service Pack (SP) 3 and SUSE has agreed to keep publishing updates for Leap 42.3 until June 2019. This means the extended End of Life for Leap 42.3 will increase the total lifetime of the Leap 42 series to 44 months. Users of the openSUSE Leap 42 series are encouraged to use the additional months to prepare the upgrade to Leap 15, which was released in May. " * * * * * The Librem 5 is a smart phone being designed to run open source software, such as a GNU/Linux distribution with a GNOME-based desktop interface. The Librem 5 is still in development and is expected to be released sometime in 2019. At the moment the developers are testing new designs and filling in gaps in functionality which will hopefully be included in the corresponding upstream projects. " Some more bugs were fixed in libhandy too as well as more preparation for GTK+4. One of the issues found and fixed was memory leak was found and fixed. Also there was a bug found and fixed in HdyColumn where the wrong width was being used for column height calculation. If you are following the librem-5-dev email list, then you may have seen that libhandy v0.0.2 has been released too! Nobody likes unsolicited ads so Better ad blocking was suggested to upstream to be used with Epiphany and is undergoing discussion. The phone will ship with an SMS app which also has E2EE messaging. We are working with the Fractal project upstream to get encryption implemented, but it’s not clear whether the Fractal 1-1 successor app (GNOME Messages) will have all the things we need by launch. " More details can be found in this blog post. * * * * * The NAS4Free project makes a network attached storage (NAS) operating system based on FreeBSD. The project is in the process of changing its name to XigmaNAS. The wiki and forums have already been moved to their new domain and the project's main website will soon follow. Details on the process and the reason behind the name change can be found in this forum thread. * * * * * These and other news stories can be found on our Headlines page.





Questions and Answers (by Jesse Smith)

Maximum storage limits on Linux Filling-up-all-available-space asks: What is the maximum upper limit for disk and swap space? Just how much stuff can Linux hold?



DistroWatch answers: There are theoretical limits on the amount of disk, memory and swap space you can access with a Linux distribution. In reality though we are likely to run into practical limits (such as the cost of equipment or physical room size) before we run into the theoretical restrictions of the Linux kernel.



The amount of memory Linux can access can vary from one processor architecture to another, so you will run into different memory size restrictions depending on the number of registers in your CPU and how big they are. On a x86_64 processor, which most modern desktop and laptop computers have, I think the maximum amount of memory Linux can access is defined by 44 bits. Which should provide an upper limit of about 16TB of RAM. Or about a thousand times more than the average laptop has at my local electronics store.



The amount of data we can write to disk storage will vary quite a bit depending on which file system we are using. The commonly used ext4 file system has an upper limit of around 1EiB, which if memory serves is a million terabytes. Another file system, called XFS, is often used by enterprise-class distributions and can store up to 8EiB of data. If that's still not enough, the advanced Btrfs format provides up to 16EiB of storage. In this arena ZFS probably has the highest theoretical limit with 256 trillion YiB of storage. A yobibyte (YiB) is a trillion, trillion bytes. At this point one might wonder if the ZFS developers were just making up new numbers to drive home just how much storage space their file system could handle.



I'd like to point out that the above file system storage limits are for just one file system. We could mount multiple massive file systems and/or attach additional storage over the network via a NAS. You're probably going to run out of money for new hard drives before reaching the upper limit of data we can write to attached file systems.



The maximum limit of swap space is a little less mind boggling. The maximum amount of swap space we can use will again vary by hardware architecture, but the mkswap manual page offers some pretty good estimates. The maximum number of swap areas (files or partitions dedicated to swap space) is 32. The maximum number of pages in a swap area is about 4 billion. A page's size can vary, but will typically be 4,096 bytes. So the maximum amount of swap space is probably 4,096 bytes per page, multiplied by about 4 billion pages in a swap partition, multiplied by 32 swap spaces: 512TB. * * * * * Additional answers can be found in our Questions and Answers archive.





Released Last Week

Torrent Corner

Upcoming Releases and Announcements

Opinion Poll

Review of Linux Mint Debian Edition 3 The Linux Mint project maintains two main branches of its distribution, one based on Ubuntu and the other based on Debian. Earlier this year we reviewed Mint 19 which is based on Ubuntu 18.04. With a new version of Linux Mint Debian Edition due to be released soon, should we review the Debian-based edition too, or is covering the available features in one branch of Mint enough?



You can see the results of our previous poll on using portable operating systems in last week's edition. All previous poll results can be found in our poll archives.



Review of Linux Mint Debian Edition 3

Yes - review LMDE 3 No - do not review LMDE 3 No preference