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.
Ah, I get you. That’s true.
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.
Ah, I get you. That’s true.
making the place less equal, more of a broadcast medium, and less accessible to unconnected individuals and small groups.
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.
How does an instance get into one of these archipelagos if they use allowlists?
By reaching out, I would say. 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 think both models (i.e. allowlist/blocklist) have their own perks and drawbacks and are all necessary for a healthy and enjoyable internet.
I would tend to agree. I think both methods have their merits. Though ideally I’d rather have most instances use a blocklist model. This is less cumbersome to the average user and this achieves (in my opinion) one of fediverse goal of having an online identity not tied to an instance, an online identity you can easily migrate (including comments, follow, DMs, …) if needed.
But the blocklist model is too hard to maintain at this time. There are various initiative to try and make it work, such as fediseer, and it might be good enough for most. But I think it’s a trap we should not fall into. On the fediverse, “good enough for most” is not good enough.
Now that people are fleeing to the Fediverse, we’re just gathering our tribe - and this is a natural phenomenon.
I think there is indeed something of that effect going on as well, this is true. But I do not think this warrants a move to allowlist by itself.
I think the move to allowlist is mandated by the fact that building a safe space for “minorities” is hard. The tools to alleviate issues such as harassment and bigotry are not sufficient at this time to keep those communities fully open.
Which is a shame as I think the best way to fight those issues, as a society, is to have people express themselves and have healthy conversation on issues that are rarely brought up.
But we are not entirely giving that up by moving to an archipelago model. It just means that individuals would have multiple accounts, on different archipelago. The downside is that it makes the fediverse less approachable to the average person.
I think the current technical limitations push us toward this archipelago model.
The thing is, bigotry and racism, to name only two, will exist on any social media, any platform where anyone is free to post something. And since those are societal issue, I don’t think it is up to the fediverse to solve. Not all by itself by any means.
What the fediverse can solve however, is to allow instances to protect themselves and their members from such phenomenon. And my limited understanding, as a simple user, is that’s it’s not possible right now. Not on lemmy nor on Mastodon, if I trust the recent communications around moderation and instance blocking. Not without resorting to allow list.
This is annoying to admit because it goes against the spirit of the fediverse. But the archipelago model is the only sane solution short term IMO. And it will stay that way until the moderation tools make a leap and allow some way to share the load between instances and even between users.
What a shit show. And if it is confirmed that laptop CPU are also affected, even if to a lower extent, AMD will be the only option on consumer hardware in the coming couple of years. Thankfully, Qualcomm entered the scene recently which should stir up the competition and prevent AMD from resting on its laurels.
On the topic of exposing sequence number in APIs, this has been a security issue in the past. Here is one I remember: https://www.reuters.com/article/us-cyber-travel-idUSKBN14G1I6/
From the article:
Two of the three big booking systems - Amadeus and Travelport - assign booking codes sequentially, making brute-force computer guesswork easier. Of the three, Amadeus, through its web portal CheckMyTrip, is especially vulnerable, Nohl said.
The PNRs (flight booking code) have many more security issues, but at least nowadays, their sequential aspect should no longer be exposed.
So that’s one more reason to be careful when exposing DB id in APIs, even if converted to a natural looking key or at least something easier to remember.
I would not have expected anyone to go to ASUS’ office to press the issue. So, good on GN and hopefully will see some long-term results. But seeing how the company has a hard time acknowledging some issues such as the ROG Ally SD card one, I would not hold my breadth.
I like the idea of aggregating communities. Especially if the modding tools are powerful enough. This could lead to communities being essentially curated lists of other communities. Which is great for new users to discover new communities without being overwhelmed by the unordered list of communities on the instance.
Another feature that I’d like to see is an equivalent to the mastodon’s lists, a way to aggregate communities for yourself. So that you could browse the content of communities sharing a same theme in a dedicated view.
I don’t think that’s the issue. As said in the article, the researchers found the flaw by reading the architecture documentation. So the flaw is in the design of the API the operating system uses to configure the CPU and related resources. This API is public (though not open source) as to allow operating system vendors to do their job. It usually comes with examples and pseudo code on how some operations work. Here is an example (PDF).
Knowing how this feature is actually implemented in hardware (if the hardware was open source) would not have helped much. I would argue you are one level too low to properly understand the consequences of the implementation.
By the vague description in the article it actually looks like a meltdown or specter like issue where some code gets executed with the inappropriate privileges. Such issues are inherent to complex designs and no amount of open-source will save you there. We need a cultural and maybe a paradigm shift on how we design CPU to fully address those issues.