-
GAMEPOD.hu
Arch Linux topik
Új hozzászólás Aktív témák
-
Sonja
veterán
válasz anorche1 #5327 üzenetére
Az automatikusan induló alkalmazásokhoz létrehozol egy bejegyzést, ami a következő parancsot tartalmazza:
xinput set-prop 'Logitech Gaming Mouse G400' 'libinput Accel Speed' '-1'
Értelem szerűen a Logitech Gaming Mouse G400 helyett a te egered neve kell. Így minden indítás után kikapcsolódik az egér gyorsítása, ahogy nálam is.
Ha csalódni akarsz, bízz az emberekben!
-
anorche1
őstag
válasz anorche1 #5405 üzenetére
Ha a kde system settingsben a display and monitor/compositorban a rendering backend et atrakon opegl 3.1 vagy 2.0 rol xrenderre, akkor megszunik a problema. Jelent valami hatranyt, ha xrenderen haszanalom openglhez kepest?
"It never gets easier, you just go faster." Greg LeMond
-
vargalex
félisten
válasz anorche1 #5601 üzenetére
Arch linux alatt nem "divat" a fejlesztéshez szükséges header file-okat (azért kell neked, mert valami saját alkalmazást akarsz készíteni?) külön devel csomagba tenni. Az alap csomag része:
[gavarga@gavarga-e5540 ~]$ pikaur -Ql openmpi | grep ".h$"
openmpi /usr/include/mpi-ext.h
openmpi /usr/include/mpi.h
openmpi /usr/include/mpi_portable_platform.h
openmpi /usr/include/mpif-c-constants-decl.h
openmpi /usr/include/mpif-config.h
openmpi /usr/include/mpif-constants.h
openmpi /usr/include/mpif-ext.h
openmpi /usr/include/mpif-externals.h
openmpi /usr/include/mpif-handles.h
openmpi /usr/include/mpif-io-constants.h
openmpi /usr/include/mpif-io-handles.h
openmpi /usr/include/mpif-sentinels.h
openmpi /usr/include/mpif-sizeof.h
openmpi /usr/include/mpif.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/comm.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/comm_inln.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/constants.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/cxx_glue.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/datatype.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/datatype_inln.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/errhandler.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/errhandler_inln.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/exception.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/file.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/file_inln.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/functions.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/functions_inln.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/group.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/group_inln.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/info.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/info_inln.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/intercomm.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/intercomm_inln.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/intracomm.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/intracomm_inln.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/mpicxx.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/op.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/op_inln.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/request.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/request_inln.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/status.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/status_inln.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/topology.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/topology_inln.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/win.h
openmpi /usr/include/openmpi/ompi/mpi/cxx/win_inln.h
openmpi /usr/include/openmpi/ompi/mpiext/affinity/c/mpiext_affinity_c.h
openmpi /usr/include/openmpi/ompi/mpiext/cuda/c/mpiext_cuda_c.h
openmpi /usr/include/openmpi/ompi/mpiext/pcollreq/c/mpiext_pcollreq_c.h
openmpi /usr/include/openmpi/ompi/mpiext/pcollreq/c/pmpiext_pcollreq_c.h
openmpi /usr/include/openmpi/ompi/mpiext/pcollreq/mpif-h/mpiext_pcollreq_mpifh.h
A pvm egy elég régen módosított aur csomag. A gondja az, hogy nincs rpc/types.h header file (azaz /usr/include/rpc/types.h). Ha jól sejtem, ez most már a libtirpc csomag része lett. Így a fordításnál a /usr/include/tirpc-t kellene include-olni.
[ Szerkesztve ]
Alex
-
Lenry
félisten
válasz anorche1 #7418 üzenetére
ebbe én is belefutok mindig, amikor új gépre rakom fel az Archot.
első körben fusd át a Wiki idevonatkozó részeit
Font configuration
Firefox#Font troubleshooting
Rondák a betűk a Feuerfuchsban[ Szerkesztve ]
Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
Frawly
veterán
válasz anorche1 #7421 üzenetére
Ja, feltűnően gyors, a jóhoz meg könnyű hozzászokni. Meg frissebb is, mint a Manjaro, ez is előnye. Pedig a Manjaro is relatíve új verziós csomagokat használ a disztrók többségéhez képest, meg nem olyan lassú, főleg, ha pl. Debian/Ubuntu-alapú disztrókkal hasonlítod össze. Pl. a pacman már régóta a leggyorsabb csomagkezelő (pl. a függőségi fát is nagyon villámgyorsan állítja össze a többi csomagkezelőhöz képest), de mióta zstd-csomagtömörítésre álltak át, azóta meg valami hihetetlen dimenzióban veri az összes többit. Főleg mikor mutatod Windows usereknek, hogy Archon mennyi egy terminálos pacmanos rendszerfrissítés (átlagos, de nagyobb), kb. 1-2 perc (jó, netsebességtől függ), abból a letöltést leszámítva a tényleges telepítési idő kb. 5-10 mp. SSD-n, nem hiszik el, mert ugyanez Windowson tart SSD-vel is 10-30 percig, mármint egy hasonló kaliberű frissítés.
A pacmant jelenleg csak az inteles Clear Linux csomagkezelője veri sebességben, de az csal, nem egész csomagokat tölt le és telepít, hanem csak a csomagok közötti deltát, különbségeket tölti le, telepíti, így nagyságrenddekkel kevesebb adatot kell megmozgatnia, eleve letölteni is sokkal kevesebb, és ez utóbbi a szűk keresztmetszet.
Pont tegnap este olvastam egy másik fórumot, hogy az userek mint szenvednek egy nem is olyan új Ryzen mobil APU-ba épített AMD IGP driverrel (meg itt ezen a fórumon is egy régi AMD R9 GPU-val), Ubuntu meg Debian alatt, mindenféle PPA-kal, meg backports kernellel vergődnek, Arch-alapú disztrón meg minden alapból van annyira friss, hogy ez nem gond (simán megy DXVK, Proton, stb.), meg a forráskódból pörgetés sem, mert rendelkezésre állnak a legújabb dev csomagot, nem úgy, mint Ubuntun, hogy csak x verzióval előttiek. Főleg akkor sajnálom ezeket a usereket, amikor ilyen Stockholm-szindróma mentén védik a megszokott disztrójukat, amit csak megszokásból használnak, hogy de jó, az ő disztrójuk enterprise grade, meg stabilabb, meg LTS, meg mit tudom én mennyivel hosszabb támogatási idő, meg release party-t is tartottak a legutóbbi kiadás megjelenésekor. Ja, támogatottabb meg stabilabb. Lenne, ha menne rajta az, amit futtatni akarnának, és nem kéne vergődni vele. Közben meg mi tudjuk, hogy a gyakorlatban az Arch-vonal a full rolling létére semmivel nem instabilabb, sőt, még azt is megkockáztatom, hogy kevesebb a probléma vele, mert Ubuntun, Minten előfordul olyan, hogy frissítés után nem bootol a GRUB, meg drivergebasz vagy rossz X.org konfig miatt nem tölt be a grafikus felület, meg disztrófrissítést nem él túl az a nagyon stabil rendszer (pl. mikor 18.04-ről 20.04-re frissítenek), ilyenbe Archon sose futottam bele, hogy egy rendszer frissítés után ilyen teljesen elemi szinten boruljon meg. Volt, hogy 1-2 csomag telepítése-frissítése hibával meghiúsult, meg 1-2 alkalmazás frissebb verziója crashelt vagy kisebb bug fordult elő vele (semmi mission critical), de ezekre is mindig van gyorsan közzétett instant workaround (downgrade, upgrade még frissebb AUR-os gites verzióra, konfigfájl átírása vagy újragenerálása, pacman átparaméterezése, felesleges fájl vagy rossz symlink kézi törlése, jogosultsági probléma kézi kiigazítása), meg nagyon gyorsan jön a javító frissítés is, néha még órák sem telnek el közötte, így aki nem pár óránként frissítőmániás, mint én voltam régen, az javarészt bele sem fut még ezekben sem, mert mire rendszerfrissítést indít el, már a javított csomagok települnek neki, persze ilyen javított csomag is évente olyan kevésszer fordul elő, hogy egy kezén megszámolja ezeket az ember, lásd. archlinux.org News szekciója, és bár ott nem írnak minden ilyenről, de nincs lényegesen több incidens azoknál, amik fel vannak ott tüntetve. Ennyit a nagy instabilitásról.
-
Lenry
félisten
válasz anorche1 #7426 üzenetére
nem kell a discard az fstabba
Arch-on a systemd hetente intézi a discardot (periodic trim), így nincs szükség a folyamatos trimet kapcsoló fstabos megoldásra.
ez ilyen vagy-vagy dolog, nem érdemes mindkettőt bekapcsolnia relatime-ot is hagyhatod, mára az az alapértelmezett beállítás, lényegesen kevesebb terheléssel jár, mint a régi atime, de megmarad a funkcionalitás, amit a noatime-al elvesztenél
[ Szerkesztve ]
Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
Frawly
veterán
válasz anorche1 #7423 üzenetére
Beleteheted a discardot, ha akarod. A kolléga félig írta csak jól, Archon van fstrim systemd service, azzal is működőképes (ilyenkor nem kell discard), de figyelni kell, hogy alapból az sincs bekapcsolva, neked kell systemctl enable fstrim segítségével bekapcsolni, részletekért lásd a belinkelt Arch Wiki cikket. Tehát vagy-vagy módszer, rád van bízva melyik szimpatikus, melyiket használod, discard mount opció vagy fstrim service. Az SSD TRIM-ezését bármelyik megcsinálja normálisan. Mindegy melyiket választod, elég annak futnia, nem kell a kettő párhuzamosan.
#7423 anorche1: rossz hírem van, ezt nem tudja. Még a Delphinnél sokkal komolyabb fájlkezelők sem, mint a Double Commander Qt, vagy Krusader vagy hasonló kétpaneles fájlkezelők, amiket mégis élből jobban ajánlok. Ha zavar ez a rendezési mód, át kell nevezned az 1 nevű fájlokat 01-re, a 2-es nevű fájlt 02-re, erre vannak tömeges átnevezési módszerek regexp alaján, szintén lásd pl. Double Commander. Én erre Vifm + vim megoldást használok, de lehetne shell scriptet is írni, ami ls | grep | mv segítségével nevezi át.
[ Szerkesztve ]
-
vargalex
félisten
válasz anorche1 #7441 üzenetére
Nem lehet, hogy ez éppen egy bug az aktuális verzióban és a Manjaro-ban egy régebbi található? Több bug-ot is láttam ezzel kapcsolatban, pl. ezt. Ennél azt írja, hogy Natural sorting beállítás nem jut érvényre azonnal, hanem csak akkor, ha újra megnyitod a beállítások ablakot.
[ Szerkesztve ]
Alex
-
Lenry
félisten
válasz anorche1 #7445 üzenetére
"bash color prompt"
erre keress rá, de ez külön művészeti ágegyébként a
~/.bashrc
PS1
kezdetű sorát kell izgatni
én pl a legtöbb gépen más színt igyekszem beállítani, hogy ezzel is elkülönüljenek, ha több gépre vagyok belépve, illetve nálam a root promptjában aroot
(usernév) általában piros.Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
Frawly
veterán
válasz anorche1 #7452 üzenetére
Animációkat javaslom akkor is kivenni, ha szereted a csilivilit, mert lassítják a grafikus felület reakcióidejét. Nem a hardverigény növelése miatt, vagyis nem csak amiatt, hanem mert az animációs időt mindegy milyen kicsi értékre veszed le, valamekkora lagot okozni fog. Egy kis wobbly windows meg leállási anim effekt belefér, de pl. programok megnyitásánál, bezárásánál, váltásánál, meg a dokknál, menüknél, alkalmazásindítóknál nem éri meg használni. Jelenleg az Openbox + picom kompozitor is tudna pl. fade effekteket, de kikapcsoltam, mert mikor hirtelen alkalmazást vagy desktopot váltok, akkor nem volt azonnali a váltás.
Ugyanez a helyzet a simított görgetéssel, néhány progi azt is tudja, hogy ha darabonként görgetsz, akkor is lagot okozva, kicsit tovább, lassítva görgeti a tartalmat, és a darabos görgetési mozgások kiegyenlítődjenek, de ez meg idegesítő, mikor hosszú doksiban pozicionál az ember, és szeretne azonnal a doksi egy adott részére ugrani, és ez a csilivili effekt megnöveli a reakcióidőt.
[ Szerkesztve ]
-
anorche1
őstag
válasz anorche1 #7456 üzenetére
Vegul az lxqt mellett dontottem. Tetszik. Egy kerdesem lenne. Hogyan tudom qt -s alkalmazasoknal (qbittorent) dark semat, colort hasznalni?
Meg egy:
KDE alatt, ha a laptop funkcio billentyuivel allitom a fenyerot, akkor lehetosegem van teljesen kikapcsolni azt. Itt hozza tudok adni egy 0 fenyeros beallitast?[ Szerkesztve ]
"It never gets easier, you just go faster." Greg LeMond
-
Frawly
veterán
válasz anorche1 #7457 üzenetére
Az LXQt sem rossz, esetleg Openbox. Képernyő fényerejét többféleképp is le lehet venni 0-ra, vagy xbacklight vagy hasonló backlight alkalmazással 0 fényerőt megadni paraméternek (lásd man), vagy kiadni a xset dpms force off parancsot, vagy ezt hozzárendelni egy billentyűhöz.
A minimalistább WM-ek csicsásításához pedig picom kompozitort érdemes használni, ami tud vsyncet, átlátszóságot, átlátszó elmosottságot, árnyékokat, ki/behalványodási effektet, ár az LXQt-nek lehet van saját beépített kompozitora, mert az nem csak egy WM, hanem egy komplett DE.
-
Frawly
veterán
válasz anorche1 #7460 üzenetére
Octopi-t sose használtam. Ha találgatnom kéne, akkor terminálból megkap valami parancssori opciót, amit a dmenu nem nyújt neki, és ennek hiányában nem fut. Terminálból is csak így egymagában hívod meg, egy parancsként, semmi kapcsoló mögötte? Esetleg terminálból indítva a megfelelő jogosultsággal indul, míg dmenu-ből indulva nem.Pamac nem jó helyette? Vagy a terminálos octopi parancsra csinálsz egy gyorsbillentyűt?
Ahogy olvasom, a PCmanFM-qt-ben nem lehet letiltani ezt a smooth scrollt. KDE alatt le lehet, de ebben a fájlkezelőben nem. Ez elég ostoba volt részükről, beletenni egy megkérdőjelezhető feature-t, és nem kikapcsolhatóvá tenni. Pedig nem is azért írtam, mert LXQt alatt bele fogsz futni, erről a smooth scrollingról még a KDE kapcsán tettem csak említést.
Egyébként ha nem ragaszkodsz az egész Qt-ökoszisztémához, akkor lehet az LXQt alapjául szolgáló Openbox-ot is futtatni, picom kompozitorral (és mondjuk tin2 vagy polybar panellel), és Gtk3 alkalmazásokkal, pl. a PCmanFM-nek van Gtk-s változata, abban nincs smooth scrolling.
Eset
[ Szerkesztve ]
-
Lenry
félisten
válasz anorche1 #7506 üzenetére
ha nagyon zavar, akkor AUR-ból mindháromhoz van firmware
aic94xx-firmware
wd719x-firmware
upd72020x-fwGvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
Frawly
veterán
válasz anorche1 #7506 üzenetére
Ezzel nem kell foglalkozni. Még 10 évvel ezelőttről benne maradt ez a debug üzenet az mkinitcpio scriptben, és mindenkinek kiírogatja ezt. Ha nem használod ezt a felsorolt 3 hardvert konkrétan, akkor hagyd figyelmen kívül.
#7509 Siriusb: ilyet néha nálam is csinál, mármint nem a KDE, hanem mindenféle disztró, mindenféle felülettel, meg androidos telóval is. Ilyenkor néha a router nem tudja újraépíteni a WAN kapcsolatot, és azért érzi úgy, hogy bejelentkezés kéne. Vagy indítsd újra a routert, vagy a webes felületére lépj be.
-
Lenry
félisten
válasz anorche1 #7539 üzenetére
a Windows alatt jobb nem piszkálni, ő akkor is használja, amikor te nem akarod, és hülyébbnél hülyébb hibákat képesek generálni a legkülönfélébb szoftverek, ha nincs swap.
Linuxon tényleg fölöslegessé tud válni, ha kellően sok RAMod van. cserébe nyilván neked kell figyelni, meg homlokon csapni magad, amikor az OOM killer elkezdi kilőni a programjaidat.
jah meg swap nélkül nincs HibernálásGvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
Frawly
veterán
válasz anorche1 #7539 üzenetére
Igen, swapnak mindig is az volt a haszna, ha elfogy a memória, akkor se menjen le hídba a rendszer, hanem kilapozza a memóriát lemezre, és legyen újra valamennyi szabad memória. Nagyban függ attól, hogy jelenleg mennyi memória van a gépedben, meg mi a felhasználásod. Ezt neked kell nézni, gyakran előszedsz egy feladatkezelő-jellegű progit, megnézed, hogy mennyit használ a swap-ból, mennyi szabad a RAM-ból, ha bőven van mindig szabad memóriád, és a swapot vagy nem használja a rendszer, vagy csak kicsit, akkor neked nem fog kelleni. Kb. 4 GB RAM-ig van rá szükség. 8 GB határeset, felhasználásfüggő, pl. a futtatom a Chrome-ot 1000+ füllel és mellette állnak az Electron app hegyek és megnyitott komplett LibreOffice és hasonló bloat dolgok, akkor lehet még 8 gigához is kell. Ha viszont van 12-16 giga RAM-od, vagy csak 8, de minimalistább Linux rendszert használsz (csak egy WM, meg pehelysúlyúbb alkalmazások, mint Firefox, mpv, stb.), akkor átlag felhasználás mellett nem nagyon kell swap. Ezt csak ökölszabálynak írom, nem mindenkire igaz, ezt neked kell ellenőrizni.
Én 8-16 GB RAM-nál már Windowsban is mindig kikapcsoltam. Ja, rinyál, hogy nem kéne, de utána beveszi, és még sose hiányzott. Bár Windowsnál azért kell jobban, mert annak szarabb a memóriakezelése, kevésbé hatékonyan ossza be a memóriát, az jobban töredezik (ki nem használt memórialap tartományok ékelődnek kihasználtak közé), de nem kötelező, ott is meg lehet nélküle lenni. Nagyban függ, hogy ki mennyi programot futtat egyszerre, miket telepít és futtat, mennyire lusta bezárni futó dolgokat, és hogy mire használja a gépet.
-
Frawly
veterán
válasz anorche1 #7961 üzenetére
A --efi-directory nem jó, annak is a /mnt/efi-t adjad meg. Elvileg úgy jónak kéne lennie. A másik, ami előfordul, hogy egyes Acereknél az UEFI nem szabályos, csak Windows only bootra van fixen bedrótozva, hogy bootkor a Windows bootmgfw.efi fájlát akarja bebootlni név szerint. Ez kikerülhet az alábbi parancs kiadásával:
cp $MOUNTPOINT/EFI/grub/grubx64.efi $MOUNTPOINT/EFI/Microsoft/Boot/bootmgfw.efi$MOUNTPOINT helyett nyilván azt adod meg, ahová felcsatoltad. Bár az is furcsa, amit írsz, hogy /mnt-be csatolod, az EFI partíciót /boot-ként szokásos felcsatolni.
Másrészt, ha sima UEFI és ext4 partíciók, semmi titkosítás, RAID, LVM bonyolítás nincs, akkor systemd-bootot is használhatsz, az egyszerűbb, és nem kell hozzá GRUB sem.
-
Shyciii
veterán
válasz anorche1 #8086 üzenetére
Én ezeket raktam fel (Xorg lés intel driver)
xorg-server, xorg-xinit, xorg-fonts-encodings, xorg-mkfontscale, mesa, xf86-video-intel, intel-media-driver
Ez utóbbi viszont videókártya függő. Arch wiki ír is róla:
- HD Graphics series starting from Broadwell (2014) and newer are supported by intel-media-driver.
- GMA 4500 (2008) and newer GPUs, including HD Graphics up to Coffee Lake (2017) are supported by libva-intel-driver. -
Shyciii
veterán
válasz anorche1 #8098 üzenetére
Van egy ilyen sorod:
URxvt.font: 9x15,xft:TerminessTTFNerdFontMonoEzt változtasd meg mondjuk 11x17-re, vagy 13x19-re, vagy akár még nagyobbra.
De amúgy nemigazán értem, mert ez urxvt-t feltételez, te viszont xterm-et írtál. Szerintem az xterm ezt használja:
XTerm.vt100.font: 9x15
Ilyen sorod viszont nincsen. Nem lehet, hogy nem xterm-et használsz, hanem urxvt-t?[ Szerkesztve ]
-
anorche1
őstag
válasz anorche1 #8101 üzenetére
Okes, osszeraktam a kepet, sikerult megcsinalni, koszonom
Akadt megy problemam. Vsyncet hogyan tudom bekapcsolni? picom -ot feltelpitett, szepen fut, transperency, fading, minden mukodik, de hiaba van a vsync bekapcsolva, nem segit.
etc/X11/xorg.conf.d/20-intel.conf -ban be van kapcsolva a tearfree, de ez sem segitett.
Szerk.:
Kozben ez i meglett:
picom configban kellett az xrendert glx -re atirni[ Szerkesztve ]
"It never gets easier, you just go faster." Greg LeMond
-
-
Shyciii
veterán
válasz anorche1 #8109 üzenetére
Picom kevés ehhez. Videókártyától függően egyéb beállítások is szükségesek. Arch wikiben írnak erről mind intel, mind nvidia terén. Nekem pl ez kellett, hogy ne essen szét a kép, de közben megmaradjon a hardveres gyorsítás intel alatt:
:
/etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "AccelMethod" "sna"
Option "TearFree" "true"
Option "TripleBuffer" "true"
EndSection -
Shyciii
veterán
válasz anorche1 #8119 üzenetére
Szívesen :)
i3-hoz használsz valamilyen login managert? Pl lightdm, lxdm, gdm stb? Mert ha nem, akkor meg is van a probléma forrása, ugyanis a teamvieweres bagázs úgy gondolja, hogy a linuxot már csak úgy támogatja, hogy ha használsz login managert. Aki nem, az meg b.ssza meg szerintük.
[ Szerkesztve ]
-
Shyciii
veterán
válasz anorche1 #8121 üzenetére
Amúgy ha ragaszkodnod kell a Teamviewerhez, akkor lehet az a megoldás, hogy az Arco linux repoját felveszed, és ebből a repoból teszed fel a Teaviewert, ugyanis Erik Dubois megoldotta azt, hogy login manager nélkül is menjen. Legalábbis nekem ezt mondta mikor erről leveleztünk....