Re: Distros: The Gourmet Food Of GNU/Linux

09.08.2026 09:11, Leroy H wrote:
> On Sun, 9 Aug 2026 08:39:57 +0500, Stanislav N. aka pztrn wrote:
> 
>>
>> And how many distros you have built from scratch and how many
>> of them are in use by users other than you?
>>
> 
> That's the whole purpose of GNU/Linux.  Is is not?
> 
> Every installation is different and unique to the individual
> that builds it.  GNU/Linux allows nearly infinite configuration
> possibilities and can accommodate any need.
> 
> I deeply pity those poor fools that can only depend on a one-size-fits-all
> distro.

It is great you have so much time for that.

> 
> 
>>
>> There is nothing to "avoid", I built my kernel from Gentoo tree and it was running fine.
>>
> 
> Then don't complain.
> 

I am not. It is you trying to complain.

> 
>>
>> So libc update doesn't requiring world rebuild? Whoah, how did they managed it?
>>
> 
> No, it does not.  I just built the newly released glibc-2.44 (it only requires
> three minutes) and NOTHING needed to be rebuilt.  NOTHING.
> 
> You are entirely mistaken.
> 
> The GLIBC folks do not ever break user space.
> 

Good they finally managed to do that!

What about gcc update? :)

> 
>>
>> - 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.
>>
> 
> Ha, ha, ha, ha, ha, ha, ha!
> 
> I operate a standalone desktop workstation and such "security" concerns
> are totally irrelevant as well as being a serious detriment to performance.
> 

Lets see what will you say when your data will be stolen via chained exploit when you enter your entertaining website.tld with "special" banner of javascript injection. Or when you'll became a part of botnet. AIDE is working on your side, right? Or you adopted something like ostree to make your system and important binaries/libraries immutable? You wrote BPF program that will reject suspicious packets BEFORE they processed by kernel or network card module? Are you killing unknown processes automatically?

> I understand hardware from logic gates on up (but you don't) and such "security"
> crap is ludicrous in the extreme.

Is your path "security by obscurity"? :)

And if you understand hardware logic - what next 5 vulnerabilities in Intel/AMD will be discovered?

> 
> Please do not respond further.  It is obvious that your technical knowledge
> is highly deficient and I surely cannot waste my time attempting to explain
> digital fundamentals to someone like you.
> 

Instead of being so offensive you should try to explain your POV without any offense. And maybe your words won't sound so stupid and selfish. It is unprofessional ¯⧹_(ツ)_⧸¯.

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