Re: Distros: The Gourmet Food Of GNU/Linux

09.08.2026 07:41, Leroy H wrote:
> On Sun, 9 Aug 2026 07:00:35 +0500, Stanislav N. aka pztrn wrote:
> 
>>
>> You just said that Arch is a pile of garbage. That means you hate it somehow.
>>
> 
> Arch is just another mainstream distro and ALL mainstream distros
> are garbage.
> 
> Furthermore, "hate" is the inappropriate term.  I have a professional
> and rational detestation for such mainstream distros.
> 

And how many distros you have built from scratch and how many of them are in use by users other than you?

>>
>> I was using Gentoo for so long and love it too, despite on fact that
>> I either build GENERIC_DISTRO_NAME kernel by using all drivers as modules
>> OR compile drivers within kernel.
>>
> 
> You have the option to build the kernel yourself, independent of the
> Gentoo tree and thereby avoid all such issues.
> 
> The fault is entirely YOURS, and not with Gentoo.
> 

There is nothing to "avoid", I built my kernel from Gentoo tree and it was running fine. I do not understand to what you trying to appeal here. I was able to build vanilla kernel, with gentoo patches and with dozen other patches like Zen. Why should I do that without using Portage to manage kernel's sources if I can?

> 
>>
>> But after some time I realized that I have work to do, not to recompile
>> whole world because GCC upgrade.
>>
> 
> ???????????
> 
> There is no reason to recompile world due to a GCC update.
> 
> You are totally mistaken.

So libc update doesn't requiring world rebuild? Whoah, how did they managed it?

(of course I mean upgrading to new major version which will produce ABI-incompatible libraries and of course not stage4 rebuild but only those packages that requires libc in that example, but you should know that, right?)

> 
>>
>> Arch is great if you want vanilla software (almost, with MUCH FEWER patches
>> applied than in any other distro) but do not want to hassle with compilation.
>>
> 
> Let us examine the distributed Arch "bash" program, which is located here:
> 
> <https://archlinux.org/packages/core/x86_64/bash/>
> 
> Let us use the "checksec" utility to examine how it was built in terms of
> "security" features:
> 
> <https://github.com/slimm609/checksec>
> 
> 
> Here is the checksec output:
> 
> RELRO       Stack Canary  CFI          NX          PIE          RPATH     RUNPATH     Symbols     SafeStack           Stack Clash  W^X Seg  Selfrando     Sanitizers  FORTIFY Lvl  GLIBCXX Assert  FORTIFY  Fortified  Fortifiable  Name
> Full RELRO  Canary Found  SHSTK & IBT  NX enabled  PIE Enabled  No RPATH  No RUNPATH  No Symbols  No SafeStack Found  No Probes    Enabled  No Selfrando  None        Unknown      Unknown         Yes      12         17           ./bash
> 
> 
> In stark contrast, here is the checksec output on my customized Gentoo
> bash:
> 
> RELRO     Stack Canary     CFI                NX          PIE           RPATH     RUNPATH     Symbols     SafeStack           Stack Clash  W^X Seg  Selfrando     Sanitizers  FORTIFY Lvl  GLIBCXX Assert  FORTIFY  Fortified  Fortifiable  Name
> No RELRO  No Canary Found  NO SHSTK & NO IBT  NX enabled  PIE Disabled  No RPATH  No RUNPATH  No Symbols  No SafeStack Found  No Probes    Enabled  No Selfrando  None        Unknown      Unknown         No       0          12           /bin/bash
> 
> 
> Notice the extreme difference.  The "RELRO," "Stack Canary," "CFI,"
> "PIE," and "Fortify" fields are enabled in Arch but disabled in my
> custom Gentoo build.  This is an extremely significant difference
> and it indicates that Arch is garbage and junk.
> 

Sorry, but:

- RELRO is a relocation of critical things like GOT (Global Offset Table) to read-only memory so other processes cannot change it and inject own code into control flow.
- Stack Canary essentially is buffer overflow protection mechanism. Attacker will be unable to write something to memory outside of designated buffer and eventually won't hack you.
- CFI is "Control Flow Integrity", so attacker won't be able to inject bad things in it and overtake application's control flow.
- PIE is "Position-Independed Executables". These executables on startup will be loaded in random memory location to harden defense against attackers who tries to change memory bytes. Part of ASLR mechanism.
- Fortify is FORTIFY_SOURCES, a mechanism that tries to prevent buffer overflows and string format injections (and some other attack vectors).

Are you REALLY sure that YOUR bash binary is more secure than in Arch? It is more likely you've tried to get most from your system's performance and deliberately disabled some protection measures that kind-of eat it.

-- 
WBR, Stanislav Nikitin a.k.a. pztrn.