But it's really quite fast compared to more general balance card services like NFC/tap to pay, etc.

If there's a problem with a plan then there's a problem with the plan. If there's a problem with the implementation then there's a problem with the implementation.

But when you bypass that entire process and go roll out a bunch of changes and efforts that you claim will be flawless and dole out no-bid contracts that balloon past their estimates despite ending in complete or near complete failures then that's entirely on the leadership that kicked it off.

There is no transparency here and it's not even possible to point to specific things that went wrong because it's effectively all undocumented and intentionally done outside of the existing systems and rules. And it happens again and again with different projects.

Each time it's the leadership's fault because they chose to step outside the normal processes and accountability leaving us with no way to learn from mistakes made during the exercise beyond "the processes exist for a reason, stop ignoring them".

IMHO the only reason there's not been pushback from the EU already is because so much assistive tech is only possible with wireless connectivity currently. Once privacy conscious assistive tech is viable those crackdowns will probably be on the horizon even if only for the security risk associated with millions of internet connected devices with poor security posture.

Imagine an energy efficient IC for a small multimodal model that can do voice to text, text to speech, question/answer, tool calling, and structured output.

Wire that up to a microcontroller that parses the structured output to constrain the model (rather than giving the model direct hardware access).

Now you have an assistive tech mode for supporting vision impaired users without requiring them to configure an app on their phone, pair devices, etc. And so now the user can just speak to the washing machine to tell it what to do.

And because models are getting better and better at multi-language support, you can rely on a single model to cover a wide range of spoken languages. And therefore you don't need a bunch of variants of this chip for a single product line.

TLDR this gives a path to replace "always online" and "wifi enabled" devices with fully on-device capabilities without being forced to abandon assistive technology support.

Coal is already here but most places worked really hard to move to cleaner sources (oil being one of them) and wind down the existing coal infra.

This is part of the reason why people have been pushing nuclear SMRs (small modular reactors) given they can often be set up in existing coal plants and they just replace the coal part of the plant and reuse the existing turbines, etc since just like coal nuclear is basically a glorified steam boiler.

https://web.archive.org/web/20260310115201/https://www.willi...

Some places may scale up natural gas but unless a regional already has a lot of LNG infrastructure in place, a sudden drop in oil means bringing back coal.

And coal is of course far worse than oil.

Gradual sustained economic pressure will push a move to cleaner alternatives but a sudden shock leaves countries with exactly one option: bring back coal so the lights and heat/AC stay on.

Higher information density is ideal but when people are working in less than ideal conditions (stress, lack of sleep, alarms going off, etc) you need to prioritise information clarity and clarity of actions over raw density.

They have dedicated UX designers who do relatively little code but focus entirely on making the UX as optimal for the traders as possible and one of them was on an episode.

They talked about how most of the normal UX rules for SW go out the window because quants and traders have such different needs than "normal software".

It really won't take hours. You probably read more than that just looking at HN for like 20 minutes.

especially since if you are rebasing you may want to rebase your changes from one branch to another (i.e. move to top of main or from on top of one feature to another).

So instead you can just do git rebase --autosquash -i last-good or just git rebase --autosquash and let it squash it down for you.

switch and restore replaced checkout. history is being developed to replace rebase for most common use cases. maintenance replaces gc. etc.

- https://git-scm.com/docs/gittutorial

- https://git-scm.com/docs/giteveryday

- https://git-scm.com/docs/gitworkflows

- https://git-scm.com/docs/gitfaq

- https://git-scm.com/cheat-sheet

Or if you want to sit down and really learn the nuts and bolts

- https://git-scm.com/book/en/v2

You do your development and use rebase to organise your code into logical commits/patches that can each be reviewed separately. This way when you do your review in github or on the mailing list or whatever you can review each logical change by going through and reviewing the commits separately (which you can do in github by selecting the commit in the dropdown for the review window).

And of course via email based workflows or "stacked patchset" workflows like what tangled provides then you can get deltas between revisions so that you can see what changed in a given commit between rev 1 and rev 2 so that you don't have to re-review the entire patchset/PR, only the stuff that matters (but still broken up into logical changes).

For git. You can run `git maintenance run` or the legacy command `git gc`.

> What's left in terms of meaningful technical barriers, that would prevent this all from being baked into Android instead of requiring Play Services?

Well now I think the last major barrier is cleared (which was E2EE being nonstandard). Currently the on-device infra is very google-oriented but there is support for non-google-jibe RCS but it still requires google, etc to explicitly opt-in apps to get access to the APIs on device.

A big part of this IMHO is google refusing to give up their moat but they may finally get it into AOSP at some point.

If they don't at this point I think the only way it'll happen is if the EU forces their hand (which they hopefully will do).

They did this quietly in the background and most people didn't notice but in doing so they released new system/OS level services and started relying on those. And notably they did this rollout staggered such that only some people got it and some didn't which made everything way more confusing.

GrapheneOS has a bunch of security hardening to restrict crosstalk between apps and services and the assumptions GOS made and the assumptions Google made about how services and apps should be allowed to interact were disjoint. That mismatch in assumptions broke things for a while. And the lack of clear communication from Google about this change combined with various anti-spam/rate limiting issues (Gmessages kept trying to register not expecting to fail and kept slamming the servers which looked like spam and triggered exponential backoff retries) compounded together to render RCS broken for a few weeks during that migration.

Notably this was also broken for basically every other non-google/non-samsung android provider for a while as well due to how poorly the migration was communicated by google.

Then not long after that was resolved graphene changed how they handled their sandboxing to make it less brittle to google changes and since then there's not been much in the way of issues.

The only issue with RCS since then has been a brief break in RCS (~1-2 days) about a month ago due to what was essentially an update to Google's services putting the graphene sandbox briefly out of sync. This was fixed almost immediately on the alpha release channel and just took ~48 hours to move through the alpha->beta->stable pipeline.

From this point on now that RCS is more or less all "standard" stuff now you shouldn't see any major breakages. The only situation where you might see one would be when android inevitably opens up RCS outside of the google services walled garden but even then you should be able to continue relying on the google services version until the non-google version is stable.

Kagi of course reviews it but generally it's good enough that I don't see much LLM generated content in the results anymore.