@JessTheUnstill: I have a strong feeling about this point. It seems to me that as a society, we've been too willing to allow a hierarchy between "developers" and "end users" to creep into the "software products" that we use, and I believe that technical means encouraging people to see, and treat, software not as black boxes but as systems of rules that can be modified on the fly would help neutralise the worst abuses of this unpleasant development.
I'm not entirely sure how to get there yet, though. In the context of web browsers, adding simple and powerful tools to enforce the notion the user has power over what happens in the browser, by means of easy-to-use archival and scraping and "content" re-formatting tools would probably be a good start.
@riley @JessTheUnstill@infosec.exchange @ariadne@treehouse.systems (Disclaimer: I can't see the original post that this is replying to)
Something about this that has been annoying me forever... it's *very difficult* to build a system that is manipulable in this way without losing its security and reliability properties.
That doesn't mean that it's not worth doing, of course, but it does mean that the 'obvious' approaches generally work very poorly, and that it's a Big Problem that you can't really work towards incrementally, because if you start with a quicksand foundation, it can never become reliable later.
At the same time, very few people seem to be interested in figuring out these Big Problems properly, instead choosing to work within the 'status quo' framework of hierarchy. But the people who *are* interested in changing this, often don't recognize the complexity.
So in the end we just end up with a lot of unreliable user-manipulable tools that then further entrench the belief that "this just isn't possible" :/ And I'm not sure where one would even begin to fix this problem...
@forestjohnson: I'm intrigued. Please elaborate?
@riley @joepie91 @ariadne@treehouse.systems
Well first of all there has been a proliferation of "sysadmin app-store" projects that dramatically cut down on the amount of linux config work that folks have to do in order to do web publishing on their own hardware or to operate their own web services. Here are some of them:
https://coopcloud.tech/
https://nextcloud.com/
https://yunohost.org/
https://syncloud.org/
https://freedombox.org/
Second of all, more and more important "types of things" are seeing new application releases that have dramatically improved usability for the sysadmin -- remember how much of a massive PITA it was to set up WordPress? Well now you can set up Ghost with just a single `docker compose up`. In the past if you wanted to host your own video livestream... Good luck. It would have been very arcane and prone to the reliability issues that joepie was talking about. But now there is https://owncast.online which is very simple to set up and works reliably every time.
IMO Owncast is a great case study / inspiration on a very usable app that is friendly to the less-technical sysadmin. Gabe did an amazing job with it within the technical limitations and challenges of live video streaming... I would love to see more apps like this and honestly I think we will.
@forestjohnson @riley @ariadne@treehouse.systems I cannot speak for Owncast, as I don't have experience with it, and also don't have sufficient third-party reports to go off.
However, the "just wrap it in a Docker container" is exactly one such example of an 'easy solution' that ignores the complexity of the problem; while the installation is certainly made easy, in practice I see this causing a constant barrage of extremely-hard-to-debug failures down the road, missed updates, insecure configurations, and so on.
This is kind of what I was getting at with my previous comment, albeit in a different context; for things to be accessible, they need to *keep* working reliably into the future, but almost all of the work around what I'll call "sysadmin accessibility" calls it solved after the installation step.
Very few people are interested in dealing with all the hard and icky bits of keeping it working in the long term (which will frequently involve actual technical changes to the software and its architecture).
@joepie91 @riley I don't think it matters that much whether its a docker container, OS package, git clone, etc. All of those work with ghost.
Point I was trying to make is, ghost is more self-contained, it "just works", it has its own sqlite that it uses if you don't configure a db connection, for example. Its minimum viable setup documentation is at **least** 3 times shorter than oldschool WordPress.
And hey, if someone uses one of those sysadmin app store projects, chances are they're a click away from a working secure config for ghost that receives updates.
Docker may not solve maintenance but in my experience it makes maintenance way easier, but that's neither here nor there. Some people like it some people hate it. But I'll say I've been using ghost for about 8 years, most of that time in docker, and besides having to do some maintenance on my custom template, I've had zero problems. I never had to go into the container to fix something, just upload the new version of the template into the web UI. Or take / restore a backup using the web UI.
The point of what I'm talking about: this software does not force me to live in the CLI. I can set it up once in CLI and barely touch it besides version upgrades for like 8 years. And when i do have to go into CLI, i'm always just editing docker compose. When I update the image version, no need to worry about nodejs version conflicts with other apps or anything like that.