171–180 of 196 posts
Earlier quoted context omitted.
No, it uses native Nix directly on your machine - Linux, Mac, or Windows. Its integration with Docker is that it can _build_ Docker images from the Nix packages in your "devbox".
I'm assuming for windows it only works in WSL2? cause last time I checked nix wasn't compatible with native windows development, sadly
Wsl/nix should work.
Earlier quoted context omitted.
What I really want is a tool like docker compose that builds on top of a tool like this (instead of docker)
Assuming you want the service management aspect of docker compose look at user-mode process supervisors like supervisord. You can install it in your nix environment and config all the dependent services it should manage. It's a little more crufty vs. the simplicity of docker compose but it also has a lot more power and flexibility. There are tons of other options to explore too like systemd user services or skarnet's…
Earlier quoted context omitted.
As far as I can tell it is: 05:10:27 $ nix --version nix (Nix) 2.6.0 I installed it with `apt install nix-bin` on Ubuntu 22.04. EDIT: I installed Nix with the old-fashioned "pipe shit to bash" method and it seems to work now. When I say "work", I mean it in the sense of "doesn't fail", because it's been stuck at `devbox shell` for a good five minutes now with no indication. Not to be too negative, I think this is a g…
The package you want on Debian is called nix-systemd-setup or something like that, not nix-bin. (nix-bin just gives you the Nix binary, and I guess if you created /nix yourself you could use it for a single-user install.) The expectation is that you want a multiuser install, which requires a running daemon and the creation of some system users, and the nix setup package handles that. I think the package descriptions…
Earlier quoted context omitted.
The package you want on Debian is called nix-systemd-setup or something like that, not nix-bin. (nix-bin just gives you the Nix binary, and I guess if you created /nix yourself you could use it for a single-user install.) The expectation is that you want a multiuser install, which requires a running daemon and the creation of some system users, and the nix setup package handles that. I think the package descriptions…
It would be great if devbox displayed the recommended command to install Nix upon first run. First users of devbox shouldn't be expected to know the details on how Debian packages Nix.
> For the best experience, we recommend installing Nix via the official installer, i.e., via this one-liner:
> > curl | bash, blah blah blah
> (Existing Nix users who have or prefer an alternative setup can still use devbox! See this page about compatibility: [link to a 1/2 page reference doc]
(Happily, the experimental features now experiencing widespread uptake in the community will make some of those differences I outlined less relevant.)
Earlier quoted context omitted.
agree: I compiled a list of supporting facts and dissenting opinions here https://dx.tips/the-end-of-localhost this is of course extremely hated on HN, which understandably loves independence and self reliance.
Speaking as a person who does have a strong gut reaction against cloud development, I think a lot of the justifications like 'what if I'm on a train' do mask a real desire to say it just feels bad . Public reason. Is it logically consistent with other things I don't own? Like Chrome, within which all my apps run? No. But is there something that feels right about having all my code running on the CPU on my lap? Unacco…
still, your feelings matter. imo, totally welcome to them.
some people also like keeping gold in their safes, cash under their mattress, running on their own power and food off grid. i will fight for their right to do that.
but also i observe that most people have a demonstrated tendency towards centralization for convenience, and the technology is coming along for mass availability of this tech.
Earlier quoted context omitted.
https://nix.dev/tutorials/building-and-running-docker-images... asserts that you'd need a remote builder or cross-compiling. So it seems possible (unless maybe there are still enough cross-compile issues?)
Can cross builds hit the main binary caches or is that awaiting Hydra support for content-addressed derivations? Are there big caches for cross-compiled packages?
Earlier quoted context omitted.
I have been avoiding nix for a while since I had a bad time with it several years ago, however recently used it for a small Haskell/Latex environment for literal programming and found it worked really well. I’m probably going to invest time into learning it now, as the online docs seem to have gotten better.
It sounds like the improved docs have made a difference already, and that's great to hear. Could you name anything else that you think made your more recent experience so much better than your prior one?
Having a deterministic environment, but that is actually running on your laptop is so much better than working inside a docker container. Inside a container the file system is very slow, and you lose all of your other tools and shell aliases.
Earlier quoted context omitted.
> Dictating to people how their workflow should look - _that_ is the antipattern. Developers should choose their OS, their editor, and virtually everything about their workflow. I'm not convinced it is. Back in the day, each developer had their workstation (not laptop) configured just so , with their own pile of `doit.sh` scripts to tickle the system in just the right way, to get things to compile and render and send…
Have you tried neovim? You can have pretty close to feature parity with VSCode due to it's LSP support; for most languages, you'll be using the exact same Intellisense engine (LSP server) as VSCode. (Python is the exception I'm aware of, but python-lsp-server is serviceable even if Pylance, the proprietary VSCode one, is better). And when the internal tooling team ships a new version of the LSP server, you'll be able…