Making SRFI-170 less of a monster hga@xxxxxx 02 Aug 2019 08:23 UTC
Amendment 1 to Making SRFI-170 less of a monster hga@xxxxxx 02 Aug 2019 12:38 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster John Cowan 02 Aug 2019 17:43 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster Lassi Kortela 02 Aug 2019 18:41 UTC
(missing)
Re: Amendment 1 to Making SRFI-170 less of a monster Lassi Kortela 02 Aug 2019 19:53 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster hga@xxxxxx 02 Aug 2019 20:00 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster John Cowan 02 Aug 2019 20:44 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster John Cowan 02 Aug 2019 21:22 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster Lassi Kortela 02 Aug 2019 21:24 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster John Cowan 02 Aug 2019 21:50 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster hga@xxxxxx 02 Aug 2019 21:28 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster Lassi Kortela 02 Aug 2019 22:02 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster hga@xxxxxx 09 Aug 2019 21:40 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster Lassi Kortela 09 Aug 2019 22:25 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster hga@xxxxxx 09 Aug 2019 22:53 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster John Cowan 10 Aug 2019 01:33 UTC
Unix logging systems Lassi Kortela 10 Aug 2019 08:19 UTC
Re: Unix logging systems Duy Nguyen 10 Aug 2019 11:00 UTC
Re: Unix logging systems hga@xxxxxx 10 Aug 2019 11:47 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster hga@xxxxxx 02 Aug 2019 20:50 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster John Cowan 02 Aug 2019 21:39 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster hga@xxxxxx 02 Aug 2019 22:42 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster Lassi Kortela 02 Aug 2019 22:55 UTC
Re: Amendment 1 to Making SRFI-170 less of a monster John Cowan 03 Aug 2019 02:51 UTC

Re: Amendment 1 to Making SRFI-170 less of a monster Lassi Kortela 02 Aug 2019 22:55 UTC

>     Ah, the more I think about it, the better I like it.  Scheme
>     implementation gurus have to write the lower level one to interact
>     with their implementation, while the higher level needs experts in
>     how to least unsafely do spawn et. al. on Linux, the BSDs, etc.
>
> We already have too many experts in how to do things unsafely.  But a
> safe and easy-to-understand design can have bad implementations
> replaced.

If the subject is OS interfaces, I think *both* of the classical
approaches are wrong (!)

The only hope is to have some "OS sherpas" who know the details of the
current crop of operating systems, can make educated guesses of future
developments, and can combine all that knowledge to craft something that
has a good chance to stand the test of time.

The problem with the safe and easy designs is that they usually leave
out some crucial detail you need. This was the bane of most high-level
languages for long. The situation is better nowadays, but IIRC a major
asset of Perl back in the day is that it had a _comprehensive_ Unix API,
not just the Platonic ideals of system calls.