Fatdog64 720 Final is released
Fatdog64 720 Final was released on 20 December 2017, after about three weeks of beta (720 beta was announced here).It was a hectic before Christmas so I didn't get to announce it here in my blog. In fact, Barry Kauler (original author of Puppy Linux) announced it earlier that I do
- which is quite a tribute for us 
There isn't much changes between this and beta, other than a few bug fixes - as I said earlier, 720 beta was actually quite stable.
One new "feature" made it there: 720 now comes with two initrds (dual-initrds) - the first one is the usual huge initrd, and the second one is a very small initrd (around 3.5MB) with ability to "load" the larger initrd. This was a suggestion from forum member LateAdopter, which we "adopted"
Why the need for that? Some people have been complaining about the slow booting speed of Fatdog64 due to its huge initrd. There are many reasons for this slowness but it's mainly because:
a) old BIOS
b) old bootloaders (grub4dos/grub-legacy)
c) boot from modern, large filesystem such as ext4 with size over 16GB.
This particular combination is especially toxic - bootloaders usually use BIOS calls to get data from the disk, and old bootloaders don't understand new filesystem well so while they can load from it, they only do it very very slowly.
Nevertheless, the new "nano-initrd" (as I call it) to the rescue. The small initrd will be loaded fast enough by the bootloader, and then Lnux kernel takes over and load the huge initrd - with the use of modern, optimised code. So booting remain fasts.
However, nothing comes for free. It's basically a stripped down initrd (as explained here so along with the cutdown in size, a lot of other stuff must be sacrificed too. Don't expect the nano-initrd to be able to boot from exotic environments.
Release Notes
Forum announcement
Get it from the usual locations:
Primary site - ibiblio.org (US)
nluug.nl - European mirror
aarnet.edu - Australian mirror
uoc.gr - European mirror
Comments - Edit - Delete
How to create Nvidia driver SFS for Fatdog and Puppy
If you need to use Nvidia driver (instead of the open-source nouveau driver), I've written the steps to prepare the driver SFS yourself.I wrote this article because Nvidia driver is sensitive to kernel changes; each kernel changes requires a rebuild of the driver. And we usually don't provide nvidia driver for beta releases.
Also, there are variations of the nvidia driver (long term, short term, legacy, etc) supporting different cards. Creating a driver for each variation, and re-creating them every time the kernel change, takes a lot of time.
So I've published the way for you to do that yourself. The steps enable you to create the SFS yourself, or, if you can't be bothered about the SFS, it will install the driver directly for you.
As a bonus, it should work on recent Puppy Linux too.
The instruction is here.
Note: this article is an update of the original instructions I wrote here (which is XenialPup64 specific).
Comments - Edit - Delete
I accidentally removed glibc
I accidentally removed glibc.I was running Fatdog build process and I wanted to remove glibc from its chroot.
The correct command to do that was this:
ROOT=chroot removepkg glibc32 glibcbut I typed in the wrong way:
removepkg ROOT=chroot glibc32 glibcThis has the unintended effect of attempting to remove ROOT=chroot package
(which didn't exist), and then glibc32, and glibc. Of course the removal wasn't fully successful, but the dynamic linker /lib64/ld-linux-x64_64.so.2 was deleted and that's enough to stop almost anything.
In a normal distro this would probably require an immediate re-install.
In Puppy-like distro (including Fatdog) all you need to do is to boot pristine, disregarding any savefile/savefolder (pfix=ram for Puppies and savefile=none for Fatdog); and then clean up the mess you've created by the accidental deletion. This is usually done by deleting the whiteouts, so glibc can "show up" again in the layered filesystem.
But I was in the middle of something and I really didn't want to reboot and abandoned what I was doing. What to do? I still had a few terminals open, is there anything I could do to salvage the situation?
Fortunately, Fatdog has a failover mechanism for situation like this.
Fatdog has a static busybox located in /aufs/pup_init/bin/busybox. This busybox is linked with complete set of applets, with its shell (ash) compiled to prefer internal busybox applets instead of external commands.
By running its shell
/aufs/pup_init/bin/busybox ashI am back in a working shell, and I can do "ls" and other things as needed because the busybox is fully static and doesn't need glibc.
Inside there, I then run Fatdog's whiteout clean up script
sh fatdog-clean-whiteout.shwhich run nicely because busybox has enough applets to support it. This removes the whiteout, in effect, undo-ing the deletion.
But trying to do "ls" on another terminal still indicate that glibc isn't installed yet. This is because aufs, the layered filesystem, isn't aware that we have "updated" its layer behind its back. All we need to do is to tell it to re-evaluate its layers.
This can be done by running (from the terminal that runs static busybox shell) this command
mount -i -t aufs -o remount,udba=reval aufs /Once this is done, the system is back to live, and the project is saved.
Comments - Edit - Delete
Fatdog64 720 Beta is Released
The next release of Fatdog64 is finally here!Well, the beta version at least. I actually think this is the next stable release. We have been running this for weeks ourselves, but because we have made so many changes, it's good to treat it as beta and test it on wider audience.
A lot of improvements since the last release; lots of package updates, and lots of fixes too. However this is still based on 710 as the base.
We plan to follow this one up with a Final soon, hopefully before Christmas.
What's next?
Once it goes to final, it would probably be sunset for the 700 series. While 720 is running very well, it is showing its age. Some binary packages refuses to run on it, demanding a newer glibc, for example.
The decision isn't final yet, and the 800 series isn't probably going to be started very soon (we all need to catch our breaths). Meanwhile, enjoy it while you can.
Release Notes
Forum announcement
Get it from the usual locations:
Primary site - ibiblio.org (US)
nluug.nl - European mirror
aarnet.edu - Australian mirror
uoc.gr - European mirror
Comments - Edit - Delete
How to destroy FOSS from within - Part 3
This is the third installment of the article.In case you missed it, these are part one and part two.
In the previous post, I stated that the direction in an FOSS project is set by two groups of people:
a) People who work on the project, and
b) People who are allowed to work on the project.
We have examined (a) in part two, so now let's examine (b).
Who are the people allowed to work on the project? Aren't anyone allowed? The answer is a solid, resounding, "NO".
Most FOSS projects, if they are contributed by more than one person, tend to use some sort of source code management (SCM). In a typical SCM system, there are two classes of users: users with commit rights, who can modify the code in the SCM (committers), and read-only users, who can read and check-out code from the SCM but cannot change anything.
In most FOSS projects, the number of committers are much smaller than the read-only users (potentially anyone in the world with enough skill is a read-only user if the SCM system is opened to the world e.g. if you put the code in a public SCM repository e.g. github and others).
The committers don't necessarily write code themselves. Some of them do; some of them just acts are a "gatekeeper"; they receive contributions from others; vet and review the changes; and "commits" them (=update the code to the SCM) when they think that the contribution has met certain standards.
Why does it matter? Because eventually these committers are the ones that decide the direction of the project by virtue of deciding what kind of changes are accepted.
For example, I may be the smartest person in the world, I may be the most prolific programmer or artists in the world; if the committers of the project I want to contribute don't accept my changes (for whatever reason); then for all practical purposes I may as well don't exist.
Hang on you say, FOSS doesn't work this way. I can always always download the source (or clone the repo) and work it on my own! No approval from anybody is required!
Yes, you can always do that, but that's you doing the work privately. That's not what I mean. As far as the project is concerned, as far as the people who use that project is concerned; if your patches aren't committed back to the project mainline, then you're not making any changes to the project.
But hey hey, wait a minute here you say. That's not the FOSS I know. The FOSS I know works like this: If they don't let me commit this large gobs of code that I've written, what's stopping me to just publish my private work and make it public for all to see and use? In fact, some FOSS licenses even require me to do just that!
Oh, I see. You're just about to cast the most powerful mantra of all: "just.fork.it", is it?
I regret to inform you that you have been misinformed. While the mantra is indeed powerful, it unfortunately does not always work.
Allow me to explain.
Fork usually happens when people disagree with the committers on the direction they take.
Disagreement happens all the time, it's only when they are not reconcilable that fork happens.
But the important question is: what does the forking accomplish in the end?
Personally, I consider a fork to be successful if it meets one of two criteria:
a) the fork flourishes and develops into a separate project, offering alternatives to the original project.
b) the fork flourishes and the original project dies, proving that the people behind the original project has lost their sights and bet in the wrong direction.
In either case, for these to happen, we must have enough skilled people to back the fork. The larger the project, the more complex the project, the more skilled people must revolt and stand behind the fork. It's a game of numbers; if you don't have the numbers you lose. Even if you're super smart, you only have 24 hours a day so chances are you can never single-handedly fork a large-scale project.
In other words, "just.fork.it" mantra does not always work in real world; in fact, it mostly doesn't.
Let's examine a few popular works and let's see how well they do.
1. LibreOffice (fork of OpenOffice). This is a successful fork, because most of the original developers of OpenOffice switch sides to LibreOffice. The original project is dying.
2. eglibc (fork of glibc). Same story as above. Eventually, the original "glibc" folds, and the eglibc fork is officially accepted as the new "glibc" by those who owns "glibc" name.
3. DragonflyBSD (fork of FreeBSD). Both the fork and the original survives; and they grow separately to offer different solutions for the same problem.
4. Devuan (fork of Debian). The fork has existed for about two years now, the judge is still out whether it will be successful.
5. libav (fork of ffmpeg). The fork fails; only Debian supported it and it is now dying.
6. cdrkit (fork of cdrtools). The fork fails; the fork stagnates while the original continues.
7. OEM Linux kernel (fork of Linux kernel). There are a ton of these forks, each ARM CPU maker and ARM boardmaker effectively has one of them. They are mostly failed; the fork didn't advance beyond the original patching to support the OEM. That's why so may Android devices are stuck at 3.x kernels. Only one or two are successful, and those who are, are merging back their changes to the mainline - and eventually will vanish once the integration is done.
8. KDE Trinity (fork of KDE). It's not a real fork per se, but more of a continued maintenance of KDE 3.x. It fails, the project is dying.
9. MATE desktop (fork of GNOME). Same as Trinity, MATE is not a real fork per se, but a continued maintenance of GNOME 2.x. I'm not sure of the future of this fork.
10. Eudev (fork of systemd-udev). The fork survives, but I'd like to note that the fork is mostly about separating "udev" from "systemd" and is not about going to separate direction and implementing new features etc. Its long-term survivability is questionable too because only 2 people maintain it. Plus, it is only used by a few distributions (Gentoo is the primary user, but there are others too - e.g. Fatdog).
11. GraphicsMagick (fork of ImageMagick). The fork survives as an independent project but I would say it fails to achieve its purpose: it doesn't have much impact - most people only knows about ImageMagick and prefers to use it instead.
I think that's enough examples to illustrate that in most cases, your fork will only **probably** survive if you have the numbers. If you don't, then the fork will either die off, or will have no practical impact as people continue to use the original project.
In conclusion: The mantra of "just.fork.it" is not as potent as you thought it would be.
As such, the direction of the a project is mostly set by committers. Different projects have different policies on how committers are chosen; but in many projects the committers are elected based on:
a) request by the project (financial) sponsor, and/or
b) elected based on meritocracy (=read: do-ocracy) - how much contribution he/she has done before.
But remember what I said about do-ocracy?
Comments - Edit - Delete
Fatdog Update
Well, I'm still here. I've been busy with life, moving houses, making arrangements, etc. Too much things to do, too little time. I wouldn't bore you with all that mundane things, since what most probably you're here for Fatdog.Anyway.
Fortunately for all of us Fatdog64 lovers, it has not been so quiet for Fatdog64 under the hood. Our two new members, "SFR" and "step", have been busy at work - bug fixes, package updates, package rollback when the updates don't work :), package replacements, etc. You will find them in the Forum as well, helping other people.
I would say that recruiting them was the best decision we have done - the dynamics works well between us so discussion is always productive.
In fact, we're nearing a release now. To be accurate, however, we have been "near a release" for a few months now - there are so many changes we'd like to share with you; but there is always "one more thing we would to before release to make it better" - and the it's back to the kitchen
. So this release may happen soon or may be a bit later (or a lot later) - cross your fingers!
But seriously, all in all, things are looking good on Fatdog64 side. The team has done lots of exciting improvements. As usual, it may not be perfect, but there is a always the next release
.
It has not been so well on the ARM front. I'm really the only one who works on FatdogArm, and my lack of time to do anything with it means it gets left behind; and it shows. No new platform supported, packages not updated ... although, all in all, it still runs pretty well, for an aged OS.
Well, that's about it for now. On my other FOSS article, I have published two parts. It's actually a four-parter, so there are two more parts to publish ... I'll get that done very soon.
Cheerios everyone.
Comments - Edit - Delete
Fatdog64 build recipes
I've just uploaded the build recipes for all the official packages of Fatdog64. They are available here.They are tarballs, containing the recipe proper, and other supporting files such as patches, desktop files, icons, etc.
They have previously been available in the binary packages (every official Fatdog binary package contains the build recipe tarball inside); but to make it easier for people to search and re-use; we have decided to extract them and upload it in separate place.
The recipe itself is just a shell script, to be used with Fatdog's pkgbuild system. If you want to use it to build it as is, you need that build system which you can get from here. Warning: only tested to work in Fatdog. However, if you just want to examine how the build is done; you can just look at the recipe - it's simple enough to understand.
Note: If you're already on Fatdog64, don't bother getting that. pkgbuild is already included as part of Fatdog's devx.
These build recipes will be updated from time to time; but I can't guarantee any "freshness" of any of these recipes. And oh, they come as totally unsupported - feel free to use them as you see fit, but the risk is all yours. And while I'd be glad to hear suggestion and/or patches for them; please don't come to me for support. My hands are already full of other things.
Comments - Edit - Delete
Real-time Kernel for Fatdog64 710
I built and uploaded real-time kernel for Fatdog64.It's based on Linux 4.4.52 - the latest as of today; and from the same branch as the 710 kernel (4.4.35); and one of the LTS (long-term-support) version; patched with 4.4.50-rt63 patches.
I could manage only the "Basic RT" (PREEMPT_RTB) configuration. This is somewhat between "low-lateny" and "fully preemptible" configurations. I tried the "fully preemptible" (PREEMPT_FULL) configuration but while it gave me a kernel binary; it didn't work satisfactorily --- too many lockups at too unpredictable times.
It has been a very long time since I built an RT kernel (the last one was probably around Linux 3.4 days) which can run in fully preemptible manner. The RT patches aren't always stable either; depending on the kernel version they can be good, okay, or just bad; so I suppose for today, this is the best I can get.
Apart from changing the pre-emption level to PREEMPT_RTB, I made two more (unrelated) changes:
- I increased timer frequency to 1000 Hz.
- I added SDA_HWDEP support.
The first change is done because I plan to use the RT kernel for some audio work that requires lower latency and higher timer resolution.
The second one is done because by tweaking the codec's amplifier I could make my laptop speaker louder by using HDA Analyzer (which requires HDA_HWDEP support); but it turns out to be wishful thinking.
Anyway, enjoy. If you need a guide on how to use the new kernel, look here. There is a new way to test kernels without having to do all above, but it hasn't been written yet. I'll write it when I have time (and motivation) - basically you use "extrasfs" boot parameter to load the kernel-modules.sfs instead of replacing the kernel modules inside your initrd.
Comments - Edit - Delete
Fatdog64 is now listed in Distrowatch
I have been notified of this for a while, but because of my other stuff I forgot to announce it here.Distrowatch is basically a site that monitors various Linux distributions and their updates; as well as news about what's new; what's coming up; and other interesting stuff about Linux distributions. If you haven't been there already, you should check it out.
Fatdog64 has been recommended to Distrowatch for a quite a while, languishing in the "submission queue" for years. Apparently this year is the year - we finally are listed there: http://distrowatch.com/fatdog.
Yay!
Comments - Edit - Delete
How to destroy FOSS from within - Part 2
This is the second installment of the article. In case you missed it, part one is here.In the past, companies try to destroy FOSS by disreputing them. This is usually done by hiring an army of paid shills - people who spread hoaxes, misinformation, and self-promotion where FOSS people usually hang around (in forums, blog comments), etc. This is too obvious after a short while, so the (slightly) newer strategy is to employ "unhelpful users" who hangs around the same forum and blog comments, pretending to help, but all they do is to shoot down every question by embarassing the inquirer (giving "oh noobs questions, RTFM!", or "why would you want to **do that**???" type of responses, all the time).
Needless to say, all these don't always work (usually they don't) as long as the project is still active and its community isn't really filled with assholes.
In order to know how to destroy FOSS, we need to know how FOSS survives in the first place. If we can find lifeline of FOSS; we can choke them and FOSS will inevitably die a horrible death.
The main strength of FOSS is its principle of do-ocracy. Things will get done when somebody's got the itch do to it; and that somebody will, by virtue of do-ocracy, sets the direction of the project.
The main weakness of FOSS is its principle of do-ocracy. Things will get done when somebody's got the itch do to it; and that somebody will, by virtue of do-ocracy, sets the direction of the project.
The repeated sentence above is not a mistake, it's not a typo. Do-ocracy is indeed both the strength and the Achilles' heel of FOSS. Let's see this is the case.
Direction in an FOSS project is set by two groups of people:
a) People who work on the project, and
b) People who are allowed to work on the project.
Lets examine (a).
Who are the people who work on the project? They are:
1) People who are capable of contributing
2) People who are motivated to contribute
Let's examine (1).
Who are the people capable of contributing? Isn't everyone equally capable? The answer is, though may not be obvious due to popular "all people is equal" movement, is a big, unqualified NO. People who are capable of contributing are people who have the skill to do so. Contribution in documentation area requires skilled writers; contribution artworks require skillful artists; contribution in code requires masterful programmers. If you have no skill, you can't contribute - however motivated you are.
The larger a project grows, the more complex it becomes. The more complex it comes, the more experience and skill is needed before somebody can contribute and improve the project. To gain more skill, somebody needs to invest the time and effort; and get themselves familiar with the project and or the relevant technology. Bigger "investment" means less number of people can "afford" it.
And this creates a paradox. The more successful a project becomes, the larger it becomes. The larger it becomes, the more complex it becomes. The more complex it becomes, the smaller the available talent pool.
Let's examine (2).
People contributes to FOSS projects for many reasons, some are less noble than others. Example:
- School projects (including GSoC)
- Some does it out for "paying back" ("I used FOSS software in the past, now I'm paying it back by contributing").
- Some does it for fame and want to show off their skils.
- Some does it just to kill time.
- Some does it for enhancing their resume (oh wow - look at the number of projects in my github account !!! (although most of them are forks from others ...)).
- Some does it because they are the only one who needs the feature they want, so they just get it done.
- Etc, the reasons are too numerous to list. But there is one **BIG** motivation I haven't listed above, and I'm going to write it down in a separate sentence, because it is worthy of your attention.
👉👉👉 Some does it because it is their day job; they are being paid to do so 👈👈👈
What can we conclude from (1) and (2)?
A larger, more complex project requires people with more skills.
More skills requires more investment.
More investment requires more motivation.
Motivation can be bought (=jobs).
Thus it leads to the inevitable that: the more complex a project becomes, the more chance that the people who are working on it are paid employees. And paid employees follows the direction of their employer.
In other words: a larger project has more chance of being co-opted by someone who can throw money to get people to contribute.
We will examine (b) in the next installment.
Comments - Edit - Delete
