-
GAMEPOD.hu
Arch Linux topik
Új hozzászólás Aktív témák
-
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.
-
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
[ Szerkesztve ]
You may corrupt the souls of men, but I am steel. I am doom.
-
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.
[ Szerkesztve ]
-
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ő.
-
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.
[ Szerkesztve ]
-
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.
-
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.
-
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
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
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
#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.
-
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
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.
[ Szerkesztve ]
-
-
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
É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 -
Csipem díítíí-t, de ezt most komolyan gondolta?
linkPassionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
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
-
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? -
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á.
-
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.
-
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:
![;]](//cdn.rios.hu/dl/s/v1.gif)
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][ Szerkesztve ]
Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
májkimiki
őstag
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. -
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. -
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.
-
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[ Szerkesztve ]
Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
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).
[ Szerkesztve ]
-
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.[ Szerkesztve ]
Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
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.
-
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
Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
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
Ha ''a'' ram megy dualban ''b'' rammal, és ''c'' ram megy dualban ''b'' rammal, akkor ''a'' ram megy dualban ''c'' rammal?
-
Shyciii
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ő. Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
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.
-
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.[ Szerkesztve ]
Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
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.
-
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.
[ Szerkesztve ]
-
csixy
addikt
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?
[ Szerkesztve ]
Kert, kütyük,munka,matek,morfondír...ennyi. Szóval ács nem vagyok, de nemrégiben sikerült faragnom egy mőködőképes fogpiszkálót.
-
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.
-
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.
-
csixy
addikt
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.
Kert, kütyük,munka,matek,morfondír...ennyi. Szóval ács nem vagyok, de nemrégiben sikerült faragnom egy mőködőképes fogpiszkálót.
-
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. -
csixy
addikt
"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. 
Kert, kütyük,munka,matek,morfondír...ennyi. Szóval ács nem vagyok, de nemrégiben sikerült faragnom egy mőködőképes fogpiszkálót.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
) nem pedig a Chromium-ot 
(ne kérdezzétek hogyan) 
Új hozzászólás Aktív témák
BoB- Mobil flották
- Samsung Univerzum: Így ismerhető meg a Galaxy AI bármilyen telefonon
- Vicces képek
- Mobilinternet
- Kerékpárosok, bringások ide!
- EA Sports WRC '23
- Videó stream letöltése
- Azonnali informatikai kérdések órája
- Ubiquiti hálózati eszközök
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- További aktív témák...
- Warhammer Online - Age of Reckoning (DE) Collectors Box (Figurával!)
- Eladó Steam kulcsok kedvező áron!
- Steam, Windows, Origin kulcsok, előfizetések közvetlenül a kiadótól, a LEGJOBB ÁRON!
- Vírusirtó, Antivirus VPN kulcsok
- Windows, Office licencek a legolcsóbban, egyenesen a Microsoft-tól - 2990 Ft-tól!