- iPhone topik
- Vodafone mobilszolgáltatások
- Telekom mobilszolgáltatások
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Eleglide C1 - a középérték
- Milyen okostelefont vegyek?
- Android szakmai topik
- DIGI Mobil
- Android alkalmazások - szoftver kibeszélő topik
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
Hirdetés
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
A legtöbb amerikai szerint a TikTok egy őket befolyásoló eszköz
it Egy felmérés szerint a legtöbb amerikai osztja azon véleményt, hogy a TikTok egy őket befolyásoló eszköz.
-
Snapdragon 8-as szériával várhatók a Honor 200-ak?
ma A Honor 200 állítólag a 8s Gen 3-at, a 200 Pro változat pedig a 8 Gen 3-at használja majd.
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
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ő.
[ Szerkesztve ]
-
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.
-
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
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.
-
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.
[ Szerkesztve ]
-
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.
[ Szerkesztve ]
-
Frawly
veterán
Arch alatt hogy oldható meg, hogy az állandóan töltőről hajtott laptop csak 99%-ig töltse az akkut, utána állítsa le a töltést? Windows alá vannak ilyen toolok, de Linuxnál fogalmam sincs hogy lehet ezt megvalósítani.
-
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.
[ Szerkesztve ]
-
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 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 #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
Csak hogy ne pangjon a topik: Archra 18-as Kodit honnan érdemes szedni? Az AUR-ban lévő gites verzió nem fordul le, a Kodi tárolói meg debianos/ubuntus tárolók. Netflix 1080p nézéséhez kéne. Külön LibreELEC-et bootolni állandóan körülményes.
-
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
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
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
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
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.
[ Szerkesztve ]
-
Frawly
veterán
Jó tudni. Viszont egy ilyen parancsot félve adnék ki, mert van fent pár AUR-os csomag, és elkezdi nekem mindegyiket újra letölteni, forráskódból forgatni, tökön szúrom magam, még i7-en is órákat tartana.
-
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
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
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
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
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.
[ Szerkesztve ]
-
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
-
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
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
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
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
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
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
Folytatva a szokásos monológköreimet:
Az NVIDIA befejezi a 32 bites operációs rendszerek támogatását -
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
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
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.
[ Szerkesztve ]
-
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.[ Szerkesztve ]
-
Frawly
veterán
-
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
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.
[ Szerkesztve ]
-
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
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 #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 #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.
[ Szerkesztve ]
-
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.
Új hozzászólás Aktív témák
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! LEGOLCSÓBB! Automatikus 0-24
- Steames kulcsok jó áron eladóak!
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Canva Pro előfizetés - 1 éves