megous

Flyby https://x.com/FlyingBeagle_/status/2116029654356336781

Google doesn't show reality in the north either. It's completely destroyed there too, in the same manner as in Rafah. East Gaza City is also leveled completely.

And it's not like they don't have the data. You can see in Google Earth "archive" how the whole map is a patchwork of randomly old tiles.

I actually don't mind people who think AI can't write code. :) Less demand the better.

But personally I know AI can write absolutely insanely complex things in very short amount of time, that just work and work well. I'm running things I would not dream of just 1 year ago, like advanced ISP pipelines on (formerly) high end Kintex K480T based FPGA accelerators pretty much fully written by AI, from the RTL, to all the testbenches, algorithm research, calibration tooling, etc. etc. And that's just one weekend project.

Allright, I removed stray anubis install I had on my vps, after running this.

Fully deserved. I hate these spammers.

There's no escaping the fact that EU fucked the hobbyists that previously were able to ship stuff not even made or available in EU at sane prices from china. I f I were to buy things I did in last 12 or so years based on current rules, I'd pay like 200% on customs/taxes and bullshit charges like 3+EUR per made up category on invoice or whatever it's now.

Hopefully, it will put a downwards price pressure on middlemen/resellers, now that buying directly is prohibitively expensive.

Yeah, sure. By magic I guess. :)

?

Why would you need to be elite? That's your own assumption.

There are two conditions for compromise. You're in the position where you have opportunity/access. You are willing to do what's asked.

MITM only works if you allow trust in corporate CA on the outbound HTTPS connections. And why would you?

You're sending your knock over the public network in the clear. It's observable by anything in the path. And then you're not the only one that can find the keyhole.

Naive. There's not much that prevents you from running ssh over https. Not even traffic patterns will give you up in the age of ubiquitous websockets and/or http2 streams.

Smartphones are everywhere, and Israeli spyware is well known, some companies producing it are even banned in US. Not in EU though, for whatever reason. (one probably being, some governments are/were using it against opponents, like in Poland, Hungary or Greece)

They likely mean manipulated equipment for purposes of spying. It follows from the context further in the article when he's talking about Gaza.

Ever wondered how much Israel uses their 8200 alumni it has embedded in all major tech corporations? Maybe this is part of it. Embedding backdoors, and plausibly deniable bugs, or giving access directly, exfiltrating data, whatever.

Optionally. And passkeys attestation only covers the HW key for example, not the OS running the website or the website. You're still completely free to re-implement it your way + FIDO2 is a standard, so eg. if you want to write your own native app for the bank web API, or whatever else, you can and passkey attestation will not stop you.

Android app/os attestation on the other side is a complete lockdown that prevents you from creating your own apps on top of server side apis the original mobile apps use.

Well, dog and baby owners are great targets for advertising, so this makes sense.

You can do the same with LLM. Have one session document something, and other session write up an implementation, with nothing but docs shared in between.

JS webapps have one key feature in this respect, there's no possibility for banks to force particular OS/HW on you via attestation.

Not all UAF are explotiable. It really depends on what code that uses the stale pointer does with it and how controllable the freed/re-used data are. Although when evaluating I'd count much more on the first condition, rather than the second one, which may not be so easy to ascertain.

Logic would indicate that if it didn't happen, it would not be normal if it did now.

Looks like archlinux already did. After update my fake st*pe.com cert no longer verifies. Ufff.

Well, so what now? It's not like I have these in my system CA store, they're just intermediaries cross-signed by sectigo.

Never happened.

There's no single point to war. It can be anything from enjoying the destruction and killing and torture and lack of rules, to "retribution" (for people who are into thinking of other people in terms of arbitrarily and vaguely defined groups), though creating chaos to get political advantage, to distraction from political issues, or really whatever...

I see /dev/input/event# files as usual. I don't think the kernel ever created events/ subdir by itself. Might be your udev configuration issue.

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."

https://avalon.law.yale.edu/imt/judnazi.asp

That's what IRGC is suggesting. Article authors cite some organization that tells you how to interpret this suggestion.

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.

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.

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.

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

It was fixed in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

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..