@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...
@riley This is more or less the approach I've been taking personally; but I've found *very* few other people who are willing and able to collaborate on that topic without trivializing the complexity of it :/
@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.
@riley @joepie91 @ariadne@treehouse.systems
Not to mention the very platform we are talking on right now is a testament to the progress made towards breaking down barriers between users and admins.
Mastodon / other ActivityPub projects have a lot of the same pain points that wordpress did, or worse, but the fact that this network exists at all and is growing (it seems to have achieved enough "network effect" to "take off", i.e., its not going to disappear in a year) is definitely something.
5-10 years ago those "this just isn't possible" people would have claimed that something like the ActivityPub network will never happen because its too hard for sysadmins to build and maintain something that users will continue to choose to use _**instead of**_ something like twitter.
@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.
@joepie91: May I suggest collecting the most obvious approaches, and carefully cataloging the ways in which they're broken, so as to try and bootstrap some resemblance of iterative approximation?
(My thinking here is, a major reason making this field hard to think about is, we've got a bunch of ill-conceived intuitive social assumptions about how society should work, and they tend to repeatedly clash with common just as intuitive engineering ideas about how computers should work. By making these assumptions explicit, by laying the problem field out in the open for people interested in solving these problems that very explicitly concern the intersection of society, technology, and geekdom, it should become a little bit easier to thinking about the hard parts, and to discuss them among people of otherwise diverse backgrounds and subtly diverse intuitions.
The end product, after all, will necessarily involve breaking and reshaping some of these assumptions.)
ariadne@treehouse.systems