HN user
writing at vadosware.io
Ah to be clear this isn’t my work! Interested in seeing what the HN community thinks about this project
I skimmed the code and it looks reasonable, but I have to assume it’d vibe coded (which doesn’t mean it’s bad).
Another really interesting Lisp that I recently came across:
Wow, had no idea this existed, thanks for writing it and sharing it!
No worries, and thanks for your service -- people buying possibly-disappointing early devices definitely enables the newer devices to exist :)
I hadn't heard of the Pinenote before looking at your comment, so I looked at the site and saw some things that made it seem unfit for purpose as an ereader. I made my comment because I was interested in hearing your impressions if you were using it as a daily driver.
I updated my original comment to include some more personal blogs with first-hand accounts. They're not mine but worth linking to for others!
I haven't bought a PineNote yet, but it's probably going to be my choice for that size of Tablet. I opted for a Xteink instead and have been very happy with it.
Personally I view stuff like this as a nice-to-have, not a must-have. If it means I can't have an interface where I can buy books and then download them to my ereader, or I can't have an iphone app where I can read books and have my progress synced between my ereader and my phone, or it's unstable, or the battery life isn't good, then I would rather go with the Kobo. I understand that different people have different priorities, but those are mine. Stuff like this is why I'm interested in hearing more detailed information about what exactly the tradeoffs are for going with something like the Pinenote.
I agree that there are certainly a lot of sharp edges to less supported platforms. I just think I'd rather get a Boox (and deal with Android/Graphene) or PineNote over the Kobo over the long term. Then again, my usage of very simple -- maybe I just don't read as much/depend as much on the ereader to the extent that others do!
I think you can still sideload KOReader on them, but that's a shame that they're making it harder to replace the stock OS entirely. I hadn't heard about that prior to now so thanks for bringing that up. I only have a Sage I bought a few years ago.
Ah yes, AFAICT what you're saying is correct -- sideloading apps is not an issue as far as I could find, it was just the inability to have custom firmware/OS.
I was very disappointed in this, and I generally see it as a step towards locking down that will only continue. Would love to be wrong though as I was very very convinced I wanted a Kobo Libra Color earlier).
People that are happy with the Kobos as they are (and the bundled software/services) I'm sure will be happy to keep buying though, I think the market is certainly big enough for that!
More expensive and less out-of-the-box software, but straight to the point on device ownership/what kind of software you can run, fewer strings attached.
This note was in the original comment, did you read it? The fact that it is $400 (more expensive) and has less out of the box software is literally mentioned to alert people to that.
The Kobos don't limit what you can do with them either, you can sideload alternative e-reader software like KOReader that improves on the built-in reader functionality.
This is patently false, the latest Kobo Libra Color is using secure boot which completely locks out custom development:
https://www.mobileread.com/forums/showthread.php?t=363175
So much so that QuillOS which used to be Kobo focused rewrote to support the PineNote
https://github.com/Quill-OS/quill
The point is to buy hardware that is built for you to freely modify and fully own, from the start.
My post was to make sure everyone knew the PineNote was an option, because I certainly did not know it until someone on HN made me aware.
Could you maybe make your point more concrete? Are you attempting to completely dissuade people from using the PineNote because it may not be easy to side load apps to it on hacker news?. Obviously different people have different propensities to do hacking, and some may not be able to afford the PineNote due to how expensive it is, but it's not clear what the goal of your comment was.
If your goal was "invest in Kobo instead of PineNote", I disagree with that. I'm not interested in investing (whether money or time) in an ecosystem that is just going to rug pull me eventually, over nickels and dimes.
BTW for those who agree, another great option is XTeink -- very hackable, and I've bought one myself:
And there's a Linux phone out there which looks pretty encouraging too:
https://furilabs.com/shop/flx1splus/
Graphene is likely still the easier more polished option, but it's great to have options these days.
BTW for those who are looking for a device, the PineNote exists:
https://pine64.org/devices/pinenote/
More expensive and less out-of-the-box software, but straight to the point on device ownership/what kind of software you can run, fewer strings attached.
[EDIT]
Great experience blogs on the PineNote
https://shom.dev/posts/20250308_pinenote-day-one/
https://shom.dev/posts/20250406_a-pinenote-only-5-day-weeken...
can't stand the thought of people not understanding the above reply[0]
[0] https://knowyourmeme.com/memes/its-one-banana-michael-what-c...
You want to waste VRAM, in this economy?
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!
https://news.ycombinator.com/item?id=46283016
https://pine64.org/devices/pinenote/
It’s quite pricey but certainly more straightforward in its offering.
Kobo is the cheaper and has a color option and is likely slightly less hackable.
[EDIT] Ah, I think this is what I found:
https://github.com/Quill-OS/quill
Kobo’s switch to secure boot made things harder for Quill which seemed to be the only custom OS.
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.
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
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?
If you’re poking around WASM consider falling down the Component Model rabbit hole:
https://github.com/WebAssembly/component-model/blob/main/des...
Threading is actively being worked on right now (to be released in 0.3.x, soon), and some changes just made their way into LLVM as well:
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).
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 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.
Not the original commenter but this is an excellent answer, thanks for the clear explanation — this is what people continue to come to HN for IMO.
Also thanks for all the podcasts and content, always a joy to watch.
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.
Incredibly badass. This is the best news I’ve read all year — world is better with Sid in it.
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
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.
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
> be me
> write an IDL (WIT[0]) interface which specifies what the component should do
> write the webassembly component
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).
If you’d like to get acquainted with modern WebAssembly, check out the component model book:
https://component-model.bytecodealliance.org/
It includes high level concepts, practical code samples and more that introduce the really powerful parts of WebAssembly.
With regards to the JS ecosystem specifically there are 3 projects to know:
https://github.com/bytecodealliance/StarlingMonkey
https://github.com/bytecodealliance/ComponentizeJS
https://github.com/bytecodealliance/jco
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.
*linear types (the leak free future bit)
This description is also a good crystallization of why one would want linear types
Really excited for the possibilities here.
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 :)
Please just contribute to seaweedfs or the other options instead!
There are a lot of other options when it comes to locally hosted S3, minio has not been the best option for a long while.
It was used the most in introductory articles/examples maybe but there were better options
If someone has written an article about how $X is not dead, $X is probably dead.
Not much to add here but wanted to agree, this is post was actually hacker news (tm)
Hey just a heads up, the submission link is missing a ‘t’