elisee

From https://ladybird.org/why-ladybird.html

    The world needs a browser that puts people first, contributes to open standards using a brand new engine, and is free from advertising's influence.
     
    This is why I've co-founded the Ladybird Browser Initiative with Andreas and my family has pledged $1M to support Ladybird's development. I believe in Ladybird and I believe in Andreas' vision, and I hope you'll help us support an open, independent browser that supports you.
     
    Chris Wanstrath
    GitHub Founder & former CEO

You might want to append `+ window.location.search` after the pathname for pages such as this very one to open properly.

From my experience building it under WSL on a reasonably recent laptop: from cloning the Git repo to seeing SerenityOS pop up in QEMU, maybe half an hour. A lot of it is downloading and building the toolchain.

And then incremental rebuilds (when I go and pull the latest changes once in a while to see what's new) take anywhere between 1-10 minutes, depending on what changed exactly. YMMV.

For an entire operating system, it's pretty cool already! I wonder if C++20 modules will take it down some more, it's been mentioned a few times as something to investigate.

The article says "The first, and easiest way to address it is to reprocess spent fuel as France does." but France has a long-term nuclear waste storage project (see https://fr.wikipedia.org/wiki/Cig%C3%A9o) so that seems to paint an incomplete picture?

I don't know much about the subject to be fair.

Andreas has recently mentioned that SerenityOS is meant to be an English-language OS. (Might have been on Discord or a Q&A video, not sure.)

I believe his rationale is that other languages are generally awkward at talking about technical stuff, and SerenityOS is addressed at technical users anyway. In my own experience as a French native speaker, I do tend to prefer all my software to be in English rather than getting the awkwardly-translated-in-French version.

As far as accessibility goes, like anything in the project, it's up to someone passionate to step up and work on it.

Most likely a reference to the word in the serenity prayer, which is what SerenityOS is named after (Andreas mentioned it a few times in his videos).

Video of the exoskeleton in action: https://www.youtube.com/watch?v=-yBfUcFRZ-I

Bit by bit indeed! The birthday posts here give a nice overview of how much the system has evolved over its couple years of existence: https://www.serenityos.org/happy/

The monthly progress videos are also nice in that regard.

For what it's worth it does support 2x density (https://github.com/SerenityOS/serenity/pull/4966) and there's a design doc about High-DPI: https://github.com/SerenityOS/serenity/blob/master/Documenta...

Andreas has been making videos (https://www.youtube.com/c/AndreasKling/videos) sharing his journey: technical ones working on some part of the system, as well as more personal ones talking about his philosophy, struggles and moments of joy.

I'm just one of many but I'm guessing his sincerity combined with his technical abilities make it all very compelling to watch and contribute with money or code, even though the system isn't at a point where you would want to use it.

Basically: it's a fun, open, ambitious project whose story is being told mainly through videos, with a kind and interesting person behind it.

Which one? The home page one seems to work for me. Otherwise try: https://sparks.land/discord

Haha I feel your pain, I did the same initially, took a few rewrites over the years to get to something I'm happy with and runs well.

There's a central Deno server program called the switchboard, which serves static content, runs a small REST API for account management / login, and starts a WebSocket server for game servers to register themselves.

Each game server (a stand-alone Deno program that might or might not run on its own machine) connects to the switchboard over websocket and authenticates itself with an API key (since people will be able to make their own game servers).

When a player wants to join a server, they POST a request to the switchboard, which gives them back a token that they can send to the game server after establishing a WebSocket connection to it. The game server checks the token with the switchboard and gets back public user account info if it's valid.

Each game server's logic is currently single-threaded. I guess we might end up offloading some work to WebWorkers later on.

A server can publish some state info through the switchboard that will be broadcasted to other servers from the same user. This is used to show player counts in game rooms from a lobby, things like that.

I run the whole thing on a couple cheap Scaleway servers, with Cloudflare in front (no AWS nor containers or anything of the sort). My previous platform, built with Node.js (https://jklm.fun) is able to sustain at least 2000 concurrent players like that, though admittedly those are board-like games which are not very demanding, unlike the games for Sparks.land which will be more fully-fledged... so we'll see how that holds up!

Not quite, I'm running Sucrase on my Deno HTTP server: if the extension is ".ts", I put the file through sucrase before serving it as text/javascript. In development, it happens every single time I reload (and it's fast enough that I don't even notice). In production, Cloudflare requests the .ts file from my server once (triggering sucrase), and then caches it.

It's getting there! They finished a rewrite of the extension recently and it's quite nice.

If you're on Windows like me, sadly there's still a nasty bug with path mismatches between the LSP server and the VSCode extension (https://github.com/denoland/deno/issues/9744) which requires reloading the window to fix spurious errors, but I'm sure it'll be fixed soon enough.

Correct! In production we've got Cloudflare in the middle, so we're only using sucrase on-the-fly for each .ts file during development. So far it's unnoticeable in terms of loading times.

> I notice your script files are all pretty small, have you run into any upper limits on performance or scalability so far with this approach?

Not that I can tell. But if we need to, we can always do a minified bundle in production later on. So far it's just nice to not have to even think about it!

Ah thanks for the heads up. It requires WebGL 2 which isn't yet in iOS's Web engine I believe? And IIRC all browsers have to use it on iOS. It does work on Android.

Happy to see Deno get some financial backing!

I've been building my new multiplayer games website [1] with Deno over the last 4 months and apart from some minor growing pains, it's been a joy to use.

The lack of unnecessary package management, and the TypeScript-by-default approach makes Web dev much nicer. We're also using TypeScript on the client-side, relying on VSCode for error reporting. We use sucrase to strip the types just as we're serving the script files, so that there is no extra build time, it feels like TypeScript is Web-native and we can share typed code with the server.

[1] Not yet launched but we ran a preview past weekend with hundreds of players over WebSockets: https://twitter.com/MasterOfTheGrid/status/13757583007179735... - https://sparks.land

Indeed! I swore off Web development a couple times because of the mess but now my whole party games platform is made with plain JS, no bundling, no post-processing, no big frameworks and it's pretty good. (Although I did recently augment it with some JSDoc types, for long-term maintainability)

At least three devs have asked why I wasn't using some reactive framework or big library. I know why: I'm much more productive without! Simple DOM helpers go a long way: https://jklm.fun/common/dom.js

(If you're curious: https://jklm.fun)

Can you point to some games (or game projects) using Grid Engine?

I've been focusing on re-making my various Web party games into a more unified platform at https://jklm.fun/

The previous iterations were built years ago using CoffeeScript, Grunt/Gulp, Jade, Stylus, etc. This time around, I went for vanilla HTML/JS/CSS, no transpilation, no bundler, no build step at all (and no frameworks). It's been a joy. I'm using the TypeScript compiler in VS Code for sanity checking and might add some JSDoc to leverage the type checks even, but for now it's quite nice as is.

I've also enjoyed building up a Discord community for it all, got almost a thousand people in there now and it's a lot of fun interacting on a daily basis.

Found via https://twitter.com/MStrehovsky/status/1110150403998576640