Date: Fri, 03 Nov 2000 18:56:28 -0800 From: Jordan Hubbard <jkh@winston.osd.bsdi.com> To: Terry Lambert <tlambert@primenet.com> Cc: ignacioc@avantel.net (Ignacio Cristerna), freebsd-advocacy@FreeBSD.ORG Subject: Re: Installation: what to (not) do about it Message-ID: <24441.973306588@winston.osd.bsdi.com> In-Reply-To: Message from Terry Lambert <tlambert@primenet.com> of "Fri, 03 Nov 2000 14:40:17 GMT." <200011031440.HAA16097@usr02.primenet.com>
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. And yet you jump in and say it was inadequate when you admit you haven't even read it in detail. Hmmmmmm. FWIW, I do talk about ugrades in the paper and how to make them reversible and less potentially destructive since a lot of the barriers to a successful upgrade experience come from justifiable user fears about what happens if the process goes wrong on a production system. > 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. This explanation just doesn't cut it, Terry, not did it cut it the last 5 or so times you used it. Many people seem to get past the "commit filters" just fine and perhaps the real answer is that they have a degree of perserverance and committment to achiving their goals that you simply lack. But we'll discuss that more in detail below. > 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 .. You seem to have this "thing" about the softupdates code which is entirely out of proportion to the actual reality. The reality is that Kirk allowed us to incorporate the code into FreeBSD and which meant that people could read it and hack on it, a significant part of those fundamenal goals I mentioned. The code wasn't initially free for "commercial use", though CD releases and a fairly broad spectrum of "commercial" activities were in fact allowed, but it was a bolt-on option which any user could freely use on a personal basis and many did. Those who didn't want to comply with the selective-use license simply didn't enable softupdates and their overall "FreeBSD experience" was not adversely impacted by this. That's why we felt that the trade-off, and one we did indeed debate rather seriously first, was worth it. What you were describing was a body of code for which the source code would NOT be available and to which people could not make general improvements. Not only that, but the overall "FreeBSD experience" would be substantially different for people using that installer from the point of their very first contact with the OS, a very different kettle of fish than soft updates which are essentially invisible to the naked eye (for 99.9% of what pass for "average users"). It is a complete mystery to me how you can fail to see the difference or even draw a parallel between the two technologies with a straight face. > 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. The Caldera installer, which many people have drawn parallels to, is completely free and can be ftp'd from their site. Judging by the extreme number of similarities in the Red Hat installer, it also appears likely that at least one other major Linux vendor did exactly that. I therefore find it difficult to swallow your argument that an insistence on it being freely available is something which would be an absolute barrier to entry for any next-generation graphical installer. The empirical evidence available hardly supports such an assertion. > 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. And this is speculation masquerading as fact. You have no sure way of knowing that this would, in fact, have occurred or that "two FreeBSDs" would have even been widely accepted by the project contributors or the user community. I see it as far more likely that your mysterious commercial benefactors would have been deluged with demands that they open source their product immediately so that people could customize it and this might in turn have led to a siege mentality on their part and very poor results. You simply have no way of knowing for sure what you claim as fact above. > o I'll fix the VFS stacking code; I've had working stacking > without cache coherency problems sinmce 1996, the last That would be fine. You'll have to work with the other VFS folks, of course, since nobody gets carte blanche to play lone ranger in the code base and that's something that we all, including myself and anyone else with a committer's hat, has to live with. Still, if you're halfway personable about it and don't get high-handed or let your ego take precedence over good sense, I'm sure you'll be met with nothing but enthusiastic support for the idea. > 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. Fine too - we've even discussed this before and agreed that it's something which should be done. > o I'll update my QUOTA stacking layer code; this will let Good good. > 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. As long as that doesn't break all the clients of PTYs (and there is the long-standing and classic problem of how PTYs are allocated by walking vs a true PTY allocation mechanism), I'm sure nobody would argue with that either. > o I'll fix the VMWARE problem that prevents more than one Fine. > o I'll fix the root partition vs. mounted FS distinction Fine. > o If a Windows based installer is committed to by the project, If you commit to building one, I'm sure people will commit to using it. That's about the only "commitment" you can expect from an amorphous blob of developers led by an only slightly-less amorphous blob of core people and to expect anything more than that would be silly. More on that in a moment. > 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, Again, build a better mousetrap and they will come. Build a can opener masquerading as a mousetrap and expect the opposite reaction. You're not going to get advance buy-in for something nobody has ever seen or can even realistically quantify, but if you can in turn show that you're capable of more than just discussing how the future will be better under your aegis then you can expect that people will begin to take you and your proposals more seriously. This one seems a bit pie-in-the-sky to me, but I'm always willing to look at it. > 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 Like I've told you many times, Terry, nobody gets a "guarantee" of anything in this project since it's not a kitchen appliance dealership which hands out limited customer guarantees along with every frigidair they sell. What you get is the chance to deal with a large group of people and try, through dint of effort and perserverance, to sell them on your ideas and (more importantly) your working code. Even if I wanted to change this as part of "putting up or shutting up" for you I could not since it's not in my power to beam hypno-rays directly into the brains of several hundred people and get them all to agree up front to buy a used car from you. That's something that you, and only you, can do. Same deal *everyone* else gets. In short, this is life, deal with it. - Jordan 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?24441.973306588>