Real neurons are orders of magnitude more complex than their artificial pseudo-approximation (it is all based on the century-old understanding of how neurons work). You can think of _individual_ biological neuron as an analog of the small artificial neural network. You can see this simple visual explanation on YouTube[1]. So we aren't even close. It doesn't mean the AI is impossible, it just means people underestimate the "computing power" of real brains, as well as that AI, even the future one might be totally different in how it works from the natural intelligence.
For QNX/Blackberry it would make sense to opensource Photon since they are not using it anymore. Porting it to the modern QNX and other systems would be great.
The problem is that it's not sustainable - QEMU improved so much since the moment of fork and updating the QEMU code in Unicorn is always done manually. It is especially important for architectures that evolve quickly - ARM64, RISC-V, x86. Meanwhile, QEMU now has the notion of TCG plugins[1] that can read/write registers and memory, which is enough for most cases. You can see many examples of the plugins in contrib/plugins[2] directory of the mainline QEMU - a good starting point.
seL4 despite being formally verified contained gnarly bugs, like [1]. Thus, it's not a silver bullet as some people think. Yes, it improves the quality, but only one of the aspects of hardening software, like ASAN, SAST, fuzzing, strict languages, and so on.
Combine it with automated lab like this[1][2][3][4][5] (and many others) and it will iterate much quicker. Some already do but at a smaller scale, AFAIK.
IIRC TeXmacs supports only quite limited subset of what LaTeX and TeX can do. Just like LyX, it could create new documents but will often fail opening ones that were created outside of it.
I should note, it's still not on par feature-wise compared to TeX ecosystem, but it gets there with incredible speed. As for UX - it beats anything TeX-based ten times over.
I have been using TeX/LaTeX for ages and today same issues hinder the user experience like multiple decades ago - cryptic error messages, complex pipeline, lack of the proper Unicode symbols support out of the box, and so on.
Nowadays, with Typst existing, it's vital for TeX ecosystem to solve these issues, since none of them are present in Typst. Projects like Tectonic would solve this for TeX, but they lack enough hands and (maybe) financial support.
Otherwise, using TeX only makes sense nowadays only if 1) you already have some templates 2) some features are still missing in Typst 3) you are just forced to use TeX/LaTeX for whatever reason.
In the modern world there is no place for the commercial compiler. They should have made it free (and open source) and only IDE (maybe) paid one. Even better - push into GCC or LLVM.
Not directly related, but still reminds me of the recent Kurzgesagt (they are famous for well-researched content and are originally from Germany) video[1] about the bleak future Germany is facing in upcoming decades.
I wish they would make local-only deployment easier. For example, lets take 3 machines and try to setup Radicle to work only on those, without joining the common Radicle network. Like on-premises GitLab, but decentralized, without the need of the server. It requires quite some serious scripting and usecase not covered in the documentation.
The real game changer would be completed Federation[1] support. This is why I am donating both Forgejo[2] and Codeberg[3] and urge everyone doing the same, to give more time and resources for the Forgejo team to implement it properly.
Another good contender is the Radicle[4][5] which is completely decentralized on top of the Git.
> Github is doing some classic big org sneaky things where they don't count degraded service fully.
Even worse example is the Travis CI. For more than a year their CI jobs sometimes get stuck or do not start for days, and, surprise-surprise, it's never shown at their status page[1] - always green. We would switch to something else entirely if not the unique offering of PowerPC and SystemZ servers/runners. Apart from that - it's the worst CI service I used so far.
For this, gcc-rs[1][2] is the most promising candidate.
[1] https://rust-gcc.github.io/
[2] https://github.com/Rust-GCC/gccrs