I stated it so people can come to their own conclusions as to whether or not they want to use it, as it is a deal breaker for some, but not for others.

TheMightyCat got it working in userspace, but it’s AI code.

I know that’s the case in the US with FCC regulations. Not sure about other countries. I believe SDRs are illegal here (US), although things like the HackRF One and Flipper Zero are still sold. Getting the modem to be whitelisted for use on carriers is a whole other story, though.

So isolating a proprietary, off the shelf modem from the system RAM by not having it be on a PCIe-like bus and having a hardware killswitch would be the next best option.

It’s a shame there aren’t any open source modem designs out there. Something that concerns me with Qualcomm SoCs is that their integrated modems have complete access to the system RAM (or at least, that’s what I heard). Would it be possible to interface with the modem through a more limited protocol that supports hotplugging, like USB for instance? That way, it can also be completely disconnected with a killswitch like what the Librem 5 has.

So if you end up making a RISC-V phone, those would require complete rewrites?

I don’t think they are the norm for small projects, mainly due to price. While an external security audit would be nice, I’m talking more about the question of how many people have looked at your code who also happen to be security experts? I think asking you to get an actual professional security audit would be unreasonable due to the cost of getting one.

So fingerprintd depends on the phone having a TPM? That makes sense. For whatever reason, I thought it did the actual processing itself.

I’m asking you about your code specifically. You’re not a maintainer of 81voltd, so asking you about that wouldn’t make too much sense. I am asking you and not the maintainers of 81voltd out of convenience, though, since you are easy to get a hold of on a convenient platform and are likely to respond. If I were to get a hold of the 81voltd maintainers, I would be asking them the same question.

Wouldn’t fingerprintd also have an attack surface, given it’s an authentication daemon?

I’d ask if there’s a chance at GNOME Mobile support since that’s by far my favorite mobile Linux DE, but given their strict anti-AI policies, I don’t think that would be a possibility, at least not if upstreaming is the end goal.

This isn’t a question exclusive to the use of AI, but moreso involves being new to low level systems coding in general, and that is one of security. Given smartphones in particular are highly portable devices that are the first to be seized, especially in more fascist-leaning countries such as the US, security is of upmost concern, even compared to other computing devices like a laptop, desktop, or a server. Not including your kernel code that has already been mainlined, has your code been audited by any security experts, especially your userspace code that is not part of the kernel, and thus will not be reviewed by any kernel maintainers?

If you agree with the points, then how is the ban shortsighted? It’s not like the ban can’t be revisited in the future.

While you do host a repo, pmOS device packages can’t depend on imsd/fingerprintd/etc. since they’re not in pmOS’s main repo, so it adds extra steps for the end-user. I’m unsure if pmbootstrap supports building images with external APKs either, and if not, it would have to be done post-install.

There is another problem that I haven’t mentioned, and that is since your packages already exist, that demotivates other people from working on LLM-free code that performs the same task, even if it doesn’t eliminate it entirely.

If you do not fully understand the code you’re working on in a deep, architectural sense, is that something you are willing to improve upon over time to the point where you will no longer need to use LLMs to code?

I await your post about it, as I’m curious about your viewpoint, especially going more in-depth.

The already mainlined kernel patches wouldn’t need to be rewritten since they’re already in the mainline kernel. I didn’t see where you specified that before.

But not all HWE is in the kernel. For example, your userspace VoLTE daemon is extremely useful for those who need VoLTE, but would not be able to be packaged in pmOS so other devices can benefit from it, since pmOS is the de facto mainline Linux distro for mobile (there are others, but pmOS is the largest and where most development is done). Same goes for your fingerprint daemon.

There is, of course, also the ethical matter of using AI, as the pmOS page mentions, but balancing issues of pragmatism and principles have been a challenge in the FOSS community since the beginning (ex: “free software” vs “open source”).

On the last point about understanding the code, I feel you’ve shown that you are able to understand the code that you commit, or at least I hope that you do. I’m willing to take you at your word when it comes to that.

https://docs.postmarketos.org/policies-and-processes/development/ai-policy.html

postmarketOS bans contributions written either entirely or in part by LLMs, so your contributions would be disqualified under those policies.

The Linux kernel, as far as I’m aware, does not have these same policies, so if your changes were to be mainlined, then the Linux kernel changes would then trickle down to pmOS, but your userspace programs/services would still not be able to be accepted upstream, nor would any of the non-mainlined kernel changes.

That’s a shame to hear. I wonder how many of the ideas will be able to be rewritten by actual human developers and how much of it will have to be scrapped.

The Fairphone 6 and 6+ is something to keep an eye on, specifically with TheMightyCat’s build of postmarketOS. It’s almost fully functional with a close-to-mainline kernel, unlike Jolla phones and UBPorts, which both rely on Android kernels which will eventually stop being supported.

When it comes to an ME/PSP analog, there is ARM TrustZone, but each vendor has their own implementation, so whether or not it constantly runs in the background, has full access to system memory, and is completely proprietary is up to each vendor. When it comes to phones and laptops that support cellular connections on the other hand, the integrated baseband, which also has full access to system RAM and is proprietary would be my main concern.

RISC-V has a memory tagging implementation: https://github.com/riscv/riscv-memory-tagging/tree/main

Both AMD and Intel are working together on an x86 memory tagging implementation called ChkTag: https://community.intel.com/t5/Blogs/Tech-Innovation/open-intel/ChkTag-x86-Memory-Safety/post/1721490

AMD iGPUs are hard to beat for things like gaming. IDK much about running AI models, since I don’t care much about that kind of stuff.

Power efficiency is really the only thing that ARM has over x86. Also RISC-V theoretically has better power efficiency compared to ARM, though since RISC-V is so new, more advanced implementations would need to be developed first in order to match the performance per watt in a full-fledged desktop-class CPU.

When it comes to laptops, I’m personally sticking with x86 until there are faster RISC-V CPUs available that I can daily drive in a laptop.

Even though ARM has much better battery life compared to x86, I’d still just be trading one proprietary architecture for another.

The Fairphone 6 and 6+ can theoretically work with any distro that has 64 bit ARM support. The close-to-mainline kernel fork is where most of the important work is being done, and the rest is in portable open source software (like VoLTE support in userspace, for example).

If you don’t already have the Jolla hardware, I’d consider getting a Fairphone 6 or 6+ instead and using TheMightyCat’s build of postmarketOS. They’ve been doing some insane work with hardware enablement on the close-to-mainline kernel for that phone to the point where it’s almost 100% fully functional.

I’m not a big fan of SailfishOS due to its proprietary userspace.

GrapheneOS on devices that can run it, LineageOS on devices that can’t.

I’m keeping an eye on AXP.OS since DivestOS has stopped being developed.

That is, of course, if you’re only counting Android and not Linux mobile. If you are, then I’d add PostmarketOS to the list, though it’s hard to find a device that can be used as a daily driver yet, though the Fairphone 6 is very close.

Yeah, and regulations across different countries has to be even more difficult. IIRC in the US, the baseband has to be proprietary, but I could be wrong on that. Are you planning on releasing the schematics and gerbers for it, and/or are you planning on selling it commercially a la the Pinephone?

I’m just looking forward to a fully functional mainline phone in general. Having it be RISC-V as well would just be a cherry on top.