phh

For the context, the vast majority of carriers do RCS with Google's RCS servers (https://github.com/phhusson/rcs-scanner). I'm a bit rusty, but to my knowledge the only exceptions are Jio in India, all Chinese telcos, and some Japenese telcos.

Of course it is relevant privacy-wise (Google still gather a lot of metadata about who speaks to who and when), but that's not even the reason I'm mentioning it.

In the RCS specification, there are three lines on a killer-feature: device attestation. A server can whitelist which devices are allowed to connect to it. And of course Google uses this, allowing only Google-certified devices and Apple devices.

And then, there is actually one RCS client for Google's RCS servers. Because Google Messages doesn't use RCS, it uses a custom protocol based on protobuf. My personal guess is that this protobuf is a 1-to-1 matching with actual RCS, and it's both-way compatible. But still, that means that potentially the Google device-attestation won't work with an RCS client.

Sibling comments say that GrapheneOS plan on implementing it. I think it can reasonably work. TBH I'm expecting that giving a LLM the publicly available information about RCS on microG should give a working "send message" within a day (even when using Google apps rather than microG, it's just that the microG work explains the API). And once RCS work in GrapheneOS' message app, it should be pretty straightforward to port to microG, so yay. However I have to admit I'm not optimist about how long it will keep working. I'd say we are two years away from Google enforcing RKP device integrity for RCS, and uh, good luck passing that.

Of course, I'm hoping that, in the EU, the DMA will break this Google/Apple-only device-attestation, but I'm not aware of anyone pushing that ATM.

Considering child comment, I agree it's not great. That being said, would a bit-hash have worked? How many users are capable of sending bit-perfect images to someone else? I don't expect more than 5% of people to know...

Relatedly, someone found that on a Qwen MoE, increasing the number of experts at the deep layers reduces the number of thinking tokens. So while you mention that the LLM is capable of thinking more if it's thinking less clearly, it looks like it's also capable of thinking less if it's thinking more clearly?

This has been validated on Qwen3.6-35B-A3B and Qwen3.8-Flash-Next, but with the caveat that it was always on quants.

https://github.com/vagrillo/llama.cpp/blob/moe-expansion/ben...

Hum, I don't really know. I was pretty sure it applies to anything connected to the internet even if it's Ethernet-only, but double checked. And reading the EU directive, it looks pretty obvious to me that you're right, it's only for devices with wireless connectivity... (the wireless connectivity doesn't need to be wifi/internet though. like if you have a 433mhz-to-ethernet gateway it still fits).

(Technically it says "which intentionally emits and/or receives radio waves for the purpose of radio communication", I'll let HN crowd determine if Ethernet emits/receive radio waves in an enclosed channel called Ethernet cable)

I definitely love this article and this spirit. I've accumulated a lot of crap/cheap IoT, I'll probably owning them!

Two things:

- to rain on the parade, the European RED directive makes secure upgrades mandatory for anything connected to the internet (I suspect that's why Elgato Key Light Mini has signed firmwares). So OEMs are now required to prevent you from doing that. (EN18031-1). It even requires that network credentials (WiFi SSID/PSK) to be stored on secure storage (idk if you can pass that requirement without secure boot. I would guess Elgato does?). "secure upgrade" is loosely defined as "integrity and authenticity are valid at the time of installation" so this requirement doesn't forbid us from upgrading our hardware, but the most likely implementation of OEMs does.

- When you want to do that on Android smartphones (please do!): I recommend to go through GSI/Treble route: This way you quickly have an OS that boots. There are a lot of things to fix, but it will be mostly userspace stuff, which will be easier for the agent to work with. Agent will be able to decompile OEM's userspace and compare with AOSP's userspace, and implement the differences. (That's compared to the ""legacy"" or LineageOS official method which are more convoluted, including kernel stuff, and getting just to "it boots" can be complicated).

Yes, obfuscation was always a matter of cost: how much money do you need to break the protection? LLM just decreased that amount by a lot.

(Yes ok, RSA4096 is technically a matter of cost, you just need an infinite amount of money)

> "You can just make it type words, what's the risk in that?"

I don't know if it's a useful answer to people saying this kind of stuff, but here are some examples of other attacks arbitrary USB pwn allows.

A USB device can appear as a network adapter and most OS will happily route all your traffic there, so your speaker can know which porn you're looking at!

It can also appear as a DisplayLink dongle, so it can see what's on the screen (it does require those specific drivers installed, and uh yeah, no way in hell it's technically possible on that MCU).

It can also turn it into a mouse jiggler to prevent lock screen (yes it's technically the same thing as your first point, just HID, but different angle).

It can also appear as a USB-storage: You don't trust the cloud, so you're writing those super secret documents to give to your boss on the USB drive you just plugged in? Surprise, you actually sent it to the attacker.

You can do an IR remote without a RTOS, but as soon as you do BLE you realistically need a RTOS. You have timers for keep-alives, connection states, competing interrupts, CPU-"intensive" tasks that can be preempted (for crypto)

I'm sorry to announce this to you, but the last PowerBook was released 21 years ago

I agree with you that it is the very obvious conclusion, but it isn't obvious to everyone. But it could still be relevant to you if you find yourself discussing with someone saying "why do we even spend money making an API, the AI can just control my computer?"

I'm on the side of "clever, fun, but feels useless". But to defend the project, all sensors require a powered central system. It's pretty common for Zigbee to have one repeater per room [1], which is just what is needed for this system.

[1] Because any AC-powered Zigbee device is a repeater, so just a bulb or a plug is enough

Laying out the math (assuming earth is an homogeneous sphere) just in case it's not clear:

F_gravitational = G m1 m2 /r^2

g = G Mass_earth / r_earth^2

Mass_earth = r_earth^2 * g/G

Density_earth = r_earth^2 * g/G / V_earth

Density_earth = 3*g / (4*Pi*G*r_earth)

Prior to Cavendish we already new g and r_earth, just missing G.

TFA says "After 1,000 fast charges, the battery should retain more than 90 percent of its original state of charge, the company said."

I can't really judge whether 1000 charges is a reasonable target for a car, though i think that 1000 fast charges is reasonable. It should probably be able to push to 5000 slow charges and 500 fast charges, which should fit a lot of use-cases.

Well, you stopped hearing about it, not because it stopped being used, but because its support became mainstream for a very long time. Google strongly recommends using zram on all devices, even on devices with a lot of RAM since like Android 10?

Unironically. Every time I asked a LLM to make something faster, they always tried blind code optimisations, rather than measure.

Absoultely.

I'll add to your comment that it isn't a bug of MCP itself. MCP doesn't specify what the LLM sees. It's a bug of the MCP client.

In my toy chatbot, I implement MCP as pseudo-python for the LLM, dropping typing info, and giving the tool infos as abruptly as possible, just a line - function_name(mandatory arg1 name, mandatory arg2 name): Description

(I don't recommend doing that, it's largely obsolete, my point is simply that you feed the LLM whatever you want, MCP doesn't mandate anything. tbh it doesn't even mandate that it feeds into a LLM, hence the MCP CLIs)

An ESP32-C3 Super Mini can be found for below 3$ (cheapest I had was 1.58€). Since the original clock is 3.88$, it can't be that much cheaper.

Since GCC is lacking such an essential optimization, you should consider have one of your junior interviewee contribute this basic optimization mainline.

You can make frequency inertia with solar (even without batteries if you accept running with a constant reserve so with reduced efficiency). Spain showed that there is a learning curve, that's for sure, but their issue was a "simple" oscillation problem that can be fixed by adjusting frequency-follow rate and grid-disconnect rules. It wasn't like a peak of energy consumption or loss of energy production that only a rotating mass could compensate.

80% is catastrophic though. In a classroom of 30 all honest pupils, 6 will get a 0 mark because the software says its AI?

Is there a survey of SoTA of what can be achieved with CSI sensing you would recommend?

What is available on the low level? Are researchers using SDR, or there are common wifi chips that properly report CSI? Do most people feed in CSI of literally every packet, or is it sampled?

I'm curious why they are using actual modems rather than just doing it with VoWifi that merely requires a SIM card reader (pretty much just an UART)

Except I'm guessing they are not selling their equity, they are making debt backed by their equity?

Well you can't really do -600C sand (or anything), so the benefits of sand VS water largely diminished. "just" freezing water already gives you around 300C equivalent of sand (if my napkin is correct).

Also the point of this plant is to exploit the counter-correlation of cheap electricity and cold. Usually there is a bigger correlation between cheap electricity and heat.

Well in FP4

I dream of getting mcp with interoperable micropayments before ads.

> > Tail recursion IME is a bigger foot gun

> This is true for some languages, but not all.

Useless anecdote that tail-recursive can be a foot gun even in Scala.

I did a (screening) job interview at Datadog, they asked for "give the spare change back on that amount of money" exercise (simple variant), "in whichever language you want". I did my implementation in tail-recursive Scala (with the annotation). I ended up trying to explain that tail-recursivity doesn't explode in memory for the rest of the call (and failed)

It depends on espeak-ng which is GPLv3

You can technically run it on a 8086 assuming you can get access to a big enough storage.

More reasonably, you should be able to run the 20B at non-stupidly-slow speed with a 64bit CPU, 8GB RAM, 20GB SSD.

Well if nVidia wasn't late, it would be runnable on nVidia project Digits.