- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Magga: PLEX: multimédia az egész lakásban
- Tomasz72: Ventilátor upgrade
- Elektromos rásegítésű kerékpárok
- Chosen: Canon 5D II - portrézás 2025-ben
- Szevam: „Rendszerleállás” – egy AI képzeletbeli halál utáni élménye
- bambano: Bambanő háza tája
- Geri Bátyó: B550 szűk keresztmetszet, de mi és miért?
-
LOGOUT
Arch Linux topik
Új hozzászólás Aktív témák
-
Archttila
veterán
Frissult a
libmodplug
Name : libmodplug
Version : 0.8.9.0-5
Description : A MOD playing library
Architecture : x86_64
URL : http://modplug-xmms.sourceforge.net/
Licenses : custom
Groups : None
Provides : None
Depends On : gcc-libs
Optional Deps : None
Required By : ffmpeg
Optional For : cmus
Conflicts With : None
Replaces : None
Installed Size : 366.09 KiB
Packager : Andreas Radke <andyrtr@archlinux.org>
Build Date : Mon 02 Jan 2023 08:17:31 AM CET
Install Date : Mon 02 Jan 2023 12:30:21 PM CET
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By : Signature
-
-
Sonja
nagyúr
Na, most már ír hibát is terminálban.
SystemLocale hu_HU
SystemLanguage hu
SystemEncoding UTF-8
DefaultSystemCodePage 65001
DefaultFileSystemCodePage 65001
DefaultRTLFileSystemCodePage 65001
XInitThreads: 1
[FORMS.PP] ExceptionOccurred
Sender=EInvalidOp
Exception=Invalid floating point operation
Stack trace:
$00007F761A4795AA in /usr/lib/libmodplug.so.1
$AFB825E294BA1100 in
Exception at 00007F761A4795AA: EInvalidOp:
Invalid floating point operation.
TServerListnerThread.DestroyLátszólag elindul, de nincs sehol. Érdekes, mert ez a libmodplug hanghoz köthető?!
Ötlet?!
Szerk.: Arch fórumon van topik is, és a libmodplug visszaváltása eggyel régebbi verzióra, bizony megoldja a problémát!
Érdekes.
-
-
attilav2
őstag
Én már régóta openbox+tint2+sakura+xscreensaver+thunar+pcmanfm-t használok a nagysúlyú desktopok helyett,(rimuru leírása alapján, azóta változott pár dolog, de utána lehet googlezni+arch wiki) sokkal gyorsabb, és jóval kevesebb gond van vele, igaz macerásabb a beállítása, de csak egyszer kell megcsinálni, a konfigok lementhetők és újratelepítéskor visszamásolhatók.
-
#68216320
törölt tag
Ezt egy kicsit részleteznéd? Mert én is belefutottam és nem tudom mi legyen a dependency-vel.
$ sudo pikaur -Syu
:: A csomagadatbázisok szinkronizálása...
core naprakész
extra naprakész
community naprakész
multilib naprakész
:: Starting full AUR upgrade...
Reading repository package databases...
Reading local package database...
hiba: nem sikerült előkészíteni a tranzakciót (nem sikerült kielégíteni a függőségeket)
:: wxgtk-common eltávolításával megtörik a(z) 'wxgtk-common' függőség amit wxgtk2 kér
-
Archttila
veterán
Csak ugye Arch Wiki meg azt mondja hogy:
MPD is configured in the file mpd.conf(5) which can be located in various paths depending on the setup chosen (system-wide or per-user). In short, the two common locations used are:
1.
~/.config/mpd/mpd.conf
in per-user configuration mode, this is the first location
2. searched,/etc/mpd.conf
in system-wide configurationEbbol en arra kovetkeztetek, hogyha sudo systemctl start mpd.service paranccsal inditom a service-t, akkor eloszor a ~/.config/mpd alatt fogja keresni a konfigot, es csak utana az /etc/ -ben.
-
Siriusb
veterán
Persze, meg fog jelenni minden. Én régen utáltam a KDE-t, mára megszerettem, ezt használom. Openbox is nagyon jó, csak azt is meguntam.
KDE-ben mindent megkapok készen. Érdemes áttérni a qt-s alkalmazásokra, igazából gtk viszonylatban talán csak Meld-et és a gThumb-ot tudnám hirtelen mondani, ami jobb a qt-s párjuknál. Na jó, ott van még a Geany is, de lehet ez már csak megszokás kérdése. -
Archttila
veterán
Nem sikerult megszokni, esetleg szimplan csak nem tetszik, vagy ki sem probaltad?
Nekem meg már az egerészés idegen... pedig még visszonylag newbie vagyon tiling fronton.mikor is kezdtem, 2020 nyar vege vagy szeptember kornyeke... nem emlekszem mar pontosan.
Monjuk amikor nagyon benne vagyok akkor azert bevillan, hogy ez most egerrel mennyivel tobb ido lett volna kivitelezni
orul is neki a felesegem amikor este mecha billel megy a zuzda
-
growler
őstag
Köszi ! A Garuda fórum eszembe sem jutott.
Ezek szerint nem vagyok egyedül.
Várok 1-2 napot mert ha minden igaz, a 3 telepíthető pamac közül lehet hogy csak
azt érinti a probléma amelyiket én választottam. - Biztos hogy nem a Pamac-Nosnap-ot."Eltávolítottam és telepítettem a Pamac-Nosnapt. Ez rögzítette a problémámat, amit használok a PAMAC-t."
-
zoltanz
nagyúr
Ubuntu-n nekem is a
pulseaudio
mellett fut apipewire
. lekérdezéskor hanszerver:PulseAudio
(onPipeWire
0.3.19)
Viszont mikor eltávolítottam a pulseaudiot felrakta pipewire csomagokat . inxi szerint ugyan nem aktív, de attól még futhat egy mélyebb rétegben sztem:
Sound Server: ALSA v: k5.15.0-2-amd64
-
Archttila
veterán
Köszönöm de sajnos nem működik. Azért biztos ami biztos megnéztem imv-vel is de azzal sem jó.
Marad a régi felállás imv-vel.Viszont közben találtam egy hasznos okosságot:
for_window [title="(?:Open|Save) (?:File|Folder|As)"] floating enable, resize set width 1030 height 710
még pár év és összeáll ez...
-
Frawly
veterán
Ja, mondtam én, hogy nem nehéz. Sok felhasználó azért fél tőle, mert nem érti hogyan működik, meg ilyen Buguntu telepítő összegányolja neki automatán nem működőre, vagy mint ubyegon, hogy kifogtak nem szabványos UEFI implementációs gépet, ahol az UEFI boot Windows only-ra van bedrótozva. Persze ez utóbbit is meg lehet oldani, csak nem olvasnak utána. Ebből meg az a mítosz alakul ki, hogy az UEFI boot szar, meg nem működik, meg lehetetlen, meg így meg úgy.
#8075 sati: a DE-k nem nyúlnak a default shellhez. Ő állította át a user accountban. Én is átállóban vagyok, a /bin/sh symlinket lecseréltem /bin/bash-ról /bin/dash-ra. De ez a scriptshellt cseréli le. A dash egy minimalistább, gyorsabb shell, ami jobban POSIX szabványos, szemben a Bash-sal. Pár héten belül a Bash interaktív shellt is lecserélem zsh-re. Meg a dwm-bspwm váltás is sok hete csúszik. Pulseaudio-Pipewire váltás meg egy hete volt meg.
A váltás nem megy azonnal, mert zsh alatt is ki kell kísérletezni beálításokat, pl. vi-mód, prompt csere, autokiegészítés, stb.. Persze mindezt oh-my-zsh nélkül, saját kútfőből. Az oh-my-zsh lényegében csak egy pluginmanager, ami a zsh-be tud felhasználói scripteket és beállításokat importálni. De ilyeneket kézzel is tudsz magadnak írni a zshrc-be, nem kell hozzá külön bloatot feltenni.
Gépösszerakósdival csak annyiból nem jó várni, hogy ha magyarban vetted, helyi boltban, akkor főleg célszerű 3 napon belül összerakni, hogy ha valami nem működik, hibás, akkor 3 napon belül visszajuttatva azonnal cserélniük kell, nem ülhetnek rajta 15-30 napig ilyen-olyan bevizsgálás, javítás, stb. címén. De ha online vetted is, akkori is meg 14 vagy mennyi napon belül érdemes megejteni, hogy ha hibás, el tudj állni a vételtől.
-
attilav2
őstag
Openbox + tint2 tálca egy ideális kezdő pálcika wm, Rimuru arch telepítési blogjában van róla leírás, illetve jó még az Arch openbox wiki, Debian openbox wiki
-
Frawly
veterán
Csinálj UEFI-t. Jobb, gyorsabb, egyszerűbb. Arch Wiki systemd-boot szócikkét nézd.
Az UEFI boothoz csak 1 extra partíció kell, de még ez se extra, mert egyben a /boot szerepét is betölti. Egy kb. 100 megás, vagy kicsivel nagyobb FAT32 partíció, mindenképp 1 giga alatt adj meg neki méretet, Archnak nem kell sok hely, ha lesz mellette más OS is, akkor viszont nem árthat 200 mega felett adni, akár 500-ig is. A típusa mindegy is, de „EFI System” típus szokott lenni, és FAT32-re kell formázni, és így kell telepítéskor felcsatolni /boot-ként. Annyi, hogy UEFI bootnál a partíciós tábla ne dos/MBR legyen hanem GPT.
Lényegében az egész systemd-boot telepítése csak egyetlen bootctl install parancs. Meg az EFI partíción két .conf fájl szerkesztése kézzel, amibe megadod neki a bootmenü opcióit, és a kernelparamétereket, initramfs nevét. De cserébe se GRUB, se semmilyen nyomorékság nem kell hozzá, később nem törnek el ilyen hülyeségek.
UEFI BIOS-ban sem kell általában állítani semmit, a legtöbb gépen a deafult az UEFI boot vagy UEFI + Legacy BIOS boot. Bár én azért meggyőződnék, hogy a bootopció UEFI only boot-on legyen, az a legtisztább, nehogy elkezdjen az Arch iso mégis Legacy BIOS módban bootolni.
Az UEFI boot egyébként sok mindenben megegyezik a Legacy BIOS boottal. Annyi a változás, hogy az OS-ek a bootkódjukat többé nem a lemez 0. szektorába, az MBR-be teszik bele, hanem a FAT32-es EFI partícióra teszik .EFI fájlok formájában. Így több OS megfér egymás mellett kulturáltan, és nem írják felül egymás bootszektorát, és emiatt többé az OS-ek telepítési sorrendje is mindegy lesz. Az UEFI BIOS meg tudja kezelni ezeket az .EFI fájlokat, indítani. Ennyi a lényege tömören.
De az UEFI bootnak van egy csomó előnye. GPT partíciós táblával megy, amiben csak sima (nem göcsörtös) partíciók vannak, nincs vergődés többé ilyen elsődleges, kiterjesztett, logikai partíciókkal, nem kell bootflagekkel szórakozni, nem kell külön bootmanagert telepíteni (hiszen az UEFI BIOS egyben már bootmanager is, és tudja menedzselni neked az általa detektált EFI partíciókon lévő .EFI fájlokat).
Plusz az UEFI bootnak előnye lehet, hogy a gép az OS betöltése előtti eszközinicializálási időt lerövidítheti. Nem minden gépen, de néhányon ez lehet a helyzet. Hiszen ha nem hagyományos BIOS módban bootol, akkor nem végez el egy csomó, visszafelé kompatibilitás miatt benne hagyott hagyományos BIOS POST eszköztesztet, és kihagyva ezeket a sallangokat gyorsabban eljuthat a gép az OS betöltőjéig.
Meg most már így 2021-ben nem célszerű MBR Legacy BIOS bootot erőltetni, hacsak nincs annyira szükség az adott gépen, hogy valami legacy OS-t futtass, DOS, Win9x, XP, vagy hasonló.
A másik előnye az UEFI bootnak, hogy pl. Archnál csak egyszer kell megcsinálni. Utána megmarad, esetleges újratelepítésnél már hozzá se kell nyúlni az EFI partícióhoz, simán bootol majd vele az új telepítésű rendszer is, főleg, ha PARTUUID-kel hivatkoztál a root partícióra és nem particináltál újra. Ez jelentős kényelem a hagyományos MBR-es boottal szemben. Illetve előny, hogy ha nem is bootolna a rendszer egyszer, akkor is könnyű megjavítani, mert a FAT32-es partíciót minden OS olvassa, írja és csak szöveges config fájlokat kell a sytemd-boothoz szerkesztened, emiatt nem kell speciális Live rendszert, meg GRUB javítókonzolt beizzítani, hanem bármivel megjavíthatod a dolgokat. Ez se elhanyagolható.
-
Apollyon
Korrektor
Látom nem spóroltál a tárhellyel.)
(#8049) sati: ha nem tolsz komoly dolgokat 8 giga ram is elég lesz, de az a jövőbiztos, ha 2x8 van... Bár ha jól olvastam, eddig 4-ből is kijöttél, akkor már a 8 is kánaán lesz.))) Böngészésre biztos elég és vm-re is, ha csak az lesz amit írtál.
Ha meg van steamed, akkor protonnal elvileg jól kell fussanak a dóz only cuccok is, pláne a régiek.
Mondjuk swayt sose használtam, csak i3 volt meg dwm, és szigorúan X, mármint, ha wayland alól tolod, akkor lehetnek gondok steammel is. -
Archttila
veterán
En is pentekre terveztem be a desktop gep szereldet
Eddig ARM-on zuztam az Arch-ot, de vegul ugy dontottem megy vissza a PI servernek a szekreny tetejere
Memoriaval kapcsolatban lenne egy kerdesem. Sway melle (kb 400MB az alaprendszer) szerintetek eleg lesz a 8GB RAM ugy, hogy idonkent azert befigyelne egy kis virtualizacio? Semmi komoly, csak amolyan disztro mustra.
Illetve a gaming vonalat egy ideje mar elengedtem, de a retro (2000 elotti) jatekok azert meg a szivem csucskei. Szoval idonkent ezeket is Windows alatt inditanam WM-be, mert korabbi tapasztalataim szerint azert a Wine sem tud mindent elfogadhatoan futtatni. Mondjuk az is igaz h jo reg volt mar mikor utoljara hasznaltam...Holnap adnam le a rendelest iPon-os ismerosnek, de ha azt mondjatok hogy felesleges a 16GB-os KIT akkor nem vennem meg.
-
-
hmmm
ezt nézted már? -
-
-
-
Frawly
veterán
Egyetértek, az imv az jobb, de a feh azért népszerű, mert X-es háttérképmegjelenítőnek használják. Amire persze megint lenne egyszerűbb, imagemagick display, vagy xsetroot, de azok (mint írtam) bugzanak egyes kompozitorokkal, míg a feh nem.
De ha csak képnézégető kell, akkor én is az imv-t preferálom, nem túl fapados, de mégis tudja a szükséges dolgokat, anélkül, hogy bloat lenne, még a vi/vim-billentyűket is támogatja. Plusz támogat X mellett Waylandet is. Az sxiv és feh túl fapados, a nagyobb képnézők meg túl bloatak imo.
Nálam ezek az imv, mpv, ffmpeg, imagemagick, sox alap toolok lettek, igazi svájcibicskák, sok mindenre jók. Lefednek majdnem minden kép/hang-nézési, szerkesztési, lejátszási, konvertálási igényt, ezek elsők között vannak, amiket felteszek minden rendszerre. Alig kell mellettük mást használni (nagyon ritkán használok persze flac, lame, oggenc, opusenc, qaac/neroaac enkódereket, de csak audio-nál teszek kivételt).
Az imagemagick-et kevesen ismerik, pedig az is jó, képmegjelenítésre, konvertálásra, font viewernek, stb.. zathura szintén, nem csak pdf-nézőnek, de ps, djvu, e-könyvformátumok nézésére is. vim (most már részemről neovim, de adott esetben Emacs, Micro, stb.) is elég univerzális, nem csak szövegszerkesztőnek, hanem IDE-nek, git-kliensnek, diff-ek nézésére, hexeditornak, dokumentumkonvertálónak (unix/win sorvégek, különböző kódlapok között váltás), terminál-multiplexernek, less-alternatívának, mindenesnek.
Terminálos fájlkezelők is ilyenek, jók doksinézőnek, tömörítő/mount felületnek, archiválónak, takarítónak, fájlkeresőnek, stb..
Ez a jó ezekben a minimalista CLI toolokban, hogy nem felhasználóbarátak, mivel nincs GUI-s interface-ük, ezért a kapcsolóikat, billentyűiket fejben kell tartani, meg kell tanulni, de ha valaki abszolválja, akkor utána mindent visznek, mint Kamaz a kereszteződésben. Többé nem kell vergődni, hogy jajjistenem, xy konvertálásához, szerkesztéséhez, nézéséhez mit tegyek fel. Igazából itt tud duplán kamatozni a vi/vim-tudás is, hogy annak a billentyűit általában minden ilyen tool ismeri, vagyis a legtöbb támogatja valamilyen szinten. Ez megint olyan, hogy kínkeserv megtanulni, de aztán nagyon hosszú távon kamatozik. Én ezért irigylem azt, aki még a 70-es években megtanulta a Unixot, C-t, vi-t, grep-et, sed-et, shellt, stb.-t, annak már 5. évtizede kamatozik mindaz a tudás, ami sokaknak a mai napig újdonság, meg megtanulhatatlan advanced tool, nem kell nekik állandóan X évente újat tanulni, mint ahogy anno a CP/M usereknek meg kellett tanulni a DOS-t, DOS után a Windowst, Windowson belül is jöttek-mentek a hülyeségek, Silverlight, .NET, PowerShell, Visual Basic, MS C, C#, stb., állandóan újat tanulni, most az web/electron-hájp, állandóan csak a fetrengés.
-
Shyciii
veterán
Köszi. Az usbreset-et az AUR-ból próbáltam, de nem találtam hozzá syntaxist, így amiket próbáltam azzal nem működött. Pl a másik linken próbált módon is xxxx:xxxx amit persze az lsusb által kiadott értékekkel próbáltam.
Most nézem, hogy az AUR-os usbreset az nem ugyanaz a linken levő usb-reset -el. Nah akkor ezt lefordítom mindjárt és próba.
-
Shyciii
veterán
Az oké, hogy MTP, de a SUBSYSTEM résznél őt is USB-ként érzékeli. Ez azért biztos, mert az android hackeléséhez fastboot parancsokkal szintán csak úgy működik, ha létrehoztam egy udev szabályt a magdott vendorid-vel, és ott is usb-t megadva működik azóta is. Itt viszont így sem.
-
-
Frawly
veterán
Az Xfce teszi ki, nem a Thunar. Ott nézd meg, ahol írtam: Settings Manager (magyarul nem tudom mi a neve, talán beállítóközpont), ott Desktop (Asztal) ikon, az előjövő ablakban Icons (Ikonok) fül, és ott lesz az alja felé, hogy az eltávolítható meghajtókat ne tegye ki asztalra:
-
Frawly
veterán
Nálam nem mutat ilyet a Thunar. Abban biztos vagy, hogy a Thunar teszi ki az ikonokat az asztalra? Az asztal beállításai között nézelődj:
In Settings Manager>Desktop, click the "Icons" tab. Clear the checkbox for "Removable Devices". I think this will remove all of the extra drive icons from your desktop. -
Frawly
veterán
Üdv az Archer táborban. Júbájgön el lesz keseredve, hogy már senki nem fahéjas mentázik. Amúgy te véletlenül nem az a hwsw-s csokis vagy?
Az eltávolító meghajtóra nincs sok ötletem. Az biztos, hogy az Arch nem mutat róla semmit. Legfeljebb a fájlkezelő, amivel nézitek. Pontosan melyik fájlkezelőt használjátok? PCmanFM, Nautilus, Dolphin?
Lehet a BIOS-ban a SATA vezérlő van RAID módban AHCI helyett, vagy a kernel egyes újabb SATA vezérlőkön lógó meghajtókat így kezel le.
Az Arch egyébként olyan, hogy ha megtanulod feltenni, meg mindent beröffenteni alatta, belőni a dolgokat, ahogy neked kell, akkor később már az életben nem lesz vele gond. Nincs külön disztrófrissítés, nem kell újratelepíteni.
-
Frawly
veterán
Nem értem mit csinálsz. Attól nem lesz neted, hogy a Wi-Fi-kártyát down állapotba küldöd.
Ami nálad hiányzik, az az, hogy hiába hoztál létre wifi-menu/wpa_supplicant profilt (benne SSID, jelszó), és mentődött is el, bootnál nincs olyan systemd service, ami automatikusan beizzítja. Ez lehet NetworkManager, lehet netctl, lehet wicd, és hasonlók. Az Arch Wiki alapján válassz egyet.
Az Openbox meg a többi kisebb WM ilyen minimalista. Nem kezelik helyetted a netkapcsolatokat, ahogy egy KDE, Gnome Shell, Cinnamon, stb..
-
Siriusb
veterán
Juj, ettől a sok sudo-tól megszédülök.
Ez nem Ubuntu.
Én feldobnám a networkmanager-t (és az nm-applet-et), hadd intézze, amit kell.
-
Frawly
veterán
Pedig a hivatalos iso-nak dd-vel kiírva bootolnia kéne Legacy-n is.
Az UEFI boottól miért zárkózol el? Azt értem, hogy fujj, meg nem kell, de ha véletlenül mégis kipróbálod, még be is jöhet. Pl. megvan az az előnye, hogy pl. systemd UEFI boottal tudod indítani a gépet, és nem kell GRUB, syslinux, stb.-vel szenvedni, meg külön frissítgetni őket állandóan. Én a helyedben adnék egy esélyt az UEFI bootnak. 2018-ban, pár nap múlva már 2019-ben nem elhamarkodott átállni. 2007-ben még joggal morogtak ellene, hogy a Windows sem támogatja normálisan, meg még túl új, kísérleti, de azóta eltelt néhány év.
-
anorche1
őstag
-
anorche1
őstag
Manjarot hasznalok, ott alapbol fel van rakva. Ahogy olvasom, nem ezzel lesz a gond, hanem a kernellel.
"Finally I have found a solution.
The intel_pstate driver has some problem with some Intel Hswell and later processors. Arch Linux users have noticed that this is the intel_pstate and the kernels internal timer problem. When timer is set to 300Hz (the default in arch) the intel_pstate driver is to sensitive. In Ubuntu this timer is set to 250Hz in a generic kernels.
When I test the linux-lowlatency kernel (whitch has set CONFIG_HZ to 1000) the problem seems to disappear (seems, because I have tested this in 4.11 lowlatency kernel and solution do not solve this problem). Battery lifetime increase from 2.5 to 4.5 hours for chrome html5video decoding. "
Hogyan tudnam modositani ezt a legegyszerubben a kernelben?
Új hozzászólás Aktív témák
Hirdetés
- Le Mans Ultimate
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Xbox Series X|S
- Battlefield 4
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Intel Core i3 / i5 / i7 / i9 10xxx "Comet Lake" és i3 / i5 / i7 / i9 11xxx "Rocket Lake" (LGA1200)
- Intel Dual Core 2000 felhasználók barátságos offolós topikja
- EAFC 25
- Tőzsde és gazdaság
- iPhone topik
- További aktív témák...
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Eladó Steam kulcsok kedvező áron!
- NEC MultiSync V421 monitor (42") 1920 x1080px
- Csere-Beszámítás! AMD Ryzen 5 9600X Processzor!
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB DDR5 RTX 4070Ti Super GAMER PC termékbeszámítással
- ÁRGARANCIA! Épített KomPhone Intel i7 14700KF 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Eladó szép állapotban levő Huawei P30 Pro kék 6/128GB 12 hónap jótállással!
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest