W dniu 2012-01-04 14:55, Bartlomiej Lidke pisze:
> Tomasz Kaczanowski<kaczus@dowyciecia_poczta.onet.pl> wrote:
>> W dniu 2012-01-04 13:02, Bartlomiej Lidke pisze:
>>> Tomasz Kaczanowski<kaczus@dowyciecia_poczta.onet.pl> wrote:
>>>> W dniu 2012-01-04 11:39, Bartlomiej Lidke pisze:
> [....]
>>>> Program powinien sprawdzać jedynie minimalną wersję biblioteki. I
>>>> wtedy problemy tu opisane się nie pojawiają.
>>>
>>> to jest kwestia zarowno zgodnosci jak i bledow pojawiajacych sie w tych
>>> bibliotekach. kazdy Twoj koncowy uzytkownik moze miec inna wersje i
>>> jego interesuje to ze mu Twoj program nie dziala i do Ciebie przychodzi
>>> z pretensjami (support). Ty sie go pytasz o biblioteki i potem musisz
>>> sobie taki zestaw skompletowac zeby zweryfikowac blad. powodzenia
>>
>> A jednak się da. I to się sprawdza. Oczywiście trzeba ograniczać się do
>> bibliotek porządnych, a nie bałaganu.
>
> nie rozwiaze Ci to problemu bledow w bibliotekach w innych wersjach
> na srodowisku uzytkownika. a w jaki sposob stwierdzasz ze biblioteka jest
> porzadna? czy np. gtk jest porzadne?

Nie potrzebowałem używać, więc nie wiem, czy jest porządne.


>>> i nie mozesz "sprawdzac minimalnej wersji" poniewaz znikasz w ten sposob
>>> problem funkcjonalnosci "deprecated"
>>
>> Co znaczy znikasz? Dla utrzymania zgodności są preferowane 2 wersje
>> 1) metody nowe i stare różnią się nieznacznie - wtedy wrappujesz i masz
>> stare i nowe metody
>> 2) zmiany są bardzo duże - tworzysz nową bibliotekę, starą przestajesz
>> supportować, ew sprzedajesz/oddajesz/cokolwiek kod innym
>
> czyli narobiles sobie roboty. ktos inny wrzuci do swojego google-earth
> czy czegostam innego wymagana biblioteke i wogole nie ma tego problemu

Tam, gdzie jest balagan, to jest wlasnie robota, puchnące niepotrzebnie
pliki wykonywalne, bo ufać bibliotekom zewnętrznym nie można. WIęcej,
biblioteka się rozwija działa lepiej, ale użytkownik z tego nie
skorzysta....


>>> popatrz tez z punktu widzenia uzytkownika. chcialbym np. sprawdzic
>>> najnowsza wersje:
>>> http://www.kdenlive.org/user-manual/downloading-and-
installing-kdenlive
>>>
>>> i oprocz sredniego pomyslu w postaci virtualbox-ow oraz live-cd moge
>>> jedynie wpasc w bagno kompilacji (patrz wymagania). a ja chce tylko
>>> odpalic program i stwierdzic czy sie do czegos nadaje czy nie. tak w 5-10 minut
>>>
>>
>>
>> Bo całość jest od początku nie przemyslana.
>
> acha. a jak rozwiazac ten problem fafnastu wymaganych bibliotek po stronie
> uzytkownika i to jeszcze w konkretnych wersjach? inaczej niz wpakowac je
> do swojego podkatalogu 'lib' i bez statycznego linkowania?

wpakować można, ale jako instalowane warunkowo, tudzież wypisać wymagane
biblioteki i zostawić użytkownikowi to by je posiadal - wszystko zależy
od popularności.

>> przykład: http://mos.aminet.net/package/misc/math/MathScript32
>> staroć jak widać, są podane tylko warunki brzegowe i okazuje się, że ja
>> mając obecnie po wielu latach inny system, biblioteki w dużo nowszych
>> wersjach z możliwościami na które tamtejszy sprzęt nie pozwalał. Program
>> rozpakowuję i po prostu uruchamiam i on działa.... Więc można. Ale to
>> właśnie nie na Linuksie, bo ten niewiele gwarantuje, a twórcy 3rd party
>> bibliotek dokładają jeszcze dodatkowo, żeby bałagan był jeden wielki.
>
> amigowcem nie jestem ale:
> - jakich zewnetrznych rozwijajacych sie od 15 lat bibliotek ten program uzywa?


Rozwija się choćby cały pakiet MUI (tak wyglądał kiedyś:
http://www.sasg.com/mui/ do wersji 3.8, teraz wersja 4.0 posiada
przepisane biblioteki ze zmienioną funkcjonalnością - jedna z wersji
została zintegrowana z systemem MorphOS
http://morphos-team.net/index.html). Zmieniły się też funkcje systemowe.

> - czym sa fontengine.library oraz post.library?

jednymi z wymaganych bibliotek? Na tyle mało popularnymi w danym
okresie, że autor postanowił je dołączyć?


> czy ten program w sensie skomplikowania zaleznosci jest wogole porownaniem
> do wspomnianego kdenlive? to jest tylko pierwszy poziom:
>
> Depends: kdebase-runtime, libc6 (>= 2.1.3), libgcc1 (>= 1:4.1.1), libice6
> (>= 1:1.0.0), libkdecore5 (>= 4:4.4.0), libkdeui5 (>= 4:4.3.4), libkio5
> (>= 4:4.3.4), libknewstuff3-4 (>= 4:4.4.0), libknotifyconfig4 (>= 4:4.3.4),
> libkrossui4 (>= 4:4.3.4), libmlt++3, libmlt3, libnepomuk4 (>= 4:4.3.4),
> libqt4-dbus (>= 4:4.6), libqt4-network (>= 4:4.6), libqt4-svg (>= 4:4.6),
> libqt4-xml (>= 4:4.6), libqtcore4 (>= 4:4.6.1), libqtgui4 (>= 4:4.6.2),
> libsm6, libstdc++6 (>= 4.2.1), libx11-6, libxau6, libxdmcp6, libxext6,
> libxft2 (>> 2.1.1), libxpm4, kdenlive-data (= 0.7.8-1.2), melt, ffmpeg

Np tym, że nie wypisano wymaganych bibliotek systemowych, które są nie
istotne, po za minimalną wersja pakietu? Można by wypisać biblioteki
MUI, których ten program potrzebuje w minimalnych wersjach, ale zamiast
tego wpisano, że pakiet ma być co najmniej w wersji 3.x


--
Kaczus
http://kaczus.republika.pl

do góry

Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> wrote:
>> czyli narobiles sobie roboty. ktos inny wrzuci do swojego google-earth
>> czy czegostam innego wymagana biblioteke i wogole nie ma tego problemu
>
> Tam, gdzie jest balagan, to jest wlasnie robota,

trudno sie nie zgodzic z czyms tak ogolnym

> puchnące niepotrzebnie pliki wykonywalne,

a co ma wielkosc pliku wykonywalnego do tego czy biblioteka jest w /usr/lib
czy w /usr/share/costam/whatever?

nawet jesli dostane wersje zlinkowana statycznie to wole statycznie
linkowany program ktory dziala (i zajmuje straaaaaszne ilosci bajtow
w czasie terowych dyskow) niz taki ktory nie dziala wogole

> bo ufać bibliotekom zewnętrznym nie można.

ufac mozna czlowiekowi. jeszcze raz: postaw sie na miejscu serwisu
oprogramowania komercyjnego. wolisz zeby uzytkownicy mieli 10 wersji
niezbednej do dzialania Twojego programu biblioteki czy jedna, ta
ktora PRZETESTOWALES? postaw sie w miejscu uzytkownika: wolisz przeczytac
na stronie tego kdenlive i wielu innych produktow z kategorii 'multimedia'
litanie niezbednych bibliotek po czym sobie odpuscic czy tez chcialbys
sciagnac pakiet kdeenlive_and_all_needed_stuff.zip, rozpakowac i odpalic?

> WIęcej,
> biblioteka się rozwija działa lepiej, ale użytkownik z tego nie
> skorzysta....

ciekawe jak uzytkownik programu zlinkowanego z libcurl (np. wysylajacego
cos ftp-pem) skorzysta z tego ze nowa wersja libcurl-a dodala funkcje
pozwalajaca np. na wysylanie przez proxy (przyklad teoretyczny)

>> acha. a jak rozwiazac ten problem fafnastu wymaganych bibliotek po stronie
>> uzytkownika i to jeszcze w konkretnych wersjach? inaczej niz wpakowac je
>> do swojego podkatalogu 'lib' i bez statycznego linkowania?
>
> wpakować można, ale jako instalowane warunkowo,

no to doszedles do punktu wyjscia. od poczatku twierdze ze duze zewnetrzne
programy powinny miec przynajmniej mozliwosc sciagniecia w formie paczki
ze wszelkimi zaleznosciami. a czesto jest to znacznie wygodniejsze dla
obu stron

> tudzież wypisać wymagane
> biblioteki i zostawić użytkownikowi to by je posiadal - wszystko zależy
> od popularności.

no i wypisali mi w kdenlive. w kilku innych tego typu programach rowniez.
i odpalic ich nie moge

>>> przykład: http://mos.aminet.net/package/misc/math/MathScript32
>>> staroć jak widać, są podane tylko warunki brzegowe i okazuje się, że ja
>>> mając obecnie po wielu latach inny system, biblioteki w dużo nowszych
>>> wersjach z możliwościami na które tamtejszy sprzęt nie pozwalał. Program
>>> rozpakowuję i po prostu uruchamiam i on działa.... Więc można. Ale to
>>> właśnie nie na Linuksie, bo ten niewiele gwarantuje, a twórcy 3rd party
>>> bibliotek dokładają jeszcze dodatkowo, żeby bałagan był jeden wielki.
>>
>> amigowcem nie jestem ale:
>> - jakich zewnetrznych rozwijajacych sie od 15 lat bibliotek ten program uzywa?
>
>
> Rozwija się choćby cały pakiet MUI (tak wyglądał kiedyś:
> http://www.sasg.com/mui/ do wersji 3.8, teraz wersja 4.0 posiada
> przepisane biblioteki ze zmienioną funkcjonalnością - jedna z wersji
> została zintegrowana z systemem MorphOS

mowisz o tym:
http://www.sasg.com/mui/history.html ?

to 3.8 wyszlo razem z tym mathscriptem ktory pokazales. w 1997 roku. czyli
przez 15 lat zmienili z 3.8 na 4.0 i to ma czegos dowodzic? stabilnosci
martwego oprogramowania?

> http://morphos-team.net/index.html). Zmieniły się też funkcje systemowe.
>
> > - czym sa fontengine.library oraz post.library?
>
> jednymi z wymaganych bibliotek? Na tyle mało popularnymi w danym
> okresie, że autor postanowił je dołączyć?
>
>
>> czy ten program w sensie skomplikowania zaleznosci jest wogole porownaniem
>> do wspomnianego kdenlive? to jest tylko pierwszy poziom:
>>
>> Depends: kdebase-runtime, libc6 (>= 2.1.3), libgcc1 (>= 1:4.1.1), libice6
>> (>= 1:1.0.0), libkdecore5 (>= 4:4.4.0), libkdeui5 (>= 4:4.3.4), libkio5
>> (>= 4:4.3.4), libknewstuff3-4 (>= 4:4.4.0), libknotifyconfig4 (>= 4:4.3.4),
>> libkrossui4 (>= 4:4.3.4), libmlt++3, libmlt3, libnepomuk4 (>= 4:4.3.4),
>> libqt4-dbus (>= 4:4.6), libqt4-network (>= 4:4.6), libqt4-svg (>= 4:4.6),
>> libqt4-xml (>= 4:4.6), libqtcore4 (>= 4:4.6.1), libqtgui4 (>= 4:4.6.2),
>> libsm6, libstdc++6 (>= 4.2.1), libx11-6, libxau6, libxdmcp6, libxext6,
>> libxft2 (>> 2.1.1), libxpm4, kdenlive-data (= 0.7.8-1.2), melt, ffmpeg
>
> Np tym, że nie wypisano wymaganych bibliotek systemowych, które są nie
> istotne, po za minimalną wersja pakietu? Można by wypisać biblioteki
> MUI, których ten program potrzebuje w minimalnych wersjach, ale zamiast
> tego wpisano, że pakiet ma być co najmniej w wersji 3.x

wylosuj sobie jakas z powyzszych bibliotek i sprawdz co sie w niej zmienilo
przez ostatnie 15 lat i porownaj to z mui

--
butthead
o 'Niesmiertelnym' (c) Pleciucha:
"Jest to jedyny film, w którym Szkot gra Egipcjanina, który jest Hiszpanem
i Francuz, który gra Szkota, który jest Nowojorczykiem..."

do góry

W dniu 2012-01-04 15:23, Tomasz Kaczanowski pisze:
> W dniu 2012-01-04 14:55, Bartlomiej Lidke pisze:
>> Tomasz Kaczanowski<kaczus@dowyciecia_poczta.onet.pl> wrote:
>>> W dniu 2012-01-04 13:02, Bartlomiej Lidke pisze:
>>>> Tomasz Kaczanowski<kaczus@dowyciecia_poczta.onet.pl> wrote:
>>>>> W dniu 2012-01-04 11:39, Bartlomiej Lidke pisze:
>> [....]
>>>>> Program powinien sprawdzać jedynie minimalną wersję biblioteki. I
>>>>> wtedy problemy tu opisane się nie pojawiają.
>>>>
>>>> to jest kwestia zarowno zgodnosci jak i bledow pojawiajacych sie w tych
>>>> bibliotekach. kazdy Twoj koncowy uzytkownik moze miec inna wersje i
>>>> jego interesuje to ze mu Twoj program nie dziala i do Ciebie przychodzi
>>>> z pretensjami (support). Ty sie go pytasz o biblioteki i potem musisz
>>>> sobie taki zestaw skompletowac zeby zweryfikowac blad. powodzenia
>>>
>>> A jednak się da. I to się sprawdza. Oczywiście trzeba ograniczać się do
>>> bibliotek porządnych, a nie bałaganu.
>>
>> nie rozwiaze Ci to problemu bledow w bibliotekach w innych wersjach
>> na srodowisku uzytkownika. a w jaki sposob stwierdzasz ze biblioteka jest
>> porzadna? czy np. gtk jest porzadne?
>
> Nie potrzebowałem używać, więc nie wiem, czy jest porządne.
>
>
>>>> i nie mozesz "sprawdzac minimalnej wersji" poniewaz znikasz w ten
>>>> sposob
>>>> problem funkcjonalnosci "deprecated"
>>>
>>> Co znaczy znikasz? Dla utrzymania zgodności są preferowane 2 wersje
>>> 1) metody nowe i stare różnią się nieznacznie - wtedy wrappujesz i masz
>>> stare i nowe metody
>>> 2) zmiany są bardzo duże - tworzysz nową bibliotekę, starą przestajesz
>>> supportować, ew sprzedajesz/oddajesz/cokolwiek kod innym
>>
>> czyli narobiles sobie roboty. ktos inny wrzuci do swojego google-earth
>> czy czegostam innego wymagana biblioteke i wogole nie ma tego problemu
>
> Tam, gdzie jest balagan, to jest wlasnie robota, puchnące niepotrzebnie
> pliki wykonywalne, bo ufać bibliotekom zewnętrznym nie można. WIęcej,
> biblioteka się rozwija działa lepiej, ale użytkownik z tego nie
> skorzysta....

Z punktu widzenia producenta aplikacji nie uważam tego argumentu za
decydujący.
1. Zdarzają się biblioteki nie działające lepiej w nowych wersjach -
przeważnie użytkownik nie jest świadom, czy nowa biblioteka jest lepsza,
tylko instaluje ją bo jest nowa.
2. Jeżeli użytkownik koniecznie musi, to przecież może sobie wrzucić
nową wersję biblioteki do katalogu z aplikacją. Z reguły będzie wiązać
się to z rezygnacją z supportu producenta. Lub może zamówić test
programu z lepszą wersją biblioteki - jeśli producent aplikacji
stwierdzi, że jego program działa z nową wersją biblioteki, to sam mu ją
wrzuci do katalogu z aplikacją i będzie świadczył support dla wersji,
którą sam zatwierdził.

Oczywiście robię wyjątki dla bibliotek z dużym wsparciem ich producenta
(w moim przypadku .NET Framework + inne pochodzące od M$) i nie wrzucam
ich do katalogu mojej aplikacji, ale wszystkie pozostałe wolę mieć w
wersji, którą sam przetestowałem :-).

Pozdrawiam

--
gregorius

do góry

On 04-01-2012 11:08, Stachu 'Dozzie' K. wrote:
> On 2012-01-04, Bartlomiej Lidke<o...@r...cy.rot13.invalid> wrote:
>> Stachu 'Dozzie' K.<d...@g...eat.some.screws.spammer.invalid> wrote:
>>> On 2012-01-04, Bartlomiej Lidke<o...@r...cy.rot13.invalid> wrote:
>>>> po trzecie: porozmawiaj z adobem (libssl, libcurl, itp), autorami bibble
>>>> (libQT*), blendera (python), googlem (libqt*), ibm-em (libssl, libxml2,
>>>> i wiele innych), ingresem (libxerces), libreoffice (np. libxml2) i powiedz
>>>> im ze sa bardzo sredniowieczni (to bo szybkim przeleceniu /opt-a)
>>>
>>> Wiesz, też mogę przytoczyć trochę softu robiącego podobny kretynizm.
>>> Tylko co to ma do rzeczy? To kretynizm i tyle.
>>
>> ten kretynizm uratowalby mnie przed konfliktem svn vs ssh na jaki wpadlem.
>> jesli minusy takiego podejscia sa wg Ciebie wieksze od plusow to chetnie
>> sie czegos nowego dowiem
>
> To co napotkałeś, to zwykły błąd maintainera. Albo skutek używania
> nieoficjalnego repozytorium bez skoordynowanego zarządzania
> przyjmowanymi pakietami. Albo skutek używania zestawu nieskoordynowanych
> ze sobą nieoficjalnych repozytoriów. To się naprawia w inny sposób,
> a nie ładując zależności do wnętrza pakietu.
>
Troche p* glupoty. Nie kazdy program jest open source, nie kazdy jest
kompatebilny z nowsza wersja biblioteki. Posiadanie kilku wersji tej
samiej biblioteki jest po prostu wymuszane tak czy siak. Dyski jak na
potrzeby binariow sa generalnie tanie, wrzucenie wszystkich biblotek do
katalogu z applikacja (wlasnie w punktu widzenia admina) zalatwia
problem niezgodnosci pomiedzy biliotekami.

Pozdr

Marek

do góry

On 2012-01-05, Marek Borowski <m...@b...com.nospam> wrote:
> On 04-01-2012 11:08, Stachu 'Dozzie' K. wrote:
>> On 2012-01-04, Bartlomiej Lidke<o...@r...cy.rot13.invalid> wrote:
>>> Stachu 'Dozzie' K.<d...@g...eat.some.screws.spammer.invalid> wrote:
>>>> On 2012-01-04, Bartlomiej Lidke<o...@r...cy.rot13.invalid> wrote:
>>>>> po trzecie: porozmawiaj z adobem (libssl, libcurl, itp), autorami bibble
>>>>> (libQT*), blendera (python), googlem (libqt*), ibm-em (libssl, libxml2,
>>>>> i wiele innych), ingresem (libxerces), libreoffice (np. libxml2) i powiedz
>>>>> im ze sa bardzo sredniowieczni (to bo szybkim przeleceniu /opt-a)
>>>>
>>>> Wiesz, też mogę przytoczyć trochę softu robiącego podobny kretynizm.
>>>> Tylko co to ma do rzeczy? To kretynizm i tyle.
>>>
>>> ten kretynizm uratowalby mnie przed konfliktem svn vs ssh na jaki wpadlem.
>>> jesli minusy takiego podejscia sa wg Ciebie wieksze od plusow to chetnie
>>> sie czegos nowego dowiem
>>
>> To co napotkałeś, to zwykły błąd maintainera. Albo skutek używania
>> nieoficjalnego repozytorium bez skoordynowanego zarządzania
>> przyjmowanymi pakietami. Albo skutek używania zestawu nieskoordynowanych
>> ze sobą nieoficjalnych repozytoriów. To się naprawia w inny sposób,
>> a nie ładując zależności do wnętrza pakietu.
>>
> Troche p* glupoty. Nie kazdy program jest open source, nie kazdy jest
> kompatebilny z nowsza wersja biblioteki. Posiadanie kilku wersji tej
> samiej biblioteki jest po prostu wymuszane tak czy siak. Dyski jak na
> potrzeby binariow sa generalnie tanie, wrzucenie wszystkich biblotek do
> katalogu z applikacja (wlasnie w punktu widzenia admina) zalatwia
> problem niezgodnosci pomiedzy biliotekami.

To na *uj w ogóle komu biblioteki dynamiczne, poza ładowaniem pluginów?
Trochę p* głupoty.

Był już taki pomysł na dystrybucję Linuksa, która miała mieć wszystko
linkowane statycznie. Zdaje się że nie wypalił.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu 2012-01-05 09:45, Marek Borowski pisze:
> On 04-01-2012 11:08, Stachu 'Dozzie' K. wrote:
[...]
>> To co napotkałeś, to zwykły błąd maintainera. Albo skutek używania
>> nieoficjalnego repozytorium bez skoordynowanego zarządzania
>> przyjmowanymi pakietami. Albo skutek używania zestawu nieskoordynowanych
>> ze sobą nieoficjalnych repozytoriów. To się naprawia w inny sposób,
>> a nie ładując zależności do wnętrza pakietu.
>>
> Troche p* glupoty. Nie kazdy program jest open source, nie kazdy jest
> kompatebilny z nowsza wersja biblioteki. Posiadanie kilku wersji tej
> samiej biblioteki jest po prostu wymuszane tak czy siak. Dyski jak na
> potrzeby binariow sa generalnie tanie, wrzucenie wszystkich biblotek do
> katalogu z applikacja (wlasnie w punktu widzenia admina) zalatwia
> problem niezgodnosci pomiedzy biliotekami.

Polecam w takim przypadku szybko zakutalizować popularną bibliotekę,
w której wykryto i załatano poważną dziurę w bezpieczeństwie, a używaną
przez fafnaście aplikacji na serwerze.

--
Paweł Kierski
n...@p...net

do góry

On Jan 3, 9:39 pm, A.L. <l...@a...com> wrote:
> On Tue, 3 Jan 2012 16:47:11 +0000 (UTC), Adam Przybyla
>
>
>
>
>
>
>
>
>
> <a...@r...pl> wrote:
> >In pl.comp.programming Szyk <s...@o...pl> wrote:
> >> Witam
>
> >> W systemie Windows mo na spotka r ne kompilatory C++. Np. Visual i
> >> GNU. Kompiluj one programy w postaci exe lub dll. A zatem:
>
> >> Dlaczego programy i biblioteki skompilowane r nymi kompilatorami C++
> >> nie s ze sob kompatybilne?
>
> >> Gdzie jest s aby punkt specyfikacji? Czy standard C++ jest nie
> >> precyzyjny? Czy mo e standard plik w DLL jest nie precyzyjny?
>
> >> Czy s takie systemy operacyjne w kt rych programy (i biblioteki
> >> wsp dzielone) kompilowane r nymi kompilatorami C++ s ze sob
> >> kompatybilne?
> >    ... oczywiscie, pod kazdym Linuksem. Z powazaniem
> >                                                            Adam Przybyla
>
> Echem.... Ja uzywam pewnego komercjalnego oprogramwoania. Platne, 5
> cyfrowo w dolarach. Maja 5 roznych wersji binarow na rozne Linuksy. Na
> ten sam pecet

Opera też tak ma i co z tego?

do góry

Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid> wrote:
> On 2012-01-05, Marek Borowski <m...@b...com.nospam> wrote:
>> Troche p* glupoty. Nie kazdy program jest open source, nie kazdy jest
>> kompatebilny z nowsza wersja biblioteki. Posiadanie kilku wersji tej
>> samiej biblioteki jest po prostu wymuszane tak czy siak. Dyski jak na
>> potrzeby binariow sa generalnie tanie, wrzucenie wszystkich biblotek do
>> katalogu z applikacja (wlasnie w punktu widzenia admina) zalatwia
>> problem niezgodnosci pomiedzy biliotekami.
>
> To na *uj w ogóle komu biblioteki dynamiczne, poza ładowaniem pluginów?
> Trochę p* głupoty.

ciagle uparcie patrzysz na swiat z pozycji maintainera opensourcowego
pakietu czy czegos w tym stylu. to ze jakistam 'wget' uzywa sobie libssl-a
to pieknie. tak ma byc. ale sa konkretne argumenty za uzyciem innego podejscia
w okreslonych sytuacjach. przyklady podalem w watku

> Był już taki pomysł na dystrybucję Linuksa, która miała mieć wszystko
> linkowane statycznie. Zdaje się że nie wypalił.

zdaje sie, ze nikt tutaj o czyms takim nie mowil

--
butthead
o 'Niesmiertelnym' (c) Pleciucha:
"Jest to jedyny film, w którym Szkot gra Egipcjanina, który jest Hiszpanem
i Francuz, który gra Szkota, który jest Nowojorczykiem..."

do góry

Paweł Kierski <n...@p...net> wrote:
> Polecam w takim przypadku szybko zakutalizować popularną bibliotekę,
> w której wykryto i załatano poważną dziurę w bezpieczeństwie, a używaną
> przez fafnaście aplikacji na serwerze.

latasz normalnie mechanizmami dystrybucji. z drugiej strony dostawca
komercyjnego programu ktory uzywa tejze biblioteki informuje Cie mailem
ze jest poprawka. dla nich to prosty rachunek zyskow i strat:
- maja jedna wersje biblioteki na roznych konfiguracjach klienta
- maja przetestowana swoja aplikacje z ta jedna jedyna wersja
- jesli klient zglasza blad to automatycznie odrzucaja klase bledu
typu: "nie mozemy zreplikowac poniewaz klient ma inny zestaw bibliotek"
- powyzsze kosztem tego ze musza byc podpieci pod powiadamianie o bledach
z uzywanych bibliotek i na podstawie opisow bledow decyduja czy jest
to cos co tknie ich klientow czy nie i ewentualnie generuja patcha
do swojej aplikacji

wielu sie decyduje na takie podejscie i ja im sie nie dziwie

--
butthead
o 'Niesmiertelnym' (c) Pleciucha:
"Jest to jedyny film, w którym Szkot gra Egipcjanina, który jest Hiszpanem
i Francuz, który gra Szkota, który jest Nowojorczykiem..."

do góry

On Thu, 5 Jan 2012 13:10:16 -0800 (PST), Sektor van Skijlen
<e...@g...com> wrote:

>On Jan 3, 9:39 pm, A.L. <l...@a...com> wrote:
>> On Tue, 3 Jan 2012 16:47:11 +0000 (UTC), Adam Przybyla
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> <a...@r...pl> wrote:
>> >In pl.comp.programming Szyk <s...@o...pl> wrote:
>> >> Witam
>>
>> >> W systemie Windows mo na spotka r ne kompilatory C++. Np. Visual i
>> >> GNU. Kompiluj one programy w postaci exe lub dll. A zatem:
>>
>> >> Dlaczego programy i biblioteki skompilowane r nymi kompilatorami C++
>> >> nie s ze sob kompatybilne?
>>
>> >> Gdzie jest s aby punkt specyfikacji? Czy standard C++ jest nie
>> >> precyzyjny? Czy mo e standard plik w DLL jest nie precyzyjny?
>>
>> >> Czy s takie systemy operacyjne w kt rych programy (i biblioteki
>> >> wsp dzielone) kompilowane r nymi kompilatorami C++ s ze sob
>> >> kompatybilne?
>> >    ... oczywiscie, pod kazdym Linuksem. Z powazaniem
>> >                                                            Adam Przybyla
>>
>> Echem.... Ja uzywam pewnego komercjalnego oprogramwoania. Platne, 5
>> cyfrowo w dolarach. Maja 5 roznych wersji binarow na rozne Linuksy. Na
>> ten sam pecet
>
>Opera też tak ma i co z tego?

Nic.

A.L.

do góry