- Milyen egeret válasszak?
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Samsung LCD és LED TV-k
- AMD Ryzen 9 / 7 / 5 10***(X) "Zen 6" (AM5)
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Projektor topic
- Na, milyen hardver kerül a fa alá?
- Egér probléma
- Szünetmentes tápegységek (UPS)
- Milyen billentyűzetet vegyek?
-
PROHARDVER!
Arch Linux topik
Új hozzászólás Aktív témák
-
Shyciii
veterán
Eszemágában sem volt az xmonad-ot kipróbálni. Pont a Haskell miatt. Csak az xmobar-t konfigoltam volna be, mint a polybar-t. Az még nem lett volna vészes, de így hogy ennyi csomaggal operál...Így már nem érdekel az összehasonlítás, hogy mennyi erőforrást ehet.
Amúgy a chmod-chown témára visszatérve nekem van egy a winyón egy sda3-as partíció, amit felmountoltam a /home/Data alá, és muszáj volt chmod 744-et használnom a 644 helyett, mert a vifm az sxhkd-s billentyűparancsra nem akart megnyílni. Egész pontosan a super + enter- re van beállítva, ami kiadja az st -e vifm /home/Data /home/Data parancsot. De ez csak akkor fut le, ha 744-esre vannak beállítva a jogok. 644 esetén csak egy villanás van, és semmi nem történik. Az érdekesség, hogy ha a konzolban adom ki az st -e vifm /home/Data /home/Data parancsot, akkor rendben megjelenik. Pedig a bsowm+sxhkd configja ugye a /home/shyciii alatt van, valahogy mégis gondja van. -
attilav2
őstag
#7873 jimmy399
Én is szívok, új arch telepítésnél - akár a hivatalos módon kézzel, akár calamarch-al telepítem - a vlc nem képes megnyitni a dvb streamet(se T-t se C-t) a tbs tuner driver(tbsecp3-driver-git-dkms) jól van feltéve mert az mpv megnyitja a streamet. A régi telepítésemen minden további nélkül a vlc is meg tudja nyitni a dvb streamet. Valamit megint variáltak... -
Frawly
veterán
válasz
jimmy399
#7894
üzenetére
Azért azt megnézném, hogy a kernel melyik drivert használja. lsmod parancs kilistázza, esetleg felrakod az inxi-t és futtatsz egy inxi -Fxxx parancsot. Mert az egy dolgok, hogy feltetted az ati X.org drivert, de annak nem lesz hatása, ha a kernel továbbra is az amdgpu-t használja.
-
-
Frawly
veterán
válasz
jimmy399
#7883
üzenetére
Az amdgpu nem tudja az HD5xxx-eket meghajtani. A 7xxx-eket már meg tudja. De a 7xxx-et még meg tudja hajtani a radeon/ati driver is. Alapvetően, ha egy GPU támogatja mindkettőt, akkor az amdgpu-t érdemes vele használni, hiszen az újabb, többet fejlesztik, gyakrabban kap javításokat, optimalizációkat, stb..
#7884 csixy: nem muszáj két gép, egyen feltelepíted, mellette egy okostelefonon, táblagépen, akármin is tudod olvasgatni az Arch Wiki-t. Vagy először virtuális gépben gyakorlod ki a telepítést, és a host gépen nézed hozzá háttérben a böngészőben az Arch Wiki telepítési útmutatóját, és mikor már megy a telepítés, utána csinálod fizikai gépen.
Haladók meg úgy szokták, hogy bebootolják az Arch telepítőt, azon a háttérben nyitnak egy új text konzolt (Alt+F2), és abban szöveges lynx, elinks, elinks2 vagy hasonló böngészővel olvasgatják a Wiki-t, így is csak 1 gép kell hozzá, és váltogatnak az 1-es és 2-es konzolok között. Én mindjárt egy harmadikat is nyitok, amiben bizonyos parancsok kimeneteit őrizgetem, az 1-es konzolban meg a telepítést csinálom, 2-esben text böngésző megy. De csak akkor, ha valami olyan telepítési momentum fordul elő, amit még nem csináltam, számomra újdonság, és a telepítésnek egy olyan fázisában van rá szükség, amikor még nincs grafikus felületem. Ha ugyanis a telepítésnek már egy olyan fázisában van rá szükség, amikor van grafikus felület már, akkor simán a háttérben futó grafikus böngészőben is lehet nézni, míg a parancsokat terminálba vereted be.
Sokféleképp meg lehet oldani két gép nélkül. De én mégis amondó vagyok, hogy Archnak akkor állj neki, ha van 2 géped minimum, vagy 1 gép, de azon egy tartalék drive-on egy pót OS. Arra az esetre, ha elcsesznéd a telepítést, nem működne, akkor ne maradj használható gép nélkül. Már pedig eleinte el fogsz tolni dolgokat, de pont ez e lényege, hogy tanulási folyamat. Bár xfce-t pl. könnyű feltelepíteni, mert ott újraindítás és felhasználólétrehozás után csak felteszed pacmannal az xfce metacsomagot, és az behúz automatikusan minden szükséges függőséget, drivert, panelt, értesítőt, addonokat, gtk-s bizbaszokat, alap text editort, terminált, stb-stb.. Az Arch akkor nehezebb, ha minimalista WM van csak rajta, mert akkor neked kell mindenről kézzel gondoskodni, mindenféle driver, alkalmazás, kézi telepítése, hozzájuk egyenként kézzel .conf fájlok szerkesztgetése.
-
Frawly
veterán
válasz
Shyciii
#7891
üzenetére
Nekem nem is ez a bajon az xmonad-dal meg xmobar-ral. Persze ez is baj vele, hogy komplett Haskell toolchain kell hozzá, meg állandóan újrafordítgatni kódból, ráadásul a Haskell csomagok elég nagyok is, nem csak az a gond, hogy 117 csomag, de vannak közöttük ilyen 100+ mega felettiek, igaz ezek nem mind a futtatáshoz kellenek, csak a kódfordításhoz. Hanem hogy ebben a megérthetetlen funkcionális programozásos Haskell-ben van megírva, ami felfoghatatlan, meg agyrém. Ezeknél még a dwm is jobb, mert igaz, hogy forráskódból forgatós az is, de legalább hagyományos, sztenderd C, rövid forráskód, nincs függőség, stb..
Ez az xmondat, xmobar azoknak mennyország, akik eleve Haskell-ben fejlesztenek, jól ismerik, és az egész ökoszisztémájukat eköré akarják építeni. Mindenki másnak nagyon nem ajánlom. Neked különösen nem, mert a bspwm szerintem sokkal haladóbb, minimalistább, rugalmasabb az xm-akármi-haskelles megoldásoknál.
Kolléga helyében az amdgpu modult feketelistára tenném a /etc/modprobe.d/akarmi.conf fájlba a blacklist amdgpu sor hozzáadásával.
A TRIM-ről meg kiderült, hogy NTFS, úgyhogy ott az ntfs tools csomagosokat kell csesztetni, nem a kernel tehet róla.
Bár azért annyiból megértem a kollégát, hogy Archon nem lenne szabad előfordulnia, hogy egy új kernel miatt ennyire eltörik valami. Akármilyen új is. Bár azt várjuk még ki, hogy mire jut a radeon és xf86-video-ati driverekkel, hátha az megoldja neki.
-
Shyciii
veterán
Ondoltam kipróbálom az xmobar-t a polybar helyett, hogy mennyi erőforrást foglal el, erre installáláskor kiírja, hogy 117 csomagot rakna fel összesen. No, akkor már nem is érdekel az xmobar

-
Shyciii
veterán
Akinek gondjai vannak. Ugye most jött ki tegnap az új kernel. Nyilván előfordurdulhatnak problémák, hisz szinte rögötn megkapjuk. Amúgy meg ma újabb 5.11-es kernel jött ki, szal valszeg javították is ezeket a hibákat. Szal kernel frissítésekkel óvatosan ha "olyan" hardvered van.
-
#63718632
törölt tag
Azt a mankót leírhatod egy papírra is. Kell vagy 5-6 parancs amit a telepítőből csinálsz. Aztán reboot után mégint 5-6 parancs, hogy legyen GUI-d is. Csakk saccoltam a parancsok számát, meg csak a legfontosabbakat vettem számba.
Amúgy is érdemes követni az install wiki oldalt, mert lehetnek változások. Nem kell bemagolni és fejből tolni. -
jimmy399
senior tag
válasz
jimmy399
#7883
üzenetére
Nos, kipróbáltam a másik driverrel. Ha nem frissítem a kernelt akor jó. Ha frissítem, akkor kifagy az egész gép.
SSH-n telefonon keresztül léptem be, és megnéztem mi történik.BUG: kernel NULL pointer dereference, address: 0000000000000000008
#PF: supervisor read access in kernel mode
xPF: error_code(0x0000) - not-present pageDe felteszem a screenshotot is.
-
és Lck
Köszönöm , megoldódott.
Telepítenék én simán arch-ot is, csak az a gondom vele, hogy egyszerre kettő gép kell hozzá. Merugye az egyikre mahinálom a fogamat szíva, meg fohászkodva a telepítést, s a másikon meg internetkapcsolattal nézem és olvasgatom a mankófájlt, hogy hogyan kell csinálni, mit mikor kell tenni. Ráadásul az egyik gépről a másikra nem lehet copy-pastézni. -
jimmy399
senior tag
Pedig elég lett volna ha egyszer megnyomja a kikapcsoló gombot, és rendesen leállt volna.
Konzolos bejelentkezést használtam akkor, látta, hogy fut valami. No, de mindegy is már.Rápróbálok az xf86-video-ati-ra és úgy is megnézem, hogy fagy-e az egész rendszer, köszi a tippet, csak én is, amikor néztem a drivereket, akkor az amdgpu-ra esett a választásom.
-
Frawly
veterán
Én is erre tippeltem, így legyen ötösöm a lottón. Azt nem értem miért teszik be. Gondolom aki az installer scriptet csinálta, az a saját rendszerén tiltja ennek a csomagnak frissítését saját szakállra, mert valami problémát okozott nála, és a telepítő létrehozásánál elfelejtette kivenni, benne maradt. Csak erre tudok gondolni.
De mint írtam, nem csak konkrétan ez a baj a 3d party install scriptekkel, hanem hogy egy csomó ilyen más lépést is meghúznak, amiről nem érti az ember, hogy miért, meg nem is tud róla, és csak ilyen hibákba ütközésnél veszi észre. Meg feltelepítenek olyan dolgokat is, ami az embernek nem biztosan kell. Ezért kétkedek mindig, mikor ilyen n+1. installert kezd el dicsérni valaki, hogy milyen kafa. Általában minél inkább kacsalábon forog, minél kulcsrakészebb, annál inkább gányolás van mögötte.
Itt múltkor is volt valami kolléga, aki vagy Manjaro-n, vagy valami custom Arch installernél belefutott abba, hogy a felhasználója tagja volt valami olyan csoportnak, amit nem értett, vagy users-ben volt, már nem emlékszem. Ott is az okozta a gondot, hogy az installer saját szakállra old meg dolgokat. Ahogy pl. az említett, UEFI bootnál MBR-es lemezre települni képtelenséget, meg egyes gépeken a Windows EFI-jére fixen bedrótozott fájlnevet se tudják orvosolni az installscriptek, grafikus telepítők, így meg nem működik az UEFI boot.
De ez nem csak Arch specifikus, Ubuntu, stb. vonalon is így van. Ezt nem értette múltkor ubyegon a kedvenc Mintjén, hogy annak a default települő 2000+ csomagnak és beállításnak a jó része igazából nem kell neki, de ő meg van győződve, hogy valamire kell. Hiába magyaráztam neki, hogy átlagos Arch install 1000 csomag körül/alatt szokott lenni, matekozza ki. De ő erősködött, hogy ami nem kell neki, azt átállítja, leszedi, de nem veszi észre, hogy mire leszed ~1000 csomagot, ugyannyi munkával feltehetett volna ő is egy 1000 csomagos Archot, amiről semmit nem kéne leszedjen. Nem mindig az a könnyű és felhasználóbarát, ami először annak látszik.
Pontosan ezért nincs az Archnak telepítője, nem akarja kitalálni a felhasználó helyett, hogy milyen partíciókat, bootmódot, bootloader, grafikus felületet, stb. akar, nem akarja kitalálni, hogy milyen csomagra van szüksége. És nem csak a kezdőknek készült disztrók hibáznak ebben, hanem még az olyan minimalisták is, mint a Void, annak a telepítője is rontott el dolgokat, meg feltételezte, hogy GRUB az kell, mikor nem feltétlenül, stb.. Pedig a Void az már haladó disztró.
Az Archnak nagyon igaza van ebben a KISS elvben, hogy semmit nem szabad a felhasználónak leegyszerűsíteni, működésileg elfedni absztrakciókkal, mert az nem egyszerűvé, hanem bizonyos foktól bonyolultabbá, rugalmatlanabbá teszi a dolgokat. Ez nem csak Linuxnál van így, de pl. HTML szerkesztőknél, plain TeX vs. LaTeX viszonylatában, stb.. Ez egy általános jelenség.
-
Frawly
veterán
válasz
jimmy399
#7879
üzenetére
Gondolom a szervizes nőci csak nem tudta hol kell kikapcsolni, újraindítani Openboxnál, nem ismerte a Linuxot, a kikapcsológomb sem minden gépen kapcsol ki, van, ahol sleepbe, hibernációba küld le. Ő meg ki akarta nyomni a rendszert teljesen, hogy legközelebb újrabootoljon, és nem akart inkompetensnek tűnni, hogy a kikapcsolást keresi. Csak tipp.
A HD5550-öt ellenőrizve viszont arra jutottam, hogy azt a radeon drivernek kéne hajtania, szintén kernelből, és ahhoz nem az xf86-video-amdgpu Xorg 2D driver kell, hanem az xf86-video-ati. Ez egy olyan régi GPU, amit nem támogat az amdgpu driver.
A HD7560D-t meghajtja a radeon és xf86-video-ati driver épp úgy, de ahhoz már az amdgpu és xf86-video-amdgpu ajánlott inkább.
-
jimmy399
senior tag
Lehet, hogy durva, de régebben az amd.iommu-val voltak gondok, hogy ki kellett kapcsolni kernel paraméterben, hogy használja a rendszer.
Itt egy régebbi Trinity GPU van, ráadásul egy Hd 5550-el, ami külön PCI-express slotban van. 4 évig pihent, újrapasztázás megvolt mind a GPU , mint a CPU oldalon. Én is konzolon jelentkezek be .xinitrc xfce4-session indítással. Egyelőre marad az 5.10-es kernel bónusz nehetízéssel virtualbox-al, dkms-el. Remélem javítva lesz.Viszont elmentem egy pc-szervízbe. Akkor laptopot használtam, Hp 2530p-t. Arch-al, konzolos belépéssel indított openbox-al. A csaj, simán kikapcsolta a power gomb hosszú nyomásával, ahelyett hogy egyszer nyomta volna meg röviden és kikpacsolt volna... Durva, hogy akkor meg most is nem ismerik a GNU/Lunix rendszert.
-
Frawly
veterán
Örülök, hogy megoldódott. Sajnos itt jön elő, amiről mindig szónokolni szoktam, hogy angolul használva a rendszert több találatot adna a kereső. Erre a magyar csomagfrissítés kihagyására hoz a Google 4 találatot, abból az egyik MAME emulátorban Pac-Man játékról szól, a másik háromból meg nem derül ki semmi. Az angol nyelvű hibaüzenetre előjött volna min. 100-500 találat.
A másik, az az Arch-installscriptek kiszámítóhatatlansága, azok is tudnak ilyen random config fájlban benne hagyni spéci sorokat, amiket te Arch WIki alapján történő szabályos installal nem tennél. Ezért mondtam, hogy nem mindig megbízhatóak ezek, a telepítést leegyszerűsítik, de nem látod át, hogy mit és miért csinál a háttérben, azok neked tényleg szükségesek-e.
-
Frawly
veterán
válasz
jimmy399
#7873
üzenetére
Ez durván hangzik, hogy ennyire semmi nem megy, de még LTS-sel is gondod van. Pedig az 5.11-es kernelbe pont hogy AMD procikhoz érkezett javítás.
Én Ryzen 4700U-t használok, amiben Vega8 integrált GPU van. Nálam csak annyit okozott az 5.11-es kernel, hogy minden bootkor kiírja, hogy amdgpu: Unsupported power profile mode 0 on RENOIR. Semmilyen hibát nem okoz, csak idegesítő, mivel konzolon jelentkezek be, és általában épp gépelek bejelentkezés közben, mikor odaokádja ezt a sort. Ezt a kellemetlenséget leszámítva minden működik, CPU, GPU fronton is. Igaz nekem az 5.10.x-szel sem volt problémám, akkor nem írt ki semmit, CPU rendesen szabályozta a frekit azzal is. TRIM-mel sincs gondom, igaz én ext4-et használok az SSD-n.
Drivereket jókat használsz, kernel amdgpu KMS driver (alapból a kernelben van), mesa (OpenGL 3D-s gyorsítsához), xf86-amdgpu-video (2D-s X.org gyorsításhoz), vulkan-radeon, ezeket kell használni, ezeket is használod szerintem.
-
_Dumber_
őstag
Downgradeld az egészet egy régebbi napra.
https://www.rdeeson.com/weblog/176/how-to-rollback-a-system-update-on-arch-linuxEgy hét múlva próbáld újra.
A KDE 5.21 alatt nekem a xfreerdp nem ment multimonitoron. Dolgozni kellett, időm meg nem volt játszadoznom..
-
jimmy399
senior tag
Remek faszaság tört a rendszerre rendszerfrissítés után.
kernel 5.10.11-arch1-1 -ről frissítve 5.11.2.arch1-1-re teljes rendszerfagyás amikor a másodlagos monitort bekapcsolom.
Downgradeltem az xf86-video-amdgpu-t 19.1.0-2 -ről egyel korábbi verzióra. -> fagyás
Downgradeltem a kernelt 5.11.2.arch1-1 ről linux-lts-5.10.19-1 -re ment minden simán DE a cpu minimum frekvencián üzemelt, szaggatott minden. Mondom Remek.

Powercpu-val cpu-frequency-scanling gonvernort váltva sem történt semmi, mert minimum frekvencián maradt a cpu.
Fasza.
Feltettem vissza az 5.10.11-arch1-1-et minden ok.
Pacman.conf ignorepkg linux, linux-headers... Ja mellesleg a pulseeffects se megy a legutolsó friss verzióval, mert azonnal crash-sel...
Eddig nem volt ilyen gondom, hogy vissza kell tartsak csomagokat, mert a frissítéssel fagy a gép, meg nem indulnak a programok.Alaplap:
Asrock Fm2-A75 Pro4-m
Amd A8-5600K cpu
12 GB ram
VGA:
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7560D]
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Redwood LE [Radeon HD 5550/5570/5630/6390/6490/7570]Azt értem, hogy a két VGA nem a csúcs, meg lehet másik driver kellene, de az 5550-es csak azzal a driverrel megy, amit az arch linux ati oldal emleget, mert legacy, bár a 7560D is benne van a korban.
boot: UEFI
Elsődleges vga az integrált 7560D mert csak ez tud UEFI GOP-ot, a HD 5550 nem. Mindkét monitor D-SUB-os. (2 x 19" 1440 x 900)

-
Ez mi miatt van, hogy nem frissíti a pacman ezt?
"figyelmeztetés: archlinux-appstream-data: csomagfrissítés kihagyása (20210125-1 => 20210218-1) " -
Frawly
veterán
Mert érdemes a legszűkebb jogosultságokat kiosztani, azokat, amik épp hogy elegendőek. Persze a 755-tel sincs semmi baj. A lényeg, hogy ne 777, mert az egyes esetekben túlzás lehet. Persze nem a világ vége. Kivéve rekurzívan. Nyilván mindenkinek a saját rendszere a saját vára, olyan jogosultságokat oszt a fájlrendszeren, amit akar. Amiket én írtam, az csak ajánlás (chmod helyett chown, chmod XXX helyett u/g/o+r/w/x), meg default (644, helyesen valóban 755).
Épp ilyen ajánlás szokott lenni, hogy sudo/doas esetén nem engedni kell az összes futtatási jogot és onnan fekete listázni, hanem fordítva, mindent tiltani (alapból így van), és csak fehér listás alapon megengedni ezt-azt, főleg, ha jelszó nélküli futtatásról van szó.
Sőt, tovább megyek, az Arch Wiki még a chown-t se ajánlja a chmod helyett, mármint felcsatolt fájlrendszeren, helyette a mountolásnál ajánlja az umask megfelelő beállítását, ami pl. nekem sem áll kézre, sose tudom a maskértékeket fejből meghatározni, meg megjegyezni a számokat, pedig ez a legajánlhatóbb, ilyenkor tulajdonba vétellel sem kell szórakozni.
-
vargalex
félisten
Azt azért megnézem, hogy hogy tudod 3 számjegyes formátumra váltani, hogy a jelenlegi jogosultságtól függetlenül pl. mindenkinek adj futtattási jogot. De itt én is írhatnék bármilyen példát, a lényeg azon van, hogy a jelenlegi jogosultságtól függetlenül valamivel kiegészíteni, vagy valamit elvenni.
-
Frawly
veterán
válasz
stranger28
#7864
üzenetére
Félig érted jól. Az oktális formátum rekurzív kiadásával van gondom. Ezen kívül a 777 nem rekurzív kiadásával is, de csak akkor, ha megszokásból megy, és nincs mögötte valós indok, hogy ne chmod +x vagy akármi legyen. Mert pont ez a baj vele, hogy nagyon sok ember csak a chmod 777-ről olvasott, és már csak gondolkozás nélkül, rutinból csapatja. Működni valóban működik, mert 777-tel hozzá fogsz férni olyan fájlokhoz és mappákhoz, amikhez eddig nem, de egy csomó negatív következménye lehet.
De nyugodtan mondjatok példát, mikor a 777 ajánlott, főleg rekurzívan, egy chown helyett.
-
Frawly
veterán
Nem, nem amikor kedved van. A chmod +x vagy +akármi, u+akármi, stb. sokkal kulturáltabb, mert nem kell ellenőrizni, hogy mik most a jogosultságot, meg miért azok. Mondom, itt ráadásul a rekurzív kiadásról volt szó. Egy-egy fájlnál én is el tudom képzelni a chmod 777-et, ha olyan fájlról van szó, amit mindenkinek kell tudnia futtatni, és nem érdekel, hogy most mik a jogosultságai. De rekurzívan mindenképp ellenjavallott. Ha ingerenciád támad rá rekurzívan, gondold át jobban.
De nem kell nekem hinni, adj ki chmod 777 -R parancsot egy egész fájlrendszerre és nézd meg mit fognak hozzá szólni a programok. A saját szemeddel kell lásd, hogy mi a baj vele, mert ennél érthetőbben nem tudom elmagyarázni.
Apt-get ügyében utánanéztem, és megváltozott az álláspont. Vagyis nem teljesen tévedtem, csak nem deprecated, mégis sok oldal az apt-ot ajánlja helyette, függőségkezelés miatt. Részletek itt.
Persze, nem álmodtam, mert régen tényleg volt róla szó, pár éve, hogy ki fogják vezetni, de ezek szerint meggondolták magukat, ennek ellenére viszont továbbra is az apt az ajánlott.
Olyasmi, mint az ifconfig a net-tools csomagból, a évek óta deprecated, az ip parancsot kéne használni helyette, de mégis tovább használják az emberek. Ráadásul az ifconfig olyan, ami nekem is jobban kézreáll, de igyekszek helyette az ip-t használni, sajnos annak elég hülye kapcsolói vannak.
-
Lenry
félisten
a 777 csak egy példa volt. írhattam volna 666-ot vagy 400-at vagy 644-et is. faxmindegy
Ez a chmod 3+ számjegy akkor kell...
... amikor épp olyan kedved van hogy ezt akarod használni. mint írtam, oda-visszaváltható az oktális formátum a betűs változattal. egyik sem jobb mint a másik, mert pontosan ugyanarra valók és pontosan ugyanazt lehet megvalósítani velük. egyik sem tud olyat, amit a másik nem.Az apt-get már évek óta deprecated, helyette az apt ajánlott.
erről most hallok először. linkelj már pls erről valamit. kösz. -
Frawly
veterán
De, gányolás, mert a legritkább esetben van csak rá szükség, hogy mindenkinek, minden jogot megadj futtatást is beleszámítva. Plusz ez a chmod 777, mint írtam, minden fájlnak futatható jogot ad, egy sima plain text, kép fájlnak is, ami fájlkezelőknél zavart szokott okozni! De, igen, gányolás.
Ez a chmod 3+ számjegy akkor kell, ha valami olyan fájlrendszert kell rendbe tenni, ami korábban egy chmod 3+ számjegyes laikus már szétbarmolt olyan szintre, hogy használhatatlan, és kézzel kell az összes fájl, összes mappa, összes jogosultságát mindenki irányában rendbe tenni.
Egyébként meg normál fájlokra a 644 ajánlott, futtathatókra 744 vagy ritkábban 774. A 777 csak a legritkább esetekre fenntartandó, és mint legritkábbakra, nagy melegen nem javallott rekurzívan, több mappára kiadni.
Legtöbbször, mikor ezt a 777-et laikusok kiadják, valójában csak fájlokhoz szeretnének hozzáférni, és az esetek 99,9999%-ban ezen segít egy chown -R is. A 777 használata olyan, hogy be akarsz menni egy épületbe, de ahelyett, hogy az ajtót nyitnád ki, betöröd, és az összes ablakot is kitöröd mellé, hogy mindennek, és mindenkinek szabad ki/bejárása legyen, minden nyíláson, ha kell, ha nem.
Apt-get-tel alapvetően nem lenne baj, ha évek óta nem az apt lenne helyette ajánlva. Az apt-get már évek óta deprecated, helyette az apt ajánlott. Igaz még egy ideig az apt-get is menni fog, de érdemes leszokni róla, mert egy ponton túl majd nem fog működni és el lesz távolítva a Deb/Ubuntu-alapú rendszerekről. Egyszerűen csak szép fokmérője az időbeli elmaradottságnak, ha valaki még apt-get-et emleget, példázza, hogy elfelejtett tájékozódni, meg haladni a korral.
-
Lenry
félisten
Ez a három számjegyes gányolás még...
az égvilágon semmi gányolás nincs benne, csak ésszel kell használni. mint mindent.
egychmod 777pont ugyanazt csinálja, mintha azt mondanám neki, hogychmod ugo+rwx, csak rövidebb leírni. ne csináljunk úgy, mintha nem tökéletesen ugyanannak a funkciónak két külön szintaxisáról lenne szó, amik egy az egyben válthatók oda-vissza.Ugyanezen anyagok szokták írni az apt-get használatát
már mi bajod van még az apt-gettel is? -
Frawly
veterán
Nyilván ez ízlés kérdése, meg hogy ki mit szokott meg. De hosszú távon a világos téma rontja a szemet, értve ez alatt, ha napi 8+ órában gépezel. Sötét témán itt most nem azt értem, amit sokan, hogy koromfekete, meg sötétszürke, van mindenféle, pl. a Bespin-színtéma kávébarna, vagy a solarized dark középsötét tengerkék (nem a kedvencem,de népszerű), stb. A lényeg, hogy ne ilyen szemheggesztő fehér, citromsárga, rikító világoskék legyen. Már egy ilyen melegebb pasztellszín, világosbarna, papírszín is előrelépés, mint ami itt a prohardver.hu-n is van. Tehát világos témából is vannak kulturáltabbak.
De ez a fehér-világosszürke, ami Xfce-n van, ez a legrosszabb, unalmas, és rohadt világos, szemégető. Már vagy 31 éve minden OS-t ezt használja, szürke-kék ablakok, fehér háttérrel, sárga ikonokkal, fekete betűkkel, egyszerűen már halálunalom.
De mint mondtam, Xfce-éknek elnézem, mert mindig is ízlésficamosak voltak. A Mint Cinnamon/Mate alap témája is világosabb, de legalább fokokkal kulturáltabban és kevésbé unalmasan néz ki.
Persze a sötét téma sem mindig szép, ehhez is kell ízlés. Pl. sok KDE-s disztró default sötét témája elég gusztustalan, undormány sötétszürke, ilyen buzilila-kékes-cserepes, flat témás háttérrel, egyszerűen hányás az egész. Pedig sötét, nyilván az az előnye megvan, hogy a szemet kíméli legalább, de akkor is ízléstelen.
-
Frawly
veterán
válasz
attilav2
#7857
üzenetére
Igen, pont ez a baj ezekkel a rendszerekkel, hogy kulcsra készek, és ha neked másfajta kulcsra készség kell, akkor szedhetsz le egy csomó mindent, meg rakhatsz fel, és nem lettél sokkal előrébb a normál, kézi Arch telepítéshez képest.
Igazából az Archot nem nehéz feltenni, ezt a többieknek írom, nem neked. Tényleg csak pár kulcs parancs, a többi, amit az Arch Wiki ír, az alternatív módon is megoldható, pl. particionálásra akármilyen program, rendszer használható, még Archnak sem kell lennie. Meg az Arch Wikiben egy csomó lépés opcionális, pl. hardveres óra állítása, ez nekem sok év alatt csak egy szem gépen kellett (és ez sem fog kelleni újratelepítéskor). Szóval egy csomó lépés át is ugorható, kiváltképp, ha mondjuk Arch reinstall van, mert akkor újraparticionálni nem kell, bootmegoldást ha okos az ember, nem kell újratelepíteni (kivéve GRUB, de azért írom, hogy okos), fstab-ot újra lehet hasznosítani, stb-stb., így még jobban leegyszerűsödik.
Persze annyira ezeknek a third party Arch installereknek sem vagyok ellene, mert ugyan így az Archnak az egyik lényege veszik oda, de mégis inkább ez, mint hogy a jóember Ubuntut meg többi szemetet tegyen fel, ezek legalább tényleg Arch alapúak, Arch tárolóból dolgoznak, elérhető az AUR, stb-stb..
-
attilav2
őstag
válasz
Laszlo733
#7613
üzenetére
Kipróbáltam a calamarch-ot, bár fel tudom telepíteni az arch-ot a hivatalos módon, nem vagyok annyira láma
, kíváncsi voltam mennyire használható ez a telepítő. Nos azt kell mondjam használható, szinte kulcsra kész rendszert ad. Azt leszámítva hogy nálam a telepítő nem tudta létrehozni a partíciókat, mbr kiosztás volt a céllemezen, én meg uefi módban telepítettem, talán ez lehetett a gond, ebbe még a win10 telepítőnek is beletörhet a bicskája. cfdisk -z /dev/céleszköz módon megoldottam a partícionálást gpt-re, ezután a grafikus telepítő partícionáló részében már csak fájl rendszereket és csatolási pontokat választottam ki a cfdiskben létrehozott partíciókhoz, majd szépen felkúszott a rendszer. Alaprendszert, amd drivereket és xfce4-et telepítettem. Probléma mentesen indult az új rendszer, csak az amdgpu drivert finomhangoltam az arch Wiki alapján hogy ne legyen tearing. -
Frawly
veterán
válasz
Archttila
#7855
üzenetére
Bölcsen tetted. A 775 és 777 a kétes biztonságon kívül azért sem jó, mert az összes fájlt futtathatónak jelöli, ezért pár fájlkezelőben, mikor meg akarod nyitni az alapértelmezett alkalmazással (pl. egy szöveges dokumentumot, képet, filmet, zenét), akkor helyette megpróbálja binárisként vagy scriptként futtatni, és kiírja, hogy hibás. Ez nekem sok bosszúságot okozott, régi NTFS-es mentéseim még nekem is chmod 775-tel lettek Linuxra átmentve (mikor Windowsról tértem át 7+ éve), és egy darabig megszivatott (Double Commander, mc, Vifm is), mire átállítottam a a legtöbb adatfájlnál szokásos 644-re (simán olvasható fájlok, tulajdonosnak írható is, de nem futtatható).
Ezért mindenkinek szoktam javasolni, hogy ilyen háromjegyű numerikus formára ne adja ki a chmod parancsot. Elsősorban chown-nal kell helyettesíteni, ha mégis a tulajdonos/csoport körén belül jogosultságot kell változtatni, pl. utólag futtathatónak kell jelölni, mert valami bináris vagy script, akkor a chmod +x formában kell kiadni (esetleg a plusz jel elé ugoa betűk valamelyikét írni), és nem 775, meg 777, stb..
Ez a három számjegyes gányolás még régi könyvek, meg régi, kezdőknek szánt netes leírások alapján terjedt el, és elég sok emberbe berögzült sajnos, eleinte belém is. Hála istennek, ezt ma már egyik oldalon sem ajánlják, de régi anyagokban sajnos benne maradt, és a kereső felhozhatja. Olyan régi anyagokról van szó, amik főleg még systemd előttiek, meg xfree86-os korszakból valók, magyarán tényleg dinoszaurusz korabeliek, ilyen Ubuntu 14.04 és előtte való időkből. Ugyanezen anyagok szokták írni az apt-get használatát, meg a gksu, és hasonlók bemutatását. De SSD-knél is van ilyen, az SSD-k őskorában, 2008-10 között sok cikk született, hogy mindenféle kímélő beállítást és cselpraktikát kell alkalmazni, hogy csökkentsük az írások számát, és utóbb kiderült, hogy ez teljesen felesleges átlag felhasználásnál, de az SSD-s topikba is mai napig esnek be emberek, akik régi cikkben olvasták még ezeket a baromságokat. Állandóan le kell nekik írni, hogy ez elavult infó, de mivel a kereső felhozza a mai napig, dátumot meg nem nézik az emberek, így a mai napig tévhitek keringenek miatta.
-
Frawly
veterán
válasz
Archttila
#7851
üzenetére
A dbus-t teljesen tiltani nem lehet, mert egy-két dolog használja, böngészők, Wine, Steam, stb.. De elvileg annyira ki lehet patkolni, hogy default a rendszerrel ne induljon el, csak olyan progival, ami tényleg használja is.
Ennek az spi-nek meg még nem volt türelmem utána nézni hogy mi a rák, hogy lehet kiirtani, minek kell. Elvileg ennek is a dbus-hoz van köze, egyfajta interprocess kommunikációt nyújt állítólag, mármint nekem ez jött le egy gyors, felszínes utánaolvasásból.
A másik, ami minimialista rendszerre nemkell, az a kompozitor, meg a polkit. A polkit arra való, hogy grafikus felületen root joggal futtasson valaki grafikusok programot. Mióta a kdesu, gksudo, stb. megszűnt, azóta ez a polkit való rá, de meg lehet nélküle lenni, néhány WM/DE viszont automatán indítja.
-
Archttila
veterán
chmod -R esetén hogy tudok folder(eke)t kizárni?
-
Frawly
veterán
válasz
Shyciii
#7849
üzenetére
Alapból elég ronda, de át lehet témázni normálista, rendes Gtk-téma, jobb panel, normális háttérkép, azért ki lehet belőle faragni jót. Ez az egérszürke, kerekített, paktányemblémás téma szerintem is gáz, azt nyilván nem érdemes default-on hagyni. Ízlésük sose volt az Xfce-seknek, ezt meg kell nekik bocsátani. Védelmükre legyen mondva, hogy próbálnak valami egyedivel előrukkolni, csak az esztétikai érzékük nincs meg hozzá szegénykéknek.
Nálam vágólapkezelésre clipmenud megy. Notification nincs, mert csak nincs rá egyszerűen szükségem, felcsatolásnál sem. Asztali ikonok nem keveset tudnak fogyasztani sajnos, ezt már régen tapasztaltam.
Az Xfce még a Gtk2-es időkben volt sovány, mióta áttértek Gtk3-re, és bevezettek új feature-öket, azóta már inkább a nehezebb súlycsoportban indul, mint a könnyebben. Ugyanez igaz az LXDE-t váltó LXQt-re is. Épp ezért, régen gyenge gépre még javasoltunk Xubuntut meg Lubuntut, ma már ezeket meg sem említem, mikor valaki régi/gyenge gépre keres disztrót. Lassan már az MX is határeset.
-
Shyciii
veterán
Én bekonfigoltam vágólap-kezelést, és notifications is van, igaz csak eszköz csatlakozáshoz és leválasztáshoz használom, és mégis milyen keveset eszik a rendszer. Ezek nem tételek. Az asztali ikonok kirakásának lehetősége is minimálus fogyasztású. Xfce alatt meg a compositort anno is kikapcsoltam, mert minden animáció idegesít, és még így is hatalmas lépés volt az Openbox-ra váltás fogyasztás terén. Rég volt már az, mikor az xfce tényleg keveset fogyasztott... És akkor itt van még az, hogy borzalmas randa 😄
-
Frawly
veterán
válasz
Shyciii
#7846
üzenetére
Nyilván az Openbox kevesebb lesz, de nem annyival, mint gondolnád. Az Xfce is Openbox alapú, ha Openboxon használsz kompozitort, dokkot, témát, akkor majdnem ugyanott vagy, ezeket ráadásul Xfce-n is ki lehet kapcsolni. Szerintem az 1330 reális, úgy, hogy Gparted meg 2 füles Firefox is megy. Nem kevés, de nem az az agyam eldobom szint.
Alapból nekem is 700-1000 MB-ot eszik a dwm/SwayWM, Firefox fut sok füllel, meg pár terminálablak. Gpartedet nem használok, sose szerettem, nem csak azért, mert GUI-s, hanem lassú, lassan particionál, szeret bugzani, stb.. A böngésző meg minden platformon bloat sajnos, azt nem lehet megúszni.
Meg ahogy írod, ilyen minimalista rendszernél se dokk, se asztali ikonok, se értesítés, se központi vágólapkezelés, se autocsatolás, stb., azok azért szépen tudnak enni, ha minden fut a háttérben, ezeket felrakod Openboxra, majdnem Xfce-szintű fogyasztást kapsz. Nyilván ezek tiling WM-nél nincsenek nagy részt, már ezekkel jelentős memória spórolható.
Jelenleg, míg e sorokat írom, csak Firefox fut, 12 füllel, meg egy szál terminál, és 1279 MB a fogyasztás. Arch + dwm, minden sallangtól mentes, egyedül mint írtam, még az ez spi meg dbus szutyok nincs csak kiszedve, de más semmi nem megy, se autocsatolás, se ikonok, se kompozitor, se semmi (jó, ntp, meg nagyon minimalista vágólapkezelő csak, meg egy feh háttérkép, ami nem is foglal). Szóval ehhez képest az 1330 nem olyan irreális full DE-n, úgy, hogy még fut 1-2 extra bloat.
-
Frawly
veterán
válasz
vargalex
#7844
üzenetére
Igen, egyetértek, a Waylandet nem szabad erőltetni. A böngészők kiválóan elmennek XWayland X.org emulációval, jó, nem ideális, de működőképes, nem fagy, nem crashel, stabil. Ez a Wayland-támogatás még minden böngészőn gyerekcipőben jár, ahogy a hardveres videókódolás is. Semmi baj nincs az XWaylanddel, egy csomó alkalmazás X-es, azokhoz úgy is fel kell tenni, pl. Wine, Steam, médialejátszók, meg még egy rakat népszerű program. Még egy jó évtizedig nem jön el az a pont, mikor minden normálisan támogat natívan Waylandet, ami jó lenne, mert amúgy jó cucc nagyon, csak még korai adoptáció szakaszában van. Kevés progi támogatja natívan, kevés WM/DE érthető el rá. Már használható állapotban van napi szinten, csak túlerőltetni nem kell.
-
Shyciii
veterán
Azért az 1330MB elég sok. Openbox alatt sem foglalt nekem ilyen sokat ezzel a pár programmal, és azért az Openbox már "GUI"-s, bármit is jelentsen ez. Ugyanúgy meg volt mindene, mint az előtte levő XFCE, KDE változatoknál. Egyedül az asztalra kihelyezett ikonokat nem használtam, de azt még a Windows rendszeren sem használom. Viszont Openbox alatt nem használtam egyedi scripteket alap funkciókra. Winyó mountolása is az udiskie volt stb, de ennyit nem foglalt pár proginál akkor sem.
Most meg egyenesen keveset mutat Bspwm alatt minimalizálva amennyire csak tudtam. Most pl fut egy terminál ablak, egy Chromium 7db füllel és 607MB-ot mutat. -
Frawly
veterán
Nem rossz ez azért. Bár én ilyenbe nem tennék munkát, ha valahol kéne egy USB-s rendszer, bebootolnék egy Live rendszert, ízlés szerinti DE-vel. Nyilván annyira nem kényelmes, mint egy rendesen telepített rendszer, de legalább nem kell munkát beletenni. Mert beleteszem én, ha a gépre, belső meghajtóra rendesen feltett, napi szinten használt fő rendszerről van szó, ott kifizetődik a bele tett munka.
Az 1330 MB-os használat meg úgy nem sok, hogy screenfetch-csel nézed (vagy ez már neofetch?), ami többet jelez ki a ténylegesnél, meg fut Firefox 2 füllel, meg GParted, ami megint memory hog, úgyhogy ahhoz képest az 1330 az nem olyan rettenet sok egy komplett DE-s, full GUI környezetben, ami ráadásul csak úgyis USB-s külső meghajtós pótrendszernek lesz használva. Egy Win10 úgy megeszik 1100 megát, hogy semmi nem fut rajta egy Task Manageren túl.
Ez még nálam sem lenne sokkal kevesebb, igaz nálam terminálban cfdisk lenne megnyitva, meg neofetch, meg neofetch mellett felesleges az asztali környezet grafikus névjegye, stb., de olyan 700+ MB körül lennék, talán kicsivel több. És ahogy nyitnánk meg egyre több mindent mindketten, úgy lenne a különbség egyre elhanyagolhatóbb memóriahasználat terén. Ha én is megnyitok Steamet, Goldendictet, fut a Firefox, meg egy csomó terminál, már én se nyerek sokat a minimalista rendszeren, jó, egy KDE-hez képest talán igen, egy Xfce-hez képest már annyira nem.
Ahol nyerek, az az ultrarövid bootidő, meg hogy a progik, doksik, mappák mind az ujjbegyeim alatt vannak gyorsbillentyűkre drótozva (fájlkezelőt sem nagyon kell megnyitnom), és a progik azonnal felvágódnak a képernyőre egy terminálban. Semmi lag, csak pattogósság.
Egyedül a háttérkép nem tetszik, sose értettem, hogy az Xfce miért erőlteti mindig ezt a gusztustalan patkánytémát. Tegyél ki egy normális, szép hátteret, valami természeti kép, vagy wallup.com-ról, vagy wallpaperscraft.com-ról, vagy alphacoders-ről, esetleg Derek Taylor git tárolójából. Minjárt egy kis árnyékot, átlátszóságot is be lehet kapcsolni mellé, hogy pofásabb legyen, a hardverigényt nem sokban dobja meg. Ha már full DE, meg full GUI környezet, akkor legyen meg mellette a csicsa által nyújtott plusz.
Meg annyi, hogy én ilyen világos, meg fehér témát nem használnék, kiég tőle a szemem, főleg, ha napi sok órában nézem. Minden gépemen 10+ éve csak sötét téma van, a szem meghálálja.
-
Frawly
veterán
válasz
Archttila
#7833
üzenetére
Hát, ha ilyen 3900X-eket vették össze, akkor nem csodálom, hogy felemésztett anyagilag. Én csak azt mondom, hogy ha már felemésztett, megvetted, akkor akár használhatnád is. Attól még nem kell függőnek lenni, meg 5900X-et venni, meg szuperszámítógépet. RPi nem rossz kis gép, de szerintem nem desktopra való.
Én egyébként ezért sem veszek sose túl drága hardvert. Pedig megengedhetnék egy drága Mac-et, vagy egy 5900X-et, de annyi pénzt nem akarok belelapátolni, eleve az én igényeimhez mérten overkill, nem használnám ki. Csorogna rá a nyálam, de felesleges túlköltekezés lenne. Elég nekem egy középkategóriás, 6-8 magos korszerű valami, csak ne ilyen ergya, 10 éves, 2 magos, minimum cache-es, minimum W-os szerencsétlenség legyen. Igazából 8 giga RAM-ma is bőven ellenék, csak azért van a gépeimben 16, mert a jövőtállóságra is gondoltam, meg ne volt annyi az árkülönbözet, hogy ezen spúrkodjak.
Ugyanez GPU-ból, elég nekem az 1080p hight settings, 60 fps, nem kell ultra, meg 1440p-4K-8K, nem kell high refereshrate. Integrált GPU-n hajlandó vagyok 720p-s kompromisszumra is (laptopon, stb.). Ja, nyilván jó lenne jobb (4K ultra is leskálázható 1080p-s kijelzőre), de megint felesleges pénzégetésre lenne csak jó.
-
Shyciii
veterán
csixy
Calam-arch telepítőt hsználva sosem lesz kevés a memóriahasználat

sati
Nekem linuxon még az életben nem crashelt a Chromium. Most is a legfrissebb 88-assal nyomulok, de semmi baj, kellően gyors is.Frawly
Sok kicsi sokra megy. Nekem 650db csomag van fent a rendszeren, pedig ezt még tartalék melós gépnek is használom, meg egyedi dolgokra, négis elég ilyen kevés csomag. Ezért is írtam magamnak saját telepítőt, mert akármilyen grafikus arch telepítőt próbáltam ki, mindegyik minimum 720-750db csomaggal operált.
-
Archttila
veterán
Külső HDD-n, torrent, filmek, zenék, képek, biztonsági mentések, archive anyagok tárolásához szerintetek ez így rendben van?
chown -R alucard:users /mnt/PiDrive1chmod -R 755 /mnt/PiDrive1vagy legyen inkább 775?
-
attilav2
őstag
A brave a chrome alapúak közül egész jónak tűnik, egy ideje használom, eléggé stabilnak tűnik, tán ez most a legjobb chrome alapú böngésző. Aztán ott van az edge ami egy ideje linuxra elérhető lett, ez nem annyira stabil de tetszetős a kinézete(olyan w10 utánérzés
) sajnos az aur csomagját nem frissítik rendszeresen így szerkeszteni kell a PKGBUILD-ot hogy a legfrissebb binárist telepítse, a kommentekbe általában postolja valaki a frissített PKGBUILD-ot. -
Archttila
veterán
A nem lat tovabb az kisse tulzas, de ertem mire gondolsz.
A mai napig Castlevaniazok (SotN) de barmikor szivesen eloveszek egy River Raid-et vagy egy jo kis Shoot 'em up-ot a nosztalgiafaktor miatt. En mar akkor tudtam milyen nehezek a FromSoftware jatekok (King's Field) amikor itt rengeteg RGB gamer meg a vilagon sem volt
nem ez a Dark Souls-on nevelkedett generacio vagyok
-
-
Archttila
veterán
Raspberry-m mindig is volt, emellett a (fake)
Atari korszak óta a konzolok is folyamatosan jelen vannak a háztartásban, szóval nem egy te mész, te jössz szituról van szó. Egyáltalán nem.A PC vonalat muszáj voltam dobni mivel már teljesen felemésztette az anyagiakat és az összes szabadidőmet. Amit a képeken látsz az csak töredéke az elmúlt 5 év termésének. Idővel egyre nehezebb volt megmagyarázni a feleségemnek, hogy miért van szükségem egy közel 100.000 forintos gépházra, és ha már így van, akkor miért kell újra eladnom belőle a méregdrága RTX-et, mikor lényegében voltak időszakok amikor hetekig be sem kapcsoltam a gépet.
Megváltozott az életem, elköltőztünk, munkahelyet váltottam, családom lett, a futószalagon gyártott játékok meg már régen nem hozták azt a szintet mint egy Dungeon Keeper 2, Broken Sword vagy egy Diablo 1, csak ugye ehhez is idő kellett mire elfogadtam, megmagyaráztam magamnak, hogy már vége, nem te vagy a célközönség, nem akarnak már szórakoztatni a fejlesztők... (illetve ez nem teljesen az ő saruk de ebbe most nem mennék bele, tudom milyen a impossible határidős meló)Szóval ez a 3900x megtartás olyan mintha azt mondanád a drogosnak, hogy büszke vagyok rád, sikeres volt a terápia, de azért tartsd meg a tűt és az esütkanalat

Röviden ennyi.
Attila voltam, 95 óta gépfüggő

-
Frawly
veterán
válasz
Archttila
#7830
üzenetére
Ezt nem tudtam, hogy ennyire ITX huszár voltál. Attól a Ryzen 3900X-től kár volt megszabadulni, azzal a procival vagy 20 évig ellehettél volna, drága, de addigra visszahozza az árát. Csendes az, ha leveszed az órajeleit enerigatakarékosra. Ha meg hajtod, akkor meg úgyis a teljesítmény fontos, nem a hangja.
Az tuti, ha nekem lett volna egy 3900X-em, sose váltok Rpi-ra. Nekem csak ilyen csóresz ATX Ryzen 2600-asom van (még csak X-esnek sem X-es), meg egy 4700U rizsás, középkategóriás noteszem, de ezekről se váltanék sose Rpi-ra, legalábbis magamtól nem. Az Rpi még egy i3-340, és egy i5-2520M után is nagy visszalépés.
-
Archttila
veterán
Köszi a hosszúra nyúlt választ, de nézted a linkjeimet?
Amikor ITX vonalon voltam, akkor egy Louqe Ghost 8.5 literes kuckóban hűtöttem a Ryzen 3900x-et. (linkem nézd meg, de az ITX topikban is van pár rig-em
)
Azért is írtam, hogy inkább CPU/Arch viszonylatban kérnék segítséget, de akkor ezek szerint a 3550H jobban megéri mint a 3300U.A memóriák nem forrasztottat, CPU-t leszámítva minden upgradelhető, a cucc meg maga extreme csendes. [link]
-
Frawly
veterán
válasz
Archttila
#7826
üzenetére
Szerintem egykutya, ma már normális böngésző nincs. A Firefox még egy fokkal annyiból jobb, hogy kicsit kevesebb erőforrással beéri, több mindent tudsz állítani rajta, meg több normális plugin érhető el hozzá, meg a használatával nem a Google/Chrome-alapúság monopóliumát támogatod. De ma már a FF is elég szar, Wayland ide, mobil nézet amoda. Egyébként szerintem a mobil nézetet azért erőlteti, mert az RPi IGP-jét mobil GPU-ként érzékeli. Vagy a Wayland miatt.
-
Frawly
veterán
válasz
Archttila
#7825
üzenetére
Most elég szar új gépet venni, semmi nincs készleten, minden drága, koronacirkus, készlethiányok, áremelések, közelgő világválság miatt. Most tényleg csak azt tudod venni, amit találsz. A Ryzen 5-öt jobban támogatom, de azt nem biztos, hogy kapsz. Ha veszel is gépet, és nem laptop, akkor inkább magad rakd össze hardverelemenként, rendes asztali ATX gép, Ryzen proci (vagy Intel, de akkor abból a legújabb gen), 16 GB RAM. Laptopból meg veszed, ami van készleten, arra figyelj, hogy min. 8 GB RAM (de inkább 16, mert oda szokott lenni forrasztva), valami min. Ryzen 5 vagy Core i5-ös (nem túl régi genes inteles) proci, meg legyen bővíthető benne az SSD. Meg a driverek miatt az NV dedikált GPU-t lehetőleg kerülni kell Linuxon. Meg az még minimum ma már, hogy min. FullHD IPS kijelző, ebből ne engedj, ne vedd meg már 2021-ben a HD-s TN paneles szutykokat, amiknek mára már rég ki kellett volna haljanak.
Mini PC-t nem ajánlok, az ötvözi a laptop és az asztali gép hátrányait, és annyival kevesebb helyet nem foglal. Egy asztali gépnél úgyis a monitor, bill, egér, kábelek foglalják a helyet, az mini PC-nél is ugyanúgy ott van, az ATX házat is épp úgy el tudod suvasztani valahová, hogy ne legyen útban. Fogyasztásra sem lesz nagy különbség, mert ha nem hajtod ki, akkor a desktop se fog túl sok W-ot enni, cserébe mindene bővíthető, nincs benne semmi odaforrasztva, standard alkatrészek jók bele (ATX táp, full magasságú PCIe kártyák, desktop DDR4 memória, standard M.2 és SATA meghajtók). Egy bölcsen vett és időközben minimum pénzért bővített asztali konfiggal 10-15 évet ki lehet húzni, megéri a többlethelyet.
-
Frawly
veterán
válasz
attilav2
#7823
üzenetére
Listázhatnám, de nincs sok értelme, én kevés fontot telepítek, azokat is kézzel, Ubuntu font family, Fantasque Sans Mono terminálban, DejaVu fontcsomag mindenféléhez (Thunderbird, Firefox, stb.), meg most talán valami Nerd font van fent, ami működni sem akar dwm alatt. Nincs nagyon más fent, mivel én nem telepítek asztali környezetet, csak WM-et, meg mindenből terminálos programot használok GUI-s helyett.
Egyébként meg az sem baj, ha túl sok font van telepítve, mert azok nem kérnek memóriát, meg nem töltődnek be, ha nem használja őket semmi, és sok lemezterület se kell nekik. Egy kényelmetlenség van, ha túl sok font van fent, hogy azok néha frissülnek is, ami sávszélt viszi, meg ha esetleg gyakori fontcache-generálás van, azt egy töredékmásodperccel lassítják, de ennyi.
-
Archttila
veterán
Pár hónapja még azt írtam a Firefox-ról hogy Chromium-hoz képest nagyon lassúcska szegénykém. Nos ez a héten változott.

A Chromium amióta a 88-as verzióra váltott folyamatosan crash-el de ezt úgy kell érteni, hogy tényleg folyamatosan.
Fel is rántott rendesen, gondoltam jól van akkor megy vissza a róka dacára annak, hogy korábban lassabbnak tituláltam. Hát nem, egyáltalán nem lassabb sőt! Megkapta a Wayland támogatást, és repeszt
(Xwayland disabled)Egyetlen hibája neki, hogy a weboldalakat folyamatosan mobilnézetben szeretné megjeleníteni.
Szerintetek ez mitől lehet?
-
Archttila
veterán
Koszonom! (neked is Frawly)

Mas:
Tudjatok korabban mar emlitettem, hogy nem anyagi korlatok miatt hasznalok Raspberry-t hanem reszint azert, (gondolom ez mar az oregseg jelei) mert probalok csak az aktualis es tenyleges felhasznalasi igenyeimnek megfelelni, a fentmarado penzmagot pedig egyeb (szamomra) fontosabb dolgokba fektetni.
A kis Malnagep nagyon jo belepot biztositott az Arch vilagaba. Most nem sorolnam fel, hogy milyen rendszereket (grafikus alkalmazasokat) hasznaltam elotte es hol tartok most...
legyen eleg annyi, hogy szamomra egy kellemes am még valoszinuleg hosszu ut alapjait fektette le ez a kis takonyzold PCB. ![;]](//cdn.rios.hu/dl/s/v1.gif)
Ennek ellenere ma vegul arra a kovetkeztetesre jutottam, hogy leveszem a terhet a vallarol, es hamarosan mar csak fajlszerverkent eli tovabb nyugodt kis eletet, a hetkoznapi Archoskodasra pedig veszek egy x86-os mini pc-t. Ehhez kernek most egy kis segitseget, valojaban inkabb csak a procirol erdekelne a velemenyetek. Korabban a gaming vonalon megszoktam, hogy altalaban a felsohazbol valasztok MAGamnak valami jokepu CPU-t ugy 8-12 maggal, bloat windows-hoz etc. Most viszont az Arch-hoz kellene igazodni, azon belul is a DE mentes kornyezethez, ezert en azt gondolom, hogy egy Ryzen 3300U 8GB 2400MHz konfig eleg lehet a kituzott celhoz. Az eleg lehetet ugy ertem, hogy a bongeszes (youtube+facebook szakmai oldalak) es AUR-bol telepites lesz a legnagyobb kihivas amivel meg kell birkoznia, akarom mondani relative ertelmes sebesseggel vegrehajtania. (valljuk be RPI-n pl. egy rtorrent forditas nem valami huuudegyors mutatvany)
A kovetkezo vasat neztem ki a feladatra. (na jo kettot)
3300U (kuponnal most 101e lenne)
MINISFORUM DeskMINI UM300 AMD Ryzen 3 3300U 8GB DDR4 256GB SSD Radeon Vega 6 Graphics [link]
3550H (kuponnal most 107e lenne)
T-Bao TBOOK MN35 AMD Ryzen 5 3550H Mini PC 8 GB DDR4 256 GB NVME [link]
A minisforum (tobb okbol kifolyolag is) szimpatikusabb viszont gyengebb benne a CPU.
Szerintetek a fentebb vazolt igenyeknek eleget tesz a Ryzen 3, vagy gondolvan a jovore is legyen inkabb a HT-s Ryzen 5?

-
BoB
Topikgazda
Moving to Zstandard images by default on mkinitcpio
As linux-lts moved to the 5.10 version, all official kernels of Arch Linux now support zstd compressed initramfs images, so mkinitcpio is switching to zstd compressed images by default with version 30, which is currently on [testing].
If, for any reason, you are using a kernel version prior to 5.9, make sure to change mkinitcpio.conf COMPRESSION to use one of the compressors supported, like gzip, otherwise you will not be able to boot images generated by mkinitcpio. -
attilav2
őstag
Azt ki tudnád listázni hogy nálad milyen font csomagok vannak fenn? Milyen parancssal lehet kilistázni a fenn lévő font csomagokat?
Gondolkodok egy minimalista újratelepítésen, kde helyett mate vagy cinnamon alapokon, mert már eléggé meghízott a rendszer, viszont a fontokkal mindig gondban voltam újratelepítés után, mindig el kellett telnie pár hónapnak mire úgy ahogy helyre rázódott a dolog(weboldalak, rendszer párbeszédpanelek, menük helyesen nézzenek ki). -
Frawly
veterán
válasz
Shyciii
#7821
üzenetére
Nálam X.org témában ezek vannak fent, meg ezeknek a kötelező függőségeik:
xf86-input-libinput
xf86-input-synaptics
xf86-video-amdgpu
xorg-fonts-encodings
xorg-server
xorg-server-common
xorg-setxkbmap
xorg-xauth
xorg-xev
xorg-xinit
xorg-xkbcomp
xorg-xmessage
xorg-xmodmap
xorg-xprop
xorg-xrandr
xorg-xrdb
xorg-xset
xorg-xsetroot
xorgprotoEzek közül vannak feleslegesek, pl. az xsetroot, xprop, xev csak valamihez kellett, saját scriptben kísérleteztem velük és csak fent maradtak. De a többi kell, libinput billentyűzetnek, synaptics a tapipad multitouch részéhez, xf86-amdgpu a 2D-s videógyorsításhoz és vsynchez, xauth, server, xinit, xmodmap, xkb, xset, utóbbi három billentyűzetkezeléshez. Tehát annyira sok sallang nálam sincs, nem a teljes xorg metacsomag van fent.
Talán még a fontencoding az, ami lehet felesleges. Nem is én tettem fel, valami behúzta függőségnek.
-
Frawly
veterán
válasz
Shyciii
#7818
üzenetére
Akkor lehet ez a különbség. Bár nem látom be, hogy ez ekkora lenne, mivel nálam csak a X.org server fut, lehet van fent felesleges csomag, de azok nem töltődnek be, ha nem használja őket semmi. Következő installnál én is törekedni fogok, hogy a minimumot rakjam fel ebből is.
Amire még az én esetemben gondolok, hogy az AMD GPU miatt nőtt meg a memóriaigény, szerintem komplexebb drivere van (mint kernel, mind a X.org, mind a mesa szintjén), mint a korábbi Intel IGP-knek, amit használtam, mivel jóval több feature-t is tud. De ez is csak egy tipp, nem vagyok benne biztos.
-
Shyciii
veterán
Részben Arch wiki installja alapján állítottam össze a scriptemet, de annál minimalistább, mert pl a xorgot egy az egyben rakná fel kompletten az arch wiki, én viszont kislabilizáltam, hogy valójában mi az a minimum xorg csomag, ami kell nekem. Már ezzel rengeteget spóroltam. A többiről nem is beszélve.
-
Frawly
veterán
Aki már most 5.11-es kernelt használna Archon (egyelőre a Testing tárolóban van csak), Ryzen APU-val, annak előre szólok, hogy a kernel kiírja, hogy:
amdgpu: Unsupported power profile mode 0 on RENOIR
Természetesen ez csak egy üzenet, amit kiír, semmilyen rendellenességet nem okoz. Valószínű először rossz energiagazdálkodási profilra akarja belőni az integrált AMD GPU-t, majd ezt sikerrel korrigálja magától.
Csak azért szólok, mert elsőre én is megijedtem, hogy itt valami baj van, hiszen én display manager híján a konzolon jelentkezek be, és kiírta ezt a sort, de a bejelentkezés és a grafikus felület töltése simán ment, nem tapasztalok semmilyen rendellenességet nem okoz, sem szöveges módban, se grafikus módban, sem 2D-s, sem 3D-s alkalmazások alatt.
-
Frawly
veterán
válasz
attilav2
#7815
üzenetére
Fel lehet épp gányolni, mert elég kimásolni a .deb alóli tar.gz-ből a bin mappát, az portable módban akár a user mappájából is lehet futtatni. De nem érdemes, mert így nem frissül, meg a libekkel való verziókompatibilitása sem lesz biztosított. Inkább az AUR-ból kell megoldani, ha egy mód van rá. Ha kisebb progi (a Chrome, Chromium nem ilyen), akkor akár forráskódból is lehet kézzel forgatni, az is jobb, mint az ubuntus csomag telepítése.
-
attilav2
őstag
válasz
growler
#7798
üzenetére
Szerintem nem éri meg debian csomagokat feltaknyolni, ha elérhető az aur-ban azt kell választani, ha nem elég friss az aur által buildelt csomag át lehet írni a PKGBUILD-ban a deb csomag elérési útját verziószámát stb, és akkor a frissebbet is lebuildeli és felrakja.
Én a chromium vaapi ubuntus ppa változatát taknyoltam fel hasonló módon kézzel ahogy frawly írta, a youtube vga gyorsítás ment vele, de a felrakás módja szétcseszte a jogokat a rendszerkönyvtárakban így más programok hibásan kezdtek működni
végül rendszer reinstallal sikerült rendbehozni, szóval aki nem ért nagyon az unix jogokhoz az ne nagyon taknyoljon fel manuálisan más disztróhoz való csomagokat, akár nagy szívás is lehet belőle. -
vinibali
őstag
válasz
vinibali
#7813
üzenetére
szerintem ott lehet a gond, hogy tullep a dropbear-es reszen a boot es ezert dobja el a csatlakozast. egy teljes particio van cryptsetuppal titkositva, nincs alatt lvm. most azt gondolom, hogy ez igy lehet hogy nem jo, illetve valamiert hiaba adom meg a crpytdevice=UUID=* parametert, az a root=UUID=*-ot akarja felolvasni.
:: running hook [netconf]
IP-Config: eth0: ************
IP-Config: eth0: gw: ************ dns0: ************ dns1: ************
:: running hook [dropbear]
Starting dropbear
[237] Feb 14 06:50:11 Running in background
:: running hook [encryptssh]
ERROR: Failed to open encryption mapping: The device UUID=************ is not a LUKS volume and the crypto= paramater was not specified. -
vinibali
őstag
Tavoli dmcrypt feloldas kapcsan vannak koztunk tapasztaltabbak?
Adott egy FM2-es gep, ahol a home particiot kellene feloldani, meg is csintaltam mindent ami: a dropbearhez tartozo leiras resze.
Annyi erdekesseg maradt, hogy amikor betolt a kernel es initrd es pillanatra felvillannak a halokartya ledjei, a netconf-nal visszaadja a gep a helyes halozati beallitasokat, majd a ledek elaszanak es ugy maradnak mindaddig, amig a jelszot be nem irom egy billentyuzetrol es folytatodik a betoltes.
ha nincs hozzaadva az r8169 a modules reszhez akkor fel sem villannak a csatlakozon a ledek, bar ezt nem nem is szerepel a drotos leirasban, csak a wifisnek a resze.
ameddig rossz host kulcsokkal akartam guritani es a dropbear hibara futott, nem dobta el a halozati kapcsolatot a boot alatt, csak connection refused-ot dobalt a nem futo dropbear. -
Frawly
veterán
válasz
Shyciii
#7809
üzenetére
Az elég szép. Nem tudom, nálam alap Arch van, Arch Wiki alapján feltéve, nem használok semmilyen scriptet, dwm is minimalistább, kisebb WM, nem kell neki sxhkd, stb., és mégis többot foglal a rendszer. Az is igaz, hogy a rendszerben még benne van pár szemét, dbus, at-spi, pipewire, amit nem én telepítettem bele, hanem valami csomag behúzta függőségnek, és az Arch elindítja, ha kell, ha nem.
Lehet nálad még valami régebbi Arch telepítés van, amibe ezek a szutykok még nincsenek benne default, és/vagy a terminálod is soványabb. Egyébként a bspwm-re átállást én is fontolgatom, mert összességében a dwm nem jön be. Használható, elvagyok vele, de vannak korlátai, mindenhez patchelni kell, nem támogatja rendesen a panelprogramokat, mint polybar, nem lehet manipulálni X-es toolokkal (xdotool, wmctrl, néhány scriptemben használnék ilyeneket), mivel nem ewmh kompatibilis. A bspwm úgy sokkal rugalmasabb nála, hogy lényegében semmivel nem bloatabb, így kacsingatok felé.
-
Frawly
veterán
Sajnálsattal olvasom, pont nemrég, az Ubuntu topikban is írtam egy kezdőnek, hogy még több évtizedes unixos-linuxos tapasztalattal rendelkezdő veteránok is megszívják a dd-t, és bedarálják a rendszerüket. Nem viccelek, nekem is van ilyen ismerősöm, adta ki a dd-t automatikusan a /dev/sdb-re, csak épp a gépben benne lett felejtve egy pendrive, ami bootkor a /dev/sda-t kapta, a rendszermeghajtó kivételesen /dev/sdb-ként szerepelt, és ledarálta azt.
Én még pont a dd-t nem szívtam meg, de pl. rekurzív jogosultságváltást adtam ki véletlenül túl magas mappaszinten (chown, és nem vettem észre, hogy rossz mappaszinten vagyok), amivel bedaráltam a rendszerem, meg a felhasználóm sem tudott bejelentkezni polkit hibával. Ilyen lámulásokat mindenki elkövet, tanulópénz.
A dd-be régóta be kéne építsenek védelmeket, hogy minden dd-zés előtt kérdezzen, listázza ki a meghajtókat, írja ki a dd-zendő meghajtó méretét előtte, és ne engedjen olyan meghajtóra dd-zni, amiről rendszer fut (kapcsolóval felül lehessen írni), és külön figyelmeztessen, ha olyanra dd-zik, amin van fájlrendszer. Én reflexből minden dd előtt futtatok egy lsblk parancsot, hogy meggyőződjek, hogy jó meghajtóra fogok dd-zni.
Ez ilyen, újratelepíted, azzal is tanulsz. Szépen húzod le újra az install iso-t (ha régen telepítetted a rendszert), és telepíted újra. Esetleg lehetne úgy, hogy particionálás után belépsz terminálban chroot környezetbe (gépet újra nem indítva), és az alól telepítesz az Arch Wiki alapján vanilla Archot, particionálás, pacstrap, pacman -S csomaglista, bootloader telepítése, passwd, exit, reboot.
-
Na ekkorát még nem szívtam linux ügyben sosem! Egy dd-vel fejbeqúrtam a saját rendszerem. A telepített rendszer már oda van, de még mindig él a RAM-ban. A dd-t még megcsináltam végül oda ahova eredetileg szándékoztam, most már nagyon kíváncsi vagyok rá, hogy fog-e menni ez a kalandos úton készült silverblue telepítő. Még mindig a RAM-ból netelek. Újraindítva már biztos nem fog menni.A Gparted egy üres SSD-t mutat. Qrva jó.
-
Frawly
veterán
Ja, akkor meg is van a nagy csodálkozás oka, a screenfetch kamu adatokat közöl a memóriafoglalásra. Ő maga nem sok memóriát foglal egyébként, 1 ms alatt lefut, utána már semmit nem foglal. Próbáld helyette a neofetch-t, az nem véletlenül népszerűbb. Bár a neofetch RAM kijelzése sem a legjobb, de ennyire kamu adatokat nem ír.
De az a mérvadó, amit a free ír (és a -m kapcsolóval a legjobb meghívni, tehát a legjobb kapcsolót használtad, bár a -wm kapcsolóval még kicsit részletesebb), az alapján 497 mega (a shared-et van, aki még hozzáadja, de az már úgyse nagy különbség általában), ami egy szál terminálhoz képest (ha tényleg csak az fut) még mindig vaskos, de már nem olyan eszméletlenül, közepesnek mondható.
Tényleg csak és csakis kizárólag a free a mérvadó, az a kerneltől kérdezi le, a /proc/meminfo alapján. Persze általában a többi tool is innen veszi az adatokat, de sok progi elég egyéni szájíz szerint értelmezi, se az akármilyenfetch, se az akármilyentop, se a grafikus feladatkezelők kijelzése nem pontos. Össze-vissza szoktak hülyeségeket mutatni, szórnak az adatok, nem is elenyésző mértékben.
Tényleg sok éves linuxos tapasztalat, hogy a free a pontos. A terminálos progik közül a sima top, a grafikus progik közül az lxtask van még a legközelebb hozzá. A htop már nem pontos, bár sok proginál azért kicsit pontosabb. A fetch-ek közül a neofetch még a legpontosabb, de az hozzáadja a shared-et a used-hoz, szóval így kell figyelembe venni. Minden más proginál lehet legyinteni, nem szabad elhinni, amit írogatnak, se gotop, se Conky, se gnome-system-monitor, se semmi nem megbízható sajnos.
A free -wm kimenetében pedig a buffers és cache oszlopokat nem szabad memóriafoglalásként figyelembe venni, mert bár foglalnak a memóriában, de olyan módon csak, hogy igény esetén azonnal felszabadul utánuk a memória, tehát nem veszik el más programok elől, meg nem lassítanak semmin, azaz pont, hogy gyorsítanak. Az used oszlopot kell figyelembe venni, esetleg a shared hozzáadható. A többi oszlop csak tájékoztató jellegű.
Egyébként ez a fél gigás memóriafoglalás annyiból kicsit sok, hogy csak 4 giga RAM-od van, ebből levesz az integrált GPU, máris csak kb. 3,5-3,75 giga marad, ebből még a rendszer cache-elne, főleg ha grafikus progikat használsz, ez a foglalás nő, beküldesz neki egy több füles böngészést, és már erősen swapol a történet. Ha ennyire szeretsz bloatot használni, akkor majd egy 8 gigára bővítést megfontolhatnál. A 16 GB overkill lehet, ha nem használod ki, de a 8-nak mindenképp lenne a te felhasználásodnál értelme, különösen, ha Chrome-alapú böngészőt használsz.
-
Frawly
veterán
-
Archttila
veterán
-
Frawly
veterán
Örülök, hogy sikerült a bootolás. Az Archnál elvileg mindegy, hogy mivel telepíted, valami installerrel vagy Arco Linux formájában, ugyanazt az Arch ökoszisztémát kapod, ugyanaz a pacman és ugyanazok a tárolók.
GPU driver külön nem kell, csak ha NV kártyát használsz. Xfce4-nél viszont sokallom, hogy egy szál terminál fut és 700 MB memóriát bekajál, az nagyon bloat. Ennyiből már megáll egy Gnome vagy KDE, de még Cinnamon is. Persze baj sincs vele, de azért az Xfce a 3-as és korai 4-es verzióknál azért jóval soványabb volt, utoljára én a korai 4-essel teszteltem valami 2 éve, és akkor olyan 270-300 megát evett, az is igaz, hogy nem volt fent minden, csak a legszükségesebbek rajta. Az is igaz, hogy az egész Linux bloatabb, mint 2 éve, most már a dwm-es Arch telepítésem egy Termite terminállal sem áll meg 230 MB alatt, anno azért jóval kevesebb volt, az is igaz, hogy a dbus-t meg at-spi szutykokat még nem heréltem ki róla, meg még nem álltam át st terminálra. Artixon Openbox Termite terminállal 280 MB. Egyelőre a legsoványabb a SwayWM-es Archom a maga 170 MB-os fogyasztásával, ha egy Termite terminál fut.
És nem mintha 8-16 GB RAM-nál nem lenne mindegy, de a betöltési időkön meglátszhat. Én azért nem szeretem a magas memóriafogyasztást, a vaskos kódok lassabbak is, mert be kell tölteni őket a procinak, és az a procinak is többletterhelés, meg forráskódból is hosszabb őket lefordítani. És mikor a sok kicsi jön össze, egy kis plusz 50 mega itt, 150 mega amott, a végén azon kapja magát az ember, hogy giga felett karistol, és dupla idő alatt bootol a rendszere.
Ha a bloatosodás így folytatódik, a mainstream DE-s disztrók be fogják érni a Win10-et, ami 1,1 gigát eszik alapból, default stock telepítés után közvetlenül. Az is igaz, hogy 1,1 gigás idle memóriafogyasztásnál is gyorsabbak lennének a Win10-nél, mivel a Linux kernel jobban kezeli az erőforrásokat, meg jobban a linuxos fájlrendszerek, az egész rendszer reszponzívabb lenne, mivel se szutyok NTFS, se Defender, se registy, se OneDrive, se Windows Update, se telemetria nincs. De azért nem lenne jó, ha beérnénk a Win10-et. Sajnos ez az átka, hogy a Linux népszerűsödik, meg egyre többen használják, a többsége frissen Windowsról jövő felhasználó, és az ő kedvükért Windowst csinálnak belőle, holott a Linux lényege pont az lenne, hogy nem Windows.
A 90-es években egy korai Linux disztró ráfért pár floppyra, mármint a telepítő, és elment egy 486-oson is 8-16 MB RAM-ból, egy fvwm, KDE1-2, Gnome1-2 szintű felülettel. Attól hova vagyunk már, jelenleg egy ultrasovány, systemd-mentes, grafikus felülettel nem rendelkező Gentoo is így megy egy 64 MB RAM-os 486-oson, csak a boot 11 perc. Másik részről azért ez nem egy fair összehasonlítás, mert akkor még nem volt minden netre kötve, nem volt mindenben milliónyi biztonsági folt, nem használtak az emberek akkor még 3D GPU-t (vagyis a LInuxon nem), nem használtak fontsimítást, meg HD, FullHD videókat, max. MPEG1, meg később DVD ment SD-ben, jóval egyszerűbb volt a world wide web is. Tehát egy egyszerűbb világ volt, a kódoknak kevesebbet kellett tudni, és kevésbé biztonságosnak kellett lennie. Cserébe viszont a hardver is hatványozottan gyengébb volt.
Ezt nem érti ubyegon, hogy jól fut a HP Elitebookján a Cinmanó, persze, amit kihagy a számításból, hogy i5 procival meg 12 GB RAM-mal, SSD-vel, és a legfontosabb kulcsszóval: EGYELŐRE MÉG. De már észrevette, hogy a korábbi 2,7 mp.-es bootideje rég a múlté, már rég duplája felett nyomja, és nem látja ennek a veszélyét.
-
wwenigma
Jómunkásember
válasz
wwenigma
#7341
üzenetére
Ismét előhozakodok ezzel a kérdésemmel.

Adott egy AX200-as kártya amit a korábbi 8260 helyére raktam be egy PCIe adapterbe. A BT része működik, látja. Viszont a WLAN része egyáltalán fel sem tunik sehol sem, sem dmesg sem lspci nem mutatja. Barkinak valamilyen ötlete van? Google-ból kifogytam.
Új hozzászólás Aktív témák
- Steam, GOG, Epic Store, Humble Store, Xbox PC Game Pass, Origin Access, uPlay+, Apple Arcade felhasználók barátságos izgulós topikja
- Samsung Galaxy A54 - türelemjáték
- Automobilista 2
- Milyen egeret válasszak?
- Horgász topik
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Samsung LCD és LED TV-k
- Google Pixel topik
- AMD Ryzen 9 / 7 / 5 10***(X) "Zen 6" (AM5)
- Elektromos autók - motorok
- További aktív témák...
- Lenovo Thinkpad X1 Yoga 6th Gen. i7 11th, 32GB RAM, új akku, 4G LTE, toll, 27% ÁFÁS (0215)
- BESZÁMÍTÁS! MSI B650 R7 7700 64GB DDR5 1TB SSD RX 7900 XTX 24GB Lian Li LANCOOL 216 ARGB 850W
- Új és régi konzolok Okosítása és Szoftveres szintű javítása - Már 12.52 FW-s PS4-ek is!
- Dell Latitude 7420 Core i7-1185 G7, 16GB RAM, SSD, jó akku, számla, 6 hó gar
- iPhone 13 mini 128GB Green -1 ÉV GARANCIA -Kártyafüggetlen, MS3897
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Azért köszi a segítséget, úgy néz ki nem mostanság lesz megoldva a bug, de ez a bug se egyedi, csak nálam éppen a vga miatt ütközött ki.


, kíváncsi voltam mennyire használható ez a telepítő. Nos azt kell mondjam használható, szinte kulcsra kész rendszert ad. Azt leszámítva hogy nálam a telepítő nem tudta létrehozni a partíciókat, mbr kiosztás volt a céllemezen, én meg uefi módban telepítettem, talán ez lehetett a gond, ebbe még a win10 telepítőnek is beletörhet a bicskája. cfdisk -z /dev/céleszköz módon megoldottam a partícionálást gpt-re, ezután a grafikus telepítő partícionáló részében már csak fájl rendszereket és csatolási pontokat választottam ki a cfdiskben létrehozott partíciókhoz, majd szépen felkúszott a rendszer. Alaprendszert, amd drivereket és xfce4-et telepítettem. Probléma mentesen indult az új rendszer, csak az amdgpu drivert finomhangoltam az arch Wiki alapján hogy ne legyen tearing.

Atari korszak óta a konzolok is folyamatosan jelen vannak a háztartásban, szóval nem egy te mész, te jössz szituról van szó. Egyáltalán nem.


