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.

lowmagnet more or gave a succinct summary. I've also now added other comments here, discussing my views. I don't believe it's necessary, and I would proscribe other ways to accomplish the same design. It's a philosophy of API design, not some kind of absolute stricture.

I feel very strongly that type safety is of paramount importance in development, and "oneof" (and other similar constructs) in protocol design breaks fundamental ideas of type safety. It's a feature of the IDL that doesn't translate well to the actual implementing language, is not strictly necessary as the same thing can be accomplished through other designs that have an added benefit of being more explicit, both to the implementer and to the consumer.

In proto3 all fields are optional. As such, I don't see the need for "oneof" since you should check in business logic whether or not the field is there. By using "oneof" you are declaring two different types can be the same name. It's a philosophical argument that you're free to disagree with.

I haven't specifically looked at the Kubernetes code base, but I will -- thanks for the pointer! We plan to expand / support / better standardize the annotations in the github.com/gunk/opt package in time.

Yes, this has the added benefit of standardizing protocol buffer based workflows across teams / repositories. I appreciate the criticism, but we (the Brankas developers) find this syntax significantly easier to use, as well as the tooling provides a better mechanism for using other protoc generators.

There is an explanation in the README file, but I'll explain:

It helps to standardize workflows across a number of different source repositories (all Go based), where a number of different developers had come up with different ad-hoc ways of generating code against protobuf definitions. Since the syntax is Go-derived, it reduces cognitive load for developers when specifying protocol buffer definitions. We understand that it may not be for everyone, but it works for our team.

Thanks for the input -- this actually does support enums, using a variant of Go's const:

    type MyEnum int

    const (
        MYENUMVAL MyEnum = iota
    )

We just pushed the first initial, public release of Gunk, a modern frontend and syntax for Protocol Buffers.

Check out releases here: https://github.com/gunk/gunk/releases/tag/v0.1.0

Please note this is still extremely early / alpha stage, but we are soliciting feedback on our initial design. We hope to make this project useful to the greater developer community.

Yes, it reads from STDIN. If it doesn't, it's a bug, and please file an issue on GitHub.

This is a syntax highlighting issue, most likely. The \ commands are not highlighted. Are you using a white or light colored background? Likely the contrast isn't high enough. I just updated the documentation with more information on controlling syntax highlighting.

You can either try disabling syntax highlighting completely ( \set SYNTAX_HL false ) or change the Chroma style used ( \set SYNTAX_HL_STYLE paraiso-light )

See this page: https://xyproto.github.io/splash/docs/all.html for an example of what the various Chroma styles should look like.

I think they're saying "SEQUEL", which is the widely accepted/recognized pronounced mononym for "SQL".

Yes and no. ODBC on Windows may (or may not) be provided by the Microsoft JET driver, which can be considered a database unto itself. Specifically, there is a separate ODBC driver for Go that usql supports, which is what this is reflective of. I actually edited the above after posting to remove a double entry for PostgreSQL and MySQL, as there are two different Go drivers for each of those databases (4 in total) that are well supported by the community.

As what amjith said -- however, I personally find myself working with upwards of 3+ different databases in a single day. I may not be the use case, but eventually I realized it would have been easier to write a single, consistent client that works across all databases the same, as opposed to learning yet another broken, random client.

Since usql is written in Go, it compiles to a single static executable, and as such you don't need any extra dependencies. {pg,my,db}cli requires pip + python, which is usually broken on many systems that I've been an admin on. Also, good luck getting pip working properly on Windows. Also, since its written in Go, its likely significantly faster.

It's more of a passionate side project at the moment, as I am still reverse engineering the protocols involved. It's not close to completion, but I'm hoping to have it done sometime in the next few months. It's not a high priority, as there are other ways to connect to Oracle.

My goal is to get rid of all the non-Go dependencies, which would (for the first time, ever) finally make it a reality to have a single, small binary that can connect to "every" database and that can be freely distributed. If you'd like to help, please feel free to start an implementation. While I'm not following a specific development routine for the native Oracle driver, I do have a repository with a bunch of (non-building) code that I made to assist with inspecting the raw protocol captures.

Yes, I've been working on a 100% native Go driver for Oracle. It is not even alpha or beta quality at this time.

Just released the latest version of usql, which fixes issues with syntax highlighting, adds initial support for Cassandra databases via CQL, among other changes.

If you've not seen usql before, it's a universal command-line client for SQL databases (and now also Cassandra), modeled on psql. usql makes it easy to work from the command-line, in a simple and consistent way across any database and on any platform (Windows, macOS, Linux). usql is written in Go, and provides things like syntax highlighting and compatibility with databases other than PostgreSQL (see below for the list of the supported databases).

Progress is moving at a decent clip towards a v1.0, which I expect to include 100% native Go support for Oracle databases, tab-completion, full compatibility with psql's \pset (and other output formatting) commands.

usql supports the following databases:

    Microsoft SQL Server
    MySQL
    PostgreSQL
    SQLite3
    Oracle
    Apache Avatica
    Cassandra
    ClickHouse
    Couchbase
    Cznic QL
    Firebird SQL
    Microsoft ADODB (Windows only)
    ODBC
    Presto
    SAP HANA
    VoltDB

Same command syntax as psql, so no need to learn a new tool. A single command line client that works with every database, so there's no need to have multiple binaries installed. It's a single static binary, so it can be copied and used from anywhere -- no need for endless pip dependencies.

Yes it's had syntax highlighting for about 2 months now. I haven't finished the 0.6.0 release, but if you install from source you can use it from there.

Please try usql:

    go get -u -tags oracle github.com/xo/usql