loo

This must be why after 45 years make still has no "list targets" option.

The gap in this workflow is you have to go out of your way to get a diff. Never mind a diff of what's actually in the .gem. Glancing at changelogs on GitHub only reviews changes from good actors.

In practice most of us just update, often with live reload running, and move on.

We need mandatory peer review of updates before they're distributed in the first place.

python2 -> python3 was just a handful of things like that.

Oh no, you see he isn't responsible, it's everyone else! /s

> When is/was HTTP ever really extended?

https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

Only a few of those existed in the 1.0 spec. The rest evolved in practice. You can add your own without asking anyone else. Libraries don't have to be changed. Your payloads are your business. Encodings are flexible and negotiable.

> i think HTTP only really won because of those.

It's proven to be a predictable, stable, extensible, compatible, generic information exchange protocol. If it's won, it's because of that.

You don't just have to trust the package, but all of its transitive dependencies as well.

Node apps should be developed in isolated containers or VMs.

We need peer review of every update, imo.

Starting to think checking node_modules into an app repo, so you get update diffs, is sane.

Nicely executed. Showing other people's results while you wait is great. What's your throughput? (images/sec)

The music on that documentary tripped me the fuck out. Amazing series.

Ha, hearing the word "process" in Wolfram's voice, there.

It has better performance and UI than Element, for my money.

You probably have more people contributing on Discord than you'd have just on Github. Maybe 2, 3 or more times as many.

Discord tends to be social in a way Github is not, with lower friction to contribute. And perhaps even a better asynchronous model.

I don't discount your frustrations. Maybe a bot that can create GH issues from Discord would help. With rights to use it spread liberally around the community.

Tell people you need help getting data into Github, give them a bot so they don't have to context switch, and they'll probably surprise you.

I know the 'server' term smells bad to anyone who knows better.

But to me, the encouragement to explore / read conversations you may have no interest in is a good thing. Just like forums.

The alternative experience on IRC can be stifling. People really do atomize their conversations there. And often avoid chatting from fear of stepping on someone's disinterested toes, or going even slightly off topic.

At least on Discord, ~everyone in a server is present in all of the channels.

So relocating a topic isn't "switch to a room with hardly anyone in it". It's more like a category move on a forum.

Getting people to join in a new channel on IRC is like pulling calcified teeth!

I've been pleased with the DragonRuby Game Toolkit 'server', which has 12 channels in a category called 'Open Spaces' named after various video game characters.

The community uses them freely and naturally. It gives a means to talk about a niche / ad-hoc stuff without stepping on anyone's toes.

If you have a project going, you can effectively claim one of the unused channels for a while by simply posting in it.

Because everyone is present without explicitly joining, the conversations are more discoverable and inviting, without having to nag anyone to do anything.

With you in my heart, always,

loo

If your comment doesn't exist, how can we read it?

I saw this one misreported as 22 minutes in Firefox and Discord. Only 1:43 ? in reality https://www.youtube.com/watch?v=RerbrfVd1nI

> Herbie Hancock on Miles: Don't play the butter notes!

Yes. Some reaching the Primary box.

> As it also point out, CAP theorem doesn't really account for eventual consistency well.

Consistency is the first letter. Systems can be eventually available or eventually non-partitioned too.

You can promote two of the 'eventually's to 'now'. It ejects the other tautologically.

Jo sends $100 from Bank A to Alice at Bank B, then Bob sends $100 from Bank B to Jo. The banks will have no USD to settle at clearing as a result.

Did Jo and Alice participate in a USD transaction?

You're missing that there doesn't need to be a SaaS server side.

HTTP is simply the delivery mechanism for a self-contained WASM application. Just like it is the delivery mechanism for most native binaries now.

They are porting the codebase to WebAssembly, not developing a Google Docs type SaaS product.

It shouldn't be difficult to see that GIMP and LibreOffice can run on this runtime with similar privacy.

We typically download native executables over HTTP. Then check for application updates over HTTP.

Privacy respecting WASM apps can do the same.

This is the new Java, not the new SaaS.

Most of those SaaS have native mobile apps which track you, too. The runtime is not to blame. FOSS applications could be delivered with near-instant load times, native feel and excellent sandboxing, with one universal build target.

That is a remarkable ability.

Do not let the crimes of Web 3.0 blind you to this.

Tracking and disrespect for privacy are utterly orthogonal.

The web can function as a fully offline application runtime.

Desktop applications can track your every click with HTTP requests to their server.

The runtime does not determine this.

This is not true. LibreOffice is being ported to the web, for example

https://wiki.documentfoundation.org/Development/WASM

This argument applied similarly for IE6.

Like IE6, Safari is not a normative subset of web standards.

The realization still has an ideal identity, an "address" in the graph.

The steps it can take from that point may still exist Platonically.