• 27 Posts
  • 789 Comments
Joined 3 years ago
cake
Cake day: June 22nd, 2023

help-circle








  • While I don’t exactly intend to run RAID, I ended up choosing nas drives for the 24/7 intended usage,

    The purpose of a NAS drive is to be LESS reliable than a regular drive, not more reliable. Explanation: if a regular drive gets a read error on a block, it will retry for quite a while before giving up. The host, meanwhile, has to wait for the data to be retrieved if the retries work. That’s all it can really do, wait and hope. Meanwhile, the waiting slows the application down.

    A NAS drive instead will fail once or twice, then give up immediately, since it knows that it’s in a RAID system and that the data is also present on other disks. The RAID then puts the data together from the other drives and gets it to the host, logging the error. It will also hopefully mark the bad block on the drive with the read failure, and rewrite the recovered data to a spare sector. So this is faster than all the retries even though the drive that had the bad block gives up on it rather than attempting recovery by repeated reads.

    So if you buy NAS drives, put them in a RAID.

    Drives are currently around 2x as expensive as a year or so ago but they are available if you can afford them. I guess that’s better than shortages where they’re hard to find even if you can pay. We’ve had that before too.

    I like to think the current situation will settle out. Who knows though. Drive space is still way less expensive than in 2010 or anything like that.





  • The webview isn’t supposed to show the bloaty page directly. Your client would retrieve the bloaty HTML, strip the junk out or maybe completely reformat the page, and then show the “purified” page in a browser. I did this for a while with local proxy cgi’s but they eventually stopped working due to AI bros over-scraping everything. Also, are you going to write custom de-bloating for different sites that your client reads? It helps quite a bit. I can send you some of mine if you want.

    Yes a normal web page can’t pull arbitrary feeds but I had thought there were permissions you could give to enable that. Like I think Manifest v2 lets you turn off the cross origin check, so you could write a Firefox extension. But, they shut down Manifest v2 in Chrome in order to prevent ad blockers from working.


  • We already have lite.cnn.com and there must be tons of RSS readers already? Emacs’s gnus.el has an RSS reader that I use on my laptop if that helps. It’s probably not usable on a phone.

    Anyway, I’m supportive of the idea but for the same reason, I don’t have a Play account. If the app eventually shows up on F-droid I might give it a try.

    The name “Compass” must already be in use for tons of other things, fwiw.

    Why a built in reader instead of a web view? Don’t we already have too many apps with their own special text UI’s?

    In fact I wonder if the whole thing can be done as a static web page with local storage and permissions to retrieve the remote RSS, if that’s a thing. Or it could be a very simple standalone httpd that a local browser could point at.

    There’s another issue, which is that news RSS feeds often only give you the headlines. Here’s an example:

    https://www.sfgate.com/bayarea/feed/bay-area-news-429.php

    if you want to see a complete story, you have to click a link that gives you the usual bloaty web page full of ads. It’s fronted by the now-common bot detection stuff so you would have to do some fancy scraping to get the underlying page into your special client. If you want to go that route, you probably have to orchestrate a real browser anyway.