kenshaw

I encountered this while trying to issue a new certificate for a service. As a temporary fix, started using ZeroSSL which conveniently also supports the ACME protocol. While not a big problem, if you have something like `cert-manager` being used on Kubernetes, then it requires quite a bit of reconfiguration, and you may spend a couple hours trying to figure out why a certificate hasn't been issued yet.

That said, I'm unbelievably grateful for the great product (and work!) LetsEncrypt has provided for free. Hope they're able to get their infrastructure back up soon.

Thanks, appreciate the package. I submitted a PR as I was also looking for a Go package similar to this, and wanted to make using this as a library a bit easier. I plan on using this to automate some website login/authentication flows, where physical tokens are (for obvious reasons) not really a possibility.

discord.

I'm the author of xo. I appreciate the reference here, but that's not really what xo does. It generates all boilerplate for you directly based on whatever is defined by the database. It doesn't do anything with YAML, nor does it generate a SQL schema. xo does have 2 templates that _generates_ YAML and _generates_ SQL queries to recreate the schema, but the only input you can give xo is an active database.

That's cool. As per the other comment, you should share it with the community.

A long overdue release. General bug fixes, \d* commands, new database support, and a native Oracle driver.

Foreign keys should definitely be used in most schema designs. While I can agree that they are problematic when doing a schema migration, a schema migration would only happen "very rarely" whereas inserts/deletes happen regularly. I believe this comment is more of a reflection of the specific database (MySQL) which has relatively poor FK performance and adjunct issues when compared to other SQL databases.

Also, from a process perspective of migrating a schema, the ideal mechanism would be to incrementally copy from the existing schema to the new schema (meaning there is no breakage in the interim). Granted (and somewhat obviously) for databases as large as what GitHub is likely using, this is not possible -- and so a "full migration" at once is their only option. However, part of that "full migration", to me, would be to _remove_ the original foreign keys from the schema, rename/delete/alter tables/fields/indices, and then after all of that is complete, as a final step, re-add referential integrity (ie, foreign keys).

I'd specifically like to point out the following:

1) This comment gives advice about all SQL databases based on the conclusion / operation of only one database (MySQL), whereas the same base facts do not apply to others (eg, PostgreSQL, Microsoft SQL Server, ...), and should not be used to evaluate whether using FKs makes sense for other databases or not.

2) Schema migrations should be done rarely, if ever. A better approach would have been to start with a schema design that was less prone to _needing_ change. Regardless, even if schema migrations are done with _regularity_, that frequency would still be orders of magnitude less regular than, eg, code changes or CRUD operations. As such, throwing away FKs simply to accommodate either a poor or non-thoroughly thought-out schema is tossing the baby with the bathwater, especially since the purpose of FKs is to reduce the ability of other tiers in the application from losing or otherwise corrupting the structured data storage.

3) FKs are useful when doing CRUD operations. They are not useful during schema changes. As such, the proper process in this case would be to temporarily remove FKs, perform the schema migration, and then re-institute the FKs. This may not always be possible, due to, eg, active business logic components or some such that can't allow the database to be taken offline to perform a migration (see point #2). In that instance, there are a number of other mitigations that can be put in place in the logic tiers, such as being able to recognize different schema revisions, and deploying that _prior_ to doing a schema change. As such, one would first migrate an active "smart" logic tier that can recognize different schema revisions, and allow for incremental migration of schemas without enacting a cluster-wide lock/disabling of reads/writes.

I disagree, and history does not show this to be true. We have been more fickle when it comes to instant messengers than almost any other technology on the face of the planet (pun intended). From IRC, ICQ, AIM, Facebook messages on the website (not Messenger), WhatsApp, Telegram. I count 6 major shifts in the last 19 years. This would indicate that the over/under lifespan of a messenger is roughly 3.5 years.

All it takes is a usable interface, general availability, and a reason to change. If WhatsApp starts doing content moderation, of any form on the client, I am of the strong opinion that users will find this to be "creepy" and will immediately start shifting. As it is, all of my technical contacts have already left WhatsApp for Telegram. Since that group/audience has been the bellwether for all of the previous instant messaging client shifts over the last 2 decades, I imagine it's only time before "everyone else" also shifts off WhatsApp. I don't necessarily think it will be Telegram, but they definitely have the most momentum today when compared to, eg, Line, Zalo, Viber, Kik, et al.

I appreciate your response, and will give you the benefit of doubt -- however this is in conflict with what a superficial reading of Schneiner's article suggests. Reading the reporting it would seems to indicate that this is happening/in process at Facebook.

While I cannot speak for the Forbes' author, Schneiner is widely reputed as a trustworthy source, especially on matters related to information security. This article calls into question his professional reputation as a information security journalist or yours as an executive at WhatsApp.

As such, in order to help the general community decide for themselves, please shed some light on the following:

1. Does Facebook/WhatsApp have any specific plans for moderating content, via any mechanism, on the client? If so, please enumerate the kind/type of client-based content moderation currently in discussion.

2. Has Facebook/WhatsApp previously looked at doing content moderation on the client? If so, please enumerate the kind/type of client-based content moderation that was previously discussed.

3. What will you do, if Facebook/WhatsApp decides to implement content moderation and/or a content "backdoor" on the client sometime in the next 3 years? Will you continue to work for Facebook/WhatsApp?

4. Should Facebook/WhatsApp decides to implement content moderation on the client, what forewarning will Facebook/WhatsApp give us. What will you personally give?

5. You say that this is easy to detect. Can you please provide technical guidance (or pointers to such) on how to go about detecting this, so that the community at large may better learn how to detect this in any instant messaging app, WhatsApp or otherwise?

I ask the above, in all sincerity, as Facebook's previous poor handling of data requires these kinds of inquiries -- especially when in opposition to reporting by Schneier, who's reputation as a information security journalist is bar-none.

Yes, I understand how this would be done. It's a design philosophy. If you'd like Gunk to support "oneof", we're open to Pull Requests!

Gunk is a frontend to protoc. If one needs to use "oneof", it's still possible to just define it in a .proto file. Gunk interoperates cleanly with both .proto and .gunk files.