• 0 Posts
  • 86 Comments
Joined 2 years ago
cake
Cake day: June 25th, 2023

help-circle





  • It’s not being made “as painful as possible”, it’s just manual. Arch isn’t a distro that’ll preconfigure things for you so everything’s plug’n’play, it’s a distro that’ll give you access to everything and the power to use it however you like, but with that comes the expectation and responsibility to manage those things.

    Installing arch manually is simply a good lesson in how your system is set up, what parts it’s made up of, in part because you’re free to remove and switch out those parts.

    And sure, there’s no magic bullet to make sure a new user understands everything they did, but I think in the end, if you’re not willing to read, learn and troubleshoot, you might just want a different distro.




  • Not when taken to such an extreme so as to obfuscate the meaning and behavior of code, and make it difficult to understand how you would arrive at that code.

    Sane defaults serve to reduce verbosity without obfuscating meaning, simpler syntax with different ordering and fewer tokens reduce verbosity to make the code easier to read by reducing the amount of text you have to pay attention to to understand what the result is.

    I imagine there’s also a distinction to be made between verbosity and redundancy - sometimes extra text might fail to carry information, or carry information that’s already carried elsewhere. I’m not sure where the line should be drawn, because sometimes duplicate information can be helpful, and spacing out information with technically meaningless text has value for readability, but I feel like it’s there.






  • Overproduce to cover everybody’s needs, and if you want to use that overproduction to cover somebody else’s problems, make that the new target and produce over it to keep a safety margin. Otherwise you’re just going to hide the problem and run into trouble when production dips.

    Not saying this is the right approach, but this is the idea I’m getting from the thread. I feel like it might not work with the economics of supply and demand combined with capitalistic greed, but if a margin exists as safety, allocating it removes that safety.




  • KubeRoot@discuss.tchncs.detoTechnology@lemmy.world*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    11
    arrow-down
    1
    ·
    2 months ago

    Yes, apple should allow that, and Sony should allow that. Your “gotcha” seems pretty stupid, because “allow” doesn’t mean “facilitate” - it’s not Apple’s responsibility to make those things work on their devices, but Apple is going out of their way to prevent individuals from making those things happen on their own.


  • If you license your project under GPL, and somebody submits some code (like through a pull request) that ends up in the library you use, you are now also bound by the GPL license, meaning you also have to publish the source of any derivatives.

    The way to avoid it is to use something like a CLA, requiring every contributor to sign an agreement giving you special rights to their code, so you can ignore the GPL license in relation to the code they wrote. This works, but is obviously exploitative, taking rights to contributions while giving out less.

    It also means if somebody forks the project, you can’t pull in their changes (if you can’t meet GPL terms, of course), unlike with MIT, where by default everybody can make their own versions, public or private, for any purpose.

    Though it’s worth noting, if you license your code under MIT, a fork can still add the GPL license on top, which means if you wanted to pull in their changes you’d be bound to both licenses and thus GPL terms. I believe this is also by design in the GPL license, to give open-source an edge, though that can be a bit of a dick move when done to a good project, since it lets the GPL fork pull in changes from MIT versions without giving back to them.