On 09/09/2023 23:53, bad sector wrote:
> On 2023-09-09 15:16, Jonathan N. Little wrote:
>> bad sector wrote:
>>> "I advise against removing snap support from Ubuntu as it is built-in
>>> with the system.
>>
>> "built-in with the system" Sorry I am calling bs on that one. You can
>> easily remove it, it is not "built-in"
>
> OK, take it up with the copuke guru who wrote it. Me I took it out, then I couldn't log in any more, then I backleveled
> and now I'm writing from it. End of story.
>
>
>
<..snipped...>

probably PBK&C
Not a guru, myself. Followd easy-to-find instructions, now running fine withot snap Ub. 20.04, fully updated.

--
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#befor

On 9/10/23 01:00, Henry Crun wrote:
> On 09/09/2023 23:53, bad sector wrote:
>> On 2023-09-09 15:16, Jonathan N. Little wrote:
>>> bad sector wrote:
>>>> "I advise against removing snap support from Ubuntu as it is built-in
>>>> with the system.
>>>
>>> "built-in with the system" Sorry I am calling bs on that one. You can
>>> easily remove it, it is not "built-in"
>>
>> OK, take it up with the copuke guru who wrote it. Me I took it out,
>> then I couldn't log in any more, then I backleveled and now I'm
>> writing from it. End of story.
>>
> <..snipped...>
>
> probably PBK&C

That's always possible but the steps listed really exlude unrelated
interventions.

> Not a guru, myself. Followd easy-to-find instructions, now running fine
> withot snap Ub. 20.04, fully updated.

I followed the instructions:

1
removed all the 'snap-listed' snap-based packages and then

2
removed all the snap-system packagess that remained.

I did nothing else. I might try again if and when I have time.

On 10/09/2023 14:34, bad sector wrote:
> On 9/10/23 01:00, Henry Crun wrote:
>> On 09/09/2023 23:53, bad sector wrote:
>>> On 2023-09-09 15:16, Jonathan N. Little wrote:
>>>> bad sector wrote:
>>>>> "I advise against removing snap support from Ubuntu as it is built-in
>>>>> with the system.
>>>>
>>>> "built-in with the system" Sorry I am calling bs on that one. You can
>>>> easily remove it, it is not "built-in"
>>>
>>> OK, take it up with the copuke guru who wrote it. Me I took it out, then I couldn't log in any more, then I
>>> backleveled and now I'm writing from it. End of story.
>>>
>> <..snipped...>
>>
>> probably PBK&C
>
> That's always possible but the steps listed really exlude unrelated interventions.
>
>> Not a guru, myself. Followd easy-to-find instructions, now running fine withot snap Ub. 20.04, fully updated.
>
> I followed the instructions:
>
> 1
> removed all the 'snap-listed' snap-based packages and then
>
> 2
> removed all the snap-system packagess that remained.
>
> I did nothing else. I might try again if and when I have time.
>
>
>
I did this over a year ago, and the site where I read the instructions is no longer accessable. But I do recall there
being more ste[s than what you mentioned. Sorry, memory cells are fading...

--
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#befor

On 9/10/23 00:53, this is what azigni wrote:
> I have donated $0.00 to Linux. I'm grateful for Linux in all its forms. Be grateful, you too can be a user for $0.00. If
> that isn't good enough, move on to another OS.
>
>
I thought about Mint's plea for donations, irregardless of which way the donations are going, I put in $25 last month.
I guess I was in just that right mood and as much as I use my machine, and the hours of fun and use I get a day out of
it, I thought $25 was a cheap expense. Not that it is flawless, just quite useful.

Soap box over.
--
Linux Mint 21.2 Cinnamon
Al

Henry Crun wrote:
> On 10/09/2023 14:34, bad sector wrote:
>> On 9/10/23 01:00, Henry Crun wrote:
>>> On 09/09/2023 23:53, bad sector wrote:
>>>> On 2023-09-09 15:16, Jonathan N. Little wrote:
>>>>> bad sector wrote:
>>>>>> "I advise against removing snap support from Ubuntu as it is built-in
>>>>>> with the system.
>>>>>
>>>>> "built-in with the system" Sorry I am calling bs on that one. You can
>>>>> easily remove it, it is not "built-in"
>>>>
>>>> OK, take it up with the copuke guru who wrote it. Me I took it out,
>>>> then I couldn't log in any more, then I backleveled and now I'm
>>>> writing from it. End of story.
>>>>
>>> <..snipped...>
>>>
>>> probably PBK&C
>>
>> That's always possible but the steps listed really exlude unrelated
>> interventions.
>>
>>> Not a guru, myself. Followd easy-to-find instructions, now running
>>> fine withot snap Ub. 20.04, fully updated.
>>
>> I followed the instructions:
>>
>> 1
>> removed all the 'snap-listed' snap-based packages and then
>>
>> 2
>> removed all the snap-system packagess that remained.
>>
>> I did nothing else. I might try again if and when I have time.
>>
>>
>>
> I did this over a year ago, and the site where I read the instructions
> is no longer accessable. But I do recall there being more ste[s than
> what you mentioned. Sorry, memory cells are fading...
>

Basically following these instructions, (one of many sites with same info):

<https://www.omgubuntu.co.uk/2022/04/how-to-install-firefox-deb-apt-ubuntu-22-04>

Then completely remove snapd if you have not other snap apps

sudo apt remove snapd

That is it.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

On 9/10/23 08:56, Henry Crun wrote:
> On 10/09/2023 14:34, bad sector wrote:
>> On 9/10/23 01:00, Henry Crun wrote:
>>> On 09/09/2023 23:53, bad sector wrote:
>>>> On 2023-09-09 15:16, Jonathan N. Little wrote:
>>>>> bad sector wrote:
>>>>>> "I advise against removing snap support from Ubuntu as it is built-in
>>>>>> with the system.
>>>>>
>>>>> "built-in with the system" Sorry I am calling bs on that one. You can
>>>>> easily remove it, it is not "built-in"
>>>>
>>>> OK, take it up with the copuke guru who wrote it. Me I took it out,
>>>> then I couldn't log in any more, then I backleveled and now I'm
>>>> writing from it. End of story.
>>>>
>>> <..snipped...>
>>>
>>> probably PBK&C
>>
>> That's always possible but the steps listed really exlude unrelated
>> interventions.
>>
>>> Not a guru, myself. Followd easy-to-find instructions, now running
>>> fine withot snap Ub. 20.04, fully updated.
>>
>> I followed the instructions:
>>
>> 1
>> removed all the 'snap-listed' snap-based packages and then
>>
>> 2
>> removed all the snap-system packagess that remained.
>>
>> I did nothing else. I might try again if and when I have time.
>>
> I did this over a year ago, and the site where I read the instructions
> is no longer accessable. But I do recall there being more ste[s than
> what you mentioned. Sorry, memory cells are fading...

Familiar :-)

No rush, I fixed a hsitload of outstanding issues so my ubuntu
2do list is _almost_ clear

On Sat, 09 Sep 2023 15:36:57 -0400, David W. Hodgins wrote:

>
> If redhat and/or ibm ever decide to make changes to systemd that annoy enough
> developers and distribution creators, then like any gpl licensed software, it
> will get forked.
>

There is much more to GNU/Linux than developers and distro creators. There
are also USERS and a LOT of users do not desire systemd, GNOME, KDE, etc.

But the voice of these users is totally disregarded because the developers
and distro maintainers have the "we know best" attitude.

This is no delusion. The "we know best and let the user be damned" attitude
is perhaps the norm among developers and distro maintainers.

There are some few exceptions, with Gentoo being the most significant.

It it were not for Gentoo I would not be able to maintain my custom GNU/Linux
system as I desire.

On 9/10/2023 11:02 AM, Jonathan N. Little wrote:
> Henry Crun wrote:
>> On 10/09/2023 14:34, bad sector wrote:
>>> On 9/10/23 01:00, Henry Crun wrote:
>>>> On 09/09/2023 23:53, bad sector wrote:
>>>>> On 2023-09-09 15:16, Jonathan N. Little wrote:
>>>>>> bad sector wrote:
>>>>>>> "I advise against removing snap support from Ubuntu as it is built-in
>>>>>>> with the system.
>>>>>>
>>>>>> "built-in with the system" Sorry I am calling bs on that one. You can
>>>>>> easily remove it, it is not "built-in"
>>>>>
>>>>> OK, take it up with the copuke guru who wrote it. Me I took it out,
>>>>> then I couldn't log in any more, then I backleveled and now I'm
>>>>> writing from it. End of story.
>>>>>
>>>> <..snipped...>
>>>>
>>>> probably PBK&C
>>>
>>> That's always possible but the steps listed really exlude unrelated
>>> interventions.
>>>
>>>> Not a guru, myself. Followd easy-to-find instructions, now running
>>>> fine withot snap Ub. 20.04, fully updated.
>>>
>>> I followed the instructions:
>>>
>>> 1
>>> removed all the 'snap-listed' snap-based packages and then
>>>
>>> 2
>>> removed all the snap-system packagess that remained.
>>>
>>> I did nothing else. I might try again if and when I have time.
>>>
>>>
>>>
>> I did this over a year ago, and the site where I read the instructions
>> is no longer accessable. But I do recall there being more ste[s than
>> what you mentioned. Sorry, memory cells are fading...
>>
>
> Basically following these instructions, (one of many sites with same info):
>
> <https://www.omgubuntu.co.uk/2022/04/how-to-install-firefox-deb-apt-ubuntu-22-04>
>
> Then completely remove snapd if you have not other snap apps
>
> sudo apt remove snapd
>
> That is it.
>

When I do

snap list

I see a "gnome" entry. I see Firefox too. In the tree,
Firefox is only available as a Snap, not as a .deb (whereas
Firefox is a .deb on Mint and acquired directly from Mozilla
in a brown paper bag).

If I do this

sudo apt remove snapd

then before and after I reboot the VM, the loop mounts are still there,
and the Snap packages are still running. The loop mounts are on top of
mount point /snap and thus the 4GB we see in the tree there, is all
squashfs mounts on top of /snap.

bullwinkle@SUPERFLY:~$ cat /etc/mtab
....
/dev/loop2 /snap/bare/5 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
/dev/loop3 /snap/core22/607 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
/dev/loop0 /snap/core22/858 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0

/dev/loop1 /snap/gnome-42-2204/126 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0 <=== Trouble ???
/dev/loop4 /snap/firefox/2517 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0 <=== Trouble ???

/dev/loop5 /snap/snapd-desktop-integration/83 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
/dev/sda2 /var/snap/firefox/common/host-hunspell ext4 ro,noexec,noatime 0 0
/dev/loop10 /snap/snapd/18933 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
/dev/loop8 /snap/gtk-common-themes/1535 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
/dev/loop7 /snap/gnome-42-2204/87 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
/dev/loop6 /snap/snap-store/959 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
/dev/loop9 /snap/snapd/19457 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
....
bullwinkle@SUPERFLY:~$

However, with no snapd, this command no longer works.

snap list # command not found

Doing that seems to remove the management of it, at least.

If, using Synaptic, I attempt the equivalent of

sudo apt install firefox

then it includes as a dependency, the snapd package I have just removed.

So not only will I have to switch over my Firefox, before doing
additional damage, I'll need to find Gnome DE too, as a .deb .
Ubuntu Studio might have different dependencies, similar to those.

*******

I gave it a try, and Ubuntu 23.04 survived the removal of its nads.

sudo apt remove snapd

Then, boot the DVD and do a bit more work.

sudo mount /dev/sda2 /mnt
cd /mnt/snap
sudo rm -Rf *
cd ..
sudo chattr +i snap # This keeps the naughty munchkins from mounting stuff in here
sudo umount /mnt

On a reboot, it still works. There is a "gnome" entry in Synaptic,
so maybe a .deb version there awaits.

[Picture]

https://i.postimg.cc/FHKCK8Ss/ub2304-unsnapped.gif

Paul

Paul wrote:
> When I do
>
> snap list
>
> I see a "gnome" entry. I see Firefox too. In the tree,
> Firefox is only available as a Snap, not as a .deb (whereas
> Firefox is a .deb on Mint and acquired directly from Mozilla
> in a brown paper bag).
>
> If I do this
>
> sudo apt remove snapd
>
> then before and after I reboot the VM, the loop mounts are still there,
> and the Snap packages are still running. The loop mounts are on top of
> mount point /snap and thus the 4GB we see in the tree there, is all
> squashfs mounts on top of /snap.
>
> bullwinkle@SUPERFLY:~$ cat /etc/mtab
> ...
> /dev/loop2 /snap/bare/5 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
> /dev/loop3 /snap/core22/607 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
> /dev/loop0 /snap/core22/858 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
>
> /dev/loop1 /snap/gnome-42-2204/126 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0 <=== Trouble ???
> /dev/loop4 /snap/firefox/2517 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0 <=== Trouble ???
>
> /dev/loop5 /snap/snapd-desktop-integration/83 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
> /dev/sda2 /var/snap/firefox/common/host-hunspell ext4 ro,noexec,noatime 0 0
> /dev/loop10 /snap/snapd/18933 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
> /dev/loop8 /snap/gtk-common-themes/1535 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
> /dev/loop7 /snap/gnome-42-2204/87 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
> /dev/loop6 /snap/snap-store/959 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
> /dev/loop9 /snap/snapd/19457 squashfs ro,nodev,relatime,errors=continue,threads=single 0 0
> ...
> bullwinkle@SUPERFLY:~$
>
> However, with no snapd, this command no longer works.
>
> snap list # command not found
>
> Doing that seems to remove the management of it, at least.
>
> If, using Synaptic, I attempt the equivalent of
>
> sudo apt install firefox
>
> then it includes as a dependency, the snapd package I have just removed.
>
> So not only will I have to switch over my Firefox, before doing
> additional damage, I'll need to find Gnome DE too, as a .deb .
> Ubuntu Studio might have different dependencies, similar to those.
>
> *******
>
> I gave it a try, and Ubuntu 23.04 survived the removal of its nads.
>
> sudo apt remove snapd
>
> Then, boot the DVD and do a bit more work.
>
> sudo mount /dev/sda2 /mnt
> cd /mnt/snap
> sudo rm -Rf *
> cd ..
> sudo chattr +i snap # This keeps the naughty munchkins from mounting stuff in here
> sudo umount /mnt
>
> On a reboot, it still works. There is a "gnome" entry in Synaptic,
> so maybe a .deb version there awaits.
>
> [Picture]
>
> https://i.postimg.cc/FHKCK8Ss/ub2304-unsnapped.gif

Firstly IIRC he was using 22.04 LTS, and my example was for 22.04 LTS.
Non-LTS can be a crapshoot. I have a HP EliteBook that has 23.04 but I
haven't bothered to remove the snap version of Firefox because I was
testing the claim that they improved the snap load times and it seems
that they have.

Now before you can remove snapd you do have to change the repository
priority of Firefox to the deb, else after an update the snap version
will be reinstalled. But, at least with 22.04, after doing the previous
steps nothing breaks when your remove snapd.

snapd:
Installed: (none)
Candidate: 2.58+22.04.1
Version table:
2.58+22.04.1 500
500 http://us.archive.ubuntu.com/ubuntu jammy-updates/main amd64
Packages
500 http://security.ubuntu.com/ubuntu jammy-security/main amd64
Packages
2.55.3+22.04 500
500 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages

No snapd.

sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs
rw,nosuid,relatime,size=3805692k,nr_inodes=951423,mode=755,inode64 0 0
devpts /dev/pts devpts
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs
rw,nosuid,nodev,noexec,relatime,size=769476k,mode=755,inode64 0 0
/dev/sda1 / ext4 rw,relatime,errors=remount-ro 0 0
securityfs /sys/kernel/security securityfs
rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,inode64 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k,inode64 0 0
cgroup2 /sys/fs/cgroup cgroup2
rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
bpf /sys/fs/bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs
rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=18610
0 0
mqueue /dev/mqueue mqueue rw,nosuid,nodev,noexec,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime,pagesize=2M 0 0
debugfs /sys/kernel/debug debugfs rw,nosuid,nodev,noexec,relatime 0 0
tracefs /sys/kernel/tracing tracefs rw,nosuid,nodev,noexec,relatime 0 0
ramfs /run/credentials/systemd-sysusers.service ramfs
ro,nosuid,nodev,noexec,relatime,mode=700 0 0
configfs /sys/kernel/config configfs rw,nosuid,nodev,noexec,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,nosuid,nodev,noexec,relatime 0 0
/dev/sdb1 /mnt/extra ext4 rw,relatime 0 0
/dev/sda5 /home ext4 rw,relatime 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc
rw,nosuid,nodev,noexec,relatime 0 0
sunrpc /run/rpc_pipefs rpc_pipefs rw,relatime 0 0
tmpfs /run/user/1000 tmpfs
rw,nosuid,nodev,relatime,size=769472k,nr_inodes=192368,mode=700,uid=1000,gid=1000,inode64
0 0
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse
rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
portal /run/user/1000/doc fuse.portal
rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0

No snap virtual mounts...no broken GNOME.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

"David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:

>
> Learning how to use systemd and all of it's components is a large learning curve.
> So was learning how to minimize cyclic dependencies with initd start up scripts.

SysV init scripts were a puked-up cat's hairball of non-uniform shell
scripts and a bunch of symlinks. Good riddance! :-)

On 9/17/23 12:03, Bud Frede wrote:
> "David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:
>
>>
>> Learning how to use systemd and all of it's components is a large learning curve.
>> So was learning how to minimize cyclic dependencies with initd start up scripts.
>
> SysV init scripts were a puked-up cat's hairball of non-uniform shell
> scripts and a bunch of symlinks. Good riddance! :-)

So sez you but some very interesting distributions have no problem with
SysVint and do not use systemd(evil). I haven't used
a distro with systemd for some years now. It does not improve the
average user's experience at all as far as I can see and the creator
of Linux, one Linus Torwalds has no use for it either.

What's GNU with you?

bliss- Dell Precision E7730- PCLinuxOS 64- Linux 6.5.3- Plasma 5.27.8

--
bliss dash SF 4 ever at dslextreme dot com

Bobbie Sellers wrote:
> the creator
> of Linux, one Linus Torwalds has no use for it either.

There was a pretty long interview w/ LT back in '14 about systemd. It
didn't sound like he was in the anti-systemd camp then.

https://itwire.com/business-it-news/open-source/65402-torvalds-says-he-has-no-strong-opinions-on-systemd
Torvalds says he has no strong opinions on systemd

I don't know if he's said anything lately. '14 was a long time ago.

--
Mike Easter

On 9/18/23 08:26, Mike Easter wrote:
> Bobbie Sellers wrote:
>> the creator
>> of Linux, one Linus Torwalds has no use for it either.
>
> There was a pretty long interview w/ LT back in '14 about systemd.  It
> didn't sound like he was in the anti-systemd camp then.
>
> https://itwire.com/business-it-news/open-source/65402-torvalds-says-he-has-no-strong-opinions-on-systemd  Torvalds says he has no strong opinions on systemd
>
> I don't know if he's said anything lately. '14 was a long time ago.
>

> Linus Torvalds Blocks All Code from Systemd Developer for the Linux
> Kernel - The developer needs to fix the problems in systemd before
his > patches are accepted.

This if from 2014 maybe he has revised his opinions since then
but he says clearly that Poettering was attempting to change the
kernel to work with systemd. Mr.Torwalds was adamant that he
should fix systemd to work with the kernel, not the kernel to
work with systemd.

<https://news.softpedia.com/news/Linus-Torvalds-Block-All-Code-from-Systemd-Developer-for-the-Linux-Kernel-435714.shtml>

Now some distros completely reject systemd and Dr.Klaus Knopper of
Knoppix renown wrote his own startup rather than get enmeshed in the
coils and confusions of systemd. Other systems have done similar
things.

bliss- Dell Precision E7730- PCLinuxOS 64- Linux 6.5.3- Plasma 5.27.8

--
bliss dash SF 4 ever at dslextreme dot com

Bobbie Sellers wrote:
> Mike Easter wrote:
>> Bobbie Sellers wrote:
>>> the creator of Linux, one Linus Torwalds has no use for it
>>> either.
>>
>> There was a pretty long interview w/ LT back in '14 about systemd.
>> It didn't sound like he was in the anti-systemd camp then.
>>
>> https://itwire.com/business-it-news/open-source/65402-torvalds-says-he-has-no-strong-opinions-on-systemd
>> Torvalds says he has no strong opinions on systemd
>>
>> I don't know if he's said anything lately. '14 was a long time
>> ago.
>>
>
>> Linus Torvalds Blocks All Code from Systemd Developer for the
>> Linux Kernel - The developer needs to fix the problems in systemd
>> before
> his > patches are accepted.
>
That was about LT's 'war' w/ Kay Sievers who he was very unhappy w/
about not tending to bugs in the manner LT expected.

> This if from 2014 maybe he has revised his opinions since then but he
> says clearly that Poettering was attempting to change the kernel to
> work with systemd. Mr.Torwalds was adamant that he should fix
> systemd to work with the kernel, not the kernel to work with
> systemd.
>
> <https://news.softpedia.com/news/Linus-Torvalds-Block-All-Code-from-Systemd-Developer-for-the-Linux-Kernel-435714.shtml>
>
>
Here's the essence of what that 2014 article said:

> Everything started from a bug in systemd that caused the operating
> system to fail to boot. A solution has been proposed, but not uptream
> for systemd, but for the Linux kernel, and a patch was submitted.
> Basically, the bug was still there in systemd, but code has been
> added to the Linux kernel so that this problem would be
> circumvented.
>
> The patch was submitted to the kernel, but Linus Torvalds is not a
> big fan of adding code to the Linux kernel just to fix a problem from
> another package. He is not a patient man and this is not the first
> time that he intervened.

Further down LT said he wasn't accepting any more patches from KS.

--
Mike Easter

Bobbie Sellers <bliss@mouse-potato.com> writes:

> On 9/17/23 12:03, Bud Frede wrote:
>> "David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:
>>
>>>
>>> Learning how to use systemd and all of it's components is a large learning curve.
>>> So was learning how to minimize cyclic dependencies with initd start up scripts.
>> SysV init scripts were a puked-up cat's hairball of non-uniform
>> shell
>> scripts and a bunch of symlinks. Good riddance! :-)
>
> So sez you but some very interesting distributions have no
> problem with SysVint and do not use systemd(evil). I haven't
> used

"systemd(evil)"

That's your problem right there. Systemd is just software. It either
works for you or it doesn't. There's no need to get all political about
it. Unix/Linux is not a religion, and systemd is not either.

I've worked as a UNIX and then Linux sysadmin for 25+ years and am
currently supporting Linux systems running a large software suite. (My
title is no longer "Sysadmin," but I do a lot of the same tasks.) The
list of UNIX and unix-like OSes I've worked with is long, and I can't
even count anymore the number of Linux distros I've used.

SysV init has always been rather awkward, overly complex if you want to
do anything other than basic things, and its time is past. I saw the
writing on the wall years ago when SMF came out in Solaris, and was just
waiting for Linux to adopt something similar.

Systemd isn't quite what I was expecting, but it works quite well
IMO. The big cloud providers are stuffed full of VMs using systemd. The
number of Linux systems still using SysV init is minuscule. The battle
is over and you're still emulating Chicken Little.

I don't really care if you want to tilt at windmills, and you're free to
use whatever init system trips your trigger, but I think you're wrong
about systemd's utility for the Linux community. It's a good thing, not
a bad one.