Fatdog64 ISO builder is released
Fatdog64 ISO Builder is a tool to make custom Fatdog64 ISO.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.
Announcement
No comments - Edit - Delete
Fatdog64 702 Final is released.
After the planned two weeks of RC stage, 702 is finally released.Release notes
Forum announcement
Get it as usual from ibiblio or one of its mirrors: aarnet, uoc.gr, and nluug.nl.
No comments - Edit - Delete
Fatdog64 702rc is released
Maintenance update, mainly fixes and a few updated packages.Release notes
Forum announcement
Get it as usual from ibiblio or one of its mirrors: aarnet, uoc.gr, and nluug.nl.
No 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.
No comments - Edit - Delete
Updated savedir support on FAT
"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.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.
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.
Fatdog64 has supported savedir since version 620 (April 2013), this includes support for non-POSIX filesystems too such as NTFS and FAT.
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).
I've now upgraded the support for savedir on FAT as well, using posixovl; this gives savedir on FAT some support for rudimentary POSIX features, such as permissions, device nodes, and fifos.
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?
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).
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
This will be in the next release of Fatdog, whenever that will be.
No 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.
No 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.
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
