Workflows Archive on lore.kernel.org
 help / color / Atom feed
From: Evan Rudford <zocker76@gmail.com>
To: Greg KH <greg@kroah.com>, workflows@vger.kernel.org
Subject: Re: Is the Linux kernel underfunded? Lack of quality and security?
Date: Wed, 18 Nov 2020 18:59:09 +0100
Message-ID: <CAE90CG5MQM+8qX0F_RHmHwrh3fP1oxbtTym_tv-UhW2K3pYD-A@mail.gmail.com> (raw)
In-Reply-To: <20200105081550.GB1667342@kroah.com>

Thanks for your detailed response, I will try to address those points
one by one.

Am So., 5. Jan. 2020 um 09:15 Uhr schrieb Greg KH <greg@kroah.com>:
>
> On Sun, Jan 05, 2020 at 04:49:32AM +0100, Evan Rudford wrote:
> > The problem of underfunding plagues many open source projects.
>
> Does it?  Citation please :)
> And compared to what exactly?

Linux might be hard to compare with other open source projects because
of its enormous scale.
But anyways, I saw many different open source projects that were
underfunded based on their "GitHub-situation".
Even large projects like "webpack"  seem to suffer from underfunding
right now. Here is a citation for you:
https://webpack.js.org/blog/2020-10-10-webpack-5-release/
Also some "medium-sized" projects like
https://github.com/typeorm/typeorm tend to be underfunded unless a
company is willing to sponsor them.

> > Although code reviews and technical discussions are working well, I
> > argue that the testing infrastructure of the kernel is lacking.
>
> Does it?  No one can argue we are "doing to much testing", and more
> testing is always wanted, and happening, can you help with that effort?

Well, yes I would help, but it seems to be hard unless you are working
for one of those companies who are actually doing kernel-testing.

> > Severe bugs are discovered late, and they are discovered by developers
> > that should not be exposed to that amount of breakage.
>
> Specifics please.

This is perhaps only relevant for some specific users.
When I see a critical bug report, then I always ask the question:
Could this bug have been catched by a test-suite with reasonable
efforts compared to the size of the project?
Or is it such a weird corner case that no test-suite could have
realistically catched this bug, other than by pure luck?
For most projects, I tend to lean towards the first answer.

> Remember that Linux runs on _EVERYTHING_ so testing on _EVERYTHING_ is
> sometimes a bit hard and bugs only show up later on when people get
> around to running newer kernels on their specific hardware/workload.
>
> > Moreover, I feel that security issues do not receive enough resources.

This is perhaps hard to argue because the competition isn't good.
To be honest, I feel that neither Linux nor any other "major" OS is
reaching "high" security-standards.
It is a fallacy to think that the security-situation is good just
because nobody else is better.
And of course, rewriting Linux is nearly impossible, but I doubt that
Linux will ever become "truly secure" as long as everything is written
in C.
Let's face the reality: C is an excellent systems programming
language, but it is like an "unprotected chainsaw" with respect to
security.

> Again, citation please?  I would argue that right now we have too many
> people/resources working on security issues that are really really minor
> in the overall scheme of things.
> greg k-h

I agree that the current security-efforts might not be well-directed
for the overall scheme of things.
However, I don't think that security has "too many" people in total.
It might be true that "minor" security-issues are eating too many
resources, but there are still "non-minor" security issues that are
not yet addressed.

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-05  3:49 Evan Rudford
2020-01-05  8:15 ` Greg KH
2020-11-18 17:59   ` Evan Rudford [this message]
2020-11-18 18:13     ` Steven Rostedt
2020-11-18 19:30       ` Evan Rudford
2020-11-18 19:51         ` Steven Rostedt
2020-11-18 19:53         ` Theodore Y. Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAE90CG5MQM+8qX0F_RHmHwrh3fP1oxbtTym_tv-UhW2K3pYD-A@mail.gmail.com \
    --to=zocker76@gmail.com \
    --cc=greg@kroah.com \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Workflows Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/workflows/0 workflows/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 workflows workflows/ https://lore.kernel.org/workflows \
		workflows@vger.kernel.org
	public-inbox-index workflows

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.workflows


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git