On Sat, May 26, 2012 at 06:59:35PM +0100, Wookey wrote: > I hesitate to prolong this thread further, but I do have a couple of > data points. (and couldn't let Neil's nonsense go). > > +++ Neil Williams [2012-05-25 16:15 +0100]: > > > So instead of fixing the defaults you suggest everybody to drop the > > > programs they use (mc, firefox, mysql)? ;) > > > > On machines which don't have the resources for those programs, yes. > > There are alternatives out there - change to a less hungry program or > > expand the hardware. > > The idea that there are machines without the resources for mc is > silly. It's a very low-resource console-based program. > > But there is this issue of the way its vfs does temporay unpacking in > /tmp. That makes sense in the 'this is temporary, it should go away on > reboot' sense, but some big files will use up a lot of ram when /tmp > is tmpfs. > > I don't know what the right thing to do about this is, but the 'set > TMPDIR' sugestion is useless IMHO. When I start mc I have no idea what > things will be unpacked under the VFS over the next days/weeks. I > don't want _everything_ to go in /var/tmp and not get cleaned up > automatically (is there cron job that does this for old files?) > > Perhaps mc should get clever and change TMPDIR itself on the fly for > large files, but I don't know how practical that is.
Or, it should get clever and not unpack everything. There are plenty of software that are able to read into archives without extracting from them. There are even fuse filesystems to do that if it doesn't want to do it itself. Using a temporary directory, be it on disk or in RAM, is *always* going to be a limitation. As a matter of fact, i remember some virtualization solution (vserver or lxc, i think) that gave me a 16MB /tmp by default. It doesn't matter if it's on disk or in RAM at this point. If mc is going to try to unpack a kernel archive in there, it's going to blatantly fail. Yet, there's no excuse for it to not do better. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120526185205.ga24...@glandium.org
