Page 4 of 4 FirstFirst ... 234
Results 31 to 36 of 36

Thread: The Direct3D 10/11 State Tracker Is Still Around

  1. #31

    Default

    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.

  2. #32
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,045

    Default

    Quote 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...

    Quote 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

    Quote 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?


    Quote 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...

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

    Quote 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

  3. #33
    Join Date
    Oct 2010
    Posts
    427

    Default

    Quote 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.

  4. #34

    Default

    Quote 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).

  5. #35

    Default

    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).

  6. #36
    Join Date
    Jan 2012
    Posts
    4

    Default

    What are the legal issues surrounding the distribution


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •