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.
No 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.
No comments - Edit - Delete
Android: detecting outgoing call pickup
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.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.
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.
It turns out that it doesn't.
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. Stack Overflow 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).
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?
I solved it by detecting the ring-back tone. 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.
1 Comment - 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.
No comments - Edit - Delete
UEFI is the new DOS
As I was doing some reading about UEFI emulation on BIOS systems, I came across this interesting link: http://www.multiboot.ru/DUET.htm. In essence, that the linked page says, is that UEFI is essentially a clone of DOS. I'm inclined to agree.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 here]), 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 here]), 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?
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 here. 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.
If your system already comes with UEFI firmware in ROM - that's the equivalent of having ROM DOS. Rejoice!
No comments - Edit - Delete
One bootx64.efi to rule them all
Barry recently blogged about gummiboot, which contains an interesting link to a feature of gummiboot that I overlooked previously. Barry linked to a phoronix article, which linked to a blog post from Harald.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.
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!
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.
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.
Harald has the code here, but it's somewhat tied to Fedora and systemd. Here is the extracted code that does the actual magic.
#!/bin/sh
echo your kernel cmdline > cmdline.txt
objcopy \
--add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \
--add-section .cmdline="cmdline.txt" --change-section-vma .cmdline=0x30000 \
--add-section .linux="/path/to/your/vmlinuz" --change-section-vma .linux=0x40000 \
--add-section .initrd="/path/to/your/initrd" --change-section-vma .initrd=0x3000000 \
linuxx64.efi.stub "$1"
The only catch is this - where does this "linuxx64.efi.stub" come from?
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: https://cgit.freedesktop.org/gummiboot/ - you just need to checkout one commit before the final one (the final commit deletes everything to persuade people to move to systemd-boot).
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.
2 Comments - Edit - Delete
Fatdog64 FatdogArm double release
FatdogArm Beta4 is released.Release Notes
Downloads
Fatdog64 710 alpha is released.
Release Notes
Forum announcement
Downloads.
As usual you can find them on ibiblio's mirrors too:
uoc.gr, nluug.nl, aarnet.edu
No comments - Edit - Delete
FatdogArm on Odroid-XU4
A kind gentleman who goes by the nickname of "pjf" on Puppy Linux forum gave me an Odroid-XU4 to play with.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.
The kernel package for Odroid-XU4 (and also XU3 - these two are software-compatible with each other) is here: http://distro.ibiblio.org/fatdog/arm/releases/beta4/kernel-packages/, or on any of ibiblio's mirrors.
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.
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), *ALL( of which can be run simultaneously under HMP mode.
It is so powerful that:
---
a) I can decode h.264 1080p video and render it to 1080p, with AAC audio, using software only (no hardware acceleration).
b) I can watch youtube using html5, with audio, without any stutter.
I've never been able to do this in my previous board. It is the fastest little board I've ever used, bar none.
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.
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).
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.
No comments - Edit - Delete
Can a FOSS contributor retracts his/her contributions?
Another aspect of Rage-quit: Coder unpublished 17 lines of JavaScript and “broke the Internet” 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).I would think the answer is obvious, if we separate the contribution and the publishing.
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.
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.
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.
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.
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.
Now back to npmjs.com. They should have made it clear that they allow (or disallow) contributors to remove their contributions; and the stand by that. 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 npmjs.com is perpetual and can then choose whether or not they want to contribute. But npmjs.com can't have it both ways - because in the end you will irritate both the authors, and the end users.
No comments - Edit - Delete
Fatdog64 710 builds 32-bit/64-bit wine
Fatdog64 710 passed its ultimate test this weekend: the ability to build wine that supports running 32-bit and 64-bit Windows applications.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.
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.
Happy Easter everyone.
No comments - Edit - Delete
