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.
No comments - Edit - Delete
Fatdog64 lives on
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.If you want to follow what has been updated recently, you can look at an overview of the changes since 701 release here.
Also, recently somebody asked me what Fatdog could do, so I decided to write an article about it here.
No 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).
No comments - Edit - Delete
Bluetooth support for Cubox-i
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).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.
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
, and there were no notes whatsoever saying these configs are needed at all 
. I have been using Solidrun's defconfigs (= manufacturer knows best, etc) - and badly beaten by it, wasting hours on unnecessary debugging 
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.
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.
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.
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.
With this, the FatdogArm platform support for cubox-i is considered complete.
No 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.
No 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.
No comments - Edit - Delete
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?
No 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
No comments - Edit - Delete
Fatdog64 701 is released
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.Release notes
Forum announcement
Get it as usual from ibiblio or one of its mirrors: aarnet, uoc.gr, and nluug.nl.
1 Comment - Edit - Delete
Misc updates - PSIP, FatdogArm, xlogin
I have implemented multi-account support in psip, 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.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 release notes.
xlogin is a very small Xorg login manager, more basic that slim 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 here.
Among other changes, it now works with authorisation (MIT-MAGIC-COOKIE stuff), and I have re-coded xlogin-rootjpeg to use stb_image so it no longer depends on libjpeg - plus ability to resize the image on the fly.
3 Comments - Edit - Delete
