On Thu, 9 Jun 2016 11:22:40 -0400, Dan wrote in message
<20160609152240.gm9...@xps-linux.djph.net>:
> Simon Walter wrote:
> > On 06/09/2016 07:07 AM, Dan Purgert wrote:
> > >Yet another thing that systemd is getting its tentacles into ...
> > >wonder when the majority of users will say "enough is
Simon Walter wrote:
> On 06/09/2016 07:07 AM, Dan Purgert wrote:
> >Yet another thing that systemd is getting its tentacles into ... wonder
> >when the majority of users will say "enough is enough" with it?
> >
> >
>
> They will not. The majority of users are freeloaders. So we may end up
> using
Le 08/06/2016 23:49, Rainer Weikusat a écrit :
https://www.kernel.org/doc/Documentation/cgroup-v2.txt
Thanks for the link. Not that I want to control resource usage, but
cgroup can help to keep track of processes.
Didier
___
Dng mailing l
On Thu, Jun 09, 2016 at 10:24:55AM +0900, Simon Walter wrote:
> linuxvoice.com/interview-lennart-poettering
>
> It's an old article, but as I read, I realized how much I disagree with
> Lennart. TBH, he sounds like an Apple fan.
>
Good morning, Simon! ;)
>
> I don't like Upstart or Cannonical
Hi,
So, GNOME users will be hand-held to have their background processes
terminated automatically. And, those who want to bypass this
functionality need to tweak their system to allow some background
processes persist. Huh, this mysterious tweaking looks like the right
recipe System administra
linuxvoice.com/interview-lennart-poettering
It's an old article, but as I read, I realized how much I disagree with
Lennart. TBH, he sounds like an Apple fan.
Now we get controversial, because those who like to feel smart, yet
don't know much, feel empowered by AI. Those who don't feel smart,
On 06/09/2016 07:07 AM, Dan Purgert wrote:
Didier Kryn wrote:
[snip]
I cite:
"Systemd and cgroup developers are working together to turn systemd into a
global cgroup manager that creates higher-level control knobs and prevents
direct access to the kernel. Many Systemd changes are already r
Didier Kryn wrote:
>[snip]
>
> I cite:
> "Systemd and cgroup developers are working together to turn systemd into a
> global cgroup manager that creates higher-level control knobs and prevents
> direct access to the kernel. Many Systemd changes are already released
> while cgroup changes are s
Didier Kryn writes:
> Le 08/06/2016 12:49, KatolaZ a écrit :
>> Killing all the processes at logout should be easily doable using
>> cgroups (which existed much before Poettering got his bachelor
>> degree), and is indeed easily doable with screen, nohup, and hundred
>> of similar amenities.
>
>
Le 08/06/2016 23:31, Didier Kryn a écrit :
one of the documents I found
(https://www.linux.com/blog/all-about-linux-kernel-cgroups-redesign)
is full of references to systemd to the point it is literally disgusting.
I just found the explanation, the rewriter, and current developper
of cgr
Le 08/06/2016 12:49, KatolaZ a écrit :
Killing all the processes at logout should be easily doable using
cgroups (which existed much before Poettering got his bachelor
degree), and is indeed easily doable with screen, nohup, and hundred
of similar amenities.
I looked for documentation on cg
Edward Bartolo wrote:
> One strategy would be to deny
> server access to anyone not using systemd. This would force Devuan to
> set up an entirely independent infrastructure. I think, this may do
> some serious disruption: be prepared as Devuan is not yet totally
> divorced from Debian.
I suspec
On Wed, 08 Jun 2016, Dan Purgert wrote:
> This was in the comments of the article on lwn (sorry, I forget who
> linked it on the mailing list). I'm honestly not sure how "true" it is,
> but it seems to coincide with what else I've been reading.
>
> 1. In the beginning there was there login. Every
On Wed, Jun 08, 2016 at 10:43:41AM +0200, Didier Kryn wrote:
>
> I sometimes have to logout and login again to be able to kill
> wild threads of Icedove which survive in a blocked state after the
> windows have been closed. The idea to be able to kill all processes
> started in a session is no
KatolaZ wrote:
> On Wed, Jun 08, 2016 at 12:13:48PM +0200, Didier Kryn wrote:
>
> [cut]
>
> >
> > Yes, nohup. I guess it issues setsid() and disconnects from the
> > controlling terminal, but any process can do that on its own. I was thinking
> > of a way to decide which session can do that
Jaromil wrote:
> On Wed, 08 Jun 2016, Didier Kryn wrote:
>
> > Otherwise, I like the idea to have a better control of what
> > survives a session.
>
> I also like that and I like that is simply made.
>
> For many of us is already made possible in simple ways: you run inside
> screen (or even
Hi,
The current strategy looks very tentatively similar to how a bully
behaves when they repeatedly fail to visibly persecute (control) their
victims. Making architectural decisions that clearly break other
utilities that work to force users to use systemd is nothing less that
a wild cry from frus
On 06/08/2016 07:49 PM, KatolaZ wrote:
[sorry for the long reply]
Very well put.
Killing all the processes at logout should be easily doable using
cgroups (which existed much before Poettering got his bachelor
degree), and is indeed easily doable with screen, nohup, and hundred
of similar am
On Wed, Jun 08, 2016 at 12:13:48PM +0200, Didier Kryn wrote:
[cut]
>
> Yes, nohup. I guess it issues setsid() and disconnects from the
> controlling terminal, but any process can do that on its own. I was thinking
> of a way to decide which session can do that and which cannot, and I imagine
Le 08/06/2016 11:07, Jaromil a écrit :
On Wed, 08 Jun 2016, Didier Kryn wrote:
> Otherwise, I like the idea to have a better control of what
>survives a session.
I also like that and I like that is simply made.
For many of us is already made possible in simple ways: you run inside
screen
On Wed, 08 Jun 2016, Didier Kryn wrote:
> Otherwise, I like the idea to have a better control of what
> survives a session.
I also like that and I like that is simply made.
For many of us is already made possible in simple ways: you run inside
screen (or even better tmux, having read screen'
21 matches
Mail list logo
