10 interesting stories served every morning and every evening.
Skip to main content
🚨 The Conservatives (EPP) are attempting to force a new vote on Thursday (26th), seeking to reverse Parliament’s NO on indiscriminate scanning. This is a direct attack on democracy and blatant disregard for your right to privacy. No means no. Take action now!
...
Read the original on fightchatcontrol.eu »
It’s been about a year since coding agents appeared on the scene that could actually build you full projects. There were precursors like Aider and early Cursor, but they were more assistant than agent. The new generation is enticing, and a lot of us have spent a lot of free time building all the projects we always wanted to build but never had time to.
And I think that’s fine. Spending your free time building things is super enjoyable, and most of the time you don’t really have to care about code quality and maintainability. It also gives you a way to learn a new tech stack if you so want.
During the Christmas break, both Anthropic and OpenAI handed out some freebies to hook people to their addictive slot machines. For many, it was the first time they experienced the magic of agentic coding. The fold’s getting bigger.
Coding agents are now also introduced to production codebases. After 12 months, we are now beginning to see the effects of all that “progress”. Here’s my current view.
While all of this is anecdotal, it sure feels like software has become a brittle mess, with 98% uptime becoming the norm instead of the exception, including for big services. And user interfaces have the weirdest fucking bugs that you’d think a QA team would catch. I give you that that’s been the case for longer than agents exist. But we seem to be accelerating.
We don’t have access to the internals of companies. But every now and then something slips through to some news reporter. Like this supposed AI caused outage at AWS. Which AWS immediately “corrected”. Only to then follow up internally with a 90-day reset.
Satya Nadella, the CEO of Microsoft, has been going on about how much code is now being written by AI at Microsoft. While we don’t have direct evidence, there sure is a feeling that Windows is going down the shitter. Microsoft itself seems to agree, based on this fine blog post.
Companies claiming 100% of their product’s code is now written by AI consistently put out the worst garbage you can imagine. Not pointing fingers, but memory leaks in the gigabytes, UI glitches, broken-ass features, crashes: that is not the seal of quality they think it is. And it’s definitely not good advertising for the fever dream of having your agents do all the work for you.
Through the grapevine you hear more and more people, from software companies small and large, saying they have agentically coded themselves into a corner. No code review, design decisions delegated to the agent, a gazillion features nobody asked for. That’ll do it.
We have basically given up all discipline and agency for a sort of addiction, where your highest goal is to produce the largest amount of code in the shortest amount of time. Consequences be damned.
You’re building an orchestration layer to command an army of autonomous agents. You installed Beads, completely oblivious to the fact that it’s basically uninstallable malware. The internet told you to. That’s how you should work or you’re ngmi. You’re ralphing the loop. Look, Anthropic built a C compiler with an agent swarm. It’s kind of broken, but surely the next generation of LLMs can fix it. Oh my god, Cursor built a browser with a battalion of agents. Yes, of course, it’s not really working and it needed a human to spin the wheel a little bit every now and then. But surely the next generation of LLMs will fix it. Pinky promise! Distribute, divide and conquer, autonomy, dark factories, software is solved in the next 6 months. SaaS is dead, my grandma just had her Claw build her own Shopify!
Now again, this can work for your side project barely anyone is using, including yourself. And hey, maybe there’s somebody out there who can actually make this work for a software product that’s not a steaming pile of garbage and is used by actual humans in anger.
If that’s you, more power to you. But at least among my circle of peers I have yet to find evidence that this kind of shit works. Maybe we all have skill issues.
The problem with agents is that they make errors. Which is fine, humans also make errors. Maybe they are just correctness errors. Easy to identify and fix. Add a regression test on top for bonus points. Or maybe it’s a code smell your linter doesn’t catch. A useless method here, a type that doesn’t make sense, duplicated code over there. On their own, these are harmless. A human will also do such booboos.
But clankers aren’t humans. A human makes the same error a few times. Eventually they learn not to make it again. Either because someone starts screaming at them or because they’re on a genuine learning path.
An agent has no such learning ability. At least not out of the box. It will continue making the same errors over and over again. Depending on the training data it might also come up with glorious new interpolations of different errors.
Now you can try to teach your agent. Tell it to not make that booboo again in your AGENTS.md. Concoct the most complex memory system and have it look up previous errors and best practices. And that can be effective for a specific category of errors. But it also requires you to actually observe the agent making that error.
There’s a much more important difference between clanker and human. A human is a bottleneck. A human cannot shit out 20,000 lines of code in a few hours. Even if the human creates such booboos at high frequency, there’s only so many booboos the human can introduce in a codebase per day. The booboos will compound at a very slow rate. Usually, if the booboo pain gets too big, the human, who hates pain, will spend some time fixing up the booboos. Or the human gets fired and someone else fixes up the booboos. So the pain goes away.
With an orchestrated army of agents, there is no bottleneck, no human pain. These tiny little harmless booboos suddenly compound at a rate that’s unsustainable. You have removed yourself from the loop, so you don’t even know that all the innocent booboos have formed a monster of a codebase. You only feel the pain when it’s too late.
Then one day you turn around and want to add a new feature. But the architecture, which is largely booboos at this point, doesn’t allow your army of agents to make the change in a functioning way. Or your users are screaming at you because something in the latest release broke and deleted some user data.
You realize you can no longer trust the codebase. Worse, you realize that the gazillions of unit, snapshot, and e2e tests you had your clankers write are equally untrustworthy. The only thing that’s still a reliable measure of “does this work” is manually testing the product. Congrats, you fucked yourself (and your company).
You have zero fucking idea what’s going on because you delegated all your agency to your agents. You let them run free, and they are merchants of complexity. They have seen many bad architectural decisions in their training data and throughout their RL training. You have told them to architect your application. Guess what the result is?
An immense amount of complexity, an amalgam of terrible cargo cult “industry best practices”, that you didn’t rein in before it was too late. But it’s worse than that.
Your agents never see each other’s runs, never get to see all of your codebase, never get to see all the decisions that were made by you or other agents before they make a change. As such, an agent’s decisions are always local, which leads to the exact booboos described above. Immense amounts of code duplication, abstractions for abstractions’ sake.
All of this compounds into an unrecoverable mess of complexity. The exact same mess you find in human-made enterprise codebases. Those arrive at that state because the pain is distributed over a massive amount of people. The individual suffering doesn’t pass the threshold of “I need to fix this”. The individual might not even have the means to fix things. And organizations have super high pain tolerance. But human-made enterprise codebases take years to get there. The organization slowly evolves along with the complexity in a demented kind of synergy and learns how to deal with it.
With agents and a team of 2 humans, you can get to that complexity within weeks.
So now you hope your agents can fix the mess, refactor it, make it pristine. But your agents can also no longer deal with it. Because the codebase and complexity are too big, and they only ever have a local view of the mess.
And I’m not just talking about context window size or long context attention mechanisms failing at the sight of a 1 million lines of code monster. Those are obvious technical limitations. It’s more devious than that.
Before your agent can try and help fix the mess, it needs to find all the code that needs changing and all existing code it can reuse. We call that agentic search. How the agent does that depends on the tools it has. You can give it a Bash tool so it can ripgrep its way through the codebase. You can give it some queryable codebase index, an LSP server, a vector database. In the end it doesn’t matter much. The bigger the codebase, the lower the recall. Low recall means that your agent will, in fact, not find all the code it needs to do a good job.
This is also why those code smell booboos happen in the first place. The agent misses existing code, duplicates things, introduces inconsistencies. And then they blossom into a beautiful shit flower of complexity.
How do we avoid all of this?
Coding agents are sirens, luring you in with their speed of code generation and jagged intelligence, often completing a simple task with high quality at breakneck velocity. Things start falling apart when you think: “Oh golly, this thing is great. Computer, do my work!”.
There’s nothing wrong with delegating tasks to agents, obviously. Good agent tasks share a few properties: they can be scoped so the agent doesn’t need to understand the full system. The loop can be closed, that is, the agent has a way to evaluate its own work. The output isn’t mission critical, just some ad hoc tool or internal piece of software nobody’s life or revenue depends on. Or you just need a rubber duck to bounce ideas against, which basically means bouncing your idea against the compressed wisdom of the internet and synthetic training data. If any of that applies, you found the perfect task for the agent, provided that you as the human are the final quality gate.
Karpathy’s auto-research applied to speeding up startup time of your app? Great! As long as you understand that the code it spits out is not production-ready at all. Auto-research works because you give it an evaluation function that lets the agent measure its work against some metric, like startup time or loss. But that evaluation function only captures a very narrow metric. The agent will happily ignore any metrics not captured by the evaluation function, such as code quality, complexity, or even correctness, if your evaluation function is foobar.
The point is: let the agent do the boring stuff, the stuff that won’t teach you anything new, or try out different things you’d otherwise not have time for. Then you evaluate what it came up with, take the ideas that are actually reasonable and correct, and finalize the implementation. Yes, sure, you can also use an agent for that final step.
And I would like to suggest that slowing the fuck down is the way to go. Give yourself time to think about what you’re actually building and why. Give yourself an opportunity to say, fuck no, we don’t need this. Set yourself limits on how much code you let the clanker generate per day, in line with your ability to actually review the code.
Anything that defines the gestalt of your system, that is architecture, API, and so on, write it by hand. Maybe use tab completion for some nostalgic feels. Or do some pair programming with your agent. Be in the code. Because the simple act of having to write the thing or seeing it being built up step by step introduces friction that allows you to better understand what you want to build and how the system “feels”. This is where your experience and taste come in, something the current SOTA models simply cannot yet replace. And slowing the fuck down and suffering some friction is what allows you to learn and grow.
The end result will be systems and codebases that continue to be maintainable, at least as maintainable as our old systems before agents. Yes, those were not perfect either. Your users will thank you, as your product now sparks joy instead of slop. You’ll build fewer features, but the right ones. Learning to say no is a feature in itself.
You can sleep well knowing that you still have an idea what the fuck is going on, and that you have agency. Your understanding allows you to fix the recall problem of agentic search, leading to better clanker outputs that need less massaging. And if shit hits the fan, you are able to go in and fix it. Or if your initial design has been suboptimal, you understand why it’s suboptimal, and how to refactor it into something better. With or without an agent, don’t fucking care.
All of this requires discipline and agency.
All of this requires humans.
...
Read the original on mariozechner.at »
...
Read the original on rpastro.square.site »
Tesla runs a bug bounty program that invites researchers to find security vulnerabilities in their vehicles. To participate, I needed the actual hardware, so I started looking for Tesla Model 3 parts on eBay. My goal was to get a Tesla car computer and touchscreen running on my desk, booting the car’s operating system.
The car computer consists of two parts - the MCU (Media Control Unit) and the autopilot computer (AP) layered on top of each other. In the car, the computer is located in front of the passenger seat, roughly behind the glovebox. The part itself is the size of an iPad and the thickness of a ~500 page book and is covered in a water-cooled metal casing:
By searching for “Tesla Model 3 MCU” on Ebay, I found quite a lot of results in the $200 - $300 USD price range. Looking at the listings, I found that many of these sellers are “salvaging” companies who buy crashed cars, take them apart, and list all parts for sale individually. Sometimes, they even include a photo of the original crashed car and a way to filter their listings for parts extracted from the same vehicle.
To boot the car up and interact with it, I needed a few more things:
* The display cable to connect them together
For the power supply, I went with an adjustable 0-30V model from Amazon. There was a 5 ampere and a 10A version available, at the time, I figured it’s safer to have some headroom and went with the 10A version — it was a very good decision, as it later turned out, the full setup could consume up to 8A at peak times. The Model 3 screens were surprisingly expensive on Ebay, I assume that is because it is a popular part to replace. I found a pretty good deal for 175 USD.
The last and most difficult part to order was the cable which connects the MCU to the screen. I needed this because both the computer and a screen were being sold with the cables cut a few centimeters after the connector (interestingly most sellers did that, instead of just unplugging the cables).
This is when I discovered that Tesla publishes the wiring “Electrical Reference” for all of its cars publicly. On their service website, you can look up a specific car model, search for a component (such as the display), and it will show you exactly how the part should be wired up, what cables/connectors are used, and even what the different pins are responsible for inside a single connector:
Turns out the display uses a 6-pin cable (2 for 12V and ground, 4 for data) with a special Rosenberger 99K10D-1D5A5-D connector. I soon discovered that unless you are a car manufacturer ordering in bulk, there is no way you are buying a single Rosenberger cable like this. No Ebay listings, nothing on Aliexpress, essentially no search results at all.
After digging around a bit, I found that this cable is very similar to a more widely used automotive cable called “LVDS”, which is used to transfer video in BMW cars. At first sight, the connectors looked like a perfect match to my Rosenberger, so I placed an order:
The computer arrived first. To attempt to power it on, I looked up which pin of which connector I needed to attach 12V and ground to using the Tesla schematics & the few pictures online of people doing the same desk-MCU setup. Since the computer included the shortly cut cables, I was able to strip the relevant wires and attach the power supply’s clips to the right ones:
I saw a couple of red LEDs start flashing, and the computer started up! Since I had no screen yet, there were not many ways to interact with the car. Reading @lewurm’s previous research on GitHub I knew that, at least in older car versions, there was a network inside the car, with some components having their own webserver. I connected an Ethernet cable to the port next to the power connector and to my laptop.
This network does not have DHCP, so you have to manually set your IP address. The IP you select has to be 192.168.90. X/24, and should be higher than 192.168.90.105 to not conflict with other hosts on the network. On Reddit, I found the contents of an older /etc/hosts file from a car which shows the hosts that are normally associated with specific IPs:
@lewurm’s blog mentioned that SSH on port :22 and a webserver on :8080 was open on 192.168.90.100, the MCU. Was this still the case on newer models? Yes!
I had already found 2 services to explore on the MCU:
* An SSH server which states “SSH allowed: vehicle parked” - quite funny given the circumstances
This SSH server requires specially signed SSH keys which only Tesla is supposed to be able to generate.
Interestingly, Tesla offers a “Root access program” on their bug bounty program. Researchers who find at least one valid “rooting” vulnerability will receive a permanent SSH certificate for their own car, allowing them to log in as root and continue their research further. — A nice perk, as it is much easier to find additional vulnerabilities once you are on the inside.
* This SSH server requires specially signed SSH keys which only Tesla is supposed to be able to generate.
* Interestingly, Tesla offers a “Root access program” on their bug bounty program. Researchers who find at least one valid “rooting” vulnerability will receive a permanent SSH certificate for their own car, allowing them to log in as root and continue their research further. — A nice perk, as it is much easier to find additional vulnerabilities once you are on the inside.
* A REST-like API on :8080 which returned a history of “tasks”
This service is called “ODIN” (On-Board Diagnostic Interface Network), and is intentionally exposed to be used by Tesla’s diagnostics tool “Toolbox”.
* This service is called “ODIN” (On-Board Diagnostic Interface Network), and is intentionally exposed to be used by Tesla’s diagnostics tool “Toolbox”.
Around this time, I also removed the metal shielding to see exactly what the boards look like inside. You can see the two different boards which were stacked on top of each other:
Once the screen and the BMW LVDS cable arrived, it unfortunately became clear that the connector is not going to fit. The BMW connector was much thicker on the sides and it was not possible to plug it into the screen. This led to some super sketchy improvised attempts to strip the two original “tail” cables from the MCU and the screen and connect the individual wires together. The wires were really sensitive and thin. The setup worked for a couple of seconds, but caused wire debris to fall on the PCB and short it, burning one of the power controller chips:
It was extremely hard to find the name/model of the chip that got burned, especially since part of the text printed on it had become unreadable due to the damage. To be able to continue with the project, I had to order a whole other car computer.
In the meantime, my friend Yasser (@n3r0li) somehow pulled off the impossible and identified it as the “MAX16932CATIS/V+T” step-down controller, responsible for converting power down to lower voltages. We ordered the chip and took the board to a local PCB repair shop, where they successfully replaced it and fixed the MCU. Now I had two computers to work with.
So I really did need that Rosenberger cable, there was no getting around it.
After having no luck finding it online and even visiting a Tesla service center in London (an odd encounter, to say the least), I had to accept what I had been trying to avoid: buying an entire Dashboard Wiring Harness.
Back in the Tesla Electrical Reference, in addition to the connectors, one can find every part number. Looking at the cable which connects the MCU to the screen, the number 1067960-XX-E shows. Searching for it on Ebay brings up this monstrosity:
Turns out that actual cars don’t have individual cables. Instead they have these big “looms”, which bundle many cables from a nearby area into a single harness. This is the reason why I could not find the individual cable earlier. They simply don’t manufacture it. Unfortunately I had no other choice but to buy this entire loom for 80 USD.
Despite how bulky it was, the loom worked perfectly. The car booted, the touch screen started up, and I had a working car computer on my desk, running the car’s operating system!
Having the system running, I can now start playing with the user interface, interacting with the exposed network interfaces, exploring the CAN buses, and perhaps even attempting to extract the firmware.
...
Read the original on bugs.xdavidhu.me »
Apple has just lost me as an user. It will take me a while before I can fully migrate away from their devices, and I suspect I might need to keep a mac around for my work, but I will move all my personal computing to Linux and Android again.
I been an Apple user since MacOS 8. I had both a Newton MessagePad 2000 and an eMate 300. I got the original blue toilet-seat iBook G3. I was there for the developer road show introducing MacOS X. I paid for my developer account since then. Recently, I had a Macbook Air, iPhone 17, iPad Mini.
I’m gonna throw all of them away — not literally ofc — because of recent slop this company been shipping. It is death through a thousand papercuts. To summarise for yous there are three main issues for me and the last one happened today and is what pushed me through the threshold.
I absolutely hate Apple quarantine and gatekeeping of software. As a developer, I should just be able to ship software to those interested in my apps. Be aware that I don’t give a flying fuck about mobile development, I’m talking about desktop apps here.
I gave in to the Apple racketering scheme and got myself a developer account from the very start. I had to fax my card details to them, that is how long I had my account.
Even though my software is packaged and notarised as per their requirements, they still show my users a dialog box confirming they want to run my app, something they do not for apps installed through their walled garden. This is just friction to punish developers outside their store. I am very tired of it.
That has been an absolute fiasco. Liquid glass is completely broken from a design point of view. I have no idea how that got out of the door, and now multiple updates in, it still just as bad.
Not only it looks ugly, and that is subjective of course, but it is visually broken. Interfaces built with AppKit or SwiftUI that rendered perfect, are now overlapping controls and clipping stuff. They have no consistency at all in terms of icons, placement, corners…
I am not a designer, I don’t even care about design much, but when a bad design spreads like ink on a glass of water poisoning my workflows, it is when I notice it.
My iPhone updated last night and per UK laws, it introduced age verification. The way Apple decided to implement this is through credit card checking.
First it attempted to check my Apple Wallet, it failed even though I have five cards in it and am able to use the App Store fine.
Then it moved onto wanting me to manually add a card to verify myself. It failed with all my five cards. Four were debit cards, and one was a credit card from another country, cause you know I am an immigrant who has accounts still in my own original birth place.
So it failed age verification and locked me out of many features. Bear in mind, I am 45 years old. I have an Apple account for 25 years, the age of my personal account alone should already verify my age.
Credit cards are not documents. Many people don’t have them. Apple don’t provide any other way to verify your age because they are a stupid American company with American values in which you’re just as human as your credit score.
Age verification is a scam, but checking it with a credit card is even worse.
Next steps for me
I was already done with Apple for some months now, but due to that happening today, I am angry af and will speed up my plans.
I’m tired of devices that are not actually mine, of workflows that without blessing from a higher corporate authority won’t work. I’m gonna move back to Linux and Android.
Yeah, I know Google gonna fuck Android soon the same way, but at least with Android you tend to have more options.
For my computing needs, I purchased a MNT Pocket Reform. It will take them a while to assemble and send it to me, but once I have it, my macbook will become a work laptop only. All software I make already ships for Linux.
I am considering getting a Fairphone Gen 6. Not sure if I will go with stock Android or their Murena /e/OS version. It depends how the degoggled version handles my banking apps. I might need to go with stock Android.
After those two, I plan to assemble a little homelab using either a TinyMiniMicro form factor PC running Linux and if I have the budget an ugreen NAS. On those machines, I want to have something to handle my photo backup and shared drive. Will probably use either tailscale or some cloudflare bullshit to connect them to each other.
This is it, moving back towards taking control of my computing again.
Did you enjoyed reading this content? Want to support me?
You can buy me a coffee at ko-fi.
You can reach out to me on Bluesky, or Mastodon, Secure Scuttlebutt, or through WebMentions.
...
Read the original on andregarzia.com »
Why do I file bug reports with Apple Feedback Assistant? I plead insanity. Or perhaps addiction. I seesaw between phases of abstinence and falling off the wagon. I’ve even tried organizing a public boycott of Feedback Assistant, with a list of demands to improve the experience for users, but the boycott never caught on with other developers. Regardless, an incentive still exists to file bug reports, because Apple actually fixes some of my bugs. My main complaint about the bug reporting process is not the unfixed bugs but rather the disrespect for bug reports and the people who file them. Apple intentionally wastes our time with no regrets, as if our time had no value, as if we had some kind of duty to serve Apple.
In March 2023, I filed FB12088655 “Privacy: Network filter extension TCP connection and IP address leak.” I mentioned this bug report at the time in a blog post, which included the same steps to reproduce and example Xcode project that I provided to Apple. In the three years since I filed the bug report, I received no response whatsoever from Apple… until a couple of weeks ago, when Apple asked me to “verify” the issue with macOS 26.4 beta 4 and update my bug report.
I install the WWDC betas every year in June but don’t run OS betas after September when the major OS updates are released. I don’t have enough time or indeed enough Apple devices to be an unpaid tester year round. Thus, verifying issues in betas is a hassle for me. I’ve been burned by such requests in the past, asked by Apple to verify issues in betas that were not fixed, so I asked Apple directly whether beta 4 fixed the bug: they should already know, since they have my steps to reproduce! However, their response was evasive, never directly answering my question. Moreover, they threatened to close my bug report and assume the bug is fixed if I didn’t verify within two weeks! Again, this is after Apple silently sat on my bug report for three years.
Although I didn’t install the beta myself, I spoke to the developers of Little Snitch, who do run the macOS betas, and they kindly informed me that in their testing, they could still reproduce my issue with macOS 26.4 beta 4. It was no surprise, then, that when I updated to macOS 26.4, released to the public yesterday by Apple, I could still reproduce the bug with my instructions and example project. It appears that Apple knowingly sent me on a wild goose chase, demanding that I “verify” a bug they did nothing to fix, perhaps praying that the bug had magically disappeared on its own, with no effort from Apple.
By the way, a few weeks ago I published a blog post about another bug, FB22057274 “Pinned tabs: slow-loading target=“_blank” links appear in the wrong tab,” which is also 100% reproducible but nonetheless was marked by Apple with the resolution “Investigation complete - Unable to diagnose with current information.” On March 9, I updated the bug report, asking what additional information Apple needs from me—they never asked for more information—but I’ve yet to receive a response.
I can only assume that some bozos in Apple leadership incentivize underlings to close bug reports, no matter whether the bugs are fixed. Out of sight, out of mind. Apple’s internal metrics probably tell them that they have no software quality problem, because the number of open bug reports is kept lower artificially.
Ironically, the iPadOS 26.4 betas introduced a Safari crashing bug that I reported a month ago, but Apple failed to fix the bug before the public release. What’s the purpose of betas? As far as I can tell, the purpose is just to annoy people who file bugs, without doing anything useful.
...
Read the original on lapcatsoftware.com »
ARC-AGI-3 is an interactive reasoning benchmark which challenges AI agents to explore novel environments, acquire goals on the fly, build adaptable world models, and learn continuously.
A 100% score means AI agents can beat every game as efficiently as humans.
Instead of solving static puzzles, agents must learn from experience inside each environment—perceiving what matters, selecting actions, and adapting their strategy without relying on natural-language instructions.
...
Read the original on arcprize.org »
Antimatter is matter’s equal and opposite. If the two meet, they annihilate each other, turning entirely into energy. This makes it incredibly difficult to store or move antimatter.
On 24 March, a team at CERN, the European particle-physics laboratory near Geneva, Switzerland, transported 92 antiprotons in a specially designed bottle that traps the particles using magnetic fields. The bottle travelled on the back of a truck, taking a 30-minute journey around the lab’s site.
The experiment’s ultimate goal is to take the antiparticles to a location free of experimental noise, where antiprotons can be studied with greater precision than is possible in the CERN ‘antimatter factory’ where they are created.
CERN is the only place in the world that produces usable quantities of antiprotons. Many staff members turned out with their mobile-phone cameras to capture the truck as it travelled more than 8 kilometres around the site, reaching a maximum speed of 42 kilometres per hour.
“It is something humanity has never done before, it is historic,” says team member Stefan Ulmer, a physicist at Heinrich Heine University Düsseldorf (HHU) in Germany. “We bought a lot of champagne, and we invited the entire antimatter community to celebrate with us today.”
How to transport antimatter — stick it on the back of a van
Antimatter can be used to study other phenomena, such as the structure of radioactive nuclei, or researched itself to unravel some of the Universe’s deepest mysteries. Physicists who created the antimatter factory more than 30 years ago dreamed that someday it might be possible to transport the material, says Christian Smorra, a physicist at the HHU who led the project. “Now it’s finally possible.”
“This is a great technological achievement,” says Tara Shears, a physicist at the University of Liverpool, UK. Antimatter is the most fragile type of matter there is, so storing it, let alone driving it around CERN, is “a technological marvel”, she says.
“I love the idea of CERN becoming the Deliveroo [a food-delivery company] of antimatter,” she adds.
Antiparticles are like their ordinary counterparts, except with their charge and magnetic properties reversed. Although matter is abundant, antimatter occurs naturally only very rarely. No one knows why this disparity exists, when both should have been created in equal amounts during the Big Bang.
CERN makes antimatter by colliding beams of protons into a dense metal, then using electric and magnetic fields to slow and capture the antiprotons that emerge. Most particles are lost in the painstaking process.
...
Read the original on www.nature.com »
LLMs are too important to be left to big tech. There is a gap between frontier models and models that can run on your device, but local models improve each day, and once they cross a certain capability threshold, they will be good enough for most purposes; and will come with full privacy and control.
Based on these assumptions, we’ve been working on Ensu, Ente’s offline LLM app. Today is our first release.
In the rest of this post, we’ll explain why we think the assumptions hold, what we’re doing, and how you can get involved.
LLMs are too important to be left to big tech. We’ve written in depth about this earlier, here and here.
Briefly, those posts come at it from two angles:
If you’re someone who hates LLMs, you would still be able to recognize in clearer moments of thought that LLMs are a technology that can’t just be wished away. If you’re someone who finds joy in interacting with LLMs, you would recognize the lack of privacy and the high dependency (arbitrary bans, content shaping, non-portable memory) you have on centralized providers.
And in both cases it is also clear that LLMs can be used to manipulate people en masse. Ergo, we can’t be at the mercy of big tech controlling them.
The issue is that there is a capability gap between large centralized models and smaller models that can be run offline on your device.
But we’re problem solvers, and this is not our first rodeo. When we first started Ente Photos, it seemed unthinkable that we’d be able to deliver face recognition, person clustering and natural language image search all running locally on your device. People called us crazy.
It took many years, but we did it. Our users enjoy these features every day. Everything is done locally on device, and also synced, end-to-end encrypted, across all your devices. Full privacy, full control, without loss of convenience; technology in service of people, not as a tool of surveillance.
In the same vein, while we have been itching for a long time to do something about local LLMs, it is only recently that smaller models are becoming feasible to run on consumer devices. We now think there are actionable steps we can take.
This is where the second assumption comes in. While smaller decentralized models improve every day, so do the larger centralized models. However, we think the gap is not what is important - instead, it is about a threshold, and about how the model’s capabilities are used. Once smaller models will cross a certain threshold, they will be sufficient to provide joy, utility and convenience in the life of people.
Today we’re releasing Ensu. It is a chatgpt-like app that runs completely on your device with full privacy and zero cost. Soon, you’ll also be able to backup and sync your chats across your devices by connecting your Ente account (or self hosting), with full end-to-end encryption.
This is not the beginning, nor is this the end. This is just a checkpoint.
Ensu is currently an Ente Labs project. For now, we want to only iterate on the product and its direction, without bringing pricing and stability too early into the picture.
Just to set expectations right, it is currently not as powerful as ChatGPT or Claude Code. Still, it is already quite fun! Here are some things we’ve been doing with it:
* Introspecting about thoughts we wouldn’t risk putting into a non-private LLM.
* Talking about books (Ensu currently doesn’t have web search, but you’ll be surprised how well it knows classics like the Gita or the Bible)
* Jabbering with it on flights when there is no internet.
The app is open source, and available for iOS, Android, macOS, Linux and Windows. We also have an experimental web based version. Image attachments are also supported. The core logic is written in Rust, and for each platform we have native (mobile) and Tauri (desktop) apps that use the same shared logic.
We’ve already implemented (optional) E2EE syncing and backups so that you can access your chats across devices. This uses the Ente account you already have, and it can also be self hosted just like Ente Photos. However, at the last minute we decided not to enable sync in the checkpoint we’re releasing today. That’s the story of the next section.
We’re viewing Ensu as a journey. There is a precise destination - a private, personal LLM with encrypted sync - however the path to it is hazy. There are multiple directions we could take:
* Instead of general chat, we shape Ensu to have a more specialized interface, say like a single, never-ending note you keep writing on, while the LLM offers suggestions, critiques, reminders, context, alternatives, viewpoints, quotes. A second brain, if you will.
* A more utilitarian take, say like an Android Launcher, where the LLM is an implementation detail behind an existing interaction that people are already used to.
* Your agent, running on your phone. No setup, no management, no manual backups. An LLM that grows with you, remembers you, your choices, manages your tasks, and has long-term memory and personality.
For now we will just wait a while for feedback before taking the next step. And because these future directions might change the persistence architecture, we’ve delayed enabling sync.
When sync does arrive, your existing local chats will get backed up and sync too.
We would love your feedback. The next steps are unclear, and we want you to influence what we build. Tell us what you want, and we’ll make it. You can write to us at [email protected], or join our Discord and head over to the #ensu channel.
You can download Ensu here.
...
Read the original on ente.com »
Today, we’re announcing an update on how GitHub will use data to deliver more intelligent, context-aware coding assistance. From April 24 onward, interaction data—specifically inputs, outputs, code snippets, and associated context—from Copilot Free, Pro, and Pro+ users will be used to train and improve our AI models unless they opt out. Copilot Business and Copilot Enterprise users are not affected by this update.
Not interested? Opt out in settings under “Privacy.” If you previously opted out of the setting allowing GitHub to collect this data for product improvements, your preference has been retained—your choice is preserved, and your data will not be used for training unless you opt in.
This approach aligns with established industry practices and will improve model performance for all users. By participating, you’ll help our models better understand development workflows, deliver more accurate and secure code pattern suggestions, and improve their ability to help you catch potential bugs before they reach production.
Our initial models were built using a mix of publicly available data and hand-crafted code samples. This past year, we’ve started incorporating interaction data from Microsoft employees and have seen meaningful improvements, including increased acceptance rates in multiple languages.
The improvements we’ve seen by incorporating Microsoft interaction data indicate we can improve model performance for a more diverse range of use cases by training on real-world interaction data. Should you decide to participate in this program, the interaction data we may collect and leverage includes:
Outputs accepted or modified by you
Inputs sent to GitHub Copilot, including code snippets shown to the model
This program does not use:
Interaction data from users who opt out of model training in their Copilot settings
Content from your issues, discussions, or private repositories at rest. We use the phrase “at rest” deliberately because Copilot does process code from private repositories when you are actively using Copilot. This interaction data is required to run the service and could be used for model training unless you opt out.
The data used in this program may be shared with GitHub affiliates, which are companies in our corporate family including Microsoft. This data will not be shared with third-party AI model providers or other independent service providers.
We believe the future of AI-assisted development depends on real-world interaction data from developers like you. It’s why we’re using Microsoft interaction data for model training and will begin using interaction data from GitHub employees as well.
If you choose to help us improve our models with your interaction data, thank you. Your contributions make a meaningful difference in building AI tools that serve the entire developer community. If you prefer not to participate, that’s fine too—you will still be able to take full advantage of the AI features you know and love.
Together, we can continue to build AI that accelerates your workflows and empowers you to build better, more secure software faster than ever.
If you have questions, visit our FAQ and related discussion.
Mario Rodriguez leads the GitHub Product team as Chief Product Officer. His core identity is being a learner and his passion is creating developer tools—so much so that he has spent the last 20 years living that mission in leadership roles across Microsoft and GitHub. Mario most recently oversaw GitHub’s AI strategy and the GitHub Copilot product line, launching and growing Copilot across thousands of organizations and millions of users. Mario spends time outside of GitHub with his wife and two daughters. He also co-chairs and founded a charter school in an effort to progress education in rural regions of the United States.
Everything you need to master GitHub, all in one place.
Build what’s next on GitHub, the place for anyone from anywhere to build anything.
Meet the companies and engineering teams that build with GitHub.
Catch up on the GitHub podcast, a show dedicated to the topics, trends, stories and culture in and around the open source developer community on GitHub.
We do newsletters, tooDiscover tips, technical guides, and best practices in our biweekly newsletter just for devs.
Yes please, I’d like GitHub and affiliates to use my information for personalized communications, targeted advertising and campaign effectiveness. See the GitHub Privacy Statement for more details.
...
Read the original on github.blog »
To add this web app to your iOS home screen tap the share button and select "Add to the Home Screen".
10HN is also available as an iOS App
If you visit 10HN only rarely, check out the the best articles from the past week.
If you like 10HN please leave feedback and share
Visit pancik.com for more.