Kifutottam a szerk. időből...

Azon gondolkodtam, hogy mondjuk az olyan eseteket, amikor egy olyan méretű window van, ami nem fér el sehova (pl: munka közben a háttérben fut gui-val a handbrake) akkor azt hogyan kezeli?
Gondolom a meglévőre nem nyit egy ablakot neki, igaz?
(Új még a WM nekem, soha nem használtam)

Nalam a dual monitor (monitor+TV) igy nez ki (mindenfele GUI nelkul evek ota mukodik)
Sway config output section:

### Output
# LG 32' Monitor
output DP-1 {
mode 2560x1440@74.971Hz
position 0 0
adaptive_sync off
dpms on
scale 1
scale_filter smart
subpixel rgb
render_bit_depth 8
bg /usr/share/backgrounds/arch.png fill
}
# LG 55' OLED TV
output HDMI-A-1 {
mode 3840x2160@120.000Hz
position 0 0
adaptive_sync on
dpms on
scale 1
scale_filter smart
subpixel rgb
render_bit_depth 10
bg #000000 solid_color
disable
}

es ilyen egyszeruen valtok kozottuk

## Screen control
mode "(M)onitor (T)v (O)ff" {
bindsym m output $monitor enable, output $tv disable, mode "default"
bindsym t output $tv enable, output $monitor disable, mode "default"
bindsym r output $monitor enable, output $tv enable, mode "default"
bindsym o output $monitor disable, output $tv disable, mode "default"

# Retrurn to default mode
bindsym Return mode "default"
bindsym Escape mode "default"
}
bindsym $mod+x mode "(M)onitor (T)v (O)ff"

position, scale nekem default. (nyilvan tetszes szerint valtoztatod)

Es igen, az archinstall script van ugy h bugos, amikor eloszor probaltam akkor a particionalasnal hasalt el, bar hozzateszem nem nagyon szoktam rendszer ujrahuzni

[ Szerkesztve ]

Én ugyan még nem vettem rá magam, hogy install scriptet írjak, de az általad írt locale.gen módosítást én sed-el csinálnám:

sed -i /etc/locale.gen 's/#en_US.UTF-8/en_US.UTF-8/g'

Persze a locale.gen pont egy olyan file, amit akár egyszerűen csak felül is írhatsz azzal a tartalommal, amit egyébként a # törlésével engedélyeznél. Pl.:

echo "en_US.UTF-8 UTF-8" > /etc/locale.gen

Köszi, ez értékes info. Már néztem amúgy a Sway config-odat, amit linkeltél.
Na, majd amikor a saját gépen lesz végre valami, akkor konkrétumokkal is látom mindezt.

vargalex:
Köszönöm. A "sed" nem idegen, de valahogy nem jutott eszembe. Fene ...
(Lassan mehetek molnárnak, mert az agyam, mint a szita)
Igen, a "locale.gen" nem volt a legjobb példa, hiszen egyetlen értékes sora lesz, de mondjuk egy "/etc/default/grub" esetén már tényleg csak egyetlen részt akatok átírni.
Szóval a lényeg azért átment gondolom.

Sziasztok,

A gépemen a videó néha megtörik. Ennek több fokozata van.

Gyorsított (vaapi) videókban, böngészőben de vlcben is, néha mindenféle kockák jelennek meg, a kép remeg, néha bezöldül. A hiba néha magától elmegy.

A másik fajta hiba ami néha előfordul az ennél súlyosabb. Rendszerint akkor szokott előjönni hogyha a videókkal már probléma van. A kockák és vibrálás ráterjed az egész képernyőre azaz nemcsak ott ahol a videó megy. Az egérkurzort tudom mozgatni, de ha valahova oda kattintok akkor nem történik semmi. Ha átmegyek konzolra (tty1), ott a szöveg rendesen látszik. Ha visszajövök grafikus felületre, a hiba marad. Ilyenkor az szokott segíteni hogy a konzolon a lightdm szolgáltatást újraindítom. Az a baj hogy ekkor az összes grafikus alkalmazás újraindul, azaz majdnem felér egy rezettel. Van valami “lightosabb” módja is az újraindításnak, hogy az alkalmazások megmaradjanak úgy ahogy vannak; például a drivert valahogy újra lehetne indítani?

Vajon mi lehet ennek a hibának az oka? Ez egy Xfce bug lehet? Ha ráraknék egy Waylandet akkor vajon megoldódna? Vagy ez inkább egy videokártya driver bug? Esetleg hardveres dolog, valami rossz bios beállítás? Nyílt AMD meghajtót használok egy HD6850 hez. Egy intel videós laptopon is Archot használok Wayland/Gnome -al, ott semmi ilyesmi problémát nem tapasztaltam.

System:
  Host: bazsarch Kernel: 6.3.1-arch1-1 arch: x86_64 bits: 64 compiler: gcc
    v: 13.1.1 Desktop: Xfce v: 4.18.1 Distro: Arch Linux

Graphics:
  Device-1: AMD Barts PRO [Radeon HD 6850] vendor: PC Partner / Sapphire
    driver: radeon v: kernel arch: TeraScale-2 bus-ID: 03:00.0 temp: 37.0 C
  Display: x11 server: X.org v: 1.21.1.8 driver: X: loaded: radeon
    unloaded: modesetting dri: r600 gpu: radeon resolution: 1600x1200~60Hz
  API: OpenGL v: 4.5 Mesa 23.0.3 renderer: AMD BARTS (DRM 2.50.0 /
    6.3.1-arch1-1 LLVM 15.0.7) direct-render: Yes

Nyilván okozhatja driver is, de ezeket a remegéseket/zöldüléseket, stb. sokszor hibás VGA RAM, esetleg túlmelegedés okozza. Én megnézném valami GPU stress test-el is (bár lehet, hogy vannak specifikusabb alkalmazások is erre).
Mondjuk abból, hogy lightdm szolgáltatás újraindítása után ismét jó, lehet, hogy a túlmelegedésre gondolnék. Nézd meg a GPU hőmérsékleteket.

Git migration announcement
This Friday morning (2023-05-19) the Git packaging migration will start until Sunday (2023-05-21). The Arch Linux packaging team will not be able to update packages in any of the repositories during this period.

via Arch Linux news

Szia,

Hidegen is csinálja, 36 fokon is előjött. 1080 soros YouTube nézés közben fel szokott menni a hőmérséklet kb 50 fokig. Az egyik stressz tesztet (amelyikben a Zeppelin van) a linkről próbáltam, ott felment 55 fokig is, és minden ok volt.
A videókártya nem éppen egy mai darab, akár valami hibája is lehet. Vagy valami miatt nem kompatibilis az alaplappal. Tekergetem majd a bios pci-e beállításokat és hátha belebotlok valamibe. Windowsom nincs ezen a gépen, azt nem tudom kipróbálni.

Sziasztok!

Régóta szívok az NFS megosztással.

A cél, hogy egy mappát megosszak a laptopról egy klienssel.
A kliensek másik eszköz NFS megosztását gond nélkül látják, tehát nálam van a gond a laptopon.

Végigcsináltam mindent a wiki szerint, de mivel amikor egy éve először elkezdtem ezzel foglalkozni, nagyon kevés időm volt, tuti elbénáztam valamit.
Most újrakezdtem, de ugyanaz az eredmény.

A TV látja azt, hogy melyik foldert akarom megosztani (igazából azt látja, amit az /etc/exports file-ba írok), de hiába van arra a folderre mountolva bármi, azt már nem látja a kliens oldalon semmi: se linux, se a TV, se a Chromecast.

Ugyanitt akadtam el régebben is. Már hiába csinálom végig a wiki, vagy más tutorialok szerint, nem műxik. Biztosan valami el van mókolva, csak nem jövök rá, hogy mi az.

Van tippetek erre?

[ Szerkesztve ]

Elvileg sikeresen lezajlott a váltás, a tervezettnél előbb. Viszont még egyik tényleges mirror se követte le a változást, legalábbis a core-testing, extra-testing még egyiken sem létezik, akinek ez nem kell, azok változást nem fognak észrevenni. A /etc/pacman.conf-ot át kell írni, hogy milyen tárolókat használjon, esetleg egy pacman -Scc; pacman -Syy parancsot érdemes futtatni. Lehet lesz még pár nap, mire újraindul az újabb verziós csomagok készítése.

Fejlemény: már a -tesing végő tárolók is mennek, várni kellett 1-2 órát, mire lekövették a gyorsabb mirrorok a változásokat. Problémát nem tapasztalok.

A tegnapi mesa frissités indithatatlanná tette a wine-s játékot. Downgrade helyre rakta - mesa 23.1.0-1 helyett 23.0.3 - endeavour os. Manjaro még nem frissített, ott jó (még).

asszem 10 éve tettem fel a céges gépemre az Arch-ot, eddig nem volt olyan gond az OS-sel, ami pár percnél hosszabb időre megállította volna a munkát

rendszergazda vagyok

[ Szerkesztve ]

Az openboxot szeretném a --debug kapcsolóval indítani display managerből (sddm-et használok). A probléma az hogy amikor ki akarok lépni az openboxból akkor első probákozásra csak villan egyet a kép és nem lép ki, második próbálkozásra lép csak ki és kapom vissza a display managert. Ha az sddm-et leállítom és startx-el indítom az openboxot akkor simán elsőre működik a kilépés. Van egy másik gépem ott is sddm-et és openboxot használok, ott első alkalomra probléma nélkül kilép és visszatér az sddm-hez. Melyik fájlt kell szerkesszem hogy a display managerből --debug kapcsolóval tudjam elindítani az openbox-ot ? Azt olvastam a google-ban hogyha --debug-gal indítom akkor a /var/log-ba teszi a logjait az openbox, vagy esetleg máshova ?

ÁÁÁ. pedig már két éve is volt rá megoldás, de elfeledkeztem róla.
https://linuxmint.hu/comment/46806#comment-46806
Meglepő, de még mindig működik. Semmi baj az arch-al, csak nem kell feledékenynek lenni.

OpenBLAS >= 0.3.23-2 update requires manual intervention

The openblas package prior to version 0.3.23-2 doesn't ship optimized LAPACK routine and CBLAS/LAPACKE interfaces for compatibility. This decision has been reverted now, and the ability to choose a different default system BLAS/LAPACK implementation while keeping openblas installed is now provided to allow future co-installation of BLIS, ATLAS, etc.

The default BLAS implementation will be used for most packages like NumPy or R. Please install "blas-openblas" and "blas64-openblas" to make OpenBLAS the default BLAS implementation, just like the old behavior.

Unfortunately you will get errors on updating if you currently have OpenBLAS installed as the default BLAS implementation:

error: failed to prepare transaction (could not satisfy dependencies) :: installing openblas (0.3.23-2) breaks dependency 'blas' required by cblas :: installing openblas (0.3.23-2) breaks dependency 'blas' required by lapack

Please append your preferred default BLAS implementation to the regular -Syu command line to get around it. For example:

pacman -Syu blas-openblas

or

pacman -Syu blas

Sziasztok,
btrfs + luks combóval van valakinek tapasztalata.
Néha, kernel frissítés közben, a gép magától újraindul.
Természetesen ilyenkor már bootolni sem tud, mehet a pxe boot.
Virtualizálásra van használva, ilyenkor jóval nagyobb terheléseket is kap, de ez a hiba csak kernel updatekor van.
Ötlet?

[ Szerkesztve ]