William Chivers wrote: > Hello, > > Thank you Theo and your team of developers for OpenBSD. > > Some people responding to the "European Orders" thread seem to have lost > sight of what OpenBSD is and who develops it. I am a bit of a newbie here > (although I have been using computers in my career since 1972)...
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. I do embedded work and expect to maintain a system for decades without massive overhaul. 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. 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). 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; 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. 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. 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. 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. Michael
