site  contact  subhomenews

Is ChromeOS the way to go?

July 20, 2021 — BarryK

I have been wondering about this for some time. My understanding is that ChromeOS was originally designed for a permanently online computer, not really for running off-line. I haven't closely followed development, but apparently that changed, allowing off-line use.

Then in 2016 Google announced that ChromeOS would be supporting Android apps:

They haven't stopped there. In 2018, Google announced that ChromeOS would be supporting Linux apps, a project named "Crostini", via a Debian-based virtual machine:

That was when I started to pay attention to ChromeOS development. It seems that Linux is a terminal interface, however, GUI apps can, apparently, be installed. Here is one guide, that explains how "Gnome" apps can be added to the ChromeOS package manager:

But how much of this is hype? What is the reality? This article, published Jan. 11, 2021, has some revealing statements:


And in the last two years, Linux has improved by leaps and bounds and it’s almost stable to use.


Also, keep in mind currently, Linux on Chrome OS does not support hardware acceleration so the performance is slightly choppy.

...I would have thought that depends on the GPU. Perhaps computers with Intel GPUs would have hardware acceleration? A bit of online reading, it seems GPU acceleration, using openGL, is available, at least for recent Intel GPUs, but a couple of reports it is troublesome. Obviously a work-in-progress, that hopefully will improve.

Gimp, LibreOffice, Inkscape, apparently run OK, and particularly interesting, so do Windows apps, via Wine. I see can even run Windows 10 in a virtual machine.

This certainly is interesting!      

Tags: linux

Grub2config replaces Grub4Dos

July 14, 2021 — BarryK

This is great news! 'shinobar' is an old-timer. He joined the old Murga Puppy Forum in 2009, and has created PETs that have been important components of Puppy, including Grub4dos GUI, and SFS loader. EasyOS has his Grub4dos PET, in the "Setup" menu.

He is a member on the new Puppy Forum, but has kept a low profile. The great news is that he is working on a replacement for his old Grub PETs. Forum thread here:


Grub4Dos does not support GPT/UEFI system, which is new standard of the recent PC's. Grub2Config is a script installs the grub2 boot loader and makes the menu automatically probing intalled systems same way as the old Grub4DosConfig, enabling multiboot with Windows, Ubuntu and etc.. It supports both legacy MBR system and new GPT/UEFI. Also supports UEFI Secure boot thanks to the Gyrog's MOK manager.

It is still under development, but very promising indeed.     

Tags: linux

Attempted to compile Paragon NTFS driver

May 21, 2021 — BarryK

I posted yesterday about a technique to automatically resize the save-file in Puppy Linux:

...the post by 'telcoM' mentions that for automatic shrinking of the save-file, the underlying filesystem must support "hole punching". The ext4 driver does, that's good, however for NTFS it looks like will require the new NTFS driver from Paragon.

Paragon has submitted it for inclusion in the Linux kernel, but it hasn't made it in yet. You can see the submissions from Alexanda and Konstantin:

...v26 is the latest, and patch number 4 is v14.

The patches applied to both kernel 5.10.38 and 5.12.5, however, most unfortunately, compile fails in both cases. Was tossing up whether to wait for v27, or report the failure to Konstantin now. Hmmm, will probably do the latter.

EDIT 2021-05-24:

Tags: linux

Automatic resizing of save-file for Puppy

May 20, 2021 — BarryK

Just made a discovery that is extraordinary. I didn't know this is possible...

One of the things that I don't like about Puppy is the save-file. When you run out of space, you have to increase the size. And of course, you have to choose an initial size.

A save-file is required on a partition with a non-Linux filesystem, such as FAT or NTFS. With a Linux filesystem, such as ext4, you have the option of having a "save-folder", which does not require resizing -- you just use it as much as you want, until the partition is full.

With EasyOS, I did away with the save-file, and only use the save-folder. So a frugal install of Easy must be to a partition with Linux filesystem, preferably ext4.

However, I have just read this, a post by 'telcoM':

telcoM's reply is so good, I have to repeat it here:

A filesystem needs to have a defined maximum size. But as the filesystem-as-file can be sparse, that size can be an arbitrary number which doesn't have much to do with how much space the filesystem-as-file takes up on the underlying filesystem.

If you can accept setting an arbitrary maximum size limit (which can be much greater than the actual size of the underlying filesystem) for the filesystem-as-file, you can create a sparse file and a filesystem on it right now:

/tmp# df -h .
Filesystem                Size  Used Avail Use% Mounted on
<current filesystem>       20G   16G  3.0G  84% /

/tmp# dd if=/dev/null bs=1 seek=1024000000000 of=testdummy
0+0 records in
0+0 records out
0 bytes copied, 0.000159622 s, 0.0 kB/s
/tmp# ll testdummy
-rw-r--r-- 1 root root 1024000000000 Feb 19 08:24 testdummy
/tmp# ll -h testdummy
-rw-r--r-- 1 root root 954G Feb 19 08:24 testdummy

Here, I've created a file that appears to be a whole lot bigger than the filesystem it's stored onto...

/tmp# du -k testdummy
0       testdummy

...but so far it does not actually take any disk space at all (except for the inode and maybe some other metadata).

It would be perfectly possible to losetup it, create a filesystem on it and start using it. Each write operation that actually writes data to the file would cause the file's space requirement to grow. In other words, while the file size as reported by ls -l would stay that arbitrary huge number all the time, the actual space taken by the file on the disk as reported by du would grow.

And if you mount the filesystem-as-file with a discard mount option, shrinking can work automatically too:

/tmp# losetup /dev/loop0 testdummy
/tmp# mkfs.ext4 /dev/loop0
/tmp# mount -o discard /dev/loop0 /mnt
/tmp# du -k testdummy 
1063940 testdummy
/tmp# df -h /mnt
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0      938G   77M  890G   1% /mnt

/tmp# cp /boot/initrd.img /mnt
/tmp# du -k testdummy 
1093732 testdummy

/tmp# rm /mnt/initrd.img
/tmp# du -k testdummy
1063944 testdummy

Automatic shrinking requires:

1.) that the filesystem type of the filesystem-as-file supports the discard mount option (so that the filesystem driver can tell the underlying system which blocks can be deallocated)

2.) and that the filesystem type of the underlying filesystem supports "hole punching", i.e. the fallocate(2) system call with the FALLOC_FL_PUNCH_HOLE option (so that the underlying filesystem can be told to mark some of the previously-allocated blocks of the filesystem-as-file as sparse blocks again)

3.) and that you're using kernel version 3.2 or above, so that the loop device support has the necessary infrastructure for this.

If you're fine with less immediate shrinking, you could just periodically run fstrim on the filesystem-as-file instead of using the discard mount option. If the underlying filesystem is very busy, avoiding immediate shrinking might help minimizing the fragmentation of the underlying filesystem.

The problem with this approach is that if the underlying filesystem becomes full, it won't be handled very gracefully. If there is no longer space in the underlying filesystem, the filesystem-as-file will start receiving errors when it's trying to replace sparse "holes" with actual data, even as the filesystem-as-file would appear to have some unused capacity left. 


As noted above, there is a problem when the size of the file grows to fill the underlying partition, so there would still have to be a size-check, the free space in the underlying partition. Then refuse to write anything more to the save-file.

That is just so brilliant. This is making me rethink everything...

I suspected that although this is a new discovery for me, it might be old news for some of the Puppy, Fatdog, etc., developer guys, such 01micko, jamesbond and dimkr. I asked dimkr if he knew, and this is his reply:

Yes, and I even used a sparse file for easy installation.

In, I made woof-CE able to produce Chrome OS style images that can be written to a flash drive with dd, or written to the built-in 16 GB SSD to install Puppy persistently, instead of Chrome OS.

To make it easy to flash Puppy to the SSD, I built a 16 GB image (exactly the size of the SSD) and put it inside a small 2 GB image that can be flashed to any flash drive that's at least 2 GB. This way, the user doesn't need a 2+16 GB flash drive and has to boot Puppy, download the 16 GB image, then flash it, because the mostly-empty 16 GB image (a sparse file is already inside the 2 GB image.

See here: ... 


Tags: linux

Puppy moving to Xwayland

May 18, 2021 — BarryK

Forum members 'dimkr' and '01micko' are doing great things at "woof-CE-testing". I posted about dimkr's elimination of the 'initrd' file:

There are other developments underway, including a move to using Xwayland instead of Xorg. If you would like to give it a go, see here:

Very early days though, so many things broken. Probably best restricted to people who can fix bugs, rather than just report them.

I haven't tried it myself, but interested as it looks like the way we will have to go, eventually. 'dimkr' posted a screenshot:


I have not studied anything about Wayland or Xwayland, so don't understand why "cage" is used. Cage project: looks like cage is an easy way to get an X app to run on Xwayland. So dimkr is running jwm, and from that rox, etc. See this:    

Tags: linux

Puppy Linux without an initrd

March 31, 2021 — BarryK

We know about the 'initrd' file, which is an initramfs that runs first at bootup. EasyOS has this, as do the puppies.

A traditional full installation, occupying an entire partition, may not need an initrd, and can be run directly from the kernel boot parameters. For example, if the full installation is in /dev/sda9, then boot parameters would include root=/dev/sda9, or the PARTUID could be specified.

If an initrd is used, the boot parameters would not have root=, instead would have something like initrd=initrd.gz, where initrd.gz is the name of the file, with perhaps a path.

One of the reasons we have a initrd is to setup the layered filesystem, using overlayfs or aufs, then a switch_root is performed onto the layered filesystem.

However, Dima, forum name 'dimkr' on github and the Puppy Forum, and 'iguleder' on the old Puppy Murga Forum, has come up with a way to load the layered filesystem without requiring an initrd.

It is achieved with a special 'init' executable, written in C and statically linked with musl. The boot parameters would be something like this: root=/dev/sda9 init=/init, which tells the kernel that there is a "full installation" at /dev/sda9 and to run /init.

Except that there isn't really a full installation, there are only SFS files. The init executable does what the initrd used to do, sets up the SFS layers and then switches onto the top of the layers.

Dima has created a new project "frugalify" which has this init executable:

He has also built a demo Puppy, dpupOS:

It must be emphasized that this is not for end users, only for those who want to play with something new and interesting and provide feedback. I tried it a few days ago, and there are too many issues to be considered as suitable for end users -- but they are details, the guts of it are sound.

A note about iguleder -- he goes way back, about 11 years I think, In the Murga Forum, and has been a fantastic contributor, as well as lots of projects on github. he is active developing woof-CE, which is great. I think that he is a young bloke, compared to me anyway.

If you are interested in compiling it yourself, I uploaded some musl chrootable root filesystems a few years ago, see a blog post here:

Downloadable from here, x86_64, x86, aarch64, armhf tarballs:

...I think there are instructions inside the tarballs.     

Tags: linux certificate issues

March 11, 2021 — BarryK

The Puppy Linux Forum, at currently does not work.

This has been reported by ozsouth at one of the alternative Puppy forums:

However, this URL works:

01micko and others are trying to fix it.

EDIT 2021-03-21:
The forum is fixed, this URL now works:

Thanks to Erik and Mick for sorting it out. 

Tags: linux