Conversation with #inferno at Sat Oct 18 23:31:49 2008 on powerman-asdf@irc.freenode.net (irc) (23:31:49) #inferno: The topic for #inferno is: Inferno and Limbo | Website: http://www.vitanuova.com/inferno/index.html | Documentation: http://www.vitanuova.com/inferno/docs.html | Wiki: http://canto.hopto.org/wiki/1/index.html | Tutorial: http://www.resc.rdg.ac.uk/twiki/bin/view/Resc/InfernoTutorial | Mailing list archives: http://dir.gmane.org/gmane.os.inferno.general (23:40:58) olegfink left the room (quit: "WeeChat 0.2.6"). (01:26:10) gualteri left the room. (01:54:30) eekee left the room (quit: Read error: 60 (Operation timed out)). (03:30:42) uriel: powerman-asdf: you around? (03:30:53) powerman-asdf: uriel: yep (03:32:39) uriel: I'm adding some russian translations of the plan9 papers that I have found to the doc archive (03:32:52) uriel: was wondering if you could take a look, because I'm not sure what I'm doing :) (03:33:05) uriel: http://doc.cat-v.org/plan_9/translations/russian/papers/ (03:36:32) powerman-asdf: uriel: it's ok. except most links don't work (yet?) (03:37:16) uriel: yea, I know, I'm slowly adding each page (03:37:47) uriel: they need to have their html fixed up a bit (and converted to utf-8 and so on) (03:40:37) powerman-asdf: utf-8... you know, I've converted my Gentoo to utf-8 right after I've to send my translation to you and realize chances are you know nothing about koi8-r :) (03:41:48) powerman-asdf: so I decide it's good timing to switch overall system to utf-8... something I delayed for years because there was a lots of bugs in utf-8 support in software which works just fine with non-utf-8 (03:49:40) uriel: yea, linux's utf-8 support is a joke (03:49:54) uriel: full of really nasty and insidious bugs and it is really slow and just stupid (03:51:32) powerman-asdf: yep. but I decide, at end of 2008, there finally _more_ software buggy with non-utf-8 input than software buggy with utf-8 input :D (03:51:47) uriel: haha (03:52:05) uriel: plan9 had non-buggy utf-8 since 1993 ;) (03:56:30) powerman-asdf: uriel: It's sacrilege, but is it also had non-buggy amarok, opera, vim, mutt, bash, mc? I never used plan9 and probably never will. Linux UI as programmer's workstation is ideal for me. And Gentoo plus a lot of DJB software instead of standard give me enough reliability as for sysadmin. (03:56:30) powerman-asdf: But I hate these complex and buggy internals... glibc and linux kernel are just jokes. So while I'd like to use it, I unlike idea to program my software for it. So, that's why Inferno but not Plan9. (03:58:05) powerman-asdf: Maybe I'm not enlightened enough. I've tried acme. Several times. No success. I tried hardly. Maybe few years later, when I become a little more smarter/older. (04:24:28) powerman-asdf: uriel: btw, do you aware about 'killgrp'>/prog/n/ctl doesn't kill _all_ processes in group? (04:24:38) powerman-asdf: man says: Kill all processes in the same group as the process. A process writing to its own ctl file does not kill itself. (04:24:43) powerman-asdf: but that's not true (04:25:23) powerman-asdf: I'm experiment with Eratosthenes module from ipwl: http://www.gemusehaken.org/ipwl/sourcecode/book-examples/sieve-naive.b (04:27:05) powerman-asdf: I modified it to stop after 10000 iterations, and added NEWPGRP plus "killgrp". (04:27:47) powerman-asdf: After it exits, I see ~20 threads alive. killgrp has killed about ~1200, but left these 20. (04:28:25) powerman-asdf: Executing killgrp second time solve issue. But that's not normal. (04:29:20) uriel: powerman-asdf: re plan9, I don't know about amrok (*yuck*), but you can run opera just fine with linuxemu (04:29:46) uriel: (somebody ported vim natively, as for bash, the least said the better) (04:29:49) powerman-asdf: here is mine: http://powerman.name/tmp/sieve-naive.b (04:30:40) uriel: as for the killgrp issue, all I can say is: http://code.google.com/p/inferno-os/issues/list (04:32:18) powerman-asdf: uriel: I don't think porting linux software with all their internal ugliness and complexity into plan9 make plan9 better. "if you want linux - use linux and fuck off from plan9." :) I heard this somewhere and tend to agree. (04:32:56) uriel: powerman-asdf: well, that is what I say, but still, sometimes you have to do what you hate to do and it can't be helped (04:33:05) powerman-asdf: ok, if you think it's a bug, then I'll report it. there was chance I missed something, as usually. (04:33:35) uriel: I have no idea if it is a bug or not, but if the documentation doesn't match the observed behavior, it is a bug as far as I'm concerned (04:34:09) powerman-asdf: unless both documentation and behaviour doesn't match user at console :) (04:40:11) uriel: could be :) (05:08:21) uriel left the room (quit: Read error: 110 (Connection timed out)). (05:21:44) KillerX left the room (quit: ). (06:24:23) underspecified_ [n=eric@softbank220043052011.bbtec.net] entered the room. (06:24:32) underspecified left the room (quit: Read error: 54 (Connection reset by peer)). (07:46:10) uriel [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room. (08:20:44) eno__ [n=eno@adsl-70-137-168-121.dsl.snfc21.sbcglobal.net] entered the room. (08:21:28) eno left the room (quit: Read error: 60 (Operation timed out)). (08:33:00) underspecified_ left the room (quit: ). (08:45:36) uriel_ [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room. (09:03:19) uriel left the room (quit: Read error: 110 (Connection timed out)). (11:26:50) underspecified [n=eric@softbank220043052011.bbtec.net] entered the room. (12:33:39) rog [n=rog@78.148.90.236] entered the room. (14:53:39) KillerX [n=anant@gentoo/developer/KillerX] entered the room. (15:18:47) underspecified left the room (quit: ). (16:01:15) uriel [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room. (16:12:11) eekee [n=eekee@cpc4-lanc4-0-0-cust12.brig.cable.ntl.com] entered the room. (16:13:49) uriel_ left the room (quit: Read error: 104 (Connection reset by peer)). (16:19:36) mennis_ left the room (quit: Read error: 104 (Connection reset by peer)). (16:49:30) uriel_ [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room. (16:49:38) uriel left the room (quit: Read error: 104 (Connection reset by peer)). (17:00:49) olegfink [i=olegfink@62.141.52.142] entered the room. (17:17:15) rog_ [n=rog@78.144.45.195] entered the room. (17:25:39) rog left the room (quit: Read error: 110 (Connection timed out)). (18:19:40) underspecified [n=eric@softbank220043052011.bbtec.net] entered the room. (18:27:44) eno__ left the room (quit: "leaving"). (19:13:56) eekee left the room (quit: Read error: 145 (Connection timed out)). (19:20:30) pierre- [n=pierre@93-81-58-99.broadband.corbina.ru] entered the room. (19:24:17) uriel_ is now known as uriel (19:33:07) eekee [n=eekee@cpc1-lanc4-0-0-cust860.brig.cable.ntl.com] entered the room. (21:54:16) pierre- left the room (quit: Read error: 60 (Operation timed out)). (23:30:18) rog [n=rog@78.144.139.202] entered the room. (23:38:03) rog_ left the room (quit: Read error: 110 (Connection timed out)). (00:18:30) npe [n=npe@66.112.249.148] entered the room. (00:38:47) ooooo [i=none@201.80.219.33] entered the room. (00:57:39) rog left the room (quit: ). (01:25:28) ooooo left the room (quit: Remote closed the connection). (01:28:49) npe left the room (quit: ). (02:12:51) KillerX left the room (quit: ). (04:15:42) underspecified left the room (quit: ). (05:07:45) underspecified [n=eric@clair18.naist.jp] entered the room. (05:09:06) ooooo [i=none@201.80.219.33] entered the room. (05:17:33) uriel_ [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room. (05:31:39) uriel left the room (quit: Read error: 110 (Connection timed out)). (05:44:30) uriel_ is now known as uriel (06:42:40) uriel_ [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room. (06:57:14) uriel left the room (quit: Read error: 110 (Connection timed out)). (10:22:00) uriel_ is now known as uriel (10:38:53) mjl-: morning (10:39:28) eekee: hallo (10:39:53) mjl-: yo eekee (10:39:58) rog [n=rog@78.148.28.10] entered the room. (10:39:58) eekee: what's up? (10:40:06) mjl-: not too much (10:40:10) mjl-: getting ready for work :) (10:40:15) mjl-: coffee almost ready ;) (10:40:15) eekee: ah ya :) (10:40:16) mjl-: morning rog (10:40:18) eekee: :) (10:40:29) mjl-: something happening at your end? (10:41:03) eekee: not majorly. There's been a long discussion on the fragmentation of inferno in #plan9 though (10:41:11) eekee: and other related topics (10:41:15) mjl-: yeah, i just read a bit of it (10:41:35) mjl-: slow mailing list... i guess that's not too nice (10:41:38) mjl-: good we have irc ;) (10:41:41) eekee: no indeed (10:41:41) mjl-: the biggest time waster! ;) (10:41:42) eekee: ya ;) (10:41:44) eekee: hehe (10:41:49) mjl-: btw, regarding patches (10:42:07) eekee: I would like to launch a 'proper' distro for 9 or inferno (10:42:23) mjl-: the last too patches i sent to the inferno-os google code bug thing were applied very quickly (within a few hours!) (10:42:28) eekee: oh nice (10:42:29) mjl-: i agree they were trivial, but still (10:42:43) mjl-: charles is definately paying attention to those (10:43:05) mjl-: but i guess the bigger bug reports (which also don't have a patch attached ;)), don't get much priority if they are not bothering vn (10:43:07) eekee: I wonder why other patches weren't applied then? (10:43:16) eekee: vn? (10:43:16) mjl-: me neither (10:43:20) mjl-: vitanuova (10:43:24) eekee: oh right (10:43:40) mjl-: somehow my hands never want to type "vitanuova" right the first time ;) (10:43:47) mjl-: correctly* (10:44:00) eekee: oh heck yeah, sorry I had to ask (10:44:10) mjl-: anyway, making a "proper" distro is a lot of work :) (10:44:16) mjl-: and there is acme-sac (10:44:25) mjl-: which is a bit like it, but different (10:45:57) eekee: yeah... I was just thinking sometimes I can't think clearly for a few days (or weeks when it's bad) & that could kill it (10:46:09) mjl-: true (10:46:23) mjl-: i'm always wondering who else is working behind the screens at vn, besides vn (10:46:34) mjl-: it always seems like it's a one-man show (10:46:57) eekee: maybe it is (10:46:58) mjl-: but that would mean so much work... charles couldn't do it on his own i think (10:47:18) eekee: well hmm (10:47:40) mjl-: anyway (10:47:46) mjl-: if we want patches to be applied (10:48:03) mjl-: i think the easiest (and best for starters) is testing them ourselves fist (10:48:04) mjl-: first* (10:48:12) mjl-: you are here, powerman, me, we use inferno quite a lot (10:48:13) eekee: yeah of course (10:48:23) eekee: mmm (10:48:44) mjl-: and the inferno-os from svn seems to be working quite nicely for me (10:48:55) mjl-: so i don't have an immediate need to have that changed or anything (10:48:57) eekee: ahh (10:49:00) eekee: I C (10:49:21) mjl-: and for new software: i don't think it has to end up in inferno-os. can be distributed from p9's contrib (10:49:25) mjl-: or some other means (10:49:38) mjl-: or do you have different needs/views? (10:51:35) eekee: not really, just that contrib index is (or was) exceptionally slow and full of odd little bits of undocumented code, very few packages use fgb's contrib system (10:51:39) eekee: etc etc lol (10:51:47) eekee: I'm looking for a cleanuup, I guess (10:52:22) mjl-: i agree, it isn't pretty (10:52:35) mjl-: but that is hardly a reason to fork an os :P (10:52:58) mjl-: having some kind of "package" for inferno that can be executed without "installing" it into the base system, could be nice (10:53:20) eekee: not from this perspective, no, but much of the talk seemed to be about the core system (10:53:35) eekee: but if svn inferno works... (10:54:06) mjl-: with core system you mean which libraries & tools are available? (10:55:08) eekee: and languages, yeah (10:55:26) mjl-: interesting (10:55:31) mjl-: which would you like? (10:55:35) mjl-: or is that in #plan9 backlog? (10:55:46) eekee: oh not so much which, as problems with what's there (10:55:52) eekee: bugfixes (10:55:56) mjl-: ah, ok (10:56:19) mjl-: i would like to have the time to read through the limbo compilers (10:56:26) eekee: also the dev in charge of inferno-openmoko is adding all sorts of stuff to lmbo (10:56:29) eekee: *limbo (10:56:33) mjl-: it doesn't look too complex, but still a lot of code (10:56:38) mjl-: really? (10:56:53) mjl-: i saw a list (10:57:00) mjl-: but i didn't expect that to get implemented anytime soon (10:57:02) eekee: yeah.. well pcre came up as the worst thing. Aparently it's a terribly innefficient regexp implementation (10:57:30) mjl-: i guess inferno's regex could do with a with improvements (10:57:54) mjl-: but doesn't pcre jit regexes into machine code? (10:58:19) mjl-: i like some of the "newer" regex syntax (e.g. as python has) (10:58:21) mjl-: but not all (10:58:49) eekee: possibly, but despite that there was a web page posted which I will kill myself if I've lost... it showed pcre implementation being thousands of times slower than old un*x code (which will also be present in plan 9 & inferno) (10:59:13) eekee: aha: http://swtch.com/~rsc/regexp/regexp1.html (10:59:28) mjl-: yes, i've seen that (10:59:39) mjl-: i think some of the libs mentioned have a workaround now (10:59:43) mjl-: so they use the faster method (10:59:46) eekee: ahh (11:02:16) powerman-asdf: the question is, if anything so nice, then why inferno's regex(6) doesn't have all these nice features? (11:02:41) eekee: that's easy, it's an old standardised implementation (11:02:50) eekee: (inferno's regex, that is) (11:02:58) eekee: also people have got used to a different standard (11:03:34) mjl-: jups (11:03:36) rog: hi folks (11:03:46) rog: nice to see some activity on the inferno list (11:03:50) powerman-asdf: hehe (11:04:18) rog: FWIW, vitanuova *is* just charles these days. (11:04:38) rog: ... and has been for a while now. (11:04:47) mjl-: ah, thanks for the info (11:04:52) mjl-: i can't say "good to hear" (11:04:59) mjl-: he is doing quite a job then (11:05:12) mjl-: assuming he has work to do that pays bills (11:05:33) rog: i think he doesn't advertise it because then people won't consider inferno a viable platform, and he really wants it to go somewhere. (11:05:41) eekee: uriel: check up to date info on the implemmentation of things you want to complain about before scaring people ;P (11:05:52) mjl-: powerman-asdf: as for e.g. regex(6). i think p9 (and inferno) people normally stick to something proven, and definately don't just on the new-features bandwagon. perhaps a bit too much sometimes... (11:06:06) mjl-: inferno should go somewhere (11:06:15) mjl-: it is very good stuff (11:06:20) rog: there is an implementation of perl regex somewhere in inferno. possibly in the ecmascript stuff. (11:06:25) powerman-asdf: as for me, I _tend_ to agree (11:06:45) powerman-asdf: this taken from context of discussing inferno-openmoko (11:07:01) eekee: ok (11:07:02) mjl-: hah cool, rog knows the source code from his head of course! :) (11:07:10) rog: perl regexp is really complex. and it has backtracking, which can invoke really bad performance. (11:07:41) eekee: Aye I figured about backtracking (11:07:43) rog: mjl-: i never worked on the ecmascript stuff, actually. i think it was chris locke, and later john firth. (11:08:11) mjl-: heh ok, so you know the location of source code! ;) (11:08:12) rog: john firth, BTW, was responsible for all the later limbo developments. (11:08:29) rog: mjl-: /appl/lib/ecmascript ?? :-) (11:08:36) mjl-: BINGO :P (11:08:44) ***rog goes to look (11:09:14) rog: yup (11:09:42) mjl-: but i guess i really meant that you know which kind of code exists somewhere, and the general name for it :P (11:10:06) rog: % wc regexp.b (11:10:06) rog: 1286 4450 26964 regexp.b (11:10:07) rog: % wc $I/appl/lib/regex.b (11:10:07) rog: 389 1342 8114 /Users/rog/inferno/appl/lib/regex.b (11:10:18) rog: where the first one is from ecmascript (11:10:25) rog: you can see the difference... (11:10:32) eekee: cor (11:11:24) eekee: how much would character classes account for? (11:11:31) rog: dunno (11:11:32) powerman-asdf: rog: can you please point me to doc which document conventions related to thread exit status? I mean these nice "fail:*" and "interrupted" things, which handled in special way by dis and sh? (11:12:44) rog: powerman: see prog(3). and in particular the "wait" file. (11:12:52) powerman-asdf: was there. nothing there. (11:13:24) rog: eekee: if you mean character class tables. it seems none - there are no obvious big tables of numbers in the code. (11:13:52) eekee: eenteresting (11:13:53) powerman-asdf: "The error message will contain at most 64 characters.". That's all. (11:14:14) rog: oh, i see what you mean. (11:15:48) rog: where is "interrupted" treated specially? (11:16:01) rog: i think that's an internal thing, no? (11:17:02) powerman-asdf: hehe (11:17:03) powerman-asdf: no (11:17:12) powerman-asdf: just try raise "interrupted" (11:17:27) powerman-asdf: and thread will not be in broken state (11:18:00) powerman-asdf: dis doesn't differ between interrupted generated by kill and by user's raise (11:18:55) powerman-asdf: when such things doesn't documented it may costs somebody some time debugging... a lot of time, if he will be out of luck (11:20:22) rog: yeah. it should probably be documented, along with the fail: convention somewhere. (11:20:48) eekee: see this is what I was plugging for, (11:21:11) powerman-asdf: rog: ok, thanks. I'll do this and will send it to issue tracker. (11:21:18) rog: the fail: convention is more important though. i can't see the interrupted thing being much of a problem in practice. (11:21:32) rog: and i'm not sure where the best place would be to document it (11:21:37) eekee: in a well-maintained system doc bugs like that wouldn't take long to fix (11:21:53) mjl-: powerman-asdf: you made the inferno manual page index ordered by subject, right? (11:22:11) uriel: eekee: did you see my post to inferno-list with dozens of broken references in the man pages? they have been there for years, nobody gives a shit (11:22:14) powerman-asdf: interrupted may lead to strange behaviour - someone's thread will disappear without any noticed and without becoming broken (11:22:28) mjl-: uriel: when did you send that? (11:22:33) mjl-: i don't recall reading it (11:22:36) powerman-asdf: just because someone used 'raise "interrupted"' (11:22:59) uriel: (nobody gives a shit because the only people using inferno are the people that already know it and have no need for documentation) (11:23:05) uriel: mjl-: months ago (11:23:11) rog: powerman-asdf: ... but that's pretty unlikely, in all honesty. (11:23:17) mjl-: uriel: ok, i see it (11:23:22) mjl-: uriel: i've noticed some errors too (11:23:37) mjl-: and man2html is far from perfect (11:23:40) uriel: mjl-: Aug 23: Fixes for man pages reference errors (11:23:49) uriel: man2thml is a joke (11:23:57) mjl-: uriel: http://article.gmane.org/gmane.os.inferno.general/4100 ← that's the post (11:24:11) powerman-asdf: rog: hmm. so, if you think it's unlikely, then it's ok to ignore it? :( (11:24:35) mjl-: uriel: it works in many cases. and yes, that's not a very good excuse (11:24:43) rog: uriel: no, the real reason is that doing the documentation properly is a hell of a lot of work, and charles, for his own reasons, is unwilling to delegate system maintenance to other people... (11:25:00) uriel: mjl-: hmmm... I think I have quite a few more fixes somewhere, but given the interest in that one I hardly feelt motivated to go though the pain of collecting more (11:25:39) uriel: rog: well, then charles has been ensuring that inferno is relegated to total obscurity (11:26:01) mjl-: as for documentation (11:26:07) mjl-: when i try to write manual pagees (11:26:15) mjl-: it is quite horrible (11:26:26) mjl-: the inferno man pages are written nicely (11:26:37) eekee: they are, better than plan 9 (11:26:37) mjl-: my english is just quite lousy (11:26:59) eekee: my natural form of expression isn't any human language I think (11:27:06) mjl-: eekee: : (11:27:06) mjl-: :) (11:27:23) rog: i agree, it's really hard to write good man pages. (11:27:32) eekee: :) (11:27:49) eekee: problems, problems *sigh* :) (11:27:58) rog: but i think it's a useful kind of hardness. the kind that means that when you get there in the end, you've done something really useful. (11:28:17) uriel: not as hard as having a single person maintaining a whole operating system (+ vm that runs in a dozen operating systems) on his spare time (11:28:28) eekee: yeah...! (11:29:18) mjl-: uriel: it's annoying that patches aren't applied. especially those reference-fixing patches. they contain no rewriting... so should be relatively easy to check & apply (11:29:46) mjl-: i suspect that some patches end up in the queue "oh, i have some other changes lying around for that, and i'll push them together, later, when i am done with that" (11:30:05) uriel: later == in a couple or three years (11:30:17) eekee: I wouldn't be surprised (11:30:20) rog: uriel: it's true. the world weighs on charles' shoulders. but he's in a bind - the moment he gives out commit rights, the source code swings out of control, and you end up with endless feature creep. (11:30:42) uriel: rog: that is such total *bullshit* (11:30:44) mjl-: exactly, i don't expect him to give out commit rights (11:31:07) eekee: needs responsible people with commit rights. Determine responsible, for each applicant... (11:31:08) mjl-: but getting simple patches applied would be nice (11:31:10) rog: i'm saying it the way i think he sees it (11:31:26) uriel: rog: pretty much all open source projects have a 'benebolent dictator', and that in no way precludes delegation, it just means that somebody can veto any decision (11:31:55) uriel: (ok, not all open source projects, but most do anyway) (11:32:22) mjl-: yeah. i think it makes sense if the users (us) propose patches, and charles apply them if he likes them. which is what we do now, but i guess charles may not always have to time to look at them. that's the pity (11:32:29) rog: the problem is that there are very few people in the world (and i'm not one of them) who produce code that charles deems good enough to go into the core of inferno. (11:32:36) eekee: Torvalds didn't do delegation for a long time. He almost burned out on linux but a few got together & talked him into delegating (11:32:51) uriel: and really, opening up stuff like the documentation, or releasing the mountains of unreleased changes (like the recently discussed in some bug repport, that apparently has been bittroting for years) has *zero* implications (11:33:44) rog: mjl-: charles will never like them. he might like one idea or another in principle, but he will have his own ideas on how it should be done... so he will do it himself... sometime, or probably never. (11:33:59) eekee: hmm pride over code quality isn't any good for those that want code now (11:34:05) uriel: rog: again, I'm all for having high standards of entry, it is not about that, it is about transparency and delegating stuff that clearly he has no time/interest in taking care of (11:34:11) mjl-: rog: okay, than we have a crisis on our hands now ;) (11:34:23) eekee: ohh (11:34:57) uriel: mjl-: inferno in crisis? you mean like the state it has been in since 1998? (or probably earlier) (11:35:25) mjl-: uriel: i wasn't too serious (11:35:30) mjl-: i see it like this: it works for me (11:35:36) mjl-: that is what i care about (11:35:43) rog: eekee: those that want code now shouldn't be able to ruin the maintainability of the codebase as a result of their desires... (11:35:47) mjl-: the only reason to have others use, it that it won't die (11:36:01) eekee: rog: not even if we're the ones that want it now? :} (11:36:03) mjl-: that's my interest in getting other people use it. i don't care if it becomes highly popular (11:36:27) uriel: rog: charles current method is clearly completely counterproductive even towards his own goals, look at acme-sac and inferno-openmoko, he is basically encouraging people to fork inferno (11:36:33) mjl-: i even think that something is lost when it becomes very popular (11:36:43) rog: uriel: i agree. (11:36:48) eekee: I guess what I'm thinking is that linux has a pretty good maintainability model, even if it's not briliant it's better, but I dunno (11:36:58) rog: mjl-: i agree (11:37:06) uriel: rog: and then you end up with an acme-sac tree that is totally different, and that russian girl is well on her way to totally messing her tree (11:37:07) mjl-: eekee: i really wouldn't want inferno to look anything like linux (11:37:18) eekee: hmmmmm (11:37:19) mjl-: eekee: code-wise (11:37:24) eekee: no... (11:37:30) mjl-: with all different styles, ideas, ways of doing things (11:38:10) uriel: mjl-: I don't want inferno to be 'very popular', I want to be able to run it without it crashing randomly due to bugs in the X-drawing code, or it taking 100% of my cpu on windows (11:38:29) eekee: the thing is if you allow different styles etc you enable vastly more people to contribute (11:38:51) mjl-: uriel: true, but you can fix that. and if you send a patch to the inferno list, there will be a good chance it will be applied (11:39:04) mjl-: i'm still seeing x11-related crashes on openbsd (11:39:05) rog: the thing about inferno is that everybody seems to focus on the trivial things that are "obviously wrong" like uriel's man page typos. but the main things that really need doing are deeper and harder problems. and nobody knows how to do them properly. (11:39:06) uriel: mjl-: that 'I don't want inferno/plan9 to look like linux' is a red herring, nobody (nobody that has a clue about the subject anyway) wants that (11:39:31) uriel: mjl-: so lets stop justifiying avoiding any change on a clearly broken system because we are too afraid of becoming like linux (11:39:57) rog: uriel: it's not "clearly broken". (11:40:05) uriel: rog: well, the obvious stuff is what keeps most people from being able to put up with inferno (11:40:06) mjl-: rog: what are the deeper and harder problems present right now? (11:40:29) mjl-: rog: i'm using inferno to serve http (with quite a few scgi apps), irc, and some more (11:40:53) mjl-: so it works at least quite reasonable for those things. (11:41:08) mjl-: probably depends on what you want. inferno should be shining on embedded of course... (11:41:13) eekee: how does it handle load? (11:41:18) uriel: rog: inferno is an obscure niche system nobody knows, if it is full of sharp edges people new to it will run right into, it will ensure that nobody will ever use, the cost of entry is way too high (11:41:36) rog: mjl-: in no particular order: distributed authentication, garbage collection behaviour, decent graphics. (11:41:50) rog: mjl-: and more that i can't think of currently. (11:41:57) uriel: rog: (and I'm not arguing at all for being more 'newbie friendly', I'm arguing that things that are obviously broken should be fixed so people that don't know their way around them doesn't have to get hit by them again and again) (11:42:01) rog: mjl-: oh yes, limbo. (11:42:17) rog: uriel: what things are you thinking of? (11:43:20) uriel: auth: I thought it had been mostly been solved? gc: charles said he had some new (unreleased) code that solved this? (and brucee told me at some point charles was interested in using his code) graphics: russ recent work for 9vx and p9p should solve the worst of this (11:43:24) powerman-asdf: uriel: "should be fixed" - or at least documented. (11:44:04) uriel: rog: I'm thinkinf of simple stuff, simpler packaging, man pages with broken references, crashing bugs, etc... (11:44:47) uriel: charles still refuses to release a simple .zip distribution, when the pointless installer has been shown again and again to be 1) broken 2) pointless (11:45:02) rog: uriel: auth: no. inferno really needs something like the spki stuff charles has been talking about for years. so that in a distributed system, each node doesn't need to maintain its own permission list. (11:45:38) uriel: rog: I thought inferno already had spki? wasn't that what the last gsoc was all about? about finishing that up and adding it to plan9 factotum? (11:45:40) rog: uriel: gc: i don't think so. (11:46:49) rog: uriel: graphics: how do you mean? i'm talking about spending the time to do decent graphical design. and probably allow graphics acceleration too. (11:47:57) rog: uriel: there *is* a zip distribution. http://www.vitanuova.com/dist/4e/20071003/windows.zip (11:48:39) rog: uriel: auth: no, spki has been advanced, but not finished. i'm a bit sad about that. (11:49:00) rog: uriel: pointed to from http://www.vitanuova.com/inferno/net_download4T.html (11:49:12) eekee: I got my install from various zipfiles... (11:49:55) rog: uriel: when you say "crashing bugs", have you got any examples? inferno very rarely crashes for me. (11:49:55) eekee: oh tgz (11:50:20) rog: i think the layout of that page could be better though. (11:50:20) uriel: oh well, that .zip file is news, now all that is left is for the whole vn inferno site to get dumped and moved to google code, that would help quite a bit with organizing things (11:50:48) uriel: (if only inferno-list could move there too, it would be too good to be true, and everyone knows I hate google with passion, but still it would be a huge improvement) (11:51:03) uriel: ooooo: those are not tgz (11:51:05) rog: uriel: chill out (11:51:08) uriel: er eekee (11:51:20) eekee: ah (11:51:46) rog: uriel: have you ever hung out on #haskell? (11:51:54) uriel: rog: sorry, many of this things just have been very frustrating for some of us, I know I have issues in dealing with problems, but then others seem to prefer to just pretend they don't exist, and I don't think that is much better (11:52:16) uriel: rog: no, why? I probably would get banned quite fast, like from most irc channels ;P (11:53:02) rog: uriel: well, if you listen and don't speak, you'd see that it's possible to have a constructive and friendly discussion. (11:53:18) rog: uriel: ... even when some of the issues are contentious. (11:53:55) rog: uriel: by using the language you do, you cause an instant descent into similar language of the other residents of the channel. (11:54:03) rog: uriel: it's totally unnecessary. (11:54:14) uriel: rog: I don't think any of the issues are really contentious, my communication style is a big part of the problem, the reluctance of others to communicate at all is another big problem (11:54:38) uriel: (the thought of the amd64 plan9 port makes my blood boil, can't help it) (11:55:19) rog: uriel: 1) yes, your communication style is all your problem. because if i took away your communication style, and just left the actual content, you'd have said about 3 things so far today. (11:55:51) rog: uriel: 2) but i agree the reluctance of others to communicate at all is another big problem. but you don't help that. (11:56:25) eekee: stating 3 things & convincing others of them are two different things (11:57:06) rog: even if one feels like ranting and raving (and god knows i do sometimes), actually doing so is never a useful way of advancing your cause. (11:57:58) rog: and uriel, it often feels like you're ranting and raving. (11:58:06) uriel: rog: well, it is really hard to tell if there is any way to advance my cause some times (11:58:19) uriel: I'm often obviously ranting and raving (11:58:25) rog: uriel: i understand that. (11:59:15) rog: uriel: sometimes, though, you have to just realise that shouting about it won't help. maybe there *is* no way you can change what people do by shouting at them. (11:59:35) uriel: I have my own problems, I try to do my best, even if I fail most of the time, but then maybe some times things I do are not totally counterproductive, see gsoc, or the many 9p implementations out there and so on (11:59:50) uriel: rog: I'm trying to learn to accept that (12:00:01) rog: uriel: then, the only way of making forward progress is to try to do what you're talking about. and let that speak for itself. (12:00:32) rog: uriel: i'm afraid i do think that gsoc was totally counterproductive in the end. (12:00:37) uriel: rog: if you see things like ninetimes.cat-v.org and doc.cat-v.org and gsoc, and my talks at conferences and so on, that is what I really try to do (12:00:37) eekee: that's a rather limiting way forward (12:00:55) eekee: not entirely limiting - cat-v.org (12:01:43) uriel: rog: it is also a bit hard when what one gets for all that is being repeatedly insulted and ridiculed, and not only when I do stupid things, but some times it seems that no matter what (12:02:07) eekee: I'm considering the issue myself because it's very hard for me to express myself clearly first time around & I really need to express myself in order to really grasp a sibject (12:03:15) uriel: if somebody wants to say I'm an asshole, fine, but all the snide comments start to become rather frustrating (specially combined with things like russ saying "I don't add awk to p9p so uriel has something to complain about" and so on) (12:03:59) rog: uriel: i hadn't seen ninetimes.cat-v.org. that's cool. but you have to realise that in lots of people's minds you've been shouting at them forever. if you want to change that image from destructive to constructive, you've a lot of work to do. (12:05:54) uriel: lots of peple have been shooting themselves in the foot since about for ever... (12:06:06) rog: uriel: the problem has been that every time you say something, even if you're saying something constructive, you have a go at something at the same time. that doesn't help. people can usually see that anyway (12:06:26) eekee: but lots of other people don't think those people are... it's a strange universe we live in (12:06:48) uriel: anyway, it doesn't matter, I'm just still strugling with my double personality of both knowing I shouldn't care about any of this stuff, and being upset about how badly things are mismanaged and thinking that if only things changed there would be hope.. (12:06:49) rog: uriel: if they have, they have. but it's their foot. (12:07:45) rog: uriel: i have the same issues. but i don't think that swearing about it will help. (12:07:46) uriel: well, it is our collective feet, because the world is a poorer and more ugly place because of the failure of software like plan9 and inferno (12:08:53) ***eekee sighs (12:10:01) rog: uriel: the difficulty with both plan 9 and inferno is that both are worlds apart from the usual world. that's their strength, but also their weakness, as they can't use all the usual libraries, etc. (12:10:57) uriel: rog: while that is true, they have many other issues than that, other systems that are also worlds apart from 'the usual world' have managed to be quite sucessful in at least creating a small parallel world (12:11:44) rog: uriel: i agree. but what would it take for them to "not fail" in your eyes? (12:11:54) eekee: I thought 9 & inferno were showing some success in that regard (12:12:05) uriel: anyway, I'm really tring to move from the software industry, because I can't take it anymore, when I have had to help my elder neighbours with heir mac I end up feeling ill after five minutes (12:12:06) rog: eekee: which regard? (12:12:31) uriel: rog: it would take a community around them that is engaged and keeps them alive (12:12:38) eekee: plan 9 is moderately well-known about in my distro community, up from unheard-of 4 years ago (12:12:54) rog: eekee: which distro is that? (12:12:56) uriel: rog: certain attitudes (specially the communication one) from those 'in charge' have made that totally imposible (12:13:01) eekee: inferno... well there's inferno-ds. I don't think that's going unnoticed (12:13:30) uriel: eekee: that is going totally unoticed, the project has < 10 page visits per day (12:13:41) eekee: OTOH the bugs in inferno I'm hearing about don't sound nice, & the lack of fixing... is just silly in a project that expects to survive (12:13:48) eekee: oh dear (12:14:28) rog: eekee: uriel hasn't mentioned a single actual bug in the inferno code so far, AFAICS. (12:15:14) rog: eekee: real bugs get fixed pretty quickly. the more difficult issue are feature requests. (12:15:16) eekee: rog: broken links in man pages came up. not code, but really just as important to the worth of the system (12:15:45) uriel: there you go: http://code.google.com/p/inferno-os/issues/detail?id=36 the reason I don't even bother to touch inferno (12:15:46) eekee: ah you're looking at it that way. well I want a way forward there (12:16:08) eekee: uriel: not seen that bug (12:17:08) rog: uriel: it's always difficult when you don't give a reliable method of reproducing the problem. (12:17:30) rog: uriel: i've been using emu on linux for ages, and i've never seen that issue. (12:17:52) uriel: rog: well, lucky you (12:18:11) uriel: I get the problem after less than 10min of usage (12:18:53) eekee: I'm not gettign it now. distro inferno in a 32-bit chroot I hardly bother maintaining within a 64-bit linux system with 64-bit x server *shrug* could be an X server bug for all I know (12:19:12) eekee: some bugs won't get fixed. :( This is the way of the universe (12:20:06) uriel: that is fine, it just means I can't run inferno, and there is very little inferno is useful for at the moment (12:20:24) eekee: what linux distro are you using? (12:21:06) eekee: and when did you last update? :) (12:21:11) rog: uriel: since you seem to be the only person that can reliably reproduce this bug, why don't you take the time to try and narrow down the cause? (12:21:45) uriel: rog: I'm not the only person, there has been others that have the same problem (12:22:06) uriel: and I spent a couple of days trying to reproduce it in a more consistent fashion (12:22:13) rog: uriel: for instance, one of your posts mentioned that removing the -g and -C options made it work ok. what about trying each of those independently? (12:22:33) rog: uriel: or trying different colour specs (12:22:40) rog: uriel: etc etc. (12:23:08) rog: uriel: in the end, you have the same opporunity to fix the problem as anyone else. (12:23:17) eekee: Oh I hate methodical bug testing myself. I =invariably= lose track of what I've tested & what I haven't :) That's something I need to find a way around though (12:23:46) eekee: -C r8g8b8 works for me btw. about to try -g; never used it. hmm I could test a really big -g size (12:23:49) rog: uriel: if you came up with a post saying "here's the problem. here's a possible fix" i have no doubt the problem would be fixed. (12:24:10) rog: uriel: look at how richard miller does this kind of thing (12:25:13) eekee: I would use a personal instance of a bug tracker to track mini-changes, but it's still not easy... hmm (12:25:41) uriel: rog: if I'm going to spend time doing that, I will rather spend it ripping 9vx's graphics code and plugging it into inferno (12:26:00) uriel: of course I doubt I would get an acceptable result to anyone involved, but that would be the right solution (12:26:05) rog: uriel: it's like you're invoking "the inferno developers" to help fix your bug. but it's an open source system. if you want it fixed, it really really helps to identify the problem. (12:26:21) rog: uriel: what's special about 9vx's graphics code? (12:27:20) rog: uriel: or "different" i should probably have said. (12:28:40) uriel: rog: it actually works? (12:28:49) rog: BTW, plugging in support for a different framebuffer interface shouldn't be hard at all. (12:28:57) eekee: I got this, but no freezup yet: arena image too large: size 9744384 cursize 20875776 arenasize 24771168 maxsize 33554688 (12:29:21) uriel: 9vx's graphics have got quite a lot of testing and had many bugs that still lurk in drawterm and p9p fixed (12:29:33) uriel: (russ migrated some of those bugs from 9vx back to p9p) (12:30:08) eekee: oh hey after gettign that I can no longer resize the window (12:30:25) rog: eekee: sounds like you've got a very large screen and not enough image memory. you could try starting with '-pimage=64000000' or bigger (12:30:42) eekee: rog: I was testing for very large screen, yes (12:31:05) rog: eekee: the usual image pool has a memory limit of 32MB (that's what the message said). (12:31:20) eekee: I see (12:31:23) eekee: that worked *nod* (12:31:38) rog: eekee: personally i think there should probably be an option to allow unlimited pool size. (12:32:01) eekee: uriel: would 9vx's graphics code work on non-x86 architectures? (just checking) (12:32:16) rog: eekee: but inferno's not unusual for VM-style environments in specifying a max size (e.g. sbcl does too) (12:32:20) uriel: eekee: yea, that has nothing to do with the vx32 stuff (12:32:56) uriel: eekee: the code is mostly identical to the p9p code, and closely related to the drawterm (and somewhat less the inferno) code (12:32:58) eekee: ok cool (12:33:07) rog: i think it would be quite amusing to try to put vx32 inside inferno. (12:33:08) eekee: rog: ah ok (12:33:13) eekee: ya lol (12:33:42) eekee: vms are a craze at the mo ^^ How pany ways are there of running plan 9 under linux? (12:33:53) uriel: rog: what do you mean? (it certainly sounds sort of interesting, not sure how useful, but...) (12:34:06) rog: eekee: infinite... (VM inside VM inside ...) (12:34:14) eekee: oh dear yes.... (12:34:17) eekee: hehe (12:34:43) rog: uriel: i mean running vx32 code with syscalls that call back to inferno sys calls. (12:35:25) rog: uriel: of course, it would only work under x86. but nonetheless interesting for that. and russ has plans for getting around that restriction. (12:38:17) eekee: uriel: did you try -pimage- with that bug? (12:38:25) eekee: * -pimage= (12:39:19) uriel: eekee: I don't even have linux at hand here (12:39:29) eekee: uhm ok (12:45:27) uriel: this was the result last time I tried to help somebody setup inferno: http://code.google.com/p/inferno-os/issues/detail?id=101 (12:46:20) eekee: oh btw I need a sort of make clean for the inferno tree. On my Zaurus it's linked against a bugged version of glibc. I've upgraded glibc but it appears to be a statically-linked bit of code as gdb gives a file path which includes the old version # (13:00:45) ***eekee settles for rm -f $(file $(find * -type f ) | grep ELF | cut -d: -f1 ) (13:01:55) eekee: uriel: btw your issues sound kinda like how I've grown to feel about Linux, which in turn is the reason why I even started looking at Plan 9 & Inferno when what I really want is a desktop OS (13:02:32) eekee: I have rather a mismatch of need and ability. trying to work on the ability part,with limited results (13:05:00) KillerX [n=anant@gentoo/developer/KillerX] entered the room. (13:05:30) rog: eekee: can't you use "make clean"? :-) (13:06:10) rog: eekee: (or "make nuke" but that can be a bit extreme at the top level, 'cos it blows away the compilers and mk) (13:06:16) eekee: rog: make: *** No rule to make target `clean'. Stop. (13:06:21) rog: oops, in both cases i mean "mk"\ (13:06:29) eekee: oh woops (13:06:41) eekee: hmm, I think I have blown away mk (13:06:54) rog: maybe you haven't got it in your path? (13:07:05) eekee: rog: nono I was typing make, not mk (13:07:24) rog: so does mk work? (13:08:22) eekee: it might have if I hadn't just rm -f'd it :) (13:08:42) eekee: don' worre I cken recover (13:08:49) eekee: *ken (13:08:49) eekee: lol (13:09:39) rog: yeah, that find was a bit radical. (13:10:29) rog: you'd've been better doing something like: rm $(find . '(' -name '*.o' -o -name '*.a' ')') (13:10:52) rog: ... and rm Linux/386/bin/* (13:11:00) rog: (except mk, of course :-) (13:11:53) eekee: eh, fiddly :o) (13:13:25) rog: eekee: touch Linux/386/lib/*.a and then mk usually do the job, i think. (13:14:44) eekee: oh I'm rerunning makemk.sh (13:14:59) eekee: after changing it to use gcc -Os (16:06:38) pierre- [n=pierre@89.179.94.138] entered the room. (16:17:30) underspecified left the room (quit: ). (16:18:19) underspecified [n=eric@clair18.naist.jp] entered the room. (16:19:25) underspecified left the room (quit: Client Quit). (16:33:06) jas left the room (quit: ). (16:33:22) jas [n=jas@adsl-69-215-39-41.dsl.chcgil.ameritech.net] entered the room. (16:57:01) anothy [i=none@cpe-76-189-197-62.neo.res.rr.com] entered the room. (17:51:31) underspecified [n=eric@softbank220043052011.bbtec.net] entered the room. (20:57:32) eekee: braugh. still busted on zaurus (21:01:22) eekee: eh, gonna put a proper linux on my Z (21:09:08) acmeuser [n=acmeuser@outbound-tdsinternet2.epicsystems.com] entered the room. (21:09:28) acmeuser left the room (quit: Remote closed the connection). (21:28:13) uriel_ [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room. (21:33:13) uriel__ [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room. (21:44:39) uriel left the room (quit: Read error: 110 (Connection timed out)). (21:45:46) uriel_ left the room (quit: Read error: 110 (Connection timed out)). (21:50:26) pierre- left the room (quit: Read error: 110 (Connection timed out)). (22:16:36) KillerX left the room (quit: ). (23:01:31) uriel__ is now known as uriel (23:38:31) soul9 left the room (quit: Remote closed the connection). (23:40:26) Guest62713 [n=none@9souldier.org] entered the room. (23:40:44) Guest62713 is now known as soul9 (00:02:26) rog left the room (quit: ). (00:24:46) uriel_ [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room. (00:41:35) uriel left the room (quit: Read error: 110 (Connection timed out)). (01:18:20) powerman-asdf: I wonder is it desired behaviour: if command started by sh will do 'raise "fail:"' then sh will handle it as normal exit without errors/exceptions: $status will be empty, and things like && / and {} {} will work like command exit successfully? (01:19:23) uriel_: powerman-asdf: best ask rog when he shows up (01:19:28) uriel_: (or maybe anothy might know) (01:23:57) powerman-asdf: uriel_: Can you shed some lights on general attitude to reliability? I mean, let's imagine that "fail:" thing is *not* desired behaviour, just for example. But it is for simplicity - because it "unlikely to happens", "nobody will do this silly thing", "nothing goes really worse because of it", etc. How such things tend to be handled in Inferno world? (01:24:34) uriel_: I can't (01:24:44) powerman-asdf: in djb's world such things are simple not acceptable. without discussions. (01:24:54) powerman-asdf: :( (01:25:08) uriel_: this is plan9/inferno, discussion is not acceptable, ever (01:25:14) powerman-asdf: :) (01:25:20) uriel_: (I'm being sarcastic, in case that was not obvious) (01:26:15) powerman-asdf: I think all your sarcasm is obvious, at least for me. So you shouldn't bother about this. (01:28:31) powerman-asdf: But it very sad you can't answer this ques. Actually, it's probably only really important thing for me. (01:29:31) powerman-asdf: I remember that quote about "panic()", but it isn't applicable here. Error handling way and general attitude to reliability are different things. (01:32:35) powerman-asdf: uriel_: Of course it's always should be some balance between simplicity, reliability and features. And while I don't bother much about the last, it's very important for to me find out balance between simplicity and reliability used here. (01:32:50) powerman-asdf: If it too much about simplicity then it's worse. :( (01:33:03) powerman-asdf: I hope it isn't. (01:33:28) ooooo left the room (quit: Remote closed the connection). (01:33:37) powerman-asdf: After all, Inferno is mostly working stable enough, no matter there few bugs lurking around for a long time. (01:35:13) uriel_: powerman-asdf: let me explain my point of view again: inferno is unreliable because it is incredibly buggy, it is incredibly buggy because nobody uses it (01:35:28) powerman-asdf: anothy: Can you please take a look at my ques above (15 min ago in backlog)? (01:35:59) uriel_: if inferno had two dozens active users, reliability probably would increase over ten fold (01:38:32) powerman-asdf: uriel_: I hear you. But hope you take it too hard and real situation not so awful. At least for non-graphic apps. All I need from Inferno is reliable network services. I don't need wm/*, maybe except for debugging. (01:39:18) powerman-asdf: And even wm looks stable on standard resolutions/color depth. (01:40:04) powerman-asdf: Maybe I too romantic because of limited experience, of course. (01:41:24) uriel_: well, you are the one complaining about reliability... (01:45:40) powerman-asdf: there no software without bugs. even helloworld will fail in some environments. (01:46:01) uriel_: I'm just saying inferno is way buggier than most software (01:46:12) uriel_: but they are mostly stupid bugs and sharp edges from unfinished stuff (01:46:43) uriel_: the fundations are much more solid than most other systems because it is much simpler and elegant (and that is the only thing that has made it possible for survival so far) (01:46:57) KillerX [n=anant@gentoo/developer/KillerX] entered the room. (01:49:45) powerman-asdf: uriel_: only important things are how many bugs there (inferno probably doesn't have many - compared to, say, linux - because of it simplicity), how critical they are (this is questionable for me right now, because I afraid simplicity has take over reliability while developing inferno), and how ease to fix them (support quality, also questionable because as far as I see charles works good enough, but you think different). (01:52:17) powerman-asdf: I tend to test thoroughly everything I will use, so chances are I catch ~all bugs in my area, and chances are there will be ease workarounds or charles will fix them. I hope I'll have stable environment for my apps in this way. (01:54:10) powerman-asdf: Let's take as example that "fail:" thing. It's not a problem to avoid using this buggy (?) case. Only important thing is to be aware about it. And I hope there not so many such subtle pitfalls in Inferno to turn this into real problem. (02:06:45) powerman-asdf: Race condition I found is worse though. But I hope Charles will fix it soon. And it also can be worked around using additional sync when you aware about it. (02:08:14) uriel_: "because I afraid simplicity has take over reliability while developing inferno" (02:08:24) uriel_: that is probably the worst false dychotomy possible (02:08:50) uriel_: The cheapest, fastest, and most reliable components are those that aren't there. -- Gordon Bell (02:08:58) uriel_: The central enemy of reliability is complexity. -- Geer et al. (02:09:04) uriel_: Simplicity is prerequisite for reliability. -- Edsger W. Dijkstra (02:09:17) uriel_: ..At first I hoped that such a technically unsound project would collapse but I (02:09:17) uriel_: soon realized it was doomed to success. Almost anything in software can be (02:09:17) uriel_: implemented, sold, and even used given enough determination. There is nothing a (02:09:17) uriel_: mere scientist can say that will stand against the flood of a hundred million (02:09:17) uriel_: dollars. But there is one quality that cannot be purchased in this way -and (02:09:20) uriel_: that is reliability. The price of reliability is the pursuit of the utmost (02:09:22) uriel_: simplicity. It is a price which the very rich find most hard to pay. (02:09:25) uriel_: - C.A.R. Hoare (02:09:41) uriel_: and so on.... (02:09:49) powerman-asdf: uriel_: there *always* some balance exists (02:10:05) powerman-asdf: there no silver bullet, even so nice as simplicity (02:10:06) uriel_: ? between what? simpler == more reliable (02:10:07) uriel_: period (02:10:28) uriel_: of course simplicity is no silver bullet, because simplicity is *HARD* (02:10:58) powerman-asdf: probably there different simplicities we're talking about (02:11:03) uriel_: but saying that something is unreliable because it is too simple is absurd (02:11:52) powerman-asdf: if you ignore some corner cases in sake of simplicity then your app will be buggy on these corner cases (02:12:14) powerman-asdf: while been more reliable in general, with more usual cases, of course (02:12:52) uriel_: perhaps, but if you don't handle corner cases, then you just don't handle corner cases (02:12:55) uriel_: you are not more unreliable (02:13:04) uriel_: you simple narrow your problem space (02:13:09) uriel_: which is a good thing (02:13:16) uriel_: s/sipmle/simply (02:15:01) powerman-asdf: this isn't really good. the corner cases are rare thing only until to start ignoring them - remember Murphy's law (02:15:50) powerman-asdf: and you narrow problem space in that way *only* if it very well documented, which isn't looks like the case (02:17:06) uriel_: powerman-asdf: thing is, you can't handle all corner cases (02:17:12) uriel_: that is why you need to narrow your problem space (02:17:42) powerman-asdf: and here is one more important thing to note. if you "don't handle corner cases", then your app should just raise when it see such cases saying "I can't handle it". If it continue to work in some undefined way - I tend to consider this a very serious bug. (02:17:48) uriel_: and documentation is irrelevant to any of this stuff (02:18:03) uriel_: another thing with simple components is that they need almost no documentation (02:18:13) uriel_: that is one of the wonderful things about the original unix concept (02:18:23) uriel_: isn't like cat(1) needs much documentation (02:18:44) uriel_: it does one thing, it does it well, it is easy to understand, it is reliable (02:19:40) powerman-asdf: isn't "raise" in Limbo require much documentation? is isn't. but then why the hell there special undocumented handling of substring-based exceptions exists both in dis and sh? (02:21:07) uriel_: no clue, exceptions AFAIK is one of those things that were added later on, and I think that like many such things, they were never quite finished properly (02:21:17) powerman-asdf: oops :) (02:21:38) uriel_: (again, mostly because nobody uses the system much, and charles is too busy to fix everything 'properly') (02:22:14) powerman-asdf: afaik raise was added later on as part of limbo, but exceptions was always there in Sys (02:22:30) uriel_: but something like exceptions *adds* complexity, so you might argue that Inferno in some aspects has become way too complex, but that is another issue (actually the oposite of what you complained about) (02:22:36) uriel_: and it is still way simpler than the alternatives (02:23:01) uriel_: I'm not expert in the history of inferno, ask anothy ;P (02:24:25) powerman-asdf: djb software, to be honest, isn't complex. but it try to handle all possible corner cases... and it very robust. (02:25:08) powerman-asdf: I don't know, maybe from _your_ view djb software *is* complex. No idea. But as for me it looks simple enough. (02:26:02) uriel_: it is certainly simpler than the alternatives (02:26:19) uriel_: but then, last I checked djb didn't write a general purpose operating system (02:26:40) powerman-asdf: And if we talking by quotes, there one more: "Make everything as simple as possible, but not simpler." -- Albert Einstein. Note that "but not simpler" part, it's very important. (02:27:37) powerman-asdf: I tend to think it's somewhat related to these corner cases. :) (02:27:41) uriel_: powerman-asdf: I think Hoare and Dijkstra knew quite a bit more about software engineering and design than Einstein (02:28:24) uriel_: and people keep repeating that Einstein quote to make all kinds of points, as far as I can tell it doesn't really mean much (02:28:52) powerman-asdf: I think software engineering isn't somewhat unique in the world. There are general things and ideas, applicable to most things, if not all. (02:29:16) uriel_: sure, but again, Einsteins quote is quite meaningless (02:29:30) uriel_: I could just as well say "You should be careful, but not to careful" (02:29:35) uriel_: it means fucking nothing (02:29:59) uriel_: and everyone reads into it whatever they like (02:30:33) powerman-asdf: Not really. I think it's about some balance needed in anything. (02:31:03) uriel [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room. (02:34:24) powerman-asdf: uriel: Ok, let's take ease example. Let's take /appl/cmd/cat.b. What can be simpler, yeah? :) (02:35:34) powerman-asdf: There we see, it doesn't try to handle the case when it unable to write exactly n bytes. Without any tries to handle this error gracefully, check is it was partial write, loop to write last part, etc. (02:35:48) powerman-asdf: It just raise. And that's for good, if you ask me. (02:36:44) powerman-asdf: But it also do check for errors when try to open files. And raise too. And that's good too, if you ask me. But these checking for errors may be removed, for simplicity. And that's will be bad. If you ask me. (02:37:10) powerman-asdf: So. It simple, but no simpler. (02:37:27) powerman-asdf: That's my understanding of Einsteins quote. (02:40:30) uriel: maybe (02:41:08) uriel: anyway, when I run cat(1) I certainly don't care much about errors, as long as the exit code is either '' or an error string, that is enough for me (02:41:44) uriel: and if you want complains about reliability, fill bug repports, or submit patches... (02:41:51) uriel: arguing about it in irc wont do much (02:42:01) uriel: (specially with a clueless moron like me) (02:42:54) powerman-asdf: Another example, if it will compare sys->write() result not to n, but to -1, and raise only if it -1 - this is also bad, because "corner case: partial write" will not be handled in defined way. While in cat(1) there no difference between checking != n and checking == -1 from simplicity view, in some other apps first, more (only!) correct way may be more complex. And I can't agree second, simpler way should be used here in sake for simplicity... (02:43:59) uriel: ? (02:44:27) uriel: really, cat either succeeds or fails, if it can't write everything it fails, if write() fails, it fails (02:45:01) uriel: I don't quite see what mudding the error paths would give you (02:46:41) powerman-asdf: I mean, write() can give three results: -1 (error), n (ok), some other value (unlikely corner case like partial write or bug in Sys or whatever). And I'd like to see handling for all possible return values, instead of handling only first two and ignoring last for implementation simplicity. (02:47:46) uriel_ left the room (quit: Read error: 110 (Connection timed out)). (02:48:28) powerman-asdf: cat handle everything, and it's good. but it doesn't increase complexity of cat. in some other app it handling all, even corner, cases _may_ increase complexity. (02:49:28) powerman-asdf: and I prefer such sort of complexity there instead of blind simplicity in hope corner cases will never happens (02:50:21) powerman-asdf: that's what I mean when sad "because I afraid simplicity has take over reliability while developing inferno" (02:51:50) powerman-asdf: Just look at these quotes: "The central enemy of reliability is complexity. -- Geer et al.", "Simplicity is prerequisite for reliability. -- Edsger W. Dijkstra". They talk about reliability, and simplicity here is just a way to get reliability. (02:52:41) powerman-asdf: So, simplicity *should not* take over reliability. It isn't simplicity an end goal, it's reliability. (02:55:42) powerman-asdf: From that view, if application do raise, then it mean it failed. No matter which string exactly it raises. And if sh have && / and {} {} features, then they shouldn't execute second part if first one failed. Even if it failed with "fail:" exception! But probably implementation simplicity of sh take over sh reliability here... (02:59:10) powerman-asdf: uriel: when I asked you above about general attitude to such issues in community, I asked is such sort of issues tend to be ignored as "unlikely corner cases, we don't wanna increase complexity of sh just to handle them" or tend to be fixed asap because "it's awful reliability issue :)". (03:09:26) uriel: first, there is no 'community', ok? (03:10:12) uriel: even charles will have a different way to make such judgements than, for example rob (03:10:33) uriel: the only person I blindly trust to get stuff 100% right is ken (03:11:22) uriel: (and even he has made some obvious mistakes over the years, unix's suid bit is a good example of this, but he has been good at recognizing and fixing them, and his code is of the best quality I know) (03:11:53) uriel: the old kenfs file server is probably one of the most reliable pieces of software ever created (03:12:42) uriel: ken's compilers are also probably some of the most reliable, and I have never seen them produce broken code, their error messages might be simplistic, but at least they are straightforward (03:13:24) powerman-asdf: you live in this community a lot of years, so I expect you've some feeling about this (03:13:25) uriel: from there, everything else is a gradient, sam for example is quite reliable, but still has some lurking bugs here and there, acme is much more complex, and has many more quirks (03:13:36) uriel: *there is no fucking community* damn it (03:13:48) powerman-asdf: ohh ok (03:13:56) powerman-asdf: no community (03:14:00) powerman-asdf: but there people (03:14:02) uriel: everyone is totally antisocial and pseudo-autistic (03:14:13) uriel: (everyone in their own peculiar way) (03:14:31) uriel: so, no community, no agreement, no nothing (03:14:55) powerman-asdf: they work with it, they develop it... even if they doesn't as responsive as you would except from "community" (03:15:06) uriel: who? (03:15:50) uriel: anyway, this discussion is pointless and completely unproductive, as I said, if you have issues, bring them up to charles, as he is the benebolent dictator in charge and the only one that can do something unless you want to write the patches yourself (03:15:53) powerman-asdf: you. charles. mjl-. olegfink. rog. I think many others who doesn't spend their time here. (03:16:07) powerman-asdf: ok (03:16:21) powerman-asdf: I already in process of filing this bug report. (03:16:50) powerman-asdf: thanks for you time, anyway. I just tried to avoid bothering clarles with silly things. (03:17:06) uriel: hah, many others? as rog pointed out, charles is the only one working on inferno, in his spare time, and unless things change it is unlikely that more people will get involved (03:17:42) uriel: if you want to change things, fine, go ahead and try something, I will shout encouragement, but just going round and round in phylosophical circles is a waste of time (03:18:15) powerman-asdf: if inferno turned out to be reliable enough for *me*, then I'll do all I can to involve more people in using it (03:18:57) powerman-asdf: if not - heh, then I try to learn as much as possible from inferno to come back to my perl, using all new ideas I got from inferno in my everyday work (03:31:51) powerman-asdf: uriel: "hah, many others?" - I've roughly counted people to send bugreports to google code - there about 30 different people. probably much more silently playing with it (03:33:28) powerman-asdf: anyway, it looks like you already have "few dozens" users which you asked about above (03:48:31) ooooo [i=none@201.80.219.33] entered the room. (05:16:01) uriel_ [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room. (05:32:45) uriel left the room (quit: Read error: 110 (Connection timed out)). (05:41:37) underspecified left the room (quit: ). (06:15:16) KillerX left the room (quit: Read error: 101 (Network is unreachable)). (06:16:33) KillerX [n=anant@gentoo/developer/KillerX] entered the room. (06:26:19) KillerX left the room (quit: Read error: 113 (No route to host)). (06:33:17) underspecified [n=eric@clair18.naist.jp] entered the room. (07:01:49) eno [n=eno@nslu2-linux/eno] entered the room. (07:18:37) KillerX [n=anant@gentoo/developer/KillerX] entered the room. (07:39:06) pierre- [n=pierre@93-81-43-182.broadband.corbina.ru] entered the room. (08:04:46) megaboz left the room (quit: Read error: 110 (Connection timed out)). (08:05:06) ooooo left the room (quit: Read error: 110 (Connection timed out)). (08:57:39) pierre- left the room (quit: Read error: 110 (Connection timed out)). (09:35:50) soul9 left the room (quit: Remote closed the connection). (09:36:58) Guest6361 [n=none@9souldier.org] entered the room. (09:38:26) Guest6361 is now known as soul9 (09:39:28) soul9 left the room (quit: Remote closed the connection).