| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 02/19/14 14:37, Gevisz wrote: |
| 5 |
> On Tue, 18 Feb 2014 22:53:12 +0400 |
| 6 |
> the <the.guard@××××.ru> wrote: |
| 7 |
> |
| 8 |
> On 02/18/14 17:56, Gevisz wrote: |
| 9 |
>>>> On Mon, 17 Feb 2014 23:30:42 -0600 Canek Peláez Valdés |
| 10 |
>>>> <caneko@×××××.com> wrote: |
| 11 |
>>>> |
| 12 |
>>>>> On Mon, Feb 17, 2014 at 8:05 PM, Gevisz <gevisz@×××××.com> |
| 13 |
>>>>> wrote: [ snip ] |
| 14 |
>>>>>> How can you be sure if something is "large enough" if, as you |
| 15 |
>>>>>> say below, you do not care about probabilities? |
| 16 |
>>>>> |
| 17 |
>>>>> By writing correct code? |
| 18 |
>>>> |
| 19 |
>>>> No, by arguing that fixing bugs in a 200K line program is as easy |
| 20 |
>>>> as fixing a bug in 20 10K line programs. It is just not true, just |
| 21 |
>>>> the opposite. |
| 22 |
>>>> |
| 23 |
>>>>>>>> SysVinit code size is about 10 000 lines of code, OpenRC |
| 24 |
>>>>>>>> contains about 13 000 lines, systemd — about 200 000 |
| 25 |
>>>>>>>> lines. |
| 26 |
>>>>>>> |
| 27 |
>>>>>>> If you take into account the thousands of shell code that |
| 28 |
>>>>>>> SysV and OpenRC need to fill the functionality of systemd, |
| 29 |
>>>>>>> they use even more. |
| 30 |
>>>>>>> |
| 31 |
>>>>>>> Also, again, systemd have a lot of little binaries, many of |
| 32 |
>>>>>>> them optional. The LOC of PID 1 is actually closer to SysV |
| 33 |
>>>>>>> (although still bigger). |
| 34 |
>>>>>>> |
| 35 |
>>>>>>>> Even assuming systemd code is as mature as sysvinit or |
| 36 |
>>>>>>>> openrc (though I doubt this) you can calculate |
| 37 |
>>>>>>>> probabilities of segfaults yourself easily. |
| 38 |
>>>>>>> |
| 39 |
>>>>>>> I don't care about probabilities; |
| 40 |
>>>>>> |
| 41 |
>>>>>> If you do not care (= do not now anything) about probabilities |
| 42 |
>>>>>> (and mathematics, in general), you just unable to understand |
| 43 |
>>>>>> that debugging a program with 200K lines of code take |
| 44 |
>>>>>> |
| 45 |
>>>>>> 200000!/(10000!)^20 |
| 46 |
>>>>>> |
| 47 |
>>>>>> more time than debugging of 20 different programs with 10K |
| 48 |
>>>>>> lines of code. You can try to calculate that number yourself |
| 49 |
>>>>>> but I quite sure that if the latter can take, say, 20 days, the |
| 50 |
>>>>>> former can take millions of years. |
| 51 |
>>>>>> |
| 52 |
>>>>>> It is all the probability! Or, to be more precise, |
| 53 |
>>>>>> combinatorics. |
| 54 |
>>>>> |
| 55 |
>>>>> My PhD thesis (which I will defend in a few weeks) is in |
| 56 |
>>>>> computer science, specifically computational geometry and |
| 57 |
>>>>> combinatorics. |
| 58 |
>>>> |
| 59 |
>>>> It is even more shameful for you to not understand such a simple |
| 60 |
>>>> facts from elementary probability theory (which is mostly based on |
| 61 |
>>>> combinatorics). |
| 62 |
> TBH I don't understand your estimate. Where did permutations come |
| 63 |
> from? are you comparing all the different combinations of lines of |
| 64 |
> code? |
| 65 |
> |
| 66 |
>> I just wanted to convey that, if an involved program is n times longer, |
| 67 |
>> than another one, it does not, in general, true that it will take only |
| 68 |
>> n times more time to find a bug. The dependence here would be nonlinear |
| 69 |
>> and with much more steep growth than the linear one, just because all |
| 70 |
>> the possible ways to go wrong grows proportional to permutations, not |
| 71 |
>> necessary of lines but at least of some other units whose number is |
| 72 |
>> roughly proportional to the number of lines. |
| 73 |
As I see it: |
| 74 |
Suppose we can have b different paths in each unit of code |
| 75 |
(for 1 unit having 1 input we would get b possible outputs). |
| 76 |
Suppose we have A different states after executing N units, but we |
| 77 |
have 1 more unit to execute at the end. Executing the final |
| 78 |
unit A times with different initial states we get b outcomes for |
| 79 |
each of the A initial states. Now we have A*b possible final states, |
| 80 |
so we get b^(n+1) states after executing N+1 units. |
| 81 |
If there are s mistakes we can make in each unit we will get 2^s paths |
| 82 |
in each unit. Finally 2^(s*N)I may be glitching though. |
| 83 |
-----BEGIN PGP SIGNATURE----- |
| 84 |
Version: GnuPG v2.0.22 (GNU/Linux) |
| 85 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
| 86 |
|
| 87 |
iQEcBAEBCAAGBQJTBxE1AAoJEK64IL1uI2haoFMH/Ag/JJEh3OZBUf6lR+bp3iV5 |
| 88 |
HQOh+V+J2vclDcOqc2AQDEYFIR++3yo1iqlw9vW8pI2wSRvcia2j0fs1M/kamvhH |
| 89 |
xJC+yaeDQ9dy544PQS/y1vnSxK4nqyTybZ0/yj4liRofkY+4Gyn+hZanPO6R04cn |
| 90 |
UDXH/K0uvlhSyIaFRkzmCD8wrEH/slPPGtB3+GwpSckM4MUwtNsjLyng78+AhX9j |
| 91 |
A2m5pKrFVHnE09XqGKm+G4La2LeNy33fOTgfL4O/s8q8xCRkIuf/B2mEO/76eUwn |
| 92 |
QYjSN77sLtDFfxJSfO46Gch3nA3obcKBVqZkVtqy5Z83m3OjqwKT7xu4yLLHM4Y= |
| 93 |
=4zVQ |
| 94 |
-----END PGP SIGNATURE----- |
Archives