Fatdog64 903 Final is released
Fatdog64 903 Final Release.Forum announcement.
You can download it from ibiblio.org, uoc.gr, or nluug.nl.
Comments - Edit - Delete
Fatdog64 902 Final Is Released
Fatdog64 902 Final Release.Forum announcement.
You can download it from ibiblio.org, uoc.gr, or nluug.nl.
Comments - Edit - Delete
Fatdog64 901 Final Is Released
Fatdog64 901 Final Release.Forum announcement.
You can download it from ibiblio.org, uoc.gr, or nluug.nl.
Comments - Edit - Delete
Fatdog64 900 Final is released
Fatdog64 900 Final Release.Forum announcement.
You can download it from ibiblio.org, uoc.gr, or nluug.nl.
Comments - Edit - Delete
Fatdog 900 Beta is released
Fatdog 900 marches along, and now the Beta release is here.Fatdog64 900 Beta Release.
Forum announcement.
You can download it from ibiblio.org, uoc.gr, or nluug.nl.
Comments - Edit - Delete
Fatdog 900 Alpha and Fatdog 814 Simultaneous Release
The long awaited release of Fatdog64 900 is now here. It is in alpha state. At the same time, we release the last, and final version of the 800 series (814).Fatdog64 900 Alpha Release.
Fatdog64 814 Final Release.
Forum announcement.
You can download 900 Alpha from ibiblio.org, uoc.gr, or nluug.nl.
And 814 Final from ibiblio.org, uoc.gr, or nluug.nl.
Comments - Edit - Delete
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
