I've built about 10 mechanical keyboards so far, including a bunch of split ergo ones and low profile variants too. From that, I know the layout matters a lot, as well as the switches themselves; the programability and other features to me are nice but ultimately can be worked around.
I'm curious about the switches you're using. On the tech specs it says:
"Dual steel arm scissor switch w/ retention spring, 40gf actuation force"
Are they custom switches then? If so, are they most similar to current Magic Keyboard switch feel, or something Choc or MX low profile, or their own thing altogether?
The switches feel like a M-Series MacBook with a decent amount more travel and more "snappy", tactile feeling. They feel quite different to, for example, Choc switches (which we used on our previous keyboard).
That's really interesting. Hmm... it's too bad that there's no easy way to try out the keyboard and its unique switches before committing. But it's intriguing nonetheless.
Can you share how long you're looking to run the preorder/early bird special?
They are almost certainly the Cherry MX Ultra Low Profile[0], or else an almost 1:1 clone of them. Identical design, identical height and actuation distance. The actuation force is a bit off, but those numbers are more of a suggestion anyways.
Yeah, it's about how Windows has .msi installers, whereas for MacOS it's a .dmg where you copy the exec binary (which itself is a folder) into the /Applications folder.
I've been messing around with this as well, and there are a few good options now, if you're willing to self-host services:
- calibre-web, as a pure web front end to the calibre db
- Calibre Web Automated, which is a rewrite of the app, with a better web UI, that is faster and adds functionality
- Grimmory, a Java-based book mgmt. app w/ a web front end too
- BookOrbit, similar to Grimmory but written in Node and seems to scale better w/ 100k+ book libraries
The better way to get books onto KOReader is via connecting to these apps' OPDS feeds. Wireless, and most of these other apps have better library organization.
Last week they released a change that put the header Strict-Transport-Security into all responses (yes, even non-HTTPS ones!). This broke not just BookOrbit, but every other app I had running on that server, because suddenly everything being served by that host refused to work without HTTPS.
I probably should have done it sooner, but I spent a big chunk of the afternoon setting up new DNS entries so I can access each app through a different hostname. That was easy enough for me, running OPNsense with my own internal DNS, but you may not have that much flexibility in your home.
I submitted an issue (see https://github.com/bookorbit/bookorbit/issues/760) and a few days later, they created a semi-fix such that the header is only sent out in secure responses. But this still has the effect of forcing every app on that server to require HTTPS.
