From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C34EE158083 for ; Wed, 25 Sep 2024 01:42:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E2C09E29C0; Wed, 25 Sep 2024 01:42:28 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 84AE3E29B0 for ; Wed, 25 Sep 2024 01:42:28 +0000 (UTC) Message-ID: <6af6d0dd-f081-4345-b574-ea6d6c9358bb@gentoo.org> Date: Tue, 24 Sep 2024 21:42:23 -0400 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [gentoo-user] Wayland! Beware of! To: gentoo-user@lists.gentoo.org References: <65e5de50-e053-46ff-be61-52f472d95025@gentoo.org> Content-Language: en-US From: Eli Schwartz Autocrypt: addr=eschwartz@gentoo.org; keydata= xjMEZmeRNBYJKwYBBAHaRw8BAQdAYNZ7pUDWhx1i2f3p6L2ZLu4FcY18UoeGC04Gq/khqwfN I0VsaSBTY2h3YXJ0eiA8ZXNjaHdhcnR6QGdlbnRvby5vcmc+wpYEExYKAD4WIQTvUdMIsc4j CIi+DYTqQj6ToWND8QUCZoRL+gIbAwUJBKKGAAULCQgHAwUVCgkICwUWAgMBAAIeBQIXgAAK CRDqQj6ToWND8aB5AP9r4kB691nNtNwKkdRiOdl7/k6WYzokvHvDamXxRJ0I+gEAjZqR5V8y mfR3fy2Z+r2Joeqdt3CIv5IwPs64spBvigLOOARmZ5E0EgorBgEEAZdVAQUBAQdATT46Z06b 1X9xjXFCYFxmq/Tj3tSEKZInDWTpoHQp4l8DAQgHwn4EGBYKACYWIQTvUdMIsc4jCIi+DYTq Qj6ToWND8QUCZmeRNAIbDAUJBKKGAAAKCRDqQj6ToWND8a2RAP40KPfbfoiZAJW5boFmFJ3G TUBDJRh9CWHyaPqq2PN+0wD/R07oLzfnJUN209mzi9TuTuHjeZybysyqXSw4MAxkMAY= In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------pODjRP4T000IomMOlD6SyOE8" X-Archives-Salt: c157129d-1d5a-43d9-b67b-7f632b583042 X-Archives-Hash: 65a581a580ecbfb7022a3fd71c2393e1 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------pODjRP4T000IomMOlD6SyOE8 Content-Type: multipart/mixed; boundary="------------6dPlKfHaEukvQcn0fGMerenH"; protected-headers="v1" From: Eli Schwartz To: gentoo-user@lists.gentoo.org Message-ID: <6af6d0dd-f081-4345-b574-ea6d6c9358bb@gentoo.org> Subject: Re: [gentoo-user] Wayland! Beware of! References: <65e5de50-e053-46ff-be61-52f472d95025@gentoo.org> In-Reply-To: --------------6dPlKfHaEukvQcn0fGMerenH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9/24/24 6:00 PM, Walter Dnes wrote: > On Mon, Sep 23, 2024 at 05:11:14PM -0400, Eli Schwartz wrote >=20 >> Do you have that little faith in the Gentoo Developers, that you >> think we'd make a USE flag change that made everyone's systems >> suddenly break? >> >> :( >=20 > I was around way back when "ipv6" became the default. I was using > Firefox back then. Type in a URL; Firefox spins its wheels for 60 > seconds in IPV6; it finally gives up and drops down to IPV4. This > happened with every URL. Please do not disable the USE=3Dipv6, as that is *utterly* insane. It als= o does approximately nothing. In packages which support this USE flag, which is rare, it causes the code to use old, untested APIs which only support ipv4, rather than new, tested APIs that support ipv4 and ipv6 equally well while having the benefit of being stable, reliable and efficient. These old deprecated codepaths are prone to crashing and segfaulting because the codebase for it is not enabled by anyone and the original implementations are only kept around for the benefit of e.g. ancient static binaries that cannot be rebuilt. USE=3Dipv6 does not mean "ewww, evil bloated ipv6 socket functions". It has NO influence on whether you use ipv4 or ipv6 traffic, as the vast majority of the software you use doesn't even support the option, they simply use maintained functions that just ask the kernel to give you some internet traffic. If you actually want to disable ipv6, instead of insanely rebuilding binaries to use untested broken segfaulting code, use the sysctl knob to tell the kernel "when asked to give some application a bit of internet traffic, don't use ipv6". net.ipv6.conf.all.disable_ipv6 This will: - actually work - work with applications that unconditionally use non-deprecated generic socket APIs - not crash when running untested code, because the code is actually tested Believe you me -- I am **very** aware of the painfulness inherent in applications trying ipv6, failing, not knowing they cannot use ipv6, and eventually timing out. I historically solved it with the sysctl because my ISP had broken/nonexistent ipv6, I continue to solve it with the sysctl when my network cannot handle ipv6, and I will solve it with the sysctl in the future when my network cannot handle ipv6. I do not "solve" ipv6 by building 0.05% of my applications with crash-prone APIs just because those APIs are also so old they predate ipv= 6. The new APIs support ipv4 quite well; use them. I'm sorry to hear you "broke" your own system through your own stubborn ignorance. At no point did Gentoo developers ever break your ipv4, you are imagining it. > After that I ran with USE=3D"-* yada yada yada" for quite some time. > Currently, I'm less extreme, merely disabling a bunch of USE flags... >=20 > USE=3D"X apng ffmpeg introspection jpeg opengl openmp png truetype x264= x265 xorg threads vala -acl -caps -clang -context -elogind -filecaps -gr= aphite -gstreamer -haptic -iptables -ipv6 -libav -llvm -manpager -pam -se= ndmail -spirv -tofu -su -udisks -upower -wayland" >=20 > The "szip" and "xinerama" USE flags seem to have disappeared. That's quite the bloated collection of enabled USE flags you have there -- lots of stuff that are much more bloated than ipv6, in fact. :) And really, you despise app-text/manpager with such ferocity that you have to set a global USE for it lest a second program come to add that US= E? You hate /usr/bin/su so much that it's simply intolerable that util-linux might build it? But support for animated PNG files is too precious and dear to you, that feature you absolutely have to have. Oh no, the bloat! We will be buried under it! =2E.. But using a tested ipv4 codepath instead of an untested ipv4 codepath is too much bloat for you, so you'd rather the crashes and the segfaults. Brilliant. > And who can forget the move from /dev/hda hdb hdc etc., to /dev/sda > sdb sdc etc.? Machine literally unbootable on the newly compiled > kernel. Fortunately, I always have "Production" and "Experimental" > kernels. The newly compiled kernel is always "Experimental". If thing= s > go badly, I drop back to the "Production" kernel and try to figure out > what went wrong. Only after a long while do I execute my "promote" > script that copies "Experimental" over top of "Production". That's quite the long-term grudge you have there. "Who can forget" it indeed. ;) How about: pretty much everyone. What a tempest in a teapot. (Even if I took this rant seriously, that wasn't anything the Gentoo developers did. What's your proposed remediation, stay on the earlier editions of kernel 2.6 for another 15 years because "that newfangled 2.6 kernel man, that's just totally breaking my system"?) Your kernel testing and rotation management is boringly plebeian, as it's what approximately every other Gentoo system does by default without any configuration needed. --=20 Eli Schwartz --------------6dPlKfHaEukvQcn0fGMerenH-- --------------pODjRP4T000IomMOlD6SyOE8 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZvNqfwUDAAAAAAAKCRCEp9ErcA0vV6Vc AQDO4IZ7sD7pwhZJzidixSL7+tQK6wuhPbiXyp6/8MwSeQEAsz0KI0ylW3U+DBGZ0RD/XdQMXwP9 19erDKERxfRA1g0= =aQAa -----END PGP SIGNATURE----- --------------pODjRP4T000IomMOlD6SyOE8--