From the desk of James Fatdog64, FatdogArm, Linux, ARM Linux, and others Fatdog64 build recipes Fatdog64'Linux I've just uploaded the build recipes for all the official packages of Fatdog64. They are available <a href= target=_blank>here</a>. <br /> <br />They are tarballs, containing the recipe proper, and other supporting files such as patches, desktop files, icons, etc. <br /> <br />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. <br /> <br />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 <a href= target=_blank>here</a>. 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. <br /> <br />Note: If you're already on Fatdog64, don't bother getting that. pkgbuild is already included as part of Fatdog's devx. <br /> <br />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. Real-time Kernel for Fatdog64 710 Fatdog64'Linux I built and uploaded real-time kernel for Fatdog64. <br /> <br />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. <br /> <br />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. <br /> <br />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. <br /> <br />Apart from changing the pre-emption level to PREEMPT_RTB, I made two more (unrelated) changes: <br />- I increased timer frequency to 1000 Hz. <br />- I added SDA_HWDEP support. <br /> <br />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. <br /> <br />The second one is done because by tweaking the codec's amplifier I could make my laptop speaker louder by using <a href= target=_blank>HDA Analyzer</a> (which requires HDA_HWDEP support); but it turns out to be wishful thinking. <br /> <br />Anyway, enjoy. If you need a guide on how to use the new kernel, look <a href= target=_blank>here</a>. 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. Fatdog64 is now listed in Distrowatch Fatdog64'Linux I have been notified of this for a while, but because of my other stuff I forgot to announce it here. <br /> <br /><a href= target=_blank>Distrowatch</a> 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. <br /> <br />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: <a href= target=_blank></a>. <br /> <br />Yay! <br /> <br /> How to destroy FOSS from within - Part 2 Linux'General This is the second installment of the article. In case you missed it, part one is <a href=/blog/?viewDetailed=00168 target=_blank>here</a>. <br /> <br /><hr> <br /> <br />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 <i>"oh noobs questions, RTFM!"</i>, or <i>"why would you want to **<u>do that</u>**???"</i> type of responses, all the time). <br /> <br />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. <br /> <br />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. <br /> <br />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. <br /> <br />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. <br /> <br />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. <br /> <br />Direction in an FOSS project is set by two groups of people: <br />a) People who work on the project, and <br />b) People who are allowed to work on the project. <br /> <br /><b><u>Lets examine (a).</u></b> <br /> <br />Who are the people who work on the project? They are: <br />1) People who are capable of contributing <br />2) People who are motivated to contribute <br /> <br /><hr> <br /> <br /><u>Let's examine (1).</u> <br />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. <br /> <br />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. <br /> <br />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. <br /> <br /><hr> <br /> <br /><u>Let's examine (2).</u> <br />People contributes to FOSS projects for many reasons, some are less noble than others. Example: <br />- School projects (including GSoC) <br />- Some does it out for "paying back" ("I used FOSS software in the past, now I'm paying it back by contributing"). <br />- Some does it for fame and want to show off their skils. <br />- Some does it just to kill time. <br />- 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 ...)). <br />- Some does it because they are the only one who needs the feature they want, so they just get it done. <br />- 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. <br /> <br />👉👉👉 Some does it because it is <span style=emr>their day job</span>; they are being paid to do so 👈👈👈 <br /> <br /><hr> <br /> <br /><u><b>What can we conclude from (1) and (2)?</b></u> <br />A larger, more complex project requires people with more skills. <br />More skills requires more investment. <br />More investment requires more motivation. <br />Motivation can be bought (=jobs). <br /> <br />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. <br /> <br />In other words: a larger project has more chance of being co-opted by someone who can throw money to get people to contribute. <br /> <br />We will examine (b) in the next installment. Time flies Fatdog64'Linux Wow, it is now the third month of 2017. I haven't written anything for 3 months! <br /> <br />Well, things do get quiet during the holiday season; and as usual there are real-life issues that I need to take care of. <br /> <br />In between, things have happened. Fatdog64 is now featured on Distrowatch: <a href= target=_blank></a>, yay! <br /> <br />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! <br /> <br />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 <a href= target=_blank>here</a>. Also checks out <a href= target=_blank>Fatdog contributed packages thread</a>. <br /> <br />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. <br /> <br />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. <br /> xscreenshot is updated Linux'General <a href=/wiki/wiki.cgi/Xscreenshot target=_blank>xscreenshot</a>, 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 <a href=/wiki/main/files/xannotate-2016-10-21.tar.bz2 target=_blank>here</a>. Fatdog64 710 Final is released Fatdog64'Linux 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 <a href= target=_blank>Release Notes</a>. <br /> <br />You can also leave your feedback in the Puppy Linux forum, where we made our <a href= target=_blank>Announcement</a>. <br /> <br />Get it from the usual locations: <br /><a href= target=_blank>Primary site - (US)</a> <br /><a href= target=_blank> - European mirror</a> <br /><a href= target=_blank> - Australian mirror</a> <br /><a href= target=_blank> - European mirror</a> <br /> <br />It may take a while for the mirrors to update. How to destroy FOSS from within - Part I Linux'General 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. <br /> <br />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. <br /> <br />The blog post is too long to write in one go, so I will split this into a few posts. <br /> <br /><hr> <br /> <br />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. <br /> <br />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". <br /> <br />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. <br /> <br />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. <br /> <br />So I was a believer that money cannot stop FOSS. <br /> <br />And how wrong I turned out to be. <br /> Fatdog64 710 Beta Release Fatdog64'Linux 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. <br /> <br />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. <br /> <br /><a href= target=_blank>Release Notes</a> <br /><a href= target=_blank>Announcement</a> <br /> <br />Get it from the usual locations: <br /><a href= target=_blank>Primary site - (US)</a> <br /><a href= target=_blank> - European mirror</a> <br /><a href= target=_blank> - European mirror</a> <br /><a href= target=_blank> - Australian mirror</a> <br /> <br />It may take a while for the mirrors to update because ibiblio has been having problems recently. Android: detecting outgoing call pickup Android I've been very busy programming an app on Android lately. It's an emergency app - one that enables someone in distress to make an emergency call as well as reporting the situation to a monitoring server, which then notify pre-defined parties so they can take action to help. <br /> <br />It is a very interesting experience, and quite challenging. This is too much to tell in just one blog post, so I'll probably spread it over a few posts as time allows. Or I'll follow up with some articles. <br /> <br />To begin with, please remember two facts: Android, as a platform, is 9 years old as of now. It was also a platform originally designed to serve as base for smartphones. So, I expected that they would have straightened out all the kinks in it; and have good support for telephony functions. <br /> <br />It turns out that it doesn't. <br /> <br />For example - there is no function, or event, whatsoever, to detect that an outgoing call has been picked-up by the remote party. Sure, the Android's own phone application knows this, but this knowledge for some reason is not disseminated to others. In Android 5+ you can get this information, but only if you are a "system" app. Most applications are *NOT* system app, because, well, to be able to install as a system app, you need to root your device first. So this isn't a solution you can apply generally. <a href= target=_blank>Stack Overflow</a> is full of questions about this for many years, with no good answer until today. There isn't any improvement from Google as well to add this feature (I'm quite sure that a few Google engineers are watching Stack Overflow). <br /> <br />But I *need* this ability to detect remote pickup, because, well, in my application, if the outgoing call is not answered in a certain time, I would need to terminate the call and call another number. What to do? <br /> <br />I solved it by detecting the <a href= target=_blank>ring-back tone</a>. As long as the call has not been picked-up, the ring-back tone will be heard. If the ring-back tone is no longer heard after certain time (and call is still on-going), we can assume the call has been picked up. Booting your BIOS system via UEFI Linux'General 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. <br /> <br />I managed to get <a href= target=_blank>DUET</a> working on qemu, but it didn't work on some of my target systems. Another alternative that I explored is <a href= target=_blank>CloverEFI</a>, 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. <br /> <br />So the initial objective can be considered as a failure. <br /> <br />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. <br /> <br /><hr> <br />Note†: It is possible to format the disk using GPT and have BIOS boots from it. I even described the process on <a href=/wiki/wiki.cgi/BIOSBootGPT target=_blank>my own article</a>. 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: <br />a) can be booted by BIOS <br />b) understands GPT <br />c) can boot your OS of choice <br /> <br />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. <br /> UEFI is the new DOS General As I was doing some reading about UEFI emulation on BIOS systems, I came across this interesting link: <a href= target=_blank></a>. In essence, that the linked page says, is that UEFI is essentially a clone of DOS. I'm inclined to agree. <br /> <br />This is why: the page elaborates and compares how (from end-user's perspective) they are essentially the same: there is a kernel (UEFI TSL and UEFI RT [explanation <a href= target=_blank>here</a>]), there is a command line interpreter (shellx64.efi); there is a standard executable binary format (.efi files, which is some sort of flat-mode PE/COFF [details <a href= target=_blank>here</a>]), there is a system library you can link to to build your own binaries (EDK - UEFI Dev Kit c.f. libc); and the fact that an .efi binary can do anything that you want it to do, just like a DOS program can. UEFI provider kernel-like services like handling input devices, manages text and graphical displays, manages filesystem (FAT32 - the successor to DOS' original filesystem of FAT). The shell is single-user just like COMMAND.COM. You can even extend its capability by installing "drivers" - filesystem drivers, network drivers, what what you. A 64-bit DOS with support for all modern hardware, here we come. What's not to like? <img src=images/smilies/happy.gif /> <br /> <br />If your system comes with BIOS, you can run UEFI firmware using DUET (Developers' UEFI Environment). DUET is basically UEFI firmware on a disk (or flash drive, or optical drive) that you can "boot" from your BIOS. Rod Smith (the author of rEFInd, popular UEFI boot manager) wrote about it <a href= target=_blank>here</a>. Once booted, DUET takes over the system and the whole system now acts as if it has an UEFI firmware. You can boot your UEFI-capable OS with it, or you can run shellx64.efi - welcome to UEFI DOS. <br /> <br />If your system already comes with UEFI firmware in ROM - that's the equivalent of having ROM DOS. Rejoice! <img src=images/smilies/happy.gif /> One bootx64.efi to rule them all Linux'General Barry recently blogged about <a href= target=_blank>gummiboot</a>, which contains an interesting link to a feature of gummiboot that I overlooked previously. Barry linked to a phoronix article, which linked to a <a href= target=_blank>blog post</a> from Harald. <br /> <br />TL;DR: gummiboot has a feature to build a single UEFI binary that contains Linux kernel, initrd, and the kernel command line. One UEFI file that contains the entire OS. <br /> <br />Yes, with this, you can have one bootx64.efi (bootloader) that actually contains the entire operating system (kernel, initrd, etc). While the idea is not new - Rob Landley pushed for ability to embed initrd into vmlinuz a long time ago - this is one step even better: embedding into the bootloader! <br /> <br />Why would we even bother? For one thing, it enables you to carry a stick with FAT32 partition in it, and a single file strategically located and named in /EFI/boot/bootx64.efi which contains the entire operating system for recovery and rescue purposes. It also means the return of boot-time virus - this time in the form of boot-loader virus (instead of boot-sector) from the days past if you are not careful. <br /> <br />Another thing is - if you run an embedded system with UEFI bootloader, after your OS are loaded entirely into the RAM, you can happily replace/upgrade your OS ("firmware") in one swop - there are no transactions needed to check if the bootloader update works ok, if the kernel update works okay, if the initrd works okay ... you just replace one file, if that one file update is okay (checkum matches etc) then all is good. <br /> <br />Harald has the code <a href= target=_blank>here</a>, but it's somewhat tied to Fedora and systemd. Here is the extracted code that does the actual magic. <br /><pre class=code><code class=highlight>#!/bin/sh <br />echo your kernel cmdline > cmdline.txt <br />objcopy \ <br /> --add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \ <br /> --add-section .cmdline="cmdline.txt" --change-section-vma .cmdline=0x30000 \ <br /> --add-section .linux="/path/to/your/vmlinuz" --change-section-vma .linux=0x40000 \ <br /> --add-section .initrd="/path/to/your/initrd" --change-section-vma .initrd=0x3000000 \ <br /> linuxx64.efi.stub "$1" <br /></code></pre> <br /> <br />The only catch is this - where does this "linuxx64.efi.stub" come from? <br /> <br />This EFI stub is built as part of the gummiboot bootloader. Gummiboot is "obsoleted" as its content are "absorbed" into systemd (and renamed to systemd-boot or something); but the code still exists and still works nicely here: <a href= target=_blank></a> - you just need to checkout one commit before the final one (the final commit deletes everything to persuade people to move to systemd-boot). <br /> <br />I tested this with Fatdog64's initrd, with and without basesfs in it. Without basesfs - I ended up with 61MB bootx64.efi. With basesfs, I ended up with 366MB bootx64.efi. Both works as expected when launched from qemu as long as I have 2GB of RAM or more. <br /> <br /> Fatdog64 FatdogArm double release Fatdog64'FatdogArm'Linux FatdogArm Beta4 is released. <br /><a href= target=_blank>Release Notes</a> <br /><a href= target=_blank>Downloads</a> <br /> <br />Fatdog64 710 alpha is released. <br /><a href= target=_blank>Release Notes</a> <br /><a href= target=_blank>Forum announcement</a> <br /><a href= target=_blank>Downloads</a>. <br /> <br />As usual you can find them on ibiblio's mirrors too: <br /><a href= target=_blank></a>, <a href= target=_blank></a>, <a target=_blank></a> <br /> <br /> FatdogArm on Odroid-XU4 FatdogArm'Linux'Arm A kind gentleman who goes by the nickname of "pjf" on Puppy Linux forum gave me an Odroid-XU4 to play with. <br /> <br />As a result, FatdogArm now supports Odroid-XU4. The support is pre-eliminary - it's mainly kernel supports; the usual hardware acceleration stuff aren't supported yet. <br /> <br />The kernel package for Odroid-XU4 (and also XU3 - these two are software-compatible with each other) is here: <a href= target=_blank></a>, or on any of ibiblio's mirrors. <br /> <br />This work is still in flux, though, as I'm still tweaking the kernel. It's now my 3rd compile. It may change. And while you can find beta4 SFS there, I haven't really released it and I may still make some changes soon. <br /> <br />Odroid-XU4 is a little machine that could. The SoC is Samsung Exynos 5422. It comes with 8 cores (ARM BIG.little architecture - 4x 2GHz cores, and 4x 1.7GHz cores), <b>*ALL(</b> of which can be run simultaneously under HMP mode. <br /> <br />It is so powerful that: <br />--- <br />a) I can decode h.264 1080p video and render it to 1080p, with AAC audio, using software only (no hardware acceleration). <br />b) I can watch youtube using html5, with audio, without any stutter. <br /> <br />I've never been able to do this in my previous board. It is the fastest little board I've ever used, bar none. <br /> <br />It comes with a cost though. All those speed doesn't come from nothing. It is no longer fanless like Odroid-U2; XU4 comes with a fan. The power supply now can provide juice up to 4A - but this probably to support 2 USB3 ports on its board too. <br /> <br />PS: I used 3.10.y kernel. The 4.2 kernel is marked as EXPERMENTAL by hardkernel and currently lacks many of the fine improvements you can find in 3.10, like sound, and HMP support. It was created to be able to boot Debian server, but I find that even for server work, this is no good because it lacks the ability to schedule the cores properly. And furthermore, it seems to have been abandoned (last update is Aug 2015, while 3.10 is updated just a week ago). <br /> <br />PPS: An oh, on the same URL, you can find official Raspi2 kernel packages too. This is my official kernel packages, which I built from source, and of which I can also supply its kernel source SFS. The berryboot-based kernel are still available in its old link but I'm going to take it down soon. Can a FOSS contributor retracts his/her contributions? General Another aspect of <a href= target=_blank>Rage-quit: Coder unpublished 17 lines of JavaScript and “broke the Internet”</a> is from the comments I've read on-site: is it okay for a FOSS contributor to retract his/her contribution from a public site? Some says yes (contributor has rights) and some says no (once open it is open forever). <br /> <br />I would think the answer is obvious, if we separate the contribution and the publishing. <br /> <br />An author of an FOSS contribution has full rights to his contribution - he can retract, remove, destroy, change, or even change the license of his work. There is no question about it. <br /> <br />But due to the nature of FOSS, once the contribution is published, anyone can take it and re-publish it (with attributions as needed). The original author has no say about it and can't demand that they be taken down; because when he/she published the code he/she gave the world irrevocable right to do just that. <br /> <br />That does not mean the author cannot revoke his/her work, of course they can. It's just that he can't demand that everyone else must also take down the copy of his/her work. <br /> <br />Now, when author publishes his/her work through a 3rd party, however, he/she has to obey the terms of this 3rd party publisher. Some will give the rights to retract and delete, some do not. The point is, the publisher must make the terms and conditions clear. <br /> <br />Github for example allows you to retract and delete anything you publish on it - no trace will be left on its site if you choose to remove your work. Facebook is at the opposite - although at the beginning they didn't make it clear, nowadays it is pretty obvious that while you can delete your account and logins, whatever you submit to Facebook will live forever, and they can even use it long after you've removed your account. You give them that rights when you join Facebook. If you don't agree - well, don't use the Facebook. Simple. <br /> <br />Now back to They should have made it clear that they allow (or disallow) contributors to remove their contributions; and the <b>stand by that</b>. If they allow authors to remove their contributions, people who use the service knows that anything on npmjs should be considered ephemeral and can disappear at anytime - thus they can take mitigative actions (or choose not to use the service at all). If they don't allow removals, authors who contribute to the service knows that anything they choose to publish through is perpetual and can then choose whether or not they want to contribute. But can't have it both ways - because in the end you will irritate both the authors, and the end users. <br /> <br /> Fatdog64 710 builds 32-bit/64-bit wine Fatdog64'Linux Fatdog64 710 passed its ultimate test this weekend: the ability to build <a href= target=_blank>wine</a> that supports running 32-bit and 64-bit Windows applications. <br /> <br />To support 32-bit Windows apps, wine must be built in 32-bit mode. To support 64-bit Windows apps, wine must be built in 64-bit mode. To build wine that can support both, it must be built in both 32-bit and 64-bit mode. That requires multilib support. <br /> <br />And that's the new, major feature of Fatdog64 710: Fatdog64 now supports multilib natively. Building wine in 32-bit and 64-bit mode is the final test that its multilib capability is complete, working, and correct. <br /> <br />Happy Easter everyone. Local copy anyone? General I just read this: <a href= target=_blank> <br />Rage-quit: Coder unpublished 17 lines of JavaScript and “broke the Internet”</a>. <br /> <br />There are too many interesting aspects to consider from the article, but the one that surprised me the most is this: somebody removed their contribution from a public repo, and everything broke? Really? Haven't anyone heard of "local copy"? Fatdog64 710 enters testing stage Fatdog64'Linux Fatdog64 710 is the next generation of Fatdog64. It is still part of 700 series but considered as another branch; because it has a new build system (both for system and user packages) as well has other infrastructure changes which I prefer not to disclose for now. It share the common base as 700 thus many software packages will be largely backward and forward compatible between 700/710 although some may not, due to the usage of many newer libraries in 710. <br /> <br />710 has been in the works for about a year, since the first 700 release went final, but it got stuck there as real-life priorities took over. Most recently, I have 710 ready for testing since early Feb this year but I had to postpone it because I need my laptop to be stable and can't affort running a test OS at that time. <br /> <br />Yesterday, however, I took the plunge and migrated my savedir to 710. The testing process has begun. Fatdog702 ISO re-uploaded Fatdog64'Linux Due to the CVE-2015-7547 scare that hits glibc recently, plus the fact that it is not easy to update glibc, I've decided to re-upload Fatdog64 702 that was uploaded a few days ago with a new set of ISO, devx, and nls SFS that contains a new patched glibc. <br /> <br />The CVE patch itself comes from the Debian team (since the official patch only applies cleanly to latest glibc - not to glibc 2.19 that 702 uses). Thank you Debian. <br /> <br />The new packages md5sums are as follows: <br />--- <br />c7bff729fc3a6100246020466e94e6af Fatdog64-702.iso <br />54cc4ef28741e9e9844ab6f5ca66d41c fd64-devx_702.sfs <br />975d127442a8a336ec14dc743d51ad61 fd64-nls_702.sfs <br /> FatdogArm on Raspiberry Pi 2 FatdogArm'Linux'Arm There were some interest in running FatdogArm on Raspberry Pi 2 (raspi2 for short). While FatdogArm will never run on the original Raspberry Pi for many reasons (the biggest one: unsupported ARMv6 architecture), raspi2 has a modern quad-core Cortex A7 (=ARMv7 architecture) CPU running at 900 MHz, and comes with 1GB RAM standard. Not stellar, but not bad either. <br /> <br />Thanks to the help of forum member "mories" and the berryboot 2.0 kernel/modules, it was possible to get FatdogArm on raspi2: <a href= target=_blank></a>. It's available here: <a href= target=_blank></a>. <br /> <br />But I could not test it myself since I didn't own a raspi2 myself. Now, a kind gentleman who prefers to remain nameless has given me a raspi2 board, together with a very nice cover. <br /> <br />Though I am very busy these days, this inspired me to get the basics going on. I've just built a kernel directly from Raspi's official kernel source distribution (branch 4.1.y). Together with the closed-source bootloader (also from Raspi's official firmware distribution), I've managed to get it to boot to desktop. <br /> <br />This is still a long way to get raspi2 to become a tier-1 supported platform (we need to configure various hardware acceleration modules), but at least it is now running under its own kernel. <br /> <br />When things is a bit more stable I'm going to prepare a proper raspi2 kernel package, replacing the berryboot-based package we have right now. And perhaps publish beta4. Fatdog64 ISO builder is released Fatdog64'Linux Fatdog64 ISO Builder is a tool to make custom Fatdog64 ISO. <br /> <br />It's similar to Puppy Linux "woof", except that this builder specifically builds from Fatdog64 self-built packages only. Since it works with Slackware-style packages (.txz), you may be able to tweak it to work from Slackware packages as well, though that has never been tested. <br /> <br /><a href= target=_blank>Announcement</a> Fatdog64 702 Final is released. Fatdog64'Linux After the planned two weeks of RC stage, 702 is finally released. <br /> <br /><a href= target=_blank>Release notes</a> <br /><a href= target=_blank>Forum announcement</a> <br /> <br />Get it as usual from <a href= target=_blank>ibiblio</a> or one of its mirrors: <a href= target=_blank>aarnet</a>, <a href= target=_blank></a>, and <a href= target=_blank></a>. <br /> Fatdog64 702rc is released Fatdog64'Linux Maintenance update, mainly fixes and a few updated packages. <br /> <br /><a href= target=_blank>Release notes</a> <br /><a href= target=_blank>Forum announcement</a> <br /> <br />Get it as usual from <a href= target=_blank>ibiblio</a> or one of its mirrors: <a href= target=_blank>aarnet</a>, <a href= target=_blank></a>, and <a href= target=_blank></a>. <br /> Updated kbstate and a2dp-alsa Linux'General I've updated <a href=/wiki/wiki.cgi/KbState target=_blank>kbstate</a> to detect multiple keys from multiple event devices at once, making usage a lot simpler. <br /> <br />I've also updated <a href=/wiki/wiki.cgi/BluezA2DP target=_blank>a2dp-alsa</a> to work correctly with Android devices; and improve it so that a2dp-buffer is no longer necessary; and fix the Makefile for newer gcc. It can now be used as "pass-through router" reliably. Updated savedir support on FAT Fatdog64'Linux "Save directory" (savedir for short) is way of persistence whereby the user-modified files are stored in a directory somewhere, as opposed to "savefile", in which they are stored to a big loopback-mounted file. <br /> <br />Savefile is very convenient and reliable method of persistence and it works across many different filesystems including networked, non-POSIX ones, because we can always choose the filesystem inside the savefile - usually one that is POSIX compatible. <br /> <br />However savefile has a minor irritation - you are limited by its size. Sure you can always resize it if it gets full, but it's a hassle. Savedir on the other hand doesn't have this limitation, but it must be located on a POSIX filesystem. Well not really, but if not, then you'll get a lot of odd behaviours. <br /> <br />Fatdog64 has supported savedir since version 620 (April 2013), this includes support for non-POSIX filesystems too such as NTFS and FAT. <br /> <br />The support for NTFS was upgraded in October 2015 to support true POSIX permissions made available from recent versions of ntfs-3g. NTFS is pervasive and is good compatibility filesystem for Windows OS, so this is an overdue update (although I personally still recommend that you use savefile on NTFS). <br /> <br />I've now upgraded the support for savedir on FAT as well, using <a href= target=_blank>posixovl</a>; this gives savedir on FAT some support for rudimentary POSIX features, such as permissions, device nodes, and fifos. <br /> <br />However using posixovl as the base on savedir isn't without problem. For one thing, it cannot be unmounted cleanly - so you must always run fsck at boot ("dofsck" will do this for you). On another front, posixovl emulation of POSIX on FAT isn't perfect, and you will sure notice some oddities. And the last point is - FAT is much more corruption-prone as compared to modern filesystems (including NTFS). But if you're happy to play with fire, then - yeah, why not? <img src=images/smilies/teeth.gif /> <br /> <br />As a bonus, I also make posixovl to work with CIFS too - so now you can enjoy network-based savedir with full POSIX features (plus some unwanted oddities, as I said above). <br /> <br />I've made the usage of posixovl for FAT and CIFS not obligatory. You can always fallback to old method of using FAT and CIFS directly - which will unmount cleanly, but you will have to live with the limitations of non-POSIX filesystems (e.g. all files turned into executables; permissions are lost, etc). Or of course, just use savefile <img src=images/smilies/happy.gif /> <br /> <br />This will be in the next release of Fatdog, whenever that will be. <br /> Updated article: New Apps on Old Glibc Linux'General Somebody asked me recently about my article, <a href=/wiki/wiki.cgi/NewAppsOnOldGlibc target=_blank>How to run new apps on older glibc</a>. He tried to follow the instructions in the article but encountered an error. <br /> <br />As it turns out, when I wrote that article I only wrote half of it. I planned to write the other half but other things took my attention and I forgot about it. <br /> <br />I have now updated it and written the complete steps as well as re-testing the steps again to make sure that it works. <br /> <br />So if you're running a new application that depends on newer glibc but you can't re-compile or upgrade your OS for whatever reason, you may want to look at that article again. Review of meteor General Not too long ago I was looking at alternative development tools for Android other than what Googld provides. I got quite interested in <a href= target=_blank>meteor</a>, which claimed itself as a "Javascript App Platform". I have written javascript since 1997 (since before it was called EcmaScript, since before DOM Level 1 was standardised); while not exactly a fan of the language, I can do things with it so it intrigued me. In the past I have also had fun with Aptana Jaxer (now defunct) which more or less did the same thing - without the Android part. <br /> <br />Most of it is what it says it is. Documentation works, tutorial works (which is more than what many products from large companies can offer!). The javascript works too, of course. <br /> <br />But I noticed something that I really don't like - it's blurring the line between server-side activities and client-side activities. Let me explain. <br /> <br />In meteor, scripts can be tagged to run in client (=browsers), server, or both. Round-trip latency is reduced or eliminated using transparent client-side caching (ie, your code doesn't need to know about it - generated plumbing code + embedded libs takes care of that). You're supposed to write stuff as if they run on clients; and only code server-side stuff when necessary (at least that's the impression I've got). <br /> <br />This is supposedly a very good thing - focus your development work on your requirements rather than the plumbing of the platform; and get stuff done quickly. <br /> <br />But it feels wrong to me. I would rather prefer an environment where I know (and can separate) what runs on the server, and what runs on the client. <br /> <br />For one, with this much close-coupling, when the plumbing stops working or starts leaking, I can imagine that debugging will extremely fun. <br /> <br />Another downer for me is the realisation that the app I make will be fully tied to this platform. The frontend (client-side) can only work with the backend (server-side) it is written with; there is no easy way to make a single server that services heterogeneous, multi-platform clients. <br /> <br />All these may still be acceptable if the end result of the (android) app is a single bundle that I can deploy as a standalone - but no, meteor doesn't work that way. The android app it created is basically just a webapp facade (bunch of html and js), and needs to connect to a remote server for it to *work*. The server-side stuff are not included in the APK. That means, if the (remote) server dies, the app is useless. <br /> <br />There are other concerns but they are relatively minor compared to the above, so with great disappointment I have to put it aside. It had so much potential in it. Fatdog64 lives on Fatdog64'Linux There has been no posts about Fatdog64 lately. But it does not mean that its development has stopped. On the contrary, it is still actively maintained. I've received a lot of help from Puppy Linux forum members such as SFR, step, and L18L, to mention a prolific few. <br /> <br />If you want to follow what has been updated recently, you can look at an overview of the changes since 701 release <a href= target=_blank>here</a>. <br /> <br />Also, recently somebody asked me what Fatdog could do, so I decided to write an article about it <a href=/wiki/wiki.cgi/FatdogIsVersatile target=_blank>here</a>. <br /> Puppy Linux Slacko 6.3.0 is released Linux'General Puppy Linux "Slacko" is the flagship Puppy Linux based on Slackware. <br /> <br />Mick has just released the latest and greatest version 6.3.0 of Puppy Linux Slacko, both 32-bit and 64-bit flavours (Slacko and Slacko64). <br /> <br />The Slacko64 is the first ever official (non-beta) release of 64-bit Puppy Linux, so it is exciting times! <br /> <br />Go grab and give them a test drive yourself, from <a href= target=_blank>Puppy Linux Slacko official homepage</a>. <br /> <br />Note: Fatdog64's 32-bit compatibility SFS is based on 32-bit Slacko 5.96 (beta version of Slacko 6.x). <br /> <br /> Bluetooth support for Cubox-i FatdogArm'Linux'Arm'Fatdog64 Bluetooth was the last feature of FatdogArm that wasn't working on Cubox-i (it works on the Nexus 7). The last time I looked on it was on April this year. My main problem was I always get the message "can't set hci protocol" near the end of firmware upload, when using the built-in hci driver with brcm_patchram_plus (similar message when using the external hciattach). <br /> <br />There were a lot of people who reported these, and only got the shrugs ... "works for me" type of replies. Most of the "solutions" to this problem concerns about variation of parameters to use on brcm_patchram_plus, as well various links to different versions of .hcd file dumps. However, most of the messages ended there. There were no confirmation whether or not the fix works, and whether there are possibly other causes. And no-one said anything about the kernel. <br /> <br />As it turns out, the kernel *was* the problem. The bluetooth host hardware in cubox-i is connected via MMC SDIO, using the serial interface. To support serial bluetooth devices correctly, the kernel needs BT_HCIUART_* to be enabled. The default defconfig from SolidRun 3.10 kernel did't enable these <img src=images/smilies/doh.gif />, and there were no notes whatsoever saying these configs are needed at all <img src=images/smilies/thumbdown.gif />. I have been using Solidrun's defconfigs (= manufacturer knows best, etc) - and badly beaten by it, wasting hours on unnecessary debugging <img src=images/smilies/cry.png /> <br /> <br />Curiously, SolidRun 3.14 kernel defconfig *does* have these enabled - so they *do* know. Why this isn't documented elsewhere - I have no idea. Go and ask them. <br /> <br />Anyway, as soon as the kernel is rebuilt, bluetooth works. I tested it by getting it paired and connected with a bluetooth speaker and bluetooth keyboard. Both works nicely. <br /> <br />I have integrated these findings into a package called imx6-bluetooth, and have uploaded it to the repo. However, it won't work unless you use a kernel with those configs enabled. <br /> <br />I'm going to upload a new kernel for cubox-i later. If you're interested to use it *now*, then leave me a message. <br /> <br />With this, the FatdogArm platform support for cubox-i is considered complete. MariaDB: Eat your cake and still have it General Some people say you can't make money with open source or Free software. But there are many exceptions to that. Red Hat is one of the most prominent exceptions. Well, MariaDB is apparently another one, and a special one at that. <br /> <br />You see, MariaDB is a fork of a software called MySQL. MySQL is a Free software (GPL licensed) that was developed by MySQL AB. In 2008, MySQL AB was sold to Sun Microsystems for US$1 billion (Sun was later bought by Oracle). MySQL AB held the original copyright of MySQL source code and that right was sold to Sun (along with other things like the name, trademarks, etc). <br /> <br />But being Free software, one can take MySQL source code, and "fork" it, i.e. make modifications to the source code and re-distribute both the modified code and binary programs for others to use - without any (financial) obligations to MySQL AB (or Sun or Oracle) as long as the original (GPL) license requirement is met. <br /> <br />"MariaDB" is one of such fork. To "support" and "maintain" (and also "promote") MariaDB, there is an organisation called MariaDB Corporation AB. This organisation has received many funding rounds from venture capital (VC) companies. We are not talking about $10,000 individual donation, or $500,000 kickstarter campaign; we're talking about US$20 million direct VC funding: the last round being in Feb 2015. <br /> <br />We all know that VC companies are not charities. They expect returns on the money they invested. In other words, they expect returns from the money they gave to MariaDB AB. The usual way to get this returns back is to wait for MariaDB AB to get sold to someone else (to the public by IPO, or to other larger companies through private deals). Depending on your VC math, that $20million funding translates to a company valuation between $200m to $2 billion - not too shabby at all. <br /> <br />With me so far? OK. The punchline: the person who created MySQL, MySQL AB, MariaDB fork, and MariaDB AB is the one and same person. He created MySQL and MySQL AB and sold it (in 2008). Not long after that (in 2009) he created MariaDB fork, and later on he also started MariaDB AB; and by the looking of it, MariaDB AB will probably get sold too sooner or later. <br /> <br />I don't know about you, but I feel this is a proof that you can indeed eat your cake for breakfast *AND* still have it (so you can eat it again for lunch - and perhaps still have it even after that, for dinner? <img src=images/smilies/happy.gif /> ). And this is only possible if you're doing Free software. <br /> Javascript "Promise" General No, Javascript isn't promising you anything. It's just an oddly named object in Javascript, which, despite its queer naming, is worth considering, especially if you are losing too much hair from doing a lot of async callbacks. <br /> <br />Explanation of what it is, why it is useful, how it works, and how to write your own implementation in 90-lines - all <a href=/wiki/wiki.cgi/JavascriptPromise target=_blank>here</a>. Small web browser Linux'General Since we are in the subject of small programs, is there are any small GUI web browser? Less than 50K, perhaps? I must be joking, right? <img src=images/smilies/teeth.gif /> <br /> <br />Well, you _<i>could</i>_ make a small web browser like that. Just make GUI shell that links in Yeah. That would work. May as well create a shell script that launches firefox. Hey, small browser in 512 bytes! <br /> <br />Seriously, can we have a small browser, without external dependency, that weight less than 500K (excluding the weight of the GUI toolkits)? <br /> <br />The answer is you can; and the key to that is <a href= target=_blank>libgtkhtml2</a>. This is a HTML 4.0, CSS2 compatible rendering engine that weighs less than 500K. Since it is small it makes sense to have this as part of the system library (it is used by the likes of Osmo, Claws mail, etc for example); and if you already have it as a system library then you can truly makes a browser with the size of less than 50K, linking in this library. <br /> <br />If you don't have it as system library, you can still link it statically and have final stripped executable that is less than 500K (the exact size depends on your compiler optimisation settings, etc). <br /> <br />I have made such a browser, and you can download the source <a href= target=_blank>here</a>. In Fatdog64, that has libgtkhtml2 by default, the binary size is really 38K. Linked in statically, with -Os, the binary size is about 350K (on x86_64 build). <br /> <br /><b>Note about libgtkhtml2 source</b>: as you can probably see from the link given, libgtkhtml2 is a dead project. That gnome site listed version 2.11.1 as its final version, but there is (or was) a newer version from gnome-svn (which had also long been defunct) - which, fortunately, has been preserved by the Yocto project <a href= target=_blank>here</a>. I took this version, applied as many forward patches I could find (mainly from the also defunct - and also preserved by Yocto), and added my own stability patches. This final copy of libgtkhtml2 of mine is located <a href= target=_blank>here</a>. <br /> <br /><b>Final note:</b> libgtkhtml2 is old. It <b>*will*</b> choke, hang or crash on newer CSS3 (and some CSS2.1) or HTML5 stuffs. It does not have Javascript. While its HTML parsing is not too bad (it uses libxml2's html parser - which *is* maintained), its CSS parsing is horrible - instead of a grammar-derived parsing, it uses ad-hoc string searches. I have fixed some of the low-hanging bugs but a lot more still lurks in it. So I strongly advise you against using it for general purpose web browsing - for that you can have <a href= target=_blank>netsurf</a>, <a href= target=_blank>links2</a>, or other excellent projects - and while they aren't as small as libgtkhtml2, they do work for modern Internet. <br /> <br />The only reason why I tried to resurrect this, is to use it as a small (local) help viewer for HTML contents - just like mdview, in my previous post. After all, you don't want a <a href= target=_blank>help viewer that links to multi-megabytes webkit libraries</a>, do you? <img src=images/smilies/teeth.gif /> <br /> <br /> mdview: a small, GTK-based markdown viewer Linux'General I am quite annoyed by help-viewer programs that are huge and pull out a lot of dependencies, sometimes a lot more than the main programs themselves. After all, their purpose in life is just to support the main program and to provide a convenient UI to view some pre-formatted text files. <br /> <br />Then I found that hardinfo has a very nice help viewer which is very under-utilised (because there is hardly any help documents in it). It supports direct viewing of markdown-formatted files (well, a subset of markdown), and it has *no* dependencies other than GTK. <br /> <br />After playing with it for a while I decided to detach it out from hardinfo, polish it a little bit, fixed a few bugs and added some more features, and now I have mdview, a 60K-sized help/markdown viewer. <br /> <br /><hr> <br /> <br />From the homepage: <br /> <br />mdview is a super light-weight, GTK-based markdown files viewer. It has no other dependencies other than GTK itself. It reads and displays text files in (a subset of) markdown format, and provide live links to other files as well as to the Internet. It is ideal for showing help files (its original purpose), user manuals, and other small set of hyperlinked markdown files. <br /> <br />Get it from here: <a href= target=_blank></a> Fatdog64 701 is released Fatdog64'Linux Maintenance update, mainly fixes and a few updated packages. New features including USB/bluetooth tethering, working bluetooth send/receive files, MTP browser, and Find'N'Run, and a few others. <br /> <br /><a href= target=_blank>Release notes</a> <br /><a href= target=_blank>Forum announcement</a> <br /> <br />Get it as usual from <a href= target=_blank>ibiblio</a> or one of its mirrors: <a href= target=_blank>aarnet</a>, <a href= target=_blank></a>, and <a href= target=_blank></a>. <br /> Misc updates - PSIP, FatdogArm, xlogin FatdogArm'Linux'Arm'Fatdog64 I have implemented multi-account support in <a href= target=_blank>psip</a>, a long-time asked feature. You can keep multiple accounts but only one can be active at a time. PSIP will be included in the upcoming Fatdog64 701 release. <br /> <br /><hr> <br /> <br />FatdogArm Beta3 has been released - with new Nexus7 2012 support, dual-core support fror OLPC XO-4, and improved touch support overall. Thanks to 01micko and mavrothal for their tests, feedback and suggestions. Check out the <a href= target=_blank>release notes</a>. <br /> <br /><hr> <br /> <br /><a href= target=_blank>xlogin</a> is a very small Xorg login manager, more basic that <a href= target=_blank>slim</a> which is included in Fatdog, but it has one thing that slim does not - it supports network operation and XDMCP. Jon (the original author) stopped development long time ago (about 2008 looking at the file dates), but I found this useful, so I picked up the code, cleaned it, fixed it where it didn't work - and I have my fork <a href= target=_blank>here</a>. <br /> <br />Among other changes, it now works with authorisation (MIT-MAGIC-COOKIE stuff), and I have re-coded xlogin-rootjpeg to use <a href= target=_blank>stb_image</a> so it no longer depends on libjpeg - plus ability to resize the image on the fly. <br /> Making VirtualBox Guest Addition for Fatdog64, the easy way Fatdog64'Linux The articles I have written in in my archives usually are generic ones. But today I am inspired to write one specifically for Fatdog64, so <a href=/wiki/wiki.cgi/MakingVBoxGuestAdditionForFatdog target=_blank>here it is</a>. Enjoy. <br /> <br /> Fatdog64 700 on Acer Iconia W500 Fatdog64'Linux Micko, also known by his nickname 01micko in the <a href= target=_blank>Puppy Linux Forum</a>), managed to install Fatdog64 700 on Acer Iconia tablet W500 and got it to run quite smoothly. Here is <a href= target=_blank>his original announcement with pictures</a>, and here is <a href= target=_blank>his step-by-step instructions</a> to do. <br /> <br />Thanks Mick! <img src=images/smilies/thumbup.gif /> <br /> <br />In case you wonder who Micko is: he is the prolific developer of Puppy Linux Slacko (the official Puppy Linux releases based on Slackware) - and has been holding the the torch for a couple of years now. He is also the co-maintainer of Woof-CE, the build system for Puppy Linux; as well <a href= target=_blank>several small desktop utilities</a>. His latest work, Puppy Slacko6 beta is what gets re-packaged as 32-bit compatibility library package for Fatdog64. <br /> <br />He took a break for a few months but has just recently come back and we hope he will stay for a while <img src=images/smilies/happy.gif /> <br /> <br />Mick has a blog <a href= target=_blank>here</a>. FatdogArm on Nexus 7 FatdogArm'Linux'Arm A kind gentleman who prefers to remain anonymous gave me an Asus Nexus 7 2012 ("grouper") last year so that I could put FatdogArm on it. Due to various circumstances, I was not able to look into it until very recently. <br /> <br />The same gentleman informed me that most of the works should have been done since Ubuntu team has managed to boot Ubuntu on it as early as 2013, and there was a development called <a href= target=_blank>Multirom</a> that enables dual/multi-booting of various OS on Nexus 7, making it even more convenient. <br /> <br />Well, I was late to the game, but late is better than never. I finally had the chance to try to get it going. The Nexus 7 given to me was in a pristine condition, stock firmware, not rooted. So I upgraded it to Android Lollipop 5.1, rooted it, installed Multirom on it (manually). Perhaps I will write the steps a little later. <br />Then I grabbed Ubuntu Nexus 7 kernel and modified it for FatdogArm, and after some little tinkering, here is an image. <br /> <br /><a href=images/nexus7.jpg rel=prettyPhoto><img rel=prettyPhoto src=thumbs/nexus7.jpg /></a> <br /> <br />Framebuffer, framebuffer console, wifi, sound, touchscreen, USB-OTG all works thanks to Ubuntu hardwork of porting mainline kernel to support Nexus 7. I have not tested other devices (accelerometer, camera, compass, etc). <br /> <br />It is still early days but I hope I can upload a beta3 version of FatdogArm with basic support for the Nexus 7 (and the recently rebuild SMP kernel for XO-4) soon. <br /> <br /> Updated 32-bit compatibility SFS Fatdog64'Linux Fatdog64 is a 64-bit operating system so it cannot run 32-bit programs by default. To run 32-bit programs, the kernel must be compiled to support such and 32-bit version of the libraries are needed. <br /> <br />Both have always been provided since Fatdog64 launches back in the day. The 32-bit libraries are compiled together in an <a href= target=_blank>SFS</a> called <i>32bit compatibility library</i>. <br /> <br />Compiling libraries are time consuming (not to mention the testing) and we have our hands full taking care of 64-bit libraries (and ARM for me). So we have always out-sourced the job of making 32-bit libraries to someone else: instead, we usually take an existing, known good, and widely used version of Puppy Linux and re-package it. <br /> <br />The very first version of 32bit compatibility (for Fatdog64 500 series) was based on Puppy Linux Wary 5.0. The second version of 32bit libraries (for Fatdog64 600 series) was based on Puppy Linux Slacko 5.3.1, and for a while this was the only available 32-bit libraries for Fatdog64 700 too. <br /> <br />I have just compiled a new 32bit compatibility library based on Puppy Linux Slacko 6 beta (5.9.3), accounting for a new directory layout in Fatdog64 700 which has a clean separation between 64-bit and 32-bit libraries. All 32-bit libraries now lives in /lib and /usr/lib, as it shoud be (in 600 series this was still a bit mixed, forcing us to use /lib32 and /usr/lib32 instead). The non-shared configuration still lives in /etc32, and a "start32" is still provided for compatibility purposes. <br /> <br />The name of the new 32bit library is <b>32bit-slacko6.sfs</b> and it is available from ibiblio and its mirrors with immediate effect. <br /> SMP-enabled kernel for OLPC XO-4 FatdogArm'Linux'Arm I had known even before I received the laptop over a year ago that the <a href= target=_blank>Marvell Armada PXA2128</a> Soc used in XO-4 featured a dual-core CPU, but for some reason the kernel didn't support that. <br /> <br />I recently got tipped by forum member mavrothal, my partner in development of FatdogArm for the OLPC, that the OLPC kernel for XO-4 finally got dual-core capability, who had built the latest git master from the kernel and <a href= target=_blank>got SMP kernel working</a>. <br /> <br />I didn't have the time back then, but yesterday I finally got the chance to play with it. I built the kernel myself too, and I needed to update the OFW firmware to at least q7c04 for the dual-core kernel to run, but everything is smooth - new kernel booted and worked flawlessly with both cores enabled. All the existing functionalities continue to work, but the rc.platform will require a little patch because the ID code that I used to identify XO-4 has changed. <br /> <br />I will upload the new kernel, with update instructions (mainly pointing back to OLPC on how to update the firmware etc), and a new FatdogArm sfs with the required rc.platform change. <br /> <br />It has been a long time since the last FatdogArm beta2 release, so I may as well update some of the other packages too and call it beta3. Watch this space for further announcement. <br /> <br /> <br /><hr> <br /> <br />After updating the OLPC firmware, the old original Fedora/Sugar in XO-4 will stop running. The fix is to download a newer build of the OS and install it to the laptop. <br /> <br />I need to say that I continue to be impressed and amazed of how OLPC implements these processes (both updating firmware and updating the internal OS). They are simple, easy, foolproof and very informative. <br /> <br />This is a far cry from similar processes of other commercial offerings. Especially since I had to deal with UEFI recently - if only UEFI implements half of what OLPC does with its Open Firmware, it would have been immensely more useful. Something's got to be better than BIOS, but UEFI isn't the one - OpenFirmware certainly is. <br /> <br />I applaud the engineering that went into the design and implementation of these features. There must have been a lot of thinking, and a lot of effort to examine of how the processes on standard PC broke down or failed in one way or another - and they made it really better. <br /> <br />This is of course on top of other excellent features of OLPC laptop - and I don't even mean the advertised educational benefits - but things like physical robustness, ease of maintenance, quality selection and durability of its components. Sure, this does not make it the lowest cost laptop (or even a lower cost tablet), but quality has its price and an investment of an OLPC laptop will far out-weight its cost and last far longer than any other laptops (or tablets) designed for similar purposes. <br /> <br />Personal note - I still think that a laptop is a far more useful for education than a tablet, regardless of the recent fad. If you are a decision maker and considering to get some sort of tablets or OLPC laptops, I'd highly recommend you go with OLPC XO-4. As a bonus, an XO-4 with touch screen (XO-4 touch) can function as a tablet too - just flip its screen. That is how versatile it is. <br /> <br />Disclaimer: I am saying all the above not because I am affiliated with OLPC (the only indirect relationship I have with OLPC is that I am doing a non-commercial community project for the OLPC XOs - that is, FatdogArm). I really like the OLPC laptop, I really like OLPC mission, and I really wish and hopeful that OLPC as an organisation will succeed and continue to focus on these quality offerings. <br /> Dual-boot Windows/Linux on Sony laptop with UEFI and Secure Boot Fatdog64'Linux I haven't written an article for a very long time, so here is one: <a href=/wiki/wiki.cgi/SonyLinuxUefiBoot target=_blank>Dual-boot Windows/Linux on Sony laptop with UEFI and Secure Boot</a> Never mind. I found one. General I am a subscriber of <a target=_blank>Mikey's Funnies</a>, and has been for a very long time. <br /> <br />Today this came into my mailbox, and since Easter is coming in two week's time, I find that this is especially appropriate and I couldn't resist to re-post it here. <br /> <br /><span style="border: 1px solid black; display: inline-block; padding: 1em;">Paddy was driving down the street in a sweat because he had an important meeting and couldn't find a parking space. Looking up to heaven, he said, "Lord, take pity on me. If you find me a parking space, I will go to Mass every Sunday for the rest of me life and give up me Irish whiskey!" <br /> <br />Miraculously, a parking space suddenly appeared. <br /> <br />Paddy looked up again and said, "Never mind. I found one." <br /> <br />[forwarded by Adon Brownell]</span> <br /> <br />How many times do we act like that ourselves? <br /> xannonate/xscreenshot updated Linux'General Minor update to <a href=/wiki/wiki.cgi/Xannotate target=_blank>xannotate</a>/<a href=/wiki/wiki.cgi/Xscreenshot target=_blank>xscreenshot</a>: the hotkey can now be given in either symbolic form (e.g. "Print") or in numeric form (107). This is necessary because sometimes the same key name (e.g. Print) can have multiple key codes (e.g. 107, 218); and hotkey selection inside X works based on keycodes. I found this out because the "Print" button on my (newish) laptop doesn't work; it turns out that this particular laptop dish out 218 for the Print button; while the standard mapping is 107 (which gets used), so as far as the program is concerned it never gets triggered. <br /> <br />As a convenience, if you give it a numeric keycode, it will try to find the other standard keycode that represents the same key, and grab it too. <br /> Fatdog64 700 is released Fatdog64'Linux Linux 3.18.7 and many enhancements and bug fixes over the 700rc release. <br /> <br /><a href= target=_blank>Release notes</a> <br /><a href= target=_blank>Forum announcement</a> <br /> <br />Get it as usual from <a href= target=_blank>ibiblio</a> or one of its mirrors: <a href= target=_blank>aarnet</a>, <a href= target=_blank></a>, and <a href= target=_blank></a>. <br /> Fatdog64 700rc Release Fatdog64'Linux Linux 3.18.6, Seamonkey 2.32, flash player and other bug fixes. <br /> <br /><a href= target=_blank>Release notes</a> <br /><a href= target=_blank>Forum announcement</a> <br /> <br />Get it as usual from <a href= target=_blank>ibiblio</a> or one of its mirrors: <a href= target=_blank>aarnet</a>, <a href= target=_blank></a>, and <a href= target=_blank></a>. <br /> Maximum size of initramfs Linux'General Well, I'm still around <img src=images/smilies/teeth.gif />. <br /> <br />Just want to document this often asked problem: what is the maximum size allowed, for an initramfs? Obviously this will be related to how much RAM you have, but what is exactly the relationship? <br /> <br />I have answered the question <a href= target=_blank>here</a>, but I didn't explain why the numbers are what they are. This post attempts to correct that, if you're interested. <br /> <br />When considering this question, there are two things to remember: <br />a) initramfs will be uncompressed to memory during boot-up, so the amount of RAM needed would be the size of the initial initramfs + size of uncompressed initramfs <br />b) how much RAM the kernel will want to allocate for holding initramfs. <br />For the system to successfully boot, (a) must be the same or less than (b). <br /> <br />(a) is easy - by rule of thumb, it is twice the uncompressed size of initramfs. It is exact for uncompressed initramfs, and approximate for compressed initramfs; in either way it will give you the upper bound. <br /> <br />(b) is a bit more complicated. Traditionally the kernel will use "ramfs" for initramfs (that's why it is called init-ramfs ... <img src=images/smilies/teeth.gif />), and it will happily allocate all of your RAM for it, which is unwise, so you should at least subtract about 0.5GB from your RAM size if you want a usable system (unless your idea of fun is dealing with kernel OOM-killer that kills your important system services right after boot - not me). <br /> <br />But somewhere around kernel 3.x (circa 2012), the kernel merged "inittmpfs" patch from Rob Landley (of busybox and toybox and aboriginal Linux fame). It means that from that day onwards, initramfs will use "tmpfs" as opposed to "ramfs" by default (you can still switch back to using ramfs by specifying "rootfstype=ramfs" on your kernel command line). In case you're not familiar with the difference, "tmpfs" is "ramfs" with a size-limit (among others); and by default the limit is 50% of your RAM. <br /> <br />But wait, you say, doesn't "tmpfs" come with knobs to specify the maximum size? Yes, it does, but not at boot-time, no. Sure, you can re-mount it and changes it size, but we're talking here the situation during initramfs loading, *before* any code in initramfs itself is started ... <br /> <br />Rob actually has a patch to do exactly this, using "rootfsflags", but <a href= target=_blank>don't count on it going to mainline kernel soon</a>. <br /> <br />But I digress. So, to come back to the subject, with "ramfs" you get all of your RAM (minus your 0.5GB), and with "inittmpfs" you get 50% of your RAM. This is (b). And since (a) is twice the size of your initramfs, it means that the maximum allowable size of your initramfs is 1/2 of (b). <br /> <br />Which means, if you use "inittmpfs" (which is the default in modern kernels), your initramfs size is limited to 1/2 of 50% of your RAM, or 25% of your RAM. If you use "ramfs" by specifying "rootfstype=ramfs" in your kernel boot command line, when this limit can increase to 1/2 of your RAM (minus 0.5GB), or, about 40%-45% of your RAM (depending on how big it is). <i>Q.E.D</i>. <br /> <br /> no longer used. General I have relinquished control over the old domain of this blog and wiki, which was "". I have put a notification <a href=?viewDetailed=00116 target=_blank>here</a> but apparently I still have a few links pointing to the old domains. <br /> <br />I am informed today that the old domain has been taken over and is being used to distribute malware. Please avoid that domain from now on. <br /> <br />Because of that, I have urgently changed all links that I know to point to the new domains. If you still know some old links to the no-longer used domain, please let me know and I will update them if it is under my control. Fatdog64 700 beta2 is released Fatdog64'Linux Linux 3.17.1 and other updates, fixes problem with missing fonts on opera/chrome and others. <br /> <br /><a href= target=_blank>Release notes</a> <br /><a href= target=_blank>Forum announcement</a> <br /> <br />Get it as usual from <a href= target=_blank>ibiblio</a> or one of its mirrors: <a href= target=_blank>aarnet</a>, <a href= target=_blank></a>, and <a href= target=_blank></a>. <br />