* [TUHS] Do Interface specifications such POSIX or the LSB Still Matter @ 2018-02-14 20:53 Clem Cole 2018-02-14 22:13 ` George Michaelson ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Clem Cole @ 2018-02-14 20:53 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [TUHS] Do Interface specifications such POSIX or the LSB Still Matter 2018-02-14 20:53 [TUHS] Do Interface specifications such POSIX or the LSB Still Matter Clem Cole @ 2018-02-14 22:13 ` George Michaelson 2018-02-16 15:12 ` Clem Cole 2018-02-14 22:45 ` David Arnold 2018-02-16 11:28 ` arnold 2 siblings, 1 reply; 13+ messages in thread From: George Michaelson @ 2018-02-14 22:13 UTC (permalink / raw) [-- 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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* [TUHS] Do Interface specifications such POSIX or the LSB Still Matter 2018-02-14 22:13 ` George Michaelson @ 2018-02-16 15:12 ` Clem Cole 0 siblings, 0 replies; 13+ messages in thread From: Clem Cole @ 2018-02-16 15:12 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [TUHS] Do Interface specifications such POSIX or the LSB Still Matter 2018-02-14 20:53 [TUHS] Do Interface specifications such POSIX or the LSB Still Matter Clem Cole 2018-02-14 22:13 ` George Michaelson @ 2018-02-14 22:45 ` David Arnold 2018-02-16 15:19 ` Clem Cole 2018-02-16 11:28 ` arnold 2 siblings, 1 reply; 13+ messages in thread From: David Arnold @ 2018-02-14 22:45 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [TUHS] Do Interface specifications such POSIX or the LSB Still Matter 2018-02-14 22:45 ` David Arnold @ 2018-02-16 15:19 ` Clem Cole 2018-02-16 15:45 ` Larry McVoy 0 siblings, 1 reply; 13+ messages in thread From: Clem Cole @ 2018-02-16 15:19 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [TUHS] Do Interface specifications such POSIX or the LSB Still Matter 2018-02-16 15:19 ` Clem Cole @ 2018-02-16 15:45 ` Larry McVoy 2018-02-16 18:36 ` Clem Cole 2018-02-16 18:48 ` Steve Nickolas 0 siblings, 2 replies; 13+ messages in thread From: Larry McVoy @ 2018-02-16 15:45 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [TUHS] Do Interface specifications such POSIX or the LSB Still Matter 2018-02-16 15:45 ` Larry McVoy @ 2018-02-16 18:36 ` Clem Cole 2018-02-18 1:01 ` Larry McVoy 2018-02-16 18:48 ` Steve Nickolas 1 sibling, 1 reply; 13+ messages in thread From: Clem Cole @ 2018-02-16 18:36 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [TUHS] Do Interface specifications such POSIX or the LSB Still Matter 2018-02-16 18:36 ` Clem Cole @ 2018-02-18 1:01 ` Larry McVoy 2018-02-19 15:01 ` Clem Cole 0 siblings, 1 reply; 13+ messages in thread From: Larry McVoy @ 2018-02-18 1:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [TUHS] Do Interface specifications such POSIX or the LSB Still Matter 2018-02-18 1:01 ` Larry McVoy @ 2018-02-19 15:01 ` Clem Cole 0 siblings, 0 replies; 13+ messages in thread From: Clem Cole @ 2018-02-19 15:01 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [TUHS] Do Interface specifications such POSIX or the LSB Still Matter 2018-02-16 15:45 ` Larry McVoy 2018-02-16 18:36 ` Clem Cole @ 2018-02-16 18:48 ` Steve Nickolas 1 sibling, 0 replies; 13+ messages in thread From: Steve Nickolas @ 2018-02-16 18:48 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [TUHS] Do Interface specifications such POSIX or the LSB Still Matter 2018-02-14 20:53 [TUHS] Do Interface specifications such POSIX or the LSB Still Matter Clem Cole 2018-02-14 22:13 ` George Michaelson 2018-02-14 22:45 ` David Arnold @ 2018-02-16 11:28 ` arnold 2018-02-16 15:03 ` Clem Cole 2 siblings, 1 reply; 13+ messages in thread From: arnold @ 2018-02-16 11:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [TUHS] Do Interface specifications such POSIX or the LSB Still Matter 2018-02-16 11:28 ` arnold @ 2018-02-16 15:03 ` Clem Cole 2018-02-16 16:08 ` Steffen Nurpmeso 0 siblings, 1 reply; 13+ messages in thread From: Clem Cole @ 2018-02-16 15:03 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [TUHS] Do Interface specifications such POSIX or the LSB Still Matter 2018-02-16 15:03 ` Clem Cole @ 2018-02-16 16:08 ` Steffen Nurpmeso 0 siblings, 0 replies; 13+ messages in thread From: Steffen Nurpmeso @ 2018-02-16 16:08 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2018-02-19 15:01 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-02-14 20:53 [TUHS] Do Interface specifications such POSIX or the LSB Still Matter Clem Cole 2018-02-14 22:13 ` George Michaelson 2018-02-16 15:12 ` Clem Cole 2018-02-14 22:45 ` David Arnold 2018-02-16 15:19 ` Clem Cole 2018-02-16 15:45 ` Larry McVoy 2018-02-16 18:36 ` Clem Cole 2018-02-18 1:01 ` Larry McVoy 2018-02-19 15:01 ` Clem Cole 2018-02-16 18:48 ` Steve Nickolas 2018-02-16 11:28 ` arnold 2018-02-16 15:03 ` Clem Cole 2018-02-16 16:08 ` Steffen Nurpmeso
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).