modulus

joined 1 year ago
[–] [email protected] 6 points 1 month 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.

[–] [email protected] 9 points 1 month 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.

[–] [email protected] 6 points 1 month 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.

[–] [email protected] 15 points 1 month 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."

[–] [email protected] 4 points 1 month ago (1 children)

So it would still help optimising persuasion at scale (also known as lying to people to best et them to act against their interest). Why is this a good thing again?

[–] [email protected] 9 points 1 month ago (3 children)

what do I think the history is? A record of the sites I visited.

What do I think the history isn't? A correlated record of which advertisements I've been exposed to, and which conversions I've made, that gets sent to people who are not me.

Pretty relevant distinction. One thing is me tracking myself, another thing is this tracking being sent to others, no matter how purportedly trustworthy.

[–] [email protected] 22 points 1 month ago* (last edited 1 month ago) (7 children)

I'd like people to STOP PRETENDING that the only plausible reason why someone doesn't agree with this is that we don't understand it. Yes, I understand what this does. The browser tracks which advertisements have been visited, the advertiser indicates to the browser when a conversion action happens, and the browser sends this information to a third-party aggregator which uses differential techniques to make it infeasible to deanonymise specific users. Do I get a pass?

Yes, this is actively collaborating with advertising. It is, in the words of Mozilla, useful to advertisers. It involves going down a level from being tracked by remote sites to being tracked by my own browser, running on my own machine. Setting aside the issues of institutional design and the possibility for data leaks, it's still helping people whose business is to convince me to do things against my interest, to do so more effectively.

[–] [email protected] 13 points 1 month ago (9 children)

I don't blame Mozilla for not single-handedly ending advertising online. That's too much to expect from anyone. But they could at least avoid active collaboration with the enterprise. And if they're going to engage in it, they should at the very least warn their users.

[–] [email protected] 7 points 1 month ago (3 children)

I don't have a complete solution, but I have a vector, and this is in the opposite direction, being, according to its own claims useful to advertisers.

The solution passes through many things, but probably has to start by changing the perception of advertising as a necessary nuisance and into a needless, avoidable, and unacceptable evil. Collaboration does not help in this regard. Individual actions such as blocking advertising, refusing to accept any tracking from sites, deploying masking tools, using archives and mirrors to get content, consciously boycott any product that manages to escape the filtering, are good but insufficient.

[–] [email protected] 47 points 1 month ago* (last edited 1 month ago) (33 children)

Whatever opinion you may have of advertising as an economic model, it’s a powerful industry that’s not going to pack up and go away.

Fuck that. Not if we don't make it. That's precisely the point. Do not comply. Do not submit. Never. Advertising is contrary to the interests of humanity. You're never going to convince me becoming a collaborator for a hypothetically less pernicious form is the right course of action. Never. No quarter.

We’ve been collaborating with Meta on this,

That makes it even worse.

any successful mechanism will need to be actually useful to advertisers,

And therefore inimical to humanity in general and users in particular.

Digital advertising is not going away,

Not with that attitude.

but the surveillance parts could actually go away

Aggregate surveillance is still surveillance. It is still intrusive, it still leverages aggregate human behaviour in order to harm humans by convincing them to do things against their own interest and in the interest of the advertiser.

This is supposedly an experiment. You've decided to run an experiment on users without consent. And you still think this is the right thing--since you claim the default is the correct behaviour.

I cannot trust this.

[–] [email protected] 11 points 1 month ago

It's hard when I don't get told about it and find by chance.

[–] [email protected] 7 points 1 month ago

Yes, for example I donate to thunderbird since I find it useful. And I wouldn't mind donating to Firefox either provided they wouldn't do this sort of fuckery.

though in the long run we need to overturn capitalism of course, and that an economic model is viable doesn't mean we should sustain it or justify it.

8
submitted 5 months ago* (last edited 5 months ago) by [email protected] to c/[email protected]
 

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 ›