* Michael Grigoni <michael.grig...@cybertheque.org> [2009-04-30 19:51]: > I agree online threats change; my argument is for a stable core o/s, with > patches made for threat mitigation and stable API and ABI and configuration > within a major release number, to make life easier for small shops that > can't afford to shoot at moving targets all the time. I need to run on > old hardware, and reading the commits and changes scares me no end that > performance issues would cripple my systems if I continually 'upgraded'.
if you followed releases you would notice that APIs and even ABIs on OpenBSD are pretty damn stable. Exceptions exist, of course, but they are kinda rare. And as for performance... you'd notice old machines do not suddenly get slower over time. In a 10 year's scope, perhaps, when we accept more memory usage for performance, but not really on shorter terms. > Managing threats requires resources, and it should be up to the user to > understand and choose the solutions to threat management within the scope > of the hardware resources available to him. Performance data is often > lacking, so I take a conservative approach and backport what I need > and then test for stability and performance on my hardware. This approach > isn't much in evidence within obsd development, as Theo stated, it > doesn't 'excite' the developers, and of course mature hardware is often > no longer available to developers so support is dropped. we do not tend to drop support for hardware. happens for really really ancient stuff (>10years) from time to time, but even that seldom. if you spent your energy used for backporting and performance testing and whatnot on testing recent releases on your hardware you'd save a LOT of time and get a lot of goodies back in the process. > I had argued for a 'tiered' release structure, e.g. major releases which > are expected to run well on a certain class of hardware over a long term, our releases do that. > and minor releases which address bugs and online threats. No one expects > MS Windows XP to run at all on a 486/33 with 16MB RAM, but they do expect but OpenBSD does. even 4.5. might run into a little trouble with 16MB RAM, but even that is doable (might require a custom kernel) > Win98SE to do so, and indeed that o/s is still a viable product to many > people. and shouldn't be. > Some time ago I had posed performance questions in the openbsd-sparc lists > in hopes that I could get performance and resource data that could direct my > decisions regarding 'upgrades' on older sparc architectures; replies were > essentially along the lines of 'try it', which I guess in an open source > environment is a fair expectation, however on a rapid-release cycle, I > just cannot manage this. but you can manage backporting? hilarious. > Having profiling data on system calls, library functions, facilities like > 'pf', etc. for various architectures, updated on each release, would go a > long way towards permitting an objective analysis for upgrade decisions. nobody is stopping you from doing this really... > Certainly, when a release drops support for my hardware, that is a show > stopper right there and everything else is moot. you keep talking about dropping hardware support. what the hell are you referring to? > Newer isn't always better, and in tough economic times, and even for 'green' > reasons, I would argue for more attention to optimization for mature hardware. balony. I run OpenBSD 4.5 just fine on ancient hardware (and lots of more current hardware, of course) -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
