3 ms·
> Using it is usually as simple as "configure;make;make install". "Usually" indeed. Because if it breaks, you do need to know the implementation details to fig
by sltkr 11y ago
> Using it is usually as simple as "configure;make;make install".
"Usually" indeed. Because if it breaks, you do need to know the implementation details to figure out what's wrong.
- Jare 11y agoThat's the same for "wget|sh", apt-get, npm or any other system. Now, if the argument is that configure tends to break more often and for more obscure reasons, I can tentatively agree with that.
- deong 11y agoThis is the reason why all these standalone things bundle everything into their installation process. The problem is installing 206 different pythons on my system just makes it more likely that something else is going to break.
- garthk 11y ago… which is one of the pressures driving Docker adoption. Each process tree gets its own root filesystem to trash with its multitude of dependencies. DLL hell, shared library hell, JDK hell, Ruby and Python environment hell… a lot of it can be summed up as "userland hell". Docker makes it easy to give the process its own bloody userland and be done with it.
- deong 11y agoI think this falls under the heading of "I'm old", but I already have one machine to maintain. Replacing it with N machines to maintain doesn't feel like a win to me.
- lmm 11y agoI'd actually disagree with that. Auto* breaks less often than wget or npm, IME.
- bd_at_rivenhill 11y agoMy experience is that "configure;make;make install" has a much higher probability of success (>95% regardless of whether you are running the most up-to-date version of the OS) than something like cmake (which seems to hover around 60% if you try to build on slightly older systems).