OSNews

In theory ISVs could also build their own live cd in asm and distribute their program that way, but would it be worth the effort?

Until there is an msi equivalent that can be installed across Linux distros without worry of some random library update breaking your program expect the current situation of Linux getting the shaft from ISVs to continue.

Telling ISVs that they're stoopid heads for not wanting to write a bunch of scripts for not only multiple distros but also multiple versions of those distros is insane. Don't forget they also have to support all those multiple distros and versions as well. It isn't like open source where you can just dump the program and then have all the distros figure it out. When customers ask why program whizbang doesn't work in distro version combination xyz you can't tell them to fix if themselves if they don't like it (which really means f off since very few can actually fix such problems).

You win ISVs over by creating an appealing and stable platform for them, not by telling them to figure it out a chaotic mess on their own.

The real problem is at the end of the day Linux is designed around open source applications. Most Linux advocates have no idea as to how many headaches you run into when you try to distribute proprietary GUI applications in Linux, especially compared to Windows or OSX. Until the distros get together and acknowledge that more needs to be done to bring in ISVs expect the Linux desktop to continue to flatline.

I don't expect much to change however, given the entrenched FOSS ideology, the ongoing window manager war and failure of the LSB.

During the Slashdot discussion of the announcement of the project, a point was brought up that this makes it easier for small programmers to distribute programs for multiple architectures.
The problem still arises, that the programmers must still compile their program for every architecture they want to release on.
The only improvement that a fat binary provides for a programmer is that their personal project website can list one raw package for their various programs, with a 3x bigger executable file sharing the same data, instead of releasing 3 separate packages with their own copy of the data. That's it.
Programmers still need to package their program for all of the different distributions, because fat binaries doesn't fix that at all. If a programmer wants to distribute a DEB and an RPM, they still need to create those manually. Fat binaries would only help for making one DEB and one RPM for all supported architectures, instead of one DEB and one RPM per architecture.

Big packages ship the data separately, so that'd be one binary for each arch, and one data package. That's why there are noarch rpm's and such stuff as well.

That's assuming that the data is not arch-specific, which is almost always, but not always. In such rare cases fat elf would be even fatter hehe

I can see a substantial benefit if we left the package manager behind... no longer would users be required to know whether they have an 386, 686, x86_64, ARM, or PPC installation: download and it'll work... at least, provided it was distributed as one. Right now, we have the package manager handling all of those distinctions; this would remove the vital dependencies on a specific package manager... at least, provided you have all the right versions of the libraries installed.