Date: Fri, 3 Nov 2000 14:40:17 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jkh@winston.osd.bsdi.com (Jordan Hubbard) Cc: tlambert@primenet.com (Terry Lambert), ignacioc@avantel.net (Ignacio Cristerna), freebsd-advocacy@FreeBSD.ORG Subject: Re: Installation: what to (not) do about it Message-ID: <200011031440.HAA16097@usr02.primenet.com> In-Reply-To: <13013.973250533@winston.osd.bsdi.com> from "Jordan Hubbard" at Nov 03, 2000 03:22:13 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > What ever happened to that huge amount of installer code that > > The FreeBSD Project funded with that Russian(?) guy? > > 1. It wasn't the project who funded or really had much of anything to > do with it, it was Walnut Creek CDROM > > 2. It wasn't a huge amount of code. > > 3. It's called libh and there's already a mailing list devoted to it > and several volunteers devoted to its gradual improvement. Where > have you been? One assumes you at least read the paper I did on > the topic of installers where libh is also described fully. I scanned it. It wasn't posted widely to FreeBSD lists to which I subscribe. I basically got to see a quoted, perhaps partial copy of your posting. From the parts of it I read, it was inadequate. It did not address the layered software issues that have only recently resurfaced in the thread on using the NetBSD rc file code. Without these issues being addressed, an installer that can only install, but not upgrade or incrementally add packages that "just work", would be the result. Such an effort might be nice if you are a CDROM manufacturer, but it's frankly useless to almost all users, since you only install once, but you do similar tasks all the time. > 4. You seem to be almost compelled to furnish a stream of singularly > unhelpful replies to this topic lately, providing everything from > citations to proprietary projects which run counter to the goals of > the FreeBSD project to manufactured descriptions of projects like > libh. It really makes me wish you'd choose to focus all the free > time you now so obviously have now on actually writing code; that > would be a refreshing change from your current operational model. I've tried doing code for FreeBSD before; other than trivial things that it takes zero brains to understand, most of my stuff hasn't made it past the commit filters, who insist on being educated about everything, and appear to be unwilling to go to college to get that education. On the contrary to your comment about having a lot of free time, what I have is a slow net conection, and I'm working to remedy that. Meanwhile, it means that I have time to read and respond to email while waiting for large downloads to complete, at least while I'm not running Microsoft tools to work on project management or business planning, etc.. I would work on coding, but FreeBSD is incapable of supporting a winmodem. As it is, I am working 12 to 16 hours a day, and have a CVS repository with about 5 million lines of code in it, about 6% of it mine, and for which I did all of the integration. --- On the subject of "counter to the goals of the FreeBSD project", which goals are those, the goal of getting FreeBSD into the hands of more people? The goal of improving the user experience? The goal of ensuring that the install code is open source, and letting it be called FreeBSD when it has soft updates code with it under a non-open source license, but not when it has an installer with it with the a similar license? I fully understand the desire to link the installer source code to use of the FreeBSD trademark, but I think that desire is contrary to the long term best interests of FreeBSD. Whether or not you agree with this is irrelevant, until your constrants can stay in force, yet still result in a new installer being written. You are currently two years to the bad. Before you go off on a tear again, let me point out that I am _NOT_ offering to do a proprietary installer for commercial purposes myself, I am merely pointing out that it has been much longer than a year without a new installer, and had their terms been agreed to a year agao, FreeBSD would have its installer source code today, and under the terms you are insisting upon, up front. --- I'll tell you what I _am_ willing to do, assuming the project is willing to guarantee that they will commit the code (I could care less if they want to "clean it up" and pee on it to make it smell like them in the process, so long as there is a agreeable time limit on the process): o I'll fix the VFS stacking code; I've had working stacking without cache coherency problems sinmce 1996, the last time I tried to submit the patches, and the PTB insisted I dumb them down to the point that they then could complain that the changes were gratuitous because they didn't have the vision to keep their eyes on the goal instead of the process. o I'll update my UMSDOS stacking layer code; this will let you install a UNIX FS with correct metadata onto an MSDOS partition, and is the first step required to create a "test drive" version of FreeBSD that doesn't require partitioning. For me to do this, the VFS stacking code changes must first be committed to the source tree. o I'll update my QUOTA stacking layer code; this will let you apply quotas to any VFS layer, and not limit you to only using them in conjunction with FFS. Again, for me to do this, the VFS stacking code changes must first be committed to the source tree. o I'll provide specfs changes to support clone devices; I won't go so far as to force ytou to take the other changes I've made in this area (I currently run without a struct fileops, and specfs no longer exists, on one of my research systems; it lets me do things like change ownership on sockets and named pipes, like SVR4 and Linux can, and BSD can't -- but I won't force you to take that code). You will have to accept the cloning pty implementation sample code as part of this, so that I can be assured that no one will break things before the next phase is complete. o I'll fix the VMWARE problem that prevents more than one virtual machine running at the same time. For me to do this, the specfs changes must first be commited to the source tree. o I'll fix the root partition vs. mounted FS distinction abstraction, and move the mount overlay to higher level code, so that it isn't being duplicated per VFS, as it is now (and being omitted in some, making it impossible to boot from those partitions). o If a Windows based installer is committed to by the project, and someone is willing to tackle the FBSDBOOT.EXE mechanics, I'll provide an autorun.inf and the necessary Windows code examples to do a "test drive" install to an UMSDOS directory hierarchy. o If the project will commit to adding it to their archived files, and changing the package suffix, as well as modifying the MIME types on the FreeBSD web server to add a new type, and modifying the "helper" applications installed by default in the browser ports, I will provide code that lets you do "one click install" of ports from the FreeBSD web sites. I will give instructions and documentation, but the integration itself is up to other FreeBSD people. For me to do this, I will need not only project buy-in, but also buy-in from the FreeBSD web site administrator, and the browser ports maintainers. I would be doing this at pretty high opportunity cost, since my time is currently valued at around $120/hr, after taxes. So now it's your turn to "put up or shut up"; I _can't_ expend the effort on these things without a guarantee that that effort will not be wasted, like it was last time I spent the effort on these and similar projects on behalf of FreeBSD. I _can't_ afford to spend 40 hours doing one of these things (~$10,000, pre-tax), if I don't have some sort of commitment that that money won't be flushed down the toilet by the project. Ball's in your court. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011031440.HAA16097>