Get it from the usual mirrors: ibiblio.org, uoc.gr, or nluug.nl.
No comments - Edit - Delete
Who appoints the arbiter of truth?
Or shall we speak in one voice with Pilate, who asked: "What is truth?" (John 18:38).
No comments - Edit - Delete
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.
No comments - Edit - Delete
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
No comments - Edit - Delete
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).
No comments - Edit - Delete
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.
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.
No comments - Edit - Delete
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).
No comments - Edit - Delete
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.)
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.
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 thr