On Wed, May 13, 2015 at 7:42 AM, Jack L. Frost f...@fleshless.org wrote:
On Tue, Apr 28, 2015 at 08:03:02PM -0400, Jude Nelson wrote:
Hey everyone,
I have the latest news for vdev:
Hi. I dunno if it's very relevant to this particular mailing list, but
still.
I've packaged vdev and all
On Tue, Apr 28, 2015 at 08:03:02PM -0400, Jude Nelson wrote:
Hey everyone,
I have the latest news for vdev:
Hi. I dunno if it's very relevant to this particular mailing list, but still.
I've packaged vdev and all its dependencies for Arch:
https://aur.archlinux.org/packages/vdev-git
Yes, we need another MacroShaft screwing us over a barrel... NOT.
Sent from my Windows Phone
From: Laurent Bercotmailto:ska-de...@skarnet.org
Sent: 5/5/2015 3:21 PM
To: dng@lists.dyne.orgmailto:dng@lists.dyne.org
Subject: Re: [Dng] [dng] vdev status updates
Hello
* I then argue that in the current world, autocompletion is not
reliable, because since it does not stat(), it cannot hide filenames
the user cannot execute, such as a 0644 file. What your autocompletion
is currently printing is an approximation of the programs you can run,
not an
Hello again
0700 for root-only binaries would hide them from your shell's
autocompletion.
Which would be lots of stat() system calls.
If a shell doesn't make them, then it doesn't verify that a file is
executable either. (I just checked with zsh: it doesn't indeed.)
Sure, few
On 02.05.2015 15:40, Hendrik Boom wrote:
On Thu, Apr 30, 2015 at 11:42:24PM +0200, Didier Kryn wrote:
Le 30/04/2015 20:16, John Morris a écrit :
The FHS was carefully designed to accomodate things like NFS root,
Years ago I heard that /usr could be mounted read-only, and even shared
between
On Sun, May 03, 2015 at 06:37:06PM +0200, Joerg Reisenweber wrote:
On Sun 03 May 2015 11:15:45 Laurent Bercot wrote:
I remember 10ish years ago, mount was actually /sbin/mount.
It migrated to /bin at some point, probably, as you say, when the
user mount option was added. I personally think
On May 3, 2015 at 3:09 PM Hendrik Boom hend...@topoi.pooq.com wrote:
On Sun, May 03, 2015 at 06:37:06PM +0200, Joerg Reisenweber wrote:
Even in your dream distro without any path, don't tell me you won't *have*
*to* come up with another concept for attaching meta info alternative to
On Sun 03 May 2015 15:09:49 Hendrik Boom wrote:
files are identified *only* by metadata. Has anyone ever
tried something like this?
I guess tracker https://wiki.gnome.org/Projects/Tracker and the way it's
used by some apps / OS to locate data
http://maemo.org/packages/view/imageviewer/
On 03/05/2015 10:15, marc...@welz.org.za wrote:
So you have just argued that to hide things from autocompletion,
one should make things 0700. We have also established that
for this scheme to work the shell needs to do a stat() *for* *each*
*candidate* executable. But the my /bin/bash does not do
On Sun 03 May 2015 11:15:45 Laurent Bercot wrote:
I remember 10ish years ago, mount was actually /sbin/mount.
It migrated to /bin at some point, probably, as you say, when the
user mount option was added. I personally think that moving
executables between places is a bad thing, and one of the
On Sun, May 03, 2015 at 06:37:06PM +0200, Joerg Reisenweber wrote:
Even in your dream distro without any path, don't tell me you won't *have*
*to* come up with another concept for attaching meta info alternative to path
names, and then you need to update that instead of moving files
Taken
On Thu, Apr 30, 2015 at 11:42:24PM +0200, Didier Kryn wrote:
Le 30/04/2015 20:16, John Morris a écrit :
The FHS was carefully designed to accomodate things like NFS root,
readonly NFS mounting of parts of the system, mandating things like
*/share/ to only contain arch neutral data, etc.
On 02/05/2015 09:43, marc...@welz.org.za wrote:
0700 for root-only binaries would hide them from your shell's
autocompletion.
Which would be lots of stat() system calls.
If a shell doesn't make them, then it doesn't verify that a file is
executable either. (I just checked with zsh: it
On Sat 02 May 2015 11:01:07 Laurent Bercot wrote:
So there are very good reasons for keeping the classic/standard layout.
The reasons you gave so far are pretty minor.
The reasons you gave for *changing* stuff are negligible so far: iirc it was a
shorter PATH which would benefit some
/usr partition.
-Jim
From: dr.kl...@gmx.at
To: dng@lists.dyne.org
Date: Thu, 30 Apr 2015 10:12:30 +0200
Subject: Re: [Dng] [dng] vdev status updates
From the FreeBSD point of view:
https://www.freebsd.org/doc/en/books/handbook/dirstructure.html
Anyway, symlinking /bin to /usr/bin
Le 30/04/2015 01:27, Joerg Reisenweber a écrit :
On Wed 29 April 2015 23:46:51 Didier Kryn wrote:
They decided to put them on the second disk which contained user data
and was therefore mounted at /usr
AFAIK that's Unix System Resources or somesuch, not User
Maybe it's true, but it sounds
from time to time.
-Jim
Date: Thu, 30 Apr 2015 08:48:10 +0100
From: kato...@freaknet.org
To: reisenwe...@web.de
CC: dng@lists.dyne.org
Subject: Re: [Dng] [dng] vdev status updates
On Thu, Apr 30, 2015 at 01:27:48AM +0200, Joerg Reisenweber wrote:
On Wed 29 April
Le 30/04/2015 13:21, Joerg Reisenweber a écrit :
and here is more (sorry to link to the obvious):
http://www.pathname.com/fhs/pub/fhs-2.3.html (possibly outdated, I didn't
check for a long time)
Thanks Joerg, for recalling the link.
This FHS is nothing more than a summary of current
On Thu 30 April 2015 15:30:06 Didier Kryn wrote:
This FHS is nothing more than a summary of current practice; it
does not contain any sound rationale
I beg to differ on that, to me it seems it has all the sound rationale it
needs, to for example understand why /bin should have commands
On Thu 30 April 2015 19:02:54 Laurent Bercot wrote:
/sbin/route is not inherently better than
/bin/route; we are just used to /sbin/route and inertia does the rest - but
it would actually be *simpler* to just move everything to /bin and /usr/bin
and be rid of /sbin and /usr/sbin altogether. It
On Thu 30 April 2015 19:02:54 Laurent Bercot wrote:
- Made sense at the time, doesn't make sense today: the separation between
administrator commands (/sbin, /usr/sbin) and user commands (/bin,
/usr/bin). Back then, filesystems were slow and scaled badly, caches were
small, and it was costly
On Thu 30 April 2015 19:02:54 Laurent Bercot wrote:
It would also shorten PATHs,
which would be a definite blessing on some systems.
I guess - just like you said, and according to RFC2119 SHOULD (NOT) - you
could simply symlink /sbin to /bin on your system when there's a good reason
for doing
On 30/04/2015 22:35, Joerg Reisenweber wrote:
exactly this PATH issue is what I expect and appreciate here: I do NOT expect
command autocompletion of normal user to get confused by command names that
are not supposed to even be in user's PATH
0700 for root-only binaries would hide them from
Le 30/04/2015 20:16, John Morris a écrit :
The FHS was carefully designed to accomodate things like NFS root,
readonly NFS mounting of parts of the system, mandating things like
*/share/ to only contain arch neutral data, etc.
The whole FH can be shared by NFS root, except /var, which
On 29/04/15 02:03, Jude Nelson wrote:
Hey everyone,
Sorry for being incommunicado these past two weeks--I was working on a
conference paper that was due last Friday. Thank you all for being
patient!
I have the latest news for vdev:
[Status updates]
* Support for booting from LVM2
On Wed, Apr 29, 2015 at 5:46 PM, Didier Kryn k...@in2p3.fr wrote:
Le 29/04/2015 22:34, Hendrik Boom a écrit :
On Wed, Apr 29, 2015 at 10:47:27AM -0400, Steve Litt wrote:
I'm under the impression you can do most or all of what needs to be
done in the actual init, rather than the initramfs.
Le 29/04/2015 22:34, Hendrik Boom a écrit :
On Wed, Apr 29, 2015 at 10:47:27AM -0400, Steve Litt wrote:
I'm under the impression you can do most or all of what needs to be
done in the actual init, rather than the initramfs. This gets a little
complicated now that Linux has been improved by
Le 29/04/2015 19:07, Steve Litt a écrit :
On Wed, 29 Apr 2015 18:13:04 +0200
Didier Kryn k...@in2p3.fr wrote:
Le 29/04/2015 16:47, Steve Litt a écrit :
maybe then we could eliminate the initramfs step entirely.:-)
Sure that would be nice. It's something you can do for each
Le 29/04/2015 23:54, Jude Nelson a écrit :
On Wed, Apr 29, 2015 at 5:46 PM, Didier Kryn k...@in2p3.fr
mailto:k...@in2p3.fr wrote:
Le 29/04/2015 22:34, Hendrik Boom a écrit :
On Wed, Apr 29, 2015 at 10:47:27AM -0400, Steve Litt wrote:
I'm under the impression you
On Tue, 28 Apr 2015 20:03:02 -0400
Jude Nelson jud...@gmail.com wrote:
* Packaging. I'm working on a way to automatically build a .deb for
vdevd that will, among other things, safely generate and install an
initramfs without having to hack the initramfs tools (as is the case
today). Please
On Tue, Apr 28, 2015 at 08:03:02PM -0400, Jude Nelson wrote:
[TODO]
* I still need to figure out how to generate /dev/disk/by-partuuid and
/dev/v4l/by-path, and possibly others.
/dev/disk/by-partuuid does not exist on my udev-based Jessie install.
It would presumably be the PARTUUID=...
From: Jude Nelsonmailto:jud...@gmail.com
Sent: 4/28/2015 9:34 PM
To: Isaac Dunhammailto:ibid...@gmail.com
Cc: dng@lists.dyne.orgmailto:dng@lists.dyne.org
Subject: Re: [Dng] [dng] vdev status updates
Hi Isaac,
[Snip]
Theoretically, it *should* work if /etc/{passwd,group} are present
Hi Isaac,
[Snip]
Theoretically, it *should* work if /etc/{passwd,group} are present in the
initramfs, with those paths. It's possible to mistakenly copy them to /
instead of /etc, but I assume that you've already checked that.
Detail that shouldn't make a difference but might:
static or
34 matches
Mail list logo
