Gavin McCullagh wrote:
On Mon, 09 May 2005, Herman Robak wrote:
Most of the software packages don't have to track new hardware. Even if it's old, it will still work. However, the installer, the kernel and X will often simply not work on newer hardware.
Could we agree on a small infrastructure, like the installer, the kernel and X? And maybe a few more libraries and daemons that communicate directly with the hardware? "Base + drivers"?
This is an interesting idea. I think keeping up with hardware is an important problem with the long release cycle.
Another is interoperability. The first example that comes to mind is
OpenOffice. It seems to be a thing that many people use backports of, I
know I do. I don't know when OpenOffice 2 will be out but (leaving aside
the JRE issues for a moment), it is a substantial improvement in
interoperability with Microsoft Office[1] and certainly won't ever be in
sarge. I imagine there will be others from time-to-time.
Would it be at all possible for a semi-official debian-edu/skolelinux backports archive to exist for this? They needn't be on the install cd but they would be a set of important upgrades which were regularly needed and would not change often at all. Right now it would be nice to have OOo 1.1.4 for example. Given that there would only be a small number of packages hand-picked by skolelinux/debian-edu developers, it might be more feasible to ensure that upgrades worked for machines with the vanilla system and those with a few extra backports. A few guidelines/rules could be devised to stop the number of packages getting out of hand.
This aproach would not help us keeping up with hardware, just some programs. How should we solve the hardware-problem?
Markus
Perhaps this would add too much work, I'm not sure.
Gavin
[1] Indeed it is also better than v1 at rescuing corrupted Word docs as I have had to do several times on a friends thesis :-)
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
