Re: node-like file conflicts
On Mon, 2012-08-06 at 16:15 +0100, Ian Jackson wrote: I'll double check the facts of course. If I have also see if I can understand the situation in each case well enough to make a recommendation. It seems at the very least that many of these issues are within a particular family of packages. Hopefully they won't mostly be as bad as node. It would also probably be good to distinguish between pairs that have the same binary name offering essentially the same semantics (e.g. crm and crm114) and unrelated binaries that happen to have the same name (e.g. lid and libuser). Also siggen is paired with itself in that list. Weldon -- 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/1344266645.9914.3.camel@skipjack
Re: node-like file conflicts
On Mon, 2012-08-06 at 17:39 +0200, Jakub Wilk wrote: No, the list is in format: D'oh. Thanks. I'll still see if I can tease out which of those are binaries trying to do the same thing and which are completely unrelated. Weldon -- 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/1344268000.9914.4.camel@skipjack
Re: Moving /tmp to tmpfs makes it useless
On Mon, 28 May 2012 13:03:47 +0200 Toni Mueller t...@debian.org wrote: It's not, see below. Also, most of the time, /tmp goes into / (on smaller systems), and is thus typically *very* much limited in space. If the theory is to design for the trained chicken install (and it still is, right?), then / gets the entire disk minus whatever gets assigned to swap. The sort of administrator who knows why she would want /home, /usr, and /var mounted separately can also be trusted to do whatever the right thing for her situation is with /tmp. HOWEVER, what's currently missing is the ability in the installer to put /tmp on / (AFAICT). Giving it a partition puts it on disk, not doing anything puts it on tmpfs. Yes, it's a single-line change to fstab on your first boot, but still. Over the past decade or so of writing one-off scripts I have (rightly or wrongly) formed the habit that /tmp is a 1777 area of disk where I can dump large things I don't want in memory at the moment (and therefore also a poor man's very asynchronous IPC domain -- yes, it's not supposed to be, but I think we'll also all admit we've done that at some point). Much better developers than me seem to have formed this opinion too (cf browsers' behavior while it waits for you to tell it what to do with an unknown content-type: it's a disk-based pipe to whatever program you pick to open it, except now it's a memory-based pipe, and I think /tmp on tmpfs is breaking those developers' expectations). We may be wrong, but apparently a lot of us don't yet trust the swapping algorithm to put the right stuff on disk yet. Also, I'd be more comfortable with tmpfs if it could be quota'd with standard quota tools. Having /var/run on a tmpfs may be a good idea, though. Gah! I want *somewhere* I can park stuff on disk. Why are people so against that? Can we at least keep /var/tmp? (But I'm more worried about /var filling up than /, personally.) And how many of these are we going to do? Right now on my Squeeze laptop I have /lib/init/rw, /dev/shm, and /tmp. Do we really need more things that look like on-disk directories but aren't? (Then again I'm still grumpy about sysfs.) Though actually /var/run makes more sense than /tmp, since it's pretty much just for pids and sockets. I request that the bug be tagged wontfix. Despite what I said above, I agree. The argument about web applications' session info is persuasive, and that's probably the hardest set of apps to change. As long as we are sure programs aren't dropping arbitrarily large files into it (I'm looking at you, Iceweasel...) and as long as there's *some* section of actual disk somewhere that's 1777. Also, this is rapidly approaching two sets of choir-preaching, so I'll bow out after this. Cheers, Weldon -- 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/20120528082652.f9a53baa.wel...@b.rontosaur.us
Re: Moving /tmp to tmpfs is fine
On Tue, 2012-05-29 at 12:15 +0800, Thomas Goirand wrote: What's the folder structure in /tmp then? /tmp/something/$USER? It's the Wild West over there. You'll often see something like /tmp/$procname/$pid/blah or /tmp/$procname/$user/blah, or just /tmp/$some_hash_of_who_knows_what/blah. FHS is uncharacteristically laconic: http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES Weldon -- 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/1338267368.2617.0.camel@minerva
Re: Moving /tmp to tmpfs makes it useful
On Fri, 25 May 2012 21:56:55 -0400 Ted Ts'o ty...@mit.edu wrote: The major difference is that tmpfs pages only get written out to swap when the system is under memory pressure. In contrast, pages which are backed by a filesystem will start being written to disk after 30 seconds _or_ if the system is under memory pressure. I still think the major difference is that page cache - ext2 can be quota'd while tmpfs - swap cannot (AFAIK; has that changed in the past couple of years?). This may be good or bad depending on your use case. And if you consider how much memory most desktop/laptops have, and how often people **really** are downloading multi-gigabyte files to /tmp (note that browsers tend to default downloads to ~/Downloads) Browsers write files to ~/Downloads (or ~/Desktop) *when the user selects Save As*. On Iceweasel and Chrome at least, if you click a link to a content-type the browser cannot natively display, it downloads it to /tmp while it's waiting for you to tell it what to do with it. These files can be arbitrarily large. Weldon -- 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/20120526073853.d0868690.wel...@b.rontosaur.us
Re: Moving /tmp to tmpfs makes it useless
On Fri, 25 May 2012 15:12:03 -0400 Nikolaus Rath nikol...@rath.org wrote: Weldon Goree wel...@b.rontosaur.us writes: If only ext*fs supported quotas... Aren't quotas only for non-root and per file system? I think we're already safe from non-root filling up / because of the reserved 5%. Yes, but I was thinking of a multi-user install (that being, after all, what I administer for a living). I like the ability to keep ~fred and ~joe from locking each other out of /tmp (yes, there are ways to do that with tmpfs, but I have to think about them, unlike quotaing a normal filesystem). Then again, with virtualization the days of multiple-interactive-user installations may be coming to an end. Cheers, Weldon -- 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/20120526082230.f450dc45.wel...@b.rontosaur.us
Re: Moving /tmp to tmpfs makes it useless
On Fri, 2012-05-25 at 10:02 -0400, Nikolaus Rath wrote: I think having / and /tmp share the same file system is a bad idea, because then writing lots of stuff to /tmp would potentially fill up the root file system (that typically also includes /var) and then cause a lot of breakage. If only ext*fs supported quotas... (Snark aside, does tmpfs support quotas yet/will it ever?) Weldon -- 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/1337967711.26842.3.ca...@minerva.trit.us
Re: RFC: OpenRC as Init System for Debian
On Wed, 2012-05-09 at 21:57 +0800, Patrick Lauer wrote: Why this arbitrary limit to only one application? http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3chap=4 Something along those lines makes life a lot easier and avoids these schizophrenic hacks around package managers that don't respect files - but it needs support in the package manager to work reliably. Years ago I nearly had a heart attack when I saw the following output from etc-update: Merging trivial changes to fstab Doesn't Arch have a setup where foo.conf includes foo.conf.local (or conf.d/foo, or something; I get frustrated with Arch about 2 minutes after booting, usually) for anything the user edits? Personally I'd rather have a set of files that I know the distribution may blow away at any moment and a separate set of files that I know the distribution will never alter. I get that a change to the semantics of a configuration file may require user-altered stuff to change, but even dispatch-conf doesn't help with that. Weldon -- 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/1336574157.3040.20.ca...@skipjack.trit.us
