Things like running a distributed database for a community on top of the devices they own, hopefully also running true mesh networking.
Also, choosing the OS means freedom to choose the interface you like or develop your own (or to pay somebody to do that for you). Freedom to not be in walled gardens.
He doesn't want to create an LLC because he doesn't want anyone to question his motives.
Also this is the Netherlands not Germany :)
Does this HW have access to PDAF pixel data?
For example here's patches to get NFC YubiKey working in Secrets app:
https://github.com/pimeys/oneplus6-yubikey-nfc
It is a work in progress but pretty easy to pick things up and fix in this age of agents...
Genuinely, I am going to log off Hacker News and not come back here. Or any social media to be honest. The lot of social media is just doing nothing but raising my blood pressure, making me miserable, and making me more afraid to actually go talk about things with people in real life. And it sucks and I ought to know better at this point.
If someone ever sees me use this site again, and scrolls my profile, this is permission to bully me off of using this website :).
I said "Using LLMs makes a unmaintainable climate-destroying bug ridden slopfest."
Does an LLM make unmaintainable code? Generally, yes. Its tremendously verbose, with structures strange for humans.
Climate destroying? Depends on the LLM, but if its a US corporate based one, then yes. Just go look at the methane burners and diesel burners needed before power grid hookups years later. Climate devastation for sure.
Bug ridden? #7 on HN is "AI-Generated GitHub Copilot “Autofix” Allowed Compromise of Snowflake's Jira" https://news.ycombinator.com/item?id=49331423
All of that defends the slur 'slopfest', which is well deserved.
Whether it's unmaintainable depends on how big it gets. That patch is 200 lines of comprehensible code, it passes. Plus what are we comparing against for maintainability and bugs? Novice code? No code at all? Treat it as a prototype for a valuable feature instead of implying it's worse than useless.
But the slopfest and verbose code is where you’re missing the bigger picture. Model written code can be understood by other models. That means future models could improve that code even more in the future.
But the biggest thing you’re missing? If that code compiles, works, and is secure? The value to people between now and a new model making it better is something gained, not lost.
Progress doesn’t happen over night. But just because it doesn’t, doesn’t mean we stop the presses and write all the books manually because we don’t have the internet yet. It means we work with what we have, derive value from it, to use that value to invest into the future.
> I didnt say "pimeys sucks".
I heard "nekusar sucks".
If you're looking for a daily driver the most reliable I've seen is the furi phone. Those guys are passionate and have put in a pathological amount of time to getting calls working world wide. They can only pull it off by supporting one phone that they sell.
The Jolla C2 (SailfishOS) and Volla Phone Quintus (Ubuntu Touch) are also pretty good daily drivers, only issue is they they're only available in the EU.
Also worth keeping an eye out for the upcoming Comodore Callback (SailfishOS), which is being shipped worldwide.
The SoC vendors get Android working, get the drivers going, help do ports or modifications for major customers and hide it all behind NDAs, blobs, sometimes a bunch of hacks and all of it is closed source work.
The postmarketOS guys to their credit are trying to do "proper" mainline work which is admirable but probably frustrating, non-trivial and requires a lot of reverse engineering.
- AI code generation is way over-hyped and is only 1% capable of the feats that the advocates claim.
- AI is too expensive to use, and even if it is 100 times less expensive than a human for the same task, there is still too much cost involved.
- AI are secretly nerfed for free-software projects.
- No one has bothered to try AI on free-software phone projects yet.
- Other?https://source.puri.sm/Librem5/hw/l5-schematic
The repo name is "schematic", but it also contains ECAD (and a link to MCAD) designs and BOM published on a free license.
I've been daily driving GNU/Linux phones for 18 years now and I keep seeing people dreaming about things we already have!
Librem 5 runs an FSF-endorsed operating system, i.e., it's 100% free software in the OS.
Unfortunately even that one is missing modern replacements of outdated unsupported AOSP sample apps (like Phone and Contacts, others can be replaced without extra privileges).
I'm not sure it has to have money involved to be serious, and in fact the last time Lineage had money involved it didn't end very well.
Of course money has to be involved.. try asking them whether device X will be supported or try reporting a bug. First you'll be verbally abused by "BadDaemon" (https://gitlab.com/BadDaemon), then you won't get the answer and your bug (and patch) will just sit in the tracker, because as this incredibly kind guy will explain to you, they're volunteers, they'll fix the bug when they want to, or they will never fix the bug. They might support the device in the future, or they might not and you're not supposed to ask about that unless you want to interact with BadDaemon - this interaction is the only thing guaranteed there.
Of course there are awesome people there, like npjohnson or mikeNG, but a pack of volunteers just can't compete with big tech giants..
I also, more directly, mean that they do generally have separate versions of core apps.
Anyway I'm not sure that one of the oldest and most longstanding third-party ROMs anywhere in the Android scene would fail to meet the threshold for "serious."
My advice would be to not take the frustrating and useless road of a non-profit structure for some things that you do for pleasure.
The for-profit will be simpler and give you more liberties, and if, in the end, you have the good mindset that you want your creations to be shared freely, you can do it anyway. It is a state of mind.
Even in the day to day, like for him to pay himself a salary or do expenses, things could be tricky as administration could easily consider as personal abuse of funds of a non profit.
We had Librem 5 which had real OS support that didn't have to rely on third-party volunteers, I wish they released something more modern..
Is there any precedent to believe that such a thing is in fact possible?
> and volunteers have to use hacks
I have terrible news for you about how the official firmware works.
> to unofficially implement basic Android 1.0 functionality years after a device was released?
Conversely, in other places it's far better than Android 1.0. But yes, if you can only start developing against the device after it's released, then your software will be released after the hardware ships plus development time.
> That's sad to see. This is just lame, drivers should be implemented by those who work on them..
My general understanding of the Android ecosystem is that they do write drivers, and you don't want those drivers. I like to imagine that somewhere that out there somebody must be making phones with high quality software, but I've never heard of them.
> I have terrible news for you about how the official firmware works.
I've seen some e-waste ODM (Tinno) code and their freestyle philosophy on modifying the kernel code.. however they at least have to fix this so that basic functionality works as there's QA and serious bugs will affect certification and they'd not get paid. But here if you report a bug to PostmarketOS (but well, even LineageOS), nothing will happen unless you fix it (and if you submit a patch, it will sit there forever, welcome to FOSS).
> My general understanding of the Android ecosystem is that they do write drivers, and you don't want those drivers
What's wrong with pixel drivers for instance? I'm of course not talking about those written by e-waste ODMs like Tinno who can't even release GPL kernel sources properly.
A couple of issues , back from my sailfish os porting days (haven't touched it in half a decade so things might have changed):
1. You would still need to run a lot of Android user space to make use of these drivers. We had a separate second init system that runs a stripped down version of Android init, starting enough services to make use of these drivers.
2. These binary drivers are tied to the kernel and Android versions that were released with the phone. So if you wanted some of the newer kernel features (back then it was like better container support), you're out of luck.
Usually, all this means you rely on a lot of hacks to fix some bugs... And porting takes a lot of time and effort.
Where did you get this idea from?