Hi Paul, I'm not responding to create a big discussion about the issues you raise (partly because I don't disagree with most of what you wrote) - but since I've participated in the discussion so far, I want to respond so I it doesn't seem like I'm quiet simply because you raise points that you don't like about Bering uClibc.
> If people with > floppy only hardware want to maintain a stripped down floppy only > version, that's great, but do we really want the fate of B-U tied to > such limitations? What I would like to see would be something in between - maintain the floppy image because it serves a good purpose to many users and also makes sure that developers don't go overboard with adding bloat, while at the same time supporting more recent hardware. It would be in my own interest - none of the 6 "production" boxes I run Bering uClibc on has a floppy or CDROM - they all boot from CF, on different kinds of hardware (Soekris, WRAP, Nexcom). So, to me the question is more along the lines of "is there somebody who is willing to work on making booting off something other than floppy and CDRom easier?" So far, the answer to that has been "no" (and there's only so much 5 or so people can do in their spare time). > 1) I was a core developer for FreeBSD for over six years. I've been > a Debian follower for about eight years as well. Both projects > lost major mindshare because their software was too difficult for > folks to install. As dedicated hackers, we looked at ourselves and > said: "WTF?" Then Mandrake and later Fedora came along and we saw > how installs should work. Even eye candy can be important. :-( I don't disagree with that - I just wouldn't want to spend my spare time working on a nice installer that will work under every imaginable operating system on every imaginable hardware. And I even less want to have to support that kind of thing. > Installing B-U on modern hardware is still a pain requiring multiple > tools and sometimes multiple operating systems. Well, depends on what you want to install it _to_. If you boot off CDROM, or floppy, it's quite easy (but I guess floppy is at least partly ruled out with the "modern hardware"). You're certainly right about installing it to CF, DOM, DOC, HD or some sort of USB memory. > 2) It's insanely tedious to upgrade the software because the configs > are still stored with the binaries, and there are no tools for > merging diffs between the configs (e.g. ucf). Absolutely, no debate about that. This is something that has been on our todo-list for quite a while (and several people, including myself, have worked on it), but nothing mature enough to give to the public has come out of it yet (unless I missed something). > 3) There's no easy way to figure out what modules should be updated. With "modules" - are you referring to kernel modules (if so, the answer would be easy - if you install a new kernel, update all modules), or rather packages. If you're referring to the latter, and would like to see some sort of "update check" that spits out a list of packages on the router that are out of date, again, I agree - and I even started working on that on "company time", until I found out that there wasn't any commercial interest in such a thing whatsoever, so I was no longer able to work on this during work. > Other developer rants: > > 4) The development environment is a mess. It needs to be portable and > self contained. People should be able to build a development > environment on any POSIX based system, even a cygwin environment. :-) I guess it's an improvement over what was available before, but of course you're right that it still has a long way to go, before it will build things cleanly on every current distro, let alone until it will do a real cross-compile (I'm not even sure the latter can be done at all with the buildtool-approach). But remember where we're coming from - before, sources and packages were built mainly by hand (maybe people set up some scripts to help, but it was still mainly a manual process, unless somebody else had some build-system running that I don't know about). Having to rebuluild a package often meant that due to the manual process, things were overlooked and a broken package was released (if the brokenness wasn't caught during testing). Today, despite all the issues that buildtool has, one can issue "./buildtool.pl build" on a (supported) linux box with internet connectivity, and more likely than not one will have a full build environment a few hours later (plus everything one needs to create all the packages in the bering-uclibc tree). > 5) The way we use CVS is a mess. Because diffs are stored out of tree > in .tar.gz files and applied at build time, it's a pain in the ass > to see what work other people have done. Debian has this problem, > FreeBSD does not. CVS and SVN have branches, sources should be > tracked and imported. Well, here I disagree. I actually like the "clean sources from upstream plus patches" approach. That's pretty much the same way SRPMs work on RedHat. I agree that it makes it difficult to keep track of what has changed, especially if commit messages and changelogs don't provide that info. To me, the main advantage of the "tarball + patches" approach is that it makes it easy for people to add their own patches before the build (or remove patches). If everything was stored as source in CVS (I guess you're thinking of vendor branches here, since we'd be tracking 3rd party sources) that would be more difficult, at the very least. > Once > you climb over the hurdle of getting the damn thing working, you no > longer care about the install experience, Yup, that sounds familiar. > but to gain additional workers > and reduce your support load, this needs to be done. In any commercial > endeavor (e.g. even Ubuntu and RedHat like commercializations of Linux), > initial user experience is the FIRST priority, not the last priority. Indeed, and if Bering uClibc was a commercial endeavor, I would surely hope that whowever was running the show would throw more personell at the project (and if I were that person, I _would_ throw more personell at it). Maybe this is a chicken-and-egg problem - without a better "user experience" there'll not be more people working on the project, and without more people working on the project, it's extremely unlikely a "better user experience" will happen any time soon. Martin ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
