Re: [DNG] Mutuality and harmlessness
Dear Steve. Steve Litt - 25.11.18, 19:18: > On Sun, 25 Nov 2018 09:27:20 +0100 > Martin Steigerwald wrote: > > Hello Spiral of Hope. > > > > Thank you for your point of view. > > > > spiralofhope - 24.11.18, 18:24: > > > Now > > > > > > > what happens if I let go any belief that some of them are true > > > > or > > > > right, preferably my own, and some of them are false or wrong, > > > > preferably those of apparent others? What is beyond true or > > > > false, > > > > beyond right or wrong, beyond black or white, beyond left or > > > > right? What if, just what if this world is not binary, like a > > > > computer? What > > > > if, just what if this world has all the different colors and > > > > none > > > > of them are right or wrong? > > > > > > The binary is real. > > > > For me it is not. It is just part of the illusion. > > Genocide is wrong, full stop. > > I know you know this, but say it just in case there's any moral > equivocator who really believes there's no right or wrong in any > context: That's very dangerous. Just this for clarification: I named the thread "Mutuality and harmlessness". I also wrote: > Years ago I read a brilliant book titled (translated from german): "If > it hurts, it is no love". This is how I see love still: True love > never ever hurts. If it hurts, it is no love. I remember I wrote something along the lines of as well: If I hurt apparent others, I hurt myself. However I did not find it as I looked a moment ago. So I really see nothing in what I wrote which would support engaging in killing other people, engaging in genocide. As far as I see the belief in right or wrong, in good or bad – "You are a threat, cause you are bad" – and the wanting to control an apparent other's experience that I often saw coming along with it, is what motivated killing, what motivated genocides. Of course I can believe anything I like… however if I want to change the belief of any apparent other to align with my beliefs, that is where the trouble starts. Human beings used religions with a strict set of beliefs what is right and what is wrong, what is good and what is bad, what is divine and what is evil to bring a lot of suffering among them. Just as an example. If any belief in right or wrong, good or bad, divine or evil every stopped human beings from harming each other… the prisons of this world would be empty. There are not. If I drop any beliefs in good or bad, right or wrong, divine or evil… why would I even want to harm anyone else? Does that mean I need to let people get away with any violence, with any abuse they come up with? No. Does that mean I should refrain from standing up for civility, mutuality and harmlessness? No. But when I stop standing up for this from the place of right or wrong, good or bad, divine or evil, when I start standing up for this from a place of love and freedom I stand up for this from a very different place. If anything in this world is loved into existence by the one self, which many call God, everything is sacred. I skip responding to the other posts and instead let all the different colors expressed there just be. Thank you, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mutuality and harmlessness
Dear Steve. Martin Steigerwald - 27.11.18, 10:30: > I skip responding to the other posts and instead let all the different > colors expressed there just be. Of course, I let your opinion also be, Steve. As there really i no "instead". I can also let an opinion be I reply to. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Jessie + Huawei USB modems
On 11/23/18 5:02 PM, Adam Borowski wrote: On Fri, Nov 23, 2018 at 01:28:00PM +0100, Alessandro Selli wrote: Right, many USB modems show up as something different than a networking device when they are plugged-in. I haven't used any of them for a long time, but I remember many of them show up as a CDROM device which carries the Windows drivers and/or some Windows utility. The actual modem shows up after the CDROM device is unmounted or ejected. Ie, usbmodeswitch. This might or might not work with modemmanager -- in my experience, it works _randomly_. Including having the dongle suddenly switch while the connection is running, with obviously fatal results. And modemmanager seems to be unable to recover. Ok, today I paid a visit to the seniors' club to see what can be done. I found their old USB stick modem, inserted it into the Devuan box ...: root@devuan:~# lsusb Bus 002 Device 005: ID 19d2:0017 ZTE WCDMA Technologies MSM Bus 002 Device 003: ID 0951:1642 Kingston Technology DT101 G2 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 002: ID :3825 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub root@devuan:~# usb_modeswitch -v 19d2 -p 0017 Look for default devices ... product ID matched Found devices in default mode (1) Access device 005 on bus 002 Current configuration number is 1 Use interface number 0 USB description data (for identification) - Manufacturer: ZTE,Incorporated Product: ZTE WCDMA Technologies MSM Serial No.: MF6670VIPD01 - Warning: no switching method given. See documentation -> Run lsusb to note any changes. Bye! root@devuan:~# ... then I tried again but with some more options: root@devuan:~# usb_modeswitch -v 19d2 -p 0017 -K Look for default devices ... product ID matched Found devices in default mode (1) Access device 005 on bus 002 Current configuration number is 1 Use interface number 0 Use endpoints 0x01 (out) and 0x81 (in) USB description data (for identification) - Manufacturer: ZTE,Incorporated Product: ZTE WCDMA Technologies MSM Serial No.: MF6670VIPD01 - Sending standard EJECT sequence Looking for active driver ... OK, driver detached Set up interface 0 Use endpoint 0x01 for message sending ... Trying to send message 1 to endpoint 0x01 ... OK, message successfully sent Read the response to message 1 (CSW) ... Response reading failed (error -7) Device is gone, skip any further commands -> Run lsusb to note any changes. Bye! root@devuan:~# lsusb Bus 002 Device 005: ID 19d2:0017 ZTE WCDMA Technologies MSM Bus 002 Device 003: ID 0951:1642 Kingston Technology DT101 G2 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 002: ID :3825 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub root@devuan:~# usb_modeswitch -v 19d2 -p 0017 -K -R Look for default devices ... product ID matched Found devices in default mode (1) Access device 009 on bus 002 Current configuration number is 1 Use interface number 0 Use endpoints 0x01 (out) and 0x81 (in) USB description data (for identification) - Manufacturer: ZTE,Incorporated Product: ZTE WCDMA Technologies MSM Serial No.: MF6670VIPD01 - Sending standard EJECT sequence Looking for active driver ... OK, driver detached Set up interface 0 Use endpoint 0x01 for message sending ... Trying to send message 1 to endpoint 0x01 ... OK, message successfully sent Read the response to message 1 (CSW) ... Response reading failed (error -7) Device is gone, skip any further commands Device handle empty, skip USB reset -> Run lsusb to note any changes. Bye! root@devuan:~# ... seems that -K (eject memory stich driver) and -R (reset) did not change much (if anything). Any idea? The package modemmanager is supposed to take care of the correct initialization of a number of known and supported modems using udev's rules (the ASCII package install 18 such rules). Yet, I think sometimes human intervention is still needed, and of course several USB modems (as well as PCMCIA/CardBus ones and some WiFi dongles and Access Points) are partially, poorly or not supported at all. Alas, we're deeply in the "sacrifice a young black goat" land. The quality of drivers, firmware and _hardware_ is so egregious that it's far more effort effective to take an old phone and set up tethering. There is no modemmanager there, as well as no vwdial, ppp, etc installed per default in this Devuan distr
Re: [DNG] Devuan Jessie + Huawei USB modems
On 27-11-18 13:53, Miroslav Skoric wrote: > On 11/23/18 5:02 PM, Adam Borowski wrote: >> On Fri, Nov 23, 2018 at 01:28:00PM +0100, Alessandro Selli wrote: >> >>> Right, many USB modems show up as something different than a >>> networking device when they are plugged-in. I haven't used any of them >>> for a long time, but I remember many of them show up as a CDROM device >>> which carries the Windows drivers and/or some Windows utility. The >>> actual modem shows up after the CDROM device is unmounted or ejected. >> >> Ie, usbmodeswitch. This might or might not work with modemmanager -- >> in my >> experience, it works _randomly_. Including having the dongle suddenly >> switch while the connection is running, with obviously fatal >> results. And >> modemmanager seems to be unable to recover. >> > > Ok, today I paid a visit to the seniors' club to see what can be done. > I found their old USB stick modem, inserted it into the Devuan box ...: > > root@devuan:~# lsusb > Bus 002 Device 005: ID 19d2:0017 ZTE WCDMA Technologies MSM > Bus 002 Device 003: ID 0951:1642 Kingston Technology DT101 G2 > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 003 Device 002: ID :3825 > Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > root@devuan:~# usb_modeswitch -v 19d2 -p 0017 > Look for default devices ... > product ID matched > Found devices in default mode (1) > Access device 005 on bus 002 > Current configuration number is 1 > Use interface number 0 > > USB description data (for identification) > - > Manufacturer: ZTE,Incorporated > Product: ZTE WCDMA Technologies MSM > Serial No.: MF6670VIPD01 > - > Warning: no switching method given. See documentation > -> Run lsusb to note any changes. Bye! > > root@devuan:~# > > > ... then I tried again but with some more options: > > > root@devuan:~# usb_modeswitch -v 19d2 -p 0017 -K > Look for default devices ... > product ID matched > Found devices in default mode (1) > Access device 005 on bus 002 > Current configuration number is 1 > Use interface number 0 > Use endpoints 0x01 (out) and 0x81 (in) > > USB description data (for identification) > - > Manufacturer: ZTE,Incorporated > Product: ZTE WCDMA Technologies MSM > Serial No.: MF6670VIPD01 > - > Sending standard EJECT sequence > Looking for active driver ... > OK, driver detached > Set up interface 0 > Use endpoint 0x01 for message sending ... > Trying to send message 1 to endpoint 0x01 ... > OK, message successfully sent > Read the response to message 1 (CSW) ... > Response reading failed (error -7) > Device is gone, skip any further commands > -> Run lsusb to note any changes. Bye! > > root@devuan:~# lsusb > Bus 002 Device 005: ID 19d2:0017 ZTE WCDMA Technologies MSM > Bus 002 Device 003: ID 0951:1642 Kingston Technology DT101 G2 > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 003 Device 002: ID :3825 > Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > root@devuan:~# usb_modeswitch -v 19d2 -p 0017 -K -R > Look for default devices ... > product ID matched > Found devices in default mode (1) > Access device 009 on bus 002 > Current configuration number is 1 > Use interface number 0 > Use endpoints 0x01 (out) and 0x81 (in) > > USB description data (for identification) > - > Manufacturer: ZTE,Incorporated > Product: ZTE WCDMA Technologies MSM > Serial No.: MF6670VIPD01 > - > Sending standard EJECT sequence > Looking for active driver ... > OK, driver detached > Set up interface 0 > Use endpoint 0x01 for message sending ... > Trying to send message 1 to endpoint 0x01 ... > OK, message successfully sent > Read the response to message 1 (CSW) ... > Response reading failed (error -7) > Device is gone, skip any further commands > Device handle empty, skip USB reset > -> Run lsusb to note any changes. Bye! > > root@devuan:~# > > > ... seems that -K (eject memory stich driver) and -R (reset) did not > change much (if anything). Any idea? > >>> The package modemmanager is supposed to take care of the correct >>> initialization of a number of known and supported modems using udev's >>> rules (the ASCII package install 18 such rules). Yet, I think >>> sometimes >>> human intervention is still needed, and of course several USB modems >>> (as >>> well as PCMCIA/CardBus ones and some WiFi dongles and Access Points) >>> are >>> partially, poorly or not supported at all. >> >
[DNG] Participate to the first Devuan Conference in Amsterdam!
Dear Init Freedom Lovers, On the fourth anniversary of the birth of Devuan, once again the Veteran Unix Admins salute you! # Participate to the first Devuan Conference in Amsterdam! ## From Friday, April 5th through Sunday, April 7th 2019 # The power of choice The Devuan Conference 2019 is a not-for-profit event, this means that the conference fees will cover the bare cost of venue, catering, logistics and documentation materials. At this stage we accept donations and offers for sponsorship: if you like to help, contact us at or make a donation using the description '**Devuan Conference**' directly to: ``` Paypal: foundat...@dyne.org ``` Or via bank wire to the IBAN below : ``` Dyne.org foundation (non-profit) Bank: ABN-AMRO - Amsterdam, The Netherlands IBAN: NL87ABNA0406496021 BIC: ABNANL2A ``` # Call for Sponsors Space at the conference is limited and we are trying to balance the amount of registration with the size of the venue and resources available. Hence registrations at this time are called mainly for **talks** and **sponsors**. In two weeks we will follow up with more information and an early bird offer for tickets. Please do consider sponsoring this event! We will work hard to give you and all the conference attendees all the visibility deserved. Send your sponsorship proposal to with the word `sponsor` in the subject. If we have enough sponsors to cover all costs we'll be able to grant free entrance! # Call for Papers Devuan Conference 2019 is YOUR conference! Please share your ideas and passion. If you would you like to: - present on a Devuan-related topic, or - report on a particularly successful/unexpected/original use of Devuan, or - host a Devuan-related workshop for users or developers, or - run a Devuan-focused hacking session, or - Then please contact us at If you like to propose a talk please send us a title, description, length in minutes and any URL or PDF via email, please also include the word '**CFP**' in the subject. # Travel and accomodation The costs for reaching and staying in Amsterdam are entirely on participants, but we hope that by releasing early this call everyone has enough time to conveniently book a place in this beautiful city and perhaps allow a couple extra days to visit it and hang out. # Live streaming and recording The conference will be a great occasion to have in-depth interviews with developers and adopters as well plenary sessions of Q&A with the public, in the hope to exchange more information about the future of Devuan. The event will be streamed live and recorded and all recordings will be freely made available online. Journalists interested to participate are welcome to contact us, we will prepare a press folder and make sure they can reach anyone they want to interview. # Contact For any further questions please feel free to contact our conference organisation committee via email at we are happy to receive suggestions and wishes and requests, to make this the best possible conference for our community # Further steps Thanks for reading up to hear! if you or anyone else is interested please make sure to subscribe our devuan-announce list here: https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-announce updates will follow in the coming months, meanwhile if you are sure to attend make sure to reserve your tickets and stay in Amsterdam: on 5-7 April 2019 the very first Devuan Conference is happening! Happy Hacking! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Participate to the first Devuan Conference in Amsterdam!
I don't want to be "that American," so I'm writing to ask: will this conference will be done primarily in English or another language? *Linux O'Beardly* linux.obear...@gmail.com http://o.beard.ly On Tue, Nov 27, 2018 at 5:57 PM Veteran Unix Admins wrote: > > Dear Init Freedom Lovers, > > On the fourth anniversary of the birth of Devuan, > once again the Veteran Unix Admins salute you! > > # Participate to the first Devuan Conference in Amsterdam! > > ## From Friday, April 5th through Sunday, April 7th 2019 > > # The power of choice > > > The Devuan Conference 2019 is a not-for-profit event, this means that > the conference fees will cover the bare cost of venue, catering, > logistics and documentation materials. > > At this stage we accept donations and offers for sponsorship: if you > like to help, contact us at or make a donation > using the description '**Devuan Conference**' directly to: > ``` > Paypal: foundat...@dyne.org > ``` > Or via bank wire to the IBAN below : > ``` > Dyne.org foundation (non-profit) > Bank: ABN-AMRO - Amsterdam, The Netherlands > IBAN: NL87ABNA0406496021 > BIC: ABNANL2A > ``` > > # Call for Sponsors > > Space at the conference is limited and we are trying to balance the > amount of registration with the size of the venue and resources > available. Hence registrations at this time are called mainly for > **talks** and **sponsors**. In two weeks we will follow up with more > information and an early bird offer for tickets. > > Please do consider sponsoring this event! We will work hard to give > you and all the conference attendees all the visibility deserved. > > Send your sponsorship proposal to with the > word `sponsor` in the subject. > > If we have enough sponsors to cover all costs we'll be able to grant > free entrance! > > # Call for Papers > > Devuan Conference 2019 is YOUR conference! Please share your ideas and > passion. > > > If you would you like to: > - present on a Devuan-related topic, or > - report on a particularly successful/unexpected/original use of Devuan, or > - host a Devuan-related workshop for users or developers, or > - run a Devuan-focused hacking session, or > - > > Then please contact us at > > If you like to propose a talk please send us a title, description, > length in minutes and any URL or PDF via email, please also include > the word '**CFP**' in the subject. > > # Travel and accomodation > > The costs for reaching and staying in Amsterdam are entirely on > participants, but we hope that by releasing early this call everyone > has enough time to conveniently book a place in this beautiful city > and perhaps allow a couple extra days to visit it and hang out. > > # Live streaming and recording > > The conference will be a great occasion to have in-depth interviews > with developers and adopters as well plenary sessions of Q&A with the > public, in the hope to exchange more information about the future of > Devuan. The event will be streamed live and recorded and all > recordings will be freely made available online. > > Journalists interested to participate are welcome to contact us, we > will prepare a press folder and make sure they can reach anyone they > want to interview. > > # Contact > > For any further questions please feel free to contact our conference > organisation committee via email at we are > happy to receive suggestions and wishes and requests, to make this the > best possible conference for our community > > # Further steps > > Thanks for reading up to hear! if you or anyone else is interested > please make sure to subscribe our devuan-announce list here: > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-announce > updates will follow in the coming months, meanwhile if you are sure to > attend make sure to reserve your tickets and stay in Amsterdam: on 5-7 > April 2019 the very first Devuan Conference is happening! > > Happy Hacking! > > ___ > 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] merging /tmp
Quoting Erik Christiansen (dva...@internode.on.net): > That leaves /var, which I've kept separate for three decades, to obviate > the risk of furious rates of logging fatally depleting /. OK, it takes > longer now, but the principle remains. Tip (and one man's opinion): On servers, I've long found it useful to hsve /var as an ext2 filesystem (for highest raw performance), with the following mount options: noatime,nodev,nosuid The noatime option further and substantially reduces metadata overhead, another non-trivial boost to system disk performance. The other two are an aid against software mishap and a first-level obstacle against automated system-cracking tools -- there being no legitimate reason for device nodes or SUID binaries on that filesystem. (Depending on your system, you probably want to ensure that /var/lib and /var/spool are served from elsewhere, either separate filesystems of their own or symlinks to trees elsewhere /like to dirs under /home or some such.) > Growth of /tmp was never a problem, as removal of several day old tmp > files was/is a standard cronjob, at least after you've been bitten once. I actually think tmpfs for /tmp is a fine idea, provided (1) you are aware of what'll happen if it balloons, and (2) you're OK with it being backed by volatile storage and aren't surprised by it being empty after reboots including unplanned ones. The speed gain is serious. If nervous about all of /tmp being volatile, you could, e.g., have subdir /var/volatile only mounted as tmpfs. For me, I'm leaning towards all of /tmp being on tmpfs and _no_ swap of any kind on near-future server systems because of intended use of only SSDs, no spinning rust at all. I don't have hard data, but suspect that the wear on SSDs from swap activity is substantial to a degree that outweighs swap's functional utility -- for my use-case, at least. I intend to have a go at a style of operation where running out of physical RAM means the OOM killer gets loose for a while, and see how that goes. The implicity assumption is 'I'll try to avoid that by having enough RAM and not running tasks configured so they're likely to blow up and drive the system into swap.' My metrics say that I haven't been driving into swap, so it's probably a reasonable stance. . ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] merging /tmp
On 27.11.18 22:28, Rick Moen wrote several juciy tips, including: > (Depending on your system, you probably want to ensure that /var/lib > and /var/spool are served from elsewhere, either separate filesystems > of their own or symlinks to trees elsewhere /like to dirs under /home > or some such.) I'm still getting my head around the concept of having separate /var and then symlinking /var/spool back into /home. Admittedly, I do in effect something like that for mail, as procmail (invoked directly by postfix) dumps 99.9% of mail to ~/mail/*, so only the smallest residue hits /var/spool/mail/erik . That outlier has been a backup nuisance, which your method obviates. Looking at /var/lib for the first time in three decades, I see the merit of that symlink, at least for backup purposes. > > Growth of /tmp was never a problem, as removal of several day old tmp > > files was/is a standard cronjob, at least after you've been bitten once. > > I actually think tmpfs for /tmp is a fine idea, provided (1) you are > aware of what'll happen if it balloons, and (2) you're OK with it being > backed by volatile storage and aren't surprised by it being empty after > reboots including unplanned ones. The speed gain is serious. > > If nervous about all of /tmp being volatile, you could, e.g., have > subdir /var/volatile only mounted as tmpfs. > > For me, I'm leaning towards all of /tmp being on tmpfs and _no_ swap of > any kind on near-future server systems because of intended use of only > SSDs, no spinning rust at all. I don't have hard data, but suspect that > the wear on SSDs from swap activity is substantial to a degree that > outweighs swap's functional utility -- for my use-case, at least. I > intend to have a go at a style of operation where running out of > physical RAM means the OOM killer gets loose for a while, and see how > that goes. The implicity assumption is 'I'll try to avoid that by > having enough RAM and not running tasks configured so they're likely to > blow up and drive the system into swap.' My metrics say that I haven't > been driving into swap, so it's probably a reasonable stance. Now that is very appealing. It feels like the way things should be. It'll take a while to marshall the round-tuits, but it's now on the to-do list. Many thanks for the insight. Erik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
Quoting KatolaZ (kato...@freaknet.org): > # ldd /sbin/mount.nfs | grep "/usr" > libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 > (0x7f82f53ac000) > libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 > (0x7f82f52cf000) > libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 > (0x7f82f529b000) > libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 > (0x7f82f4fd1000) If I were relying on NFS during early boot, I'd file a bug against package nfs-common, and also, meanwhile, compile a local-package substitute with either static binaries or ones linked to libs in /lib (and provide those). > # ldd /sbin/lvscan | grep "/usr" > liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 > (0x7fde00702000) > > # ldd /sbin/lvs | grep "/usr" liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7fd3b7fa1000) Ditto package lvm2. (Which FWIW I've avaoided needing.) > # ldd /sbin/sysctl | grep "/usr" > liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 > (0x7f3ab7b18000) Um, I know of no reason why /sbin/sysctl would be urgently needed in a minimal system prior to availability of /usr for purposes of backup, restore, system repair, etc. I've never needed to futz with /proc/sys/* entries while running in maintenance mode, but, if one did need to do so, doing the task using 'echo' is more than sufficient. > # ldd /sbin/gdisk | grep "/usr" > libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > (0x7f7ddf10f000) I haven't yet needed gdisk (& cgdisk, sgdisk, fixparts), having so far successfully avoided GPT. The obvious alternative to gdisk is GNU parted (package parted), and FWIW it suffers a similar build boo-boo, requiring library libtic.so.5 (terminfo) from inside /usr/lib. Tsk-tsk. ;-> > # ldd /bin/kill | grep "/usr" > liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 > (0x7f9f6aa4a000) > > # ldd /bin/ps | grep "/usr" > liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 > (0x7fd7f6ebc000) Yeah, those two are really annoying. FWIW, my server system has older versions of those two utilities that do _not_ have that (IMO) build error. Local packages will be an immediate resort, when/if I hit that. > # ldd /bin/efibootmgr | grep "/usr" > libefivar.so.1 => /usr/lib/x86_64-linux-gnu/libefivar.so.1 > (0x7f7ed22bd000) > libefiboot.so.1 => /usr/lib/x86_64-linux-gnu/libefiboot.so.1 > (0x7f7ed20b) As with GPT, I've managed so far to step sideways and successfully evade the Second System Effect poster child that is EFI. I'm also unconvinced that efibootmgr is essential to a 'recovery' minimal maintenance system, anyway. My readings suggest that I would want to have a 'EFI stub kernel' configuration where you place an (unsigned) kernel binary image in the EFI System Partition and rely on the EFI firmware to boot that kernel and mount the root fs directly without needing a bootloader. Coverage at, among other places: https://wiki.gentoo.org/wiki/EFI_stub_kernel (As usual, I'm saying this is an example of what would Work for Me[tm]. What might suit others or some entire abstract group of people is a different discussion.) > Most of the utilities you would need to debug a problem in mounting a > /usr over NFS, or a failing lvm volume, or a scrambled efi partition > (some of the use cases somebody mentioned before) need stuff in > /usr. This has not been my experience for my own use case (granting your point about /bin/kill and /bin/ps as provided in packaged versions I am not yet running). If I encounter that, I will consider that situation to involve critical bugs that I would resolve through the package maintainer if possible, or via a locally built alternative if not. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Participate to the first Devuan Conference in Amsterdam!
On Tue, 27 Nov 2018, Linux O'Beardly wrote: >I don't want to be "that American," so I'm writing to ask: will this >conference will be done primarily in English or another language? it will be entirely in english. Also in Amsterdam you can be reassured everyone speaks and understands english. the announce contains some spelling mistakes that may suggest otherwise :^) and that's entirely my fault to rush it out. ciao! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
