pja

From his showreel, it seems Erik also created the animation of the final moments of the Cassini mission to Saturn: https://www.youtube.com/watch?v=xrGAQCq9BMU

Showreel: https://erikwernquist.com/showreel

Yes, I should have caveated that: 128kbit mp3 from a decent encoder is transparent to average listeners.

To a “trained” ear that is listening out for the differences? Sure, those are perceptible. But those aren’t normal people.

That’s just the nomnomml demo website - the text is editable so that you can see live updates in the rendered UML diagram.

The underlying js library will render straight to an HTML canvas or to SVG from a Node.js program. You can run it from the command line if you want to.

Sure - these codecs lose information. The clue is in the name!

The question is can you hear those differences, to which the answer is basically no, for a modern codec at high enough bitrate. "enough" is 128kbit or more in blind listening tests.

Are we talking mp3 or other codecs here? mp3 has a a couple of encoding ”tells” that a trained listener can pick up on (although it gets increasingly hard to do so beyond 128kbit IIRC). Other codecs don’t even have those & at higher bitrates people can’t pick them out in blind listening tests.

Please do watch & internally digest the explanatory videos at https://xiph.org/video/

It explains why you’re wrong in easily digestible terms & how a 44kHz sample rate will accurately encode signals right up to the Nyquist limit. The second video is an end to end demo showing the process in action.

One of these requires having the spa challenge authentication method active, which concerns NTLM passwords. I’m going to guess that approximately zero currently running exim mailservers are using this authentication method. It’s not even mentioned in the default Debian configuration files.

Another is a stack overflow, which will hopefully be caught be the stack-protector hardening on Debian/Ubuntu.

Which leaves the worst of them - the buffer overflow :(

Add

    # Disable Power LED after boot
    dtparam=pwr_led_activelow=off
    # Disable SD card activity led
    dtparam=act_led_trigger=none
    dtparam=act_led_activelow=off
    # Disable the ethernet LEDs - these are Pi4 specific values.
    # Look in the docs for the values for other Pi boards.
    dtparam=eth_led0=4
    dtparam=eth_led1=4

to /boot/config.txt

It’s really important for industrial users & RPi has put a lot of focus on their commercial customers for some time now.

It’s a typo: They mean 5A I think.

Jeff Geerling measured 1.8W idle power draw.

Based on my experience with previous Pis, I bet you’ll be able to drop that even further by turning off unused board components at boot time.

That'll be peak power draw though: you have to spec the standard power supply to cope with the CPU running @ 100% & simultaneously feeding the 1G ethernet and all the USB ports at max power.

Jeff Geerling measured 11W peak board power running benchmarks. Idle power was measured at 1.8W.

They claim it will draw less power than the Pi4 for the same workloads.

Absolutely rock solid for me.

Have you tried running it with a freshly created profile?

Having spelunked through some Google announcements on this, it looks like they planned to do so back when Android 11 was in development (https://android-developers.googleblog.com/2020/02/Android-11... ), but I can’t find any evidence that image decoders are included in the current Android Mainline system updates that ship via Google Play - video codecs are, but not image ones apparently.

The image decoders are in android.graphics (https://developer.android.com/reference/android/graphics/pac... ) & that API subset is not listed in the Android Mainline system modules that are catalogued here: https://source.android.com/docs/core/ota/modular-system

It looks as if they planned to include image decoders, but that was dropped sometime during the Android 11 development cycle, unless I’ve missed something (which is certainly possible).

Edit: the final dev release announcement for Android 11 keeps the same paragraph about the native image decoder. So maybe it is there & I’m just not finding it? https://android-developers.googleblog.com/2020/09/android11-...

Canonical’s job application process is famously insane, so I wouldn’t personally put too much weight on anything in this blogpost.

https://android-developers.googleblog.com/2020/02/Android-11... says:

“Native image decoder - New NDK APIs let apps decode and encode images (such as JPEG, PNG, WebP) from native code for graphics or post processing, while retaining a smaller APK size since you don’t need to bundle an external library. The native decoder also takes advantage of Android’s process for ongoing platform security updates. See the NDK sample code for examples.”

However, poking about in the Android mainline module docs I can find no evidence that the image decoder libraries are included in the system updates that get pushed through Google Play. I’ve unpacked the obvious modules & found the video codecs, but no sign whatsoever of the image decoder libraries,

It would be helpful to be able to tell whether a given phone has received such an update, especially in the case of 0-click exploits like this one! Are all Android 11+ phones guaranteed to receive it? (it would seem so, if this is a core security component) Is there anyway to tell whether you’ve received it? This aspect of Android updates seems to be entirely opaque to the end user - updates get pushed through Google Play services & that’s it.

After some investigation, I found https://support.google.com/product-documentation/answer/1141...

which gives some details of Android system updates pushed through Google Play. This changelog does not list CVEs or specific bugfixes, so it’s impossible to tell which bugs have been closed via this route, but it is at least slightly better than nothing at all.

It is possible to map those updates to actual CVEs mentioned in the AOSP sources via a circuitous route involving adb & running a bunch of commands on your phone, according to this blog post: https://www.esper.io/blog/building-a-google-play-system-upda...

Looking at the current AOSP wepb sources, no module tags have been attached to the current release, so it doesn’t look like it’s been pushed out yet, if it’s possible for Google to do so at all outside the monthly security updates for in-support phones.

It seems that GrapheneOS is making releases for Pixel phones, including the 4a which include patches for the webp exploit: https://grapheneos.org/releases#2023091800

Yes, and Google should be supporting these old devices as far as possible.

Not doing so is a disservice to their customers frankly.

No, I’m saying it’s extremely frustrating that Google just drops security support entirely for devices like this, when they could continue to at least patch egregious platform bugs like this one, even if they can’t fix everything.

It’s just icing on the proverbial cake that a month after they drop security support for the 4a a 0-click remote exploit is found.

So there’s a webp system library as well as the one in Chrome?

Nice of Google to drop security support for the Pixel 4a just before this bug drops.

So if your Android device is out of support, there’s now a 0-click exploit floating about in the wild?

Or will updating the SMS App, Chrome, WhatsApp, Signal etc be sufficient to cover all the likely input routes?

London has one of the best public transport networks in Europe.

Because this post has fallen off the front page, so almost no one is reading it to downvote nonsense like this.

Google fails pedestrians for the same reason it fails cyclists - it’s off road data is terrible & it’s not interested in fixing it.

In large cities, the roads are the only routes, so pedestrians can go OK with GMaps. Anywhere else & Google is prone to send you waltzing down a main road instead of the paths marked for actual pedestrian use in my experience. Same for cycling.

Thanks for trying, at least: You weren’t able to shift leviathan, but there’s no shame in that.

Google maps is still terrible for pedestrian / cycling use.

OSM is much, much better but I guess Google refuses to pull OSM data because it would require them to open up their own maps.

It’s M.2 2242 Gen3 PCIe NVMe, 512Gb in the base spec, configurable up to 2Tb, but presumably end user replaceable.

https://starlabs.systems/pages/starlite-specification

If you’re going to use C# for a compiler, why not go the whole hog & use F#?

The vast.ai FAQ claims they take 25% of the hourly rate: https://vast.ai/faq#Hosting-General

23andme looks for specific single nucleotide polymorphisms (SNPs) so it’s completely unsuitable for looking for this kind of DNA alteration that could be anywhere in the genome.

That is a fantastically weird temp / resistance chart.

Would semi-conductor like properties result in something like this - thermal noise pushing electrons into the band gap?