T2 supports x32_abi

René has announced preliminary support for x32_abi in T2. He sent this email:

Hi all,
a little xmas and new year treat, maybe especially for the small binary embedded
and/or puppy folks:

I just committed some basic x86-64/x32 support glue to the t2/trunk.

X32 is x86-64 with 32-bit pointers, so still taking advantage of all the many more
general purpose registers and optimized calling convention, with less memory
and thus cache utilization (like we where running sparc32 user-land on sparc64
by default for this reason, too):


Not everything just builds yet (obviously not even upstream, e.g. no support for
valgrind or other low-level stuff yet).

This is very good news!
Awhile back, I got excited about x32, but it was a bit embarrassing as I misunderstood what it was all about.
But now, I can have a go at compiling for x32 in T2, and build a super-small and super-fast Quirky.

Note, this was my earlier, aborted, post on the topic:

Thanks for the Xmas/New-Year pressie René!
Posted on 8 Jan 2016, 7:56 - Categories: Quirky

Kernel module loading

In my previous blog post, I deliberated on the direction of Quirky and the merits of a full install versus frugal or live-CD:

A full install means that there is no need for an initrd. I see the initrd, or initramfs, as an unecessary extra step at bootup. I gave the ability to not have an initrd as one good reason for doing a full install.
Note though, other distros such as Debian and Ubuntu do have an initrd with a full install, a massive one. They throw in the entire collection of modules (which remain duplicated in the main f.s.).

I have rather wistfully thought that without an initrd, the kernel should be capable of automatically loading all modules, without need for udev and without needing to replay uevents. Yes, theoretically the kernel could be made to do that. It does everything required, such as automatically creating /dev device nodes, load firmware, and able to match module aliases to the actual hardware.

Yeah, except that this is more of a hopeful statement, rather than fact.
In theory, the kernel should be able to load all of the modules, without needing udev (or eudev or any other helper). Yes, except that it doesn't.

Booting Quirky Werewolf 7.4, 88 modules get loaded. I determine that by running "lsmod | wc -l" and subtracting 2. The script /etc/rc.d/rc.sysinit replays kernel uevents to achieve this. Puppy Linux has the same code and will load the same modules.

udev at bootup
We have to replay the uevents in our rc.sysinit script. Up until now, it has been rather complicated -- rc.sysinit has a mix of scanning through /sys and running "uedadm trigger ...". Messy. Actually, just this alone will load all the modules (after launching udevd):

udevadm trigger --action=add

...in fact, it loads one-more than before, 89 modules. Years ago, when I was last investigating this, I seem to recall problems with such a wide sweeping replay -- maybe it was slow, or hung. Anyway, running eudev 1.10 on my laptop now, it works, and fast.

I tested this, which it seems will narrow the replay to uevents that do not already have a loaded driver:

udevadm trigger --action=add --attr-nomatch=driver

Then I read somewhere that doing it in two steps is good:

udevadm trigger --action=add --attr-nomatch=driver --type=subsystems

udevadm trigger --action=add --attr-nomatch=driver --type=devices

The main problem with figuring all of this out is the very poor documentation.
I just happened to come across a post that described "--attr-nomatch=driver". I read some posts that you should not use "--action=add" -- yet I have to, otherwise most modules do not load.

The idea of not using udev at all at bootup, for coldplug module loading, is just not the way the kernel is designed these days. We might as well launch udevd and run "udevadm trigger ..." at bootup, as the daemon is then in place for future hotplugging.

Bootup without udev
Just "thinking out loud" here. We could take the kernel conceptually back a few years, and configure it to use an external "uevent helper" script to load modules (by calling 'modprobe').
One reason this kind of thing was done away with, I think, is because of the huge number of parallel processes that can be created, as the kernel spews out uevents.

I decided to experiment. The 4.2.6 kernel in Werewolf 7.4 is configured without support for a "uevent helper", so I compiled 4.2.8 and enabled that. Set it to /sbin/hotplug.

I got it working, kind of. The problem is, I could not get it to load anywhere near 88 modules.

Udev is here to stay.
Posted on 18 Dec 2015, 7:40 - Categories: Quirky

Where am I going?

I have been thinking about Quirky Werewolf 7.4. The direction I have taken is to make Quirky more Puppy-like. That is, improved frugal installation, more viable ongoing running from live-CD, even support for multiple SFS files.

This has been done from scratch to be simpler than Puppy. So, a reimplementation of the concepts in Puppy, but simpler underlying scripts. Still using a zram for live-CD and frugal, which is different from how Puppy does it.

However, all of this Puppy-like behaviour is what I got away from in the original Quirkies. They were full installations only.

The reasons for that original decision were:

1. No initrd
A full install means that there is no need for an initrd. I see the initrd, or initramfs, as an unecessary extra step at bootup. It is complicated, slows down bootup, and file duplication bulks up the size of the distribution.

2. Speed of solid state drives
The whole Puppy running-in-RAM thing is (mostly) due to the slowness of reading from drives. Mechanical magnetic-platter drives specifically, but also solid state drives that are choked via slow serial interfaces such as USB2.

I saw the future as computing devices with internal solid-state drives, with very fast read times. Thus, a full install will be fast, and there will be nothing (such as SFS files) cluttering up the RAM.

3. Optical drives on the way "out"
More and more computing devices are being sold without an optical drive. They are still hanging in there with desktop PCs, however, increasingly they are becoming legacy devices that only serve an occasional use.

My next computer will not have an optical drive. Actually, I own an external USB optical drive, that will serve my needs on the rare occasion that it will be needed.
My next laptop, that I need to tote around, including take as cabin luggage on flights, will not be burdened by the extra space and weight needed for an optical drive.

Summing up
All of the above, is, I think, a good argument for why I created Quirky. The direction it is going now, introducing Puppy-like features, is, well, not appropriate.

Let Puppy continue, doing what Puppy does well. I reckon that I will take Quirky back to full install only.

Future thoughts
In 2016, I am thinking of purchasing a new laptop. With solid-state drive and touch screen. The latter is another thing that may become pretty much standard.

This means that I will need to develop Quirky with a touch-enabled user interface.

These are my thoughts about the direction of Quirky, but not necessarily what I will end up doing.
Who knows? -- maybe Canonical will finally deliver Ubuntu Touch with true convergence, and it will be so awesome that I will forget all about Quirky...
Posted on 18 Dec 2015, 6:56 - Categories: Quirky

Quirky 7.4 released

This is a new release of Quirky, in the "Werewolf" series, which started with version 7.3, followed by bugfix releases 7.3.1, 7.3.2 and 7.3.3.

Read the release announcement for 7.3 here:

A concise announcement for 7.4:

Quirky Linux version 7.4 is released.This is the latest in the "Werewolf" series, built with binary packages from Ubuntu 15.10 (and compatible with the large Ubuntu package repositories), that started with version 7.3, followed by 7.3.1, 7.3.2 and 7.3.3 bugfix releases.
Version 7.4 brings major changes in the installation, save-session and init (in the initrd) scripts, offering more flexible running modes for the live-CD and frugal installations, and simpler installation.
The package selection is mostly the same as 7.3.3, except that the VLC media player has been dropped in favour of XINE, and bugs in some packages are fixed.

A full announcement and release notes can be found here:

Read about how to install Quirky here:

Primary download:

Note that the installer script offers to download the .iso file, if not already, however it does so from ibiblio.org which is very slow. Recommend download from a mirror site, such as nluug:
Then run the installer.

There are a couple I know of:

1. Xine hangs. I switched over from VLC as XINE plays my video test files much better. However, if XINE is closed via the menu, it leaves behind a zombie process that cannot be killed, and even prevents shutdown!
Always close XINE by clicking the close-box at top-right of window.
If anyone can figure that one out, please do!

2. If you use the installer to do a full install to a partition, at first bootup a popup message tells you that you have booted from a live-CD. Harmless message, just an annoyance, and I will fix it.

Please go to this thread in the Puppy Forum, for all bug reports and discussion:

Extra notes
I have only released a 64-bit build, so Quirky will not run on some early Pentium CPUs that are 32-bit only.
Posted on 10 Dec 2015, 18:11 - Categories: Quirky

Quirky Installer, initrd changes

Quirky Installer
I have made major changes. Simpler to use, I think.
The first window, for choosing 64bit/32bit CPU, amount of RAM, and BIOS/UEFI, has been removed.

A new feature is frugal install to drive. The Installer offered frugal install to partition, however, I noticed interest in the forum Quirky feedback thread, for frugal to a drive, such as USB Flash stick.

I have deprecated the .usfs.xz file, will now only ship a .iso file. The Installer only uses an iso file now.

Full installs do not use a initrd, only frugal.
I have added extra functionality to the 'init' script in the initrd, to support possible future requirements. It has grown to 199 lines.

I thought about offering more "Puppy like" features, but simpler. Instead of the 1000+ lines of the init script in Puppy, Quirky's init is only 199 lines.

I have changed the way init works. It now defaults to scanning the drives, looking for installed files. This can be bypassed later, either by "install_specs" on the kernel commandline, or remaster the CD.

There is a new file, 'Q_ID', that can be placed in a frugal installation folder, for the live-CD to find the correct folder.

The init script supports "half-full" installation, part frugal, part full. That is, there is a q.sfs, but the saved session occupies the entire partition. Haven't implemented that in the Installer yet.
This is a Puppy thing.

The init script will load any extra SFS files it finds in the install folder. Another Puppy thing, but lacking all the management functionality in Puppy, such as automatically fixing the menu when a SFS added or removed.
I put this capability into the init script, in case anyone really wants to load an SFS file.

One extra thing. The 'popup' utility is misbehaving in Quirky Werewolf. The timeout feature wasn't working. This is in the 'pup-tools' package. Fixed.
Posted on 8 Dec 2015, 8:53 - Categories: Quirky

Pages: [1] [2] [3] [4] [5] ...