W dniu czwartek, 23 listopada 2017 11:55:53 UTC+1 użytkownik Maciej Sobczak napisał:
> > Masz mikroskop do badania jądra linuxa i za jego pomoca zamierzasz
> > oceniać budowę mostu. Proporcje Ci nie zniknęły tylko sa poza skalą i
> > nie sa proporcjonalne.
>
> Dlaczego nie są?
> Mamy:
> - wielomodułowy system
> - na kilkanaście milionów linii
> - pisany ponad 20 lat
> - przez setki ludzi
> - w zespole rozproszonym po całym świecie
>
> O jakim systemie teraz napisałem?
> ...
> Wiesz, że nie zgadłeś?
>
> Do tej pory użyłeś każdego z powyższych punktów jako argumentu uzasadniającego, że
system ma wiele gigabajtów.
> Tymczasem jest system, który spełniając te warunki tych gigabajtów nie ma.
>
> Stąd wątpliwości i szukanie dalszych argumentów.
>
> Odpowiedzi merytoryczne do tej pory:
> - nie ma motywacji, żeby było mniej
> - kod debugowy i symbole
>
> To sa dobre odpowiedzi (ale potrafię sobie wyobrazić ich więcej).
>
> > Jesteś jak ten jehowiec
>
> O, nowe.
>
> > Ale dowiem się z doświadczeń swoich i okolicznych. Np. przez fakt że
> > programy sa napisane pod architekture x86/Sparc wynika ze sa pisane nie
> > dlużej niż jakieś 30 lat, no i zatrudnienia w firmach. Ale nie przejmuj
> > się, to tylko głupie fakty. Miliony roboczolat brzmia zdecydowanie
> > bardziej ekscytująco.
>
> Tak niestarannie trollujesz, że nawet swoich sąsiednich zdań nie kojarzysz.
> Właśnie o to mi chodziło, że nie da się zmiescić tego (proporcjonalnego) miliona
roboczo-lat w 30 lat realnie dostępnych na rozwój takiego produktu.
> Właśnie to wskazuje na zaburzenie proporcji (czyli: ktoś przy mniejszym wysiłki
zrobił większą binarkę).
>
> > dyskutuje z misiaczkiem co twierdził że na tej planecie nie
> > sposób takiego kodu napisać.
>
> Nadal twierdzę, że nie da się upchnąć miliona roboczo-lat w 30, które były
dostępne. Stąd obserwacja, że mamy do czynienia z innymi proporcjami w czasach i
rozmiarach. A stąd pytanie, dlaczego.
>
> BTW - misiaczek też jest nowy w tej dyskusji. Gorzej, że wypalasz się na
niewłaściwym odcinku i brakuje Ci energii na realną dyskusję.
>
> > Wiele z nich jest oczywistych. Zacznij od zastanowienia się:
> > a) ile czasu trwa linkowanie gigabajtowych execów
> [...]
>
> Moje pierwsze pytanie w tej dyskusji było: czy statycznie zlinkowane byłoby
mniejsze. Nie wiemy tego (sam napisałeś, że nie możesz sprawdzić), więc teraz Twoje
pytanie o to ile czasu trwa linkowanie gigabajtowych execów jest bezpodmiotowe.
Najpierw ustalmy, czy te gigabajty byłyby w statycznie zlinkowanym programie. Tego
nadal nie wiemy, bo z braku możliwości przeprowadzenia testu pozostają tylko domysły,
ewentualnie wyzwiska.
>
> > To tak na początek. Wyboraź sobie że mnożysz te czasy i pamięci razy
> > ilośc programistów (setki)
>
> Słyszałem o buildach integracyjnych off-line.
> Nie ma potrzeby, żeby każdy programista linkował u siebie kompletny system.
> Podobnie jest z testami.
>
> > Nie
> > spodziewaj sie że ktokolwiek powaznie będzie dyskutowal z kimś kto nie
> > wie jakie efekty daje domyślna kompilacja w Visualu
>
> Ja nawet przez chwilę nie zakładałem, że w takiej specyficznej branży ktoś używa
domyślnych opcji kompilacji. Naprawdę.
>
> Ale jeśli używa się domyślnych, to jest to kolejny trop.
>
> Nadal jednak nie wpada mi to do kategorii "niezbędne".
>
> > > Czyli jednak zakładasz, że przeszedłbym rekrutację?
> >
> > Obecnie biora każdego kto ma choć kawalek palca do stukania w klawisze.
>
> Pewnie dlatego kompilują z domyślnymi opcjami...
>
> > Możesz pisać router do fpga
> > ale raczej nie stanie się to godzine po rekrutacji. Coś bardziej po 10
> > latach.
>
> Dziwna strategia. Jak my zatrudniamy specjalistę od FPGA, to nie po to, żeby przez
10 lat tego nie robił.
> Ale jak już napisałeś - ta branża jest specyficzna. :-)
>
> > Jeszcze starszy od jądra linuxa jest kod w zegarku na korytarzu w
> > technikum gdzie uczęszczałem, na 8051.
>
> Ale nie ma 15 milionów linii kodu i nie był pisany przez >20 lat przez setki ludzi
w rozproszonym zespole.
>
> > Jakie wnioski moglibysmy z tego
> > wyciągnąc
>
> Bardzo starannie nie wyciągasz żadnych.
>
> > Znowu nazywasz ludzi pracujących z tym kodem głupimi.
>
> Nic podobnego. Pytam tylko. I do tej pory mamy takie odpowiedzi, po odfiltrowaniu
wyzwisk:
>
> - nie ma potrzeby biznesowej, żeby był mniejszy rozmiar,
> - kod debugowlat, niektórzy wybitni.
>
> Masz na myśli jądro Linuksa?
> Bo już się pogubiłem w Twoich argumentach i o jakim systemie rozmawiamy.
>
> > Nie, ty pytasz inżynierów w nasa
>y,
> - stosowanie domyślnych opcje kompilacji
>
> > Masz grupę ludzi którzy klepią kod od 20
> O NASA jeszcze w tej dyskusji nie pytałem. Nieumiejętnie trollujesz.
>
> > Ja nie wyzywam ludzi. Ja stosuje tą sztuczkę
>
> Gdybyś był politykiem, miałbyś już mema za to stwierdzenie.
>
> > >> Ten kod jest niezbędny.
> > > Tego nie pokazałeś.
> >
> > Jak można to udowodnić bez znajomosci
> > architektury aplikacji co jest a co nie niezbedne?
>
> I gdybyś od początku wyłożył karty na stół, że nie znasz tej architektury, to bym
wiedział, że nie trzeba tak mocno tej dyskusji toczyć.
>
> Pozostaję więc przy tym, co udało nam się do tej pory zebrać:
>
> - brak motywacji biznesowej,
> - kod debugowy,
> - domyślne opcje kompilacji.
>
> Jeśli chciałbyś dołożyć coś do tej listy (oprócz wyzwisk), to ja bardzo chętnie.
>

1) teoretycznie mozliwe sa takie
wielkie procesy na kilka GB ale
ja powiatpiewam w to glownie dlatego ze wydaje mi sie ze takie wielkie programy
raczej beda jakimis raczej zestawami procesow a nie pojedynczym procesem
(jak ktos chce blysnac ze zna takie wielkie procesy to prosze o konkretne dane bo
inacczej to zachowywanie sie jak prz4edszkolak)

2) jak podalem wyliczenia takie wielkie binarki to nie miliony
roboczo lat tylko kilka tysiecy
(przy zalozeniu dosyc przezwoitej
produktywnosci w firmach moze z tym byc gorzej niz zalozona ale nie wiem dokladnie )

3) kod w postaci dllek i libek statycznych zamuje dokladnie tyle samo
(w przypadku libek mnozna czasem linkowac wybiórczo ale to nie ma wiekszego znaczenia
imo pominawszy
patologiczne przypadki gdy ktos linkuje dziesiatki dllek ktorych prawie wcale nie
uzywa ot by zlinkowac -
w przypadku dllek za to mozna wspoldzielic dllki miedzy procesami
co w zaleznosci od systemu moze spowodowac zmniejszenie zuzycia pamieci)
(osobiscie jestem raczej fanem linkowanie dynamicznego - jesli robi sie je dobrze)