It is not. You are really dismissing his original point that the contribution is made difficult because of code bloat. I have a hard time believing this is easier than ever, as 20 years ago the code must have been simpler.
Are we talking about the kernel or the entire distro?
Let's look at one of the favorite whipping boys from uninformed folks claiming linux systems are now bloated: systemd.
In many ways the consolidation of various disparate userspace components that occurred with the advent of systemd has substantially simplified the task of contributing to anything it covers.
There's now a mono repo encompassing a huge swath of the core of userspace with far less code duplication than we used to have in the bad old days where every little component was a snowflake project managed by its own respective cabal with its own mailing lists (if you're lucky) and its own ideas of how configuration files should be parsed, services installed/enabled/run, and generally a huge snowflake pile of redundant functionality.
Anyone with basic C knowledge now can clone the well organized repo and in very little time be reading and modifying code in a DVCS, and with systems and processes like git and github in place you can have your first patch up in the form of a reviewable and upstream-mergable PR in under an hour, without anyone else's involvement!
If you don't think this is has all lowered the barrier substantially for individual contributors interested in understanding, modifying, and contributing changes to the code underpinning their systems, you simply have no idea what it used to be like.
>its own ideas of how configuration files should be parsed, services installed/enabled/run, and generally a huge snowflake pile of redundant functionality.
Wouldn't there have been a different possible way of tackling this issue tho? Some framework group setting a standard for config file parsing, etc and then compiling a list of component(s) that fit these definitions?
It used to be that things like sysvinit were a handful of sourcebfules that you could read and understand in a few hours. Now you must wade through 500.000 lines of code to find what you're looking for.
I've yet to find this makes things that much harder to find. Even on smaller projects people clearly don't read the entire thing to find what they're looking for. Searching for a given bit of functionality is far from an O(n) process.
Then our experiences with these codebases are entirely different. I have a hard time looking things up in the systemd source code. The code really is more complex.
sysvinit scripts were/are massive, plus usually source some other file. For systemd they're replaced with configuration files. Much easier.
I don't see why you'd need to check the source code though. It's often just init scripts, plus the various related ones (timers, path, socket, etc). Before that was also spread out over multiple things. Now they all share a similar way of doing things.
Slight annoyance is that some systemd manpages too often refer to another manpage. Example: if you e.g. skim the systemd.service manpage, you'll likely miss the options documented under systemd.exec. The manpage does refer to those, but I often forget that you need to read multiple manpages.
Comparing systyemd with init scripts is disingenious. I can only read systrmd unit files after learning their language, which includes all the meanings and interactions of the possible statements in them. In othrrvwords, I have to learn at least the entire default behavior of systemd up front. With init scripts I need to only know the script language. A skilled Linux user will be quite familiar with the later anyway.
> Comparing systyemd with init scripts is disingenious
You're not really explaining why I think. For systemd you have configuration files. It's very easy. At a last resort you can write a shell script for some special handling. With init scripts it's totally false that "you only need to know the script language". The way those init scripts are written differs across distributions. Meaning, small differences between e.g. Fedora, openSuse, Mageia, etc. Bigger differences for Debian.
I don't get why you call a configuration file a language.
> A skilled Linux user will be quite familiar with the later anyway.
That's what I mean, the system unit files are way easier. There's pretty much options for loads of things. Much easier than doing that stuff yourself in each and every shell script.
Loads of things which is an easy option in systemd I wouldn't know how to easily to in a shell script (e.g. ProtectHome).
What on earth are you talking about? Individuals can and do contribute to Linux every day!
The barrier to contributing to Linux is lower than ever, this is such utter nonsense.