There aren't usually many domains where a process can't be described as a series of steps. Deciding what those are called, and structuring data in such a way that it each of those steps works sensibly can be challenging, but that is the process of making code comprehensible.
I can remember as a novice that I would write an entire program in a single, many-thousand line function, unable to see where the boundaries between functions should be. With experience and expertise in the domain, it becomes easier to see where those should be.
That is an ideal way of seeing this. As a for-profit company their priority is shareholder value, so the focus isn't "people paid and games were made", it's the money left-over, and even more importantly that the number must grow.
The layout engine is limited. It does flow text quite well, but when I had mine (the screen broke a few months ago) I was working on adding more features to the rendering engine.
It's easy to write a HTML & CSS layout engine to support most of the epub spec, but hard to do it well on such a constrained chip. Even things like nested lists and inline code snippets are a challenge.
That must be why Amazon does a lot of pre-processing on their server. They know what device they are sending to and can tailor the file for that device.
Maybe expecting the X4 to look great is asking too much. It took Amazon years to get it right on Kindle. Hyphenation is a difficult task.
The X4 doesn't have a touch screen, so you're safe on those points. The next iteration will do though, although I think you will be able to turn it off in the reader view.
I really like the Matrix ecosystem, and this client seems like a cool addition, but how are posts like this with a load of AI generated prose getting on the front page?
I can't say how frustrating it is to be midway through reading something and realise there's no human author.
While AI was used for writing the code and large parts of the text (including in the blog post), I can assure you there's been a human author dedicating many days and sleepless nights on this alongside the AI.
Especially when it comes to the blog post, it's been human-reviewed and tweaked many times.
Still, if you don't like the content, it probably doesn't matter that there had been a human dedicating too much of his free time on this side project.
I love matrix-docker-ansible-deploy and use it for my homeservers.
I also bounced off this piece around halfway through when I realized it was mixed AI/human content. I can read AI output anytime I want. Show me your true self! :)
Maybe it's because I scrolled down before reading, but I could instantly tell this entire text was AI slop from the massive overuse of emojis and bullet points.
In case anyone is interested, this creator built a remake of Portal for the N64, uploading a really cool set of videos describing the work that went into building it.
He's since stopped to work on his own IP, I believe that the issue was that Valve couldn't allow it because they'd never get Nintendo to agree to it. Something along those lines, anyway.
I think the main issue was he used Nintendo owned tools and libraries to make his game instead of the GPL ones, making the release of the port dependent on Nintendo's approval too. I guess even Valve didn't want to deal with their lawyers.
In principle he could use alternative tools, like libdragon, but he said even if he did that it was unlikely Valve would permit it, as Nintendo would still be antagonized somehow. And Valve it seems wants to improve their relationship with Nintendo (See: Valve blocked Dolphin on steam, and took down a video showing yuzu installed on the steam deck).
It's an interesting question of comparison actually. Valve run the world's biggest videogame ecommerce platform, for PCs only (including handheld PCs like steam deck). Nintendo run a comparably large videogame ecommerce platform, but only for their two hardware platforms: switch and switch 2. Just roughly based on hardware sales, seems to be roundabout the same audience size. Nintendo maybe comes ahead because they're well established in the hardware space (Valve is trying to close the distance), and of course far, far away in terms of 1st party game development - Valve has, what, 8 games? All phenomenal, but nothing compared to Nintendo's library.
Does Valve even make games anymore? The only thing of note they've done since like 2020 is put a fresh coat of paint on CounterStrike. Which still counts of course but it feels like they are REALLY coasting on the reputation of games that came out 20+ years ago.
Valve's working on Deadlock, an FPS / MOBA. It's very polished, but in early access right now. Based on what I've seen when I tried playing it, and just what I hear in the gaming sphere, it'll probably be a decade-defining multiplayer game once it's done, like TF2 or CSGO both are.
They definitely coast, but when they do release something, it's always phenomenal. I do wish they'd make more games, though.
If I recall correctly, there was also the issue that a Nintendo 64 ROM of their game would be fundamentally incompatible with Steam, which (as many forget) is technically their DRM solution. I could be wrong, of course.
You are free to publish any ROM to any system, it's a basic right against both monopolies and freedom of speech restrictions. What you can't do is to ilegally pull propietary dependencies without permission.
The problem I'm pointing out is that it's a work based on a Valve property that fundamentally cannot be tied to the DRM because it's "just" a ROM.
I believe this came up when the creator was talking about libdragon-- Valve has been more forgiving of other games like Hunt Down the Freeman and whatnot because they're native executables with the Steam DRM, which video games based on Valve properties necessarily must have. Portal 64 simply cannot do this, because Steam is not a Nintendo 64 application.
I think the problem is that it's too onerous to run your own instance, but being on anything but the "default" instance means dealing with volunteer moderators imposing their worldview on the available discourse.
Creating a Mastodon account shouldn't mean supporting the particular political affiliation of the moderators, but I think it feels that way for many of the instances.
I think that Ladybird has driven a lot of the effort, otherwise we'd just see browsers continuing to use Chromium with backports to allow v2 being worked on.
Ladybird was already progressing rapidly within SerenityOS well before it was officially launched, and I think that's given people a new inspiration for how plausible it is to create a browser from scratch. I'm really pleased we're seeing Servo having a resurgence too.
It’s indeed rapidly progressing feature-wise, but I have yet to see an explanation for how they intend to manage security once market adoption happens.
Ladybird is written in C++, which is memory-unsafe by default (unlike Rust, which is memory-safe by default). Firefox and Chrome also use C++, and each of them has 3-4 critical vulnerabilities related to memory safety per year, despite the massive resources Mozilla and Google have invested in security. I don’t understand how the Ladybird team could possibly hope to secure a C++ browser engine, given that even engineering giants have consistently failed to do so.
> Firefox and Chrome also use C++, and each of them has 3-4 critical vulnerabilities related to memory safety per year, despite the massive resources Mozilla and Google have invested in security.
And part of Firefox/Chromes security effort has been to use memory safe languages in critical sections like file format decoders. They're far too deeply invested in C++ to move away entirely in our lifetimes, but they are taking advantage of other languages where they feasibly can, so to write a new browser in pure C++ is a regression from what the big players are already doing.
I just checked out Servo, and like all browsers it has a VERY large footprint of dependencies (notably GStreamer/GOject, libpng/jpeg, PCRE). Considering browsers have quite the decent process isolation (the whole browser process vs heavily sandboxed renderer processes), I wonder how tangible the Rust advantage turns out to be.
I just looked at the top CVEs for chrome in 2025. There are 5 which allow excaping the sandbox, and the top ones seem to be V8 bugs where the JIT is coaxed into generating exploitable code.
One seems to be a genuine use-after-free.
So I can echo what you wrote about the JS engine being most exploitable, but how is Rust supposed to help with generating memory-safe JITed code?
I know they have said that. But it feels a bit strange to me to continue to develop in C++ then, if they eventually will have to rewrite everything in Swift. Wouldn't it be better to switch language sooner rather than later in that case?
Or maybe it doesn't have to take so much time to do a rewrite if an AI does it. But then I also wonder why not do it now, rather than wait.
That is the plan, but they are stalled on that effort by difficulties getting Swift's memory model (reference counting) to play nice with Ladybird's (garbage collection)
I think there was some work with the Swift team at Apple to fix this but there haven't been any updates in months
I know that that’s the plan, but I believe it when I see it. Mozilla invented entire language features for Rust based on Servo’s needs. It’s doubtful whether a language like Swift, which is used mostly for high-level UI code, has what it takes to serve as the foundation of a browser engine.
I can remember as a novice that I would write an entire program in a single, many-thousand line function, unable to see where the boundaries between functions should be. With experience and expertise in the domain, it becomes easier to see where those should be.