knz42

As explained in another comment below, it's a good thing when all the byte usage is represented in the ELF section headers or the symbol tables.

The DWARF data is currently so represented, and so was pclntab prior to 1.16.

Today, the DWARF data is still present; the symbol for pclntab has an advertized size of zero, and the amount of data not represented in the symbol table and ELF section headers has grown.

> If the 73% of the binary diagnosed as “not useful” were really not useful, a reasonable demonstration would be to delete it from the binary and see the binary still run. It clearly would not.

Probably not if all of it was removed at once.

It could be that just 5% of it is useful and removing all of it would produce a non-working binary. What does the experiment prove exactly?

Look you can claim that "having the necessary metadata for garbage collection and reflection in a statically-compiled language takes up a significant amount of space" but without clear evidence of how much space that is, with proper accounting of byte usage, this claim is non-falsifiable and thus of doubtful value.

How does this compare to https://onlysponsors.dev/ ?

HN discussion here: https://news.ycombinator.com/item?id=25882021

They can't require things that have a direct impact on the employee's private life, so contraceptives and anti-psychotic drugs are out.

They can't require things that have unknown medical impact, so random pills out.

(However, some food items can be mandatory. For example if you're a sporter, you can be required by your employer to take certain supplements.)

You're mis-reading the text.

The reduction in cost pertains to the try/catch (defer/recover) mechanism, not error returns.

The cost of error returns has not reduced since Go 1.10.

This was clarified in the conf talk [1] [2]: error returns should be used at API boundaries, and panic-driven handling only "within" a component.

[1] https://www.youtube.com/watch?v=inrqE0Grgk0&t=15126s

[2] https://docs.google.com/presentation/d/1WVu4O-ax7punUC2V_XgT...

FYI these results were presented at the Go Systems Conf SF last December: https://www.youtube.com/watch?v=inrqE0Grgk0&t=15126s

Absolutely yes.

And yet it certainly is there.

> that the actual performance cost for checking the error return is random, variable, and small. Good to know :)

That is certainly not the article's conclusion. The cost is deterministic, constant and non-negligible.

The report says that AWS's ARM-based Graviton2 cores were tested. Where can we find the download link for the CockroachDB release that was used to test on ARM?

You need to integrate transaction coordination with replication to ensure that the replication respects transaction atomicity (so that cross-shard queries get all their reads and writes isolated from each other, and rolled back atomically when a txn is aborted).

So separating the layers like you do is only possible if there is an XA protocol between the layers. Neither K8s nor Ceph support that.

I wasn't sure. Thanks for checking. three years is a negligible amount of time.

> How compatible?

That is literally explained in more than 40% of the article.

BSL is "delayed free software". Take the code, wait 3 years, then it's entirely free software.

This article reads odd to me. It seems to me that serious players do not compromise on these things at all.

For example, CockroachDB (https://www.cockroachlabs.com/) aims to support extremely large databases in a distributed fashion, and does not compromise on any of the points the author raises.

For folk who prefer a video to text, I found the following high level explanation on Youtube: https://www.youtube.com/watch?v=wdv8uvDhbcQ

The technology is open source though. (Its BSL license automatically switches to APL after a year or two.)

> It seems like an argument against all kinds of transactions that are linked to irreversible side effects, regardless of whether any are nested.

Correct. The best design is small transactions without side effects. The problem with the existence of nested transactions is that they encourage large transactions across multiple components, where it's too easy to sneak some side effects in.

> I would love to know what the author (or others) think the better alternative is.

Small transactions with a retry loop using exponential back-off and, depending on application requirements, a max latency deadline with fallback/error.

> > Additionally, nested transactions can amplify performance anomalies.

> Is this not a CockroachDB-specific performance limitation

Nested transactions encourage cross-component, and thus long-lived transactions. Long-lived txns holding locks cause performance problems in every SQL engine, not just crdb.

Author here - yes there are schemes to do it client-side. However there is enough legacy code and frameworks out there that use nested transactions via pg's savepoint protocol, that some compatibility with those is warranted.

They do - sometimes.

What is the story behind the removal of VLAs from C99 in later revisions?

If that's the problem you're trying to solve, make a "CoC for folk under 18" and let that be the end of it.

> CockroachDB annoyingly requires manual certificate creation and distribution to each node, and if you don't set those up then you can't use any authorization at all. It's strange and user-hostile to disable auth completely just because you don't use certs.

This comment is not any more true as of CockroachDB 20.1 (Upcoming in Q2 2020).

This version will enable you to set up your own transport-level security with clients using password authentication to crdb.

Hello bithavoc, I happen to be currently working on that area of CockroachDB and I would like to help.

To start with, any scenario that you find where a secure deployment without an Enterprise license makes you unable to operate your apps using the core features, would be a serious bug on our side and we'd give it high priority. There is no intent to do bait-and-switch here.

If I read between your lines I can see the following:

- you need an admin user to create databases;

- the only admin user is root;

- it appears that you cannot log in with root on a secure cluster (TLS enabled). Is that understanding correct?

I think I understand the following: your SQL client is attempting to connect using TLS but without presenting the root client cert to the server. The root client cert is a cert that you can generate using the cluster's CA key (using the `cockroach cert` command). Without a valid client cert, the connection is refused.

You may think this seems to work for other users than root. This is because for other users, when cert validation fails, the server allows the client to use a password instead. This choice to use a password is not available for the root user up to and including 19.2.

Here is your way forward:

- either you configure your SQL client that creates database to present the root client cert to the server. This will enable you to use the root account on a secure server and create databases (and other users, and then assign privileges to these users over the new database).

- or, you wait until crdb 20.1, where it will be possible to configure a password for the root user and let root clients use password authentication instead of presenting client TLS certs.

Does this help?

If it doesn't please create an issue on github and describe your situation in more details and cc me (@knz). Thank you

I'm the author of the article linked in this entry and https://science.raphael.poss.name/go-calling-convention-x86-..., and this is IMHO the best comment in this thread.

No you cannot strip away pclntab, it is necessary to implement the (mandatory, often used) runtime.Callers API.

The C library supports unicode too nowadays (at least the GNU C library does) yet linking a simple program that uses printf does not import 300KB of code.

The answer comes from the reflection code as the other commenter states.

Just accumulating knowledge says nothing about what programmers actually can do on the workplace.

this is a better matrix: https://science.raphael.poss.name/programming-levels.html

It's 20% of one person. One single flight spews many car-years worth of greenhouse gases.