[TUHS] Do Interface specifications such POSIX or the LSB Still Matter

[TUHS] Do Interface specifications such POSIX or the LSB Still Matter

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]

I've send a couple of you private messages with some more details of why I
ask this, but I'll bring the large question to debate here:


​Have POSIX and​
LSB lost
​their
 usefulness/relevance?  If so, we know ISV’s like Ansys are not going to go
‘FOSS’ and make their sources available (ignore religious beliefs, it just
is not their business model); how to we get that level of precision to
allow
​the part of the
 market
​ that will be 'binary only' continue to
 create applications?

Seriously, please try to stay away from religion on this
​ question.   Clearly, there are a large number of ISVs have traditionally
used interface specifications.  To me it started with things like the old
Cobol and Fortran standards for the languages.   That was not good enough
since the systems diverge, and /usr/group then IEEE/ANSI/ISO did Posix.


Clearly, Posix enabled Unix implementations such a Linux to shine, although
Linux does not doggedly follow it.  Apple was once Posix conformant, but
I'd not think they worry to much about it.   Linux created LSB, but I see
fewer and fewer references to it.

I worry that without a real binary definition, it's darned hard (at least
in the higher end of the business that I live day-to-day) to get ISV's to
care.

What do you folks think?

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180214/45a38ad4/attachment-0001.html>

[TUHS] Do Interface specifications such POSIX or the LSB Still Matter

[George Michaelson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2994 bytes --]

once you have virtualized OS support embedded in a wrap like docker
why do you need the definition of the sysctl() calls as a spec? Ok so
clearly the people who write virtualization need some equivalent, but
basically, virtualbox or parallels or vmware plus docker == "I run a
miniature clone of the real underlying OS" so the premise behind the
ABI spec in POSIX which made it possible to write code depending on
runtime calls into systems libraries is somewhat moot. I suspect that
a minority of programs tickle things which are POSIX+/- later and they
never work well.

LSB sort of works. Sort of.

WINE manages to handle an amazing number of things, with no formalized
POSIX equivalent boundary definition.

So this is a view from the "I want to run this binary I have been
given" world view, which is mostly the consumerist take.

"I want a roughly plausible story to compile this code on a different
OS" is a different take. I recently had some code which had to compile
a C to Python shared library to extend the python core, with OpenSSL
calls. its well written. It works on FreeBSD from its porting base in
Debian, and the author is not stupid, and writes code in wide public
support (I won't out him but he's an old school MIT graduate and
really can code very well)

it simply doesn't work as-is on OSX. So clearly, something in the
API/ABI space as compiled up for OSX, for this source mashup gets
outside the boundary of what I believe POSIX tries to do. So.. how did
POSIX help? Did it avoid the problem? Nope. Did it make the problem
surface smaller? Probably.

-G

On Thu, Feb 15, 2018 at 6:53 AM, Clem Cole <clemc at ccc.com> wrote:
> I've send a couple of you private messages with some more details of why I
> ask this, but I'll bring the large question to debate here:
>
>
> Have POSIX and
> LSB lost
> their
>  usefulness/relevance?  If so, we know ISV’s like Ansys are not going to go
> ‘FOSS’ and make their sources available (ignore religious beliefs, it just
> is not their business model); how to we get that level of precision to allow
> the part of the
>  market
> that will be 'binary only' continue to
>  create applications?
>
> Seriously, please try to stay away from religion on this
> question.   Clearly, there are a large number of ISVs have traditionally
> used interface specifications.  To me it started with things like the old
> Cobol and Fortran standards for the languages.   That was not good enough
> since the systems diverge, and /usr/group then IEEE/ANSI/ISO did Posix.
>
>
> Clearly, Posix enabled Unix implementations such a Linux to shine, although
> Linux does not doggedly follow it.  Apple was once Posix conformant, but I'd
> not think they worry to much about it.   Linux created LSB, but I see fewer
> and fewer references to it.
>
> I worry that without a real binary definition, it's darned hard (at least in
> the higher end of the business that I live day-to-day) to get ISV's to care.
>
> What do you folks think?
>
> Clem
>

[TUHS] Do Interface specifications such POSIX or the LSB Still Matter

[David Arnold]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5557 bytes --]

Purely from my own perspective, and perhaps a little round about … 

As an ISV, the best customer experience comes from having your software provided in the distribution’s repositories.  That implies that your product be both gratis and libre (to some definition).  At that point, it’s an ‘apt’, ‘yum’, etc away.

Second best is in the distribution’s secondary repositories (Universe, Extras, EPEL, etc).  A customer potentially has to fiddle with their enabled repositories, but that’s a one-off, and afterwards plain sailing.  This mostly requires source availability unless your product is something that’s very widely demanded, and the source not feasibly made available (eg. Adobe Flash player browser plugins, or similar).  Note that for some customers, they are not permitted (by their internal compliance people) to enable eg. EPEL.

Third best is where you host package repositories yourself for a selection of distributions you care about.  This is basically the best customer experience possible for commercially-licensed binary-only distribution.  The end-user has to import your repository definition, approve your certificate, etc, but that’s a one-off thing, fairly simple to do, and thereafter they can install and update anything you publish with minimal effort.  Compliance-wise, this is actually easier than the vendors’ secondary repos, because it’s limited to one company with whom there’s a contractual relationship.

In that context …

POSIX matters largely as an historical artefact: it means that Linux and macOS are mostly compatible.  But new features are added relatively frequently, and there’s apparently minimal value placed on compatibility with others.  The bulk of your application code is compatible (ie. all the POSIX stuff), but corner cases need compatibility handling.  The UI, the filesystem, etc, often ends up being entirely different.

LSB had numerous issues:
* It was too minimal, not including much beyond basic POSIX.  IIRC, it didn’t include even OpenSSL, for example (at least in earlier editions)
* It was often an optional package, needing to be installed before LSB-based applications would work
* It then had different versions, and vendors were late to implement the later (more broad) requirements, so in practice you could only rely on the base set
* After all of that, an LSB-based package was still typically installed and maintained differently from everything else on the system, so the end-user’s experience was pretty bad

In my experience, you were actually better off just building on glibc and making a minimal (POSIX-ish) set of assumptions about installed utilities and filesystem layout).  That way at least you avoided the issues of needing to install LSB-compatibility packages, versioning of the LSB packages, etc.

Implicit in all of this is that the market for commercial Unix and the BSDs is negligible, and has been for basically 10 years.  Aside from a brief uptick for Solaris 10, that was pretty-much true from about Solaris 7 onwards.  RHEL3+ and SLES9+, and then later Ubuntu LTS, and perhaps Darwin/Mac OS X/macOS covered enough of the market.  Today, macOS is the worst to support, since it doesn’t have a system package manager so you have to handle the patching/update process yourself, AND it’s a different kernel, C runtime, and vendor userland libraries.  RHEL/CentOS and Ubuntu LTS cover most customers.  SLES still has a few niches, but it's dying.  macOS is used only as a client, and mostly that doesn’t matter since applications are using a web UI on a Linux backend anyway.

I think the bigger question is really … is there really still a market for commercially-licensed installable software packages?  The set of things that cannot be delivered via the web, and are not available as Free/Open Source is ever-shrinking.

The operating system as we know it has become a substrate.  Linux has won, and the battle has moved on to the services layer.



d

> On 15 Feb 2018, at 07:53, Clem Cole <clemc at ccc.com> wrote:
> 
> I've send a couple of you private messages with some more details of why I ask this, but I'll bring the large question to debate here:
> 
> ​Have POSIX and​ LSB lost ​their usefulness/relevance?  If so, we know ISV’s like Ansys are not going to go ‘FOSS’ and make their sources available (ignore religious beliefs, it just is not their business model); how to we get that level of precision to allow ​the part of the market ​ that will be 'binary only' continue to create applications?
> 
> Seriously, please try to stay away from religion on this​ question.   Clearly, there are a large number of ISVs have traditionally used interface specifications.  To me it started with things like the old Cobol and Fortran standards for the languages.   That was not good enough since the systems diverge, and /usr/group then IEEE/ANSI/ISO did Posix.  
> 
> 
> Clearly, Posix enabled Unix implementations such a Linux to shine, although Linux does not doggedly follow it.  Apple was once Posix conformant, but I'd not think they worry to much about it.   Linux created LSB, but I see fewer and fewer references to it.
> 
> I worry that without a real binary definition, it's darned hard (at least in the higher end of the business that I live day-to-day) to get ISV's to care.
> 
> What do you folks think?
> 
> Clem
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180215/668088be/attachment.html>

[TUHS] Do Interface specifications such POSIX or the LSB Still Matter

[arnold]

There was an article about this in ;login: in 2015 if I recall
correctly. Worth trying to find.  The issue is a real one.

HTH,

Arnold

Clem Cole <clemc at ccc.com> wrote:

> I've send a couple of you private messages with some more details of why I
> ask this, but I'll bring the large question to debate here:
>
>
> ???Have POSIX and???
> LSB lost
> ???their
>  usefulness/relevance?  If so, we know ISV???s like Ansys are not going to go
> ???FOSS??? and make their sources available (ignore religious beliefs, it just
> is not their business model); how to we get that level of precision to
> allow
> ???the part of the
>  market
> ??? that will be 'binary only' continue to
>  create applications?
>
> Seriously, please try to stay away from religion on this
> ??? question.   Clearly, there are a large number of ISVs have traditionally
> used interface specifications.  To me it started with things like the old
> Cobol and Fortran standards for the languages.   That was not good enough
> since the systems diverge, and /usr/group then IEEE/ANSI/ISO did Posix.
>
>
> Clearly, Posix enabled Unix implementations such a Linux to shine, although
> Linux does not doggedly follow it.  Apple was once Posix conformant, but
> I'd not think they worry to much about it.   Linux created LSB, but I see
> fewer and fewer references to it.
>
> I worry that without a real binary definition, it's darned hard (at least
> in the higher end of the business that I live day-to-day) to get ISV's to
> care.
>
> What do you folks think?
>
> Clem

[TUHS] Do Interface specifications such POSIX or the LSB Still Matter

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3591 bytes --]

Aharon - is this article you were referring:  POSIX Has Become Outdated:
Atlidakis, Andrus & Geambasu
<https://www.usenix.org/system/files/login/articles/login_fall16_02_atlidakis.pdf>

I have it and have read it.   It is a great piece and I think spot on for
new(er) applications being written fresh for Mac OSx, Android, *etc.*

I'm personally poking at this from the large (clustered) view of a
commercial ISV (think in Geo Sciences, Mech E CAD, Fluids, Chem, or
Financial) that has valuable code (much still in Fortran BTW).  More over
their customers have huge amounts of data developed over 30-40 years using
those codes, so if you magically tried to replace the codes, you need to
revalidate the data too.

So how do your define/agree upon/build interfaces that that ISV can trust
and an IHV/OEM can use to sell systems, particularly for the commercial
part of the market.  The very high end (national labs/high energy physics
types) write their own code.   But the main part of the commercial
scientific community does not.


POSIX.1 and LSB certainly helped to solve a set of problems.   But it seems
like the developers of the systems don't care any more.  They have a use my
'framework' and my app store mentality.    Which sort of is working for
mass market where you sell millions of copies.

The problem is that those codes were all developed when an older market
model and market model has changed as the market great to include a new
group of players.  The problem is that the market does not care much for
that older portion of the total market these days, so their model is
squeezed.    But as I said, even if magically new codes appeared to replace
the old ones, the old data is still an issue.

Clem
ᐧ

On Fri, Feb 16, 2018 at 6:28 AM, <arnold at skeeve.com> wrote:

> There was an article about this in ;login: in 2015 if I recall
> correctly. Worth trying to find.  The issue is a real one.
>
> HTH,
>
> Arnold
>
> Clem Cole <clemc at ccc.com> wrote:
>
> > I've send a couple of you private messages with some more details of why
> I
> > ask this, but I'll bring the large question to debate here:
> >
> >
> > ???Have POSIX and???
> > LSB lost
> > ???their
> >  usefulness/relevance?  If so, we know ISV???s like Ansys are not going
> to go
> > ???FOSS??? and make their sources available (ignore religious beliefs,
> it just
> > is not their business model); how to we get that level of precision to
> > allow
> > ???the part of the
> >  market
> > ??? that will be 'binary only' continue to
> >  create applications?
> >
> > Seriously, please try to stay away from religion on this
> > ??? question.   Clearly, there are a large number of ISVs have
> traditionally
> > used interface specifications.  To me it started with things like the old
> > Cobol and Fortran standards for the languages.   That was not good enough
> > since the systems diverge, and /usr/group then IEEE/ANSI/ISO did Posix.
> >
> >
> > Clearly, Posix enabled Unix implementations such a Linux to shine,
> although
> > Linux does not doggedly follow it.  Apple was once Posix conformant, but
> > I'd not think they worry to much about it.   Linux created LSB, but I see
> > fewer and fewer references to it.
> >
> > I worry that without a real binary definition, it's darned hard (at least
> > in the higher end of the business that I live day-to-day) to get ISV's to
> > care.
> >
> > What do you folks think?
> >
> > Clem
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180216/095225f7/attachment.html>

[TUHS] Do Interface specifications such POSIX or the LSB Still Matter

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

On Wed, Feb 14, 2018 at 5:13 PM, George Michaelson <ggm at algebras.org> wrote:

> once you have virtualized OS support embedded in a wrap like docker
> why do you need the definition of the sysctl() calls as a spec?
>
​Maybe -- HPC folks use UNIX/Linux but really don't want an OS between the
HW and their application.
And its not just the *.1 style system functions.   Think SPEC1170 where we
discovered 1170 difference interfaces, database file etc... that ISV had to
know about to deal with a 'UNIX' application.​  And that was before we had
things like fabric and messaging.

Within the >>Linux<< (which 'never forked' like UNIX did) the test matrix
is still huge for an ISV these days.



>
> LSB sort of works. Sort of.
>
agreed - hence my question.  But is sort of RHish and its not clear it
being maintained because people don't care.


ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180216/627f6fc2/attachment.html>

[TUHS] Do Interface specifications such POSIX or the LSB Still Matter

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]

On Wed, Feb 14, 2018 at 5:45 PM, David Arnold <davida at pobox.com> wrote:

> is there really still a market for commercially-licensed installable
> software packages?  The set of things that cannot be delivered via the web,
> and are not available as Free/Open Source is ever-shrinking.
>

​I agree with the later, but for the folks that have traditionally made a
market in the former (think commercial HPC - geo science, mech-e cad,
financial, chemistry, etc..) - they have codes [often in Fortran] and years
and year of data that those codes have been used to create an validate.

Ever-shrinking is right, but those folks have very valuable (billions of
dollars) invested in that data and their businesses behind them.   The code
they use is proprietary and closed.

As I said in another message, the test matrix for the folks that develop
that code got unwieldy.

Containers is the only alternative I have seen so far that might solve
this, but .... that same folks don't like no stinking OS between their app
and the HW, so using virtualization technology to solve a problem is
usually a no-no.

Thanks again,
Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180216/7faefd4c/attachment.html>

[TUHS] Do Interface specifications such POSIX or the LSB Still Matter

[Larry McVoy]

On Fri, Feb 16, 2018 at 10:19:37AM -0500, Clem Cole wrote:
> On Wed, Feb 14, 2018 at 5:45 PM, David Arnold <davida at pobox.com> wrote:
> > is there really still a market for commercially-licensed installable
> > software packages?  The set of things that cannot be delivered via the web,
> > and are not available as Free/Open Source is ever-shrinking.
> 
> ???I agree with the later, but for the folks that have traditionally made a
> market in the former (think commercial HPC - geo science, mech-e cad,
> financial, chemistry, etc..) - they have codes [often in Fortran] and years
> and year of data that those codes have been used to create an validate.
> 
> Ever-shrinking is right, but those folks have very valuable (billions of
> dollars) invested in that data and their businesses behind them.   The code
> they use is proprietary and closed.
> 
> As I said in another message, the test matrix for the folks that develop
> that code got unwieldy.

Meh, not really.  Until Git ate our market, we supported everything you
might imagine.  Windows, MacOS, Linux-{x86,x86_64,sparc,ppc,itanium,mips},
AIX, IRIX, HP-UX, Solaris.

Source base of 2.6 million lines of code and docs.

The coding part that was bad was Windows vs Posix, that was painful (no
fork on Windows, had to map windows error codes to errnos, link, stat,
utime, sockets, all had to be emulated, file names mapped from unix to
windows and back again, etc, etc).

The rest of it was pretty easy.  We limited our stuff to very basic
stuff, we shipped our own stdio (based on NetBSD's) because we stacked
stuff on top of it 

	/*
	 * Open a stdio handle to file that is gzipped
	 * After the fpush you can fread/gets/fseek/whatever.
	 */
	FILE *f = fopen(file, "r");
	fpush(&f, fopen_zip(f->fh, "r"));

For a long time I was careful about what we used in libc, I'd been burned
by realloc() implementations that didn't work.  In the last 5 years or so
I loosened up about that, the bugs were always in the odd ball Unixes and
they had gone away.

I think it gets harder the more "fancy" you get.  If you are doing 
commandline/compute stuff it's pretty easy.

Want GUI stuff that is cross platform?  That's a mess, we went with 
Tcl/Tk (which will drive the pure lisp people even more crazy, sorry;
we "solved" that problem with a byte code compiler that took a C like
dialect and spit out tcl byte codes).  Probably would do Qt or something
else today (didn't want to have C++ in the tool chain 20+ years ago).

Want video?  Oh, my.

Want sound?  Oh, my.

I don't see any standard trying to fix that cross platform, windows and
Linux are too different.  Though maybe the Linux on windows stuff solves
that?  I dunno.

> Containers is the only alternative I have seen so far that might solve
> this, but .... that same folks don't like no stinking OS between their app
> and the HW, so using virtualization technology to solve a problem is
> usually a no-no.

Netflix does a lot in AWS.  And they care about performance.  But they 
code around the variance that you get from containers, I could see that
as an issue for the old school fortran people.

I'm sort of struggling to see what problem it is you want to solve.

[TUHS] Do Interface specifications such POSIX or the LSB Still Matter

[Steffen Nurpmeso]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3108 bytes --]

Clem Cole <clemc at ccc.com> wrote:
 |Aharon - is this article you were referring:  [1]POSIX Has Become Outdated: \
 |Atlidakis, Andrus & Geambasu[/1]
 |
 |  [1] https://www.usenix.org/system/files/login/articles/login_fall16_02_atl\
 |  idakis.pdf
 |
 |I have it and have read it.   It is a great piece and I think spot \

They seem to have made it.  Congratulations!
Just five people and six pages of text, graphs and images it took
to throw several different generations of programmers and
experience over board.  That is brilliant.

 |on for new(er) applications being written fresh for Mac OSx, Android, etc. 

Thankfully they describe what they are talking about (apps).  I do
not use one of those.  I believe most of them use Java, an
all-in-one environment which only uses some basic system-calls
where absolutely necessary.

  ...
 |POSIX.1 and LSB certainly helped to solve a set of problems.   But \
 |it seems like the developers of the systems don't care any more.  They \
 |have a use my
 |'framework' and my app store mentality.    Which sort of is working \
 |for mass market where you sell millions of copies. 
  ...

All the servers, mail, web, database etc., they all build upon ISO
C and the much more serious POSIX superset.  POSIX clearly has
a number of dramatical deficiencies, but much less than ISO C has.
Internationalized string processing is a huge problem,
internationalized calendars a second: this is a shortcoming
inherited from the first generations that created C and UNIX.
They definitely had to face completely different problems, but
that UTF-8 did not made it into C and POSIX in the 1995 amendment,
for example, for this people are to blame.  I am not clever enough
to realize how strxfrm() can be made to work for complicated
languages, but it actually seems to be possible.

And select(2) is not capable to bring the performance that modern
super-parallel code requires, it is a bottleneck.  Several
different interfaces which can do better exist on the different
platforms (e.g., of kevent on FreeBSD and epoll on Linux my
opinion is that kevent is better), but they are not portable and
so they are not yet standardized.  But a FreeBSD developer brought
up the issue, and so maybe the future brings an improvement there.

P.S.: that developer has also created a completely new and
portable UNIX-style interface for (GUI-less) programs in the
cloud, cloudabi the name.  Programs are compiled once and run on
any system that supports the syscall interface, for example
FreeBSD.  You do not have a terminal, too, i think, though.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
-------------- next part --------------
An embedded message was scrubbed...
From: Clem Cole <clemc@ccc.com>
Subject: Re: [TUHS] Do Interface specifications such POSIX or the LSB Still	Matter
Date: Fri, 16 Feb 2018 10:03:11 -0500
Size: 13904
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180216/b4097f2f/attachment.mht>

[TUHS] Do Interface specifications such POSIX or the LSB Still Matter

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3219 bytes --]

On Fri, Feb 16, 2018 at 10:45 AM, Larry McVoy <lm at mcvoy.com> wrote:

>
>
> Meh, not really.  Until Git ate our market, we supported everything you
> might imagine.  Windows, MacOS, Linux-{x86,x86_64,sparc,ppc,itanium,mips},
> AIX, IRIX, HP-UX, Solaris.
>
> Source base of 2.6 million lines of code and docs.
>
​Did you have messaging (Co-Arrays, MPI or SHMEM) mixed in?  I'm guess
not., but your system is (was) extensive so I'm asking....
Commercial HPC code from folks like Western Geco, Ansys, Pam and the like
do...
Within a manufacturer these can differ.   Want to run both Pam Crash and
Fluent -- be careful, their MPI's libraries were (may still be) mutually
exclusive.





>
> ​....​
>  We limited our stuff to very basic
> ​ ​
> stuff
>
​Yup -- very wise.   Simple library to insulate you from OS.
Did you shipped statically bound or use *.so's
Also how much are you dependant on OS databases (password & credential
libraries and other things  stored in /etc, /usr/lib or /var)​?
​This is were even within Linux, life can get messy pretty fast.​



>
> I think it gets harder the more "fancy" you get.  If you are doing
> commandline/compute stuff it's pretty easy.
>
​Agreed... but multi-thousand costing/leasing @ dollar/euro codes because
they save you millions at the design, or before you drill time, tend to
have a high bar.

​


>
> Want video?  Oh, my.
>
​exactly...​



>
> Want sound?  Oh, my.
>
> I don't see any standard trying to fix that cross platform, windows and
> Linux are too different.  Though maybe the Linux on windows stuff solves
> that?  I dunno.
>
In the old days, I was just trying to be consistent within UNIX flavors so
we created POSIX.
These days, ​I'm just trying to be consistent within Linux ... so I've
tried to use LSB to define something for an ISV that they can rely.




>
> Netflix does a lot in AWS.  And they care about performance.  But they
> code around the variance that you get from containers, I could see that
> as an issue for the old school fortran people.
>
​Good .. you get it.​



>
> I'm sort of struggling to see what problem it is you want to solve.
>
​Without revealing the ISV, I know very well know HPC ISV that used to have
a >>Linux<< only test matrix of over 140 perminations before they could
release and they only supported RH and SuSE.   But between different
manufacturers, distributed file systems, interconnect, messaging stacks,
compilers *et al​*

*​ *it got messy very fast.​

We helped to that down to a much smaller number today and I think they now
may even include Ubuntu, but maybe not; because most of the
commercial folks are traditionally RH or SuSE (HPC moving to a more cloud
oriented deployment have cause the push for Ubuntu support by the ISVs).
But most commercial folks doing traditional scientific work loads run their
own clusters (and are not cloud based )-- for a number of reasons.  As I
said, they like the HW by themselves, they tend to use fabrics for the
interconnect *etc*...

Thanks again,
Clem

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180216/fc7e3883/attachment.html>

[TUHS] Do Interface specifications such POSIX or the LSB Still Matter

[Steve Nickolas]

On Fri, 16 Feb 2018, Larry McVoy wrote:

> Want video?  Oh, my.
>
> Want sound?  Oh, my.
>
> I don't see any standard trying to fix that cross platform, windows and
> Linux are too different.  Though maybe the Linux on windows stuff solves
> that?  I dunno.

Doesn't SDL take care of that reasonably well? Most modern apps also seem 
to dispense with the OS-native audio and video codecs and use some form of 
the FFMPEG code to handle that.

-uso.

[TUHS] Do Interface specifications such POSIX or the LSB Still Matter

[Larry McVoy]

On Fri, Feb 16, 2018 at 01:36:14PM -0500, Clem Cole wrote:
> On Fri, Feb 16, 2018 at 10:45 AM, Larry McVoy <lm at mcvoy.com> wrote:
> > Meh, not really.  Until Git ate our market, we supported everything you
> > might imagine.  Windows, MacOS, Linux-{x86,x86_64,sparc,ppc,itanium,mips},
> > AIX, IRIX, HP-UX, Solaris.
> >
> > Source base of 2.6 million lines of code and docs.
> >
> ???Did you have messaging (Co-Arrays, MPI or SHMEM) mixed in?  I'm guess
> not., but your system is (was) extensive so I'm asking....

Nope.  We did our own protocol over TCP and HTTP.

> >  We limited our stuff to very basic stuff
> >
> ???Yup -- very wise.   Simple library to insulate you from OS.
> Did you shipped statically bound or use *.so's

We could build static, we had a "make crank-static", but we rarely did
that, it was only for some oddball targets.  99.9999% of the time it
was dynamic and it was not a problem because I was so careful about
what we used in libc (as I said before, it was only in the last 5 years
that I trusted that realloc() actually worked).

> Also how much are you dependant on OS databases (password & credential
> libraries and other things  stored in /etc, /usr/lib or /var)????
> ???This is were even within Linux, life can get messy pretty fast.???

We really didn't use much, we were not parsing that stuff for the most
part.  There were some things we did, for example, we have a fstype()
function that called disktype().  It tried to find the mount point,
looking through

	/etc/mtab
	/etc/mnttab
	/var/log/mount.today

and it figured out if it was NFS or not.  If it was not NFS then it 
called disktype which tried to figure out if it was SSD or not by 
pawing through stuff like /sys/block/%s/queue/rotational

All of that was so we could auto-optimize parallelism, NFS wants 8 way,
SSD wants all the CPUS, rotating disk wants just one or you thrash the
arm.

> > Netflix does a lot in AWS.  And they care about performance.  But they
> > code around the variance that you get from containers, I could see that
> > as an issue for the old school fortran people.
> >
> ???Good .. you get it.???

Maybe.

> > I'm sort of struggling to see what problem it is you want to solve.
> >
> ???Without revealing the ISV, I know very well know HPC ISV that used to have
> a >>Linux<< only test matrix of over 140 perminations before they could
> release and they only supported RH and SuSE.   But between different
> manufacturers, distributed file systems, interconnect, messaging stacks,
> compilers *et al???*
> 
> *??? *it got messy very fast.???

I really don't see why.  I can see why if they are using every library
known to man, but if you want portable you don't do that.

[TUHS] Do Interface specifications such POSIX or the LSB Still Matter

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2102 bytes --]

On Sat, Feb 17, 2018 at 8:01 PM, Larry McVoy <lm at mcvoy.com> wrote:
>
> I really don't see why.  I can see why if they are using every library
> known to man, but if you want portable you don't do that.
>
​The ISV's customers are interesting in getting a specific job done - be it
a simulation, ​

​geo or therma prediction.  Time to money is what matters to the end user -
so they pick the 'best' product to do their job.   ​Hence, e
xecution speed is typically the prime directive for an ISV like this and
they are using Fortran for portability.​ Which is different from your
design point I suspect.   You need to be fast enough, but the choice of
bitkeeper vs cvs vs ... is likely made with a different high order bit.

​For the ISV​, at a
 minimum, it is a testing issue of the different perminations.  They need
to be fast, but their production code is deployed a top of 'a stack of
turtles.'   As I said RH Linux != SuSE != Ubuntu (they are similar but the
kernels are not the same and the system DB's vary -- those tend to cause
installation issues).  GFortran != Intel ifort != PCG FTN != Cray FTN !=
IBM fortran. Much less GCC != Clang != Intel​ icc != IBM CC - cause
interesting issues with dynamic loading.   IBM MPI != HP MPI != OpenMPI !=
Intel MPI  etc..tend to cause ISV code to step on each other.
​
Then you add  Mellanox IB is not IBM is not Intel and ....
Mellanox Verbs is not Cisco Verbs is not PSM is not OFED
​ and locking and scaling starts to get strange​
.

Each of these can be a 'little different' even though they all follow
standards.  It becomes a old Al Haig - style - "I'm in charge" problem.
Moreover, I know of one large distro insists on only testing their IB stack
point to point with two system, even when they have been offered a HW from
a
vendor
​ that has 4 compute nodes plus a head node, just to chase and tease out
the corner cases that drive the ISV mad.

​
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180219/03000165/attachment.html>