Date: Fri, 28 Jul 2006 14:22:37 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Robert Watson <rwatson@freebsd.org> Cc: hackers@freebsd.org, Joel Dahl <joel@freebsd.org> Subject: Re: cvs commit: www/en/projects/ideas index.sgml Message-ID: <20060728142237.lhocfctqugoocc48@netchild.homeip.net> In-Reply-To: <20060728092503.U4612@fledge.watson.org> References: <200607280705.k6S7585g094248@repoman.freebsd.org> <20060728092503.U4612@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Robert Watson <rwatson@freebsd.org> (from Fri, 28 Jul 2006 =20 09:52:33 +0100 (BST)): [moving to hackers@... feel free to redirect if you think there's a =20 more appropriate list] > > On Fri, 28 Jul 2006, Joel Dahl wrote: > >> Modified files: >> en/projects/ideas index.sgml >> Log: >> - Extend the ktrace project with a new task. [1] [adding some warnings to this project] Thanks for reviewing and the heads up regarding problems which may =20 arise. Yes, we should add them to the entry. > BTW, a problem that has occurred a number of times in the past is that > people have approached us with implementations of ideas in the idea > list that it has later transpired we aren't actually interested in > (sometimes at all). I think it might not be a bad idea to sprinkle the My impression is, that we lack some committers which not only have =20 time to review the submissions, but also have the necessary domain =20 specific knowledge at the same time. > idea list with some additional cautionary language -- often ideas > listed there are things to explore, not to adopt without very careful > consideration. For example, the "FPU subsystem overhaul", "Process Uhm... the FPU one... ok. AFAIK bde reviewed it. I haven't seen the =20 review (or I don't remember it), but so far it looks like it would be =20 beneficial to commit it (AFAIR). I'm not able to review the code (I =20 lack the necessary domain specific knowledge), but I wanted to give it =20 a try on my system and then send a mail to arch to get some technical =20 reasons why to not commit commit it. Similar for the new TCP checksumming code. Initially there was a =20 problem, it got fixed, and now nobody takes care of it since everyone =20 seems to think "it's flawed". At least this is the impression I got. > checkpointing", "Pluggable disk shceduler", "Magic Symlinks", "NFS > Lockd (kernel implementation)", and several others -- the task here > often isn't to port/write the code, the task is to port/write and then > perform a detailed and careful evaluation of the changes to decide > whether they are a good idea, and then consider adopting the code only > if the evaluation suggests it is a good idea and after significant > refinment. So far we got not much responses from committers/developers. There's a =20 lot of interest in working on some of the entries, but so far we don't =20 get much review for the entries/ideas themself. Any refinement is =20 welcome and appreciated. So if someone has some thoughts about =20 specific entries: please, share them with us. > Some of the ideas on this list are distinctly "explore this direction > as a computer scientist, not a code hacker" sorts of problems -- for > example, the "Process checkpointing" task seems to suggest that if you > can read the DFBSD repository and write some C code, you're set. In > fact, this is not remotely the case. Checkpointing is a very difficult > problem in computer science, with little consensus on how it should be > done (and indeed whether it should be done at all) by general purpose > operating systems. Not only that, but we would not adopt the DFBSD > implementation as-is, as it solves a few of the easy problems, and none > of the hard ones (i.e., security). The requirements here aren't just > the ability to write code, but an understanding of distributed systems, > our application/execution model, a strong understanding of the > performance and security requirements, and willingness to not just look > at code but the extensive research literature on this topic. AFAIR the process checkpointing in DFly has to be enabled (or am I =20 mixing this up with the magic symlinks?) in the kernel. And the man =20 page contains some text what is possible and what not, and about =20 security implications. Yes, they don't use a model which is able to =20 solve all cases, but for some cases where the programs (those which =20 don't make heavy use of I/O and thus can open/close I/O channels when =20 they are needed) are written to make use of this feature, you can make =20 some users happy and the developers can concentrate at the problem at =20 hand. So it's one of those 80/20 solutions. While I agree that a 100% =20 solution would be nice, I think an implementation of this in -current =20 would be nice to have. > I think people often grab ideas from the list thinking that if > implemented as described, they will get committed, and this is not the > case. In many of the sorts of "scientific" cases it's likely we'll > look at the results and say, "Oh, that was a bad idea", or maybe > slightly more likely, "Oh, hmm, not so sure about that". The existing Joel and I already talked briefly about an "we don't do that" or "been =20 there, done that, wasn't a good idea" page because of this. > cautionary language captures that there might be disagreements on the > specifics, but fails to capture that there may be disagreements on the > fundamental ideas themselves. I like the ideas list idea a lot, and Ok, we should change that. Thanks for providing a big picture view for =20 those of us which don't see the forest while sitting in front it... > don't want to see it removed, but I also don't want people getting the > false impression that this is a "todo" list. Some items are todo items > and obvious short-order commit candidates, others are out-there ideas > that have potential and should be characterized as "high risk" when it > comes to the results actually being used. Maybe what we should be > thinking about is classifying the todo list items into rote items > (things where the chances of adoption of a decent implementation are > high, subject to review) and researchy things (where the chances of > adoption are low, not just because the chances of a good implementation > are low, but because there are lots of open and very difficult > questions involved). This would help prevent misunderstandings, if > nothing else. We need some reviewers here... while I'm able to come up with a nice =20 technical description of roughly expressed ideas (as long as I get the =20 idea), I'm not a TRB and as such aren't aware of every implication. =20 And some ideas are expressed in a way which make them sound like it's =20 "common knowledge to people which work in this field" (ATM I refer to =20 the NFS lockd in kernel implementation idea). So: helping hands are welcome! Thanks for taking some time to review some parts of the list. Bye, Alexander. --=20 All great discoveries are made by mistake. =09=09-- Young http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060728142237.lhocfctqugoocc48>