Fedora 10 - Poradnik

[@WalDo]

Zarządzanie zawartością na forum wcale proste nie jest ;-)

Ano nie. Wordpress to dobre rozwiązanie, ale trzeba jakiś zgrabny tekst wrzucić do pierwszego posta, dużymi literami, że skonsolidowany poradnik jest pod adresem http://fedora.pl/poradnik i że treść porad na forum może różnić się nieco od tych w poradniku.

 

I dorzuć mnie do edytorów, proszę. Postaram się nie rozrabiać zanadto. Mam nadzieję, że jest jakiś backup :-]

[sokar620]

Odnośnie problemów z livną: można chwilowo skorzystać z pbone.net

rpm -ivh ftp://ftp.pbone.net/mirror/atrpms.net/f10-i386/atrpms/stable/libdvdcss-1.2.10-5.fc10.i386.rpm ftp://ftp.pbone.net/mirror/atrpms.net/f10-x86_64/atrpms/stable/libdvdcss-1.2.10-5.fc10.x86_64.rpm

Co do binarnych kodeków i wget - wydaje mi się, że to wszystko jedno, w jaki sposób się je pobiera. Niefajne jest to, że wget uruchamiany jest jako root i po instalacji kodeki zostają w katalogu /root (sam to pisałem ale dopiero mnie oświeciło). Można by dodać "usuwamy kodeki".

 

[@WalDo]

Z tego co widzę sporo osób ma problemy ze Skype. Ja akurat nie korzystam, ale jeśli ktoś by umiał napisać jakiś sensowny, uwzględniający różnice sprzętu (desktop, laptop) poradnik, to fajnie by było. Problemy najczęściej na lapkach są z tego co czytałem i najczęściej z mikrofonem.

[sokar620]

Mi osobiście brakuje na wstępie czegoś takiego:

I Ogólne

Programy w Fedorze dostarczane są w postaci pakietów binarnych. Do ich instalacji, oraz zarządzania nimi służy RPM Package Manager. Jego obsługa odbywa się przez wydanie w konsoli polecenia rpm wraz z żądanymi opcjami. Najczęstsze zastosowania to:

• rpm -ivh

nazwa_pakietu – instalacja pojedynczego pakieturpm -Uvh nazwa_pakietu – aktualizacja zainstalowanego pakieturpm -e nazwa_pakietu – usunięcie pojedynczego pakieturpm -qa | grep nazwa_pakietu – sprawdzenie w bazie danych, czy określony pakiet jest zainstalowany.Pakiety rpm zawierają również spis programów, które są wymagane do ich poprawnego działania. W przypadku, gdy w naszym systemie brak jest wymaganego programu lub biblioteki instalacja zakończy się niepowodzeniem – otrzymamy komunikat o niespełnionych zależnościach.

W celu ułatwienia pracy z tak skonstruowanymi pakietami powstał program yum, który sprawdzi za nas listę zależności i w razie potrzeby ściągnie odpowiednie programy i je zainstaluje. Z yuma także korzystamy w konsoli, najczęstsze zastosowania to:

yum install nazwa_pakietu – instalacja pakietuyum remove nazwa_pakietu – usunięcie pakietu (uwaga: jeśli usuwany pakiet jest wymagany przez inny program to ten również zostanie usunięty – proszę o ostrożność)yum localinstall nazwa_lokalnego_pliku_rpm – instalacja, np.: samodzielnie ściągniętego pakietu rpm wraz ze sprawdzeniem jego listy zależności (w przypadku tego polecenia należy przejść w konsoli do katalogu, w którym plik rpm się znajduje)Yum posiada własną bazę pakietów(tak zwanie repozytoria), z których są one ściąganie i instalowane w systemie.

Jeśli dopiero zainstalowałaś/zainstalowałeś Twoją Fedorę, to bardzo często będziesz korzystać z rpm i yuma.

[Theriel]

Fajne, ale troszeczkę bym to zmodyfikował... przeciętny użytkownik nie będzie czytał czegoś, co jest długie. Informacje o localinstall - niepotrzebne (dwuklik na paczkę i się pod Xami instaluje), rpm -e -> wystarczy jak początkujący użytkownik zapamięta yum remove. Z tego co pamiętam ivh można ZAWSZE zastąpić Uvh, więc kolejny punkt odpada .

 

No i położyłbym nacisk odwrotnie - najpierw yum, później rpm...

 

Ale to tylko takie moje ?0.02, sama idea i wykonanie ogólnie mi się podoba .

 

Oczywiście jak powiecie, że zbędnie się czepiam to po prostu dokleję do Poradnika w aktualnej, zaproponowanej wyżej formie...

[@WalDo]

Najczęstsze wykorzystanie yuma to yum update - przynajmniej u mnie.

sokar620 ma rację. Trzeba ludziom powiedzieć, że taki np. PackageKit to tylko GUI do nakładki (yum) na rpm

 

"-Uvh" zdecydowanie bezpieczniejsze. Napisałbym nawet, że należy zawsze stosować opcję "-U" zamiast "-i", bo "-i" może prowadzić do istnienia w bazie pakietów RPM informacji o wielu tych samych programach/pakietach w różnych wersjach. A to może destabilizować system.

 

Ogólnie to wiedza o RPM dla nowego użytkownika jest mało przydatna. Większość będzie korzystać z PackgeKit. Czasem w konsoli z yuma. Z rpm to naprawdę w szczególnych wypadkach.

 

@Theriel - yum localinstall jak najbardziej powinno zostać. Jeśli mówimy o "dwuklik pod Xami", to możemy w ogóle odpuścić yuma i rpm

 

Do tego co napisał sokar620 dodałbym ciekawe opcje yuma takie jak provides, search, list. Warto pokazać łatwość wyszukiwania brakujących paczek/programów/plików za pomocą yumex oraz wskazać stronę rpm.pbone.net, na której łatwo można wyszukać brakujące paczki (czasem łatwiej niż przez yumex czy yum provides)

[Theriel]

Zrobione :]. Nie mam tylko zbytnio pomysłu jak zrobić żeby te komendy przy "yum" się tak z tekstem nie zlewały... zrobienie bulletpointów póki co dało najlepszy efekt, ale wciąż...

[Gość _PaT]

Poradnik zawiera sformułowanie następujące

Tu uwaga: pracując na komputerze z procesorem 64-bitowym po wybraniu architektury x86_64 miałem do wyboru nadzorcę QEMU lub KVM. Dla każdej innej architektury nie było możliwości wyboru - zawsze nadzorca QEMU. Jeśli ktoś wie dlaczego tak jest lub przynajmniej wie jak dla innych architektur umożliwić wybór KVM, to chętnie się dowiem i uzupełnię ten tutorial.

Właściwie trochę jest to zamieszane. QEMU, jako emulator, sam z siebie oferuje emulację różnych środowisk, jak i386, x86_64, ppc itd. (uwaga, oznaczenia architektur są nieintuicyjne i mylące). Natomiast KVM jest , jak nazwa wskazuje, techiką wirtualizacji na poziomie jądra systemu, co oznacza mniej więcej tyle, że nie zmieniamy nic związanego z rozkazami kierowanymi do procesora (brak translacji/emulacji), natomiast wykorzystujemy dodatkowe ringi (nie tylko 0 i 3 jak to bywa w systemach bez wirtualizacji) . Żeby wyjaśnić przejrzyście, trzeba by się trochę napocić, dlatego sobie to odpuszczę. Wiedzę taką łatwo znaleźć w necie.

 

Teraz bardziej skrótowo.

QEMU jest emulatorem, dlatego na liście wyboru są architektury, które potrafi emulować (to też trochę na wyrost, ale potencjalnie prawda).

KVM nie jest emulatorem, dlatego na liście jest tylko bieżąca architektura, dla której potrafi wykorzystać wirtualizację. Jeśli mamy procesor 64-bitowy, a chcemy wgrać system 32-bitowy, to nie ma problemu. 64-bitowy procesor w maszynie gościa, tak jak na natywnej, również obsługuje 32-bitowe rozkazy.

 

Sądzę, że końcowy użytkownik nie musi widzieć takich opisów w poradniku. Jako ciekawostkę podam, że są plany połączenia QEMU i KVM. KVM korzysta z dziedzictwa QEMU (np. w kwestii wirtualnych dysków), zgodnie z zasadą DRY.

[Gość _PaT]

Przeczytałem cały ten temat oraz poradnik i zauważyłem niespójność ideologiczną. Część z Was widzi poradnik jako książkę kucharską, do której zagląda się tylko po to, żeby zrealizować jakiś przepis krok po kroku. Mamy problem i chcemy go szybko rozwiązać(pewnie dlatego nazwałbym poradnik książką kucharską lub zbiorem przepisów). A inni zauważają, że ludzie jednak przejawiają głębsze zainteresowanie jakimś tematem, co wynika z ich ciekawości lub bardziej złożonego problemu. W tej sytuacji poradnik powinien stanowić coś na kształt dokumentacji technicznej, a czasem nawet deweloperskiej. Trzecim rodzajem potencjalnej formy przekazania wiedzy jest oznaczanie tematów na forum jako [sOLVED] (czego u nas nikt nie robi), lub przepisywanie ich na konkretne receptury (czego też "prawie" nikt nie robi). Od przepisów różni je to, że musimy spełniać pewne wstępne warunki i oczywiście wiązać się z problemem (np. mam notebooka firmy xxx, model yyy, zainstalowałem beryla na jądrze xen i mój netbeans na openjdk nie potrafi malować w okienku). Są to problemy wysoce specjalistyczne, z którymi użytkownicy Linuksa muszą sobie jednak radzić.

 

Widzę zatem trzy opcje:

1) Książka kucharska

2) Nieformalna dokumentacja (dokumentacja użytkowników)

3) Zbiór rozwiązań określonych problemów

 

Dobór narzędzi, który mi przychodzi do głowy do tych celów:

wiki - 2, 3

forum - 2, 3

stronka internetowa (jak obecny poradnik) - 1

 

Czym jest poradnik, co ma zawierać i do kogo jest skierowany? Która z powyższych trzech opcji, a może jeszcze inna? Na jakiej jest licencji? Dlaczego nie przetłumaczyć Unofficial Fedora FAQ, przecież obecnie poradnik idzie w tę stronę?

 

Ktoś wcześniej wspomniał, że poradnik nie posiada spisu treści. Mądra uwaga. Przychylam się do prośby o jego dodanie.

[Gość _PaT]

Do informacji o phpMyAdminie dopisałbym, że w domyślnej konfiguracji, jest dostępny tylko z lokalnego hosta. Można to zmienić w /etc/httpd/conf.d/phpMyAdmin.conf, co nie jest zalecane ze względu na jego czarną przeszłość

[Theriel]

Kiedy tworzyłem pierwszą wersję założeniem była książka kucharska. Polski odpowiednik My-guides, HowToForge, MJMWired. Dlatego też byłem przeciwny umieszczaniu zbyt dużej ilości opisów, wyjaśnień dot w/w yuma i RPM-a. To jest dokumentacja - a to się bardziej nadaje na wiki Fedory. Uważam też, że założenie "książki kucharskiej" powinno zostać - od rozległych opisów są wiki, dokumentacja, man etc... choć, jak już pisałem wcześniej - ja tego nie robię dla siebie, więc lepiej by było chyba wspólnie uzgodnić jakąś formę i się jej trzymać. Jeżeli większość uważa, że powinno być inaczej - OK...

 

Jak ja to widzę:

Jestem użytkownikiem Fedory, chcę coś zainstalować/skonfigurować - zaglądam do poradnika i... mam. <-- tego oczekuje zdecydowana większość. Czy nam to się podoba czy nie.

Chcę się dokształcić - poczytam dokumentację...

Oczywiście, *szczątkowe i podstawowe* fragmenty dokumentacji można przemycać - jak np: wstęp o yumie. Ale bez przesady.

 

Dlaczego nie stworzyć tłumaczenia Unofficial FAQ? 1)Bo nikt nie będzie zgadywał co jest w changelogu w/w faq i wprowadzał zmian, więc lepiej mieć coś niezależnego, nawet jeśli nam się większość zagadnień powtórzy. 2)Ponieważ tutaj jest z założenia inna forma - książka kucharska z nagłówkami poszczególnych działów (aplikacje, serwer, internet etc.), a nie pytanie-odpowiedź na temat Fedory... 3)Ponieważ sądzę, że mogłoby to się rozrosnąć jako poradnik kierowany do wszystkich - patrz np: aktualny dział zawierający konfigurację aplikacji serwerowych. 4)Ponieważ Unofficial Faq nie jest pozbawiony błędów -> np. tylko jeden sposób instalacji sterowników do nvidii - a jak ktoś będzie potrzebował legacy?

 

Dlatego zaciągać inspirację z Unofficial FAQ - jak najbardziej. Stworzyć tłumaczenie - raczej niet...

[@WalDo]

Co racja to racja. Ja w każdym razie nie do końca byłem pewien formy tego co pisałem. Przyczyna niejasnej formy leży zapewne w tym, że cały temat poradnika rozpoczął się dość spontanicznie. Pewnego wieczoru Theriel zapytał mnie na PW czy on może coś takiego zrobić Powiedziałem "czemu nie" i za kilka godzin pierwszy post już był. A potem każdy z autorów dodawał co mu serce dyktowało

 

Osobiście byłbym za gotowymi przepisami. Dokumentacja jest w sieci (sporo gotowych przepisów również ), więc odnośniki do nich można podać w przypisach do danej porady - ci którzy będą chcieli wiedzieć więcej będą mieli ułatwione zadanie, ci którzy chcą tylko rozwiązać/ominąć problem skorzystają z poradnika i... zamkną przeglądarkę.

 

Przy okazji dzięki _Pat za wprowadzenie do tematu KVM. W sumie jest tak jak intuicyjnie przeczuwałem, resztę sobie doczytam.

[@Sorror]

Niezależnie od charakteru poradnika, powinien on być umieszczony w ramach forum - spora liczba sporadycznych jego użytkowników nie zdaje sobie w ogóle sprawy z istnienia czegoś poza nim (fedora.pl), poza tym takie dzielenie to nic innego jak kolejna przeszkoda do pokonania w poszukiwaniu informacji. Przykładem świecić nam może fedoraforum.org, gdzie wszystko jest ładnie zintegrowane z vB. IPB również ma odpowiednie narzędzia, gdyby je wykorzystać można by w końcu zrezygnować z dzielenia serwisu na fedora.pl i forum.fedora.pl.

[Arabski]

Też sądzę, że formuła "książki kucharskiej" się lepiej sprawdzi. Możnaby najwyżej podlinkować parę haseł dla dociekliwych - coś w stylu "Dalsza lektura"

 

Przez ostatnie 2 dni, F10 instalowałem chyba 5 razy Nie pytajcie dlaczego. W każdym razie poradnik się świetnie sprawdza "na przeklikanie" żeby szybko mieć co potrzeba.

[HaKsiu]

Witam.

 

Jestem tutaj nowy a więc chcę się z wami przywitać i zadać pytanie dotyczące poradnika dla Fedory 10

A dokładniej, mam pytanie czy opisana instalacja sterowników ATI

http://forum.fedora.pl/index.php?showtopic=20092"" odnosi się do Fedory 32 czy także do 64 bitowej, czemu się pytam po zainstalowaniu opisanej tam instalacji do kart ati mam problem z botowaniem fedory przy próbie botowania wersji kernela 26.27.12-17.25.fc10.x86_64 wyskakuje błąd "Error 15: File not found" w starszej wersji kernela botowanie dziala .

 

Czy może jest jakaś na to rada ?