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 rCLUnixrCY trademark, but it does not work the >way people expect when they think of the term rCLUnixrCY.
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 rCLunix philosophyrCY 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 rCLunix philosophyrCY 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 rCLunix philosophyrCY 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 rCLunix philosophyrCY 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 rCLunix philosophyrCY would that be?
The one where init does a single task instead of spreading itself
throughout the system ...
What rCLsingle taskrCY 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 rCLunix philosophyrCY would that be?
The one where init does a single task instead of spreading itself
throughout the system ...
What rCLsingle taskrCY 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 rCLunix philosophyrCY would that be?
The one where init does a single task instead of spreading itself
throughout the system ...
What rCLsingle taskrCY 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 rCLsingle taskrCY 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> 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 rCLsingle taskrCY did init do?
Boot the system to usable state.
What would you say systemd does that is not related to that?
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.
In article <vj16j0$30r12$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote: >....
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.
I agree with you. But it underscores a major difference between two very >different ways of thinking about computing, which can be described as >"Unix-think" vs. "Windows-think".
systemd represents nothing so much as the bringing of "Windows-think" to Unix.
If one embraces "Windows-think", then systemd makes complete sense.
If one embraces "Windows-think", then systemd makes complete sense.
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 rCLsingle taskrCY 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.
In article <vj16j0$30r12$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote: ...
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.
I agree with you. But it underscores a major difference between two very different ways of thinking about computing, which can be described as "Unix-think" vs. "Windows-think".
systemd represents nothing so much as the bringing of "Windows-think" to Unix.
If one embraces "Windows-think", then systemd makes complete sense.
In fact, systemd is a lot of like the original goal of MS's "dot net",
which was to put a solid wall between the applications programmer and the actual operating system.
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?
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 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?
Jim Jackson , dans le message <slrnvlk56u.2qa.jj@iridium.wf32df>, a
|-crit-a:
My God, how did we all manage running services before systemd came along?
Badly, with services that have crashed and nobody noticed for weeks.
Some teams have been working on better replacement for SysV init, but
without the industrial strength of Red Hat they could only stay niche.
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 donrCOt 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 HatrCOs 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:
So the other distros thought they needed to
follow suite in order to pick up some of that market.
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 donrCOt just to be started, they al
so need to be managed and shut down cleanly.
Poettering created the wrong solution to the wrong problem.
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.
IrCOm sure you have. Which means you are familiar with the wholesale copying >and pasting of boilerplate from one script to the next. rCLWhat does this >bit do?rCY rCLDonrCOt bother thinking too hard, just stick it in, just in >case.rCY
God knows how I'd do that with systemd ...
Figure out what the directives do (theyrCOre 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.
IrCOm sure you have. Which means you are familiar with the wholesale copying and pasting of boilerplate from one script to the next. rCLWhat does this bit do?rCY rCLDonrCOt bother thinking too hard, just stick it in, just in case.rCY
God knows how I'd do that with systemd ...
Figure out what the directives do (theyrCOre 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.
rCLSimple things should be simple, and complex things should be possible.rCY
-- Alan Kay
He was talking about GUI design, but the same applies to systemd. And to a lot of other popular *nix software, while werCOre at it.
Poettering understands that services donrCOt 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.
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.
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-a:
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 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 rCLUnixrCY trademark, but it does not work the
way people expect when they think of the term rCLUnixrCY.
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 rCLunix philosophyrCY would that be?
The one where init does a single task instead of spreading itself
throughout the system ...
What rCLsingle taskrCY 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 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 rCLsingle taskrCY 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 Sat, 7 Dec 2024 15:00:50 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) gabbled:
In article <vj16j0$30r12$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote: >>....
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.
I agree with you. But it underscores a major difference between two very >>different ways of thinking about computing, which can be described as >>"Unix-think" vs. "Windows-think".
systemd represents nothing so much as the bringing of "Windows-think" to Unix.
If one embraces "Windows-think", then systemd makes complete sense.
Yes, I've heard that said before and it does ring true. I guess we should be thankful that systemd still uses text based config but I wouldn't be surprised
if some Windows like binary registry isn't somewhere on the horizon. Of course
Poettering has worked for MS for a long time so one can see where all his bad ideas come from.j
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.
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.
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.
AIX ("AIX Isn't uniX") [...]
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 canrCOt stand the thought of people making different choices from you, you know what you can do.
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?
MacOS launchd is arguably even worse insofar as it also has things like
Mach namespaces to deal with.
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 canrCOt 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 canrCOt 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.
There was no reason why you had to. You could easily have createdHave done - been running Devuan since 2016.
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 canrCOt stand the thought ofThe fact that people are free to make stupid choices does not mean that
people making different choices from you, you know what you can do.
Far too many people think complicated = clever.
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 theThat would likely be because systemd users are getting what they want,
other? We only see systemd-haters complaining about those using it,
you donrCOt see systemd users complaining about those who donrCOt?
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.--- Synchronet 3.21d-Linux NewsLink 1.2
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?
... I think some of us get a bit pissed at some people making out
that previous inits were (almost) unworkable - which is palpably false.
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.
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 donrCOt 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 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 rCLstrawmanrCY 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 donrCOt 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 donrCOt see systemd users complaining about those who donrCOt?
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 donrCOt 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 rCLstrawmanrCY 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.
rCyUnworkablerCO may be an exaggeration, but the practical issues and functionality gaps were real; even if you didnrCOt 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.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 63 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 492924:49:29 |
| Calls: | 840 |
| Calls today: | 1 |
| Files: | 1,300 |
| D/L today: |
5 files (16,259K bytes) |
| Messages: | 258,313 |