I'm currently using direnv + 1password + https://github.com/tmatilai/direnv-1password. `direnv` to load shell environment dynamically upon entering a directory. It can load static .env files, but can also source shell scripts to load envvars.
1password is the company password manager. It has shared 'vaults' where a team can share secrets with one another. They can thus be used for authorization, who can access which secrets.
direnv-1password is a plugin for direnv that will load secrets from 1password into envvars. With this, upon entering a project, you'll be asked to unlock 1password (using yubi or fingerprint scan) and it'll fetch the needed secrets from the project.
This way secrets secrets are not easily readable from your disk, like they would with .env files.
Other password managers likely have similar tooling for direnv. Though I don't know whether it'll be this convenient.
Most services are connected through SSO, so those won't have passwords and are automatically shut down when the user leaves the company.
All employees also have a 1password account for which we can store individual passwords for the services that are not connected through SSO.
For some services we only have a single token/service account which we need to share within the team. Often they were stored in a `.env` file, but that tend to be a burden for onboarding and quite a bit of maintenance for each individual.
Within my current team we share them using direnv and https://github.com/tmatilai/direnv-1password. Secrets are loaded as environment variables whenever the dev enters the projects directory. They are loaded from 1password which is unlocked using fingerprint scanner. This way the secrets are not actually stored on disk.
People leaving the team does still require manual password rotation, but at least not everyone in the team needs to update their `.env` file this way.
Thanks for this comment. I currently use direnv with great success for managing virtual environments (mostly various language versions, dependencies, and environment variables). I'll look into this approach of pulling in credentials for those environments from a password store.
I think direnv is a highly underrated tool. Switching between environments with a simple 'cd' is of huge benefit to my development experience.
True, but you can represent that in the db as a a CLI invocation to run in a subshell.
The big gain from something like carapace or my theoretical SQLite-based completion system is faster startup time. I had to remove zsh-completions from my shell setup as it added too much to the startup time (https://github.com/bbkane/dotfiles/blob/master/zsh/README_no...)
For many phones it is possible to change the exposed protocol from mtp to mass storage. Mass storage does need an image file with fat filesystem to work on most devices. It nowadays is not possible to expose the phones internal storage.
I've worked on DriveDroid. There were indeed people who have done this.
Best example of such a use-case was someone who wanted to make an old printing press fetch files its files from the internet. The press only had an interface for floppy disks. He replaced the floppy disk controller with a floppy emulator that exposed an USB port. Connected a phone with DriveDroid. Synced usb image files from the internet to be exposed over usb mass storage. The image files were fat images that hold the printing job files. They were generated by the server automatically. It worked pretty well from what I heard.
Personally, I think because its feature-set is currently very much "scattered".
Nix is in the transition to use 'flakes': a new concept that gives a bit more structure and allows easier reuse of Nix packages, NixOS modules and more. In addition it includes a standardized 'lock' file. Lock files are quite useful (or even essential) for reproducibility.
However, it is in experimental phase for more than 4 years now. It is behind a configuration flag, so it isn't obvious how to use it. A division in community, projects and documentation happens this way.
Because it is still considered an experimental feature, flakes and its surrounding CLI tools aren't mentioned in the official docs.
Even though it is experimental, flakes is considered an essential part of Nix by a large portion of the community.
This makes those people look for and create their own solutions:
It makes sense that these are created. I'm still hoping Nix flakes will become the default and UX can be iterated upon. But it doesn't make the future of Nix all bright and beautiful atm.
> It is behind a configuration flag, so it isn't obvious how to use it.
It is: the error message tells you exactly how to activate it.
> A division in community, projects and documentation happens this way.
No, not really. flakes are not fundamentally different, they just replace channels, a very small component, with something new and more powerful.
You can convert any NixOS config in minutes if you just import the configuration.nix, add --impure and add a nixpkgs input.
> its surrounding CLI tools aren't mentioned in the official docs.
> This makes those people look for and create their own solutions:
Also not entirely true. Before flakes there where several projects like niv which are now more and more in maintenance mode and got replaced by flakes.
There was a need for a feature like flakes in the community for a long time and it it slowly forming shape.
> This results in multiple documentation sites:
Yes, like for any other big ecosystem. There will grow community maintained wiki's, opinionated websites, guides and resources. Is that necessarily a bad thing? We can't prevent people from creating them and not everything fits into the official guide especially if it is opinionated.
> Multiple wrapping tools for development environments:
Same thing. nix-shell is pretty basic and does not have every bell and whistle and people in the community build on top of that, create wrappers and new tools and try to build the bells and whistles. Similar things for example happened in the debian community with for example aptitude and synaptics.
> I'm still hoping Nix flakes will become the default
It will and the tools you listed above won't go away. Flakes do not attempt to replace them and what they try to achieve but to support them.
Can you elaborate? I always thought deterministic builds would enable faster builds (because it would basically allow for downloading and verification of binaries).
As an example, gcc includes code generators that try a few random things in order to optimize code. So two builds, on the same system, won't result in the same byte code.
Nix already does binary substitution. It just has the assumption baked in that builds don't do anything nondeterministic (and the Nix build sandbox removes a lot, but not all, of those opportunities; the ones remaining are things like threads, hence the slowdown).
I don't know how NetBSD handles this, but for any provider that doesn't allow you to use custom ISO's or ipxe, you can use [nixos-in-place](https://github.com/jeaye/nixos-in-place). I've used it before. It isn't ideal, but it gets the job done.
1password is the company password manager. It has shared 'vaults' where a team can share secrets with one another. They can thus be used for authorization, who can access which secrets.
direnv-1password is a plugin for direnv that will load secrets from 1password into envvars. With this, upon entering a project, you'll be asked to unlock 1password (using yubi or fingerprint scan) and it'll fetch the needed secrets from the project.
This way secrets secrets are not easily readable from your disk, like they would with .env files.
Other password managers likely have similar tooling for direnv. Though I don't know whether it'll be this convenient.