linux-kernel - Re: [RFC PATCH 00/11] an introduction of library operating system for Linux (LibOS)

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]

Message-ID: <55183EF9.9060709@nod.at>
Date:	Sun, 29 Mar 2015 20:05:45 +0200
From:	Richard Weinberger <richard@....at>
To:	Antti Kantee <pooka@....fi>, Hajime Tazaki <tazaki@...e.ad.jp>
CC:	linux-arch@...r.kernel.org, arnd@...db.de, corbet@....net,
	cl@...ux.com, penberg@...nel.org, rientjes@...gle.com,
	iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [RFC PATCH 00/11] an introduction of library operating system
 for Linux (LibOS)

Am 29.03.2015 um 18:59 schrieb Antti Kantee:
> On 28/03/15 21:17, Richard Weinberger wrote:
>> Am 27.03.2015 um 16:17 schrieb Antti Kantee:
>>> Let me try to offer some insight.  I've been working on something similar in mainline NetBSD for almost 8 years now, so in addition to ideas popping into my head I've also tested
>>> them out in the real world.  I do think that all operating systems should be structured to support a lib mode, and hopefully integrating Hajime's work into Linux will get on the
>>> right track.
>>
>> IMHO it depends on the maintenance burden.
>> Linux source changes magnitudes faster than NetBSD's.
> 
> I can understand why you're worried about maintenance burden -- believe me, I've heard all the excuses before, starting all the way back from "it's impossible".  Let's dissect your
> concern.
> 
> There's a reason I wrote in my original mail: "Figuring out how to make the libos as close to zero-maintenance as possible is indeed the trick".  It took me a few weeks to make
> things work in my version, but it took four years to figure out how to make things as maintainable as I could figure out how to make them.  The good news is that the results of
> those four years are more or less generic and independent of OS.
> 
> The source may change an order of magnitude faster in Linux, but Linux also has several orders of magnitude more resources.  Even if you do not believe that available resources are
> relevant in the equation, you can still take the data from NetBSD, multiply the maintenance burden with any Stetson-Harrison constant you see fit, and have your expected Linux
> maintenance burden value.
> 
> Mind game: what if I were to assert that the maintenance burden of application compatibility is too high on Linux compared to NetBSD due to the high rate of change?  I think
> everyone would rush to tell me that I'm wrong...

There is no need for mind games. Patches talk. :)

> So why not just evaluate Hajime et al's work for its functional merits and immediate benefits, and see how maintenance burden plays out by collecting actual data on it.

Hajime's work is currently under evaluation. Guess what we're doing right now?

Thanks,
//richard
--
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/