From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 28 12:22:36 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11E2916A4E0; Fri, 28 Jul 2006 12:22:36 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 516E343D45; Fri, 28 Jul 2006 12:22:35 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5FAD4.dip.t-dialin.net [84.165.250.212]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k6SC9wr0018961; Fri, 28 Jul 2006 14:09:58 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k6SCMbaH078604; Fri, 28 Jul 2006 14:22:37 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Fri, 28 Jul 2006 14:22:37 +0200 Message-ID: <20060728142237.lhocfctqugoocc48@netchild.homeip.net> X-Priority: 3 (Normal) Date: Fri, 28 Jul 2006 14:22:37 +0200 From: Alexander Leidinger To: Robert Watson References: <200607280705.k6S7585g094248@repoman.freebsd.org> <20060728092503.U4612@fledge.watson.org> In-Reply-To: <20060728092503.U4612@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new X-Mailman-Approved-At: Fri, 28 Jul 2006 14:34:58 +0000 Cc: hackers@freebsd.org, Joel Dahl Subject: Re: cvs commit: www/en/projects/ideas index.sgml X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 12:22:36 -0000 Quoting Robert Watson (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