• 0 Posts
  • 5 Comments
Joined 3 years ago
cake
Cake day: June 30th, 2023

help-circle
  • wanting to advertise for the little guy in general is kind of pointless, it feels good until you realize that in a healthy ecosystem there are just always going to be more little guys–the middle guys are selected from larger pool and the big ones are selected from larger pool of the middle guys … it’s the evolution. and evolution is all about niches and being good enough.

    the kind of link lists linked in the OP are actually awesome, but they are best served in larger number and in context. especially, if eg. i see someone make an insightful post or article and turns out the same person has a list of links, then it’s usually a treasure trove of more posts, articles, insights and even projects and communities. and yes, if i gave the link list to my mom it would be completely counter-productive, regardless of whether someone is a “little guy” or not. the littleness is not the point, the relevancy is.

    and sure you could make link lists that are assorted ranging topics with the main criterion “the author found it interesting and want to share it and/or come back later to it”, and while some of that cake is eaten by micro-blogging sites like mastodon or bluesky (esp. the sharing and quick discussion). outright simple, structured lists also have own kind of charm.


  • Vast, vast majority of sites that exist are small. And significant portion, if not most of them are going to be actually not that interesting or outright junk. Who’s going to decide which are good enough to show up on the list? And how are you going to maintain them over time—if you succeed in making a small site discoverable, now what, is it going to be on the list forever? If not, on what kind of criteria you’re going to maintain it, and how are you going to measure it?

    Don’t get me wrong, I’m not saying people should built these lists, they absolutely should. But there is no one-size-fits-all solution and creating something that resembles one-size-fits-all is going back to the twisted, weird system that so many of Lemmy users (including me) are happy to be away from.

    I see no problems with the screenshot you posted. Of course that “KIA” comment is extremely insensitive at best, but we all know that any sort of open Internet community has this problem.

    If you find Reddit more interesting, then you have already solved the problem for you: just go discover things there. If you find your Lemmy homepage boring, maybe sub to different communities and set up your page to show subscribed only (that particular setting helped me a lot).

    If you want to create some sort of smart automated strategies that get you to have the the cake and eat it too (eg. remain subscribed to all of those communities but filter posts for based on some sort of diversity criteria eg. “no star trek more than once a month”) then please go ahead and experiment: the content is freely available using computer-readable formats, you can learn to code or hire someone… I bet someone is already doing something like that. You don’t need to solve the problem on higher level, and doing so is going to do more harm than good.

    But as you say, it’s not an easy problem but I think it shouldn’t be. No individual should be able to impose restrictions like that globally. We are each responsible for our own diet. (And for lemmy.world thank mods for keeping out the shit sprayers.)



  • keeping all these containers up to date

    Updates are a good way to get the security holes fixed, but unfortunately it’s also often how the holes get in in the first place.

    I mean, for most projects it’s kind of sensible to assume that over long time, the code will become rather more secure and less buggy, so eventually the pros/cons might come out in favor of a strategy of updating every time. But it’s good to know that every update is inherently a double edged sword.

    That’s why I like the model that distros like Debian do: they keep the code stable for long time, and only send updates for which a typically independent party (package maintainer) has already decided that a given update indeed is a necessary bugfix, or even specifically a security fix. Similar policy of course could be applied to a Docker container as well, but I don’t know how many projects do this, and it would be a per-project policy, most probably not quite independent.