On Tue, 18 Feb 2014 22:53:12 +0400 the <the.gu...@mail.ru> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 02/18/14 17:56, Gevisz wrote: > > On Mon, 17 Feb 2014 23:30:42 -0600 Canek Peláez Valdés > > <can...@gmail.com> wrote: > > > >> On Mon, Feb 17, 2014 at 8:05 PM, Gevisz <gev...@gmail.com> > >> wrote: [ snip ] > >>> How can you be sure if something is "large enough" if, as you > >>> say below, you do not care about probabilities? > >> > >> By writing correct code? > > > > No, by arguing that fixing bugs in a 200K line program is as easy > > as fixing a bug in 20 10K line programs. It is just not true, just > > the opposite. > > > >>>>> SysVinit code size is about 10 000 lines of code, OpenRC > >>>>> contains about 13 000 lines, systemd — about 200 000 > >>>>> lines. > >>>> > >>>> If you take into account the thousands of shell code that > >>>> SysV and OpenRC need to fill the functionality of systemd, > >>>> they use even more. > >>>> > >>>> Also, again, systemd have a lot of little binaries, many of > >>>> them optional. The LOC of PID 1 is actually closer to SysV > >>>> (although still bigger). > >>>> > >>>>> Even assuming systemd code is as mature as sysvinit or > >>>>> openrc (though I doubt this) you can calculate > >>>>> probabilities of segfaults yourself easily. > >>>> > >>>> I don't care about probabilities; > >>> > >>> If you do not care (= do not now anything) about probabilities > >>> (and mathematics, in general), you just unable to understand > >>> that debugging a program with 200K lines of code take > >>> > >>> 200000!/(10000!)^20 > >>> > >>> more time than debugging of 20 different programs with 10K > >>> lines of code. You can try to calculate that number yourself > >>> but I quite sure that if the latter can take, say, 20 days, the > >>> former can take millions of years. > >>> > >>> It is all the probability! Or, to be more precise, > >>> combinatorics. > >> > >> My PhD thesis (which I will defend in a few weeks) is in > >> computer science, specifically computational geometry and > >> combinatorics. > > > > It is even more shameful for you to not understand such a simple > > facts from elementary probability theory (which is mostly based on > > combinatorics). > TBH I don't understand your estimate. Where did permutations come > from? are you comparing all the different combinations of lines of > code?
I just wanted to convey that, if an involved program is n times longer, than another one, it does not, in general, true that it will take only n times more time to find a bug. The dependence here would be nonlinear and with much more steep growth than the linear one, just because all the possible ways to go wrong grows proportional to permutations, not necessary of lines but at least of some other units whose number is roughly proportional to the number of lines. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCAAGBQJTA6wWAAoJEK64IL1uI2ha5nIH/iUl2VNVAabzJzRJzC29zmWg > t7KwGcfrtx2D40N7n4yM4LB7VBmnyoQ6+Iroh/uk3S33S/YK/5igN8UfuhvV+lvU > 85X3T3RE3oK3kURLq68bb4Ri2zLFQ8y1rQdrrUr9ABzy+F4Xfo+W4t+lLsHSQ+dY > f4F7ByfJAHwh9OziFKh2/qwLj4z0Trv8AzZZhP8M29kTNWEWGyo5rGg8vRqm8Klm > kHR3RvvTdV4AgYGHqxdtrO7qpB50VXZA8ihzl7lbmsBJj3pWBo1osFNWNP82yy7r > s4hev5QrCpgOlEebtYi/noX8Vxx335SUirGCgjN/W9xhIwt3jfMqRes6zD+bi7A= > =F5to > -----END PGP SIGNATURE----- >
