Dev onboarding, then and now
blog.fahhem.com
blog.fahhem.com
You just added the overhead of running another whole computer in your computer to solve it.
Also the author states he is locked into using VS Code, which seems like a risky dependency to have.
I can ship the VM to a thousand people. I can't do the same with my machine.
In my experience, VM centric deployment processes lead to extremely brittle programs.
But I mean, ye, if you got a brittle mess, you better use VMs for deployment. I am not against using that method, as long as I gotta admit I've made a mess.
Even if you use hard locked versions of deps there is a whole multiverse of problems you can encounter when compared to having everything ready to go that is identical to your expectations.
The program is being made less brittle because it is tested in different environments and the practical max amount of dependencies are lower than shipping a custom distro for your program.
I am not arguing that for a given program, it is less likely to execute properly in a shipped and tested VM image, than on a Sparc workstation running Solaris.
> The program is being made less brittle because it is tested in different environments and the practical max amount of dependencies are lower than shipping a custom distro for your program.
If we're talking about web (which is my assumption since images don't make a lot of sense otherwise) there is exactly 0 benefits to testing apps in different environments since they're only going to be deployed in one, right? And either way if that changes you can specifically test for any other envs you want to run your app in, and not let your developers take that pain onto them by fighting deps/configurations along the way.
Either way it's painfully obvious why one is better than the other.
It's not 100% perfect for managing exact versions because you update nixpkgs and many packages update as a result, but you can pretty easily pin multiple versions of it or override the version for a specific package
It's not that. It's replacing "it works on my machine and I'm not sure why it doesn't on yours" with "follow these exact steps and it will work on your machine too".
It's perfectly reasonable to use containers to solve dependency management. But it's a really bad form to have containers as the only viable way to distribute your software, and a very reliable indicator that your software won't work at all.
I can run a VM on both my machine and yours.
> You just added the overhead of running another whole computer in your computer to solve it.
A VM hasn't had the overhead of running a full computer in a long time. Depending on your platform, containers (or hyper-V) are near-native performance. And let's be real, when your dev environment is spending 45 minutes running eslint, a 1-2% overhead isn't going to make or break you.
> Also the author states he is locked into using VS Code, which seems like a risky dependency to have.
Lockin isn't a binary bad thing. Flexibility isn't free. Supporting every possible workflow in every possible environment ends up with catering lowest common denominator, which sucks. If VSCode dies, I'll move onto a replacement, just like I did when we (thankfully) decided eclipse was to go to the farm.
Yeah? And? Containers are an easy way of solving the problem of getting a known configuration for everything from the OS on up. You are wasting time and money not taking advantage of that.
> Also the author states he is locked into using VS Code,
You're a professional. Use what your coworkers are using (75% of professional devs are using Visual Studio Code). If you have Vim muscle memory, that can be accommodated quite well with extensions. Otherwise, just fucking switch already, you'll save yourself time and pain.
But the justification gets muddled. In fact there is no VM in docker and no "another whole computer". Containers are lightweight and great. Even if you have a correctly-engineered bullet-proof hermetic build solution for your bitwise reproducible artifacts... you almost certainly want to implement that using container technology of some form.
Use Docker. It's great. Do the hard work too, sure. But start with an ad hoc Dockerfile.
There is as soon as you run containers on a different OS (IOW as soon as it's not Linux containers on Linux or Windows containers on Windows)
That said, this was not a particular jab at your comment, more like a clarification for readers, as a lot of people are somehow under the belief that Docker for Mac involves no VM (the other belief being that containers themselves are somehow lightweight VMs)
It’s been… ok. Devcontianers are a great idea, but the implementation is rough around the edges at times. There is a complex story around making sure your dependencies are appropriately synced. If you want any test reliability, you need to rebuild the container in CI/CD before running tests, which isn’t impossibly complex but isn’t out of the box and can require additional work and really thinking through things at times. While the deduplicated dockerfile multi-stage flow of dev -> test -> prod images works, I’ve found it to take a nontrivial amount of work and background to get this up and running.
There also is the git integration, which is functional but flaky. First, you have to use VSC’s terminal rather than your console. Which I have found is not an issue for junior devs that just do what they’re told, but the crusty seniors who are used to it not mattering which terminal you use seem to find a lot of headache here.
It will occasionally randomly not find the ssh keys git needs and fail to authenticate, and the only fix I’ve found is to open a new terminal outside of VSC and git push (or any other remote authenticated operation), which somehow reenables VSC’s SSH compatibility. Which of course may also fail if you have pre-commits in place that rely on the dev container env having pre-commit installed.
There is also a bit of complexity around bind mounts in general, I can’t recall specifics but we have had some compatibility issues related to this that are difficult lot debug, as there is some magic that VSC seems to do behind the scenes that you can’t replicate outside of VSC. We also had some issues multi-architecture targeting that was made more complex by this setup.
Overall, devcontianers are fine and they will work in most cases, but they are not panacea. They basically take all of the distributed frustration of each user’s individual setup and consolidate that frustration and headache onto your tech/devops lead etc. This is, of course, by design. Solve it once, for everyone. But you don’t magically have less edge cases. And of course the dev and CI/CD setup becomes entirely magic to anyone not involved in configuring it in detail. So when issues pop up, I’ve found devs to be less able to unblock themselves without getting the lead involved.
I do. I no longer need to pollute my machine with thousands of crappy dev packages that I need only to compile next special snowflake.
If the system is deployed on Linux then you run Linux in a VM. (Which also deals with some of the other issues) I have done that since the early 2000 or even before we remotely logged in to a machine running the correct OS (X Windows is useful) albeit I was on site so a fast connection to the server.
Now whether it is good design to make assumptions that only Linux matters is another question. I am old enough that I had to use multiple Unix systems SunOS Solaris NeXTStep and Linux. And good practice was to compile C++ with two different compilers as the error messages and edge cases were not very edge.
If you mean just use Linux then not possible. You need MS Excel for any financial work - the alternatives are just not complete enough, Mail also (well used to) needs the OS. And I suspect most people prefer the GUI of macOS and Windows which do just work.
If you mean why isn't the app written to just work then that is often ignorance of what calls and things are Linux specific - a non GUIO business app should be easily portable;le between macOS and Linux and SunOS etc you don't need low level API calls for that.
Nix/Guix: Why? We literally solved this issue 20 years ago.
In the real world you're going to need to understand what your dependencies are (if only for understanding and closing security holes when they are discovered) and you will be in a world of pain when the yolo approach catches up with you.
I'm not saying to not use containers btw. I think containers are great and can save time when use properly. They are just not the panacea people make them out to be.
See https://github.com/NixOS/nixpkgs/issues/93327 (which grew from https://github.com/NixOS/nixpkgs/issues/9682)
In order to get devpod ssh to work, DevPod injects itself into your host machine (where all the devcontainers run). When you ssh into your devcontainer, devpod's ssh implementation acts as a proxy into the container, allowing you to get an in-container shell without having to run sshd inside the container. But people are already injecting VS Code into remote machines, so maybe this doesn't matter to you.
DevPod's ssh implementation does not handle newlines properly; full-screen displays can get garbled on many terminals. But most DevPod users are using the terminal inside VS Code, which seems to work fine.
In the past, I had to resize the terminal once manually after execing in, but I think either docker or bash or something in the chain got an update in the past few years that fixed it to automatically work
For web projects, I understand that latency should be considered, but I've learned what's important there and don't want to build/compile/minify my projects in development so I'm wasting time downloading the same MB's of JS over and over when only a few bytes changed so I'm not getting cache hits.
But it do not seems to have gotten the love I feel it deserves from the nix community.
The whole premise of this article is shaky.
Understand what the command does and why you're told to run it before you run it.