pornel

I've successfully emulated remotes with ESPHome + xiao seeed + basic IR diode. Dozen lines of YAML can turn it into a thermostat in Home Assistant.

Flipper Zero can record IR remotes.

RAM needed for keeping KV cache around may be the more expensive factor.

IANAMLE, but there is "grokking" that makes models learn to actually generalize, even after you give them enough parameters that would let them memorize the dataset:

https://en.wikipedia.org/wiki/Grokking_(machine_learning)

High-dimensional gradient descent behaves very differently than the simplified 3d visualisations we use to demonstrate it, and has lots of ways out of local minima:

https://www.youtube.com/watch?v=NrO20Jb-hy0

so it seems like there is a benefit to giving models more space to learn in rather than forcing them to compress the knowledge from the start.

And it's not even a matter of supporting a build system. Each build script for each build system is its own snowflake with its own custom method of finding or building its dependencies, its own method of configuring optional features, etc.

Sorting that out and unifying it for every project is basically the tedious job that Linux distros do.

It's just a marketing stunt. They've got the ad for Claude-powered code rewrites, and that worked beautifully. Everyone got the message: spend big bucks with Anthropic to get rid of whatever codebase bugs you - please, think of the IPO!

If it was about Claude Code itself, they could have rewritten it. They keep saying they don't even write code any more, so it shouldn't even matter what language it's in.

Chromium is 17-20 (excluding some features they think are footguns) and even has its own MiraclePtr.

There's no True Scotsman C++. All C++ codebases would be perfectly safe, except the ones that people actually wrote.

Note that Rust has been created after C++ already had smart pointers. Rust treated "modern" C++ as safety failure to be replaced, not as an unrealized competitor. This is still a problem with the C++ WG today: their most ambitious safety ceiling is aiming below Rust's floor.

Heck yes!

I don't get why USA wants to keep losing money on sustaining failed uncompetitive zombie companies. The companies that decided to lose long term competence for short-term gains need to go bankrupt (you've had EV-1, but decided to drill, baby, drill). The greedy shareholders that rewarded destructive value extraction need to lose money, instead of getting a soft exit at taxpayers' expense.

If you want to give a subsidy, give it to something that will modernize and expand manufacturing, not to prolong death of companies whose entire R&D strategy is inventing new subscriptions for old car components.

The problem is that the LG company went full-spyware. It's not a mere risk, they turned hostile on their customers.

I think legislation could quite sensibly require OSes and browsers to have easy to enable well-integrated parental controls (which mostly already exists). Browsers could voluntarily send "I'm a child" flag, if you want to make it every website's problem.

But the current legislation is stupid. Treating toddlers like hackers, and forcing every website to deanonymize users. It is so backwards, that it's hard to believe it's not done on purpose as the first step to ban anonymity and strictly control all online access. In the UK of course they're already talking about having a VPN ban, because the hacker toddlers are learning how to mask their IP addresses.

But that's the thing - people can live with the contradictions. You can find people at a gas station who will totally agree that air pollution and CO2 emissions are killing people, but still fill up the tank.

I get that it makes less efficient resistive heating more economical, but the tank size seems like a red herring. If you go for a heat pump you can have a larger tank anyway, and heat it during the solar peak too. A larger tank will allow you to store water at a lower temperature (instead of hotter water to be diluted). Smaller delta makes heat pump more efficient and heat loss slower.

I don't remember the details of Symbian any more, other than it was some ancient fork of C++ and clunky cooperative multitasking.

Nothing by Alex Karp is aligned with any users. This guy is a mercenary, and he seems to be in this job for the love of killing.

And prove you're not a child by handing over your ID or selfie to a company that Values Your Privacy according to their price list.

Microsoft will snitch your Windows install GUID when you connect through a VPN.

If you make your connection too anonymous, Google's recaptcha will not let your through until you use your mobile phone to prove your humanity, which knows your phone number (which in many countries can't be obtained anonymously, you burner-phone terrorist).

billed for buying unit-hours from an operator... that's very carefully worded to make it sound like a corporation<>customer relationship and not socialism.

Use cargo tree to understand Rust/Cargo deps.

The lock format is a multi-line TOML, with a varying number of lines per dep due to redundantly listing deps-of-deps, so a naive line count massively overstates the number.

Cargo.lock contains many unused dependencies, because it's a superset of all combinations of all optional/disabled features of all transitive deps across all possible platforms (so that the deps don't reshuffle even if you enable/disable feature flags or compile on another platform). But that means Cargo.lock is going to have 3 async runtimes even if you use one. It's going to have syscall definitions for RedoxOS and wrappers for WASM, because some dep of dep is compatible with those platforms. But these deps won't even be downloaded if you don't build for these platforms.

The number you got presented is not representing the unit you're insinuating. A crate in Rust is a compilation unit. It's common for projects to ship as a collection of many crates. It's a smaller unit than what C counts as one dependency, and slightly coarser than an .o file. I don't see people freaking out by how many .o files their projects have, including all transitive ones from deps like openssl or curl.

They don't want all Americans to reproduce. Making a law they want still needs a couple of Supreme Court decisions overturned.

I suspect we'll move away from pull requests, because in the LLM world they're the worst way of accepting a contribution.

Verbose slop is painful to review, and it's dangerous to accept unreviewed code from a stranger.

For a maintainer it's way easier to tell their own agent to reimplement the same idea. It's still slop, but done their way, under their supervision.

For popular projects agent-made pull requests become a DoS attack. I wouldn't be surprised if projects start refusing to accept unsolicited PRs and switch to "don't call us, we'll call you". You could have an agent scanning forks of your projects to find what bugs users are fixing and what features they're adding, and use it as a roadmap, without the pressure of accepting any particular commit as-is.

I'd also like to move away from a binary merged-not-merged divide. Projects may have a stable manually-reviewed core that should be protected from agents messing it up, while allowing the sloppy parts to churn however LLMs like it.

I've watched an interview with Andrew Kelley: https://youtu.be/iqddnwKF8HQ where he seemed much more chill and level-headed.

Now you have to take your eyes off the road and look through three screens to find a new icon that showed up somewhere. Then keep not looking at the road and tap though multiple layers of settings screens to dismiss the false positive.

Car makers are chronically awful at making software, and regulations that force them to write more such software are doomed to suck.

I'm certainly distracted by all the beeping and bonging the car makes.

Everything you can capture with Flipper has off-the-shelf cheap simple components you can find in your DIY electronics/maker store: IR leds, 433Mhz antennas. Seeed xiao is also small enough that you can stuff it and a relay into appliances and simulate button presses.

I use it to clone remotes of "dumb" devices and emulate them with ESPHome to make them "smart" fully offline under my control.

LLM agents have plenty of "bad habits" that are impossible to get rid of. I suspect they're a side effect of reinforcement learning. Training objective rewards fewer tokens, so the results just need to be good enough most of the time while cutting as many corners as possible.

Similarly, I'm trying to stop agents "gracefully" handling errors by stuffing results with empty junk and continuing (get_list_of_problems().unwrap_or_default() -> "no problems found!"). I've filled AGENTS.md with "fail closed", "extremely strict error handling", "no fallbacks", "don't use sentinel values", and hundreds of variations of these, but they work about as well as "do not hallucinate". I get "You're absolutely right, this will cause problems!" and the fix is "changed to Err(_) => String::new()", I suspect it's another case of gaming RL - failing early and loudly increases the chance of failing and being penalized. So fudging data, ignoring errors, and presenting a barely-working result is a better strategy overall. When it fails, it fails anyway, but as long as it stumbles to the finish line it has a non-zero chance of getting accepted by the RL judge.

Apple used to know this. They've had animations after items were dismissed, but avoided animations before showing an item.

Old Apple understood design is more than making things pretty. The glassy Apple is all about how it looks in a demo.

> But you can just use very similar structures yourself in C programs! You can prevent problems in C as well by construction, even when the compiler does not enforce it.

Enforcement is the point. Otherwise you're just saying people should be writing bug-free programs. "By construction" doesn't mean it's possible to construct a program satisfying a requirement, but that the compiler ensures it's impossible to violate it.

Even for a hypothetical perfectly diligent flawlessly executing programmer it's a time saver. If you want to run a 3rd party function across threads: in Rust, the compiler tells you if it's thread-safe or not, tracing through all dependencies, callbacks, checking data structures, mutexes, ref counts, etc.

And it works the other way, if I change a function that used to be thread-safe to do something unsynchronised, it won't compile any more in users' multi-threaded programs, instead of silently screwing them. Their code may have been perfectly correct before the change, and I couldn't feasibly track down everyone using my function before making a change, but having invariants in the type system automates this checking and communication.

> Just look at some of the bugs found in Rust, it is just the same old nonsense as everywhere

You're comparing your perfect self who writes flawless C on the first try with some random guy's library.

Properly designed Rust written by flawless Rust programmers is also bug-free.

Language safety is a human problem (exists to catch mistakes), and it's hard to sensibly argue whether your imaginary average C programmer is better than mine.

Rust's claims aren't absolute, so aren't disproven by a single counter-example (https://infosec.exchange/@littlealex/116838684458539473)

It's better to look at broader data, e.g. https://github.com/rust-fuzz/trophy-case - look how much lower typical severity is there.

And you can look at data from Google where they track drop in defect density in Android as it gets rewritten in Rust. I know all these top engineering companies just aren't as flawless as you are, and that's okay, Rust is for the rest of us.

Thinking that C's lax null handling is fine because it traps misses the entire angle of preventing problems by construction, making invalid states unrepresentable.

Having a program potentially crash is very weak compared to eliminating the crashing code path entirely, guaranteed statically. This matters more and more as the programs grow, because series of 99% correct components will take correctness towards zero (failure probability mulitplies), while 100% correct scales.

Non-nullable types not groundbreaking. I'm just using this example, because it's basic enough that C has a relatable counterpart. Although some values are truly optional and Rust still has to deal with those, having &/&mut references that are never-ever NULL (and never dangling, never uninit, never misaligned, never unexpectedly mutated) makes this problem go away for all the code paths using them (which is the majority in practice).

But C completely lacks the real good stuff in Rust, like Send/Sync. You can shake some bugs with tsan, and have a static analyzer try to figure out effects and propagate them across functions, but like all analysis in C, it's hampered by lack of explicit info in the code (heuristics causing false positives), difficulty of performing true whole-program analysis, and dynamic code being a dead-end (unlike Rust where the traits are part of function types). Until you try it, you won't know how awesome it is to write thousands of lines of pervasively multi-threaded code, and have it work on the first try, without a single UAF or data race (and before you say what about deadlocks and higher-level logical races - there are library building blocks which usually prevent these too).

> people think C is much worse than it is because they do not understand what can be achieved.

I've been writing for ~25 years, from microcontrollers to compilers. Rust for 11. I think I have very good understanding of what is possible. C is stuck in 1970s. Rust at least advanced us to 1990's :)

I think it's much more common for people to not grasp how far Rust is ahead, and think it's merely a slight refinement of "be careful, use tooling" approach in C, rather than a shift towards a level correctness never seen in C.

Depends how you define "can", because you can invent your own conventions not checked by the compiler, or even make a compile-to-C language.

But more directly, C barely lets you define non-NULL pointers. It doesn't have pointers that guarantee the data behind them is initialized, it doesn't have never-leaves-this-thread data types. Const merely guarantees that you can't (strongly shouldn't) mutate data, not that it definitely won't be mutated by any thread.

It's not switching costs, but trust.

There's no congress. There's no policy (they've been making noises about not allowing AI regulation and now they're not-regulating it like a child paying with an on/off switch). The law is whatever Dear Leader's mood is today. It overrides any contract you sign with private companies, and they roll over and take it, because that's how oligarchies work.

Technically, absolutely.

Whether it would suit you, depends if you can learn to like Rust's approach of moving more work to the type system. In Rust you do certain things the Rust's way, period. Programmers used to C being unopinionated about everything find that objectionable.