I know, but they used to be more exciting I feel like - but I guess it's only natural that development speed goes down as more and more low-hanging fruit has already been picked. What remains of the non-boring stuff is probably quite complicated and difficult to stabilize.
With Linux, I can change just about everything. If I want a real-time kernel, I can switch. If I want a different desktop environment, change. If I want more control from my keyboard, Linux has my back.
As much as I agree with the sentiment of the article, this is a terrible reason and more likely to scare people away from Linux rather than get them to install it.
If you know what a "real-time kernel" is, you're probably already using Linux and you are a highly technically literate user. Any "normal person" user is going to look at that and think "Oh, I guess I need to understand technobabble in order to use Linux". Normal users care about easy, preset defaults, not customization.
Once again, Linux adoption is kneecapped by its own users, who forget what normal people really care about.
If I eventually decide I want to split my one file script into two files will I be able to?
I honestly would say that's when it goes from a script to a proper project, and you should treat it like that with a Cargo.toml and everything. I think this is a case where it would push you towards better practices and I don't think it should support multiple files like that.
As much as "instance drama" can be a bit tiring, I think it might be an inevitable outcome and shouldn't necessarily be seen as completely bad. My thinking is that instance drama would not occur if all the instances were similar, and that would be bad. As it is, there are actually differences among the instances and that's good - some disagreements due to those differences is inevitable.
Now, it would be good if we could agree to disagree and still be friends... but that also moves into the paradox of tolerance. But I would say most instances have nothing strongly against each other, despite any differences in moderation or rules or approach. The Pareto principle applies too... probably 20% of the instances are responsible for 80% of the drama. If you don't like the drama, try avoiding those 20% of instances 😅.
I get what you're saying here and mostly agree, but just want to point out that you are transferring a resource - your labour. So it is a bit more nuanced than this.
I doubt they knowingly sponsored a project based on the developers’ political ideologies
But now they should know right? But the response makes it clear they don't really care. They want to include everyone in the "big tent", which clearly runs afoul of the paradox of tolerance. I am not a fan of their response.
I don't know but it could be anything else than an Arc. Obviously you should still be able to take a usual reference to such a thing.
References are just pointers, they don't have any counting. This proposal as I understand it is an attempt at making reference-counting more ergonomic.
It sounds like that would require unifying the architecture of all fediverse platforms, which nobody is interested in and very much goes against the point (decentralization). Right now all of these platforms are written independently, with unique architectures and different programming languages.
Suffice to say that, while it's a nice thought, what you're proposing is not really realistic, nor is it actually desired.
Matrix is not part of the fediverse, so that's kind of a special case and doesn't work the same at all as the rest.
What you describe sounds very simplified, but let me assure you that there is nothing simple about this problem (I say that as a software engineer that has studied ActivityPub, the protocol underlying the fediverse).
Wait, you're going to federate whether a user clicked on a link between instances?
That seems kinda too far. I would not want other instances to know what I have or have not clicked. That's a level of surveillance I'm not comfortable with and I fear how that data might be abused.
Tbh I wouldn't even want my own instance to track what I click
Let’s apply quality control on upvotes, so any post can get only 20 upvotes till it gets a specific amount of comments then the limit could be pumped up to 40 upvotes till it gets more comments, etc…
Ultimately this is just limiting ways that people can vote. Voting is the democratic way to sort posts. I don't think you can limit without ultimately influencing the system in unintended bad ways, since that will restrict how people can vote. Just let people vote.
I know, but they used to be more exciting I feel like - but I guess it's only natural that development speed goes down as more and more low-hanging fruit has already been picked. What remains of the non-boring stuff is probably quite complicated and difficult to stabilize.