Re: The most insane proposal in regard to the Linux kernel development

[Artem S. Tashkinov]

On 2016-04-07 01:05, Greg KH wrote:
> On Sat, Apr 02, 2016 at 05:43:47PM +0500, Artem S. Tashkinov wrote:
> > One very big justification of this proposal is that core Linux 
> > development
> > (I'm talking about various subsystems like mm/ ipc/ and interfaces 
> > under
> > block/ fs/ security/ sound/ etc. ) has slowed down significantly over 
> > the
> > past years so radical changes which warrant new kernel API/ABI are 
> > less
> > likely to be introduced.
>
> That's not true at all, the change is constant, and increasing, just
> look at the tree for proof of that.
>
> > Please, share your opinion.
>
> Please read Documentation/stable_api_nonsense.txt for my opinion, and
> that of the current developers.
>
> If you don't agree with this, that's fine, you are welcome to fork the
> kernel at any specific point and keep that api stable, just like many
> companies do and make money from it (SuSE, Red Hat, etc.)
>
> best of luck with your kernel project,

Tell me, why no one in the Linux kernel dev team is concerned that:

1) There is up to a hundred regressions in each kernel release where a 
big chunk of them are caused by internal API changes?
2) API changes sometimes require drastic changes in every related 
hardware driver and since there's no way you can realistically test the 
code or the hardware, people later discover that their hardware has 
stopped working?
3) The core kernel developers do not have enough expertise to correctly 
update the entire kernel source tree so little things get broken?
4) Developing drivers for a moving target is a Herculean job?
5) You cannot easily bisect kernel regressions because regressions are 
often caused by things _outside_ of the problem you're experiencing.
6) You cannot use new drivers for you hardware on your old kernel, 
because new drivers are incompatible with an old source tree (don't 
remind me of RHEL's kernel - it's a rare exception and they usually port 
only the drivers their respective clients use).
7) Tech unsavvy people cannot realistically debug the kernel.

Hey, please, do not tell me that you're doing a great job following 
postings in LKML or resolving bugs files in bugzilla. You do a very 
lousy job indeed - multiple postings in LKML get zero replies because a 
corresponding developer is either not subscribed to LKML at all, or he 
has missed the message. There are literally hundreds(!) of bugs in 
bugzilla which have ZERO replies. What's more, a great number of kernel 
developers do not have accounts in bugzilla and they don't read 
corresponding mailing lists.

What the hell is wrong with you guys? You're developing the kernel like 
it's your toy project.

1) There's no accountability whatsoever.
2) There are no unit tests. Not a single one.
3) There's no surefire way to contact developers who have commited "bad" 
code.
4) There's no sense of direction.
5) There's no easy way to debug the kernel.

For instance, let's talk about the revoke() call. Right now, if a 
certain IO device is removed while files on it are still open (there are 
multiple ways of opening files in Linux, starting from fopen() and 
ending with mmap()), the kernel state is basically undefined(!). Great! 
The corresponding mount point cannot be reused(!). Whatever program, 
which has its files' descriptors on this accidentally removed device, 
usually cannot gracefully quit or continue working. How on Earth this 
syscall doesn't get the utmost attention?

Then we have bug 12309(1). My last comment to this bug gives a very 
simple way of reproducing it on all Android devices.

Then we have bug 15875(2) which will probably take just ten man hours to 
be resolved, yet there is no interest at all, yet thousands of people 
have very real problems due to it.

Tell me, are you really proud of yourselves?
Tell me, do you develop the kernel for your amusement, ego, your 
employee or for average people to use?
Tell me, are you really interested in more people migrating from stable 
long term supported OSes to Linux?

I want some truly honest answers. And let's not repeat this mantra "we 
don't have enough resources". You have enough resources to break 
API/ABIs in a huge way, you have enough resources to introduce 
regressions - you only don't have enough resources to have any 
resemblance of a responsible development process.

Best regards,

Artem

1) https://bugzilla.kernel.org/show_bug.cgi?id=12309
2) https://bugzilla.kernel.org/show_bug.cgi?id=15875