Skip Navigation

Posts
65
Comments
607
Joined
3 yr. ago

  • 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.

  • TL;DR:

    • Use std Mutex if your critical sections are short and you're not too worried about fairness.
    • Use parking_lot Mutex if you experience thread starvation and don't care about panic poisoning.
  • Duration::from_mins and Duration::from_hours seems nice. Otherwise kind of a boring release if you ask me.

  • Deleted

    Permanently Deleted

    Jump
  • 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.

  • Deleted

    Permanently Deleted

    Jump
  • 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 don't really get it

  • if you transfer resources to them

    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.

  • How do I now actually get a &Arc? Without implicitly cloning?

    & is such a fundamental part of the syntax, I really don't think it's meaning should be muddled.

  • 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).

  • It feels like they could all be part of one unified platform.

    They are. It's called the fediverse.

    There's no reason why any of these software options couldn't support all the same stuff, as you say. But so far they have chosen not to.

    Maybe another option will come along one day that supports more of it at once.

  • This is like requiring people to read a specific text book before they vote in real life elections. I hope you can see the problem with that.

  • 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

  • How would you know for remote users?

  • 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.

  • The title makes it sound like writing Rust for git will be mandatory

  • Did you read the post? The author suggests trying out other version control systems too.