Hacker News Reader

Comment by linksnapzz | Hacker News Reader

This is a nice paper, and I do appreciate the authors' efforts. I fight with this stuff daily.

But...this caught my eye:

"While it’s a pleasant thought experiment to imagine a world where we do not require backwards compatibility with estab- lished loaders, the state of the practice is that we must work within the limitations of ELF and the System V ABI model."

In light of the current HPC orthopraxis, I wonder if there might not be real value in seeing how far towards reality one could drag the thought experiment of not having to depend on that backwards compatibility. E.G. what sort of work abandoning the ELF/SysV ABI model might require.

Dijkstra said something once about the problems of the real world being the ones that you're left with when you refuse to apply their effective solutions.

View on HN

I tried to remove the expectation that supercomputer applications would load their libraries dynamically and that became one of the single most hated aspects of that product line

people really hate having their expectations violated - even if its an expectation of a fork in the eye

Do tell; which product was this?

cray xt3. my understanding that in later versions Cray shipped compute node linux with some solution for maintaining the .so file on the nodes

Interesting! I'd never touched a Catamount/SUNMOS system; didn't know that static everything was an option there, although some of my friends did work on those. Do you suppose the friction was due to it not being how their local workstation/previous system worked?

yeah, mostly just 'what the hell'. I pretty sure it really didn't get in anyone's way - all the libraries were installed on the front end. it wasn't an option - we didn't support dynamic linking there

I never worked with the XT3, but I’ve worked with others with similar limitations. Many of our projects prefer static linking, but at any given time they tend to have to run on several platforms. As of today, they have to run on at least two where one won’t load gpu components in libraries correctly if they are statically linked, and one where it won’t if they’re dynamically linked. Forcing projects into one model or the other makes the smaller requirements on other platforms much harder to deal with, even if the requirement aligns with the project’s preference.

Another author here (Tom Scogland). We seriously talked about it, and are exploring some other loading models as part of subsequent work. The real trick is that this has all been neglected and effectively set for so many decades that if we do manage to find something better, it will take convincing some of the most conservative open source maintainers and code owners in existence to update the loader and c standard library to roll it out in a way most users would be able to leverage. We’re trying, and think we’ve found some really preferable alternatives and options, so here’s hoping.

Neat! I look forward to hearing about yr. work!

Reply on news.ycombinator.com