Russell Coker [EMAIL PROTECTED] writes:
On Sunday 25 December 2005 00:55, Goswin von Brederlow
[EMAIL PROTECTED] wrote:
Russell Coker [EMAIL PROTECTED] writes:
On Saturday 24 December 2005 11:35, Goswin von Brederlow
Basicaly everything that needs /run doesn't use /var/run anyway,
Russell Coker [EMAIL PROTECTED] writes:
On Saturday 24 December 2005 11:35, Goswin von Brederlow
Basicaly everything that needs /run doesn't use /var/run anyway,
e.g. mount. And one could link /var/run to /run on both / and /var and
then nothing needs to change even if it uses /var/run.
On Sunday 25 December 2005 00:55, Goswin von Brederlow
[EMAIL PROTECTED] wrote:
Russell Coker [EMAIL PROTECTED] writes:
On Saturday 24 December 2005 11:35, Goswin von Brederlow
Basicaly everything that needs /run doesn't use /var/run anyway,
e.g. mount. And one could link /var/run to
Russell Coker [EMAIL PROTECTED] writes:
On Monday 19 December 2005 11:49, Bernd Eckenfels [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED] you wrote:
If /run is tmpfs, it means everything stored there eats virtual memory.
So a musch metter strategy would be to move everything from /run
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
On a vm-based fs, you always use *address space* for data in it, and it is
linearly coupled to the amount of filesystem used (or even to the full size,
for extremely dumb filesystems).
Not that address space shortage is something I'd fear
On Saturday 24 December 2005 11:35, Goswin von Brederlow
Also as for sym-links, there's no reason why /var/run couldn't be used
all along. Imagine we have a system where /var is mounted from an LVM
volume (or something else that can't be mounted early on). So we start
with a /var
On Thu, Dec 22, 2005 at 05:09:02PM +1100, Russell Coker wrote:
368K is an issue on a machine with 8M of RAM, it's an annoyance if you have
16M, beyond about 32M it stops being a problem.
Yeah, and a new optimization step only takes a few thenth of a second and
only a few extra KB of memory,
On Friday 23 December 2005 10:48, Gabor Gombas [EMAIL PROTECTED] wrote:
On Thu, Dec 22, 2005 at 05:09:02PM +1100, Russell Coker wrote:
368K is an issue on a machine with 8M of RAM, it's an annoyance if you
have 16M, beyond about 32M it stops being a problem.
Yeah, and a new optimization
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
Peter Samuelson wrote:
Given the need, and now the reality, of /run, is there any need for
a
separate /var/run?
Need is probably too strong, but it's certainly convenient if we
don't
have to change the way we currently use /var/run/.
How
In article [EMAIL PROTECTED] you wrote:
aren't really there anyway, I have never heard of non-swappable in-memory
filesystems.
the ram disks, afaik.
Those are: Solaris, *BSD and The Hurd. Solaris and all of the BSDs can do
VM-based filesystems that are nearly identical to tmpfs. I don't
On Monday 19 December 2005 11:49, Bernd Eckenfels [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED] you wrote:
If /run is tmpfs, it means everything stored there eats virtual memory.
So a musch metter strategy would be to move everything from /run to
/var/run at the end of the boot
On Monday 19 December 2005 23:04, Gabor Gombas [EMAIL PROTECTED] wrote:
On Mon, Dec 19, 2005 at 01:49:37AM +0100, Bernd Eckenfels wrote:
tmpfs stores run ressources in vm more efficiently (since they are
otherwise in th buffercache and the filesystem).
Quite the contrary. tmpfs needs vm
On Thu, 22 Dec 2005, Russell Coker wrote:
On Monday 19 December 2005 23:04, Gabor Gombas [EMAIL PROTECTED] wrote:
On Mon, Dec 19, 2005 at 01:49:37AM +0100, Bernd Eckenfels wrote:
tmpfs stores run ressources in vm more efficiently (since they are
otherwise in th buffercache and the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gabor Gombas [EMAIL PROTECTED] writes:
On Tue, Dec 20, 2005 at 03:59:04AM +1000, Anthony Towns wrote:
That is, pretty much everything that runs as a daemon, and that might
have otherwise used /var in general.
That's why I'd like to have a check
On Mon, 19 Dec 2005, Steve Langasek wrote:
by constraining the actual *implementation* of /run (barring ugly
hacking of the init scripts), you've made the system less suitable
for a third use case:
- memory is at a premium, disk is not
Then IMHO Debian is NOT the appropriate system
Gabor Gombas wrote:
... I'd like to have a check for /run (or /lib/run or whatever)
being empty at the end of the boot process
The new mountvirtfs prints such warnings for all the virtual
filesystems.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
On Tue, Dec 20, 2005 at 09:23:05AM -0200, Henrique de Moraes Holschuh wrote:
Then IMHO Debian is NOT the appropriate system to run on that box. Get a non
glibc-based one that also likes to pass -Os to gcc and compiles the kernel
with -Os.
AFAIK -Os is not the upstream default for kernel
On Tue, Dec 20, 2005 at 12:13:15PM +0100, Thomas Hood wrote:
The new mountvirtfs prints such warnings for all the virtual
filesystems.
Where? I do not see any such checks in /etc/init.d/mountvirtfs. Also, to
be effective, such checks should run at level S99 in rc[2345].d and I do
not see
Tmpfs memory can be swapped out, so is this even a hypothetical
problem?
Maybe it isn't on Linux. I wasn't aware tmpfs could be swapped out.
That still leaves the question of just which features we want to require
from our non-Linux kernels for basic operation, I guess.
Yes, I don't
On Tue, Dec 20, 2005 at 09:09:27AM +, Roger Leigh wrote:
Wouldn't that break mtab, or will that be moved under /var at the end
of booting?
It can be moved. Using mount --bind even the mount binary does not need
to be modified for the new location.
Gabor
--
[Anthony Towns]
I note the FHS's limited definition of /lib (essential libraries and
kernel modules) is already incorrect for /lib/udev,
/lib/lsb/init-functions, /lib/linux-sound-base, /lib/terminfo,
/lib/alsa, /lib/alsa-utils, /lib/discover and /lib/init.
I did not look closely at the
Anthony Towns:
Mmm; privately asking someone who works on the FHS is a different thing
to asking on the FHS lists, or actually talking to our users.
True.
Claiming support from the FHS guys on the basis of a conversation with
Chris doesn't seem appropriate; anymore than -policy support
On Mon, Dec 19, 2005 at 09:18:29AM +0100, Petter Reinholdtsen wrote:
I did not look closely at the others, but /lib/lsb/init-functions is a
library of shell functions, and /lib/terminfo/ is a library of
terminal definitions. Both are essential for the function of several
systems in Debian.
On Sun, Dec 18, 2005 at 01:26:45PM +0100, [EMAIL PROTECTED] wrote:
Steve Langasek wrote:
(We also shouldn't need to specify a policy for mounting any
particular filesystem on /run, but merely mount /run early iff it's
present in /etc/fstab and leave the implementation details to the
Anthony Towns wrote:
A possible concern is people seeing /run and thinking ah, there's a
directory I can use for stuff, and having it be used instead of
/var/run or $TMPDIR or /var/lib or /var/cache for things it's not
appropriate for.
I think that everyone agrees that /run is to be used
On Sat, Dec 17, 2005 at 10:13:35PM -0600, Peter Samuelson wrote:
[Steve Langasek]
Given the reality of /lib, is there any need for a separate /usr/lib?
The principle is the same: /lib is used only for the minimal system
required for booting, and everything else should go in /usr/lib.
Steve Langasek wrote:
Are there really any init scripts that need to write out data prior
to checkroot.sh (the point at which /run would be writeable by
default on the rootfs)?
Well, it would be nice if fsck logs could be stored in /run until
/var/log/ is available for writing. It would be
On Mon, Dec 19, 2005 at 01:49:37AM +0100, Bernd Eckenfels wrote:
tmpfs stores run ressources in vm more efficiently (since they are otherwise
in th buffercache and the filesystem).
Quite the contrary. tmpfs needs vm space even if nobody needs the data
(thus, it could be evicted from the page
On Dec 18, Roger Leigh [EMAIL PROTECTED] wrote:
Debian guarantees that it exists on debian systems.
But what about the future, and what about it being specifically for
POSIX-SHM?
Tell us... Do you have reasons to believe that we will be forced to
remove /dev/shm/ in the future?
/run doesn't
On Dec 19, Anthony Towns aj@azure.humbug.org.au wrote:
I note the FHS's limited definition of /lib (essential
libraries and kernel modules) is already incorrect for /lib/udev,
/lib/lsb/init-functions, /lib/linux-sound-base, /lib/terminfo, /lib/alsa,
/lib/alsa-utils, /lib/discover and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
[no need to CC me; I'm subscribed to the list]
On Dec 18, Roger Leigh [EMAIL PROTECTED] wrote:
Debian guarantees that it exists on debian systems.
But what about the future, and what about it being
On Mon, Dec 19, 2005 at 01:14:45PM +0100, Marco d'Itri wrote:
But what about the future, and what about it being specifically for
POSIX-SHM?
Tell us... Do you have reasons to believe that we will be forced to
remove /dev/shm/ in the future?
If in the future glibc decides to choose some
On Dec 19, Gabor Gombas [EMAIL PROTECTED] wrote:
If in the future glibc decides to choose some other implementation
for shm_open(), then it has no reason to stay.
But it has no reason to go away either, since there are many other uses
too for a tmpfs.
/run doesn't especially /need/ to be a
On Mon, Dec 19, 2005 at 09:18:29AM +0100, Petter Reinholdtsen wrote:
[Anthony Towns]
I note the FHS's limited definition of /lib (essential libraries and
kernel modules) is already incorrect for /lib/udev,
/lib/lsb/init-functions, /lib/linux-sound-base, /lib/terminfo,
/lib/alsa,
On Mon, Dec 19, 2005 at 09:31:28AM +0100, Thomas Hood wrote:
Anthony Towns:
Claiming support from the FHS guys on the basis of a conversation with
Chris doesn't seem appropriate; anymore than -policy support would be an
appropriate claim if Manoj had said it looked okay.
Agreed.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Dec 19, Gabor Gombas [EMAIL PROTECTED] wrote:
If in the future glibc decides to choose some other implementation
for shm_open(), then it has no reason to stay.
But it has no reason to go away either,
On Mon, Dec 19, 2005 at 09:57:48AM +0100, Thomas Hood wrote:
Anthony Towns wrote:
A possible concern is people seeing /run and thinking ah, there's a
directory I can use for stuff, and having it be used instead of
/var/run or $TMPDIR or /var/lib or /var/cache for things it's not
Anthony Towns:
Sorry, I was paraphrasing above. The actual definition is Essential
shared libraries and kernel modules, and The /lib directory contains
those shared library images needed to boot the system and run the
commands in the root filesystem, ie. by binaries in /bin and /sbin.
On Sun, 18 Dec 2005, Marco d'Itri wrote:
Reality check: packages have been using it for a long time and the world
has not fallen yet.
Debian-style reality check: if it is broken, we better fix it before it does
any damage.
Since we are talking namespace violation, I'd say we better fix this
On Sun, 18 Dec 2005, Marco d'Itri wrote:
Debian guarantees that it exists on debian systems.
No, we don't. We guarantee it exists on Sarge. It may or may not exist in
Etch and Sid in the future.
1. It exists only on Linux-based OS's
2. There is no gaurentee that it will continue to be
Anthony Towns wrote:
Developers have been known not to be completely familiar with policy,
but it's admins and upstream programmers that I'm particularly
thinking of.
I don't see any problems arising from rampant /run use by _admins_.
They are always free to do what they want with their
On Mon, 19 Dec 2005, Marco d'Itri wrote:
On Dec 19, Gabor Gombas [EMAIL PROTECTED] wrote:
If in the future glibc decides to choose some other implementation
for shm_open(), then it has no reason to stay.
But it has no reason to go away either, since there are many other uses
too for a
On Dec 19, Roger Leigh [EMAIL PROTECTED] wrote:
If in the future glibc decides to choose some other implementation
for shm_open(), then it has no reason to stay.
But it has no reason to go away either, since there are many other uses
too for a tmpfs.
There are many uses for an ext3fs,
On Dec 19, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
Debian guarantees that it exists on debian systems.
No, we don't. We guarantee it exists on Sarge. It may or may not exist in
Etch and Sid in the future.
If we use it then it's reasonable to assume that we would not suddenly
On Mon, Dec 19, 2005 at 05:48:45PM +0100, Thomas Hood wrote:
Note the definition for /usr/lib is Libraries for programming and
packages and /usr/lib includes object files, libraries, and internal
binaries that are not intended to be executed directly by users or
shell scripts. and /var/lib
On Mon, Dec 19, 2005 at 01:04:23PM +0100, Gabor Gombas wrote:
Quite the contrary. tmpfs needs vm space even if nobody needs the data
Yes, we are talking about a few pages in swap space at most.
And I am not sure if not used is valid here, since symlinks and
sockets would be in memory even if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Dec 19, Roger Leigh [EMAIL PROTECTED] wrote:
If in the future glibc decides to choose some other implementation
for shm_open(), then it has no reason to stay.
But it has no reason to go away either,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Dec 19, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
1. It exists only on Linux-based OS's
2. There is no gaurentee that it will continue to be there at all
3. There is no guareteee that
In article [EMAIL PROTECTED] you wrote:
/var/run/screen, which aren't guaranteed to stay small at all. On one
particular samba fileserver I checked, /var/run is less than two orders of
magnitude smaller than /usr/lib. :)
if this is a busy fileserver, it is mapped to memory anyway.
Gruss
On Dec 19, Roger Leigh [EMAIL PROTECTED] wrote:
With this example, it's trivial to trigger namespace conflicts and
break shm_open(). mkdir /dev/shm/foobar, for example, or create a
symbolic link. These fail outright. If a regular file was opened, it
And so would two programs using the same
On Dec 19, Roger Leigh [EMAIL PROTECTED] wrote:
That tmpfs will not be removed from the kernel just because shm_open()
will switch to a different implementation.
Of course. But if that happened there would be no reason to keep
/dev/shm mounted; you would need to use an alternate location.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Dec 19, Roger Leigh [EMAIL PROTECTED] wrote:
With this example, it's trivial to trigger namespace conflicts and
break shm_open(). mkdir /dev/shm/foobar, for example, or create a
symbolic link. These
Le lundi 19 décembre 2005 à 21:12 +0100, Marco d'Itri a écrit :
On Dec 19, Roger Leigh [EMAIL PROTECTED] wrote:
That tmpfs will not be removed from the kernel just because shm_open()
will switch to a different implementation.
Of course. But if that happened there would be no reason to
Le lundi 19 décembre 2005 à 18:45 +0100, Marco d'Itri a écrit :
On Dec 19, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
Debian guarantees that it exists on debian systems.
No, we don't. We guarantee it exists on Sarge. It may or may not exist in
Etch and Sid in the future.
If
On Dec 19, Roger Leigh [EMAIL PROTECTED] wrote:
That's correct, but you should still not be using the namespace for
non-SHM activities.
Because?
--
ciao,
Marco
signature.asc
Description: Digital signature
On Dec 19, Josselin Mouette [EMAIL PROTECTED] wrote:
That tmpfs will not be removed from the kernel just because shm_open()
will switch to a different implementation.
Of course. But if that happened there would be no reason to keep
/dev/shm mounted; you would need to use an
On Monday 19 December 2005 17:11, Marco d'Itri wrote:
The real lesson in this is that object names should be choosed
carefully.
AFAIK, the namespace is part of the object name, an thus should be chosen
carefully too.
--
Felipe Sateler
pgpHMa4cCTsTl.pgp
Description: PGP signature
On Mon, Dec 19, 2005 at 07:40:24PM +0100, Bernd Eckenfels wrote:
Yes, we are talking about a few pages in swap space at most.
It's 55 pages (220k) on this machine (368k on ext3). And it's a simple
desktop with not much running state.
And I am not sure if not used is valid here, since symlinks
On Mon, Dec 19, 2005 at 09:12:22PM +0100, Marco d'Itri wrote:
There is no reason why it should be moved.
But there is a reason why its current abusers should get fixed to use
something else. Just think what happens if an app does something like
shm_open(/network, ...), or even better,
On Mon, Dec 19, 2005 at 09:11:42PM +0100, Marco d'Itri wrote:
The real lesson in this is that object names should be choosed
carefully.
Exactly. Therefore any object not created by shm_open() should not use
the /dev/shm/ path prefix. Glad you finally agree :-)
Gabor
--
On Tue, Dec 20, 2005 at 03:59:04AM +1000, Anthony Towns wrote:
Putting R in / spoils the otherwise read-only character of that
directory. *shrug*
No, it's not. Mounting something over a top-level subdirectory does not
require / to be writeable.
That is, pretty much everything that runs as a
On Tue, Dec 20, 2005 at 01:32:41AM +0100, Gabor Gombas wrote:
On Tue, Dec 20, 2005 at 03:59:04AM +1000, Anthony Towns wrote:
Putting R in / spoils the otherwise read-only character of that
directory. *shrug*
No, it's not. Mounting something over a top-level subdirectory does not
require /
On Mon, Dec 19, 2005 at 12:23:00PM +0100, Thomas Hood wrote:
Steve Langasek wrote:
Are there really any init scripts that need to write out data prior
to checkroot.sh (the point at which /run would be writeable by
default on the rootfs)?
Well, it would be nice if fsck logs could be stored
Marco d'Itri wrote:
I do not remember a consensus about this.
Perhaps the last hold-outs can be convinced this time? :)
Bernd Eckenfels wrote:
and if it is placed in a tmpfs (which is really the best thing
anyway)
it doesnt matter under which mountpoint it is located.
It does matter,
(OK, this time reformatted to make my webmail composer happy.)
Marco d'Itri wrote:
I do not remember a consensus about this.
Perhaps the last hold-outs can be convinced this time? :)
Bernd Eckenfels wrote:
and if it is placed in a tmpfs (which is really the best thing
anyway) it doesnt
On Dec 18, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I have yet to hear any strong reason why we should _not_ implement
/run.
I do not count It's ugly! as a strong reason.
It's not needed (since we have /dev/shm/), so it's harmful.
--
ciao,
Marco
signature.asc
Description: Digital
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Dec 18, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I have yet to hear any strong reason why we should _not_ implement
/run.
I do not count It's ugly! as a strong reason.
It's not needed (since we
On Sun, Dec 18, 2005 at 02:37:28PM +0100, Marco d'Itri wrote:
On Dec 18, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I have yet to hear any strong reason why we should _not_ implement
/run.
I do not count It's ugly! as a strong reason.
It's not needed (since we have /dev/shm/), so it's
In article [EMAIL PROTECTED] you wrote:
However there a big differences: /var/run is much smaller than /run, and if
sorry i meant to say: /var/run is much smaller (bytewise) as /usr/lib.
Gruss
Bernd
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
In article [EMAIL PROTECTED] you wrote:
Bernd Eckenfels wrote:
and if it is placed in a tmpfs (which is really the best thing
anyway) it doesnt matter under which mountpoint it is located.
It does matter, because /run needs to be usable before other
filesystems are mounted, and a filesystem
Are we seriously expecting to ship etch with 2.4
kernels? Is anyone still doing active security support for it?
This point isn't too bad yet. As you've seen 2.4 had a security update a
few days ago. Sure, it's from August, but 2.6 isn't doing better anyway.
Some Debian kernel team people
On Sun, Dec 18, 2005 at 01:26:45PM +0100, [EMAIL PROTECTED] wrote:
It does matter, because /run needs to be usable before other
filesystems
I realise your heart's set on /run, but is there any possibility
of putting it under /lib/run or /boot/early-writable-fs instead of
introducing a new
On Dec 18, Wouter Verhelst [EMAIL PROTECTED] wrote:
It's not needed (since we have /dev/shm/), so it's harmful.
Does not follow. Cars aren't needed either (you can always take the
train, or go by bus), but that doesn't make them harmful.
Cars and trains are different thigs, but a tmpfs is a
On Dec 18, Roger Leigh [EMAIL PROTECTED] wrote:
How strongly can I put this? /dev/shm is for *shared memory*, not for
random junk. /dev/shm is for POSIX shared memory and semaphores
/dev/shm is a tmpfs which happens to be used by POSIX SHM. I have not
seen yet a good reason why it should not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Dec 18, Roger Leigh [EMAIL PROTECTED] wrote:
How strongly can I put this? /dev/shm is for *shared memory*, not for
random junk. /dev/shm is for POSIX shared memory and semaphores
/dev/shm is a tmpfs
Marco d'Itri [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Furthermore, /dev/shm is a mount point with a _very_ specific function.
It's a bad idea to start using it for something else.
Reality check: packages have been using it for a long time and the world
has not fallen yet.
Anthony Towns wrote:
is there any possibility
of putting it under /lib/run or /boot/early-writable-fs instead of
introducing a new directory on / that's of very limited use?
That is certainly possible, but I don't see anything wrong with putting
it at the top level either.
FWIW I asked Chris
On Dec 18, Joe Smith [EMAIL PROTECTED] wrote:
1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm,
or that if it does exist, that it can be be read as a block device, or that
if it can, it has a file system on it.
2. Neither does FHS.
3. The Linux 2.6 device list
On Dec 18, Thomas Hood [EMAIL PROTECTED] wrote:
FWIW I asked Chris Yeoh for his opinion on the name and he said that
/run sounded preferable to both /etc/run and /lib/run.
Competition with /root in tab-completion, for a start.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Sun, Dec 18, 2005 at 01:03:37PM -0500, Joe Smith wrote:
1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm,
or that if it does exist, that it can be be read as a block device, or that
if it can, it has a file system on it.
2. Neither does FHS.
3. The Linux 2.6
su, 2005-12-18 kello 20:18 +0100, Marco d'Itri kirjoitti:
Sounds it sounds to me like it is a bad idea to use it.
Only because you have no clue of what you are talking about.
Marco, would please keep the discussion technical, and not attack the
people taking part, even if you think they're
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Dec 18, Joe Smith [EMAIL PROTECTED] wrote:
1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm,
or that if it does exist, that it can be be read as a block device, or that
if
On Sat, Dec 17, 2005 at 06:09:05PM -0600, Peter Samuelson wrote:
Given the need, and now the reality, of /run, is there any need for a
separate /var/run? I vote we migrate to /var/run - /run, at least in
the default install.
If /run is tmpfs, it means everything stored there eats virtual
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Dec 18, Thomas Hood [EMAIL PROTECTED] wrote:
FWIW I asked Chris Yeoh for his opinion on the name and he said that
/run sounded preferable to both /etc/run and /lib/run.
Competition with /root in tab-completion, for a start.
Under what
On Sun, Dec 18, 2005 at 04:50:33AM +, Matthew Garrett wrote:
Steve Langasek [EMAIL PROTECTED] wrote:
On Sun, Dec 18, 2005 at 03:57:35AM +, Matthew Garrett wrote:
Under Linux, can't all of this be done with mount --move anyway? I'm not
convinced that we actually need a /run any more.
On Sun, Dec 18, 2005 at 05:24:40PM +0100, Marco d'Itri wrote:
Reality check: packages have been using it for a long time and the world
has not fallen yet.
Emphasis on yet. /dev/shm was created to be used uniquely by shm_open(),
and violating this _will_ cause some problems after a certain
On Sun, Dec 18, 2005 at 01:03:37PM -0500, Joe Smith wrote:
1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm,
or that if it does exist, that it can be be read as a block device, or that
if it can, it has a file system on it.
AFAIK /dev/shm is just an internal detail
[Anthony Towns]
I realise your heart's set on /run, but is there any possibility
of putting it under /lib/run or /boot/early-writable-fs instead of
introducing a new directory on / that's of very limited use?
/lib is no more appropriate than /sbin. That it is already overloaded
in the FHS to
This one time, at band camp, Marco d'Itri said:
On Dec 18, Thomas Hood [EMAIL PROTECTED] wrote:
FWIW I asked Chris Yeoh for his opinion on the name and he said that
/run sounded preferable to both /etc/run and /lib/run.
Competition with /root in tab-completion, for a start.
Well, that's
In article [EMAIL PROTECTED] you wrote:
If /run is tmpfs, it means everything stored there eats virtual memory.
So a musch metter strategy would be to move everything from /run to
/var/run at the end of the boot process.
tmpfs stores run ressources in vm more efficiently (since they are
On Sun, Dec 18, 2005 at 07:38:41PM +0100, Thomas Hood wrote:
Anthony Towns wrote:
is there any possibility
of putting it under /lib/run or /boot/early-writable-fs instead of
introducing a new directory on / that's of very limited use?
That is certainly possible, but I don't see anything
[Thomas Hood]
After installation you should have a tmpfs mounted on /run. This has
been created for the use of that handful of packages that need a
place to store run time state files independently of networking.
Given the need, and now the reality, of /run, is there any need for a
separate
On Sat, Dec 17, 2005 at 06:09:05PM -0600, Peter Samuelson wrote:
[Thomas Hood]
After installation you should have a tmpfs mounted on /run. This has
been created for the use of that handful of packages that need a
place to store run time state files independently of networking.
Given the
Steve Langasek [EMAIL PROTECTED] wrote:
The principle is the same: /lib is used only for the minimal system required
for booting, and everything else should go in /usr/lib. /run should be used
only for junk that needs to be stored early in the boot sequence, and
everything else should go in
[Steve Langasek]
Given the reality of /lib, is there any need for a separate /usr/lib?
The principle is the same: /lib is used only for the minimal system
required for booting, and everything else should go in /usr/lib.
/run should be used only for junk that needs to be stored early in
the
On Sun, Dec 18, 2005 at 03:57:35AM +, Matthew Garrett wrote:
Steve Langasek [EMAIL PROTECTED] wrote:
The principle is the same: /lib is used only for the minimal system required
for booting, and everything else should go in /usr/lib. /run should be used
only for junk that needs to be
Steve Langasek [EMAIL PROTECTED] wrote:
On Sun, Dec 18, 2005 at 03:57:35AM +, Matthew Garrett wrote:
Under Linux, can't all of this be done with mount --move anyway? I'm not
convinced that we actually need a /run any more.
So you would have these files stored in /var/run from the
In article [EMAIL PROTECTED] you wrote:
The principle is the same: /lib is used only for the minimal system required
for booting, and everything else should go in /usr/lib. /run should be used
only for junk that needs to be stored early in the boot sequence, and
everything else should go in
98 matches
Mail list logo
