Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

classic Classic list List threaded Threaded
125 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Frederic Crozat-4
Hi all,

this is a announcement regarding changes which have just landed in
upstream systemd (not yet released nor pushed to Factory)
regarding /media and /tmp:
- /media will no longer mounted as tmpfs. This is because udisks2 will
no longer use /media for mounting removables devices
but /run/media/<user>
- /var/run and /var/lock are no longer bind-mounted to /run | /run/lock.
We should replace those directories with symlink to /run | /run/lock
(probably at initrd time, this is what is done on Fedora)
- /tmp is mounted as tmpfs, to make the default setups as stateless as
possible. As stated on
https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to
fix some applications to use /var/tmp instead of /tmp when they need
persistent storage. Another big issue is educating users.

--
Frederic Crozat <[hidden email]>
SUSE

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Per Jessen-2
Frederic Crozat wrote:

> - /tmp is mounted as tmpfs, to make the default setups as stateless as
> possible. As stated on
> https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need
> to fix some applications to use /var/tmp instead of /tmp when they
> need persistent storage. Another big issue is educating users.

I can see this one causing a few issues, especially for existing users,
but at least there is an easy work-around.


--
Per Jessen, Zürich (16.6°C)

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Cristian Rodríguez-2
In reply to this post by Frederic Crozat-4
El 27/03/12 13:08, Frederic Crozat escribió:

> Hi all,
>
> this is a announcement regarding changes which have just landed in
> upstream systemd (not yet released nor pushed to Factory)
> regarding /media and /tmp:
> - /media will no longer mounted as tmpfs. This is because udisks2 will
> no longer use /media for mounting removables devices
> but /run/media/<user>
> - /var/run and /var/lock are no longer bind-mounted to /run | /run/lock.
> We should replace those directories with symlink to /run | /run/lock
> (probably at initrd time, this is what is done on Fedora)
> - /tmp is mounted as tmpfs, to make the default setups as stateless as
> possible. As stated on
> https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to
> fix some applications to use /var/tmp instead of /tmp when they need
> persistent storage. Another big issue is educating users.
>

+1000, that makes a lot of sense, thanks for your efforts :-)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Robert Schweikert-6
In reply to this post by Frederic Crozat-4


On 03/27/2012 12:08 PM, Frederic Crozat wrote:

> Hi all,
>
> this is a announcement regarding changes which have just landed in
> upstream systemd (not yet released nor pushed to Factory)
> regarding /media and /tmp:
> - /media will no longer mounted as tmpfs. This is because udisks2 will
> no longer use /media for mounting removables devices
> but /run/media/<user>
> - /var/run and /var/lock are no longer bind-mounted to /run | /run/lock.
> We should replace those directories with symlink to /run | /run/lock
> (probably at initrd time, this is what is done on Fedora)
> - /tmp is mounted as tmpfs, to make the default setups as stateless as
> possible. As stated on
> https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to
> fix some applications to use /var/tmp instead of /tmp when they need
> persistent storage. Another big issue is educating users.

We probably have to consider any potential ill side effects for users
that have /tmp already setup as a tmpfs mount.

Robert
>

--
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
[hidden email]
[hidden email]
781-464-8147
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Frederic Crozat-4
Le mardi 27 mars 2012 à 12:35 -0400, Robert Schweikert a écrit :

>
> On 03/27/2012 12:08 PM, Frederic Crozat wrote:
> > Hi all,
> >
> > this is a announcement regarding changes which have just landed in
> > upstream systemd (not yet released nor pushed to Factory)
> > regarding /media and /tmp:
> > - /media will no longer mounted as tmpfs. This is because udisks2 will
> > no longer use /media for mounting removables devices
> > but /run/media/<user>
> > - /var/run and /var/lock are no longer bind-mounted to /run | /run/lock.
> > We should replace those directories with symlink to /run | /run/lock
> > (probably at initrd time, this is what is done on Fedora)
> > - /tmp is mounted as tmpfs, to make the default setups as stateless as
> > possible. As stated on
> > https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to
> > fix some applications to use /var/tmp instead of /tmp when they need
> > persistent storage. Another big issue is educating users.
>
> We probably have to consider any potential ill side effects for users
> that have /tmp already setup as a tmpfs mount.

This will need to be tested but I think systemd will just "override" the
default from /etc/fstab in that case (but I'm not 100% sure)

--
Frederic Crozat <[hidden email]>
SUSE

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Cristian Rodríguez-2
In reply to this post by Robert Schweikert-6
El 27/03/12 13:35, Robert Schweikert escribió:

> We probably have to consider any potential ill side effects for users
> that have /tmp already setup as a tmpfs mount.
>
> Robert
>>
>
Other than the "is already mounted in..." warning, I do not see other
ugly side effect it might have...

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Matthias G. Eckermann-3
In reply to this post by Frederic Crozat-4
On 2012-03-27 T 18:46 +0200 Frederic Crozat wrote:
> Le mardi 27 mars 2012 à 12:35 -0400, Robert Schweikert a écrit:
> >
> > We probably have to consider any potential ill side effects
> > for users that have /tmp already setup as a tmpfs mount.
>
> This will need to be tested but I think systemd will just
> "override" the default from /etc/fstab in that case (but I'm
> not 100% sure)

That would be rather inconvenient: think about people who might
have special mount options to /tmp on tmpfs, such as size, ...

so long -
        MgE

--
Matthias G. Eckermann     Senior Product Manager   SUSE® Linux Enterprise
SUSE LINUX Products GmbH  Maxfeldstraße 5          90409 Nürnberg Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Michal Kubecek
In reply to this post by Frederic Crozat-4
On Tue, Mar 27, 2012 at 06:46:23PM +0200, Frederic Crozat wrote:
> >
> > We probably have to consider any potential ill side effects for users
> > that have /tmp already setup as a tmpfs mount.
>
> This will need to be tested but I think systemd will just "override" the
> default from /etc/fstab in that case (but I'm not 100% sure)

I thought we are talking about having /tmp on tmpfs on default (but
still allowing admin to change it manually to whatever they want or
need) so that I didn't have any problem with that.

But now when you are talking about systemd "overriding" /etc/fstab...
this is evil. I strongly disagree with anything like that.

                                                        Michal Kubeček

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Bruno Friedmann-2
In reply to this post by Frederic Crozat-4
On Tuesday 27 March 2012 18.08:01 Frederic Crozat wrote:
> Hi all,
>
> this is a announcement regarding changes which have just landed in
> upstream systemd (not yet released nor pushed to Factory)
> regarding /media and /tmp:
> - /media will no longer mounted as tmpfs. This is because udisks2 will
> no longer use /media for mounting removables devices
okay so all work and effort to fix situation comparing 11.4 and 12.1 is lost (again :-()
> but /run/media/<user>
Sometimes (old song) they should really think about that not all computers are phone device.
We will adapt again to survive
> - /var/run and /var/lock are no longer bind-mounted to /run | /run/lock.
How much package will have to be fixed again just for that ?
> We should replace those directories with symlink to /run | /run/lock
> (probably at initrd time, this is what is done on Fedora)
Could it be pushed before M3 please to have a better timeframe for feedback and tests?
> - /tmp is mounted as tmpfs, to make the default setups as stateless as
> possible. As stated on
> https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might need to
> fix some applications to use /var/tmp instead of /tmp when they need
> persistent storage. Another big issue is educating users.
Just have a clear listing of all application that need to be fixed and all kind of usage
verified, like split tar gimp inkscape (memory hungry things) etc and all kind of stuff that could use /tmp
There's a bunch of application that use it to swap undo and kind of things using tmpfs could be pretty counter intuitive
So test and bench need to be written for openQA

the whole /etc/sysconfig/cron has to be revisited completely

And a point that need to be clear and have a hook permitting users to clean it up
What happens with my old /tmp directory as soon as this feature is enabled?
On the next boot we'll simply mount the directory over with a tmpfs.
and then you keep forever the 4GB iso you put it inside before the update/upgrade
-> move previous /tmp to /tmp.old or rpmsave or whatever than joe and jane can cleanup


>

Thanks for the RFC Fredirc :D

> --
> Frederic Crozat <[hidden email]>
> SUSE
>
> --
> To unsubscribe, e-mail: [hidden email]
> To contact the owner, e-mail: [hidden email]
>
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
 
openSUSE Member & Ambassador
GPG KEY : D5C9B751C4653227
irc: tigerfoot
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Claudio Freire
On Tue, Mar 27, 2012 at 3:39 PM, Bruno Friedmann <[hidden email]> wrote:
> And a point that need to be clear and have a hook permitting users to clean it up
> What happens with my old /tmp directory as soon as this feature is enabled?
> On the next boot we'll simply mount the directory over with a tmpfs.

IIRC, you can't mount on a non-empty directory.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Michal Kubecek
On Tue, Mar 27, 2012 at 03:48:30PM -0300, Claudio Freire wrote:
> On Tue, Mar 27, 2012 at 3:39 PM, Bruno Friedmann <[hidden email]> wrote:
> > And a point that need to be clear and have a hook permitting users
> > to clean it up What happens with my old /tmp directory as soon as
> > this feature is enabled?  On the next boot we'll simply mount the
> > directory over with a tmpfs.
>
> IIRC, you can't mount on a non-empty directory.

You can. I'm even not sure if it was ever impossible.

                                                        Michal Kubeček

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Claudio Freire
2012/3/27 Michal Kubecek <[hidden email]>:
>> IIRC, you can't mount on a non-empty directory.
>
> You can. I'm even not sure if it was ever impossible.

It was, I remember it failing when I wanted to mount loop devices back
in 8.x (2.4 kernel), though I bet it was the user space tool the one
complaining not the kernel.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Lars Müller
In reply to this post by Matthias G. Eckermann-3
On Tue, Mar 27, 2012 at 07:16:23PM +0200, Matthias G. Eckermann wrote:

> On 2012-03-27 T 18:46 +0200 Frederic Crozat wrote:
> > Le mardi 27 mars 2012 à 12:35 -0400, Robert Schweikert a écrit:
> > >
> > > We probably have to consider any potential ill side effects
> > > for users that have /tmp already setup as a tmpfs mount.
> >
> > This will need to be tested but I think systemd will just
> > "override" the default from /etc/fstab in that case (but I'm
> > not 100% sure)
>
> That would be rather inconvenient: think about people who might
> have special mount options to /tmp on tmpfs, such as size, ...
We should cover at least these two cases:

a) Is /tmp covered by special settings in /etc/fstab?

If that's the case we inform the user via a short comment in the
syslog and systemd does nothing further regading /tmp

If systemd is such a relaxed and flexible dude and allows it.  I have my
expectations and count on the systemd dictatorship. ;)

b) If we're sure this is a system which used the old default method to
handle /tmp (by doing nothing special) we move anything from inside /tmp
to a speaking new location we created before with the help of

   mktemp -d /tmp-backup-$( date +%F)-XXXX

Else a less experience user might be surprised.  On the other had such
users also might miss the new location.

We also have to ensure such move is only performed one time.

Cheers,

Lars
--
Lars Müller [ˈlaː(r)z ˈmʏlɐ]
Samba Team
SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

attachment0 (197 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Carlos E. R.-2
In reply to this post by Michal Kubecek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-03-27 19:40, Michal Kubecek wrote:
> On Tue, Mar 27, 2012 at 06:46:23PM +0200, Frederic Crozat wrote:

> I thought we are talking about having /tmp on tmpfs on default (but
> still allowing admin to change it manually to whatever they want or
> need) so that I didn't have any problem with that.
>
> But now when you are talking about systemd "overriding" /etc/fstab...
> this is evil. I strongly disagree with anything like that.

Indeed.

There are people that use a very large partition for /tmp. Some programs
needs gigabytes of temporary space. You can not make those people use tmpfs.

- --
Cheers / Saludos,

                Carlos E. R.
                (from 11.4 x86_64 "Celadon" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk9yKQ0ACgkQIvFNjefEBxo5vwCgkUEl4Z5E528WTodXe8jc7Zjk
tMMAoNAGzPGDaKKdRYk8nieABKBPkWmE
=ntPQ
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Jiri Slaby-6
In reply to this post by Frederic Crozat-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/27/2012 06:08 PM, Frederic Crozat wrote:
> - /tmp is mounted as tmpfs, to make the default setups as stateless
> as possible. As stated on
> https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might
> need to fix some applications to use /var/tmp instead of /tmp when
> they need persistent storage. Another big issue is educating
> users.

This will break a ton of boxes.
* People won't be able to hibernate because their memory will be full
of temp undroppable bloat.
* The overall system performance will be *hugely* reduced. Again,
because the memory will be full of temp bloat, not having memory for
gluttonous firefox.

Yes, I still have a notebook with 2G of memory. I still have a 386 box
with 512M of memory. And both are currently on the edge. No, thanks, I
really don't want any more swapping.

Did they think about this change thoroughly?

(And yes, I have /tmp as tmpfs on my 6G-of-RAM machine.)

BTW stateless /tmp can be achieved by rm -rf /tmp/* at each boot.

regards,
- -- js suse labs


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

iQIcBAEBAgAGBQJPcjWgAAoJEL0lsQQGtHBJ4UoP/3+GAc8xA9yyFbDORaA0z8hp
8JS16e9eG78M9+h0xN7Xyss/sZNm6SU/0R4jyKRqSlDVIt7Vjzsvc2GnwbWWWfrb
1ltY//wP7f4aGO2cRD4cTekIXpg3/NxydJmSD+LPS7J70jYiCEjNsqYA1BwKmbKW
z3bvHtCbH6zLs5atVomx8ec6nerUGtBaGor53NNbpCN54qfB91YbcvanN2Ajkrwk
JOm5XvGe80uqKu3ovQLLAMERDedGO4weGReMrJZgeGDOLcb5JHIx5Fji+npIZvIN
Xh05EI6vJ6tQNRDf4Sz1+25aofuKyNOn6V2cD5SN6ZbwQQlJ37cFserZkkbYPQFg
o4cJXO1+hkuQRgNYCsP7Dmg0UA+Mbv2H+y6O1amnnzPYOS4ZxoleYvhM/Q7P4+cM
rRh4G5YxMHcckpyDZpBjmAQvXvfm2FzAj6cqcTGxZjWIwXky++2uO+TehNrbWWxE
K4647sB5RNgMnlotCmxZpbuD+7P6fQuQq5U7tMxXmqm6FVMz7ZK9T1QhmSBSZjIW
cHuO+lMhzmSs82J/gV5K/g5fngpee4VxVpLCrPcK4yZ4HtaOt7QBiimWS8r+8I8G
3nX1thL7p617ntaDZIxCVgEj3uL8a3baUjcTqkkJ0sbNwu53I3I6UiYCRMJ9wxxc
/3ES172z1mzVA2n6qWit
=3IPP
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Claudio Freire
On Tue, Mar 27, 2012 at 6:48 PM, Jiri Slaby <[hidden email]> wrote:
> Yes, I still have a notebook with 2G of memory. I still have a 386 box
> with 512M of memory. And both are currently on the edge. No, thanks, I
> really don't want any more swapping.
>
> Did they think about this change thoroughly?
>
> (And yes, I have /tmp as tmpfs on my 6G-of-RAM machine.)
>
> BTW stateless /tmp can be achieved by rm -rf /tmp/* at each boot.

A more important matter is... how does the distribution guarantee
correct behavior on low-memory systems?

If I install it on a 128M system, you simply can't assume any
significant amount of tmpfs storage. What then? Suck up 64M of RAM for
tmpfs? That's quite useless for temp files and quite detrimental of
system performance.

I think this default has to be handled done a lot smarter than "tmpfs
by default on all".

Remember, 128M is not necessarily a 20-yo box. It may be a virtual
machine. Even though you'd expect the need of customization on a VM
already, I still think /tmp has to be made really small on all systems
(no matter how much RAM), if only to guarantee consistent behavior
across all installations.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Joerg Mayer
In reply to this post by Jiri Slaby-6
On Tue, Mar 27, 2012 at 11:48:16PM +0200, Jiri Slaby wrote:
> On 03/27/2012 06:08 PM, Frederic Crozat wrote:
> > - /tmp is mounted as tmpfs, to make the default setups as stateless
> > as possible. As stated on
> > https://fedoraproject.org/wiki/Features/tmp-on-tmpfs , we might
> > need to fix some applications to use /var/tmp instead of /tmp when
> > they need persistent storage. Another big issue is educating
> > users.
>
> This will break a ton of boxes.
...
> Did they think about this change thoroughly?

I doubt it - but only because it seems impossible to me the think of all
possible effects/problems ;-)

What I don't understand is, why is os following so early/at all? Is the
os project more or less blindly following fedora design decisions now?
How about not copying this feature over (or to be more precise: disable
it completely, which might let us use the original semantics for how)
and see how fredora survives the coming weeks. Once they've found the
very ugly stuff we may look at lessons learned and then enable this
or continue to disable it.
:wq
Ciao
    Jörg

--
Joerg Mayer                                           <[hidden email]>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Rüdiger Meier
In reply to this post by Frederic Crozat-4
On Tuesday 27 March 2012, Frederic Crozat wrote:

> - /tmp is mounted as tmpfs, to make the default setups as stateless
> as possible. As stated on

This is absolutely stupid (at least having this per default). Would need
a few 100GB big swap partition for most of my systems...

cu,
Rudi

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Cristian Rodríguez-2
In reply to this post by Carlos E. R.-2
El 27/03/12 17:54, Carlos E. R. escribió:

> There are people that use a very large partition for /tmp. Some programs
> needs gigabytes of temporary space. You can not make those people use tmpfs.

so what ?
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock

Cristian Rodríguez-2
In reply to this post by Joerg Mayer
El 27/03/12 19:16, Joerg Mayer escribió:

> What I don't understand is, why is os following so early/at all? Is the
> os project more or less blindly following fedora design decisions now?


sharing policies and implementation details with other mayor
distributions will actually save us from a lot of work and reinvention.


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

1234 ... 7