We are a systemd free linux community

Edited again: 2018-11-15

As the previous site started out (08/2017) of the temporary need for Artix users to meet and exchange experiences, share solutions to problems, now that Artix has its official site, we have decided to move in the direction the site had already taken anyway.  Freedom and equality of access and exchange of information.

Antix is to Debian what Obarun is to Arch, and Devuan is to debian what Artix is to arch. All four of these projects/distributions seem to be very promising in concept and execution.  Equally promising, if not more, is Void linux taking an independent path.  Continue reading


What do we need computers for? What if!

First I would like to welcome cynwulf1 to the community and in specific to the small sub-sector of the community of contributors.  Cynwulf1 appears to have been around this sport long and with a wide spectrum of experience.  He recently contributed an article and some comments on the world of BSDism.

While recently I have worked closer with some of the creators of systems we use I have tried to learn how they think, or how they think differently from us users of systems.  The question that appeared to me is whether they can possibly know or care what “people need” or are they just driven by what they need for themselves, which in some cases is a system to work on, while creating systems.

Continue reading

What is a “*BSD”?

Considering a *BSD

With the arrival of a certain “init system”, more Linux users have at least dabbled with *BSD derived OS of late. There is a renewed interest as it’s perceived as an “escape route”. I have read comments that some Linux users see *BSD as their “last resort” to escaping systemd if it become unavoidable in their Linux distribution. So far as I can tell, it still seems entirely possible to avoid systemd in Linux, so it is my view that some of this sentiment is kneejerk and as a result of fearmongering.

I decided to write this to dispel some myths and help prospective users manage their expectations. I am a ‘BSD user who migrated away from Linux long before the arrival of systemd in notable Linux distributions such as RHEL and Debian.

What is a “*BSD”?

Several distinct, full and complete operating systems derived from Berkeley UNIX (not just a kernel), which in itself is a descendant of AT&T UNIX. All of the projects have different goals and focus – which is in fact why they are separate projects. To summarise: FreeBSD and NetBSD are the original forks of 386BSD, you can read on the web as to why FreeBSD and NetBSD forked from 386BSD. OpenBSD was an early fork of NetBSD and DragonFly BSD is a fork of FreeBSD. All of these have diverged and today, the four major *BSD derived projects are very different OS, but of course at the same time have similarities, which make them “BSD” as opposed to Linux or anything sysv based (such as Solaris).

Some further reading:


What isn’t “BSD”?

“BSD” is not Linux, not GNU, not a GNU/Linux distribution, nor is it based on Linux, neither is “BSD” from a single source or just a kernel. “BSD”, doesn’t really exist anymore. Operating systems descended from BSD (4.4BSD-lite 2, etc) do still exist (often referred to collectively as “*BSD” or “BSD”), but the term “BSD” is just and umbrella term and is often about as meaningful as “*nix”.

They are not platforms for ideological or political pontificating/rants. In fact the OpenBSD project in particular strongly discourages this and you will probably be asked to leave their mailing lists if you start “advocating”, etc.

The *BSDs are not binary compatible, so the term “BSD distribution” as an analog to “Linux distribution”, which you will often see bandied around in Linux circles, is also meaningless.

The *BSDs are much older than Linux, indeed, the *BSDs could have been “Linux” if it weren’t for certain corporations and lawsuits. Linus Torvalds once famously stated that he would probably not have started Linux if the FreeBSD kernel had been available and unencumbered at the time. Linux came about as a necessity – because the GNU/Hurd kernel was simply not ready (and still isn’t).

Who should / should not consider using a *BSD?

Those prepared to read about the various OS at least some of the above links, as well as man pages and documentation might want to proceed further, those who just want a “works out of the box” system should move on. Those wanting a “just like Linux” system should move on. Those wanting to complain that *BSD isn’t ready yet or is “too difficult”, or “years behind” Linux, should just move on. I could equally claim that Linux is “years behind” Windows or macOS – and in some respects I’d be right. That’s it.

Those who dabble with a *BSD because they ‘hate’ something else – e.g. Linux or systemd, etc should also move on.

The various *BSDs have been built by UNIX professionals for UNIX professionals. We are “along for the ride”, we get to use the free stuff, we don’t really need to complain about it.

We can, if we have skills or the funds contribute something in order to get what we want, or make strides in that direction. We can sit about and complain and annoy people on the official mailing lists, but it won’t change a thing – and you will find next to no developer willing to take heed. If you’re a developer working for a small project for free, why would you listen to complaints to the effect that your software doesn’t provide this or that, or that you need to be more like Linux/Windows/whatever?

So, if you want the wifi driver for the “Made UP Name Athercomtel WXS20005ZXL” to work, you will need to do something: i.e. send working hardware to the developer or do some research or learn C and see if you can improve the driver / write or port a driver. That’s how it works in ‘BSD land. No one will do it for you.

Where can one get support for the *BSD stuff?

Look no further:

  • % man man
  • % man
  • Refer to the operating system’s online handbook
  • Search the web
  • Search mailing list archives
  • Search the operating system’s official forums (if applicable)
  • Search the unofficial *BSD forums and as a last resort, *BSD subsections of Linux forums (the latter are of limited use).
  • Register an account at a *BSD official or unofficial forum and ask a properly constructed question, including all relevant details.
  • Post to the official mailing list, ensuring you post to the correct mailing list, with a full description of the problem, how to reproduce the problem, what you have tried and dmesg(8).


Software apart from the base system (the OS and userland), is referred to as “port”. Ports are typically made up of much of the software you also find available for Linux, with various copy left and non copy left licences, ported to any given *BSD derived OS. All of the various *BSDs have their own ports systems, but the original ports system was from FreeBSD.

For some Linux users, it’s often surprising to learn that much of the software they use was not originally written for Linux or is not specifically for Linux, but was coded to be roughly POSIX compliant and/or portable to any *nix like OS. An example would be X.org – much older than Linux and released under a permissive licence (not GPL). So if one has any objection to permissive licences – don’t run an X server!

A ports system is essentially a source tree, by which the user can build software from source and dependencies are resolved. A pre-built port is called a package and is obtained either by a “Linux like” package manager (such as FreeBSD’s pkg) or by the “legacy” package tools (still used by OpenBSD). Dependencies are resolved in both cases. The ports system is not regarded as part of the OS.

So while packages are binary – they are still ports, as there built, usually with the default compile flags, from the same ports source tree.

init system?

No *BSD uses sysvinit. So an “escapee” from systemd will still find themselves in unfamiliar territory. The simple “BSD style” init does not have System V style runlevels nor the familiar /etc/init.d schema. In Linux land, the rc system used in Slackware Linux and one or two more, is probably the most comparable to that used by the *BSDs. There are small differences in this system as implemented bet

Forging ahead, giving it a go and learning

So long as you understand the basics of how these projects are developed, that they’re free, that no one owes you anything that “works out of the box” is hardly ever a project goal, then you are always encouraged to try it out.

Which one is the best?

An impossible one and recipe for many flamewars, to the extent that discussing other OS has been pretty much disallowed at a certain official *BSD forum… but forums are forums, usually have a high fanboi population and there will always be certain characters who make a career out of slating one OS while building up another – one can only try them and see which works best for you.

The only advice I can give is – forget VMs. Try to get some kind of bare metal for an install – find an extra HDD and throw it in and install on that. Knowing if a *BSD works on some crap virtualised x86 is not really that useful, knowing if your hardware is supported and if everything works is very useful to know. This may ultimately come to define which of the *BSDs you use, if any and not which is perceived as “the best”.

I could recommend all four of the major *BSD derived OS, for various reasons, but it’s still “horses for courses” and my recommendation doesn’t really matter in the grand scheme of things as it really depends on what the individual wants to do with the OS.

Don’t expect “out of the box” dual boot with other OS. Install the *BSD on it’s own hard disk or better yet it’s own computer. Then set up your other OS’ bootloader, if applicable, to chainload it. This is simple (how you’d do it for windows) and once you’ve got the knack it’s a 5 minute job. No *BSD developer on any mailing list is going to be interested in someone trying to multiple boot Windows, Linux and FreeBSD on the same x86 PC.

*BSD is not for everyone

That may indeed be the case, or it may be that you will revisit at some point.

There is another common sentiment I have come across from time to time:

“I’m hesitant because RMS has said bad things about the BSD style licences”

I hesitate to use the term, but “FUD”. Ideological differences – with much of the ideology coming from the GNU side and the average user being mislead by propaganda.

The BSD licence is extremely simple and unrestricted, in that sense it’s the very essence of “free”. The GNU GPL “copyleft” licences tend to be “militantly free” and v3 in particular is a lengthy and complex legal document which puts far more limits and controls on what can and can’t be done with the software.



There is no simple “divide” here. While most of the *BSD based operating systems usually do not contain GPL code (or strive not to add any more), the sysadmin/user has the facility to install 3rd party software, “ports”, which does usually include a lot of GPL’d code. And with regard to Linux distributions, BSD style permissive licences are commonly found there as well.

There are indeed arguments for both licences. The reality is, we have this present situation – many different free software licences, some copyleft., some not. We have to live with it, but neither licence type is a reason for an end user to exclude anything.

In terms of the “corporate” aspect – if “Fortune 500 Company Inc” takes NetBSD and wraps it up as a proprietary offering and sells it as some kind of network appliance – and gives nothing back to NetBSD, (or maybe throws a donation of < $5k at them), that doesn’t affect the project or a user of NetBSD, it doesn’t make NetBSD “less free”.

If that same company takes over a GPL v3 licenced project, employs and pays the developers, funds the project, decides the direction it will now take – decided ultimately who they will sell that subsidiary onto when it no longer serves a purpose – I’ll leave the reader to decide which is the “freer” .

New base and KDE-Plasma live images from Obarun

On some very specific hardware a recent linux5.0 change caused a delay in tty/login appearance.  It was found and fixed.

05-2 Base image 564MB (iso and cksum files)
05-2 KDE-Plasma live image (iso and cksum files)

A few weeks from now a new set of images will reappear as s6opts/s6boot are deprecated and 66 will move into the main obarun repositories (obcore,obextra, observice).   Continue reading

HACK: Void kernel management – vkpurge modification

For those that don’t know about Void and kernels, Void offers many of them at any single period and updates them within 24hr of a new edition.  The kernel pkg name for each edition stays the same, but the versions have an extended naming that is also used in making the bootable images.   For example, let’s say you are following “linux4.19” and it is currently linux4.19.39-1.  Then there might be 4.19.40-1, 4.19.40-2 and so on.  If you use vkpurge to list the editions it will show you all except for the current.  Let’s say you also follow linux4.14, linux4.20, and linux5.0.  You may end up having to remove many kernel editions within a week.  Continue reading

Latest Obarun installation/live images released (base, JWM, KDE Plasma)

Since the Fall of 2018 Obarun has committed to publish a new base iso-image (Obarun_x86_64-2019-05.iso) every month. The current installer updates itself from the obarun git repository when it starts.   The installer allows you the ability to select desktops and software during installation or install a base system, boot and customize on your own.   2-3 times a year a new live-desktop image using JWM is also published.  This is the latest iso with JWM published mid-April (Obarun-JWM_x86_64-2019-04-2.iso).
Since the major new release and change of repositories in April 2019, along with the introduction of Obarun’s own 66 management system over Skarnet’s S6 init, there have been minor refinements reflected in the new iso.  So if you have last month’s images there is no need to download the newer one. 
Although I never liked anything KDE myself I tested it and it works flawlessly.  For those who want to install plasma, although possible with the installer from other isos, it might be helpful to have the live image handy to see how user services are employed and handled by 66 and required for plasma.
Older images (before mid-April 2019) may require some attention and manual intervention to incorporate the changes in repositories, although the installer may take care of the change.

Continue reading

What you must know about 66 * ease * simplicity * no magic

.  .  .  .  .    A 66 FAQ document

Is 66 different than s6 or an alternative to it?

NO!  66 is a layer of software on top of s6 that makes s6 easier and more understandable to users with little or no experience in unix-system-administration.  66 takes bundles of complicated s6 commands and scripts and simplifies them into 66 commands that help you customize and optimize your system just the way you need.   Experienced enterprise lever administrators are not limited by 66 in any way, it only makes monitoring their systems easier and quicker.

Continue reading