fritzy

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 did a web remake of the old DOS re-imagining of SpaceWar a few years back as an exercise. https://spacewar.pro https://github.com/fritzy/spacewar.pro

It's kind of fun watching the AI fight each other if nothing else.

Ultima Online 2

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.

I made a HTML5 version based on the DOS spacewar.exe as an exercise at https://spacewar.pro

OP's game hasn't flopped. The beta just launched yesterday and appears to be trending on steam and itch.

In reality, everyone works together to make sure the project is successful throughout its lifespan. It's not usually a hand-off.

I, the OP, am a starter myself. I was focused on finishers because they're often undervalued.

`table -> trigger to log table -> trigger to notify` is exactly the right solution here. You can even use the same stored proc to replay old logs.

I should submit https://spacewar.pro as a clone of DOS SPACEWAR

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.

Step one: Enable Linux Subsystem for Windows

Step two: Install "Bash for Windows aka Ubuntu root"

Step three: compile as normal

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.

You're right there. This was a naive stab at it that I hadn't properly thought through. I'll try to update the post this weekend.

The skills don't seem to be a stretch. Basically a devops guy that used to be a full stack guy.

The roadmap being, basically stay away from commercial encryption software. Don't trust hardware that you can't see. Worry about secure routers as much as worrying about secure endpoints. Shouldn't that have been obvious?

This may be related. https://twitter.com/fritzy/status/367532797356826624

I found it odd (not wrong, just unusual) that an open source project would purchase ad promotions like promoted tweets, rather than the company itself. This may be a move to make things like this less awkward.

The pairing of the statement about Snowden with an inquiry into government sponsored hacking is telling about their attitude and reasons for not being super cooperative.

So very amused by this!

All coffeescript all the time! I guess you can't expect much else from a ruby group.

Yeah, the html5audio option doesn't seem to work in Firefox with Flash disabled.

Howdy Zac! yeah, it's basically fallen out of our evolved scrumlike process. We'll likely add more features and polish in that direction.

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.