HN user

fritzy

118 karma

Nathan Fritz @fritzy Twitter

[ my public key: https://keybase.io/fritzy; my proof: https://keybase.io/fritzy/sigs/tPQ3r4AIbdd4z3PjHVslzkuA0bPDA1SBaPPkqSqMUqA ]

Posts3
Comments38
View on HN

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.

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.

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."

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.

I agree. I'm unhappy with the names -- I'm trying to avoid naming things the same as Redis.

A feed is in publish order (not a set). Edited items are brought to the top.

A sorted_feed lets you publish at whatever end/index you want. You can also move items to a different index. Sorted feeds give you reposition events as well.

If nothing else, I'll fix this with documentation for 1.0.