- Yettel topik
- Xiaomi 12 - az izmos 12
- Apple iPhone 15 Pro Max - Attack on Titan
- Hivatalosan is bemutatta a Google a Pixel 6a-t
- Samsung Galaxy A54 - türelemjáték
- Samsung Galaxy S23 Ultra - non plus ultra
- One mobilszolgáltatások
- Milyen okostelefont vegyek?
- Nem növel telepméretet a Galaxy S26 Ultra
- CMF Buds Pro 2 - feltekerheted a hangerőt
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
Frawly
veterán
Ez ilyen, Archon nem lehet azt, hogy csak 2 évenként frissítesz. Ez nem Debian, CentOS, meg Ubuntu LTS/Mint. Rollingnál nagyobb a pörgés, azért egy min. 3 havonta nem árt frissíteni a leglustábbaknak sem, nagyon szélsőséges esetben talán 6 havonta sem túl késő, de azzal már nem rizikóznék, mert már bőven oroszrulett szintje. De aki rollingot használ, az pont azért használja, mert friss verziókat akar, ők meg frissítenek min. hetente, de van, aki kb. naponta, mert így tudják kiélvezni az előnyét.
Aki tényleg nagyon lusta, meg fél frissíteni, az tegye fel a felsorolt konzervatív, kiadás alapú disztrókat, ott simán évekig húzhatja, hogy csak 1-2 évenként frissíti. Mert az Arch-vonal tényleg a legjobbabb, csak nem való mindenkinek. Nem, nem azért, mert nincs installer, hanem teljesen laikusoknak, akiknek a böngészőből folyik ki a Zinternecc, meg a PC egy elképzelhetetlen fekete mágia, amit a Nyílászárók hajtanak, azoknak nagyon nem ajánlott. Mondom, még a Manjaro sem, hiába felhasználóbarátnak van beállítva.
Ez kb. olyan, mikor sok fiatalt bead anyu-apu mérnöknek meg informatikusképzésre, és eleve tudják, hogy nem jók matekból (nem, nem azért, mert hülye, csak nem ez érdekli, sose volt meg hozzá a hajlama, affinitása) meg hasonlókból, de azért megrizikózzák és próbálják végigszenvedni, hátha átmennek. Valóban van is néhány, aki sikerrel jár, vagy mert össze tudja magát kapni, vagy mázlija van, de ezt ilyen alapon nem lehet mindenkinek ajánlani. Vagy pl. aki tudja, hogy lusta meg nem jó fizikum, az ne testnevelési főiskolával próbálkozzon.
Ha nálad nem ez az eset áll fenn, akkor vedd úgy, hogy nem neked szólt a hsz-em, ebben az esetben meg inkább azt ajánlom, hogy kézi csomagolgatás, meg keyringezés helyett telepítsd újra az egész rendszert, jobban jársz, tiszta lappal indítasz.
-
Frawly
veterán
Aaron Griffin távozásával Polyák Levente vette át az Arch vezetését. Nem ismerem, de sok csomagnak a fenntartója évek óta, a munkája alapján normálisnak tűnik. A leköszönő vezér amúgy sem csinált már semmit évek óta. Majd azért a Black Panthereseknek, UHU-soknak elmondhatná valaki, hogy mostantól a Nemzeti Disztró az az Arch
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Frawly
veterán
válasz
vargalex
#6557
üzenetére
Én is teljes frissítést nyomok, de most beleestem két teljes frissítés között egy ilyen felemás állapotba. Gyanítottam, hogy az újabb teljes frissítés lesz a megoldás, és így is lett.
(#6558) anorche1: terminálban kiadod az "ethtool hálózati_eszköznév" parancsot. Az eszközneved az "ip link" paranccsal tudod megnézni. Az ethtool írni fogja a Speed: résznél, hogy milyen protokollsebességgel jött létre a kapcsolat.
-
Frawly
veterán
Tegnap egy frissítés miatt eltört a Thunderbird Archon, terminálban segfault-ot dobott. A megoldás: frissíteni kell a teljes rendszert, minden csomagot, akkor helyreáll. Állítólag az sqlite csomag okozta a gikszert. Arra az esetre mondom, ha ti is belefutnátok, az Arch fórumon is panaszkodtak rá, ott volt, akinek a sqlite csomag downgrade-je segített. Nekem meg a teljes frissítés.
Ha nem frissítetek túl gyakran, nagy az esélye, hogy bele sem futtok.
-
Frawly
veterán
válasz
samujózsi
#6532
üzenetére
Nem tudom, KDE-t elég egyszerű felvarázsolni. Ha megvan az Arch alaptelepítés, akkor utána a bebootolt alaprendszeren lenyomatsz egy pacman -S plasma parancsot, ez beránt minden függőséget, SDDM, KDE, X.org. Ezután meg systemctl enable sddm és systemctl start sddm parancsokkal indítod az SDDM-et, illetve teszed be automatikus indulásba.
Ilyen GUID problémába még nem futottam bele soha. Régen inkább arra kellett vigyázni, hogy a KDE5 Wayland session-re defaultol (Fedorán, és Kubuntun is), és ezt nem szerette néhány GPU driver, ami a Waylanddel nem volt kompatiblis. De ahogy nézem, ezt már megoldották, mert a Wayland sessionhöz fel kell tenni a külön plasma-wayland-session csomagot. Ha kellenek a KDE-s alkalmazások, akkor a kde-applications csomagcsoportot is telepíteni kell.
Az Arch inkább akkor munkás, ha valami minimalista WM-et teszel fel, ami tényleg csak WM, semmi panel, háttérképkezelés, semmi alkalmazásindító, se téma, se ikonok, se automount, se semmi az ég adta egy világon, így mindenről neked kell gondoskodni egyenként, meg configfájlokat hegeszteni az összeshez, mire komplett DE-vé csiszolod. De még ez is játszi könnyedségű ahhoz képest, mintha ugyanezt Gentoo-n akarnád csinálni, vagy Linux From Scratch-ből.
De szerintem KDE-vel vagy Gnome-mal nem érdemes nagyon Archot telepíteni a gyorsaság miatt. Maximum a rollingság miatt. Ugyanis hiába pici és gyors az Arch, ha felszögel az ember bloat DE-ket, akkor már semmiképp nem lesz sok sebességelőnye előnye egy Ubuntu, Kubuntu, Mint Cinnamon, stb.-hez képest. Mondom, egyedül a rolling modell miatt érheti meg ezekkel használni.
Az Arch, Gentoo előnye akkor jön ki igazán, ha minimalista rendszert építünk belőle, mert akkor duplán lesz gyors a többi mainstream, DE-s disztróhoz képest. Alapvetően erre találták ki őket. Azért is követik a KISS alapelvet.
-
Frawly
veterán
válasz
vargalex
#6527
üzenetére
Szerintem sem hw-függő. Kár volt ennyire gyorsan feladni, mert a Manjaro egy szélesebb támogatottsággal rendelkező, modernebb, gyorsabb rendszer. Már csak a kíváncsiság is hajtana, hogy megfejtsem mitől léptetett ki több böngészőben is. Amolyan becsületbeli ügy, csak azért is alapon.
Nekem továbbra is a dátumkezelés volt gyanús, hogy terminálban még mindig nem stimmelt az idő, el volt állítódva egy órával. timedatectl paranccsal rá kellett volna nézni, hogy megfelelő időzónát, megfelelő DST beállításokat használ-e, rendszeresen frissül-e az NTP idő, a hardveres óra UTC-t használ-e.
-
#6523
Frawly
veterán
teleahocipöm
#6522
Frawly
veterán
válasz
teleahocipöm
#6522
üzenetére
Ez nagyon furcsa, mindenhogyan. Eleve a Chrome meg a Chromium ugyanaz a kódbázis, és az egyik csinálja, a másik nem. Firefoxon is kijelentkeztet?
-
#6517
Frawly
veterán
teleahocipöm
#6515
Frawly
veterán
válasz
teleahocipöm
#6515
üzenetére
Ezért írtam, hogy a dátumot nézd meg!!! Igaz dátumot írtam, de azt hittem, hogy egyértelmű lesz, hogy amit a date parancs ír ki, tehát dátum+idő. Épp azért volt ez az első tippem, mert ilyen időbélyegzős gikszereknél van az, hogy kijelentkeztet, meg nem fogadja el https oldalakon a tanúsítványt.
-
#6511
Frawly
veterán
teleahocipöm
#6501
Frawly
veterán
válasz
teleahocipöm
#6501
üzenetére
Egyébként ez az időnként kijelentkeztetés mit takar konkrétan időbelileg? Naponta, néhány naponta, hetente? Firefoxszal is csinálja?
-
#6504
Frawly
veterán
teleahocipöm
#6503
Frawly
veterán
válasz
teleahocipöm
#6503
üzenetére
A Chromium beállításai között nézz rá, hogy meddig tartja meg a sütiket, azok mikor járjanak le. Illetve ilyen sessionvesztést okozhat az is, ha a dátum nem stimmel a gépen.
-
#6498
Frawly
veterán
teleahocipöm
#6497
Frawly
veterán
válasz
teleahocipöm
#6497
üzenetére
Terminálban kiadod a glxinfo parancsot. Bár szerintem anélkül is sejtened kéne, hogy milyen GPU van a gépben, prociba integrált IGP, vagy valami dedikált GPU, abból is Nvidia vagy AMD.
-
Frawly
veterán
Átváltott az Arch zstd-csomagtömörítésre. Igaz még nem minden csomagnál, csak azoknál, amik frissültek dec. 27. óta. 1300%-os gyorsulást ígérnek. Ennyi szerintem nincs, de érezhetően gyorsabban csomagolja ki a csomagokat, tehát tényleg jelentős.
(#6495) teleahocipöm: üdv újra a fórumon. Emlékszem 2014-2015 környékén több linuxos topikban láttalak, aztán nem írtál a fórumra hosszú ideig.
A HDMI kijelző látszik a kijelzők között? Milyen GPU kimenetén van?
-
Frawly
veterán
A Fluxboxot Openbox-klónnak tartom, pedig lehet fordítva van, a lényeg, hogy az összes ilyen *box egy kaptafára megy. PekWM-et, EvilWM-et nem ismerem.
@Shyciii: valóban az Openbox nem nyújt se panelt, se háttérképkezelést, míg az IceWM tudja ezeket. Asztalkezelést egyik kisebb WM sem tud, azt valami fájlkezelővel kell pótolni. Minden WM mögött más koncepció húzódik meg. A billentyűzetről irányítás egyébként valóban hatékonyabb, gyorsabb egy billkombót megnyomni, mint egérért kinyúlni, elvinni a célterület fölé, pontosan becélozni, és csak utána kattintani. Persze vannak kivételek, rajzprogramok, videóvágó szoftverek, stb., oda jobb az egér.
Rofi helyett én a dmenu-t használom, de a Rofi is jó, sőt, van ezekhez hasonló terminálos progi is, az fzf. Igaz csak ritkán dmenu-zök, mivel minden kicsit is gyakran használt progi be van drótozva billentyűkre, kb. 52 darabra. Így általában nincs szükségem név szerinti indításra.
-
Frawly
veterán
válasz
Shyciii
#6478
üzenetére
Igen, az Openbox és az IceWM szerintem az a két legsoványabb WM, ami egy klasszik desktophoz szokott felhasználónak is használható, hiszen DE funkciókat nyújtanak. Az ennél minimalistábban csak power userekenek ajánlhatóak. Jelenleg Gentoo-n nekem is Openbox van, igaz csak átmenetileg, amíg nem találok jobbat. Az Archon használt SwayWM-et dobnom kellett systemd-logind függőség miatt.
-
Frawly
veterán
-
Frawly
veterán
válasz
#63718632
#6474
üzenetére
BÚÉK neked is. Erről az Obarun-ról még nem hallottam. Ez az S6-rc elég bonyolultnak tűnik. A Wikije alapján így kell benne szolgáltatásokat indítani:
66-tree -nE szolgáltatásfa
66-enable -t szolgáltatásfa szolgáltatásA szolgáltatásfának olyan nevet adsz, amilyet csak akarsz. A szolgáltatás neve meg elvileg lightdm.
Lehet előtte a régi login manager le kell tiltanod:
66-disable -t fája -S neve
-
Frawly
veterán
válasz
Shyciii
#6471
üzenetére
A felhasználód ~/.bashrc-jének a végére ez megy:
if [[ "$(tty)" == "/dev/tty1" ]]
then
startx
fiA ~/.xinitrc-nek a végére meg
exec wm_indító_bináris
Így ha a tty1-en jelentkezel be, és azzal a felhasználóval, akkor a WM automatikusan indul. De csak akkor. Ha tty2-7-en jelentkezel be, akkor nem, és a tty1-en akkor sem, ha másik felhasználóval, pl. root.
-
Frawly
veterán
Arra még érdemes figyelni, hogy az IceWM menüje nem tartalmazza a telepített alkalmazásokat. Ezért a menumaker csomagban lévő progival kell minden egyes újabb szoftver telepítése után aktualizálni:
menumaker -f icewmIlletve ha csíkoz a kép ablakmozgatás, görgetés, videólejátszás közben, akkor Intelnél belőni a X.org-ban a tearfree opciót, vagy feltenni kompozitort, utóbbiból most a picom a legjobb. Illetve IceWM-hez van egy csomó jó téma a themes.ice-wm.org, box-look.org, deviantart.com oldalakon.
Más tudnivaló nincs, szög egyszerű WM, eleve panellal jön, amit le tudsz cserélni, vagy ki tudsz kapcsolni. Esetleg ha bloatabb alkalmazást használsz, azoknak kellhet a d-bus meg a pulseaudio, de ez már nem IceWM specifikus.
-
Frawly
veterán
DM nem kötelező, indítható startx-szel .xinit.rc-ből. De DM-et se nehéz telepíteni, egyszerűen pacmannal felrakod. Ami trükkös ezen a ponton, hogy feltelepül az adott DM, de ahhoz, hogy boot után betöltődjön, ahhoz systemctl enable dm-neve és systemctl start dm-neve parancsokkal tudod beröffenteni.
Egy ideje login managert se használok. Konzolos bejelentkezést követően automatikusan betölt bashrc-ből a sway, ha a tty1-en jelentkezek be. Ennek csak annyi a kényelmetlensége, hogy a felhasználónevet is be kell pötyögnöm, meg a képernyőzároláskor külön progit kell használnom. Ha meg el akarom kerülni a grafikus felületet, akkor tty2-7 valamelyikén jelentkezek be, vagy a tty1-en, de másik felhasználóval.
-
Frawly
veterán
Igen, egy sima viewer progival majd csak nézd meg őket. Látni fogod, hogy ugyanazzal az MZ-s fejléccel érkeznek. Nincs új a nap alatt, meglévő technológiák mentén építkeznek tovább.
Azt meg előre megmondtam, hogy nem kell hozzá mindenféle resolvd. Amiben helyi DNS-felülbírálást akarok, azt a hosts fájlba teszem, azt minden figyelembe veszi. Még a Chrome/Chromium is figyelembe vette, pedig az nagy ívben tesz az alternatív DNS beállításokra. Lényegében a pihole is egy hosts fájl, csak ki van helyezve egy hálózati eszköz formájában, hogy minden gép tudja használni, ne kelljen egyiken sem külön állítgatni.
-
Frawly
veterán
Nagyon helyes. Szakmai fejlődés csak úgy van ha kilépsz a korábbi komfortzónából. Nehogy feladd, már van egy telepített Arch rendszered, ezt próbáld minél jobban belakni, megismerni. Az bőven nem gond, ha az első néhány telepítésnél nem sikerül valami, vagy kifejezetten gallyra megy. Az lesz a tanulópénz, meg egy jó alkalom az újratelepítés gyakorlására, meg a rendszer újra működőképessé hozására.
Nálam most ugyanez van Gentoo-n. Igaz én bonyolítom is magamnak, hogy minimalizmus möhöhőő, csak azért is legújabb RC-kernel, meg git v-9999-es bleeding edge csomagok, mert L'oreál és megérdemlem. Aztán a Gentoo meg OFF topikban ott vihognak rajtam a tapasztaltabb gentoo-sok, már előre tudják, hogy szívás lesz belőle, de szórakoznak rajta, olyan olyan vagyok, mint a prérifarkas, hogy még nem tudni hogy, de tutira szakadékban köt ki porfelhőt hagyva maga után. Meg mikor feltelepítettem, örültem, hogy van egy működő alaprendszerem. Gyorsan kiderült, hogy lófütyi nincs, nem ment az i915 driver, nem ment az Intel Wi-Fi, nem ment a Thinkpad speciális gombok és ACPI, nem volt jó az UUID az fstab-ban, nem ment semmi, csak alaposabban tesztelni kellett a rendszert, folytatni a belakását, már tornyozódnak a nehézségek. Ez az, amit nem lehet könyvből meg tanfolyamon megtanulni, csak ha az ember már azt az adott rendszert használja ténylegesen.
Nekem is voltak frusztráló dolgok az Arch Wiki-ben. Pl. eleinte Intel GPU-n állandóan lefagyott a Login Manager, mindegy melyiket raktam fel. De csak a Login Manager, az is csak néha, zároláskor fagyott le, mással nem volt gond. Hónapok után derült ki, hogy ott van a releváns infó az Intel Arch Wiki cikkben, amit ugyan el is olvastam, de ott negyedik generációról volt szó (nem szabad a X.org drivert feltenni az ezeknél újabb GPU-kre), nekem meg 2. genes Core i-s a gépem. Csak a negyedik generáció az Intel GPU-k generációjára vonatkozott, és valójában az én 2. genes procimban már 6. generációsnak számít az IGP. Nem olvastam figyelmesen, csak fourth generation, bla-bla, aztán ugrottam is át a színes dobozt, hogy csak valami nagyképű hülye okoskodik benne, mert nincs élete a lúzerjének. Kiderült nem erről van szó, kifejezetten azért volt színes dobozban, mert az inteles felhasználók zömének releváns infó, aminek a hiányától sokan szívnak.
-
Frawly
veterán
válasz
samujózsi
#6461
üzenetére
Azért lebeszélni sem beszélnék le senkit az Arch-ról. Ha nem is neki való még, próbálkozni nyugodtan lehet vele, meg akár használni, nem kell bohócnak lenni hozzá, igenis megéri használni. Csak akkor ne azt várjuk már el tőle, hogy egy sor vagy egy installer után pöccre minden úgy fog menni, ahogy Ubuntun megszoktuk. Ez nem Ubuntu, nem kiadás alapú, nem installeres, itt az embernek magának kell kiépítenie a rendszer minden elemét. Más filozófia, más rétegnek van szánva. Ennek ellenére használható kezdőknek is, nem egy kezdőről tudok, aki Arch-csal kezdett. Persze teljesen kezdőnek inkább a Manjaro-t ajánlanám, de cigam kolléga van annyira régen jelen a linuxos topikokban, hogy annyira kezdőnek semmiképp nem minősül. Szóval gyűrődni ajánlott vele, minden napra fog tartogatni ilyen új ismeretet, ma a dhcpcd-ről, holnap valami másról, végül az ember így ismeri meg a Linuxon alaposabban.
Emlékszem, hogy pl. ubyegon kollégának is sokkoló volt, hogy Archon alapból nincs fent a mesa csomag, mikor az Mint-en alapból van. Persze azt hozzá kell tenni, hogy Archon azok a dolgok, amiknek kell, pl. kompozitorok, nagyobb DE-k, stb., behúzzák függőségnek. Ez a dhcpcd is azért nem probléma, mert ahogy elkezd valaki Gnome-ot vagy KDE-t vagy hasonlót telepíteni, az mindent behúz függőségnek, login manager, X.org, mesa, Network Manager, ez utóbbi behúzza a dhcpcd-t, meg minden görcsöt, ami kell neki, nem kell semmit nyomozni, hogy úristen, mi is kell nekem.
Ezt a mi is kell nekem kérdést azoknak kel végiggondolni, akik minimalista WM-mel telepítik, mert ott se háttérképkezelés, se panel, se launcher, se hálózatkezelés, se kompozitálás, se semmi nincs, mindenről az embernek magának kell gondoskodnia, meg előre tudnia, hogy mi kell neki.
-
Frawly
veterán
Igen, ha nem tudod, mi kell neked, akkor jó eséllyel nem való az Arch. Persze gyűrődni akkor is lehet vele, tanulási célzattal. Pont ezért jó, tapasztalatszerzés miatt, hogy legalább tisztában leszel vele, hogy mi is kell neked. Meg ahogy egyre régebb óta linuxozol, úgy változni is fog, hogy épp milyen megoldásra esküszöl.
Az EFI-től nem kell félni, mert pont, hogy egyszerűbb. Nem kell ilyen os-probe-os, mountolós varázslás sem. Az EFI boot lényege, hogy van egy univerzális FAT32 bootpartíció. Egyetlen egy (elméletileg lehet több, de nem ajánlom), az összes azon a lemezen lévő OS-nek (de fel lehet venni közéjük más lemezen lévő OS-eket is). Mivel GPT UEFI boot esetén nincs MBR, ezért nem oda írja be az OS az indítókódját, hanem egy .EFI fájlba, az EFI partícióra. Így nem írogatják át az OS-ek egymás alatt az MBR-t, hanem mindegyik tud indulni a saját loaderjével.
Így ha már van fent a gépen egy UEFI-s OS, mindegy, hogy Linux vagy Windows vagy mi, akkor eleve el lesz készítve az EFI partíció, lesz loader.conf vagy valami hasonló megoldás. Akkor csak bootctl installal-lal beteszed a systemd-boot .EFI fájlját az EFI partícióra, meg a loader.conf-ban kitöltöd az EFI fájl indulási paramétereit. Vagy alternatív megoldásként nem foglalkozol loader.conf-fal és systemd-boottal, hanem mindjárt az EFI partíción lévő kernelt használod indításra EFI stub boottal, ezt efibootmgr -c paranccsal tudod hozzáadni az UEFI BIOS bootbejegyzései közé az NVRAM-ba.
Egyébként meg UEFI-s gépen lehet továbbra is hagyományos BIOS bootot használni MBR-rel. Egyedül 2020 után készült, vadi új Intel lapoknál lesz csak megvonva ez a lehetőség. A régebbi lapokon, meg az összes AMD-n támogatva van.
Egyébként az EFI egy nagyon érdekesre kitalált dolog. Lényegében egyfajta 64 bites DOS. Nem röhögni, tényleg ez az igazság. Ezért is van FAT32 kitalálva EFI partíciónak, és nem ext, nem NTFS, nem más. Hiszen az .EFI fájlok MZ-fejléces DOS .exe fájlok, .exe kiterjesztés nélkül (a kiterjesztés mindegy), de nem tartalmaznak DOS vagy BIOS hívásokat (mint a legtöbb DOS program), hanem bare metal binárisok, közvetlenül a „vason” futnak, OS közbeékelése nélkül. A neten vannak olyan pihent agyú kockák, akik ilyen ASM-ben írt DOS bare metal progikat bootolnak be UEFI-vel (primitív játékok, képernyővédők, grafikus demók), pontosabban EFI stub boottal
A sors iróniája, hogy hagyományos MS/PC/stb. DOS nem bootolható be UEFI-vel, mivel még ugyan .EFI binárisként be lehetne bootolni elvileg, de az UEFI 64 (ritkán 32) bites védett módra lövi be a procit, a DOS meg nem kapcsolgat bootkor x86 proci módot, hanem csak 16 bites valós módból (x86 real mode) tud indulni. Bár elvileg a FreeDOS-t fel lehetne készíteni erre. -
Frawly
veterán
Ezt értem, hogy neked frusztráló, sajnálom. Nem is védeni akarom őket, de azt értsd meg, hogy az Archnak az a szemlélete, hogy semmit nem tesz be a telepítési folyamatba, ami nem minden embernek kell, vagy nem csak egy verzió van belőle. A linux csomagot is azért vették ki a base-ből, mert nem mindenki a legújabb stabil kernelt akarja használni, hanem mondjuk Zen-t vagy LTS-t, és akkor az így a base részeként nem kerül fel feleslegesen a legfrissebb kernel, és nem kell felesleges csomagot frissítgetni, meg leszedegetni. dhcpcd szintén zenész, mert mint olvasod, van, akinek nem kell. Tehát akinek kell, külön fel kell tegye, ami egyébként a legtöbb ember, mert a desktop felhasználók 99,99%-a Wi-Fi routerről nyomatja, ami tipikusan DHCP-s. Ez az Arch alapfilozófiája, ha nem feltétlenül kell az userek 100,00%-ának, akkor opcionális csak. Épp ezért nincs az Archnak telepítője. Azt honnan látnák előre, hogy te majd milyen kernelt, hálózati megoldást, stb. szeretnél? Ubuntun ez el van döntve, itt nincs.
Arch Installation Guide-ból régen kettő volt, egy felületes nagyon kezdőknek, meg egy részletes haladóknak. Ez utóbbi lett meghagyva, a kezdőknek szóló törölve lett az Arch Wiki-ből, mert párhuzamosan futottak, és a kezdős anyag nem volt rendesen karbantartva, el volt avulva, ellentmondott a másiknak. A mostani Installation Guide-ban ott van benne az a bekeretezett rész a dhcpcd-ről, amit te is észrevettél. Meg a Guide legvégén ott van a bootloader telepítésére utalás, ami elkalauzol linkekkel a vonatkozó cikkekre, amik az egyes bootloaderekkel és bootolási módokkal foglalkoznak. Tehát ott van minden, csak át kell látni, mindent el kell olvasni, nagyon figyelmesen. Nem szabad vakon csak a parancsokat követni, úgy valami könnyen kimarad.
-
Frawly
veterán
válasz
#63718632
#6453
üzenetére
Imho a Gentoo nem éri meg mindenkinek. Még az is elképzelhető, hogy arra jutok, hogy nekem sem éri meg a beletett munkát. Nem tudom még, nem tartom valószínűnek, mert már így is volt pozitív hozadéka, egyszerűsödött az initrendszer, egyszerűsödött a boot, már tanultam belőle egy csomó mindent, hogy konfigurálunk fordítandó kódot, mely csomagok bloatak igazán. Ez az, amit nem tudsz addig, amíg meg nem próbáltad a Gentoo-t.
Archra átállni viszont teljesen megéri, ezt több év archozással a hátam mögött mondom. Szerintem simán jobb, mint akármelyik másik bináris disztró. Azért nincs telepítője, mert rád bízzák, hogy milyen funkcionalitást milyen megoldással valósítasz meg. Te döntöd el, hogyan bootolsz meg milyen hálózati kapcsolódásos megoldással éred el a netet, milyen grafikus felületet és protokollt használsz, stb.. Egyedül csak az van Archon eldöntve, hogy systemd-s és initramfs-ses. Minden mást meg tudsz változtatni (igazából ezt a két kötelező elemet is ki tudod belőle hackelni), csak azt a csomagot kell feltegyed, amire valóban szükséged is van. Az is nagyon jó, hogy rolling, friss csomagokkal, de ahhoz képest mégis elég stabil, nem kell distro-upgrade-ekkel szívni kiadások között, meg elavult csomagverziókkal küzdeni. Az Arch még nem über geekség.
Bár eddig nekem a Gentoo sem tűnik sokkal nagyobb számnak. Egyedül az macerás, ha valami spéci fordítási opciót akarsz, pl. hogy mit forgass bele a szoftver kódjából a bináris szoftverbe, vagy a legeslegfrissebb verziókat. Ott lehet vele szívni, de amúgy nem tűnik nagyobb számnak az Archnál. Na meg az egy kicsit kellemetlen, hogy állandóan várni, míg kódból fordul valami le, ha nincs izom géped, akkor nagyobb csomagoknál szívás annyit várni. Persze, míg fordul a kód, addig használhatod másra a gépet, de azért sokkal kellemetlenebb ahhoz képest, mint egy kész bináris csomagot felpasszintani.
-
Frawly
veterán
válasz
samujózsi
#6451
üzenetére
Ja, pont ezt mondom én is, hogy nem kell, de azért a disztrók erőltetik, mert valakinek hátha kell alapon, rá van tukmálva mindenkire. Az a baj, hogy a systemd tele van ezekkel, ha kell, ha nem, le van nyomva az ember torkán, pedig vagy szüksége sincs rá egyáltalán, vagy ha van, sokkal egyszerűbb, könnyebben konfigurálható formában is rendelkezésre áll. Aztán ilyen flame-topikokban nem szokták érteni, hogy mi a baj a systemd-vel. Többek között az ilyen húzások.
-
Frawly
veterán
Akkor szerintem én vagyok a villamos, mert használtam már Archot, többféle gépen, Wi-Fi-on és Ethernet-en keresztül is netezve, és a /etc/systemd/network/ mappában soha semmit nem kellett matatnom, az pl. most is holt üres. Rendesen telepítettem őket, kézzel, semmi segédszkript, meg 3rd party installer.
A network mappában matatást két esetben tudom elképzelni, hogy fontos: 1) több Ethernet vagy több Wi-Fi-chip van ugyanabban a gépben, és választani kell melyikkel kapcsolódjon, vagy 2) speciális DNS szabályokat akarsz felállítani (piehole) csak kifejezetten arra az eszközre, de ez utóbbit lehet Network Managerben is, még csak grafikus felület sem kell hozzá, mert van TUI-s része is (nmtui vagy nm-tui vagy minek hívják), vagy módosítások ellen védeni a /etc/resolv.conf-ot.
De mint írtam, Archon sem engedem beavatkozni a systemd-t a hálózat kezelésébe. Azért mert a netctl vagy akár a NetworkManager hol elvesztette a Wi-Fi-t (ez régebben volt), vagy feleslegesen sokáig vártak rá, és feltartották a bootfolyamatot, ez utóbbiból lett elegem. Persze, működik systemd-vel is, csak köszönet nem lesz benne. Helyette a szög egyszerű, wpa_supplicant (Wi-Fi) + dhcpcd simán működik egymagában, mindenféle systemd-s beavatkozás nélkül, és megy, se Wi-Fi-ról leszakadás, se bootkor várakozás. Ethernetnél wpa_supplicant sem kell, csak dhcpcd egymagában. Az egyszerűség sokszor kifizetődő. Pedig van speciális DNS szabályom is, a szolgáltatói DNS-sel sok oldal nem jön be, ezért 1.1.1.1-es nyílt DNS-t használok. A dhcpcd meg eleve úgy van kitalálva, hogy működik systemd-vel és anélkül is.
Ezt nem hiszik el nekem a Debian, Ubuntu, Mint szentháromságon nevelt MBR GRUB Matyik sem, hogy az egyszerűség sokszor kifizetődő. Felhörögnek, hogy GPT soha, fújj UEFI, nem bootol, kiazakiesztaszrtkitatálta. Közben meg GPT UEFI EFI stub vagy EFI systemd boot holt egyszerű, semmi MBR-kód, semmi elsődleges meg kiterjesztett partíciózás, semmi bootflag, semmi GRUB meg grub.cfg meg GRUB-frissítési gikszer. Helyette csak egy FAT32 EFI partícióról betöltődik az UEFI BIOS-ban hivatkozott .EFI fájl (ez a kernel), esetleg felparaméterezve (systemd bootnál .conf fájlból), és a rendszer bootol. Sose törik el semmi bootolás megkezdésekor, mert nincs külön bootmanager, ami eltörjön, és az EFI partíció megmarad bootképesnek egy teljes rendszerújratelepítéskor is (pl. ha újrahúzza valaki az Archot). Ezt meg hiába mondod neki, lázadnak, hogy GRUB az akkor is kell, mert a fogakat is tisztíccsalya, meg Debianék jobban értenek hozzá, és ők nem tévedhetnek. Közben meg én leszek a hülye, mert simán bootol GRUB nélkül nálam, nem csak az Arch Wikiben terjedő mendemonda, még Gentoo-n is megy, ahol systemd sincs (vagyis van, ha úgy akarod, de default nincs). Persze megy az UEFI boot GRUB-bal is, meg lehet oldani, csak minek plusz egy bootloader a működési folyamatba beláncolni. Ez kb. olyan, mintha egy szekrényt kulccsal bezárnék, azt betenném egy másik szekrénybe, és azt kulcsra zárva annak a kulcsát hordoznám, ennyi erővel az első szekrény kulcsát is őrizgethetné az ember. Ez a fő rákfenéje újabban a linuxos világnak, a dolgok felesleges bonyolítása, főleg olyan átlagos desktop rendszeren, ahol csak Pistike netezik, meg ext4 partíciókat használ mindenféle LVM, RAID, LUKS, ZFS, snapshotok meg minden nélkül. Mert valóban van, ahol bonyolítani kell, de az nem desktopos felhasználás, vagy nem átlagos.
Pedig nekem GRUB-bal sem volt soha bajom, személy szerint, nálam mindig probléma nélkül működött, pöccre. De minek legyen egy felesleges telepítési lépés, felesleges csomag letöltése, (esetleg felesleges fordítása forráskódból emerge-kor), telepítése, felesleges frissítése, felesleges hibaforrás. Minek, ha egyszer felesleges, ráadásul tényleg hibaforrás, mert sok felhasználót látok vele szenvedni, hogy el-eltörik nekik frissítéskor.
-
Frawly
veterán
Szerintem nem használja a helyi pihole-os DNS-t, hanem helyette azt a szolgáltatóit, amit a routertől kap, a szolgáltatói DNS-ben meg csak a WAN címek vannak, LAN-os nincs. Csak tipp. Rá kéne erőszakolni a hálózati kapcsolatok beállításánál, hogy a pihole-féle DNS-t használja. Ezt végső soron be lehet írni a /etc/resolv.conf fájlba, nameserver Mö.Hö.Hö.Hő IPv4 formában, de azt alapból felülírja a drágalátos systemtré (igen, jól mondjátok, tényleg zseniális alkotás) bootkor, amit meg lehet ugyan akadályzni, ha elveszed róla az írási jogot, de az meg nagyon favágás (amit Archon meg is léptem).
Egyébként a helyi háló neveinek feloldására egyáltalán nem kell systemd-resolvd. Az csak ahhoz kell, ha azt akarod, hogy a systemd is állítgassa a /etc/resolv.conf-ot vagy valami másik systemd-megoldást akarsz mögé, pl. Network Manager.
Nálam Archon is, system-resolvd nélkül működik a dhcpcd, simán kezeli a resolv.conf-ot. Gentoo-n meg megint csak egymagában dhcpcd, ott az OpenRC miatt szóba sem jön egyéb megoldás.
Helyi címeket fel tudsz venni a /etc/hosts fájlba is, pl.:
192.168.2.1 router
192.168.2.2 pihole
192.168.2.3 gép2 -
Frawly
veterán
válasz
samujózsi
#6440
üzenetére
Neked ez volt az első, és utánaolvastál a telepítési útmutatóban. Aki viszont régebb óta archerkedik, az 17 év alatt már megszokta, hogy a base csomagcsoport tartalmazott egy kulcsra kész alaprendszert, fordításhoz, hálózatkezeléshez, configfájlok szerkesztéséhez. Aztán sok ember vagy emlékezetből telepít vagy sok kezdő megnéz olyan tutorial videót, mondjuk a distrotube YouTube-csatornán, ahol még a régi módszert mutatják be telepítésnél, és ott esnek pofára, hogy nem működik, mert se nano, se kernel, se semmi.
Egyébként itt az lett volna a megoldás Archék részéről, hogy megtartják a base csomagot, és base-new vagy base-minimal néven létrehoznak egy másik csoportot, amit csak haladóknak ajánlanak. Vagy a régi megtartották volna base-old vagy base-legacy néven, és mindenki könnyen aktualizálta volna a saját telepítési útmutatóját.
Megértem a döntésüket, hogy miért nyirbálták meg a base-t. Az Arch filozófiája a minimalizmus, keep it simple, csak az kerüljön fel a rendszerre, amit használsz is. Na már most a base csoport (bár nem volt kötelező használni, de leírások miatt mindenki használta) felnyomott egy rakat csomagot, linux kernel, nano, vi, stb., holott lehet a fele szükségtelen volt, mert valaki eleve a linux-lts vagy linux-zen vagy hasonló spéci kernellel akarta telepíteni, meg nano vagy vi helyett mással. Ezért kiszedtek minden felesleget, ergo szerintem teljesen kinyírták a base csoportot. Ez jó hír volt néhány minimalista advanced usernek, hogy többé az Arch telepítést nem úgy kell folytatniuk, hogy leszedegetnek felesleges csomagokat (noha a base-t használni eddig sem volt kötelező), viszont cserébe a kezdőket, meg a régi leírásból telepítőket csúnyán megtréfálta.
-
Frawly
veterán
Nagyon megritkították a base csoportot. Már csak a gcc-libs-et teszi fel, meg a pacman-t. Minden más kikerült belőle, nano, vi, dhcpcd, meg minden. Nem csak a linux, linux-firmware. Fel kell tenned kézzel: pacman -S dhcpcd, de ha már ott vagy, nézd meg mi nincs fent a rendszeren, és mindent telepíts. Bár függőségnek úgyis behozzák a programok, amiknek kell, pl. wicd, wpa_supplicant, Network Manager, stb..
-
Frawly
veterán
válasz
_Dumber_
#6430
üzenetére
Na, ez a fajta szívás nem hiányzik nekem, azért nem használok többé ilyen bloat megoldásokat, mint ezek a Kakrámik, KDE, Dolphin, stb.. Inkább terminálban csinálok mindent, inkább root jogozok, inkább szerkesztek konfigfájlokat, de terminálban legalább látni, hogy mi a hiba, és sokkal egyszerűbb is elhárítani őket.
Ami tippem lenne a problémád megoldására: ideiglenesen állítsd be a Google-nél, hogy minden alkalmazás és eszköz korlátlanul, engedélykérés nélkül hozzáférjen az accountodhoz. Majd próbálj újra kapcsolódni a lépések alapján. Ha így megy, akkor visszacsinálod a korlátlanra engedélyezést (bekapcsolva hagyva biztonsági kockázat), tehát újra egyéni engedélyezési alapon lekorlátozod, és tudni fogod, hogy az engedélyezéssel van a baj.
-
Frawly
veterán
válasz
samujózsi
#6424
üzenetére
Nyugi, ezeket a disztrós meg linuxos neveket senki nem tudja kimondani, még Amerikában sem. Össze vissza Díbiön-öznek meg Júbántuznak a Debiön és Úbuntu helyett, ahogy mondani kéne. Vagy a Gnome-ót hol Nóm-nak, hol Gnóm-nak, hol gö Nóm-nak mondják. Még maga a Linux név sem egyértelmű, mert a legtöbben a bevett Linöksz-ként ejtik, de lehet Linuksz-nak és Lájnöksz/Lájnuksz-nak is ejteni, Linus angolosított neve alapján.
A Gentoo-t és sokszor Gentó-nak mondom, pedig Dzsentú-nak kéne. Ez állítólag valami gyorsan úszó pingvinfajtáról kapta a nevét, de nagyon gyanúsan a Gen2-őt lehet beleérteni. A Mate sem Máte, sem nem Mé(j)t, hanem Ma Té.
De például a Wine-t is vine-nek mondom rossz megszokásból, mikor ~vájn-nak kéne.
-
Frawly
veterán
A GRUB egy nagy monstum. Ezt akkor veszed észre, ha pl. Gentoo alatt forráskódból fordítod, valami ~750 MB a forráskódja, és nálam az a gép, ami a defconfigos legújabb kernelt ~12 perc alatt fordítja, a GRUB-ot 25-30 percig forgatta. És ezt minden frissítéskor el kell játszani.
Ehhez képest az EFI stub boot csak egyetlen sor bejegyzés az UEFI BIOS-ba. És egy szabvány kernelbinárist indít, ami egyben EFI bináris is. Annyira egyszerű, mint a szög, nem kell hozzá adott esetben semmit telepíteni, semmit frissíteni, 0 dolog van, ami egy frissítéskor eltörhet, 0 erőforrást használ. Ugyanis az UEFI már egymagában is egy bootmanager, felesleges mögé beláncolni egy másikat. Ezeknek az egyszerű megoldásoknak szépsége van, ezt csak akkor érted meg, ha kipróbálod, megérted a működésüket.
Van itt egy kolléga, ubyegon, ő mindenáron ragaszkodik a Legacy BIOS MBR boothoz, MBR-hez, meg a GRUB-hoz. Kétszer megpróbált UEFI bootot is, de a szerencsétlen grafikus telepítők vagy elcseszték neki, vagy a HP laptopja nem szabványos UEFI-jű. Ebből levonta azt a következtetést, hogy az UEFI ×4r, egy átláthatatlan fekete mágia, ő azt soha többet. Az a baj, hogy az UEFI-val sokaknak az a baja, hogy nem értik meg, meg rosszul próbálják használni, és ez kudarcélményhez vezet, és máris rohannak vissza a jól megszokott MBR + GRUB-os megoldásokhoz. Nagy úr, ha valamit ismersz és mindig beválik. Sokan így ragadtak XP-n is, meg majd most 2020 januárja után Win7-en is. Pont ilyen indoklással, hogy régen jó volt, most is megy, minek piszkálni.
Már pedig ha valaki egy minimalista rendszert épít, akkor miért ne legyen a bootolás is modern, meg parádésan egyszerű? Ha GRUB kell, feltelepítek 2 perc alatt az Ubuntut, azon lesz minden szabvány megoldás out of the box, GRUB, systemd, Gtk + Gnome, X.org + Wayland, meg stb.. Csak akkor szopó, ha ezek többjére épp nincs szükségem, akkor minek tenném fel? Ubuntut feltelepíteni Áltsulis Pistike is tud, abban nincs semmi művészet, meg informatikai tudás.
-
Frawly
veterán
Ez nem mazochizmus. Nincs semmi baj a GRUB-bal, de van egy tudásszint, ami fölött meg tudsz lenni nélküle, teljesen el tudod hagyni, és jóval egyszerűbb megoldásokat tudsz használni helyette, amik nem törnek el frissítéskor, és század annyi erőforrást sem esznek. Lásd előző hozzászólásom.
Ráadásul ezeket a minimalista EFI stub és EFI systemd bootos megoldásokat nem is nehéz megcsinálni. Szívni csak eleinte kell vele, amíg meg nem érted hogy működik, meg ki nem tapasztalod, onnantól viszont egyszerűbbé válik, mint a GRUB.
Ezért nem szabad egyféle megoldásnál leragadni, csak azért, mert azt megszoktad, meg már érted.
-
Frawly
veterán
válasz
samujózsi
#6403
üzenetére
Ja, vagy az efibootmgr-rel kell a régi bootbejegyzést törölni és újat csinálni a helyére, vagy az UEFI BIOS-ban kell új bejegyzést kézileg felvenni, vagy ebben az EFI shellben kell indítani a kernelt, és ott mögé írni a paramétereket. Ez az ára, ha nincs bootmanager, de cserében nagyon egyszerű, bloatmentes megoldás. Egyébként a leírásodból úgy vettem észre, hogy ott rontottad el, hogy nem látta az EFI partíciót.
A systemd EFI boot annyiból könnyebb, hogy az nyújt egy minimális menücskét, ahol már nem is tudom milyen billentyűre lehet szerkeszteni a bootparamétereket, ahogy GRUB-ban. Meg kényelmesebben be lehet vele bootolni több OS-t és kernelt.
A GRUB-ot viszont nem szoktam erőltetni, ha nincs rá szükség. Az csak olyan speciális esetekben kell, ha ZFS partícióról akarsz bootolni, meg RAID van vagy hasonlók. Átlag desktop linuxnál kb. 0 értelme van, ha mindenből deafult beállítást használ valaki.
Azért mondtam, hogy minden megoldásnak megvan a maga előnye, maga rugalmassága vagy egyszerűsége, de ezek egymást kizárják, valami vagy bloat, vagy minimalista, vagy egyszerű, de akkor rugalmatlan, vagy bonyolult, de akkor rugalmas, többféle felhasználási kört is lefed. Ez mindenkinek egyéni, hogy mire van szüksége, mire használja, ehhez milyen megoldást választ, ezért mennyi bloatságot hajlandó fizetni.
Sőt, QEMU-n még olyat is lehet, hogy EFI partíció sincs, hanem a virtuális gép UEFI BIOS-ába az EFI kernel binárist a host felöl adagolod be, qemu paraméterként, és azzal indul a rendszer. Ennek csak az az egy kényelmetlensége, hogy a kernelt akkor a host gépen kell forgatnod.
-
Frawly
veterán
válasz
samujózsi
#6400
üzenetére
Elvileg, amiket írtál, azokat jól csináltad pedig. A hiba abban lehet, amit nem csináltál lépésként. Azt viszont nem értem hogyan kapsz UEFI shellt. Ha nem is bootol a cuccos, akkor is egy bootmenüt kéne visszaadnia, hogy válassz másik bootmeghajtót.
Próbálj meg kézzel, Esc megnyomására előhívott UEFI-ben, rámenni a Boot Manager menüben az EFI internal shellre. Ebben kézileg kezdesz megint navigálni:
fs0:
vmlinuz-linux initrd=initramfs-linux.img root=PARTUUID=bla-bla rwÍgy mit ad vissza?
-
Frawly
veterán
válasz
samujózsi
#6398
üzenetére
Ja, hát ezt ne is a Google-lel oldd meg, hanem az Arch Wiki telepítési útmutatóját kövesd, és azon kívül az EFISTUB szócikkét. Fontos, hogy lépésről-lépésre kövess mindent.
Nem szabad összeguglizott blogcikkeket használni helyette, azokban lehetnek helytállótlan és elavult lépések, megoldások. Sőt, régen az Arch Wiki-vel is vigyázni kellett, mert két telepítési leírás is volt rajta, egy részletes, Installation Guide címen (ez mindig ott van), meg egy getting started (vagy mi volt a címe) gyorstalpaló kezdőknek, utóbbiban velősebben volt összefoglalva a telepítés menete, de cserébe tele volt olyan elavult infóval, amit a részletes útmutatóban már javítottak, vagy frissítettek.
-
Frawly
veterán
válasz
samujózsi
#6396
üzenetére
Ez a KVM EFI nálad pontosan mit takar? Én a QEMU-t -enable-kvm kapcsolóval használom és OVMF Tiano Core UEFI firmware-rel. A Gentoo-t szépen bootolja EFI stub boottal, Archot még nem próbáltam rajta.
Azok a lépések kritikusak, amiket írtam. Különösen az initramfs generálása, amit minden kernelfrissítéskor és kernelcserekor meg kell lépni. Frissítéskor a pacman megcsinálja neked, de ha kézileg cserélsz kernelt, mert pl. saját magad által fordítottat használsz, akkor kézzel kell leküldenek az mkinitcpio-t.
-
Frawly
veterán
EUFI bootnál nincs olyan, hogy egy lemez bootolható-e vagy nem. Nincs olyan boot flag, mint MBR-nél. Az UEFI nem a bootflaget keresi, hanem a FAT32-re formázott EFI partíciót, és az azokon lévő binárisokat.
(#6389) samujózsi: Archon nekem sem megy az EFI stub boot, amit te akarsz használni, pedig jól csinálod, én is így próbáltam, és nekem sem ment sehogy sem. Viszont az EFI systemd boot az alig más ettől, és az simán megy Archon, ha az érdekel, abban tudok segíteni, úgy UEFI-val még egyszerű bootolni, úgy, hogy nincs GRUB.
Egyébként EFI stub bootnál azt ellenőrizzed, hogy a kernel a -l "\vmlinuz-linux" binárissan induljon, és a paraméterek így add át neki: -u "initrd=initramfs-linux.img root=PARTUUID=bla-bla rw".
Illetve még fontos, hogy chroot környezetben, felcsatolt boot partíció után lefuttasd az initramfs-t generáló scriptet:
mkinitcpio -p linuxMaga az efibootmgr a nevével ellentétben nem bootmanager, csak egy bejegyzést tesz az UEFI-be, elhelyezve az UEFI RAM-ben egy egy soros bootbejegyzést. De ilyet sok UEFI-ben kézzel te is tudsz csinálni, efibootmgr használata nélkül is.
-
#6387
Frawly
veterán
gentlemann02
#6386
Frawly
veterán
válasz
gentlemann02
#6386
üzenetére
Igazából majdnem mindegyik Arch-klón egyforma, mindegyik egy normál Arch, kiegészítve grafikus telepítővel, meg esetleg grafikus csomagkezelővel. A Manjaro annyiból speciális, hogy ők tesztelik az Arch-csomagokat kicsit tovább, nem azonnal veszik át az Arch csomagjait.
-
Frawly
veterán
válasz
Shyciii
#6375
üzenetére
Nincs ezzel gond. Az ilyen minimalista WM-eket azoknak csinálták, akik mindent bill-lel irányítanak, sose egereznek, és szinte csak terminális alkalmazásokat használnak (pl. Double Commander helyett Vifm, Ranger, mc, nnn, stb.). Neked azért nem tűnik élhetőnek. Azzal egyetértek, hogy az Openbox már szinte annyira sovány, hogy annál nem sokkal leszel előrébb egy még fapadabb WM-mel.
Egyébként sokszor nem is a WM határozza meg, hanem hogy mit telepítesz mellé, milyen tálca, milyen rendszerértesítések, milyen appok a tálcára, mik futnak a háttérben.
Pl. nálam egy Gentoo alaprendszer konzolos boot után 29 mega memóriát foglal. Egy Arch meg 100-at. Grafikus felületeket betöltve Xorg+dwm Gentoo-n 52 mega memóriát eszik összesen, mindennel együtt ennyi az össz memóriahasználat. Archon meg 145 MB a Wayland + SwayWM. Persze nem fair összehasonlítás, mert Archon fut a systemd, egy rakat systemd-s szolgáltatás (háttérvilágítás, NTP, stb.), Terminus font kezelés konzolban, Pulseaudio, azaz tele van Poettering-bloat-sallanggal. Ezzel szemben a Gentoo alaprendszerem még nem belakott, így se ALSA, se Pulseaudio, a systemd-nek nyoma sincs, helyette openrc van. De azért szépen látszik, hogy milyen szépen növögetnek a memóriafogyasztások +100 megákkal. Mondom, nem is azzal van baj, hogy a memóriát foglalja, mert szűken, de 16 GB RAM-ba beleférek, persze össze kell húzni, mert alapból csak ilyen 8-10 giga áll üresen. Hanem hogy betölt ennyi komplex szart, aminek a 75%-ára nincs szükségem, fölöslegesen növelve a komplexitást, függőségeket, minél több modul tölt be, annál nagyobb az esélye, hogy valami eltörhet egy frissítéskor, stb.. A Linuxnak pont ez a lényege, hogy a UNIX filozófiának megfelelően minden moduláris és szabadon választható benne, olyan kernellel, olyan init rendszer használsz benne, olyan audiórendszerrel, olyan ablakkezelővel, olyan kiegészítőkkel. olyan témákkal, olyan alkalmazásokkal, amilyet épp akarsz, nem kell azt használni, amit egy öltönyös-nyakkendős céges barom kitalált előre. Pont ez a baja a systemd-nek és a Pulseaudiónak, hogy kötelező használni, mert szinte mindeni rádependel, ezzel meg megsértik ezt az alapelvet.
Felhasználásfüggő is. Nekem teljesen jó lenne az udev + jmtpfs, mert csak egyetlen telót csatlakoztatok. Nekem teljesen felesleges, hogy állandóan fusson a gvfs + gvfs-mtp. A pulseaudio-val is az a gondom, hogy csak a Firefox miatt van fent, és rágok, hogy egy alkalmazás hülyesége miatt fut egy bloat szar. Mert ugyebár az ALSA is megfelelő lenne, a pulseaudio lényegében egy ALSA fölé húzott szerver-kliens alapú vezérlőréteg. Az ALSA önmagában bőven elég lenne, hogy egy alkalmazásnak legyen hangja.
-
#6380
Frawly
veterán
gentlemann02
#6378
Frawly
veterán
válasz
gentlemann02
#6378
üzenetére
Elvileg mindegy, de a Manjaro-nak nagyobb a támogatása. Esetleg ha systemd-mentes vonalon akarsz továbbmenni (MX Linux systemd-mentes), akkor Artix-ot is bepróbálhatod, az is Arch-klón, de systemd nélkül. A konfigoddal nem lesz gond, AMD CPU, AMD APU GPU, mindegyiket támogatja rendesen a kernel, meg a benne lévő nyílt kerneldriverek, a hardver ereje és a memória is elég, hogy elvigyen akármilyen linuxot. Hacsak nincs valami rohadt spéci Wi-Fi vagy tuner kártyád, esetleg nagyon ritka nyomtatód, akkor nem lesz gondod egyik disztrón sem a drivertámogatással.
-
Frawly
veterán
válasz
Shyciii
#6375
üzenetére
Akkor lehet rosszul emlékeztem a fogyasztására. És itt nem az a baj, hogy fogyaszt memóriát, hanem akkor is foglalja, ha nem használsz MTP-t épp. Ez itt a gond. Elindul, fut a háttérben. Ha csak addig foglalná, amíg ténylegesen használom, akkor nem érdekelne.
Egyébként elméletben a jmtpfs-t is lehetne automatizálni, egy udev szabályt felvenni, ha az adott usb eszközt csatlakoztatják (ezt ki kell nézni, hogy mit ír ki rá, amikor a teló csatlakoztatva van), akkor automatikusan futtassa le a jmtpfs-ses scriptet. De még nem csináltam ilyet.
-
Frawly
veterán
válasz
attilav2
#6373
üzenetére
Szerintem amdgpu driverrel előre lefordítja és betölti a shadereket. amdgpu pro drivernél meg úgy van beállítva, hogy játék közben töltögeti őket.
(#6370) Shyciii: hidd el, ez személet kérdése. Ahogy anno láttad, hogy egy openboxos linux rendszer mennyivel egyszerűbb és pattogósabb egy KDE-hez képest, úgy mindenben lehet egyre minimalistább megoldást találni. Valahol szokni is kell folyamatosan, nem lehet azonnal az ultraminimalizmusba belemenni, mert az elsőre használhatatlan lesz. Mindig csak annyiban kell minimalizmusra törekedni, amennyiben még számodra használható a rendszer, ez majd változik idővel, ahogy fejlődsz minimalizmus terén.
Nálam pl. a jmtpfs nem foglal semmi memóriát, mert alapból nem fut. A 0 megás memóriafoglalással semmilyen más megoldás nem tud versenyezni, akkor sem, ha csak 1 bájtot foglal. Annyi, hogy a telefon nem csatlakozik automatikusan, de ez nem baj, mert a csatlakozás megtörténik, amikor Vifm-ben rámennék a teló mappájára, ahová fel szokott lenni csatolva. Eleve úgyse lesz teljesen kényelmes egy androidos teló csatolása MTP-n, mivel biztonság miatt neked kell a telót felébreszteni, bekapcsolni kézzel rajta az MTP-t, és még utána hiába is csatolja automatikusan a gvfs-mtp, még fájlkezelőben úgyis át kell váltsál rá, ha másolni akarsz rá valamit.
A régi andoridos telók, 4-es verzióig bezárólag még annyiból voltak kényelmesek, hogy volt rajtuk USB Mass Storage funkció, ott tényleg elég volt, hogy gépre dugtad a telót, semmilyen képernyőzárat, meg semmit nem kellett oldogatni hozzá, se MTP-t minden egyes alkalommal bekapcsolgatni, és azonnal fel is csatolódott. De MTP-vel sose lesz már ilyen kényelmes, biztonságilag úgy van tervezve az Android, hogy csak kényelmetlenül tudjál MTP-vel kapcsolódni, nehogy valaki a hátad mögött csatlakozzon hozzá így, és tudtod nélkül matasson valahogy a telódon az adataid között.
Egyébként azt a gvfs-mtp-t nézd meg még egyszer, mert nem csak 36 MB, fut mellette a gvfs is, meg még annak pár másik modulja, adj csak szépen össze mindent. Van az majdnem 100 mega, hidd el. Meg nem is ezzel van baj, hanem egy full extrás Linux DE-nek minden része ilyen, egy ki 100 mega itt, egy is 50 mega amott, és szép apránként a végére kijön, hogy +500-1000 mega. Ha pedig elérsz egy fejlődési szintet, rájössz, hogy ennek 90+ %-a felesleges is, mert léteznek rá CLI/scriptes megoldások, amit billetnyűkre tudsz drótozni, meg automatizálni, és nem kell minden szarnak futnia a háttérben. Pont ez a baja a systemtrének is, nem csak egy init-rendszer már, hanem egy komplett mini OS, futtat egy rakat szolgáltatást.
Hidd el, 16 GB RAM-ból nem fáj nekem sem, hogy most van 500 mega itt, 1000 mega amott, általában 8-10 giga üresen áll, a kernel cache-nek használja. Hanem a sok memóriafoglalás azt jelenti, hogy sok minden fut, ami a gép reszponzivitását tudja csökkenteni. És ha még úgy is érzed, hogy nálad most minden reszponzív, meglepődnél, hogy minden mennyivel pattogósabb egy minimalista rendszeren, aki nem szokott még hozzá, nem hisz a szemének.
Abban viszont egyetértek, hogy az FTP szerver sokszor elegánsabb megoldás, mivel nem ütközik adott esetben az USB2 korlátjába sem, meg nem kell vezetékkel csatlakoztatni a telefont.
-
Frawly
veterán
válasz
attilav2
#6367
üzenetére
Nincs zavar, olyan mirror-t használsz, amiben nem frissült le az összes csomag még. Próbálj másik mirror-ra váltani, ott van az archlinux.org-on a mirrorlist generator, meg a mirrorkereső. Ha be van állítva az új mirror, akkor benyomatsz neki egy sudo pacman -Syyu parancsot.
Vagy a clementine csomag fenntartója nem húzta be függőségnek az újabb protbuf verziót. Néha hibáznak a csomagfenntartók is.
-
Frawly
veterán
válasz
Shyciii
#6361
üzenetére
De, érdemes, ha minimalista rendszert akarsz. Én pl. ilyen minimalista, majdnem csak terminal only, meg fapad tiling WM-es rendszerre soha nem tennék fel gvfs-mtp-t, felteszi a gvfs-t, meg egy csomó bloat függőséget, futás közben eszik egy csomó memóriát. Persze akinek eleve full extrás DE-s bloat rendszere van, annak mindegy, már nem oszt-szoroz, sőt, azokba sokszor már be is van építve ilyen megoldás.
Minimalista rendszerekre teljesen jó a jmtpfs, annyi kényelmetlensége valóban van, hogy nem teljesen automata (bár azért valami udev szabállyal lehet ki lehetne trükközni) alapból, de mégis stabilan működik.
Nálam úgy van megcsinálva, hogy a Vifm-ből hívom a jmtpfs-ses scriptet, mikor a telefon csatolására fenntartott mappára váltanék bookmark-kal benne, nyilván ehhez a telefont előtte csatlakoztatnom kell bekapcsolt MPT-vel. De működik, még csak kényelmetlennek sem mondanám.
A minimalista rendszerek ilyenek, elsőre észszerűtlennek tűnnek, nem is azonnal lehet beleszokni, egy folyamat, míg átállsz ilyenekre.
-
Frawly
veterán
válasz
attilav2
#6358
üzenetére
Az amdgpu-pro drivert nem éri meg feltenni. Szimpla felhasználónak, meg játékokhoz semmi extra előnyt nem fog nyújtani, semmi nem fog gyorsabban vagy hibamentesebben futni. Cégeknek csinálják a pro drivert, főleg OpenCL támogatás van benne GPU-s számításokhoz. Tényleg csak szivatod magad, ha erőlteted. Az RX550 helyett lehet jobban megérte volna rámenni egy RX570-re, használtan piszok olcsók. Bár ha nem cél az 1080p High settings minden játéknál, akkor ilyen Medium grafikára meg 720p-re teljesen jó az RX550 is.
-
Frawly
veterán
válasz
#63718632
#6355
üzenetére
Így valóban működtethető. Akár még billentyűkombinációra is bedrótozható.
A gvfs-mtp kicsit bloat, de az meg olyan teljes automatikát tud, hogy semmilyen script meg parancsikon nem kell, érzékeli, mikor telót csatlakoztattak bekapcsolt MTP-vel, és magától gondoskodik a teló felcsatolásáról.
Én is scripttel használom a jmptfs-t, Vifm fájlkezelőből hívogatom billkombóra.
-
Frawly
veterán
válasz
#63718632
#6348
üzenetére
Itt most már kevered a dolgokat. Az allow_other az az -o kapcsoló része volt, azt is ki kéne venni az mtpfs parancs mögül. Így csak az maradna a parancs után, ahová csatolni akarod.
A jmtpfs-nek meg az a baja, hogy a home mappádba akarod felcsatolni, és abban már vannak fájlok. Csinálj neki először kézzel egy üres mappát, pl. /home/archlabs/proba és ebbe csatold fel.
Ezt az ESET Mobil Security-t nem értem, hol fut ez? A telón vagy a Linuxon?
Szerk.: látom te is rájöttél a jmtpfs-re. Én úgy tudom, hogy nem automatizálható. Ha utóbbira van igény, akkor én gfvs-mtp telepítésével oldanám meg.
-
Frawly
veterán
-
Frawly
veterán
válasz
attilav2
#6341
üzenetére
Sok waylandes cucc nem fut virtuális gépen, főleg nem Virtualbox alatt. Ezt figyelembe kell venni. Egyébként soha nem volt gondom Waylanden a Qt-s, meg a KDE-s alkalmazásokkal. Archon volt utoljára nekem a KDE5 még fél-egy éve irdatlan bugos, de az sem Wayland-bug volt, X.org-ra kapcsolva is ugyanolyan hulladék volt.
-
Frawly
veterán
válasz
jimmy399
#6325
üzenetére
Szerintem a Wayland teljesen használható állapotban van. Ami a gond vele, hogy kevés grafikus felület hozzá (kicsi a választék) és kevés (natív) alkalmazás használja. A fejlesztők idegenkednek tőle, így nem sokan fejlesztenek rá. Persze így nem is fog terjedni, mert mindenki „elvan” a X.org-gal.
-
Frawly
veterán
válasz
#63718632
#6322
üzenetére
Egyébként annyiból megérheti mégis a Windowst telepíteni elsőnek, hogy az létrehozza neked az EFI partíciót, rajta a mappastruktúrával, meg a loader.conf fájllal, így azt nem kell már az ArchLabs telepítőnek vagy Arch alatt neked megcsinálni, csak a kész infrastruktúrába beilleszteni a dolgokat. Így talán kicsivel kényelmesebb, de működik fordítva is.
-
Frawly
veterán
válasz
#63718632
#6319
üzenetére
Az mindegy, hogy systemd boot vagy nem. Az UEFI boot az UEFI boot. A lényege, hogy az OS indítókódja egy futtatható, .EFI kiterjesztésű fájlként az EFI partíción van. Csak annyi a különbség, hogy systemd bootnál egy systemd-bootx64.efi fájlt tölt be az UEFI BIOS, GRUB-nál meg egy grub.efi fájlt. Tehát a GRUB csak annyiban más a systemd boothoz képest, hogy be van toldva egy plusz felesleges láncszem. Hiszen az UEFI már önmagában is egy bootmanager, felesleges mögé még +1 bootmanagert beláncolni a bootolási folyamatba.
A Windowst mindez nem zavarja, mert az az EFI partícióról a saját bootx64.efi fájlját menedzseli. Az UEFI boot pont azért lett így kitalálva, hogy egymást ne bántsák a feltelepített OS-ek. UEFI bootnál az OS-ek telepítési sorrendje is mindegy, nincs az, mint Legacy BIOS bootnál, hogy a Windowst kell elsőnek telepíteni és csak utána a Linuxot.
-
Frawly
veterán
-
Frawly
veterán
válasz
Shyciii
#6314
üzenetére
Használd a free parancs kimenetét. Az a legpontosabb. A memóriahasználatot a kernelstatisztikákból kérdezi le, amit a /proc/meminfo cat-elésével is elérhetsz. Az ebben írt adatokat gyúrja át emészthető formában.
Értelmezni meg úgy kell a memóriafoglalást a free kimenetében, hogy össze kell adni a used, shared, buffers oszlopokat, a cache-t nem szabad hozzáadni, mert azt a kernel dinamikusan szabályozza, nem veszi el az alkalmazások elől a memóriát. Ha kell az alkalmazásnak, akkor a kernel felszabadítja a cache-t. Amit a free parancs a „free” és avaible oszlopoknál ír, az viszont nem a valóságot tükrözi.
-
Frawly
veterán
válasz
Shyciii
#6305
üzenetére
Egyik AUR helper sem tökéletes. Hibás vagy nem forduló, felrakahatatlan AUR csomagot bármelyik helpert használva lehet lelni. Ez az AUR mindenképp egy bizonytalan valami, bárki feltölthet rá akármit, nincs ellenőrizve a minősége, meg gyakran az AUR-os csomagot el szokta hanyagolni a gazdája, hosszú ideig nem frissíti, ezért el szoktak ezek törni működésképtelenre.
-
Frawly
veterán
válasz
#63718632
#6288
üzenetére
Mikor a yay-t felteszed, akkor is ugyanazt csinálod, csak git clone-nal szeded le a forráskódot, majd átváltasz a forráskód mappájára és makepkg -si, ami egy script de elvégzi a fordítást.
Abba igazat adok, hogy legalább 1 AUR helpert normálisan támogathatna az Arch, úgy, hogy a hivatalos tárolóban is benne legyen binárisan.
Közvetlenül a pamac-aur-t így telepíted a forráskód letöltése után, terminálban:
sudo pacman -Syu meson ninjatar -xvf /ahová/a/pamacaurt/letöltötted/pamac-9.1.1-1.tar.gzcd pamac-v9.1.1mkdir builddircd builddirmeson --prefix=/usr --sysconfdir=/etcninjasudo ninja install -
-
Frawly
veterán
válasz
#63718632
#6270
üzenetére
A pacman -Rns yaourt paranccsal. Esetleg még az /etc/pacman.conf végén, ami benne van az archlinuxfr-es sor, azt kiszeded, vagy # jelet a sorok elé szúrva kikommenteled, majd futtatsz egy pacman -Syyu parancsot.
De még leszedni sem muszáj, hagyhatod fent, nem foglal sok helyet, használod helyette a yay-t.
-
Frawly
veterán
válasz
#63718632
#6266
üzenetére
A legfrissebb, hivatalos tárolós ffmpeg-et. Ez most az Arch hivatalos tárolójában a 4.2.1-es verzió.
Tehát nyomatod fel ezeket:
sudo pacman -Rdd ffmpeg x265 libde265
sudo pacman -Syyu ffmpeg x265 libde265A dd kapcsoló kihagyja a függőségellenőrzést. Ha a telepítéskor reklamálna a függőségek miatt, akkor a -Sdd kapcsolóval próbáld telepíteni.
-
Frawly
veterán
Akkor az még jobb, ha Qt5. Sose volt vele problémám egyik grafikus felület alatt sem ezekkel, sem X.org-on, sem Wayland-kompozitorokkal. Már csak ez az egy Qt-s progi van, amit használok, mivel ebben a legegyszerűbb leszervezni, ha valami torrentet csak részlegesen akarok letölteni. Persze hosszú távon ki lesz váltva vagy Transmission CLI-vel, vagy rtorrent-tel, és az utolsó Qt-s progit is végleg száműzöm.
-
Frawly
veterán
válasz
attilav2
#6259
üzenetére
A konfigfájlban adj hozzá billentyűzetkombinációt. De ha ilyen kattintási ingerenciáid vannak, akkor inkább ne tedd fel, mert tiling WM, amit billetnyűzetes irányításra terveztek. Tehát se ablakok, se ablakdekorációk, se tálca. Kattintani is kevés dologra lehet, teljes képernyős mód füleire, meg a panelen a virtuális asztalokra, és kifújt. Nem is azért írtam, hogy feltegyed, csak példának, hogy egy másik waylandes felületen is probléma nélkül futnak a Qt-s alkalmazások.
Alapértelmezésben Sway-ben Win+d indítja a dmenu-t. A többi billentyűparancsot a default configban tudod megnézni: /etc/sway/config fájlban, ezt másold át a ~/.config/sway/config fájlként, és módosítsd saját igényed szerint.
Egyébként ha Qt kell és Wayland, akkor a KDE5-öt is kipróbálhatod.
-
Frawly
veterán
válasz
attilav2
#6256
üzenetére
Az Arch Wiki szerint fel kell tenni a qt5-wayland csomagot.
Nekem Gnome3 Waylanden és most SwayWM Waylanden nincs gondom a Qt-s alkalmazásokkal. Igaz most Sway-en egyedül a qBittorrentet használom, ami Qt-s, de az csak Qt4-es. Semmi baj nincs vele, nem fagy, pedig semmilyen spéci környezeti változót nem adok meg neki.
-
Frawly
veterán
válasz
attilav2
#6252
üzenetére
Sose késő rájönni ezekre. Pontosabban a mesa az hardveres 3D-s OpenGL gyorsításért felel.
A r600-as radeonokhoz meg alapból a kernelben lévő nyílt, legacy, „radeon” nevű, kernel mode setting (KMS) drivert használja a rendszer.
Az xf86-video-ati elvileg kéne, de már én is olvastam több helyen, hogy a telepítése nélkül is el lehet lenni. Így van ez Intel GPU-kkal is, azoknál sem kell már az xf86-video-intel csomag, igaz azoknál ez a tény hivatalosan is reklámozva van az Arch, Debain wikijeiben. radeon drivernél ilyet nem írnak.
A VDPAU nem függ a mesa-tól, sem a kernel drivertől, sem a Xorg-tól, hanem ahhoz külön csomagot kell feltenni: mesa-vdpau.
Az amdgpu nyílt kernel driver (és ennek a xorg-os párja) újabb kártyákhoz való, HD6000-es kártyákhoz még nem, hanem az attól újabb GCN architektúrájú kártyákhoz.
Az amdgpu-pro meg a zárt driver, de azt csak OpenCL-hez éri meg feltenni állítólag.
-
Frawly
veterán
Nekem Waylanden nem volt még gond egy játékkal sem. Vagyis 1-2-nél a teljes képernyős mód szórakozott első indulásnál, de ez sem a Wayland, hanem a SwayWM sara volt, és ilyenkor a játék menüjében előbb ablakos módot kiválasztva, újraindítva, majd újra teljes képernyős módot választva és újraindítva jók lettek ezek a játékok, utána akárhányszor indítom, probléma nélkül futnak.
Szerintem a Wayland teljesen élhető lenne, a gond az alacsony adoptációjával van, 2 bloat DE, 1 használható i3wm-klón érhető el rá, a többi rá írt DE/WM meg kísérleti tesztfázisban megrekedt demó, meg prealfa koncept. Tehát a választék nem valami nagy, ez vele a fő baj. Meg az is kár, hogy kevés az a natív waylandes alkalmazás, ami normálisan kihasználná azt az előnyt, amit nyújtani tudna. Pedig nem rossz a Wayland, gyors, a X.org-nál minimalistább, bloatmentesebb (még XWayland Xorg emulációval is). Tehát lenne értelme elterjeszteni, de a fejlesztők még nem ismerik, idegenkednek tőle.
Sokan tévesen ítélik meg a Waylandet, mert kipróbálják Gnome3, KDE5 Plasma alapokon, és az bloatnak tűnik. De azokon sem a Wayland a bloat, hanem maga az egész DE. Emiatt sokan azt hiszik, hogy a Wayland is olyan értelmetlen bloat, mint a systemd meg a Pulseaudio, pedig pont hogy fordítva. Csak jól kéne tudni használni.
-
Frawly
veterán
Ez igaz. Ennyiből a te megoldásod elegánsabb, nem vár még feleslegesen újabb X percet, hanem a frissítés befejeztével azonnal szabályosan leállítja a gépet. Viszont csak terminálból indított frissítéssel működik.
Bár a legegyszerűbb csak simán terminálosan futtatni a frissítést. Ha még letöltés közben van, és jön a telefon, akkor ki lehet lőni Ctrl+C-vel, vagy a letöltés végeztével a nem-et választani telepítéskor, így később is befejezhető a frissítés egy újabb futáskor. Ha viszont már telepíti a frissítéseket, és jön a telefon, hogy menni kell, akkor én azzal már nem trükköznék, megvárnám. Egy nem korszerűtlen, SSD-s gépen a legnagyobb Arch frissítés is, mikor az összes csomag lecserélődik (igaz ebbe nem kalkuláltam bele az AUR-os frissítéseket, amiknél forráskódból forgatással is megy el idő), végez kb. 2 perc alatt, annyit szépen a telefonáló megvár, míg indulok. Azért az elég furcsa hívás lehet, ami után annyira gyorsan kell indulni, 0 ms-on belül, hogy csak a telefont van idő letenni, meg Ctrl+C+shutdownt nyomni.
Egyébként még annyiból igazat adok a kollégának, hogy ez gyakori felhasználói igény. A windowsos topikokban is gyakran előfordul, hogy valakinek azonnal menni kéne, ezért kilövi a Windows frissülését, ami később gondhoz vezet. Ezért a moden OS-ek frissítés/csomagkezelőjébe be kéne építsenek egy hotkeyt, aminél van a frissítés befejeztével állítaná le a gépet, vagy az első alkalmas, menthető részműveletnél lőni ki a frissítést, úgy, hogy később be lehessen fejezni, adatvesztés és a telepítés tönkretétele nélkül. Teljesen kivitelezhető lenne.
-
Frawly
veterán
Amit én írtam, az akkor is megy, ha nem parancssorból lett elindítva a frissítés. A Ctrl+Z valóban háttérbe teszi, de a poweroff nem tudom mennyit vár SigTerm vagy SigKill szignál után.
(#6243) attilav2: nálam nem volt gond a Clementin-nel, se Wayland KDE5, se Wayland SwayWM alatt. Szerintem valahogy furcsán gányoltad fel a KDE-t, ha rendesen, fullosan teszed fel, akkor Wayland alatt is futnia kell a X.org-os programoknak, XWaylandet használva. Mindegynek kéne lennie, hogy milyen session-t indítasz KDE-ből, legalábbis a Clementin futása szempontjából.
-
Frawly
veterán
Ilyen esetekben még azt tudod csinálni, hogy mikor jön egy ilyen telefon és menni kell, de nem akarod sokáig járatni a gépet, akkor nyitsz egy terminált, abban benyomatod a sudo shutdown +30 parancsot, és fél óra múlva leáll a gép magától. Ha nem nagyon lassú HDD-s szutyok, addig 10× végez egy Arch frissítéssel addigra, és nem csak a gép lesz szabályosan leállítva, de a frissítés is befejeződik normálisan.
-
Frawly
veterán
yaourtot már nem használunk. Megszűnt teljesen a támogatása. A yay-t ajánlom helyette, de vannak más alternatívák is. Szerk.: áá, látom, te is rájöttel.
Frissítés közben meg Ctrl+C-t nem nyomunk. Ha sietned kell, akkor eleve nem futtatod le a csomagkezelőt. Futtasd akkor, ha van rá időd. Főleg akkor nem szabad megszakítani, amikor már a csomagokat telepíti. Míg csak tölti őket, addig nem olyan nagy gond a megszakítás. Ha már frissítés közben jössz rá, hogy menned kell, hagyd úgy a gépet, hogy befejezze a frissítést.
-
Frawly
veterán
Tudom, beállításokat és addonokat is. De erre minden böngészőnél van saját sync megoldás.
(#6217) jimmy399: én is vagy LUKS-szal vagy ATA jelszavas hardveres AES titkosítással védem a meghajtóim. De nem mindenki jár el így, nekik fontos, hogy a Keepass titkosít. Iletve fontos a password manager titkosítása akkor is, ha mondjuk a keepass adatbázist mondjuk átviszed telóra, ahol nem lesz se LUKS, se ATA/AES jelszó.
-
Frawly
veterán
válasz
Shyciii
#6215
üzenetére
Ezért nem érdemes egy böngészőnél lecövekelni, mert abban vannak a jelszavak, kártyaadatok. Erre password manager való, pl. Linuxra ajánlom a KeyPass X-et. Szépen el tudod menteni benne weboldalanként és bankkártyánként az adatokat, hogy aztán bármilyen böngészőben használd.
Az adatokat AES titkosítással tárolja, egy mesterjelszóval levédve, innentől csak erre az egyetlen egy jelszóra kell emlékeznek.
-
Frawly
veterán
válasz
attilav2
#6199
üzenetére
Jó, végül is azt használsz, amit akarsz. Csak furcsa, mert Archról nem NyíltSüSüre szoktak váltani, hanem Voidra, Gentoora vagy LFS-re, vagy valamelyik BSD-re.
A jogokat állítani tudod scripttel is, nem kell kézzel minden frissítéskor. Sőt, beledrótozhatod az AUR-os makepgk scriptbe is.
De végül a disztró nem annyira számít, ha elérsz egy tudásszintet, onnantól mindegy lesz mit használsz, mindet be lehet állítani a saját igényeid szerint, és csak abban van különbség a disztrók között, hogy:
1) milyen módszerrel frissülnek2) milyen frissek a csomagok
3) mekkora a csomagválaszték a hivatalos és külső tárolókban. -
Frawly
veterán
válasz
attilav2
#6194
üzenetére
Fura lépés ez tőled. Kevés reszeléssel szinte bármelyik disztrótól kapsz kulcsrakész rendszert, és bármelyikre fel lehet szögelni a Chrome/Chromium vaapi-t.
Igazából, ha GRUB-bal és nagy DE-vel telepíted, KDE, Gnome, akkor az Archon sem kell semmit reszelni, mert függőségként mindent felkerül. A vaapi-s Chromiumot meg valami más disztró bináris csomagjából kimásoltad volna, ha nem tudtad volna az AUR-os fordítási hibát megoldani.
-
Frawly
veterán
válasz
#63718632
#6186
üzenetére
Furcsa, ha az amd-ucode csomag telepítve van, akkor amd-ucode.img fájlnak is léteznie kéne a /boot mappában (boot partíció gyökere). Próbáld még egyszer telepíteni, esetleg a kernellel együtt, mert az utóbbi az mkinitcpio-t is lefuttatja, hátha az a gond. Tehát felnyomatod ezeket:
sudo pacman -S linux amd-ucodeNyühögni fog, hogy már fent van, de Y-t nyomsz, hogy reinstall legyen belőle.
Amit még el tudok képzelni, hogy kihagytad az amd-ucode.img elől a perjelet, tehát fontos, hogy
initrd /amd-ucode.img
legyen a sor tartalma. Az is fontos, hogy ennek a sornak nem szabad megelőznie ezeket a sorokat:
efi /vmlinuz-linux
initrd /intel-ucode.img -
Frawly
veterán
válasz
#63718632
#6176
üzenetére
Igen van. Oda is épp úgy kell ugyanaz a sor, amit a kolléga írt, csak az intel-ucode helyére amd-ucode-ot írsz, azaz:
initrd /amd-ucode.img(#6175) Siriusb: pedig ez a paraméter kell GRUB-nál is, csak annyi a könnyebbség, hogy annál nem neked kell beírnod, mert az adott ucode csomag módosítja a grub configját, és így a GRUB-ba automatice bekerül, és innen a GRUB telepítésekor, újrakonfigurálásakor automatikusan hozzáadódik. UEFI systemd bootnál viszont ilyen még nincs, oda neked kell minden sort kézzel beírni, nincs rá se szkript, se csomag után települő post script, ami betenné.
-
Frawly
veterán
válasz
Shyciii
#6173
üzenetére
Így van, látszatvédelem volt, nem töltődött be. Épp ezért nem csak fel kell tenni a csomagot ész nélkül, hanem az Arch Wikin utánaolvasni a használatának és beállításának. Nem díszből írnak hozzá több oldalnyi cikket, persze kezdőknek úgy tűnik, hogy nagyon kockák akarnak csak ott okoskodni, de amit írnak, az pechre mind fontos.
-
Frawly
veterán
Megviccelt az Arch. A Wi-Fi kártyát a laptopban mindig is wlp3s0-nak keresztelte a systemtré. Mára viszont wlan0-ra változott, ami tetszetősebb, de nem volt erről megint hír az Arch oldalán, így először nem értettem, hogy miért nincs net. Először azt hittem, hogy a kártya döglött ki, mivel az ifconfig sem látta. De aztán láttam, hogy az lspci listázza, és az lsmod szerint be van hozzá töltve az iwlwifi kernelmodul. Akkor látom csak net link parancs futtatása után, hogy az interface neve megváltozott. Csináltam neki új profilt wpa_supplicanttal, áthegesztettem a Wi-Fi-t indító scriptemet, most már jó, ifconfig is listázza.
-
Frawly
veterán
válasz
attilav2
#6166
üzenetére
Szerintem ha már tudod telepíteni az Archot, akkor ne disztróhoppolj mainstream disztróra, mint a OpenSuse, Fedora, meg egyebek, mert visszalépés, visszafejlődés. Utóbbiak bloatak, hülyebiztosak, túl corporate-csilivili-marketing trendmajom disztrók, és semmi érdemi előnyt nem kínálnak az Arch ellenében.
Maradj Archon, ha meg ott is kifejlődtél a minimalizmus felé, akkor jöhet egy systemd-mentes Void vagy a Gentoo.
Egyébként az Arch, Gentoo, Debian Wikijei szinte minden disztróra alkalmazhatók, egyedül a csomagnevek változnak, meg ugye a Gentoo alapból nem systemd-s, de telepíthető azzal is.
-
Frawly
veterán
válasz
#63718632
#6152
üzenetére
Pedig az Arch Wiki ezt írja. Igaz a timesync-es cikkben csupán (Usage rész), az Installation Guide-ban, és a System Time szócikkben nem említik (csak az utóbbiból lenyíló, már linkelt cikkben írják). Szóval elismerem, hogy elég genya, jól el van dugva ezt a set-ntp-t használó módszer. Le kéne cseréljék az Installation Guide-ban említett régi módszert erre, amit írtam.
@vargalex: azért ne örülj, mert lehet magának a pikaur-nak nem okozott gondot, de az új pacman eltört egy csomó AUR-os makepgk scriptet is, független ez attól, hogy milyen AUR helpert használsz. Most netszerte mindenki szorgosan szopórollerezik az új pacman miatt, Archon és klónjain is.
-
Frawly
veterán
válasz
#63718632
#6145
üzenetére
Az óra 1 órával való elállítódása több mindentől függ. Milyen UEFI BIOS van fent a gépen, fut-e dualbootban Windows. Milyen NTP megoldás van fent, vanilla Archon, meg a legtöbb klónon csak a sima timedatectl van fent, aminek van systemd-s timesync service megoldása, ami kezeli az időzónákat, szinkronban tartja az órát, kezeli az NTP-t, DST-t, a /etc/systemd/timesyncd.conf-on keresztül. Viszont fel lehet tenni helyette más megoldást, pl. openntpd-t.
Vanilla Archon ez elég szokott lenni telepítés után:
timedatectl set-ntp true
timedatectl set-timezone Europe/BudapestHa meg van dualbootban Windows, akkor abban az Arch Wiki-ben ismertettet registry hacket hozzáadni, hogy a gép óráját UTC-ben tartsa, ne helyi időben. Ezek nekem tökéletesen elégnek bizonyulnak, mindig pontos az idő, rendszeresen szinkronizál, Windows sem állítja el a gép óráját.
Sajnos az Arch Installation Guide-ban benne maradt egy régi időzához symlink-eléses módszer, azt is meg lehet csinálni, de felesleges és hatástalan. Még a systemd előtti időkből maradt benne:
ln -sf /usr/share/zoneinfo/Region/City /etc/localtime
hwclock --systohc@FEAR: az ’szna be, ha BSD-ken is elterjedne a systemd. Végső esetre az a vésztervem, ha már minden disztrót megfertőzött a system, a Gentoo-t is, akkor BSD-re állok át. Előtte viszont még Gentoo-ra fogok, és végül nem a csomagfrissesség, meg a kódforgatásos optimalizálás miatt, hanem a systemd-t szeretném dobni.
-
Frawly
veterán
válasz
#63718632
#6136
üzenetére
A legnagyobb hiba, hogy nem volt fent nálad a go és a base-devel. A group-ot nem kell hozzáírni. Nálam rendesen frissen tartott vanilla Archon simán fordul a yay master git, azokkal a parancsokkal, amiket írtam. Még csak warning sincs, nem hogy error.
Abban viszont egyetértek veled, hogy ezt a pacman 5.2-re váltást nagyon hirtelen lépték meg, egy csomó felhasználó és klóndisztró szív miatta. Itt nem az a baj, hogy váltottak, hanem túl hirtelen tették, nem adtak időt az AUR helperes és egyéb fejlesztőknek, hogy előre teszteljenek, meg legyen idejük felkészülni, kompatibilissé tenni a szoftvereket, és erre a felhasználók sem lettek értesítve, hogy pl. AUR helpereket, GUI-s pacman frontendeket is frissíteni kell majd emiatt. Azért léptek ilyen hirtelen, mert fel szerették volna gyorsítani a .xz-ben tömörített csomagokról zstd tömörítésre váltást, ami már rég ki volt tűzve célként, de már régóta húzódik. Ennek ellenére ilyen apróságok miatt nem kéne kapkodniuk.
Az amd-ucode csomaggal sincs semmi baj, azt csak azért sérelmeztem, hogy semmilyen hírben nem tették közzé, hogy onnantól fogva nem a linux-firmware csomagban lesz, ahogy sok évig előtte, hanem külön csomagként kell majd feltenni. Egy 2 soros hír elfért volna róla az archlinux.org főoldalán, a News szekcióban.
Azzal nincs baj, ha Arch-csal próbálkozol. Majd belejösz az ilyenekbe, hogy AUR-hoz milyen csomagoknak kell fent lenni, meg telepítés után az első a mirrorlistet rendbe tenni, stb.. Mindenki elkezdi valahol.
-
Frawly
veterán
válasz
Laszlo733
#6100
üzenetére
Na, ebbe én is belefutottam. Az 5.2-re frissült pacmannal nem volt kompatibilis a fent lévő yay. Ezért újra forráskódból kell leforgatni:
git clone https://github.com/Jguer/yay.gitcd yaymakesudo make installEzután már működik. Ezt a baromságot nekem is írja:
==> WARNING: PACKAGER should have the format 'Example Name <email@address.invalid>'De csak warning, nem error, ami miatt leállna az aktuális csomag telepítése, nem kell vele foglalkozni. Gondolom az új pacmannak más a formátuma, mint a réginek, és ehhez még nem igazították hozzá az AUR-ban lévő makepkg scripteket.
-
Frawly
veterán
válasz
Laszlo733
#6108
üzenetére
Archon nincs frissítéskezelő. Csak pacman terminálban/konzolban.
Az NFS-ből, és tűzfal+torrent kombóból ítélve ez egy szerver, de akkor meg nem tudom minek rá SSDM, meg KDE. Ezek mind mehetnek grafikus felület nélkül. Octopi meg az aztán tényleg egy olyan dolog, ami hulla felesleges egy szerverre.
Az Octopival nem tudsz mit csinálni, ha rossz a makepkg script, akkor így jártál. Esetleg megtanulsz Bashül és kijavítod. Van ez így, hogy egy gondozatlan AUR csomag eltörik, mivel a gazdája nem igazítja hozzá a változásokhoz.
-
Frawly
veterán
válasz
Laszlo733
#6104
üzenetére
Távolítsd el az Octopit pacman -Rns segítségével. Aztán töröld a ~/.cache/yay/ mappa tartalmát. Majd próbáld újratelepíteni az Octopit yay-jal.
Én a történetedben azt nem értem, hogy a pacmant miért yay-jel akarod telepíteni? Miért nem pacmannal? Nálam simán települt az 5.2-es, semmilyen hibám nem volt azóta. Igaz én Octopit nem használok, yay-t is csak az AUR-os csomaghoz.
-
Frawly
veterán
válasz
ubyegon2
#6078
üzenetére
Igen, ezeket szoktam is írni. Csak az NCQ TRIM van feketelistán, nem az egész TRIM. Tehát a fstrim, fstrim.service, discard mount paraméter működik továbbra is, de a kernel azonnal kikényszeríti a végrehajtásukat, nem ütemeződnek (queue) későbbre. Ez pedig némi belassulással járhat. 860-asnál már ez nincs, ott az NCQ TRIM sincs tiltva.
-
Frawly
veterán
Igazad van, rosszul emlékeztem. Régen "Samsung SSD 8*" szerepelt benne, de végül a 860-asra feloldották, a 840 rajta maradt, a 850-esre emlékeztem teljesen rosszul.
Akkor az viszont lehet oka, hogy a 850 Pro amiatt lassul be, mert az NCQ TRIM le van tiltva, emiatt a kernel azonnal kikényszeríti a végrehajtását.
-
Frawly
veterán
válasz
vargalex
#6072
üzenetére
A modern kernelekben jó pár hónapja csak a 840-es van már feketelistán, a 850-860-as szériát kivették belőle. Nekem is ubyegon mutatta.
Schyciii: nyilván nem konzumer SATA SSD-t kell virtual hostingra használni, arra valóban nem való. Arra enterprise NVMe SSD kell. De sima workstation, desktop, home felhasználásra teljesen jó a 850-860 Pro, még nagyobb fájlmásolásoknál is.
Minimalista felhasználásra, főleg desktop Linux alá, esetleg C2D és annál gyengébb gépekbe (amik jobb SSD-t nem hajtanának ki) az A400 is teljesen jó, WIn10, Linux 4-6 mp. alatt bootolni tud rajta, programok azonnal betöltődnek, ennyi a lényege, nem kell várni, míg HDD-t rotyogtat a rendszer. Csak nagy fájlmásolásokat ne akarj rajta, mert arra már nem való. Ha erre próbálod használni, akkor nagy csalódás lesz a vége, és rájössz, hogy nem volt értelme az SSD-n spórolnod, pár ezres árdiffiért vehettél volna valami jobbat. Ezért első kérdés a Milyen SSD-t veszek topikban, hogy mekkora anyagi keret van rá, és milyen felhasználásra lesz, milyen gépbe.
A400-nál attól is nagyon függ a belassulás, hogy mennyi írás van rajta, mennyire van betelítve adattal, és eleve mekkora tárhelyes modell. Ami az A400-ról nagyon hiányzik, az a DRAM cache, de annak a hiánya inkább random lemezműveleteknél látszik meg jobban.
-
Frawly
veterán
válasz
Shyciii
#6069
üzenetére
Pedig a 850 Pro egy elég jó SSD, nincs is rajta NAND cache, csak DRAM cache. Nagyon gyors, klasszik/planár MLC NAND van rajta, még nagyobb csíkszélességen gyártva, így nem csak gyors, de elég strapabíró is. NAND cache ezért is nem kell neki, mert olyan jófajta NAND van rajta, ami nem cache módban is elég gyors, konzisztensen tudja tartani az írást/olvasást, végig a meghajtó teljes tárterületén.
Ezzel a cache problémával inkább nagyon olcsó SSD-ken találkozni, ahol planár TLC, vagy gyérebb 3D TLC/QLC NAND van (A400, BX500, 660p), na, azok tényleg mocskosul be tudnak lassulni, ha kifogy alóluk a cache. Ha viszont sokat másolsz nagy tételben, akkor nyilván nem ilyen SSD-t kell venni.
Illetve nálam áll hegyekben a sok giga RAM is kernel cache-nek, meg az MX300-nak is még normális a cache-elése, nem egy sebességbajnok SSD, de azt a sebességet konzisztensen, belassulások nélkül tartja, így talán én azért nem futottam bele abba, amit írtok.
Egyébként az iotop-pal tudod nézni, ha a rendszer I/O miatt van terhelve.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Yettel topik
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Xiaomi 12 - az izmos 12
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Nem tetszik a Procon-SP-nek, hogy a Nintendo távolról kivégezheti a Switch 2-t
- Luck Dragon: Asszociációs játék. :)
- Xbox tulajok OFF topicja
- Szeged és környéke adok-veszek-beszélgetek
- BestBuy topik
- NTFS, exFAT, FAT32 – Melyiket válaszd és miért?
- További aktív témák...
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Bomba ár! Dell Latitude 7320 - i5-11GEN I 8GB I 512SSD I HDMI I 13,3" FHD I Cam I W11 I Garancia!
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 4070 Ti Super GAMER PC termékbeszámítással
- AKCIÓ! ASUS PRO WS W790E-SAGE SE alaplap garanciával hibátlan működéssel
- Törött, Hibás iPhone felvásárlás!!
- Apple iPhone 16 Pro Max - Natural Titanium - Újszerű - 1 töltési ciklus - 2026. 05. 13.-ig Apple gar
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest