[gentoo-dev] Concerns about WIPE_TMP change

[gentoo-dev] Concerns about WIPE_TMP change

[Stefan de Konink]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello,


I joined this mailinglist because of my concern pointed in:

http://bugs.gentoo.org/show_bug.cgi?id=206604


How stupid anyone could be that stores anything in /tmp. I think it is a
problem to change the default behavior of a system that in essence will
result in data loss.

As pointed out by others you should not use /tmp to store data, my
return question is then, why are the other ./tmp directories not wiped?
If any ./tmp on a partition was 'kernel' governed I could agree that a
semi-ramdisk would be gone upon reboot, or after an application was done
running. But it is not.


In any case my request would be to put a message with bells and beeps in
the ebuild that cause the /etc/conf.d/bootmisc change announcing that by
then the default option for /tmp is deletion on boot. To be consistent,
also delete /var/tmp. If anyone thinks wiping /var/tmp is evil, please
reconsider /tmp too. In my opinion WIPE_TMP should be in the same state
as RC_PARALLEL_STARTUP. Unless anyone can make sure a user knows what he
is doing, disable it.



Yours Sincerely,

Stefan de Konink

ps. No I did not have data loss, like any good admin I read before I
apply. And yes I prefer to store anything that will not cause harm, such
as extracted sources for gdb use in /tmp.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHkVb/YH1+F2Rqwn0RCsK4AJ4wEQPC5MrCrZdIEzKIjJkh+pKNoQCfX1BG
alIrUmXiM2kulk3p635PiZk=
=57tK
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Concerns about WIPE_TMP change

[Mark Loeser]

[-- Attachment #1: Type: text/plain, Size: 2153 bytes --]

Stefan de Konink <skinkie@xs4all.nl> said:
> How stupid anyone could be that stores anything in /tmp. I think it is a
> problem to change the default behavior of a system that in essence will
> result in data loss.

I think this might just be a communication problem.  You seem to be
contradicting yourself here by saying how someone could be stupid for
storing something, and then defending people that are doing something
you are admitting to be stupid and not logical.

> As pointed out by others you should not use /tmp to store data, my
> return question is then, why are the other ./tmp directories not wiped?
> If any ./tmp on a partition was 'kernel' governed I could agree that a
> semi-ramdisk would be gone upon reboot, or after an application was done
> running. But it is not.

Because according to the FHS (and common sense), files or directories in
/tmp should not be considered to be preserved.  /var/tmp on the other
hand is specifically for temporary files that should be preserved
between reboots.


> In any case my request would be to put a message with bells and beeps in
> the ebuild that cause the /etc/conf.d/bootmisc change announcing that by
> then the default option for /tmp is deletion on boot. To be consistent,
> also delete /var/tmp. If anyone thinks wiping /var/tmp is evil, please
> reconsider /tmp too. In my opinion WIPE_TMP should be in the same state
> as RC_PARALLEL_STARTUP. Unless anyone can make sure a user knows what he
> is doing, disable it.

Please refer to my explanation above as to why /var/tmp is different
from /tmp.

Should an elog statement been put into the ebuild...maybe.
I leave that up to the maintainer to decide what is important enough to
be logged, and they clearly thought this wasn't in this case.  But
bringing it up on this mailing list is atleast the correct place to get
a discussion going on what should be mentioned when we change default
configurations if that is your intention.

Thanks,

-- 
Mark Loeser
email         -   halcy0n AT gentoo DOT org
email         -   mark AT halcy0n DOT com
web           -   http://www.halcy0n.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Concerns about WIPE_TMP change

[Richard Freeman]

Mark Loeser wrote:
> 
> Should an elog statement been put into the ebuild...maybe.
> I leave that up to the maintainer to decide what is important enough to
> be logged, and they clearly thought this wasn't in this case. 

I think that this would probably warrant an elog.  Sure, anybody who 
knows the "correct" way to admin unix doesn't put anything important in 
/tmp - but educating our users before blowing away their data isn't a 
bad thing.  We shouldn't assume our users are idiots, but this is an 
obscure enough piece of admin knowledge that I think that users will be 
impacted by the change.

Doesn't impact me one way or another - in my case both /tmp and /var/tmp 
are tmpfs filesystems.  However, I do have a few longer-duration "temp" 
folders on my system that get cleaned by tmpreaper but is used for stuff 
that is nice to keep around a little longer.
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Concerns about WIPE_TMP change

[Duncan]

Richard Freeman <rich0@gentoo.org> posted 4791F359.1050500@gentoo.org,
excerpted below, on  Sat, 19 Jan 2008 07:55:53 -0500:

> I think that this would probably warrant an elog.  Sure, anybody who
> knows the "correct" way to admin unix doesn't put anything important in
> /tmp - but educating our users before blowing away their data isn't a
> bad thing.  We shouldn't assume our users are idiots, but this is an
> obscure enough piece of admin knowledge that I think that users will be
> impacted by the change.

Obscure?  It's the directory name (says another with both /tmp and /var/
tmp on tmpfs).  How much less obscure can you get than announcing it 
every time the path is referenced or specified?  Who could reasonably 
argue that tmp doesn't mean tmp?

Never-the-less, an elog wouldn't hurt, and the implementation cost is 
pretty low as well, so I'd say just elog it.  That way, there's two 
warnings to point to instead of just one (the name of the dir), for the 
inevitable complaints.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Concerns about WIPE_TMP change [offtopic]

[Stefan de Konink]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Duncan schreef:
> Richard Freeman <rich0@gentoo.org> posted 4791F359.1050500@gentoo.org,
> excerpted below, on  Sat, 19 Jan 2008 07:55:53 -0500:
>
> Obscure?  It's the directory name (says another with both /tmp and /var/
> tmp on tmpfs).

...very offtopic but how are you all compiling stuff like firefox on a
ram disk. Or is 8GB of ram very cheap suddenly?


Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHkoUjYH1+F2Rqwn0RCiGcAKCFWHbUfmXHA6OJ47owQ23ACpfMFwCfVqFf
tQ5D4kN+U2Oxs8WjaCl8FP0=
=5UKn
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Concerns about WIPE_TMP change [offtopic]

[Alec Warner]

On 1/19/08, Stefan de Konink <skinkie@xs4all.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Duncan schreef:
> > Richard Freeman <rich0@gentoo.org> posted 4791F359.1050500@gentoo.org,
> > excerpted below, on  Sat, 19 Jan 2008 07:55:53 -0500:
> >
> > Obscure?  It's the directory name (says another with both /tmp and /var/
> > tmp on tmpfs).
>
> ...very offtopic but how are you all compiling stuff like firefox on a
> ram disk. Or is 8GB of ram very cheap suddenly?

8gb is very cheap.

But who compiles firefox? :)

>
>
> Stefan
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHkoUjYH1+F2Rqwn0RCiGcAKCFWHbUfmXHA6OJ47owQ23ACpfMFwCfVqFf
> tQ5D4kN+U2Oxs8WjaCl8FP0=
> =5UKn
> -----END PGP SIGNATURE-----
> --
> gentoo-dev@lists.gentoo.org mailing list
>
>
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Concerns about WIPE_TMP change [offtopic]

[Stefan de Konink]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Alec Warner schreef:
>> But who compiles firefox? :)

Probably everyone that noticed that the segmentation faults coming from
the precompiled versions are annoying?


Stefan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHkpfdYH1+F2Rqwn0RCjLoAJ9dA6BN/2011ed1IFZ9aabPqoRtFQCeJAsF
w8Pf3sgIwIyDQwQNY/O6t10=
=PqIa
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Concerns about WIPE_TMP change [offtopic]

[Duncan]

Stefan de Konink <skinkie@xs4all.nl> posted 47928523.2080203@xs4all.nl,
excerpted below, on  Sun, 20 Jan 2008 00:17:55 +0100:

> ...very offtopic but how are you all compiling stuff like firefox on a
> ram disk. Or is 8GB of ram very cheap suddenly?

Well, tmpfs is swap-backed if necessary.  That's one of its strengths.  
And no, 8 gig of at least registered memory (what my Opterons use) isn't 
cheap -- I paid >$1000 for mine a year or so ago, but it sure is nice, 
combined with a dual dual-core system (Opteron 290s, upgraded ~4 months 
ago from 242s).

MAKEOPTS="-j20 -l12" keeps things from getting too out of hand.  It'll 
sometimes use 3 gigs or so of app memory (and about the same tmpfs it 
appears), but not too bad.  I ran -j (unlimited jobs) for awhile, and 
it's fun to see the jobs climb to several hundred, but even with 16 gigs 
4-way striped swap, the system goes draggy at that and >10 gigs into 
swap.  Keeping it to ~12 jobs means responsiveness stays reasonable, at 
least with the new 2.6.24 user based scheduling and the portage user kept 
to the same or half the share of my regular user.  Swap seldom gets used, 
and if it does, it's only a few megs of the apps I don't use much anyway 
(/proc/sys/vm/swappiness set to 100 so it flushes apps, not cache, to 
swap, as apps and the main system are on raid-6 so only two-way striped 
while swap is 4-way striped).

Nice system to run Gentoo on. =8^)  Using ccache, recompiling the updated 
kde4-svn daily is only ~2 hours or so, during which the system remains 
pleasantly usable. =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Concerns about WIPE_TMP change [offtopic]

[Richard Freeman]

Stefan de Konink wrote:
> ..very offtopic but how are you all compiling stuff like firefox on a
> ram disk. Or is 8GB of ram very cheap suddenly?
> 

Swap is your friend.  The performance hit is the same as what you'd get 
compiling on disk if pages need to be swapped out.  The performance is 
of course far superior for any pages that don't need to be swapped out. 
  The big clean at the end is of course MUCH faster in a ram-disk.

The beauty of tmpfs is that it performs no worse than disk in the worst 
case, and in the case of short-lived files it performs far better.  If 
you write, use, and delete a file on disk (more than a few seconds 
apart) the kernel actually takes care to sync everything as if you cared 
about the file 10 minutes into the future.  The kernel can also be far 
more opportunistic with how it swaps pages compared to how it flushes 
buffers - since there is a general understanding that when you write to 
a file you care about being able to read it back in a few days.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Concerns about WIPE_TMP change [offtopic]

[Caleb Cushing]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

On Jan 20, 2008 8:43 AM, Richard Freeman <rich0@gentoo.org> wrote:

> Stefan de Konink wrote:
> > ..very offtopic but how are you all compiling stuff like firefox on a
> > ram disk. Or is 8GB of ram very cheap suddenly?
>

not to mention, last time I checked open office only required ~2GB of space
to compile and it takes more than firefox. Most apps can be done in less
than 512MB

-- 
Caleb Cushing

I currently only check my email once or twice a week, due to lack of
internet in home. I apologize for the inconvenience

[-- Attachment #2: Type: text/html, Size: 816 bytes --]

Re: [gentoo-dev] Re: Concerns about WIPE_TMP change [offtopic]

[Philip Webb]

080121 Caleb Cushing wrote:
> last time I checked open office only required ~2GB to compile

OO 2.3.1 needed  3,25 GB  here, which was less than in the past IIRC.
You're correct that that is far more than any other pkg needs.

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Concerns about WIPE_TMP change [offtopic]

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

On Mon, 2008-01-21 at 20:34 -0500, Caleb Cushing wrote:
> On Jan 20, 2008 8:43 AM, Richard Freeman <rich0@gentoo.org> wrote:
>         Stefan de Konink wrote:
>         > ..very offtopic but how are you all compiling stuff like
>         firefox on a
>         > ram disk. Or is 8GB of ram very cheap suddenly?
> 
> not to mention, last time I checked open office only required ~2GB of
> space to compile and it takes more than firefox. Most apps can be done
> in less than 512MB

The largest abuser of space in the tree that I am aware of is
games-fps/ut2004-data which weighs in at nearly 7GB to install.  I'm
pretty sure that games-strategy/nwn-data is pretty close with USE="hou
sou" enabled.  ;]

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: Concerns about WIPE_TMP change

[Olivier Galibert]

On Sat, Jan 19, 2008 at 10:18:35PM +0000, Duncan wrote:
> Richard Freeman <rich0@gentoo.org> posted 4791F359.1050500@gentoo.org,
> excerpted below, on  Sat, 19 Jan 2008 07:55:53 -0500:
> 
> > I think that this would probably warrant an elog.  Sure, anybody who
> > knows the "correct" way to admin unix doesn't put anything important in
> > /tmp - but educating our users before blowing away their data isn't a
> > bad thing.  We shouldn't assume our users are idiots, but this is an
> > obscure enough piece of admin knowledge that I think that users will be
> > impacted by the change.
> 
> Obscure?  It's the directory name (says another with both /tmp and /var/
> tmp on tmpfs).  How much less obscure can you get than announcing it 
> every time the path is referenced or specified?  Who could reasonably 
> argue that tmp doesn't mean tmp?

Tmp has never meant "erase at restart", because restarts are often not
predictable.  Tmp has sometimes meant things like "erased after a
week", or "erased when space gets low", but never "erased after
restart" which is just unusable.

Frankly, if I'm writing a long email (which mutt stores in /tmp) and a
powerloss makes it gone even if I was saving it from time to time
while I was writing it, I'll get annoyed.  Severely annoyed.

It's just another bug of the FHS that shoule be ignored.

  OG.
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Concerns about WIPE_TMP change

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

Olivier Galibert wrote:
> Tmp has never meant "erase at restart", because restarts are often not
> predictable.  Tmp has sometimes meant things like "erased after a
> week", or "erased when space gets low", but never "erased after
> restart" which is just unusable.

 >> POSIX wrote:

/tmp
     A directory made available for applications that need a place to create 
temporary files. Applications shall be allowed to create files in this 
directory, but shall not assume that such files are preserved between 
invocations of the application.


> Frankly, if I'm writing a long email (which mutt stores in /tmp) and a
> powerloss makes it gone even if I was saving it from time to time
> while I was writing it, I'll get annoyed.  Severely annoyed.
> 
> It's just another bug of the FHS that shoule be ignored.

The only one you would have to get annoyed at is yourself.  Every spec out there 
says you don't store persistent info on /tmp.  Use /var/tmp if you want to keep 
things between boots.  That's why it's there. :P

-- 
fonts,                                            by design, by neglect
gcc-porting,                              for a fact or just for effect
wxwindows @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Concerns about WIPE_TMP change

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]

On Saturday 19 January 2008, Olivier Galibert wrote:
> On Sat, Jan 19, 2008 at 10:18:35PM +0000, Duncan wrote:
> > Richard Freeman <rich0@gentoo.org> posted 4791F359.1050500@gentoo.org,
> > > I think that this would probably warrant an elog.  Sure, anybody who
> > > knows the "correct" way to admin unix doesn't put anything important in
> > > /tmp - but educating our users before blowing away their data isn't a
> > > bad thing.  We shouldn't assume our users are idiots, but this is an
> > > obscure enough piece of admin knowledge that I think that users will be
> > > impacted by the change.
> >
> > Obscure?  It's the directory name (says another with both /tmp and /var/
> > tmp on tmpfs).  How much less obscure can you get than announcing it
> > every time the path is referenced or specified?  Who could reasonably
> > argue that tmp doesn't mean tmp?
>
> Tmp has never meant "erase at restart", because restarts are often not
> predictable.  Tmp has sometimes meant things like "erased after a
> week", or "erased when space gets low", but never "erased after
> restart" which is just unusable.

dont know where you get this "unusable" business from.  ive never had a 
problem with it and ive been using WIPE_TMP since i introduced it which has 
been over a year (maybe two or three).  nor has it been a problem for 
everyone who mounts /tmp as a tmpfs.  nor anyone else who uses /tmp 
correctly.

> Frankly, if I'm writing a long email (which mutt stores in /tmp) and a
> powerloss makes it gone even if I was saving it from time to time
> while I was writing it, I'll get annoyed.  Severely annoyed.

i dont know what sort of magic you think is going on behind the scenes.  there 
is no guarantee that mutt will write every byte after you type it, flush the 
I/O buffer, and make sure it gets synced to the disc.  or that the kernel has 
actually synced it to the disk.  or that the disk has actually written it out 
of its own I/O buffer to the drive.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Re: Concerns about WIPE_TMP change

[Richard Freeman]

Duncan wrote:
> 
> Obscure?  It's the directory name (says another with both /tmp and /var/
> tmp on tmpfs).  How much less obscure can you get than announcing it 
> every time the path is referenced or specified?  Who could reasonably 
> argue that tmp doesn't mean tmp?
> 

Anybody who comes from the world of Windows - where temp directories 
aren't cleaned and usually eventually grow to 1/3rd of the disk on a 
typical spyware-laden install?

You and I know what /tmp is for, but we also know that we shouldn't be 
running as root all the time and yet I'm sure there is a note in the 
install handbook about that.  95% of new linux users come from Windows, 
and as such they have a few bad habits that they'd probably be all to 
happy to lose if somebody takes the time to point them out.

In any case, an elog should solve the problem...
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Concerns about WIPE_TMP change

[Fabian Groffen]

On 20-01-2008 08:47:26 -0500, Richard Freeman wrote:
> You and I know what /tmp is for, but we also know that we shouldn't be 
> running as root all the time and yet I'm sure there is a note in the 
> install handbook about that.  95% of new linux users come from Windows, and 
> as such they have a few bad habits that they'd probably be all to happy to 
> lose if somebody takes the time to point them out.

On Solaris /tmp is mounted on your swap, so you don't want to write
large/many files there (e.g. unpacking source tars).

> In any case, an elog should solve the problem...

Mike already added an elog, so it's done.

-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Concerns about WIPE_TMP change

[Donnie Berkholz]

On 08:47 Sun 20 Jan     , Richard Freeman wrote:
> Duncan wrote:
>> Obscure?  It's the directory name (says another with both /tmp and /var/
>> tmp on tmpfs).  How much less obscure can you get than announcing it every 
>> time the path is referenced or specified?  Who could reasonably argue that 
>> tmp doesn't mean tmp?
>
> Anybody who comes from the world of Windows - where temp directories aren't 
> cleaned and usually eventually grow to 1/3rd of the disk on a typical 
> spyware-laden install?
>
> You and I know what /tmp is for, but we also know that we shouldn't be 
> running as root all the time and yet I'm sure there is a note in the 
> install handbook about that.  95% of new linux users come from Windows, and 
> as such they have a few bad habits that they'd probably be all to happy to 
> lose if somebody takes the time to point them out.

Just one other point here. 95% of new Linux users is not 95% of new 
Gentoo Linux users.

Thanks,
Donnie
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Concerns about WIPE_TMP change

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

On Sunday 20 January 2008, Donnie Berkholz wrote:
> On 08:47 Sun 20 Jan     , Richard Freeman wrote:
> > Duncan wrote:
> >> Obscure?  It's the directory name (says another with both /tmp and /var/
> >> tmp on tmpfs).  How much less obscure can you get than announcing it
> >> every time the path is referenced or specified?  Who could reasonably
> >> argue that tmp doesn't mean tmp?
> >
> > Anybody who comes from the world of Windows - where temp directories
> > aren't cleaned and usually eventually grow to 1/3rd of the disk on a
> > typical spyware-laden install?
> >
> > You and I know what /tmp is for, but we also know that we shouldn't be
> > running as root all the time and yet I'm sure there is a note in the
> > install handbook about that.  95% of new linux users come from Windows,
> > and as such they have a few bad habits that they'd probably be all to
> > happy to lose if somebody takes the time to point them out.
>
> Just one other point here. 95% of new Linux users is not 95% of new
> Gentoo Linux users.

another point: i dont think ive ever met anyone who even knew what the Windows 
temp directory was or even how to find it.  no one relies on that directory 
to manage their files.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

[gentoo-dev] Re: Concerns about WIPE_TMP change

[Duncan]

Mike Frysinger <vapier@gentoo.org> posted
200801210005.29587.vapier@gentoo.org, excerpted below, on  Mon, 21 Jan
2008 00:05:29 -0500:

> another point: i dont think ive ever met anyone who even knew what the
> Windows temp directory was or even how to find it.  no one relies on
> that directory to manage their files.

Well, you've (virtually, anyway) met one now.

Back when I ran on MS, I always made it a point of setting both TMP and 
TEMP to a dedicated temp partition, a practice that saved my *** at least 
once, during the IE4 betas when MS pulled a trick that had people ending 
up with IE's cache index crosslinked with multiple other files, costing 
folks various documents and/or drivers, etc (there were reports of both) 
in the process.  Since I'd decided IE's cache was temp data and had it on 
my temp partition (along with TEMP/TMP), the only data it could corrupt 
was other temp files. =8^)

Of course, the other advantage of a separate temp partition was that in 
the event of a crash, the only files generally open were temp files, 
thus, the only partition that generally had to be scandisked was the 
relatively small and quickly scanned temp partition. =8^)

So such people are out there...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Concerns about WIPE_TMP change

[Roy Marples]

On Sat, 2008-01-19 at 02:48 +0100, Stefan de Konink wrote:
> In my opinion WIPE_TMP should be in the same state
> as RC_PARALLEL_STARTUP.

That's a fair point.

Luckily, the all the Gentoo init scripts that all my computers use are
now at the stage where we could easily flick parallel startup on by
default and expect it to work just fine.

Thanks

Roy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Concerns about WIPE_TMP change

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

On Saturday 19 January 2008, Roy Marples wrote:
> On Sat, 2008-01-19 at 02:48 +0100, Stefan de Konink wrote:
> > In my opinion WIPE_TMP should be in the same state
> > as RC_PARALLEL_STARTUP.
>
> That's a fair point.

how ?  these two options are not related in the slightest.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Concerns about WIPE_TMP change

[Stefan de Konink]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Mike Frysinger schreef:
> On Saturday 19 January 2008, Roy Marples wrote:
>> On Sat, 2008-01-19 at 02:48 +0100, Stefan de Konink wrote:
>>> In my opinion WIPE_TMP should be in the same state
>>> as RC_PARALLEL_STARTUP.
>> That's a fair point.
> 
> how ?  these two options are not related in the slightest.

Because both options should be enabled manually under the presumption if
one knows what one is doing. Potential dataloss vs Potential boot
problems, I think that is the same ball park.


Stefan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHkmWYYH1+F2Rqwn0RCsuKAJ9JYYk75AU0DkmDKV7nS/MPdeNLRACeIaIl
jZnOJaxMD4MnO0wGS4JnZSk=
=fK5B
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Concerns about WIPE_TMP change

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

On Saturday 19 January 2008, Stefan de Konink wrote:
> Mike Frysinger schreef:
> > On Saturday 19 January 2008, Roy Marples wrote:
> >> On Sat, 2008-01-19 at 02:48 +0100, Stefan de Konink wrote:
> >>> In my opinion WIPE_TMP should be in the same state
> >>> as RC_PARALLEL_STARTUP.
> >>
> >> That's a fair point.
> >
> > how ?  these two options are not related in the slightest.
>
> Because both options should be enabled manually under the presumption if
> one knows what one is doing. Potential dataloss vs Potential boot
> problems, I think that is the same ball park.

as Roy points out, parallel startup is stabilized which means it will be 
enabled by default

WIPE_TMP had already been moved to yes by default in baselayout-2, i just got 
tired of waiting

i can add an elog, but the arguments for not turning it on by default are far 
from convincing
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Concerns about WIPE_TMP change

[Stefan de Konink]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Mike Frysinger schreef:
> i can add an elog, but the arguments for not turning it on by default are far 
> from convincing

Please, only do this, and I'll stop about this subject. :)

So something like *beep*beep*beep* /tmp will now by default cleaned upon
restart, this behavior is configurable in /etc/conf.d/bootmisc. For more
permanent temporary storage use /var/tmp. For more information about
/tmp look at: http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES


Stefan



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHkmzDYH1+F2Rqwn0RCvVLAJ95si3oUVrzvmvhyozzYcqf58UJEwCfYCz7
Ieark6Y+rPn+Q7NKH9ZB8lU=
=xkJy
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list