Re: The "Unix Philosophy 2020" document

2020-01-04 Thread Casper Ti. Vector
On Sun, Jan 05, 2020 at 02:31:52PM +0800, Casper Ti. Vector wrote: > I admit that I am quite bad at quarreling with inherently malicious > people on social networks, and now explicitly request you to help > spreading the post -- Twitter, Medium, your private circle, whatever > suitable -- and

Re: The "Unix Philosophy 2020" document

2020-01-04 Thread Casper Ti. Vector
On Sat, Jan 04, 2020 at 08:25:12PM +0200, fungal-net wrote: > For the first time in 2.5yrs of blogging anti-systemd propaganda ONE > article has 10 time more visits in less than 24hrs than the whole blog > (nearly 300 articles) has for a whole day. So someone is interested. (Somewhat) back to

Re: The "Unix Philosophy 2020" document

2020-01-04 Thread Casper Ti. Vector
On Sat, Jan 04, 2020 at 08:25:12PM +0200, fungal-net wrote: > I wouldn't mind reposting this for you if you had asked me yesterday, or > about 18 hours ago, as I have an older decorated account. Many thanks, but I am afraid the submission would still not have met their high "quality" standard

Re: The "Unix Philosophy 2020" document

2020-01-04 Thread fungal-net
Casper Ti. Vector: > On Fri, Dec 27, 2019 at 11:37:19PM +0800, Casper Ti. Vector wrote: >> Now I know the reason. "Your account is too young. Please wait >> at least 5 days to begin posting." --- /u/AutoModerator > > Another try: > . > Given the

Re: The "Unix Philosophy 2020" document

2020-01-04 Thread Laurent Bercot
Another try: . Your efforts are commendable, but r/linux is, like most "general purpose, general audience" fora, a cesspool of ignorance and mediocrity - so the result was predictable. :D (Even if the moderator was well-intentioned, they have

Re: The "Unix Philosophy 2020" document

2020-01-04 Thread Casper Ti. Vector
On Fri, Dec 27, 2019 at 11:37:19PM +0800, Casper Ti. Vector wrote: > Now I know the reason. "Your account is too young. Please wait > at least 5 days to begin posting." --- /u/AutoModerator Another try: . Given the result, it seems that attempts

Re: The "Unix Philosophy 2020" document

2019-12-29 Thread Oliver Schad
On Sun, 29 Dec 2019 18:07:39 +0200 Alex Suykov wrote: > Er, that whole quoted part, including the last sentence, is about > using cgroups to supervise processes. Not about the use of cgroups in > general. I can't think of any other use cases where cgroup > supervision would be useful, other than

Re: The "Unix Philosophy 2020" document

2019-12-29 Thread Alex Suykov
Sat, Dec 28, 2019 at 06:41:56PM +0100, Oliver Schad wrote: > > The reason I think it's mostly useless is because the only use case > > for cgroup supervision is supervising double-forking daemons, which > > is not a very smart thing to do. A much better approach is to get rid > > of

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Oliver Schad
On Sat, 28 Dec 2019 15:05:59 -0300 Guillermo wrote: > Exactly. And that's what nosh's move-to-control-group(1) and > set-control-group-knob(1) do. They are convenience tools invoked by > nosh scripts generated by conversion of unit files (with > 'system-control convert-systemd-units'). Nosh's

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Oliver Schad
On Sat, 28 Dec 2019 12:29:59 -0600 "Serge E. Hallyn" wrote: > Note that with a few simple scripts, users (and daemons) can do this > all themselves. That is true, but the interface to setup and kill the stuff is a bit ugly or long to write. It makes sense to have an elegant/short way to express

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread eric vidal
On Sat, 28 Dec 2019 16:04:53 +0200 Alex Suykov wrote: > Sat, Dec 28, 2019 at 01:57:25PM +1100, eric vidal wrote: > > > Well, for me, cgroups is clearly a lack to s6. Using it for every > > process like systemd do have no sense, but in some case it can be > > useful to protect e.g an "over-eat"

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread eric vidal
> I definitly have to correct you: cgroups are *NOT* designed to catch > wild forking processes. This is just a side-effect ot them. I'm totally agreed. Systemd use it in the wrong way. It should not be used to track processes. > The purpose is to control resource limits, like CPU, RAM, Disk

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Laurent Bercot
If there's important pressure to have cgroups support, I will probably end up applying some version or another of jlyo's patch to s6-supervise Duh, no, I spaced out big time there. jlyo's patch is about namespaces support, not cgroups support. No modification to the supervisor is necessary to

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Serge E. Hallyn
On Sat, Dec 28, 2019 at 06:41:56PM +0100, Oliver Schad wrote: > On Sat, 28 Dec 2019 15:37:35 +0200 > Alex Suykov wrote: > > > The reason I think it's mostly useless is because the only use case > > for cgroup supervision is supervising double-forking daemons, which > > is not a very smart thing

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Oliver Schad
On Sat, 28 Dec 2019 12:19:30 -0300 Guillermo wrote: > El vie., 27 dic. 2019 a las 20:56, Oliver Schad escribió: > > > > Sorry, I have to correct that a bit: you can use the freezer cgroup > > as I did, but there is no guarantee, that you can successfully kill > > a freezed process. > > You

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Oliver Schad
On Sat, 28 Dec 2019 16:04:53 +0200 Alex Suykov wrote: > Sat, Dec 28, 2019 at 01:57:25PM +1100, eric vidal wrote: > > > Well, for me, cgroups is clearly a lack to s6. Using it for every > > process like systemd do have no sense, but in some case it can be > > useful to protect e.g an "over-eat"

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Guillermo
El sáb., 28 dic. 2019 a las 11:06, Alex Suykov escribió: > > Minor note on this. Resource limiting with cgroups does not require > any explicit support from s6, or any external tools for that matter. > Literally just `echo $$ > $cg/cgroup.procs` in the startup script > is enough, assuming the

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Oliver Schad
On Sat, 28 Dec 2019 15:37:35 +0200 Alex Suykov wrote: > The reason I think it's mostly useless is because the only use case > for cgroup supervision is supervising double-forking daemons, which > is not a very smart thing to do. A much better approach is to get rid > of double-forking and then

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Guillermo
El vie., 27 dic. 2019 a las 20:56, Oliver Schad escribió: > > Sorry, I have to correct that a bit: you can use the freezer cgroup as > I did, but there is no guarantee, that you can successfully kill a > freezed process. You can't? So the 'kill -9' command in your script might not work while the

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Alex Suykov
Sat, Dec 28, 2019 at 01:57:25PM +1100, eric vidal wrote: > Well, for me, cgroups is clearly a lack to s6. Using it for every > process like systemd do have no sense, but in some case it can be > useful to protect e.g an "over-eat" allocation memory by a program > (in particular over a server).

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Casper Ti. Vector
On Sat, Dec 28, 2019 at 03:37:35PM +0200, Alex Suykov wrote: > The reason I think it's mostly useless is because the only use case > for cgroup supervision is supervising double-forking daemons, which > is not a very smart thing to do. A much better approach is to get rid > of double-forking and

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Alex Suykov
Sat, Dec 28, 2019 at 01:46:08AM -0500, Steve Litt wrote: > * No if any code within the s6 stack must be changed. So much good > software has gone bad trying to incorporate features for only the > purpose of getting new users. It does not require any changes to s6. That's a major point I'd

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Casper Ti. Vector
On Fri, Dec 27, 2019 at 04:29:13PM -0500, Steve Litt wrote: > What is slew? >From the Gentoo Forums post: "[the example] also uses slew, a flexible framework that thinly (~500 core SLOC, including ~200 for core service definitions) wraps around s6/s6-rc to offer some features commonly requested

Re: The "Unix Philosophy 2020" document

2019-12-28 Thread Casper Ti. Vector
On Sat, Dec 28, 2019 at 04:24:40AM +0200, Alex Suykov wrote: > I don't think a tool like this has any actual uses, other than in > arguments with systemd fans, but I guess that alone could justify > its existance. Thanks. It's brilliant! -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread Steve Litt
On Sat, 28 Dec 2019 04:24:40 +0200 Alex Suykov wrote: > Fri, Dec 27, 2019 at 07:23:09PM +0800, Casper Ti. Vector wrote: > > > I also wonder if someone on this mailing list is interested in > > actually implementing a cgroup-based babysitter as is outlined in > > the post, perhaps packaged

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread eric vidal
> https://github.com/arsv/minibase/blob/master/src/misc/runcg.c > > It's really simple. > > I don't think a tool like this has any actual uses, other than in > arguments with systemd fans, but I guess that alone could justify > its existance. Thanks for this link this is really interesting.

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread Alex Suykov
Fri, Dec 27, 2019 at 07:23:09PM +0800, Casper Ti. Vector wrote: > I also wonder if someone on this mailing list is interested in actually > implementing a cgroup-based babysitter as is outlined in the post, > perhaps packaged together with standalone workalikes of the cgroup > chainloaders

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread Oliver Schad
On Sat, 28 Dec 2019 00:54:07 +0100 Oliver Schad wrote: > Disclaimer: this has race-conditions by design. systemd has them as > well. No, they don't say that of course. You can't read the tasks > atomically and change their state to stopped, freeze or whatever. So > they always could fork away.

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread Oliver Schad
On Fri, 27 Dec 2019 12:32:27 + "Laurent Bercot" wrote: > As for cgroups-related chainloaders, I could probably write some in > s6-linux-utils, but wasn't the cgroups interface designed to make > sure those operations are trivial to implement as small scripts? I changed in the past sysv init

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread Alex Suykov
Fri, Dec 27, 2019 at 04:29:13PM -0500, Steve Litt wrote: > What is slew? I'd guess this thing: https://gitlab.com/CasperVector/slew

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread Steve Litt
On Fri, 27 Dec 2019 21:54:11 +0800 "Casper Ti. Vector" wrote: > On Thu, Dec 26, 2019 at 09:57:35PM -0500, Steve Litt wrote: > > Very, very nice! You should publicize this. > > . > It seems to be downvoted, which may be unsurprising given the

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread Steve Litt
On Fri, 27 Dec 2019 01:52:58 +0800 "Casper Ti. Vector" wrote: > In addition to providing arguments suitable as stock replies to > systemd proponents, that post also contains steps to build a small > example system based on s6/s6-rc/slew, which updates the Ubuntu > example in

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread Casper Ti. Vector
On Fri, Dec 27, 2019 at 09:54:11PM +0800, Casper Ti. Vector wrote: > . > It seems to be downvoted, which may be unsurprising given the generic > sentiment toward systemd in r/linux. Anyway, as of now I cannot load > the post page (perhaps because

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread Casper Ti. Vector
On Thu, Dec 26, 2019 at 09:57:35PM -0500, Steve Litt wrote: > Very, very nice! You should publicize this. . It seems to be downvoted, which may be unsurprising given the generic sentiment toward systemd in r/linux. Anyway, as of now I cannot load

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread Casper Ti. Vector
On Fri, Dec 27, 2019 at 12:32:27PM +, Laurent Bercot wrote: > Is there real pressure to have this? AFAIK, the only pressure is from systemd fanboys. But this is indeed a biggest criticism from them; we would be able to save quite a lot of flamewars if the feature was simply there.

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread Laurent Bercot
I also wonder if someone on this mailing list is interested in actually implementing a cgroup-based babysitter as is outlined in the post, perhaps packaged together with standalone workalikes of the cgroup chainloaders (`create-control-group' etc) from nosh? Is there real pressure to have this?

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread Casper Ti. Vector
On Thu, Dec 26, 2019 at 07:17:02PM +, Laurent Bercot wrote: > That is awesome, and you are doing very important work. Thanks :) > Could somebody volunteer to track down all the similar documents we have, > and make a list of links on a "meta" page? I also wonder if someone on this mailing

Re: The "Unix Philosophy 2020" document

2019-12-27 Thread Casper Ti. Vector
On Fri, Dec 27, 2019 at 02:09:48AM +0100, Oliver Schad wrote: > OMG - how much work was that? Great! The post is mostly based on materials from the UP2020 document, but optimised for length and with information added here and there; the "Linux cgroups" and "Myths" parts are largely new materials.

Re: The "Unix Philosophy 2020" document

2019-12-26 Thread Steve Litt
On Fri, 27 Dec 2019 01:52:58 +0800 "Casper Ti. Vector" wrote: > On Sun, Nov 17, 2019 at 02:26:44PM +0800, Casper Ti. Vector wrote: > > If you are a regular non-anonymous Slashdot reader, I will be very > > grateful if you can vote my recent comment up: > >

Re: The "Unix Philosophy 2020" document

2019-12-26 Thread Oliver Schad
> On Sun, Nov 17, 2019 at 02:26:44PM +0800, Casper Ti. Vector wrote: > > I have written a dedicated "s6/s6-rc vs systemd" post on the Gentoo > forums, which I believe have included convincing responses to most > common arguments by systemd proponents: >

Re: The "Unix Philosophy 2020" document

2019-12-26 Thread Laurent Bercot
I have written a dedicated "s6/s6-rc vs systemd" post on the Gentoo forums, which I believe have included convincing responses to most common arguments by systemd proponents: . That is awesome, and you are doing very important work. (The kind

Re: The "Unix Philosophy 2020" document

2019-12-26 Thread Casper Ti. Vector
On Sun, Nov 17, 2019 at 02:26:44PM +0800, Casper Ti. Vector wrote: > If you are a regular non-anonymous Slashdot reader, I will be very > grateful if you can vote my recent comment up: > > > [I know it is not quite decent to rally for votes

Re: The "Unix Philosophy 2020" document

2019-12-08 Thread Casper Ti. Vector
On Sun, Oct 13, 2019 at 09:57:18PM +0800, Casper Ti. Vector wrote: > Sorry, but there are currently no figures due to a limited time budget; > I will probably make a plan about adding pictures and then implement it, > perhaps before the end of this year if time permits. As a further note, > I am

Re: The "Unix Philosophy 2020" document

2019-11-30 Thread Jeff
30.11.2019, 16:48, "Casper Ti. Vector" : > See also this design: > . since scheme was mentioned in that article: an init/supervisor written entirely in (Guile) Scheme already exists (http://www.gnu.org/software/shepherd/): The GNU Daemon

Re: The "Unix Philosophy 2020" document

2019-11-30 Thread Casper Ti. Vector
On Sat, Nov 30, 2019 at 04:01:40PM +0100, Jeff wrote: > a useful command interpreter should provide some builtins IMO. > this is much more efficient and avoids excessive exec chaining > (analoguous to single combined utils for several tasks vs the > "one task one tool" approach). there might be a

Re: The "Unix Philosophy 2020" document

2019-11-30 Thread Casper Ti. Vector
On Sat, Nov 30, 2019 at 01:29:35PM +, Laurent Bercot wrote: > [...] Here, I'd like to hear *less* about systemd, > and more about better designs. I do not mean to bad-mouth nosh, but I find it really necessary to note that after skimming through `move-to-control-group.cpp', I feel quite

Re: The "Unix Philosophy 2020" document

2019-11-30 Thread Laurent Bercot
Friendly reminder that: - systemd discussion, even criticism, is off-topic, unless it's a deep technical analysis of a part of systemd and whether or not implementing equivalent functionality would be relevant to supervision systems. If you want to rant against systemd, it's certainly a

Re: The "Unix Philosophy 2020" document

2019-11-30 Thread Jeff
> this sounds even more funny with regard to the posting's title > "Unix Philosophy 2020(!!!)". C++ is the perfect language to implement systemd in btw, though even prof. dr. L. Poettering abstained from doing so. will we see a C++ rewrite of our favourite "init framework" (the "master of the

Re: The "Unix Philosophy 2020" document

2019-11-30 Thread Jeff
> why C++ btw ? > > i don't see any benefit in not using C in the first place, > since when does one write Unix system tools in C++ ? > > is it the added "advantage" of bloated binaries and additional > lib dependencies ? this sounds even more funny with regard to the posting's title "Unix

Re: The "Unix Philosophy 2020" document

2019-11-30 Thread Jeff
>>  Macros and/or helper functions (again cf. [1]; they can be factored into >>  a mini-library in nosh) can also be used to reduce boilerplate like >>  > const int error(errno); >>  > std::fprintf(stderr, ..., std::strerror(error)); >>  > throw EXIT_FAILURE; >>  which can be easily observed after

Re: The "Unix Philosophy 2020" document

2019-11-25 Thread Casper Ti. Vector
On Mon, Nov 25, 2019 at 10:52:02AM +0800, Casper Ti. Vector wrote: > Macros and/or helper functions (again cf. [1]; they can be factored into > a mini-library in nosh) can also be used to reduce boilerplate like > > const int error(errno); > > std::fprintf(stderr, ..., std::strerror(error)); > >

Re: The "Unix Philosophy 2020" document

2019-11-24 Thread Casper Ti. Vector
On Sun, Nov 24, 2019 at 05:13:15PM -0300, Guillermo wrote: > Those are just two if statements 'sharing' a body for brevity. That > deals with errors in the openat() and subsequent write() calls, for > the file that controls cgroup membership. By displaying a message > constructed in the same way

Re: The "Unix Philosophy 2020" document

2019-11-24 Thread Guillermo
El dom., 17 nov. 2019 a las 4:28, Casper Ti. Vector escribió: > > A system proponent gave a remark about nosh's `move-to-control-group', > which appears, to some degree, justified: > Those are just two if statements 'sharing' a body for

Re: The "Unix Philosophy 2020" document

2019-11-16 Thread Casper Ti. Vector
On Sun, Nov 17, 2019 at 02:26:44PM +0800, Casper Ti. Vector wrote: > If you are a regular non-anonymous Slashdot reader, I will be very > grateful if you can vote my recent comment up: > A system proponent gave a remark about nosh's

Re: The "Unix Philosophy 2020" document

2019-11-16 Thread Casper Ti. Vector
On Sun, Oct 13, 2019 at 01:37:43AM +0800, Casper Ti. Vector wrote: > [...] Consequently I think that, with an appropriate amount > of publicity for the document, much more people would be willing > to keep an eye on, migrate to, or even help develop daemontools-ish > systems, potentially creating

Re: The "Unix Philosophy 2020" document

2019-10-28 Thread Casper Ti. Vector
On Mon, Oct 28, 2019 at 08:34:31AM -0700, Avery Payne wrote: > For those readers that meet the following critieria: > - Are unfortunate enough to only speak a single language, English; > - And simply want to read an English version of the document; > - Are (un)fortunately running a current Debian

Re: The "Unix Philosophy 2020" document

2019-10-28 Thread Avery Payne
For those readers that meet the following critieria: - Are unfortunate enough to only speak a single language, English; - And simply want to read an English version of the document; - Are (un)fortunately running a current Debian installation with missing Latex dependencies; Do

Re: The "Unix Philosophy 2020" document

2019-10-22 Thread Casper Ti. Vector
On Tue, Oct 22, 2019 at 12:54:17PM -0400, Steve Litt wrote: > What URL is the best one for us to publicize? " for PDFs, for the source code"? (I do not want to clutter the git repo with PDF files...) -- My

Re: The "Unix Philosophy 2020" document

2019-10-22 Thread Steve Litt
On Tue, 22 Oct 2019 23:33:41 +0800 "Casper Ti. Vector" wrote: > On Sun, Oct 13, 2019 at 01:37:43AM +0800, Casper Ti. Vector wrote: > > [...] Consequently I think that, with an appropriate amount > > of publicity for the document, much more people would be willing > > to keep an eye on, migrate

Re: The "Unix Philosophy 2020" document

2019-10-22 Thread Casper Ti. Vector
On Sun, Oct 13, 2019 at 01:37:43AM +0800, Casper Ti. Vector wrote: > [...] Consequently I think that, with an appropriate amount > of publicity for the document, much more people would be willing > to keep an eye on, migrate to, or even help develop daemontools-ish > systems, potentially creating

Re: The "Unix Philosophy 2020" document

2019-10-13 Thread Casper Ti. Vector
(Removed the skaware list from To:, for previously noted reason.) On Sun, Oct 13, 2019 at 10:21:13AM +0200, Oliver Schad wrote: > thank you for the effort putting things together. I was asking myself > some questions. What is the target group? What is the exact purpose of > that document? As was

Re: The "Unix Philosophy 2020" document

2019-10-13 Thread Oliver Schad
Hi Casper, thank you for the effort putting things together. I was asking myself some questions. What is the target group? What is the exact purpose of that document? For systemd I have a more practical approach to discuss: 1) how many config statements are there? 2) how many cases exist, which

Re: The "Unix Philosophy 2020" document

2019-10-12 Thread Casper Ti. Vector
On Sat, Oct 12, 2019 at 02:58:59PM -0400, Steve Litt wrote: > [...] > http://troubleshooters.com/linux/systemd/lol_systemd.htm > [...] Well, I knew that, and cited your diagrams ([15] and [18] in the document as of v0.1.1). I believe those who told me the point about cohesion and coupling in the

Re: The "Unix Philosophy 2020" document

2019-10-12 Thread Steve Litt
On Sun, 13 Oct 2019 01:37:43 +0800 "Casper Ti. Vector" wrote: > However, people told me that the document is not quite accessible to > those who know really little about systemd: one example is they do not > even know much about how the modules are organised in systemd, so the > claim that the

Re: The "Unix Philosophy 2020" document

2019-10-12 Thread Casper Ti. Vector
(I guess discussions about this document is probably destined to be off-topic on the skaware list, so further public mail in this thread will only be posted to the supervision list; sorry for the disturbance.) On Fri, Sep 27, 2019 at 04:38:16PM +0800, Casper Ti. Vector wrote: > Although the