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!

Posted on 30 Apr 2016, 03:18 - Categories: General
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.



Posted on 19 Apr 2016, 11:09 - Categories: Linux General
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.



Posted on 27 Mar 2016, 23:41 - Categories: General
Comments - Edit - Delete


Local copy anyone?

I just read this:
Rage-quit: Coder unpublished 17 lines of JavaScript and “broke the Internet”
.

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"?

Posted on 27 Mar 2016, 21:25 - Categories: General
Comments - Edit - Delete


Updated kbstate and a2dp-alsa

I've updated kbstate to detect multiple keys from multiple event devices at once, making usage a lot simpler.

I've also updated a2dp-alsa 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.

Posted on 28 Dec 2015, 20:48 - Categories: Linux General
Comments - Edit - Delete


Updated article: New Apps on Old Glibc

Somebody asked me recently about my article, How to run new apps on older glibc. He tried to follow the instructions in the article but encountered an error.

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.

I have now updated it and written the complete steps as well as re-testing the steps again to make sure that it works.

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.

Posted on 20 Dec 2015, 00:30 - Categories: Linux General
Comments - Edit - Delete


Review of meteor

Not too long ago I was looking at alternative development tools for Android other than what Googld provides. I got quite interested in meteor, 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.

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.

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.

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).

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.

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.

For one, with this much close-coupling, when the plumbing stops working or starts leaking, I can imagine that debugging will extremely fun.

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.

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.

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.

Posted on 18 Dec 2015, 03:45 - Categories: General
Comments - Edit - Delete


Puppy Linux Slacko 6.3.0 is released

Puppy Linux "Slacko" is the flagship Puppy Linux based on Slackware.

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).

The Slacko64 is the first ever official (non-beta) release of 64-bit Puppy Linux, so it is exciting times!

Go grab and give them a test drive yourself, from Puppy Linux Slacko official homepage.

Note: Fatdog64's 32-bit compatibility SFS is based on 32-bit Slacko 5.96 (beta version of Slacko 6.x).



Posted on 18 Nov 2015, 02:06 - Categories: Linux General
Comments - Edit - Delete


MariaDB: Eat your cake and still have it

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.

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).

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.

"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.

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.

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.

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? ). And this is only possible if you're doing Free software.


Posted on 8 Aug 2015, 10:05 - Categories: General
Comments - Edit - Delete


Javascript "Promise"

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.

Explanation of what it is, why it is useful, how it works, and how to write your own implementation in 90-lines - all here.

Posted on 12 Jun 2015, 06:04 - Categories: General
Comments - Edit - Delete


Pages: ... [4] [5] [6] [7] [8] [9]