site  contact  subhomenews

Gxlat language translator

July 28, 2018 — BarryK

This is brilliant! Puppy Forum member vovchik developed this around 2011/2012, however, Google changed to a paid service.

Recently, vovchik has figured out a way around this, so we can still use it for free, using a special script named 'trans'. originally, Gxlat had compiled binaries, however, now is just two shell scripts, and gtkdialog and gxmessage are used for the GUI, which we have in all the pups.

Here is the forum thread:

The latest PET, posted 10 July 2018, has some problems. The file was corrupted, but I was still able to expand it, the icon is missing from /usr/share/pixmaps, and it presents itself as version 0.2b.

There is an earlier version that is 0.3, so I have created a PET and it presents itself as version 0.4. I put in the icon, and modified the gxlat.desktop file slightly -- one thing, put it into the Document menu (sub-section utility), as this is less crowded.

Here is the PET (45KB):

This will be in the next release of EasyOS and Quirky. This is really nice vovchik, much appreciated!

Tags: easy, quirky, linux

aarch64 packages imported into woofQ from OE

July 24, 2018 — BarryK

I have compiled a heap of packages in oe-qky-src, my port of OpenEmbedded, cross-compiled on a x86_64 host PC, for a aarch64 target.

These packages have been imported into woofQ, and uploaded. Here they are:

What I would like to do is boot a aarch64 Easy/Quirky distro on my RPi3. Want to get it going quickly, and the easiest way will be to use the Bamarni Pi64 Debian-based aarch64 distro:

...that is for the RPi3 B-model, which is what I have. There is a later B+ model, which the Bamarni Pi64 currently doesn't work on, but another chap has a fork of Bamarni Pi64 that does:

It should be possible to replace the Bamarni Pi64 files on the SD-card with the Quirky build. My build doesn't have any hardware acceleration, just the framebuffer driver, software-rasterized openGL, etc., but it will get me going.

Will post a progress report soon!

EDIT 20180725
Yay, got a desktop at second bootup. Needed a little fix, wasn't loading the Xorg fbdev driver. Lovely, sound works on my TV (using HDMI input),

So far, just one problem, the QuickSetup window renders with everything upside-down. That is, the "OK" button is at the top of the window. It is still usable. I do recall this problem from ages ago, but not the solution. QuickSetup uses gtkdialog for the GUI rendering.

Tags: easy, quirky

EasyOS version 0.9.5 released

July 24, 2018 — BarryK

EasyOS is an experimental distribution, and continues to evolve. Version 0.9.5 is a snapshot of the current ideas, probably with some rough edges, and likely to change soon.

I have been playing with using the Xephyr nesting X server in which to run containers, even to the extent of running an entire desktop in a Xephyr container. This experiment is primarily what 0.9.5 demonstrates.

At first bootup, you will see the usual "www" and "console" icons (with superimposed lock symbols) which run SeaMonkey and Sakura (terminal emulator) in containers:


...however, there is a new icon, "desk". This runs the entire desktop in a container. Click on it, and the screen will flip to the new desktop:


...looks very similar! However, it is all inside a container. Appropriately, the drive icons are not there, as it is a locked environment. There are some details to be sorted out, for example the "Shutdown" entries in the menu need to be removed.

The other two, "www" and "console" icons on the main desktop (top picture), run SeaMonkey and Sakura on the main desktop. There are using Xorg. In summary, an app using Xorg appears on the main desktop, and using Xephyr will appear on the alternative "containerized desk".

When viewing the Xephyr "containerized desk", hit Alt-F6 to flip back to the main desktop. On the main desktop, click the "desk" icon to flip back to the Xephyr desktop.

Not wishing to stretch the user's conceptualization too much, but containerized apps can be made to run on either the Xorg or the Xephyr desktops, in their own containers. For example, the container "www" icon on the main desktop can actually launch SeaMonkey on either desktop -- if on the Xephyr desktop, SeaMonkey will be in its own container, with its own separate security settings, not the same container as the Xephyr desktop.

On the otherhand, if you were to run the normal SeaMonkey in the Xephyr desktop, it will be running in the same container as the rest of the Xephyr desktop.

Anyway, it is here for anyone who wants to play with it:

It is an image file to be written to a USB-stick. There are many utilities for doing that. If you need some instruction, read this:

If you wish to read-up on what EasyOS is all about, look here:

Discussion on EasyOS is happening at this thread of the Puppy Forum, for 0.9.5 start reading from here:

Have fun!

Tags: easy

Nheko Matrix chat client

July 18, 2018 — BarryK

Purism are using Matrix for chat forums, including for the Librem 5 phone:

So, decided to give it a go. There are various Matrix client apps, and I compiled Qt5-based Nheko:

The PET for EasyOS 0.9.5+ (not yet released) is here:

Dependencies are 'olm', 'libsodium', 'liblmdb', which are also PETs. Also 'boost' version 1.66, which is in the upcoming Easy 0.9.5.

Nheko, at startup, offered to register, where a username, password, and "Home Server" can be entered. For the latter, I entered "", and a captcha came up in the browser to verify that I am a human.

After starting Nheko, I was in my own "room", "@<myusername>", but unable to change out of it. Nheko is lacking some features, but is under rapid development.

I logged in at the online browser Matrix client:

Logged in, I was able to ratify a user-agreement, that then allowed changing rooms. I was also able to personalize my account, with email and avatar, which cannot be done in Nheko.

Started up Nheko, logged in, then hit the "+" icon and was able to change rooms. Chose "", and yay, there it is!

Hmmm, perhaps it is easier just to use the online client.

Tags: linux, easy, quirky

petget0, a single container runs all of EasyOS

July 07, 2018 — BarryK

As I posted recently, I have been rethinking how containers are implemented in EasyOS. Overall, I want to make them simpler to use.

In the previous post, I explained that X server security in containers has been improved, and introduced a new container named 'petget0':

The basic idea to make container usage extremely simple, is to do away with the need to create containers for running individual apps. Instead, there is just one container, pre-created, and all apps can be run in it.

The concept is simple: the petget0 container is a complete EasyOS, that does everything the main EasyOS does, in a separate desktop, and you can toggle between the container desktop and the main desktop. It is two separate operating systems, the difference being that the containerized one is highly locked down.

The name "petget0" is an arbitrary choice. After bootup, in the main desktop, you can see the petget0 container files here:

/mnt/wkg/containers/petget0/container you can poke around in the container as much as you want. You are "outside" the container, in the main desktop, running as root, so have unlimited power.

Now, to flip into the containerized desktop...

In the JWM tray, you will see a process named "containerized apps", click that, and you will be flipped into the containerized desktop. This is what you will see:


The containerized desktop is running pekwm window manager and lxpanel tray. Everything runs as per normal, as you can see in the above snapshot. Everything, even the PETget Package Manager, so you can install packages -- these will install into the petget0 container, which is completely separate from the main desktop.

To flip back to the main desktop, press ALT-F6, that is, hold down the ALT key and tap the F6 key.

Note, I have set it up so that when EasyOS is booted up, it automatically flips into the containerized desktop. Because, it is likely that this is where you will mostly like to be.

Now for some technical details...

Technical notes

It is useful, for users and developers, to know how all of this is achieved "under the hood".  At bootup, the main desktop starts in the normal way, with Xorg, running JWM window manager and ROX-Filer for the desktop icons and wallpaper.

In /root/Startup, there are various scripts that run after X has started. To follow the trail from the commandline, /usr/bin/xwin is run, which launches Xorg and /root/.xinitrc. The latter launches various things, including /usr/sbin/delayedrun and finally JWM.

It is /usr/sbin/delayedrun that runs the scripts in /root/Startup. These are mostly applets that run in the JWM tray, such as battery-status and volume-control. It also runs /root/Startup/xephyr.

/root/Startup/xephyr launches the Xephyr server, then starts the container:

 Xephyr :1 -fullscreen -title "$TXT1" -name "xephyr" -zap -dpi "$DPI" -nolisten tcp &
sleep 0.5
#next, run window manager and panel inside petget0 container...
ec-chroot petget0 pekwm-lxpanel

Xephyr is started fullscreen, so a black screen will appear. I have only tested this on my midi-tower PC, with Intel video, so I don't know if this fullscreen startup will work with other video hardware. I opted for fullscreen, as starting in a window has some problems.

Look at /usr/local/easy_containers/ec-chroot to see how it starts the container and launches it. Following the trail, the /ec-run script will run first in the petget0 container, which will then run /usr/bin/pekwm-lxpanel. The latter will launch pekwm and lxpanel.

pekwm, lxpanel

I chose these two rather than JWM, as had some show-stopper problems with running the latter in Xephyr. Though, that was when I was using Xephyr as a resizeable window. Now running fullscreen only, will revisit JWM.

pekwm and lxpanel have been compiled in my fork of OpenEmbedded (commits July 6, 2018):

I used a very old version of lxpanel,, partly because it is simple and does the job, and secondly because Puppy Forum member plinej created some patches for that version. I modified those patches to suite EasyOS, and they are in the github repo. What the patches do is add paths to where icons are kept in EASYOS, and to automatically load from the XDG .desktop files -- so no external menu converter is required, just restart lxpanel.

I am unfamiliar with pekwm and lxpanel, getting up to speed. With pekwm, a right-click brings up a menu, generated by the 'xdg2pekwm' uility, but it looks awful. If anyone has experience with pekwm, your input will be welcome!

Network access

I have not unshared the network namespace. The ultimate security would be to do so, but this is a maybe for the future. So, apps in the container use the main system Internet connection. This requires /etc/resolv.conf to be copied into the container, and this is done in the ec-chroot script.

However, it is likely that the network connection is not established at bootup, when the petget0 container is started, so /etc/resolv.conf is empty.

There is a fix for this, service-script /etc/init.d/petget0. This script runs when there is Internet connection, and copies /etc/resolv.conf into the container.

EasyOS has pup_event service management, my own creation to start and stop services when dependencies are met. Examine scripts /etc/rc.d/ and /etc/rc.d/rc.services_ipc, and file /etc/eventmanager, to see how pup_event service management works.

Mount namespace

petget0 is pretty well locked down, though there are still some things that need to be done.

I would like to unshare the mount namespace, however, SeaMonkey crashes. But, only when accessing https sites. This is something that needs further investigation.

petget0 configuration file currently has these settings:

#For security, unshare these namespaces:

....the ultimate aim is to set all of them to "true".

User zeus

There is a user:group named zeus:zeus. This can be used in containers to lock-out access as required. In EasyOS, like Puppy Linux, the user runs as root, having unlimited rights. In a container, the user is still "root", but with limited rights. Examine the ec-chroot script, and /ec-run to see how Linux Capabilites is used to restrict the rights.

The ec-run script is an example. It is owned zeus:zeus, with 700 permissions, so only zeus can use it. The password assigned to zeus is the same as that given at bootup, so only you know it.

Running as "root", in a container, does have one big advantage: copying files to and from the main root filesystem. It becomes a non-issue, no need to be concerned with file ownerships and permissions. That is, if, in the main desktop, you copy a file into the petget0 container, perhaps something that you want to open by an app in the container, no problem with it being owned by root, the app in the container will have full rights over it.

Enough rambling on, this post has become too long. But, it is good to document as much as possible. For me too -- I look at what I did a couple of years ago, and can't recall how it works, so I also need these posts to refresh my memory!

Tags: easy

Improved X server security in Easy Containers

July 06, 2018 — BarryK

I am gradually ramping up the security for Easy Containers. Most recently, attention has been given to the X server that is used in a container, and the ways in which it can be accessed. Here is a snapshot of the latest Easy Container Management (see Filesystem menu):


Now, there is a choice of Xorg or Xephyr X servers. The latter is a nested server, which outputs to its own window within the main Xorg desktop. Using Xephyr in a container is considered to be more secure.

There are four ways in which an application can "connect" to the X server: tcp port, abstract socket, pipe or Unix Domain Socket. Both Xorg and Xephyr are started with "-nolisten tcp", thus disabling that option.

To see where the servers are launched and the commandline, for Xorg, see /usr/bin/xwin, for Xephyr see /root/Startup/xephyr (in the upcoming EasyOS 0.9.5)

The other three have arguments for an against. For EasyOS 0.9.5, I decided to launch Xorg with "-nolisten tcp -nolisten local", thus in the case of Xorg there only remains the Pipe and Unix Domain socket options.

Anyway, the "?" help button that you can see in the above snapshot, has useful summaries of each option.

To see the choices applied to a container, there is a configuration file. EasyOS 0.9.5 has a new container named "petget0", and the configuration file is here:


Printing the X choices:

#Connect to X by abstract socket, pipe, or unix domain socket (abstract|pipe|unix)...
#Use Xorg or Xephyr server (xorg|xephyr)...

As I posted recently, I wanted to rethink some of the basics. That will be ongoing, however, I am now looking at implementing containers in a different, simpler, way. Simple, so that the above Easy Containers Management GUI app will never even be needed to run. So the user will not have to get involved in the details of creating a container and making those technical security choices.

Will explain more soon...

Tags: easy

coreutils cp utility broken compiled with musl

July 02, 2018 — BarryK

In the latest build of EasyOS I am getting file copy errors when using 'cp'. This build is using a statically compiled coreutils single-binary (with applets symlinked to it, just like busybox), that was compiled in OE.

Here is an example:

# coreutils --coreutils-prog=cp -a -f /mnt/sdb1/projects/woof/woof-project/builds/quirky-out_amd64_amd64_oe_pyro_easy/sandbox3/rootfs-complete/var varX
coreutils: failed to preserve ownership for varX/local/pupdial/isp: Not supported

"isp" is a symlink to a folder, target with permissions '777'. That is what causes the error message, though the copy does succeed.

Alright, trying busybox cp:

# rm -rf varX
# busybox cp -a -f /mnt/sdb1/projects/woof/woof-project/builds/quirky-out_amd64_amd64_oe_pyro_easy/sandbox3/rootfs-complete/var varX

...good, no error message.

OK, compiling coreutils with uClibc. I used a very old uClibc, refer to, and bumped coreutils to 8.30. Have a static single binary, test it:

# rm -rf varX
# coreutils --coreutils-prog=cp -a -f /mnt/sdb1/projects/woof/woof-project/builds/quirky-out_amd64_amd64_oe_pyro_easy/sandbox3/rootfs-complete/var varX


Grumble, grumble, this reinforces my dislike of musl. I did a search on the Internet, this bug has been reported over several years.

Tags: easy, oe

Xorg .Xauthority is extra protection

July 02, 2018 — BarryK

I don't know of any pups that have bothered with this, however, ~/.Xauthority is an extra level of security, that I have now implemented in EasyOS.

I am playing with running X apps in containers with the Xephyr nested X server. In /usr/bin/xwin, I now launch Xorg with "-nolisten tcp -nolisten local", which prevents any app to connect to the Xorg server via a TCP port or what is called an "abstract socket".

That leaves /root/.X11-unix/X0 a Unix Domain Socket. This is how apps will communicate with Xorg.

Inside a container, it is still possible to connect with Xorg :0, even though apps inside the container cannot "see" /root/.X--unix/X0 in the host. This can be done with 'socat'. Do this in the host:

# socat -ly -d -d TCP-LISTEN:6000,fork,bind=localhost UNIX-CONNECT:/tmp/.X11-unix/X0 &

Then in the container:

# export DISPLAY=localhost:0

However, Xorg itself is considered to have many security weaknesses, and one step-up to improve security is to use Xephyr, which is a nested kdrive X server. I am running this on DISPLAY :1, launched in the host,

Putting that aside, while reading up on X xecurity, it seemed to me that it will be a good thing to implement /root/.Xauthority. A "cookie" can be placed in this file, and any other computer that wants to connect to our local Xorg must have a matching cookie in its own ~/.Xauthority file.

So, /etc/rc.d/rc.sysinit now has this, just after the hostname is autogenerated:

 xPW="$(< /dev/urandom tr -dc 'a-f0-9' | head -c32)"
echo -n '' > /root/.Xauthority
xauth -f /root/.Xauthority add ${PUPHOSTNAME}/unix:0 . ${xPW}

The hostname may also be changed in QuickSetup, /usr/sbin/quicksetup, which calls /usr/sbin/hostname-set. So, the same code is now in hostname-set, just after writing to /etc/hosts.

I think that I have got it right, not verified yet! If I haven't, if the cookie has the wrong hostname, then the desktop will become non-functional.

There is something called "FamilyWild", which basically enters a wildcard in place of the hostname. That means the cookie will work for all local displays, regardless of what the hostname is. Unfortunately, I want to distinguish between :0 and :1, whereas the docs state that FamilyWild applies to "all displays".

Here is some further info:


A special connection family (FamilyWild, value 65535) causes an entry to match every display, allowing the entry to be used for all connections.

For the record, I found this on the Internet, a way to convert a cookie to FamilyWild:

# touch test1
# xauth nlist :0 | sed -e '/^..../ffff/' | xauth -f test1 nmerge -
# xauth -f test1 list

Tags: easy