- Samsung Galaxy A55 - új év, régi stratégia
- Honor 200 Pro - mobilportré
- One mobilszolgáltatások
- iPhone topik
- Mobil flották
- Samsung Galaxy S21 FE 5G - utóirat
- Ilyen lesz a Fairphone 6
- Android alkalmazások - szoftver kibeszélő topik
- A lapkakészlet és az akku különbözteti meg a Motorola Edge 60 és Edge 60 Pro-t
- Karaktere biztos lesz az első Nothing fejhallgatónak
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
Siriusb
veterán
válasz
attilav2
#8922
üzenetére
The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications.
Esetleg még ezt érdemes elolvasni:
https://wiki.archlinux.org/title/Solid_state_drive#TRIM -
-
BoB
Topikgazda
válasz
attilav2
#8916
üzenetére
" ha minden igaz firmware-ból végzi automatikusan, semmilyen rendszer beállítást nem igényel"
Legalábbis ez az infó terjeng a linux kezdő topikban.
Csinálj egy fstrim-et. Mi a kimenet? Trim-elni fog.
Csinálj még egyet, nem fog trimmelni mert nincs mit.
Hozz létre egy fájlt tetszőleges mérettel. (pl. dd if=/dev/random of=./testfile bs=4M count=1) ez egy darab 4M méretű fájl.
Töröld le.
Csinálj még egy trimet, láss csodát, pont 4M adat trimmelődött.
Szerinted nvme esetén egy SATA parancsot akar kiadni az fstrim mert a fejlesztők annyira hülyék, vagy inkább egy nvme parancsot? (deallocate)
-
vargalex
félisten
válasz
attilav2
#8820
üzenetére
Nekem egy Xiaomi AX3200, egy Cudy WR3000 és egy D-Link DIR-860L is aktív használatban van. Egyiknél sem tapasztaltam sem vezetékes, sem wifi problémát. Sőt, ismerősök között többnél van több éve Asus RT-AC65P szintén OpenWrt-vel (én is használtam ezt több évig, most a szekrényben van), náluk sincs semmi hasonló. Mindegyik Mediatek SoC-al szerelt.
A Dynalink is aktív használatban van már, így sajna nem tudom nélkülözni.
-
vargalex
félisten
válasz
attilav2
#8814
üzenetére
Nekem a fiam gépében és egy régi gépben is Realtek integrált NIC van (az egyik Gigabyte alaplap). Semmi gond nincs velük Arch alatt.
Illetve az ASRock J3455-ITX-ben is Realtek NIC van, ott sincs gondom.
Merre vagy helyileg? Szívesen kipróbálnám azt az USB-s NIC-et...Nekem 3 db TP-Link UE300 USB-s NIC-em van, azok is mennek. Szintén Realtek chip-es.
-
sztpega
tag
válasz
attilav2
#8809
üzenetére
Lehet ez a gondod?
[link]
Nekem nincs gondom Manajron, de ezt írták megoldásnak:
Edit/etc/NetworkManager/NetworkManager.confto add:[connection-dad-default] ipv4.dad-timeout=0That disables Duplicate Address Detection (DAD)
Restart:$ sudo systemctl restart networkmanager -
attilav2
őstag
válasz
attilav2
#8261
üzenetére
Lehet hogy a veracrypt telepítő szúrta el a rendszert, a veracrypt mount.veracrypt állománya volt az egyetlen a /usr/sbin-ben levő bináris. Lehet a veracrypt telepítő szkriptje csinált a /usr/sbin-ből valódi mappát, de az is lehet hogy már korábban valami elcsezte a rendszert és csak utána telepítettem a vercryptet. A veracryptre vagy egy aur-os app-ra gyanakszok. Vigyázni kell a külső forrásokkal. Magyarch live alatt töröltem a /usr/sbin-t és symlinkeltem a /usr/bin-t /usr/sbin néven, a műtét úgy tűnik sikerült, bootkor nem jelzett az init hibát. Spotify szokott még rendetlenkedni, sokszor akadozik nem játszik le, de ez betudható annak hogy alapvetően debianra fejlesztették és archon nem tökéletes. Debian 11-en jól megy. Különbség még a debian és arch között hogy a debian még a LUKS jelszó bekérése előtt betölti a vga drivert, az arch csak a LUKS prompt után tölti be. Debian telepítőben ki tudtam választani a titkosított partícióra a noatime discard flageket, és működik az fstrim
Samsung840-nél a continous(folyamatos trim blacklistelve van a kernelben a ha jól tudom), ezért időnként futtatnom kell az fstrim-et, vagy van rá systemd service de abban nem bízom. -
Shyciii
veterán
válasz
attilav2
#8137
üzenetére
attilav2
Persze, hogy köröket ver sebességben a KDE-re. Kis túlzással úgy viselkedik a KDE és a Gnome a Linux világában, mint egy felhízlalt Windows. Aki egy kicsit is jobban érdeklődik a Linux iránt, az mind elkezd mozogni a KDE-Gnome páros irányából előrefele. A KDE-Qt-s appokat én is kerülöm. Leginkább azért, mert a Bspwm nem Qt-s, így egy olyan app használata igencsak megnöveli a felesleges csomagok számát.
I02S3F
Egyszer kell csak felkonfigurálni. Utána egy szimpla shell scriptbe beleteszed a felkonfiguráláshoz szükséges parancsokat, és az alap config fileokat ami a home könyvtáradban vannak meg vissza kell tenni a helyére és kész. Egész konkrétan ha én újra akarom húzni a rendszeremet, akkor 2db shell scriptet kell csak lefuttatnom, és ott vagyok, mint mielőtt legyalultam a rendszert. -
Frawly
veterán
válasz
attilav2
#8071
üzenetére
Elég ritkán történik meg, ahogy nézem, gyorsan helyre is hozták. Nyilván ők is emberek, korlátozott erőforrásból (saját pénz, adományok, nonprofit működés) nem tudnak egész szerverparkokat és adatcentereket ballancerrel megoldani, előfordul, hogy az az egyetlen szerveren lerohad valami, csak az nem hibázik, aki nem dolgozik. Ilyenkor visszanézel később. Semmit nem lehet ellene tenni.
-
Frawly
veterán
válasz
attilav2
#8046
üzenetére
Valahol már minden modern initrendszer kicsit systemd-szerű lett, mindegyik támogat párhuzamos service-indítást, service-függőségkezelést, eseményekre reagálást.
dhcp service-nek gondolom vannak kapcsolói, hogy kiírja mit csinál. Szerintem hosszabb távon jó, ha nem írja, nem hányja tele a képernyőt szeméttel, meg kicsit gyorsabban is fut.
-
Frawly
veterán
-
Frawly
veterán
válasz
attilav2
#8042
üzenetére
Az OpenRC-vel nekem vegyesek a tapasztalataim. Gentoo alatt bejött, Artix alatt hagyott kívánni valót maga után, de azért használható volt.
Amúgy isten hozott a minimalistább WM-ek világában. Igen itt minden kényelmi funkcióért küzdeni kell. De csak először, amíg meg nem érted mi kell hozzá, meg el nem mented azt a néhány .xml meg .conf fájlt a home-ból, .config mappából, utána elég csak azokat visszahúzni minden gépen, minden újratelepítésnél és meg fogod látni hogy így a fájlokat visszamásolva az egész sokkal gyorsabban újra bekonfigurálható, újra belakható, sokkal részletesebben testre szabhatóbb, mint a KDE valaha is volt/lesz, nem kell egyenként minden grafikus szarban hatodik fül eldugott menüjének akármijére kattintgatni végig, mire minden be lesz állítva. Az már csak hab a tortán, hogy mennyivel gyorsabb vele a gép, szemének alig hisz az ember, hogy a grafikus felület milyen gyorsan bevillan.
Azzal is egyetértek, hogy az Artix dokumentációja elég gyér, bár ők ezt úgy gondolják, ha valamit nem találsz benne, akkor az Arch Wikit olvassad. De a Gentoo Wiki is hasznos, meg tapasztalatom szerint a Debian Wiki is, utóbbi főleg a Wi-Fi driverek kinyomozásához, de vannak még benne egyéb jó dolgok, amik a többi Wiki-ben nincsenek benne.
-
Frawly
veterán
válasz
attilav2
#8040
üzenetére
Elvileg a cryptsetup defaultjai megbízhatók. AES256, XTS, meg valami min. 2048 bites hash.
Bitlocker megint olyan, hogy zárt forráskód. Próbálhatod helyette a VeraCrypt-et, az TrueCrypt formátumú konténereket és partíciótitkosítást tud, és azt el tudja olvasni írhatóra a LUKS.
A cryptsetup alapból nem titkosítja le az egész meghajtót, hanem csak headert ír fel, meg egy két adatot és csak annyit titkosít. A jövőben rákerülő adatok viszont titkosítva lesznek. Ennek ellenére cryptsetup után ajánlanak egy teljes dd if=/dev/rand parancsos végigírást, de szerintem ez nem szűkséges, majd ahogy telíted be a meghajtót, partíciót, majd titkosodik az egész adatterület.
-
Frawly
veterán
válasz
attilav2
#8038
üzenetére
Így van, ezeket teljesen jól foglaltad össze. Ha nem támogatja a BIOS, attól még használhatod, de bootkor, egy másik rendszer alól kell kinyitni hdparm-mal. Nyilván, így bootolni nem lehet róla, csak adattárnak használni.
Másrészt meg valóban, nagyon kell figyelni, hogy jól jelszavazd le, és ne felejtsd el a jelszót, mert a hardveres titkosítás nem csak az adataidat, hanem az SSD-t is védi lopás esetére, és ha nem tudod a jelszót, akkor reszeltek az egész drive-nak, nem lehet kinullázni, hekkelni, a gyártó sem tudja neked leoldani a titkosítást. Pontosan, ahogy írod, mehet a kukába. De ez téged véd, mert ha valaki megfújja a gépet, SSD-t, akkor hiába is próbálja elpasszolni, téglásítva lesz az egész SSD, se újraformázni, se semmit csinálni nem lehet vele. Jó, nagyon kevés kivétel van, mikor valami BIOS-os jelszavazási gyengeség (pl. üresen hagyja az admin jelszót, és az csak user ATA passwordot állítja, vagy az admin jelszót a gép sorozatszáma alapján generálja ismert algoritmussal, de ez ritka, gyártók kerülik).
A LUKS ezzel szemben törölhető, ha el is felejtetted a jelszót, csak az adatokat bukod róla, a drive bármikor leformázható. Meg a LUKS megbízhatóbb is, mivel opensource és auditált, így biztos lehetsz benne, hogy se NSA hátsó ajtó, se implementálási gyengeség nincs benne hagyva. Ha betartod a cryptsetupos ajánlásokat, akkor bombabiztos a LUKS, se az FBI, se a CIA ki nem nyitja a rohadt büdös életben, hacsak nem tudnak valahonnan szerválni egy qvantumszuperszámítógépet, ami bruteforce-szal belátható időn belül törni tudja.
-
Frawly
veterán
válasz
attilav2
#8036
üzenetére
A crypttabot azért nem tudom, mert ugyan használtam LUKS-ot már, de nem SSD-vel, hanem HDD-vel, és ott nem kellett TRIM-mel, discard-dal szórakozni.
Egyébként én még mindig amondó vagyok, ha SSD-id vannak, akkor az azokba beépített hardveres titkosítást használd. Neked is könnyebb, mert gép bekapcsolásakor a BIOS bekéri a meghajtók ATA jelszavát, onnantól kinyílik a titkosításuk, és a továbbiakban minden szoftver, OS, akármi úgy érzékeli, hogy titkosítatlan meghajtóra dolgoznak, közben meg titkosítás alatt van, de hardveresen, transzparensen.
-
attilav2
őstag
válasz
attilav2
#8029
üzenetére
Letitkosítottam a windowsos lemezeket is, windowsos rendszer ssd + exfat adattároló ssd, bitlockerrel. Az aur ban levő dislocker meg tudja nyitni a bitlockerrel titkosított lemezeket, itt van egy leírás a használatáról: https://www.ceos3c.com/open-source/open-bitlocker-drive-linux/
Frawly:
További beállításokat eszközöltem hogy a LUKS átengedje a TRIM-et, létrehoztam a /etc/crypttab.initramfs -t és beleírtam ezt: rd.luks.options=2e1434a6-a4ac-49bf-91a0-d4f7dd5d3619=discard (a titkosított lemez uuid-je szerepel benne) ahogy a wikiből kihalásztam így kell csinálni, bár lehet elég lett volna a rd.luks.options=discard, inkább biztosra mentem, utána újra generáltam az initramfs-t. fstab-ba bekerültek a discard,noatime opciók.
Nem reklamált a rendszer bootoláskor, persze tudom ez nem azt jelenti hogy működik trim, de akár működhet is
A wiki szerint, ha jól értelmezem. az /etc/crypttab -os bejegyzéseket az initramfs miatt nem veszi figyelembe bootoláskor a rendszer bootlemez esetén, illetve ez a fájl arra való hogyha a bootlemezen kívül van más titkosított lemez akkor azoknak az automatikus felcsatolását lehet benne defdiniálni a megfelelő opciókkal. -
Frawly
veterán
válasz
attilav2
#8031
üzenetére
Az Arch Wiki ajánlja még a rd.luks.options=discard kernelparamétert is, ahogy a screenshoton is látszik. Ezen túlmenően a crypttab-ba és az fstab-ba is kell a discard paraméter, ha az SSD-n lévő fájlrendszer támogatja, ha nem támogatja, akkor meg fstrim-et kell helyette ütemezni.
Egyébként az SSD-k nem szeretik a szoftveres titkosítást, mert az teleírja őket, és nem látják, hogy mi a hasznos adat, mi nem. Ezen a TRIM egy kicsit tompít, de az SSD-knek nem nagy barátja az egész lemezes szoftveres titkosítás.
Ezzel a linkeden azért nem foglalkoztak, mert ott NVMe SSD-t használtak, azon meg máshogy van megoldva a TRIM-nek megfelelő opció, hardveresen, így nem kell ezzel szórakozni.
Azért is támogat több SSD is hardveres öntitkosítást, közöttük a 860QVO is támogatja az AES-256-ot. De! Ehhez olyan alaplap kell, ami van TPM 2.0 chip, és a BIOS is támogatja az ATA jelszót. Az a baj, hogy a legtöbb konzumer gép nem támogatja, csak céges notik, céges desktop, thin client, workstation, server, stb.. Nem is értem, hogy a konzumer lapokról ezen mit spórolnak le, mert nem valami drága megoldás. Persze elméletben lehet úgy is használni, hogy az alaplap nem támogatja, hanem boot után te nyitod ki hdparm segítségével, de ilyenkor meg nem lehet róla bootolni. Csakis ATA, SATA, AHCI SSD-knél fontos ez..
-
Frawly
veterán
válasz
attilav2
#8028
üzenetére
Persze, hogy működik. Ez egy teljesen sztenderd telepítés, annyi benne a csavar, hogy cryptsetup-pal letitkosította a második partíciót, és arra telepítette a rendszert. Illetve a systemd-boot menüjében hozzáadott egy extra sort: options cryptdevice=PARTUUID=bla-bla... Illetve, ha tudod így telepíteni, akkor ennél kell maradni, és hagyni a GRUB-ot.
Amire még figyelj, hogy ha SATA SSD-ről van szó, akkor a TRIM átengedéséről a LUKS rétegén gondoskodni kell. NVMe SSD-nél (amilyen a leírásban is van), meg HDD-nél nem kell ilyen.
Vim az hasznos, de nem kötelező azt használni konzolban sem. Bármit felrakhatsz magadnak, leginkább a micro nevű text editort ajánlom, de van helyette egy csomó másik: ne, e3, ee, nano, tilde, mcedit, emacs, uemacs, vagy amit akarsz. Van egy rakat, közülük egy csomó „hagyományosabb” a vim-nél. Régen a base csomag része volt a vi, de már nem az. De szerintem a vim a legjobb az összes közül, főleg, ha tud valaki gépírni. Illetve az Emacs is nagyon jó, de azt sem sokkal könnyebb megtanulni, mint a vim-et.
-
-
Frawly
veterán
válasz
attilav2
#8003
üzenetére
Teljesen jó termelésirányításban, meg akármire is. Ezt már többször is írtam, hogy céges felhasználásra csak LTS az igaz volt régen, de már jó pár éve nem az.
Igazából a rollingságát is lehet tompítani az Archnak. Pl. nem frissíted olyan gyakran, meg helyi tárolót hozol létre, ahova csak olyan csomagot engedsz be, amit egy tesztgépen már teszteltél, a többi gép meg már csak ezeket húzhatja le. Ja, külön munka, de ha az egész cég archos ökosisztéma, csomó géppel, akkor simán megéri.
Inkább csak annyi, hogy általános ipari és céges felhasználásnál szerintem elveszik az Arch előnye, de hátránya se nagyon van. Igazából ízlés kérdése, hogy ki mit ismer, miben bízik, stb.. A legtöbb helyen nem azért van Red Hat alapú disztró, meg Ubuntu LTS, meg Debian, mert azok a legstabilabbak, hanem a legtöbb IT szakember azokat ismeri, így azokat vállalja be. Sokan csak egy Archot azért nem piszkálnának meg bottal sem, mert nem ismerik, nem szokták még meg, és úgy vannak vele, hogy éles környezetben nem fognak elkezdeni tanulgatni. De ez nem jelenti azt, hogy éles környezetben ne lenne bevethető.
Félig a lustaság is benne van. Az informatikus nem szeret dolgozni, minek frissítgessen állandóan Archot, ha egyszer egy CentOS-nél meg elmegy, hogy évente egyszer frissíti, és 10 évig nem kell komolyabban hozzányúlnia. Az LTS meg a miegymás ezt a lustaságot is kiszolgálja. Szintén a lustaságot van hivatva segíteni, hogy a nagy céges corporate disztrókra supportot is tudsz venni, ami ugye nem szükséges, de sok cégnél kényelmes, hogy ha gond van valamivel, akkor nem neked kell megcsinálni, hanem lehet a megoldásért más hátát verni, meg mindig mástól várni a megoldást.
Sőt, tovább megyek, a legtöbb helyen azért van Windows onlyság is, mert azt biztosan ismerik, van vele belső tapasztalat, ahhoz mindig találni szakembert is, mert Dunát lehet velük rekeszteni, van hozzá support. Nem azért használják, mert stabilabb meg jobb lenne.
-
Shyciii
veterán
válasz
attilav2
#8003
üzenetére
Én is jópár éve használok Arch-ot, és volt hogy a frissítés után nem tudott bebootolni. 2-3 ilyen alkalom volt, míg Windows 10-es munkaállomások a melóhelyemen egyszer sem haltak meg. De ettől függetlenül nem az a gond, hogy valaki Windows-t használ, és összeomlik, és akkor kész vége. A jobb melóhelyeken, vagy nagyobb cégeknél, vagy akár kisebbeknél is ha jó rendszergazdájuk van, akkor ott kezdődik, hogy minimum van 2-3 gép tartalékban, felinstallálva+programok, és csak a user-t kell létrehozni, meg mondjuk microsoft365-be bejelentkezni, és kész. Persze ehhez kell egy olyan felfogás is, hogy lokálisan semmit nem tárolunk. Arra ott van a file szerver, vagy ha pl MS gold partner, akkor szinte biztos hogy OneDrive is van használatban. Innentől kezdve semmi extra egy új tartalék gépet üzembehelyezni. Gyorsabb, mint hogy helyrehozd a Windowst, vagy Linuxot. A még komolyabb MS technológiát használó cégek meg akár roaming profile-t is használhatnak pluszban, ami aztán végképp fullosan visszahozza még a profile adatait is, hogy milyen ikon és hol vannak az asztalon. Szal egy cégnél, főleg termelésirányítást is végző cégnél, ami kritikus munka minimális leállásal, ott nem az oprendszer számít, hanem a rendszer egészének működése.
-
válasz
attilav2
#8003
üzenetére
évek óta kizárólag Arch fut a saját munkaállomásomon, bár nyilván ha valami nyűgöm volna, azt magamnak könnyen tudom orvosolni.
ennek ellenére nem nagyon volt bajom, sima irodai munkára bátran merném ajánlani.
termelésirányítónak, stb... ha az adott szoftver fut Linuxon, akkor nem érzem hogy bármivel nagyobb kockázat vagy probléma lenne, mint a Windows, sőt... -
Frawly
veterán
válasz
attilav2
#8001
üzenetére
Az efistub nagy királyság, annak a lényege, hogy a kernel közvetlenül .EFI binárisként bootol, nincs semmilyen bootmaganer (az UEFI egymagában is egy bootmanager). De az efistub-ot nem támogatja sok nem szabványos gyártói UEFI, meg ha initramfs, titkosítás, stb. van, akkor vagy nehézkes lehet, vagy lehetetlen.
Én systemd nélküli disztrókon lehetőleg efistub bootot használok, systemd-s disztrókon systemd-bootot, mert az is még kellően egyszerű. GRUB-ot csak akkor tennék fel, ha valami RAID-ről, egzotikus partíciótípusról, spéci titkosítós mókáról kell bootolni, vagy MBR Legacy bootkor (bár akkor is hajlanék valami egyszerűbb bootmanager felé).
-
Shyciii
veterán
válasz
attilav2
#7999
üzenetére
https://linuxhint.com/setup-luks-encryption-on-arch-linux/
Ahogy nézem semmi extra nincs a luksban. Lásd fenti link. Pár sorral több csak a telepítés. Nyilván systemd-boot esetén más a /boot. Mondjuk vmware alatt lehet hogy kell más is, de azt nem tudom. Én az összes próbálkozásomat a saját fizikai notimon csináltam, mert az ha működik, akkor nem kell még azt átirogatnom, hogy fizikai gépen is működjön. Nyilván ha ilyen volumenű dolgot csinálok, mert van időm, akkor előtti csinálok a rendszerről egy image-t. Mondjuk múltkor már arra sem volt szükség, mert a jelenlegi telepítőscriptem a beállítássaimat is visszatölti az adatokkal együtt :)
-
Frawly
veterán
válasz
attilav2
#7993
üzenetére
Kiegészítés: egyébként nem haszontalan, mert ha legközelebb egy gépre valami gyors disztrót akarok feltenni, az már lehet nem Mint vagy Xubuntu vagy hasonló lesz, hanem ilyen archinstall scriptes vanilla Arch. Tehát ez haladóknak is jó lehet, ha gyorsítani akarnak a telepítésen. Mert sokszor telepít az ember egy 1-2× használatos, eldobható rendszert, ami gyorsan kell valami alapon kerül fel, arra az esetre kiváló. Tehát mint írtam, nem vagyok ellene. És ahogy a Phoronixon olvasom, ez ne is automatizálva lesz az Arch telepítőn, hanem egy parancs formájában kell behívni, ergo aki akarja, használja, aki nem akarja, annak továbbra is lehet hagyományos kézi módszerrel Archot telepíteni. Így tőlem elfér.
Meg azoknak is emberkéknek is jó lehet, akik már majdnem ott vannak azon a szinten, hogy Archot használjanak, de eddig valami nem ment a kézi wiki-s telepítésnél, és állandóan feladták, de már kevés hiányzik nekik, őket átsegítheti ezen a ponton egy extra lökést adva. Így már nem lesz visszatartó erő, hogy jajj, nincs installer, meg nem kell gyanús, gányolós, 3rd party installer scriptek beszerzésével és működésképtelenségével vergődni.
-
Frawly
veterán
válasz
attilav2
#7993
üzenetére
Ez még nem bloatosodás, csak épp értelme nincs. Az Archnak szándékosan nincs telepítője, hogy ne találja ki a user helyett, hogy mi kell neki. Persze, eddig is voltak 3rd party telepítőscriptek, de azokkal az Arch értelme lett lehúzva a klotyón, meg sok láma összealkot vele ilyen gányolt telepítést, aztán jönnek az archos topikokba, mert nem érik hogy működik, mi van telepítve, mi mi miatt nem jó. Mert ha te telepíted kézzel a Wiki alapján, akkor a parancskimenetekből látod, ha valami nem jó. Ha egy installer csinálja helyetted, akkor nem látod.
Persze ettől még félpozitív hír is lehet, mert ha több user áll be az Arch mögé, akkor több csomag lesz rá, több tároló, jobban fejlődik. Inkább egy független Arch mögé álljanak be a userek, mint ilyen corporate bullshit Coninical, Red Hat, Süsü baromságok mögé. Szóval engem nem annyira zavar.
Annyiból viszont félnegatív hír, hogy ha sok windowsos meg ubuntus láma beáll mögé, akkor viszont az megindíthat nagyobb bloatosodást, csak azért, hogy őket kiszolgálják. Az meg nem lenne jó.
Egyébként én ha kezdőbbeknek kell Arch, Arco Linuxot szoktam ajánlani. Viszonylag egy normális belga faszi csinálja (Erik Dubois, még YouTube-csatornáján is közzétesz segítő videókat), vanilla Archot kap a user, ha feltelepíti (szemben a Manjaro-val, ami módosított tárolókat használ, meg le van maradva verziókkal), és általában még nem túl bloatak a lemezképek, default Archhoz elég közel vannak, nem kell túl sok sallangot elviselni a rendszeren. Az Arco Linux meg rendes telepítővel jön, azt hiszem Calamares. Így egy kezdőbb user is belekóstolhat a rollingba, meg a frissességbe. Vannak nagy DE-s és kisebb WM-es lemezképek is belőle.
-
Shyciii
veterán
válasz
attilav2
#7983
üzenetére
Én a Bspwm előtt Openboxot használtam. Tavaly nyáron még megvolt a config, de már töröltem, mert egyértelmű lett, hogy nem fogok visszamászni Openbox-ra. Amúgy az Openboxot szerintem könnyebb volt konfigurálni (általánosságban, mert pl a Bspwm szerintem könnyebb, de pl a qtile, xmonad nehezebb) ráadásul ott erre volt egy-két gui-s applikáció. Amúgy ahogy Frawly-nek, nekem sem az a tapasztalatom, hogy az Openbox kevesebbet fogyaszt, mint a TilingWM-ek. Itt egy régi kommentemből idézet:
"Hidegindításkori memóriafoglalások:
Openbox: 201MB
i3: 196MB
Bspwm: 185MB
Qtile: 227Mb"
Ezek mind fizikai gépen történtek, ugyanazon programokkal, ugyanazokat betöltve, ugyanolyan kinézettel. Itt látszik, hogy a Bspwm-el kaptam a legjobb eredményt. Az érdekesség még, hogy azóta a Bspwm nálam 141MB-ot foglal. Úgy látszik ennyit egyszerűsítettem a rendszeremen azóta -
Frawly
veterán
válasz
attilav2
#7983
üzenetére
Itt el tudod érni a konfigom Openboxhoz. Egyben illesztettem be, az eleje a ~/.config/openbox/autostart script, a második bekezdéstől pedig a ~/.config/openbox/rc.xml.
Amiket használtam: picom kompozitor yshui forkja (ezt később dobtam), polybar panel, dmenu, xss-lock, synclient (Synaptic-kompatibilis touchpadhoz többujjas bindek), xbindkeys a multimédiagombokhoz, feh a háttérkép beállításához. Termite terminál, saját scriptek, képernyőkímélő asciiquarium teljes képernyős terminálban futtatva és transzparens i3lock-kal zárolva, képnézőnek imv, videók és audió lejátszsára mpv, pdf/ps/djvu nézésére Zathura, neovim szövegszerkesztésre, Vifm fájlkezelésre, csatolásra saját script, sok scriptem fzf-választót használ (az fzf ugyanolyan, mint a dmenu, de terminálban fut és rugalmasabban keres). De szinte minden megoldásom terminálos, pl. htop és hasonlók, majdnem mindent saját script végez, SSD infók kiírása, kézi fstrim, hangerő szabályozására pamixert használó script, vagy pulsemixer (amit látok te is használsz), torrentnek transmission-cli tremc terminálos klienssel vagy webes klienssel (böngésző), de mostanában btcli-vel kísérletezek helyette. Időjárás nézésére curl wttr.in. NTP-re ntpd, fényerőszabályozásra light, emellett redshift-script, screenshotozni scrot (Sway alatt grim), androidos teló csatolására jmtpfs script. Wi-Fi-hoz egyszerű wpa_supplicant + dhcpcd scripttel csatlakozok egy lépésben. Számológépnek calc (ez egy terminálos progi), illetve Python-értelmező. Login manager nincs, közvetlenül konzolban jelentkezek be, és bashrc-be az adott felhasználó/tty[szám] kombóhoz drótoztott WM indul el előre megadott xinit-scripttel.
A WM-ben a legtöbb progi Super+A-Za-z gombokra indul, speciális funkciók Super+1-9, Super+F1-F12, Alt-Tab, Alt F1-F12, PrnScr, stb. billentyűkre érek el funkciókat.
Egyébként most is ezeket használom kb., de dwm alatt, de a polybar helyett a dwm saját panelja megy egy dwmbar-script segítségével kiírva rá a doglokat, i3lock helyett alock, nem fut már kompozitor, médiagombokat is a dwm kezeli xbindkeys nélkül. Elkezdtem clipmenud-vel is kísérletezni, de ez nem jön be.
Mindenre próbálok vim-es kiosztást használni programon belül, minden mappára át tudod váltani közvetlenül fd + fzf kombót használó scripttel, minden doksim megnyitom fzf-es scripttel, 1-2 billetnyű lenyomása után ott van, akárhány almappa mélységben, az adott mappán, adott doksinál. Így 1-2 billentyű lenyomására gépírás módban ott van minden az ujjam alatt, az összes fontos program, mappa, doksi, azonnal nyílik, lag, betöltési idő nélkül, a billentyűt nincs időm felengedni, már a képernyőn van. Nincs grafikus tallózás, nincsenek ikonok, nincsen dokk, nincs tálcaapp, nincs egerezés, csak egész képernyős programok, gap, keret, fejléc, toolbar, menüsor, akármi nélkül. Tiling módba ritkán váltok, ha több mindent kell látni, vagy át kell tekinteni, hogy mi fut (a KDE érzékeny sarokmegoldása ihlette), ilyenkor az alap master-stack layoutot használom, ami default az összes tiling WM-ben. Nyilván ez Openboxnál nem játszik, de annak van saját taskváltó listája helyette.
Firefox a böngészőm, benne Tridactyl addon, ami vim-módban kezeli a böngészést, billentyűkkel, egeret így itt is alig használok (kivételesen igen, pl. a vim-es billentyűk miatt nem működne a YouTube-on a webes videólejátszó gyorsbillentyűi, így itt automatikusan kikapcsolódik a vim-mód, és egeret is használok, de nem is az egér a jó szó, hanem touchpad gesture-öket). Ténylegesen egeret csak akkor használok, ha FPS, TPS, szimulátor játékkal játszanék.
Kicsit külső szemmel figyelve olyasmi mikor a gépet használom, mintha MS-DOS-t használnék, billentyűzet, terminál, teljes képernyős szöveges progik, 0 betöltési idők. Alig-alig van grafikus progi, Firefox, Goldendict, 1-2 alkalmazás ritkán Wine-ban (pl. Scriptum GIB szótár), Steam, néhány játék (vegyesen natív linuxos, és windowsos Wine-ban).
De mégse DOS, mert nem legacy rendszer, hanem modern 64 bites, legújabb verziók, modern programok, ha valami régi is (pl. vim 90-ből, ami a 70-es évekbeli vi-ra megy vissza), annak is modern változatát használom (neovim), vagy kétpaneles fájlkezelő (ami a Norton Commanderre megy vissza, ehelyett Vifm, megint a vi/vim-mód miatt). Természetesen a minimalizmus miatt semmiről nem kell lemondanom, épp úgy fut minden GUI-s program, játék, médialejátszó, modern kódek, hardveres gyorsítás mindenféle kódekhez és grafikus API-hoz. Tehát nincs az, hogy hátrányt szenvednék akármiből. Nyilván, ha valami ritkább, GUI-s prorgamot indítok, az nincs az ujjam alatt, az dmenu-ből keresem ki, vagy fzf-script listázza (pl. játékok), de az is villámgyorsan nyitható, gyorsabban, mintha valaki ilyen hagyományos grafikus menüből tallózgatná ki egérrel.
De ahogy észrevettem, youtube-os linuxerek is hasonló rendszerrel dolgoznak, mind Arch vagy (ritkán) Gentoo alap, pálcika tiling WM, terminálos programok, neovim (vagy modern Emacs-disztró), fzf, dmenu, billentyűzet-only vezérlés. Nyilván azért nem ugyanaz a rendszer mindenkinél, mert más a WM (dwm, bspwm a legnépszerűbb, de előfordul minden más is), más a téma, más színek, betűtípus, más terminálemulátor (Alacritty és Termite a legnépszerűbb), más böngésző (most a linuxosok körében népszerűbb a Brave, mint a Firefox), más fájlkezelő (Vifm helyett vagy mellett lf, ranger, nnn, PCmanFM, Emacs dired), más screensaver (asciiquarium helyett pl. cmatrix vagy hasonló), stb., de a lényeg nem változik, hasonló rendszer, hasonló filozófiával. Nyilván két egyforma rendszer nincs, mert mindenkinek más szájíz diktálja a billentyűzetkombókat, amire drótoz, más progikat használ, más az ízlése, más a felbontása, monitormérete, billentyűzetkiosztása, hol laptop, hol asztali gép, hogy 1, hol 3 kijelző hol ergonomikus/osztott billentyűzet, hol másik kiosztás, stb.. Sok ötletet a youtube-osktól meg reddittről, unixpornról szedtem, sok megoldást ott láttam először, de nyilván ezeket már saját kútfőből is keresem, meg próbálom saját ötletekkel optimalizálni.
Egyébként nekem a Sway jött be eddig legjobban, de egyrészt mással is kísérletezni kell, nem ragadhatok le egy megoldásnál. Meg van 1-2 hiányossága is a Swaynak. Pl. teljes képernyős vagy floating módos programról nem tud átváltani a háttérben futó másikra, bár ez nem bug, hanem minden tiling WM-ben lévő feature, meg pl. nem mutat tasklistet, amikor alkalmazások között váltasz át, akár azonos monitor vagy workspace-re, akár nem, ez jó lenne bele, bár wrofi-val talán pótolható, de nem volt még türelmem megcsinálni. Vágólapkezelését is egységesíthetnék X-es és Waylandes alkalmazások között, ezt sati kolléga megoldotta clipman-nel.
A konfigom is mindig változik most fogok bspwm-re váltani, így megint lesz változás. Emiatt nem is szoktam a rendszerről mentést csinálni, csak az adatokról, adatfájlokról. Rendszermentés visszahúzásával nem is mennék semmire, ha egyszer a rendszer mindig változik.
-
Frawly
veterán
válasz
attilav2
#7981
üzenetére
Sway konfigom feltölhetem neked a pastebin-re, de sokra nem mennél vele, mert egy majdnem teljesen stock Sway config, amit elérsz a /etc/sway/config vagy /usr/share/doc/sway/ alatt.
A konfig egy része amúgy is az én felhasználásomra van, keybind-ek, pl. meg billkiosztás, egyes hardverek pollrate-je, ID-je, ezzekkel semmire nem mennél. Ráadásul én a Sway-t és az i3-at is tabbed layoutban használom szinte kizárólag, nem tilingban, semmi extra layout, semmi gap, semmi cicomázás, nincs ablakkeret, nincs fejléc, nincs semmi, szerintem a falnak mennél tőle. Tehát a Sway konfigom egyik része neked teljesen irreleváns lenne, a másik része meg teljesen default, az i3-as konfig meg már meg sincs.
De igen, ezt nem hitted el, hogy a minimalizmus nem csak gyenge hardveren kamatozik. Az egész futási teljesítmény, lagok hiánya, prociterhelés, stb. is egész más, más használni a gépet. Ezek a KDE szintű monstrumok annak lettek kitalálva, aki modern, erős hardveres használja, windowsos desktop mentalitással, és nem akar azon a szinten túllépni, hogy egérrel kattintgat ikonkra. De hogy ilyen cast, szerver, meg hasonló spécibb dolgokra is van használva, ott már kijön a tiling meg a minimalizmus rugalmassága, aki ehhez hozzászokott, már nem fog visszatérni hagyományos DE-kre, mert túl korlátosnak, lassúnak, rugalmatlannak fogja érezni.
-
Frawly
veterán
válasz
attilav2
#7979
üzenetére
VGA gyorsítást én ebben nem látok. A Firefoxot hagyd le, mert zavarja az adatok kiértékelését. Kicsivel több lett a fogyasztás, de nem annyival, mint vártam, talán mert nem fut 3D gyorsítás vagy nem tudom. Mondom, ez a mennyi az az annyi, azt akkor látod meg, ha fizikai gépre teszed fel, olyan rendszerre, amit tényleg használsz is napi szinten. Pl. egy 16 gigás pendrive-ra, vagy egy külső SSD-re vagy HDD-re.
Na meg ilyen virtuális gépen természetesen nem csak az Artix fogyaszt kevesebbet, de egy systemd-s Arch is. Ha már életszerűtlen környezetben hasonlítunk össze.
Egyébként Archon nálam még mindig fut két extra nyomorékság, amit sosincs időm kihekkelni, valami spi2 görcsség, meg polkit baromság, természetesen egyik se kéne, és sokat foglalnak. PulseAudio helyett lehetne apulse-t használni. picom kompozitort már régóta elhagytam, igaz így nincs árnyék meg átlátszóság, de nem sok különbség van szemre, vsync viszont épp így van. Háttérképnél is elértem, hogy a feh vagy xsetroot nem marad betötve, hanem kilép, miután lecserélte a hátteret. De még mindig érzem, hogy lehetne még mit minimalizálni a rendszeren, igaz már sokat nem nyerek vele, 1-2 folyamatot lehetne még megúszni, meg alig néhány MB memóriát lespórolni, de egy idő után az ember elég egy olyan minimalista korlátot, amit már nem lehet meghaladni, vagyis legalább úgy nem, hogy a rendszer általánosan használható desktop marad, ami mindenre használható.
Plusz nálam pl. olyanok is futnak, mint ntpd, amire nagy szükségem is van, mert ezen az új gépen hajlamos a gépóra sokat késni. A másik, régi laptopom meg asztali gépen ez nem jellemző, ott csak eseti jelleggel futtatnék NTP-t, de ezen a gépen hatványozottabban kell, meg ez a pontos idő nálam mánia is. Megint: hardverfüggő is.
Ez ilyen, ez egy folyamat, idő kell neki. A minimalizmus sose olyan, hogy meg lehet erőszakolni 5 perc alatt. Próbálkozni kell többször, új megoldásokat felfedezni, configokkal kísérletezni. Egy min. több éves utazás.
-
Frawly
veterán
válasz
attilav2
#7977
üzenetére
Na, látod, erről beszéltem. Ha feltennéd a VBox Guest Additions-t is, azaz a hozzá való KMS modulokat az Artix tárolóiból, meg belövöd rajta a hardveres gyorsítást, meg még nyitsz pár böngészőfület, és máris még jön rá jó pár mega. Azért is mondtam, hogy van egy gyakorlati minimum, amit figyelembe kell venni, és nem szabad ilyen kérdésben sem sznobságból túlzott, értelmetlen minimalizmusra törekedni, mert azért a hardvereket meg kell hajtani, kellenek a különböző gyorsítások, ha az ember tartalmat fogyaszt, böngészik, esetleg játszik, stb..
Mint írtam, gépfüggő is, mert vannak emberek, akinek a nyomtató miatt CUPS, szkenner miatt Sane modulok, PPP csatlakozó egyes hálózati kapcsolatokhoz, webkamera, ujjlenyomatolvasó, stb. szutykok is igényelnek futó drivert, ez szépen mind jön rá.
De ez nem csak Linux alatt van így. Amlékszem anno XP is, mikor 140 MB-ot evett a rendszer boot utáni idle-ben, ahogy felment pl. egy bloatabb HP vagy Samsung, Cannon nyomtatódriver, máris megugrott közel 300-ra. Csak egy darab drivertől. Ha még jött rá ilyen Radeon Catalyst a .NET szutykaival, meg egyéb tálcaalkalmazások (pl. Intel RST, Creative Control Panel, stb..), máris hízott tovább.
-
Frawly
veterán
válasz
attilav2
#7975
üzenetére
Nekem fordított irányú a tapasztalatom, és nálam a Sway eszik kevesebbet, igaz két különböző gépen néztem, ahol az eltérő méretű driverek jelenthetnek különbséget, az egyik Intel IGP-s gép, a másik AMD APU-s. Az intelesen a Sway majdnem 100 megával kevesebbet eszik, mint az AMD-sen a sokkal minimalistább X.org + dwm.
Mint mondtam, virtuális gép alatt sose fogsz valós számokat, valós viselkedést látni, ahhoz fel kell tegyed fizikai vasra, rendesen. Nem csak a GPU miatt, hanem pl. hangdriver, Pulseaudio, egyéb szutyok is fut egy átlag desktop rendszeren, míg virtuális gépben, ha nincs hangeszköz, nincs hardveres GPU gyorsítás, akkor egy csomó driverrel, kernelmodullal kevesebb is fut. Egy zárt NV driveres rendszeren ez elvileg még rosszabb, főleg, ha a user még egy csomó más hardvert is hajt róla. Tehát az, hogy minek mekkora a fogyasztása, az elég gépfüggő is, meg attól is függ, hogy ki mire használja a gépet.
Amit ilyen virtuális gépekben, mindenféle extra hardveres körítés és virtuális extension nélkül látsz memóriafoglalási adatokat, azok csak elvi minimumok. Lehet ilyeneket a valóságban is elérni, pl. egy Gentoo + X.org + dwm trióval, ha nem fut GPU driver, nincs még hang, stb., akkor esetleg, pl. ilyen beágyazott rendszereken. De desktopnál, amin böngészel, meg használsz mindenféle programot, ott a 100 mega alatti foglalás irreális. Akármi az initrendszer.
-
Frawly
veterán
válasz
attilav2
#7972
üzenetére
Ebből a memóriafoglalásból nem lehet kiindulni. Csalóka. Virtuális gépben futó rendszernél nem lesz GPU driver, nem lesz hardveres gyorsítás, nem fut mesa, nem fut kompozitor (jó ennek nem is kell más rendszeren sem), nem fut hangdriver, stb.. Úgy persze, hogy kevesebbet foglal. Igazi gépen nézd, ott bőven lehet kb. ugyanez a rendszer az általam írtakkal 200-250 MB is, ha valami komolyabb dedikált GPU-d van, vagy modern AMD APU. Intel IGP kicsit soványabb, de ott is meglesz vagy 150 MB körül.
A megakadás kikapcsoláskor is lehet ACPI driver meg nem felelősége, ez igazi gépen nem lesz problma. Initrendszer ízlés kérdése. Artixot mindjárt háromféle inittel is lehet telepíteni. Nekem egyébként a systemd-vel nem is a tulajdonságai, memóriafoglalása a bajom, hanem hogy minden dependel rá, és nem lehet elhagyni maradéktalanul. Itt a képeden is bizonyíték, hogy ott fut az elogind, ami systemd-logind részimplementációja, ergo nem kerülted ki teljesen.
A másik baja az alternatív initnek, hogy a bootidejük általában kicsit lassabb, és a disztrónak sok csomagot patchelnie kell, hogy menjen nem systemd-inittel, és emiatt kicsit lassabban érkeznek meg az újabb verziók bele. Szóval ez a systemd-nélküliség kétélű fegyver.
-
Shyciii
veterán
válasz
attilav2
#7968
üzenetére
Hát elég minimalista rendszert használok Bspwm-el. Helyenként túlzóan is. Pl az usb-s háttértárakat egy script oldja meg, de pl használok network managert hiába bloat, mert ez egy notebook, így kell kényelmes wifi választán, vagy openvpn-es csatlakozás.
Én nem ismerek teljes systemd mentes arch klón-t, csak az Artix Linux-ot, ami részben systemd mentes, de azért van benne egy-két ráutaló jel. Asszem tán az elogind pl., s-ig systemd-mentes. -
Frawly
veterán
válasz
attilav2
#7959
üzenetére
Örülök, hogy sikerült. Ez a másik szépsége a Linuxnak a Windowszal szemben, hogy nem csak szektor alapon lehet klónozni, nincsnek rejtett szektoros trükkök. Simán fáljalapon másolható.
Az rync kapcsolói nem fontosak. A nagybetűs kapcsolók csak nagyon speciális esetben fontosak, a --progress 2 semmit nem gyorsít (azért volt gyors, mert SSD-ről volt szó, nem a kapcsoló miatt), igaz ezek a sebességen nem is rontanak. Ha az Arch Wiki így ajánlotta, akkor jónak kell lennie.
Természetesen bármi alól csinálható, még csak Arch alapúnak sem kell lennie, csak legyen rajta egy konzol, shellel meg rsync-kkel. Ez megint csak a CLI toolok szépsége, nem kell neki GUI, meg 1-2 gigás Live iso, és hasonló extrák.
Ez az rsync nem csak rendszerklónozáshoz jó, hanem backup készítéséhez, gépek közötti adatátvitelnél is jól hasznjálható, sokoldalú alapparancs, megéri ismerni a használatát. Szerintem a kapcsolói kicsit hülyék és komplikáltak, de simán megtanulható.
-
Frawly
veterán
válasz
attilav2
#7956
üzenetére
Igen, írtam, hogy a dd az üres blokkokat is átmásolja, de ez nem tragédia. Írtad, hogy SSD-ről van szó, azon eleve nem tart sokáig, másrészt szekvenciális művelet, ami egy HDD-n sem annyira rettenet lassú.
Ez az e2image is megfelelő lehet, bár nem ismerem, így ebben nem tudok segíteni, hogy hogyan használd. Max utána tudnék olvasni, de azt te is meg tudod tenni magadtól.
Amikor én csináltam ilyet, akkor tömörített tar-t használtam:
cd /
sudo tar -czfpv --one-file-system /cel/backup.tar.gzMajd ezt bontottam ki a céllemez előre létrehozott partíciójával
sudo tar -xzfpv backup.tar.gz /cél/felcsatolás
(ebből a -p nem is feltétlen kellett volna, a -v csak a fájllistázáshoz van, a z=gzip, de lehetett volna használni -j, -J, --zstd vagy egyéb kapcsolókat helyette)
De lehetett volna így is, pl. root partíciónál, az előre létrehozott, formázott, és felcsatolt célpartícióra:
sudo rsync -avHASX / /cél/csatolás/
Ez is kicsit overkill, mert szerintem elég lenne az rsync -a, a többi kapcsolónak nem lenen szerepe egy átlagos rendszeren.
Az rsync előnye, hogy előbb nem ment tömörítvénybe, hanem közvetlenül másol forrás és cél között. A tar viszont jobb, ha el is akarod tenni a mentést backupként.
-
Frawly
veterán
válasz
attilav2
#7953
üzenetére
Ha tényleg nagyobb a céllemez, mint a forrás, akkor nem kell semmilyen clone-szutyok. Először megparticionálod a céllemezt, akkora partíciókkal, amekkorákat akarsz rá. Aztán a sudo dd if=/dev/akármi[partíciószám] of=/dev/másikeszköz[partíciószám] bs=32M status=progress paranccsal átklónozod őket egyenként.
A végén még szükséges, hogy az átklónozott partíción a fájlrendszert a sudo resize2fs /dev/cél[partíciószám] segítségével, hogy ténylegesen is kitöltse a rendelkezésére álló nagyobb partíciót.
Ha bootmeghatjó, akkor még szükség lehet a bootloaderben a kernelparamétereknél a root partíció PARTUUID-jének átírására, illetve a /etc/fstab-ban is az UUID-ket átírni, mert azok ezzel a módszerrel változhatnak.
Egyébként szerinte a clonezillának sem lehet baja a GPT-UEFI-vel. Semmiben nem bonyolultabb, mint az MBR Legacy Boot. Annyi, hogy át kell klónozz egy FAT32 partíciót. Igazából az UEFI boot nem hogy bonyolultabb, de egyszerűbb, ha megérted hogyan működik.
Egyébként dd helyett működne a fájl szintű átmásolás is, rsync-kel vagy tar-ral, de az bonyásabb, bár annyi előnye lenne, hogy a nem használt szektorokat nem másolja át feleslegesen.
-
-
Frawly
veterán
válasz
attilav2
#7946
üzenetére
A Chromium mindenen lassan fordul, ilyen 12-64 magos procikon is simán 20-60 perc, most akkor arányosíthatod. 1 giga felett van a kódbázisa, ez szépen mutatja, hogy mekkora bloathegy, én néha azon csodálkozok, hogy csak pár giga memória kell neki, és nem pár tizen giga.
Az az X4 még ma se olyan rossz gép, főleg ha a 8 giga RAM meg egy SSD alatta van, akkor ilyen átlag felhasználásra, linuxozásra, böngészésre simán elmegy. Modern utasításkészletek is benne vannak, meg ha van benne egy elfogadhatóbb Videó Károly, akár még játékokra és nagy felbontású médiakódekek nézésére is alkalmas.
De ez nem az AMD érdeme, hanem az Intel bűne, meg hogy a szilikonos technológia a végéhez közeledik, és lelassult a fejlődés, főleg, amíg az Intel 2-4 maggal meg tikk-takk-ozással lassította, míg fölényben volt. Egy 10 éves Core i proci is teljesen jó még, ha 4 mag van benne, nem hogy egy 5 éves AMD.
Nagy kódfordításkor azért látszik ezeken a régebbi procikon a kevés cache, meg a 4 mag limitje, kisebb IPC, nyilván ha erre akarja valaki használni, akkor vegyen modern procit, de az már nem átlag felhasználás. Arra Ryzent kell venni.
-
Shyciii
veterán
válasz
attilav2
#7946
üzenetére
Pont ezért jó még neked. Március elejei Chromium verziónál van már ez a probléma (89-es verzió), régebbiek működnek, csakhát Chromiumnál (is) különösen fontos a frissítés a biztonsági lyukak miatt.
"But all version of Chromium will be affected from March 15, even on older builds where the API keys are still present."
-
Shyciii
veterán
válasz
attilav2
#7943
üzenetére
Brave-el az a bajom, hogy az sem a Chrome account alá szinkronizál vissza. Ennyi erővel használhatnám tovább a Chromiumot, és ha valamiért linux reinstall lesz, akkor a profilt visszatöltöm és megmaradnak az újonnan létrehozott chromium alatt. Viszont nekem pont szükség van a gougle account alá szinkronizáláshoz, mert időnként kell, hogy más gép elé mikor leülök, akkor gyorsan megkapjam a könyvjelzőimet (aztán persze annak végeztével törlöm a lokális profilt). Amúgy a Brave-t androidon használom már nagyon régóta (akkor még fejükben se született meg, hogy desktop felé nyissanak). Bár androidon már eldurvult a Brave, mert csak a user data 600MB felett van...régen még ez is egész light volt.
Akkor egyelőre marad az aur-os google chrome, de azért ez az eset a google-tól a b.zd meg kategória. -
Frawly
veterán
válasz
attilav2
#7937
üzenetére
Olyat nem nagyon tudok, aminek a Konsole-hoz hasonló menüje lenne és úgy kezelné a vágólapot. Talán a gnome-terminal, de az is ugyanolyan bloat, és nem biztosan tudja.
sati a vágólapproblémákat clipman-nal oldotta meg. Mindig ígértem, hogy én is kipróbálom, de sose jutok oda, általában nem veszem elő azt a gépet, amin a Sway van.
-
Frawly
veterán
válasz
attilav2
#7934
üzenetére
Jól néz ki ez a bar a tetején, swaybar? Konfigját betennéd? Látom a billentyűzet nevét megoldottad *-os helyettesítéssel, azt is lehet.
Amúgy ja. Wayland előnye, hogy soványabb, mint az X.org, pattogósabb, kevesebb lag, főleg vad görgetésnél látszik, meg a böngészők is pattogósabbnak tűnnek, még XWayland emulációval is, nem hogy tényleges Wayland módban.
Fogyasztásban is bármire köröket ver szinte, még a minimalistább X-es WM-ekre is. Egyedül a Konsole-t nem párosítanám hozzá, mert bár nem rossz terminál, de elég bloat, bár azért nem a legvészesebb. A memóriafogyasztás nem is azért fontos, mert nem lenne az embernek elég memóriája, nekem pl. 16 giga van minden gépben, hanem kevesebb dolgot kell a memóriába betöltenie, a procinak kevesebb dolgot kell végrehajtania, és ez meg is látszik betöltési időkön. Egy komplett KDE 5 Plasma betöltése SSD-n is vagy 5-9 mp., egy Sway 0,05 mp. alatt a képernyőre vágódik. Ennyi, ezen nem sok mindent lehet ragozni, ez a pattogósság függőséget okoz, a hibernációt/sleepet is szükségtelenné teszi. Még gyorsabb lehet, ha az egerészős grafikus alkalmazásaid szinte mindegyikét lecserélted terminálos CLI/TUI alkalmazásra, meg billentyűzetorientált irányításra, de ez hosszabb megszokási-átalakulási folyamat része, lehet hónapok-évek kérdése is, nem nagyon lehet siettetni. Az összes alkalmazást nem lehet terminálossal kiváltani, mert a használható böngészők mind bloatok és GUI-sak, ezt pl. nem lehet megkerülni, meg ha kell Wine, Steam, hasonlók, azok is szükségszerűen bloatok. A másik előnye a tisztán minimalista rendszernek, hogy gyorsabban is frissül, mivel kisebb csomagokból áll, azoknak kevesebb függősége is van, így a frissítési idő is rövidebb, mivel csak fele annyi csomag van a rendszeren, negyed annyi méretben, és egy-egy frissítésnél kevesebb dolog is törhet el, mivel nincs nagyon függőség. Persze ezt majd akkor tapasztalod meg, ha egyszer KDE nélkül teszed fel.
Egyelőre én X-en vagyok megint (dwm, néha IceWM, kezdem konfigurálni a bspwm-et), de csak kísérletezés miatt, a Sway-jel jobban meg voltam elégedve, hiányzik, ha nem találok jobbat, vissza fogok rá én is váltani, mert amúgy nagyon jó. A régi gépen még Sway fut, de azt nem nagyon veszem elő, csak ha valami adatot akarok előásni róla. Csak azért kísérletezek most X-szel, mert az konzervatív disztrókkal (pl. Gentoo, Slackware, Debian) és BSD-kel kompatibilisebb, meg hátha felfedezek rajta egy Swaynél is minimalistább, de használható megoldást, nyilván ezen a vonalon is meg kell próbálni fejlődni, legfeljebb nem hoz eredményt. Ha egész életemben Swayen maradok, akkor megrekedhetek fejlődésügyileg, amit nem akarok, azért próbálok ki más dolgokat is. A Sway megvár, konfigja el van mentve, bármikor visszaállhatok rá.
-
Frawly
veterán
válasz
attilav2
#7930
üzenetére
A sima terminálos indítás nem mindig elég, főleg nem elég csak közvetlenül induláskor nézni, hanem tartósan kell használni terminálból indultan, lehet ezt a hiányzó .so modult csak akkor írja, ha MPEG-TS alapú cuccot próbálsz megnyitni, anélkül nem. Ez az .so hiány mindig kibukik terminálból, játékoknál is így szoktam kinyomozni a hiányzó so-kat. Elvileg szakszerűen az ld /alkalmazás/elérési/útja/alkalmazásnév való, az kiírja, hogy milyen dinamikus függőségek lehetnek, ezt is lehet használni.
Nálam a Swaynak nem volt baja az XWaylanddel, minden normálisan futott, nem crashelt. Arra figyelj, hogy Swayből lehetőleg ne kézzel barmoltat tegyél fel, hanem az Arch hivatalos tárolójából a stabil Sway release-t. A git-es dev ágnak lehetne bugjai.
-
Frawly
veterán
válasz
attilav2
#7930
üzenetére
Sway-en így kell a billentyűzetet belőni a ~/.config/sway/config fájlban:
input "1:1:AT_Translated_Set_2_keyboard" {
xkb_layout hu,us
xkb_options grp_led:caps,grp:alt_space_toggle,caps:escape
repeat_delay 280
repeat_rate 50
}Ez csak egy példa. Nálad az input neve más lesz, a swaymsg -t get_inputs parancs kilistázza.
Az én példámban ThinkPad X220 billentyűzeten állít be elsődleges szabvány, 104 gombos ISO magyar és másodlagos 104 gombos ANSI amerikai kiosztást, közötük bal Alt+Space-re váltva, másodlagos kiosztásnál a Caps Lock ledje ég. A Caps Lock le van cserélve Escape-re, ez a vim-módokhoz kell az egyes alkalmazásokban. Plusz az utolsó két sorban felvettem a billentyűzet érzékenységét és ismétlési sebességét.
De ha neked nem kellenek ennyire extra feature-ök, akkor a magyar kiosztás egyszerűbben belőhető:
input "möhöhő-input-név" {
xkb_layout hu
}Ezzel csak szabvány, 104 billentyűs ISO magyar kiosztásod lesz, semmilyen extra nem lesz bekapcsolva, nem lesz másodlagos kiosztás, meg semmilyen más bonyolítás. Egy Sway-újraindítást igényel. Az input nevet nem lehet sose kitalálni, mert fizikai hardverfüggő, minden gépen, és gyártónál más. De hasonló módszerrel kell konfigolni az egeret, tapipadot, trackpointot, ezek érzékenységét, extra feature-eit, pl. több ujjas gesztus, kattintáskombók, görgetés, stb..
A bemenu okés, még nem próbáltam, de sokan dicsérik. A dmenu-nek néha lehet bugja Wayland alatt, pl. nem akar eltűnni, beragad a képernyő tetején, igaz ez ritka. De a Rofi-nak is van waylandes klónja. Redshitf-nek is, meg egy csomó másik mindennek. Wayland alatt is minden megoldható, csak eltérő toolokat igényel, mert az általánosan ismert X-es toolok nem működnek, mivel nem véletlen van a nevükben az x, az X serverhez lettek kitalálva, a Wayland meg ne X, hanem egy egész másik protokoll.
-
Frawly
veterán
válasz
attilav2
#7927
üzenetére
Bizony, bizony. Ha megnézed az Arch tárólójának a csomaginfóját a vlc csomagról (kattints a show more-ra), akkor látod, hogy az aribb24 opcionális függőség, sőt, ha tovább olvasod, van aribb25 is, amire lehet később szintén szükséged lehet.
Ne feledd, hogy ez Arch. Nem Ubuntu meg Snap/Flatpakk, ahol a VLC gigás csomagban érkezik, és minden függőség hozzá van csomagolva, hogy egységsugarú usernek is hülyebiztos legyen. Ez egy minimalista disztró, itt tényleg csak azt emeli be függőségnek a pacman, ami annyira kell a futásához, hogy épp csak elinduljon üresben, külön médiafájl megnyitása nélkül. Ha extrák kellenek, azt neked kell kinyomozni, meg kézzel feltenni, és tudni mire van szükséged. Ez a magam építem a rendszerem, csak az van fent, amire tényleg szükségem van mentalitás különbözteti meg az Arch/Gentoo usert az ubuntusoktól.
-
Frawly
veterán
válasz
attilav2
#7924
üzenetére
Ezek szerint hiányzó függőség volt. De ezeket cvlc nélkül is ki kellett volna írnia, ha terminálból indítod a VLC-t. Ez egy általunk gyakran javasolt trükk, hogy a GUI-s progikat is indítsuk terminálból, ott a hibakimenetben sok minden látszani fog, ami grafikus felületen rejtve marad.
Amit még tudsz ilyenkor, hogy újratelepíted a VLC-t az Arch tárolójából. Ez önmagában nem fogja a függőséghiányt megoldani, de ha szintén terminálban vagy konzolban csinálod, akkor a telepítés végén ki fogja listáznia pacman az ún. opcionális függőségeket, amik nem kötelezőek, nem default függőségek, csak 1-2 extra feature-höz kellenek, és nagyon valószínű, hogy meg fogod találni ott, hogy mi hiányzik neki, ami [not installed] státuszú, de neked kellhet.
Ezért szoktam papolni, hogy terminál, terminál, terminál, meg miért jobbak a minimalista, terminálos, CLI/TUI progik. Ezért. Mert egyszerűbbek, jobban debugolhatóak, látszik mi mit ír ki, nem kell külön loggal kínlódni, meg a GUI felületen elrejtéssel harcolni. Mert fasza a GUI, kényelmesnek tűnik, szépen témázható, szép nagy ikonok, csak épp rettenet nem hatékony, meg rettenetesen korlátoz, ha átlépsz egy szinten. Ez senkinek nem tűnik fel, mert az emberek már 30+ éve megszokták, hogy csak grafikus felület, csak grafikus felület, csak GUI, és már el sem bírják képzelni, hogy lehet máshogy is, sőt, nem csak lehet, hanem legtöbbször az lenne a hatékonyabb.
-
attilav2
őstag
válasz
attilav2
#7925
üzenetére
aribb24 - ez a csomag lesz a hunyó szerintem, most letöröltem és egyből nem tudta megnyitni a vlc a dvb-t streamet, miután visszaraktam ezt a csomagot a vlc meg tudta nyitni a dvb-t streamet.
A csomag leírása:
Library for ARIB STD-B24, decoding JIS 8 bit characters and parsing MPEG-TS stream -
Archttila
veterán
válasz
attilav2
#7919
üzenetére
Ezek vannak a chromium-flags.conf-ba:
--no-xshm--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#--force-dark-mode--enable-features=WebUIDarkModechrome://gpu alatt
Window manager wlroots wmAz első bejegyzés workaround egy crash-elős bugra
(állítólag x86-on nem jelentkezik)Egyetértek Frawly-val, miszerint általánosságba kijelenthető, hogy az RPI nem desktop-nak való DE! nekem akkor is az a tapasztalatom, hogy egy overclocked 4GB-os PI4-en SSD-vel, pálcika WM--el és lightweight alkalmazásokkal meglepően jól teljesít az Arch. (32 bit)
Írom ezt úgy, hogy az első Arch install-om egy Ryzen 3900-en történt
nyilván más liga, de ha azt mondom, hogy ezt így a fent leírt formában napi szinten lehet használni akkor azt hidd el nem viccből írom
Csak, hogy éreztessem a különbséget: a (csak) 32bites Arch Sway kombó 1000x fluidabb élmény nyújt a PI-n, mint egy 64 bites Manjaro Xfce edition. Pedig elvileg az egy lightos kis DE-nek számít a piacon, szóval gondolhatod... -
Frawly
veterán
válasz
attilav2
#7915
üzenetére
Xwaylandet ne tiltsd le, mert elég sok program van, amiből nincs waylandes alternatíva. Legyen fent az Xwayland, ha a progik épp nem használják, nem fogyaszt. KDE-vel össze sem lehet hasonlítani, mintha a Win10-et meg az MS-DOS-t hasonlítanád össze ilyen tekintetben, más dimenzió.
A Sway-nek, mint tiling WM-nek akkor van értelme, ha:
1) főként terminálos programokat használsz. Ezen a ponton kapásból kiestél ilyen Deadbeef (jó, ez még annyira nem), Clementine, LibreOffice, VLC, stb. igényekkel, ráadásul ezek önmagukban bloatok, ezek foglalnak 2+ gigát, nem a Sway. Épp ezt szoktuk mondani ubyegonnal, hogy ha valaki bloat rendszert használ, akkor pálcika WM-nek nincs értelme, mivel nem az fogja enni a sok memóriát, hanem a böngésző, bloat GUI-s megoldások, és a pálcika WM és a full DE-k között a memóriafoglalás kiegyenlítődik sok ilyen programnál.
2) billentyűzetorintált workflow-t akarsz (mint írtad, neked ez is gond)A Sway egy i3wm-klón, tehát tekintsd úgy, hogy i3wm-et használsz, de közben a jövő technológiáját teszteled (Wayland). Nyilván a Wayland-ökoszisztéma más, nem működnek a szokásos X-es toolok, pl. xrandr, redshift, scrot, feh/nitrogen, setxkbmap, Rofi, X screenrecorder, stb., helyette ezekből waylandes változat kell.
Firefoxot nem ajánlom Wayland módban, ez a része csak kísérleti, és bugos. SBC is felejtős, mikrokontrollernek, mikroszervernek valók, nem desktopnak, swayezni, KDE-zni. Főleg ahhoz kevesek, amit te akarsz, hogy háttérben ilyen 2-8 giga bloat fut, VLC, LibreOffice, böngésző 10 tabbal, Clementine, stb.. Erre rendes desktop gépet kell venni, min. 4 magos proci, min. 8 giga RAM, modern GPU, ami modern kódekeket tud kódolni hardveresen, stb.. Futni futnak ezek SBC-n is, de baromi lassú, élvezhetetlen, körülményes lesz, nem fog jó felhasználói élményt adni.
A másik csapdája ezeknek az SBC-knek, a komolytalan teljesítményt leszámítva is, hogy drágák. Az ne tévesszen meg, hogy maga az SBC csak pár dollár, de kell hozzá SD-kártya vagy SSD, hűtő, ház, kábelek, USB-s töltő, kijelző, billentyűzet, tököm tudja mi, és amikor ezt a sok apróságot összeadod, könnyen kijön, hogy egy használt Core i laptop vagy szubnoti lényegesen olcsóbbra kijön, minden bele van integrálva, teljesítménye is nagyobb, natívan futtatja az x86-os kódokat, áramból és helyből nem kér sokkal többet.
Persze lehet venni SBC-t, hobbista kisérletezésre jók, csak arra kell figyelni, hogy ne költs rá túl sokat.
-
Frawly
veterán
válasz
attilav2
#7857
üzenetére
Igen, pont ez a baj ezekkel a rendszerekkel, hogy kulcsra készek, és ha neked másfajta kulcsra készség kell, akkor szedhetsz le egy csomó mindent, meg rakhatsz fel, és nem lettél sokkal előrébb a normál, kézi Arch telepítéshez képest.
Igazából az Archot nem nehéz feltenni, ezt a többieknek írom, nem neked. Tényleg csak pár kulcs parancs, a többi, amit az Arch Wiki ír, az alternatív módon is megoldható, pl. particionálásra akármilyen program, rendszer használható, még Archnak sem kell lennie. Meg az Arch Wikiben egy csomó lépés opcionális, pl. hardveres óra állítása, ez nekem sok év alatt csak egy szem gépen kellett (és ez sem fog kelleni újratelepítéskor). Szóval egy csomó lépés át is ugorható, kiváltképp, ha mondjuk Arch reinstall van, mert akkor újraparticionálni nem kell, bootmegoldást ha okos az ember, nem kell újratelepíteni (kivéve GRUB, de azért írom, hogy okos), fstab-ot újra lehet hasznosítani, stb-stb., így még jobban leegyszerűsödik.
Persze annyira ezeknek a third party Arch installereknek sem vagyok ellene, mert ugyan így az Archnak az egyik lényege veszik oda, de mégis inkább ez, mint hogy a jóember Ubuntut meg többi szemetet tegyen fel, ezek legalább tényleg Arch alapúak, Arch tárolóból dolgoznak, elérhető az AUR, stb-stb..
-
Frawly
veterán
válasz
attilav2
#7823
üzenetére
Listázhatnám, de nincs sok értelme, én kevés fontot telepítek, azokat is kézzel, Ubuntu font family, Fantasque Sans Mono terminálban, DejaVu fontcsomag mindenféléhez (Thunderbird, Firefox, stb.), meg most talán valami Nerd font van fent, ami működni sem akar dwm alatt. Nincs nagyon más fent, mivel én nem telepítek asztali környezetet, csak WM-et, meg mindenből terminálos programot használok GUI-s helyett.
Egyébként meg az sem baj, ha túl sok font van telepítve, mert azok nem kérnek memóriát, meg nem töltődnek be, ha nem használja őket semmi, és sok lemezterület se kell nekik. Egy kényelmetlenség van, ha túl sok font van fent, hogy azok néha frissülnek is, ami sávszélt viszi, meg ha esetleg gyakori fontcache-generálás van, azt egy töredékmásodperccel lassítják, de ennyi.
-
Frawly
veterán
válasz
attilav2
#7815
üzenetére
Fel lehet épp gányolni, mert elég kimásolni a .deb alóli tar.gz-ből a bin mappát, az portable módban akár a user mappájából is lehet futtatni. De nem érdemes, mert így nem frissül, meg a libekkel való verziókompatibilitása sem lesz biztosított. Inkább az AUR-ból kell megoldani, ha egy mód van rá. Ha kisebb progi (a Chrome, Chromium nem ilyen), akkor akár forráskódból is lehet kézzel forgatni, az is jobb, mint az ubuntus csomag telepítése.
-
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.
-
Shyciii
veterán
-
Frawly
veterán
válasz
attilav2
#6780
üzenetére
Ennél kicsit több konkrétum kéne, hogy fagyott állapotba kerül. Melyik fázisban fagy meg? Még mielőtt lehúzná az AUR script a binárist, vagy azután, mikor tar.zst csomaggá tömöríti, vagy mikor pacmannal rakja fel? Sőt, még jobb lenne, ha komplett kimenetet tennél be, hogy lássul hol akad meg.
A Chromecast-hez nem értek, de a Chromiumban egy csomó minden nincs benne, ami Chrome-ban benne van. Akármi hiányozhat neki.
(#6779) Shyciii: a szöveges böngészőre jól emlékszel, az a Lynx, de forkjai futnak links, elinks, stb. néven is. Abban találták ki, hogy a linkek között navigálsz kurzorbillentyűkkel, de nem csak fel-le, hanem domainek és előzmények között is. Ezt a navigálási módszert viszont átvették egy csomó más programban, közöttük az mc is támogatja, csak alapból nincs bekapcsolva. Gondolom az egyszeri userek miatt nincs engedélyezve alapból, mert ész nélkül nyomkodnak mindent, nincs önfegyelmük, és nehogy az legyen, hogy valami adatot azért vesztettek, mert rosszat nyomtak.
Ebben különbözik a vi/vim, hogy annak pont az a filozófiája, hogy
1) modális, azaz módok között váltasz, a különböző módokat lehet beragadó Ctrl-nek vagy Alt-nak is felfogni, amit nem kell nyomva tartani, de mégis átértelmeződnek különböző módban ugyanazok a billentyűk
2) mindent gépírástartásban végzel az alfanumerikus részen, nem nyúlsz ki más billentyűkhöz, se kurzormozgató nyilakhoz, se Home, End, Pg Up/Dn, stb., mert akkor ki kéne lépni gépírástartásból, meg egérért sem nyúlsz ki, se funkcióbillentyűkért, se semmiért.Az, hogy eltávolításkor a pacman meghagyja a Lightdm maradványait, az nem a Linux, és nem a Lightdm hibája, hanem az Arch csomagfentartójáé, aki a Lightdm-et csomagolja és frissíti. Ő felejti el a post install/uninstall scriptbe beletenni a szutykok eltávolítását. Ha annyira zavar, akkor az Arch oldalán a Packages részben rákeresel a Lightdm csomagra, ott ha belemész, a linken írni fogja, hogy ki a csomagfenntartó, és lesz hozzá e-mail elérhetőség. Vagy az Arch oldalán a Bugs szekcióban jelented, vagy az Arch fórumán.
-
attilav2
őstag
válasz
attilav2
#6780
üzenetére
A pikaur man oldala meg is említi a notable features résznél amit szeretek benne:
interactively handle common build problems (like untrusted GPG key or checksum mismatch, wrong architecture)Míg a trizen-nél csak a --skipinteg kapcsoló áll rendelkezésre, nem kezeli interaktívan a leggyakoribb build problémákat.
BoB: Javaslom a yay-t próbáld meg, valószínű kiváltja mind2-t.
Ránézek -
Frawly
veterán
válasz
attilav2
#6373
üzenetére
Szerintem amdgpu driverrel előre lefordítja és betölti a shadereket. amdgpu pro drivernél meg úgy van beállítva, hogy játék közben töltögeti őket.
(#6370) Shyciii: hidd el, ez személet kérdése. Ahogy anno láttad, hogy egy openboxos linux rendszer mennyivel egyszerűbb és pattogósabb egy KDE-hez képest, úgy mindenben lehet egyre minimalistább megoldást találni. Valahol szokni is kell folyamatosan, nem lehet azonnal az ultraminimalizmusba belemenni, mert az elsőre használhatatlan lesz. Mindig csak annyiban kell minimalizmusra törekedni, amennyiben még számodra használható a rendszer, ez majd változik idővel, ahogy fejlődsz minimalizmus terén.
Nálam pl. a jmtpfs nem foglal semmi memóriát, mert alapból nem fut. A 0 megás memóriafoglalással semmilyen más megoldás nem tud versenyezni, akkor sem, ha csak 1 bájtot foglal. Annyi, hogy a telefon nem csatlakozik automatikusan, de ez nem baj, mert a csatlakozás megtörténik, amikor Vifm-ben rámennék a teló mappájára, ahová fel szokott lenni csatolva. Eleve úgyse lesz teljesen kényelmes egy androidos teló csatolása MTP-n, mivel biztonság miatt neked kell a telót felébreszteni, bekapcsolni kézzel rajta az MTP-t, és még utána hiába is csatolja automatikusan a gvfs-mtp, még fájlkezelőben úgyis át kell váltsál rá, ha másolni akarsz rá valamit.
A régi andoridos telók, 4-es verzióig bezárólag még annyiból voltak kényelmesek, hogy volt rajtuk USB Mass Storage funkció, ott tényleg elég volt, hogy gépre dugtad a telót, semmilyen képernyőzárat, meg semmit nem kellett oldogatni hozzá, se MTP-t minden egyes alkalommal bekapcsolgatni, és azonnal fel is csatolódott. De MTP-vel sose lesz már ilyen kényelmes, biztonságilag úgy van tervezve az Android, hogy csak kényelmetlenül tudjál MTP-vel kapcsolódni, nehogy valaki a hátad mögött csatlakozzon hozzá így, és tudtod nélkül matasson valahogy a telódon az adataid között.
Egyébként azt a gvfs-mtp-t nézd meg még egyszer, mert nem csak 36 MB, fut mellette a gvfs is, meg még annak pár másik modulja, adj csak szépen össze mindent. Van az majdnem 100 mega, hidd el. Meg nem is ezzel van baj, hanem egy full extrás Linux DE-nek minden része ilyen, egy ki 100 mega itt, egy is 50 mega amott, és szép apránként a végére kijön, hogy +500-1000 mega. Ha pedig elérsz egy fejlődési szintet, rájössz, hogy ennek 90+ %-a felesleges is, mert léteznek rá CLI/scriptes megoldások, amit billetnyűkre tudsz drótozni, meg automatizálni, és nem kell minden szarnak futnia a háttérben. Pont ez a baja a systemtrének is, nem csak egy init-rendszer már, hanem egy komplett mini OS, futtat egy rakat szolgáltatást.
Hidd el, 16 GB RAM-ból nem fáj nekem sem, hogy most van 500 mega itt, 1000 mega amott, általában 8-10 giga üresen áll, a kernel cache-nek használja. Hanem a sok memóriafoglalás azt jelenti, hogy sok minden fut, ami a gép reszponzivitását tudja csökkenteni. És ha még úgy is érzed, hogy nálad most minden reszponzív, meglepődnél, hogy minden mennyivel pattogósabb egy minimalista rendszeren, aki nem szokott még hozzá, nem hisz a szemének.
Abban viszont egyetértek, hogy az FTP szerver sokszor elegánsabb megoldás, mivel nem ütközik adott esetben az USB2 korlátjába sem, meg nem kell vezetékkel csatlakoztatni a telefont.
-
Frawly
veterán
válasz
attilav2
#6367
üzenetére
Nincs zavar, olyan mirror-t használsz, amiben nem frissült le az összes csomag még. Próbálj másik mirror-ra váltani, ott van az archlinux.org-on a mirrorlist generator, meg a mirrorkereső. Ha be van állítva az új mirror, akkor benyomatsz neki egy sudo pacman -Syyu parancsot.
Vagy a clementine csomag fenntartója nem húzta be függőségnek az újabb protbuf verziót. Néha hibáznak a csomagfenntartók is.
-
Frawly
veterán
válasz
attilav2
#6358
üzenetére
Az amdgpu-pro drivert nem éri meg feltenni. Szimpla felhasználónak, meg játékokhoz semmi extra előnyt nem fog nyújtani, semmi nem fog gyorsabban vagy hibamentesebben futni. Cégeknek csinálják a pro drivert, főleg OpenCL támogatás van benne GPU-s számításokhoz. Tényleg csak szivatod magad, ha erőlteted. Az RX550 helyett lehet jobban megérte volna rámenni egy RX570-re, használtan piszok olcsók. Bár ha nem cél az 1080p High settings minden játéknál, akkor ilyen Medium grafikára meg 720p-re teljesen jó az RX550 is.
-
Frawly
veterán
válasz
attilav2
#6341
üzenetére
Sok waylandes cucc nem fut virtuális gépen, főleg nem Virtualbox alatt. Ezt figyelembe kell venni. Egyébként soha nem volt gondom Waylanden a Qt-s, meg a KDE-s alkalmazásokkal. Archon volt utoljára nekem a KDE5 még fél-egy éve irdatlan bugos, de az sem Wayland-bug volt, X.org-ra kapcsolva is ugyanolyan hulladék volt.
-
#63718632
törölt tag
válasz
attilav2
#6291
üzenetére
Nekem nincs bajom a konzollal, terminállal. Cimbimet nem érdekli ez része a témának. Neki megfelel így, nem telepít semmit, csak frissít. Hozzám jön, ha gubanc van. Rutinból lövi a screenshotot és küldi nekem. A múltkori pacman gubancon kívűl az én botlásaim miatt kellett piszkálni a rendszerét.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
) barátunk is megmondta.
1,92 liter, 8/16 CPU, bivaly APU 
![[kép]](https://clonezilla.org/clonezilla-live/doc/03_Disk_to_disk_clone/images/ocs-08-3-command-to-run.png "[kép]")
Új hozzászólás Aktív témák
Hirdetés
BoB
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Gyermek PC játékok
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- AKCIÓ! ASUS MAXIMUS VIII HERO Z170 chipset alaplap garanciával hibátlan működéssel
- LG 48C4 - 48" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - A9 Gen7 CPU
- BESZÁMÍTÁS! Gigabyte H610M i5 13400F 16GB DDR4 512GB SSD RX 6700XT 12GB DeepCool MATREXX 40 650W
- BESZÁMÍTÁS! MSI B450M R5 5500 16GB DDR4 512GB SSD GTX 1080Ti 11GB Rampage SHIVA Chieftec 700W
- Canon imagePrograf PRO-6100S plotter - szinte új, 500m2 nyomat
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged