🚀 go-pugleaf

W dniu środa, 20 kwietnia 2011, 11:02:58 UTC+2 użytkownik Andrzej Rosa napisał:
> On 2011-04-19, Piotr B. [pb2004] 
>  wrote:
> > Andrzej Rosa <bak...@yahoo.com> wrote:
> [...]
> >>>> 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.
> 
> Nie bo nie, czy nie bo tak?
> 

Ta wg. Ciebie jedyna zaleta przesądza że i w teorii i w praktyce jest to nieporównywalne do linkowania statycznego.

> >>> 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 
> 
> Dlaczego ma nie działać?
> 

Nie rozumiem pytania.

> > 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ę.
> 
> W najgorszym wypadku zależności nigdzie nie są zdefiniowane.
> 

Poproszę realny współczesny przykład w miarę poważnej aplikacji.

> >>> 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.
> 
> Z okresu błędów i wypaczeń?  Jakie szczęście, że od tej magicznej daty
> wszyscy autorzy instalatorów nagle zmądrzeli...
> 

Współczesnymi narzędziami po prostu trudno byłoby zrobić instalator podmieniający plik chroniony bo inaczej dystrybuuje się zależności, które trafiają do folderów systemowych.

> >> 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.
> 
> Zrobili to Windows-way, czyli napisali własny instalator, który obsysał
> na maksa, na wiele różnych sposobów.

Instalshield ztcp czyli nie własny.

>  Linux-way nie mogli zrobić, bo nie
> ma systemowego narzędzia, którym mogliby się wyręczyć.

Bzdura. Jest MSI, a sprawdzenie wersji systemu to kwestia sprawdzenia jednej property: http://msdn.microsoft.com/library/aa370556.aspx
W installshield wystarczy klikać myszą:
http://kb.flexerasoftware.com/doc/Helpnet/installshield15helplib/AddingOSPrereqCond.htm

> 
> >> 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.
> 
> Słyszałeś o "bugfixes do not sell"?  Linuksiarze tego nie wymyślili.  
> 
> Ale nawet gdyby się opłacały, nadal mamy z głowy jedynie "poważne" firmy
> z jaką marką do utrzymania.  Całej reszty planktonu to nie dotyczy.  
> 

Znowu aby dyskusja nie była akademicka poproszę o konkretny przykład płatnego programu bez poprawek błędów bezpieczeństwa.

> >>>> 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.
> 
> Sytuacja jest nieomal perfekcyjnie analogiczna do wypuszczenia kilkuset
> aplikacji, każda z własną wersją biblioteki zamiast zainstalowania
> jednej (och, niech będzie paru) wersji w systemie.  Upgrade staje się
> koszmarem.
> 

Gdzie konkretnie widzisz problem? Ja widzę że w przypadku dllki tak jak zresztą pisze autor bloga wszystko sprowadza się do utrzymania kompatybilności co nie jest wielkim problemem. W przypadku błędu wystarczy poprawić kod w jednej bibliotece i ją zbudować. Z tego co pisze autor bloga po migracji na dll byłaby sytuacja kilkaset aplikacji z jedną wersją tej biblioteki.

-- 
Piotr B.