One of the most important skills I found in open source development is separating technical arguments from religious arguments, and choosing to simply ignore the latter. You can spend all your time having the religious debates and feeling very productive while actually getting absolutely nothing done. Learning to recognize the distinction and, crucially, not engage at all when someone is coming at you with a religious argument is incredibly valuable for anyone who is or wants to be in a leadership-ish role in that kind of environment. You've got better things to do with your time than explain to someone why building a whole separate kernel is a stupid idea.
In general, in democratic organizations it is a failing strategy to not engage in arguments or to boycott elections. It is a recipe for an imbalance that is almost impossible to correct later.
So, I respectfully disagree with your suggestion to not engage at all.
https://pythonafrica.blogspot.com/2023/12/an-open-letter-to-...
> We understand that the argument against support for DjangoCon Africa was that the host country, Tanzania, is not a safe place for the LGBTQIA+ community.
That's not as simple as "woke ideology" though. If you don't find the convention, Africa doesn't get a pycon. If you do fund it, you're funding something that excludes queer people.
Without knowing any details, I guess they should have been more eager to fund it. then at least some people would benefit
You do know this kind of thing has zero to do with Python? Nobody is having sex at pycon? They can just do what everyone else does, and not make that the most important thing in the world while at the stupid convention.
Like personally I think logging should end, so can I just make this position a requirement that everyone else has to agree with to attend Pycon? It makes no sense, as it isn't related to the topic of the convention. I think that is why it gets labeled as an ideology.
At some point we should say they are deeply hostile to the large and well respected portion of the python community who are queer, if they want to exclude them for who they are then we can also decide not to run a pycon there.
Going back to Rust for Linux (the actual thing we were talking about), you cannot cleanly separate the "religious" and "technical" sides of the argument. Rust doesn't provide safety advantages when calling into C code unless you inform the type system of what the memory safety requirements of that C code are. Otherwise you have to litter your code with unsafe blocks everywhere to manually call into C, which makes it a lot closer to C code. Safe Rust requires you to know and understand what the C code is doing, or have good documentation related to that code, and keep your bindings up to date when the C code changes. That's both technical and religious - insamuch as Rust demands good docs and some subset of the C people don't want to provide them.
[0] Yes, banning homosexuality is inherently authoritarian. It's literally the first thing any authoritarian does, to check if society's liberal reflexes still work or not.
> Yah I'm sure the African pycon was planning to ask every attendee if they are LGBT...
You're passing judgement on people you don't know, while you remain in a privileged and ignorant position. Many trans/NB/intersex people could be easily identified as such, based on their appearance/voice/etc. Even if the concern was sexuality alone (or other characteristics you could mask/hide), nobody wants to live out their life in a closet - that's also the entire point of a conference: to go there and talk to other people, to feel safe while doing so, to be able to remain yourself.
The problem space is way more nuanced than "just don't have gay sex in public lol".
I think Python devs such as you and I are much more privileged than the average African.
Still, TinkersW's comment amounts to "don't be gay". That's exactly the kind of thinking that enables this problem in the first place.
Whether you're privileged or not, tolerance could be as simple as just letting people live their lives. Acts of discrimination, hate, aggression - whether mandated by law, by customs, or else - these are all wilful choices, made by people who commit them.
That's precisely my point. Mentionning someone else's "privilege" is a meaningless ad hominem.
Do you think maybe a technical convention should be about the technical stuff? A place where technical things are the only focus and the other stuff doesn't mater - a place where technical merit rules and drives the discussion?
If so, wouldn't it make sense to hold that convention somewhere that allows everyone to display their technical merit rather than in a country that will go as far as to look at visitors social media an potentially jail them over something that has nothing to do with python?
Would you be ok with it if the convention for your technical expertise was held at a convention center owned by a logging company who didn't allow you entry to the building because of your comment here? The convention isn't going to engage in politics, and by not considering such things they've effectively banned you from participation for non-technical reasons. Wouldn't it be better if they held it across the street at the convention center that explicitly supported the right of disgusting ideals like anti-logging (but is otherwise no different)?
It turns out that sometimes defending basic rights of your organization's membership is in fact a requirement for creating a situation where technical merit rules. By not doing so, you participate in a situation where non-technical considerations are part of what tech and what engineers are allowed to make it have a major influence on the technical direction of your thing.
That's besides the point. People are not at a Python convention for sex. Having a convention in a different culture doesn't mean accepting all the moral tenets of that culture.
You're effectively cancelling the entire African and Asian Continents. I'm failing to see in putting barriers to what is the best gateway for economical progress for a lot of people in our time.
Defund all pycons from 80% of the world then. Because that's the vast majority of Asia, Eastern Europe, the Middle East, Latin America and a lot of the rest of the world.
This will just result in forks and fragmentation in the long term, as opposed to having to work with and being more accepting of "queers".
However, one side's failure to engage means that the other viewpoint has won and is now driving everyone else out. Nothing new, just a classic purge of heretics.
Back to my original point: It is bad advice to not engage in the discussions. Unbalanced outcomes end up tearing a community apart.
-----
"The mission of the Python Software Foundation is to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers."
Organizational issues are a whole other ballgame. I can see how my original comment was not specific enough about this.
* https://ntoll.org/article/psf-woe/ * https://ntoll.org/article/victorian-python-allegory/
Sorry for using vague terminology. I don't personally keep up with PSF dramas. My point was about communities in general, not just the PSF in particular.
To be fair, the dominant group itself also uses vague terminology. The PSF director's linked-in account says, "I'm motivated by the intersection of technology and social justice." Their social media accounts are more specific though: https://x.com/baconandcoconut?lang=en
If he doesn't like it so much, he should stop writing about it. I'm sorry, but I went into those blog posts with an open mind, and all I found was a long list of personal complaints with relatively few details about the actual situation.
Open source is definitely very political and if you are not political you will find you will produce lots of technical output that will never be merged. There is also lots of etiquette that can go to using mailing list and patchset formatting to knowing who to ask to review. When you talk about design changes you better have credibility, as your design might not even be evaluated if you do not have a track record. I really disagree with your comment and in my experience with lots of OSS different projects i contributed to, i can tell you politics is equal or more important than raw technical competence the bigger the project is.
The core argument is that attempts to convert the Linux kernel to Rust are burning out the people putting in that work. The choice might not be between Rust in Linux or a new kernel, but between burned out devs failing to put Rust in Linux or a new Linux-compatible kernel written from scratch in Rust.
The argument may have been 'go pound sand', that's what it means.
Also, WSL1 and some BSDs are examples of Linux compatibility.
> Also, WSL1 and some BSDs are examples of Linux compatibility.
Yes, and they suffer from either performance or lack of drivers, hence WSL2 running a real Linux with some dark magic to share hardware and network, sort of. Surely you don't mean this as an argument in favor of rolling your own Linux-compatible kernel?
They key aspect will be importing was has gone wrong in the Rust and kernel community cultures.
A: never make any changes to the system they are maintaining, or
B: learn Rust.
Neither of those options seem reasonable, so it's a difficult problem. So if the contingent of people who want to see Rust in the kernel is large enough it may be better for them to fork the kernel, as it's unlikely that advocacy will have enough of an effect.
Imagine the churn if they would have changed their ways whenever there was some new hot thing.
And this is applicable to most devs too.
I might not have pushed back even a couple years ago but the language has been around nearly ten years now, has undeniable advantages (and disadvantages of course as with anything), and it's only gaining in popularity. Too much of the opposition feels like they're just hoping the movement fizzles out so they don't have to seriously engage with it, and I don't believe that's going to happen.
Genuinely curious because I haven't been around so long, have there been previous pushes for the inclusion of other languages in the kernel? Anything even close to the level we're seeing now with Rust?
In the end, if enough contributers are willing to contribute in Rust, there will be Rust in the kernel I believe. Beggars can't be pickers.
Apart from C++ I don't think there has been any contender. But I am not following the mailing list really.
10 years is still yesturday. We will see.
The problem is that some subsystem maintainers do not want to even properly document existing APIs (sic!) and want to reserve the right to willy-nilly hack some changes into "their" subsystems without discussing it with other stakeholders.