site  contact  subhomenews

Fatdog64 811 works real nice

October 12, 2021 — BarryK

Fatdog64 version 811 is the latest in the Fatdog puppy-derivative distribution. Using it, it seems very much like a puppy, UI, menu-structure, heaps of apps, but there are differences -- most notable is the Gslapt package manager instead of PPM in the pups.

The last time that I reported on a release of FatDog was version 720, in 2017:

https://bkhome.org/news/201712/fatdog64-720-final-released.html

...you might want to read that if interested in the history of FatDog. The developers are forum members kirk, jamesbond, step and SFR.

Version 811 was released on September 10, 2020, here is the announcement thread:

https://forum.puppylinux.com/viewtopic.php?t=746

I did try 811 earlier, when attempting to get it to run in a container in EasyOS. What prompted me to play with it again, is Gcmartin recommended it for my old HP workhorse PC with "new" Nvidia GeForce 210 GT218 video card, for which the 'nouveau' kernel module does not work. I posted about that a few days ago:

https://bkhome.org/news/202110/gt210-nvidia-card-for-old-workhorse-pc.html

Yes, Fatdog is particularly useful for booting up with troublesome video cards. The boot menu includes "disable radeon driver", "disable nouveau driver" and "severe video problems" choices.

The last two both work for me. Choosing to disable the nouveau kernel driver causes a kernel commandline parameter "blacklist:nouveau". Choosing "severe video problems" causes a kernel commandline "nomodeset".

Actually, they have the same effect. In the second case, the nouveau kernel module loads, but with modesetting disabled, which effectively disables it.

So, with no kernel GPU driver loaded, Xorg will start with whatever framebuffer mode is in effect at bootup. Which is interesting. I see that Fatdog has these:

CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FB_EFI=y
CONFIG_FB_UVESA=m
CONFIG_FB_SIMPLE is not set

A significant difference with EasyOS is it has:

CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FB_EFI=y
CONFIG_FB_UVESA is not set
CONFIG_FB_SIMPLE=y
CONFIG_FB_VESA=y

Anyway, back onto Fatdog 811, my impressions are it is pleasant to use, with everything that you would want for configuring. And of course lots of apps, including LibreOffice. Very good, I see also PuppyPhone and TigerVNC in the menu. X11vnc also.

At first, I grumbled that there was no hardinfo or pupsysinfo app, as I am accustomed to one of those in the "System" menu -- but hardinfo is there, you have to go to "Fatdog Control Panel" first.

And definitely can recommend Fatdog for booting on PC with troublesome video hardware!

EDIT 2021-10-18:
Fatdog64 version 812 is due out soon. Right now, there is 812 RC:

https://forum.puppylinux.com/viewtopic.php?t=4262    

Tags: linux

Debian-noroot works great on new Alldocube 7-inch tablet

August 18, 2021 — BarryK

I posted several days ago about installing "DebDroid-ng" on my Huawei tablet:

https://bkhome.org/news/202108/debdroid-ng-works-great.html

...that uses a VNC server in Debian and a VNC viewer in Android, and is launched from termux.

More recently, I tested termux's method of running a Debian desktop:

https://wiki.termux.com/wiki/Graphical_Environment

...and tried both "Xserver XSDL" and "Android Xserver", instead of VNC. Android Xserver is only a partial implementation of X11, and the desktop was badly broken. Xserver XSDL works, but as warned, is unstable -- a few minutes after starting, the mouse pointer froze.

Having a native Android X server is more efficient than going through a VNC connection, so I explored this some more...

Sergii, the guy who developed Xserver XSDL, has also created a complete Debian Buster XFCE desktop, bundled with Xserver XSDL, as an Android APK package. It is simply a matter of install, tap the "debian" icon, and the Debian desktop is up and running.

I thought that as Sergii has modified this Debian specifically to run on his Xserver XSDL, that it should be stable, and yes, it is. Used it for about an hour yesterday, no freeze, no crash. Again today, still stable.

Firstly, here is his Xserver-XSDL project page:

https://github.com/pelya/xserver-xsdl/tree/xsdl-1.20

...it looks like he attempted to go up to SDL 2.x, but has fallen back to using SDL 1.2 -- which I can understand!

There is an Xserver XSDL APK file for Android, that I installed for the termux tests, however the Debian noroot APK has the X server builtin, so it is standalone. So, I uninstalled Xserver XSDL (and Android Xserver), and installed this, from the Google Play Store:

https://play.google.com/store/apps/details?id=com.cuntubuntu

For the record, here is the project page:

https://github.com/pelya/debian-noroot

And Sergii has put APKs here:

https://sourceforge.net/projects/libsdl-android/files/apk/XServer-XSDL/

I found the mouse scrollwheel doesn't work. Ah yes, mouse... absolutely essential. Very sluggish.

So definitely there are issues! But, a lot does work. I installed Gimp and Inkscape, they work. Slow, but they do work. A photo showing the Synaptic Package Manager, that I used to install Gimp and Inkscape:

img1

I should mention, I am doing this on my new 7 inch Alldocube tablet, posted about recently:

https://bkhome.org/news/202108/7-inch-tablet-with-4g-lte.html

img2

It arrived a few days ago. Minimal specs, but a surprisingly pleasant experience to use. But, had a storage problem...

I formatted a 128GB SD card as internal storage, and used a USB cable to copy in several hundred MB of videos -- but later on, they just disappeared. The folder that I had created for them still existed, but contents were gone. Huh???

This must be something to do with the SD card being internal storage. So I reformatted it as portable storage, and copied the videos again. This time they have been retained.

However, back to only 16GB internal storage. Have installed a few apps, including a GPS offline mapping app, and of course Debian-noroot and Gimp/Inkscape, and Settings is now showing 10GB used. Need to be careful not to run out of internal storage!

Pare for the course, vendors cheating on device specs. I am treating it as normal now. At least for products from China. Alldocube are honest, which does make it hard for them, as many other vendors of smartphones and tablets on Aliexpress are outright scam artists. However, Alldocube are incorrect with one of the specs, claiming a weight of 224g:

https://www.alldocube.com/en/parm/iplay7t-parm/

...I weighed it at 239g. Which reminded me, I am posting weights on my blog, using a cheap Kmart digital scale. Need to confirm that it is accurate, so have ordered a set of steel calibration weights 5g to 200g.

OK, back onto Debian-noroot, here is some user feedback:

https://www.reddit.com/r/SamsungDex/comments/kvwu98/best_linux_implementation_so_far_for_me_debian/

At first I didn't know how to bring up the virtual keyboard, so used a bluetooth keyboard. But I was reading this, rather old review, it explains how to bring up the keyboard:

https://www.nextpit.com/turn-your-android-device-into-a-linux-pc-without-rooting

...swipe from the right, to expose the three command buttons, and tap on the "back" button, and hey-presto the keyboard appears and can type in the terminal window. Tap again on the "back" button to make the keyboard go away.

Here are videos. The first one was created in 2014, but note that Debian-noroot had a significant upgrade in 2020...

"Use an Android phone like a desktop PC"
https://www.youtube.com/watch?v=iFulMBNvjZA

"debian linux on android"
https://www.youtube.com/watch?v=0SxJv8KHTPM

"install debian linux on android"
https://www.youtube.com/watch?v=H_GqtFsVtgQ

It has been fun getting Debian-noroot running on the tablet. An extremely restricted environment of course, but I can see the usefulness of Gimp and Inkscape to provide superior image editing. Maybe more uses, we shall see.    

Tags: linux

DebDroid-ng works great

August 09, 2021 — BarryK

This post is to give a thumbs-up for DebDroid-ng, created by "marcusz", a method for running Debian in Android phones and tablets, without having to root the phone. I have played with various alternatives, but found DebDroid-ng to be the simplest.

I reported on one of the alternatives a couple of days ago, "Userland":

https://bkhome.org/news/202108/userland-is-a-way-to-add-puppy-or-easyos-to-android.html

...cannot recall what the issue was, but did run into a problem with using UserLand.

I am waiting on arrival of a 7 inch Alldocube tablet, a contender for phone replacement and for hiking (GPS maps, watching videos, FM radio). Would like to experiment with also running Linux on it, even though it is a very low-end device.

While waiting, decided to play with the choices out there for installing Linux, on my Huawei tablet. This is an 8 inch tablet that I bought early 2020, also pretty low-end specs. Never used it much, partly because it doesn't have Google Play Services -- yes, I am hooked on Google Play Services.

Tried a few methods to install Linux on the Huawei tablet. One that looked really great, only supports aarch64 ...that was when I discovered the tablet only has 32-bit Android 10 installed, despite having a 64-bit CPU.

Then discovered DebDroid-ng. The "ng" part is important, because marcusz completely rewrote it early in 2021, and appended the "-ng". Project page:

https://github.com/WMCB-Tech/debdroid-ng

...that page has the instructions, and I just followed them.

It does require the "termux" app, and doesn't say so, but I assume also wants a VNC client app -- I chose "VNC Viewer".

For those who have access to the Google Play Store, do not install termux from there, as it is no longer updated. Instead, install the "F-Droid" app, which is an alternative app store, free apps only, and install termux from there.

I found VNC Viewer in the Huawei AppGallery, but assume it is also in other app stores.

Then all that you do is tap on the "termux" icon, and type in commands as explained in the DebDroid-ng project page.

It defaults to installing Buster release of Debian. You do need fast Internet connection.

So far, have only tested it once. Got a desktop, XFCE, great. What is immediately obvious, is that it needs a mouse to be usable. Without a mouse, extremely painful to use. Haven't tried with mouse yet, but assume if pair a Bluetooth mouse in Android, it will work in Debian.

Just a preliminary post, to report the pleasant install experience.

One thing planning to do next is explore using "Xserver XSDL" app instead of VNC.   

Tags: linux

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:

https://www.androidauthority.com/android-apps-on-chromebooks-693696/

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:

https://www.theverge.com/circuitbreaker/2018/5/8/17318340/chrome-os-update-new-features-linux-apps-google-io-2018

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:

https://www.techrepublic.com/article/how-to-install-a-gui-for-linux-apps-on-your-chromebook/

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

https://beebom.com/best-linux-apps-chromebook/

Quoting:

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

..."almost"!!!

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:

https://forum.puppylinux.com/viewtopic.php?f=155&t=3360

Quoting:

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:

https://bkhome.org/news/202105/automatic-resizing-of-save-file-for-puppy.html

...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:

https://patchwork.kernel.org/project/linux-fsdevel/list/?submitter=194037

...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:
Fixed:

https://bkhome.org/news/202105/kernel-51039-compiled-with-paragon-ntfs3-driver.html  

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':

https://unix.stackexchange.com/questions/501500/is-it-possible-to-make-a-dynamically-risizing-filesystem-as-file

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.

https://outflux.net/blog/archives/2012/02/15/discard-hole-punching-and-trim/

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. 

...END QUOTE

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...

EDIT:
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 https://github.com/puppylinux-woof-CE/woof-CE/pull/2231, 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:

https://github.com/puppylinux-woof-CE/w ... ge.sh#L144 

   

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:

https://bkhome.org/news/202103/puppy-linux-without-an-initrd.html

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:

https://forum.puppylinux.com/viewtopic.php?f=40&t=2967

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:

img1

I have not studied anything about Wayland or Xwayland, so don't understand why "cage" is used. Cage project:

https://github.com/Hjdskes/cage

...it 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:

https://github.com/puppylinux-woof-CE/woof-CE/pull/2265    

Tags: linux