Amazingly screwed-up installation experience



  • @flabdablet said:

    The main reason Windows got popular in the first place has nothing at all to do with technical merit. It was all due to the savvy OS lock-in deals that MS made with a raft of microcomputer hardware vendors, in an era when most microcomputers weren't capable of running a minicomputer OS like Unix.

    Bullshit. Unix has been a fucking joke for decades.

    @flabdablet said:

    But if you honestly believe that most IT customers make purchasing decisions on the basis of technical merit, as opposed to marketing and herd behaviour, then I honestly believe you're deluded.

    Of course they're following the idiot herd; that's why Linux and FOSS continue to exist despite being such utter, absolute garbage.



  • @flabdablet said:

    @blakeyrat said:
    @flabdablet said:
    So if there's a long established, well documented and almost universally accepted convention in place for laying out a system-wide file tree, then what exactly is it that you think makes simply taking advantage of that convention by hardcoding the appropriate pathnames "dumber" than requiring every program to translate the appropriate CSIDL_xxxx identifiers to arbitrary pathnames?

    Because it gives the user/system administrator power. The power to ensure applications are installed on a network drive. The power to localize the folder name, if they so desire. The power to assign meaningful quotas to different types of data. Here's where you chime in with the tired old, "but most people don't do that!!!! Nyah!!"

    No, this is where I chime in with the fact that Unix also gives sysadmins ways to do all of those things, and that it has done so for longer than Windows has even existed.

    One of Microsoft's most annoying tendencies is to trumpet every half-assed attempt to replicate some totally customary Unix facility as if it were a revolutionary new idea they've just come up with themselves. They've been playing that game since the early 80s and show no signs of giving it up.

    Refusing to adhere to Windows filesystem conventions when on Windows, just because you like Linux better, makes you a supreme douche. One does things one way, the other does things another way. The correct answer is to follow the proper conventions for the OS you're running on, not the one you wish you were running on.

     



  • @javispedro said:

    Oh god,  I hate Dropbox. They do this even on Linux. It's the only software I have on my PC that randomly decides to autoreinstall itself to $HOME/.local, without a single warning.

    I run it completely fucking chrooted under a user account with nearly no permissions.


  • Discourse touched me in a no-no place

    @joe.edwards said:

    @boomzilla said:
    @joe.edwards said:
    There are no drive letters

    Do kids these days ever ask, "Why 'C'?"


    Well obviously A: is for your 3½ diskettes and B: is for your 5¼... Oh my God, I'm fucking old.
    So where do the 8'' ones go? Or should that link go in the Bad Ideas thread?



  • @javispedro said:

    Oh god,  I hate Dropbox. They do this even on Linux. It's the only software I have on my PC that randomly decides to autoreinstall itself to $HOME/.local, without a single warning.

    I had installed Dropbox using their Debian package, and was pleased to find that not only had it put a binary in /usr/bin and man pages in /usr/share/man and generally behaved itself, it had added /etc/apt/sources.list.d/dropbox.list to keep itself up to date using the standard package installer rather than using some fucked-up Dropbox-specific method. So, I thought, all good! I was a little concerned when on first run it told me I needed to download a "proprietary daemon" but hey, I like having my KeePass automatically sync'd so what the hell, let's do it.

    Then I read your message, and did a locate dropbox to see where the bulk of it actually went and yep, that "proprietary daemon" is 57 meg of Python and .so libraries and fuck knows what stuffed into ~/.dropbox-dist. So I immediately did rm -rf ~/.dropbox-dist to see what would happen. The directory disappeared and my running instance of Dropbox kept running, but since merely unlinking in-use things doesn't actually get rid of them, I rebooted to see whether .dropbox-dist was merely a staging area for downloads or something more vital. When I logged on, Dropbox did the first-run "download the daemon" thing again, and once that had run there was once again 57 meg of something or other sitting in my home folder.

    So I did sudo mv ~/.dropbox-dist /opt/dropbox and sudo chown -R root:root /opt/dropbox and ln -s /opt/dropbox ~/.dropbox-dist and rebooted again, and it autostarted and ran as if nothing had happened. So I logged off my account and logged in to my beloved's, and did ln -s /opt/dropbox ~/.dropbox-dist for her as well, and then started Dropbox from Applications->Internet same as I'd initially done after installing it for me; and it skipped the "download the daemon" thing and went straight to the account creation or login step, so I have no doubt it will just work without needing to add another 57 meg of shite to hers as well.

    Being able to work around irritating proprietary brokenness in straightforward ways like this is one of the reasons I really, really like *nix.

    I'm quite keen to find out what will happen now when /opt/dropbox/dropbox decides it's out of date and finds itself chown'd to root. Will it politely complain, silently fail, or destroy my symlink and give me another 57 meg of new version? Time will tell.



  • @flabdablet said:

    No, this is where I chime in with the fact that Unix also gives sysadmins ways to do all of those things, and that it has done so for longer than Windows has even existed.

    O rly? How do I install a package to a directory of my choosing, instead of where it's hard-coded to go? How do I implement a quota for a single program (binaries, libraries and whatever-else)? How do I keep two versions of the same program installed when they both want to overwrite /usr/bin/fuckeree?



  • @mott555 said:

    Refusing to adhere to Windows filesystem conventions when on Windows, just because you like Linux better, makes you a supreme douche.
    And, of course, vice versa. But once again, this thread started with a proprietary Windows-only package that refuses to adhere to Windows filesystem conventions when on Windows. The whole Linux derail came about because of a completely unsubstantiated inference that this asshattery was somehow FOSS's fault.

    @mott555 said:

    One does things one way, the other does things another way. The correct answer is to follow the proper conventions for the OS you're running on, not the one you wish you were running on.
    Absolutely agree.


  • ♿ (Parody)

    @ender said:

    @joe.edwards said:
    Well obviously A: is for your 3½ diskettes and B: is for your 5¼... Oh my God, I'm fucking old.
    Nah, this means you're young. A: is obviously for 5¼ floppy, and B: is for 3½ one, which was added a few years later when those newfangled not-so-floppy discs became more common.

    That's crazy. A: is obviously your boot disk and B: is for other stuff.



  • @flabdablet said:

    @javispedro said:
    Oh god,  I hate Dropbox. They do this even on Linux. It's the only software I have on my PC that randomly decides to autoreinstall itself to $HOME/.local, without a single warning.

    I had installed Dropbox using their Debian package, and was pleased to find that not only had it put a binary in /usr/bin and man pages in /usr/share/man and generally behaved itself, it had added /etc/apt/sources.list.d/dropbox.list to keep itself up to date using the standard package installer rather than using some fucked-up Dropbox-specific method. So, I thought, all good! I was a little concerned when on first run it told me I needed to download a "proprietary daemon" but hey, I like having my KeePass automatically sync'd so what the hell, let's do it.

    Then I read your message, and did a locate dropbox to see where the bulk of it actually went and yep, that "proprietary daemon" is 57 meg of Python and .so libraries and fuck knows what stuffed into ~/.dropbox-dist. So I immediately did rm -rf ~/.dropbox-dist to see what would happen. The directory disappeared and my running instance of Dropbox kept running, but since merely unlinking in-use things doesn't actually get rid of them, I rebooted to see whether .dropbox-dist was merely a staging area for downloads or something more vital. When I logged on, Dropbox did the first-run "download the daemon" thing again, and once that had run there was once again 57 meg of something or other sitting in my home folder.

    So I did sudo mv ~/.dropbox-dist /opt/dropbox and sudo chown -R root:root /opt/dropbox and ln -s /opt/dropbox ~/.dropbox-dist and rebooted again, and it autostarted and ran as if nothing had happened. So I logged off my account and logged in to my beloved's, and did ln -s /opt/dropbox ~/.dropbox-dist for her as well, and then started Dropbox from Applications->Internet same as I'd initially done after installing it for me; and it skipped the "download the daemon" thing and went straight to the account creation or login step, so I have no doubt it will just work without needing to add another 57 meg of shite to hers as well.

    Being able to work around irritating proprietary brokenness in straightforward ways like this is one of the reasons I really, really like *nix.

    I'm quite keen to find out what will happen now when /opt/dropbox/dropbox decides it's out of date and finds itself chown'd to root. Will it politely complain, silently fail, or destroy my symlink and give me another 57 meg of new version? Time will tell.

    That's amazingly broken software, but let's see if I understand this:

    You spent time "fixing" the problem and implementing the fix on another account, and now you've likely lost the ability to receive automatic updates for a poorly-written daemon that connects to the Internet and has read and write access to most of your personal files. What did you get in exchange? You saved 57 megabytes and made your filesystem a little more logically-laid-out. To me it seems like you satisfied your OCD at the expense of real concerns: namely, being able to get security updates. Maybe you'll get lucky and DB will refuse to run with your out-of-date version.

    Oh, and if by some miracle you do get an automatic update, it's going to wipe out your work and you'll have to do the copying-and-resymlinking business again. And if you really don't care about updates and don't want it to overwrite your symlink, just chown it to root and don't give yourself write perms.



  • @morbiuswilters said:

    Except you can't enforce them on a case-by-case basis. Every fucking library gets shat out into /usr/lib. Every fucking binary gets barfed up into /usr/bin or /usr/sbin*.

    Wait what? Is that even dumber than I thought?

    What if an application Foo has a math.lib, and an application Bar has a completely different math.lib? God please tell me there's subfolders for each app!



  • @flabdablet said:

    The main reason Windows got popular in the first place has nothing at all to do with technical merit. It was all due to the savvy OS lock-in deals that MS made with a raft of microcomputer hardware vendors, in an era when most microcomputers weren't capable of running a minicomputer OS like Unix.

    Explain why Novell existed. In your little mental framework here. If Unix was always so much better than Windows, then why Novell? Why would people buy and use Novell, which was super-successful for many years and was not Unix?



  • @blakeyrat said:

    @morbiuswilters said:
    Except you can't enforce them on a case-by-case basis. Every fucking library gets shat out into /usr/lib. Every fucking binary gets barfed up into /usr/bin or /usr/sbin*.

    Wait what? Is that even dumber than I thought?

    What if an application Foo has a math.lib, and an application Bar has a completely different math.lib? God please tell me there's subfolders for each app!

    From what I can tell on my current Linux workstation (unfortunately we support several Linux distros along with Windows), it depends. Some stuff dumps things straight into /usr/lib, /usr/bin, and /usr/include. Other stuff creates a subfolder first. Some do both and then symbolically link into the subfolder.


  • @morbiuswilters said:

    How do I install a package to a directory of my choosing, instead of where it's hard-coded to go?
    Build it from source is the general answer, because pretty much every package has build-time config options that let you specify where it's going to be installed. But if you're working with precompiled binaries you have a range of options, from symlinks to union mounts.

    @morbiuswilters said:

    How do I implement a quota for a single program (binaries, libraries and whatever-else)?

    What kind of quota are you after? The way your question is worded suggests you're looking for a way to limit the total size occupied by the program itself, which is incidentally not a problem that the CSIDL resource lookup mechanism can solve for you. If that's really what you want to do - perhaps because the package in question is an auto-updating self-standing monolith from outer space that you have no real control over - you can create a loop device backed by a fixed-size but sparse file, make a filesystem on that, then mount it on a subdirectory of /opt and stuff the package in there.

    If you're after a way to limit the amount of disk space consumed by running the program, easiest way I can think of is to create a group for it to run in, impose a per-group disk quota on that, and make a small wrapper script in /usr/bin that uses sg to launch the actual executable; use file permissions on the executable to prevent it being executed with an incorrect group ID.

    @morbiuswilters said:

    How do I keep two versions of the same program installed when they both want to overwrite /usr/bin/fuckeree?
    In much the same way you'd keep two versions of a Windows package installed when their installers both want to overwrite C:\Windows\System32\msvc90.dll. Swearing would be involved. Again, this is really not something that the CSIDL mechanism makes any easier.


  • Discourse touched me in a no-no place

    @flabdablet said:

    @morbiuswilters said:
    How do I keep two versions of the same program installed when they both want to overwrite /usr/bin/fuckeree?
    In much the same way you'd keep two versions of a Windows package installed when their installers both want to overwrite C:\Windows\System32\msvc90.dll. Swearing would be involved.
    Now there would be a case where rendition to Gitmo would be justified. (OSX's “pack everything in a directory and call that the application” style, for all that it's bloated and fairly awkward to distribute, at least avoids the vast majority of the most hellish parts of DLL Hell.)



  • @flabdablet said:

    In much the same way you'd keep two versions of a Windows package installed when their installers both want to overwrite C:\Windows\System32\msvc90.dll.

    "Hello, welcome to 1999. Please step carefully out of the timepod. Let me tell you about some technical problems we've been having with Windows..."



  • @bstorer said:

    But for every Twitter activist who makes a name for herself for #CancelColbert, there are thirty others toiling in obscurity.

    The thing is, I don't think that woman misinterpreted that joke at all. It was a racist joke. Now, I don't agree with stringing people up over silly crap like that, but Colbert was trying to lynch another guy on even-more tenuous "kinda sounds racist and makes white people uncomfortable" grounds. Instead, he gets a pass for an actual racist joke while trying to attack someone for something that's not even offensive?



  • @blakeyrat said:

    @morbiuswilters said:
    Except you can't enforce them on a case-by-case basis. Every fucking library gets shat out into /usr/lib. Every fucking binary gets barfed up into /usr/bin or /usr/sbin*.

    Wait what? Is that even dumber than I thought?

    What if an application Foo has a math.lib, and an application Bar has a completely different math.lib? God please tell me there's subfolders for each app!

    No, in the Unix world, it's just assumed that libm (the C math library) is always the same libm. Two different programs can link against two different versions of libm, although this will quickly become a nightmare of DLL hell as you try to manage all of these dependencies. For the end-user, it may not be so awful because there are teams of people donating their time to keeping all of this shit straight in the package manager, but if you want to compile your own versions or go off the rails, good fucking luck.



  • @blakeyrat said:

    @flabdablet said:
    The main reason Windows got popular in the first place has nothing at all to do with technical merit. It was all due to the savvy OS lock-in deals that MS made with a raft of microcomputer hardware vendors, in an era when most microcomputers weren't capable of running a minicomputer OS like Unix.

    Explain why Novell existed. In your little mental framework here. If Unix was always so much better than Windows, then why Novell? Why would people buy and use Novell, which was super-successful for many years and was not Unix?

    Or VMS.



  • @morbiuswilters said:

    You saved 57 megabytes and made your filesystem a little more logically-laid-out. To me it seems like you satisfied your OCD at the expense of real concerns: namely, being able to get security updates.

    I only did the chown root:root step so I can find out what happens when Dropbox needs to update itself but can't; the ultimate aim is to work out how to save the many redundant megabytes of downloads that Dropbox would otherwise do to update each of its per-user installations in turn. Download volume caps suck, but many of my customers have them.

    The existence of this page suggests that Dropbox doesn't actually bother doing automatic self-updates, but I'd like to be sure. Once the next version comes out, I will figure out how best to handle it. With any luck it won't actually do its own updates, and I'll be able to do them myself with a tiny script run from cron.

    But yes, OCD.



  • @morbiuswilters said:

    No, in the Unix world, it's just assumed that libm (the C math library) is always the same libm.

    How are these names doled-out? Is there a registry of them somewhere, like Apple app creator codes, or it is just first-come, first-serve? What if I write a program with a libm but I'm not aware of the existing one because my distro doesn't ship it?



  • @mott555 said:

    From what I can tell on my current Linux workstation (unfortunately we support several Linux distros along with Windows), it depends. Some stuff dumps things straight into /usr/lib, /usr/bin, and /usr/include. Other stuff creates a subfolder first. Some do both and then symbolically link into the subfolder.

    Not exactly. Some packages create subfolders underneath /usr/lib, but the libraries there are still shared. So if I have two apps, Foo and Bar that both want to use libbaz, then they will both use /usr/lib/baz/libbaz.so (for example.)

    It's still a global namespace. Bar can't use a completely separate libbaz. However, this rarely comes up because everybody just knows that libbaz is what it is and there won't be two different libbazes, in theory. Also, all of this is managed by the package maintainers for your distro. This is one reason it's so fucking hard to create a single binary that Linux folks can download and install, because different distros will throw shit in different places or use different versions of the packages or different conventions.

    That's why with Linux, you usually don't see a binary for download like you do for Mac OSX or Windows, you instead get told to just install it from your package manager. If the project is really, really enterprising, they might pre-compile some versions for popular distros like Debian and RHEL and run their own package repositories so you just need to add their repo to your package manager. And a lot of projects don't do this, because it's a lot of work: you have to compile separate versions not just for different distros, but for different releases of those distros. So usually it's just left to the distro maintainers themselves to compile for the different releases of the distro they still support. Then you end up with a bunch of different binaries for the same package, which usually won't run on a system that's not running the same exact release of the same distro (although big distros usually have some other distros which are compatible; RHEL and Debian both have derivative distros which are package-compatible, for the most part. Other derivative distros may be so-so on compatibility--for example, some Debian packages will work on Ubuntu, but some won't.)



  • @blakeyrat said:

    @flabdablet said:
    In much the same way you'd keep two versions of a Windows package installed when their installers both want to overwrite C:\Windows\System32\msvc90.dll.

    "Hello, welcome to 1999. Please step carefully out of the timepod. Let me tell you about some technical problems we've been having with Windows..."

    As you correctly hint, properly coded Windows installers don't overwrite the same DLL any more. Which fact I was using, somewhat obliquely, to make the point that you're really unlikely to find binary packages for whatever Linux distro you're using that want to overwrite the same executable. Two packages containing the same file is something most package managers will complain vociferously about.

    So if you're going to run multiple versions of something side by side, you're probably building from source; and if that's the case, you almost certainly have build configuration options that let you set any embedded hardcoded pathnames to whatever they need to be set to.

    But if none of that works, and you're out of other options, you can fix any of these issues with creative abuse of chroot and ln, or tmpfs and mount --bind, or union filesystems.



  • @flabdablet said:

    Build it from source is the general answer, because pretty much every package has build-time config options that let you specify where it's going to be installed.

    Yeah, exactly. That's not much of an option.

    @flabdablet said:

    But if you're working with precompiled binaries you have a range of options, from symlinks to union mounts.

    Union mounts are hacky-as-shit. Have you ever tried using symlinks that way? It's all off-the-rails, as far as the package manager is concerned. Do an update and now you've got new versions of the library that have to be copied somewhere else and symlinked. That's a mess.

    @flabdablet said:

    The way your question is worded suggests you're looking for a way to limit the total size occupied by the program itself, which is incidentally not a problem that the CSIDL resource lookup mechanism can solve for you.

    Why not? Seems like you could put a quota on the directory where the package is installed and be done with it. But anyway, you could also put a quota on, say, the data that the program creates. Or stick it on a faster or slower storage device. Having the ability to specify where stuff is installed is nice. (And don't give me the symlink nonsense.. that's a hacky way to handle it and it can break fairly easily.)

    @flabdablet said:

    @morbiuswilters said:
    How do I keep two versions of the same program installed when they both want to overwrite /usr/bin/fuckeree?
    In much the same way you'd keep two versions of a Windows package installed when their installers both want to overwrite C:\Windows\System32\msvc90.dll. Swearing would be involved. Again, this is really not something that the CSIDL mechanism makes any easier.

    That's not the same thing at all. If I want to install two versions of Fuckeree™ on Windows, say versions 1.9 and 2.0, I can do that during setup, putting them into Program Files\Fuckeree 1.9 and Program Files\Fuckeree 2.0. You can't do that on Linux when both versions want to install to the same place.



  • @morbiuswilters said:

    @blakeyrat said:
    @flabdablet said:
    The main reason Windows got popular in the first place has nothing at all to do with technical merit. It was all due to the savvy OS lock-in deals that MS made with a raft of microcomputer hardware vendors, in an era when most microcomputers weren't capable of running a minicomputer OS like Unix.

    Explain why Novell existed. In your little mental framework here. If Unix was always so much better than Windows, then why Novell? Why would people buy and use Novell, which was super-successful for many years and was not Unix?

    Because Novell ran on the same kind of cheap and increasingly ubiquitous microcomputers that Windows did and Unix didn't, and its networking product was mature when Microsoft's was embryonic.

    @morbiuswilters said:

    Or VMS.
    As in Novell wasn't VMS, or VMS wasn't Unix? Little lost here.



  • @blakeyrat said:

    @morbiuswilters said:
    No, in the Unix world, it's just assumed that libm (the C math library) is always the same libm.

    How are these names doled-out? Is there a registry of them somewhere, like Apple app creator codes, or it is just first-come, first-serve? What if I write a program with a libm but I'm not aware of the existing one because my distro doesn't ship it?

    It's just managed by the "community" and tradition. You can create your own libm, but since this is Linux you're not going to be installing your own software--remember, it's going to be compiled for you and distributed by hundreds of Linux distros. So they wouldn't allow you to use your own libm, they'd make you change it.

    You could distribute your own installer, though, which overwrote libm with your own version. That would break things, although it might go unnoticed for awhile with a more-obscure library name. But if that happened, then people would just be "RTFM" and snotty mailing list postings. It's not really a thing that's protected against, except for the fact that building cross-distribution installable binaries for Linux is so hard that most people just let the distros do it for them.



  • @flabdablet said:

    So if you're going to run multiple versions of something side by side, you're probably building from source;

    whoosh That's exactly my point. You don't seem to grasp that I'm complaining about the near-universal inability on Linux to run multiple versions of the same application in parallel. Yes, I know I can compile from source or use chroot to get around it, but goddamn. I mean, do you not see how this very-common use case is made 100x harder because of the asinine way FHS and Unix tradition work?



  • @powerlord said:

    @anonymous234 said:

    @Ben L. said:
    @blakeyrat said:
    game *tool* developers are the worst of the worst
    If anyone disagrees with blakeyrat, find a family member who doesn't have experience with Valve's Hammer world editor and see how far they can get without reading a guide.
    I still haven't managed to get the TF2 dedicated server running.
    ...can't tell if serious...

    Getting srcds running isn't that hard as long as you read the SteamCMD wiki page and know that TF2's server Steam ID is 232250.

    Once its installed, you run srcds on Windows and get a nice GUI to start it... or start it from the command line with srcds -console -game tf +maxplayers 24 +map ctf_2fort... on Linux, substitute ./srcds_run for srcds.

    Hammer, on the other hand, is ridiculously complicated and also has a tendency to crash.

     

    1. I don't want SteamCMD, I'm running it from Steam's actual GUI. 
    2. I installed "Source Dedicated Server", but that's apparently the name of the first version. I need "Source Dedicated Server 2007". Usually if I download "Skype" or "Gimp" or "VLC media player" or I go to the shop and ask for "Windows" I get the last version, not the first one. But whatever.
    3. Hosted by imgur.com

       

    4. Hosted by imgur.com

     

    And no, I didn't really want to spend more than 10 minutes trying to fix it or learning about what gameinfo.txt does or where it's supposed to be.



  • @flabdablet said:

    @morbiuswilters said:
    Or VMS.
    As in Novell wasn't VMS, or VMS wasn't Unix? Little lost here.

    VMS was also a popular alternative to Unix. Look, people have been trying to get away from the clusterfuck that is Unix for decades. Unfortunately, we keep getting dragged back in because there are millions of idiots who think checking your mail in a CLI is perfectly-acceptable; that wanting to run two versions of the same application is some crazy, esoteric use-case that shouldn't be handled; that the idea of packages being installed in a sane, isolated fashion is wrong and instead they should be scattered over a dozen places in the filesystem..

    I don't even know. I give up. This industry is fucked. I'd say that maybe we'd be okay in 50 years when all the Unix people are dead, but the stupidity keeps infecting younger generations. It's like arguing with people who put leeches on their body when they're sick because they think X-Ray machines steal their soul or something. It's just nuts..



  • @morbiuswilters said:

    @flabdablet said:
    The way your question is worded suggests you're looking for a way to limit the total size occupied by the program itself, which is incidentally not a problem that the CSIDL resource lookup mechanism can solve for you.

    Why not? Seems like you could put a quota on the directory where the package is installed and be done with it. But anyway, you could also put a quota on, say, the data that the program creates. Or stick it on a faster or slower storage device. Having the ability to specify where stuff is installed is nice. (And don't give me the symlink nonsense.. that's a hacky way to handle it and it can break fairly easily.)

    But the CSIDL mechanism doesn't address any of that. None of the CSIDL stuff is settable per application; it's system-wide (or user-wide, for the ones that point to things inside the user profile). You use CSIDL_PROGRAM_FILES to find that everything that usually goes in C:\Program Files is actually in E:\Software, but it has no useful contribution to make to the distinction between %ProgramFiles%\Fuckeree 1.9 and %ProgramFiles%\Fuckeree 2.0.

    It seems to me that you're arguing for something completely orthogonal to the hardcoded paths vs CSIDL lookup distinction. All of what you've said says that you believe that having each package occupy its own directory is a better way to run a railroad than spreading pieces of packages across a limited number of standardish directories. For what it's worth, there are Linux distro maintainers who agree with you. But none of that has any bearing on whether hard coded pathnames embedded inside executables are or are not dumber than hard coded CSIDL enumeration values that do the same job.

    I'll take pity on Blakey at this point and raise the only advantage that the CSIDL mechanism genuinely has over hard coded paths: in theory they ought to let you move C:\Program Files to E:\Software, change the single registry setting that defines what CSIDL_PROGRAM_FILES resolves to, and have everything still work; CSIDL is in effect a late binding mechanism for a small but important subset of directories.

    Which is all well and good, but try doing that on an actual Windows box and see how far you get. Hint: not very far, because there are early-bound references to the underlying filesystem paths everywhere else in the registry.

    Every OS makes certain things hard to do properly. The thing about Windows is that the typical response to that fact has been to add more and more and more special-purpose mechanisms to solve specific problems; Unix has to do less of that because the underlying mechanisms and conventions are almost always flexible enough to let you work around whatever difficulty you need to. Symlinks might be somewhat fragile but fuck they're useful.



  • @morbiuswilters said:

    Some packages create subfolders underneath /usr/lib, but the libraries there are still shared. So if I have two apps, Foo and Bar that both want to use libbaz, then they will both use /usr/lib/baz/libbaz.so (for example.)

    Well, no. That's how pre-NT windows did it, which could not distinguish between two libraries with the same basename even if they were on different paths. Linux uses the inode number to distinguish libraries, so you can load /usr/lib/baz-1.0/libbaz.so and /usr/lib/baz-1.2/libbaz.so from the process without a problem. No idea how Windows NT does it, but you can certainly do it too.

    Also in Linux the entire idea of putting stuff inside a subdirectory in /usr/lib is so that other programs searching for libraries do not find them. Because when a program asks for "libbaz.so" (that is, not specifying the absolute pathname) then it will find /usr/lib/libbaz.so, but not /usr/lib/baz/libbaz.so . That's similar to the idea of DLL search paths in Windows.

    If you look closely, virtually the 3 operating systems have very similar if not identical ideas. For example, the concept of application bundles in OS X is virtually the same as application directories in Windows, and the same ideas are used for rpath = $ORIGIN bundles in Linux (used by many propietary programs that do not want to hardcode paths in the binaries).

    The big difference in Linux, as Morbs described, is that there is a "central authority" (the distribution) which arbitrates between the various application. Thus, there is no problem if each application dumps its libraries in /usr/lib because the distribution is responsible for ensuring no name conflicts appear. One may argue whether this is the best method or not but it's the way it is. Applications not subject to this "central authority" are supposed to install in /opt which is basically equivalent to "Program Files" in Windows; that is, /opt/<vendor>/<program>/lib/libbaz.so .

    BTW, why does community server randomly eat spaces between my words? I don't think I've posted enough in these forums to deserve this punishment...



  • @blakeyrat said:

    The FOSS version/ripoff is called Godot. Honestly, it might be good, who knows.

    And yes, "install in AppData" is programmer code for, "Vista UAC came along and we're too fucking lazy to fix our 20,000 permissions bugs."

    And yes, game developers are the worst and game *tool* developers are the worst of the worst. If you want a laugh, try out RPG Maker.




    That is reminding me, that default installation for oracle client or (ODP .NET) is App folder. So it installs to "c:\app\Nagesh\" and my friend "Rajesh" cannot use it.

  • Considered Harmful

    @Nagesh said:

    Filed under: How can Oracle with so much dollars do this to me?

    Oracle has so much dollars they can do whatever they want to you.



  • @flabdablet said:

    But the CSIDL mechanism doesn't address any of that. None of the CSIDL stuff is settable per application; it's system-wide (or user-wide, for the ones that point to things inside the user profile). You use CSIDL_PROGRAM_FILES to find that everything that usually goes in C:\Program Files is actually in E:\Software, but it has no useful contribution to make to the distinction between %ProgramFiles%\Fuckeree 1.9 and %ProgramFiles%\Fuckeree 2.0.

    It seems to me that you're arguing for something completely orthogonal to the hardcoded paths vs CSIDL lookup distinction. All of what you've said says that you believe that having each package occupy its own directory is a better way to run a railroad than spreading pieces of packages across a limited number of standardish directories. For what it's worth, there are Linux distro maintainers who agree with you. But none of that has any bearing on whether hard coded pathnames embedded inside executables are or are not dumber than hard coded CSIDL enumeration values that do the same job.

    True, I did get a bit side-tracked there. I was expanding to a more generic Windows-vs-Unix filesystems conventions rant.

    @flabdablet said:

    I'll take pity on Blakey at this point and raise the only advantage that the CSIDL mechanism genuinely has over hard coded paths: in theory they ought to let you move C:\Program Files to E:\Software, change the single registry setting that defines what CSIDL_PROGRAM_FILES resolves to, and have everything still work; CSIDL is in effect a late binding mechanism for a small but important subset of directories.

    Which is all well and good, but try doing that on an actual Windows box and see how far you get. Hint: not very far, because there are early-bound references to the underlying filesystem paths everywhere else in the registry.

    That's a bug with the software in question, though, not a gripe with the underlying convention.

    @flabdablet said:

    The thing about Windows is that the typical response to that fact has been to add more and more and more special-purpose mechanisms to solve specific problems; Unix has to do less of that because the underlying mechanisms and conventions are almost always flexible enough to let you work around whatever difficulty you need to.

    I don't really agree with that. It's more like everything in Unix is a hack, so what's the difference in throwing one more hack on top? Also, Unix just takes the default attitude of "You don't need it" and a lot of people accept that. It seems to me Microsoft tries a lot harder to make sure things work, to make sure there are ways to do the things you want that don't involve spit and baling twine.

    @flabdablet said:

    Symlinks might be somewhat fragile but fuck they're useful.

    Symlinks are great for some things, but for trying to move a package to a place it wasn't hard-coded to live? It's a really PITA hack.



  • @javispedro said:

    Linux uses the inode number to distinguish libraries, so you can load /usr/lib/baz-1.0/libbaz.so and /usr/lib/baz-1.2/libbaz.so from the process without a problem.

    What the fuck are you on about? That isn't at all what we were talking about. Christ.

    @javispedro said:

    Thus, there is no problem if each application dumps its libraries in /usr/lib because the distribution is responsible for ensuring no name conflicts appear.

    Which means you're pretty much limited to installing stuff from your distro. Yay, flexibility! Luckily, cross-platform binaries are such a royal PITA on Linux that nobody really bothers!

    @javispedro said:

    One may argue whether this is the best method or not but it's the way it is.

    Was there anyone here who said that wasn't the way it is? My vitriolic ranting was because it is an awful system. So, yeah, we're past the point of arguing how it works and into the "whether this is the best method or not" territory. Oy.

    @javispedro said:

    the same ideas are used for rpath = $ORIGIN bundles in Linux (used by many propietary programs that do not want to hardcode paths in the binaries).

    Unfortunately, most FOSS software is still too dumb to do this, so you get shit hard-coded all over the place. And honestly, I don't know the last time I've seen something that actually used rpath = $ORIGIN on Linux.


  • ♿ (Parody)

    @morbiuswilters said:

    Also, Unix just takes the default attitude of "You don't need it" and a lot of people accept that. It seems to me Microsoft tries a lot harder to make sure things work, to make sure there are ways to do the things you want that don't involve spit and baling twine.

    Unless you're an apparently crazy person with multiple monitors who wants a taskbar on all of them. How is it that MS still can't do that?



  • @Nagesh said:

    That is reminding me, that default installation for oracle client or (ODP .NET) is App folder. So it installs to "c:\app\Nagesh" and my friend "Rajesh" cannot use it.
    Filed under: How can Oracle with so much dollars do this to me?

    "Oracle Support here, my name is Nage--uh, Michael. How can I make today an Oracle Day for you?"

    "Yes, my friend Rajesh cannot make use from my Oracle client because it is installed to c:\app\Nagesh."

    "Well I'm sorry to hear that. We do hear this complaint a lot. If your friend legally changes his name to 'Nagesh', then he will be able to use the same Oracle client. Thank you and have a very Oracle Day. click"



  • @boomzilla said:

    @morbiuswilters said:
    Also, Unix just takes the default attitude of "You don't need it" and a lot of people accept that. It seems to me Microsoft tries a lot harder to make sure things work, to make sure there are ways to do the things you want that don't involve spit and baling twine.

    Unless you're an apparently crazy person with multiple monitors who wants a taskbar on all of them. How is it that MS still can't do that?

    I don't know, I've wanted that or tried to do it. The real question is: why is Windows so far behind Linux in text-only newsgroup viewers? And why is Windows so far behind Linux in failing to support WebGL? Man, I tried that Fish thing on Windows and was getting crazy framerates with a thousand fish. That's simply unacceptable; I expect it to behave the same as as on my Linux box where it rendered about a quarter frame per-second and after about 10 seconds Firefox started having a seizure and I frantically had to kill it so it didn't bring down my entire system.

    Of course, since you asked about multiple monitors, there's one area Windows beats Linux: being able to plug or unplug a second monitor without having it randomly freeze up the motherfucking OS. So maybe M$ felt it was more important to, you know, actually make sure people could have more than one monitor before they worried about how many taskbars the user had.



  • @morbiuswilters said:

    So maybe M$ felt it was more important to, you know, actually make sure people could have more than one monitor before they worried about how many taskbars the user had.

    I don't reply to dumbfuck, but Windows 8 does put a taskbar on each monitor.



  • @morbiuswilters said:

    That's a bug with the software in question, though, not a gripe with the underlying convention.
    Windows then? Because from Vista onwards there is no support for moving Program Files or Users directory away from system partition (it can be done, but it will cause random updates to fail to install or worse).
    @boomzilla said:
    Unless you're an apparently crazy person with multiple monitors who wants a taskbar on all of them. How is it that MS still can't do that?
    I've had taskbars on all monitors (without using Ultramon) since 2012.



  • @Somebody said:

    whoosh That's exactly my point. You don't seem to grasp that I'm complaining about the near-universal inability on Linux to run multiple versions of the same application in parallel. Yes, I know I can compile from source or use chroot to get around it, but goddamn. I mean, do you not see how this very-common use case is made 100x harder because of the asinine way FHS and Unix tradition work?

    Check out NixOS. It's not a "big" Linux distribution, but it's handy. And it's not any harder to use than Arch (which is braindead easy).



  • @Captain Oblivious said:

    @Somebody said:
    whoosh That's exactly my point. You don't seem to grasp that I'm complaining about the near-universal inability on Linux to run multiple versions of the same application in parallel. Yes, I know I can compile from source or use chroot to get around it, but goddamn. I mean, do you not see how this very-common use case is made 100x harder because of the asinine way FHS and Unix tradition work?

    Check out NixOS. It's not a "big" Linux distribution, but it's handy. And it's not any harder to use than Arch (which is braindead easy).

    Hey, my username is Captain Oblivion and I'd appreciate it if you quote me correctly!

    NixOS might be okay, but we'd still live in a world where most Linux distros just barf files all over the filesystem and call it a "standard".

    Also: hey, it gives me the ability to run multiple Tux Racers side-by-site. It's still Tux Racer. FOSS is so behind the curve, I don't see any reason to compete.



  • @morbiuswilters said:

    @Nagesh said:
    That is reminding me, that default installation for oracle client or (ODP .NET) is App folder. So it installs to "c:\app\Nagesh" and my friend "Rajesh" cannot use it.
    Filed under: How can Oracle with so much dollars do this to me?

    "Oracle Support here, my name is Nage--uh, Michael. How can I make today an Oracle Day for you?"

    "Yes, my friend Rajesh cannot make use from my Oracle client because it is installed to c:\app\Nagesh."

    "Well I'm sorry to hear that. We do hear this complaint a lot. If your friend legally changes his name to 'Nagesh', then he will be able to use the same Oracle client. Thank you and have a very Oracle Day. click"

    I see he's solved that specific problem before.



  • @PJH said:

    @joe.edwards said:
    @boomzilla said:
    @joe.edwards said:
    There are no drive letters

    Do kids these days ever ask, "Why 'C'?"


    Well obviously A: is for your 3½ diskettes and B: is for your 5¼... Oh my God, I'm fucking old.
    So where do the 8'' ones go? Or should that link go in the Bad Ideas thread?

    The tens-digit of my age can be represented as a single bit, but I have personally copied files from drive B to drive A. I've never seen an 8" floppy, though. Aren't they usually hard when they get that long?



  • @Ben L. said:

    @morbiuswilters said:
    @Nagesh said:
    That is reminding me, that default installation for oracle client or (ODP .NET) is App folder. So it installs to "c:\app\Nagesh" and my friend "Rajesh" cannot use it.
    Filed under: How can Oracle with so much dollars do this to me?

    "Oracle Support here, my name is Nage--uh, Michael. How can I make today an Oracle Day for you?"

    "Yes, my friend Rajesh cannot make use from my Oracle client because it is installed to c:\app\Nagesh."

    "Well I'm sorry to hear that. We do hear this complaint a lot. If your friend legally changes his name to 'Nagesh', then he will be able to use the same Oracle client. Thank you and have a very Oracle Day. click"

    I see he's solved that specific problem before.

    Or else every Indian person is named Nagesh and all tech support is inevitably out-sourced to India. How dare you suggest something so racist?



  • @Ben L. said:

    I've never seen an 8" floppy, though.

    I take it you've never been to a U.S. Minuteman Launch Control Center..

    @Ben L. said:

    Aren't they usually hard when they get that long?

    Oh, yeah, the missileers also work with old technology.

    Really, the people who are up-in-arms about this are idiots. Next up we'll have Nanzi Pelosi saying "I can't believe they don't use iPads! We have to upgrade the whole infrastructure to run on the Google immediately!" And that's how human civilization was destroyed.



  • @Ben L. said:

    I've never seen an 8" floppy, though. Aren't they usually hard when they get that long?
    I knew this discussion was going to go that direction. It was just a matter of which deviantcommenter was going there first.



  • @HardwareGeek said:

    @Ben L. said:
    I've never seen an 8" floppy, though. Aren't they usually hard when they get that long?
    I knew this discussion was going to go that direction. It was just a matter of which deviantcommenter was going there first.

    It's history's fault for coming up a name that was literally one letter away from "eight-inch floppy dicks". Seriously, the first time somebody said "eight-inch floppy disk" out loud how were they not like "Oh.. oh no, that will never do.."? What names were rejected? "Large flaccid data doughnut"?

    This raises another question: do they call them 8" floppies in Europe? Or do they insist on using their own stupid units so it's like "923432.139080π√x micro-becquerel information puck"?



  • @morbiuswilters said:

    @flabdablet said:

    I'll take pity on Blakey at this point and raise the only advantage that the CSIDL mechanism genuinely has over hard coded paths: in theory they ought to let you move C:\Program Files to E:\Software, change the single registry setting that defines what CSIDL_PROGRAM_FILES resolves to, and have everything still work; CSIDL is in effect a late binding mechanism for a small but important subset of directories.

    Which is all well and good, but try doing that on an actual Windows box and see how far you get. Hint: not very far, because there are early-bound references to the underlying filesystem paths everywhere else in the registry.

    That's a bug with the software in question, though, not a gripe with the underlying convention.

    Considering that the "software in question" is written by Microsoft and ships as part of the OS, that's a difference that makes no difference. Seriously, have you ever tried to shift Program Files or Documents and Settings to somewhere else right after a clean installation of Windows? You need to edit lots of registry values to make it work, and good luck finding every last one; many of them use weirdly edited versions of the pathname prefixes.



  • @morbiuswilters said:

    @Ben L. said:
    @morbiuswilters said:
    @Nagesh said:
    That is reminding me, that default installation for oracle client or (ODP .NET) is App folder. So it installs to "c:\app\Nagesh" and my friend "Rajesh" cannot use it.
    Filed under: How can Oracle with so much dollars do this to me?

    "Oracle Support here, my name is Nage--uh, Michael. How can I make today an Oracle Day for you?"

    "Yes, my friend Rajesh cannot make use from my Oracle client because it is installed to c:\app\Nagesh."

    "Well I'm sorry to hear that. We do hear this complaint a lot. If your friend legally changes his name to 'Nagesh', then he will be able to use the same Oracle client. Thank you and have a very Oracle Day. click"

    I see he's solved that specific problem before.

    Or else every Indian person is named Nagesh and all tech support is inevitably out-sourced to India. How dare you suggest something so racist?

    www://en.wikipedia.org/wiki/Nagesh



  • @flabdablet said:

    @morbiuswilters said:
    @flabdablet said:

    I'll take pity on Blakey at this point and raise the only advantage that the CSIDL mechanism genuinely has over hard coded paths: in theory they ought to let you move C:\Program Files to E:\Software, change the single registry setting that defines what CSIDL_PROGRAM_FILES resolves to, and have everything still work; CSIDL is in effect a late binding mechanism for a small but important subset of directories.

    Which is all well and good, but try doing that on an actual Windows box and see how far you get. Hint: not very far, because there are early-bound references to the underlying filesystem paths everywhere else in the registry.

    That's a bug with the software in question, though, not a gripe with the underlying convention.

    Considering that the "software in question" is written by Microsoft and ships as part of the OS, that's a difference that makes no difference. Seriously, have you ever tried to shift Program Files or Documents and Settings to somewhere else right after a clean installation of Windows? You need to edit lots of registry values to make it work, and good luck finding every last one; many of them use weirdly edited versions of the pathname prefixes.

    I used to run Program Files on a separate drive, but it's been years. Nowadays my Windows usage has been mostly for testing in different browsers or using software that won't run on Linux, like Office.


Log in to reply