Sven Slootweg @joepie91@pixie.town

And to be clear: I don't like systemd. I don't like Red Hat.

But you know what I like even less? Janky init constructions and "nobody should ever need more than..." rhetoric.

I am absolutely not going to relitigate long-debunked grievances about systemd in this thread, and if you think such grievances are appropriate in this context, I invite you to read the first post again and *actually* read it this time.

Growing increasingly tired of Logitech's shit wireless dongle reception

Welp. It seems that the reason the birthday paradox has always felt like a confusing concept to me, is because it has a reputation for being counterintuitive (and many explanations try to address that counterintuitive aspect) but it has never actually been counterintuitive for me in the first place so I didn't have that frame of reference, and I was looking for a 'gotcha' that wasn't there...

The Dutch Wikipedia article on it actually explained *why* this is confusing to people, which ironically is what made me realize this 🙃 Turns out it works pretty much just exactly how I expected

Okay! So you want to replace the current web technologies like HTML, CSS, and JS, with something that's less work to implement, because building browsers is too hard. Neat!

But if you're going to do that, here's a few things that people often overlook, that you should consider:

1. Are the languages *actually* the problem? Much of the complexity in browsers today has to do with the browser APIs, which are totally separate from even the JS language spec, and can be left out even in a spec-compliant JS implementation. Maybe you want to change or reduce the browser APIs instead?

2. Who will be using your new web? Is it just for a particular group of people, or do you intend for it to *replace* the web as we know it today, for everyone? Are you sure that you're accounting for everyone's usecases in that group?

3. Can you explain how existing browser features came to exist, why people use them, and whether they are still in use? Why or why not? Are you certain that you're not overlooking something? Chesterton's Fence applies here.

4. How does your design deal with cases where you *didn't* foresee a usecase, and now have to retroactively add it to your API surface? Is there a place for it in the design, or will it have to be glued onto the side, ultimately ending up with the same kind of inconsistent mess we have with browser APIs today?

5. Do you want to support commercial usage of your web? If it's intended to replace the existing web but do not want commercial users, how do you make it interesting for third parties to implement it, including support for day-to-day things where commercial organizations currently decide the process and tools used?

6. If you don't want commercial users, how do you prevent from companies coming in and claiming it for themselves anyway, co-opting it into something outside of your control? Have you prepared a strategy to defend it from this, if it becomes successful enough to be commercially interesting?

7. Who governs the development process of your web? If it's one central person or organization, how do you prevent corruption? If it's *not* one central person or organization, how does that affect your plans to prevent co-optation?

8. Most "rebuild the web" ideas are opposed to the idea of webapps. But webapps are a big reason that non-Windows users can participate in daily life too nowadays. If your project is anti-webapp, how do you safeguard this ability? If it's anti-webapp *and* you intend to replace the current web, how do those two goals reconcile?

Look, if you're going to reply to this post with some grand yet unsupported claims because you personally don't like systemd, then the response you get will have an equivalent amount of effort put into it, which is to say very little.