Re: [9fans] Mousing is faster than typing but users not believe it
On Tuesday, June 21, 2011 10:20:27 AM Jack Johnson wrote: which is why I find it hard to get hot headed over any of the assertions, but tend toward trusting the research. What research?
Re: [9fans] Mousing is faster than typing but users not believe it
On Tuesday, June 21, 2011 11:04:28 AM Jack Johnson wrote: On Tue, Jun 21, 2011 at 9:42 AM, errno er...@cox.net wrote: On Tuesday, June 21, 2011 10:20:27 AM Jack Johnson wrote: which is why I find it hard to get hot headed over any of the assertions, but tend toward trusting the research. What research? The rabbit hole is pretty deep, but you could start with: International Journal of Human-Computer Studies http://www.sciencedirect.com/science/journal/10715819 ...and a teaser on variables: http://www.intechopen.com/source/pdfs/5711/InTech-The_effects_of_panel_loca tion_target_size_and_gender_on_efficiency_in_simple_direct_manipulation_tas ks.pdf Very cool, thankyou! Something of actual substance. I'll definitely check those out with great interest. I was hoping that when you said trusting the research, you weren't referring to the 'research' that 'Tog' vaguely alluded to in that opinion- piece article of his which was linked to earlier in this thread. Cheers
Re: [9fans] Mousing is faster than typing but users do not believe it
On Friday, June 17, 2011 12:57:37 AM Guilherme Lino wrote: oh yea a apple RD from 1989 that justifies everything Heheh, and you know it's worse even than that. Because, _what_ Apple RD? Where can I review the tests and measurements - and the parameters involved thereof - performed in this cool 50 million dollar RD? the remainder of this email is basically redundant to the above point The Apple RD which Tognazzi made vague reference to, is nowhere to be found in said article. For all anyone knows, there was no legitimate/valid/verifiable/repeatable RD done by Apple on this particular subject. 'Tog' was apparently unable or unwilling to provide any of the actual source material, or in fact in real details whatsoever concerning the specifics of the research vaguely cited in said article. In other words, how do we know for certain that users experience real amnesia! when using keyboard shortcuts, and that the mouse is objectively faster while the keyboard is merely subjectively so, and that keyboard command shortcuts take users two seconds to perform? Because that's what Bruce Tognazzini once wrote in a short article circa 1989. And what's the _actual_ supporting evidence? A few sentences from... Bruce Tognazzi! ... elaborating on his own theory, in his own forum. Do we have any further evidence? Certainly! A variety of anecdotes from a variety of various people on various forums and blogs and mailing lists supporting their various confirmation biases on the matter. I'd be willing to re-approach the subject: Mousing is faster than typing (but users do not believe it), the moment I'm able to, you know, review the actual evidence and tests used to support the claim. Until then, this whole ridiculous farce is all to reminiscent of a glib little song I was force fed as a child: The mouse is faster, yes we know; because Tognazzi tells us so. On Friday, June 17, 2011 07:26:32 AM comeauat9f...@gmail.com wrote: On Jun 17, 2011, at 5:16 AM, Noah Evans noah.ev...@gmail.com wrote: .., a bit disappointed that people seem content to rely on intuition rather than measurement to understand the problem. The assumption that something is fact or obvious I've observed is indeed often a common trap many fall into. It's all very depressing. ):
Re: [9fans] Mousing is faster than typing but users do not believe it
On Wednesday, June 15, 2011 10:46:39 PM Charles Forsyth wrote: i've just got back to reading the list to find that some people clearly have no difficulty using a keyboard! And it's certainly comforting to know that some folks really know their way around a mouse!
Re: [9fans] Mousing is faster than typing but users do not believe it
On Wednesday, June 15, 2011 09:27:49 AM Jacob Todd wrote: There's an article on the wiki containing links to related info, also. Does anyone have the actual text of this $50 million dollar research apple performed? Does anyone know the actual parameters and proficiency levels of the human subjects involved in the test? Or is is it really the case that all we have amounts to: We’ve done a cool $50 million of R D on the Apple Human Interface. We discovered, among other things, two pertinent facts: Test subjects consistently report that keyboarding is faster than mousing. The stopwatch consistently proves mousing is faster than keyboarding. and: It takes two seconds to decide upon which special-function key to press. ... from some guy (Tog) who generally summarized something about something back in 1989; the entire result of this cool $50 million, to point out at that... for _new_ users unfamiliar with the mouse and unfamiliar with the equivalent keyboard-shortcuts pertaining to an undisclosed range of specific operations... that the mouse was indeed faster? Well, shit howdy! Fathom that. For a new user. The mouse may in fact be faster. For certain operations. News flash! Our 50 bazillion dollar research has shown that tricycles are faster than bicycles. ( ... for unskilled cyclists. ) And that automatic transmissions are faster than manual. ( ... for untrained drivers. ) Crawling is quicker than running. ( ... for children who haven't learned to walk. ) Context is everything. And, I know this may be really hard to believe for you flat-earth mousers out there, who have absorbed Tog's incredibly informative articles on the important specifics of the research he cited... but I guarantee it doesn't take me _2_freaking_seconds_ to decide what keys to press; unless of course it's a brand new shortcut that I'm completely unfamiliar with. And I absolutely _promise_ that if I was somehow irrevocably burdened with: ...a... two... se...cond... de...lay... for... ev...er...y... sin...gle... key...board... co...mmand... short...cut... ... that I _most_certainly_ would prefer the mouse for all operations. Yeah... I suppose it takes 2 seconds for a nascar driver to decide what gear he should shift into, and what pedal he should press down on, every time he commands his vehicle to perform an operation. I can definitely understand and accept a certain cognitive-subjective time-perceptual-bias for mouse-vs-keyboard operations under very particular instances: such as the new-user unaccustomed to a mouse who is also learning a collection of unfamiliar keyboard shortcuts at the same time, might result in said user intuitively feeling like the keyboard shortcuts were quicker. But that's an extremely narrow band of use-case; and it certainly does not apply in any way shape or form when dealing with skilled and experienced users who, after undergoing the requisite learning-curve, have internalized to muscle-memory a library of keyboard-based operations.
Re: [9fans] Mousing is faster than typing but users do not believe it
On Wednesday, June 15, 2011 01:30:37 PM andrey mirtchovski wrote: On Wed, Jun 15, 2011 at 2:19 PM, errno er...@cox.net wrote: [words like bazillion] can you summarize what you wrote using less keystrokes? the time spent thinking your message through is certainly worth the delay in clicking send. Does anyone have the actual text of this $50 million dollar research apple performed? Does anyone know the actual parameters and proficiency levels of the human subjects involved in the test?
Re: [9fans] crazy idea - drawterm in javascript?
On Tuesday, May 17, 2011 10:31:32 AM John Floren wrote: they want to let you connect to your Plan 9 system from a web browser, because you can find a Javascript-supporting web browser anywhere (except Plan 9) these days. On Tuesday, May 17, 2011 12:00:15 AM Adrian Tritschler wrote: Serve it over http and access your CPU server from anywhere that's got a web browser. Is it really all that often when a Plan 9 user is in the precarious situation of needing to access his plan9 system from some other person's/party's pc or laptop? Is this for when you glide into a coffee shop and forget your laptop or something? Hey, Mr may I borrow your laptop's web browser for a sec... I really need to hack some code on my plan9 system. On Tuesday, May 17, 2011 12:04:02 PM Skip Tavakkolian wrote: that's not the point though; the point is to have something that runs natively in the browser. On Tuesday, May 17, 2011 10:31:32 AM John Floren wrote: Writing a drawterm replacement in Javascript is not going to downgrade Plan 9. Ok, who slipped me the Cr@zy Pills? Just a couple weeks ago, javascript and web technologies were THE DEVIL INCARNATE... but suddenly, here's something we can all get behind... javascript + html5 + browsers and other web standards are now OK[tm]? So it's cool to have the 9 running 'native' in a browser (via javascript!)... but to have the web running 'native' in Plan 9... is stark full of controversy, fear, uncertainty and doubt? On Tuesday, May 17, 2011 11:18:45 AM erik quanstrom wrote: one would then be able to write applications for non-plan 9 users in plan 9. I realize I'm being unimaginative, but I'm having a very difficult time conceiving what sort of plan 9 application could possibly be appealing to non-plan 9 users. On Tuesday, May 17, 2011 11:18:45 AM erik quanstrom wrote: it would be nice to have emulated environment that's more portable than 9vx and not tied to 32-bit x86. Well now this at least actually makes some modicum of sense to me. The web is the key.
Re: [9fans] crazy idea - drawterm in javascript?
On Tuesday, May 17, 2011 04:40:50 PM Jacob Todd wrote: Writing/porting web stuff to plan 9 will be hard. Writing something that accesses plan 9 from the web will be less hard. Correct; but also somewhat ancillary to the general areas of concern: Is it really all that often when a Plan 9 user is in the precarious situation of needing to access his plan9 system from some other person's/party's pc or laptop? Ok, who slipped me the Cr@zy Pills? Just a couple weeks ago, javascript and web technologies were THE DEVIL INCARNATE... I realize I'm being unimaginative, but I'm having a very difficult time conceiving what sort of plan 9 application could possibly be appealing to non-plan 9 users. The web is the key. Cheers
Re: [9fans] crazy idea - drawterm in javascript?
Hey David, thanks for responding. The sci-fi you write below is exactly the sort of fiction I'd find very interesting in 9 space, and corresponds rather closely to what I premised in a past thread[1]. So, I believe we're speaking the same language; but the picture you've painted seems out-of-band to the drawterm-in-browser idea presented by the OP; for instance: Instead of a traditional web server platform for web applications this could be an alternative deployment target. If we're talking in terms of alternative deployment targets, then we're talking about a controlled environment where we have control over the installed software and hardware; but the drawterm-in-javascript idea is intended for pre-deployed, 3rd-party accessibility to plan 9. Use a grid of Plan 9 machines with a native interface in JavaScript. and: The one that doesn't look like a Plan 9 application, but instead looks like a useful application? The drawterm-in-javascript-on-web-browser idea doesn't actually provide a general-consumer-friendly interface to plan 9 - it just amounts to window into the currently-existing plan 9 ui... we're still talking text + libdraw, libpanel, libcontrol, libframe, etc.. I agree that an html + css + javascript ui on Plan 9 would be a good and familiar way to get native Plan 9 applications into the hands of general users; but this drawterm-in-javascript idea does not facilitate the goal of a more accessible/familiar WIMP environment for a general consumer market; though it would be a useful tool once we finally did have a native web within plan 9 itself, because then 'we' _could_ make good on erik's: one would then be able to write applications for non-plan 9 users in plan 9. ... in a way that would actually be appealing to non-plan 9 users. [1] http://www.mail-archive.com/9fans@9fans.net/msg19990.html
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Thursday, May 05, 2011 09:35:15 PM ron minnich wrote: The reason I asked if errno had looked at webfs was that he can do the standard thing (port some C++/Python Library From Hell to Plan 9) The above described standard thing is more in line with my capabilities. Porting clang is well beyond me though, even at my most optimistic; so I've decided to dedicate time toward looking more closely into porting the netsurf libs for css, html and dom; and mozilla's spidermonkey - as they are further along than webfs/abaco (further along, meaning seemingly more active and current), and I can focus simply on a port, rather than green-field design and development from scratch. In other words, I think I can manage to eventually port small ad-hoc stuff; and then slowly bake it closer and closer to something that is more and more 9'ish. Although I think I understand that the prevailing custom here on 9fans is to scorn most software written by and for the unwashed masses - or for the general consumer industry - I'm not so convinced that a reasonable compromise can't exist to fulfill the needs of a class of user who exist a little higher up the stack than, say, low-level systems programmers working on specialist projects within industrial or academic research and development facilities. or do a much more interesting thing, which is look at stuff like abaco and webfs, and learn some lessons, and build something that is faster, better, and cheaper. It's more interesting, yes - but I fear also far, far less likely for me to pull off; no one else has managed to pull it off yet, there's no way I can. (Like I said before: I write backend business logic for web-based applications in java/groovy and perl and shell, along w/ some db and network administration etc. on linux; my skills are humble, but serviceable for what I do for a living not to give you my life story or anything... heheh) In other words, I'm fully cognizant of the fact that I do not have the necessary pre-requisite experience to build a better mouse trap. This is a research OS, not a Windows replacement. There's a reason to use it. You want a great desktop experience that is familiar, get an ipad. Aww... man. Do you not think it's possible or worthwhile to have a great(er) desktop (or consumer-oriented embedded device) experience built atop Plan 9? After a few months of reading and learning and actual hands-on experience, I've found that rio and acme and mk and 8c ,etc., are far less interesting than union directories, per-process namespaces, 9p and intrinsic, ubiquitous distributed computing - that's where I personally think the action is at. I don't care what editor or compiler someone uses; but the idea of cpu'ing from a smartphone to run heavy-weight processes (for just one example) gets the geek in me pretty excited with possibility. Or the idea of a home network where I have one cpu/auth server, one file server and a number of super cheap thin-clients providing a modern web interface and shared data for friends, guests and family. I'm tired of maintaining everyone's computers in my house on an ad-hoc basis; and I think I could deploy a higher performing, more maintainable, but overall cheaper network with Plan 9. But I can hardly expect visitors and family to run acme and abaco. Cheers
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Thursday, May 05, 2011 10:20:47 PM Skip Tavakkolian wrote: it is (or was) in fgb's contrib. he ported it over back in 2006. cpue% js js help() JavaScript-C 1.5 pre-release 6a 2004-06-09 Right on. One step closer to web domination from a plan 9 platform. (: Thankyou kindly for the heads-up.
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Thursday, May 05, 2011 09:35:15 PM ron minnich wrote: The reason I asked if errno had looked at webfs was that he can do the standard thing (port some C++/Python Library From Hell to Plan 9) The above described standard thing is more in line with my capabilities. Porting clang is well beyond me though, even at my most optimistic; so I've decided to dedicate time toward looking more closely into porting the netsurf libs for css, html and dom; and mozilla's spidermonkey - as they are further along than webfs/abaco (further along, meaning seemingly more active and current), and I can focus simply on a port, rather than green-field design and development from scratch. In other words, I think I can manage to eventually port small ad-hoc stuff; and then slowly bake it closer and closer to something that is more and more 9'ish. Although I think I understand that the prevailing custom here on 9fans is to scorn most software written by and for the unwashed masses - or for the general consumer industry - I'm not so convinced that a reasonable compromise can't exist to fulfill the needs of a class of user who exist a little higher up the stack than, say, low-level systems programmers working on specialist projects within industrial or academic research and development facilities. or do a much more interesting thing, which is look at stuff like abaco and webfs, and learn some lessons, and build something that is faster, better, and cheaper. It's more interesting, yes - but I fear also far, far less likely for me to pull off; no one else has managed to pull it off yet, there's no way I can. (Like I said before: I write backend business logic for web-based applications in java/groovy and perl and shell, along w/ some db and network administration etc. on linux; my skills are humble, but serviceable for what I do for a living not to give you my life story or anything... heheh) In other words, I'm fully cognizant of the fact that I do not have the necessary pre-requisite experience to build a better mouse trap. This is a research OS, not a Windows replacement. There's a reason to use it. You want a great desktop experience that is familiar, get an ipad. Aww... man. Do you not think it's possible or worthwhile to have a great(er) desktop (or consumer-oriented embedded device) experience built atop Plan 9? After a few months of reading and learning and actual hands-on experience, I've found that rio and acme and mk and 8c ,etc., are far less interesting than union directories, per-process namespaces, 9p and intrinsic, ubiquitous distributed computing - that's where I personally think the action is at. I don't care what editor or compiler someone uses; but the idea of cpu'ing from a smartphone to run heavy-weight processes (for just one example) gets the geek in me pretty excited with possibility. Or the idea of a home network where I have one cpu/auth server, one file server and a number of super cheap thin-clients providing a modern web interface and shared data for friends, guests and family. I'm tired of maintaining everyone's computers in my house on an ad-hoc basis; and I think I could deploy a higher performing, more maintainable, but overall cheaper network with Plan 9. But I can hardly expect visitors and family to run acme and abaco. Cheers
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Friday, May 06, 2011 12:08:08 AM ron minnich wrote: After a few months of reading and learning and actual hands-on experience, I've found that rio and acme and mk and 8c ,etc., are far less interesting than union directories, per-process namespaces, 9p and intrinsic, ubiquitous distributed computing - that's where I personally think the action is at. The I humbly submit that you may have Missed The Point. I'm sorry if I'm being obtuse - what is The Point that you're referring? I don't care what editor or compiler someone uses; but the idea of cpu'ing from a smartphone to run heavy-weight processes (for just one example) gets the geek in me pretty excited with possibility. well, maybe you haven't :-) Now I'm really confused. Speak not in riddles, friend - explain what you mean! (: Please. (:
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Friday, May 06, 2011 05:59:25 AM erik quanstrom wrote: In other words, I think I can manage to eventually port small ad-hoc stuff; and then slowly bake it closer and closer to something that is more and more 9'ish. i hope that works for you. unfortunately, i think that process will be a lot like making a pig into a supermodel by starting with the lipstick. I'm certain you're right. But it's a concrete and approachable starting place for me, that corresponds well to my _current_ level of experience and ability with plan 9. I expect that after a certain point, I would ditch it and start fresh with the new insights and wisdom gained from the initial attempt. You may disagree with such an approach, but based from what I know of my own self, it's the approach that is most likely to eventually produce some measure of something-more-than-nothing. This is a research OS, not a Windows replacement. There's a reason to use it. You want a great desktop experience that is familiar, get an ipad. snip the way i would read that is that since we value clean ideas and orthogonal design more than polish, you get a clean and malleable os, but you don't get this for free. it's not that easy to port stuff to plan 9, and it's hard to get folks interested in certain boil-the- oceans projects like building a full html 5 web browser. Acknowledged, and understood.
[9fans] freedom (was Re: Compiling 9atom kernel)
I'm aware that 9fans doesn't usually take kindly to speculative fiction, conjecture, or speculation. Please forgive me, I'm writing with honest intentions. On Friday, May 06, 2011 05:07:21 AM Lucio De Re wrote: On Thu, May 05, 2011 at 11:45:27PM -0700, errno wrote: I'm tired of maintaining everyone's computers in my house on an ad-hoc basis; and I think I could deploy a higher performing, more maintainable, but overall cheaper network with Plan 9. But I can hardly expect visitors and family to run acme and abaco. To cut a long story short, you want your cake and eat it. Unfortunately, 99% of the population prefer to eat a pre-made cake and give up the ownership part. It is hardly Plan 9's fault that those who write poor software for the wrong environment can't be evangelised; as you point out, it doesn't even make sense. But you're stuck, aren't you? As soon as, say, a browser is developed for Plan 9 (assuming that someone could afford the resources), the standards will change and the browser will need major surgery. Who's going to invest in that? Basically, the mover and shakers are precisely the people who don't want Plan 9 (or anything like it) to be a success story. They are winning. I concur, and I think this is a generally sound summary of the situation. And highly astute, with regards to your comment concerning certain movers and shakers. Plan 9 has mind-numbing potential of being a bonafide disruptive technology, if the cat ever got outta the bag. I'm convinced that the web is the key. html + css + javascript over http through ssl is able to adequately satisfy ~80% of the general public's computing needs and wants. (I pulled that 80% figure out of my ass, but I doubt I'm all too far from the mark) So, what to do? The Web: Reject it? (aka go buy a tablet ) Reproduce it? (aka have you looked at webfs? ) Reuse it? (aka port webkit) There's no possible way that I'm the only one who has envisioned some rendition of the following science-fiction: * a Plan 9-based platform targeted at the general consumer market * this platform offers html + css + javascript (aka the web) as the primary front-end ui * said platform is purchased via a turnkey hardware package: a single preconfigured plan 9 cpu/auth/file server using commodity hardware, in the $2000-$4000 price range * said unit can comfortably support ~10 simultaneous users, each using super-cheap thin-clients at ~$200 dollars per unit * the idea is the consumer purchases the cpu/auth/file server unit and one or more thin client units; this is all any typical household needs * with purchase of said unit, customer receives option to pay $19.99 a month for a hosted Plan 9 VPS - customer's household cpu/auth/file server stays synchronized with this VPS, thereby facilitating ever-present remote access to personal computing environment * said platform is easily scaleable (obviously - it's plan 9) to support larger more demanding environments - such as businesses and organizations - decouple the auth/cpu/file server and/or purchase higher-end servers (monetary values pulled out of my ass - just throwing ballpark guestimates to get the point across) I don't want google and facebook and flicker et. al. owning my data; I don't want to make intel and dell rich with their overpowered machines and processors so I can run ever-bloating os and software; I don't want to maintain a collection of various ad-hoc essentially autistic (please excuse the term) computers in my household. I want to be able to access my private, personal computing environment from anywhere with an internet connection via my portable thin client. I want to be able to easily share my data and resources within a trusted circle. I want all communications to innately and transparently run over an ssl encrypted channel at all times. A radically distributed internet where power and control is put back into the hands of individuals. I'm tired of centralized gilded cages and hierarchical client server models formed and shaped mostly for the benefit of a few monolithic companies and an ever-encroaching federal government, and the ever-insidious Intellectual Property gestapo. From where I stand, this is where Plan 9 belongs. This is what it ought to be doing, and where it ought to be going. I hope I have not offended anyone, please do not be too harsh on me if you disagree.
Re: [9fans] freedom (was Re: Compiling 9atom kernel)
On Friday, May 06, 2011 09:29:33 AM Jack Norton wrote: You've got some misplaced idealism. Yeah you're probably right. In the end though, the list will eventually say it: start hammering out some code and we'll see what you come up with. Proof in the pudding. Truth. errno wrote: From where I stand, this is where Plan 9 belongs. This is what it ought to be doing, and where it ought to be going. And that comment was particularly lame - I'm in no position to assert what plan 9 ought to be doing. Sorry for that, got carried away.
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
Quick attempt at damage control, hope it's not too late: On Friday, May 06, 2011 03:32:26 PM Comeau At9Fans wrote: [...] errno pulls this off. [...] something like FireFox working on Plan 9. Let's say that the executable is fully functional People may take it you literally mean: Firefox-on-Plan-9. nonono I tried real hard to avoid that misunderstanding. And, fully functional := css 2.1/3, ecmascript 3rd/5th (w/ dom), html 4.1/5, ssl/tls On Sunday, May 01, 2011 09:09:06 PM errno wrote: (and, forget about the browser part of the web for now - I think web _browsers_ suck worse than the web itself - I'm just concerned with the web _engine_ for now) On Sunday, May 01, 2011 06:42:12 PM errno wrote: With regards to web browsers - the over-generalized kitchen-sync applications that supply the cookie management and password storing, and bookmarks, and cert management, and home pages, and back/forward buttons and all that shtuff - a decent web engine library would facilitate any number and any manner of unique and specialized front-ends. The engine is the important part, the actual front-ends are expected to just... materialize. On Friday, April 29, 2011 09:05:39 PM errno wrote: (by web experience, I'm not talking about porting firefox and flash to Plan 9 - I'm talking about native or ported libraries for what wikipedia refers to as a web browser engine or layout engine; and by fully functional, I'm talking about something that can score at least an 80% or so on the acid2 test.)
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Friday, May 06, 2011 03:32:26 PM Comeau At9Fans wrote: How does this change things literally, conceptually and philosophically? Consider this question across the board, for instance, can Plan 9 handle it (whatever that means)? How does it change Plan 9's future? What I'm getting at is that I'm hearing things about it being a research OS, so what would it mean for a research OS to have a full fledged browser available for it? A veneer of html + css + javascript over the intrinsically distributed foundations of Plan 9, would provide the bridge for an entire class of use-cases currently out of reach: When friends and family can comfortably use it, for activities other than data-archival, then I can deploy it for uses beyond my own limited, personal learning projects. The benefit I intend to receive for this is the freedom to enjoy Plan 9 more often, while reducing linux dependency, and reducing overall costs: both in hardware requirements, and in maintenance time/effort. On Sunday, May 01, 2011 09:09:06 PM errno wrote: The idea is to remove the middle-man. On Friday, May 06, 2011 12:08:04 AM errno wrote: Do you not think it's possible or worthwhile to have a great(er) desktop (or consumer-oriented embedded device) experience built atop Plan 9? Or the idea of a home network where I have one cpu/auth server, one file server and a number of super cheap thin-clients providing a modern web interface and shared data for friends, guests and family. I'm tired of maintaining everyone's computers in my house on an ad-hoc basis; and I think I could deploy a higher performing, more maintainable, but overall cheaper network with Plan 9. But I can hardly expect visitors and family to run acme and abaco.
Re: [9fans] freedom (was Re: Compiling 9atom kernel)
On Friday, May 06, 2011 09:07:07 AM errno wrote: * said unit can comfortably support ~10 simultaneous users, each using super-cheap thin-clients at ~$200 dollars per unit Make that ~$25 dollars per unit: On Friday, May 06, 2011 03:15:46 PM Gorka Guardiola wrote: http://www.raspberrypi.org/ Well, it seems to lack ethernet/wifi; so, maybe more like ~$55. :)
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Friday, May 06, 2011 04:56:26 PM Comeau At9Fans wrote: On Fri, May 6, 2011 at 7:47 PM, errno er...@cox.net wrote: When friends and family can comfortably use it, for activities other than data-archival, then I can deploy it for uses beyond my own limited, personal learning projects. The benefit I intend to receive for this is the freedom to enjoy Plan 9 more often, while reducing linux dependency, and reducing overall costs: both in hardware requirements, and in maintenance time/effort. How and/or why do you feel it would reduce the hardware requirements of friends and family? And especially so versus linux? The same way a linux terminal server w/ linux thin-clients would reduce hardware requirements. So why not just use a linux terminal server then? Because linux lacks the inherent distributed qualities of Plan 9.
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Friday, May 06, 2011 05:12:02 PM Lyndon Nerenberg wrote: A veneer of html + css + javascript over the intrinsically distributed foundations of Plan 9, would provide the bridge for an entire class of use-cases currently out of reach: Speaking in platitudes doesn't make a case. How specifically would this tie in to 9p? How specifically does it fit into namespaces? Huh? ... the same way webfs does? 9p and namespaces is exactly what allows me to transparently access the cpu/auth/file server from my thin client from which to springboard my operating environment from any location, and how I'm able to the processor on the cpu server, and how I'm able to arrange multiple discrete environments from ad-hoc resources. That shit's intrinsic and seamless to the plan 9 experience; I don't understand how it's not immediately obvious how 9p and namespaces tie in and fit into the whole idea. Right? I hope I'm not still missing The Point, 'cuz that would be really embarrassing by this juncture. :) Show us some code fragments. Write some simple file servers to stub out this veneer you describe. In the process of doing this you will learn a lot about plan 9. And as a side effect, you will come to understand why nobody else has gone down this road. I have no disagreement. I don't mind responding as long as people are directing comments and questions at me though; should I announce that I hereby extract myself from any further discussion? I don't mind doing that either, if it means reducing annoyance levels from the list members. I don't want make a continued annoyance of myself; it's true that I've got plenty to cognate and work on. Thankyou
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Monday, May 02, 2011 03:38:53 AM Salman Aljammaz wrote: why is everyone on about native web? what does that even mean? http://diveintomark.org/archives/2011/04/15/nativity-scene (sorry, couldn't resist!) (: It occurs to me that the existence of webfs and abaco, etc. are indicators that the idea of a native web engine/library isn't entirely without merit. Either that... or the people involved in those other attempts finally realized that firefox over vnc or linuxemu, and charon over inferno, are far superior solutions in every conceivable way. (: Web sites and HTML5 run best when they run natively, on a browser optimized for the operating system on your device. A more generalized form of the above statement would not be devoid of fact.
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Sunday, May 01, 2011 04:56:40 PM blstu...@bellsouth.net wrote: Starting Goal: a modern, standards compliant web engine library for Plan 9 As others have pointed out that's pretty hard to define, Agreed, I did try to make an attempt at a modicum of a definition to work from, but it was in an earlier post: (by web experience, I'm not talking about porting firefox and flash to Plan 9 - I'm talking about native or ported libraries for what wikipedia refers to as a web browser engine or layout engine; and by fully functional, I'm talking about something that can score at least an 80% or so on the acid2 test.) web browser engine (html, css, dom ecmascript) but in the current web world, you can cover a surprisingly large fraction of sites if you have good JavaScript and CSS support. Definitely: css 2.1 (or 3), ecmascript 3rd (or 5th) w/ dom support, html 4.1 (or 5) That's the entire client side of the web. (well, ssl is pretty crucial...) Digression: --- With regards to web browsers - the over-generalized kitchen-sync applications that supply the cookie management and password storing, and bookmarks, and cert management, and home pages, and back/forward buttons and all that shtuff - a decent web engine library would facilitate any number and any manner of unique and specialized front-ends. The engine is the important part, the actual front-ends are expected to just... materialize. Interesting-ish web browsers: luakit: http://luakit.org/projects/luakit/ vimprobable: http://vimprobable.org/ Personally though, I'm tired of the web browser and would like to see more of a web shell. A web shell would look like a command shell, have zero interface or control widgets, and would consist entirely of the html canvas. Ctrl-c exits the html canvas and throws you back into the web command shell. Type a url, hit enter - the command shell is replaced with the html canvas again. No back/forward/home buttons, no menus or url bars, or search bars, etc., no config screens - just like an rc shell. --- Running Java in the browser isn't as trendy as it once was, so the big missing piece would be Flash, which of course, is the root of all evil. In my mind, for whatever little that's worth, I think flash (and java) could both be reasonably ditched entirely. Under the naive hope that the web has already moved away from embedding java, and flash is next to go (once html 5 is generally ubiquitous). Options: * write from scratch * port existing codebase There's one other possibility that I've thought about. Inferno's browser charon is more capable than it might appear. It has some degree of JavaScript support. The main thing I've noticed when trying to use it for some day-to-day browsing is that it lacks CSS and could use some work on performance. I suspect that adding CSS to charon and doing some performance work on it would be easier than either of those two options. I suspect netsurf might actually be better to work from than charon, if only because netsurf is already written c rather than limbo, and has already been ported to many platforms. Another idea, is rather than port an entire existing web engine stack (webkit) - is to just cherry pick some of the separate pieces - spidermonkey and libcss (both written in c), for instance - port them over individually then bake them into abaco or a webfs-ng or something.
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Sunday, May 01, 2011 06:44:42 PM erik quanstrom wrote: I suspect netsurf might actually be better to work from than charon, if only because netsurf is already written c rather than limbo, and has already been ported to many platforms. unless i've completely misunderstood, brian is suggesting to run charon in plan 9-hosted inferno. Ah, I believe you're right; thanks for the correction. I'll risk venturing an opinion on that approach: Running a plan 9 hosted inferno is essentially another take on the vnc or linuxemu workarounds. It won't provide the same freedoms and benefits of a native library/engine/framework.
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Sunday, May 01, 2011 07:38:43 PM erik quanstrom wrote: I'll risk venturing an opinion on that approach: Running a plan 9 hosted inferno is essentially another take on the vnc or linuxemu workarounds. It won't provide the same freedoms and benefits of a native library/engine/framework. what freedoms are those? The freedom _from_ an extra, extraneous, alien environment. [1] The freedom _for_ building a variety of native front-ends. The freedom _for_ integrating with existing native libraries. Perhaps freedoms and benefits are synonymous in this context, and thus redundant. [1] yes - I think it's strictly accurate to consider inferno as being alien and extraneous to plan 9.
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Friday, April 29, 2011 11:26:03 PM Anthony Sorace wrote: On Apr 30, 2011, at 12:05 AM, errno wrote: But APE has c++ (old version of gcc though). APE has no c++. there is a very old version of gcc floating around on sources that can, with some effort, sometimes be made to compile things. Ah, ok - thanks for the correction. And thanks for the friendly response in general, appreciated. So, shaking this out just a bit further: (anyone reading, please just ignore this if you find it too long, and/or too annoying, and/or too naive - or whatever - I'd rather hear crickets chirping than hecklers carping - thanks) Starting Goal: a modern, standards compliant web engine library for Plan 9 Options: * write from scratch * port existing codebase Option Considerations: * writing from scratch is simply too momentous a task: because it's a huge amount of work. there's a whole pile of standards and pseudo-standards to deal with, the set is ever-growing, the components are ever-growing, and there isn't really a good definition of 'correct'. it's all just a hideous mess. + thus, porting from an existing codebase is likely the more realistic option Porting Options: * gecko * webkit Porting Option Considerations: * of the port options, gecko and webkit are the most well-developed, active, complete candidates. + the choice between gecko or webkit might be arguable, but webkit may be a more desirable choice as it has a more modular design with better separation of concerns and a cleaner api, thus webkit will be targeted. New Goal: in accordance to the above enumerated considerations, the goal is to port webkit to plan 9, for the purpose of facilitating a modern, standards compliant web framework library for Plan 9 WebKit Considerations: * webkit is built primarily with c++ * webkit has a moderate number of build dependencies and app dependencies * plan 9 currently lacks a reliably functional, modern, native c++ compiler, so the goal cannot be accomplished without some means of c++ support in plan 9 C++ Compiler Options: * gcc * llvm/clang C++ Compiler Considerations: * somewhat similar to the gecko vs. webkit decision, the choice between gcc or clang may also be arguable New Prerequisite Goal: port a c++ compiler and std libs to plan 9 Ok, so really - in order to have any real chance of seeing a satisfactory, native/near-native web experience on plan 9, an existing codebase must be ported - and that codebase is written in c++, so: For the purpose of satisfying stated goal, a c++ compiler must first be ported to plan 9. Regardless, it is predicted that porting a c++ compiler to plan 9, _then_ porting webkit to plan 9, is _still_ less work than writing a brand new, complete, standards-compliant web browser engine from scratch. The question then becomes: which c++ compiler should be targeted, gcc or llvm/clang? On an entirely subjective/relative scale of 1 to 5, how difficult is it to port gcc or clang to plan 9? Is this effectively impossible without a dedicated and focused team of developers? Is anyone already doing this? Due to the requirements, it appears that incorporating the web as a 1st-class-platform in plan 9 is effectively unapproachable: Porting a c++ toolchain isn't likely going to happen, and the skillsets and resources necessary to build a solution from scratch presents far too high a bar too manage. Anyhow, thanks for letting me walk myself through the scenario. It's hard to spend any time working with and reading about plan 9 without thinking in terms of how much better a great many things would be if said things had a native plan 9 implementation. The Web on Plan 9 seems like Web++ to me. But, I'm also coming from the simple-minded perspective of a basic admin and consumer-grade enduser - someone who likes the idea of setting up a distributed plan 9 network in my house for guests, friends and family. A plan 9 terminal would be useless to such people at the current time though - which kinda deflates my balloon a bit, ah well... so it goes.
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Saturday, April 30, 2011 01:25:53 AM Steve Simon wrote: First I assume you have used abaco - it is incomplete but its the best plan9 has at present - without using linuxemu. I appreciate abaco for what it is, but unfortunately it's not something I can expect to satisfy most users' activities on the web. I still haven't tried a browser through linuxemu though... maybe that'll end up being sufficient. If you are saying that you are willing to take this on (getting a modern native plan9 web browser running) I may be able to help in some areas Excellent - I'm definitely willing to see how far I can get. My little 9 network is currently in the midst of being re-deployed (was going to play around with 9front); when I get it back online (so I have an instance to work from), I'll send you an email - I could definitely use the advice/pointers of someone more experienced. Thanks! One idea I was considering for several years was trying to get Dillo running as a fairly compliant browser, initially under an X11 server but later you might be able to merge the framebuffer backend to dillo (via a library I cannot remember) and replace it with a library which talks /dev/draw rather than linux framebuffer. Interesting... I did spend some time seeking out other, possible more simple, alternatives, dillo for instance - but I came to the spoiled-minded conclusion that to do it right - so that it's not just another kind-of basically working for a limited subset of use-cases situation - that it really should use a current and active engine such as webkit (preferable) or gecko. just some random thoughts. Thankyou! Cheers
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Saturday, April 30, 2011 03:21:09 PM smi...@zenzebra.mv.com wrote: errno er...@cox.net writes: Due to the requirements, it appears that incorporating the web as a 1st-class-platform in plan 9 is effectively unapproachable: You forgot to backtrack to your webkit/gecko choicepoint and follow down the gecko goal tree. Gecko is also written primarily in c++, which means porting a c++ compiler to plan 9 would still remain a prerequisite for that path also. (I haven't done a valid evaluation of gecko vs. webkit; I've built and poked around webkit, but haven't done the same for gecko. My c skills are rather humble, but my c++ skills are entirely non-existant... so I'm unable to perform a valid evaluation of the two anyhow) On Saturday, April 30, 2011 05:18:03 AM Ethan Grammatikidis wrote: Possibly another option: * netsurf Very cool, that's another potential port candidate that I wasn't aware of - and it's written in c, which lowers the bar quite a bit. I'll definitely take a closer look at netsurf next weekend, maybe it's a more realistic target. Thanks!
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Saturday, April 30, 2011 04:33:23 PM Lyndon Nerenberg wrote: Gecko is also written primarily in c++, which means porting a c++ compiler to plan 9 would still remain a prerequisite for that path also. No, it's written in a combination of g++-version_of_the_week and whatever Visual Studio calls C++ for its current release. You cannot port that shit. Nor should you. Warning heeded, and understood. That's not the first time I've heard less than stellar accounts regarding gecko. One thing with webkit is at least the option is there to use a different compiler (llvm/clang). And it looks like they're in the initial stages of unifying the build system to gyp (written in python, which Plan 9 already supports) - which is far better than autotools IMHO.
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Thursday, April 28, 2011 08:03:23 PM erik quanstrom wrote: Though I don't understand why folks around here complain about linux so often and so vehemently, when the only reason why you're complaining is because you _need_ linux... to furnish all the things you can't do with plan 9 - either personally, or within your organization. people who care about Doing Things Right are easy to upset. Bloat... can't live with it, can't live without it. ... I hope that something better comes along. http://www.youtube.com/watch?v=_yaP_kc3y9w On Thursday, April 28, 2011 08:11:49 PM andrey mirtchovski wrote: errno, you sound like you may be trespassing on our collective 9fans lawn. i wave a cane in your general direction. Plan 9 rules and linux drools - I get it - but, wake me up when there's a Grand Unified Solution for implementing a perfectly clean, multi-purpose, general-use operating platform for an ad-hoc, rapidly (d)evolving, messy industry/market/society - that isn't itself intrinsically, hopelessly bloated in order to fulfill said purpose. Until then, complaining about de-facto linux bloat is a lot like complaining about death and taxes. Boring and disingenuous. IMHO, at least. (I'm just glad the collective plan 9 lawn expands far beyond the pointless linux-hate gazebo.)
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Friday, April 29, 2011 02:04:26 AM Charles Forsyth wrote: [1] For those gnashing teeth over glibc - might want to check out musl libc. It's no plan 9 libc, but it's definitely less worse than glibc. ``News: As of version 0.7.7, musl has been successfully bootstrapped by a third-party system integrator.'' hmm. they had to do more than just compile it? a library has to be `bootstrapped'? i blame the parents. Really? I think it's fair enough to say that your standard library has been bootstrapped upon the first instance of it being baked into a new platform as the native libc. https://github.com/chneukirchen/sabotage On Friday, April 29, 2011 02:18:26 AM Charles Forsyth wrote: complaining is because you _need_ linux... to furnish all the things you can't do with plan 9 - either personally, or within your organization. it's true, but at least i haven't got to run either Windows or MacOS. the underlying problem is that the things we might simply import (mainly browser) can't simply be imported. it's not just us: you might have noticed that Google's Picasaweb runs under Linux by including a copy of Wine as part of its iceberg. also google in any alternative-os list you like for a discussion of the hopelessness of ./configure Icebergs are justified when used as a temporary stop-gap until a native solution is devised and implemented. Thus, a webkit environment (AWE) seems like a pretty decent compromise until Plan 9 is finally able to treat the wild wild web like a first-class citizen. I have no clue how difficult it would be to port webkit to Plan 9 though, but I imagine it would be easier than writing a pure Plan 9 web browser engine (html, css, dom ecmascript) from scratch. (I just do basic backend web programming and linux systems administration - so I'm just speculating.) But then again, why would anyone want a fully functional web experience on Plan 9 - what would be the purpose? Apparently nobody does, otherwise it'd be implemented already.
Re: [9fans] Plan 9 GSoC projects selected
On Friday, April 29, 2011 05:43:21 AM Ethan Grammatikidis wrote: On 27 Apr 2011, at 6:47 pm, Anthony Sorace wrote: • Unification of X11 code and wsys device, by Jesús Galán López [1] [...] [1] http://www.google-melange.com/gsoc/proposal/review/google/ gsoc2011/yiyus/1 I'm a bit curious about this one but all I get from the link is This proposal is not made public, and you are not the student who submitted the proposal, nor are you a mentor for the organization it was submitted to. I know you already received more info, but there was also this recent thread related to the topic: http://www.mail-archive.com/plan9-gsoc@googlegroups.com/msg00431.html
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Friday, April 29, 2011 05:21:12 AM Jacob Todd wrote: Seeing that plan 9 doesn't have a c++ compiler, i doubt it will ever be ported. But APE has c++ (old version of gcc though). I expect that a webkit (or gecko) port would need to rely on APE, right? I guess I'd have to start with the build dependencies first, some of them might already be on contrib somewhere. Cinap runs opera 9, flash 7, even blender under linuxemu, though. You might want to take a look at it. 9hal.ath.cx. Thanks for the heads-up, I'll check it out. you can also use vnc on plan 9 if you 'need' to use the web. Yep, I'm aware of the vnc workaround... but, it's just the same as a native, or near-native approach. If the goal was to build a plan 9 network in my house for my friends and family to use, for the purpose of easy administration, according to plan 9 distributed practices - then needing to have linux/bsd boxen completely defeats the purpose, and is counter-productive. On Friday, April 29, 2011 05:32:09 AM erik quanstrom wrote: i don't mind a good lively discussion, but these comments seem a bit trollish to me. I have/had no intent, no interest, and no benefit in trolling; please don't accuse me of being antisocial. I apologize if disingenuous was the wrong term. why don't we get back on track? Ok: On Friday, April 29, 2011 05:32:09 AM erik quanstrom wrote: On Friday, April 29, 2011 03:19:23 AM errno wrote: But then again, why would anyone want a fully functional web experience on Plan 9 - what would be the purpose? Apparently nobody does, otherwise it'd be implemented already. that's not logical. I operated on the understanding that Plan 9 gets developed according to peoples' desire to scratch particular itches. I was also operating under the impression that the clean and well-designed nature of plan 9's abstractions and architecture would facilitate making hard problems easier. Rather than offering speculation, from which to be knocked down and/or insulted for, I figure maybe I should just ask: If it is accepted that people do in fact want a fully functional native (or native-ish) web experience on Plan 9, what is the logical explanation for it still not existing after so many years? (by web experience, I'm not talking about porting firefox and flash to Plan 9 - I'm talking about native or ported libraries for what wikipedia refers to as a web browser engine or layout engine; and by fully functional, I'm talking about something that can score at least an 80% or so on the acid2 test.)
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Friday, April 29, 2011 09:05:39 PM errno wrote: Yep, I'm aware of the vnc workaround... but, it's just the same as a native, or near-native approach. I meant: [...] but, it's just _not_ the same as a native approach.
Re: [9fans] Compiling 9atom kernel WAS: Re: spaces in filenames
On Thursday, April 28, 2011 12:39:07 PM erik quanstrom wrote: On Thu Apr 28 15:30:38 EDT 2011, dexen.devr...@gmail.com wrote: On Thursday 28 of April 2011 20:50:14 Brian L. Stuart wrote: Life is too short to configure and compile Linux and GNU software. or spending days on choosing a computer with all the hardware supported. oh wait. that's not how you do it. you spend about the normal amount of time checking, and then when you get the machine you fix what's left. :-) i've just configured an new xeon 1155, which has had a nic that wasn't quite supported (pch2 lan + 82579 phy), and a wierd lapic/ioapic configuration. all told, it was only about a day to get it working. now i could have spend that amount of time with an os that might have supported everything out-of-the-box, but it's doubtful that i'd have it even configured yet. I'd be more excited about quick compile times on plan 9 when I can use plan 9 to check my bank account, watch youtube videos, and order movie tickets or pizza over the web. But I still need a loonix box to do those things, so I still need to suffer the horrors of glibc[1] and ~760M kernel sources - which is unfortunate. I understand why plan 9 avoids posix and unix and gtk+ and the gnu toolchain - or flash, or firefox, etc., etc. - but it would be nice if it had fuller, more complete support for the web. I wish AWE would manifest. APE - a posix environment vs. AWE - a web(kit) environment. Alas, if wishes were fishes... (we'd all be rich fishermen). Though I don't understand why folks around here complain about linux so often and so vehemently, when the only reason why you're complaining is because you _need_ linux... to furnish all the things you can't do with plan 9 - either personally, or within your organization. [1] For those gnashing teeth over glibc - might want to check out musl libc. It's no plan 9 libc, but it's definitely less worse than glibc.
[9fans] kfs and cwfs comparison
Hello! Question, regarding kfs and cwfs: why choose one over the other? In other words, what points are important to be aware of when deciding which of the two are more appropriate for any given new installation/deployment? (let's assume that kfs's 28-character filename limit isn't an issue, and that there's no concern for supporting legacy fs formats) Additionally, under what conditions/circumstances might either of those two be a more suitable/optimal alternative to, say, fossil? Thanks!
Re: [9fans] kfs and cwfs comparison
On Sunday, April 24, 2011 04:13:59 AM erik quanstrom wrote: Question, regarding kfs and cwfs: why choose one over the other? In other words, what points are important to be aware of when deciding which of the two are more appropriate for any given new installation/deployment? (let's assume that kfs's 28-character filename limit isn't an issue, and that there's no concern for supporting legacy fs formats) Additionally, under what conditions/circumstances might either of those two be a more suitable/optimal alternative to, say, fossil? in my experience, both are more robust in the face of unexpected outages than fossil. ken fs/cwfs also provides a dump file system (that is, history) without the need to run venti. Thanks for the info - couple more questions, if you don't mind: How about in terms of resources/overhead - is kfs more appropriate in constrained/embedded devices than cwfs? Or maintainability? Are kfs and cwfs both relatively equal in terms of maintenance and/or disaster recovery? Are kfs and cwfs equally dependable/stable? Finally, what about the difference between a terminal and auth/cpu/fileserver - would kfs/cwfs be more or less appropriate for a terminal vs. a server? I'm curious, because I'm about to do another plan9 install after a pretty long hiatus; and this time I'd like to switch filesystems (fossil/venti distracted from my plan9 learning curve a bit last time) - I'd just like to get some extra info that's not in the man pages, so that I can make a more informed decision.
Re: [9fans] kfs and cwfs comparison
On Sunday, April 24, 2011 09:10:22 AM erik quanstrom wrote: snipped Thanks for satisfying those questions, much appreciated! On Sunday, April 24, 2011 08:01:01 AM Steve Simon wrote: Ideally there would be a wiki page on this - I will have a go shortly... That would be helpful; looking through the archives, I can see that similar questions - regarding the effective differences between the various plan 9 disk fs's - have been brought up on the list before. On Sunday, April 24, 2011 09:10:22 AM erik quanstrom wrote: How about in terms of resources/overhead - is kfs more appropriate in constrained/embedded devices than cwfs? by default, kfs just uses 10mb of memory. i haven't run cwfs enough to say with any confidence how well cwfs does. but kfs will use less disk space (and if no changes, constant space) since old copies are not kept. Or maintainability? Are kfs and cwfs both relatively equal in terms of maintenance and/or disaster recovery? both have a weak spot. kfs. there's one copy of the file system. if you corrupt it, you're out of luck. i've never seen this happen. cwfs. if the fs is halted during the dump, there is a non-zero chance of corruption. i have seen this, but recover main can usually roll the fs back to the last good dump. the same mechanism can recover a fs if an untimely shutdown has corrupted the cache. Are kfs and cwfs equally dependable/stable? i would say so. Finally, what about the difference between a terminal and auth/cpu/fileserver - would kfs/cwfs be more or less appropriate for a terminal vs. a server? it depends. i would tend to use kfs only if i were storing my real data someplace else. i find the lack of history to be a big problem. but then again, i tend not to run fses on terminals. i just run ken's fs and am done with it. :-) - erik
