Notices by codesections (codesections@fosstodon.org), page 11

@sir

> This is also why I question niche programming languages like Rust when they claim to be suited to systems programming or even kernel development. That’s simply not true when they only run on a small handful of operating systems and CPU architectures.

My understanding is that Rust runs on ~90 platforms. https://forge.rust-lang.org/platform-support.html How many platforms would you like to see it support before you'd say it supports more than a small handful?

(I agree that portability is important)

@Wolf480pl @wowaname @jacek

> I read a bit about redis pub sub, and it turned out it's no good... but I forgot why :/

Interesting. If you remember why, I'd be interested in the details (relevant to my interests, as they say)

@Wolf480pl @wowaname @jacek

Yeah, this is also something I'd be interested in helping with, depending on how it goes.

I've been working with pub/sub in Redis lately, which has a pretty good model for this sort of thing (not saying you would/wouldn't want to use Redis, just saying the model is similar)

I'm currently working on some #rust code that is passing state around in a way that reminds me of props-drilling in #react.

That strikes me as a pretty serious code smell, but I'm not sure right off how to avoid it. More thought is required.

@Wolf480pl @wowaname

> Then there's also the storage problem.

Wait, I'm confused about how (B) history presents less of a problem than (A) history. So long as at least one person stays in the channel, doesn't the same amount of history have to be kept (somewhere) as for (A) history?

@wowaname @Wolf480pl

> discord has a permission so that certain roles are not allowed to see channel history. expand on that and you have your solution to point A

Yeah, I hate to admit it, but Discord really has thought through a lot of these issues and presents pretty good UX (unlike Slack, which has … giffy support, I guess?)

@Wolf480pl

Formalizing that sort of history would require sifting through the conversations and abstracting a series of decisions into general principles. (Or effectively just copying the chat history).

Maybe that work is worth doing, but it's definitely *work*—and it's something that would have to be maintained over time.

It's like docs for code. Yes, external documentation is great, but it can get stale and is a lot of work. There's a lot to be said for self-documenting code

@Wolf480pl

> Why was this not documented in a more persistent place, like a wiki, an issue tracker, a forum, or a mailing list?

Some of it was. (the CLI working group keeps notes from it's meetings).

Let me switch examples: when I became a Fosstodon mod, I also joined a chat with (A) history, including discussions about how to handle moderation issues.

Could the results of each discussion have been documented? Well, maybe, but not easily
(1/2)

@dgold @Wolf480pl

Yeah, not arguing against IRC—it's my preferred chat method (well, it and Mastodon) and I last used it earlier today.

Just talking about what features are good/helpful in an app to help prevent Slack/etc. from gaining more ground (whether that's an IRC client of some kind or a new protocol as @Wolf480pl suggested up-thread)

@Wolf480pl

(And the same thing happened with Slack channels I (unfortunately) joined in my last job)

And there wasn't any negative privacy effect, either—that channel was intended for professional discussions within the working group, and everyone understood that the composition of the working group would change and that new members would have access to past conversations. Anything that would have been inappropriate to share with new members would *already* have been inappropriate to say.

@Wolf480pl

To expand on this a bit/make it more concrete: I recently joined the #rust CLI working group, which communicates via chat methods that have have " what happened in the channel before you become a member of it" history.

I was able to skim through what the group was talking about in the weeks before I joined, giving me a good sense of what the live issues/current projects were. Without that history, it would have taken much more time (from me and others) to get me up to speed

(1/2)

@Wolf480pl

> There are 3 kinds of history:
A) what happened in the channel before you become a member of it … Now, I believe (A) isn't all that necessary, and may even be harmful from privacy POV.

I said this last time you brought this up, and don't want to belabor the point, but…

(A) is *really* useful for a lot of project/business/organizational chats—it lets a newcomer join a channel and get up to speed quickly.

If you're hoping to replace centralized things (#slack), (A) is a must (imo)

@apetresc

> (BTW his Mastodon handle is already in the article you linked so I think the cat's out of the bag in that regard)

Yeah, my thought wasn't really about protecting privacy so much as not filling up their notification feed with comments about how much the situation sucks

@thegibson

I'm also curious why you say that. Delaware is the traditional choice, but I haven't (yet) looked into it in detail for myself (it's on the to-do list, though)

@alexbuzzbee

I feel like this is at risk of the flaw identified in https://m.xkcd.com/937/

(or maybe in https://m.xkcd.com/325/ I guess it's a bit of a theme)

@kelbot

> Any recommendations for a scanner that will primarily used for documents that is known to have no issues on linux?

I'd also be interested in this. So far, I've limited my scanning to the occasional critical document and just used my phone, but I'd be interested in a solution that makes it easier to scan larger numbers of documents.

@rmdes

> [Picture of a poster]

I feel vaguely like the typography choices in that poster are trolling me