Some random updates

OK, let's start with Barry K, the original author of Puppy Linux and the spiritual grandfather of every "dog"-themed Linuxes out there, Fatdog included

For you who haven't read Barry K's blog recently, you should check it out. Barry has come out with new interesting stuff that should spice out your "Puppy" experience (strictly speaking, it's not Puppy Linux anymore - Barry handed over the baton long time ago. Instead Barry now does Quirky/EasyOS/etc - but as far as we're concerned, it's a "puppy" with a quote ).

Barry is also branching to 64-bit ARM (aarch64). I'm sure he will soon release an 64-bit ARM EasyOS. If you remember, Barry was also one of the first to venture to 32-bit ARM a while ago (a tad over 6 years ago) and made a Puppy that ran on the original Raspi. Quite an achievement considering that the original Raspi was barely able to run any desktop at all - but that is Puppy at its best, showing the world that even the weakest computer in the world can still run a desktop (as long as it's Puppy ). It was also one of the motivation that made me do FatdogArm.

Speaking about Raspi and FatdogArm, I have also recently pulled out my Raspi 3 out of retirement. But this time I'm not doing it for desktop replacement, but mainly because I'm interested to use it for what it was originally made: interfacing with stuff. Direct GPIO access, I2C and SPI is so interesting with the myriad of sensor packages out there. I've been playing with Arduino for a while and while it's cool, it's even cooler to do it using a more powerful platform. Now this article shows you how to do it directly from the comfort of your own PC (yes, your own desktop or laptop), if you're willing to shell out a couple of $$ to get that adapter. I did, and it is quite fun. Basically it brings back the memory of trying to interface stuff using the PC's parallel port (and that adapter indeed emulates a parallel port ... nice to see things haven't changed much in 30 years). But it's speed is limited to the emulation that it has to go through - the GPIO/I2C/SPI has to be emulated by the kernel driver, which is passed through USB bus, which then emulated by the CH341 on the module. If you want real speed, then you want real device connected to your system bus - and this is where Raspi shines. I haven't done much with it, but it's refreshing to pull out the old FatdogArm, download wiringPi and presto one compilation later you've got that LED to blink. Or just access /sys/class/gpio for that purpose.

Now on to Fatdog64 800. I'm sure you're dying to hear about this too OK. As far as Fatdog64 800 is concerned - we've done close to 1,100 packages. We're about 200 packages away from the finish line. As usual, the last mile in the marathon is the hardest. It's bootloaders, Qt libs and apps, and libreoffice. Here's crossing your finger to smooth upgrading of all these packages.

Speaking about updates, I've also decided to go for the newest bluetooth stack (bluez). I have been a hold-on on bluez 4 for the longest time, simply because the bluez 5 does not work with ALSA - you need to use PulseAudio for sound. But all of that have changed, ther e is now an app called bluez-alsa that does exactly that. I've been thinking to do it myself were it not there; but I've been thinking too long Anyway, I'm glad that it's there. Bluez 5 does have a nicer API the last time I looked at it (as in, more consistent) though not necessarily clearer or easier to use than Bluez 4. But that's just Bluez.

Well that's it folks for now. And in case I don't see you... good afternoon, good evening, and good night

Posted on 3 Aug 2018, 17:29 - Categories: General Fatdog64 Linux
Comments - Edit - Delete


New Fatdog64 is in the works

It's the time of the year again. The time the bears wake up from hibernation. After being quiet for a few months, the gears start moving in the Fatdog64 development.

Fatdog64 721 was released over 4 months ago. It was based on LFS 7.5, which was cutting edge back in 2014 (although some of the packages have younger ages as they got updated in every release).

As I have indicated earlier (in 720 beta release, here), 700 series is showing its age. Compared to previous series, the 700 series is actually the longest-running Fatdog series so far, bar none.

But everything that has a beginning also has an end. It's time to say goodbye to 700 series and launch a new series.

The new series will be based on LFS 8.2 (the most recent as of today). This gives us glibc 2.27 and gcc 7.3.0. Some packages are picked up from SVN version of BLFS, which is newer.

How far have we gotten with this new release? Well, as of yesterday, we've got Xorg 1.20.0 running with twm, xterm and oclock app running from its build sandbox.



Hardly inspiring yet, but if you know the challenge we faced to get there, it's a great milestone.

As it is usual with Fatdog64, however, it will be released when it is ready. So don't hold your breath yet. If 721 is working well for you, hang on to it (I do!). But at least you know that wouldn't be the last time you heard of this dog.





On a special note, I'd like to say special thanks to "step" and "Jake", the newest members of Fatdog64 team (and thus is still full of energy - unlike us the old timers hehe). While I have been shamelessly away from the forum for many reasons, "step" and "SFR" continue to support Fatdog64 users in the forum. My heartful thanks to both of them.

Of course, also thanks to the wonderful Fatdog64 users who continue to support each other.

Posted on 31 May 2018, 01:37 - Categories: Fatdog64 Linux
Comments - Edit - Delete


Fatdog64 721 is Released

In the light of recent Spectre and Meltdown fiasco; the Linux kernel team has released patches to sort of workaround the problem.

It's not free, you will get a performance hits anywhere from 5% to 30% depending on the kind of apps that you use (more if you use virtual machines), but at least you're protected.

We have released Fatdog64 721 with updated kernel (4.14.12) that comes with this workaround.

You can, however, decide risk it and not use the workaround, by putting "pti=off" boot parameter. You'd better know what you're doing if you do that, though.

Apart from that, this release also supports microcode update and hibernation. We've bundled the latest microcode from both Intel (dated 8 Jan 2018) and AMD (latest from linux-firmware as of 10 Jan 2018); however it is unclear whether any of them address the problem.



Release Notes
Announcement (same announcement as 720).

Get it from the usual locations:
Primary site - ibiblio.org (US)
nluug.nl - European mirror
aarnet.edu - Australian mirror
uoc.gr - European mirror



Posted on 11 Jan 2018, 21:40 - Categories: Fatdog64 Linux
Comments - Edit - Delete


Fatdog64 720 Final is released

Fatdog64 720 Final was released on 20 December 2017, after about three weeks of beta (720 beta was announced here).

It was a hectic before Christmas so I didn't get to announce it here in my blog. In fact, Barry Kauler (original author of Puppy Linux) announced it earlier that I do - which is quite a tribute for us

There isn't much changes between this and beta, other than a few bug fixes - as I said earlier, 720 beta was actually quite stable.

One new "feature" made it there: 720 now comes with two initrds (dual-initrds) - the first one is the usual huge initrd, and the second one is a very small initrd (around 3.5MB) with ability to "load" the larger initrd. This was a suggestion from forum member LateAdopter, which we "adopted"

Why the need for that? Some people have been complaining about the slow booting speed of Fatdog64 due to its huge initrd. There are many reasons for this slowness but it's mainly because:
a) old BIOS
b) old bootloaders (grub4dos/grub-legacy)
c) boot from modern, large filesystem such as ext4 with size over 16GB.

This particular combination is especially toxic - bootloaders usually use BIOS calls to get data from the disk, and old bootloaders don't understand new filesystem well so while they can load from it, they only do it very very slowly.

Nevertheless, the new "nano-initrd" (as I call it) to the rescue. The small initrd will be loaded fast enough by the bootloader, and then Lnux kernel takes over and load the huge initrd - with the use of modern, optimised code. So booting remain fasts.

However, nothing comes for free. It's basically a stripped down initrd (as explained here so along with the cutdown in size, a lot of other stuff must be sacrificed too. Don't expect the nano-initrd to be able to boot from exotic environments.



Release Notes
Forum announcement

Get it from the usual locations:
Primary site - ibiblio.org (US)
nluug.nl - European mirror
aarnet.edu - Australian mirror
uoc.gr - European mirror


Posted on 28 Dec 2017, 14:36 - Categories: Fatdog64 Linux
Comments - Edit - Delete


How to create Nvidia driver SFS for Fatdog and Puppy

If you need to use Nvidia driver (instead of the open-source nouveau driver), I've written the steps to prepare the driver SFS yourself.

I wrote this article because Nvidia driver is sensitive to kernel changes; each kernel changes requires a rebuild of the driver. And we usually don't provide nvidia driver for beta releases.

Also, there are variations of the nvidia driver (long term, short term, legacy, etc) supporting different cards. Creating a driver for each variation, and re-creating them every time the kernel change, takes a lot of time.

So I've published the way for you to do that yourself. The steps enable you to create the SFS yourself, or, if you can't be bothered about the SFS, it will install the driver directly for you.

As a bonus, it should work on recent Puppy Linux too.

The instruction is here.

Note: this article is an update of the original instructions I wrote here (which is XenialPup64 specific).

Posted on 4 Dec 2017, 15:58 - Categories: Fatdog64 PuppyLinux Linux
Comments - Edit - Delete


I accidentally removed glibc

I accidentally removed glibc.

I was running Fatdog build process and I wanted to remove glibc from its chroot.

The correct command to do that was this:
ROOT=chroot removepkg glibc32 glibc

but I typed in the wrong way:
removepkg ROOT=chroot glibc32 glibc


This has the unintended effect of attempting to remove ROOT=chroot package
(which didn't exist), and then glibc32, and glibc. Of course the removal wasn't fully successful, but the dynamic linker /lib64/ld-linux-x64_64.so.2 was deleted and that's enough to stop almost anything.

In a normal distro this would probably require an immediate re-install.

In Puppy-like distro (including Fatdog) all you need to do is to boot pristine, disregarding any savefile/savefolder (pfix=ram for Puppies and savefile=none for Fatdog); and then clean up the mess you've created by the accidental deletion. This is usually done by deleting the whiteouts, so glibc can "show up" again in the layered filesystem.

But I was in the middle of something and I really didn't want to reboot and abandoned what I was doing. What to do? I still had a few terminals open, is there anything I could do to salvage the situation?

Fortunately, Fatdog has a failover mechanism for situation like this.

Fatdog has a static busybox located in /aufs/pup_init/bin/busybox. This busybox is linked with complete set of applets, with its shell (ash) compiled to prefer internal busybox applets instead of external commands.

By running its shell
/aufs/pup_init/bin/busybox ash

I am back in a working shell, and I can do "ls" and other things as needed because the busybox is fully static and doesn't need glibc.

Inside there, I then run Fatdog's whiteout clean up script
sh fatdog-clean-whiteout.sh

which run nicely because busybox has enough applets to support it. This removes the whiteout, in effect, undo-ing the deletion.

But trying to do "ls" on another terminal still indicate that glibc isn't installed yet. This is because aufs, the layered filesystem, isn't aware that we have "updated" its layer behind its back. All we need to do is to tell it to re-evaluate its layers.

This can be done by running (from the terminal that runs static busybox shell) this command
mount -i -t aufs -o remount,udba=reval aufs /

Once this is done, the system is back to live, and the project is saved.


Posted on 4 Dec 2017, 22:08 - Categories: Fatdog64 Linux
Comments - Edit - Delete


Fatdog64 720 Beta is Released

The next release of Fatdog64 is finally here!

Well, the beta version at least. I actually think this is the next stable release. We have been running this for weeks ourselves, but because we have made so many changes, it's good to treat it as beta and test it on wider audience.

A lot of improvements since the last release; lots of package updates, and lots of fixes too. However this is still based on 710 as the base.

We plan to follow this one up with a Final soon, hopefully before Christmas.

What's next?

Once it goes to final, it would probably be sunset for the 700 series. While 720 is running very well, it is showing its age. Some binary packages refuses to run on it, demanding a newer glibc, for example.

The decision isn't final yet, and the 800 series isn't probably going to be started very soon (we all need to catch our breaths). Meanwhile, enjoy it while you can.

Release Notes
Forum announcement

Get it from the usual locations:
Primary site - ibiblio.org (US)
nluug.nl - European mirror
aarnet.edu - Australian mirror
uoc.gr - European mirror


Posted on 4 Dec 2017, 13:08 - Categories: Fatdog64 Linux
Comments - Edit - Delete


Fatdog Update

Well, I'm still here. I've been busy with life, moving houses, making arrangements, etc. Too much things to do, too little time. I wouldn't bore you with all that mundane things, since what most probably you're here for Fatdog.

Anyway.

Fortunately for all of us Fatdog64 lovers, it has not been so quiet for Fatdog64 under the hood. Our two new members, "SFR" and "step", have been busy at work - bug fixes, package updates, package rollback when the updates don't work :), package replacements, etc. You will find them in the Forum as well, helping other people.

I would say that recruiting them was the best decision we have done - the dynamics works well between us so discussion is always productive.

In fact, we're nearing a release now. To be accurate, however, we have been "near a release" for a few months now - there are so many changes we'd like to share with you; but there is always "one more thing we would to before release to make it better" - and the it's back to the kitchen . So this release may happen soon or may be a bit later (or a lot later) - cross your fingers!

But seriously, all in all, things are looking good on Fatdog64 side. The team has done lots of exciting improvements. As usual, it may not be perfect, but there is a always the next release .

It has not been so well on the ARM front. I'm really the only one who works on FatdogArm, and my lack of time to do anything with it means it gets left behind; and it shows. No new platform supported, packages not updated ... although, all in all, it still runs pretty well, for an aged OS.

Well, that's about it for now. On my other FOSS article, I have published two parts. It's actually a four-parter, so there are two more parts to publish ... I'll get that done very soon.

Cheerios everyone.

Posted on 6 Nov 2017, 01:13 - Categories: Fatdog64 Linux
Comments - Edit - Delete


Fatdog64 build recipes

I've just uploaded the build recipes for all the official packages of Fatdog64. They are available here.

They are tarballs, containing the recipe proper, and other supporting files such as patches, desktop files, icons, etc.

They have previously been available in the binary packages (every official Fatdog binary package contains the build recipe tarball inside); but to make it easier for people to search and re-use; we have decided to extract them and upload it in separate place.

The recipe itself is just a shell script, to be used with Fatdog's pkgbuild system. If you want to use it to build it as is, you need that build system which you can get from here. Warning: only tested to work in Fatdog. However, if you just want to examine how the build is done; you can just look at the recipe - it's simple enough to understand.

Note: If you're already on Fatdog64, don't bother getting that. pkgbuild is already included as part of Fatdog's devx.

These build recipes will be updated from time to time; but I can't guarantee any "freshness" of any of these recipes. And oh, they come as totally unsupported - feel free to use them as you see fit, but the risk is all yours. And while I'd be glad to hear suggestion and/or patches for them; please don't come to me for support. My hands are already full of other things.

Posted on 18 Mar 2017, 05:55 - Categories: Fatdog64 Linux
Comments - Edit - Delete


Real-time Kernel for Fatdog64 710

I built and uploaded real-time kernel for Fatdog64.

It's based on Linux 4.4.52 - the latest as of today; and from the same branch as the 710 kernel (4.4.35); and one of the LTS (long-term-support) version; patched with 4.4.50-rt63 patches.

I could manage only the "Basic RT" (PREEMPT_RTB) configuration. This is somewhat between "low-lateny" and "fully preemptible" configurations. I tried the "fully preemptible" (PREEMPT_FULL) configuration but while it gave me a kernel binary; it didn't work satisfactorily --- too many lockups at too unpredictable times.

It has been a very long time since I built an RT kernel (the last one was probably around Linux 3.4 days) which can run in fully preemptible manner. The RT patches aren't always stable either; depending on the kernel version they can be good, okay, or just bad; so I suppose for today, this is the best I can get.

Apart from changing the pre-emption level to PREEMPT_RTB, I made two more (unrelated) changes:
- I increased timer frequency to 1000 Hz.
- I added SDA_HWDEP support.

The first change is done because I plan to use the RT kernel for some audio work that requires lower latency and higher timer resolution.

The second one is done because by tweaking the codec's amplifier I could make my laptop speaker louder by using HDA Analyzer (which requires HDA_HWDEP support); but it turns out to be wishful thinking.

Anyway, enjoy. If you need a guide on how to use the new kernel, look here. There is a new way to test kernels without having to do all above, but it hasn't been written yet. I'll write it when I have time (and motivation) - basically you use "extrasfs" boot parameter to load the kernel-modules.sfs instead of replacing the kernel modules inside your initrd.

Posted on 12 Mar 2017, 05:30 - Categories: Fatdog64 Linux
Comments - Edit - Delete


Pages: ... [2] [3] [4] [5] [6] [7] ...