Time flies
Wow, it is now the third month of 2017. I haven't written anything for 3 months!Well, things do get quiet during the holiday season; and as usual there are real-life issues that I need to take care of.
In between, things have happened. Fatdog64 is now featured on Distrowatch: http://distrowatch.com/table.php?distribution=fatdog, yay!
Also, we recruited new member, "step" from the Puppy Linux forum. Before joining, step is known as maintainers of a few programs used in Puppy Linux, such as gtkmenuplus, findnrun, and others. Welcome step!
Though this blog is quiet, the Fatdog development is not. It continues nicely in the background with comfortable pace: bug fixes, minor feature updates, etc. Bug fixes isn't always possible, but package updates are visible here. Also checks out Fatdog contributed packages thread.
On the other news, LFS 8.0 has been released and while it is tempting to conclude that Fatdog 800 will follow suit soon, it won't happen.
While 710 (which is based on LFS 7.5/CLFS 3.0) is getting older, it has no major problem as its program and libraries continue to be updated. Fatdog 700/710 has acquired a large number of third party contributed software and we plan to keep them usable for a foreseeable time to come, by supporting 700-series until at least the end of the year. There may be one or two more releases (720? 721? or 730?) but they will use the same base.
Comments - Edit - Delete
xscreenshot is updated
xscreenshot, my dead simple screen capture program for X11, gets a facelift. It can now capture screenshot with mouse cursors in it; and it can also capture a single window. Oh, and now the filenames are created based on timestamp, rather than just a running number. You can get the latest version from here.Comments - Edit - Delete
Fatdog64 710 Final is released
The final version of Fatdog64 710 has been released. A lot of improvements since the last Beta release in August 2016; whose details you can see in the Release Notes.You can also leave your feedback in the Puppy Linux forum, where we made our Announcement.
Get it from the usual locations:
Primary site - ibiblio.org (US)
nluug.nl - European mirror
aarnet.edu - Australian mirror
uoc.gr - European mirror
It may take a while for the mirrors to update.
Comments - Edit - Delete
How to destroy FOSS from within - Part I
Although I don't set the scope of this blog, from my previous posts it should be obvious that this is a technical blog. I rarely post anything which is non-technical in nature, here; and I plan to keep it that way.But there have been things moving under the radar which, while in itself is not technical in nature, will affect technical people the most, and hit them the hardest. Especially people working in the FOSS, either professionally, or as hobby.
The blog post is too long to write in one go, so I will split this into a few posts.
For many years, I have been under the silly belief that nothing, nothing, short of global-level calamity (the kind that involves extinction of mankind), can stop the FOSS movement. The horse has left the barn; the critical mass has been reached and the reaction cannot be stopped.
The traditional way companies have fought each other is by throwing money for marketing and fire sale; outspending each other until the other cave in and goes bankrupt. Alternatively, they can swallow each other ("merge and acquire"); and once merged they just kill the "business line" or "the brand".
But they can't fight FOSS like that. Most FOSS companies survive on support. You can acquire them (e.g. MySQL), and then kill them; but one can easily spring up the next day (e.g. MariaDB). You cannot use fire sale on software licensing continuously, because the price of FOSS software licensing is eventually $0, and you can't compete with "free", well, not forever.
I still remember the days that a certain proprietary software company threw their flailing arms up in the air in exasperation, for not being able to compete against FOSS. The only thing they could do was bad-mouth FOSS and keep talking about "quality", and "amateur", and "unprofessional" when it was obvious their own products and conducts was none the better either.
So I was a believer that money cannot stop FOSS.
And how wrong I turned out to be.
Comments - Edit - Delete
Fatdog64 710 Beta Release
In development for over 3 months, this beta release contains many fixes and improvements since the last Alpha release. It is the continuing journey towards Final, which we aim to make it happen soon.During this beta period we are greatly helped by Jake SFR (from Puppy Linux forum) which contributes bug reports, bug fixes, and feature improvement patches; we were also helped by forum member step who, in addition to providing the bug report and patches, also maintains key Fatdog applications such as wallpaper-manager and findnrun, among others. The beta release would not be as good as it is were it not due to the effort of these two gentlemen. So our heartful thanks to them.
Release Notes
Announcement
Get it from the usual locations:
Primary site - ibiblio.org (US)
uoc.gr - European mirror
nluug.nl - European mirror
aarnet.edu - Australian mirror
It may take a while for the mirrors to update because ibiblio has been having problems recently.
Comments - Edit - Delete
Booting your BIOS system via UEFI
In my previous post, I wrote about my exploration on running UEFI on BIOS based systems. The original motivation was to find "cure" to long boot time from USB flash drive, when initrd is large (like the case in Fatdog). I reasoned that since in many BIOS systems USB booting is done via hard-disk emulation (and thus it depends on the quality of the emulation), it would be better to run a firmware that recognises and is capable of booting from USB devices directly, without emulation.I managed to get DUET working on qemu, but it didn't work on some of my target systems. Another alternative that I explored is CloverEFI, which is a fork of DUET. This worked better than DUET and it booted on systems where DUET wouldn't. However, I could not notice improvement on boot times. I haven't looked at DUET disk driver; I was hoping that it would provide a hardware UHCI/EHCI driver but probably doesn't - if it still depends on BIOS to access the USB via hard-disk emulation, then I've gained nothing.
So the initial objective can be considered as a failure.
However, come to think of it, I now have a better reason why you want to run UEFI on your BIOS system. When you run DUET, you are, essentially, "flashing" your BIOS and "upgrading" it with a newer UEFI firmware. While BIOS can do most of what UEFI can, there is one thing that it cannot do: it cannot boot from disk over 2TB in size†. This is not a hardware limitation, it is a consequence of applying a 36-year old design meant for 5 MB harddisk to today's world. With UEFI "update", you can format your disk using GPT and boots successfully from it.
Note†: It is possible to format the disk using GPT and have BIOS boots from it. I even described the process on my own article. That article, however, has a non-obvious limitation: the bootloader you use, must be capable of using the filesystem and booting the OS of your choice. The article was targeted for Linux users, thus syslinux was the chosen example and it would work beautifully. If, however, you want to boot other OS that syslinux doesn't understand, then you have to choose a different boot loader that:
a) can be booted by BIOS
b) understands GPT
c) can boot your OS of choice
In this case, booting GPT disk via DUET doesn't sound very unreasonable, considering that you've got more choice of UEFI bootloaders than non-UEFI ones for some specific OS.
Comments - Edit - Delete
One bootx64.efi to rule them all
Barry recently blogged about gummiboot, which contains an interesting link to a feature of gummiboot that I overlooked previously. Barry linked to a phoronix article, which linked to a blog post from Harald.TL;DR: gummiboot has a feature to build a single UEFI binary that contains Linux kernel, initrd, and the kernel command line. One UEFI file that contains the entire OS.
Yes, with this, you can have one bootx64.efi (bootloader) that actually contains the entire operating system (kernel, initrd, etc). While the idea is not new - Rob Landley pushed for ability to embed initrd into vmlinuz a long time ago - this is one step even better: embedding into the bootloader!
Why would we even bother? For one thing, it enables you to carry a stick with FAT32 partition in it, and a single file strategically located and named in /EFI/boot/bootx64.efi which contains the entire operating system for recovery and rescue purposes. It also means the return of boot-time virus - this time in the form of boot-loader virus (instead of boot-sector) from the days past if you are not careful.
Another thing is - if you run an embedded system with UEFI bootloader, after your OS are loaded entirely into the RAM, you can happily replace/upgrade your OS ("firmware") in one swop - there are no transactions needed to check if the bootloader update works ok, if the kernel update works okay, if the initrd works okay ... you just replace one file, if that one file update is okay (checkum matches etc) then all is good.
Harald has the code here, but it's somewhat tied to Fedora and systemd. Here is the extracted code that does the actual magic.
#!/bin/sh
echo your kernel cmdline > cmdline.txt
objcopy \
--add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \
--add-section .cmdline="cmdline.txt" --change-section-vma .cmdline=0x30000 \
--add-section .linux="/path/to/your/vmlinuz" --change-section-vma .linux=0x40000 \
--add-section .initrd="/path/to/your/initrd" --change-section-vma .initrd=0x3000000 \
linuxx64.efi.stub "$1"
The only catch is this - where does this "linuxx64.efi.stub" come from?
This EFI stub is built as part of the gummiboot bootloader. Gummiboot is "obsoleted" as its content are "absorbed" into systemd (and renamed to systemd-boot or something); but the code still exists and still works nicely here: https://cgit.freedesktop.org/gummiboot/ - you just need to checkout one commit before the final one (the final commit deletes everything to persuade people to move to systemd-boot).
I tested this with Fatdog64's initrd, with and without basesfs in it. Without basesfs - I ended up with 61MB bootx64.efi. With basesfs, I ended up with 366MB bootx64.efi. Both works as expected when launched from qemu as long as I have 2GB of RAM or more.
Comments - Edit - Delete
Fatdog64 FatdogArm double release
FatdogArm Beta4 is released.Release Notes
Downloads
Fatdog64 710 alpha is released.
Release Notes
Forum announcement
Downloads.
As usual you can find them on ibiblio's mirrors too:
uoc.gr, nluug.nl, aarnet.edu
Comments - Edit - Delete
FatdogArm on Odroid-XU4
A kind gentleman who goes by the nickname of "pjf" on Puppy Linux forum gave me an Odroid-XU4 to play with.As a result, FatdogArm now supports Odroid-XU4. The support is pre-eliminary - it's mainly kernel supports; the usual hardware acceleration stuff aren't supported yet.
The kernel package for Odroid-XU4 (and also XU3 - these two are software-compatible with each other) is here: http://distro.ibiblio.org/fatdog/arm/releases/beta4/kernel-packages/, or on any of ibiblio's mirrors.
This work is still in flux, though, as I'm still tweaking the kernel. It's now my 3rd compile. It may change. And while you can find beta4 SFS there, I haven't really released it and I may still make some changes soon.
Odroid-XU4 is a little machine that could. The SoC is Samsung Exynos 5422. It comes with 8 cores (ARM BIG.little architecture - 4x 2GHz cores, and 4x 1.7GHz cores), *ALL( of which can be run simultaneously under HMP mode.
It is so powerful that:
---
a) I can decode h.264 1080p video and render it to 1080p, with AAC audio, using software only (no hardware acceleration).
b) I can watch youtube using html5, with audio, without any stutter.
I've never been able to do this in my previous board. It is the fastest little board I've ever used, bar none.
It comes with a cost though. All those speed doesn't come from nothing. It is no longer fanless like Odroid-U2; XU4 comes with a fan. The power supply now can provide juice up to 4A - but this probably to support 2 USB3 ports on its board too.
PS: I used 3.10.y kernel. The 4.2 kernel is marked as EXPERMENTAL by hardkernel and currently lacks many of the fine improvements you can find in 3.10, like sound, and HMP support. It was created to be able to boot Debian server, but I find that even for server work, this is no good because it lacks the ability to schedule the cores properly. And furthermore, it seems to have been abandoned (last update is Aug 2015, while 3.10 is updated just a week ago).
PPS: An oh, on the same URL, you can find official Raspi2 kernel packages too. This is my official kernel packages, which I built from source, and of which I can also supply its kernel source SFS. The berryboot-based kernel are still available in its old link but I'm going to take it down soon.
Comments - Edit - Delete
Fatdog64 710 builds 32-bit/64-bit wine
Fatdog64 710 passed its ultimate test this weekend: the ability to build wine that supports running 32-bit and 64-bit Windows applications.To support 32-bit Windows apps, wine must be built in 32-bit mode. To support 64-bit Windows apps, wine must be built in 64-bit mode. To build wine that can support both, it must be built in both 32-bit and 64-bit mode. That requires multilib support.
And that's the new, major feature of Fatdog64 710: Fatdog64 now supports multilib natively. Building wine in 32-bit and 64-bit mode is the final test that its multilib capability is complete, working, and correct.
Happy Easter everyone.
Comments - Edit - Delete
