This is awesome! How reliable are kindle jailbreaks/avoiding updates, etc?
Have opted for other devices like the xteink (or a boox in the future) due to what seemed like a relatively small ecosystem around “aftermarket” kindle modifications.
The kindle would be a great option if it could be reliably jailbroken and loaded with custom software
Jailbreaks will be overridden on modern Kindle firmwares unless you install an additional extension to prevent updates.
I use the "renameotabin" extension and enable Wi-Fi from time to time to load books from FTP via Koreader. It has been 3 years since I jailbroke it, and there have been no resets for me.
Depending on your firmware version, most jailbreak guides will have you either create an empty directory with the same name as the OTA firmware file (causing any OTA downloads to fail) or install an extension called `renameotabin` which renames the binaries responsible for performing the update, rendering them inaccessible.
This is a great point. Back when I was checking I think I was underwhelmed by the customization ecosystem for kobos but now I’m not sure what was stopping me/made me reconsider.
Upon further inspection there is also the Pine Note!
I've been using one of the Kobo Clara devices running Plato (built in Rust) for a few years now. Other than a couple of minor bugs early on, I've had no issues.
It's largely the exact device that I want my book reader to be:
* Small and lightweight
* Nice epaper screen
* No need for an internet connection whatsoever
* Natively understands EPUB
* Just reads books -- no ads, no markets, no apps, no upsell
The built-in Kobo firmware isn't great. IIRC Rakuten/Walmart hoover up and sell your reading habits, etc. Hence one reason why I don't connect mine to the internet (running Plato probably fixes this, but restarting the device doesn't immediately go into Plato). The device is also weirdly sluggish with the default Kobo software, and much faster in Plato.
I'm done with the kindle ecosystem, except for one last jailbroken kindle that I use for reading, but once that dies it's nice to know options.
Open source software, open (to the owners) with default configs, open ecosystems, repairability, hackability, open hardware are all factors I look for across multiple devices now. routers & wifi, readers, phones, headphones, laptops, keyboards, etc..
They don't always have to hit every element - but the more they cover, the more likely I am to track and purchase them when the time comes.
That’s right — I’m assuming you mean OS threads when you write “actual threads”.
Stackless Coroutines are currently supported for p3, stackful coroutines AKA “virtual threads” are coming (which I assume is what you mean by green threads), and “actual threads” as in OS threads are not currently a goal for the ABI AFAIK —- would you mind explaining some uses you were thinking of?
That’s a great question and something we’re going to have to figure out going forward on the JS side.
What I can say now is that the first version will probably be single threaded stack switching coroutines, and the model that seems to fit most naturally in my head is virtual threads mapping to some worker thread n in a premade pool.
It seems we're at a bit of a crossroads. It seems like the world both needs:
- Permissionless email (i.e. for agents, empowered users who can program now)
- Pervasive email allow listing
Wonder if these can both exist at the same time, i.e. having a "public" email that is read first by AI (let's imagine we're in a world where prompt injections weren't so possible) and heavily filtered, along with one that is private and allow-list gated (via some easier-than-gpg-to-use identity marker).
This is essentially a re-explanation of Neon’s architecture as a blog post.
Amazing that the Postgres ecosystem got this software for “free” (as in at least a basic version of it is F/OSS, IIRC there wasn’t any core bits held back), and the extremely engineer-heavy company got to make money, AND they got bought out in true acquisition style by a larger player that truly benefits from the tech.
The Postgres ecosystem is pretty unique in its ability to produce a “boring” stable product, innovate, stay F/OSS, and create financial outcomes for participants.
You can't have it all, forever -- the tech is there for anyone to fork and improve, build new businesses (!), inspect, etc. F/OSS is basically a miracle as-is.
If we compare the current state of the world to one in which they were acquired and then continued to put out more F/OSS, things look bad (which I assume is your implication). I choose to instead make the comparison to the world where we never see this tech and it stays proprietary. Sure, eventually someone in F/OSS might have gotten around to building this solution, but they pulled forward the future and we get to see and build on the result for free.
This a 100 times^. The Postgres ecosystem is remarkable and has managed to strike the balance between OSS and commercial successes in a way that most infra verticals have not.
Wow HN really does have a problem with commenting on anything to do with Mozilla.
Anyway, awesome to see this from the team inside Mozilla — hope this can become a new revenue stream over the long term.
Really excited to see some tight integration with Firefox and Thunderbird in the future.
People are going to hate this, but if someday Mozilla expands to being a productivity suite I’d be pretty happy to give them my money. ProtonMail is doing it and I trust them as well.
Mozilla has shown again and again that they care more about their politics than they do about what their customers want.
They resently released an updated Mascot that is "non-binary and goes by they/them". They'd rather just keep shoving their politics down their customers throats than actually provide them what they want.
The most mature tool chain right now is Rust, but there is good support for most things with LLVM underneath (C/C++ via clang). Golang, python and support for other languages is getting better and better (tinygo and big go) and there’s even more to come.
One of the goals of WebAssembly is to melt right into your local $TOOLCHAIN as a compilation target, and we are getting closer every week.
Very reductive :) there are flavors and hints of all these previous technologies /paradigms in WebAssembly + Component Model today, because only fools would attempt to build something without considering relevant prior art.
Won't bother trying going through differences/how-this-is-not-that but I'll say this: This time, it's slightly better, just like every time before.
I'd even go so far as to say this iteration is much better than what came before, and the speed of adoption by multiple language toolchains, platforms, operating systems, browsers proves that.
So far I haven't seen that on the existing tooling, nothing that would make me say it is much better, rather it looks much worse given the developer experience.
Zero IDE integration, no right mouse click to generate or consume interfaces/stubs, no debugging tools, no integration with existing toolchains like those alternatives, no wire debugging,....
It feels designed for those that never left the command line, vim and emacs kind of world.
I think we probably disagree on the most important parts of the tooling. I’m a lot more focused on what it lets me do/whether the abstractions are right.
That said, people have worked on IDE integration (it’s not zero, ex. WIT syntax highlighting), there is existing integration with upstream language tool chains, but trying to debate that seems silly. Whether tech is good or worth exploring is not dictated by IDE support, I think!
There has been substantial work on improving debugging, DX and documentation! Hopefully in the LLM age the existing can move even faster
Get your blatant component model propaganda outta here ;)
(to elaborate: WASM works just fine without the component model, it's not "the future of WebAssembly", just an option built on top of it, and of questionable value tbh)
The entire article boils down to one specific problem: string marshalling overhead can be optimized to be about 2x faster. Integrating the component model into browsers is overkill for that (and everything else belongs into the toolchains without touching the browser guts).
> The entire article boils down to one specific problem: string marshalling overhead
No, I don't think so at all. 80% of the article is about other problems (JS bindings are complicated to generate and a leaky abstraction, additional tools beyond the compiler are required, compiler authors don't want to deal with them, they increase the friction for getting started, they're hard to debug, ...)
...all those problems should be fixed in the toolchains, not in the browser.
Emscripten exists, DWARF debugging support exists and works (I can step from C/C++ code into JS code and back with the WASM DWARF debugging extension for VSCode), other language ecosystems just need to catch up.
You're implying the only solution to unnecessary friction is reams of unnecessary lubricant.
Someone had to spend time building those unnecessary toolchains. Imagine if this time were spent developing cool libraries or use cases for WASM, instead of building out plumbing.
> Get your blatant component model propaganda outta here ;)
It's perfectly good content, sir!
> (to elaborate: WASM works just fine without the component model, it's not "the future of WebAssembly", just an option built on top of it, and of questionable value tbh)
WebAssembly absolutely works fine without the component model, and I'd argue it's much better with the component model.
Here's my simple pitch.
world before component model:
> be me
> build a webassembly core module
> give it to someone
> they ask what imports it needs
> they ask how to run it
> they ask how to provide high level types to it
world after component model:
> be me
> write an IDL (WIT[0]) interface which specifies what the component should do
> write the webassembly component
WebAssembly gives us an incredible tool -- a new compilation target that is secure, performant and extensible. We could crudely liken this to RISCV. In $CURRENT_YEAR it doesn't make sense to stop at the RISCV layer and then let everyone create their own standards and chaos in 50 directions on what the 1/2/3 step higher abstractions should be.
Emscripten carried the torch (and still does great work of course) in building this layer that people could build on top of, but it didn't go far enough. Tools like wasm_bindgen in Rust work great but lack cross-platform usage.
The Component Model is absolutely the future of WebAssembly. Maybe not the future of WebAssembly core, but if you want to be productive and do increasingly interesting things with WebAssembly, the Component Model is the standards-backed, community-driven, cross-platform, ambitious way to do things with WebAssembly.
To be incredibly blunt, the failure of other attempts to centralize community, effort, and bring people along to build a shared thing that is just low cost enough that everyone can build on top is impressive. Nothing against other efforts, but I just can't find any similar efforts that others have standardized on in any meaningful way.
We're talking about a (partially already here) world where every popular programming language just outputs to WebAssembly natively and computers on every popular architecture/platform have an easy time running those binaries and libraries? If that's not the future, paint me a different one/show me movement in that direction -- genuinely would love to see what I'm missing!
And in all of this, the Component Model is optional -- if you don't like it, don't use it. If WebAssembly core works for you, you are absolutely free to build! wasm32-unknown-unknown is right there, waiting for you to target it (in Rust at least).
People undoubtedly thought going for Affine types was too much, and even simple things like null safety or enums-with-values and the prevalence of Result saw debate with minimalists voicing concerns.
A world where you could write a Rust program that is memory leak free with Affine types is one I want to live in. Haskell can do it now, but its just not easy and Rust has beat out Haskell with its mix of ML-strength types and practicality.
IMO these changes maintain Rusts winning mix of academia and practicality. Heres a proof point — dependent types weren't mentioned :)
reply