site  contact  subhomenews

bcm popup messages

July 16, 2017 — BarryK
BaCon Cairo Messenger (bcm) is a popup message box for shell scripts, written by forum member vovchik.

Oh dear, not another one! I am losing count of how many there are already in Quirky. Well, we have these:

pupmessage, xdialog, gxmessage, xmessage, popup, gtkdialog, yad, pupdialog, gtkdialog-splash

So, why not have one more!

I was reading about MRUF created by musher0, a PET to list most-recently-used files. His PET has three binary executables, so I thought why not put those binaries into Quirky.

Starting with bcm. This is a very pretty popup messenger thingy, written in BaCon. Vovchik posted about it here:

I have compiled it and created a PET. It will be in the next Quirky. It is /usr/bin/bcm, only 39KB. I also included the source in the PET, /usr/share/doc/bcm/bcm.bac and a help file, bcm.txt.

Tags: quirky, linux

Take-a-Shot screenshot utility

July 16, 2017 — BarryK
Quirky 8.1.94 has two screenshot utilities, and old one, mtPaint-snapshot, and one created by 01micko: Screeny.

Yesterday, musher0 informed me that there is a very good screenshot utility named Take-a-Shot, created by SFR.

I looked, here it is:

Tried it out, it sure is cool. So, it is going into the next Quirky.
I will leave the others in, so users will be spoilt for choice. But, they are so tiny, doesn't matter.

Tags: quirky, linux

GetFlash get Flash Player fixed

July 16, 2017 — BarryK
Forum member shinobar originally wrote GetFlash. Quirky Xerus 8.1.94 has version 1.5-4b, but testers have reported it no longer works, that is, fails to download the latest Adobe Flash Player.

Fortunately, some of the guys, rerwin, Geofrey and Sailor Enceladus, have continued work on it. The latest is 1.7-1:

I have tested it, it works. This will be in the next Quirky.

Note, it has an optional new feature, created by Geoffrey, to auto-update the Flash Player. It defaults to off, but if you want to try that feature, note that sszindian reported that it locks up SeaMonkey:

I don't know why it would lockup, unless the update is happening after SeaMonkey has been started.

Tags: quirky, linux

Puppy versus Quirky

July 15, 2017 — BarryK
A tester of Quirky Xerus64 8.1.94 (8.2beta), has complained about the lack of a "pupsave" file, and slow shutdown.

Someone with a Puppy background needs to be aware that Quirky has some philosophical differences from Puppy, and be prepared to embrace them.

Quirky is intended primarily to be a full installation. For other distributions, such as Ubuntu, Debian and Slackware, a full install is all they offer. Basically, a full install just means that the distro occupies an entire partition, and it has to have a Linux filesystem, such as ext4.

A full install may or may not have an initramfs. This is a mini-Linux that runs in RAM before the main distro partition is started up. Quirky does not have a initramfs. Debian for the desktop does, for the Pi doesn't.
The reasons for and against an initramfs are a topic for another time!

Quirky's full install has a fundamental difference from other distros, due to the ramdisk-based snapshot/recovery/rollback mechanism, called "easyinit".

Quirky is deployed as a live-CD ISO file, but this is not as flexible as Puppy. Puppy has several modes, known as PUPMODEs, one of which is, running from live-CD, to have a "pupsave" file mounted as a layer in the aufs layered filesystem.
What this means is that all changes get automatically and immediately saved to hard drive. The downside to this is that it is limited by the size of the pupsave file, but then, if you make it big to start with, say 5GB, then you are good to go for awhile.
Ditto for a frugal installation -- this is similar to a live-CD in that Puppy can also have a pupsave file.

Quirky live-CD and frugal installation run totally in RAM. There was a philosophical choice made not to use a pupsave file. One reason is for those people who want to be as invisible on the Internet as possible, or as secure as possible. any changes happen in RAM only. The user can choose to save the current session at any time, by clicking the "save" icon on the desktop. But a security-conscious user may choose to do that only when there is some change, such as Internet-setup, or a package installed.

Note though, Quirky can be configured to bring up the session-save window at every shutdown, so you can decide whether you want to save the current session or not.

There two limitations to consider with this totally-running-in-RAM situation:

One is the size of RAM. My laptop has 4GB of RAM, however Quirky assigns about 5.3GB working space -- this is because zram compression is used. So that's how much space you have for installing packages, caching, etc. Though, Quirky dumps all caching in /var at shutdown, to save space.
So, if you have a reasonable amount of RAM in your PC, you are pretty much OK. If you download files, you would do that to the hard drive, so as not to bulk up your session in RAM -- so you do need to have that awareness.
There is a storage icon in the tray that will start flashing if RAM space is getting low.

Two, as everything is running in RAM, when you save a session to hard drive (or external drive), the session has to be copied in its entirety to the save-file. In Quirky, the save-file is named s.sfs, and it is a squashfs filesystem. And yes, if at any time you want to see your saved files, just click on s.sfs and you can view the contents.
Saving a session is done by the 'mksquashfs' utility, and the time this takes depends on how much there is to save. It starts off just a couple of seconds. If your session grows to say 5GB, then a save may take a minute.

There are some future possibilites for keeping the session small. For a frugal installation, there is q.sfs (all of Quirky) and s.sfs. It is possible to transfer installed packages out of s.sfs, to q.sfs. It could even be done when the package is installed.

In fact, I might do this soon, as it is easy to implement. When you click on the "save" icon, Quirk could detect if you have installed packages and offer to move them permanently into q.sfs. That frees up your working space in RAM, and s.sfs stays small.
This will even work with a live-CD, not just a frugal installation.

Regarding other interesting ways of running Quirky, I am exploring those in the latest branch, Easy Linux.

Tags: quirky, linux

Xorg Wizard partly broken

July 14, 2017 — BarryK
Testing Quirky Xerus64 8.1.94, I have a problem. Exit from X to the commandline, type "xorgwizard".

This enables the user to make manual choices, such as which video driver to use. For example, Xorg might autodetect and use the 'intel' video driver, but you might prefer to use the 'modesetting' driver.

The wizard offers a choice of drivers. On my laptop with hybrid Nvidia and Intel graphics, The drivers that I expect the wizard to offer are: vesa, modesetting, nouveau, nv and intel.
Assuming those Xorg drivers exist, many distros don't have 'nv' anymore (it is an unaccelerated Nvidia driver).

However, the wizard only offers me vesa and modesetting.

The wizard, which is script /usr/sbin/xorgwizard-cli, runs "Xorg -configure" to probe for various things, including what drivers are appropriate.
What I have found over the years is that "Xorg -configure" has provided less information. Now it provides no information at all (running Xorg 1.18.4).

It would be so nice if the Xorg developers remove an option that now does nothing!

There are links that comment on this lack of info provided by "-configure", such as the comment "X -configure is a virtually useless anachronism":

...actually, no, it is still useful, or rather would be if it worked.

Anyway, I am going to have to do a big update to xorgwizard-cli.


Quirky Xerus64 8.1.94 released

July 14, 2017 — BarryK
This is a beta release, the final will be version 8.2. The previous release of Quirky Xerus64, for PCs with 64-bit CPUs, was version 8.1.6, in January 2017.

Since then, I have mostly been working on other things, such as the experimental container-friendly Easy Linux.

I have, however, been aware of outstanding issues with 8.1.6. After deciding recently to work on a new version of the Quirky Xerus series, many things have been upgraded and fixed.
In particular, I found that the overlay filesystem is broken -- all prior releases use aufs, but for 8.1.6 and other builds around that time and since then, have used overlay filesystem, also known as "overlayfs".

Actually, I was not aware of the problems with overlayfs, as I use Quirky on a daily basis as a full installation, which does not use an overlay filesystem. In Quicky, only the live-CD and frugal installs use an overlay f.s.

Quirky Xerus 8.1.94 has returned to aufs, and it "just works".

There is a brand new theme, here is a snapshot:

I tested a selection of videos, comparing VLC and Xine, and found the latter to perform better. For example, Big Buck Bunny at 2160p had missed frames and disintegration, whereas Xine played it perfectly. So, 8.1.94 has Xine-UI for multimedia.

There are two options to download, an ISO live-CD, and an image for a 8GB (or bigger) USB Flash stick.

Download from here:

Instructions for installing:

The devx and kernel-source PETs (334M, 146M):

Feedback is welcome at the Puppy Forum:


fsck at bootup improved

July 13, 2017 — BarryK
Quirky is in one respect very different from Puppy, in that, after bootup, the first script /sbin/init, has the option of continuing to bootup (by executing /bin/busybox init), or switch_root to a ramdisk, where various diagnostic and maintenance operations can be performed. For example, a fsck of the installed partition.

The way this differs from Puppy, is Puppy can do a fsck earlier, in the initramfs. However, a normal full install of Quirky does not have a initramfs.

Testing on the Pi3, /sbin/init failed to switch_root to the ramdisk. It is a strange failure, but I think that I have fixed it. Have put the fix into the script, haven't tested on the Pi yet.


Fixing Quirky save-session

July 12, 2017 — BarryK
Testers of Quirky Xerus64 8.1.6 experienced issues with saving a session in a live-CD or frugal installation.

The good news is that I fixed one show-stopper bug. It was to do with an incorrect path when using overlay instead of aufs.

The bad news is that I have hit another show-stopper bug, that seems to be a fault in overlay filesystem.
I am running kernel 4.11.9, so very recent overlay driver.

Booting the live-CD, have a zram on top, the read-write layer, and q.sfs on the bottom, the read-only layer.
When I tried to run "rm -rf <folder>" it spat out lots of errors about directories "not empty".

I googled, and found people reporting this error when using btrfs, or overlay.
btrfs I expect, it is flakey.

This is one of the overlayfs reports:

OK, I am going to compile the 4.11.9 kernel with aufs, see if that fixes it.