modulus

joined 2 years ago
[–] modulus@lemmy.ml 1 points 1 week ago

Interesting article, and I definitely agree I prefer clear instructions when those are possible.

I only have an objection. When it's said that no matter how well chatbots behave, it's bad design, and that they're being used to substitute expensive people; well, expensive people's interface is chatting too. So in that regard I'm not sure there's a meaningful difference. Obviously there is if the chatbot is badly behaved, but the article says that it's a problem even setting that aside.

[–] modulus@lemmy.ml 7 points 5 months ago (2 children)

Get your DeepSeek3 and r1 weights before it's illegal!

[–] modulus@lemmy.ml 3 points 5 months ago

Advertising, cryptocoin shit, pay to play... This is an awful idea.

[–] modulus@lemmy.ml 3 points 9 months ago

Interesting article. I knew a bit about the split between the covenants of civil and political rights, and economic, social and cultural rights, but for example I didn't know the right to self-determination was introduced thanks to the Soviet Union.

A funny thing about the article is that it is not especially favourable to the Soviet Union--it reproduces the usual uncritical clichés--but even that makes liberals really annoyed.

[–] modulus@lemmy.ml 6 points 11 months ago (1 children)

I do not think it is a very good analogy. I do not see how this would turn into a broadcast medium. Though I do agree it can feel less accessible and there is a risk of building echo chambers.

Not so concerned on that--people being able to establish their tolerances for whom they want to talk to is fine with me. But if the system goes towards allowlists, it becomes more cliquish and finding a way in is more difficult. It would tend towards centralisation just because of the popularity of certain posters/instances and how scale-free networks behave when they're not handled another way.

It’s most likely a death sentence for one-persone instances. Which is not ideal. On the other hand, I’ve seen people managing their own instance give up on the idea when they realized how little control they have over what gets replicated on their instance and how much work is required to moderate replies and such. In short, the tooling is not quite there.

I run my instance and that's definitely not my experience. Which is of course not to say it can't be someone else's. But something, in my opinion not unimportant, is lost when it becomes harder to find a way in.

[–] modulus@lemmy.ml 9 points 11 months ago (3 children)

I'm concerned that people are already eager to bury the fediverse and unwilling to consider what would be lost. The solutions I keep hearing in this space all seem to hinge on making the place less equal, more of a broadcast medium, and less accessible to unconnected individuals and small groups.

How does an instance get into one of these archipelagos if they use allowlists?

Same thing with reply policies. I can see the reason why people want them, but a major advantage on the fedi is the sense that there is little difference between posters. I think a lot of this would just recreate structures of power and influence, just without doing so formally--after all the nature of scale-free networks is large inequality.

[–] modulus@lemmy.ml 6 points 11 months ago

It's possible FF wouldn't get away with something like integrating ad blocking by default, but in no reasonable universe were they required to do the PPA stuff and turn it on by default. Nor is it clear that it will lead to websites caring about FF compatibility--unfortunately many already don't.

[–] modulus@lemmy.ml 15 points 11 months ago (2 children)

The usual pro-advertising take. "It's ok that we're going to experiment without your consent on how to manipulate you, because we only use aggregated data so it's not personal, it's business."

[–] modulus@lemmy.ml 1 points 1 year ago (1 children)

Definitely, AP is not magic. But if even within one protocol round-tripping and full-fidelity is impossible or very difficult, that makes it only harder and less likely through a bridge.

[–] modulus@lemmy.ml 1 points 1 year ago

IMO bridging or translation isn't federation per se. Also it seems unlikely that protocols would converge to that extent. In fact AP implementations are already different enough that even within the same protocol it's hard to represent all the different activities instances can present.

[–] modulus@lemmy.ml 13 points 1 year ago (5 children)

I wouldn't really count Mastodon/Bluesky bridging as federation. They're incompatible protocols that were never intended to work together (arguably Bluesky was explicitly designed to avoid using AP).

[–] modulus@lemmy.ml 22 points 1 year ago (4 children)

For me the weirdest part of the interview is where he says he doesn't want to follow anyone, that he wants the algorithm to just pick up on his interests. It's so diametrically opposed to how I want to intentionally use social networks and how the fedi tends to work that it's sometimes hard to remember there are people who take that view.

 

I have a struct that looks like this:

pub struct Game {
    /// A HashSet with the players waiting to play as account strings.
    lobby: HashSet<String>,
    /// capacity determines  how many people a match contains.
    capacity: u8,
    /// A vector of ongoing matches.
    matches: Vec<Match>,
    /// HashSet indicating for each player which match they are in.
    players: HashMap<String, usize>,
}

I realised that this won't work because if there are 3 matches (0, 1, 2) and I remove 1 because it ends, the players that used to point at 2 will be pointing outside the vector or to an incorrect match.

So I thought the obvious solution was to use a reference to the match: players: HashMap<String, &Match>. But this makes lifetimes very complicated.

What's a good way to deal with a case like these where data are interrelated in the same struct?

 

Hi there,

I'm trying to do some native windows rust programming. I'm using native-windows-gui and native-windows-derive to do it, but if I try to mix that with tokio, I get the following:

No entry point found error for GetWindowSubclass. On console, I get:

error: process didn't exit successfully: `C:\source\myprojectanem\target\debug\myprojectname.exe` (exit code: 0xc0000139, STATUS_ENTRYPOINT_NOT_FOUND)

If I change

#[tokio::main]
async fn main() {

to:

fn main() {

The problem goes away, but obviously I can't use tokio then.

Any clue what the problem is and how to fix it?

 

Hi there,

I'm working on a bot to do social games on the fedi, and using the mastodon-async crate for communicating with the ActivityPub server in question. At the moment I'm using tokio mt as a runtime, though I'm new at async so if you think I shouldn't let me know.

The pattern I want to implement is the following:

  • At any given time, a user sends a "play" message to the bot.
  • If the player list is empty, the player is added to it awaiting someone else.
  • Otherwise, the bot checks if there are enough players on its list (who have previously sent a play message). For some games, enough is 1, since it's a 2-player game, for some it's 3 or more.
  • If there are enough players, play commences. list is cloned for that match, then emptied so other players can get in.

What I'm not very clear is how to keep this list to assure that sequence will be respected. I.a., if two play messages come reasonably quick together, I want one to be processed, then entered on the list, or get the match to start; then the other to get processed.

My current thoughts:

  • I could use a channel that receives the player accounts. When a new player is added, it performs the logic.
  • I could use a mutex with a list (or an option player value for the degenerate case of 2-player games).

Any thoughts on what the reasonable thing to do is here? I'm very new to async and while I realise there's probably lots of ways to do this, they're not all equally ergonomic and I want to avoid myself future pain.

view more: next ›