site  contact  subhomenews

Thinking about service managers

February 13, 2018 — BarryK

These are just "out loud" thoughts...

There are many service managers that derive from, or were inspired by, a package called 'daemontools'. Runit is one of them.

I have been sifting so many of the service managers, with maybe init replacement, but have always been left discontented.

Trying to pin down why this discontent...

The emphasis on automatic restarting of daemons. Why? If a daemon crashes for some reason, I don't want it to be automatically restarted.

The lack of support for one-shot services.

Incomplete dependency management. For example, I want a service to wait until there is a network up. Nothing else to be held up. I know that I can do it by examining /sys/class/net/dormant, but fitting this in as a dependency is at best a klutz, as far as I can see, in the service managers that I have looked at.

There are lots of init replacements with service management, such as minit, ninit, cinit, myinit. Or, service management with optional init replacement, such as runit and s6. Then there are some that are service managers only, such as serel.

I got excited that Runit applets are in Busybox, until I realised how limited it is. Not the Busybox implementation, the fundamental concept of daemontools. Unless my understanding has not fully grasped the capabilities, which is possible.

Here is another...


OpenRC is developed for Gentoo, and adopted by some other distros. It is a service manager, though apparently can become an init-replacement. What is particularly interesting is that thought has gone into using it with Busybox and Busybox's init:

Download source:


However, I was unable to compile it statically, so have taken it no further.

Will keep researching...

Tags: easy, quirky

Busybox 1.25.1 Runit applets

February 13, 2018 — BarryK

There is a problem with all the puplets, including Easy and Quirky. Well, unless a developer has tackled in it their puplet.

The problem is the order of execution of service scripts at startup, for example, those in /etc/init.d -- we execute those in a fixed order, however, that is barely adequate.

It may be that a certain service script should only run after there is a network connection, for example. Or sound is working, or X is running, and so on.

I have been looking at various solutions, and liked the look of Runit. Homepage:

Then, surprise, surprise, I found that the Runit utilities are in Busybox. They are:

chpst, setuidgid, envuidgid, envdir, softlimit, runsv, runsvdir, sv, svlogd

Using Landley's Aboriginal Linux, the older chrootable filesystem with uClibc (he has shifted to musl, unfortunately), I have compiled Busybox statically with those Runit applets enabled. I also enabled these network applets:

inetd, udpsvd, tcpsvd

Here is the PET:

...however, don't install it, as it will replace all the "full" utilities with symlinks to busybox. For example, 'sort' and 'date'. If you really want to use it, open it up with the 'pet2dir' utility, then copy the 'busybox' executable, then the above applet symlinks.

I have also compiled 's6' statically, and there are PETs, however, it is a solution that will add megabytes to the build. So, at this stage I am favouring Busybox Runit. To actually use it, is next on the agenda.

Here is an interesting read: 

Tags: easy, quirky

woofQ uploaded, 2018-02-11

February 11, 2018 — BarryK

This is the latest woofQ, as used to build Quirky Xerus 8.4.

Uploaded as a tarball here:

I also updated the woofQ Bones repository. Read about Bones here:

And woofQ and Bones here: 

Tags: easy, quirky

Quirky Xerus x86_64 version 8.4 released

February 09, 2018 — BarryK

It has been awhile since the last release of Quirky. That was version 8.3, in July 2017:

Now, a brand spanking new version. Announcement and release notes here;

A brief announcement:

Quirky Linux 8.4 x86_64 is codenamed "Xerus" and is built using the woofQ Quirky Linux build system, with the help of Ubuntu 16.04.3 binary packages. Thus, Xerus has compatibility with all of the Ubuntu repositories.
Quirky is a fork of Puppy Linux, and is mainly differentiated by being a "full installation" only, with special snapshot and recovery features, and Service Pack upgrades, though recently there is limited support for live-CD session-saving and "frugal" installation.
Version 8.4 has many architectural improvements and package upgrades, including new packages Sakura, Refind, EasyApps, PupControl, VTE and EasyShare. EasyShare is a simple "one top shop" for network file sharing and printing, using Samba and SSHFS. Upgraded applications include Pclock (0.8.2) and seaMonkey (2.49.1). The Linux kernel is now version 4.14.17

Quirky is shipped as an ISO file or a Flash-drive image file. Instructions to install are here:

Primary download site:

This is a third option, install scripts:

...for experts only.

To join in with discussion on Xerus 8.4, go to the Puppy Forum:

Have fun!

Tags: quirky

Busybox 1.27.2 compiled statically

January 25, 2018 — BarryK

The last time that i compiled Busybox statically, it was version 1.25.1, using Landley's Aboriginal Linux, chrootable root-filesystem. That was late 2016, and i have been using that up until now.

I wanted to enable some more applets in Busybox, 'nsenter', 'dnsd' and 'inetd', so went through the exercise again.

I downloaded the latest stable source, version 2017.02.09, of Buildroot, from here:

This defaults to using Busybox 1.27.2. I added my own 'busybox.config', and jamesbond's 'guess_fstype' applet patch.

Then ran:

# make menuconfig
# make uclibc-menuconfig
# make busybox-menuconfig
# make

I didn't change much. Chose target of x86_64 nocona CPU, and for uClibc turned on 'wchar' and 'locale' support.

There were a couple of fails. I had to replace /usr/include/limits.h in the host system (EasyOS Pyro64 0.7) with limits.h from Xerus64.

Then Busybox compile failed and I had to disable 'nfs' support for the 'mount' applet. I can live with that. It is probably something lacking in the uClibc configure options.

Anyway, got there. If any pup builders want the latest Busybox, statically compiled, with lots of applets, here is the PET (728KB):

EDIT 2018-02-09:

I reverted to the 1.25.1 busybox PET. Testing the above, something seemed not quite right (got a hang at bootup). When building with "make menuconfig", using the .config from 1.25.1, an incredible number of configure options were flagged as no longer valid, and maybe something has changed to cause the problem. I might have to advance the version number more gradually, and maybe go back to Landley's Aboriginal Linux as a precaution.

Another thing. The motivation to upgrade was to enable some more applets, including 'dnsd' (domain name server), however, it (dnsd) doesn't work. Really weird, but I did a search with google and it seems that "nobody" actually uses it. I have successfully used 'bind' and 'dnsmasq', so I think that I know what I am doing, regarding dns servers. The busybox dnsd does not respond to the port.

Tags: easy, quirky

Easy network printing with CUPS

January 12, 2018 — BarryK

I have been trying all day to setup printing over a small network, just two PCs running Easy 0.6.6, connected to an ethernet router (and to the Internet via wi-fi wan, to my mobile phone hotspot).

One PC, my "midi-tower", has a Brother HL-2040 laser printer connected via USB port. Local printing works fine. The other PC is my Mele "mini-pc", and I want to be able to print from it.

The problem is, I cannot get the "ipp" protocol to work. I have studied online documentation, and can get the client machine, my mini-pc, to see the remote printer, however when do an actual print, get the dreaded "Filter failed".

As stated, I have messed around all day, trying different things. Then, I found something that "just works", very simple. I would like to acknowledge "paulkerry" for this info:

Just a comment: there is a lot of outdated, vague, ambiguous and misleading documentation about CUPS online. For example, one "very official" site explained the format of the ipp protocol as:


...without explaining that only "hostname" and "printername" must be substituted, and the text "printers" must be left as-is. There wasn't even an example, nor was it properly explained how to find the printername.

Anyway, I did learn how to specify ipp properly, but got stuck at "Filter failed".

The method described by paulkerry works, so here is a little tutorial to explain how to set it up. Note, I plan to semi-automate this, by extending QuickSamba, which I plan to rename to EasyShare. Anyway, the tut...

1: Firewall

I ran the firewall setup on both client (my mini-pc) and server (my midi-tower) PCs, so that the CUPS port (631) is enabled. In this snapshot, I have also enabled Samba ports, but that isn't necessary for just printing with CUPS:


On the server-PC, just setup the local printer as you normally would, but tick some extra boxes...

2: Server PC

You need to have the cupsd daemon running and point the web browser at http://localhost:631. In Puppy/Quirky/Easy, you do this by running the "CUPS Printer Wizard":


A window will popup asking if you want to add a new printer, and you click "Yes", then you will get the CUPS web interface:

image on "Adding Printers and Classes", then the next window:

images each of those, 1, 2, 3 and 4. Do not miss "Change Settings". Probably "Allow remote administration" is optional, but I enabled it, as I was then able to bring up the CUPS web interface of the server-PC on my client-PC. Next window...

...well, anyone who has setup a local printer will be familiar with this. Continuing, as per usual, except an important checkbox to tick...

...the first two boxes are pre-filled. It is not essential, but useful, to fill "Location". And, you must tick "Share This Printer".

In the next window, you choose a driver...


And set some printer options...


That's it, the server-PC is setup. Before setting up the client, you will need to know the IP-address of the server. A few ways of doing that. Open a terminal and type "ifconfig", and you will see it -- in my case it is "":


In Puppy/Easy/Quirky, there is no need to edit the /etc/cups/cupsd.conf main configuration file, as it is pre-configured OK. Note, for this tutorial, I am running pristine EasyOS Pyro64 version 0.6.6.

Now for the client-PC...

3: Client PC

Over on my Mele mini-pc, setup is easy-peasy. I created file /etc/cups/client.conf...


...with content just one line, "ServerName <ip address of server>"

Finally, restart the cupsd daemon...


...and run "lpstat -t" to verify that the remote printer is found.

That's it, nothing more to do. If you ran an application and choose "Print...", the remote printer will be offered, in my case, my Brother HL-2040.

Also, the CUPS web interface of the server can be accessed from the client, by going to "" in the client web browser.

As stated, I have thoughts how this setup can be semi-automated, including automatic creation and update (if the ip-address changes) of /etc/cups/client.conf. Stay tuned.

Tags: linux, easy, quirky

Retrovol replaced with Aumix and Pnmixer

December 31, 2017 — BarryK

Retrovol is a combination audio mixer and tray applet. It has been working fine for me, until today.

Now that I am using a Radeon HD 6780 video card, suddenly Retrovol is broken. The icon is sometimes in the tray, sometimes not. When not displaying anything, there is still a space that responds to clicks. Sometimes though, it dies completely. Even though it may respond to clicks, the volume slider does not work.

A quick search on the Puppy Forum reveals that I am not alone;

What these people have not identified, is what video card they are using. Given that I have been using retrovol for years on different PCs and laptops without any problem, always Intel video, and suddenly broken when I have changed to a AMD card, well, it is too much of a coincidence.

So, Easy and Quirky have changed over to 'aumix' and 'pnmixer'. The former is a audio mixer, the latter a tray applet.

Which reminds me, my build of Quirky for the RPi had the same problem, retrovol was broken, and I used aumix and pnmixer.

Tags: easy, quirky

OpenGL hardware acceleration for AMD video card

December 31, 2017 — BarryK

I have posted that only had software rendering for OpenGL, for my AMD/ATI BART Radeon HD 6870 video card:

I compiled 'mesa' in OpenEmbedded without 'llvm'. I wanted to avoid llvm, due to it's size, as have done in some earlier pups. The problem is that some of the AMD/ATI mesa drivers require llvm.

The mesa drivers that require llvm are: r300, r600, radeonsi

However, I did read that r600 can be compiled without llvm, by the configure options:

--with-gallium-drivers=r600 --disable-gallium-llvm

Not so r300 and radeonsi, they need llvm, apparently.

I determined that my video card needs the 'r600' driver. I decided to include llvm, for the sake of others who might need the r300 and radeonsi drivers.

llvm can be compiled in OE, however, it is not configured properly, nor is mesa in OE configured properly -- for example, won't build the r600 driver.

So, I have built llvm and mesa in a running Quirky Pyro64 (0.6.2). The package 'elfutils' is required, can be installed from the PPM.

Here is how I compiled llvm, version 3.9.1 (with hints from LFS):

# mkdir build
# cd build
# CC=gcc
# CXX=g++
 -DLLVM_TARGETS_TO_BUILD="host;AMDGPU;X86" -Wno-dev ..
# make
# new2dir make install

Then mesa 17.0.2:

# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=x86_64-pc-linux-gnu \
 --enable-shared-dricore --enable-osmesa --enable-xa --enable-gallium-llvm --enable-shared-glapi \
 --enable-glx-tls --enable-dri --with-dri-drivers=i915,i965,nouveau,r200,radeon,swrast \
 --with-gallium-drivers=r600,r300,radeonsi --enable-dri3 --enable-gles1 --enable-gles2 \
 --enable-egl --enable-llvm-shared-libs --disable-omx-bellagio --enable-vdpau \
 --with-egl-platforms='drm x11'
# make
# new2dir make install

There was some uncertainty here, what drivers to put into "--with-dri-drivers" and "--with-gallium-drivers". I did what seemed sensible, though it did seem that some, for example "i965", could be moved to the latter. Some online examples have the drivers in both, which seems odd.

Some of the options are auto-detected, however, putting them in explicitly is good to check that the host has the required packages.

Yay, running 'glxinfo':

OpenGL renderer string: Gallium 0.4 on AMD BARTS (DRM 2.50.0 / 4.14.1, LLVM 3.9.1)

...that is, not using the "software rasterizing" anymore. I haven't been able to give any TLC for NVIDIA video, will have to get hold of an NVIDIA card to play with.

Tags: easy, quirky