Re: [9fans] RFS alternatives (Was: Living with Plan 9)
Thanks for the info, but the devices encumbered with ioctls are the tricky ones and even if they can be sorted out I'm sure there are some other traps out there. Too bad there are no RFS gurus lurking here to offer their wisdom on remoting devices. I'm no RFS guru, thank deity, but I did RTFC once and F was apposite. ioctl was handled by having the client know exactly what each ioctl looked like, i.e. it only worked for known cases. There was a humungous switch which knew the right stuff to copy inout, how to byte swap and align any words, structs etc. After deciding what the right stuff was, it copied in the right stuff from user space, passed over the call to the server, the server then executed it and passed back the right stuff to the client, the client then copied out the right stuff, then I started losing the will to live. Dave.
Re: [9fans] permissions
Oh, you can get them in the UK ...APC's stuff is telnet-able and very nice, but how many limbs can you afford?e.g. http://uk.insight.com/p/APCUA03N1K/apc-switched-rack-pdu-power-distribution-strip.html£306.99 ex VAT.HTH,Dave.On 18 Oct, 2010,at 10:05 AM, Steve Simon st...@quintile.net wrote: we use power switches in testing, in case we really wedge machines. Oh, is this a telnet capable mains switch? Is tehre a UK version, I have wanted such a thing for ages. -Steve
Re: [9fans] dtrace for plan 9
Would this answer your question: http://blogs.sun.com/jonh/entry/the_dtrace_deadman_mechanism Well, it answers the question What is the DTrace so-called deadman mechanism? I think. That's a sort of part of a possible solution, which is OK. To be pedantic, it's not a true deadman mechanism, which operates at the point of failure (incapacity of the driver), not when it's all over (death of the passengers). What's described there is more like a pair of buffers at the end of the crowded terminus station. Or are you literally trying to figure out the upper bound on the # of virtual instructions in a single probe? Well, more importantly, the consequent real-time involved. IOW: assuming you have some common sense (and a degree of chutzpah, given the complexity of the solaris kernel), and thus you have a reasonable idea about how long a time too long is to be holding up your kernel, how do you know whether a given D bytecode blob is gonna execute for too long or not? D
Re: [9fans] rows to cols?
Wow.
Excellent us of tools.
The smallest arbitrary-columns answer I could come up with was:
awk '{if(m NF)m=NF;for(i=1;i=NF;i++)r[NR, i]=$i}END {for(i=1;i=m;i+
+){for(j=1;j=NR;j++)printf %s , r[j,i];print }}' t
I'm sure there's an insane sed solution out there somewhere for very
small numbers of rows and columns.
D
On 13 Nov 2009, at 08:44, Richard Miller wrote:
Is there an easy way to transpose the text so that rows become
columns, and vice versa? Delimiter is space.
If you know in advance the number of rows colums, it's easy:
term% cat t
one two three four
five six seven eight
nine ten eleven twelve
term% tr -s ' ' '\xA' t | pr -t -3 -l4 | tr -s ' ' ' '
one five nine
two six ten
three seven eleven
four eight twelve
Re: [9fans] dtrace for plan 9
On 10 Nov 2009, at 01:00, Roman Shaposhnik wrote: What exactly do you want to know? I worked with DTrace quite extensively. What is the upper bound on the runtime of a single D bytecode sequence? Or to put it another way, what's the longest time delay that DTraceco can cause in your kernel? D
Re: [9fans] dtrace for plan 9
I don't know anything specific about DTrace, insert-obvious-and-boring-sarcastic-comment-here/ but I'm thinking a clear, consistent interface for logging and tracing kernel operations sounds like a good thing. So am I, but how does this relate to dtrace? D
Re: [9fans] dtrace for plan 9
One thing I suspect people may be forgetting in the race to emulate YA feechure of YA UNIX variant is that one of the reasons for DTrace's complexities (hierarchical namespace, in-kernel interpreter) is the complexity of the Solaris kernel. When they're trying to work out how a thread in a proc in a zone in an ldom got to spin on a lock, you *need* awk in your kernel to work out wtf is going on. (In fact, for the serious cases, to me, D feels too limited to be useful because of it's deliberate restrictions, yet too dangerous due to its possible unbounded runtime ). In reality, for many cases, something simpler does the job better: other people use DTrace to do what I would do with truss(1) and a few joined-up braincells. The latter uses less time and effort and doesn't Heisenberging your kernel nearly so much. On plan9 this is even more the case. I'd be happy to see a BPF-style filter in the kernel for filtering events before chucking them up to userland, but a language interpreter and all the associated mess, overheads and potential security holes? No thanks. D On 8 Nov 2009, at 14:19, dav...@mac.com wrote: I don't know anything specific about DTrace, insert-obvious-and-boring-sarcastic-comment-here/ but I'm thinking a clear, consistent interface for logging and tracing kernel operations sounds like a good thing. So am I, but how does this relate to dtrace? D
Re: [9fans] dtrace for plan 9
Having banged my head against D's rampant inconsistency and almost but not quite total dissimilarity to awk, I think even acid's intemperate lingo is preferable. OTOH, the idea of chucking ANY language interpreter into a kernel seems wrong too. Yes, dtrace dtrace/D provide great capabilities (trust me: I administer hairy systems and dtrace has definitely helped us), and some of the ideas are good, but the whole thing is a mess. Maybe I'm missing something, but wouldn't be slightly nicer to have something like a set of dynamic probes which queue up blobs of data up for userland code to do the hairy lifting on? Also, you don't want a debugger, you want a data analyser: awk, maybe? Dave. On 28 Oct 2009, at 02:38, Jeff Sickel wrote: Yes please. I'd hate to see the Plan 9 ideas turned into subjecting some unfortunate programmer(s) with having to write hundreds of thousands of probes instead of following the more acid based approach. dtrace has it's place. And as you've said, eye candy wins. But I still think there's a way to use acid and the linker to provide the kinds of hooks you want for debugging. -jas On Oct 27, 2009, at 9:23 PM, ron minnich wrote: One other thought on this line. The dtrace tools include a kernel module which understands the dtrace language. Maybe an alternative plan 9 approach is a kernel driver which understands acid. ron
Re: [9fans] sed question (OT)
You can do it, definitely. Caveat: I'm in bed with a virus and the brain's on impulse power so these are untested and may be highly suboptimal. Is the input guaranteed to have 2 words on each line? What are your definitions of words and blanks? I know from your snippet that there's no leading blanks and no empty lines. Assuming there are 2 words on every line, something like: h s/[A-Za-z0-9_-]+(.).*/\1/ y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/ G s/(.)\n([A-Za-z0-9_-]+).(.*)/\2\1\3/ ought to roughly work after your fragment. If = 2 words per line isn't assumed: h t urnofflag : urnofflag s/[A-Za-z0-9_-]+[^ A-Za-z0-9_-]*(.).*/\1/ t for2 b cosnot2wds : for2 y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/ G s/(.)\n([A-Za-z0-9_-]+[^ A-Za-z0-9_-]*).(.*)/\2\1\3/ b : cosnot2wds g Bizarrely, within it's limitations (\n, \0, size limits), sed is, in some sense, complete, since you can store any number of things in the spaces (using /(.* \n)/ etc.) and branch conditionally. Another insane possibility, since there are only 26 variations, is to do: s/^a/A/ s/^([A-Z][A-Za-z0-9]+[^ A-Za-z0-9_-]*)a/\1A/ s/^b/B/ s/^([A-Z][A-Za-z0-9]+[^ A-Za-z0-9_-]*)b/\1B/ You can of course, use sed to create the above script like so: echo abcdefghijklmnopqrstuvwxyz | sed ... Filling in the ellipses is left as an exercise for the already addled reader. BTW: if you're shovelling a lot of this kind of muck, it may, paradoxically, be easier to do it on the command line and use your shell's variables for the repeated bits of regexps, commands etc. The only caveats are that this technique will curdle your brain even more than sed already does and it may, oddly, be the exception to the rule that rc is more elegant than sh, due to caret vs. double-quotes. Apologies for grandstanding, but I used to do this sort of stuff for a living. I wrote a piece of training courseware for sed once which had far worse excesses than the above as examples. RFC-822 header-reassembly anyone? I also used to get my intellectual rocks off on stuff like this until I finally grew up (in my late 40s). Dave. SEE ALSO teco, assembler, qed. On 29 Oct 2009, at 15:41, Steve Simon wrote: Sorry, not really the place for such questions but... I always struggle with sed, awk is easy but sed makes my head hurt. I am trying to capitalise the first tow words on each line (I could use awk as well but I have to use sed so it seems churlish to start another process). capitalising the first word on the line is easy enough: h s/^(.).*/\1/ y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/ x s/^.(.*)/\1/ x G s/\n// Though there maye be a much easier/more elegant way to do this, but for the 2nd word it gets much harder. What I really want is sam's ability to select a letter and operate on it rather than everything being line based as sed seems to be. any neat solutions? (extra points awarded for use of the branch operator :-) -Steve
Re: [9fans] go to this site
I see that I wasted about 3 minutes of my life. On 27 Oct 2009, at 00:00, ron minnich wrote: nebula.nasa.gov and see what you see ron
Re: [9fans] So quiet!
I would suggest that we're the most eclectic. Try having a conversation with a bunch of 9fans that doesn't encompass several millennia of culture, technology etc. Also I'm fairly certain that a disproportionately large number of 9fans aren't CS grads. As with Un*x, it's the people who recognise the power and simplicity who are the fans, not the academic dogmatists and fashionistas. D On 23 Oct 2009, at 15:06, David Leimbach wrote: on the contrary... I have always equated the plan 9 crowd as the most punkrock of the alternative OS crowd. On 10/23/09, W B Hacker w...@conducive.org wrote: erik quanstrom wrote: On Thu Oct 22 22:54:41 EDT 2009, eri...@gmail.com wrote: Everyone is busy drinking and debating protocol semantics. I think we've managed to empty the coraid fridge of beer. skip, sorry about that. we drank all your beer. - erik Tsk, Tsk, ..and here some of us thought that Plan9 team were all pointy-haired ivory-tower types who drank only white wine... ;-) ..ducks and waddles offstage... Bill
Re: [9fans] bluetooth
Thanks a million for all your work on this: it means I'll probably be running plan9 seriously soon:-). To be selfish for a moment ... Presumably there's still a medium sized asteroid of pain to go through to get something like, say, my bluetooth stereo-phones+headset(A2DP/AVRCP/... ... ...) working sensibly? Oh, and we'll need more drivers which will need to be more complex and more efficient and less buggy while driving more, and more divergent hardware which is becoming ever more complex and bigger and buggier, of course. OTOH, of course, we do at least have the wonderfully clean plan9 view of all this contortionous mess, so at least when I need to push an avrcp driver onto my stack, I can manipulate and see the hideous vipers nest in userland and prod it with rc. Plus, of course, it'll be totally dandy for connecting my plan9 wristputer to my plan9 briefcase. Well done again. D On 23 Sep 2009, at 15:48, Richard Miller wrote: A very superficial glance a long time ago suggested that it was a twisty little maze of de-facto and de-vulgus standards. i.e. the death of a thousand committees. The core standard (defining the communication layers) is actually not too bad, compared to some I've had to look at. It's huge, but a lot of it is describing low-level radio stuff (below the hci layer) which your bluetooth chip takes care of. All the profiles (application layers) have their own separate standards documents, and there indeed is a morass of (non)design by committee. Then there's the hardware ... Maybe I was lucky, but my random choice of development hardware (a cheap generic usb dongle with a CSR chip) has seemed to behave just as the spec says. Of course there have been surprises, but so far these have been where the spec was ambiguous and my guess didn't match the firmware designer's guess.
Re: [9fans] bluetooth
A very superficial glance a long time ago suggested that it was a twisty little maze of de-facto and de-vulgus standards. i.e. the death of a thousand committees. Then there's the hardware ... On 22 Sep 2009, at 20:34, Skip Tavakkolian wrote: anyone looked at this or given it any thought?
Re: [9fans] sources down?
You may think it's a question of money (you mentioned it is for free). It's not. There are many projects out, totally for free, but reliable. When I do something it must be reliable, or it's worth criticizing. Firstly if sources goes down, no-one dies so it's not a big deal. Secondly, given the choice between a bit unreliable but very cool and very reliable but totally shit, I know which I will take. D
Re: [9fans] extensions of interest
Is it? It's probably a statistical certainty based on 9-fans being a fairly fixed-size group, which it does seem to be and human beings being remarkably similar in their ability to forget things. Max kudos to Russ as usual for spotting it. Let's wait another approx 4 years less 3 weeks and see what happens. On 12 Apr 2009, at 03:42, Anthony Sorace wrote: right on schedule! http://9fans.net/archive/2001/05/482 (may 31 2001) http://9fans.net/archive/2005/05/69 (may 7 2005) okay, that timing's just freaky.
Re: [9fans] a bit OT, programming style question
Exactly, and the end user can choose to have a re or glob expansion program, rather than having to muck up the shell code with different flags or whatever. somebody is going to jump in very soon and tell us why this is funny :-) i promised i wouldn't, Well someone's gotta tell these prepubescents ... Because the V6 shell did it, that's why..
Re: [9fans] mmap and shared libraries
A thought ... Shared libraries do 2 possibly useful things: 1) save space 2) stop you having to re-link when a new library is released. Now 2) doesn't really happen anyway, due to .so versioning hell, so we're left with 1) ... I know it's kind-of hacky and unstructured (how do you know the venti block size?), but could you not block-align the library members in the .a, so venti would do the sharing on disk for you? As a further step, you could also page align the text segments of the library members, then implement a venti-like scheme for read-only pages in memory, so that when the executable loads, it gets any common library pages shared. Dave. P.S. Sorry not to make Volos: where are the rest of the photos?
Re: [9fans] Questions on notes
Frankly, I was trying to see whether an external process reading on somebody else's /proc/n/note would make any sense. One thing that I wanted to implement was a note thief process that would constantly read on a target's /proc/n/note and handle the notes externally using a different kind of IPC to communicate with the target. Why? If you want the target process to receive a different kind of IPC, then why don't you send your different kind of IPC directly to the process? Would this be completely impossible to implement using /proc/n/note ? I think so, simply because you can't constantly read: you need to read, process, read, ... and while you're processing, the target process can get hit with a note.
Re: [9fans] apropos of the glendix post
This gets punted around every few months and nothing happens. I've done some basic information-gathering but got no further for the usual reasons, so, in an effort to stimulate some inertia, here's a small suggestion ... Is there anyone out there who's gonna be in Volos and wants to participate in a driver-writing BOF? DaveL On 4 Sep 2008, at 06:47, [EMAIL PROTECTED] wrote: if linux can use binary blobs, why can't plan9 do it too? I think the BLOBs are platform specific, but I may be mistaken. If I'm right, there's no way that we'd get any momentum to turn this around. But your earlier comment is extremely valid, too few people are working on drivers. Without wishing to fan Discordia's flames, it is true that the 9fans community does not seem focused on solving problems, but rather on the academic value of the ease in which problems could be solved if one followed the 9 True Ways :-) That said, how do we mobilise the community to focus on useful drivers? I suppose we start with Ron's wish list, then we explore Russ' partially complete postings (i386 emulation, Centrino drivers, I'm sure I've forgotten many more) and thirdly we post a list of willing contributors, possibly split into code writers and advisors. Any takers? ++L
[9fans] Any Brits going to iwp9? ...
... and any great travel plans to share? DaveL
Re: [9fans] sad commentary
Quote from a comedian (Rhod Gilbert. maybe?): Well... No. I've got a TV, OK? I'm not interested in watching TV on my phone for the same reason that I'm not interested in having a piss in my tumble dryer.
Re: [9fans] Plan 9 Terminal Target
Talking of cheap machines ... Does anyone know anything about the Elonex One? http://elonexone.co.uk/ It's ~USD200. I'm getting a couple anyway for other reasons, but if they could be used to do something 9ish as well, that would be a bonus. I'll start looking at running 9 on it ASAP of course, but any shoulders to stand on would be useful. DaveL Another good cause! I'm cycling 50 miles from London to Brighton to support the British Heart Foundation. http://www.justgiving.com/davelukes-brighton-bikride
Re: [9fans] when is a branch not a branch?
On 3 Jun 2008, at 00:29, ron minnich wrote: On Mon, Jun 2, 2008 at 3:50 PM, Charles Forsyth [EMAIL PROTECTED] wrote: Don't try this with 8a. 8a is too damn smart no, it's simply following instructions. i meant that as praise for 8a if that came across wrong. not at all: i meant that as a description of 8a's algorithm to eliminate branches and a damned fine joke, which only hit me later. You're not the only one, Ron. Cunning linguist. DaveL I'm jumping off the top of Guy's Hospital to support the Myasthenia Gravis Association. Please support me! http://www.justgiving.com/davelukes-abseil
Re: [9fans] LSI Logic 53C1030 SCSI
after that, there was no question that i would take all the SCSI drives for recycling. the SATA drives are much, much faster that the `fastest' of the old SCSI drives. ... and less likely to die. How old are those drives? My very vague rule of thumb is that the bathtub failure curve for most moving computer machinery rises steeply after at most about 5 years, so if they're already a few years old ... it's really not worth the time and effort trying to do a driver just to keep the SCSI drives in service. ... for the couple of years before they inevitably die. More usefully: disassemble the drive(s) and use the platters for scaring crows and art installations. DaveL I'm jumping off the top of Guy's Hospital to support the Myasthenia Gravis Association. Please support me! http://www.justgiving.com/davelukes-abseil
