- Hivatalosan is bemutatta a Google a Pixel 6a-t
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Friss koncepciót hoz a Nothing Phone (3)
- Xiaomi 15 Ultra - kamera, telefon
- Íme az új Android Auto!
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Xiaomi 15 - kicsi telefon nagy energiával
- iPhone topik
- Azonnali mobilos kérdések órája
- Yettel topik
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
Frawly
veterán
Elvileg sikeresen lezajlott a váltás, a tervezettnél előbb. Viszont még egyik tényleges mirror se követte le a változást, legalábbis a core-testing, extra-testing még egyiken sem létezik, akinek ez nem kell, azok változást nem fognak észrevenni. A /etc/pacman.conf-ot át kell írni, hogy milyen tárolókat használjon, esetleg egy pacman -Scc; pacman -Syy parancsot érdemes futtatni. Lehet lesz még pár nap, mire újraindul az újabb verziós csomagok készítése.
-
Frawly
veterán
válasz
Archttila
#8704
üzenetére
Az ilyen gondjuk általában Ubuntu, Debian felhasználóknak vannak, mert elavult kernelt, mesa-t használnak. Valójában nincs baj vele. eGPU-nál viszont az adott gép BIOS-a, meg a dokk bezavarhat a kompatibilitásba, az eGPU egy olyan bizonytalan műfaj, hogy nincsenek rá garanciák. Hacsak nem találsz valakit, akinek konkrét kártya, dokk, gép kombójában biztosan megy, és te nem veszed meg pontosan ugyanazokat a hardverelemeket, akkor nem garantálható, hogy megfelelően fog működni.
Nekem nincs RX 6xxxx-em, de használtam már RX 570, RX Vega8, 680M Radeon kártyát és IGP-ket, mindegyik kiválóan ment Arch alatt, semmi drivergond, semmi spécit nem kellett hozzá feltenni vagy állítani, alapból normálisan működtek, X.org és wlroots Wayland, Gnome/KDE Wayland alatt is. Az AMD modern kártyái a legkompatibilisebbek. Azért veszek én is csak AMD-t, hiába az Nvidia kártyák adott esetben erősebbek, azzal kitörölhetem, ha egyszer csak Win only, és Linuxon, FreeBSD-n is csak egy kotvák zárt driverrel megy, amivel csak a gond van, nem lehet tőle kernelt frissíteni, Waylandet használni, stb..
Az Nvidia már kezdi összeszedni magát, elkezdte a nyílt driver fejlesztését, de csak 16xx és 20xx vagy annál újabb kártyák támogatottak, és egyelőre még mindig nagyon bugos állapotban van. Évek lesznek, mire utolérik az AMD-t, Intel-t ebben a tekintetben. Addig meg az van, hogy Linuxhoz, BSD-hez tudni kell hardvert venni, akkor nem lesz gond az inkompatibilitással. Kivéve, mint mondtam, az eGPU, az egy abszolút lutri műfaj.
Nekem is volt eGPU-m, de én szándékosan működő kombót vettem, RX570-es Radeon kártya, EXP GDC 4-es dokk, Thinkpad X220-on használtam Express Card-dal, és egy CX550-es táp hajtotta az egészet, és rendesen működött Arch és Win10 alatt is. Csak aztán meguntam, hogy tele van az asztal kábellel, meg körülményes volt összedugni a laptoppal, ezért pár hónapra rá inkább betettem a kártyát és a tápot egy asztali gépbe, amit ezek köré építettem. Ha már így is, úgy is a helyet foglalja, akkor legyen félmegoldások helyett rendes ATX-es asztali gép. Megérte, a mai napig jól működik, bár tervezem a Ryzen 2600-at lecserélni egy 5800-asra, az RX570-et meg valami modernebb, 8 giga VRAM-os kártyára, ilyen RX 6700 szintre gondolok, de még kicsit drágállom őket.
-
Frawly
veterán
válasz
Archttila
#8645
üzenetére
Bocs, ezt hülyén írtam. Az AUR/linux-amd az eleve zenvr3-ra kéne legyen, de van egy ugyanilyen csomag, AUR/linux-amd-znver2. znver-re (Zen, Zen+) nincs külön ilyen kernel, de egy generic AUR-os kernelcsomagot viszont le lehet rá fordítani optimaliizáltan, a /etc/makepkg.conf-ba beilleszted ezt:
CFLAGS="-march=native -O2 -pipe -fno-plt"
CXXFLAGS="${CFLAGS}
RUSTFLAGS="-C opt-level=2 -C target-cpu=native"
MAKEFLAGS="-j$(nproc)"
Ez a native kapcsoló lényegében detektálja, hogy mi az adott procihoz a legoptimálisabb fordítási profil, ami kihasználja az összes utasításkészletet. Nem csak kernelnél fog működni, hanem a összes AUR-os csomagnál életbe lép, már ha az adott csomag makepgk scripte felül nem bírálja, de ez ritka. -O2 helyett -O3-mal is lehet próbálkozni, de azt nem minden kód szereti, igaz azok felül szokták bírálni -O2-re.
Ebből a MAKEFLAGS="-j" rész detektálja a prociszálak számát, azon belül is a nproc parancs, pl. ha 16 szálas a proci, akkor 16-tal tér vissza, és így make -j16 formában hívódik meg a make, és fordít mindent. Érdemes megejteni általánosságban is, mert sok AUR-os csomag fordítása gyorsabb lesz.Szerintem valami hasonló van Debian-on is, igaz ott nincs AUR, de a rendszerben valahol be lehet konfigurálni ezeket a fordítási kapcsolókat, hogy ha forráskódból forgatsz, akkor minden magot használjon, és konkrét procira optimalizáljon. Ha más nem, akkor az adott fordítandó kód makefile-jában vagy közvetlenül a fordítást végző parancsok kiadásakor írod be ezeket a környezeti változókat, pl.
make CFLAGS="-march=native -O2 -pipe -fno-plt" CXXFLAGS="${CFLAGS} MAKEFLAGS="-j$(nproc)"
Elvileg, mert Debianon nem csináltam még ilyet, de minden disztrón működnie kéne.
-
Frawly
veterán
Arra azért figyelj, hogy egy Ryzenekre szabott kernel, ha inteles rendszered van, akkor jó eséllyel bebootolni se fog.
Egyébként nem fordul órákon át, 10-15 perc körül, ha nem túl szar a gép. Már pedig mivel Ryzenekre készült, azokból a leggyengébb is van olyan gyors, meg annyi magos (min. 4), hogy kb. ennyi idő alatt lefordítja, és ezeken a rendszereken mindig van min. 8 giga RAM is. Nálam mind Ryzen 2600, 4700U, 6800H + 16 GB RAM alatt lefordult kb. 10 perc alatt (az is igaz, hogy a makepkg konfigjába be van állítva, hogy az összes magot használja és zenvr-zenvr2-zenvr3-ra optimalizáljon. A stock vanilla kernel defconfiggal kb. 2-3 perc, de ez egy fullos kernel, egy csomó extra AMD cucc, meg Arch-patch, extra driver benne van, ami egy csomó kernelmodult jelent, így nyilván hosszabb a forgatása, de nem vészes. Ennek ellenére néhány embert frusztrálhat ez a 10 perc is, hogy izzik a procija meg süvítenek a ventik, nekik lett kitalálva a bináris változat.
-
Frawly
veterán
válasz
Archttila
#8083
üzenetére
Nem tudom. Én btrfs-re csinálnám, és ahhoz RAID sem kell, mert be van építve a btrfs-be, hogy lemezen átnyúló redundáns kötetet is tud. A ZFS dettó. Az ext4-gyel sincs baj, ha RAID van alatta. Amelyik jobban tetszik, jobban bízol benne. Esetleg a RAM-tól is függhet, de ha az RPi-ról van szó, akkor azon a 4 giga RAM elég a ZFS-hez is.
-
Frawly
veterán
válasz
Archttila
#8081
üzenetére
Én azért X.org-ozok, mert azon többféle WM van. A Wayland jó, de csak kevés WM érhető el alá. Jó a Sway, de meg akarok ismerni mást is. Nem akarok olyan szemellenzős lenni, mint a kollégák a Linux OFF topikban, hogy 7-10 éve vannak beleragadva ugyanabba a disztróba, grafikus felületbe, megoldásba.
Az Xmonad-nak az a baja, hogy Haskell-ben van írva, az meg egy nagyon spéci programozási nyelv, ami funkcionális, mindenféle lamba calculus kell hozzá, hogy megértse valaki. Ilyen teljesen elvont, nyakatekert koncepció. Emiatt én sose fogom megérteni, feltenni. Ha sima C-ben, vagy göcsörtös C++-ban vagy hasonló sztenderd imperatív strukturált nyelven lenne írva, akkor megküzdenék vele, de így felejtős örökre.
Én, ha most kéne gépet venni, akkor akármennyire is AMD Ryzen párti vagyok, mivel azt nem nagyon lehet normális áron kapni, mivel hiány van abból is, simán Intel i5-10400-at, vagy i5-11400-at vennék, 6 mag, 12 szál, iGPU, hozzá 2×8 giga DDR4 RAM. Sima ATX, semmi ITX meg passzív, meg egyebek, készleten is van szinte mindenhol, ajánlott fogyasztói árnál nem sokkal magasabban. Ennek van most a legjobb ár/értékaránya, mármint az olyanok közül, ami jövőtálló is. Bár egy Ryzen 1600-3600 se rossz vétel egy olcsó B450-es lappal, csak ugye azt ki is kell fogni, hogy legyen valahol normális áron készleten, és annak alacsonyabb az IPC-je, és ahhoz kell dedikált GPU is. Később meg beledobnék GPU-t, ha lement az ára, vagy most egy 750Ti vagy hasonló alap kártyát (bár az linuxozáshoz nem a legjobb, mivel NV), AMD RX560, vagy ilyesmi, aminek nem szabadult úgy el az ára. Én nem vagyok márkahívő, simán azt veszem, ami a legjobb vétel, és van benne annyi időtállóság, hogy később se kelljen kidobni, meg sztenderd alkatrészekkel lehessen bővíteni. Egyedül GPU-ból szoktam lehetőleg AMD-hez ragaszkodni, de ott sem márkahűségből, hanem Linuxon ahhoz a legjobbak a GPU driverek összességében, és nem kell zárt driverrel szórakozni, ahogy NV kártyák esetén. De laptopnál elmegy most az Intel IGP is, a legújabb Xe UDH 730-750 nem is annyira rossz, felért az AMD Vega 3-8-10 szintjére, teljesítményben legalábbis, de driverben sem annyival rosszabb.
-
Frawly
veterán
Ja, mondtam én, hogy nem nehéz. Sok felhasználó azért fél tőle, mert nem érti hogyan működik, meg ilyen Buguntu telepítő összegányolja neki automatán nem működőre, vagy mint ubyegon, hogy kifogtak nem szabványos UEFI implementációs gépet, ahol az UEFI boot Windows only-ra van bedrótozva. Persze ez utóbbit is meg lehet oldani, csak nem olvasnak utána. Ebből meg az a mítosz alakul ki, hogy az UEFI boot szar, meg nem működik, meg lehetetlen, meg így meg úgy.
#8075 sati: a DE-k nem nyúlnak a default shellhez. Ő állította át a user accountban. Én is átállóban vagyok, a /bin/sh symlinket lecseréltem /bin/bash-ról /bin/dash-ra. De ez a scriptshellt cseréli le. A dash egy minimalistább, gyorsabb shell, ami jobban POSIX szabványos, szemben a Bash-sal. Pár héten belül a Bash interaktív shellt is lecserélem zsh-re. Meg a dwm-bspwm váltás is sok hete csúszik. Pulseaudio-Pipewire váltás meg egy hete volt meg.
A váltás nem megy azonnal, mert zsh alatt is ki kell kísérletezni beálításokat, pl. vi-mód, prompt csere, autokiegészítés, stb.. Persze mindezt oh-my-zsh nélkül, saját kútfőből. Az oh-my-zsh lényegében csak egy pluginmanager, ami a zsh-be tud felhasználói scripteket és beállításokat importálni. De ilyeneket kézzel is tudsz magadnak írni a zshrc-be, nem kell hozzá külön bloatot feltenni.
Gépösszerakósdival csak annyiból nem jó várni, hogy ha magyarban vetted, helyi boltban, akkor főleg célszerű 3 napon belül összerakni, hogy ha valami nem működik, hibás, akkor 3 napon belül visszajuttatva azonnal cserélniük kell, nem ülhetnek rajta 15-30 napig ilyen-olyan bevizsgálás, javítás, stb. címén. De ha online vetted is, akkori is meg 14 vagy mennyi napon belül érdemes megejteni, hogy ha hibás, el tudj állni a vételtől.
-
Frawly
veterán
válasz
attilav2
#8071
üzenetére
Elég ritkán történik meg, ahogy nézem, gyorsan helyre is hozták. Nyilván ők is emberek, korlátozott erőforrásból (saját pénz, adományok, nonprofit működés) nem tudnak egész szerverparkokat és adatcentereket ballancerrel megoldani, előfordul, hogy az az egyetlen szerveren lerohad valami, csak az nem hibázik, aki nem dolgozik. Ilyenkor visszanézel később. Semmit nem lehet ellene tenni.
-
Frawly
veterán
Ó, bazz, elfelejtettem előtte topikot váltani, nem ide akartam. Benéztem melyik topikba megy. Most már mindegy, itt hagyom, nem írom át az OFF-ba is. Gondoltam megindulhatna egy disztrófüggetlen eszmecsere róla, de így már mindegy.
#8069 attilav2: igen, BT-vel lehetnek bajok. Igaz az Pulseaudio-val is problémás. Semmit nem konfiguráltam, Arch Wiki ajánlására benyomattam a pacman -S pipewire pipewire-pulse pipewire-alsa parancsot, erre engedélyt kért, hogy leszedje a pulseaudio-t. Telepítés után reboot és minden ment. Nem kellett hozzá semmit konfigurálni. Igaz a DAC-om még nem próbáltam ki rajta, minden más egyelőre úgy tűnik megy, böngésző, lejátszóprogramok, játékok, egyelőre nem futottam semmi hibába. Még a pulsemixer és pamixer is épp úgy működik. A HUP-on már régóta ajánlgatják, de eddig nem mertem feltenni, mert nem volt időm, hogy ha nincs hang, akkor újabb problémát kelljen megoldani. A másik gépemen egyébként fent volt a Pipewire, Archon és Artixon is, de azokon a Pulseadio mellett, nem helyett üzemelt, ami azért elég lényeges különbség.
-
Frawly
veterán
Némileg OFF-beli OFF, de átlőttem Archon a Pulseaudio-t Pipewire-re. Minden működik továbbra is. RAM fogyasztás nem változott, de a CPU terhelés lement kb. felére. Eddig tetszik, de még nem tudtam kellően tesztelni.
Azért nem az Arch topikba írom, mert nem archosokat is érdekelhet, illetve sem nem kezdő, sem nem haladó téma. Egyszerű ajánlás.
-
Frawly
veterán
Csinálj UEFI-t. Jobb, gyorsabb, egyszerűbb. Arch Wiki systemd-boot szócikkét nézd.
Az UEFI boothoz csak 1 extra partíció kell, de még ez se extra, mert egyben a /boot szerepét is betölti. Egy kb. 100 megás, vagy kicsivel nagyobb FAT32 partíció, mindenképp 1 giga alatt adj meg neki méretet, Archnak nem kell sok hely, ha lesz mellette más OS is, akkor viszont nem árthat 200 mega felett adni, akár 500-ig is. A típusa mindegy is, de „EFI System” típus szokott lenni, és FAT32-re kell formázni, és így kell telepítéskor felcsatolni /boot-ként. Annyi, hogy UEFI bootnál a partíciós tábla ne dos/MBR legyen hanem GPT.
Lényegében az egész systemd-boot telepítése csak egyetlen bootctl install parancs. Meg az EFI partíción két .conf fájl szerkesztése kézzel, amibe megadod neki a bootmenü opcióit, és a kernelparamétereket, initramfs nevét. De cserébe se GRUB, se semmilyen nyomorékság nem kell hozzá, később nem törnek el ilyen hülyeségek.
UEFI BIOS-ban sem kell általában állítani semmit, a legtöbb gépen a deafult az UEFI boot vagy UEFI + Legacy BIOS boot. Bár én azért meggyőződnék, hogy a bootopció UEFI only boot-on legyen, az a legtisztább, nehogy elkezdjen az Arch iso mégis Legacy BIOS módban bootolni.
Az UEFI boot egyébként sok mindenben megegyezik a Legacy BIOS boottal. Annyi a változás, hogy az OS-ek a bootkódjukat többé nem a lemez 0. szektorába, az MBR-be teszik bele, hanem a FAT32-es EFI partícióra teszik .EFI fájlok formájában. Így több OS megfér egymás mellett kulturáltan, és nem írják felül egymás bootszektorát, és emiatt többé az OS-ek telepítési sorrendje is mindegy lesz. Az UEFI BIOS meg tudja kezelni ezeket az .EFI fájlokat, indítani. Ennyi a lényege tömören.
De az UEFI bootnak van egy csomó előnye. GPT partíciós táblával megy, amiben csak sima (nem göcsörtös) partíciók vannak, nincs vergődés többé ilyen elsődleges, kiterjesztett, logikai partíciókkal, nem kell bootflagekkel szórakozni, nem kell külön bootmanagert telepíteni (hiszen az UEFI BIOS egyben már bootmanager is, és tudja menedzselni neked az általa detektált EFI partíciókon lévő .EFI fájlokat).
Plusz az UEFI bootnak előnye lehet, hogy a gép az OS betöltése előtti eszközinicializálási időt lerövidítheti. Nem minden gépen, de néhányon ez lehet a helyzet. Hiszen ha nem hagyományos BIOS módban bootol, akkor nem végez el egy csomó, visszafelé kompatibilitás miatt benne hagyott hagyományos BIOS POST eszköztesztet, és kihagyva ezeket a sallangokat gyorsabban eljuthat a gép az OS betöltőjéig.
Meg most már így 2021-ben nem célszerű MBR Legacy BIOS bootot erőltetni, hacsak nincs annyira szükség az adott gépen, hogy valami legacy OS-t futtass, DOS, Win9x, XP, vagy hasonló.
A másik előnye az UEFI bootnak, hogy pl. Archnál csak egyszer kell megcsinálni. Utána megmarad, esetleges újratelepítésnél már hozzá se kell nyúlni az EFI partícióhoz, simán bootol majd vele az új telepítésű rendszer is, főleg, ha PARTUUID-kel hivatkoztál a root partícióra és nem particináltál újra. Ez jelentős kényelem a hagyományos MBR-es boottal szemben. Illetve előny, hogy ha nem is bootolna a rendszer egyszer, akkor is könnyű megjavítani, mert a FAT32-es partíciót minden OS olvassa, írja és csak szöveges config fájlokat kell a sytemd-boothoz szerkesztened, emiatt nem kell speciális Live rendszert, meg GRUB javítókonzolt beizzítani, hanem bármivel megjavíthatod a dolgokat. Ez se elhanyagolható.
-
Frawly
veterán
válasz
Apollyon
#8058
üzenetére
Máris nem időtálló, vagyis persze, nem avult el, de ha annak idején vette volna azt, amit írtam, azt most minimális pénzből upgrade-elhette volna egy 5600X-re, vagy 5800-ra, ami főleg az egy szálas ereje alapján köröket fut az 1. genes Threadripper köré. Ezt csak példának írtam, hogy a papíron brutális hardverre pénzégetés nem mindig a legjobb dolog, akkor se, ha van pénzed. Meg igazából a prémium hardver sose érte meg, mert nem volt jó az ár/értékaránya. Kicsi többletteljesítményért és presztízsbeli előrelépésért aránytalan felárat kellett mindig is fizetni, magyarán nem a teljesítményt meg nem az időtállóságot fizeted meg, csak a prémium életérzést, hogy elmondhasd, hogy neked az aktuális leg-leg van meg.
Attól is függ, hogy mire használja valaki. Mert az a 1920-as Threadripper amúgy erősebb, mint egy akárhány genes közép-Ryzen. De csak akkor, ha olyan felhasználásod van, hogy a magokat mindet kihajtod általában, meg hasznosul a sok cache is, pl. server/workstation-szerű felhasználásnál. Ha csak ilyen átlag user desktop és youtuber felhasználás, meg némi gaming, ott inkább az számít, hogy legyen 4-6 mag és egy magon legyen erős.
Míg ha SSD-be vagy jobb monitorba fektetett volna, akkor az mindenképp hasznosul, több tárhelye lett volna videókat vágni, VM-ezni, meg a több pixel jobb képminőséget, jobb olvashatóságot adott volna neki.
De billentyűzeteknél is ezt játszotta a koma. 400 dolláros, spéci, ergononomikusan osztott mechanikus billentyűzetből már a másodikat vette nemrég. Míg egy sztenderd, normál ANSI kiosztású 100-150 dolláros, jobbfajta kapcsolós mechanikus billentyűzettel jobban járhatott volna, de nyilván olyat nem vett, mert olyan csak a proliknak van, és nem prémium, ergo „égő”.
A másik oldalon meg van a fószernek egy erőforrásokkal feleslegesen spórolós mániája is. Nyitja a VM-et, erre büszkén mondja, hogy 2 szál, 4 giga memóriát adott neki. Közben meg a többi 20-22 szál, meg a többi ~55 giga memória ott áll üresen, de nyilván nem lehet a VM-nek többet adni, mert az milyen lenne már, hogy a megvett hardver lenne valamire használva, rárúgná az ajtót a helyi kommandós osztag.
-
Frawly
veterán
válasz
Shyciii
#8056
üzenetére
Azért szerintem a 8 ajánlottabb. Nagyon keservesen, de beleférnék én is a 4-be, de akkor a rendszerhez swapot kell tartani, meg én rendszeresen vagyok 3 giga felett, és akkor már gyakran elkezdené használni a swapot is. 8-nál is kell még a swap, de akkor szinte csak nagyon ritkán nyúl hozzá. 16 gigánál meg átlagosabb desktop felhasználásnál teljesen elhagyható a swap.
Egyébként igen, nekem is ment le az idők folyamán a memóriaigényem, eleinte KDE-vel meg Cinnamonnal kezdtem, meg egy időben Chrome-ot is használtam. De aztán ahogy lett előbb mindenféle kisebb DE, majd WM-ek, Openbox, i3, Sway, dwm, egyre inkább ment lefelé. De ehhez nem csak a WM-ek járultak hozzá, hanem ahogy telt az idő, egyre inkább több programom terminálos lett. Régen pl. használtam LibreOffice-t, GUI-s text edittort, torrent, stb., ezeket fokozatosan kiváltottam terminálos megoldásokkal.
Ennek ellenére a memóriafogyasztásra figyelek. Minden gépemben 16 giga van (bár két laptopnál levesz belőle az integrált GPU is), és általában a nagy része üres, de mégis figyelek erre, mert elsősorban innen mérni le, ha valami megoldás bloat. Ha sok memóriát eszik, és nem azért, mert nem férne bele, de amelyik progi sok memóriát használ, annak a szutykainak a betöltögetésével a procinak is időznie kell, többletfeladata van, sanszosabb, hogy más I/O műveleteket (lemez) is jobban igényel akkor, az meg növeli a reagálási időket, pár ms itt, pár amott. Hiába bika a proci, javarészt egy szálon töltődnek ezek a szutykok.
Ez nagyon szépen tapintható a két véglettel. Egy KDE pl. 8-9 mp. alatt tölt be SSD-vel is. Ugyanez egy minimalista WM-mel, konzolos bejelentkezéssel harmada, majdnem negyede is lehet időben. És nem a gép lesz gyorsabb, egyszerűen csak kevesebb mindent kell a procinak betöltögetni, kevesebb utasítást kell végrehajtania, kevesebb minden olvasódik be háttértárról, és a sok kicsi meg összeadódik. De ugyanez van betöltési időknél egy terminálos progi betöltődése még ms-ben sem nagyon mérhető, míg egy nagyobb GUI-s alkalmazás, ami ugyanazt csinálja, azért több msec vagy akár majdnem másodpercben is mérhető késéssel töltődhet be. Azért nagyon nem mindegy, hogy valami azonnal vágódik a képernyőre, még az embernek a billentyűt sincs ideje felengedni, vagy van-e egy kis töltögetés.
Persze a másik végletre is figyelni kell, mikor valaki pótcselekvésből túl sok RAM-ot vesz. Pl. a DistroTube csatornán az amerikai faszi, eleve 32 giga RAM-mal vette a mostani gépét, abból is általában 20+ giga állandóan kihasználatlanul állt, mivel minimalista tiling WM, terminálos alkalmazások, kevés grafikus progi (böngésző, OBS felvétel 1080p-ben, KDEnlive videóvágás 1080p-ben, néha 1 szál VM). Erre pár hónapja bővítette 64 gigára. Nyilván semmi nem lett gyorsabb, most már 20-30 giga helyett 52-62 giga áll üresen. Ráadásul ez az a mennyiség, amit már a kernel cache-elésre se használ el, ez ilyen abszolút pocsékolás, pénzégetés, pótcselekvés, e-pénisznövelés.
De ugyanezt játszotta el a procival is. 12 magos, 24 szálas Threadripper 1920-ast vett, amihez drága, spéci alaplap is kell. Elégette rá az értelmetlenül sok pénzt anno, mikor megjelent. Közben meg egy 1600-2600-as Ryzennel (plusz egy normális B450-es AM4 alaplappal), simán jobban járt volna, az is 6 mag, 12 szál, bőven elegendő lett volna neki, de még akár gyorsabb is lett volna, mivel egy mag magasabb órajelre turbózik fel (hiszen egy magra több Watt energiakeret jut). De ha 6 mag nem elég, egy Ryzen 2700X (akkor még nem jelent meg a 3xxx/5xxx sorozat) mindenképp már sok lett volna neki, de a proci-lap csak töredékébe került volna. Ugyanígy, 32 helyett vett volna 16 gigát, azért ezen a szinten nagy különbségek vannak. Ezt megfejelte Radeon VII workstation kártyával, amit megint nem használ ki, néha napján játszik csak, akkor is 1080p-ben. Akkor már jobban járt volna egy jóval olcsóbb RX5700-zal, felébe sem került akkor, játékokban talán még kicsivel több fps-t is kapna. Ez az, hogy az overkill hardvernek a legtöbbször nincs értelme. A többletpénzt meg beletehette volna több/nagyobb SSD-be, akárhány TB-ba, vagy lecserélhette volna a 3 darab FullHD monitorját 4K-ra, vagy vett volna még jobb kamerát, az értelmesebb pénzköltés lett volna, ha már a pénz mindenképp égette a zsebét.
-
Frawly
veterán
válasz
Archttila
#8054
üzenetére
Nem kell figyelni semmilyen sorrendre. Ugyanazon EFI partíciót használják, sőt, az azon lévő .EFI fájlokat is tudják közösen használni, ha az adott disztrók mindegyike támogatja a systemd-bootot. Annyi, hogy a közösen használt /boot/loader/*/*.conf fájlokba hozzá kell adni a másik rendszer kernelbetöltő sorát, paraméterestől, root partícióstól, stb. és simán bootolnak.
Ez a jó az UEFI bootban, hogy azonos EFI partíciót használnak, legfeljebb különöbző .EFI fájlokat, amik megférnek egymás mellett. Mert MBR Legacy BIOS bootnál az volt, hogy átírogatták az OS-ek egymás alatt az MBR-t, így számított a sorrend.
-
Frawly
veterán
válasz
Archttila
#8049
üzenetére
A retró játékokat jellemzően elég jól futtatja a Wine. Amelyiket mégse, arra natív Windows telepítést tarts. virtuális gépben sose lesz az igaz, meg lehet GPU passthrough-val szórakozni.
8 giga arra, amit írsz, elég, de a 2×8 nem sokkal drágább, és időtállóbb. Ha nem is használod ki, akkor is a kernel befogja cache-elni, befoghatod ramdrive-nak, böngészőcache-nek, így pocsékba nem megy, meg legalább akkor a swap-ot is teljesen mellőzheted.
A 8 giga attól is függ, hogy integrált vagy dedikált GPU-t használnál (ami a RAM-ból foglal le magának).
#8050 Apollyon: a SwayWM kevesebbet fogyaszt, mint az i3 és a dwm, de nem a WM része miatt, hanem mivel Wayland, ezért nem futtat komplett X.org servert, hanem csak egyes programokhoz XWayland emulációt. Illetve Wayland alatt nekem ugyanolyan problémátlan volt a Wine, Steam, mint X.org alatt.
-
Frawly
veterán
válasz
attilav2
#8046
üzenetére
Valahol már minden modern initrendszer kicsit systemd-szerű lett, mindegyik támogat párhuzamos service-indítást, service-függőségkezelést, eseményekre reagálást.
dhcp service-nek gondolom vannak kapcsolói, hogy kiírja mit csinál. Szerintem hosszabb távon jó, ha nem írja, nem hányja tele a képernyőt szeméttel, meg kicsit gyorsabban is fut.
-
Frawly
veterán
-
Frawly
veterán
válasz
attilav2
#8042
üzenetére
Az OpenRC-vel nekem vegyesek a tapasztalataim. Gentoo alatt bejött, Artix alatt hagyott kívánni valót maga után, de azért használható volt.
Amúgy isten hozott a minimalistább WM-ek világában. Igen itt minden kényelmi funkcióért küzdeni kell. De csak először, amíg meg nem érted mi kell hozzá, meg el nem mented azt a néhány .xml meg .conf fájlt a home-ból, .config mappából, utána elég csak azokat visszahúzni minden gépen, minden újratelepítésnél és meg fogod látni hogy így a fájlokat visszamásolva az egész sokkal gyorsabban újra bekonfigurálható, újra belakható, sokkal részletesebben testre szabhatóbb, mint a KDE valaha is volt/lesz, nem kell egyenként minden grafikus szarban hatodik fül eldugott menüjének akármijére kattintgatni végig, mire minden be lesz állítva. Az már csak hab a tortán, hogy mennyivel gyorsabb vele a gép, szemének alig hisz az ember, hogy a grafikus felület milyen gyorsan bevillan.
Azzal is egyetértek, hogy az Artix dokumentációja elég gyér, bár ők ezt úgy gondolják, ha valamit nem találsz benne, akkor az Arch Wikit olvassad. De a Gentoo Wiki is hasznos, meg tapasztalatom szerint a Debian Wiki is, utóbbi főleg a Wi-Fi driverek kinyomozásához, de vannak még benne egyéb jó dolgok, amik a többi Wiki-ben nincsenek benne.
-
Frawly
veterán
válasz
attilav2
#8040
üzenetére
Elvileg a cryptsetup defaultjai megbízhatók. AES256, XTS, meg valami min. 2048 bites hash.
Bitlocker megint olyan, hogy zárt forráskód. Próbálhatod helyette a VeraCrypt-et, az TrueCrypt formátumú konténereket és partíciótitkosítást tud, és azt el tudja olvasni írhatóra a LUKS.
A cryptsetup alapból nem titkosítja le az egész meghajtót, hanem csak headert ír fel, meg egy két adatot és csak annyit titkosít. A jövőben rákerülő adatok viszont titkosítva lesznek. Ennek ellenére cryptsetup után ajánlanak egy teljes dd if=/dev/rand parancsos végigírást, de szerintem ez nem szűkséges, majd ahogy telíted be a meghajtót, partíciót, majd titkosodik az egész adatterület.
-
Frawly
veterán
válasz
attilav2
#8038
üzenetére
Így van, ezeket teljesen jól foglaltad össze. Ha nem támogatja a BIOS, attól még használhatod, de bootkor, egy másik rendszer alól kell kinyitni hdparm-mal. Nyilván, így bootolni nem lehet róla, csak adattárnak használni.
Másrészt meg valóban, nagyon kell figyelni, hogy jól jelszavazd le, és ne felejtsd el a jelszót, mert a hardveres titkosítás nem csak az adataidat, hanem az SSD-t is védi lopás esetére, és ha nem tudod a jelszót, akkor reszeltek az egész drive-nak, nem lehet kinullázni, hekkelni, a gyártó sem tudja neked leoldani a titkosítást. Pontosan, ahogy írod, mehet a kukába. De ez téged véd, mert ha valaki megfújja a gépet, SSD-t, akkor hiába is próbálja elpasszolni, téglásítva lesz az egész SSD, se újraformázni, se semmit csinálni nem lehet vele. Jó, nagyon kevés kivétel van, mikor valami BIOS-os jelszavazási gyengeség (pl. üresen hagyja az admin jelszót, és az csak user ATA passwordot állítja, vagy az admin jelszót a gép sorozatszáma alapján generálja ismert algoritmussal, de ez ritka, gyártók kerülik).
A LUKS ezzel szemben törölhető, ha el is felejtetted a jelszót, csak az adatokat bukod róla, a drive bármikor leformázható. Meg a LUKS megbízhatóbb is, mivel opensource és auditált, így biztos lehetsz benne, hogy se NSA hátsó ajtó, se implementálási gyengeség nincs benne hagyva. Ha betartod a cryptsetupos ajánlásokat, akkor bombabiztos a LUKS, se az FBI, se a CIA ki nem nyitja a rohadt büdös életben, hacsak nem tudnak valahonnan szerválni egy qvantumszuperszámítógépet, ami bruteforce-szal belátható időn belül törni tudja.
-
Frawly
veterán
válasz
attilav2
#8036
üzenetére
A crypttabot azért nem tudom, mert ugyan használtam LUKS-ot már, de nem SSD-vel, hanem HDD-vel, és ott nem kellett TRIM-mel, discard-dal szórakozni.
Egyébként én még mindig amondó vagyok, ha SSD-id vannak, akkor az azokba beépített hardveres titkosítást használd. Neked is könnyebb, mert gép bekapcsolásakor a BIOS bekéri a meghajtók ATA jelszavát, onnantól kinyílik a titkosításuk, és a továbbiakban minden szoftver, OS, akármi úgy érzékeli, hogy titkosítatlan meghajtóra dolgoznak, közben meg titkosítás alatt van, de hardveresen, transzparensen.
-
Frawly
veterán
válasz
attilav2
#8031
üzenetére
Az Arch Wiki ajánlja még a rd.luks.options=discard kernelparamétert is, ahogy a screenshoton is látszik. Ezen túlmenően a crypttab-ba és az fstab-ba is kell a discard paraméter, ha az SSD-n lévő fájlrendszer támogatja, ha nem támogatja, akkor meg fstrim-et kell helyette ütemezni.
Egyébként az SSD-k nem szeretik a szoftveres titkosítást, mert az teleírja őket, és nem látják, hogy mi a hasznos adat, mi nem. Ezen a TRIM egy kicsit tompít, de az SSD-knek nem nagy barátja az egész lemezes szoftveres titkosítás.
Ezzel a linkeden azért nem foglalkoztak, mert ott NVMe SSD-t használtak, azon meg máshogy van megoldva a TRIM-nek megfelelő opció, hardveresen, így nem kell ezzel szórakozni.
Azért is támogat több SSD is hardveres öntitkosítást, közöttük a 860QVO is támogatja az AES-256-ot. De! Ehhez olyan alaplap kell, ami van TPM 2.0 chip, és a BIOS is támogatja az ATA jelszót. Az a baj, hogy a legtöbb konzumer gép nem támogatja, csak céges notik, céges desktop, thin client, workstation, server, stb.. Nem is értem, hogy a konzumer lapokról ezen mit spórolnak le, mert nem valami drága megoldás. Persze elméletben lehet úgy is használni, hogy az alaplap nem támogatja, hanem boot után te nyitod ki hdparm segítségével, de ilyenkor meg nem lehet róla bootolni. Csakis ATA, SATA, AHCI SSD-knél fontos ez..
-
Frawly
veterán
válasz
attilav2
#8028
üzenetére
Persze, hogy működik. Ez egy teljesen sztenderd telepítés, annyi benne a csavar, hogy cryptsetup-pal letitkosította a második partíciót, és arra telepítette a rendszert. Illetve a systemd-boot menüjében hozzáadott egy extra sort: options cryptdevice=PARTUUID=bla-bla... Illetve, ha tudod így telepíteni, akkor ennél kell maradni, és hagyni a GRUB-ot.
Amire még figyelj, hogy ha SATA SSD-ről van szó, akkor a TRIM átengedéséről a LUKS rétegén gondoskodni kell. NVMe SSD-nél (amilyen a leírásban is van), meg HDD-nél nem kell ilyen.
Vim az hasznos, de nem kötelező azt használni konzolban sem. Bármit felrakhatsz magadnak, leginkább a micro nevű text editort ajánlom, de van helyette egy csomó másik: ne, e3, ee, nano, tilde, mcedit, emacs, uemacs, vagy amit akarsz. Van egy rakat, közülük egy csomó „hagyományosabb” a vim-nél. Régen a base csomag része volt a vi, de már nem az. De szerintem a vim a legjobb az összes közül, főleg, ha tud valaki gépírni. Illetve az Emacs is nagyon jó, de azt sem sokkal könnyebb megtanulni, mint a vim-et.
-
Frawly
veterán
válasz
Archttila
#8026
üzenetére
Lehet használni többfélét is, és akkor a pacman sorrendben végigpróbálja őket, ha nem elérhető az elsőként szereplő szerver, akkor próbálja tölteni a másodikról. A rollingnak ez hátránya, hogy gyakran frissül, sok csomag, és nagyon le kell követnie a mirrornak is a sok apró változást, ha egy-két csomag nem frissül, dőlhet a függőségi sor, mint a dominóknál. Ez egy lassabban frissülő, kiadás alapú disztrónál (Debian, Ubuntu, Red Hat vonala) nem olyan nagy gond, de elméletileg ott is előfordulhat.
-
Frawly
veterán
Én mondanám, hogy megmondtam, és mondom is. Talán nincs még 2 hete, hogy valaki az Linux OFF topikban jelezte, hogy gondja van a Void magyar mirrorjával. Erre írtam, hogy ez a baj a kicsi disztrókkal, nem sok mirror, de még nagy disztrónál, mint az Arch, ott sem mindegy, hogy mely mirrorokat használja az ember, és nem csak letöltési sebesség miatt, hanem a tier1 mirrorokhoz képest történő syncállapot miatt, amibe itt most ti is belefutottatok. Épp ezért nem csak pinget meg nyers letöltési sebességet kell nézni, hanem pl. készenléti időt (szerverkimaradás), sync-frissességet. A német szerverek általában jobbak ebben, mint a magyar. Az archlinux.org-on lévő mirrorösszeállítóval lehet nézelődni.
Egyébként nem is jártam messze a megoldástól az Syu-val, hogy nem volt teljesen lefrissülve, de ezek szerint nem user error, hanem mirror synclag miatt.
-
Frawly
veterán
Gummiboot tudtommal már nincs. Az a systemd-boot régi neve volt. De nem tömi tele a partíciót. Ennek ellenére nem írtam, hogy nekem sem volt még gondom a GRUB-bal, mikor még használtam. Egyszer volt, hogy nem bootolt, de akkor balfék Win7 update-je írta felül, nem Linux oldalán volt a hiba. Én csak azért nem használom a GRUB-ot, mert 1) feleslegesen nagy, bloat valami, 2) nincs rá szükségem. De ahogy olvasom a fórumokat, nagyon sok embernek eltörik, és rendszeren jönnek kérdésekkel, hogy nem bootol. Systemd-bootnál ilyet még nem hallottam, az is igaz, hogy annál lehet azért nem, mert aki olyat használ, az ért hozzá, és jól rakja fel magának. Na, meg sokkal egyszerűbb is, csak egy szál .EFI fájl, meg két darab plain text .conf fájl, az egész egy pirinyó megoldás.
De elvileg az EFI stub boot még elegánsabb, ott semmilyen bootmanager nincs (az UEFI már önmagában is egy bootmanager), ott a kernel bootol közvetlenül EFI binárisként. Ennek viszont van 1-2 hátránya, néhány nem annyira szabványos alaplap UEFI-je nincs vele kibékülve, meg ha pl. hirtelen átszerkesztett paraméterekkel kell hívni a kernelt, akkor azt nem lehet egykönnyen kivitelezni.
GRUB csak akkor kell, ha valaki ZFS-ről, btrfs-ről, RAID-ről, egész lemezes szoftveres titkosításos megoldásról (esetleg LVM-ről), stb. akar bootolni. Akkor kell. De ezek nem az átlag felhasználói réteg, az simán titkosítatlan ext4 partíciókat használ, ahhoz nem kell. Még legacy BIOS bootnál sem, mert vannak nála soványabb, biztosabb megoldások, amik nem törnek el.
-
Frawly
veterán
válasz
Shyciii
#8009
üzenetére
A GRUB egy hulladék, az eltörik Ubuntun, Minten, meg mindenhol. Archnak előnye, hogy ott ki is kerülheted, ha nem teszed fel a GRUB-ot, akkor nem lesz mi eltörjön. Illetve, de, a rendszergazdának van erre ideje. Mert ez a munkája. Ha túl nehéz neki, elmegy szenet lapátolni, vagy munkanélkülinek.
Abban viszont egyetértek, hogy a Linux sem tökéletes. Az Arch sem. Ma már az OS-ek, böngészők kódbázisai olyan nagyok, hogy áttekinthetetlen kódméret, főleg, ha a csomagokat is hozzávesszük. Ráadásul egyre inkább rohannak a verziókkal. Nem csak a rolling, a Win10, fejlesztők, stb. is.
#8010 Sonja: nálam simán jó. Települ és működik az mc. Semmilyen PGP hiba nincs. Pedig semmilyen ilyen refresh-keys mókolást nem ejtettem meg.
Ilyenkor általában megéri egy pacman -Syu parancsot kiadni, mert az, ha van új keyring csomag, akkor azt is befrissíti, és utána menni fog az mc.
-
Frawly
veterán
válasz
Shyciii
#8005
üzenetére
Nekem még sose volt olyan, hogy egy Arch ne bootolt volna frissítés miatt. Soha!!! Volt, hogy frissítés tört el ugyan dolgokat, nagyon ritkán (kb 2 évente egyszer) 1-1 progi crachelt, meg produkált olyan bugot, amit workarounddal, csomag downgrade-del, stb. kellett megoldani (ilyenkor is megoldható pár perc alatt), de olyan sose fordult elő, hogy az egész rendszer enblock bootképtelen lett volna, meg rendszer nélkül maradtam volna akármikor is. Az is igaz, hogy nálam ez még Windowszal sem fordult elő, csak hogy 1-1 nem tetsző driver kékhalált okozott, de ilyenkor is elég volt egy csökkentett módú újraindítás, és a driver eltávolítása, vagy eszköz letiltása.
És itt azt kell érteni, hogy nem csak az Archot védem, meg istenítem, hanem igazából ez bármilyen disztróra igaz. Még talán BSD-kre is, ha a cég megtanulja magának megoldani, talál hozzá szakembert, akkor szinte bármilyen elterjedtebb modern OS-es ökoszisztémán el lehet lenni, annak bármelyik disztribúciójával.
-
Frawly
veterán
válasz
attilav2
#8003
üzenetére
Teljesen jó termelésirányításban, meg akármire is. Ezt már többször is írtam, hogy céges felhasználásra csak LTS az igaz volt régen, de már jó pár éve nem az.
Igazából a rollingságát is lehet tompítani az Archnak. Pl. nem frissíted olyan gyakran, meg helyi tárolót hozol létre, ahova csak olyan csomagot engedsz be, amit egy tesztgépen már teszteltél, a többi gép meg már csak ezeket húzhatja le. Ja, külön munka, de ha az egész cég archos ökosisztéma, csomó géppel, akkor simán megéri.
Inkább csak annyi, hogy általános ipari és céges felhasználásnál szerintem elveszik az Arch előnye, de hátránya se nagyon van. Igazából ízlés kérdése, hogy ki mit ismer, miben bízik, stb.. A legtöbb helyen nem azért van Red Hat alapú disztró, meg Ubuntu LTS, meg Debian, mert azok a legstabilabbak, hanem a legtöbb IT szakember azokat ismeri, így azokat vállalja be. Sokan csak egy Archot azért nem piszkálnának meg bottal sem, mert nem ismerik, nem szokták még meg, és úgy vannak vele, hogy éles környezetben nem fognak elkezdeni tanulgatni. De ez nem jelenti azt, hogy éles környezetben ne lenne bevethető.
Félig a lustaság is benne van. Az informatikus nem szeret dolgozni, minek frissítgessen állandóan Archot, ha egyszer egy CentOS-nél meg elmegy, hogy évente egyszer frissíti, és 10 évig nem kell komolyabban hozzányúlnia. Az LTS meg a miegymás ezt a lustaságot is kiszolgálja. Szintén a lustaságot van hivatva segíteni, hogy a nagy céges corporate disztrókra supportot is tudsz venni, ami ugye nem szükséges, de sok cégnél kényelmes, hogy ha gond van valamivel, akkor nem neked kell megcsinálni, hanem lehet a megoldásért más hátát verni, meg mindig mástól várni a megoldást.
Sőt, tovább megyek, a legtöbb helyen azért van Windows onlyság is, mert azt biztosan ismerik, van vele belső tapasztalat, ahhoz mindig találni szakembert is, mert Dunát lehet velük rekeszteni, van hozzá support. Nem azért használják, mert stabilabb meg jobb lenne.
-
Frawly
veterán
válasz
attilav2
#8001
üzenetére
Az efistub nagy királyság, annak a lényege, hogy a kernel közvetlenül .EFI binárisként bootol, nincs semmilyen bootmaganer (az UEFI egymagában is egy bootmanager). De az efistub-ot nem támogatja sok nem szabványos gyártói UEFI, meg ha initramfs, titkosítás, stb. van, akkor vagy nehézkes lehet, vagy lehetetlen.
Én systemd nélküli disztrókon lehetőleg efistub bootot használok, systemd-s disztrókon systemd-bootot, mert az is még kellően egyszerű. GRUB-ot csak akkor tennék fel, ha valami RAID-ről, egzotikus partíciótípusról, spéci titkosítós mókáról kell bootolni, vagy MBR Legacy bootkor (bár akkor is hajlanék valami egyszerűbb bootmanager felé).
-
Frawly
veterán
válasz
attilav2
#7993
üzenetére
Kiegészítés: egyébként nem haszontalan, mert ha legközelebb egy gépre valami gyors disztrót akarok feltenni, az már lehet nem Mint vagy Xubuntu vagy hasonló lesz, hanem ilyen archinstall scriptes vanilla Arch. Tehát ez haladóknak is jó lehet, ha gyorsítani akarnak a telepítésen. Mert sokszor telepít az ember egy 1-2× használatos, eldobható rendszert, ami gyorsan kell valami alapon kerül fel, arra az esetre kiváló. Tehát mint írtam, nem vagyok ellene. És ahogy a Phoronixon olvasom, ez ne is automatizálva lesz az Arch telepítőn, hanem egy parancs formájában kell behívni, ergo aki akarja, használja, aki nem akarja, annak továbbra is lehet hagyományos kézi módszerrel Archot telepíteni. Így tőlem elfér.
Meg azoknak is emberkéknek is jó lehet, akik már majdnem ott vannak azon a szinten, hogy Archot használjanak, de eddig valami nem ment a kézi wiki-s telepítésnél, és állandóan feladták, de már kevés hiányzik nekik, őket átsegítheti ezen a ponton egy extra lökést adva. Így már nem lesz visszatartó erő, hogy jajj, nincs installer, meg nem kell gyanús, gányolós, 3rd party installer scriptek beszerzésével és működésképtelenségével vergődni.
-
Frawly
veterán
válasz
attilav2
#7993
üzenetére
Ez még nem bloatosodás, csak épp értelme nincs. Az Archnak szándékosan nincs telepítője, hogy ne találja ki a user helyett, hogy mi kell neki. Persze, eddig is voltak 3rd party telepítőscriptek, de azokkal az Arch értelme lett lehúzva a klotyón, meg sok láma összealkot vele ilyen gányolt telepítést, aztán jönnek az archos topikokba, mert nem érik hogy működik, mi van telepítve, mi mi miatt nem jó. Mert ha te telepíted kézzel a Wiki alapján, akkor a parancskimenetekből látod, ha valami nem jó. Ha egy installer csinálja helyetted, akkor nem látod.
Persze ettől még félpozitív hír is lehet, mert ha több user áll be az Arch mögé, akkor több csomag lesz rá, több tároló, jobban fejlődik. Inkább egy független Arch mögé álljanak be a userek, mint ilyen corporate bullshit Coninical, Red Hat, Süsü baromságok mögé. Szóval engem nem annyira zavar.
Annyiból viszont félnegatív hír, hogy ha sok windowsos meg ubuntus láma beáll mögé, akkor viszont az megindíthat nagyobb bloatosodást, csak azért, hogy őket kiszolgálják. Az meg nem lenne jó.
Egyébként én ha kezdőbbeknek kell Arch, Arco Linuxot szoktam ajánlani. Viszonylag egy normális belga faszi csinálja (Erik Dubois, még YouTube-csatornáján is közzétesz segítő videókat), vanilla Archot kap a user, ha feltelepíti (szemben a Manjaro-val, ami módosított tárolókat használ, meg le van maradva verziókkal), és általában még nem túl bloatak a lemezképek, default Archhoz elég közel vannak, nem kell túl sok sallangot elviselni a rendszeren. Az Arco Linux meg rendes telepítővel jön, azt hiszem Calamares. Így egy kezdőbb user is belekóstolhat a rollingba, meg a frissességbe. Vannak nagy DE-s és kisebb WM-es lemezképek is belőle.
-
Frawly
veterán
válasz
jimmy399
#7989
üzenetére
Továbbra is tartom, hogy ez valószínű nem kernelhiba, hanem az újabb kernelekhez kéne valami mágikus kernelparaméter. A HUP-on olvastam a bejegyzésed, hogy radeon driverrel hajtod mindkettőt és próbáltad amdgpu-val is, szóval mást nem nagyon lehet tenni. Azt már múltkor is beszéltük, hogy az xf86-video-ati és xf86-video-amdgpu drivereket is próbáltad X.org alatt. Mást nagyon nem lehet megpróbálni, csak a kernelparaméter marad, már ha tényleg nem kernel bug, ami azért meglehet, de nem találok semmit, ez jelentheti azt is, hogy más még nem jelezte.
Végső esetben egy CSM Legacy BIOS bootos telepítést is csinálhatsz, egy külső meghajtóra, hogy megnézd, hogy ha elsődleges kártyának használod az 5550-est, akkor a hibajelenség előfordul-e. Az ugyanis örökké nem maradhat, hogy emiatt sose frissítesz kernelt, mert előbb-utóbb nem úszod meg. Egy ideig lehet halogatni workaroundként, csak végleges megoldásnak nem jó. Azt is mondanám, hogy majd az 5.12-es kernel megoldja, de az véglegesként majd csak 3 hét múlva jön ki.
-
Frawly
veterán
válasz
jimmy399
#7986
üzenetére
Ezt szerintem X.org konfigban kéne beállítani, vagy valami xrandr-t használó sorral az xinitrc-be, hogy a default kártyát használja, amit te akarsz és kézilag egy általad megadott felbontás, frissítésre álljon be. A hibát valószínű az okozza, hogy a VGA csati analóg, nem jön át rajta a DDC jel a monitortól, hogy milyen felbontásokat támogat, így meg a X.org elkezd valamit defaultra állni, találgatás alapon és a monitor vagy kártya nem szereti, valami egzotikus frissítés miatt. Bár ezt a DVI-nak meg kéne oldania.
#7987 Shyciii: én sose hittem ezekben a spéci kernelekben. Lehet nyersz vele egy lényegtelen 1-2% futási többletteljesítményt, de egy csomó kompatibilititási szívás bugok árán. Egyszerűen az időt nem érik meg. Nem véletlen, hogy a hivatalos kernelben nincsenek benne ezek a csodapatchek, meg spéci ütemezők nem defaultok. Ha annyira jobb lenne, akkor Torvalds belereszelné ezeket defaultnak.
-
Frawly
veterán
válasz
attilav2
#7983
üzenetére
Itt el tudod érni a konfigom Openboxhoz. Egyben illesztettem be, az eleje a ~/.config/openbox/autostart script, a második bekezdéstől pedig a ~/.config/openbox/rc.xml.
Amiket használtam: picom kompozitor yshui forkja (ezt később dobtam), polybar panel, dmenu, xss-lock, synclient (Synaptic-kompatibilis touchpadhoz többujjas bindek), xbindkeys a multimédiagombokhoz, feh a háttérkép beállításához. Termite terminál, saját scriptek, képernyőkímélő asciiquarium teljes képernyős terminálban futtatva és transzparens i3lock-kal zárolva, képnézőnek imv, videók és audió lejátszsára mpv, pdf/ps/djvu nézésére Zathura, neovim szövegszerkesztésre, Vifm fájlkezelésre, csatolásra saját script, sok scriptem fzf-választót használ (az fzf ugyanolyan, mint a dmenu, de terminálban fut és rugalmasabban keres). De szinte minden megoldásom terminálos, pl. htop és hasonlók, majdnem mindent saját script végez, SSD infók kiírása, kézi fstrim, hangerő szabályozására pamixert használó script, vagy pulsemixer (amit látok te is használsz), torrentnek transmission-cli tremc terminálos klienssel vagy webes klienssel (böngésző), de mostanában btcli-vel kísérletezek helyette. Időjárás nézésére curl wttr.in. NTP-re ntpd, fényerőszabályozásra light, emellett redshift-script, screenshotozni scrot (Sway alatt grim), androidos teló csatolására jmtpfs script. Wi-Fi-hoz egyszerű wpa_supplicant + dhcpcd scripttel csatlakozok egy lépésben. Számológépnek calc (ez egy terminálos progi), illetve Python-értelmező. Login manager nincs, közvetlenül konzolban jelentkezek be, és bashrc-be az adott felhasználó/tty[szám] kombóhoz drótoztott WM indul el előre megadott xinit-scripttel.
A WM-ben a legtöbb progi Super+A-Za-z gombokra indul, speciális funkciók Super+1-9, Super+F1-F12, Alt-Tab, Alt F1-F12, PrnScr, stb. billentyűkre érek el funkciókat.
Egyébként most is ezeket használom kb., de dwm alatt, de a polybar helyett a dwm saját panelja megy egy dwmbar-script segítségével kiírva rá a doglokat, i3lock helyett alock, nem fut már kompozitor, médiagombokat is a dwm kezeli xbindkeys nélkül. Elkezdtem clipmenud-vel is kísérletezni, de ez nem jön be.
Mindenre próbálok vim-es kiosztást használni programon belül, minden mappára át tudod váltani közvetlenül fd + fzf kombót használó scripttel, minden doksim megnyitom fzf-es scripttel, 1-2 billetnyű lenyomása után ott van, akárhány almappa mélységben, az adott mappán, adott doksinál. Így 1-2 billentyű lenyomására gépírás módban ott van minden az ujjam alatt, az összes fontos program, mappa, doksi, azonnal nyílik, lag, betöltési idő nélkül, a billentyűt nincs időm felengedni, már a képernyőn van. Nincs grafikus tallózás, nincsenek ikonok, nincsen dokk, nincs tálcaapp, nincs egerezés, csak egész képernyős programok, gap, keret, fejléc, toolbar, menüsor, akármi nélkül. Tiling módba ritkán váltok, ha több mindent kell látni, vagy át kell tekinteni, hogy mi fut (a KDE érzékeny sarokmegoldása ihlette), ilyenkor az alap master-stack layoutot használom, ami default az összes tiling WM-ben. Nyilván ez Openboxnál nem játszik, de annak van saját taskváltó listája helyette.
Firefox a böngészőm, benne Tridactyl addon, ami vim-módban kezeli a böngészést, billentyűkkel, egeret így itt is alig használok (kivételesen igen, pl. a vim-es billentyűk miatt nem működne a YouTube-on a webes videólejátszó gyorsbillentyűi, így itt automatikusan kikapcsolódik a vim-mód, és egeret is használok, de nem is az egér a jó szó, hanem touchpad gesture-öket). Ténylegesen egeret csak akkor használok, ha FPS, TPS, szimulátor játékkal játszanék.
Kicsit külső szemmel figyelve olyasmi mikor a gépet használom, mintha MS-DOS-t használnék, billentyűzet, terminál, teljes képernyős szöveges progik, 0 betöltési idők. Alig-alig van grafikus progi, Firefox, Goldendict, 1-2 alkalmazás ritkán Wine-ban (pl. Scriptum GIB szótár), Steam, néhány játék (vegyesen natív linuxos, és windowsos Wine-ban).
De mégse DOS, mert nem legacy rendszer, hanem modern 64 bites, legújabb verziók, modern programok, ha valami régi is (pl. vim 90-ből, ami a 70-es évekbeli vi-ra megy vissza), annak is modern változatát használom (neovim), vagy kétpaneles fájlkezelő (ami a Norton Commanderre megy vissza, ehelyett Vifm, megint a vi/vim-mód miatt). Természetesen a minimalizmus miatt semmiről nem kell lemondanom, épp úgy fut minden GUI-s program, játék, médialejátszó, modern kódek, hardveres gyorsítás mindenféle kódekhez és grafikus API-hoz. Tehát nincs az, hogy hátrányt szenvednék akármiből. Nyilván, ha valami ritkább, GUI-s prorgamot indítok, az nincs az ujjam alatt, az dmenu-ből keresem ki, vagy fzf-script listázza (pl. játékok), de az is villámgyorsan nyitható, gyorsabban, mintha valaki ilyen hagyományos grafikus menüből tallózgatná ki egérrel.
De ahogy észrevettem, youtube-os linuxerek is hasonló rendszerrel dolgoznak, mind Arch vagy (ritkán) Gentoo alap, pálcika tiling WM, terminálos programok, neovim (vagy modern Emacs-disztró), fzf, dmenu, billentyűzet-only vezérlés. Nyilván azért nem ugyanaz a rendszer mindenkinél, mert más a WM (dwm, bspwm a legnépszerűbb, de előfordul minden más is), más a téma, más színek, betűtípus, más terminálemulátor (Alacritty és Termite a legnépszerűbb), más böngésző (most a linuxosok körében népszerűbb a Brave, mint a Firefox), más fájlkezelő (Vifm helyett vagy mellett lf, ranger, nnn, PCmanFM, Emacs dired), más screensaver (asciiquarium helyett pl. cmatrix vagy hasonló), stb., de a lényeg nem változik, hasonló rendszer, hasonló filozófiával. Nyilván két egyforma rendszer nincs, mert mindenkinek más szájíz diktálja a billentyűzetkombókat, amire drótoz, más progikat használ, más az ízlése, más a felbontása, monitormérete, billentyűzetkiosztása, hol laptop, hol asztali gép, hogy 1, hol 3 kijelző hol ergonomikus/osztott billentyűzet, hol másik kiosztás, stb.. Sok ötletet a youtube-osktól meg reddittről, unixpornról szedtem, sok megoldást ott láttam először, de nyilván ezeket már saját kútfőből is keresem, meg próbálom saját ötletekkel optimalizálni.
Egyébként nekem a Sway jött be eddig legjobban, de egyrészt mással is kísérletezni kell, nem ragadhatok le egy megoldásnál. Meg van 1-2 hiányossága is a Swaynak. Pl. teljes képernyős vagy floating módos programról nem tud átváltani a háttérben futó másikra, bár ez nem bug, hanem minden tiling WM-ben lévő feature, meg pl. nem mutat tasklistet, amikor alkalmazások között váltasz át, akár azonos monitor vagy workspace-re, akár nem, ez jó lenne bele, bár wrofi-val talán pótolható, de nem volt még türelmem megcsinálni. Vágólapkezelését is egységesíthetnék X-es és Waylandes alkalmazások között, ezt sati kolléga megoldotta clipman-nel.
A konfigom is mindig változik most fogok bspwm-re váltani, így megint lesz változás. Emiatt nem is szoktam a rendszerről mentést csinálni, csak az adatokról, adatfájlokról. Rendszermentés visszahúzásával nem is mennék semmire, ha egyszer a rendszer mindig változik.
-
Frawly
veterán
válasz
attilav2
#7981
üzenetére
Sway konfigom feltölhetem neked a pastebin-re, de sokra nem mennél vele, mert egy majdnem teljesen stock Sway config, amit elérsz a /etc/sway/config vagy /usr/share/doc/sway/ alatt.
A konfig egy része amúgy is az én felhasználásomra van, keybind-ek, pl. meg billkiosztás, egyes hardverek pollrate-je, ID-je, ezzekkel semmire nem mennél. Ráadásul én a Sway-t és az i3-at is tabbed layoutban használom szinte kizárólag, nem tilingban, semmi extra layout, semmi gap, semmi cicomázás, nincs ablakkeret, nincs fejléc, nincs semmi, szerintem a falnak mennél tőle. Tehát a Sway konfigom egyik része neked teljesen irreleváns lenne, a másik része meg teljesen default, az i3-as konfig meg már meg sincs.
De igen, ezt nem hitted el, hogy a minimalizmus nem csak gyenge hardveren kamatozik. Az egész futási teljesítmény, lagok hiánya, prociterhelés, stb. is egész más, más használni a gépet. Ezek a KDE szintű monstrumok annak lettek kitalálva, aki modern, erős hardveres használja, windowsos desktop mentalitással, és nem akar azon a szinten túllépni, hogy egérrel kattintgat ikonkra. De hogy ilyen cast, szerver, meg hasonló spécibb dolgokra is van használva, ott már kijön a tiling meg a minimalizmus rugalmassága, aki ehhez hozzászokott, már nem fog visszatérni hagyományos DE-kre, mert túl korlátosnak, lassúnak, rugalmatlannak fogja érezni.
-
Frawly
veterán
válasz
attilav2
#7979
üzenetére
VGA gyorsítást én ebben nem látok. A Firefoxot hagyd le, mert zavarja az adatok kiértékelését. Kicsivel több lett a fogyasztás, de nem annyival, mint vártam, talán mert nem fut 3D gyorsítás vagy nem tudom. Mondom, ez a mennyi az az annyi, azt akkor látod meg, ha fizikai gépre teszed fel, olyan rendszerre, amit tényleg használsz is napi szinten. Pl. egy 16 gigás pendrive-ra, vagy egy külső SSD-re vagy HDD-re.
Na meg ilyen virtuális gépen természetesen nem csak az Artix fogyaszt kevesebbet, de egy systemd-s Arch is. Ha már életszerűtlen környezetben hasonlítunk össze.
Egyébként Archon nálam még mindig fut két extra nyomorékság, amit sosincs időm kihekkelni, valami spi2 görcsség, meg polkit baromság, természetesen egyik se kéne, és sokat foglalnak. PulseAudio helyett lehetne apulse-t használni. picom kompozitort már régóta elhagytam, igaz így nincs árnyék meg átlátszóság, de nem sok különbség van szemre, vsync viszont épp így van. Háttérképnél is elértem, hogy a feh vagy xsetroot nem marad betötve, hanem kilép, miután lecserélte a hátteret. De még mindig érzem, hogy lehetne még mit minimalizálni a rendszeren, igaz már sokat nem nyerek vele, 1-2 folyamatot lehetne még megúszni, meg alig néhány MB memóriát lespórolni, de egy idő után az ember elég egy olyan minimalista korlátot, amit már nem lehet meghaladni, vagyis legalább úgy nem, hogy a rendszer általánosan használható desktop marad, ami mindenre használható.
Plusz nálam pl. olyanok is futnak, mint ntpd, amire nagy szükségem is van, mert ezen az új gépen hajlamos a gépóra sokat késni. A másik, régi laptopom meg asztali gépen ez nem jellemző, ott csak eseti jelleggel futtatnék NTP-t, de ezen a gépen hatványozottabban kell, meg ez a pontos idő nálam mánia is. Megint: hardverfüggő is.
Ez ilyen, ez egy folyamat, idő kell neki. A minimalizmus sose olyan, hogy meg lehet erőszakolni 5 perc alatt. Próbálkozni kell többször, új megoldásokat felfedezni, configokkal kísérletezni. Egy min. több éves utazás.
-
Frawly
veterán
válasz
attilav2
#7977
üzenetére
Na, látod, erről beszéltem. Ha feltennéd a VBox Guest Additions-t is, azaz a hozzá való KMS modulokat az Artix tárolóiból, meg belövöd rajta a hardveres gyorsítást, meg még nyitsz pár böngészőfület, és máris még jön rá jó pár mega. Azért is mondtam, hogy van egy gyakorlati minimum, amit figyelembe kell venni, és nem szabad ilyen kérdésben sem sznobságból túlzott, értelmetlen minimalizmusra törekedni, mert azért a hardvereket meg kell hajtani, kellenek a különböző gyorsítások, ha az ember tartalmat fogyaszt, böngészik, esetleg játszik, stb..
Mint írtam, gépfüggő is, mert vannak emberek, akinek a nyomtató miatt CUPS, szkenner miatt Sane modulok, PPP csatlakozó egyes hálózati kapcsolatokhoz, webkamera, ujjlenyomatolvasó, stb. szutykok is igényelnek futó drivert, ez szépen mind jön rá.
De ez nem csak Linux alatt van így. Amlékszem anno XP is, mikor 140 MB-ot evett a rendszer boot utáni idle-ben, ahogy felment pl. egy bloatabb HP vagy Samsung, Cannon nyomtatódriver, máris megugrott közel 300-ra. Csak egy darab drivertől. Ha még jött rá ilyen Radeon Catalyst a .NET szutykaival, meg egyéb tálcaalkalmazások (pl. Intel RST, Creative Control Panel, stb..), máris hízott tovább.
-
Frawly
veterán
válasz
attilav2
#7975
üzenetére
Nekem fordított irányú a tapasztalatom, és nálam a Sway eszik kevesebbet, igaz két különböző gépen néztem, ahol az eltérő méretű driverek jelenthetnek különbséget, az egyik Intel IGP-s gép, a másik AMD APU-s. Az intelesen a Sway majdnem 100 megával kevesebbet eszik, mint az AMD-sen a sokkal minimalistább X.org + dwm.
Mint mondtam, virtuális gép alatt sose fogsz valós számokat, valós viselkedést látni, ahhoz fel kell tegyed fizikai vasra, rendesen. Nem csak a GPU miatt, hanem pl. hangdriver, Pulseaudio, egyéb szutyok is fut egy átlag desktop rendszeren, míg virtuális gépben, ha nincs hangeszköz, nincs hardveres GPU gyorsítás, akkor egy csomó driverrel, kernelmodullal kevesebb is fut. Egy zárt NV driveres rendszeren ez elvileg még rosszabb, főleg, ha a user még egy csomó más hardvert is hajt róla. Tehát az, hogy minek mekkora a fogyasztása, az elég gépfüggő is, meg attól is függ, hogy ki mire használja a gépet.
Amit ilyen virtuális gépekben, mindenféle extra hardveres körítés és virtuális extension nélkül látsz memóriafoglalási adatokat, azok csak elvi minimumok. Lehet ilyeneket a valóságban is elérni, pl. egy Gentoo + X.org + dwm trióval, ha nem fut GPU driver, nincs még hang, stb., akkor esetleg, pl. ilyen beágyazott rendszereken. De desktopnál, amin böngészel, meg használsz mindenféle programot, ott a 100 mega alatti foglalás irreális. Akármi az initrendszer.
-
Frawly
veterán
válasz
attilav2
#7972
üzenetére
Ebből a memóriafoglalásból nem lehet kiindulni. Csalóka. Virtuális gépben futó rendszernél nem lesz GPU driver, nem lesz hardveres gyorsítás, nem fut mesa, nem fut kompozitor (jó ennek nem is kell más rendszeren sem), nem fut hangdriver, stb.. Úgy persze, hogy kevesebbet foglal. Igazi gépen nézd, ott bőven lehet kb. ugyanez a rendszer az általam írtakkal 200-250 MB is, ha valami komolyabb dedikált GPU-d van, vagy modern AMD APU. Intel IGP kicsit soványabb, de ott is meglesz vagy 150 MB körül.
A megakadás kikapcsoláskor is lehet ACPI driver meg nem felelősége, ez igazi gépen nem lesz problma. Initrendszer ízlés kérdése. Artixot mindjárt háromféle inittel is lehet telepíteni. Nekem egyébként a systemd-vel nem is a tulajdonságai, memóriafoglalása a bajom, hanem hogy minden dependel rá, és nem lehet elhagyni maradéktalanul. Itt a képeden is bizonyíték, hogy ott fut az elogind, ami systemd-logind részimplementációja, ergo nem kerülted ki teljesen.
A másik baja az alternatív initnek, hogy a bootidejük általában kicsit lassabb, és a disztrónak sok csomagot patchelnie kell, hogy menjen nem systemd-inittel, és emiatt kicsit lassabban érkeznek meg az újabb verziók bele. Szóval ez a systemd-nélküliség kétélű fegyver.
-
Frawly
veterán
válasz
Shyciii
#7967
üzenetére
Ez néha ugrál, majd mikor 178-at ír, akkor hagyjad futni a watch free -mw parancsot, és látni fogod, hogy egy idő után (10-20 mp.) visszaugrik ~140 MB környékére. Az teljesen jó. Le lehet menni egyébként ez alá is, de csak systemd-mentes disztrón, és annyira ultraminimalista megoldásokkal, hogy szerintem nem éri meg, mert használhatatlan lesz a gép, nem tudsz hatékony workflow-t kialakítani. Ez a ~140-170 MB ez teljesen jó, már kellően minimalista, hogy atomgyorsan, pattogósan fusson, de még kellően rugalmasak ezek a bspwm, Sway, stb. szintű dolgok, hogy bármilyen workflow-ra be tudod configolni őket.
#7968 attilav2: Nyilván úgy a Sway-nek meg a akármilyend-ket elhagyó minimalizmusnak nincs értelme, hogy a sok KDE által feltelepített szutyok továbbra is fut, meg mindenből olyan progikat használsz, amik betöltik a Qt-hegyeket. Minimalista rendszernél nem csak az OS meg az init service-ek minimalisták, hanem a progik is, többségében terminálos, CLI-TUI megoldások. Nyilván nem mindenben, mert pl. a grafikus bloat böngészőket nem lehet kiváltani, meg ha kell Wine, Steam, videóvágó progik, vagy hasonló, akkor annál sem lehet megúszni a bloatot. Ez nagyban attól is függ, hogy mire használod a gépet.
Egyébként a KDE-vel, Cinnamonnal, stb. sem lenne baj, csak bloat és nagyon windowsos szemléletű. Ennek ellenére kezdőknek kiváló, az első linuxos hónapjaikban, de ha már elértél egy szintet, akkor érdemes túllépni rajtuk.
Épp így, ahogy a kolléga is észrevette, hogy felesleges a GRUB, meg ahogy te is észrevetted, hogy felesleges a systemd-networkd, meg egyéb szutykok, úgy még elég sok ilyen sallangot lehet kilőni, ha ezeket nem tölti be a gép, máris sokat gyorsul a boot, betöltési idők, stb.. Csak azért, mert a gépnek nem kell betöltenie egymásra épülő sallangokat. Ezt nem érti ubyegon, hogy nem arról van szó, hogy ezek a sallangok ne férnének el 8-16 GB RAM-ba, hanem mikor ezeket kell a RAM-ba töltögetni, akkor az a procinak is munka, a felhasználnak plusz latency, és mindegyik csak egy apró, pár msec, de mikor sok ilyen egymásra épülő szutyok összejön, egyik 10, másik 50, harmadik 100 megákat töltöget be, akkor tudnak belassulni a dolgok.
systemd-mentes Archot viszont nem ajánlom. Még többet is foglalnak a memóriából, mert egyszer fut a saját initrendszerük, meg még rá a különböző systemd-pótló megoldások (elogind), és ezek együtt többet kitesznek, mint ha csak systemd-t használnál önmagában. Persze próbálkozhatsz vele, pl. Artix Linux, hátha bejön, de sok előrelépésre ne számítsál.
Főleg akkor nagyon kínszenvedés a systemd hiánya, ha ilyen KDE meg hasonló megoldásokat futtatsz, mert azok extrán igényelni szokták a sok szutykuk futtatásához. Gnome, Xfce is.
Igazából a Sway is támaszkodik a systemd-re, de csak a logind részére, de még ezt is át lehet hidalni elogind nélkül, a Gentoo Wiki-nek van erről valami cikke emlékeim szerint, hogy scripttel hogy lehet ezt kiváltani.
-
Frawly
veterán
válasz
anorche1
#7961
üzenetére
A --efi-directory nem jó, annak is a /mnt/efi-t adjad meg. Elvileg úgy jónak kéne lennie. A másik, ami előfordul, hogy egyes Acereknél az UEFI nem szabályos, csak Windows only bootra van fixen bedrótozva, hogy bootkor a Windows bootmgfw.efi fájlát akarja bebootlni név szerint. Ez kikerülhet az alábbi parancs kiadásával:
cp $MOUNTPOINT/EFI/grub/grubx64.efi $MOUNTPOINT/EFI/Microsoft/Boot/bootmgfw.efi$MOUNTPOINT helyett nyilván azt adod meg, ahová felcsatoltad. Bár az is furcsa, amit írsz, hogy /mnt-be csatolod, az EFI partíciót /boot-ként szokásos felcsatolni.
Másrészt, ha sima UEFI és ext4 partíciók, semmi titkosítás, RAID, LVM bonyolítás nincs, akkor systemd-bootot is használhatsz, az egyszerűbb, és nem kell hozzá GRUB sem.
-
Frawly
veterán
válasz
attilav2
#7959
üzenetére
Örülök, hogy sikerült. Ez a másik szépsége a Linuxnak a Windowszal szemben, hogy nem csak szektor alapon lehet klónozni, nincsnek rejtett szektoros trükkök. Simán fáljalapon másolható.
Az rync kapcsolói nem fontosak. A nagybetűs kapcsolók csak nagyon speciális esetben fontosak, a --progress 2 semmit nem gyorsít (azért volt gyors, mert SSD-ről volt szó, nem a kapcsoló miatt), igaz ezek a sebességen nem is rontanak. Ha az Arch Wiki így ajánlotta, akkor jónak kell lennie.
Természetesen bármi alól csinálható, még csak Arch alapúnak sem kell lennie, csak legyen rajta egy konzol, shellel meg rsync-kkel. Ez megint csak a CLI toolok szépsége, nem kell neki GUI, meg 1-2 gigás Live iso, és hasonló extrák.
Ez az rsync nem csak rendszerklónozáshoz jó, hanem backup készítéséhez, gépek közötti adatátvitelnél is jól hasznjálható, sokoldalú alapparancs, megéri ismerni a használatát. Szerintem a kapcsolói kicsit hülyék és komplikáltak, de simán megtanulható.
-
Frawly
veterán
válasz
attilav2
#7956
üzenetére
Igen, írtam, hogy a dd az üres blokkokat is átmásolja, de ez nem tragédia. Írtad, hogy SSD-ről van szó, azon eleve nem tart sokáig, másrészt szekvenciális művelet, ami egy HDD-n sem annyira rettenet lassú.
Ez az e2image is megfelelő lehet, bár nem ismerem, így ebben nem tudok segíteni, hogy hogyan használd. Max utána tudnék olvasni, de azt te is meg tudod tenni magadtól.
Amikor én csináltam ilyet, akkor tömörített tar-t használtam:
cd /
sudo tar -czfpv --one-file-system /cel/backup.tar.gzMajd ezt bontottam ki a céllemez előre létrehozott partíciójával
sudo tar -xzfpv backup.tar.gz /cél/felcsatolás
(ebből a -p nem is feltétlen kellett volna, a -v csak a fájllistázáshoz van, a z=gzip, de lehetett volna használni -j, -J, --zstd vagy egyéb kapcsolókat helyette)
De lehetett volna így is, pl. root partíciónál, az előre létrehozott, formázott, és felcsatolt célpartícióra:
sudo rsync -avHASX / /cél/csatolás/
Ez is kicsit overkill, mert szerintem elég lenne az rsync -a, a többi kapcsolónak nem lenen szerepe egy átlagos rendszeren.
Az rsync előnye, hogy előbb nem ment tömörítvénybe, hanem közvetlenül másol forrás és cél között. A tar viszont jobb, ha el is akarod tenni a mentést backupként.
-
Frawly
veterán
válasz
attilav2
#7953
üzenetére
Ha tényleg nagyobb a céllemez, mint a forrás, akkor nem kell semmilyen clone-szutyok. Először megparticionálod a céllemezt, akkora partíciókkal, amekkorákat akarsz rá. Aztán a sudo dd if=/dev/akármi[partíciószám] of=/dev/másikeszköz[partíciószám] bs=32M status=progress paranccsal átklónozod őket egyenként.
A végén még szükséges, hogy az átklónozott partíción a fájlrendszert a sudo resize2fs /dev/cél[partíciószám] segítségével, hogy ténylegesen is kitöltse a rendelkezésére álló nagyobb partíciót.
Ha bootmeghatjó, akkor még szükség lehet a bootloaderben a kernelparamétereknél a root partíció PARTUUID-jének átírására, illetve a /etc/fstab-ban is az UUID-ket átírni, mert azok ezzel a módszerrel változhatnak.
Egyébként szerinte a clonezillának sem lehet baja a GPT-UEFI-vel. Semmiben nem bonyolultabb, mint az MBR Legacy Boot. Annyi, hogy át kell klónozz egy FAT32 partíciót. Igazából az UEFI boot nem hogy bonyolultabb, de egyszerűbb, ha megérted hogyan működik.
Egyébként dd helyett működne a fájl szintű átmásolás is, rsync-kel vagy tar-ral, de az bonyásabb, bár annyi előnye lenne, hogy a nem használt szektorokat nem másolja át feleslegesen.
-
Frawly
veterán
válasz
Shyciii
#7950
üzenetére
Szerintem ez nem kell, ha amúgy nincs problémád a bootolással és a GPU-t használó alkalmazásokkal, akkor nem szükséges belebarmolni az mkinitcpio.conf-ba. Ha viszont van, és Intel GPU-t használsz, akkor igen, az i915-öt a MODULES sorba bele lehet tenni, próbaképp. Azért írtam fentebb, hogy nálam ez amdgpu KMS driverrel működött, de akinek hasonló problémája van, hogy nem megy neki valami, vagy esetleg bootkor a kernel behányna ilyen zavaró hibasorokat, akkor ezzel a beállítással sanszos, hogy megszabadulhat ezektől. Rémlett, hogy egy oldallal ezelőtt egy másik kollégának két AMD-s gépen is volt ezzel gondja, egy dedikált és egy integrált AMD GPU-val is.
Ilyen intel_agp meg kötve hiszem, hogy manapság kell bárkinek is. Ez valami nagyon régről maradhatott benne a Wiki-ben.
-
Frawly
veterán
Írtam róla régebben, hogy az 5.11-es kernel állandóan kiírkálta a amdgpu: Unsupported power profile mode 0 üzenetet, ami működési zavart nem okozott, csak idegesítő volt, hogy bejelentkezés közben állandóan behányta a konzolba.
Megleltem rá a megoldást: a /etc/mkinitcpio.conf fájlba a MODULES=() sorban a zárójelek közé oda kellett írni az amdgpu szót, majd újrageneráltam a initramfs-t az mkinitcpio -p linux parancs kiadásával így modulként korai bootszakaszban tölti be. Ezzel eltűnt a hibaüzenet.
Ami külön fontos: ha más is AMD GPU-t használva tapasztal friss kernellel problémákat, akkor megpróbálhatja ezt a modulos átszerkesztést, legfeljebb ha az ő GPU-jához nem az amdgpu driver kell, hanem a radeon, azzal is kéne működnie. Egy próbát megér, galibát biztosan nem fog okozni.
-
Frawly
veterán
válasz
attilav2
#7946
üzenetére
A Chromium mindenen lassan fordul, ilyen 12-64 magos procikon is simán 20-60 perc, most akkor arányosíthatod. 1 giga felett van a kódbázisa, ez szépen mutatja, hogy mekkora bloathegy, én néha azon csodálkozok, hogy csak pár giga memória kell neki, és nem pár tizen giga.
Az az X4 még ma se olyan rossz gép, főleg ha a 8 giga RAM meg egy SSD alatta van, akkor ilyen átlag felhasználásra, linuxozásra, böngészésre simán elmegy. Modern utasításkészletek is benne vannak, meg ha van benne egy elfogadhatóbb Videó Károly, akár még játékokra és nagy felbontású médiakódekek nézésére is alkalmas.
De ez nem az AMD érdeme, hanem az Intel bűne, meg hogy a szilikonos technológia a végéhez közeledik, és lelassult a fejlődés, főleg, amíg az Intel 2-4 maggal meg tikk-takk-ozással lassította, míg fölényben volt. Egy 10 éves Core i proci is teljesen jó még, ha 4 mag van benne, nem hogy egy 5 éves AMD.
Nagy kódfordításkor azért látszik ezeken a régebbi procikon a kevés cache, meg a 4 mag limitje, kisebb IPC, nyilván ha erre akarja valaki használni, akkor vegyen modern procit, de az már nem átlag felhasználás. Arra Ryzent kell venni.
-
Frawly
veterán
válasz
Shyciii
#7941
üzenetére
Ja, akkor gyári Chrome. Sokat a Chromiummal úgyse nyersz, mert 99%-ban amúgy is megegyezik a Chrome-mal, meg ha úgyis mindent Google accountba szinkronizálsz, akkor annak az 1% (többieknek mondom: nem kötözködni, csak hasraütésszerű számok) sem fog különbözni.
Igazából szerintem ma már mindegy mit használsz, mindegyik browser egy bloat szar lett. Én azért maradok a Firefoxnál, mert testreszabhatóbb, mint a Chrome-alapúak, és legalább ennek a használatával nem a Google egyeduralmát támogatom.
-
Frawly
veterán
ld /alkalmazás/elérési/útja/alkalmazásnév helyett ldd /alkalmazás/elérési/útja/alkalmazásnév kell. Ez egy elég szerencsétlen félreírás, mivel mind az ld, mind az ldd valós parancs Linux alatt, de mást csinál, az ld az linkel, az ldd meg függőségeket ír ki, ami nem lett statikusan belefordítva, persze ennek is a linkeléshez van köze. Természetesen ldd-t akartam írni, de nem vette be a második d-t, ami jelentős félreértésekhez, másik parancs futtatásához vezet.
-
Frawly
veterán
válasz
attilav2
#7937
üzenetére
Olyat nem nagyon tudok, aminek a Konsole-hoz hasonló menüje lenne és úgy kezelné a vágólapot. Talán a gnome-terminal, de az is ugyanolyan bloat, és nem biztosan tudja.
sati a vágólapproblémákat clipman-nal oldotta meg. Mindig ígértem, hogy én is kipróbálom, de sose jutok oda, általában nem veszem elő azt a gépet, amin a Sway van.
-
Frawly
veterán
válasz
attilav2
#7934
üzenetére
Jól néz ki ez a bar a tetején, swaybar? Konfigját betennéd? Látom a billentyűzet nevét megoldottad *-os helyettesítéssel, azt is lehet.
Amúgy ja. Wayland előnye, hogy soványabb, mint az X.org, pattogósabb, kevesebb lag, főleg vad görgetésnél látszik, meg a böngészők is pattogósabbnak tűnnek, még XWayland emulációval is, nem hogy tényleges Wayland módban.
Fogyasztásban is bármire köröket ver szinte, még a minimalistább X-es WM-ekre is. Egyedül a Konsole-t nem párosítanám hozzá, mert bár nem rossz terminál, de elég bloat, bár azért nem a legvészesebb. A memóriafogyasztás nem is azért fontos, mert nem lenne az embernek elég memóriája, nekem pl. 16 giga van minden gépben, hanem kevesebb dolgot kell a memóriába betöltenie, a procinak kevesebb dolgot kell végrehajtania, és ez meg is látszik betöltési időkön. Egy komplett KDE 5 Plasma betöltése SSD-n is vagy 5-9 mp., egy Sway 0,05 mp. alatt a képernyőre vágódik. Ennyi, ezen nem sok mindent lehet ragozni, ez a pattogósság függőséget okoz, a hibernációt/sleepet is szükségtelenné teszi. Még gyorsabb lehet, ha az egerészős grafikus alkalmazásaid szinte mindegyikét lecserélted terminálos CLI/TUI alkalmazásra, meg billentyűzetorientált irányításra, de ez hosszabb megszokási-átalakulási folyamat része, lehet hónapok-évek kérdése is, nem nagyon lehet siettetni. Az összes alkalmazást nem lehet terminálossal kiváltani, mert a használható böngészők mind bloatok és GUI-sak, ezt pl. nem lehet megkerülni, meg ha kell Wine, Steam, hasonlók, azok is szükségszerűen bloatok. A másik előnye a tisztán minimalista rendszernek, hogy gyorsabban is frissül, mivel kisebb csomagokból áll, azoknak kevesebb függősége is van, így a frissítési idő is rövidebb, mivel csak fele annyi csomag van a rendszeren, negyed annyi méretben, és egy-egy frissítésnél kevesebb dolog is törhet el, mivel nincs nagyon függőség. Persze ezt majd akkor tapasztalod meg, ha egyszer KDE nélkül teszed fel.
Egyelőre én X-en vagyok megint (dwm, néha IceWM, kezdem konfigurálni a bspwm-et), de csak kísérletezés miatt, a Sway-jel jobban meg voltam elégedve, hiányzik, ha nem találok jobbat, vissza fogok rá én is váltani, mert amúgy nagyon jó. A régi gépen még Sway fut, de azt nem nagyon veszem elő, csak ha valami adatot akarok előásni róla. Csak azért kísérletezek most X-szel, mert az konzervatív disztrókkal (pl. Gentoo, Slackware, Debian) és BSD-kel kompatibilisebb, meg hátha felfedezek rajta egy Swaynél is minimalistább, de használható megoldást, nyilván ezen a vonalon is meg kell próbálni fejlődni, legfeljebb nem hoz eredményt. Ha egész életemben Swayen maradok, akkor megrekedhetek fejlődésügyileg, amit nem akarok, azért próbálok ki más dolgokat is. A Sway megvár, konfigja el van mentve, bármikor visszaállhatok rá.
-
Frawly
veterán
válasz
attilav2
#7930
üzenetére
A sima terminálos indítás nem mindig elég, főleg nem elég csak közvetlenül induláskor nézni, hanem tartósan kell használni terminálból indultan, lehet ezt a hiányzó .so modult csak akkor írja, ha MPEG-TS alapú cuccot próbálsz megnyitni, anélkül nem. Ez az .so hiány mindig kibukik terminálból, játékoknál is így szoktam kinyomozni a hiányzó so-kat. Elvileg szakszerűen az ld /alkalmazás/elérési/útja/alkalmazásnév való, az kiírja, hogy milyen dinamikus függőségek lehetnek, ezt is lehet használni.
Nálam a Swaynak nem volt baja az XWaylanddel, minden normálisan futott, nem crashelt. Arra figyelj, hogy Swayből lehetőleg ne kézzel barmoltat tegyél fel, hanem az Arch hivatalos tárolójából a stabil Sway release-t. A git-es dev ágnak lehetne bugjai.
-
Frawly
veterán
válasz
attilav2
#7930
üzenetére
Sway-en így kell a billentyűzetet belőni a ~/.config/sway/config fájlban:
input "1:1:AT_Translated_Set_2_keyboard" {
xkb_layout hu,us
xkb_options grp_led:caps,grp:alt_space_toggle,caps:escape
repeat_delay 280
repeat_rate 50
}Ez csak egy példa. Nálad az input neve más lesz, a swaymsg -t get_inputs parancs kilistázza.
Az én példámban ThinkPad X220 billentyűzeten állít be elsődleges szabvány, 104 gombos ISO magyar és másodlagos 104 gombos ANSI amerikai kiosztást, közötük bal Alt+Space-re váltva, másodlagos kiosztásnál a Caps Lock ledje ég. A Caps Lock le van cserélve Escape-re, ez a vim-módokhoz kell az egyes alkalmazásokban. Plusz az utolsó két sorban felvettem a billentyűzet érzékenységét és ismétlési sebességét.
De ha neked nem kellenek ennyire extra feature-ök, akkor a magyar kiosztás egyszerűbben belőhető:
input "möhöhő-input-név" {
xkb_layout hu
}Ezzel csak szabvány, 104 billentyűs ISO magyar kiosztásod lesz, semmilyen extra nem lesz bekapcsolva, nem lesz másodlagos kiosztás, meg semmilyen más bonyolítás. Egy Sway-újraindítást igényel. Az input nevet nem lehet sose kitalálni, mert fizikai hardverfüggő, minden gépen, és gyártónál más. De hasonló módszerrel kell konfigolni az egeret, tapipadot, trackpointot, ezek érzékenységét, extra feature-eit, pl. több ujjas gesztus, kattintáskombók, görgetés, stb..
A bemenu okés, még nem próbáltam, de sokan dicsérik. A dmenu-nek néha lehet bugja Wayland alatt, pl. nem akar eltűnni, beragad a képernyő tetején, igaz ez ritka. De a Rofi-nak is van waylandes klónja. Redshitf-nek is, meg egy csomó másik mindennek. Wayland alatt is minden megoldható, csak eltérő toolokat igényel, mert az általánosan ismert X-es toolok nem működnek, mivel nem véletlen van a nevükben az x, az X serverhez lettek kitalálva, a Wayland meg ne X, hanem egy egész másik protokoll.
-
Frawly
veterán
válasz
attilav2
#7927
üzenetére
Bizony, bizony. Ha megnézed az Arch tárólójának a csomaginfóját a vlc csomagról (kattints a show more-ra), akkor látod, hogy az aribb24 opcionális függőség, sőt, ha tovább olvasod, van aribb25 is, amire lehet később szintén szükséged lehet.
Ne feledd, hogy ez Arch. Nem Ubuntu meg Snap/Flatpakk, ahol a VLC gigás csomagban érkezik, és minden függőség hozzá van csomagolva, hogy egységsugarú usernek is hülyebiztos legyen. Ez egy minimalista disztró, itt tényleg csak azt emeli be függőségnek a pacman, ami annyira kell a futásához, hogy épp csak elinduljon üresben, külön médiafájl megnyitása nélkül. Ha extrák kellenek, azt neked kell kinyomozni, meg kézzel feltenni, és tudni mire van szükséged. Ez a magam építem a rendszerem, csak az van fent, amire tényleg szükségem van mentalitás különbözteti meg az Arch/Gentoo usert az ubuntusoktól.
-
Frawly
veterán
válasz
attilav2
#7924
üzenetére
Ezek szerint hiányzó függőség volt. De ezeket cvlc nélkül is ki kellett volna írnia, ha terminálból indítod a VLC-t. Ez egy általunk gyakran javasolt trükk, hogy a GUI-s progikat is indítsuk terminálból, ott a hibakimenetben sok minden látszani fog, ami grafikus felületen rejtve marad.
Amit még tudsz ilyenkor, hogy újratelepíted a VLC-t az Arch tárolójából. Ez önmagában nem fogja a függőséghiányt megoldani, de ha szintén terminálban vagy konzolban csinálod, akkor a telepítés végén ki fogja listáznia pacman az ún. opcionális függőségeket, amik nem kötelezőek, nem default függőségek, csak 1-2 extra feature-höz kellenek, és nagyon valószínű, hogy meg fogod találni ott, hogy mi hiányzik neki, ami [not installed] státuszú, de neked kellhet.
Ezért szoktam papolni, hogy terminál, terminál, terminál, meg miért jobbak a minimalista, terminálos, CLI/TUI progik. Ezért. Mert egyszerűbbek, jobban debugolhatóak, látszik mi mit ír ki, nem kell külön loggal kínlódni, meg a GUI felületen elrejtéssel harcolni. Mert fasza a GUI, kényelmesnek tűnik, szépen témázható, szép nagy ikonok, csak épp rettenet nem hatékony, meg rettenetesen korlátoz, ha átlépsz egy szinten. Ez senkinek nem tűnik fel, mert az emberek már 30+ éve megszokták, hogy csak grafikus felület, csak grafikus felület, csak GUI, és már el sem bírják képzelni, hogy lehet máshogy is, sőt, nem csak lehet, hanem legtöbbször az lenne a hatékonyabb.
-
Frawly
veterán
válasz
attilav2
#7915
üzenetére
Xwaylandet ne tiltsd le, mert elég sok program van, amiből nincs waylandes alternatíva. Legyen fent az Xwayland, ha a progik épp nem használják, nem fogyaszt. KDE-vel össze sem lehet hasonlítani, mintha a Win10-et meg az MS-DOS-t hasonlítanád össze ilyen tekintetben, más dimenzió.
A Sway-nek, mint tiling WM-nek akkor van értelme, ha:
1) főként terminálos programokat használsz. Ezen a ponton kapásból kiestél ilyen Deadbeef (jó, ez még annyira nem), Clementine, LibreOffice, VLC, stb. igényekkel, ráadásul ezek önmagukban bloatok, ezek foglalnak 2+ gigát, nem a Sway. Épp ezt szoktuk mondani ubyegonnal, hogy ha valaki bloat rendszert használ, akkor pálcika WM-nek nincs értelme, mivel nem az fogja enni a sok memóriát, hanem a böngésző, bloat GUI-s megoldások, és a pálcika WM és a full DE-k között a memóriafoglalás kiegyenlítődik sok ilyen programnál.
2) billentyűzetorintált workflow-t akarsz (mint írtad, neked ez is gond)A Sway egy i3wm-klón, tehát tekintsd úgy, hogy i3wm-et használsz, de közben a jövő technológiáját teszteled (Wayland). Nyilván a Wayland-ökoszisztéma más, nem működnek a szokásos X-es toolok, pl. xrandr, redshift, scrot, feh/nitrogen, setxkbmap, Rofi, X screenrecorder, stb., helyette ezekből waylandes változat kell.
Firefoxot nem ajánlom Wayland módban, ez a része csak kísérleti, és bugos. SBC is felejtős, mikrokontrollernek, mikroszervernek valók, nem desktopnak, swayezni, KDE-zni. Főleg ahhoz kevesek, amit te akarsz, hogy háttérben ilyen 2-8 giga bloat fut, VLC, LibreOffice, böngésző 10 tabbal, Clementine, stb.. Erre rendes desktop gépet kell venni, min. 4 magos proci, min. 8 giga RAM, modern GPU, ami modern kódekeket tud kódolni hardveresen, stb.. Futni futnak ezek SBC-n is, de baromi lassú, élvezhetetlen, körülményes lesz, nem fog jó felhasználói élményt adni.
A másik csapdája ezeknek az SBC-knek, a komolytalan teljesítményt leszámítva is, hogy drágák. Az ne tévesszen meg, hogy maga az SBC csak pár dollár, de kell hozzá SD-kártya vagy SSD, hűtő, ház, kábelek, USB-s töltő, kijelző, billentyűzet, tököm tudja mi, és amikor ezt a sok apróságot összeadod, könnyen kijön, hogy egy használt Core i laptop vagy szubnoti lényegesen olcsóbbra kijön, minden bele van integrálva, teljesítménye is nagyobb, natívan futtatja az x86-os kódokat, áramból és helyből nem kér sokkal többet.
Persze lehet venni SBC-t, hobbista kisérletezésre jók, csak arra kell figyelni, hogy ne költs rá túl sokat.
-
Frawly
veterán
-
Frawly
veterán
válasz
Shyciii
#7911
üzenetére
Na, látod. Megint beigazolódik, amit mondtam.
A find parancs helyett én is fd-t használok, mert tényleg gyorsabb. Én fzf-fel vegyítem, tehát fd . / | fzf és így pár billentyű lenyomásából ki tudok választani listáról dolgokat, gyakran csak 1-2 billentyű. Én így nyitom meg az összes mappát, dokumentumot, már Vifm-et is ritkán használok. Így tényleg baromi gyors, hogy benyomom a gyorsbillentyűt, előjön a lista, 1-2 billentyűre kiválasztom a megnyitni kívánt mappát, fájlt (ezekre külön gyorsbillentyű van), és azok azonnal megnyílnak a nekik fenntartott alkalmazásban, mindegy hány mappa mélységben vannak a jelenlegi pozíciómhoz képest. Ez kb. 1000× gyorsabb, mint a hagyományos GUI-s workflow, hogy előbb becélozni egérrel az alkalmazásindító ikont, néha még rosszabb, mert alkalmazásmenüt is meg kell nyitni előtte, aztán mikor már fut az alkalmazás, akkor abban még megnyitogatni dolgokat, megint egérrel célzás, tallózás. Nálam ugyanez 1-3 billentyű (gépírástartásban már elve felettük vannak az ujjaim), még csak pontosan sem kell emlékezzek a fájl vagy mappa nevére, elég, ha csak kb.-re írok be 1-2 jellemző betűt, még csak egymás után se kell legyenek, a fuzzy finder pont attól fuzzy, hogy akkor is megtalálja.
Ennek csak az az egy baja van, hogy ha nem a saját rendszerem előtt ülök, akkor rossz visszatérni a hagyományos GUI-s megoldásokhoz, főleg Windows alatt, mintha hátrakötött kézzel kéne mindent csinálni, annyira érezni, hogy nincs hatékonyság. Egyszerűen fényévekkel le van maradva. Nyilván ezt nem érzi az, aki a hagyományos megoldásokhoz szokott hozzá.
-
Frawly
veterán
válasz
Shyciii
#7909
üzenetére
Az st benne van egy olyan mappában, ahova a PATH mutat? Mert ha csak simán forgatod forráskódból, akkor lehet nem telepítetted, csak lefordítottad, és nem került be a /bin/ vagy /usr/bin mappába, vagy hasonló.
De nekem ez a vifmrun is gyanús, simán st -e 'vifm /home/Data /home/Data' sornak kellene lennie, run nélkül. Lehetőleg idézőjelben, az mindegy, hogy egyszeres vagy kétszeres idézőjel.
#7908 jimmy399: akkor meg végképp fogalmam sincs, hogy ha LTS-sel sem jó.
-
Frawly
veterán
válasz
jimmy399
#7904
üzenetére
Nem értem, megírom a hozzászólás, elküldődik, de nem jelenik meg a fórumon. Nem először van. Már több rendszeren és gépen előfordul, kezd frusztráló lenni.
Amit eredetileg írtam: próbáld feltenni az Arch hivatalos tárolójából a linux-lts csomagot, ez lecseréli a kernelt az utolsó LTS-re, ami most az 5.10-es ág, átmeneti megoldásnak jó lehet.
-
Frawly
veterán
válasz
Shyciii
#7905
üzenetére
Ez tényleg fura. Ilyet még nem láttam. Nálam simán elindul a Vifm mindenhogy, default usermappáknál és fájloknál is, amik mappa esetén 755-ösek default (ahogy írod, a listázáshoz kell az execute jog a mappákra), a fájok 644-esek (tulajnak/usernak írható, csoportnak és többeknek csak olvasható. Ez a default minden disztrón.
Persze az is igaz, hogy ez felhasználástól függ, mert aki többfelhasználós gépet használ, és fájlokat akarn megosztani, ott muszáj min. a csoportjogokat is úgy beállítani, hogy mindenki írhassa, futtathassa, amit kell. Elvileg a 777 az publikus mappáknál kéne, ahol követelmény, hogy nem csak a tulajon és a csoportján belül tudják írni, futtatni, hanem tényleg mindenki. Bár ilyenkor se célszerű minden fájlra, mert a fájlkezelők (nem csak a Vifm) akkor binárisként/scriptként próbálnak futtatni adatfájlokat is, és írogatják ki a hibaüzeneteket. Így futtatható jog tényleg csak a mappákra, binárisokra, és scriptfáljokra kell, de ezek az összes fájl számához képest töredéke egy normál rendszeren. 777-re meg tényleg az esetek 99,9999999%-ában felesleges állítani, ez mint mondtam, sok embernél csak régi megszokás, hogy kényelemből bevereti háromszor a legmagasabb oktális számot, mert elég ráfeküdni egy darab billentyűre.
xshkd vonatkozó sora nálad mit mond?
-
Frawly
veterán
válasz
Shyciii
#7900
üzenetére
Ezt most nem egészen értem. Minek kellett pontosan futtatási jog? vifm-nek, vagy sxhkd-nek, vagy az sxhkd scriptnek vagy minek?
A chmod 744 az oké, ha célzott fájlra van kiadva, de akkor már jobb a chmod +x parancs. Valószínű ebben az esetben ugyanezt eredményezte volna.
Egész partícióra viszont nem szabad kiadni a 744-et. valószínű nem tudta a Vifm megnyitni a /home/Data mappát, és egy chown -R felhasználód /home/Data parancs megoldotta volna, a jogok összekutyulása nélkül. Vagy mountoláskor az umask opció.
-
Frawly
veterán
válasz
jimmy399
#7897
üzenetére
A radeon az a régebbi driver, amit az Arch Wiki ATI-nak nevez. Akkor jó driverrel hajtod őket, nem kéne szórakoznia. Feltéve, hogy fent van az x86-video-ati driver is.
#7896 attilav2: próbáld a VLC-t terminálból indítani, és megnézni, hogy mit ír ki, mikor nem tudja a streamet megnyitni. Erről az oldalról ellenőrizd, hogy a VLC opcinális függőségei közül is fent legyen minden, ami neked kell.
-
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.
-
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.
-
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.
-
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.
-
#7867
Frawly
veterán
stranger28
#7864
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.
-
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.
-
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..
-
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.
-
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.
-
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.
-
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ó.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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.
Új hozzászólás Aktív témák
Hirdetés
BoB
- LG 77G4 - 77" OLED evo - 4K 144Hz 0.1ms - MLA - 3000 Nits - NVIDIA G-Sync - AMD FreeSync - HDMI 2.1
- Azonnali készpénzes AMD Radeon RX 5000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- Hp Prodesk 600 G3/ G5/ G6 SFF-MT / i5 8-9-10 gen, Hp EliteDesk 800 G4 / Win11- Számla, garancia
- REFURBISHED és ÚJ - HP USB-C/A Universal Dock G2 docking station (5TW13AA) (DisplayLink)
- REFURBISHED és ÚJ - HP USB-C Dock G5 docking station (5TW10AA) - 3x4K felbontás, 120Hz képfrissítés
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest