On Saturday 06 November 2010 19:40:49 Denys Vlasenko wrote: > I actually started looking at a lot of things which were not watched and > were allowed to rot. Approximately in the order I started looking at them: > > * stack size > * bss size > * fix most of bugs filed in database (most of them were easy) > * warning-free build > * randomconfig error- and warning-free build > * code readability > * expanding testsuite, especially shell testsuite (did not even exist) > * assuring testsuite does not show regressions with new releases > * running testsuite over randomconfig build does not throw false positives > > Basically you complain that I also had to watch for > and not allow complexity to increase too much, and I did not do that. > This doesn't seem to be entirely fair. I can't do everything.
Understood. Neither can I. I'm not exactly complaining, I'm saying your priorities are different from mine, in the context of explaining why I feel overwhelmed and need to disengage from the project. > > I'm not saying more features is bad. I'm saying the loss of simplicity > > is bad. > > So what's your proposal? My proposal was leaving you alone? I'm just replying to the emails I'm cc'd on. :) > > All three things trade off for each other, but one of them has taken it > > on the chin in favor of the other two. It makes the project > > uncomfortable for me to work on, and I don't believe the amount of > > time/energy I have available to put in won't even keep up with the > > ongoing degradation of the quality. > > I guess someone else needs to do that, if you don't have the time. > > Sad but true: there is always more things to do than time available. Oh yeah. > For example, one of _my_ longstanding TODOs: > uclibc testsuite needs reviving. It has bit rotted. My todo is regression testing nightly uClibc builds in aboriginal, making sure that it cross compiles, boots, and builds stuff natively. Tell you what, when I get around to poking at that (and I haven't even redirected the nightly cron job snapshot build of -stable to upload the results to landley.net instead of the defunct impactlinux.com yet... heck, I haven't even got a new mailing list up yet), I'll email you about it. > > I'm already running a red queen's race over on the kernel and qemu side, > > and LLVM will be another, and when I start caring about the unreleased > > uClibc code that will be another, and when I get distros natively > > bootstrapped the bootstrapping logic will bit rot too. > > Sometimes I just not let myself to start hacking on something new. > Because I know there will not be enough time to continue. I'm 38, and have been had Linux as my primary programming environment since 1998, so I'm probably a few years ahead of you on the curve here. :) > Maybe you can do the same. If you feel overloaded, just resist > the temptation of working on less important things. This is why I killed my tinycc fork and haven't done a qcc restart. This is why I'm not looking at llvm yet (although it's mephorically flashing at me from my todo list). This is why I'm _not_ trying to dive back into busybox development when I see a target-rich environment... > For example, why do you want to bootstrap distros? To concretely demonstrate that that building natively (instead of cross compiling) is a viable approach that scales well. Because being able to reproduce things from first principles is the only way to squeeze the black magic out. Because embedded build systems that also commingle what you build with how you build are are _stupidly_ non-orthogonal and thus separating the "create a toolchain", "cross compile a working native development environment", and "build a bunch of packages" steps. Because the only way to really test code is to run as much real world data through it as possible, thus the way to test a build environment is to try to build as many real world packages as possible. Because package management is the distro's problem, and they have a large staff of people doing it full-time, and reinventing this wheel is sad but until it's easy to leverage the work they do people will keep reinventing it badly, over and over, with buildroot and OE and so on. Because I'm halfway finished with the research, design, and implementation and want to finish to get it off my plate. (And maybe convince somebody else to use it and take up maintenance of it once it _is_ working and automated to a nightly cron job.) > Is its value worth the time you expect it to take? It's the logical progression off what I've been doing, and if I don't finish my own work nobody else will. > Do you remember that you do need to sleep sometimes? ;) I've been doing a huge amount of that this week. (Modulo the weird al concert.) I'm still in the recovery phase of my gap between contracts. Reading the temeraire books, catching up on email and web reading and the netflix queue, getting more exercise in the past week than in the previous month... I honestly haven't done nearly as much programming as I expected, but I'm familiar enough with my own cycles to know that once I've spun back up to speed, I'll probably get traction fairly suddenly and start going. :) > Good news if that if your project is successful, you might > eventually find that other people taking parts of work on themselves. Yes please. Alas, the website I was using going down kind of sucks. (It would be churlish of me to try to put this on morris, wouldn't it? My landley.net domain is still parked on a server in Eric Raymond's basement, still using his personal internet connection, and although it's FIOS it's still pretty finite and the server it's on is closer to "nine fives" of reliability than "five nines"...) > You might eventually acquire a "lieutenant" who will maintain > "building distros on Aboriginal Linux" chunk. > *Thats* how projects scale beyound what can one person do > in 24 hours per day. > > But this requires social skills, yes. Linus, not Theo de Raadt. I know. On the scale that Linus is at one end of and Theo's at the other end of, I might be somewhere around Alan Cox on a good day. He codes, he integrates, he advises, but he doesn't really _lead_ much. He had the opportunity to do so, back when I posted that "patch penguin" thing I had an email conversation with Alan where he told me he was worried about supplanting Linus and didn't _want_ to. People could get patches into his tree more easily than Linus's, people were using the -ac tree and basing distros on it, but Alan thought Linus was a better architect and didn't want the job. So Alan ended the -ac tree and took a year off to get an MBA, to force people to stick with Linus and work their problems out... Alan is a better _and_ more prolific coder than I am, by the way... > > I'm glad busybox does more things for more people, but I'd already > > implemented most of the feature set I personally needed to do this back > > in 1.2.2, and the remaining bits I've added since (oneit, patch, > > nbd-client, ccwrap, etc.) could live as individual files in > > sources/toys/*.c if necessary. (You'll note I haven't pushed oneit into > > busybox, even though an init program designed to launch a single > > executable with a proper controlling TTY and signal handling, reap > > zombies until that executable exits, and then shut the system down... > > once upon a time that simplicity would have been in busybox's purview. > > But it would have been a unique facility of busybox, not a copy of an > > existing program somebody else already wrote and maintains externally, > > and thus not part of busybox's _current_ mandate. > > Active contributors have privileges like adding their personal toys :D > Mine is nmeter. I think adding yours is ok too. Busybox has at least two init programs already. Given that, I'm not inclined to add a third. Speaking of which, I need to get around to testing hush against real world shell scripts. (I need to patch my local build so defconfig selects hush, I can do that now, actually...) > > I'm happy that busybox is well maintained, and I'm happy that if I post a > > bug report here it tends to get addressed promptly. But my goals and > > busybox's goals have drifted apart over the years, and I'd rather spend > > the majority of my time elsewhere now. > > I don't have a problem with that. Work on things you enjoy most. > If you don't really enjoy hacking on busybox, don't torture yourself. I used to, and I want to help, but I moved on, Erik moved on... And I refuse to be Bruce. :) Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
