modulus

joined 2 years ago
[–] modulus@lemmy.ml 5 points 4 months ago (1 children)

I'm not very convinced by this article. A lot of the "realities" are not, they're policy choices. Just as an example, the notion of the non-driving elderly adult having to be taken by their child to some office to get an ID is just a consequence of the US choosing not to have compulsory and free or nominal charge ID for all residents. Most of the other objections are equally dependent on specific policy choices, which may apply in some places and not others.

[–] modulus@lemmy.ml 1 points 5 months 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 10 months ago (2 children)

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

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

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

[–] modulus@lemmy.ml 3 points 1 year 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 1 year 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 1 year 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 1 year 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 1 year 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 2 years 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 2 years 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 2 years 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).

 

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 ›