Sven Slootweg (soft-deprecated) @joepie91@pixie.town

@cykonot @jonny Pretty much - inspiring confidence to *try* things, especially, and then building up a genuine confidence that derives from understanding (as opposed to 'false confidence').

It's more or less "teaching people to learn". There's remarkably little programming-specific learning involved, really 🙂

@jonny One detail I just realized I forgot: when they're going in the wrong direction, I don't usually tell them "that is wrong", but instead ask them a "self-reflection" question that prompts them to take a moment and think about it more. For example, "and if you did it that way, how would thing X change?"

It's less confrontational, and helps them to learn identifying the 'failure points' early, where they can catch themselves before making a mistake, by making self-reflection a habit early on.

@Lyude I feel like this doesn't quite address what I was trying to get at - you say "we", but who are "we" (ie. the people who functionally control the network) exactly, how are they organized, and what prevents a hostile takeover of some sort? Is it just a central organization? If yes, what legal form does it have? How do you ensure that those in power of it are universally deemed trustworthy?

The problem with things like "a widely used messenger" is that it becomes an incredibly appealing target to co-opt, and so you're going to have to deal with a lot more attacks than eg. your typical FOSS software foundation - companies trying to bribe contributors, legal attempts at takeovers on technicalities, sabotage, disinformation campaigns, and so on. The network effect is not just a barrier to adoption, it's also a large organizational risk.

Even if all of the people in power within the organization are absolutely spotlessly 'clean' and perfect (and that's already hard to achieve in this context), you're going to keep getting harassed by people trying to exploit the bounty of a large and widely used centralized network - whether it be corporations, governments, overt fascists, or whatever else.

A very big part of the motivation for federated networks (or fully P2P networks, but those introduce even more technical challenges) is precisely to address this problem; by structuring the system such that no one party holds outsized control, nobody is such an appealing target, and trying to take over *all* parties involved is very impractical and expensive.

So if we can't rely on that - because the premise here is to not rely on federation - then how do we address that risk in practice?

@Lyude I'm curious if you have any thoughts on how to reconcile "not in the hands of a company" with "should not rely on federation and should avoid the technical challenges it introduces"?

As historically, some form of centralization has been *how* these technical challenges have been avoided, but that then creates the risk of "in the hands of a company" again (even if you run it as eg. a foundation/non-profit, because that doesn't fully protect from this for various reasons either).

@foone Hilariously I bought a little TV box like this some 15-20 years ago, at Aldi, and other than not literally using VLC (I think...) it was basically exactly this.

It had an HDMI port, and an ethernet port, and some USB sockets. You'd plug in a storage device, and it would play arbitrary video files off it, in arbitrary formats, with a remote. Or you'd configure a Samba share, and it'd do the same thing off that. And that was *it*.

I think this was before Chromecast, Jellyfin, Plex, smart TVs, smartphones(?), etc. existed...

Should still have it somewhere. But it doesn't do HD.

@jonny What I tend to do when teaching programming and related things, is to have 'guided self-exploration'.

I make it very clear upfront that there is no penalty for getting things wrong, and that they *will* sometimes get things wrong and that's completely okay, and that's an intentional part of how I teach, and that I will be there to help them out whenever they get stuck.

Then I do usually 1-2 hour sessions at a time, deciding together on a small task (in a real project they want to do, not a sample/demo project!) that lets them practice some aspect of programming or project maintenance, and we go through it together.

Crucially I don't tell them *how* to do it; I give them a pointer on how to reason towards the answer, but don't provide the answer itself, and instead encourage them to 'reason out loud' and try things out (emphasizing that if something goes wrong, I will help them undo it, so they should feel free to try things even if unsure), and constantly ask them questions on "okay, and what would you do next?", incrementally narrowing down the scope of the question until the answer occurs to them.

The idea behind this is that you're always there as a 'support net' for them to fall back on, but they do as much of the "reasoning towards an answer" process as possible by themselves - and this helps them very quickly learn to identify the "meta-process" of working *towards* an answer based on incomplete information and missing background knowledge.

(For this to work, it's important that they work on a project/goal of their own invention - because that means that they already intrinsically know what the end goal is with all of its detail and nuance, and so you only need to teach and communicate the "how to get there" parts, not the "what are you supposed to be doing" parts.)

This approach often takes a bit for students to get into, as it *feels* hard initially and so being supportive is very important, but I've had universally positive feedback to it in the end. It usually only takes 2-3 sessions before they start getting the vast majority of "what to do next" answers right, even on topics they've never worked with before, and usually before they feel confident about their answers.

Interestingly, this has also worked very well with students who self-reported serious learning disabilities, and who had run into walls with everything else.

@porkroll (At least it's only allocating within a memory-mapped file and not system memory in general)

@porkroll It's not exactly voluntary :P Unfortunately it's more or less necessary to have a reasonably performant SHM implementation...

@frith01 Just to confirm, you have (direct or indirect) personal experience with not having reliable internet connectivity available?

@gsuberland@chaos.social @tsrberry @baldur Also, related to the 'user surveys' point - it's surprisingly helpful to just enter your project name into a search engine every once in a while, and read every blog post, Reddit thread, and rant you come across. Those tend to be *full* of things that never made it into 'properly filed' issues, and give a good impression of the general atmosphere around your project, because people tend to speak more freely and directly.

Of course that does mean that you should refrain from responding to them unless you are absolutely 100% certain that you can do so non-confrontationally, because seeking out confrontation with people talking in their own spaces is (deservedly) a very quick trip to the trash pile. Better to just take notes and work on fixing their complaints in the background.

(Bonus points: you can do this one as an 'unaffiliated' contributor with no formal power within the project. Whereas a proper user survey, although it can have better coverage, tends to require speaking formally for the project.)