- Poco X6 Pro - ötös alá
- Okosóra és okoskiegészítő topik
- Apple iPhone 15 Pro Max - Attack on Titan
- Redmi Note 10S - egy a sok közül
- Magisk
- Megérkezett a Google Pixel 7 és 7 Pro
- Ennyibe kerülhet a Xiaomi Watch S4 európai változata
- Xiaomi Watch 2 Pro - oké, Google, itt vagyunk mi is
- Samsung Galaxy S23 Ultra - non plus ultra
- Milyen okostelefont vegyek?
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
Frawly
veterán
Egyébként én arra gyanakszok még, hogy itt a legtöbben valami ocsmány, intézőszerű fájlkezelőt használtok, Nautilus vagy Dolphin, vagy hasonló szutykot, és az bugzik be. Próbáljátok ki terminálban, mc-vel vagy hasonlóval, hogy hogyan alakul a CPU terhelés, meg ott is akad-e az egér.
-
Frawly
veterán
válasz
Shyciii
#6066
üzenetére
Na, a 27% már reálisabb, de amellett még mindig nem kéne akadnia az egérkurzornak. Nálam ilyen nagy SSD-ről SSD-re másolás közben is teljesen simán gördül az egérkurzor, sehol egy megakadás. Pedig mint írtam, sima vanilla Arch, meg lófütykös számítási teljesítményű régi notebook.
De, hogy ha 2-3 hónapja nem csinálta, akkor az van, amit legelőször írtam, hogy ez valami friss bug, vagy a kernelben, vagy valami userspace toolban, ami most jött elő nemrég.
-
Frawly
veterán
válasz
vargalex
#6064
üzenetére
Ezt tényleg nem ártana tisztázni. Van ugyanis olyan taskmanager, amit 100% terhelésnek veszi az összes mag együttes terhelését, van, amelyik többszáz %-nak (pl. négy szálas procinál 400%-ot vesznek teljes terhelésnek, 8 szálasnál 800%-ot).
Én htop-pal néztem, a CPU [Bar] oszlop van nálam bekapcsolva, ami 100%-nak veszi az összes magra számított max. terhelést. De amikor a szálaknál listázza a terhelést, meg folyamatoknál, azt viszont egy magra vetítve méri.
Még azért a proci sem lenne mindegy.
-
Frawly
veterán
válasz
vargalex
#6062
üzenetére
Jó, de itt maximumra járatott prociról beszéltünk. Az 1 magra eső terhelés nem releváns, egy 12 szálas procinál azért ne számítson a 100% egy szálra eső terhelés, mikor az csak összességében a proci ~8%-a. Persze nem azt mondom, hogy nem magas nálam is, mert egy normálisan megírt OS-nél, drivernél max. 1-2% körül kellene, hogy legyen. De az ntfs-3g-nél megszoktam, hogy bloat, annál örülni kell, hogy támogatott az NTFS egyáltalán, hacsak lehet, tartós linuxozásnál kerülni kell az NTFS partíciók használatát.
De ext4-nél valóban én is sokallom azt az 5-25%-ot (egy magra 20-100%). Amit még nem írtam: nálam titkosítás sincs (vagyis van, de az hardveres, szoftveres szint felé transzparens). Szóval nem kellene ennyinek lennie, de azért attól messze van, hogy kimaxolja a procit, meg gondot okozzon.
-
Frawly
veterán
válasz
Shyciii
#6060
üzenetére
Morbid, amit írtok, Archon nekem meg nem eszi meg, ext4-ről másolok ugyanarra az ext4 partícióra, egy régi SATA SSD, és a proci sem erős, egy i5-2520M, ami kb. egy asztali közepes C2Q szintjén lehet mindössze, szóval kb. 10 éves szint, másolás közben 5-25% között ingadozik az össz procihasználat (ez már ki van vetítve 4 szálra, a 100% lenne az, amikor az összes szál maximumra lenne terhelve). Az idő java részében közötte van a két szélső értéknek, és 11% körül van. Az is igaz, hogy nálam az SSD sem gyors (MX300), tartós írásnál mindössze 300 MB-ra maxolódik ki, még az sincs meg mindenhol, néha beesik 200 közelébe, pedig SATA3 módban fut, nem ütközik bele SATA2 limitbe.
Kipróbáltam NTFS-ről is ext4-re, igaz az SATA2-re korlátozott SSD-ről ment (mSATA Samsung 860 EVO), de ramdrive-ra másoltam, ami kb. 6000 MB/sec-et tud. Itt sem volt több 33-37%-nál a procihasználat, igaz ezt konzisztensen tartotta, nem nagyon ingadozott. Pedig a legfrissebb rendszerem van Archon, friss ntfs-3g-vel, kernellel, meg mindennel, annyira friss, hogy a Testing tárolóból van a legtöbb minden. Talán ami nálam eltér, hogy terminálos alkalmazásokat használok, meg ultraminimalista waylandes felületet, míg nálatok a grafikus felületnek egy ilyen lemeztartalmat kijelző frissítési bugja dobhatja meg a procihasználatot.
Meg kéne nézzétek, hogy konkrétan melyik folyamat eszi annyira a procit.
-
Frawly
veterán
válasz
Shyciii
#6058
üzenetére
Ebben teljesen igazad van, még ramdrive-nál és NVMe SSD-nél sem lenne szabad 100%-ig tekernie a procit, akkor sem, ha az gyengébb. Épp ezért, én inkább gyanakszok arra, hogy valami újonnan előkerült bug, de tényleg simán lehet, hogy ennyire szuboptimálisra van megírva.
-
Frawly
veterán
válasz
vargalex
#6049
üzenetére
Én nem néztem rá. Igaz csak most lett nemrég AMD-s gépem, és még arra is lusta voltam feltenni Linuxot, mert mikor időm van elé ülni, Win10 alatt nyomatok rajta AAA-s játékcímeket. Pedig még a partíciós hely is meg van a Linuxnak hagyva
De emlékszem, hogy régen ki volt hangsúlyozva, hogy csak Intel procikhoz kell külön microcode csomag (intel-ucode), AMD procikhoz a linux-firmware csomag tartalmazta. Ezek szerint már 1 éve külön van, de én lemaradtam róla, mert egy darab hír sem volt róla. Aki nem veszi észre, annak elég kínos.
-
Frawly
veterán
válasz
ubyegon2
#6043
üzenetére
Ez lehet, hogy az SSD teszi annyira gyorssá az I/O műveleteket, hogy a proci lesz a szűk keresztmetszet.
De még simán lehet az is, amit én írtam, hogy bugos a legutóbbi verzió. Az ntfs-3g-ből nem jön ki túl sűrűn verzió, ezért simán lehet, hogy már egy régebbi LTS kiadáson is az utolsó verzió van. Vagy az is lehet, hogy a legújabb kernelekben van egy bug, ami előhozza ezt a procitúlpörgetés ntfs-3g-vel.
(#6044) Shyciii: ezt mondom én is, hogy a 100% az túl durva. Bár az is igaz, amit uby ír, hogy a procitól is függ. De nálad HDD-re megy, és nem SSD-re, ami jobban be tudná pörgetni.
-
Frawly
veterán
válasz
ubyegon2
#6038
üzenetére
Az ntfs-3g valóban terheli a procit, de azért 100%-ra nem kéne pörgetnie. Már a második user a héten, aki erre panaszkodik, ráadásul nem csak Arch alatt, szerintem ez egy bug lesz a legfrissebb verzióban. Lehet kipróbálom most már én is, és jelentek nálam hány %-ot eszik az ntfs-3g.
-
Frawly
veterán
Egyébként nagy francok az archosok. Sokszor még hír sincs kint egy változásról. Pl. jó pár hónapja kikerült a linux-firmware csomagból az AMD procikhoz a microcode csomag, és most már külön csomagban van, amd-ucode néven. De erről se hír, se értesítés, gondolom mert úgy gondolták, hogy a rendszert nem töri el működésképtelenre, nincs szükség kézi beavatkozásra (de, szükség van rá). Én is csak azért vettem észre, mert múltkor itt egy kolléga felhozta UEFI systemd-boot kapcsán. Az Arch Wikiben már benne van, de aki nem tud a változásról, az nem fogja keresgetni benne.
Gondolom úgy voltak vele, hogy majd az emberek észreveszik frissítéskor, vagy egy olyan csomag telepítésekor, aminek opcionális függősége.
-
Frawly
veterán
válasz
Laszlo733
#6032
üzenetére
Akkor meg is van a gond. Nemrég a base csomagot átrendezték, nem jó a régi telepítési módszer. A base már nem tartalmaz egy csomó mindent, így pl. kernelt és mkinitcpio-t sem. Pár napja variálták át. bob linkelt róla ennek a topikoldalnak a tetején, a #6007-es hozzászólásban, de itt a hír még egyszer.
Szóval pacstappal (vagy chroot környezetben pacmannal) nyomathatod is fel a linux linux-firmware mkinitcpio nano csomagokat is, mint a huzat.
Pont egy olyan szerencsétlen átmeneti időszakot fogtál ki, amikor már átvariálták, meg hír is van róla, de a Wiki-ben a telepítési útmutatóban még nem írták át. Annyira tudtuk előre, hogy ezt jó páran meg fogják szívni
Szerk.: de, át van írva már a telepítési útmutatóban. Ezért kell mindig a legfrisebb Arch Wiki alapján telepíteni, és nem ilyen más weboldalakon közzétett régi ismertetők alapján.
-
Frawly
veterán
Nekem mindenre van, a vim a fő szövegszerkesztőm, és file viewerem, grafikus felületen is (terminálban), nem csak konzolos felületen. Nem csak erre-arra használom. Vifm-ben még a csoportos átnevezés is vim-ben történik, meg sed/awk helyett is ezt használom, amikor csak lehet. Bashban is vi-módot használok. Meg Bashban is van egy olyan funkció, hogy meg tudom nyitni az utolsó parancsot átszerkesztésre vim-ben, fc paranccsal, vagy Esc + v egymásutánjával is ugyanezt a hatást érem el, ez utóbbi a Bash-féle vim-módban visual módba lép be.
Sőt, a WM-et és a böngészőket is vim-es módban meg vim-addonokkal használom, meg sok más programban is vim-billentyűket (Vifm, zathura, less, neomutt, Termite, stb.). Tehát nálam a vim egy életforma, mivel több mint egy text editor, egyenesen egy interakciós módszer, egyfajta működési filozófia az összes proginak. Kár, hogy nem mindegyikben lehet bekapcsolni, vagy konfigurálni vi/vim-módot.
-
Frawly
veterán
válasz
vargalex
#6021
üzenetére
Igen, ha a terminál emulátorral vágod ki egérrel, akkor nem gond, mert akkor nem a vim küldi vágólapra, hanem a terminálemulátor. De! A vim-nek pont az az értelme, hogy gépírástartásban kapcsolgass a módok között. Ahogy kinyúlsz egérért kijelölgetni, értelmét veszti a vim, annyi erővel használhatnál gedit-et, vagy Kate-et, vagy Geany-t.
A vim-nek pont az lenne a lényege, hogy y-nal (yank) jelölj ki normal vagy visual módban. Így kijelölve viszont a garfikus felület felé nem regisztrálódik, ha nincs a vim vágólaptámogatással lefordítva. Tudom, mert szívtam miatta, meg az Arch fórum tanulsága szerint mások is szoptak miatta.
A sima vim csomag annak van, aki konzolból használja csak a gépet (nem grafikus felület + terminál kombóval), és nem akar GVim-et is feltenni, hanem a legminimalistább akar maradni.
-
Frawly
veterán
Nem. A gvim csomagban lévő „sima” terminálos vim nem GUI-s frontend. Épp olyan karakteres üzemmódú alkalmazás, mint a vim csomagban lévő vim vagy az mc, ranger, stb.. Fut grafikus felület nélkül is konzolban.
Amiről te beszélsz az a gvim csomagban lévő gvim bináris, ami valóban egy grafikus alkalmazás (grafikus felületen GVim-nek látszódik), aminek kell grafikus felület, X.org vagy XWayland, hogy futni tudjon, különben el sem indul, kiírja, hogy nem talált megfelel display-t.
Amiről én beszélek, az a gvim csomagban lévő „sima” vim bináris. Ez Archon +clipboard és +xterm-clipboard compiler flagekkel lett eleve lefordítva. Emiatt ahogy írod is, működik a vim-ből szöveg kihelyezése vágólapra, amit lát egy grafikus X.org-os progi is, pl. egy Gtk-s Firefox. Akkor is látják, ha nincs xsel, vagy stb.. Ennek viszont feltétele, hogy a vim vágólaptámogatással legyen fordítva. Persze az is kell, amit írsz, hogy a terminál tudjon grafikus vágólapot kezelni, de nem tudom kit hülyítünk, minden közismert terminálemulátor tudja ezt, aki meg valami olyan spéci őskövületet használ, ami ezt nem tudja, az magára vessen.
Archban a gvim és a vim csomag egymást kizárja. Ha fent van a vim, akkor a gvim csomag telepítésénél kérdez, hogy lecserélheti-e a vim csomagot, ha nem engeded meg neki a cserét, akkor a gvim nem települ. Persze nem csak a GVim-et telepíti a gvim keretében, hanem a sima vim-et is, pont ezért van ütközés a két csomag között, mert mindegyik ugyanazt a vim binárist is feltenné.
De ez így van Ubuntu- és Debian-származékokon is, azoknál a vim-gtk vagy vim-gnome csomagban lévő vim (és nem gvim) binárisnak van vágólaptámogatása. A különbség annyi, hogy vágólaptámogatással nem rendelkező vim nincs is ezeken a disztrókon, vagyis van, de azt már vim-tiny-nak hívják.
-
Frawly
veterán
Nem. A gvim csomag Arch alatt két vim-et is tartalmaz. Egy grafikus Gtk-s GVim-et (ez az, amiről te beszélsz), és egy terminálos „sima” (karakteres felületű) vim-et is (de ennek is van clipboard támogatása), ez utóbbit használom én.
Ha a sima vim csomagot teszed fel, akkor az csak egyfajta vim-et tesz fel, de az sem terminálra, hanem konzolra van tervezve.
Persze ez Arch alatt van. Más disztrókon annak a kérdése, hogy a disztró készítői a vim-et milyen csomagba milyen compiler flag-ekkel fordították. Az archerek úgy döntöttek, hogy a sima vim csomagban lévő vim-nél kihagyják a clipboard funkciót a fordítás során, míg a gvim csomagba lévő vim-ben meghagyták. Lehet vitatkozni azon, hogy ez mennyire jó ötlet, de önkényesen így döntöttek.
Mivel te Gentoo-t használsz, nálad ez nem probléma, szépen a vim fordításakor bekapcsolod azt az opciót, hogy clipboard támogatás is legyen, már nem is tudom minek hívják ezt a flaget. Ez a vim vs. gvim csomag felrakása csak az Archnál kérdéses, de ez itt pont releváns, mert az Arch topikban vagyunk, nem a Gentoo-sban. De sokan már Archon is egy huszárvágással véget vetettek ennek a kérdésnek, és vim/gvim helyett neovim-et tesznek fel, amiben szintén van clipboard támogatás tudtommal.
-
Frawly
veterán
válasz
vargalex
#6015
üzenetére
Jó, de a vi sem lesz fent. Egyébként meg aki a vi-t tudja használni (mint te és én is), az meg nem vi-t fog feltenni, hanem mindjárt vim-et. Vagyis még inkább gvim-et, mert abban is van sima vim és az úgy van lefordítva, hogy működik a vágólapja a grafikus felület felé. A sima vim csomagban lévő vim-nél ez nem működik, fordítás közben lett kihagyva ez a feature. De gvim helyett lehet neovim-et is használni.
Egyébként a legkorrektebb lenne a szövegszerkesztőkre egy metacsomagot csinálnia az Archnak, editor néven. Így csak install közben annyit kellene tenni, hogy a pacstrap-nak vagy pacmannak a base linux csomagok mellé felsorolni az editor metacsomagot, és telepítéskor számozva rákérdezne, hogy melyik text editort telepítse, onnan meg mindenki kiválaszthatná magának, ami neki kell. Ez főleg kezdőknek lenne hasznos, akik nem tudják előre mit is akarnak, mi a választék.
Aki rutinos róka, az azonnal nyomatja a base linux gvim vagy base linux nano csomagokat, nem akasztja meg ez a változás.
-
Frawly
veterán
válasz
vargalex
#6009
üzenetére
Igen, valóban igazad van. Lefuttattam most egy pacman -Syy parancsot és ezután már a pacman -S base nem is metapackage-t, hanem egy szál csomagot akar tényleg telepíteni.
Viszont írja, hogy opcionális függőségnek fent van a linux: bare metal support. Ez mi a tök? Esetleg ez csak simán a kernelt jelenti?
Az sem értem, hogy akkor mi a különbség a metacsomag és a csoport között.
-
Frawly
veterán
Ez sajnos nem tűnik igaznak. Mármint nem téged kritizállak, hanem a hír valódiságát. Most próbáltam ki egy pacman -S base parancsot, a core tárolókban még a régi metacsomagot jelenti, aminek 53 csomag a tagja. Az testing tárolókban is még mindig egy metacsomag, de már csak 3 tényleges csomagot foglal magában: gcc-libs, glibc, linux. Tehát nem igaz, hogy kernelt nem tartalmaz.
Az meg egy kritikus döntés, hogy e2fsprogs-ot sem fog, mert az nagyon szükséges lenne, meg ha a kernelt is kiszedik belőle, függőségnek be kéne húzza mindkettőt. Ez a túlzott karcsúsítás csak arra jó, hogy egy csomó kezdőbb user kifelejtsen valamit, aztán menjen a vergődés, hogy se formázni, se ellenőrizni nem tudja a fájlrendszereit.
Az viszont nem baj, ha a text editort kihagyják belőle. Eddig vi volt a default, de azt sokan nem tudják használni, aki meg guru, úgyis gvim-et tesz fel (akkor is, ha terminálban használja, mert a gvim csomagban lévő vim-ben normálisan működik a vágólap a grafikus felület felé). Aki meg nem ismeri a vi/vim-et, az meg eddig is nano-t használt, vagy mceditet, vagy hasonlót, most csak annyi a különbség, ha nano-nál marad, akkor fel kell tennie.
-
Frawly
veterán
válasz
vargalex
#6003
üzenetére
Jó tudni. LTS kernelt nem használtam még Archon, csak tárolósat meg git-eset. Azt hittem, hogy ahogy azoknál, átnevezi a meglévő kernelt, és nem lesz benne a nevében az lts.
Mondjuk nem is fogok egyhamar LTS kernelt használni Archon, az Arch lényege a frissesség. Ha LTS-re van igény, akkor másik disztró után néznék inkább. Persze teszt erejéig oké, nem is biztos, hogy megoldja a szóban forgó fordítási problémát.
-
-
-
Frawly
veterán
Ne aggódj, szerintem nálad is a most kijött Mesa 19.2.0 okozza a hibát. Nem az Arch hibája, a Mesa devek írták a szoftvert ilyen instabilra. Tudnak a hibákról, javítás alatt van, nemsokára várható a 19.2.1.
Nálam egyébként csak a Chromiummal van baj. A többi program teljesen jól megy, Firefox, mpv, játékok.
(#5990) eddie1978: Annál szerintem el fogod tudni kerülni ezt a hibát, mert hátrébb jár a verziókkal, így a Mesa csomag is régebbi benne. Mire meg elérnek az újabb verzióig, az már a javított 19.2.1 lesz. Egyébként jövő héten én is kipróbálom a CL-t, nagyon kíváncsi vagyok rá. Nem a stabilitására, hanem a sebességére.
-
Frawly
veterán
válasz
wwenigma
#5980
üzenetére
Ha az AUR-os nem megy fel, akkor esetleg valami debianos vagy ubuntus csomagból. Amúgy milyen hibát dob? Mert el lehet hárítani a fordítási hibákat is.
Egyébként az iwlwifi firmware-nek alapból benne kell lennie a linux-firmware csomagban, ami a base install része. Az AUR-os iwlwifi csak abban különbözik ettől, hogy gyakrabban frissül és hamarabb kerül bele az új verziós firmware.
-
Frawly
veterán
A kalandok folytatódnak. Most frissült a SwayWM, ugyanaz a verzió (1.2), de újabb build (-2 helyett már -3). Erre most már el sem indul a chromium bináris, azt mondja terminálban:
[863:863:0930/042000.321493:FATAL:memory_linux.cc(42)] Out of memory.
Trace/breakpoint trap (core dumped)Természetesen van elég memória, 14,5 GB szabad a 16 gigából, egy keveset eszik az IGP, meg 600 megát az egész Linux, kernel, systemd, SwayWM, Firefox több füllel. Szerintem még az IGP 1 gigás memóriájából is szabad vagy 900 mega.
Szerk.: az Arch bugtrackere is hozza már, más is jelentette 23 órája. Állítólag a Mesa 19.2 okozza, ahogy már sejtettem, de szerintem nem csak az, mert azzal nekem legalább elindult, ha tearingelt is. A Sway frissítése tett be neki végleg.
-
Frawly
veterán
válasz
attilav2
#5973
üzenetére
Az a proci kihajtja szoftverrenderben is az 1080p-t, de talán még a 4K-t is. De mindenképp megéri hardveres dekódolást használni, mert nem melegszik feleslegesen a proci, nem zúgatja a ventiket, kevésbé eszi az akkut.
Archon az AUR lenne arra való, hogy forduljon a dev verzió, csak nem build szerveren fordul, hanem a saját gépeden. Az a gáz, hogy nincs belőle nem patchelt verzió.
-
Frawly
veterán
válasz
attilav2
#5970
üzenetére
Egyáltalán nem gányolás, szépen megoldottad újraforgatás nélkül. Gondolkodok rajta, hogy én is felteszem. Csak nincs kedvem szórakozni vele. Várok még pár napot, hátha egy frissítés helyreteszi a Chromiumot, ha nem, akkor törlöm a gépről, és helyette befogok egy másodlagos Firefox profilt inkább.
Nálam azért van 2 böngésző is fent, mert tematikusan használom. A Firefox a fő böngésző, a Chromium a másodlagos, amit csak szórakozásra, videózásra, stb. használok, hogy ne egy böngészőben legyen 500 fül megnyitva, hanem témák szerint szétszedem két böngészőre, így legalább több böngészővel is lesz tapasztalatom. De ha a Chromium ilyen bugos marad, akkor dobni fogom szemrebbenés nélkül. Egyébként sem a kedvencem, fájni nem fog érte a szívem.
Ugyebár a bug, ami nálam van, az abszolút a Chromium hibája. Még azzal sem jöhetnek, hogy túl új a Mesa, mert a 19.2-es ágat már hónapok óta tesztelték egy csomóan bétaként, majd RC-kként, sőt, jó ideje végleges kiadásban is, az csak az archosok lustasága, hogy Archra még csak most ért el. A Wayland és Sway WM sem lehet oka, mert az meg rég nem frissült, meg a többi alkamazással jó. Ez megint tipikus Google fejlesztési minőség. Utálom ezeket a multikat, csak bullshitelni tudnak, meg divattrendkedni és bloatosítani, de mikor normális dolgot kéne letenni az asztalra, akkor az már nem megy, helyette van a fetrengés, meg lázas bugfoltozás.
-
Frawly
veterán
válasz
attilav2
#5966
üzenetére
Az hagyján, hogy az nem működik, de Archon a Chromium legújabb frissítése eltörte a hardveresen gyorsított kirajzolást, tearingel videók alatt.
Hiába lövöm be a szükséges dolgokat chrome://flags és chrome://gpu oldalon, hogy használjon GL renderinget, hiába kényszerítem a Chromiumra az --ignore-gpu-blacklist --enable-gpu-rasterization --enable-native-gpu-memory-buffers --enable-zero-copy flageket az Arch Wiki alapján, akkor sem jó, a chrome://gpu oldalon azt írja, hogy:
Problems Detected
GPU process was unable to boot: GPU access is disabled due to frequent crashes.
Disabled Features: allEsetleg a Waylanddel vagy a Sway WM-mel nem fér össze. mpv és Firefox alatt jó a lejátszás, van gyorsítás, nem tearingelnek a videók.
Esetleg még a Mesa csomagra gyanakszok, pár napja frissült 19.1.x-ről 19.2-re. Lehet ez is az oka, de eléggé idegesít, hogy nem működik. Nálam Intel HD3000 GPU van, amit az i915 kernel driver hajtana.
-
Frawly
veterán
válasz
attilav2
#5963
üzenetére
A Windows nem tud systemd boottal indulni, mivel nem tartalmaz systemd-t. De egy épp olyan .EFI fájllal indul, mint amilyen a systemd bootnak is van, tehát megférnek egymás mellett, két külön EFI fájl, két külön bootloader, az UEFI BIOS bootkor mindkettőt megtalálja. Még a loader.conf-ba is be tudja magát írni a Windows (ilyenkor az Arch boot menüjében is látszik, anélkül hogy belemennél az UEFI BIOS bootmenüjébe), de ez továbbra sem jelenti azt, hogy systemd boottal indulna.
-
Frawly
veterán
válasz
attilav2
#5960
üzenetére
Ezt elég könnyű. Windows az nem systemd boottal indul, hanem a saját .EFI fájlait teszi be az EFI partícióra, de ez a systemd bootot nem zavarja. Pont ez az UEFI boot lényege, hogy sok OS .EFI loadere elfér ugyanazon az EFI partíción, és nem írogatják egymást felül, mint Legacy BIOS bootnál az MBR-ben. Szóval nyugodtan telepítsd újra a Windowst, az Arch systemd bootot nem fogja bántani.
Sőt, Windows UEFI bootos telepítésekor van több opciód is. Az egyik, hogy a linuxos meghajtó EFI partíciójára teszi az indítófájlait. A másik, hogy annak a meghajtónak az EFI partíciójára, amelyiken a Windows lesz. Mindkettő simán kell hogy működjön.
-
Frawly
veterán
válasz
attilav2
#5957
üzenetére
Megoldódott vele a konzol háttérszíne? El lehet lenni azért Legacy boottal is, de érdemesebb az UEFI bootra rámenni. Egyes gépeken meggyorsíthatja a booteszközök megtalálását, meg kényelmesebb több OS-nél.
Engem meg legutóbb az Arch a light nevű csomaggal ×0patott meg. Már van fél éve használom, de egy hónapja kitalálta, hogy nem ment a fényerőállítás. Utánaolvasva meg is találtam a megoldást, hogy a jogosultságprobléma, nincs jogom a /sys/class/backlight/intel_backlight/brightness írására, és nem elég átállítani chmod-dal, mivel bootkor nullázza magát, hanem udev szabályt kell rá csinálni. Meg is tettem, wheel csoport tulajdonába tette az udev szabály, meg adott neki a csoportra nézve írási jogot. Reboot, nem jó, nincs jogom írni. Anyád. Utánaolvasva találtam egy másik udev példaszabályt, ami a video csoportot használja, megpróbáltam ezt is, mert a felhasználóm tagja ennek a csoportnak. Így sem ment. Terminálban udev szabály nélkül kiadtam megint a chown-t a wheel csoportnak, majd chmod g+w, majd az udev szabályban is visszaírtam a wheel csoportra (csak a video stringet kellett megint átírni wheel-re). Reboot után jó lett. De amit nem értek, hogy mindjárt először is így próbáltam, akkor miért nem működött? Elég X-Akta.
-
Frawly
veterán
válasz
attilav2
#5951
üzenetére
Már el is küldtem privátban, ott válaszoltam. De valahová leírtam ezt ebbe a topikba is, mikor csixy csinálgatta magának a multibootos lemezeit. Neki sikerült a leírás alapján, sőt, annyira belejött ebbe a GRUB nélküli UEFI systemd bootba, hogy a végén vagy 9-10 disztró is bootolt neki ugyanezzel a módszerrel, az Arch systemd EFI loadere töltögette be mindet .conf fájl alapján. Szóval nem nehéz ez, csak rá kell jönni hogyan működik.
A legtöbb leírás feleslegesen ragaszkodik a GRUB-hoz, ez még Legacy BIOS MBR-es beidegződés, reflex.
-
Frawly
veterán
BIOS-t próbálj meg frissíteni, lehet úgy az új BIOS ténylegesen is le tudja kapcsolni a kívánt GPU-t. Nagyon más ötletem már nincs.
Az acpi-call-dkms-nél konkrétan arra gondoltam, hogy a hozzá való kernelmodullal együtt. Arch alapú disztrókon elvileg AUR-ban van, és kernelmodullal együtt települ.
-
Frawly
veterán
Hú, ez tényleg húzósabb, mint gondoltam. Minden oldal ezt az acpi-call-t írja, amit az Arch Wiki is. Esetleg acpi call dkms?
Akkor könnyebb lenne, ha két különböző gyártójú GPU lenne. De így, hogy mindkettő AMD és mindkettőt az amdgpu kerneldriver hajtja, így kiesik a kernelparaméteres letiltogatás, hiszen ha letiltod, akkor egyikkel sem lesz kép.
-
Frawly
veterán
Ezt kernelparaméterrel lehet elérni, a bootloaderben megadod a kernel mögött a vonatkozó paramétert, hogy az IGP-t használja. De ehhez tudni kéne, hogy pontosan milyen IGP-ről van szó.
Szintén kernelparamétereknél le lehet tiltani a dGPU-t is. Ehhez megint tudni kéne, hogy pontosan milyen GPU-ról van szó.
-
Frawly
veterán
Mielőtt valaki jönne, hogy rövid időn belül már a második frissítés problémás Archon, annak azért elmondanék előre pár dolgot:
1) Ez a két érintett csomag elég ritkán használt. A tensorflow egy gépi tanuláshoz való valami (nem sokan foglalkoznak vele), az astyle forráskód formázáshoz (amit azért nem használnak sokan, mert azt a fejlesztői IDE-k is automatice megcsinálják). Tehát egyszeri Gipsz Jakab átlagfelhasználó általában ezeknél nem is érintett egyáltalán. Általában azért is szoktak ezek ritkán használt csomagnál előfordulni, mert azok ritkábban frissülnek és ilyenkor nagyobb közöttük a verzióbeli ugrál általában.
2) Az ilyen figyelmeztetéseket legtöbbször már maga a pacman is kiírja, elismételve a hírt, arra az esetre, ha valaki nem követi az Arch oldalát.
3) Általában ezek könnyen megoldhatók. Ha a hírre nem is figyelmeztet a pacman (de szokott), hanem csak pl. azt írja ki, hogy blabla already exists, akkor azt a bizonyos fájlt, symlinket csak el kell távolítani sudo rm-mel vagy pacman --overwrite-tal felülírni. Ha azt írja, hogy package conflict, akkor a vonatkozó csomagot el kell távolítani sudo pacman -R kapcsolóval, az új megfelelő csomag meg be lesz húzva függőségként Szóval a megoldás általában valami pofon egyszerű valami, nem kell hozzá feltétlenül az archlinux.org hírszekcióját követni árgus szemekkel.
4) Évente jó ha 1-2 ilyen van. Általában az is valami apróbb-cseprőbb csomag. Jelentősebb szopó frissítésnél Archon akkor volt, mikor systemd-re álltak át, de az minden disztrónál szopó volt. Azóta csak ilyen apró, könnyen megoldható manual intervention-ök vannak nagy ritkán már évek óta.
-
Frawly
veterán
Ezt egy kicsit bővebben kifejtem, mert nem érthető.
Tehát az SSD-ket ún. lapméret alapján szokták alignálni. Az SSD-n a NAND cellák NAND lapokba vannak rendeződve. De egy darab cellát nem lehet írni/olvasni (az SSD vezérlője nem képes rá), hanem csak egy egész NAND lapot (akkor is, ha csak 1 cellát érint majd a módosítás, olvasás). Ez a lapméret jellemzően 4KB volt a régi SLC-MLC-s SSD-ket, egy ideig még a TLC-seken is, de a modern 3D NAND-on már általában 16 KB vagy még több.
Emiatt a legtöbb particionálóprogi 1024K eltolással particionál, mert az maradék nélkül osztható 4K-s, 8K-s, 16K-s, 32K-s, ..., 512K-s, 1024K-s lapmérettel is, megfelelve a jövőbeni SSD-k igényének is.
Na most itt ebben a topikban valaki német fórumok javaslata alapján felvetette, hogy egy még nagyobb egység, a blokkméret alapján kéne alingálni. Ugyanis a NAND lapok egy még nagyobb egységbe, ún. blokkban is kezelhetők, ennek törléskor, trimeléskor van előnye. A blokkméret általában elég nagy, ilyen több MB-os, SSD-nként eltérő, modern 3D NAND-okon magasabb, mint korábbi 2D-seken, ilyen 6-30 MB nagyjából. Tehát egy blokkban ~1000-es nagyságrendű lap van.
De itt jön a logikai bukfenc. A fájlrendszerek által kezelt logikai szektorok 0,5-4K-sak jellemzően, ez meg is felel, maradék nélkül osztható a 4-16K-s lapmérettel, és az 1024K alignálással, mert így a lemezműveletek nem lógnak át laphatárokon. De tegyük fel, hogy nem blokkméret alapján vannak alignálva a partíciók. Ekkor a partíciók első és utolsó pár szoktora, fizikai lapja átlóghat blokkhatárokon, de ez csak ezt a pár szektort, lapot érinti. De a közöttük lévő szektorokat nem, mert azoknak a lapmérete/szektormérete maradék nélkül osztható a blokkmérettel, így nem lesz olyan köztes lap/szektor, ami blokkhatárokon nyúlna át.
Vegyük például az én átlagos felhasználásomat. Egy régi 3D TLC-s SSD-m van, 16 KB-os lapmérettel, 24 MB-os blokkmérettel (1 blokkban 1536 NAND lap van), és 4KB clusterméretes ext4 partíciókat használok rajta, 512 bájtos logikai szektormérettel. A partíciók 1024K-n vannak alignálva. Ez azt jelenti, hogy a partícióim első 23 megabájtja (1472 lapja vagy 5888 logikai klusztere vagy 47104 logikai szektora) átlóg blokkhatárokon. Az ezek után lévő többi szektor, lap nem lóghat át blokkhatáron, ami a tárterület 99,99%-át jelenti.
A gyakorlatban tehát ezzel annyit bukok, hogy ezeknek a szektoroknak a törlése lassabb egy nagyon minimálisan, talán már ez sem mérhető. De mi annak az esélye, hogy pont az ezekre eső blokkot érinti a törlés? Nagyon minimális. Szóval a gyakorlatban nincs semmi értelme blokkméret alapján alignálni, felesleges önszopatás. Nem nagy áldozat, mert maximum 23 MB veszteséggel járna az első partíció előtt a kihasználatlan terület, de nekem pl. nem tetszene, hogy emiatt nem feltétlenül lennének egész GB-tal osztható partícióméreteim. Ez utóbbi akkor jön jól, ha szétcsesződne a partíciós tábla (bár GPT-n ilyenkor van belőle több másolat), könnyű rekonstruálni a partíciós táblát.
Persze továbbra sem lehetetlen, mert csinálhatnám úgy, hogy partícióméretek ne csak 1 GB-tal, hanem 24 GB-tal legyenek oszthatóak (pl. az első partíció 48 gigás, a második 240, a harmadik 480, stb.), de ez felesleges matek, meg helypocsékolás az első partíció előtt. Ez ilyen tipikus német precízkedés, hogy 0,00000001% előnyért szopjuk, hogy elméletileg is maximálizáljuk a lehetőségeket. Nehogy egy krumlihéjnyi valami is pocséka menjen.
Arról nem is szólva, hogy az adott SSD blokkmérete elég nehezen deríthető ki adott esetben. Az SSD gyártók fel sem tüntetik, hanem be kell azonosítani a NAND típusát (ha ezt sem találni meg online, akkor szét kell szedni az SSD-t, vagy leszedni róla az M.2 matricát, ami azonnali garivesztés, és megnézni milyen NAND van rajta), majd a NAND gyártójának valami részletes technikai spec sheetjéből nyomozható ki. Tényleg nem éri meg vele szívni.
-
Frawly
veterán
válasz
Siriusb
#5921
üzenetére
SSD-s körökben szokták használni, nem a térdemből szoptam. Ahogy a particionálást sem fordítják le, sokan az alignálást sem magyarítják le még jobban partícióeltolásnak. Ja, tudom, újmagyar, a grammar nazikat lehet zavarni fogja, majd szednek nyugtatót. Felírja nekik az orvos, klaviatúrán, majd kinyomtatja a printeren. Vihetik utána a receptet az apotékába szkennelésre.
-
Frawly
veterán
Ezt még nem volt időm tesztelni, mármint a blokkméret alapján történő alignálást, de már előre rájöttem, hogy hülyeség lesz.
Tegyük fel, hogy nincsenek blokkméret alapján alignálva a partíciók. Ez csak a partíciók első és utolsó blokkját befolyásolja lényegében. Ez pedig kevés ahhoz, hogy sebességbeli hátrányt vagy élettartamnövekedést hozzon.
Nem véletlen, hogy csak ilyen ködös német fórumok írnak erről a blokkméret mentén alignálásról, és ehelyett midenki a sztenderd 1 megás partícióeltolást használja, amit a particionálóprogik és telepítők alapból alkalmaznak.
Persze ki fogom próbálni, mert nem kerül semmibe, de már előre látom, hogy nincs értelme, nem javít majd semmin. Nem is egy nagy áldozat, csak felesleges.
-
-
Frawly
veterán
válasz
eddie1978
#5894
üzenetére
Nem nagyon off, már kíváncsi voltam valakinek a tapasztalatára a Clear Linuxot illetően. Ezek szerint gyorsabb, mint az Arch.
Az akku lehet simán halódik már, gyenge, és bizonyos százalékon túl gyorsan esik. Elvileg lehet kalibrálni, teljes lemerítés majd feltöltést követően, de az aksi ereje nem áll helyre, csak a töltöttségi százalékok fognak egyenletesebben esni róla.
-
Frawly
veterán
válasz
Shyciii
#5891
üzenetére
Ez nem csak az Openboxot fenyegeti, az IceWM-et, meg a többi régi X.org-os WM-et sem fejlesztik már. Egy megoldás van, megtanulsz programozni, forkolod, és karban tartod te.
Elvileg DPI-t a többféle módon tudsz állítani, ~/.Xresources fájlban, X.org beállításaiban, randr-ban. Ennek ellenére megvannak a korlátai, a HiDPI-t semmiképp nem fogja támogatni az Openbox. Kézzel még annyit tudsz rajta segíteni, hogy nagy felbontású kijelzőn beállítasz rohadt nagy betűtípust, 20 pontosat vagy nagyobbat, meg eleve olyan témát választasz, amin nagyobbak a grafikus elemek. Esetleg lehet a Gtk témával is variálni, de olyat még nem csináltam. Körülményes, sok hekkelést igényel, de elérhető, hogy normálisan nézzen ki ultranagy felbontáson, meg nagy képpontsűrűségen is.
-
Frawly
veterán
válasz
Shyciii
#5889
üzenetére
Gondolom az Openbox fejlesztője úgy van vele, hogy amit akart funkciónak, az már benne van, stabilan működik, és lezártnak tekinti a fejlesztést. Ez viszont soha nem jó hozzáállás. Pl. engem az idegesített az Openboxban, hogy témázásnál csak két színű XBM képelemeket támogat, és emiatt nagyon korlátozott, amit designügyileg csinosítani lehet rajta.
-
Frawly
veterán
válasz
Shyciii
#5887
üzenetére
Nyilván az Openboxot úgy értem, hogy felkonfigurálva, panellel, indítómenüvel, stb.. Alap konfigban tényleg fapados lesz klasszik DE usereknek. De még mindig jobb ebben is, mint a tiling WM-ek, mert ott szürke háttér sincs, meg kattintani sem lehet semmire, hogy legalább egy kamu menü előjöjjön.
Az engem is aggaszt, hogy az Openboxot rég nem fejlesztik, több éve, igaz egy éve jött ki belőle új verzió, de abban is minimális változás volt.
-
Frawly
veterán
válasz
Shyciii
#5885
üzenetére
A Gnome szerintem is rossz. Semmit nem lehet rajta állítani. Még ha fel is teszi az ember a Gnome Tweaks-t, akkor is egy csomó dolog állíthatatlan marad, ilyen alap dolgok, hogy hol legyen a panel, meg mi legyen rajta. Fel lehet tenni rá addonokat, de azok sem segítenek minden hiányosságon.
RAM-nál nem a swappiness értékével érdemes játszani, hanem venni kell elég RAM-ot. Min. 8 GB-ra bővítsél, ha kifogod olcsón, van rá keret, akkor 16-ra, igaz az már overkill lehet, bár erősen felhasználásfüggő. A 32+ GB-nak viszont tényleg nincs értelme átlag felhasználásnál, az csak felesleges pénzégetés.
A Sway-en még gondolkodok, mert ez a stabil tárolókban felrakott 1.1.1 jól működik, és végre rátaláltam a redshift-wlr-gamma-control-git AUR csomagra, amivel van újra redshift-elési lehetőség is. De ennek ellenére elkezdem újra használgatni a dwm-et is.
Az Openbox valóban nagyon jó, az a fajta felület, ameddig átlag desktophoz szokott user is le tud menni minimalizmusban. A tiling WM-ek meg az IceWM már túl fapados lehet DE-khez szokott emberkéknek.
-
Frawly
veterán
válasz
Shyciii
#5883
üzenetére
Igen, a KDE és a Gnome3 a két legnagyobb, ami támogat Waylandet. Ezen kívül van a Sway WM, Enlightenment, ami használható. A többi waylandes felület még nagyon demo/alpha állapotban van, nem használhatók.
De én pl. most fogom dobni a Sway WM-et is. Most próbáltam frissíteni a legújabb dev-git-es ágra, erre felcserélődtek a touchpad és trackpoint gombjai, a konfig fájlban az új left_handed disable opcióval sem sikerült helyreállítani. Befrissítettem a többi Sway összetevőt is, wlroots, swaybg, stb., de erre az egész segfault-olt. Most egyelőre a stabil 1.1.1-es van fent az Arch hivatalos tárolóból, ez is relatíve friss verzió, de elegem van belőle, hogy ilyen trehány banda fejleszti. Visszaállok X.org + dwm-re.
Kár érte, mert a Wayland tetszene. Egyszerű, gyors, pattogós. Semmi 1000 éves visszafelé kompatibilitás, vsync-kel kínlódás meg bloatság. De ha a fejlesztők ennyire töketlenek hozzá, hogy nem tudnak rá normális felületet írni, akkor nincs értelme.
KDE-t, Gnome-ot nem teszek fel, túl bloatak. Ezen kívül a Gnome túl fapados is, esküszöm dwm-en többet lehet testre szabni.
-
Frawly
veterán
válasz
ubyegon2
#5880
üzenetére
WM-eknek ott a haladó topik. Bár ide is belefér, mert Archon volt kérdéses, és nem kezdők topikja ez se. Igen, a WM-eket meg kell ismerni, viszont megéri. Nyilván ha még nem vagy rá készen, akkor Eltéess Elemérkedj DE alapokon.
A Wayland WM-es kalandjaimat a Linux OFF topikba szoktam írni a magam részéről, mivel ott semmi nem OFF.
-
Frawly
veterán
válasz
ubyegon2
#5877
üzenetére
A klónokról nem tudok nyilatkozni. De az Arch-ban az a poén, hogy valóban nem DE-s felhasználóknak készült, hanem univerzális próbál lenni, hogy szerveren, meg minimalista konzolos, terminálos, WM-es felhasználáshoz is jó legyen. Persze felrakhatsz rá DE-t is, az kényelmesebb.
Nyilván ha pl. felteszed Archra a Cinmanót, akkor az hoz magával minden függőséget, dbus, X.org, mesa, login manager, témák, default alkalmazások, stb..
Archból épp ezért nincsenek kiadások. Nincs stable, nincs LTS, nincs desktop, nincs server edition. Testing sincs, de ahhoz vannak plusz tárolók, amiket be lehet kapcsolni.
-
Frawly
veterán
válasz
Shyciii
#5876
üzenetére
Az SSDM csak a KDE Waylandet támogatja. A GDM jóformán az összes létező waylandes felületet. A LightDM csak X.org-os felületeket.
Ha konzolon jelentkezel be, akkor a képernyő zárolására vannak grafikus programok, pl. i3lock, vagy hasonló, igaz ezek nagyon fapadosak.
Egyébként az Arch + minimalista WM felállásban ez a nehéz. Nem telepíteni, hanem mindent beállítani, testre szabni. Ezeket a DE-kkel készen kapod, de WM-ek alatt mindenről a usernek kell gondoskodnia.
-
Frawly
veterán
válasz
Shyciii
#5866
üzenetére
Lehet, hogy alapesetben lesz benne egy vezetékes kapcsolat, de ha nem lenne, akkor bizony fel kell venni nm-appletben egy vezetékes kapcsolatot, IP-nek dinamikust adsz meg, és mindent default-on hagysz, meg bejelölöd, hogy az legyen az alapértelmezett kapcsolat.
Tint2 elmegy, de a polybar szerintem is jobb.
Én anno LXDM-et használtam login managernek Openbox mellé. De mióta áttértem minimalista megoldásokra, azóta nem használok semmilyet. Egyszerűen konzolon jelentkezek be, és bizonyos konzolok (pl. 1-es, 2-es) úgy van beállítva a bashrc-ben, hogy az adott WM-et indítsa el (SwayWM, dwm) bejelentkezés után automatikusan. Ennek csak annyi a kellemetlensége a login managerhez képest, hogy a felhasználói neved is nekem kell beírnom, nem csak a jelszót. Viszont ezt felfogható egy plusz biztonsági lépésként, mert így a rendszerbe kontárkodóknak nem csak a jelszavad kell kitalálni, hanem előbb a felhasználói nevet is.
A login managereket én azért dobtam, mert fagyogatott a GDM-en és a KDE login managerén kívül az összes, az Intel GPU drivere miatt. Meg a SwayWM waylandes, és azt nem is tudja sok login manager indítani, lényegében csak a GDM támogatná, az meg nekem bloat.
-
Frawly
veterán
válasz
Shyciii
#5864
üzenetére
Akkor viszont ha van Network Manager, akkor dhchcd-t nem szabad használni, hanem a kapcsolatokat felvenni a grafikus nm-applet-ben. Majd csak utána fognak működni, meg legközelebbi bootolásnál automatikusan kapcsolódni, meg DHCP-ről címet kérni.
Tudom mit beszélek, én is használtam már Archon Openbox + Tint2 + NetworkManager + nm-applet + Wi-Fi felállást.
-
Frawly
veterán
válasz
Shyciii
#5856
üzenetére
De, kapcsolatot létre kell hozni Network Managerben, pl. nmcli-vel. Vagy wifi-menu-vel.
Bár az sem mindegy, hogy vezetékes vagy vezeték nélküli kapcsolatról van szó. Ha csak simán vezetékes, akkor lehet kap dhcpcd automatikus indulásával is IP-t, de Wi-Fi sose ilyen egyszerű, mert ott SSID, jelszó, frekiállítás, stb. van.
Szerk.: látom vezetékes kapcsolat. Ahhoz nem kell Network Managert felrakni, ha nem tervezel másik kapcsolatot használni mellette.
-
Frawly
veterán
válasz
Shyciii
#5843
üzenetére
Nálam i7-2620M prociról van szó (Sandy Bridge), 16 giga RAM, Crucial MX300 SATA3 SSD, Arch Linux Openboxon próbáltam akkoriban, pluginek nélkül az Atomot. Nem mértem hány másodperc, de elég lassú volt minden tekintetben.
A GIMP meg a LibreOffice minden gépen lassan indul, i9-esen, meg Threadripperen is, még az sem számít nekik, ha NVMe SSD-t teszel alá. De csak az első indítás ilyen, ha nem rebootol valaki, másodjára gyorsabban nyílnak meg. De a GIMP-nél meg a LibreOffice-nál nincs gond ugyanezen a gépen, lassan indulnak, de aztán használható sebességgel futnak, nem úgy, mint az Atom.
-
Frawly
veterán
Nálam i7-es notin az egész Atom volt kompletten lassú, indulás, szöveg beírása, menük reakcióideje. Pedig még plugin is alig volt fent, azért is volt fapados.
A vim valóban érthetetlennek tűnik elsőre, mert gépíráshoz tervezték, meg módok között kell váltani, és ezt nehéz megszokni. Egyébként a vim nem is szövegszerkesztő, hanem szövegfeldolgozó, olyasmi, mint a sed, awk, csak valós időben viszed be szövegmanipuláló parancsokat billentyűkkel. Eleve, mikor manipulálja valaki vele a szöveget, akkor nem úgy kell gondolkodni, mint egy normál szövegszerkeszőnél.
A Geany teljesen jó. Régen a Kate volt még jó, igaz az nem nagyobb projektekhez volt akkor sem való, de az 5-ős verziótól kezdve agyon van butítva, ahogy a Gedit is. Ezért a vim előtt SciTe-t használtam. Jó még a Sublime, de az fizetős. A Kommodo Edit sem lenne rossz, de az elviselhetetlenül bloat. Projektekhez állítólag a Visual Studio Code jó, az ingyenes.
Aki vim-mel próbálkozik: mindenképp a gvim-et tegye fel, akkor is, ha nem GUI-n használja (javasolt nem GUI-sat használni), hanem terminálból. Azért gvim-et, mert az abban lévő vim tudja a vágólapkezelést a X.org felé. A sima vim csomagban lévő vim-ből ki van szedve egy csomó funkció, eleve úgy van forgatva a forráskód. Illetve a neovim-mel lehet próbálkozni, de az nem sztenderd még, nem próbáltam.
Amire még sokan esküsznek, de nekem mindig is átláthatatlan volt, meg nehezen lenyomható billkombói vannak: Emacs.
-
Frawly
veterán
válasz
Nagytoll
#5826
üzenetére
Ott valami nem linuxos gond van, mert annyit minimum ki kéne írjon az UEFI BIOS-nak is, hogy nem talált bootolható OS-t. Ha F12-re vagy ilyesmire kézileg előhozod az UEFI BIOS bootmenüjét, ott milyen lehetőségeket kínál? Secure boot ki van kapcsolva?
A GRUB-ot jól telepítetted, bár az elérési útja (/EFI) attól is függ, hogy miként van felcsatolva. Az biztosan nem baj, hogy nem /dev/nvme-ként adtad meg, az nem működne. Ez már nem MBR, hogy a GRUB indítókódját oda kéne írni. Az NVMe eszközökön kötelező a GPT+UEFI boot, és az UEFI indítófájlok mindenképp az EFI partícióra mennek, vagyis abba a mappába, ahová az EFI partíció fel van csatolva.
-
Frawly
veterán
válasz
#63718632
#5823
üzenetére
Pedig sudo systemctl enable ufw.service paranccsal kell indítani. Egyébként lehet elindul nálad, de ez csak magát a tűzfalat indítja, a grafikus kezelőfelületet nem, tehát a gufw-t be kéne tegyed az asztali környezet vagy ablakkezelő automatikus indításába, hogy lássad futni.
-
Frawly
veterán
Na, közben megtaláltam a Micron doksit, ez az MX300-on lévő 32 rétegű 3D TLC NAND-ra 16K-s lapméretet ad meg, de a blokkméretnél 1536 lapot ír, ez pedig 24 MB-os blokkméretre jön ki, amit néhány IT-s oldalon írt cikk is megerősít.
Majd kipróbálom, ha újrahúzom a rendszert, hogy 24 MB-on alignálok, bár elég overkillnek néz ki, de kíváncsi vagyok mennyit gyorsul. Tippre semennyit nem fog.
-
Frawly
veterán
válasz
vinibali
#5813
üzenetére
Ja, így már értem. De ez szerintem továbbra is hülyeség. Valóban, így már ártani nem árt a 6 megás eltolás (1,5×8K), de használni sem használ semmit.
Az én Crucial MX300-amban már 16K-s lapok vannak, a block erase size-t nem tudom, elő kell keresnem a pdf doksit a Micron-tól. De a sztenderd 1M-es eltolással teljesen jól megy. Igaz nem egy villám SSD, mert nem valami gyors, de nagyobb eltolással sem lenne jobb. Ennek ellenére kíváncsivá tettél ezzel a témával, legközelebb, ha particionálom, kipróbálom nagyobb eltolással.
-
Frawly
veterán
Az 5.2-es kernellel eltört a Wine, de nem telt el egészen 24 óra, jött a javítás, Wine 4.12-es, ezzel már jó. Az eltörtet úgy kell érteni, hogy futott, de boothibát írt ki, le lehetett okézni, onnantól működött minden rendesen. Gyorsan rendbeszedték. Ez a jó az Archban, ha el is törik valami, hihetetlen gyorsan lépnek. Aki nem frissít túl gyakran, mondjuk csak hetente, az bele sem fut jó eséllyel.
-
Frawly
veterán
Nem ugyanaz a mikrokód minden AMD procinál. De azonos csomagban vannak, linux-firmware, alapból telepítve van, induláskor a kernel ebből betölti a gépben lévő procira vonatkozót.
A GPU driver attól függ milyen GPU-d van. Ha AMD, ahhoz nem szokott megint semmi extra kelleni, a linux-firmware csomagban ott vannak a szükséges firmware-ek hozzá, a kernelben meg az opensource driver, ehhez már csak a mesa csomag kell, de ez is fel szokott kerülni függőségnek.
Szerintem a váltásnál nem lesz problémád, főleg, hogy AMD-ről AMD-re váltasz. Simán mennie kéne mindennek.
-
Frawly
veterán
válasz
vinibali
#5799
üzenetére
A 6 MB-os partícióeltolás rossz. A Samsung 840 EVO planár TLC-s SSD, 4K-s NAND lapokba szervezett cellákkal. 4K-s partícióeltolás kell neki. De a linuxos és modern windowsos toolok, telepítők régóta 1024K-n particionálnak, ami osztható egy csomó eltolással, így megfelel a 4K-s, 8K-s, 16K-s, stb. eltolásnak is. Ez fontos, mert a modern 3D TLC-s és 3D QLC-s SSD-k már min. 16K-s particionálást igényelnek.
Archon meg a /boot/loader/loader.conf szerkesztésével vagy az efibootmgr futtatásával be lehet állítani, hogy melyik UEFI-s bootlehetőség bootoljon default. Egyszer átállítod, a Windows utána már nem fog hozzányúlni, miután egyszer a telepítése után ezt megcsináltad. De kulturált UEFI BIOS-okban is lehet kézzel állítani a sorrendet.
Bootidőnél nem minden gépen van nyereség. Én az UEFI bootot inkább a kulturáltsága miatt szeretem, átláthatóbb, nélkülözhetővé teszi a GRUB-ot. Csak a secure boottal meg közbeláncolt extra bootmanagerekkel (GRUB) nem kell bonyolítani, az UEFI egymagában is egy bootmanager, használható systemd boottal, további bootmanager közbeiktatása nélkül. Ráadásul kényelmes is, mert Arch alatt egyszer megcsináltam az UEFI systemd bootot, és lassan már 3. éve hozzá sem kellett többé nyúlni, pedig a Win10-et és az Archot már párszor újratelepítettem azóta, de mivel az UEFI bootbeállítások az EFI partíción tárolódnak, azok nem vesznek el újratelepítéskor. MBR-nél minden újratelepítéskor telepítheted újra a GRUB-ot vagy Syslinuxot, vagy amit használsz.
-
Frawly
veterán
válasz
Shyciii
#5793
üzenetére
A HDMI-s gépre még nem tettem fel az Archot, de használtam már Linuxon HDMI-n. Meg kéne jelennie a HDMI-s hangeszköznek a PulseAudio kimenetei között, azt kéne kiválasztani. Ezt alapból nem is mpv-ben kell állítani, hanem a pamixer-ben, hogy a megfelelő kimenetet használja. Valószínű analóg jack kimenetre állítottad, azért nem küldi ki a hangot.
-
Frawly
veterán
-
Frawly
veterán
Erről nem kell neked gondoskodni. Ha a proci lesz a szűk keresztmetszet, akkor a kernel ütemezője úgyis úgy fogja pakolgatni a szálakat, hogy jól kihasználja a procit. Ennek ellenére a gigabites netet azzal a procival nem fogod tudni kihajtani, túl gyenge (rossz IPC, kicsi freki, kevés L2 cache, amin az összes mag osztozik), több szálon futó torrentprogival sem. Egy normálisabb i5/i7-es szintet szoktak ajánlani gigabithez.
Fogadd el, hogy csak egy részét leszel képes kihajtani a gigabitnek, vagy cseréld le azt a gépet / procit.
Egyébként meg a gigabites netnek ezért nincs lakossági szinten értelme. A legtöbb embernek se a kábelei, se a routere, se a Wi-Fi-je, se a hálókártyái, gépei, akármilyei nem tudják kihajtani a felét sem.
Ha nagyon minimalista torrentprogi kell, akkor rtorrent.
-
Frawly
veterán
válasz
Shyciii
#5744
üzenetére
Ennek egyszerű a megoldása, tegyél fel Qt-s sötét témát, ami hasonlít a sötét Gtk-s témádra. Persze Arch Wiki alapján rá lehet erőszakolni a Gtk-sat is a Qt-s progikra, de ez bugokkal járhat.
Nálam már csak egy Qt-s alkalmazás maradt, a qBittorrent, de le fogom cserélni, úgyis egyre ritkábban használom és egyre alapabb dolgokra. Régen viszont nagy szükségem volt rá, mert elég nagy seedállományom volt, amit nehéz volt gondozni, de ma már ez nem érint.
VLC helyett ajánlom az mpv-t. Notepadqq helyett meg SciTe. De ez egy fejlődési folyamat, ahogy egyre hosszabban használsz Linuxot, úgy fejlődik az alkalmazásválasztékod is, terelődsz az egyre kevésbé bloat megoldások irányába. Lásd KDE helyett már Openboxot használsz, qBittorrent helyett Transmissiont (Delugot nem ajánlom, Pythonban írt, erőforrás-zabáló, lassú), XnView helyett feh-t. Majd fog ez még fejlődni, mire eljutsz te is a terminálos alkalmazásokig, meg a még fapadosabb WM-ekig.
-
Frawly
veterán
Arch Linux Drops GCC 9 From Testing Due To BCache Corruption Bug
Mielőtt ubyegon örülne, hogy instabil az Arch, csak úgy mondanám, hogy csak Testingen jön elő, és ott is csak akkor, ha SSD-vel cache-el valaki HDD-t, és még az is kell hozzá, hogy valaki 5.0 vagy újabb kernelt használjon. Én nem teszek ilyet, így nálam Testingen sem okozott gondot a legújabb kernel mellett gcc 9.1, simán fordult vele minden. Ennek ellenére beraktam ide a hírt, hátha valaki érintett, mert az archlinux.org-ra csesztek kitenni. Gondolom úgy voltak vele, hogy Testing tárolót úgyis csak a bátrak és a haladók használnak, ők megoldják maguknak.
-
-
Frawly
veterán
válasz
Shyciii
#5714
üzenetére
A libva-intel-driver is működhet, de a te GPU-d már a legújabb generációba tartozik és az intel-media-driver való hozzá, amit gyurmafigura ír. Ez több codec-et támogat. Ellenőrizheted az Arch Wiki VAAPI cikkéből kiindulva.
A Chrome egy hulladék mindenképpen, az alatt a hardveres gyorsítás mindig is problémás volt. Persze ha elégedett vagy a libva-val, akkor maradhatsz annál. Én is azt használom, de én kényszerből, az én Intel IGP-m még egy régi generáció, és azt nem támogatja az intel-media-driver, hiába telepítem, nem használja a rendszer.
-
-
Frawly
veterán
válasz
Shyciii
#5709
üzenetére
Igen, ha nem váltogatod, akkor az Intel IGP-t használja. Ezt inxi -Gxxx futtatásával ellenőrizheted is.
Nálam van egy kis akadás. Nem nagy, néha, sok másodpercenként kicsit ugranak a csíkok. Nem tudok vele mit csinálni, ez az eltérő fps miatt van. Tényleg csak olyan enyhén, hogy ilyen tesztvideóval lehet csak kimutatni, akkor is nagyon figyelni kell rá, hogy észrevegyem. Nekem csak Intel IGP-m van (HD3000).
Annak örülni kell, ha nálad egyáltalán nem csinálja. De Intel IGP-n is sok mindentől függ, milyen driverrel hajtod, pl. KMS kernel driverből is van már kétféle, az egyik a hagyományos i915, a másik az Iris Gallium3D, ami alapból nincs bekapcsolva, és a Broadwell prociktól kezdve támogatja az IGP-ket, a régebbi Intel GPU-kra csak az i915 elérhető.
Az sem mindegy, hogy fent van-e a X.org-hoz a xf86-video-intel driver (nem ajánlják, de van, aki esküszik rá mégis), vagy enélkül hajtod, vagy ha fent is van, akkor be van-e kapcsolva a tearfree vagy valami egyéb opció benne.
De még kompozitora is válogatja. Compton és Compton között is vannak különbségek, még az eredeti verziókban is, nem hogy a forkhoz képest.
-
Frawly
veterán
válasz
Shyciii
#5707
üzenetére
Valamennyire minden kijelzőn akadnak ezek a tesztcsíkok. Azért tűnik randomnak, mert nem minden képkocka kerül asszinkronba, kell egy pár frame, mire annyira asszinkronban frissülnek a képkockák, hogy akadást érzékelsz. A kijelződ sanszosan 60 Hz-es, míg a legtöbb videó 29.97 fps-ses. De még 60 fps-ses videónál is előjön, hogy a kijelzőfrissítés sose pontosan 60 Hz, hanem ilyen 59,99 vagy 60,02 vagy hasonló.
Még nálam is van egy kis akadás, pedig nálam se X.org, se Compton, se Compton git, helyette Wayland kompozitor van (wlroots + SwayWM).
A gond akkor van, ha túl nagyok az akadások, szinte végig diavetítés az egész, na, akkor tényleg a GPU driver nem jó.
Milyen hardveren használod az Arch Openboxot? A GPU miatt kérdezem.
-
Frawly
veterán
-
Frawly
veterán
Nem, nem arra gondoltam. Meg lehet úgy csinálni, hogy időkorlátra való tekintet nélkül nem kell többé beírni a jelszót rebootig, még másik ablakban sem. Ez még kényelmesebb, mint az időkorlát megemelése. De képzeld el, hogy véletlenül lefut valami szutyok, ami simán root jogot kap, mert már egyszer aktiváltad a sudo-t. Nem véletlen, hogy az összes disztróban a default az 5 perc körüli idő. Igen, kényelmetlen állandóan beírogatni, kellemetlenséggel jár, ha lejár, de a felhasználó saját biztonságát szolgálja.
Ha csak az a baj, hogy yay-es telepítés vége felé time out-ol, simán újra kell csak indítani a yay -S programnév paranccsal, akkor látni fogja, hogy .cache-ben már le van fordítva, és egyenesen a telepítéséhez fog hozzákezdeni az elkészült, azaz a már lefordított és betömörített AUR-os csomagnak. Vagy amit már írtak, hogy a yay tartja meg a sudo jogot egy kapcsolóval.
-
Frawly
veterán
A password timeout-ot nem ajánlom 0-ra venni. Sőt, azt sem, hogy csak egyszer kérjen jelszót tty_tickets-szel , és onnantól az egész sessionben ne kelljen újra sudo-t megadni, másik ablakban sem. Hihetetlen kényelmes, de biztonságilag megkérdőjelezhető. Egyszer futtatsz valamit sudo-ként onnan minden szutyok egyszerű sudo-val rendszergazdai joghoz jut, elég veszélyes.
A kényelem és a biztonság egymást kizáró fogalmak.
Az AUR-ból forgatás úgyis csak a legelején és a legvégén kér jelszót. Először mikor a build függőségeket teszi fel, másodszor mikor a kész csomagot. Nem kell ott ülni mellette. Ha végzett és time outolna, akkor a cache-ben megmarad a kész csomag, azt felteszed pacman -U segítségével.
(#5689) Siriusb: wow, ezt a nobody useres trükköt nem ismertem. Ez a jó a Linuxban, minden nap tanul az ember valamit.
-
Frawly
veterán
A sima userként lefordítod és betömöríted csomagot yay-jel, majd root-ként pacman - U ~/.cache/yay/új-csomag-neve.tar.xz módon.
De szerintem minden AUR helpernek fog kelleni sudo jog, mert a végén, amikor a csomagokat telepítenék, ahhoz nélkülözhetetlen. Vagy csinálod úgy, ahogy fent írtam, cache-ből telepíted rootként a kész csomagot.
Azt sem értem, hogy miért ne akarnád a felhasználód felvenni a sudoers-be, vagy ha nem akarod, akkor gondolom biztonsági célzattal, de akkor meg miért szeretnéd, hogy tudjon mégis a rendszerre csomagokat feltelepíteni? Valahogy az egész problémád nem áll össze nekem.
-
Frawly
veterán
Ja, Chrome újrafordítását én sem ajánlom, állítólag nagyon lassú és szopós, és akkor frissülni sem fog. Szerintem bőven elég Chromiumot feltenni a tárolókból, és a neten utánaolvasni milyen google-os cucc van bekapcsolva rajta, azokat a flags:// oldalakon kiirtani belőle.
-
Frawly
veterán
Igen, most jelenleg egy elég új csomag van belőle, de hosszú hónapokig csak egy régebbi volt elérhető, valami 0.7-es vagy 0.9-es, mikor a git-ágban már rég az 1.0RC ment. De majd idővel elavul újra a sway csomag. Igen, Archon valóban frissek a csomagok, de azért 1-2 kivétel, meg 1-2 lusta csomagfenntartó akad sajnos. De mint mondtam, ebbe az 1-2 perc fordítási időbe senki nem döglik bele.
Ez szokott lenni a dwm-mel is. Ott is mindenki fosik, hogy újra kell fordítani, ott ráadásul minden konfigolás után, de az meg csak másodpercekig tart. Abból is van csomag, de mivel minden konfigurálás után úgyis újra kell fordítani, nem érdemes használni. Kicsit ilyesmi a Sway is, bár azt nem kell újrafordítani konfiguráláskor, de érdemes belőle a legropogósabb git-dev verziót használni.
kékluficet: nem kell ide ebuild meg emerge. git clone https://faxtudjami/sway/blabla.git, cd mappa, make és kész. Persze előtte a wlroots-ot kell ugyanúgy fordítani. Nem egy nagy technológiai malőr.
-
Frawly
veterán
Sway-t nem ajánlják, mert elég gyorsan fejlődik, a stable disztrócsomagokban pedig egy régi verzió van. Bugjelentést sem fogadnak el róla, azonnal elutasítanak a fejlesztők is kérdéssel, kéréssel, ha nem a legújabb verziót használod. De mint mondtam, egy gyenge gépen is kb. 2 perc lefordítani, gyorsabbon meg néhány mp..
Plusz akinek Gentoo-ja van, az pont azért tette fel, mert nem akar tárolóktól függeni.
-
Frawly
veterán
Akkor sikerült téged is félreértenem. Ha már Gentoo-d van, forgass kézzel. Egy Termite nem is rettenet nagy. Nem Chrome, LibreOffice, stb., amit több órán át kell fordítani.
Ezt szeretem a Sway-ben is, hogy marha pici. Archon is forráskódból kell forgatni, de ezt ajánlják a Sway fejlesztői is. De egy elég régi gépen is lefordul 1 perc alatt a wlroots-git, és másik 1 perc mire a sway-git is lefordul. Nem egy nagy idő. Igaz nálad XWaylandnek is kell fordulnia hozzá, de az is elég kicsi csomagnak tűnik.
-
Frawly
veterán
De nem azt írtad, hogy Sway-t használsz? Pont a waylandes terminálokról írok, X11-re van egy kazal. Egyébként meg nincs igaza ennek az oldalnak, mert a Termite támogatja a Xorg-ot is, legalábbis én úgy tudom. Nem csak Wayland only, és ezt onnan gondolom, hogy ubyegon kedvenc kopasz youtube-os fószerei közül is használja az egyik Qtile, dwm, xmonad, stb. Xorg-os felületek alatt hiba nélkül.
Az való igaz, hogy GPU gyorsítás nincs a Termite-ban, de elvileg ha Waylandet támogat, onnantól a kompozitornak kell gondoskodnia a GPU gyorsításról, nem az alkalmazásnak.
-
Frawly
veterán
Én Termite-ot használok, annak is van natív Wayland-támogatása, és elég sovány terminál (bár függősége lehetne egy kicsit kevesebb), még vim-módja is van, nálam teljesen bevált, semmi hiányosságba vagy bugba nem futottam bele. Az is igaz, hogy nekem terminállal még sose volt bajom, előtte amiket használtam, azokkal sem volt problémám (Gnome Terminal, lxterminal, Konsole), egyedül az xterm-et nem szeretem, alap konfiggal elég ocsmány, de ha beállítja az ember, az is elmegy. Vagyis van még egy, amit nem annyira szeretek, az st. Az annyira minimalista, hogy semmit nem tud default, még vissza sem lehet benne görgetni.
Sajnos Wayland-képes terminálból még elég kevés van. A kollégától elnézést, félreértettem.
Ezt az Alacrittyt kipróbálnám, de már a fejlesztői oldalon ilyeneket írnak: Wayland support is available, but not everything works as expected.
Így nincs sok bizadalmam benne, hiába GPU gyorsított.
-
Frawly
veterán
válasz
Siriusb
#5654
üzenetére
De minek kell neked Linuxra windowsos telnet/SSH kliens? Ezt meg a Puttyt Windowsra fejlesztik, oda muszáj, mert nincs normális terminál. Linux alól viszont megnyitsz akármilyen terminált, kalapálod be az ssh hostname parancsot és már megy is, nem kell sem Putty, sem Hello Kitty, sem Cucly.
Illeve pont egy másik topikban írtam nemrég, hogy ha megnyomod véletlenül a Ctrl+S-t, akkor olyan, mintha lefagyott volna a terminál, konzol. Próbáld meg Ctrl+Q-t nyomni, hátha megjavult.
-
Frawly
veterán
További példák a windowsos beidegződésekre, amikre pont most volt példa az itteni linuxos topikokban: iTunes használata Linux alatt, linuxos szerverre grafikus felület telepítése, Linux felügyelete TeamViewer-rel (mikor az X is kínálna erre megoldást, meg egy RDP-s natív linuxos progi is). Szóval a jelenség valós, csak nem mindenkinél jön ki egyformán.
De pl. láttam már windowsos usereket Linuxra CCleaner-klónt telepíteni, meg Wine alatt Winamp-ot használni, amikor a natív linuxos Audacious, Qmmp, XMMS-klónok ugyanezt tudnák.
De nem akarok offolni, csak példákat hoztam fel. Nyilván az egésznek nem sok köze van az Arch-hoz, ez disztrófüggetlenül ki tud jönni. Bár akik Archot használnak, azok általában már vannak olyan szinten, hogy ennek kevésbé vannak kitéve.
-
Frawly
veterán
válasz
Shyciii
#5647
üzenetére
A dir működik, az ls parancsra van drótozva, ugyanaz a kettő. De nem erre céloztam, hanem arra, nem is érzed, hogy bizonyos megszokásaid Windowsról vannak. Nyilván idővel egyre kevesebb lesz. Én is csak akkor vettem észre ezeket, mikor már elhagytam őket, hogy milyen feleslegesek voltak. Szerintem már neked is érezned kell, hogy egy Arch + Openbox mennyire más ahhoz képest, mint amikor elkezdtél linuxozni. De mikor még nekikezdtél, akkor nem tudtad, hogy lesz még fejlődés, windowsmentesebb gondolkodásmód később, de lett.
Vannak, akiknek többet árt a Windows. Pl. nem egy kezdő akar Linuxon weboldalakról binárist telepíteni a tárolók helyett, vírusirtót meg tűzfalat akarnak feltenni Linuxra is, meg WinRar-t, Total Commandert használnak Wine alatt. Minden jogosultságot chmod 777-tel oldanak meg, lehetőleg az egész partíción. Mindent jelszó nélkül akarnak használni, rendszergazdaként és hasonlók. Nyilván ők nem érzik, hogy ezek windowsos berögződések, de valójában azok.
-
Frawly
veterán
válasz
Shyciii
#5645
üzenetére
Jó, hát aki azt sem tudja, hogy mi az az egér meg partíció, az valóban nehezebben fog beleszokni a Linuxba is. De! Megfigyelésem szerint a windowsos előélet még hátráltat is Linuxnál, mert próbálja a kedves user a windowsos szokásokat, berögződéseket átültetni Linuxra, amiről le kell őket szoktatni, ezt még én is tapasztaltam magamon anno egy bizonyos szinten.
Láttam olyan öregeket, akiknek az unoka tette fel az Ubuntut, Mintet, stb., és egész jól kezelték, de nem azért, mert ELTE progmatot végeztek még anno 1936-ban, hanem nem volt még előzetes windowsos tudásuk, ami összezavarta volna őket, nem hasonlítgatták össze lépten-nyomon a kettőt. Megmutatták nekik, hogy mikor milyen ikonra kell kattintani és könnyedén elboldogultak vele, persze csak alap felhasználói szinten, böngészés, Skype, netrádió hallgatása, stb.. Semmi ilyen haladóbb szintű dolog, mint terminálban ügyködés, rendszerfrissítés, konfigfájl szerkesztése. Sőt, még arcukba nyíló popup szemetet és magától felmászó toolbar-rengeteget sem kaptak, meg Candy Crusht villogó csempékkel.
Az egészből azt akarom kihozni, hogy mindenkinek az a könnyű, amit elsőre megszokott. Épp ez a trükkje a MS-nak, mindenkit rászoktat a Windowsra, szinte mindenki azt szokja meg, azt ismeri meg elsőnek, és utána minden sz4rn4k fog tűnni, ami nem Windows, nem pont úgy működik, stb.. A fejlesztőket is lepénzelte Redmond, hogy fontos üzleti, kreatív, mérnöki programcsomagokat, AAA-s/exkluzív csak Windowsra (vagy Xboxra) hozzanak ki (esetleg Mac-re, mert az a MS-nak nem versenytárs a speciális ökoszisztéma miatt).
-
Frawly
veterán
válasz
Shyciii
#5642
üzenetére
Tapasztalatom szerint a windowsos előélet nem sokat jelent Linuxban. Max. tudod mi az a partíció, kötegelt fájl, jogosultságok, konfigfájl (Windows alatt .ini-k) és ennyi. A többit úgyis elölről kell tanulni. Ezt is szeretem a Linuxban, hogy teljesen különbözik a windowsos világtól, nem csak koppintása annak.
-
Frawly
veterán
válasz
Shyciii
#5636
üzenetére
Egyes alkalmazásoknak kellhet a dbus. Igaz én sem használok már ilyet, de régebben pl. a redshift-gtk, Skype ilyen volt, meg volt még valami másik grafikus progi, aminek nem emlékszek a nevére, talán valami színprofilt vagy mit lehetett vele szerkeszteni. Ezeket ha elindítod és nem tudnak a d-bus demonhoz kapcsolódni, akkor leállnak d-bus error: cannot open socket apja kaszá't möhöhő hibaüzenettel, vagy ha nem is állnak le, de kiköpik ezt a sort hibakimenetbe, és nem működnek teljes funkcionalitással.
Nem is a kedved akartam elvenni, csak megjegyeztem, hogy a full extrás, kezdőket mindenben kiszolgáló disztrók, DE-k mögött oltári nagy munka van, mire mindent beletesznek, összecsiszolnak, hogy minden menjen pöccre, minden működjön mindennel,és komplett legyen az egész ökoszisztéma. Közben meg a kezdők azt hiszik, hogy ez természetes, csak fel kell rakni „Az” Ubuntut vagy „A” Mintet, vagy „A” KDE-t, és az már gyárilag ilyen, csak fejlesztőknek csak le kell szüretelniük a bokorról, és mehet is az .iso/.deb fájlba forrón és gőzölgőn, és ez a Linux ilyen, hogy felteszed, aztán minden megy, mint Windowson, grafikus Update, Steam, Wine, szkenner, Candy Crush, Photoshop, MS Office, spéci BT-s billentyűzet drivere, mindezt tökéletes magyarsággal.
Emlékszek anno uby kollégának is természetes volt, hogy a mesa csomag meg a wifi/cpu mikrokód, stb. firmware-ek ott vannak minden disztrón, míg egyszer csak valami Arch-klónon kellett észrevegye kellemetlen meglepetésként, hogy ezek a dolgok nem olyan mindenhol magától értetődően jelen lévő alapok, mint azt ő korábban naivan gondolta. Persze én is ezt hittem kezdőbb koromban. Igazából nekem Archon ezt volt eleinte nehéz megszokni, nem is a telepítési procedúrát. Mindenhez ki kellett tapasztalni, hogy milyen csomagot kell feltenni, hogy kell konfigolni, milyen hardverekhez milyen driver és beállítás kell, milyen systemd service-eket kell engedélyezni. De megéri vele szenvedni, később egyfajta szabadságot ad, és nem lesz az ember mindenféle csoda-full-extrás disztró kövi LTS kiadására szorulva, ahol megáll az élet, ha nem megy valami, és megy a vergődés downgrade-re, meg instabil, meg bla-bla.
Persze ez Archon sem feltétlenül nehéz, ha pl. full extrás DE-t tesz fel valaki, mert csak felteszi a plasma, gnome, xfce metacsomagot, abban benne van minden, kompozitor, tálca, dbus, login manager, anyja kínja, húzza magával kompletten a full mesa, Xorg, pulseaudio, stb. csomagokat függőségi fába, és nem kell kinyomozni mihez mi kell. De ahogy valami kisebb WM-et tesz fel az ember, IceWM, Openbox, i3wm, vagy hasonló, akkor ezek a dolgok nagy hirtelenséggel nem lesznek adottak, nem kerül fel minden, már kapásból azon el kell kezdeni kínlódni, hogy a telepített WM nem fog elindulni magától, mert boot után csak egy szöveges login konzol fogad, és mennek az emberek a fórumra sírni, hogy jajj, instabilazarch, rohadtrolling, nemmegy, micsinájjak, bezzeg a 2099-ig támogatott Zubbonytu Eltées Mínusz 3 pont 04 köbgyök kettőn alapból ment.
Ez Gentoo-n még annyival van súlyosbítva, hogy ott a csomagot is neked kell lefordítanod, meg systemd sincs alapból, az init-et is az embernek magának kell összehegesztenie, stb..
-
Frawly
veterán
válasz
Shyciii
#5634
üzenetére
Ja, ha Xfce-panelt használsz, akkor nem kell autostartba tenni a clipmant.
Ez van, ha WM-et használsz. Mindenről neked kell gondoskodni, kukáról, panelról, asztalikonokról, háttérképről, alkalmazásindóról/menüről, vágólapkezelőről, automountról, d-bus kezelésről, speciális laptopbillentyűk működéséről, hangerő és Wi-Fi appletről, energiatakarékossági beállításokról, kompozitorról, stb.. A kezdőknek való DE-s disztrókban ez már mind kulcsrakészen ott van, kényelmi okokból, hogy a kezdőnek ne azzal kezdődjön a linuxos pályafutása, hogy nem működik ez, nem működik amaz, nem tudja mit kell felrakni, hogyan, és csak vergődik, meg az lesz, hogy XxaralinuxX. De aki haladóbb, és ilyen Arch plusz minimalista WM-et használ, annak számolnia kell, hogy nem csak egy pacman -S openbox-ból áll a telepítés, mert csak egy szürke háttér meg a jobb egérgombos menü fogja fogadni, de azon kívül semmi nem lesz.
Az Eltées Elemérek ezt nem érthetik 
Új hozzászólás Aktív témák
Hirdetés
- Trollok komolyan
- CPU léghűtés kibeszélő
- PlayStation 1 / 2
- Milyen légkondit a lakásba?
- EA Sports WRC '23
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- AMD GPU-k jövője - amit tudni vélünk
- Poco X6 Pro - ötös alá
- Okosóra és okoskiegészítő topik
- További aktív témák...
- 27%-OS ÁFÁS SZÁMLA I Jogtiszta Microsoft digitális és fizikai termékek I DIGITALKEYZ.COM
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- Csere-Beszámítás! RTX Számítógép játékra! R5 5600X / RTX 3080 / 32GB DDR4 / 1TB SSD
- AKCIÓ! MSI B365M i5 8600 16GB DDR4 512GB SSD RX 5700XT 8GB CM MASTERBOX Q300L Zalman 600W
- Apple iPhone X, 256GB, Kártyafüggetlen
- Csere-Beszámítás! Olcsó Számítógép PC Akár játékra! Intel X5650 / GTX 1650 / 24GB / 240SSD+ 500HDD
- Olcsó Laptop! Dell Latitude 7280. I5 7300U / 8GB DDR4 / 256GB SSD
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest