Na luzie > Rozmowy w toku
Jesli nie arch lub manjaro ,to co ?
pavbaranov:
--- Cytat: Arristo w Luty 10, 2015, 08:50:41 ---Z tego co czytałem, SuSe słynie z problemów ze sterownikami do kart graficzncyh.
--- Koniec cytatu ---
Jak w każdym przypadku stosowania sterowników własnościowych. Te najlepiej mieć ustabilizowane na jakimś LTSie, dużo czytać nt. zmian wprowadzanych wraz z nową wersją Xów i czy są one wspierane przez sterowniki własnościowe. Dopiero jeśli z lektury wynikać będzie, że wszystko jest ok, to wówczas można cokolwiek aktualizować. Generalnie nie sprawdzają się one we wszystkich dystrybucjach oferujących bardzo nowe elementy core, głównie kernel i Xy.
--- Cytat: Arristo ---A co Sabayona, to z tego co pamiętam są wersje np. 15.1, 15.2, 15.3 itd. 15.2.1, to najwyraźniej poprawiona wersja 15.2. Możesz sprawdzić np. tutaj ftp://mirror.optusnet.com.au/sabayon/iso/monthly/ - jest wersja 15.1, 15.2 i 15.2.1
--- Koniec cytatu ---
Zanim Ci napisałem sprawdziłem ;) :
--- Cytuj ---Sabayon 15.02.1 is (...) a monthly release generated, tested and published to mirrors by ourbuild servers containing the latest and greatest collection of softwareavailable in the Entropy repositories.
The ChangeLog files related to this release are availableon our mirrors.
--- Koniec cytatu ---
Źródło: http://www.sabayon.org/latest
Co mniej więcej oznacza: Sabayon 15.02.1 jest miesięcznym wydaniem (dystrybucji), utworzonym z przetestowanych paczek i upublicznionym na serwerach, zawierającym najnowsze i najlepsze, dostępne oprogramowanie. Zobacz dziennik zmian na naszych serwerach.
Sytuacja z niedziałającym instalatorem trafia się niekiedy każdej dystrybucji i jest zależna od sprzętu (hardware'u). Odkąd używam linuksa nie pamiętam, by było wydanie jakiejkolwiek dystrybucji, która - jeśli instalator w ogóle ma - to byłaby niemożliwa do zainstalowania na każdym komputerze. Dlatego jak pisałem - informację podałeś cenną, ale - jeśli bez konkretów, to połowiczną i w ten sposób wprowadzającą w błąd.
darecki:
O, juz widze ze Arristo poinformowal , ze instalator w sabayonie dziala , tez akurat sprawdzalem. Sam Sabayon to fajny systemik , tylko ze jego znakiem firmowym bylo to ze "rozkraczal sie " po pierwszej wiekszej aktualizacji.
Moze teraz to sie zmienilo , nie wiem , mam nadzieje ze mnie oswiecicie , pozdrawiam
pavbaranov:
--- Cytat: darecki w Luty 10, 2015, 11:28:22 --- Sam Sabayon to fajny systemik , tylko ze jego znakiem firmowym bylo to ze "rozkraczal sie " po pierwszej wiekszej aktualizacji.
--- Koniec cytatu ---
Bo Sabayona, jak zresztą każdy system typu rolling release nie aktualizuje się, jak wyjdzie "większa" aktualizacja, a robi to na bieżąco. Wówczas ilość problemów jakie mogą powstać maleje, a nadto dużo łatwiej jest zdiagnozować problem i ewentualnie przywrócić poprzednie, działające rozwiązania. Z tym ostatnim, w przypadku Gentoo (czy Sabayona bądź Calculate) oraz Archa większych problemów nie ma - w przypadku Manjaro - mogą być spore, albowiem ta dystrybucja nie ma żadnego archiwum ani paczek, ani nawet poprzednich PKGBUILDów. Pół biedy, jeśli pomiędzy aktualizacją nie zmieniły się PKGBUILDy - można je pobrać, zmienić i zbudować coś ze starszym oprogramowaniem, jeśli jest w ogóle dostępne w upstreamie. Pół biedy, jeśli w cache pacmana, takie paczki się znajdują - można je zainstalować stamtąd. Jeśli jednak nie, to... modły do Phila i jego drużyny. W Gentoo nie ma problemu, bowiem praktycznie zawsze można zbudować dowolną wersję aplikacji. W Sabayonie - jeśli pamiętam, przynajmniej jakiś czas są jeszcze starsze wersje paczek. Calculate - tu przyznam, że nie mam pojęcia, ale w razie czego są dostępne ebuildy (zresztą te same w Sabayonie i Gentoo). Ba, samo portage zwykle trzyma kilka wersji ebuildów dla kilku różnych wersji paczek, zatem przypadłości można zniwelować. Niemniej jednak, jak w każdym systemie budowanym ze źródeł (mimo binarek w Sabayonie i Calculate, to są to systemy budowane ze źródeł), szczególnie zmiana kompilatora może powodować duże problemy z oprogramowaniem i prowadzić do wywrotki całego systemu.
Generalna zasada dla stabilnych desktopów w przypadku dystrybucji RR: kernel LTS, aktualizacja core wyłącznie jeśli jest to konieczne (po co poprawiać coś co działa dobrze, wszak zasada, że lepsze jest wrogiem dobrego działa powszechnie), a aktualizacja aplikacji wówczas, gdy się tego chce, bądź gdy trzeba (np. dostarczane są jakieś poprawki błędów, a już szczególnie bezpieczeństwa). Akurat menedżer pakietów w Sabayonie (przynajmniej w czasach, gdy używałem tej dystrybucji) dość dobrze potrafił to rozwiązać, choć nie zawsze z sukcesem (szczególnie, gdy mu się na siłę w czymś pomogło :) )
darecki:
Pawle , czyli , z tego co napisales, mozna wywnioskowac , ze jesli chciałoby sie miec "stabilnego" archa , to powinno sie korzystac z kerneli lts.Przyznam sie szczerze , ze staralem sie dosc duzo czytac na ten temat (stabilnosc arch linux-a) i z takim pogladem spotkalem sie pierwszy raz .Przewaznie slyszy/czyta sie aby nie instalowac rzeczy z AUR , czeste aktualizacje , oczywiscie czytac to co pisza deweloperzy o dostepnych aktualizacjach , (choc jesli chodzi o to , to chyba tez i deweloperzy czesto zapominaja umiescic odpowiednie wzmianki na stronie arch-a) , no i oczywiscie nie korzystac z repo testing no i pare jeszcze wskazowek.
Tak ze , dzieki za cenna informacje , teraz , na pewno jak bede instalowal system skorzystam z Twojej sugestii.
pavbaranov:
Darek - Po pierwsze jestem gorącym przeciwnikiem twierdzeń o "stabilnym" systemie, czy też np. "lekkim" środowisku bądź aplikacji. Cały podział na "stabilne" linuksy i pozostałe wziął się z bardzo prostackiego tłumaczenia nazw repozytoriów w Debianie. Tam mamy "stable", "testing" i "unstable". Efekt tego jest taki, że w głowach niektórych naszych linuskowych myślicieli ;) wytworzony został obraz, że jeśli jakaś dystrybucja nie ma repozytorium "stable", to jest... "niestabilna" itp. itd. bzdury.
Ręczę Ci, że ten "podział" nie ma nic wspólnego ze "stabilnością" (inna sprawa jak to rozumieć) systemu, a jedynie z psychologią, a w zasadzie z efektem, jaki się u nas wytwarza szermując właśnie takimi sformułowaniami. Podobnie mogę ręczyć, że każda licząca się i nieeksperymentalna dystrybucja jest "stabilna".
Jeśli w Archu coś trafia do repozytoriów (nietestowych) to zbudowany z nich system ma działać. I - najczęściej - działa. Ba, mogę zaryzykować twierdzenie, że jeśli jest odpowiednio administrowany przez użytkownika, to powoduje mniej problemów od niejednej dystrybucji "wydawniczej" Debiana włączywszy.
Każda instalacja, a nie dystrybucja, jest na tyle stabilna, na ile świadomym jest jej użytkownik. Fakt, że wiele dystrybucji (jeśli nie wszystkie) dostarczając doprawdy wielu aplikacji, często przeoczy, że np. jakiś paczka X wprawdzie daje się zainstalować, ale wadliwie działa, albowiem paczka Y, z którą ma współdziałać winna być w innej wersji, mieć jakiś patch itp. To jest nieuniknione i wspólne dla wszystkich systemów, niezależnie od tego, czy jest to Android, Windows, czy którakolwiek dystrybucja linuksowa.
Wracając do tezy, którą postawiłem w poprzednim poście, to ma ona 2 aspekty. Po pierwsze tak - kernel LTS daje więcej spokoju zawsze. Takie rozwiązanie ma jednak swoje wady. Kernele stają się LTSami w sposób albo arbitralny (tzn. ktoś postanowił się nim dłużej opiekować), albo stają się, albowiem dana wersja jest wykorzystywana np. w dużej ilości serwerów, z uwagi na to, że np. RedHat w jakiejś wersji taki kernel oferuje. Albo Google w Androidzie. Trzeba pamiętać o tym, że linuksowy kernel, tak jak zresztą całe oprogramowanie, jest w ciągłym rozwoju. Praktycznie nie ma czegoś takiego, co byłoby w jakiś sposób pełne i skończone. Jest jedynie, na określonym etapie swojego rozwoju na tyle dojrzałe, by nadać mu jakąś cyferkę (z przyczyn marketingowych te cyferki niekiedy nadawane są bez sensu, a przykładów dawać nie będę, bo jest ich mnóstwo). Nie oznacza to wcale, by po wypuszczeniu takiej wersji nie były prowadzone dalsze prace. Wracając do kernela. Jeśli dany LTS oferuje Ci to, co potrzebujesz, a następna/-e wersje kernela nie wprowadziły dla Ciebie istotnych zmian w funkcjonalności (np. w następnej wersji nie ma wprowadzonej obsługi jakiegoś sprzętu, albo lepszej obsługi), z której chciałbyś skorzystać, to LTS jest rozsądnym wyjściem na jakiś czas. Z takim kernelem bowiem musi współpracować całe pozostałe oprogramowanie. Niemniej jednak, jeśli w nowszym kernelu wprowadzone zostało coś, co powoduje, że lepiej z niego skorzystać, nie warto pozostawać przy LTSie. Dam Ci przykład. Od kilku lat mam komputery oparte o platformy AMD. W kernelu 3.13 wprowadzona została pewna funkcjonalność, która powodowała, że układy AMD (grafika) przestawały się w końcu tak bardzo grzać. Jaki był zatem sens pozostania na 3.12 (LTS), skoro nie był on dla mojego sprzętu lepszy, a wręcz przeciwnie. Niemniej jednak, gdybym miał Intela, to być może używałbym 3.12 (a teraz 3.14) i w ogóle nie przejmował się 3.13 i następnymi.
Drugi aspekt jest istotny wyłącznie dla użytkowników korzystających z zamkniętych sterowników, głównie grafiki. Te sterowniki, niezależnie od tego, od jakiej pochodzą firmy, najczęściej wyróżniają się kilkoma cechami. Po pierwsze niezmiernie rzadko "aktualna" wersja sterownika jest "aktualna" dla "aktualnego" kernela, czy Xów. Innymi słowy ich współpraca może być żadna. Druga, to zwykle potrzebują one innych "ustawień" w kernelu od sterowników otwartych. Efekt jest taki, że bardzo często po zmianie jednego z komponentów "core" trzeba przeinstalować sterowniki, bowiem inaczej system się rozleci (tzn. nie wstanie). W *buntu czy Debianie sprowadzało się to do odinstalowania sterowników własnościowych, zainstalowania wolnych, restartu, zainstalowania nowego systemu, restartu, zainstalowania własnościowych, odprawienia modłów i restartu... :) Generalnie zasada praktycznie dla każdego systemu. M.in. dlatego Catalyst nie jest wspierany oficjalnie przez Archa. Trudno bowiem pogodzić system, który co do zasady ma dostarczać najnowszego oprogramowania ze sterownikami, które bardzo często aktualność mają z elementami core kilka miesięcy wstecz. To dlatego też w Manjaro zdarzało się, że elementy core przez długi czas nie były aktualizowane (co powodowało, że wprawdzie Catalyst działał, ale ci, którzy korzystali z wolnych sterowników mieli przez dłuższy czas "gorsze" wsparcie).
Innymi słowy - wszystko z wyczuciem i według potrzeb.
Teraz dochodzimy do "stabilności" dystrybucji. Jak już wspomniałem, praktycznie termin dla mnie nie istnieje. Co to oznacza, że dystrybucja jest stabilna? Zupełnie inna rzecz, to stabilność systemu. Niestety prawda jest bolesna: stabilny system jest pochodną rozważnego użytkownika (administratora). Nie odpowiem Ci co trzeba robić. Mogę powiedzieć tylko i wyłącznie tyle, że siedząc na rolling, zwykle stosuję się do następujących zasad i mój system jest - przynajmniej w miarę - stabilny (a korzystam z repozytoriów mesa-git oraz z testing):
- system aktualizuję często (najczęściej raz dziennie), po aktualizacji sprawdzam, czy przeszła ona bez problemów; jeśli nie (a najczęściej przechodzi) wracam z wersjami oprogramowania, które ostatnio zainstalowałem do wersji poprzednich,
- kernel kompiluję sam, choć mógłbym spokojnie używać np. linux-ck,
- używam od kilku ładnych lat wyłącznie wolnych sterowników (nie jestem graczem, sterowniki własnościowe nie są mi potrzebne),
- co jakiś czas robię konserwację systemu.
I to ma działać i działa.
W zasadzie jedno mnie w Archu wkurza, a mianowicie raz na 2 miesiące z jakichś przyczyn, o których nikt nic nie wie, przestaje mi działać albo drukarka, albo skaner. Na pewno nie jest to moja wina, tylko jakiejś aktualizacji, która jest trudna do uchwycenia, a oczywiście dewowie Archa o tym nie informują, albowiem generalnie nie informują o niczym.
Nawigacja
[#] Następna strona
Idź do wersji pełnej