Manifesto

What is Fury? (Added 10-25-2019)

While in greek mythology fury could represent “a spirit of punishment” to this project we would like to think it more likely represents a culmination of efforts from a community coming together quickly, furiously.  

How is Fury different? (Added 03-18-2020) (Updated 03/24/2020 for future improvement around virtual-box-guest-additions)

Let’s start with a few goals:

1.) Provide a read write filesystem to allow trying drivers to verify hardware works without commiting to disk.

2.) Automate the process of installing a graphical desktop while allowing all other parts of the installation process to work exactly like FreeBSD.

3.) Install a pristine copy of FreeBSD that can be updated with FreeBSD tools from then on.

4.) Make the process of configuring devices, complex tasks relating to desktop configuration easier for small to mass deployments by reducing the overall amount of steps required. In other words just enough automation but not too much that we do something inherently wrong.

Now lets deep dive:

The first difference from FreeBSD is that we provide a different delivery mechanism with a few extra helper tools to make 1-4 a reality. The FreeBSD installation media boots a read only UFS filesystem media. We could easily produce a similar media which uses the rc.initdiskless framework to make certain directories writable in it’s LiveCD mode. That would get rather large if you were to try to include an entire desktop. You would not be able to install packages, or try random things to get your hardware to work. Instead you would have to commit to disk first just to know if your intel graphics chip is really going to work.

A second, and new difference from FreeBSD media is that we update to the latest patchset each quarter so the user does not have to immediately have to update using freebsd-update to protect from vulnerabilities. The FuryBSD build system uses poudriere to do this and we ensure that the jail is always up to date with the latest patchsets. FreeBSD offers 12.1-RELEASE ISO media, and we offer 12.1-p2 ISO media which means RELEASE + patches from freebsd-update already included. Thanks goes to a community member for suggesting this feature request on GitHub.

Poudriere image is also used by the build system to assemble a tar archive which later on becomes a compressed uzip that consumes far less space. The reasoning for this is poudriere does not yet support our use case fully so we break out into extracting the tar archive, installing packages, overlays, dotfiles in /usr/share/skel, enabling services, making uzip, making minimal ramdisk, making image.

During the boot process a smaller ramdisk image is loaded to fit into UEFI staging size limitations with a tiny init script that loads mounts that compressed image, then replicates an exact copy using dump | restore to a malloc memory disk created by the init. This dump | restore method is the closet equivalent to UFS replication that I know of, or at least that is the best I can describe it. This is how we end up with a smaller ISO 1.8GB that can boot up read write.

Since kldload expects modules to load other modules in /boot/kernel the purpose of rerooting instead of chrooting like other solutions is to allow other low level utilities such as kldload to work while maintaining a fully read write filesystem. Unlike any other BSD distribution media out there as of the time of writing after the reroot takes place we boot an unmodified copy of stock FreeBSD as if it were already installed from live media. When you reboot the live media the changes are gone unless you install to disk prior to the reboot then any, and all changes you made will be replicated to your install.

This allows us to do the following:

1.) Boot a pristine copy of stock FreeBSD, as we boot we detect whether we boot UEFI, BIOS and we load the proper failsafe driver. We also detect if we are booting in VMware, or Xen and prepare rc.conf, xorg accordingly before rerooting.

2.) We boot the user to the desktop of their choice, we connect them to the network automatically if using ethernet, and provide a tool to make connecting to wifi easier if the device is supported.

3.) We provide an xorg tool that allows the user to try various combinations of intel, nvidia drivers from the live filesystem without having to install. Some setups are more predictable, and safer to fully automate. For example Virtualbox will be included in future ISOs but removed on the fly before booting when VirtualBox is not running.

4.) Finally we allow the user to commit the installation to disk. Every change you made is saved unless you reboot without installing.

Since this is a FreeBSD installation unlike other projects FuryBSD can go away and there is no need for a migration path because FuryBSD is FreeBSD you can just keep updating FreeBSD. This is why we cannot be as adventurous like other projects when it comes to updating mechanisms or base OS changes like service frameworks because we do not want to ever have to break that promise, and leave people stranded with no clear path forward. This is how we are also different from other derivatives of the past, and present.

This means we are also not as exciting as some other projects since we follow production FreeBSD, and we are not trying to invent a desktop environment we simply provide the most popular major desktops. We just try to make FreeBSD work for you with a lot of automation, a few essential tools, and some nice theming so you can simply get a desktop installed, configured quicker, and easier.

With that said how can we improve? We can continue to make, and bundle new tools to make automation easier whether or not that task be setting up your printer, locale settings, there is so much to be done. That can be exciting too. This is still a fairly new project so it will take a while to establish.

The plan for 2020 (Added 03-18-2020) (Updated 03-24-2020 to add release schedule)

2020 Q1 – 01/15/2020
2020 Q2 – 04/15/2020
2020 Q3 – 07/15/2020
2020 Q4 – 10/15/2020

Once per quarter new ISO’s will be published for XFCE, KDE which contain the latest production version of FreeBSD with the latest patchsets, and packages from the quarterly repos. For each of these releases we will address many of the community enhancement requests, bug fixes, and include any community contributions during each of these quarters.

While the Q1 2020 image was delivered about 2 months later than expected the next images should start to arrive closer to the beginning of each quarter as FreeBSD quarterly pkg repositories are updated.

The milestones for Q1, Q2, Q3, Q4 2020 can be found at GitHub.

From looking through the milestone it’s easy to see that some of the projects objectives this year are community driven. The initial focus for 2020 is to focus on the core experience of the Live ISO, and provide a unique tool for making applying Xorg changes a breeze.

Each quarter we make sure we continue to improve upon that experience, and flesh out support for KDE, and possibly Gnome by end of year 2020 as well while making sure that the core experience does not break. This year is just about getting the release process down, and making sure we have a stable vehicle to continue to deliver timely updates each quarter.

For the next year 2021 I would like to focus on the post install experience by building out a tweak tool for doing post installation tasks such as configuring webcam, printer, connecting to a directory server, enabling network discovery, setting up a firewall, other system hardening.

This will be expanded upon more as time goes on as to how exactly it will be implemented but just know that a good chunk of the scripting is already in place in my personal repo which is public, and the plan has been thought about for several years already. Having a live ISO was a stepping stone in that plan.

The original manifesto (Added 10-25-2019)

FuryBSD is a back to basics lightweight desktop distribution based on stock FreeBSD.  As one of the first releases it will merely start as a vessel to deploy nothing more, nothing less than the following:

  • FreeBSD 12.X RELEASES
    • No development branches
    • Quarterly ports by default
    • No unnecessary tunables, services
    • FreeBSD tools first to perform system management
      • freebsd-update, pkg, bsdconfig, bsdinstall
  • Top tier applications
    • Firefox
    • Maybe others to come
  • Lightweight but first class desktop environments
    • XFCE
  • Small footprint
    • Installation image only 1.8GB in size to download (updated 03-18-2020)

What’s next? (Added 10-25-2019)

Our next images will focus on FreeBSD 12.1, and getting the LiveCD to it’s best possible state.  We will ready the forums, and work on documentation to provide some basic guidance on how to get started, and what to do in case of failure.

Below represents the first technical roadmap of what has been in mind for the project all along:

  • A sane framework for loading, 3rd party proprietary drivers graphics, wireless
    • This needs more thought, investigation to do correctly.  We don’t want to make too many assumptions, and break hardware that may work.  For example a first draft of a tool might have assumed HyperV was actually VirtualBox.  We don’t want to introduce regressions, and cause more problems. This has to be done carefully.  Is this an opt in, or opt out process? In general where often this could be an upstream FreeBSD limitation we have to be careful about making the same mistakes other distributions have when they get it wrong and broke devices which could have worked.
  • Cleanup up the LiveCD experience a bit more to continue to make it more friendly
    • No matter how tempting we want to avoid using other third party installers, or making too many of our own tools which would mean more maintenance in critical areas to keep up with change from too small of a team.  In general while bsdinstall, and bsdconfig might not look the most appealing they just work. There is little reason to make something new other than visual appeal which can perhaps still be taken care of by leveraging bsdinstall, etc.
  • Printing support out of box
    • Do we chose cups?  Which sets of drivers?  Some despise cups and chose to pursue traditional unix printing methods.  How we address this has to be decided.
  • A few more default applications included to provide a complete desktop experience. 
    • This will require some democratic decision making within the project and community to come to an agreeance on what ships with the image that may also be removed.  As part of this a welcome tour will be created to showcase even more of the best, and most popular software.
  • Integrated ZFS replication tools for backup and restore
  • Live image persistence options
    • For writable media such as USB stick and the like we should allow contents to be saved, and restored upon the next reboot.
  • A custom pkg repo with sane defaults
    • GKSU – The graphical switch user utility is another could example.  This cannot be installed without including Gnome 3’s file manager unless we provide a custom package repo in the future.  This may be an essential tool to provide administrator access functional in the graphical environment for XFCE for future printing support integration out of the box, etc.  This is another area where we must be careful, and provide guidance to contributors to do the same. We can’t flip sound backends, nor experiment too much in these areas without creating a poor user experience.
  • Continuous integration for applications updates
    • In order to ensure mission critical applications such as wine always continue to work we will provide hooks in Jenkins to monitor, and prevent bad updates from getting pushed when the critical list fails, or when too much fails in general
  • Quality assurance for FreeBSD on the desktop
    • As we learn the pain points if any test suites will be developed around critical areas of functionality to ensure that new releases, and rollups do not break systems. 
  • Tailored artwork, color scheming, and theming
    • Part of providing a good user experience is looking good.  Providing the user a reason to want to come back. Also the impact of professional looking artwork may mean more adoption for business.
  • Directory services integration
    • Full support to join Active Directory, and LDAP environments for corporate deployment.  We want for FuryBSD to be enterprise friendly as well.
  • Marketing
    • It needs to be decided what efforts can be undertaken such as BSDstats, distrowatch, and other metrics gathering tools.  At the moment BSDstats would reflect that we are FreeBSD, and not FuryBSD. So it would not do this project any favors necessarily to gain in popularity.  Something like this has to be opt in if the time ever comes.
  • Community
    • Steps should be taken to ensure the community is respectful, and respected in return.  In general responding back to trolling should be avoided but we need to ensure the users aren’t driven away from the project by it as well.  Therefore moderation will be required at some point.
  • Donations
    • If the project grows in popularity enough at some donations could be collected and if this happens we must be transparent about how those funds are spent to improve hosting, contracting, or other efforts to benefit the project, and community.
  • Security hardening
    • Some effort should be taken to set reasonable hardening such as user not being able to see another processes by default, as well as expose more intense options to advanced users such as kernel lockdown, firewalling.

Conclusion (Added 10-25-2019)

So while today FuryBSD is merely a vessel to install FreeBSD with XFCE we want to become one of the better open source desktop distributions possible by maintaining high standards.  That will mean picking the right balance of tuning knobs to ensure quality expectations can be met, and allowing the user to have as pure of a FreeBSD experience as possible as well as being transparent, and thoughtful about decision making.