I can see Matt’s point of view. Data transfer fees are expensive, especially at WordPress scale. Automattic probably covers a lot of that cost that wordpress.org is incurring and wants WP Engine to pay their fair share.
WP Engine also seems to do some other “not in good faith” things such as change the woocommmerce Stripe attribution from wordpress.org to their own Stripe account.
While the legal dispute is on trademark, I think it’s really on WP Engine profiting on wordpress.org without giving back. It’s not illegal, but blacklisting WP Engine isn’t illegal either.
Automattic is essentially subsidizing a private equity backed company. I’d be upset and frustrated too if I was in Matt’s position.
If you support WP Engine, you’re supporting Silver Lake Private Equity.
If Matt had wanted to, for example, tell WPEngine they're own their own for hosting these services with a cutoff date at least 4 weeks in the future, then fair play. Or to demand to bill them some reasonable cost share of the price to operate (and let's not play games, a reasonable cost for the humans involved, which likely far exceeds servers or bandwidth), then still fair play.
To pitch a tantrum, cut them off with no notice, then gloat about it online... oof. I can't understand why anyone would want to be in business with someone like that.
This position rests pretty heavily on the idea that Wordpress.com is subsidizing wordpress.org, which is a charitable foundation that accepts donations. Do you have any specific reason to believe this is true? I don’t recall seeing that complaint directly here but maybe I missed it.
When I say subsidizing I mean financially subsidizing (i.e. paying for wordpress.org bandwidth costs) - that's the only way the comment makes sense, and I am not inclined to believe it to be true without evidence. As the other response notes though wordpress.org isn't even the foundation apparently, so is wordpress.com subsidizing wordpress.org? Have they asked WPEngine to cover their costs?
> Wordpress.com is subsidizing wordpress.org, which is a charitable foundation that accepts donations
Nope. There goes Matt, muddying the waters. Contrary to many people (including myself's belief) wp.org is very explicitly, in his words, NOT the Foundation, just a benevolent gift of his to the community. You could be excused, given all the links to donate to the Foundation and accompanying text, or the fact that it lives on the Foundation's ASN, though.
Not normal enough. Would you do all your personal emailing on your work email? I don't know why so many people have a blind spot when it comes to GitHub
At $JOB, it's mandated to have a separate GitHub account
Yes. My work GitHub account is via SSO using my work creds. My personal GitHub account is much older and uses my personal email address.
Of course, we can’t (or shouldn’t) be uploading any of our code to GitHub for work. We have self-hosted Bitbucket servers. The corporate GitHub accounts are strictly used for Copilot.
If/when I leave the company, I’m pretty sure they don’t want all the code tied to my personal account. That sounds like a nightmare. I don’t want that either.
Yes, of course. In fact it is a pretty bad idea to use the same profile for an employer. Always treat an employer as disposable, along with the respective GitHub username for it.
I would say most devs use same GitHub profile for work and personal projects. GitHub provides pretty easy way to join various organizations with same handle. It almost seems exception when a developer creates a new profile for work.
The practice can vary significantly by the employer. Some employers prefer the usernames be new and unique to the employer, whereas others don't care. It's obvious that it's a major liability for the employee to reuse the username for personal and professional organizations.
Yeah, exactly. Personally I always thought that was a better policy (to have separate profiles) but I've actually had senior devs in the org tell me to just use my personal one and add my work email to it, so that's what I did. Seemed strange to me but I didn't question it too much. Maybe I should've, lol.
I agree and apologise for writing bigserial out of ossified habit. Identity columns hew to the SQL standard, bigserial is a pg-ism. I actually do still use it when the ORM’s DDL generator prefers as much (looking at you Rails), there’s no gain from fighting the middleware.
For other readers: the two are almost the same in behaviour, they differ primarily in that identity columns don’t need a USAGE grant on their associated sequence, and the ALWAYS makes it harder (but despite the term not actually impossible) to override the default value on row insert.
> class UUIDField: A field for storing universally unique identifiers. Uses Python’s UUID class. When used on PostgreSQL and MariaDB 10.7+, this stores in a uuid datatype, otherwise in a char(32)
> [...] Lookups on PostgreSQL and MariaDB 10.7+: Using iexact, contains, icontains, startswith, istartswith, endswith, or iendswith lookups on PostgreSQL don’t work for values without hyphens, because PostgreSQL and MariaDB 10.7+ store them in a hyphenated uuid datatype type.
> For backends that have no “native” UUID datatype, the value will make use of CHAR(32) and store the UUID as a 32-character alphanumeric hex string.
> For backends which are known to support UUID directly or a similar uuid-storing datatype such as SQL Server’s UNIQUEIDENTIFIER, a “native” mode enabled by default allows these types will be used on those backends.
> In its default mode of use, the Uuid datatype expects Python uuid objects, from the Python uuid module
> safe: The UUID was generated by the platform in a multiprocessing-safe way
And there's not yet a uuid.uuid7() in the uuid Python module.
UUIDv7 leaks timing information ( https://news.ycombinator.com/item?id=40886496 ); which is ironic because uuids are usually used to avoid the "guess an autoincrement integer key" issue
> use “bigint generated always as identity” instead of bigserial.
The commenter you are replying to was not saying anything about whether to use UUIDs or not; they just said "if you are going to use bigserial, you should use bigint generated always as identity instead".
The question is the same; why would you use bigint instead of the native UUID type?
Why does OT compare text and UUID instead of char(32) and UUID?
What advantage would there be for database abstraction libraries like SQLalchemy and Django to implement the UUID type with bigint or bigserial instead of the native pg UUID type?
Also, I think you're misunderstanding the article. They aren't talking about storing a uuid in a bigint. They're talking about have two different id's. An incrementing bigint is used internally within the db for PK and FK's. A separate uuid is used as an external identifier that's exposed by your API.
Many people store UUID's as text in the database. Needles to say, this is bad. TFA starts by proposing that it's bad, then does some tests to show why.
I'm not quite sure what all the links have to do with the topic at hand.
Which link are you concerned about the topicality of, in specific?
Shouldn't we then link to the docs on how many bits wide db datatypes are, whether a datatype is prefix or suffix searchable, whether there's data leakage in UUID namespacing with primary NIC MAC address and UUIDv7, and whether there will be overflow with a datatype less wasteful than the text datatype for uuids when there is already a UUID datatype for uuids that one could argue to improve if there is a potential performance benefit
Another model I’ve seen is a combination of subscription and usage where there’s a monthly base and then additional charge for usage overages. Example is Sendgrid.
Tagging documents isn’t really a big problem. Companies typically only have a finite, handful of contract templates that the admin tags manually.