> I also add my thanks to the discussion. I do have a fundamental question > to pose however. It seems that opensource culture for large projects > is driven by featurism and the need to make massive changes incorporated > into frequent releases.
> I come from a background of very long-term > stability requirements for APIs and ABIs, performance figures on hardware > over long life-cycles and stringent documentation. Let me guess, such a background involved payment with lots of money. Sorry, but it must be said. The downside to slow-moving systems is more obvious when you sit down and compare our security reputation against long-term stability products like HPUX, or pick any other old unix vendor. Check out their packet filter, while there. Check out the advanced things you can do with their system.. like drive modern hardware. Check any other similar long life products, same story -- every time. The problem with those products with long life cycles is that they are "non-development oriented". They are closed cycle; they are dead, they are boring. The only reason they exist is to service an industry which feeds back money. The "wait until the meat falls off the bones" mentality in them is precisely what led many of us to work on these alive projects. Many of us waited decades for vendors to not fix the most obvious bugs, and eventually, we walked. There is only one way forward for legacy+new systems is to seriously step up the money and the people. Both. Not just one. So perhaps you are saying that too much life is a bad thing. I can see how there might be environments where that is true, but please keep those systems disconnected from the Internet, and nowhere near the systems that distribute power or other utilities to me. In fact, keep them away from systems that provide the power to the warehouses where my food ships through, or the aircraft I fly, or the traffic lights I drive near, or from my banks. Soon the places you can use such systems get rather small. > I do embedded work > and expect to maintain a system for decades without massive overhaul. I hope you don't hook them up to the net, because the Internet has changed substantially since 3.2 shipped. It is much more hostile because more people know how software breaks. Except you will hook them up to the net, because you think a 1-man team can keep up with this situation. Well, ok you don't believe that which is one reason why you are asking us. You can't keep up, so you wish to push the effort out to our project. We know that as a project we don't stand a CHANCE of dealing with the past and the future. And we aren't paid enough, either. > I chose obsd when it was at 3.2 for a project and have maintained it > with backports of fixes, missing functionality and other maintenance > tasks by browsing CVS and doing some original coding; I cannot afford > to change the O/S every six months to accommodate the latest release, and > if I pose questions to a list about some issue with older code, I am > usually ignored, so I am on my own. This wasn't always the case in > this business and it was expected that an O/S would have major releases > with ongoing simultaneous maintenance of previous releases for decades. Our team is small. We cannot stretch our team out to do that. There is just absolutely no business case for it; nor is it fun -- I doubt that it could be made fun. The volunteers do what they do because it is fun, sorry. > When I chose obsd, it was because of isakmpd and openssl and the bsd > heritage, as a bsd kernel was appropriate for the task (more than an > RTOS and less than the bloat of other *nix); I qualified the performance > for the chosen platform and expected that I could continue for years to > develop and refine the system, but soon discovered that I was outside of > the accepted paradigm. This is also true for other major projects (even > worse with Asterisk for example, and of course it has forked a number > of times due to various issues including dissatisfaction with the roadmap). You do realize that when you say we had isakmpd, you mean we had an IPSEC stack. You'd be stunned at the breakage we had to do to make that fit. And ipv6 caused grief again. The routing table has had to change to support the new fancy routing tables. It is all contingent. It simply is not possible to stay in the dark ages _and_ move forward. So you were running something which had just gone through *massive changes*, and yet, the minute we shipped it, we should stop that mentality, and maintain it for 5 years? Oh come on. > I need an O/S with certain core functionality designed for performance > on mature hardware, and to be expected to upgrade with each release would > only put in peril a stable system, especially when there are no published > performance benchmarks with each release (on all of the supported platforms) > to permit an analysis of the cost-benefit ratio to doing an upgrade. > Adding extra resource-consuming features is another concern, and there is > little data to permit a reasoned analysis on this score as well (for the > majority of large opensource projects). > > A modular approach to an O/S would be welcome; And a modular approach would be broken the very next day, by some developer who forgets that their nifty new kernel optimization which has some promise in the future, rather surpringly affects some minor code in a userland library. And then we would either have to decide to move ahead, or stay back. If I was getting paid money, I might for a few seconds accept such conundrums, but for free; heck no. Most developers come home from a day job to play in a space where movement forward is not impeded by "the past". When I impose pressure that some parts of the system should stay the same, you would be stunned at the difficulties I face. And we are OpenBSD a slow and steady project... > say a major version every five > years, with an a la carte menu of features, which are subject to versioning > and upgrade over that period, and maintenance of a stable set of APIs, ABIs > and configuration files over that same period. If some 'feature' package > requires a re-formulation of its APIs, then it could exist in parallel with > previous versions, and be maintained at least over the major release period. Which which army of volunteers would we do this... in a project that survives largely off donations and around 2000 CD sales a year? > Most importantly, the specific hardware targets of a new release (and their > minimum and optimal resource requirements) should be made clear so that there > is no confusion about the suitability of that release. This approach seems to > be rejected by the majority of contemporary opensource developers on large > projects, but has historically been crucial to any commercial systems > deployments. That is because the approach is impossible. You've done it for a few years. You've been paid, right? Can you imagine doing it for free, in your spare time? We're always looking for volunteers.. > I have little reason to expect any shifts in the paradigm here, but only > point out that if when major O/S products are a moving target, their adoption > is far less certain and less widespread. Depends who you are. When we look around the net, the only people running the old code are those who are getting paid to run old code. Almost everyone has come around to a new way of using code -- they run the code at the earliest possible moment they can, because then the developers of the code are still interested in fixing bugs in it. Therefore it becomes possible to run, test, and ship code before the developers have been distracted. This is the new paradigm. It is best to get used to it, I think. The only case where this probably does not apply is when there is a lot of money involved. But that is not the world we, as volunteers, live in. > I will continue to maintain and adapt 3.2 in the absence of reliable > performance > data for subsequent releases; I just wish that there was a 'version 3' obsd, > much like there is a 'version 3 MS-Windows', with known performance > characteristics > and resource requirements. Puleeseeeee. We don't need curmogeons around here.
