3 ms·

Hey, author here. NickelMenu is terrific and Cobalt uses it to show the menu item in the default Kobo menu. It's just that Cobalt and NickelMenu are not the sam

by thepoet 1mo ago

Hey, author here. NickelMenu is terrific and Cobalt uses it to show the menu item in the default Kobo menu. It's just that Cobalt and NickelMenu are not the same in terms of project goals. 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.

KennyBlanken 1mo ago
[flagged]
- kaonwarb 1mo ago
  This wouldn't exist without OP's agency; it's reasonable for them to take credit. If there are bugs, etc., that's fair game. Declaring hate for folks because of their approach is not.
  - bigstrat2003 1mo ago
    No, not really. If you used an LLM you didn't actually make anything. It's like if one commissions a work of art: yes, it wouldn't exist if not for your actions, but no, you didn't make it.
    - deleted 1mo ago
      [deleted]
    - mkagenius 1mo ago
      > If you used an LLM you didn't actually make anything On my way to ask all academia and researchers to stop using LLMs for their research. As it's just llm doing the research, right?
      - qmmmur 1mo ago
        Academia would largely agree
- hexasquid 1mo ago
  This got me thinking about what "I made this" means, when we're building on top of zillions of abstractions "made" by others. I don't make the binaries. The compiler does. I just feed in specification called source code.
- bb88 1mo ago
  This kind of "purity" argument is absolutely toxic. We've seen it with the vietnam paper comparing ORMs to SQL, etc. etc. Please stop this. You didn't hire him, you certainly aren't willing to give him a salary for him to live off of. If you want to complain about LLMs used in software, advocate for a voluntary LLM disclosure published in the docs someplace, so people can make informed decisions.
- maybsum1else 1mo ago
  this is such a stupid, lazy take. I mean, just think about cameras and photography. there's talented photographers, they know how to adjust cameras, they understanding lighting and composition, and yet the camera is what is actually producing the photo... but it's not taboo at all, for anyone to claim credit for taking a photo, no matter their skill level or the quality of the result. It's generally accepted that 'using the tool' is part of the process. if someone said "i created this photo" it might sound like an odd choice of words, but you wouldn't find the need to 'set them straight' by explaining their camera is actually what created the photo. you can be a hater all you want, but you're just as annoying as the thousands of vibe-coded projects that are annoying you.
- oa335 1mo ago
  what a horrible attitude, especially for a forum dedicated to "hackers". the code is open source, why dont you show us what a quality test suite looks like?
  - allarm 1mo ago
    Oh my. Don't you think that code generated by an LLM has nothing to do with "hackers"? And once/if you realize that, don't you immediately see that they're right? Maybe not in the way they say it, but otherwise - they're absolutely right.
- mkagenius 1mo ago
  The project already does QA. cargo test --workspace --all-features The above command runs 2000+ tests. Instead of being toxic, you could have just looked at docs or the code to find them.
  - wonnage 1mo ago
    2000 ai generated tests on a hobby project that the author has almost certainly not reviewed does not inspire confidence
the-grump 1mo ago
I admire and support your effort, but the title makes it sound like you couldn't run apps in the past. Nickelmenu deserves a mention in the opening paragraph and a differentiation of what this new piece of software brings to the table.
- thepoet 1mo ago
  Thank you for the kind words. I will add a page to the project explaining the differentiation. 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.
  - cassepipe 1mo ago
    Awesome 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"
mlongval 1mo ago
Very nice project. I looked at it with the aide of Claude. I was interested in porting the Chess game that Claude helped me make for NickleMenu that runs on my Kobo Elipsa Gen1. From my understanding of Claude's analysis it would be difficult to port the chess game because each Cobalt app is sandboxed, and my app would not be able to spawn the Stockfish engine that my Chess (Nickle menu) game needs to run. Is that an erroneous conclusion? Also I probably could not port my Tailscale client to Cobalt for the same reasons. I kinda creates a separation. Perhaps that is by design: Cobalt = very secure, Nickle = more open but more risk. Finally the Elipsa Gen1 does not seem to be included in the supported platforms. Thanks. Cheers from Canada!
- thepoet 1mo ago
  Thanks! Can you please create two separate issues in the project for both Elipsa Gen1 support and the other for the stockfish and tailscale client implementation support. Would love to discuss and collaborate with you on both. I would need your help to test on the actual Gen1 device. There are current issues and PRs for Clara HD and Color devices support so we can take it up by common generations.

by thepoet 1mo ago

KennyBlanken 1mo ago

[flagged]

kaonwarb 1mo ago
This wouldn't exist without OP's agency; it's reasonable for them to take credit. If there are bugs, etc., that's fair game. Declaring hate for folks because of their approach is not.
- bigstrat2003 1mo ago
  No, not really. If you used an LLM you didn't actually make anything. It's like if one commissions a work of art: yes, it wouldn't exist if not for your actions, but no, you didn't make it.
  - deleted 1mo ago
    [deleted]
  - mkagenius 1mo ago
    > If you used an LLM you didn't actually make anything On my way to ask all academia and researchers to stop using LLMs for their research. As it's just llm doing the research, right?
    - qmmmur 1mo ago
      Academia would largely agree
hexasquid 1mo ago
This got me thinking about what "I made this" means, when we're building on top of zillions of abstractions "made" by others. I don't make the binaries. The compiler does. I just feed in specification called source code.
bb88 1mo ago
This kind of "purity" argument is absolutely toxic. We've seen it with the vietnam paper comparing ORMs to SQL, etc. etc. Please stop this. You didn't hire him, you certainly aren't willing to give him a salary for him to live off of. If you want to complain about LLMs used in software, advocate for a voluntary LLM disclosure published in the docs someplace, so people can make informed decisions.
maybsum1else 1mo ago
this is such a stupid, lazy take. I mean, just think about cameras and photography. there's talented photographers, they know how to adjust cameras, they understanding lighting and composition, and yet the camera is what is actually producing the photo... but it's not taboo at all, for anyone to claim credit for taking a photo, no matter their skill level or the quality of the result. It's generally accepted that 'using the tool' is part of the process. if someone said "i created this photo" it might sound like an odd choice of words, but you wouldn't find the need to 'set them straight' by explaining their camera is actually what created the photo. you can be a hater all you want, but you're just as annoying as the thousands of vibe-coded projects that are annoying you.
oa335 1mo ago
what a horrible attitude, especially for a forum dedicated to "hackers". the code is open source, why dont you show us what a quality test suite looks like?
- allarm 1mo ago
  Oh my. Don't you think that code generated by an LLM has nothing to do with "hackers"? And once/if you realize that, don't you immediately see that they're right? Maybe not in the way they say it, but otherwise - they're absolutely right.
mkagenius 1mo ago
The project already does QA. cargo test --workspace --all-features The above command runs 2000+ tests. Instead of being toxic, you could have just looked at docs or the code to find them.
- wonnage 1mo ago
  2000 ai generated tests on a hobby project that the author has almost certainly not reviewed does not inspire confidence

the-grump 1mo ago

I admire and support your effort, but the title makes it sound like you couldn't run apps in the past. Nickelmenu deserves a mention in the opening paragraph and a differentiation of what this new piece of software brings to the table.

thepoet 1mo ago
Thank you for the kind words. I will add a page to the project explaining the differentiation. 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.
- cassepipe 1mo ago
  Awesome 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"

mlongval 1mo ago

Very nice project. I looked at it with the aide of Claude. I was interested in porting the Chess game that Claude helped me make for NickleMenu that runs on my Kobo Elipsa Gen1. From my understanding of Claude's analysis it would be difficult to port the chess game because each Cobalt app is sandboxed, and my app would not be able to spawn the Stockfish engine that my Chess (Nickle menu) game needs to run. Is that an erroneous conclusion? Also I probably could not port my Tailscale client to Cobalt for the same reasons. I kinda creates a separation. Perhaps that is by design: Cobalt = very secure, Nickle = more open but more risk. Finally the Elipsa Gen1 does not seem to be included in the supported platforms. Thanks. Cheers from Canada!

thepoet 1mo ago
Thanks! Can you please create two separate issues in the project for both Elipsa Gen1 support and the other for the stockfish and tailscale client implementation support. Would love to discuss and collaborate with you on both. I would need your help to test on the actual Gen1 device. There are current issues and PRs for Clara HD and Color devices support so we can take it up by common generations.