Ryan Gordon Is Fed Up, FatELF Is Likely Dead

[Svartalf]

They could be douchebags like Autodesk and only compile on Redhat and tell their paying customers to use Redhat when alien fails to convert the rpm to deb, everyone else can obviously get stuffed.

The current system is FUBAR for third party software, which is really the problem isn't it? A few people not liking a development model and an innate unwillingness to do anything that benefits the desktop/workstation with that model.

Here's a hint: Nothing in FatELF FIXES what you're talking to. And it's not FUBAR for development of commercial solutions. Unless you understand how to do it right, you won't get any further with FatELF as it doesn't resolve the need to build custom, vetted runtimes to go with your application if you want to make it work cross-distribution- not that you can't do that most of the time without them anyhow. FatELF just bundles it up in a nifty package that can just as easily be done with shell scripts, etc. It's not difficult like people keep saying it is. Those that are doing it like you say like Autodesk don't know what to do to do it right.

1) Proprietary stuff probably ought to go into /opt.
2) If you put it into /opt with a proper launcher script, it works.
3) If you put a link elsewhere (like /bin or /usr/bin...) for the /opt/<foo>/bin drop, it'll work as expected.

Not at all hard. Done right, you can have "universal" RPMs and DEBs along with an installer for anything else. Seriously.

FatELF doesn't add to this, doesn't remove the need to do this.

[movieman]

The current system is FUBAR for third party software, which is really the problem isn't it? A few people not liking a development model and an innate unwillingness to do anything that benefits the desktop/workstation with that model.

Indeed. If third-party developers really cared about their software still running in three years when we've all abandoned X86 for ARM (or whatever) they'd build a repository for their users to download from rather than try to impose a Windows 'ship and forget' model onto Linux... then the problem is solved without making substantial and probably patent-restricted changes to the base operating system.

Personally I don't think that FatELF is such a bad idea, but given that the whole concept of downloading random software from random sites and installing using random scripts is already a bad idea, I don't see that it really helps. Once you get used to installing with a package manager, having to manually install any kind of software just seems so 20th century.

[yogi_berra]

And it's not FUBAR for development of commercial solutions.

Which explains the vast array of consumer oriented closed source software aimed at the platform.

Take a step back and look at what you are expecting people to do from the viewpoint of someone that is not familiar with the platform, it is a convoluted process that you just happen to be familiar and comfortable with.

[movieman]

Which explains the vast array of consumer oriented closed source software aimed at the platform.

I'm still trying to figure out why I need all this 'consumer oriented closed source software'. The only closed-source software I have on my non-embedded Linux boxes are a couple of drivers and some Windows software that runs in Wine, which I don't really use anymore because I found open source methods of doing the same things.

If you want to put commercial games on Linux, then you'd be much better off setting up a 'package manager' system like Steam than demanding numerous changes so that you can pack multiple versions into one binary that probably won't work in a couple of years anyway.

One of the worst things about Windows is that all this 'consumer oriented closed source software' requires you to download it from random web sites, trust that it's not spyware, run some random install program which may well not even work, and then installs yet another 'update' service so that it can phone home every time you boot up in order to see whether there's a new version, thereby ensuring that once you've installed a dozen of these programs there are so many 'updaters' that your system takes fifteen minutes to log in. Personally I would much rather never see a commercial game on Linux than have to put up with that nonsense.

[some-guy]

IMO, if two things were possible with FatELF, it would be successful:
* Combining two ELF binaries into one FatELF.
* Splitting a FatELF into separate ELF binaries.

If those two were possible, then someone could install a 32bit version of libc and it would merge with the 64bit version of libc. Also proprietary software could be distributed as one FatELF binary, then stripped into a ELF that worked on the system.

[Svartalf]

Which explains the vast array of consumer oriented closed source software aimed at the platform.

Take a step back and look at what you are expecting people to do from the viewpoint of someone that is not familiar with the platform, it is a convoluted process that you just happen to be familiar and comfortable with.

And not a single thing about FatELF fixes that "convoluted process". Seriously. And it's not like making games on Windows is any less of a "convoluted process"- it's just different. VisualC++ doesn't magically make the problems all go away on Windows either. Anyone that tells you this is selling something or sadly misinformed.

[smitty3268]

From the perspective of a developer (note my tag... ) it doesn't make it much more elegant than the current state of affairs. Seriously.

I'll take your word for it, then.

If it were not needing quite so many alterations to everything in creation in the infrastructure, I can see where it MIGHT make some things a "little cleaner" to some developers.

That's what I was getting at. I think there's no way the very, very, minor benefit is worth even a fraction of the changes that would be required to implement it, but I suppose I can see how some might find it appealing.

But it doesn't resolve that you still have to MAKE those binaries for all the platforms and resolve inconsistencies between distributions- it changes a lot for no appreciable gain, contrary to the claims of others in this thread.

Oh yes. Too bad the LSB never really fixed things the way it was supposed to, because a standard base that developers can count on across distros is the only real way to improve this.

[misiu_mp]

Which explains the vast array of consumer oriented closed source software aimed at the platform.

Take a step back and look at what you are expecting people to do from the viewpoint of someone that is not familiar with the platform, it is a convoluted process that you just happen to be familiar and comfortable with.

Im not a game or a 'third party' developer and never deployed anything this way, but I also think using a directory tree + starter/wrapper script bundle is not fubar but rather simple and straight-forward. Of course you need someone familiar with a platform if you want to release for it, but it really doesn't take a lot. There are several applications released this way and others can follow if they want and know about it.

The problem is there is a lot of FUD relating to it which is used as an nail to the 'low market share - low ROI' coffin. I think the real reason for lack of closed apps is that the programs are so tightly entangled in windows stuff (such as UI or DirectX) and the executives so ignorant that they dismiss the investment in porting it given the near-non-existing (as they see it) audience. Plus there are cases of people submerged in the 'on linux you have to give your stuff away for free' -cloud of ignorance.

Besides, when it comes to games an argument I hear often is that DirectX is a complete game-development platform and thus much easier to create games with, whereas OpenGl is more rudimentary graphics-only library and requires combination with other libraries.
Maybe Svartalf or some other game developer could mention how SDL relates to this, as a side-note.

[stevenaaus]

Loose marbles

Only read half this huge thread, but can't resist my $0.02...
Ryan must have rocks in his head to think this will work. Apart from the obvious "Linux runs on every architecture", while OSX supported two and a half; the dynamic nature of Linux, and it's system library structure, means simple binary support for the x86 platform ~alone~, is almost unworkable.

The sad news is Linux _has_ a default installer, and it's called auto-config.

Ryan should stick to fighting for Linux ports, and running Icculus , as both these projects need all the help they can get anyway :> Check out http://icculus.org/. It's pretty fitting to see Fat Elf sitting alongside a heap of other half-baked projects.

[misiu_mp]

Script checks for x86-64, system reports back x86_64, fail

Which would be handled by the fatELF supporting libraries that are maintained by the distro.

For one: I would like to know it it EVER happened that any kernel anytime provided x86-64 instead of x86_64 (otherwise checking for x86-64 in the script is a simple mistake which could be alleviated by an automatic script generator).

If it did, how about we make a robust platform-identification either by sticking to one way of writing x86_64 as returned by uname or by providing separate tools (or api's) like is_x86, is_64bit, is_x86_64 or even one is_arch tool, that takes a string argument but can be flexible about it on top of documented specification.