Cue the nuclear shills that will handwave away any legitimate concern with wishful thinking and frame the discussion as solely pro/anti fossil, conveniently pretending that renewables don’t exist.

ETA:

Let’s look at some great examples of handwaving and other nonsense to further the nuclear agenda.

Here @danielbln@lemmy.world brings up a legitimate concern about companies not adhering to regulation and regulators being corrupt/bought *cough… Three Mile Island cough*, and how to deal with that:

So uh, turns out the energy companies are not exactly the most moral and rule abiding entities, and they love to pay off politicians and cut corners. How does one prevent that, as in the case of fission it has rather dire consequences?

So of course the answer to that by @Carighan@lemmy.world is a slippery slope argument and equating a hypothetical disaster with thousands if not millions of victims and areas being uninhabitable for years to come, with the death of a family member due to faulty wiring in your home:

Since you can apply that logic to everything, how can you ever build anything? Because all consequences are dire on a myopic scale, that is, if your partner dies because a single electrician cheaped out with the wiring in your building and got someone to sign off, “It’s not as bad as a nuclear disaster” isn’t exactly going to console them much.

At some point, you need to accept that making something illegal and trying to prosecute people has to be enough. For most situations. It’s not perfect. Sure. But nothing ever is. And no solution to energy is ever going to be perfect, either.

Then there’s the matter of misleading statistics and graphs.
Never mind the fact that the amount of victims of nuclear disasters is underreported, under-attributed and research is hampered if not outright blocked to further a nuclear agenda, also never mind that the risks are consistently underreported, lets leave those contentious points behind and look at what’s at hand.

Here @JohnDClay@sh.itjust.works shows a graph from Our World in Data that is often thrown around and claims to show “Death rates by unit of electricity production”:

Seems shocking enough and I’m sure in rough lines, the proportions respective to one another make sense to some degree or another.
The problem however is that the source data is thrown together in such a way that it completely undermines the message the graph is trying to portray.

According to Our World in Data this is the source of the data used in the graph:

Death rates from energy production is measured as the number of deaths by energy source per terawatt-hour (TWh) of electricity production.

Data on death rates from fossil fuels is sourced from Markandya, A., & Wilkinson, P. (2007).

Data on death rates from solar and wind is sourced from Sovacool et al. (2016) based on a database of accidents from these sources.

We estimate deaths rates for nuclear energy based on the latest death toll figures from Chernobyl and Fukushima as described in our article here: https://ourworldindata.org/what-was-the-death-toll-from-chernobyl-and-fukushima

We estimate death rates from hydropower based on an updated list of historical hydropower accidents, dating back to 1965, sourced primarily from the underlying database included in Sovacool et al. (2016). For more information, see our article: https://ourworldindata.org/safest-sources-of-energy

Fossil fuel numbers are based on this paper which starts out by described a pro-nuclear stance, but more importantly, does a lot of educated guesstimating on the air-pollution related death numbers that is straight up copied into the graph.

Sovacool is used for solar and wind, but doesn’t have those estimates and is mainly limited to direct victims.

Nuclear based deaths is based on Our World in Data’s own nuclear propaganda piece that mainly focuses on direct deaths and severely underplays non-direct deaths.

And hydropower bases deaths is based on accidents.

So they mix and match all kinds of different forms of data to make this graph, which is a no-no. Either you stick to only accidents, only direct deaths or do all possible deaths that is possibly caused by an energy source, like they do for fossil fuels.

Not doing so makes the graph seem like some kind of joke.

You don’t know Some Software Corp and their world famous website somesoftwarecorp.com?

The proposal is bad enough as it is, but it’s the duplicitous gaslighting BS that really pisses people off.

If they came out and said “We came up with this thing to prevent loss of revenue on ads and prevent LLMs from capturing data” then people would still be against it, but at least it would feel like an honest discussion.

Instead it’s just another page out of Google’s playbook we’ve seen many times already.

1. Make up some thinly veiled use cases that supposedly highlight how this would benefit users, while significantly stretching the definition of “users”
2. Gaslight every one by pretending that people simply misunderstand what you’re proposing and what you’re trying to achieve
3. Pretend that nobody provides reasonable feedback because everyone is telling you not to commit murder in the first place instead of giving you tips on how to hide the body
4. Latch onto the few, inevitable, cases of people going too far to paint everyone opposing it in a negative light
5. Use that premise to explain why you had to unilaterally shut down any and all avenues for people to provide comment
6. Make the announcement that you hear people and that you’re working on it and that all will be well
7. Just do what you want anyways with minimal concessions if any and rinse repeat

For what it’s worth I blame W3C as well.
Their relatively young “Anti-Fraud Community Group” has essentially green lit this thing during meetings as can be seen here:

https://github.com/antifraudcg/meetings/blob/main/2023/05-26.md

https://github.com/antifraudcg/meetings/blob/main/2023/07-07-wei-side-meeting.md

WEI can potentially be used to impose restrictions on unlawful activities on the internet, such as downloading YouTube videos and other content, ad blocking, web scraping, etc.

Did the author of the article come from some dystopian parallel universe?

Well that explains why they did a 180 on their “no AI” rule, which has the mods in a tizzy.

Who knows, maybe it’ll cut back on the toxicity in the sense that you don’t have to interact with toxic people ¯\_(ツ)_/¯

But for iOS you’re forced to use Xcode for implementing certain things like permissions, build and upload.

You can do all that via VSCode as well if you so desire.

Permissions, configurations, etc. are essentially all just XML files and can be edited as such, building, running in simulator and uploading can all be done via CLI.

And if you’re not comfortable doing it via the terminal in VSCode, you can also find some extensions.

Personally as a native dev I don’t know why you’d want to of course, but to each their own.

I think you might be misunderstanding what this does.

You did a search for symbol references that contain “User” ignoring cases.

When you do a search for symbol references this way, Xcode will return two things:

1. A declaration of all the symbols containing “User” and/or some context surrounding the symbol (ignoring Case)
2. Show any places where your code references the symbol

And it did just that.

The first three .swift files show references to symbols that contain “User”.
The forth one, User.swift, is in and of itself a symbol that matches the query and has symbols inside itself.
The last one UserViewModel.swift is in itself a symbol as well and all the parts that are nested within that you’ve annotated with underscores and question marks, serve to give you context about the symbol “UserViewModel”, hence the ellipses.

It’s essentially telling you “Hey I’ve found this symbol UserViewModel, it starts with a var named username, has a bunch of stuff following that (i.e. …) then has an extension, then some more stuff (i.e. …) and then ends”.

Without knowing what’s inside UserViewModel.swift I can’t tell if it goofed with giving you a typical declaration, but that doesn’t change the fact that its trying to give you context about a valid search result, the symbol UserViewModel, so that you can figure out if that’s the one you’re looking for.

Keep in mind that variables are considered symbols as well, but in this instance I don’t think that’s what happened here, otherwise it would’ve been marked with a P instead of a C.

If this is not desired behavior then I suggest you switch from “Containing” to “Matching Word” or instead consider using the search bar at the bottom of the Symbol Navigator. Another option, if you’re searching while going through code, is to right click on the symbol in your code and click Find > Find Selected Symbol in Workspace.

Lastly it might be an idea to go over the Xcode documentation as a refresher. This would be a good starting point.

That said, Apple clearly feels that things can be improved by clarifying, because in the current Xcode beta they’ve changed the option label from References to Symbols (and added a few more options).

Most likely different incentives and platform culture.

Customization isn’t that big on iOS, other than the occasional viral fad, so there’s less interest for custom keyboards and in return less development spent on it.

Monetization of custom keyboards is also really hard and due to limitations on tracking and collecting data the incentives that Android has don’t really exists on iOS.

So what you end up with is a handful of custom keyboards often by big players that have bags of money to throw at it or as a companion to a regular app (e.g. Grammarly, GIF apps) to fulfill a specific function.

They’re right about browsers, but jumped the shark on keyboards.

Custom keyboards come with some rules and limitations for obvious reasons, but they’re by no means the system keyboard in disguise like how browsers are all WebKit under the hood.

Here’s documentation on custom keyboards: https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/CustomKeyboard.html#//apple_ref/doc/uid/TP40014214-CH16

Good instinct, here’s a BBC source.

Edit: Apparently this is old news? Or the news is that lawsuits have commenced?

I would expect they’d collate that information and pass it on at regular intervals to the instance that holds the true version of the post, who then subsequently disseminates that information to subscriber instances.

Then again, I guess you could collate the detailed information in a similar manner.

Not disputing what you’re saying, I assume you’ve tested this out and that’s what you’re reporting, just commenting on the choices made by the project to implement it this way.

Is that what you found out during your experiments?

That seems like a really inefficient and useless implementation to have all instances provide those details to one another, when every instance can simply keep track of it for their own users and pass along the total number.

Pro tip: if you do insist on using Google scroll to the bottom until you see a notice like the one below.

You can then click on the complaint to see the URLs that were removed.

They’ve wisened up a bit and now require a (throwaway) email to access the links, but chances are that if you’re looking for something more obscure, the link you seek is still there.

Typical Lemmy experience, haha.

Honestly has its charms, gives me the feeling of nostalgia, like we’re back in the early 2000’s.

Another such rough edge is that comments sometimes get posted twice, like your comment

I think it makes sense for a “redditlike” to be searchable, while also understanding that Mastodon is a different beast and can benefit from lack of search.

Don’t know if Mastodon posts on Lemmy instances have a specific characteristic, but perhaps you can consider filtering them out while keeping “regular” Lemmy posts and comments?