On 11/21/2017 1:35 PM, Maciej Sobczak wrote:
>> Sprawdź to lepiej ile zajmuje jądro *plus* wszystkie moduły
> Nadal megabajty. Podobno kilkadziesiąt.

A typowy program do usuwania pryszczy modelkom może i setki. Czy już
widzisz jak zły wybrałeś przykład?

> A to poziom trudności wpływa na stosunek rozmiaru binarki względem liczby linii
kodu?

Na podstawie bredni o tym ile lat pisano jądro linuxa wymysliłes sobie
że nie da się napisac aplikacji tak dużej aby kod zajmował GB.

Pozwól że zacytuje:

"czyli na oko miliard linii kodu i milion lat pracy"

> Ja piszę o tym, że jeżeli weźmiemy Linuksa jako pewny znany punkt odniesienia

Czy jak bym wziął przecietne seminarium jako punkt odniesienia do badań
nad religijnością obywateli to miałbyś może jakąs uwagę do metodyki czy
Ci nie zależy?

>, to przykład wielogigabajtowych DLLek tak bardzo od tego punktu odniesienia
odbiega, że aż się prosi o wyjaśnienie.

Wyjaśnienie: w rzeczywistym świecie sa projekty większe
kilkanascie/dziesiąt razy od Linuxa pod względem kodu.

> I tego wyjaśnienia nadal nie widać.

Ależ widać tylko nijak nie potrafisz szukać bądź obracasz się w
środowisku helloworldowców gdzie takich rozmiarów nie ma i eksrapolujesz
tą ignorację na ogromne aplikacje.

>> Innymi słowy przechodzisz do atakowania faktów
> Ja podałem fakty z Linuksa.

A ja z seminarium.

>> W technice można
>> najzwyczajniej sprawdzić rozmiar naciskając szary + w total commanderze.
> Nie napisałem nigdzie, że plik nie może mieć takiego rozmiaru

Znowu czas na cytat:

"Co z kolei każe poddać pod wątpliwość, czy w ogóle taki program dało
się na tej planecie napisać"

Ja robie szary + i mam wynik. Ty twierdzisz że nie mogę mieć. Ludzie o
wykształceniu technicznym nie spierają się o fakty i nie bazują na
urojeniach wyssanych z palca.

>, tylko że (w porównaniu do znanego punktu odniesienia) ten rozmiar ma wątpliwe
uzasadnienie.

Czyli już odwrót. Już nie tyle nie da sie napisać co nie ma
uzasadnienia. No no, szybko uciekasz.

>> Zawsze możesz sie zatrudnić w jednej z firm (a niektóre mają
>> oddziały w PL) i nawrzeszczeć na swojego kierownika że imbecyl
> Zauważyłem, że za każdym razem gdy o czymś dyskutujemy pojawiają się dwa stałe
zjawiska:
> 1. mam sobie zerknąć na EDA
> 2. w Twoich postach pojawiają się wyzwiska

Wyzwiskiem jest twoje twierdzenie że firma nie jest w stanie pisać softu
bo popełnia jakieś trywialne bledy jak linkowanie pornola do dllki czy
błedny kod który robi gigabajty zamiast megabajtów.

Ja tylko skrystalizowałem obelgi rzucane przez Ciebie w jedno *słowo*.

>> Zwróć jednak uwagę łaskawym okiem ze docelowy rozmiar dll nie jest
>> krytycznym parametrem decydującym o sprzedaży lub nie softu na rynku.
> I w ten sposób sam podrzuciłeś argument do dyskusji wskazując, że nie ma motywacji,
żeby te DLLki były mniejsze.

Nie ma. Motywacja jest biznesowa. Czasem też ważne jest, niestety, że
jakiś ficzer nie chce się zmiescić na dyskietce. Powiedzmy że wiekszość
uzytkownikow już ich nie używa między innymi z tego powodu.

> Wstępne podsumowanie:
> - ja stawiam zarys tezy, że taki rozmiar może nie być optymalny
> - Ty stwierdzasz, że nie ma motywacji biznesowej, żeby był optymalny
> Czyli nie ma między nami różnicy zdań, wbrew Twojemu wyobrażeniu, że ktoś kogoś
atakuje, itd.

Podsuwasz idityczny przykład z resourcami w dll i myślisz że nie
atakujesz? Atakujesz zdrowy rozsądek. Ludzie piszacy tak wielki kod mają
*ZUPEŁNIE* inne problemy niż te z poziomu gimnazjum.

>> Nikt tu nie pisze o gigantycznych dllkach. Piszę natomiast o
>> gigantycznej liczbie dllek.
> Dobrze, popracujmy nad tym argumentem.
> Napisałem pustą funkcję w C i bez żadnych optymalizacji zrobiłem z niej:
> - plik obiektowy: 687 bajtów
> - archiwum do linkowania statycznego: 840 bajtów
> - dynamiczną bibliotekę dzieloną: 56731 bajtów

Brawo. Kupiłem garnek. Wlałem do niego kroplę wody. Zważyłem i wyszło 1kg.

Wniosek: dwie krople wody w garnku to już 2kg.

> W przypadku linkowania z archiwum wyciągany jest sam tekst funkcji, więc tu narzutu
nie ma.
Natomiast biblioteka dzielona jest 80 (słownie: osiemdziesiąt) razy
większa, niż plik obiektowy. Oczywiście ten narzut jest sztucznie
zawyżony przez sam fakt, że funkcja jest pusta, ale...

Cała bzdura w tym ale. Zazwyczaj detale jak kod debugowy, symbole itp
duperele niezauwazalne hobbystycznie mają znaczenie. Oczywiście pod
warunkiem że ktokolwiek jest na tyle głupi aby z nagłówka kiepsko
skompilowanego dll wyciągać wnioski o narzucie.

>> Na codzien pracuje z projektem gdzie jest
>> ich koło setki i mają sumeryczny rozmiar 0.5GB
> ... ale powinno być zrozumiałe, że skoro DLL ma pewne wewnętrzne narzuty, to suma
rozmiaru dużej liczby DLLek nie przekonuje mnie, że w sumie tyle tych bajtów musi
być.

Nic nie kumasz. 95% tych bajtów to kod. Reszta "narzut", cokolwiek to
miało by znaczyć. Ten "narzut" posiada również zalety które ignorujesz.
To jest balans. Można stracić 5% dysku i zyskać znaczące ficzery w kodzie.

>> Ja zaś, rozumiesz, mialem taki przypadek że kiedys jak siadałem to pękło
>> ramię w fotelu na kółkach i przewróciłem kubek z herbata na klawiature.
>> Z tego wniosek że LG wszystkie klawiatury dziadowskie robi.
> Ja takiego wniosku bym nie wyciągnął, ale cieszę się, że się z nami tym
podzieliłeś.

Ty zas wyciągasz wnioski z nagłówka dll i nie widzisz swojej
śmieszności? Sprowadzenie dyskutanta do pozimu własnych absurdów czasem
działa ale tutaj widać nie bardzo.

>>> Może to jest jakiś trop?
>> Nie. To tylko brednie.
> Więc powinno być bardzo łatwo to wykazać.

Oczywiscie. Mam kilka dllek które z róznych względow musza się
kompilować rownież do .lib. Nie są małe, mają w sumie może z 100MB. Czy
to lib czy dll rozmiar plików jest podobny z dokładnością do szumu.
Zadziwiające, nie? A już przeciez chciałeś pisać do MS że mają poważnego
buga w implementacji dll...

> A tymczasem od początku stwierdziłeś, że odpowiedniego doświadczenia nie możesz
przeprowadzić.

Nie możesz. To nie jest tylko przestawienie switcha w projekcie. Tak to
dziala dla helloworldow. Dla duzych aplikacji jest to nie możliwe.
Przyczyn jest tak wiele że uważam za bezensowne dyskutowanie nad nimi.

>> Więc zatrudnij się w jednej z większych firm programistycznych w okolicy
> A mógłbyś coś polecić?

Nie, miałbym ich na sumieniu.

>> doświadczenia hobbystyczne z hello world mają się nijak do praktyki.
> Praktyka jest taka, że nie ma motywacji, żeby było optymalnie. Sam tak napisałeś.

Jest optymalne w granicach mozliwosci technicznych, tylko funkcja celu
jest zupełnie inna niż myślisz. Jest skomplikowana.

>>> A jeśli mam jedną zmienną statyczną, która jest kontenerem rzeczy, które będą do
niego dodane później?
>> Znowu masz opcje: idziesz do kierownika projektu i nazywasz go
>> imbecylem,
> Znowu wyzwiska.

Sam wyzywasz ludzi na około twierdząc że popełniają trywialne błedy z
dllkami i na pewno da sie je zredukować. No więc pewno się w niewielkim
stopniu da tylko PO CO?

> A może faktycznie można mieć mniej zmiennych statycznych?
> Albo nawet w ogóle ich nie mieć?

Idiotyczna rada. Nigdy jak widać nie pracowaleś nad projektem który ma
~20 lat kodu stukanego przez 4 pokolenia ludzi. Najlepiej idź i wyjasnij
że trzeba wszystko przepisać w C#. Na pewno znajdziesz zrozumienie, może
nawet ktoś poklepie po ramieniu współczując.

>> Brakuje ci pokory
> Bo podałem liczby, z którymi nie wiesz, co zrobić?

Brakuje Ci pokory abys zrozumiał że Twoje trywialne obliczenia z
helloworlda sa gówno warte w zderzeniu z rzeczywistościa gdzie kod
przytłacza, problemy sa nie do znalezienia na stackoverflow, gdzie
kompilatorom kończy się stos przy linkowaniu, gdzie milisekundy
ładowania aplikacji mają znaczenie dla testowania, gdzie istnieją w
ogóle jakieś testy, gdzie istnieje inzynieria programowania, gdzie
zespoły sa rozproszone w nastu miejscach na świecie itd itp setki
powodów. Zazwyczaj organizacyjnych a nie programistycznych, ale mających
wpływ na programowanie.

>> Możesz zacząć od
>> sprawdzenia ile dllek jest w windowsie 10 po instalacji
> Faktycznie można od tego zacząć, bo w pierwszym poście w tej dyskusji napisałem, że
base-system jest wyjątkiem, gdzie kod dzielony jest uzasadniony. Ale dyskutujemy o
aplikacjach.

Które zachowują się jak systemy operacyjne. Mają wlasne uniwersalne
abstrakcje, własne utility, współdziela kod między modułami itd itp. Nie
istnieje wyraźna roznica w złożoności jednego czy drugiego pod względem
podziału na funkcjonalności. Byłes już u tych imbecyli z Photoshopa aby
im wyjaśnić jak głupi sa nie linkując statycznie wszystkiego? Może nie
wiedza że powinni? Bigbounty czeka.

>>> Jeśli w ogóle mam jakąś architekturę, to od razu zakładam, że jest rozproszona
>> Brednia. Nic nie zakaldasz bo nie ma takiego założenia.
> Tak zakładam i do tej pory się to sprawdzało.

Powiedz to kolesiom od gcc na ten przykład. Że powinni zakładać ze
linker odpali sie gdzie indziej niż kompilator.

Wiesz dlaczego to głupie? Bo tak wlasnie można zrobić
distcc/IncrediBuild tylko że w tym celu w gcc nie trzeba linkować
niczego statycznie ani w ogóle o tym wiedzieć.

> Co ciekawe, zrobiłem zgodnie z Twoim zaleceniem i zerknałem do branży EDA, żeby
skonfrontować swoje hobbystyczne wyobrażenie z prawdziwym światem:
> https://www.google.com/patents/US20070073809
> i popatrz jaka niespodzianka - tam też się sprawdziło.

Nie, to najzwyczajniej nie na temat.

> (Właśnie dlatego nie traktuję branży EDA jako wyjątkowego źródła olśnień albo
przykładów. Branża jak inne.)

Nie, jest specyficzna. Jest znacznie wieksza niż "największe znane
aplikacje jakie widział kowalski w bogatej firmie".

>> Zakładasz że oprogramowanie pisza gimazjaliści na zlecenie?
> O, w poprzedniej dyskusji też coś wspominałeś o gimnazjalistach.

Bo tylko gimnazjalista mógłby zapomieć wyładować dllkę i tylko
gimnazjalista mogłby nie napisać na to testu i tylko popsute testowanie
benchmarkowe mogło by tego nie wykryć.

Innymi słowy tak, są firmy gdzie gimnazjalisci pisza soft. Niektórzy
mają 50 lat, ale to stan umysłu bardziej. I tak, niektórzy z obawy że
zapomna wyładować dllkę z pamięci linkuja wszystko statycznie,
niewątpliwie gdzieś tacy są. No bo jak spieprzyć to raz a dobrze.

>> No wiec to
>> też prawda, ale nie dotyczy raczej aplikacji po kilka GB kodu.
> Ale jeszcze nie wykazałeś, że te GB są uzasadnione.

W tej chwili właśnie strzeliłeś w pysk programistów wszystkich dużych
aplikacji. I serio, masz czelnośc twierdzić że to ja obrażam ludzi?

> Wręcz przeciwnie - sam wskazałeś, że nie ma motywacji, żeby było tego mniej

Ten kod jest niezbędny. Jesli chcesz go zredukować to uzyskasz 5-10%
nadludzkim wysiłkiem. Obawiam się że Twojego magebajta z gigabajta nie
da się uzyskać bez usuwania ficzerów.

>, czym tylko utwierdziłeś mnie w moich wątpliwościach w tym temacie.

Dalej masz wątpliwosci nad faktami?

>> To nie sa obliczenia. To brednie.
> Ciekawe, ile osób przekonałeś.

Moim celem jest tylko ekspozycja bredni. Nie mam interesu w
przekonywaniu kogokolwiek.