If you have the power to start a war, and you did start and aggressive war against other state, I'd say it's quite a stretch to be called a civilian. You're the one that deserves being taken down the most, as aggression is the highest crime, from which all other crimes follow.
"To initiate a war of aggression, therefore, is not only an international crime; it is the supreme international crime differing only from other war crimes in that it contains within itself the accumulated evil of the whole."
All we can say is that allegedly a projectile hit a ship according to the article.
Article title is typical manipulation. "Something happened" as "something else also is happening". :) Very common technique. News website skimmers will conflate the two. Nobody who read the title will go back after 1-3 months to ask what was learned since about what happened, and that will be it.
News websites commonly use this for pumping up xenophobia against immigrants, too, where I live.
A more mundane and common use of this technique is for reading the displays of weighing scales, digital micrometers, and similar instruments which did not originally have the feature to enable computer connectivity.
In my teens, I built a digital serial interface for a scale company my uncle was a salesperson for, think highway and landfill truck scales. This is how I built it, very straightforward to your point, mitm from the scale to the display.
Analogue hole is how I did a more efficient smart garage door hack than what people were talking about here at the time. Soldered zigbee switch into the physical button; worked great :D
I had a similar idea to bypass DRM for a while. Some kind of board that goes between the display panel driver and whatever sends it the signal, and outputs something you can capture, e.g. DVI or unencrypted HDMI. Not sure how practical it is.
In the past (circa a few years ago) the connection between the main board for a display and the glass driver board would be a ribbon cable, LVDS signalling. Very straightforward and typically not soldered. There'd be a ribbon cable connector. So yeah, you could just put a board between easily. And there are LVDS to H264/H265 chips already.
But as the other comment points out, older HDCP is broken wide open so ... easier to just use that. Plenty HDCP strippers on the market.
So much Pine64-bashing and quite a lot of factual errors.
There were several pinephone HW revisions that fixed HW issues based on direct developer feedback. Yeah, there was no direct communication with HW engineers, but at least the critically important feedback was applied (otherwise modem would not be able to wake up Pinephone SoC from sleep and Alt-D over USB-C would not work at all, and probably bunch of other things I barely remember). I or someone else in #pinedev could tell TL Lim, and if change was reasonable it would be made. There was quite lively discussion around HW issues in #pinedev early on. And company did not seem to lack effort, eg. for Pinephone keyboard there were like 5 revisions, including doing an X-Ray analysis of burned down keyboard MCU and subsequent citcuit improvement. So communication to get HW changes was possible, and was usually via TL Lim, not via HW devs.
"The volunteers working on the PinePhone's kernel generally didn't [upstream]" is factually completely wrong.
PinePhone DT was mainlined for Linux 5.7 by me. smaeul rewrote the sun8i-codec driver and did lot of stability and other work, anarsoul upstreamed Bluetooth and maintained Lima, and many many many more small upstream contributions by different people (git log is your friend), just on the kernel side. People created entire new upstream projects like Crust and p-boot and levinboot, etc.
Yes, there's some long residual stack of patches, but so what? Accurate statement is that some perhaps critical work stayed out-of-tree, partly by choice and partly due to upstream rejections or dependencies, and not that "the volunteers generally didn't upstream." The claim is overstated to the point of being misleading.
And another thing is that even if there was lack of upstreaming, almost no Anroid phone is fully upstream in Linux and it doesn't prevent it from gaining marketshare. Downstream kernels suffice for it.
Latest version of supported downstream kernel for pinephones with good HW support has been available for years. Almost no Android phone can even claim that for their downstream kernel.
Then there's over-estimation in the article of how upstreaming to kernel is important. You can easily say that having full HW support quickly in some downstream kernel is kinda preferable, because it allowed people to actually use the phone sooner, and allowed userspace development to progress. If every change would have to go to upstream, with its long iteration times, etc., people would not be able to use the phone at all for 4 years or so. How many would even stay around? :) I ceratinly prefered making the HW work and work well, over upstreaming. I understand upstream kernel is a distro maintainer wish. People are free to have wishes. :D
Pushing upstream changes coordination of work and to some extent simplifies maintenance for some, while making it way harder for others in the community.
The article says PPP "still had major software problems when its sales were cancelled in August 2025.". Yeah, no. Pinephone Pro has almost full kernel support, multiple bootloaders, even graphics/touch support for U-Boot, etc. There are no SW kernel issues that I'm aware off that were not solved years ago. Yes, again, you need a downstream kernel, but it's been maintained for every release for years since the beginning, just like PP. It's very similar situation to Raspberry Pi, which also sucks without downstream kernel, but did not prevent it from reaching marketshare, or whatever. Commercial cancellation is more lack of interest/commercial viability, rather than anything pointing to lack of SW support.
The article opens by promising to "examine what held back mobile Linux." Well, it consistently assigns blame to companies/vendors while treating the enormous volunteer engineering as background and blameless. Well it's not.
As for the company: Pine64 promissed 10 years of original Pinephone. It's so far delivering what? 8th year? At the same/similar pricing to 8 years ago, across all that happened in the HW industry in the meantime? Covid? Ramocalypse? I'd call that a massive success on promissed claim. The company also never promissed fully working OS/HW android experience. It promissed cheap accessible long-term stable HW product to jumpstart the ecosystem (paraphrasing from memory). And I thoroughly enjoyed developing and supporting Pinephone on the kernel side for 8 years release after release, building well designed (as far as UX goes) bootloaders, and interacting with TL Lim and wider community, etc.
"Once the best volunteers abandoned PINE64, the company hasn’t been able to complete the development of the PinePhone Pro, PineNote, PineTab2 and many of its other projects, so the people who ordered these devices are unlikely to ever be able to use them as fully functional devices."
Sooo. what HW support is lacking on Pinephone, Pinephone Pro or PineTab2 or Pinebook Pro, or other consumer products, if you take some downstream maintained kernel and use it? You'll find that very little of consequence is missing. I know of one: HW accelerated video encoding on original Pinephone. The only claim I see other than performance, is lack of "HW accelerated video encoding". But who would want to record videos with webcam level sensor that uses CAF for auto-focus? Has anyone even tried to imagine what it means practically when you get CAF full range sweep in the middle of the vide? :)
Performance is not really relevant to "level of SW support".
You can also say that perhaps people drifted off after the work was mostly done, because there was nothing more exiting to do, other than absolutely unsatisfying gruntwork that even paid engineers at most android shops don't bother to do.
"but instead PINE64 dismissed the screen flicker" is also incorrect, IIRC. I remember suggesting removal of some resistor to avoid leakage of power into PL port power rail, that caused variation in backlight PWM control voltage, since PL rail served as a voltage reference for backlight PWM. And it was resolved.
Hi Megous, I'm the author of the article. Before we get started here, just let me say from the outset, thank you for all your hard work on the PINE64 hardware.
I will correct the things that I got wrong in the article, if I can verify my errors.
I have the PinePhone 1.2b (Beta Convergence Package), that was shipped to me on April 5, 2021. It is currently running Mobian Weekly with kernel 6.18.32.1, which I downloaded about three weeks ago.
I see the flicker on my PinePhone's screen. I usually see it for a minute or two after I turn on the phone or resume from a suspend, but I sometimes see it at other times. I see the flicker both when the screen brightness is set to a minimum or to a maximum. I have seen this problem the whole time I have owned the PinePhone.
I assumed it was caused by this issue: https://wiki.pine64.org/wiki/PinePhone_v1.2#Backlight
However, rereading it, my case doesn't fit, because the screen flicker exists at both minimum and maximum brightness. Can you explain this?
Maybe my screen flicker problem is special, but was the problem listed on the wiki ("When backlight brightness is very low and the CTP controller actively communicates on the I2C bus the backlight blinks heavily.") ever resolved by PINE64?
There are several possible causes of screen flicker.
One cause of screen flicker is if display is not properly turned off and driver does not wait the required 120ms after turning it off before cutting the power to it. Then on the next display power on, it may very visibly flicker for extended period of time, depending on time between last power off and next power on of the display. I believe mainline kernel driver does not wait. This was my bane when I worked on p-boot bootloader. :-D
Things in mainline get regularly broken by unrelated work, so maybe this got broken by the unrelated kernel change in 2024 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... that caused the clock that feeds the timing controller for the panel to not be able to set required 432 MHz to achieve the specified 60 Hz, so if you run mainline kernel change made for Olimex laptop caused Pinephone panel to be driven by 16% faster clock and refresh rate is almost 70Hz, which is out of spec. It can only be fixed by revert, without breaking anything else like eg. convergence functionality. Probably not the source of the flicker, but who knows how borderline panels behave. Eg. the mentioned commit says that pinephone SoC MIPI-PLL is unstable at 432 MHz, yet it does not acknowledge what that driving the panel at 16% faster clock may result into at all, from 16% higher power drain due to every userspace app having to render at 70 Hz, to stutter of video playback or UI stutter in systems that don't derive all timing from the display (eg. if input is read at 60Hz and output is done at 70Hz this can really mess up the UI feel) to behavior on borderline panels.
Panel clocked at higher than expected frequency may not complete the required LCD dicharge process correctly/completely due to compressed time (and this error may accumulate over several power on/off cycles), because it works with different than expected timings to complete a fixed physical process. (partly speculating here - what I know for sure is that this issue that causes flickering accumulates over several power on/off cycles if poweroff is done wrongly)
In any case, for my kernel I prefer 60Hz and underlocked PLL (works on all my 5 pinephones) so I revert that 500 MHz PLL limit in my kernel and run the panel at specified frequency. I don't see any flicker issues on my devices other than during development/hard poweroffs, etc..
"There were several pinephone HW revisions that fixed HW issues based on direct developer feedback... So communication to get HW changes was possible, and was usually via TL Lim, not via HW devs."
That's great, but that wasn't my experience as an ordinary buyer of the PinePhone who wasn't on the special developers list and had no way to communicate with TL Lim. PINE64 provides no way for an ordinary user to register a bug report about the hardware in the PinePhone.
Since PINE64 didn't provide a way for me to register a bug report about it, I listed those errors on the wiki page. Instead of fixing the schematics, every mention of errors in the schematics was deleted from the wiki by user "Kx" on 2023-12-24. My questions on the PINE64 forum about how to get the schematics fixed were never answered. I don't blame PINE64 for the wiki edits, since I assume "Kx" was just someone in the community who didn't like seeing that there were errors in the schematics. However, the fact that PINE64 doesn't have a public bug tracker for its hardware issues is frankly an indication of problems with the way the company was run in my opinion.
"Accurate statement is that some perhaps critical work stayed out-of-tree, partly by choice and partly due to upstream rejections or dependencies, and not that "the volunteers generally didn't upstream." The claim is overstated to the point of being misleading."
I did some web searches and see that there were more commits to mainline Linux than I thought. I will edit that part. However, there was a marked difference between Purism and PINE64 in this respect.
"The article says PPP "still had major software problems when its sales were cancelled in August 2025.". Yeah, no. Pinephone Pro has almost full kernel support, multiple bootloaders, even graphics/touch support for U-Boot, etc. There are no SW kernel issues that I'm aware off that were not solved years ago."
I don't own a PPP, so I was going off what is listed on the PPP PINE64 wiki, which lists:
Bootloader (critical bugs), Stability (WIP), Suspend (Experimental), Updates (WIP), Phone (WIP), MMS (WIP), LCD (WIP), Rear camera (WIP), front camera (WIP), camera flash (critical issues), Bluetooth (WIP), GNSS (WIP), Sensors (WIP), Keyboard add-on (WIP), Qi Wireless (WIP), LoRa (not implemented), Fingerprint reader (not implemented).
Is the wiki wrong? I held off on buying the PPP for years waiting for those issues to be resolved, and I saw little progress on getting those problems solved since many of the high profile volunteers left in 2022.
"As for the company: Pine64 promissed 10 years of original Pinephone."
"Sooo. what HW support is lacking on Pinephone, Pinephone Pro or PineTab2 or Pinebook Pro, or other consumer products, if you take some downstream maintained kernel and use it? You'll find that very little of consequence is missing."
The PineTab2 wiki says that Bluetooth doesn't work, WiFi can't be reset, so device needs to be power cycled. The camera drivers need to be ported, The Rockchip CSI/ISP driver needs to be extended to handle 2 lanes. Suspend does not currently work reliably, so suspend has been disabled.
"Performance is not really relevant to "level of SW support"."
In the case of the A64 in the PinePhone, its GPU for hardware acceleration is pretty weak, and there is no ISP and aDSP, and the VPU's hardware encoder only includes H.264 video, so I don't think SW support was really holding back the performance of the cameras and the speed of the interface. There are other SoC's where proper SW support is a more relevant issue holding back performance.
Purism chose to upstream their changes to mainline Linux, whereas the volunteers working on the PinePhone's kernel generally didn't.
To:
Purism generally chose to upstream its changes to mainline Linux, whereas the volunteers working on the PinePhone's kernel were less consistent about upstreaming their changes.
I also added a postscript note at the bottom of the article thanking you for pointing out that you had submitted more upstream to mainline Linux than I thought, and linked back to this conversation.
Yes, the feedback that would tend to get addressed was always related to actual HW issues, and the issues listed in your blog article seem to all be failry superficial without any effect in practice. Eg. eMMC and DRAM is a commodity, various phones batches likely got different components based on what was available. I know for sure that my pinephones have different eMMC chips from different vendors that have different real speeds, so got to 78 MiB/s at DDR52 some just to 50-60 MiB/s, etc. DRAM will probably be a similar case just based on the fact that some phones got 2GiB and some 3GiB on the same PCB.
"I don't own a PPP"
Yes, wiki is not uptodate. There are several bootloaders available, from levinboot https://xnux.eu/log/103.html to u-boot with display support and graphical menu, there are small tools like rk2aw that fix the HW issue with charging from discharged battery (bootloaders fix it too to some extent), etc. Suspend is not experimental, never really was. It was working from the beginning, because it was implemented by Rockchip for google RK3399 chromebooks or whatever. LCD works. Cameras work and ISP is fully supported since like 1 year after release, and 0 days after release for ISP. Camera flash works, but should not be used for extended period of time, due to overdriving the LED. Dunno what bluetooth issue would be about, it's part of WiFi chip and supported mainline. GNSS fully works just like on Pinephone, since it's the completely identical thing part of EG25-G modem. Sensors fully work. Keyboard add-on is supported mainline, with out of tree policy manager for managing dual battery power if you like. Qi/LoRa are I know nothing about, and are just back-covers unrelated to PPP in particular. Convergence works well, including HDMI audio. Fingerprint reader was a user backcover project, that got some help from Pine 64 IIRC, and would be an insecure toy anyway. There's basically nothing missing on the kernel/low-level side of things that would be a show-stopper for anything I can imagine doing, except for video encoding acceleration. But that's just a lack of upstream consensus how to even create a kernel api for it. It's not really pinephone pro specific issue. There's no lack of upstreaming attempts for this over the years. There will be no encoder drivers upstream for any stateless encoder HW accelerators, until there will be consensus. Downstream kernel can have encoder in a few days if someone wants it.
Pinetab2 wiki is not accurate either. You'd be better off looking at pages of distros you'd like to use that support the device. Support level is always determined by the distro anyway.
As for GPU acceleration. SW support is absolutely key, especially on older GPUs. If you optimize for those you can have very snappy UI for pretty much any imaginable smartphone functionality with imperceptible latency even on original Pinephone with maybe one exception, and that is web browsers. Those are just so bloated these days it's ridiculous.
Normal distros and Android have extremely bloated architecture, so things get slow and heavily dependent on storage load times. I know for sure that original Pinephone GPU is fully capable moving those few UI pixels typical mobile UI has at 60 FPS with barely any dips even at reduced CPU/GPU/DRAM frequency to save power without any sweat. Things need to be done differently though.
Central support status matrix pages are futile for Pine64 devices. You can have perfect kernel/bootloader support and any chosen distro can still be unusable, because of lacking userspace integration. And there are maaany distros. And some pick and choose kernel patches, and fix/break various things. Some distros also disown bootloader support, so whether something will work or break depends on what bootloader user runs, etc. etc.
There's plenty of outdated info everywhere. Users should just ignore anything status related that's apparently old. And that wiki page was last updated 3 years ago or so.
All this "engineering" really is, is basically just reducing CPU use (trading it for doing things on HW accelerators/offloads if present) and lowering the voltage/frequency to what's needed and suspend/resume. There's no special sauce in there.
App can be easily stopped in linux via SIGSTOP/SIGCONT. It will consume 0 power then. :)
Even original Pinephone has all what's needed for efficient use of energy for smartphone use cases.
And if you stop thinking of "apps" as processes and design architecture differently, you can have millisecond scale reactions to all user input on the entire phone even on original pinephone. Apps opening in a blink of an eye right after boot, etc. :)
Linux phones trying to reproduce Android architecture are kinda pointless. What would be the point, when you have the freedom to implement any other architecture, actually suited for the user centered model, where you don't have to ballance the needs of untrusted app providers.
Actually LLMs are creating better compilers than what exists. In 2 weekends I let a LLM write almost fully compliant re-targetable C23 compiler (except for a few C library related things that are worthless for its targets) with state of the art optimization for five 8 and 16-bit fairly different architectures. For PIC16F/18F it's slightly better than XC8. For 8051 it's waaay better at optimization than industry standard Keil C51, and of course sdcc. Dev process found several pretty startling miscompilations that XC8 is prone to. And it's tiny. Codebase is like 0.5 MiB with data file for all ~1100 PIC microcontrollers that normally take gigabytes in XC8 taking 350 KiB.
So it's optimized both on code/data size needed for the compiler, which is like 3 orders of magnitude smaller. It has better coverage of C23, and it produces smaller, faster and more correct code. :)
I really doubt there's anything interesting in there, judging from experience of looking at implementations of mobile banking apps and websites. Horrendous API, some intrusive scanning/probing/fingerprinting code and usually pretty weird ass ad-hoc cryptography protocols + some mechanism to try to lock API use to OS vendor giving a blessing for its use, so usually Google has to say, "ok, you can call API of your bank to access your money" or whatever on every single use of the app. (which is one of their ways to increase moat around their walled OS gardens) Otherwise you're out of luck using a mobile app. Websites don't have this issue, yet. Mozilla doesn't gate my access to bank APIs.
Backend will have some shuffling of data around some ledgers + a lot of ceremony around auditing + shit ton of CRUD mess and arcane connections to other systems/institutions. Probably the nightmare of nightmares codebase, if frontends are any indication. :D
Same with healthcare ime. I'm more on the human services side, but I was reversing their apis since pre llm days when I was a relative novice. Many don't even minify, so you can step thru the frontend src in devtools.
And yes, if frontends are any indication, just seeing tip of the shit-berg
There are some days I just hit a raw debugger in AuthForRealThisTime() under a three-paragraph jsdoc written by bot which is itself under the commented-out Auth() function. So many questions arise, and I can burn hours rabbit-holing the stack
Value of contributing/sharing small tools (< 5-10 thousands lines), that can be written by a LLM in an hour or two is perhaps too little to bother.
But it's still possible and useful to contribute (or to contribute to) complex well tested programs, that are just not reproducible in a weekend by a LLM.
Also organizing projects maybe in a form that makes them easy to reliably customize and extend by a LLM, if that's how the people will interact with open SW development in the future, may also be something useful.
Though I dunno what "complex" will mean in the future, if LLM can at the moment already write state of the art well tested C23 compliant re-targetable C compiler for various 16/8-bit MCUs, along with SW simulators, along with timing exact system verilog IP cores, for 5 different architectures, in two weekends on a cheap $100/mo. plan and it all just works. :) It's going to be hard.
Yeah as someone who has been working on multiple large scale systems projects entirely with agents…there’s not much left that can’t be built given the tokens and time (and patience of course…for now).
"To initiate a war of aggression, therefore, is not only an international crime; it is the supreme international crime differing only from other war crimes in that it contains within itself the accumulated evil of the whole."
https://avalon.law.yale.edu/imt/judnazi.asp
reply