- iPhone topik
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Íme az új Android Auto!
- Samsung Galaxy S20 és S20+ duplateszt
- Xiaomi 13 - felnőni nehéz
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Honor Magic6 Pro - kör közepén számok
- Karaktere biztos lesz az első Nothing fejhallgatónak
- Samsung Galaxy S24 FE - később
- Kedden érkezik a Galaxy S25 Edge
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
-
Shyciii
veterán
Igen azt nem néztem, hogy a htop a shared memory-t is beleszámolja, de a Conky többet mutat még így is. A polybar modulja meg végképp. Az 1,1GB memóriahasználatot mutat miközben a free -m 239MB-ot, tehát több, mint a free -m+shared+cache.
Igazából ez most úgy jött ki nálam, hogy megszüntetem a conky-t, és 1-2 dolgot ki akartam rakni a polybarra, többek között a a memória használatát is. No mindegy. Megnézem, hogy hogyan kell polybarra kirakni úgy egy értéket, hogy egy terminal parancsot futtatok. Mikor beállítottam magamnak a polybar-t a mostani kinézetre, akkor rémlett, hogy lehet ilyet. Ha igen, akkor majd a free .m parancs értéket iratom ki. -
#63718632
törölt tag
Úgy néz ki helyre állt a rend. Bezártam minden futó programot és a "Munka menet és indítás" beállításokban kiválasztottam az automatikus mentést és bejelentkezéskor a munkamenet választó mutatását. Egy "default" menett munka menetem van, mint eddig, csak aktualizálva a mostani dátumra.
Most már munkamenet választó nélkül is rendesen megy minden bejelentkezés után. -
#63718632
törölt tag
Köszi szépen, elindult a frissítés.
Annyi lenne még, hogy ezen a rendszeren Yaourt van még Aurhelper-nek. Nyár elején még nem figyeltem a Yaourt elavultságát és az jött szembe legelőször, azt telepítettem. Most lecserélném Yay-re. Azt telepítettem már másik gépre. A Yaourt-ot hogyan tudom leszedni telejesen? -
attilav2
őstag
A Sway-t felraktam, ha elindítom csak egy üres asztalt kapok és a jobb egérgombra sem jön elő menü. Mit kell beállítsak, hol, hogy valamit el tudjak benne indítani?
qt5-wayland csomag telepítve van és a libek is megvannak a /usr/lib/qt/plugins/platforms
alatt de csak az xcb plugint tudja betölteni a plasma wayland session. Ez tuti valami Arch specifikus hiba. -
Shyciii
veterán
Igazad van. Én ma indítottam egy frissítést, és kb 132db elemet töltött le (ezek mind lent voltak, de mégis szükségesnek ítélte, mert compton helyett már picom lett a csomag, ami csak most derült ki), majdnem 400MB letöltés, és ezek telepítése. i3-as notebookon ssd-vel 1 perc alatt felrakta. Szerintem ez akármilyen sürgős könnyen kivárható.
-
attilav2
őstag
Úgy telepítettem a Kde-t ahogy kellett.
pacman -S plasma, pacman -S plasma-wayland-session + a mesa csomagok, az xwaylandet is behúzta azthiszem.
A plasma metacsomag egyébként koránt sem tesz fel mindent, pl a konsole-t sem. A plasma meta csomag teszi fel a legtöbb összetevőt azthiszem, de egy tumbleweed kde alaptelepítéshez képest azért még mindig elég szegényes. -
whbear
senior tag
Köszi az infót. Volt időm. Csak jött egy telefon hogy azonnal indulni kell. Bár legközelebb hagyom hogy fusson le. Még nem kezdte el a frissítést, csak az üres helyet ellenőrizte. Ezért gondoltam hogy nem lesz gond. De lett. Lehet hogy mire értelmezte a megszakítást már benne volt a kernel frissítésben.
-
Shyciii
veterán
Sajnos az általad leírt megoldás lecövekel egy gépre (meló helyen ez működik is, ott pl Dashlane-t használunk Windows-ra), de a Chrome-ban tárolás lényege az unvierzalitása mellett az, hogy ezt bámelyik gépen megkaphatom ahol chrome van, márpedig az szinte minden gépen van. Mobilon szintúgy van, persze ott Brave Browser-t használok, de ugye az chromium alapú, így ott szintén automatikusan tudom használni.
-
-
attilav2
őstag
Nem vagyok expert linuxos, ezért a fájlrendszer jogokhoz nem nagyon értek, csak a chown paramétereit tudom ha valamit saját tulajdonba szeretnék venni akkor: chown -R felhasznalo:users, vagy ha root nak akarom adni akkor root:root ot írok, chmod paramétereit nem ismerem, shell scriptekhez sem értek, így nem is tudnám a chromium ubuntu dev ppa branch csomagjait makepkg scriptbe bedolgozni :)) 3 deb ből kellene arch csomagot gyártani maga a chromium, az ffmpeg-extra, és a lokalizációs csomag, ja és a legújabb 19.10 es ubuntus chromium dev csomagokat kellene átültetni, valaki a fórumról csinálhatna makepkg scriptet :)) Az arch-ot azért tudom egyébként feltelepíteni mert nagyon jó wikije van, és megvan a logikai érzékem hozzá. A tumbleweedben az tetszik hogy csak pár naponta kap frissítéseket, nem olyan nagy a tempo mint az Arch nál, kevesebbet változtatnak szerintem. Kulcsrakész desktop rendszert ad telepítés után, nem kell találgatnom mik az éppen hiányzó kde/egyéb csomagok, meghát az is közrejátszott a váltásban hogy lusta vagyok, az Arch al mindig van egy kis utómunka, meg hajt a kíváncsiság. Gentoo nekem magas, nem szeretek sok időt szánni a fordítgatásokra. Épp elég hogy a tv kártyám (tbs márkájú) opensource drivere vagy fél óráig fordul mert saját v4l tree-t fordít, minden kernel váltásnál újra kellene fordítani, ezért nem is üzemelem be sokszor linux alatt a tv kártyámat.
-
attilav2
őstag
Az ubuntu dev chromiumot manuálisan bemásoltam arch alá, csak utána volt egy kis szívás a rendszerkönyvtárak jogaival, ami miatt az ufw leállt, helyrehoztam. De macerás minden chromium frissítésnál másolgatni meg jogokat állítgatni. Majd ha kijavítják arch-on a chromium vaapi -t akkkor lehet visszatérek.
-
#63718632
törölt tag
A
/boot/loader/entrieskönyvtár tartalma:ArchLabs-fallback.confArchLabs.conf
A sorrend így volt:title ArchLabs Linuxlinux /vmlinuz-linux-ltsinitrd /amd-ucode.imginitrd /initramfs-linux-lts.imgoptionsroot=PARTUUID...........
A /boot könyvtárban nincsamd-ucode.img.
A sorrendet néztem az ArchWikiben, ott is azinitramfs-linux.... .imgelőtt volt az inteles ucode img. -
#63718632
törölt tag
Sikerült egy jó kis helyzet gyakorlatot összehoznom
. Megcsináltam a módosítást konfig fájlban, majd restart.
A bootolás megakadt ezekkel a hibaüzenetekkel:Failled to open file: amd-ucode.imgTrying to load files to higher addressFailled to open file: amd-ucode.img
Vesztemre a fallback konfigba is beírtam a változást, nem bírtam elindítani a rendszert.
Jó hát akkor "valahogy" töröljük ki azt a két módósítást. Evidens, hogy egy live rendszerrel, amivel megkeresem a fájlokat, módósítom és örülök. Ahha, csak ugye a /boot könyvtár az üres, ha nincs bele csatolva az efi partíció. A conf.file meg ott van. Na hogy is kell kézzel mountolni live os alá UUID-vel egy speciális partíciót? Ritkán, szinte soha nem kell ilyen műveleteket csinálnom, de most muszály. A rendszer kész van, be van lakva, be van állítva. Nem opció az újra telepítés.
A lényeg, hogy a live os /media/demo-ba csináltam egy könyvtárat az efi partíció UUID azonosítójával. Mert a / partíciót is az alapján csatolja. Így már elértem a conf.fájlokat és kitöröltem a bejegyzéseket.
Most ismét ketyeg a rendszer.
Az amd-ucode csomag természetesen telepítve van. Kellene csinálni egy amd-ucode.img-t kézzel? -
Shyciii
veterán
Nem poénból nem írtam be, hanem mert feltételeztem, hogy anno mikor kb fél éve újraraktam akkor még a Zen installerrel, akkor feltételeztem, hogy ha már mindent megcsinál, akkor ezt is. Csak most hogy magamnak irogatott cuccokat, scripteket rakom egybe, akkor néztem, hogy jééé, hiányzik ez a sor, és hogy hogy lehet. Csak mivel nem rakom fel hetente az Archot mint te szoktad, így nem egyszerű visszaemlékezni, hogy anno mit mivel telepítettem, mit teszteltem.
-
-
attilav2
őstag
Egyelőre biztos nem váltok, pl a Gufw nem elérhető tumbleweed-re, csak instabil tárolóból lehetne feltenni, ez nem tetszik. Kénytelen voltam parancssorból konfigolni az Ufw-t, de nem volt nehéz a google adott leírásokat. Meg az sem tetszik hogy a videólejátszáshoz külső tárolókat kell hozzáadni, pl packman, vlc, amik esetleg összeakadhatnak a gyári csomagokkal egy frissítéskor. Egyelőre nem is raktam be külső tárolókat. Az viszont tetszik hogy a chromium alapból vaapi támogatással van forgatva és működik is a hw videó gyorsítás. Igazából a kíváncsiság hajtott a SuSe kipróbálására, utoljára a linux hőskorában a 2000-es évek legelején használtam SuSe-t és érdekelt azóta mennyit változott.
-
#63718632
törölt tag
-
#63718632
törölt tag
Korai volt az örömöm, mert restart után megint 1 órával előrébb járt a rendszer idő. Hiába követtem az Arch Wiki-t. Viszont az általad írt parancs segített és nem találkoztam a Wikin. Konkrétan ez tette rendbe:
timedatectl set-ntp trueNincs Windows, csak ez a rendszer és UEFI telepítés.
A BIOS órája is jól járt, jár. -
#63718632
törölt tag
Nálam is előjött. Próbálom a yay-t telepíteni, de hibára futok.
[laci@laci-pc-endeavouros ~]$ cd yay
[laci@laci-pc-endeavouros yay]$ make
go build -v -mod=vendor -ldflags '-s -w -X "main.version=9.4.2"' -o yay
make: go: Command not found
make: *** [Makefile:47: yay] Error 127Ez egy friss Endeavour rendszer, az este telepítettem.
-
Laszlo733
aktív tag
" Én a történetedben azt nem értem, hogy a pacmant miért yay-jel akarod telepíteni? Miért nem pacmannal? Nálam simán települt az 5.2-es, semmilyen hibám nem volt azóta. Igaz én Octopit nem használok, yay-t is csak az AUR-os csomaghoz. "
Én nem akartam, hanem a frissítéskezelő nem telepítette. Az Arch forumon meg olvastam a hibáról és ott javasolták a yay törlését, majd a pacman telepítését pacman -nel és a git yay telepítést
-
Laszlo733
aktív tag
Köszi a segtséget!
Az Oktopi újratelepítésénél egy ilyet dobott:
[arch@Archlinux ~]$ yay -S octopi
:: There are 4 providers available for octopi:
:: Repository AUR
1) octopi 2) octopi-dev 3) octopi-git 4) octopi-kde-git
Enter a number (default=1):
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur: 2] alpm_octopi_utils-1.0.1-1 octopi-0.9.0-3
:: Downloaded PKGBUILD (1/2): alpm_octopi_utils
:: Downloaded PKGBUILD (2/2): octopi
2 alpm_octopi_utils (Build Files Exist)
1 octopi (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==>
:: Parsing SRCINFO (1/2): alpm_octopi_utils
:: Parsing SRCINFO (2/2): octopi
/usr/share/makepkg/lint_config/variable.sh: sor: 67: szintaktikai hiba „fi” váratlan tok
en közelében
/usr/share/makepkg/lint_config/variable.sh: sor: 67: ` fi'
/usr/share/makepkg/lint_config.sh: sor: 43: lint_config_variables: parancs nem található
Error downloading sources: alpm_octopi_utils -
Laszlo733
aktív tag
Igen, terminálból is betöltődik lefagy, majd összeomlik. A kimenet hibás fájlleíróra panaszkodik.
Az utolsó pár sor:"SELECT COUNT(id) FROM Images WHERE album=:a;"
Error messages: "Unable to fetch row" "database table is locked: Images" "6" 1
Bound values: (QVariant(int, 2))
ASSERT: "!isEmpty()" in file /usr/include/qt/QtCore/qlist.h, line 363
digikam.dimg: "/home/linux/Pictures/Házi videó/2013.05.16_saját/2014_Januá
r/20140102_201319.jpg" : JPEG file identified
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = digikam path = /usr/bin pid = 6087
KCrash: Arguments: /usr/bin/digikam
KCrash: Attempting to start /usr/lib/drkonqi from kdeinit
sock_file=/run/user/1000/kdeinit5__0
pa_write() failed while trying to wake up the mainloop: Hibás fájlleíró
pa_write() failed while trying to wake up the mainloop: Hibás fájlleíró
pa_write() failed while trying to wake up the mainloop: Hibás fájlleíró
Invalid write to eventfd: Hibás fájlleíró
Code should not be reached at ../pulseaudio/src/pulsecore/fdsem.c:199, function pa_fdsem
_post(). Aborting.
Unable to start Dr. Konqi
Re-raising signal for core dump handling.
Félbeszakítva (core készült) -
Laszlo733
aktív tag
Telepítettem az autoconf -ot, de utána így is hibára fut a yay -S gksu
Hunk #20 succeeded at 2876 (offset 5 lines).
Hunk #21 succeeded at 2888 (offset 5 lines).
patching file Makefile.am
patching file libgksu/Makefile.am
Hunk #1 succeeded at 27 with fuzz 2.
patching file libgksuui/Makefile.am
Hunk #1 succeeded at 10 with fuzz 2 (offset 1 line).
patching file libgksu/Makefile.am
Can't exec "aclocal": Nincs ilyen fájl vagy könyvtár at /usr/share/autoconf/Autom4te/Fil
eUtils.pm line 326.
autoreconf: failed to run aclocal: No such file or directory
==> HIBA: Hiba történt a prepare()-ben.
Megszakítás...
Error making: libgksu -
Nem az online TRIM érintett ebben a dologban? (a 800-as sorozat amúgy más rég kikerült a blacklist-ból) Erre a gyűlölt systemd egyébként rég nyújt megoldást, de azelőtt is lehetett ütemezett TRIM-et használni. Sok disztró főleg Arch alapúak még default discard parancsot alkalmaznak FSTAB-ban, nekik érdemes odafigyelni, aki meg pure Archot használ, csak tudja, mit hogyan kell alkalmazni.
Egyszóval az nyilvánvaló még mindig szerintetek is, hogy a Samsung 800-as sorozatnak semmi gondja nincs a TRIM-mel, kivéve 2 tipust, aminek az online TRIM ATA parancs(discard) okoz gondot?
Ez így korrekt? Vagy megint nem jól értelmezek valamit?
-
Shyciii
veterán
Nah nekem Kingston A400-as van
Mondjuk anno azért vettem, mert olcsó volt. Már nem is emlékszem, hogy hány éves.
Sok általános weboldalon én is mindig azt olvastam, hogy a Samsung 840 Pro és 850 Pro jó SSD, de sajnos amit mondtam, azt megerősítette a Rackforest, és a Doclernet is. Ha nem ismered őket, akkor mindketten hostingot végeznek, és hát mi is ezt tapasztaltuk. Otthoni használatra biztos jók ezek a Samsungok, de nagyobb másolás esetén bukováriak. És akkor még ott a trimmelési gondjuk. Mondjuk erről csak akkor olvastam, mikor elkedzem linuxozni. Viszont most olvasom vargalextől, hogy a 850 Pro is érintett ebben. Hihetetlen, hogy ezt képtelenek megoldani.
Amúgy én egy ideje szemezgetek a WD Black SN750-es SSD-vel. Persze M.2-essel. Mondjuk még nem néztem meg, hogy a notebookomba betehető-e, befér-e. -
Shyciii
veterán
Double Commander-t használok
Kipróbáltam neked terminal alóló, és ugyanaz a jelenség. Viszont itt szembetűnőbb volt még egy dolog. Semmi gond nem volt egészen addig, míg az SSD cache-e be nem telt. Ahogy betelt, onnantól kezdve akadozik a kurzor, miközben a proci most 22% átlagt mutatott. És így viszont már nagyon ismerős jelenség. Semmi bug nincsen, hanem az SSD a "szar".
Ugyanis van egy másik tapasztalatom kb 2 évvel ezelőttről. Vannak olyan szervereink, amik RAID1-es köteget használnak Samsung 850Pro SSD-vel. No ott láttam ezt a jelenségget először. Nagy file másolásakor amíg a cache nem telik gyors, és utána drasztikusan leesik a teljesítmény, de olyan szintre, hogy ha valaki távasztalozott arra a szerverre, akkor ki is esett onnan. Amióta már a az SSD-s szerverekben Intel S35 és S46-al kezdődő típusokat használunk, azóta semmi ilyen gond nincsen. Egyszerűen vannak SSD-k, amik szarok olyan nagy file-ok írásában, amik nagyobbak, mint a cache-e. -
Shyciii
veterán
Én újra kipróbáltam a saját ssd-mről ssdm-re másolni egy 14GB-os filet, de ugyanaz. Conky és htop is átlag 27%-os cpu terhelést mutat minden magra, de közben az egérkurzort mozgatva rettentően akadozik. Viszont így elgondolva ezt 2-3 hónapja biztos nem csinálta, mert kb akkor szerveztem át a winyót, és helyezgettem ide-oda cuccokat, és közben tudtam dolgozni, szal itt valamelyik frissítés után lett nekem ilyen. Mindegy, ritkán van ilyen
-
Shyciii
veterán
Az a baj, hogy nekem notebookom van, így nem tudok belerakni még egy SSD-t, mert nincsen hely. Saját SSD-mről másolva 200GB-nyi egy fileos adatot ugyanarra az SSD-re nekem is megeszi a procit, illetőleg a proci terhelés a conky szerint 35% körül van, de az egérkurzoron látni, hogy baromira belassult a rendszer. Ez viszont a SATA csatoló egyértelmű hibája, mert ebből a szempontból nemigen van előrelépés a PATA-hoz képest. USB-s külső SSD van, de ugye ott is az USB korlátozza le.
-
vargalex
félisten
Az emlékezetemben nekem már úgy élt, hogy az AMD procikhoz külön csomag van. Most jutott eszembe ez a hozzászólásod, így megnéztem gyorsan a microcode wiki history-t. Jól emlékeztem, az a jó pár hónapja egészen pontosan 2018 augusztus 26-án volt.
Nyilván azóta ránéztem már az oldalra, ezért emlékeztem... -
-
vargalex
félisten
Ugyan nem írta a kolléga, hogy milyen CPU-ról van szó, de nyilván 1 mag futott 100%-on, kérdés az milyen sebességre képes.
Mégpedig valószínűleg pont azért, mert SSD-ről meglehetősen gyorsan lehet olvasni, így valóban az ntfs-3g terhelte. Persze az elért olvasási sebessegről sem tudunk semmit... -
vargalex
félisten
Engem soha nem zavart a clipboard támogatás hiánya. Kijelölök egy szöveget és középső gombbal (vagy touchpad esetén a 2 gomb egyidejű nyomásával) beillesztem. Nem akarom én nézegetni a vágólapot, nem kell többszörös tartalom, stb.. Mindig az utoljára kijelöltet akarom beilleszteni és ez megy oda-vissza a sima alap vim-el is.
-
F34R
nagyúr
van ha aktiv az xsel, vagy xclip.. egyebkent meg nincs.. [link] meg ugyszint akkor tudod hasznalni ha a terminal emulatorban van clipboard tamogatas. egybkent guirol terminalba siman ment eddig is, vica versa voltak gondok. A gvim meg egy gui-s frontend extrakkal. Nem is kerdes, hogy ezert mukodnek benne az altalad emlitett dolgok. Nalam ez valtozo mi van fent, legendas Distro hopper vagyok.
-
-
vargalex
félisten
Jó lett volna, ha frissíted a repo-t a
pacman -Selőtt. Így nyilván nálad még a cache-elt verziót jelentette. A linkelt hírben egyébként metapackage-t írnak, nem package-t és ez az infó jött RSS feed-ből is.
Ahogy a hír is mondja, eddg a base egy group volt, most viszont metapackage lett. -
-
-
_NCT
addikt
Köszi szépen a választ! Tegnap felcsesztem magam és váltottam Manjaro-ra, mert szeretnék Arch vonalon maradni, de annyira nem fontos, hogy mindig megkapjam a legújabb frissítéseket. A stabilitás fontosabb, kernelből is lts kell vmware miatt. Mondjuk az az én balf@szságom hogy nem vollt beütemezve backup legalább a root-ról.
-
attilav2
őstag
Néztem htop-al a különbséget, firefoxnál ahol nincs hw videó gyorsítás 40-50% között terhelődtek a processzor magok youtube 1080P 60FPS videó lejátszásakor, chromium-dev -nél ugyanez a videó 15% prociterheléssel ment. Nálam fenn van mind firefoxban mind chromiumban a h264ify plugin, ez kényszeríti a youtubeot hogy h264-ben renderelje a videókat vp9 helyett. A vga-m csak h264 dekódolást támogat, de szoftveres dekódolásnál is jól jön a h264 ify, mert a legtöbb procinak jobban fekszik a h264 mint a vp9. Szerintem te is rakd fel a h264ify-t ha még nincs fenn.
-
Frawly
veterán
A kalandok folytatódnak. Most frissült a SwayWM, ugyanaz a verzió (1.2), de újabb build (-2 helyett már -3). Erre most már el sem indul a chromium bináris, azt mondja terminálban:
[863:863:0930/042000.321493:FATAL:memory_linux.cc(42)] Out of memory.
Trace/breakpoint trap (core dumped)Természetesen van elég memória, 14,5 GB szabad a 16 gigából, egy keveset eszik az IGP, meg 600 megát az egész Linux, kernel, systemd, SwayWM, Firefox több füllel. Szerintem még az IGP 1 gigás memóriájából is szabad vagy 900 mega.
Szerk.: az Arch bugtrackere is hozza már, más is jelentette 23 órája. Állítólag a Mesa 19.2 okozza, ahogy már sejtettem, de szerintem nem csak az, mert azzal nekem legalább elindult, ha tearingelt is. A Sway frissítése tett be neki végleg.
-
attilav2
őstag
Igazából a kíváncsiság vezérelt hogyha felrakom az ubuntu alá forgatott chromium-dev verziót akkor működni fog e a hardveres videó gyorsítás, mert kubuntun a chromium-dev -el simán megy, és ahogy sejtettem arch-on is simán megy a videógyorsítás chromium-dev verzióval. Nomeg az ubuntus chromium-dev felrakásával fordítási időt is akartam spórolni, mert van ugyan az aur-ban chromium-dev de csak forrásból lehet feltenni, chromium fordításra meg horror időket írnak a neten ilyen alap procikkal ami egy átlagembernek van.
Egyébként meg az X4 860K, de gondolom a legtöbb mai alap proci is csak kihajtja rendesen vga nélkül is az 1080P-t, a 860K kihajtja, szóval nekem felesleges lett volna dev-chromium felrakásával bíbelődnöm de hajtott a kíváncsiság. A linuxos firefoxban sincs hw videó gyorsítás, elvileg mostanában rakják majd bele. Ha neked is elmegy az 1080p youtube cpu-ból akkor felesleges dev chromiummal bíbelődnöd szerintem. De ha kíváncsi vagy hogy nálad is működik e a hw videó gyorsítás akkor hajrá!
Arch-on ezzel a patchelt aur-os chromium-vaapi-bin -el van a gond, hogy a patchet nem megfelelően alkalmazzák nem aktualizálják az aktuális mesa-nak megfelelően, és az arch fórum topikban amit linkeltem ezt szóvá is tették. Az kellene itt is mint ubuntun, kellene egy build szerver amin mindig lefordulnak a legújabb chromium-dev buildek, ezt az arch közösség szerintem meg tudná finanszírozni.
-
attilav2
őstag
Talán chromium-dev csomaggal megoldódna a videó és egyéb gyorsítás, viszont ott meg nem működik a google fiókkal szinkronizálás, de ez legyen a legkisebb gond.
Csak kellene csinálni egy bináris csomagot valakinek rendszeresen, kellene egy build szerver amin automatikusan fordulnak a chromium-dev csomagok arch-ra. -
attilav2
őstag
Igen, sajnos a radeon 6670-el nem fér össze valamiért az arch konzol, google kidobott pár arch-os találatot erre de megoldás nincs
Sajnos a mikrokód betöltése sem szünteti meg a hibát, néhány alkalommal fekete ahogy kell a konzol, de kikapcs és másnapi bekapcs után szürke konzollal indít megint. Különösen telepítéskor kellemetlen, nem jó a szemnek Feltelepített rendszeren nem annyira zavaró már. Ez a hiba azthiszem a display managerre is hat, ha feltelepítek valamilyet, sddm-et próbáltam régebben, mert kde hez ezt ajánlják, akkor elég sűrűn elhasalt a DM, le kellett szedjem mert nem tudtam vele bejelentkezni, el sem indult vagy összeomlott. De ugyanaz a DM kubuntunál rendesen működik ezen a vason.... -
Frawly
veterán
Ezt egy kicsit bővebben kifejtem, mert nem érthető.
Tehát az SSD-ket ún. lapméret alapján szokták alignálni. Az SSD-n a NAND cellák NAND lapokba vannak rendeződve. De egy darab cellát nem lehet írni/olvasni (az SSD vezérlője nem képes rá), hanem csak egy egész NAND lapot (akkor is, ha csak 1 cellát érint majd a módosítás, olvasás). Ez a lapméret jellemzően 4KB volt a régi SLC-MLC-s SSD-ket, egy ideig még a TLC-seken is, de a modern 3D NAND-on már általában 16 KB vagy még több.
Emiatt a legtöbb particionálóprogi 1024K eltolással particionál, mert az maradék nélkül osztható 4K-s, 8K-s, 16K-s, 32K-s, ..., 512K-s, 1024K-s lapmérettel is, megfelelve a jövőbeni SSD-k igényének is.
Na most itt ebben a topikban valaki német fórumok javaslata alapján felvetette, hogy egy még nagyobb egység, a blokkméret alapján kéne alingálni. Ugyanis a NAND lapok egy még nagyobb egységbe, ún. blokkban is kezelhetők, ennek törléskor, trimeléskor van előnye. A blokkméret általában elég nagy, ilyen több MB-os, SSD-nként eltérő, modern 3D NAND-okon magasabb, mint korábbi 2D-seken, ilyen 6-30 MB nagyjából. Tehát egy blokkban ~1000-es nagyságrendű lap van.
De itt jön a logikai bukfenc. A fájlrendszerek által kezelt logikai szektorok 0,5-4K-sak jellemzően, ez meg is felel, maradék nélkül osztható a 4-16K-s lapmérettel, és az 1024K alignálással, mert így a lemezműveletek nem lógnak át laphatárokon. De tegyük fel, hogy nem blokkméret alapján vannak alignálva a partíciók. Ekkor a partíciók első és utolsó pár szoktora, fizikai lapja átlóghat blokkhatárokon, de ez csak ezt a pár szektort, lapot érinti. De a közöttük lévő szektorokat nem, mert azoknak a lapmérete/szektormérete maradék nélkül osztható a blokkmérettel, így nem lesz olyan köztes lap/szektor, ami blokkhatárokon nyúlna át.
Vegyük például az én átlagos felhasználásomat. Egy régi 3D TLC-s SSD-m van, 16 KB-os lapmérettel, 24 MB-os blokkmérettel (1 blokkban 1536 NAND lap van), és 4KB clusterméretes ext4 partíciókat használok rajta, 512 bájtos logikai szektormérettel. A partíciók 1024K-n vannak alignálva. Ez azt jelenti, hogy a partícióim első 23 megabájtja (1472 lapja vagy 5888 logikai klusztere vagy 47104 logikai szektora) átlóg blokkhatárokon. Az ezek után lévő többi szektor, lap nem lóghat át blokkhatáron, ami a tárterület 99,99%-át jelenti.
A gyakorlatban tehát ezzel annyit bukok, hogy ezeknek a szektoroknak a törlése lassabb egy nagyon minimálisan, talán már ez sem mérhető. De mi annak az esélye, hogy pont az ezekre eső blokkot érinti a törlés? Nagyon minimális. Szóval a gyakorlatban nincs semmi értelme blokkméret alapján alignálni, felesleges önszopatás. Nem nagy áldozat, mert maximum 23 MB veszteséggel járna az első partíció előtt a kihasználatlan terület, de nekem pl. nem tetszene, hogy emiatt nem feltétlenül lennének egész GB-tal osztható partícióméreteim. Ez utóbbi akkor jön jól, ha szétcsesződne a partíciós tábla (bár GPT-n ilyenkor van belőle több másolat), könnyű rekonstruálni a partíciós táblát.
Persze továbbra sem lehetetlen, mert csinálhatnám úgy, hogy partícióméretek ne csak 1 GB-tal, hanem 24 GB-tal legyenek oszthatóak (pl. az első partíció 48 gigás, a második 240, a harmadik 480, stb.), de ez felesleges matek, meg helypocsékolás az első partíció előtt. Ez ilyen tipikus német precízkedés, hogy 0,00000001% előnyért szopjuk, hogy elméletileg is maximálizáljuk a lehetőségeket. Nehogy egy krumlihéjnyi valami is pocséka menjen.
Arról nem is szólva, hogy az adott SSD blokkmérete elég nehezen deríthető ki adott esetben. Az SSD gyártók fel sem tüntetik, hanem be kell azonosítani a NAND típusát (ha ezt sem találni meg online, akkor szét kell szedni az SSD-t, vagy leszedni róla az M.2 matricát, ami azonnali garivesztés, és megnézni milyen NAND van rajta), majd a NAND gyártójának valami részletes technikai spec sheetjéből nyomozható ki. Tényleg nem éri meg vele szívni.
-
-
Frawly
veterán
Ezt még nem volt időm tesztelni, mármint a blokkméret alapján történő alignálást, de már előre rájöttem, hogy hülyeség lesz.
Tegyük fel, hogy nincsenek blokkméret alapján alignálva a partíciók. Ez csak a partíciók első és utolsó blokkját befolyásolja lényegében. Ez pedig kevés ahhoz, hogy sebességbeli hátrányt vagy élettartamnövekedést hozzon.
Nem véletlen, hogy csak ilyen ködös német fórumok írnak erről a blokkméret mentén alignálásról, és ehelyett midenki a sztenderd 1 megás partícióeltolást használja, amit a particionálóprogik és telepítők alapból alkalmaznak.
Persze ki fogom próbálni, mert nem kerül semmibe, de már előre látom, hogy nincs értelme, nem javít majd semmin. Nem is egy nagy áldozat, csak felesleges.
-
eddie1978
senior tag
Úgy tűnik, hogy marad. Minden működik amit eddig próbáltam. Appimage-ből tudom használni a Goldencheetah és a Hugin programot is. Ez nagyon tetszik. Gyorsabb sokkal a működésük is. A Goldencheetah 2-3 másodperc alatt indul és stabilan. Mindig betölti az edzés adatokat. Arch Xfce alatt sokkal lassabb volt és sokszor újra kellett indítanom, hogy betöltse rendesen amit kell. Hugin is gyors bár az alapból is gyorsult az utóbbi hónapokban.
Szerintem ez bárkinek ajánlható napi használatra. Nagyon egyszerű kezelni. Ami az őrületbe kergetett az Xfce alatt, hogy mindig átált a billentyűzetkiosztás ha ablakot váltottam. Ez itt most nincsen.
Amitől tartottam, hogy az Xfce mint lightweight de után a Gnome lassabb lesz. Nos nem. Pörög szépen. Simán van olyan gyors ha nem gyorsabb.Érezhetően gyorsabb össz globál mint a korábbi Arch telepítés.
Amint írtam a telepítés next next ok reboot és használható. Pár perc az egész. Számomra sokkal átláthatóbb mint a céges Win10.
Ami nem ok, lehet codec hiány, az a Google Photos és a Vimeo video lejátszás nem megy. Photosnál nem működik az MPV lejátszás, míg a Vimeo-nál igen.
Ellenben Youtube alacsonyabb CPU terheléssel megy mint az előző rendszeren a Chromium alatt. Itt sincs HW decoding Firefox alatt sem.
Viszont most vettem észre, lehet eddig is volt csak nem figyeltem, hogy cicereg a gép.Ami még jól működik és Xfce alatt nem volt jó az a kijelző fényerőszabályzás. Itt lemegy nullára a jelzőcsík de a fényerő minimumra állítódik. Xfce alatt a jelzőcsík nulla állapota lesötétítette a kijelzőt teljesen. Ezt úgy tudtam kikerülni, hogy teljes fényerőre fel, majd onnan csavartam le minimumra. Akkor jó volt.
Lehet, hogy amiket írtam, simán megoldhatóak de nincs kedvem/időm pöcsölni már. Eszköz a gép nekem már és nem cél, hogy piszkáljam.
Akku:
A lemerítés feltöltés ciklus már többször megvolt. Nem nagyon változott. Tegnap pont láttam ahogyan 34%-ról 6%-ra esik egy pillanat alatt. Ez van. (Kacérkodom egy Ipad Pro 11 256GB változattal a video/kép szerkesztés miatt. Elég meggyőző amit a neten mutatnak.) Bár a Shotcut sokat fejlődött tavasz óta, de fényévekre van a Youtube linken lévő videótól. Akkor még egy sima crossfade is megakasztotta a szerkesztőben visszajátszva az anyagot. Most ez folyamatos. Stabilabb is lett. Alakul.
-
Shyciii
veterán
Bizony a két színnél több nincs. Hálistennek én ezt preferálom, nincs szükségem nagyobb "csicsára". Viszont az már aggaszt, hogy a DPI állítását nem támogatja. FULL HD-s 15,6"-os notin ez még nem olyan nagy baj, de azért pl Chromiumnál szükség volt a megjelenített betük esetén a 120%-os beállításra, hogy kellemes legyen olvasni. Ezt is említették neki, de a DPI-t se óhajtja belerakni. Szal félek. hogy pár éven belül annyira elmaradott lesz az Openbox, hogy már a stabilitásából is veszni fog, és akkor kereshetek helyette mást. Márpedig ha jól tudom, hogy kifejezetten ilyan WM nemigen van. Mármint olyan, hogy a Tiling és a DE-k között helyezkedik el ilyen kellemesen, és stabilan működik.
-
Shyciii
veterán
És a legnagyobb baj, hogy a fejlesztőjében nincs is hajlandóság, hogy komolyabban hozzányúljon, pedig sokan nyaggatják.
Amúgy nem tom hogy itt hányan használják a Remmina programot távasztalra, de most írtam a fejlesztőknek, hogy tegyenek bele egy új funkciót, mely azoknak lenne hasznos, akik újratelepítik a rendszert, vagy egyszerre kell több passwordöt változtatni, mert bár van ilyen funkció benne, de figyelmen kívűl hagyja azt, hogy valaki a szerverhez való user/password különböző, ha használ RD Gateway user/password-öt. Pl nálam is. Úgyhogy kézzel kellett egyenként változtatnom vagy 40db szervernél így. Rettentő korrektek. Még aznap visszaírták, hogy köszönik az ötletet, és már látható is, hogy az 1.4-es verzió roadmap-jében már szerepel is a kérésem.
-
Shyciii
veterán
Igen tudom a +memória lenne az igazi, de ebben az évben kivitelezhetetlen lesz (autó motorjának és váltójának felújítása (ez most volt), nyaralás, magánműtét, motoros vizsga, motor + cuccok megvétele). Szal most minden másra kell költenem, de nem a notebookra.
Azért egy átlag user mikor belép egy üres Openboxos felületre, valszeg programhibára fog gyanakodni, mert egy nagy szürkeséget lát. Egyedül jobb clickre jön elő egy menü, ami 90%-ban kamu dolgokat ad ki
Onnantól kezdve vagy vadászik AUR-ból GUI-s programokat amikkel lehet ezt-azt állítani, vagy szépen kézzel szerkesztgetni az xml alapú fileokat. Ezutóbbit éri meg, mert az elején ahogy néztem 1-1 frontend-et csináltak pár funkcióhoz, de nem az igaziak. Érdemesebb megtanulni az xml fileok felépítését, meg egy kis python nyelvet. Amúgysem árt, mert ha követjük a minimalizmust, akkor a tálca ami mondjuk legyen polybar vagy akár tint2 ahhoz úgyis megint config fileokat kell szerkesztgetni, és megint csak xml vagy python, aztán jön a conky, dettó érteni kell a nyelvét, úgyhogy a GUI-s állítóknak ezen a szinten javarészt leáldozott.
Nagyon szeretem az Openbox-ot, de már egy jó ideje nincs fejlesztve, és félek, hogy ahogy halad előre a Linux, egyre kevésbé lesz kompatibilis vele, és a végén oda jutunk, hogy nem lesz már stabilan müködőképes. Pedig most zseniálisan stabil, egyszer sem fagy be, lassul be. KDE, Gnome, XFCE, Deepin mind-mind volt valami zűr (fagyás, nuku reakció) mikor anno probáltam. -
Shyciii
veterán
Én Gnome-nak anno 2x adtam esélyt. Mind a kétszer gyorsan elbukott. Olyan érzésem volt, mintha olyan embereknek csinálnák, akik még életükben nem láttak számítógépet, tehát rettentően egyszerű, szájbarágós, átkonfigurálhatatlan. Ebből a szempontból a KDE jobb volt. Egészen addig, mig el nem kezdett foglalkoztatni a minimalista rendszerek, mert akkor igen gyorsan feltűnt, hogy azaz én világom. Gondolkoztam, hogy mielőtt UEFI átállás miatt komplett rendszer, sőt komplett SSD gyalulás volt a GPT miatt, hogy előtte felrakom az i3-at is, de ab abszolút minimalista tiling rendszerek már nem jönnek be nekem annyira. Egy egyszerű 15"-os notebookon nem tudnám az előnyüket kihasználni, nem sok minden fér el egy képernyőre. Viszont azért az ablakok gombbal való helyezgetése, nagyítása, kicsinyítése, szétosztása 2-vé megtetszett, úgyhogy azért azt megoldottam Openbox alatt.
Közben eszembejutott, hogy elfelejtettem, hogy az előző változatban a swappiness-re mennyit állítottam be, úgyhogy most kapott egy 30-as értéket. SSD + 4GB RAM memória + 2GB SWAP (ezt még sosem léptem túl), szerintem ezzel nem lövök bakot. Főleg úgy, hogy a legtöbb memóriát akkor foglalom, mikor egyszerre közel 60db gépre RDP-zek be a Remminával. -
Shyciii
veterán
Frawly
KDE-s Wayland? Most a Waylandnek nem az lenne az értelme, hogy egy egységes szabvány legyen, és mindenki azt használja? Most akkor ezt is mindenki csűri csavarja, és nem lesz egységes?
A LightDM-re az Arch Wiki azt írja, hogy támogatja a Wayland-et: https://wiki.archlinux.org/index.php/LightDM
Én élvezem a testreszabást. Jobban, mint egy agyontelepített kész DE-t használni. Engem az éltet, hogy bütykölhetek. Épp ezért tértem át Openbox-ra. Előtte megnéztem, hogy pl ki miket valósított meg Openbox, i3 alatt, és amik tetszettek, azokat egyenként a saját rendszeremen is megcsináltam. Volt amihez 2-3 perc alatt lehetett megoldást találni, és volt, amihez kellett fél óra is. A hosszabbak javarészt a notebook léte miatt voltal. Ilyen pl a fedél lecsukásakor zárolja a rendszert. Ezt teljes valójában meg sem találtam sehol az én felállásomhoz. De azt megtaláltam, hogy mi és hogyan vezérli a fedél lecsukásának eseményét. Az meg elég volt ahhoz, hogy módosítsam az én képemre.
-
Belefér, de szét van szórva, a Linuxos programok topik mintájára nem lenne elvetendő ötlet egy helyen kezelni a témát, egy jó összefoglalóval az elején. Így gyakorlatilag fragmentált nagyon és senki nem talál semmit, hanem kérdez egyből.
Ez a téma ugyanúgy érdekelheti a Debianosokat, Fedorásokat, mint az Archereket, Gentoosokat (lehet, hogy egyes szám elég lett volna itt)
A Wayland WM-es kalandjaimat a Linux OFF topikba szoktam írni a magam részéről, mivel ott semmi nem OFF.
Na látod! Akit érdekel a WM téma, örömmel olvasná ezeket is.....
Na mindegy, csak egy ötlet volt.
-
A klónokról nem tudok nyilatkozni.
Ahhoz képest azt emlegetve cikiztél! Ja és az Eltées Eleméreket is jegyeztem.
De az Arch-ban az a poén, hogy valóban nem DE-s felhasználóknak készült, hanem univerzális próbál lenni, hogy szerveren, meg minimalista konzolos, terminálos, WM-es felhasználáshoz is jó legyen. Persze felrakhatsz rá DE-t is, az kényelmesebb.
Potosan emiatt kezdtem átolvasni, mi a helyzet Arch topik terén, de azt szűrtem le, hogy eléggé égető lenne már egy WM-es topikot nyitni, mert gyakorlatilag a WM lényegét meg nem értve de büszkén és folyamatosan blogolja botladozásait ide átsértődött kollégátok.
Illetve azért kezdtem átnézegetni a hsz-eket, hogy lassan.......de ez csak régen volt Arch topik, fene se kíváncsi WM-es blogolásra. Még pár évet Eltées Elemérkedek inkább.![;]](//cdn.rios.hu/dl/s/v1.gif)
Nyilván ha pl. felteszed Archra a Cinmanót, akkor az hoz magával minden függőséget, dbus, X.org, mesa, login manager, témák, default alkalmazások, stb..
Jó esetben egy részét a függőségeknek, pár éve már próbáltam. Amúgy meg logikus, hogy felrak mindent, hogy működjön, amiket használni akarok, ha már az öreg desktop bírja. Nem szenvednék évekig WM-ekkel, csak azért, hogy áltassam magam, woooow nekem ez is megy, aztán telepakolom QT meg GTK mix-szel és szidom a fejlesztőket, hogy fapados WM-re miért nem csinálnak ezer témát!
Szóval csinálj egy WM topikot, szerintem lesz aki hamar belakja, plusz a válaszaidból egész jó kis tudásbázis képződik lassan. (ill nem is lassan)
-
Emlékszek anno uby kollégának is természetes volt, hogy a mesa csomag meg a wifi/cpu mikrokód, stb. firmware-ek ott vannak minden disztrón, míg egyszer csak valami Arch-klónon kellett észrevegye kellemetlen meglepetésként, hogy ezek a dolgok nem olyan mindenhol magától értetődően jelen lévő alapok, mint azt ő korábban naivan gondolta.
Igazad van amúgy, én voltam marha, pedig szkeptikus voltam, de ti annyira nyomtátok ezt a Manjaro nevű archklónt, hogy lenyomta a Mint-et is, tuti felhasználóbarát, a róla szóló cikk is úgy harangozza be, hogy ez a legjobb kezdőknek, el lehet felejteni a terminalt.....etc.
Ezek szerint csak én láttam jól eddig, szóval lófakk ass neked!
Én koromban meg naívan...... Egyébként ezek a csudaklónok nem desktop Linuxnak készülnek?
Nem?
De!LFYA
(kicsit későn reagálok, de eddig hanyagoltam az Arch topikot, szóval aki emiatt beszól......)
-
Shyciii
veterán
Csak a GDM támogatja a Wayland-et? Arch Wiki szerint elvben támogatja a LightDM és az SDDM is. Aztán hogy mennyire működőképes azt már nem tom, de az Intel GPU-mmal anno nem fagyogatott az SDDM mikor Manjaro-ztam, a LightDM meg jól működik amióta pure Arch-ozom. Sima konzolon én is gondolkodtam, de a probléma, hogy nem tudtam megoldani a notebook lockolását úgy, hogy a konzolra dobjon. Persze van slock, de valamilyen olyan bűn ronda (nem mintha a csicsát szeretném, ezért is van lightdm), de azért nézzen ki valahogy, ha már grafikus felület.
Amúgy most hogy újrahúztam a rendszert, kiderült, hogy hiányosan dokumentáltam, hogy mit kell csinálnom, hogy a fedél lecsukásakor zárolja a rendszert, de hálistennek azért rájöttem, hogy mit hagytam ki a scriptemből (mert ugye mindenféle guis bloat-ot nem akartam erre).
-
Shyciii
veterán
Nm-appletben nekem sosem kellett a vezetékes nethez felvenni kapcsolatokat dinamikus ip használata esetén, csak a wifi kapcsolódás miatt. Most otthon kipróbáltam a vezetékes kapcsolódást a routerhez, és azonnal kap ip-t bárminő változtatás nélkül ahogy kell. Szal a menlóhelyen változtattak valamit amióta nem használtam a kábelt.
Amúgy a Tint2-t te szeretted? Én gyűlöltem a korlátoltsága miatt, úgyhogy váltottam Polybar-ra.
, de az aurhelperek is érdekelnek.
(mármint ha parancssorból lett indítva előtte a frissítés.)
. Megcsináltam a módosítást konfig fájlban, majd restart.
viszont gksu helyett lehet nem artana mast talalni. 
Sajnos a mikrokód betöltése sem szünteti meg a hibát, néhány alkalommal fekete ahogy kell a konzol, de kikapcs és másnapi bekapcs után szürke konzollal indít megint. Különösen telepítéskor kellemetlen, nem jó a szemnek 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
BoB
- Csere-Beszámítás! Gigabyte Aorus Elite RX 9070 XT 16GB Videokártya! Bemutató darab!
- Telefon felvásárlás! Samsung Galaxy A15, Samsung Galaxy A25, Samsung Galaxy A35, Samsung Galaxy A55
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- MSI CYBORG 15 A13V
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest