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

[jaromil]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

hi Ruben,

On Wed, Jun 09, 2010 at 08:16:49PM +0200, Rub�n Rodr�guez wrote:

> 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.

sure, still the kernel module is needed to mount partitions (oh and
BTW, i wonder why there isn't a FUSE module for older versions, that
would be really backward compatible...)

> > 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.

yes, but people still will have to do it. not trivial. and modules
will be around without a versioning number on their filename to clear
things up... i start trembling when i think of these things.

> > - - 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.

sure, as yet another avid reader of code and changelogs, you can bet i
know how Linux is proceeding :) not as much as everyone here, but that
much that suffices to actually desire an update myself.


so now i add another solution to this riddle:

- - have FUSE modules for squashFS 2 and 3 backward compat.

> > 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...

... and some both :)

let's say d:b hasn't such a big core developer community, so we keep
"stable legacy" as a unique goal for now. one could consider pure:dyne
an experimental branch, indeed.

> 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.

right.

> How was it cleaned?

with "oil of elbows", as an Italian adagio says :) early blob
detections scripts from Jebba and stuff like that.

actually the update to a stable linux-libre is a major reason to have
a new release on our side, possibly with good RT patches (who else is
doing that after Kon Kolivas left?) ... now i think of it, it should
be higher on my agenda. its just that coding FreeJ and some other
software devel to pay the day has taken most of the time...

ciao


- --
jaromil, dyne.org developer, http://jaromil.dyne.org

GPG: B2D9 9376 BFB2 60B7 601F  5B62 F6D3 FBD9 C2B6 8E39
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQQcBAEBCAAGBQJMD+iXAAoJEAslGzkIl3JR4nwgAILJCbYqH1bc/2fYp4y90+s2
n0NWfupZL4p0fcMhgK1toYoAIMwaopUVsvYTETjBXfbk6XKrk9hZw1ebK6Dd/cTX
TKf0WLmejJ8zbPqzSIA6GPf5Yxh7dPLK791ukGMu8MJcXIwV7+iZN81FYooMRrjI
PKbzSMitey9ad0AFNZCfDOySLocX84RMpgq6yMdqmMSJePuGgQu36ikw5hA4nTjZ
hPRBheXo6PmOWrQkiE0qhXgTyYy5bY4/cOs42p4g+8v4F/RkPHFU0sLlsz6oA6iK
9Z/2JUEkLMoHZJTX8+kTkIGnDzgmZBREqaCb9nmYNTS8Er5uNjdJKmrVx0T6JFot
qtbE5uuSSUqaTcAhNiOxzJUmPyMqo22CoqMAOxdSsNOH3gcSK95PUtVRCimeGfin
zNXFSDrJcksw5WVqCjS02AJ98kxrQzom4cv3Q/kjoHVTOPtaOB9WE8XRkzwNbkHK
i7EDkjVIQjvxU99YOBtNJfix2y1JlKXki175VOVOzFqKy+1t2GIKEaUJpe+BLOfD
n+GXwhd0X+ysKH+guaJDVFB3ROhYRIlJmK328NO8nQE3NwnmgmRrf3GRyofye/sP
RYTV98jSEf91CSfyhCXWbm+94m2d5PfLNyAM7PjGUp2Iu/lEm6KWvBQ49e/rZKuT
ssETuQg4pxveIVhql2g3/0FBY7GPbQ6v0u6oEKLBz5iv+dvBqVYLPcP2UJON9gHg
wiNri8swGSEPCSYBTx9AmoHYcmE69aLtxl5OH0ocC/SWFRPQwG8J5HDRSrfA8ouZ
2ljvn5aEvCyMVG4MZ19GmFPjGc7KU05tZD10vvTRPiy7fw4DWGizJ7scGUPhagvT
D4sEni8gvzanzSj6mhvLRG5sAGaWectrjSMT/+XtC2gchaYKhYZvCJ8IiSryPCWP
QxHPSG0XQh3yZNp8R8psPPKj02M4mB+vHH4g2CSDwBRNjkoDYxFG/NCv1M8lSRvv
QFMvyM4w9s/6Pk/IdSKOHJWUiWkvVFFerQP5vd+Zy+dSFCu+uSXME7Kwt6SF2Ul3
jTacVvA+75v2HdGM7xCL5cy9qoFROrN7/7v5+SkGo6cpJE94JxdoY69lI8tVWWwT
LN0hhjtb0awirbdI0MJQLb7MkzMPvN4BQ8JSyyrX/NfG8bHQjIlyCJo2+zbE/Nrv
ZktknQlXrcktFbvPNt8EYmrPlhYXP0FIo5ZPQMx7uUTAr7NpX6bXVYJHuxCJLdlc
9ROIKgrru2WDo1qPqozOXPmGivOLzdWGnXt8hBH7PJP6mxSGk6iQixc1R+Ty9Ah6
CSMF83N3QffDyss7h2r9MShfc8H3H4YfeeVcCBMZLwvVoik/W5txHj010OXP6SM=
=ajtx
-----END PGP SIGNATURE-----