HN user
In an age of malicious agentic AI, this level of access is negligent. A lack of engineering controls preventing this from happening at all means that a simple phishing or supply chain attack could easily have resulted in the same outcome or worse.
This sort of conversion gets coverage every once in a while and it's been neat to see old frames getting chopped onto new electric drivetrains. I spoke with one of the people interviewed in this article[1] a couple years back about converting an old truck I have sitting around into an EV.
The Model 3 approach takes their unified rear axle (motor,axle,wheels) and mounts it into an existing frame. Then you just need to find a place to stuff the batteries, retrofit some high-voltage electronics, and you're off to the races. One of the drawbacks of that approach is that it changes the stance of the vehicle, but for this Mustang that doesn't seem to matter much - it still looks classic.
Other converters either go for the high end with a model S and fit the motor into a traditional drivetrain for a sleeper build, or they go for the low end and take an old forklift motor and batteries and build what is effectively a street-legal golf cart. Prices range from $5-100k depending on your level of DIY and how dangerous of a classic car you want on the other side of the process.
[1] https://coloradosun.com/2023/06/25/classic-cars-electric-veh...
sounds like a good opportunity to bring back "letters of marque." These were less about authorizing ships to fight back against pirates, and more about authorizing private to your army to find and capture pirate vessels with the expectation that they would be allowed to keep whatever loot they captured. sounds like we're taking a step in that direction as the Internet is being identified as Lawless as the sea.
For the skeptics here, this is the exponent thats driving the development of datacenters in space. The data has utility but it will be stuck in orbit. Space-based storage and processing makes a lot more sense when you consider that getting all that data to ground is challenging now, and will soon be impossible.
I agree. I've been researching a lot of this tech lately as a part of a C2PA / content authenticity project and it's clear that the math are outrunning practicality in a lot of cases.
As it is we're seeing companies capture IDs and face scans and it's incredibly invasive relative to the need - "prove your birth year is in range". Getting hung up on unlinkable sessions is missing the forest for the trees.
At this point I think the challenge has less to do with the crypto primitives and more to do with building infrastructure that hides 100% of the complexity of identity validation from users. My state already has a gov't ID that can be added to an apple wallet. Extending that to support proofs about identity without requiring users to unmask huge amounts of personal information would be valuable in its own right.
You seem to have missed requirement #3 -> tracking and identifying reuse.
An 18-year-old creating an account for a 12-year-old is a legal issue, not a service provider issue. How does a gas station keep a 21-year-old from buying beer for a bunch of high school students? Generally they don't, because that's the cops' job. But if they have knowledge that the 21-yo is buying booze for children, they deny custom to the 21-yo. This is simple.
We are missing accessible cryptographic infrastructure for human identity verification.
For age verification specifically, the only information that services need proof of is that the users age is above a certain threshold. i.e. that the user is 14 years or older. But in order to make this determination, we see services asking for government ID (which many 14-year-olds do not have), or for invasive face scans. These methods provide far more data than necessary.
What the service needs to "prove" in this case is three things:
1. that the user meets the age predicate
2. that the identity used to meet the age predicate is validated by some authority
3. that the identity is not being reused across many accounts
All the technologies exist for this, we just haven't put them together usefully. Zero knowledge proofs, like Groth16 or STARKs allow for statements about data to be validated externally without revealing the data itself. These are difficult for engineers to use, let alone consumers. Big opportunity for someone to build an authority here.
Maybe code is free, but code isn't all that goes into building software. Minimally, you have design, code, integrate, test, document, launch.
Claude is going to help mostly with code, much less with design. It might help to accelerate integration, if the application is simple enough and the environment is good enough. The fact is, going cross-platform native trebles effort in areas that Claude does not yet have a useful impact.
At 16k tokens/s why bother routing? We're talking about multiple orders of magnitude faster and cheaper execution.
Abundance supports different strategies. One approach: Set a deadline for a response, send the turn to every AI that could possibly answer, and when the deadline arrives, cancel any request that hasn't yet completed. You know a priori which models have the highest quality in aggregate. Pick that one.
I agree completely. It's a mistake to anthropomorphize these models, and it is a mistake to permit training models that anthropomorphize themselves. It seriously bothers me when Claude expresses values like "honestly", or says "I understand." The machine is not capable of honesty or understanding. The machine is making incredibly good predictions.
One of the things I observed with models locally was that I could set a seed value and get identical responses for identical inputs. This is not something that people see when they're using commercial products, but it's the strongest evidence I've found for communicating the fact that these are simply deterministic algorithms.
I've made many business cases for internally-built SaaS tools, and they always rest on the idea that our probability of success is higher if we staff a team and build the _exact thing_ we need versus purchasing from a vendor and attempting an integration into our business.
It's far more challenging to win the 'build' argument on a cost savings approach, because even the least-savvy CIO/CTO understands that the the price of the vendor software is a proof point grounded in the difficulty for other firms to build these capabilities themselves. If there's merit to these claims, the first evidence we'll see is certain domains of enterprise software (like everything Atlassian does) getting more and more crowded, and less and less expensive, as the difficulty of competing with a tier-1 software provider drops and small shops spring up to challenge the incumbents.
100% of my LLM projects are written in Rust - and I have never personally written a single line of Rust. Compilation alone eliminates a number of 'category errors' with software - syntax, variable declaration, types, etc. It's why I've used Go for the majority of projects I've started the past ten years. But with Rust there is a second layer of guarantees that come from its design, around things like concurrency, nil pointers, data races, memory safety, and more.
The fewer category errors a language or framework introduces, the more successful LLMs will be at interacting with it. Developers enjoy freedom and many ways to solve problems, but LLMs thrive in the presence of constraints. Frontiers here will be extensions of Rust or C-compatible languages that solve whole categories of issue through tedious language features, and especially build/deploy software that yields verifiable output and eliminates choice from the LLMs.
If software engineers can agree on anything, it's that LLM experiences are wildly inconsistent. People have similar inconsistencies. We have different experiences, intellects, educations, priorities, motivations, value systems. And in software specifically (and institutions generally) we create methodologies and processes that diminish our inconsistencies and leverage our strengths.
Gas town is a demonstration of a methodology for getting a consistent result from inconsistent agents. The case in point is that Yegge claims to have solved the MAKER problem (tower of Hanoi) via prompting alone. With the right structure, quantity has a quality all its own.
At current rates of emissions, we’re only about 20 years away from people needing to install CO2 scrubbers in their homes.
Soda lime, or calcium hydroxide, is the current state of the art. We use that in an anesthesia and in saltwater aquariums and in scuba rebreathers. An idealized system can capture 500 mg per gram, but in practice you only capture around 250mg/g. This outperforms the method in the article but it’s one-shot. There are interesting proposals to use this for direct capture at industrial facilities and to turn the waste material into bricks for building.
The key advantage of this new material appears to be that it can be heated and reused. That would be very valuable in an interior direct air capture use case. Think about filtering the CO2 from an office or a home to get us back to pre-industrial levels indoors.
This approach kind of reminds me of taking an open-book test. Performing mandatory verification against a ground truth is like taking the test, then going back to your answers and looking up whether they match.
Unlike a student, the LLM never arrives at a sort of epistemic coherence, where they know what they know, how they know it, and how true it's likely to be. So you have to structure every problem into a format where the response can be evaluated against an external source of truth.
Trains and airplanes are fundamentally different from cars. A car accident is unlikely to kill you. A plane crash will. A car accident is unlikely to kill your entire family. A plane crash will.
The standard is higher for these modes of transportation because the consequences of individual incidents are higher. People innately recognize this; we only have one life; one family.
This is not a controversial take, the evidence already exists.
There's a website tracking deaths associated with Teslas, including 61 autopilot fatalities. This has not deterred people from continuing to use autopilot, because using autopilot is a sensible decision. Use of autopilot reduces accidents sixfold in a trend that has been improving over time.[1] Waymo has better statistics and even better performance.[2]
These technologies are going to change the world in a huge way. I'd wager that within 10 years, every luxury car will be outfitted with Waymo sensor kits. Nobody will care how it looks. Within 20, you won't be able to buy consumer insurance for a car you drive yourself.
[1] https://www.tesla.com/VehicleSafetyReport [2] https://waymo.com/safety/impact/
I don’t disagree with including user attestation in addition to hardware attestation.
The notion of their being a “analog hole” for devices that attest that their content is real is correct on the face, but is a very flawed criticism. Right now, anybody on earth can open up an LLM and generate an image. Anybody on earth can open up Photoshop and manipulate an image. And there’s no accountability for where that content came from. But not everybody on earth is capable of projecting an image and photographing it in a way that is in distinguishable from taking a photo of reality. Especially when you’ve taken into consideration that these cameras are capturing depths of field information, location information, and other metadata.
I think it’s a mistake to demand perfection. This is about trust in media and creating foundational technologies that allow for that trust to be restored. Imagine if every camera and every piece of editing software had the ability to sign its output with a description of any mutations. That is a chain of metadata where each link in the chain can be assigned to trust score. If, an addition to technology signatures, human signatures are included, that just builds additional trust. At some point, it would be inappropriate for news or social media not to use this information when presenting content.
As others have mentioned, C2PA is a reasonable step in this direction.
Jacked up prices isn't what is happening here. There is a psychological effect that Heroku and other cloud vendors are (wittingly or unwittingly) the beneficiary of. Customer expectations are anchored in the price they pay when they start using the service, and without deliberate effort, those expectations change in _linear_ fashion. Humans think in linear terms, while actual compute hardware improvements are exponential.
Heroku's pricing has _remained the same_ for at least seven years, while hardware has improved exponentially. So when you look at their pricing and see a scam, what you're actually doing is comparing a 2025 anchor to a mid-2010s price that exists to retain revenue. At the big cloud vendors, they differentiate customers by adding obstacles to unlocking new hardware performance in the form of reservations and updated SKUs. There's deliberate customer action that needs to take place. Heroku doesn't appear to have much competition, so they keep their prices locked and we get to read an article like this whenever a new engineer discovers just how capable modern hardware is.
It's GPU performance.
Spin up ollama and run some inference on your 5-year-old intel macbook. You won't see 4000x performance improvement (because performance is bottlenecked outside of the GPU), but you might be in the right order of magnitude.
Modern video codecs are what broke the telco monopoly on content and gave us streaming services in the first place. If the cdn bill is make or break, the service isn’t going to last.
And there’s no transfer of effort to the user. Compute complexity of video codecs is asymmetric. The decode is several order of magnitude cheaper to compute than the encode. And in every case, the principal barrier to codec adoption has been hardware acceleration. Pretty much every device on earth has a hardware-accelerated h264 decoder.
The 'cost of a bad hire' is received wisdom that needs to go away. The first order effects of your team's time investment are easy to see and make good content for your engineering leadership blog when you're aiming for promotion. The second order effects are what get debated in threads like this ad infinitum.
Paradoxically, a higher bar for hiring increases these consequences for everyone. A bad hire is only consequential in the first place because hiring managers are slow to cut them loose. Managers are slow to cut loose because they are morally culpable for the consequences to the individual they hired. When a manager extends an offer, they are accepting some responsibility for a significant change in a person's life. It's very difficult to walk that back when it's a bad fit, knowing that hiring is a slow process and every other company out there is scared of making a bad choice. But at the end of the day, interviews are an approximation of the candidate/company fit in what is ultimately a matching problem. More attempts make for better matches. Companies and candidates both would be better served by being faster to hire and faster cut loose.
I pay for Kagi for search, my family uses Kagi. I pay for NextDNS to block ads, all of my family's devices use NextDNS. I pay for credits on OpenRouter and host an OpenWebUI instance, all of my family's AI is private. I pay for the news - The Economist, the WSJ, FT, NewScientist, etc. Lies are free, the truth is behind a paywall.
The only thing money can't buy, yet, is a phone network free of robocalls.
What makes node supply chain attacks so dangerous is the CI/CD pattern whereby all dependencies are downloaded from the internet every time a build is created. NPM attacks move fast.
I previously worked in an environment where our ci servers weren't internet-connected. One of the things we did get get node builds to work was we had 'node_modules' for our projects in a separate repository that got joined with our source code in CI to complete a build. When a developer added a dependency, they had to update this repo from their local version. It was annoying to have to synchronize two repositories, but this ended up being a forcing function for the development team to adopt several of the suggestions listed here. When you see a PR with a massive diff for a small dependency change, eyebrows raise and the team starts conversations about how to improve things.
A talented chef might cut vegetables at 25hz, while the blade is moving at 44khz. So whatever cutting improvement is conferred by the ultrasonic tech will certainly be applied towards fast cutting. It seems that the main benefit for fast cutting would be that food doesn't stick to the blade.
I'll cut bread with my chef's knife (amazon shun knockoff) when I want to make less of a mess. One interesting thing I noticed is that when Scott was cutting bread in the video he was cutting a croissant and no crumbs fell.
It will be interesting to see the knife in the hands of real chefs. Two things I'm curious about are whether the ergonomics of the button are good, and whether the ultrasonic action atomizes foods as they're being cut, changing the experience of cooking in some way.
The article is hyperbole and this only impacts ARR for consumer services, which tend to be either month-to-month paid in arrears, or annually prepaid. It doesn't change anything, but if your gym membership goes high-tech it might be easier to cancel.
The specific provisions[1] covering unfair contract terms apply only to "unilateral" contracts, meaning contracts that are offered to a customer who meets two important criteria. First that they attempted to negotiate specific terms in the contract. Second that they had no ability to influence those terms but continued to purchase the service anyways. Real, scaled, committed SaaS ARR isn't going anywhere.
[1] https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng#cpt_IV
This is a terrific article the synthesize is several of the trends that have been at play the past five or six years. One interesting phenomenon of AI is that university enrollment and computer science is already falling. A lot. So if the AI promise doesn’t deliver (there are already signs), software engineering talent is going to cost a lot more than it did before.
This belief is completely incorrect. Helmets increase survivability and decrease the degree of injuries in every respect. This is a very well-studied phenomenon with many public and peer reviewed sources. [1]
To respond to the 'nuance' of your remark, that helmets change rider behavior for the worse, resulting in higher aggregate injuries - that is also incorrect. The passage of helmet laws results in significant reductions (20-50%) in head injuries and deaths. These are reductions among the same population, in the same geography, in a short timeframe. It is indisputable.
If the total number of recorded injuries is going up, it's because ridership has increased. Ridership is up for lots of reasons, population growth and health benefits being two of them. Cycling is a terrific way to improve your overall health, even when the risk of injury or death due to cycling is taken into consideration. [2]
And if manufacturers profit from improving the health and safety of a population? Good.
[1] https://newrossgreenway.org/bicycle-helmet-vs-no-helmet-stat... [2] https://pmc.ncbi.nlm.nih.gov/articles/PMC10546027/
What a hot take! If you're in an organization where leadership 'points the finger' at McKinsey to cast blame for an unpopular decision, imagine what sorts of decisions they would have made without the consultants!
Consultants are hired to improve decision quality. They do that through a combination of analysis, experience, and industry connections. The work product is rarely 'powerpoints'. The work product is the actual work, which entails people doing research, making decisions, executing on them, and measuring results.
At any rate, I don't disagree with you that consultants aren't going anywhere. This post is an ad for an immature AI service that makes a bunch of claims about how they've solved for hallucinations and knowledge cutoffs in order to take down McKinsey. If they had solves for those problems, they'd be wasting their effort building a replacement for consulting firms.
You're conflating gene therapies vs. the human genome with gene therapies vs. viral genomes. In some cases, the illnesses are genetic, but this article is specifically about how gene therapy companies keep going out of business trying to cure rare genetic illnesses! Even if the technology is the same, the uses are very different and regulatory approval is still required for the application of the technology.
That's not to say there aren't additional ethical challenges that would arise if gene therapies were cheap, but the ethics concerns you're raising seem like future concerns, relevant to a world that does not yet exist.