eavotan

Sorry my statement was not clear.

I meant I was loosing interesting articles on my RSS server without filtering. I won't be loosing resources that I have already archived.

On the other side, having so many sources allows me to find articles about one topic and group them. Making future research for reporters easier. At least I hope so.

[edit0 grammar and typo]

I just don`t do it. One could use a service in between, which opens up pay-walled content. But for me it`s not worth the hassle. Even if I`m loosing high quality content ... which is only available on one site.

I blacklist "bad" sites that don`t care about freedom or sites that just make life harder for the reader. Like unnecessary advertisement, binding the core functionality to cookies and/or javascript, being not international, copying from other sites ... those criteria can sum up to a overall bad user experience. Those criteria are only "bad" for me in the context of news and blog sites.

Almost.

Those bookmarks are more or less the tip of the iceberg. And they were almost all created during $DAYJOB which was years ago. Although already then (~2017) i had about 3500 sources in my RSS Server. And of course, I lost track of everything remotely interesting.

Archiving those links was fundamental work for creating my news blog, which is still run privately until I figure out how to implement a community communication system (mostly commenting) that will work on an IPFS backend. I mean, the comment section of HN is what has made me come to this site for years.

+1 for posteo. they are transparent about who wants data from them. https://posteo.de/en/site/transparency_report

came here to say this. zotero also saves metadata as an extra. as long as it is used from within a browser.

If you want to support multiple platforms this is the way to go. I don't see a problem with it.

We have the freedom to use different package managers. It comes, likes everything else, with it's own drawbacks.

The lack of information. Most install docs tell about installation requirements. One-liners don't.

> Not knowing what the script is going to do.

This is more like: not knowing what to do, when it doesn't work. And this is always the case until it works. Which is just a local Phenomenon and i can't expect things that work for me to work for others. So why don't write an expressive installation documentation with multiple steps instead of one-liners that either work or don't. There is just no in between.

Take the installation instruction of syncthing for example:

    curl -s https://syncthing.net/release-key.txt | sudo apt-key add -

    echo "deb https://apt.syncthing.net/ syncthing stable" | sudo tee /etc/apt/sources.list.d/syncthing.list

These two steps are hard to automate, if you don't have an interactive shell.

Same goes for the saltstack-boostrap-script. This script doesn't work on all platform equally good. This is not an reliable state. So in the end I'll stick with the normal way to install things which is very easy to automate.