Nowe posty Problem ze sterownikami. (5) 2024-04-13, 21:25:16
Instalacja xfce4 (2) 2024-04-13, 16:20:17
Serie kompilacji bez instalacji dla “emerge” w Gentoo (2) 2024-04-08, 18:40:04
Plasma 6 w Neonie ssie trochę mniej ... (17) 2024-04-05, 10:03:46
Problem z Linux Lite po instalacji (3) 2024-04-03, 14:23:40
Jak właczyć num locka przy starcie systemu debian 12? (12) 2024-04-02, 17:43:54
Brak dźwieku w systemie. (5) 2024-04-02, 16:13:41
Dystrybucja pod HP Omen (7) 2024-03-29, 11:33:05
[Poradnik] Wyszukiwanie Sterowników (2) 2024-03-27, 21:08:23
Ile pingwinów? (1) 2024-03-27, 08:59:24
|
Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.
Wiadomości - pavbaranov
871
« dnia: 2018-02-26, 20:29:40 »
A ja wybrałem GNU/Linux bo jest to oprogramowanie do swobodnego działania i nie rozumiem dlaczego jako początkujący użytkownik mam nie mieć wolności modyfikowania wedle własnego uznania. Cóż i jeśli tego nie rozumiesz, to... w zasadzie nie powinieneś używać jakiegokolwiek systemu z linuksem na czele. A zostawienie wszystkiego tak jak jest bo działa i jest ok, to niestety myślenie typowo MS - myślenie komercyjne - nie dotykaj bo zepsujesz! Nie ruszaj bo jest jakaś polityka... W Linux nie ma żadnej polityki jest wolność. NIe, to nie żadna polityka i nie myślenie MS. To rozsądek. Pierwsze to nie "wolność", a absolutnie proste: you known your system! Dopiero jak poznasz, to możesz cokolwiek - a i to ostrożnie - robić. I to na własną odpowiedzialność. Jak zaczniesz cokolwiek, komukolwiek radzić, to musisz być tego rozwiązania na 100% pewny, a rozwiązanie sprawdzone. Innymi słowy obowiązuje stara, lekarska zasada: primum non facere. Właśnie dlatego, że linux daje taką wolność. Sorry, ale nie wytrzymałem.
872
« dnia: 2018-02-26, 15:19:34 »
Nie - nie rozwalisz systemu, jeśli zmiany wprowadzasz sensownie. Popatrz sobie na fragment mojego ~/.bashrc (nie nadaje się - przynajmniej w części dla Ciebie po to inny system): # Moje aliasy:
alias Syu='sudo pacman -Syu'
alias Rcns='sudo pacman -Rcns'
alias update-grub='sudo grub-mkconfig -o /boot/grub/grub.cfg'
alias mirror='sudo reflector --verbose --latest 5 --sort rate --save /etc/pacman.d/mirrorlist'
alias KDEinfo='qdbus org.kde.KWin /KWin supportInformation'
(nie mówię, że to rozwiązanie najlepsze, jedyne - po prostu wskazuję jak może to wyglądać): Syu, czy Rcns - tak nazywających się binarek nie dostarcza żadna paczka. Spokojnie zatem mogę zrobić taki alias. Jednocześnie dla mnie jest bardzo czytelne (to fragment polecenia: pacman -Syu lub pacman -Rcns). Podwójnie zatem jest ok: raz - rozwiązanie funkcjonuje wyłącznie na moim koncie, dwa - brak obawy, że jakaś paczka to zdubluje. Podobnie np. w przypadku KDEinfo. Nie ma takiej obawy. Dwa następne wymagają odmiennego potraktowania. Jeśli chodzi o "mirror" - cóż - tu w istocie nie mogę wykluczyć, że jakaś paczka mogłaby dostarczyć tak nazywającej się binarki. Sprawdziłem jednak - nie mam w systemie, zatem może być. Przynajmniej do chwili, w której nie zainstaluję czegoś, co dostarczy /usr/bin/mirror. No i słowo odrębne, czyli update-grub (tak, wiem w AUR jest paczka, która instaluje taki skrypt, jednakże nie jest on mi potrzebny, a ze względu na to, że jest w AUR nie obawiam się, że jakaś paczka instalowana z repozytorium zainstaluje mi taką zależność; to, co buduję z AUR jest natomiast przeze mnie wnikliwie przeglądane). W moim systemie zatem nie ma czegoś takiego jak update-grub - mogę bezpiecznie użyć takiego aliasu. Inaczej sprawa wygląda z Mintem, który taką paczkę dostarcza (nie powiem, czy obecnie to update-grub, czy update-grub2) - ustawienie takiego aliasu byłoby zatem bez sensu. Jeśli zatem zrobisz z głową, to szanse, że coś sknocisz są minimalne. Nawet jeśli uda Ci się sknocić, to całość wprowadzanych zmian masz w jednym pliku (~/.bashrc), do którego masz dość łatwy dostęp nawet gdy coś w nim sknocisz. Jeśli wszystkie aliasy będziesz miał w jednym miejscu tego pliku to łatwo się tu połapiesz i... wszystko masz czytelne. Przy czym aliasy nadają się na właśnie jakieś skróty dłuższych poleceń. Musisz jednak pamiętać, by nie zastąpić polecenia systemowego. Skrypty - wg mnie - do bardziej zaawansowanego użytku i jeśli już wprowadzane do systemu (czyli nie w /home, a umieszczane w katalogach systemowych), to bezwzględnie za pomocą paczki, którą ich menedżer będzie mógł zarejestrować (tak wiem, w przypadku deb to droga przez mękę, choć o ile pamiętam, to był jakiś programik, który ze skryptów robił nie tylko deb, ale nawet i przetwarzał taki skrypt do binarki). Jeśli w moim przykładzie, jako alias dałbym coś takiego: alias pacman='sudo pacman -Rcns'
To wywołanie wówczas systemowej komendy zwróci informację: błąd: tylko jedna operacja może być użyta na raz
Łatwo zapomnieć o takim "cudownym" aliasie, a przedstawiając na jakimś forum taki "problem" spowodujesz jedynie konsternację innych użytkowników, bowiem mało kto wpadnie na to, że swoim aliasem podmieniłeś polecenie systemowe i to powoduje jego wadliwe działanie. Podsumowując: jeśli wiesz co robisz - krzywdy sobie nie zrobisz. Ważne by wiedzieć jak i co.
873
« dnia: 2018-02-26, 12:01:32 »
Bodaj najlepjej udokumentowane miejsce w necie z informacjami (także programami), które są Ci potrzebne: http://pendrivelinux.com/, bo rozumiem, że wyjaśniać Ci co się stało nie ma ani potrzeby, ani sensu.
874
« dnia: 2018-02-26, 11:58:36 »
Taki lekki OFF-TOP, ale jednak na kanwie. Na początek muszę zrobić drugi  @Zdzisław Knopp - wprawdzie posłużysz tu jako przykład, ale to co napiszę, to nic osobistego. Bezpieczeństwo itd. - to sprawy absolutnie oczywiste. Dla świadomego użytkownika. Weźmy jednak pod uwagę, kto zadaje nam pytanie. Akurat Zdzisław jest przykładem totalnego świeżaka, który po prostu linuksa (a nie wiem, czy jakikolwiek inny system) nie zna. Uczy się dopiero jego i to nie tylko po omacku, nie tylko nie sięgając po materiały źródłowe (aczkolwiek wiem, że w przypadku Minta to trudne, bo... ich nie ma  , to jeszcze bardzo nieuważnym (skoro nie dostrzega tego, co jakiś program mu nawet podpowiada). Obowiązkiem zatem każdej osoby, która chce mu pomóc winno dać mu taką poradę, która w jak najmniejszym stopniu będzie ingerować w system. Jeśli tylko istnieje jakieś rozwiązanie, które ogranicza się do przestrzeni jego użytkownika, to takie winno zostać mu podane. Inaczej, za chwilę, jego Mint będzie miał z Minta paczki i repozytoria. Oczywiście można i taki system utrzymywać, ale trzeba być takiego systemu świadomym. Zdzisław nie jest i tu zaczyna się podstawowa kwestia i zabawa. Mniejsza o to, czy utworzy sobie "skrót" (w jego rozumieniu) do programu w postaci aliasu, czy w postaci skryptu. Z pewnego punktu widzenia na jedno wychodzi. Niemniej jednak teraz zrobię to, co być może powinienem na samym początku odpowiadając w tym wątku. @Zdzisław Knopp - Pamiętaj, że ów "skrót" (jak go rozumiesz) jest pewną ingerencją w system. Piszesz, że chciałbyś by po wpisaniu "l" system wykonał "ls -l". Ok. Wszystko pięknie i ładnie, ale... (to co poniżej, to jedynie przykład). To jest prawdopodobnie bezpieczne, bowiem być może nie istnieje jakiś program, który masz/możesz mieć zainstalowany, który wykonywałby się poprzez wpisanie samej literki "l". Zwróć jednak uwagę, że w tym momencie dokonałeś pewnej ingerencji. Jeśli zrobiłeś to tak jak ktoś tu proponował w /usr/bin, czy potem w /usr/local/bin, to owe "Twoje" "l" znane jest już całemu systemowi, wszystkim użytkownikom. Jeśli teraz zainstalujesz jakiś program, który będzie się wykonywać w taki sam sposób, to które z owych "l" ma zostać wykonane? To "Twoje", czy to, które zostało dostarczone w paczce? Dobrymi zasadami tworzenia własnych rozwiązań tego typu w systemie są: - stwórz taką nazwę, która jest dla Ciebie łatwa do zapamiętania, ale raczej nie przyjdzie do głowy komuś innemu, - sprawdź, czy jakikolwiek inny program w systemie nie ma takiej nazwy - nazwa musi być absolutnie jednoznaczna, - umieść takie rozwiązanie wyłącznie w sposób umożliwiający korzystanie z niego przez Ciebie rozumianego jako użytkownik systemu; żaden inny użytkownik (nawet nieistniejący!) nie powinien z niego korzystać, chyba, że jesteś administratorem takiego systemu i doskonale wiesz co robisz i dlaczego, - pamiętaj, że od chwili zastosowania swojego rozwiązania w systemie, inny program, który będzie się chciał odwołać do programu o takiej samej nazwie, jaką właśnie utworzyłeś, to wykona Twój program (coś tu zakręciłem, ale chyba wiadomo o co chodzi); jeśli np. (trywialne) Twoje rozwiązanie będzie polegać na np. "podmienieniu" cp przez powiedzmy cp -r, to od tej chwili każde wywołanie cp dokona przekopiowania wraz z podkatalogami, czy tego chcesz, czy nie, - jeśli Twoje rozwiązanie to aliasy, to umieszczaj je wyłącznie w ~/.bashrc, a sam plik ~/.bashrc w wersji "nieruszonej" zachowaj w kopii (choć jego skasowanie winno spowodować odwtorzenie w wersji "oryginalnej" dla danej dystrybucji), - jeśli to skrypt, to trzymaj w jednym, określonym miejscu (moja sugestia to ~/bin, ale możesz dać cokolwiek innego; jeśli ma być widoczne - dodaj to PATH), - jeśli po dokonanej przez Ciebie zmianie system zacznie zachowywać się nieobliczalnie, to zastanów się, czy nie jest to spowodowane ową Twoją ingerencją; w pierwszej kolejności przywróć "ustawienia fabryczne" , I na koniec... Tak patrzę na tę klawiaturę, którą się posługuję i dostrzegam sporą ilość możliwości. Czy aby nie lepiej zamiast aliasów, czy skryptów dostępnych ogólnie, nie przypisać jakiejś kombinacji klawiszy (tak, znów trzeba sprawdzić, czy jest ona "wolna") tego, co chcesz?
875
« dnia: 2018-02-26, 08:45:50 »
Utwórz jako root np. skrypt /usr/local/bin/l z zawartością:
ustaw chmod 755 /usr/local/bin/l
i już l działa jako własne polecenie.
Nie będę polemizować co lepsze alias, czy skrypt, bo to są dywagacje nt. wyższości świąt Wielkiej Nocy nad Bożego Narodzenia, jednakże proponowane wyżej rozwiązanie jest - moim zdaniem - głupotą. Po pierwsze - wprowadza do systemu program wykonywalny (skrypt) pomijając system zarządzania programami (nie ma znaczenia tu dystrybucja). Prosimy się o kłopoty. Po drugie - wprowadza program systemowo, dostarczając go wszystkim użytkownikom, czy tego ów inny użytkownik chce, czy nie (linux niekoniecznie musi mieć jednego użytkownika; ba nawet jeśli ma, to dobrze jest niekiedy sprawdzić działanie na użytkowniku testowym, by wykluczyć możliwość wadliwego działania systemu właśnie ze względu na modyfikacje zrobione na danym koncie). Uszczęśliwiamy zatem kogoś na siłę. Po trzecie - dość łatwo w proponowany sposób nadpisać polecenie systemowe znajdujące się w /usr/local/bin (o ile tam się znajdzie; teoretycznie winny binarki iść do /usr/bin, ostatecznie do /bin, jednakże nie mogę wykluczyć, że ktoś napisze jakiś program, gdzie ta binarka pójdzie do /usr/local/bin) jakimś własnym. Pomijam już to, że wówczas system nie będzie zachowywał się tak, jak przewidzieli jego twórcy i twórcy poszczególnych aplikacji, które mogą się odwoływać do tych poleceń. Jeśli już robić skrypt, który ma służyć określonemu jedynie użytkownikowi, to wg zasady: wolnoć Tomku w swoim domku. Dla użytkownika i dokonywania zmian w zachowaniu systemu, służy wyłącznie jego katalog domowy. Współczesne systemy często w PATH mają nawet ustawione ~/bin/ (jeśli nawet nie ma, to łatwo to ustawić). I to jest właściwe miejsce wg mnie na takie skrypty. Określony użytkownik uzyskuje funkcjonalność według własnych potrzeb, ale innemu nie zmieniamy systemu. Nie powoduje żadnej ingerencji w katalogi systemowe, które w ogóle nie powinny być dla użytkownika. Dla systemu paczek jest to obojętne (ten nie ma nic do /home i tutaj niczego nie zapisuje).
876
« dnia: 2018-02-24, 07:56:21 »
Gdzie chcesz, byleby nie w "środku" czegoś, co już tam masz. Ja mam dopisane na końcu.
877
« dnia: 2018-02-23, 18:48:44 »
878
« dnia: 2018-02-19, 15:18:53 »
Utworzyliśmy i mamy nadzieję dotrwać w tym postanowieniu by tworzyć. Repozytorium (a w zasadzie kilka) dostępne jest na https://github.com/polaur. Więcej informacji: https://forum.archlinux.org.pl/viewtopic.php?id=615 (tu również aktualizowana lista dodawanych/zmienianych aplikacji) oraz http://linux-pavbaranov.blogspot.com/2018/02/polaur-pol-arch-user-repository.htmlPo zaznajomieniu się z treścią ogłoszeń (lub jednego, są bliźniaczo podobne), zapraszam do korzystania w imieniu swoim oraz pozostałej ekipy. Zasada jest dokładnie taka sama jak z AUR, a jedynie nie oferujemy żadnego "polaurhelpera" Zanim oczywiście rzucicie się do korzystania i instalowania wszystkiego co tam jest i jak leci  dwa kubły zimnej wody: 1. Proszę uważnie zwrócić uwagę na to co zawierają repozytoria repo-refreshed oraz pkg-trunk i dla kogo one są przeznaczone. 2. To jest repozytorium społeczności Archa, a to oznacza, że o ile jeszcze istnieje duże prawdopodobieństwo, że z lepszym lub gorszym skutkiem programy te będą działać także w tych dystrybucjach, które bezpośrednio korzystają z repozytoriów Archa, to już w przypadku Manjaro Stable i Testing absolutnie takiej gwarancji nie ma. Osobiście co najmniej odradzam (bo zabronić nie mogę) osobom, które mają te wersje tej dystrybucji korzystania co najmniej z dwu repozytoriów: pkg-trunk /to w ogóle/ oraz repo-refreshed /to w ostateczności i to wyłącznie wówczas, gdy wersje bazowe paczek między Manjaro a Archem się wyrównają/. Nieco lepiej będą mieć osoby korzystające z Manjaro Unstable, bowiem tutaj - teoretycznie nie powinno być większych problemów, ale trzeba pamiętać, że wersje paczek bazowych muszą być te same, co w Archu (paczki są budowane i testowane w tej dystrybucji). Z uwagi na to, że nikt z nas nie ma (co najmniej już) Manjaro, to nie jesteśmy też w stanie zapewnić jakiegoś wsparcia dla tego systemu.
879
« dnia: 2018-02-19, 11:32:45 »
Imponujące
880
« dnia: 2018-02-16, 21:32:45 »
Potrzebujesz akutalizować? 15.04 to lata temu i niektóre rzeczy są tam zdecydowanie inne niż w obecnych wersjach. Jeśli zatem możesz zdecydować się na instalację systemu od początku - zrób to zamiast aktualizacji.
881
« dnia: 2018-02-15, 19:40:56 »
@dragonite: Tak wygląda GRUBy: https://pl.wikipedia.org/wiki/GNU_GRUB. Ze względu na różne względy może przybierać lekko/mocno inny wygląd. To jest "to coś" co widzisz jako pierwsze przy bootowaniu się systemu. Jeśli nie widzisz czegoś takiego, to bodaj należy wcisnąć Shift. Zwykle masz też tu legendę jak wejść w polecenia, które są przekazywane kernelowi przy starcie. Generalnie: - ctrl+e
odnajdujesz linię... hmmm... najprościej będzie tak - tę, w której masz wpis "quiet" albo po nim, albo w miejsce jego wpisujesz "nomodeset" - ctrl+x
System winien wystartować.
882
« dnia: 2018-02-15, 15:30:29 »
O ile znam Debiana oraz pobawiłem się samym Deepin DE, to specyfiki dystrybucji Deepin nie znam. Być może znajdziesz jakiegoś użytkownika akurat jej, który lepiej Ci podpowie niż ja. Niemniej jednak wiem, że: - Deepin oparty jest o Debian Sid,
stosuje ten sam system pakietów deb,
instalacja ich odbywa się co najmniej tak jak w innych dystrybucjach opartych o Debiana, czyli z pomocą apt/dpkg i/lub jakiegoś GUI, które potrafi sobie z tym poradzić w jakimś narzędziu graficznym (osobiście nie lubiłem żadnych innych wynalazków i używałem programu synaptic).
I tu się moja wiedza kończy nt. Deepin OS. Bazując na "debianowej" i zakładając, że w Deepin jest tak samo, to masz: - w dowolny sposób (np. przez apt/apt-get) masz zainstalować sterowniki: xserver-xorg-video-ati oraz xserver-xorg-video-intel (ten ostatni masz) oraz firmware-linux-nonfree,
z reguły to nie jest konieczne, ale sugeruję - wykonać restart komputera
Niestety po restarcie prawdopodobnie uruchomi Ci się system z wykorzystaniem GPU w Intelu (ot, taka specyfika, że w notebookach zawsze jest preferencja dla stosowania energooszczędnych układów, a takim jest grafika zintegrowana). Sprawdzasz zainstalowanie obu sterowników: Jeśli wszystko jest prawidłowo zainstalowane, to dla wykorzystania sterownika ATI w bardziej konkretnych zastosowaniach, musisz jeszcze wpisać: $ xrandr --setprovideroffloadsink radeon Intel
Sprawdzasz: $ DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
W wyniku winno być AMD. Jeśli chcesz wykorzystywać ATI/AMD jako pierwszą, to trzeba zrobić taki plik konfiguracyjny jak opisane tu: https://wiki.archlinux.org/index.php/PRIME#Discrete_card_as_primary_GPU. Choć rozwiązanie jest w zasadzie uniwersalne, to przed decyzją o trwałej zmianie (chyba, że umiesz się dostać do TTY bez startującego poprawnie środowiska) poleciłbym to jeszcze sprawdzić na jakichś bliżej deepinowych forach; możesz się posługiwać forum/wiki Debiana lub Ubuntu (ostrożniej). PS1: PRIME to nie jest oprogramowanie, a technologia umożliwiająca pracę na komputerach z tzw. grafiką hybrydową, stąd w jakimś menedżerze pakietów raczej szukaj tej nazwy w opisie (nb. prawidłowo winna być pisana wielkimi literami), a nie w nazwie paczki. PS2: Niektóre notebooki umożliwiają wybór określonego GPU do pracy w BIOSie - musisz sprawdzić w dokumentacji swojego.
883
« dnia: 2018-02-15, 08:40:48 »
Twój Radeon jest obsługiwany przez dwa sterowniki: - otwarty ATI, który w Debianie nazywany jest xserver-xorg-video-ati i dostępny winien być w wersji 7.10.0
- własnościowy Catalyst
Sterowniki własnościowe dla Radeon 6400M nie są już rozwijane od blisko 3 lat. Ich instalacja jest możliwa dla xorg w wersji 1.17.x. I w tym momencie w zasadzie możesz zapomnieć o tym, że je zainstalujesz. Deepin jest oparty o Debian Unstable, xorg-server masz tu we współczesnej wersji 1.19. Oczywiście jeśli czujesz się na siłach spróbować zainstalować (skądś, bo nie wiem skąd) wersję kompatybilną z Catalyst, to możesz spróbować (być może jest też jakieś niezaleźne repozytorium z Catalyst i wówczas ma wszystkie paczki, które są razem potrzebne w systemie). Gorąco jednak odradzam zwłaszcza, że jest to de facto branie na swoje barki utrzymywania całego systemu (Catalyst nie jest obecnie wspierany w Debianie Sid, a ostatnia wersja Debiana, na której daje się go uruchomić do Debian  . Innymi słowy - rozsądek podpowiada jeden wybór - sterownik ATI. Tym łatwiej winno to przyjść z uwagi na to, że co najmniej od chwili zaangażowania się AMD w tworzenie tego sterownika jest on na prawdę dobrej jakości i nie ustępuje własnościowemu. Oprócz sterownika powinieneś mieć zainstalowany tzw. firmware, które dostępne jest w paczkach firmware-amd-graphics lub firmware-linux-nonfree (instaluj, którą chcesz, a i tak winno to być w zależnościach). Przy hybrydowej karcie musisz mieć jeszcze zainstalowany sterownik dla karty zintegrowanej, czyli intela (ale to masz i możemy pominąć). Technologia umożliwiająca obsługę obu kart nazywana jest PRIME. Niektóre dystrybucje mają jakieś "ułatwiacze" dla jej obsługi - przeszukaj swoje repozytoria/sklep, czy czegoś takiego nie widzisz. Jeśli nie, to obsługa odbywa się w taki sposób, jak masz opisane w wiki Debiana: https://wiki.debian.org/AtiHowTo#Hybrid_Graphics lub szerzej np. w bliższym mi wiki Archa: https://wiki.archlinux.org/index.php/PRIME (oczywiście nie interesuje Cię kwestia instalacji, która tu jest podana; dla Ciebie ważne, że masz mieć oba sterownik, o których pisałem wyżej zainstalowane). Pytałeś o inne dystrybucje, które mają sterownik dla Twojej karty AMD. Z przyczyn, które opisałem wyżej, wszelkie dystrybucje, które są oparte o współczesne wersje Xów, MESA itd. nie umożliwią (a przynajmniej w prosty sposób) instalacji Catalyst (bodaj najprościej rozwiązane to w Archu i Manjaro). Szczerze jednak nie polecam tego sterownika, bo robi on po prostu sporo kłopotów, zwłaszcza początkującym, zwłaszcza że często jest to "gwałceniem" systemu i ze względu, że nic/niewiele lepiej a niekiedy gorzej będziesz miał w stosunku do sterownika ATI. Sterowniki otwarte są dostępne w każdej dystrybucji. Jeśli jednak chciałbyś znaleźć jakąś dystrybucję, która obsługuje Catalyst, to szukaj pośród takich, gdzie xorg-server jest w wersji co najwyżej 1.17.
|
Pokaż wiadomości