On Wed, Feb 02, 2000 at 10:03:26PM +0000, Terry Dawson wrote:
> I think you'll find they're happy to try out new application software,
> prior to it being released in their distribution, because most
> distributions have been very slow in embracing amateur radio. They just
Ok - I can't really comment here - I'm rolling my system on my own here
(_and_ on a not-so-common hardware: alpha AXP)
> don't want to be mucking about with kernels and base configuration
> utilities all the time.
Then don't install new software oll the time :-).
Seriously, I have a little opinion against 'plug-in-radio-amateurs' who
call for a service technician when thir microphone plug has a loose contact.
I think I apply this opinion to copiter issues, too ....
> > may be out there) to test each and every modification on them.
> No of course not. You've taken an extreme interpretation of what I've
> said.
Hmm - yes, intentionally. It should ask the question: Where do you draw
the borderline between to-be-supported and -obsolete-?
> > I think it's absolutely sensible, targetting for 2.4 or later, to intentionally
> > cut support for older kernels.
> > Look at the new ax25-tools: they _require_ glibc 2.1.x - because supporting
> > older libs is ugly and older libs don't provide funcionality the tools need.
> > If you already have glibc, then a new kernel is no problem!
>
> The decision to discontinue support for the older pre-glibc was an
> obvious one. Just about every new piece of software will be written to
> support glibc so users will be forced to upgrade anyway, but perhaps
> most importantly, because it is absolutely fundamental to *all* of
> Linux, not just amateur radio, the move is assured of happening
> relatively painlessly because all distributions will have strong
I wouldn't say painlessly. If you've managed to upgrade to glibc then
compiling and installing a newer kernel is _easy_.
(installing a newer all-in-one distro doesn't count here)
> incentive to support it. Such incentive doesn't exist for things like
> AX.25 utilities.
>
> All I'm really saying is that "sudden death" handovers always cause
> trouble. A period of overlap allows end-users the luxury of a small
> amount of time to work out what needs to be done to upgrade, with the
Well, that's true somehow. But as I understand from the discussion there
are some 'mutually exclusive' changes to be done.
> option of falling back to something that works in the interim.
It seems it's time to talk about what is actually wrong, why, and how
it can be done better. And when we have consensus here then DO it... :)
Thorsten
--
| Thorsten Kranzkowski Internet: [EMAIL PROTECTED] |
| Mobile: ++49 161 7210230 Snail: Niemannsweg 30, 49201 Dissen, Germany |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] |
