• 0 Posts
  • 54 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle

  • That basic idea is roughly how compression works in general. Think zip, tar, etc. files. Identify snippets of highly used byte sequences and create a “map of where each sequence is used. These methods work great on simple types of data like text files where there’s a lot of repetition. Photos have a lot more randomness and tend not to compress as well. At least not so simply.

    You could apply the same methods to multiple image files but I think you’ll run into the same challenge. They won’t compress very well. So you’d have to come up with a more nuanced strategy. It’s a fascinating idea that’s worth exploring. But you’re definitely in the realm of advanced algorithms, file formats, and storage devices.

    That’s apparently my long response for “the other responses are right”





  • A complicated plugin ecosystem (e.g. Jenkins) makes for a terrible use experience. It’s annoying to configure a bunch of config files. Managing dependencies can be a complete nightmare. these problems also complicate your ci/cd.

    So I’ll offer a slightly different answer. I prefer a single file instead of splitting up the config. And I’ll use OpenTelemetry as an excellent example of why. the plugins are compiled right into the app binary. This offers a ton of advantages, including a great reason to merge all of your app configs in a single file.

    This really only works well if you have a good app though.








  • So I read a bit of Mozilla’s documentation about this feature. It sounds like they’re trying to replace the current practices with something safer. Honestly, my first thought is that this is a good thing for two reasons.

    • It’s an attempt to replace cross site tracking methods, which are terrible
    • Those of us that fight against ads, tracking, etc. can simple use typical methods to block the api. Methods that were already using (I think)

    If both of these are true, then it could be a net positive for the world. Please tell me if I’m wrong!


  • Ok that is an impressive number but it feels a little disingenuous. You still need to something on your machine to interpret the js code, right? Is that included in the 13k? How much storage does that take?

    EDIT: Well this is by far my most negative comment here. That’s almost entertaining. I’ll share a few more of my thoughts here rather than respond to individual comments. Maybe the context will make this more palatable.

    First, I expect that the js language is doing most of the work here. Which makes sense. But having a browser installed as a prerequisite is an enormous dependency.

    How would that stack up against other languages? Can I build a 13k binary using C? How about C#? I think Go is maybe the most interesting because the binary is entirely self contained by default. No external dependencies aside from the OS. I don’t think this or a similar game is viable with only 13k. Which is fine! I just that I find 13k is disingenuous.

    That brings up the question of whether or not we should include the OS in the storage size. I would think not. But that’s only because the OS is (usually) the least common denominator when we talk about developing software. It’s generally assumed by default. But if someone wants to compare with a game that interfaces with hardware directly, then yes, we should absolutely include the OS as a dependency.

    Now that I’m giving this more thought, I suspect that the devs wrote 13k of code + assets to make the game functional. Still impressive. But the more I think about this, the more meaningless that number gets. Does pre or post compiling matter more? What if we compress the thing as tarball? There’s just too many ways to manipulate this number.



  • I’m generally not a big fan of big social media like e.g. Facebook where you might have many thousands of followers, purposefully grow the numbers, etc. I personally think these things are an everyday evil. Yes, it’s a bit melodramatic 🙂but that’s how I feel. Reddit, and now Lemmy are about as far as I like to go with it.

    So the isolation of geo-local-only federation is a feature. The feature, actually. I want an entire social media platform that isn’t capable of focusing on single accounts. Where you are near guaranteed to interact with your local community only. Where it would take a dramatic effort for a single actor to influence global opinions. I want a social media platform that isn’t so easy to manipulate. I could go on and on.


  • After reading your responses, it seems like we’re describing two different methods of building this system.

    Your ideas seems to depend on having many instances for various regions, where all instances are federated with each other. So my local instance somewhere in the US would still be federated with for example, an instance in Germany. But the content I receive would be heavily focused on “nearby” content. Interesting

    My ideas are based on an important difference. An instance for my town would only federate with instances for the surrounding towns. Maybe one or two more “hops” away. So sharing content between my local instance and one in Germany would be impossible. Content on my local instance would only be accessible to users in nearby instances. Local content enforced by local federation.


  • I spent several weeks thinking about this exact idea.

    Federation is cool. You could set up each instance to only federate with instances for nearby towns and cities. Maybe a “2 district” radius. Users would only see content for their local communities. Local news stays local. Local government could officially participate if they wish. People you talk to are actually neighbors you might see in person. Larger regions like counties, states, provinces, or even countries, could also have dedicated instances and federate similarly. I think this is the big appeal and it sounds awesome!

    There are a few problems 🙂

    First is a little bit of confusion with posting. Let’s say that I see a post about a cool new restaurant in my town. I share it with a friend who lives a few towns away and that’s outside the “federation radius”. I can’t share the post with that friend very easily. Maybe the tools could be enhanced to make this viable?

    Second is a matter of privacy. How do you know that new accounts belong to people associated with the geographic location of each instance? If you don’t validate, the system will certainly be abused. If you do validate, then users need to supply some real info! Home address, ID, etc. that’s a big deal for users and instance admins.

    Third. What happens if you move? Do you have to abandon your old account and start over? Again, the system itself can be developed further to solve this. But that’ll take time and money.

    Next is the operating costs. You would need to build thousands of instances to build this system up. And each one would have to be tied to a geographic region. You need new features to handle signups this way. You have the simple cost of running these servers. You probably need a lot of staff to manage it all. This is an expensive platform for one party to run. Alternatively…

    It doesn’t have to be one party running this entire system. That’s the point of the Fediverse, right? The operational costs go way down if anyone can run their own instance. But how do you enforce the rules of federating with instances for geographically nearby locations? I don’t see a reasonable way to solve this one.

    I could probably keep listing issues. But these are the big ones IMO. If you solve these, the system is viable and could be amazing.



  • I agree in full!

    I’ve thought quite a bit about corporate funding of the fediverse. The only possibility good way that I currently see is if there’s a not-for-profit acting as a middle man to dispense the funds. And that not-for-profit can’t voice opinions on how the fediverse is developed. Even this is wishful thinking.

    I’ve actually given thought to creating this non-for-profit but I don’t really know how to get started or get attention for significant donations.