On Mon, 17 Apr 2017 10:09:02 +0200
exha...@posteo.net wrote:
> in the same way that there's not a perfect graphical desktop for all
> the people,
Quoted for truth!
You can't *download* or *install* the perfect GUI desktop, you must
construct the GUI desktop that's best for you. And that requires
On Tue, Apr 18, 2017 at 03:36:09AM -0400, Steve Litt wrote:
> On Mon, 17 Apr 2017 10:09:02 +0200
> exha...@posteo.net wrote:
>
> > in the same way that there's not a perfect graphical desktop for all
> > the people,
>
> Quoted for truth!
>
> You can't *download* or *install* the perfect GUI desk
Alessandro Selli:
> On Fri, 14 Apr 2017 at 12:06:44 +0200 (CEST)
> k...@aspodata.se wrote:
> > Enrico Weigelt:
> > ...
> > > Let's just take some example: libsrvmgt with funcs like that:
> > >
> > > * srvmgt_daemonize()
> > > --> detach from controlling terminal, etc
> >
> > Why do any monit
On 18/04/2017 at 10:35, k...@aspodata.se wrote:
> Alessandro Selli:
>> On Fri, 14 Apr 2017 at 12:06:44 +0200 (CEST)
>> k...@aspodata.se wrote:
>>> Enrico Weigelt:
>>> ...
Let's just take some example: libsrvmgt with funcs like that:
* srvmgt_daemonize()
--> detach from contr
On Tue, Apr 18, 2017 at 12:21:05PM +0200, Alessandro Selli wrote:
[cut]
>
> > And why should a program/daemon care if
> > it has a monitor or not ?
>
> Why should a car driver care if the traffic light has the red or the
> green light turned on?
> Why should a sysadmin care if the OS he us
On Tue, 18 Apr 2017 11:32:00 +0100
KatolaZ wrote:
> > Why should a car driver care if the traffic light has the red or the
> > green light turned on?
> > Why should a sysadmin care if the OS he uses runs systemd or not?
> >
>
> This is a totally wrong assumption. Being a sysadmin is all a
On 18/04/2017 at 12:32, KatolaZ wrote:
> On Tue, Apr 18, 2017 at 12:21:05PM +0200, Alessandro Selli wrote:
>
> [cut]
>
>>> And why should a program/daemon care if
>>> it has a monitor or not ?
>> Why should a car driver care if the traffic light has the red or the
>> green light turned on?
>>
On Tue, Apr 18, 2017 at 11:32:00AM +0100, KatolaZ wrote:
> On Tue, Apr 18, 2017 at 12:21:05PM +0200, Alessandro Selli wrote:
> > Why should a car driver care if the traffic light has the red or the
> > green light turned on?
> > Why should a sysadmin care if the OS he uses runs systemd or not?
On Tue, Apr 18, 2017 at 01:32:01PM +0200, Adam Borowski wrote:
[cut]
> >
> > This is a totally wrong assumption. Being a sysadmin is all about
> > setting and implementing *policies*. And the choice between systemd or
> > anything else is exactly a matter of policy. So yes, a sysadmin *must*
> >
Allesandro, I'm not interested in a debate (people talking past each
other), I'm interested in understanding why the proposed library and
it function calls are such a good idé, since I don't think it is.
Wheter to run a monitor or not is a different question, which I
consider is up to the local
Le 17/04/2017 à 16:54, Enrico Weigelt, metux IT consult a écrit :
On 17.04.2017 16:37, Joachim Fahrner wrote:
Am 2017-04-17 11:18, schrieb Klaus Ethgen:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
https://github.com/systemd/systemd/issues/5644
No further comment needed.
Have fun reading.
I've read this thread fairly thoroughly, but fail to see much of a use
case...
There's hypothetical stuff, what if service x needs service y. Well, what
if it does. Should it demand that y be running at every moment and on the
same host? DOES it demand that?
This isn't a good thing to spend
Alessandro Selli:
...
> And
> what I don't like of Karl Aspo's idea is that it takes any instrument of
> policy checking and enforcing out of the monitor, which ends up not
> being able to monitor anything, it becomes just a shell: fire and forget.
I honestly do not understand what I have written
On Tue, Apr 18, 2017 at 03:11:51PM +0200, k...@aspodata.se wrote:
[cut]
>
> > I was also been ironic on Aspo, as many times he can only counter
> > another person's ideas asking "What if cannot be trusted?",
> > as if this constitutes a valid argument against being able to set
> > policies for
On Tue, Apr 18, 2017 at 02:15:38PM +0100, Arnt Gulbrandsen wrote:
> I've read this thread fairly thoroughly, but fail to see much of a use
> case...
>
> There's hypothetical stuff, what if service x needs service y. Well, what if
> it does. Should it demand that y be running at every moment and on
kato...@freaknet.org writes:
I genuinely don't understand why the kernel should know about the
internals of running processes, or get notified if a process is
"ready" to do whatever it is supposed to do, or get queried by other
processes which would like to access this kind of information, or
mai
kato...@freaknet.org writes:
Unfortunately we are already paying the consequences of badly-written
software implementing oddly-designed solutions to non-existing
problems...
Indeed. But what's your point?
Arnt
___
Dng mailing list
Dng@lists.dyne.org
On 18/04/2017 at 15:11, k...@aspodata.se wrote:
> Alessandro Selli:
> ...
>> And
>> what I don't like of Karl Aspo's idea is that it takes any instrument of
>> policy checking and enforcing out of the monitor, which ends up not
>> being able to monitor anything, it becomes just a shell: fire and
On Tue, Apr 18, 2017 at 02:48:54PM +0100, Arnt Gulbrandsen wrote:
> kato...@freaknet.org writes:
> >Unfortunately we are already paying the consequences of badly-written
> >software implementing oddly-designed solutions to non-existing
> >problems...
>
> Indeed. But what's your point?
>
Oh, you
Katola2:
> On Tue, Apr 18, 2017 at 03:11:51PM +0200, k...@aspodata.se wrote:
...
> > If I can get a value from the kernel instead of from the process,
> > I'd take the kernel value.
> >
> > Why do a process have to query the kernel to get a value and then
> > sending it to a monitor over a commun
Alessandro:
> On 18/04/2017 at 15:11, k...@aspodata.se wrote:
> > Alessandro Selli:
> > ...
> >> And
> >> what I don't like of Karl Aspo's idea is that it takes any instrument of
> >> policy checking and enforcing out of the monitor, which ends up not
> >> being able to monitor anything, it becomes
On 18/04/2017 at 16:42, k...@aspodata.se wrote:
> Alessandro:
>> On 18/04/2017 at 15:11, k...@aspodata.se wrote:
>>> Alessandro Selli:
>>> ...
And
what I don't like of Karl Aspo's idea is that it takes any instrument of
policy checking and enforcing out of the monitor, which ends up
On 18/04/2017 at 14:46, k...@aspodata.se wrote:
[...]
> Why srvmgt_daemonize(), use -f and daemon() and you'd be fine in
> either camp, end case.
This is well *if* the daemon has -f and does daemon(). I know the
only programs that do not do it are those that were not intended to be
run as dae
On 18/04/2017 at 16:16, KatolaZ wrote:
> On Tue, Apr 18, 2017 at 02:48:54PM +0100, Arnt Gulbrandsen wrote:
>> kato...@freaknet.org writes:
>>> Unfortunately we are already paying the consequences of badly-written
>>> software implementing oddly-designed solutions to non-existing
>>> problems...
>>
On Tue, Apr 18, 2017 at 06:48:31PM +0200, Alessandro Selli wrote:
[cut]
>
> > There is really no other reasonable alternative, IMVHO.
>
> Yes, there is. It's called a good compromise. Then, outside of it,
> you find the purists and the extremists.
>
We have seen what an irresistible avala
On 18/04/2017 at 19:01, KatolaZ wrote:
> On Tue, Apr 18, 2017 at 06:48:31PM +0200, Alessandro Selli wrote:
>
> [cut]
>
>>> There is really no other reasonable alternative, IMVHO.
>> Yes, there is. It's called a good compromise. Then, outside of it,
>> you find the purists and the extremists.
>>
Il 18/04/2017 23:10, Alessandro Selli ha scritto:
> On 18/04/2017 at 19:01, KatolaZ wrote:
>> On Tue, Apr 18, 2017 at 06:48:31PM +0200, Alessandro Selli wrote:
>>
>> [cut]
>>
There is really no other reasonable alternative, IMVHO.
>>> Yes, there is. It's called a good compromise. Then, out
On Tue, Apr 18, 2017 at 11:10:24PM +0200, Alessandro Selli wrote:
> On 18/04/2017 at 19:01, KatolaZ wrote:
> > On Tue, Apr 18, 2017 at 06:48:31PM +0200, Alessandro Selli wrote:
> >
> > [cut]
> >
> >>> There is really no other reasonable alternative, IMVHO.
> >> Yes, there is. It's called a good
Dear Devuaners,
just to let you know that a .deb package for apulse is now available
in experimental (except for armel: I am working on that). Just add the
repo:
deb http://packages.devuan.org/devuan/ experimental main
to your sources.list, and then "apt-get update && apt-get install
apulse" s
In the middle of installing several packages using
apt-get install postgresql ruby-sass
I get a message.
Setting up postgresql-common (165+deb8u2) ...
supported-versions: WARNING! Unknown distribution: devuan
/usr/share/postgresql-common/supported-versions: 64:
/usr/share/postgresql-common/su
30 matches
Mail list logo
