Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #16517 > unrolled thread

Faking a TTY on a pipe/socketpair

Back to article view | Back to comp.unix.programmer

Contents

  Faking a TTY on a pipe/socketpair Muttley@dastardlyhq.com - 2024-11-16 11:26 +0000
    Re: Faking a TTY on a pipe/socketpair gazelle@shell.xmission.com (Kenny McCormack) - 2024-11-16 20:51 +0000
      Re: Faking a TTY on a pipe/socketpair Muttley@DastartdlyHQ.org - 2024-11-17 08:41 +0000
        Re: Faking a TTY on a pipe/socketpair Wolfgang Agnes <wagnes@example.com> - 2024-11-17 11:38 -0300
        Re: Faking a TTY on a pipe/socketpair gazelle@shell.xmission.com (Kenny McCormack) - 2024-11-17 18:25 +0000
          Re: Faking a TTY on a pipe/socketpair Muttley@DastartdlyHQ.org - 2024-11-17 18:41 +0000
    Re: Faking a TTY on a pipe/socketpair Kaz Kylheku <643-408-1753@kylheku.com> - 2024-11-17 17:48 +0000
      Re: Faking a TTY on a pipe/socketpair Muttley@DastartdlyHQ.org - 2024-11-17 18:39 +0000
      Re: Faking a TTY on a pipe/socketpair Eric Pozharski <apple.universe@posteo.net> - 2024-11-18 07:54 +0000
        Re: Faking a TTY on a pipe/socketpair scott@slp53.sl.home (Scott Lurndal) - 2024-11-18 14:02 +0000
        Re: Faking a TTY on a pipe/socketpair Kaz Kylheku <643-408-1753@kylheku.com> - 2024-11-18 20:43 +0000
          Re: Faking a TTY on a pipe/socketpair Eric Pozharski <apple.universe@posteo.net> - 2024-11-19 10:07 +0000
    Re: Faking a TTY on a pipe/socketpair Janis Papanagnou <janis_papanagnou@hotmail.com> - 2024-11-18 03:38 +0100
      Re: Faking a TTY on a pipe/socketpair Muttley@DastartdlyHQ.org - 2024-11-18 08:26 +0000
      Re: Faking a TTY on a pipe/socketpair Richard Kettlewell <invalid@invalid.invalid> - 2024-11-18 09:51 +0000
        Re: Faking a TTY on a pipe/socketpair Muttley@DastartdlyHQ.org - 2024-11-18 09:57 +0000
    Re: Faking a TTY on a pipe/socketpair rlhamil@smart.net (Richard L. Hamilton) - 2024-12-03 05:29 +0000
      Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-03 08:20 +0000
        Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-03 20:21 +0000
          Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-04 08:34 +0000
            Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-05 02:11 +0000
              Re: Faking a TTY on a pipe/socketpair gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-05 06:44 +0000
                Re: Faking a TTY on a pipe/socketpair cross@spitfire.i.gajendra.net (Dan Cross) - 2024-12-05 13:15 +0000
                  Re: Faking a TTY on a pipe/socketpair gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-05 13:57 +0000
                    Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-05 15:06 +0000
              Re: Faking a TTY on a pipe/socketpair Nicolas George <nicolas$george@salle-s.org> - 2024-12-05 08:01 +0000
              Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-05 08:19 +0000
                Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-05 20:45 +0000
                  Re: Faking a TTY on a pipe/socketpair scott@slp53.sl.home (Scott Lurndal) - 2024-12-05 21:06 +0000
                  Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-06 10:28 +0000
                    Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-06 20:00 +0000
                      Re: Faking a TTY on a pipe/socketpair John Ames <commodorejohn@gmail.com> - 2024-12-06 12:37 -0800
                        Re: Faking a TTY on a pipe/socketpair scott@slp53.sl.home (Scott Lurndal) - 2024-12-06 22:15 +0000
                      Re: Faking a TTY on a pipe/socketpair Muttley@dastardlyhq.com - 2024-12-07 10:04 +0000
                        Windows-think and systemd (Was: Something completely unrelated to what we're yapping about now) gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-07 15:00 +0000
                          Re: Windows-think and systemd (Was: Something completely unrelated to what we're yapping about now) Muttley@dastardlyhq.com - 2024-12-07 16:05 +0000
                            Re: Windows-think and systemd (Was: Something completely unrelated to what we're yapping about now) rlhamil@smart.net (Richard L. Hamilton) - 2024-12-14 09:09 +0000
                              AIX (was Re: Windows-think and systemd) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-14 12:24 +0100
                          Re: Windows-think and systemd (Was: Something completely unrelated to what we're yapping about now) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-08 03:51 +0000
                          Re: Windows-think and systemd (Was: Something completely unrelated to what we're yapping about now) Jim Jackson <jj@franjam.org.uk> - 2024-12-09 20:38 +0000
                        Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-09 16:24 +0000
                        Re: Faking a TTY on a pipe/socketpair rlhamil@smart.net (Richard L. Hamilton) - 2024-12-14 09:06 +0000
                  Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-06 17:01 +0000
                  Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-09 20:28 +0000
                    Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-10 01:27 +0000
                      Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-10 21:01 +0000
                    Re: Faking a TTY on a pipe/socketpair Richard Kettlewell <invalid@invalid.invalid> - 2024-12-10 08:50 +0000
                      Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-10 09:23 +0000
                        Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-10 12:26 +0000
                        Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-10 20:55 +0000
                          Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-10 22:02 +0000
                          Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-11 08:33 +0000
                            Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-11 22:26 +0000
                              Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-11 22:40 +0000
                                Re: Faking a TTY on a pipe/socketpair Nicolas George <nicolas$george@salle-s.org> - 2024-12-11 23:34 +0000
                                  Re: Faking a TTY on a pipe/socketpair Alexis <flexibeast@gmail.com> - 2024-12-12 19:15 +1100
                                    Re: Faking a TTY on a pipe/socketpair Nicolas George <nicolas$george@salle-s.org> - 2024-12-12 11:46 +0000
                                  Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-12 08:27 +0000
                                    Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-12 09:38 +0000
                                      Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-12 22:24 +0000
                                  Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-13 20:07 +0000
                                    Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-13 22:05 +0000
                                      Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-14 15:20 +0000
                                        Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-14 22:26 +0000
                                          Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-16 23:03 +0000
                                            Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-17 02:39 +0000
                                              Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-18 21:19 +0000
                                                Re: Faking a TTY on a pipe/socketpair scott@slp53.sl.home (Scott Lurndal) - 2024-12-18 22:16 +0000
                                                  Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-18 22:25 +0000
                              Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-12 08:39 +0000
                                Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-12 22:31 +0000
                                  Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-13 10:38 +0000
                                    Re: Faking a TTY on a pipe/socketpair John Ames <commodorejohn@gmail.com> - 2024-12-13 07:42 -0800
                                      Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-14 01:35 +0000
                                        Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-14 20:16 +0000
                                          Re: Faking a TTY on a pipe/socketpair Muttley@dastardlyhq.com - 2024-12-15 12:43 +0000
                                            Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-15 21:25 +0000
                                              Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-16 08:16 +0000
                                                Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-16 19:51 +0000
                                                  Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-17 08:34 +0000
                                                    Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-17 19:44 +0000
                                                  Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-17 17:27 +0000
                                        Re: Faking a TTY on a pipe/socketpair John Ames <commodorejohn@gmail.com> - 2024-12-16 07:55 -0800
                                          Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-16 20:15 +0000
                                            Re: Faking a TTY on a pipe/socketpair John Ames <commodorejohn@gmail.com> - 2024-12-16 12:44 -0800
                                            Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-16 23:07 +0000
                                              Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-17 02:37 +0000
                                                Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-17 08:35 +0000
                                                  Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-17 19:45 +0000
                                              Re: Faking a TTY on a pipe/socketpair Richard Kettlewell <invalid@invalid.invalid> - 2024-12-17 19:48 +0000
                                                Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-17 20:45 +0000
                                                  Re: Faking a TTY on a pipe/socketpair gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-17 22:00 +0000
                                                Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-17 20:54 +0000
                                            Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-17 17:28 +0000
                                      Re: Faking a TTY on a pipe/socketpair Muttley@dastardlyhq.com - 2024-12-14 10:05 +0000
                                  Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-13 11:42 +0000
                                  Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-13 20:15 +0000
                  Re: Faking a TTY on a pipe/socketpair rlhamil@smart.net (Richard L. Hamilton) - 2024-12-14 08:52 +0000
                    Re: Faking a TTY on a pipe/socketpair Muttley@dastardlyhq.com - 2024-12-14 10:09 +0000
                    Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-14 22:28 +0000
                Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-05 20:46 +0000
          Re: Faking a TTY on a pipe/socketpair rlhamil@smart.net (Richard L. Hamilton) - 2024-12-14 08:48 +0000
            Re: Faking a TTY on a pipe/socketpair Muttley@dastardlyhq.com - 2024-12-14 10:06 +0000
            macOS and UNIX conformance (was: Faking a TTY on a pipe/socketpair) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2024-12-16 14:05 +0000
      Re: Faking a TTY on a pipe/socketpair Richard Kettlewell <invalid@invalid.invalid> - 2024-12-03 08:38 +0000
      Re: Faking a TTY on a pipe/socketpair scott@slp53.sl.home (Scott Lurndal) - 2024-12-03 14:22 +0000

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#16736

On 2024-12-11, Nicolas George <nicolas$george@salle-s.org> wrote:
> Jim Jackson , dans le message <slrnvlk56u.2qa.jj@iridium.wf32df>, a
>  ?crit?:
>> My God, how did we all manage running services before systemd came along?
>
> Badly, with services that have crashed and nobody noticed for weeks.

People keep saying that. But in my experience services were run as 
efficiently as they seem to be run today. Perhaps the team I worked in 
knew what it was doing :-)

[toc] | [prev] | [next] | [standalone]

#16738

On Fri, 13 Dec 2024 20:07:58 -0000 (UTC), Jim Jackson wrote:

> On 2024-12-11, Nicolas George <nicolas$george@salle-s.org> wrote:
>>
>> Jim Jackson , dans le message <slrnvlk56u.2qa.jj@iridium.wf32df>, a
>>  écrit :
>>>
>>> My God, how did we all manage running services before systemd came
>>> along?
>>
>> Badly, with services that have crashed and nobody noticed for weeks.
> 
> People keep saying that. But in my experience services were run as
> efficiently as they seem to be run today. Perhaps the team I worked in
> knew what it was doing :-)

How many custom services were you running on a single machine, just out of 
curiosity?

[toc] | [prev] | [next] | [standalone]

#16748

On 2024-12-13, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Fri, 13 Dec 2024 20:07:58 -0000 (UTC), Jim Jackson wrote:
>
>> On 2024-12-11, Nicolas George <nicolas$george@salle-s.org> wrote:
>>>
>>> Jim Jackson , dans le message <slrnvlk56u.2qa.jj@iridium.wf32df>, a
>>>  ??crit??:
>>>>
>>>> My God, how did we all manage running services before systemd came
>>>> along?
>>>
>>> Badly, with services that have crashed and nobody noticed for weeks.
>> 
>> People keep saying that. But in my experience services were run as
>> efficiently as they seem to be run today. Perhaps the team I worked in
>> knew what it was doing :-)
>
> How many custom services were you running on a single machine, just out of 
> curiosity?

What do you mean by custom? There were database services, web-based 
services, information servers other than web all running on 2 big 
servers. The infrastructure services (file servers, DNS, NTP, DHCP, 
boot servers, automatic backup etc etc) were split between 2 servers 
with backup and failover. not sure how you'd classify our mail service, 
as infrastructure or custom, but it was far from bog-standard.

[toc] | [prev] | [next] | [standalone]

#16750

On Sat, 14 Dec 2024 15:20:25 -0000 (UTC), Jim Jackson wrote:

> On 2024-12-13, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Fri, 13 Dec 2024 20:07:58 -0000 (UTC), Jim Jackson wrote:
>>
>>> On 2024-12-11, Nicolas George <nicolas$george@salle-s.org> wrote:
>>>>
>>>> Jim Jackson , dans le message <slrnvlk56u.2qa.jj@iridium.wf32df>, a
>>>>  ??crit??:
>>>>>
>>>>> My God, how did we all manage running services before systemd came
>>>>> along?
>>>>
>>>> Badly, with services that have crashed and nobody noticed for weeks.
>>> 
>>> People keep saying that. But in my experience services were run as
>>> efficiently as they seem to be run today. Perhaps the team I worked in
>>> knew what it was doing :-)
>>
>> How many custom services were you running on a single machine, just out
>> of curiosity?
> 
> What do you mean by custom?

Code that you had to write substantially from scratch, as opposed to 
configuring standard DBMS, Web, directory, MTA, DNS etc.

I ask because the standard services will already have their startup 
requirements worked out, because your own would require you to create your 
own startup scripts. Which is where the trouble would often start, with 
sysvinit.

[toc] | [prev] | [next] | [standalone]

#16760

On 2024-12-14, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sat, 14 Dec 2024 15:20:25 -0000 (UTC), Jim Jackson wrote:
>
>> On 2024-12-13, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> On Fri, 13 Dec 2024 20:07:58 -0000 (UTC), Jim Jackson wrote:
>>>
>>>> On 2024-12-11, Nicolas George <nicolas$george@salle-s.org> wrote:
>>>>>
>>>>> Jim Jackson , dans le message <slrnvlk56u.2qa.jj@iridium.wf32df>, a
>>>>>  ??crit??:
>>>>>>
>>>>>> My God, how did we all manage running services before systemd came
>>>>>> along?
>>>>>
>>>>> Badly, with services that have crashed and nobody noticed for weeks.
>>>> 
>>>> People keep saying that. But in my experience services were run as
>>>> efficiently as they seem to be run today. Perhaps the team I worked in
>>>> knew what it was doing :-)
>>>
>>> How many custom services were you running on a single machine, just out
>>> of curiosity?
>> 
>> What do you mean by custom?
>
> Code that you had to write substantially from scratch, as opposed to 
> configuring standard DBMS, Web, directory, MTA, DNS etc.


Ok I've done specific network monitoring stuff from scratch - back in
the day, when SNMP was a new thing. But it was easier to control than
other stuff because I (and a couple of others) wrote it - we knew it -
so what's difficult? We even transitioned it from pre-SYS-V init to
SYS-V init, and I remember no difficulties.

>
> I ask because the standard services will already have their startup 
> requirements worked out, because your own would require you to create your 
> own startup scripts. Which is where the trouble would often start, with 
> sysvinit.

[toc] | [prev] | [next] | [standalone]

#16763

On Mon, 16 Dec 2024 23:03:46 -0000 (UTC), Jim Jackson wrote:

> Ok I've done specific network monitoring stuff from scratch - back in
> the day, when SNMP was a new thing. But it was easier to control than
> other stuff because I (and a couple of others) wrote it - we knew it -
> so what's difficult? We even transitioned it from pre-SYS-V init to
> SYS-V init, and I remember no difficulties.

Anything with this <https://www.phoronix.com/news/Facebook-systemd-2018> 
level of complexity?

[toc] | [prev] | [next] | [standalone]

#16774

On 2024-12-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 16 Dec 2024 23:03:46 -0000 (UTC), Jim Jackson wrote:
>
>> Ok I've done specific network monitoring stuff from scratch - back in
>> the day, when SNMP was a new thing. But it was easier to control than
>> other stuff because I (and a couple of others) wrote it - we knew it -
>> so what's difficult? We even transitioned it from pre-SYS-V init to
>> SYS-V init, and I remember no difficulties.
>
> Anything with this <https://www.phoronix.com/news/Facebook-systemd-2018> 
> level of complexity?

Of course not - what a silly question. And the interesting thing was 
that their set up is SO complicated systemd is only a part of their 
solutions, which is sort of obvious. I'd have been more interested in a 
comparison of previous set up v. current with systemd.

Their process for non-stop upgrades was a fairly standard one of old 
service handing over to new and having to notify and co-operate with 
systemd because systemd handles new connections. Previously I suspect 
their processes handled incoming connections directly and there would 
have been process-process link to do the hand over. Which one works out 
easier to program and manage I'm not sure. But given they'd gone for a 
solution Centos which had systemd init they had to adapt to it.

Anyway it was interesting thanks for the pointer.

[toc] | [prev] | [next] | [standalone]

#16775

Jim Jackson <jj@franjam.org.uk> writes:
>
>
>Their process for non-stop upgrades was a fairly standard one of old 
>service handing over to new and having to notify and co-operate with 
>systemd because systemd handles new connections. Previously I suspect 
>their processes handled incoming connections directly and there would 
>have been process-process link to do the hand over. Which one works out 
>easier to program and manage I'm not sure. But given they'd gone for a 
>solution Centos which had systemd init they had to adapt to it.

Modern non-stop systems route new connections at a higher level (e.g. netscaler)
for both load balancing and resiliancy.  systemd is not (thankfully)
involved in that at all.

[toc] | [prev] | [next] | [standalone]

#16776

On 2024-12-18, Scott Lurndal <scott@slp53.sl.home> wrote:
> Jim Jackson <jj@franjam.org.uk> writes:
>>
>>
>>Their process for non-stop upgrades was a fairly standard one of old 
>>service handing over to new and having to notify and co-operate with 
>>systemd because systemd handles new connections. Previously I suspect 
>>their processes handled incoming connections directly and there would 
>>have been process-process link to do the hand over. Which one works out 
>>easier to program and manage I'm not sure. But given they'd gone for a 
>>solution Centos which had systemd init they had to adapt to it.
>
> Modern non-stop systems route new connections at a higher level (e.g. netscaler)
> for both load balancing and resiliancy.  systemd is not (thankfully)
> involved in that at all.

Indeed, and for over 20 years. But, the talk did describe the adaptations
needed for running a non-stop service on top of systemd on a single box.

[toc] | [prev] | [next] | [standalone]

#16716

On Wed, 11 Dec 2024 22:26:56 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>On Wed, 11 Dec 2024 08:33:29 -0000 (UTC), Muttley wrote:
>
>> On Tue, 10 Dec 2024 20:55:05 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>>
>>> One thing lacking from sysvinit is, while it can start a service, it
>>> cannot ensure the service was started properly, and it cannot perform
>>> reliable service shutdown. So the job of service management was really
>>> only half-done.
>> 
>> It doesn't need to , it can just spawn off a script or some other
>> program which does that which is entirely inline with the unix
>> philosophy.
>
>Which is where the trouble starts.

The trouble is with any support scripts, not with init. I've written a 
number of init scripts with a lot of surrounding logic. God knows how I'd
do that with systemd short of just getting it to call the exact same script
which rather defeats the purpose of having systemd.

>> Something Poettering never understood.
>
>Poettering understands that services don’t just to be started, they also 
>need to be managed and shut down cleanly.

Poettering created the wrong solution to the wrong problem.

[toc] | [prev] | [next] | [standalone]

#16726

On Thu, 12 Dec 2024 08:39:07 -0000 (UTC), Muttley wrote:

> On Wed, 11 Dec 2024 22:26:56 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>> On Wed, 11 Dec 2024 08:33:29 -0000 (UTC), Muttley wrote:
>>
>>> It doesn't need to , it can just spawn off a script or some other
>>> program which does that which is entirely inline with the unix
>>> philosophy.
>>
>> Which is where the trouble starts.
> 
> The trouble is with any support scripts, not with init. I've written a
> number of init scripts with a lot of surrounding logic.

I’m sure you have. Which means you are familiar with the wholesale copying 
and pasting of boilerplate from one script to the next. “What does this 
bit do?” “Don’t bother thinking too hard, just stick it in, just in case.”

> God knows how I'd do that with systemd ...

Figure out what the directives do (they’re all documented), and which 
settings will achieve the result you want. Most of the time, your service 
file will be very simple and very short, since all the common cases are 
already covered.

“Simple things should be simple, and complex things should be possible.”
    -- Alan Kay

He was talking about GUI design, but the same applies to systemd. And to a 
lot of other popular *nix software, while we’re at it.

>> Poettering understands that services don’t just to be started, they al
>> so need to be managed and shut down cleanly.
> 
> Poettering created the wrong solution to the wrong problem.

Lots of sysadmins, and distro maintainers, and developers of service apps, 
disagree.

Think of how simple it is to log error messages now: systemd automatically 
captures stderr, and shows it in your service status and in the journal.

[toc] | [prev] | [next] | [standalone]

#16733

On Thu, 12 Dec 2024 22:31:50 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>On Thu, 12 Dec 2024 08:39:07 -0000 (UTC), Muttley wrote:
>> The trouble is with any support scripts, not with init. I've written a
>> number of init scripts with a lot of surrounding logic.
>
>I’m sure you have. Which means you are familiar with the wholesale copying 
>and pasting of boilerplate from one script to the next. “What does this 
>bit do?” “Don’t bother thinking too hard, just stick it in, just in
>case.”

Its a few lines of code and usually one just copies a simple rc file and
starts from there.

>> God knows how I'd do that with systemd ...
>
>Figure out what the directives do (they’re all documented), and which 

Why TF would I want to have to leanr Yet Another Config Language when in
shell script I have a turing complete language that can do anything with the
system? You might as well say "Don't bother with that car, use this pushbike
instead."

>> Poettering created the wrong solution to the wrong problem.
>
>Lots of sysadmins, and distro maintainers, and developers of service apps, 
>disagree.

Sheep exist even i open source. That other abortion poetrring wrote pulseaudio
was shoved into every distro until people realised that all it did was 
remove the complexity of Alsa and add its own complexity in exchange. And
being built on alsa it simply added another layer and hence delay into the
sound system where you REALLY don't want delays.

>Think of how simple it is to log error messages now: systemd automatically 
>captures stderr, and shows it in your service status and in the journal.

Oh wow, is there no end to its magical abilities!

[toc] | [prev] | [next] | [standalone]

#16735

On Fri, 13 Dec 2024 10:38:51 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:

> That other abortion poetrring wrote pulseaudio was shoved into every
> distro until people realised that all it did was remove the
> complexity of Alsa and add its own complexity in exchange. And being
> built on alsa it simply added another layer and hence delay into the
> sound system where you REALLY don't want delays.

This bears repeating. Why *anybody* decided to trust the judgement of
the person who gave us the jankiest of all the incredibly janky *nix
audio subsystems is beyond comprehension.

[toc] | [prev] | [next] | [standalone]

#16739

On Fri, 13 Dec 2024 07:42:07 -0800, John Ames wrote:

> This bears repeating. Why *anybody* decided to trust the judgement of
> the person who gave us the jankiest of all the incredibly janky *nix
> audio subsystems is beyond comprehension.

There was no reason why you had to. You could easily have created your own 
distro without any of his code in it, if you wanted to. Or become an 
aficionado of one of the existing distros that did exactly that.

Open Source is all about choice. If you can’t stand the thought of people 
making different choices from you, you know what you can do.

[toc] | [prev] | [next] | [standalone]

#16749

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Fri, 13 Dec 2024 07:42:07 -0800, John Ames wrote:
>> This bears repeating. Why *anybody* decided to trust the judgement of
>> the person who gave us the jankiest of all the incredibly janky *nix
>> audio subsystems is beyond comprehension.
>
> There was no reason why you had to. You could easily have created your own 
> distro without any of his code in it, if you wanted to. Or become an 
> aficionado of one of the existing distros that did exactly that.
>
> Open Source is all about choice. If you can’t stand the thought of people 
> making different choices from you, you know what you can do.

If these people get paid by $big_name_companies, there's exactly nothing
individuals can do about that. Unless they happen to be rich enough that
they can waste a ton of money on their hobbies and then, they'd still
need to get a competent work force from somewhere.

[toc] | [prev] | [next] | [standalone]

#16752

On Sat, 14 Dec 2024 20:16:08 +0000
Rainer Weikusat <rweikusat@talktalk.net> gabbled:
>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Fri, 13 Dec 2024 07:42:07 -0800, John Ames wrote:
>>> This bears repeating. Why *anybody* decided to trust the judgement of
>>> the person who gave us the jankiest of all the incredibly janky *nix
>>> audio subsystems is beyond comprehension.
>>
>> There was no reason why you had to. You could easily have created your own 
>> distro without any of his code in it, if you wanted to. Or become an 
>> aficionado of one of the existing distros that did exactly that.
>>
>> Open Source is all about choice. If you can’t stand the thought of people 
>> making different choices from you, you know what you can do.
>
>If these people get paid by $big_name_companies, there's exactly nothing
>individuals can do about that. Unless they happen to be rich enough that
>they can waste a ton of money on their hobbies and then, they'd still
>need to get a competent work force from somewhere.

The sort of idiots who make those "why don't you write your own" remarks
probably still live with and are financed by mum and dad so don't see the
issue with spending months rolling your own system. Plus they seem to have
some kind of believe that you shouldn't criticise something unless you have
the ability to replicate it youself which means no one should ever comment on
any music, films, TV, food etc they disliked unless they could make a hollywood
blockbuster, album, whatever themselves. Its a very juvenile attitude.

[toc] | [prev] | [next] | [standalone]

#16753

Muttley@dastardlyhq.com writes:
> On Sat, 14 Dec 2024 20:16:08 +0000
> Rainer Weikusat <rweikusat@talktalk.net> gabbled:
>>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Fri, 13 Dec 2024 07:42:07 -0800, John Ames wrote:
>>>> This bears repeating. Why *anybody* decided to trust the judgement of
>>>> the person who gave us the jankiest of all the incredibly janky *nix
>>>> audio subsystems is beyond comprehension.
>>>
>>> There was no reason why you had to. You could easily have created your own 
>>> distro without any of his code in it, if you wanted to. Or become an 
>>> aficionado of one of the existing distros that did exactly that.
>>>
>>> Open Source is all about choice. If you can’t stand the thought of people 
>>> making different choices from you, you know what you can do.
>>
>>If these people get paid by $big_name_companies, there's exactly nothing
>>individuals can do about that. Unless they happen to be rich enough that
>>they can waste a ton of money on their hobbies and then, they'd still
>>need to get a competent work force from somewhere.
>
> The sort of idiots who make those "why don't you write your own" remarks
> probably still live with and are financed by mum and dad so don't see the
> issue with spending months rolling your own system.

I actually did. By the time when systemd started to become a serious
nuisance, I had just started to work on a different product. The
previous had been an (ARM9-based) UTM appliance and I actually wrote an
own init for that. I was determined to avoid doing that again but still
needed more process management than sysvinit + rc provided.

I started this as sort-of a conscious anti-systemd experiment. The idea
was that, whenever I needed some process management feature, I'd write a
(fairly small) C program to provide that and find out how far this would
get me. That was about fifteen years ago. I've meanwhile accumulated 38
of these C program with a total size of 5690 lines of code and that's
enough for all of my process management needs and I'm dealing with some
more complicated stuff then people just running web servers.

This is arguably not open source but the copyright belongs to my
employer. OTOH, if it were, mainstream Linux distributions wouldn't use
it, not the least because many people just love complicated stuff (like
systemd).

> Plus they seem to have some kind of believe that you shouldn't
> criticise something unless you have the ability to replicate it
> youself which means no one should ever comment on any music, films,
> TV, food etc they disliked unless they could make a hollywood
> blockbuster, album, whatever themselves. Its a very juvenile attitude.

Indeed.

[toc] | [prev] | [next] | [standalone]

#16754

On Sun, 15 Dec 2024 21:25:36 +0000
Rainer Weikusat <rweikusat@talktalk.net> wibbled:
>employer. OTOH, if it were, mainstream Linux distributions wouldn't use
>it, not the least because many people just love complicated stuff (like
>systemd).

True. Far too many people think complicated = clever. What they don't
understand is that really smart people have the ability to make complicated
stuff simple for the user. Sadly not an ability Poettering has.

[toc] | [prev] | [next] | [standalone]

#16757

On Mon, 16 Dec 2024 08:16:28 -0000 (UTC), Muttley wrote:

> Far too many people think complicated = clever.

You mean, clever like struggling with complicated workarounds to clunky, 
ancient init systems that don’t actually handle service management very 
well, when more modern ones solve long-standing problems in a much simpler 
and more elegant fashion?

[toc] | [prev] | [next] | [standalone]

#16764

On Mon, 16 Dec 2024 19:51:36 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>On Mon, 16 Dec 2024 08:16:28 -0000 (UTC), Muttley wrote:
>
>> Far too many people think complicated = clever.
>
>You mean, clever like struggling with complicated workarounds to clunky, 
>ancient init systems that don’t actually handle service management very 
>well, when more modern ones solve long-standing problems in a much simpler 
>and more elegant fashion?

Sure, but we're talking about systemd.

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.unix.programmer

csiph-web