Re: [DNG] That one unsupported app: was Predictable Network Interface Names - Stupid or good idea?
> > OpenBSD's overall stance on virtualization makes it a poor choice for a > desktop OS unfortunately. I partially understand the reasoning, however, > given the limits of software support on the *BSDs in general, and OpenBSD > in particular, the lack of virtualization options effectively makes it > unusable for a substantial number of users. > Looks like this might change in the next release. Link: http://undeadly.org/cgi?action=article&sid=20151122214050 > The situation on FreeBSD seems a little better though, and I've seriously > considered making that switch. > > > > > > > On Sun, Jan 10, 2016 at 6:10 PM, Steve Litt > wrote: > >> On Sun, 10 Jan 2016 21:55:48 + >> Dave Turner wrote: >> >> > Slackware is hard work when you have been used to the ease of debian >> > for so many years... >> > Eventually it all worked OK until one particular bit of music >> > composition software I like to use could only be found in >> > Slackbuilds, and it would not install even after I did some editing >> > of the scripts. I gave up and installed devuan again. >> >> Devuan is an excellent distro and I applaud you for installing it. >> >> If you ever find that one app that you can't install on Devuan, just >> run a VM or container that *does* do that app right, and run that one >> app there. >> >> The entire reason why I didn't migrate to OpenBSD and happily stay >> there in September 2014 is because OpenBSD has no functional and >> working Qemu, and shows little motivation to change that. So I'd have >> to permanently live without those couple programs I needed. Normal >> Linuxes enable you to run other distros in VMs or containers, so choose >> the best one, even if it won't do your favorite program. >> >> SteveT >> >> Steve Litt >> January 2016 featured book: Twenty Eight Tales of Troubleshooting >> http://www.troubleshooters.com/28 >> >> >> ___ >> 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] That one unsupported app: was Predictable Network Interface Names - Stupid or good idea?
On Mon, Jan 11, 2016 at 2:18 AM, Dave Turner < dave_t_tur...@barradas.free-online.co.uk> wrote: > All the BSDs have the packages I want and need, except working WiFi for > laptops! > My main desktop is an old Intel iMac. FreeBSD and PC-BSD would not install. > I could not get sound to work on NetBSD and OpenBSD. > So the old iMac runs debian jessie systemd and all. > > My old laptop is now running devuan again, but this time as the Dom0 for a > xen hypervisor that will run NetBSD. My hope is that xen will pass on the > WiFi connection so that I have a NetBSD laptop with working WiFi. We'll see! > So far I'm not sure the xen part is quite as it should be, I need to spend > some more time with the docs. > > DaveT > > > > > > On 11/01/16 00:15, Stephanie Daugherty wrote: > > OpenBSD's overall stance on virtualization makes it a poor choice for a > desktop OS unfortunately. I partially understand the reasoning, however, > given the limits of software support on the *BSDs in general, and OpenBSD > in particular, the lack of virtualization options effectively makes it > unusable for a substantial number of users. > > The situation on FreeBSD seems a little better though, and I've seriously > considered making that switch. > > > > > > > On Sun, Jan 10, 2016 at 6:10 PM, Steve Litt > wrote: > >> On Sun, 10 Jan 2016 21:55:48 + >> Dave Turner wrote: >> >> > Slackware is hard work when you have been used to the ease of debian >> > for so many years... >> > Eventually it all worked OK until one particular bit of music >> > composition software I like to use could only be found in >> > Slackbuilds, and it would not install even after I did some editing >> > of the scripts. I gave up and installed devuan again. >> >> Devuan is an excellent distro and I applaud you for installing it. >> >> If you ever find that one app that you can't install on Devuan, just >> run a VM or container that *does* do that app right, and run that one >> app there. >> >> The entire reason why I didn't migrate to OpenBSD and happily stay >> there in September 2014 is because OpenBSD has no functional and >> working Qemu, and shows little motivation to change that. So I'd have >> to permanently live without those couple programs I needed. Normal >> Linuxes enable you to run other distros in VMs or containers, so choose >> the best one, even if it won't do your favorite program. >> >> SteveT >> >> Steve Litt >> January 2016 featured book: Twenty Eight Tales of Troubleshooting >> http://www.troubleshooters.com/28 >> >> >> ___ >> Dng mailing list >> Dng@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> > > > > ___ > Dng mailing > list...@lists.dyne.orghttps://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] Predictable Network Interface Names - Stupid or good idea?
> Isn't the initial identification of network adapters and assignment originally handled by the Kernel or is this another urban myth that I have mistakenly hung on to? Yes--network interfaces are given a monotonically-increasing sequence number as they are enumerated (e.g. the X in ethX and wlanX). However, X isn't guaranteed to refer to the same NIC across boots. > I've only run into mac duplication a couple of times in my life thus far. That's why vdev also accepts a sysfs device path, which is guaranteed to persist across boots provided that the device remains on the same bus :) -Jude On Sat, Jan 9, 2016 at 3:30 PM, Hendrik Boom wrote: > On Sat, Jan 09, 2016 at 09:19:33PM +0100, Anto wrote: > > > > On 09/01/16 19:44, shraptor wrote: > > >On 2016-01-09 19:17, Anto wrote: > > > > > >>On the topic. It would be quite interesting how vdev will be (or is) > > >>managing this network interface naming assignment. Do you have any > > >>comment on this, Jude? > > > > > >vdev uses by default old naming convention but has a file > > >called /etc/vdev/ifnames.conf where you can set names arbitrarily. > > > > > >Example ifnames.conf that is auto-generated at compile time > > >(only covered up my mac addresses) > > > > > ># Format: > > ># PERSISTENT_INTERFACE_NAME mac|devpath MATCH_ARGUMENT > > ># * PERSISTENT_INTERFACE_NAME is the persistent name of the > > >network interface > > ># * If the second argument is "mac", then MATCH_ARGUMENT is the > > >colon-separated MAC address > > ># * If the second argument is "devpath", then MATCH_ARGUMENT is > > >the device path to the NIC in sysfs > > ># > > ># Example: a wireless USB dongle, to be named "wlan-edimax" > > ># > > ># Using the "mac" match: > > ># wlan-edimax mac 80:1F:02:D3:B2:83 > > ># > > ># Using the "devpath" match: > > ># wlan-edimax devpath > > >/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0 > > > > > >eth0 mac XX:XX:XX:XX:XX:XX > > >wlan0 mac XX:XX:XX:XX:XX:XX > > > > Thanks shraptor, > > > > It looks good to me. > > > > I have been trying to do the same on udev to have persistent > > interface name according to the MAC address, e.g. by following the > > tips on > http://wiki.networksecuritytoolkit.org/nstwiki/index.php/Network_Setup_Tips > , > > but no joy so far. Perhaps it always fails because I am using eudev > > instead of systemd-udev. So I just use the workaround to have > > net.ifnames=0 on my kernel command line until we have vdev package > > on Devuan repository. > > And when the vdev package lands on the Devuan repository couold we please > have a jessie package or backport for it? Even though jessie is > supposed to be stable? > > -- hendrik > > > > > Cheers, > > > > Anto > > ___ > > 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] Error building vdev
The vdev_subprocess error comes from trying to build vdevfs, an optional add-on to vdev that is still under development and has not bee sync'ed with some recent changes to the rest of the codebase. You can avoid building it with no loss of functionality. The only things you'll need to build to get a functioning system are: make -C vdevd # builds the daemon make -C hwdb # builds the hardware database make -C example # builds the sample config files make -C example initramfs # builds an initramfs with vdev (use at your own risk; you'll need to ensure that the resulting initramfs loads the proper modules) -Jude On Sat, Dec 26, 2015 at 7:48 AM, aitor_czr wrote: > On 12/26/2015 04:21 AM, Daniel Reurich > wrote: > > On the other hand, i packaged succesfully **libfskit** and **libpstat**.> > Anybody knows where can i find a stable branch of **libpthread** ? > > I thought libpthread was a part of glibc. > > regards, > Daniel. > > > You are right Daniel, i just downloaded the sources of glibc and it > includes libpthread. > > Thanks, > >Aitor. > > ___ > 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] OT: Degree?
> 2) Which companies (just for examples) don't require it? Forgot to mention--my local LUG was often attended by people from local software development firms, ISPs, and IT departments. If you're not a member of a LUG yet (or some other computer-related club), signing up for one and getting to know these people is a good way to get a professional network started :) They can also help guide you on your future career choices, and even help you get jobs with them. On Thu, Nov 12, 2015 at 2:49 PM, Jude Nelson wrote: > Hi Mitt, > > Questions: >> 1) Are there many people without degrees in the industry? >> > > Most software engineers I know have at least a minor in computer science, > but have at least a BS or BA in some engineering discipline if they don't > have a BS/BA in computer science. I have met a few really proficient > self-taught developers, but they are the exception, and they almost always > had a leg-up from someone else. Every large company I have worked for > required a degree from its software engineers. > > >> 2) Which companies (just for examples) don't require it? >> > > Anyone you can convince to hire you :) I'd go for start-ups and smaller > shops, since the hiring processes there probably won't be so impersonal as > to automatically ignore your application simply for lack of a degree. > Smaller shops will ask to see a portfolio of previous work (like the stuff > on your github), or ask you to do a small week-long project with some of > the other employees in order to judge how proficient you are when you're in > your element. > > >> 3) Are there any hobbyists around here, that earn some money from >> coding? >> >> From what I've heard, universities here teach something that is >> obsolete and is not used anymore, or simply don't teach what we do >> here (Unix, administration, hardware...). >> > > I've had experiences writing software both with and without a formal > education. I'm of the opinion that if you go to university in order to > acquire a formal background in computer science, then it's worth every > penny. This is because a formal background helps you understand both > theory and practice from first principles. Once you can understand it from > first principles, it becomes a lot easier to pick up new skills, and makes > it possible to design long-lasting low-maintenance software that won't need > to be rewritten from scratch every few years. It also gives you the > ability to look at trends in the industry and tell the difference between > what's fundamentally new, what's a passing fad, and what's snake-oil. Of > course, the mileage you get out of it depends on how thorough you were in > making sure you understand all the material. > > If you instead want to focus more on learning specific skills, you might > want to consider going to a community college and getting your associate > degree. It's a lot less expensive than university, and faculty usually > come from an industrial background and can share their real-world > experiences with you. There will almost always be more hands-on courses > available than at university, such as on things like systems > administration, Unix, mobile app development, game development, and > preparation classes for particular certifications. One nice thing about > community college is that if you decide later that you want to go on to > university, most universities will accept some/all of the credits you > earned at your community college (but double-check this first!). For > example, both of my parents and my brother got their bachelor degrees by > doing two years at community college and two years at university. > > If you do go the university route, you should go to a non-profit, > regionally-accredited one [1], and if at all possible, you should > physically attend (even if it means a long commute). Also, you'd be amazed > at how many scholarships go unclaimed each year. > > -Jude > > [1] https://en.wikipedia.org/wiki/Regional_accreditation > > >> Thanks for any kind of information, >> >> Mitt >> ___ >> 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] OT: Degree?
Hi Mitt, Questions: > 1) Are there many people without degrees in the industry? > Most software engineers I know have at least a minor in computer science, but have at least a BS or BA in some engineering discipline if they don't have a BS/BA in computer science. I have met a few really proficient self-taught developers, but they are the exception, and they almost always had a leg-up from someone else. Every large company I have worked for required a degree from its software engineers. > 2) Which companies (just for examples) don't require it? > Anyone you can convince to hire you :) I'd go for start-ups and smaller shops, since the hiring processes there probably won't be so impersonal as to automatically ignore your application simply for lack of a degree. Smaller shops will ask to see a portfolio of previous work (like the stuff on your github), or ask you to do a small week-long project with some of the other employees in order to judge how proficient you are when you're in your element. > 3) Are there any hobbyists around here, that earn some money from > coding? > > From what I've heard, universities here teach something that is > obsolete and is not used anymore, or simply don't teach what we do > here (Unix, administration, hardware...). > I've had experiences writing software both with and without a formal education. I'm of the opinion that if you go to university in order to acquire a formal background in computer science, then it's worth every penny. This is because a formal background helps you understand both theory and practice from first principles. Once you can understand it from first principles, it becomes a lot easier to pick up new skills, and makes it possible to design long-lasting low-maintenance software that won't need to be rewritten from scratch every few years. It also gives you the ability to look at trends in the industry and tell the difference between what's fundamentally new, what's a passing fad, and what's snake-oil. Of course, the mileage you get out of it depends on how thorough you were in making sure you understand all the material. If you instead want to focus more on learning specific skills, you might want to consider going to a community college and getting your associate degree. It's a lot less expensive than university, and faculty usually come from an industrial background and can share their real-world experiences with you. There will almost always be more hands-on courses available than at university, such as on things like systems administration, Unix, mobile app development, game development, and preparation classes for particular certifications. One nice thing about community college is that if you decide later that you want to go on to university, most universities will accept some/all of the credits you earned at your community college (but double-check this first!). For example, both of my parents and my brother got their bachelor degrees by doing two years at community college and two years at university. If you do go the university route, you should go to a non-profit, regionally-accredited one [1], and if at all possible, you should physically attend (even if it means a long commute). Also, you'd be amazed at how many scholarships go unclaimed each year. -Jude [1] https://en.wikipedia.org/wiki/Regional_accreditation > Thanks for any kind of information, > > Mitt > ___ > 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] Packaging vdev
Hi aitor_czr, On Tue, Nov 10, 2015 at 7:25 AM, aitor_czr wrote: > I uploaded fskit to gitlab: > > https://git.devuan.org/aitor_czr/fskit/tree/gbp-master > That's a very outdated version of fskit. The latest one (the one consistent with vdev) is in github: https://github.com/jcnelson/fskit > > > I didn't see the dpkg template in 'contrib/debian'. That blindness !! > > Now, i see some significant differences between this template and mine. In > my opinion: > > 1.- '/usr/lib/libfskit.so' and 'usr/lib/libfskit_fuse.so' dinamical > libraries must be included in the respective *-dev.install files, instead > of 'libfskit.install' and 'libfskit-fuse.install'. > > 2.- libfskit depends on libfskit-fuse and not the other way around, > because libfskit-fuse is the backend (I did it so in Netman). > > Isn't it? > It's the other way around: libfskit-fuse depends on libfskit. But unless you're packaging vdevfs along with vdevd, you don't need libfskit at all :) HTH, Jude > > > Aitor. > > On 11/08/2015 02:38 PM, shraptor > wrote: > > Sorry read a little bit fast there, thought you was building vdev but > you are working on fskit > > > anyway default is */usr/local/lib/** > Defaults can be overridden in buildconf.mk > > > > ___ > 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] Is Jude Nelson OK?
I'm alive, barely. Not only am I working on my thesis, but also I work at a start-up based on my thesis's technology, and I've had to spend the past few weeks preparing for a conference at which I'm presenting this week. I haven't even had time to answer emails :( Shraptor: I've seen your emails and Github reports--I think you've discovered the source of the ID_INPUT bug. The udev-compat.sh script walks the metadata stored in /dev/metadata/dev/$DEVICE, and uses it to generate the udev labels and tags. The stat_input helper in /lib/vdev should print out VDEV_INPUT=1 when given the path to the device file to your mouse, and VDEV_INPUT=1 should be present in /dev/metadata/dev/$MOUSE_DEVICE/properties. udev-compat.sh reads the properties file and translates VDEV_INPUT=1 into E:ID_INPUT=1 in /run/udev/data/$MOUSE_DEVICE_ID. The fact that this isn't happening consistently suggests either a race condition, or a bug in udev-compat.sh that causes the udev file (in /run/udev) to get overwritten somehow. Example of what should happen with character device 13,82 (/dev/input/event18 on my laptop) $ /lib/vdev/stat_input /dev/input/event18 VDEV_INPUT=1 VDEV_INPUT_MOUSE=1 VDEV_INPUT_CLASS=mouse VDEV_PROPERTIES="VDEV_INPUT VDEV_INPUT_MOUSE VDEV_INPUT_CLASS " $ stat /dev/input/event18 File: '/dev/input/event18' Size: 0 Blocks: 0 IO Block: 4096 character special file Device: fh/15d Inode: 38955 Links: 1 Device type: d,52 Access: (0660/crw-rw) Uid: (0/root) Gid: ( 149/ input) Access: 2015-09-04 17:57:47.982595330 -0400 Modify: 2015-09-04 17:57:47.982595330 -0400 Change: 2015-09-04 17:57:48.058595332 -0400 Birth: - $ cat /run/udev/data/c13:82 I:6426 E:ID_PATH=platform-i8042-serio-2 E:ID_PATH_TAG=platform-i8042-serio-2 E:ID_INPUT=1 E:ID_INPUT_MOUSE=1 E:ID_INPUT_CLASS=mouse If the file is getting overwritten somehow, one way to get a trace of it happening is to use inotifywatch(1) to watch /run/udev/data/ to see what files get created, written, and unlinked when you plug your mouse in. Apologies for disappearing for the past two weeks. Getting ready for this next conference took a lot more time than I hoped it would :/ -Jude On Wed, Oct 28, 2015 at 10:47 AM, aitor_czr wrote: > I had a look at vdev... > > Impresive. > > I will try to debianize it. > > Aitor. > > On 26/10/15 13:00, Jaromilwrote: > > > On Mon, 2015-10-26 at 10:46 +0100, shraptor wrote: > > > > Maybe he is just swamped with work. > > > > He said he follows what's happening and that there are still some> > > > hiccups to work out. He also wrote that he finds less and less time> time > > > to work on vdev this academic year. > > Of course this is it. a Ph.D. can be very demanding especially in > writing phase and especially if full-time and including a tuition > contract. > > Lets allow people involved to find their own pace as Devuan is still > based on voluntary effort and everyone involved feels enough the urge as > well the peer pressure. > > The current development phase is aligning for a beta release, there is a > lot of work going on on many levels, not only technical, but less > urgency for vdev anyway, which won't be substituting udev right away. > It is indeed good to have it packaged, so more people can try and > perhaps it will attract more contributors. > > So in case of vdev I have no worries, as Jude is well dedicated and > understand the huge importance of what he is doing, with your help of > course, and also vdev is a concrete outcome of his Ph.D. thesis, so > there is an incentive also in that context to carry it on. > > In any case, good that we care about each other. After all it's been one > year now we are sitting around this camp, warming canned beans in pans > over the fire and doing our best to re-build a new town :^) and its > coming along. > > ciao > > > > ___ > 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] vdev status update: eventfs
Hi shraptor, On Wed, Sep 23, 2015 at 1:30 PM, shraptor wrote: > On 2015-09-23 17:14, Jude Nelson wrote: > >> @shraptor >> >>> So how to get eventfs going with vdev. >>> ./eventfs /run/udev >>> or where should eventfs be mounted? >>> Eventfs mounting will not be handled by vdev, right? >>> >> >> Vdev won't set up eventfs. I'll ship a sysv init script with it that >> will mount it automatically (probably shortly after init starts, since >> libudev-compat programs will need it relatively early in the boot >> process). >> > > Is it a hard dependency on eventfs? > Vdev does not need eventfs. Libudev-compat benefits from using it, but does not need it for correct operation. It's a soft dependency. Or will some functionality work without eventfs? > Yes--it will remain possible to use libudev-compat without eventfs. > > Is it the same data as was made availible in /run/udev before?? > No, eventfs will handle the contents of /dev/metadata/udev/events and /dev/events. If you look in /dev/metadata/udev/events, you'll see that libudev-compat processes will have created a bunch of directories there--one for each struct udev_monitor--into which vdev's udev-compat.sh helper writes device events. Currently, there is no straightforward and automatic way to clean this directory out, but doing so is nevertheless necessary since the directories for a process's struct udev_monitor instances will persist after the process dies (I've written a script to clean the dead directories out periodically, but it's not perfect). By having libudev-compat clients write to eventfs, we can ensure that these directories are automatically removed after the process that created them dies. -Jude > > > >> I was planning on having it mounted on /run/events, in order to make >> it available as a generic IPC system for other programs to use for >> their own purposes. Eventfs isn't specific to vdev; I'm hoping to >> use it as a partial alternative to dbus. I'm open to alternative >> mount points, though. >> >> @jaromil >> >>> Amazing news. noone here doubts you are continuing to build up on >>> >> the >> >>> solid foundations you laid, I am sure vdev will become a relevant >>> component for many mission-critical GNU/Linux system installations. >>> >> >> Please do not hesitate to ask for anything you need in terms of >>> infrastructure and funding we can contribute from our donation pot. >>> >> >> Thank you for your generous offer! I think I'm fine for now insofar >> as development infrastructure, but one thing that will be particularly >> tricky is creating the packaging scripts needed to replace udev >> automatically, but without rendering the host unbootable if something >> goes wrong. >> >> Thanks, >> Jude >> >> On Tue, Sep 22, 2015 at 6:20 AM, vmlinux wrote: >> >> Great news! Thank you for all your efforts! >>> >>> On September 21, 2015 9:44:12 PM CDT, Jude Nelson >>> wrote: >>> >>> ::I'm pleased to announce the availability of eventfs >>> >>> -- >>> Sent from a Mobile device. >>> >> >> >> ___ >> 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] vdev status update: eventfs
@shraptor > So how to get eventfs going with vdev. > ./eventfs /run/udev > or where should eventfs be mounted? > Eventfs mounting will not be handled by vdev, right? Vdev won't set up eventfs. I'll ship a sysv init script with it that will mount it automatically (probably shortly after init starts, since libudev-compat programs will need it relatively early in the boot process). I was planning on having it mounted on /run/events, in order to make it available as a generic IPC system for other programs to use for their own purposes. Eventfs isn't specific to vdev; I'm hoping to use it as a partial alternative to dbus. I'm open to alternative mount points, though. @jaromil > Amazing news. noone here doubts you are continuing to build up on the > solid foundations you laid, I am sure vdev will become a relevant > component for many mission-critical GNU/Linux system installations. > Please do not hesitate to ask for anything you need in terms of > infrastructure and funding we can contribute from our donation pot. Thank you for your generous offer! I think I'm fine for now insofar as development infrastructure, but one thing that will be particularly tricky is creating the packaging scripts needed to replace udev automatically, but without rendering the host unbootable if something goes wrong. Thanks, Jude On Tue, Sep 22, 2015 at 6:20 AM, vmlinux wrote: > Great news! Thank you for all your efforts! > > On September 21, 2015 9:44:12 PM CDT, Jude Nelson > wrote: > > ::I'm pleased to announce the availability of eventfs > > -- > Sent from a Mobile device. > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] vdev status update: eventfs
Hey everyone, I promise, I'm not dead :) I've been working on vdev off and on over the past couple months as time permitted, but I haven't had anything interesting to report here (mostly bug fixes, which are tracked on the project's Github [1]). This past week I've been able to spend more time on vdev, now that my major event for $WORK has come and gone. I'm pleased to announce the availability of eventfs [2], the final piece of software required to replace udev. Eventfs is a specialized userspace filesystem that replaces the udev-to-libudev event multicast protocol, which is currently based on netlink but will soon be based on kdbus. Eventfs fulfills an equivalent role, but it does so in a portable manner in userspace, and it abstracts dealing with message multicast groups as dealing with files and directories with a few extra rules [3]. I'm going to migrate my production machine to using eventfs with libudev-compat this weekend. Once I'm satisfied that it works as expected, I'll begin packaging all of vdev's components for Devuan. Questions, comments, and feedback are all welcome :) Thanks, Jude [1] https://github.com/jcnelson/vdev [2] https://github.com/jcnelson/eventfs [3] https://github.com/jcnelson/eventfs/blob/master/README.md ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What's /dev/bus/usb?
/dev/bus/usb/* are USB devices, organized by the kernel-assigned USB bus number and USB device number (i.e. /dev/bus/usb/$USB_BUS_ID/$USB_DEVICE_ID). This includes not only USB devices like mice and Web cameras, but also USB hubs and controllers. Vdev creates the /dev/bus/usb/* device files as well. -Jude On Thu, Aug 27, 2015 at 9:43 AM, Steve Litt wrote: > Hi all, > > What's /dev/bus/usb? On Wheezy, this is where you must aim your > inotifywait command to detect insertion and removal of flash drives. > > Is /dev/bus/usb used on Devuan? > > Is /dev/bus/usb a udev thang, and if so, does vdev continue the > tradition? > > Thanks, > > SteveT > > Steve Litt > August 2015 featured book: Troubleshooting: Just the Facts > http://www.troubleshooters.com/tjust > ___ > 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] Can dracut use vdev?
Hi Steve, I've never tried it with dracut; all of my efforts have been getting it to work with Debian's initramfs tools. I don't know how tightly coupled dracut is to udev, but it's worth investigating at some point :) -Jude On Wed, Aug 12, 2015 at 8:41 AM, Steve Litt wrote: > Hi all, > > Is there anyone here using dracut on a system that uses vdev instead of > udev? Does it work OK? > > Thanks, > > SteveT > > Steve Litt > August 2015 featured book: Troubleshooting: Just the Facts > http://www.troubleshooters.com/tjust > ___ > 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] Congratulations to the Devuan team
Thank you everyone for your kind words about vdev! I apologize for not posting much about it for the past few weeks. I had been on vacation earlier, and now almost all of my spare time between getting back and September 12 is taken up by finishing up my PhD thesis and gearing up for a conference that the start-up I'm working for is organizing [1]. I've mostly been working behind the scenes with a few people from this list on finding and fixing bugs in vdev. Once September 12 comes and goes, I'll be able to devote more time towards getting a package ready and finishing up a few remaining chores on the vdev issue tracker. Then I can create a versioned branch that will evolve into the first stable release :). Thank you all for your patience! -Jude [1] If anyone's interested, the conference details are here: http://blockstack.org/summit On Wed, Aug 12, 2015 at 10:30 PM, Robert Storey wrote: > About vdev... > > It looks like it's almost ready for prime time, but that further testing > is needed to work out any bugs. So I'd like to throw out a little > suggestion to expedite that. > > Could someone come up with a package so that we can install vdev on > Debian? In my case, I'm currently using antiX as my stable operating > system. I would be willing to install vdev on it and put it through its > paces, reporting back any suspected bugs I encounter. > > Barring a specific package, then maybe some published instructions and a > download for installing it on Debian. > > It sounds to me like vdev could be a game changer, so I'm enthused about > installing it and doing what I can to make it a new standard. > > As I've mentioned before, I do occasionally write for DistroWatch, so if I > can get a positive experience with vdev, I'd do an article on that. > Hopefully, this would encourage others to download and install vdev, > helping to move along its widespread adoption. > > Kudos to all the Devuan developers. > > - Robert > > > ___ > 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] automount, mount, and USB sticks
On Tue, Jul 28, 2015 at 11:09 PM, James Powell wrote: > Eventually, and I kinda realized this, work may be needed to write a > udisks replacement for vdev that can work off vdev without loosing > functionality to udisks using applications and file managers, especially > for non-Linux systems. > > Nothing fancy, but as long as it works and allows for some level of > control for admins, I don't have a problem with it. > > Thoughts? > If all udisks2 needs from the device manager is libudev (or libgudev), then we should be good to go as-is. Libgudev should work unmodified with libudev-compat. However, replacing udisks[2] with a suite of simple setuid or setgid programs that implement the equivalent functionality might be a better long-term solution. It would be much easier to hook into a GUI, for example, and if done right, it would remove the need for polkit and dbus integration. -Jude -- > From: Hendrik Boom > Sent: 7/28/2015 7:45 PM > To: dng@lists.dyne.org > Subject: Re: [DNG] automount, mount, and USB sticks > > On Tue, Jul 28, 2015 at 01:08:26PM -0700, Gregory Nowak wrote: > > On Tue, Jul 28, 2015 at 03:17:11PM -0400, Hendrik Boom wrote: > > > Of course I have to guess whether the device has > > > been plugged in as /dev/sdb, or /dev/sde, or whatever. In case of > > > (frequent) doubt, I switch to a root console with control-alt-F1 and a > > > login, unplug the device, and plug it in again. It will the tell me > > > after a while, that a new device has been inserted, and tell me what > > > /dev/sd* name it has dynamically installed. I end up, as root, > > > mounting the device with root as the owner. It's usually a USB stick > > > with one of the ubiquitous Microsoft file systems used on USB sticks, > > > and all the files can be read or writen by root only. > > > > There is a much easier way. Instead of switching consoles and > > guessing, just plug the device in, and look at the last screen full of > > the output from dmesg. > > Yes, that would have been easier. > > > Also, if you're mounting on your own laptop, it > > will usually have one hd, /dev/sda. When you plug in a usb device, it > > will probably have /dev/sdb. If you unplug it, and plug in the same > > device, or plug in another stick, it will probably have /dev/sdb > > still. > > For whatever reason, there was a time when it kept picking new letters > if I umounted the stick, took it ouot, and put another in. Maybe there > was a bug somewhere then? But I could not rely on it always being > /dev/sdb. > > > So, you could just put a line in /etc/fstab which will allow a > > normal user to mount /dev/sdb1 for example to whatever directory you > > want. All you would have to do as a normal user is to type: > > mount /dev/sdb1 > > after plugging in the drive, and you should be able to find its' > > contents under whatever directory you specified in fstab. > > Truth is, I no longer trust it to be consistent. > > -- hendrik > > > > > Greg > > > > > > -- > > web site: http://www.gregn.net > > gpg public key: http://www.gregn.net/pubkey.asc > > skype: gregn1 > > (authorization required, add me to your contacts list first) > > If we haven't been in touch before, e-mail me before adding me to your > contacts. > > > > -- > > Free domains: http://www.eu.org/ or mail dns-mana...@eu.org > > ___ > > 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 > > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] A better default windows manager
On Sat, Jul 25, 2015 at 2:41 PM, Hendrik Boom wrote: > On Sat, Jul 25, 2015 at 12:47:13PM -0500, T.J. Duchene wrote: > > > > > > On 7/25/2015 9:54 AM, Steve Litt wrote: > > > > > >I've heard that wayland will require systemd. > > > > > >SteveT > > > > > > > > I have to apologize, Steve. > > > > When I refer to "Wayland" I am referring to the Linux project, which > > as far as I know does NOT have anything to do with systemd. It's > > just easier to call it "Wayland" so everyone know what I am talking > > about. > > > > Weston is the Linux implementation of Wayland. Wayland itself is > > nothing more than a display protocol, which has nothing more to do > > with systemd than X11 does. > > So is it Weston that does or does not involve systemd? > And which is it, finally? > Weston does not require systemd, but it does offer optional integration with logind. It will rely on XDG environment variables if logind is not running. Related, Weston depends on dbus by default. Unsurprisingly, the dbus integration code was added by an individual who is both a core systemd developer and core kdbus developer. However, it can be disabled at compile-time. Like T.J. said, X11 is to X.org just as Wayland is to Weston. Wayland does not depend on systemd or dbus anymore than HTTP does. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The figure of commits behind the upstream on github
Hi Anto, [snip] > does anybody have any suggestion how to easily find out that our fork > repositories need updating without keep checking the upstream repositories? > You're going to have to pull changes upstream periodically. That's just the way git is designed--if you're not hosting the repository that the original project developers push to, then you're by definition going to be pulling from their repository. However, from your description, it sounds like you could make your workflow a little bit easier: 1. fork the original repository 2. add the original repository as a remote for pulls (i.e. git add remote ...) 3. make your changes and push them to your forked repository 4. pull from the original repository (i.e. git pull ) 5. resolve merge conflicts 6. repeat steps 3-6 periodically If your changes are unlikely to be in conflict by pushes to the original, you might consider creating a cron job to periodically run steps 3 through 6 for you, and have it email you when there are merge conflicts (step 5) that can't be automatically resolved. HTH, Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)
On Thu, Jul 23, 2015 at 10:30 PM, T.J. Duchene wrote: > On Thursday, July 23, 2015 08:22:55 PM Hendrik Boom wrote: > > On Fri, Jul 24, 2015 at 12:12:01AM +0200, Teodoro Santoni wrote: > > > ... but, yeah, it's outside the scope of Devuan. D-Bus just sucks and > is > > > documented on a random basis, when you compare it to the rest of > > > GNU/Fedora > > > it's... like GTK: it sucks, there are alternatives but it's a PITA to > port > > > away 'cause a lot of big codebases uses them as foundation. > > > > So there are alternatives to GTK: Do any suck less? What are they? > > > What's wrong with GTK? I don't care for it, but it is not any worse than > Microsoft's UI. > > There are lots of alternatives. wxWidgets and Qt are the most common > suggestions, but there are far more esoteric ones. If you are aiming for > widest portability support, Qt is probably your best bet. > Doesn't wxWidgets use GTK on GNU/Linux? > > I don't care for it myself - because it is C++. Minor correction: GTK is written in C, and relies on GLib, which is also written C. However, it's open to debate as to how similar/different C-plus-GLib is to C++ in practice. Cheers, Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Will there be a MirDevuan "WTF"?
> > > If I was able to understand correctly, vdev works with dbus. Vdev does not use dbus. No idea how or why you came to this conclusion. Search the code if you don't believe me. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] vdev status update: performance, bugfixes, and udev events
Hey everyone, I have the latest news for vdev: * [EXPERIMENTAL] Vdevd now has actions and helpers that will cause it to generate and propagate device events to libudev-compat clients. Libudev-compat clients should receive hotplug events as they would have with libudev, and they should be able to enumerate devices. This means that it should be possible now to run X11 with vdevd and libudev-compat, without needing an xorg.conf. To do so, you'll need to symlink vdev's /dev/metadata/udev to /run/udev. * Hardware database access performance has been significantly improved, and made more accurate (i.e. it should now match all prefixes against the device modalias, not just the longest one). By "significant", I mean by an order of magnitude. * As an optimization, vdevd can now run specially-crafted helper scripts as "daemonlets." Instead of fork()/exec()'ing a shell for each action, vdevd will instead fork() an action's command once and feed it a sequence of device requests, encoded as a list of environment variables. When running as a daemonlet, the command will be expected to run a loop that will parse the request from vdevd, call the command's main body of code, and report back the "exit" status. The heavyweight scripts (i.e. the ones that benefit from this) have all been turned into daemonlets in this round of commits. This leads to around 25% performance improvement (on average) for each command. * vdevd now benchmarks its actions, and writes performance information to its logfile at the end of coldplug processing. Just to give a reference frame: vdevd currently takes about 9 seconds to cold-process all of my laptop's hardware (i.e. it's slower than udev, but not that much slower). * libvdev is no longer a build target. Its code will instead be statically linked to vdevd and vdevfs. This is to make installation and deployment easier. There's no real loss to doing so--the library isn't that big in the first place, and the only programs that will ever use it are vdevd and vdevfs (note that libvdev is not at all related to libudev). * Bugfixes: -- the pre-seed script that runs before coldplug device processing can now create device nodes, and signal to vdevd to run the associated helper scripts anyway. -- the pre-seed script will select the first free loop device (with losetup -f) for the hardware database. -- [NEEDS CONFIRMATION] the ifname.sh script should select the correct config file now. I'm still chasing down a "Device or resource busy" bug in renaming interface names, so please keep your eye out for it. -- [NEEDS CONFIRMATION] the disk.sh helper should now generate /dev/disk for USB disks. Thanks to everyone who helped me test vdevd so far! -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Dng] vdev status update: device properties and udev compatibility
Hi Isaac, On Mon, Jun 29, 2015 at 10:12 AM, Isaac Dunham wrote: > On Fri, Jun 26, 2015 at 04:40:33PM +0200, Didier Kryn wrote: > > Le 25/06/2015 07:04, Jude Nelson a écrit : > > > In time, it will also work the busybox tools, but I am still working > on > > >getting busybox's blkid to work here (specifically, we need the "-p" > flag > > >to work in order to get low-level partition table information and > > >filesystem metadata). > > > > Contrary to the other options, which only deal with formatting the > > output, option -p cannot be emulated with a wrapper script. Have you any > > idea of how to proceed. I am only a consumer of Busybox and have never > tried > > to dig into the source. Are you, or anybody in this list, able to submit > a > > patch to busybox blkid? > > What information fields from -p are needed? > For libudev compatibility, we will need: * usage (e.g. filesystem, crypto_LUKS, etc.) * filesystem type * filesystem UUID * subvolume UUID (where applicable) * partition table type (e.g. dos, GPT, etc.) * partition table UUID * partition table entry scheme * partition table entry type * partition table entry size * partition table entry offset * partition table entry UUID * partition table entry number * parent disk device Examples: # blkid -p -o export /dev/sda DEVNAME=/dev/sda PTUUID=0003da58 PTTYPE=dos # blkid -p -o export /dev/sda1 DEVNAME=/dev/sda1 UUID=67378bcc-ba07-4074-9a7e-9daef3537ad5 VERSION=1.0 TYPE=ext4 USAGE=filesystem PART_ENTRY_SCHEME=dos PART_ENTRY_UUID=0003da58-01 PART_ENTRY_TYPE=0x83 PART_ENTRY_NUMBER=1 PART_ENTRY_OFFSET=2048 PART_ENTRY_SIZE=195309568 PART_ENTRY_DISK=8:0 Thanks, Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
Has anyone taken a look at pleaserun? Link: https://github.com/jordansissel/pleaserun. It's made by the same person who wrote fpm (Jordan Sissel). It lets you generate init scripts for a plethora of different inits, given only the installed location of the binary. -Jude On Thu, Jun 25, 2015 at 7:50 PM, Florian wrote: > On Thu, 18 Jun 2015 16:58:59 +0200 > Mat wrote: > > > > So in general I think that this approach - moving init system specific > > things out of the main package and providing one package per init > > system > > - is a good way of supporting multiple init systems. > > > > For instance: > > openssh-server - the ssh daemon, stripped of its startup > > script openssh-server-sysv- the traditional sysvinit startup > > scripts openssh-server-run - startup scripts for runit > > openssh-server-epoch - startup scripts for epoch > > openssh-server-openrc - startup scripts for OpenRC > > openssh-server-systemd - why not? > > etc.. > > > Hello diversity! > > It's quite for a while that I'm reading this formidable list, now it's > time to spend my actual two cents: Since I've read the following mail > from the "epoch feature request" thread... > > On Wed, 17 Jun 2015 11:25:28 -0400 > Steve Litt wrote: > > > Here is the sum and total of information that could ever be needed for > > an Epoch Object (service, thing, whatever): > > > (...) > > > > Most of the preceding can safely be left to its default and remain > > unmentioned. Some of it is defined by the LSB header. My point is, by > > the time all is said and done, an Epoch object is pretty darn simple, > > pretty much like a systemd unit file (which is probably what we > > *should* kidnap as our source of conversion data). > > > ...I wonder, if it is necessary to create that many (daemon*initsys) > packages, as Mat (and others?) proposed - or if it was possible to > create some standardized per-daemon config file, to be parsed by > init-system-specific scripts into suitable configurations / init- > scripts. > > On the long run, these "universal" definitions could be maintained with > their respective daemon, while the particular parser-scripts might > become part of the init-systems, possibly as an extra package. > > This should provide a simple way of solving package dependencies, while > bringing greatest flexibility, if these init-system-specific scripts > were invokable in some interactive mode, asking the user (or a higher- > level configuration tool) which daemons to take care of. > > Disclaimer: I'm more of an advanced user than a developer, but willing > to get my hands dirty if this idea should prove to make sense for at > least a subset of the existing (and upcoming:) init-systems, perhaps > even including systemd. > > Regards, > > Florian > > > -- > "A specialist is a barbarian whose ignorance is not well-rounded." > Stanislaw Lem, His master's voice > > ___ > 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] [Dng] vdev status update: device properties and udev compatibility
Hi Didier, On Fri, Jun 26, 2015 at 10:40 AM, Didier Kryn wrote: > Le 25/06/2015 07:04, Jude Nelson a écrit : > >> In time, it will also work the busybox tools, but I am still working on >> getting busybox's blkid to work here (specifically, we need the "-p" flag >> to work in order to get low-level partition table information and >> filesystem metadata). >> > > Cheers Jude. The amount of work already done is impressive! > > I vave a question specifically about Busyboxe's blkid. > > Contrary to the other options, which only deal with formatting the > output, option -p cannot be emulated with a wrapper script. Have you any > idea of how to proceed. I am only a consumer of Busybox and have never > tried to dig into the source. Are you, or anybody in this list, able to > submit a patch to busybox blkid? I'll see what I can do, but in the mean time, I'll have vdev try to continue without the information given by -p. Thanks, -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] [Dng] vdev status update: device properties and udev compatibility
Hey everyone, After a longer-than-expected development cycle, I have the latest news for vdev. The TL;DR is that vdev has gained enough infrastructure to generate the information that normally gets put in /run/udev. This is important for most libudev clients, because this information gets used to detect and enumerate hardware. It's the way the X server detects input devices via udev, for example. This is still being heavily tested, and is not complete, but I am please to report that: * vdev now tracks device properties and device tags, under /dev/metadata/$DEVPATH/properties and /dev/metadata/$DEVPATH/tags/, respectively. They are added by shell library subroutines available to vdev's helpers (in subr.sh). * vdev now uses the same hardware database as udev to report human-curated hardware properties (such as human-readable vendor strings). To keep things simple, vdev comes with a script that generates a squashfs filesystem image from the *.hwdb files installed to /lib/udev/hwdb.d and /etc/udev/hwdb.d. This is our alternative to systemd's/udevd's mmap()-able on-disk hwdb trie. The filesystem image itself gets mounted to /dev/metadata/hwdb by the pre-seed script, and vdev now comes with a helper tool (hwdb.sh) that can use a combination of a modalias string, a devpath, a subsystem path, and some sysfs information to look up the device properties. * vdev now comes with a "udev-compat.sh" helper script that reads vdev's /dev/metadata/ directory and hardware database in order to generate /dev/metadata/udev, which is meant to be symlinked to /run/udev. This lets the udev_enumerate API detect and enumerate devices by tags and properties. It is important to emphasize that this helper is logically isolated from the rest of vdev--vdev gets along just fine without it (since all udev-isms are contained by this helper), so if you don't need /run/udev, you can safely disable this helper script. * Disk property detection has been significantly improved, and is much closer to how udev does it (including adding support for querying a disk's parent device's properties, which is necessary to handle partitions properly). Thanks to Didier for working with me on this! In time, it will also work the busybox tools, but I am still working on getting busybox's blkid to work here (specifically, we need the "-p" flag to work in order to get low-level partition table information and filesystem metadata). There is of course more work to be done on this, but the next big milestone (my next goal) will be to boot to X with vdevd, without having to generate an xorg.conf. I have not tried this yet, and I do not expect it to work as of the latest commit, but I believe that all the necessary infrastructure is in place to begin the painstaking process of ensuring that vdev detects enough of the host's devices' properties for commonly-used libudev clients work as they did with udev. This will confirm that we generate enough of /run/udev/ for alpha. Thanks, Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
Looks like Linus weighed in. I found the whole conversation thread interesting. http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05492.html -Jude On Sat, Jun 20, 2015 at 5:28 PM, KatolaZ wrote: > On Sat, Jun 20, 2015 at 08:15:01PM +0200, Didier Kryn wrote: > > [cut] > > > > > I think a new generation of programmers has been comitted to > > maintain and evolve > > Linux. They have strong technical skills but haven't been taught > > well enough - or not at > > all - the philosohy of UNIX. They have fun with Linux; they love > > writing daemons and > > using the IPC toolbox and they happily write daemons to replace the > > security features > > provided by good old file-permissions. They just don't realize the > > damage they are > > causing. They are professionals and they don't care the DIY guy who > > isn't as skilled as > > them. > > > > Or...we are just blind cavemen, trying do keep alive a zombie that > lives only in our memories and has evolved into something else, while > we were busy flaming about the last flavours of Ubuntu? > > I just think it's not a matter of skill (unix has never ever been just > a matter of skill), but rather a problem of bad attitude towards other > peers, their work and their contributions. And good attitude towards > peers is what has allowed the community around Linux to come along in > these years. Without good attitude, what was once a community will > slowly -but inexorably- become just a chit-chatty crowd, in which > speaking louder than your peers would be far more important than > having anything interesting to say at all. > > Well, I'd better stop here, and avoid the usual boring "auntie's > rant"... > > HND > > KatolaZ > > -- > [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] > [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] > [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] > [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] > ___ > 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] We Must be Prepared ....
Whelp, looks like kdbus in systemd is no longer optional (but to be fair, its use can be disabled at runtime, and won't be used anyway if kdbus isn't present in the kernel). Announcement: http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html -Jude On Fri, Jun 19, 2015 at 10:06 AM, Clarke Sideroad wrote: > On 06/19/2015 02:59 AM, Arnt Gulbrandsen wrote: > >> Clarke Sideroad writes: >> >>> I hoping the Kernel Developers as a combined whole would see the >>> bigger Linux picture well beyond the desktop. >>> I can't see the Kernel being made to swallow something that would >>> poison the whole multifaceted structure in the way that the various >>> distros swallowed the, "just another init, what's all the fuss >>> about?", ever expanding systemd. >>> >> >> Can you imagine the kernel supporting anything that is a problem for its >> biggest user? http://bit.ly/1ocxYwI >> >> > Android initially just grabbed kernel and forked off. > > I suppose you are right the Kernel Developers did go through the hassle of > luring Google back into the fold and the relationship gets positive press > for both. In that light it does seem unlikely that they would forego all > that, just to please the Poetterites. > > Clarke > > ___ > 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] We Must be Prepared ....
I'm not worried. Linus won't accept kdbus until he thinks it's in a position where it will be stable and easily supported for the foreseeable future. Watching kdbus get refactored a few times over this past year, I'd wager a guess that they're going to end up keeping as much of dbus in userspace as possible, and only add the parts that absolutely must run in kernel space to the kernel (as kdbus). Thus far, this has been limited to the memfd API, which is needed for zero-copy memory transfers. They'll probably also end up adding a specialized kdbusfs (akin to devpts) that offers namespaced and permissioned access to dbus endpoints, represented as a hierarchy of character device files. Remember, kdbus isn't dbus, anymore than a UNIX domain socket is dbus. The reason they're working on kdbus at all is because they have discovered that it's costly to pipe a lot of data between dbus endpoints, and it's hard to control capabilities, visibility, and access to them (since there are usecases where endpoints may not trust each other). Arguably, these problems can be addressed by using a combination of existing IPC mechanisms, but the argument that Greg KH and company put forth over and over again is that there's too much legacy code using dbus at this point (namely, from the IVI community and desktop communities) that we can't just tell them to refactor everything. It might be true--I don't know how big the IVI codebases are, for example. However, I don't really sympathize with the desktop communities--they built dbus to their specifications from their experiences with DCOP and Bonobo, and still managed to get it wrong. My $0.02. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Dng] Hal and Vdev
Hi Isaac,
On Wed, Jun 17, 2015 at 12:49 AM, Isaac Dunham wrote:
> On Tue, Jun 16, 2015 at 02:55:09PM -0400, Jude Nelson wrote:
> > Hi Isaac,
> >
> > On Mon, Jun 15, 2015 at 11:40 PM, Isaac Dunham
> wrote:
> > > I've looked at https://github.com/cshorler/hal-flash, and here's what
> > > I can make out:
> > > - This version uses dbus to connect to udisks2 for everything it
> > > doesn't stub out. I guess glib is used extensively.
> > > - Answers the following "property strings" for devices in
> > > libhal_device_get_property_string():
> > >system.hardware.serial, storage.bus, storage.serial
> > > In libhal_device_get_property_uint64(), only storage.size is answered.
> > > In libhal_manager_find_device_string_match(), a query about
> > > key "storage.drive_type", value "disk", returns a list of hard drives.
> > > storage.bus seems to be more-or-less "ata", NULL, or ...
> > > something else, I don't know what.
> > > I'm not sure if storage.size is free space or total size, but it's
> > > an unsigned 64-bit value.
> > >
> > > The system serial numbers are stored in
> > > /sys/devices/virtual/dmi/id/*_serial
> > > but are chmod 0400 (readable only to root).
> > >
> > > libhal_device_get_property_{int,double}() are stubs.
> > >
> >
> > Very interesting. I'm currently in the process of getting vdevd to parse
> > the udev hardware database and generate /run/udev, so we should soon have
> > the necessary machinery to define an action that makes vdevd write those
> > fields somewhere where a stub libhal library can find them. I'll look
> more
> > into this, if I can figure out the exact fields the stub libhal will need
> > (it seems that they all come from sysfs?).
>
> storage.serial won't, as far as I can tell; it comes from ata_id or the
> equivalent tool.
>
I already have that, then. I forked ata_id some time ago to create
stat_ata (installed to /lib/vdev/stat_ata), and vdevd's helper scripts
already use it to query (S)ATA disks to generate their persistent symlinks.
Thanks,
-Jude
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Dng] Hal and Vdev
Hi Isaac,
On Mon, Jun 15, 2015 at 11:40 PM, Isaac Dunham wrote:
> On Mon, Jun 15, 2015 at 08:18:18PM -0400, JeremyBekka C wrote:
> > > Hi Jeremy,
> >
> > > I have a question about the deprecated program hal. We like to stream
> > > videos from Amazon.com but we need hal installed in order to make it
> work.
> > > The Hal Debian wiki says that it is being deprecated and it is being
> > > replaced by udev (https://wiki.debian.org/hal). Since vdev is being
> > > written to replace udev, are there any plans to incorperate hal's
> functions
> > > into vdev or keep maintaining it seperaratly?
> > >
> >
> > Do you know what specific functions of hal you need? Hal's functionality
> > got split between udisks/udisks2, upower, and udev some time ago. Things
> > like device plug state, device properties, and device capabilities are
> now
> > tracked by udev (in /run/udev) and accessed by libudev, for example. My
> > goal for vdev is to be compatible with udev, so if you can use udev
> today,
> > you should be able to use vdev when it's ready.
> >
> > Thanks,
> > Jude
>
> Hal is used "for DRM", which in the context of Flash and the period
> of development almost certainly is "Digital 'Rights' Management".
> I would presume from the fact that one can load the flashplayer
> without it that the library is dlopen'd.
>
> I've looked at https://github.com/cshorler/hal-flash, and here's what
> I can make out:
> - This version uses dbus to connect to udisks2 for everything it
> doesn't stub out. I guess glib is used extensively.
> - Answers the following "property strings" for devices in
> libhal_device_get_property_string():
>system.hardware.serial, storage.bus, storage.serial
> In libhal_device_get_property_uint64(), only storage.size is answered.
> In libhal_manager_find_device_string_match(), a query about
> key "storage.drive_type", value "disk", returns a list of hard drives.
> storage.bus seems to be more-or-less "ata", NULL, or ...
> something else, I don't know what.
> I'm not sure if storage.size is free space or total size, but it's
> an unsigned 64-bit value.
>
> The system serial numbers are stored in
> /sys/devices/virtual/dmi/id/*_serial
> but are chmod 0400 (readable only to root).
>
> libhal_device_get_property_{int,double}() are stubs.
>
Very interesting. I'm currently in the process of getting vdevd to parse
the udev hardware database and generate /run/udev, so we should soon have
the necessary machinery to define an action that makes vdevd write those
fields somewhere where a stub libhal library can find them. I'll look more
into this, if I can figure out the exact fields the stub libhal will need
(it seems that they all come from sysfs?).
Thanks,
Jude
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Hal and Vdev
Hi Jeremy, On Mon, Jun 15, 2015 at 8:18 PM, JeremyBekka C wrote: > Hi Jeremy, > > I have a question about the deprecated program hal. We like to stream >> videos from Amazon.com but we need hal installed in order to make it work. >> The Hal Debian wiki says that it is being deprecated and it is being >> replaced by udev (https://wiki.debian.org/hal). Since vdev is being >> written to replace udev, are there any plans to incorperate hal's functions >> into vdev or keep maintaining it seperaratly? >> > > Do you know what specific functions of hal you need? Hal's functionality > got split between udisks/udisks2, upower, and udev some time ago. Things > like device plug state, device properties, and device capabilities are now > tracked by udev (in /run/udev) and accessed by libudev, for example. My > goal for vdev is to be compatible with udev, so if you can use udev today, > you should be able to use vdev when it's ready. > > Thanks, > Jude > > > As James Powwle pointed out, I need the function of hal that deals with > DRM on the Amazon videos. Since I have udev installed and Amazon videos do > not play without hal, does that must mean that udev is not responsible for > DRM? If so, then I misunderstood the point of the hal wiki because I > thought the functions of hal were included in udev. This would then seem to > indicate to me that udisks/udisks2 or upower should have taken over the DRM > function of hal, but that does not seem to be the case. > > My question is then, would it be possible to get the DRM functionality of > hal in vdev or one of the other programs? If so, how could that be > accomplished? I would like to not have to depend on a deprecated program if > I don't need to. > I don't know enough yet about why Amazon's DRM regime requires libhal and hal. A bit of googling on the train this morning suggests that Adobe flash player (the old unsupported one) needs it for some reason. I'm not sure why, though--I looked at the symbol table and linkage tables of the libflashplayer.so library, and didn't see any references to libhal or even dbus. Again, my main goal with vdev is udev compatibility, not necessarily hal compatibility. If the requisite functions from hal made it into udev, then it would be something I would work on as part of vdev's release. If not, then it's outside my scope, and would be a separate project. In the mean time, it looks like someone else has done the legwork to make hal installable without breaking the things that replaced it: https://launchpad.net/~mjblenner/+archive/ubuntu/ppa-hal Hope this helps, -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Jenkins build failures on build002
Thanks! Re-queuing it for build now... -Jude On Mon, Jun 15, 2015 at 3:17 PM, Franco Lanza wrote: > Anyway, it was a logrotate not running cleanly and a /var/log fill-up > the root fs. Now it's fixed > > -- > > 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 > --- > > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] Jenkins build failures on build002
Hey everyone, I thought this was an intermittent problem, but repeated trials have convinced me otherwise. Jenkins appears to be failing to set up its build directories for i386 and amd64 when I queue the dbus packages for building. The last console log for amd64, for example, is here: https://ci.devuan.org/job/dbus-binaries/35/architecture=amd64,label=amd64/console. In all cases, autobuild queued my build requests on host build002, so maybe something's wrong with that particular host? The arm64, armhf, and armel packages succeeded in that build. For testing purposes, is there a way I can tag a package to build on a particular host? Also, is there a way I can tag a package to build for a particular architecture? For future reference, I'm not sure where to report errors like on GitLab. Is there a preferred issue tracker for Jenkins-related bugs? Thanks, Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Hal and Vdev
Hi Jeremy, I have a question about the deprecated program hal. We like to stream > videos from Amazon.com but we need hal installed in order to make it work. > The Hal Debian wiki says that it is being deprecated and it is being > replaced by udev (https://wiki.debian.org/hal). Since vdev is being > written to replace udev, are there any plans to incorperate hal's functions > into vdev or keep maintaining it seperaratly? > Do you know what specific functions of hal you need? Hal's functionality got split between udisks/udisks2, upower, and udev some time ago. Things like device plug state, device properties, and device capabilities are now tracked by udev (in /run/udev) and accessed by libudev, for example. My goal for vdev is to be compatible with udev, so if you can use udev today, you should be able to use vdev when it's ready. Thanks, Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
My take-away from this and the related threads is that a daemon author would ideally provide options to have it: * Either write log messages to stderr or syslog, but write the same data regardless; * Either stay running in the foreground, or auto-background itself once it's ready to begin taking requests; * Write a PID file only at the user's request--that is, only if a path is given. I figure it's up to the user to select the combination of options suitable to address the task at hand, and it's up to the distro to select the sensible defaults. -Jude On Sat, Jun 13, 2015 at 2:37 PM, Laurent Bercot wrote: > On 13/06/2015 08:40, Didier Kryn wrote: > >> Yes, daemon writers are good-willing developpers; they want their >> software to serve as many users as possible; and users install >> distros. This gives power to the distros. But if someone provides >> them with a KISS readyness-signaling method, along with a systemd >> wrapper, then they can satisfy RedHat's requests at no cost. >> > > And there you go: > http://skarnet.org/software/sdnotify-wrapper.c > > Untested with a real systemd, because I'm not going to install a > real systemd anywhere - but I've listened to a socket on the other > end of NOTIFY_SOCKET and it appears to work. Bug-reports welcome. > > > The question now is who will develop, maintain and package this >> wrapper? Will Devuan be the official developper of >> "Systemd-Readyness-Wrapper", or can anyone convince Openssh or who >> else to take the job? Or are the daemon's developper powerfull enough >> to tell RH "do it yourself."? >> > > I'm willing to maintain this for the time being; as long as systemd > does not gratuitously break compatibility with itself, it should not > be too hard. The goal is to encourage daemon developers to stop using > the sd_notify() interface and just write a newline somewhere; the > wrapper is just there to make this simple behaviour work with systemd, > nothing more. > > I firmly believe it should *not* be packaged by Devuan. The wrapper is > meant to only be used on systemd installations, which is exactly what > Devuan is not. Devuan can advertise such a wrapper, advocate its use, > but I don't think it makes sense for it to be a part of the Devuan > distribution. > > I'm providing a single C file for now. I can turn it into a complete > package tarball with configure/make/make install if there's interest. > I'm not going to make distribution-specific packages, though; that's > the job of distribution maintainers. > > Enjoy! > > -- > Laurent > > ___ > 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] One issue with ongoing depoetterization
Hi Steve, So, if we code up a dummy sd_notify to interface replace the one from > systemd, we can make ongoing future depoetterization easier, and very > possibly give ourselves a better, easier to administer init. > If you're referring to this API [1], it doesn't look too bad. In most cases, it looks like we should be able to create a library that simply wrote the relevant information to a well-known location in the filesystem (such as "/run/srv/$SERVICE/..."). Other processes interested in the state of $SERVICE would just read it directly, and use inotify(2) to watch for state changes. Tooting my own horn here, but if we mounted runfs [2] on /run/srv/, we could also be guaranteed that /run/srv/$SERVICE/... automatically disappears if $SERVICE dies unexpectedly. Thanks, Jude [1] http://www.freedesktop.org/software/systemd/man/sd_notify.html [2] https://github.com/jcnelson/runfs ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Systemd sneaks in was file download zone
Hi Clarke, Can you: * give us a listing of which systemd packages are installed (something like "aptitude search systemd | egrep ^i")? * use "apt-cache rdepends" to show us which packages depend on them? Thanks, Jude On Thu, Jun 11, 2015 at 1:48 PM, Clarke Sideroad wrote: > On 06/11/2015 11:04 AM, Steve Litt wrote: > >> On Thu, 11 Jun 2015 08:35:34 -0400 >> Clarke Sideroad wrote: >> >> It seems my fresh netboot install this morning has swallowed and >>> installed systemd. >>> It was an "expert" 64bit install of "jessie" with XFCE and >>> subsequently firmware-linux-non-free had been installed for the >>> embeded video and then the fglrx-driver installed. Not sure where >>> it picked up the systemd along that path. >>> >>> Removing it and its namesake friends took out Network Manager, >>> PulseAudio, CUPS and a bunch of assorted other bits >>> I installed WICD to send this and will now put the furniture back in >>> place. >>> >>> Warning: You will probably be seeing more of this kind of info from >>> simple folks like me, now that testing is easier with a netboot iso. >>> >>> Clarke >>> >> Hi Clarke, >> >> First, from what I understand, the microsecond you get Devuan Alpha 2 >> installed, go into /etc/apt/sources.list and comment out the two from >> debian, leaving only the ones from devuan. I think that will help some. >> >> Second, my understanding is that NetworkManager and PulseAudio are so >> thoroughly infested with systemd that it's better to purge them from >> your system, like you'd throw a bedbug-ridden mattress into the >> dumpster. No use having that stuff hanging around. I **love** what >> they've done with Wicd, putting it on the menu right there in front of >> your face. Nice! >> >> Third, what leads you to the conclusion that your system installed >> systemd? On my VM-hosted Alpha-2 with LXDE, I have a whole bunch of >> files and directories with "systemd" in their names, but I think it has >> nothing to do with my bootup. >> >> To prove I was initting with sysvinit, I wrote the following >> shellscript called /root/testdaemon.sh: >> >> >> #!/bin/sh >> while true; do >>date >> /tmp/junk.log >>sleep 5 >> done >> >> >> The preceding program, when run, appends the time to /tmp/junk.log >> every five seconds, a thing you can see with the following command: >> >> tail -f /tmp/junk.log >> >> Then I put the following line right at the bottom of my /etc/inittab: >> >> SV:12345:respawn:/root/testdaemon.sh >> >> After I rebooted, /tmp/junk.log kept being appended, meaning that >> inittab was being read, meaning that sysvinit is doing the initting. >> >> >> Hi Steve, > > These were fresh UEFI hard drive installs not a VM. > From what I can see systemd is being installed with the base installation > in both jessie and ceres. > No debian in my sources.list only deb and deb-src devuan was in there, > either for jessie or ceres depending on the installation choice. > I noticed Sysvinit was being installed during the second install phase, > but on the boot I have systemd. > Maybe it is the init chooser that is defaulting to systemd. > > To confirm the installation of systemd, I checked by doing a search with > Synaptic and sure enough the slimy thing was there with a green box next to > it. > > I hope to mess with this later but it has swallowed too much of my time > already today. > I nuked the install and have returned to my hacked Debian version. > > Clarke > > > > > ___ > 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] vdev compatibility
Hi David,
On Mon, Jun 8, 2015 at 12:46 PM, David Hare wrote:
>
> Question for Jude:
>
> I use the live-boot tools a lot and make live-images. The live-boot
> scripts, which go in initramfs, rely a lot on udev and commands like "blkid
> -o udev"..
>
> Will vdev, when ready, have compatibility for such cases?
>
The "-o udev" directive tells blkid to format its output in a way that udev
can import it with an IMPORT{} directive in a rule. It should work
regardless of whether or not udev is installed.
I'm not familiar with the live-boot scripts, but in preparing initramfs
boot scripts for testing vdev, the only changes I've had to make are
starting vdev in place of udev, and mounting vanilla tmpfs on /dev instead
of devtmpfs. I'd imagine that it will be similar with live-boot scripts,
but I'll have to take a closer look. I'm happy to work with you and others
on ensuring that you can use vdev in place of udev wherever possible :)
> Thanks for all your good work. I'm actually using eudev at the moment
> (works fine in the "live" scripts) but look forward to trying vdev as soon
> as possible.
>
My pleasure!
Thanks,
-Jude
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] libudev-compat update
Hi Jack, On Mon, Jun 8, 2015 at 5:46 AM, Jack L. Frost wrote: > On Mon, Jun 08, 2015 at 01:31:40AM -0400, Jude Nelson wrote: > > Hey everyone, > > > > I've just pushed my first stab at libudev-compat to the vdev repository. > > It took a while to work out how to remove the need for udev to send > libudev > > clients device events, but I think I've figured out something that works. > > Is evdev supposed to work with this eventually? > Yes. In fact, my goal for alpha is to be able to use libudev-compat in conjunction with vdev to run X.org without an xorg.conf. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] libudev-compat update
Hey everyone, I've just pushed my first stab at libudev-compat to the vdev repository. It took a while to work out how to remove the need for udev to send libudev clients device events, but I think I've figured out something that works. Instead of sending events via a netlink multicast group, the device manager is expected to atomically put a serialized struct udev_device message into a set of process-specific directories (i.e. as strings that can be parsed by udev_device_new_from_nulstr()). Libudev-compat clients create these directories when they create struct udev_monitor instances, so the device manager need only write the event file somewhere privately, hard-link it into each such directory (ensuring "atomic send" semantics), and then unlink it. This means that pretty much any program you want can trivially send device messages to other programs as long as it can write to their directories, and inspect or even re-order pending messages. Instead of a netlink socket, a struct udev_monitor in libudev-compat contains an epoll handle, an inotify handle, and a socket pair. The epoll handle is used to indicate the readiness of the inotify handle, the "sink" end of the socket pair, or both, and is the pollable handle returned by udev_monitor_get_fd(). Libudev-compat ensures that a struct udev_monitor's handle will poll as ready-to-read if and only if there is at least one unprocessed device event. The inotify handle is set up to watch the process-specific directory for IN_CREATE events, in a one-shot fashion (the directory itself is created as part of udev_monitor_new()). When a client program receives a device event with udev_monitor_receive_device(), libudev-compat resets the one-shot inotify handle, scans the directory, and sends as many files' contents as it can as messages to the "source" end of the monitor's socket pair. Libudev-compat filters unwanted devices on the socket pair using a BPF program in the same way that libudev does for netlinks sockets (i.e. the logic is the same in both libraries). Devices events are sent in lexicographic order by name, and are consumed from the "sink" end of the socket pair. Because we're not using netlink anymore, we have to preserve multicast semantics across fork() as well--that is, if the process fork()'s and the device manager subsequently sends a device event, both the parent and child must receive it. To do so, libudev-compat maintains a global table of all existing monitors, which it does as part of udev_monitor_new() and udev_monitor_unref(). Upon fork(), as part of a pthread_atfork() handler, the libudev-compat child creates a new events directory, and re-targets all of its monitors' inotify handles to watch it instead. It also closes and re-opens each monitor's socket pairs, so it will not accidentally consume its parent's buffered device events. This ensures that the next time the child calls udev_monitor_receive_device(), it will look in its own directory, and it will receive and consume events independently of its parent, as desired. I have lightly tested libudev-compat's ability to do all of the above with a helper program for vdev (vdevd/helpers/LINUX/event-put.c), and with a test program that can be compiled with the "test" target in libudev-compat/ (i.e. "cd libudev-compat && make test"). It appears to work so far, but I invite the community to review the code and try it themselves. What I need to do next is create vdev scripts that will cause it to send off events to libudev-compat clients, using event-put. To do so, I'll also need to add helper scripts to generate and maintain /run/udev/, since the struct udev_device's that libudev-compat clients will expect to receive must include all of the metadata udev would generate for them. Thanks, Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] straw poll, non-free firmware for installers
On Wed, Jun 3, 2015 at 9:29 PM, Daniel Reurich wrote: > Ok, > > That was interesting > > Here's my thinking on the how and the why. > > definition of terms: > user = the person using the installer to install Devuan. > module = linux kernel module. > hardware = reference to the particular chipset(s) in scope, be they SoC or > plug in cards or devices. > firmware = non-free binary blob that is required to be loaded by the > standard kernel module for the hardware in scope in order for the hardware > to operate. > essential: required for proper operation. > > > How: > > > I will build a (udeb) package called firmware-reqd that: > > 1) Will provide an early detection of a select list of common essential > hardware that: > a) requires a non-free firmware blob > b) is essential to make the system use-able enough to complete the > installation to a bootable state. > > 2) Upon detection of said hardware, I will provide a prompt informing the > user about the specific piece(s) of hardware detected that require non-free > firmware to and give them the option to load that firmware and continue the > installation or abort it at that point. > > 3) Only firmware meeting the above criteria will be included in the iso, > but not used or loaded unless the operator specifically chooses to do so. > > 4) The choice to use non-free firmware will naturally lead to the question > about whether the related firmware deb packages should be installed during > the install. I could provide an option here, defaulting to yes but > allowing deselection for those who may want to leverage the non-free > firmware only during install but not on the running system. > > Note: When non-free firmware udebs are installed by debconf my > understanding is that each of them will present the user a license upon > which is also required to be accepted before that udeb is installed. > > > > Why this approach: > > I agree in principle about using strictly free/libre open source software, > and where I have the choice I personaly will select hardware that aligns > with those principles. > > However, I would not want my choices to become the tool that would punish > those less informed, or unable to make the sacrifices required to comply > entirely with that principle. To do so would be ungracious and unrealistic, > and boils down to elitism and puritanism. > > Nevertheless, to silently let the installation of non-free firmware be > done without recognition and challenge is not right either. So I see the > most gracious approach is to inform the users and grant them the > opportunity to choose how they would like to proceed. It gives opportunity > for those who for conscience sake would refuse non-free firmware to do so, > whilst not enforcing that choice an all users. > > I think that this is a reasonable approach, and once the above proposed > package is ready, it is my intention to have it included in the official > installer images we ship. Anyone that strongly objects can re-build their > own installers without the non-free firmware packages added. > > I like this approach as well as Nextime's. I generally favor approaches that help the users make informed decisions, but otherwise don't get in their way of them doing what they want with their computers. I can help out with steps 1 and 2, if you're interested. There's lots of overlap with my work on vdev. Thank you for all the hard work you've put into getting the Devuan installer ready! -Jude > > > > > On 03/06/15 20:37, Daniel Reurich wrote: > >> Hi, >> >> I'd like a straw poll on whether we should include non-free firmware in >> our installers by default. >> >> It's a deviation from Debians traditional position, but a pragmatic one >> that shows we care about the end users. >> >> Keen for feedback. >> >> >> > > -- > Daniel Reurich > Centurion Computer Technology (2005) Ltd. > 021 797 722 > ___ > 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] straw poll, non-free firmware for installers
On Wed, Jun 3, 2015 at 12:15 PM, Franco Lanza wrote: > > On Wed, Jun 03, 2015 at 08:37:22PM +1200, Daniel Reurich wrote: > > > > Hi, > > > > I'd like a straw poll on whether we should include non-free firmware in > our > > installers by default. > > > > It's a deviation from Debians traditional position, but a pragmatic one > that > > shows we care about the end users. > > > > Keen for feedback. > > Maybe we can think about having 2 images for every iso/installer, the > default onw as usual without any non-free package, and another one, > under a non-free directory structure with some large readme, with > non-free drivers bundled. This should not be a so huge additional > effort, and will give even more freedom of choice. > +1 > > -- > > 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 > --- > > > ___ > 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] New systemd release notes regarding udev.
Hi Jim, > It seems udev is getting split up between several projects within systemd > and GNOME. It seems gudev is being handed off in the future to GNOME and > parts of udev are being pushed deeper into systemd. > > gudev splitting off isn't a problem; in fact, I applaud the decision. > I'm not surprised at this, since kdbus didn't get pushed into the kernel > mainline, but it does show evidence of the callousness being presented to > the Linux ecosystem. If they don't get their way one way, they try to get > their way another. > > I am wondering how much longer eudev can remain tied to systemd-udev, > unless it becomes completely independent. We still are waiting on the > progress of vdev, patiently. So until then, it seems to be wait and see yet > again. > vdev will ship with libudev-compat, which is ABI-compatible with the public API of libudev 219. I'm afraid I couldn't manage ABI compatibility with the private API, but AFAIK only udev and systemd were its clients anyway. Also, vanilla libudev 219 doesn't overlap that much with systemd, so we can easily build our own and ship that in place of libudev 220+ in the near-term. libudev-compat is still a work in progress, but it's my last major blocker, and I hope to have something testable by early next week. The key challenge has been in removing the need for the udev-controlled netlink multicast group to deliver events while continuing to provide the same semantics at comparable performance. While my approach almost certainly won't be as fast as netlink-based libudev, it should: * be fast enough for our purposes (will provide actual performance data when I have them); * be easier to troubleshoot (i.e. the admin can read, inject, reorder, copy, and remove device events without having to instrument the device manager, the kernel, or the libudev client); * be agnostic to which device manager (if any) is running; * let the admin control which root-context events get propagated to containerized libudev clients (something udev and libudev *cannot* do, due to their reliance on netlink). You don't have to wait up for me, though--Devuan's udev and eudev are ready to use now :) Developing vdev and libudev-compat is one of several contingency plans for the scenario where udev and libudev become intractably dependent on systemd. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Lennart reacts to the release of Devuan
On Sun, May 31, 2015 at 2:16 AM, Yves wrote: > Frankly, I find this video simply inappropriate, unnecessary and > inflammatory. > Just my 2 cents. > > If you do not like his code. > Just make do without the code. > > Damn I find this distasteful!! > Agreed. > > > > > On 31 May 2015 1:51:01 PM ACST, Init Freedom > wrote: >> >> https://www.youtube.com/watch?v=_cdEFF-ttLw >> >> May the source be with you, gents. >> >> -- >> >> Dng mailing list >> Dng@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > ___ > 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] OT: separate GUI from commands
Hi Jonathan, > > Yes I know, I was trolling. But it was a friendly troll. See, I included > a hash at the end of my email. Here is my Proof-of-Troll(tm) that matches > that hash: > > echo "Sorry but I couldn't resist trolling you here. :) Still intrigued by > your file-system based widget idea, though." | sha256sum > > Haha, good one! > In retrospect I should have been more detailed that the troll was playing > dumb about Visual Basic, but if you switch the order > of my two categories you can see the strong evidence. :) > > > If anything, I think it validates the case for a system like shui. The > fact that different applications in different problem domains independently > gain built-in support for scripting suggests that there's a > naturally-occurring need to be able to interact with applications > programmatically as well as interactively. So, why not design applications > with this need in mind from the get-go? > > > I think because you would need to have all the applications use the same > language. > Not necessarily. See below. > > For example, if I use the 'lg' console in Gnome Shell (which is > essentially just a poor man's HTML5 devtools) I can get access > to javascript objects that represent the various elements of the DE. But > when I say 'element' I only mean the x11 windows > and the pre-fabbed Gnome widgets and stuff. For example, I can't inspect > the "Save" button in Thunderbird and change its > attribute "display" to "none". That makes 'lg' so limited that I can > safely say I've never used it in all the time I've used Gnome. > Funny you bring up GNOME as a related example. A few GNOME developers on Twitter just spent the last few days hating on the very idea of a scriptable UI (and the Devuan community in general), all in response to this very email thread. > I use the devtools in Chrome and Firefox all the time, however. I do this > because most of the time I can inspect every element > that makes up the web page or app I happen to be viewing. (I can also get > FPS, profile, and all kinds of other invaluable > instant feedback.) Exceptions are of course webgl and HTML5 canvas > (because those contents are just pixels), but I don't run into those so > often in my normal browsing. > > This is already slow with all apps on the web (well, most) using the same > language (and being optimized on the fly on modern > browsers). Seems like for this to be workable on the desktop you'd need > wrappers for various languages which would add even more overhead. > > But it's quite possible I've misunderstood the upshot of the system you're > describing. > The design is still pretty rough in my head (I brought it up because it was related to Hendrik's original post, and it seemed like a good time to get feedback), but I don't think shui needs to have the same design as a Web browser. It wouldn't track nearly as much information, for example. All it would need to do is render the application's UI and run helper programs as subprocesses to handle UI events. It's not a perfect fit for every graphical application, but my goal would be to make it easier to make applications whose behaviors can be systemically extended and automated by the user. Thanks, Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] automounting in a window manager
Hi Robert, > It says, among other things, that udev can be configured to handle > automounting. That's nice, but since systemd has polluted udev beyond > repair, I'm wondering if Devuan can be set up to handle it better, perhaps > with vdev. Or is there a better way? > > Have you considered pmount(1)? Or, were you looking for something more automated? Related to vdev, one feature in my pipeline is to create a "vdevd-user" daemon to replace udisks/udisks2 and upower. It would behave almost the same as the system-wide vdevd, but with the following key differences: * it would get started as part of a user's login session, * it would run under the user's permissions, * it would watch the contents of /dev/ with inotify (Linux) or kqueue (BSD), instead of listen to the kernel for hotplug events. The system vdevd would populate /dev/ per usual, and your vdevd-user instance would run your user-defined actions when device files and metadata appear or disappear. One such action could be to run pmount(1) to mount (or umount) removable media. Another action might be to change your CPU performance profile and backlight on your laptop if your AC power state changes (NB: while there are no device files for ACPI devices, vdevd receives events about them and records them to /dev/metadata/, which vdevd-user could watch and act on). It's worth pointing out that vdevd-user could easily work with udevd, mdev, or a static dev as well--the device manager only needs to create the requisite files for vdevd-user to consume. There's no need for a dedicated dbus interface, client library, or init system. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
Hi Jonathan, Shell-based command access to software like Powerpoint would indeed be > great. But I wonder if we can raise the bar a bit > and consider an approach that could serve the largest audience. > Especially users who themselves aren't developers or > programmers. > > It seems to me such a system must be characterized by the following two > properties: > * basic - the language itself should be simple enough that the user > doesn't have to spend too much time on boilerplate and > learning eccentricities of the language. (And the environment should be > able to generate as much of the boilerplate on its own, > especially for common patterns.) > What language would you propose? If I create shui, I'd make it language-agnostic so users can select whatever language(s) they want. My example with shell scripts was just to illustrate the possibility :) > * visual - we know the user is already interacting with a graphical > system. So it makes sense that the command-based > system should include graphical modes of interaction and visualize as much > as it can. (For example, letting the user choose > from a set of familiar widgets rather than making them memorize a baroque > naming system.) It should look as familiar as it > can without sacrificing power, letting the user see as much of the data > flow without having to create the entire mental model > on their own. > Yeah, a RAD tool would be a natural extension of the idea! > Just imagine the possibilities if Powerpoint gave you access to an > environment like that! > It didn't occur to me when I wrote my original email, but it turns out Powerpoint can be scripted with VBA. So can Libreoffice (it supports Javascript and Python as well as Libreoffice Basic). There are others, like Blender, GIMP, KDE (i.e. SuperKaramba, Plasma, Kross), GNOME 3, the NetBSD kernel (Lua), the Linux kernel (ePBF), and so on, that I had forgotten to list. If anything, I think it validates the case for a system like shui. The fact that different applications in different problem domains independently gain built-in support for scripting suggests that there's a naturally-occurring need to be able to interact with applications programmatically as well as interactively. So, why not design applications with this need in mind from the get-go? -Jude PS Not sure why, but your email hit my (Gmail's) spam filter. Just thought you should know :) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
Hi Steve, excellent feedback as always :) On Wed, May 27, 2015 at 4:41 PM, Steve Litt wrote: > On Wed, 27 May 2015 14:27:17 -0400 > Jude Nelson wrote: > > > > I've been thinking about the general form of this problem (and a > > general solution) for months, and I think I'm almost ready to provide > > a formal design document. > > > > [The Problem] > > Many programs couple the business logic to the presentation logic. > > The code that drives the UI is too intermingled with the code that > > provides the application's core functionality to use them separately, > > or develop on them independently. > > Hi Jude, > > Be careful what you wish for. MVC was created to solve this problem, > and it looks to me like, in the hands of most developers, like MVC > makes an unfathomable Easter Egg Hunt where a reasonably simple > algorithm can't go six lines without the need to go look something up > somewhere else. And yet, in the hands of most practitioners, my > observation is they *still* manage to intersperse program logic, data > and UI. > > Separation is good, but not all ideas for separation are good. > Yeah, MVC can get out of hand if used improperly. However, that's can be because sometimes MVC isn't the right factoring in the first place, but (for Web applications in particular) a lot of development frameworks force developers to try to shoehorn their applications into it nevertheless. I should point out, I don't see shui as an MVC-like framework. I see shui as way to compose unrelated individual programs that each implement a single UI element to create complex graphical applications, in the same spirit as using the shell to compose unrelated individual programs that each implement a data stream filter to create a pipeline that accomplishes a complex data transformation. I'd use the shell with zenity to accomplish what I'm proposing with shui, except that I additionally want to expose the structure of the UI as a first-class aspect of the application as well. This is because I want to let the user arrange the UI elements of an application however they see fit without having to touch any code (i.e. they can create and preserve whatever workflow they want irrespective of the developer's intentions), and I want the user to be free to borrow UI elements from one application and put them in others (i.e. we can never lose features; only disable them). > > [clip] > > > [Motivation] > > I was watching my SO create a (long) Powerpoint presentation the > > other day, and she wanted to add a "fade in" animation to each bullet > > point on each slide. Powerpoint (and every office suite I'm familiar > > with) makes you do this by hand, bullet-point by bullet-point, with a > > mouse. The UNIX hacker in me saw this, and wondered why it's not > > possible to simply open a shell and run something like "for > > ppt_bullet in $(ppt-ls "bullets"); do ppt-animate "fade-in" > > "$ppt_bullet"; done". This would have saved an hour of tedious, > > repetitive effort. > > > > The reason this isn't possible is because Powerpoint (and every other > > office suite) does not offer a command-oriented UI. What could > > Powerpoint have done? One option is to add a program-specific > > command-language (like how vim and emacs do). However, I don't think > > this the answer either, for two reasons: > > (1) The UI (the command-language in this case) is still tightly > > coupled to the program, and has rules and semantics that are only > > applicable to the program. > > I think #1 above is a *good* thing. There's a reason it's called a > *domain* specific language. It's the functions of this program's > "business logic", and nothing more. > > Yes, domain-specific languages have their place. However, all Turing-complete languages are equivalently powerful. So, there had better be a compelling reason to spend time designing a domain-specific language that you then expect users to go learn just to use your program properly, as opposed to embedding support for a more general language that the user already knows (or can easily learn through 3rd party resources) and shipping a library for that language that exposes your domain-specific functionality. It's a bit of digression, but the point I'm arguing is that unless the programming paradigm itself is so specific to your problem domain that you need a whole new programming language to describe its system of logical axioms (this is rarely the case), I think developers and users are better off with the latter option since it doesn't re-invent the wheel and doesn't waste th
Re: [Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
Hi Hendrik, On Wed, May 27, 2015 at 12:35 PM, Hendrik Boom wrote: > On Wed, May 27, 2015 at 02:27:17PM -0400, Jude Nelson wrote: > > Hi Hendrik, > > > ... (much snipped) (I'm sorry, I hadn't meant to take you away from > vdev for the amount of time it took to write this lengthy and > interesting reply) > > > > > An interesting consequence of structuring applications this way is that > you > > can trivially solve both network transparency and application > distribution: > > simply put the application on an NFS mount (or some network filesystem), > > and run the interpreter on the local client. The application stores > > runtime state as files within its directory hierarchy, so they get > > automatically written to the NFS server. Users could run remote > > applications locally simply by mounting the remote volume and running the > > interpreter on them in-place. > > > > > I was considering building such an interpreter as well as and a suite of > > applications for Devuan at some point, after finishing vdev. I was > > thinking of calling it "shui"--both from the concept of "feng shui" (the > > idea of harmonizing everyone with their environment), as well as serving > as > > an acronym for "SHell-oriented User Interface". > > Sounds interesting. But for applications like ordinary text editing, > it might become a little slow if you end up running a shell script > with every character typed. The idea did seem to work somewhat for > the ancient mail handler MH (if I recall correctly). > > But as for the file system ... I wonder if the completely virtual file > system in something like Inferno could help things along -- put more > of the primitive operations into the file itself. Or have I > misunderstood Inferno? > > Of course, taking this to its logical conclusion would move the > file system rather seriously in the direction of a typed persistent > objects system, with methods and so forth. A very different beast > from what we're used to. > These are excellent points. I should clarify, shui itself would be designed as an aggregate of programmable widgets. Each one would know how to render itself, and how to interpret a particular directory and run its scripts. One such widget would be a text area with the capabilities you originally described. The value shui provides is that it would make it very easy for users to swap out parts of the text editor they didn't want, or mix and match components without having to become developers and without having to re-compile the application. I don't think we'd need a typed persistent object system at the end of the day, since unless all application developers agreed to it, there wouldn't be a unified type system in the first place. Flat files of bytes should be just fine for the purpose of developing applications--if the application needs an advanced type system, it can implement it itself. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
Hi Hendrik, On Wed, May 27, 2015 at 6:12 AM, Hendrik Boom wrote: > On Wed, May 27, 2015 at 03:32:00PM +0200, Laurent Bercot wrote: > > > As a rule of thumb, developers should always use the smallest possible > > amount of dependencies for a project, and clearly separate layers - e.g. > > if a project comes with an engine and a GUI, then the engine should come > > as a command-line tool in its own package with no dependencies on > graphical > > stuff, which would be the role of the GUI package. But I'm a dinosaur AND > > a fan of minimalism, so I don't expect many people to think like me. > > I mean this as a serious question, not as a piece of sarcasm, > though it could easily be misconstrued as such. > > I am testing the limits of the advice to separate interaction from > command line, though. Sometimes limit testing leads to discoveries. > > I'm in the process of writing (yet) a(nother) editor and output formatter, > and on reading this, I started to wonder -- just how could one separate > a command-line version from the UI? I can see that the output > formatter can be so separated (and very usefully), but the actual > editing? > > Brainstorming welcome. > I've been thinking about the general form of this problem (and a general solution) for months, and I think I'm almost ready to provide a formal design document. [The Problem] Many programs couple the business logic to the presentation logic. The code that drives the UI is too intermingled with the code that provides the application's core functionality to use them separately, or develop on them independently. However, we would like to be able to do this in order to allow the user to apply existing tools and skills in one domain without affecting the other domain, and allow developers to innovate in one domain without affecting the other. This should be possible, since rendering a UI is usually (but not always) a separate, orthogonal concern from performing the desired functionality. [Motivation] I was watching my SO create a (long) Powerpoint presentation the other day, and she wanted to add a "fade in" animation to each bullet point on each slide. Powerpoint (and every office suite I'm familiar with) makes you do this by hand, bullet-point by bullet-point, with a mouse. The UNIX hacker in me saw this, and wondered why it's not possible to simply open a shell and run something like "for ppt_bullet in $(ppt-ls "bullets"); do ppt-animate "fade-in" "$ppt_bullet"; done". This would have saved an hour of tedious, repetitive effort. The reason this isn't possible is because Powerpoint (and every other office suite) does not offer a command-oriented UI. What could Powerpoint have done? One option is to add a program-specific command-language (like how vim and emacs do). However, I don't think this the answer either, for two reasons: (1) The UI (the command-language in this case) is still tightly coupled to the program, and has rules and semantics that are only applicable to the program. (2) Without careful design, the user can't bring to bear existing knowledge or existing tools to address problems. This is a general gripe I have against vim and emacs too--if you're going to offer a Turing-complete command language, why not offer one that is widely-used already and lets people use external tools? What I would like the most is if Powerpoint were somehow designed so that its runtime state was exposed to the system shell, so I could operate on it directly. Powerpoint wouldn't need to ship with its own custom language, and I could use whatever tools I wanted. [Related Work] This is something that Smalltalk/SQUEAK got right, as well as SecondLife (but to a lesser extent). In these environments, a UI element is fully scriptable by the user, and can access functionality in other UI elements and store persistent state within them. As a user, I can easily add my own functional overlays on top of the application, as well as my own custom UIs that extend the functionality of the application on-the-fly. If Powerpoint were written as a SQUEAK application, I might have been able to write and attach a button on-the-fly that iterated through each bullet point and added an animation. This is something that RESTful Web services sometimes get right as well. The business logic in a RESTful Web service is meant to be decoupled from the CSS/HTML/Javascript UI, so you should be able to use use any HTTP-speaking client to interact with the business logic on the remote servers. For example, this lets Web front-end developers create mash-ups of multiple services, and it lets devops and back-end developers write scripts with curl to interact with services. The downside is that you're limited by the availability and expressiveness of the RESTful API (which you do not control). Applescript, ActiveScript, and nowadays Powershell try to do something like this, but they fall short architecturally in that they can't access and operate on all of the application's
Re: [Dng] vdev status update (May 25 2015)
Hi Anto, On Wed, May 27, 2015 at 6:19 AM, Anto wrote: > > > On 25/05/15 18:29, Jude Nelson wrote: > >> Hey everyone, >> >> I have the latest news for vdev: >> >> . > > . > >> Thoughts and feedback to the above welcome :) >> -Jude >> >> > Thanks a lot Jude for all your efforts. > > Since you put a big fat warning "**CURRENTLY BROKEN. DO NOT ATTEMPT. WE > ARE MIGRATING TO .DEB PACKAGES.**" on > https://github.com/jcnelson/vdev/blob/master/how-to-test.md#appendix-b-booting-with-vdevd > about 13 days ago, I have been waiting for your update on the deb build > package script so I can continue testing. How far are we on that? Please do > not assume that I am pushing you. > > If that would be quite far due to higher priorities on other parts of vdev > development, how about if you included test cases for any parts of vdev > that still need testing? > > For instance, a simple list like below would help novice testers like me > (and hopefully help speeding up vdev development as it looks getting more > complex): > > 1. Test Case A Title > Test Unit: vdev function X > Expected Result: test pass> > Test Result: Pass or Fail > Test Log: > > 2. Test Case B Title > Test Unit: vdev function B > Expected Result: test pass> > Test Result: Pass or Fail > Test Log: > > And so on. > > I think that will also help you shifting your priorities in putting your > efforts on each parts of vdev development. > > Cheers, > > Anto > > What you're asking for is a black-box test suite. In most software systems, this is highly desirable, and is usually added into the CI so the CI can verify that all tests pass before generating a package. Unfortunately, systems like udev and vdev are exceptions--their "expected results" are tightly-coupled to the underlying hardware. There's no way to categorically describe the expected results without also describing all the relevant aspects of the underlying hardware as well, and there are as many different hardware configurations as there are users (so each user has a different expected result). The best I can do is verify that vdev produces a /dev that has the same files that udev would have created on the same hardware. I'm still figuring out the packaging. My goal is to add Makefile targets to use fpm to generate packages (for testing and cross-distro compatibility), and then worry about adding the Devuan-specific control files to get vdev hooked into the CI system (ideally, I'd find a way to get fpm to generate those for me too). -Jude > ___ > 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] vdev status update (May 25 2015)
Hi Hendrik, On Mon, May 25, 2015 at 2:25 PM, Hendrik Boom wrote: > On Mon, May 25, 2015 at 12:29:12PM -0400, Jude Nelson wrote: > ... > > What I'm working on going is the following: > > * fork runfs to create eventfs, a RAM-backed userspace filesystem that > > looks and smells like tmpfs, but is designed such that (1) files and > > directories share fate with the process that creates them, and (2) the > > filesystem remembers the order in which files in a directory are created. > > We'd use it to implement reliable one-writer many-reader uevent packet > > multicast. Specifically, the eventfs would work like a tmpfs, but with > the > > following different behaviors: > > -- a directory and its children only exist if the process that created it > > is still running. Once the process dies, the directory and its children > > are automatically removed. > > -- each directory contains an eventfs-managed "head" symlink that points > to > > the newest-created regular file child > > -- each directory contains an eventfs-managed "tail" symlink that points > to > > the oldest-created regular file child > > -- unlink()-ing "head" really unlinks the file that "head" points to, and > > causes "head" to point to the next-newest regular file child > > -- unlink()-ing "tail" really unlinks the file that "tail" points to, and > > causes "tail" to point to the next-oldest regular file > > Just wondering what happens if process A creates a directory in > eventfs, process B makes it its working directory, and then process A > dies. Does process B end up with a nonexistent working directory? > umount won't let me do this. WOuld this be different? > The directory would continue to exist as long as there was at least one open handle to it, but subsequent path resolutions on it or any of its descendants would fail. The effect is basically the same as "rm -rf"-ing the process's working directory. Also, like with any other filesystem, you would be unable to unmount it until all handles were closed. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] vdev status update (May 25 2015)
Hey everyone,
I have the latest news for vdev:
* Added support for /dev/snd/by-id symlinks (thanks Jack L. Frost aka
openfbt!)
* Merged support for static linking vdev, building a libvdev.a archive
file, and building vdev with non-GNU libc (thanks Didier Kryn!)
* Added support for optionally running device helper scripts, even if the
device still exists. This is because sometimes other programs can create
device nodes independently of vdev, but not set them up appropriately. By
default, vdev will assume that a device is already set up if its device
file(s) exists already, and will not run any of its helper scripts. While
this means that scripts do not need to be idempotent by design (i.e.
they're run at most once), it also means that any program that creates a
device file is expected to set it up as well. This is inappropriate, since
managing device policies (i.e. permissions and persistent symlinks) is the
job of the device manager, not tools that happen to create device files.
To address this, vdev action files now support an "if_exists" directive,
that can be set to:
-- "run", as in, run the action's commands even if the device exists;
-- "mask", as in, don't run the action's commands, but don't report an
error that the device exists
-- "error", as in, stop running actions for this device (even if there are
still some to be processed), and log an error.
The absence of an "if_exists" directive causes vdev to try to run all
action commands for a device if the device does not exist, but report an
error if it does exist.
Thanks Scooby for the suggestion!
* [WIP] I'm making progress on libudev-compat, an ABI-compatible libudev
replacement that does not depend on udevd (or netlink or systemd or kdbus).
A bit of background: libudev defines an opaque "struct udev_monitor" that
contains a client-accessible pollable file descriptor, an API for defining
device event filters, and a method ("udev_monitor_receive_device") for
receiving "struct udev_device" instances generated from hotplug events.
Clients get the file descriptor and poll() on it, and then receive "struct
udev_device" instances from the associated monitor. The way it works under
the hood today is the pollable file descriptor is a non-blocking raw
netlink socket that listens to udevd's multicast group (btw, this is one of
the reasons why udev can't run in a container); the filtering API
implements code to build and attach a BPF filter to the socket that
implements the client's filter preferences; and
"udev_monitor_receive_device" receives the next serialized "struct
udev_device" message from udevd's multicast group and returns it to the
client.
What I'm working on going is the following:
* fork runfs to create eventfs, a RAM-backed userspace filesystem that
looks and smells like tmpfs, but is designed such that (1) files and
directories share fate with the process that creates them, and (2) the
filesystem remembers the order in which files in a directory are created.
We'd use it to implement reliable one-writer many-reader uevent packet
multicast. Specifically, the eventfs would work like a tmpfs, but with the
following different behaviors:
-- a directory and its children only exist if the process that created it
is still running. Once the process dies, the directory and its children
are automatically removed.
-- each directory contains an eventfs-managed "head" symlink that points to
the newest-created regular file child
-- each directory contains an eventfs-managed "tail" symlink that points to
the oldest-created regular file child
-- unlink()-ing "head" really unlinks the file that "head" points to, and
causes "head" to point to the next-newest regular file child
-- unlink()-ing "tail" really unlinks the file that "tail" points to, and
causes "tail" to point to the next-oldest regular file
* We will mount eventfs on /dev/events/.
* libudev-compat creates the directory /dev/events/libudev-$PID/ when the
client starts, effectively giving it an in-order queue of device events.
Because directories share fate with the processes that create them in
/dev/events, the client doesn't need to remove /dev/events/libudev-$PID/
when it exits (i.e. you can kill -9 it without polluting your filesystem
tree).
* create a tool called "event-put" that writes a device uevent packet to
/dev/events/$PID_OF_DEVICE_MANAGER/$SEQNUM, hard-links it to each
/dev/events/libudev-*/$SEQNUM, and then unlinks
/dev/events/$PID_OF_DEVICE_MANAGER/$SEQNUM. This implements a zero-copy
uevent multicast--the packet is written once (as a file), but each
libudev-compat client receives a reference to it (as a hard-link).
* I'll implement "struct udev_monitor" as follows:
-- the pollable file descriptor will be an inotify watch handle on
/dev/events/libudev-$PID/, and it watches for IN_CREATE. As a consequence,
the file descriptor will have data available whenever event-put adds a new
uevent to be processed. This means clients can continue to poll on this
file descripto
Re: [Dng] Suggestion for vdev
Hi James, Apologies for the late reply--things have been busy at work lately. I'd be happy to add an OpenRC init script :) I opened an issue for it here: https://github.com/jcnelson/vdev/issues/27 Also, a BSD-style init script would be nice at some point ( https://github.com/jcnelson/vdev/issues/28). -Jude On Wed, May 20, 2015 at 9:05 PM, James Powell wrote: > Jude, when vdev gets mature enough, could you submit an init script to the > OpenRC project, please? > > Thanks, > Jim > > ___ > 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] A novice attempt to speed up Devuan development
Hi Jaret, On Sat, May 16, 2015 at 11:28 PM, Jaret Cantu wrote: > Just pushed eudev to the Devuan git. > > https://git.devuan.org/jaretcantu/eudev > > I used eudev version 1.9 since it is based on systemd 215. That is the > udev/systemd version used by Jessie, so it just seemed to make a lot more > sense. > > I'm using it right now (and I'm pretty sure I've committed all of the > manual changes I had to make on account of whoopsies), and the only > difference I see in before-and-after "ls -Rl /dev"s is two extra pts. > > I uploaded all of the git-buildpackage stuff, too, so it should be easy to > recreate. > > Probably some systemd scraps that I didn't properly scrub. I was not > terribly diligent with checking for all of the unnecessary dependencies. > > I think you need a kernel with FHANDLE, too, for eudev to work properly. I > got error messages until I recompiled my kernel. > This is WONDERFUL news! I'm so glad you were able to get this to work! As you say, it's not easy to separate systemd from udev. Hats off to you :D Best, Jude > On 05/07/2015 02:47 PM, Anto wrote: > >> >> >> On 07/05/15 18:00, Anto wrote: >> >>> >>> On 07/05/15 17:32, Svante Signell wrote: >>> On Thu, 2015-05-07 at 16:53 +0200, Anto wrote: update-initramfs: deferring update (trigger activated) > update-rc.d: warning: start and stop actions are no longer supported; > falling back to defaults > No idea about this one. insserv: script eudev: service udev already provided! > insserv: exiting now! > update-rc.d: error: insserv rejected the script header > dpkg: error processing package eudev (--install): >subprocess installed post-installation script returned error exit > status 1 > This is probably due to that the eudev.postinst? and udev.postinst scripts differs. Check these scripts in debian/ and compare with the one from udev. HTH >>> >>> Thanks for the hints. I just put back the previous disk image and I am >>> looking at them now. >>> >>> >> I think I don't want to fiddle around any further and I just want to >> forget having eudev package. >> >> My last attempt just now was to try to match the environment used by the >> build script on >> https://git.devuan.org/pkgs-utopia-substitution/devuan-eudev, to avoid >> any unnecessary changes. That is by using Debian wheezy install with kernel >> 3.2, udev 175-7.2 and eudev-2.1.1.tar.gz. I also tried eudev-2.1.tar.gz. >> But those did not even pass the configure script, because the include >> directory was not found. I am not sure what kind of setup was used when the >> build script was being developed. Anyway, I am done with this :) >> >> anto@d945gclf:~/packages/eudev/eudev-2.1.1-1+devuan$ >> anto@d945gclf:~/packages/eudev/eudev-2.1.1-1+devuan$ dpkg-buildpackage >> -us -uc >> dpkg-buildpackage: source package eudev >> dpkg-buildpackage: source version 1:2.1.1-1 >> . >> >> . >> checking for unistd.h... (cached) yes >> checking linux/btrfs.h usability... no >> checking linux/btrfs.h presence... no >> checking for linux/btrfs.h... no >> configure: error: *** KERNEL header not found >> make: *** [build-deb/config.status] Error 1 >> dpkg-buildpackage: error: debian/rules build gave error exit status 2 >> anto@d945gclf:~/packages/eudev/eudev-2.1.1-1+devuan$ dpkg --list | grep >> linux >> ii console-setup-linux 1.88 all Linux specific >> part of console-setup >> ii doc-linux-text 2008.08-1 all Linux HOWTOs and >> FAQs in ASCII format >> ii libselinux1:amd64 2.1.9-5 amd64 SELinux runtime >> shared libraries >> ii libselinux1-dev 2.1.9-5 amd64 SELinux >> development headers >> ii linux-base 3.5 all Linux image >> base package >> ii linux-headers-3.2.0-4-amd64 3.2.68-1+deb7u1 amd64Header files >> for Linux 3.2.0-4-amd64 >> ii linux-headers-3.2.0-4-common 3.2.68-1+deb7u1 amd64Common >> header files for Linux 3.2.0-4 >> ii linux-image-3.2.0-4-amd64 3.2.68-1+deb7u1 amd64Linux 3.2 for >> 64-bit PCs >> ii linux-image-amd64 3.2+46amd64 Linux for >> 64-bit PCs (meta-package) >> ii linux-kbuild-3.2 3.2.17-1 amd64 Kbuild >> infrastructure for Linux 3.2 >> ii linux-libc-dev:amd64 3.2.68-1+deb7u1 amd64Linux support >> headers for userspace development >> ii util-linux 2.20.1-5.3amd64 Miscellaneous system >> utilities >> anto@d945gclf:~/packages/eudev/eudev-2.1.1-1+devuan$ >> anto@d945gclf:~/packages/eudev/eudev-2.1.1-1+devuan$ dpkg --search >> btrfs.h >> linux-headers-3.2.0-4-common: >> /usr/src/linux-headers-3.2.0-4-common/include/trace/events/btrfs.h >> linux-headers-3.2.0-4-common-rt: >> /usr/src/linux-headers-3.2.0-4-common-rt/include/trace/events/btrfs.h >> anto@d945gclf:~/packages/eudev/eudev-2.1.1-1+devuan$ >> anto@d945gclf:~/packages/eudev/eudev-2.1.1-1+devu
Re: [Dng] [dng] vdev status update (2015-05-03)
Hi Steve, On Thu, May 14, 2015 at 11:03 AM, Steve Litt wrote: > On Wed, 13 May 2015 23:24:42 -0400 > Jude Nelson wrote: > > > Hey everyone, > > > > I have the latest news for vdev: > > > > * vdev now creates symlinks for: > > -- /dev/v4l/by-path > > -- /dev/disk/by-partuuid > > -- /dev/disk/by-partlabel > > Thank you Jude. It's astounding what you've been able to accomplish. > Thanks! Fortunately, it's not as bad as it looks--it's mostly a matter of reading the udev rules files and writing a script that does the same thing :) > > > > * the initramfs hook conditionally pulls in iproute2, lvm, dmsetup, > > blkid, etc. > > I can think of few things more brain taxing than writing a program to > tweak a RAM filesystem and accompanying init script that will be used > on the *next* boot. Troubleshooting and experimentation must be a slow > process, with boots intervening. Even on a VM on a fast host. > Yeah, it can get pretty tedious. Fortunately, I'm using a minimal QEMU image, so reboots happen pretty fast (i.e. the working set fits entirely in my disk cache). I have developed a new-found appreciation for the people who designed Debian's initramfs system. Despite the tediousness of building cpio images, Debian's initramfs-tools package is surprisingly flexible and well-documented. There are a couple little things it could make the process less painful, though; I'm in the process of getting together some patches to send to Debian, if they're interested. > > > > > > [For Next Time] > > > > * The next immediate objective is to package vdevd for Devuan, to > > make it easier to test (in particular, easier to get a working > > initramfs). > > Could you please make sure that there's a way for us Qemu users to use > it? I don't know whether I'm the only one, but Vagrant errors out on my > Debian Wheezy machine. So I'm still using the Valentine edition. > Absolutely! I intend to make the first iteration of packages available as direct downloads (will post hashes to the ML), and will continue to do so until I can figure out how to hook the vdev repository into Devuan's CI system. Thanks, Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] A novice attempt to speed up Devuan development
Following up to what T.J. said... On Thu, May 14, 2015 at 1:15 PM, T.J. Duchene wrote: > > > I think the fact that I pointed out clearly shows that there is very good > > technical reason to exclude udev, unless you are willing to be the > maintainer > > of udev outside systemd source tree in Devuan. > > [T.J. ] Please understand that I very much respect your position, and I > agree with you that a "put up or shut up" attitude can be warranted in many > instances. However, I do not believe that this is one of them. The > shortest and most reasonable route to release a stable 1.0 of Devuan is to > use udev for the present. THAT in and of itself trumps your concerns in my > opinion. I will admit that I find Jude's proposal intriguing - but it is > hardly ready for use. Eudev might make a good replacement, but udev is > still the best candidate in terms of people using it if you follow the > principle that "eyes make bugs shallow". > I thought it was already settled and decided by the VUA that Devuan Jessie will use udev. I agree with this stance, for the same reason as T.J. points out--udev is production-ready, whereas vdev is not. It's the pragmatic thing to do--I only have a handful of hours per week to work on vdev, so it makes no sense to hold up the release waiting for it. However, I think the plan is to offer vdev as a udev alternative in at least ascii, so users who want to try it out will be able to do so with minimal effort. Thanks, Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update (2015-05-03)
Hi James, On Thu, May 14, 2015 at 12:04 AM, James Powell wrote: > Thanks Jude. > > The Slackware package is delayed, but only due to the lack of a Slackware > style script. I might try to ask one of the Slackware team for assistance > when I resume work. However, the package is fairly much completed in terms > of installation points and directory setup. > Hey, that's pretty cool! First the AUR packages (from Jack Frost aka openfbt), now Slackware. I'm not a Slackware or Arch user, but please let me know if there's anything I can do to make packaging easier? I don't want to make things needlessly difficult :) -Jude > Sent from my Windows Phone > ------ > From: Jude Nelson > Sent: 5/13/2015 8:24 PM > To: dng@lists.dyne.org > Subject: [Dng] [dng] vdev status update (2015-05-03) > > Hey everyone, > > I have the latest news for vdev: > > * vdev now creates symlinks for: > -- /dev/v4l/by-path > -- /dev/disk/by-partuuid > -- /dev/disk/by-partlabel > > Thank you Scooby for helping me confirm this! > > * vdev now sets the proper ownership and permissions for: > -- /dev/mISDNtimer > -- /dev/mwave > -- /dev/parport[0-9] > -- /dev/printer > -- /dev/ppdev > -- /dev/lp[0-9] > -- /dev/irlpt[0-9] > -- /dev/sch[0-9] > -- /dev/pktcdvd[0-9] > -- /dev/qft[0-9] > -- /dev/zqft[0-9] > -- /dev/nqft[0-9] > -- /dev/nzqft[0-9] > -- /dev/rawqft[0-9] > -- /dev/nraqft[0-9] > -- /dev/rawctl > -- /dev/aoe > -- /dev/lirc[0-9] > -- /dev/legousbtower > -- /dev/sonypi > -- /dev/mmtimer > -- /dev/sgi_* > -- /dev/z90crypt > > * Didier Kryn has gotten vdevd and vdevfs to statically link and compile > with musl libc. I'm looking forward to merging his contributions :) > > * the build system has been refactored to use Makefiles more > appropriately: > -- every generated file gets written to a separate build/ directory > -- every generated file is created by a non-phony target (i.e. nothing > happens by side-effect) > -- global buildconf.mk for setting variables > Thanks to Didier again for the suggestion! > > * the initramfs hook conditionally pulls in iproute2, lvm, dmsetup, > blkid, etc. Moreover, vdev's helpers conditionally use these programs if > they are present. This means that vdev doesn't strictly depend on them > anymore, which is good if you're not using mapped devices or logical > volumes. Thanks to Anto for the suggestion! > > * the initramfs hook pulls in the correct GNU libc files now, so chown(1) > will work correctly in the initramfs. Thanks to Scooby, Isaac Dunham, Tom > H for their help! > > > [For Next Time] > > * The next immediate objective is to package vdevd for Devuan, to make > it easier to test (in particular, easier to get a working initramfs). I'm > currently dissecting udev's packaging and reading through Isaac's mdev > scripts to see what to expect and what we can recycle. I've never packaged > something this complex before. Thanks to Scooby, Anto, Tom H, and others > for all their help on getting me this far! > > * Symlinks and permissions for RAID devices (/dev/md[0-9] and friends). > I don't run a RAID myself, so I'll need to go set one up in QEMU. If > someone wants to test vdev with a RAID, let me know, and I'll try to write > a helper script to play around with sooner rather than later. > > * In some distros and configurations, a separate device manager (like > mdev) can populate just enough of /dev to mount root, but not try to set up > any symlinks. Vdevd must have a way for the admin to tell it to run helper > scripts for the device even if its device node was already created > (indicating that it has been set up), so the symlinks and permissions still > get set appropriately. Thanks to Scooby for reporting this! > > Thanks, > -Jude > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Systemd discussions at LinuxQuestions.
Hi James, On Wed, May 13, 2015 at 11:58 PM, James Powell wrote: > I agree T. J. > > The problem is too much "thinking" about problems, rather than offering a > clear solution other than scrapping the fore and replacing it entirely > seems to be the source of the problem. > > One argument I stand by adamantly is that while sysvinit was imperfect in > design, it left room to allow the tree to branch in various ways with the > applied tools. OpenRC is a prime example of taking sysvinit and expanding > upon it in a way that allows for diversity just like daemontools, bsd-style > scripting, and other service supervisors do brilliantly. Sysvinit doesn't > have to be the workhorse, but it can be the harness providing the standard > functions of startup and shutdown for the workhorse of your choosing. > > However few people are willing to step outside their boxes and look for > ways to improve systems without resulting to rampant progressivism with new > software than isn't even finished in it's goals. > > In the late 90s Dan Bernstein's daemontools could have ended the > overreliance on sysvinit, but few embraced it. > > Now we see the rush to "do" when something comes along to create a rift. > No ill will to anyone, but if anyone had have "done" years ago, there might > be less a need to "do" now. > It's not clear to me how much really needed doing in the first place. The people who actually needed djb's daemontools went ahead and used them. The people who actually needed to contain processes in cgroups did so, and they did so with vserver and openvz before cgroups existed. The people who actually wanted service socket activation used xinted. The people who actually needed to start services in parallel either hacked their init scripts to do so, or wrote Makefiles that started/stopped groups of services in parallel while enforcing inter-service dependencies as dependencies between targets. I think the sudden rush to Fix-All-The-Things we're seeing (the "rampant progressivism" as you call it) is part of human nature. I have this pet theory that people tend to progress through three stages of understanding when applying themselves to a new field: (1) they know little or nothing about it, and they know it. (2) they learn more than they thought there was to know about it, and (wrongly) believe that they know mostly everything about it. (3) they reach the field's state-of-the-art and see the boundary between what is known and unknown, and acquire the humility that comes from understanding that no matter how much they think they know, there's a lot more that they don't. At any given point, there are way more people in stage #1 than stage #2, and way more people in stage #2 than in stage #3. The people who are comfortable using the tools I mentioned above tend to be at stage #3 in the field of building and using UNIX-like operating systems. This is because in addition to knowing what tools are available, they know the trade-offs between them and how to select them to find the best solution to a particular problem. They also know when and when not to create new tools, and they know how to define their scope. There's no desire on their end to sacrifice flexibility for convenience--they've dealt with enough problems to appreciate that having lots of small interchangeable and composable tools is critical to being able to tackle a wide variety of them. Unfortunately, this doesn't do people in stages #1 and #2 any favors. The value proposition of systemd is that it automates a common set of stage #3 problem-solving strategies that a stage #1 or #2 user is likely to encounter, but without requiring the user to have a stage #3 level of understanding. I think it's the stage #2 people who appreciate this that become the loud-mouthed zealots we're all so fond of. They're the ones who want to Fix-All-The-Things--they know that there are some hard stage #3-level problems out there, but they mistakenly believe that they (or their favorite tool) will know how to fix them. It's not that they're Bad People (quite the opposite, they tend to be Concerned Citizens); the problem is that they know enough to act on the problems they see, but not enough to know that their solutions aren't always appropriate or desirable. As a result, enterprising developers who can capitalize on (or even create) the concerns of the stage #2 people tend to get their software adopted and stand to gain power, influence, and money from the community. When stage #3 people object (as you have), the stage #2 people crowd them out as "haters", "luddites", "elitists", or "trolls", and the stage #1 people tend to go along with the stage #2 people since they can't tell stage #2 and stage #3 people apart, and there are more stage #2 people. I see all the noise about systemd as just the latest instance of this phenomenon in my field. Just my $0.02. -Jude > > Sent from my Windows Phone > -- > From: T.J. Duchene > Sent
[Dng] [dng] vdev status update (2015-05-03)
Hey everyone, I have the latest news for vdev: * vdev now creates symlinks for: -- /dev/v4l/by-path -- /dev/disk/by-partuuid -- /dev/disk/by-partlabel Thank you Scooby for helping me confirm this! * vdev now sets the proper ownership and permissions for: -- /dev/mISDNtimer -- /dev/mwave -- /dev/parport[0-9] -- /dev/printer -- /dev/ppdev -- /dev/lp[0-9] -- /dev/irlpt[0-9] -- /dev/sch[0-9] -- /dev/pktcdvd[0-9] -- /dev/qft[0-9] -- /dev/zqft[0-9] -- /dev/nqft[0-9] -- /dev/nzqft[0-9] -- /dev/rawqft[0-9] -- /dev/nraqft[0-9] -- /dev/rawctl -- /dev/aoe -- /dev/lirc[0-9] -- /dev/legousbtower -- /dev/sonypi -- /dev/mmtimer -- /dev/sgi_* -- /dev/z90crypt * Didier Kryn has gotten vdevd and vdevfs to statically link and compile with musl libc. I'm looking forward to merging his contributions :) * the build system has been refactored to use Makefiles more appropriately: -- every generated file gets written to a separate build/ directory -- every generated file is created by a non-phony target (i.e. nothing happens by side-effect) -- global buildconf.mk for setting variables Thanks to Didier again for the suggestion! * the initramfs hook conditionally pulls in iproute2, lvm, dmsetup, blkid, etc. Moreover, vdev's helpers conditionally use these programs if they are present. This means that vdev doesn't strictly depend on them anymore, which is good if you're not using mapped devices or logical volumes. Thanks to Anto for the suggestion! * the initramfs hook pulls in the correct GNU libc files now, so chown(1) will work correctly in the initramfs. Thanks to Scooby, Isaac Dunham, Tom H for their help! [For Next Time] * The next immediate objective is to package vdevd for Devuan, to make it easier to test (in particular, easier to get a working initramfs). I'm currently dissecting udev's packaging and reading through Isaac's mdev scripts to see what to expect and what we can recycle. I've never packaged something this complex before. Thanks to Scooby, Anto, Tom H, and others for all their help on getting me this far! * Symlinks and permissions for RAID devices (/dev/md[0-9] and friends). I don't run a RAID myself, so I'll need to go set one up in QEMU. If someone wants to test vdev with a RAID, let me know, and I'll try to write a helper script to play around with sooner rather than later. * In some distros and configurations, a separate device manager (like mdev) can populate just enough of /dev to mount root, but not try to set up any symlinks. Vdevd must have a way for the admin to tell it to run helper scripts for the device even if its device node was already created (indicating that it has been set up), so the symlinks and permissions still get set appropriately. Thanks to Scooby for reporting this! Thanks, -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status updates
On Wed, May 13, 2015 at 7:42 AM, Jack L. Frost 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 its dependencies for Arch: > > https://aur.archlinux.org/packages/vdev-git > https://aur.archlinux.org/packages/fskit-git > https://aur.archlinux.org/packages/libpstat-git Hey, this is pretty cool! Thanks for taking the time to do this :D I'm working on Debian packages at the moment. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Which source version fo systemd are you stripping code from?
> Since I have time on my hands, I would like to give a try stripping > the bare minimum of necessary functions from systemd. I know the task > is complex. If I fail, it will not be the end of the universe. > > Which systemd source version are you using? I am assuming it should be > version: 215-17 from Debian Jessie. > > I'm basing libudev-compat on libudev 219. Also, some of vdev's helper programs (i.e. the ones that begin with "stat_") are derived from code in udev 219. It probably doesn't matter what version you go with unless you need a specific feature or want to avoid a specific bug. Why not just go with the latest? Stable releases of systemd are pretty frequent. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?
Hi Jaret, > It would probably help to have some ground rules on how Devuan handles > packages which provide systemd support. I know Devuan says "Nope!" when it > comes to anything that would introduce systemd/init system dependencies, > but does it ever get more elaborate than that? If it is already in a wiki > or README on git, I've missed it. > > I can think of two ways these dependencies would come up in packages that > would need to be addressed: > > * Configurable systemd support: > > All Devuan packages should be configured NOT to depend on systemd, > whenever possible. This prevents init-system creep. This doesn't stop one > from using systemd and a package that has potential systemd support (like > xfce); however, said package on Devuan would not get any of the additional > benefits from systemd, such as... um, binary logging? > > I would recommend against maintaining a separate, systemd-configured > repository; that would just be mainline Debian. > > I think the plan is to address needless dependencies and lock-in in a more general way, via the constitution ( https://git.devuan.org/devuan/devuan-project/wikis/DevuanConstitution). Sections 2.2 and 9.10 are meant to alleviate this problem--not just for systemd, but for all software package suites that get included. > > * Hard systemd requirements: > > I believe this is where gnome3 and similar software falls; the project has > a hard runtime and/or buildtime dependency on systemd. The only way to > offer these packages on a non-systemd Devuan is to patch out the systemd > from the source. Fortunately, FreeBSD already has to do this, right? Just > raid their patches. > +1 > > This can become a maintenance burden, which is why it is cool to have a > second option on how Devuan can handle these packages: *don't*. > > > > Now, this handling of systemd-dependent packages still means that systemd > can be offered, but only as an init. (An init system only be used to > initialize a system? What madness is this!) And the only way that systemd > will ever make it onto your system is with an explicit apt-get install > since no other packages depend on it. > > But IMHO, I think it would be wiser to offer uselessd instead of systemd: > > http://uselessd.darknedgy.net/ You may be interested to know that uselessd is effectively dead in the water. The original uselessd author has since given up ( https://forums.darknedgy.net/viewtopic.php?id=4963). Someone else seems to have taken over, but I haven't heard anything about its subsequent progress (last repository commit is January 6: https://bitbucket.org/Tarnyko/uselessd). > > > Thataway, our (e)udev offering would be less muddled. Also, hilarity. > Already working on it :) > > Besides, going with uselessd instead would make a systemd-ish Devuan > different than just Debian with poorer systemd integration. It would kinda > be like libav over ffmpeg; on this distro, systemd would just be considered > a "deprecated" version of uselessd (what with its text logs and lack of > gluttony against fellow software projects), even though both projects (in > both cases) are considered currently active. > > I'm personally not opposed to someone taking up maintenance of uselessd and packaging it in a way that it conforms to Devuan's constitution :) The problem is, we'd need to find someone with the time, skill, and willpower to do it. That person is not me. I barely have enough time to work on vdev as it is :( -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?
On Tue, May 5, 2015 at 1:41 PM, shraptor shraptor wrote: > But I guess there is no obstacle to for instance run vdev with systemd, > huh? > There shouldn't be. However, someone will have to write a .service file for it. -Jude > > On Tue, May 5, 2015 at 7:33 PM, Jaromil wrote: > >> >> dear Noel, >> >> I'm happy that you are back, we really miss DWN, but I'm also sorry to >> contradict you on this one. >> >> On Tue, 05 May 2015, Noel Torres wrote: >> > As a resume: If you want a systemd-free system, Devuan is your >> > distribution, and will always be. But if you want a system designed to >> > be unable to run systemd, please leave us. This is not the place for >> > such an anti-freedom POV. >> >> perhaps we could say it was to simplify the transition, but in operating >> on packages so far we have removed systemd and the possibility to run it >> on Devuan, which is now as far as that of running sysvinit on Debian for >> normal users. This is more of a consequence of how Debian imposed >> systemd than a deliberate choice from our side. I personally agree with >> your line about init-freedom, but less agree with the line of telling >> people this is not their place especially if they look for a >> systemd-free system for whatever reason they have. >> >> At the inception of Devuan we have analysed the tradeoff of keeping >> systemd optional and thought it was too much work in a direction we >> weren't interested: we recommend Debian as the system of choice for >> those wanting to have systemd crippl*cough*cough*manage their computers. >> >> As simple as this, the result is that there is no option to have systemd >> in Devuan now and the simpliest way to have it would be anyway to use >> Debian. I'm not sure it will be ever a priority to get systemd back as >> optional for Devuan. Perhaps init-freedom is really realized by a >> plurality of distributions and if there is a merit for Devan is still >> that of preserving this freedom by providing an OS that is open to every >> init system *but systemd* since the latter does exclude anyone else by >> an enormous network of dependencies. In the future we'll invest efforts >> in supporting sysvinit and more init systems our there (OpenRC, DMD >> etc.) thus we'll be a bit more "universal" than Debian. >> >> Again personally I think that is an arrogant move today for any OS to >> declare itself "universal" as init-freedom and more freedom in the >> future is really realized by a plurality of distributions, a lesson we >> learn from this fork perhaps. >> >> ciao >> >> >> >> ___ >> 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] About (k)dbus in LKML
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 for it. > > IMO from the collective discussion, kdbus doesn't seem to be really well > designed, fast, or reliable compared to traditional D-Bus and only has a > small if minimal gain over traditional D-Bus near negligible. In short, one > could wonder if this effort was a complete waste of time, or a convoluted > effort to introduce a proprietary IPC in the kernel that can only be used > by system so they can kill off netlink support in udev in favor of kdbus. > My pick is the latter as we all know how the systemd kabal thinks, and we > all can make an educated guess as to where Greg Kroah-Hartman's > true loyalties lie. > The D-Bus implementation you're using isn't really fast or reliable in the first place :P Linus's benchmarks suggest that the reason the D-Bus implementation is so slow is because it suffers performance-death-by-a-thousand-cuts. There are a bunch of needless malloc()s, copies, locks, etc. per call that aren't costly by themselves, but they add up. What remains to be seen is how a *well-written* userspace D-Bus performs, or even a D-Bus that uses memfds or page-spicing for large messages. Also, netlink isn't going anywhere. Linus does not break userspace, and other device managers (including vdev) and hotplug programs all rely on netlink to receive device events. > The native IPC for Linux has been reliable, though it's not exactly fast > by all means, but in terms of working, it works, does it's job well, and > has a proven track record. > Shared memory is pretty damn fast--close to as fast as theoretically possible. Once set up, there is literally zero overhead (no context swtiches, no MMU reprogramming, no TLB flushes, etc.) since the pages of RAM are mapped in both the producers and consumer's page tables. Also, according to Kay Sievers himself, the humble pipe is faster than kdbus for messages smaller than 32K on an x86_64 system. This is even without vmsplice(2). All it needs are new protocols worked in to help it out by introducing new > methods of using the IPC while maintaining legacy pathways. Oddly enough > another IPC, Plumper from 9P has been available for some time now, but has > never been attempted at a port. > > IIRC 9P gets used today in libvirt and qemu for sharing folders. Also, it's "plumber" :) > I, and possibly others, can only hope Linus actually and ultimately says > "no" to kdbus and sees the purpose behind kdbus not being a successor > to D-Bus but a proprietary IPC that can be used by system for udev, and > only for that purpose. > It doesn't really matter to us whether or not kdbus gets accepted. Obviously, Linus won't accept it if he feels that it'll be a maintenance hassle, since once it's in the kernel, its interface is not allowed to change. Gazing into my cracked and cloudy crystal ball, what'll probably happen is the policy and marshaling logic will be kept in userspace, and the kernel will get a patch that adds the minimal set of primitives needed to address the actual shortcomings with the D-Bus design (but not problems with the current implementation). This includes memfd and file descriptor sealing today. Maybe down the road send(2) and write(2) will get a new flag to atomically check if the receiver is still connected and abort if not, and maybe read(2) and recv(2) will an option to atomically check the sender's credentials before receiving data. I get the impression from the discussion that these are all the D-Bus developers really need the kernel to do for them, but I could be wrong. > > Though should it become part of the mainline, we all know Lennart will > waste no time in dropping netlink support in udev just to get his way. > He's already said as much. > > If that becomes the case, eudev can hopefully make an effort to keep > netlink alive in a separate tree while backporting code in from > system-udev, but who knows how long that will last. However, Linus did make > a stern warning that if they did anything to break the userspace (and > breaking netlink in udev would do just that), they could have any number of > penalties from more developers from systemd banned from kernel > developments, to as well as possibly code excised from the kernel. > No doubt that eudev will continue regardless of systemd-udev. Plus, we'll have vdev soon enough too (which addresses problems that neither udev nor eudev handle). -Jude Date: Tue, 28 Apr 2015 23:00:55 +1000 > From: ad_u...@runbox.com > To: dng@lists.dyne.org > Subject: [Dng] About (k)dbus in LKML > > > 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 > ful
Re: [Dng] [dng] vdev status updates
On Wed, Apr 29, 2015 at 5:46 PM, Didier Kryn 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. This gets a little >>> complicated now that Linux has been "improved" by having /sbin >>> and /bin be symlinks to /usr/bin, which might not be mounted in early >>> boot, but aside from that, I think once you have possession of /bin >>> and /sbin, then assuming that /etc is not a mountpoint, I think most >>> other stuff can be delayed til the real init, always assuming that it's >>> easier to put stuff in the on-disk init than in initramfs. >>> >> Is that Linux that has been "improved" by turning /sbin and /bin into >> symlinks? Or is it Debian? Or the systemd collection of distros? >> >> -- hendrik >> >> Here's the story I read about /usr, and it sounds like the truth: > > When people built the first Unix machine, the first disk, containing > /bin went full but they needed to add more files to /bin . They decided to > put them on the second disk which contained user data and was therefore > mounted at /usr. Hence /usr/bin. It was a technical workaround for > disk-size limitation. > > Nowadays some distros got rid of /usr but still make it a symlink to / > because of softwares that rely on it. If Debian is now doing sort of the > opposite, it must be some trick. I've nothing against; as long as you keep > /usr, use it at your will; it's all about convenience tricks. Even these days, in some UNIXes (OpenBSD comes to mind), /bin and /sbin differ from /usr/bin and /usr/sbin in that they only contain statically-linked programs. This is useful for doing things like upgrading the rest of the system, so you have a way to recover from catastrophic errors (like /usr or /lib becoming unusable). -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status updates
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 non-static busybox?
>
Not sure; will find out and let you know if it makes a difference.
>
> A couple shots in the dark:
> -check that you're using properly spelled usernames/groups, and that
> $IFS isn't something weird.
>
Did the former, but not yet the latter.
> -double-check that you have a non-empty passwd/groups file, containing
> the same users/groups and world-readable.
>
Does it have to be world-readable even if the chown(2) happens from a
process with uid=0? I verified that they're non-empty, and verified that I
was unable to (as root) use busybox chown from the initramfs shell.
>
> To debug it:
> -Add ltrace (with dependencies) and a *non-static* busybox to your
> initramfs and try running
> ltrace busybox chown USER:GROUP FILE
>
> This shows you the functions that are called, so you can check if they
> return success.
>
I will add ltrace (and ldd) to my initramfs and try this out :)
>
> > * As Anto's experience shows, getting a working initramfs is tedious to
> do
> > and easy to get wrong. This is not only because there are multiple init
> > systems that vdevd will need to work with (e.g. sysv-rc, file-rc, openrc,
> > etc.), but also init scripts and initramfs scripts that come from
> packages
> > that depend on udev are (unsurprisingly) tightly coupled to udev. This
> > makes it difficult to install vdevd on a running Debian system without
> > removing udev (which is in itself undesirable, since it will take a large
> > swath of packages out with it), since I have to pretty much fork both
> sets
> > of scripts and try to mash them up into a custom initramfs without
> altering
> > /usr/share/initramfs-tools. This is effectively what my (extremely
> kludgy)
> > initramfs Makefile does.
>
> Check what I did with mdev (in hooks/ directory of github.com/idunham/mdev
> );
> I did *not* find that initramfs-tools was at all tightly coupled with udev,
> to the point that dropping the correct scripts into
> /usr/share/initramfs-tools and convincing dpkg that it didn't need udev
> was quite adequate.
Thanks for the link! It's good to get feedback from someone who's packaged
a device manager before :)
Regarding setting up the initramfs, my experience is a bit more involved.
I had to patch initramfs-tool's init script so it wouldn't try to mount
devtmpfs, and wouldn't try to pull in udev config files or migrate udev's
info from /run. This is because to the best of my knowledge, the only
reason devtmpfs needs to be mounted at all is because udev no longer
creates device files on its own (it only changes ownership and adds
symlinks). However, using devtmpfs will be problematic for libudev-compat,
which relies on inotify(2) to detect device changes (i.e. a device file
that shows up in devtmpfs from the kernel does not generate an inotify
event).
> However, you *will* need to take care that there is only one script moving
> /dev to the target filesystem, or you will almost certainly get a failed
> boot.
>
> Also, I cannot comment on whether LVM et al. are tightly coupled with udev.
>
I'm still looking into this, but so far it seems that the dmsetup and
cryptsetup hooks both pull udev-specific files in for their own
consumption. Also, the initramfs functions library, as well as the nfs,
cryptoroot, and lvm2 local-* scripts explicitly depend on udevadm to run
what is basically a poll loop to wait for udev to find the relevant
devices. It's not clear to me yet whether or not this is a consequence of
udev daemonizing before it finishes processing coldplugged devices
(introducing the need to run "udevadm settle" over and over), or a
consequence of some interplay between the udev-isms that have worked their
way into lvm and dmsetup. Either way, some refactoring and encapsulation
may be in order.
>
> > What I'm going to make my next priority is making a .deb for vdevd that
> > automatically generates the initramfs in a "safe" manner. I'd need to do
> > this in a way that disables, but does not remove the udev scripts. This
> is
> > easier said than done due to tight integration with udev, but I don't
> think
> > it's insurmountable.
> >
> > What we'll need is a well-written .deb post-install script that:
> > * sets up config files needed to generate persistent device names
>
> Install config files, marked as such.
>
It's more involved than that--the /etc/vdev/ifnames.conf file needs to be
generated from the host's network interfaces, for example (like the
/etc/udev/rules.d directory). But obviously surmountable :)
> > * installs our versions of the initramfs scripts for things like lvm,
> > suspend/resume, etc.
> > * disables the udev versions, but does not uninstall them
>
> It wi
Re: [Dng] A systemd-free Valentine image: Was: Re: ... devuan image
Hi Svante, On Tue, Apr 28, 2015 at 2:53 AM, Svante Signell wrote: > On Mon, 2015-04-27 at 13:49 -0400, Haines Brown wrote: > > I'm running debian wheezy on a 32-bit machine. Given the appearance of > > Jessie last Saturday, it seemed time to try out devuan. Because I don't > > know what to do with the qcow2 files of the current builds, I went back > > to the Valentine ISO. > > Just FYI: I have an almost systemd-free Valentine image by now in > qemu :) > > # cat /etc/apt/preferences.d/systemd > Package: systemd > Pin: release o=Debian > Pin-Priority: -1 > > # cat /etc/apt/sources.list > deb http://packages.devuan.org/merged ascii main contrib non-free > deb http://packages.devuan.org/merged jessie main contrib non-free > deb http://angband.pl/debian nosystemd main > (deb-src entries omitted) > > # dpkg -l xfce4 > ii xfce4 4.10.1 all Meta-package for the Xfce > > # dpkg -l |grep 215-17 > ii libgudev-1.0-0:i386 215-17 > i386 GObject-based wrapper library for libudev > ii libudev1:i386215-17 > i386 libudev shared library > ii udev 215-17 > i386 /dev/ and hotplug management daemon > > The last two will be replaced by vdev when Jude is finished :) > > The only question right now is: > # apt-get remove libgudev-1.0 > The following packages will be REMOVED: > colord gstreamer1.0-plugins-good libgudev-1.0-0 quodlibet > task-xfce-desktop thunar thunar-archive-plugin thunar-media-tags-plugin > thunar-volman udisks2 upower xfburn xfce4 xfce4-goodies > xfce4-places-plugin xfce4-power-manager > 0 upgraded, 0 newly installed, 16 to remove and 0 not upgraded. > After this operation, 16.1 MB disk space will be freed. > Do you want to continue? [Y/n] n > > Jude? > Getting there... I'm hopeful that libgudev-1.0 will "just build" against libudev-compat, since libudev-compat strives to be ABI-compatible with libudev. Also, please see https://lists.dyne.org/lurker/message/20150429.000302.88924987.en.html :) -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] [dng] vdev status updates
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 volumes has been added. vdevd will create all /dev/VG/LV links, /dev/mapper/ symlinks, and /dev/disk/by-id/lvm-pv-uuid-XXX links. I have successfully used vdev to boot the Devuan QEMU image from April 24--the one with root and swap on LVM. * Support for /dev/input/by-id has been added, but needs testing. In particular, I'm not sure what kinds of devices other than USB input devices go here. I think maybe old serial and MIDI joysticks might go here, but I do not have any to test on (let alone a computer with a COM or MIDI port). If you're not seeing a device symlink that should be here, please let me know. * vdevd's helper scripts now set device ownership and permissions correctly, instead of defaulting to root.root and 0600. [Development] * Under the hood, I've refactored vdev's subr.sh shell library, such that each vdev-specific method is appropriately prefixed (with "vdev_"). * With Scooby's help, I'm getting a list going for package dependencies going for vdevd's helper scripts, to make it easier to package vdev. The list is in pkg/dependencies.txt. [Integration Testing] * Scooby, Tom H, and Anto have been hitting vdev hard, and Scooby has been able to boot to desktop with vdevd (but first by writing an xorg.conf). Their reports have been instrumental in closing the functionality gap between vdevd and udevd. Thank you to everyone who participated! * On initramfs testing: Anto has helped me uncover some problems with my very early, very hack-ish makefile for generating initramfs images. I think the latest commit should fix at least some of the problems (but not all of them), but I have not had time to look into whether or not the process works for file-rc. [TODO] * I still need to figure out how to generate /dev/disk/by-partuuid and /dev/v4l/by-path, and possibly others. * 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 see [Help Wanted]. * libudev-compat. No ETA on this, but I'm going to try to make some progress on it next week. Fortunately, a lot of programs can be compiled without libudev, so it's not as high of a priority right now. [Help Wanted] * Astute readers may notice that one method in vdev/helpers/LINUX/subr.sh is called vdev_chown. This is because for whatever reason, Debian's busybox chown does not accept usernames and group names when running in the initramfs. I have tried: -- copying over /etc/passwd, /etc/passwd-, /etc/group, /etc/group- to the initramfs. -- using GNU chown. -- strace-ing both GNU chown and busybox to confirm that they access /etc/passwd and /etc/group. It does not appear to be specific to busybox chown; busybox ls doesn't resolve UIDs and GIDs to usernames and groups either, for example. Anyone familiar with busybox on this list want to weigh in? The vdev_chown shell method is clearly a hack and I'd love to be rid of it, but until I figure out why busybox chown is misbehaving, it's necessary to set device file ownership in the initramfs (i.e. I think it's less evil than using opaque UIDs and GIDs in vdevd's helper scripts). * As Anto's experience shows, getting a working initramfs is tedious to do and easy to get wrong. This is not only because there are multiple init systems that vdevd will need to work with (e.g. sysv-rc, file-rc, openrc, etc.), but also init scripts and initramfs scripts that come from packages that depend on udev are (unsurprisingly) tightly coupled to udev. This makes it difficult to install vdevd on a running Debian system without removing udev (which is in itself undesirable, since it will take a large swath of packages out with it), since I have to pretty much fork both sets of scripts and try to mash them up into a custom initramfs without altering /usr/share/initramfs-tools. This is effectively what my (extremely kludgy) initramfs Makefile does. What I'm going to make my next priority is making a .deb for vdevd that automatically generates the initramfs in a "safe" manner. I'd need to do this in a way that disables, but does not remove the udev scripts. This is easier said than done due to tight integration with udev, but I don't think it's insurmountable. What we'll need is a well-written .deb post-install script that: * sets up config files needed to generate persistent device names * installs our versions of the initramfs scripts for things like lvm, suspend/resume, etc. * disables the udev versions, but does not uninstall them * safely builds the initramfs from our scripts. * (long-term) does the above in a way that is agnostic to the device manager, since there are real-world use-cases for
Re: [Dng] Fwd: [dng] vdev status update
Hi Anto, > > I am confused now about your comment that we can "install any/all device > managers and pick one that gets started at boot-time via the alternatives > system". > > I initially thought that vdev requires udev or any other device managers > to work. But since you added the command to disable udev on > https://github.com/jcnelson/vdev/blob/master/INSTALL.md, I followed that > and I got the impression that vdev will replace udev. That is not my intention when it comes to packaging vdev. Devuan is all about preserving the user's freedom to run the software they want, so the ultimate goal is to make it possible for multiple different device managers to coexist. However, this is somewhat difficult to do this right now, especially when it comes to testing vdev. That's why the INSTALL document and the installation scripts attempt to disable udev. > > However, either any of those has no affect at the moment as vdev's init > still fails to mount the root file system, so it does not touch /sbin/init > yet. > Yes. Perhaps it is better to start with vdev for amd64 first. I think that > would speed up differentiating Devuan from Debian, so that will not be only > for me. Probably not for the initial release of Devuan, but later on after > vdev is stable. > > In regards to the deb package of vdev, I have to test it on a real test PC > to be safe, instead of on my "current test machine" which is the PC that I > am using for writing this email. > Once I have a deb ready, it will automatically generate the initramfs and do something more sane with the initscripts than the Makefile. Thanks, Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Boot sequence: was vdev status update
Hi Steve, On Sat, Apr 18, 2015 at 12:02 PM, Steve Litt wrote: > On Sat, 18 Apr 2015 00:08:54 -0400 > Jude Nelson wrote: > > > > The init program in example/initramfs/init goes into > > /usr/share/initramfs-tools/init, not /sbin/init :) The initramfs's > > init script is fundamentally different from the init program > > in /sbin. That also explains your inability to reboot. > > > > Basically, when the bootloader loads the initramfs, the kernel mounts > > it as the root device and starts /sbin/init. /sbin/init, in turn, > > runs the script at /init (which you can see from the initramfs shell > > with "ls /"), which is copied into the initramfs image by the > > update-initramfs and mkinitramfs tools from the > > file /usr/share/initramfs-tools/init. > I had misspoken here--as Laurent and Isaac pointed out, the kernel will load /init as PID 1 in the initramfs. This script in turn exec's the "real" init process from the root device (/sbin/init). I'm sorry if I caused confusion--I will be more careful in the future to fact-check myself. Thanks, -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Fwd: [dng] vdev status update
Hi Anto, On Sat, Apr 18, 2015 at 2:19 PM, Anto wrote: > On 18/04/15 19:46, Anto wrote: > >> >> Hello Jude, >> >> I have tried a lot other combinations but the problem remains, that is >> the init fails to mount the root partition. >> >> I am not sure why as I can manually mount any disks that are available on >> /dev at (initramfs) prompt. I had to do that in order to be able to copy >> any logs into the disks or edit /etc/runlevel.conf to restore it. I also >> tried to add kernel boot options "root=/dev/sda1 init=/sbin/init", but that >> still does not help. >> >> The first error on initramfs.debug is "/init: line 1: mount_top: not >> found". Please have a look on that initramfs.debug and its corresponding >> dmesg output on >> https://minifora.eu/public/devuan/vdev/initramfs_debug_logs.tar.gz. >> >> Cheers, >> >> Anto >> >> > Hello Jude, > > Sorry for keep sending emails instead of sending them at once. I just > thought it will be good to have comparison of the logs with the successful > boot using udev. Please have a look on same set of the logs with udev on > https://minifora.eu/public/devuan/vdev/udev_initramfs_debug_logs.tar.gz. No worries :) I'm sorry I didn't get a chance to look at this today (I've been out of town all day). I'm going to try again tomorrow. Would it be easier for you if I just went ahead and created an amd64 deb for vdev? I would have to make it conflict with udev for now(*) since it would need to prevent udev from running, but it seems like this is acceptable for your current test machine. Thanks, Jude (*) The tentative plan for the future would be to let you install any/all device managers and pick the one that gets started at boot-time via the alternatives system. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Fwd: [dng] vdev status update
Hi Anto, [snip] > 1. compile and install vdev > 2. copy vdev's initrd into /boot > 3. rename /sbin/init to /sbin/init.novdev 4. copy vdev's init file into /sbin > The init program in example/initramfs/init goes into /usr/share/initramfs-tools/init, not /sbin/init :) The initramfs's init script is fundamentally different from the init program in /sbin. That also explains your inability to reboot. Basically, when the bootloader loads the initramfs, the kernel mounts it as the root device and starts /sbin/init. /sbin/init, in turn, runs the script at /init (which you can see from the initramfs shell with "ls /"), which is copied into the initramfs image by the update-initramfs and mkinitramfs tools from the file /usr/share/initramfs-tools/init. > 5. manually set the vdev's initrd and init.vdev in grub.cfg > 6. manually add /etc/init.d/vdev into runlevel.conf (and keep > /etc/init.d/udev) > first, I tried to put vdev before udev, then the other way around > 7. reboot my PC using vdev's initrd and init > > There are some progress on the boot messages, but I still ended up on > (initramfs) prompt. As before, I can only use my keyboard using kernel > 3.2.0, so I could capture the vdev_debugging that you asked before. Please > download that from > https://minifora.eu/public/devuan/vdev/vdev_debug_logs.tar.gz. That file > also contain the copy of /var/log/messages, but I just took the messages > since I started to keep rebooting my PC. > > I think something still do not work properly on the vdev's init as I got > message saying "/sbin/init: 30: .: Can't open /conf/arch.conf" at boot and > when I did reboot as below. > > root@hp8530w:~# reboot > > Broadcast message from root@hp8530w (pts/1) (Fri Apr 17 18:28:56 2015): > > The system is going down for reboot NOW! > Loading, please wait... > mount: sysfs already mounted or /sys busy > mount: according to mtab, sysfs is already mounted on /sys > mount: proc already mounted > /sbin/init: 30: .: Can't open /conf/arch.conf > root@hp8530w:~# > root@hp8530w:~# reboot > WARNING: could not determine runlevel - doing soft reboot > (it's better to use shutdown instead of reboot from the command line) > Loading, please wait... > mkdir: cannot create directory `/var/lock': File exists > mount: sysfs already mounted or /sys busy > mount: according to mtab, sysfs is already mounted on /sys > mount: proc already mounted > /sbin/init: 30: .: Can't open /conf/arch.conf > root@hp8530w:~# > > I am still using file-rc instead of sysv-rc, but I didn't clean up > /etc/rc?.d directories. I tried to use sysv-rc, but my mouse and keyboard > are not being detected when using kernel 3.18.11. They are only being > detected on kernel 3.2.0 from wheezy repository. I think there is something > wrong with my kernel config but I will investigate that later. > Not sure yet what could be the cause of your keyboard and mouse not working. Let's see what happens after you fix steps 3 and 4--it could be a side-effect of the init program being broken, since the init program should also run the console setup scripts. Thanks, Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Wana give a try to vdev
Hi Didier,
[Snip]
> Hello Jude.
>
> Here is a brief summary of what I did up to now. The goal was to
> install a minimal rootfs in flash memory of an embeded Powerpc (MVME3100)
> to use as a sandbox.
>
> 1) I compiled a kernel with the following boot parameters:
> console=ttyS0,9600 root=/dev/mtdblock1 rootfstype=jffs2
>
> 2) The filesystem contains busybox-1.20.2 statically linked with musl,
> which I had done a while ago.
>
> 3) vdevd:
>
> I first tried to compile vdev natively on Debian Wheezy, but could not
> link it statically as I wanted. This is actually a classical problem with
> glibc everytime network functions are used. Actually the offending
> functions are getpwnam_r() and the like. I guess this is related with NIS
> compatibility built in the glibc.
The functions that call getpwnam_r() and getgrnam_r() in libvdev are only
used by vdevfs. It looks like this is going to be the case for the
foreseeable future. I just pushed code that moves them into vdevfs, so you
shouldn't see those errors again when statically linking with glibc.
Thanks for trying that out!
> I decided to link against musl libc. To save time I just downloaded a
> ready-made image of sabotage-linux for powerpc and compiled vdev in a
> sabotage chroot.
>
Good to know! I hadn't tried it with musl yet, but I'm glad to hear that
it works with it.
>
> I have now my minimal OS working. init is a little script doing the
> necessary mounts, including /dev on tmpfs and creating a few device files
> (console, ttyS0, null, zero). The script starts an interactive session and
> I could try to run vdevd by hand:
>
> / # vdevd /dev
> 00487:268746168: [ vdev.c:0425] vdev_init: ERROR:
> vdev_config_load('(null)') rc = -14
> 00487:268746168: [ main.c:0042] main: ERROR: vdev_init rc = -14
> / #
>
> AFIU, I am only missing a config file... :-)
Yup, missing a config file :)
If you run "make -C example" on the host, the Makefile will generate all
the host-tailored vdev config files you'll need (such as persistent
interface naming rules). They will be generated in example/build/etc/vdev
(which can just be copied into /etc).
Once you have your config files generated, you'll need to add "-c
/path/to/config/file" as an argument. I just pushed code to vdevd that
makes it look in /etc/vdev/vdevd.conf, if "-c" is not given (and if
/etc/vdev/vdevd.conf doesn't exist, vdevd should fail with ENOENT instead
of EFAULT).
Also, if you want more verbose debugging output from vdevd, you can pass
"-v" or "-v2" :)
Thank you for giving vdev a try, despite it's pre-alpha-ness :)
-Jude
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Fwd: [dng] vdev status update
Hi Anto, I push code to both github and git.devuan.org. Either one works :) Thanks, -Jude On Fri, Apr 17, 2015 at 9:40 AM, Anto wrote: > On 17/04/15 06:00, Jude Nelson wrote: > >> Hi Anto, >> >> I just committed preliminary support for using vdevd with devtmpfs. >> vdevd should automatically detect whether or not devtmpfs is mounted on >> /dev, and nevertheless run device setup scripts (by using its own device >> metadata tree in /dev/vdev/ to see whether or not the device was actually >> processed). >> >> NB for developers: this problem isn't specific to Linux--I expect to >> encounter it with FreeBSD as well, since it has a full-blown in-kernel >> devfs. vdevd will keep track of "OS quirks" in the future--one of which is >> the "Device Already Exists" quirk, whereby vdevd simply expects the OS to >> provide the device file (regardless of the mechanism). The Linux-specific >> vdevd back-end now checks to see if vdevd will create files on a devtmpfs >> filesystem, and enables that quirk if so. >> >> Funny, undocumented (!!) discovery: the devtmpfs filesystem type (see >> statfs(2)) is the same (!!) as the tmpfs filesystem type, despite being a >> fundamentally different filesystem. I'm surprised that this wasn't caught >> during the devtmpfs code review--guess I'll have to file a bug report. >> Anyway, if you find yourself wondering why vdev has to detect devtmpfs by >> parsing /proc/mounts and verifying that the realpath of the mountpoint is >> the same as or is a subdirectory of a devtmpfs mountpoint, that's why--we >> (currently) can't rely on the f_fsid in statfs(2) or statvfs(2). >> >> Thanks, >> Jude >> >> > Hello Jude, > > Before I start pulling your latest commit, could you please let me know > from which source should I pull that? Should it be from > https://git.devuan.org/pkgs-utopia-substitution/vdev or > https://github.com/jcnelson/vdev? So far I have been using the one on > github.com. > > Cheers, > > Anto > > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Fwd: [dng] vdev status update
Hi Anto, I just committed preliminary support for using vdevd with devtmpfs. vdevd should automatically detect whether or not devtmpfs is mounted on /dev, and nevertheless run device setup scripts (by using its own device metadata tree in /dev/vdev/ to see whether or not the device was actually processed). NB for developers: this problem isn't specific to Linux--I expect to encounter it with FreeBSD as well, since it has a full-blown in-kernel devfs. vdevd will keep track of "OS quirks" in the future--one of which is the "Device Already Exists" quirk, whereby vdevd simply expects the OS to provide the device file (regardless of the mechanism). The Linux-specific vdevd back-end now checks to see if vdevd will create files on a devtmpfs filesystem, and enables that quirk if so. Funny, undocumented (!!) discovery: the devtmpfs filesystem type (see statfs(2)) is the same (!!) as the tmpfs filesystem type, despite being a fundamentally different filesystem. I'm surprised that this wasn't caught during the devtmpfs code review--guess I'll have to file a bug report. Anyway, if you find yourself wondering why vdev has to detect devtmpfs by parsing /proc/mounts and verifying that the realpath of the mountpoint is the same as or is a subdirectory of a devtmpfs mountpoint, that's why--we (currently) can't rely on the f_fsid in statfs(2) or statvfs(2). Thanks, Jude On Thu, Apr 16, 2015 at 8:28 PM, Jude Nelson wrote: > Hi Anto, > > [snip] > >> I am not really sure if I understood what you explained. I don't think I >> have devtmpfs on my PC when I use the working initrd. The one mounted on >> /dev with the type of devtmpfs is udev. Here are the output of mount and >> the content of my fstab. >> >> root@hp8530w:~# uname -a >> Linux hp8530w 3.18.11-1v1-hp8530w #1 SMP Wed Apr 15 00:49:22 CEST 2015 >> x86_64 GNU/Linux >> root@hp8530w:~# >> root@hp8530w:~# mount >> sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) >> proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) >> udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_ >> inodes=492536,mode=755) >> devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime, >> gid=5,mode=620,ptmxmode=000) >> tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime, >> size=401084k,mode=755) >> /dev/disk/by-uuid/c0e1e620-5636-48f2-90dd-4d246d58b815 on / type ext4 >> (rw,relatime,errors=remount-ro,data=ordered) >> tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec, >> relatime,size=5120k) >> tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec, >> relatime,size=1641020k) >> fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) >> /dev/sda2 on /home type ext4 (rw,relatime,data=ordered) >> root@hp8530w:~# >> > > You have devtmpfs mounted. It's this line here: > > > udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_ > inodes=492536,mode=755) > > If you run "mount" while in the initramfs, you might see devtmpfs as > well. If so, then please make sure that you're using vdev's initramfs > "init" script in example/initramfs/init, instead of the one in > /usr/share/initramfs-tools/init. Vdev's init does not mount devtmpfs, but > initramfs-tool's init does. Devtmpfs cannot be mounted on /dev while vdev > is running (but I'll fix this soon). > > >> root@hp8530w:~# cat /etc/fstab >> # /etc/fstab: static file system information. >> # >> # Use 'blkid' to print the universally unique identifier for a >> # device; this may be used with UUID= as a more robust way to name devices >> # that works even if disks are added and removed. See fstab(5). >> # >> # >> # / was on /dev/sda1 during installation >> UUID=c0e1e620-5636-48f2-90dd-4d246d58b815 / ext4 >> errors=remount-ro 0 1 >> # /home was on /dev/sda2 during installation >> UUID=5be7af77-0d10-4685-989f-1004b1eabec8 /home ext4 defaults >> 0 2 >> # swap was on /dev/sda3 during installation >> UUID=3a37a27d-84cc-4d06-9920-5419bb4ccbae noneswap sw >> 0 0 >> # /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 >> /dev/cdrom1/media/cdrom0 udf,iso9660 user,noauto 0 0 >> # /dev/cdrom/media/cdrom0 udf,iso9660 user,noauto 0 0 >> root@hp8530w:~# > > > This is more evidence to me that the reason you got dropped into a shell > in the initramfs was because vdev saw the /dev/sd* device files from > devtmpfs, and (incorrectly) thought that they had already been processed > and thus didn't go on to generate > /de
Re: [Dng] Fwd: [dng] vdev status update
Hi Anto, Sorry for the late reply; I had been super busy with work over the last 24 hours. On Wed, Apr 15, 2015 at 2:43 PM, Anto wrote: > On 15/04/15 05:20, Jude Nelson wrote: > >> Hi Anto, >> >> >> Don't you want to know my setup? >> >> Yes, eventually :)  However, I don't want to waste your time either, at >> least until I am more confident that the vdev installation process works >> correctly. >>  >> >> Maybe there are some packages required by your vdev, but I don't >> have them installed on my PC. Or maybe the kernel 3.18.10 that I >> use require different treatment, so I need to use different kernel >> version to test your vdev. I think knowing that could help you >> troubleshoot the problem. I am really not sure the requirements to >> properly test your vdev at this stage. So perhaps having the same >> setup as your development environment could avoid any unnecessary >> issues. >> >> >> Well, there is one thing, if you're not too busy and it's not too >> inconvenient for you. Vdev logs its early boot messages to >> /run/vdev/vdevd.boot.log. If you could capture that file and send it to >> me, that would not only help me understand your setup, but also why vdev is >> misbehaving. >> >> Better yet, from the initramfs shell, if you could run "vdevd -v2 -f -c >> /etc/vdev/vdevd.conf --once /dev > /tmp/vdev-debugging.log" and send me the >> contents of /tmp/vdev-debugging.log, that will not only populate /dev >> (assuming vdevd works correctly on that invocation), but also generate a >> lot of extra debugging information in /tmp/vdev-debugging.log that would >> help me diagnose the problem. >> >> No worries if you're too busy or have better things to do, though :) >> >> Thanks again, >> Jude >> > > Hello Jude, > > Let's just say that I am doing this egoistically all for myself. :) So I > will devote my time to test your vdev as much as I can. > > Unfortunately, I cannot get the debugging log that you are after. Using > kernel 3.18.10 and 3.18.11, the keyboard was not being detected after it > got to the (initramfs) prompt, so I could not type anything. I managed to > execute the debugging command using kernel 3.2.0, but it didn't seem to > write the log to the /tmp directory. I think that is due the disk was not > detected. I could only capture the last messages using the camera of my old > mobile phone, so the quality is not good. Please have a look on > https://minifora.eu/public/devuan/vdev/vdev_debugging_15Apr15_3.jpg. > Thanks for sending me the picture :) The "rc = -17" error code means that the device exists (i.e. it's -EEXIST). If you look in /dev from the initramfs, you should see a bunch of device files. The "rc = -2" at the end is a minor bug--vdevd didn't create /dev/pts/ptmx, so it couldn't look up any metadata under /dev/vdev for it (i.e. rc == -2 is -ENOENT). That by itself shouldn't prevent root from mounting, though. Do you have devtmpfs mounted on /dev? That could be the reason it doesn't boot. At this time, if a device file exists that vdevd did not create, vdevd won't run any helper scripts for it when it processes it. If your root partition device file exists (e.g. /dev/sda1) since e.g. devtmpfs created it, and your /etc/fstab identifies your root device partition using a persistent path (e.g. /dev/disk/by-uuid/... or the like), vdevd won't generate the persistent path, since that's done by the helper scripts for /dev/sda1. As such, the script routines that parse /etc/fstab won't find the root device, and the initramfs init will abort and drop you into a shell. For those who don't know, devtmpfs is basically a no-frills devfs that modern udev now requires to be mounted to work correctly (i.e. devtmpfs makes the device files these days, not udev). vdevd is currently not compatible with devtmpfs, since it expects to create all the device files itself. I'll update the Linux port to check of devtmpfs is mounted before running, so vdevd will still run the helper scripts even if devtmpfs created the device files already. > I am not sure if this would be relevant. I am using file-rc instead of > sysv-rc, so I didn't actually have any /etc/rc?.d directories. After the > installation of the "example", /etc/rcS.d directory and S02vdev link under > it got created. It could possibly be a problem later on, but I think I will > worry about that (add it into /etc/runlevel.conf) after the boot process > can reach it. > That is relevant! I had assumed in the Makefile that the user is using sysv-rc,
Re: [Dng] Fwd: [dng] vdev status update
Hi Anto, > > Don't you want to know my setup? Yes, eventually :) However, I don't want to waste your time either, at least until I am more confident that the vdev installation process works correctly. > Maybe there are some packages required by your vdev, but I don't have them > installed on my PC. Or maybe the kernel 3.18.10 that I use require > different treatment, so I need to use different kernel version to test your > vdev. I think knowing that could help you troubleshoot the problem. I am > really not sure the requirements to properly test your vdev at this stage. > So perhaps having the same setup as your development environment could > avoid any unnecessary issues. > Well, there is one thing, if you're not too busy and it's not too inconvenient for you. Vdev logs its early boot messages to /run/vdev/vdevd.boot.log. If you could capture that file and send it to me, that would not only help me understand your setup, but also why vdev is misbehaving. Better yet, from the initramfs shell, if you could run "vdevd -v2 -f -c /etc/vdev/vdevd.conf --once /dev > /tmp/vdev-debugging.log" and send me the contents of /tmp/vdev-debugging.log, that will not only populate /dev (assuming vdevd works correctly on that invocation), but also generate a lot of extra debugging information in /tmp/vdev-debugging.log that would help me diagnose the problem. No worries if you're too busy or have better things to do, though :) Thanks again, Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Fwd: [dng] vdev status update
Hey Anto, On Tue, Apr 14, 2015 at 3:38 PM, Anto wrote: > On 14/04/15 21:18, Anto wrote: > >> >> Hello Jude, >> >> I have just done the following: >> >> - remove /etc/vdev >> - |git pull https://github.com/jcnelson/vdev|- remove /etc/vdev >> - make clean >> - compile and install libvdev, vdevd and example (step 1) >> - for step 2, I need to use root account as otherwise I got the following >> errors: >> >> cp -a ./initramfs//* ./build/initramfs/ >> ../tools//initramfs/mkinitramfs -t ./build/initramfs/ -o >> ./initrd.img-`uname -r` >> /dev/sda1: Permission denied >> /usr/sbin/iucode_tool: cpuid kernel driver unavailable, cannot scan >> system processor signatures >> make[1]: Leaving directory `/usr/src/vdev/example' >> >> - copy initrd from example directory to /boot >> - boot using the previous grub.cfg >> - reboot my PC to use the initrd of vdev >> >> There is no ERROR about missing vdev config but my PC still ends up at >> (iniramfs) prompt. >> >> Cheers, >> >> Anto >> >> Thanks for giving it a try again! I'm going to try to reproduce it on my VM and I'll get back to you (could be a few days, though). > > Perhaps I was not quite clear on my previous email. There is indeed no > error messages about missing vdev config. But at the beginning of boot, I > still get the following messages: > > Loading, please wait... > /init: line 175: resolve_device: not found > I'm not sure what this is, but let me see if I can reproduce it on my VM. Thanks, Jude > > ___ > 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] Fwd: [dng] vdev status update
It just occurred to me that my reply wasn't CC'ed to the ML.
-- Forwarded message ------
From: Jude Nelson
Date: Tue, Apr 14, 2015 at 2:12 PM
Subject: Re: [Dng] [dng] vdev status update
To: Anto
Hi Anto, thank you for giving that a try!
> I am not sure if at this stage, it is worth it to report the problems that
> I have just experienced.
>
Actually, every bit of feedback helps :)
>
> I followed your 3 steps instruction to have vdev on the PC that I am
> currently using for writing this email (HP EliteBook 8530w), and
> surprisingly it does not work (yet) :)
> Before anyone ask: no, this is not a "production" PC as I have been
> beating it up so bad in the last 3 years since I got it used from the
> company I work for.
>
> In the grub.cfg, I used the same set of files as the ones from the running
> kernel generated by update-initramfs, except the initrd that I took from
> the "example" directory under vdev source directory.
>
> It booted the initrd, but just ended up on the (initramfs) prompt. It is
> hard to get the error messages during boot. I tried to record them using my
> mobile phone and the messages at the beginning are the following:
>
> Loading, please wait...
> /init: line 175: resolve_device: not found
> 00071:859055872: [ vdev.c:0425] vdev_init: ERROR:
> vdev_config_load('/etc/vdev/vdevd.conf') rc = -2
> 00071:859055872: [ main.c:0042] main: ERROR: vdev_init rc = -2
>
>
>
It looks like the config file didn't get installed to the right place.
Upon further inspection, it looks like I forgot to have the Makefile
install the vdev init script as well (I had installed it manually in my
VM). I'll add "create a generic device manager init script that works with
udev, vdev, mdev, and static /dev" to my TODO list :)
I pushed a fix to both git.devuan.org and github.com, if you're anxious to
try it again (I tested it insofar as ensuring that it generates /etc/vdev
properly, and it installs the vdev init script and removes the udev script
links from /etc/rcS.d). I haven't tested it on my VM yet, though.
Thanks again for giving this a go!
-Jude
> ___
> 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] [dng] vdev status update
Hi Anto, Thanks a lot for all your efforts on this. > My pleasure :) > > It looks like we are getting closer now, or at least to be able to compile > vdev as a deb package. And it seems the only package that needs to be > re-compile is initramfs. Do you think it is reasonable now to start > packaging vdev? > There are still a few things to be done before I'd recommend using it regularly (i.e. outside of a VM): * finish the remaining device scripts (in particular, scripts for setting up LVM). * integrate vdev, mdev, udev, static /dev, and other device management strategies into Devuan's alternatives system. * fork Debian's initramfs-tools to use the alternatives system to figure out which device manager's files (if any) to include in the initramfs. * finish designing, writing and testing libudev-compat with applications that depend on libudev0 or libudev1 (this one's pretty open-ended still). > > or did anybody try it already? > I'm using it as the device manager in my copy of the alpha Vagrant image, and others have tested it locally (but not for booting, AFAIK). I'm working on getting it to boot the the qcow2 image, which boots from LVM. Thanks, -Jude > ___ > 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] [dng] vdev status update
Hey everyone, I didn't have much time to work on vdev this weekend, but I did manage to make the vdev installation process easier. The build process automatically generates the host-specific /etc files for you (i.e. including rules for persistent interface names), as well as an initramfs with vdev installed so you can use it to boot. I've added preliminary instructions on how to install vdev to https://git.devuan.org/pkgs-utopia-substitution/vdev/blob/master/INSTALL.md. DISCLAIMER: the above process has only been lightly tested. I apologize in advance if you encounter bugs. Please do not try this on a production system, and please read *all* of the instructions before attempting to install (since it will mess with your initramfs). I hope to do more next weekend, but it's currently a very busy time of year for me right now (I have a work-related deadline at the end of April that I have to meet). Thanks, Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] two lists and developer disconnect (was: Re: dev-list)
Hi Johnathan, I should clarify what I had meant to say earlier in context--I believe I misspoke (serves me right to post with low blood sugar). On Thu, Apr 9, 2015 at 4:57 PM, Jude Nelson wrote: > > The ML structure will neither fix nor prevent bad behavior. However, it >> can mitigate its effect on the project. For this reason, I support >> Hendrik's idea of having a -tech mailing list for technical topics only >> (but that both users and developers can join). I also support having a few >> guidelines on more specialized mailing lists (should they be created) that >> describe what behavior is appropriate on them, as well as having a >> publicly-visible process in place for how to deal with people who abuse >> their list membership. >> >> It was wrong of me to suggest that being off-topic in and of itself evil; that was not the intent of this paragraph. Sometimes, I use the phrase "bad behavior" in a general way to simply mean "behavior that is inconsistent with what is expected". In this case, it was not meant to be a statement about the quality of the content or the character of the poster, but rather about the context in which the post occurs. Not the best choice of words, I must admit. What I was trying to say is that no matter what ML structure Devuan goes with, it's not going to eliminate the fundamental problems with mailing lists (i.e. people can post off-topic, people can misspeak, people can come off as insensitive without meaning to, etc.). But, by grouping threads by topic (i.e. having separate MLs), we can mitigate some of the frustrations felt by some subscribers by helping them find only the emails that they want to read, since certain subjects lend themselves better to the sensibilities of the reader. I've said more than I wanted to say on the ML topic--I'm fine with whatever Devuan chooses to do, but if I had to express a preference, it would be for a separate -tech ML. Thanks, -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] two lists and developer disconnect (was: Re: dev-list)
Hi Jonathan, On Thu, Apr 9, 2015 at 4:23 PM, Jonathan Wilkes wrote: > Hi Jude, > I wrote an email about some GUI features I'd like to see in the default DE > for Devuan. Jaromil wrote a thoughtful response. As a result I'm willing > to use the first stable release (and possibly beta release) and give > feedback and/or bug reports. > > If that's the kind of thing that belongs on a "tech" list, then what's the > purpose of this list? > You've hit the nail on the head as to why I also recommended "having a few guidelines on more specialized mailing lists." If Devuan goes towards multiple mailing lists, the guidelines should make it clear on the signup page which ML is appropriate for which topic (much like how a forum is organized by category). > > Also-- are the VUAs arguing for more lists actually arguing that more > abstraction doesn't come with the cost of adding more complexity? > (Especially given that there's already an invite-only dev list, so > guaranteeing that any additional dev list would be a misnomer.) > Not sure what you mean? I don't know anything more than you do about the private dev list (I'm not a VUA). > > Also-- what is the cost of advocating on _this_ list for more empathy and > less meanness? > Very little :) That's not the problem here, though (excluding trolls). The problem is that it's getting harder and harder to wade through the volume of uncategorized email to find only the tiny subset of them you're interested in reading. It's no one's fault that it's come to this, really--it's the expected emergent behavior of having a lot of enthusiastic people on a single mailing list. The conventional way to manage the volume of emails is to organize groups of conversations by topic somehow, to make it easier to find what you're looking for. -Jude > -Jonathan > > > > On Thursday, April 9, 2015 2:10 PM, Jude Nelson > wrote: > > > It has been suggested several times now that the reason Debian developers > supposedly suffer a disconnect from Debian users is because there are > dedicated -dev and -user mailing lists, where -dev is moderated to be > development topics only. It has been suggested that because developers can > simply ignore -user, they get disconnected from their needs. > > I don't think either of these conclusions are true. First, even if a DD > isn't subscribed to any public Debian mailing list, (s)he still receives > bug reports, feature requests, and direct emails from users. Moreover, the > first two are public record. Wanting to ignore unrelated conversations is > not a sign of disconnect. > > Second, disconnect can happen regardless of the ML structure--anyone can > whitelist/blacklist email addresses belonging to people they don't want to > listen to, and anyone can simply ignore an email message. > > Third, the biggest sources of toxicity in user/developer relations in > Debian that I have seen are narcissism and the lack of empathy. I have > seen prominent developers dismissing valid, constructive criticism with "if > you don't like it, fork it--it's open source after all" and "Linux is not > about choice." I have also seen long-time Debian users bad-mouthing > developers for not going through great lengths to support their pet > use-case--nevermind the fact that the use-case applies only to them and is > greatly outside the scope of the program. > > The ML structure will neither fix nor prevent bad behavior. However, it > can mitigate its effect on the project. For this reason, I support > Hendrik's idea of having a -tech mailing list for technical topics only > (but that both users and developers can join). I also support having a few > guidelines on more specialized mailing lists (should they be created) that > describe what behavior is appropriate on them, as well as having a > publicly-visible process in place for how to deal with people who abuse > their list membership. > > Thanks, > -Jude > > On Thu, Apr 9, 2015 at 12:15 AM, Martijn Dekkers < > devuan-li...@dekkers.org.uk> wrote: > > > We do not need another list. > > > That's pretty arrogant. Can you back that up with some actual reasons, > like others in this discussion are doing? Or is this simply a case of > "because I said so" > > ___ > 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
[Dng] two lists and developer disconnect (was: Re: dev-list)
It has been suggested several times now that the reason Debian developers supposedly suffer a disconnect from Debian users is because there are dedicated -dev and -user mailing lists, where -dev is moderated to be development topics only. It has been suggested that because developers can simply ignore -user, they get disconnected from their needs. I don't think either of these conclusions are true. First, even if a DD isn't subscribed to any public Debian mailing list, (s)he still receives bug reports, feature requests, and direct emails from users. Moreover, the first two are public record. Wanting to ignore unrelated conversations is not a sign of disconnect. Second, disconnect can happen regardless of the ML structure--anyone can whitelist/blacklist email addresses belonging to people they don't want to listen to, and anyone can simply ignore an email message. Third, the biggest sources of toxicity in user/developer relations in Debian that I have seen are narcissism and the lack of empathy. I have seen prominent developers dismissing valid, constructive criticism with "if you don't like it, fork it--it's open source after all" and "Linux is not about choice." I have also seen long-time Debian users bad-mouthing developers for not going through great lengths to support their pet use-case--nevermind the fact that the use-case applies only to them and is greatly outside the scope of the program. The ML structure will neither fix nor prevent bad behavior. However, it can mitigate its effect on the project. For this reason, I support Hendrik's idea of having a -tech mailing list for technical topics only (but that both users and developers can join). I also support having a few guidelines on more specialized mailing lists (should they be created) that describe what behavior is appropriate on them, as well as having a publicly-visible process in place for how to deal with people who abuse their list membership. Thanks, -Jude On Thu, Apr 9, 2015 at 12:15 AM, Martijn Dekkers < devuan-li...@dekkers.org.uk> wrote: > > We do not need another list. >> > > That's pretty arrogant. Can you back that up with some actual reasons, > like others in this discussion are doing? Or is this simply a case of > "because I said so" > > ___ > 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] [dng] vdev status update
Hi Isaac, On Wed, Apr 8, 2015 at 7:04 PM, Isaac Dunham wrote: > On Tue, Apr 07, 2015 at 05:22:55PM -0400, Jude Nelson wrote: > > > > > "report every kind of device, since it listens to the kernel's > driver > > > core > > > > > (i.e. libudev learns about network interfaces, buses, power > supplies, > > > > > etc.--stuff for which there are no device files" > > > > > > Currently, it doesn't *report* devices; that takes something longer > term, > > > like inotify, polling a netlink socket, or listening to a daemon. > > > > > > It also has no clue about events or hardware that could not have a > > > corresponding device, since it uses block/char and major:minor to find > > > the hardware. > > > > > > I have a general idea of how to get information like this, by recursing > > > through /sys or /dev, and I know of some code I could use as a starting > > > point, but I don't know what the ideal format is. > > > If someone points me at a program they'd like to use without libudev > > > (preferably C with minimal dependencies) that doesn't cover a lot of > > > ground (ie, it's clear what functionality udev provides, and I wouldn't > > > need to duplicate much of libudev to get it working), that would be a > > > good starting point for expanding libsysdev. > > > > > > > You might find something useful in vdev_linux_sysfs_register_devices() > and > > vdev_linux_sysfs_find_devices() functions in vdevd/os/linux.c. They're > > both involved in generating the initial coldplug device listing. They > only > > need libc to work, and libvdev/sglib.h for basic data structures. > > I know how to get the devices that show up in /dev; > I'm not sure about getting the sysfs entries that *don't* show up there. > I'm also not sure how anything beyond this is used. > Ah, my bad for misinterpreting your request. I found the sysfs rules overview from kernel.org helpful when I was working on this [1]. Basically, all devices (even ones without a major/minor number) are enumerated under /sys/devices/; the other directories under /sys/ all contain symlinks to device directories in /sys/devices/. Each device in /sys/devices/ has a "uevent" file that, when read, produces the payload of the netlink packet that the driver core would have sent when the device was added (note that some of them will be empty). The kernel organizes devices into a tree internally, which gets exported via sysfs. Each device has a globally-unique DEVPATH, which is the path to the device's directory under /sys/devices (except, DEVPATH omits the /sys prefix). Moreover, each device has a SUBSYSTEM that identifies the device's parent node in the device tree (which may or may not be a device itself). For example, PCI slot :ff:02.2 on my laptop has a DEVPATH of /devices/pci:ff/:ff:02.2. If you look in /sys/devices/pci:ff/:ff:02.2/, you'll see a symlink called "subsystem" that contains a symlink to the device's subsystem's device--in this case, "../../../bus/pci" (the basename of the path in "subystem" is the device's subsystem name--in this case, "pci"). The contents of the DEVPATH directory in sysfs include device-specific attributes--usually stuff like serial numbers, vendor strings, power-related data, etc. Is this the information you were looking for? [1] https://www.kernel.org/doc/Documentation/sysfs-rules.txt > > > > > To avoid the troublesome corner case where a libudev client > crashes and > > > > >> potentially leaves behind a directory in /dev/uevents/, I would > > > recommend > > > > >> mounting runfs [1] on /dev/uevents. Runfs is a special FUSE > > > filesystem I > > > > >> wrote a while back that ensures that the files created in it by a > > > > >> particular process get automatically unlinked when that process > dies > > > (it > > > > >> was originally meant for holding PID files). > > > Hmm... > > > Do we need to have a subdirectory of the mountpoint? > > > Could you just use ACLs if you need to make a limited subset available? > > > I get the impression that we can do this for mdev via a script along > > > these lines: > > > > > > > FILENAME=`env | sha512sum | cut -d' ' -f1` > > > for f in /dev/uevents/* > > > do env >"$f"/$FILENAME > > > done > > > > > > but it would be *nicer* if we only needed to write one file. > > > >
Re: [Dng] Would like to help with Devuan
Welcome aboard, Jeremy! The easiest way to help out is to use Devuan regularly, and keep track of the things about it that bother you. Then, try to figure out how to fix them, and share your fixes--be they new program configurations, shell scripts, Python scripts or C programs. If you ever get stuck, feel free to email the list and we can help you :) -Jude On Wed, Apr 8, 2015 at 8:40 AM, KatolaZ wrote: > On Tue, Apr 07, 2015 at 10:07:13PM -0400, JeremyBekka C wrote: > > [cut] > > > > > I know that I have a lot to learn, especially after reading the > technical > > posts here about the development of Devuan, but I am motivated and want > to > > learn. There is so much out there to read that I am overwhelmed sometimes > > and don't really know where to start. There are so many man pages that I > > really don't know which ones are the most important ones to read first. > So, > > I am wondering if I could get some tips on what I need to learn and how I > > can go about getting the proper training to be of service here in the > > Devuan community. I would like to be able to help detect and fix bugs, > and > > maybe become a package manager someday. > > > > > > Welcome Jeremy, > > as other have already said, there is probably no standard recipe to > get there :) IMHO, the manpages that you must to read first are those > of the programs that you need right now, the programming language to > learn first is the one that you need right now, the tools to use first > are those that you need right now, and so on. That's because studying > something that you need or would very much like to know is much easier > than just reading anything at random. > > Having said that, if you don't feel a compulsive need to know anything > in particular, then you should probably start from the core utils: > > $ info coreutils > > and when you have gone through them you can start wandering at random, > e.g.: > > $ man `ls /bin /sbin | shuf | head -1` > > and when you are done with those, try: > > $ man `ls /usr/bin /usr/sbin | shuf | head -1` > > But remember: manpages are there to be read when you need them, not to > be memorised :) > > Concerning programming languages, I agree that C should be the first > choice, together with shell scripting and then one of either Perl or > Python. But again, if you can't find a way of using them, or you don't > feel the need to use them for something in particular, then you will > just learn and forget almost everything. > > My2Cents > > KatolaZ > > -- > [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] > [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] > [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] > [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] > ___ > 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] dev-list
> suggest that Pottering is evil, > Definitely looking forward to this stopping. Seriously, it's not Lennart's fault that Debian decided to switch to systemd. If you want to blame anyone for this, blame the CTTE, the DDs who voted against init freedom in the GR, and the systemd fanbois who poisoned the well on the discussion. Neither Lennart, Red Hat, nor systemd drove me to Devuan. The Debian leadership and the greater Debian community did. -Jude > > > ___ > 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] [dng] vdev status update
Hi Isaac, [snip] > > > > libsysdev is meant to help clients pull information from sysfs. I don't > > think it is supposed to help clients run privileged ioctls (Isaac, please > > correct me if I'm wrong!). > > Not at present. > It basically maps a device to a sysfs directory and possibly gets a > *little* more info from that (currently just PCI IDs). > > You cannot make a library do anything privileged without either > helper programs or a helper daemon. > Personally, I'm inclined to think it would be nicer to use helpers... > but there are limitations to both approaches. > > I suppose it would be *possible* to make it configureable which it does. > Certainly :) I'd like to support that in libudev-compat as an option at some point. > > > > Can libsysdev do this part quoted below? > > > > > > "report every kind of device, since it listens to the kernel's driver > core > > > (i.e. libudev learns about network interfaces, buses, power supplies, > > > etc.--stuff for which there are no device files" > > Currently, it doesn't *report* devices; that takes something longer term, > like inotify, polling a netlink socket, or listening to a daemon. > > It also has no clue about events or hardware that could not have a > corresponding device, since it uses block/char and major:minor to find > the hardware. > > I have a general idea of how to get information like this, by recursing > through /sys or /dev, and I know of some code I could use as a starting > point, but I don't know what the ideal format is. > If someone points me at a program they'd like to use without libudev > (preferably C with minimal dependencies) that doesn't cover a lot of > ground (ie, it's clear what functionality udev provides, and I wouldn't > need to duplicate much of libudev to get it working), that would be a > good starting point for expanding libsysdev. > You might find something useful in vdev_linux_sysfs_register_devices() and vdev_linux_sysfs_find_devices() functions in vdevd/os/linux.c. They're both involved in generating the initial coldplug device listing. They only need libc to work, and libvdev/sglib.h for basic data structures. > > > > Is vdev and libsysdev tested together? > > > > > > > They're currently not used together. Libsysdev is meant to help programs > > that only need libudev for a few things (like querying sysfs) do so > without > > linking against libudev. > > > > > > To avoid the troublesome corner case where a libudev client crashes and > > >> potentially leaves behind a directory in /dev/uevents/, I would > recommend > > >> mounting runfs [1] on /dev/uevents. Runfs is a special FUSE > filesystem I > > >> wrote a while back that ensures that the files created in it by a > > >> particular process get automatically unlinked when that process dies > (it > > >> was originally meant for holding PID files). > Hmm... > Do we need to have a subdirectory of the mountpoint? > Could you just use ACLs if you need to make a limited subset available? > I get the impression that we can do this for mdev via a script along > these lines: > FILENAME=`env | sha512sum | cut -d' ' -f1` > for f in /dev/uevents/* > do env >"$f"/$FILENAME > done > > but it would be *nicer* if we only needed to write one file. > I agree that one file per event is ideal (or even a circular logfile of events, if we could guarantee only one writer). However, I'm not sure yet what a fine-grained ACL for device events would look like. My motivation for per-client directories is that unprivileged clients can be made to see only its own events and no one else's by default (i.e. by chmod'ing the directory to 0700), and that they make it easy reason about sending post-processed events only to the clients you want--just change the list of directories to iterate over in that for-loop :) > Also, wouldn't mounting that with runfs result in records of uevents > getting erased if they're written by a helper rather than a daemon? > Yes; good catch. There are a couple straightforward ways to address this: (1) have a separate, unprivileged device-event-log daemon curate /dev/uevents/ and have the helper scripts forward device events to it, or (2) fork and/or patch runfs to allow files to persist if they're generated by a certain whitelist of programs (i.e. all programs in a particular set of directories, like /lib/vdev/), but disappear otherwise once the creating process dies. > > Thanks, > Isaac Dunham > Thanks for your feedback! -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update
Hi Scooby, [Snip] > > >> However, this has proven to be a somewhat challenging problem, for a >> couple reasons. First, inotify(2) does not work on pseudo-filesystems like >> sysfs or devtmpfs, so we can't just watch /sys for changes, and we can't >> use devtmpfs for /dev. This means that systems using libudev-compat will >> require a "vanilla" tmpfs for /dev (or nothing at all), so it can detect >> when devices are added or removed. Second, only block and character >> devices show up in /dev. However, udevd reports every kind of device, >> since it listens to the kernel's driver core (i.e. libudev learns about >> network interfaces, buses, power supplies, etc.--stuff for which there are >> no device files). Clients will expect this behavior, so it's not enough to >> simply look up a new block/character device's sysfs data. >> > > Is this "listen to kernel driver core" something you don't want to do? If > so is it because one of the project goals > is to support several platforms i.e BSD? > > Or is it to keep it modular and not so interdependent? > Libudev clients expect to receive "post-processed" driver events from udev via a dedicated netlink multicast group (defined as UDEV_MONITOR_UDEV in libudev-monitor.c). Nothing stops libudev clients from opening their own netlink socket and listening directly to messages in the NETLINK_KOBJECT_UEVENT multicast group, but the advantage of listening to udevd is that udevd takes care of parsing the uevent packet, looking up extra metadata from sysfs and the hardware database, querying the device (!!), and filling in a "struct udev_device" instance with all the information it gathers. The reason why libudev doesn't just do all of the above is because querying the device is often a privileged operation, since it usually entails doing specialized ioctls. This is why udevd (and vdevd and mdev) need to run as root--the helper programs they run need to have sufficient privileges. This isn't an option for libudev clients, though, which is why they need to get device information from a device manager. My plan is to make vdevd make this information available via the filesystem (for portability and better access control), and patch libudev so clients can retrieve it. Over in systemd-land, I'm pretty sure the plan going forward is to replace netlink with kdbus to do the same task. > > >> My tentative solution is to require the device manager (whatever it >> happens to be) to take one extra step in addition to adding/removing device >> files: record driver core uevents in a well-defined location in /dev (let's >> say /dev/uevents/), so libudev clients can discover them (with inotify(2)), >> read them, and send them off to their applications. This can be done >> without loss of generality in udev, vdev, and mdev, and I can make a script >> that takes the appropriate action with mknod (so those with a static /dev >> can alias "mknod" to the script, if desired). >> > > So you want to split up the "listen to kernel driver core uevents" part > and vdev right? > > Trying to figure this out > > I saw you mentioning Isaac Dunham's libsysdev in another message. > It is a replacement for libudev, right? > libsysdev is meant to help clients pull information from sysfs. I don't think it is supposed to help clients run privileged ioctls (Isaac, please correct me if I'm wrong!). > Can libsysdev do this part quoted below? > > "report every kind of device, since it listens to the kernel's driver core > (i.e. libudev learns about network interfaces, buses, power supplies, > etc.--stuff for which there are no device files" > > Is vdev and libsysdev tested together? > They're currently not used together. Libsysdev is meant to help programs that only need libudev for a few things (like querying sysfs) do so without linking against libudev. > >> >> > To avoid the troublesome corner case where a libudev client crashes and >> potentially leaves behind a directory in /dev/uevents/, I would recommend >> mounting runfs [1] on /dev/uevents. Runfs is a special FUSE filesystem I >> wrote a while back that ensures that the files created in it by a >> particular process get automatically unlinked when that process dies (it >> was originally meant for holding PID files). >> > > > I tried runfs on my system that is using aufs and couldn't get it to run > I got something like "Transport endpoint is not connected" > This is not a problem for me since dev/ won't be persistent between boots > so can run without runfs. > Interesting. Were you able to get runfs to run somewhere else, i.e. on a temporary directory? Was there something else mounted there already that crashed earlier? If you run runfs with -f, it will run in the foreground, and that can tell you if something is amiss (you can also run it in valgrind this way). Runfs takes the standard FUSE options (-f for foreground, -s for single-threaded, -o $FUSE_OPTION for FUSE-specific options, -d for FUSE debugging output). > bes
[Dng] [dng] vdev status update
Hey everyone, Scooby, John Carline, lepoitr, and others (who wish to remain anonymous) have been sending me logs filesystem listings from running vdev locally. I very much appreciate it--it helped me discover and fix bugs relating to persistent paths for disk devices, seeding /dev with initial device files, and adding support for Virtualbox USB devices. Thank you to everyone who helped me with this! We are getting close to feature-parity with udev insofar as generating the proper device paths. However, there are still a few kinds of device paths that are not yet handled (that I know of). They are: * /dev/input/by-id/* * /dev/disk/by-partuuid/* * /dev/md/* * LVM volume group and logical volume paths (i.e. /dev/$VOLUME_GROUP/$LOGICAL_VOLUME) Lack of LVM VG/LV paths is probably a deal-breaker for many people on this list; I'll make it my next priority. I've also been modifying libudev 219 so clients do not need udevd to be running to receive device events. I mentioned last week that the strategy I would take is watching /dev for device files to get added/removed, and synthesizing the appropriate driver core uevent from the added/removed file (i.e. by looking up the associated uevent in /sys). However, this has proven to be a somewhat challenging problem, for a couple reasons. First, inotify(2) does not work on pseudo-filesystems like sysfs or devtmpfs, so we can't just watch /sys for changes, and we can't use devtmpfs for /dev. This means that systems using libudev-compat will require a "vanilla" tmpfs for /dev (or nothing at all), so it can detect when devices are added or removed. Second, only block and character devices show up in /dev. However, udevd reports every kind of device, since it listens to the kernel's driver core (i.e. libudev learns about network interfaces, buses, power supplies, etc.--stuff for which there are no device files). Clients will expect this behavior, so it's not enough to simply look up a new block/character device's sysfs data. My tentative solution is to require the device manager (whatever it happens to be) to take one extra step in addition to adding/removing device files: record driver core uevents in a well-defined location in /dev (let's say /dev/uevents/), so libudev clients can discover them (with inotify(2)), read them, and send them off to their applications. This can be done without loss of generality in udev, vdev, and mdev, and I can make a script that takes the appropriate action with mknod (so those with a static /dev can alias "mknod" to the script, if desired). The device manager would treat /dev/uevents/ as an "IPC" area. A libudev client would create a directory /dev/uevents/$PID/ upon initialization, and the device manager would write the uevent to each directory in /dev/uevents/ to a file named by the hash of the uevent's contents. Once the libudev client consumed the file, it would unlink it. For example, the PCI slot :ff:02.2 on my laptop generates the uevent packet containing: """ PCI_CLASS=6 PCI_ID=8086:2D13 PCI_SUBSYS_ID=17AA:2196 PCI_SLOT_NAME=:ff:02.3 """ The device manager would take the SHA256 of this string (57d39e74f7638f6c78c1fb86d81d2f203852b609f501df216abe4b45339d636f), and write the contents of this packet to the file /dev/uevents/*/57d39e74f7638f6c78c1fb86d81d2f203852b609f501df216abe4b45339d636f (i.e. one copy in each libudev client's /dev/uevents/ directory). Then, each libudev client would get woken up through inotify(2), would read the new file, forward the device event packet to the client, and unlink it. To avoid the troublesome corner case where a libudev client crashes and potentially leaves behind a directory in /dev/uevents/, I would recommend mounting runfs [1] on /dev/uevents. Runfs is a special FUSE filesystem I wrote a while back that ensures that the files created in it by a particular process get automatically unlinked when that process dies (it was originally meant for holding PID files). Any feedback on the above development plan is welcome, especially if a simpler, more robust approach can be found. Thanks, Jude [1] https://github.com/jcnelson/runfs ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Too many man pages, too much complicated : systemd
Should have said in the earlier email: the list of contributors I gave earlier is definitely not all-encompassing, nor was it meant to be (I was trying to give an example of other people working towards a systemd-free future, and those were the first few people that came to mind). This is why a wiki page with all contributors accounted for--not only developers, but also testers, bug-hunters, integrators, editors, document-writers, graphic artists, packagers, and so on. We're all in this together :) On Mon, Apr 6, 2015 at 3:23 PM, Jude Nelson wrote: > > > On Mon, Apr 6, 2015 at 11:07 AM, Martijn Dekkers < > devuan-li...@dekkers.org.uk> wrote: > > [snip] > >> It really is a pity. The VUA and guys like Jude do awesome work bringing >> the state-of-the-art forward when it comes to actually building working >> technology that does not depend on systemd, whilst this list is quickly >> just an echo chamber of pre-approved opinions. And the pre-approved >> opinions are getting less by the day. >> >> > I've seen at least two posts now where I've been held up as an example of > doing something about systemd. First, thank you for your kind words :) > Second, I can't take all the credit :) Besides the VUA collective > (Jaromil, Nextime, Hellekin, and others?), there's also: > > * Dima Krasner, who is working on LoginKit ( > https://git.devuan.org/pkgs-utopia-substitution/loginkit), as well as > building Puppy Linux from Devuan, and getting lightdm to work without > logind. > * Isaac Dunham, who is working on libsysdev ( > https://github.com/idunham/libsysdev) and getting X.org to run without > libudev. > * Scooby, lepoitr, John Carline, and other anonymous contributors who are > helping me test vdev on live hardware. > > I'd like to get a list together (perhaps on the wiki?) of the names or > aliases of the people who are working on making Devuan possible, so we can > give credit where credit is due. > > -Jude > > >> On 6 April 2015 at 17:55, Steve Litt wrote: >> >>> On Mon, 6 Apr 2015 11:46:45 +0300 >>> Martijn Dekkers wrote: >>> >>> > > What really puzzles me is why if you love systemd that much you just >>> > > continue arguing about systemd on the ML of a Debian fork >>> > > specifically born to throw systemd away. Do you think you might be >>> > > able to convince us that systemd is *good* and *beautiful* and >>> > > *necessary*? I don't want to be saved, thanks ;) >>> > > >>> > >>> > Looks to me like he isn't arguing for systemd, but he is just >>> > discussing systems designs and implementation. Also looks to me like >>> > he is simply keeping an open mind, and not getting swept away in hate >>> > either way >>> >>> But to what point? Devuan was born in, OK, I'll use your >>> characterization, hate, of systemd. Eliminating systemd is the >>> cornerstone of Devuan. Sure, we're forming principles that accommodate >>> our refusal to use systemd, and accommodate future software fiascos, >>> but it's obvious that Devuan=NoSystemd. >>> >>> So what is the point, on this particular list, of keeping an open mind >>> on the subject of systemd? I can see the point on the Manjaro list, or >>> the Gentoo list, or the Saybayon list, or the OpenSuSE list. But on >>> declared systemd-never lists like Devuan or Funtoo, or for that matter >>> on declared systemd-forever lists like RedHat and Fedora, what's the >>> point of being systemd agnostic? >>> >>> Systemd-agnosticism is appropriate in most venues. But not in venues >>> whose very foundation is pro or anti systemd. >>> >>> SteveT >>> >>> Steve Litt >>> Twenty Eight Tales of Troubleshooting >>> http://www.troubleshooters.com/28 >>> >>> >>> ___ >>> 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] Too many man pages, too much complicated : systemd
On Mon, Apr 6, 2015 at 11:07 AM, Martijn Dekkers < devuan-li...@dekkers.org.uk> wrote: [snip] > It really is a pity. The VUA and guys like Jude do awesome work bringing > the state-of-the-art forward when it comes to actually building working > technology that does not depend on systemd, whilst this list is quickly > just an echo chamber of pre-approved opinions. And the pre-approved > opinions are getting less by the day. > > I've seen at least two posts now where I've been held up as an example of doing something about systemd. First, thank you for your kind words :) Second, I can't take all the credit :) Besides the VUA collective (Jaromil, Nextime, Hellekin, and others?), there's also: * Dima Krasner, who is working on LoginKit ( https://git.devuan.org/pkgs-utopia-substitution/loginkit), as well as building Puppy Linux from Devuan, and getting lightdm to work without logind. * Isaac Dunham, who is working on libsysdev ( https://github.com/idunham/libsysdev) and getting X.org to run without libudev. * Scooby, lepoitr, John Carline, and other anonymous contributors who are helping me test vdev on live hardware. I'd like to get a list together (perhaps on the wiki?) of the names or aliases of the people who are working on making Devuan possible, so we can give credit where credit is due. -Jude > On 6 April 2015 at 17:55, Steve Litt wrote: > >> On Mon, 6 Apr 2015 11:46:45 +0300 >> Martijn Dekkers wrote: >> >> > > What really puzzles me is why if you love systemd that much you just >> > > continue arguing about systemd on the ML of a Debian fork >> > > specifically born to throw systemd away. Do you think you might be >> > > able to convince us that systemd is *good* and *beautiful* and >> > > *necessary*? I don't want to be saved, thanks ;) >> > > >> > >> > Looks to me like he isn't arguing for systemd, but he is just >> > discussing systems designs and implementation. Also looks to me like >> > he is simply keeping an open mind, and not getting swept away in hate >> > either way >> >> But to what point? Devuan was born in, OK, I'll use your >> characterization, hate, of systemd. Eliminating systemd is the >> cornerstone of Devuan. Sure, we're forming principles that accommodate >> our refusal to use systemd, and accommodate future software fiascos, >> but it's obvious that Devuan=NoSystemd. >> >> So what is the point, on this particular list, of keeping an open mind >> on the subject of systemd? I can see the point on the Manjaro list, or >> the Gentoo list, or the Saybayon list, or the OpenSuSE list. But on >> declared systemd-never lists like Devuan or Funtoo, or for that matter >> on declared systemd-forever lists like RedHat and Fedora, what's the >> point of being systemd agnostic? >> >> Systemd-agnosticism is appropriate in most venues. But not in venues >> whose very foundation is pro or anti systemd. >> >> SteveT >> >> Steve Litt >> Twenty Eight Tales of Troubleshooting >> http://www.troubleshooters.com/28 >> >> >> ___ >> 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] Too many man pages, too much complicated : systemd
If I ever write a desktop suite, it will store settings as a well-defined directory tree with human-meaningful file names and contents instead of a MySQL database or a large flat opaque file. That's just me, though. Jude On Sun, Apr 5, 2015 at 7:37 PM, T.J. Duchene wrote: > > > > -Original Message- > > From: Renaud (Ron) OLGIATI [mailto:ren...@olgiati-in-paraguay.org] > > Sent: Saturday, April 4, 2015 5:34 PM > > To: dng@lists.dyne.org > > Subject: Re: [Dng] Too many man pages, too much complicated : systemd > > > > On Sun, 05 Apr 2015 00:11:55 +0200 > > toto titi wrote: > > > > > Nearly as complex as a Microsoft operating system, look at that : > > > http://www.freedesktop.org/software/systemd/man/ > > > > Please, Sir, could we have a registry ? > > > > Cheers, > > > > Ron. > > -- > [T.J. ] You already do have a registry. > > It's called "gconf" and has been part of Gnome for the last decade. KDE > uses a MySQL database for many settings as well, so Gnome is not the only > culprit. > > The basic idea of a database/registry is not a bad one. It is actually > very > efficient for miscellaneous settings, or programming new features rapidly, > but the flip-side is that flat files are easier to fix if something goes > south. The idea of a registry gets a bad rap because of the poor way that > Microsoft implemented theirs with UUID codes that are hard to decipher, and > the fact that Microsoft never provided a tool to clean up the database to > prevent software rot. Fortunately, the Linux equivalents are user account > based rather than system wide and can easily be cloned, modified, or if > necessary dumped. > > T.J. > > > > > > ___ > 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] What do you guys think about "Suggest" and "Recommends" dependency?
I'm all for it. If there are a set of packages that usually get installed together, we can create a metapackage for them. -Jude On Thu, Apr 2, 2015 at 6:36 PM, Franco Lanza wrote: > Personally on debian i was using from date > > APT:Install-Recommends "0"; > APT:Install-Suggests "0"; > > in all my install apt.conf. > > I don't like apt downloading and installing things that are not required > but just recommended or suggested, expecially in server or embedded > envs, but also on my desktop. > > What do you think if we make this the default in devuan? > > > > -- > > 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 > --- > > > ___ > 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] What about pulseaudio, avahi, ... ?
Unlike systemd, you can easily get a working desktop system without PulseAudio, even on Debian. IIRC, the only commonly-used program that requires PulseAudio is Skype, and I've been able to get by even then by using apulse[1]. -Jude [1] https://github.com/i-rinat/apulse On Wed, Apr 1, 2015 at 3:25 PM, toto titi wrote: > Hi Guys, > and thank you to all of you for this fork. > Do you plan to get rid of pulseaudio and avahi as well, or do you just > focus on systemd ? > > ___ > 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] Wana give a try to vdev
Hi Didier, Thank you for offering! I haven't tried statically linking vdev or its helper programs yet, but I don't see why it wouldn't work. You'll need to tweak the vdevd and vdevd helper program makefiles (in vdevd/Makefile and vdevd/helpers/LINUX/Makefile, respectively) to add the -static directive to gcc. All of the helper programs only need libc. vdevd needs libvdev (which can be built with make -C libvdev), but libvdev only needs libc. Let me know how it goes? I'll add it to the tutorial I just sent out if it works :) Thanks, Jude On Tue, Mar 31, 2015 at 12:18 PM, Didier Kryn wrote: > Dear Jude, > > I would like to try your vdev. I plan to use a diskless embeded > powerpc I have available for devel. I prefer that to using quemu and I want > to keep my laptop functional h24. > > I would do it in an OS built from scratch with only 3 components: > kernel version 2.6.29, busybox and vdev. Therefore I would like to compile > vdev and link it statically from the source. Does it seem feasible? > > Didier > > ___ > 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] [vdev] vdev tutorial
Hey everyone, A few people have asked me privately how to help test vdev, for which I am very grateful :) It inspired me to write up a tutorial and crash course to testing and using vdev [1]. The instructions should work in the Vagrant image (or in Debian testing/unstable, for that matter). Any/all comments, feedback, and pull requests welcome :) -Jude [1] https://git.devuan.org/pkgs-utopia-substitution/vdev/blob/master/how-to-test.md Also available at https://github.com/jcnelson/vdev/blob/master/how-to-test.md ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update
Thankfully, the puppy should be fine :) She only ate a few capsules, and we caught her just after the fact, so we were able to get her proper treatment before the toxicity could set in. We get to take her home from the vet either tonight or tomorrow. -Jude On Tue, Mar 31, 2015 at 3:15 AM, Archangel Amael wrote: > Well how are the puppies? > Hey everyone, > > I don't have as much to report this week as I usually do, since I spent > half my weekend dealing with a pet medical emergency (TL;DR: ibuprofen is > toxic to puppies, and puppies can chew through child-proof lids). > > I am happy to report that I was able to extract the code for libudev 219 > from systemd 219, and get it to compile independently. The resulting > library is ABI-compatible with systemd's (no real surprise). > > My next steps are working through a couple vdev bugs that Scooby helped me > find, as well as get libudev to work without udevd. > > More next week, > Jude > > ___ > 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] Any plans to provide xinit without the systemd hacks?
Hey Isaac, So, I'm looking at startx here: http://cgit.freedesktop.org/xorg/app/xinit/tree/startx.cpp Where's the offending block of code? Is it lines 191-200? Looking at the commit history ( http://cgit.freedesktop.org/xorg/app/xinit/log/), it doesn't look like startx sees many changes these days. It should be easy to keep a separate startx script around, if you don't want it starting X on your current tty. -Jude On Sat, Mar 28, 2015 at 11:26 AM, Isaac Dunham wrote: > startx always used to start a new X server on a new TTY; now it starts > on the current vt. > > This is the result of a block of code in startx that forces "vtarg" to > the equivalent of `tty`. > The sole reason for this is that logind gets confused when something opens > on a new vt. > Will Devuan include an xinit package that doesn't do this? > > Thanks, > Isaac Dunham > ___ > 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] [dng] vdev status update
Hey everyone, I don't have as much to report this week as I usually do, since I spent half my weekend dealing with a pet medical emergency (TL;DR: ibuprofen is toxic to puppies, and puppies can chew through child-proof lids). I am happy to report that I was able to extract the code for libudev 219 from systemd 219, and get it to compile independently. The resulting library is ABI-compatible with systemd's (no real surprise). My next steps are working through a couple vdev bugs that Scooby helped me find, as well as get libudev to work without udevd. More next week, Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
