- Íme az új Android Auto!
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Samsung Galaxy Watch7 - kötelező kör
- Xiaomi 14T - nem baj, hogy nem Pro
- Samsung Galaxy A56 - megbízható középszerűség
- One mobilszolgáltatások
- A lapkakészlet és az akku különbözteti meg a Motorola Edge 60 és Edge 60 Pro-t
- Google Pixel topik
- Yettel topik
- Android alkalmazások - szoftver kibeszélő topik
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
Shyciii
veterán
válasz
vargalex
#7104
üzenetére
ARM-on biztos, de hogy az én notebookon minden csak nem erős, az tuti. Egy 130eFt-os notebookról beszélünk. Core i3...
Egyedül az 1Gbites hálókártya jó benne, meg az általam belerakott SSD (ugye anélkül nem bírna ekkora letöltést feldolgozni). Úgyhogy bár a Transmission 1 magot használ, de egy totál átlagos x éves i3-assal is lazán hozza a Digi 1Gbitjét. Szerintem ennél több nem kell. A több magos feldolgozás max akkor lenne értelmes, ha konkrétan seed szervert üzemeltetnék mondjuk 50-100 embernek. -
Shyciii
veterán
válasz
vargalex
#7095
üzenetére
vargalex
Az is tartalmaz QT-s függőségeket, tehát nekem ugyanúgy kuka.
Frawly
De milyen funkciógazdagság kell? Nekem max annyi kell, hogy beállítható legyen, hogy .torrent file betöltésekor ne indítsa el automatikusan, hogy kiválaszthassam hogy azon belül mely fileokat töltse le, és kész. Ennyi. Meg persze rendben, és gyorsan szedje le. Ennél több nekem nem kell. Nem akarok statisztikát meg ilyeneket nézni. Jöjjön le, ami kell nekem, aztán kész
CLI változatot én is kipróbáltam a böngésző miatt, de ugye böngészőt nem nyitogatok az infóhoz, pláne hogy az erőforrásigényesebb.sati
Tranmission-gtk nekem lazán hozza a 921Mbit/sec-et. A Digi-m ugye 1000Mbites, szal majdnem a teljes sebességet hozza.
-
-
-
Frawly
veterán
válasz
vargalex
#7068
üzenetére
Amit viszont a fejlesztőknek nyomon kell követni, ha arra dependelik a szutykukat. Meg az is hozzátartozik, hogy a libtorrent-rasterbar az nem így hirtelen hozta ki az új verziót, hogy csak mindenki szívinfarktust kapott, hanem általában a kijövő új verzió pár hónappal előtte már folyamatában tesztelhető git-dev ágban, pont azért, hogy előre lehessen vele tesztelni, és ne megjelenés után érjen mindenkit meglepetésként, hogy jé, nem megy.
Ezt csak azért írom, hogy ha vannak itt fejlesztésben laikusok is, akkor értsék, hogy ez nem úgy megy, hogy kijön valami új komponens, és akkor mindenki megijedve gyorsan lesöpri a fejlesztőasztalt, hogy jé, nem megy, milyen váratlan, gyorsan, hama-hama, reszeljünk rajta. Egy rendes fejlesztő mindig előre tesztel, még béta komponensekkel is, előre tart platformonként többféle dev/debug buildet, amikben már a következő komponensekkel teszteli a következő verziót. Itt az van, hogy a qB fejlesztők lusták, még kb. fél éve kihozták a stabil 4.2.5-öt, és kényelmesen hátra dőltek, az alkotás kész, a gép forog, az alkotó pihen, COVID nyári szünet, most jó, hozzá ne nyúlj, míg megy, még ránézni sem szabad, mert szemlenyomatos lesz. Most pofonként éri őket, hogy nem lett volna szabad pihengetni, fejleszteni folyamatosan kell, főleg a mai verzióhajhász/rolling világban. Aki pihenni, meg hátra dőlni akar, az keressen másik hobbit/munkát. Ilyen opensource multiplatformos fejlesztő majd csak akkor pihen, ha nyugdíjba megy, vagy épp szívinfarktus miatt tolják be a mentőbe, de ott is csak addig pihenhet, amíg töltődik a defibrillátor. Persze ennyire nincs kiélezve, egy ilyen nagyobb projekten, mint a qBittorrent is, több fejlesztő dolgozik párhuzamosan, fejlesztést megosztva. Ilyen projektnél eleve szokott lenni erre külön felelős (néha több ember), aki csak azzal foglalkozik, hogy jövőbeli dev verziókkal és komponensekkel tesztel, egyengeti az utat a többieknek. Míg megint egy másik emberke a jelenlegi stable előtti, de még támogatott stable verzióba szokta visszaportolni a jelenlegi verzió hibajavításait és feature-eit. Megint másik csak buildet csomagok meg ír alá, egy megint másik emberke a weboldalt igazgatja, megint másik a dokumentációt tartja karban, stb.. Tehát nem egy embernek kell az összes feladattal örlődni, nem is tudna, mert fizetés nélkül csinálják, abszolúte hobbiból, meg szakmai érdeklődésből, fejlődésből.
Nyilván erre az Arch csomagfenntartó is figyel, nem véletlen, hogy az 1.2.10-es libtorrent-rasterbar nem került még be az Arch stable tárolóba, csak a testingben próbálgatják egyelőre, bár erre isten igazából a staging lenne való, csak azt a lépcsőt szeretik átugrani. Én viszont bekapcsolom a testinget, mert vannak benne frissebb csomagok, és szökőévente szokott probléma lenni belőle, így nagy hátrány nem ér miatta, cserébe gyorsabban kapom meg az új feature-öket, optimalizációkat.
-
Frawly
veterán
válasz
vargalex
#7065
üzenetére
Kösz az infót, erre már nem emlékeztem, hogy az a testingből van. Kipróbáltam a nox-ot is, az is ugyanazzal a hibával hasal el. Nem fogom ennek ellenére a libtorrent rasterbart downgrade-elni, mert 1) semmi baja, 2) ez a qbittorrentesek bénasága, 3) dobni fogom a qbittorrentet egészében, amit már rég tervezek meglépni, azért is tesztelem már mellette egy ideje az rtorrentet.
Kár érte, mert a qBittorrent azon kevés programok közül való volt, amiből még GUI-sat használok, ezzel hogy ez kiesik, már csak a Termite, Goldendict, Firefox lesz az, ami GUI-s és rendszeresen használom, persze a Wine, Steam, játékok is GUI-sak, de azokat ritkán futtatom. A többi progi mind CLI-s. De annyira jó és feature-gazdag volt az qB, hogy azt eddig nem tudtam elengedni, de úgy néz ki, ennek is eljött az ideje.
-
-
Shyciii
veterán
válasz
vargalex
#6701
üzenetére
OFF
Nihhiiiincs? Én is azt hittem mikor odakerültem a céghez, aztán elkezdte sorolna a bbérügy szakértő, aki a navos oktatást is szokott tartani, hogy akkor miből is áll ez az egész, aztán 1 perc után mondtam neki, hogy köszönöm ennyi elég is, mert a felét sem értettem már. Én is azt hittem hogy van a bár, pár adó, szabadság, esetleg rugalmas munkaidő, gyed- gyes egy-két ilyen faszság, oszt kész. Hát nagyon nem
Indexelés amúgy rendben van. Mivel MSSQL-es, így egy-egy lekérdezést végig lehet monitorozni, és persze azt is, hogy melyik tábla, melyik részében tölti a legtöbb időt, de így idő után nincs tovább. Mondjuk Google Spanner-jére kíváncsi lennék, mert ott nincs ilyen gond mint a sima MSSQL, vagy MySQL-ben. Hatalmas adatokkal is könnyen elbánik. No de ennyi, mert ez mégiscsak Linux fórum -
Shyciii
veterán
válasz
vargalex
#6699
üzenetére
Sok nagyválalati program (pl bérszámfejtő közép és nagycégeknek) elég sok táblába kell széthúzni, ha azt akarod, hogy áttekinthető legyen, könnyen lehessen riportolni, és relatíve gyors legyen. Nyilván 100 tábla helyett lehetne 10 is, mert 1-2-be összevonod, viszont akkor egy hulladék lassú lesz a program. Így is szükséges módosítgatni, mert olyan cégek (ha már bérszámfejtés), amik 8000 munakvállalót kezelnek, azért ott egy-egy lekérdezés nem pér másodperc még így sem. Az már más kérdés, hogy ekkora mennyiség esetén már nem az SQL lenne jó választás, de erre már nincs ráhatásom. Ez van, ezt kell "szeretnem".
-
Shyciii
veterán
válasz
vargalex
#6697
üzenetére
Pedig nem. Többszörösen egymásbaágyazott IF függvények a saját script programhoz. Eredendően egy sorba írták (így is hosszúak az xml scriptek, hátha még mindegyiket egy sorra bontják ki), szal nekem mindenképp kell az, hogy ne kelljen folyamatosan scrolloznom.
HeidiSQL-ben meg nem szimpla lekérdezések vannak, úgyhogy az megint bukta. Olyan adatbázisokba kell belenyúlnom, amiben több 10000db tábla van... -
Shyciii
veterán
válasz
vargalex
#6695
üzenetére
Persze, el lehet. Sőt 13,3"-os kijelzőn is, csak épp a hatékony használattól távol van. Itt mindenki hazavihetett egy monitort magával.
Nálam csak a HeidiSQL programnak muszáj teljes kijelzőn mennie, mert különben az információk felét sem látom amire szükségem van, és akkor még nem beszéltem az XML kódról amit kezelnem kell, amik esetén egy sorban nem 20 karakter van, hanem sokszor 400 felett a sok egymásbaágyazás miatt. Nah ezt több sorba tördelve hogy megjelenjen kis ablakba baromi zavaró. -
Frawly
veterán
válasz
vargalex
#6557
üzenetére
Én is teljes frissítést nyomok, de most beleestem két teljes frissítés között egy ilyen felemás állapotba. Gyanítottam, hogy az újabb teljes frissítés lesz a megoldás, és így is lett.
(#6558) anorche1: terminálban kiadod az "ethtool hálózati_eszköznév" parancsot. Az eszközneved az "ip link" paranccsal tudod megnézni. Az ethtool írni fogja a Speed: résznél, hogy milyen protokollsebességgel jött létre a kapcsolat.
-
samujózsi
senior tag
válasz
vargalex
#6539
üzenetére
Itt már csak az a kérdés, hogy mi a fenének kellett az az -r kapcsoló...
Ok nélkül nem szoktam ilyesmit, de ez az egész csak egy teszt volt, hogy fel tudom-e tenni EFI-s gépre az arch alaprendszert, utána meg kipróbáltam, hogy megy-e rajta a docker.
Hogy ehhez minek kellett system user? Ötletem sincs.
A lényeg, hogy akkor legalább ilyen szinten nincs komolyabb gond vele. -
samujózsi
senior tag
válasz
vargalex
#6537
üzenetére
Biztos, hogy nem csináltam ilyet.
Mondjuk az is érdekes, hogy a usermod nem csak a user id-t írta át, de a home alatt a fájlok tulajdonosát is.Szerk: megvan egy régebbi állapota a VM-nek, -r (alias --system) kapcsolóval hoztam létre valamiért a userem, azért kapott 1000 alatti UID-t.
Hogy miért kellett a -r, azt már nem tudom. Valami oka biztosan volt, de ennek már végképp nincs nyoma a history-ban. -
Frawly
veterán
válasz
vargalex
#6527
üzenetére
Szerintem sem hw-függő. Kár volt ennyire gyorsan feladni, mert a Manjaro egy szélesebb támogatottsággal rendelkező, modernebb, gyorsabb rendszer. Már csak a kíváncsiság is hajtana, hogy megfejtsem mitől léptetett ki több böngészőben is. Amolyan becsületbeli ügy, csak azért is alapon.
Nekem továbbra is a dátumkezelés volt gyanús, hogy terminálban még mindig nem stimmelt az idő, el volt állítódva egy órával. timedatectl paranccsal rá kellett volna nézni, hogy megfelelő időzónát, megfelelő DST beállításokat használ-e, rendszeresen frissül-e az NTP idő, a hardveres óra UTC-t használ-e.
-
-
samujózsi
senior tag
válasz
vargalex
#6448
üzenetére
Arch-on még nem futottam dns problémába, de ubuntun hasonlókkal nyűglődök hosszú ideje. A dhcp ad neki egy dns-t, de lokálisan a systemd resolvert használja mindenki, az meg hol foglalkozik a dhcp-n kapott szerverrel, hol nem. Úgy tűnik, ez systemd hülyeség.
Sajnos nem emlékszem, hogy kerültem ki a dolgot, de valami systemd konfigba kellett belepiszkálnom. -
válasz
vargalex
#6442
üzenetére
Köszi!
Kellett hozzá asystemd-resolvedis, és már működik is az internetes címek névfeloldása. A helyi háló neveit valahogy nem akarja
...1 a router, ...2 a pihole DHCP-vel.
Másik gépről tudom pingelni név alapján az Arch-os gépet, de én nem tudom a helyi háló gépeit név alapján elérni. Mindenikre azt írja: Átmeneti névfeloldási hiba.
Van ötlet hogy mi kell még? -
-
#63718632
törölt tag
válasz
vargalex
#6190
üzenetére
Az amd-ucode csomag a telepítéssel jött, nem én tettem fel utólag. Most újratelepítettem ahogy Frawly ajánlotta. Lett is amd-ucode.img a /boot-ban. Beírtam az ArchLabs.conf-ba a meglévő initrd sor után az amd img-t. Mentettem, reboot és most elindult a rendszer.
Szerintem nem a sorrend volt a probléma, hanem nem volt amd-ucode.img, amit be szerettem volna tölteni.Feltételezem, hogy az ArchLabs telepítő script-jét kellene egy kicsit csiszolni, ha systemd boot kerül alkalmazásra. Akkor nem jön létre az img.
De ez így engem nem igazán zavar, hogy utólag kellett beállítani. Hiszen jó pár dolgot, service-t is utólag röffentettem be. Tudom most már erre is figyelni kell.
Közeleg nagyon az a pillanat, amikor tiszta Arch-ot fogok telepíteni magamnak. Ezek apró lépések, abba az irányba.
Köszi szépen mindkettőtöknek. -
Frawly
veterán
válasz
vargalex
#6072
üzenetére
A modern kernelekben jó pár hónapja csak a 840-es van már feketelistán, a 850-860-as szériát kivették belőle. Nekem is ubyegon mutatta.
Schyciii: nyilván nem konzumer SATA SSD-t kell virtual hostingra használni, arra valóban nem való. Arra enterprise NVMe SSD kell. De sima workstation, desktop, home felhasználásra teljesen jó a 850-860 Pro, még nagyobb fájlmásolásoknál is.
Minimalista felhasználásra, főleg desktop Linux alá, esetleg C2D és annál gyengébb gépekbe (amik jobb SSD-t nem hajtanának ki) az A400 is teljesen jó, WIn10, Linux 4-6 mp. alatt bootolni tud rajta, programok azonnal betöltődnek, ennyi a lényege, nem kell várni, míg HDD-t rotyogtat a rendszer. Csak nagy fájlmásolásokat ne akarj rajta, mert arra már nem való. Ha erre próbálod használni, akkor nagy csalódás lesz a vége, és rájössz, hogy nem volt értelme az SSD-n spórolnod, pár ezres árdiffiért vehettél volna valami jobbat. Ezért első kérdés a Milyen SSD-t veszek topikban, hogy mekkora anyagi keret van rá, és milyen felhasználásra lesz, milyen gépbe.
A400-nál attól is nagyon függ a belassulás, hogy mennyi írás van rajta, mennyire van betelítve adattal, és eleve mekkora tárhelyes modell. Ami az A400-ról nagyon hiányzik, az a DRAM cache, de annak a hiánya inkább random lemezműveleteknél látszik meg jobban.
-
Frawly
veterán
válasz
vargalex
#6064
üzenetére
Ezt tényleg nem ártana tisztázni. Van ugyanis olyan taskmanager, amit 100% terhelésnek veszi az összes mag együttes terhelését, van, amelyik többszáz %-nak (pl. négy szálas procinál 400%-ot vesznek teljes terhelésnek, 8 szálasnál 800%-ot).
Én htop-pal néztem, a CPU [Bar] oszlop van nálam bekapcsolva, ami 100%-nak veszi az összes magra számított max. terhelést. De amikor a szálaknál listázza a terhelést, meg folyamatoknál, azt viszont egy magra vetítve méri.
Még azért a proci sem lenne mindegy.
-
Frawly
veterán
válasz
vargalex
#6062
üzenetére
Jó, de itt maximumra járatott prociról beszéltünk. Az 1 magra eső terhelés nem releváns, egy 12 szálas procinál azért ne számítson a 100% egy szálra eső terhelés, mikor az csak összességében a proci ~8%-a. Persze nem azt mondom, hogy nem magas nálam is, mert egy normálisan megírt OS-nél, drivernél max. 1-2% körül kellene, hogy legyen. De az ntfs-3g-nél megszoktam, hogy bloat, annál örülni kell, hogy támogatott az NTFS egyáltalán, hacsak lehet, tartós linuxozásnál kerülni kell az NTFS partíciók használatát.
De ext4-nél valóban én is sokallom azt az 5-25%-ot (egy magra 20-100%). Amit még nem írtam: nálam titkosítás sincs (vagyis van, de az hardveres, szoftveres szint felé transzparens). Szóval nem kellene ennyinek lennie, de azért attól messze van, hogy kimaxolja a procit, meg gondot okozzon.
-
Shyciii
veterán
válasz
vargalex
#6048
üzenetére
vargalex, Frawly
Ezesetben viszont akkor sem az SSD-t, vagy a procit tartom hibásnak, hanem a szabványt, ahogyan kezeli a háttértárakat. Igaz már rég volt, de ha visszaemlékeztek, akkor a csatoló szabványa szabja meg, hogy a procit mennyire terheli (lásd régen PATA, SCSI). Ugyebár SCSI mérföldekkel gyorsabb volt anno bárminél, és másoláskor a proci 5% körül terhelődött, és lazán csinálhattál bármit mellette, míg PATA-s winyóknál lazán 10x, 15x-ös volt a terhelés a SCSI winyókhoz képest.
-
Frawly
veterán
válasz
vargalex
#6049
üzenetére
Én nem néztem rá. Igaz csak most lett nemrég AMD-s gépem, és még arra is lusta voltam feltenni Linuxot, mert mikor időm van elé ülni, Win10 alatt nyomatok rajta AAA-s játékcímeket. Pedig még a partíciós hely is meg van a Linuxnak hagyva
De emlékszem, hogy régen ki volt hangsúlyozva, hogy csak Intel procikhoz kell külön microcode csomag (intel-ucode), AMD procikhoz a linux-firmware csomag tartalmazta. Ezek szerint már 1 éve külön van, de én lemaradtam róla, mert egy darab hír sem volt róla. Aki nem veszi észre, annak elég kínos.
-
válasz
vargalex
#6042
üzenetére
Igazad van, marhaságot írtam, az SSD teszi éppen bottleneck-ké a CPU-t! Egyszóval a lassú HDD esetén nem lenne akkora a terhelés.
(#6041) Frawly
Ne röhögtess így kora reggel! Csak nem fog egyszerre ugyanazon bug egy nyamvadt elavult LTS-en meg a super ropogós rollingon is jelentkezni!
És ahogy a mester is említette, nem volt arról szó, hogy az ntfs-3g terhelné a CPU-t, csak annyi, hogy közel 100-on pörgött, de másolás közben az emberek leállítanak közben minden egyéb folyamatot? Lószart.
Egyszóval amit a kolléga tapasztalt, az maga a normál működés abban a helyzetben. Ki kell lőni a -csába a Wines fs-et és minden OK lesz.
Egyébként meg meg kéne nézni a futó processzeket cli-ben és látható lenne minden, nem kéne itt a Látóasszony topik munkáját átvenni. (gondolom, ha én 1bites Ubuntu származék használóként használom a cli-s rendszer monitorozást, akkor Archereknek ez főleg menni fog)
-
Frawly
veterán
válasz
vargalex
#6021
üzenetére
Igen, ha a terminál emulátorral vágod ki egérrel, akkor nem gond, mert akkor nem a vim küldi vágólapra, hanem a terminálemulátor. De! A vim-nek pont az az értelme, hogy gépírástartásban kapcsolgass a módok között. Ahogy kinyúlsz egérért kijelölgetni, értelmét veszti a vim, annyi erővel használhatnál gedit-et, vagy Kate-et, vagy Geany-t.
A vim-nek pont az lenne a lényege, hogy y-nal (yank) jelölj ki normal vagy visual módban. Így kijelölve viszont a garfikus felület felé nem regisztrálódik, ha nincs a vim vágólaptámogatással lefordítva. Tudom, mert szívtam miatta, meg az Arch fórum tanulsága szerint mások is szoptak miatta.
A sima vim csomag annak van, aki konzolból használja csak a gépet (nem grafikus felület + terminál kombóval), és nem akar GVim-et is feltenni, hanem a legminimalistább akar maradni.
-
Frawly
veterán
válasz
vargalex
#6015
üzenetére
Jó, de a vi sem lesz fent. Egyébként meg aki a vi-t tudja használni (mint te és én is), az meg nem vi-t fog feltenni, hanem mindjárt vim-et. Vagyis még inkább gvim-et, mert abban is van sima vim és az úgy van lefordítva, hogy működik a vágólapja a grafikus felület felé. A sima vim csomagban lévő vim-nél ez nem működik, fordítás közben lett kihagyva ez a feature. De gvim helyett lehet neovim-et is használni.
Egyébként a legkorrektebb lenne a szövegszerkesztőkre egy metacsomagot csinálnia az Archnak, editor néven. Így csak install közben annyit kellene tenni, hogy a pacstrap-nak vagy pacmannak a base linux csomagok mellé felsorolni az editor metacsomagot, és telepítéskor számozva rákérdezne, hogy melyik text editort telepítse, onnan meg mindenki kiválaszthatná magának, ami neki kell. Ez főleg kezdőknek lenne hasznos, akik nem tudják előre mit is akarnak, mi a választék.
Aki rutinos róka, az azonnal nyomatja a base linux gvim vagy base linux nano csomagokat, nem akasztja meg ez a változás.
-
Frawly
veterán
válasz
vargalex
#6009
üzenetére
Igen, valóban igazad van. Lefuttattam most egy pacman -Syy parancsot és ezután már a pacman -S base nem is metapackage-t, hanem egy szál csomagot akar tényleg telepíteni.
Viszont írja, hogy opcionális függőségnek fent van a linux: bare metal support. Ez mi a tök? Esetleg ez csak simán a kernelt jelenti?
Az sem értem, hogy akkor mi a különbség a metacsomag és a csoport között.
-
Frawly
veterán
válasz
vargalex
#6003
üzenetére
Jó tudni. LTS kernelt nem használtam még Archon, csak tárolósat meg git-eset. Azt hittem, hogy ahogy azoknál, átnevezi a meglévő kernelt, és nem lesz benne a nevében az lts.
Mondjuk nem is fogok egyhamar LTS kernelt használni Archon, az Arch lényege a frissesség. Ha LTS-re van igény, akkor másik disztró után néznék inkább. Persze teszt erejéig oké, nem is biztos, hogy megoldja a szóban forgó fordítási problémát.
-
_NCT
addikt
válasz
vargalex
#5993
üzenetére
Ezt próbáltam, sajnos nem oldotta meg. Egy egyszerű scripttel kiolvastam pacman.log fájlból hogy milyen verzióról mire történt a frissítés, és a -U kapcsoló használatával a cache-ből visszaraktam a régi csomagokat, de halott volt a dolog (segfault ugyanúgy).
Mondjuk tegnap Manjaro-val is szívtam, USB-s TPLINK adaptert használok, amely mindenféle USB descriptoros hibákat dobott. Aztán átdugtam egy másik USB portba és tökéletesen működött a rendszer. Egy USB hardverhiba okozhat ekkora galibát? Konkrétan nem működött az egerem, billentyűzetem sem...
-
attilav2
őstag
válasz
vargalex
#5947
üzenetére
Írhatnál egy systemd-boot konfiguráló shell szkriptet Arch-hoz, ami bekéri a partíciót
és már nyomja is bele a konfigba az uuid-jét. Illetve telepíti a systemd boot-ot a megfelelő(bekért) paraméterekkel. Amit most írtál azt shell szkriptként elmentem, hogy ne kelljen beírni, mert úgyis elrontom -
válasz
vargalex
#5936
üzenetére
Köszi!
Akkor rosszul tudtam.
Teljesen gyári kernelem van.
Próbáltam a wiki szerint csinálni, de nálam nincs olyan sor, hogy "works!", amikor futtatom a turn_off_gpu.sh-t. Ez a gond.vinibali: Nálam Gigabyte lapon csak az van, hogy "Init display first"; IGP, PCI-E, vagy auto.
Eredetileg PCI-E-n volt, de a másik kettőt is kipróbáltam, semmi változás nem történt. -
-
Shyciii
veterán
válasz
vargalex
#5861
üzenetére
Pont a Wiki-t olvasva kezdtem el használni, viszont a dhcpcd-vel sem ment alapból. Hibába csináltam ami a Wiki-n van, vagy ahogy írtad, bootkor nem volt net, csak ha restartoltam a szolgáltatást. Mintha előbb indult volna a kelleténél, és ezért nem volt.
Viszont most próbából megnéztem a Zen Installer-t, ami grafikusan felületen pár scripttel telepít pure Arch-ot. Ő használ Network manager-t alapból, még az nm-applet is kint van a tint2 tálcán. De mint mondtam, nekem anno semmit nem kellett állítani a Network Manageren, mert alapból kábelt bedugva kapott IP-t. Ez a gond, csak most ütközött ki nekem. Lehet hogy azóta volt változtatás rajta, mert én vagy 3/4 éve nem telepített Arch-ot, úgyhogy bármi lehet. -
Shyciii
veterán
válasz
vargalex
#5836
üzenetére
Igen, a lassúsága ami engem is zavar, főleg hogy minden más meg nagyon gyors. Geany már nem is tudom miért, de valahogy nem tetszett. Sublime jó lett volna, de a kicseszett Projekt kezelése nem akart működni, hiába olvastam tutorialokat hogy milyen egyszerű. Nekem sosem jegyezte meg. Atom-ban viszont teljesen magátólérthetően működik rendben, és pluginekkel minden megoldható ami nekem kell. Úgyhogy egyelőre marad. Aztán majd 2-3 hét múlva - mikor az egészet Arch-ot újrahúzom az UEFI-zés miatt - marad-e az Atom, az majd kiderül.
-
-
válasz
vargalex
#5758
üzenetére
Honnan találtok infót arról, hogy az egyes torrent kliensek hány magon tudnak futni?
Én pár hónapja egy épített kis négy magos (egy szálon buta) x86 NAS miatt kerestem infót, de nem találtam biztosat.
A próbálgatás pedig nem hozott eredményt, mert mindegyik csak 15-25% körül kért. -
-
Frawly
veterán
válasz
vargalex
#5557
üzenetére
Jó, most nem tudom miért kötekedtek, de tényleg. Nem a Blikkből szopom, még én is sokáig csak a yaourtot ismertem. Annyira nem vagyok fogyatékos, hogy ha oda lett volna írva rendesen a többi is, hogy azt nem próbálom ki. Meg az Arch Wiki-n kívül is egy csomó cikk a neten a yaourtot mutatja be, meg egy csomó git-es oldal, ahol említik az Arch AUR-os elérhetőséget, ott példának csak a yaourt -S csomagnév van megadva telepítési metódusként.
A népszerűségét ennek köszönheti a yaourt, nem annak, hogy kiemelkedne a többi AUR helper / pacman wrapper közül akármivel is. A többi nem volt eléggé reklámozva.
-
Siriusb
veterán
válasz
vargalex
#5537
üzenetére
Mondtam, hogy mindig a felhasználó a hülye!
Köszönöm!
(#5538) vinibali
proftpd folyamatosan megy, de azon csak a telefonom cuccait szinkronizálom belső hálón. Akartam valamit, amivel viszonylag egyszerűen tudok barátokkal megosztani (nagyobb méretű) fájlokat, ha ritkán szükség van rá. Nem is fog futni állandóan az sshd.service, nem akarok bajlódni esetleges támadások kivédésével, bár lehet továbbgondolom még.Köszi mindenkinek a segítséget!
-
Frawly
veterán
válasz
vargalex
#5503
üzenetére
Akkor lehet én csináltam rosszul, de egy időben az Arch Wiki, meg Kékluficet Arch-cikke is úgy írta, hogy tárolónak fel kell venni az archlinux.fr-t. Lehet ez egy elavult ajánlás, nem vettem észre, hogy módosították. Pedig én mindig kicsit máshogy telepítek, minden telepítésnél másmilyen rendszert építek fel, más fs, más WM/DE, más Wi-Fi-kezelő, stb..
De ez a yaourt mindig is ilyen vitatott volt, sokan már 2 éve is temették, aztán még mindig használható. De azért váltottam most már, ha ennyien óvva intenek tőle, akkor nem kockáztatok vele. Már sok helyről olvastam, hogy ajánlott lecserélni.
-
Frawly
veterán
válasz
vargalex
#5318
üzenetére
Én is főleg akkor húzok újra Archot, ha új rendszermeghajtót vagy új gépet veszek (bár a legutóbb vett SSD-mre, már tar-ral klónoztam a rendszert, nem húztam újra). Amúgy csak kétszer kellett Archot ezen kívül újrahúzni, egyszer az én hibámból, elhánytam a jogosultságokat az új user home-jában, és polkit hiba miatt behalt a systemd, nem lehetett megjavítani. A másik alkalommal meg GPU és Wi-Fi bugos működése miatt váltottam Xorg-ról Waylandre, de akkor már az ext4-ről f2fs-re váltást is megléptem. Nyilván én sem telepítem újra hetente. Nagy ritkán viszont nem lámaság újratelepíteni. Nekem sose volt szent a belakott rendszer, ellentétben itt a PH-n sok emberrel. Majd belakódik újra, meg így a legjobb tiszta lappal kezdve kipróbálni teljesen új dolgokat. Ez a jó az Archban, nem vagy kiadásokhoz meg flavor-ökhöz kötve, bármit fel lehet rá tenni, bármilyen rendszert össze lehet rá legózni.
-
attilav2
őstag
válasz
vargalex
#5272
üzenetére
/etc/hosts és /etc/resolv.conf tartalma
[attilav@attilav ~]$ cat /etc/resolv.conf
# Generated by NetworkManager
search lan
nameserver 192.168.1.1 (ez a routerem címe, ez így rendben van sztem)
[attilav@attilav ~]$ cat /etc/hosts
# Static table lookup for hostnames.
# See hosts(5) for details.
127.0.0.1 localhost
::1 localhost
127.0.1.1 attilav.localdomain attilav -
Frawly
veterán
válasz
vargalex
#5208
üzenetére
De, 8xx-es Samsungon is megy a queued TRIM, de teljesítményvesztés léphet fel, ezért nem érdemes használni. Ez csak azzal jár, hogy a mount opciók között nem szerepelteted a discard-ot.
A hiánya egyáltalán nem fájó. Bőven elég, ha az fstrim-et használod helyette, vagy fstrim systemd service engedélyezésével, vagy néha napján kézzel lefuttatva a sudo fstrim -a -v parancsot. Ezek a megoldások is rendesen TRIM-elik a meghajtót, semmi hátrány nem ér.
Fájlrendszernek XFS semmiképp. Vagy ext4, vagy f2fs. Mindkettővel van tapasztalatom. Mindkettő egyformán gyors. Az ext4 szerintem jobb, mivel az f2fs bootkor néha lassan ellenőrzi a fájlrendszert (fsck), az ext4-nél ez is villámgyors.
-
válasz
vargalex
#5165
üzenetére
A Bluestar-ban vagy a pure Arch-ban? A kérdező előbbit használja.
(#5164) Frawly
Szerintem egyformán nem kezdőbarát.
cron-ba belebarmolni, ami vagy fog menni, vagy nem.
Vagy fog menni.....öööö ezt nem értem, arra gondolsz, hogy ha ki van kapcsolva a gép, nem fut le a heti cron?
-
csixy
addikt
válasz
vargalex
#5147
üzenetére
Nem tudom zen telepítővel telepítettem arch linuxot . Nem tudom mi célt szolgál. Kodi is került bele, nem-e attól lett? Most, hogy kérdezeted Alex kutakodok a neten , de még nem jöttem rá. Vagy az AUR miatt lett?
Aha kezd derengeni.
Szóval a revenge installer készítőjét spookykidmm-nek hívják a nicknevén. -
b3Ro
senior tag
válasz
vargalex
#5056
üzenetére
Ha a gnome-ra erted a "nem szep"-et, akkor nem nincs gondom vele, szerintem eleg pofas.
Egy dolog jott elo sajnos. Apro screen tearing v screen flickering vagy minek is nevezzem. Latom, ha figyelem, es mar figyelem, mert tudom, h ott van... Felcsapom a wiki-t a kavem melle -
-
vargalex
félisten
válasz
vargalex
#4957
üzenetére
Már lemaradtam a szerkesztésről. LTS kernel esetén (4.14.18-1-lts) ez így néz ki:
gavarga@gavarga-e5540 ~ % cat /sys/module/snd_hda_intel/parameters/power_save_controller
Y
gavarga@gavarga-e5540 ~ % cat /sys/module/snd_hda_intel/parameters/power_save
0Megoldásként létrehoztam a /etc/modprobe.d/disable_audio_powersave.conf file-t a következő tartalommal:
gavarga@gavarga-e5540 ~ % cat /etc/modprobe.d/disable_audio_powersave.conf
options snd_hda_intel power_save=0[ Módosította: Intruder2k5 ]
-
vargalex
félisten
válasz
vargalex
#4956
üzenetére
Szerintem megvan a bűnös:
gavarga@gavarga-e5540 ~ % cat /sys/module/snd_hda_intel/parameters/power_save_controller
Y
gavarga@gavarga-e5540 ~ % cat /sys/module/snd_hda_intel/parameters/power_save
10Ha jól sejtem, most lett default-ban aktív. Én mindenesetre kikapcsolom, mert a munkahelyen majdnem egész nap rajtam van a fejhallgató, viszont nem mindig szól valami. Ezek a "pukkanások" pedig elég zavaróak.
-
#4948
Flowtation
őstag
vargalex
#4947
Flowtation
őstag
válasz
vargalex
#4947
üzenetére
Azt hiszem megjavítottam.
Most úgy működik, hogy bootnál már nincs failed sor, de a filekezelőben még rögtön nem elérhetőek a megosztások. Pár másodperc és jó lesz.
Ezek a változások történtek:
Fstab:noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0
és találtam egy ilyen bejegyzést az egyik manjaro fórumban:sudo systemctl enable NetworkManager-wait-online
Erre először kiírt valamit, hogy bekerült ide-oda, de kapkodtam, nem jegyeztem le. Reboot és jó lesz, bár most legutóbb csak az egyik megosztás élt, a másik kettő nem. De legalább haladok. Le tudnád írni, hogy mit csináltam, főként az első sorral?szerk: Érdekesen működik. Reboot után az a megosztás amin állt a dolphin, az jó, a másik kettő nem. Viszont ha rámegyek a másik partícióra az ssd-n (ubunu) akkor megjavul a két másik is. Ki látott már ilyet?!
-
#4946
Flowtation
őstag
vargalex
#4945
Flowtation
őstag
válasz
vargalex
#4945
üzenetére
Szia!
Megpróbáltam mindkét verziót, de nem működik. Ugyanazt a hibát kapom a filekezelőben. Viszont a systemd-s verziónál nem jelez hibát a boot során, mégse megy. Az igaz, hogy a sorba ugyanazt írtam be, mint a példában volt, természetesen a saját adatok maradtak:192.168.1.140:/export/FILM/ /home/lorinc/FILM nfs auto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0 -
#4944
Flowtation
őstag
vargalex
#4943
Flowtation
őstag
válasz
vargalex
#4943
üzenetére
Szia!
Köszi, sajnos nem működik a link. Erre gondoltál?Egyébként már próbáltam a _netdev-et, egyelőre sikertelenül. Ezt akkor a manjaroban kell az fstab-ba beírni?
A nincs hálózat egyébként igaz lehet, mivel a journal szerint pont a csatolások után jön a hálózat felépítése, ha jól láttam. -
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.
-
Istju
senior tag
válasz
vargalex
#4677
üzenetére
Köszönöm Mester:-) Te már jó pár routeres gondomat oldottad meg:-) Jó, hogy te is Archos vagy:-) Én is az lennék, de legutóbb a systemd faxszágai miatt izomból felnyomtam a manjaro openrc.t , tudom, hogy van arch openrc is, de akkor így sikerült. A rendszer azóta is hibamentes, de ha lex időm felnyomok egy vegytiszta arch linuxot:-)
-
zenwalk
senior tag
válasz
vargalex
#4403
üzenetére
a minidlna.service fajl pedig ezt tartalmazza
-
#59070464
törölt tag
válasz
vargalex
#4381
üzenetére
Sajnos en is igy tudom. Na majd este jatszok vele. Kozben az alabbiak arra utalnak, hogy nem a mobilnet es nem a 722N lesz a hiba oka, mert
Errol a szerverrol (ami egyebkent baromi lassu ertheto okokbol):
37 # Location: Los Angeles, CA, USA
38 # Responsible: 4096R/C3F4FFCF3EAE8697 Luke R. <g4jc@openmailbox.org>
39 # Work hours: 24*7
40 Server = http://server2.goodgnus.com.ar/$repo/os/$archEzt kapom:
error: python: signature from "Felix Yan <felixonmars@gmail.com>" is invalid
:: File /var/cache/pacman/pkg/python-3.5.2-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)).Errol a szerverrol (ami nyilvan gyors):
42 # Location: London, UK
43 # Responsible: Parabola Project
44 Server = http://repo.parabola.nu/$repo/os/$archEzt kapom:
error: failed retrieving file 'python-3.5.2-1-x86_64.pkg.tar.xz' from repo.parabola.nu : SSL read: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac, errno 0
warning: failed to retrieve some filesKet eltero hiba ugyanazokkal az eszkozokkel inkabb szerver problemaval hozhato ossze. Vagy valami egeszen massal. Azert a korabban beszelt teszteket kesobb ugyekszem megcsinalni.
Egyebkent az /etc/pacman.d/mirrorlist szerkesztese utan pacman -Syy, majd pacman -Scc es utana pacman -S speedtest-cli
-
#59070464
törölt tag
válasz
vargalex
#4379
üzenetére
Egyelore nem tudok terminal-bol csatlakozni rejtett SSID-hoz.
A halado topicban nem jott ra valasz, akkor mar itt is probat teszek. Nem rejtett WPA2 PSK-hoz igy csatlakozok:
wpa_supplicant -B -i interface -c <(wpa_passphrase SSID passphrase)Egyebkent nem mindig gyanakszom mobilnet hibara, mert van eth-el is PGP signature hibam. Mondhatni random, nem tudom egyertelmuen megmondani. Viszont az biztos, hogy a repo sync a community.db-re mindig valami SSL read(?) hibat dob. E vegett mar inkabb gyanakodnek mobilnet hibara. Tovabb kellene szukiteni a kort es eloszor csatlakozni valahogy a 722N-el rejtett 1043-hoz, aztan meg USB tethering mobilnettel.
-
Egyedül az 1Gbites hálókártya jó benne, meg az általam belerakott SSD (ugye anélkül nem bírna ekkora letöltést feldolgozni). Úgyhogy bár a Transmission 1 magot használ, de egy totál átlagos x éves i3-assal is lazán hozza a Digi 1Gbitjét. Szerintem ennél több nem kell. A több magos feldolgozás max akkor lenne értelmes, ha konkrétan seed szervert üzemeltetnék mondjuk 50-100 embernek.
Új hozzászólás Aktív témák
Hirdetés
BoB- Apple asztali gépek
- Íme az új Android Auto!
- AMD vs. INTEL vs. NVIDIA
- Futás, futópályák
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Synology NAS
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- Bluetooth hangszórók
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- A fociról könnyedén, egy baráti társaságban
- További aktív témák...
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Lenovo S10-2 Intel Atom retró csajszis netbook eladó
- ÁRGARANCIA!Épített KomPhone i5 10600KF 16/32/64GB RAM RX 6600 8GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X 16/32/64GB RAM RX 7600XT 16GB GAMER PC termékbeszámítással
- Csere-Beszámítás!AMD Asztali számítógép PC Játékra! R5 5600/ RX 6700XT 12GB / 16GB DDR4 / 500GB SSD
- BESZÁMÍTÁS! MSI B450M R5 5600 16GB DDR4 512GB SSD RTX 3060 12GB THERMALTAKE Core V21 Enermax 650W
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged