Re: removing toxic emailers
On Sat Apr 17, 2021 at 7:21 AM BST, Chris Punches wrote:
> I've lived in most states in the US and can confirm exclusionary
> regional cultures not only exist but are more common than the absence
> of them.
>
> You might not see it in Sioux City, but you'll see it in LA, you'll see
> it in Dallas, Bangor, Miami, Baton Rouge, Chickasha, pretty much
> anywhere you travel to will have that, and some of their elements
> aren't pretty -- they do have one thing common among all of them --
> they are aversive to each other based on perceived lifestyle, legacy,
> and value system superiority.
>
> California culture has earned theirs as much as any of the other US
> regions have. I would find it difficult to believe that someone who
> didn't notice that had actually been to these places and examined for
> this -- it is no secret, and many people in those places generally
> pride themselves over it.
>
> I think there may be a tendency in some academic communities to ignore
> or marginilize the prominnence in their worldview the parts of society
> that do not fit within their value systems as well.
I wasn't even implying that these cultures are 'good' or 'bad', just
that they exist and differ from the various regional cultures which
exist all over the world. I think people were quite touchy at my line
of questioning. I recognise that there are differences between i.e.
LA and Seattle or SF and NY, but those differences pale in comparison
to the differences between Moscow and LA, Beijing and NY, or Sydney
and SF -- and those are all still large international cities.
The fact that over 50% of the SC is based in (probably?) urban North
America should give pause to some humility that it may not represent
the truly global nature of hackerdom. On a technical front this isn't
important, but if you're trying to impose *culture* on a global group,
it might be useful to remember that you have a steering group in which
over 50% of its members represent urban North America, but in the
world, only about 2% of the population live in urban North America.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
> I wasn't even implying that these cultures are 'good' or 'bad', just > that they exist and differ from the various regional cultures which > exist all over the world. I think people were quite touchy at my line > of questioning. I recognise that there are differences between i.e. > LA and Seattle or SF and NY, but those differences pale in comparison > to the differences between Moscow and LA, Beijing and NY, or Sydney > and SF -- and those are all still large international cities. Give me a break Forsku. Could you care to share how you feel imposed upon or feel disenfranchised by this discussion not being sensitive to your culture? How does a code of conduct, or how would discouraging “micro-aggressions” disrespect your lived experiences or make it uncomfortable for you to contribute to GCC? > The fact that over 50% of the SC is based in (probably?) urban North > America should give pause to some humility that it may not represent > the truly global nature of hackerdom. On a technical front this isn't > important, but if you're trying to impose *culture* on a global group, > it might be useful to remember that you have a steering group in which > over 50% of its members represent urban North America, but in the > world, only about 2% of the population live in urban North America. As far as I understand it Chris Punches lives in North America. Only 2% of the world population lives in the US, indeed, most live in China. It’s interesting the unkind reaction Liu Hao received in this very thread when they encountered the arguments making a false equivalency of these proposals to their countries’ history. I’m sure he felt not great, being forced to either defend the CCP or not share their views on the questions of this conversation. What is even the argument you are making at this point? Aaron
Re: removing toxic emailers
On Sat Apr 17, 2021 at 9:27 AM BST, Aaron Gyes via Gcc wrote:
> Give me a break Forsku.
>
> Could you care to share how you feel imposed upon or feel
> disenfranchised by
> this discussion not being sensitive to your culture? How does a code of
> conduct,
> or how would discouraging “micro-aggressions” disrespect your lived
> experiences
> or make it uncomfortable for you to contribute to GCC?
I have no idea what "micro-aggressions" are other than what I read on the
news. It's not a concept that is known outside of a bubble in parts of the
United States. I have never lived in that bubble, it is not a term I have
ever heard face-to-face, therefore I have no idea whether it affects me or
not. I do know that I'd feel pretty uncomfortable signing up to not cause
something when I have no idea what it is.
I feel imposed upon when, as a volunteer, I'm expected to submit not just
my volunteered time but all of my time in every venue to your cultural
norms. This is not normal. Just because some of you are paid very nice
salaries to hack on free software doesn't mean all of us are.
> It’s interesting the unkind reaction Liu Hao received in this very
> thread
> when they encountered the arguments making a false equivalency of these
> proposals
> to their countries’ history. I’m sure he felt not great, being
> forced to either
> defend the CCP or not share their views on the questions of this
> conversation.
I didn't see that, but yes it's unreasonable to expect anyone to defend the
CCP (or any government for that matter) in order to contribute views to an
argument. Everyone should be encouraged to share their views on something
which is important to all of us: the wellbeing of GCC going forwards.
Language like "give me a break", btw, or expecting someone to explain how a
code of conduct which hasn't been written yet 'imposes' on them personally
is also not encouraging.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On Apr 17, 2021, at 1:36 AM, Frosku wrote: > I feel imposed upon when, as a volunteer, I'm expected to submit not just > my volunteered time but all of my time in every venue to your cultural > norms. This is not normal. Just because some of you are paid very nice > salaries to hack on free software doesn't mean all of us are. I don’t make a dime. I find it hard to imagine it would take you all of your time not to act like an asshole. Nobody has even asserted professionalism should be required of professionals. Yet you seem extremely uncomfortable with some bare minimum standards. I assumed as a technical, somewhat obsessive person, you have already Googled “microagressions”, imagined what they would be in the context of a major open source project, and what in-group and out-groups exist in this context, then came to some kind of conclusion that explains your hostility. Aaron
Re: removing toxic emailers
Hi Andrew and GCC, On April 17, 2021 5:04:55 AM UTC, Andrew Pinski via Gcc wrote: > On Fri, Apr 16, 2021 at 9:56 PM Frosku wrote: > > > > On Sat Apr 17, 2021 at 5:05 AM BST, Ian Lance Taylor wrote: > > > On Fri, Apr 16, 2021 at 4:16 PM Frosku wrote: > > > > > > > > When I refer to a 'California cultural standard', that's not > > > > prescriptive. It's just a reference to the fact that a *lot* of > > > > the SC live in California, and any culture prescribed by the > > > > steering committee will be overly influenced by that > > > > commonality. > > > > > > To the best of my knowledge, 2 of the 13 members of the GCC > > > steering committee live in California. > > > > And the rest of the west coast United States / New England? > > I count 5 which are not in the United States or Canada. And how many are affiliated with (controversial) US corporations (or their subsidiaries)? Here are the numbers: https://gcc.gnu.org/pipermail/gcc/2021-April/235285.html Ultimately the culture and behavious that you are trying to prescribe here, are those of US tech workplaces. The ones where "hiring for culture fit" was invented. A culture that works strongly against unions, for example. https://theintercept.com/2020/06/11/facebook-workplace-unionize/ Yes, the exact same Facebook that Nathan described here as "a joy because of the huge step towards gender equality amongst the engineers": https://gcc.gnu.org/pipermail/gcc/2021-March/235091.html Inclusive to some, but eager to exclude others for political reasons, as you see in Nathan's long request. We are talking about culture where people do NOT start a strike when a scientist like Timnit Gebru is fired for what she wrote in a paper and so on. Nor when Google doubled down by firing Margaret Mitchell. THIS is the culture you are trying to impose to global Free Software. Is this a culture that is safe for Free Software? To me, it's not. To Stallman, neither. Terry Davis? Nope. As for me, I have been depicted as a "jerk" and "concern troll" here. My contribution is unwelcome. My code is welcome, the problem is me. Because I refuse to bow down to US workspace moralism and hypocrisy. I'm a toxic emailer, right? But in fact, millions of people outside the US would feel excluded. And threatened. But we are all "jerks", right? Such culture is also dominated by RICH men, but it's unable to see the problem in term of global and local distribution of wealth and power and thus interprets it as a matter of sex, gender and race. Which is obviously totally fine for rich men, as it distract people's attention from the root of their power and won't really fix the problem. And it's also fine for most leaders in this activist space, because they can focus attivists' attention and outrage against easier preys, like Stallman. After all, it's easier to obtain corporate support (and money) if you problematize these issues instead of the distribution of wealth and power that causes them. They need to fight, but cannot afford to win. Giacomo
Re: removing toxic emailers
> I feel imposed upon when, as a volunteer, I'm expected to submit not just > my volunteered time but all of my time in every venue to your cultural > norms. Can you not imagine… some people have already felt that way for quite some time, and became excluded? That it is not a hypothetical for them? Aaron
Re: removing toxic emailers
On Fri, 16 Apr 2021, Frosku wrote: > In my view, if people employed by a small number of American companies > succeed in disassociating GCC from GNU/FSF, which is representative of > the free software grassroots community I find this insistant focus by some on "American companies" interesting - and quite pointless. And my passport is burgundy. It also is a completely unwarranted attack on the integrity of the maintainers, contributors, and other leaders of GCC. Regardless of the color of their passports. Personally I care about quality of what we ship, supporting our users, and upholding the principles of free software/open source. And I am willing to bet this applies to the vast majority of us. So please stop those unfounded allegations. Gerald PS: Our release managers, for example, are British (Joseph), Czech (Jakub), and German (Richi), IIRC. The majority of the FSF board, FSF leadership, and RMS himself are American from what I can tell.
Re: A suggestion for going forward from the RMS/FSF debate
Le 16/04/2021 à 19:06, Richard Kenner a écrit : >> The authority of the FSF, GNU and RMS over GCC is and has been a >> fiction for decades, > For the most part, I agree. > >> It would be usefull to clarify with the FSF and GNU what the >> actual relations are, > Why? What would that gain? I go back to my analogy of the British Queen. > What would be gained by "clarifying" that if she actually intervenes > non-trivially in the government of any Commonwealth nation, she'd lose > that power? There are differences between the queen and RMS, even if the image has some merit. For example, the UK remains a formal monarchy in part because the queen has better social skills than RMS. The supporters of software freedom in general are probably not in favour of a monarchy, even formal, even if they know their debt to RMS. Therefore, if the GNU project loves to keep this childish fictious power of the chief GNUisance, this doesn't prevent GCC to remain associated to the FSF. -- Didier
Re: removing toxic emailers
On Sat Apr 17, 2021 at 10:04 AM BST, Aaron Gyes via Gcc wrote:
> On Apr 17, 2021, at 1:36 AM, Frosku wrote:
> > I feel imposed upon when, as a volunteer, I'm expected to submit not just
> > my volunteered time but all of my time in every venue to your cultural
> > norms. This is not normal. Just because some of you are paid very nice
> > salaries to hack on free software doesn't mean all of us are.
>
> I don’t make a dime. I find it hard to imagine it would take you
> all of your time not to act like an asshole. Nobody has even
> asserted professionalism should be required of professionals.
>
> Yet you seem extremely uncomfortable with some bare minimum standards.
>
> I assumed as a technical, somewhat obsessive person, you have already
> Googled “microagressions”, imagined what they would be in the
> context
> of a major open source project, and what in-group and out-groups exist
> in
> this context, then came to some kind of conclusion that explains your
> hostility.
Aaron,
If you could kindly refrain from making repeated character attacks and
trying to imply that because I disagree with you on policy I must be
some kind of knuckle-dragging bigot, that would be a really good start
to having a productive discussion. Perhaps instead of talking about
whether I'm "obsessive", want to "act like an asshole", etc we can
pretend we've been through that tiring exercise and discuss substance.
My "hostility" to codes of conduct is that I have little confidence that
they would be applied evenly (in which case, the way you've spoken to me
thus far would surely not be considered proper conduct as you've taken
little time to drop to the level of ad hominem attacks and implications)
and would instead be used as a battering ram against people who are a)
neurodivergent and struggle with social norms or b) are from different
cultures which are more direct in communication style.
It's all well and good to talk the talk of diversity and inclusion, but
it seems to me that what's actually achieved is locking out some of the
most isolated and vulnerable people -- who have found a home in our
community -- in order to make some of the most privileged people in
society more comfortable. *That* is the source of my hostility to what
I believe is for the most part a noble but misguided proposal.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
Beware with what you desire, Frosku. On April 16, 2021 11:15:57 PM UTC, Frosku wrote: > > I can't speak for others, but for me at least, replacing ties with GNU > with ties to another well-respected (non-corporate) entity in the free > software world like Debian or the Apache foundation would go a long way in > allaying my worries about this shift. Pretending to defend Free Software is way cheaper that to actually defend it. In particular against a Google employee that violate GPL during his working hours. https://gcc.gnu.org/pipermail/gcc/2021-March/235224.html Giacomo
Re: removing toxic emailers
On Sat Apr 17, 2021 at 10:08 AM BST, Aaron Gyes via Gcc wrote:
> > I feel imposed upon when, as a volunteer, I'm expected to submit not just
> > my volunteered time but all of my time in every venue to your cultural
> > norms.
>
> Can you not imagine… some people have already felt that way for quite
> some
> time, and became excluded? That it is not a hypothetical for them?
>
> Aaron
Absolutely, and we should find ways to re-include them without swapping
their exclusion for the exclusion of other vulnerable people.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On Sat Apr 17, 2021 at 10:29 AM BST, Giacomo Tesio wrote:
> Beware with what you desire, Frosku.
>
> On April 16, 2021 11:15:57 PM UTC, Frosku wrote:
> >
> > I can't speak for others, but for me at least, replacing ties with GNU
> > with ties to another well-respected (non-corporate) entity in the free
> > software world like Debian or the Apache foundation would go a long way in
> > allaying my worries about this shift.
>
> Pretending to defend Free Software is way cheaper that to actually
> defend it.
> In particular against a Google employee that violate GPL during his
> working hours.
>
> https://gcc.gnu.org/pipermail/gcc/2021-March/235224.html
What I desire is that GCC stay a part of GNU, a project that exists solely
to create a free operating system for the entire world to use. What I fear
most is a GCC steered by essentially a monoculture of paid big-tech coders
with no input from the free software community or GCC's non-corporate
users. Therefore, if a childish and ultimately unwarranted split is to
happen, it should be with the oversight of an organization friendly to free
software values. Not Google and not Facebook.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On Sat Apr 17, 2021 at 10:08 AM BST, Giacomo Tesio wrote:
> But in fact, millions of people outside the US would feel excluded.
> And threatened. But we are all "jerks", right?
>
> ...
>
> Such culture is also dominated by RICH men, but it's unable to see the
> problem in term of global and local distribution of wealth and power
> and thus interprets it as a matter of sex, gender and race.
>
> Which is obviously totally fine for rich men, as it distract people's
> attention from the root of their power and won't really fix the problem.
Did you ever notice that income group (in a global sense) is never a
protected characteristic in these COCs which proclaim to defend the
disenfranchised and the disadvantaged? It would seem to me that low income
is the greatest predictor of disadvantage globally.
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
Hi Gerald,, On April 17, 2021 9:09:19 AM UTC, Gerald Pfeifer wrote: > On Fri, 16 Apr 2021, Frosku wrote: > > In my view, if people employed by a small number of American > companies > > succeed in disassociating GCC from GNU/FSF, which is representative > > of the free software grassroots community > > I find this insistant focus by some on "American companies" > interesting - and quite pointless. And my passport is burgundy. So much that in fact, we are talking about some of the most controversial corporation in the whole world. And while we are talking about "toxic emailers", it's not lost to me the irony that all this divisive debate about inclusive and righteous behaviour started with an email of a Facebook employee that defines working in Facebook "a joy". https://gcc.gnu.org/pipermail/gcc/2021-March/235091.html Yeah the same Facebook that still does what Cambridge Analytica used to. > It also is a completely unwarranted attack on the integrity of the > maintainers, contributors, and other leaders of GCC. Regardless of > the color of their passports. This is a strawman. People are just concerned about the undue influence that these controversial corporations can have on GCC through the influence they have on their employees. It would be overly naive to pretend that the Steering Committee members' are not influenced by their affiliations, even if we were not talking about the champions of surveillance capitalism. And this has nothing to do with their integrity. Why should they have declared such affiliations in the SC's web page, if they were irrelevant? Because they acknowledge that their affiliations have a non-negligible influence on what they do and what they do not. Also this has nothing to do with their passports. In fact, as you say, > The majority of the FSF board, > FSF leadership, and RMS himself are American from what I can tell. It was Nathan who framed his request in term of culture, politics and whiteness and priviledge... And since the GCC Steering Committe did what he requested, we have to assume that these are the kind of arguments that we have to debunk, providing you with a more varied perspective. But unfortunately you keep invalidating our perspective because... we are "jerks". Giacomo
Re: removing toxic emailers
在 17/04/2021 16.27, Aaron Gyes 写道: As far as I understand it Chris Punches lives in North America. Only 2% of the world population lives in the US, indeed, most live in China. It’s interesting the unkind reaction Liu Hao received in this very thread when they encountered the arguments making a false equivalency of these proposals to their countries’ history. I’m sure he felt not great, being forced to either defend the CCP or not share their views on the questions of this conversation. What is even the argument you are making at this point? The history is written with many coincidences. Something is there just because it happened, while other didn't. I don't see anything wrong why a moderate number of all developers are from the US: Because modern computers were invented by American people. It's simply that people who contribute more deserve more, and who contribute less deserve less. That's fair. It's a natural law. There is no reason to go against that. -- Best regards, Liu Hao OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
On Thu, Jan 21, 2021 at 1:42 PM Fangrui Song wrote: > > On 2021-01-21, H.J. Lu via Gnu-gabi wrote: > >On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote: > >> > >> 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI > >> > >> #define GNU_PROPERTY_UINT32_AND_LO 0xb000 > >> #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff > >> > >> A bit in the output pr_data field is set only if it is set in all > >> relocatable input pr_data fields. If all bits in the the output > >> pr_data field are zero, this property should be removed from output. > >> > >> If the bit is 1, all input relocatables have the feature. If the > >> bit is 0 or the property is missing, the info is unknown. > >> > >> 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI > >> > >> #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 > >> #define GNU_PROPERTY_UINT32_OR_HI 0xb000 > >> > >> A bit in the output pr_data field is set if it is set in any > >> relocatable input pr_data fields. If all bits in the the output > >> pr_data field are zero, this property should be removed from output. > >> > >> If the bit is 1, some input relocatables have the feature. If the > >> bit is 0 or the property is missing, the info is unknown. > >> > >> The PDF is at > >> > >> https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf > >> > >> -- > >> H.J. > > > >Here is the binutils patch to implement it. > > > >-- > >H.J. > > Hi, H.J. > > Thank you for CCing llvm-dev:) In the past various GNU ABI proposals > went unnoticed by LLVM folks who don't happen to subscribe to GNU lists. > (A lot! I personally subscribe to some lists and check the discussion > just in case I miss something important:) ) > > I have researched a bit and observed that the following GNU_PROPERTY > values are currently used by compilers/linkers: > > Bitwise OR for relocatable links. Bitwise AND for executable/shared > object links. > > * GNU_PROPERTY_X86_FEATURE_1_AND = GNU_PROPERTY_X86_UINT32_AND_LO + 0, > * used by Intel Indirect branch tracking and Shadow Stack > * GNU_PROPERTY_AARCH64_FEATURE_1_AND, used by AArch64 Branch Target > * Identification and Pointer Authentication > > Bitwise OR for all links. > > * GNU_PROPERTY_X86_ISA_1_NEEDED = GNU_PROPERTY_X86_UINT32_OR_LO + 2, > * used by GCC -mneeded (for -march=x86-64-v[234]) > > There appear to be another type of AND/OR bits which are not defined in > ABIs (AFAICT): > > * GNU_PROPERTY_X86_ISA_1_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + 2 > * GNU_PROPERTY_X86_FEATURE_2_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + > * 1 I have no use for these operations for generic targets. > > I think generalizing the AND/OR idea to all architectures probably > requires us to think about these questions: > > * What's the impending usage of the generic AND/OR ranges? ifunc? :) I'd like to add GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION: https://groups.google.com/g/x86-64-abi/c/DRvKxJ1AH3Q > * Does the concept generalize well to other architectures? If we It should work for GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION. > * consider AArch64/x86 FEATURE_1_AND to be the same thing, the current > * usage is purely x86 specific. > * Is AND/OR encoding expressive enough to represent the required states? For GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION, yes. > * I've asked two folks and they expressed concerns. I think the three > * AND/OR usage above speak for themselves. > * Szabolcs Nagy mentioned that GNU_PROPERTY is an OS-specific mechanism > * (GNU), but the features are oftentimes arch specific which make sense > * to other OSes or bare-metal. > * Szabolcs: Do we need any versioning mechanism? > > The feature selection and compatibility checking mechanism has some > overlap with GNU/arch-specific attributes (e.g .ARM.attributes, > .riscv.attributes). If I understand correctly, GNU_PROPERTY has an > associated program header so it can be checked by loaders > (kernel/ld.so/emulator) while Attributes don't have program headers so > they are largely assembler/linker protocols. In an inflexible way that > such feature bits can affect observable states to loaders as well, e.g. > .ARM.attributes can affect e_flags (soft/hard float). .MIPS.abiflags > has an associated program header PT_MIPS_ABIFLAGS (I know nearly nothing > about mips) Some thoughts from mips folks would be useful. > > Last, I think a feature selection and compatibility checking mechanism > is assuredly useful, but whether the current AND/OR scheme can perfectly > satisfy that goal I am unsure. Having the proposal is a very good start, > though:) Thanks a lot for driving the discussion:) My current ultimate goal is GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION with a compiler option, -fsingle-global-definition: 1. All accesses to protected definitions are local access. 2. In executable, all accesses to defined symbols are local access. 3. All global function pointers, whose function bodies aren't locally defined, must use GOT. 4. All read/w
Re: A suggestion for going forward from the RMS/FSF debate
> >> It would be usefull to clarify with the FSF and GNU what the > >> actual relations are, > > Why? What would that gain? I go back to my analogy of the British Queen. > > What would be gained by "clarifying" that if she actually intervenes > > non-trivially in the government of any Commonwealth nation, she'd lose > > that power? > > There are differences between the queen and RMS, even if the image > has some merit. I was refering more to the FSF and GNU project here than to RMS.
Re: removing toxic emailers
> Sent: Saturday, April 17, 2021 at 9:09 PM > From: "Gerald Pfeifer" > To: "Frosku" > Cc: gcc@gcc.gnu.org > Subject: Re: removing toxic emailers > > On Fri, 16 Apr 2021, Frosku wrote: > > In my view, if people employed by a small number of American companies > > succeed in disassociating GCC from GNU/FSF, which is representative of > > the free software grassroots community > > I find this insistant focus by some on "American companies" > interesting - and quite pointless. And my passport is burgundy. > > It also is a completely unwarranted attack on the integrity of the > maintainers, contributors, and other leaders of GCC. Regardless of > the color of their passports. > Personally I care about quality of what we ship, supporting our > users, and upholding the principles of free software/open source. > And I am willing to bet this applies to the vast majority of us. > > So please stop those unfounded allegations. > > Gerald > > PS: Our release managers, for example, are British (Joseph), Czech > (Jakub), and German (Richi), IIRC. The majority of the FSF board, > FSF leadership, and RMS himself are American from what I can tell. It all depends on the quality of the people running it and in it. RMS is certainly top quality considering he got so many minds to start thinking straight about how software is developed and used. Nation is just an idea. The idea of nation is made because of sameness, of race, religion, ethnicity, ideologies, languages. The free software movement is in defiance of all those things. A total defiance of the sameness. Many people in our community have still to figure out *how to be* in our community. Many are getting it wrong. And it shows.
Re: removing toxic emailers
> Sent: Saturday, April 17, 2021 at 9:25 PM
> From: "Frosku"
> To: "Aaron Gyes" , gcc@gcc.gnu.org
> Subject: Re: removing toxic emailers
>
> On Sat Apr 17, 2021 at 10:04 AM BST, Aaron Gyes via Gcc wrote:
> > On Apr 17, 2021, at 1:36 AM, Frosku wrote:
> > > I feel imposed upon when, as a volunteer, I'm expected to submit not just
> > > my volunteered time but all of my time in every venue to your cultural
> > > norms. This is not normal. Just because some of you are paid very nice
> > > salaries to hack on free software doesn't mean all of us are.
> >
> > I don’t make a dime. I find it hard to imagine it would take you
> > all of your time not to act like an asshole. Nobody has even
> > asserted professionalism should be required of professionals.
> >
> > Yet you seem extremely uncomfortable with some bare minimum standards.
> >
> > I assumed as a technical, somewhat obsessive person, you have already
> > Googled “microagressions”, imagined what they would be in the
> > context
> > of a major open source project, and what in-group and out-groups exist
> > in
> > this context, then came to some kind of conclusion that explains your
> > hostility.
>
> Aaron,
>
> If you could kindly refrain from making repeated character attacks and
> trying to imply that because I disagree with you on policy I must be
> some kind of knuckle-dragging bigot, that would be a really good start
> to having a productive discussion. Perhaps instead of talking about
> whether I'm "obsessive", want to "act like an asshole", etc we can
> pretend we've been through that tiring exercise and discuss substance.
>
> My "hostility" to codes of conduct is that I have little confidence that
> they would be applied evenly (in which case, the way you've spoken to me
> thus far would surely not be considered proper conduct as you've taken
> little time to drop to the level of ad hominem attacks and implications)
> and would instead be used as a battering ram against people who are a)
> neurodivergent and struggle with social norms or b) are from different
> cultures which are more direct in communication style.
>
> It's all well and good to talk the talk of diversity and inclusion, but
> it seems to me that what's actually achieved is locking out some of the
> most isolated and vulnerable people -- who have found a home in our
> community -- in order to make some of the most privileged people in
> society more comfortable. *That* is the source of my hostility to what
> I believe is for the most part a noble but misguided proposal.
There are times where *not to act* is the solution. If the United States
and the Soviet Union acted upon aggressiveness by the other during tho last
century, the global ecosystem would have been wiped out. Human development
and progress brought us the capability for complete annihilation. More
like "Star Wars" than "Star Trek". More like 1984 and a Utopia.
> >>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
>
Re: removing toxic emailers
> Sent: Saturday, April 17, 2021 at 11:56 PM > From: "Giacomo Tesio" > To: gcc@gcc.gnu.org, "Gerald Pfeifer" , "Frosku" > > Subject: Re: removing toxic emailers > > Hi Gerald,, > > On April 17, 2021 9:09:19 AM UTC, Gerald Pfeifer wrote: > > On Fri, 16 Apr 2021, Frosku wrote: > > > In my view, if people employed by a small number of American > > companies > > > succeed in disassociating GCC from GNU/FSF, which is representative > > > of the free software grassroots community > > > > I find this insistant focus by some on "American companies" > > interesting - and quite pointless. And my passport is burgundy. > > > So much that in fact, we are talking about some of the most controversial > corporation in the whole world. > > And while we are talking about "toxic emailers", it's not lost to me > the irony that all this divisive debate about inclusive and righteous > behaviour started with an email of a Facebook employee that defines > working in Facebook "a joy". > https://gcc.gnu.org/pipermail/gcc/2021-March/235091.html > > Yeah the same Facebook that still does what Cambridge Analytica used to. It's worse than that. Facebook provides the soil and nourishment for companies like Cambridge Analytica to grow. Some early work on "The Shift News" exposed facebook profiles used to spread rumours about the government’s perceived enemies including the family of slain journalist Daphne Caruana Galizia in 2017. Her police protection was removed entirely in 2013 when the Labour party - a frequent target of her investigations - returned to power. https://theshiftnews.com/2018/05/27/the-shift-news-disinformation-watch-fake-facebook-account-behind-unsubstantiated-attacks-on-opposition-mp/ https://edition.cnn.com/2019/11/30/europe/daphne-caruana-galizia-qa-intl/index.html > > It also is a completely unwarranted attack on the integrity of the > > maintainers, contributors, and other leaders of GCC. Regardless of > > the color of their passports. > > This is a strawman. > > People are just concerned about the undue influence that these controversial > corporations can have on GCC through the influence they have on their > employees. > > It would be overly naive to pretend that the Steering Committee members' > are not influenced by their affiliations, even if we were not talking about > the > champions of surveillance capitalism. > > And this has nothing to do with their integrity. > > Why should they have declared such affiliations in the SC's web page, > if they were irrelevant? > > Because they acknowledge that their affiliations have a non-negligible > influence on what they do and what they do not. > > > Also this has nothing to do with their passports. > > In fact, as you say, > > > The majority of the FSF board, > > FSF leadership, and RMS himself are American from what I can tell. > > > It was Nathan who framed his request in term of culture, politics and > whiteness and priviledge... > > And since the GCC Steering Committe did what he requested, we have to > assume that these are the kind of arguments that we have to debunk, > providing you with a more varied perspective. > > But unfortunately you keep invalidating our perspective because... we are > "jerks". > > > Giacomo >
Re: removing toxic emailers
> Sent: Saturday, April 17, 2021 at 9:41 PM
> From: "Frosku"
> To: "Giacomo Tesio" , "Andrew Pinski" ,
> "Andrew Pinski via Gcc"
> Subject: Re: removing toxic emailers
>
> On Sat Apr 17, 2021 at 10:08 AM BST, Giacomo Tesio wrote:
> > But in fact, millions of people outside the US would feel excluded.
> > And threatened. But we are all "jerks", right?
> >
> > ...
> >
> > Such culture is also dominated by RICH men, but it's unable to see the
> > problem in term of global and local distribution of wealth and power
> > and thus interprets it as a matter of sex, gender and race.
> >
> > Which is obviously totally fine for rich men, as it distract people's
> > attention from the root of their power and won't really fix the problem.
>
> Did you ever notice that income group (in a global sense) is never a
> protected characteristic in these COCs which proclaim to defend the
> disenfranchised and the disadvantaged? It would seem to me that low income
> is the greatest predictor of disadvantage globally.
The one thing that would make a difference is if the rich take on the idea
of sharing. The reason that communism failed was because the idea of sharing
was taken on by the poor, who had nothing to offer.
If there is going to be progress regarding the way the free software movement
sees things, mocking day and night those who have things to offer is stupid.
I have no intention of going there, or trying to buy a ticket to heaven with
my goodness.
> >>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
>
Re: removing toxic emailers
Fundamentally, "micro-aggressions" describe insults and dismissals. Interpreting insults and dismissals as aggression leads only to an atrophy of the skills needed to mediate one's own disputes with others. I oppose the use of the term absolutely. - Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent: Saturday, April 17, 2021 at 8:27 PM > From: "Aaron Gyes via Gcc" > To: gcc@gcc.gnu.org > Subject: Re: removing toxic emailers > > > I wasn't even implying that these cultures are 'good' or 'bad', just > > that they exist and differ from the various regional cultures which > > exist all over the world. I think people were quite touchy at my line > > of questioning. I recognise that there are differences between i.e. > > LA and Seattle or SF and NY, but those differences pale in comparison > > to the differences between Moscow and LA, Beijing and NY, or Sydney > > and SF -- and those are all still large international cities. > > > Give me a break Forsku. > > Could you care to share how you feel imposed upon or feel disenfranchised by > this discussion not being sensitive to your culture? How does a code of > conduct, > or how would discouraging “micro-aggressions” disrespect your lived > experiences > or make it uncomfortable for you to contribute to GCC? > > > The fact that over 50% of the SC is based in (probably?) urban North > > America should give pause to some humility that it may not represent > > the truly global nature of hackerdom. On a technical front this isn't > > important, but if you're trying to impose *culture* on a global group, > > it might be useful to remember that you have a steering group in which > > over 50% of its members represent urban North America, but in the > > world, only about 2% of the population live in urban North America. > > > As far as I understand it Chris Punches lives in North America. > > Only 2% of the world population lives in the US, indeed, most live in China. > > It’s interesting the unkind reaction Liu Hao received in this very thread > when they encountered the arguments making a false equivalency of these > proposals > to their countries’ history. I’m sure he felt not great, being forced to > either > defend the CCP or not share their views on the questions of this conversation. > > What is even the argument you are making at this point? > > Aaron > >
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, 16 Apr 2021 at 19:01, Jason Merrill wrote: > > On Fri, Apr 16, 2021 at 10:49 AM Christopher Dimech via Gcc > wrote: > > > Sent: Saturday, April 17, 2021 at 1:03 AM > > > From: "Ville Voutilainen" > > > To: "Christopher Dimech" > > > Cc: "GCC Development" > > > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > > > > > On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > > > > The "small minority of developers" you speak of sure > > > > > seems to consist of developers who are not in the minority > > > > > considering how much they _actually contribute_ to the project. > > > > > > > > Due to their being paid for the work. Have no doubt that if others > > > > were being paid, the contributions could likely drown the current > > > > contributors. Thus, the claim of a power grab is valid. > > > > > > How convenient to make that claim and just bypass what's said in the next > > > bit: > > > > > > > > > > > > Some of them don't need to perform a "power grab"; they > > > > > already have all the power fathomable, by virtue of being maintainers > > > > > and active developers. > > > > > > I very much doubt your lofty hypothesis that if "others" were being paid, > > > the > > > contributions would "likely drown" the current contributors. Especially > > > when we're talking about people who have submitted pretty close to ZERO > > > patches to GCC. You can give a claim that a person $foo would contribute > > > if being paid to do it. I'll buy that claim if you're talking about > > > people like > > > Nathan Sidwell and Iain Sandoe from the time before they became active > > > contributors again, now that they've been hired to do that. I will not > > > buy that claim about people who haven't been GCC contributors before. > > > > There are many users of gcc who are more qualified to know what is needed > > in gcc, than developers. That does not mean than I want to diminish their > > authority for gcc. But that authority was still conferred to them by the > > the Gnu Project - which demands responsibility to carry out the assigned > > tasks to the best of their ability, not to excoriate their obligation > > towards > > the project itself. > > > > The ultimate authority is the final responsibility of the Gnu Project, > > not only that of gcc. > > Free Software means there is no ultimate authority. In Free Software, > leadership of the development process is by the "consent of the > governed". If there is sufficient objection to the existing > leadership, developers can change it, either by negotiation for > changes with the current leadership or by forking. > > The EGCS fork happened because a critical mass of developers gave up > on the GNU GCC2 leadership model. The reconciliation happened because > GNU agreed to accept the EGCS development model as GNU GCC. > > I hope to resolve the current crisis by leadership adjustments > something along the lines of Ville's proposal, rather than forking. > > Jason That's pretty much all I ask. Jason, Jeff, Thomas, others, please discuss this matter among the maintainers, and if need be, among the SC, and make a decision, or at least provide an indication of how you see these matters. I think that indication gives us megabytes more data than philosophical discussions will, entertaining as they might be.
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Sunday, April 18, 2021 at 5:07 AM > From: "Ville Voutilainen" > To: "Jason Merrill" > Cc: "Christopher Dimech" , "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Fri, 16 Apr 2021 at 19:01, Jason Merrill wrote: > > > > On Fri, Apr 16, 2021 at 10:49 AM Christopher Dimech via Gcc > > wrote: > > > > Sent: Saturday, April 17, 2021 at 1:03 AM > > > > From: "Ville Voutilainen" > > > > To: "Christopher Dimech" > > > > Cc: "GCC Development" > > > > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > > > > > > > On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > > > > > The "small minority of developers" you speak of sure > > > > > > seems to consist of developers who are not in the minority > > > > > > considering how much they _actually contribute_ to the project. > > > > > > > > > > Due to their being paid for the work. Have no doubt that if others > > > > > were being paid, the contributions could likely drown the current > > > > > contributors. Thus, the claim of a power grab is valid. > > > > > > > > How convenient to make that claim and just bypass what's said in the > > > > next bit: > > > > > > > > > > > > > > > Some of them don't need to perform a "power grab"; they > > > > > > already have all the power fathomable, by virtue of being > > > > > > maintainers > > > > > > and active developers. > > > > > > > > I very much doubt your lofty hypothesis that if "others" were being > > > > paid, the > > > > contributions would "likely drown" the current contributors. Especially > > > > when we're talking about people who have submitted pretty close to ZERO > > > > patches to GCC. You can give a claim that a person $foo would contribute > > > > if being paid to do it. I'll buy that claim if you're talking about > > > > people like > > > > Nathan Sidwell and Iain Sandoe from the time before they became active > > > > contributors again, now that they've been hired to do that. I will not > > > > buy that claim about people who haven't been GCC contributors before. > > > > > > There are many users of gcc who are more qualified to know what is needed > > > in gcc, than developers. That does not mean than I want to diminish their > > > authority for gcc. But that authority was still conferred to them by the > > > the Gnu Project - which demands responsibility to carry out the assigned > > > tasks to the best of their ability, not to excoriate their obligation > > > towards > > > the project itself. > > > > > > The ultimate authority is the final responsibility of the Gnu Project, > > > not only that of gcc. > > > > Free Software means there is no ultimate authority. In Free Software, > > leadership of the development process is by the "consent of the > > governed". If there is sufficient objection to the existing > > leadership, developers can change it, either by negotiation for > > changes with the current leadership or by forking. Even when there is insufficient objection, one can fork. Progressing this to extreme, suppose one person disagrees with all the rest, he can fork. There are no qualms about that. > > The EGCS fork happened because a critical mass of developers gave up > > on the GNU GCC2 leadership model. The reconciliation happened because > > GNU agreed to accept the EGCS development model as GNU GCC. > > > > I hope to resolve the current crisis by leadership adjustments > > something along the lines of Ville's proposal, rather than forking. I do not see people really intending to fork. It explains why detractors have gone berserk. > > Jason > > That's pretty much all I ask. Jason, Jeff, Thomas, others, please > discuss this matter > among the maintainers, and if need be, among the SC, and make a decision, or > at least provide an indication of how you see these matters. I think > that indication > gives us megabytes more data than philosophical discussions will, entertaining > as they might be. >
Re: A suggestion for going forward from the RMS/FSF debate
On Sat, 17 Apr 2021 at 20:31, Christopher Dimech wrote: > I do not see people really intending to fork. It explains why detractors > have gone berserk. I appreciate your colorful exaggerations, but I should point out that the libstdc++ maintainer has stated his intention to fork, in unambigous terms. A helper elf of his has stated that he will follow the fork, if it occurs. I'm politely entertaining the possibility that you missed that, but Mr. Wakely is not joking when he indicates that he wishes to do a non-FSF fork of lbistdc++.
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Sunday, April 18, 2021 at 5:40 AM > From: "Ville Voutilainen" > To: "Christopher Dimech" > Cc: "Jason Merrill" , "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Sat, 17 Apr 2021 at 20:31, Christopher Dimech wrote: > > I do not see people really intending to fork. It explains why detractors > > have gone berserk. > > I appreciate your colorful exaggerations, but I should point out that > the libstdc++ > maintainer has stated his intention to fork, in unambigous terms. A helper > elf of his has stated that he will follow the fork, if it occurs. I'm > politely entertaining > the possibility that you missed that, but Mr. Wakely is not joking > when he indicates > that he wishes to do a non-FSF fork of lbistdc++. Talk facts not rhetoric. What I have seen is people trying to resolve the problem without resorting to an actual complete fork. For this to happen, people would have to agree on things they would not be completely satisfied about. If the fork is presented as a threat, things are not going to work well. I am not complaining about a decision, whatever that is. But parading nuclear missiles means nothing - that I should know.
Re: removing toxic emailers
On 17/04/2021 13:56, Giacomo Tesio wrote: > Hi Gerald,, > > On April 17, 2021 9:09:19 AM UTC, Gerald Pfeifer wrote: >> On Fri, 16 Apr 2021, Frosku wrote: >>> In my view, if people employed by a small number of American >> companies >>> succeed in disassociating GCC from GNU/FSF, which is representative >>> of the free software grassroots community >> >> I find this insistant focus by some on "American companies" >> interesting - and quite pointless. And my passport is burgundy. > > > So much that in fact, we are talking about some of the most controversial > corporation in the whole world. > > And while we are talking about "toxic emailers", it's not lost to me > the irony that all this divisive debate about inclusive and righteous > behaviour started with an email of a Facebook employee that defines > working in Facebook "a joy". > https://gcc.gnu.org/pipermail/gcc/2021-March/235091.html > > Yeah the same Facebook that still does what Cambridge Analytica used to. > >> It also is a completely unwarranted attack on the integrity of the >> maintainers, contributors, and other leaders of GCC. Regardless of >> the color of their passports. > > This is a strawman. > > People are just concerned about the undue influence that these > controversial corporations can have on GCC through the influence they > have on their employees. > Do you have any justification for thinking that the number of such "concerned people" is significant? It is clearly at least one - you - and arguably a couple of the others who have posted here. But do you think it is many, and do you think they have any reason or justification for this concern? (Repeating it multiple times in these mailing list threads is not reasoning or justification - "proof by repeated assertion" arguments can be dismissed off-hand.) I am not a Facebook fan myself. I have an account that I use almost exclusively just for keeping up with a couple of sports clubs of which I am a member, and which use Facebook to publish information. I don't like the way it tracks so much information about me and other people, and I don't see how it benefits me. (Google tracks information too, but I see more benefit in it.) However, that is /my/ choice and /my/ opinion, and the way /I/ like to use (or avoid) social media. Other people have very different opinions, and find a lot to like about Facebook. That's /their/ choice. Big companies like Facebook and Google are powerful tools. They usually try to be "good" most of the time - after all, they are staffed by real people with real consciences who are, as most people are the world over, basically good people. They will make mistakes sometimes, and powerful tools get abused on occasion. But on the whole they are trying to provide a service people want and can make use of, while also making a living in the process. Anything else is paranoia - and like most conspiracy theories, it falls flat when you realise it would involve huge numbers of people keeping quite about doing evil. I do believe that Facebook, Google, IBM, etc., will have /some/ influence on gcc and all the other free and open source projects that they support. That is because they are big users of such software - it makes sense for them to support them and help and encourage them. And sometimes they will be contributing towards specific features that they want for their systems. (This does not seem to be common for gcc, as far as I understand it from the key developers here.) For example, Facebook want improvements to filesystems in Linux so they have employed people specifically to work on btrfs. IMHO, this is /fine/. There is nothing wrong with that. It is companies "scratching their own itches", just as individual developers often do. We all benefit. It may be /influence/, but it is minor and it is certainly not /undue/ influence. The way you go on about "controversial American companies" and "undue influence" suggests you think these companies are forcing their employees on the gcc steering committee to add backdoors to gcc to tell Facebook what projects you are compiling, or make gcc only work well on Red Hat. That would be utter nonsense. So what is it that you think these companies are doing wrong for gcc? How do you think they are influencing it? Who are all these "concerned people" ? If you have justification, evidence, or even a rational argument for your concerns, please share them. If not, please stop repeating baseless paranoia. You have made your point, such as it is - please move along now. (That is not censorship - it's just a polite request to stop wasting people's time.) David Brown
Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
On 2021-04-17, H.J. Lu wrote: On Thu, Jan 21, 2021 at 1:42 PM Fangrui Song wrote: On 2021-01-21, H.J. Lu via Gnu-gabi wrote: >On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote: >> >> 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI >> >> #define GNU_PROPERTY_UINT32_AND_LO 0xb000 >> #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff >> >> A bit in the output pr_data field is set only if it is set in all >> relocatable input pr_data fields. If all bits in the the output >> pr_data field are zero, this property should be removed from output. >> >> If the bit is 1, all input relocatables have the feature. If the >> bit is 0 or the property is missing, the info is unknown. >> >> 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI >> >> #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 >> #define GNU_PROPERTY_UINT32_OR_HI 0xb000 >> >> A bit in the output pr_data field is set if it is set in any >> relocatable input pr_data fields. If all bits in the the output >> pr_data field are zero, this property should be removed from output. >> >> If the bit is 1, some input relocatables have the feature. If the >> bit is 0 or the property is missing, the info is unknown. >> >> The PDF is at >> >> https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf >> >> -- >> H.J. > >Here is the binutils patch to implement it. > >-- >H.J. Hi, H.J. Thank you for CCing llvm-dev:) In the past various GNU ABI proposals went unnoticed by LLVM folks who don't happen to subscribe to GNU lists. (A lot! I personally subscribe to some lists and check the discussion just in case I miss something important:) ) I have researched a bit and observed that the following GNU_PROPERTY values are currently used by compilers/linkers: Bitwise OR for relocatable links. Bitwise AND for executable/shared object links. * GNU_PROPERTY_X86_FEATURE_1_AND = GNU_PROPERTY_X86_UINT32_AND_LO + 0, * used by Intel Indirect branch tracking and Shadow Stack * GNU_PROPERTY_AARCH64_FEATURE_1_AND, used by AArch64 Branch Target * Identification and Pointer Authentication Bitwise OR for all links. * GNU_PROPERTY_X86_ISA_1_NEEDED = GNU_PROPERTY_X86_UINT32_OR_LO + 2, * used by GCC -mneeded (for -march=x86-64-v[234]) There appear to be another type of AND/OR bits which are not defined in ABIs (AFAICT): * GNU_PROPERTY_X86_ISA_1_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + 2 * GNU_PROPERTY_X86_FEATURE_2_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + * 1 I have no use for these operations for generic targets. I think generalizing the AND/OR idea to all architectures probably requires us to think about these questions: * What's the impending usage of the generic AND/OR ranges? ifunc? :) I'd like to add GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION: https://groups.google.com/g/x86-64-abi/c/DRvKxJ1AH3Q * Does the concept generalize well to other architectures? If we It should work for GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION. * consider AArch64/x86 FEATURE_1_AND to be the same thing, the current * usage is purely x86 specific. * Is AND/OR encoding expressive enough to represent the required states? For GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION, yes. * I've asked two folks and they expressed concerns. I think the three * AND/OR usage above speak for themselves. * Szabolcs Nagy mentioned that GNU_PROPERTY is an OS-specific mechanism * (GNU), but the features are oftentimes arch specific which make sense * to other OSes or bare-metal. * Szabolcs: Do we need any versioning mechanism? The feature selection and compatibility checking mechanism has some overlap with GNU/arch-specific attributes (e.g .ARM.attributes, .riscv.attributes). If I understand correctly, GNU_PROPERTY has an associated program header so it can be checked by loaders (kernel/ld.so/emulator) while Attributes don't have program headers so they are largely assembler/linker protocols. In an inflexible way that such feature bits can affect observable states to loaders as well, e.g. .ARM.attributes can affect e_flags (soft/hard float). .MIPS.abiflags has an associated program header PT_MIPS_ABIFLAGS (I know nearly nothing about mips) Some thoughts from mips folks would be useful. Last, I think a feature selection and compatibility checking mechanism is assuredly useful, but whether the current AND/OR scheme can perfectly satisfy that goal I am unsure. Having the proposal is a very good start, though:) Thanks a lot for driving the discussion:) My current ultimate goal is GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION with a compiler option, -fsingle-global-definition: 1. All accesses to protected definitions are local access. 2. In executable, all accesses to defined symbols are local access. For other folks, I think https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected#protected-data-symbols-and-copy-relocations has summarized the current toolchain state and answered these questions. clang always e
Re: A suggestion for going forward from the RMS/FSF debate
On 2021-04-17 10:40, Ville Voutilainen via Gcc wrote: On Sat, 17 Apr 2021 at 20:31, Christopher Dimech wrote: I do not see people really intending to fork. It explains why detractors have gone berserk. I appreciate your colorful exaggerations, but I should point out that the libstdc++ maintainer has stated his intention to fork, in unambigous terms. A helper elf of his has stated that he will follow the fork, if it occurs. I'm politely entertaining the possibility that you missed that, but Mr. Wakely is not joking when he indicates that he wishes to do a non-FSF fork of lbistdc++. On the helper elf front, I can concretely state that I will not (for the foreseeable future) be assigning copyright to FSF on *new* concurrency and parallelism related features in libstdc++ or the support libraries for this work to the FSF.
Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
On Sat, Apr 17, 2021 at 11:25 AM Fangrui Song wrote: > > > On 2021-04-17, H.J. Lu wrote: > >On Thu, Jan 21, 2021 at 1:42 PM Fangrui Song wrote: > >> > >> On 2021-01-21, H.J. Lu via Gnu-gabi wrote: > >> >On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote: > >> >> > >> >> 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI > >> >> > >> >> #define GNU_PROPERTY_UINT32_AND_LO 0xb000 > >> >> #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff > >> >> > >> >> A bit in the output pr_data field is set only if it is set in all > >> >> relocatable input pr_data fields. If all bits in the the output > >> >> pr_data field are zero, this property should be removed from output. > >> >> > >> >> If the bit is 1, all input relocatables have the feature. If the > >> >> bit is 0 or the property is missing, the info is unknown. > >> >> > >> >> 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI > >> >> > >> >> #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 > >> >> #define GNU_PROPERTY_UINT32_OR_HI 0xb000 > >> >> > >> >> A bit in the output pr_data field is set if it is set in any > >> >> relocatable input pr_data fields. If all bits in the the output > >> >> pr_data field are zero, this property should be removed from output. > >> >> > >> >> If the bit is 1, some input relocatables have the feature. If the > >> >> bit is 0 or the property is missing, the info is unknown. > >> >> > >> >> The PDF is at > >> >> > >> >> https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf > >> >> > >> >> -- > >> >> H.J. > >> > > >> >Here is the binutils patch to implement it. > >> > > >> >-- > >> >H.J. > >> > >> Hi, H.J. > >> > >> Thank you for CCing llvm-dev:) In the past various GNU ABI proposals > >> went unnoticed by LLVM folks who don't happen to subscribe to GNU lists. > >> (A lot! I personally subscribe to some lists and check the discussion > >> just in case I miss something important:) ) > >> > >> I have researched a bit and observed that the following GNU_PROPERTY > >> values are currently used by compilers/linkers: > >> > >> Bitwise OR for relocatable links. Bitwise AND for executable/shared > >> object links. > >> > >> * GNU_PROPERTY_X86_FEATURE_1_AND = GNU_PROPERTY_X86_UINT32_AND_LO + 0, > >> * used by Intel Indirect branch tracking and Shadow Stack > >> * GNU_PROPERTY_AARCH64_FEATURE_1_AND, used by AArch64 Branch Target > >> * Identification and Pointer Authentication > >> > >> Bitwise OR for all links. > >> > >> * GNU_PROPERTY_X86_ISA_1_NEEDED = GNU_PROPERTY_X86_UINT32_OR_LO + 2, > >> * used by GCC -mneeded (for -march=x86-64-v[234]) > >> > >> There appear to be another type of AND/OR bits which are not defined in > >> ABIs (AFAICT): > >> > >> * GNU_PROPERTY_X86_ISA_1_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + 2 > >> * GNU_PROPERTY_X86_FEATURE_2_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + > >> * 1 > > > >I have no use for these operations for generic targets. > > > >> > >> I think generalizing the AND/OR idea to all architectures probably > >> requires us to think about these questions: > >> > >> * What's the impending usage of the generic AND/OR ranges? ifunc? :) > > > >I'd like to add GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION: > > > >https://groups.google.com/g/x86-64-abi/c/DRvKxJ1AH3Q > > > >> * Does the concept generalize well to other architectures? If we > > > >It should work for GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION. > > > >> * consider AArch64/x86 FEATURE_1_AND to be the same thing, the current > >> * usage is purely x86 specific. > >> * Is AND/OR encoding expressive enough to represent the required states? > > > >For GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION, yes. > > > >> * I've asked two folks and they expressed concerns. I think the three > >> * AND/OR usage above speak for themselves. > >> * Szabolcs Nagy mentioned that GNU_PROPERTY is an OS-specific mechanism > >> * (GNU), but the features are oftentimes arch specific which make sense > >> * to other OSes or bare-metal. > >> * Szabolcs: Do we need any versioning mechanism? > >> > >> The feature selection and compatibility checking mechanism has some > >> overlap with GNU/arch-specific attributes (e.g .ARM.attributes, > >> .riscv.attributes). If I understand correctly, GNU_PROPERTY has an > >> associated program header so it can be checked by loaders > >> (kernel/ld.so/emulator) while Attributes don't have program headers so > >> they are largely assembler/linker protocols. In an inflexible way that > >> such feature bits can affect observable states to loaders as well, e.g. > >> .ARM.attributes can affect e_flags (soft/hard float). .MIPS.abiflags > >> has an associated program header PT_MIPS_ABIFLAGS (I know nearly nothing > >> about mips) Some thoughts from mips folks would be useful. > >> > >> Last, I think a feature selection and compatibility checking mechanism > >> is assuredly useful, but whether the current AND/OR scheme can perfectly > >> satisfy that goal I am unsure. Having the propo
gcc-10-20210417 is now available
Snapshot gcc-10-20210417 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20210417/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision 85c3858465b9fc8c05d11c7b0a6c72792788f33f You'll find: gcc-10-20210417.tar.xz Complete GCC SHA256=78826271a0b84a4329cca5608e856e49b44f8708b862c1e246b3da3a47339b6d SHA1=2148f94eab8be406617bbb6742871797e852c822 Diffs from 10-20210410 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: A suggestion for going forward from the RMS/FSF debate
On 2021-04-17 12:08, Christopher Dimech wrote: Thomas, So we are decided? I am not pushing anybody down the cliff - rms, you or anybody. I simply wish that after a few world wars, people start seeing the light and things will be somewhat blissed out working on free software. In a lot of ways this is pretty simple for me. Having observed a few weeks of the FSF's ham-fisted response to the ham-fisted way in which they handled a this entire matter, makes it very easy for *me* to arrive at the stance that the *current state* of the FSF is such that I don't personally believe it has the ability to be a good steward of the work that is assigned to it going forward, and so *I* am not going to do that thing in particular as long as that remains the case. I'll see my work in GCC11 through (there's one remaining patch review to address this week); I don't like leaving things in a half assed state if I can avoid it. The work to finish out C++20 library support features which passed through the Concurrency and Parallelism study group (SG-1) in WG21 on their way to being standardized will be, for now, done in a public repo with GPL license sans-FSF assignment. Other work which I have initiated to replace the dependency on Thread Building Blocks within the Parallel STL algorithms (PSTL); something required for this part of libstdc++ to no longer be marked 'experimental' will not be done with a GPL license and will not, as a result, be assigned to the FSF. It is my hope, and expectation, that that work will become part of GCC12 and GCC13 respectively, and I will know in the fullness of time if that expectation is to be met.
Re: removing toxic emailers
This conversation has moved well off-topic for the GCC mailing lists. Some of the posts here do not follow the GNU Kind Communication Guidelines (https://www.gnu.org/philosophy/kind-communication.en.html). I suggest that people who want to continue this thread take it off the GCC mailing list. Thanks. Ian
A suggestion for going forward from the RMS/FSF debate
You have specified that the community does not require my approval or that of Eric Raymond. That is true of course. But many have gone through so much new age training that they ended up with a very sophisticated way of bullshitting themselves. Regards Christopher > I'll see my work in GCC11 through (there's one remaining patch review to > address this week); I don't like leaving things in a half assed state if > I can avoid it. The work to finish out C++20 library support features > which passed through the Concurrency and Parallelism study group (SG-1) > in WG21 on their way to being standardized will be, for now, done in a > public repo with GPL license sans-FSF assignment. Other work which I > have initiated to replace the dependency on Thread Building Blocks > within the Parallel STL algorithms (PSTL); something required for this > part of libstdc++ to no longer be marked 'experimental' will not be done > with a GPL license and will not, as a result, be assigned to the FSF. Using a GPL and assigning copyright are two different things though. > It is my hope, and expectation, that that work will become part of GCC12 > and GCC13 respectively, and I will know in the fullness of time if that > expectation is to be met. >
A suggestion for going forward from the RMS/FSF debate
I was under the (likely incorrect, please enlighten me) impression that the meteoric rise of LLVM had more to do with the license allowing corporate contributors to ship derived works in binary form without sharing proprietary code. - NightStrike You are correct. LLVM is under the Apache License Version 2.0, which is a free software license compatible with the GNU GPL Version 3.0. But the license comes with LLVM Exceptions that nullifies the Apache License, because it then allows others to embedded their work into object form. Furthermore, it continues to nullify the Apache License by allowing patent treachery. The LLVM License is thus a perfidious license intended to allow the licensor to sue you at their choosing. Consequently, the LLVM Owners are being extremely dishonest, because they are using the words "Apache License" to trick people into believing that the LLVM License has anything to do with free software. It does not. Regards Christopher
Re: A suggestion for going forward from the RMS/FSF debate
> Furthermore, it continues to nullify the Apache License by allowing patent > treachery. The LLVM License is thus a perfidious license intended to > allow the licensor to sue you at their choosing.= “Patent treachery”? And the intent of the license is to... accommodate lawsuits? That’s some very motivated reasoning you’re doing right there. Aaron
Re: A suggestion for going forward from the RMS/FSF debate
On 4/17/21 12:11 AM, NightStrike via Gcc wrote: I was under the (likely incorrect, please enlighten me) impression that the meteoric rise of LLVM had more to do with the license allowing corporate contributors to ship derived works in binary form without sharing proprietary code. Intel, IBM, nVidia, etc. are I think this is a blinkered view. Sure, there are companies that build proprietary toolchains using llvm as the base but I would argue that it is the *result* of the rise of llvm and not the cause. The cause IMO is accessibility to other projects, most notably compiler researchers and students who find it a lot easier to target llvm than gcc because compiler-as-a-library. License may have been a factor for some of those uses (e.g. I know some who think copyleft is not free enough and BSD style licensing is the *real* freedom), but concluding that it is the major reason is to delude ourselves. It is also the reason why gcc does not even figure in situations where a larger project would need AOT or JIT compilation; we had to concede that ground all because of the FSF/GNU fears that companies would make proprietary compilers out of a gcc compiler-as-a-library. Of computer science graduates I have encountered over the last decade, I know few who started their journey with gcc and they were all in the initial part of the decade. In recent years I don't think I encountered any student who works on gcc; many even start with the assumption that gcc is in maintenance mode. So to summarize, the reasons why llvm is gaining traction *today* (I'm sure there are more): - Compiler-as-a-library - llvm is the first choice in FOSS projects and use cases are exploding with gcc nowhere in sight - Mindshare - most students and researchers are focused on it - Funding - llvm has a much stronger funding ecosystem than gcc. This includes direct funding from the foundation and development workforce from various organizations and universities. - License - Companies are building proprietary solutions on top of llvm. Siddhesh
Re: A suggestion for going forward from the RMS/FSF debate
> Sent: Sunday, April 18, 2021 at 6:09 PM > From: "Siddhesh Poyarekar" > To: "NightStrike" , "Ville Voutilainen" > > Cc: "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On 4/17/21 12:11 AM, NightStrike via Gcc wrote: > > I was under the (likely incorrect, please enlighten me) impression > > that the meteoric rise of LLVM had more to do with the license > > allowing corporate contributors to ship derived works in binary form > > without sharing proprietary code. Intel, IBM, nVidia, etc. are > > I think this is a blinkered view. Sure, there are companies that build > proprietary toolchains using llvm as the base but I would argue that it > is the *result* of the rise of llvm and not the cause. > > The cause IMO is accessibility to other projects, most notably compiler > researchers and students who find it a lot easier to target llvm than > gcc because compiler-as-a-library. License may have been a factor for > some of those uses (e.g. I know some who think copyleft is not free > enough and BSD style licensing is the *real* freedom), but concluding > that it is the major reason is to delude ourselves. > > It is also the reason why gcc does not even figure in situations where a > larger project would need AOT or JIT compilation; we had to concede that > ground all because of the FSF/GNU fears that companies would make > proprietary compilers out of a gcc compiler-as-a-library. > > Of computer science graduates I have encountered over the last decade, I > know few who started their journey with gcc and they were all in the > initial part of the decade. In recent years I don't think I encountered > any student who works on gcc; many even start with the assumption that > gcc is in maintenance mode. For military focused PhDs, gcc is used. > So to summarize, the reasons why llvm is gaining traction *today* (I'm > sure there are more): > > - Compiler-as-a-library - llvm is the first choice in FOSS projects and > use cases are exploding with gcc nowhere in sight > > - Mindshare - most students and researchers are focused on it > > - Funding - llvm has a much stronger funding ecosystem than gcc. This > includes direct funding from the foundation and development workforce > from various organizations and universities. You will not get funding grants in the US if you mention free software, because the US Department of Commerce does not allow it. > - License - Companies are building proprietary solutions on top of llvm. > > Siddhesh >
