Hirdetés
- Luck Dragon: Asszociációs játék. :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- eBay-es kütyük kis pénzért
- GoodSpeed: Márkaváltás sok-sok év után
- D@reeo: Pi-hole és a Telekom Sagemcom F@st 5670 DNS beállítása
- N€T0X|N: Poloskahegy
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- bb0t: Ikea PAX gardrób és a pokol logisztikája
-
LOGOUT
Arch Linux topik
Új hozzászólás Aktív témák
-
growler
őstag
-
Frawly
veterán
válasz
growler
#7798
üzenetére
Még nem használtam debtap-et, de én ha .deb csomag kell, akkor eddig vagy Double Commanderrel bontottam ki, vagy az "ar -xv" paranccsal, és az úgy nyert tar.xz-t pedig szintén kézzel, tar-ral, vagy Double Commanderrel, mc-vel, vifm-mel, stb. és kézzel másolom be a szükséges mappákba.
De az is igaz, hogy nem ez a megfelelő mód rá, mármint ahogy én csinálom. A debtap-ot szokták javasolni hozzá, vagy az AUR-ból felrakható dpkg csomagot. Én csak azért csinálom így, mert nem akarok hozzá plusz szutykot telepíteni, hanem megoldom azzal, ami épp a rendszeren fel van téve.
-
Frawly
veterán
válasz
szuszinho
#7796
üzenetére
Szerintem az illető kernelmodulnak túl új a mostani 5.10.14-es kerneled, még egy régebbi verzió a függősége. Esetleg próbáld meg a linux-headers csomagot is telepíteni, hátha az megoldja. Kötve hiszem, de egy próbát megér. Ha nem megy, addig nem tudsz kernelt upgrade-elni.
-
szuszinho
őstag
Minden frissítéskor ez fogad:
==> dkms install --no-depmod -m i2c-ch341 -v 20190628 -k 5.10.14-arch1-1Error! Bad return status for module build on kernel: 5.10.14-arch1-1 (x86_64)Consult /var/lib/dkms/i2c-ch341/20190628/build/make.log for more information.==> Warning, `dkms install --no-depmod -m i2c-ch341 -v 20190628 -k 5.10.14-arch1-1' returned 10==> depmod 5.10.14-arch1-1Kell foglalkoznom ezzel?
(Egy RFLink gateway van az usb-n)
-
jimmy399
senior tag
válasz
attilav2
#7793
üzenetére
A képpel semmi gond nincsen, eleve a gép nem tud lejátszani 4k-t max fullhd-ben vannak meg filmek, meg eleve 1920 x 1200-as felbontásba állítom be a tv-t.
Windows alatt csak fullhd-t enged eleve, de ott persze semmi gond a hanggal.
Hálózaton kapja meg a gépem is a videót és onnan nézzük, mert párom laptopjáról van megosztva ahol vannak a filmek.Viszont! Arra, hogy a hdmi kábel okés az az, hogy van egy másik 40"-os tv-n ami Philips, és azon gyönyörűen megy a videó, nincsen semmi gond se a képpel, se a hanngal.
Párom laptopjáról meg eleve nem lehet HDMI-n összekötni a tv-vel, mert semmilyen szinten nem ad képet vele. Na? (Acer Aspire A315-54, Ryzen5 Vega8 gpu. Viszont a Philips tv-vel megy szépen a laptop ugyan azzal a 7 méteres hdmi kábellel.)
Szóval esélyes, hogy a TV a szar, olcsó volt, válogat is mit játszik le, szerencse, hogy a gyerekeknek lesz majd odaadva később.
-
Köszönöm szépen a segítségeket. Úgy tünik, hogy kezdem picit belakni a magam arch telepítéseit. Igaz, hogy egyelőre csak calam-arch telepítővel, de most már nagyon tetszik. Most végre megcsináltam (ez talán már örökös darab lehet) egy stabil swájci bicskát egy usbs-ssd-ből. GPT-re partícionáltam, de a lemez első 1Megás partíciója egy bios_grub partíció lett, majd az EFI, aztán a /, a swap, és a /home partíciókat tettem rá. Így bőven van hova menteni , illetve onnan a /home parícióból betolni fájlokat a gyógyítandó rendszerre, illetve rendszerből, hisz mindig mindenhol ezt a kis szerszámomat szeretném bootolni.
A telepítést egy hp250 G7-es (UEFI és Legacy is megy rajta) laposon csináltam. XFCE került rá, nem telepítettem rá direkt video drivereket, hanem hagyom, hogy bütyköljön magának a linux amit akar, hátha így lesz minden körülmények között bootolható. Lehet, hogy hiba, de a firefox felkerült rá, mert megszoktam és egy Nemo fájlkezelő is. Nem tudom, hogy GTK ill. QT viszonylatban ez hiba-e, de így lett, így kevesebbet kell terminálozni a fájlműveleteknél. Újraindulás után a /boot/grub mappába másoltam az /usr/lib/grub mappából az i-386-pc mappát, mert az kell majd a Legacy bootoláshoz. Ezután újra indítván egy live rendszerről Legacyban chroot segítségével meggyógyítottam a kisbicskám Legacy bootját is. Konstatáltam, hogy az UEFI telepítás ismét lerombolta az alapgépem Arch UEFI bootját, de azt megint meggyógyítottam Frawly útmutatásai alapján egy :sudo efibootmgr --disk /dev/nvme0n1 --part 1 --create --loader /EFI/Arch/grubx64.efi --label "Arch" --verbose
csatakiáltással.
Bootol a HP250 g7-es vason UEFI és Legacy módban is. Bootol az öreg Sony waio vpceh3l1e vasamon Legacyban és bootol a tiszta UEFI-s (de bootolásra finnyás) Asus x51na gumiragasztóval kitömött gépen is.
Mostan örülök.
-
attilav2
őstag
válasz
jimmy399
#7791
üzenetére
7m-res hdmi kábel szerintem már nagyon hosszú, különösen 4K-hoz, a képpel nincs gond csak a hanggal? Ajánlom az anydesk-et(android/android tv app) a desktop tv-re küldésére hálózaton keresztül. Ha AMD vga-d van akkor windows alatt szóbajöhet az AMD Link amit az adrenalin driver tartalmaz, van hozzá alkalmazás android/android tv-re, vga-s gyorsítást használ a desktop átküldésekor, így jobb mint az anydesk, de sajnos csak windows alatt elérhető mert kell hozzá az adrenalin driver ami linux alatt nincs
-
jimmy399
senior tag
válasz
jimmy399
#7791
üzenetére
Ez van a logban, amikor a hang eltorzul:
febr 07 19:11:57 jimmy-pc-arch rtkit-daemon[570]: Successfully made thread 125548 of process 125544 owned by '1000' RT at priority 5.
febr 07 19:11:57 jimmy-pc-arch rtkit-daemon[570]: Supervising 4 threads of 1 processes of 1 users.
febr 07 19:11:57 jimmy-pc-arch pulseaudio[125544]: Module "module-udev-detect" should be loaded once at most. Refusing to load.
febr 07 19:11:57 jimmy-pc-arch systemd[442]: Started Sound Service. -
jimmy399
senior tag
Sziasztok!
Lett nekem egy új problémám. Elég fura, de ti hátha tudtok segíteni.
Vettem egy hdmi kábelt, ami 7,5 méteres. Bedugtam a gépbe, és a Tv-be. A gép egy Asrock fm2-A75 Pro4-m, a tévé egy 50" 4K-s samsung tv.
Elkezdek lejátszani a tv-n egy filmet, az smplayerben átállítottam a kimeneti hangot a Tv hdmi bemenetére. Ahogy szól a film elkezd a hang kb 5-10-random percenként torzítani.
Kiadom a pulseaudio -k parancsot, és megjavul egy időre.Windows 8.1 alatt minden ok. Ott nincs hiba.
Mitévő legyek?
Linux jimmy-pc-arch 5.10.11-arch1-1 #1 SMP PREEMPT Wed, 27 Jan 2021 13:53:16 +0000 x86_64 GNU/Linux
pulseaudio Verzió : 14.2-2
smplayer Verzió : 21.1.0-1
Most megpróbálom VLC --- Ott is ugyan ez. Verzió: 3.0.12-1 -
Frawly
veterán
Nem olyan. A PPA egy külső tároló, amiben már lefordított binárisok vannak. A fejlesztő git-es tárolóján maga a program forráskódja van, és ebből lehet több ág, jelenlegi legfrissebb (általában napi aktuális, master, current, dev), kiadás (release), kiadásra jelölt (RC), stb.. A -git végű AUR-os scriptek a legfrisebb kiadást töltik le a forráskódból és azt forgatják. Ennek egyébként még van egy olyan hátránya, hogy a -git végű hamarabb frissül, így ha gyakran ráeresztesz AUR-os frissítést, akkor állandóan frissülni akar, meg újrafordítani. A sima, nem-git-es változat csak tényleg verzióugráskor, kiadáskor frissül, fordítódik újra.
#7789 _Dumber_: nem baj, egy próbát megért. Nem volt felesleges, mert így megtudtuk, hogy nem a kompozitor felelős érte, így vagy az a modul, ami kiteszi ezt a menüt, vagy a KWin ablakkezelő bugja.
-
Frawly
veterán
Abból a nem-git-es verzió általában a fejlesztő által stabilnak titulált kiadás (release), míg a git-es változat meg közvetlenül a fejlesztő git tárolójának aktuális ágából lehúzott, épp az aznap aktuális legfrisebb dev verzió. Ezt azért nem bétának nevezik, mert a béta is kiadásalapon menne, ez meg ilyen folyamatos snapshot-szerű valami. Ilyenkor megéri általában a git-eset felrakni, és a nem-git-est csak akkor, ha a git-essel baj lenne. A git-es általában frissebb, több feature lehet benne, de cserébe a bugok esélye is megnő, ezért is töltenek fel az AUR-ban két változatot, hogy ha eltörne egyik, akkor a másikban egy stabil verzió még használható maradjon.
-
Frawly
veterán
válasz
_Dumber_
#7783
üzenetére
Ez mindenképp bugnak tűnik. Tesztképpen kapcsold ki a kompozitort. Akkor csinálja-e.
Egyébként meg screenshotot is tudsz lőni, állítsd be PrnScr-re, hogy ne a képlopó alkalmazás induljon, hanem egyben már a screenshotot is lője bele egy előre bekészített mappába. Akkor csak egy gombnyomás.
-
_Dumber_
őstag
Ha már wayland akkor ez miért lehet?
Arch/KDE/multimonitor alatt a "felugró információs ablak" a képernyő szélén látható.
(A kép szerkesztett, mivel nem tudtam képernyőképet csinálni róla. Ahonnan kivágtam ott természetesen minden normálisan látható.)
[kép]Valahogy így kellene (ilyen X alatt):
[kép]Ez BUG vagy beállítás kérdése?
-
Archttila
veterán
Persze nyilván igazad van, csak megörültem ennek a ficsörnek.
de akkor ezek szerint korán 
Időnként azért ránézek amúgy is van most más ami idegesít.A minidlna nem frissíti az elérési útvonalon megadott média dir-t, pedig a minidlna.conf-ba minden adott a normális működéshez:
minidlna.conf (ide vonatkozó része)
inotify=yesnotify_interval=12090-inotify.conf
cat 90-inotify.conf# Increase inotify max watchs per user for local minidlnafs.inotify.max_user_watches = 100000cache db file
ls -la /var/cache/minidlna/files.db-rw-r--r-- 1 minidlna minidlna 135168 Feb 6 16:40 /var/cache/minidlna/files.dbminidlna.service
[Unit]Description=minidlna serverAfter=network.target[Service]Type=simpleUser=minidlnaGroup=minidlnaExecStart=/usr/bin/minidlnad -SProtectSystem=fullProtectHome=onPrivateDevices=onNoNewPrivileges=on[Install]WantedBy=multi-user.targetSzerinted mi lehet a gond? A minidlna fut szépen, csak a médiakönyvtárat nem frissíti magától, így nekem kell állandóan újraindítani vagy a minidlnad -R paranccsal észhez téríteni.
-
Frawly
veterán
válasz
Archttila
#7778
üzenetére
Ez ilyen műfaj. A Wayland-támogatás a Chrome-alapú böngészőkben a legkísérletibb, és ez a böngészőcsalád áll a legrosszabbul ezekkel a gyorsításokkal. Mondom, attól, hogy waylandes WM-et használsz, még nem muszáj mindenből a Wayland only megoldásokat erőltetni. Nyilván, ha van valamire natív waylandes alternatíva, érdemes azt használni, mivel soványabb lesz, nem kell a rendszernek hozzá XWaylandet betöltenie, de utóbbit sokszor nem úszod még meg. Ez még sajnos odébb van, hogy minden Wayland-kompatibilis lesz és minden megy vele. Megy persze így is, XWayland-es pótlással, meg kisebb-nagyobb workaroundokat alkalmazandó, teljesen használható a hétköznapokban, csak tökéletességet nem szabad még elvárni. Ez mindig ilyen, ha korai technológiát adoptál az ember, vannak vele extra lépések. Bár még mindig inkább ez, hogy korai adopterként huszárkodni, mint ókonzervatívként elavult technológiákkal küzdeni (ilyen ősrégi protokollok és verziók használata, MBR-hez és legacy BIOS boothoz ragaszkodás, mikor nem kéne, XP-s Matyik, 2.6-os kerneles CentOS-ses népek, Gtk/Gtk+, Qt3-4 libeken rekedt programok, 32 bites libekkel és 32 bites rendszerrel, PAE-vel szenvedés, stb.).
-
Blasius
tag
Sziasztok,
Systemd lelkivilággal kapcsolatos kérdés következik...
Van egy scriptem (undervolter.sh; egy parancs van benne csak, ugyanaz amit ki adnék terminalban. Szóval a scriptnek csak le kellene futni, aztán kész).
Le akarom futtatni ha a rendszer bebootol, és miután suspendből feláll akkor is.
Csináltam egy servicet:
/etc/systemd/system/undervolterresume.service[Unit]Description=ScriptAfter=Suspend.target #*#*[Service]Type=oneshotExecStart=/usr/bin/undervolter.sh[Install]WantedBy=multi-user.target
Boot után jó.De suspend után nem fut le. A
#*#*-al megjelölt részt próbálom variálni. Próbáltam Before=...-t de próbáltam ...=Resume.target - et is. Valaki tudja hogy mi lehet itt az ideális beállítás? Vagy a script ha már egyszer lefutott (boot után) akkor utánna már nem akar többet lefutni?(Valójában nem értem hogy boot után amúgy miért jó, hiszen a
#*#*-rész miatt akkor nem is kéne futnia; én úgy értelmezem.)Esetleg ha a script a login után/elött futna az is jó lenne. (Azoknak nem tudum mi a .target)
Üdv
-
Shyciii
veterán
-
attilav2
őstag
Egy esetleges jövőbeli szívás ami a chromium használókat fogja érinteni
Hacsak addig el nem áll a szándékától a google.
Use Chromium? Sync Features Will Stop Working on March 15
Egy ideje már a google chrome-ot használom az aur-ból, rendszeresen frissítik.
Az edge-t is használom, bár vannak hibáid de tetszik(a renderelés minősége szerintem elég jó), nem működik az ms account sync egyelőre linux alatt, a legördülő menükben levő linkeket nem nyitja meg a linuxos verzió egyelőre(pl digi.hu), az aur csomagot nem frissítik rendszeresen de a kommentekben általában posztolnak az aktuális verziót letöltő/buildelő PKGBUILD fájlt -
"Ami a HP-t és az UEFI bootot illeti, ez egy ismert tény, ezt már többször leírtam ubyegonnak is, hogy miért nem bootol neki a Mint Cinnamonja, nem azért, mert az UEFI bootolás szar, hanem a HP az UEFI BIOS-ban lefixálta, hogy..."
Ubiegonnak azért sem megy az UEFI a HP üzleti notiján, mert egy ősrégi BIOS van rajta és fóbiásan kerüli a windowst és csak windows segítségével tudna rajta BIOS-t frissíteni. Én megtettem a BIOS frissítést ( lehet , hogy feleslegesen) majbex@rtam a folyamat alatt, de nem kellett flashelő emberhez fordulni utánna, mert sikerült.
Na kitöröltem a HP mappát az EFI -ből , remélem, hogy nem kellett az oda (a BIOS frissítés szemete lehetett.).
-
Köszöszönöm szépen! Győztél!!!!!! Örök hála +1 sör !
Majd még a 2002 és a 2004-es bejegyzést nem tudom, hogy mi célra van ott, s ha nem kell, akkor hogy törölhető.[noki@pista-hp250g7notebookpc ~]$ sudo efibootmgr --disk /dev/nvme0n1 --part 1 --create --loader /EFI/Arch/grubx64.efi --label "Arch" --verbose[sudo] noki jelszava:Timeout: 0 secondsBootOrder: 0001,2001,0002,3002,0003,2004,2002,0000Boot0000* Internal Hard Drive - KBG30ZMV512G KIOXIA BBS(HD,Internal Hard Drive - KBG30ZMV512G KIOXIA,0x500)................+0.0....#0.0?0.0.................................X..z.......A................................%x...Boot0002* ubuntu HD(1,GPT,074cea58-d9ed-47cd-a2cd-4d65c4163df7,0x800,0x32000)/File(\EFI\ubuntu\shimx64.efi)RCBoot0003* Windows Boot Manager HD(1,GPT,074cea58-d9ed-47cd-a2cd-4d65c4163df7,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................Boot2001* EFI USB Device RCBoot3002* Internal Hard Disk or Solid State Disk RCBoot0001* Arch HD(1,GPT,074cea58-d9ed-47cd-a2cd-4d65c4163df7,0x800,0x32000)/File(\EFI\Arch\grubx64.efi)[noki@pista-hp250g7notebookpc ~]$ efibootmgr -vTimeout: 0 secondsBootOrder: 0001,2001,0002,3002,0003,2004,2002,0000Boot0000* Internal Hard Drive - KBG30ZMV512G KIOXIA BBS(HD,Internal Hard Drive - KBG30ZMV512G KIOXIA,0x500)................+0.0....#0.0?0.0.................................X..z.......A................................%x...Boot0001* Arch HD(1,GPT,074cea58-d9ed-47cd-a2cd-4d65c4163df7,0x800,0x32000)/File(\EFI\Arch\grubx64.efi)Boot0002* ubuntu HD(1,GPT,074cea58-d9ed-47cd-a2cd-4d65c4163df7,0x800,0x32000)/File(\EFI\ubuntu\shimx64.efi)RCBoot0003* Windows Boot Manager HD(1,GPT,074cea58-d9ed-47cd-a2cd-4d65c4163df7,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................Boot2001* EFI USB Device RCBoot3002* Internal Hard Disk or Solid State Disk RC[noki@pista-hp250g7notebookpc ~]$ -
[noki@pista-hp250g7notebookpc ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 476,9G 0 disk
├─nvme0n1p1 259:1 0 100M 0 part /boot/efi
├─nvme0n1p2 259:2 0 16M 0 part
├─nvme0n1p3 259:3 0 155,4G 0 part
├─nvme0n1p4 259:4 0 506M 0 part
├─nvme0n1p5 259:5 0 155,5G 0 part
├─nvme0n1p6 259:6 0 156G 0 part /
└─nvme0n1p7 259:7 0 9,4G 0 part [SWAP]
[noki@pista-hp250g7notebookpc ~]$ sudo fdisk -l
[sudo] noki jelszava:
Disk /dev/nvme0n1: 476,94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: KBG30ZMV512G KIOXIA
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 42D183DC-B6B1-42E6-AB00-A5104B4E453F
Eszköz Start Vége Szektorok Size Típus
/dev/nvme0n1p1 2048 206847 204800 100M EFI System
/dev/nvme0n1p2 206848 239615 32768 16M Microsoft reserved
/dev/nvme0n1p3 239616 326148796 325909181 155,4G Microsoft basic data
/dev/nvme0n1p4 326150144 327186431 1036288 506M Windows recovery environment
/dev/nvme0n1p5 327188480 653295615 326107136 155,5G Linux filesystem
/dev/nvme0n1p6 653295616 980451327 327155712 156G Linux filesystem
/dev/nvme0n1p7 980451328 1000214527 19763200 9,4G Linux lapozó
[noki@pista-hp250g7notebookpc ~]$ -
Igen pedig először működött és a linux mint még most is működik párhuzamosan a windows bootjának a tönkretétele nélkül, ennek van egy efi fájlja a Microsoft\boot mappában és az valószinüleg egy átnevezett shimx64.efi, vagy arra mutat rá.
"Az efibootmgr kimenetedből nekem az jön le, hogy véletlenül MBR-rel particionáltad az adott meghajtót, vagy tévedésből egy másik, MBR-es meghajtód partíciójára hivatkozol (mert rosszat adsz meg az efibootmgr-nek)." ... Nem az egész masinában egy nvme lapka van , ott van alább a gparted képe . Ő a /dev/nvme0n1 ssd. Az efibootmgrnek a Gentoo efibootmgr wiki oldala alapján , annak mintájára adtam meg a paramétereket. Nem lehet hogy az a baj, hogy nekem a sudo efibootmgr -c -L "Grub_arch" -l '\EFI\Arch\grubx64.efi' szöveg helyett a sudo efibootmgr -c -L "Grub_arch" -l '\efi\EFI\Arch\grubx64.efi' szöveget kellene írnom ?
Kitakaríthatom szerinted a BIOS flashelés után az EFI mappában felejtett HP mappát, az nemigen kell oda.
Mindjájrt nézem az lsblk és fdisk -l kimenetet. Addig is köszi!
-
anorche1
őstag
Volt megint egy kis szabadidom meg kedvem, hogy kde -rol egyyel minimalistabb de -re valtsak, lxqt -re. Elkezdtem szepen belakni, de a legtobb problemat megoldottam vagy megkerultem, de egyel nem boldogulok.
Laptopok hasznalok, vegyes felhasznalassal. Van amikor a lapotop hangszorojabol szeretnem kerni a hangot, van amikro usb -s hangkartyarol, van amikor a hdmi kabelen keresztul, van amikor bluetooth -on.
pavucontrol-qt csomag segitsegevel tudok szepen bemenetet valtani, de a panelen a hangero allito kiegeszito ezt nem koveti le, es a laptop hangero gombjaira is az reagal.Tehat keves az, hogy pavucontrol -ban beallitom, hogy a hdmi -n szoljon a hang, mert a hangerot tovabbra is mondjuk a laptopon allitom. Egy default hanglejatszo eszkoz kde -n 2 kattintas, itt meg vagy 10.
Ti ezt hogy oldajatok meg? Valami script gyorsbillre rakva, mindengyik lehetseges kimenetre beallitva egy?
-
Frawly
veterán
Az szopás, akkor csak az marad, hogy arra a /boot/EFI/Microsoft/Boot/bootmgfw.efi fájlként másolod oda a grubx64.efi-t. Bár azt nem értem, hogy először akkor hogyan bootolt a Grub, mikor frissen telepítetted először. Mert ha ez a gond, már legelső esetben sem kellett volna bootolnia semmilyen általad most hiányolt „szép” bootmenünek, hiszen a grubx64.efi nem tudott volna elindulni.
Az efibootmgr kimenetedből nekem az jön le, hogy véletlenül MBR-rel particionáltad az adott meghajtót, vagy tévedésből egy másik, MBR-es meghajtód partíciójára hivatkozol (mert rosszat adsz meg az efibootmgr-nek).
Nagyon fontos lenne az efibootmgr kiadása előtt lsblk-val és fdisk -l segítségével (írja a partíciós tábla típusát) is tisztázni, hogy hogyan paraméterezed fel az efibootmgr kimenetét:
sudo efibootmgr --disk /dev/sdX --part Y --create --loader /EFI/GRUB/grubx64.efi --label "GRUB" --verboseItt X a meghajtó betűjele (esetleg ha NVMe meghajtó, akkor lehet a neve /dev/nvmeWnZ, ahol W, Z számok), az Y partíció száma, 1-től indítva. A --label "GRUB” helyett megadhatsz akármilyen címkét, pl. --label "Bla-bla", csak tudjad, hogy melyik bootbejegyzés melyik. Nem lényeges hogyan hívod, még akár lehet két különböző bootbejegyzésnek is egyaránt "GRUB" a címkéje, csak akkor hajlamos leszel összekeverni, mikor a Boot menüben választasz 1. GRUB, 2. GRUB, 3. akármi között, hogy akkor most melyik-melyik.
Nagyon könnyű összekeverni, hogy ha azt hiszed, hogy a /dev/sda meghajtóról van pl. szó, és közben meg épp másik betűjelet kapott, mert pl. valami külső meghajtó lett a gépen felejtve (pendrive, USB-s HDD), vagy egy Live rendszer vagy másik disztró alól próbálkozol. Kétszer is nézd meg, hogy jó meghajtót adsz-e meg neki, és hogy az valóban GPT partíciótáblás.
Tudom, baromi nyűg, nem felhasználóbarát, de ez a része még Windows alatt sem felhasználóbarátabb semmivel, ha nem bootol, akkor Windowsnál is a telepítőjét be kell bootolnod, ott elő kell szedned a Javítókonzolt, és ott a diskpart progival épp úgy ilyen elvont "sel disk akárhány", meg "sel vol akárhány" és bootrec parancsokat, meg mágikus szavakat kell a fejére olvasni. Tényleg nem könnyebb az sem semmivel, nem a Linux iránti elfogultság mondatja velem, végigcsináltam már ezt Windowson is, mikor egy régi HDD-ről egy új SSD-re klónoztam a rendszert, és nem bootolt UEFI-vel többé, elhasalt hibaüzeneteken. Sikerrel megjavítottam, de egy dekával sem volt könnyebb, mint a linuxos fdiskezés, meg efibootmgr-ezés. Sőt, még annyival rosszabb is a Windows megoldása, hogy nem ad annyi visszajelzést meg kimenetet.
-
Frawly
veterán
válasz
vargalex
#7760
üzenetére
Video accceleration nincs, de OpenGL vagy WebGL renderelésnek kellene lennie, és nála az sincs. Ami baj, mert így minden kirajzolandó elemet a proci számol, hangsúlyozom nem videóról van szó, hanem mindenféle weboldalelemről, kép, font, átlátszóság, stb.. Az is lehet, hogy a Chromiumnak nem tetszik a RPi4 GPU drivere, vagy csak az a része, amit a Wayland hajt.
A video acceleration az más, akkor a GPU nem a kirajzolást gyorsítja, hanem a videókodeket dekódolja ki (vagy encode-olja), hogy ne a procinak kelljen.
-
Az a baj , hogy ha meg akarom csináltatni a bootmenü pontot az efibootmgr progival akkor az arch partícióját MBR-nek teszi be GPT helyett és újraindítás után pedig luxálja.
[noki@pista-hp250g7notebookpc ~]$ sudo efibootmgr -c -L "Grub_arch" -l '\EFI\Arch\grubx64.efi'
Timeout: 0 seconds
BootOrder: 0001,2001,0002,3002,0003,2004,2002,0000
Boot0000* Internal Hard Drive - KBG30ZMV512G KIOXIA
Boot0002* ubuntu
Boot0003* Windows Boot Manager
Boot2001* EFI USB Device
Boot3002* Internal Hard Disk or Solid State Disk
Boot0001* Grub_arch
[noki@pista-hp250g7notebookpc ~]$ efibootmgr -v
Timeout: 0 seconds
BootOrder: 0001,2001,0002,3002,0003,2004,2002,0000
Boot0000* Internal Hard Drive - KBG30ZMV512G KIOXIA BBS(HD,Internal Hard Drive - KBG30ZMV512G KIOXIA,0x500)................+0.0....#0.0?0.0.................................X..z.......A................................%x...
Boot0001* Grub_arch HD(1,MBR,0x0,0x2000,0xee2000)/File(\EFI\Arch\grubx64.efi)
Boot0002* ubuntu HD(1,GPT,074cea58-d9ed-47cd-a2cd-4d65c4163df7,0x800,0x32000)/File(\EFI\ubuntu\shimx64.efi)RC
Boot0003* Windows Boot Manager HD(1,GPT,074cea58-d9ed-47cd-a2cd-4d65c4163df7,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Boot2001* EFI USB Device RC
Boot3002* Internal Hard Disk or Solid State Disk RC
[noki@pista-hp250g7notebookpc ~]$ -
Szóval tudom a "BIOS" bootmenüből bootolni a windowst és a linux mintet.
Az Arch bootolható a "Boot from efi file" bootmenü sorból, elnavigálván a .../Arch/grubx64.efi , vagy a .../Boot/bootx64.efi fájlig és arra kattintva indul az arch grubmenüje és bootol az arch.
Tanácsodra frissítettem a HP 250 g7-es noti biosát F23-ról F35-re , a frász majd ki tört. Furi módon ez a noti linuxxal jött ki, de csak windowsból lehetett frissíteni a biosát. A BIOS-ban semmi változást nem tapasztaltam.
A frissítő flashelő hagyott egy HP mappa szemetet (?) az EFI mappában. Ezt benne hagyjam?
/boot/efi/EFI/
├── Arch
│ └── grubx64.efi
├── Boot
│ ├── bootx64.efi
│ ├── fbx64.efi
│ └── mmx64.efi
├── HP
│ ├── BIOS
│ ├── BIOSUpdate
│ └── DEVFW
├── Microsoft
│ ├── Boot
│ └── Recovery
└── ubuntu
├── BOOTX64.CSV
├── grub.cfg
├── grubx64.efi
├── mmx64.efi
└── shimx64.efi/boot/efi/EFI/HP/
├── BIOS
│ ├── Current
│ │ ├── 08532.bin
│ │ └── 08532.sig
│ ├── New
│ │ └── 08532.s12
│ └── Previous
├── BIOSUpdate
│ ├── BiosMgmt32.efi
│ ├── BiosMgmt32.s09
│ ├── BiosMgmt32.s12
│ ├── BiosMgmt32.s14
│ ├── BiosMgmt.efi
│ ├── BiosMgmt.s09
│ ├── BiosMgmt.s12
│ ├── BiosMgmt.s14
│ ├── CryptRSA32.efi
│ ├── CryptRSA.efi
│ ├── HpBiosMgmt32.efi
│ ├── HpBiosMgmt32.s09
│ ├── HpBiosMgmt32.s12
│ ├── HpBiosMgmt32.s14
│ ├── HpBiosMgmt.efi
│ ├── HpBiosMgmt.s09
│ ├── HpBiosMgmt.s12
│ ├── HpBiosMgmt.s14
│ ├── HpBiosUpdate32.efi
│ ├── HpBiosUpdate32.s09
│ ├── HpBiosUpdate32.s12
│ ├── HpBiosUpdate32.s14
│ ├── HpBiosUpdate.dll
│ ├── HpBiosUpdate.efi
│ ├── HpBiosUpdate.log
│ ├── HpBiosUpdate.s09
│ ├── HpBiosUpdate.s12
│ └── HpBiosUpdate.s14
└── DEVFW
├── Current
├── DevFwUpdate32.efi
├── DevFwUpdate32.s12
├── DevFwUpdate.efi
├── DevFwUpdate.s12
├── HpDevFwUpdate32.efi
├── HpDevFwUpdate32.s12
├── HpDevFwUpdate.efi
├── HpDevFwUpdate.log
├── HpDevFwUpdate.s12
├── New
├── Previous
├── ReadMe.txt
└── ReleaseNote.txtés itt van a kimenete a
[noki@pista-hp250g7notebookpc ~]$ efibootmgr -v
Timeout: 0 seconds
BootOrder: 2001,0002,3002,0003,2004,2002,0000
Boot0000* Internal Hard Drive - KBG30ZMV512G KIOXIA BBS(HD,Internal Hard Drive - KBG30ZMV512G KIOXIA,0x500)................+0.0....#0.0?0.0.................................X..z.......A................................%x...
Boot0002* ubuntu HD(1,GPT,074cea58-d9ed-47cd-a2cd-4d65c4163df7,0x800,0x32000)/File(\EFI\ubuntu\shimx64.efi)RC
Boot0003* Windows Boot Manager HD(1,GPT,074cea58-d9ed-47cd-a2cd-4d65c4163df7,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Boot2001* EFI USB Device RC
Boot3002* Internal Hard Disk or Solid State Disk RC
[noki@pista-hp250g7notebookpc ~]$Nem tudom, hogy van-e jelentősége , de egy nvme lapka az ssd benne.
-
Archttila
veterán
-
Archttila
veterán
Egyelőre a feh
![;]](//cdn.rios.hu/dl/s/v1.gif)
kivételével minden megy, de azt meg amúgy is száműzni akartam. (imv lesz helyette)
Viszont van itt valami amit nem értek.
A Chromium valami oknál fogva eldobta a hardveres gyorsítást, pedig ez korábban szépen ment az alábbi paraméterekkel:$ > cat chromium-flags.conf--ignore-gpu-blocklist--enable-gpu-rasterization--enable-oop-rasterization--disable-gpu-driver-bug-workarounds--enable-accelerated-video-decode--use-gl=desktop--enable-zero-copy--enable-features=UseOzonePlatform--ozone-platform=wayland#--enable-vulkan--enable-native-gpu-memory-buffersÉrtelemszerűen a wayland-es opciókat csak ma, a frissítés után aktiváltam.
Most meg
chrome://gpu
Canvas: Software only, hardware acceleration unavailable
Compositing: Software only. Hardware acceleration disabled
Multiple Raster Threads: Enabled
Out-of-process Rasterization: Disabled
OpenGL: Disabled
Hardware Protected Video Decode: Disabled
Rasterization: Software only. Hardware acceleration disabled
Skia Renderer: Enabled
Video Decode: Software only. Hardware acceleration disabled
Vulkan: Disabled
WebGL: Software only, hardware acceleration unavailable
WebGL2: Software only, hardware acceleration unavailable
Problems Detected
Gpu compositing has been disabled, either via blocklist, about:flags or the command line. The browser will fall back to software compositing and hardware acceleration will be unavailable.
Disabled Features: gpu_compositing -
Frawly
veterán
válasz
Archttila
#7757
üzenetére
Ennyire azért még ne örülj, lesz még szükséged az XWaylandre, hiszen a legtöbb GUI-s program X-es, és használja, nálam a Wine, Steam, Goldendict, Thunderbird (a neomuttot nem szereti a Google, hiába álíltom be, hogy kapjon jogosultságot a mailjeimhez, állandóan elfelejti a rendszerük), meg 1-2 apróság és a játékok, akkor is, ha a FF-ot Waylandre állítom. Hiába 99%-ban terminálos TUI/CLI alkalmazásokat használok, sajnos abban az 1%-ban elkerülhetetlen, hogy X-es alkalmazást futtass. Persze, idővel egyre inkább nőni fog azon alkalmazások száma, amik natívan waylandesek, de még jó ideig nem tudod valós felhasználásnál mellőzni az Xwaylandet. Valós felhasználáson azt értve, hogy mindennapos desktop felhasználásnál. Ha valami speciális ipari, meg céges felhasználás, pl. egy progi fut rajta kiosk-módban, arra elég lehet a natív Wayland.
-
Frawly
veterán
válasz
vargalex
#7755
üzenetére
Oké, akkor elsiklottam felette. De örülök, hogy ennyire képben vannak, mert ez sok embernek okoz gondot, nem csak Archon, hanem mindenféle Linuxon, Deb/Ubuntu és Red Hat/Fedora vonalán is. Sok ember csak emiatt írja le az UEFI bootot, pedig nem is azt tehet róla, hanem a gyártó idiotizmusa. Sőt, még ennél is rosszabb, mert aki teljesen kezdő, és az az első tapasztalata a Linuxszal, hogy mindjárt az első telepítés után nem bootol neki, az meg nem azt fogja levonni tanulságnak, hogy a gyártó tehet róla, meg az UEFI boot, hanem azt hiszi, hogy a Linux ×4r, és pattintja is vissza a Win10-et. Amiben az az irónia, hogy az egész szenvedést a MS okozta karöltve a gyártóval, és visszamenekül azok karjaiba, holott pont ezt akarták elérni.
-
Frawly
veterán
válasz
jimmy399
#7752
üzenetére
Wow, még Dellnél is előfordulhat, igaz nem mindegyiken, mert nekem is volt Dell Latitude-om, és azon nem volt ilyen gond, de ezek szerint csak pont jó termékcsaládot fogtam ki.
Szépen megoldottad, ezt a megoldást felvehetnék az Arch Wiki-be is.
#7753 csixy: szerintem az idősebb kollégák vagy be sem küldik, vagy beküldik, de majd csak valami határidő-hosszabbítsára, hogy találjanak rá valakit. Esetleg valami fiatalabb asszisztens megcsinálhatja nekik, ha van olyanjuk.
-
Ugyan már nincs mit. Én valahogy ezt az etapot leküzdöttem már jó időben előre. Csak elképzelem, ahogy a 80-éves körüli kollégám ma bemenvén az munkahelyére ma már el olvassa ezt az emailt és nagy élvezettel elkezd telefonálgatni, excel értő embert keresni ...Nagyon érdekes. Nekem felért egy továbbképzéssel.
-
jimmy399
senior tag
Hellósztok!
Nekem Dell gépen volt az, hogy feltelepítettem a Windows-t majd utána az Arch-ot. Dual boot elsőre megvolt, de ahogy a Windows-t butultam be, abban a pillanatban csak a Windows indult el, nem volt grub választómenü. Ugyan úgy az UEFI volt a ludas, mert ugyan megvolt a bejegyzés a boot menüben a grub-nak de nem lehetett első helyre feltenni.
Túrtam a google-t és a megoldás az lett, hogy Windows alatt admin cmd-ben kellett átírni a bcdedittel az bootmgfw.efi bejegyzését a grub-ra kellett javítani:bcdedit /deletevalue {bootmgr} path \EFI\arch\grubx64.efi
Ezután már bejött a grub és lehetett rendszert választani.
-
"Csalódtunk benned,"
Nem erről van szó. Hétvégén telefonálgattam a körorvosi COVID kampányoltások miatt a pacientúrámmal és töltögettem a táblázatokat. Egyébként libre office programot használtam (mindig azt telepítek a windowsba is). Csak excel formátumba mentettem. De túl fürge voltam mert amikor azt hittem, hogy kész vagyok , akkor kaptam még egy táblázatot, amibe 3 újabb adattartalom kellett, ettől jött belőlem néhány cikornya és kezdhettem újra a telefonálgatást és csinálhattam egy másik táblázatot. Elszórakoztam vele egy hétvégét. A továbbképzések tehát autodidakta módon történtek. 
-
Frawly
veterán
Nem kell semmilyen GRUB mappát csinálni, annak ott kéne lennie, ahol eddig is volt, csak bootbejegyzés nem mutat rá. Egyedül a grubx64.efi fájlt átnevezed bootmgfw.efi-re, és bemásolod a /boot/EFI/Microsoft/Boot/ mappába, persze miután csinálták kézzel ide mappát. Az UEFI-hez bootbejegyzést nem csak efibootmgr-rel tudsz csinálni, hanem magából az UEFI BIOS-ban is a Boot-opcióknál, vagy még ezt sem, mert ezt a Microsoft-os bejegyzést automatikusan megtalálja.
Csalódtunk benned, a továbbképzésen ki kellett volna követelni, hogy linuxosként a LibreOffice Writerből vagy terminálos sc vagy sc-im progiból akarsz továbbképződni
Azt se gondoltam volna, hogy van még ilyen telefonközpontos képzés, el nem tudom képzelni, hogy mit lehet továbbképződni, főleg, mióta gépek csinálják leginkább, de ha még oda is tesznek embert, akkor is csak pár gombot kell neki megmutatni, hogy milyen bejövő hívást hova hogyan kapcsolhat, és hogy kezelje a prioritásokat. Nagyon nagy tudománya ennek már nincs. De még régen, az analóg időkben is sokszor meg tudta csinálni egy helyben betanított portás, meg 0 műszaki érzékkel bíró Titkárságiné Mancika. -
Most kicsit törött vagyok, mert hétvégén megvolt az autodidakta excel továbbképzésem és a telefonközpontos kiképzésem , mert szerveztem a "10 +6"-ot, de legalább rájöttem , hogy kell xlsx-be fejlécet csinálni. Majd előveszem pár nap múlva azt a lapost és felteszem , amiket mondtál.Köszi. Arról van szó, hogy a bios-os bootmenüben nincs benne a telepített arch, de a "Boot from EFI file" menüpntot választva ha elnavigálok a ...Arch/grubx64.efi vagy ... Boot/bootx64.efi fájlhoz és azt indítom akkor bebootol az Arch. ... Megpróbálok akkor egyelőre csinálni egy Grub mappát oda és belemásolom a grubx64.efi fájlt az Arch mappából és az efibootmgr progival megtanítani neki a .../Grub/grubx64.efi fájlt és úgy hátha visszateszi a boot menübe.
-
Frawly
veterán
válasz
Archttila
#7746
üzenetére
Tipikusan a ~/.bashrc fájlban érdemes, beilleszted valahová ezt a sort:
EDITOR='micro'Ezt nagyon ajánlott beletenni, nem csak annak okán, amit írtam, hanem visudo, sudoedit, vifm, AUR helperek, meg egy csomó minden használja az EDITOR változót, hogy megtudják mi a felhasználó default text editora. Elvileg még grafikus felületű text editort is meg lehet adni, de az nem valami ideális.
-
Frawly
veterán
Nem értem pontosan a problémát. Mi az a szép sor? Ezt kéne tisztázni, utána talán meg tudom mondani, hogy hogyan kell felparaméterezni az efibootmgr progit.
A pontos leírás után mindjárt beközölhetsz egy teljes efibootmgr -v kimenetet is, annyival előrébb leszünk.
Ami a HP-t és az UEFI bootot illeti, ez egy ismert tény, ezt már többször leírtam ubyegonnak is, hogy miért nem bootol neki a Mint Cinnamonja, nem azért, mert az UEFI bootolás szar, hanem a HP az UEFI BIOS-ban lefixálta, hogy csak mindenképp a \EFI\Microsoft\Boot\bootmgfw.efi fájlból bootoljon, akkor is, ha van máshova mutató bootbejegyzés. Ez a HP görénysége, el akarták lehetetleníteni mindennek a bootolását, ami nem Microsoft Windows.
Erre, ahogy az Arch Wiki vonatkozó cikke is írja, két megoldás van. Az első, hogy a “Customized Boot” opciót át kell állítani még bootolás előtt a grafikus UEFI-ben erre:
\EFI\grub\grubx64.efiDe ez a módszer csak a legfrissebb HP UEFI-knél működik, BIOS-t kell hozzá frissíteni. Helyesebben pongyolán továbbra is BIOS frissítésnek hívja ezt mindenki, de valójában UEFI firmware frissítés lenne a szakszerű neve, a modern gépeken jó régóta nincs BIOS, ha az UEFI támogat is legacy BIOS módot, már azt is csak emulációval, nem valódi BIOS formájában.
A másik módszer meg elérhetővé tenni a GRUB (vagy a kernel, vagy egyéb linuxos bootmanager) indítóját azon a néven, amit a HP UEFI-je fixen tartalmaz, így a HP azt fogja hinni, hogy Windowst indítasz. Ehhez ezeket az utasításokat kell kiadni GRUB-hoz:
mkdir -p $MOUNTPOINT/EFI/Microsoft/Boot
cp $MOUNTPOINT/EFI/grub/grubx64.efi $MOUNTPOINT/EFI/Microsoft/Boot/bootmgfw.efiA $MOUNTPOINT változót előtte ellenőrizni kell, hogy a megfelelő helyre mutasson (pl. /boot), vagy egyből átjavítani a jó elérési útra. Ezzel a második, más néven átmásolós módszerrel mindenképp lehet bootolni, egy hátránya van, ha Windows dualbootot akarsz, akkor azt ellehetetleníti.
Azt is meg kell jegyezni, hogy ezt nem csak a HP csinálja, a HUP-on két user is jelezte ugyanezt a problémát, az egyik egy Acer Aspire netbookon, a másik valami noname x86-os táblagépen, már nem emlékszem a márkára, csak hogy valami ismeretlen márka volt. Persze attól még hogy többen is csinálják, nem kéne a gyártóknak ezzel kavarni, mert így a usereknek nem lesz bizadalma az UEFI bootásnál, és örök világvégéig fogják erőltetni az MBR legacy BIOS bootolást, aminek semmi értelme.
Egy fontos dolog: az efibootmgr paranccsal óvatosan szabad csak vitézkedni. Ugyanis előfordulhat, hogy ha rosszul van megadva egy kapcsoló, akkor az összes meglévő bootbejegyzést törli az UEFI NVRAM-ból vagy csak az aktuális bejegyzést teszi bele, ha az meg nem jó, akkor bootolhatatlan lesz a gép, és előfordulhat, hogy még egy USB-s pendrive-ról se fog bootolni, ha nincs az EUFI menüjében egy Restore Defaults opció a bootrésznél. Erre nagyon kell figyelni, mert nagyot lehet vele szopni, általában mindig van rá megoldás, de lehet nehéz tető alá hozni. Én ebbe a régi ThinkPad-emen belefutottam, mákom volt, hogy volt Restore Defaults opció, ha nem lett volna, akkor is meg tudtam volna oldani valami kényszerített firmware-frissítéssel, de oltári szívás lett volna.
-
Az arch wikiben olvastam, hogy a HP laposok, a linux és az uefi boot nem nagyon szeretik egymást, ill nagyon szigorúam meg van szabva, hogy mint lehet ..., amiből egy szót sem értek. Tény viszont, hogy hibátlanul feltelepült a calam-arch linuxom, szép sora volt a "bios" menüben is a HP250 G7-es laposon. Aztán próbáltam egy USB-s vinyóra is felrakni ugyanazt az arch linuxot azon a gépen és valahogy kiütődött a gépre telepített arhchom "BIOS"-os boot menü sora, s azóta csak efi filéből tudom indítani vagy a grubx64.efi, vagy bootx64.efi fájlt, mindkettő elindatja az arch linuxom, de bárhogy bütykölök az efibootmgr programmal, sehogy se sikerül visszacsinálni a szép bootmenüs "BIOS" sort. Telepítsem újra az egészet?
-
Frawly
veterán
válasz
Archttila
#7742
üzenetére
A zip-es módszerre egy script is írható, amit a kedvenc fájlkezelődből hívogatsz, hogy ha .odt vagy docx formátumot nyitnál meg, akkor a scripttel nyitja, ami kicsomagolja a /tmp-be, onnan behívja rá az $EDITOR változóban lévő text editort (nálad ez elvileg micro), ott szerkeszted, kilépés után folytatódna a script, hogy azonos néven visszacsomagolja, visszamásolja az eredeti helyére.
Arra nagyon jó, ha csak egyszerű módosítások kellenek egy doksin, 1-1 szó beszúrása, törlése. Ami viszont hosszabb, meg több oldalas formázásos művelet, arra nem jó.
Én kifejezetten kerülöm az office-os formátumokat, libreoffice-osakat is. Ahol lehet plaint text-et, plain TeX-et, markdown-t, rtf-et, HTML-t, pdf-et használok doksinak, azok minden platformon bloatmentesen szerkeszthetők, megjeleníthetők, nyomtathatók. Nálam már kb. 2 éve nincs is fent LibreOffice, előtte meg kb. 1 évig fent volt, de csak megszokásból tettem fel, hátha kell alapon, de aztán rájöttem, hogy soha nem használom. De volt idő, mikor én is rendszeresen használtam, még kezdő koromban. Az MS Office-nál határozottan jobb, mára egy csomó mindenben többet tud már a LibreOffice, nincs belekényszerítve a szalagmenüs barmolás, de akkor is bloat.
Ugyanígy, táblázatkezelésre se kell feltenni, arra ott az sc, sc-im, meg a scriptnyelvek, ezeket kiegészítheted gnuplottal, és ugyanott vagy kb., ugyanazt megcsináltad töredék erőforrásból.
Prezentációkészítésre is vannak különböző pehelysúlyú alternatívák, pl. sent, akármilyen fentebb ismertetett szöveges formátum a kedvenc dokumentumnyelven (HTML, XML, TeX, stb.) amit pdf-re konvertálsz (de minden megjelenő prezentációs menüpont az külön oldalra generálódik le), LaTeX Beamer csomag, de már láttam olyan vagányt is, aki vim-mel ASCII art-ban (figlet, toilet, boxes, cowsay, ponysay, lolcat parancsokat ötletesen kombinálva) nyomatta a prezentációt, az már hardcore.
Adatbázis-kezelésre se kell feltételen MS Access meg LibreOffice Base, meg lehet oldani bármilyen SQL megoldásban, mariadb, mysql, de még minimalistább az sqlite, bár ezekhez kellhet valami minimalista kliens is, ennek nem vagyok szakija, de kulturáltan megoldható ez is különösebb blaot nélkül. Esetleg XML, CVS/flatdatabase plain text alapon.
MS Office meg LibreOffice akkor kell, ha olyan cégnél vagy, ahol tényleg kötelező mindent abban szállítani, de akkor meg fizetnek érte, hogy ezt lenyeld. Régen még hivatalok meg iskolák ragaszkodtak hozzá, mindent .doc-ban kell leadni, de ezt kezdik feladni. Egyedül még néhány munkáltató ragaszkodhat hozzá, hogy csak abban várja az önéletrajzokat. Vagy pl. dizájnban, grafikus kiadványokban utazol és muszáj InDesignt használni.
-
Frawly
veterán
válasz
Archttila
#7740
üzenetére
Lehet szerkeszteni vim-ben, Emacs-ben és Micro-ban, átnevezed az odt-t, docx-et zip-re, kicsomagolod, benne egy sztenderd XML fájl van, ami plain text-ként szerkeszthető. Pandoc tudja még konvertálni különböző formátumokra oda-vissza. Esetleg webes LibreOffice, MS Office, Google Docs, stb. tudja szerkeszteni, hangsúlyozom az online/webes verzióról beszélek, amihez semmit nem kell felrakni. Ha viszont rendszeresen szükséged lenne a szerkesztésére, akkor muszáj feltenni, hiába bloat, egyébként csak magadat szivatod meg. Pandoc se kicsi, igaz az nem is fut egyben, az egy tool-gyűjtemény, amiben számos CLI konverter van.
Az meg nem lep meg, hogy az újraindítás megoldotta. Ezért szajkózom az OFF topikban is, hogy a gépet érdemes minél többször újraindítani, főleg ha az ember rollingot használ és sokat frissít. Mert kékluficet büszkén mutogatta, hogy a Gentoo-ját gyakran frissíti, de már hónapok óta nem volt újraindítva. Nem hitték el, hogy ez így önszivatás, meg cirkuszi mutatványozás.
Én kb. naponta frissítek, és újra is indítok min. 1×, valamint a nap végeztével is kikapcsolom a gépet. Nincs értelme a sleepnek, hibernációnak, gyors gépek, SSD-vel, pár mp. alatt bootolnak komplett grafikus környezettel, nem látom értelmét a hosszú uptime-os kavarásnak.
Nem véletlen, hogy az összes supportos ügyfélszolgálat is úgy szokta kezdeni, hogy kapcsolja ki-be, indítsa újra, stb.. Ez az első hibakizáró lépés mindenhol.
-
Archttila
veterán
Eltűnt a ronda átmenet, egy újraindítás megoldotta.
(ne kérdezzétek hogyan) Minimalista rendszereken ti mivel szerkesztitek az ODT, DOC és egyéb Office doksikat? Kerestem micro plugint de nem találtam. (valójában semmit nem találtam
)
Tényleg csak nagyon ritkán lenne rá szükségem, így ha nem muszáj nem raknám fel a LibreOffice-t. -
Shyciii
veterán
válasz
Archttila
#7736
üzenetére
Szívesen :) ezért írtam, hogy neked a start-at kapcsoló kell, mert ami utána van, az a vifm szintaktikája :) az a színátmenetes probléma lehet hogy a swayhez köthető, mert ilyen problémám nincs Bspwm alatt. De az is lehet, hogy a feh miatt van, mert az nem wayland kompatibilis szerintem.
-
Archttila
veterán
válasz
Shyciii
#7735
üzenetére
Működik, köszönöm!
Annyi, hogy a végéről ki kellett vennem a ./ karaktereket a %f elől, ellenkező esetben hibát dob.
Egyetlen dolog nem tetszik csak, hogy ha különböző felbontású képek jönnek egymás után a mappába, akkor rettentően csúnya az ablakváltásnál használt átmenet. Ez nem nagy probléma, de azért észrevehető. -
-
Blasius
tag
Köszi a választ!
Időközben egy nagyobb adag frissítés jött, de nem javult meg.
Az nm-applet fent van, fut is, ps aux -al megtalálom. De ha csak futtatom a terminálban nem történik semmi.
A bluetoothot a start menüből tudom futtatni.Amúgy a bluetooth és a hálózat is megy, csak a tálca ikon hiányzik. De így pl nem tudom hirtelen hogy hogy tudnék wifi hálózatot váltani ha kellene.
Üdv
-
Archttila
veterán
válasz
Archttila
#7731
üzenetére
Úgy tűnik megtaláltam a megoldást:
include/image Open=feh %f View=%view{ascii} /usr/lib/mc/ext.d/image.sh view ALL_FORMATSAnnyi kis szépséghibája van csak a dolognak, hogy ha egy mappán belül több kép is van, akkor nem lehet egymás után léptetni őket, egyszerűen csak megnyit és kész, kész nem tudom léptetni.
Most bújom a man feh -t
-
Shyciii
veterán
No mégis imagemagick lett a dologból a forgatás miatt, mert kiderült, hogy az ffmpeg úgy forgatja a képeket, hogy újrakódolja, vagyis így ront a képminőségen. Ha meg beállítom hogy a codec-et másolja, nem újrakonvertálja, akkor meg a forgatás nem engedi, szal Imagemagick-et konfigoltam be az imv-be.
-
Archttila
veterán
swaybg húzza be a hátterem. [kép]
Nálam a képnézegető csak arra kell, hogy az innen onnan letöltött szakmai (C. gamut, gamma formulák, stb) képeket tudjam szelektálni, a családi és egyéb fotókat más platformon rendszerezgetem, szerkesztgetem.
Az mc-t szeretném majd még szépen beállítani úgy, hogy ha rányomok egy jpeg, png... képre, akkor az alapértelmezett (jelenleg feh) alkalmazást nyissa meg (a korábban belőtt floating window modban
) nem pedig a Chromium-ot Ezzel csak annyi gond van, hogy szégyen van sem, de egyszerűen nem értem hogyan működik az ide vonatkozó rész az mc.ext konfigban:type/^JPEGView=%view{ascii} /usr/lib/mc/ext.d/image.sh view jpegInclude=imageValami olyasmiről lehet szó, hogy a fenti elérésen az image.sh tárolja az alapértelmezett alkalmazásra vonatkozó részt, de ennek a tartalma megint csak nyomokban tartalmaz számomra értelmezhető részt, és ez piszok idegesítő
$ > cat /usr/lib/mc/ext.d/image.sh#!/bin/sh# $1 - action# $2 - type of fileaction=$1filetype=$2[ -n "${MC_XDG_OPEN}" ] || MC_XDG_OPEN="xdg-open"do_view_action() {filetype=$1case "${filetype}" injpeg)identify "${MC_EXT_FILENAME}"which exif >/dev/null 2>&1 && exif "${MC_EXT_FILENAME}" 2>/dev/null;;xpm)sxpm "${MC_EXT_FILENAME}";;*)identify "${MC_EXT_FILENAME}";;esac}do_open_action() {filetype=$1case "${filetype}" inxbm)(bitmap "${MC_EXT_FILENAME}" &);;xcf)(gimp "${MC_EXT_FILENAME}" &);;svg)(inkscape "${MC_EXT_FILENAME}" &);;*)if [ -n "$DISPLAY" ]; thenif which geeqie >/dev/null 2>&1; then(geeqie "${MC_EXT_FILENAME}" &)else(gqview "${MC_EXT_FILENAME}" &)fielif see >/dev/null 2>&1; then(see "${MC_EXT_FILENAME}" &)else(zgv "${MC_EXT_FILENAME}" &)fi;;esac}case "${action}" inview)do_view_action "${filetype}";;open)("${MC_XDG_OPEN}" "${MC_EXT_FILENAME}" >/dev/null 2>&1) || \do_open_action "${filetype}";;*);;esacPersze itt van még az F2-es user menü, amiben szinte minden hasznosságot be lehet állítani, valahogy így: [link]
Eszméletlen milyen szépen rendbe van rakva az a menu a srácnak, szinten minden van benne. Nagyon tetszik. -
Frawly
veterán
válasz
Archttila
#7729
üzenetére
Akkor esetedben maradj a feh-nél. Nálam az imv nem tett fel ennyi mindent, de ez azért van, mert nálam már fent volt az mpv, imagemagick, ffmpeg, meg hasonló csomagok, és azok az általad listázott csomagoknak a nagy részét már feltették, így az imv alig húzott le plusz 2-3 függőséget.
Meg ezeknek a függőségeknek a nagy része tényleg hasznos, nem bloat, pl. glu kell ahhoz, hogy hardveres gyorsítást használjon a progi, heic, raw, exr megint hasznos extra képformátumok és feature-ök támogatásánál, tehát nem olyan bloatsági függősége, mint pl. ha lenne egy rakat Qt/Gtk, meg mindenféle icon library függőség, ahogy a valódi bloat programoknál.
Egyébként én most fogom dobni a feh-t, xsetroot-ot használok majd háttérképnek, és kikapcsolom a picom kompozitort, mivel elhagyom az átlátszóságot, cserébe a X.org konfigba teszem be a tearfree meg DRI opciókat, így már nem fog bugzani az xsetroot. Nekem feh mindig is csak a háttérkép miatt volt fent, akkor is csak olyan X-es WM-eknél, amik saját maguk nem támogatták a háttérképet (pl. dwm, Openbox, bspwm, i3wm). Pl. IceWM támogatja, meg waylandes felületeknek is van saját háttérképmegjelenítője (Sway-nek swaybg).
-
Archttila
veterán
for_window [title="feh"] floating enableMűködik!!
Most nem tudom mi legyen, tartsam meg a feh-t, vagy rakjam fel az imv-t?
Az imv-nek sok a függősége viszont wayland kompatibilis.
Ha csak a nyers adatokat nézem akkor:$ > sudo pacman -S fehresolving dependencies...looking for conflicting packages...Package (2) New Version Net Changeextra/imlib2 1.7.1-1 0.94 MiBextra/feh 3.6.2-1 0.41 MiBTotal Installed Size: 1.35 MiB:: Proceed with installation? [Y/n] n$ > sudo pacman -S imvresolving dependencies...looking for conflicting packages...Package (12) New Version Net Change Download Sizeextra/aom 2.0.1-1 7.30 MiB 1.39 MiBcommunity/freeimage 3.18.0-7 0.77 MiB 0.25 MiBextra/glu 9.0.1-2 0.35 MiB 0.12 MiBextra/jasper 2.0.24-1 0.98 MiB 0.19 MiBcommunity/jxrlib 0.2.1-3 0.60 MiB 0.17 MiBextra/libde265 1.0.8-1 0.83 MiB 0.25 MiBextra/libheif 1.10.0-1 0.69 MiB 0.19 MiBcommunity/libinih 52-1 0.03 MiB 0.01 MiBcommunity/libnsgif 0.2.1-4 0.02 MiB 0.01 MiBextra/libraw 0.20.2-1 2.26 MiB 0.36 MiBextra/openexr 2.5.4-1 30.57 MiB 5.46 MiBcommunity/imv 4.2.0-2 0.21 MiB 0.05 MiBTotal Download Size: 8.45 MiBTotal Installed Size: 44.60 MiB:: Proceed with installation? [Y/n] n -
Frawly
veterán
válasz
Shyciii
#7727
üzenetére
Ez igaz, hogy felesleges csak ehhez feltenni még egy programot, de az imagemagick hasznos egyébként is, mivel nem csak képforgatásra lehet használni, hanem bármilyen tömeges átméretezésre, konvertálásra, képmegjelenítésre, fontok megjelenítésére is, akár még pdf-et is konvertál, tehát egy elég univerzális eszköz, szinte bármit visz, ami nem hang vagy nem videó. Így én mindig felteszem, nyilván ez nem kötelező, egyéni döntés eredménye.
@sati: próbáld így:
for_window [title="feh"] floating enableEzt a swayimg-t még nem próbáltam, de egy elég szög egyszerű valaminek tűnik. Igényfüggő, hogy elég-e valakinek, már így ránézésre leszűröm ezt.
Rég nem swayeztem, már pár hónapja, mert az új gépre még nem tettem fel. Most újra X.org-os WM-eket próbálok, amiket régen nem próbáltam. De lehet visszatérek Sway-re, mivel az jobban bevált, de a Waylanddel az a baj, hogy kevés használható WM van rá, Sway, Weston, és kifújt. Vannak még waylandes WM-ek, de azok nagyon kísérleti, proof of concept állapotban vannak, és nem sok mindenre használhatók. Míg X.org-ra van egy rakat érdekes WM.
-
Shyciii
veterán
Nekem is vannak rések a csempék között, de nem akkorák, hogy kiderüljön, hogy milyen háttérkép van.
Ffmpeg-el nem konvertálok képet (amúgysem szoktam képeket konvertálni), hanem csak a kép forgatására állítottam be. Ehhez teljesen felesleges még egy programot telepíteni. -
#63718632
törölt tag
válasz
Archttila
#7725
üzenetére
Pár hete kezdtem érdeklődni a VM-ek használata iránt. Eleinte természetesen virtuális gépen kezdtem, aztán több felől kaptam információkat arról, hogy lehetnek bugok. Ha nem rendes fizikai gépen próbálom használni.
Elővettem egy régebi notimat és natívan telepítve ismerkedem velük és tényleg meg szűnt egy-két olyan dolog ami VBox-ban rendellenesen működött. Attól függetlenűl, hogy aVBox rendesen be volt állítva. -
Archttila
veterán
Pont ez az egyik dolog amit nem értek. Miért nem natív hardveres környezetben tesztelte mondjuk Arch alatt?
Én még csak 3 hónapja használom de az égvilágon semmi bajom vele. Illetve ami van az az én hibám, én bénázok, én nem tudok xy beállítást... etc.De ha már billt ragadtam akkor kérdezek egy gyorsat:
A feh -t hogyan állíthatnám be úgy, hogy ha egy adott könyvtárra kiadom a feh parancsot, akkor ne egy új terminál ablakot nyisson a másik alatt, hanem floating dobja elém (a többi ablak felé) a képet mondjuk fix xy méretben.
A pavucontrol-t sikerült belőnöm, de a feh-vel nem működik.
sway konfigba:
for_window [app_id=pavucontrol] floating enableKözben telepítettem az imv-t (a feh amúgy sem wayland compatible)
Illetve ezt is ki szeretném próbálni: [swayimg] -
Frawly
veterán
válasz
Archttila
#7720
üzenetére
Igen, ez a videója elég láma lett. Bár nála megértem, hogy ódzkodik a Waylandtől, mivel OBS-t, meg egy csomó X.org-függő toolt használ a videói elállításához. Amúgy meg pechje volt, hogy pont egy szar swayes disztrót próbált ki, ami még nagyon kísérleti állapotban van, ebből meg levonta azt a téves következtetést, hogy a Sway meg a Wayland szar, és alfa, közben meg egyáltalán nem, mert használtam én is 1 évig, és semmi baj nem volt vele. Az se segített az ügyén, hogy rosszul beállított, hardveres gyorsítás nélküli virtuális gépen próbálta, nem fizikai gépen. Meg őnála a Sway eleve hátrányból indul, mivel i3wm klón, az i3 meg manuális tiler, és DT a dinamikus tiling WM-eket szereti. Szóval nála ez teljes istenkáromlás, hogy valami i3-szerű is legyen, meg Wayland is, ez túl nagy lelki törés. Amúgy persze nincs igaza, egy jó dolog, már most használható napi szinten, nem kell 5-10 évet várni vele, ahogy jósolja.
-
Frawly
veterán
válasz
Shyciii
#7719
üzenetére
Igen, én ezt értem, de képnéző szinten ez még mindig pinduri. Majd nézd meg mit foglal egy XnView, Gwenview, meg a többi, legalább egy 0 lesz még mögötte, és még esetleg megduplázhatod, megtriplázhatod még rá, ott lesz 100-300 MB környékén. Ahhoz képest eléggé pinduri, mivel nem használ semmilyen grafikus libet.
Tilingnál valóban kevésbé lényeges a háttérkép, de vannak emberek, akiknél vannak rések a csempék között, vagy mint nálam, hogy átlátszóság a terminálon, ami alatt átüt a háttérkép, meg hangulat miatt, míg el nem indítom az első alkalmazást, látok valami hátteret, kinéz az egész desktop valahogy, esetleg virtuális desktopoknál is jól jöhet. Most az a pár MB még nekem se tétel, amibe egy háttérkép kerül, bootidőben sem kimutatható. De azzal sincs baj, ha te nem használsz, mert tényleg nincs sok szerepe tilingnál, és ez is egyfajta minimalizmusos spórolás. Lehet még én is kipróbálom, tervben van véve, hogy csak egyszínű háttér legyen, meg a kompozitort és átlátszóságot is dobom, helyette tearfree opciót használok a X.org konfigban, és nem lesz átlátszóság sehol, úgyse használok transzparenciát a polybaron és terminálon kívül.
Képeket lehetőleg ne ffmpeg-gel konvertálj, hanem imagemagick csomag convert parancsa a legjobb rá.
-
szuszinho
őstag
Backupnak futtatok hetente egy parancsot:
tar -g /media/HDD4TB/Backup/Docker/snapshot.file-zcpf /media/HDD4TB/Backup/Docker/backup-`date +%Y-%m-%d`.tar.gz /home/szuszi/{docker,dockerconfigs}
A .tar.gz könyvtárai üresek, és most szükségem lenne egy fájlra, mert kitöröltem...
Hogy kell kitömöríteni a snapshot filet? -
Shyciii
veterán
No most hogy végetért a meló, gyorsan megcsináltam (imv configjába), hogy imv alatt olyan képforgatást csinálok, amit be is jegyez a jpg-be CTRL+R-el:
<Ctrl+r> = exec ffmpeg -y -i "$imv_current_file" -vf transpose=1 "$imv_current_file"
Ez a része nagyon zsír ennek az imv-nek -
Shyciii
veterán
Én a feh-et nem használtam háttérkép beállítására. Tilling WM mellett feleslegesnek érzem a háttérképet. Feh-et csak képek megnézésére és forgatására használtam. Amúgy annyira nem is pinduri az imv erőforrás foglalalása:
41k-s png esetén
feh -> 11MB memória
imv -> 23MB memória5MB-os jpg esetén
feh -> 61MB memória
imv -> 80MB memória -
Frawly
veterán
válasz
Shyciii
#7717
üzenetére
Ezt jó tudni, ez nekem is jól jön, mármint ez a Vifm-ből megnyitás, eddig imv %f %d illetve imv %f * beállítást használtam. Egyébként ha neked elég a feh, akkor maradhatsz annál is. De az imv többet tud. Ez a kétszer annyi erőforrás is relatív, mert a feh olyan pinduri, hogy annak a kétszerese is nudli, főleg, ha nagyobb képnézőkkel összehasonlítod. Nem akarlak egyikről sem a másikra átbeszélni, a feh-nek valóban megvan az az előnye, hogy kicsi, és ha már fent van háttérképmegjelenítésnek, akkor akár használható képnézésére is, miért ne. Nekem a feh túl fapad, de ha neked elég, akkor nincs azzal baj.
-
-
Shyciii
veterán
Ez az imv képnéző akár jó is lehetne, de egy számomra fontos dolgot nem tudok beállítani rajta, és mivel elég gyenge a doksija is, így nem találtam rá megoldást. Mégpedig arra, hogy ha vifm-ből egy képet-et "elindítok", akkor ne csak jelenítse meg, hanem megadott gombokkal tudjak lépdesni a megnyitott kép könyvtárában a többi kép között. Ez így már működik, mert a vifm-be beírtam, hogy imv %f %d ,viszont ha lépkedek előre, akkor a megnyitott kép után nem a következőt adja, hanem a mappában levő elsőt.
-
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.
-
Frawly
veterán
válasz
Shyciii
#7710
üzenetére
De, a feh GUI-s progi, ha elindítod magában, akkor is működik, feltéve, hogy az adott mappában van képfájl. Nem sok az a 4-5 menü, de grafikus. Nyilván ez nem olyan nagy baj, de akkor sem tisztán CLI-s. mpv sem, de még mindig a legjobb lejátszó. Megjegyzem, hogy a CLI nem fontos azoknál a programoknál, amik úgyis grafikus képet nyitogatnak, pl. pdf/kép/videónéző/szerkesztő, stb.. VLC-vel nem az a baj, hogy GUI-s, hanem hogy rohadt bloat. És ezt nem csak függőségekre és memóriafoglalásra írom, hanem bugosságra, és tényleges prociigényre is, gyenge gépeken az a videó, ami mpv-ben folyamatos lejátszású, VLC-ben durván akad.
A webes Transmissionnek az a lényege, hogy böngésző minden gépen van, mindig fut jó esetben, semmi pluszt nem kell hozzá nyitogatni. Míg ha a legminimálisabb CLI klienst is használod hozzá, az többet foglal, mint a már eleve fent lévő böngésző. Meg webes interface-nél szét van választva a szerver-kliens, ezért távoli gépről is tudod irányítani, amit nem webes megoldásnál nem tudsz megtenni.
Nekem hiányzik a qBittorrent, mert a legjobb torrentkliens, még a bloatságát is elnéztem, de a fejlesztői töketlenkednek sorban, új verziókor nem követik le a libtorrent-rasterbar lib változásait. Merő lustaságból, és ebből elegem lett, így dobtam.
-
Shyciii
veterán
Transmission cli-s verzióját kipróbáltam, de értelmetlennek tartom számomra. Ahhoz hogy megnézzem a tartalmát, ahhoz indítsak el egy jóval energiaigényesebb programot (böngésző), mintha a saját guis felületét használjam, ami meg csak 9MB memóriát eszik.
Szerintem a feh eléggé cli-s abban az értelemben, hogy nincsen gui felülete, hogy te ott nyitogass képeket, vagy csoportosíts stb. Csak mikor megnyílik a kép, akkor van egy 4-5db-os menü, amiben lehet egy-két funkciót választani. Pont így van az mpv videólejátszóval is. Üresen nem tudom elindítani magában (illetve asszem valami csel van már rá, de csak elindítva a programot nem reagál, csak ha adok neki bemenetként egy filet. Ezek nekem már eléggé minimálak. Főleg hogy ha egy VLC-hez hasonlítom. -
Frawly
veterán
válasz
Shyciii
#7708
üzenetére
Nem is fontos a mixer, az csak példa volt, hogy még olyan apróságokat is lehet optimalizálni. Én egyébként nem hangerő-szabályozásra használom, mert arra tényleg ott a billentyűzeten a hangerő fel/le gombok (meg némítás ki/be, és mikrofonnémítás ki/be), meg a polybar hangerőszabályozója, hanem kimenetek között választani, egyszerre több kimenet hangerejét szabályozni. Amúgy ritkán használok mixert én is, de akkor nagyon kell.
Transmission-ből fel tudsz tenni cli-s változatot és azt webes vagy terminálos tremc-klienssel használni. Bár azok sem esznek kevesebbek, mint a gtk-s változat.
A feh nem cli-s, de határeset, mert cli-s kapcsolókkal is működik. Nálánál minimalistább lenne az imagemagick display vagy a xsetroot, de azok bugzanak a picom kompozitorral, de egyéb WM/DE kompozitorával is összeakadhatnak.
A böngésző viszont tényleg az, amit nem lehet kiváltani minimalistábbra, abból muszáj GUI-s bloatot használni, ezt nem lehet megkerülni.
-
Shyciii
veterán
Dehogy használok zip-et. Azért van fent a zip és unzip, mert sokszor találkozom zip fileokkal, és ki kell tömörítenem, vagy van olyan ügyfél, aki zip-ben kéri a dolgait. Saját mentéseim a linuxhoz tar+gz-t használok. Ma mindent átírtam tar+zstd-re. Az a baj, hogy a programjaimat is leváltottam már cli-s megoldásokra. Vifm, micro, freerdp, feh stb. Guis egyedül a chromium és transmission-gtk (torrent). Én amint változtatok a rendszerem működésén, azt tesztelés után rávezetem az arch telepítő scriptembe is, ami meg megy fel a github-ra, szal mindig naprakész. Én már nem is tudom, hogy milyen mixert használok. Hangerőt is ritkán módosítom. Azt meg lehet a polybar-on elvégezni. Úgyhogy az még biztos gui-s. Valszeg amúgy a pavucontrol lesz az, mert régen is azt használtam.
-
Frawly
veterán
válasz
Blasius
#7700
üzenetére
Net és BT amúgy elérhető a rendszeren, csak ikonja nincs? Konkrétan biztos megoldást nem tudok, de én úgy indulnék neki a megoldásnak, hogy terminálban a sudo pacman -S xfce kiadásával újratelepíteném az Xfce-t, de nem azért, mert ez konkrétan segít, hanem a telepítés végén a pacman kiírja az opcionális függőségeket, és ott sorolja, hogy mi van feltéve, mi nincs, hátha említi azokat a csomagokat, amik nálad a hiányzó tálcaappletekre vonatkoznak.
A hálózati Xfce tálcaikont egyébként az nm-applet nevű csomag adja, a BT-t már nem tudom, ezekre kéne ránézni, hogy telepítve vannak-e. Ha telepítve vannak, akkor kézzel kéne őket terminálból indítani, ha nem is indulnak, ott látszani fog a kimenetben a hibaüzenet, hogy miért nem indulnak.
-
Frawly
veterán
válasz
Shyciii
#7705
üzenetére
Egyrészt függ attól is, hogy az adott disztrón belefordították-e az xz és zstd csomagba a párhuzamos működést, Archnál belefordították, de magától nem megy, kapcsolókat (-T akármennyiszál) kell megadni hozzá, hogy több szálat használjon, és mint írtam, akkor sem skálázódik tökéletesen. Azzal egyetértek, hogy a Linux ebben lemaradásban van, mivel a Unix-filozófia miatt még mindig a tar + tömörítő CLI megoldásokat erőltetik, mivel a Unix-filozófia betartása, tar-ral való kompatibilitás, és a scriptekben való automatizálhatóság a fő cél, nem a GUI-s felhasználóbarátság.
A többiben egyetértek, az Arch valahol unalmas, minden megy rajta, nem nagyon törik el semmi, az ember már egy idő után nem tud mit optimalizálni, annyira minimalista és optimalizált a rendszere, hogy minden 0,00001 mp. alatt indul és megy, boot villámgyors, rendszer sovány. Ilyenkor mennek át az unatkozók Gentoo-ra, hogy azzal szenvedjenek egy kört. Bár optimalizálni mindig van mit, te is optimalizáltad a KDE-t Openboxra, majd azt bspwm-re, fájlkezelőt vifm-re, erre most a tömörítést zip-ről zstd-re, a rendszeren mindig lehet valamit optimalizálni. Én pl. nemrég a pavumixert és ncmixert váltottam át pulsemixer-re, a vim-et nvim-re, az automata csatolást saját scripktekre, az xz-t zstd-re, stb.. Ezért nem szoktam elmenteni a rendszeremet sem, hogy baj esetén visszahúzzam, mivel úgyis mindig változik a rendszerem, egy régi mentés visszahúzásával nem sokra mennék, mire azt átállítgatom újra, annyi erővel feltelepítek egy új rendszert is.
-
Shyciii
veterán
BoB, Frawly
Ne értsetek félre, nem akarom fikázni a linuxot, csak tényleg 2021-ben egyértelműnek tűnt, hogy azárt ez már megoldott (mikor elkezdtem linuxozni, akkor már konstatáltam, hogy ez gond), és gondoltam, hogy akkor módosítom a rendszert ennek megfelelően. A belinkelt weboldalt természetesen már olvastam (többször is) az elmúlt 2 évben. Tudom furán fog hangzani, csak eljutottam arra a szintre, hogy nem tudok már mit módosítani a rendszeren, és most már ilyen "faszságokkal" törődöm :D Nyilván Archozom, Bspwm, és semmi se az egy programos automatizált működéssel megy. Mindent amit csak használok levékonyítottam, hogy minél kevesebb erőforrást használjon (és persze így mégtöbbet tudtam meg a működéséről az egész rendszernek), mindent lescripteztem, így egy része mégis automtikus, csak jóval kevesebbet foglal, és gyorsabb, vagy egy gombnyomásra megy minden. Írtam saját telepítőscriptet is mikor az archot újra akarom húzni. Az is megcsinál mindent, még a mentéseket is visszaállítja. Gyakorlatilag pont azt kapom, mint ahogy most vagyok (csak persze a backup scriptemet előtte futtatni kell). Szal tényleg odajutottam, hogy nem tudom már mit baszkodni a rendszeren, és "unatkozom", "szenvedek" :-) Amúgy fura, mert nekem az xz tömörítés nem több szálon megy, csak egy. A zstd már több szálon megy, igaz abból 1 szál pörög 100%-on, a többi kb 20%-on, pedig semmi plusz kapcsolót nem használtam. A man page alapján pedig a default érték az 1 szál...nah mindegy. Úgyhogy akkor config fileok, és egyéb használt cuccok mentésére akkor zstd-t fogok használni, nem gunzip-et. Főleg hogy míg a gunzip 47mp alatt van meg 433MB-al, a zstd kb 10mp alatt van meg 411MB-al. Döbbenetes különbség...vifm-et már át is írtam, hogy a fusemountolás kezelje (archivemount), és a tömörítő aliasomat is átírtam zstd-re, meg a kitömörítő függvényt is gyorsan felkészítettem rá, bár eddig még nem találkoztam kitömörítés ügybne ezzel a formátummal.
-
Frawly
veterán
Én a részemről a zstd-t használom, általános használatnál 19-es fokozaton, ha gyors tömörítés kell, akkor 3-as fokozaton, ha a tömörítési fok nem számít, csak a sebesség, pl. kernelimage, akkor az 1-es fokozatot preferálnám (de a kernel konfigban ezt nem lehet megadni, de gondolom 1-3-as fokozat valamelyikét használja).
A 22-es fokozat a maximum zstd-nél, de az nagyon lassú, lassabb, mint az xz maximum fokozata. 19-es fokozaton 2,5× gyorsabb az xz-nél, és csak 1-2%-kal tömörít rosszabbul, mint a maximum tömörítéses xz. A legideálisabb a 15-ös tömörítési fokozat nálam, az 8× gyorsabban tömörít a maximális zx-nél, de 12%-kal rosszabbul. De nem rossz a default 3-as tömörítési fok se, az 120× (!!!) tömörít be gyorsabban, de 25%-kal rosszabbul. A leggyorsabb, 1-es zsdt fokozat 167× tömörít gyorsabban, de 31%-kal rosszabbul. Ezek átlagos számok, egy 560 megás angol szótár tömörítésével tesztelve. Természetesen a „sima” linuxos zip-et veri keresztben-hosszában, tömörítési sebességre és tömörítési fokban is.
Párhuzamosításra viszont nem a legideálisabb, mivel hiába adom meg, hogy 8 szálon tömörítsen, jellemzően 4-5 szálat használ, a tömörítés vége felé már csak 2 szálat, majd 1-et. A 2 legfelsőbb ultra tömörítési fokozaton már csak 2 szálat használ, a tömörítés vége felé már csak 1-et. De a 7-zip is ugyanígy viselkedik, nem mértem le, de feltehetőleg az xz is. Tehát azt nem lehet elvárni egyik linuxos tömörítőtől sem, hogy állandóan kitekerik az összes prociszálat. Igaz ez a gcc-re is, ott is hiába adjuk meg a make-nek, hogy hány job-ot toljon párhuzamosan, még nagy projekteknél is fellép egyfajta limit, mikor nincs annyi párhuzamos fordítani való, hogy pl. 64+ szálat kihajtson. Igaz ez átlag konzumer szinten nem nagy korlát, mert az átlag konzumer proci kb. 4 szálat tud nagy átlagban. Mondom átlagban, van, akinek 16-ot, van, akinek csak 2-őt, a 4 az egy erős átlag, ami figyelembe veszi a még használatban lévő, de nem teljesen irreleváns procikat (régi Core 2 Duo/Quad vagy régi genes Core i, vagy Phenom / A / FX).
De flac-nál pl. a default 5-ös tömörítési fokot használom, mert nagyon gyors, és csak alig pár százalékkal tömörít rosszabbul, mint a sokszorosan lassú 8-as fokozat. Az is igaz, hogy a flac csak egy szálat tud használni maximum.
Az is igaz, hogy baromi ritkán tömörítek befelé, inkább csak kifelé, utóbbit is inkább vifm-et használva, ami meg fuse modulokat használ kibontásra. Mondjuk ma véletlenül többször is, mivel egy 96 kHz-es lossless flac albumot benyomtam 48 kHz-es 512 kbps-os opus-ba, meg most a zstd-t, xz-t, zip-et méregettem sebességre, tömörítési fokra, de ilyesmik szökőévente egyszer fordulnak elő.
-
Frawly
veterán
válasz
Shyciii
#7701
üzenetére
Ez a tar közbeiktatása a Unix-filózófia miatt, hogy egy tömörítő csak egy dolgot tudjon, csak tömöríteni, és ne kelljen tudnia fájlrendszerfüggő, és jogosultságkezelő megoldásokat lekezelnie, a tar ezeket a feladatokat leveszi a tömörítő válláról. Amúgy most nézem, hogy nem csak az xz, hanem a zsdt is tud már több szálon dolgozni, nem kell parallel változatot feltenni, -T0 kapcsolóval megpróbálják az összes magot használni. Az xz LZMA tömörítést használ (mint a 7-zip), emiatt jobban tömörít, de lassabb. A zstd kevésbé tömörít jól (ez a Facebook által kifejlesztett Zstardard tömörítést használja), de iszonyat gyors, és a kevésbé tömörít jól kitételt úgy kell érteni, hogy alig marad el néha az xz-s tömörítési foktól. Szóval így tömöríts:
tar -I 'xz -T0' -cvf tömörítvénynév.tar.xz forrásmappa
tar -I 'zstd -T0' -cvf tömörítvénynév.tar.zst forrásmappaHa nem akarsz ilyen hosszút fejben tartani, akkor lehet rá Bash-aliast csinálni, a ~/.bashrc-be:
alias tomorit="tar -I 'zstd -T0' -cvf"Ha annyira nem akarod ezt a tar-os megközelítést, akkor tényleg az marad, hogy vagy a zip (zip csomag) vagy 7z (p7zip csomag) valamelyikével tömörítesz, de egyik sem kezeli rendesen a linuxos jogosultságokat és attribútumokat, így rendes archiválásra nem jók, viszont nem igénylik a tar-t. Ezen felül a zip elég gyengén tömörít (és nem támogat több szálat), gzip-nek felel meg (igazából opensource pkzip-klón), a 7z már jobban, és az tud többszálúságot (igaz csak 2-4 szálat tud kezelni) és solid archivumot, mikor egy fájlként tömöríti, de ilyenkor lényegében ugyanúgy működik, mint a tar+egyéb tömörítő megoldás, elveszted azt az előnyét, hogy windowsos logika mentén működik.
Ott van még a rar, de annál megint ugyanaz az elakadt lemez forog: windowsos logika, de nem kezeli a linuxos jogosultságokat, így archiválni nem jó, plusz proprietary formátum, plusz tud solid tömörítést, aminél megint elveszik az előnye a nem-tar-os megoldásokhoz képest.
A példáimban egyszeres idézőjelben meg tudsz adni a tömörítőnek más kapcsolókat is a -T0 mellé, pl. tömörítési fok, ennek a mikéntjét a man tömörítő kimenetéből tudod meg. Bár a default tömörítési fokot éri meg legjobban használni, mert annak van a legjobb tömörítési fok / tömörítési idő arányszáma, a nagyon erős tömörítése fokozatok gyakran aránytalanul lassúak, és a gyakorlatban nem tömörítenek annyival jobban, hogy számítson. Régen, mikor kisfloppyra meg CD-re kellett mindent rányomorgatni, meg netsávszélt kell kímélni, akkor fontos lehet a legjobb tömörítési fok, de sima archiválásnál nincs nagy jelentősége, ez nem csak az álltalános tömörítőknél van így, hanem pl. a lossless audiotömörítőknél is, pl. flac. A legextrémebben tömörít a PAQ8 vagy ZPAQ aktuálisan legújabb variánsa, de ezek maximum fokozaton több órán, több napon keresztül tömörítik sok giga memóriát felhasználva azt, amit a normál tömörítők perceken belül betömörítenek, és cserébe csak néhány százalékkal tömörítenek jobban, ergo nem éri meg, mert csak a saját idejét őrli fel vele az ember, csak ilyen elméleti versenyekre jók. Épp ezért favorit most a legtöbb embernél a zsdt, erre áll át minden disztró majd, mert ugyan pár %-kal rosszabbul tömörít, de olyan villámgyors, mintha tömörítetlen adattal dolgozna.
A példáimban csak betömörítést írtam, de kitömöríteni is így kell, csak a c kapcsoló helyett x kapcsoló kell.
-
BoB
Topikgazda
válasz
Shyciii
#7701
üzenetére
A zstd elég gyors, de be lehet állítani a tömörítés mértékét is a sebességg kárára / előnyére (mondjuk máshol is). (erre váltottak az arch csomagok tömörítésénél is).
Ráadásul ha Arch-ot használsz előbb említett okok miatt ez mindenképpen fent lesz már.
wiki.archlinux.org/index.php/Archiving_and_compression#Compression_tools
-
Shyciii
veterán
Hát ez elég gáz. Tar mellé én gzip-et szoktam használni, dehát...Amúgy a sima zip nem csak egy filet tud betömöríteni, hanem komplett mappákat, vagy ha akarod, akkor csak a megadott fileokat tömöríti be, amik ráadásul különböző helyekem van, szal a linuxos zip korrekt, de az se tud több magot használni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
kivételével minden megy, de azt meg amúgy is száműzni akartam. (imv lesz helyette)
(ne kérdezzétek hogyan) 
) nem pedig a Chromium-ot 
Új hozzászólás Aktív témák
BoB- BLACK FRIDAY! - Jogtiszta Windows - Office & Vírusirtó licencek- Azonnal - Számlával - Garanciával
- PC Game Pass előfizetés
- Árváltozás: Deus Ex Human Revolution Collector's Edition
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Vírusirtó, Antivirus, VPN kulcsok
- OnePlus Nord 2T 128GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! Samsung Galaxy S23/Samsung Galaxy S23+/Samsung Galaxy S23 Ultra
- Honor 90 512GB, Kártyafüggetlen, 1 Év Garanciával
- Dell Precision 7560 - Intel Core i9-11950H RTX A4000 32GB 1TB SSD FHD
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: BroadBit Hungary Kft.
Város: Budakeszi