I’m the Yujiri from yujiri.xyz. https://yujiri.xyz/contact.gmi

  • 14 Posts
  • 188 Comments
Joined 3 years ago
cake
Cake day: June 25th, 2021

help-circle



  • Well, on that benefit: you could get the same information from non-for-profit sources, in a more neutral and ethical way.

    Not in dispute, but that’s a non sequitur. Just because a better alternative is possible doesn’t mean the existing thing provides no benefit - otherwise you’d be saying food stamps have no benefit because the benefit could be provided more efficiently by a better system, etc.

    When someone’s freedom affects everyone basics rights, we ought to act.

    Really puzzled how any of the things you’ve mentioned, except pollution, “affect everyone’s basic rights”. Do people have a basic right to never be spoken to by someone with a motive that renders them possibly biased (even though the existence of that motive is generally obvious)? That’s all for-profit advertizing is.

    The idea that you should be allowed to steal from someone (I assumed that by ‘banned’ you are imagining the punishment being a fine) for speaking to others with a bias is absurd, and if you were to believe that consistently, it would also apply to lots of ordinary peer to peer conversation.




  • What a terrible article.

    Whenever I read the claim that copyleft ideology is hypocritical because it imposes a restriction on acceptable use of the software, I pretty much just stop paying attention. The ideology of copyleft is very clear and consistent: making non-free derivatives isn’t a valid freedom because it takes freedom away from others. No, just because you don’t like something doesn’t make it hypocritical. Compare copyleft to defensive force: everyone agrees that it’s wrong to punch someone, but everyone also agrees that you can punch back against someone who punches first.





  • The two use cases suggested:

    Alice holds a digital wallet that securely manages her identity, data, and authorizations for external apps and connections. Alice uses her wallet to sign in to a new decentralized social media app. Because Alice has connected to the app with her decentralized identity, she does not need to create a profile, and all the connections, relationships, and posts she creates through the app are stored with her, in her decentralized web node. Now Alice can switch apps whenever she wants, taking her social persona with her.

    • Creating a profile takes what, 2 minutes? And you do it only once per app.
    • Connections and relationships: Okay so you want to copy your list of followers? That’s nothing remotely new. Pleroma literally has that (also for blocks and mutes).
    • If you want automatic discovery of existing followers, fine, but note that already exists on some platforms via email addresses or phone numbers. All you’d need to extend it to secure, decentralized identifiers is for those platforms to have a metadata field for users to put such an identifier. Hardly revolutionary.

    Bob is a music lover and hates having his personal data locked to a single vendor. It forces him to regurgitate his playlists and songs over and over again across different music apps. Thankfully there’s a way out of this maze of vendor-locked silos: Bob can keep this data in his decentralized web node. This way Bob is able to grant any music app access to his settings and preferences, enabling him to take his personalized music experience wherever he chooses.

    So you want to import playlists between music apps? That could only work if each song has a globally unique identifier for the playlists which is known to all the platforms. That isn’t the case, and changing that would require every musician to change their workflow.




  • This is a concern I hadn’t really thought of before.

    Stuff I read in the past that I think is important here:

    As per Drew’s article, I think the main defense we have is the idea of finite scope. In a free alternative to twitter (or another social media platform), there is not an infinite set of features that are desirable. If we pick our feature set wisely, we can build a platform that feels as though nothing is missing, and if we do this, they won’t be able to do the “extend” part because it would be obvious that anything they could add would be making the experience worse, not better. Some of our solutions may have already achieved this - if that’s so, the strategy becomes convicing enough people of that.

    For one example I’d name quote tweets. This is a feature that I think is probably an anti-feature. Compared to replies, it is a “third person” form of engagement, which naturally breeds toxicity rather than understanding in disagreement, and encourages people to engage with the worst people on the platform. It also biases people toward having less realistic and less optimistic views of those who disagree with them by showing them only the worst members of the opposing camp. See Shamus Young’s “This Game is Bad For You” - very insightful on this topic.

    If we can identify and avoid all such anti-features, and convince enough people to see them as such, we foil the middle E in EEE.


  • I think all of these arguments are really bad, and I’m someone who hates universal package managers.

    “Fragmentation is not an issue”

    t seems, they all agree that all of the different packaging formats and managers are a problem. However, is it really so?

    Well, duplication of effort is always a downside.

    As a developer, by simply using a free licence, you can just sit back and let all of the distros build binaries and do all of the work for you.

    The whole complaint being made is that this doesn’t always happen in a timely fashion, and even when it does, it requires a lot of work to be done by each of those distributions.

    “There is no need for universal package managers”

    Yet, there is a universal package manager that has been around longer than even traditional package managers. BUILDING FROM SOURCE! Many people forget that all of their software is a git clone, make, and make install away from being installed.

    I wish it were that simple. In practice, most projects are much harder to build than that. Many use build systems other than plain make such as CMake or Meson and Ninja or GNU autotools (and every project that uses autotools has different levels of intermediate files committed so different commands are needed to build it), and you’ll need to install whatever bespoke build tools they have. I almost always run into arcane error messages that can give me a lot of trouble even as an experienced Linux user and programmer. This is especially true if you’re on a distribution (like anything Debian-based, in other words most newbie distros) where header files are in separate packages, so trying to build anything will give you errors as if you have nothing installed.

    A story I always share when this comes up is of my GTK patch that fixed a GObject Introspection annotation (affects generated bindings for other langauges). I spent twelve fucking hours trying to compile GTK and failed. I gave up and submitted the patch without having seen a successful build (it got accepted).

    Again, I am an experienced Linux user and programmer. If even I have so much trouble compiling programs from source, expecting anyone who doesn’t have my skill set to do it is crazy.

    “Universal package managers are inefficient”

    Flatpak, Snap, and AppImage are just not as fast as conventional package formats. Try using any modern version of Ubuntu, and just see how slow their Snaps are.

    I have never noticed them being particularly slow, either to install or to run, though I can’t comment on Snap specifically as I’ve only used Flatpak and AppImage.

    But, that isn’t really even the worst part. Because of the nature of universal package managers, they require much more space than traditional packages. Every single app, instead of sharing the dependencies of all other apps on the system, is bundled with all of its dependencies. This can add gigabytes of space to many apps, and slow down older HHD’s.

    I mean, sure, reducing space requirements is noble, and universal package managers probably take up a little more space (I haven’t analyzed it myself). But it’s far from a chief concern in a day where even low-end drives have hundred of gigabytes of capacities. And as for " instead of sharing the dependencies of all other apps on the system" - blaming static linking is a serious mistake. The space impact of static linking is not a large cost and it easily makes up for it with its advantages in simplicity and reliability. I would blame dynamic linking for a lot of the headaches we have with packaging and compilation. Dynamic linking introduces the need for complex dependency resolution algorithms, tying each executable to a huge amount of environment it has to carry around in order to work, breaking the portability of programs and crowding your package manager output with obscure libraries you’ve never heard of and shouldn’t have to.

    http://harmful.cat-v.org/software/dynamic-linking/