Small web browser
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?
Well, you _could_ make a small web browser like that. Just make GUI shell that links in libwebkit.so. Yeah. That would work. May as well create a shell script that launches firefox. Hey, small browser in 512 bytes!
Seriously, can we have a small browser, without external dependency, that weight less than 500K (excluding the weight of the GUI toolkits)?
The answer is you can; and the key to that is libgtkhtml2. 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.
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).
I have made such a browser, and you can download the source here. 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).
Note about libgtkhtml2 source: 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 here. I took this version, applied as many forward patches I could find (mainly from the also defunct svn.o-hand.com - and also preserved by Yocto), and added my own stability patches. This final copy of libgtkhtml2 of mine is located here.
Final note: libgtkhtml2 is old. It *will* 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 netsurf, links2, or other excellent projects - and while they aren't as small as libgtkhtml2, they do work for modern Internet.
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 help viewer that links to multi-megabytes webkit libraries, do you?
Comments - Edit - Delete
mdview: a small, GTK-based markdown viewer
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.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.
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.
From the homepage:
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.
Get it from here: https://chiselapp.com/user/jamesbond/repository/mdview3/home
Comments - Edit - Delete
Never mind. I found one.
I am a subscriber of Mikey's Funnies, and has been for a very long time.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.
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!"
Miraculously, a parking space suddenly appeared.
Paddy looked up again and said, "Never mind. I found one."
[forwarded by Adon Brownell]
How many times do we act like that ourselves?
Comments - Edit - Delete
xannonate/xscreenshot updated
Minor update to xannotate/xscreenshot: 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.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.
Comments - Edit - Delete
Maximum size of initramfs
Well, I'm still around.
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?
I have answered the question here, but I didn't explain why the numbers are what they are. This post attempts to correct that, if you're interested.
When considering this question, there are two things to remember:
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
b) how much RAM the kernel will want to allocate for holding initramfs.
For the system to successfully boot, (a) must be the same or less than (b).
(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.
(b) is a bit more complicated. Traditionally the kernel will use "ramfs" for initramfs (that's why it is called init-ramfs ...
), 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).
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.
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 ...
Rob actually has a patch to do exactly this, using "rootfsflags", but don't count on it going to mainline kernel soon.
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).
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). Q.E.D.
Comments - Edit - Delete
jamesbond3142.no-ip.org no longer used.
I have relinquished control over the old domain of this blog and wiki, which was "jamesbond3142.no-ip.org". I have put a notification here but apparently I still have a few links pointing to the old domains.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.
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.
Comments - Edit - Delete
New article - Linux multi-seat
It has been a while since I wrote an article, so here is a new one: Demystifying Linux multi-seat.Comments - Edit - Delete
Xscreenshot updated
Add "delayed" snapshot function to Xscreenshot accessed by Shift-hotkey). This is useful when you want to capture open menus etc. The usual way of pressing hotkey to capture won't do because as soon as press a key, the menu is closed."Delayed" snapshot avoid this by you pressing the hotkey first (to trigger the capture), and it giving you the chance to open the menu, and after a while it will do the capture behind the program's back.
Get it from here.
Comments - Edit - Delete
New URL for this blog
This blog and its corresponding wiki is now accessible from http://www.lightofdawn.org/. So it's time to update your bookmark or your RSS reader
. The original URL will remain for a while, but will eventually be removed.
Comments - Edit - Delete
aufs - please support Mr. Okajima
Aufs filesystem is a full-featured, full-fledged layered filesystem for Linux, created by Mr. Junjiro Okajima. It is an alternative to "unionfs", Unlike unionfs, however, aufs is actively developed, and actively supported. Unlike other alternative Linux layered filesystems like "overlayfs", aufs is feature rich and has a lot of options. Aufs is mature and stable software, it is about 10 years old by now.I don't know how extensive aufs is used in the field, but I have a suspicion that many "live" OS systems (with support for persistence) will use aufs in form or another. I also think that aufs would be widely deployed in the embedded world, where one needs to have "writable" rootfs while still having the base OS in ROM. What I *do* know is that aufs is used in Fatdog64, FatdogArm, Puppy Linux and its multiplicity of derivatives, Slax, AntiX, and perhaps many others.
I recently had the pleasure of working directly Mr. Okajima.
I had problems with kernel oops with FatdogArm on cubox-i. Researching the problems, I found that kernel oops was a known common problem in the official cubox-i kernel and there were some solutions - but they didn't seem to work for me. My oops symptoms were quite different, too - the kernel didn't immediately crashed; but all filesystem operation failed, which lead me to suspect that the problem may have had to do with aufs (the other popularly Linux distros on cubox-i - Arch, Ubuntu - they all don't use aufs as far as I'm aware).
I escalated the problem to Mr. Okajima through the public mailing list and to my pleasant surprise, found that he was all courtesy, and very responsive. Mr. Okajima is very knowledgeable person - not only he helped me to troubleshoot the problem, but he actually solved it. This is despite the fact this was his first time looking at problems in ARM systems (and the problem required looking at ARM code dissasembly to find the cause); and the fact that he didn't have any ARM boxes whatsoever to reproduce the problem. One rarely encounters this kind of support and talent - even in the commercial world.
I'd encourage those who beneftis from aufs - especially commercially - to support the work of Mr. Okajima in whatever means that they can. Donation link is here (this goes straight to Mr. Okajima - not to me).
Comments - Edit - Delete
