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
Time flies
Wow, it is now the third month of 2017. I haven't written anything for 3 months!Well, things do get quiet during the holiday season; and as usual there are real-life issues that I need to take care of.
In between, things have happened. Fatdog64 is now featured on Distrowatch: http://distrowatch.com/table.php?distribution=fatdog, yay!
Also, we recruited new member, "step" from the Puppy Linux forum. Before joining, step is known as maintainers of a few programs used in Puppy Linux, such as gtkmenuplus, findnrun, and others. Welcome step!
Though this blog is quiet, the Fatdog development is not. It continues nicely in the background with comfortable pace: bug fixes, minor feature updates, etc. Bug fixes isn't always possible, but package updates are visible here. Also checks out Fatdog contributed packages thread.
On the other news, LFS 8.0 has been released and while it is tempting to conclude that Fatdog 800 will follow suit soon, it won't happen.
While 710 (which is based on LFS 7.5/CLFS 3.0) is getting older, it has no major problem as its program and libraries continue to be updated. Fatdog 700/710 has acquired a large number of third party contributed software and we plan to keep them usable for a foreseeable time to come, by supporting 700-series until at least the end of the year. There may be one or two more releases (720? 721? or 730?) but they will use the same base.
Comments - Edit - Delete
xscreenshot is updated
xscreenshot, my dead simple screen capture program for X11, gets a facelift. It can now capture screenshot with mouse cursors in it; and it can also capture a single window. Oh, and now the filenames are created based on timestamp, rather than just a running number. You can get the latest version from here.Comments - Edit - Delete
Fatdog64 710 Final is released
The final version of Fatdog64 710 has been released. A lot of improvements since the last Beta release in August 2016; whose details you can see in the Release Notes.You can also leave your feedback in the Puppy Linux forum, where we made our Announcement.
Get it from the usual locations:
Primary site - ibiblio.org (US)
nluug.nl - European mirror
aarnet.edu - Australian mirror
uoc.gr - European mirror
It may take a while for the mirrors to update.
Comments - Edit - Delete
How to destroy FOSS from within - Part I
Although I don't set the scope of this blog, from my previous posts it should be obvious that this is a technical blog. I rarely post anything which is non-technical in nature, here; and I plan to keep it that way.But there have been things moving under the radar which, while in itself is not technical in nature, will affect technical people the most, and hit them the hardest. Especially people working in the FOSS, either professionally, or as hobby.
The blog post is too long to write in one go, so I will split this into a few posts.
For many years, I have been under the silly belief that nothing, nothing, short of global-level calamity (the kind that involves extinction of mankind), can stop the FOSS movement. The horse has left the barn; the critical mass has been reached and the reaction cannot be stopped.
The traditional way companies have fought each other is by throwing money for marketing and fire sale; outspending each other until the other cave in and goes bankrupt. Alternatively, they can swallow each other ("merge and acquire"); and once merged they just kill the "business line" or "the brand".
But they can't fight FOSS like that. Most FOSS companies survive on support. You can acquire them (e.g. MySQL), and then kill them; but one can easily spring up the next day (e.g. MariaDB). You cannot use fire sale on software licensing continuously, because the price of FOSS software licensing is eventually $0, and you can't compete with "free", well, not forever.
I still remember the days that a certain proprietary software company threw their flailing arms up in the air in exasperation, for not being able to compete against FOSS. The only thing they could do was bad-mouth FOSS and keep talking about "quality", and "amateur", and "unprofessional" when it was obvious their own products and conducts was none the better either.
So I was a believer that money cannot stop FOSS.
And how wrong I turned out to be.
Comments - Edit - Delete
Fatdog64 710 Beta Release
In development for over 3 months, this beta release contains many fixes and improvements since the last Alpha release. It is the continuing journey towards Final, which we aim to make it happen soon.During this beta period we are greatly helped by Jake SFR (from Puppy Linux forum) which contributes bug reports, bug fixes, and feature improvement patches; we were also helped by forum member step who, in addition to providing the bug report and patches, also maintains key Fatdog applications such as wallpaper-manager and findnrun, among others. The beta release would not be as good as it is were it not due to the effort of these two gentlemen. So our heartful thanks to them.
Release Notes
Announcement
Get it from the usual locations:
Primary site - ibiblio.org (US)
uoc.gr - European mirror
nluug.nl - European mirror
aarnet.edu - Australian mirror
It may take a while for the mirrors to update because ibiblio has been having problems recently.
Comments - Edit - Delete
Booting your BIOS system via UEFI
In my previous post, I wrote about my exploration on running UEFI on BIOS based systems. The original motivation was to find "cure" to long boot time from USB flash drive, when initrd is large (like the case in Fatdog). I reasoned that since in many BIOS systems USB booting is done via hard-disk emulation (and thus it depends on the quality of the emulation), it would be better to run a firmware that recognises and is capable of booting from USB devices directly, without emulation.I managed to get DUET working on qemu, but it didn't work on some of my target systems. Another alternative that I explored is CloverEFI, which is a fork of DUET. This worked better than DUET and it booted on systems where DUET wouldn't. However, I could not notice improvement on boot times. I haven't looked at DUET disk driver; I was hoping that it would provide a hardware UHCI/EHCI driver but probably doesn't - if it still depends on BIOS to access the USB via hard-disk emulation, then I've gained nothing.
So the initial objective can be considered as a failure.
However, come to think of it, I now have a better reason why you want to run UEFI on your BIOS system. When you run DUET, you are, essentially, "flashing" your BIOS and "upgrading" it with a newer UEFI firmware. While BIOS can do most of what UEFI can, there is one thing that it cannot do: it cannot boot from disk over 2TB in size†. This is not a hardware limitation, it is a consequence of applying a 36-year old design meant for 5 MB harddisk to today's world. With UEFI "update", you can format your disk using GPT and boots successfully from it.
Note†: It is possible to format the disk using GPT and have BIOS boots from it. I even described the process on my own article. That article, however, has a non-obvious limitation: the bootloader you use, must be capable of using the filesystem and booting the OS of your choice. The article was targeted for Linux users, thus syslinux was the chosen example and it would work beautifully. If, however, you want to boot other OS that syslinux doesn't understand, then you have to choose a different boot loader that:
a) can be booted by BIOS
b) understands GPT
c) can boot your OS of choice
In this case, booting GPT disk via DUET doesn't sound very unreasonable, considering that you've got more choice of UEFI bootloaders than non-UEFI ones for some specific OS.
Comments - Edit - Delete
