This misfeature can show up in surprising places. Any use of assembly (`.s`) files in a Go program will by default add the executable-stack flag, as we discovered in CockroachDB: https://github.com/cockroachdb/cockroach/issues/37885
It's mainly for fun, but to find cases where it might be useful, think about symlinks into this filesystem. `ln -s /bashfs/somescript.sh /etc/hosts` and then your hosts file can be dynamically generated without any changes to programs that read it. It can be a clever way to sneak dynamic behavior into contexts where there would normally just be a static file.
Don't destroy it, embrace it. AMP is the low-javascript web many of us pine for. If browsers implemented AMP natively (and it were properly standardized), it would be great, and it has tons of potential for things like RSS readers. Google's heavy-handedness here has a lot of problems, but if they've managed to get publishers on board with a move away from the JS quagmire we should be pushing in the same direction and not fighting against it.
AMP still includes javascript that does many retarded things, including hiding the site contents until the JS is loaded, often from 3rd party CDNs. So if you're blocking the amp JS then the site just shows a blank screen, until some CSS animation trickery blends it in a few seconds later.
In other words if you use a content blocker AMP can be slower than the page would be without it.
AMP hides the entire page to avoid what is known as a Flash of Unstyled Content (FOUC). The document unhides as soon as a single AMP javascript resource loads, or an 8s timeout if that fails. That javascript is very cacheable and is often already in the browser cache to begin with.
embrace something else. It would be lovely if it was implemented natively, disentangled from google, and without google strongarming websites to their own implementation and CDN.
They didnt win publishers because of their wonderful implementation, they are literally blackmailing them with deranking if they don't (I suppose I could use a carrot analogy but i m more suspicious)
There is so much evil that can happen if AMP becomes the de facto walled garden of the web. I imagine if that happens, then we 'll end up needing google's review before websites can even be reachable. Or a government could order google to effectively shut down a bunch of sites instantly. The current version of amp is worthy of destruction before it grows to become indestructible
Quick question : my company uses a "devops as a service" partner. Basically we pay a monthly fee to have their guys on call 24/7 in case something starts to go wrong. Additionally they update and manage our kubernetes cluster, installing and setuping any dependency we require. From our point of view, we have a fully managed kubernetes cluster.
Financially, we pay AWS for EC2 instances and other expenses + them on top of that for consulting service, they have root access to the cluster. We do not have any devops/infra guy in the office.
Would they be allowed to install (and manage) CockroachDB on our cluster if we need to ?
I'm not a lawyer or in any way speaking for Cockroach Labs, but the Additional License Grant in their license looks to allow "contractors" to do that kind of thing. It's you or your lawyer's call as to whether you're safe in your scenario, but it seems to me that the answer is yes.
We decided to draw the line at whether the end user has direct control over table schemas. If users can specify the schema to be used, it's a database service and needs a license. If you're fitting everything into a generic schema (even if the user can specify things that look like new columns in the UI), it's an application and doesn't need a special license.
I'm surprised everyone is saying it's clear, because I think it's sort of vague, so maybe someone can talk me out of it. :)
If I build a service that lets customers define object types by dragging form widgets, and I turn that into a CRUD app backed by CockroachDB, and they just get to pick a CSS template and occasionally get Excel dumps, are they controlling the schema? They don't write any SQL, they certainly don't ever type or see the words CREATE TABLE, but internally I create a table for each of their types with a schema generated from their input, does that count?
Someone else asked about hiring a sysadmin consulting service. If I go to them and say, "Hey, my consulting firm will install and maintain your production servers, pay us $N/hour for routine changes and $kN/hour to page us," but they have their own developers who write code and can cobble together dev infra if needed, can they choose to use CockroachDB? In my reading of the license, they have the right to make it available to us as their contractor, but we don't have the right to download and install it and make it available to them for them (or us!) to run their CREATE TABLE statements on.
(I appreciate that edge cases are hard, and that while "just leave it open source" provides easy answers to these questions, it obviously brings other difficulties that you care about avoiding!)
Here's another one: if I run some website that's backed by Cockroach and has its own source code available publicly for pull requests (think Reddit until a few years ago, etc.), and one of my customer sends me a pull request that changes a schema in order to implement a feature they care about, does that count?
We at TimescaleDB spent a lot of time thinking about how to best express this dividing line in a manner concretely understandable by engineers. Glad to see others starting to take a similar approach.
As a startup founder and CTO who has had to deal with getting (or not getting) such licenses through legal, I really appreciate the clarity of definition here. Typically the language tends to be vague around "derivative works as a service" which conservative lawyers treat as a risk.
I think this is an argument for not giving root/superuser all possible permissions by default. It's OK that granting the `pg_execute_server_program` permission gives access to this feature, but it should still be something you have to opt in to, instead of making database superuser equivalent to the host user that the database runs as.
For comparison, in CockroachDB (disclosure: I'm a co-founder of Cockroach Labs), we don't have any features that let you execute server programs, but we do have something analogous to `pg_{read,write}_server_files` via the BACKUP, RESTORE, and IMPORT commands. In order to use these commands with a target on the server's filesystem, though, the database `admin` role isn't enough. The server also needs to be started with the `--external-io-dir` flag (and file operations will be limited to that directory). This gives an extra layer of opt-in before filesystem operations are allowed.
It's an argument for sure. But there's a significant maintenance cost to every security boundary you impose, especially when it's as counter-intuitive as "root may not do suchandsuch".
Was the problem not that no free OS supported color fonts properly? Emacs does not belong to the Monochrome Font Foundation, after all. Disabling a feature because it causes crashes is not ideological.
> Note, I don't believe it's necessary for _all_ transactions to be strictly serializable, but I would make the argument that all read-write transactions should be in order to prevent the anomaly in the article. In other circumstances it's reasonable to make the tradeoff and accept potentially stale data.
How exactly does the "free checking" example work?
Is it two transactions, where each transaction is responsible for checking the total balance across all accounts? Or is it three transactions, where a third read-only transaction verifies the sum of all accounts?
If it's two transactions, I think the anomaly as described is prevented even by non-strict serializability, because the additional reads force the transactions to conflict. If it's three transactions, then what we're really concerned with is the read-only transaction. What does it mean to mix some strictly-serializable transactions and non-strictly-serializable ones?
It is 3 transactions. Alice deposits money into her savings acount, then subsequently withdraws money from her checking account. In the meantime, some concurrent process transactionally reads the balances of both accounts.
Since there is no internal causality tying transactions 1 and 2 together, transaction 3 is allowed to arbitrarily order them without violating serializability.
I think the answer to your second question comes down to what anomalies you are trying to protect against. In order to prevent causal reverse, all read-write transactions must be strictly serializable, but it is safe to reorder read-only ones.
