Glad to hear that! That’s an area of dsub which I appreciate: it’s pretty clear what’s cached offline and not, transitioning to offline is one tap away, and caching whole sub-trees of the library is easy and convenient. As a frequent flyer, I get that I might be an atypical user, but I rely on this very much.
Looks like it was caused by the “size of streaming cache” which I had set to 0 under the assumption/hope it would mean “unlimited”. Though I had to log out and back on for album art to effectively reappear.
Glad this project is alive and well! For strange reasons, covers are not displayed in-app (replaced by a generic placeholder) but do appear in the android media related screens (media controls, lock screen, etc).
You seem angry. It’s just too bad you couldn’t funnel this energy into learning and configuring nextcloud to your needs. It is actually pretty lean when you set it up properly. Anyhow, happy you found something you liked eventually.
They are going mainstream the same way fully autonomous cars are: in the wildest dreams of tech oligarchs on a deregulation crusade. Humanoid robots are actually a tougher problem to crack, and this coming up now is rather the sign of AI investors desperate to diversify out of language models, so when THAT bubble eventually pops, I’m not sure how much will remain of humanoid bots either.
There is no dedicated native mobile app yet (though there is a bounty for it), so the mobile experience happens via a PWA that is decent for browsing and quick editing, but lacks offline support
If you need semantic notes with typing and structure, nothing beats https://triliumnotes.org/ IMO/E
The pace of the project is moreover very high these days
For the record, it seems the project moved on, just without its previous maintainer, to github: https://github.com/tt-rss/tt-rss
Prosody is a great piece of software, and so is ejabberd which offers some perks. I can’t speak for the other servers (mongooseim, openfire, tigase, …) which I haven’t tried in a long time,
All that’s to say that it’s amazing that we get so many well maintained and compatible servers (and clients) implementations in XMPP-land, and all the implications for its healthy future.
I mean, a mechanical timer costs, like, 3 bucks in any currency and lets you set charge and discharge cycles. Add 10 bucks and you have one that you can pilot via REST API.
Don’t rip out the battery, that’s free UPS!
If there’s nothing utterly specific from the nextcloud ecosystem that you absolutely need, no, Synology has you covered
You seem to be obsessed with optimising one resource at the expense of others.
If you want to push it and paint me as obsessed about something, then let it be this: providing this community with on-topic and reasonable advice
you’re only going to save a few MB of RAM.
This is false, and you should read once again my previous message illustrating why: on a decent “self-host”-friendly machine, the same software may work very well, or not at all, depending on whether the user would engage with very basic configuration. This goes beyond RAM (memory isn’t the sole shared resource), and I’m adamant that the alternative (which was “pretending that the problem doesn’t exist” turned into “throwing money at the problem”) is unreasonable.
On the other hand, if you’re doing it to learn more about computers then it might be worthwhile. This is a community of hobbiests, after all…
Or more importantly: the extent to which you can self-host out of sheer luck and ignorance like you suggest is very limited. If you don’t want to engage with a minimum amount of configuration, you might bump into security issues (a much broader and complex subject) long before any of the above has a material impact.
I’m saying this based on real world experience
And do you think I would spend my time engaging if that wasn’t from my own very “real world experience” of lessons learned the hard way?
Bringing-up “diminishing returns” as if this was an optimisation game also doesn’t do this justice. Take the typical “household FOSS package” with software names often brought up in here: a nextcloud instance, a photo-sharing service like immich, private instant messaging, a software forge, a subsonic-compatible audio/video streaming server, a couple php websites like wallabag and RSS aggregators.
An Intel Atom CPU and 4GB of RAM is plenty sufficient for all that, and will cost you single digit USD a month, granted you put the (one-time) effort to tune and balance those services. Would you run all the above from upstream’s docker files, I can guarantee you that you would deem this (perfectly fine otherwise) server underpowered for the task at hand (and would probably go for a 10th gen or so Intel Core CPU, quadruple the RAM and 3-6× the energy cost in the process).
And that’s the point I’m making here: a self-hosting community of tinkerers should (ideally) know better, for the ethics’ sake of keeping the process environmentally friendly, and not wasting other people’s money.
Do you have the data to back that up?
I mean, you are the one making the exceptional claim that unnecessarily running multiple instances of programs on a device with finite resources has no practical adverse effect. Of course, the effects can be more or less drastic depending on the many variables at play (hardware, software, memory pressure, thread starvation, cache misses, …) and can indeed be negligible in some lucky circumstances. The point is that you don’t call that shot, and especially not by burying your head in the sand and pretending it’s never gonna be a problem.
Effective use of computing resources requires tuning. Introduction of a new service creates imbalance. Ensuring that the server performs nominally and predictably for all intended services is a balancing act and a sysadmin’s job. Services whose deployment settings are set by someone with no prior knowledge of the deployment constraints can’t be trusted to do a good job at it (that’s the nature of the physical world we live in, not my opinion), and promoting this attitude promote the kind of wasteful and irresponsible computing I was on about.
Now, I’ll give you the link to this basic helper for tuning a PostgreSQL server: https://pgtune.leopard.in.ua/
Will you tell me what are the correct inputs for my homelab (I won’t tell you the hardware, the set-up, the other services running on it, the state of the system, etc)?
And later, when you will distribute your successful container to millions of users, what will you respond to the angry ones that will complain that your software is slow, to no fault of your coding, because they happen to pile up multiple DBs, web servers, application servers, reverse proxies, … on their banana SoCs?
I disagree. You are just entertaining the idea that servers must always and forever be oversized, that’s the definition of wasteful (and environmentally irresponsible). Unless you are firing-up and throwing-away services constantly, nothing justifies this and sparing the relatively low effort it is to deploy your infrastructure knowingly.
Precisely what pre-devops sysadmins were saying when containers were becoming trendy. You are just pushing the complexity elsewhere, and creating novel classes of problems for yourself (keeping your BoM in control and minimal is one of many others that got thrown away)
Self hosting doesn’t mean “being wasteful and letting containers duplicate services”. I want to know which DB application X is using, so I pool it for applications Y and Z.
It says it’s federated. When you are your own provider, e2ee doesn’t matter nearly as much (you probably have a bunch of personal files, backups, services running on the same box anyway).
Edit: I would gladly take constructive comments with the downvotes. For a moment I thought we were on “selfhosted”, where “you are your own provider” should resonate in with most
I came to bitwarden because we needed to share passwords with my SO and the way those replicate seamlessly on all our devices (desktop, laptop, iOS, Android) is a no brainer. Since bitwarden/vaultwarden is full self-hostable and open-source, I don’t see why I would pass on its convenience.