Re: [9fans] Les Mis?rables
Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Erreplicate. Bye, bye, cute acute. --On Monday, January 19, 2009 6:53 AM + jimmy brisson theotherji...@gmail.com wrote: Although there is already an ircfs for Inferno, since I don't want to run Inferno outside of Plan 9, and certainly not over a remote connection to Plan 9 (these also being my only options -- unless someone wants to start creating drivers for Atheros wireless cards), I've begun work on an FS backed IRC client for native Plan 9. Steve Q. When did supporting Atheros wireless cards stop being a solution? As a High School senior, I have tons of time on my hands, but very little experince. Therefore, I am could be handed the sorce for a working wifi driver and replicate it for Atheros based cards (using my current linux wifi driver for reference). In other words, could someone point me in the right direction? thanks, Jimmy
Re: [9fans] Les Misérables
hiro: Yeah, I think your arguments make perfectly sense. I would still be interested to know whether Akshat had the same thoughts in mind:) I have great affinity for everything Plan 9 -- from the superficial interface to the depths of its methodology (although, I was recently dumped by venti). Coding an FS backed application is something I've always wanted to do; one that provides an interface for something I regularly use and understand very well, would be easier than other things. Steve is spot-on. And as Erik pointed out, Inferno simply isn't Plan 9 -- though I still wouldn't mind it on top of Plan 9 if it were not so slow over drawterm/cpu(1) on 9vx. Would I still work on this application? Yeah -- it's not there on Plan 9 natively, which has its own benefits (and comfort -- see above). Beyond that, an even more interesting application would be an IRC server itself, which, with the backing of an FS, could have a dual effect/usage of both, fs attachment (for Plan 9 folks), and the normal protocol connection (for everyone else). This could perhaps employ the Plan 9 namespace methodology for containing some sort of conversation- spaces for users... and stuff. I won't elaborate... too many ideas popping in and out, for otherwise menial tasks ak
Re: [9fans] Les Mis?rables
2009/1/18 jimmy brisson theotherji...@gmail.com: ... When did supporting Atheros wireless cards stop being a solution? As a High School senior, I have tons of time on my hands, but very little experince. Therefore, I am could be handed the sorce for a working wifi driver and replicate it for Atheros based cards (using my current linux wifi driver for reference). In other words, could someone point me in the right direction? See the great Eric Smith who thought he could -- and related messages: http://9fans.net/archive/2006/04/286 Sadly, most of that time will probably go into hopes and failures of the replication idea, and by the time college starts up, you'll have learned just enough to no longer have any more time to write working driver code. In short: it's not easy (see jmk's post as reply to the above reference). thanks, Jimmy an import(4) for free time would be very valuable -- I would not have needed a hammer and chisel as a printing device, usable with Plan 9, ak
Re: [9fans] Les Mis?rables
See the great Eric Smith who thought he could -- and related messages: http://9fans.net/archive/2006/04/286 Sadly, most of that time will probably go into hopes and failures of the replication idea, and by the time college starts up, you'll have learned just enough to no longer have any more time to write working driver code. In short: it's not easy (see jmk's post as reply to the above reference). always look on the bright side of life da doo da doo da doo da do ta do. sure it's not easy writing a driver. if it were, there'd be no satisfaction in doing it. yet they are still just software. there is nothing magical about a driver. i would recommend getting some documentation, though. drivers themselves don't retain much information on what the magic registers do. - erik
Re: [9fans] Changelogs Patches?
I think I'm now ready to pick up this old thread (if anybody's still interested...) On Jan 7, 2009, at 5:11 PM, erik quanstrom wrote: Lets see. May be its my misinterpretation of what venti does. But so far I understand that it boils down to: I give venti a block of any length, it gives me a score back. Now internally, venti might decide just a clarification. this is done by the client. from venti(6): Files and Directories Venti accepts blocks up to 56 kilobytes in size. By conven- tion, Venti clients use hash trees of blocks to represent arbitrary-size data files. [...] Right. This, by the way, suggests that the onus is on the clients to help venti reuse as much blocks as possible. Has there been any established practices of finding the best cut-here points? But even in the former case I don't see how the corruption could be possible. Please elaborate. i didn't say there would be corruption. i assumed corruption and outlined how one could recover the maximal set of data and have a consistent fs (assuming the damage doesn't cut a full strip across all backups) by simply picking a good block at each lba from the available damaged and/or incomplete backups, which may originate at different times. (russ was the first that i know of to put this into practice.) in the case of zfs, my claim is that since zfs can reuse blocks, two vdev backups, each with corruption or missing data in different places are pretty well useless. Got it. However, I'm still not fully convinced there's a definite edge one way or the other. Don't get me wrong: I'm not trying to defend ZFS (I don't think it needs defending, anyway) but rather I'm trying to test my mental model of how both work. We assume a damaged set of arenas for venti and a damaged set of vdevs for ZFS. Everything is off-line at that point and we are running strictly in forensics mode. The show, basically, consists of three acts: 1. salvaging as many good data blocks as possible 2. building higher-order structures out of primary data blocks 3. trying to rebuild as much of a consistent FS as possible using all the available blocks It seems to me that #1 and #2 are 100% the same in terms of the probability of success. In fact, one might claim that ZFS has a slight edge because of: a. volume management being part of the FS b. the ditto blocks IOW every block pointer having up to 3 alternative locations for the block it points to The net result is that you might end up with more good blocks to choose from in ZFS world, than in venti's case. Which brings us to #3. Once again, we might have more blocks to choose from than we want (including free blocks) but the generation number should be enough of a clue to filter unwanted things out. Thanks, Roman. P.S. Oh, and in case of ZFS a damaged vdev will be detected (and possibly re-silvered) under normal working conditions, while fossil might not even notice a corruption.
