From the desk of James

Fatdog64 904 Final is released

Fatdog64 904 Final Release.

Forum announcement.

Yes we are still here!

It has been many seasons since I last posted. A lot has changed over the years. Old stories end. New stories begin. As they say, "time changes everything". Priorities change.

But as things change, there are still things that remain constant, remain unchanged.

Fatdog is one of them.

Fatdog is still alive. Still kicking. Still actively maintained. By the same Fatdog team. Though we don't announce every single changes that we make, updates still trickle to Fatdog package repository. Eventually, when the time comes, there will be another release.

In the meanwhile, enjoy.

Fatdog64 903 Final is released

Fatdog64 903 Final Release.

Forum announcement.

You can download it from ibiblio.org, uoc.gr, or nluug.nl.

Fatdog64 902 Final Is Released

Fatdog64 902 Final Release.

Forum announcement.

You can download it from ibiblio.org, uoc.gr, or nluug.nl.

Fatdog64 901 Final Is Released

Fatdog64 901 Final Release.

Forum announcement.

You can download it from ibiblio.org, uoc.gr, or nluug.nl.

Fatdog64 900 Final is released

Fatdog64 900 Final Release.

Forum announcement.

You can download it from ibiblio.org, uoc.gr, or nluug.nl.

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.

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.

Fatdog64 813 is released

Release notes here, announcement (and discussions) here.

Get it from the usual mirrors: ibiblio.org, uoc.gr, or nluug.nl.

Who fact-checks the fact-checkers?

In the moment of confusion, who is the arbiter of truth?
Who appoints the arbiter of truth?

Or shall we speak in one voice with Pilate, who asked: "What is truth?" (John 18:38).

The Pale Blue Dot

Image of our homeworld taken from a distance of 6 billion kilometres away (approximately, 40.4 AU, or 5.5 light-hours), by Voyager 1, on 14 Feb 1990.
For context, at this location, Voyager was farther than the average orbital distance of Pluto.

This is what Carl Sagan had to say about the image:

Look again at that dot. That's here. That's home. That's us. On it everyone you love, everyone you know, everyone you ever heard of, every human being who ever was, lived out their lives. The aggregate of our joy and suffering, thousands of confident religions, ideologies, and economic doctrines, every hunter and forager, every hero and coward, every creator and destroyer of civilization, every king and peasant, every young couple in love, every mother and father, hopeful child, inventor and explorer, every teacher of morals, every corrupt politician, every "superstar," every "supreme leader," every saint and sinner in the history of our species lived there--on a mote of dust suspended in a sunbeam.

The Earth is a very small stage in a vast cosmic arena. Think of the rivers of blood spilled by all those generals and emperors so that, in glory and triumph, they could become the momentary masters of a fraction of a dot. Think of the endless cruelties visited by the inhabitants of one corner of this pixel on the scarcely distinguishable inhabitants of some other corner, how frequent their misunderstandings, how eager they are to kill one another, how fervent their hatreds.

Our posturings, our imagined self-importance, the delusion that we have some privileged position in the Universe, are challenged by this point of pale light. Our planet is a lonely speck in the great enveloping cosmic dark. In our obscurity, in all this vastness, there is no hint that help will come from elsewhere to save us from ourselves.

The Earth is the only world known so far to harbor life. There is nowhere else, at least in the near future, to which our species could migrate. Visit, yes. Settle, not yet. Like it or not, for the moment the Earth is where we make our stand.

It has been said that astronomy is a humbling and character-building experience. There is perhaps no better demonstration of the folly of human conceits than this distant image of our tiny world. To me, it underscores our responsibility to deal more kindly with one another, and to preserve and cherish the pale blue dot, the only home we've ever known.

Both the image and the quote were sourced from Wikipedia. I added the arrow to point out the location of the pale blue dot. Yes, it's that small. In fact, according to NASA, it is less than a pixel.

How to handle bug report

I recently tested the Go language (a language invented by a star-studded team, including the original inventor of C language and Unix), however, it didn't go smoothly.

I encountered a problem: I cannot compile a simple hello world program. It gave out a cryptic error message which search engines of the world cannot find.

Concerned, I raised a bug report. Mind you, it's not a support request, not a question. It's a __BUG REPORT__.

I received two kind of responses.

(1) The first one was short and sweet, and closed the ticket immediately, basically telling me not to ask question there.

But I wasn't asking a question. I was reporting what I thought to be a BUG!

This very unhelpful response was a big turn off. How would you encourage people to use your product if you ignore bug reports on your public bug tracker?

I quickly replied that with a piece of my mind.

My retort attracted a second response.

(2) This second response was a lot more helpful. It gently informed me that this was probably the problem of my own making; it linked to another ticket which had similar symptoms to the one I reported, and showed me how my issue could be caused by the same problem as described in the other ticket.

This response motivated me to do more investigation, and it turned out that the problem was indeed on my side. Hence, I replied in kind and moved on, after thanking the second responder.

No cookie for correctly guessing which one wins another customer (if this were a commercial project).

______________

So what's the outtake here?

With response (2): I learn that Go uses files with the name of .a that aren't libraries, and therefore should not be stripped.

But more importantly, others will learn the same thing (once the issue is indexed by search engines, next time someone else tries looking it up, they won't find empty results).

And finally, perhaps, just perhaps, the Go developers themselves will learn that adopting a file extension (.a) that already has an existing, different meaning, is probably not the best idea.

What do we learn from response (1)? Go away, and Go use another language.

___________

Sadly, attitude like (1) is very common on the IT world - especially in the commercial world. (I know Go isn't commercial, but I'm willing to bet that most of its core developers and support persons are employees).

Read the whole saga yourself: https://github.com/golang/go/issues/50509

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

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.

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

Cowboy Bebop Netflix Live Action 2021

"The Abolition of Man" was a heavy read, and its consequences weighed even heavier on my mind, so I thought I'd take a break and do something fun, like watching something light and entertaining.

Netflix launched the live-action adaptation Cowboy Bebop series on November 19. That should be good, right? (despite many previous dire warnings ...)

If you don't know what Cowboy Bebop is, you probably don't want to read the rest of this long post anyway. But if you still want to know, it is an iconic anime from the turn of the previous millenium.

If you don't even know what anime is ... well, I think you should really leave now, unless you really want to go down the rabbit hole. But again, if you really want to know, "anime" is the Japanese word for "animation", that is, what we in the western worlds call as "animated movie", or "cartoon movies".

For the benefit of those who really don't know (who I am kidding ... if you get this far, you must be familiar with it, otherwise, why keep reading a very long post containing my silly opinion on a silly cartoon show. There are more important things to take care in the world ...), "Cowboy Bebop" is the story of a group of futuristic bounty hunters, living in the space ship called the "Bebop". ("cowboy" being the in-universe derogatory term for "bounty hunters", so the title could roughly be translated as "Bounty hunters who lived in a space-ship named the "Bebop"). There are five major characters - Spike Spiegel, Jet Black, Faye Valentine (the three are the "cowboys"), Ed (which is a girl), and Ein (which is a dog).

What's so interesting about bounty hunters anyway? Well, there is a reason why this show is iconic. You really have to watch and decide it for yourself. People have different tastes and preferences. Some people say it's iconic because it is the first anime that uses jazz music (but that's not true). Some people says because it's the animation quality (which isn't bad, but there are other anime that have good animation quality either), etc. I was skeptical before I watched myself more than a decade ago, but after I did, I agreed that this was overall a good show. (If you have Netflix, the anime version of the Cowboy Bebop is there too, all the 26 episodes of it. There is also a movie which isn't on Netflix, but you don't miss much if you don't watch it, although I think the opening song of the movie is cool.)

OVERVIEW
--------

Now, I'm here to talk about the live-action adaptation. Many youtubers and podcasters have commented on this, and usually I don't bother to comment on things that people have already commented - but I will make an exception here. I will have to emphasise that my opinion is my own; if they sound similar to what others have said, it's probably because we all share similar sentiment.

There is a meme that any Netflix adaptation ends up turning into trash. I don't know how true is that, I don't watch Netflix that much (there are more important things to do in life other than spending all of your free time watching other people's imagination), but I will say that in the case of Cowboy Bebop, they do a very bad job on it.

Season 1 was released with 10 episodes in it. I watched the first episode and my stomach churned. But I might be biased, so I gave it another chance and watched the second episode. It made me want to throw up, but, hey, third time's lucky right? After watching the third episode I think I have torturned myself enough. To top it off, I happened to watch a video clip of the last few minutes of the episode 10. When I watched it, I thought it was a joke made by someone who hated Netflix (or the show, or both). I went back to Netflix to check it ... lo and behold, that extremely tasteless cliffhanger __was__ there. It's so bad, even if you don't know anything the show, I __guarantee__ you that you will be turned off too).

A lot of the opinions so far have talked about the actors who played the adaptation, about the various race-swap and gender-swap (seems to be a feature of any movie in the last few years or sos). I don't want to talk about these, I think those points have been well rehearsed everywhere else. I don't necessarily agree or disgree with these opinions; but today that's not what I want to talk about.

I'm a writer, so my point is focused more on the story, the plot, and the characters.

To start off, this thing is supposedly a "live-action adaptation". It's not a reboot. It's not a remake. It's not re-imagination. It is an "adaptation". And yes, sure, adaptation means you have the freedom to change some of the details, insert new stories or previously unexplained back stories, etc. But it has to be consistent; at least, it has to be consistent with what have been established before (otherwise, it's really different show, isn't it?)

And lack of this consistency is why it sucks and sucks so badly.

THE CHARACTER
-------------

I will start with the bold conclusion that just by looking at the characters only, the live-adaptation of Cowboy Bebop is __not__ Cowboy Bebop. Or, equivalently, it is Cowboy Bebop in name-only. Yes, they have characters with the same name, these characters live in the same ship, the same universe, supposedly - but __everything else__ is different.

Let's start with Spike.

The anime Spike isn't the same as the live-action Spike. They don't share the same principles, they don't behave in the same way, they don't interact with others in the same way. They have different values, they care about different things.

There so many differences, but I will mention only one thing which is enough to spoil everything.
* The anime Spike is a man who doesn't care whether he lives for the next day or not.

* The live-action Spike pretends to not care whether he lives or not, but in reality, he really does __not__ want to die.

The difference seems subtle, it's not. The anime Spike is a man who has nothing else to lose. A lot of the (careless) actions in anime Spike can be attributed to his attitude to life; which couldn't be explained otherwise.

The live action Spike, however, is the opposite. He really cares about living and continue living. So why does he behaves so carelessly either? Because he's a hero? Because he's kind-hearted? Because he's arrogant? Because he's a jerk? Because he's just careless? Pick any reason you want - you will still find that this is not the anime Spike in the end.

How about Jet?

In the anime, Jet was like a big brother to Spike. He has his own share of bitter past, and like Spike, he had resigned to it and just live day by day. Being older, he is a tad wiser, and knowing Spike's past, he acted more than just a friend and a parter, he acted as a sort of surrogate big brother to Spike. Of course, he gets annoyed from time to time - but he didn't pick up fights or whiny for the sake of being whiny. He was trying to turn Spike into a better man.

The live-action Jet, however, was just a whiny partner. He was whiny, and complained too much, just for the sake of being whiny and irritating. I understand the writers' intention to intensify the "sarcastic banter" between the two, but I think they dialled it way way too much, to the point that Jet had become an annoying character. Really with the amount of animosity that Jet showed towards live-action Spike, I wonder why he didn't bother to kick him out altogether already (the "Bebop" ships belonged to him anyway).

I mean, I wonder why the live-action Jet took the live-action Spike as a partner to begin with. He didn't know Spike's past (Spike's lying to him, basically, that's just another one trait that differentiates anime Spike and live-action Spike), but still, if you're an ex-policement turned bounty hunter (with potentially lots of enemies), you __really__ want to check that your future live-in partner wouldn't want to slice your throat when you are sleeping, don't you? Sheesh.

As for Faye - I can't say much about Faye. I only saw her in the first episode, and she didn't get much airtime there. Not saying I like it, or agree with her acting or writing; but I've just not seen enough to make a decision.

But surprisingly, I have seen Vicious in the live-action, and too much of that, for that matter, in just 3 episodes.

In the anime, Vicious was not introduced until a bit later, and even then, when introducted, he was not introduced as anything special, other than being a person from Spike's murky past. Only much later it was revealed that in addition to being a highly skilled fighter, he is also a masterful strategist; ambitious and cold as a block of ice. It is easy to imagine that a person of this quality can rise through the rank to become a high ranking official of the mob. He was Spike's equal (or copy) in almost everything, except that Spike had left the dark side and he chose not to. That's why he was such a threatening archenemy: because they were equals.

The live-action Vicious is really a parody of the anime Vicious, really. Firstly, for a supposedly important archenemy, you reveal him in the first episode, with his names, his face and whatnot. That's a real grand entrance, boys and girls. First episode! Secondly, and most importantly, you will quickly learn that the most prized trait of this "grand enemy" is his nastiness. Other than that, he's somebody an easy-to-anger, greedy, careless, incompetent petty thug who likes to claim how "good" he is. He's so weak that Spike could easily kill him anytime he wanted. And then you make the entire season's plot to be the conflict between these two guys? Come on. I can't even reasonably think how the live-action Vicious earns his position in the mob.

THE PLOT
--------

And then we have the plot. The anime was a series, not a serial. You can watch any episodes in any order, apart from two parters and "deciding episodes" (where a member joined or left the Bebop), and not missing anything.

The live-action, however, made it obvious that it was a serial. You have to watch all of them, and __in order__, or you'll miss the plot, literally.

But that's not the point of contention. It's okay to "adapt" a series into a serial, provided that you do it right. Provided you can capture the spirit of the show. As I said above, you don't have to keep all of the original materials. You can keep some, and insert other new materials - as long as you remain consistent to what show is all about.

The main plot of the anime is how three broken people, people who have no hope for the future because of broken their past, continue to stay alive as they slowly learn to overcome their brokenness and learn to look forward to the future, because of the odd kind of friendship that formed in the shared events that they experience together.

The main plot of season 1 (based on what I've seen on the 3 episodes, and based on the one-sentence plot summary provided by Netflix itself), seems to be the on-going conflict between Spike and Vicious.

Of so many plots they could use, this one - for me at least - is the least interesting plot there is. The live-action shows Vicious as early as the first episodes, and it tracks what he does on almost every episode (at least on the episodes that I watched). At 3 episodes, I still haven't formed any bonding with the characters (Spike or Jet), and I couldn't care less about their supposedly "archenemy". Archenemies are only important once I've emotionally invested enough with the characters; but this certainly don't happen in episode 1, 2 or 3.

Okay, there is conflict between Spike and Vicious in the anime too, but it __isn't__ part of the main plot. The open conflict is only shown in two episodes - the episode which introduced Vicious, and an episode where the two have the final showdown. For the most part, they didn't care of each other, unless there was some shared interest (or accidentally crossed paths). Otherwise, Spike couldn't care less about Vicious, and Vicious wasn't obsessed about murdering Spike either. So why elevate this highly unimportant sub-plot to be the __highlight__ of the show?

I have enough of watching shows about two guys with personal conflict having a go with each other. It simply doesn't click for me; it's __not__ entertaining. Firstly, as I said, I don't care about the conflict if I don't care about the characters. Secondly, I don't have to watch movies for that; the newspaper writes about this kind of stuff everyday.

THE SHOW
--------

Then the show itself. Being a show about bounty hunting, there are bound to be fights, shootings, explosions, etc. But the anime make it clear that it was not an __action__ show. Every scene was there for a reason. Fightings, for example, is not there for the sake of showing the figthing, but also to show the (sometimes hard) choices that the character have to take during he fights (or not fight).

In the live-action, the fighting is there just for the sake of the fighting. Not saying the fighting scene is bad in itself, but it really felt like a generic fight scene without any emotion in it, no connection to the story (other than the sarcastic remarks - something which was used aesthetically in the anime, but way too much in the live-action it became so farcical and predictably boring). If I want to watch an action movie with a lot of fights, there are much better shows.

In the anime, the fighting is there to advance the plot. In the live-action, the fighting is there for the sake of showing off the fights.

And then the constant bickering between Spike and Jet. In the anime, they don't bicker. They argue, but not all the time. Most of the time they are in (silent) agreement. When there are serious problems, they don't just bicker. Things happen. Spike left Bebop temporarily because of a big argument with Jet. That's how adults behave.

In the live-action, they constantly bicker with each other. It's really unbearable listening to two grown-up men who are supposed to be friend and partners constantly being sarcastic to each other. As I said earlier, I find it extremely odd why Jet doesn't kick Spike out of his ship already; and how Spike could keep up with Jet's whining.

It feels funny on how they try to bring more "realism" into the live-action adaption, and tries to "explore" the "depth of the emotion" encountered by the characters by amplifying their edgy traits, but only succeeding to make the live-action character as a parody of the anime's version of them.

Oh, and one last thing (ending of Episode 1 - you can compare the live-action and anime version): In space, nobody can hear you when you scream. Or plead. Don't forget that.

CONCLUSION
----------

I am not the only one who complain about it. I watched the original Cowboy Bebop anime back in 2003 or 2004, and I have re-watched the series twice in the intervening years. On the last re-watch, my son watched with me as well.

We both watched the live-action; and we more or less came to the same conclusion. In fact, he told me that he specifically doesn't want to watch any further, as the live-action __ruins__ his experience. And my son is in the millenial generation, supposedly the target audience for this kind of show.

This show is Cowboy Bebop in name only; but otherwise it's not even close to the anime.

Enjoy the show if you like it, but for me, the show ends at episode 3. The whole thing just looks like and feels like a cheap comedy about bickering partners and a soul-less generic fighting action show. The spirit that makes "Cowboy Bebop" iconic is simply missing in the live-action adaptation. I would rather use my free time to do other things (or watch better shows, perhaps, a repeat of the Cowboy Bebop anime).

The Abolition of Man

I've just finished reading it, "The Abolition of Man", by C.S. Lewis. At about 81 pages (excluding the generous appendix and notes), it is a very worthwhile investment of your time.

If you think that "1984" is prophetic, wait until you read this book.

If you espouse the idea of The Great Filter - you might finally have a glimpse of what it could be.

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.

More apologies ...

If you apologise without admitting you're wrong, does it still count as apology?

If you apologise without promising you won't do it again, does it still count as apology?

If you apologise without reparations, does it still count as apology?

If you apologise on behalf of someone else, while that someone else clearly is neither sorry nor repentant, does your apology even have meaning?

Apologies, and donations

If you are forced to apologise, does it still count as an apology?

If you are forced to make a donation, does it still count as a donation?

If you are forced to be kind, does it mean that you are a kind person?

Is the action more important than the motive? Or is the motive more important than the action?

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.

Empty shells

I have been playing video games recently and are struck on how good games has progressed since the days I played Lemmings and Doom.

What struck me was mainly how good the graphics look like, how life-like it has become; especially when the game protagonists are humans. Their faces are pretty and handsome, their bodies are perfectly proportional and toned, their movements are graceful.

No doubt, this is due to the talented artists that created meticulously them, from draft drawings, 3D modelling, skinning and texturing, and motion capture; it is also the attestation of the immense computing power of modern GPUs. When combined with talented voice actors, the imagery is complete - we are, definitely, in the uncanny valley.

However, no matter how real these characters look like, I cannot drown a tiny voice in my head that keeps saying that what I see is all there is. There is no depth. There is no substance. All I see is literally skin-deep. Underneath the skin of that pretty girl or handsome man, there is nothing. They are hollow. Literally. They are just million of triangles covered by textures; voiced by someone else with stories which aren't their own. They are just empty shells.

But sadly, there are people - real-life people - who are real-life versions of these empty shells. They do have flesh and bone, and will bleed if hurt; but otherwise, what you see of them, is all there is. There is no depth. There is no soul. They speak with with other people's voices and their life are other people's stories. There is nothing else beyond what the eyes can see or the ears can hear or the hands can touch.

Beware that you don't fall for these empty shells. For beneath their skin, there is only nothingness that awaits you.

Even more important, is to beware that you don't become empty shells yourself. Focusing on the outside, but forgetting the most important part of yourself - what's inside.

For when that happens, you become nothing.

Ants in a terrarium

Imagine ants in a terrarium.

They are born there, they grow up there, they go about their daily life, and they die there too.

Lets say that there are multiple queens, each commanding multiple her own colonies of ants. Every ant will scavenge for food for its colonies, but they also fight for territories, and sometimes attempt dominion over other colonies. Generations of ants are born, alive, and die over time.

The ants think their problems are important, their possessions are important. Their territories are important, their dominion of other colonies are important. They think that they are important.

But they are just ants living in a terrarium.

---

(Originally contemplated on Feb 2006)

Christmas wishes 2020

Any bad things I did, I did it because of my own failings, so please forgive me.
Any good things I did, I could only do it because God has helped me, so to God all the glory.

Merry Christmas everyone.

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.

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.

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

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!

Goodbye to a friend - John de Murga

John de Murga (aka John Murga) was the owner of the official Puppy Linux forum, formerly located in http://murga-linux.com/puppy/index.php

If you use Fatdog64, you will know that we hosted our support threads on the same forum.

But my involvement with the Puppy Linux forum dates back well before then. I started browsing the forum when I was still a Windows user back in 2006; and joined in 2007 when I was converted into Puppy Linux user - and had been a regular on the forum ever since. Until the forum went down in early July 2020.

---

But in all my years being John's forum, I don't really know John Murga. Not personally. Never met him. Never spoke with him. Not even knowing how he looked like - well, not until a few days before I wrote this. Not through my fault though, I only know bits and pieces that he himself chose to share, for he himself claimed to be 'the man of mystery'.

He and his work, however, left an indelible mark on my life. It was such a simple work. Setting up an online forum. What was so difficult about it? Get a web-hosting site. Click a button, and you've got a forum and up running. Easy. Everyone can do it, right?

No. Not every one can do what John did.

The forum he set up was the forum where I spent lots of my past life on. Where I got help when I started and when I stumbled. Where I, eventually, helped others as I became proficient enough. Where I, unexpectedly, met and became friends with people in the real world.

All of these because he had the tenacity to keep the forum going for 15+ years; and let the forum to govern itself instead of strict policing found in many others. He even had the magnanimity to allow people to post links of competing projects and forums. This was one of the factors why so many people stayed on and the forum grew to become the melting pot of folks from all walks of life, sharing the same interest - Puppy Linux, and Linux in general.

So it was great shock and sadness that I learn of his passing recently in May 2020. I was even more stunned to know that he had left a young family - a daughter and twins who were born shortly after his passing. I have young children myself, I could not even begin to contemplate how it must have felt, to be left so soon, and so suddenly.

Nevertheless, I would like offer a prayer of hope for whom that John's family, that John had left a legacy that not many people could manage to do: to change the life of thousands, if not then ten thousands. John had left many friends that he himself probably didn't know. I was one of them, one among the thousands. For us, he is a hero. In every sense of the word.

Goodbye, John, and all blessings in your next journey.

You will be missed, but not forgotten.

---

Eulogy from 01micko, the current steward of Puppy Linux

Eulogy from Barry Kauler, the creator of Puppy Linux

Memories

“And this world will stay with you, forever. You will keep it in your heart. We are ephemeral creatures; we always live in the present. We jump from one moment to another; memories are all that we carry within us. Even if you won’t ever visit this place again, it will still be alive in your dreams, every time you recall them.”
---
The Book of the Ten Children, Reunion Part II:Epilogue

Fatdog64 updates - behind the scenes

Fatdog64 was last released on 23 Jan. And although we have been quiet, it doesn't mean that things stopped. Things are still going in the background, bug fixing, adding features, etc.

Here are a few major things that has been going on, in no particular order.

1. Puppy Linux forum user ICPUG has indicated possible issues with Fatdog savefile residing on an NTFS partition, especially partition shared with Windows. This is due to the way Fatdog uses ntfs-3g: it runs with full permission control enabled. It makes NTFS behaves like POSIX filesystem and we can use it for save directory (not only save file), but on the other hand it makes Windows complain about not-granted access each time the partition needs to be accessed from Windows.

Based on this feedback, we have added "ntfsnoperm" boot parameter to disable that permission control. When this parameter is used, ntfs-3g is run without permission: it would behave just like FAT filesystem (all files and directories are owned by a given uid/gid specified at mount time). It would not be possible to use a save directory on NTFS, but at least the permission wouldn't be touched and Windows will stop complaining.

2. The same ICPUG also found an old bug related to the above: where the user "spot" would be unable to access a Downloads folder that has been relocated to a save partition if the save partition is NTFS. This has been fixed.

3. Fatdog has long supported btrfs. The kernel is built to support btrfs and we have the complete btrfs-progs included; and nominally we support having save directory on btrfs. But this does not actually work; because "aufs" - the unifying filesystem layer that we use to make the magic happen, does not support btrfs the way it supports other filesystem. For the techie: the problem is that aufs cannot have its xino file inside btrfs. It has to be somewhere else.

Thanks for our team member SFR (his Puppy Forum name), this was brought to attention and he shared a fix too. The fix was tested, worked on, and finally merged: now, save directory will work seamlessly on btrfs-formatted partition.

4. The original motivation for doing (3) above was actually to attempt to use a compressed filesystem. This has been a particular interest for me for years. The last time I explored this (a couple of years ago), btrfs wasn't mature enough and there was no other native writable filesystem with compression support. Sure, there were native filesystem with compression support - but they were all readonly (squashfs being the most popular one). Sure, a couple of FUSE filesystems support compression too (in fact it's their number one feature), but they were not actively maintained and being done in userspace, it was slow. I never got enough motivation to implement them properly with Fatdog.

Btrfs finally changed this equation. By now it should be considered mature enough (although probably not as hyped as before), and it supports compression as well. In fact, it supports three different compression algorithms: lzo, lz4 and zstd.

So as we fixed btrfs save directory support, we grafted compression support too. If the kernel parameter "btrfscompress" is specified, the compression support for btrfs will be enabled, using the algorithm specified on that parameter. This has been tested to work wonderfully and using zstd, the compression rate is about 30% on average.

5. We have an update on the in-house "screencaster" application (a program record the video of the display). It now has the ability to take repeated screen capture, better quality video, among other things.

6. Step, another member of Fatdog team, has also revamped the "Samba Shares" application. It has been re-factored and is heavily tested to work across different Samba servers (different Windows versions, etc).

7. We have also fixed a long-standing bug when running Fatdog with RAM layer operation, which can cause inconsistencies if the system is heavily used (a lot of filesystem access) when the "merge down" process happens. SFR found this to be irritating enough to find a solution that works better; and this got incorporated into Fatdog.

An additional feature was also added: the ability to remove whiteouts if they don't hide any files on the lower SFS layers, but not activated by default due to possible conflict with multisession operation (we haven't tested the interaction yet).

8. We also include the "updater script" which re-enable VLC's ability to play youtube video directly, without having to update VLC itself. The script is called update-vlc-playlist-luac.sh. SFR found this script.

And of course, many other smaller bugfixes and feature addition, as well as adding and updating packages on the repo as well.

So when will we have a new release? Well, it will be released when it is released.

The road to hell is paved with good intentions

Good intentions, good deeds, now matter how good they are, when carried to its logical conclusion, always lead to destruction.

Because when we go north to reach the most extreme northern point, without knowing what the north pole actually is, we will never reach it.

We need directions. We need sign posts. And fortunately there are sign posts and directions to north pole, if that's all we want to go.

How about sign posts of life?

There is this someone. He called himself as The Way. The Way that will lead you to the Truth. The Truth about Life, and beyond. The Truth that will set you free.

But He, like all sign posts, doesn't demand that He be followed.
It is up to us if we want to.

Nothing to Fear, but Fear Itself

Thus said Franklin D. Roosevelt, the 32nd president of the United States, even though I'm sure many wise men before him have said the same, although, perhaps, not in the same exact words.

Fear of something is almost always worse than that something itself.

Love at first sight

"Love at first sight often ends at the first quarrel."
---
The Book of Ten Children, 1:2

Fatdog64 810 Final is released

Maintenance release, basically a bug-fixed version of 810 Beta.

Release Notes and Forum announcements

Can't believe that Fatdog is coming to its twelfth year.

Download locations: ibiblio.org, aarnet, uoc.gr, nluug.nl.

CSVfix patches for regex and exec

CSVfix is a tool for manipulating CSV files. Along with the usual column re-ordering and filtering, CSVfix offers a powerful per-cell data transformation using a simple expression language, as well as regular-expression for string matching and editing. And if this is not enough, CSVfix can execute external process - for every cell that needs to be processed. And oh, it's available for Windows too!

I find this tool to be very handy in what I need to do, so when I encountered a bug in its regex processing (for its "edit" command), I immediately checked if there is any updates to this tool. Unfortunately, its development seems to have ceased in 2015; and no other people seem to have picked up the development (I did find some forks, but they were all older copies from when it was still hosted in google code).

So I set out to figure out about the problem and hopefully rectify it. I found that the problem was in its regex library, which was a home-grown library (apparently adapted from an algorithm book). It is 2020 as of this time of writing, and C++ now comes with its own STL regex library (std::regex). I decided to rip off the custom regex lib and replace it with the STL regex instead, while keeping the rest of the class interface identical, therefore no other part of the code needed to be changed. This instantly fixed the problem, and as a bonus, now we can use ECMAScript-compatible regex instead of just the basic regex.

Later, I found out that the "exec" command also had a bug (the flag "-ix" did not work properly), so I traced this and fixed it too.

Oh, and during the process, I tried to run its testsuite - and while most of them passed, some did fail. Mainly because of CRLF/LF inconsistencies, so I changed those the test data to use LF. It is also a warning that this tool only works with platform "newline" - CRLF in Windows, and LF in Linux - so if files were to be exchanged between platforms, they must be properly translated first before use.

Here are the individual patches.
- regex patch
- exec patch
- test-case patch

They apply on top of the commit 93804d4 from 2015-02, which was the latest when I wrote this. They are licensed in the same way as the original CSVfix is licensed.

If CSVfix is not powerful enough for you, there are other similar tools:

1. miller is a tool in very similar spirit with CSVfix, but it is (much) more sophisticated. Its "data transformation language" looks more expressive than the one in CSVfix. If you have a problem you cannot solve with CSVfix, miller will probably help you. As a bonus, it is still in active development - that means bugs will be squashed. It is written in C, you will need to compile it if it is not in your package repository. (Fatdog, naturally, has it in its repository).

2. csvkit is a collection of tools that more or less perform the same functions as CSVfix. It supports direct conversion to/from Excel files, importing/exporting into databases (sqlite and postgresql as documented, perhaps others too), as well as running direct SQL queries from CSV files (and databases too). It is written in Python3 so you can install it using pip3. Fatdog has this in its repository too (so you can install it using package manager instead of pip3).

3. rbql basically enables you to run SQL-like on CSV files; but its power is its ability to run python (or javascript, depending on which backend you choose) code for every cell. Fatdog has it in its repository too, although you can just use pip to install it, if you don't run Fatdog.

The Good Book

Everyone keep two books. The "good book", and the "bad book". People that we know, we like, and generally we like to be associated with, is in our "good book". People that have hurt us, or people who behave in a manner that we despise, on the other hand, get their names written in our "bad book".

Being listed in either book have consequences, both good and bad.

Now, God carries two books too. Would you rather be in men's good books, or God's good book? How do you live your life - are you striving to be in God's good book, or to be in other men's good books?

Welcome to the new decade ... or not!

This new year 2020 is a new year that is divisble by ten. It changes the second digit from "1" in 2019 to "2" in 2020.

A lot of people are wishing me happy new year and also welcoming me to the new decade. I am grateful for their well-wishes.

Except for one thing.

2020 is not the start of the new decade. Just like year 2000 is not the start of the new millenium. The new decade starts at year 2021. Just like the 21st century starts at 2001, not at 2000. Year 2000 belongs to the 20th century.

In case you don't see why: it is because we start counting our calender at Year 1 AD. So the first decade - all ten years of it - would be the counting numbers from 1 to 10. The second decade starts at year 11 AD.

But of course, I'm being pedantic. Who cares anyway. Calendars have always been subject to various "adjustments"; and different cultures use different calendars. Those still using Julian calendars have not celebrated the new year yet, it is still 9 days away at the time of writing.

PS: We do not have Year Zero. The year before 1 AD is year 1 BC.

Fatdog64 810 Beta is Released

Maintenance release.

Release Notes and Forum announcements

Download locations: ibiblio.org, aarnet, uoc.gr, nluug.nl.

The Author of Life

I am an author. I write both fiction and non-fiction works.

When I write fiction stories, I make and write my own characters. These characters are people who live in my fictional world, fictional universe, oblivious to the fact that they are all fictitious. For them, everything that happens in their world is as real as it could be.

Now, of course, those characters I have created: they are not independent of me. They exist because of me, they exist in me. Eventually, I do get to decide that they see, that they hear, what they feel, what they do. I determine their fate, their destiny. I set how life is going to be for them, and what revolves in their world.

But they are not just characters, or puppets. In my mind, they are alive, and I'm only writing part of their life that I happen to see. Not only that, I love my characters, and I care about what happens to them. Certain characters are lovable, and some are detestable - but I certainly care about all of them.

I wish - if it were ever possible - to actually meet my characters, in their own universe. See how they live, how they feel. Feel their joy, and suffer their sadness. Be one of them. And tell them, how much I care and love all of them. That all of their life has meaning to me, their author.

---

If you are an author, or an artist of any kind that loves your own created arts, it is easy to see that you, too, is a work of art of an omnipotent Author, that is, God.

When God paints, you see the flowers, country side, and the star constellations.
When God sculpts, you see the mountains and the Laniakea supercluster.
When God builds, you see the quarks self-assembling to atoms and the visible universe.
When God engineers, you see protein machines and solar systems and life.

And when God writes, you see yourself.

You exist because of Him, your Author.

He cares about you, more than you care about your own creation.

He loves you so much that He gives you life, and more: something that you can never give to your own creation: a free and independent mind to decide what you want to do about Him - whether to love Him back, or to reject and deny Him.

He loves you so much that He came into this world, to feel its joy and suffering, and to tell you that He love you, and to tell you that your life is meaningful, and that there are more to your life than just this world; He showed the way to Himself.

I thank my Author for giving me life.
I thank my Author for loving me more than I love myself.
I thank you, Lord Jesus, and I long to see you face-to-face when the time comes.

Life is like a harddisk ...

With every new day, we savour new experience... keeping it in our memory. As time passes, we buried our moments deeper in the hierarchy of directories. Over time, we forget what we know.

Sometime, we feel that life is too much for us - that's when it's time to dig into our repositories and delete unnecessary files and folders, so that new experience can come in.

There are times that we still feel burning anger and hatred or sick to the stomach of somebody or something, though we thought we have forgotten it... it's because the file is still in you, in the recycled bin or trash folder. You need to really empty it to let go, and life will begin a fresh.

The only thing is, we cannot buy a new life like we replace a damaged harddisk or upgrade its capacity... but then, who needs to upgrade? Unlike a harddisk that comes with a predefined storage size, our capacity to absorb experience and live to the fullest is unbounded - provided we know how to not keep the bad stuff.
---
Originally posted 18 August 2006, before the advent of SSD.

What is reality

What’s reality, he thinks. Alone, in this world, he can no longer differentiate between dreams and reality. He has no reference to compare things with, and when this happens, there is no way to weight any evidence against any standard. He shouts, and echoes comes back to him, and he does not know whether someone hears his shout or not. But he cannot be sure whether he just thinks he shouts or he actually does shout. Nothing to check against. It’s the point of when and where reality blurs with dreams and nightmares.
---
The Book of Ten Children, Reunion:4. Originally posted in 11 November 2006.

Tomorrow is promised to no one

“I am still making peace with them, every single day,” she said softly. “That’s why I don’t want you to go when you were still upset with me. If bad things happen to you – perhaps you lose concentration in your battle against the bad guys, because of me – then really, I’m not sure I can live with it. It’s already difficult with my parents. I can’t let it happen to another person that I really care about. At least, before you go, I want to have peace between us. I can’t wait until the next time you come again, because tomorrow is promised to no-one.” she said with trembling voice.
---
The Book of Ten Children, 5:5

Fatdog64 801 is Released

It is a rolled-up updates, containing bugfixes and minor feature updates.

Release Notes and Forum announcements

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

ISO Builder: Get it from here: http://distro.ibiblio.org/fatdog/iso/builder/ and choose the builder dated 2019.05 and the package list for 801.

Enjoy.

Today is Ash Wednesday

Count your blessings!

Fatdog64 800 Final released

Just two weeks ago we released 800RC. Based on the feedback and our own day-to-day usage, we feel that it is now stable enough and can used to replace the last stable version of Fatdog 721, hence the final release.

The list of changes from 800RC isn't many, and you can check them out in the Release Notes. Forum Announcement is here.

You can get it from ibiblio and the usual mirrors:

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

In this release we also publish the ISO builder suitable for making your own custom versions of Fatdog64 800. Get it from here: http://distro.ibiblio.org/fatdog/iso/builder/ and choose the builder dated 2019.02 and the package list for 800.

Enjoy.

Fatdog64 800RC Release

About two and half months after the initial 800 Alpha release, we finally release the first Release Candidate (RC). There is one beta release in between on 20 December which I didn't get to announce here (Christmas time - busy days).

As usual it's package updates and bug fixes - but mainly bug fixes. Not only regressions caused by new packages, but also long-standing bug fixes from earlier version. Hence the recommendation to update. On my last test, I could still run this release on a 1GB Intel Atom N450 Acer eMachines netbook from ca. 2012; so if your machine is similar or more powerful than that, you can run it too.

If things are going to plan and there is no embarassing bugs, this release will become final.

This is the Release Notes; and this is the Forum Announcement; but if you're not familiar with the Alpha or Beta release I would suggest you read a little bit on both. We will probably copy and consolidate all the changes for the Final release, but not until then.

You can get it from ibiblio and the usual mirrors:

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

In this release we also publish the ISO builder suitable for making your own custom versions of Fatdog. Get it from here: http://distro.ibiblio.org/fatdog/iso/builder/ and choose the builder dated 2019.02 and the package list for 800rc.

Enjoy.

How to destroy FOSS from within - Part 5

This is the fifth and final installment of this article.
In case you missed it, the these are part one, part two, part three and part four.

The last time I wrote about this was the beginning of 2018, where the outlook was bleak with Spectre etc. Well here we are in early 2019. The world didn't collapse, so there is still hope; so I too would end this series with a hopeful note.

Part V: Can we do anything about it?

The article was originally a four-parter. But I don't want to end it with a depressing note, so here is the final part, and hopefully more uplifting that the previous parts.

Let's start by observing that "only in democracy the people can vote to elect a dictator". Yet, we don't see hordes of democracies tumbling into dictatorships. So there is still hope for democracy.

Which, I hope, also means that there are still hopes for FOSS.

One way I can see, is to have independent talents that oversees the project; as well as independent talents that actually contribute to the project. (Being an independent leader is meaningless if all the do-ers are against you - remember this is do-ocracy right?).

FOSS flourishes when there is a constant flow of talents going into the community. People don't become expert overnight, but those with enough motivation and effort can always start at the bottom of the ladder and acquire the skills as they continue to participate over time, with mentoring from the older guys.

Alternatively, when a project becomes too unwieldy; perhaps it is a better idea to start with a new codebase, clear from "legacy" stuff and therefore easier to understand - but with still remembering the lessons learnt from that legacy code (or else the new code will be doomed to repeat the same bugs are the legacy code ...).

How can we keep the independent talents coming into FOSS?

I don't have an answer. I can only say that hope springs eternal. Everyone has an itch to scratch: I have seen people take up impossible projects or coming up with impossible replacement projects. New FOSS software coming out from research projects or from student thesis are still happening. So things still does happen. But the trend isn't healthy. And perhaps we all should think of what we can do to help.

THE END

After-note 1
Some FOSS projects are originally closed-up products opened up by the original company owner. Also, some companies open-sources their products for the "community" and changes for "premium" or "enterprise" version, which is not FOSS (the "freemium" business model). I have nothing against this; and instead applaud those companies who have chosen to open source their products.

In this situation it is normal and fair to expect that the direction of these projects continue to be dictated by the original owner, especially when most of the development are still done by the company's own employees.

The FOSS projects that I'm concerned with are those original grass-root community projects (or once-closed-but-now-opened projects that are no longer controlled by the original authoring entities) that have risen to the top of the mindshare, but are no longer recognisable as such due to these undue influences.

After-note 2:
One must not conclude from these articles that corporate contribution (in terms of money or employee time) into an FOSS project is automatically bad and unwanted. It is not; and in fact many projects won't be as successful or survive without them.

We welcome contributions from anyone in any form, but what we need to ensure is independence from external influences.

World map stat counter update

It was over five years ago I wrote this stat counter (here and here).

The world has since moved on, IP addressed have changed hands (and locations), and even the database format has changed. If you still have a copy of the old MaxMind GeoLite database, the old program would still work but if you don't - well, MaxMind has deprecated the old database format as of January 2019 and you cannot get a copy of it anymore.

However, MaxMind still offers freely downloadable geo-IP database, in a slightly different format (GeoLite2). I have now updated the world map stat counter to work with this format.

You can get the updated sources (along with 32-bit statically compiled binary), here. The GeoLite2 database is here and you need a "converter" (to convert the CSV file from network format to integer-range format) here. Then read the original articles and you should be good to go. The v4 has "2" appended to all the programs - ipgeocode2, preprocess2, etc so they can co-exist with the older version if you so wish.

The Road to Fatdog64 800 Alpha

Today, the first of Fatdog64 800 series is released to the wild - the Alpha release. Despite being labelled "alpha", this release has been tested for a few months and has been used day-to-day in real production machines (in varying degrees) for about two months by all of us, in the team.

It has not been a smooth ride all along. Living in the "bleeding edge" means that you really need to prepare to bleed (that's why we don't update the base on every release - it would be downright impossible). Latest packages don't always build, and when they do, they don't always run, and they do, they don't always run stably, and when they do, they don't always work, and when they do, they don't always work correctly, and when they do, they don't always provide good performance, and so on, and so on - you get the picture.

But we have finally arrived. It may not be perfect, and it never will, but for us - it is good enough for day-to-day usage; so the decision to release.

This blog post documents a few of the stumbling blocks that we passed through on our way to the Alpha release. By sharing the knowledge, I hope that others on the same journey can avoid them.

Warning: the information that comes after this is going to be very technical. Don't worry if you don't understand it - just use whatever that you do.

The particular bug that took as considerable time (weeks) to solve was this: it's a bug that causes the desktop to unpredictable, involutary exit to the console.

And it turns out, this problem has __multiple__ underlying causes. Each cause ends up with the X server exiting (sometimes gracefully and sometimes not) so that we're dropped back the console.

Sometimes there crash messages in Xorg.0.log, sometimes don't. Sometimes the exit is immediate (X goes down and we're back in the console), sometimes it's gradual (applications start to fail one by one, before X itself finally gives up its ghost and dies).

Bug #1: fontconfig doesn't like its cache to be tampered with.

This bug happens only when running with the RAM layer (savefile=ram:device:xxx, in Puppy's parlance this is pupmode=13). When anything that uses fontconfig starts (e.g X, gtk2, etc), fontconfig will be initialised and its first action is to scan all the font directories and makes its cache.

When we run using the RAM layer, these caches are stored in the RAM layer, and eventually will be "merged-down" to the actual savelayer (copying the files from the RAM layer to the savelayer, and then removing the copy on the RAM layer, and then refreshing the aufs layered filesystem so that the copy on the RAM layer gets re-surfaced on the root of the filesystem).

This has worked for the longest time, but we found out that in Fatdog 800 this isn't the case. Even the process of copying the files from RAM layer to savelayer (not even deleting them) triggered a cascade of failure in fontconfig, which eventually resulted a crash in all higher-level libraries and applications that uses this.

Fixes #1: We still don't really know what changed - this could be a change in the kernel, fontconfig itself, glibc, or others (remember, in 800, with a new base, **all things were updated** so we can't easily isolate one component from another), but once we know what triggered the collapse, we worked around it by making sure that fontconfig caches are not touched during the merging process.

Bug #2: Xorg server crash on radeon-based systems when DRI3 and glamor is enabled (the default settings).

This has been a long running bug due to Mesa (open-source OpenGL 3D library) changing its infrastructure to support newer, more powerful radeon cards, changing both the acceleration API (DRI2 to DRI3), acceleration methods (EXA to glamor), memory management (GEM, GBM, etc).

But the bug isn't in Mesa alone. Eventually Mesa needs to interface with the video driver, so co-operation with xf86-video-ati driver is needed.

And then there is the kernel too, the radeon DRM driver from the kernel.

There are multiple components and every component is a potential source of failure (which in this case they all contributed to the problem one way or another).

To make it worse, the problem is completely unpredictable. The system can run hours without a glitch before the desktop crashed, or it can crash in next hour after booting. It brought a completely un-reliable experience.

There is no good solution for this because every component keeps changing, so updating one component could very well break another. All we can do is watch bugzillas, forums, mailing lists, and listen to possible solutions.

Fixes #2: I think in this case, we got lucky. Most of the bugs were fixed in mesa 18.2.3, and the final bug was fixed in xf86-video-ati git-master, one commit after 18.1.0. We're going to stick with this combination for a while!

Bug #3: After an unpredictable amount of time, Xorg server will crash (due to failed assert), giving up messages similar to this:



[xcb] Unknown sequence number while processing queue

[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called

[xcb] Aborting, sorry about that.

pidgin: xcb_io.c:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

There is one unanswered report here: https://bugzilla.redhat.com/show_bug.cgi?id=1582478

This initially happened on ROX-Filer when it was worked heavily, so naturally we thought the problem was with ROX-Filer. But then it started to happen elsewhere (other GTK applications), so it could be anywhere in gtk2, glib, glibc, aufs kernel module, or even the kernel itself.

We scoured for solutions for similar problems, and we got some solution like this: https://forum.freecadweb.org/viewtopic.php?t=28054

But they don't work and they don't make sense. FreeCAD is a 3D-heavy application, so disabling DRI3 and (in some others links, disabling 3D hardware-acceleration) doesn't make sense for applications like ROX-Filer which is purely 2D and doesn't make use of any acceleration at all.

This was especially difficult to pinpoint because it happened randomly; and it was one of the thing I would have filed into "unsolved" files, were it not for SFR. SFR found a way to reproduce this problem reliably (by clicking the "refresh" button on ROX-Filer a few hundred times - and he even provided a automation script so we don't have to buy a new mouse after every experiment ).

Once we can reproduce this, re-building the libraries with debug symbols and running them under "gdb" quickly pointed out that the problem is within libxcb - a library at the bottom of the Xorg stack.

Bisecting on libxcb, we found that the problem is caused by a particular code commit that tries to "fix" another bug when dealing with Vulkan drivers:

https://cgit.freedesktop.org/xcb/libxcb/commit/?id=fad81b63422105f9345215ab2716c4b804ec7986

But the way it was fix is, in my opinion, is incorrect (it was reading stuff when it shouldn't - this kind of thing should be protected with a mutex or we'll end up with a race).

Fixes #3: So we reverted this commit and poof! - the problem disappears. I tested clicking the button to about 16,000 times and no more crash.

This was the last bug we squashed.

So there. One symptom, three underlying problems, that can be triggered at different semi-random times, resulting in a totally different error messages and behaviour, confusing all of us.

We falsely declared victory after the first and the second were squashed - only to be humiliated when the crash happened again, in a slightly different way. By the time we squashed the last bug, we were wary enough __not__ to declare it fixed until a few days later and it was finally confirmed that we've finally made it through.

All in all, we spent more than a month to solve all of them. Now that we've past through them, I hope others can avoid the same mistake.

Meanwhile, enjoy Fatdog64 800 Alpha!

Forum announcement here: http://www.murga-linux.com/puppy/viewtopic.php?t=114719

Release Notes here: http://distro.ibiblio.org/fatdog/web/800a.html