Hardware-ology - how to restore a Vaio laptop to Win10

So I happened to get ahold of an old Vaio Laptop. No recovery disk. At time of use, came with Win7.

My kids have asked for a laptop for a long time for now, and I figured this is a good shot.

However.

The Vaio is pretty old (~2018 or such), and targeted to Win7.
The bios on it appears to NOT be able to boot from other than FAT32 partitions.
Win10 images come in UDF format (some industry craze of later times apparently),
which - you guess it - cannot be picked up by the bootloader on the Vaio (needless to say, the bios is as barenaked as possible).

After excluding also PXE (my home router does not support it); it seems there is time to take a different step. How about slicing out the extras from the Win10 installation image to make it fit on a 4GB partition? In the end, it's merely 1.8 GB over that limit. Shouldn't be that hard, right?

So I found this link from Dell that tells how to slice the windows image.

However.

I have been a debian user for about 7 years now, so there is no windows machine around at my home.   

So,  the best solution was to get one of the Edge Virtual machines Microsoft kindly provides, and hope the tool in question ("dism") is available...and guess what? On the Win10 VM, it is!

So, downloading the latest Win10 ISO, installing guest tools on the Edge VM, sharing a folder, correcting the file access rights to basically 777 to _everything_ and splitting the install with this command:

`dism /Split-Image /ImageFile:"c:\temp\install.wim /SWMFile:"c:\temp\install.swm" /FileSize:4000`

Great. That was easy. Now we have a Win10 ISO that fits on a FAT32 partition.

Unfortunately, the Vaio still does not comply with the USB stick and just display an empty screen with a flickering cursor.

The Vaio itself is not a USB-3 device. But the stick is 2.10.

Bummer.

So the next step is, if it's not a "legacy" boot device, it can only be a UEFI one, right?

Thanks to the Alpine people, over here we have perfect instructions on how to create a UEFI-compatible boot stick.

So, in this case, reformat the stick, and re-sync all the files (this has become tedious by now hasn'it it?).

Well, same result. Bummer #2

EDIT : long story short, downloading Rufus and installing the ISO on the usb stick was the straightforward solution. Done.
For some reason, the formatting of the stick is incredible specific for these old MBR/UEFI booting machines.

The Barber paradox

The barber, a well-shaved man,  shaves all and only the people from a town who do not shave by themselves. Who shaves the barber?

A barber - as defined by the assumption - is someone who shaves all and only people who do not shave by themselves.
Furthermore, any individual is a barber, as long as he shaves more than one person. Let's assume for simplicity there to be only one barber.

"All" in the context of the statement is not defined as a number; but we can assume (for the sake of simplicity) for it to be more than one, i.e. at least two. The definition, furthermore, states also that there is more than one person (=people) that do not shave alone.

Lets assume all the villagers, including the barber, those who shave alone, and those who don't, to be individuals. Let's also focus only on the individuals who do not shave alone, and the barber, and forget the ones who shave alone.
Let's further include another assumption, i.e. that all individuals can shave.

Assuming we have only one individual acting as a barber all the time in the town (i.e. one single individual who shaves more than one, and all persons from the set that do not shave alone).

In the set of individuals, a barber stands out as an individual who shaves more than one person - in fact the barber shaves "all" the people who do not shave alone - except himself, which he cannot, due to definition (this btw precludes him being part of the set of people who do not shave by themselves). All other individuals can shave without being barbers, as long as everyone shaves only one and the same person - the barber.

All the people who are shaved by the single barber can therefore shave the barber; as the barber is a single individual; they do not have to be considered as barbers in the terms of the original definition.

This sets the barber into a "special" barber set - it shaves everyone; but is shaved by everyone else.
Moreover; the barber is not a barber, if he shaves himself.

Is this crazy or what?

Further developments:
- barber is a role that changes from individual to another (in turns; the question is, not who shaves the barber, but who is the barber today? ); i.e. can there be more than one barber in the town, for whom the same restrictions apply?

JIRA herp derp!

So you want to use jira, because it's fancy and great and awesome. Yes you are right, it is good (at least for sw development).
And you want to do it quickly; so you use a docker container?
And you want to use it safely; so you want HTTPS?
And you do NOT want to put it behind an apache reverse proxy?
Well, Tomcat supports https just well.
BUT! Keep in mind that the key store needs to be in JKS format,as the JVM is 1.8.xx. Yes, ladies & gents, in atlassian's docker container, the JVM is ancient.
I just spent three hours figuring out why "trustAnchor is empty". Herp derp

Let's do the time-warp again! Or, compile LLVM in SB2 on the SFOS sdk (x86 target)

Yes; this sounds like one of these epic challenges.
The stock browser of SFOS is pretty much abandoned to itself. It is gecko-based; gecko has been labeled as "deprecated" by Mozilla, then as "still supported", then got re-promoted to a (somewhat obscure) "we keep it until we can switch". The switch in question meaning to be the jump to servo, a rust-based web engine used in their latest quantum-based firefox. So the idea is to compile it on the x86 target to begin with.

Achieving this faces challenges.

In order to achieve this goal, we will need clang, which requires llvm and a decently recent (>=4.9.5) gcc compiler, as well a decently recent python 3 verison (>=3.5.0). On top of this, we have here:

a) the glibc in the mer toolchain (at the time of writing) is stone age (2.19)
b) the compiler in the mer toolchain (at the time of writing) is old (4.8)
c) the compilation environment, scratchbox2 (a legacy development chroot originally developed by Nokia), has aged a bit, but the taste has slightly bitterned, and might cause acidity of stomach to some newer software's.

The first two points affect mainly the correct functionality of llvm.
llvm as a compiler is a different type of beast. In that it reimplements some functionalities in it's own ways, to ensure portability across multiple platforms. For example, locks via symlinks (same as pthreads do for instance). This exact feature of llvm is the first hurdle to overcome in order to get a functional toolchain; it uncoveres a non-POSIX conformance issue in mer / scratchbox2 (on i486 architecture) related to symlinks path resolution (in the mapping logic).

scratchbox2 as a development tool is very powerful; it allows to build for multiple targets, by isolating each specialized environment, and allowing fine-grained customization for the developer; combined with easiness of switching between these. Needless to say, the flexibility of this tool is admirable. Packages can be installed in specific environments(so-called "targets"), multiple architectures are supported, targets can be exported/copied, you name it. All of this is possible thanks to an interception layer, provided via a customized pre-loader library, configured as default when entering the development MER chroot, and which takes care of mapping the active target to the "real" counterpars (in terms of files) by intercepting and managing the most well-known System calls / glibc api's (open, close, execvp and so on).
It needs to be also mentioned that nowadays (with MER merging int SFOS) the platformc chroot has been officially replaced by VM's, which ship scratchbox2 pre-installed.


The 'box2's interception layer's has limits, however, and they become visible on our journey to firefox. Take pthread, for an example; a library on it's own, but which (as an implementation) "lives" at glibc's home repository. This vicinity causes trouble for sb2, as the closeness gives way to  "priviledged" relationships (in terms of api's) between pthread and glibc; now before you scream in disgust, these types of "close" relationships are very much acceptable from a glibc's or pthread's perspective (coherence of api's), if not welcomed (performance), and make sense in glibc/pthread's universe (coherence). But for the outsider's ('box2) interception layer, as an alien, this is a major problem, an interaction which is totally invisible to the SFOS development environment, and hence causes lots of things to go havoc (for example multiprocessing module of python, which internally relies on system-V semaphores).

And unfortunately, there is more glibc features which rely on many private counterparts of public api's. Up to the point where common POSIX libraries become non-functional under scratchbox2 (we already mentioned these - systemV semaphores anyone?) on some targets (i486, for instance),  or exec's, which also fall into the set of functions utilized internally by glibc via a private api. Exec's are for example used by the posix_spawn api's, which in turn - you know where this is going - are used (if the spawn.h header is detected, and is the case as MER ships it) by llvm.

Nevertheless, with these issues out of the way, you should be able to reliably compile the llvm. So now to the funny part, the compilation. Did I mention MER has an ancient glibc? (e)glibc 2.19 , as used (at the time of writing) by MER, lacks certain floating point operations (sse3 & more recent), which llvm relies on. Though these are not critical per se, they might turn up iffy warnings during compilation (if not bugs at runtime), hence relative build.rs files which include them in the compilation need to be patched to exclude them.

Once done so, you should have a clean LLVM implementation running on SFOS. Enjoy!

Of Mountains, Tablets, and fishes - A story of porting SFOS to Teclast x89 tablet

In Raethoromanian(Ladin)/Dolomites mythology, mountains have always played a big role.

A legend tells the story of a girl from the (Dolomites) mountains, accidently noticed by a Prince hunting in the area, and of the two subsequently falling deeply in love with each other.
Soon realizing the fact, and realizing her son is reluctant to back out of the relationship, the Queen forces him to move the girl into their home, the castle of the Realm, so that they could get properly married, and live together.
It so happens that the people from the castle did not approve of the relationship, and foremost did not accept the girl, even before her entrance  to the castle; they envy her, hate her, and shame her on her first public appearance, at which, out of shame and shyness, she turns into a small mountain furret (montagnóla).
The guests appear shocked, and consider killing the animal, but suddently the unexpected : a fire-like halo shines in strongly from the windows.
The guests, scared by the unusual event, curiously glare outside, wondering if the town is on fire; only to notice a once-gray mountain turned glooming fire-red! The ground creepily starts shaking, the castle slowly collapsing on itself, into the ground. The girl and Prince barely escape to safety; they are destined to become King and Queen of what is the biggest Ladin myth of the Dolomites, the Reign of the Fanís.
The mountain has been fire-red ever since, as of to reminding humans to their humbleness, and can be admired even today, in the Dolomites area of Sennes.

What does this have to do with tablets, and more to with fishes?
Quite few, if nothing at all, of course!
Or, perhaps the effort required to seize the top of a mountain, is comparable to the amount of work required to port SF OS to a new tablet HW?

In the spirit of "if the mountain does not come to I, I will go to the mountain" (see, mountains again!); if Jolla did not (manage to) make a tablet for me, well I'll be damned if I can't make one for me. It's a challenge to myself.

This series of posts are supposed to give an insight in the deep works of kernel porting, modules compiling, booting, involved when porting SFOS to new Hardware. I hope people will find it inspiring, and start experimenting on their own. Sailfish is a great OS, and most of all, a great idea (even tho still lacking in terms of full freedom). This, coupled with the amount of things I will (need to) learn on the way to it, is reason enough for me to try. And most importantly, I want to have FUN doing it.

The chosen hardware for this effort, is the Teclast x89, featuring a cheap Intel Bay Bridge SoC, 2 GB of RAM, 32 GB of flash, sd-card slot, dual boot Android / Windows 10 out of the box, and (luckily) unlocked bootload.
All in all, a decent Hardware replacement for the official Jolla tablet.

But first, some considerations:
DISCLAIMER : ANY OUTCOME OF THESE ACTIONS ARE THE RESULT OF YOUR OWN RESPONSIBILITY; I AM NOT RESPONSIBLE FOR DAMAGED HARDWARE / SERVICES / EQUIPMENTS. This is advanced hard work; if you are not ready to risk your hardware, or do not have a ginuea-pig hw, DO NOT START.

Still interested? Stay tuned for the next posts!

Virtualbox and Win7 issues

If VirtualBox does not start on Win7;
uninstall it, install it without USB emulation (add it afterwards).

XDG VS SailfishOS

During development of Quickbar, I happened to stumble upon a small issue related to XDG and mime types. This same issue has been raised over at tjc forums lately, so I got inspired and restarted digging.

The problem : lookup of mime types seem to fail relentlessy; opening files with xdg-open as of now (release 1.1.9.28) opens Documents application, no matter which file is actually opened. "So what", you might ask, "where's the problem, apps on SailfishOS rely on QT. We can open anything we want with QDesktopServices::openUrl". Unfortunately, qt internally (and QDesktopServices::openUrl more specifically) relies on xdg-open. So to investigate this, I followed the xdg-mime trace given in the comments of the tjc post.

On SailfishOS xdg tools refer to mimeapps.list for storing mime type associations; xdg scripts come from the package xdg-utils (in case of mer 1.1.0-rc3, keep in mind this version number cause it's the cause of all evil). This is a weird part, but everything is still correct here; this was quite misleading for a long time, as I believed the problem to be mimeapps.list being used as DEFAULT even outside KDE envs; that held until I stumbled on this post in the freedesktop mailing list, which claims that defaults.list has been declared deprecated and superseded by mimeapps.list. In fact, the specification does not happen mention defaults.list at all anymore. The same issue is raised in different environments as well, for example on  this post of the lxde group
 From the same LXDE group post, it seems  the latest and greatest (yet unreleased) version of xdg on the master contains a fix for this. issue.