My question is, why is driving by sight with speed limited (40 kmh afaik) not something that is enforced by the train itself when there is no connection to the other controls systems. How is that not a hard limit instead of something the train operator needs to remember?
Just inferring from GP, it sounds like the line was in an illegal/invalid state. Couple others are pointing out that the newer LZB system have much smaller block sizes than ASFA system it fell back to. Which means there were likely multiple trains under different LZB blocks occupying same ASFA blocks. That is a crash state, and train safety systems aren't designed to offer safe and normal operation of two already-crashed-on-paper trains.
What they needed to do was to move ALL trains around until the initial state is in a valid configuration under the ASFA system. Probably like moving one train at a time at <40kph so that there is minimum one ASFA block, which might be tens of miles or however long they are, between every single trains on the line. Then the whole operation could be switched to ASFA system at full speed at much reduced capacity. It also means the train more or less wouldn't be moving for the rest of the day. Not only passengers would be angry but there will inevitably few that needs to be hospitalized for things like mild dehydration and sometimes small injuries if they needed to be evacuated.
What likely happened was that they didn't think about any of that at all, and just hot rebooted into the ASFA system without deconflicting anything. The ASFA system signaled ok to proceed to all trains sharing the same ASFA blocks to their next vacant blocks, not knowing that some of blocks were occupied by multiple trains before humans put it online, which would be an out-of-question horrifying hypothetical to the ASFA computers. And when the system ordered a train in the block to stop because a block in front was occupied, there were in fact two trains in that block, one still driving towards the one in front at 160kph, far away from the stop signal, and two collided.
> Probably like moving one train at a time at <40kph so that there is minimum one ASFA block
If you tell the drivers to move by sight (also <40km/h), you can tell them to all move at the same time, because "by sight" means that the drivers themself can observe objects in their track. They essentially start to move like cars on the road, which they normally don't. Normally a driver does not have an obligation to verify that it is safe to drive somewhere, but then they do. It does not mean that the trains actually move at 40km/h, they can move at 1km/h if that what is required in order to move the train by sight. 40km/h is just the maximum after which it is deemed unsafe to move a train by sight even in the best sight conditions.
> Not only passengers would be angry [...]
I doubt that was even a consideration, that would mean that they would have been aware they ordered a collision, but rather:
> What likely happened was that they didn't think about any of that at all [...]
Note, that in a similar fashion as I stated in another comment (https://news.ycombinator.com/item?id=50299422), if you compare the speeds using friction, 40km/h on a train is equivalent to 300-400 km/h with a car on the road.
The thing that is enforced by the train when LZB goes down, is that the train stops. This seems to have worked correctly. Bringing a train from a stop to movement again is a potentially unsafe situation, and the situation is that the automatic system can't get movement authorities, so no safe system is going to do that automatically.
b) In a point based train control system, communication only happens at specific points. That's why it is called this way. On it's own it is safe, because in order to do anything non safe, like passing a red signal, you need to pass such a point. In order to violate a speed limit, you would need to pass the start of the speed limit, which also is such a point.
If you operate a line based control system, you are constantly making collisions from the view of the point based control system. The moment the line based system breaks down, the point based control system takes over and the only safe choice to do in the case of a collision is to immediately stop all trains. That's exactly what it did.
ATCs will have outages or drops all the time. you don't want a train to suddenly lurch down to 40 kph because of a blip. cellular coverage in Europe is pretty good but not perfect -- and it's an even bigger problem in N America.
likewise you're not going to be using Automatic Train Control in yards, sidings, or terminals, and you may need to get up to speed sometimes to move across a big yard.
manual mode lets the conductors and traffic controllers make those calls.
and it's "not something they need to remember" -- it's 40 kph or whatever the track is authorized for under ATC.
Train control in Europe doesn't really use wireless communication. Emergency calls do happen over radio, and a movement authority could be transmitted, but the continuing enforcing does not. Also I am not aware of there being ATC in general railway in Europe.
But if you replace ATC with train control in general, then yes, I agree.
Not quite. My C++ Linux rewrite is already production ready, meaning in theory I no longer need to rely on the Linux kernel devs. This will, in a matter of months I presume, become the norm.
I also want to see the known abstraction skills of LLM used to properly recognize where the objective nature of C++ makes most sense in Kernel code. All the new interfaces, polymorphism.
IMO, an agentic operating system should be not only about "integrating the agent everywhere" but also about providing the compartimentalization and tools to allow working safely with agents when they can reach into every part of the system. It should allow to easily extend the system safely.
I also built an agentic OS but the underlying system is very different based on a custom actor runtime with capabilities and a way to arbitrarily create and compose restricted capabilities.
The idea is that you can sculpt the OS to your needs using agents and fully restrict what they can or can't do.
The core is also I think kind of interesting because at it's core it's an actor runtime, where each program receives and sends messages, and only when processing a message they use memory. Each program has managed persistent state as well. So it's very easy to create actors that persist data and you can have millions of them without using a lot of resources.
> IMO, an agentic operating system should be not only about "integrating the agent everywhere" but also about providing the compartimentalization and tools to allow working safely with agents when they can reach into every part of the system. It should allow to easily extend the system safely.
Right, but that's also a contradiction. An "agentic" OS is most interesting to the average AI enthusiast if it can, essentially, be your executive assistant: shop for you, book travel for you, manage your agenda, sort through your emails, do your taxes, and so on - possibly including anticipating your needs before you articulate them. That requires human-equivalent access, more or less.
Most people also don't need it - really, most lives are not that complicated - but the allure of your own computerized EA is undeniable. It's your personal servant, how cool is that.
The safe and principled way to use agents is to scope permissions appropriately, restrict them to narrowly-defined tasks, etc, but that also makes the technology a lot more boring. And these silos are very difficult to build when you're interacting with third-party services anyway.
You could as well argue that vibecoding is wrong and that there are principled ways to use agents for precisely-scoped, restricted tasks. Sure, but the entire SF Bay Area is vibecoding now, and if something breaks or gets hacked, that's just the cost of business.
I disagree they are fundamentally at odds. The design I'm exploring with capabilities means that if you want you can do all of those things, but you can also scope them. An actor can create another actor and pass the capability or restrict it further. Imagine something like codemode with capabilities, where you want your agent to be able to shop for you. You ask your OS agent, it creates a couple different actors, one maybe manages your money, with limits you can set. Only that actor can do that. Another gets a restricted HTTP client only for those shops you whitelist.
Then a third is an agentic actor that gets access to those other two. That one then has access to two things:
* HTTP requests to specific websites
* A limited way to use money
Since you can compose the primitives to limit the impact of any agent doing stupid shit you can trust it more to shop for you or book travel for you.
Of course it's more friction, but you can also choose how involved are you. You can potentially trust your coding agent to do most of it and once done everything that can be deterministic is deterministic, and only agents come in for the non-determinism and adaptability.
As the system evolve you have a library of actors that act as restricted capabilities, and an agent cannot create them out of thin air.
I have been experimenting with agents inside the application itself as it's being developed. The application has a harness and then that harness can self-evolve and evolve/introspect the application.
There are no competitors because USA doesn't need a competitor since it already owns most of the technology and is merely licensing it to ASML for production. The EUV light source itself is entirely researched, developed, and produced in California, for instance.
The EUV LLC research was US-funded, agreed. But the light source is Cymer, which ASML has owned since 2013. Its drive laser is Trumpf (Germany), and the optics are Zeiss (Germany). Nikon and Canon had access to the same public research and dropped EUV. The US had GCA, Perkin-Elmer and SVG, and lost the market anyway. If integration were the easy part, someone else would have done it. You are underselling what it means to perfect the machines by calling it "just integrating".
By that logic SpaceX is a German company. Liquid-fuel rocketry was researched and developed at Peenemünde, and the US brought in von Braun's team wholesale to build its program. SpaceX just integrates German IP. Or Google is Swiss. The web was invented at CERN; Google is just an integrator of European tech. Or Apple Silicon is British. ARM was designed in Cambridge; Apple just licenses it.
Point one remains. The "solution" appears to come from somebody who thinks its OK to run Claude against a production database.... “wouldn’t it be nice if prod DB writes were easy to roll back”
The point remains that if they ran Claude against a test database they would have found the bug without killing their production database, and therefore also not need to come up with an over-engineered "solution".
Sometimes also the less over-engineered the better. Stuff like PITR and pg_dump is battle-tested and easy to reason about.
reply