Allows you to have a digital copy of your ID and sign in to government sites/services (there are alternative methods).
(Linked from the post: https://forum.syncthing.net/t/discontinuing-syncthing-androi...)
But for a "normal" linux environment on a phone I recommend postmarketOS. They make an effort to support a variety of user interfaces, init systems, devices.
Still, it is important to consider that the hardware and driver support is the limiting factor here. The camera is very bad on the pinephone because it doesn't have the image processing capability to record video in realtime. It also has no OpenGLES3 or Vulkan. Very poor lima GPU.
But. I think what we should ask for now should be simpler. Let this be an alpha geek toy, let folks fiddle with some basic devices boards that can do the thing. The work on PinePhone, Mobian, others is good pioneering work, alas largely held back by there just being so few decent devices for folks to play with. The driver situation keeps making hope here impossible.
It's not a high hope, but Qualcomm has a QCM6490 chip is maybe a rare hope. A chip that is somewhat buyable by regular makers, an extended life version of the Snapdragon 778G. It's pretty modern, and comes with very featureful connectivity hardware. We're seeing variants like non-cellular Radxa Dragon Q6A in the field. Particle has a new Tachyon board you can buy with it. https://www.cnx-software.com/2024/07/31/tachyon-business-car...
It's just stunningly rare alas that folks can make systems with vaguely modern cellular chips. The cores are just not available generally. Sure it's be great to have a well produced Linux phone that is super consumer acceptable with a great OS build out, a new or revived Maemo or a Jolla Sailfish: folks who can go sign the NDAs and make a consumer device but have it be Linux. But I think for this dream to really take hold, humanity needs to be afforded some possibility to have an honest shake, some chance to be a little closer to the machine than typical cellphone bargain. The lack of cellular chip availability has been so so damning to this quest. And here is one counter-example, a crack in the wall, where I see flowers and hope grow.
There was some real nice moments where it seemed like maybe some Snapdragon cellphones in general we're getting Linux support to some level, in mainline, just for the base stuff. No cellular. Unclear to me but it seems like maybe those were just the very barest of beginnings; whether any peripherals at all work or whether there was even a screen is unclear. The trickle of releases also seems to have died off. FWIW though, I will note the previous Fairphone 5 does use the above QCM6490. https://www.phoronix.com/news/Linux-6.1-Arm-Hardware
(not a plane) https://www.youtube.com/@Ground-Effect/videos
Trains - not so hard, it's getting legit real track time that's the issue - and you can always 'cheat' with a Hi Rail Pickup Truck modification.
Automobiles - .. you are kidding, right? You've never built (or met a builder of) a road certified car, truck, or other vehicle?
https://grapheneos.org/articles/attestation-compatibility-gu...
> FuriOS allows for running apps inside a container running Android codenamed Andromeda. This container has complete integration with the host and makes all Android applications work like native applicationsSo many committees - so little progress.
I ran this with a custom fork to expose the device screen as a VNC server for years, no problems
Apps developers can decide to require Play Integrity so your Android fork cannot be used to run their apps.
Google can decide to not support or explicitly exclude your custom fork. Due to Play Integrity used on their own products, you cannot run Wallet on most forks where Google is not running as root.
Google can decide to delay or not publish source code so your Android fork cannot be maintained anymore.
Manufacturers, Google and developers can alter that deal at any point in time. Recently:
- Delayed patch of AOSP unless your are a partner: >>45158523
- Wall of shame of manufacturers locking bootloader: https://github.com/melontini/bootloader-unlock-wall-of-shame
Those "annoyances" are only one of the attacks made, and not all of them can be easily defended against without having the manpower to actually maintain your own hardware and software stack.
Hell, my watch runs Tizen and that's running a bog standard Wayland + PulseAudio + systemd setup: https://docs.tizen.org/platform/porting/system/#systemd
With the right kernel drivers, configuration, and tweaks, with a well-configured userland on top of that, you can run the "normal" Linux stack in a mobile device.
Getting applications to conform with an API that won't let them drain the battery in the background to make sure notifications don't arrive two seconds too late is much harder. Desktop applications don't really like being suspended/resumed the way mobile applications do.
1: https://www.belastingdienst.nl/wps/wcm/connect/nl/intermedia...
https://gpdstore.net/product-category/gpd-handheld-gaming-pc...
https://www.usnews.com/insurance/auto/how-do-those-car-insur...
Only a question of time until it becomes mandatory
https://github.com/microg/GmsCore, so basically you cannot. It's monopoly in daylight.
Most banking apps in Germany use this API and thus work on GrapheneOS and other non-Google controlled ROMs with a locked bootloader.
PlayIntegrity is unnecessary and mostly offers vendor lock in to Google's ecosystem.
> Why not try to fork AOSP or GOS
Which concerns do you share? Both AOSP and GOS must follow the Google development strategy, they aren't exactly independent on Google (which is a problem: >>45208925 ). Nevertheless GOS on Librem 5 or Pinephone would be a nice idea, except the GOS developers are against that: >>45101400
> Linux's (nonexistent) security model
Linux's security model is based on trusting the software you're installing from the FLOSS repositories, and it works very well.
See also: https://puri.sm/posts/closing-the-app-gap-momentum-and-time/
Personally, I'm pretty enthusiastic about the whole Lemmy project, and I think it's actually a much better fit to the federated ActivityPub model than Mastodon.
Ah, I have to admit I don't know much about porting :) We did put up a community wiki and the HADK is up there: https://sailfishos.wiki/books/hadk/page/hadk so that you might get some idea of the process ... I'm not sure to what extent this is different from that 'halium' builds that piggz makes. It makes sense to ask him directly, since he has a stream lined process that targets, among others, the phones you have.
As to why the hardware adaption layer is needed (ie. the android one) it's where all the binary blobs are :) Among other bits.
Android is based off, and runs off a linux kernel: https://en.wikipedia.org/wiki/Android_(operating_system). Android being modified in places including userspace is a fair point, but it's linux derived.
MacOS reminded me of it's BSD intermixings. Although the BSDs are separate from Linux, both were Unix alternatives. MacOS was downported to iOS. While iOS is not Linux at it's core, it's definitely based on an alternative to unix, similar to linux.
BSD references: https://developer.apple.com/library/archive/documentation/Ma...
We focus on helping end users adopting "alternative mobile OS", we compiled a list of those alternatives on our website: https://sailmates.net/actors/
we also provide phones at-cost (aka without making benefits) for users interested in those alternatives but without the technical knowledge to flash one
GrapheneOS are against using their development resources on a platform that is drastically, significantly worse than the hardware platform they already have, which is quite fair. It is not about Pine64 or Purism's products specifically. They would not be against them if they met 95% of the requirements detailed in https://grapheneos.org/faq#future-devices. It would more sense to explain which of those requirements you think are unreasonable.
Which added vnc support directly onto scrcpy, so I could leave a tablet plugged in to my headless server and access the tablet remotely via VNC
The alternative was to use X11vnc but it was janky and had some issues, plus higher cpu usage
I was actually surprised it is this good. I reinstalled recently and before the reinstall I had much worse battery life (Maybe 8 hours with normal usage). I think it was because of Syncthing running in the background.
It is also possible to use s2idle suspend which will improve the battery life even more but you will not be able to receive calls during suspend (though that may also be fixed in the future)
Let me heat up the discussion using this quote
> The Linux kernel has atrocious security. It has an anti-security architecture, implementation and culture. The Linux kernel is not a good base for building any new operating system with a focus on privacy and security
My GrapheneOS phone fully supports such facilities. I trust your app works on it?
here's all you need to do, if not: https://grapheneos.org/articles/attestation-compatibility-gu...
> Applications are security principals. The main difference to traditional operating systems that run apps in the context of the logged-in user account is that Android apps are not considered to be fully authorized agents for user actions. In the traditional model typically implemented by server and desktop OS, there is often no need to even exploit the security boundary, because running malicious code with the full permissions of the main user is sufficient for abuse.
https://dl.acm.org/doi/fullHtml/10.1145/3448609
And then there's also:
- No root access (by default)
- Verified Boot
- Hardware-backed key store and hardware attestation
- User profiles are encrypted independently of each other
- …
https://developer.android.com/privacy-and-security/security-...
This works by signing an attestation using a hardware-backed key (which is in turn signed by Google). So, there is no way to emulate this in software, because your ROM simply does not have the private key to do so. Part of the attestation is information on whether the booted operating system was signed:
https://source.android.com/docs/security/features/keystore/a...
Again, since this is all hardware-signed, you could only fake this information if you were somehow able to extract the private key from the secure element. The primary weakness is that you could try to patch out the part of the application that asks for this attestation. But they found a solution to that, remote attestation. Instead of the app asking for the attestation, e.g. Google's servers or your bankcan ask for the attestation and for the reasons outlined above, your custom firmware is not able to fake this. If your bank, etc. implemented remote attestation, you can simply do not do banking on your phone anymore.