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

Re: /tmp as tmpfs and consequence for imaging software

#1 Backup.  Why is supporting optional kernel features injected at runlevel S and not runlevel 3?

At runlevel 3, being optional, no one will care which is done. At runlevel S, before a login can fix things, it's a problem.

/tmp is legacy. You don't write history or future for others. What I mean is: /tmp is just a directory of convenience guarunteed to be there. If you want Gnome to cache orbit using shared memory - then using /tmp is not the way. configuring orbit is the way.

#2 I still don't think you offered proof that using LIMITED memory as a ramdisk for /tmp will outperform other uses of that memory.

And this sounds like NEWBIES will end up on a red-herring chase figuring out why they are getting tmp error messages and having to read about tmpfs to get their system up. NEWBIES have too much to handle already with installing and booting: far too much in my opinion.

>> so is really only misbehaving when misconfigured.

No. It's also misbehaving if MIS-USED by newbies. What new user knows to increase swap beyond what linuxdocs say and knows not to put files in /tmp ??? And me. I use /tmp for local scripts.

I saw some init scripts (was it ppp?) using / storing files in /dev/shm. I personally don't like the policy "any package alters ppp and disperses what it's doing widely across the system". and ppp scripts don't share memory why use /dev/shm ? !

it's a pain to check to see after each package installs if it has not badly altered ppp shell scripts to allow rooting the system in some way.

Reply to: