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

[steffen@sdaoden.eu (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>