From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mirv.inri.net ([167.88.120.88]) by ur; Tue Apr 18 16:19:33 EDT 2017 Received: from [192.168.1.82] ([107.207.65.229]) by mirv; Tue Apr 18 16:19:33 EDT 2017 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [9front] aux/listen changes From: Stanley Lieber X-Mailer: iPhone Mail (14E304) In-Reply-To: Date: Tue, 18 Apr 2017 16:19:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <99147B08-6D16-450F-9F4E-6B34D0019737@stanleylieber.com> References: To: 9front@9front.org List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: overflow-preventing lossless descriptor-oriented event-scale control > On Apr 18, 2017, at 4:06 PM, Steve Simon wrote: >=20 > Too you really run different services on different servers? > All my cpu servers run the same services, whilst the terminals don=E2=80=99= t even run listen. >=20 > Plan9 has plenty of problems but /rc/bin/service is not a significant one I= MHO. >=20 > -Steve Yes, I run different services on several machines that share a disk file sys= tem. Plan 9's best point of separation for integrity of processes is individual k= ernels. Sometimes you want to isolate stuff that might go nuts or is otherwi= se unreliable. Example: crashing my web server (likely) does not cause my e-mail to stop pr= ocessing. The point about tracking in the repository is also salient. It makes sense t= o fall back on sane defaults but also check for site customized alternatives= . That's why /cfg exists in the first place. It's a good idea to track (only= ) the sane defaults in the repository. sl