It occurs to me that the biggest fallacy the "free market" cult makes is believing that there can ever be a free market in pollution or extraction. It's impossible to fully internalize the externalities of either, which means they will always impact people who have no say in the prices and who receive no compensation.

Even if you think it's possible for a government to approximately internalize externalities, they never even try, which means every "free market" really rests on a set of resources whose price is set by a powerful few. In other words, centrally planned.

The cultists try to make us think the debate is over whether a free market is "good" or "bad", when in fact free markets don't actually exist at all, and they're really just arguing for leaving central planning in the hands of people who will never be held accountable for anything.

At some point, it's fool me twice...

Maybe switch to AGPL projects or something.

https://fosstodon.org/@opensourcepledge/113358154795074627

@aud I suspect the framers would be shocked at the 14th amendment and would have expected us to have had a new constitutional convention rather than a civil war.

The whole concept of originalism makes no sense when you consider that the Constitution wasn't intended to apply to the states. Which makes me suspect that originalists actually want to throw out the 14th amendment. And probably most of the others beyond the Bill of Rights.

@aud The Second Amendment is a very interesting example, because it's been "obsoleted" by both the 14th amendment and the fact that we now have a large, permanent standing army, large reserves, the national guard, and paramilitary police forces. I'm pretty sure it was originally intended to protect the states from the federal government, and that it didn't really occur to the framers that states would try to disarm their own people because that would be disarming *themselves* since they didn't have their own militaries.

There are those who argue that the 14th Amendment makes the Constitution a completely different document by applying it to the states. So that would have been a step change in the entropy of the country.

@aud I'm not sure if anyone has written about it, but I guess the entropy of an organization would be defined as something like how much additional text you need beyond its constitution to describe its behavior, if you wanted it to correspond in some way to corruption. But that could also have a high value for an organization that had a lot of unwritten tradition.

There are also complexity measures, and I can imagine possible definitions for temperature as well, specifically as a measure of dissatisfaction, leading to "evaporation" and "evaporative cooling".

In tech orgs, technical debt may be the best analog to entropy. I imagine all organizations must have equivalents.

@aud I haven't done any macro programming at all. Some of the template stuff. I hate that it looks too much like C++. There are even some false friends, which I think is objectively bad.

@aud Being able to do Zig metaprogramming in Zig is definitely my favorite Zig feature.

@alcinnz We have to be able to actually get there. Right now I'm envisioning using Servo or CEF. Implementing the DOM would be a massive undertaking, as you're well aware, but replacing it as well as all the applications that depend on it actually seems like a much larger undertaking, no matter how much simplification is possible along the way.

I'm looking at this entirely from the user experience angle, which includes application/component developers. People's biggest complaint about the DOM is inconsistent vendor support. But that's actually just a problem for web apps. It's not a problem with a local app for which you control the whole runtime.

If some alternative starts to coalesce and an ecosystem starts growing around it, I'll be all over that. But for now my plan is for the rendering stack to be mostly off the shelf. I know that's a bit surprising since I've spent a lot of time talking about rendering, but one of the things I realized over the course of that thought experiment (along with some code) is that it can only do anything to meaningfully improve the user experience as part of a much larger project.

One of the principles I'm hoping this can maintain is that individual parts of the stack should be able to be swapped out. So I'd definitely like to see the DOM eventually implemented on top of something better and then someday dropped entirely.

@smallcircles

@alcinnz We need to keep the DOM around to render web pages with JS that uses it, but nothing stops us from implementing it as a translation layer on top of a simpler API.

One challenge with WebGPU is that (I think) you just get a canvas. For component-based UIs we'd need more flexibility. Which could just be rendering to a transparent texture that then gets rendered as part of another element.

Mainly I don't want to be stuck with WIMP, but I could be persuaded it's not the long pole right now.

@smallcircles

@alcinnz He's vague about specifically how it's failed, though. Browsers' lacking a UI for alternate stylesheets seems like a chicken & egg problem that's easily fixable.

There were at least a couple of different attempts to make HTML/CSS/JS based mobile OSes: WebOS and the one Cory Ondrejka led at Facebook. Both failed because web apps couldn't be made responsive enough on a mobile processor at the time. But because the mobile device companies make so much money on distributing native mobile apps, there's no longer any incentive to advance the state of the web apps. Imagine if all the effort going toward "AI" went toward making web apps responsive on phones?

iOS is a lost cause, but I don't think anything stops us from turning, say, Vanadium into an awesome mobile app runtime. Though I think we should be looking to 5-10 years in the future, so as
@smallcircles said maybe Servo is the right renderer to be targeting?

@smallcircles Vscode in the browser is definitely a force to be reckoned with/coöpted.

Git's learning curve leaves a lot to be desired. I think its internal complexity might be too high compared to something like Pijul, but I don't know. We need to build on what we have and evolve the system rather than trying to build something from scratch, or we'll be stuck in Xanadu.

I do think version control should be built into the development environment, and it should understand the semantics of the language. This becomes especially necessary when you start getting into visual languages where the user isn't expected to understand the serialization of a program, UI element, etc.

@alcinnz

I also find Godot super interesting, in that it can produce binaries that use WASM and WebGPU to run in a browser without needing the developer to actually be able to write code.

My vision is something that encompasses the whole lifecycle from end-to-end: a development environment like Godot or Electron that lets people make programs, a runtime/container like Electron that instead of being included with every application instead can load its own package format. And some kind of distribution system for discovering and shipping packages.

On top of this we build our "component-based interface". Which will require a different security model than the Web currently uses, though we'll probably still use iframes and web workers for isolation.

We also need a way of storing data both locally and in arbitrary remote storage services. Preferably with standardized formats and transcoders for sharing common bits of information like contacts, calendar events, pictures and movies, etc.

5/5 for now. Discussion and feedback welcome! Except for complaints about Electron. Or toxic minimalism.

And now to the thing that triggered this epiphany for me: this thread with @joepie91 I link to the end instead of the beginning, because I think it's the important bit and I'm not sure how much of the thread others will be able to see if they don't follow joepie91.

Sven Slootweg (@[email protected])

Content warning: personal venting

Pixietown (social.pixie.town)

Electron is probably the most spot-on example of this "embrace and extend" strategy. They're taking work that's already being done by the CEF project and using it to make a desktop application framework that gives developers access to all the "web technologies" they know and love, without having to implement a new browser from scratch.

Please read that whole thread before complaining about Electron. And then still don't complain about Electron to me.

4/n

The right way to avoid this nightmare future isn't to try to swim upstream, resisting these tools just because they will be (and are) being abused by capitalism. It's to use all of the tools available to us to build the future WE want.

As @alcinnz pointed out, the thing in common between WASM and WebGPU is that they're completely crossplatform. I think they're the future because they make it so we don't need to care what CPU or kernel the host uses. They also provide a more robust isolation model than any "raw" OS does. WASM/GC can even support capability-based security.

Instead of trying to fork or replace the Web, we should evolve it. We should embrace and extend the things capitalism produces that serve our purposes.

Microsoft famously invented "embrace and extend" as a strategy for beating FOSS, but my favorite example comes from Mozilla. While Google was struggling to get anyone to adopt NativeClient and Portable NativeClient, Mozilla made it so Spidermonkey could efficiently execute the code being spit out by an experimental C++ to JS compiler called Emscripten, creating AsmJS (I could be getting the exact history wrong, please feel free to correct me but I don't feel like researching it myself).

The advantage of AsmJS over NaCl and PNaCl is that it was part of the JS engine, so it had exactly the same API people already knew for web development. NaCl, on the other hand, used PPAPI, the same API that Chrome plugins used. That made it a lot harder to adopt in another browser and created a steeper learning curve for anyone who didn't already know how to write plugins (again I might have some details wrong; please feel free to correct me).

Eventually Google dropped NaCl and PNaCl in favor of making V8 able to execute AsmJS efficiently. They even did it without writing any AsmJS-specific code, which is pretty impressive. Eventually AsmJS got its own compact represenation very similar to PNaCl (which was based on LLVM bitcode). That dramatically improved loading times, the biggest disadvantage of AsmJS, which compressed well but still decompressed into very "fluffy" source code that the JS engine had to parse.

3/n

I recognized some of the building blocks of the future years ago, in particular WASM and WebGPU. I've hesitated to embrace them because of their dependency on the web and the browser ecosystem, and because of my terror over what I knew capitalism plans to do with them, which is to move us entirely to a subscription-based software model where we have no control at all over our data. The "legacy web" will be replaced with "content-delivery services" that can't be scraped or used in any other way without some kind of business relationship. Which is exactly the direction Reddit and Twitter have gone even without needing WASM for the rendering piece.

2/n

I've been so much time mourning the death of what I saw as the future of computing back in the microcomputer and early PC era, and blaming capitalism, Google, Apple, and the FOSS movement, that I hadn't actually considered the possibility that we'd already seen the future.

We're stuck in these ancient and new battles of Linux vs BSD, GNOME vs KDE, Wayland vs X11 and even systems vs everything else. But none of those matter because they're all the past. It's worse than useless to fight over the best way to copy Apple and Microsoft. We have to leap ahead of them, or we will always be under the thumb of capitalism.

First of all, we need to start from the top, not the bottom. What should the experience of using a computer be like? I don't have the answer, but I know what it shouldn't involve, and that's worrying about all those things I mentioned in the last paragraph.

1/n (feel free to interject whenever)

@mauve I'll have to check that out!

The advantage of Erlang's ports is that they can't crash the node.

And it occurs to me that too minimal a core can lead to "dependency hell", so even if the system is modular like that, there probably still needs to be a standard way to do I/O securely.

There's also the "ActiveX problem" where as soon as an application wants to do something interesting you lose all protection from the sandbox.

When you insist that people don't vote, you're probably trying to suppress voter turnout. So don't do that either.

So when you insist that others vote, what you're saying is that you don't want to accept that you live in a plutocracy. Which makes you part of the problem.

Low voter turnout is a symptom of the belief that one's vote doesn't make a difference. It is not the root cause of bad government. Rather, plutocracy is the cause of both bad government and low voter turnout.