On Monday 28 November 2005 02:07, Rob Landley wrote:
On Sunday 27 November 2005 12:31, Nix wrote:
Did you catch Linus's long rant about how MAP_PRIVATE is deeply stupid and
that Linux will never really implement it?
What's that?
And you can fsync and do stuff like journaling within a file.
On Sunday 27 November 2005 22:41, Rob Landley wrote:
On Sunday 27 November 2005 13:20, Blaisorblade wrote:
*shrug* The same argument could be made about any other argument that
mount interprets. (Currently: loop, defaults, noauto, ro, rw, nosuid,
suid, dev, nodev, exec, noexec, sync, async,
On Tuesday 29 November 2005 10:08, Blaisorblade wrote:
On Monday 28 November 2005 02:07, Rob Landley wrote:
On Sunday 27 November 2005 12:31, Nix wrote:
Did you catch Linus's long rant about how MAP_PRIVATE is deeply stupid
and that Linux will never really implement it?
What's that?
On Friday 25 November 2005 23:31, Rob Landley wrote:
On Friday 25 November 2005 15:04, Nix wrote:
The ~/.kde directory doesn't contain temporary files, but persistent
state:
~/.kde/share/apps/kmail/lock is persistent state?
I do know that half the time the darn battery runs out and kde
On Saturday 26 November 2005 11:44, Rob Landley wrote:
On Friday 25 November 2005 17:33, Blaisorblade wrote:
On Friday 25 November 2005 22:04, Nix wrote:
On Fri, 25 Nov 2005, Rob Landley moaned:
On Friday 25 November 2005 13:33, Nix wrote:
That a normal user can allocate persistent
On Saturday 26 November 2005 12:47, Rob Landley wrote:
On Friday 25 November 2005 20:12, Nix wrote:
If it's a problem you have both hostile users and no size limits on /tmp
and you therefore have bigger problems anyway. :)
My original point was that the semantics of what UML wants is shared
On Sun, 27 Nov 2005, [EMAIL PROTECTED] whispered secretively:
It's not a file, it's a AF_UNIX socket bound there - and bind() fails if the
file exists. So it's a different story (I was puzzled by a missing
bind(O_EXCL), but I learned with trial there's no need).
There's an (optional)
On Sun, 27 Nov 2005, [EMAIL PROTECTED] whispered secretively:
(as an aside, I do despise learning *so* fast... I wouldn't be able to use
socket() without manuals, and there's a lot of stuff I'd like to learn well.
And I'd really like to _start_ and finish even a little project on my own...
On Sunday 27 November 2005 19:35, Nix wrote:
On Sun, 27 Nov 2005, [EMAIL PROTECTED] whispered secretively:
Nice move to disable init=/bin/sh. Really. Next one is moving kdelibs
into the kernel?
Nah, AIUI the initramfs runs *first*;
it's its job to parse those parts
of the kernel
On Sunday 27 November 2005 12:17, Nix wrote:
[Sorry for response delay, steaming cold/flu]
On Fri, 25 Nov 2005, Rob Landley worried:
On Friday 25 November 2005 15:04, Nix wrote:
The ~/.kde directory doesn't contain temporary files, but persistent
state:
~/.kde/share/apps/kmail/lock is
On Sun, 27 Nov 2005, [EMAIL PROTECTED] whispered secretively:
Plus, for deep troubleshooting (mainly for kernels) init=/bin/sh is useful.
init=/bin/busybox/sh is also useful for those cases when you've futzed
your libc. :)
No - the kernel doesn't allow storing the full set of infos which are
On Sunday 27 November 2005 13:20, Blaisorblade wrote:
Try rdinit=/bin/sh, that affects what init gets run on the initramfs.
(Assuming the initramfs has a comand shell...)
Missing from Documentation/filesystems/ramfs-rootfs-initramfs.txt.
I only dredged through the source and found it
On Sunday 27 November 2005 12:49, Nix wrote:
I'm using both matlab/octave *and*, when running backups, said French disk
archiver. The source is gradually being Anglicised so that the developer
base can rise a bit :)
It has numerous advantages over tar and rsync if, like me, you're stuck
On Sunday 27 November 2005 12:35, Nix wrote:
On Sun, 27 Nov 2005, [EMAIL PROTECTED] whispered secretively:
It's not a file, it's a AF_UNIX socket bound there - and bind() fails if
the file exists. So it's a different story (I was puzzled by a missing
bind(O_EXCL), but I learned with trial
On Sunday 27 November 2005 12:31, Nix wrote:
I personally symlink /bin, /sbin, and /lib to the
corresponding /usr directories and consolidate the whole mess, myself.
Yes, you have to patch gcc's paths (in collect2) to not search _both_
/lib and /usr/lib because if gnu's linker
On Friday 25 November 2005 15:04, Nix wrote:
The ~/.kde directory doesn't contain temporary files, but persistent state:
~/.kde/share/apps/kmail/lock is persistent state?
I do know that half the time the darn battery runs out and kde suddely shuts
down my desktop without the courtesy of even
On Sat, Nov 26, 2005 at 04:03:54AM -0600, Rob Landley wrote:
On Friday 25 November 2005 17:46, Chris Lightfoot wrote:
On Fri, Nov 25, 2005 at 02:18:43PM -0600, Rob Landley wrote:
Using /tmp for anything has been kind of discouraged for a while, because
throwing any insufficiently
On Friday 25 November 2005 17:33, Blaisorblade wrote:
On Friday 25 November 2005 22:04, Nix wrote:
On Fri, 25 Nov 2005, Rob Landley moaned:
On Friday 25 November 2005 13:33, Nix wrote:
Actually, I consider the fact the OOM killer doesn't delete files out
of tmpfs mounts to be a
On Friday 25 November 2005 20:12, Nix wrote:
If it's a problem you have both hostile users and no size limits on /tmp
and you therefore have bigger problems anyway. :)
The size limits on /tmp aren't per-user.
Yeah, true, if you think the OOM killer is worthwhile (I do: most of the
MM
On Thu, Nov 24, 2005 at 06:11:01AM -0600, Rob Landley wrote:
So my question is, could system v shared memory be used in place of the tmpfs
mount? (Can it be mapped in the right location and inherited across fork()?)
tmpfs and shmfs are two names for the same underlying code. I think the
On Friday 25 November 2005 03:55, Jeff Dike wrote:
On Thu, Nov 24, 2005 at 06:11:01AM -0600, Rob Landley wrote:
So my question is, could system v shared memory be used in place of the
tmpfs mount? (Can it be mapped in the right location and inherited
across fork()?)
tmpfs and shmfs are
FYI:
The mounts on a Fedora Core 4 system:
/dev/hda2 on / type ext3 (rw)
/dev/proc on /proc type proc (rw)
/dev/sys on /sys type sysfs (rw)
/dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda1 on /boot type ext3 (rw)
/dev/shm on /dev/shm type tmpfs (rw)
/dev/hdb1 on /home type ext3
On Friday 25 November 2005 04:52, Rob Landley wrote:
FYI:
The mounts on a Fedora Core 4 system:
...
The mounts on the x86-64 PLD system I've been borrowing (and on which I do
not have root access):
...
The shell servers from sourceforge:
...
And I reiterate that on my ubuntu laptop /tmp is
On Fri, Nov 25, 2005 at 02:56:49PM +, Nix wrote:
You could certainly do just that with POSIX shm :)
Another option is to mlock the memory, which should
prevent paging, but requires root. I have a patch which
does this using a helper binary, if people would like it.
--
``As usual the
On Fri, 25 Nov 2005, Chris Lightfoot murmured woefully:
On Fri, Nov 25, 2005 at 02:56:49PM +, Nix wrote:
You could certainly do just that with POSIX shm :)
Another option is to mlock the memory, which should
prevent paging, but requires root. I have a patch which
does this using a
On Friday 25 November 2005 09:03, Chris Lightfoot wrote:
On Fri, Nov 25, 2005 at 02:56:49PM +, Nix wrote:
You could certainly do just that with POSIX shm :)
Another option is to mlock the memory, which should
prevent paging, but requires root. I have a patch which
does this using a
On Fri, 25 Nov 2005, Rob Landley uttered the following:
A) mlock would be a bad thing. Not only is it a trivial DOS waiting to
happen
but I like the UML physmem being swapped out under memory pressure. I just
don't want uselessly writing it to disk over and over in the absence of any
On Fri, Nov 25, 2005 at 02:18:43PM -0600, Rob Landley wrote:
Using /tmp for anything has been kind of discouraged for a while, because
throwing any insufficiently randomized filename in there is a security hole
waiting to happen.
Which case are you worried about here? SFAIK all the
On Sat, 26 Nov 2005, [EMAIL PROTECTED] announced authoritatively:
On Friday 25 November 2005 22:04, Nix wrote:
On Fri, 25 Nov 2005, Rob Landley moaned:
On Friday 25 November 2005 13:33, Nix wrote:
Actually, I consider the fact the OOM killer doesn't delete files out of
tmpfs mounts to be
29 matches
Mail list logo
