Meh, mai nap folyamán kétszer fagyott csontra a Manjaro... úgyhogy egyelőre 5.4-es kernel+nouveau lesz, aztán majd meglátjuk.

Az a nyomorult snap sem akar működni update után, cannot attach cgroup program: Operation not permitted hibaüzenetet dob. Egyetlen egy snap programom van (illetve már csak volt), az is csak azért, mert az AUR-os változat nem fordult le. Most viszont lefordult, a snap-os változatból átmásoltam a config fájlt, a snaptól pedig megszabadultam, remélhetőleg egyszer és mindenkorra.

Jó hír ellenben, hogy a GNOME Kapcsolatok végre tud csatlakozni a céges Windows-os gépemhez.

[ Szerkesztve ]

Nem Ryzenes gép véletlen?

Nem, egy i5.
Amúgy arra már rájöttem, hogy az AUR-ból telepített Anydesk miatt fagy a gép. Tegnap feltettem Flatpakból, egyelőre jónak tűnik.
Ettől függetlenül propriertary driverrel továbbra sem hajlandó visszatérni a monitor kikapcsolt állapotból. Illetve a több verzió óta használt x11vnc sem megy, eddig gond nélkül működött, a frissítés óta hibával leáll.

Hát nem tudom. Nekem furcsán gördülékeny most minden.

Nekem eddig volt furcsán gördülékeny
Sosem volt semmi problémám egyik frissítésnél sem.

A laptopomon egyébként minden működik, pedig azon is friss Manjaro Gnome van, sőt abban is egy i5-ös proci van. Igaz, abban Intel UHD van csak, nem Nvidia, és azon az x11vnc-t sem használom. De mondjuk az Anydesk is megy probléma nélkül.

Nagyon nagy szívás ez a grafikus driver dolog. Hát hiába ez az oprendszer nem desktopra lett kitalálva.

Ilyenek minden operációs rendszer alatt előfordulnak. A múltkor a munkahelyemen 6 dolgozói gépről kellett eltávolítanom KB5005566 számú frissítést, mert az egyik (de csak az egyik!) nyomtatóval nem tudtak nyomtatni. Ha ráküldtek bármilyen nyomtatást, a program két másodperc alatt csontrafagyott.
Volt olyan, hogy az egyik backup DNS gépünk tökéletesen ment a Windows Server 2012-vel, a 2016-tal is, a 2012 R2-vel viszont folyamatosan teljes fordulaton zúgott.
Aztán nem is olyan rég az egyik Intel driverben volt valami bug, ami miatt kékhaláloztak a Windows 10-es gépek.
Az x11vnc-s problémát meg tudtam oldani úgy, hogy az /etc/gdm/custrom.conf-ban a WaylandEnable=false sor elől kivettem a komment jelet, így most Xorg session-ben vagyok, nem Xwayland-ben. Ezt már korábban megcsináltam, de úgy látszik, a frissítés felülírta.
Ami viszont érdekes, hogy a laptopon is Wayland-ben vagyok, ott pedig simán kiírja az x11vnc, hogy "Wayland display server detected...".

Az NT alapú Windowsok, amik desktopra lettek kiadva (tehát Windows 2000-től fölfelé) sem asztali rendszernek készültek, arra ott volt a Windows 9x vonal.

Sziasztok . Szeretnék rnedet tenni a fejemben a sok csomagkezelő / pacman , pamac , octopi, yay , AUR , meg még asszem van kettő / közt .

Ha valaki elmagyarázná röviden , mi micsoda és mire jó , megköszönném . :-)

A pacman az Arch-tól örökölt csomagkezelő. Ez tud a hivatalos repókból letölteni csomagokat, főleg bináris csomagokra használjuk, de tud forrásból összeállítani és fordítani. AUR-t nem tud kezelni.
A pamac a Manjaro saját csomagkezelője. Alapvetően ugyanúgy a libalpm-et használja, és alapvetően ugyancsak arra használjuk, hogy a bináris csomagokat leszedjük a hivatalos repókból. Ez annyival okosabb a pacmanál, hogy tud még AUR-ból is fordítani és telepíteni.
Van grafikus felülete, a pamac-manager paranccsal indul (amúgy külön van GKT-hoz és külön QT-s GUI, a pamac-manager azt indítja el, amelyik telepítve van) , és még értesítési ikonja is van (pamac-tray).
Az Octopi is csak egy grafikus felület. Egyes Manjaro disztrókon (pl. a Manjaro Xfce-n) ez van a pamac-manager helyett. Amiért jó, mert tud több AUR helpert is kezelni, trizent, yay-t, pacaurt...

A yay, a trizen, a pacaur, a paru és a többi, ezek mind AUR helperek. Arra valók, hogy AUR-ból tudjál telepíteni. Én Manjaro alatt nem használom egyiket sem, a trizen van telepítve, de az is csak azért, mert volt olyan csomag, amit a pamac nem tudott lefordítani, a trizen viszont igen. Szóval nálam pacman, pamac, pamac-manager és trizen van, a többit nem használom.

Sziasztok !
Manjaro: az AUR beállításai szerintetek így megfelelőek ? [link]

Ennyit szoktam állítani én is, gondom nem volt még vele.

Köszi !
Volt olyan alkalmazás, melyet ezen beállítások mellett a pacman/pamac nem talált/nem tudtam telepíteni.
A "yay -S csomagneve" viszont megtalálta, és telepíthető volt.

[ Szerkesztve ]

A pamac-et én csak frissítési értesítőnek meg keresési segédnek használom. Ebben nézem elsőre a keresett csomagot, aztán az AUR-ban. Parancssorból frissítek mindent, meg telepítek.
Bár én Manjaro-t nem nagyon használok, de az Arch rendszeremre a pamac-aur csomagot szoktam feltenni. Van ebből jó pár, ha rákeresel. Nem tudom a Manjaro pont melyiket használja.

A keep built packagest érdemes bekapcsolni, ha csak nem vagy nagyon kifogyva a lemezterületből. Ez megtartja az összeállított és lefordított AUR csomagokat, így ha törlöd, de újra fel szeretnéd telepíteni, akkor nem fordítja le újra (ha csak nincs változás a csomagban, persze).

Igen, vannak olyan AUR csomagok, amiket a pamac nem tud összeállítani. Én ezekre trizent használok, de a yay is ugyanolyan jó megoldás.

Köszönöm !

Köszönet Neked is !

Sziasztok!
A legutóbbi frissítés (21.2.1-re) után, megnéztem vannak-e "Árva" csomagok?
Kettőt mutat: CMake, (3.22.1-5) és itltool
A CMake az egy elég alapvető csomag - tényleg törölhető lenne??

Az előző kérdésem kiegészíteném ezzel: [link]

Azt mondanám, érdemes lenne elmerülni az arch rejtelmeiben : https://unix.stackexchange.com/questions/370530/pacman-orphan-packages
Szerintem akár törölheted is, ártani nem ártasz vele.
Én nem piszkálom. Nekem is ezt írja ki ez a parancs :

$ pacman -Qdtq
cmake
nasm
ninja
python-argcomplete
qt5pas
vala

OS : EndeavourOS KDE . . . . . . Parancs menü : https://pastebin.com/u/txt444

Köszönöm!
Úgy döntöttem törlöm az elárvult csomagokat.
De előtte csinálok rendszer-visszaállítási pontot - aztán' majd kiderül
hogy tényleg nem okoz-e galibát ezek (főleg a CMake) törlése.

A legutóbbi problémám óta szereztem egy monitort illetve lett egy GT1030-am és gyönyörüen megy a rendszer a gépemen.

[ Szerkesztve ]

MINISFORUM ELITEMINI HM90+NINTENDO SWITCH V2+NINTENDO WII+TELEKOM T-PHONE PRO 5G (6/128)+NINTENDO 2DS+LG 43UJ635V+SAMSUNG SYNCMASTER C24F390

Az Antergos óta nem próbáltam Arch alapú Linuxot asztalon, de ez mindent felülmúl. Nagyon egyszerű volt W11-ről átállni, minden működik ami eddig fontos volt, csak konzisztensebben.
Ami nem fontos, ujjlenyomat-olvasó, touchpad szélére húzva és tartva az ujjat nem vonszolja a kurzort, samba nem igazán akar működni, de nem baj.

Probálom futtatni az In Sound Mine játékot Manjaro Linux KDE alatt de akadva megy. (Nvidia 510-es driver van fent,Secure Boot off,Heroic Launcher+Default Wine 7.4 indul csak el,a többi 2 ami egy modósított Wine nem sajnos.

Mit kell állitsak a rendszerben illetve a Launcherben hogy jól fusson?

UI: Windows alatt jobban megy mikor még a W10 volt fent.

[link]

MINISFORUM ELITEMINI HM90+NINTENDO SWITCH V2+NINTENDO WII+TELEKOM T-PHONE PRO 5G (6/128)+NINTENDO 2DS+LG 43UJ635V+SAMSUNG SYNCMASTER C24F390

A játék külön műfaj...
Ultimate Linux Gaming Guide

Azt hiszem nem leszünk barátok a Linuxal.

Esetleg ez mennyire jó játékra?

[link]

MINISFORUM ELITEMINI HM90+NINTENDO SWITCH V2+NINTENDO WII+TELEKOM T-PHONE PRO 5G (6/128)+NINTENDO 2DS+LG 43UJ635V+SAMSUNG SYNCMASTER C24F390

Á... Amúgy próbálj valami light ablakkezelőt használni KDE mellett/helyett, minél egyszerűbb, annál jobb, lehet a kwin vagy bármelyik kompozitor már használja a GPU-t annyira, hogy a játék akadjon.

De ennyire?

A Windows is használja valamilyen szinten a vga kártyát nem?

Akkor a Steam Decken miért mennek a gamek? Az is Manjaro KDE használ.

[ Szerkesztve ]

MINISFORUM ELITEMINI HM90+NINTENDO SWITCH V2+NINTENDO WII+TELEKOM T-PHONE PRO 5G (6/128)+NINTENDO 2DS+LG 43UJ635V+SAMSUNG SYNCMASTER C24F390

A Deck Proton-t használ (az egy bővített Wine). A ProtonDB egészen jó értékelést kapott az általad említett játék, de a részletes leírásban azért látszik, hogy vannak vele problémák.

Ubuntu MATE 20.04, hobbi cayenne termesztő

Én wayland alatt fürgének érzem az intelt de csak desktopra használom. nVidiánál mondják hogy vannak gondok. Lehet hogy nem játékra találták ki ezt a platformot, vagy nem az átlag játékokra.

Bosszantott, hogy Gnome (Wayland) alatt háromszor kellett kattintani a Chrome fejlécére a maximalizáláshoz.
A chrome://flags/#ozone-platform-hint -néla Wayland-et választva működik a duplaklikk és még a csippentős zoom is.

A Win11 továbbra is katasztrófa, közben új gépem lett ami sikítva kéri hogy a hozzá adott gyári win helyett Manjaro fusson rajta. Sajnos az ujjlenyomat-olvasó ennél se működik.

Ha Manjaro Gnome-ot telepítetek, ne válasszátok a lemez titkosítását, mert nem fog tudni bebootolni a rendszer.
Ez egy ismert bug, én már a második Manjaro telepítésnél szaladok be. Utólag live CD-vel bebootolva elméletileg valahogy meg lehet csinálni, én fél óra után feladtam.
Azt nem tudom, hogy a többi asztali környezettel szerelt változatot is érinti-e, illetve azt sem, hogy minden gépen előjön-e a bug, vagy csak egyes BIOS/UEFI környezetben.

Sziasztok.
Friss Manjaro telepítés, minden ok.
Kivéve,
használom a ddccontrol szoftvert a fényerő, kontraszt állítására.
És ilyet eddig egy disztró se csinált amit a Manjaro.

A ddccontrol i2c buszon vezérli a monitort, első indításnál kiválaszt egy számomra megfejthettlen logika alpján egy random i2c buszcímet.
Ez eddig volt dev:/dev/i2c-0, 1,2stb.,8,9. Ezek tök random, nem tudom mi alapján csinálja, a monitor és a konfig ugyanaz, a hdmi kábel sincs sose kihúzva.
Namost ez az i2c cím ez eddig sose változott, de a Manjaro alatt kb. 5-6 boot után megváltozik. pl. mai napig 9 volt, a mai boot után 3 lett.
És ez nagyon kellemetlen mert a bill.kombinációs fényerő értékeket nekem féltucat szkript intézi és így nem találja a monitort, nem működik.
Eddig, 5 nap alatt már 3x át kellett írnom a szkripteket és ez így nem gyerebe.
Pl. ez egy 75% fényerő uasítás
ddccontrol -r 0x10 -w 75 dev:/dev/i2c-9
ami az i2c-9 címen érné el a monitort. de ez a mai bootnál megváltozott i2c-3 -ra.
Ezt miért csinálja? Hogyan lehetne fixálni?

[ Szerkesztve ]

Akkor mi történik, ha mind a 10 (vagy csak több) számra kiadod a parancsot ? nem elegáns, de ha működik ...

OS : EndeavourOS KDE . . . . . . Parancs menü : https://pastebin.com/u/txt444

Vesszővel elválasztva? Szintaktikailag eléggé tök vagyok.
i2c-1,2,3, stb vagy kell szóköz?

Szerk, kipróbáltam, nem megy.
Több módon.
0,1,2,3,4
0, 1, 2, 3, 4
0 -1 -2 -3 -4

[ Szerkesztve ]

Arra gondoltam, hogy ugyanazokat a parancsokat kiadod egymás alatt a szkriptben :
ddccontrol -r 0x10 -w 75 dev:/dev/i2c-9
ddccontrol -r 0x10 -w 75 dev:/dev/i2c-3
ddccontrol -r 0x10 -w 75 dev:/dev/i2c-5

OS : EndeavourOS KDE . . . . . . Parancs menü : https://pastebin.com/u/txt444

Ja így.
Meglátom, elég sok körmölnivaló lesz meg kopi-paste, egy utasítás így néz ki, egy adott értékhez állítja a fényerőt és a kontrasztot is,
 echo jelszavam | sudo -S ddccontrol -r 0x10 -w 75 dev:/dev/i2c-9
 sleep 1 ; echo jelszavam | sudo -S ddccontrol -r 0x12 -w 90 dev:/dev/i2c-9
és ilyenből van 6 darab, nulla és teljes fényerő+kontraszt beállítása.
Mielőtt leharapjátok a fejem a jelszavam betételéért egy szkriptbe, nekem 100x egyszerűbb így mint hozzáadni a ddccontrolt a sudoers izével, amúgy nem vágom, egy szimpla fényerőállításhoz minek rendszergazdai jogosultság
Most kapcsoltam be a gépet, manjarot indítottam és most visszaállt i2c-9-re, a fene se érti a lelkivilágát

Én sem értettem míg rá nem kényszerültem a monitor fényerő, kontraszt változtatására naponta többször és meguntam a monitor alján gépészkedést a menü gombokkal.
Így a pc-ről lehet mindent állítani.

Közönöm a segítséget.

Cinnamon felületű Manjaron azért ez egyszerűbb. [link]
Redshift + QRedshift kisalkalmazás telepítésével.
A nappali / éjszakai üzemmód váltás automatikusan történik
a megadott geolocation alapján.

Azon agyalok, mióta előjött a problémád. Nem lehetne-e valahogy kényelmesebbé tenni a folyamatot. Majd a systemd szakértők helyre teszik az elméletem.
Arra gondoltam, hogy kellene egy lekérdezés, ami az éppen aktuális i2c bus címet lekérdezi a GUI elindulása után. Ez egy systemd service vagy unit lenne.
Ennek az eredményét meg átadni egy másik service-nek vagy unit-nak, ami azt a szkriptet indítja, amiket már eddig megírtál. Annak függvényében, hogy mi az éppen aktuális i2c busz.
Nem tudom a jelszó-sudo megoldásod hogyan befolyásolja ezt.
Azért kíváncsi vagyok az ebben jártasak véleményére, hogy egyszerűsödne a folyamat ezzel a megoldással?

[ Szerkesztve ]

Nem tudom a redshift mit csinál de szerintem a gammával játszik xrandr vonalon.
A ddccontrol meg natívan a monitort vezérli, pl. ha leveszem 100-ról 0%-ra a fényerőt akkor a monitor backlight ledeket veszi lejjebb.
Ez biztos mert ha a ddccontrollal veszem le a fényerőt, a monitor fogyasztása 22 wattról lemegy 10 wattra.
Elviekben létezne a legegyszerűb megoldás, a gyári fényerő de én eddigi pályafutásom alatt egyik gépemen se működött egyik disztrón sem.

Most reggeli boot, a változatosság kedvéért i2c-7 lett
Viszont. Hekkelve indul a Manjaro, a telepítésnél sehova nem kértem a rendszerindító bejegyzést mert én szögeltem bele az efibe.
És van egy hibaüzenet a bootnál ami valami video anomáliára utal, mindjárt befényképezem. Lehet ennek van köze a változó címekhez?
Utánanézek a boot fallback opciónak, lehet megoldaná.
A Manjaro boot sokkal finnyásabb mint egy mezei Ubi vagy Mint, erre már rájöttem az évek alatt.

"Hekkelve indul a Manjaro, a telepítésnél sehova nem kértem a rendszerindító bejegyzést mert én szögeltem bele az efibe."
A megelelő méretű, és fájlrendszer partíciónak adtam /boo/efi csatolási pontot.
Ez alapján a telepítő tudta hogy hova kerüljön a rendszerbetöltő.
És nem kell hekkelnem hogy induljon.

Uram Ön nem egy Ventoy rendszert használ rendszerindításra
Ahol nem akarnám a Manjaro által elbaltázni az eddig megszokott 10+ elemű bootmenüt.

[ Szerkesztve ]

Értem ! ... Így már más a leányzó fekvése.
Nálam 1 eszközre (SSD) 1 rendszer kerül.
(Több is van - ezek közül indítás után a GRUB-ban választok.)