Protestware is fascinating. It exposes that corporations depend on developers with no formal or informal relationship. It's also like that Daffy Duck cartoon where he performs a magic trick he can only do once -- you can get your message out or cause some damage, but after that, no one will use your tools anymore.
SteamOS is only going to support other hardware by coincidence. Valve is unlikely to put in resources beyond the hardware that they want to support. It's also unlikely to change the whole "firmware restore, entire drive" approach. They're not going to put in the resources or support work into making and maintaining a full distro by themselves.
A community distro (be it a console-like gaming focused distro or not) is going to be the way to be the way to go for the foreseeable future. I'm pretty happy with running EndeavorOS w/ KDE, Steam, and Heroic. The Steam client with Proton is where most of the magic happens in Linux anyway. If I wanted to get fancy, I could set up GameScope with Steam Big Picture to take a SteamOS/Bazzite approach.
There's similar projects like QB64 and L-Basic. I have to wonder if keeping language variants alive will be of historic significance hundreds of years from now. Will anyone care about early computing to this extent?
I haven't had Firefox crash in years, and I use nightly for all of my day-to-day browsing. Chrome crashes or locks whenever I iterate on a canvas based game after some amount of refreshes.
This post doesn't reject limit, offset -- it's just that you shouldn't use it if your data is very deep or if you need hard consistency. It's nice that you live in a world where this stuff doesn't matter though. Congrats on not having these requirements.
I imagine the render task tree also has to determine which intermediate textures to keep in the texture cache, and which ones will likely need to be redone in the next frame. That kind of optimization has to be tricky.
It seems strange that they would claim that Python's libuv based event loop is twice as fast as Node.js's libuv based event loop. There's some context missing to that statement or it's flat out false.
We in the XMPP community work hard to make "Jabber" secure. Forward secrecy, federation and client scoring, carefully constructed extensions. But without end-to-end encryption like PGP or something, you're open to attack. There are some really neat specs that work on making this more transparent and better, but yes, you can't just blindly use someone else's service and go "it's secure."
Both of these articles fail to mention that as of Postgres 9.5, you can use logical replication rather than WAL. This is why Amazon's RDS now supports multi-region slaving with Postgres.
According to the feature-set, this is basically NeoVIM.
* Separation into front-end and back-end: NeoVIM does this. The UI uses the same interface a plugin does.
* Asynchronous operations: NeoVIM uses libuv to do this (same asynchronous C++ lib as NodeJS).
* Plug-ins over scripting: Yup, NeoVIM does this, as well as dropping vimscript (although it will compile vimscript into Lua for you).
* JSON: NeoVIM uses msgpack, which is significantly less overhead than JSON, but structure compatible.
The two other features listed are Rust and rope-structures, which are implimentation specifics that don't affect users or plugin writers at all.
Edit: The more the merrier! And it's good to see more projects using Rust, but I don't see this as a strong need. See https://github.com/rogual/neovim-dot-app for a nice native Mac UI plugin/client for neovim.