The author literally spells out why this isn't always the case:
> Yes to start out it’s 95% booleans. But then you want a rollout. And then you want some targeting rules. And then you want non booleans… maybe some json. Oo wouldn’t it be nice if the json could conform to a schema… and then eventually you are like damn I really want to change these without deploying. Or you want to read the same flag from multiple services.
I really like that this exists, but I found the menus and UI to be rather non-intuitive. My main use case was to sync reading progress between my Kobo and my iPhone. I was able to do this using KOReader on the Kobo & the Readest app[1] on iPhone (also open source).
Ultimately I decided to get rid of KOReader because it felt a bit laggy. The gestures (eg: swiping up on the left side to increase frontlight brightness) didn't work well either.
I eneded up writing my own software to sync progress from Kobo to a KOReader Sync server[2] which my Readest app also connects to (love that unlike the Kindle, the Kobo is quite an open system). You can even set it up so you can SSH into it[3].
I really appreciate that KOReader is an option. On my older Kindle (first-gen Paperwhite), the default reading experience had declined until page turns take several seconds. Firmware update and factory reset wouldn't fix it. Using the default reader just wasn't a viable scenario.
I jailbroke it, launched KOReader, and it's like I have a new e-reader. The amount of customizability gets kind of in the way, but once it's set up I don't really think about it from one month to the next. I also didn't feel the need to upgrade my original install either.
Amazon bricked the first gen paperwhite, so I went on a similar journey. I started out making a single rust app on it, then went down the rabbit hole of trying to replace the shell/launcher. https://github.com/justinledwards/ferrink-home-assistant and "ferrink" is the launcher. It is pretty snappy on the paperwhite for what it is.
I tried to set up KOReader multiple times and always got stuck figuring out where all the settings are and how exactly they work. It seems very complete, but I'm just too dumb to actually use it.
I went through the same on my 10-inch Android tablet. The key is just sticking with it long enough to get it set up for your needs and prefs. I'm glad I did because it's really great. While the docs are quite good, if you get stuck just use an LLM. Once you get it configged, you won't be using the UI much.
KOR is both complete and very capable. It can very probably do everything you'll ever want but, as many people observe, the UI is just a bit weird. That's not to say the UI is broken or inconsistent, its simply that its approach is a little different than you'd expect. Once I got familiar with the main flow of the UI, it hasn't been an issue for my daily-use needs. If you care about flexibility, control, features and having it "your way", I think it's well worth the one-time effort to set up. It's also extensible with plug-ins and the UI is entirely user-moddable with Lua scripts. I use several found here: https://github.com/sebdelsol/KOReader.patches.
There's a search function hidden near the help menu. That was handy whenever I lost a menu item, which was frequently. I do like it now it's set up and it accurately reports the battery level, unlike the Kobo reader which says 40% then 0%.
I use the Project:Title[1] addon, I think someone else here on HN suggested it a few months ago. The only catch is that you need to update it manually each time after updating KOReader
I was a bit dumbfounded by the original KoReader browsing UI, I would have expected something more organized, but I thought "maybe it's just a setting I haven't discovered yet".
It looks like I need one of those instead. Will do when I have some time.
Does this support collating books of the same series together?
I also found all existing e-reader software to be lacking, and all I really wanted was a basic reader. I ended up writing my own with Rust and MyPDF (the latter doing all the heavy loading).
The hardware is great, but the software is pretty lacking. Apparently a lot of the tools out there are from folks in similar situation: had the hardware, but the software to drive it was lacking.
Love Obsidian but I've previously commented about the security model for plugins here: https://news.ycombinator.com/item?id=45308131. TLDR: your entire vault (and possibly filesystem) is exposed to every single plugin you install.
I really do think Obsidian needs 2 things to have any reasonable security:
1. It needs to be a lot more batteries-included. A user shouldn't need a plugin for basic functionality.
2. It needs a granular permission system, where each plugin should have to declare and prompt you to allow or reject specific permissions, just like on iOS and Android. The system should enforce that a plugin cannot bypass this.
> A user shouldn't need a plugin for basic functionality.
What functionality are you thinking of? I just looked and I've never enabled community plugins.
My Obsidian complaint is the opposite. I think its bloated well beyond the initial premise of a markdown editor over a directory of files. I think it was just about perfect right before the introduction of the Canvas feature.
Here are some feature I wish existed in Obsidian without any plugins:
* Dataview [1] (this is now solved with Bases, so I really appreciate that)
* Folder Note [2] (I, and I assume many others come from Notion, and I wish this were a thing)
* Recent files [3]
* A built in calendar [4]
* Link embeds [5] (or something to store previews for pasted links)
* Waypoint [6], or something to create a table of contents
These are just things I wish existed, but whether or not these are 'basic' can be debated. Ultimately I do wish there were a robust permission system for plugins so that personal functionality gaps can be plugged, but without compromising safety.
I had a recent files plugin but bases let me remove it.
I have a "system" base that I put on the ribbon.
it defaults to "recently created", but I have a bunch of different views for hunting down anomalies too.
There are many essential features missing that should be included in the core app for security, compatibility, longevity and for the benefit of new users who prefer to stay clear of plugins.
1) Basic functional search
Search should handle different order of words, misspellings (fuzziness), offer indexing and searching in a larger scope than just titles and aliases (e.g. headers or content), as well as allowing users to customize search priorities. Basically - just include Omnisearch as a core plugin.
2) Basic image preview
Displaying an image on full screen, with panning and zoom, when clicked upon.
3) Full "folder notes" support
Out-of-the-box support for a vault structure where each note has its own dedicated folder where all its attachments are placed. While the basic functionality is present, an external plugin is required to declutter the vault file hierarchy and actually make this approach feasible. Folder notes approach is in my opinion the only way to keep a large vault organized.
4) Basic formatting.
Text coloring. Text alignment and justification. Basic image positioning. Proper text flow wrapping around images. Table formatting (at least a setting minimum column width).
5) Markdown parsing within HTML tags
Basics Markdown features like [[linking]] don't work within a section of text enclosed by HTML tags. And using HTML/CSS is currently required to achieve basic formatting like centered or colored text.
6) Option to use the first h1 tag as the note title
I'm talking about actual support for this and integration with core functionality like search and linking. Useful (sometimes long) titles are an essential part of note-taking and knowledge databases. Meanwhile, filenames are simply semi-unique file system identifiers. Forcing users to use filenames as titles compromises the usefulness of titles and leads to issues with filename / filepath length. In HTML and Markdown, the h1 tag was always intended for the title.
7) Consistent formatting between reading view and editing view
Rendering of content, especially vertical spacing between elements differs between those views for no credible reason. The code syntax highlighter is also deficient in editing mode, despite it being the mode in which Obsidian users spend 99% of their time while writing, editing and reviewing notes.
It's not an exhaustive list, but these are the biggest pain points right now. And let me repeat - you shouldn't continue to rely on community plugins for these features. Even though community plugins are great, they are a security concern, their development could cease at any point, and new users don't know about them.
IMO that site overcounts downtime. If you filter for major and critical outages (the kind that make the front page of HN), the story is still bad but it’s not 84.92% bad.
I think it's like some kind of collective inferiority complex. Nobody really understands things anymore but everyone is afraid to point out mistakes of others because they are scared to come under scrutiny themselves then.
I think the default position people like to take generally is to just go with the status quo. GitHub has reached status quo level. As in "nobody ever got fired for choosing GitHub". It's the only forge I've seen advertisements for in the meatspace, and even non-technical people know about it. On job applications, companies ask for my GitHub URL. I think it'll be awhile now before they get abandoned. That said, I recently started moving my stuff over to Codeberg. The change needs to start with us, the people writing software.
Why is it easier to submit a bug report if my bug reporting system is run by the same company as your code repository? Why are those things even slightly related?
Because users and community contributors most likely already have an account, are familiar with the UI.
There is also the "gamification" aspect that GitHub have. Doesn't motivate me personally, but could have effect on some others.
Projects on GitHub gets a lot more visibility.
To the point that many projects that do not use GitHub as their main forge are still often mirroring their repository there, and have to deal with double source of bug reports or pr.
The thing about an SLA is that once you’ve broken it you’ve lost the trust. It doesn’t _really_ matter what the cost is for breaking it, nobody chooses their platform based on the refund they’ll get if they’re down. But they absolutely do choose based on reliability and uptime. The enterprise SLA refund credit will show as a (big) metering blip, but the problem is the people who signed the contracts are going to be speaking to Gitlab now
> Yes to start out it’s 95% booleans. But then you want a rollout. And then you want some targeting rules. And then you want non booleans… maybe some json. Oo wouldn’t it be nice if the json could conform to a schema… and then eventually you are like damn I really want to change these without deploying. Or you want to read the same flag from multiple services.
reply