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
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
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
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 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 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
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.
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
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 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
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 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
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
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
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
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
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
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
42 matches
Mail list logo
