MariaDB Plc. appears to be the top contributor to MariaDB's codebase (81.9% of commits since the beginning of 2020)[0].

[0]: https://mariadb.org/mariadb-contribution-statistics-march-20...

> MariaDB Plc. appears to be the top contributor to MariaDB's codebase (81.9% of commits since the beginning of 2020)[0].

For context MariaDB existed before 2020, Before the Plc, since 2009, and will continue to exist after.

speaker support is being actively worked on [1]

[1]: https://phpc.social/@marcan@treehouse.systems/10981800943090...

The benchmarks appear to show AWS wins by a considerable margin in all tests, and is cheaper at all quoted price points, but is hardly above Azure in the cost performance table. This appears to be due to including Azure's reserved pricing but continuing to use AWS and GCP's on-demand pricing. This is misleading, as both GCP and AWS offer discounts for yearly commitments.

Also, the RAM ratios for the machines are different across vendors. E.g. In the blogpost, the AWS machines have 2GB/vCPU vs 4GB/vCPU for GCE. This does depends on the workload though.

Thanks for your comment, for this part I will try to let the author knows this case.

Despite Mozilla's claim that Firefox Suggest is opt-in, many users (myself included) found the setting enabled by default when it initially shipped.

I'd recommend checking your settings to see if sponsored suggestions are enabled.

Not sure what OP is referring to, but Microsoft has multiple Visual Studio Code extensions (e.g. Remote SSH) that are closed-source and hard-coded not to work with any self-compiled versions of Visual Studio Code.

From their S-1:

> We do not have an adequate history with our subscription or pricing models to accurately predict the long-term rate of customer subscription renewals or adoption, or the impact these renewals and adoption will have on our revenues or operating results.

For context, GitLab recently axed their lowest priced plan and grandfathered in existing users at cheaper rates for the next year. Their retention rate may drop once discounts run out and the new pricing kicks in.

As to the parent's comment about "The Homer" and non-core features being bad, I'd point to their CI autoscaling solution as an example of being underdeveloped, over-marketed, and suffering from technical debt. Their autoscaler uses docker machine behind-the-scenes, which hooks into various cloud providers to abstract away the act of spinning up new VMs. It works reasonably well, but Docker has archived the repository and no longer supports the software. GitLab forked the repository and maintains it for critical fixes, but is not willing to develop or accept new features. It has been known to break against new versions of Docker, does not handle concurrency very well in new environments, and does not allow [1] executing multiple concurrent jobs within spun up VMs, despite marketing that it can [2].

While the autoscaler does work, it's limitations and quirks reduces it's utility and cost-savings significantly within smaller organizations. The technical debt leaves me doubting any improvements will come within the next few years as they try to architect a new solution to replace the existing one.

I have no idea how GitLab compares in other areas, but within CI autoscaling it seems they're stuck with a cliff to climb down before they can move forward again.

[1]: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2787#no...

[2]: https://about.gitlab.com/blog/2017/11/23/autoscale-ci-runner...

CI is moving in Kubernetes everywhere I know. Builtin kubernetes pod autoscaler can add capacity based on job queue length metric, so no need for docker machine anymore.

To some extend, yes. On the other hand, they’re currently the only service where I can set up one VM, give it my AWS credentials, and have fully automated scaling.

The hoops you have to jump through in Github are absolutely unfun.

> Free is for a single developer, with the purchasing decision led by that same person

> Premium is for team (s) usage, with the purchasing decision led by one or more Directors

Doesn't this conflict with the stewardship promise that "The open source codebase will have all the features that are essential to running a large 'forge' with public and private repositories"?

When the tiering of a feature is being evaluated, the stewardship promise (https://about.gitlab.com/company/stewardship/#promises) will override the guidance on our pricing page (https://about.gitlab.com/company/pricing/#buyer-based-tierin...).

Thanks again for the question.

Edit - I've created an MR to document this on our pricing model page: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

Thanks for the question. I shared it with @sytse and he's putting some thought into it.

If there is a Lua library for it, it'd be possible with the Nginx Lua module [1]

[1]: https://github.com/chaoslawful/lua-nginx-module

Check out https://play.google.com/store/apps/details?id=com.premii.hn , it's a fairly clean version for Android.

The colon-based syntax was voted down.

What went live in 5.4 was support for brackets in lieu of array()

    // Typical array syntax
    $arr = array('key' => 'asdf');

    // Supported in 5.4+
    $arr = ['key' => 'asdf'];