Linux Standard Base 3.2 wydane

Według mnie lepiej by było stworzyć dystrybucję hybrydową, która obsługiwałaby RPM, DEB, TGZ, PBI i porty… Każdy mógłby wybrać coś dla siebie, a jeśli np. w repozytorium RPM nie będzie szukanego pakietu, to najprawdopodobniej znajdzie go w repozyturium DEB/TGZ/PBI, i na odwrót.

to zrób

@Z: Najwięcej zalet mają ebuildy bo mogą służyć jako spoiwo dla różnych systemów pakietów.

@Emdé: Coś takiego już istnieje (teoretycznie). Nawet brak zależności w .tgz nie jest problemem, bo zależności są opisane w ebuildach. Tylko jakoś nikt nie może tego zauważyć. Nawet developerzy Gentoo nie są tym zainteresowani.

No, ale… przecież ja właśnie o tym mówię. Mianowicie: po co nam te różne systemy pakietów?

Oczywiście: kiedyś-tam każdy zespół opracowywał swój system – ja nie przeczę, że konkurencja jest rzeczą zdrową. Po latach z tej konkurencji – jak mi się wydaje – zwycięsko wyszedł "deb", jako system dający największe możliwości. Jaki jest sens utrzymywać te pozostałe, otwarcie powiedzmy, że po prostu gorsze? Że niby "tyle pracy w to poszło, więc szkoda jakoś zarzucić"?

Problem w tym, że tobie tak się zdaje. A innym (w tym mi) może się zdawać coś zupełnie innego.

Po pierwsze konkurencja jest niezbędna. Popatrz co się dzieje z X11. Poza dołożeniem obsługi AIGLX nie pojawiło się tam nic nowego od bardzo długiego czasu i nie ma żadnego pomysłu jak rozwinąć iksy w nowoczesną technologię. Przecież to pomysł z lat 80-ych dwudziestego wieku.

Po drugie deb nie wyszedł zwycięsko z żadnej konkurencji. Nawet na poziomie OSnews nie dojdziemy do porozumienia, który system pakietów jest najlepszy. Poza tym jeśli porównać ilość dystrybucji korzystających z deb i z rpm to chyba wygra rpm.

Po trzecie LSB raczej nic nie zmieni. Open source to nie Windows. Microsoft może sobie najpierw wymyślić standard, potem go zaimplementować, a potem zmusić użytkowników i producentów software i hardware do używania go. W open source zawsze będzie różnorodność, bo open source powstaje oddolnie (w większości tworzą go użytkownicy). Jak mi się zachce to mogę wypuścić własną wersję kernela zupełnie niekompatybilną z LSB. LSB ma sens jedynie jako potwierdzenie faktycznie używanych standardów.

@jr: Sa pomysly, jak rozwinac X11. Bardzo dobre pomysly. Nie ma natomiast kasy, zeby zaplacic odpowiednio duzej ilosci developerow za ich odpowiednio szybka realizacje, wiec sprawa posuwa sie do przodu dosyc powoli.

No to miło słyszeć. Pieniądze się znajdą. Open source zdobywa coraz większy rynek i ktoś w końcu wyłoży kasę.

Po pierwsze konkurencja jest niezbędna.

Nie zgadzam się. Paczki to pewien format zapisu, a więc sytuacją optymalną będzie, jeżeli będzie możliwość używania jednego formatu w większości popularnych dystrybucji. Nie może być tak, że ZU musi ściągać źródła i kompilować jakąś aplikację tylko dlatego, że twórca nie udostępnia odpowiedniego formatu paczki. Z X11 jest tak samo. W tak podstawowych sprawach jak paczki, obsługa trybu graficznego, dźwięk muszą być pojedyńcze standardy, albo zaraz okaże się, że poszczególne dystrybucje Linuksa są ze sobą całkowicie niekompatybilne.

<blockquotePo trzecie LSB raczej nic nie zmieni. Nie chodzi o to, żeby zastosowały się do tego wszystkie dystrybucje, a tylko te zaprojektowane z myślą o ZU, którego naprawdę nie obchodzi, to czy paczka .deb kompiluje się 0.0001% szybciej od .rpm. On chce mieć łatwą instalację i możliwość użycia każdej paczki jaką znajdzie w necie.

Standard może być jeden, ale to musi wyjść w praniu. Jeśli LSB zarządzi odgórnie oficjalny standard to będzie to tylko martwy zapis. I w żadnym wypadku użytkownik nie powinien ściągać softu tak jak to jest w Windows. Nie ma konieczności tworzenia repozytorium z każdym dostępnym oprogramowaniem, wystarczy że w systemie będzie informacja skąd ściągnąć zaufaną wersję (np. ze strony autora/producenta). W przeciwnym razie okaże się, że linuks wcale nie jest taki bezpieczny, a wirusy świetnie sobie na nim radzą.

Myślę, że gdyby chłopaki od Ubuntu, SUSE, Mandrivy i RH się dogadali, spokojnie mogliby przepchnąć dowolny system pakietów.

Faktem jest, że LSB określa system pakietów.

package file format

@Thar

Problem w tym, że tobie tak się zdaje. A innym (w tym mi) może się zdawać coś zupełnie innego.

A, tak – tyle, że ja moje wyobrażenia uzasadniłem. A takie pyskowanie, jak w cytacie – to może jest dobre do podstawówki, na " `dyskusję' na przerwie przed WF-em".

@jr

Po pierwsze konkurencja jest niezbędna.

Znaczy: niech się dalej ZU męczą z rozmaitymi formatami pakietów – "wszak cierpią w słusznej sprawie"?

Popatrz co się dzieje z X11. Poza dołożeniem obsługi AIGLX [..]

Tak, to rzeczywiście "bardzo na temat"…

Po drugie deb nie wyszedł zwycięsko z żadnej konkurencji. Nawet na poziomie OSnews nie dojdziemy do porozumienia, który system pakietów jest najlepszy.

No faktycznie – "dyskutując" w taki sposób, jak widać w przytoczonych cytatach, to faktycznie ciężko będzie (brak jakichkolwiek kontrargumentów, albo mówienie o czymkolwiek; np. o X11).

Poza tym jeśli porównać ilość dystrybucji korzystających z deb i z rpm to chyba wygra rpm.

"jedzmy … – przecież miliony much nie mogą się mylić"?

Znaczy: niech się dalej ZU męczą z rozmaitymi formatami pakietów – “wszak cierpią w słusznej sprawie”?

Może powstać dystrybucja, która używa wszystkich rodzajów pakietowania i ZU się nie będą męczyć. Konkurencja daje napęd do rozwoju. Chyba wiesz jak działa wolny rynek? Zresztą, nawet gdyby się pojawił jeden system pakietowania, to zaraz by ktoś zrobił forka (jak to w open source), więc pomysł z założenia utopijny.

"Popatrz co się dzieje z X11. Poza dołożeniem obsługi AIGLX [..]"

Tak, to rzeczywiście “bardzo na temat”…

Xorg nie ma konkurencji. Czego nie rozumiesz?

"Po drugie deb nie wyszedł zwycięsko z żadnej konkurencji. Nawet na poziomie OSnews nie dojdziemy do porozumienia, który system pakietów jest najlepszy."

No faktycznie – “dyskutując” w taki sposób, jak widać w przytoczonych cytatach, to faktycznie ciężko będzie

No przecież jakoś trzeba skłonić developerów do używania wspólnego systemu pakietów, więc wypadałoby, żeby doszli między sobą do porozumienia. Na podstawie naszej dyskusji robię estymację i twierdzę, że developerzy nigdy się w tej kwestii nie dogadają.

“jedzmy … – przecież miliony much nie mogą się mylić”?

To samo mogę powiedzieć o debach. Ja używam ebuildów

Xorg nie ma konkurencji. Czego nie rozumiesz?

Tak, to cały czas na temat.

Na takie "argumenty", jak powyższy i pozostałe, to szkoda klawiatury. Zresztą, na zaczepki typu "czego nie rozumiesz" także.

@Z

Nie wiem, gdzie widzisz pyskowanie z mojej strony. W każdym razie, użycie pseudoerystycznej zagrywki polegającej na porównaniu adwersarza do osoby nieletniej jest poniżej mojego poziomu. EOT.

Jakieś herezje straszne opowiadasz. Załóżmy że chcę zainstalować sobie applet do wifi. Ten applet zależy od wpa_supplicant, więc w sobie powinien mieć taki pakiet, ale wpa_supplicant zależy od >=linux-krenel-2.6.22, więc pakiet wpa_supplicant ma w sobie pakiet z jądrem, ale … itd. Zależności zmyślam, bo mi się nie chce szukać prawdziwych. Nie będę tłumaczył dlaczego ta idea jest niewykonalna.

Teraz wchodząc na stronę Skype, X-Moto, VMWare, Firefoxa, Opery mamy:

1 wersję dla Windows, 1 wersję dla Maka i dużo wersja dla Linuksa, albo (jak w przypadku FF) coś czego się nie instaluje.

Pierwszy błąd jaki robisz to założenie, że użytkownik powinien sobie aplikację sam ściągnąć. Od tego jest manager pakietów i większość z wymienionych przez Ciebie programów jest w dowolnej dystrybucji. Z tymi których nie ma jest problem. Tutaj błąd robią producenci software'u. Dostarczaniem pakietów powinni się zajmować developerzy dystrybucji a producenci powinni dostarczyć binarki, które można "zapakować" w pakiet i rozprowadzać bez problemów licencyjnych. Z resztą nawet z tym co jest teraz można sobie poradzić. W Gentoo są w dystrybucji wszystkie wymienione przez ciebie programy. Tam nie ma problemu z licencjami, bo pakiet nie zawiera treści (binarek) tylko informację skąd je wziąć i co z nimi zrobić. Niestety nikt nie chce dostrzec zalet portage i zrobić na jego podstawie binarnej dystrybucji.

"Tam nie ma problemu z licencjami, bo pakiet nie zawiera treści (binarek) tylko informację skąd je wziąć i co z nimi zrobić. Niestety nikt nie chce dostrzec zalet portage i zrobić na jego podstawie binarnej dystrybucji."

Afaik w debach tez tak jest

Tylko ten model ma jedną poważną wadę – wymaga ingerencji osób trzecich. Teraz to nie jest problem, ale jak Linuksy zdobędą popularność i soft zacznie lawinowo powstawać to twórcy dystrybucji się nie wyrobią w wydawaniu paczek dla swojej dystrybucji – zabije to też małe distra, których developerzy nie mogą sobie pozwolić na paczkowanie milionów programów. Model o którym mówisz doskonale sprawdza się dla oprogramowania rdzennego dystrybucji, czyli X Window, KDE, GNOME, … i innych pakietów dostarczonych wraz z dystrybucją – paczka zoptymalizowana pod konkretną dystrybucję. Rzecz w tym abym ja jako developer mógł stworzyć jedną paczkę z aplikacją, która gwarantuje mi w 100%, że ten program będzie działać na wszystkich Linuksach zgodnych z tym systemem pakietowym, w dodatku bez dostępu do internetu (to też jest ważne, niestety u ludzi bez neta nawet nie instaluje Linuksa, bo to nie ma sensu), bo jak ktoś nie ma dostępu do internetu i dostanie program to jak mu się dociągną zależności?

Załóżmy że chcę zainstalować sobie applet do wifi. Ten applet zależy od wpa_supplicant, więc w sobie powinien mieć taki pakiet, ale wpa_supplicant zależy od >=linux-krenel-2.6.22, więc pakiet wpa_supplicant ma w sobie pakiet z jądrem, ale … itd.

Standard takiego systemu pakietów powinien stwierdzać jakie pakiety muszą być zainstalowane w systemie, czyli jakich bibliotek nie trzeba osadzać w paczce. Oczywiście osadzanie linux-kernel jest bez sensu (co to za linux bez linuksa?), co do wpa_supplicant – kwestia dyskusyjna.

:

Ponadto powstaje inny problem, np. kiedyś zainstalowałem sobie VMWare, które ładnie sobie działało, aż do upgrejdu GTK, które coś pozmieniało w API. Gdyby VMWare było zainstalowane w oparciu o taki system paczek, to program przed uruchomieniem miał by odpalany skrypt testujący jakich bibliotek użyć, systemowych czy z paczki i po upgrejdzie GTK rozpoznał by niekompatybilną bibliotekę systemową i użył by własnej. Tak to musiałem czekać aż ukaże się wersja kompatybilna z tym nowszym GTK. Taki problem nie zdarzył by się ani w Windows (bo program ma zależności zazwyczaj w swoim katalogu) ani na MacOSX (bo wymagane biblioteki są w katalogu Frameworks paczki z aplikacją).

:

Jeszcze jedno – nigdy nie obrzucam kogoś hasłem, że wygaduje herezje, jeśli ten uzasadnia swoje stwierdzenie.

@Theq: Wiem, ale to jednak nie to. Na przykład CrossOverOffice nie jest dostępny do ściągnięcia i deba pewnie nie ma, a ebuild jest. Przy instalacji napisze żebyś odpowiedni plik wrzucił do odpowiedniego katalogu i go zainstaluje. Pod Gentoo po prostu nie ma czegoś takiego jak program spoza dystrybucji. Jeśli czegoś nie ma oficjalnie to na pewno ktoś już napisał ebuilda. Co prawda trzeba go wtedy znaleźć samodzielnie, ale wszystko masz w systemie.

Tylko ten model ma jedną poważną wadę – wymaga ingerencji osób trzecich.

Dla mnie to zaleta. Kolejna para oczu, która testuje i dba o bezpieczeństwo mojego systemu.

…ale jak Linuksy zdobędą popularność i soft zacznie lawinowo powstawać…

W tym wypadku tym bardziej potrzebne będą oficjalne repozytoria, bo zwiększy się popyt na malware. Jeśli będzie można ściągnąć program z dowolnej stronki i go zainstalować, to będziemy mieli sytuację podobną do tej znanej z Windows. Poza tym jeśli będzie więcej użytkowników to i developerów będzie więcej.

Oczywiście osadzanie linux-kernel jest bez sensu (co to za linux bez linuksa?)

Dlatego zaznaczyłem (niezbyt jasno, sory) że kernel ma być w wersji co najmniej 2.6.22. Tego nie można zagwarantować, bo nawet w dystrybucji binarnej możesz mieć starszy kernel.

np. kiedyś zainstalowałem sobie VMWare, które ładnie sobie działało, aż do upgrejdu GTK,

A ten VMware był instalowany z dystrybucji? Jeśli tak to był to zwykły babol, ale nie świadczy to błędach w założeniach tylko o czyimś niedopatrzeniu. Jeśli był spoza dystrybucji to przesiądź się na Gentoo

Taki problem nie zdarzył by się ani w Windows …

W Windows i OSX sprawa jest o wiele prostsza, bo tam zawartość systemu jest przewidywalna. Producenci używają standardowych bibliotek i mają pewność, że w systemie one są. Jeśli używają niestandardowych to biblioteki dają razem z programem. W linuksie nie ma czegoś takiego. Z wersji na wersję może się zmienić ABI.

Załóżmy, że robisz upgrade i wszystkie programy spoza dystrybucji nagle stwierdzają, że nie działają z nowym GTK i wszystkie ładują swoją wersję do ramu. Nagle się okazuje, że w pamięci masz 20 kopii starego GTK w tej samej wersji a wersja systemowa leży na dysku i czeka na lepsze czasy.

Jeszcze jedno – nigdy nie obrzucam kogoś hasłem, że wygaduje herezje, jeśli ten uzasadnia swoje stwierdzenie.

Sory, nie miało być personalnie. Po prostu twoje podejście przewraca do góry nogami model rozwoju dystrybucji linuksa, więc dla mnie to są herezje.

Dla mnie to zaleta. Kolejna para oczu, która testuje i dba o bezpieczeństwo mojego systemu.

Oczywiście mówisz to wszystko z założeniem, że każda dystrubucja się zainteresuje danym "spsiałym" programem. Czemu spsiałym? A to dlatego, że to jest nowa rzecz, nikt o niej nie wie to po co mają paczkować? Powstaje błędne koło.

@Rsh: Dystrybucja nie musi się interesować. Wystarczy, że jakiś użytkownik wystawi prywatne repozytorium. Jeśli wrzuci tam jakieś śmieci to takie repozytorium długo nie pożyje a wkurzeni użytkownicy mu zlinczują serwer. Jest to przynajmniej jakiekolwiek zabezpieczenie w przeciwieństwie do ściągania softu z jakiegoś noname.programy.dla.linuksa.com. Z takiej strony możesz ściągnąć zainfekowaną paczkę nawet z popularnym softem.

BTW – świetny system ma pod tym względem Arch. Ściągasz wszystko z oficjalnej strony projektu (nawet soft niespełniający podstawowych kryteriów pakietowania) ale wszystko się dzieje transparentnie i użytkownicy na bieżąco wrzucają poprawki. Mimo, że nie ma żadnych gwarancji, że nie ściągniesz malware to jest to dość bezpieczne.

@Rsh:

Jak nikogo nie interesuje dany program to po co go wrzucać? Jak kogoś bardzo zainteresuje – to albo zrobi paczkę (jeśli umie) albo da znać że coś takiego by się przydało (jeśli będzie mu na tym bardzo zależało). Gdy nikt mimo to się nie zainteresuje – zmieni dystrybucję. I pozostanie tyle systemów paczek, ile będzie nadążało za softem. Pozostałe zostaną w tyle i w końcu odpadną. Co za problem?

Imo, rozwiązanie typu dodawanie repozytoriów ala Ubuntu jest dośc wnerwiające – co to za przyjazność "odpal terminal i przeklep następujące komendy" – od razu mówię, że Ubuntu/Debiana nie używałem, ale tak to wygląda na różnych tutorialach jakie czasami się spotyka. Powinno to działać na zasadzie dwukliku i prośby o hasło + jakaś podstawowa informacja co zostanie wykonane. Może taka pseudo-paczka mogłaby zawierać tylko dane na temat repozytorium, na którym się znajduje? Oczywiście znowu podkreślam, że dwuklikowa instalacja byłaby optymalna.

@jr: taki system pakowania sprawdzi się tylko dla serwerów. Oprogramowanie użytkowe liczy się w milionach i cay czas powstaje nowe. User Ubuntu będzie się denerwował, że w repo openSuSE jest program którego nie ma w repo Ubu i vice-versa, bo jakiś fan programu X, który potrafi robić paczki, będzie miał openSuSE, ale nie będzie takiego fana z Ubunu, dlatego to nie jest rozwiązanie! Ja bardzo często spotykałem się z programami, które miały paczki, np. dla Ubuntu i Fedory, ale nie dla openSuSE. Najlepiej jak by był jeden uniwersalny format pakietu który jednym przeciągnięciem myszki instalujesz w systemie, bez dostępu do internetu. Taie mało proste założenie, które spełnia Windows i Mac OS X na desktopie.

Jeśli był spoza dystrybucji to przesiądź się na Gentoo

Równie dobrze mogłeś zmienić nazwę Gentoo na Windows. Ja nie chcę używać Gentoo, bo:

1. nie mam czasu na kompilację

2. chcę openSuSE, albo inną dystrybucję

3. chcę ten sam program tak samo zainstalować koledze, który ma inną dystrybucję niż ja

:

Aktualne systemy pakietowe są dobre do oprogramowania systemowego, czyli takiego, które integruje się z systemem w mocnym stopniu (np. manager okien, shell, pulpit, serwer okien, jądro). Mogą to być również zwykłe aplikacje użytkowe, zoptymalizowane pod konkretną dystrybucję, ale nie można zmuszać producentów softwareu do paczkowania dla xyz dystrybucji, a niezależny fan programu nie zapewni dobrego supportu. Taki model jest zbyt zawodny i niczego nie gwarantuje – wystarczy, że fan danego distra zmienił swoje upodobania. Takie coś nie pozwoli wybić się nowym programom, ani nowym dystrybucjom. Jeśli nowe distro mogło by używać tysięcy uniwersalnych paczek aplikacji to miało by o wiele większe szanse na zaistnienie.

:

PS. ten VMWare był ściągnięty ze strony producenta w postaci uniwersalnego skryptu instalatora, który nie zawierał zależności.

:

PS2. LSB wie że problem jest i aktualnie pracuje nad jakimś systemem pakietowym dla desktopa, ale nie wiem na jakich zasadach ma to działać.

@jr:

Po prostu twoje podejście przewraca do góry nogami model rozwoju dystrybucji linuksa, więc dla mnie to są herezje.

Właśnie w tym rzecz, że nie. Wszystko zostaje jak jest, ale dodatkowo jest jeden uniwersalny standard pakietów dla wszystkich dystrybucji desktopowych, łatwy w użyciu dla zwykłego zjadacza chleba, który nie chce mieć najmniejszego pojęcia o komputerze i systemie.

Może by tak najpierw spróbować pobawić się w deweloperkę jakiejś dystrybucji, a potem, mając pojęcie o czym się mówi, wypowiadać się? Biblioteki można linkować statycznie lub dynamicznie. Praktycznie wszystkie dystrybucje linkują wyłącznie (pewne uproszczenie) dynamicznie. Efektem tego jest to, że pakiet zależny od jakiś bibliotek, zależy często od konkretnej wersji biblioteki – tej z którą był kompilowany. Czyli i tak w systemie musi być zainstalowana wersja biblioteki wybrana przez kompilującego program. Mało tego, na poziomie źródeł też mogą wystąpić niezgodności wymagające odpowiednich łatek. Ergo, jedyną sensowną metodą jest dostarczanie pakietów przez twórców dystrybucji lub dostarczanie przez producenta programu pakietów dla konkretnej wersji konkretnej dystrybucji i tak właśnie się w realnym świecie dzieje. Ten brak przenośności pakietów binarnych pomiędzy dystrybucjami nawet przy identycznym systemie pakowania implikuje kompletną dowolność systemu pakietowania przez twórców dystrybucji.

P.S.

do zwolenników formatu deb: Czas, a tym samym koszty utrzymywania pakietów źródłowych deb są znacznie wyższe niż w przypadku rpm. Debian mający tysiące deweloperów może sobie na to pozwolić, a np takie PLD już nie, a mimo to ma znacznie lepiej rozwiązane problemy zależności i wyszukiwania pakietów.

@qwark: tak się składa, że z zawodu jestem programistom i wiem czym różni się linkowanie statyczne od dynamicznego. Niestety programy zlinkowane statycznie pożerają więcej pamięci, bo kod biblioteki jest załadowany drugi raz do pamięci RAM. Niestety owocuje to mniejszą wydajnością systemu operacyjnego, który jest zmuszony częściej używać pliku/partycji wymiany. Linkowanie statyczne to jedynie półśrodek, a nie rozwiązanie.

:

Wg. mnie system pakietów dla desktopa powinien:

- być niezależny od dystrybucji i nie ingerować w systemowe paczki dystrybucji

- w miarę możliwości używać bibliotek systemowych, dopiero w drugiej kolejności tych dostarczonych wraz z aplikacją

- jeśli więcej programów ma tę samą bibliotekę w wymaganiach to powinien uwspulnić ją dla wszystkich aplikacji zainstalowanych z uniwersalnych paczek

- być standardem LSB (producenci softwareu muszą mieć mocny i pewny standard)

- banalny w użyciu dla zwykłego użytkownika (np. przez przeciągnij i upuść)

- nie wymagać internetu do normalnego działania

Jeżeli systemy linuksowe mają być kiedykolwiek _powszechnie_ używane przez _zwykłych_ użytkowników, muszą być prostsze nie tylko w obsłudze ale przede wszystkim w utrzymaniu. Pod słowem utrzymanie należy rozumieć instalowanie nowych aplikacji i instalowanie nowych urządzeń. Póki co na zabawe linuksem może pozwolić sobie osoba, która ma zacięcie informatyczne lub poprostu posiadająca odpowiednią wiedzę. W innym przypadku, na _domowych_ biurkach linuks bedzie niszową pozycją. Pamiętajmy, że konkurencja może być zachowana jeżeli jest jeden głowny ale darmowy i otawarty standard. Dlatego założenia mario mni się podobają i chciałbym, żeby w tym kierunku szedł rozwój systemu. W innym przypadku przegoni go HaikuOS

@mario:

Wg. mnie system pakietów dla desktopa powinien:

– być niezależny od dystrybucji i nie ingerować w systemowe paczki dystrybucji

Nie powinien być niezależny bo się zrobi taki sam bajzel jaki jest teraz na windows. Pisałem już o tym, a ponieważ nie podałeś kontrargumentów to rozumiem, że się na to godzisz.

- w miarę możliwości używać bibliotek systemowych, dopiero w drugiej kolejności tych dostarczonych wraz z aplikacją

O tym też już pisałem. Nie dość, że będzie bajzel na dysku, bo każdy program będzie miał komplet własnych bibliotek, to po aktualizacji do niekompatybilnej wersji biblioteki (przecież jest niezależny od dystrybucji) to wszystko wyląduje w ramie. A co z upgrade'ami tych programów? Mam biegać ze strony na stronę i sprawdzać czy się nowe wersje pojawiły? Czy może tak jak na windows jakieś wkurzające popupy?

Weź to jakoś dokładniej opisz, bo to o czym teraz mówisz nie trzyma się kupy.

- jeśli więcej programów ma tę samą bibliotekę w wymaganiach to powinien uwspulnić ją dla wszystkich aplikacji zainstalowanych z uniwersalnych paczek

Czyli aplikacja spoza dystrybucji ma mieć prawo do mieszania mi w systemie? Świetny pomysł. Bajzel będzie jeszcze większy niż na Windows.

.

Wspólny standard pakietowania może się sprawdzić, ale musi być zależny od dystrybucji. To znaczy developer bierze uniwersalną binarkę, testuje i jeśli wszystko działa to dodaje do repozytorium. Pracy niewiele ale jest gwarancja, że soft jest odpowiedniej jakości.

@jr:

Nie powinien być niezależny bo się zrobi taki sam bajzel jaki jest teraz na windows. Pisałem już o tym, a ponieważ nie podałeś kontrargumentów to rozumiem, że się na to godzisz.

Windows to jeszcze nie to, wolał bym coś bardziej w stronę Mac OS X. W Mac OS X aplikacja to specjalny folder, którego skopiowanie do katalogu /Applications oznacza instalację. A co do wirusów, o tak samo jak możesz ściągnąć paczkę z niepewnego źródła, tak samo możesz ściągnąć rpm/deb z niepewnego repozytorium. Prawdę mówiąc sztuczne poczucie bezpieczeństwa jest jeszcze gorsze niż dbanie o to bezpieczeństwo i ściąganie paczek tylko z pewnych źródeł. a naprawdę poza oficjalnymi repo nie możesz być pewien. Nie masz też pewności, że ktoś nie włamał się na repo i nie zaraził paczek, albo maszyna paczkującego jest zarażona i on nieświadomy udostępnia te paczki milionom.

Nie dość, że będzie bajzel na dysku, bo każdy program będzie miał komplet własnych bibliotek, to po aktualizacji do niekompatybilnej wersji biblioteki (przecież jest niezależny od dystrybucji) to wszystko wyląduje w ramie.

Nie wszystko tylko to co zaktualizowałeś i po aktualizacji nie jest kompatybilne. Za to się bez problemu uruchomi, a Ty nie musisz stawać na głowie aby rozwiązywać głupie problemy. Przeciętny laik, który wie, że coś potrafisz zadzwoni wtedy po Ciebie, zamiast dać Ci spokój.

A co z upgrade’ami tych programów? Mam biegać ze strony na stronę i sprawdzać czy się nowe wersje pojawiły?

Nic nie stoi na przeszkodzie aby taka aplikacja miła w jakimś pliku XML opis i linki do serwera aktualizującego ją, a system paczek sprawdzał co jakiś czas dla wszystkich znajdujących się w katalogu /Applications czy są nowe wersje. Ściągane były by wprost z serwera producenta.

"jeśli więcej programów ma tę samą bibliotekę w wymaganiach to powinien uwspulnić ją dla wszystkich aplikacji zainstalowanych z uniwersalnych paczek"

Czyli aplikacja spoza dystrybucji ma mieć prawo do mieszania mi w systemie? Świetny pomysł. Bajzel będzie jeszcze większy niż na Windows.

Eehhh, nie zrozumiałeś. Przypuśćmy że mamy w systemie niwersalnych paczek zainstalowane 2 programy: A i B. Wymagają one biblioteki a.so w wersji od 1.0.0.0 do 1.5.0.0. To jeśli w systemie jest zainstalowana wersja a.so w wersji 1.5.0.0 to aplikacje A i B powinny używać tej biblioteki z systemu, ale jeśli nie ma biblioteki spełniającej ten warunek w systemie, to obie aplikacje używają biblioteki a.so np. z paczki aplikacji A, tak aby nadal starać się zużywać mniej ramu.

Wspólny standard pakietowania może się sprawdzić, ale musi być zależny od dystrybucji. To znaczy developer bierze uniwersalną binarkę, testuje i jeśli wszystko działa to dodaje do repozytorium. Pracy niewiele ale jest gwarancja, że soft jest odpowiedniej jakości.

Mój znajomy z mieszkania obok chciał Linuksa, ale jak sobie pomyślałem, że on nie ma Internetu i musiał bym do niego biegać z paczkami i ściągać je u mnie z netu to stwierdziłem, że dam sobie spokój. Rzecz w tym, że większość fajnego softu w dystrybucjach jest w repo, a ściąganie całych repo na 5 DVD, które zaraz będą w nowszych wersjach nie bardzo mi się uśmiecha. Szukanie paczek wg. zależności i ściąganie też do najszybszych i najprzyjemniejszych czynności nie należy, jak mam internet to robi to za mnie program. Dlatego system paczek powinien być obsługiwany tak samo prosto z dostępem do Internetu jak i bez dostępu do Internetu.

A co do wirusów, o tak samo jak możesz ściągnąć paczkę z niepewnego źródła, tak samo możesz ściągnąć rpm/deb z niepewnego repozytorium.

No właśnie nie tak samo. Open source opiera się na społeczności i społeczność natychmiast wykluczy ze swojego grona skompromitowanego użytkownika, a jego serwer zginie śmiercią tragiczną. Oczywiście całkowitej pewności nie ma nigdy, ale bezpieczeństwo można mierzyć i twój model jest dużo mniej bezpieczny od obecnego.

… aplikacje A i B powinny używać tej biblioteki z systemu, ale jeśli nie ma biblioteki spełniającej ten warunek w systemie, to obie aplikacje używają biblioteki a.so np. z paczki aplikacji A …

To jeszcze mi powiedz jak aplikacje się dogadają między sobą której wersji użyją? Wymagało by to w gruncie rzeczy oddzielnego managera pakietów, który zapanowałby nad tymi wszystkimi wersjami bibliotek. Kosztowało by to ogrom pracy, a zysk z tego niewielki.

Mój znajomy z mieszkania obok chciał Linuksa, ale jak sobie pomyślałem, że on nie ma Internetu i musiał bym do niego biegać z paczkami i ściągać je u mnie z netu to stwierdziłem, że dam sobie spokój.

A jak ten twój znajomy już sobie założy internet, to będzie Ci to do czegoś potrzebne? Bo to trochę wysiłek wyrzucony w błoto – projektować system, który nie będzie nikomu potrzeby za parę lat.

@mario,

Lepszego systemu instalacji pakietów od tych w Linuksach nie ma! A to przeciągnij i upuść to może jest dobre dla dzieci…

@jr:

To jeszcze mi powiedz jak aplikacje się dogadają między sobą której wersji użyją?

Przed odpaleniem aplikacji może być uruchamiany skrypt sprawdzający komplet bibliotek dla niej.

A jak ten twój znajomy już sobie założy internet, to będzie Ci to do czegoś potrzebne? Bo to trochę wysiłek wyrzucony w błoto – projektować system, który nie będzie nikomu potrzeby za parę lat.

Oczywiście, że będzie! Biorę CD z programami i instaluje z niej programy binarne na mojej dystrybucji, na dystrybucji kolegi i mogę to nawet zrobić na laptopie w pociągu bez dostępu do internetu, czy marnowania czasu na kompilowanie źródeł. Ponadto nie wyobrażam sobie jak będą działały managery pakietów jak ilość oprogramowania wzrośnie np. 10 krotnie. Sprawdzanie zależności będzie wymagało ogromny zasobów, a pobieranie list pakietów z internetu będzie dobrym sposobem na marnowanie łącza i kawę.

:

@term: powiedz to pani Zosi w sekretariacie. Instalacja oprogramowania powinna być właśnie prosta, tak aby nawet dziecko sobie z tym bez problemu poradziło.

@jr: system jest oprogramowaniem służącym do uruchamiania programów i to uruchamianie i instalacja programów powinny być jak najłatwiejsze w każdych warunkach. Nie jest to normalne aby od desktopowego systemu wymagać łącza internetowego, co innego serwer.

warto przeczytać jeszcze to:
http://julipedia.blogspot.com/2006/10/mac-os-x-vs…