Re: [9fans] how about intel D510MO
On Thu, Apr 1, 2010 at 3:13 AM, Alex zhao...@gmail.com wrote: Hi everyone, I've been playing plan9 in qemu for sometime now. the only computer I have is a PS3/ubuntu9.04, and I'm thinking about buy a low cost x86 board for plan9. Is intel D510MO a good choise? I can't comment on how this motherboard runs Plan 9 but I'm using it as a headless Linux server to run venti and do Go programming. I put it into a mini-box.com M350 enclosure w/ their 80W picoPSU-80 power supply (selling in a kit for $69). Add some RAM and a hard drive and you have a very compact, reasonably powerful system. Since the board is passively cooled w/ a heat sink and the PSU plugs right into the board, the only noise comes from the HD. Most sites rate the idle power draw at ~20 watts. Overall I'm very pleased w/ it. I should note though that the case does get warm above the heat sink. However since the Atom doesn't support ECC RAM (for that matter neither does the mighty Core i7) I'm somewhat cautious about trusting it as an always on file server without additional checksums in software. Pretty much all AMD chips support ECC RAM, although of course mobo/BIOS support is a different matter. John
Re: [9fans] Are we ready for DNSSEC ?
By the end of May, all the root servers should be running DNSSEC http://royal.pingdom.com/2010/01/19/the-internet-is-about-to-get-a-lot-safer/ Is Plan9 ready for such a move? Reading what D. J. Bernstein has to say about DNSSEC is always fun. See e.g. this paper http://cr.yp.to/talks/2009.08.10/slides.pdf about abusing DNSSEC to launch denial of service attacks. He has also proposed an alternative to DNSSEC, http://dnscurve.org/.
Re: [9fans] MIPS LSB compiler
On Thu, Nov 12, 2009 at 9:12 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Thu, Nov 12, 2009 at 8:34 PM, lu...@proxima.alt.za wrote: Go has added a cat amongst the pigeons :-) ... * A ducktyping of sorts with interfaces and such. On the surface it just saves you a bunch of extends XXX, but it actually seems to bridge the gap between dynamically typed world and a statically typed one to an extent As a long-time Python programmer, Go's interfaces are what I find most immediately appealing as they give you the speed and safety of a compiler w/ the flexibility of swapping in arbitrary types provided they satisfy the interface. It's trivially easy compared to C++ (inheriting from a common base class--hah, try doing that w/ std::fstream) or Java (explicitly implementing an interface). This is such a common idiom in dynamic languages that it's second nature to talk about file like objects. And goroutines w/ channels is just icing on the cake. Although you take a slight hit vs C or C++ in terms of single threaded performance, as soon as you're on multi-core, and who isn't nowadays, Go wins. I see Go pushing C usage down even further to the embedded/kernel/bootstrap space and rapidly displacing C++ as the language of choice for developing new high performance systems--already its out of the box library is much richer than what C++ gives you, especially for network programming where standard C++ is mute. Go overlaps w/ a lot of what I've used Python for in systems and network programming. Python is very nice when it works but if you have to escape out to C for speed it quickly becomes a drag. SWIG helps but machine generated code is not fun to debug. And I can't be the first person to wonder when the Go ARM compiler will be available on Android... Interesting times indeed. John
Re: [9fans] FAWN: Fast array of wimpy nodes (was: Plan 9 - the next 20 years)
could you explain how raid 5 relates to sata vs sas? i can't see now it's anything but a non-sequitor. Here is the motivating real-world business case: You are in the movie post-production business and need 50 TB of online storage at as low a price as possible with good performance and reliability. 7200 rpm SATA (currently ~15¢/GB on Newegg) plus RAID narrows the performance and reliability of benefits of 15k rpm SAS (currently ~$1/GB) at a much lower cost.
[9fans] FAWN: Fast array of wimpy nodes (was: Plan 9 - the next 20 years)
I certainly can't think ahead 20 years but I think it's safe to say that the next 5 (at least doing HPC and large-scale web type stuff) will increasingly look like this: http://www.technologyreview.com/computing/22504/?a=f, which talks about building a cluster from AMD Geode (!) nodes w/ compact flash storage. Sure it's not super-fast, but it's very efficient per watt. If you had more cash you might substitute HE Opterons and SSD's but the principle is the same. The general trend is that capital expenditures for computing are going down but operating expenditures are going up. Indeed if you sign up for something like Amazon's EC2 service, your initial capital outlay is exactly $0. (I vividly recall paying over $3000 for a low-end server and $300/month in colo fees back in early 2003 when I had a hosting business.) Apparently they use the above cluster to implement some type of distributed memcached style cache. Here is the page listing the many clients for memcached: http://code.google.com/p/memcached/wiki/Clients. However, if w/ Plan 9 you implement the interface to the cache as a 9p service, it is automatically available to any language that can do file I/O (heck, even Haskell, if you can slog through the advanced type theory). So your software development costs go down. Another change that levels the playing field in Plan 9's favor is the clock-speed wall and the move to multi-core chips. Soon everyone is going to have to re-write their software to make it concurrent if they want to make it run faster. And concurrency is hard, especially when the predominant model is preemptive threads. Here again Plan 9's technical advantages of its lightweight kernel and CSP threading model confers an economic advantage. I think the key to successfully being able to use Plan 9 commercially is to use its unique technical advantages to exploit disruptive economic changes. Economics beats technology every time (e.g., x86/amd64 vs. MIPS/Itanium, Ethernet vs. Infiniband, SATA vs. SCSI) so don't try to fight it. John
Re: [9fans] FAWN: Fast array of wimpy nodes (was: Plan 9 - the next 20 years)
Economics beats technology every time (e.g., x86/amd64 vs. MIPS/Itanium, Ethernet vs. Infiniband, SATA vs. SCSI) so don't try to fight it. if those examples prove your point, i'm not sure i agree. having just completed a combined-mode sata/sas driver, scsi vs ata is is fresh on my mind. i'll use it as an example. To clarify, I meant that given X vs. Y, the cost benefits of X eventually overwhelm the initial technical benefits of Y. With SATA vs. SCSI in particular, I wasn't so much thinking of command sets or physical connections but of providing cluster scale storage (i.e., 10's or 100's of TB) where it's fast enough and reliable enough but much cheaper to use commodity 7200 rpm SATA drives in RAID 5 than server grade 10k or 15k rpm SCSI or SAS drives. John
Re: [9fans] security questions
Robert Raschke wrote: Also note there's a new book out that includes Inferno as a major example, essentially explaining OS principles in general, in Inferno, and in Linux: Principles of Operating Systems: Design and Applications by Brian Stuart ( http://www.amazon.co.uk/exec/obidos/ASIN/1418837695 ) I've only just started reading it, so can't really comment on how good it is yet. Looks promising so far though. I recently bought this book and have read most of it. It's especially good at bridging the gap between OS theory and the gritty details of implementation with clear explanations of selected source code extracts from the Inferno and Linux kernels. The chapter on Inferno process management and its scheduler is especially illuminating. Although it focuses on the implementation of Inferno I've also found it helpful for understanding the Plan 9 kernel since it covers the Inferno device driver model, viz. embedded 9p/Styx servers. It also reviews the Inferno implementation of kfs, which is written in Limbo, but the mental translation to C is easy. John
Re: [9fans] Plan9 - the next 20 years
Steve Simon wrote: I cannot find the reference (sorry), but I read an interview with Ken (Thompson) a while ago. He was asked what he would change if he where working on plan9 now, and his reply was somthing like I would add support for cloud computing. Perhaps you were thinking of his Ask a Google engineer answers at http://moderator.appspot.com/#15/e=c9t=2d, specifically the question If you could redesign Plan 9 now (and expect similar uptake to UNIX), what would you do differently?
Re: [9fans] python csp
coming up: another port of the 9 code. maybe i'm hidebound, but i hate to do concurrent programming without channels! How about using queues (http://docs.python.org/library/queue.html)? I've used them many times for inter-thread communication. John
Re: [9fans] python csp
How about using queues (http://docs.python.org/library/queue.html)? no alt. Couldn't you implement it approximately using http://docs.python.org/library/queue.html#Queue.Queue.qsize?
Re: [9fans] C Programming in Plan 9 from Bell Labs
On Sat, Mar 7, 2009 at 7:01 PM, Pietro Gagliardi pietr...@mac.com wrote: http://plan9.bell-labs.com/sources/contrib/pietro/programming.pdf I uploaded a slightly updated version to /n/sources/contrib/pietro/programming.ms and updated the PDF likewise. When I get more time I will further expand the tutorial. Overall nicely done so far. I find it useful for getting a feel for how the Plan 9 programming environment is different from the more conventional Unix one.
Re: [9fans] threads vs forks
On Tue, Mar 3, 2009 at 3:52 AM, hugo rivera uai...@gmail.com wrote: I have to launch many tasks running in parallel (~5000) in a cluster running linux. Each of the task performs some astronomical calculations and I am not pretty sure if using fork is the best answer here. First of all, all the programming is done in python and c... Take a look at the multiprocessing package (http://docs.python.org/library/multiprocessing.html), newly introduced with Python 2.6 and 3.0: multiprocessing is a package that supports spawning processes using an API similar to the threading module. The multiprocessing package offers both local and remote concurrency, effectively side-stepping the Global Interpreter Lock by using subprocesses instead of threads. It should be a quick and easy way to set up a cluster-wide job processing system (provided all your jobs are driven by Python). It also looks like it's been (partially?) back-ported to Python 2.4 and 2.5: http://pypi.python.org/pypi/processing. John
Re: [9fans] threads vs forks
On Tue, Mar 3, 2009 at 4:54 PM, erik quanstrom quans...@quanstro.net wrote: I should have qualified. I mean *massive* parallelization when applied to average use cases. I don't think it's totally unusable (I complain about synchronous I/O on my phone every day), but it's being pushed as a panacea, and that is what I think is wrong. Don Knuth holds this opinion, but I think he's mostly alone on that, unfortunately. it's interesting that parallel wasn't cool when chips were getting noticably faster rapidly. perhaps the focus on parallelization is a sign there aren't any other ideas. That seems to be what Knuth thinks. Excerpt from a 2008 interview w/ InformIT: InformIT: Vendors of multicore processors have expressed frustration at the difficulty of moving developers to this model. As a former professor, what thoughts do you have on this transition and how to make it happen? Is it a question of proper tools, such as better native support for concurrency in languages, or of execution frameworks? Or are there other solutions? Knuth: I don’t want to duck your question entirely. I might as well flame a bit about my personal unhappiness with the current trend toward multicore architecture. To me, it looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks! I won’t be surprised at all if the whole multithreading idea turns out to be a flop, worse than the Itanium approach that was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write. Full interview is at http://www.informit.com/articles/article.aspx?p=1193856.
Re: [9fans] threads vs forks
I believe GIL is as present in Python nowadays as ever. On a related note: does anybody know any sane interpreted languages with a decent threading model to go along? Stackless python is the only thing that I'm familiar with in that department. Check out Lua's coroutines: http://www.lua.org/manual/5.1/manual.html#2.11 Here's an implementation of the sieve of Eratosthenes using Lua coroutines similar to the Limbo one: http://www.lua.org/cgi-bin/demo?sieve
[9fans] Visual font viewer
Is there a program that will render some subset of a font file so that you get a quick feel for what it looks like? John
Re: [9fans] source browsing via http is back
I've turned it back on and will watch to see if our web server gets swamped by it. This interface should not be used to mirror the contents of sources. What interface should be used to used to mirror sources? 9fs? replica? More specifically, if I wanted to set up my own HTTP mirror of sources, what is the labs approved way to stay in sync?
Re: [9fans] Pegasus 2.6 is released
You're missing the beauty of 9p. Who needs dynload() when you have mount()? Mount allows me to add new names to the process namespace. Dynload allows me to call functions or access data in a library that is not known to the process (e.g., scripting language interpreter) until runtime. They solve different problems. John
Re: [9fans] Pegasus 2.6 is released
Kenji Arisawa wrote: Pegasus 2.6 is released with new WebDAV script written in Lua. Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more details. Do you have a non-local URL host name?
Re: [9fans] Pegasus 2.6 is released
Pegasus 2.6 is released with new WebDAV script written in Lua. Interesting that you used Lua. I think it's generally under-appreciated but IMO is very well designed and philosophically a good fit for Plan 9. However, inasmuch as you had to build a custom interpreter to add features for Pegasus this exposes a weakness of Plan 9 in that it can't dynamically load libraries at run-time which is the normal extension mechanism for scripting languages on other platforms. Can someone comment on how feasible it would be to add general support for dynamically loading libraries to Plan 9? Is there some structural reason why it can't be done or is it just that nobody has done the work yet? Note that I am specifically not asking about shared libraries... John
Re: [9fans] Pegasus 2.6 is released
the argument that if the normal extension mechanism for scripting languages is x, thereforenot having x is a weakness seems a version of argumentum ad populum. doesn't dynamic loading seem at odds with the tools approach? the more complex the interface, the less general the tool. Dynamic loading allows scripting languages to load arbitrary binary extensions at run-time. Without dynamic loading in Plan 9 you need to recompile the Lua (or Python) interpreters to statically link in your binary extensions, so in this case dynamic loading makes the tool more general. (FWIW, as has been pointed out on this list previously, Inferno applications can dynamically load modules at run-time.) John
Re: [9fans] What about Haskell? [was: How can I use alef?]
I've often though quite a few languages could be shrunken down fit with Plan9's diretory/files system. Python, for instance, would need much less code for networking etc. So a language that specialsed in I/O primitives would be a good choice. That doesn't sound like Haskell to me. I/O is about changing state. That said, there must be a way to make it fit :) Of the few I have used, I think python is the best hybrid that fits. Lua (http://www.lua.org/) is also a good choice as its standard library is so minimalist that porting it is trivial. IIRC there is an APE port somewhere in contrib. John
Re: [9fans] those funny gnu guys
On Fri, Nov 14, 2008 at 10:34 AM, erik quanstrom [EMAIL PROTECTED] wrote: this is just stupifying: http://tech.slashdot.org/comments.pl?sid=1029797cid=25761431 I see that this comment has been voted +4 informative. Truly a shining example of the web 2.0 wisdom of crowds at work! John
Re: [9fans] Minimalist cpu hardware (was: 9grid)
On Wed, Nov 12, 2008 at 2:46 AM, Steve Simon [EMAIL PROTECTED] wrote: An Intel Atom D945GCLF mini ITX was reccomended to me, I believe it is all supported by plan9 and draws very little power. I was going to use one to replace a large noise server I have at home. Nice, but I'm envisioning something w/ more horsepower, in the core 2 or athlon 64 x2 class, but in a comparably sized form-factor. John
[9fans] Minimalist cpu hardware (was: 9grid)
I've been wondering about the minimal h/w you'd need for a cpu server and whether it exists in a compact blade-like form. Conceivably all a plan 9 cpu server needs is cpu, ram, pxe ethernet and all the gunk necessary to get it to boot, i.e., no video, no i/o ports, no disk controllers etc. that otherwise just burn power. I'm imagining something small enough that four blades could fit into a standard size tower chassis that you could stick under your desk and not worry about it electrocuting your kids (although fan noise might be an issue). The likes of rackable just seem to sell full-blown servers in a blade form-factor, for a premium. Given that you can buy a motherboard w/ all the bells and whistles, 4 gb of ram and a nice multi-core 64-bit cpu for $300, the raw material for such a board in theory should cost less. I think the mainstream market is there in applications like image processing or rendering animations--although presumably not so much in the finance sector nowadays--where the data lives on dedicated file servers. If the price was low enough it could even be attractive to hobbyists running pov-ray or what not. But if such a thing existed it would also be the basis for a nice plan 9 cpu cluster. Any recommendations? John
Re: [9fans] Do we have a catalog of 9P servers?
It seems that MS is pushing webdav hard. that's what's needed when heavy things run out of fuel. Even as a potential substitute for ftp webdav is a farce. Speaking from personal experience, the amount of XML you need to generate for a directory listing is at least 20 times the size of the equivalent ftp listing, and then you twiddle your thumbs waiting for the webdav client to parse and render it. And don't get me started on vista... My wife's new dell laptop uses up 800 MB of ram doing who knows what after it boots and two times out of three fails to go to sleep w/ the fan whirling like a banshee. At times I wonder if I shouldn't have paid the $700 premium for the macbook. Sorry for the OT rant...
[9fans] Porting Plan 9 to the TI Beagle Board
In the recent NeXT thread Eric mentioned the TI Beagle Board (http://beagleboard.org/). It's quite neat: $150 for a 3 x 3 PCB w/ a 600 MHz ARM core, HD capable video, and SD card, audio, serial, USB and DVI ports. The documentation seems fairly complete, although according the mailing list there are issues about how much of the video and DSP interfaces will be documented. Hardware-wise it seems it only needs Ethernet to make it capable of being a Plan 9 terminal, although in theory that can be added via USB. How much would be involved in porting Plan 9 to it? Would the current Plan 9 ARM compiler be up to the task? John
Re: [9fans] A new language for Plan 9
On Thu, May 1, 2008 at 9:54 PM, ron minnich [EMAIL PROTECTED] wrote: On Thu, May 1, 2008 at 9:41 PM, John Barham [EMAIL PROTECTED] wrote: I first saw it in a language in 1978 called Offal, by Aron Insinga. Well with a name like Offal at least he wasn't setting expectations too high... Just about as high as Python went, it turns out :-) Touché. At least it wasn't called Parrot or it might have been dead from the start. John
Re: [9fans] A new language for Plan 9
Pietro Gagliardi wrote: The compiler generates Assembly in a temporary file, then calls up the assembler to make the program. That sounds somewhat similar to Dan Bernstein's qhasm (http://cr.yp.to/qhasm.html) which is a semi-portable assembly language combining C-like syntax w/ direct access to registers. Anathema to the Plan 9 philosophy I suppose but given that clock speeds seem to have hit a wall it's one way to wring out more speed. To be fair he seems to intend it to be used only for number crunching inner loops rather than as a general purpose language. John
