<div dir="ltr"><div>I just realised...  I will now need an account on the IBM Support Site, a SiteID AND an Entitlement to file bugs on any Redhat packages.</div><div><br></div><div>For those who don't know the system - every site (University, company, Laboratory etc) has a SiteID number.</div><div>You had better know that number - and if someone leaves or retires you had BETTER get than number from them.</div><div>(I handled a support case once where a customer had someone retire - and not pass on the site ID- we had to get a high up in IBM UK invoplved);.</div><div><br></div><div>One person on site then has the ability to allow others on the site to open support issues.</div><div>You just cannot decide to open a support issue -you must have the rights to ask for support for that product.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 29 Oct 2018 at 16:55, Joe Landman <<a href="mailto:joe.landman@gmail.com">joe.landman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 10/29/18 12:44 PM, David Mathog wrote:<br>
<br>
[...]<br>
<br>
> It turns out that getting up to date compilers and libraries has become<br>
>> quite important for those working on large distributed code bases.<br>
><br>
> Libraries are harder.  Try to build a newer one than ships with CentOS <br>
> and it is not uncommon to end up having to build many other libraries <br>
> (recursive dependencies) or to hit a brick wall when a kernel <br>
> dependency surfaces.<br>
<br>
<br>
This was my point about building things in a different tree.  I do this <br>
with tools I use in <a href="https://github.com/joelandman/nlytiq-base" rel="noreferrer" target="_blank">https://github.com/joelandman/nlytiq-base</a> , which <br>
gives me a consistent set of tools regardless of the platform.<br>
<br>
Unfortunately, some of the software integrates Conda, which makes it <br>
actually harder to integrate what you need.  Julia, for all its <br>
benefits, is actually hard to build packages for such that they don't <br>
use Conda.<br>
<br>
<br>
> In biology apps of late there is a distressing tendency for software <br>
> to only be supported in a distribution form which is essentially an <br>
> entire OS worth of libraries packaged with the one (often very small) <br>
> program I actually want to run.  (See "bioconda".)  Most of these <br>
> programs will build just fine from source even on CentOS 6, but often <br>
> the only way to download a binary for them is to accept an additional <br>
> 1Gb (or more) of other stuff.<br>
<br>
<br>
Yeah, this has become common across many fields.  Containers become the <br>
new binaries, so you don't have to live with/accept the platform based <br>
restrictions.  This was another point of mine.  And Greg K @Sylabs is <br>
getting free exposure here :D<br>
<br>
<br>
-- <br>
Joe Landman<br>
e: <a href="mailto:joe.landman@gmail.com" target="_blank">joe.landman@gmail.com</a><br>
t: @hpcjoe<br>
w: <a href="https://scalability.org" rel="noreferrer" target="_blank">https://scalability.org</a><br>
g: <a href="https://github.com/joelandman" rel="noreferrer" target="_blank">https://github.com/joelandman</a><br>
l: <a href="https://www.linkedin.com/in/joelandman" rel="noreferrer" target="_blank">https://www.linkedin.com/in/joelandman</a><br>
<br>
_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
</blockquote></div>