How (if you saw that need) did you address permissions concerns, e.g., around any Git users being able to force drop all files from a backend?
Back (long time ago) when I was looking into this, there was no KISS, out-of-the-box way to manage the Git Annex operations a Git user would be allowed to perform. Gitolite (or whatever Git platform of choice) can address access control concerns for regular Git pushes, but there is no way to define policies on Git Annex operations (configuration, storage management).
Might not be super hard to create a Gitolite plugin to address these, but ultimately for my use-case it wasn’t worth the effort (I didn’t really need shared Git Annex repos). Do you tackle these concerns somehow? I guess if people don’t interact with your repositories via Git/SSH but only through some custom UI, you might deal with it there.
It’s been a couple of years since I’ve last used it, but if you want container orchestration with a relatively small footprint, maybe Hashicorp Nomad (perhaps in conjunction with Consul and Traefik) is still an option. These were all single binary tools. I did not personally run them on 2G mem VPSes, but it might still be worthwhile for you to take a look.
It looks like Nomad has a driver to run software via isolated fork/exec, as well, in addition to Docker containers.
Except that they can’t, because (due to the limitations of ASCII), U+0027 had an overloaded meaning, seeing that the character had to cover both opening and closing quotes (as well as being used as a prime tick). Which is why pretty much every font I’ve seen has a straight glyph at U+0027, whereas the glyph at U+2019 is the one you’d usually want for an apostrophe. You can also observe that word processors follow the Unicode standard in this regard. E.g., after typing “they're” into Libre Office, once you copy-paste it, you’ll see that the ASCII single quote has turned into U+2019.
> When text is set, U+2019 right single quotation mark is preferred as apostrophe, but only U+0027 is present on most keyboards. Software commonly offers a facility for automatically converting the U+0027 apostrophe to a contextually selected curly quotation glyph.
An interesting related project is the AdNW (http://www.adnw.de/) layout, which was created by defining metrics based on Dvorak’s ideas and running a genetic optimization algorithm on a corpus of German (50%) and English (50%) text.
The symbol layers were copied from the Neo2 layout, which afaik were arranged manually.
> You can't print anything because the language is lazy. Forcing any values to print them can and will result in random operations happening on your store. You can never know which values are safe to inspect. This kills debugging.
I don’t quite follow the conclusion. Forcing values will not result in random operations on the store. Forcing values can only ever create store derivations, which is an internal representation of all derivations that were encountered while evaluating some expression. I won’t ever mutate existing data or remove anything from the store, nor will it actually build anything or fetch cached packages, so forcing values should be unproblematic. Store derivations can later be garbage collected.
Since Nix packages are distribution-independent, once you have it packaged with Nix, you could theoretically skip packaging for Ubuntu etc., but of course that may raise the bar of entry for your users.
This is completely dependent on your location and the size of the company. E.g., when I recently looked into the stats for Germany, the average annual income for a developer in a small to medium-sized company is ~48k€ (~55k$), which is a long way from the 80k figure.
Self-signed will work just as well, since no MTA talking to you requires the cert to be trusted (maybe DANE is required now in that case, but I was also using self-signed before I set up DANE and peers would all use opportunistic encryption.
letsencrypt is a bit cumbersome if you want to support DANE, at least if you don’t run your own DNS or have an API to your provider’s DNS.
German users might also be interested in the AdNW layout (http://www.adnw.de/). They started out with Neo’s excellent and logical arrangement of the non-alphabetical layers, but replaced the alphabetic layers with a layout created by running an optimization algorithm on a text corpus of 50% English and 50% German text (whereas in Neo the key arrangement was created manually, based on intuition). The metrics they used were largely inspired by Dvorak’s research.
> hard not to wind up on spam lists almost impossible to be removed from
I’ve been running my own infrastructure for years now and know various people that do this also. Not once have I heard about anyone winding up on a blacklist. The only way I could imagine that happening is either a new server inheriting a legacy IP with bad reputation, or possibly running your server inside a home ISP network, which are frequently rejected by MTAs. Is there any other way in your opinion?
It might be prudent to have GnuPG return an error exit code instead of just printing a warning on stderr. Currently, it seems that clients (at least when using the shell interface) are supposed to parse the error stream. And even when they do (which many probably don’t), it’s not necessarily obvious that the presence of warnings indicates to the client that the data should not be used.
My question was aimed at ops generic statement. As for Make, it originally wasn’t clear to me where the issue was supposed to lie. Lines in rule bodies are handed off to the shell, and that whitespace in rule dependencies need escaping didn’t seem surprising since it’s a list (though it’s probably a bug that whitespace in target names must be escaped, since it’s just one token that ends in a colon). But I see now that the expansion of list-valued automatic variables is probably a real Make-endemic issue.
I don’t quite see how Unix tools have trouble with spaces in filenames. Could you detail some cases where the space handling is not due to the shell, as opposed to the program being invoked?
Back (long time ago) when I was looking into this, there was no KISS, out-of-the-box way to manage the Git Annex operations a Git user would be allowed to perform. Gitolite (or whatever Git platform of choice) can address access control concerns for regular Git pushes, but there is no way to define policies on Git Annex operations (configuration, storage management).
Might not be super hard to create a Gitolite plugin to address these, but ultimately for my use-case it wasn’t worth the effort (I didn’t really need shared Git Annex repos). Do you tackle these concerns somehow? I guess if people don’t interact with your repositories via Git/SSH but only through some custom UI, you might deal with it there.