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  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:	Sun, 29 Mar 2015 16:59:58 +0000
From:	Antti Kantee <pooka@....fi>
To:	Richard Weinberger <richard@....at>,
	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)

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...

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.

   - antti
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists