4 ms·

You seem to be confused about how typical C/C++ projects are built. If you need globally installed dependencies, you're going to have to install them yourself.

You seem to be confused about how typical C/C++ projects are built. If you need globally installed dependencies, you're going to have to install them yourself. A typical makefile is not going to download a long list of random junk from the internet and install it your machine without asking. Although you'd be forgiven for thinking so if you're used to npm. If you don't like where the project installs its binaries or libraries, you can configure that before `make` or `make install`. You can install it to your home directory, have a separate directory tree for experiments, or whatever you want, and clean it up whenever it is convenient. You can also install things in usr/local and just ignore them. The system is actually well designed if you learn how to use it. If you need a dependency, use your package manager to install it and you can trivially delete it later... and if you try five different frontends for the same library, you only install one copy of it. Docker is a workaround for a lack of Unix awareness and sysadmin experience.

spion 6y ago
The system is not well designed. For example: if I have 3 projects I'm developing locally, each needing a dozen (somewhat overlapping) libxxx-dev dependencies to build, how can I automatically clean up the dependencies that are no longer needed when I delete one of the 3 projects? Distro package managers are focused on providing a good experience for sysadmins while ignoring needs during development time. Unfortunately, docker and the developer-centric improvements in language package managers have come at the expense of worse sysadmin experience. The situation will remain sub-optimal until both groups start working together to address both needs.
- inimino 6y ago
  If you've got some leftover libraries in /usr/local/lib on your development machine because of an experiment, why is that the end of the world? If you're worried about it, you shouldn't be. The worst thing about Docker is that people think learning Docker is a substitute for basic competence as a sysadmin.
  - spion 6y ago
    I'll put it in context. Let's say I have leftover garbage in usr/local/lib. I clone a new project that I need to patch because it's broken. I try to fix the new project but the fix isn't working. I have no idea why. I spend hours trying to trace down the problem. What was the issue? The project picked up some of the old garbage libraries I had in usr/local/lib, which had a bug that made my fix not work. For developers, global dev library garbage = global mutable state. It interferes with development, creates more sources of potential issues, and takes time to trace and debug. A clean and/or localized environment is essential for the accurate pinpointing of bugs and issues.
    - inimino 6y ago
      > I spend hours trying to trace down the problem. This is the problem. Once you understand library loading, once on your system, and learn, once, how to query the system and see what libraries are being loaded and from where, you won't have to waste hours on this problem again. Until that point, you're operating a system without understanding, and that will always lead to breakage.
      - saagarjha 6y ago
        I've installed hundreds of pieces of software from source, and I have a fairly decent idea of how linking and loading works. I still have to spend time figuring out why something doesn't build when it should due to something strange about my system.
      - spion 6y ago
        Of course I understand how it works. I just can't constantly keep in mind what garbage I played around with 3 months ago that might be responsible for the issue I'm looking at right now. I don't expect it, and more importantly, I shouldn't have to expect it. It's a basic tenant of development. Eliminate all additional sources of issues and complexity by presenting a clean, well-controlled sandbox in order to effectively diagnose it and fix the real bug. In fact, you should be able to try a newer version of a dependency, an older one, or run 10 variants (containers) each with different versions to e.g. test whether the project you're working on is widely compatible with a flexible range of that dependency. These things are done all the time. The tools are inadequate, not the developers. Engineers on both sides need to stop assuming everyone else is an idiot.

spion 6y ago

The system is not well designed. For example: if I have 3 projects I'm developing locally, each needing a dozen (somewhat overlapping) libxxx-dev dependencies to build, how can I automatically clean up the dependencies that are no longer needed when I delete one of the 3 projects? Distro package managers are focused on providing a good experience for sysadmins while ignoring needs during development time. Unfortunately, docker and the developer-centric improvements in language package managers have come at the expense of worse sysadmin experience. The situation will remain sub-optimal until both groups start working together to address both needs.

inimino 6y ago
If you've got some leftover libraries in /usr/local/lib on your development machine because of an experiment, why is that the end of the world? If you're worried about it, you shouldn't be. The worst thing about Docker is that people think learning Docker is a substitute for basic competence as a sysadmin.
- spion 6y ago
  I'll put it in context. Let's say I have leftover garbage in usr/local/lib. I clone a new project that I need to patch because it's broken. I try to fix the new project but the fix isn't working. I have no idea why. I spend hours trying to trace down the problem. What was the issue? The project picked up some of the old garbage libraries I had in usr/local/lib, which had a bug that made my fix not work. For developers, global dev library garbage = global mutable state. It interferes with development, creates more sources of potential issues, and takes time to trace and debug. A clean and/or localized environment is essential for the accurate pinpointing of bugs and issues.
  - inimino 6y ago
    > I spend hours trying to trace down the problem. This is the problem. Once you understand library loading, once on your system, and learn, once, how to query the system and see what libraries are being loaded and from where, you won't have to waste hours on this problem again. Until that point, you're operating a system without understanding, and that will always lead to breakage.
    - saagarjha 6y ago
      I've installed hundreds of pieces of software from source, and I have a fairly decent idea of how linking and loading works. I still have to spend time figuring out why something doesn't build when it should due to something strange about my system.
    - spion 6y ago
      Of course I understand how it works. I just can't constantly keep in mind what garbage I played around with 3 months ago that might be responsible for the issue I'm looking at right now. I don't expect it, and more importantly, I shouldn't have to expect it. It's a basic tenant of development. Eliminate all additional sources of issues and complexity by presenting a clean, well-controlled sandbox in order to effectively diagnose it and fix the real bug. In fact, you should be able to try a newer version of a dependency, an older one, or run 10 variants (containers) each with different versions to e.g. test whether the project you're working on is widely compatible with a flexible range of that dependency. These things are done all the time. The tools are inadequate, not the developers. Engineers on both sides need to stop assuming everyone else is an idiot.