Fatdog64 813 is released
Release notes here, announcement (and discussions) here.Get it from the usual mirrors: ibiblio.org, uoc.gr, or nluug.nl.
Comments - Edit - Delete
Xdialog ported to GTK+ 3
Xdialog is a popular program to create a simple GUI for shell scripts. It is easy to use and implements the most commonly used GUI elements (e.g. input boxes, message boxes, etc). It was one of the earliest program of its kind.Sure, there are tons of similar program like this nowadays, some with even more powerful features - kdialog, zenity, yad, and I'm sure there are a lot more ... but Xdialog has two things going for it.
1. It's available almost anywhere.
2. It's command line interface (the parameters you pass to it, to get the GUI you want), is stable and unchanged in the last 20 years.
Any program you write with Xdialog would most probably work, while the same thing can't be easily said for the others.
There is only one problem. Xdialog is old, and for the longest time, has always been available only with those with GTK+ 2. GTK+2 has been end-of-life for about a decade now, although it is still popular.
GTK+ 2 replacement is GTK+ 3, so it's a reasonable migration path (as opposed to Qt for example, which requires a total re-write).
So far, I have not found a port of Xdialog to GTK+ 3, so I decided to start my own. The motivation is simple: so that in the future when we move to GTK+ 2-less future (only pure GTK+ 3), existing shell scripts that use Xdialog still works (we have a ton of those).
The result is here: http://chiselapp.com/user/jamesbond/repository/xdialog/index
The code in the repository compiles with both GTK+ 2 and GTK+ 3 (the original Xdialog compiles with GTK+ 1 and GTK+ 2). Login as anonymous in order to download the tarball. The port retains almost all of the features of the original Xdialog (except "unavailable" status are not available for radiolist/checklist/buidlist).
PS: While in the process of porting it, I found that somebody already did that here: https://github.com/wdlkmpx/Xdialog. I ended up using borrowing some of the codes from there to speed up the porting process, although the final code that goes into my repository is different wdlkmpx's. Another thing which is different is that I tried to retain all the existing functionalities, while wdlkmpx's port has dropped some of the lesser used features (which he documented in the his version of the Xdialog's manual).
Comments - Edit - Delete
The state of FOSS today
Somebody recently propped up Okular.It's the best PDF viewer, they say. You can view a lot of other stuff, not only PDF, but also stuff like XPS, Djvu, CBR, and many others. And it has annotation ability. And form-filling. And a lot of other nice stuff. Supposedly.
Wow. Nice. I already have a working and nice PDF viewer (Evince and qpdfviewer), but this Okular sounds so much better! I've really got to see it!
So what's the next logical stop? Try it, of course.
So I head to the website, and then on to the download page.
And immediately I see that we have problem, Houston.
There is an option to download it from the KDE Software Centre, since, well, Okular is a sub-project of KDE. There is no surprise here. It requires KDE to run, at least, KDE libraries.
But I don't have KDE.
And I can't install KDE from my repository either!
Why? Oh, it's only because I'm running my own build-from-source Linux (=Fatdog64), so I won't have KDE in my repository until I build KDE myself. But KDE is a big project, building the whole thing just to __try__ to use a PDF viewer sounds ... silly.
But that's not a problem in 2021, right?
Everybody delivers their programs in AppImage.
Well, no.
At least not this Okular.
Well no problem, just use Flatpak! Okular supports Flatpak!
Sorry, no cigar either.
Flatpak isn't just a packaging mechanism, it's an entire ecosystem.
The host OS needs to support Flatpak in the first place, before it can be used.
Fatdog64 doesn't have Flatpak support, and I'm not about to add it either (because it requires another bajillion dependencies to be built) - certainly, not for the sole purpose of testing a PDF viewer.
So what else can I do?
I see that Okular provides Windows binaries.
But I don't run Windows!
Yeah, but that's what "wine" is for, right?
So, downloaded said Windows binary, launched it with wine, and only then I got to see the wonderful PDF viewer. No amount of words can explain my jubilation, finally.
It gives me such a warm feeling, that me, someone who runs a FOSS operating system, has a such difficulty to run another FOSS software on it. Instead, I have to resort to using a binary meant for closed-source OS in order to run said FOSS software on a FOSS OS.
Merry Christmas everyone.
PS1: if you're wondering what's the point of this post: if the Okular team can spend the effort to make a Windows binary (with all the dependencies compiled in), why can't they do the same thing for other Linux users, in AppImage format?
By all means, pander to Windows users if you have to - but remember where you came from, would you? Nobody cares for your stuff in the Windows world: Adobe makes the most comprehensive PDF tools (viewer, editor, whatever have you) in the entire Windows universe. Only folks in the FOSS world do, and you're not making it easy for them.
PS2: Of, and if you're an AppImage packager, I have a message for you too.
Please, please, __resist__ the temptation to build your stuff on systems with the latest glibc, especially the one released last month. It makes said AppImage not runnable with people who happen to have OS with glibc from, say, 3 years ago, which is not that long ago.
Remember that the whole point of AppImage is to make it distro-independent, and this includes older distro, not only those relased in 2021 ?
Even a project as complex as VirtualBox can run on truly ancient glibc, because, they realise that backward-compatibility is important.
Yeah. Thanks for listening.
Comments - Edit - Delete
Introducing aloopd - the ALSA Loop Sound Server
Aka, who needs the stinking pulseaudio?Motivation
All over many years, I only had one soundcard in my machines. I configured it once, and there it went. No further tweaking was ever needed. If I needed alternate sound output - just plug in a headphone to the headphone jack. Nothing else was needed, ALSA takes care of everything.
When laptops started to support HDMI output, a problem arose. The HDMI output in effect was a second soundcard; so all these new-fangled laptops now had two soundcards. It was not a problem in itself, except that the kernel had no idea which was was to be the "default". Often times, the HDMI output was chosen as the default soundcard (over the "more correct" analog output jack), and since the laptop HDMI's port was not connected to anything, the result is an absolute silence when the user tried to play some audio apps.
To address this problem, Kirk invented Multiple-Sound-Card-Wizard (MSWC) to allow the user to choose which soundcard he/she wanted to use as the default. This settings was persisted over reboots, so the user only had to configure it once. MSCW was quickly adopted by Puppy Linux world, and its derivatives still lives on until today.
In Fatdog, MSCW was replaced with "fatdog-default-soundcard.sh" (FDS) - which worked exactly like the original MSCW except that it had more options and more features (e.g. equaliser, pre-amp, stereoswap, etc).
And then came bluetooth speakers. The FDS was updated to support these as well, so audio apps could route the audio to these speakers too. Now, unlike the analog out/HDMI selection, which was usually set only once and then never touched again, with bluetooth speakers one might want to connect to it one day, and disconnect and use the internal speaker the other day.
FDS supported this - but, after each changes, the audio app had to be restarted. If you're watching a video you had to quit the video player, make the change using FDS, and re-started. A bit annoying, but not too bad you only had to do it once a day.
And then came USB soundcards. That's okay, we could still ignore that. And then come USB headphones. These are headphones whose cables are permanently soldered to USB soundcards, the only way to make them make sound, is to connect their USB connections to USB ports and then run FDS to set the configuration.
This now means that over the course of the day, one might want/need to change the "default" soundcard many times - perhaps to route over the internal soundcard, then to bluetooth speakers/headset, then to USB headphones, etc ... FDS still works, but if one has to restart the audio app everything this happens, it starts to get more and more annoying.
The solution to avoid re-starting the audio apps is to use a "audio router", a middleman that takes the output from an audio app, and then send it to the correct destination (internal soundcard, bluetooth speakers, USB devices, etc). These "audio routing" function is done by a "sound server", of which pulseaudio is the most well know notorious example, but there are others too (JACK for real-time audio, older/defunct ones like EsoundD/ESD, aRts, etc).
All these sound servers suffer from the same problem: the applications must be explicitly programmed to use them. Apps that uses PulseAudio have to use PulseAudio API and link with PulseAudio libraries, same for JACK, and all the others too. And therein lies the problem.
1) If you don't have these libraries at run-time, the app goes kaput.
2) Even if you do, in case the "sound server" cannot run properly at run-time, you won't hear any sound.
And PulseAudio, while being the most popular soundserver in this decade (due to it being pushed down the throat on many distributions, just like systemd is), isn't exactly the most stable or the easiest one to configure. If you need proof, just use your favourite search engine and see how many questions there are about "PulseAudio not working" ...
Anyway, as I said, in days past, I only had one soundcard, so the need to do all these was non-existent - if one only has one soundcard, what's really the need of having a middleman? So, I was never bothered about this for long while ...
Until now. Recently got a USB headphone. With a regular headphone, you plug in the jack to the hole, and it all works (the sound on the laptop was turned off and redirected to the headphone). This was by the way done by the __hardware__ (the audio codec chip), there is no "sound server" in the kernel that does this.
However, things aren't the same with USB audio. As I said above, it is effectively a different soundcard, so FDS needs to be called to configure the app to use it, and then the audio app has to be restarted ...
And thus is born the ALSA Loop Sound Server.
The ALSA Loop Sound Server
As it turns out, ALSA has already come with a sound server of sorts.
It's primitive compared to others, but for me, it does the job fine enough.
My objective is only one: I want to be able to switch sound output without having to shutdown and restart the audio apps. I can live with the interruption during the switching, I can live with the fact that different soundcards have different mixer (volume) control etc (although this apparently can be automated as well - I haven't tried it).
The ALSA Sound Server consist of two components: the kernel module component called snd-aloop (ALSA Loopback module), and the user-space program called "alsaloop". ALSA Loopback module basically acts are virtual soundcard and acts are a "pipe" - audio data goes from one part, and out into another. "alsaloop" acts like a pump - it read data from one card, and output it to another.
The entire setup is conceptually simple:
- use snd-aloop to create a virtual soundcard and make it as the default output.
- run alsaloop, which reads audio from this virtual soundcard, and push it out the actual soundcard.
So the audio routing becomes like this:
app --> loopback virtual soundcard --> alsaloop --> actual soundcard.
But what have we achieve with this middle-man setup? Well, the magic of this setup is that even if "alsaloop" is not running, the audio app will continue to blissfully send its output - except that of course you hear no sound.
To hear any sound, run the "alsaloop" pump, and if you want to switch output, just kill alsaloop and re-start it with different output. Presto!
This implementation is available on Fatdog64 812.
It is capable of switching audio seamlessly between internal soundcards and bluetooth speakers, without restarting the sound apps.
Beyond Fatdog64 812
After the release of Fatdog64 812, I worked a little bit more on the ALSA Sound Server and it is now capable of delivering __network__ audio, using a neat package called "trx" (available in the Fatdog repository).
It is now possible to send audio over the network, and receive audio from the network. Using multicast, it possible to send a single stream to multiple listeners at once.
All using only ALSA (and trx).
This implementation will be available on next release of Fatdog, whenever that will be. If you are keen to test, you can always get the "tip" version of Fatdog, which gets updated whenever there is an interesting feature (or update).
Comments - Edit - Delete
Fatdog64 812 Final is released
The release candidate was released a little over 3 weeks ago. As the reports have dried up and and we have fixed all reported bugs, it's time to release Fatdog 812 Final.There are two features in Final which wasn't there in RC (and thus, is considered experimental because it only received short testing time): Simple Bluetooth Manager, and ALSA Loop sound server.
There is nothing special about the overdue Bluetooth Manager, but I may write a little about the ALSA Loop sound server (aloopd) later.
Release notes here, announcement (and discussions) here.
Get it from the usual mirrors: ibiblio.org, uoc.gr, or nluug.nl.
Comments - Edit - Delete
Fatdog64 812 RC is released
Yeap, still here. Still alive and kickin'.Just dropping by to let you know something that you've probably already known: that is Fatdog64 812 RC has been released.
Release notes here, announcement (and discussions) here.
Get it from the usual mirrors: ibiblio.org, uoc.gr, or nluug.nl.
Unfortunately we lost AARNET for the Australian folks.
Comments - Edit - Delete
Fatdog64 811 is released
Fatdog64 811 was released on 10 September 2020.Release notes here, announcement here.
Get it from the usual mirrors: ibiblio.org, aarnet, uoc.gr, or nluug.nl.
Comments - Edit - Delete
RetroPie
I've always enjoyed retro gaming. In Fatdog we have always had dosbox (emulator for DOS games) for as long as I can remember, and scummvm (for Sierra games) came a little bit later. I've recently added a few more emulators: mednafen (multi-emulators for GBA, SNES and others), desmume (NDS), duckstation and pcsxr (PS1) as well as pcsx2 (PS2). I threw ZX-Tune as well, to play the music from those old games.But very recently I've been introduced to RetroPie, a distro for Raspberry Pi (raspi) which is dedicated to turning your raspi to a retro gaming machine. Since I have a dusty Pi3 laying around doing nothing (which I was supposed to use for testing Mick's Raspbian Buster but never got my lazy bum off to actually do it - sorry Mick!), I reckon, why not give it a try. If it doesn't work all I wasted is a couple of minutes downloading ~800MB image and couple of minutes "dd"-ing it.
As it turned out, it worked the first time around. Once the SD card as prepared, I put it inside the raspi, hooked the raspi to my TV, and then turned the raspi on. I was instantly asked to configure my controller (I didn't have one, but no problem, retropie accepts keyboard too). I configured the optional wifi setup (I didn't have to do it, but I wanted to try its samba feature). Then all I needed to do was to install the games (which I can install via USB, SFTP, or Samba). No stupid questions, no hassle, no config file. It's all ready to use. Most of the popular emulators were already included, and those that don't, are literally available for installation, a few clicks away.
With retropie on it, the raspi has been magically turned into a retro gaming machine. In the beginning I didn't believe that the raspi had enough muster to pull up a decent emulation, but I was pleasantly proven wrong. Most emulators worked well. Some had a few stutters every once a while but it was nothing to fret about.
The display quality was good, too. Retro games were notorious for displaying low-res pixelated images on today's high-res TV, but the emulators included in retropi had a few tricks up their sleeve to make the images sharper. I'm not surprised about that (after all I compiled some of those for Fatdog64 too) but what surprised me that the little raspi could pull off the enhanced graphics too. Well again not all emulators and not all games, but as I said, nothing to fret about.
Now, I have FatdogArm, Fatdog's variants that runs on ARM machines, the raspi included. If I really want to, I could, in theory, build and package all these myself too, producing a custom FatdogArm build that does what retropie does. All the software used in retropie is FOSS software. The standard release of FatdogArm was built to run as a "desktop-replacement" OS, but of course at its very core it was designed to be modded to produce a build that met specific needs. Making a retro gaming machine would be one of those.
But of course, why bother? The folks who makes retropie does a very good job, and the result is a very polished retro gaming software. Unless you try very very hard, you won't even know that beneath all the pretty faces, it runs Raspian Buster Linux. Rather than spending thankless hours building software on FatdogArm so it can become retropie wannabe, I may as well use retropie as is and start gaming with my kids
Anyway. In case you want to try retropie and don't have raspi, there is no need to fret and there is no need to fork out extra dollars too. While originally designed for raspi (all varians from pi 0/1/2/3/4), today's retropie supports other platforms: Odroid C1/C2, Odroid XU3/XU4, as well as standard PC! Yes, standard PC. You can use your old laptop, old desktop, NUC if you have one, etc basically any PC. The details are all on their website, if you're interested, go ahead and check it out.
Meanwhile, I've got a few games I need to catch up.
Disclaimer: I am not affiliated with retropie or any of its developers. In fact I wasn't aware that it exists until last week. I'm writing this to share with fellow retro gamers who aren't aware of retropie.
Comments - Edit - Delete
spcplayer patch for libao
I've been intro retro gaming lately, and one of the interesting aspects of the retro gaming is their music; in particular, the music in their original format.One of those formats is SPC. There are plenty of players for Windows (mostly plugins to popular music players), but standalone players for Linux are few and far between.
There is this player called AudioOverload but it is closed-source and output only to /dev/dsp. It does have a nice interface and supports many different video game formats, not only SPC.
The older version of gstreamer (0.10 branch) has a decoder in their 'bad plugins' collection called "GstNsfDec" which apparently can be used to decode SPC file (I haven't tested) - but do I really want to install the entire train of old gstreamer libs just to do that?
Then I found this vspcplay is an SDL-based player which is really nice and full featured; unfortunately the emulation isn't accurate; it sounds different from what I heard in the game and it eats 100% of one of my CPU core when running it.
Finally I found this one: SPC-PLAYER, a CLI player for SPC but unfortunately like AudioOverload it also outputs to /dev/dsp (and other OSS devices).
The problem with outputting to /dev/dsp is that whatever program is outputting the sound takes an exclusive use of the soundcard. I cannot play anything if I have my web brower open and one of its tab is pointing to youtube (even if nothing is being played), because the browser keep the sound access open and this prevents other programs to access /dev/dsp.
The only way to make work nicely is to use ALSA, which comes with built-in mixer (dmix) allowing multiple programs to use the sound card at the same time.
So I've written a simple patch for SPC-PLAYER to use libao, a very nice sound output library that enables us to output to a variety of output devices (ALSA, OSS< Pulse, etc) with exactly the same, simple API. Nice.
Well, if you're interested, you can find the patch in my patches page.
Note that SPC-PLAYER compiles in 32-bit only due to its extensive usage of x86 assembly in its APU emulation.
__________________________
EDIT: and just after I spent the effort to create the patch, I found ZXTune which is a full-fledged multi-format chiptune player which includes support for SPC and many other formats! You know, you can't guess by its name alone (ZXTune - it plays only sounds for ZX Spectrum? Come on ...). It's open source and binary is provided, too! Works out of the box and supports the formats I'd love to play. The program comes in GUI flavours (Qt) and CLI, with only minimal dependencies needed (the rest of the libs needed were compiled statically with the binary).
So go ahead and use that instead.
------------------------
EDIT: After finding ZX-Tune, JakeSFR informed me that deadbeef music player can also play SPC files.
Interesting. I looked into that, and found that deadbeen uses a library called "game music player", also known as libgme, to do that. And I found out ZXTune uses the same library too!
The library also has a simple "sample player" which uses SDL for output and hence is not affected by the "OSS problem".
You can get libgme from here.
That probably explains why nobody bothers to patch SPC-PLAYER, but that's okay. At least now I know how to use libao for my future projects
Comments - Edit - Delete
New forum for Fatdog
Fatdog has, for years, since its inception, always been piggybacking on Puppy Linux forum. Firstly because of its obvious roots; also because we simply didn't have enough man power to run and police an independent forum ourselves.As the previous blog entry indicates, however, John de Murga, the owner of the Puppy Linux forum, sadly passed away, and the original Puppy Linux forum went down (for a time).
Behind the scenes people are frantically working to bring it up, but there are also efforts to setup a replacement forums, including one by rockedge.
By now, both efforts have been fruitful: the old forum has been resurrected and the rockedge forum has flourished with old and new members (re-)joining it.
The stewards of Puppy Linux has decided that the old forum will continue in read-only mode as archives, while rockedge forum will take over as the new Puppy Linux forum.
Rockedge has graciously offered a section of the forum specifically for Fatdog, for which we are very grateful.
After some internal discussions, we have decided to take the offer and continue the tradition of piggybacking on Puppy Linux forum. All of Fatdog team members have now re-joined there as well.
For your reference:
---------
The new forum address: https://forum.puppylinux.com (Fatdog posts will be in the Fatdog section)
The old (archived) forum (in case you need to review/check old postings for older version of Fatdogs): http://oldforum.puppylinux.com (Fatdog posts are in the Puppy Projects section)
We'll see you there in the new forum!
Comments - Edit - Delete
