https://grapheneos.org/releases#changelog

feels so weird not being in the daily capybara struggle session 😔

That's a common convention in academic papers to demonstrate pairs of correlations, it's the same as writing

"We also find a positive correlation between cognitive ability and realistic beliefs AND a negative correlation between cognitive ability and pessimistic beliefs."

https://awesome-selfhosted.net/tags/document-management.html#paperless-ngx

I stopped using Paperless-NGX for this reason. It eats RAM and CPU insanely even after configuring it to stop doing OCR and no ML. I wish there is a Go alternative.

Capitalism 1 billion dead

Agree with your analysis, just pointing out that Phoronix forums have always been like this, or at least the tendency is to insult each other. Their culture is more toxic than any other Linux forums I've seen, maybe besides /g/.

"Be the change you want to see in the world."

But anything that requires configuration...should have a fully functional GUI.

Does this apply to ones with only 4 or 5 options to configure, where's the cutoff? Configuration files set the default flags and arguments, and a lot of command line tools that are configurable are small and simple enough that making a GUI just to configure it is not worth the hassle, the increased complexity and codebase size. The idea is that if the software is one or a few executable binar(ies) with enough flexibility, then contributors who's proficient with GUI toolkits can write the GUI wrapper (as a separate package), otherwise it's actually just a waste of time for the main dev(s). If that sounds reasonable, then you could write it yourself, pay someone to do it, or wait for someone to volunteer their time.

To address the problem itself. Maybe you should explain what problems you have with editing the configuration files yourself? I know the cons are: (1) having to know or be able to read toml, yaml, json, ini, or some kind of config syntax (but I think they are designed to be generally quite easy to understand), (2) it takes a bit longer to find and open if you're not used to it, (3) everything is a file so it's linear, making it harder to see where things are, so longer configs are a PITA. Good tools I think benefit from a GUI or TUI is TLP, archive managers, calculators, volume controllers, font manager or viewer (kinda obvious), why would you want a GUI to configure, e.g., bat, pacman, i3, dunst, all the xorg stuff like xresources, xmodmap??

In return, the pros are: (1) if there are no external docs, the docs can stay inside the default or sample configuration in the form of comments, whereas for GUI you can't possible include this information for every single toggle, (2) it's harder to version control because of increased abstraction, (3) it's not possible to translate every configuration field to a GUI if it's beyond just a toggle, you would still have to type things in.

I think having an extra GUI wrapper is a matter of complex balance, and made into reality by contributors and volunteers (or eventually, the devs themselves). To say everything should have a FULLY functional GUI if you have to configure it is a bit of an exaggeration and overreach.

Monitoring. Try out Prometheus/InfluxDB and Grafana, throw Loki in there too... It'll keep you busy for a few days to a week at least.

I did all of that and I just use Netdata now.

Mobilism most of the time and also Telegram channels from modder groups.

I agree that the experience on Linux is quite variable; I set up my Linux installation to play games once 3 years ago (it didn't take me hours) and my Steam games are plug and play. I don't play all the games from those lists but RDR2 plays perfectly fine for me. Occasionally, there would be updates that would introduce a regression for some games (DX12 is still a bit hit or miss on some titles) and it would take a few searches to find a workaround, but I can accept that, since I can stay on an OS I trust and would rather use. Rarely, there would be a serious bug or issue that I find difficult to triage because I can't tell whose fault it is between Proton/Wine, Steam, Nvidia etc. But this happened once in the past few years.

I think what would help is Steam making their own Wiki (with contributors) on gaming on Linux for its own platform for players who just want a streamlined experience.

But communities like /c/linux_gaming (or its orange site equivalence) are ways to get support and help one another. You could even see it as the "friends you make along the way".

I would say gaming on Linux has come a long way since, but depending on how much time and energy one has for the occasional tinkering, one might need to exercise more patience. Sounds like Windows gives you what you need, and that's okay.

If it's all URLs, you can look here: https://github.com/awesome-selfhosted/awesome-selfhosted#bookmarks-and-link-sharing. I use linkding myself and save everything I want to look at later, avoiding the need to "save" or "pin" posts. Other solutions can also offer offline caching locally too.

Most services have installation for Docker. I started from knowing nothing about this stuff (albeit quite tech-savvy) and I would say my favorite route is with Docker compose. Don't bother with tutorial videos or courses, this isn't a theory-based activity but rather a practical one. For simple services (I'll come back to this in a bit), you want to skim through the documentation and look for the keywords "Docker" or "compose". Copy the file content as needed and fill in the gaps with the details as you personalize the service. Learn how to convert Docker run commands to compose. Use issue trackers, this community, the old reddit community to look for similar setup and inspirations.

Now, you want to self-host Firefly, Immich, etc. These, as far as I know, all have good docs and a compose file. Immich is a bit more involved. And a lot of them use big separate databases. Database administration is a bit scary, but hopefully, you won't need to manually intervene or fix a broken database until you are better adapted to the world of self-hosting. Run backups, and do what I should have done: test run services before using it in production. Let's say you want to run Immich. Start it up, and upload a few test files, and try to use all the functionalities. If it breaks, you don't lose anything and can run the real thing when you're confident it's what you want.