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.
No comments - Edit - Delete
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.
No comments - Edit - Delete
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
No comments - Edit - Delete
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.
No comments - Edit - Delete
Today is Ash Wednesday
Count your blessings!No comments - Edit - Delete
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.
No comments - Edit - Delete
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.
No comments - Edit - Delete
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.
No comments - Edit - Delete
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.
No comments - Edit - Delete
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
No comments - Edit - Delete
