Perineum Sunning^wikipedia^ (SFW, surprisingly.)

Hell yes! Huge step in the right direction. Kernel exploit's still a ways off, but this is exciting.

I've never heard of Visora before, so let me make sure I've got this right.

Visora is kinda "Mechanical Turk" broker for paying people (a pittance) to build data sets for training slop machines, right?

Are they saying that someone somewhere is paying people through the Visora platform to get them to create/provide footage of house cleaning being done from the perspective of the person doing the cleaning? (I'm guessing in order ostensibly to... I dunno... train robots to clean houses or something?)

Or am I missing the point Visora is trying to make entirely?

Opening sentence:

Smart glasses are making everyday life easier or making humans more dependant is a matter of debate, but have now wondered how it can catch people in vulnerable situations, secretly record them or even show them in poor light, give the privacy concerns around them?

Am I having a stroke? Is this auto-translated through 7 different languages using a translation engine from the nineties or something?

I stopped reading after that, so I don't know if the rest of the article is similarly fucked.

No signs of a payoff inside the tech sector either.

4

Ok. That gives me more clarity. Thank you!

I don't think OP is asking for what you're saying they're asking for.

There are vegans who gatekeep and exclude people who eat plants/fruits/vegetables fertalized with animal manure. Richard Stallman approved of using proprietary operating systems to build Free Software in some cases. There's probably no end to how deep you can go down such purity rabbitholes. And the same is true of AI.

In the vegan example, most people don't think of not eating manure-fertilized plant products as a requirement for being a vegan. Similarly, I don't think anyone expects "no AI was used in the making of this product" to mean they built it on an operating system free of generative AI. (Particularly because, as you rightly say, it's nigh infeasible to escape generative AI entirely, at least right now.)

That said, a website like Itch.io that explicitly forbids projects that include AI-generated code, story, assets, etc, (not as in was built completely without the influence of generative AI, but just the game/project/whatever itself includes no AI-generated stuff), will consider strong-enough evidence of a violation of that policy a bannable offense, and offers a way to report offenders would almost definitely meet virtually everyone's (including OP's I'd wager) definition of "AI-free". And that would accomplish probably 99% as much benefit (over sites that indiscriminately allow slop) as the purest possible approach without the drawback of a 99% smaller catalog. I don't think a rule that earlier versions of a game must not have contained AI-generated content is necessary either, really.

Yes some slop would slip through. Some people are bad actors. And I'd think generative-AI boosters are more liable to try to scam people for profit than the average person. But also, most scams are fairly low effort. And I expect that if a site like what I'm describing existed, the majority of dishonest submissions would be pretty transparent. Even those that actually managed to get listed would get removed fairly quickly.

Every broker has rules. (Including Lemmy.) And every sufficiently complex ecosystem has parasites. And so every broker has rule-breakers. Ebay and Amazon and Steam and Itch.io etc etc etc exist despite the difficulty in enforcing whatever particular rules they might have. Yes rule violations slip through and affect customers on all of the above platforms and every other platform. Doesn't mean there's no point in having rules at all.

Oh look. Another perfectly normal headline.

What a way to celebrate yor cake day.

That word "we" is doing a lot of heavy lifting.

Are you saying Itch.io already has a "no-AI" policy? If so, can you share a link to they say that?

So the voices of other memory would be less crowded than expected. (IYKYK.)

/c/imgoingtoheavenforthis

Was generative AI involved in the creation of any of these images? (A bit of searching indicates MS Paint has I image generation capabilities built in. Something called "Image Creator" that uses DALL-E to generate images based on a text prompt. Was that or any other generative AI used in generating these posts?)

Hey, it works. I can smell the bullshit over the internet already.

Basically the other options are "AI good", "AI bad", and "I dunno". I took the remaining option to cover either "AI both good and bad" or "AI neutral".

How are all the images posted by this bot made?

Also, aren't bots required to say in their bios who to contact if they misbehave? (I'm guessing it's @[email protected], but still, just to be explicit about it.)

Edit: Yes they are. #3 here.

Hoo boy. Got a report on this one. "Misinformation".

Sounds like the basic claim of the video is:

• Nafisa Fai gave a speech in front of an inverted American flag.
• Right-wingers flipped a shit.
• Nafisa Fai put out a deepfake image showing a not-inverted flag.
• Journalists (Oregon Journalism Project and Axios) published a piece "debunking" the claim that Nafisa Fai gave a speech in front of an inverted flag, citing the deepfake as proof.
• Said journalists subsequently retracted their story.
• Nafisa Fai removed the deepfake from pages she owned.

The above all seems to be true as far as my research has found. While the video creator's political bent and underlying agenda very much doesn't match mine, neither do I want inconvenient facts about liberal candidates buried.

Beyond that, the video states:

• That they believe the journalists knew the image was a deepfake before publishing their supposed "debunking" article.
• That Nafisa Fai's platform includes (unjustly) funneling "infinite" (being hyperbolic, of course) taxpayer money to Somalis on wellfare.

The first of these two bullets is unsubstantiated, and so I'd say the term "misinformation" fits. The second is hardly a statement to be taken seriously. It's more aimed at stoking anger than any objective statement of facts. But more concerningly, the second point and the way the video makes the point is straight up, unfiltered anti-Somali bigotry. I don't think we want this community being a platform for such bigotry.

The first bulleted list above being basically correct makes me not want to delete this post. The amount of misinformation probably isn't enough to warrant action. But the bigotry, I've decided, warrants removal of this post. I don't think it warrants banning the OP, however.

I realize that probably this comment won't be visible anywhere once I remove the post, but I still wanted to spell out my whole reasoning.

Well, I don't like it. Lol.

Adding something like monads to Go as some first-order kind of thing really feels to me like it would be a big bag on the side. (I mean, I feel like all the functional stuff in Java like lambdas and streams and stuff is a bag on the side in the same way. Java fanboys back in the day touted Java's proceduralness as a strength. Now I have to wonder whether those fanboys have left Java for other languages and the Java fanboys we have now are a new crop of lambda-positive Java fanboys or whether the old Java fanboys changed their tunes and decided functional programming was a good thing for Java after all.) It'd make Go kindof not Go any more, making it "just another language that adds features willy-nilly".

Plus, changing the standard library to use monads instead of multiple return values for errors would be a huge backwards-incompatible thing. Not to say backwards-incompatible changes shouldn't be made. (I have great respect for Python's 3.0 rework, for instance. And I think Java is extremely overdue for something similar.) But I don't see adding monads as a benefit at all, let alone worth the effort of migrating.

I'm sure part of the reason why most of the previous proposals haven't been accepted is because it would create tons of interactions with existing Go functionality and/or confusing edge cases, each of which would have to be considered.

I just googled (DuckDuckGo'd, actually) and ran across this proposal. I'm not sure I hate... something roughly like it (yet). But it's not as if it doesn't have any costs.

My thoughts on it:

• I will say I strongly oppose creating variables with magically-decided names (for which I'm pretty sure there's no precedent in Go), so I'd want the "Declaring the err variable" version mentioned in the proposal that would require the variable name to be explicit: count := strconv.Atoi(input) ? err { return err } (rather than count := strconv.Atoi(input) ? { return err }.) (I'd probably be ok with omitting that variable name after the ? rather than requiring an underscore if that value wasn't used in the body of the block... if I convince myself I'm ok with even the basic premise, that is.)
• I also don't think there's any precedent for any syntactical elements requiring a variable to be "of interface type that implements the built-in error type", so I'd rather the ? construct assign the positionally-last return value to the more locally-scoped variable (whose name is after the ?) than requiring that variable to be of any particular type.
• One open question would be "would count be visible within that block"? Usually a variable is not defined until after the statement that declares it, but this new block would be... part of the statement that declares it, which makes it kindof weird for that variable to be visible inside the block. I concede it would be useful to be visible inside the block, but it still makes scoping confusing, which isn't an insignificant cost. Of course, if count, err := strconv.Atoi(input); err != nil {...} also declares a variable that's visible within the block is part of the statement, but that feels different to me because in that case the variable is only visible inside the block and not outside as well.
• If hypothetically I did convince myself I was ok with a proposal like this, I might want use of the ? expanded to other situations. Like func bob() (int, error) { ... } ; func(i int) { ... }(bob()?) to silently suppress the error that bob returns. But one major cost of that would be that there's no rule that "if you return an error, the other return values must be the zero value of the associated type". It's a common convention, but not so common as to be inviolable. If, say, a library did return something specific rather than the zero value when returning an error, it would probably have to devote a lot of extra documentation to that situation because that's a pretty confusing corner case. (Like, maybe a function returns a coefficient to be multiplied by something, but does a return 1, fmt.Errorf("...") if something fails because you're more likely to want a 1 in an error condition where you're multiplying that value by something than a 0. (Or maybe that case would be better with a 0.))
• I don't think I'd ever use such a construct with a block on one line. I'd probably make it look more like the following, which honestly makes it harder to see the benefit relative to the existing if err := bob(); err != nil { ... } convention:

count := strconv.Atoi(input) ? err {
  return err
}

Honestly, the more I think about it just while writing out my thoughts above, the more I think it isn't worth it. There is one poposal for error handling that I can say I "like" without reservations, though. (And it seems the core Go team is, roughly, planning to take that route.)

If I had to pick a biggest frustration with how Go is, it would probably be nil. I kindof wish it didn't have that or anything like it. Not to say I've thought it through. There may be really good reasons why nil has to exist. But maybe it would be fine for the zero value of a function to be a function that does nothing but panic. And the zero value of a map to be an empty map. And the zero value of a pointer to be a pointer to a zero value of the pointed-to type. Etc. I don't think it's worth changing that at this point, though. I'd rather just use Go as it is than have Go embark on such a drastic change.