KOReader is one of these projects where idea is fantastic, it's impressive that it works, and the result is sufficiently quirky that I couldn't get used to it. UI is cumbersome. On kobo, it feels like it's draining battery much faster than the "regular" kobo OS. When you sync progress to KOSync with WiFi you keep getting these "Connecting to wifi" popups. And on mobile, having to use the internal keyboard feels like using the keyboard on a reader, which I do not want to.
I've never used it on Kobo (as I don't have one), but I felt that for the Kindle KOReader it was a significantly better experience than the stock experience. It's easy to sync stuff with Calibre, you can choose any TTF font, and there are more display options for reading. At least on the Kindle Paperwhite (purchased in 2015), it does not appear to significantly affect battery life.
Maybe I'm just too entrenched in the engineering space that I'm just used to "developer UI", but my wife is decidedly not a software person and she seems to like KOReader just fine.
Is it though? Engineering is providing the cheapest solution that corresponds to what your customer asked. As it goes: anyone can build a bridge with infinite budget, only an engineer can do it for cheap.
A system that's un-necessarily complex for what it does is over built, and under engineered.
I think it's important beyond semantics, because sometimes you have to propose designs that wouldn't be in books, yet they're the cheap and fit with all requirements, and are thus well engineered.
Now the difficulty is to figure the requirements that are not being expressed. "Allowing an occasional resurfacing" and "don't explode when there's icing" are obvious ones; the hard one for our job are "allow for adding another lane" or "allow support for trains as well"... because you know these might come.
I think they already tried rewriting billing with AI. Very smartly they only tried rewriting the estimator first. This post is about the outcome of it.
Weekend is too long bro! With AI they can weite 50 implementations in a single prompt. They clearly are using tooo many humans and that's why they're lagging
Storage-based billing is huge, unless you mean something other than “places that make you pay for storage separately”.
Also many places I’ve worked, storage is a huge part of the spend but that depends a lot on what you do. e-commerce doesn’t use a ton of it, but if you handle user-generated content or do any kind of training (LLM, computer vision, etc) then you can very much end up in a place where storage becomes a top line number for infra spend.
GitHub pre-Copilot was probably like that. They host a shitload of data, most of which is just at rest the majority of the time. Storage and networking are probably the majority of their infra costs.
Oh, I also don’t think I’ve ever seen that but I’m not surprised. Even if you could steal a huge amount of storage, filling it with data would take ages and the cat and mouse game of moving the data as hacks get uncovered would be untenable.
I have seen things get hacked for bandwidth, back in the days before you could rent a gbps uplink from the cloud for $0.12. Some scene release groups would hack into universities or companies to do the initial seeding over their super fast links. It used storage, but that wasn’t really the goal.
Like kgwgk already said - people post the occasional horror story where they run up a huge AWS bill, either due to a run-away process or getting hacked. It seems to almost always be about Compute, not Storage.
> and they also imply deleting all your data so that you don't pay for storage.
Not necessarily. They could imply that your storage becomes inaccessible immediately, but only gets deleted after some time period (say, 1 month). What spending limits do depends on the implementation.
How would that work? If you only pay for one day, your access (read and write) gets cut off after the first month. Then if you don't pay the bill for the entire grace period, your data gets deleted.
Not only can you not set limits, even the alarms are not real time. So it is entirely possible to get on the hook for terrifying amounts of money and not know until it's all too late.
> I have to call MINI at some point and demand they fix this garbage
That would never occur to me. Whenever something produced by a large company breaks, I pretty much assume there's no signal possible back to whomever is responsible for the breakage, and that whatever is broken now is broken forever.
To the author's point, they're A-gile, but forgot that the first step in the process was customer feedback
Tell that to Volvo. They even state on their feedback form that they don't respond to feedbacks, which IMHO is a polite way of saying that they don't read the feedback but still need a form, because no form would be bad publicity.
The EDPB has explicitly ruled on that, when it comes to age verification^1, you should delete: "Trust models are crucial to prevent data breaches in age assurance contexts [...] once the user's age is verified, no record of the personal data used for the age assurance process is kept".
They most likely weren't allowed to keep it past the verification per GDPR art.5. Once the passport has been verified for whatever purpose they needed it ("age verified to be > 18yo on 2026-06-12" or "identity verified to be XXXX YYYY"), there is no legitimate use for the passport photo and details anymore, and they should delete it.
(I'm naive in this area, but..) I wonder if the various "proof of age" laws coming into play will clash with the GDPR in insidious ways. Like requiring identity providers to hold definitive "proof" of why they made an assessment rather than merely proving and discarding. I assume/hope there is some cryptographic way to do this rather than hang on to passport and ID images, however.
There are established ways / protocols to hold and provide cryptographically valid proof of a verification process, without any need to keep the actual id images in any storage. And to my knowledge there is no requirement for compliant KYC (Know your customer) to provide their ID as a proof as long as the verification process itself is compliant and audited in accordance to certain criteria.
You can compare this in a certain way to file hashes. A successful verification with a predefined minimum level of credibility can be encrypted to a special string for later being used, if a service needs to verify the person again. It doesn't matter then, that the original passport images or video ident has been deleted the second after id verification has been completed.
I'm somewhat knowledgable on privacy topics, pasting my answer to another comment:
The EDPB has explicitly ruled on that, when it comes to age verification^1, you should delete: "Trust models are crucial to prevent data breaches in age assurance contexts [...] once the user's age is verified, no record of the personal data used for the age assurance process is kept".
> Zero password protection on document storage systems
>
> No encryption for sensitive identity verification data
>
> Public URL access with no authentication requirements
>
> No access logging or monitoring systems in place
Pretty much the bingo of secure storage, even CTF demos make it less obvious. Storing a document that they have no business keeping in the first place, with no security whatsoever.
reply