Fedora i Ubuntu to dystrybucje Linuksa prawie identyczne. “Prawie”, bo każda dystrybucja ma swoje specyficzne cechy i pomimo, iż w większości są zbudowane na tym samym oprogramowaniu, występują poważne problemy z kompatybilnością. Lekarstwem ma być nowa wersja standardu LSB 4.
LSB, czyli Linux Standard Base, jest specyfikacją, która określa pewien poziom zgodności pomiędzy wszystkimi dystrybucjami Linuksa. Dokumentacja projektu LSB jest rozsądnie przygotowana i gdyby twórcy poszczególnych dystrybucji wzięli ją sobie do serca, to z pewnością system spod znaku pingwina stałby o półkę wyżej na rynku IT.
Ma się to zmienić z nadejściem LSB w wersji 4. Linux Standard Base ma wreszcie wyjść z cienia i w pełni rozwinąć swoje skrzydła, głównie dzięki wsparciu finansowemu Linux Foundation. Nad wersją 4 specyfikacji przez ostatnie 18 miesięcy pracowało 50 inżynierów w pełnym wymiarze godzin.
Pozostaje nam czekać na wydanie LSB 4, które ma nastąpić pod koniec bieżącego roku.
Szczegóły specyfikacji LSB 4: http://www.linuxfoundation.org/en/ProjectPlan40
Więcej informacji: http://www.internetnews.com/dev-news/art...+Linux.htm
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
OSnews.pl jest społecznościowym serwisem informacyjnym poświęconym oprogramowaniu, systemom operacyjnym i światowi IT. więcej »
Gdyby była rozsądnie przygotowana, to by wzięli. Niestety, LSB nie propaguje wzorców dobrych, a wzorce obecne w rozwiązaniach firm tworzących LSB (jak choćby głośne RPM-y jako domyślny system paczkowania).
A w czym ten RPM są gorsze od takich DEB-ów? Pytam, bo jestem ciekaw, a sam siedzę na Debianie.
Z tego co wiem to deby to po prostu archiwum (tak jak odf) i są szybsze.
a widziałeś opensuse 11. Jest znacznie szybsze od ubuntu mimo, że na RPMach
Ale nikt nie pisał, że dystrybucje oparte na rpm sa szybsze, bo to było by jakieś nieporozumienie.
Widziałem Opensuse i nie zauważyłem jakoś, by było szybsze… Wręcz istnieje opinia, że tojedna z najwolniejszych dystrybucji…
opensuse 11 jest znacznie szybsze od opensuse 10.3 i wcześniejszych
ale niestety wolniejsze niż opensuse 12… cóż, ideałów nie ma
a co ma system paczkowania do szybkości systemu jako takiego? przecież po instalacji z paczek, tych paczek już nie ma. Bo jeśli brać pod uwagę instalację z paczek rpm, a z paczek deb to na pentium dual core idzie szybciej z deba
.rpm to paczka binarna do obslugi ktorej potrzebujesz odpowiednich bibliotek/specjalizowanego programu.
.deb – to archiwum ar (takie same jak biblioteki .a), w ktorym masz dwa archiwa tar.gz – jedno zawierajace to, co bedzie rozpakowane do twojego filesystemu; drugie zawierajace opis pakietu + wszelkie skrypty pre/post-inst/rm/upgr.
niedzwiedz_2: szbykosc tu nie ma znaczenia.
aix: ale o czym ty piszesz? instalacji pakietow? czy moze o np. upgrade systemu (opensuse wykorzystuje do tego tzw. delta-rpm, ktore to sa ich wlasnym rozszerzeniem, calkowicie niezgodnym z innymi systemami rpm – btw. dzieki tym przyrostowym poprawkom, oczywiscie musi to byc szybsze).
Przykro mi ale bredzisz… Lepiej nie wypowiadaj się na tematy, o których nie masz pojęcia… Rpm-y to też archiwa, które oprócz plików, zawierają opis własnej zawartości, oraz wymaganych zależności. Nie ma najmniejszego problemu z wypakowaniem z rpm dowolnego pojedynczego pliku. Różnice w plikach deb i rpm-ach są ideowo drugorzędne. Większe różnice były (czas przeszły!) w zarządzaniu tymi pakietami-apt robił to mądrzej (zależności!) od rpm. Ale to czas przeszły: Mandriva używa urpmi, które jak twórca urpmi stwierdził “ma być tym dla rpm, czym apt dla deb” i tak się stało. Apt był trochę wydajniejszy, ze względu na bazę danych zależności o większej wydajności, ale to też w rpm-ach poprawiono. I nie pitol, że jakieś upgrade systemu przy rpm-ach wymaga jakiś specjalnych rpm-ów: nie ma to NIC wspólnego z rpm-ami, a tylko z programem nimi zarządzającymi. Dowodem na to jest to, że rpm na Mandrivie dalej jest i działa, choć po co go używać (no może po za katastrofami wymagającym rpm –rebuilddb) gdy jest urpmi. Niezliczona ilość użytkowników Madrivy robiła upgrade systemu: wystarczy tylko dodać jego nowe repozytoria, wgrać nowy kernel (zwykle, choć zmienia się to z wersji na wersję urpmi, aktualizację kernela trzeba wymusić ręcznie-domyślnie ta paczka nie podlega aktualizacji automatycznej) i zapodać coś w stylu urpmi –auto-select –force (tu force ma inne znaczenie niż w rpm: oznacza domyślnie ‘yes’ na pytania). Aktualizacja nie ma nic wspólnego ze “specjalnymi” rpm-ami, a tylko i wyłącznie z jakością programu nimi zarządzającego. Oczywiście zarządzanie pakietami nie wymaga, jak stwierdził błędnie kolejny mędrek wśród komentujących, żadnego połączenia z Internetem! Lokalna repozytorium jest tworzone na HD i jest tylko synchronizowane z nośnikami zewnętrznymi, np. sieciowymi jak ftp itp. Można włożyć DVD z paczkami rpm i Mandriva utworzy lokalne repozytorium dla tych rpm-ów (trochę to potrwa): w czasie późniejszej instalacji, urpmi poprosi o włożenie odpowiedniego nośnika. Gdy jest kilka rpm w tej samej wersji, urpmi preferuje na nośnikach stałych, następnie na wymiennych, a dalej sieć. Suma summarum: nie ma znaczących ideowych czy jakościowych różnic między deb i rpm i programami nimi zarządzającymi-który system jest lepszy, to moim zdaniem kwestia marketingu. Uważam natomiast, że powinien nastąpić wybór wspólnego rozwiązania dla wszystkich dystrybucji. P.S. Oczywiście są też srpm umożliwiające automatyczną kompilację i instalację ze źródeł.
Takie małe pytanko. RPM-y, jak DEB-y też zawierają skrypty konfiguracyjne. Tego nie jestem pewny i nigdy nie miałem okazji sprawdzić. Dziękuję za odpowiedź
.
Artwi: mam mala prosbe
nie wypowiadaj sie w tematach – w ktorych masz jak widac marna wiedze. prosze, najpierw doczytaj na temat deltarpm, czym rozni sie rpm4 od rpm5. moze zrozumiesz ze rozne dystrybucje uzywaja roznych wersji samego programu rpm (dokladniej – roznych forkow, z roznymie właściwościami).
ja nic nie pisalem o predkosci obslugiwania zaleznosci, tudziez “bazy danych”
skoro jestes taki “mandrivowy mastasz” – zainstaluj deltarpm z poprawka do openssl z opensuse na swojej zajebiaszczej mandrivie.
i prosze mi tu nie wyjezdzac z programi na wyzszym poziomie (wspomniane urpmi, czy tez wspomniany apt) – bo dyskusja toczyla sie rpm/dpkg.
.
co do wspomnienia o “archiwum” – a i owszem, .rpm to rowniez archiwum, ale moze sprobujesz choc troche wysilku wlozyc i MOZE (choc watpie) zrozumiesz – ze chodzilo mi o STANDARDOWE archiwum, ktore mozna obslugiwac bez specjalizowanych narzedzi typu rpm/dpkg. na solarisie .deb rozpakujesz przy uzyciu ar/tar/gzip – a rpm? da sie .cpio wypakowac jak ma sie dostep chocby do perla, ale juz ze skryptami konfiguracyjnymi – bedzie ciezko
.
raz jeszcze prosze – nim zaczniesz obrzucac kogos blotem – spojrz dokladniej o co w temacie chodzi. jak pisze o narzedziach nizszego poziomu – nie wyjezdzaj mi tu ze swoja marna wiedza w temacie jednego konkretnego narzedzia, w dodatku do obslugi pakietow w jednej z najbardziej wysmiewanych dystrybucji…
Ależ proszę, nie upieraj się przy trwaniu w błędzie! Mnie nie chodzi o różne wersje programu rpm, bo to NIE MA ZNACZENIA – może dystrybucja wcale takiego programu nie mieć. Nie obchodzi mnie że jakaś dystrybucja ma deltarpm, a inna gammarpm – WAŻNE BY BYŁ TEN SAM FORMAT PACZEK RPM (i tak jest, jak wyżej napisałem) i zapewniam, że choć nie mam “deltarpm”, to o ile w OpenSuse w paczce nie jest namieszane z nazwami plików i katalogów, przeważnie mogę taką paczkę zainstalować u siebie…
I proszę, zadaj sobie odrobinę trudu i poczytaj coś o budowie paczki rpm, np. w Wikipedii (polecam szczególnie akapit Physical package format – jak uważasz że gzip, bzip2, lzma, xar (RPM5) to niestandardowe archiwa, to się może do tego publicznie nie przyznawaj, bo się ośmieszasz… W każdym razie jak masz takie wielkie kłopoty z przeglądaniem zawartości rpm, to polecam coś, z czym poradzi sobie nawet lama: Midnight Commander’a! Wchodzisz w paczkę jak w katalog i zapewniam – możesz przeglądać/kopiować również skrypty instalacyjne…
Przestań siać FUD na temat rpm i zachwalać deb, bo nie ważne są narzędzia (te mogą być inne w każdej dystrybucji), nawet nieszczególnie jest ważna budowa paczek (bo translator sobie z tym łatwo poradzi) choć te są dość podobne-naprawdę rpm różni się drugorzędnie od deb, tylko to co wspomniałem i o co chodzi w LSB: jednakowa struktura katalogów, bibliotek, menu itp.! Dla takiej nieszczególnie życzliwej Linuksowi firmy jak np. Adobe, którą jednak należy docenić że zadaje sobie trud tworzenia pluginów flashplayera również pod Linuksa, naprawdę nie jest ważne czy musi tworzyć rpm, deb, czy zwykłe archiwum, czy wszystko naraz, bo to kwestia jednego skryptu, ale co jest problemem, to że różne mędrki wśród deweloperów, o nadmiernie wybujałym ego i źle pojętej kreatywności, umieszczają katalog z ogólnosystemowymi pluginami do przeglądarki internetowej np. (to tylko część możliwości, nie jestem w stanie ogarnąć całości tej źle pojętej radosnej twórczości) /usr/lib/mozilla/plugins/, /usr/local/lib/mozilla/plugins/, /usr/lib/browser/plugins, /usr/local/lib/defaultbrowser/plugins/, /opt/mozilla/plugins/ itp, itd i zapewne trudniej, niż zrobić binarkę działającą pod Linuksem, jest napisać skrypt instalacyjny, który ma za zadanie wyśledzić gdzie też wybujałe ego dewelopera raczyło ukryć katalog z pluginami w tej konkretnej dystybucji i jakby się programiści Adobe nie wysilali, nigdy nie napiszą skryptu, który poprawnie instalowałby na wszystkich dystrybucjach! I TO JEST PROBLEM, a nie dylemat DEB CZY RPM, bo to drugorzędne! Nawet jak wszyscy będą używać Twojego ukochanego deb’a, to z uwagi na wskazany problem (a plugin przeglądarki to naprawdę jeszcze pikuś w porównaniu do kobył typu X, KDE czy OpenOffice…) sytuacja się nie poprawi! Gdy się ten problem rozwiąże, to translacja rpm-deb czy generowanie obu paczek będzie błahostką. Jak nie rozumiesz istoty problemu, to przykro mi – dalsza dyskusja nie będzie miała sensu…
jellonek: powiedz mi prosze jak bardzo specjalistycznym narzedziem jest mc? Rpm’y mozna “podgladac” za jego pomoca bez najmniejszych problemow (chyba, ze ktos nie umie nacisnac klawisza enter) Poza tym archiwum *.cpio mozna rozpokowac za pomoca …. cpio (taki tar tylko, ze inny. Stosowany czesto w starszych uniksach)
Na tyle, że z reguły w dystrybucjach się go nie umieszcza. Podobnie specjalistyczny jest windowsowy Total Commander, przy rozszerzeniu powłoki do transparentnego przeglądania zipów.
pitr: mc korzysta ze specjalistycznego narzedzia o nazwie “rpm”. aby dostac sie do .cpio w .rpm – muszisz wyznaczyc offset, a tego “w pamieci” nie zrobisz, majac tylko podstawowo skrojonego busyboxa, tudziez na “obcej” platformie (np. jakies bsd) probujac wygrzebac kawalek dokumentacji z jakiegos .rpm. btw. ten twoj “starszy tar” jest stosowany do initialramfs w uzywanym przez ciebie kernelu linuksowym (zakladajac ze korzystasz z linuksa).
.
Artwi: doczytaj – to ma znaczenie. w opensuse masz 2 rodzaje paczek: programow (zwykle rpm) i poprawek do nich (delta rpm). tak wiec to twoje “WAZNE BY BYL TEN SAM FORMAT PACZEK RPM” wlasnie nie jest spelnione.
prosze – wroc pieniaczu dopiero jak doczytasz… raz jeszcze prosze – sproboj zainstalowac paczke opensuslowa, a pozniej do niej POPRAWKE. przeczytaj to moze z 2 razy, moze wiecej, moze w koncu zrozumiesz.
btw. nie zachwalam deb. wisi mi on – to tylko narzedzie.
ty poprostu nie rozumiesz krytyki rpm.
btw2. nie nazywaj “medrkami” ludzi, majacych wiedze techniczna na o wieeele wyzszym poziomie niz twoj. generalnie – przestan obrazac ludzi.
jellonek: konieczność rozpakowywania archiwum za pomocą dd i cat to jest na prawdę bardzo ważna rzecz. Weź nie żartuj, bo się ośmieszasz – równie dobrze ja mogę powiedzieć, że deba nie otworzę za pomocą komendy echo.
Druga sprawa – wcale nie trzeba używać initrd, więc nie trzeba wcale używać tara.
Sprawa trzecia – nie mając binutils nie mam ‘ar’.
ok – to do tego dd oblicz offset w pamieci…
initramfs to cpio, a nie tar – nie myl pojec…
co predzej znajdziesz pod hpuxem – binutils czy rpm?
A tak tak, cpio – której jest jeszcze rzadziej instalowane domyślnie na linuksach niż tar. Mógłbym wręcz powiedzieć, że częściej widuję rpm niż cpio.
A która literka w LSB zawiera system hpux, AIX czy cokolwiek innego?
Pytanie powinno brzmieć – w czym są lepsze? W niczym, a mimo to dzięki lobbingowi Red Hata zostały włączone do LSB.
… a skoro już zostały włączone one, a nie jakieś tam deby to może czas zabić deby?
Utrzymanie dobrej jakości pakietu źródłowego rpm jest łatwiejsze/tańsze niż odpowiednika deb. Poza tym nie widać szczególnych zalet deb w stosunku do rpm. Co do lobbingu to przy wybraniu pakietów deb równie łatwo można by oskarżać o to Ubuntu, więc nie przesadzajmy.
Nie widzę różnicy. Natomiast od obydwu o wiele prostsze są paczki pkg.tar.gz z Archa.
O ile mi wiadomo to jest jeden format DEB. Dystrybucje pochodne po debianie używają tego samego formatu paczek. A jeśli chodzi o RPM to każda dystrybucja (oparta o RPM) ma własną wersję.
Więcej szczegółów: http://osnews.pl/rpm-package-manager-510/
Ja osobiście poczułem wzrost szybkości instalowania paczek, gdy przesiadłem się z openSUSE na Debiana. Oczywiście powodem wzrostu szybkości może być np. użycie różnych algorytmów kompresji (Gzip / Bzip2), więc to wcale nie musi oznaczać że jakiś format paczek jest z natury szybszy od innych.
To Ci źle wiadomo… Gdybyś przeczytał to co zlinkowałeś, wiedziałbyś, że RPM5 zachowuje wsteczną kompatybilność, a trudno by rpm we wcześniejszej wersji obsługiwał wersje późniejsze. Co zaś do dystrybucji, używają jednakowych rpm (w sensie struktury paczek), a problemem jest tylko przekleństwo Linuksa: dowolność dystrybucji w podziale oprogramowania na biblioteki, wolna amerykanka w strukturach katalogów itp. To wszystko występuje też w dystrybucjach z deb. Jak takie problemy nie zachodzą, paczkę z RH można instalować w OpenSuse czy Mandrivie. Przykładem jest np. OpenOffice.org w postaci paczek rpm np. w wersji od UX: działa na różnych dystrybucjach, a jedyną różnicą są paczki rpm z wpisami do menu systemowego (nie jest to niezbędne do działania). LSB ma PRZEDE WSZYSTKIM UJEDNOLICIĆ WOLNĄ AMERYKANKĘ W PODZIALE NA BIBLIOTEKI, STRUKTURZE KATALOGÓW, WPISACH MENU itp.! Wybór deb czy rpm to w LSB SPRAWA DRUGORZĘDNA! Gdyby ujednolicić podziały bibliotek, struktury katalogów, wpisy do menu, bez problemu działałyby automatyczne translatory rmpdeb i dyskusja o wyższości jednych nad drugimi stałaby się zbędna…
Czasami instaluję paczki rpm z RH na OpenSuse i nie ma problemów.
Artwi: znowu sie wypowiadasz w temacie ktorego nie rozumiesz?
rpm5 obsluguje ktora wersje wczesniejszego formatu rpm4 – suse? redhat/mandriva? czy moze orginalnego rpm4?
problemem byly nie tylko roznice w strukturze katalogow, ale i chociazby w sposobie nazywania pakietow, albo w tym – ze rpm mogl byc zalezny od konkretnego pliku – ktory sie znajdowal w niewiadomojakimpakiecie.
btw. w jaki sposob chcesz ujednolicic sposob zaleznosci? wymusic na maintainerach pakietow? no bez jaj prosze…
hering: zgadza sie – czasami sie udaje. podobnie jest z jednakowymi paczkami np. od opery – tyle ze przygotowujac taka paczke trzeba sie starac o jak najmniejsze zewnetrzne zaleznosci…
Proszę Cię, nie trolluj: różnice w strukturze katalogów czy podziale bibliotek to nie są różnice formatu paczki rpm! I nie ma formatu rpm4 wersja suse, wersja mandriva, wersja RH, jest tylko format rpm4, JEDNAKOWO obsługiwany przez te dystrybucje. Różne wersje ma tylko zawartość, którą te paczki dla poszczególnych dystrybucji zawierają. Jak tego nie pojmujesz, to jak pisałem – dalsza dyskusja jest bezcelowa. Dziwne tylko, że jak dystrybucje używające deb mają inną strukturę katalogów, bibliotek itp., więc wzajemne używanie paczek deb między nimi też sprawia ogromną trudność, to nie piszesz o “różnych wersjach deb w różnych dystrybucjach”… Jakaś obsesja antyrpmowa?
raz jeszcze prosze: doczytaj.
miedzy tymi dystrybucjami ten format jest niemal identyczny – ale nawet w samych plikach .spec masz roznice takie, ze bardziej skomplikowanego .srpm z jednej dystrybucji nie przekompilujesz na innej.
ja tego nie musze pojmowac – wystarczy ze zajrze do zrodel – czego pewnie user mandrivy boi sie…
jellonek: chyba sam się nie orientujesz w temacie…
A deby korzystają z tar i ar suse? rh/mandriva? a może oryginalnego?
Jeśli bardzo chcesz wiedzieć, to w przypadku rpma mogą wystąpić niekompatybilności na 2 płaszczyznach (pozostałe płaszczyzny dotyczą dowolnego systemu pakietowania!):
1. wersja db – miałaby znaczenie, gdyby w dystrybucji X zainstalować sobie właśnie pakiet rpm z dystrybucji Y – można stracić bazę danych pakietów (nic dziwnego – instalując postgresa 8 w miejsce postgresa 7 też trzeba się dump/restore posłużyć). Oczywiście nie wpłynie to na możliwość pracy z samymi paczkami.
2. użyty wewnętrznie kompresor – np. w PLD był przez jakiś czas problem przy zmianie lzma.
No toś przywalił… A niby do deba nie da się włożyć innej struktury katalogów (w ogóle od tego jest FHS) ani nie da się inaczej nazwać? To jest co najwyżej problem tworzącego paczkę (czy to rpm, czy deb, czy nawet tar.gz).
Bo do tego używa się menedżerów pakietów. I tu ponownie – rpma bardzo łatwo przekonywało się do tego, aby do zależności w czasie budowania dodawał właśnie nazwę tego pakietu – tak było jeszcze za czasów PLD Ra. Więc ponownie – to jest kwestia decyzji osoby przygotowującej pakiet.
No i ponownie pokazujesz, że nie rozumiesz kompletnie idei zależności – właśnie dlatego w PLD zrezygnowano z zależności od PAKIETU (czyli jego NAZWY), bo wystarczająca jest zależność od BIBLIOTEKI (lub pliku) – to, w jakim pakiecie (tzn. w pakiecie o jakiej nazwie) się znajduje dana biblioteka, znajdzie menedżer pakietów (w PLD poldek).
a czy ja pisze ze i deb jest taki wspanialy?
) to juz mnie ubawiles 
nie jestem oratorem deba, krytykuje tylko .rpm
z tym “nierozumieniem idei zaleznosci” (pewnie twojej idei
Aha, krytykujesz rpm za rzeczy, które od rpm nie zależą?
I jeśli ubawiłem, to wytłumacz się proszę z zacytowanego fragmentu, przypomnę:
Używając Open Suse zorientowałem się, że rpmy to też po prostu archiwum. Równie dobrze szła mi instalacja przez ‘rpm -ivh pakiet’ jak i przez przekopiowanie plików z rpma do odpowiednich katalogów.
a w jaki sposob kopiowales z rpma? mc?
w ten sposob np. nie “zainstalujesz” niczego, co wymaga dodatkowych skryptow pre-, post- instalacyjnych, w ktorych np. tworzony jest uzytkownik/grupa do obslugi danego programu.
No i widzisz jak się kompromitujesz? Można, choćby za pomocą mc, uruchomić te skrypty, a problem z taką manualną instalacją nie polega na niemożności uruchomienia skryptów (bo je można uruchomić), tylko na tym, że zainstalowane pliki nie zostaną zarejestrowane w bazie rpm, więc gdy jakiś później instalowany “normalnie” pakiet będzie chciał je używać, to przy instalacji błędnie będzie wykazywał błędy w zależnościach… Ale dokładnie to samo zjawisko zajdzie w deb…
jellonek: idź siać trolizm na onet bo teraz to już normalnie rogami o ekran szorujesz.
Artwi: zalezy w jaki sposob dostajesz sie z pod mc (rozne distra roznie to obsluguja – bo sa 2 mozliowsci) do .rpm – jesli przy uzyciu programu rpm – masz dostep do tych skryptow (tj. da sie je wykopiowac) – jesli przy pomocy rpm2cpio – to juz niestety nie.
jellonek:
Wyjaśnij zatem w tym kontekście swoje wątpliwości dotyczące wstecznej kompatybilności rpm5.
Oczywiście, że przekompilujesz – spece co najwyżej korzystają z makr (w celu uproszczenia rzeczy, które się często powtarzają, typu zarządzanie użytkownikami/grupami, działającymi usługami, częste triggery), zatem wystarczy wrzucić sobie właściwe definicje makr. Przykład? Chcesz skompilować speca z PLD (bardzo dużo zamotanych makr). Wystarczy wziąć pakiet rpm-build-macros, wrzucić do ~/.rpmmacros oraz ~/.rpmrc i można budować.
Wyobraź sobie, że do deba też mogę załadować skrypt instalacyjny, który na innej dystrybucji debowej się wywali (bo nie będzie koniecznego oskryptowania, będą inne katalogi itp).
Cały czas starasz się zdyskredytować rpma, przedstawiając różnice pomiędzy PRZYJĘTYMI metodami paczkowania, a nie immanentne cechy rpma. Możesz przytoczyć coś, czemu wynien jest rpm? Kiedyś brakowało mu Suggests, ale już jest, są kolory, więc jak dla mnie jest już wszystko, co kiedykolwiek miał deb.
Są różne + i różne – tych pierwszych i ty drugich zarazem. Apt jest jednym z lepiej zoptymalizowanych pod kątem zużycia pamięci managerów pakietów, znowu rpm jest imho potężniejszy ze względu na rollbacki.
Powyższa dyskusja pokazuje dla czego LSB nigdy nie będzie się liczyć. I bardzo dobrze. Gdyby wszystkie dystrybucje wyglądały tak samo… Koszmar. A tak każdy znajdzie coś dla siebie. LSB to utopia.
Jest w LSB4 system pakietów, który:
- nie zmusza mnie do używania internetu (np. aby ściągnąć zależności, chciałbym aby zależności były w paczce)
- jest uniwersalny i niezależny od dystrybucji i jej wersji, mogę zainstalować dany pakiet na każdym Linuksie, który jest zgodny z LSB4 (chciałbym wejść na stronę skype i ściągnąć po prostu wersję dla Linuksa, która będzie działała na każdym Linuksie)
Jak LSB te problemy rozwiąże to ekspansja Linuksa na desktopie jest prawie, że pewna.
wystarczy spakietować program kompilowany statycznie
zalety:
- nie martwisz się o zależności
wady:
- pakiet zajmuje więcej, musi bowiem zdublować biblioteki/programy z innych pakietów (każdy taki statyczny pakiet!); wyobraź sobie statycznie skompilowane KDE, każdy element środowiska jest większy o jakieś 50 MB statycznego kdelibs
Nie interesują mnie półśrodki!
Kompilowanie statyczne ma ogromne wady, bo program nie używa w systemie bibliotek dynamicznych, które już są załadowane w pamięci i zajmuje przez to więcej pamięci operacyjnej (lepiej gdy używana jest shared memory). Chciałbym aby pakiety miały w sobie zestaw dodatkowych bibliotek (których może nie być w systemie) i używały ich wtedy gdy system nie posiada danej biblioteki, lub biblioteka w systemie nie jest kompatybilna z programem. Nie każdy ma dostęp do Internetu, a jak ktoś go nie ma i chce Linuksa to niestety w 99% taka osoba jest zniechęcona i chce Windows z powrotem!
W każdym systemie paczek można umieścić w paczce jej zależności. Po prostu nikt tego nie robi, bo to dublowałoby biblioteki i powodowało konflikty wersji.
@Thar: nie widzę problemu aby kilka wersji jednej biblioteki egzystowało w systemie obok siebie. Często jest to nawet konieczne, wtedy gdy twórca biblioteki uczynił wersję następną niekompatybilną z poprzednią (co się często zdarza).
Rzecz w tym, że w Linuksach system pakietowy nie nadaje się do instalacji klasycznych programów biurkowych (zwykłych aplikacji), wtedy gdy tej aplikacji nie ma w repozytorium. Tworzy się wtedy ogromny problem. Gdyby stworzyć jeden uniwersalny system paczek, który egzystował by obok tego specyficznego dla dystrybucji, to osoba pobierająca program z Internetu, czy z płyty CD, nie miała by problem z jego instalacją na dowolnym Linuksie. Np. ja nie mając dostępu do Internetu przesyłam po WIFI koledze na laptopa program, on go instaluje i działa, powiedzmy, że ja mam openSuSE a kolega Ubuntu. Normalnie jest to duży problem, prawie nie do obejścia, a gdyby stworzyć system paczek, który to rozwiązuje to problem instalacji programu spadł by do poziomu przeciągnij i upuść, jak to jest w Mac OS X.
@Thar: kwestia konfliktów itp pokazuje oczywiście ułomność obecnych systemów pakietowych.
Moim zdaniem obecne systemy pakietowe są dobre dla oprogramowania rdzennego dystrybucji, niestety nie nadaje się on do instalacji regularnych programów użytkownika, bo programy A i B mogą wymagać biblioteki X w 2 różnych wersjach, wtedy musisz wybrać pomiędzy program A i B, a co jeśli potrzebujesz obu? Dlatego uważam, że systemy pakietowe w Linuksach są dobre, ale tylko do oprogramowania dostarczonego z dystrybucją, oprogramowania nad którym czuwa twórca dystrybucji. Często jest tak, że w dystrybucji nie ma całego softu jaki chcesz używać i wtedy zaczynają się schody.
Ty nie widzisz, a ja nie lubię mieć kilku wersji tego samego. To, co proponujesz nie oznacza, że byłoby kilka wersji różniących się API – nawet, jeśli się ono nie różni, inna wersja biblioteki i tak musiałaby być zainstalowana, bo paczka miałaby ją w zależnościach.
Dlatego nie należy tego rozwiązywać paczkami, które z założenia miały ułatwić synchronizowanie z najnowszymi dostępnymi wersjami programów. Wystarczy, żeby producent programu użył jednego z dostępnych graficznych instalatorów na Linuksa i wrzucił wszystko do /opt/nazwa_programu.
Po co chcesz wymyślać koło od nowa?
Taak, a kwestia śmieci zostawianych w rejestrze pokazuje ułomność zarządzania oprogramowaniem w Windows, lol…
Na poważnie, to nie pamiętam już, kiedy ostatnio miałem konflikt. Dependency hell to FUD siany przez dyletantów którzy Linuksa palcem nawet nie tknęli i użytkowników Slackware.
[cite]
Dependency hell to FUD siany przez dyletantów którzy Linuksa palcem nawet nie tknęli i użytkowników Slackware.
[/cite]
Pobieram. Zazwyczaj nawet, gdy menadżer paczek mi coś wypluwa(niekiedy się zdarza), to nie rezygnuje z instalacji. W OpenSuSE wystarczy klikać zmień dystrybutora, nie usuwaj, itd. i zazwyczaj nie ma problemów. A sytuacje, że menadżer paczek coś wypluwa są bardzo rzadki. Zdarzyły mi się dwa razy chyba na trzy lata, bo menadżer paczek pod OpenSuSE stał się bardziej głośny. Jedna sytuacja była podczas aktualizacji dystrybucji(zmiana dostawcy paczek), a drugą miałem podczas pewnej aktualizacji KDE4 do wersji z Factory.
@Sławek: mnie się to zdarza w OpenSuSE o wiele częściej, a używam go codziennie w domu. Ponadto o wiele większym problemem jest instalacja programu, którego nie ma w systemie pakietowym. Z większością takich problemów przeciętny user sobie nie poradzi.
@Thar: Jeśli programista robiący paczkę przetestował ja z danymi wersjami biblioteki i deklaruje kompatybilność, to gwarantuje w ten sposób, że jego program będzie działał. Wolę mieć nawet 3 razy więcej tej samej biblioteki w systemie, byle by aplikacja działała. Nie raz zdarzyło mi się, że jakiś program przestał działać po aktualizacji bibliotek. Np. VMWare po aktualizacji GTK, czy kilka innych programów instalowanych ze źródeł lub z instalatora *.sh. W pewnych przypadkach czekam aż dostawca programu dostosuje go do nowej biblioteki, w innych, kiedy coś jeszcze mogę zrobić, kombinuje, ale zabiera mi to za dużo czasu i jest to czas zmarnowany.
mario: : nie widzę problemu aby kilka wersji jednej biblioteki egzystowało w systemie obok siebie.
Tylko czym to się ma różnić od statycznego kompilowania? Biblioteka będzie siedzieć w pamięci dwa razy i pożerać swoje miejsce!
Tym, że programy używające biblioteki z jednej wersji i programy, które wolą wersję drugą nie będą marnować pamięci. A jeśli już pozbędziesz się programów, które używają wersji starej, to nowa, która nie była statycznie linkowana będzie zajmowała minimalną ilość pamięci. Statyczne linkowanie ma sens tylko w przypadku małych i rzadko stosowanych bibliotek, lub wrapperów na biblioteki.
@Thar: “Taak, a kwestia śmieci zostawianych w rejestrze pokazuje ułomność zarządzania oprogramowaniem w Windows, lol…”
w Linuksach też masz śmieci po aplikacji pozostawione w ~/.[nazwa_aplikacji]. Czasem nawet te śmieci chcesz bo instalując nową wersję programu chcesz zachować stare dane. Taki system pakietów kompletnie nic w kwestii tych śmieci nie zmienia, nadal zostaną one na swoim miejscu.
Śmieci to jest to, co pozostaje w rejestrze, a NIE JEST do niczego potrzebne. Ustawienia pozostawione w katalogu aplikacji to NIE SĄ śmieci!
“Ty nie widzisz, a ja nie lubię mieć kilku wersji tego samego. To, co proponujesz nie oznacza, że byłoby kilka wersji różniących się API – nawet, jeśli się ono nie różni, inna wersja biblioteki i tak musiałaby być zainstalowana, bo paczka miałaby ją w zależnościach.”
Nie musiałaby.
@mby7930: to jest dokładnie to samo. W Windows przyjęło się kiedyś (teraz na szczęście się od tego odchodzi), że aplikacja wszelkie swoje ustawienia pozostawia w rejestrze, podobnie jak w UNIX przyjęło się, że aplikacja wszystkie swoje ustawienia ma w:
/etc
/usr/local/etc
~/.[nazwa_aplikacji]
Po odinstalowaniu aplikacji też zazwyczaj nie potrzebujesz tego katalogu konfiguracji w swoim home. Oczywiście globalne pliki konfiguracji zostaną usunięte przy deinstalowaniu paczki, ale podobnie jest w Windows, gdzie deinstalator aplikacji usuwa wpisy jakie utworzył instalator. Oczywiście w UNIX o wiele łatwiej te śmieci usunąć niż w Windows, ale generalnie są i są to dokładnie te same “śmieci” co w Windows.
Jak już definiujesz te “śmieci” to uczciwość nakazywała by tego nie ograniczać do rejestru, powinno wyglądać to tak:
Śmieci to jest to, co pozostaje PO DEINSTALACJI, a NIE JEST do niczego potrzebne.
W większości przypadków po deinstalacji programu nie potrzebujesz katalogu z jego ustawieniami osobistymi, jeżeli nie zamierzasz z tego programu korzystać.
BTW. trochę kojarzy mi się to Twoje stwierdzenie z hasłem “it is a feature, not a bug”
Zaglądałeś kiedyś do rejestru? Konfiguracja programu to nie śmieci. W rejestrze natomiast masz sporo g*wna nie potrzebnego dla programu jako takiego..
@3ED: to są informacje dla systemu o zainstalowanej aplikacji, zarejestrowanych komponentach itp, nie był bym do końca taki pewien, że są niepotrzebne.
Nie mówię też, że z rejestru się tak łatwo usuwa jak z katalogu home, bo nie mowa tutaj o łatwości usunięcia pozostałości po aplikacji (zresztą dlatego wszyscy odchodzą od trzymania danych w rejestrze), ale mowa jest o tym, że śmieci w Linuksie też są, a nie lubię hipokrytów i dzieciaków rzucających nieprawdziwymi argumentami (najgorsze jest to, że większość z nich usilnie się tych argumentów trzyma i mimo dowodu nie chce popuścić).
BTW moja siostra (używa Ubuntu) tych śmieci w Linuksie nie potrafi sobie usunąć sama – ba nawet pewnie nie wie, że są (podobnie jak i pod Windows też nie wie, że są). Oczywiście nie jest to żaden problem, bo zazwyczaj te śmieci zajmują bardzo mało, a ona sama prawie nic nie instaluje i tym bardziej prawie nic nie usuwa.
Z tego, co mi wiadomo, to paczki(np. RMPy) mogą zawierać inne paczki. Jeżeli jakaś paczka nie występuje w twoim systemie, to zostanie zainstalowana z tej, która ją wymaga. Pytanie tylko, po co? Już nie lepiej podzielić wszystko na większą liczbę plików i dać je na płytce? Prościej i szybciej, a także dając użytkownikowi większą wolność
.
@pawels:
Jakoś pod jedynie poprawnym politycznie “systemem” operacyjnym nikt się nie martwi o ilość zjedzonego miejsca na dysku – zresztą – nie bądźmy aptekarzami – dziś MB w tę czy w tę nie robi już różnicy.
Gratulację, właśnie z Linuksa zrobiłeś Windowsa!
Weź się nie ośmieszaj. Nie ma to niczego wspólnego z Windowsem, poza tym, że w Windows nie ma takich problemów z instalacją programów od dostawców 3-cich. System instalacji programów w Windows też jest ułomny i ma wiele błędów. Już lepszy jest sposób instalacji w Mac OS X, gdzie instalacja programu to przeciągnięcie ikony programu do folderu /Applications, a usuwanie to przeciągnięcie do kosza.
to nie do konca jest dobra metoda, bo uniemozliwia pelne usuniecie wszystkich smieci pozostalych po programie, w przypadku “deinstalacji”. zostaja smieci w ~/Library/{Application\ Support,Caches,Preferences} i pewnie wielu innych miejscach. przypomina to troche sytuacje z zasmieconym rejestrem w windows, choc na pewno nie ma tak negatywnego wplywu na wydajnosc systemu…
Ale w Linuksie jest dokładnie tak samo! Jak odinstalujesz dowolny program zainstalowany z repo to zawsze zostają po nim śmieci w ~/home.
Dla maka akurat powstał specjalny program, który bada czy usuwana jest z kosza aplikacja, i jeśli tak to pyta czy usunąć też pliki po niej pozostawione (nie zawsze chcesz je usuwać, bo jak instalujesz nową wersję tej samej aplikacji to raczej się je pozostawia).
“Ale w Linuksie jest dokładnie tak samo! Jak odinstalujesz dowolny program zainstalowany z repo to zawsze zostają po nim śmieci w ~/home.”
Bzdura.
Poza tym, najlepszym wyjściem byłoby stworzenie dla dystrybucji desktopoowych “żelaznych” elementów, który byłyby zawsze od palca dostępne. Biblioteki do grafiki, sieci, dźwięku itp.
Tak jak masz w Windows – wiadomo, że masz obsługę dźwięku tak a tak, GUI takie a takie, a jak chcesz czegoś więcej – dostarczasz sam razem z programem. Ale niektóre rzeczy na pewno są, więc jest się na czym oprzeć.
Napisanie “bzdura” nie wystarczy aby mnie przekonać, wysil się!
Co do drugiej części Twojej wypowiedzi to się zgadzam, wtedy takie uniwersalna paczki były by mniejsze … ale takie elementy właśnie definiuje LSB Desktop.
Tutaj popieram mario. Jakiś standard (różny od wszystkich aktualnych systemów pakietów) by się przydał. Ale nie uważam, by trzeba było wszystkie zależności trzymać w każdej jednej paczce. Jeśli dawałbym program kumplowi bez dostępu do Internetu, chciałbym móc wpisać takie
pkg -download-dependences moj_program.pkgi czekać, aż mi się wszystkie zależne pakiety ściągną do aktualnego folderu. Później np. pakuję wszytkie te pliki w jeden pakiet samemu i daję kumplowi (mogłoby się przydać coś w stylupkg -pack_packages ./*do zrobienia pakietu instalującego wszystkie podane pakiety). Żeby w repozytorium nie trzymać mega wielkich pakietów, ale żeby móc łatwo przekazać komuś pakiet razem z zależnościami.Co do “śmieci” – Linux nie ma *całkiem* identycznie jak Windose, bo nie ma burdelu w rejestrze, ALE tak, każdy soft też pozostawia śmieci w ~/.program! Zainstalujcie sobie na Linuksie 50 dowolnych programów, po czym usuńcie je, nie wywalając tręcznie konfigów. Potem zróbcie to samo na Winie. Obejrzyjcie rejestr w Winie i ~/.* w Linuchu. Wskażcie 5 podobieństw…
a –purge w apt?
@Silmethule: To będzie trudne, rejestr to jeden plik? tutaj masz dwa miejsca, z czego po odinstalowaniu (np. przez purge) konfiguracja zostaje tylko w jednym – home (i bardzo dobrze). Jeden katalog łatwiej usunąć niż stado katalogów i podkatalogów pomieszanych z innymi katalogami (zwirtualizowany rejestr), których nazwy nieczęsto nie mają nic wspólnego z nazwą programu. Ponadto nie można łatwo usunąć tych śmieci (jeżeli nie usunie instalator – bardzo często), a są one interpretowane przez system – jeden plik. A tutaj w home może leżeć mnóstwo pliczków ale nie są one w ogóle brane pod uwagę (jeżeli nie ma programu) i nieczęsto zajmują poniżej 50KB, a usunięcie sprowadza się do usunięcia jednego katalogu (i w myślach: o nie, następnym razem konfigurować będę musiał od nowa) i oczywiście strzelasz sobie w stopę bo w windowsie problemem pewnie byłoby zarchiwizowanie sobie tych ustawień, nie sądzisz?
“..i nieczęsto zajmują poniżej..” → “..i najczęściej zajmują poniżej..”
ps. Edycja komentarzy by się przydała..
Klik2?
Oglądam właśnie info o klik2 i to chyba jest właśnie to! Klik w pierwszej wersji jednak nie bardzo mi pasował, a tutaj taka niespodzianka!
Mam nadzieję, że będzie to popularnie i większość aplikacji będzie miała wersja dla klika.
http://klik.atekon.de/screencast/
To jest niezłe rozwiązanie dla instalacji programów firm trzecich tylko nikt z tego nie korzysta i dalej producenci robią tysiąc wersji paczek dla każdego distro.
Ciekawe. A jak wyglądają aktualizacje?
Przed chwilą testowałem działanie tego klika. Połowa lub większość programów ze strony nie chce się zainstalować. Te które się udało zainstalować – działają raczej bez problemów.
O aktualizacjach można zapomnieć – jest tam np. firefox w wersji 2, który zresztą i tak się nie chciał zainstalować
@WadsoM: niestety to jest urok wersji deweloperskich. Chciałbym aby ktoś tego klika skończył
.
@qwak: Chyba sam mało wiem o tym mechanizmie. Wydawało mi się, że Klik2 po prostu kompiluje program i zależności z odpowiednim prefiksem
. Nie jest to dobre dla dostawców zamkniętego softu, ale dla nich zawsze pozostaje /opt . O Klik2 chyba sam muszę poczytać 
.
@Sławek: Klik niczego nie kompiluje tylko pakuje program gotowy do uruchomienia z obrazu dysku iso. Ściągasz aplikację w postaci pliku CMG (Comressed iMaGe) i klik automatycznie potrafi zamontować taki obraz (przez FUSE) i uruchomić z niego aplikację, niezależnie od wersji systemu.
BTW. Przydała by się do klika jeszcze opcja install, pozwalająca na rozpakowanie i zainstalowanie programu z obrazu, tak aby jego uruchamianie się było szybsze. Sądzę, że dorobienie takiej opcji było by bardzo proste.
Taki package management juz istenieje i ma sie dobrze, do tego nei wymaga zadnego LSB, a dziala rowniez na FreeBSD i Solaris out of the boxm nazywa sie OpenPKG i dziala bardzo dobrze.
Do tego nie jest upierdliwy dla standartowego systemu, poniewaz wszystko laduje w /openpkg lacznie z skryptami startowymi itd, poprostu wszystko jet tylko w /openpkg jezeli chcesz sie go pozbyc to jedyne co musisz zrobic to rm -rf /openpkg KISS!
Dzięki – przetestuję to!
Nie wyspałeś się? Jakim cudem w paczkę chcesz wrzucić zależność w postaci biblioteki, która jest używana w 100 programach? Skompilować statycznie czy doklejać do każdego pakietu wszystkie pakiety wymagane?
mario: kolejna bzdura to to, że mając programy A i B wymagające innej wersji biblioteki trzeba z jednego zrezygnować. Biblioteki mają coś takiego jak SONAME i spokojnie można mieć w systemie wszystkie wersje. Najlepszy przykład – pewnie masz to nawet u siebie, to pakiety compat-libstdc++ zawierające właśnie stare wersje.
Silmethule: też się chyba nie wyspałeś. To co jest w ~/.program to jest KONFIGURACJA UŻYTKOWNIKA. Niby system miałby usuwać MOJE DANE? To może jeszcze po usunięciu kompilatora z dysku powinny być kasowane wszystkie pliki źródłowe, a po usunięciu przeglądarki obrazków powinien wywalić zdjęcia z wakacji?
@gotar: tylko jak system wykonuje upgrade to odinstaluje Ci starą bibliotekę i zainstaluje nową, wtedy program instalowany ze źle skonstruowanej paczki (co często się zdarza), albo z instalatora uniwersalnego, przestanie działać. Byle Kowalski nie będzie też wiedział jak zainstalować z paczek więcej wersji bibliotek, ba nawet nie będzie wiedział co to biblioteka.
Uważam, że powinien powstać standard, który definiuje jakie biblioteki muszą być w systemie zawsze, tak aby uniwersalne paczki zajmowały mniej. A paczki uniwerslane w miarę możliwości powinny zawierać wszystkie zależności niestandardowe, tak aby uruchomienie programu było możliwe zawsze. Niestety zmorą Linuksa jest to, że dużej ilości oprogramowania po prostu nie da się uruchomić. Np. instalowany z repo SUSE program wired czy inne programy muzyczne, które chciałem sobie przetestować, po prostu się nie uruchamiają. A gdyby miały swoje biblioteki, z którymi programista przetestował te programy to problemu by nie było. Mnie nawet nie chce się walczyć aby je uruchomić, a najśmieszniejsze jest to, że w przypadku tych samych programów, które mają wersje dla Windows czy Maka na tych systemach nie ma problemu, problemy są tylko na Linuksie, a wynika to właśnie z ułomności systemów pakietowych, które nie nadają się do instalacji normalnych aplikacji użytkownika!
Jak system wykonuje upgrade to nie usunie biblioteki, na którą jest zależność. Oczywiście jeśli instalujesz coś przez ./configure && make install to masz problem, ale nie spotkałem paczek rpm, które nie mają zależności właśnie od samej biblioteki – jakiś przykład?
I jak sobie wyobrażasz standard, wymagający konkretnej wersji np. GTK? Miałby być aktualizowany raz na kwartał?
Sprawdzona praktyka, to udostępnianie paczki z zależnościami oraz statycznej.
A ja powtórzę swoje słowa – potrzebny jest całkiem nowy system paczek dla oprogramowania poza oficjalnymi repozytoriami, który by był standardem (tzn. żeby twórca programu mógł wrzucić jedną paczkę, która zainstaluje się na każdej liczącej się dystrybucji i będzie zawierała to co potrzebne). I ujednolicić nazewnictwo pakietów żeby można było wrzucić w taką standardową paczkę zależności do dociągnięcia z repytorium dystrybucyjnego.
Bo co kogo obchodzi, że Fedora używa .rpm, a Debian .deb skoro mają osobne repozytoria do własnego użytku? Tylko trzeba maksymalnie ujednolicić obsługę paczek (PackageKit już to robi)
Nazewnictwo paczek w sumie już teraz jest bardzo jednolite. Choćby wszystkie kodeki. Jedynym problemem jest oznaczanie różnych wersji(stabilnych i nie) w różnych ssytemach paczek, ale od tego jest zarządca repozytoriów. A zamiast jednolitego menadżera paczek, potrzebne jest raczej jednolite API i to, żeby menadżer paczek nadal wszystko nadzorował.
Wyobraź sobie, program potrzebuje “libpotrzeba.so-5.5.3.2″, menadzer pakietów odszukuje w bazie taki plik i sprawdza jaki to pakiet, np. “potrzeba-old_5.5.3.2_1.rpm” i go instaluje.. Pliki posiadają tzw. soname jak Sławek wspomniał..
Nic trudnego, na pierwszy rzut oka i nie trzeba wspólnych repo czy nazewnictw programów. Wystarczy oprzeć zależności na nazwach plików, a nie nazwach pakietów.
LSB mogłoby rozwiązać wiele problemów Linuksa i zachęcić programistów do tworzenia programów na ten system. Mogłoby, ale nie wiem czy to się uda.
Chociażby w przypadku paczek powstaje duży problem: czy Debian albo Ubuntu porzucą .deb, bo LSB stanowi inaczej? Raczej nie, co nie wróży dobrze temu standardowi.
A powinno nie dobrze wróżyć tym dystrybucjom. Tyle się mówi o standardach i interoperacyjności, a użytkownicy tych dystrybucji kochają swoje deby jak windows swoje exe installery
Ubuntu, Mint i Debian to wystarczający kawałek tortu Linuksowego. Jeśli standard LSB nie będzie stosowany w 80% systemów Linux, to równie dobrze może go nie być, bo mniejsze liczby nie będą wiele znaczyć dla programistów.
Użytkownicy jak użytkownicy, ale ciężko jest nagle zmienić system zarządzania paczkami w jakiejś dystrybucji, zwłaszcza w takich byczkach jak Debian.
Niech zrobią normalna programy do tych rpmów najpierw, standardowy w Fedorze bodajże yum to porażka na całej linii.
Yum to porażka ? Ale dlaczego ? Podaj jego ułomności. Chociaż jak piszesz “bodajże yum” to pewnie nie widziałeś go w akcji albo nie zapoznałeś się z instrukcją obsługi do niego. Ja z yumem nie mam zadnych problemów – ładnie rozwiązuje zależności.
Zainstaluj sobie poldka.
yum to porażka, bo jest:
a) wolny
b) nie ma wygodnego CLI (znaczy w ogóle go nie ma).
CLI ma – yum shell. A czy to wygodne, to nie wiem – nie używałem. Z argumentem a) się zgadzam.
Jest jeszcze smart, którym już sporo ludzi zastąpiło Yuma.
Hahah, już jakiś zayumany zajumał mi karmę, bo w życiu poldka na oczy nie widział.
Powtórzę: zainstalujcie sobie, działa na wielu dystrybucjach rpmowatych, nie tylko na PLD.
Wydaje się że wystarczy przepisać takiego aptitude do współpracy z rpm (o ile jeszcze nie ma) i gra gitara. Użytkownicy i developerzy będą mieli nadal to samo narzędzie, ciekawi mnie natomiast zawartość metadanych i in kompatybilne funkcje.
w sumie to ma swoje dobre i slabe strony. Fajnie bybylo gdyby jeden powstal jeden system paczek tylko boje sie ze narzuca z gory jakies gowniane pomysly i nie bede mial opcji korzystania z systemu pakietow bez zaleznosci. Co do rpm i deb osobiscie trudniej mi sie robi rpm, a raczej o wiele dluzej, niz deb czy inne. Uwazam ze rozne systemy pakietow maja swoje zalety, osobiscie nie widze nawet opcji zeby zrobili jeden system pakietow. Taki projekt musialby by brac pod uwage wszystkie zalety poszczegolnych rozwiazan np chocby z gentoo.
)
Zreszta zawsze jest duzo gadania, palnow a zwykle konczy sie tak ze albo proejktu nie zrobia, albo go spierdola -_- w tym przypadku stawiam ze nowy system pakietow do niczego sie nie bedzie nadawal i malo ktora dystrybucja bedzie z tego korzystac (w najgorszym wypadku zawsze mozna wrocic na *bsd on nigdy nie zawodzi
“Uwazam ze rozne systemy pakietow maja swoje zalety, osobiscie nie widze nawet opcji zeby zrobili jeden system pakietow. Taki projekt musialby by brac pod uwage wszystkie zalety poszczegolnych rozwiazan np chocby z gentoo.”
A ja widzę opcję, i tak prędzej czy później musi zostać IMO zrobione. Natomiast gentoo zostawmy tym, którzy mają za dużo czasu wolnego i im go nie szkoda.
Ale czasu procesora
A tak na poważne – Gentoo nie używa się, żeby programy były 3% szybsze (choć można się w to pobawić) – większymi zaletami są:
- Dostęp do nowych programów i bibliotek (wersje testowe) i łatwość tworzenia ich (użytkownik może łatwo popoprawiać)
- Personalizacja – w tradycyjnym podejściu jeśli program A może korzystać z 2 backendów i nie ma opcji do wyboru w runtime to musi on być jako 2 paczki (totem/totem-xine, epiphany, epiphany-webkit, epiphany-xulrunner1.9).
IMHO gentoo też mogłoby robić pakiety rpm.. Narazie to jak dobrze pamiętam (np. quickpkg) robi zwykłe tarówki.
Gentoo obsługuje instalację rpmów.
Trzeba przyznać jedno – żadna dystrybucja nie porzuci swojego systemu pakietów: debian i ubuntu nie zrezygnuje z DEB, gentoo nie przerzuci się na paczki RPM itp. Można za to spróbować ujednolicić API wszystkich managerów pakietów.
Paczka z programem do zainstalowania uruchamiała by “systemowy manager pakietów” (bez wchodzenia w szczegóły czy to jest yum, apt-get, yast), mówiła temu managerowi co jest potrzebne aby instalowana aplikacja mogła poprawnie działać, manager pakietów wskaże miejsca do których odpowiednie pliki powinny być skopiowane (np. /usr/bin/, /etc/coś_tam/, itp.), manager pakietów powinien też uaktualnić skrypty startowe jeśli aplikacja będzie tego wymagać, instalowana aplikacja powinna mieć również możliwość nakazania managerowi pakietów utworzenia w menu odpowiednich pozycji z zainstalowaną aplikacją a także skojarzenia rozszerzeń plików i mime/type.
Wystarczy że każda dystrybucja wydałaby odpowiedni back-end do swojego managera pakietów, o jednakowym niezmiennym API.
Wiem że stworzenie takiego back-endu który automatyzowałby cały proces instalacji byłoby trudne, oraz nie każdą aplikację dałoby się w ten sposób zainstalować, ale do instalacji gier, czy po porostu zwykłych aplikacji powinno wystarczyć.
Nie rozwiązuje to jednak problemu doinstalowywania wymaganych paczek z internetu bądź z płytek z systemem.
Najlepsze było by rozwiązanie na wzór “1-Click Install” stosowanego w openSUSE, kto wie.. może nawet kilku windziarzy dałoby się dzięki temu przekonać.
Niestety większość twardogłowych deweloperów Linuksa nie widzi związku pomiędzy wzrostem liczby użytkowników a wymiernymi korzyściami dla systemu (natywne programy, sterowniki etc).
Nie wiem jak to działa w OpenSUSE, ale rozszerzony Firefox z Ubuntu obsługuje protokół apt:, który tylko instaluje paczkę z repozytorium. By się raczej przydała możliwość dodania repozytoriów jednym kliknięciem.
W OpenSuSE to jakoś tak działa. Wchodzisz na stronkę downoload.opensuse.org, wpisujesz nazwę programu, klikasz na obrazek z napisem install i zaznaczasz opcję “pozostaw te repozytoria po instalacji”. Inną sprawą są repozytoria społeczności w Yast. Nie wiem czy nie mówimy o tym samym. Może czas, żeby przetestować najnowsze Ubuntu po paru latach nie spotykania się z tym systemem.
Ja akurat się przejechałem na dystrybucjach opartych na rpm. Często na repo nie było programów czy libów mi potrzebnych, więc ściągałem źródła, kompilowałem, #make install… I nadal dany lib nie był widoczny w systemie. Istny koszmar później robić symlinki w różnych miejscach i dopisywać lokacje wszystkich depów przy instalacji czegoś nowego… W distro Debiano-podobnych nie miałem takiego problemu, więc jak dla mnie deb>rpm.
A co do wspólnego systemu paczek/instalatorów to przecież jest multum projektów instalatorów (np Bitrock installer) chodzących na wszystkich dystrybucjach i nawet rejestrujących dany program w bazach paczek, żeby można było łatwo go odinstalować. Tylko, że te instalatory, chociaż dobre, to często mają ograniczenia licencyjne, że nie można ich użyć przy komercyjnych programach, albo kosztują w przypadku komercyjnych appsów (a inne firmy np nie chcą płacić dodatkowo za sam instalator).
A instalacja czegokolwiek offline’owa to IMHO przeżytek i niepotrzebne utrudnienie. Linux od zarania swojego istnienia był nieodłącznie związany z siecią i ten system po prostu kiedy ktoś nie ma netu nie zdaje egzaminu. Z 2 strony mamy w końcu XXI wiek i życie bez netu jest męczarnią samą w sobie, wiec należy zakładać, że każdy user ma dostęp do sieci (a jak nie to dostarczać na płytce z programem całe drzewko depów dla różnych distro, które są wymagane dla danego programu).
Jak już tak ambitnie samodzielnie kompilowałeś, to mogłeś iść mały szczebelek wyżej i tworzyć srpm i kompilować z tego, a jak działało, to podzielić się ze społecznością i wrzucić swojego rpm-a do publicznego repozytorium…
Oczywiście całkowicie nie masz racji co do instalacji offline’owo: nie zawsze jest to możliwe, a dodatkowo jest multum zastosowań, w których komputer nie powinien mieć połączenia z siecią, czy to ze względów bezpieczeństwa, czy też dlatego, że do danego zastosowania sieć jest zbędna, więc z uwagi na Brzytwę Ockhama nie powinno jej być, czy też dlatego, że często jest tak, że np. pracownicy nie mający dostępu do internetu (bo ich praca tego nie wymaga), czy nawet połączenia komputerów wewnątrz firmy (i nie mogący wysyłać do siebie wiadomości sieciowych z miłosnymi wyznaniami) jakoś dziwnie zwykle mają większą wydajność w pracy…
Po za tym zupełnie nie rozumiem tych Twoich dywagacji na temat instalacji offline i sieciowej. W czym problem? W Mandrivie nie widzę żadnej różnicy (z wyjątkiem prędkości) w wygodzie instalowania sieciowej czy niesieciowej. Wkładam np. CD z rpm i daję polecenie dodania nośnika, to jak zawiera dane repozytorium, Mandriva dodaje to swojej bazy, wraz z numerem seryjnym CD, jak danych nie ma, to Mandriva skanuje CD (czasochłonne) i takie dane tworzy. Potem gdy coś się instaluje, to Mandriva otwiera napęd optyczny i prosi o włożenie odpowiedniego CD. Z punktu widzenia obsługi przez użytkownika nie ma żadnej różnicy czy instaluje sieciowo, czy nie, więc nie wiem z czego robisz problem.
Naprawdę uwierz – nie ma żadnego problem deb czy rpm! Jedyny problem to twórcy dystrybucji używających innych nazw na te same pliki, inaczej krojących soft na biblioteki, używający innej struktury katalogów a gdy zdarzy im się nawet użyć tej samej struktury, to walących pliki do innych katalogów niż ich koledzy po fachu, innych menu systemowych! Gdyby to ujednolicić, zniknęłoby 99% problemów z instalacją softu: pozostałyby problemy typu inna wersja kompilatora itp., a wzajemna konwersja deb na rpm i odwrotnie byłaby tak prosta, że każda dystrybucja miałaby do tego automat i użytkownik prawie nie zwracałby uwagi czy instaluje deb czy rpm. Obecnie istnieje wiele narzędzi pozwalających instalować, poprzez konwersję rpm-deb i odwrotnie, paczki z obcych dystrybucji, czy automatycznie generujących ze źródeł odpowiednie pakiety, ale z uwagi na wspomniane wyżej problemy wynikające ze źle pojętej “kreatywnej twórczości” deweloperów dystrybucji, zwykle takie narzędzia nie działają w oczekiwany sposób.
1)Jeśli chodzi o repozytoria to nawet Microsoft w następnej wersji windowsa będzie miał własne repozytoria, w którym będą producenci umieszczać swoje programy dla aktualnej wersji windows więc pomysł ze ściąganiem aplikacji bezpośrednio ze strony producenta po prostu upadnie ( ze względu na wyżej podane powody)
2)Jeśli chodzi o jeden format archiwów to i tak to nic nie zmieni gdyż debianowcy np. będą mieli bibliotekę A w wersji 10.0, a bibliotekę B w wersji 3.0. W Redhat będzie odwrotnie- bo każde distro idzie własnym tempem rozwoju więc pojawią się znowu problemy z zależnościami itp. A przecież dla zwykłeko usera liczą się numerki w wersji programu, zaś dla admina jak najstabilniejsze działanie więc może być ciężko znaleźć złoty środek. Jeśli ktoś choć raz tworzył paczkę deb czy rpm to wie, że każda dystrybucja ma inne miejsca gdzie przechowuje poszczególne pliki, inne skrypty, inne wersje bibliotek. Dlatego może po prostu postawić gigantyczny serwer gdzie każdy producent danego oprogramowania będzie pisał jeden skrypt budujący paczkę a następnie serwer będzie budował dla każdego distro oddzielnie, wtedy udałoby się wyłapać więcej błędów w trakcie budowania takiego programu (bo każde distro ma inne wymagania co do bibliotek), a zadowoleni by byli wszyscy. Bo każde distro się rozwija oddzielnie tak jak dotychczas, bo mamy najświeższe programy w repo i dużą ilość oprogramowania bo wrzuca się tylko w jedno miejsce a mieli dla wszystkich chętnych. Ale to chyba jest po prostu utiopia…
Kiedy API zmienia się stosunkowo wolno. Więc program zlinkowany z /usr/lib/libgtk-x11-2.0.so w wersji 2.10 zadziała i z 2.16.
A wersję x.y i z.y (x != z) i tak trzeba oddzielnie instalować.
Mówisz o ABI. Program zlinkowany z GTK+ 2.10 będzie działał z 2.16 pod warunkiem, że nie zmieni się ABI. API może być to samo.
Stałe API oznacza tyle, że można *skompilować* program przeznaczony dla 2.10 korzystając z biblioteki w wersji 2.16, nie że raz skompilowany będzie działał z tą wersją.
Ale poza tym, prawda:)
Masz rację – jednakże zazwyczaj API i ABI zmieniają się tak samo (nie jest tak zawsze – API może być rzeczywiście kompatybilne a ABI się zmienić) – stąd użycie skrótu myślowego (i za dużo czasu spędzonego przy interpretowanych językach
).
Jeszcze raz przepraszam za skrót myślowy
W sumie, to rozwiązanie zastosowane w Gobo Linux mogłoby rozwiązać sporo kwestii. Trzeba stworzyć jednolite API lub wirtualny system plików dla instalatorów. Wtedy to odwołując się do /install/apps/bin mielibyśmy dostęp do binarek pod /usr/bin , a odwołując się pod /install/apps//bin, mielibyśmy dostęp do binariów naszej aplikacji. Oczywiście struktura katalogów w wirtualnym drzewie mogłaby być inna, choćby zgodna z Linux File System Hierarchy
. Zarówno jeden, jak i drugi pomysł jest warty przemyślenia.
/intall/apps/coś/bin dawałoby dostęp do binariów naszej aplikacji. System komentarzy zjadł mi pewien wyraz. Przeprasza. Jeszcze /install/system/bin odwoływałby się do /bin.
wy sie klocicie o rpm/deb, a ja spokojnie wklepuje emerge mozilla-firefox i ide sobie zrobic jesc… ^^ i mam w d. systemy pakietów.
Faktycznie, ja wklepuję pacman -S firefox i nawet nie zdążę zrobić nic do jedzenia
A ja wklepuję emerge opera i akurat zdąrzę sobie przypalić papierosa. ;]
Co jest złego w linkowaniu statycznym ? Pod Windows masa programów tego używa i jakoś sobie radzi. W najgorszym przypadku z grą czy aplikacją dostarczane są odpowiednie DLLki, czasami mające w sumie po kilkanaście MB. Dyski naprawde są bardzo tanie – 500GB to koszt ~250zł. Ludzie instalują masę gier i jakoś na nikim nie robi wrażenia 8GB potwór.
Problemem jest masa śmiecia dostarczanego z różnymi dystrybucjami – 10 terminali, 5 kalkulatorów, 20 edytorów tekstu i wiele innych. Gdyby wprowadzić zestaw Jedynie Słusznych (TM) narzędzi (co najwyżej dwa z każdej grupy), to myślę że chodziło by to lepiej. Pod Windowsem jest prosty notatnik i bardziej zaawansowany wordpad – obydwa spełniają swoje zadanie. Pod dowolnym unixem za to mamy emacs, vi, vim, nano, pico, ee, gedit, kwrite i dziesiątki innych, których po instalacji zwykły użytkownik nigdy nie włączy – poza jednym edytorem z danego środowiska graficznego. Czemu nie może być grupy najbardziej potrzebnych narzędzi, a jeśli użytkownik chce to sobie dorzuci inne ? Chcę posłuchać mp3 to instaluję WinAMPa, za to pod linuxem muszę mieć do wyboru 100 różnych odtwarzaczy, które nie mają połowy funkcjonalności winampa. Gdyby dostarczać tylko najpotrzebniejsze aplikacje, nie było by problemem dostarczanie odpowiednich zależności z aplikacjami tworzonymi przez osoby trzecie.
Problem różnych katalogów rozwiązałoby IMO API, które mówi, jak się nazywa standardowy katalog dla danego użytkownika. Np. pod Windowsem mogę sobie pobrać ścieżkę do katalogu Moje Dokumenty czy gdzie w katalogu użytkownika mają być umieszczane prywatne dane aplikacji.
Nie chodzi o dysk tylko o zajmowaną pamięć potem. DLLki są od tego aby nawet w pamięci jeśli są załadowane wielokrotne to używały pamięci dzielonej lub COW.
Jeszcze do pluginów – różnica między dynamicznymi bibliotekami [dynamic library] a współdzielonymi [shared library].
@AgentJ:
Przy grach to jeszcze ujdzie bo i tak nikt nie uruchomi dwuch jednocześnie ale przy np. toolkitach to taki gtk+ + gdk + zależności to 11 MB. Przy ok. 50 procesach to 0.5 GB pamięci tylko na bibliotekę gtk+ z zależnościami. Xulrunner to 25 MB – używany przez kilka aplikacji. Na oko przeciętna aplikacja ma 20 MB w bibliotekach współdzielonych – przy 100 procesach to akurat jakieś 2 GB (a ja miałem do nie dawna 512 MB a kilka lat temu 256 MB) bez uwzględniania sterty, stosu czy kodu samych aplikacji. Swapowało by się to w sposób straszliwy…
Żaden nie spełnia tego, co potrzebuje. Notatnik jest tak prymitywny, że nie ma żadnych funkcji. Nie ma kolorowania składni. Nie ma spell-checkera. O oskryptowaniu/dodaniu pluginu tego można zapomnieć. To są chyba właściwości, które ma większość wymienionych przez Ciebie edytorów unixowych.
Wordpad to nie jest edytor tekstu tylko procesor tekstu – zupełnie inna kategoria.
Po krótkim rzuceniu okiem na listę to wszystkie bardziej zaawansowane playery (banshee, amarok, rythmbox) powinny spełniać większość oczekiwań (co najmniej 90%) – może z wyjątkiem wsparcia dla skórek WinAmpa 2.x etc. – za to posiadać własne zalety.
Zmienna HOME prawdę Ci powie. Pod sh można użyć ~ dla siebie lub ~nazwa dla innego użytkownika.
Kiedyś stosowano $HOME/.nazwa_aplikacji ale chyba przechodzi się na $HOME/.config/nazwa_aplikacji
Próbowano – nigdy nie osiągnięto popularności. Chyba Independence Linux miał na celu stworzenie takiej dystrybucji. O kilku innych projektach też słyszałem. Wszystkie upadły.
PS. Liczone było przez ldd program | awk ‘{print $3}’ | grep ‘/’ | xargs ls -l -H | awk ‘{sum+=$5} END {print sum}’ a nie ldd biblioteka | awk ‘{print $3}’ | grep ‘/’ | xargs ls -l -H | awk ‘{sum+=$5} END {print sum}’ czy rzeczywiste zajmowanie pamięci.
Standardowe API do pobierania katalogu użytkownika to getenv($HOME); I dostępne jest od… Od ,,zarania dziejów”. A marudzenie na 100 edytorów to właśnie marudzenie.
Krótko: nie masz pojęcia o tematach, o których się wypowiadasz.
API do pobierania katalogu użytkownika mówisz… ~ – powtórzę słownie: tylda. Kolega rozumiem nie widział nigdy na oczy żadnego uniksa?
Standardowy system paczek, struktur katalogów etc. jest Linuksowi tak potrzebny jak rybie ręcznik.
Linux już dawno ma standardowy system paczkowania i nazywa się on “źródła spakowane tar.gz/tar.bz2″. Nie po to wszystko tak zostało wymyślone, żeby teraz zastanawiać się jak korporacyjnym burakom ułatwić wygodne wciskanie zamkniętych blobów w nasze wolne systemy. Bo nie oszukujcie się – tylko do tego będzie używany LSB.
Dla mnie wolność jaką daje mi wolne oprogramowanie po części polega na tym, że mogę swobodnie instalować zamknięte bloby…
Dokładnie! Pakiety źródłowe pozwalają rozwijać się użytkownikowi, instalacja takiego Firefoksa to 4h, które można poświęcić na pogłębianie zainteresowań czy spotkania towarzyskie zamiast bezproduktywnie tracić czas przed komputerem. Poza tym pozwala bardziej doceniać oprogramowanie. Inaczej patrzy się na GIMP-a instalowanego przez 5 minut, a inaczej na kompilowanego przez godzinę. Od razu widać, że ten drugi daje o wiele więcej radości.
A w dodatku: jaka oszczędność prądu! tar.gz/tar.bz2 jest super!
Stek bzdur i na dodatek nie wiesz, że standardowa struktura katalogów istnieje od zarania dziejów i nazywa się FSB.
Drobna poprawka — FHS.
Oczywiście, ale na usprawiedliwienie – 25 minut wcześniej wyżej napisałem dobrze:)
Nie każdy zwykły user Linuksa musi umieć kompilować programy ze źródeł.
Rozwiazanie od dawna istnieje i sam czesto z niego korzystam. Powiem krotko: alien (http://kitenet.net/~joey/code/alien/)
Niestety, tak jak pisali przedmowcy problem tkwi w balaganie jaki powstal w strukturach katalogow. Na nic sie zdalo FHS (http://www.pathname.com/fhs/) skoro i tak wszyscy (poza debianem) maja go w dupie…
Poziom tekstu żałosny, imho cały ten portal (bo już nie wiem czy to osnews/ln/pl) powinien wprowadzić jakiś system oceniania autorów. Mam dość czytywania miernoty i wyławiania perełek. Jak dla mnie autor najpierw niech skończy te studia a potem weźmie się za pisanie tekstów informatycznych.
Po przeczytaniu wszystkich wypowiedzi postanowiłem wtrącić swoje 3 grosze (a może nieco więcej).
Uważam, że Linuksowi jest potrzebna pewna standaryzacja. Powody chyba znane. Natomiast moim zdaniem nie ma co wymuszać takiego a takiego typu paczki. Jak napisał Artwi, przygotowanie kilku paczek to kwestia jednego skryptu (w ostateczności można użyć programu alien) zaś ożywiona dyskusja w tym temacie nad wyższością DEB nad RPM i odwrotnie jasno dowodzi, że raczej nikt z typem paczki nie ustąpi. Poziom kompatybilności powinien być więc niżej – w zawartości paczki. Niech każda dystrybucja ma własny typ paczki, ale trzyma się pewnych standardów na niższym szczeblu. Jednak z racji tego, że rozmieszczenie plików nie jest jednakowe (np. wspomniane plug-iny do Firefoxa), dla mnie idealną sytuacją byłoby, gdyby twórca paczki z programem dał do niej opis gdzie jaki plik ma iść (np. libabc -> biblioteki (np. /lib), libqwerty -> biblioteki lokalne (np. /usr/local/lib) itd.). W ten sposób jeśli tylko system przez jakiś plik konfiguracyjny/zmienne środowiskowe lub w inny sposób dostarczy stosowne informacje o specyficznej dla siebie hierarchii plików, będzie wiadomo co gdzie szukać i pewien poziom kompatybilności będzie zachowany. Opcjonalnie brak takowych informacji mógłby świadczyć o strukturze zalecanej np. przez LSB co skutkowałoby instalowaniem w domyślne katalogi.
Jeśli problemem dla dostawców oprogramowania byłoby istnienie 25 rodzajów paczek, zawsze istnieje możliwość zrobienia archiwum tar.gz/tar.bz2 z odpowiednią zawartością.
To odnośnie paczek i rozłożenia plików.
Kwestia różnych wersji programów i bibliotek w różnych dystrybucjach też jest dla mnie do rozwiązania pod warunkiem pewnej zgodności ABI wszystkich programów danej wersji standardu. Pod tym hasłem rozumiem coś podobnego do LSB (albo i samo LSB – nie zagłębiałem się w jego specyfikację) co definiowałoby, że np. wersja 1.3 oznacza system, który ma Glibc w wersji min. 2.7, kernela w wersji min. 2.6.26, X.org w wersji min. 7.2 itd. Taka specyfikacja byłaby w miarę regularnie uaktualniana i, w przeciwieństwie do LSB, dotyczyłaby TYLKO konkretnych programów/bibliotek. Czyli dana dystrybucja byłaby zgodna z taką specyfikacją niezależnie od rozłożenia plików czy rodzaju stosowanych paczek do programów i pozwalałaby się szybko zorientować czy aktualna wersja dystrybucji na naszym dysku pozwala na używanie danego programu czy też trzeba uaktualnić.
Co do niekompatybilności bibliotek i programów wymagających ich różnych wersji do działania, wolałbym mieć działające programy i 3 różne wersje tej samej biblioteki niż niedziałający program czy kompilowany statycznie (choć to pewne wyjście jest pod warunkiem, że dotyczy kilku aplikacji a nie całego systemu). Co do trzymania kilku wersji biblioteki jednocześnie, zainteresowałbym się rozwiązaniem zastosowanym w GoboLinuksie. Tam mamy np. /Programs/Glibc/2.5, /Programs/Glibc/2.7 i link /Programs/Glibc/Current wskazujący na aktualnie używaną wersję (np. 2.7). Jeśli np. program abc nie chce działać z wersją 2.7 a działał z poprzednią, wystarczyłoby go tylko jakoś zmusić do używania innej wersji niż domyślna. A na resztę programów to nie wpłynie. Do stosowania tego podejścia nie trzeba struktury katalogów GoboLinuksa, choć dzięki niej mogłoby być łatwiej.
/* Tak na marginesie, w tym systemie da się instalować programy bez roota bez żadnych Klik’ów */
Jeśli chodzi o wspomniane wcześniej piekło zależności – na dystrybucjach typu Mandriva, Ubuntu czy openSuSE problem praktycznie nie istnieje a jeśli chodzi o dystrybucje pokroju Slackware’a – cóż… wybór ich użytkowników.
Usunięcie pozostałości po odinstalowanym programie dałbym jako domyślnie zaznaczoną opcję do menedżera programów – czasem może zajść potrzeba zachowania tych plików. A co do pozostałości po ręcznie usuniętym programie – menedżer mógłby wykryć zniknięcie programu i zaproponować wyczyszczenie.
Przyznaję, że nie wiem, jak rozwiązać problem instalacji programu z zależnościami bez internetu. Na razie jedyne co wymyśliłem to ładowanie do paczki wszystkich wymaganych zależności a instalowanie tylko tych niezainstalowanych. Opcjonalnie dystrybucje mogłyby tworzyć dwa rodzaje paczek – z minimalną ilością opcji i zależności i maksymalną. Ale czy to ma sens?
Odnośnie Klik’a – jest kilka możliwości na “kliknij i uruchom”, jednak chyba wszystkie albo wymagają dostępu do internetu albo obecności pewnych programów w systemie. Zastosowanie wyżej opisanej przeze mnie specyfikacji rozwiązałoby ten problem. Nie licząc metody działania, pozostałby jeszcze jeden: co z programami mającymi kilka plików wykonywalnych (Util-linux na przykład)? Który plik uruchomić? Tak, przykład jest zły (bo to nie “klikalne”), ale znajdzie się pewnie wiele innych programów o podobnym problemie. Rozwiązaniem może być…
…Podział aplikacji na dostarczone z dystrybucją (z repozytoriów) oraz innych dostawców. Wolność dla mnie oznacza nie tylko dostępność źródeł czy możliwość ich zmiany, ale także używanie zamkniętego oprogramowania. Nie wszystko pochodzi od Microsoftu i nie wszystko uważam za złe (a nawet nie wszystkie rozwiązania rodem z tejże firmy uważam za złe). Zapewne wielu Czytelników tego portalu używa Opery, Skype czy Flasha. Zatem można by nieco ułatwić producentom tych programów ich dystrybucję – niech każda dystrybucja stosuje własne rozwiązania i rozwija się zgodnie z własnymi założeniami a na to miejsce niech będą istniały jakieś standardowe metody skorzystania z tego co się w systemie znajduje. Innymi słowy spis gdzie jakie pliki można znaleźć, jakie są w systemie wersje programów i bibliotek (i gdzie one są), jak się co nazywa itd. Do tego jasno określone miejsce na instalację programów z zewnątrz (choć to może być zbędne) i mają łatwiej i dystrybucje i inni.
Summa summarum moim zdaniem standard, choć potrzebny, nie powinien wymagać konkretnych rozwiązań a jedynie wymagać jednoznacznego opisu danej dystrybucji tak, by na bazie tego opisu była kompatybilność między dystrybucjami. Nieważne czy pliki wykonywalne są w /sbin, /System/Links/Executables czy w /usr/local/bin. Dzięki opisowi program “wiedziałby”, gdzie się ma odwołać po potrzebne mu dane/pliki (chociażby przez symlinki) a dystrybucje mimo tego samego zróżnicowania byłyby ze sobą kompatybilniejsze.
Ufff… rozpisałem się. Mam nadzieję, że choć 1/10 zdań miała jakiś sens.
Zacznijmy od końca. Dla programów nie dostarczanych z dystrybucją jest /opt , /etc/opt i /var/opt . Gobo Linux faktycznie sprawuje się dość dobrze, jako menadżer paczek
, chociaż myślę, że jednak zarządcy paczek są potrzebni 
. Sam numerek wersji LSB z którą jest zgodny program/instalator może nie wystarczyć. Załóżmy, że do nowej wersji LSB wchodzi nowa(niekompatybilna z poprzednią) wersja GTK, a wersja OpenGL pozostaje. Jeżeli program ma sprawdzić przed instalacją poziom zgodności z LSB systemu, będzie to fatalne rozwiązanie. Jeśli system, to skąd ma wiedzieć czy program korzystał z biblioteki GTK lub OpenGL? Dlatego też każda biblioteka powinna być oznaczona swoją wersją. Ale problemy z dostarczaniem nowszych wersji bibliotek do dystrybucji raczej nie występują. Pomysł z dostarczaniem programowi informacji, gdzie ma włożyć odpowiednie pliki jest niezły. Rozszerzę to jeszcze bardziej. Powinien istnieć plik w /etc ze ścieżkami do określonych miejsc, podobnie jak to się dzieje w przypadku Windowsów. W sumie mógłby nim być mtab lub coś podobnego. Osobiście jestem jednak przeciwny jakimkolwiek instalatorom. Może jako graficzna nakładka na menadżera paczek, ale nie powinna ona być wykonywana z podniesionymi uprawnieniami. Taki instalator wyświetlałby tylko licencję, pokazywał pasek postępu i instruował o wszystkim menadżera paczek. Rozwiązanie o wiele lepsze, wygodniejsze, kontrolowane przez system i nie trzeba iść tak daleko ze zmianami 
.
Też zacznę od końca.
1. Co do instalatora to chodzi mi o istniejące dpkg, yum urpmi i ich nakładki. Po prostu dodałoby im się jedno – dwa zadania więcej i tyle. Oczywiście można by zrobić nowe narzędzie do tych dodatkowych funkcji (ale poza instalacją programów z zewnątrz i ich instruowaniem reszta jest opcjonalna). Natomiast mam wrażenie, że czasem przydałoby się coś jak instalator z Windowsa – jednak jego funkcję ograniczyłbym do wspomnianych paska postępu i licencji oraz wyboru opcji (typu instaluj dodatkowe grafiki). Sam proces instalacji byłby nadal zarządzany przez menedżera paczek.
2. Raczej byłbym za tym, żeby system miał z góry określoną przez twórcę zgodność ze specyfikacją a ewentualnie menedżer paczek przy uaktualnieniu czy usunięciu czegoś sprawdzałby czy nie zniknęło coś ważnego. Natomiast program ( a właściwie menedżer paczek) przy instalacji kontrolowałby, czy zgadzają się wersje.
Zapomniałem dopisać, że przy numeracji typu X.Y Przy tym samym X byłaby zgodność w dół. Zmiana X mogłaby pociągnąć zerwanie zgodności (ale za to występowałaby raz na kilka lat) pozwalając na dostosowanie do trendów i technologii.
Odnośnie kompatybilności – napisałem, że wymogiem jest zachowanie kompatybilności ABI. Natomiast nic nie przeszkadza sprecyzować dodatkowo konkretnych wersji bibliotek. Zgodność z konkretną specyfikacją to swego rodzaju podsumowanie. /* Tak jak wiele różnych procesorów (np. Phenom, Athlon, Sempron) pasuje do tej samej podstawki. */
3. Faktycznie. Zapomniałem o opt. Z tym, że mi chodziło o co innego. /opt jest wg. FHS. Dajmy teraz na to, że komuś się to nie spodoba. Zrobi sobie /packages. Wtedy wystarczy, że system będzie w konfiguracji zawierał informację, że funkjcę katalogu /opt pełni /packages i wilk syty i owca cała.
Teoretycznie pozwoliłoby to nawet lokalizować nazwy niektórych folderów, ale chyba nie ma to większego sensu.
Chyba kliknąłem nie ten link co trzeba. Miała to być odpowiedź na komentarz Sławka.
Nawet prościej: wystarczy symlink /opt –> /packages.
Aha. Można. Tak jest w GoboLinuksie. Ale że im to źle wyglądało, zrobili GoboHide. Zresztą jeden katalog pół biedy. Ale robić linki do 20-30 katalogów to już niezbyt trafione rozwiązanie.
W sumie fajnie by było, jakby do takiego czegoś dostosowali nie tylko programy innych dostawców.