My post was not disrespectful. It was matter of fact. And if the Petro Dollar only persists by use of force or perceived force, it's probably not a sustainable system for humanity. So hopefully we can go back to a soft power maintained Petro Dollar?
I disagree, "cloud" is extracting basic Linux functions into as many proprietary services as possible because businesses would rather deal with obscure YAML configurations than ever having to touch Linux-proper.
I'm sure the vast majority of businesses can handle ~10 min of scheduled downtime per week necessary to restart everything.
Now, database replication, not having to waste time to run/maintain clusters (be it Kubernetes or Elastic stack or something else), that I believe is well worth the money to offload to someone else, but even there you can get a much cheaper deal with someone that's not one of the three big cloud providers. I will also concede that Firebase is genuinely nicer to work with than its alternatives (Supabase very much included).
It's frequently simplifying things so that you don't have to worry about managing a server at all.
I run a PowerShell script once a day at noon, and I have no idea what kind of server it's running on, where in the world that server is, how much memory it has, or any other details. I get about a CPU, a dozen MB of memory, and a tiny amount of network capacity for about 5 seconds.
This is a very different experience from "We will rent you a VPS by the month".
That's like saying "Cars are a marketing term for internal combustion engines."
Clouds give you software-definable load balancers, networking, clustering, integrated systemwide security, and a boatload of managed services like message queues, databases, AI training and inference, etc. etc.
No-one sane implements all that using a collection of VPSes, because of a simple principle of business: it's more profitable to focus investment on your core competencies, and for almost all companies, managing a non-trivial computing infrastructure is decidedly not a core competency.
Literally anywhere else! Your dotfiles should be publishable to github. If they aren't you're doing them wrong.
A good thing to do is organize. You can actually load different files. Here's a pretty common pattern that you'll find and it'll illustrate how to do other things
if [[ $(uname) == "Darwin" ]]; then
source "${INSERT_SOME_DIR}/osx.zsh"
elif [[ $(uname) == "Linux" ]]; then
source "${INSERT_SOME_DIR}/linux.zsh"
fi
You do this for loading based on the operating system. You might want some aliases, commands, or other routines in one but not the other. For example, in my linux one I have stuff for cuda paths. You can do all sorts of things too, like make a (generically named) work file, which you don't publish to github but you load it if it exists. Then you can put all your work related aliases there and not contaminate anything else. Something like `[[ -a ${INSERT_SOME_DIR}/work.zsh ]] && source ${INSERT_SOME_DIR}/work.zsh`.
You shouldn't really load secure keys this way, but others had good answers so I thought I'd at least share a more general pattern since it isn't as well known among the less terminally inclined.
Okay. Here is a pattern i follow everywhere in my init files for almost every program.
Define two key env vars.
$DOTFILES and $ECORP.
The first is path to your personal set of dotfiles. The second is path to your corporate specific dotfiles.
On personal pc no need to define the $ECORP var in shell init. On work pc define that var.
based alone on that you can conditionally do almost anything.
- shell source files/aliases
- vim/editors enable disable plugins based on existence of env vars.
- define shortcuts in file manager.
- and i add the following to my main $DOTFILES .gitignore.
# Any file that contains the following will be ignored.
# Used to ignore files in corporate environment
*ECORP*
*ecorp*
Based on multiple years across different setups, using environment variables was the most reliable option since I have been in places where there are restrictions on where my init files can be placed and having to change a shit ton of paths in my dotfiles or just keeping a different branch for work and personal (and making sure they stay in sync) was too much of a hassle.
Additionally, maintaining hygiene is essential, where I only use a Read Only PAT token on my personal dotfiles in workenv. That way, there is no accidental way I would be able to push from my workenv.
You’re just splitting your dotfiles into a public and a private part. That’s useful if you want to publish the public part on GitHub, but not everyone wants to do this, and the issue of storing secrets in plain text files remain.
> the issue of storing secrets in plain text files remain.
Ummm... kinda? The problem was that reading an rc file was considered dangerous. Not putting keys in your rc files is an improvement. Encrypting them is even better than that. But I also said more words in the original post and you don't really even need to read between the lines to figure out I said "you can generalize this", especially when there's comments next to it saying "here's how you load an encrypted file"
Anywhere else? Password managers have CLIs, operating systems have their own secure storage, and lots of command line apps can store secrets in the OS's secure storage (Windows Credential Store, Secrets Service or KWallet on Linux, macOS Keyring).
Project-specific secrets can be stored locally via something like SOPS or remotely with something like Hashicorp Vault or AWS SecretsManager.
Applications that have secrets to manage (e.g., Emacs) or are partly about secrets management (e.g., GnuPG, OpenSSH) all store their secrets somewhere else and have secure (not plaintext, sometimes not even on disk) storage options available.
There's no reason to store secrets in plain text in your shell configuration. Practically any choice you can think of is a better one. Even if you did, there's no reason you couldn't store them in a more specific file that ~/.zshrc sources, and let LLM agents read zshrc but block access to the file containing your secrets. (I wouldn't rely on permissions prompts for this, though, lol.)
The AES encrypted file has some, plus a bunch of exported env vars. I do keep one function in my ~/.bashrc to make it simpler to invoke so I can do `source-secret ~/.secrets.aes`:
source-secret()
{
if [ -z "$1" ]; then
echo "Need filename to source"
elif ! [ -f "$1" ]; then
echo "File '$1' does not exist"
elif ! which aescrypt >/dev/null 2>&1; then
echo "Could not find required dependency 'aescrypt'"
else
. <(aescrypt -d -o - "$1")
fi
}
Another more secure pattern: have different shell profiles that just go dynamically inject secrets from a secrets manager. Nix is a good tool for this. You have various shell profiles configurations that call your password manager cli at bootstrap (eg new terminal tab). You auth and at bootstrap of the terminal time the secret is dynamically fetched from the password manager and injected into an env var. this has advantage over other approaches mentioned here in that the secret is never stored at rest on the end user’s machine only used in flight
Just curious, any reason to prefer using age (you mentioned that you would prefer it if starting over), over something like keepass? I am currently using keepass-cli and only reason i did not use age even though i found it was that it was new to me and I never heard of it (probably not the best reason, but in this era might be a reasonable thing to stick to devil you know). So curious about your take on this.
An array of arrays is an extremely inefficient and error-prone way to represent multidimensional arrays.
If I want a 1000x1000 array, representing it physically as a single 1000000-element array requires one allocation, and processing it element-by-element (assuming it's stored in the same order we're iterating over it) is sequential in memory and therefore very efficient.
Representing it as 1000 separate 1000-element arrays requires 1000 allocations, and pointer-chasing every time we move from one row to the next.
Isn't an array of arrays by definition the sequential implementation?
Otherwise you would have an array of pointers to arrays. The usage (syntax) for them would be the same but the performance would not be.
They also have different uses. You would expect an array of arrays to be an array of arrays which share the same length. For an array of pointers to an array you would expect dynamic length arrays contained within the original array.
Even in c++ could you not just define some int [1000][1000]foo? I've never really used C++ but my C knowledge assumption is that is 1000000 continuous elements.
I does not work fine in C++ when N and M are not compile-time constants, which is basically always the case in any interesting numerical algorithm. Also not in Rust.
It works fine in C though, or FORTRAN, or Ada, or ALGOL 60, ...
Why is that?
I find Ada much nicer than the C-languages when it comes to arrays: A'Range, A'Length, A'First, and A'Last are super-useful, as is the unconstrained array.
You can even use unconstrained arrays to provide the same functionality that Optional does in functional-programming, provided the element-type can be an element of an array:
-- Here we define an index-type with one value.
Subtype Boolean_Index is Boolean range True..True;
-- And here we define an array indexed by it, but can also have length 0.
Type Optional(Boolean_Index range <>) of Element;
And there you have the mechanism for Optional; just use "For Object of Optional_Array Loop" to enclose your operations and bam, it works perfectly.
I guess you aren't their target customer anyway, NVidia isn't that found of pure C code, with first class tooling for C, C++, Fortran, Python JIT, Ada and most recently Rust.
The std:mdspan proposal came from NVidia employees, alongside AMD and HPC research labs.
The thing is that I rewrite high performance numerical code on GPUs and the CUDA part is what sucks most. And the moment one uses templates, the compilation times make it insufferable. I really do not understand why people put up with this garbage. I am really looking forward to the day where I can remove CUDA from my projects and replace it with compiler-supported offloading is really
The kernel removed VLAs, I am more talking about vm types. But even for VLA - while I had a small role in that undertaking myself - I think it was a stupid mistake from a security point of view to remove VLAs from the kernel. Google pays for a lot of nonsense...
Nope. The C++ memory models is designed around no hidden/non-deterministic memory allocation.
If you try to allocate 10MB on the stack, that's the dev problem if the program fails, it's not the compiler job to guesstimate whether something will fit there or not (and it's impossible anyway, the compiler can't know all the stack sizes a program will ever run on).
You might have an investment management firm that has a "tech" portfolio and a separate "clothing" portfolio. By framing themselves as a tech company they'll be put into investors' "tech" portfolio. Clients will say "I think technology is the future; invest in tech companies for me" and the money manager will buy a bunch of shares from the tech portfolio. See how it works?
reply