- Apple iPhone 16 Pro - rutinvizsga
- Nem növel telepméretet a Galaxy S26 Ultra
- One mobilszolgáltatások
- Motorola Edge 60 és Edge 60 Pro - és a vas?
- Amazfit Active 2 NFC - jó kör
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Sony Xperia 1 V - kizárólag igényeseknek
- Magisk
- iOS alkalmazások
- Samsung Galaxy A56 - megbízható középszerűség
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
Frawly
veterán
Lehet lemezképet klónozni, de akár tar-ral is át lehet vinni az új rendszert. Vagy rsynccel. Vagy CloneZillával. Sokféle módja van. Én legutóbb tar-ral csináltam:
cd /
tar -cvpzf --one-file-system /cel/backup.tar.gzKicsomagolni ezzel csomagoltam ki, ha jól emlékszek:
tar -xf backup.tar.gz -C /Ha Tar-ral vagy rsync-kel csinálod, akkor viszont partíció UUID-t módosítani kell a bootmanagerben, /etc/fstab-ban.
EUFI boot elvileg lehetséges EFI partíció nélkül is, de nem tudom hogyan. Kék luficet kolléga (colomb2) szokta propagálni, de nem értettem hogy működik, mert én elvi szinten sem tartom lehetségesnek. Valahogy ő mégis használ ilyen megoldást Gentoo alatt.
-
Frawly
veterán
válasz
ubyegon2
#5166
üzenetére
Azért mert a cron-ba a haladóbbak is néha beleszerkesztenek, aztán csak csodálkoznak, hogy valami jogosultsága vagy egyéb hiba miatt nem fut le a cucc, vagy nem normálisan, vagy nem akkor, mikor kéne neki. Az fstrim system service-t meg bekapcsolod, és megy, mindenféle kínlódás meg paraméterezés nélkül, egyszerűen nem lehet elrontani.
-
Frawly
veterán
Valóban pontatlanul fejeztem ki magam. Samu 8XX sorozaton is megy a discard TRIM, de mivel a kernel nem alkalmaz queue-t, azért azonnal végrehajtódik, ami teljesítményproblémákhoz vezethet. Ezért nem érdemes használni. Viszont abban igazad lehet, hogy ettől még lehet használni, és érdemes is lehet olyankor, ha pl. FAT32-es partíciót akarsz TRIM-elni, azt jelenleg az fstrim még nem támogatja.
Az fstrim-ről meg azért gondolom, hogy hatékonyabb, mint a discard TRIM, mert hiába discardol a kernel, lefuttatva az fstrim-et hosszabban végigtrimeli a partíciókat, azaz talál még trimelni valót. Használom mindkettőt MX300-as SSD-n, az nincs a kernelben sem queued TRIM-es tiltólistán.
Júbájgön: a systemd-s fstrim-szolgáltatás használata könnyebb és felhasználó/kezdőbarátabb, mint cron-ba belebarmolni, ami vagy fog menni, vagy nem.
-
Frawly
veterán
válasz
#63718632
#5155
üzenetére
850-es Samuk a kernelben trim-tiltólistán vannak, így mountoláskor a discard paramétert NEM szabad használni. Helyette engedélyezd a fstrim systemd service-t:
sudo systemctl enable fstrim.timer
sudo systemctl enable fstrim.serviceEsetleg ha nem akarsz ezzel bajlódni, akkor az is elég, ha néha napján terminálban lefuttatod a sudo fstrim -a -v parancsot. Attól függ ennek az alkalmazási gyakorisága, hogy mennyire van tele a meghajtó, meg mennyire sűrűn törölgetsz róla. Végül is a systemd service is ezt a parancsot hívja meg előre beállított rendszerességgel.
Hosszú távú tapasztalatom alapján az fstrim-es megoldás amúgy is hatékonyabb TRIM, mint a discard-os. A discardot csak akkor erőltetném, ha nem Samu-ról lenne szó, és mondjuk FAT32-es fájlrendszeren akarsz TRIM-elni, mert azt pl. az fstrim még nem tudja. Nálam egymás mellett megy a kettő Crucial MX300 SSD-ken, azok nincsenek a kernelben tiltólistán sem.
-
Frawly
veterán
Ezért nem jó scriptekkel telepíteni. Franc tudja mi kerül bele, mitől nem fog működni, meg felhány egy csomó olyan csomagot, ami neked nem kell. Ha nincs bonyolító tényező, kész van az EFI partíció, vagy MBR boottal használod, nincs egész lemezes szoftveres titkosítás vagy LVM a háttértáron, ahová telepíted, ext4-et használsz, komplett fullos DE-t teszel fel mindjárt telepítés után pacman-nal, akkor elég könnyű telepíteni.
-
Frawly
veterán
Ezt a spooky tárolót (ez egyfajta külső PPA) az /etc/pacman.conf-ból tudod kiszedni, már ha nincs rá szükség. Ha mégis szükséged lenne rá, akkor nézd meg, hogy igényel-e hitelesítést. Vagy próbáld a pacman -Scc futtatásával a pacman cache-t teljesen kiüríteni, majd a pacman -Syu kiadásával frissítsed a csomagadatbázist, úgy már nem kéne hülyeséget írogatnia.
-
Frawly
veterán
Nem. A 3. pont független a gnome themestől. Ha normálisan működik a lightdm, akkor ne nyúlj hozzá. Érdekességnek összevetheted mi van az új .conf.pacnew fájlban, miben más, mint a te konfigod. Csak figyelmeztet, hogy az új csomagverzióban lévő .conf nem lép életbe automatikusan (nem akarja a te konfigolásodat automatán tönkretenni, felülírni), így ha mégis életbe szeretnéd léptetni, akkor a mostani .conf-ot nevezet át .conf.old-ra, az újat meg .conf.pacnew-ről .conf-ra.
A 2. pont viszont tényleg amiatt volt, hogy nem egyeztél bele a cserébe.
-
Frawly
veterán
Rosszul tetted. A Yes-re kell nyomni. Nálam is előjött, a Y-t megadva neki sikerrel lement a frissítés, mindenféle hiba nélkül. Nem rontottál el semmit, futtasd újra a frissítést, meg fogja kérdezni újra, és most ezúttal egyezz bele a cserébe.
Ezzel a possibly missing firmware for module aic94xx és wd719x figyelmeztetéssel nem kell foglalkozni, ezt mindenkinél kiírja. Még a kezdeti időkben benne hagyták ezt a f4sságot az initramfs-generáló mkinitcpio szkriptben, ezért mióta Arch az Arch, ezt írogatja ki mindenkinek. Majd megszokod, mikor már 1000×-re látod minden kernel/systemd-frissítés után. Nem te vagy az első, akinek szúrja a szemét. Annyira alaptalan és annyira régi dolog, hogy lassan inkább mém lesz már belőle
-
Frawly
veterán
De megszopatott most a Xorg gyerekek. Tegnap még használtam a gépet, de már napok óta nem frissítettem az Archom.
Erre ma kapcsolnám be, erre nem indul a grafikus felület, Start LXDE Login Manager... Stop LXDE Login Manager között cikázik a kernelkimenet, lelőni persze nem tudtam, hiába nyitottam új konzolt, visszavágta elém az TTY1-et. Mondom miafax, arra gondoltam, hogy elromlott az SSD vagy a GPU, mivel frissítés nem törhette el.
Bebootolok USB3-as pendrive-ről eltávolítom az LXDM-et, létrehozom az ~/.xinitrc-t, majd reboot, login, startx, erre az X hibával leáll. Akkor látom a kimenetből, hogy az a baj, hogy tegnap este létrehoztam az egér gyorsítására a /etc/X11/xorg.d.conf/ mappában egy 99-libinput-custom-config.conf fájlt, az Arch Wikiben leírtak szerint, az nem tetszett az X-nek. Hogy a rákban tud ez ennyire működésképtelenné válni egyetlen piszlicsáré .conf fájltól, ami nem is a megjelenítéssel kapcsolatos, csak egy libinputos bejegyzés, aminek legrosszabb esetben is csak annyit kéne okozzon, hogy az egér nem lesz érzékenyebb, meg kapnom kéne egy warningot a logban. Faxt már ezt a 30 éves X konstrukciót, ha valami nem tetszik neki, beszopatja az embert. Siethetnének a Wayland-támogatással, mert ez ultragáz már 2018-ban.
-
Frawly
veterán
Nekem úgy tűnik, hogy az olvtársak annyira vért izzadtak, hogy felcsatolás után sikerült elkeffinteniük a genfstab -U >> /mnt/etc/fstab parancsot, így meg hiába volt minden felcsatolva, nem hozta létre a script a /etc/fstab-ot. A vicc az, hogy a systemd óta ez már nem okoz bootképtelenséget, azért írtam múltkor, hogy csökken az fstab jelentősége, de ha akarod bebootolsz megint az Arch telepítővel, felcsatolod a partíciókat, és kiadod ezt a parancsot. Nincs itt semmi helyrehozhatatlan kár.
-
Frawly
veterán
válasz
ubyegon2
#5118
üzenetére
Pedig csak megszokás kérdése, hogy milyen nyelven használod. Nem kell hozzá magas szintű angol, ilyen File, Open, Print egyszerű dolgokat bárki megért, meg install packages, cannot mount bla-bla, meg file locked, stb. egyszerű kifejezéseket. Ráadásul ha megszokod, akkor úgyis elolvasás nélkül kattintasz a megszokott helyekre.
Én csak annyiból tolom túl, hogy még a területi beállítások sem magyarok, mivel próbálom a magyaros dolgokat minél jobban kizárni, hogy az angol a hétköznapok részévé váljon minél szorosabban, ez segít a nyelvtanulásban. De amíg magyarul használtam a rendszert, addig sem okozott gondot, telepítéskor mindig a legelső kérdés, hogy billentyűzet és nyelvi beállítások, itt lementem mindkét helyen a magyarra, és minden magyarul működött, sőt, mikor először frissítettem csomagkezelővel, grafikus felületen mindig felajánlotta, hogy FF-hoz meg LibreOffice-hoz magyar nyelvi csomagot talált,telepítheti-e, nem kellett semmit i8n-neznem. Igaz ez Mint KDE, Kubuntu alatt volt szokásos. Arch alatt nem tudom, mert azalatt már angolul használtam, de gyanítom Arch alatt is csak annyi, hogy a vconsole.conf-ban a keymapot beállítod (hu), a locale.conf-ban a nyelvet és a kódolást (hu_HU.UTF-8), ez alapján futtatod a locale-gen parancsot, meg timedatectl set-timezone Europe/Budapest, timedatectl set-ntp 1, majd feltolod a KDE Plasma 5 metacsomagját fullosan, végül FF, LibreOffice, de itt kézzel mindjárt mögötte a pacmannak megadod azt a csomagot, amit te is írtál.
Egyedül arra kell még vigyázni Archnál, hogy a Wiki-ben a Quick Installation-nél még valami régi tz-s parancs volt az időzónaválasztásnál, de ezt már nem találom. Az Installation Guide-ban viszont még mindig szimbolikus linkkel dolgozik, ez sem ajánlott, helyette a timedatectl-lel érdemes beállítani, az a korszerű módja.
-
Frawly
veterán
Kizárt dolog, hogy a KDE grafikus felületén ne tudnál magyar billentyűzetet kiválasztani. Valóban valami Generic PC néven fut, de a Hungariannak is ott kell lenni, ezt kell választani (nem a 101 gombosat, meg egyéb baromságokat). Valami 9 hónapja nem KDE-ztem, úgyhogy fejből nem megy, de úgy rémlik, hogy Rendszerbeállítások - Beviteli Eszközök volt a neve a magyarul, de már legutóbb is angolul használtam.
-
Frawly
veterán
válasz
ubyegon2
#5109
üzenetére
Valószínű mindkét csomagnévvel felrakja a magyar nyelvi csomagot FF-hoz. A setxkbmap nem működik KDE5 alatt, két okból is. Először is waylandes, így leszarja barnán és gőzölgőn, hogy te a setxkbmappal mit állítottál be, az Xorg-hoz való utility. Másodszor emlékeim szerint a setxkbmap-os váltás már KDE4 alatt sem ment, mert a KDE már Xorg alatt is magához ragadja a billentyűzet kezelését, hogy csak a saját appletjével tudd állítani, ellenkező esetben kihúznád az applet alól a talajt, hogy ő X kiosztásról tud, te meg beállítasz a háta mögött Y-t. Konzolban a loadkeys hu működik, de csak a konzol bezárásáig. Egyszerűen a nyelvi és területi beállításoknál be kell lőni a magyart, és automatikusan jónak kéne lennie mindenhol, grafikus felületen és konzolban is. Tényleg csak 1-2 program van, amihez magyar nyelvi csomagot külön kell lehúzni, Firefox, LibreOffice az, ami így most kapásból eszembe jut, de lehet van még egy pár.
Egyébként én pont az ilyenek miatt is nem használok már egy ideje lokalizált rendszert, még weboldalakon sem. Egyrészt nem kell ilyen külön csomagletöltésekkel vergődni, meg félig lokalizált bénaságokkal idegesíteni magam. Másrészt az angol nyelvű hibaüzenetekre több megoldást dob ki a Google, meg általában a netes tutoriálok is az adott szoftver angol nyelvű verziójához íródtak, és így könnyebb a leírást követni. Harmadszor ott van, hogy a lokalizálatlan verzió hamarabb kaphat frissítést, anno Firefox Aurorával szoptam, hogy az új magyar főverzió 2-3 nap késéssel jött ki a lokalizálatlan (amerikai angol) verzióhoz képest. Legvégül meg ott van, hogy ha angolul használja az ember, azzal is fejlődik az angolja.
Ezek miatt nálam a locale.conf-ban en_US.UTF-8 van megadva (ha nem lenne, akkor is ez az alapértelmezett), ez alapján fut le a locale-gen, így az összes alkalmazás angolul van. A dokumentumok, fájlnevek mind UTF-8-ban vannak, ezért a magyar karakterek, nyomdai és fonetikai jelek meg minden más jel, szimbólum helyesen megjelenik, meg a billentyűzet logikai kiosztása is magyar (fizikailag brit angol ISO billentyűzetet használok, de nem zavar, mert vakon gépírok 10 ujjal, és nem nézek le, hogy mi van a gombokra írva), és így teljesen tudom használni magyarul a rendszert, annak ellenére, hogy minden angolul van rajta. A területi beállításaim is amerikaiak, ez azt jelenti, Hónap, nap Év a dátumformátum, a hét első napja vasárnap, nem hétfő (! de ez konzolban, terminálban variálható a date parancs paraméterezésével), tizedesvessző helyett tizedespont van, Ft helyett $, cm helyett inch, stb., de akit zavar, a területi beállítást külön átnyomhatja magyarra, ebbe még én is belenyúltam, 24 órás időformátumot adtam meg, mivel az amcsik (a hadsereg kivételével) alapból 12 órás a.m./p.m órát használnak, amit én túl konzervatívnak találok. Dédapáink még előkapták a zsebórát, amin kettőt fordult a mutató, de a modern digitális korban az idő lineárisan telik, nem megy körbe kétszer az óramutató. Engem már az is idegesít, mikor emberek úgy mondják meg az időt, hogy háromnegyed öt lesz három perc múlva, faxért nem lehet normálisan mondani, hogy 4:42. Jó hogy nem már négyzetgyök kettőször koszinusz két pi-iksz integrál alatt, osztva ln(7)-tel, aztmatekozdki hülyegyerek.
Nyelvi téren állítottam még, hogy a hunspell is telepítve legyen, meg a LibreOffice-ban, böngészőkben működjön a magyar helyesírás-ellenőrzés is.
Amire még érdemes figyelni, hogy az idő a gép hardveres órájában UTC-ben legyen tárolva, Linuxon általában alapból így van, Windows alatt registry hack kell hozzá, amit az Arch Wiki ismertet. Dualbootnál figyelni kell, mert Windowsra bootolva elállítódik a helyes idő, a Windows alapból a helyi időt tárolja a gép órájában, ami így oda-vissza állítódik, és az alapján a Linux alatt kijelzett idő is. Illetve, hogy az időzóna jól legyen beállítva, be legyen nyomva a rendszeres NTP szinkronizáció, meg a téli-nyári óraállítgatás is automatikus legyen. Az UTC használata fontos, mert a hardveres óra UTC-s idejét használják a fájlrendszerek is, így ha valaki pl. időzónák között repül át, akkor nem lesz az, hogy az újabb fájl tűnik a régebbinek pár órával, ami bezavarhat az archiváló/mentőprogramoknak.
Az a gyanúm, hogy CheekSee a telepítésnél átugorta a lokalizációs beállításokat, biztos nem tűntek fontosnak, vagy túl sok kiizzadt vér ment a szemébe, amitől nem látta jól a Wiki utasításait
-
Frawly
veterán
válasz
vinibali
#5097
üzenetére
Nem félmegoldás, mert nincs gond vele, de kevés progi, DM, DE, WM támogatja. A többieknek tud XWayland X-et emulálni, de abban igazad van, hogy a Wayland értelme kérdőjeleződik meg, ha csak a szoftverek 1%-a használja, 99%-nak meg emulálni kell X-et, annyi erővel lehet Xorg-ot is használni. Ennek ellenére én is Wayland-párti vagyok.
-
Frawly
veterán
De hát pont ezt írtam én is. Leszedni az xf86-video-intel csomagot. Ahogy én csináltam, az csak annyiból volt más, hogy mikor lekerül a fenti csomag, akkor a pacman törli a 20-intel.conf-ot is, mert tulajdonképpen nincs rá szükség. Nálam továbbra sincs ilyen fájl (sőt, más fájl sem, a vonatkozó mappa üres), és hibátlanul megy a rendszer, a Xorg meg a default beállításait használja ilyenkor, pont azokat, amiket te is írsz. Ezért nem értem, hogy nálad meg annál a másik emberkénél múltkor a Mint topikban miért nem volt kép a csomag eltávolítása után, mikor elvileg nem lenne szabad előfordulnia. Lehet azért, mert szkripttel telepítettél, ő meg Mintet használt, és ezek miatt zavart be valami. Vagy beleszerkesztettél előtte is már a 20-intel.conf fájlba, és erre figyelemmel a pacman nem törölte le, de a paraméterek nem voltak jók a fájlban (hiszen továbbra is az sna-s Intel driverre mutattak a glamour modesetting helyett), és ez működőképtelenséget eredményezett. Az xf86-video-vesa meg nem is értem hogyan kerülhetett fel.
(#5067) ubyegon2: most már tényleg megnézem a hétvégén a Gnome3-at, már kezdi bökni a csőröm. Bár annyi rémlik, hogy volt róla nemrég egy cikk a Phoronixon, hogy Uborkán a Gnome3-hoz nem a Wayland lesz az alapértelmezett, szóval lehet csak opcionálisan waylandes.
-
Frawly
veterán
Most nincs előttem Gnome, és nem tudom ígérni, hogy hétvége előtt lesz időm feltenni. Így a látatlanban: a gnome-shell csomag fent van? Mert kéne lennie benne beépített kompozitornak, az ezer százalék, azt nem tudom a beállításoknál melyik ikonról lehet elérni, nincs most előttem Gnome telepítve.
Egyébként meg nem értem, nálam gondot okozott a Xorg Intel driver, leszedtem szintén Archon, és nálam volt kép továbbra is, meg is oldotta a gondjaim. Egyszerűen minden grafikus felület működött tovább normálisan, még a Xorg-osok is, pedig elég sokféle felület van nálam felrakva párhuzamosan, Openbox, Xfce, i3wm, dwm, IceWM, meg egy fél KDE. Az is igaz, hogy tiszta Arch van fent, nem scripttel tettem fel, hanem kézzel, a Wikit követve.
-
Frawly
veterán
Pedig így mennie kéne, ahogy csináltad. A Gnome kompozitorát megnézted? Saját beépített kompozitorral jön. Ott be kéne kapcsolni a vsyncet.
Egyébként ezt a kimenetet nem értem. Lehet igaza van lev258-nak, és én vagyok tájékozatlan, de emlékeim szerint a Gnome3-nak már waylandesnek kéne lennie, aminek a modesetting drivert kéne betöltenie (nem is lenne szabad tudnia mit kezdeni a Xorg driverrel), nálad meg Xorg-ot ír Intel Xorg driverrel, ami nem ajánlott, főleg Kaby Lake GPU-n nem, az Arch Wiki külön ki is emeli, hogy csak régi Intel GPU-kra jó már, újabbakra nem ajánlott. Mindegy, ehhez ne nyúlj hozzá, mert igaz, hogy le kéne szedni, de múltkor is volt egy kezdő a Mint topikban, akivel leszedettem a Xorg drivert, erre annyira összeqródott a telepítése, hogy kép sem volt, pedig nem lett volna szabad ilyennek történnie. Szóval én eltávolítanám az xf86-video-intel csomagot, de neked ajánlani nem tudom, ha megléped, csak saját felelősségre csináld, nem vállalom a felelősséget, ha nem lesz kép!!!
Szerk: remélem a Gnome-ot nem git-ből forgattad le, hanem rendesen a hivatalos Arch tárolóból szedted le pacman-nal.
-
Frawly
veterán
Na, akkor eljött az a pont, hogy megírod milyen gépre tetted fel, főleg a GPU lenne érdekes (CPU a cpufreq állítása miatt), mert ahhoz majd segítünk drivert választani, és konkrét driverhez tearingmentesítő megoldást használni. Így a látatlanban azt tudom tanácsolni, hogy a Gnome kompozitorában kapcsold be a vsyncet.
Amúgy próbáld meg a cpupower-gui-git csomagot leszedni yaourt-tal AUR-ból. Hátha azzal tudsz állítani a procin. Vagy Gnome alatt már sikerült a Gnome-os cpufreq appletet beüzemelni?
-
Frawly
veterán
Azért próbáld ki a Gnome-appletet. Nem olyan biztos az, hogy a fél Gnome-ot húzza magával. Meg ha még rosszabb esetben húzza is, akkor sem tölti be mindet, csak ami annyira szükséges belőle, nem hinném, hogy egy applet annyira sok memóriát megenni. Az is igaz, hogy talán Xfce-hez is van hasonló plugin.
-
Frawly
veterán
válasz
ubyegon2
#5041
üzenetére
Sehol senki nem ajánlotta az Archot kezdőknek. Az a Manjaro volt, amit pl. én továbbra is ajánlhatónak tartok bárkinek. Egyébként lehet Manjaro-val jobban is járnál, az is Arch alap, de felhasználóbarátabb, meg igaz, hogy pár nap eltéréssel frissítve az Archhoz képest, de épp úgy egész frissek a csomagjai. Így élvezheted az Arch előnyeit annak hátrányai nélkül.
-
Frawly
veterán
Én úgy tudom, hogy a Core Solo, Core Nemkettő Duo, Core 2 Duo, Core 2 Quad prociknál is pstate van, meg talán már Pentium M, Core M prociknál is. Plusz Atom, meg mindenféle procinál, ami ezek után készült. AMD-hez nem értek, nagyon régen nem volt már AMD procim.
Egyébként gratula, szép megfejtés volt, erre a lehetőségre nem gondoltam volna.
-
Frawly
veterán
A redshift szerintem nem volt konfigolva parancssori paraméterrel vagy ~/.config/redshift.conf fájlban. Meg kell adni neki a földrajzi helyet, ahol használod (földrajzi szélesség, hosszúság, Google Mapról tudsz puskázni, meg hogy nappal és éjjel milyen színhőmérsékletre állítsa a monitort, meg a gamma világosságot, és van még egy pár beállítás). Arch Wiki Redshift cikkét most nem linkelem, nehogy Ubi Egon leszóljon, terminálban is meg tudod nézni a súgóját a man redshift segítségével.
Ilyenkor mindig terminálban kell elindítani, ki fogja írni, hogy miért nem indul. Ez minden olyan progira vonatkozik, ami grafikus felületen nem indul el, vagy elindul, de aztán kilép.
A Mate Gtk-s asztali környezet, szóval a redshift csomagban lévő redshift-gtk binárist kellett volna futtatni, bár config nélkül az sem indul el. Meg nálam az is hiányolt néhány Phyton extensiont (ezt függőségnek be kellett volna húzza, ez a csomagfenntartó hibája ráadásul), meg a dbus-t is igényli, de annak Mate-en rendbe kell lennie.
Lehet már a konfigurálással sem kell bajlódnod, mert lefutott a redshift-qt, azt beállítottad, kiírta a beállításait, és már csak futtatnod kell helyette a redshift-gtk-t.
-
Frawly
veterán
Utolsó ötlet: lm_sensors csomagot telepíteni. Mondjuk az a CPU freq állításba nem szól bele, de hátha van benne olyasmi, ami kell a kiolvasáshoz. Próbáld Mint MATE-en nézegetni, hogy miket enged állítgatni. ott hányas verzió van fent belőle, tartozik-e hozzá valami conf fájl.
Ez az applet amúgy a proci teljesítményét engedné állítgatni, vagy csak kijelezné?
-
Frawly
veterán
válasz
ubyegon2
#5018
üzenetére
Igazából Archon ez a core, extra, community elnevezések csak csomagellenőrzés komolyságára utalnak. A core a legszigorúbb, ott tesztelik legszigorúbban a csomagokat, csomag maintainerként oda a legnehezebb bekerülni, ott várják el a legnagyobb megbízhatóságot. Ettől függetlenül a community sem instabil, a core-ba csak néhány csomag van, ami az alaprendszer telepítéséhez kell, más nem is fog belekerülni, pl. a mate, mivel nem szükséges az alaptelepítéshez. Sokszor ugyanazok a maintainerek készítik a core és community csomagokat is, ha megnézed, így valójában minőségi szintkülönbség nincs közöttük. Ez csak alapfilozófia, hogy a core csomagok fontosabbak, még nagyobb figyelmet kapnak.
Igazából ezzel az egésszel nem kell foglalkozni, vannak a hivatalos tárolók, onnan a pacman-nal telepítesz, és van a nem hivatalos AUR, ahonnan AUR-os progival, tipikusan yaourt, de fel lehet tenni mást is. Ennyit kell észben tartani.
Archon is van stating, meg testing, ezekkel sem volt még negatív tapasztalatom, pedig a kerneleket innen szoktam szedni. Ezek a Debian testing, unstable-nek felelnek meg, de a gyakorlatban stabilabbak ezek. Archon nem nagyon fogsz találkozni beboruló, instabil, bugos csomaggal, még staging/testing tárolóban sem. Ha néha van is bug, az nem attól van, hogy a csomagkészítő hányja el a dolgokat, hanem a fejlesztő a git/dev ágba belefejleszt valamit friss feature-t, amit nem tesztel eléggé, és amíg nincs hibajavító kiadás, addig becsúszhat bug (ez is rettenet ritka, mint a fehérholló, stable tárolókban pedig elő sem fordul). Erről nem az Arch tehet, az Arch maintainer csak azt tudja csomagolni, amit az adott progihoz az eredeti fejlesztő fejleszt, azt nem látja előre, hogy a fejlesztő hagyott-e benne bugot (bár nyilván teszteli a gépén, meg testingben, meg stagingben mielőtt a stable tárolóba kerül, de az egész folyamat sokkal gyorsabb, mint a Debian/Ubuntu-vonal esetében). Az Arch alapfilozófiája, hogy vanilla csomagokkal dolgozik, nem nagyon módosítanak semmit a forráskódon, ahogy Debian/Ubuntu-vonalon (és ez jó, mert nem hekkelnek bele disztróspecifikus dolgokat, ami az életet bonyolítja). Az Arch csomagkarbantartói is épp úgy gitből húzzák az új verziókat, és az AUR-ban lévő pkgbuild scripthez hasonlóval forgatják le meg készítik a csomagokat. Igazából az egész folyamat teljesen megbízható, egy nagyon kipróbált rendszert járattak be a csomagkészítők. A gyakorlatban azt tapasztalatom, hogy az adott csomaghoz tartozó pkgbuild scriptet annyira tökélyre csiszolják, hogy ha leszeded, és kézzel újrafordítod (az a gitből a legújabb verziót fogja lehúzni), akkor az is normálisan fog működni, csak a verziószámot nem szabad elfelejteni átírni rajta, meg ha vannak verziófüggőségei más csomagoknál, akkor azoknál a verziószámot feltüntetni.
Igazából az Arch csak annak nem való, aki nagyon kezdő/türelmetlen, vagy a gépén valami olyan speciális zárt drivert (hulladék hardverhez) vagy zárt progit kell használnia, ami régi csomagverziókra korlátozzák be, és emiatt nem frissíthet, utóbbi emberkéknek találták ki a Debiant meg a CentOS-t. Ilyen zárt hulladékokat egyébként is kerülni kell, ha egy mód van rá. Nem csak az Arch miatt, más korszerű disztróknál is ugyanez áll fenn.
Ezért fontos a nyílt forráskód. Stallman, Torvalds meg a többiek nem azért találták ki ezt az egész GNU, free, opensource, GPL mantrát, mert ingyenélő hippik, akik be vannak szívva, meg mindent ingyen akarnak, humanitárius adakozóként azt akarják, hogy falu végén, fejkendős Mari néni unokájának is legyen ingyért valami a celeronjára, ha nem telik neki Windowsra meg MS Office-ra, hanem azért, mert észrevették, hogy jogi korlátok meg a zárt forráskód visszafogják az informatikai fejlődést, amit nem tartanak megengedhetőnek, mert utána csak a függőségi, terjeszthetőségi, karbantartási szívás van azokkal, kerülgetni kell másnak a szarjait, korlátozásait és nem tudnak az érdemi fejlesztésekre koncentrálni. Igazából a saját munkájukat könnyítik meg ezzel az alapfilozófiával, meg lehetővé teszik vele, hogy más is könnyen beszálljon a fejlesztésbe. Sőt, olyan nagy cégek mint a Samsung, Microsoft, Intel, IBM, Google sem azért fizetnek kernelfejlesztőket, meg pénzelik az egész kernelt, Linuxot, mert jótékonykodni akarnak PR-ból az adójuk 1%-ával, hanem tudják, hogy nekik is jól jön, ha kiadnak egy új technikai megoldást, hardvert, platformot, akkor mindjárt lesz rá támogatott OS, szoftver, lesz egy nyílt megoldás, amihez könnyen hozzá lehet nyúlni mindenféle megkötés nélkül. Így ha pl. a Fujitsunál holnap összedobnak valami új szuperszámítógépet, új speciális kínai processzormagokkal, akkor nem kell pl. a Microsofthoz elmenniük könyörögni, hogy lécci-lécci, támogassátok már a mi non-x86 ócskavasunkat is, adjatok ki rá valamit, ha más nem alfa állapotban, itt a sarokban porosodik, összedobtunk egy kis gépecskét, 300 ezer procimag, 25 PFLOPS összteljesítmény, 240 TB RAM, lécci-lécci, hadd wordözzünk rajta mink egy jóízűt, vaskos pénzeket tejelnénk érte. Ha egyáltalán a kérésük nem süket fülekre talál, akkor is évek lennének, mire a MS elő tudna állni valami használhatóval, addigra meg már az egész projekt aktualitását vesztené. Így meg csak ráheggesztik, hozzáfejlesztik az épp aktuális Linux kernelt, és azonnal beröffen a masina, lehet tesztelni, optimalizálni, kísérletezni vele. De elég volt megnézni, mikor törtek fel ezek a mobilos ARM-es olcsó eszközök, okosteló, táblagép, a Google egyből kapott az alkalmon, nem kellett a 0-ról OS-t kitalálni hozzá, hanem azonnal nyúltak is a Linux kernelért, kihasználva annak a rugalmasságát, portolhatóságát, jogi korlátozásmentes voltát, és az Androidot így akkora sikerre vitték, amit más azóta sem tudott megismételni, magyarán bőven visszajött nekik az a pénz, amit anno a kernel támogatásába öltek.
Vagy egy másik példa, a mostani Spectre/Meltdown-sebezhetőség. Január elején publikálták, Linuxra már az első napokban megjelentek az első működő Meltdown patchek. A MS-nál először gond volt a patchekkel, aztán nekifutottak újra, aztán azzal is a gond volt, mert az Intel elcseszte a mikrokódot azokhoz a procikhoz is, amikhez egyáltalán adott ki. Aztán megint vissza lett vonva a Windows javítás, és azóta is várnak az Intelre, hogy mikor jön ki végre a javított mikrokód, amivel újra működhet és terjeszthető lesz a javítás. Erőforrásuk sincs rá, bevonni sem tudnak senkit a zárt forráskód miatt Közben meg a sötétebb oldalon teljesen más volt a hozzáállás. Nem vártak az Intelre, míg összeszedi magát, hanem lefejlesztettek saját, szoftveres megoldásokat, amihez nem kell a procira új mikrokód, a Meltdown elleni PTI már a kernelfejlesztők tarsolyában volt, de a Google is elég gyorsan előállt a retpoline technikával, meg pár hétre rá elkészült az user pointer sanitization. Így igaz, hogy linuxos vonalon is majd 30 napot kellett várni, míg minden foltozva lett egy új stabil kernelben, de egyrészt ezek linuxos szoftveres javítások kevesebbet lassítanak, mint a mikrokódos technika, plusz hamarabb is elkészültek, Windowsra még mindig nem jött ki a mai napig a végleges patch. Majd ha kijön, Torvaldsék megint lépéselőnyben lesznek, mert ők már nem hogy a patchon, de már annak az optimalizációin dolgoznak, amit addigra be is fejeznek, kijön a 4.16-os kernellel. Ha ők is vártak volna az Intelre, a mai napig nem lenne semmijük. A nyílt forráskód tette lehetővé, hogy ennyi fejlesztő ilyen gyorsan összedolgozzon, és ne kelljen függni az Inteltől. Csak hát megint ott van Gipsz Jakab, aki ezen kapva már tenné is fel a friss, javított kernelt, de oh wait, nem tudja, mert borul a rendszere, a zárt forráskodú szarja, amihez nem mer évek óta nyúlni, mert ne piszkáljuk azt, ami működik alapon még megy, és függősége van régi verziókhoz, így hiába lehetne előrelépni, vállalnia kell, hogy inkább sebezhető marad. Ugyebár az új kernellel dominósorban borulna neki minden, új kernel új systemdre és glibc-re dependel, de akkor már Xorgból is új kell, nem mennek a régi, egyedire fordított, azóta nyilvános nyílt forráskód hiányában újra nem forgatott kernelmodulok. Arch alatt meg a hobbista felhasználó kiad egy frissítés parancsot, és elégedetten használja az újdonságokat, anélkül, hogy PPA-val meg újraforgatással, disztrófrissítéssel, meg nem tudom mikkel kéne vergődnie, meg eltéesre meg feautre freezre és hasonló baromságokra várnia, hogy 1-2 év lemaradásban hadd használja már az épp aktuális verziókat.
Pont most volt gondja ebből valakinek a HUP-on, Debianon akart a szentem új Wine-t, ami nemrég jött ki, frissen, ropogósan, mindenféle új DX/Vulkan támogatással. Próbálta PPA-ból felszögelni, de teljesíthetetlen verziófüggések léptek fel. Ezeket elkezdte egyenként kézzel feloldogatni, hogy azokból is új csomagokat vadászott és forgatott, de utána azoknak a telepítése is teljesíthetetlen verziófüggésbe ütközött, amiket szintén fel kellett volna oldani, de azt már nem vállalta be, mert ennyi erővel az egészet telepíthette volna újra kézzel. Archon én akkor már kb. egy hete azt a Wine 3.akármit használtam, ami szépen lecsorgott egy pacman -Syu során olyan szép csendben, hogy fel sem figyeltem rá, probléma nélkül működött, sőt, tegnap frissült még újabb verzióra (3.3), míg máshová a 3.0-ás sem érkezett meg. Azért ez nem kis különbség.
Vagy szintén a HUP-on, még a Meltdown első heteiben indítja a topikot a szerencsétlen, hogy céges szerver, 3 tonna földdel elhantolva évek óta, megy, dolgát teszi, de most valaki véletlen átesett rajta, és ha már így belebotlottak, frissítették Meltdown ellen, és hiába zajlott le rendben a frissítés, meg volt hozzá backportolt kernel ebben a régi ágban, nem bootol. A történet lényege: CentOS 6 még 2.6.faxtudjamilyen kernel. No comment. De stabil volt, mint a beton. Míg frissíteni nem kellett. Amit nem lehet, csak ha az egész kócerájt újrarakja az ember.
De ugyanígy fogom a fejem, mikor reklámozzák, hogy ilyen olyan LTS disztró kettőezerhuszonsokig támogatott lesz. De mi a francnak? Addigra olyan régiek lesznek a csomagok, hogy érdemben nem sok mindenre lesz használható, csak muzeális használatra lesz alkalmas, arra meg főleg desktopon minek? Ha egy új böngésző nem fog rámenni, meg egy idő után már a Flasht sem lehet frissíteni rajta? Ki a ráknak szánják?
-
Frawly
veterán
A /usr/lib/mate-applets/mate-cpufreq-applet indításával próbálkozz, de csak simán is el kéne indulnia mate-cpufreq-applet indításával (nem mate-cpu-freq a neve, ahogy írtad).
Egyébként kezdem úgy látni, hogy nem jó ötlet ez az ilyen-olyan scriptek mentén telepítés, itt szívtok vele párhuzamosan.
-
Frawly
veterán
válasz
ubyegon2
#5010
üzenetére
Nem kell nekifutni, most kipróbáltam a saját rendszeremen, a sudo pacman -S mate-extra működik, húzná a mate-t is vele. A lényeg, hogy nem az AUR-ban van, amihez yaourt kell. Nem kell gitezni, fel kel tenni. Ahogy írtad, az általa feltett script is felteszi, akkor meg csak hozzá kell adni az appleteket a panelhoz.
Az Arch Mate, Arch Xfce sanszosabb gyorsabb, fürgébb lesz, mint a Mint Xfce. Archon update-grub helyett grub-mkconfig -o /boot/grub/grub.cfg futtatása van.
-
Frawly
veterán
-
Frawly
veterán
A mate csomagcsoport mellé a mate-extra csomagcsoport összes tagját is feltetted, ahogy a kollégának írtam? Mert a mate-extra csoportban benne van a mate-applets csomag, amiben benne van a mate-cpufreq-applet és a mate-cpufreq-selector. Sőt, utóbbi csomagban még a battstat-applet is benne van, ami a másik gondod is megoldja elvileg.
Ez ilyen türelemjáték, hogy mit kell feltenni. Pont azért nem először írom azt, hogy aki Minthez szokott, amibe minden bele van készítve alapból, annak az Arch egy kicsit meredek lesz elsőre. Nem kell azonnal kétségbe esni, ha ment Mint alatt, itt is menni fog, csak nem szabad feladni.
-
Frawly
veterán
Ezeket passzolom, már sok éve nem volt fent nálam MATE. Itt korábban is csak azért írtam azt példának, mert a kolléga is azt akart magának telepíteni.
Próbálj jobb klikkel hatni rá. Igazából ezt Live Mint MATE alatt kéne megnézni, hogy mivel lehet állítani, gyanítom, hogy semmi nem kell hozzá feltenni, de a neten nem sok értelmeset írnak róla.
-
Frawly
veterán
válasz
ubyegon2
#4999
üzenetére
Korábbi kimenetet minek betenni? Archon nem érdekes, amit az inxi Minten írogatott. Amúgy mennie kéne ezeknek a kártyáknak Archon is, lásd a fenti részletes litániáim, meg a linkelt Wireless network Arch Wiki cikk. Inxi helyett lspci -k, meg ip link, ip a parancsok.
A kéklufis cikk két éve módosult utoljára, de ahogy átfutottam, azóta nem nagyon változott semmi.
Érdemes tiszta telepítést csinálni, mert az sem nehéz, legalább látod hogy működnek dolgok, megtanulod, legközelebb nem leszel scriptre rászorulva. Meg menet közben látod, hogy mi az, ami nem működik, és nem kell találgatni utólag, hogy a script mit cseszhetett el.
-
Frawly
veterán
Örülök, hogy megoldódott. Wi-Fi-vel lehet szívni bármilyen disztró alatt. Gyakran előfordul, hogy a disztró vinné a Wi-Fi-t, de legtöbbször laptopokon vagy hardveres gombbal, vagy szoftveresen rfkillel blokkolva van alapból, és erre sokan nem jönnek rá, hogy csak ezért nem megy. Akinek nem megy a Wi-Fi, ezt is ellenőriznie kéne, bár ha az ip link szerint a Wi-Fi eszköz státusza „up”, akkor nem ez a baj.
-
Frawly
veterán
válasz
ubyegon2
#4995
üzenetére
Ja, az lehet. Ezeket a spéci telepítőszkripteket nem ismerem, csak plusz egy köztes réteg, amivel szopni lehet. Ha nem akarsz szívni, sokat olvasni, akkor csapd fel itt a Prohardveren kékluficet Arch Linux, ahogy én telepítem írását, azt folyamatosan frissíti is, és az alapján csinálj egy kézi Arch telepítést. Amikor a grafikus felület telepítése részhez érsz, akkor ott abbahagyod a cikk olvasását és kiadsz egy sudo pacman -S mate mate-extra parancsot, amikor kérdezi, akkor a mate és mate-extra csomagcsoportnál az összes csomag telepítése opciót választod. Ez telepíteni fog mindent, ami a MATE desktophoz szükséges, mindenednek működnie kéne alapból, semmilyen más mókolásra nem lesz szükséged. Épp úgy tudod használni a gépet, mintha csak Mint MATE-et vagy más MATE-es disztrót telepítettél volna alapból.
-
Frawly
veterán
Neked is ugyanazt az Arch Wiki linket ajánlom, amit Júbájgön kollégának betettem. Az ott írt utasításokon kéne végigmenni, elsőnek a lspci -k (vagy ha USB-s Wi-Fi, akkor lsusb -v), ha be van hozzá töltve a szükséges kernelmodul, akkor ip link paranccsal megnézni, hogy be van-e az eszköz röffentve, ha nem, akkor ip link set eszköznév up. Telepítve kell lennie a wpa_supplicantnak, és ha nem akarod kézzel .conf fájlban konfigolni, akkor a dialog csomagnak, hogy legyen TUI-s menüd a kényelmes Wi-Fi kapcsolódáshoz. Ha ezek nincsenek fent, akkor újra bebootolod az Arch telepítőd, azon fent a wpa_supplicant és a dialog, így a wifi-menu kiadásával tudsz csatlakozni a Wi-Fi-hez, felcsatolod a root partíciód, átváltasz rá arch-chroot-tal, és ott pacman -S wpa_supplicant dialog kiadásával telepíted a szükséges csomagokat, majd visszabootolsz a telepített rendszerre és tudod a Wi-Fi-t használni.
Az Intel 8260-as kártya nem igényel semmilyen extra drivert, az automatikusan felkerülő linux-firmware csomag kell neki, és automatikusan betöltődik hozzá az iwlwifi kernelmodul.
-
Frawly
veterán
válasz
ubyegon2
#4986
üzenetére
Sőt, hova ne tovább, ha trollkodunk, meg lehet említeni, hogy ha az Arch nem kezelte volna a hálókártyákat a gépedben, akkor már a telepítőszkript sem tudott volna alaprendszert telepíteni.
Abban mondjuk igazad van, hogy gáz, hogy a telepítőmédián telepítve vannak a Wi-Fi-hoz szükséges dolgok, míg az alaprendszerre nem kerül fel automatikusan. Ez amiatt van, mert az Arch filozófiája az egyszerűség, csak a legminimálisabb számú csomag legyen az alaprendszerre telepítve, ne legyen fent feleslegesen minden szar. Ha valakinek kell valami, felrakja kézzel.
Igazából az lenne a kérdésem feléd, ha lesz majd hálózatod, milyen grafikus felületet akarsz telepíteni? Mert ha valami nagyobb DE (Gnome, KDE, Cinmanó, CsákMáté, stb.), akkor azok kompletten behúznak maguknak minden függőséget, Xorg, libinput, GPU driver, NetworkManager tipikusan, Wi-Fi-hoz wpa_supplicant, ha waylandes felület, akkor waylendet, stb. Ha viszont kisebb WM-et terveztél be, akkor viszont szopós, ahogy már többször írtam, akkor neked kell gondolni mindenre, még az alap hálózatkezelésre is neked kell minden csomagot feltenned meg sokszor kézzel konfigurálnod, a kisebb WM-ek nem húznak be sok függőséget. Persze alap hálózatkezelés mindenképp kell, akkor is ha fullos DE lesz, mivel annak a csomagjait is le kell tölteni valahogy.
-
Frawly
veterán
válasz
ubyegon2
#4986
üzenetére
És láss csodát, fent is van, hiszen a kimenet alapján kezeli a hálózati eszközeidet, betöltötte a hozzájuk való kernelmodult, és state-up állapotban is vannak. Tehát nem ilyen alaptalan Nők Lapja pletykákkal traktáltalak, bár ezekhez a kártyákhoz talán még firmware sem kell, alapból viszik a kernelmodulok.
-
Frawly
veterán
válasz
ubyegon2
#4985
üzenetére
Ahogy nézem, a vezetékes kártyád felismerni, be van töltve hozzá a hozzá való kernelmodul, be is van izzítva (state: up). Lehet csak egy kézi dhcpd & parancsot kéne futtatnod, hogy kapjon IP-t, átjárót, DNS-t, és már lenne is neted.
A Wi-Fi-odra ugyanez áll, ahogy nézem azt is megismerte, a kernelmodul szintén betöltve hozzá. Azt viszont nem értem, hogy az enp2s0 vagy a wlp3s0-nak kéne-e mennie. Fel kéne hozzá tenni az alaprendszerre a wpa_supplicant és dialog csomagokat (ezek a Arch telepítőmédián fent vannak, így a script tudta használni őket telepítéskor, de a telepített alaprendszerre nem kerülnek fel automatikusan, kifejezetten kézzel kell telepíteni őket), előbbi úgy általában a minimális Wi-Fi beröffentéséhez kell, az utóbbi, hogy legalább konzolban, míg nem telepítesz grafikus felületet vagy NetworkManagert vagy wicd-t, vagy egyebet, addig is legyen egy TUI-s menüd, ahol kényelmesen tudsz SSID-t kiválasztva AP-hoz csatlakozni.
-
Frawly
veterán
válasz
ubyegon2
#4983
üzenetére
Milyen hálózati kártyáról van szó? Mert írtad, hogy nem Wi-Fi, az kevés. Aztán meg írod, hogy az Arch felrakásához is kell Wi-Fi driver. Azért kérdezem milyen hardver pontosan. linux-firmware csomagnak alapból fent kéne lennie, igaz nincs benne minden Wi-Fi, vannak különböző firmware pakkok az egyes gyártók kártyáihoz. Első körben érdemes átolvasni a Biblia részeként az Arch Wiki vonatkozó részét.
-
Frawly
veterán
A Cinnamon nem támogatja a Waylandet, a GDM igen. Elég kevés DE, WM, DM támogatja, tényleg csak egy maréknyi, de alkalmazás sincs túl sok, amit támogatná (a többieknek az XWayland emulál Xorgot). Távolítsd el pacman -Rs segítségével, majd telepítsd újra a Xorg-ot és a Cinnamont. Kéne mennie. GDM-et fenthagyhatod, nem muszáj Gnome-mal használni, más DE-ket, WM-eket is indíthat, támogatja a Xorgot is.
A Wayland egyébként nem jobb, csak modernebb, és mivel saját maga is egyben kompozitor, ezért nem kell hozzá külön kompozitort feltenni, mint X-nél. Ha annyira Waylandet akarsz, akkor Gnome3-at vagy KDE5-öt telepíts, azokkal rendesen működik, azok behúzzák függőségnek, és rendesen konfigurálja is a rendszer, nem kell vele semmit kínlódnod.
Az Arch telepítése nem nehéz, ha csak alap telepítést csinálsz. Bonyodalom onnan lehet, ha valami extra dologgal telepíted, systemd UEFI boot, LVM, LUKS, ezek kombinációja, hasonlók. Egyébként rém könnyű feltenni, kialakítod neki a partíciókat, felcsatolod őket, genfstab futtatása, pacstrap-pal alaprendszert telepítesz a felcsatolt root partícióra, átváltasz rá arch-chroot-tal, ott még feltelepíted amit kell pacman -S segítségével, hostname, lokalizáció beállítása, bootmanager telepítése, mkinitcpio-val initramfs készítése, passwd futtatásával root jelszó beállítása, reboot. A bootmanagerrel lehet esetleg nagyokat szívni, de ez nagyban függ, hogy melyiket választod, meg használsz-e UEFI bootot, meg hogy más OS-t használsz-e dual/multibootban.
Ha megvan az alaprendszer, onnan a telepítés további nehézsége attól függ, hogy komplett, fullos DE-t telepítesz-e fel, mert az leszedi magának az összes függőséget, és kulcsrakész rendszert kapsz. Ha viszont kisebb WM-et akarsz feltenni, ahhoz még elég sokmindent kell konfigolni, meg tudni hozzá, hogy melyik csomagokat szedjed le és konfigoljad, hogy az igényeid szerint tudjad használni, ha tapasztalatlan vagy, ez tud nehézségek elég állítani, meg nyálazni kell a Wiki-t sasszemekkel, de ez is csak első telepítésnél nehéz, amíg nem tapasztaltad ki.
Esetleg néhány driver feltétele lehet még szívás, főleg, ha GPU drivernél ragaszkodsz a zárt driverhez vagy valami speciális megoldáshoz, vagy virtualizációhoz kell kernelhackhez, forgatni kell Wi-Fi drivert, stb..
Már el is felejtettem sok mindent, mivel az Arch olyan, hogy ha egyszer feltelepíted, akkor többet arra a gépre a büdös életben nem kell újratelepíteni, hacsak ki nem rohad alóla a gép, vagy a disk, vagy az user szét nem cseszi valami bénasággal a telepítést, és nem tudja megjavítani. Egyébként magától frissül a végtelenségig, mivel rolling, nincs disztrófrissítés. Legutóbb 9 hónapja tettem fel egy használtan vásárolt laptopra, amibe mindjárt egy SSD is került.
-
Frawly
veterán
Most láttam egy YT-videón, hogy a pacman-t be lehet úgy állítani, hogy a letöltőcsík a Pac-Man játékra hasonlítson, ahol egy c eszi meg az o jeleket, kötőjeleket hagyva maga után [---c o o o o ] [------C o o o ], stb.
Tudom, újszülöttnek minden vicc új, de nem ismertem. Az /etc/pacman.confban a Misc options részben az ILoveCandy stringet kell hozzáadni. Ha már ott voltam, akkor kivettem a kommentjelet a TotalDownload elöl is. -
Frawly
veterán
-
Frawly
veterán
Arch-csal kapcsolatos hírek: kijött Archra is a 4.15.2-es kernel, ami már végre a Spectre1 elleni sebezhetőséget is foltozza tisztán szoftveres úton, így nem igényel mikrokódot és új BIOS-t.
A másik dolog a frissítéssel kapcsolatos:
:: Starting full system upgrade...
:: Replace compositeproto with extra/xorgproto? [Y/n]
:: Replace damageproto with extra/xorgproto? [Y/n]
:: Replace dmxproto with extra/xorgproto? [Y/n]
:: Replace fixesproto with extra/xorgproto? [Y/n]
:: Replace fontsproto with extra/xorgproto? [Y/n]
:: Replace inputproto with extra/xorgproto? [Y/n]
:: Replace kbproto with extra/xorgproto? [Y/n]
:: Replace randrproto with extra/xorgproto? [Y/n]
:: Replace recordproto with extra/xorgproto? [Y/n]
:: Replace renderproto with extra/xorgproto? [Y/n]
:: Replace scrnsaverproto with extra/xorgproto? [Y/n]
:: Replace videoproto with extra/xorgproto? [Y/n]
:: Replace xextproto with extra/xorgproto? [Y/n]
:: Replace xf86dgaproto with extra/xorgproto? [Y/n]
:: Replace xf86vidmodeproto with extra/xorgproto? [Y/n]
:: Replace xineramaproto with extra/xorgproto? [Y/n]
:: Replace xproto with extra/xorgproto? [Y/n]
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: libxfont: removing fontsproto breaks dependency 'fontsproto>=2.1.3'
Ezt a hibát frissítéskor úgy lehet megoldani, hogy eltávolítjuk a libxfont csomagot (pacman -R libxfont). Utána újra frissíteni kell pacman -Syu kiadásával és nem fog többet reklamálni. -
Frawly
veterán
Ha már sl, akkor találtam az Arch Linux tárolójában asciiquarium csomagot, az is hasonlóan ütős. Nagyon sok szabadideje van ezeknek a fejlesztőknek, igaz ennek legalább kapcsolói meg man page-e nincs legalább.
Apropó, ha már akvárium. Valami 3D grafikás linuxos opensource akváriumos képernyővédő alkalmazást nem tud valaki? Ami ki lehet tenni képernyővédőnek poéból. Tudom, hogy a 90-es évek vége óta mindenki energiatakarékos képkikapcsolást használ képernyővédő helyett, én is, de poénból nem rosszak ezek az akváriumok. Videós változatokat találtam már a YouTube-on.
-
#4935
Frawly
veterán
bandras0226
#4912
Frawly
veterán
válasz
bandras0226
#4912
üzenetére
Ha csak azért linuxozol, mert nincs pénz Windowsra, akkor rendelj az eBayről jelképes összegért működő Windows-termékkulcsot. A MS ezt a módszert nem tekinti legálisnak jogilag, de technikailag működik, a telepítő elfogadja a kódot, a MS-nál beaktiválódik a példány örökre (tehát legközelebbi telepítésnél már kódot sem kér a telepítő). Valami ezer forintért lehet így technikailag tiszta Windowst használni, menni fog vele az Update meg minden, nem kell törést használni hozzá és aktivációval trükközni. Ennyit szerintem akkor is rá tudsz szánni, ha minden pénzed ráment az új gépre.
Persze a linuxszal jobban jársz (hacsak nem játszol vagy nem Adobe-programcsomagokat használsz, meg nem CAD-ezel), mert technológiailag sokkal fejlettebb OS, de csak azért ne linuxozz, hogy spórolj. Linuxozni meggyőződésből, szakmai fejlődésvágyból, tanulási szándékkal érdemes, akkor van meg az a tényleges plusz motiváció arra, hogy próbálkozz vele és tanulgasd, szokd a használatát és kilépj a Win only IT világából.
ubyegon: nem azt írtam, hogy a Cinnamon lezár. Nem használom, csak próbáltam ötletet adni, hogy mit próbáljon még meg. A leírását olvasva az az érzésem, hogy a videódriverrel nem stimmel neki valami. Amúgy most elmegyek egy min. egy hónap pihenőre. Most nem moderálás kivételesen, hanem ez a szájbak***t oldal azt játssza már hetek óta, hogy majdnem egy percbe telik, mire egy fórumoldal vagy lap betöltődik (pedig a reklámblokkoló is ki van kapcsolva), mindegy milyen böngészővel próbálom. Más blokkoló, tűzfal, vírusirtó nincs fent, ami anomáliákat tudja okozni. Most épp jó, de ez így komolytalan oldal, ha nem tudják megoldani, hogy ünnepi időszakban bírja a terhelést. Jeleztem már a PH Interaktív fórumban, de le sem sz**ják, még csak annyit sem jeleznek, hogy náluk nem áll fenn a hiba. Lehet csak nálam ilyen, mert külföldről látogatom az oldalt, de más magyar oldal nem csinálja, csak a PH lapcsalád.
-
Frawly
veterán
Először én sem láttam, de ott van a screenshotján, hogy Cinnamon verziója. Cinnamont nem annyira ismerem, de valami Vezérlőpult félében kéne Energiagazdálkodást keresni, és ott a képernyő kikapcsolásánál kivenni a pipát az elöl, hogy jelszót kérjen. Ámbár én benne szoktam hagyni, mivel a biztonságot szolgálja, nyilván azért kapcsolt ki a képernyő, mert nem vagyok a gép előtt, akkor szépen zárjon le, hogy más ne tudjon belematatni. Ha zavaró lenne, hogy filmnézés közben zár le, akkor a lejátszókban szokott lenni olyan opció, hogy képernyőkímélő letiltása.
-
Frawly
veterán
Folytatva a szokásos monológköreimet:
Az NVIDIA befejezi a 32 bites operációs rendszerek támogatását -
Frawly
veterán
Sőt, a 32 bit koporsójába ilyen szögek is bele vannak verve:
"32 bit kernels are limited to 16 TiB because the page cache entry index is only 32 bits. This is a kernel limitation, not a filesystem limitation!"Tudom, kevés felhasználó csatol fel az otthoni 32 bites gépén 16 teránál nagyobb fájlrendszert, de pont most futott bele ilyenbe egy fórumozó egy másik oldalon, szóval annyira azért nem extrém példa, elég NAS-ba bepakolni pár 3 terás HDD-t és LVM-ként használni egy logikai kötetként. Egyszerűen a 32 biten túlhaladt a fejlődés már otthoni szinten is.
Szervereken meg már sokszorosan meghaladták, nem véletlen volt ez a fejlesztés a 4.14-es kernelben:
Original x86-64 was limited by 4-level paging to 256 TiB of virtual address space and 64 TiB of physical address space. People are already bumping into this limit: some vendors offers servers with 64 TiB of memory today. To overcome the limitation upcoming hardware will introduce support for 5-level paging. It is a straight-forward extension of the current page table structures adding one more layer of translation. It bumps the limits to 128 PiB of virtual address space and 4 PiB of physical address space. This "ought to be enough for anybody" ©. -
Frawly
veterán
Még egy kis adalék ahhoz, hogy miért irtja mindenki a 32 bitet tűzzel-vassal: LAME optimalizálás. Itt most nem erről a csomagról van szó, de szépen szemlélteti, hogy mi a baj a 32 bites támogatással. Még ha nem is 386-586-os, amit rég beszüntettek már, akkor is a 686-os architektúra támogatásával előjönnek olyan problémák, hogy nem lehet a modern procik utasításkészleteit használni, ezért minden max. MMX-hez van fordítva, ami meg modern prociknál nem segít semmit. A 64 bites csomagokkal ilyen baj nincs, hiszen a legrégebbi 64 bites x86-os proci is támogatja a mai utasításbővítések nagyját. Tehát nem csak hogy több memóriát lehet használni mindenféle PAE-trükközés és lapozgatás nélkül 64 biten, de gyorsabb is, és nem csak azért, mert 64 biten több a CPU-regiszter, de optimálisabb utasításkészletek is használhatók. Elhiszem, hogy a lassan mémmé váló bőrtok sokat nyom a latba, de nem ennyit.
-
Frawly
veterán
Akkor kérdezem máshogy. Az LXDM hol tárolja azokat a sorokat, amivel az egyes, már fent lévő grafikus felületeket indítja?
Ha ezt megtalálnám, akkor oda be tudnám szerkeszteni azt a sort, amivel már működnének a dolgok. Ugyanis az Openbox egy elég primitív WM, ezért a dbus-nak kell előbb indulnia, és wrapperként futnia az Openbox felett. Ennek meg is van a mikéntje, csak az nem, hogy hová adagoljam be az LXDM-nek.
-
Frawly
veterán
Ebben az esetben Lubuntu lesz a barátod. Az elég kicsi, könnyen használható Live módban is (telepítés nélkül futtatva), minden szükséges dolog telepítve van rá (Firefox, Flashplayer, Java, stb.). Esetleg ha nagyon régi, szar gépre lesz, akkor Puppy, esetleg AntiX vagy Sparky Linux, bár az utolsó kettőnek nem tudom, hogy Live módban mennyire használhatók.
-
Frawly
veterán
Openbox alatt nemrég vettem észre, hogy egy-két alkalmazás hiányolja a dbus-t, pedig telepítve van.
Az Arch wiki azt mondja, hogy a exec dbus-launch openbox-session sort be kell tenni az ~/.xinitrc-be. Viszont nálam ilyen nincs, mert LXDM indítja az Openbox sessiont (nem közvetlenül xinit-tel indul), de azt nem találom, ahol át tudnám szerkeszteni. Szétnéztem az /etc/lxdm/lxdm.conf-ban is, de nem találok rá beállítást, vagyis lenne egy session= rész, de abba nem merek beleszerkeszteni, nehogy bezavarjon a többi grafikus felületnek (van fent tesztelni Xfce, i3wm is). Valami mód, hogy hogyan lehetne kivitelezni?
Az sl témájához: nagyon tutkeráj, feltettem én is
Komplett manpage-dzsel jön, meg kapcsolói is vannak. Steamnél meg nem állítottam, hogy most is 32 bites, már multilib. Csak ez nem volt mindig így. -
Frawly
veterán
A 32 bit témájához: nemrég szívtam két játékkal. Nem hivatalos forrásból beszereztem a nem steames Half Life 1-et és 2-őt. Egy valag 32 bites függőséget, libet kellett ldd-vel kinyomozni, meg telepíteni, még így sem lett meg az összes, szerencsére a hiányzóakat a játékhoz mellékelték, így elindult 64 bites Archon. A 2-es résznek még 32 bites fontcache generálás is kellett, ez milyen gyökérség már! Na, ezért irtja mindenki a 32 bites dolgokat már tűzzel-vassal, mert egy a Linux mellett eltökélt kiadó is, mint a Valve, lustaságból több játéknál csak 32 bites binárist tart karban, sokáig a Steam is 32 bites volt csak. Persze hivatalos forrásnál a Steam gondoskodik a 32 bites függőségekről, leszedi magától azt a kazal libet (nem csomagkezelőből, hanem a saját mappájába vagy a játék mellé bepakolja az .so fájlokat), de akkor is kínos. Ha nem lennének a fejlesztők ilyen lusták, akkor nem szüntetné be mindenki sorra a 32 bit támogatását, mivel elférne. Így viszont a bosszúság van vele, és a többség 64 bites rendszert használ, ők pedig érthető okból nem akarnak a 32 bites binárisok miatt szopni.
-
Frawly
veterán
Ja, bocs. Azt hittem, hogy ez egy fórum, ahol bármihez hozzá lehet szólni.
Ha nem akarod kidobni azt a drága bőrtokot, belegyömöszölhetsz 64 bites gépet is, 4 gigánál több RAM-mal. Igaz akkor összepréselődnek a többletbitek, meg a RAM-ot is lehet gzippel tömöríteni kell, hogy beleférjen
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Frawly
veterán
Ezt inkább te ne írtad volna le. A max. 4 GB megcímzése architekturális korlát, nem a MS tehet róla. Non PAE kernellel a linuxos gépek sem tudnak többet megcímezni, és ebben a 4 gigás címtérben a hardvereszközök ROM-jainak és RAM-jainak a címzése is benne van, ezért látnak az ilyen rendszerek 3.X gigát. Ennek a 3.X gigának az egy része is kernel címtere, amit az alkalmazások nem használhatnak, csak tipikusan 2 gigát, és a történet ezen a ponton is elkezd elég kellemetlen lenni, mikor ma már egy kisebb játék meg egy böngésző is bőven bekajálja ezeket a memóriamennyiségeket.
Persze, a legtöbb 32 bites proci támogatja a PAE-t, de néhány régebbi a P4/Celeron Northwood és AthlonXP-s, meg még régebbi proci mégse tud PAE-kerneleket meg 7-esnél újabb windowsokat futtatni NX bit támogatásának a hiányában.
Az MS sok mindenről tehet, de erről nem. Ahogy pl. arról sem tehetnek, hogy a 64 bites windowsokból kikerült a 16 bites alkalmazások támogatása, az is architekturális korlát, és csak emulációs rétegen keresztül lenne lehetséges, de akinek emuláció kell, használ ezekre külön emulátort vagy virtuális gépet, amúgy sem szoktak teljesítménykritikus alkalmazások lenni.
Amúgy figyelmedbe ajánlom a Torvalds vélekedését a PAE-ről.
-
Frawly
veterán
Okok a cserére:
1) Max. 4 giga RAM-ot támogat, abból sem tudsz használni 3,X gigánál többet, hacsak a proci nem támogatja a PAE-t
2) Egyre inkább nem lesz támogatott a 32 bit szoftverügyileg, egyre inkább szenvedős lesz rajta bármit használni.
3) 32 bit only CPU teljesítménye ma már nem sok mindenre elég, egy combos facebookos oldal beakasztja, vagy valami más scriptekkel megpakolt oldal. Videókból is általában már a 480p-vel is problémájuk van ezeknek a prociknak, ha teljes képernyőre kiteszed, stabilan csak 360p-t visznek. Plusz egy ilyen régi gépben a GPU sem szokott a toppon lenni.Semmi gond nincs, anno nem drága bőrtokra kellett volna költeni, hanem új notit venni. Velem is fordult elő, hogy pénzt invesztáltam egy olyan régi gépbe, ami helyett újat kellett volna venni, meg is bántam idővel. Nem szabad, hogy az embert a megszokás és a érzelmi érték befolyásoljon, mikor hardverről van szó. Az ember az új hardverrel nem csak teljesítményt vesz, hanem bizonyos időtállóságot (elavultság kitolása, támogatottság) is.
-
Frawly
veterán
Nem hót felesleges, mert támogatott rendszer kerülne rá. A 64 bites rendszer elvileg nem kéne lassabban fusson, a memóriafogyasztása is csak kicsivel kéne, hogy több legyen. Ami miatt ténylegesen is több memóriát szokott enni, az pont amiatt van, hogy szenvedni kell a 32/64 bit együttélése miatt, be kell tölteni feleslegesen 32 bites libeket is a 64 bitesek mellé.
Plusz ha hardveresen nem támogatja valami a 64 bitet, az azt jelenti, hogy legalább 11 éves prociról van szó, ha nem régebbiről, azok meg általában ma már egy okostelefon vagy one board gép szintjét sem ütik meg, cserébe fölöslegesen esznek regeteg áramot, ergo szervernek is erősen pénzkidobás áramszámlát fizetni a működtetésükért.
Előbb-utóbb minden nagyobb disztró meg böngésző, meg mindenféle fontos szoftver dobni fogja a 32 bites támogatást. Jobb előbb váltani, mint utóbb fetrengeni vele. Mondjuk ez téged pont nem érint, mivel a Gentoo forrásból forgatós disztró, és abból bármikor forgatsz magadnak 32 bites x86-ra bármilyen kernelt vagy más csomagot, akár PAE-vel, akár anélkül.
-
Frawly
veterán
Nem hiszem, hogy túl sok archert érint ez. Jellemzően technikailag haladóbbak használnak Archot, és ők biztos vagyok benne, hogy költenek gépre, egyéb hardverekre, és nem rekednek meg 32 biten. Ettől függetlenül, ha annyira kell egy egész közösségnyi embernek 32 bites rendszer, akkor forkolják egészséggel.
Egyébként a 32 bites dolgokat azért irtja mindenki tűzzel-vassal (Google, disztrókészítők, de a Skype-pal megkezdte a sort a MS is), mert jellemzően már csak a szoftverek, driverek íróinak lustasága, hogy sokan megrekedtek 32 biten. Nagyon ritka, ha tényleg régi gép nem bírja el a 64 bites rendszert (már vagy 10 éve minden proci 64 bites, de a korai chipsetek kevés memóriát támgatnak, jellemzően max 2 GB). legtöbbször csak azért kellenek a 32 bites multilib csomagok, mert gyökér fejlesztők lusták karbantartani 64 bites verziót, és zárt forráskódos szoftvernél csak a 32 bites verziót publikálják.
-
Frawly
veterán
Miért nem írhatsz coming outot? Amúgy hsz.-be is jöhet, hogy miért jobb a Gentoo, mit lehet vele nyerni az Arch ellenében. Egy időben én is gondolkoztam a Gentoon, és biztos nem rossz, de nem hinném, hogy nagy a nyereség Archról váltva, csak felemésztené azt a kevés szabadidőm is. Mai gépeknél már nem dob sokat, ha a helyi CPU-ra jobban van optimalizálva a forgatott kód, egy 486-P2-es gépen még többet számított, sebességben és foglalási méretben is. Talán egy nagyon keveset biztonság terén lehet vele nyerni.
Az Archnál jelentős előny lenne, ha lenne hozzá több magántároló (van egy-kettő, hasonlóak az ubuntus PPA-khoz), és nem csak forrásból lehetne fordítani, hanem bináris AUR is lenne hozzá, 32 és 64 bites csomagokkal, és komplett függőségkezeléssel. Ami még zavar, hogy Archék kezdenek öregedni, kicsit komótosabban frissülnek a csomagok, mint néhány éve. Nem elavultak, de pl. a Fedorában már sokszor frissebbek a csomagok, csak azzal meg az a bajom, hogy nem rolling release disztró. Lehet átállok Arch testingre, még sose próbáltam, elvileg csak a tárolókat kell hozzá átállítani, meg kiadni egy pacman -Syu parancsot, csak nem tudom mennyire stabil a gyakorlatban. Az Arch stable teljesen stabilnak bizonyult, már majd 2 éve használom, 3 gépváltást is átélt, de sose volt vele baj azért, mert frissek a csomagok, és valami bug vagy instabilitási probléma jött volna elő. Lehet nem instabilabb a testing sem.
-
-
Frawly
veterán
válasz
vinibali
#4822
üzenetére
A pepperflash a hivatalos tárolóban is ott van már, nem csak az AUR-ban. Amúgy tényleg egész jónak tűnik a Chromium is, mintha kicsit gyorsabb is lenne a Chrome-nál. A chromium-widevine (AUR) csomagot telepítve megy a Netflix is, és külön pozitív meglepetés, hogy nem forráskódból forgatta, hanem tar.gz-t húzott le, amiből binárist bontott ki, szóval szempillantás alatt települt, sokkal nagyobb szopásra számítottam.
Egyelőre a Firefox 57 (Quantum) böngészőt tesztelem elsődleges böngészőként, de ha nem válik be, akkor vissza nem Chrome-ra, hanem Chromiumra váltok.
A Kodi Git fordítását még nem próbáltam ki.
-
Frawly
veterán
Egyáltalán nem off a téma, kár offba tenni. Most kicsit utánaolvastam, de se Pepperflash, se widevine, se NaCl támogatás nincs benne, fontkezelési és hardveres gyorsítási problémái lehetnek a Chromiumnak, ennyi hátránnyal nem szivatom magam. Lehet visszaállok Firefoxra, de annál most behozták ezt a Quantumot, teljesen újraírták az egészet, szinte az összes funkciót kiszedték, addonokkal nem kompatibilis, így lehet nem leszek előrébb vele, mint egy zárt Chrome binárissal.
-
Frawly
veterán
A stable Kodi tényleg ott a tárolókban, erről elfeledkeztem. Azt viszont nem tudtam, hogy a Chrome zárt forráskódú. Helyette akkor érdemesebb lenne Chromiumot feltenni? Csak a Chromiummal az a probléma, hogy se Pepperflash, se a szükséges codecek, se lófasz nincs benne, ami a Chrome-ban benne van, meg a Chrome-os fejlesztéseket sem követi le, csak időbeli késéssel.
-
Frawly
veterán
Oké, rendben, meg fogom próbálni. Egyébként ez az egy nagyon zavar az Archban. A legjobb disztró, mindig friss csomagokkal, de sok mindenhez nincs bináris csomag, aztán lehet vele henteregni, meg forrásból fordítgatni, meg dpkgbuildezni. Azt még megérteném, ha valami kisebb szoftverről lenne szó, de a Kodi meg a bétája elég népszerű, meg pl. Chrome-hoz sincs csomag a hivatalos tárolóban, csak az AUR-ból lehet azt is fordítani. Persze Chrome-nál könnyebbség, hogy letölthető egy darab .deb csomagban, amit ki lehet bontani és portable módban használni, persze ez is körülményes, mert kézzel kell frissítgetni.
-
Frawly
veterán
válasz
vargalex
#4810
üzenetére
Saját pkgbuild szintjéig szerintem nem megyek el. Esetleg ha kézzel leklónozom a gitről, kézzel felteszem a függőségeit, és magam lefordítom, akkor nagyobb sikerre számíthatok, mint pkgbuilddel? Nekem még az sem kell, hogy feltétlenül a legújabb legyen, csak legyen legalább 18-as főverzió. Úgyis csak tesztelném első körben, lehet be sem válik.
-
Frawly
veterán
válasz
vinibali
#4789
üzenetére
Mindenképp érdemes lenne cache-t használnod, meg egy ideig megtartani a régi csomagokat is, pont azért, ha valami speciális bug miatt downgrade-re lenne szükséged, vagy elmenne a neted. Nehogy már 120-3000 gigás háttértárolók korában 3-4 gigányi csomag és pár megás csomaglista számítson, amit nem mellesleg egy pacman -Scc-vel bármikor ki tudsz üríteni, ha tényleg nincs rá szükség. Gondolom szűkre szabtad a root vagy /var partíciót, és nincs helyed, de akkor egy másik drive-on formázol egy partíciót a preferált linuxos fájlrendszeredre, és becsatolod a /var/cache/pacman alá.
Eleve nem éri meg mindent tmpfs-re tenni, ha pl. a /var/-t arra teszed, akkor a logokat is bukod, ha valami gubanc van, nem tudod őket megnézni. Nem véletlenül írtam már évekkel ezelőtt is, hogy géptől függően 25-50 gigás root partíciókat csinálok magamnak, mindenki lehülyézett, hogy túl sok, mert 10 giga és 640 KB ought to be enough for anybody. Így mindig van szabad helyem dögivel, nem töredezik a fájlrendszer vagy ha nem HDD, hanem SSD, akkor normálisan tud működni a wear leveling, plusz ha elkezdene hízni a /var (ilyen még nem történt velem), akkor sem kerülök bajba.
Pedig használok én is tmpfs-t, ramdrive-nak (böngészőcache-nek, fordításhoz cache-nek),, de csak azért, mert rájöttem, hogy a 16 giga RAM-ot ezen a régebbi notin nem tudom kihasználni, talán csak legújabb játékokkal lehetne (de azokhoz meg kéne normális dedikált videókártya is, meg egy mobil i7-esnél izmosabb proci, mondjuk egy 4 magos QM vagy HM CPU). Esetleg masszív, párhuzamosított virtuálgépezéssel. Nem nyerek ezzel sem sokat, sebességérzetre nem gyorsabb a ramdrive, mint egy közönséges SATA2-SATA3-as SSD, mármint ami az apró fájlokkal történő lemezműveleteket, elérési és töltési időket (programindulás, boot, leállítás) illeti, meg a kernel amúgy is default ramcache-el ezerrel mindenféle felcsatolt fájlrendszert és I/O-műveletet mindenféle ramdrive nélkül is. 9 giga fölé még nem mentem memóriafoglalásban (plusz a ramdrive és a kernel cache), de a 4 gigából (amivel a gép jött), abból rendszeresen kilógok, mióta Firefoxról áttértem Chrome-ra. Nem akartam ilyen köztes 8-12 gigára bővíteni, ha már rászántam az időt és a pénzt, akkor kimaxoltam a gépet, így később lelesz a RAM-kérdésről a gond, meg nem kell többé swappal ökörködni, nem mintha a kernel sokat swapolt volna kevesebb RAM-nál, épp csak belenyalt pár mega erejéig. Hibernálni sem hibernálok, SSD-nél 3 mp-es bootidővel nem éri meg, szóval az életben többet nem lesz swapra szükségem ezen a gépen.
-
Frawly
veterán
válasz
Bucsi13
#4776
üzenetére
Abban egyetértünk, hogy az Arch-os csomagfenntartók kezdenek öregedni. Jó ideje a kernel is több hetes elmaradásban követi a stable ágat, pl. a 4.13.0 stable szeptember 3-a óta kint van, de az Arch stable tárolójában még mindig 4.12.13-as kernel megy, nemrég frissült 4.12.12-ről. Érdekes módon a Fedora már frissebb, igaz az meg nem rolling. Bár lehet érdemes lenne beizzítanom végre az Arch testing tárolóit.
-
Frawly
veterán
válasz
vinibali
#4785
üzenetére
Nem ez történik. A régi verziót sem törlik a tárolóból, az a verziószáma alapján elérhető, csak tudni kell hozzá az URL-t, de azt meg a pacman cache-ből elintézi. Jól mondják, frissíts rendszeresen. Kiváltképp, ha valamit amúgy is telepítesz. Nem foglal sokkal több helyet, legtöbbször ilyen 200-1000 MB-os frissítéseknél 1-2 MB-tal nő a telepítési méret. Ha annyira kell a hely, néha ürítsd a pacman cache-t a pacman -Scc paranccsal, az letakarít neked pár gigát mindig.
-
Frawly
veterán
válasz
vinibali
#4773
üzenetére
Nem offtopik egyáltalán. De akkor is tárolóból telepítünk, akkor nem lesz verziófüggés miatti ütközés. Az Archnak pont az is a lényege a rollingság mellett, hogy friss. Nem hinném, hogy a 3.19-es SQLite annyira elavult lenne a 3.20-as helyett. Ámbár én a tárolóban úgy látom, hogy augusztus 26-a óta a 3.20-as verzió érhető el az SQLite-ból a stable tárolóban, a 32 és 64 bites csomagnak is ez a verziója. Szerintem ott rontottad el, hogy nem frissítetted a rendszert, csak pacman -S sqlite parancsot adtál ki pacman -Syu sqlite helyett.
-
#4712
Frawly
veterán
PandaMonium
#4704
Frawly
veterán
válasz
PandaMonium
#4704
üzenetére
Nem elég az AUR-ból a jre-t feltenni hozzá, mindenképp kell a jdk is? Persze a jdk is behúzza függőségnek a jre-t, de szerintem a jdk nem kell.
Kipróbáltam kikapcsolt kompozitor mellett és úgy néz ki, hogy most megjavult nálam. Nem értem, mert minden úgy volt alapból is állítva a kompozitornál, ahogy BoB screenshotján is látszik, és úgy emlékszem neki is inteles kártyája van, szóval az sem lehet különbség.
-
Frawly
veterán
válasz
Siriusb
#4695
üzenetére
Igen, KDE-t használok és Abevjavát is, és nálam sem rajzol ki egy csomó mindent. Én az IcedTea-re gyanakszok, majd megpróbálom Oracle Javával.
Néha jó, sokszor kirajzol mindent, de néhány ablakot üresen jelenít meg, és csak akkor kezdi rá kirajzolni az elemeket, ha felettük rángatom az egeret.
-
#4682
Frawly
veterán
teleahocipöm
#4681
Frawly
veterán
válasz
teleahocipöm
#4681
üzenetére
Próbáld meg Windows alól, de valószínű, hogy az egy halott pendrive. Néha feltámaszthatóak ezek valami gyári DOS-os, külön bootolós, gyári resetelős megoldással, de általában az is időpocsékolás, vágd ki a kukába, és vegyél egy újat.
-
#4668
Frawly
veterán
PandaMonium
#4665
Frawly
veterán
válasz
PandaMonium
#4665
üzenetére
AirDroidot nem ismerem, de a Google Drive-nek vannak kliensei linux desktopra. Igaz a grafikus kliensek általában fizetősek, de pl. a KDE-hez van ingyenes, amivel beépül a fájlkezelőbe, illetve vannak ingyenes karakteres felületű konzolalkalmazások is, amelyek rendesen működnek.
A legjobb Wi-Fi-n megosztani egy mappáját a gépnek, és arról lehúzni telefonnal, ami kell, illetve oda bemásolni, amit az ember a telóra szán. Sokkal egyszerűbb és gyorsabb, mint BT-ozni, meg USB-kábelt dugdosni, meg MTP-s megoldásokkal kínlódni.
-
Frawly
veterán
Nem kéne ennek ilyen bonyolultnak lennie. Igaz HP-t még nem használtam Linux alatt, csak olyan nyomtatókat használtam, amit a kernel kezelt, vagy a Project Gutenberg csomag. Azokat simán hozzá lehetett adni CUPS-ban, beállította magától, hogy automatice A4-es lapméret, fekete-fehér nyomtatás, 300 DPI-s felbontás. Semmilyen usert nem kellett semmilyen lp csoportba tenni, sem semmit tükrözni, pedig többféle disztróval is próbáltam (Mint, Kubuntu, Arch). Minden programban volt nyomtatás. Előnézeti kép csak akkor van, ha maga a szoftver is támogatja, de a legtöbb támogatja, legalábbis a legfontosabbak, pdf nézők, LibreOffice-komponensek, böngészők, képszerkesztők, képnézők.
Ha meg vezeték nélkül akarod, akkor a nyomtató menüjét mindenképp végig kell zongorázni a Wi-Fi jelszó miatt, ezt akkor is kellene, ha Windowst használnál, nem Linux-specifikus. Tölts le a nyomtatóhoz egy kézikönyvet, az fogja írni, hogy mit kell a nyomtató LCD-jén nyomkodni, milyen menükben mit kell állítani.
-
#4642
Frawly
veterán
teleahocipöm
#4640
Frawly
veterán
válasz
teleahocipöm
#4640
üzenetére
CUPS-ban a felhasználó név a linuxos felhasználói neved, amivel bejelentkezel, és a jelszó is az, amit bejelentkezéskor beírsz. Nem kell külön felhasználói fiókot és jelszót regisztrálni. Ha nem fogadná el, akkor add meg felhasználói névnek a root-ot, jelszónak meg azt a jelszót, amit sudo-nál is használsz.
HP-val nem tudok segíteni, Linux alatt még nem próbáltam. Elvileg a nyomtatóban kéne beállítani, hogy a routertől kapjon IP-t, fel tudjon csatlakozni a Wi-Fi-re. Erre a nyomtató saját menüjét kell használni, azt, ami az LCD-jén jön elő.
Mindegy, azt mindig is tudtuk, hogy vannak emberek túl sok szabadidővel 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Apple iPhone 16 Pro - rutinvizsga
- Tőzsde és gazdaság
- Építő/felújító topik
- laskr99: Processzor és videokártya szilícium mag fotók újrakezdés
- PlayStation 3
- Gitáros topic
- Nem növel telepméretet a Galaxy S26 Ultra
- Autós topik
- One mobilszolgáltatások
- Motorola Edge 60 és Edge 60 Pro - és a vas?
- További aktív témák...
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- 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.
- FSP RAIDER S 750W 80 PLUS Silver táp
- Telefon felvásárlás!! Honor 90 Lite/Honor 90/Honor Magic5 Lite/Honor Magic6 Lite/Honor Magic5 Pro
- Apple iPhone 12 Pro Max 128GB Kártyafüggetlen 1Év Garanciával
- Telefon felváráslás!! Samsung Galaxy S22/Samsung Galaxy S22+/Samsung Galaxy S22 Ultra
- Asus E510M 128GB SSD, 4GB RAM, 1 Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest