Re: [DNG] What I learned at Distrowatch
On 14/12 23:31, Hendrik Boom wrote: > On Sun, Dec 13, 2020 at 09:31:02PM +0100, Didier Kryn wrote: > > Le 13/12/2020 à 03:15, Steve Litt a écrit : > > > On Fri, 11 Dec 2020 15:53:35 +0100 > > > Didier Kryn wrote: > > > > > > > > >> I don't make it an argument against xdm. Just cheating about your > > >> own arguments (~: > > > Didier, why didn't you make that suggestion to me 15 years ago? It's a > > > brilliant way to guarantee that if somebody logs out of X, they have no > > > logged in shell to make mischief with. > > > > > > I should have thought of that myself. 15 years ago :-). > > > > > Yes you should have. But this is something everybody forgets all the > > time. We all imagine a program invocation like a function call, in which > > the caller is suspended until the callee returns; but actually when the > > shell is suspended waiting the application to return, it intentionnally > > waits, but can easily stop waiting. The artefact is that we must add an > > '&' to tell it not to wait in the first place. This is a semantic sugar > > to make it behave by default "as if" it was a function call. > > > > exec does not create a new process; instead it substitutes the new > > application to the current one (the shell). I had fun some years ago > > writing an application which opened an http connection to a server on > > standard input, read the http header, and then execed another > > application given in argument. > > We Scheme programmers are very aware of this -- it's called tail-calling, and > the Scheme > implementation does this anytime it can. indeed. And in Forth it's called "next" :) Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What I learned at Distrowatch
On Sun, Dec 13, 2020 at 09:31:02PM +0100, Didier Kryn wrote: > Le 13/12/2020 à 03:15, Steve Litt a écrit : > > On Fri, 11 Dec 2020 15:53:35 +0100 > > Didier Kryn wrote: > > > > > >> I don't make it an argument against xdm. Just cheating about your > >> own arguments (~: > > Didier, why didn't you make that suggestion to me 15 years ago? It's a > > brilliant way to guarantee that if somebody logs out of X, they have no > > logged in shell to make mischief with. > > > > I should have thought of that myself. 15 years ago :-). > > > Yes you should have. But this is something everybody forgets all the > time. We all imagine a program invocation like a function call, in which > the caller is suspended until the callee returns; but actually when the > shell is suspended waiting the application to return, it intentionnally > waits, but can easily stop waiting. The artefact is that we must add an > '&' to tell it not to wait in the first place. This is a semantic sugar > to make it behave by default "as if" it was a function call. > > exec does not create a new process; instead it substitutes the new > application to the current one (the shell). I had fun some years ago > writing an application which opened an http connection to a server on > standard input, read the http header, and then execed another > application given in argument. We Scheme programmers are very aware of this -- it's called tail-calling, and the Scheme implementation does this anytime it can. -- hendrik > > -- 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
Re: [DNG] Redhat EEEs CentOS?
On Thu, 10 Dec 2020 23:47:39 -0800 Rick Moen wrote: > Quoting vmlinux (vmli...@charter.net): > > > Embrace, Extend, Extinguish? Shocking but not surprising. Even more > > reason for Devuan to exist. > > > > https://arstechnica.com/gadgets/2020/12/centos-shifts-from-red-hat-unbranded-to-red-hat-beta/ > > > Plenty of blood being spilled over there. Think there are a couple of the original CentOS devs who I remember proudly being given their Red Hats who probably now feel a dagger sticking out their back. This caught the eye. http://crunchtools.com/before-you-get-mad-about-the-centos-stream-change-think-about/ Various interesting comments: http://crunchtools.com/before-you-get-mad-about-the-centos-stream-change-think-about/#comment-647540 But as someone pointed out RH revenue in 2018 was like $3.4 billion So the reasoning is far from clear cut - it isn't really all about cash in the strictest sense (it will be there somewhere clearly). Anyone see the dark hand of IBM being waved in the background? Want a more cutting edge rapid release version for their Cloud stuff? Fedora -> CentOS -> RH ? "it’s not about making money, it’s about out growing your competitors" (and dumping a few 'free loaders' I guess) You need to be pushing the curve in that case. CentOS did not fit. I have to say personally I was surprised CentOS agreed to be 'bought out' in the first place, and then always expected this day would come. That air of inevitability. Hey ho. pgpT47YzicuZ1.pgp Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
On Sun, Dec 13, 2020 at 10:15:26PM +0100, Antony Stone wrote: > On Sunday 13 December 2020 at 21:13:10, d...@d404.nl wrote: > > > It looks like systemd again is responsible for this mess. > > That is unexpected for me, since I am starting from a clean installation of > Devuan Beowulf - no upgrade, no crossover from Debian - just a totally new > install of Devuan (which I'm expecting to be ohne/sans/without systemd in any > form). systemd can cause probems on machines without systemd. Software developed and running elsewhere may well acquire adaptations for systemd, which then cause trouble on non-systemd machines. Often unintentional trouble. For example, > > From what I understand uses eudev the same files as systemd with udev. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
On Sun, 13 Dec 2020 14:20:25 +0100
Antony Stone wrote:
> On Sunday 13 December 2020 at 13:02:45, Florian Zieboll via Dng wrote:
>
> > Am 13. Dezember 2020 12:01:39 MEZ schrieb Antony Stone
> :
> > > Well, here's the output from "dmesg | grep eth". It shows the
> > > r8169 interfaces being given names eth0, eth1 (the ones I want as
> > > eth1 and eth2), then the tg3 interface gets called eth2 (which I
> > > want as eth0).
> > >
> > > At 6 seconds in, you can see my 70-persistent-net.rules file
> > > kicking in and renaming then to xeth2, xeth1 and xeth0; then
> > > finally at 12 seconds, the second rename in
> > > /etc/network/interfaces sets them back to eth0, eth1 and eth2 in
> > > the order I want them.
> >
> > So have you tried with 'ifnames=1'?
>
> I hadn't, but I've just done so now - it makes no difference - here's
> dmesg:
>
> [0.00] Linux version 4.19.0-10-amd64
> (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6))
> #1 SMP Debian 4.19.132-1 (2020-07-24) [0.00] Command line:
> BOOT_IMAGE=/boot/vmlinuz-4.19.0-10-amd64
> root=UUID=9cbc8bd3-4cb8-4ae1-92c5-5a3659e9aed6 ro net.ifnames=1 quiet
>
> [3.394364] r8169 :04:00.0 eth0: RTL8168e/8111e,
> 00:e0:4c:80:21:6b, XID 2c20, IRQ 30
> [3.394368] r8169 :04:00.0 eth0: jumbo features [frames: 9200
> bytes, tx checksumming: ko]
> [3.450174] r8169 :05:00.0 eth1: RTL8168e/8111e,
> 00:e0:4c:80:21:6c, XID 2c20, IRQ 31
> [3.450177] r8169 :05:00.0 eth1: jumbo features [frames: 9200
> bytes, tx checksumming: ko]
> [3.489342] tg3 :07:00.0 eth2: Tigon3 [partno(BCM95723) rev
> 5784100] (PCI Express) MAC address 78:ac:c0:f7:89:f7
> [3.489347] tg3 :07:00.0 eth2: attached PHY is 5784
> (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
> [3.489350] tg3 :07:00.0 eth2: RXcsums[1] LinkChgREG[0]
> MIirq[0] ASF[0] TSOcap[1]
> [3.489352] tg3 :07:00.0 eth2: dma_rwctrl[7618]
> dma_mask[64-bit] [6.187233] tg3 :07:00.0 xeth0: renamed from
> eth2 [6.231916] r8169 :05:00.0 xeth2: renamed from eth1
> [6.246745] r8169 :04:00.0 xeth1: renamed from eth0
>
> > And are you sure, that the 'hwaddress' lines in your
> > '/etc/network/interfaces' really define which NIC to use?
>
> I'm not using hwaddress in that file - that was a suggestion from
> terryc, and I think it's the wrong idea for exactly the following
> reason:
>
> > AFAICT this option just changes ("spoofs") the MAC address of the
> > NIC for which it is defined. Although the log confirms that finally
> > eth0 is the tg3 NIC, this seems unusual (and very counterintuitive)
> > to me.
>
>
> Thanks,
>
>
> Antony.
Stop the madness! Seriously, life shouldn't be this complicated.
Observe:
#!/bin/sh
# Copyright (c) 2016 by Steve Litt
# Expat license. See http://directory.fsf.org/wiki/License:Expat
chosen_wifi_number=${1:-1}
wifidevs=0
for dev in `ip -o link | sed -n 's/[^:]*: *\(w[^:]*\).*/\1/p'`;
do
wifidevs=`expr $wifidevs + 1`
test $wifidevs -eq $chosen_wifi_number && {
echo $dev
exit 0
}
done
echo =max$wifidevs
The preceding shellscript delivers the single wifi dev name when
there's only one wifi dev. If there are more, you'll need to tweak it a
little, but no big deal. You can also change it to find Ethernet
devices by changing the "w" in the for statement to an "e". You could
even assign and export the crazy device names to environment variables
like $eth0 and $wla1.
Boxes with multiple Ethernet or Wifi devices were always a problem,
since back when I started in 1998 and probably a lot before. Back then,
the old pros advised us newcomers never to have Ethernet cards of the
same brand and model, or the naming of Ethernet devices would be
indeterminate. Names like wlEat5hit01 aren't my idea of a good
solution, but except in the case of USB dongles, they're a hell of a
lot better than the old eth0 names, if you use them right.
If we'd grown up with wlEat5hit01 and eno8shit3gg25 and gotten used to
them, we'd scream bloody murder if they were replaced with eth0 and
the like.
Shellscripts like the one in this email can be enhanced to do amazing
things with very little effort.
When you find yourself trying to peer inside black boxes like udev,
eudev, evdev, vdev and the like, perhaps it's time to try something
new. There's a reason Ken Thompson and Dennis Ritchie made UNIX the way
they did, with simple commands to give the user incredible power. It
was for situations like this, so you didn't have to read and possibly
tweak a couple thousand lines of C code, you just made a 20 line
shellscript.
SteveT
Steve Litt
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___
Dng mailing list
Dng@lists.dyne.org
Re: [DNG] Version control /etc (was Re: Ethernet names revisited)
Hi Martin, Martin Steigerwald writes: > Olaf Meeuwissen via Dng - 13.12.20, 03:48:23 CET: >> Hi Hendrik, >> >> Hendrik Boom writes: >> > I wish everything user-configurable under /etc was under revision >> > control. then we might even be able to have a vendor branch and a >> > local branch. >> Have a look at etckeeper. >> >> I've been using that for several years now on a variety of machines. >> The log for the machine I'm writing this on goes back all the way to >> its initial install on 2017-01-11 of Devuan's Jessie Official Beta2 >> :-) >> >> You may want to keep your sensitive /etc/ files out of the repository >> though, depending on your level of paranoia. > > I still do not use etckeeper, cause I prefer to just add the files to the > repository that I actually change. This way, whenever I like to > replicate the config onto another machine or even just look at what I > changed, I can just clone the repository and have exactly a tree of > those files that I adapted. Actually, I have been *thinking* about using vcsh to track those parts of /etc/ that I tinker with myself and that are amenable to sharing between (subsets of) my machines. I've been using vcsh to selectively manage the dot-files I care about and a small collection of snippets and scripts and that works quite well, for me at least. Still need to roll up my sleeves and see if I can get something like that to work for /etc/ or even / (so I can track /usr/local/ bits too). > Of course, Ansible would be also an > alternative. I am just not completely sure whether it makes sense with > just a few machines. I may start to use it with hosted virtual machines > as it eases moving to a different provider if need be. > > I do not care about all the automatic changes by package upgrades. That's you ;-) I do care, so I use etckeeper. Hendrik asked about stuffing /etc/ in git, so I suggested etckeeper. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Version control /etc (was Re: Ethernet names revisited)
Hi Dimitris, Dimitris T. via Dng writes: > Olaf Meeuwissen via Dng wrote: >> >> Have a look at etckeeper. > > was using it for years, but not anymore.. > too much disk i/o, too many files, `git gc` never ran (only by hand), > and it never really came handy during those years... > > maybe storing etckeeper repo it in a different backup disk makes more > sense, but anyway..., backups, backups, backups. :) Backups really serve another use case. I'm primarily using etckeeper to find out what may have caused something from behaving the way it did in the face of (ir)regular (unattended) upgrades. Even went so far as to allow empty commits because stuff under /var/log/apt/ is rotated away into oblivion, eventually. I also occasionally use it to find out when I upgraded to a particular version of a package. I haven't experienced any issues with disk IO or too many files. Most server machines run unattended-upgrades nightly and my laptops are only upgraded (manually) every one or two weeks. If running `sudo etckeeper vcs gc` by hand is too much trouble ;-), tag it on to the list of DPkg::Post-Invoke commands or stick it into a cron job. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
