<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 12, 2022 at 9:56 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/11/22 11:10, enh wrote:<br>
>> The next version of centos does not exist. Apparently Centos has completely gone<br>
>> away. Right, I can stop caring about it then I guess?<br>
> <br>
> (that was my reaction to the recent news, yes. "fine by me", since<br>
> centos was _always_ the most problematic distro to support, probably<br>
> because it naturally attracted the kinds of folks who _wanted_ to run<br>
> stuff from a decade ago.)<br>
<br>
I can move from 7 years to 10 if there's specific demand for it,  but 7 was<br>
based on a lot of experience and a certain amount of research. It's enough<br>
Moore's Law half lives to get you down to about 2% of the installed base, but<br>
it's ALSO where expertise in the old stuff seems to drop out of living memory.<br></blockquote><div><br></div><div>(i think i've said before, but _our_ plan is to ditch glibc for musl on the host, so we can just statically link and forget about _libc_ problems. what i don't know [because historically we've used glibc] is the extent to which these kinds of users are relying on glibc trying to work around missing stuff on old kernels. aiui glibc pretty much always tries, musl tries in some cases, and bionic basically never tries. so there might be some fallout there still, but i have no data yet. given that linux is free, kernel vulnerabilities are rife, and most modern hardware supports virtualization, i'm not _super_ sympathetic to running old software. i have a lot more sympathy for running old hardware, but as someone who's running current ubuntu on an 11 year old laptop ... i'm unconvinced i'm actually _helping_ people by making it easier to stay on ridiculously old versions of linux. 7 years is more than enough.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The old "mirror being 7 years bad luck" was from medieval observations about<br>
people recovering from old traumas, changing behavior, and moving on with their<br>
lives: that's approximately the time it takes a socializing group of humans to<br>
collectively stop reacting to a cause that's no longer present. From a technical<br>
perspective, it means past that point the relevant domain experts are no longer<br>
immediately available. People can dig up and recreate the old ways if you track<br>
down an ex-expert willing to put in some time, but most of them won't have the<br>
answers off the top of their head anymore. They've stopped exercising it,<br>
nobody's regression testing it, have to dig something out out of a box...<br></blockquote><div><br></div><div>yeah, testing's hard enough already without saying "any version of any distro shipped in the last 10 years"!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Yeah yeah, nebulous social community stuff, but that's important too. Those last<br>
3 years of support in the 10 year time horizon are the most painful for a<br>
REASON. (Somebody could totally do a thesis/dissertation on this if they wanted<br>
to...)<br>
<br>
>> If this does actually break somebody, I can have portability.h do:<br>
>> #if version < thingy<br>
>> #define _Noreturn __attribute__((__noreturn__))<br>
>> #endif<br>
>><br>
>> But I'd rather wait for a complaint?<br>
>><br>
>> (Also, when I try to build older versions with CFLAGS=--std=c99 to see where c11<br>
>> leaked in, even 0.8.0 won't build because of random failures like<br>
>> CLOCK_MONOTONIC isn't defined? Looks like gcc/glibc is being intentionally<br>
>> obstructive again. I'd rather not micromanage this the same way I refuse to<br>
>> #define gnu to get stuff out of the headers: that way lies madness...)<br>
> <br>
> interesting, i don't see that for the android build, but maybe we just<br>
> don't build that stuff for the host. (bionic's always [well, "since i<br>
> inherited it"] taken the attitude that you get all the things, all the<br>
> time.<br>
<br>
I suspect it would work if I said "gnu99" instead of "c99", but that defeats the<br>
purpose of the exercise. (The gnu guys keep forcing you to #define gnu to get<br>
wrappers for Linux system calls that the kernel guys introduced, like "man 2<br>
unshare". It has nothing whatsoever to do with gnu, never did, but the glibc<br>
guys are political propagandists.)<br></blockquote><div><br></div><div>(to be fair, gnu11 and gnu++14 are the _gcc_ political propagandists, not glibc :-) )</div><div><br></div><div>and, yeah, today's current gcc and clang both default to "gnu17" for C.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That said, using the musl toolchain --std=c99 sort of builds-ish, and I can see<br>
that typeof() showed up in commit 5a159cceb in 2017, but to test anything that<br>
old I need commit 78289203031a backported (fixing the config2help segfault in<br>
newer toolchains)...<br>
<br>
Yes, the last commit that builds with --std=c99 is commit 77f9c7700604 in May<br>
2017, because commit 5a159cceb introduced use of typeof(), a c11 feature.<br>
<br>
That was slightly/technically wrong of me (because 7 year time horizon, only<br>
about 5 and 1/2 years at the time), although the old toolchains I regression<br>
tested against already had typeof() support in their default standards (as an<br>
extension), so it still built on the old versions, even ones that predated the<br>
c11 standard; it was a widely available compiler extension (like a ? : b meaning<br>
a ? a : b) before it was standardized.<br>
<br>
Anyway, design.html says c11 now. I should probably have about.html mention it<br>
too, but I'm trying to redo the web page so "about.html" is the default landing<br>
page instead of news.html, and move the intro paragraph at the start of<br>
news.html into header.html so it's on all the pages, but about.html has its own<br>
version and moving it into the header completely screws up the flow of the first<br>
section of the about page requiring a largeish rewrite. :P<br>
<br>
> there's very little [though admittedly non-zero] value to being<br>
> able to fine-tune your standard version, but that's _far_ too<br>
> confusing for most developers. "it just works" minimizes our support<br>
> burden, and we have an orthogonal "what version of Android do you want<br>
> this to _run_ on?" problem that's more than enough cognitive load for<br>
> everyone.)<br>
<br>
This is why I puppy-eyed Rich into adding _ALL_SOURCE to musl. Just give me all<br>
the darn symbols the C library is providing.<br>
<br>
>> > given that `_Noreturn` is required to be at the start, i kind of wish<br>
>> > they'd made it imply `void`; `noreturn void` seems a bit redundant!<br>
>><br>
>> stdnoreturn.h does literally nothing except #define noreturn _Noreturn<br>
> <br>
> yeah, but like i said yesterday --- that's how you have your "sensible<br>
> keyword [noreturn]" cake and also eat "don't break existing code<br>
> [no-one's using _Noreturn]".<br>
<br>
C99 (and possibly earlier) explicitly reserved _[A-Z] as a future expansion<br>
namespace. (C99 section 7.1.3, "All identifiers that begin with an underscore<br>
and either an uppercase letter or another underscore are always reserved for any<br>
use.") The problem is that means all new things they add in future can only have<br>
_Stupid _Names... And yet typeof() didn't!<br>
<br>
  int main(int argc, char *argv) { typeof(argc) x = argc+1; return x; }<br>
<br>
Compiles just fine without #including a single header. They added a keyword<br>
outside of any reserved namespace for THIS, but not for noreturn, and this is<br>
why I'm complaining. They are hypocrites.<br>
<br>
Toolchain version upgrades break stuff. This is sadly not avoidable. The 7 year<br>
horizon thing gives people time to adapt, but anybody who adds -Werror to their<br>
build scripts voluntarily gives up the right to complain about "apt-get update<br>
du jour broke my build" happening at least annually, let alone major version<br>
upgrades that swap --std defaults...<br></blockquote><div><br></div><div>(unfortunately, the people who add -Werror to their build flags do not believe that. things like -Wall are worse, because that set changes over time, and if you're using -Werror, you just made that the problem of the toolchain team who're just trying to upgrade the compiler...)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> if you look at the git history _for<br>
> toybox_ you can see that Apple's *headers* were already using<br>
> `noreturn`, and that's why toybox had to have<br>
> __attribute__((__noreturn__)) rather than __attribute__((noreturn))<br>
> :-)<br>
<br>
When there is a standard guaranteeing us a feature, we might as well use the<br>
standardized feature. (I still pick and choose standards, ala LP64 instead of<br>
int_least8_t and int_fast8_t and intmax_t and so on.)<br>
<br>
In this project, I tend to want to peel back gratuitous wrappers and understand<br>
what it's actually doing. When I don't care about the underlying implementation,<br>
I use something like Python/Lua/Bash instead of c. :)<br>
<br>
Rob<br>
</blockquote></div></div>