- Luck Dragon: Asszociációs játék. :)
- bambano: Bambanő háza tája
- gban: Ingyen kellene, de tegnapra
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- GoodSpeed: AMD Ryzen 7 7700X vs AMD Ryzen 9 9900X Cinebench R23 & R24 Benchmarkokban mérve
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Argos: Adjátok vissza a netet! - szeretnék elaludni!
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- sh4d0w: Árnyékos sarok
-
LOGOUT
Arch Linux topik
Új hozzászólás Aktív témák
-
Shyciii
veterán
válasz
attilav2
#7999
üzenetére
https://linuxhint.com/setup-luks-encryption-on-arch-linux/
Ahogy nézem semmi extra nincs a luksban. Lásd fenti link. Pár sorral több csak a telepítés. Nyilván systemd-boot esetén más a /boot. Mondjuk vmware alatt lehet hogy kell más is, de azt nem tudom. Én az összes próbálkozásomat a saját fizikai notimon csináltam, mert az ha működik, akkor nem kell még azt átirogatnom, hogy fizikai gépen is működjön. Nyilván ha ilyen volumenű dolgot csinálok, mert van időm, akkor előtti csinálok a rendszerről egy image-t. Mondjuk múltkor már arra sem volt szükség, mert a jelenlegi telepítőscriptem a beállítássaimat is visszatölti az adatokkal együtt :)
-
válasz
Shyciii
#7998
üzenetére
Egy leírást te vagy Frawly vagy más hozzáértő csinálhatna a titkosított(LUKS) kézi telepítésről, mondjuk kezdetnek egy egyszerű 2 partíciós telepítéssel ( / /boot), swap nélkül
Csak a / lenne titkosítva, systemd-boot-al. Virtuális gépben meg lehet csinálni és akkor képekkel is tudjátok illusztrálni -
Vboxban próbálgatom ezt a hivatalos installert, háát, azt kell mondjam nem örülök neki túlzottan, alapból titkosított partíciót csinál, de hogy milyen megoldással azt nem választhatom meg.... Az Arch filozófiájával, egyáltalán a KISS-el ellentétes bármilyen installer szerintem... Aki nem érti hogy működik a titkosítás az szívhat vele, én sem értettem még meg hogyan kell titkosított (pl LUKS) telepítést csinálni, és amíg nem értem a folyamatot, de egy installer megcsinálja és valami gond lesz a későbbiekben akkor szívhatok vele mert nem fogom tudni megoldani, pláne hogy nem is tudom az installer milyen megoldással csinálta.
Időt viszont spórolt az installer rengeteget, töredék idő alatt megvolt a telepítés, viszont nem tudom milyen boot megoldást használ a rendszer, hogy lett megvalósítva a LUKS titkosítás, stb. -
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.
-
Lehet hogy utoléri az Arch-ot is a bloatosodás?
Installer scriptet kapott a telepítő média: https://github.com/archlinux/archinstall -
Shyciii
veterán
Nem hiszem, hogy Torvalds belerakná. Ő egy eléggé "érdekes" gondolkodású ember. Minap olvastam, hogy most épp a Rust-ot isteníti, így ezt most linux felé is erősen ki fogja vetíteni. Inkább úgy mondanám, hogy az kerül előtérbe, amit ő jónak tart, és nem az ami ténylegesen fontos, és jó. Persze van mikor a kettő fedi egymást, de sokszor nem. Linux is nem véletlenül kezdett elterebélyesedni, mint a windows. Bár már egyszer-kétszer végre beismerte, hogy túl nagy és felesleges már a kód, csak éppen semmit nem csinál ez miatt.
-
jimmy399
senior tag
Hm, persze, azért is állítottam be, hogy kernelt csak kézzel telepítek majd.
Legacy boot során is előfordult, hogy ugyan ez a csíkozodás hiba megjelent... Van ilyen kevert pendriveom, rufussal csinálva, és 3.12-es kernellel is megesett ,hogy ilyen lett a képernyő, csak ritkábban. -
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.
-
jimmy399
senior tag
A default kártya az UEFI-ben az integrált HD 7650D, 1 GB rammal. Amikor csak a HD 5550-est használtam legacy boot-al, akkor semmi gond nem volt az analóg csatis monitorokkal. Mióta átáltam így 2021-ben arra, hogy UEFI boot-al indítsam el a gépet, és a HD 5550-es csak másodlagos kártya lett (mivel nem képes UEFI GOP bootra), így kénytelen lettem az integráltat megtenni elsődleges kártyának, mert az 5550-es nem tud bootolni UEFI módban.
Az integrált 7650D VGA portájra rádugtam az egyik monitort, a másikat hagytam DVI-I porton, amin keresztül egy DVI-I - VGA átalakítóval használom a másik monitort.
Ha átdugom az 5550-es sima VGA csatlakozójára, akkor is hibát produkál, ergó nem a csatlakozókban van a hiba, hanem valahol a linux driverben.(5.11.11 kernel van most, korábban csak az 5.10.11-es kernel ment fagyás nélküll a gép fura csíkok nélkül) BÁR, már jobb a helyzet mert a korábbi kernelekkel csak szimplán rommá fagyott a gép ha engedélyeztem az 5550-esen a képernyőt, most már csak a korábban említett csíkozódás van meg, de ha sok paramétert (felbontás, frekvencia, oldalarány) állítom, egyszer csak lesz jó kép, de van amikor elsőre megy, random van hiba. dmesg, Xorg.log elemzés megvolt, semmi érdemleges nem derült ki a problémáról.Lehet későbbi kernel update-el kijavítják majd. Egyelőre ignorepkg listára tettem a rendszermagot. Kézzel telepítem, majd ha okés marad, ha nem akkor a cache-ból újratelepítem a korábbi kernelt.
-
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.
-
jimmy399
senior tag
Sziasztok!
Van nekem egy dual gpu-s gépem. Egy AMD A8-5600k Radeon 7650D-vel (ez az elsődleges az UEFI-ben) és egy Ati Radeon HD5550-es kártyám.
UEFI boot, Arch Linux. Kettő darab 19"-os monitor ami VGA csatlakozós. Nem akartam kidobni egyiket sem, mert még működnek, de akadt egy kis gond vele. Mármint ami a HD5550-re kötött monitorra. Eddig vissza kellett tartani a kernel frissítést, mert azonnal csonttá fagyott a rendszer, ahogy engedélyeztem a 5550-esen a monitort. Ezt már javították, viszont előjött a fura képcsíkozódás probléma, ami a címben szerepel.
A legfrissebb radeon driver van fennt, amdgpu-val is próbálkoztam, de ezzel is ugyan ez a gond.
Van amikor elsőre jó a másodlagos kijelzőn a kép, de van amikor sok-sok próbálkozás kell hogy rendes kép legyen. Állítgatom a felbontást, a frekit (60 és 75 Hz), és egyszer jó lesz pár bróbálkozás után.
Megpróbáltam, hogy átdugom mások csatlakozóba, mert van rajta DVI-I, VGA, de ugyan ez a probléma.
Windows 8.1-10 alatt nincs ilyen gond.Csatolok képet, hogy hogyan néz ki a kijelző képe.
Valami tipp esetleg?
http://img4.imagetitan.com/img.php?image=23_20210329_163534_hdr1.jpg -
Shyciii
veterán
válasz
attilav2
#7983
üzenetére
Én a Bspwm előtt Openboxot használtam. Tavaly nyáron még megvolt a config, de már töröltem, mert egyértelmű lett, hogy nem fogok visszamászni Openbox-ra. Amúgy az Openboxot szerintem könnyebb volt konfigurálni (általánosságban, mert pl a Bspwm szerintem könnyebb, de pl a qtile, xmonad nehezebb) ráadásul ott erre volt egy-két gui-s applikáció. Amúgy ahogy Frawly-nek, nekem sem az a tapasztalatom, hogy az Openbox kevesebbet fogyaszt, mint a TilingWM-ek. Itt egy régi kommentemből idézet:
"Hidegindításkori memóriafoglalások:
Openbox: 201MB
i3: 196MB
Bspwm: 185MB
Qtile: 227Mb"
Ezek mind fizikai gépen történtek, ugyanazon programokkal, ugyanazokat betöltve, ugyanolyan kinézettel. Itt látszik, hogy a Bspwm-el kaptam a legjobb eredményt. Az érdekesség még, hogy azóta a Bspwm nálam 141MB-ot foglal. Úgy látszik ennyit egyszerűsítettem a rendszeremen azóta -
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.
-
Most az i3-gaps WM -et raktam fel natív Arch-ra, ez X-es és legalább minden app fut, Sway -en sokminden nem indul el, ha bekapcsolom az xwaylandet és olyan appot indítok ami igényli akkor kidob koznolra a Sway, nincs kedvem debugolni, meg nem is értek ennyire mélyen a rendszerhez. Át chromecastoltam chrome-val tv-re az i3 képét, míg KDE-n ez a művelet 100%-on pörgette a procit, itt beérte a chrome 50%-al, és a chromecastolás befelyezése után a terhelés visszaesett a normál terhelésre 5-10%-ra, ez KDE esetén marad 100%-on és csak a restart segít. A tiling wm mintha tv képernyőre termett volna sokkal kezelhetőbbnek tűnik tv-s böngészésre, online webes videózásra. A memória foglaltság a chromecastolás alatt ~1gb körül volt, ez a KDE alatti chromecastoláshoz képest nagyon jó! Gondolkodok pl egy Rock Pi X x86-os sbc beszerzésén, ebben csak 4gb memória van, de pálcika wm-ek mellett ez bőven elég lenne, kifejezetten tv-s böngészéshez venném. Openbox-al is próbálkozni fogok(virtuális gépen nagyon jók a memória foglaltsági tapasztalataim), már fel is tettem a natív rendszerre, csak ezt bonyolultabb testre szabni mint a sway/i3-at, jól jönne ha megdobnál néhány példa konfiggal, leírással. Felfedeztem ha rendszerindítás után egyből KDE-t indítok és kilépek belőle konzolra akkor a szutykai a memóriában maradnak, sokszor igen magas proci terhelést okozva, amin csak a restart segít. Ha indítás után közvetlenül sway/i3-at indítok akkor sokkal pattógósabb a gép töredék a proci terhelés és a memória foglaltság, és még a chromecastolás is 50%-al kevesebb procit fogyaszt, még akkor is ha webes videót nézek közben, tehát a pálcika wm-ek használhatóvá tették a chromecastot de az 50%-terhelés még mindig sok, ezen lehetne még kicsit faragni ha linux szakértő lennék, de sokat faragni nem lehetne belőle valószínűleg, talán egy -10%-ot. Windows alatt a KDE-hez hasonlóan szintén közel 100% terhelés van chromecastolás közben.
-
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.
-
Sway ~150mb-ot eszik ezen a vboxos artixon, blackbox 75mb-ot eszik.
Mikor feltettem a firefoxot magával húzott vagy 600 megát, és ha elindítom akkor ~300 megára felugrik a memória foglaltság. Artix-on egy csomag több tárolóból is elérhető community, galaxy, stb ez újdonság az Arch-hoz képest. -
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.
-
Artix-openrc, blackbox memóriafoglalás, friss virtualboxos telepítés:
~70mb
Első benyomások alapján komplikáltnak tűnik ez a systemd nélküli lét, a konfigfájlok több helyre vannak szétszórva a vanilla Arch-hoz képest. Szolgáltatások engedélyezése, letiltása is komplikáltabb. Office-olós/youtube-ozós átlag desktop usernek bőven jó a systemd, sőt neki az az optimális. Aki meg szereti a rendszerét állandóan faragni annak jó az initscriptes rendszer.
Ja és nem kapcsolja ki a gépet shutdownkor, legalábbis virtualboxban nem, szinte minden disztró amit eddig vboxban próbáltam ki tudta kapcsolni a virtuális gépet, ez megakad itt:
-
-
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.
-
Shyciii
veterán
válasz
attilav2
#7968
üzenetére
Hát elég minimalista rendszert használok Bspwm-el. Helyenként túlzóan is. Pl az usb-s háttértárakat egy script oldja meg, de pl használok network managert hiába bloat, mert ez egy notebook, így kell kényelmes wifi választán, vagy openvpn-es csatlakozás.
Én nem ismerek teljes systemd mentes arch klón-t, csak az Artix Linux-ot, ami részben systemd mentes, de azért van benne egy-két ráutaló jel. Asszem tán az elogind pl., s-ig systemd-mentes. -
válasz
Shyciii
#7967
üzenetére
Akkor minimalista rendszert használsz. Nálam legalább 2-3 giga minimum, gondolom a KDE miatt. Szoktatom magam a Sway-hoz, de még ott is 1.5-2giga a foglalás egy idő után gondolom a sok háttérszolgáltatás amit a KDE felrakott. Szerencsére legalább 4 ssd-m van a gépbe így tudok különböző rendszerekkel kísérletezni, ki kell próbáljam a minimalista Arch telepítést, vagy egy systemd mentes Arch klónt, ez utóbbiból tudtok ajánlani párat?
-
Kíváncsiságból kipróbáltam a dhcpcd-t, előtte systemd-networkd és systemd-resolved volt(a régi telepítésemen pedig networkmanager, de bloatnak találtam így az újrahúzáskor már mellőztem), gondoltam kiváltom egy szolgáltatással, kikapcsoltam mindkét szolgáltatást(systemd-networkd systemd-resolved), rebootoltam majd systemctl enable dhcpcd@enp5s0 az már gyanús volt hogy az indulása eltartott kb 5mp-ig, de utána működött a net bármiféle külön resolver indítása nélkül, ez elsőre tetszett, de rebootkor jött a fekete leves a systemd rendszerindításkor vár a dhcpcd szolgáltatás elindítására kb 5-10mp-et
Próbáltam konfigurálni a systemd-t már amennyire értek hozzá, egyszerűbb beállításokat változtattam az /etc/systemd/system.conf-ban:
DefaultTimeoutStartSec=3 -al próbálkoztam, de így a dhcpcd nem tudott elindulni, felemeltem 5-re, úgy sem, majd 10-re és így már indul bootkor a dhcpcd. A systemd-networkd systemd-resolved párossal semmilyen problémám nem volt.
Lehet valahogy diagonosztizálni mi akasztja meg ennyi időre a dhcpcd indulását?
Vagy váltsak valami systemd mentes Arch klónra?
Na az arch wikiben meglett a megoldás:
https://wiki.archlinux.org/index.php/Dhcpcd#dhcpcd@.service_causes_slow_startup
Működik, nem gondoltam volna hogy egy ilyen szögegyszerű szolgáltatással mint a dhcpcd gond lehet, egyszer kipróbálok egy systemd mentes arch klónt -
anorche1
őstag
chroot utan telepitem a grubot, ugy a /efi a helyes.
De kozben rajottem, valoban az acer bios/uefi/firmware -je a ludas. Secure bootot vissza kellett kapcsolni, utana security fulon trusted efi file -nak kijelolni a grub efit, utana secure bootot ujra kikapcsolni, es mukodik.
Bár az is furcsa, amit írsz, hogy /mnt-be csatolod, az EFI partíciót /boot-ként szokásos felcsatolni.
Arch wiki install reszebol:
"mount /dev/root_partition /mnt
Create any remaining mount points (such as /mnt/efi) using mkdir(1) and mount their corresponding volumes. "root -nak /mnt -t ir, majd /mnt/efi -t emlit. De ha boot/efi -t szoktak, akkor legkozelebb oda teszem, nekem aztan mind1
-
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.
-
anorche1
őstag
Szeretnek uefi modban archot telepiteni egy acer aspire e5-532-p78v laptopra.
A sajat leirasomat kovettem, ami alapjan a dell e6440 -emre mar tobbszor sikerult feltelepitenem.Egyszeru tortenet, sda -n 2 particio, az elso 256MiB -os fat32 -re formazott, a masodik ext4 -re formazott. Sda1 /mnt/efi -re csatolva, az sda2 / -re.
Ezutan kovetem arch wikit.Grubot telepitesenel ezt csinalom:
grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB
pacman -S intel-ucode
grub-mkconfig -o /boot/grub/grub.cfgA laptopomon ez igy tokeletes, az aceren is lefut hiba nelkul, de restart utan no bootable device.
Probakent felraktam egy manjarot, azzal nem volt gond, az bootolt. De az rendszerbetoltesre mintha nem grub -ot hasznalna.
/boot/efi/EFI/Manjaro mappaban volt a grubx64.efi fajl
de volt egy /boot/efi/EFI/boot mappa, amiben ha jol emlekszem talan egy boot.efi fajl.
Ez utobbit kitorolve mar nem bootolt be tobbet, szoval ez lehet a kulcs.
Grub helyett probalkozzak meg systemd boottal? Vagy lehet csak annyi a gond, hogy en a grubot /efi -be telepitem, /boot/efi helyett? -
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ó.
-
Végül némi kínlódás után sikerült rsync-el átklónozni a fájlrendszert, nem az általad ajánlott kapcsolókat használtam, hanem az Arch rsync wiki File system copy pontjában ajánlott kapcsolókkal oldottam meg. Futó rendszerről a céllemezre nem tudtam átklónozni a rendszert mert a rsync hibára futott. Bebootoltam a MagyArch telepítővel(ami live rendszer is), majd terminálban sudo passwd root, majd su, felcsatoltam csak olvasható módban a forrásmeghajtót(ext4 root filerendszer) a home könyvtárban létrehozott MX500 mappába, a célmeghajtót partícionáltam formáztam, majd a root partíciót felcsatoltam az /mnt alá. Majd következett a fájlrendszer másolás:
rsync -qaHAXS --progress=2 MX500/ /mnt
Azt googlezás után megállapítottam hogy a forrás csatolási pont után / jel szükséges, különben a forrás csatolási pont tartalma nem a célmeghajtó gyökerébe hanem az MX500 könyvtárba kerül
A --progress=2 vel állítólag gyorsul a másolás, ami igaz lehet mert elég gyorsan végzett Ezután kijavítottam a uuid-ket az fstab-ban, majd csatoltam a boot partíciót
a /mnt/boot alá, utána arch-chroot /mnt, majd pacman -S linux amd-ucode, bootctl install, szerkesztettem amit kell, és máris bootolt az átklónozott rendszerMint az látható a MagyArch iso, de akár a CalamArch iso is(kipróbáltam), alkalmas az Arch hagyományos kézi telepítésére/klónozására, közben gui-s böngészőben -firefox- tudjuk nézni az Arch wiki-t, rágooglezni valamire. Mondjuk a CalamArch nál kicsit trükkös magyar kiosztást beállítani
-
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.
-
A dd ről azt mondják hogy egyszerű és jó eszköz, viszont az üres blokkokat is átmásolja ezért általában lassú.
Arch wikiben ajánlják az e2image-t ext fájlrendszerek másolására:
File system cloning
Using e2image
e2image is a tool included in e2fsprogs for debugging purposes. It can be used to copy ext2, ext3, and ext4 partitions efficiently by only copying the used blocks. Note that this only works for ext2, ext3, and ext4 filesystems, and the unused blocks are not copied so this may not be a useful tool if one is hoping to recover deleted files.
To clone a partition from physical disk/dev/sda, partition 1, to physical disk/dev/sdb, partition 1 with e2image, run
# e2image -ra -p /dev/sda1 /dev/sdb1Ez akkor most úgy működik hogy a céllemezen létrehozom az üres ext4 partíciót és a forráslemez ext4 partíciójáról átmásolom az adatokat e2image-vel a céllemez ext4 partíciójára(a wiki-ben megadott paraméterekkel)? Használtál már e2image-t klónozáshoz? Az e2image talán gyorsabb lenne mint a dd mert csak a használatban levő blokkokat másolja, az üreseket nem.
Szerintem a nem használt blokkok átmásolása egyébként sem tenne jót az ssd-nek, ezért ssd-hez ideálisabb olyan tool ami kihagyja az üres blokkokat. -
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.
-
válasz
baloo79
#7952
üzenetére
A partclone-val valóban át tudom másolni a partíciókat, viszont utána átméretezni sehogy sem lehetett az így átmásolt partíciókat, és más gondok is voltak, pl újraindítás után elvesztek az átmásolt partícióra írt fájlok, stb, ez azért lehet mert a clonezilla a gpt-uefi vel hadilábon áll. Inkább megoldanám közvetlenül partclone-val ha lehetséges.
-
-
A partclone tud fizikai lemezről fizikai lemezre partíciót másolni? Ha igen milyen paraméterek kellenek ehhez? Tudna valaki egy példa parancsot írni, ahol ext4 partíciót másol egyik lemezről a másikra partclone-val? Erről nem találtam leírást, csak arról hogy lehet vele partíciót image fájlba menteni. Gondoltam hogy a frissen belakott friss arch telepítésemet átmozgatnám az 500-as crucial-ról az 1tb-os 860QVO-ra. Ha sikerült átmozgatni a partíciót akkor milyen parancsokkal kell átméretezni a partíciót és az ext4 fájlrendszert ? Mert ugye a céllemez nagyobb mint a forrás.
-
Shyciii
veterán
Nézegetem az Arch wikit, és találtam egy ilyet:
KMS (Kernel Mode Setting)
A KMS-re az X futtatásához van szükség (Gnome, KDE, ...stb.).
A KMS-t minden i915 DRM drivert-t használó Intel chipkészlet támogatja, sőt a 2.6.32 verziójú kernel óta ez az alapbeállítás. A xf86-video-intel 2.10 verziója óta a KMS használata kötelező. A KMS alapvetően a kernel betöltődése után indul, de lehetőség van rá, hogy engedélyezzük, hogy már bootolás során elinduljon. Így már a boot során a natív felbontáson működhet a kijelző.
Note: KMS használata esetén /boot/grub/menu.lst fájlban kernel sorából törölni kell minden "vga" vagy "video" opciót
Adjuk hozzá/etc/mkinitcpio.conffájl MODULES sorához aintel_agpési915modulokat:
MODULES="intel_agp i915"
Nem tom mennyire aktuális cikk, de ahogy nézem kötelező a használata, de ahogy nézem nekem a MODULES rész tök üres, és rendben működik, bootoláskor sincs hibaüzenet.
Most akkor hogy is van ez? -
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.
-
Shyciii
veterán
válasz
attilav2
#7946
üzenetére
Pont ezért jó még neked. Március elejei Chromium verziónál van már ez a probléma (89-es verzió), régebbiek működnek, csakhát Chromiumnál (is) különösen fontos a frissítés a biztonsági lyukak miatt.
"But all version of Chromium will be affected from March 15, even on older builds where the API keys are still present."
-
válasz
Shyciii
#7941
üzenetére
Nos, nekem a chromium engedett bejelentkezni/syncelni FreeBSD alatt. Verzió: 88.0.4324.182 (Hivatalos verzió) (64 bites) ez van a chromium névjegye alatt. Lehetséges hogy csak az újabb verziókból vették ki a google sync lehetőséget a google kérésére, lehet hogy nem az api támogatást vonták meg? Gyanús hogy így lehet. FreeBSD alatt meg egy ideje nem frissül valamiért a chromium. Nem portsból van, nem forrásból pörgettem, pkg install -al felrakott csomag. Mondjuk beleőszülnék mire ezen a gépen lefordulna a chromium
AMD X4-860K 8GB, kb 5 évvel ezelőtti vas, de még akkor sem a legerősebbek közé tartozott. -
Shyciii
veterán
válasz
attilav2
#7943
üzenetére
Brave-el az a bajom, hogy az sem a Chrome account alá szinkronizál vissza. Ennyi erővel használhatnám tovább a Chromiumot, és ha valamiért linux reinstall lesz, akkor a profilt visszatöltöm és megmaradnak az újonnan létrehozott chromium alatt. Viszont nekem pont szükség van a gougle account alá szinkronizáláshoz, mert időnként kell, hogy más gép elé mikor leülök, akkor gyorsan megkapjam a könyvjelzőimet (aztán persze annak végeztével törlöm a lokális profilt). Amúgy a Brave-t androidon használom már nagyon régóta (akkor még fejükben se született meg, hogy desktop felé nyissanak). Bár androidon már eldurvult a Brave, mert csak a user data 600MB felett van...régen még ez is egész light volt.
Akkor egyelőre marad az aur-os google chrome, de azért ez az eset a google-tól a b.zd meg kategória. -
Próbálgatom a Weston-t, hát ezen tisztán wayland módban(xwayland kikapcsolva) még annyi alkalmazás sem fut mint a sway-en, pl deadbeef el sem indul(sway-en fut natív wayland módban). Meg jóval butábbnak tűnik mint a sway, már ami a beállítási lehetőségeket illeti.
Bellőttem egy minimál weston.ini-t, xwaylenddel fut minden, az xwaylandet használó appoknak más a fejléce(így meg lehet különböztetni a natív waylanden futó appoktól), egyéni bill kombókat nem tudom hogy lehet definiálni, ha egyáltalán lehet... -
válasz
Shyciii
#7941
üzenetére
A brave-t ajánlani tudom! Elég stabil. Tedd fel a google-chrome ot AUR-ból és szinkronizáld le amit kell, majd tedd fel a brave-bin-t AUR-ból és az első indításnál felajánlja a beállítások/könyvjelzők átvételét másik böngészőkből, kiválasztod a chrome-t és szépen beimportálja magának amit kell. A brave beállításaiban bekapcsolod a szinkronizálást, generálni fog egy jelmondatot ez lesz a jelszó, mentsd el,(újra telepítéskor jól jöhet).
brave-dev-bin AUR csomag is van, ha az új featureok hamarabb kellenek, bár ez nyilván a stabilitás rovására megy. -
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.
-
Shyciii
veterán
Ahogy nézem eljött az a pillanat, hogy a CHromium már nem tud bejelentkezni a google accountba, így nincs password szinkronizáció a google accountba való mentésekkel. Azonkívűl, hogy baxa meg a google, lett erre valami megoldás? Akár a Brave browser, vagy ott is csak a sajt szerverükre lehet szinkronizálni? Vagy marad akkor a gyári google chrome használata?
-
Archttila
veterán
A clipman nekem tökéletesen bevált:
exec wl-paste -t text --watch clipman storeattilav2
itt a teljes configom hátha találsz benne valami hasznosat: [link]
Ma kategóriákra bontom külön fájlokba, a könnyebb átláthatóság érdekében (hasonlóan mint Manjaro-n)Valami ilyesmi nálam most a desktop, de amint összeáll az X86 áttémázom a waybar-t.
(lusta vagyok) -
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.
-
Egyedül a Konsole-t nem párosítanám hozzá, mert bár nem rossz terminál, de elég bloat
Azért használok egyelőre(csak akkor ha vágólap kell terminálban) konsole-t mert nem tudom hogy az alacritty kezeli e a vágólapot, kijelölés másolás beillesztés, ha kezeli a vágólapot akkor ehhez milyen billkombók kellenek. Tudsz olyan wayland képes terminált aminek van a konsole-hoz hasonló menüje és nem bloat ? -
Waybar. Innen húztam le a konfigot:
git clone https://git.sr.ht/~begs/dotfiles/
a dotfiles nevű könyvtárba jön le, sok más sway kiegészítőhöz is van benne konfig.
A waybar konfig a dotfiles/config/waybar könyvtárban található.
Innen nézek példa konfigokat:
https://github.com/Alexays/Waybar/wiki/Examples -
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á.
-
Az arch sway wiki alapján(Keymap rész) konfiguráltam a billzetet magyarra, kicsit módosítottam a wikiben látható példán, működik a magyar kiosztás ezzel:
input * {
xkb_layout "hu"
# xkb_variant "colemak,,typewriter"
# xkb_options "grp:win_space_toggle"
}input Keyboard0 xkb_model "pc105"
Az Fn+F11-re a hangerő le, az Fn+F12-re a hangerő fel, az Fn+F10-re a mute funkciót bindeltem(Custom keybindings rész a wikiben).
bindsym XF86AudioRaiseVolume exec pactl set-sink-volume @DEFAULT_SINK@ +5% bindsym XF86AudioLowerVolume exec pactl set-sink-volume @DEFAULT_SINK@ -5% bindsym XF86AudioMute exec pactl set-sink-mute @DEFAULT_SINK@ toggleEz egy logitech rádiós billzet+egér szett, mk220 azthiszem.
-
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.
-
Nem irta ki sima terminalos inditassal, csak a cvlc -v kapcsoloval jelenitette meg milyen libek hianyoznak neki es rakerestem melyik lib melyik csomagban van es felrakosgattam ami valoszinu kell a dvb-hez. Ekezetek most nincsenek mert probalgatom a sway-t egy uj telepitesen es meg nem lottem be a magyar bill-t sway alatt. Xwayland-et le kellett tiltsam mert ha inditottam valamit aminek X kellett akkor elcrashelt a sway, kitett konzolra. Ha most inditok valamit aminek X kell, hibauzenetet dob a terminalra es legalabb nem crashel a sway
Chrome, chromium sehogy sem indul wayland modban, a sati altal javasolt kapcsolokkal sem. Ellenben a brave -chromium szarmazek- igen
Jo kis alkalmazasmenu-t allitottam be magamnak sway ala, arch wiki alapjan, .desktop fajlokat is listazza:
bemenu is a native Wayland dmenu replacement which can optionally be combined with j4-dmenu-desktopAUR to provide a Wayland-native combination for launching desktop files (as i3-dmenu-desktop does):
j4-dmenu-desktop --dmenu='bemenu -i --nb "#3f3f3f" --nf "#dcdccc" --fn "pango:DejaVu Sans Mono 12"' --term='termite'A sway/config-ba a kovetkezokepp irtam be, es mukodik:
set $menu j4-dmenu-desktop --dmenu='bemenu -i --nb "#3f3f3f" --nf "#dcdccc" --fn "pango:DejaVu Sans Mono 12"' --term='termite'Elotte termeszetesen felraktam a dmenu-t ugy hogy a wlroots-t hasznalja, meg a j4-dmenu-desktop AUR csomagot. A firefoxnak es a brave-nak csinaltam az /usr/share/applications ala uj desktop fajlokat - firefox-wayland, brave-wayland - amik wayland modba inditjak megfelelo parameterekkel ezeket a bongeszoket, a regi parancsikonokat meghagytam, hiszen nemcsak sway-t hasznalok hanem KDE-t is.
-
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.
-
válasz
attilav2
#7925
üzenetére
aribb24 - ez a csomag lesz a hunyó szerintem, most letöröltem és egyből nem tudta megnyitni a vlc a dvb-t streamet, miután visszaraktam ezt a csomagot a vlc meg tudta nyitni a dvb-t streamet.
A csomag leírása:
Library for ARIB STD-B24, decoding JIS 8 bit characters and parsing MPEG-TS stream -
Meglett a megoldás, de csak úgy hogy találomra kísérleteztem. a cvlc -v MINDIGTV.channels.conf.test.hu.fta.xspf(lejátszási lista fájl) paranccsal néztem a hibaüzeneteket, hogy milyen .so-kat hiányol, rákerestem a google-n hogy az Archban melyik csomag tartalmazza a kérdéses libet, és egyenként elkezdtem felrakosgatni amelyikről valószínűsítettem hogy kell a dvb-hez, egyszercsak megjavult
Tehát szétcseszték a vlc default függőségeit K*jó 
Jó az Arch meg minden, de ezt az állandó variálást nem szeretem, miért kell szétcseszni egy eddig jól működő csomag default függőségeit ??! -
Próbálok a végére járni hogy a VLC friss Arch telepítésen miért nem képes DVB-T/C streamet/csatornákat megnyitni. Készítettem vlc log-ot ahogy próbálja megnyitni a dvb-t csatornákat, de nem sikerül: [Link] A csatornalista(xml .xspf formátum) amit próbálok megnyitni az új rendszeren(a régi pár éves Arch telepítésemen működik vlc-vel): [Link] az újszegedi adótorony fta csatornái. Segítsetek hol lehet a hiba.
-
Archttila
veterán
válasz
attilav2
#7919
üzenetére
Ezek vannak a chromium-flags.conf-ba:
--no-xshm--ignore-gpu-blocklist--enable-gpu-rasterization--enable-oop-rasterization--disable-gpu-driver-bug-workarounds--enable-accelerated-video-decode--use-gl=desktop--enable-zero-copy--enable-features=UseOzonePlatform--ozone-platform=wayland#--enable-vulkan#--enable-native-gpu-memory-buffers#--force-dark-mode--enable-features=WebUIDarkModechrome://gpu alatt
Window manager wlroots wmAz első bejegyzés workaround egy crash-elős bugra
(állítólag x86-on nem jelentkezik)Egyetértek Frawly-val, miszerint általánosságba kijelenthető, hogy az RPI nem desktop-nak való DE! nekem akkor is az a tapasztalatom, hogy egy overclocked 4GB-os PI4-en SSD-vel, pálcika WM--el és lightweight alkalmazásokkal meglepően jól teljesít az Arch. (32 bit)
Írom ezt úgy, hogy az első Arch install-om egy Ryzen 3900-en történt
nyilván más liga, de ha azt mondom, hogy ezt így a fent leírt formában napi szinten lehet használni akkor azt hidd el nem viccből írom
Csak, hogy éreztessem a különbséget: a (csak) 32bites Arch Sway kombó 1000x fluidabb élmény nyújt a PI-n, mint egy 64 bites Manjaro Xfce edition. Pedig elvileg az egy lightos kis DE-nek számít a piacon, szóval gondolhatod... -
válasz
Archttila
#7918
üzenetére
De te ARM-on vagy én meg X86-on, ami egyik platformon működik az lehet h a másikon nem, és fordítva
Letiltottam kísérletképp a sway configjában az xwaylandot sok progi ezután már nem indult el, de a fontosabb alkalmazások ezután is futottak, libreoffice, vlc, clementine(de instabil volt wayland only módban) firefox(a wayland használatát engedélyező mozilla környezeti változó beállítása után futott), chrome és változatai ellenben nem mentek wayland alatt, hiába adtam meg a megfelelő paranccsori kapcsolókat. Ha esetleg még egy környezeti változó is kell a waylandes chrome hoz kérlek írd le melyik az. -
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.
-
Kipróbáltam, és most is tesztelem a Frawly által istenített Sway-t, a kezdésben sokat segített ez a videó.
Hát elég macerás a kezelése, de a memória fogyasztás tény hogy kisebb mint a KDE-nél. A memória fogyasztást nem mondanám soványnak ~2-2.5gb a 8-ból. Xwayland letiltva, firefox fut 10 tabbal + clementine. A natív waylandes környezetben (dierkt azért tiltottam az xwaylandet hogy tesztelhessem) van jópár program ami nem indul, Pl a chrome alapú böngészők, hiába paramétereztem fel az archwikiben is írt módon(--enable-features=UseOzonePlatform --ozone-platform=wayland), sem a google-chrome-stable, sem a chromium, sem a brave-dev-bin nem indult. Ellenben a firefox egy környezeti változó beállítása után simán fut(amit a fent linkelt videóban írtak le). Libreoffice is fut, vlc is, strawberry nem megy, clementine fut, deadbeef nem fut. Még szoknom kell billentyűkkel való irányítást, de az egérrel részben be lehet segíteni
Gondolkodok egy passzív hűtésű SBC-n/miniszámítógépen(Pl Rock PI X) ami csak böngészésre és alap dolgokra lenne, és oda jól jön egy minimalista wm, mert a proci jóval gyengébb mint egy desktop / laptop-ban. Csak a böngészés végett nem akarom járatni a nagy PC-t, de laptopot sem akarok, így jöttek képbe az SBC-k. Még gondolkodok hogy Arm sbc vagy X86 sbc legyen. -
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á.
-
Shyciii
veterán
No meg is van a megoldás. St természetesen jó helyen van, és a vifmrun-t az Überzug csinálja, ami biztosítja, hogy a vifm alatt működjön az image preview, és itt van a bibi. Ez a vifmrun viszont nem rendelkezett futtatási joggal
Köszi a segítséget. Így most megkapta a 744-et (azért más ne tudja futtatni rajtam kívűl), és miden más file-ra ráküldtem a 644-et -> fd --type f --exec chmod 644 {} \; Fd parancsot használok a find helyett, mert az "jobban" működik. -
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?
-
Shyciii
veterán
A Data mappán a shyciii:users jogokat mutatja, tehát jónak kell lennie. Ennek ellenére ha nem adom ki a Data mappára (teljesre) a 744-et, akkor billentyűkombóval nem indul el a vifm. Ha csak a könyvtárakra teszem a 744-et (ami ugye kell a listázás miatt), és a fileokra 644-et, akkor sem indul el a vifm billentyűkombóval (sxhkd-t használva). Azaz érdekes, hogy ha terminálból indítom, akkor viszont elindul, így nem tudom, hogy mi a retkes baja van, így ezt anno így hagytam.
-
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.
Csak a / lenne titkosítva, systemd-boot-al. Virtuális gépben meg lehet csinálni és akkor képekkel is tudjátok illusztrálni 
Próbáltam konfigurálni a systemd-t már amennyire értek hozzá, egyszerűbb beállításokat változtattam az /etc/systemd/system.conf-ban:
![[kép]](https://clonezilla.org/clonezilla-live/doc/03_Disk_to_disk_clone/images/ocs-08-3-command-to-run.png "[kép]")
(lusta vagyok) 
Tehát szétcseszték a vlc default függőségeit 
Jó az Arch meg minden, de ezt az állandó variálást nem szeretem, miért kell szétcseszni egy eddig jól működő csomag default függőségeit ??!
Új hozzászólás Aktív témák
Hirdetés
BoB- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Path of Exile 2 early access kulcs
- Dell D6000 univerzális dokkoló USB-C/ USB-A, DisplayLink & Dell WD15 (K17A) USB-C + 130-180W töltő
- HIBÁTLAN iPhone 14 Pro 128GB Deep Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS3102
- HIBÁTLAN iPhone 14 Pro Max 256GB Space Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3009
- Telefon felvásárlás!! Samsung Galaxy Note 10+/Samsung Galaxy Note 20/Samsung Galaxy Note 20 Ultra
- iPhone 13 mini 128GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3085, 100% Akkumulátor
Állásajánlatok
Cég: FOTC
Város: Budapest