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

help-circle




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




  • KubeRoot@discuss.tchncs.detoTechnology@lemmy.world*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    11
    arrow-down
    1
    ·
    1 month 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.




  • KubeRoot@discuss.tchncs.detomemes@lemmy.worldFTs
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    1 month ago

    NFTs try to introduce artificial scarcity

    Just want to add to that, NFTs aren’t inherently about artificial scarcity, they could also be used to track ownership of rights or real life items without a central authority that everybody needs to trust.

    Of course, cryptobros immediately went to pushing them as an investment scheme, and the actual implementations are slow, inefficient, and downright expensive to use. I don’t think anybody has managed to make NFTs actually useful, but I imagine the original creators weren’t looking to create… Whatever this is.


  • Doesn’t change the voting situation. Since your votes need to be seen by other instances, Lemmy needs a mechanism for federating votes. Since instances are untrusted, there needs to be some way of preventing manipulation. Thus, AFAIK, Lemmy simply shares your votes across instances, letting each one tally them up. As a side effect, any server admin of an instance you can interact with can also get a list of all your votes.


  • KubeRoot@discuss.tchncs.deto196@lemmy.blahaj.zoneRule
    link
    fedilink
    English
    arrow-up
    8
    arrow-down
    1
    ·
    1 month ago

    Having two different configurations of assets requires making a system that can switch between them, separate deployments for them, some way to actually fetch the asset pack by the users, testing to make sure both configurations work correctly, actually deploying the separate asset pack during an update, and then spending time fixing bugs that inevitably come up with any added complexity.

    Could they do it? Absolutely. Should they do it? Probably.

    Would there be no downside, no tradeoff? Claiming so is plainly ridiculous.


  • Dual booting is problematic, as mentioned you’re messing with your partitions and could mess up your windows partition, but also windows can, unprompted, mess up your Linux bootloader. As long as you’re careful with partitions and know how to fix your bootloader from a live image, there’s no real issue, but it’s worth keeping in mind.

    By the way, I recommend rEFInd for the bootloader when dual booting, it doesn’t require configuration and will detect bootable systems automatically.

    A VM sounds like a good idea to try a few things out, but do keep in mind performance can suffer, and you might especially run into issues with things like GPU virtualization. If you want to properly verify if things work and work well enough, you’ll want to test them from a live system.

    As a final note, you can give your VM access to your SSD/HDD - if you set that up properly, you can install and boot your Linux install inside a VM, and later switch to booting it natively. You still have the risk of messing up your partitions in that case, but it can be nice so you can look things up on your host system while setting up Linux in a VM.



  • Yes, but the issue is that the lemmy.ml maintainers are the Lemmy developers. The people who created the software, and continue maintaining it, are the same people who created the instance.

    It’s the well-known question of if you can, or should, separate the art from the artist. By funding, in its current state, the development of Lemmy, you’re supporting the people running an instance you disagree with. Unless you’re willing to take up the work to fork and continue development yourself, you can’t detach them, you either support both or none.




  • Fundamentally, the repository you have on GitHub is the same thing as the repository you have on your computer when you clone it. Pulling and pushing are shorthands for synchronizing commits between the two repositories, but you could also synchronize them directly with somebody else who cloned the repository. As somebody mentioned, you can also just host the same repository on two servers, and push to both of them.

    The issue is that git doesn’t include convenient features like issues, pull requests, CI, wikis, etc., and by extensions, those aren’t included in your local repository, so if GitHub takes them down, you don’t have a copy.

    An extra fun fact is that git can be considered a blockchain. It’s a distributed ledger of immutable commits, each one representing a change in state relative to the previous one. Everybody who clones a repository gets a copy of its entire history and fast forwards through the changes to calculate the current state.


OSZAR »