3 ms·

Well all of the 50+ people I know using linux everyday including myself, most of them as their major OS, have encountered these type of issues where you lose hu

by stinos 12y ago

Well all of the 50+ people I know using linux everyday including myself, most of them as their major OS, have encountered these type of issues where you lose huge amounts of time trying to get something rather trivial to work. While your claim "It's between chair and keyboard" aka "yeah that's because they don't know how to do it" is of course perfectly valid, the reason the problem exists in the first place is usually elsewhere. That being said, my last Debian install was pretty much effortless. But I seem to have a machine with which most Linux distors are quite happy :]

vetinari 12y ago
While there can be some trivialities that waste huge amount of time on every OS, however, installing Linux and setting up dev environment is not one of them. Certainly not compared to Windows, where you must consider VS/msvcrt version, if you are using third party SDKs. It gets into "really not funny" territory when they have conflicting requirements. Compared to that, Linux development environment is a piece of cake.
- stinos 12y ago
  Sort of agree, the benefits of most linux' distros package managment system combined with lots of open source and gcc binaries being compatible with a quite few versions back are obvious. But that doesn't mean they don't exist partly on Windows. "where you must consider VS/msvcrt version, if you are using third party SDKs." is a bit too narrow: that is (afaik) only the case if you use binary distributions of 3rd party libs and only for particular languages like C/C++ and if they make use of the standard libraries and force that upon the user by exporting instances of objects in it - and more often than not I've encountered all sorts of situation where that was not the case: - it's OK to have e.g. a C lib linking against msvcrt x and use it in an application linked against msvcrt y, as long as the API is written properly and doesn't do insane things like trying to free what has been malloc'ed elsewhere - if you have the source, you just build everything with the same VS version and that's it - for C# etc there's a rather decent package manager so that's it as well usually
  - vetinari 12y ago
    We seem to agree together :). It may be or may be not easy to rebuild everything with the same VS version, especially open source packages. Many maintainers do not care about VS at all (e.g. xz/liblzma - use mingw, VS is not C99 anyway... but mingw links agains msvcrt.dll, which is a no-no) or have some crazy build system, that is supposed to work cross-platform, but really works only on Linux and maybe OSX (I'm looking at you, py2cairo). Some of them do care and building is a piece of cake (curl). Or they are somewhere in the middle, where will make their own build system, that defies all your expectations and does it's own things ignoring your vcvars (Boost). When we get out of the C/C++ realm, it gets easier everywhere, whether C# or Python.

by stinos 12y ago

vetinari 12y ago

While there can be some trivialities that waste huge amount of time on every OS, however, installing Linux and setting up dev environment is not one of them. Certainly not compared to Windows, where you must consider VS/msvcrt version, if you are using third party SDKs. It gets into "really not funny" territory when they have conflicting requirements. Compared to that, Linux development environment is a piece of cake.

stinos 12y ago
Sort of agree, the benefits of most linux' distros package managment system combined with lots of open source and gcc binaries being compatible with a quite few versions back are obvious. But that doesn't mean they don't exist partly on Windows. "where you must consider VS/msvcrt version, if you are using third party SDKs." is a bit too narrow: that is (afaik) only the case if you use binary distributions of 3rd party libs and only for particular languages like C/C++ and if they make use of the standard libraries and force that upon the user by exporting instances of objects in it - and more often than not I've encountered all sorts of situation where that was not the case: - it's OK to have e.g. a C lib linking against msvcrt x and use it in an application linked against msvcrt y, as long as the API is written properly and doesn't do insane things like trying to free what has been malloc'ed elsewhere - if you have the source, you just build everything with the same VS version and that's it - for C# etc there's a rather decent package manager so that's it as well usually
- vetinari 12y ago
  We seem to agree together :). It may be or may be not easy to rebuild everything with the same VS version, especially open source packages. Many maintainers do not care about VS at all (e.g. xz/liblzma - use mingw, VS is not C99 anyway... but mingw links agains msvcrt.dll, which is a no-no) or have some crazy build system, that is supposed to work cross-platform, but really works only on Linux and maybe OSX (I'm looking at you, py2cairo). Some of them do care and building is a piece of cake (curl). Or they are somewhere in the middle, where will make their own build system, that defies all your expectations and does it's own things ignoring your vcvars (Boost). When we get out of the C/C++ realm, it gets easier everywhere, whether C# or Python.