Yeah, so in this hypothetical eventuality they rob themselves of income in relation to games already released, as well as goodwill in relation to games in production or planned for production in Unity. Seems to me like a recipe for backing down on one or the other.

I’m pretty sure devs can just withold payment after Jan 1, and for games already released if Unity wants the money they would be forced to sue the dev for not adhering to their illegal and unenforceable contract. They would have to prove the validity of their per-unit charges without having actually ever measured the units.

Sure it can, I’ve got no problems using frame generation on my 3060. Any RTX card can do it

“DLSS2” and “DLSS3” are not references to the version of the DLL. They are references to different output modes of the DLL, which is also backwards compatible, i.e. the 3.5 DLL can output either mode. The Starfiels mods that were available immediately at launch do not use DLSS3, or by extension frame generation. It doesn’t matter which DLL version you use

Are you sure the mod you’re using is injecting DLSS3? Using the DLSS 3.5 DLL is not related to that. If it’s only injecting DLSS2, it would be entirely expected to see negligible performance difference vs. FSR2.

Kinda sorta required if you want to stream assets from storage, an approach taken by many modern games. Might not be absolutely necessary depending on your setup / game settings. BG3 also said SSD required but there’s a “Slow HDD Mode” in the settings anyway, which I believe just shifts more of the streaming burden to RAM/VRAM. If you played on a HDD without enabling it, I guess you’d expect to see inconsistent pop-in as individual assets try to stream in faster than your storage can read. But playing with it enabled might also cause performance drop if your RAM/VRAM was already close to full utilization with the setting disabled

Upon looking to this further I’m not sure if it actually works as I understood it to, due to the way group services are handled currently in Mastodon. Clearly there is some sort of flag in Activitypub on group accounts to indicate to other apps that it is a group account, because e.g. https://lemmy.ml/c/climatejustice@chirp.social works and you can follow it but the same link substituting /c/ for /u/ does not work. And for normal user accounts, the inverse is true.

However, aside from that flag, my understanding is they are essentially just user accounts that boost any posts from followers that mention the account handle, which causes the boosted post to show in the feed for all followers of the account. Since that account isn’t actually posting the posts that it boosts, I guess it makes sense that activity wouldn’t be visible in Lemmy, where boosts don’t exist. Following this logic no posts would be displayed, and that’s what is observed. Initially I thought this was because no one on the instance had followed the group yet, because e.g. https://lemmy.world/c/BlackMastodon@chirp.social does show posts while https://lemmy.ml/c/BlackMastodon@chirp.social does not. The same group on a.gup.pe also shows more posts on https://lemmy.ml/c/BlackMastodon@a.gup.pe.

It’s hard for me to make sense of what’s going on here (especially as I don’t microblog or use Mastodon personally) because clearly the Mastodon content is federating through the lemmy instance, but I’ve only been able to observe a subset of it and I haven’t been able to figure out the parameters that have caused some posts to be visible in Lemmy but not others.

I think “communities” term is used on Mastodon in reference to what are “instances” on Lemmy. I’m talking about communities as they apply to Lemmy - in Mastodon I think they’re generally called a “group” account. You subscribe to them in Lemmy mostly the same as how you’d subscribe to a Lemmy community on a different instance. e.g. go to your.lemmy.instance/c/groupname@their.mastodon.instance and subscribe. Or just search for the Mastodon group on the Lemmy communities page, making sure the filters are set to “All”. To find a Mastodon user page is the same, just /u/ instead of /c/. You just can’t follow or subscribe to the user pages because that’s not currently a feature in Lemmy, but you can for groups/communities

Watch history is an absolutely essential metric for Youtube - I can understand how you’ve been led to believe that turning this option off is opting out from that data collection, but no. What this setting is asking is if you want the data collected to be represented to you as recommendations for other videos to watch. It absolutely doesn’t change what data is collected, just whether the videos you’ve watched should be accounted for when the algorithm is finding new videos to recommend.

My understanding is that isn’t correct - in Lemmy you currently can follow Mastodon communities, but not users (following users on any fediverse platform including Lemmy itself just isn’t a part of Lemmy yet). I believe it’s planned to be implemented, but this is one thing differentiating Lemmy and Kbin - you can currently follow Mastodon users in Kbin, and in that case I think it’s just the same way you’d follow another Kbin user. To find their user page it would just be kbin.social/u/user@their.mastodon.instance instead of kbin.social/u/user, so I assume it would be similar for Lemmy once implemented

I read the whole post, understand the reasons and respect them. Ultimately piracy is one of the topics I’m here to read about, so these changes still make lemmy.world a less usable instance for me and I don’t like that

I stopped using it because it was kinda shitty. Some page elements in my webapps just didn’t display or work correctly. Firefox is the more polished experience now. But it is kinda nice not having to morally justify your choice of browser, too.

Mostly lurked since 2009, but always had an account so I could vote. Started commenting and posting more over time, to the point it was too much, having pointless internet arguments as a substitute for doomscrolling. So when I got the first notification about the API changes in RiF, decided it was time to cut the cord. I’d already mostly come around to the conclusion that I’d been wasting my time there, but I had a notion that it was somehow OK because the place I’d chosen to waste it was somehow different and better in comparison to other social media. It wasn’t that I wanted to get on a boycott bandwagon. But the API decision, the thinly veiled intent of their ridiculous pricing, and their steadfastness in making no subsequent attempt to mitigate the changes whatsoever truly was the tipping point where I could no longer do the mental gymnastics required to con myself into wasting more time there.

They also screwed themselves over by playing the r/place trump card so soon after the last iteration in 2022. Rather than doing it to create a cool event to experience once every few years, they did it to drive engagement on Reddit. That’s made people lose interest and even if it’s another 5 years before the next one, many of them won’t come back. It’s a self-acknowledgement that the peak reddit era is finished and wouldn’t have happened without the prior backlash against their enshittification. It’s the type of thing that sets up the conditions for a death spiral, because they’ve resorted to tricks to get people to use the site and eventually they’ll run out of tricks.

I get it, so I installed the extension and browsed with it today. My feedback is that I feel like blocking individual words like Elon or Bezos would be required to make this meaningful at all. I still saw a bunch of stuff about them that the filter didn’t catch because they are so ubiquitous that you don’t need to say their full name to communicate who you’re talking about.

At the same time, while I almost always don’t care and don’t want to hear about a piece of Elon news, it doesn’t mean I’m not interested in Twitter developments, but I think the filter will block most if not all links/info about Twitter since it’s intrinsically linked to Elon’s persona.

At the end of the day I think it’s a cool idea, but I don’t think you can effectively block these guys via this method without blocking any mention of any platform they’re associated with, which isn’t really what I want.

I figured out that the swipe down doesn’t need to begin from the actual notification bar, like it does on my older Android phones. I can just naturally extend my thumb up to halfway up the screen and swipe down from there. Doesn’t work if I have scrollable content already on screen though

I can’t scrobble my music to last.fm on iOS without some janky workaround. The “almost same level of control” part of what you said relies on an assumption that only the set of use cases explicitly determined by Apple as ones that “matter” are worth supporting. That it’s more important to prevent the user from explicitly allowing a scrobbling app permission to read the music player app’s now playing notification than for the device to be able to perform this simple function.

This point of difference doesnt have any meaningful impact on collection of my data. It just stops the device from being able to do the function I want. So that what, I can sleep easier knowing that Apple designed a slick interface to point out data vectors which were already implied to be collected? It used to feel like a smartphone with training wheels, now they’ve just locked up the handlebars so that it’s easier to go straight.

I’m talking about the WHO’s recommendations in their capacity as an advisory body on public health following their analysis of IARC research, not the research itself. Many of the studies do make substantial corrections for the participant candidates. I don’t think that’s necessarily translated through to the recommendations, which should be given in the context of existing public health outcomes.

The WHO agrees that two thirds of adults in countries like USA and Aus are overweight. They agree that obesity is an extreme risk factor for cancer. They agree that non-nutritive sweeteners confer at least a short term benefit to weight loss. They agree that the cancer risk associated with those products is comparatively insignificant. So they should be careful not to potentially mislead media and the the public about that specific causal relationship. It has directly resulted in the misleading headline of this post.

But then couldn’t you just as easily say rather than ‘people use diet products because they’re overweight’, that ‘people are overweight because they use diet products’ ? I’ve certainly heard both propositions before. “Never seen a skinny person drinking Diet Coke”

I didn’t, but I just found a few papers showing a relationship between awareness/use of nutrition claims/labels and obesity.

https://bmcpublichealth.biomedcentral.com/articles/10.1186/s12889-019-7622-3

https://www.sciencedirect.com/science/article/abs/pii/S0306919214001328?via%3Dihub

That second one sums up my logic pretty well:

The analysis revealed that people with excess weight display a high level of interest in nutrition claims, namely, short and immediately recognised messages. Conversely, obese individuals assign less importance to marketing attributes (price, brand, and flavour) compared with normal weight consumers.

Generally people that engage with products marketed as “diet” options are more likely to be people that want to improve their diet. In turn those people are more likely to be overweight. And people that are not overweight are more likely to select based on other product attributes.

Edit: The use of low-calorie sweeteners is associated with self-reported prior intent to lose weight in a representative sample of US adults - https://www.nature.com/articles/nutd20169

In cross-sectional analyses, the expected relation between higher BMI and LCS [low calorie sweetener] use was observed, after adjusting for smoking and sociodemographic variables. The relation was significant for the entire population and separately for men and women (see Table 1). The relation between obesity (BMI ⩾30 kg m−2) and LCS consumption was significant for LCS beverages, tabletop LCS and LCS foods (see Figure 1a). Individuals consuming two or more types of LCSs were more likely to be obese than individuals consuming none (42.7% vs 28.4%) and were more likely to have class III obesity (7.3% vs 4.2%).