Henning Brauer wrote:
* Michael Grigoni <michael.grig...@cybertheque.org> [2009-04-30 19:51]:
<snip>
we do not tend to drop support for hardware. happens for really really
ancient stuff (>10years) from time to time, but even that seldom.
In the context of this discussion, the hardware is about 17 years old.
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 certainly would like to do so; I hope circumstances permit it in the
near term for me.
<snip>
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.
For those facilities I require in my application, yes (kernel and pf). I don't
really want to have to reinstall an entire set of configs, utilities, libraries
etc. to get the benefit of a single (or few) changes, when I am constrained by
filesystem sizes, media types, and the performance considerations of utilities
which got changed but had nothing to do with the changes I sought in the kernel
or pf.
In this context I don't need a general-purpose platform (like FreeBSD, etc.) but
a very tightly-coded, lean, mean kernel for use in certain custom applications
;)
For the same reasons, I would strip down MS-Windows, OS/2, various SVR4, etc.
and have often resorted to enhancing an RTOS for my applications. Certainly
there
are commercial O/Ses which offer small footprints, well-documented profiling,
mature architecture support, etc., but again, cost is a large factor. 'MicroBSD'
was obviously an attempt to do this publicly but sadly didn't succeed.
Regards,
Michael
