Kobo can run apps now
bandarlabs.github.io
bandarlabs.github.io
It has been maintained for years, and it supports every Kobo AFAIK.
It's called NickelMenu, and it's great. I'm in the Kobo ecosystem because of NickelMenu and Plato.
One note if you're thinking about getting a kobo due its relative openness: consider getting a two-core device. I did not do my homework and got a Clara BW because I don't want the color display. Later I found out that color is the only one with the two-core CPU.
I recommend enabling ssh (native kobo feature) so it's easier to modify the config without needing to plug in, though obviously this is optional.
If you connect over SSH, I would recommend not touching system files. The new kobos don't have a removable SD card so if you corrupt the system files and it can't boot, you need to either do some PCB surgery or get a new mainboard.
When reading, agree on it being more than sufficient.
My recommendation is partially because the price can be identical when they have a sale. That was the case when I got a BW--it was the same price as the color.
I should also mention I run quite a few things on my kobo: boringtun to connect to my home network, a fetcher to sync my books and feeds, Plato and its article fetcher whenever I update my Wallabag articles. I'm beyond pleased with my reader experience. The extra processing power would just be icing on the cake.
I got the BW over the Color only because I had read the color screen wasn't as sharp, though I've never compared them side by side.
I created this as I could not find anything existing that gives the capabilities I wanted. I read several things downloaded over web apart from books on my Mac and phone, which I would prefer to do on an eInk display. Search papers on arxiv and read them offline later, Substack, even spending a lot of time on chess puzzles, monitor my Claude/Codex remotely, generate explainer audiobooks and listen to them on my bluetooth speaker etc.
The longer battery and the display makes some use cases really shine and I wanted to create apps for my own Kobo and potentially helpful for others as well.
Nickelmenu deserves a mention in the opening paragraph and a differentiation of what this new piece of software brings to the table.
NickelMenu is a mature project and perfect at what it does, we just have different goals. NickelMenu is designed to extend Kobo's stock interface. Cobalt is designed to be an app platform like Android has for example. I wanted app creators to just write their app logic and not build things like a UI toolkit for their apps, app lifecycle and rendering support (framebuffer drawing, partial eInk refreshes, touch input handling etc.), bluetooth handling, sensor and more. Anything launched through NickelMenu like KOReader or Plato have to implement these on their own.
AFAIK NickelMenu command actions spawn arbitrary shell cmds that inherit root from Nickel, we avoid it by running apps as separate unprivileged processes with declared capabilities like network, storage, audio, fronlight etc.
I also wanted to provide ability to quickly build apps with the SDK and our simulator to test apps on before putting it on the real device, an app store to get new apps over the WiFi after the initial USB install.
This was more oriented on making my life easier, say I have an app idea that I want on my Kobo tomorrow and how quickly can I bring it live on the device. The 'you can run apps' I wrote was meant to signify anyone can now create apps using the SDK without bothering about the device specific bits and publish them and install it via Cobalt's app store. I hope this clarifies things.
Time to start a F.A.Q section on the website. You could that comment almost verbatims for the question : "How is that different from NickelMenu"
There are current issues and PRs for Clara HD and Color devices support so we can take it up by common generations.
It runs Android. It's a Chinese company and comes with a bunch of pre-installed apps, but I just blocked its abilities to phone home and use Koreader. It's been great for me
https://goodereader.com/blog/product/onyx-boox-go-7-bw "The Onyx Boox Go 7 is a dedicated e-book reader with a black and white e-paper display. This device has the same specifications and software as the Go 7 Color Gen 2, except that this model doesn’t have a Kaleido 3; instead, it uses the latest generation Carta 1300 e-paper panel, which increases responsiveness. The key selling points of this model are the physical page-turn buttons and Google Android 13, as well as full access to the Play Store. For those of you who want an e-reader that doesn’t lock you into a specific ecosystem, this deserves a look."
(slower by 2 minutes...)
Unless you're a real contrast freak, I think most people would be slightly happier with the color than the B&W; but it's definitely not worth paying extra for.
Yes, I have - I have a Kobo Libra 2 (BW), Boox Go 7 II (Color - same screen as color Kobos) and Boox Note Air 3 (Color).
The issue isn't crispness really - when rendering B&W content the crispness is about the same. However, there's a massive issue with contrast - the Color screen background is very dark and they're basically unusable (for me) without driving them constantly at 80-100% backlight (even during the day). Even at 100% backlight, the page background is darker than the BW reader at like 30% backlight.
This makes the reader eat more battery while being less pleasant for text reading. Moreover, in dark mode (light text on black background) the color screens all show severe ghosting artifacts which don't appear as much on BW screens.
Having said that - reading comics and color books (e.g. programming books) looks great on the color screens. There's just something about that slightly less vibrant "papery" look that's very attractive.
The C is sharper but the L looks more like a real book/paper. I believe as an artifact of the colour screen and it’s called “screenshot effect”. In the end, once you use either for 10 minutes it becomes “the new normal”.
Sigh - I don't want a giant, note-taking ereader - I want something about the size of a pocket book with a crisp B&W screen.
Why do I need colour? I am reading novels.
Very bad battery life. Maybe 8hrs of reading with wifi off, BT off and only low screen backlight. I need to charge it daily or every other day at best.
Physical buttons are comically bad and often don't register presses.
Built-in book reading app is slow, lacks some critical features and hangs in many epub books. I replaced it with KOreader which finally made the device usable.
It's a great screen size though (9" would be even better).
This seems like a wildly different experience than I have with it. I don't read 8 hours per day, but typically 1-2 hours per day, and charge it every 2-3 weeks.
My light levels are probably 50/50 6% (at night in bed) and ~33% (other times). I did briefly buy a Kobo remote and found that having bluetooth on for that was very bad for my battery life.
The physical buttons were also great - for the first year, then they started wearing out.
Not aware of a debug interface, but in the absence of that, you'll need to desolder the nand module and replace the files there with the help of another owner. The mobile read forums are where you can connect with fellow owners.
So the short version: I'd replace the mainboard.
My experience is over 2 years old, so I'm sure some details have changed.
It also wasn't really big enough for comics. So I'm not quite sure what the selling point is.
It definitely looks cool the first time you see it though.
(Also I thought the whole appeal of Kobo was that you don't need an account, but it wouldn't let me do anything without making an account, which I had to do thru a national partner, whose site was offline...)
--
[0] I also heard something about color e-ink having a lower effective resolution? But I'm not sure.
What's tricky is that although I don't want it to be an unconstrained app platform, I do want the ability to integrate with services that host my things to read. Karakeep, RSS, Google Play Books or Internet Archive, etc.. but I think that could be handled in a more narrow fashion.
Thanks for the clarification Claude
Edit: damn, just saw the BW note. It looks like the Clara Colour would be blocked by Cobalt...
It was starting to die and had screenglitches. After a bit of debug, it turns out that hacking the kobo is dirt simple. You open up the back, and replace the SD card. thats it.
There is a large community that have created toolchains and guides. there is of course a port of koreader (https://koreader.rocks/) which has a lua interface for making your own apps.
Plus, it is installed on top of the normal kobo operating system via NickelMenu, so it's not really messing up with anything.
Me personally, I just want a reliable toaster.
The street finds its own use for things is the excitement that we don't know what is possible, and that we ought be free to try. The amazing suite of software here sure looks like self evident proof about how exciting it is when we can go further, to me. I love the LLM prompt sidekick; super neat as an ambient display.
It's really sad how HN is so vocally anti-hacker, is so conservative, shows up so regularly to declare alliance to anti-possibility, to anti-features. For some people, they don't only fail to be interested, they are expressly anti interested, the only thing they want is for everyone else to have to live as constrained and unexplorarive and unthoughtful as they are. I don't get it. Conservatism is a wicked disease, imo.
Plus, isn't it fairly old hat to get root access on a Linux consumer device and then running whatever you want on it? Oh, it makes for a neat party trick you could make an Action Retro YouTube video out of. But perhaps people are just jaded since they've seen it done on a million types of devices by now. Maybe there are more interesting ways, and things, to hack.
The goal doesn't have to be practicality.
If a toaster needs to just be a good toaster, it sure as hell does not need a SoC than can run Linux, and I might give it the benefit of the doubt and consider its FW closely tied to HW.
Ended up being more involved than the benefit it would bring, especially considering that these media server programs know how to interface with the traditional remote over HDMI (if you have the right graphics card or a dongle) and show the selection UI on screen like a smart TV.
Anyway, my response is "you don't necessarily have to complicate your e-reader, instead you have the option of making it not an e-reader."
Years ago, it was practically a hobby of mine to go to my local Goodwill, and find an extremely cheap old used Kobo and find someone to donate it to. Now I'm thinking of getting old Kobos just for the eink display so I can run simple apps on it - while continuing to use my regular Kobo as an ereader.
(I'm talking $15 or less).
On many occasions I have compiled notes, sometimes manually created sometimes LLM curated, and put them into a .epub file to send to my kindle so I can read as I am out walking.
It would be cool to skip a few steps there, and have "live" documents at the ready, particularly in markdown if possible, without having to sync/publish etc
It is not because you can install and run apps that you have to.
Not sure if they cut it off at some point, but they can surely keep updating 10 yo devices.
HN Search: enshittification - https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Everyone already has at least one multitool, the smartphone. Most also have a tablet and/or a laptop. While this project looks like a cool hack, I don't see much practical use for another multitool with a weak CPU, laggy screen, and poor input.
I can simulate it by staying on the "Library" tab, but it tends to forget halfway frequently.
It also has a cli to let you push docs over WiFi. Oh, and a HN reader. I have another repo with the user space I use, but need to clean that up before making it public.
It's not that vibe coding is bad on its own, but it makes me worried about project's future (ease come, easy go).
Store-only by design: installing it proves delivery of an app the USB package never contained.
There's a big difference between putting money or time into a community of builders and learning in the process (myself or growing others) and maintaining a vibe coded project. That's why I want to know right away which projects are vibe coded so that I don't put any effort into them.
You're free to apply different criteria to software you use, but we're talking about having information to make an informed decision here.
So I'd like to have fully reproducible builts for a dozen or two apps I use seemlessly integrated into my laptop and phone update mechanisms. And yes, my smart TV, router, ereader and note-taking apps...
However, infinite forking also means harder to benefit from others' improvements.
Personally, so far I got best results by carefully selecting a small number of apps and devices with good track record and community around them (think Emacs that's been around for decades, but also KOReader, Linux, AntennaPod on Android and many others) and supporting those in various ways. I might vibe code an extension or config for the apps, but then I still understand what it does and why.
AI is yet to change that. I use LLMs daily at work, but software maintenance remains problematic. Producing stable software in unstable times is actually what pays my bills.
Edit: And yes - if you fork, upstreaming is a problem. It's unfair for original software maintainer to need to review, test and integrate vibe coded code.
> Charge a Kobo Clara BW (N365) and connect it over USB. Other models are refused, not guessed at.
> Tested on one device: the Kobo Clara BW (N365, device code 391), firmware 4.45.23697. Every device write is gated on an exact match of framebuffer identity, geometry, device code, serial model prefix, firmware version and kernel release, so a different reader is refused rather than guessed at.
I can't stop reading "gated" on LLM output lately.
Anyways, I wish this worked on my Libra :<
If your software is mostly written by the slop machine, fine. I don't have to be upset about it unless I think about contributing and then notice the uncanny nature of the source code. But a website and a README is directly user facing and it is a major disservice, and in my opinion, lack of respect, to generate your website copy with an LLM.
"These are photographs of the device, not simulator captures" is the kind of total throwaway verbiage that a human would never even pause to consider writing because it "clarifies" something that in the totality of context is beyond obvious. It makes the writing more fatiguing to read, and creates a terrible first impression for a project.
With my kobo any time I am bored I just read another few pages on a book or whatever? But I feel like the Soviet citizen with analysis paralysis when I go into a grocery store and can't decide which of the 32 types of bread I want to buy.
still, ios MDM or android ADB on your existing device can restrict it to your liking without needing to buy more hardware. greyscale screen, strict timelimits on the sometimes essential browser, inability to even open the appstores, removal of tracking apps, etc.
needs just as much self control as any other dumbphone, and genuinely less painful to set up.
I've experimented some with the Kobo ecosystem since I got my Clara BW, I've played with NickleMenu, Plato, and KOReader. KOReader has a built-in OPDS client, but KOReader is a bit heavyweight and it would be really nice to have a dedicated stand-alone client (especially one that supports credentialed OPDS feeds like calibre-web exposes)
I like that is a durable single use device. I wouldnt use it as general use computer at all.
Even my old kobo has experimental features like wifi and a web browser. They have been trying to break in to that market since forever.
What a great device.
https://github.com/Podginator/KoboOmnivoreConverter
It took a lot of messing around trying to figure out how nickel fit together. This is much more … impressive.
Do you know of any alternative?
so it's not something you can daily drive just yet? Is this because of technical issues that prevent it from surviving a reboot?
Jesus christ folks. Is it really a big effort to have a human proofread the first paragraph in your product launch?