xvilka

It would make sense to implement it in QEMU instead. There was some previous work in the past, don't have a link right now to the original patchseries, but here is the repository[1]. In theory, it could be adapted to the modern QEMU code infrastructure and APIs and be a good starting point. Back in the past I started[2] doing that but quickly dropped because had no time to finish.

EDIT: It looks like it might be this one: https://github.com/syunnPC/qemu-system-ia64

[1] https://github.com/pvaibhav/qemu-ia64

[2] https://github.com/XVilka/qemu-ia64/branches/all

Looks like layout/format of this PDF is heavily broken - line overflows and out of the context/layout line at the end...

I wrote "better typed", not just "typed".

CommonLisp really should evolve to update the language up to the modern standards and become more functional and better typed.

"reconciling" is the most annoying one, in my opinion.

compiling Rust programs for platforms not supported by LLVM

For this, gcc-rs[1][2] is the most promising candidate.

[1] https://rust-gcc.github.io/

[2] https://github.com/Rust-GCC/gccrs

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.

[1] https://www.youtube.com/watch?v=hmtQPrH-gC4

Looks great, but the passage about Google CEO is unnecessary in such guide, IMHO. Even if it might be true.

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.

For this, I believe, working with the mainline is more promising path, at least to reduce the amount of changes needed[1].

[1] https://gitlab.com/qemu-project/qemu/-/work_items/1896

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.

[1] https://www.qemu.org/docs/master/devel/tcg-plugins.html

[2] https://gitlab.com/qemu-project/qemu/-/tree/master/contrib/p...

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.

[1] https://github.com/seL4/seL4/issues/1199

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.

[1] https://www.ginkgo.bio/autonomous-lab

[2] https://www.emeraldcloudlab.com/

[3] https://www.kebotix.com/

[4] https://www.chemify.io/

[5] https://arxiv.org/abs/2507.01485

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.

[1] https://www.youtube.com/watch?v=n-gYFcVx-8Y

For self-hosted version as well, unless you patch it.

It doesn't have these pesky message and user limits, unlike Mattermost[1].

[1] https://github.com/mattermost/mattermost/issues/34271

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.

I am surprised you don't use RustChat[1]

[1] https://rustchat.io/

There is some CI service in Radicle but it's still very barebones[1].

[1] https://radicle.network/nodes/seed.radicle.dev/rad:z3qg5TKmN...

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.

[1] https://codeberg.org/forgejo-contrib/federation/src/branch/m...

[2] https://liberapay.com/forgejo

[3] https://donate.codeberg.org/

[4] https://radicle.dev/

[5] https://radicle.network/nodes/seed.radicle.dev

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.

[1] https://www.traviscistatus.com/history

All the more reason to donate to Forgejo/Codeberg[1][2] or contribute the code to SourceHut[3].

[1] https://liberapay.com/forgejo

[2] https://donate.codeberg.org/

[3] https://sr.ht/~sircmpwn/sourcehut/

Loosely related is the exoplanets catalog (open source)[1][2].

[1] https://exodata.space/

[2] https://github.com/oiwn/exoplanets-catalog

And Azure still doesn't support IPv6, looking at the GitHub[1].

[1] https://github.com/orgs/community/discussions/10539

Rizin[1][2] does exactly this, also there is a compact hex-II[3] mode.

[1] https://rizin.re

[2] https://github.com/rizinorg/rizin

[3] https://speakerdeck.com/ange/no-more-dumb-hex

Zellij still can't hide/show the status bar on the fly[1] and doesn't support windows preview in the windows list mode. Just these two (and many more) things are enough to stop me from migrating from tmux.

[1] https://github.com/zellij-org/zellij/issues/694