07/01/11 17:58, intrigeri: > Hi, > > anonym wrote (06 Jan 2011 15:36:49 GMT) : > >> If we're already approaching the 700 MB limit, perhaps we should >> look into a lighter DE than Gnome? > > I'd rather not to, for several reasons: > > 1. Probably thanks to Ubuntu's popularity, lots of users are somehow > used to GNOME and would need to re-learn non neglictible amounts of > practical knowledge. > > 2. My intuition tells me GNOME offers us a great bunch of useful > functionality; I fear we would slowly realize this (and need to fix it > bits after bits) if we switch to something lighter, everytime users > complain for disappeared functionality. On the other hand I must admit > I have not tried e.g. XFCE recently, and it might now have most of > GNOME features we care about. I would be happy to stand corrected on > this one. > > 3. This seems like a very radical change, with important consequences > both on usability and developement resources. I am not sure it would > be worth it since: > - we are currently only slightly above 700MB => we probably can > manage to workaround this issue for the lifetime of Debian Squeeze > without coping with such a big change > - when Debian Squeeze+1 = Wheezy is published (statistically: ~1st > quarter 2013), bundled software size is likely to have increased > again, and even using a lighter DE will probably not bring images > size back under 700MB > - when Wheezy is published, we might be in a position to reasonnably > target DVD and USB rather than CD.
Fair enough. >> 1. Let's clear out /var/lib/apt/lists (except the sub-dir called >> "partial", which can be left empty). That's 60 MB in T(A)ILS 0.6.1. > > This seemed like the lower hanging fruit => done in devel branch. > >> That makes it annoying to install new software though since one has >> to "apt-get update" before. > > Yep. It will mostly annoy... ourselves I guess. I very frequently need > to do so while developing T(A)ILS. Therefore it might be a good compromise to only do this for final releases and perhaps the later rc:s. I suppose all (?) of us use virtual machines for testing, so larger images are not problematic at these stages. >> If we choose to do this, perhaps this directory is another candidate >> for being persistent once that has been implemented? > > Sure. > >> 2. One thing I cleared in Incognito for additional space was >> /usr/share/doc, which in T(A)ILS 0.6.1 amounts to another 66 MB. One >> possible legal problem with this is that licenses usually reside there, >> and I guess most licenses require them to be shipped with any binary >> distribution. Parhaps we could have a script which re-names them >> appropriately and puts them in a licences subdir? E.g. >> /usr/share/doc/tor/copyright --> /usr/share/doc/licences/tor-copyright, etc. > > I'd like to go on shipping documentation (other than manpages) for the > bundled software, for usability reasons. Why not, if we have no better > choice... but it seems Alan suggested less drastic ways to lower > images size. We'll see. I agree that the documents in /usr/share/doc can be useful, but I think we can assume that _very_ few of our users will ever look in there. Also, this documentation can in most cases be found easily on the internets any way. >> > I suppose that translates to about half when compression is taken >> > into account. > > The average compression ratio (rootfs -> squashfs) is rather 1:3. For the record, I ran a simple test (in 0.6.1) using gzip to see how my two suggestions turned out: * /var/lib/lists reduced massively, from 60 MB to just 16 MB (lots of redundancy in there apparently). This makes me question a bit if it's worth the additional hassle of having to apt-get update. * /usr/share/doc reduced from 66 MB to just 51 MB. After all, most large files in there are already compressed. For instance, there are 36 MB worth of _gzipped_ changelogs, which I must admit I find of doubtful practical usage for the end user. Well, let's think of fiddling with /usr/share/doc as a last resort. Cheers!
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tails-dev mailing list [email protected] https://boum.org/mailman/listinfo/tails-dev
