gnu-linux-libre
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU-linux-libre] upgrade often.. or not? (was: 100% Free Software T


From: Rubén Rodríguez
Subject: Re: [GNU-linux-libre] upgrade often.. or not? (was: 100% Free Software T-shirt design)
Date: Wed, 9 Jun 2010 20:16:49 +0200

> > Latest Puppy uses 2.6.33 and the latest xorg.
> 
> i'd love to update d:b to that, besides some other minor changes to be
> done and still pending, since it basically means more hardware
> supported. but there is a backward compatibility problem then:
> SquashFS 3.0 (as included in Linux now) is *not* backward compatible
> with SquashFS 2.0 archives, nor there is a "backport" patch to include
> that support at present time.

The squashfs module currently included in linux is 4.0, and is indeed
not backward compatible. But you should be able to upgrade the userland 
tool easily.

> hence, to upgrade beyond 2.6.18 for dyne:bolic ATM it would mean to
> drop compatibility with all the .dyne modules that users produce and
> freely exchange, while indeed one of the main features of our docked
> software bundling system is to have no central repository, but free
> exchange among users.

> what i think so far can be done to overcome this limitation is:
> - - make a squashfs 2.0 patch for Linux
> - - make a conversion utility for .dyne modules to recompress in SFS-3

Recompressing those modules is a matter of two or three commands, so it
looks like the way to go to me.

> - - don't touch anything really :) people find it a lot useful already

I can agree with this, I myself prefer stable software over new
features. My comment was just to point out that new kernels aren't
heavier, and an update shouldn't be avoided based on that assumption.

> considering i really value much the fact that users can rely on
> something to be compatible over time (let's say, that the OS is
> consistent over time) how do you think would be best to interact in
> such a situation? this is one of the main reasons keeping me away from
> touching d:b nowadays, after publishing an ALPHA release of
> 2.6.22-libre with squashfs-3 and noticing this problem.

Well, that's depends on the distro philosophy, some distros like to be
on the bleeding edge while others prefer very stable legacy pieces...

I'm guessing in any case you are patching the 2.6.18 kernel included
in d:b, otherwise it would include plenty of security holes. Also, such
a kernel is older than the first linux-libre. How was it cleaned?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]