> Our implementation is up to 2x faster than optimized speculative decoding baselines and up to 5x faster than autoregressive decoding with open source inference engines
Speaking of battery, veeeeery soon phones will have mandated replaceable batteries in the EU. I'm just hoping my current moto (a $99 job perfectly adequate for absolutely everything I do) survives until then.
Aside: I've noticed over the years that phones die in one of the following ways:
- too fast charging (battery dies, charge controller dies)
- usb port dies
- screen broken
- all sorts of falls
A lether folio case, gorilla glass, and a Qi charging adapter solve all of those problems (the charging adapter also limits the current by virtue of being inefficient). It has a magnetic connector (it's a simple two-pin job and it doesn't have any issues) - in the rare occasion I want to charge up real quick, I can still hook up directly via usb c, and meanwhile the port is stuffed with the converter's plug which prevents it from accumulating dirt and fluff.
I'm glad to say that even despite many falls, some directly onto the screen, the phone itself still works very well, even if the case and glass protector are obviously ragged.
I hope once unlockable Moto's come around I'll be able to keep that one for a long while as well.
When you say replaceable, do you mean repairable or swappable? Like, does it need to be done without tools (probably takes <1 minute) or would it take me 2 hours with a load of tools (no change from today) just that there's a legal requirement for them to be commercially available?
Fwiw, besides people that crack the screen I have not seen any of the failures you've mentioned. The only phone I saw someone replace, for reasons other than software support, was myself because the gnss chip was cooked after 3 years (would track me perfectly, like if I step to the right it would notice, but with an offset of hundreds of metres so I'm in another town). All other phones I've owned are still perfectly functioning (the oldest Android phone I have, 2012, has a more reliable battery than my daily driver!), I don't use any case or screen protector. They're just software-wise obsolete because no updates and developers require the newer android apis
with the advent of AI assists, I can't wait for people to start hooking up SoCs, GPUs, and other components burdened by proprietary driver and firmware to logic analyzers, and letting AI have a crack at it. I wonder what'll happen - this might well be the end of proprietary blobs, and I'm here for it.
That would be wonderful but cracking proprietary blobs which may be and probably are encrypted, would take massive amount of time, and later rework could take a lot of tokens and broken SoCs. Nowadays electronics are driven by software so one bit off and voltage can get 9V instead of 3V for example
Oh, This might be one of the few ideas I approve AI use of.
Cursor spent like Million dollars on creating a browser which people were able to make later with a 200$/100$ subscription in the same amount of days as cursor with human assistance.
I don't think that this can be "autonomous", we assumed that making browsers could be autonomous process but it wasn't. That was the take I took from it all.
Will this be an example of autonomous tho? I think we still need a human experienced with reverse engineering in the loop but it might significantly improve their workflow
I wish if cursor, instead of having burnt million $ to something worthless essentially, Could have atleast done this experiment.
I know of AWS's reputation as a business and what the devs say who work there, so I have no argument against your point, except to say that they do manage to make it work. Somewhere in there must be some unsung heroes keeping the whole thing online.
The point being that AWS runs AWS, they don't run your business on AWS. You still need someone to actually set up AWS to do what you want, much like you would need someone to run your on-premises servers. And in my experience, the difference is not much.
The biggest issue is that with colo you're building a skill pool that can be used forever, with AWS you're building a skill pool centered around a corporate entity's business strategies and an inscrutable, closed-source system, which is not sustainable.
Helped a friend make a difficult career decision (cozy job vs something hard and new + moving to a new city) that ultimately ended up with him working on the project. Glad that happened. I love to see people grow.
Location: EU, overlap with PST
Remote: Yes
Relocation: No
Technologies: Rust, C++, Python, Go, Zig, Haskell, TypeScript, Nix, K8s, Terraform
Email: damianjobsites+hn@gmail.com
CV: on request
Senior engineer / tech lead (20+ YOE). Former IC → EM → Director → CTO.
Multiple exits. Hands-on, or owning the whole technical org.
Highlights:
- Designed and shipped a commercial LLM end-to-end (algorithms → training → MLops)
- Launched and audited major blockchain systems (e.g. Tezos)
- Shipped production systems for Oracle, Shell, Time Warner, BoA, Sparkasse, Saatchi & Saatchi, Digitas
- Built and scaled a software NGO (500k+ supporters, 1k+ volunteers)
Strengths:
- Turning ambiguous problems into shipped systems
- MVPs that don’t need rewriting
- ML, LLMs, RAGs, vector DBs
- Rigorous code and infosec audits for mission-critical infra
- 10x–1000x performance wins on legacy systems
- FP, Compilers, DSLs, distributed systems, security-critical code
Further work:
- Contributor: Rust Book, Rust By Example, Python docs, Haskell Communities and Activities Report
- Dozens of smart contract audits
- Background in cryptography, infosec, formal methods
If you need someone who can own the stack and ship reliably, email me at damianjobsites+hn@gmail.com
Infra / DevOps: NixOS/Nix, AWS, Terraform, Docker, Ansible; CI/CD, Linux internals, observability, reliability engineering.
Fintech / crypto: Launched Tezos and other blockchains; smart-contract audits; regulated, security-critical environments; built production systems for trad banks.
> The "money goes to the repo part" is the problem here, as it incentivizes maintainers to refuse legitimate pull requests.
That's not true. The issue is that the system the comment you're replying to described is escrow. Escrow degenerates in the way that you describe. I explain it a bit more in this comment elsewhere on this post:
A straight up non-refundable participation payment does not have this issue, and creates a different set of incentives and a different economy, while there also exist escape hatches for free-of-charge contributions.
> The real problem here is the amount of work necessary to make this viable.
Not necessarily. This article mentions Tezos, which is capable of doing such things on-chain already:
> all the annoying KYC/AML that a normie has to get through to use it.
There are always escape hatches. If your code is so great that people will want to pull it, then you don't pay to push. If it's not really that great, then what are we talking about? Maybe it disincentivizes mid code being pushed. So be it.
You can make friends, you can make a name for yourself, you can make a fork that's very successful and upstream will want to pull it in, you can exert social pressure / marketing to get your code merged in. Lots of options that do not involve KYC/AML.
For everyone else, I'd say KYC/AML are a good idea because of the increasing amount of supply chain exploits being pushed out into repos. If pushing by randos is gated by KYC/AML, then there's at least some method of chasing the perps down and taking them to justice.
That's a win-win-win-win situation. Less mid code, less exploits, earnings for maintainers, AI slop blocked. Absolutely amazing.
escrow is a more complex system, and there are multiple possible implementations, but the nice thing is you can skip it and get the same results.
let's assume for a second that the repo owner spends time on PR review, and that time needs to be reimbursed. let's also assume that the person pushing a PR expects some sort of bounty. then as long as the review price is less than bounty price, there's no need for escrow. the pushing party goes out on a limb paying the reviewer to merge their PR, but also expects (rightly or not) to be remunerated for solving the bounty. whether they really did solve it is in the remit of the bounty originator, who might or might not be part of the group controlling the repository. if there's escrow, then the bounty giver probably has to be part of that group. not having escrow allows for crowd funding by interests outside of the repo controlling party.
escrow is only usefully different in a situation when there is no bounty, you want to push code, and then you want to say "ok, here's some money, and here's a PR, either accept the PR and give me money or don't accept it and take my money" as a means of skipping the line or getting a shot at pushing in the first place. however, at that point two things are apparent: 1. you expect the reviewer to do work required to implement your desired changes for free and 2. this might start getting abused, with PRs getting rejected (to gain money) but then modified / refactored versions of this code being pushed via commits or from another user who is the repo owner's puppet (refactoring code is becoming super cheap due to AI). so that degenerates escrow-to-push into a scam.
there are more considerations like that in the article I linked to. I agree that an economy around FOSS pushing would be desirable. it also doesn't preclude free-as-in-money contributions - there are at least two mechanisms that would allow it: 1. you get sponsored by someone who sees your talent (either gives you money to push, or they have push access to that repo and can hand it out free) 2. you create a fork that becomes so good and valuable that upstream pulls from you for free
ultimately becoming a respected developer with free push access to contended repositories should be something that you can monetize to some extent that's purely within your remit, and it would greatly reduce unserious bullshit coming from third parties (especially all those weird hardware developers) and make it easier to be a FOSS dev.
what about per-FLOP?