paste-and-run apps for Linux and Windows

On various Mac vs Windows/Linux threads on /g/ Ive pointed out that the major advantage that Mac OSX holds over Windows and Linux is that to run a program you just paste it on your harddrive and click it and it runs. And people counter on these threads that its *possible* to do this on Windows and Linux also. So if its possible, why hasnt any Linux distro done it since the #1 problem on Linux is dependencies. Doesnt anyone here agree that relying on repo maintainers to sort out these dependency problems is not a professional solution which is why any serious Linux user has to use "compile everything" distros. So my question again, if its possible to make apps that just run without the need to compile or install, then why hasnt anyone done it?

the #1 problem on Linux is dependencies
no

/g/

Terrible!

>>1
if its possible to make apps that just run without the need to compile or install, then why hasnt anyone done it?
Because such an app would
1) take a shitload of space, since you would need to accommodate all dependencies
2) either a. the app would use the libraries/w/e packaged within itself, so that it would be impossible to update one of the dependencies without updating the whole app, additionally various apps would end up using different (sometimes conflicting) versions of the dependencies; b. the app would extract and install in the system the dependencies which aren't installed, and this would be bad because you'd end up with 10 things installed when you only want to run one
3) software licenses

I believe that the repo maintainers should be responsible for maintaining dependencies. They do a good job at it.

If you're a serious "Linux user", compiling "bleeding edge" software and tracking down dependencies shouldn't be too much of a hassle.

Trolling trolls gonna troll.

Static linking is considered passe in Lunix world(despite 1TB hardrives).
 Smartlinking all apps with static libs should make any app self-contained and free of "dependency". It wouldn't cost much for the benefit of distributing a complete single executable which works "Out of The Box" and requires Zero maintenance.

>>1
I agree with everything you said, except for it being the #1 problem.

The problem of linking is exactly what >>9 is saying; there's a whole culture around dynamic linking, and static linking is for some reason a serious taboo in the Linux world.

Maybe it's because we have all these fancy package managers, the package maintainers feel they should use them, so static linking is considered some sort of waste. Just set up the dependencies to your package and it all works magically! Except when it doesn't, and everything breaks horribly.

The argument of having to recompile is so completely fucking backwards. When a closed-source app statically links and a library needs a bug fix, you need to wait for the company to update it themselves. When an open-source app statically links, the package maintainer just needs to recompile the source for the apps that link it. This is something that could be done automatically! Why not move some of this fancy package management software onto the servers?

>>5
1) take a shitload of space, since you would need to accommodate all dependencies
Somehow Macs don't have this problem...

2) either a. the app would use the libraries/w/e packaged within itself, so that it would be impossible to update one of the dependencies without updating the whole app, additionally various apps would end up using different (sometimes conflicting) versions of the dependencies; b. the app would extract and install in the system the dependencies which aren't installed, and this would be bad because you'd end up with 10 things installed when you only want to run one
Somehow Macs don't have this problem...

3) software licenses
Somehow Macs don't have this problem.

(Full disclaimer: I fucking hate Macs almost as much as I hate Windows, and I use Ubanto as a necessary evil.)

>>10
because the Mac software ecosystem is small compared to the other two behemoths

>>9
IHBT, but
1. Programs foo and bar use libbaz, work fine but for some slightly crippling bug qux
2. foo's maintainers decide to statically link libbaz for portability
3. Maintainers for both foo and bar go on holiday together, die of malaria in a hurricane
4. libbaz has a major update that fixes qux
5. foo remains crippled but bar begins to gain users exponentially due to its new-found perfection.
6. bar's massive popularity renders it self-maintaining due to user patch submissions
7. bar gains enough money from paypal donations from satisfied users that their maintainers get an actual funeral
8. foo becomes vaporware in weeks and their maintainers are left in Scotland to become one with the peat bogs in which they lost their lives.

>3. Maintainers for both foo and bar go on holiday together, die of malaria in a hurricane
SO is foo and bar both closed-source with no possibility of forking?
Or is switching to dynamic linking TOO HARD FOR YOU(single gcc link option change, about 4-7 keystrokes)?

>>13
Yes, foo was maintained by the single EXPERT PROGRAMMER at an ENTERPRISE corporation.

>>12
I'm confused. How can the maintainers of foo be left in peat bogs in Scotland if they died of malaria in a hurricane?

>>13
Nobody wanted to fork them because of qux.

>>15

Have you ever been to Scotland?

>>17
Yes, I'm posting from there now

The foo maintainers become undead vampires and roam the streets looking for freetard-filled basements.

I love static linking!
Loading the same libraries dozens of times into RAM so my system starts swapping is just what I need!

22 Name: Anonymous 2011-02-18 13:42

<-- check 'em dubzNewer Posts

---

Don't change these.

Name:		Email:
Entire Thread Thread List

All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -