Or the phone just does "good enough" processing on its own without the user having to do anything else.
I personally use Lightroom and have Photoshop as part of the same subscription but rarely use it. (And Lightroom can do most of what I need without a lot of intervention other than some cropping on my part.)
In my case, that reassurance finally gave me a foundation to work on.
I finally knew that it wasn't my fault. I understood thst I didn't deserve what happened. I didn't need to chastise myself for breaking down during flashbacks. For the first time in my life my emotions got a concrete basis of "Yes, that is trauma. It's fucked up. You can work on it." and not "Why are you still worrying about stuff from 20 years ago" or "Well that happens to everyone, and they don't break down like you".
>by the time you have it worked out, the phone is obsolete and very few people still use it.
If you work out a phone from 5 years ago, you're not that far off from a phone of today. Nobody designs it all from scratch, you mostly modify the old one. Getting the foundations going will take years - adapting the foundation to a different phone of the same series will only take months.
Hardware is hard. It doesn’t always have the transparent composability that software has because you hit physics and the real world.
The example already given makes the point. Work has been great on the M1 but my understanding is that this has not translated all that well to e.g. M2, M3 and M4.
From my understanding of the article, Postmarket or Lineage or any other mobile operating system will be able to make use of this project. The goal is to provide FOSS drivers, so that you can run Lineage without proprietary blobs copied from the distribution of Android provided by the device manufacturer.
It's mainly a libre purity project. A Lineage user won't be able to tell a thing, but the system will be "ethically pure"
There aren't even any arm or x86 desktops that are completely blob free. There is some ridiculously expensive amd power hungry power9 thing that nothing will run on, and some of sifive's newer boards might qualify. Every arm at least has some soc blobs. And every x86 has something like ime. Going straight for a blob free phone seems like getting ahead of ourselves. How about we shoot for a completely free rpi usable on the desktop first?
It os definitely more open than most, thanks! I'm pretty sure it still has the masked boot rom before getting to the open bits. While the tpl and ddr are still blobs and might harbor naughtiness, people have at least figured out how to edit the blobs https://github.com/hbiyik/rkddr
U-boot for Rockchip builds it's own TPL. I'm using it right now. It can also use Rockchip's TPL, but that's optional, not the default. DDR training code is here:
> Postmarket or Lineage or any other mobile operating system will be able to make use of this project.
Any OS "is able" to use anything from any other OS - in theory and given infinite resources. In practice though, it makes a huge difference when something works by default.
That doesn't make sense to me, extracting/copying a firmware blob is not clean-room design. It would only be clean-room design, as the article you link to explains, if you constructed it yourself from scratch based on the functionality you understand it should have. But ok!
You might have gotten lost on the steps involved in clean-room reverse engineering here?
>extracting/copying a firmware blob is not clean-room design
It's stage 1. Clean-room reverse engineering is about working with the nature of copyright, and classically goes roughly like this:
1. You set things up with a "contaminated" or "dirty" side team who have direct exposure to the IP in question, and a "clean" (or "virgin" is another older term) side team that are thoroughly firewalled. The clean side must only have devs who have never ever had any exposure to whatever it is you're trying to clean replicate [0].
2. The dirty side is in charge of producing a "fact sheet"/spec. That side absolutely extracts/disassembles or whatever else to get at the target, which is precisely what "contaminates" them. They are looking at copyrighted code. Then they use that research to a create a purely factual spec, which is then passed across the firewall to the clean side. This must be the only communication.
3. The clean side then uses that to write new code themselves that will handle state per the factual spec they've been given.
The reason it works is that (in the US) purely factual information cannot be copyrighted, there's no "sweat of the brow" doctrine or the like. Copyright, unlike patents, does not cover ideas or methods, it's about the creativity of the person in question. You can't copyright the mathematics of a function, of "when X input is received Y is output", or of general concepts. So if two (or more) people independently create works that happen to cover the exact same subject matter, but can prove they were fully independent, then it doesn't matter even if it happened to be literally identical (however improbable that would be). Each would have their own independent copyright on it.
So clean-room RE avoids all the legal snarls around "how close is this" in favor of the simple binary question of "did the team that wrote this RE'd code have any exposure whatsoever to copyrighted IP?" If the answer to that is "no" that's the end of any legal complaint, because by definition their output cannot be a derivative work. Software patents short circuit that, part of the many reasons they're evil, but as a practical matter the number of really fundamental hard to avoid ones is rapidly shrinking because it's 2025 and by 2005 a lot of the foundations had long since been done.
----
0: Which is not necessarily trivial to hire for, because the kind of person who has the kind of skills you need also is going to tend to enjoy hacking around and reverse engineering stuff for fun anyway increasing the chance they've managed to contaminate themselves.
Such as when it's technically legal to do something as long as you do it a certain way, but the interested parties may not believe that you did it correctly and will bury you in legal discovery requests that financially ruin you or force you to stop.
Or they sue anyways hoping for a favorable ruling that changes the interpretation of the law (Oracle v. Google for a famous example of this)
>At this point why not just bite the bullet and go back to the old days of php serving html.
Going back to it is the point. HTMX lets you do that while still having that button refresh just a part of the page, instead of reloading the whole page.
It's AJAX with a syntax that frees you from JS and manual DOM manipulation.
I fairly recently developed an app in PHP, in the classic style, without frameworks.
It provided me with stuff I remembered, the $annoyance $of $variable $prefixes, the wonky syntax, and a type system that makes JS look amazing -- but it still didn't make me scream in pain and confusion like React. Getting the app done was way quicker than if any JS framework was involved.
Having two separate but tightly integrated apps is annoying. HTMX or any other classic web-dev approaches like PHP and Django make you have one app, the backend. The frontend is the result of executing the backend.
I use a Nokia N95. It works well as a phone, and does have some smartphone features. I can listen to podcasts on it, and Google Maps somehow still works fine.
photo-editing software will never be mainstream. I expect a person that works with media to be capable of picking the right download.
reply