Announcement

Collapse
No announcement yet.

The Direct3D 10/11 State Tracker Is Still Around

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    I don't really see the issue here. If you're going to distribute a 3rd party closed-source app you might as well make a statically-linked build (to the extent that's possible) that installs somewhere in ~/, and maybe a shortcut or two. I certainly don't want 3rd party stuff asking for superuser privileges and spreading their stuff all over the filesystem like they do on Windows. Uninstalling should be quite trivial then.

    In fact, I regularly go about building and installing FOSS software in a prefix under my home dir, stuff like latest Git versions.

    Comment


    • #32
      Originally posted by elanthis View Post
      They work okay. They're fragile (try installing one of those games three years from now, let's see what happens). They have a much lower chance of working if you move off the main distros.
      Like the original doom3 installer or even the return to castle wolfenstein installer? Still work on my 64 bit archlinux.

      In the humble bundle installers there was sometimes indeed the problem that there were not all 32 bit libraries there needed for the installer to run, but that's a packaging problem that should be easily avoidable...

      Originally posted by elanthis View Post
      ** Admittedly, doing things the Linux way and asking the OS to install them would be better, but last I checked MojoSetup/Loki_setup could not do that, and for good reason since not every distro is guaranteed to have every library the game might need, so Linux games take a step backward from even Windows' DLL hell and statically link or "locally bundle" libraries that otherwise have stable ABIs and belong on the system.
      On the other hand KISS is not that bad. How often do you install a windows game and then there's still d3dx9_32.dll missing because the oh so sophisticated installer failed to install it?
      www.google.com/search?q=%2Bgame+%2B"dll+not+found"+-"wine"
      About 2,910,000 results

      Originally posted by elanthis View Post
      I get so upset about the Linux installer topic in particular because it's (almost trivially) FIXABLE. It's just the distro engineers having their damn heads lodged so far up their asses that they can lick the lining of their own stomaches. Bunch of political shenanigans, intense NIH syndrome, and fear-induced bullcrap. I'm not even talking about just hitting parity with Windows, but it could be done so much _better_ than Windows if only the distros weren't in the way.
      Almost trivially? How?
      Take Archlinux. They don't feel like packaging ancient libraries. There's only one version of libjpeg: The recent one. Only one version of libpng, etc.
      How would you fix it there?


      Originally posted by elanthis View Post
      And why have it installed at all? Simply unpacking and putting a .desktop file somewhere ought to be enaugh...
      You're right. That sounds so much easier than clicking an Install icon and having it Just Work all by itself. Why didn't I think of that?
      Why should an installer do more?
      Doubleclick it,
      ask whether the install should be for everybody and say that in this case the root password is needed or just for the user,
      pop up a filechooser with /opt/gamename/ or $HOME/games/<gamename> preset, copy that stuff there,
      place a .desktop file in /usr/share/applications or somewhere accordingly in the homedirectory and ready.

      But I don't see an easy fix for libraries. Is there a system where this is not a mess? You end up either maintaining ancient libraries and everything they depend on forever or at some point you break backwards compatibility...

      Originally posted by elanthis View Post
      work around bad UIs
      Originally posted by elanthis View Post
      fix obvious bugs
      Well, I think I found the problem.

      Originally posted by elanthis View Post
      Obligatory XKCD comic:
      That in fact is extremely annoying.
      Then you do "xset s off" and "xset -dpms" and it doesn't even remember those setting over suspend to ram. *grrr*
      But to be fair: All players I have used have successfully disabled that behaviour. Except for flash. But that is obviously not intended to work correctly anyway...
      https://bugbase.adobe.com/index.cfm?...bug&id=3002806
      https://bugbase.adobe.com/index.cfm?...bug&id=2908816

      Comment


      • #33
        Originally posted by Eduard Munteanu View Post
        I don't really see the issue here. If you're going to distribute a 3rd party closed-source app you might as well make a statically-linked build (to the extent that's possible) that installs somewhere in ~/, and maybe a shortcut or two.
        Eh, that's fine for a single-user machine, but I think installing in a dedicated "users"-group read/write-able directory would be better...but then you have the problem of a (basically) world writable directory which contains executables which are likely to be executed. The safe solution to that might be to limit read/write/execute access for all code executed from that directory to it's own directory and a shared data (game-saves, scores, etc.) directory. Then the only possible security hole would be shared libraries existing outside of this "sandbox"....

        ...but I fall off topic.

        Comment


        • #34
          Originally posted by Nobu View Post
          Eh, that's fine for a single-user machine, but I think installing in a dedicated "users"-group read/write-able directory would be better...but then you have the problem of a (basically) world writable directory which contains executables which are likely to be executed. The safe solution to that might be to limit read/write/execute access for all code executed from that directory to it's own directory and a shared data (game-saves, scores, etc.) directory. Then the only possible security hole would be shared libraries existing outside of this "sandbox"....
          I understand you want to avoid having different installations of the same app, though that may or may not be a problem. The issue with the approach you described is letting unprivileged users install stuff globally. You don't need or want that. You also don't need shared state, as saves and scores naturally belong to ~/.<app_name>.

          Instead you can have the sysadmin install the application globally, but you also want that process to involve no 3rd party executable code. I'm thinking the distro could provide a general installation script that simply takes a compressed archive, unpacks it (perhaps registering it with the package manager, or in a self-contained directory), mangles permissions and sets up the paths properly for normal users. This part is distro-specific anyway.

          That sort of stuff might or might not exist already, I'm not sure, but one problem I see is convincing the vendors to stop supplying installers and asking you to run them with root privileges (and hoping they don't do anything stupid or downright evil). A simple compressed archive might be enough in many cases, although I imagine the installation script could sandbox an actual installer and move the resulting files where they belong (similar to what Gentoo does).

          Comment


          • #35
            Isn't Open Build Service solve "create package" problem for developers and pubslihers? (It may be installed to their own server to build packages with proprietary software).

            Comment


            • #36
              What are the legal issues surrounding the distribution

              Comment

              Working...
              X