Hi James,
On Thu, Apr 30, 2015 at 4:26 AM, James Powell wrote:
> The discussion has not been favorable towards the adoption from current
> reading on LKML. Past tests have not proven reliability, nor any
> significant increase of speed of messaging across the IPC. Linus seems to
> be of no love
On 01/05/15 01:32, Franco Lanza wrote:
On Thu, Apr 30, 2015 at 01:44:47AM +0100, David Hare wrote:
debootstrap --exclude systemd,systemd-sysv,libsystemd0 jessie .
without specifying a URL is working here (are the excludes needed?)
However after I chroot it and apt update:
W: GPG error: http:
Am Donnerstag, den 30.04.2015, 23:58 +0100 schrieb Jaromil:
> after all, we really are a fork. we mean it.
*Me* applauds. And throwing away the outdated yet sane levels of
knowledge and wisdom has already proven to evocate disaster[1].
"Back then most things were better; and they were, of course,
Edward Bartolo writes:
> I replaced stable with jessie as follows. debootstrap did better but
> failed. These are the results:
>
> # debootstrap --arch amd64 jessie /mnt/sda8
http://packages.devuan.org/devuan/
>
> I: Extracting util-linux...
> W: Failure trying to run: chroot /mnt/sda8 mo
On Thu, Apr 30, 2015 at 01:44:47AM +0100, David Hare wrote:
>
> debootstrap --exclude systemd,systemd-sysv,libsystemd0 jessie .
>
> without specifying a URL is working here (are the excludes needed?)
>
> However after I chroot it and apt update:
>
> W: GPG error: http://packages.devuan.org jess
On April 29, 2015 1:19:25 PM GMT+01:00, Hendrik Boom
wrote:
>On Sun, Apr 26, 2015 at 12:31:16AM +0200, Franco Lanza wrote:
>> On Sat, Apr 25, 2015 at 05:16:42PM -0400, Hendrik Boom wrote:
>> >
>> > acpid and acpi-support-base have already been removed from tasksel.
>>
>>
>> We already forked
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 yo
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 can
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 doi
On Thu, Apr 30, 2015 at 10:32:54PM +0200, Joerg Reisenweber wrote:
> 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,
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.
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 cos
I respectfully like the aspect of the FHS. While parts of it are dated and
could use a recasting, the core logic of separating kernel, admin, and user
tools, libraries, and having them available in stages.
It shouldn't be scrapped by any means, or unified. Tools as certain stages need
to be mad
On 30/04/2015 20:16, John Morris wrote:
He is correct on this point. One should always obey the rules until you
understand why the rule was made and the consequences of breaking it.
Except that the rule we're talking about just shouldn't be violated.
Once upon a time the rule was that / sh
On Thu, 2015-04-30 at 15:58 +0200, Joerg Reisenweber wrote:
> Poettering clearly understood the implications and outright rejected the
> rationale, by claiming nowadays it wasn't modern anymore to have a small root-
> fs and a separate partition for /usr
He is correct on this point. One should
On 30/04/2015 15:58, Joerg Reisenweber wrote:
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 that are needed
during early boot, before /usr gets mounted.
Thus FHS is not only a summary of current practice b
On Wed, Apr 29, 2015 at 12:33:52AM -0400, Jude Nelson wrote:
> (i.e. a device file
> that shows up in devtmpfs from the kernel does not generate an inotify
> event).
I wonder if that's a bug or a feature.
-- hendrik
___
Dng mailing list
Dng@lists.dyne
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 t
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 pr
On Thu 30 April 2015 10:12:30 Dr. Nikolaus Klepp wrote:
> From the FreeBSD point of view:
>
> https://www.freebsd.org/doc/en/books/handbook/dirstructure.html
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 l
On 28/04/15 21:00, Alex 'AdUser' Z wrote:
https://news.ycombinator.com/item?id=9450806
Hot discussion about merging kdbus in kernel.
TL;DR: The people who talk about how kdbus improves performance are just
full of sh*t. (c) Linus
It is certainly a deep and wide ranging thread. When looked at
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 s
Symlinking /bin to /usr/bin only seems like they are trying for a unified tree
approach which is an ill design. If that's the case they should just install
everything in /opt in it's own micro-tree/branch. Yes, it doesn't make sense
because you have to use an initramfs if you use a separated /us
The discussion has not been favorable towards the adoption from current reading
on LKML. Past tests have not proven reliability, nor any significant increase
of speed of messaging across the IPC. Linus seems to be of no love for it.
IMO from the collective discussion, kdbus doesn't seem to be r
>From my personal knowledge, having built LFS a few times, though this doesn't
>compare with other distributions as the purposes of /(root), /usr, /opt, and
>/usr/local have changed over the years:
/(root) is where boot-time software is to be installed that must be readily
available when the s
From the FreeBSD point of view:
https://www.freebsd.org/doc/en/books/handbook/dirstructure.html
Anyway, symlinking /bin to /usr/bin is quite strange.
Nik
Am Donnerstag, 30. April 2015 schrieb James Powell:
> From my personal knowledge, having built LFS a few times, though this doesn't
> compar
Having watched other systems transitioning to systemd, I wouldn't be surprised
if they did, or the projects get pushed into forced deprecation as ConsoleKit
did before it was revived.
-Jim
> Date: Wed, 29 Apr 2015 08:19:25 -0400
> From: hend...@topoi.pooq.com
> To: dng@lists.dyne.org
> Subjec
On Thu, Apr 30, 2015 at 01:27:48AM +0200, Joerg Reisenweber wrote:
> 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"
> /j
28 matches
Mail list logo
