Ryan Gordon Is Fed Up, FatELF Is Likely Dead

[deanjo]

I think Ryan would be at the top of the list. I strongly doubt that he's the cause of the "delay" we've seen on UT3.

Of course that is all speculation as well.

[Svartalf]

IMHO, Kernel devs are usually big boys working for good money, they don't really give a crap about you or anybody else.

Not QUITE. However, they don't abide by what they deem as inefficiency or what they deem as inelegant- or provides a solution to a problem that's nonexistent or almost so. The big stopping block with FatELF is that it really didn't solve the problem we face the way Ryan believed it would.

The main reason you don't have 64-bit binaries is not a packaging reason (though that doesn't help...)- it's that you have to build the binaries for the differing architectures, and FatELF doesn't fix that problem.

It doesn't resolve issues within your code for endianness. It doesn't resolve issues within your code for byte alignment. It doesn't resolve the issues from poorly written code that presumes a void pointer is equivalent to int- and you have issues with that going to a 64-bit world.

All FatELF did was allow you to make universal binaries...after you resolve all the other problems. The ones that actually stymie most commercial vendors from doing anything in something other than X86-32.

And, knowing what I know about the kernel crowd and of Ulrich...heh...I saw this little turn of events coming from a mile away. Sorry to see him disillusioned, but it happens...Lord only knows, I've been there a time or two for similar reasons myself.

This is not to say that it's not a nice idea, mind...it's just that the resistance is going to be high on it and that it doesn't resolve a few crucial issues that need to be sorted out "better" before solving the particular problem he tried to solve.

[L33F3R]

hes a fairly household name in the linux community. This is surprising.

[Svartalf]

Of course that is all speculation as well.

Considering he's watching and pointing Twitter comments to this thread...heh...I'd say I'm probably in the ballpark at this point. But, yeah, it's idle speculation at that.

[SlickMcRunfast]

Can't these patches be submitted to distros? If all the main distros accept the patches then main no longer matters. I support the fatElf.

[RahulSundaram]

Can't these patches be submitted to distros? If all the main distros accept the patches then main no longer matters. I support the fatElf.

It doesn't work that way. Many mainstream distributions won't agree to patch many core components in a big way without upstream agreement. Fedora certainly won't take it.

https://fedoraproject.org/wiki/Stayi...tream_projects

[Yuma]

First they piss off Con, now they piss of Ryan. Can it get any more clearer that they simply don't give a rats ass about making things simpler and improving the end user experience?

Cart before horse. You would first have to clearly demonstrate that this makes things simpler and improves the end user experience.

From my POV it doesn't make things simpler... this needs changes up and down the software stack (kernel, loader, C library, dozens of other things that touch ELF) all to accomplish something that can be accomplished at a much higher level (the package) in a much simpler way. If you expect all of the people that are affected by this to be on board you better have a rock solid argument for it.

Second, does this really improve the end user experience? Where are the hordes of people being burned by this? And why should someone who will not benefit from this squander his disk space on it? I have a hard time believing that the average user will ever need this kind of arch-independence at all, let alone at runtime.

[RahulSundaram]

.deb already supports multiple archs in a single file, doesn't it?

There is multi-lib support in .rpm format but not the .deb format. In general, .rpm format has more metadata information including licensing and has other features like delta RPM and automatic creation of debug info packages. The tools surrounding the format has been weaker in the past but the average end user it shouldn't make much of a difference anymore.

[deanjo]

Cart before horse. You would first have to clearly demonstrate that this makes things simpler and improves the end user experience.

From my POV it doesn't make things simpler... this needs changes up and down the software stack (kernel, loader, C library, dozens of other things that touch ELF) all to accomplish something that can be accomplished at a much higher level (the package) in a much simpler way. If you expect all of the people that are affected by this to be on board you better have a rock solid argument for it.

Second, does this really improve the end user experience? Where are the hordes of people being burned by this? And why should someone who will not benefit from this squander his disk space on it? I have a hard time believing that the average user will ever need this kind of arch-independence at all, let alone at runtime.

Pretty much any mac user that has used universal binaries would disagree with you.

[linuxhansl]

I don't quite get who really needs FatELF. Will we also have FatPACKAGE then, which packs an RPM,DPKG,etc in one package?

It looks to me like a solution in search for a problem.

From a political viewpoint it would just promote more binary only software... You mileage may vary here, though.