IRC Logs for #crux-devel Monday, 2015-02-23

*** Feksclaus has quit IRC00:56
*** mavrick61 has quit IRC03:28
*** mavrick61 has joined #crux-devel03:29
*** Feksclaus has joined #crux-devel07:47
frinnstyes, a bunch of scripting08:16
frinnstIm surprised anybody thinks this is a big deal or negative in any way08:17
frinnstyeah sure, maybe it wasnt handled that great by us. Im pretty sure jue sent out a notification when it was introduced08:18
frinnstbut otherwise i think ssd is the best thing since sliced bread08:18
jueprologic: sure, I'm kidding, but it looks like you doesn't read the related email ;)08:20
jueprologic: our current scripts are just too simple, frinnst noticed some points08:22
jueplease read the man-page and you will see that ssd is a really nice one ->
jueone point that bugged me ever was the 'sleep' call in restart, because we had to wait some time until the daemon finishes, but how long?08:24
jueto do this in sh is a lot more effort that to just call --retry08:25
jueprologic: have you seen what alan did with samba? Look here ->;a=blob;f=samba/smbd.rc;h=0c22f3ccbf9c0625d4df047fff678cb64f4fdb44;hb=HEAD08:26
jueisn't it much clearer to do the same and more with ssd?08:27
jueanyway, I have to admit that it might have been better to wait a bit longer or to do more than a [notify] commit with with the sshd rc-script08:30
juebut the scirpt was important for me because I liked to remove the rsa1 key and fix one bashism in it08:32
juehave to run now, bbl08:36
Romsteralan makes valid points.08:54
Romsterwhy can't we have a watchdog paralleled daemon similar to how runit does it. and it also takes care of starting services in the correct order if one depends on another.08:54
prologicfrinnst, you think it's the best thing since sliced bread :)09:00
prologicand I don't necessarily think ssd is neither better nor simpler (kiss)09:00
prologicI know the various shell scripting and core tools09:00
Romsterall ssd does is shift the complexness from many rc scripts to the one tool09:01
prologicmy grumblness (sorry) was that this wasn't communciated very well09:02
prologicbut I side with one of Alan's points in that we *shoudl* improve the quality of our rc scripts09:02
prologicrather than palming the problem off to ssd ihmo09:02
prologicand if we are serious about process supervision and the benefits it provides we should think about replacing SysVInit09:02
prologicall my points are in that ml thread09:03
prologicalso the thing is for all that ssd may do09:04
prologiccan be scripted with shell scriprting with improved shell functions09:04
prologicit's not like it's calling any magical libc functions09:04
prologicanyway I've said all I've wanted to say -- so if this is the decision and there's no if's but's or maybe's -- then please a) document it now in the handbook/wiki/etc and b) send a nice email to the user ml09:05
Romsternot to toot or anything but there is a mailing list email. to crux lists.
prologicI still don't like it because it's a band-aid solution to two things a) quality rc/init scripts and b) lack of process supervision (sysvinit)09:06
prologicRomster, as I said in the ml thread on this topic09:07
prologica "notify" email is not enough09:07
prologicas humans we tend to get complacent and start to ignore similar frequent/many things09:07
Romsteri do agree this does feel like a bandaid to sysvinit. and shell.09:08
frinnstI much prefer something like ssd over a 2 page initscript09:08
Romsterand i have to agree with frinnst on that.09:08
prologicfrinnst, sure that's fine09:08
Romsterthink we all have differing opinions here.09:08
prologicwhat's stopping us from having common shell rc/init functions?09:09
frinnstwe do now: ssd :)09:09
Romsteryou mean us having better shell code in /etc/rc.* to do do this for us09:09
prologicI don't agree but anyway :)09:09
prologicssd is half of a process supervisor09:09
prologicso why not let's just replace sysvinit09:09
prologicrunit, finit09:10
prologicbut systemd09:10
Romsteri liked runit but docs where pretty light on.09:10
prologicRomster, e.g: source /etc/rc.functions09:10
prologicfinit looks nice and might fit with CRUX's philosophy :)09:10
Romsterindeed we could just improve our /etc/rc.functions09:10
prologicyou mean actually have one :)09:11
jueprologic: is it really necessary to send html emails to a mailing list?10:51
jueprologic, Romster: I don't get the whole excitement, nobody is forced to use ssd, if you dont like it don't use it in your daemon scripts10:54
jueand replacing sysvinit with something else is quite a different story IMO10:55
jueprologic: sorry, I have to ask again, why do you think that ssd isn't simpler to use than a sh script that does the same? Have you looked at the smbd.rc script I mentioned above?12:15
prologicit's just a matter of taste and another thing to learn12:24
prologicI feel most users that really know crux tend to know shell scripting really well too12:24
prologicI'm sure ssd does a marvelous job12:24
prologicbut I'm going to have to learn that :)12:24
prologicit is still also doing half the job of a proper process supervisor12:24
prologicbut as you say - that's another story12:24
prologicalso re the html emails - I guess that's a google apps / gmail thing12:25
prologicnot even sure there's an easy way to turn this off really12:25
prologicwithout using a different mua12:25
prologicI use the web ui :)12:25
prologicanyway I'm sure the use of ssd will turn out just fine12:26
prologicbut this should have been a crux 3.2 and better communicated12:26
Romsterthe fact is if you forget to install ssd now you will get locked out of the box on reboot. from sshd not running. i think that rc script should at least be kept at the old one for a time period. and pkgadd.conf altered so it gets reviewed with rejmerge.12:31
Romsteror just changing the pkgadd.conf defaults before this really hits someone that runs crux in a datacenter with no on site sysadmin.12:34
Romsterwe inject new dependencies on a new upgrade this should of been delayed for crux 3.2. just my opinion. too late for that now so fixing pkgadd.conf asap would probably save this from happening.12:35
Romsterand if it did happen then. it's the sysadmins fault for not reviewing rejmerge12:36
Romstergoes back to game and relaxes12:36
Romsterhad one of them super busy days.12:36
Romsterhow long will it be supported by debian, since they new use systemd that makes that obsolete?13:11
jueas with everything in debian: this will take a long time13:15
jueand, as I wrote in my email, there's always the compatible start-stop-daemon in openrc13:16
Romsterah i missed that bit sorry.13:18
frinnstlol at the ssd hate15:45
juefrinnst: yeah, I don't understand it neither, thought we did a good thing ;)16:37
jaegerI think it's a good change, should make things cleaner and more consistent at the least16:38
juewell, if I read the mail from khm it looks like we, or better I, did something very stupid16:46
frinnstyeah I say we just ignore it. there's always someone(s) that wont like it18:06
frinnstunless someone can come up with something concrete18:06
frinnstI wont contribute to that thread atleast18:08
jaegerwould it be worth looking into runit or finit for 3.2, perhaps?18:57
prologicjaeger, definately20:01
prologicfinit at least looks like it might be right up our alley20:01
prologicjue, not stupid at all20:01
prologicjust poorly communicated :020:01
prologicbut I think we're all good :)20:01
prologicI've slept, I'm over it20:01
prologicI'll learn ssh and get over it :)20:01
prologicWe *should* really think about runit or finit though20:02
prologicjust to clarify; it would be like me changing a core component in circuits.core (a Python Async I/O app framework) without warning anyone or making a new major release, just a single Mercurial commit message20:03
prologiccircuits is also released only once per year and we try very hard not to break things :)20:04
*** leo-unglaub has joined #crux-devel20:58
*** Feksclaus has quit IRC21:43
*** leo-unglaub has quit IRC23:39
*** leo-unglaub has joined #crux-devel23:42

Generated by 2.11.0 by Marius Gedminas - find it at!