On Tuesday 01 February 2022 at 17:55:30, Nikolaus Klepp via Dng wrote:
> Anno domini 2022 Tue, 1 Feb 11:44:37 -0500 Steve Litt scripsit:
> >
> > In the hands of anything but a very careful and security-knowledgeable
> > programmer, writing Python3 is more secure than writing C. You could
> >
Anno domini 2022 Tue, 1 Feb 11:44:37 -0500
Steve Litt scripsit:
> tito via Dng said on Tue, 1 Feb 2022 13:49:30 +0100
>
> >On Tue, 1 Feb 2022 09:50:31 +0100
> >Didier Kryn wrote:
> >
> >> Le 31/01/2022 à 19:16, Steve Litt a écrit :
> >> >> Writing a self-daemonizing daemon in C was a
tito via Dng said on Tue, 1 Feb 2022 13:49:30 +0100
>On Tue, 1 Feb 2022 09:50:31 +0100
>Didier Kryn wrote:
>
>> Le 31/01/2022 à 19:16, Steve Litt a écrit :
>> >> Writing a self-daemonizing daemon in C was a routine when I
>> >> was still active, though I understand it could be more
On Tue, Feb 01, 2022 at 09:50:31AM +0100, Didier Kryn wrote:
> Le 31/01/2022 à 19:16, Steve Litt a écrit :
> > > Writing a self-daemonizing daemon in C was a routine when I was
> > > still active, though I understand it could be more difficult in shell.
> > But more difficult in Python. I try
On Tue, Feb 01, 2022 at 01:49:30PM +0100, tito via Dng wrote:
> On Tue, 1 Feb 2022 09:50:31 +0100
> Didier Kryn wrote:
>
> > Le 31/01/2022 à 19:16, Steve Litt a écrit :
> > >> Writing a self-daemonizing daemon in C was a routine when I was
> > >> still active, though I understand it could
On Tue, 1 Feb 2022 09:50:31 +0100
Didier Kryn wrote:
> Le 31/01/2022 à 19:16, Steve Litt a écrit :
> >> Writing a self-daemonizing daemon in C was a routine when I was
> >> still active, though I understand it could be more difficult in shell.
> > But more difficult in Python. I try to stay
Le 31/01/2022 à 19:16, Steve Litt a écrit :
Writing a self-daemonizing daemon in C was a routine when I was
still active, though I understand it could be more difficult in shell.
But more difficult in Python. I try to stay away from C if Python does
the job. I think Python3 plus its
Didier Kryn said on Mon, 31 Jan 2022 10:27:53 +0100
>Le 29/01/2022 à 21:00, k...@aspodata.se a écrit :
>> I don't see the point in letting init do serious process monitoring.
>> Just use a minimal init and startup a separate process monitoring
>> daemon (or what theese things are called).
>>
>>
Le 29/01/2022 à 21:00, k...@aspodata.se a écrit :
I don't see the point in letting init do serious process monitoring.
Just use a minimal init and startup a separate process monitoring
daemon (or what theese things are called).
...
I don't see the point, learn to write good deamons. It seems
Steve Litt wrote:
> * It requires each daemon to background itself. Eww, gross!
Does it ?
I read the examples as supporting foreground processes :
> # The BusyBox ntpd does not use syslog when running in the foreground
> # So we use this trick to redirect stdout/stderr to a log file.
Also
Steve Litt:
...
> I read the docs at https://troglobit.com/projects/finit/ , and have
> some opinions technically...
...
I don't see the point in letting init do serious process monitoring.
Just use a minimal init and startup a separate process monitoring
daemon (or what theese things are
On Wed, 26 Jan 2022 08:59:24 +0100
Martin Steigerwald wrote:
> Hi!
>
> I saw this coming into Debian Sid, so should be available in Devuan
> Ceres as well:
>
> https://troglobit.com/projects/finit/
>
> Sounds interesting, I'd say.
>
> Best,
Hi,
what scares me is;
originally reverse
Syeed Ali said on Thu, 27 Jan 2022 03:52:34 -0800
>On Wed, 26 Jan 2022 08:59:24 +0100
>Martin Steigerwald wrote:
>
>> I saw this coming into Debian Sid, so should be available in Devuan
>> Ceres as well:
>>
>> https://troglobit.com/projects/finit/
>
>I'm going to hazard the guess that this
On Wed, 26 Jan 2022 08:59:24 +0100
Martin Steigerwald wrote:
> I saw this coming into Debian Sid, so should be available in Devuan
> Ceres as well:
>
> https://troglobit.com/projects/finit/
I'm going to hazard the guess that this will be lined up in the same
way that Microsoft propped up
Le 26/01/2022 à 08:59, Martin Steigerwald a écrit :
Hi!
I saw this coming into Debian Sid, so should be available in Devuan
Ceres as well:
https://troglobit.com/projects/finit/
Sounds interesting, I'd say.
Best,
There are few very interesting point in this announcement.
1) It
Hi!
I saw this coming into Debian Sid, so should be available in Devuan
Ceres as well:
https://troglobit.com/projects/finit/
Sounds interesting, I'd say.
Best,
--
Martin
___
Dng mailing list
Dng@lists.dyne.org
Bob Proulx via Dng said on Sun, 28 Nov 2021 10:57:36 -0700
>Mike Tubby wrote:
>> ... but if you run a nameserver you may well need:
>>
>> /var/cache/bind
>>
>> as that's where your zonefiles are ;-)
>
>Sorry. No. I am curious what led you to that conclusion?
>
>By default in the Debian
Mike Tubby wrote:
> ... but if you run a nameserver you may well need:
>
> /var/cache/bind
>
> as that's where your zonefiles are ;-)
Sorry. No. I am curious what led you to that conclusion?
By default in the Debian packaged configuration only the cached zone
files downloaded on
Or, tell bind to place the zone files where they originally were, in
/etc/bind/zones or something.
The change was made about 10 years ago as a "security feature" and is
mainly used for running bind in a jail, so if it gets hacked, they can't
mess up the rest of the server. I remember when Debian
Mike Tubby said on Fri, 26 Nov 2021 13:07:36 +
>
>... but if you run a nameserver you may well need:
>
> /var/cache/bind
>
>as that's where your zonefiles are ;-)
Thanks for reminding me again one of the reasons I don't use bind. Who
in their right mind would put zone files in a cache
On 24/11/2021 10:08, Olaf Meeuwissen via Dng wrote:
Hi Hendrik,
Hendrik Boom writes:
I'm setting up a new backup script that will do it all piecemeal so
that if a part of it fails, it can be retried without having to start
*everythng* over from scratch.
Which top-level filesystems should
Hi,
Steve Litt writes:
> Dr. Nikolaus Klepp via Dng said on Tue, 23 Nov 2021 20:43:28 +0100
>
>>Anno domini 2021 Tue, 23 Nov 14:27:56 -0500
>> Hendrik Boom scripsit:
>>> I'm setting up a new backup script that will do it all piecemeal so
>>> that if a part of it fails, it can be retried without
Hi Hendrik,
Hendrik Boom writes:
> I'm setting up a new backup script that will do it all piecemeal so
> that if a part of it fails, it can be retried without having to start
> *everythng* over from scratch.
>
> Which top-level filesystems should *not* be backed up.
>
> To start with, I
Hi,
Dr. Nikolaus Klepp via Dng writes:
> Anno domini 2021 Tue, 23 Nov 21:39:07 +0200
> Lars Noodén via Dng scripsit:
>> On 11/23/21 21:27, Hendrik Boom wrote:
>> > I'm setting up a new backup script that will do it all piecemeal so
>> > that if a part of it fails, it can be retried without
Harald Arnesen via Dng said on Tue, 23 Nov 2021 21:56:43 +0100
>Steve Litt [23/11/2021 21.48]:
>
>>
>> The majority of files in /home/yourname are useless. /home/yourname
>> is a mishmash of stuff you created, settings you use, and useless
>> crap
>
Steve Litt [23/11/2021 21.48]:
The majority of files in /home/yourname are useless. /home/yourname is
a mishmash of stuff you created, settings you use, and useless crap
like cache. It's huge and ugly. For that reason I create other top
Dr. Nikolaus Klepp via Dng said on Tue, 23 Nov 2021 20:43:28 +0100
>Anno domini 2021 Tue, 23 Nov 14:27:56 -0500
> Hendrik Boom scripsit:
>> I'm setting up a new backup script that will do it all piecemeal so
>> that if a part of it fails, it can be retried without having to
>> start *everythng*
Anno domini 2021 Tue, 23 Nov 21:39:07 +0200
Lars Noodén via Dng scripsit:
> On 11/23/21 21:27, Hendrik Boom wrote:
> > I'm setting up a new backup script that will do it all piecemeal so
> > that if a part of it fails, it can be retried without having to start
> > *everythng* over from scratch.
>
Anno domini 2021 Tue, 23 Nov 14:27:56 -0500
Hendrik Boom scripsit:
> I'm setting up a new backup script that will do it all piecemeal so
> that if a part of it fails, it can be retried without having to start
> *everythng* over from scratch.
>
> Which top-level filesystems should *not* be
On 11/23/21 21:27, Hendrik Boom wrote:
I'm setting up a new backup script that will do it all piecemeal so
that if a part of it fails, it can be retried without having to start
*everythng* over from scratch.
[snip]
It depends on what you've set up.
For the systems I have, I only back up the
I'm setting up a new backup script that will do it all piecemeal so
that if a part of it fails, it can be retried without having to start
*everythng* over from scratch.
Which top-level filesystems should *not* be backed up.
To start with, I presumably shouldn't back up
/proc
/tmp
/dev (cause
Hi Alessandro,
On 27/10/21 18:19, Alessandro Vesely via Dng wrote:
I have both libc6:i386 and lib32gcc-s1 (on an AMD 64bit machine).
libc6-i686:i386 is tagged 'rc' transitional dummy package.
gcc-multilib maybe?
This is useful to cross-compile i386 applications under amd64.
Cheers,
On Wed 27/Oct/2021 18:54:16 +0200 karl wrote:
For libc5, run "man libc" and look under the heading "Linux libc".
Damn my fatty fingers, it was libc6-i686. (Not that it is much newer, it was
in stretch.)
Thanks for pointing it out anyway.
The hp-health package itself is dated 2019 in the
For libc5, run "man libc" and look under the heading "Linux libc".
The latest libc5 package is from 2003 in debian-archive, from what I
can see:
debian-archive/debian/pool/main/libc/libc/libc5_5.4.46-15_i386.deb
That is within Debian 3.0, Woody, timeline.
Regards,
/Karl Hammar
Hi all,
I have a .deb package from HP (hp-health) that has this requirement, and
doesn't install because of it. It got damaged somehow during the last
dist-upgrade. I think I'd better re-install it.
I have both libc6:i386 and lib32gcc-s1 (on an AMD 64bit machine).
libc6-i686:i386 is
Dr. Nikolaus Klepp wrote:
>> I doubt this could be ever implemented correctly as you have to check
>> every code path of every app you will armorize or as soon as your usage
>> diverges from what the distro gurus have envisioned your program
>> will stop working without even a warning.
>> Next
Le 07/03/2021 à 18:20, tito via Dng a écrit :
> On Sun, 7 Mar 2021 18:03:30 +0100
> Antony Stone wrote:
>
>> On Sunday 07 March 2021 at 17:59:22, Steve Litt wrote:
>>
>>> See this web page:
>>>
>>> https://en.wikipedia.org/wiki/Anti-pattern
>>>
>>> I'd say at least half of the listed
Anno domini 2021 Sun, 7 Mar 19:18:42 +0100
tito via Dng scripsit:
> On Sun, 7 Mar 2021 19:11:18 +0100
> "d...@d404.nl" wrote:
>
> > On 07-03-2021 18:20, tito via Dng wrote:
> > > On Sun, 7 Mar 2021 18:03:30 +0100
> > > Antony Stone wrote:
> > >
> > >> On Sunday 07 March 2021 at 17:59:22, Steve
See https://wiki.ubuntu.com/AppArmor for a explanation.
Ubuntu? What's that?
Is that the thing they use in North America 'cause they never heard of
Debian?
There is https://wiki.debian.org/AppArmor too, it seems (never read it).
Bernard (Beer) Rosset
https://rosset.net/
On 07-03-2021 19:22, Marc Shapiro via Dng wrote:
>
> What does apparmor actually do? It was installed on my system as a
> Recommends for my kernel (linux-image-4.19.0-14-amd64), but I get
> warnings of some type every time I reboot (which I don't do often, so
> I can't say just what the warnings
What does apparmor actually do? It was installed on my system as a
Recommends for my kernel (linux-image-4.19.0-14-amd64), but I get
warnings of some type every time I reboot (which I don't do often, so I
can't say just what the warnings are). Is there any reason to keep it
installed? Or
On Sun, 7 Mar 2021 19:11:18 +0100
"d...@d404.nl" wrote:
> On 07-03-2021 18:20, tito via Dng wrote:
> > On Sun, 7 Mar 2021 18:03:30 +0100
> > Antony Stone wrote:
> >
> >> On Sunday 07 March 2021 at 17:59:22, Steve Litt wrote:
> >>
> >>> See this web page:
> >>>
> >>>
On 07-03-2021 18:20, tito via Dng wrote:
> On Sun, 7 Mar 2021 18:03:30 +0100
> Antony Stone wrote:
>
>> On Sunday 07 March 2021 at 17:59:22, Steve Litt wrote:
>>
>>> See this web page:
>>>
>>> https://en.wikipedia.org/wiki/Anti-pattern
>>>
>>> I'd say at least half of the listed anti-patterns are
On Sun, 7 Mar 2021 18:03:30 +0100
Antony Stone wrote:
> On Sunday 07 March 2021 at 17:59:22, Steve Litt wrote:
>
> > See this web page:
> >
> > https://en.wikipedia.org/wiki/Anti-pattern
> >
> > I'd say at least half of the listed anti-patterns are used by
> > systemd.
>
> Very nice.
>
>
On Sunday 07 March 2021 at 17:59:22, Steve Litt wrote:
> See this web page:
>
> https://en.wikipedia.org/wiki/Anti-pattern
>
> I'd say at least half of the listed anti-patterns are used by systemd.
Very nice.
Antony.
--
I bought a book about anti-gravity. The reviews say you can't put it
See this web page:
https://en.wikipedia.org/wiki/Anti-pattern
I'd say at least half of the listed anti-patterns are used by systemd.
SteveT
Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
On 14/12 23:31, Hendrik Boom wrote:
> On Sun, Dec 13, 2020 at 09:31:02PM +0100, Didier Kryn wrote:
> > Le 13/12/2020 à 03:15, Steve Litt a écrit :
> > > On Fri, 11 Dec 2020 15:53:35 +0100
> > > Didier Kryn wrote:
> > >
> > >
> > >> I don't make it an argument against xdm. Just cheating about
On Sun, Dec 13, 2020 at 09:31:02PM +0100, Didier Kryn wrote:
> Le 13/12/2020 à 03:15, Steve Litt a écrit :
> > On Fri, 11 Dec 2020 15:53:35 +0100
> > Didier Kryn wrote:
> >
> >
> >> I don't make it an argument against xdm. Just cheating about your
> >> own arguments (~:
> > Didier, why didn't
Le 13/12/2020 à 03:15, Steve Litt a écrit :
> On Fri, 11 Dec 2020 15:53:35 +0100
> Didier Kryn wrote:
>
>
>> I don't make it an argument against xdm. Just cheating about your
>> own arguments (~:
> Didier, why didn't you make that suggestion to me 15 years ago? It's a
> brilliant way to
On Fri, 11 Dec 2020 15:53:35 +0100
Didier Kryn wrote:
> I don't make it an argument against xdm. Just cheating about your
> own arguments (~:
Didier, why didn't you make that suggestion to me 15 years ago? It's a
brilliant way to guarantee that if somebody logs out of X, they have no
On Thu, Dec 10, 2020 at 10:31:38PM -0500, Mason Loring Bliss wrote:
> On Thu, Dec 10, 2020 at 02:42:30PM -0500, Steve Litt wrote:
>
> > Wait a minute. When you say "without GUI", do you mean no X installed,
> > or do you mean it lacks the display manager to boot directly into X?
> > The former
Hi,
On 12/11/20 1:16 PM, aitor wrote:
Hi Dimitris,
On 12/11/20 12:23 PM, Dimitris via Dng wrote:
yes,
running `apt purge elogind` in testing/ceres brings in consolekit
instead.
don't have a ascii/beowulf with xorg to test, but should be the same.
The same in beowulf, one can purge
On Fri, Dec 11, 2020 at 03:48:06PM +0100, Didier Kryn wrote:
> I guess in Bash you could just issue 'exec startx', in which case bash
> would go away, returning memory and leaving no place for intrusion.
Oh, I hadn't considered that! Yeah, that should win. Thank you for the new
perspective!
Le 11/12/2020 à 04:31, Mason Loring Bliss a écrit :
>> Wait a minute. When you say "without GUI", do you mean no X installed,
>> or do you mean it lacks the display manager to boot directly into X?
>> The former precludes desktop use; the latter is how I use my computer
>> every day, because
On 12/11/20 1:52 PM, aitor wrote:
apt "install" (libsystemd0 | libelogind0)removes elogind , but xorg
will remain in the system instead.
(libsystemd0 | consolekit)
___
Dng mailing list
Dng@lists.dyne.org
Hi,
On 12/11/20 11:55 AM, Steve Litt wrote:
I'm a little slow, so let me repeat my question a different way. Is
there any way you can remove elogind with
apt remove --purge elogind; with xorg installed?
SteveT
The fact that apt "purge" removes the whole xserver-xorg stuff together
with
Hi Dimitris,
On 12/11/20 12:23 PM, Dimitris via Dng wrote:
yes,
running `apt purge elogind` in testing/ceres brings in consolekit
instead.
don't have a ascii/beowulf with xorg to test, but should be the same.
The same in beowulf, one can purge elogind (required by
xserver-xorg-core)
Hi,
On 12/11/20 1:07 PM, aitor wrote:
Hi Steve,
On 12/11/20 11:55 AM, Steve Litt wrote:
I'm a little slow, so let me repeat my question a different way. Is
there any way you can remove elogind with
apt remove --purge elogind; with xorg installed?
The short answer: yes, installing
Hi Steve,
On 12/11/20 11:55 AM, Steve Litt wrote:
I'm a little slow, so let me repeat my question a different way. Is
there any way you can remove elogind with
apt remove --purge elogind; with xorg installed?
The short answer: yes, installing libsystemd0 [*]
Cheers,
Aitor.
[*] Under
On 12/11/20 12:55 PM, Steve Litt wrote:
Is
there any way you can remove elogind with
apt remove --purge elogind; with xorg installed?
yes,
running `apt purge elogind` in testing/ceres brings in consolekit instead.
don't have a ascii/beowulf with xorg to test, but should be the same.
On Thu, 10 Dec 2020 23:02:30 +0100
Adrian Zaugg wrote:
> On 10.12.20 20:42, Steve Litt wrote:
> > On Thu, 10 Dec 2020 01:40:39 +0100
> > Adrian Zaugg wrote:
> >
> > Wait a minute. When you say "without GUI", do you mean no X
> > installed,
>
> I just mean no GUI, because with a GUI I don't
On Thu, Dec 10, 2020 at 10:31:38PM -0500, Mason Loring Bliss wrote:
> Also, for laughs, in Beowulf, the xdm binary consumes 117K on disk,
There's a pandemic on, so I'll forgive myself a little OCD.
Sorted by RSS:
$ ps uq 21538
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME
On Thu, Dec 10, 2020 at 02:42:30PM -0500, Steve Litt wrote:
> Wait a minute. When you say "without GUI", do you mean no X installed,
> or do you mean it lacks the display manager to boot directly into X?
> The former precludes desktop use; the latter is how I use my computer
> every day, because
On 10.12.20 20:42, Steve Litt wrote:
> On Thu, 10 Dec 2020 01:40:39 +0100
> Adrian Zaugg wrote:
>
> Wait a minute. When you say "without GUI", do you mean no X installed,
I just mean no GUI, because with a GUI I don't know exactly. I know
there are some Desktop environments that need it, it
On Thu, 10 Dec 2020 01:40:39 +0100
Adrian Zaugg wrote:
> On 01.12.20 15:16, Mason Loring Bliss wrote:
> > This brings us to the other thing worthy of note. Try sometime to
> > install Devuan (not Debian, Devuan) without systemd and you'll be
> > in for a rude shock. It's installed by default,
Hi Adrian,
On 12/10/20 12:46 PM, Adrian Zaugg wrote:
Hi aitor
$ apt-rdepends openssh-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
openssh-server
Depends: adduser (>= 3.9)
Depends: debconf (>= 0.5)
Depends: debconf-2.0
Depends: dpkg
Hi aitor
$ apt-rdepends openssh-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
openssh-server
Depends: adduser (>= 3.9)
Depends: debconf (>= 0.5)
Depends: debconf-2.0
Depends: dpkg (>= 1.9.0)
Depends: libaudit1 (>= 1:2.2.1)
Depends:
Hi again,
On 12/10/20 11:31 AM, aitor wrote:
Hi Adrian
On 12/10/20 1:40 AM, Adrian Zaugg wrote:
libsystemd0 gets pulled in by openssh-server and thus is
present on many of my systems – unfortunately.
This is for the ssh-agent service, used by systemd, which should be
optional.
This is
Hi Adrian
On 12/10/20 1:40 AM, Adrian Zaugg wrote:
libsystemd0 gets pulled in by openssh-server and thus is
present on many of my systems – unfortunately.
This is for the ssh-agent service, used by systemd, which should be
optional.
Cheers,
Aitor.
On Thu, Dec 10, 2020 at 01:40:39AM +0100, Adrian Zaugg wrote:
> What shows
>
> apt remove --dry-run elogind
I'll try to get a chance to do a new install, as I should figure out just
what's pulling in what. I'll post this as soon as I've got it. I'm not sure
what's pulling it in during
On 01.12.20 15:16, Mason Loring Bliss wrote:
> This brings us to the other thing worthy of note. Try sometime to install
> Devuan (not Debian, Devuan) without systemd and you'll be in for a rude
> shock. It's installed by default, and it's a massive pain to eradicate it.
What shows
apt
On Fri, 4 Dec 2020 13:20:53 -0500
Hendrik Boom wrote:
> libsystemd0 is, as I've been told, a library that provides the
> interfaces provided by systemd without the content. For example,
> a typical systemd feature will, as implemented in libsystemd0,
> merely report back in the proper
On Tue, Dec 08, 2020 at 09:22:03PM -0500, Mason Loring Bliss wrote:
> On Wed, Dec 09, 2020 at 09:33:16AM +0900, Simon Walter wrote:
>
> > We were talking about libsystemd0 being a stub.
>
> It's not a stub. There's a bunch of functionality in there. A ton of it.
> The elogind porters (who are
On Wed, Dec 09, 2020 at 09:33:16AM +0900, Simon Walter wrote:
> We were talking about libsystemd0 being a stub.
It's not a stub. There's a bunch of functionality in there. A ton of it.
The elogind porters (who are distinct from Devuan/Debian maintainers) have
ifdef'd out a large amount of stuff,
On 12/9/20 7:01 AM, Mason Loring Bliss wrote:
On Fri, Dec 04, 2020 at 09:56:54AM +0900, Simon Walter wrote:
Unfortunately for those who are scared of source code and perhaps those
who are scared in general, it is all too easy to become paranoid. After
all, you are at the mercy of those who are
On Tue, Dec 08, 2020 at 05:01:49PM -0500, Mason Loring Bliss wrote:
> Let's start with how much systemd code we're talking about. Admittedly, I'm
> not cutting out comments or whitespace here, but even so:
>
> .../elogind-241.4/src$ find . -name '*.c' -exec cat {} \; | wc -l
> 125582
On Fri, Dec 04, 2020 at 09:56:54AM +0900, Simon Walter wrote:
> Unfortunately for those who are scared of source code and perhaps those
> who are scared in general, it is all too easy to become paranoid. After
> all, you are at the mercy of those who are not scared. I'd say, pick up
> programming
On Tue, Dec 01, 2020 at 09:59:01AM -0500, Mason Loring Bliss wrote:
> On Tue, Dec 01, 2020 at 03:33:41PM +0100, Antony Stone wrote:
>
> > What, specifically, gets installed as part of Devuan which you don't want
> > to
> > see there?
>
> As an exercise, try doing a minimal install via
On 2020-12-01 23:59, Mason Loring Bliss wrote:
> On Tue, Dec 01, 2020 at 03:33:41PM +0100, Antony Stone wrote:
>
>> What, specifically, gets installed as part of Devuan which you don't want to
>> see there?
>
> As an exercise, try doing a minimal install via debootstrap, which is
> arguably the
On Tue, 1 Dec 2020 09:59:01 -0500, Mason wrote in message
<20201201145900.gv5...@blisses.org>:
> On Tue, Dec 01, 2020 at 03:33:41PM +0100, Antony Stone wrote:
>
> > What, specifically, gets installed as part of Devuan which you
> > don't want to see there?
>
> As an exercise, try doing a
On Tue, Dec 01, 2020 at 03:33:41PM +0100, Antony Stone wrote:
> What, specifically, gets installed as part of Devuan which you don't want to
> see there?
As an exercise, try doing a minimal install via debootstrap, which is
arguably the easiest way to tailor an install. I've thus far not
On Tuesday 01 December 2020 at 15:16:57, Mason Loring Bliss wrote:
> This brings us to the other thing worthy of note. Try sometime to install
> Devuan (not Debian, Devuan) without systemd and you'll be in for a rude
> shock. It's installed by default, and it's a massive pain to eradicate it.
On Mon, Nov 30, 2020 at 05:34:48PM -0500, Steve Litt wrote:
> The fact that Redhat is #64 tells me not that many people are buying
> their stupid support,
Lest we get too excited, let me note two things:
https://distrowatch.com/dwres.php?resource=faq#phr
This says,
What is this "Page
never learned anything at DW by looking statistics.. some guides and
reviews were helpful...
On 12/1/20 12:34 AM, Steve Litt wrote:
fact that Redhat is #64
certainly not a fact.
this is just a number without value. just a "Page Hit Rank"...
if i was to guess, i'd say "serious corporate
On Mon, 30 Nov 2020 20:16:48 +0900
Olaf Meeuwissen wrote:
> Hi Steve,
>
> Steve Litt writes:
>
> > Hi all,
> >
> > Devuan's #34 on Distrowatch. Not too shabby!
> >
> > Runit using Void is #40. Redhat, the clowns who started this whole
> > systemd thing, are down at #64.
>
> I don't want to
Hi Steve,
Steve Litt writes:
> Hi all,
>
> Devuan's #34 on Distrowatch. Not too shabby!
>
> Runit using Void is #40. Redhat, the clowns who started this whole
> systemd thing, are down at #64.
I don't want to spoil your party but have you looked at Fedora, at #8,
and CentOS, at #19? The fact
Hi all,
Devuan's #34 on Distrowatch. Not too shabby!
Runit using Void is #40. Redhat, the clowns who started this whole
systemd thing, are down at #64.
Meanwhile, at #18, AntiX offers a choice between sysvinit and runit.
And at #50, Artix offers a choice between OpenRC, runit and s6. It's
I agree. For me, the thing which has always put me off above all other
things was the fact that systems running systemd often did not shut down
cleanly. Manageable if it's a laptop on your desk and you have access to
the on/off button and the power cord. Not so good if the box is a
Hi,
SystemD detractors may, like myself, be repelled from using it because
everytime they installed a systemd based distribution, it always
greeted them with a system-wide freeze. Microsoft Windows has solved
that issue of system-wide freezes since almost two decades.
On my music player based on
Anno domini 2020 Sat, 18 Apr 14:12:08 +
aitor_czr scripsit:
> Hi,
>
> El 2020-04-18 a las 13:51, aitor_czr escribió:
> >
> > Hi,
> >
> > Today I replayed to the translation into spanish of one article
> > written by a systemd developer in Lennart Pottering's blog,
> >
> > and arguing
Hi,
El 2020-04-18 a las 13:51, aitor_czr escribió:
Hi,
Today I replayed to the translation into spanish of one article
written by a systemd developer in Lennart Pottering's blog,
and arguing (*aside* of the translated article) that most of the
systemd detractors are also propietary
Hi,
Today I replayed to the translation into spanish of one article written
by a systemd developer in Lennart Pottering's blog,
and arguing (*aside* of the translated article) that most of the systemd
detractors are also propietary software defenders:
Le 30/03/2020 à 16:33, Hendrik Boom a écrit :
On Mon, Mar 30, 2020 at 03:18:45PM +, aitor_czr wrote:
$ ls --inode --directory "/"
2 /
Is there anything I can do with an inode except check file identity within
a filesystem?
Can I, for example open a file for reading or writing
or read a
Many things. An open file descriptor refers to the inode.
On Mon, Mar 30, 2020 at 10:18 AM aitor_czr wrote:
> Hi,
> On 30/3/20 15:46, Simon Hobson wrote:
>
> Hendrik Boom wrote:
>
>
> On Mon, Mar 30, 2020 at 03:18:45PM +, aitor_czr wrote:
>
> $ ls --inode --directory "/"
>
> 2 /
>
> Is
Hi,
On 30/3/20 15:46, Simon Hobson wrote:
Hendrik Boom wrote:
On Mon, Mar 30, 2020 at 03:18:45PM +, aitor_czr wrote:
$ ls --inode --directory "/"
2 /
Is there anything I can do with an inode except check file identity within
a filesystem?
You can use it as a search condition for find
Hendrik Boom wrote:
> On Mon, Mar 30, 2020 at 03:18:45PM +, aitor_czr wrote:
>>
>> $ ls --inode --directory "/"
>>
>> 2 /
>
> Is there anything I can do with an inode except check file identity within
> a filesystem?
You can use it as a search condition for find using '-inum n'
Other
On Mon, Mar 30, 2020 at 03:18:45PM +, aitor_czr wrote:
>
> $ ls --inode --directory "/"
>
> 2 /
Is there anything I can do with an inode except check file identity within
a filesystem?
Can I, for example open a file for reading or writing
or read a directory given the inode number
instead
Le 12/03/2020 à 22:02, John Morris a écrit :
On Thu, 2020-03-12 at 11:14 +, Rowland penny via Dng wrote:
Here we go again, reinventing the wheel ;-)
Windows has something similar, they call it roaming profiles and that
has its problems.
It isn't exactly reinventing the wheel, it is more
On Thu, 12 Mar 2020 11:25:01 +0100
Martin Steigerwald wrote:
> Hi!
>
> Just a little rant and feel free to ignore it.
>
> systemd-homed… I hope none of it is ever implemented to elogind.
>
> https://www.freedesktop.org/software/systemd/man/systemd-homed.service.html
>
>
On Mar 12, 2020, Simon Hobson wrote:
> Dan Purgert wrote:
>
> > It's certainly useful in a "campus" environment, where you're quite
> > likely at a different computer all the time (i.e. grabbing whatever is
> > free in the computer lab to print your final paper).
>
> Isn't the answer there to
1 - 100 of 500 matches
Mail list logo
