From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Date: Thu, 17 Feb 2005 22:21:19 +0000 From: rog@vitanuova.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] writing code Topicbox-Message-UUID: 0be7aed0-ead0-11e9-9d60-3106f5b1d025 > The mechanism is, and always is, someone writes code. maybe this is unrealistic, but i'd like to see more "encouragement on principle". that is, if someone suggests something, it'd be nice if people (particular labs or ex-labs people) would chip in and say "yes, it's a good idea in principle; i'd like to see something like that" (or perhaps "yes, but it should be done in this way", or "bad idea, philosophically misguided"). if there were various projects around that had been given the thumbs-up on principle (pending actual implementation), perhaps more people might be inclined to get their hands dirty and write some code towards those ends. instead, i feel that people face the prospect of spending weeks writing code, only to be told at the end that the whole aim of their effort was misguided; or, worse, that the work was indeed misguided, but it gets included anyway on the grounds of inclusiveness, diluting the excellence of the whole system. of course, it's perfectly possible to take the view that plan 9 is perfect; that beyond minor bug fixes, new hardware ports and device drivers and more applications, plan 9 is as good as it could be. if that's the consensus view, then fine, i can live with that. but personally, i think that there *are* places where plan 9 doesn't perhaps do as well as it could, and fixing some of those might require the rethinking of some core parts of the system. maybe the first thing to do is to try and get some consensus as to where the weaknesses of the system are. the kind of things that might be put in the BUGS section of intro(1), if there was one. to start with, perhaps we could suggest areas in plan 9 which we think could use some work, in the broadest terms possible, avoiding specific solutions; then we could try to work towards specific projects aimed at addressing those areas. people could give their views on each issue, e.g. a) this isn't a problem, it's meant to be this way. b) yes this is a problem; i've no idea what to do about it though. c) yes, this is a problem, but i don't think there's a decent solution possible. d) yes, this is a problem, and here's a possible solution. e) yes, this is a problem, but the right solution is too hard. f) you're coming at this from the wrong angle. g) you're making a mountain out of a molehill. h) i don't care in the slightest about this issue. i) i don't know what the hell you're on about. here are a few for starters: isochronous/streaming data transfer over 9p: 9p is slow over wide area networks when streaming data, due to the ping-pong nature of the data transfer. can anything be done to help solve this? distributed authentication: the plan 9 authentication model relies on having an on-line authentication server. as firewalls and mobile devices continue to proliferate, might it be worthwhile adding support for a peer-to-peer model be more appropriate? graphics: high-bandwidth bitmap access is slow. additionally, even the existing hardware acceleration could be leveraged more than it is (if any portion of a window is obscured, then no h/w acceleration is used for that window). is it conceivable to have a system where all graphics operations are accelerated (as apple are apparently to be doing with their next system), or does the current architecture preclude this? graphics primitives: graphics drawn with the existing non-bitblt primitives is not great (e.g. lots of jaggies on diagonal lines). could implementing subpixel rendering help matters here? how can i continue to do work when a server goes down? aan can deal with a broken network connection, but say someone reboots the fileserver? is there any way we can incorporate some redundancy into the system, or make it easier for a applications to recover?