I wrote a short guide on this method recently: https://lemmy.ml/comment/6708735

Wow I feel dumb for not thinking of that. In my defense I like the text as #FFF on gray. KOReader’s arbitrary CSS snippets and style tweaks are really neat.

This is all I needed to do so: https://www.mobileread.com/forums/showthread.php?t=314220

Run the script from the second post, then eject the Kobo and let it install. Afterwards you can open it from the new NickelMenu button at the bottom right. My Kobo just stays in KOReader mode all the time.

You can change the background color by changing the ["cre_background_color"] key in settings.reader.lua (again, I dislike needing to configure it like this). On my Android and desktop I set it to ["cre_background_color"] = "0xECECEC",, which inverts into a nice gray when I set it to night mode, then I invert all the image colors so they’re a normal color. Font color can’t be changed though, TMK. You can change font color with custom CSS snippets.

deleted by creator

Have you tried KOReader yet? It’s not Material UI and doesn’t have any sort of “theme”, since it’s very focused on just showing your text, but it lets you extensively pick fonts and styles for your books, has dictionary lookups (tap and hold), page view, and it can sync with itself (available on the desktop and many physical ereaders). My main gripe is that it’s very configurable, and I don’t personally like many of the defaults. After setting it all up it’s quite powerful, and I use it on my physical ereader, Android phone, and desktop PC in roughly the same configuration.

That was my takeaway from this video as well. It was a lot of “aw shucks can’t we all just get along” and not understanding that in today’s world, getting along is a left-wing policy. I think there is still merit to saying that part of the reason we’re so divided nowadays is that we are forced to interact more often, but it shouldn’t be represented as the entire problem. In a way, I think a video like this is actually worse for discourse because it might convince people that there is only one problem that needs to be solved.

I use FreshRSS on desktop (web client from my self-hosted instance), and Readrops on Android (synced to my FreshRSS). For Lemmy notifications specifically you’ll likely want a dedicated client that is noisy. I was using Brief for this task temporarily, with only one RSS feed loaded and having it set to delete all but the latest message.

The app I use (Eternity) has options for 15/30/60/etc mins. You can theoretically get notifications every second if you set up your own RSS reader to check that quickly (though be considerate of your instance’s resources). Before I settled on my current solution I had an RSS reader check every so often and ding a desktop notification when it found something. I use 30 minutes because if I’m using Lemmy I’ll see the notification alert anyway, and if I’m away from Lemmy I don’t want to be notified potentially every 15 minutes when people keep replying.

Your inbox has an RSS feed that you can hook up to whatever RSS reader you want. Personally I let my Android app watch for notifications every 30 mins, and then KDE Connect will mirror that notification onto my PC when my phone dings.

Yeah I wouldn’t bother. It intends for you to have a duplicate copy on every device, which is probably not what you want. Syncthing is really good for things like synchronizing notes, calendars, password databases, music, etc to your devices. Things that you want to access in both places, but that are usually disconnected from each other from time to time.

Conduit is also licensed under Apache 2.0, so it could also be taken closed source at any point in time. The reason this wouldn’t impact Conduit as much is that there’re other contributors, whilst Synapse and Dendrite are almost exclusively developed by Element.

Right. The current perspective is based on the idea that if Synapse/Dendrite go closed-source right now, an open source version would be good as dead. Element is responsible for 95% of Synapse/Dendrite and I’m sure a community fork would have to play a lot of catch-up to figure out how to keep it going. If the community was more involved in Synapse/Dendrite implementation (and if Element let them) there would be less cause for alarm, as closing the source would just mean an immediate community fork and putting Element on ignore. Also to reiterate, The Matrix Foundation is not going along with Element on this move, and even if Element pulled something shady the Matrix Core Spec etc. would still remain open and under the Foundation’s control, so the max we have to lose is Synapse/Dendrite and all of Element’s developers.

As for the rest I agree and I do actually trust that Element is simply playing their only card here. These maneuvers are all required in order for Element to survive as a company at all, but they also unfortunately leave this backdoor open as a consequence. Matthew has pinky-promised over and over that they are only acting in good faith and that they would never use the backdoor, but it’s understandable that the presence of the backdoor is putting everyone at unease. Best case scenario we take this as a warning sign that if Element drops dead tomorrow then Matrix is also dead. If people want Matrix to not be practically owned by Element then we should diversify and prepare escape plans.

It depends on what your workflow/usecase for putting documents on the drive currently is. Syncthing is usually intended to be put on two separate devices, and then a folder on each device gets synchronized - meaning you have a folder of your documents on each device. Is there any reason not to just mount the network drive’s folder and drag the documents in that way?

This is actually quite a controversial change mainly because of their switch to a CLA. This indirectly gives them the opportunity to switch the license to closed source whenever they feel like it in the future. Semi-controversially, they are also primarly making this AGPL change in order to begin selling dual-licensing to companies. The Matrix Foundation itself does not support this change from Element, though Element is within its rights to do so.

You can read some more thoughts on this from the pessimistic folks at HackerNews. My main takeaway is that I don’t trust Element because I don’t trust anyone. I’m sure they’re doing this in good faith but I don’t like the power they have at the moment. I hope this is what’s needed to begin focusing efforts on alternative homeserver implementations like Conduit.

Syncthing - No introduction needed. Couldn’t live without it.

Healthchecks.io (you can self host this) - Dead man’s switch monitoring for all my automation. Most of my automated scripts hit up a Healthchecks endpoint when they run, and if they fail to hit the endpoint on a regular schedule I get notified. Mandatory for my anxiety.

Catbox has been operating for at least 8 years and has a clearly defined server cost + donation plan through their FAQ+Patreon, which also notes that they are happy to front any extra costs that the Patreon doesn’t cover. I’m going to guess they’d rather shut the site down than start serving ads.

catbox.moe should work

Architects vs developers.

I prefer recertified ones if they’re significantly cheaper, but that’s up to you. Recertified will likely fail faster but when they’re close to ~60% of the cost it makes sense to gamble.

As for which RAID that is up to you and how you’re setting up your array. If you’re running ZFS then mirrored pairs are somewhat flexible since you can add a pair whenever you want of any size disks, but they will cost you 50% of your disk space in redundancy. For RAID5/6 you want the disk sizes to match and for ZFS you won’t be able to add any disks to a RAID5/6 array for about a year - the code that adds that feature is coming in the next release which will take about a year.

I’m not sure what’s around for Germany, sorry. You may be able to use eBay to find local sellers cross-posting from their normal website?