Fórumok
Üdv Arch-osok.
A elmúlt hónapokban csak KVM guest-en használtam Arch-ot (több más mellett is https://hup.hu/node/187118) de elsődlegesen ezen teszteltem amit az Ubuntu 24.04 host-on fejlesztek. Azt kell hogy mondjam, sebességben és memóriában is verhetetlen, még virtuális környezetben is gyorsabb a host-nál. Egyedül az Alpine veszi fel vele a versenyt, de azt nem (még).
Mielőtt áttérek Arch-ra lenne pár kérdésem.
- Látom van LTS kernel, de az Stable ág mennyire összeomlás mentes?
- Csak Wayland-et vagyok hajlandó használni, ez szokott problémát okozni?
- Hányszor fordul elő hogy egy frissítés és esetleges boot után nincs GUI?
- Milyen buktatókba lehet belefutni ami bosszantó?
Nem mintha bármikor is összeomlott volna vagy baja lett volna a virtuális gépen, szinte nonstop fut, mert lenyűgözőnek tartom amit produkál.
Hozzászólások
Alpine még... itt nem fejelzted be a mondatot, de sejtem, hogy még nem próbáltad. Alpine annyira kompakt, hogy (épp tegnap játszottam vele) szinte semmi nincs az aarch64 csomagkezelőjében: mc, htop sem található. Nálam emiatt alpine csak az extra vékony nodejs-es docker image-ek alapja tud lenni, önálló disztróra nem használható. Talán, ha saját cpp alkalmazéást fordítasz rajta, majd bodsz mindent és tényleg egy "mikrokernel" kell csak rá.
Rosszul sejted, van Alpine virtuális gépem (https://hup.hu/node/187118), használom is tesztelésre, mert gyors. Piszok gyors.
Nem elfogultságból mondom hanem tapasztalatból, de az Arch gyorsabb. GUI tesztelésnél ez nekem fontos. De az Alpine 1 másodperc lemaradással ott van a második helyen. De ez mind KVM Guest.
Desktopnak nem szeretném az Alpine distro-t.
az Alpine eleg jol muzsikal sima desktopkent is, meg a plasma6 is veszett gyors rajta (https://wiki.alpinelinux.org/wiki/KDE). Mindennel gyorsabb :D. Vannak persze gondok olyan progikkal amik glibc-t igenyelnek, de arra ott a gcompat. Szoval megyen ott minden is.
Persze ettol meg a docker image alapnak nagyon jo. Bar en inkabb megyek a Buildroot-tal ha igazan kicsi es kompact image kell.
Alapvetően nem is arra készült az Alpine, hogy az legyen a fő disztród desktopon, hanem pont arra, amit másodiknak említesz, hogy extra vékony konténeralap legyen. Ennek ellenére azzal egyetértek, hogy mc, htop, vim/nvim, git, fzf, stb. azok annyira alap dolgok, hogy illene ott lennie a tárolókban, még a legminimalistább disztrón is, ilyen alapok hiányára nincs mentség.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Hat ize, ott is vannak
Szoval mi nincs a hol????
Akkor nem tudom, én hittem a kollégának, hogy nincs benne. Ezek szerint benne van, nem frissítette a repókat, csomaglistát, vagy rossz mirrort használ, ami rég nem frissült.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
ez alapjan arm64-en nincs...
MacOS utm-ben probaltam ki.
ja bocs, akkor beneztem, az aarch64 kitetelt nem vettem eszre/elsiklottam felette
Annyira stabol az Arch, hogy egesz kis jo kereskedelmi rendszerek epulnek ra, mint pl. a SteamOS. De tenyleg az Archhoz kepest az Ubuntu bukdacsolo kisbaba, a Fedora meg a terdet lenyuzo alsotagozatos. :D
Nem nagyon fordul elo hogy osszeomlik csak ugy, ahhoz eleg jol szet kell cseszni direktben, mindenfele AUR csomagokkal Laoszbol meg Vietnambol :D
Minden kerdesedre ott a valasz a a vilag legjobb wikijeben az archwiki-ben. Mikor meg Ubuntut hasznaltam is legtobbszor az archwiki segitett megoldani a probelmakat, meg megerteni mi mitol megy :D
ahogy fennebb már írták: az archwiki tényleg komoly dokumentáció és nem csak archlinuxra...
néhány + dolog:
- a pacman nagyságrenddel gyorsabb, mint bármelyik másik package manager: dpkg, rpm...
- pl. nincs az a szívás, hogy nem tudod, hogy az exe most a /bin-ben, a /usr/bin-ben, a /usr/sbin-ben... vagy hol a túróban van...
- nincs az a "dependency hell", hogy felraksz egy smartmontools-t és ehhez felrak egy mailszervert is 🤦♂️
- nem matatnak annyira bele a vendor munkájába, nem szedik szét, nem patchelik agyon, stb. nincs külön az app, a lib és a dev package: felraktad a qrencode-ot és ott van minden
néhány - dolog:
- amikor az arch kernelt vált, akkor általában hamar behozzák a legújabb kernelt... amivel lehet szívni... és nem sok esélyed van a kernelek között váltogatni, én ezért használok manjaro-t egy ideje: az nem kényszerít rá a kernelváltásra, több kernel van, vannak bináris modulok: zfs, virtualbox...
- igen, néha megtörténik, hogy valami gixer van upgrade után (az, hogy ne legyen GUI az azért tényleg elég ritka), de ezeket meg lehet oldani... pl. én szoktam snapshotolni upgrade előtt
mindjárt jön hajbazer és még egy páran és elmagyarázzák neked, hogy miért szar a wayland 🤭 szerintem korrektül működik, nekem a plasma azzal megy
Nem kell a legujabb kernelt hasznalni: https://wiki.archlinux.org/title/Kernel `linux-lts` csomag.
Teljesen jol mukodik.
van, amikor új kernel kell...
a 6.6-os kernel az több mint egy éves. ha új a hardver, kellhet az újabb kernel. az új kernel meg nem biztos, hogy stabil...
Ha meg valaki nagyon paranoias illetve szukseges mindenkeppen minden update-nel snapshotolni, akkor arra rengeteg project szuletett mar (https://wiki.archlinux.org/title/Snapper#Tips_and_tricks), hogy mondjuk egy pacman hook csinal egy brtfs/zfs/whatever snapshotot meg akar egy grub configot is a snapshotra, es maris bootolhato egy korabbi meg jol mukodo arch (mondjuk ez nem arch specifikus, de jo hogy itt szepen le is irjak a wiki-ben :D)
Valamikor, a gentoo wiki-je volt az etalon. Most az arch-é az.
Már egy jó ideje.
Jól leírta micsa, csak szubjektív kiegészítésként:
- Én LTS kernellel használom, így kicsit lassabban jön be az újabb kernel, stabilitási gond nem volt eddig
- Egy pár éve Sway-re tértem át Xfce-ről, de nekem így is jól megy, ritkán kell reszelni rajta
- A telepítőjéből könnyű összerakni egy live pendrive-ot segédeszköznek, önállóan fut, frissíthető, az aktuális rendszer telepíthető róla bárhová
Dell Optiplex 3060 Micro, Arch Linux & Sway
A Wayland maga jól működik - általában -, de nagyon sok alkalamazás még nem, vagy nem teljesen kompatibilis vele. Azok, amik alap Gtk/Qt cuccot használnak, azok a többségében jól működnek, de ahol valami egyedi "okosság" van a grafikus megjelenítésnél, ott van olyan program, amit csak X11-gyel teszelnek, Waylanddal meg nem, és az X11-Wayland kompatibilitás sok esetben hiányos vagy nem teljes.
Ha munkára kell, és nem ugyanazt a 4-5 alkalmazást használod egész évben, akkor inkább az X11-re szavaznék. Ha belefér, hogy van rá esély, hogy valami nem indul el vagy nem jól működik, akkor használd a Waylandet nyugodtan, komoly általános probléma nincs vele.
(Illetve, ebbe beleszólhat a grafikus kártyád drivere is, ha azt esetleg nem tesztelték Waylanddel, akkor az egy teljesen másik mondat, ennek menj utána mindenképp, ha nincs tesztelve -> X11 inkább)
Ami a "boot után nincs GUI" dolgot illeti, nálam az szokott a sláger lenni, hogy a videókártyám támogatása kikerül az aktuális nvidia drivercsomagból (vagy elrontja az nVidia a frissítést), és AUR-ból kell vadászni hozzá drivert. Ennek van egy olyan kellemetlen mellékhatása, hogy pl a Steam az direktben az nvidia driverre függene, az AUR cucc nem jó neki, így most pl nem tudom felrakni a steamet, mert konfliktus van, majd valahogy meg kell mókolnom az AUR-os drivert, hogy miket provide-oljon, meg milyen függőségek kellenek még hozzá.
De ez ilyen 5 évente előjövő probléma, és csak akkor, ha 3-5 évnél túl is használsz hardvereket.
Maga a PKGBUILD támogatja amúgy a több csomagra szétbontást, és van néhány csomag, amit darabokra szednek (ennek részben méretbeli okai vannak, vagy maga a cucc is moduláris, mint pl a PHP és a beépített extension-ök esete), de a függőségek kezelése elég jól meg van oldva a beépített csomagok esetében. Az AUR kicsit szerencsejáték, a legtöbb csomag azért elég jól meg van csinálva, de vannak ritka szar maintainerek.
Blog | @hron84
via @snq-
Ahogy az elottem szolo is mondta, Manjaro. En is azt hasznalom szerintem mostmar 7 eve, soha nem volt vele olyan gondom, amit ne lehetett volna megoldani kis utanaolvasassal. Nalam is van fent aktualis kernel ( par het kesesben van az Arch-hoz kepest, de szerintem nem gaz ), illetve a legutolso LTS is, mert miert ne.
Apropo Arch + wayland:
https://hup.hu/node/175738
A kollega rendkivul elegedett vele,, es sehol nem lattam,, hogy barmim nemu stabilitasi gondra panaszkodna.
uff
U-dash
> Látom van LTS kernel, de az Stable ág mennyire összeomlás mentes?
Kulonbozo gepeken hasznalom mindkettot, egyikkel sem volt problema. (De nagyon egyszeru setup mindegyik, ext4 lokalis diszken, stb)
> Csak Wayland-et vagyok hajlandó használni, ez szokott problémát okozni?
Az arch maga nem teszi a waylaned elmenyt rosszabba. Sway teljesen jol megy tobb gepen is nekem.
> Hányszor fordul elő hogy egy frissítés és esetleges boot után nincs GUI?
0.
> Milyen buktatókba lehet belefutni ami bosszantó?
Kernel frissites utan nem tudja betolteni az usb modult pl, igy nem tudja mountolni a pendriveot.
reboot es jo.
Ha sokaig nem frissited, elavulnak a helyi kulcsok, es akkor kicsit reszelni kell: https://wiki.archlinux.org/title/Pacman/Package_signing#Resetting_all_t…
Wiki nagyon jo.
Nem kell félned, jó lesz. :)
Mondom ezt úgy, hogy több mint 20* éve kisebb-nagyobb** megszakításokkal archot használok.
* https://hup.hu/comment/99446#comment-99446
**Funtoo, és FreeBSD. (systemd bevezetésekor, kicsit megharagudtam rájuk, de aztán visszatértem)
Az LTS-t használom házi szerveren, nincs vele gond kb 2hetente frissítem néha havonta. Asztali PC-men a linux-zen -t használom. Volt rá példa, hogy frissítés után nem volt GUI. 10 évnél régebben használom az Arch és származékait 2x fordult ez elő.
Buktatók... ha nagyon régóta (2 hónap) nem frissítettél az okoz problémákat. Aztán van hogy megváltozik egy csomag neve, de erre rákérdez és felteszi az új nevűt, legtöbbször jól.
Az LXDM-el van a legkevesebb probléma, a GDM és a KDM-el volt már problémám update után. Volt, hogy a gdm rossznak látta a jelszavam (nem y,z probléma volt).
telepíteni az ArchBang-ot használom a igazi ArchLinux a célom. Asztali PC-n az EndeavourOS és némi farigcsálás.
A Manjaro jó meg szimpi, csak kötött nem lehet annyira szabadon csomagokat installálgatni, hogy megmaradjon Manjaro-nak.
Egyszer volt, hogy a titkosított partícióimat elvesztettem frissítés után. Ez asztali PC-n volt. A házi szervet kb 4 éve telepítettem újra vinyó hiba miatt. A szerveren csak a szükséges csomagok vannak. Se hang, se grafikus felület, minimális csomag mennyiség.
Csak hobbista linux-os vagyok, lehet néha én bénáztam.
kb ennyi.
Ritka frissítés esetén jellemző szopás, hogy a sima upgrade rákérdez egy rakás kulcsra, hogy elfogadod-e, ilyenkor első körben inkább tedd fel a legfrissebb archlinux-keyring csomagot, és utána mehet a teljes frissítés.
A zen kernel milyen? Van érezhető különbség desktopon?
Érzetre semmi. Talán játék (UrbanTerror) közben mintha egyenletesebb lenne a ping.
Eveken keresztul hasznaltam arch-ot ceges gepen openbox es labwc kornyezetekkel, amig nem kellett security compliance miatt valtani. Csereben most a Lubuntu 22.04 -> 24.04 upgrade elhalt, mert keptelen volt a boot particiot osszerakni.
tapasztalatok:
Nyugodtan áttérhetsz rá, minden, amit írtál, az egyik sem gond Arch-on. Persze arra készülj fel, hogy van néhány csomag, szoftver, amiknél ha feltelepíted őket, nincsenek bekonfigurálva, de olyan szinten, hogy konfigfájl sincs, neked kell kézzel létrehozni és megszerkeszteni, vagy a /usr alatt létező példakonfigot átmozgatni a helyére, és abba beleszerkeszteni. Ez nem Ubuntu, meg Debian, hogy előre konfigolva fogják a kezed. Ezek egy részét az archinstall megoldja neked, de van, amit neked kell megcsinálni. Nem nehéz egyébként, csak néha figyelmesen el kell olvasni az Arch Wiki vonatkozó cikkét.
Szerk.: az is nagyon gyakori, hogy felteszel egy csomagot, amihez tartozik egy systemd service, de ez alapból nem engedélyeződik automatikus indulásra, neked kell systemctl-lel engedélyezni. Más disztrókon ez általában automatikusan jön a csomag telepítésével, Arch-on nem.
A Wayland nem probléma, grafikus felület sem szokott eltörni, legalábbis semmivel nem gyakoribb, mint más, akár LTS disztrókon. Az, hogy milyen nehézségekbe ütközöl, az attól függ, hogy milyen csomagokat használsz, milyen géped van, milyen hardverelemekkel, a GPU NVidia-e, ha igen, az is nagyon számít, hogy hányas generáció.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
amugy mennyire toljak fullba a kretent systemd ugyileg? ott is minden is az csinal (dns, time, dhcp stb) vagy csak az init rendszer az?
Annyira hogy barmit atallithatsz ra ha akarod. Hasznalhatod pl a GRUB helyett a systemd-bootd-t ha akarod, vagy a resolvectl-t a nevfeloldasra, stb stb. Mint minden mas disztorban amiben bent van. A kulonbseg annhyi hogy itt a wikiben vegig fogjak a kezed hogy hogyan allitsd be vagy allitsd vissza
Nem annyira. A systemd kötelező, de nem mindenre, journalra, ntp-re, dns-re, bootra, cron-ra, stb. telepíthetsz saját megoldást, nem kell azokra a systemd-t használnod. a homed, oomkiller, stb. sincs bekapcsolva alapállásban. A systemd is csak azért kötelező, mert nem akarnak széllel szemben hugyozni a disztrófenntartók, mert sok csomag erre dependel, anélkül nem működne. Akinek systemd-mentes Arch-ra van szüksége, annak az Artix-ot szokták ajánlani, esetleg alternatívaként a Void-ot.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
mint init rendszer nincs (annyira) bajom a systemd-vel, csak manapsag mar mindent is az akar csinalni, olyanokat is amihez qrvara semmi koze...
Elméletileg a systemd egy nagy esernyőprojekt, több részprojekt van benne, és azoknak a használata nem kötelező, nem is muszáj belefordítani a disztróba. Csak a szűk értelemben vett init része is működik egymagában, úgy, hogy minden más részére használsz nem-systemd-s megoldást.
Az egy megint más dolog, hogy a nagy, mainstream, felhasználóbarát asztali disztrók általában minden részét használják, ha már van, mert ez a legszabványosabb megoldás most, a normik ezt várják el, ezekre épül a legtöbb függőség. Egy kivételt szoktak tenni, és systemd-boot helyett általában GRUB2-őt használnak, mert az még több mindent támogat (pl. egzotikus fájlrendszerekről, snapshot-okról, RAID-ről, stb. bootolás). Meg igazából a systemd-boot se csak systemd-vel megy, lehet anélkül is használni. Igazából semmi köze a systemd-hez, ez egy korábban gummiboot néven létezett minimalista megoldás, csak beemelték az esernyőprojektbe, és ennek a keretében a systemd-sek gondozzák, de nem függősége a systemd, önállóan is használható.
Én nagy híve is vagyok a systemd-boot-nak, mert minimalista megoldás, kis komplexitású, lényegében az EFI partícióra csak 3 fájl kell neki,
/boot/EFI/systemd/systemd-bootx64.efi
/boot/loader/loader.conf
/boot/loader/entries/whatever.conf
Ezek közül az első fájl egy 105 KB-os szösszenet, és lényegében sose frissül, a másik két conf fájl meg egy nagyon egyszerű szintaxisú valami, triviális, pár sor szerkeszteni, és erről is levan a gond egy életre, frissítésekkor se hányódik össze, meg nem fossa össze magát, mint a GRUB szokta, mivel annyira egyszerű, hogy nincs mi rajta eltörjön. Az loader-be mehet még több conf fájl, ha több rendszert vagy többféle kernelt is akarsz bootoltatni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
nekem az elilo (efi-s lilo) bevalt minimalista bootloadernek, de egy ideje tervezem a bzt-fele loadert is kiprobalni
Az a baj, hogy a lilo-nak az EFI-s változata is elég korlátozott állítólag, még nem próbáltam, illetve a bzt-féléről olvastam a topikjában, de még nem jutottam oda, hogy kipróbáljam.
Egyébként van egy még minimalistább bootmódszer, mikor az UEFI közvetlenül a kernelt bootoltatja, kihagyva mindenféle köztes bootmanagert, ez is működhet, de csak titkosítatlan, alap kernellel támogatott fájlrendszerű meghajtón, és van egy olyan hátránya, ha bootparamétereket kell szerkeszteni, az csak kevés UEFI-ben van implementálva, vagy magában az UEFI menüben, vagy az UEFI konzolban, de a legtöbb alaplap, gép nem rendelkezik ilyen funkcióval. Ezt Linuxnál EFI stub bootnak hívják, Gentoo-nál használtam párszor, Arch-nál is kéne működjön, de ott az initramfs keresztbe tesz, és nem sikerült működésre bírnom. Elvileg minden disztrón lehetséges beüzemelni, ha olyan a kernel is, hogy bele van fordítva ez az EFI stub támogatás. A legtöbb generic kernelbe ez bele van forgatva alapból, azt hiszem, hogy a defconfig is behúzza.
A systemd boot előnye, hogy nem sokkal bonyolultabb, extra 3 fájl, de mindenhol működik, még systemd-mentes disztrón is be lehet üzemelni, egy generic bináris odamásolásával az EFI partícióra, meg 2 extra plain text conf fájlt odamentve, szerkesztve simán működik.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
A csomagkezelő ízlés kérdése, nekem a pacman annyira nem jött be, mint a dnf vagy az apt.
Meglehetősen gyakran voltak update-ek, volt vele problémám (de Fedora alatt is volt 1-2 alkalommal frissítés után), ami leverte a biztosítékot: eltűnt egyszer két napra az egérkurzor FF alatt. :D
Egyébként nem éreztem lényegi különbséget, a Debian, Fedora, és az Arch linux is egyformán jól működik. (gondolom ilyen az Ubuntu, és a többi jó disztribúció is)
Emlékeim szerint nem klikkelgetős volt a telepítés, hanem van egy jó leírás, amit szépen tudsz követni. - de ebben már nem vagyok biztos.
Az archwiki tényleg jó, sokszor más distro esetén is ott lyukadok ki, és le van rendesen írva, hogy mi hogy működik. Az egyik legjobb linux doksi.
Nem, nem ízlés kérdése. A pacman pokoli gyors, ha SSD-n futtatod, és be van kapcsolva a párhuzamos csomagletöltés is. Egyébként csak fele részben a pacman érdeme, a gyorsaság másik oka, hogy az Arch-csomagok zstd-vel vannak tömörítve, és annak pokoli gyors a kitömörítése. A betömörítése is, de a kitömörítése végképp, pedig szintetikus benchmarkokban az lz4 beelőzi, de a gyakorlatban nálam minden esetben az zstd gyorsabb.
A dnf nekem elég lassúnak tűnik, az apt az kb. közepes sebességű.
Az Arch Wiki tényleg a legjobb, de néha érdemes a Gentoo Wiki-t is olvasgatni, akkor is, ha nem Gentoo-t használsz, van benne sokszor hasznos adalék. Néha a Debian Wiki-ben is van.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
A dnf5 amúgy érzés szerint sokkal gyorsabb lett az új fedora-ban (mint az előző dnf).
Gentoo wiki: köszi, megnézem.
A csomagkezelő sebessége miért érdekes?
Én azon szocializálódtam, hogy desktopon a gép frissíti éjjel, amit kell, szerveren pedig az Ansible és társai elintézik, nincs user interakció, az Ansible meg ráér.
Számít. Ha valami nincs fent nem zökkent ki a munkamenetből a telepítés, egy paranccsal és egy sóhajjal több, de ennyi. Nincs idő másra.
Mikor áttértem Ubunturól nem akartam elhinni ezt a sebességet.
Négy éve használok Arch-alapú disztrót. Nálam a Manjaro fut, a DE az Cinnamon. Csak néhány véletleszerűen előszedett probléma a sajátjaimból.
Error: file `/boot/vmlinuz-6.9-x86_64’ not found
How to Use NVIDIA graphics only with NVIDIA Optimus?
After last update X wont start
Eléggé esetleges témák, de talán ízelítőnek megfelelőek. Fentiek, és még jónéhány más probléma sem tántorított el, maradtam a Manjaro mellett.
Szerintem jó, a support (a fórum közössége) megértő, barátságos, segítőkész. Legtöbbször eredményes.
Még nincs aláírásom.
Ez szerintem a 6.11 -re váltásnál is jelen volt. Mikor először előfordult visszaraktam az lts kernelt is. Ilyenkor arra bootolok és egy update-grub meg oldja. (manjaro)
Nincs gond vele. Nálam LTS meg normál is telepítve, mert volt egy fránya USB WiFi stick-em, ennek a drivere egy idő után többé nem fordult a normál kernellel. Azóta lett egy másik stick, az LTS kernel most is fenn van backupként, de régóta nem használom.
Passz. Xorg van XFCE meg Gnome. Utóbbit ritkán használom, pár órát rászántam és testre szabtam az XFCE-t. Megoldatlan gond XFCE esetében: sehogy sem tudom rávenni, hogy a screensavert kapcsolja le ha Firefoxban fullscreen video fut.
Nem emlékszem hogy ilyesmi előfordult volna. Ha volt akkor saját hibából, mintha rémlene, egyszer volt valami, ilyenkor felmész az oldalra, ott megtalálod a megoldást.
Történt meg, hogy egy frissítés szétbarmolt ezt-azt vagy a csomag bugos volt. Ilyenkor kb. 1-2 nap és ki van javítva.
Minden hulla a Mount Everesten valamikor egy nagyon motivált ember volt.
Köszönöm mindenkinek. Átállás megtörtént.
Voltak gondok.
1. A linux, stabil ág kernel, hát az fagy össze vissza, boot, reboot, login, logout, ahol lehet a fagyi tényleg hideg. De a linux-lts megoldotta. Atom stabilnak tűnik. Amúgy is az volt a vágyam hogy legyen egy stabil kernel, és egy GUI ami friss mindig.
2. Visual Studio Code. Ez a munkaeszközöm. Hát a "pacman -S code" egy okádék szar. Nem elég hogy a .vscode könyvtárat megváltoztatták (paramétermentes indításnál), de a dizájn fájlokba is belenyúltak a kurvák, és nem az alapértelmezett. Megoldottam a code*.tar.gz használatával. Amúgy is minden projektet külön --extensions-dir és --user-data-dir paraméterrel indítok hogy elkülönítsem. Mindegy, de a száradjon le f*.
3. Viber az nincs, csak a yayjjos. Most a flatpak-os verziót használom.
De most a szépsége:
Nem tudom mit csinálnak akik csinálják, de hasít. Tényleg. Össze se lehet hasonlítani az Ubuntuval. Az alkalmazások sokkal gyorsabban indulnak, pedig az Ubi is gyors volt. Király.
Kérdés:
ez a yay mennyire megbízható?
A yay érdekessége számomra az volt, hogy képes volt nvidia driver install/update esetén foglalkozni azzal, hogy melyik verziót akarnám feltenni. És jól csinálta. Nem egy nagy sztori tudom. Akkor viszont nekem jól jött valamiért. Azt hiszem az optimus-manager installlal küzdöttem éppen akkor. Ki tudja hanyadik alkalommal.
Mióta envycontrol-t használok a problémák megszűntek.
Szerk,: Még annyit teszek hozzá, azért a yay-t próbálom elkerülni és a snap-et is vagy mifene a neve.
Még nincs aláírásom.
Én nem használok flatpak -ot csak yay(aur), használd nyugodtan.
- nem ide
Waylandel annyi a gond mint barmi mas disztron, sima kernel is jo, buktatok ugyanazok mint mas disztron
kozel 20 eve telepitettem az archot, kb amikor a gentoo wiki elveszett, azota ugyanazt a telepitest hordozom. Eleinte neha elo fordult hogy egy frissites utan helyre kellett tenni a rendszert de mar sok eve egyszer sem
Arch-ot hasznalok >7 eve. Ket problemam van vele:
Kernel (nem LTS) update utan szukseges a restart, mert a korabbi kernel+libc paros mar csak memoriaban letezik.
Osregi nvidia kartyamnal van valami DRM beallitas ami nalam akadalyozza a megjelenitest. Minden nvidia update utan ki kell torolnom egy fajlt, hogy helyrealljon
Ezekkel egyutt tudok elni, a wiki meg tokeletes forras troubleshootingra. Laptopra, PC-re az eddigi legjobb disztro amit telepitettem. Azota sem telepitettem ujra. Nem hiszem, hogy ezutan visszamennek az ezt megelozo disztrokra. (Gentoo-ra is max morbid kivancsisagbol)
Lambda calculus puts the fun into functional programming
Az ember azt hinné hogy ha Linuxot használ akkor az a sebesség és élmény csúcsa. De nem. Nem gondoltam volna hogy Linux és Linux között ilyen különbség lehet.
Néha-néha bootolom az Ubuntut, és olyan mint egy sétabotos nagypapa az Arch után. Ez sokkoló számomra, mert azt hittem az a gyors.
Elkezdtem használni a yay-t:
Még egy kis ömlengés, de a KVM is csúcsformában van az Ubuntuhoz képest.
Pedig van közöttük sebességbeli különbség. Én ezt reklámoztam is már többször, de az Ubuntu-hívők nem hitték, hogy ekkora a sebességkülönbség, mind bootnál, mind leállásnál, mind csomagok telepítésénél, frissítésénél, néha egyenesen hajmeresztő, ha nem szokott hozzá az ember ehhez a sebességhez, eleinte el sem hiszi. Fedorához képest már nem ekkora a különbség, de még ahhoz képest is van valamennyi, főleg csomagkezelésnél. Ha a rendszert minimalizálod meg sovány ablakkezelőt használsz, a sebesség tovább fokozható. A legdurvább, mikor az ember hozzászokik egy ilyen gyors rendszerhez, és vissza kell ülnie lomha Windows elé, amin minden sokkal komótosabb (csúcs gépen, SSD-vel is), kínszenvedésnek tűnik.
yay-nél még javaslom, hogy a /etc/makepkg.conf-ban állítsd be a fordítási FLAG változóknál, hogy minimum -O2-re optimalizáljon, és használja az összes prociszálat. Meg a /etc/pacman.conf-ban, hogy használja a párhuzamos letöltéseket. Ha asztali gép, akkor bekapcsolhatod a performance governort is, kicsit az is gyorsíthat, laptopon viszont nem érdemes, csak feleslegesen öli az aksit, meg idegesítő lesz, hogy a venti süvít miatta állandóan.
Kösz az infót, akkor adok egy új esélyt a far2l-nek, ha nálad fordul Arch-on, akkor nálam is kéne, hogy működjön. Szerk.: valóban lefordult a far2l-git AUR csomag. Régebben szerintem egy másik AUR csomag volt, vagy kézzel húztam be a forráskódot, azért nem fordult le. Nem rossz ez a FAR, egész elszoktam tőle. Vannak előnyei és hátrányai is a jelenleg használt Vifm-hez, mc-hez képest. Előnyök: tud brief nézetet, mikor 3 oszlopba ömleszti a fájlokat (ebben egyedülálló a terminálos fájlkezelők között), illetve tud kiterjesztés szerint is rendezni (ez az mc is tudja, de a Vifm nem). Hátrány: nem tudja a lynx-féle kurzorbillentyűkkel való mappákba ki/belépést (mint az mc), sem a vi/vim billentyűket (mint a Vifm, lf, Ranger, nnn, stb.).
Amivel küzdök még egy ideje, hogy nem fordulnak le, az a DOS Navigator meg az Open Cubic Player.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
köszi.
Default configom volt eddig. Az -O2 az meg volt viszont a MAKEFLAGS="-j2" -t javítottam MAKEFLAGS="-j$(nproc)" -ra, a pacman configban is ki volt kommentelve a ParallelDownloads
Sajnos a DOS Navigator (dn2l) nem fordul le, de érthető. Egy DOS-os kókányolás, amit egy ősrégi Virtual Pascal fordítóval akarna lefordítani, ami egy linuxos binárist állít elő, de 32 bites PE .exe formában, amit egy másik tool átkonvertál linuxos ELF-fé. Eleve nem is fordul le, követve a git repó lépéseit, nem tetszik a fordítónak a kód, valami 73-as hibával áll le, Implementation részt keresne, ami nincs. Így szerintem én hagyom is, nem hiányzik nekem ez a 32 bites DOS-os kókányolás, ahogy nézem, még UTF-8-at se tud, nem nagyon tudnám mire használni. Ez így nem elérhető forráskód, hanem egy nagy szar sajnos. Olyan, mintha nem is lenne.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
de ezek az mc, far, dosnavigator szarok ezek minek amugy? Ha valami ilyen fancy szart akar az ember akkor arra ott a grafikus felulet file managerei, ha meg gyors es hatekony akar lenni arra meg millio jobb filemanager van, akar a neovim neotree is jobb. De van meg Ranger, Superfile, n3, lfm, stb
Azt talán érdemes megemlíteni, hogy a pacman konfigurációs fájlt csak akkor kell piszkálni ha CLI-ban történik a csomagkezelés. A GUI-s csomagkezelő alapból négy szálon tölt le, és beállítható egy másik szám is.
Még nincs aláírásom.
a pamac-ot felraktam, modern, szimpi. mem olyan mint az octopi, ami a windows 3-ra emlékeztetett, gyorsan töröltem is :-)
Ami nálam elő szokott jönni:
az /etc/pacman.d/mirrorlist -et rendszeresen szerkesztenem kell, mert felülírja és csak azt veszem észre, hogy nagyon lassú a csomagok letöltése.
(manjaro)
Ez egy Manjaro-fogás. Vanilla Arch-on ezt nem csinálja, ott az új mirrorlistet a /etc/-be mirrorlist.pacnew névet teszi be, az eredetit nem bántja, ha kell az új mirrorlist, neked kell kézileg átnevezni, de a rendszer nem kényszeríti rád automatice.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Reflector, ha lassú.
Minden hulla a Mount Everesten valamikor egy nagyon motivált ember volt.