Interesting! Looks like a race condition (with a 1ms window) during squawk allocation (the process that gives each aircraft a 4 digit identifier for ATC purposes) caused data corruption. They present that window as being small but 1ms is a decent chunk of time in our work lol
More specifically: it sounds like something which was supposed to be an atomic operation was split into two by the preempting task, with corruption happening because that task also interacted with the same piece of (now-temporarily-invalid) data.
But we're talking about a system that is also older than most people.
It was first put into operation in 1967 in the U.S.A., and brought over to the U.K. in 1974. It's formally called 'NAS En Route Stage A', and is written in a 1950s language named JOVIAL. It originally ran on an IBM 9020. It runs on IBM 9020 compatible systems today.
For some reason, a couple of years ago someone added a lengthy unverifiable description of it to Wikipedia's IBM 9020 article, even though that very description said that NAS hadn't run on a 9020 for 34 years at the time of writing, but had been running on a 4381.
I agree that devices should work independently. But I believe the fundamental baseline should be open interoperability. Yes, the dishwasher should allow a delayed start from the machine itself. But it should also have secure yet open interoperability so other authorised systems that care about the dishwasher can interact with it. I think there's ultimately a user experience benefit. I'm familiar with my phone, its UI paradigms etc. If I (or my gran) can use the dishwasher through an interface or voice assistant we're already familiar with then that's a win. Especially if the form factor of the device itself makes it challenging to deliver a great and intuitive interface in-situ.
In this regard CarPlay is evidence of success - a sufficiently interoperable car that allows users to bring their own context and ecosystems.
CarPlay is only evidence of failure if your expectation is that the car should provide a comparable ecosystem to Android or iOS - one that must also somehow follow you in your pocket when you leave the car.
This is a good point, but CarPlay is not open interoperability. Open is DisplayPort. Open is 3.5mm jack. Open is Bluetooth.
The car has two proprietary tie-ins to two dominant mobile operating systems. That’s another reason this feels like failure to me. If the car had some standard way to hook a device to it to use touch screen and output sound, I might like that.
Instead my car (2016 Honda Accord) eliminated the standard 3.5mm jack and added a janky CarPlay implementation that sometimes freezes up entirely, and there’s no way to update it. This is not progress.
I've always been interested in the concept of using the filesystem more thoroughly like this, but sometimes I wonder about the value of it, and if pulling on that thread could get us something even more interesting.
The S3 call is tooling over an already lower level operation - an HTTP PUT request. The function tooling is added /because/ it makes it easier to call correctly. You could choose to use the underlying HTTP request directly if you wanted to. The function approach may add type safety and additional client-side validation/logic that can't be expressed in the underlying API (HTTP or FS).
In some ways we can think about the FS as an RPC mechanism with service/resource discovery (LIST operations) and a fixed/limited set of functions (READ, WRITE, SEEK, etc). Perhaps a more interesting 'universal interface' would be a broadly supported RPC mechanism with the FS operations as an adoptable interface that any given resource could support. That way an S3 implementation could choose to implement the FS interface if it wanted to, and an AI agent could discover the additional functionality offered by the other interfaces it supports. Probably a pipedream .
This is core to plan9's "everything is a filesystem", a generalisation of Unix "everything is a file" and surprisingly a direct analog of Sun Spring OS RPC+Namespace model
No exactly! You’re describing a microkernel and a bunch of userspace servers. Look into Fuschia, Mach, or Android’s Binder if you’re interested it this
Because adding types adds constraints across the codebase that detect a broader set of mistakes. It's like saying what's the point of putting seatbelts into a car if they only work when you're wearing them - yes you can use them wrong (perhaps even unknowingly), but the overall benefit is much greater. On balance I find that TypeScript gives me huge benefit.
No tool is perfect. What matters is if a tool is useful. I've found TypeScript to be incredibly useful. Is it possible to construct code that leads to runtime type errors? Yes. Does it go a long way towards reducing runtime type errors? Also yes.
> No tool is perfect. What matters is if a tool is useful
Some tools are more perfect and more useful than others.
Typescript's type system is very powerful, but without strict compile-time enforcement you still spend a lot of effort on validating runtime weirdness (that the compiler ought to be able to enforce).
Yes that's true, but there's effort to consider on both sides of design decisions like those TypeScript has made. Much of the compile time behaviour comes from the decision for TypeScript to be incremental on top of JavaScript. That allows you to start getting the benefit of TS without the effort of having to rewrite your entire codebase, for example. Having used TS for many years now I feel that the balance it strikes is incredibly productive. Maybe for other folks/projects the tradeoff is different - but for me I would hate going back to plain JS, and there's no alternative available with such tight integration with the rest of the web ecosystem.
Have you seen ReScript? Of course it is not as popular as typescript but it improves on all the bad parts of typescript. You'll get sound types with the pain points of javascript stripped out. Because it compiles to readable javascript you are still in the npm ecosystem.
You don't have to rewrite your whole codebase to start using it. It grows horizontally (you add typed files along the way) compared to typescript which grows vertically (you enable it with Any types).
The point is that we don't have to move back to plain js. We have learned a lot since typescript was created and I think the time has come to slowly move to a better language (and ReScript feels the most like Javascript in that regard).
> Typescript's type system is very powerful, but without strict compile-time enforcement you still spend a lot of effort on validating runtime weirdness (that the compiler ought to be able to enforce).
That's something that you own and control, though. Just because TypeScript allows developers to gently onboard static type checking by disabling or watering down checks, that does not mean TypeScipt is the reason you spend time validating your own bugs.
> Just because TypeScript allows developers... does not mean TypeScipt is the reason you spend time validating your own bugs
Unfortunately, taking an ecosystem-wide view, it means exactly that. If one of my dependencies hasn't provided type stubs, or has provided stubs, but then violated their own type signatures in some way, I'm on the hook for the outputs not matching the type annotations.
In a strict language, The compiler would assert that the dependency's declared types matched their code, and I'd only be on the hook for type violations in my own code.
I wonder if there's a correlation here with new versions of iOS being released around the same time as new phones? Is it possible that OS optimization takes a back seat to bug fixes during the run up to release then subsequent point releases improve performance?
That's been my experience, using iPhones primarily since the 6s.
The .0 releases of iOS have been getting worse lately and are not great, but usually by .2 or .3 it's fine if not better on the older devices.
I think the annual release schedule is too much for Apple to the point that now the .0 release is effectively a public beta. Especially if there are any big changes. iOS 26 RC is laggy on my 16 Pro Max, which without a doubt can absolutely handle it, it's just a buggy mess still. I'm sure that by .2 it'll be fine.
I'd argue that TNG embodies your guess in many ways - many of the corridor and living area sets look like relatively normal, comfortable spaces. The computer is exactly that sublime technology - it's there when they need it (through a wake word) but otherwise completely invisible.
True, although I’d argue that the relative normalness is probably also a necessity due to TNG being a very long-running show, where you cannot devise bespoke design for every episode in an economical way.
Yet, I still find the textured blinky walls very immersion-breaking, for their artificial appearance. It’s nit-picking for sure; TNG did an amazing job at creating an interesting universe.
I’d just wish for some actually bold yet believable vision of the future.
I don't see anything in the parent comments referencing or advocating for 0% tolerance speed enforcement. In the UK speed limits are typically enforced with a 10% grace factor.
Instead, there's a push to reduce limits ever closer to zero.
30mph was close to the sweet spot and had been for decades. Or it would have been with a reasonable level of enforcement.
But as the ideological and/or climate-driven war on cars ramped up there's been a big push to reduce ever-more areas to 20mph, which is just too slow, especially when deployed widely/indiscriminately as it has been in Wales. (Used very sparingly, e.g. outside schools, 20mph limits were a good 'take particular care' signal to motorists - but that effect is lost when they're widespread)
Is it really about safety or is it about 'fuck cars'?
If you look at outcomes, 50km/h (30mph) is much less safe than 30km/h (20mph). If you look at the physics, that’s not surprising - stopping distances increase super linear. At the point where a 30km/h car would have come to a stop, a 50km/h car still impacts with 30km/h.
On the other hand, average speeds in populated areas usually are way lower than 30km/h, so lowering the top speed to 30km has negligible effect on travel times.
If you consider 50km/h the sweet spot, you prioritize vehicle speed over the very real risk of bodily harm for all other traffic participants.
> At the point where a 30km/h car would have come to a stop, a 50km/h car still impacts with 30km/h.
At that point it's barely superlinear. That means instead of dropping by 30kph it dropped 20kph.
Personally I'd focus more on how even a linear increase in stopping distance is a problem when pedestrians are around.
> On the other hand, average speeds in populated areas usually are way lower than 30km/h, so lowering the top speed to 30km has negligible effect on travel times.
Negligible speed impact also means negligible safety impact.
Hey all! My team and I have been working on a fully integrated AI assistant for our Mattercraft tool. It's a 3D development environment for web content - our aim is to find an efficient and expressive intersection between the development experiences of game engines, and those of frontend web development.
The AI assistant is a fully integrated 'Cursor-style' workflow that gets the benefit of additional knowledge and context that Mattercraft has about your project. Would love to get folks' thoughts!
While Mattercraft itself is already general release, we're launching the AI assistant in a beta. If you'd like to try just drop me a line at connell <AT> zappar.com.
reply