4 ms·
Why wouldn't you just run your stable work on a vm? Drop it onto an unstable host to play around and of it breaks your work environment is backed up, stable, an
by memebrane 2y ago
Why wouldn't you just run your stable work on a vm? Drop it onto an unstable host to play around and of it breaks your work environment is backed up, stable, and unimpeded. There are many creative ways to work and dogfood.
- kyrofa 2y agoPerhaps I'm misunderstanding your question, but is it really dogfooding if every meaningful thing I'm doing is within a stable VM? In general, a VM for my work doesn't change anything. It doesn't magically keep anything backed up: I still need to commit/push regularly, and so on. If the host explodes, I'm still down, even if what I'm doing is in a VM. I could immediately reinstall an older release and get set back up, but that isn't really dogfooding for an OS. I would need to report a bug and actually get the issue resolved, which generally means running in a broken state for a while to get there. Beyond that, I've used a VM for my day-to-day work in the past, and honestly I found it maddening. I couldn't fully utilize my computer without starving the host of resources, and there were a thousand other papercuts relating to hardware access and general instability. I try to avoid that development story these days. As you can see, my concerns here have nothing to do with losing code or data. They relate to lost productivity and not satisfying my primary duties.
- sshine 2y ago> a VM for my work doesn't change anything For complex software, real-life testing all the corners is impossible. You'd get some value out of people running it on VMs, some people running it on the same old hardware, some people running it on cutting-edge hardware, some people running it for extended periods and doing dist-upgrades, some people constantly reinstalling it (even within a VM). There are so many places software could fail. Especially things that aren't repeated often seem to fail: For example, websites where logging in works, but creating a user fails and nobody notices, because all employees already have accounts.
- kyrofa 2y agoI think you're misinterpreting my response. Of course there's value in testing operating systems within VMs. In fact, a solid chunk (if not most) of the Ubuntu install-base is VMs, believe it or not. I wasn't talking about that at all, but rather responding to the idea that, if I used a VM as my development platform, my problems would go away. In reality, in that context, it really changes nothing.
- wink 2y agoSurely it would be no problem to give developers a second machine for the testing period, so they could work with that one every day and if it breaks, the stable one is just one git checkout away... But no, I've actually never seen this. Probably better to lose people who leave over their employer messing up the work hardware than spending 3k per 2-3 years for a second machine.
- sshine 2y agoExtending the metaphor with this behavior, it'd be like mainly feeding your dog store-bought food, and occasionally lining up a bowl of home-made. It might sometimes eat it, but you wouldn't know. Not all software is easily dogfoodable. A funny incident: There's a git forge called https://ayllu-forge.org/ https://ayllu-forge.org/ that they use to develop itself. `git clone` had broken, and it hadn't been fixed because the developers had already cloned the code.
- kyrofa 2y agoYes that might actually help, but I can imagine the cost/benefit analysis being difficult to pull off: the costs are very real, but the benefits are less tangible. To be clear, I don't know of anyone who left because of a bad upgrade. I think a lot of folks just ran like I did, hopping from LTS to LTS after the point release (or only once their LTS was nearing EOL).