10 ms·

Seems unnecessarily complicated. A script like this gets you 95% of the way there: mkdir AppDir mkdir AppDir/bin mkdir AppDir/data cp $INSTALLDIR/a

Seems unnecessarily complicated. A script like this gets you 95% of the way there: mkdir AppDir mkdir AppDir/bin mkdir AppDir/data cp $INSTALLDIR/app AppDir/bin cp -r $INSTALLDIR/data AppDir cp `ldd AppDir/bin/app | grep -o '\W/[^ ]*'` AppDir/bin cat << "EOF" > AppDir/app #!/bin/bash SCRIPT_PATH=$(dirname $(readlink -f $0)) $SCRIPT_PATH/bin/ld-*.so.2 --library-path $SCRIPT_PATH/bin $SCRIPT_PATH/bin/app $* EOF (Sometimes I wonder if people make a big mystery of Linux app distribution on purpose, to discourage distribution outside of proper, secure channels.)

matsemann 11y ago
Everything seem complicated when you dont properly understand the problem.
- CharlesW 11y ago
  That's a really interesting thought, because everything also seems simple when you don't properly understand the problem. ("Let Apple open the damn back door, let the FBI know what's on the phone, then close it again. This isn't difficult." — Piers Morgan)
  - arnorhs 11y ago
    you two are discussing separate sides of the same coin. or to clarify: people with a naive understanding of a problem will always feel like people who don't design solutions that are overly complex. people with a deeper understanding of a problem will always feel like people who don't design solutions that are overly simplistic.
    - slavik81 11y ago
      I've successfully refactored way too much code that was needlessly complex to agree. Better understanding of a problem frequently leads to simpler solutions. It doesn't always lead to more complexity.
      - arnorhs 11y ago
        Whether people who are bad at programming, or at least inexperienced, write overly complicated code or not has got nothing to do with what I said. Except that there's word-choice correlation.
probonopd 11y ago
Yes, except that you might want to be a bit more selective in which parts you use from the base system and which parts you want to bundle - some people might not want to have e.g. glibc in each app bundle. This is where it starts to become a little more complicated than the above, see https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages https://github.com/probonopd/AppImageKit/wiki/Creating-AppIm...
- lukaslalinsky 11y ago
  If you don't have glibc in each app bundle, it won't run everywhere. Different distros have different versions of glibc and it's very easy to end up in a situation where you use some symbol that's not defined in the system one.
  - probonopd 11y ago
    Which is why you want to build on a system that is using an older version of glibc than the systems you want to run your software on. Assuming that glibc does't break backward compatibility, which it really shouldn't (and in practice, rarely ever did). Or use https://github.com/probonopd/AppImageKit/tree/master/LibcWrapGenerator https://github.com/probonopd/AppImageKit/tree/master/LibcWra...
  - inopinatus 11y ago
    This makes a mockery of shared libraries. The technical debt will accrue and run unfathomably deep. Security failures due to currency issues are simply the most obvious. The insoluble mystery bugs of mismatched dependencies will plague application developers that choose this distribution strategy.
    - _hyn3 11y ago
      Yay for hyperbole ;) Shared libraries are most useful when matched within a specific distribution's package/version chain. Tying a third-party distributed package to a given shared library, on the other hand, is less helpful than just supplying the expected, tested, and supported library upfront and still let knowledgeable operators do what they will on their chosen platform. No technical debt is accrued if the libs are truly interchangeable anyway, but especially if they are not, this stands a better shot at fixing it.
deleted 11y ago
[deleted]
Htsthbjig 11y ago
Ohh, yeah, so you force everybody to understand the command line when something does not work as expected. 95% of the way means it is not finished. When I buy a car the seller better does not say that the car works 95% of the time. Installing something in millions of computers is hard. We do it. Being able to install something on one computer with a person that is a computer programmer with 20 years experience with the command line is completely different from making it to just work for millions of people. Apple actually makes it work for millions of people in a very simple and elegant way. As a geek I could use homebrew or any other system in Linux if I want, but Apple's system works great for most people.
sillysaurus3 11y ago
I think you meant "$@" rather than $* (The quotes in "$@" are important.) Also, your script will fall over if any of the paths have spaces in them, such as INSTALLDIR. You should use lowercase for variable names like SCRIPT_PATH. Uppercase is for exported variables. readlink -f $0 breaks on OS X. You must do both readlink -f $0 and readlink $0 in order for it to work everywhere. Shell scripting isn't easy. It took a year to understand these nuances to the point that they're second-nature, and I'm still discovering new ones. Anything that improves this situation would be a welcome change in my opinion. EDIT: cat<<'EOF' is necessary here. cat<<"EOF" will interpolate variables.
- Pyxl101 11y ago
  To elaborate, the GP should have put quotes around command arguments that included variables. For example: cp $INSTALLDIR/app AppDir/bin Should be: cp "$INSTALLDIR/app" AppDir/bin
- xorcist 11y ago
  > Shell scripting isn't easy. It took a year to understand That might make it seem like too hard for some people. It's really not that bad. These particular mistakes were beginner's mistakes. But it is tricky! I usually try to tell people to avoid writing shell scripts until you've at least read the "Bash Beginners Guide" or something similar. It's comparably short (remember, you're learning a new language and an arcane one at that) but at least lets you avoid the easy traps. Also, indent and comment. Surprisingly many people seem to think hygiene is somehow less important outside their main language. On a side note, what's up with not reading manuals these days? When I am tasked with something new, no matter how trivial, my first step is to at least skim the manual get a feel for what the problem domain looks like and how you are supposed to wield the tool I am about to use. Turns out nobody does that anymore. Zero, out of over a dozen people in my closest (java, web) team have read the documentation for the product we build on. I find it unprofessional, but I realize I'm the strange one and it's probably just me getting older.
  - ZenPsycho 11y ago
    > On a side note, what's up with not reading manuals these days? The difficulty of finding manuals, and when you do, they're badly written in such a way that they assume all sorts of contextual knowledge based around the sorts of problems the author of the software was trying to solve in 1986 or whatever year. Manual writing is at least 1000x more difficult than bash scripting, because you have no way of knowing up front how the target "machine" is going to interpret your "script". And of course that's all assuming a manual even exists at all.
ldamerow 11y ago
What happens if the app forks a child process? Chrome, for example, starts nacl_helper and chrome-sandbox. Is there a straightforward way to get those children to inherit the dynamic loader and library path?
lisivka 11y ago
Don't steal my code, please. Don't bundle my open library with your proprietary app without my written permission.
abrookewood 11y ago
That depends on your target user. I can't imagine asking my parents to run your script (even if it was packaged up as a single file), but I'd like to think that they could run something like AppImage without too much problem.
draw_down 11y ago
> A script like this gets you 95% of the way there Ohhh, but that five percent!

matsemann 11y ago

Everything seem complicated when you dont properly understand the problem.

CharlesW 11y ago
That's a really interesting thought, because everything also seems simple when you don't properly understand the problem. ("Let Apple open the damn back door, let the FBI know what's on the phone, then close it again. This isn't difficult." — Piers Morgan)
- arnorhs 11y ago
  you two are discussing separate sides of the same coin. or to clarify: people with a naive understanding of a problem will always feel like people who don't design solutions that are overly complex. people with a deeper understanding of a problem will always feel like people who don't design solutions that are overly simplistic.
  - slavik81 11y ago
    I've successfully refactored way too much code that was needlessly complex to agree. Better understanding of a problem frequently leads to simpler solutions. It doesn't always lead to more complexity.
    - arnorhs 11y ago
      Whether people who are bad at programming, or at least inexperienced, write overly complicated code or not has got nothing to do with what I said. Except that there's word-choice correlation.

probonopd 11y ago

Yes, except that you might want to be a bit more selective in which parts you use from the base system and which parts you want to bundle - some people might not want to have e.g. glibc in each app bundle. This is where it starts to become a little more complicated than the above, see https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages https://github.com/probonopd/AppImageKit/wiki/Creating-AppIm...

lukaslalinsky 11y ago
If you don't have glibc in each app bundle, it won't run everywhere. Different distros have different versions of glibc and it's very easy to end up in a situation where you use some symbol that's not defined in the system one.
- probonopd 11y ago
  Which is why you want to build on a system that is using an older version of glibc than the systems you want to run your software on. Assuming that glibc does't break backward compatibility, which it really shouldn't (and in practice, rarely ever did). Or use https://github.com/probonopd/AppImageKit/tree/master/LibcWrapGenerator https://github.com/probonopd/AppImageKit/tree/master/LibcWra...
- inopinatus 11y ago
  This makes a mockery of shared libraries. The technical debt will accrue and run unfathomably deep. Security failures due to currency issues are simply the most obvious. The insoluble mystery bugs of mismatched dependencies will plague application developers that choose this distribution strategy.
  - _hyn3 11y ago
    Yay for hyperbole ;) Shared libraries are most useful when matched within a specific distribution's package/version chain. Tying a third-party distributed package to a given shared library, on the other hand, is less helpful than just supplying the expected, tested, and supported library upfront and still let knowledgeable operators do what they will on their chosen platform. No technical debt is accrued if the libs are truly interchangeable anyway, but especially if they are not, this stands a better shot at fixing it.

deleted 11y ago

[deleted]

Htsthbjig 11y ago

Ohh, yeah, so you force everybody to understand the command line when something does not work as expected. 95% of the way means it is not finished. When I buy a car the seller better does not say that the car works 95% of the time. Installing something in millions of computers is hard. We do it. Being able to install something on one computer with a person that is a computer programmer with 20 years experience with the command line is completely different from making it to just work for millions of people. Apple actually makes it work for millions of people in a very simple and elegant way. As a geek I could use homebrew or any other system in Linux if I want, but Apple's system works great for most people.

sillysaurus3 11y ago

I think you meant "$@" rather than $* (The quotes in "$@" are important.) Also, your script will fall over if any of the paths have spaces in them, such as INSTALLDIR. You should use lowercase for variable names like SCRIPT_PATH. Uppercase is for exported variables. readlink -f $0 breaks on OS X. You must do both readlink -f $0 and readlink $0 in order for it to work everywhere. Shell scripting isn't easy. It took a year to understand these nuances to the point that they're second-nature, and I'm still discovering new ones. Anything that improves this situation would be a welcome change in my opinion. EDIT: cat<<'EOF' is necessary here. cat<<"EOF" will interpolate variables.

Pyxl101 11y ago
To elaborate, the GP should have put quotes around command arguments that included variables. For example: cp $INSTALLDIR/app AppDir/bin Should be: cp "$INSTALLDIR/app" AppDir/bin
xorcist 11y ago
> Shell scripting isn't easy. It took a year to understand That might make it seem like too hard for some people. It's really not that bad. These particular mistakes were beginner's mistakes. But it is tricky! I usually try to tell people to avoid writing shell scripts until you've at least read the "Bash Beginners Guide" or something similar. It's comparably short (remember, you're learning a new language and an arcane one at that) but at least lets you avoid the easy traps. Also, indent and comment. Surprisingly many people seem to think hygiene is somehow less important outside their main language. On a side note, what's up with not reading manuals these days? When I am tasked with something new, no matter how trivial, my first step is to at least skim the manual get a feel for what the problem domain looks like and how you are supposed to wield the tool I am about to use. Turns out nobody does that anymore. Zero, out of over a dozen people in my closest (java, web) team have read the documentation for the product we build on. I find it unprofessional, but I realize I'm the strange one and it's probably just me getting older.
- ZenPsycho 11y ago
  > On a side note, what's up with not reading manuals these days? The difficulty of finding manuals, and when you do, they're badly written in such a way that they assume all sorts of contextual knowledge based around the sorts of problems the author of the software was trying to solve in 1986 or whatever year. Manual writing is at least 1000x more difficult than bash scripting, because you have no way of knowing up front how the target "machine" is going to interpret your "script". And of course that's all assuming a manual even exists at all.

ldamerow 11y ago

What happens if the app forks a child process? Chrome, for example, starts nacl_helper and chrome-sandbox. Is there a straightforward way to get those children to inherit the dynamic loader and library path?

lisivka 11y ago

Don't steal my code, please. Don't bundle my open library with your proprietary app without my written permission.

abrookewood 11y ago

That depends on your target user. I can't imagine asking my parents to run your script (even if it was packaged up as a single file), but I'd like to think that they could run something like AppImage without too much problem.

draw_down 11y ago

> A script like this gets you 95% of the way there Ohhh, but that five percent!