AFAIK: Lemon Squeezy is owned by Stripe and development is discontinued; I sold my software via FastSpring before I switched to Paddle, it is not very modern and you have to bring a lot of your own implementation; Paddle is quite easy to set up; more modern providers like tiun from Switzerland offer MCP so AI can do the setup for you (probably Paddle can as well)
Sloppie's own icon images are broken if you run from source since they're loaded from the icon theme. That works after installation.
Fonts and editor are pretty much about this part of the README:
> Sloppie is hard-coded to its author's preferences and not generic or configurable. If you like the concept and want to use Sloppie, instead of installing and using it directly, you'd likely want to clone the repository, ask a coding agent to customize the font, colors, editor etc. to your preferences and use that clone instead.
The UI fonts should have fallbacks, but the terminal doesn't.
Regarding the editor, note that it's also launched with line or line + column arguments and against the directory if no file selected — all of which work in Emacs, but not in all editors.
Give it a try! The main mechanics is coding agent + git, which should just work.
The vendor lock-in trap does not apply here. Users don't actually even run the original weights, they mostly use open source inference engines with open source agent harness. If AI provider decided to start charging, a) released models would not be affected, and b) people would drop it instantly and move to other models.
The actual problem is that we know nothing about the training set of any open-weights model. They could be intentionally biased to influence users, from political censorship to brand advertising, or general shaping of cultural norms. You run the model on own hardware not knowing if it is designed to act against you. Having whole chain open source would allow audit and reproducing the results.
The Qwen team published the same sampler settings for 3.8 and presumably they used those while testing on benchmark. Do you believe they could have achieved higher result with top-n-sigma?
I like that there is a fallback to read the full text, but why are there two such app modes? I think if the main (non-popup) one should absorb the other's features like scrolling and bookmarks.
For some texts the layout is also important to understand the context. Poems, structured text, paragraph breaks. If you read word by word and stumble into block of structured text, it's a lot of friction to figure out. I would love a background low fidelity representation of paragraphs, like the minimap in code editors, with the current word highlighted there. It could be passively monitored for places to switch mode to reading the full text, and to keep spatial orientation around character dialogs and such. It would have to not draw attention to itself though.
The theme circle icons are not useful, they should preview text background and color.
I see Dyslexic font is already built-in!
Code is not available? It would be fun to hook this to browser extension to fast-read article in a ReadKinetic popup.
I didn't mind the controls at all, they are obviously for touch and not mouse and it seems inspired by video player controls. This is a kind of app that you spend hours with, so better to have more features and options than to be beginner friendly. Very nice app, I like it so far.
The minimap is, in fact, the best idea anyone has given me today (and I think it addresses a concern 3 other people brought up in this thread). The underlying problem with all the suggestions is that you lose all the scaffolding, the paragraph breaks, the line spacing, the sense of where you are in the text that makes it easy to just jump into the text anywhere in the first place. I think this peripheral low fidelity map addresses it because you don't have to actively engage with it. Your concern about the control to not draw attention from the text is the entire point of this design. You can't make it too salient because that makes it steal the focus from the main text, which defeats the entire point.
I already have the info on paragraph and chapter breaks in the reader already, so this is more of a rendering issue rather than info display. The reason why I particularly like your first suggestion is that it lets you know something like a poem or different paragraph style is about to start so you can change your reading pattern accordingly rather than stumbling into it when you're already in prose mode reading at 400 wpm.
On the 2 modes thing, I feel like there isn't really a good reason to do it the other way. It was more that it happened that way rather than it needed to happen that way, and you're right that the main one should probably scroll and have bookmarks rather than making the user make a choice between 2 different interfaces.
Theme circles is definitely a solid suggestion, being a more practical implementation of visualising the underlying theme. Being able to see the actual colours of the background/text rather than an abstract blob is good, so that's a definite maybe.
Code isn't public yet, but extensions are something I've wanted to try for a while. In fact, someone sent me an email this morning asking precisely for that, to be able to paste a link and read articles. It can't be done directly in the page because of CORS policies, and doing it server side would involve routing the reading of articles through my server which is probably not ideal for everyone. An extension that pulls the article from whatever page you're on would be the most ideal version of this, from a privacy standpoint, so I'm considering it.
And finally, your last point is actually the first pushback I've had all day on the controls/interface. As far as 4 other people having difficulty finding the thing, I think you're right that something needs to be done, but I don't think hiding the options behind discovery is really the answer. There is a conflation in my brain between 'controlls are easily found and accessible' and 'controls are not hidden beneath layers of menus/bookmarks', and I think it's a false conflation, I had been treating them as one. Thanks for that.
Computing power is crazy cheap and does not help. The perceived slowness is because the taken measurements are averaged over second or so. When you step on the scale your weight shifts around and that affects the measurement by far more than half a kg. Averaging gives you better accuracy and more confidence in the result but it doesn't improve the measurement precision.
The scale precision comes from calibration of the measuring mechanism done on factory line at certain weights. If your specific body weight is far from the weights used in calibration, or too much time passed, then the calibration doesn't help much.
A better microcontroller doesn't help at all. Even a cheapest uC from decades ago is good enough. Better ADC and gauge sensor would help, but even more important is good analog engineering to produce self-correcting circuits with decent noise rejection.
In general this category of products is more for tracking changes in your body weight than getting the precise absolute value. And the body weight changes a lot just from hydration level, so the ±.5kg tolerance is considered good enough.
My fine spice recipe writing scale (20g max, 20k count) consistently over years of me having it keeps it's magnitude calibration of the 10g reference to a single digit count, i.e., comfortably within +-0.1%.
Ofc there's auto-zero on start involved, but translated to a people bathroom scale that'd be "comfortably better than +-100g".
A precise bathroom scale just would want a bit more effort on drift prevention as a sample mass at this scale is rather unwieldy, and critically it'd need a toe-operated button to select that you've finished climbing onto the scale, upon which it starts averaging the load to progressively improve the weight measurement accuracy. I'd expect using a bounce-height-freefall-duration based length of timing uncertainty at the start and end of the averaging period to allow proper Bayesian uncertainty quantification of the shown result, say by displaying both the 10th and the 90th percentile on the display which grow closer as you wait while standing on it.
With some cleverness a compact calibration mass might be usable to calibrate absolute scale, transferring up to the "people" range using just a random assortment of stuff that fits on the platform, totalling around 10kg.
Because building the scale to be linear in response good enough for 20k count of resolution is pretty straight-forward.
Thank you for sharing your domain knowledge!
reply