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.

@Edent So this appears to be a lightly disguised criticism of the kernel project ... the project that is working hard to incorporate Rust into a 30+-year-old code base, is (slowly) developing new contribution tools, and sees 2-300 new contributors in each and every one of its nine-week release cycles.

There are plenty of problems in kernelland, but they will not be improved by a distorted view like this.

@corbet @Edent from an outside view, the Rust thing appears to be suffering active sabotage that Linus is making little effort to stop.

@corbet @Edent On the contributor numbers, obviously hard to consider the counterfactual but ~1000 new contributors per year sounds very small compared to the size of the codebase, and the very limited turnover of lieutenants suggests they aren’t progressing very far.

Do we have data on how many of those folks actually remain active? Wikipedia has done a lot of work to define and measure new editor retention and it’d be interesting to see some of that borrowed.

@hyc

cmake: 2000
ninja: 2012

Maybe you could reconsider what “flavor of the month” means?

@Edent

IMHO, cmake and ninja are awful. I also have no shortage of memories of others complaining about autotools/autoconf (which facilitate things such as ./configure and gave rise to even worse things such as autoAutoconf [e.g. https://github.com/phantomfive/autoAutoConf ]) and based on painfully lived experiences learned the hard way? Those complaints were all merited too.

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

@cedric I've obviously muted whoever you're replying to but, yes, lots of greybeards have no concept of time!

@cedric @Edent those were the only examples that came to mind. I don't follow newer tools.

@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.

@cedric

@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.

@corbet I wasn't thinking of Linux when I wrote that - but I do find it amusing how many people have taken it as being about that.

Lots of projects are withering on the vine doe to their crappy environments, processes, and attitudes.

I think greybeards (like me) should plan for getting out of the way in *every* project.

@luis_in_brief @Edent I looked at longevity a bit one year ago: https://lwn.net/Articles/956765/ . I should run those numbers again. The brief answer is that some of those people obviously drop their one patch and move on, but others do indeed stick around for the long term.

@Edent Given the number of people screaming at the kernel project from the sidelines at the moment, it's a pretty natural conclusion to come to.

(And, as I said, we do indeed have our problems!)

@hyc @Edent You're behaving like one of the old farts he's talking about and you just made his point for him.

Being inflexible and pushing the status quo is exactly how projects die.

I am in disbelief that you think Howard might need to grow a clue, or that his projects might be at risk of dying, where of any of the code bases I downstream for MacPorts, Howard's (e.g. https://ports.macports.org/port/lmdb/details/) have by far more users, like by a factor of almost 8X the next highest ranked MacPort for which I am a maintainer (e.g. https://ports.macports.org/port/openssh/details/).

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

@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 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.

@corbet @Edent some are “working hard to incorporate Rust”and some are flouncing out of the project saying you can pry C from their cold dead hands but they will not be touching any of this Rust crap.

@maco @Edent Who have you seen "flouncing out"?

Do you really expect a project with 5,000 contributors over the course of the year to run without occasional conflict and disagreement?

At the moment we have a high-profile maintainer who is concerned about the prospect of maintaining a multi-language code base for the next ten years. I am not on board with how that concern has been expressed, and I think those concerns will not win out over the long term, but the concerns should be addressed on their merit — as the Rust-for-Linux developers have been patiently doing. Turning it into a "cold dead hands" strawman is really not going to make the process work better.

@Edent lol look at all the old farts picking this apart while thinking *they’re* not the old fart you’re talking about, and simultaneously missing the point

@luis_in_brief @corbet @Edent

Not quite...
There are methods for maintaining dual language codebases like this. The rust folks don't want to follow those method and would rather steamroll the whole process. IMO they were correct to push back... happy to chat more indepth on this one.

@binder @luis_in_brief @Edent Strange, I have not seen much "steamrolling" going on, certainly not on the part of the Rust folks. But, if you have thoughts on how things could run more smoothly, joining the mailing-list discussion with constructive comments might be a good thing to do.

@corbet @Edent @luis_in_brief

"steamrolling" being a strong term.

More they were pushing for code where it wasn't wanted. Maintainers should not be "forced" to accept code, and indeed, rust code should 'generally' be kept separate. This of course causes a whole lot of other issues, but that is what you get for having a dual language codebase.

The technical methods to handle these sorts of projects are not complex, the political aspects of course are not.

Many years of OSS have taught me what my strengths are, and political issues are not among them.

If I could give advice (which would not be accepted)... it would be to look at how enterprise handles multi language codebases.

@Edent Many replies demonstrate exactly the points you're raising 😞

Somehow you're understood that everyone should immediately jump on a new thing (which obvs isn't true, that way lies madness), not that some progress in processes and, yes, technologies would be nice.

And yes, sometimes, the "old" modes exist for good reason and *are* "better", that also needs to be seen (and explained well) - but that's not what you focused on and I wish people saw that stagnation can't be the answer.

@Edent
the git workflow by itself doesn't work, there is no method for review and revision. Things like gerrit can be used... but are pretty crap. The email based workflow works better and is more reliable.

memory safe languages, you mean like python? sure... lets use python.
NB: we already have tools and techniques to write reliable C to any standard you choose.

Community issues... well... communities are hard, for a lot of reasons.

There are actually TONS of new people trying to contribute... but they as a whole aren't willing to do the baseline work. They want to throw a CL at a project and have it accepted... and things just don't work that way.

@binder @Edent Your "the git workflow by itself doesn't work" somehow seems to assume everyone pushes to `main` directly, which ... obviously isn't how anyone would run a major project?

You get branches, pull requests (which, in all platforms from Codeberg to GH, support review and iteration), ...

You bring up python when folks obvs mean Rust. We have tools/techniques to write reliable C? And yet we ... don't seem to?

Are you arguing in good faith?

@binder
I've literally just had to set up an app specific password and futz about on the command-line to generate an email for a one-line Linux patch. That's hardly better.

As for C - https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024-9632/

Lots of projects manage their communities well. Doing the hard work *is* the work.

Your last paragraph proves my point. People want to contribute, but the system makes it hard. So they go off to places which have an easier on-ramp for new contributors.

@Edent
Contributing to linux is just about as easy as it could be. It is well documented, has great tooling, has books dedicated to the process and there are even classes.

Allowing folks to "just" do a git push... wouldn't work.

For C, I'm saying the exact opposite. You can write good code in ANY language... and I regularly deal with panics in rust. Good code is good, bad code is bad.

Few projects are nearly the size or importance of the linux kernel.

No, you misunderstand my last paragraph. Those are folks who do NOT want to do the work, they want the easiest change with the least amount of effort, then they will never look at it again. They 'merely' want a line on their resume.

IMO: getting code into a project with the security implications of linux... should be hard and heavily scrutinized... much moreso than it currently is.

@binder I'm sorry, but I can't square "easy as it could be" and that there are "books dedicated to it".

If you want to get *new* people involved, you need to give them an easy way to *start* to contribute.

The barrier to entry is so high that, IMO, it removes a lot of otherwise talented contributors who want to start slowly.

Linux himself has repeatedly mentioned the problems they have nurturing first-time contributors and turning them into long-term participants and maintainers.

@binder @Edent I never had to read a book or take a class to learn how to open a Pull Request. I just did it.

I'd rather spend my time learning about the programming itself than learning how exactly to configure a mail client in a way that will not make the maintainers sneer at me for sending the wrong bit of metadata.

@muvlon @Edent sok, you can do that. But we can't run Linux that way

@larsmb @Edent

so... you aren't recommending git... but instead a large infrastructure built around git... yes that could theoretically work.

Course that requires money, infrastructure, etc.

Python is a "memory safe" language. That doesn't mean it's magical. Rust isn't magical either.

For reliable C... this is very well studied. you there are studies from IBM and Microsoft on the effects of various software engineering techniques. In fact... safety critical systems are written in a very few languages... C being very prevalent. so yes, we know how to do that.

'merely' using the current static analyzers would eliminate nearly all memory errors, yet we don't do that, why?

It is because the incentives encourage us to not do that.

@binder @Edent Not in good faith then, thank you. Enjoy!