I agree with this. As someone who took 3 degrees in computer science, one called "systems developer" and another called "software engineer", I can confidently say we have a taxonomy problem in computer science education.
It makes me crazy that companies labels there entire programmer workforce as "software engineers" when there are no engineering concepts involved at all. Other fields (medical, mechanical, civil engineering) are a lot more mature in this area and have solved this issue long ago.
The direct hooking into the narrow phase solver is the most performant way to go about it, but it does present several issues in state management. I did the same thing in Farseer Physics Engine, but also added high level events on bodies[1]. The extra abstraction makes it easier to work with, but due to the nature of delegates in C#, it was also quite a bit slower.
They could do with creating defaults for the narrow phase handler, buffer pool, threat dispatcher, etc. for devs who don't need extreme performance and just want a simple simulation.
The security of the Apple ecosystem is miles ahead of others. Every time I reverse engineer some component of their OS, it is very different from what I've seen before. I always find myself surprised by their thoughtfulness and engineering craft.
Recently I've taken on their code signing component. The concepts they've created, such as identifying applications by their "designated requirements" is a stroke of genius. It makes the system completely stateless and capable of almost anything without auxiliary data structure or additional code.
I've seen other engineering teams try and fail at building something similar, and never with such powerful simplicity.
"In this case, the federal government prohibited us from sharing any information," the company said in a statement. "Now that this method has become public we are updating our transparency reporting to detail these kinds of requests."
“At Apple, we are always working to defend our users against even the most complex cyberattacks. The steps we’re taking today will send a clear message: in a free society, it is unacceptable to weaponise powerful state-sponsored spyware against those who seek to make the world a better place,”
"The app in question is called “LassPass Password Manager” and lists Parvati Patel as the developer. The app attempts to copy our branding and user interface..."
The Pegasus project, an investigation into NSO by the Guardian and other media outlets, coordinated by the French media group Forbidden Stories, has documented dozens of examples in which NSO’s spyware was used to attack users of Apple’s iPhone. In some cases, a vulnerability in the company’s iMessage feature, which could be penetrated by Pegasus, was used against journalists, human rights activists and other members of civil society.
The source is describing an iMessage exploit known as FORCEDENTRY, which can be used to deliver a persistent hardware backdoor (Pegasus) to an iPhone. Often, Apple is unable to detect the persistent exploit and therefore incapable of warning the user that they have a backdoored device: https://9to5mac.com/2025/02/20/apple-currently-only-able-to-...
The condition is called Anosmia and can stem from different sensor and brain conditions. It would be interesting to try the technique on people with these conditions to map the different kinds of olfactory failures.
If you get in contact with the researchers, please let us know how it went.
Please include me also in contacts. I developed anosmia about 8 years ago (well before COVID). I truly wish there were some sort of 'cure' that would restore even a small amount of my sense of smell.
It is also kinda a self-burn. Chromium an aging code base [1]. It is written in a memory unsafe language (C++), calls hundreds of outdated & vulnerable libraries [2] and has hundreds of high severity vulnerabilities [3].
Given Google's resources, I'm a little surprised they having created an LLM that would rewrite Chromium into Go/Rust and replace all the stale libraries.
Taking a bunch of data from the Korean National Health Insurance database and looking for one specific connection is less than helpful. Like carl sagan said: extraordinary claims require extraordinary evidence.
A significant error I often see in cancer studies, is the assumption that after a carcinogenic event (consumption of something toxic, exposure to radiation, etc.) suddenly there is a tumor of such a large size the person notices it and gets it investigated by a medical professional.
Some cancers take years to grow, which means the increase in certain cancer-type rates cannot possibly be explained by a carcinogenic event within a 1-year timescale.
Science is not just about finding relationships in data. You have to justify the claims, argue against them, uncover biases and guarantee the correctness of data. Statistical links are the weakest form of evidence and literally anything can be proven if not graduated through the scientific model.
It looks like a process model; isolation between programs with a system for inter-process communication, and running within a single process's memory.
If I understand correctly, instead of writing a c++ application to offload the computation of something, and then build a way of communicating the result between processes, you create a Space, define it as JIT/AOT, managed/unmanaged and execute it and use the built-in communication for transfering data.
It is an interesting approach. The author should check out Unity's Burst compiler. It takes a chunk of C# code, AOT compile it with LLVM and then the main application can invoke it. The concepts are adjacent.
Even something like Burst is, IMO, not really necessary in modern C#/.NET. It does well in benchmarks but they are almost always comparing Burst vs. normal C# in Unity. Problem is C# in Unity is stuck so far in the past that it makes Burst look amazing when it's usually not that much quicker. So if you are using modern .NET you're not restricted to a subset of C# and get good performance. And if you need even better performance there are plenty of new language features to get you there.
I generally agree. However, there are several important optimizations that Roslyn does not yet have. I love the improvements in newer versions of the compiler as much as the next guy, but historically, waiting 20 years on getting basic inlining, hoisting and SIMD accelerations has left many of us with the only option of not relying on C# for performance.
> It looks like a process model; isolation between programs with a system for inter-process communication, and running within a single process's memory.
Which is better handled by existing mature and simpler abstractions from the actor model, like Akka.net, or maybe Orleans.
For sure, but the author also proposed "unmanaged spaces" which would run in-process but with no GC. This seems to be the main goal and everything else is definitely better handled with existing solutions.
It does but the GC can still stop-the-world pause threads that aren't touching GC memory. The author's proposed isolation would provide a way to avoid that.
I wanted to reply to you directly. I was truly impressed by your comments. You understood the precise, deep technical problem I was aiming at—the GC's 'stop-the-world' pauses affecting even non-GC threads—even from my admittedly clumsy and brief initial post. Thank you for that.
What I failed to convey properly, however, is that this performance mechanism is just one small consequence of a much larger idea. It's a foundational piece of a complete architectural model I've designed to address the fundamental pains of the current microservice paradigm.
I have now finished a full manifesto that lays out this entire vision. It includes a deep critique of our current ecosystem and presents the philosophy for a new style of programming intended to solve these core issues.
Given the depth of your understanding from that first article, I would be genuinely honored to get your critical feedback on the full proposal. If you're interested, the new post and discussion are here:
https://news.ycombinator.com/item?id=45477324
Thanks again for your incredibly insightful comments.
