Notices


Reply
Thread Tools
Community Council | Posts: 3,920 | Thanked: 9,128 times | Joined on May 2012 @ Southerrn Finland
#11
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?
 

The Following 9 Users Say Thank You to juiceme For This Useful Post:
wicket's Avatar
Posts: 486 | Thanked: 2,202 times | Joined on May 2010 @ Colombia
#12
Originally Posted by juiceme View Post
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.
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.

Originally Posted by juiceme View Post
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?
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?
__________________
DebiaN900 - Native Debian on the N900.

Mobile devices with mainline Linux support - Help needed with documentation.

"Those who do not understand Unix are condemned to reinvent it, poorly." - Henry Spencer
 

The Following User Says Thank You to wicket For This Useful Post:
Posts: 1,093 | Thanked: 2,512 times | Joined on Dec 2010
#13
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.
 

The Following 3 Users Say Thank You to Android_808 For This Useful Post:
Posts: 1,371 | Thanked: 1,585 times | Joined on Jun 2010 @ Göteborg, Sweden
#14
 

The Following 6 Users Say Thank You to handaxe For This Useful Post:
wicket's Avatar
Posts: 486 | Thanked: 2,202 times | Joined on May 2010 @ Colombia
#15
Originally Posted by handaxe View Post
For interest

https://ollieparanoid.github.io/post/postmarketOS/
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.
__________________
DebiaN900 - Native Debian on the N900.

Mobile devices with mainline Linux support - Help needed with documentation.

"Those who do not understand Unix are condemned to reinvent it, poorly." - Henry Spencer

Last edited by wicket; 2017-05-27 at 00:04.
 

The Following 6 Users Say Thank You to wicket For This Useful Post:
Posts: 570 | Thanked: 1,166 times | Joined on Aug 2010
#16
Originally Posted by handaxe View Post
For interest

https://ollieparanoid.github.io/post/postmarketOS/
Thanks
Just a reminder how impossible it is to remain up-to-date
on everything that is happening now!

Originally Posted by wicket View Post
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.
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
__________________
Three n900s: One for stable working platform,
One for development testing Chopping Onions
One for saltwater immersion power testing resurrected ! parts scavenging

My Mods for Wonko's Advanced Clock Plugin:
ISO8601 clock mod and Momental_IST clock mod

Printing your Email with the N900

Last edited by theonelaw; 2017-05-27 at 09:53. Reason: add links
 

The Following 2 Users Say Thank You to theonelaw For This Useful Post:
Posts: 1,080 | Thanked: 1,623 times | Joined on Feb 2011 @ The Netherlands
#17
Originally Posted by wicket View Post
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.
Are you sure? I thought the alternative WL1251 Driver was completely open.

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

Or am I missing something?
__________________
N900 loaded with:
CSSU-T (Thumb)
720p recording,
Pierogi, Lanterne, Cooktimer, Frogatto
N9 16GB loaded with:
Kernel-Plus
--
[TCPdump & libpcap | ngrep]
--
donate
 

The Following User Says Thank You to mr_pingu For This Useful Post:
wicket's Avatar
Posts: 486 | Thanked: 2,202 times | Joined on May 2010 @ Colombia
#18
Originally Posted by theonelaw View Post
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.
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.

Originally Posted by theonelaw View Post
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.
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.

Originally Posted by mr_pingu View Post
Are you sure? I thought the alternative WL1251 Driver was completely open.

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

Or am I missing something?
The driver is completely open. The loadable firmware isn't.
__________________
DebiaN900 - Native Debian on the N900.

Mobile devices with mainline Linux support - Help needed with documentation.

"Those who do not understand Unix are condemned to reinvent it, poorly." - Henry Spencer
 

The Following 3 Users Say Thank You to wicket For This Useful Post:
Posts: 570 | Thanked: 1,166 times | Joined on Aug 2010
#19
Originally Posted by wicket View Post
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.
Very interesting, thanks for the link.

I see this here:

System Requirements
Qubes Release 3.x
Minimum

64-bit Intel or AMD processor (x86_64 aka x64 aka AMD64)
4 GB RAM
32 GB disk space
Legacy boot mode (required for R3.0 and earlier; UEFI is supported beginning with R3.1)
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.
__________________
Three n900s: One for stable working platform,
One for development testing Chopping Onions
One for saltwater immersion power testing resurrected ! parts scavenging

My Mods for Wonko's Advanced Clock Plugin:
ISO8601 clock mod and Momental_IST clock mod

Printing your Email with the N900
 

The Following 2 Users Say Thank You to theonelaw For This Useful Post:
preflex's Avatar
Posts: 138 | Thanked: 513 times | Joined on Apr 2010 @ Albuquerque, NM, USA
#20
Originally Posted by wicket View Post
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.
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
__________________
Leap before you look.
 

The Following 3 Users Say Thank You to preflex For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 07:12.