| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 94:18:20 |
| Calls: | 290 |
| Calls today: | 1 |
| Files: | 904 |
| Messages: | 76,378 |
my own program and send data to it via a socket created by socketpair(). >Unfortunately "say" behaves differently depending on whether its stdin is >attached to a tty or not (and there's no cmd line option to prevent this). >With the former it'll speak after every newline, with the latter not until it >gets an EOF and I'd rather not do a fork-exec for each individual word or >phrase that needs to be spoken.
So my question is - is there a way to set up a pipe or socketpair** so that >it appears to be a tty from the exec'd programs point of view, eg ttyname() >returns non null?
In article <vh9vgr$5bb$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote: >>So my question is - is there a way to set up a pipe or socketpair** so that >>it appears to be a tty from the exec'd programs point of view, eg ttyname() >>returns non null?
I think the short answer to your question is: No.
There's no way to directly do what you want in a clean way.
Thus, all we have is kludgey workarounds. And I'm sure you've got plenty
of your own kludgey workarounds; you don't need any more from me.
That said, if was me, I'd use Expect. A few lines of Expect would do it, >such that I could send text to the process and the process would think they >were coming from a tty. In fact, if you don't want to learn Expect (i.e., >Tcl) just for this project, I think just using "unbuffer -p" (unbuffer is a >program that comes with the Expect distribution) would do it for you.
Another way might be to write an interposer so that you could fool the
"say" program into thinking it was talking to a tty even if it wasn't. I >haven't done any Mac programming in a long time (since my Mac stopped >working), but I think interposers were do-able in the Mac ecosystem.
On Sat, 16 Nov 2024 20:51:28 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) boring babbled:
In article <vh9vgr$5bb$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote: >>>So my question is - is there a way to set up a pipe or socketpair** so that >>>it appears to be a tty from the exec'd programs point of view, eg ttyname() >>>returns non null?
I think the short answer to your question is: No.
There's no way to directly do what you want in a clean way.
Thus, all we have is kludgey workarounds. And I'm sure you've got plenty >>of your own kludgey workarounds; you don't need any more from me.
That said, if was me, I'd use Expect. A few lines of Expect would do it, >>such that I could send text to the process and the process would think they >>were coming from a tty. In fact, if you don't want to learn Expect (i.e., >>Tcl) just for this project, I think just using "unbuffer -p" (unbuffer is a >>program that comes with the Expect distribution) would do it for you.
Hmm, both sound pretty kludgey too tbh. As for Tcl , thats a blast from the past. Does anyone really still use it?
So my question is - is there a way to set up a pipe or socketpair** so that it appears to be a tty from the exec'd programs point of view, eg ttyname() returns non null?[...]
** Yes I know about the master-slave ptm,pts approach and I have done that in the past but its complete overkill for this purpose.
Kind of annoying the developers of "say" didn't consider this scenario. After >all , the whole point of having a command line speech utility is for it to
be controlled by another process, its not much use on its own other than
5 mins of novelty value!
In article <vhca72$i0nn$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >....
Kind of annoying the developers of "say" didn't consider this scenario. After >>all , the whole point of having a command line speech utility is for it to >>be controlled by another process, its not much use on its own other than
5 mins of novelty value!
I assume that their intent is that if you are doing anything remotely >serious, you will use their API. The "say" program was probably a 15 minute
effort by whoever developed the API; I doubt much thought went into it
other than as a quick "proof of concept".
On 2024-11-16, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
So my question is - is there a way to set up a pipe or socketpair** so that >> it appears to be a tty from the exec'd programs point of view, eg ttyname() >> returns non null?[...]
** Yes I know about the master-slave ptm,pts approach and I have done that >in
the past but its complete overkill for this purpose.
No; you need a master/slave pseudo TTY pair connected to an active
process, which forwards between that and the socketpair or pipe.
Sockets and pipes cannot be given window dressing so that they look
like tty's. When the standard input (or output) of a process is a tty,
and that process cares about it, it will likely try operations like >tcgetattr.
There is a command line util (MacOS "say")* that I wish to use fork-exec'd from
my own program and send data to it via a socket created by socketpair(). Unfortunately "say" behaves differently depending on whether its stdin is attached to a tty or not (and there's no cmd line option to prevent this). With the former it'll speak after every newline, with the latter not until it gets an EOF and I'd rather not do a fork-exec for each individual word or phrase that needs to be spoken.
So my question is - is there a way to set up a pipe or socketpair** so that it appears to be a tty from the exec'd programs point of view, eg ttyname() returns non null?
* The MacOS speech API is Objective-C only and completely obtuse.
** Yes I know about the master-slave ptm,pts approach and I have done that in the past but its complete overkill for this purpose.
Thanks for any help
On 16.11.24 12:26, Muttley@dastardlyhq.com wrote:
There is a command line util (MacOS "say")* that I wish to use fork-exec'd >from
my own program and send data to it via a socket created by socketpair().
Unfortunately "say" behaves differently depending on whether its stdin is
attached to a tty or not (and there's no cmd line option to prevent this). >> With the former it'll speak after every newline, with the latter not until it
gets an EOF and I'd rather not do a fork-exec for each individual word or
phrase that needs to be spoken.
On shell level I'm using a program called 'pty' that takes the command
as argument to make it think it has a terminal connection. Say, instead
of calling (forking) your 'say' command you're calling (forking) the
'pty' command with your 'say' command provided as argument. And all the
gory details are kept inside the 'pty'. - I forgot whether 'pty' came
with my Linux system, or whether I downloaded it separately, or whether
I implemented or adapted the version that is published in Stevens' APUE
book (with the source code available online, IIRC). IME it's worthwhile
to have such a tool at hand; it's useful to me for various application >contexts, and the interface is clean, a separate small tool unnecessary
to be merged on source code level, and simple to use.
Janis Papanagnou <janis_papanagnou@hotmail.com> writes:
On 16.11.24 12:26, Muttley@dastardlyhq.com wrote:
There is a command line util (MacOS "say")* that I wish to use
fork-exec'd from
my own program and send data to it via a socket created by socketpair(). >>> Unfortunately "say" behaves differently depending on whether its stdin is >>> attached to a tty or not (and there's no cmd line option to prevent this). >>> With the former it'll speak after every newline, with the latter not until >it
gets an EOF and I'd rather not do a fork-exec for each individual word or >>> phrase that needs to be spoken.
On shell level I'm using a program called 'pty' that takes the command
as argument to make it think it has a terminal connection.
‘script’ will do the same and already exists on macOS. It likes to write >stdout/stderr to a file as well as its own otuput, but you can use
/dev/null for that.
I had some trouble getting it to play fully nicely with say, but some >fiddling might get the desired effect.
On 16.11.24 12:26, Muttley@dastardlyhq.com wrote:
There is a command line util (MacOS "say")* that I wish to use
fork-exec'd from
my own program and send data to it via a socket created by socketpair().
Unfortunately "say" behaves differently depending on whether its stdin is
attached to a tty or not (and there's no cmd line option to prevent this). >> With the former it'll speak after every newline, with the latter not until it
gets an EOF and I'd rather not do a fork-exec for each individual word or
phrase that needs to be spoken.
On shell level I'm using a program called 'pty' that takes the command
as argument to make it think it has a terminal connection.
On 2024-11-16, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:*SKIP* [ 18 lines 2 levels deep]
So my question is - is there a way to set up a pipe or socketpair**
so that it appears to be a tty from the exec'd programs point of
view, eg ttyname() returns non null?
The GNU C Library has a mechanism to override this, driven by
environment variables, and a wrapper utility callet "stdbuf" which
uses the environment variables to tell a child process what buffering discipline to use for stdin, stdour or stderr.
with <20241117093714.675@kylheku.com> Kaz Kylheku wrote:
On 2024-11-16, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
*SKIP* [ 18 lines 2 levels deep]So my question is - is there a way to set up a pipe or socketpair**
so that it appears to be a tty from the exec'd programs point of
view, eg ttyname() returns non null?
The GNU C Library has a mechanism to override this, driven by
environment variables, and a wrapper utility callet "stdbuf" which
uses the environment variables to tell a child process what buffering
discipline to use for stdin, stdour or stderr.
Now I understand what's going on (back then I've come to conclusions and >called names (AKA -- I'd been pissed off by 9 out of 12); I was
wrong). But variables? Neither stdbuf(1) nor setbuf(3) give any
directions. What should I read?
with <20241117093714.675@kylheku.com> Kaz Kylheku wrote:
On 2024-11-16, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
*SKIP* [ 18 lines 2 levels deep]So my question is - is there a way to set up a pipe or socketpair**
so that it appears to be a tty from the exec'd programs point of
view, eg ttyname() returns non null?
The GNU C Library has a mechanism to override this, driven by
environment variables, and a wrapper utility callet "stdbuf" which
uses the environment variables to tell a child process what buffering
discipline to use for stdin, stdour or stderr.
Now I understand what's going on (back then I've come to conclusions and called names (AKA -- I'd been pissed off by 9 out of 12); I was
wrong). But variables? Neither stdbuf(1) nor setbuf(3) give any
directions. What should I read?
On 2024-11-18, Eric Pozharski <apple.universe@posteo.net> wrote:*SKIP* [ 2 lines 2 levels deep]
with <20241117093714.675@kylheku.com> Kaz Kylheku wrote:
On 2024-11-16, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com>
wrote:
*SKIP* [ 18 lines 2 levels deep]So my question is - is there a way to set up a pipe or socketpair**
so that it appears to be a tty from the exec'd programs point of
view, eg ttyname() returns non null?
The GNU C Library has a mechanism to override this, driven byNow I understand what's going on (back then I've come to conclusions
environment variables, and a wrapper utility callet "stdbuf" which
uses the environment variables to tell a child process what
buffering discipline to use for stdin, stdour or stderr.
directions. What should I read?Firstly, I apologize for my bad here, Eric. This is not done in glibc,
but actually by a preloaded shared library called libstdbuf.so. That
comes from CoreUtils.
There is a command line util (MacOS "say")* that I wish to use fork-exec'd from
my own program and send data to it via a socket created by socketpair(). Unfortunately "say" behaves differently depending on whether its stdin is attached to a tty or not (and there's no cmd line option to prevent this). With the former it'll speak after every newline, with the latter not until it gets an EOF and I'd rather not do a fork-exec for each individual word or phrase that needs to be spoken.
So my question is - is there a way to set up a pipe or socketpair** so that it appears to be a tty from the exec'd programs point of view, eg ttyname() returns non null?
* The MacOS speech API is Objective-C only and completely obtuse.
** Yes I know about the master-slave ptm,pts approach and I have done that in the past but its complete overkill for this purpose.
Thanks for any help
In article <vh9vgr$5bb$1@dont-email.me>,
Muttley@dastardlyhq.com writes:
There is a command line util (MacOS "say")* that I wish to use fork-exec'd >from
my own program and send data to it via a socket created by socketpair().
Unfortunately "say" behaves differently depending on whether its stdin is
attached to a tty or not (and there's no cmd line option to prevent this). >> With the former it'll speak after every newline, with the latter not until >it
gets an EOF and I'd rather not do a fork-exec for each individual word or
phrase that needs to be spoken.
So my question is - is there a way to set up a pipe or socketpair** so that >> it appears to be a tty from the exec'd programs point of view, eg ttyname() >> returns non null?
* The MacOS speech API is Objective-C only and completely obtuse.
** Yes I know about the master-slave ptm,pts approach and I have done that >in
the past but its complete overkill for this purpose.
Thanks for any help
Not on a Mac. Use "expect" which does the pts/pty stuff for you.
(on a system where pipes are STREAMS based, it might be possible
to come up with a module that made a pipe pretend on one side to be a tty; >but you'd have to get into some nasty kernel coding to do that)
(on a system where pipes are STREAMS based, it might be possible to
come up with a module that made a pipe pretend on one side to be a
tty; but you'd have to get into some nasty kernel coding to do that)
In article <vh9vgr$5bb$1@dont-email.me>,
Muttley@dastardlyhq.com writes:
There is a command line util (MacOS "say")* that I wish to use fork-exec'd from
my own program and send data to it via a socket created by socketpair().
Unfortunately "say" behaves differently depending on whether its stdin is
attached to a tty or not (and there's no cmd line option to prevent this). >> With the former it'll speak after every newline, with the latter not until it
gets an EOF and I'd rather not do a fork-exec for each individual word or
phrase that needs to be spoken.
So my question is - is there a way to set up a pipe or socketpair** so that >> it appears to be a tty from the exec'd programs point of view, eg ttyname() >> returns non null?
* The MacOS speech API is Objective-C only and completely obtuse.
** Yes I know about the master-slave ptm,pts approach and I have done that in
the past but its complete overkill for this purpose.
Thanks for any help
Not on a Mac. Use "expect" which does the pts/pty stuff for you.
(on a system where pipes are STREAMS based, it might be possible
to come up with a module that made a pipe pretend on one side to be a tty; >but you'd have to get into some nasty kernel coding to do that)
I'm wondering on Linux if it would be enough on Linux to spoof ttyname()
and isatty() using LD_PRELOAD. However it seems doing something similar
on a Mac is the usual over complicated Apple hot mess.
On Tue, 3 Dec 2024 08:20:51 -0000 (UTC), Muttley wrote:
I'm wondering on Linux if it would be enough on Linux to spoof ttyname()
and isatty() using LD_PRELOAD. However it seems doing something similar
on a Mac is the usual over complicated Apple hot mess.
macOS may be a licensee of the “Unix” trademark, but it does not work the >way people expect when they think of the term “Unix”.
Linux is far closer to the unix philosphy (ignoring systemd) ...
On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
Linux is far closer to the unix philosphy (ignoring systemd) ...
Which "unix philosophy" would that be?
Which “unix philosophy” would that be?
On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
Linux is far closer to the unix philosphy (ignoring systemd) ...
Which “unix philosophy” would that be?
In article <vir23n$17csf$5@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
Linux is far closer to the unix philosphy (ignoring systemd) ...
Which "unix philosophy" would that be?
Wouldn't it be easier to just use Google (or whatever search engine you >favor) to find out what the Unix philosphy is?
In article <viri3s$1ac00$1@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:
In article <vir23n$17csf$5@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
Linux is far closer to the unix philosphy (ignoring systemd) ...
Which "unix philosophy" would that be?
Wouldn't it be easier to just use Google (or whatever search engine you >>favor) to find out what the Unix philosphy is?
Why do people continue to try and engage with Lawrence in good
faith? He's a rather obvious troll.
In article <vis90n$5d5$1@reader2.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
is obvious trollery, not a legitimate question. If it *were* a legitimate >question, then Googling would give him his answer. But it isn't, so it >won't.,.
On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
Linux is far closer to the unix philosphy (ignoring systemd) ...
Which “unix philosophy” would that be?
The one where init does a single task instead of spreading itself
throughout the system ...
On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
Linux is far closer to the unix philosphy (ignoring systemd) ...
Which “unix philosophy” would that be?
The one where init does a single task instead of spreading itself
throughout the system ...
On Thu, 5 Dec 2024 08:19:46 -0000 (UTC), Muttley wrote:
On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
Linux is far closer to the unix philosphy (ignoring systemd) ...
Which “unix philosophy” would that be?
The one where init does a single task instead of spreading itself
throughout the system ...
What “single task” did init do?
On Thu, 5 Dec 2024 08:19:46 -0000 (UTC), Muttley wrote:
On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
Linux is far closer to the unix philosphy (ignoring systemd) ...
Which “unix philosophy” would that be?
The one where init does a single task instead of spreading itself
throughout the system ...
What “single task” did init do?
On Thu, 5 Dec 2024 08:19:46 -0000 (UTC), Muttley wrote:
On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
Linux is far closer to the unix philosphy (ignoring systemd) ...
Which “unix philosophy” would that be?
The one where init does a single task instead of spreading itself
throughout the system ...
What “single task” did init do?
* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate
This was all before systemd came on the scene.
On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
What “single task” did init do?
Boot the system to usable state.
On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
What would you say systemd does that is not related to that?
QR codes?
On Fri, 6 Dec 2024 10:28:15 -0000 (UTC), Muttley wrote:
On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
What “single task” did init do?
Boot the system to usable state.
What would you say systemd does that is not related to that?
On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
On Fri, 6 Dec 2024 10:28:15 -0000 (UTC), Muttley wrote:
On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
What “single task” did init do?
Boot the system to usable state.
What would you say systemd does that is not related to that?
Networking, including DNS
Graphics
Logging
systemd-boot
Basically init should start the system, maintain some the running of
some essential daemons and then leave well alone.
On Thu, 5 Dec 2024 08:19:46 -0000 (UTC), Muttley wrote:
On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
Linux is far closer to the unix philosphy (ignoring systemd) ...
Which ???unix philosophy??? would that be?
The one where init does a single task instead of spreading itself
throughout the system ...
What ???single task??? did init do?
* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate
This was all before systemd came on the scene.
Actually traditional Unix "init" didn't do ALL those things.
On 2024-12-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
What ???single task??? did init do?
* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate
This was all before systemd came on the scene.
Actually traditional Unix "init" didn't do ALL those things. Most
tended to have the inittab config file. Even busybox's init has.
Jim Jackson <jj@franjam.org.uk> writes:
On 2024-12-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
What ???single task??? did init do?
* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate
This was all before systemd came on the scene.
Actually traditional Unix "init" didn't do ALL those things. Most
tended to have the inittab config file. Even busybox's init has.
Depends if you mean init=/sbin/init or init=the entire sysvinit system.
If you(plural) are going talk about init systems then you need to agree >terms.
On Tue, 10 Dec 2024 08:50:20 +0000
Richard Kettlewell <invalid@invalid.invalid> wibbled:
Jim Jackson <jj@franjam.org.uk> writes:
On 2024-12-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
What ???single task??? did init do?
* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate >>>>
This was all before systemd came on the scene.
Actually traditional Unix "init" didn't do ALL those things. Most
tended to have the inittab config file. Even busybox's init has.
Depends if you mean init=/sbin/init or init=the entire sysvinit system.
If you(plural) are going talk about init systems then you need to agree >>terms.
Its probably fair to say that because the traditional init system uses
shell scripts and hence can do anything you like they often did. But the
core part should really just be limited to starting the machine and getting enough things running for a user to log on (or if its a black box to do its task).
On Mon, 9 Dec 2024 20:28:31 -0000 (UTC), Jim Jackson wrote:
Actually traditional Unix "init" didn't do ALL those things.
sysvinit certainly did. That is the usual standard of comparison, is it
not?
On Tue, 10 Dec 2024 09:23:13 -0000 (UTC), Muttley wrote:
But the core part should really just be limited to starting the
machine and getting enough things running for a user to log on (or
if its a black box to do its task).
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.
But the core part should really just be limited to starting the
machine and getting enough things running for a user to log on (or
if its a black box to do its task).
On Tue, 10 Dec 2024 09:23:13 -0000 (UTC), Muttley wrote:
But the core part should really just be limited to starting the
machine and getting enough things running for a user to log on (or
if its a black box to do its task).
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.
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.
Something Poettering never understood.
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.
Something Poettering never understood.
Poettering understands that services don???t just to be started, they also need to be managed and shut down cleanly.
My God, how did we all manage running services before systemd came along?
Some teams have been working on better replacement for SysV init, but
without the industrial strength of Red Hat they could only stay niche.
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.
Something Poettering never understood.
Poettering understands that services don’t just to be started, they also >need to be managed and shut down cleanly.
On 11 Dec 2024 23:34:39 GMT, Nicolas George wrote:
Some teams have been working on better replacement for SysV init, but
without the industrial strength of Red Hat they could only stay niche.
I wonder what you think Red Hat’s business model could be in forcing >competitors to adopt technology they developed without paying for it.
My own case is certainly niche, though s6 is extensively used for
containers, via the s6-overlay project, which currently has ~3.8k stars
on GitHub:
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.
God knows how I'd do that with systemd ...
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.
So the other distros thought they needed to
follow suite in order to pick up some of that market.
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.”
God knows how I'd do that with systemd ...
Figure out what the directives do (they’re all documented), and which
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.
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.
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.
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.
Poettering understands that services don???t just to be started, they al >>> so need to be managed and shut down cleanly.
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 :-)
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.
On Thu, 5 Dec 2024 08:19:46 -0000 (UTC), Muttley wrote:
On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
Linux is far closer to the unix philosphy (ignoring systemd) ...
Which “unix philosophy” would that be?
The one where init does a single task instead of spreading itself
throughout the system ...
What “single task” did init do?
* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate
This was all before systemd came on the scene.
On Tue, 3 Dec 2024 08:20:51 -0000 (UTC), Muttley wrote:
I'm wondering on Linux if it would be enough on Linux to spoof ttyname()
and isatty() using LD_PRELOAD. However it seems doing something similar
on a Mac is the usual over complicated Apple hot mess.
macOS may be a licensee of the “Unix” trademark, but it does not work the way people expect when they think of the term “Unix”.
On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
On Fri, 6 Dec 2024 10:28:15 -0000 (UTC), Muttley wrote:
On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
What “single task” did init do?
Boot the system to usable state.
What would you say systemd does that is not related to that?
Networking, including DNS
Graphics
Logging
systemd-boot
Basically init should start the system, maintain some the running of
some essential daemons and then leave well alone.
However I just tried this with some old preloadable modules (of
suitable architecture), and it no longer seems to work. Not sure what
else I have to do now. Maybe this changed/broke when most dynamic libraries >were replaced by a pre-linked cache files that would map in in their entirety >at reserved address(es). Faster, more secure, but maybe less flexible. >Haven't googled enough yet to find the answer, if any.
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.
In article <vit3dg$1quau$1@dont-email.me>,
This was all before systemd came on the scene.
It spawned other processes, and where the idea of run levels existed, >selected what to spawn based on those.
It did not do tricky communication with processes, elaborately
manipulate their initial environment, and except for adopting orphans
MacOS launchd is arguably even worse insofar as it also has things like
Mach namespaces to deal with.
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?
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.
MacOS launchd is arguably even worse insofar as it also has things like
Mach namespaces to deal with.
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?
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.
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.
employer. OTOH, if it were, mainstream Linux distributions wouldn't use
it, not the least because many people just love complicated stuff (like >systemd).
In article <vinp86$avd9$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Tue, 3 Dec 2024 08:20:51 -0000 (UTC), Muttley wrote:
I'm wondering on Linux if it would be enough on Linux to spoof ttyname() >>> and isatty() using LD_PRELOAD. However it seems doing something similar
on a Mac is the usual over complicated Apple hot mess.
macOS may be a licensee of the "Unix" trademark, but it does not work the
way people expect when they think of the term "Unix".
It probably does as of the version of the formal specification they met
to be allowed to use the trademark.
The fact that people are free to make stupid choices does not mean that
other people aren't allowed to call out stupidity where they see it.
Far too many people think complicated = clever.
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.
On Mon, 16 Dec 2024 07:55:19 -0800, John Ames wrote:
The fact that people are free to make stupid choices does not mean that
other people aren't allowed to call out stupidity where they see it.
Notice that all the complaints seem to go in one direction, not the other?
We only see systemd-haters complaining about those using it, you don???t see systemd users complaining about those who don???t?
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 think some of us get a bit pissed at some people making out
that previous inits were (almost) unworkable - which is palpably false.
On Mon, 16 Dec 2024 23:07:37 -0000 (UTC), Jim Jackson wrote:
... I think some of us get a bit pissed at some people making out
that previous inits were (almost) unworkable - which is palpably false.
Do you understand what a “strawman” argument is?
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?
On Mon, 16 Dec 2024 07:55:19 -0800, John Ames wrote:
The fact that people are free to make stupid choices does not mean that
other people aren't allowed to call out stupidity where they see it.
Notice that all the complaints seem to go in one direction, not the other?
We only see systemd-haters complaining about those using it, you don’t see systemd users complaining about those who don’t?
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?
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.
On Tue, 17 Dec 2024 02:37:24 -0000 (UTC) Lawrence D'Oliveiro
<ldo@nz.invalid> wibbled:
On Mon, 16 Dec 2024 23:07:37 -0000 (UTC), Jim Jackson wrote:
... I think some of us get a bit pissed at some people making out that
previous inits were (almost) unworkable - which is palpably false.
Do you understand what a “strawman” argument is?
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Mon, 16 Dec 2024 07:55:19 -0800, John Ames wrote:
The fact that people are free to make stupid choices does not mean
that other people aren't allowed to call out stupidity where they
see it.
Notice that all the complaints seem to go in one direction, not the
other? We only see systemd-haters complaining about those using it,
you don???t see systemd users complaining about those who don???t?
No. But I think some of us get a bit pissed at some people making out
that previous inits were (almost) unworkable - which is palpably false.
Whether systemd was the best possible design, or just the best option available, is another question, and perhaps more opinion-based.
Jim Jackson <jj@franjam.org.uk> writes:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Mon, 16 Dec 2024 07:55:19 -0800, John Ames wrote:
The fact that people are free to make stupid choices does not mean
that other people aren't allowed to call out stupidity where they
see it.
Notice that all the complaints seem to go in one direction, not the
other? We only see systemd-haters complaining about those using it,
you don???t see systemd users complaining about those who don???t?
No. But I think some of us get a bit pissed at some people making out
that previous inits were (almost) unworkable - which is palpably false.
‘Unworkable’ may be an exaggeration, but the practical issues and functionality gaps were real; even if you didn’t personally experience them, other people did. I think there were at least ten different
attempts to come up with something better in the free software world
alone. Meanwhile the commercial Unixes largely got their act together
long before Linux did.
Whether systemd was the best possible design, or just the best option available,
On Tue, 17 Dec 2024 19:48:51 +0000, Richard Kettlewell wrote:
Whether systemd was the best possible design, or just the best option
available, is another question, and perhaps more opinion-based.
There were, and are, other open-source choices available. Nobody is
holding a gun to anybodys head.
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?
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.
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.