Re: [Dng] libsysdev preview

[Jude Nelson]

I was looking through how FreeBSD handles the lack of udev while still
supporting Mesa, and it seems they patched it to use their libdevq [1].  I
wonder if there's some overlap with libsysdev here that can be put to use
for us...

-Jude

[1] https://github.com/freebsd/libdevq

On Tue, Jan 20, 2015 at 12:01 AM, Jude Nelson  wrote:

> Hi Isaac,
>
> > I was asking about implementation details (something like the HACKING
> > document that many projects have, giving an overview of how it works
> > internally).
>
> Good idea; I'll add one.
>
> > I'm getting the impression that libsysdev won't really make a good
> > backend for the udev API; libudev is a much more low-level interface,
> > with somewhat different logical division and flow.
> > (Abstractly, I'd be happy if it did work. But wasting time for the sake
> > of promoting libsysdev isn't going to help replace udev.)
>
> Interestingly, the libudev API doesn't look that tightly coupled to the
> udev implementation to begin with, which is why I consider libudev-compat
> to be feasible.  Namely, I'm going with the following implementation
> strategy:
>
> udev:  library state catch-all
> udev_list:  this is just a linked list implementation of (key, value)
> pairs, which some other methods in libudev happen to return
> udev_device: mostly, this is reading data from sysfs and /dev.  Not sure
> yet about device properties, but I'll figure something out.  Might want to
> use libsysdev here, and/or recycle parts of vdev's linux back-end.
> udev_monitor:  don't even bother with netlink.  Just inotify-monitor /dev
> for changes, so even a static dev will generate events.
> udev_enumerate:  this is just applying a generic set of filters on a sysfs
> directory listing.
> udev_queue:  don't bother connecting to udev.  Just inotify-monitor /dev
> again, but do so in the background (i.e. on library init).
> udev_hwdb:  read udev hwdb files
> udev_util:  only one string-encoding method; nothing to see here.
>
> -Jude
>
>
> On Mon, Jan 19, 2015 at 10:55 PM, Isaac Dunham  wrote:
>
>> On Mon, Jan 19, 2015 at 08:56:10PM -0500, Jude Nelson wrote:
>> > Regarding the architecture, I have a design document here:
>> > http://judecnelson.blogspot.com/2015/01/introducing-vdev.html  Is this
>> what
>> > you're looking for?  Or did you want a more low-level document
>> describing
>> > the implementation details?
>>
>> I was asking about implementation details (something like the HACKING
>> document that many projects have, giving an overview of how it works
>> internally).
>>
>> Being mainly acquainted with C, I might not be able to follow it myself,
>> but it may well be useful for people who want to contribute.
>>
>> > Regarding whitespace, my style is based on Stroustrup's adaptation of
>> K&R.
>> > I add whitespace where I do because it helps me read code better and add
>> > comments.
>>
>> Ah.
>> I find that the Linux kernel style (also based on K&R) seems most clear
>> to me; it seems quite different on the surface.
>> (Styles are styles, though. There's always variation.)
>>
>> > Looking forward to seeing what you do with libsysdev :)  I'm seriously
>> > considering moving libudev-compat out of vdev entirely, and having it
>> use
>> > libsysdev as a backend (either way, I don't want it to be coupled to
>> vdev).
>> >
>>
>> I'm getting the impression that libsysdev won't really make a good
>> backend for the udev API; libudev is a much more low-level interface,
>> with somewhat different logical division and flow.
>> (Abstractly, I'd be happy if it did work. But wasting time for the sake
>> of promoting libsysdev isn't going to help replace udev.)
>>
>>
>> Thanks for the comments!
>>
>> Isaac Dunham
>>
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] libsysdev preview

[Steve Litt]

Hi Jude,

I thought you were making vdev to plug replace udev. By the way, when
it's ready, I have several Epoch and runit experimental setups I'd like
to use it on.

Thanks,

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance



On Thu, 22 Jan 2015 09:50:11 -0500
Jude Nelson  wrote:

> I was looking through how FreeBSD handles the lack of udev while still
> supporting Mesa, and it seems they patched it to use their libdevq
> [1].  I wonder if there's some overlap with libsysdev here that can
> be put to use for us...
> 
> -Jude
> 
> [1] https://github.com/freebsd/libdevq
> 
> On Tue, Jan 20, 2015 at 12:01 AM, Jude Nelson 
> wrote:
> 
> > Hi Isaac,
> >
> > > I was asking about implementation details (something like the
> > > HACKING document that many projects have, giving an overview of
> > > how it works internally).
> >
> > Good idea; I'll add one.
> >
> > > I'm getting the impression that libsysdev won't really make a good
> > > backend for the udev API; libudev is a much more low-level
> > > interface, with somewhat different logical division and flow.
> > > (Abstractly, I'd be happy if it did work. But wasting time for
> > > the sake of promoting libsysdev isn't going to help replace udev.)
> >
> > Interestingly, the libudev API doesn't look that tightly coupled to
> > the udev implementation to begin with, which is why I consider
> > libudev-compat to be feasible.  Namely, I'm going with the
> > following implementation strategy:
> >
> > udev:  library state catch-all
> > udev_list:  this is just a linked list implementation of (key,
> > value) pairs, which some other methods in libudev happen to return
> > udev_device: mostly, this is reading data from sysfs and /dev.  Not
> > sure yet about device properties, but I'll figure something out.
> > Might want to use libsysdev here, and/or recycle parts of vdev's
> > linux back-end. udev_monitor:  don't even bother with netlink.
> > Just inotify-monitor /dev for changes, so even a static dev will
> > generate events. udev_enumerate:  this is just applying a generic
> > set of filters on a sysfs directory listing.
> > udev_queue:  don't bother connecting to udev.  Just
> > inotify-monitor /dev again, but do so in the background (i.e. on
> > library init). udev_hwdb:  read udev hwdb files
> > udev_util:  only one string-encoding method; nothing to see here.
> >
> > -Jude
> >
> >
> > On Mon, Jan 19, 2015 at 10:55 PM, Isaac Dunham 
> > wrote:
> >
> >> On Mon, Jan 19, 2015 at 08:56:10PM -0500, Jude Nelson wrote:
> >> > Regarding the architecture, I have a design document here:
> >> > http://judecnelson.blogspot.com/2015/01/introducing-vdev.html
> >> > Is this
> >> what
> >> > you're looking for?  Or did you want a more low-level document
> >> describing
> >> > the implementation details?
> >>
> >> I was asking about implementation details (something like the
> >> HACKING document that many projects have, giving an overview of
> >> how it works internally).
> >>
> >> Being mainly acquainted with C, I might not be able to follow it
> >> myself, but it may well be useful for people who want to
> >> contribute.
> >>
> >> > Regarding whitespace, my style is based on Stroustrup's
> >> > adaptation of
> >> K&R.
> >> > I add whitespace where I do because it helps me read code better
> >> > and add comments.
> >>
> >> Ah.
> >> I find that the Linux kernel style (also based on K&R) seems most
> >> clear to me; it seems quite different on the surface.
> >> (Styles are styles, though. There's always variation.)
> >>
> >> > Looking forward to seeing what you do with libsysdev :)  I'm
> >> > seriously considering moving libudev-compat out of vdev
> >> > entirely, and having it
> >> use
> >> > libsysdev as a backend (either way, I don't want it to be
> >> > coupled to
> >> vdev).
> >> >
> >>
> >> I'm getting the impression that libsysdev won't really make a good
> >> backend for the udev API; libudev is a much more low-level
> >> interface, with somewhat different logical division and flow.
> >> (Abstractly, I'd be happy if it did work. But wasting time for the
> >> sake of promoting libsysdev isn't going to help replace udev.)
> >>
> >>
> >> Thanks for the comments!
> >>
> >> Isaac Dunham
> >>
> >
> >



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] libsysdev preview

[Jude Nelson]

Hi Steve,

That's the plan :).  However, one aspect of replacing udev with vdev is
making a libudev compatibility library that will let us use exiting
programs and libraries (like Mesa) without having to patch them.  This
libudev-compat will probably make use of libsysdev and possibly OS-specific
libraries like libdevq, and for inspiration I was looking at what other OSs
do to address the lack of udev (it seems they have been patching out
libudev support so far, but it also looks like this is getting harder and
harder).  If possible, I'd write libudev-compat so that it won't even
depend on vdev--ideally, people could use it with a static /dev if they
wanted, or some other non-Linux device manager like devfs.

-Jude



On Thu, Jan 22, 2015 at 9:54 AM, Steve Litt 
wrote:

> Hi Jude,
>
> I thought you were making vdev to plug replace udev. By the way, when
> it's ready, I have several Epoch and runit experimental setups I'd like
> to use it on.
>
> Thanks,
>
> SteveT
>
> Steve Litt*  http://www.troubleshooters.com/
> Troubleshooting Training  *  Human Performance
>
>
>
> On Thu, 22 Jan 2015 09:50:11 -0500
> Jude Nelson  wrote:
>
> > I was looking through how FreeBSD handles the lack of udev while still
> > supporting Mesa, and it seems they patched it to use their libdevq
> > [1].  I wonder if there's some overlap with libsysdev here that can
> > be put to use for us...
> >
> > -Jude
> >
> > [1] https://github.com/freebsd/libdevq
> >
> > On Tue, Jan 20, 2015 at 12:01 AM, Jude Nelson 
> > wrote:
> >
> > > Hi Isaac,
> > >
> > > > I was asking about implementation details (something like the
> > > > HACKING document that many projects have, giving an overview of
> > > > how it works internally).
> > >
> > > Good idea; I'll add one.
> > >
> > > > I'm getting the impression that libsysdev won't really make a good
> > > > backend for the udev API; libudev is a much more low-level
> > > > interface, with somewhat different logical division and flow.
> > > > (Abstractly, I'd be happy if it did work. But wasting time for
> > > > the sake of promoting libsysdev isn't going to help replace udev.)
> > >
> > > Interestingly, the libudev API doesn't look that tightly coupled to
> > > the udev implementation to begin with, which is why I consider
> > > libudev-compat to be feasible.  Namely, I'm going with the
> > > following implementation strategy:
> > >
> > > udev:  library state catch-all
> > > udev_list:  this is just a linked list implementation of (key,
> > > value) pairs, which some other methods in libudev happen to return
> > > udev_device: mostly, this is reading data from sysfs and /dev.  Not
> > > sure yet about device properties, but I'll figure something out.
> > > Might want to use libsysdev here, and/or recycle parts of vdev's
> > > linux back-end. udev_monitor:  don't even bother with netlink.
> > > Just inotify-monitor /dev for changes, so even a static dev will
> > > generate events. udev_enumerate:  this is just applying a generic
> > > set of filters on a sysfs directory listing.
> > > udev_queue:  don't bother connecting to udev.  Just
> > > inotify-monitor /dev again, but do so in the background (i.e. on
> > > library init). udev_hwdb:  read udev hwdb files
> > > udev_util:  only one string-encoding method; nothing to see here.
> > >
> > > -Jude
> > >
> > >
> > > On Mon, Jan 19, 2015 at 10:55 PM, Isaac Dunham 
> > > wrote:
> > >
> > >> On Mon, Jan 19, 2015 at 08:56:10PM -0500, Jude Nelson wrote:
> > >> > Regarding the architecture, I have a design document here:
> > >> > http://judecnelson.blogspot.com/2015/01/introducing-vdev.html
> > >> > Is this
> > >> what
> > >> > you're looking for?  Or did you want a more low-level document
> > >> describing
> > >> > the implementation details?
> > >>
> > >> I was asking about implementation details (something like the
> > >> HACKING document that many projects have, giving an overview of
> > >> how it works internally).
> > >>
> > >> Being mainly acquainted with C, I might not be able to follow it
> > >> myself, but it may well be useful for people who want to
> > >> contribute.
> > >>
> > >> > Regarding whitespace, my style is based on Stroustrup's
> > >> > adaptation of
> > >> K&R.
> > >> > I add whitespace where I do because it helps me read code better
> > >> > and add comments.
> > >>
> > >> Ah.
> > >> I find that the Linux kernel style (also based on K&R) seems most
> > >> clear to me; it seems quite different on the surface.
> > >> (Styles are styles, though. There's always variation.)
> > >>
> > >> > Looking forward to seeing what you do with libsysdev :)  I'm
> > >> > seriously considering moving libudev-compat out of vdev
> > >> > entirely, and having it
> > >> use
> > >> > libsysdev as a backend (either way, I don't want it to be
> > >> > coupled to
> > >> vdev).
> > >> >
> > >>
> > >> I'm getting the impression that libsysdev won't really make a good
> > >> backend for the udev API; libudev is a much more low-level
> > >> interface

Re: [Dng] libsysdev preview

[Steve Litt]

Cool Jude!

As a member of the "minimum dependencies" crew, I just have to ask:
Would libsysdev, libdevq et al already be installed on a native Systemd
installation? It's important that vdev be easily installable, without
too much dependency hell.

Please tell me when vdev is ready for testing on systems like
Manjaro-systemd and CentOS. I'll derive great satisfaction from further
incursions into Redhat's territory.

Thanks,

SteveT



On Thu, 22 Jan 2015 10:09:50 -0500
Jude Nelson  wrote:

> Hi Steve,
> 
> That's the plan :).  However, one aspect of replacing udev with vdev
> is making a libudev compatibility library that will let us use exiting
> programs and libraries (like Mesa) without having to patch them.  This
> libudev-compat will probably make use of libsysdev and possibly
> OS-specific libraries like libdevq, and for inspiration I was looking
> at what other OSs do to address the lack of udev (it seems they have
> been patching out libudev support so far, but it also looks like this
> is getting harder and harder).  If possible, I'd write libudev-compat
> so that it won't even depend on vdev--ideally, people could use it
> with a static /dev if they wanted, or some other non-Linux device
> manager like devfs.
> 
> -Jude
> 
> 
> 
> On Thu, Jan 22, 2015 at 9:54 AM, Steve Litt
>  wrote:
> 
> > Hi Jude,
> >
> > I thought you were making vdev to plug replace udev. By the way,
> > when it's ready, I have several Epoch and runit experimental setups
> > I'd like to use it on.
> >
> > Thanks,
> >
> > SteveT
> >
> > Steve Litt*  http://www.troubleshooters.com/
> > Troubleshooting Training  *  Human Performance
> >
> >
> >
> > On Thu, 22 Jan 2015 09:50:11 -0500
> > Jude Nelson  wrote:
> >
> > > I was looking through how FreeBSD handles the lack of udev while
> > > still supporting Mesa, and it seems they patched it to use their
> > > libdevq [1].  I wonder if there's some overlap with libsysdev
> > > here that can be put to use for us...
> > >
> > > -Jude
> > >
> > > [1] https://github.com/freebsd/libdevq
> > >
> > > On Tue, Jan 20, 2015 at 12:01 AM, Jude Nelson 
> > > wrote:
> > >
> > > > Hi Isaac,
> > > >
> > > > > I was asking about implementation details (something like the
> > > > > HACKING document that many projects have, giving an overview
> > > > > of how it works internally).
> > > >
> > > > Good idea; I'll add one.
> > > >
> > > > > I'm getting the impression that libsysdev won't really make a
> > > > > good backend for the udev API; libudev is a much more
> > > > > low-level interface, with somewhat different logical division
> > > > > and flow. (Abstractly, I'd be happy if it did work. But
> > > > > wasting time for the sake of promoting libsysdev isn't going
> > > > > to help replace udev.)
> > > >
> > > > Interestingly, the libudev API doesn't look that tightly
> > > > coupled to the udev implementation to begin with, which is why
> > > > I consider libudev-compat to be feasible.  Namely, I'm going
> > > > with the following implementation strategy:
> > > >
> > > > udev:  library state catch-all
> > > > udev_list:  this is just a linked list implementation of (key,
> > > > value) pairs, which some other methods in libudev happen to
> > > > return udev_device: mostly, this is reading data from sysfs
> > > > and /dev.  Not sure yet about device properties, but I'll
> > > > figure something out. Might want to use libsysdev here, and/or
> > > > recycle parts of vdev's linux back-end. udev_monitor:  don't
> > > > even bother with netlink. Just inotify-monitor /dev for
> > > > changes, so even a static dev will generate events.
> > > > udev_enumerate:  this is just applying a generic set of filters
> > > > on a sysfs directory listing. udev_queue:  don't bother
> > > > connecting to udev.  Just inotify-monitor /dev again, but do so
> > > > in the background (i.e. on library init). udev_hwdb:  read udev
> > > > hwdb files udev_util:  only one string-encoding method; nothing
> > > > to see here.
> > > >
> > > > -Jude
> > > >
> > > >
> > > > On Mon, Jan 19, 2015 at 10:55 PM, Isaac Dunham
> > > >  wrote:
> > > >
> > > >> On Mon, Jan 19, 2015 at 08:56:10PM -0500, Jude Nelson wrote:
> > > >> > Regarding the architecture, I have a design document here:
> > > >> > http://judecnelson.blogspot.com/2015/01/introducing-vdev.html
> > > >> > Is this
> > > >> what
> > > >> > you're looking for?  Or did you want a more low-level
> > > >> > document
> > > >> describing
> > > >> > the implementation details?
> > > >>
> > > >> I was asking about implementation details (something like the
> > > >> HACKING document that many projects have, giving an overview of
> > > >> how it works internally).
> > > >>
> > > >> Being mainly acquainted with C, I might not be able to follow
> > > >> it myself, but it may well be useful for people who want to
> > > >> contribute.
> > > >>
> > > >> > Regarding whitespace, my style is based on Stroustrup's
> > > >> > adaptation of
> > > >> K&R.
> > > >> > I add whitespace 

Re: [Dng] libsysdev preview

[Jude Nelson]

Hi Steve,

libdevq is FreeBSD-specific, and libsysdev would probably be the only
libudev-compat dependency on Linux besides libc and friends.

vdev is almost ready for some initial testing.  It still needs some
boilerplate code and an init script, but I plan on adding that next.  My
latest patches were focused on removing the C++ dependency, so you don't
need /usr to be mounted on boot.

vdev outsources most of its device initialization functionality to shell
scripts that get invoked on device discovery.  A big part of the remaining
functional gap between udev and vdev is in writing shell scripts that set
up all the persistent names that udev rules set up (i.e. things like the
symlinks in /dev/input/by-path or /dev/disks/by-id, etc.).  I'm about
half-way through that.  It's slow-going, since udev's helper programs that
get the requisite information for persistent names are sparsely-documented
at best, as are the rules files and the persistent naming conventions (if
someone has some good documentation on this, I'd love to know about it).

The other big functional gap is in getting vdev to set up network
interfaces--namely, giving them persistent names, and (specific to
Debian/Devuan) invoking the ifupdown framework.  I'm not that well-versed
with ifupdown since I've always used my own scripts for setting up my
network, but at some point I'll have to figure out how to do this.
However, the implementation strategy is the same--it's just a matter of
writing a shell script for vdev to invoke when it discovers a network
device.

I'll post tarballs as soon as I've gotten vdev to the point where I can use
it to boot up a VM :)

-Jude

On Thu, Jan 22, 2015 at 10:32 AM, Steve Litt 
wrote:

> Cool Jude!
>
> As a member of the "minimum dependencies" crew, I just have to ask:
> Would libsysdev, libdevq et al already be installed on a native Systemd
> installation? It's important that vdev be easily installable, without
> too much dependency hell.
>
> Please tell me when vdev is ready for testing on systems like
> Manjaro-systemd and CentOS. I'll derive great satisfaction from further
> incursions into Redhat's territory.
>
> Thanks,
>
> SteveT
>
>
>
> On Thu, 22 Jan 2015 10:09:50 -0500
> Jude Nelson  wrote:
>
> > Hi Steve,
> >
> > That's the plan :).  However, one aspect of replacing udev with vdev
> > is making a libudev compatibility library that will let us use exiting
> > programs and libraries (like Mesa) without having to patch them.  This
> > libudev-compat will probably make use of libsysdev and possibly
> > OS-specific libraries like libdevq, and for inspiration I was looking
> > at what other OSs do to address the lack of udev (it seems they have
> > been patching out libudev support so far, but it also looks like this
> > is getting harder and harder).  If possible, I'd write libudev-compat
> > so that it won't even depend on vdev--ideally, people could use it
> > with a static /dev if they wanted, or some other non-Linux device
> > manager like devfs.
> >
> > -Jude
> >
> >
> >
> > On Thu, Jan 22, 2015 at 9:54 AM, Steve Litt
> >  wrote:
> >
> > > Hi Jude,
> > >
> > > I thought you were making vdev to plug replace udev. By the way,
> > > when it's ready, I have several Epoch and runit experimental setups
> > > I'd like to use it on.
> > >
> > > Thanks,
> > >
> > > SteveT
> > >
> > > Steve Litt*  http://www.troubleshooters.com/
> > > Troubleshooting Training  *  Human Performance
> > >
> > >
> > >
> > > On Thu, 22 Jan 2015 09:50:11 -0500
> > > Jude Nelson  wrote:
> > >
> > > > I was looking through how FreeBSD handles the lack of udev while
> > > > still supporting Mesa, and it seems they patched it to use their
> > > > libdevq [1].  I wonder if there's some overlap with libsysdev
> > > > here that can be put to use for us...
> > > >
> > > > -Jude
> > > >
> > > > [1] https://github.com/freebsd/libdevq
> > > >
> > > > On Tue, Jan 20, 2015 at 12:01 AM, Jude Nelson 
> > > > wrote:
> > > >
> > > > > Hi Isaac,
> > > > >
> > > > > > I was asking about implementation details (something like the
> > > > > > HACKING document that many projects have, giving an overview
> > > > > > of how it works internally).
> > > > >
> > > > > Good idea; I'll add one.
> > > > >
> > > > > > I'm getting the impression that libsysdev won't really make a
> > > > > > good backend for the udev API; libudev is a much more
> > > > > > low-level interface, with somewhat different logical division
> > > > > > and flow. (Abstractly, I'd be happy if it did work. But
> > > > > > wasting time for the sake of promoting libsysdev isn't going
> > > > > > to help replace udev.)
> > > > >
> > > > > Interestingly, the libudev API doesn't look that tightly
> > > > > coupled to the udev implementation to begin with, which is why
> > > > > I consider libudev-compat to be feasible.  Namely, I'm going
> > > > > with the following implementation strategy:
> > > > >
> > > > > udev:  library state catch-all
> > > > > udev_list:  this is just a li

Re: [Dng] libsysdev preview

[Isaac Dunham]

On Thu, Jan 22, 2015 at 10:32:39AM -0500, Steve Litt wrote:
> Cool Jude!
> 
> As a member of the "minimum dependencies" crew, I just have to ask:
> Would libsysdev, libdevq et al already be installed on a native Systemd
> installation? It's important that vdev be easily installable, without
> too much dependency hell.
> 
> Please tell me when vdev is ready for testing on systems like
> Manjaro-systemd and CentOS. I'll derive great satisfaction from further
> incursions into Redhat's territory.
Realistically, libsysdev will almost certainly not be preinstalled on a
systemd based installation in the near future. It may well not be 
preinstalled *anywhere* for several months, if it does catch on.

libsysdev is not intended to have any requirements beyond a libc that
supports POSIX 2001 (_XOPEN_SOURCE=600) and _ATFILE_SOURCE.
That is equivalent to POSIX 2008 (_XOPEN_SOURCE=700), and should be
available since glibc 2.4 or in any version of musl.

Yes, I'm in favor of minimal dependencies. If a command-line tool needs
more than libc, I start wondering why.

Thanks,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Announcing libsysdev 0.1.0

[Isaac Dunham]

On Wed, Jan 21, 2015 at 09:49:37PM -0500, Jude Nelson wrote:
> Hey, this is cool!  Looking forward to putting it to use in libudev-compat,
> since it looks like I'll be needing a way to find a device file's sysfs
> path.
> 

Glad to hear that it will be useful.
Is sysdev_devfd_to_syspath() or sysdev_getsyspath() optimal for you?
Are there any adjustments to the API that would make it easier to use?

Thanks,
Isaac Dunham

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] libsysdev preview

[Steve Litt]

On Thu, 22 Jan 2015 09:27:21 -0800
Isaac Dunham  wrote:

> On Thu, Jan 22, 2015 at 10:32:39AM -0500, Steve Litt wrote:
> > Cool Jude!
> > 
> > As a member of the "minimum dependencies" crew, I just have to ask:
> > Would libsysdev, libdevq et al already be installed on a native
> > Systemd installation? It's important that vdev be easily
> > installable, without too much dependency hell.
> > 
> > Please tell me when vdev is ready for testing on systems like
> > Manjaro-systemd and CentOS. I'll derive great satisfaction from
> > further incursions into Redhat's territory.
> Realistically, libsysdev will almost certainly not be preinstalled on
> a systemd based installation in the near future. It may well not be 
> preinstalled *anywhere* for several months, if it does catch on.
> 
> libsysdev is not intended to have any requirements beyond a libc that
> supports POSIX 2001 (_XOPEN_SOURCE=600) and _ATFILE_SOURCE.
> That is equivalent to POSIX 2008 (_XOPEN_SOURCE=700), and should be
> available since glibc 2.4 or in any version of musl.
> 
> Yes, I'm in favor of minimal dependencies. If a command-line tool
> needs more than libc, I start wondering why.

This is great news, Isaac!

If libsysdev can be compiled with no requirements other than a modern
libc, that's pretty much as good as having it package-installed!

I'm looking forward to getting rid of my udev.

Thanks!

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Upgrade paths

[Franco Lanza]

On Wed, Jan 21, 2015 at 11:05:04PM +, Noel Torres wrote:
> I've been thinking around the upgrade paths we need to provide for Devuan 1 
> "Jessie without systemd" (I'd still like ancient site names or computing 
> people names, so for me it is Devuan اَلْحَمْرَاء (put it on sources.list as 
> Devuan 
> Alhambra) or Devuan Aiken).

To let the upgrade path more easy and transparent, devuan 1 will be
called jessie.

From post devuan 1 release, we will choose our codenames...


> We must support users coming from Debian. That's why we are here. But which 
> Debian?
> 
> I think we should provide upgrade paths both for Jessie and for Wheezy.

yes, of course!


> Moving from Jessie to Aiken is not really an upgrade, and should be pretty 
> straightforward if the computer used the provided means at Debian to not have 
> systemd, and a bit harder, but not too much, if it is a Jessie with systemd 
> and the work is to free it.
> 
> Moving from Wheezy to Aiken is really an upgrade, but most of the work would 
> have been done at Debian already, so it should not be so hard.

Moving from debian jessie to devuan jessie it's matter to execute a
script or manually install a package and then fix dependencies. it
should be fairly trivial, except for complex gnome based configs
probably.

Moving from debian wheezy to devuan jessie should be as easy as
dist-upgrade to debian jessie, except we will need to choose what to do
with complex gnome based installs.

In both case we will probably stick on systemd-shim for devuan jessie,
and then move on loginkit or something like that in future.


> Any other paths we should think about?

Only one another path should be officially supported: the install from
scratch using devuan installer


> Regards
> er Envite



> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


-- 

Franco (nextime) Lanza
Lonate Pozzolo (VA) - Italy
SIP://c...@casa.nexlab.it
web: http://www.nexlab.net

NO TCPA: http://www.no1984.org
you can download my public key at:
http://danex.nexlab.it/nextime.asc || Key Servers
Key ID = D6132D50
Key fingerprint = 66ED 5211 9D59 DA53 1DF7  4189 DFED F580 D613 2D50
---
echo 
16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq
 | dc
---



signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] libsysdev preview

[Aldemir Akpinar]

On 22 January 2015 at 18:05, Jude Nelson  wrote:

> Hi Steve,
>  
>
> Many, many thanks Isaac & Jude. We have great new alternative to udev
happening here. And the best thing is that, you guys are listening to your
potential users!
I think your code will make a great deal of difference in the linux world!
I'm excited I must say.
--
aldemir
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] sugestion apulse as pulseaudio replcement

[Sean Davis]

I would love to see jack as a default or as an optional package with sane
defaults. If pulse is really needed,it works as a jack client. I have to
kill -9 pulse frequently as it leaks badly and won't die; jack only goes
crazy when I misconfigure it.
On Dec 25, 2014 9:15 PM, "Martinx - ジェームズ" 
wrote:

> Can you guys believe this:
>
> A Desktop with 6G of RAM running Ubuntu 14.10 with systemd + pulseaudio:
>
>
> USER   PID %CPU *%MEM*VSZ   RSS TTY  STAT START   TIME COMMAND
> userzyx   25830   0.3*75.0*   6171772 4487884 ? S /usr/bin/pulseaudio --start --log-target=syslog
>
>
> Pulseaudio is consuming *75% of my RAM MEMORY!!!* WTF IS THIS THING??!!!
> And I'm not playing a single music!
>
> I still do not believe that Debian was taken over by the shit that come
> out of Lennart / RedHat (sorry about the bad words). And the Linux
> community will put almost all the eggs into the systemd basket!! For God's
> sake, what a fuck is wrong with those people??? Well, I really don't care
> anymore, we have Devuan! YAY!^_^
>
> I was trusting my professional life on Debian team and now, this crap...
> The good of open source is that we have the power to make forks... Whew!
>
> You guys can count on me to make Devuan, the BEST Linux distribution EVER!
>
> Lets include apulse and also, jackd. And *kick* pulseaudio alongside with
> systemd.
>
> Honestly, I don't even care anymore about systemd, neither as an option,
> it is impossible to trust on this thing, because of Lennart past projects
> (and obvious, because of systemd terrible / creepy architecture). I still
> open to uselessd + new udev, if it make easier to keep compatibility with
> upstream Debian while we need to keep syncing with it. Also, I like the
> idea of CGroup Process, if uselessd can achieve that (i.e, control/isolate
> process using Linux CGroups), then, it is a great thing! There are space
> for a new Init System and systemd is NOT it.
>
> Happy new year!   :-)
>
> On 25 December 2014 at 19:27, m_maass  wrote:
>
>>  Dear Friends,
>>
>> my motivation  for use apulse is the follow:
>> i like simple systems, witch do what they say and no more.
>> Sometime i need sound from my PC, and i use/have ALSA.
>> Some software, especialy actual skype work only with PA or with this
>> nice part of sofware.
>>
>> I do not need "a network-capable sound server
>>  hosted at freedesktop.org
>> ." (from
>> http://en.wikipedia.org/wiki/PulseAudio).
>> This is the same problem as with systemd, the software do mutch more that
>> i want.
>>
>> The discussion about the suggestion had opened my eyes, that replacement
>> is not the best way, we should have both, if someone need the extra
>> functionality/addons.( for me are thes unwanted addons).  But how?
>>
>> 1. Idealy programs sould use ALSA and optionaly PA.
>> 2. forget the software that is only PA capable and use some alternative
>> or make it ALSA capable.
>> 2.1. use apulse, apulse make for each known application that do only work
>> with PA one wrapper script, that replace the original program.
>> 3. some other ideas?
>>
>> The problem is similar to this with systemd, if we replace ALSA->arbitary
>> init, and PA-> systemd, apulse ~>systemd-shim, skype->gnome.
>>
>> With devuan we make the same steps, right?
>>
>> Regards,
>> Mike
>>
>> On 24.12.2014 18:13, m_maass wrote:
>>
>> Dear Freedom lovers,
>>
>> i would suggest to you this project
>> https://github.com/i-rinat/apulse
>>
>> and would say thank for your efforts.
>>
>> Cheers, and Happy Grav'Mass!
>>
>> Mike
>>
>>
>>
>>
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] TPM

[Dr. Nikolaus Klepp]

Am Dienstag, 23. Dezember 2014 schrieb John Morris:
> On Mon, 2014-12-22 at 17:23 -0600, T.J. Duchene wrote:
> 
> > What can it do in the right? Nothing that can't be done without the TPM 
> > chip.  One of the first things that you learn in computer engineering is 
> > that anything problem can be solved on software or hardware.  The only 
> > difference is a question of efficiency.
> 
> Keep to the fundamentals.  TPM is all about trust.  So long as I'm using
> it to enhance my trust that the machines under my control are actually
> under my control I deem it a good thing.  If it is to be used to let
> somebody ELSE trust my machines in ways I can't control I'm probably not
> going to put up with it and disable the chip.  Just that simple, just
> look at who is trusting who and the question of whether it is good
> clears up instantly.
> 
> And yes, putting the thing in hardware does enhance security in ways
> software alone simply can't.
> 

… and if you believe that, I have a bridge to sell you.

Nik

-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[Dng] Consolekit2

[Aaditya Bagga]

Hi,

I am not sure if you guys are aware or not, but Consolekit2 is the 
original endeavor of Eric Koegel I believe [1], yet I see no mention of 
his name on the Devuan December 22 newsletter [2] under the Research -> 
Consolekit heading.


I am not affiliated to Consolekit2 in any way, just wanted to mentioned 
this from a fairness POV.


Regards,
Aaditya

References-
[1]: https://github.com/ConsoleKit2/ConsoleKit2/
[2]: https://devuan.org/newsletter_22dec.html

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] vdev update and design document

[Dr. Nikolaus Klepp]

Am Montag, 5. Januar 2015 schrieb Martijn Dekkers:
> On 5 January 2015 at 07:47, Enrico Weigelt, metux IT consult <
> enrico.weig...@gr13.net> wrote:
> 
> > On 05.01.2015 00:40, Jude Nelson wrote:
> >
> > >> In VAX/VMS there was a feature that could in theory be useful,
> > >> though I've never seen it actually used.  Fila permissions could
> > >> forbid the root user from reading the file.  This might be useful
> > >> for dire secrets.  Even the sysadmin couldn't back up that file.
> > >
> > > I think for some applications (like dealing with medical records), this
> > > is a legal requirement.
> >
> > No, certainly not (I'm currently working in than area) - that's just
> > misinterpretation. Instead you'll need clear access control rules,
> > mich might have to prevent _operators_ from accessing certain data.
> > In that case, operators wont have root access.
> >
> 
> That answer is just plain wrong. There are several areas where there are
> significant legal requirements around disallowing the concept of a root /
> UID 0 user to have overriding access. Please be advised that SELinux was
> built by the NSA *specifically* to be able to meet these legal
> requirements. Think Government, Finance, Defense, Intelligence, Law
> Enforcement, Medical. Yes, this is first-hand, practical knowledge. Stating
> that there is no legal requirement anywhere for restricting access to
> information only to a certain group of users is  funny 


Oh, wasn't the NSA the "inventor" of e.g. the compromised elliptic curve in the 
NIST standard? I would not give a cent on anything that has a NSA label on it. 
Be aware that the "legal" concept of the US/UK is confined to that countries 
and luckily not adressable worldwide.

There's a saying: "For every security problem there is a juridical solution". 
Take a look at De-Mail to see how that turns out in practice. 

Nik




-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[Dng] Because the current networking stack isn't good enough, either

[Martijn Dekkers]

http://linux.slashdot.org/story/15/01/14/2030259/systemd-gains-new-networking-features
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng