Young folks: Please can we contribute using modern git-based workflow rather than email?
Old farts: No.
: OK, but can we at least use modern memory-safe languages?
: Also no.
: Perhaps we could modernise our language & attitudes to be more inclusive?: LOL! No.
: Could we at least consider addressing some long-standing community issues?: What part of "no" are you having trouble understanding?
: Why aren't there any new people contributing to our project? Truly a mystery. 
@Edent Please can we use modern build tools like cmake, ninja, etc etc
Hell no. Plain `make` does the job easily for 90% of projects. Rtfm and learn how to use it before you go pushing for the latest flavor of the month.
Joining an existing project requires learning how it already works. You don't get to just jump in and imnediately request every current developer change all of their established procedures to accommodate you. That won't fly, anywhere in the world.
@hyc I have literally no idea what you're talking about, sorry.
@cedric I've obviously muted whoever you're replying to but, yes, lots of greybeards have no concept of time!
@Edent @cedric So you blame old devs only? That's a perfect example of stereotyping and it's the foundation for discrimination against those who fit a demographic group.
Think about what you're posting. BTW, I'm 63 with 25 years of experience as a dev. I'm learning Rust so I can have an informed opinion on this topic and to keep growing. What positive things are you working on?
@tzudad @cedric
Yes. I blame the old gatekeepers who refuse to try anything new and then complain when they can't attract newbies. I am very happy to discriminate against people willfully holding back future talent in order to protect their own fiefdoms.
Not that I have to justify things to you but, as an example of positive things…
https://fosdem.org/2025/schedule/event/fosdem-2025-4411-lessons-learned-open-sourcing-the-uk-s-covid-tracing-app/
https://shkspr.mobi/blog/2025/02/presenting-activitybot-at-fosdem/
https://openuk.uk/profiles/terence-eden/
HTH. HAND. KTHXBAI.
Gulotta @tzudad @Edent @cedric It sucks because the people in power resisting change are usually older, but most devs are pushed out of the industry by age 50. So it’s not most older people, it’s the ones in positions of power
People don’t magically stop learning or performing at 50, but generally we’re not as exploitable, we have families, we need more flexibility and benefits. So we’re sacked
Anyway the kernel maintainers are dickheads always have been
@hyc Yes, that’s quite obvious.
You are favoring a horrible old tool because it “does the job.” But you ignore the significant complexity cost it comes with, resulting in barely readable and hard to modify build code already for moderately sized projects. Better tools exist for a reason, and asking for cmake (which is also old and only a moderate improvement over make) isn’t exactly unreasonable.
It makes sense that you feel like @Edent’s post is about you.
@hyc also, I’m open to complaints about CMake! Idiomatic CMake is a fast-moving target and it all looks kinda shitty, everything is strings (ew), the code of CMake itself is gross.
But it beats hand-rolling a recursive Makefile structure for ease, maintainability, and flexibility. It will generate that for you. And Ninja freaking rules. CMake-generated Ninjafiles will properly deal with lazily-generated sources in a way that you just can’t do with recursive make.
@WPalant @Edent @cedric
@c0dec0dec0de @WPalant @Edent @cedric it's also incredibly opaque and nearly impossible to debug when something's wrong, especially when porting a project to a new environment. It only works smoothly on an existing mainstream environment, in which case everything it takes care of is already easily handled with make. Of course a lot of the pain comes from different platforms using varying versions of cmake, and features being unsupported as a result.
There are still some recently conceived projects which use vanilla make and are, IMHO, better for it. e.g. @grunfink@comam.es's snac2 (https://codeberg.org/grunfink/snac2)
But then, I am cranky when I encounter unnecessary dependencies which are brittle and cause me headaches when downstreaming codebases for ports and packages as a maintainer. I also think it is absolutely awful that Python became part of the dependencies for LLVM/clang, they introduced a circular dependency to a lower level compiler which requires a higher level interpreted language which is implemented in C? I can't even with that kind of it.sh. gcc was never that bad. Thankfully, many folks can and do still test things against gcc and we are not in a realm where the world exclusively revolves around LLVM/clang but just imagine how much worse things might get if such a world were created (and you don't have to look very hard to see how some of the monied interests behind some of these tools may have deliberately made these unnecessary dependencies happen, because they want to keep a piece of the pie even though they weren't there when it was originally baked).
Just because something is newer, doesn't mean it is better.
Sometimes newer things are used because people are lazy and want something to work quickly without having done due diligence to have things work correctly in the first place which may take longer initially, but has fewer unnecessary dependencies and gotchas in the long run.
CC: @hyc@mastodon.social @Edent@mastodon.social
@soviut @Edent yes, I understood his point. But if you fail to acknowledge the validity of "if it ain't broke don't fix it" then you've got problems too. Nobody wants to spend time reinventing wheels. Changing tooling has a high cost. If your first instinct as a new developer to a working project is "we gotta upgrade to tools I'm more comfortable with" instead of "I need to learn how this stuff works" then you've got an attitude problem.
@hyc @soviut @Edent Howard, you've accidentally entered this discussion without understanding that this is a subtoot of a particularly venomous exchange going on in the linux community right now that has nothing to do with makefiles or build scripts.
You .. might have a better reception in this thread if you take a moment to look at the resignations of Hector Marcan and Karol Herbst so that you understand the context well enough to formulate an informed comment.
@hyc @Edent If a project is having trouble attracting new talent, then something IS broken and DOES need fixing. If you are unable to maintain a decent DX in your project, that's an important aspect that's broken.
Just because the "old farts" are used to the hostile environment doesn't mean the environment isn't hostile.
Senior maintainers need to be introspective, identify their negatives and correct them. Otherwise they risk their projects being ignored to death.
@hyc @Edent Nobody said it's retooling to accommodate every newcomer and you know that; don't be disingenuous.
It's about staying reasonably current so that stuff people are learning in school, in bootcamps and online in the last decade is actually applicable. Otherwise all that talent slips by as they go towards more nimble projects.
Keeping a toolchain reasonably up to date is NOT a full time job and you know that too. It isn't even something you need to do; let the new blood who want it handle it for you.
Maybe, you don't understand how projects actually thrive? It sure as heck isn't with navel gazing about old farts not understanding new generations.
Admittedly, I am still upset that MacPorts recently lost kencu (Ken Cunningham who was doing work maintaining various gcc versions among other things for OS X Tiger and such) because some disrespectful jerk (who had maybe two commits, in something related to NodeJS/NPM I guess?) was insanely rude to him on a public mailing list. I think the rude person got banned, but the damage had been done.
We are blessed to stand on the shoulders of those who did the hard work that makes our lives easier.
More young upstarts would be wise to not it.sh on such shoulders.
Or as Ice Cube phrased it: "Pump your brakes, respect your elders." (from "Can You Dig It" https://www.youtube.com/watch?v=NVRoTyZU4RU)
CC: @hyc@mastodon.social @Edent@mastodon.social
@teajaygrey @hyc @Edent I didn't say that. I'm remarking that his response to Edent's criticism of project gatekeeping is exactly the attitude that drives away new people from joining the project.
@hyc @Edent what makes Make "plain" and cmake or ninja "flavor of the month", aside from your familiarity bias?
If you are starting software development from scratch, ninja or meson or cmake can make a lot more sense to you than gnu make.
cmake has existed since 2000 (and been used by e.g. kde since 2006), ninja has existed since 2012 - that's 13 years - and meson has existed since 2013; meson/ninja are used for such minor projects as GNOME and Chrome.
perhaps rethink your "month" definition.
@Edent I presume some of this alludes to the Rust vs C war currently on going? As some people have already pointed out: a dual language kernel isn’t a good idea. I’d be inclined to agree since being *really* good at two very different languages is a big ask in terms of cognitive load. I’d also suggest that kernels are VERY low-level and C is pretty good for that. I do understand that there are sections of kernel where it’s more about conventional programming and Rust/memory safety could help.
BUT I think overall trying to pitch this as Old people vs Young people is not the whole picture.
I worked on a product that touched Windows 95/NT drivers in my very first job and was horrified to learn that multiple compiler and assembler tools were needed - I was told this was down to different teams using their preferred tools.
I honestly think the Linux kernel should stick to C, Make, etc. fragmentation is very very bad and likely serves competitors more than the Linux ecosystem
@Edent in all fairness, the kernel email workflow IS the original git-based workflow.
@michiel the keyword you're missing is "modern".
@Edent @michiel I don't think GitHub PRs (the only ither thing I see people ask for), are particularly modern either though. There are plenty of reasons not to use GitHub (I do use it for my own stuff because I really don't care that much)
Mostly people don't necessarily want modern, they want the tool they know.
I know you alluded to this but just to say Github is owned by M$ and is closed source and proprietary.
Gitlab and codeberg are open source.
@tommcc "M$"? Are you twelve years old and living in 1997?
@Edent I never got my refund :(
Thanks, it's also somewhat ironic that this type of ad hominem attack (what are you, 12?) is what the R4L community is complaining about, and the topic of the OP lol
@kilgoretrout I'm not sure I understand. Could you explain a little more?
@Edent @kilgoretrout Also, ageist.
@tmcfarlane @Edent @michiel The “GitHub workflow” might not be the best (example: https://mitchellh.com/writing/github-changesetsbut), but having to setup a MUA to contribute is definitely worse.
Also, this is what people are used to. 100% of the projects I use and contribute to get their contributions through Merge/Pull Requests.
@maco omg, that sounds like an awesome talk to me
@Edent the replies are fascinating in how they prove the point and missed it.
A fascinating lack of ability to self analyse
@Edent I think the issue is compounded by the fact that there is still an influx of contributors to the kernel because of the industry behind it, so those maintainers aren't feeling the heat yet. It's incredibly short-sighted because relying on industry is such a precarious position for any free software project.
@Arcaik No point, just sharing this cool project :)
@Edent do you have data to back up the claim that those are the reasons that people who could be contributing, are choosing not to?
Because I would like to contribute and none of those reasons apply to me. #linux
The thing I want is actually good documentation that I can read to get me where I can be effective. And speedy replies.
@bmaxv You know, it’s perfectly possible for a development process to suffer from multiple issues at the same time. In fact, I’d say that better documentation might have been possible if new contributors weren’t burning out as quickly. People who have lived this code for decades don’t need documentation, but newcomers figuring things out tend to write their findings down.
@bmaxv yes. It is the reason I don't contribute any more.
@Edent I would say the framing as an "old farts" vs. "young folks" culture clash is not helpful. The same discussions we had 30 years ago, and not all things then labelled "modern" turned out to be good ideas. People just created new projects based on new ideas. If those projects were better, they eventually replaced the old. For example, git quickly became successful although there were older systems, but nobody ran around and tried to shamed people for using CVS.
@uecker you're *so* close to getting it!
@Edent I am probably to old to get it.
@maco @Edent When Linus started this, C++ was modern and micro kernels - certainly not a Unix kernel clone written in C. These decisions did not deter people from contributing in the last decades (well, it deterred some but not others). To me, it seems a certain set of people / companies are now trying to push for changes and I am not sure this is as simple as "young" vs "old" .