lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 26 Jan 2008 12:28:20 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	"Giacomo A. Catenazzi" <cate@...eee.net>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Valdis.Kletnieks@...edu,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: using LKML for subsystem development (was Re: Linux 2.6.24)


* Stefan Richter <stefanr@...6.in-berlin.de> wrote:

> [...] How will subscribers of LKML decide which discussion threads in 
> the huge amount of traffic are worth to glance at?  Each of us has 
> only a limited amount of time for LKML consumption.

uhm. How do you decide which of the 10000 git commits per upstream 
kernel release (more than 100 a day) you'll look at?

easy: you download the full git tree from Linus, to have all the 
information in one place, but you then you use filters, because you are 
not interested in the whole 9 million lines of kernel code.

You use filters such as:

   git-log drivers/net/

Note what you dont get: you dont get to download just drivers/net and 
nothing else. It makes no sense in isolation because this is a single 
kernel codebase that is released as one logical unit. Everyone who finds 
a bug in the kernel can be assumed to have access to the full kernel 
source. If we talk about the "upstream kernel", we all can rely on all 
of us having access to the full body of information we do development 
on. This unified information base is _powerful_ stuff.

and by logical extension, the public development "metadata" of that 
unified source tree should be ... just as easily accessible. Such as ... 
a single forum of discussion - an email list for example.

People who dont want to follow the whole, will ... filter.

For example they will only open the threads they are interested in.

Or you dont even have to read all the subjects: you can filter on "net" 
subjects for example, that filter took 2 seconds to apply for my mailer, 
on 37119 mails in my lkml folder, and this reduced the number of 
messages to 3959 - about 10% of the total size.

Or filter on _people_. The "domain experts" you are interested in. 
Filter on all mails from David S. Miller if you are interested in 
networking topics. You'll have a really good grasp of what's going on in 
that area, without having to invest too much time.

Or subscribe to lwn.net who do weekly updates with links to lkml. If you 
dont have the time, you might have the money to pay people who have the 
time to do work for you. (or if that's still too much, follow the 
time-deferred lkml updates of lwn.net)

Realize it: it's _far_ easier to filter down a too verbose source of 
information, than to put scattered, inaccessible pieces of information 
back together. It's far easier to get a cup of water from the open 
firehose than it is to gather the drops once they spilled on the ground. 
Sure, it all seems easier if you get everything presented on a nice 
little mailing list, with just the right people subscribed - but that 
isolation is the same kind of "closed source" thinking that causes so 
many problems in computing today.

lkml is about using this whole "open development" idea and pushing it to 
its logical conclusion. "Domain experts" hiding away in caves is just a 
fancy excuse for something much different and it can be really harmful 
to the end result (the kernel's quality). Most of the subsystems already 
do their development on lkml, but it could be further improved upon.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ