🚀 go-pugleaf

Andrzej Rosa <bakters@yahoo.com> wrote:
> On 2011-04-18, Piotr B. [pb2004] <p_borkowski@nospamgazeta.pl> wrote:
>> Andrzej Rosa <bakters@yahoo.com> wrote:
>>
>>>> To tak samo jak pod Windowsem.
>>
>>> Nie.  Pod Windows o spełnienie zależności martwi się każdy instalator z
>>> osobna.  Każdy po swojemu, zgodnie z własnym widzimisiem. 
>>
>> Grunt że nie ja.

> Jak instalator się gubi, problem spada na Ciebie.  (Tzn. zgodnie z
> popularnym tu podejściem, trafia to wyłącznie linuksiarzy.)

Podaj jakiś współczesny przykład.

>>>> Dla 1000 aplikacji daje 13500 MiB dodatkowego miejsca na dysku co daje 
>>>> ~=0,013 TiB. Wielka strata zważywszy na to że to największa zależność 
>>>> aplikacji pisanej w GTK.
>>
>>> A teraz załóżmy, że ludzie znajdują krytyczny błąd w GTK...
>>
>> Wyjdą aktualizacje programów.

> Acha.  

>>> Ale to nawet nie jest takie proste, bo jak zaczniesz linkować statycznie
>>> (bo to w praktyce postulujesz),
>>
>> Nie. Żadne gtk nie jest linkowane statycznie.

> Instalowanie bibliotek poza systemową ścieżką przeszukiwania (search
> path) w praktyce sprowadza się do linkowania statycznego.   Jedyna
> zaleta, że możesz zrobić upgrade tej biblioteki bez przemielenia exeka.

Nieprawda.

>>> będziesz miał w systemie totalną sieczkę
>>> jeśli chodzi o wersje.  Nie do ogarnięcia.
>>
>> Ja tego nie muszę ani nie chcę ogarniać. To robi developer każdej 
>> aplikacji. 

> Każdej.  Zwracam uwagę na kwantyfikator.

Jak tego nie robi aplikacja nie działa więc kwantyfikator jest 
prawidłowy. Inna sprawa to forma w jakiej to robi. W najgorszym 
przypadku jest to linux-way czyli informacja ala wymagania Firefoksa dla 
Linuksa podane przez Mozillę.

>> Skoro pisze aplikacje więc zna jej zależności więc nie ma 
>> najmniejszego problemu.

> 1.  To po co to całe protected foo-shmoo na Windowsie, skoro autorzy tak
> świetnie rozwiązują zależności? 

Dla aplikacji z poprzedniego wieku.

> 2.  CDProject wiedział, że Wiedźmin wymaga SP2 na XP, bo napisali na
> pudełku, ale instalator o tym już nie wiedział.  (Tak, wiem, ja
> Linuksiarz jestem.)

No zrobili to w linux-way.

> 3.  Aplikacja z błędem krytycznym w bibliotece działa, użytkownicy są
> zadowoleni.  Dlaczego autor ma rzucać dochodowy projekt po to by
> wprowadzić i rozprowadzić potencjalnie destruktywny upgrade?  Działa,
> nie ruszaj.

Po pierwsze należałoby określić czy bląd jest eksploitowalny w tej 
konkretnej aplikacji. Jeśli tak to znowu zależy jaki typ supportu 
świadczą developerzy tej aplikacji. W przypadku gdy aplikacja jest 
darmowa to rzeczywiście nie musi jej łatać. W przypadku aplikacji 
płatnej informacja o niełataniu błędów raczej nie odbije się dobrze na 
sprzedaży.

>>> Nie wierzysz?  Tutaj jest to opisane z perspektywy dewelopera softu
>>> komercyjnego:
>>> http://www.voyce.com/index.php/2008/09/24/static-libraries-are-evil/
>>
>> Autor pisze o kłopotach w przejściu z biblioteki *.lib na *.dll. Tu tego 
>> problemu nie ma.

> Autor pisze o problemach z dystrybucją i utrzymaniem kilkuset bibliotek.  
> Konkretnie, pokazuje na przykładzie jak marnie się to skaluje.  

Bzdura. Autor pisze o problemach z dystrybucją i utrzymaniem kilkuset 
bibliotek dll gdy w każdej z nich jest zlinkowana ta sama statyczna 
biblioteka na etapie rozwoju odpowiadającym dacie wydania. Wyraźnie 
pisze: „My approach would be to refactor this shared static library 
(.lib) into a stand-alone DLL.”. Chyba że twierdzisz że jest idiotą i 
nie wie jaki ma problem i co go by rozwiązało.

-- 
Piotr Borkowski