32-bit computers - my Linux Mint woes.

Amongst the Linux distros that I deem warrant some of my precious harddisk-space, Mint has earned a coveted spot, mainly due to its long-term support for its stable releases - the current one is good till 2019.  It has become apparent to me however that this 'support' is spotty at best, particularly where 32-bit hardware is concerned.  Anyway, Mint/Mate-desktop was/is set to eventually replace Ubuntu 10.04 on my setup - progress, and all that.

Although I've had problems with Mint from the get-go, two issues have been particularly annoying on my 32-bit laptop from the beginning.  One, Caja's audio-preview has a bug where, while 'previewing' an audio file, the file-manager itself would freeze, requiring that it be forcibly closed.  And two, already-generated thumbnails would be deleted each time you logged-out/rebooted, necessitating that Mate generate all of the thumbnails-cache over again - a time-consuming, CPU-intensive process.

With the latest major upgrade of Mint having been recently made available, now up to 17.3, it was with a heavy heart that I discovered that not only are these two bugs still alive & well, things have actually gotten worse.  Now, thumbnails are deleted throughout the session, so there is no rest-bite at all!  I actually contributed to a bug-report on these problems here about 6 months ago, although these problems have existed for much longer than this.  Then, I also discovered a way of fixing the thumbnail-bug, which involved patching the source-code before recompiling.  The Caja-freeze problem was fixed by 'merely' recompiling the Caja package.  'Merely' is emphasised for a reason - unfortunately, Mint doesn't make things easy for you, with its current Caja-build requiring many separate packages, whereas Git's Mate/Caja compiles everything into a single package.  What all this means is that you can get conflicts between installed Mint-built packages, and those that you build locally from Git source when you try installing them.

Fixing it!

As stated in the long-winded version above, this only effects 32-bit Mint 17.x setups, in this particular case Mint 17.3 (Rosa).  Three packages need to be rebuilt;

mate-settings-daemon (thumbnails bug)
caja (audio-preview bug)
caja-extensions (so we don't lose extensions, like 'caja-share')

Essentially, you should build these packages yourself from the Mate-Git repository, and in the case of 'mate-settings-daemon', first applying this patch, but in case this all seems a bit too much, I'll provide links to the packages that I built for my setup, but with the warning that it is always risky to install 'unknown-packages' on your computer!  You of course need to first remove the affected packages, so as a first step, remove the following Mint-built packages;

mate-settings-daemon-common (which will also remove 'mate-settings-daemon')
caja-common (which will also remove 'caja', plus a few more)
gir1.2-caja (causes a dependency-issue otherwise)

Now things get a little tricky!  Most people will want to hold onto the 'mate-control-center' application, which the Mint developers have seen fit to have made 'caja-common' one of its dependencies - a part of the main app we are replacing!  Our new Caja-build, although functionally identical, is built differently, incorporating all of its required dependencies (like 'caja-common') in a single package. So in order to get things to play nicely together, a little subterfuge is called for.  The easiest thing to do was when building the 'caja' application, to build it as 'caja-common' - that way, when re-installing 'mate-control-center', 'caja-common' is seen to be already installed, so the installation will proceed.  Short version - only one Caja package is installed, the newly-built 'caja-common', which contains everything needed, extensions excepted, while also satisfying the 'mate-control-center' dependency issue.  So, install the following new packages;

caja-common
caja-extensions
mate-settings-daemon

And then reinstall 'mate-control-center'. The final step is to add a new entry to Startup Applications (System->Preferences->Personal->Startup Applications) that will auto-start 'mate-settings-daemon' each time - name it 'mate-settings-daemon' and set its 'Command:' line to "/usr/libexec/mate-settings-daemon".

That's it!  Logout/reboot and everything will hopefully be hunky-dory.  The only casualty of doing all of this seems to be that you can no longer change Caja folder-colours, as there's no code for this function available in Mate's Git repository.  On the upside, you do get up-to-date versions of these packages (1.13 versus 1.12), as well as no longer suffering the indignity of Caja continually locking up, or thumbnails being continually regenerated.

Edit1:
I didn't expect to be returning to this, but here I am! I suffered a mini-meltdown on the Linux front today, after a software lockup, followed by a somewhat impatient physical switch-off of the computer.  Mistake.  When my Linux installation would no longer boot, I went the suggested route of doing a manual 'fsck' - Mistake 2.  I was greeted by (what turned out to be) 100's of 'inode' errors, to which I blithely Yes'd all of the prompts to repair.  Mistake 3.  Although it would now boot, it was obvious that the damage was extensive - Caja or Nemo for instance refused to run.

Though things looked bleak, I knew I still had the backup of Mint 17.3 that I had made before my aborted attempt at replacing it with Mint 18.1 - 7 months old, but good enough.  The OS image rewrite got about half way through the process when the writing software complained that the saved OS image-file was corrupt - despite having been on a different partition! - and it needed to reboot.  Now it appeared, not only had the crash completely fcuked up my 50GB OS partition, but my 200GB data storage partition as well - FUUUCCKKKKKK!!!

On recovering, one fresh installation of Mint 17.3 later, followed by an online software update, I discovered that ALL of the bugs that existed over 2 years ago in Mint 17.3 are still there - really disheartening.  Compiz for instance, still does not work.  Neither have any of the bugs mentioned in this post been fixed, nor has the ability to mount ISO's greater than 2GB - so much for 2 years worth of "Development".

But to the point of this edit.  After the fresh install of Mint 17.3, I set about fixing the bugs noted here by downloading the files & following the instructions listed above.  To my surprise, for the most part it worked!  I had installed so many packages on the old setup over the years that I felt sure that some dependency issue with a fresh install would have arisen - but no!   The only problem that I encountered concerned the Caja extensions.  The Mint developers have a one-package-per-extension policy, whereas the single extensions package that I built contains all of the extensions.  The only problem this caused me was that I first had to locate & remove 4 or so extension packages that had already been installed, before installing my 'all-in-one' "caja-extensions" package.  No biggie, just irritating.

Other than that, I'm almost back with a working system.  Compiz caused me the most problems.  With all versions since 2014 unworkable on my now ancient hardware, and after a fruitless internet search for ppa's containing the sought-after versions, I eventually was forced to go trawling for the individual packages themselves - an onerous chore, or so I thought!  Turned out that Canonical's site layout makes it really easy to locate all of the needed files - just do a search from this page (this for the 'Trusty' software-base), select the package, then your CPU architecture, then download the file, just a few clicks for each file, easy peasy!  The only challenge is discovering the order that these (9) packages then need to be installed in, as many treat others as dependencies.  I could list their install-order here, but where would be the fun in that!

Edit2:
I hate a mystery, so I decided to hunt down the reason for Mint 17.3's 'Disk Image Mounter' not working.  It's not confined to Mint either - I know from experience that it doesn't work with the 32-bit version of Deepin Linux 15.4 as well, so basically the Debian package itself is broken.

The problem is that, compilers, on their own, for 32-bit builds, default to defining variables as 32-bit numbers, unless explicitly told otherwise.  However, many programs need to work with numbers whose magnitudes can greatly exceed 32-bits - 'gnome-disk-utility' for example and the package of interest here, may encounter disks of many terrabytes in size.  'Little' 32-bit variables are no longer sufficient in situations like this, and require the use of 64-bit variables instead.  In the past, 'gnome-disk-utility', properly programmed, had no problem doing this, and long before 64-bit CPU's were even widely sold - so it has nothing to do with "ancient hardware" as many suggest. So what has changed?  It seems obvious, with fewer & fewer 32-bit computers being used, less and less testing is being done of 32-bit applications running on 32-bit hardware.  Understandable in a way, but imo, unacceptable where obvious bugs are allowed to occur across multiple version releases, often spanning YEARS - 'gnome-disk-utility' being a prime example.

Technically, all that is required is the following one-liner at the start of the code;

#define _FILE_OFFSET_BITS=64

I tried to do this on my 'fresh-install' of Mint 17.3 but failed miserably as it resisted all of my attempts to install some of the needed development packages.  This I think was down to my having added a ppa ('mc3man') to my setup in order to acquire 'ffmpeg', which 'Trusty' doesn't have in its repositories.  As this version is 'current', I suspect that up-to-date dependencies were also installed which had the effect of breaking 17.3's old libraries setup. Whatever the reason, I instead opted to install a 'fresher-install' of Mint 17.3 on another drive and try to build it on that.  It worked - another bug bites the dust!  'gnome-disk-utility' 3.12 is the result, downloadable below.

gnome-disk-utility_3.12.1-1_i386.deb

Incidently, while playing with the 'fresher-install', I also installed the working version of Compiz, realised that it was even more of a chore second time round, so made note of the packages installation-order, listed below.

libdecoration0_0.9.11+14.04.20140409-0ubuntu1_i386.deb
compiz-core_0.9.11+14.04.20140409-0ubuntu1_i386.deb
libcompizconfig0_0.9.11+14.04.20140409-0ubuntu1_i386.deb
python-compizconfig_0.9.11+14.04.20140409-0ubuntu1_i386.deb
compizconfig-settings-manager_0.9.11+14.04.20140409-0ubuntu1_all.deb
compiz-plugins-default_0.9.11+14.04.20140409-0ubuntu1_i386.deb
compiz-plugins_0.9.11+14.04.20140409-0ubuntu1_i386.deb
compiz-gnome_0.9.11+14.04.20140409-0ubuntu1_i386.deb
compiz_0.9.11+14.04.20140409-0ubuntu1_all.deb

Edit3:
Another 'tweak' to my setup before backing it up, in readiness for the next crash!  This time it's the file-manager Thunar.  Although Caja is obviously my file-manager of choice, Thunar has its uses, as it's much faster & efficient memory-wise at thumbnailing lots of pics, and also has a really nifty extension application called 'BulkRename'.  As I had already read that the 'current' 1.6.10 version in the Trusty repositories was buggy as hell, I initially opted to install an earlier version that is still in the repositories - version 1.6.3 - couldn't get it to work properly, so decided to build from source, version 1.6.11 instead.  This I did, but on running the following little test, discovered that it too had another (different) bug that also caused it to freeze.  The test simply creates some files in the folder of your choice (first line) then continually renames them.  Leaving said folder open in Thunar would normally result in it locking up within a few minutes.

 for i in $(seq 1 10); do touch "$i.txt"; done
 while true; do for i in $(seq 1 10); do mv "$i.txt" "$i.txt.txt"; done; sleep 1; for i in $(seq 1 10); do mv "$i.txt.txt" "$i.txt"; done; sleep 1; done

After some more reading, I found that the 'freezing' bug has (hopefully) been fixed as of version 1.6.12.  Below is the package that I built, which has one dependency (exo-utils) that will be downloaded & installed automatically.  Even so, one thing that caused me a major headache was that although all of Thunar's dependencies are accounted for, on my 'build-machine', Thunar would run, whereas on my 'work-machine' it wouldn't, complaining that a certain shared library was not found.  Yet there it was, plain as day, for all to see!  After searching aimlessly for inspiration for what seemed like an age, I eventually came across this post on a French forum that provided the solution.  Merci!!!  Run as root;

ldconfig

That's it!  Not sure exactly what it does but after running it, the shared library was found and Thunar now works.  The above test has been running on it for over an hour with no lock-up - so fingers crossed!  One other thing, I've had to "--exclude" one item from the package when building it with 'checkinstall' - /usr/local/share/icons/hicolor/icon-theme.cache.  This as it happens is also part of my 'gnome-disk-utility' build, and while I'm not entirely sure as to its purpose, I do know that Thunar appears to function perfectly well without it - even with 'gnome-disk-utility' not installed.

thunar_1.6.12-1_i386.deb

Note:  While adding this 'fixed' Thunar to my Deepin Linux installation, an issue arose.  Without having first installed Thunar from the repositories, BulkRename refuses to run, even after issuing the 'sudo ldconfig'.  Investigating, apparently the 'repository-install' creates a symbolic link (named "Thunar") to "thunar", which is in the same directory.  This requirement is part of a "dirty hack" - Thunar-source comment - to get it to run on the Xfce desktop.  My build on the other hand, does not create this symbolic link to "thunar" that BulkRename needs,  so it doesn't work, pure & simple!  If this occurs, first create the symbolic link manually - ie. do a;

sudo ln -s /usr/local/bin/thunar /usr/local/bin/Thunar

Then do a sudo ldconfig to include this link in the rebuild of the 'symbolic links to shared libraries cache'.  From reading, 'ldconfig' is normally done automatically whenever an application is installed via 'makeinstall', but since I'm building a discrete package with 'checkinstall', this does not occur.

Edit4:
 Never figured on an Edit4 for this old post!  I recently became fixated on getting the appImage of 'Avidemux' running on Mint 17.3.  After discovering that Avidemux 32-bit versions were no longer a thing, I had the cunning plan of installing Mint 17.3_64-bit alongside my everyday OS, so side-stepping the issue.  This ultimately proved futile, because as others had discovered before me, recent (yet, going way back) appimage builds use updated libraries that never made it to the Mint 17.3 repositories.

 Nevertheless, with the 64-bit version installed, I decided to enable Ubuntu's 'esm' critical updates service, particularly when I (re)learnt that it would extend the life of this old girl, all the way to April 2024 - cool!  I then resolved to fix the 'audio-preview freezing bug' as I did here for Mint 17.3 32-bit.  Below are the new Caja builds, which also feature a version-upgrade bump to 1.14.2.  There's no messing about this time with caja-common as described above - just install the new Caja & caja-extensions, leaving the old caja-common in-situ.

caja

caja-extensions

I'm an Android Owner... finally! First Impressions.

I've intentionally avoided getting involved in the smart-phone/tablet mania of the last few years.  In truth, I didn't see the need for one.  My trusty old Dell laptop, over 10 years old now, can still handle anything I can throw at it - and no, I'm not a games-player, apart from the odd game of Mahjongg, so no state-of-the-art hardware needed here!  Phone-wise, I still have an old Samsung SGH-D500 (original battery too) that is more than adequate of my humble needs.

But a Dragon x10 tablet owner I've become, for better or for worse.  Being a hater of all things Microsoft, and a Linux-buff with 8 years experience using that OS, an Android-based tablet was always going to be my first and only choice - Android of course having derived from Linux.

First, a word about the hardware.  The x10 sounds on paper a fairly impressive beast.  ARM7-based, it features a 8-core CPU, clocked up to 2Ghz, a snappy GPU, 1Gig RAM and 16Gig internal memory, 5M-pixel/2M-pixel cameras, coupled with a wide-viewing-angle 10.6" screen - all for €130, available from Amazon Germany.  Incidently, it is available marginally cheaper from Amazon UK - or would be, if they shipped to Ireland, which they don't - hence the German sourcing.  Fuller details on the x10 are available here.

So yeah, for the price, it's a well-spec'ed piece of kit, and very snappy in use.  It comes with a 7600mAh battery and claims some impressive run-times between charges - so I decided to do a quick test with a looped video.  With a fully-charged battery and using MX-player with hardware-decoding enabled, I managed to get just short of 13.5 hours of continuous video playback from it - which I found kinda amazing!  I should also add that that was with the minimum screen brightness, namely because that's the way I use it normally, but it also had both wireless & bluetooth enabled at the time, as I had forgotten to turn them off.

Firmware-wise, my x10 came with Android Kitkat 4.4.4.  Amazon UK had claimed that Tablet Express (the x10 manufacturer) was selling them with the new & improved Lollipop 5.1 before I had ordered, so I was disappointed to discover mine was Kitkat-based when it arrived.  Lollipop was available as a download from T.E though, so it was an opportunity to compare & contrast both systems.  I played with Kitkat for about a month before upgrading to Lollipop.

Upgrading proved a real ordeal too!  Although T.E don't make clear what Microsoft OS's are compatible with their upgrade software, as it looks like something that was produced for Windows 3.1 (so really bad) I presumed XP could easily handle it.  No such luck!  Try as I might, over the course of two days, XP resolutely refused to work with the upgrade-software.  I eventually had to borrow a copy of Win7 and to temporarily install that, all just to upgrade the x10's firmware!  It was also the first time that I had ever installed Windows 7 on a 'real' machine (I used it once with VirtualBox, but it had proven too slow) and must admit given my past recollections with Windows installations, this was a much improved experience.

Anyway, onto Android itself, and (imo) the whole setup's Achilles-heel.  First, its good points.  On the x10, most user-actions are super-slick.  Obviously a lot of thought has gone into the user-interface.  You also have more software available for it than you will ever get a chance to try - if you can ignore all of the ads!  But given that I'm old-school (my first computer was a Sinclair Spectrum) and more interested in the implemention, and know from experience just how good Linux's multitasking capabilities are, I was surprised at the obviously poor job that Android does on this front!  Given that there are 'proper' Linux distros that come on installations as small as 10Meg (Core Linux) I know that it doesn't take gobs & gobs of memory to create a 'proper' multitasking environment.  This Android does not do!  I was even more surprised to discover that earlier versions of Android had no multitasking capability at all!  Rather than a System Monitor (or Task Manager in M$ parlance) where the user can monitor & interact with running processes, all Android has is the Back-button - and it is not at all clear what this does!  Sometimes this will terminate an app, sometimes it will just send it to the background.  A perfect example of this sloppy implementation involves the use of Browsers for surfing the net.  Boot Firefox, open your favourite page, do some reading, hit the 'Recently used apps' button to start say Gmail, then head back to Firefox - what you find is that FF has been terminated, and is forced to reload its entire setup!  This sloppy handling cannot be down to lack of memory - I have 1Gig after all!!!

It is hard to come to terms with this shoddy performance, especially given that Android is derived from Linux, which has being doing 'proper-multitasking' since forever!  I can only surmise that Google has been putting all of its development effort into the GUI - but that still doesn't explain their not using already-existing technology!  I have even read that Google/Android, rather cynically, terminate/reopen apps intentionally in order to generate more revenue from the ads having to be reloaded!  If Google is following this route, then they will eventually end up getting their just desserts.

Long before Google even existed, Microsoft & Yahoo ruled.  Yahoo in particular I remember as dominating cyber-space.  And they really took the piss!  I recall how Yahoo would lace their search-engine results with irrelevant links (mostly porn-related) and to hell with what the user was searching for.  Along came Google, offering a really good search-engine with the minimum of unobstrusive ads - and they cleaned up!  If they are now going to go and undo all of that good work by producing a half-arsed OS that intentionally starts/stops apps, just so they may generate a little more revenue, then they are idiots and deserve to be kicked off of their pedestal.

After the initial novelty of the tablet, I find myself going back to the laptop more & more.  Sure, the tablet is handy, indespensible in some ways - I forgot to mention its bluetooth-headset music capability, which is superb, and its main-use here nowadays.  But being somewhat of an OS-purist, imo, Android is a huge step-backwards as far as proper multitasking is concerned.

Edit:
A quick addendum.  3 - 4 months down the line, here are a few more thoughts on this purchase of mine.  First off, one thing I didn't mention above, and something that has existed from the get-go, is that this x10 tablet suffers from a charging problem.  The charger itself is your typical cheap-and-cheerful Chinese type, complementing the tablet perfectly.  The problem is that when you plug it into the tablet's charge-socket, the tinest movement of the charger's lead will cause intermittent charging - I have often set it to charge overnight, only to find next day that no charging has taken place!  Given that the charger-plug itself looks fine, I initially thought that it was a soldering dry-joint that was causing the problem.  After carefully opening the tablet - no unscrewing necessary, it's of the 'clam-shell' variety - I am now (thankfully) again of the opinion that it is probably the charger-plug after all.  Although a dab-hand with a soldering iron, given the component dimensions involved (sub-millimeter resistor/capacitor sizes, which is kinda scary!) I really didn't want to go messing in there.  The circuit board is also tiny, especially considering the tablet's size - probably 100mm square all told.  Thing about the charger is, it's a 'custom-type', with a teeny 2mm charging plug - so no place to buy another to see if that would fix things!  Another charging-related problem is that occasionally when you plug in the charger, the tablet completely freezes.  This is really disconcerting, as the only thing you can then do is hold down the power-off button and hope!

Regarding Android, one thing I've discovered is that despite all the 'anti-rooting' articles I've come across, after you use Android for a while, rooting is the only way to go!  Two places where a rooted-device is essential, ad-removal and Bluetooth-GPS.  Before I rooted my tablet, no matter what software I installed, I could not get my Bluetooth GPS-dongle to work with the tablet.  Once rooted, things 'just work'!  Same goes for ads-removal - internet browsing with an unrooted Android is generally a pain, often unusable.  Once I installed 'Adaway' on my rooted device, browsing became a pleasure again.  My opinion of Android itself has not improved one iota either.  If only Unix/Linux could sue Google for bringing its superb multitasking capabilities into disrepute - seriously, it sucks!!!