> A new compiled version is released under an MIT license every month on the 16th.

What does than even mean? Is it equivalent to what we use to call "freeware". Is it legal to modify the binaries?

Not really? FOSS communities overestimate their importance on a daily basis.

Case in point: Linux. 90%+ of commits were corporate sponsored… in 2004. The pure community member does almost nothing of importance for Linux anymore; or any of these projects.

Zulip (for Slack) and Wekan (for Trello) are good replacements, save yourself the ethical and technical worries.

https://zulip.com/

https://wekan.github.io/

and still no one from that company has admitted to it being a mistake?

very nice

    diff --git a/server/channels/app/limits.go b/server/channels/app/limits.go
    index b13103898a..a8be8dd908 100644
    --- a/server/channels/app/limits.go
    +++ b/server/channels/app/limits.go
    @@ -36,17 +36,6 @@ func (a *App) GetServerLimits() (*model.ServerLimits, *model.AppError) {
                    limits.MaxUsersHardLimit = licenseUserLimit + int64(extraUsers)
            }
     
    -       // Check if license has post history limits and get the calculated timestamp
    -       if license != nil && license.Limits != nil && license.Limits.PostHistory > 0 {
    -               limits.PostHistoryLimit = license.Limits.PostHistory
    -               // Get the calculated timestamp of the last accessible post
    -               lastAccessibleTime, appErr := a.GetLastAccessiblePostTime()
    -               if appErr != nil {
    -                       return nil, appErr
    -               }
    -               limits.LastAccessiblePostTime = lastAccessibleTime
    -       }
    -
            activeUserCount, appErr := a.Srv().Store().User().Count(model.UserCountOptions{})
            if appErr != nil {
                    return nil, model.NewAppError("GetServerLimits", "app.limits.get_app_limits.user_count.store_error", nil, "", http.StatusInternalServerError).Wrap(appErr)

https://github.com/mattermost/mattermost/issues/34271#issuec...

Also one of the comments:

> Would be a shame if someone with too much time on their hands dug into the binary and added a few zeroes to the message limit

Can this be done via some binary-patch tool? Really curious. It would save recompile efforts.

edit: link

edit 2: I just realized, their Ubuntu repository only contains the Enterprise edition labeled "Free edition". This is really confusing. I does look like entishitification has started long ago: https://docs.mattermost.com/deployment-guide/server/deploy-l...

At first they tried to say that "we're a school" and then when the MM rep said they have an Education license, they admitted that they are not actually a school, but rather a consulting company that is gouging schools by overcharging for open source software.

Enshitification ensues.

I used to work for Facebook and many years ago people noticed you couldn't block certain people but the one that was most public was Mark Zuckerberg. It would just say it failed or something like that. And people would assign malice or just intent to it. But the truth was much funnier.

Most data on Facebook is stored in a custom graph database that basically only has 2 tables that are sharded across thousands of MySQL instances but most almost always accessed via an in-memory write-through cache, also custom. It's not quite a cache because it has functionality built on top of the database that accessing directly wouldn't have.

So a person is an object and following them is an edge. Importantly, many such edges were one-way so it was easy to query if person A followed B but much more difficult to query all the followers of B. This was by design to avoid hot shards.

So I lied when I said there were 2 tables. There was a third that was an optimization that counted certain edges. So if you see "10.7M people follow X" or "136K people like this", it's reading a count, not doing a query.

Now there was another optimization here: only the last 10,000 of (object ID,edge type) were in memory. You generally wanted to avoid dealing with anything older than that because you'd start hitting the database and that was generally a huge problem on a large, live query or update. As an example, it was easy to query the last 10,000 people or pages you've followed.

You should be able to see where this is going. All that had happened was 10,000 people had blocked Mark Zuckerberg. Blocks were another kind of edge that was bidirectional (IIRC). The system just wasn't designed for a situation where more than 10,000 people wanted to block someone.

This got fixed many years ago because somebody came along and build a separate system to handle blocking that didn't have the 10,000 limit. I don't know the implementation details but I can guess. There was a separate piece of reverse-indexing infrastructure for doing queries on one-way edges. I suspect that was used.

Anyway, I love this story because it's funny how a series of technical decisions can lead to behavior and a perception nobody intended.