Stubsack: weekly thread for sneers not worth an entire post, week ending 1st December 2024 - eviltoast

Need to let loose a primal scream without collecting footnotes first? Have a sneer percolating in your system but not enough time/energy to make a whole post about it? Go forth and be mid: Welcome to the Stubsack, your first port of call for learning fresh Awful youā€™ll near-instantly regret.

Any awful.systems sub may be subsneered in this subthread, techtakes or no.

If your sneer seems higher quality than you thought, feel free to cutā€™nā€™paste it into its own post ā€” thereā€™s no quota for posting and the bar really isnā€™t that high.

The post Xitter web has spawned soo many ā€œesotericā€ right wing freaks, but thereā€™s no appropriate sneer-space for them. Iā€™m talking redscare-ish, reality challenged ā€œculture criticsā€ who write about everything but understand nothing. Iā€™m talking about reply-guys who make the same 6 tweets about the same 3 subjects. Theyā€™re inescapable at this point, yet I donā€™t see them mocked (as much as they should be)

Like, there was one dude a while back who insisted that women couldnā€™t be surgeons because they didnā€™t believe in the moon or in stars? I think each and every one of these guys is uniquely fucked up and if I canā€™t escape them, I would love to sneer at them.

Last weekā€™s thread

(Semi-obligatory thanks to @dgerard for starting this - this one was a bit late, I got distracted)

  • self@awful.systemsEnglish
    17Ā·
    26 days ago

    after going closed-source, redis is now doing a matt and trying to use trademark to take control over community-run projects. stay tuned to the end of the linked github thread where somebody spots their endgame

    this is becoming a real pattern, and it might deserve a longer analysis in the form of a blog post

    • hrrrngh@awful.systemsEnglish
      10Ā·
      25 days ago

      I donā€™t think the main concern is with the license. Iā€™m more worried about the lack of an open governance and Redis priorizing their functionality at the expense of others. An example is client side caching in redis-py, https://github.com/redis/redis-py/blob/3d45064bb5d0b60d0d33360edff2697297303130/redis/connection.py#L792. Iā€™ve tested it and it works just fine on valkey 7.2, but there is a gate that checks if itā€™s not Redis and throws an exception. I think this is the behavior that might spread.

      Jesus, thatā€™s nasty

      • self@awful.systemsEnglish
        8Ā·
        25 days ago

        it is! and ā€œwe have no plans to break compatibilityā€ needs to be called out as bullshit every time itā€™s brought up, because it is a tactic. in the best case itā€™s a verbal game ā€” they have no plans to maintain compatibility either, so they can pretend these unnecessary breakages are accidental.

        I canā€™t say I see the outcome in the GitHub issue as a positive thing. both redis and the project maintainers have done a sudden 180 in terms of their attitude, and the original proposal is now being denied as a misunderstanding (which it absolutely wasnā€™t) now that it proved to be unpopular. my guess (from previous experience and the dire warnings in that issue) is that redis is going to attempt the following:

        • take over the projectā€™s governance quietly via proxies
        • once thatā€™s done, engage in a policy where changes that break compatibility with valkey and other redis-likes are approved and PRs to fix compatibility are de-prioritized or rejected outright

        if this is the case, itā€™s a much worse situation than them forking the project ā€” this gets them the outcome they wanted, but curtails the communityā€™s ability to respond to what will happen until itā€™s far too late.