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 hga@xxxxxx 09 Aug 2019 22:53 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Friday, August 09, 2019 5:25 PM

> Thanks for not dismissing my rant outright :p

Never, but I'm so focused on SRFI-170 (and non-Scheme stuff) that a
lot of the what's longer in its remit is being saved for later.

>>> There are not really many daemon-specific features in Unix that
>>> people should actually use :) Programmers want to be l33t by using
>>> daemon(), nohup, syslog, setuid() and stuff like that for their
>>> programs but it usually doesn't make any sense....

>> Syslog as in sending log messages to the system?  I use that every
>> day in my backup scripts, which logwatch then displays to assure me
>> that my local to disk, local to tape, and offsite ones all ran.

> I'm not intimately familiar with how syslog works; it is probably
> convenient for some scenarios....

Which is followed by lots more good writing, which I quickly
identified as the 12 Factor App before you cited it.  Which I might
have followed if I'd read that manifesto when I wrote my backup
scripts, although I'm lacking a framework for that.

And I do in fact have them do the detailed logging to separate files,
the calls to syslog are just for the "big stuff", backup type started
and stopped, and it captures blowups.  Which as "normal errors" happen
every once in a while with the offline one, which just tell me to
manually fire it off in the morning.

Spamming any syslog mediated log file (you can create your own) isn't
a good idea for me, but I hear it has been used in multi-system
environments, before those became huge with the advent of lots of
inexpensive x86 systems and then clouds.

>> nohup, I've read that systemd has done a number on it.  But isn't
>> it in theory useful for starting a batch process and exiting that
>> shell?

> It can be useful for one-off hacks, but daemons should not be
> started from a user shell at all. A random user login and shell
> session carries too much implicit environment that can cause
> heisenbugs for the daemon....

All good points, I've never felt a need for nohup except for on offs.

> Again, Heroku is just an auto-scaled version of this system with a
> glitzy web GUI on top. It's simply great stuff.

Then they need to work on their marketing, or I'm not paying attention
to it, it's pegged in my mind as "expensive Ruby hosting", although I
suppose Ruby hosting is inherently expensive.

- Harold