3 ms·

A snippet of a quote from Pirate Praveen in the article. > All the current trends are making it easy for developers to ship code directly to users. Which encou

A snippet of a quote from Pirate Praveen in the article. > All the current trends are making it easy for developers to ship code directly to users. Which encourages more isolation instead of collaboration between projects. This is where I would respectfully disagree. As a dev, packaged libraries from the system are often fine – until I hit a snag, and need to work with the devs from another project to work out a fix. With cargo/node/yarn/poetry/gopkg/... I can send a PR to another project, get that merged, and vendor in the fix while all of that is happening. If I can't do that, I'm left with hacky workarounds, as upstreaming a fix and then waiting up to 12 months (if I'm on a six-month release tempo OS) for the fix to be available to me is just not practical. Being able to work on a quick turnaround with dependencies to fix stuff is one of the huge wins with modern build tools.

ohazi 6y ago
Even as an engineer, I usually draw a line between "stuff I like to hack on" and "core system components that I'd rather not touch." I'm fine pulling a dependency from nightly for a project I'm working on, or because some program I use has a cool new feature I want to play with. But I probably wouldn't do that with, say, openssh. I can certainly sympathize with this: > and then waiting up to 12 months (if I'm on a six-month release tempo OS) for the fix to be available but the needs of system administrators are not the same as the needs of developers. That's why my development machine is on a rolling release, but my servers run Debian stable with as few out-of-repository extras as possible. Those servers are really fucking reliable, and I don't need a massive team to manage them. Maybe this sort of "boring" system administration isn't as popular as it used to be with all of that newfangled container orchestration stuff, but this is the core of the vendoring argument. Installing who-knows-what from who-knows-where can work if you're Google, but it really sucks if you're one person trying to run a small server and have it not explode every time you poke at it.
- wbl 6y ago
  The point of vendoring and not using dynamic linking is to avoid spooky action at a distance that screws up everything.
- npsimons 6y ago
  > but the needs of system administrators are not the same as the needs of developers. That's why my development machine is on a rolling release, but my servers run Debian stable with as few out-of-repository extras as possible. As another code monkey-cum-sysadmin, I very much second this: my servers are Debian stable without non-free, and there's damn good reason for that. I can appreciate GP's argument, and I've been there, pulling down CL libraries for playing around on my development machines. But what GP leaves out is that more often than not, those distribution-external packages break, and if I was relying on them, I'd be left holding the bag. I do agree, there is a problem (that the LWN article goes into), and it definitely needs attention. Distributions might be able to handle newer ecosystems better. But for all the awesome whizbang packages of NPM, QuickLisp, etc, developers need to realize that sysadmins and especially distro maintainers have to look at the bigger picture. Maybe consider that if your software introduces breaking changes or needs security updates on a weekly basis, it isn't production ready.
  - remram 6y ago
    I wonder if those packages that have been de-vendored by Debian developers, using kludges that are not supported upstream, meet your stability expectations. Not to be critical of your point, because I agree entirely.
- mdekkers 6y ago
  > Maybe this sort of "boring" system administration isn't as popular as it used to be with all of that newfangled container orchestration stuff Indeed, and all the "newfangled container orchestration stuff" also needs to run somewhere stable.
olau 6y ago
I think you misunderstood what he is talking about. The issue he's addressing is that you don't care about other projects also using this library.
z3t4 6y ago
I've been maintaining a Node.js app for about five years and almost all dependencies have been "vendored"/locked with forked libraries because some of the dependencies have been abandoned, and some have switched owners where the new owner spend their days adding bugs to perfectly working code due to "syntax modernization", or where the maintainer didn't accept the pull request for various reasons. Software collaboration is not that easy, especially if it's done by people in their (very little) spare time.
- dolni 6y ago
  > Software collaboration is not that easy, especially if it's done by people in their (very little) spare time. This is true, but somehow the Node ecosystem has managed to do it worse than those that came before it. At the risk of sounding elitist, I submit that this phenomenon is due to a flood of novice developers that are entering the industry via six week "learn to code" boot camps.

ohazi 6y ago

Even as an engineer, I usually draw a line between "stuff I like to hack on" and "core system components that I'd rather not touch." I'm fine pulling a dependency from nightly for a project I'm working on, or because some program I use has a cool new feature I want to play with. But I probably wouldn't do that with, say, openssh. I can certainly sympathize with this: > and then waiting up to 12 months (if I'm on a six-month release tempo OS) for the fix to be available but the needs of system administrators are not the same as the needs of developers. That's why my development machine is on a rolling release, but my servers run Debian stable with as few out-of-repository extras as possible. Those servers are really fucking reliable, and I don't need a massive team to manage them. Maybe this sort of "boring" system administration isn't as popular as it used to be with all of that newfangled container orchestration stuff, but this is the core of the vendoring argument. Installing who-knows-what from who-knows-where can work if you're Google, but it really sucks if you're one person trying to run a small server and have it not explode every time you poke at it.

wbl 6y ago
The point of vendoring and not using dynamic linking is to avoid spooky action at a distance that screws up everything.
npsimons 6y ago
> but the needs of system administrators are not the same as the needs of developers. That's why my development machine is on a rolling release, but my servers run Debian stable with as few out-of-repository extras as possible. As another code monkey-cum-sysadmin, I very much second this: my servers are Debian stable without non-free, and there's damn good reason for that. I can appreciate GP's argument, and I've been there, pulling down CL libraries for playing around on my development machines. But what GP leaves out is that more often than not, those distribution-external packages break, and if I was relying on them, I'd be left holding the bag. I do agree, there is a problem (that the LWN article goes into), and it definitely needs attention. Distributions might be able to handle newer ecosystems better. But for all the awesome whizbang packages of NPM, QuickLisp, etc, developers need to realize that sysadmins and especially distro maintainers have to look at the bigger picture. Maybe consider that if your software introduces breaking changes or needs security updates on a weekly basis, it isn't production ready.
- remram 6y ago
  I wonder if those packages that have been de-vendored by Debian developers, using kludges that are not supported upstream, meet your stability expectations. Not to be critical of your point, because I agree entirely.
mdekkers 6y ago
> Maybe this sort of "boring" system administration isn't as popular as it used to be with all of that newfangled container orchestration stuff Indeed, and all the "newfangled container orchestration stuff" also needs to run somewhere stable.

olau 6y ago

I think you misunderstood what he is talking about. The issue he's addressing is that you don't care about other projects also using this library.

z3t4 6y ago

I've been maintaining a Node.js app for about five years and almost all dependencies have been "vendored"/locked with forked libraries because some of the dependencies have been abandoned, and some have switched owners where the new owner spend their days adding bugs to perfectly working code due to "syntax modernization", or where the maintainer didn't accept the pull request for various reasons. Software collaboration is not that easy, especially if it's done by people in their (very little) spare time.

dolni 6y ago
> Software collaboration is not that easy, especially if it's done by people in their (very little) spare time. This is true, but somehow the Node ecosystem has managed to do it worse than those that came before it. At the risk of sounding elitist, I submit that this phenomenon is due to a flood of novice developers that are entering the industry via six week "learn to code" boot camps.