Re: The "Unix Philosophy 2020" document

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 direc

Re: The "Unix Philosophy 2020" document

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 th

Re: The "Unix Philosophy 2020" document

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 [1],

Re: The "Unix Philosophy 2020" document

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 r

Re: The "Unix Philosophy 2020" document

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 p

Re: The "Unix Philosophy 2020" document

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 a

Re: The "Unix Philosophy 2020" document

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

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 double-forking

Re: The "Unix Philosophy 2020" document

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 ser

Re: The "Unix Philosophy 2020" document

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

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" a

Re: The "Unix Philosophy 2020" document

> 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

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 su

Re: The "Unix Philosophy 2020" document

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 t

Re: The "Unix Philosophy 2020" document

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 can

Re: The "Unix Philosophy 2020" document

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" a

Re: The "Unix Philosophy 2020" document

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 group

Re: The "Unix Philosophy 2020" document

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 ju

Re: The "Unix Philosophy 2020" document

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 c

Re: The "Unix Philosophy 2020" document

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). Mi

Re: The "Unix Philosophy 2020" document

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 th

Re: The "Unix Philosophy 2020" document

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 lik

Re: The "Unix Philosophy 2020" document

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 by

Re: The "Unix Philosophy 2020" document

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 (ex

Re: The "Unix Philosophy 2020" document

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 togeth

Re: The "Unix Philosophy 2020" document

> 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. Wel

Re: The "Unix Philosophy 2020" document

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 (`creat

Re: The "Unix Philosophy 2020" document

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. S

Re: The "Unix Philosophy 2020" document

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

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

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 gen

Re: The "Unix Philosophy 2020" document

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

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 of

Re: The "Unix Philosophy 2020" document

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 t

Re: The "Unix Philosophy 2020" document

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. Neverthele

Re: The "Unix Philosophy 2020" document

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

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 li

Re: The "Unix Philosophy 2020" document

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

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

> 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

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 o

Re: The "Unix Philosophy 2020" document

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 vo

Re: The "Unix Philosophy 2020" document

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 f

Re: The "Unix Philosophy 2020" document

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 Shepher

Re: The "Unix Philosophy 2020" document

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 v

Re: The "Unix Philosophy 2020" document

30.11.2019, 15:43, "Casper Ti. Vector" : > "builtins" are supported by the `nosh' interpreter 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 to

Re: The "Unix Philosophy 2020" document

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 concer

Re: The "Unix Philosophy 2020" document

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 heal

Re: The "Unix Philosophy 2020" document

> 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 cgr

Re: The "Unix Philosophy 2020" document

> 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 Philoso

Re: The "Unix Philosophy 2020" document

>>  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

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)); > > th

Re: The "Unix Philosophy 2020" document

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 in

Re: The "Unix Philosophy 2020" document

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

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 `mov

Re: The "Unix Philosophy 2020" document

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 a

Re: The "Unix Philosophy 2020" document

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 i

Re: The "Unix Philosophy 2020" document

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 the

Re: The "Unix Philosophy 2020" document

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

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 t

Re: The "Unix Philosophy 2020" document

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

(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

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

On Sun, Oct 13, 2019 at 01:37:43AM +0800, Casper Ti. Vector wrote: > [...] and as can be inferred from Section 11 [...] I meant Section 10; sorry for that. -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: The "Unix Philosophy 2020" document

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

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 s

Re: The "Unix Philosophy 2020" document

(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 conten

The "Unix Philosophy 2020" document

On Sun, Sep 01, 2019 at 05:11:57PM +0800, Casper Ti. Vector wrote: > I roughly see. Other programs, like date(1) and conky, do seem to > output the correct time after resuming, but I (at least recently, and > you will know why in roughly two to four weeks) really do not have time > to investigate