Author Topic: Linux Dependency Black Hole  (Read 2130 times)

0 Members and 1 Guest are viewing this topic.

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8193
  • Country: fi
Re: Linux Dependency Black Hole
« Reply #50 on: April 27, 2024, 06:21:16 pm »
What's wrong with docker? It actually provides a way to create an abstraction layer to decouple the software in question from the host OS, thus helping to solve dependency issues

It is "solving" an unnecessary problem that is created by poor practices. I consider it as a bandaid, or hack, or lipstick on a pig. Even if you end up using it, I strongly suggest designing your software such that it does not depend on docker. If docker is making things slightly easier for some (the new docker generation), then it's OK. If your software is nightmare to use without docker, then it's a good indicator of failure.

* Avoid dynamic linking, link statically if possible, and therefore:
 * Avoid library dependencies like plague;
How does the latter follow from the former? If you link statically, you don't care about dependencies.

Even with static linking, unneceassary dependencies increase the size of your binary, and makes your own development work more difficult to you or anyone else who tries to build the project from sources. So what I really meant: avoid excessive library use regardless of static vs. dynamic linking.

Quote
By using libraries, you avoid reinventing the wheel and avoid making dangerous mistakes.

In the perfect world, yes, and this is correct use of libraries. It is very typical however to solve relatively simple problems with libraries which do not exactly solve that problem, and end up doing same amount of work anyway, in which case you have both your own mistakes plus any hidden within the library.

A simplified example not too far from reality is using a DSP library to perform a convolution. Meanwhile, a convolution is only a few lines of code, looping through the data, doing multiplications and additions. If you do it though a library, you are:
* Creating a dependency,
* Due to poor API, probably creating copies of data,
* Due to poor API, probably supplying pointers and data counts, increasing risk of serious memory access bugs
* Possibly decreasing performance

For truly complex problems which are a lot of work to "reinvent", and which can be abstracted to simple and intuitive APIs, this isn't a problem at all.

You seem to have good trust in quality of libraries. I don't. Therefore I suggest use only those you actually need. Quality over quantity.
« Last Edit: April 27, 2024, 06:28:26 pm by Siwastaja »
 
The following users thanked this post: JPortici


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf