While technically correct in that it is not the 'official' Debian project, the Mobian project fills the gaps to actually make Debian usable on mobile. It's a minimal set of packages to make the Pinephone usable and work is being done to upstream the packages. I've found it's pretty much the only way to use an otherwise vanilla Debian install on the Pinephone.
Privacy&security trustworthiness-wise, Mobian is an unknown quantity (at least, to me).
That should be a big concern for something as sensitive as a smartphone/handheld, which tend to handle people's electronic communication, authentication for even more sensitive resources, etc.
One path to trust would be to become an official Debian project, and to be scrutinized by broader Debian people.
Debian packaging has a nice feature too in that you can check the source used to build it, and any of the packages will be reproducible. So if you don't trust any of the Builds on the Mobian repository, you can actually check them all yourself.
For any sufficiently large project, this becomes basically infeasible unless you have serious resources or known risks to account for.
"You can check the source" is almost a meme - how many people check the source of stuff they use? Likely very few. Most depend on history of trust and audits, and well funded groups paying people check.
In learning the Debian Packaging, I have a LOT more confidence in the Debian Packaging process, and a much better understanding of why it is what it is.
Debian packaging (the quilt format) will watch the upstream git repo and will error out if the repo being packaged is different than what is upstream. The only way to add patches is to put them into the "Debian/Patches" folder and explicitly put them in there.
In addition, one of the default CI pipelines for the Gitlab called "reprotest", which checked various environment differences to ensure that the package is reproducable.
The outcome of this is it is signifiantly easier to check that a downstream package matches upstream for the average person, rather than checking all of the source, they can look at where upstream points to and check if reprotest passes.
You are ignoring the main point of the grandparent. Even excluding the possibility that an upstream is compromised. Who is going to check all the patches by hand in debian/patches?
If someone is going to insert vulnerabilities, they are probably going to hide it well as an innocent-looking patch. So, you need a C security expert. Moreover, they probably need to do this work full-time to inspect every patch, since you do not really know what you are looking for.
As the recent covert introduction of vulnerabilities in the Linux kernel [1] and Debian OpenSSL incident [2] have shown, catching patches that introduce vulnerabilities is hard.
At any rate, I think the approach taken is fine. The project is actively upstreaming changes to Debian. But if you care about security, etc., it is probably better to wait until the changes have landed in Debian and you can install vanilla Debian.
> You are ignoring the main point of the grandparent.
Respectfully, I do not think so. I went into great detail about how Debian has technical measures to prevent tampering from upstream. If one does not trust upstream programs....well that is a bit out of scope of this issue.
> Who is going to check all the patches by hand in debian/patches?
By policy, we only introduce patches there if it is absolutely necessary, so there actually aren't very many assuming you really want to. I'd argue its a tractable problem.
> But if you care about security, etc., it is probably better to wait until the changes have landed in Debian and you can install vanilla Debian.
As I said earlier, many of the Mobian devs are the same as the Debian on Mobile team, so assuming you don't trust the Mobian devs, you probably shouldn't trust the packages we put in Debian proper as well.
> If one does not trust upstream programs....well that is a bit out of scope of this issue.
This was actually the whole point.
People say "trust us because you can check the code" but checking the code is so complex that you need trust because you can't verify everything.
> As I said earlier, many of the Mobian devs are the same as the Debian on Mobile team, so assuming you don't trust the Mobian devs, you probably shouldn't trust the packages we put in Debian proper as well.
This is where the trust comes in. Not in the availability of the code.
Debian packaging has a nice feature too in that you can check the source used to build it, and any of the packages will be reproducible. So if you don't trust any of the Builds on the Mobian repository, you can actually check them all yourself.
There are still quite some packages that are not reproducible:
Debian moves far too slowly for that to have been a viable approach. Had that been attempted, we'd be sitting here a year plus later asking why Debian still doesn't support the Pinephone. (notice that it still doesn't!) This way, we have Pinephone support today (pretty much since weeks after it was released) and the majority of the work can be upstreamed so that hopefully by the time Debian 12 rolls around it will be an officially supported device.
This website looks like it got put together by a bunch of hackers, which is fine, but to attract even more contributors and other enthusiasts it might be good to at least put an intro and screenshots on the main page.
> This website looks like it got put together by a bunch of hackers,
Yeah, we try not to gatekeep folks from editing the Wiki, which is a double edged sword, like you said.
> which is fine, but to attract even more contributors and other enthusiasts it might be good to at least put an intro and screenshots on the main page.
Thank you for the feedback! would there be anything specific you would want to see for an intro/screenshots?
Not the same guy, but a video demo of the UI (even if it's just a screengrab of an emulator) would be particularly interesting. Just something to communicate visually what using the UI is like.
It's the first thing I look for when I'm curious about a mobile (and presumably animation-heavy) piece of software.
I’m very attracted to this project because of all the Linux experiences I’ve had Debian is the one that reliably works - specifically with RPi, hardware, drivers etc.
Heh, neat to see this here! I'm one if the (junior) devs helping out on this project, so if there are any specific questions I'm happy to try and answer!
Do you have a threat/security model? Perhaps, the project is not aiming for world dominance. But if it is, it would be nice to have integration with a secure element to store secrets, application sandboxing (so that a chat client cannot read your banking session), etc.
No questions but one suggestion - it would be great to ease the process of making PWAs for the Linux space. My background is designer -> JS -> node -> mucking around with C/C++, and I think this would be a great way to seed experimentation and creativity around apps - essentially hooking into the curiosity of someone chancing on the project but then being able to pick through examples, boilerplates etc and getting excited at prospect of experimenting with some core HTML/CSS/JS skills for a side project - also specifically outside of the cloying business space of android/win/iOS. The problem with Electron is you embed an entire browser with each app - perhaps some sort of version manager that links PWAs + GTK webviews?
> it would be great to ease the process of making PWAs for the Linux space
So developing for Mobian is no different than developing for Debian (in fact then I don't need to use the Modem, I just do all of my development on a Debian Machine).
So this isn't a Mobian issue per se?
EDIT: I also checked, you can install PWAs via Epihpany (which is installed by default on Mobian).
Any plans on porting it to more mainstream phones? It seems to be aiming for "first-world phones" at the moment which is nice since they are more open and you don't have to worry (too much) about proprietary blobs and firmware but leaves a big chunk of the world out.
PostmarketOS runs on more devices (and is a great Distribution!), but they also run a lot more devices through Halium (which is a compatibility layer).
Halium is interesting because it comes with the potential of building a pmOS Generic System Image (GSI). While this would be relying on vendor-shipped proprietary drivers and kernels, literally everything else could be Free and run on mostly any GSI-supported device with a full feature set.
Yep! My personal issue with Halium is the fact that now you have devices running around today running something like Linux 3.10, which I shutter at because of security concerns.
Whoops, my mistake! Unfortunately I cannot edit my comment to reflect that.
So then out of curiosity, how are you all able to port to so many devices? Do you have a bunch of volunteers, or all most of the devices not too difficult to port to pmOS?
So a few of the pmOS folks were kind enough to discuss the pmOS structure with me, so I will try to summerize here:
pmOS has really good tooling called pmbootstrap. They are able to use the downstream kernels directly (or a mainline kernel if the device supports it), and it generally isn't too difficult to get pmOS to boot with the downstream kernel. However, because of the downstream kernel, you may not get a lot of features, and will have to work to port the features to pmOS.
They also have device catagories, so if someone wants to see the status of a device, they can look here:
https://wiki.postmarketos.org/wiki/Devices which bins the devices for a user to quickly understand how well a device runs pmOS.
We welcome users, testers, and new developers! I actually started development with Mobian earlier this year. I personally would recommend getting a Pinephone for it.
The driver situation is super tough. Modern phones are full of proprietary shit and nobody is willing/able to reverse engineer all of this, and things like documentation and data sheets aren't really available.
"Mobian aims to integrate the standard Debian distribution with Phone-specific projects and modifications in a distribution that works on certain mobile phones and tablets, such as the Pinephone, the Pinetab and the Librem 5. The idea is to minimize the Mobian specific pieces by “upstreaming” changes to the original projects as much as possible."
Its a wiki for a lot of tips and tricks to get Mobian working on the Pinephone. It has a couple of other devices it will run on, but the Pinephone/Librem 5 are the most mature.
I like to think Mobian is one of the "mature" Pinephone Distros, i.e. if there is something that doesn't work on Mobian, it will not work on any Pinephone/Librem 5 Distro.
> Should I use it?
I mean...of course i will say "yes you should!", so I guess I am more curious what you are expecting or if you have specific expectations?
> What should I expect my experience to be?
Mobian uses Phosh as the default environment, so if you have used any Pinephone Distribution with Phosh, that's about what to expect.
If you have not used Phosh....well to be honest I do not know of any good Video reviews for it, but I imagine such videos exist.
That doesn't exactly answer the question though on expectations. Is the OS stable? Are there apps that crash a lot? Should I be aware of any shortcomings that would hamper a normal phone experience?
Unfortunately expectations are very individual based, which was why many of my answers were not very helpful.
> Is the OS stable? Are there apps that crash a lot?
The OS and the apps are stable, Mobian is based on testing/sid, but if we have apps that arenot a part of Debian proper, we try to make sure they are stable.
> Should I be aware of any shortcomings that would hamper a normal phone experience?
Using it as a phone is almost there, but for me, the notable shortcoming is the lack of MMS. This is being worked on (actually I have been the primary person to work on it), and I am hoping it will be included sooner than later (within the next couple of months). I have also been working on getting Visual Voicemail to work.
Wifi Calling also does not work, and no efforts have been made on that.
But Calls, SMS, Voicemail, VoLTE (though this can be carrier dependent) all work!
Compared to other distros on the pinephone, it's hampered by having Debian as a base system. The pinephone's singular camera program Megapixels is stuck on an older version on Mobian, because the newer versions require GTK 4, which Debian and thus Mobian does not package.
(You can of course compile the GTK 4 stack yourself if you want. It's Linux after all.)
Yep. So far the plan is once Bullseye moves to stable, I think we are going to look into porting GTK4 into Mobian, as Megapixels and a few other apps are moving to GTK4.
Mobian is targeting Debian Testing/Sid. Debian is currently in freeze but after the upcoming release Mobian will start getting regular updates for every package.
By "upstreaming to the original projects", does this include upstreaming changes and packages to Debian, so that stock Debian will work as well as possible on these devices?
Nice effort. What's the state of this work? It would be amazing to have some way for Debian to be available in GSI form, even while relying on a compatibility layer.
Ahhh, Planet Computers. I really want to like their devices. They’re all Android devices that technically run Linux (and SailfishOS). The issue is all their devices use MediaTek SoC’s. So Linux comes in the form of a barely supported Debian + libhybris Frankenstein’s monster. You can run Linux on them, but you’ll be hard-pressed to do anything useful in Linux.
I would love to have Android on my phone but when I plug it into a USB-C dock, it outputs a full fat linux distro (with root access) on my monitor, using the USB peripherals as input.
Meh. The single one AOSP application that I'd actually want natively on my Linux phone is the open source Hacker's Keyboard, to enable a full-sized PC keyboard on the touch screen. Everything else can be left to an emulation layer like Anbox.
I mean, if I'm running Android on the host level and the desktop OS is virtualized or containerized, I'm not fused as long as it's a fully featured desktop environment.
If so, why don't they ship standard full-PC layouts as Hacker's Keyboard does? IME, those are especially useful in landscape mode, or else on larger-screen phones and tablets.
Found this issue tracker with related information: https://forums.puri.sm/t/using-non-latin-language-on-librem-... Looks like they're still far from basic feature parity with HK: they don't have key-specific popups for alternate inputs, and are unclear on how to support shift as a "true" modifier key (as HK does) without interfering with their existing UX, which is oriented towards composing text without necessarily involving the application. (This can be especially beneficial on smaller devices, where the "keyboard" can actually be a full-screen view with the only function being pure text entry.) A more PC-like layout would still provide some benefits though.
You certainly used to be able to run full linux on Samsung phones with Dex. I think they may have discontinued it for lack of interest. (You can certainly still use it running Android).
As a Pinephone user, i am grateful for such project as it is important to upstream changes instead of end with shattered ecosystem of per-device distributions.
But the default UI based on Phosh is problematic. Minimal configuration, broken and convoluted approach to scaling makes it rather hard to use.
> But the default UI based on Phosh is problematic.
Why do you say that? EDIT: Sorry, I did not read your whole comment. I would offer that Phosh has gotten more and more mature, and I find it to work extremely well now.
Well, my main issue with Phosh is that it seems to be designed with assumption that display scaling is set to 2. But Pinephone display is not high-DPI enough to justify that, so many applications are unusable with that (or need application-specific workarounds, like setting zoom to 50% in Firefox and terminal to counteract that).
One can set display scaling to more fitting 1, which fixes applications but breaks Phosh, who now has icons too small to be practical on touch screen. And i do not see a reasonable way to confugure icon sizes short of replacing GTK resources for that or perhaps writing custom GTK-CSS style for that.
That sucks. In modern touch-enabled UI, "display resolution scaling" and "touch element size scaling" should be fully independently adjustable, to the extent practicable. I don't think projects like GTK have that kind of support built in at present. Having responsive UI layouts for small sized screens is great but it just isn't the full story.
Interesting. I unfortunately don't know enough about Phosh to comment on it, but I wonder if you bring it up to the Phosh developers, they may have better commentary on design choices?
I’ve been eyeing the Pinephone for quite some time now. Do you use yours as a daily driver? Or have you paired it with an a more-mainstream iPhone/Android?
I’m currently using an iPhone as my social circle uses primarily uses iMessage and I’ve found it hard to migrate. As a secondary device for debugging, testing, and a “burpsuite playground” I’m using an extremely cheap Nokia I picked up a few years ago.
I think a Pinephone would be cool to replace the Android I have.
Apple loves to lock you into their ecosystem (need an iPhone to use Apple Watch, etc), but iMessage is incredibly effective and often overlooked. If you use it heavily and want to move away from Apple, your options are to simply not take part in those conversations, or to convince everyone else to switch to something else. It sucks.
I heard this is really a big thing in the US yeah. Here in Europe iMessage isn't really a thing at all. Probably because apple's marketshare is so much lower.
I know many people with iPhones but nobody ever tried to invite me to an iMessage group chat. Nobody even tried to message me with it directly, because it would have switched over to SMS and I've literally never had an SMS from a person. Just automated notifications and spam.
Not that we're much better off here because we're still stuck with proprietary stuff like WhatsApp but at least it's not locked to one platform.
I personally do not use my Pinephone as a daily driver, and the main thing that stops me from using it is MMS support (I am also the lead dev on integrating MMS into the Pinephone). As soon as MMS is fully integrated, I will use it as a daily driver.
I have a few TODOs on that (which I haven't had tine for recently, but I should be able to get back to it this week). There's a few TODOs in there, so maybe work on them? (But then again, it's more a function of working with the chatty Dev than anything else).
Help testing and refining the code is also welcome too!
There is also a Matrix room you are welcome to join if you want to help, or to see how things are:
Currently, i am using it mainly as a tablet/web-browsing device when i am not near my desktop computer. My primary SIM is in an older Android phone. It would need some more work to get Pinephone ready to replace all important tasks i use the Android phone for.
Honestly, if I were to make an Android competitor, I'd try my best to compete by obviously using Linux but also including a solid package manager based on Debians, or snap and including buyable packages and a simple process for others to put their apps on said package manager / store. Maybe it can be a separate app that is optional. I'd also ensure full support for Progressive Web Apps.
Yeah, PWAs will be critical to the survival of third to market OSes which can't get large developer investment from major brands. I live in constant frustration that Windows Mobile was shut down the release prior to Windows supporting PWAs.
While I don't mean to take away from what the devs are doing (as it is awesome!), the modem is in two parts: a "user space" that is an version of Android (yes, the modem runs Android, I think Android 7?), and the actual modem has a lower level firmware based on Qualcomm Hexagon, which is still closed source, and not easily replaceable.
If you're looking for an actively developed Maemo rebased on top of modern Debian, you might be interested in Maemo Leste. [1] It's actually rebased on top of Devuan Beowulf rather the Debian (Buster), but they are open to having a Debian flavour with systemd too if anyone is willing to add support for this.
