Re: [Solved - sorta - part 2] Re: how to switch a Debian buster system from systemd to sys-v init
Hi Jonas, > On Jun 25, 2019, at 11:20 PM, Jonas Smedegaard wrote: > > Would be helpful to know if those experiencing long pause in > dbus-depending environments had _no_ dbus installed (and actively > running) or had it running with elogind. How can I tell which situation I have? Thanks! Rick
Re: [Solved - sorta - part 2] Re: how to switch a Debian buster system from systemd to sys-v init
Quoting Rick Thomas (2019-06-26 09:13:37) > Hi Jonas, > > > On Jun 25, 2019, at 11:20 PM, Jonas Smedegaard wrote: > > > > Would be helpful to know if those experiencing long pause in > > dbus-depending environments had _no_ dbus installed (and actively > > running) or had it running with elogind. > > How can I tell which situation I have? Check if elogind is installed, e.g. with `dpkg --list dbus`. Check if dbus is installed (it wouldn't be immediately after running the previously shared set of commands which explicitly remove it, but might have been later pulled in again), e.g. with `dpkg --list elogind`. If dbus is installed then check if dbus is running, e.g. by inspecting output of `ps ax` - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Icons are mixed when rebooting.
When you restart, the first icon at the top at the top moves to the end of the list of icons on the desktop. LXDE Linux debian 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux
Re: DVD Burning speed
That I don't know. It could be the dvd burning software setting this limit unless more than one type of software also does it. On Wed, 26 Jun 2019, deloptes wrote: > Date: Wed, 26 Jun 2019 01:06:11 > From: deloptes > To: debian-user@lists.debian.org > Subject: Re: DVD Burning speed > Resent-Date: Wed, 26 Jun 2019 05:06:34 + (UTC) > Resent-From: debian-user@lists.debian.org > > Jude DaShiell wrote: > > > The speed in the burning command and the fs parameter. ?Needs the right > > amount of memory in it and that's a factor of machine resource > > availability. > > but I do not have option 1x - it gives me minimum 3x. Why is this so > > > --
Re: cannot install from backports
Thank you! That makes sense now. I'm new to Debian (*long* time Ubuntu user), so I didn't realize the difference. SO, since Gimp version 2.10 is in "testing", and version 2.8 is in stable,* is there a way to install Gimp 2.10 (from "Debian testing") onto my "Debian stable" system?* Kind regards, --Brian On Tue, Jun 25, 2019 at 4:09 PM Roberto C. Sánchez wrote: > On Tue, Jun 25, 2019 at 04:04:55PM -0400, Brian Cary wrote: > >Greetings! > >As the title says, I can't seem to install anything from backports. > >Example, lets say I need to upgrade Gimp from 2.8 (in stable) to 2.10 > (in > >Testing).If I go to [1]https://backports.debian.org/Packages/ I can > verify > >that 2.10 is indeed in testing. > >I run this: > >apt -t stretch-backports install gimp > >And my newly installed Debian 9.9 replies: > >gimp is already the newest version (2.8.18-1+deb9u1). > >0 upgraded, 0 newly installed, 0 to remove and 153 not upgraded. > >Which is of course WRONG, because we just looked in Packages and > verified > >that 2.10 is in testing. > >What can I do to install Gimp 2.10 from testing? > > Testing and backports are two different things. There is no Gimp > package currently in backports. > > Regards, > > -Roberto > > -- > Roberto C. Sánchez > > -- --Brian Fantastic Fantasy, Curiously Chronicled Links for all the major platforms -> http://BrianCaryBooks.com
Re: New nomeclature of ethernet devices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The Wanderer wrote: > On 2019-06-25 at 09:28, Michael Stone wrote: >> On Tue, Jun 25, 2019 at 08:46:28AM -0400, The Wanderer wrote: >>> On 2019-06-25 at 08:11, Michael Stone wrote: > It isn't because: 1) the new names are predictable but not constant, so you can't configure a single default across all systems >>> >>> Which seems reasonable to describe as "unpredictable". >> >> They're perfectly predictable for a given system. > > And reasonably unpredictable between systems. > > Just reiterating the case where they *are* predictable misses my point > so badly that it almost seems as if it must be intentional. > >> The old names also weren't constant, but people didn't seem to care >> as much about the nuances because "that's the way it's always been". >> (Sometimes it was an eth, sometimes it was a wlan, etc.) Why were >> those differences ok but these differences aren't? Familiarity. > > No, not just familiarity. > > To the best of my awareness, the old names were 100% constant, as long > as you had no more than one interface *of a given type*. Quite so. > [...] > With the new names, the fact that two interfaces get different name > prefixes (etc.) tells you basically nothing useful about how to handle > them; it just exposes underlying hardware details of some kind, which > you don't actually need to know in order to make effective use of those > interfaces. To some degree. Unless they've changed *again* (I don't follow the "latest and greatest" changes that closely), you essentially get "en[...]" and "wl[...]" in place of 'eth0' and 'wlan0', respectively. That being said, the "new" names are relatively clunky to use when working outside of "my machine here" (e.g. with users abandoning W10). -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl0TRvUACgkQjhHd8xJ5 ooFB9wf+MLfx2BrNGRphEH7QyBWAn1+JEdQ8LzwOVx0z3emkQavrMyHocUrafO7d TMUwSlT/yYasePwLh7mwn1ii9/z2jmiegwdR8Ip5w6YmfSszjOu006GtKoUvHe4R 4QATY2ZiZxg0BCCWtnAG48flb81c0n+8/eC4x3OGbiSFu0/JYGEuQiWSrPeT8fRi w9O2CA027fz6zOM+LZe1hMFNwOkManniKYrovxUqb6ydRaqyrLL9QDaWjOdBITUc EskGRSNz2eTA6aIPrl8K3C++2C0JPYjgWpbOqXwPBasXMfd0C6YSX7Gpo3mJajFq muN9VYkHO9ia6adcs+R8CrTi0x67ug== =sff2 -END PGP SIGNATURE- -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
Re: cannot install from backports
Brian Cary wrote: > Thank you! That makes sense now. I'm new to Debian (*long* time Ubuntu > user), so I didn't realize the difference. > SO, since Gimp version 2.10 is in "testing", and version 2.8 is in stable,* > is there a way to install Gimp 2.10 (from "Debian testing") onto my "Debian > stable" system?* No. Not without breaking everything. But Debian 10 Buster is really really really close to release (two more weeks, IIRC). You can either wait for it to become officially declared stable or just upgrade ahead of time. See the Release Notes here: https://www.debian.org/releases/buster/amd64/release-notes/index.en.html Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: New nomeclature of ethernet devices
On 06/25/2019 06:51 PM, The Wanderer wrote: I want the first (only) *wired* interface. Do the new names even distinguish between the types? (I haven't paid them enough close attention to have the necessary awareness of what names result in order to be able to answer that question with any confidence.) https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html All names start with a two-character prefix that signifies the interface type.
Re: cannot install from backports
On 6/26/2019 12:27 PM, Brian Cary wrote: > Thank you! That makes sense now. I'm new to Debian (*long* time Ubuntu > user), so I didn't realize the difference. > SO, since Gimp version 2.10 is in "testing", and version 2.8 is in stable,* > is there a way to install Gimp 2.10 (from "Debian testing") onto my "Debian > stable" system?* > Simply add in '/etc/apt/sources.list' the lines for Buster but be extremely careful when mixing stable and non-stable pkgs. -- John Doe
Re: New nomeclature of ethernet devices
On Tue, Jun 25, 2019 at 07:51:53PM -0400, The Wanderer wrote: > On 2019-06-25 at 09:28, Michael Stone wrote: > > ifquery --list | grep -v lo > > And what about when you only want the wired interface, or only the > wireless one, but the machine might have one of each type? /sbin/ifquery --list | grep ^en # or grep ^wl I'm not disagreeing with you, though. I think the "predictable" names cause as many problems as they solve.
Re: cannot install from backports
On Wed, Jun 26, 2019 at 01:35:15PM +0200, john doe wrote: > Simply add in '/etc/apt/sources.list' the lines for Buster but be > extremely careful when mixing stable and non-stable pkgs. Do NOT mix stable with newer branches. If you want to upgrade to buster, go ahead. Now's a good time for it. This close to buster's release, it's going to be relatively bug-free. You don't get security coverage until the formal release, but if you can live without that for another week and a half, it should be quite usable.
Re: New nomeclature of ethernet devices
> /sbin/ifquery --list | grep ^en # or grep ^wl Of course, this fails when for some reason (either local configuration or lack or necessary info for "predictable" naming) the interface is called ... eth0! Stefan
Re: New nomeclature of ethernet devices
Hi. On Wed, Jun 26, 2019 at 08:15:00AM -0400, Greg Wooledge wrote: > On Tue, Jun 25, 2019 at 07:51:53PM -0400, The Wanderer wrote: > > On 2019-06-25 at 09:28, Michael Stone wrote: > > > ifquery --list | grep -v lo > > > > And what about when you only want the wired interface, or only the > > wireless one, but the machine might have one of each type? > > /sbin/ifquery --list | grep ^en # or grep ^wl $ /sbin/ifquery --list lo intbr int0 The result is lacking both eth0 and wlan0 which I do have here. The reason is - 'ifquery --list' lists only interfaces which are marked as 'auto' in e/n/i. I'm sticking to the plain 'ls /proc/sys/net/ipv4/conf'. It does lie if network namespaces are taken into the account, but does not require copious amounts of perl, sed and awk to be readable. Reco
Julio-Agosto Contratar ENCARGADO de Recursos Humanos, Reclutamiento, Nominas, Capacitacion
Experiencia mínima 3 años, Relaciones Industriales o afín Programa de Especialización para el Generalista de Recursos Humanos 4.0 Guadalajara, Jal. – 29 de Julio 2019 Monterrey, N.L. – 09 de Agosto 2019 Ciudad de México – 12 de Agosto 2019 ¿Qué es lo que hace a un verdadero GENERALISTA DE RECURSOS HUMANOS 4.0? Aprende en esta ESPECIALIZACIÓN todas las competencias, habilidades, conocimientos y destrezas que debe tener un GENERALISTA para poder llevar satisfactoriamente un DEPARTAMENTO de RECURSOS HUMANOS 4.0 Favor de enviar el folleto completo del Programa de Especialización para el Generalista de Recursos Humanos 4.0 con atención personalizada para: Nombre: Empresa: Teléfono: Sede: ( ) Guadalajara, Jal. / 29 de Julio 2019 ( ) Monterrey, N.L. / 09 de Agosto 2019 ( ) Ciudad de México / 12 de Agosto 2019 Número de personas interesadas: Mayor información referente a este Programa de Especialización comuníquese al: 01-800-890-86-65 o al teléfono (33) 36-32-84-80 (Contamos con más de 12 líneas a su servicio) Este boletín informativo tiene como objetivo crear valor en usted y en su Organización, si desea dejar de recibir este tipo de información favor de contestar BAJAGENERALISTA611 o en su defecto en el enlace que viene posteriormente. unsubscribe from this list
Re: New Hardware + old disks not recognized
On Tue, Jun 25, 2019 at 12:31 PM Pascal Hambourg wrote: > > Le 24/06/2019 à 01:40, Ross Boylan a écrit : > > > > # update-initramfs -u -k 4.19.0-5-amd64 > > update-initramfs: Generating /boot/initrd.img-4.19.0-5-amd64 > > /usr/share/initramfs-tools/hooks/cryptroot: 64: > > /usr/share/initramfs-tools/hooks/cryptroot: cannot open /proc/mounts: > > No such file > > cryptsetup: WARNING: Couldn't determine root device > > sed: can't read /proc/cmdline: No such file or directory > > /usr/share/initramfs-tools/hooks/cryptroot: 64: > > /usr/share/initramfs-tools/hooks/cryptroot: cannot open /proc/mounts: > > No such file > > cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries > > nor crypto modules. If that's on purpose, you may want to uninstall the > > 'cryptsetup-initramfs' package in order to disable the cryptsetup > > initramfs > > integration and avoid this warning. > > W: Couldn't identify type of root file system for fsck hook > > > > /proc/mounts isn't accessible in the chroot; > > You need to mount /proc. In a chroot, it is often desirable to mount at > least the /dev, /proc and /sys pseudo-filesystems. I'm aware, and probably should have qualified my statement--proc wasn't accessible when I ran the command. I hadn't mounted it partly out of laziness and mostly out of concern that stuff in the chroot would leak into the main system, or vice-versa. In particular ... > > > even if it were, it would > > not give the mounts appropriate for the system I'm trying to set up. > > Why not ? The output of /proc/mounts is not static, it is relative to > the process reading it. I thought /proc would give me the root of the parent system, but I just tried it and see that's not so. Thank you for pointing that out. Has it always worked that way? So do you think the chroot generated initrd would have been OK if I'd mounted proc? Ross
Re: IPv4 v IPv6
On Sat, Jun 22, 2019 at 07:34:52PM +, Andy Smith wrote: > That is why the stance that, "I have IPv4 so I don't need to do > anything" is not completely correct: it's not urgent for much of the > world at present, but we will get into a situation where either one > or both sides of a given IP conversation are behind multiple layers > of NAT that they don't control, and that's bad. I recently came across a couple of articles that indicate that due to the issues I mentioned in this email, IPv6 is already faster than IPv4: https://www.retevia.net/fast/ …and that this has some interesting effects on the economics for carriers (ISPs) and content providers (e.g. web hosts and large retailers) of v6 vs v4: https://www.retevia.net/prisoner/ Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: New nomeclature of ethernet devices
On Tue, Jun 25, 2019 at 07:51:53PM -0400, The Wanderer wrote: On 2019-06-25 at 09:28, Michael Stone wrote: On Tue, Jun 25, 2019 at 08:46:28AM -0400, The Wanderer wrote: On 2019-06-25 at 08:11, Michael Stone wrote: It isn't because: 1) the new names are predictable but not constant, so you can't configure a single default across all systems Which seems reasonable to describe as "unpredictable". They're perfectly predictable for a given system. And reasonably unpredictable between systems. When dealing with other people's systems, there was always an element of randomness. I've run into it so often that it's just hard to understand why that's even debatable but I suppose people have differing experiences. If you're absolutely convinced that the world can't work if the first ethernet interface in a system isn't named eth0, just stop reading here because it won't get any better. Just reiterating the case where they *are* predictable misses my point so badly that it almost seems as if it must be intentional. Really. The old names also weren't constant, but people didn't seem to care as much about the nuances because "that's the way it's always been". (Sometimes it was an eth, sometimes it was a wlan, etc.) Why were those differences ok but these differences aren't? Familiarity. No, not just familiarity. To the best of my awareness, the old names were 100% constant, as long as you had no more than one interface *of a given type*. And never changed anything, because locking the names via udev was necessary to keep them from renaming themselves. So if you bought a new nic it would never, ever show up as eth0 without some edits. With the new names, the fact that two interfaces get different name prefixes (etc.) tells you basically nothing useful about how to handle them; it just exposes underlying hardware details of some kind, which you don't actually need to know in order to make effective use of those interfaces. The en, wl, ww, etc, prefixes tell you the exact same information (what the class of interface is). The remaining information also relates useful information as to how the interface is attached. You might personally not care about that information, but it seems presumptuous to decide that nobody should. On a single computer with any number of interfaces of any type, the new names are 100% predictable from one boot to the next. (At least assuming you don't change which slot a given network device is connected to; IIRC that can change the assigned name, in at least some cases.) That does change the name, that's the entire point. With no real benefit as far as I can tell, but yes. Since I've already explained how that's helpful, I assume this is intentional? I understand that you refuse to believe that having more than one NIC is a thing. Computers with multiple interfaces of the same type are, AFAIK always have been, and IMO are likely to always be, much less common than computers with at most one interface of a given type. They're also the only computers where the name actually matters. In the simple case it's set at install time and doesn't change, so it could be completely random and it wouldn't make a difference. It matters if you're giving someone directions, with the computer sight unseen. Before, you could write directions - or even a script - which just referenced 'eth0' and/or 'wlan0', and hand the result out Internet-wide, with assurance that it would work reliably for the large majority of people. Now, you have to do something to detect the interface(s) and choose the right one. So your entire issue boils down to not wanting to explain a few fundamental concepts and instead take some shortcuts which would *never* have worked reliably in all cases? I'd rather just show people how to find out which interfaces they have and cover all the cases without all the drama. ifquery --list | grep -v lo And what about when you only want the wired interface, or only the wireless one, but the machine might have one of each type? Then look for the line that starts with w or e. Honestly, it seems like you're looking for problems. (Actually it's likely that the command above won't work with a wireless card, which was probably configured with network manager via a GUI. The issues with trying to support users in the wild on a variety of hardware are a lot more complicated than what the interface is named, and few of those issues are as trivial to overcome. It's basically impossible to easily cover all the ways a modern system might be configuring its network.) (Plus, I'm pretty sure the environment I work with doesn't have ifquery; it has ifconfig, but not necessarily much beyond that. The older versions didn't even have a DHCP client more sophisticated than dhcpcd. I can add tools to it, but that becomes a pain to maintain, for the same reasons as adding 'net.ifnames=0' to the kernel command line would be.) Since this is a d
Re: IPv4 v IPv6
On Wed, Jun 26, 2019 at 06:37:25PM +, Andy Smith wrote: On Sat, Jun 22, 2019 at 07:34:52PM +, Andy Smith wrote: That is why the stance that, "I have IPv4 so I don't need to do anything" is not completely correct: it's not urgent for much of the world at present, but we will get into a situation where either one or both sides of a given IP conversation are behind multiple layers of NAT that they don't control, and that's bad. I recently came across a couple of articles that indicate that due to the issues I mentioned in this email, IPv6 is already faster than IPv4: Yup. In my area all the bandwidth-intensive stuff from mobile devices is already going over a nice IPv6 route; it's unfortunate that the wired providers have dragged their feet so much.
Re: New Hardware + old disks not recognized
Le 26/06/2019 à 20:15, Ross Boylan a écrit : So do you think the chroot generated initrd would have been OK if I'd mounted proc? Yes.
Re: Debian Getting started
On Vi, 17 mai 19, 22:04:32, Paul Sutton wrote: > Hi Hi Paul, > Following on from Francisco post, I had been thinking about writing > something about getting started for a while. So decided to just get on > and do it. > > http://zleap.net/debian-getting-started/ > > I am trying to write this from my own view point of being new and > explain how I got started and how others can. Lot of references to > parts of the Debian Website. Please do link to ESR's How To Ask Questions The Smart Way. http://www.catb.org/~esr/faqs/smart-questions.html Regarding Salsa vs. Gihub, please note Salsa is using the Gitlab software. While quite similar to Github there are two important differeneces: 1. It's Free (Libre) Software 2. It is hosted by Debian There was another discussion on this list why these two points matter. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Fwd: Debian Installer Buster RC 2 release
Forwarded Message Subject:Debian Installer Buster RC 2 release Resent-Date:Wed, 26 Jun 2019 17:49:25 + (UTC) Resent-From:debian-b...@lists.debian.org Date: Wed, 26 Jun 2019 19:49:09 +0200 From: Cyril Brulebois Reply-To: debian-b...@lists.debian.org Organization: Debian To: debian-devel-annou...@lists.debian.org CC: debian-b...@lists.debian.org The Debian Installer team[1] is pleased to announce the second release candidate of the installer for Debian 10 "Buster". Improvements in this release * choose-mirror: - Update Mirrors.masterlist. * cryptsetup: - New section “Unlocking LUKS devices from GRUB” pointing to: https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html * debian-archive-keyring: - Add Buster keys (#917535, #917536). * debian-cd: - Create images to fit on 16G USB sticks too (for amd64 and i386). - Tweak package selection to make the multi-arch firmware netinst fit on CD media again (needs a 700MB CD-R): Don't include 686 PAE kernels on these CDs. - Tweak ordering of snapshot URLs in jigdo images to remove load on snapshot.debian.org. * debian-installer: - Add haveged-udeb [linux] to avoid entropy starvation issues (#923675). Those could affect HTTPS connections, SSH keypair generation, etc. - Bump Linux kernel ABI from 4.19.0-4 to 4.19.0-5. - Add œ/Œ glyphs for the French translation. - Update size limits. - Relabel “Dark theme” into “Accessible high contrast” (#930569). - Compress armhf u-boot images with “gzip -n” to avoid embedding timestamps which cause reproducibility issues. * espeakup: - Wait longer for sound cards. * grub2: - Make grub-efi-*-bin recommend efibootmgr, for debugging purposes. - Make grub-efi work on armhf too (upstream fixes for alignment bugs). * installation-guide: - Add the partman-auto-lvm/guided_size setting to the example preseed config file (#930846). * libdebian-installer: - Enlarge maximum line length in Packages and Sources files (#55). * lowmem: - Update size limits. * network-console: - Fix gen-crypt segfault, which prevented remote installations due to a missing password for the “installer” user (#926947, #928299). * openssl: - Ship an openssl.cnf in libssl1.1-udeb, fixing wget's TLS issues in the installer (#926315). * partman-auto: - Tweak Arabic translation to avoid a hang at the hard disk step (#929877). * preseed: - Update auto-install/defaultroot, replacing stretch with buster (#928031). * rootskel: - Start haveged when appropriate, to avoid entropy starvation (#923675). This means when the haveged binary is available, and when there's no hardware RNG available. - Update size limits for the graphical installer. UEFI Secure Boot updates Debian's Secure Boot setup is still being polished, the main updates are summarized below. * debian-installer: - Add shim-signed and grub-efi-ARCH-signed to build-dependencies for amd64/i386/arm64. - Use the signed shim and grub packages for all 3 arches for EFI images. - Fix the netboot setup for signed grub images to match the previous setup and the existing documentation (#928750). * grub2: - Generate a specific signed netboot image for d-i to use (#928750). - Add cpuid, play, ntfs modules to signed UEFI images (#928628, #930290, #923855). - Deal with --force-extra-removable with signed shim too (#930531). Hardware support changes * debian-installer: - [arm64] Add support for netboot SD-card-images. - [arm64] Add u-boot images for a64-olinuxino, orangepi_zero_plus2 and teres_i. - Add support for NanoPi NEO2. * flash-kernel: - Add support for NanoPi NEO2 (#928861). - Add support for Marvell 8040 MACCHIATOBin Double-shot and Single-shot (#928951). * linux: - udeb: Add all HWRNG drivers to kernel-image (#923675). - udeb: input-modules: Include all keyboard driver modules. - [arm64] udeb: kernel-image: Include cros_ec_spi and SPI drivers. - [arm64] udeb: kernel-image: Include phy-rockchip-pcie. - [arm64] udeb: usb-modules: Include phy-rockchip-typec and extcon-usbc-cros-ec. - [arm64] udeb: mmc-modules: Include phy-rockchip-emmc. - [arm64] udeb: fb-modules: Include rockchipdrm, panel-simple, pwm_bl, and pwm-cros-ec. - udeb: Drop unused ntfs-modules packages. Localization status === * 76 languages are supported in this release. * Full translation for 39 of them. Known bugs in this release == * There seems to be no known major bug as of yet. See the errata[2] for details and a full list of known issues. Feedback for this release = We need your help to find bugs and further improve the installer, so please try it. Installer CDs, other media and everything else you will need are available at our web site[3]. Thanks == The Debian Installer team thanks everybody who has contributed to this release. 1. https://wiki.debian.org/DebianInstaller/Team 2. https://www.debian.org/devel
Re: New nomeclature of ethernet devices
(This shouldn't have to be said, but please don't CC me on list messages unless you both specifically want to draw my attention to them and think I might not read them on-list otherwise. I am clearly subscribed to the mailing list.) On 2019-06-26 at 14:49, Michael Stone wrote: > On Tue, Jun 25, 2019 at 07:51:53PM -0400, The Wanderer wrote: > >> On 2019-06-25 at 09:28, Michael Stone wrote: >>> They're perfectly predictable for a given system. >> >> And reasonably unpredictable between systems. > > When dealing with other people's systems, there was always an > element of randomness. I've run into it so often that it's just hard > to understand why that's even debatable but I suppose people have > differing experiences. If you're absolutely convinced that the world > can't work if the first ethernet interface in a system isn't named > eth0, just stop reading here because it won't get any better. That's such an excessive exaggeration of my position that I have a hard time taking your associated arguments seriously. >>> The old names also weren't constant, but people didn't seem to >>> care as much about the nuances because "that's the way it's >>> always been". (Sometimes it was an eth, sometimes it was a wlan, >>> etc.) Why were those differences ok but these differences >>> aren't? Familiarity. >> >> No, not just familiarity. >> >> To the best of my awareness, the old names were 100% constant, as >> long as you had no more than one interface *of a given type*. > > And never changed anything, because locking the names via udev was > necessary to keep them from renaming themselves. So if you bought a > new nic it would never, ever show up as eth0 without some edits. Which isn't possible anyway if the network device is hardwired into the motherboard, as is the case on every consumer-targeted system I remember encountering for as long as I've been paying conscious attention. While I do know where to find add-in network cards if I need or want them, I don't know if I'd even be able to find a motherboard without integrated networking, at least on the desktop side. (And if you're doing expansion-card replacement on laptops, except maybe something like replacing one wireless card with another, you're better than I am. I'm not sure I've ever even seen a laptop with a *free* expansion slot.) >> With the new names, the fact that two interfaces get different name >> prefixes (etc.) tells you basically nothing useful about how to >> handle them; it just exposes underlying hardware details of some >> kind, which you don't actually need to know in order to make >> effective use of those interfaces. > > The en, wl, ww, etc, prefixes tell you the exact same information > (what the class of interface is). I guessed there might be something like that, but couldn't remember with confidence. > The remaining information also relates useful information as to how > the interface is attached. You might personally not care about that > information, but it seems presumptuous to decide that nobody should. That information can be useful in some contexts, and I'm certainly not saying that it should not be available to people who do care about it. But as far as I can discern, it does not tell you anything about how you(r software) needs to handle the interface, whereas wired vs. wireless does - and the overwhelming majority of potential end users do not care about anything it does tell you. If you know of any cases/examples where the exact path by which a network device is connected to the system makes a difference to how the system's software needs to handle it, please do explain it, and what the different handling involved is; I haven't been able to think of any such. >>> That does change the name, that's the entire point. >> >> With no real benefit as far as I can tell, but yes. > > Since I've already explained how that's helpful, I assume this is > intentional? I understand that you refuse to believe that having > more than one NIC is a thing. Of course it's possible to have more than one NIC. That's why having the new naming pattern available as an option is a good thing. It's just not remotely the common case, so it shouldn't be the default; people who need it will have an easy enough time of turning it on, but people who don't need it are much less likely to have enough skill etc. to turn it off. (And if they don't turn it off, it's that much harder for skilled people to advise them on how to do things.) >>> They're also the only computers where the name actually matters. >>> In the simple case it's set at install time and doesn't change, >>> so it could be completely random and it wouldn't make a >>> difference. >> >> It matters if you're giving someone directions, with the computer >> sight unseen. >> >> Before, you could write directions - or even a script - which just >> referenced 'eth0' and/or 'wlan0', and hand the result out >> Internet-wide, with assurance that it would work reli
Re: New nomeclature of ethernet devices
On Tue 25 Jun 2019 at 19:51:53 (-0400), The Wanderer wrote: > On 2019-06-25 at 09:28, Michael Stone wrote: > > On Tue, Jun 25, 2019 at 08:46:28AM -0400, The Wanderer wrote: > >> On 2019-06-25 at 08:11, Michael Stone wrote: > > >>> It isn't because: 1) the new names are predictable but not > >>> constant, so you can't configure a single default across all > >>> systems > >> > >> Which seems reasonable to describe as "unpredictable". > > > > They're perfectly predictable for a given system. > > And reasonably unpredictable between systems. I think you should understand that "predictable" means capable of being predicted. It doesn't mean you necessarily have the information at hand to make that prediction. Someone who works on PC buses would be in a better position. My zodiac sign is predictable, depending only on my birthday. But you can't tell me which. > Just reiterating the case where they *are* predictable misses my point > so badly that it almost seems as if it must be intentional. > > > The old names also weren't constant, but people didn't seem to care > > as much about the nuances because "that's the way it's always been". > > (Sometimes it was an eth, sometimes it was a wlan, etc.) Why were > > those differences ok but these differences aren't? Familiarity. > > No, not just familiarity. > > To the best of my awareness, the old names were 100% constant, as long > as you had no more than one interface *of a given type*. By "type" I take it you mean ethernet or whatever. Well, no, if you added a faster card, or one in a more "privileged slot", it would grab eth0 at the next boot, and your old one would become eth1. That's in the distant past. In more recent times, the new one would become eth(N+1). But here the problem was that each new card you added would itself become eth(N+2), eth(N+3) etc, even if you were removing the old ones. That's because udev was busy populating /etc/udev/rules.d/70-persistent-net.rules with all the MACs it had ever caught sight of. > And because you have to deal differently with interfaces of different > types (wireless interfaces need different userspace software from what > you need for wired ones), naming them differently - but still > predictably, in the same sense as before wireless interfaces ever > existed - was useful, because it let you easily distinguish which ones > needed which type of handling. That's just not true. Here's a PC with a ethernet and wireless interfaces running jessie: 2: eth1: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0e:35:3f:68:7c brd ff:ff:ff:ff:ff:ff inet 192.168.1.10/24 brd 192.168.1.255 scope global eth1 valid_lft forever preferred_lft forever inet6 fe80::20e:35ff:fe3f:687c/64 scope link valid_lft forever preferred_lft forever 3: eth0: mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 00:c0:9f:44:15:b5 brd ff:ff:ff:ff:ff:ff > With the new names, the fact that two interfaces get different name > prefixes (etc.) tells you basically nothing useful about how to handle > them; it just exposes underlying hardware details of some kind, which > you don't actually need to know in order to make effective use of those > interfaces. Eh? Here's the same PC running stretch's netboot installer: 3: wlp2s4: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0e:35:3f:68:7c brd ff:ff:ff:ff:ff:ff 4: enp2s2: mtu 1500 qdisc mq qlen 1000 link/ether 00:c0:9f:44:15:b5 brd ff:ff:ff:ff:ff:ff I'm guessing it's the p2s4 stuff that offends you. But the point is that to know what the interface is called, you should ask the system, not just make it up in some "traditional" manner. > >> On a single computer with any number of interfaces of any type, the > >> new names are 100% predictable from one boot to the next. (At least > >> assuming you don't change which slot a given network device is > >> connected to; IIRC that can change the assigned name, in at least > >> some cases.) > > > > That does change the name, that's the entire point. > > With no real benefit as far as I can tell, but yes. Well, the obvious one is that you can label the slots at the back if you have several cables to plug in. Not something many of us do, but now it's possible for those that want it, as opposed to impossible (or very risky). > It's also rare even on servers, much less on end-user systems (which > tend to have the network device hardwired into the motherboard, as often > as not). I only included that line for completism's sake - and > apparently it even misses a few cases where things can change even > without doing that, at least one of which I hadn't even considered. I'm still running one PC with just a NIC (Seattle 2 mobo). I'm sure I'm not alone. That's one of the virtues of linux: prolonging the useful life of aging hardware. > >> Computers with multiple interfaces of the same type are, AFAIK > >> always have been, and IMO are likely to always be, much less common > >> t
Brother DCP-1510 drivers wipe /opt on install
Greetings, The Brother DCP-1510 printer drivers etc installer wiped /opt except for it self . The same as over four years ago. One shudders to think that one actually pays them to produce that. The instructions to do before running the installer use two commands which are not to be found on the system or repository; lppasswd and aa-complain. Did none of the pre-install instructions. The installer ran to completion. It did install three 32 bit libraries for c and c++ . The test page printed ok. frank.jan...@actrix.gen.nz, ZL2TTS
Re: New nomeclature of ethernet devices
On 6/26/19 10:23 PM, David Wright wrote: Wait a minute—you haven't paid attention to the new names yet you're already arguing here that they shouldn't be the default? I thought the naming changes (virtual IP addresses) were to benefit cluster management, fencing and nodes, so you could have live backup schemes and redundancies. ?? Ric
