hextakatt wrote:Octacone wrote:Never had a single problem with them on Windows, even if there was, it was a super simple fix.
My dude you just cannot comprehend how many years of life I've lost due to Linux.
Eeeeh, do you forget about DLL hell?
I'm guessing that Octacone wasn't around to see the worst of it, which was in the early 1990s before the Registry was introduced in Windows 95 - though the bulk of the solution didn't really appear until Win98SE, as the initial Registry implementation left much to be desired.
DLL conflicts are still a major problem, but tend to get lost in the proliferation of even bigger and more visible problems - many of them caused by the Registry, so the cure has often been worse than the disease.
The job of managing dependencies, which is done by package managers in Linux (as core Linux doesn't have any such thing at all), is mostly done by the Registry in Windows. The main advantage for Windows is that there is exactly
one type of Registry which is present in all Windows installations (for a given version of Windows, at least), which all developers can safely target without having to worry about having to support infinity minus one package managers with different distribution models (each of which might have multiple different implementations). The down side is that this same monoculture means that when it breaks or has a vulnerability, the problem occurs on every system, all at once.
Also, whereas in the Linux world, libraries are usually treated as separate entities, to be downloaded and installed as dependencies when needed but always treated as their own packages, in Windows they are usually seen as subordinate to the programs they are used by. As a result, many Windows programs tend to bypass the use of any DLLs which aren't part of either Windows itself (which make up about 75% of Windows, for the record, which is comparable to the composition of most Linux distros when the desktop manager is included) or Windows SDK, meaning that they tend to include a lot of redundant code which
could be shared packages, but aren't.
This is also why most Windows installer packages include a copy of every third-party or bespoke DLL they need, and rely on the Registry to sort out which ones are already installed and the versions thereof. Prior to the introduction of the Windows Store, there was no easy way to distribute DLLs separately from the installers for the packages which use them, and even now it is generally more trouble than it is worth for the developers to try to use the WS as a way to get their dependencies distributed. By contrast, the majority of Linux package managers (of which there is a profusion, none of which are particularly good but most of which are superior to the WS, IMAO) work from the assumption that .so libraries are independent packages in their own right.
By no means am I saying that the Linux solutions (or the Mac OS solution, for that matter) are better; they simply suck in different ways. The fact that with most Linux distros almost any shared library can be treated as a 'just there' resource which will be automatically installed simply by including them in the dependency files has lead to a great deal of sloppiness in the handling of dependencies. Conversely, the number of different package file types, and the various flavors of each, has led to a great deal of confusion and redundant effort. Finally, there is always frustration involved when a given package is available in one package manager format but not others, or in a given format only from certain repositories. It's a trade-off.
Mind you, my plans for Kether involve a system in which
everything is a shared library (sort of, it's TOCOTOX without derailing the thread even further) and every installation is a repo for all publicly visible programs and data currently cached on them (unless the admin explicitly disables torrenting), so my perspective is a little odd.
I'm exaggerating, but I think that's the essence of the problem.