Halium Project
 

Re: Halium Project
 

The Hallium Project is a noble effort but it's not something I would ever consider using in DebiaN900 or its successor. A unified HAL that encourages the use of Android kernels (many of which are EOL and unmaintained), Android blobs and systemd is an absolute no-go in my book. I think there is market for alternate OSs to iOS and Android but they must be secure and open if they are to be taken seriously. Unfortunately Hallium inherits many of the problems present in Android. I'd sooner switch to Replicant than embrace an insecure, binary blobified GNU/Linux distro. Hallium was part of my inspiration for why I made a new thread to start documenting open mobile devices.

Re: Halium Project
 

If this actually takes off it could be a good idea. Creating a common base for libhybris derived projects to share some of the workload seems like a sensible route.

As far as using Android kernels etc. I would like to avoid it where possible as well. Unfortunately due to the lack of open source drivers for some componenets you sometimes have little choice. If you try to get a working version of Maemo on something like a Samsung Galaxy or Sony Xperia, I think Android drivers are going to be the only way to do it.

I had been intending on getting a RPi 3 to work on an experimental version of hildon that would run on a stock distro/kernel. Unfortunately, due to some compatibility issues with my 3T, I've gone out and got a Moto G5, eating away at some funds. Trying to get a Maemo-like system running on that would probably require libhybris for the time being.

Re: Halium Project
 

I think it should be possible to a working version of Maemo on a Samsung Galaxy or a Sony Xperia. There would certainly be missing functionality without the use of Android blobs and libhybris for those hardware components that require them, but I think a generic Linux operating system, like Maemo, should be bootable. Several Exynos and Snapdragon SoCs used in Samsung Galaxys and Sony Xperias already have mainline Linux support.

The use of kernels with an expiry date has been a major show stopper that has prevented me from purchasing an Android or even a Jolla phone. There are millions of Android devices with unpatched kernels still in use. Halium devices with Android kernels have the same problem. I don't think it will be long before we see another WannaCry-type worm aimed at unpatched EOL Android kernels with known vulnerabilities.

Re: Halium Project
 

Pray tell me how is using Replicant solving this problem?
It uses all the same closed binary blobs as your stock android, or do you really believe it somehow magically manifests everything open??

Re: Halium Project
 

Sorry, but I'm afraid your assertion is wrong. Replicant doesn't use any closed binary blobs. There's no magic involved. It "replaces or avoids every proprietary component of the system, such as user-space programs and libraries as well as firmwares". In other words, not everything may work but it is entirely free/open and is the only mobile operating system approved by the FSF. Replicant developers have also contributed mainline Linux and U-Boot support for devices such as the LG Optimus Black and the Amazon Kindle Fire (1st gen).

Re: Halium Project
 

From the page you linked: "While Replicant is a fully free system, other components run aside the system, such as bootloaders, firmwares and the modem operating system (if applicable). These components are usually proprietary software."

I think this is juiceme's point: even though Replicant itself may be fully free, you still can't run it on anything without proprietary blobs, so it doesn't really solve anything.

Re: Halium Project
 

The question on that page to which your quote answers is, "Is my device only running free software after I install Replicant?" I've emphasised the word "device" because this question portrays a different context: open hardware vs open software. From one point of view, you're absolutely right. The devices running Replicant do not only run free software after Replicant is installed because firmware, which is closed, is indeed a form of software. On the other hand, whilst embedded bootloaders and firmware aren't free, they do not form part of the operating system and do not ship with Replicant. The devices that Replicant runs on are not 100% open but that does not mean that Replicant is not fully free.

Replicant is distributed without any proprietary code. Functionally is indeed incomplete but you have an operating system that is entirely free which still has many uses.

We're getting a little bit off topic here. The intention of my initial rant was basically to highlight that Android is a horrible OS with many problems (not only binary blobs) and Halium does not help very much with resolving them. Instead, it facilitates in bringing the same problems to GNU/Linux distros. I don't really understand the purpose of running GNU/Linux on our phones if it comes with practically everything I hate about Android. If it's for the software catalogue, you'd probably be better off with just purchasing the Android phone you desire and running a Maru OS chroot.

Re: Halium Project
 

Just so that excellent point gets some fresh air.

Re: Halium Project
 

Well yes, but the point of these mobile devices is pretty often in these features enabled by the binary blobs.

Yes, I can probably use it for many things, just as I can use just about any device that I can load a linux kernel and basic userland on; provided it has a serial port that I can connect to.

However many people are not satisfied with a device that might be missing these features;

• graphical display
• touchscreen input (well if it has a physical keyboard then no problem)
• sound output
• microphone input
• WLAN connectivity
• Bluetooth connectivity
• 2G/3G/4G/5G connectivity
• USB connectivity
• any sensors (compass, acceleration, orientation, ...)
• NFC
• haptic feedback
• ...

Almost all of these require some kind of binary driver or loadable firmaware blob that you need to rip off from Android to enable and make use of.

Re: Halium Project
 

And besides, the point of Replicant is to be "Android without proprietary code" as I understood it.

But why would someone want to have an Android clone is something I don't understand; Android is bad in many ways; it is slow, unreliable, java-oriented, ugly, uncomprehensible, noncomplient, difficult and developer-unfriendly.

If I have to choose between something that resembles Android and does not work and something that has binary blobs underneath but provides a real GNU userland, what do you think I will choose?

Re: Halium Project
 

It varies from device to device but you might be surprised to know that many of the features you've listed often do not require a binary driver or loadable firmware. They are often supported by the kernel which is of course open source. When I run Debian or Devuan on my N900, the only binary blob I need to use is the loadable firmware for wireless network connectivity. WiFi is a frequently problem on many devices but Replicant offers connectivity via an external Wi-Fi dongle as an alternative to binary blobs for certain devices. This could probably be done on the N900 too once USB host mode has been mainlined. Have a look at the Replicant status page for what features work on which devices. It does not explicitly mention the display or touchscreen input but one would presume they are provided by the kernel.

I'm not endorsing nor saying that anyone should go out and use Replicant. A Maru OS chroot on Android solves most of the problems you have listed. It's not ideal and it's not native but if the main objective is to run GNU/Linux on a plethora of Android devices (the same objective as Halium), then it does a bloody good job at that. If we embrace Android crapness such as planned device obsolescence, insecure devices, etc., as Halium does, what is it exactly that this community stands for?

Re: Halium Project
 

The more work goes into Mali or freedreno and similar projects, the better the position will be. The work libhybris based systems are doing at the moment at least lets you make use of devices or features that otherwise be unavailable. Performance wise I doubt the open replacements are up their with what they are capable of, but then I imagine libhybris introduces a performance loss.

Re: Halium Project
 

For interest

https://ollieparanoid.github.io/post/postmarketOS/

Re: Halium Project
 

Very relevant to this discussion. I read about postmaketOS earlier today and I think it sounds great. It's a good example of why Halium is not the answer to our prayers. The developer of postmaketOS shares several ideas with where I plan to take my OS. I find it very positive that he has chosen to base it on Alpine Linux which I am a huge fan of (grsecurity, musl libc, no systemd). I plan to do things the other way around though: mainline Linux is my immediate goal rather than my long term goal. I'll share more details on my OS later.

P.S. Despite my views on binary blobs, I haven't ruled out using libhybris for certain devices that run on mainline Linux but it is not a priority.

Re: Halium Project
 

Thanks
Just a reminder how impossible it is to remain up-to-date
on everything that is happening now!

excellent !
This actually raises a question I have been muddling over:

Part One
The one and only usecase I see for Android
is a few applications which do not get ported to linux.

I downloaded the latest RemixOs to examine
whether I could lock Android inside a KVM-QEMU virtual machine,
and it does appear doable.
The idea would be to firewall any and all data
emitted from the VM to remain secure,
leaving only such data available as necessary to run
individual applications.
Imagine (for example) running the Uber application to get a ride
with exactly whatever is necessary to arrange the trip
and absolutely zero anything else getting sent.
And that only when you actually need a ride,
comms sending completely disabled at all other times.

This is a solution, but rather heavy and clumsy.

Part Two

I have over the past years begun migrating everything I use
into VMs in order to have:

1. hardware portability
2. easily cloned or backed up with zero drama
3. security isolation (banking and work stuff)
4. and other operational compartmentalization
   (I have some very heavy lifting data processing projects
   which have their own libs and daemons,
   unwelcome in my desktop environments)

and this is exquisitely nice.
Moving a webservers becomes simply a matter of which
box to put it in, zero reconfiguration involved.
[I dreaded rebuilding an old Drupal install knowing it would take weeks to get that and all the associated multiple databases hanging on yet another cluster of packages rebuilt.
I simply imaged the machine for KVM and copied it onto a KVM host.
Open a port and it was a done deal with zero sweat.]
Same for my processing work images.
We had been using VirtualBox for several years,
but this year we have abandoned all that
and gone to KVM and it is sweet.


I have not worked with Docker or other such mechanisms

intending to provide virtualized applications,
but this seems like it might be part of a solution
to providing an Android segment on top of a pure linux OS.


Part Three
Running linux apps atop a Hacked Android, ala Halium,
seems upside-down, security wise.
<Imagine carrying your groceries home in upside down bags>

Turn it right-side up running Android apps on top of a linux OS
might be an answer, but some uncomfortable thoughts linger.

The problem with Halium is that vulnerabilities
are cooked into the kernel and services before
we even get to the part about running linux software.

The flipped side of running Android applications
on top of a linux modded to translate Android services
sounds okay but what about those services?

What might be a "Docker" type of implementation
sounds like a solution - the Ubuntu Touch used AppArmor
but the way it was implemented was to firewall everything
And it fails in certain ways.

That Uber App (there is nothing working like that for UT)
if it ran in an apparmor containment
might seem fine, but:
the local boys with their stingray tower network can still
track you and listen to your microphone,
watch your camera etc.
even though Uber is locked away from other apps.
(Please understand I am not referring only
to government surveillance:
there are other far more dangerous types
using fake cell towers these days and they are terrifying.)

How could we firewall just that [Android] portion of a device
that represents a threat to the system ?
All the regular opensource software we run is not a worry,
but that random Android Blob seeking your cc number
is all it takes to ruin your day,
much less some blob phoning home to Uncle Vladimir.

This guy [ Thadeu Lima de Souza Cascardo ] has an amazing page:
https://cascardo.eti.br/blog/GNU_on_...hones_part_II/


Cheers - please go back to being happy now :) :D

Re: Halium Project
 

Are you sure? I thought the alternative WL1251 Driver was completely open.

see: https://david.gnedt.at/blog/wl1251/

Or am I missing something?

Re: Halium Project
 

That sounds like the perfect use case for Qubes OS. Unfortunately it's not suitable for mobile as it's x86-64 only and would probably be too heavyweight anyway.

I once suggested to the sfdroid guys that they containerise using namespaces but I don't know whether they implemented it in the end. I stumbled onto a promising alternative the other day called Anbox. It uses LXC so network namespaces should be fully configurable with firewall rules.

The driver is completely open. The loadable firmware isn't.

Re: Halium Project
 

Very interesting, thanks for the link.

I see this here:

That 32 GB stares down a bit bulky to KVM as I run it.
KVM can be whittled down to a a very small footprint,
particularly in something like ALPINE Wicket referred to earlier here.

(I can squeeze everything of interest into about 4 GB,
but 6 GB would leave ample room for whatever.)

I may be tempted to give QUBES a spin and check it out,
but as you point out, it seems a bit heavy.

Re: Halium Project
 

It looks like they've been working on bolting SFDroid's display onto anbox.
See: https://github.com/sfdroid/anbox
and https://twitter.com/krnlyng/status/858992240408109057

Re: Halium Project
 

No it is not only that. It is a quicker road to save millions of older devices from being senselessly recycled.
Yes, fsck blobs, everybody hates em. But meh whatever, giving many more developers than only nexus device owners access to a linux phone stack is the best way to start improving the UI components (Plasma Mobile, Sailfish, Liri OS, coming multitude of wayland compositors .. .), while the clean method pursued by PostmarketOS would be perfect as an upgrade option to Halium once critical drivers have been implemented for each device.

Yeah sure. But whatever. Some of the problems can be shielded. And why leave devices just with android instead of creating a universal linux distro (alpine looks very interesting, or debian, or a mixture) that can be installed on top of any android that can be rooted.