- Profi EKG-s óra lett a Watch Fitből
- Samsung Galaxy S22 és S22+ - a kis vagány meg a bátyja
- Kiborult a Nothing Phone (3) pletykakosara
- Xiaomi 15 - kicsi telefon nagy energiával
- Samsung Galaxy A54 - türelemjáték
- Magisk
- Xiaomi 14T Pro - teljes a család?
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Honor 200 Pro - mobilportré
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
-
Mobilarena
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
Frawly
veterán
Még egy gondolat. Kelleni nem kell semmit. Nem kell SSD-t titkosítani. HDD-t sem. Nem tart senki pisztolyt a bordáid közé. Te tudod, hogy neked milyen szintű biztonság kell, mire van szükséged, annak megfelelően döntsd el, hogy milyen részek legyenek titkosítva, és milyen titkosítási módszerrel (hardveres jelszó, szoftveres LUKS, stb.).
A titkosítás ilyen, kényelmetlenséggel jár. Persze feláldozhatod a kényelmet a biztonság oltárán, akkor a biztonságossági faktor csökken. Mindenkinek máshol van a két szélsőség között az arany középút.
Én régen minden HDD-men LVM-over-LUKS-ot használtam a rendszerlemezen, és LUKS partíciót az adatlemezeken. Aztán a rendszerlemezeim SSD-k lettek, azokon hardveres titkosítást használok (SATA SSD-ken ATA jelszót). Viszont 1-2 külső HDD-n természetesen megmaradt a LUKS. Teljesen megszoktam. Bootkor 1-2 mp. begépelni a jelszót. Plusz ha külső HDD-t csatlakoztatok nagy ritkán, akkor be kell írni még egyet. Nem halok bele. Már vagy 4 éve minden meghajtóm titkosítom. Kivételek ugyan vannak most, OS installálós, pendrive-nak használt SSD-ken nincs jelszó, de azokon érdemi adat sincs, meg egy mSATA SSD-n, amin csak Windows meg némi játék van, azon sincs titkosítás. Ennek az az oka, hogy ezek az SSD-k nem támogatják a hardveres titkosítást, a szoftvereset meg nem erőltetem rájuk, főleg, hogy nincs rajtuk semmilyen olyan egyéni adat, amit védeni kéne.
Plusz az SSD-k nem szeretik a szoftveres titkosítást. Ennek az az oka, hogy szoftveres titkosításkor az egész meghajtó telinek látszik, tele van pszeudórandom adattal. Persze a fájlrendszeren lehet szabad hely, de alacsony szinten az SSD vezérlője úgy látja, hogy tele van a meghajtó, és ezért nem tudja rajta az adatokat a cellák egyenletes fárasztása miatt pakolgatni. Vagyis van rá lehetőség, ha átengeded a titkosítási rétegen a TRIM-et, NVMe-nél még elvileg ez sem kell, mert ott a trimezést egy kombinált írási-törlési utasítás végzi. De az SSD-k akkor sem nagy barátai a szoftveres titkosításnak, sok azért is van felszerelve a hardveres titkosítási lehetőséggel, igaz ahhoz az alaplapnak is kell támogatnia, már pedig asztali lapok nem nagyon szokták, inkább laptopok, azok közül is inkább csak az üzleti kategória. Az SSD-k mindenképp más műfaj titkosításügyileg, mindenképp van velük szopófaktor valahol. HDD-t viszont mindenképp megéri titkosítani.
-
Frawly
veterán
Nem egészen értem mit akarsz, mintha kevernéd a dolgokat. A felhasználó jelszava nem egyenlő a titkosított partíció jelszavával. Mind a kettőt be kell írnod egy ponton (már ha nem csinálsz automatikus bejelentkezést, de az megint nem biztonságos). Kétszer viszont nem kell egyiket sem. HDD-nél választhatsz, hogy automatikusan csatolódjon bootkor, ilyenkor a bootkor kell beírnod a HDD jelszavát, vagy utólag csatolod fel filemanagerből vagy gvfs-ből, akkor bejelentkezés után kell beírni.
Esetleg lehet úgy, hogy jelszóbeírás helyett valami pendrive-ról kulcsfájlt használni, de az kevésbé biztonságos, mert ha valaki megszerzi a drive-ot, akkor hozzáfér az adatokhoz. A jelszó csak a fejedben van meg (ideális esetben), így azt senki nem tudja megkaparintani. Viszont kényelmetlen, hogy mindig be kell gépelni, de a kényelem és a biztonság mindig is ellentétes fogalmak.
De mondom, ha olyan az SSD, tudhat hardveres titkosítást is, azt BIOS-ban kell beállítani (vagy lehet linuxos hdparm-mal is, de nem ajánlom neked, ha nem vagy tisztában dolgokkal, mert hdparm-mal haza lehet vágni az SSD-t, meg ki lehet zárni magad belőle végleg). A hardveres SSD titkosításnak ez az egyik hátránya, ha elfelejted a jelszót, reszeltek az egész SSD-nek, többet nem tudod használni, nem csak az adatokat bukod. Szoftveres titkosításnál ha el is felejted a jelszót, akkor csak az adatokat bukod, magát a meghajtót bármikor újra tudod particionálni, a partíciókat újra titkosítani, stb..
-
Frawly
veterán
Igen, hozzáférsz a titkosított kötetekhez, akkor is, ha a felhasználói, rendszergazdai jelszót megváltoztatod, ergo nem úszod meg az SSD titkosítását, ha az azon való adatokat hozzáférhetetlenné akarod tenni.
Az érdekes, amit írsz, hogy PCIe SSD-n a nagyobb sebesség miatt a procinak jobban kell nyomni a hash sebességet, és emiatt jobban leszívja az erőforrásokat. Ez igaz is lehet. Én csak SATA meghajtókon használtam eddig, ott lassulást, gyorsabb merülést nem lehetett mérni.
Esetleg ha céges üzleti noti, akkor az SSD oldalán lehet bekapcsolni a hardveres titkosítást, annak semmi köze a szoftveres szinthez, OS, proci felé transzparens. Viszont NVMe SSD-knél nem tudom mennyire lehetséges, melyik támogatja, mert amúgy ATA-jelszóval kell bekapcsolni, de az NVMe-nek semmi köze az ATA/SATA protokollhoz.
Ha mindenképp szoftveres titkosítást szeretnél, az rendszerköteten bonyolultabb, mivel gondoskodni kell a bootolhatóságról, és SSD-n még az is bonyolító tényező, hogy ha ATA/SATA SSD-ről van szó, akkor a TRIM parancsot is át kell engedni a szoftveres rétegen, NVMe-nél elvileg nem.
Amit írtam, példát paranccsokkal, azt csak nem rendszerlemezek titkosításához írtam, tipikusan HDD-hez.
-
-
Frawly
veterán
válasz
ubyegon2
#64118
üzenetére
Nem gabalyodtam be semmibe. Nem kap, ott írja, ha a root-nak adsz meg jelszót, akkor a többi felhasználónak nem lesz sudo-val rendszergazdai jog. Pedig az lenne a kívánatos, ha alapból lenne ilyenkor is. Sőt, én ezt oda szigorítanám, hogy ilyen telepítőknél nem is engedném, hogy ne legyen a root-nak jelszava, akkora biztonsági kockázat. A Debian meg ezzel a húzással csábít rá.
Abban igazad van, hogy Archon sem az van, aminek lennie kéne, sajnos. De ott könnyebben elnézi az ember, mivel annyira minimalista, hekkelős disztró, eleve nem kezdőknek, ezért ott nem okoz gondot.
-
Frawly
veterán
válasz
ubyegon2
#64114
üzenetére
Értem amit írsz, nem is téged akarlak támadni ezzel, de ez úgy ahogy van, f4xság. Kapásból biztonsági kockázat, ha a root-nak nincs jelszava. Bárki bemászik a rendszeredbe, csak bejelentkezik root-tal és tárulnak is fel előtte a kapuk.
Semmi köze a root jelszónak ahhoz, hogy egy másik felhasználónak milyen jogokat ad a sudo. Igazából a /etc/sudoers dönti el, hogy adott felhasználói csoportnak milyen sudo jogai vannak.
Egyébként rosszul emlékeztem, mert alapból Archon sem ad rendszergazdai jogokat a sudo, szerkeszteni kell hozzá a sudoers-t. De ez attól független, hogy adsz-e meg root jelszót vagy nem. Ezzel sem értek egyet, desktop disztrókon az alapbeállításnak annak kéne lennie, hogy az összes korlátozott user kapjon sudo-val rendszergazdai jogot, és ha valaki annyira le akar korlátozni egy felhasználót, akkor vegye el tőle utólag ezt a jogot.
-
Frawly
veterán
Ja, erre még válaszolok, ha újra nekifutnál. A meghajtónevet az lsblk paranccsal tudod megnézni. Ezt kell a dd-nek is megadni.
Egyébként ha egy ilyen nagyon régi laptopról van szó, akkor lehet nem éri meg a rá fordított idő. 30-50k között vannak refurb üzleti notik (i5-i7, 4-8 GB RAM szintje), amikre normálisan tudsz akár Win10-et, akár Linuxot telepíteni, mindenféle szenvedés nélkül, nem hal meg rajta semmi.
Azt sem értem, hogy milyen infókat írtál ki pendrive-ra. Letöltöd még egyszer a Mint 19 iso-ját, előveszel egy jó pendrive-ot, és kiírod arra egy jó gépről. A pendrive az ilyen, fogyóeszköz, a legtöbb ócska, minél olcsóbb fajta, annál hamarabb tönkremegy. Én azért is használok SSD-ket USB-SATA adapterrel, gyorsabbak és tartósabbak is, mint egy pendrive, és alig drágábbak. A telepítés is gyorsabb róluk.
Nekem egyébként a Rufus is kiírt még mindent sikerrel, igaz rég használtam. Nem értem a Mint 19-et miért ne tudná kiírni. Kiválasztod, hogy dd-s kiírás meg BIOS+MBR bootmode-hoz írja és meg kell tudnia csinálnia. Nincsen nagy trükk sehol. Kiírás előtt esetleg azt érdemes megnézni, hogy a letöltött Mint 19 iso-jának az SHA checksumja megegyezik-e a szerveren jelölttel, azaz a letöltés nem sérült-e.
-
Frawly
veterán
válasz
ubyegon2
#64084
üzenetére
Ezt én nem értem. A Debian miért kever ezzel. Én Archot is úgy használom, hogy van a root, annak van egy jelszava, akkor van az én felhasználóm, annak is van egy jelszava. A sudo mégis ad rendszergazdai jogokat a felhasználómnak.
Archon muszáj is a root-nak jelszót csinálni, különben az alaptelepítés után nem tudsz bejelentkezni, ha jól emlékszem. Bár ki tudja, lehet ki lehet trükközni, hogy más a telepítéskor chroot környezetben létrehozom a felhasználómat, és annak adok jelszót, de nem érné meg ez a hozavona, jó ha a root-nak is van jelszava.
-
Frawly
veterán
A dm-crypt csak a csomag neve. Valami köztes konténerréteg mindenképp kell, LUKS, VeraCrypt vagy hasonló konténerformátum, amibe titkosít. Ebből a LUKS a legajánlottabb.
Fogod a HDD-t, létrehozol rajta egyetlen darab partíciót, ami lefedi az egész HDD-t.
Majd rendszergazdai jogokkal terminált nyitsz (pl. su):
cryptsetup -v luksFormat --type luks2 /dev/sdakrámicsoda1
Ez titkosítja az egész partíciót, default paraméterekkel, ami AES256-XTS SHA256-hash, legalábbis Archon.cryptsetup open /dev/sdakármicsoda1 titkositott
mkfs.ext4 /dev/mapper/titkosítottEnnyi a titkosítás. Ha kézileg akarod felcsatolni, akkor így lehet:
cryptsetup open /dev/sdakármicsoda1 titkositott
mount /dev/mapper/titkositott /kivant/csatolasi/pont/mappajaHa már nem kell az eszköz, akkor:
umount /kivant/csatolasi/pont/mappaja
cryptsetup close titkositottNem muszáj kézileg csatolni, sok fájlkezelő és commander típusú progi meg tudja nyitni az így elállított titkosított partíciókat, bekérik hozzá a jelszót, te csak kattintasz a meghajtóra, kapsz egy ablakot, beírod a jelszót, minden más automatikusan megy, felcsatolódik a partíció, már ha jó jelszót adtál meg. Rossz jelszó esetén vagy újra jelszókérő ablak jelenik meg, vagy hibaüzenet.
Lehet automatizálni is, bootkor. A /etc/crypttab fájlba ez menjen:
titkositott /dev/sdakármicsoda1
(vagy)
titkositott UUID=partíció-uuid-je none luksA jelszó elég erős legyen, min. 20 karakter, minél változatosabb, lehetőleg kisbetű, nagybetű, egyéb írásjel, meg lehet fűszerezni ékezetes betűkkel is. Ezt garantáltan nem töri fel senki, még akkor sem, ha esetleg mégis csatlakoznál a CIA-hez. Se FBI, se NSA, se senki nem tud vele mit kezdeni, nem tudják feltörni. Egyedül a titkosszolgálatok lehetnek kivételek, de azok sem technikailag törik meg, azok téged törnek meg, ütnek addig cipóvá, amíg el nem árulod a jelszót.
Javasolni szokták még a legelső parancs elé, hogy futtass végig az egész HDD-n:
dd if=/dev/urandom of=/dev/akarmicsoda bs=20M
Ez csak azt a célt szolgálná, hogy a HDD-n előzőleg titkosítatlan tartalom lepucolódjon, és így nem látszik a különbség a titkosított és titkosítatlan részek között. Ez ellen van egy gyorsabb módszerem. Létrehozod és titkosítod a partíciót, úgy, ahogy írtam. Mikor kész van, telemásolod mindenféle adattal, amid csak van, felmásolsz rá, hogy elfogyjon a szabad hely rajta. Utána törölhetsz belőle, ami nem kell. Azért szoktam így, mert ez gyorsabb, a /dev/random és /dev/urandom végig dd-zése elcseszettül lassú, főleg ha valami nagyobb HDD-ről van szó, egyszerűen kín kivárni, mire végigszüttyögi, akár még 24 óránál is több lehet. -
Frawly
veterán
-
Frawly
veterán
Ez egy külső bináris, ami magát frissíti? Azaz nem a hivatalos tárolókból telepítetted? Mert ha az előbbi, akkor töltsd le a legfrisebb verziót kézzel, bontsd ki azonos mappába, felülírod a létező fájlokat, és kész a frissítés.
A 19-es Mint iso-ját meg ki tudod írni 18.3 alól a dd paranncs segítségével
sudo dd if=/elérési/út/mint19.iso of=/dev/célmeghajtó bs=4M status=progress -
Frawly
veterán
Egyáltalán nem találom elavultnak. Nagyon szépen leírja a dolgokat. Egyedül az zx (LZMA/LZMA2) formátumra nem tér ki a tar kapcsán. Meg nem értem miért ajánlja a 40 napig használható fizetős Rar telepítését, én azt mellőzném Linuxon. A libunrar, unrar ingyenes, opensource, azzal ki lehet bontani rar állományokat, meg talán 7-zip-pel is. Befelé viszont nem érdemes Rar-ral tömöríteni, MS OS-ekhez készített, zárt forráskódú, fizetős szoftver, ráadásul az opensource 7-zip jobban is tömörít.
Meg azt még megemlíthette volna, hogy a Double Commander is sok mindent ki/be tud csomagolni, archivumokat tesztelni, jelszavazni, az is nagyon kényelmes archívumok kezelésére (is).
De így utánaolvasva is találok tömörítés kapcsán érdekességeket. Pl. a 7-zip-ről azt írja a Wikipedia, hogy nem kezeli a unixos fájlrendszerek metaadatait. Ezt nem is tudtam.
Az arj-t nem értem miért emlegeti, eléggé kihalt formátum. Pedig anno a DOS-os időkben nagyon népszerű volt a Rar megjelenéséig. Meg még emlékszem olyanokra, mint az .ain, .ace, .arc, azok sincsenek már sehol.
Említésre méltó még a nanozip, jobban tömörít, mint a 7-zip, és ingyenes, de sok mindent nem támogat, elég minimalista.
A legjobb a tömörítése a PAQ* változatoknak, de azok nagyon elmebeteg megoldások, némelyik a pár száz megás fájlt 10-20 órán át tömörít be, és elhasznál közben több GB memóriát, és a kicsomagolás is ennyi időbe telik, ugyanekkora memóriafoglalással, de brutálisan tömörít. Ha valakivel ki akartok cseszni, küldtök neki PAQ8PX-szel csomagolt állományt, ami modern izomgépen is 10-20 órát fog kicsomagolódni, éktelen sok giga memóriahasználat mellett, közben meg emberünk a falat fogja kaparni, mert nem tudja mellette másra használni a gépet
Windowson nemrég jött szembe egy bzui .zip fájl, amit semmi nem tudott kibontani, csak a 7-zip. Minden más hibára futott vele, azt írták, hogy hibás archívum.
Ami még újdonság a Google-től a Snappy és a Brotli, de nem nagyon akar terjedni.
-
Frawly
veterán
Szerintem nincs. Nem a Debian sara, már az összes böngésző megszüntette az Adobe NPAPI Flash támogatását, és helyette mindegyik a PPAPI Pepperflasht használja már. Ezért utóbbinak nincs alternatívája más disztrón sem, Windowson sem (Edge, IE böngészőket leszámítva).
Persze külső tárolóból felszögelhetsz Adobe Flasht, de semmi nem fogja tudni használni már.
-
-
Frawly
veterán
Mert a gzip nem tud solid tömörítést: egy fájlként becsomagolni az egészet, ami mindig sokkal hatákonyabb. A rar, 7z pl. tud. Így gzip-nél úgy oldják meg unix/like rendszereken, hogy először a tar benyomja a sok fájlt, és egy megafájlt készít belőle, és ezt tömöríti be a gzip. Ezért van egymásba ágyazva.
Végül is a rar, 7z, stb. is épp így egymásba ágyazza őket, csak nem veszed észre, mert nincs két kiterjesztés, de pl. ha a sok fájlból kibontasz egyet, akkor az előtte lévő fájlokat mind ki kell bontani, akkor is, ha nincs rájuk szükség. Ezzel szemben a tar.gz és tar.xz annyiból rosszabb, hogy ott minden fáljt ki kell bontani, mivel először a gzip-ből az egész .tar fájlt ki kell nyerni, és abból lehet csak további fájlokat kinyerni. De mint írtam, nem kötelező a tar.xz-t használni, lehet helyette 7z-t. De mégis az a gyakorlat terjedt el, hogy unix/like rendszereken forráskódot, binárisokat tar.gz-be csomagolnak, amit a magyar szakzsargon Tar Gizi-nek becéz.
Persze neked felhasználóként nem kell külön a gzip-et és a tar-t is futtatni, elég a tar-t meghívni, az gondoskodik a gzip-es részéről is.
-
Frawly
veterán
válasz
Shyciii
#63997
üzenetére
Kösz szépen. Telepítettem is a tárolóból, és tényleg olyan, mint a Messenger for Desktop volt. Bár nekem valahol fent van portable módban egy .deb csomagból kézileg kibontott Messenger for Desktop is.
Mondjuk a Caprine kapásból magával rántott egy 35 MB-os Electron csomagot, de a Messenger for Desktop is tartalmazta az Electront, volt is valami 70-100 MB a csomagméret.
-
Frawly
veterán
válasz
icemad
#63969
üzenetére
Skype és Facebook Messenger is van hozzá, le tudod tölteni az oldalukról a linuxot .deb csomagot, amit tudsz telepíteni. De tudjátok ugyanezeket böngészőből is használni a skype.com-ról vagy messenger.com-ról belépve.
LOL: most nézem, hogy a Messenger for Desktop linuxos támogatása megszűnt. Ez de gáz. Helyette Caprine-t vagy Pidgint lehet használni natív kliensként, az utóbbi benne van az alap tárolókban, szoftverközpontból telepíthető.
-
Frawly
veterán
válasz
lev258
#63925
üzenetére
Én úgy tudom, hogy kódol saját maga is, és nem csak mások által készített patch-eket rakosgat össze. Pl. a memóriamenedzsmentes dolgokat ő szokta írni a kernelben. A drivereket, fájlrendszereket, schedulereket, Meltdown/Spectre-sérülékenység elleni foltokat inkább mások készítik, de vannak még területek, amit Linus egymaga ír.
(#63928) Victor Súgó: az OS/2-nek olyannyira vége van, hogy egy csomó bank használja még, meg néha iparban is használják még, meg van egy retrós felhasználói bázisa is. Néha napján még 3rd party patchek is kijönnek hozzá. Szerintem az XP-nek is ez lesz a jövője.
-
Frawly
veterán
A Double Commander alapból nem jeleníti meg a rejtett (ponttal kezdődő) fájlokat és mappákat, külön be kell kapcsolni, hogy mutassa, a Beállításoknál kiválasztod a Fájlnézet kategóriát és ott annak a szekciónak a vége felé ott lesz, hogy Rejtett és rendszerfájlok mutatása. Az elnevezés csalóka, mert a rejtett/rendszermappákra is vonatkozik, nem csak fájlokra.
-
Frawly
veterán
válasz
growler
#63813
üzenetére
Igen, ez használható módszer. Bár nem minden alaplap támogatja, hogy csak úgy lehúzogatod a SATA kábelt, van, amelyiknél ezt a trükköt nem tudod eljátszani, mert a BIOS-t felkészítették erre a trükkre.
Szóval nem az SSD régiségétől, hanem az alaplap/BIOS korától függ. De ha nincs lejelszavazva az SSD, és támogatja a security erase feature-t, akkor a hdparm minden esetben tud security erase-t végrehajtani. Ez a security state frozen, non frozen akkor számít csak, ha az SSD le van jelszavazva.
-
#63812
Frawly
veterán
Victor Súgó
#63809
Frawly
veterán
válasz
Victor Súgó
#63809
üzenetére
De, igazad van, vannak ilyen SSD-k. De nem mindegyik. Nem mindegyik támogatja a titkosítva tárolást, ATA jelszavazást, és a security erase-t.
-
Frawly
veterán
válasz
Doky586
#63775
üzenetére
A hdparm-mal ne játssz, ha nem tudod mit csinálsz. Elgépelsz egy parancsot, és hazavághatja javíthatatlanul az egész meghajtót. SSD-nél és HDD-nél is. Csak akkor javallott a használata, ha tényleg ismered a kapcsolókat és pontosan tudod mit kell csinálni.
Egyébként security erase helyett lehet futtatni ezt is terminálban:
lsblk
sudo blkdiscard /dev/sdakármi (a /dev/azonosítót a fenti parancs jelzi ki)Ez a megoldás is végigtrimezi az SSD-t, mint a security erase, és csak pár másodperccel tart hosszabb ideig.
Szerk: á, látom megelőztek. Ugyanazt csinálja mindkettő, csak a security erase-t a firmware hajtja végre, és két fajta security erase is van, az egyik csak a titkosítási kulcsot trimezi felül, a másik a teljes meghajtót. A blkdiscard a teljes meghajtót. Ugyanaz az eredménye, épp olyan biztonsággal törli végig a meghajtót mindkét módszer. Még -s kapcsoló nélkül is. Egy végigtrimezett meghajtóról minden adat törlődik, semmit nem tudnak visszaállítani róla.
Esetleg ez a security erase NVMe meghajtóknál lehet fontosabb, mert azokon alapból nincs TRIM külön (az SATA/AHCI feature), a törlési paranccsal van összekötve.
-
Frawly
veterán
Ezekre Xubuntu, vagy más Xfce-s disztró (pl. Mint Xfce, amit már ajánlottak fentebb).
Egyébként ezek a 2 magos, 2 GHz körüli procik nem is olyan gyengék, amiket írtál, azok közül csak a 2 GB RAM tűnik nagyon korlátozónak. Ha lehet, akkor bővítsétek +2-vel, meg a HDD helyett betoltok egy 6 ezer forintos 120 gigás SSD-t.
-
Frawly
veterán
válasz
ubyegon2
#63745
üzenetére
Ez nem véletlenül SP920-as SSD? Annak szokása eltünedezni.
Nekem is volt egy furcsaság most Archon. Lement a frissítés pár napja, már nem is tudom milyen csomagok frissültek, talán systemd vagy kernel, vagy hasonló, ami miatt újra kellett bootoltatni. Erre bootkor elkezdte dobálni az fix I/O corruption hibákat végtelen loopba, közben meg cicergő hangot adott az SSD. Rögtön le is fostam a bokám, hogy akkor ez meg hogy. Kikapcsoltam a gépet 5 mp-ig nyomva tartva a bekacsológombot. Utána már rendben bootolt, adatvesztés sem volt. Nem értem mi lehetett, de magától megjavult. Valami f2fs vs. systemd bug lehet, ami csak egyszer jön elő a initramfs legenerálása után. Bár az is lehet, hogy nem az f2fs-hez volt köze, hanem most a Phoronixon olvastam, hogy az ext4 is bugozhat 4.19-es kernellel. Azóta nem jött újra elő.
-
#63739
Frawly
veterán
ontheground
#63737
Frawly
veterán
válasz
ontheground
#63737
üzenetére
Nem csak az ext2, de az ext3 és ext4 is írható/olvasható Windows alatt extra driverrel.
Linux alatt az NTFS-sel sincs baj, annyi, hogy nagy az overheadje az NTFS-es partíciók kezelésének, meg nem lehet töredezettségmentesíteni. Viszont ezek SSD-n nem okoznak gondot, TRIM-elni lehet az NTFS-t Linux alatt is.
/home-nak mindenképp ext4-et használj, ha nincs extra igényed. Nem véletlen az a default.
-
#63736
Frawly
veterán
ontheground
#63735
Frawly
veterán
válasz
ontheground
#63735
üzenetére
Ubuntu Studiohoz van azt hiszem low latency kernel. De ha nem tetszik, akkor amíg a Mixx-et futtatod, kilőheted a pulseaudio servert, akkor csak ALSA-s hang lesz. Persze ez csak akkor opció, ha az adott progi nem pulseaudio only.
Egyébként meg nekem a pulseaudio-val sem volt soha semmi latency problémám, se ropogás, se kattogás, se semmi. Esetleg próbálj meg a PA-nak még nagyobb prioritást adni, az is segíthet.
-
Frawly
veterán
válasz
ubyegon2
#63687
üzenetére
Elvileg a KDE-n is ott van ez alapból, nem is értem a kolléga problémáját. Sőt, még applet sem kell hozzá, a Rendszerbeállítások - Beviteli Eszközök résznél hozzá lehet adni listában a kiosztásokat, meg hogy melyik legyen default, és milyen kombóra váltson közöttük és menni fog. Az applet az arra kell, ha kijelzést akarsz neki vagy egérrel akarod átkattintani egy klikkből.
-
Frawly
veterán
válasz
anorche1
#63628
üzenetére
KDE-n is ki lehet tenni a tálcára Billentyűzetváltó widgetet/plasmoidot. Egyszer kell csak root jelszó, amíg hozzáadod a listához a használt kiosztásokat meg hogy melyik legyen default, és milyen hotkey-vel vált közöttük, onnantól fogva többet nem fog kelleni hozzá jelszó, és az egész úgy fog működni, ahogy Windowson.
-
Frawly
veterán
Tálcaappletnek állítólag az ibus jó a Fluxboxhoz. Vagy fbxkb. Esetleg a Tint2 tudja kezelni az Xfce és Gnome keyboard appletjeit: xfce4-xkb-plugin és gkbd-keyboard-displayl, de lehet jók ezek más tálcával is.
(#63553) csixy: nem érdemes belőle külön disztrót csinálni meg túl sok időt beleölni. Dunát lehet rekeszteni ezekkel a remaster disztrókkal amúgy is, meg ezek a pendrive-ra helyezett rendszerek is gyorsan avulnak el, sokat nem pöcsölnék ezzel. Nem éri meg.
-
Frawly
veterán
Egyébként ezért jók a minimalista disztrók és WM-ek, pl. Arch, Ubuntu/Debian minimal, stb., valami sovány WM-mel (IceWM, i3wm, Openbox, stb.), mert így megtanulod ezeket a dolgokat, hogyan kell konfigurálni, milyen login manager kell, hogy kell tálcázni, kompozitorozni, lokalizációt beállítani, kiosztást, milyen GPU driver kell, milyen hardveres gyorsításos csomag, stb., így a saját disztródat tudod felépíteni belőle, és nem leszel többé a kezdő disztrók megoldásaira szorulva, az alapoktól mindig ki tudod építeni a rendszered testre szabottan, működőre, meg könnyebben javítod, ha a disztróban elx@rtak valami gyári beállítást. Nem kell azzal szívni, hogy disztróhopperkedj, hogy egyiken ez nem megy, a másikon az nem megy, a harmadikon minden megy, de csíkoz (tearing), a negyediken az energiagazdálkodás nem jó, az ötödik jó lenne, de azon meg a téma csúnya.
Plusz ezek a minimalista rendszerek elég gyorsak is, alig pár másodperc alatt bootolnak.
Most Gnome-ot használok, de a következő Arch telepítésnél visszaállok f2fs-ről ext4-re, meg Gnome helyett Sway vagy Waybox megy fel, hogy újra minimalista rendszerem legyen.
-
Frawly
veterán
Igen, azt értjük, hogy Debian alapú, de azt továbbra is sikeresen titkolod, hogy pontosan milyen WM vagy DE ez. Nagyon valószínű, hogy létezik hozzá tálcaalkalmazás, amit csomagkezelővel felraksz, elindítasz, bekonfigurálsz, aztán utána már perzisztensen mindig be fog töltődni.
A setxkbmap-nak meg lehet adni egy csomó opciót is, melyik hotkeyre váltogasson milyen kiosztásokat, le legyenek-e tiltva a Lock gombok, be legyenek-e kapcsolva, mi legyen a compose hotkey, stb.. Tehát nem csak simán annyit tud, hogy mögéírod, hogy hu.
Nálam Openbox alatt többek között ez volt írva a ~/.config/openbox/autostart fájban
setxkbmap -option grp_led:caps,grp:alt_shift_toggle,caps:none hu,us &
xbindkeys -p &Az első sorban úgy állítottam be, hogy bal Alt+Shift-re váltson szabvány magyar és amerikai kiosztás között (többet is fel lehet sorolni, nem csak kettőt, az elsőnek szereplő lesz a default), a Caps Lock legyen tiltva (idegesít, ha véletlenül rányomok) és a letiltott Caps Lock leden mutassa, hogy melyik kiosztás aktív (nem világít - hu, ha világít us).
A második sorban meg az xbindkeys Xorg-os keybindek voltak megadva, amik az ~/.xbindkeysrc fájlban voltak konfigurálva:
"pamixer --allow-boost --increase 5"
XF86AudioRaiseVolume
"pamixer --allow-boost --decrease 5"
XF86AudioLowerVolume
"pamixer -t --allow-boost"
XF86AudioMute
"pamixer --source 1 -t"
XF86AudioMicMute
"xbacklight -inc 1"
XF86MonBrightnessUp
"xbacklight -dec 1"
XF86MonBrightnessDownEz meg azért kellett, hogy a laptopon lévő spéci billentyűk működjenek, fényerő fel-le, hangerő fel-le, némitás, mikrofonnémítást, stb..
-
Frawly
veterán
Xorg-os felület esetén a setxkbmap hu paranccsal átváltasz rá, vagy ezt beteszed automatikus indulásba. Vagy felrakod az adott grafikus felület billentyűzetes tálcaalkalmazását, amivel be tudod konfigurálni, hogy melyik legyen az alapértelmezett, és hogy milyen billetnyűre lehessen kiosztást váltogatni.
-
Frawly
veterán
A mesa csomag nem minden disztrón van fent alapból, bár a kulturáltabb, elterjedtebb desktop distrókon fent szokott azért lenni default. Az az OpenGL-hez kell. Vulkanhoz a vulkan-intel csomagot kell feltenni.
Shyciii: valóban, a hardveres videódekódoláshoz a libva-intel-driver csomagot kell feltenni, ha ez utóbbi nem menne, akkor újabb Intel GPU-kon meg lehet próbálni helyette felrakni az intel-media-driver nevű csomagot. Ezek archos csomagnevek, lehet Ubuntun, Minten kicsit máshogy hívják őket.
-
Frawly
veterán
válasz
Shyciii
#63466
üzenetére
Nem. Az i915-ös kerneldriver mindenféle Intel GPU-hoz van, egy nagy masszív, komplex driver, ami mindenféle régibb és újabb Intel GPU-t kezel, az i915-től egészen a legújabb Coffee Lake-ig, 14 év alatt megjelent több GPU generációt.
Az i965 és annál újabakat arra írtam, hogy azokra a Xorg Intel drivert nem ajánlják feltenni, mert problémákat okozhat. Ezeket csakis kizárólag az i915-ös driverrel ajánlott hajtani Xorg alatt is.
-
Frawly
veterán
válasz
Shyciii
#63462
üzenetére
Az i915 lényegében az Intel modesetting kernel driver neve, vagyis magának a kernelmodulnak, ami ezt tartalmazza. Ezzel van meghajtva Linuxon alapból az összes Intel GPU, hacsak fel nem teszed a Xorg drivert (xf86-video-intel azt hiszem a neve), vagy le nem tiltod nomodeset paraméterrel boot során.
i965-ös GPU-hoz, illetve ettől újabbakhoz (Nehalem, Sandy Bridge, Ivy Bridge, Haswell, Broadwell, az összes ezt követé Lake-es prociba integrált GPU) ez való.
Nálam Archon a Xorg sajnos mindenképp szórakozott a Sandy Bridge-ben lévő HD3000-rel, mindegy, hogy fent volt-e a Xorg driver, vagy az i915 modesetting drivert használtam helyette. Így átálltam Wayland Gnome-ra, így nincs semmi Xorg.
-
Frawly
veterán
válasz
CPT.Pirk
#63459
üzenetére
Az „újabb” inteles GPU-kat úgy kell érteni, hogy i965 és attól újabb, azok azért már jó pár évesek. Ennek az az oka, hogy a Xorg Intel drivert már alig fejlesztik egy ideje, majdnem teljesen magára hagyott projekt, csak némi folt készül hozzá, minden fejlesztő az Intel modesetting kerneldriver fejlesztésére állt át.
Gond úgy szokott lenni belőle, hogy a Xorg Intel driverrel elkezd a kernel ilyen atomic DRM helper/flipping lófütyi hibákat dobni, meg a login manager vagy a Xorg fagyni. Random. Van, akiknek bizonyos nem használt GPU csatlakozók (S-VIDEO, HDMI, stb.) letiltása segít, nálam Intel HD3000-en nem segített.
-
-
Frawly
veterán
-
Frawly
veterán
Nem Wine alatt megy. Ez egy natív, 32 bites linuxos játék, a MoH:AA Loki-Icculus-féle portja, LibGL-t, OpenAL-t, és OSS-t használ natívan.
De abban is biztos vagyok, hogy nem a futtatható állománnyal van a baj, mert kipróbáltam, és más .desktop fájlokat sem hajlandó hozzáadni a rendszer a menühöz.
Mondanám, hogy Arch, vagy Gnome 3.30 bug, de akkor gyurmafiguráknál is elő kéne jönnie. Semmilyen ezzel kapcsolatos dolgot nem állítottam át a Gnome-ban, még a Tweaks-ben sem. Egyszerűen nem értem.
exec /home/Gmz/MOHAA/mohaa_lnx formában nem tudom futtatni, mert a játéknak fontos lenne, hogy a munkamappája /home/Gmz/MOHAA legyen, mert ebben kell megtalálnia bizonyos gyárilag mellékelt .so fájlokat. Ha csak simán teljes elérési úttal hívom meg, akkor nem fogja megtalálni ezeket és nem fog működni.
-
Frawly
veterán
Nálam az sose működött, ha csak simán odamásoltam, már a 3.28-as verzióban sem. Ebben a 3.30-ban meg sehogy sem működik, pedig próbáltam rendszergazdaként a gtk-update-icon-cahe és update-desktop-database parancsokat is futtatni, hátha úgy frissül. Ki-bejelentkezés, újraindítás se segít. Teljesen mindegy milyen jogokat adok az ikonnak, ki a tulajdonos, nem bukkan fel sehol az indítómenüben, se a dashben.
Elvileg a .desktop fájl is jó, az ikonját rendesen meg is jeleníti, de csak Double Commanderben, a Gnomes Files egyik ilyen .desktop fájl ikonját sem jelenti meg. Arra is ügyeltem, hogy az a progi, amire a .desktop fájl mutat, olyan mappában legyen, aminek a nevében nincs szóköz, meg a kis/nagybetűre is figyeltem
-
Frawly
veterán
Szerintem nem kezdő téma, de hátha mégis, és csak én nézek el valamit.
A Gnome3 application menüjéhez szeretnék kézzel alkalmazást .desktop fájlként hozzáadni.
Ez már régen is nehezen működött, a kész .desktop fájlt először a Gnome-fájlkezelőben futtatnom kellett, ott rákérdezett, hogy futtathatóvá-akarom-e tenni (akkor is ha futtathatónak volt jelölve már). Utána berakta a menübe.
Aztán egy idő után az is kellett, hogy én másoljam be kézzel a .desktop fájlt a ~/.local/share/applications mappába. De már ez sem működik, mióta frissült a 3.30-as verzióra. Hiába van beállítva a Gnome fájlkezelőben, hogy ezeket a futtatható szöveges fájlokat nyissa meg, ne szerkessze, sehogy nem tudom a menühöz adni, hiába másolom be a fenti mappába, hiába adok neki +x attribútumot (vagy 777-et), nem jelenik meg a menüben. Próbáltam ki-bejelentkezni, gépet újraindítani, hátha úgy látszani fog, de nem.
-
Frawly
veterán
válasz
ubyegon2
#63306
üzenetére
Igen, olvastam, meg írtam azt is, hogy be lehet menni alá.
A Waybox nem úgy klón, mint az Arch klónok. Waylandre a felületeket teljesen át kell írni, mivel más protokollt használ. Az Arch-klónok csak telepítőscriptben meg beállításokban térnek el. Nagyon nem egy a kettő. A Waybox, Sway csak úgy klón, hogy kinézetben, működésben próbálja utánozni az eredeti Xorg-os verziót, de a kódjuk teljesen a 0-ról van írva.
Nekem még soha egyik disztrón sem volt gond a betűkkel, pedig infinalityt soha nem használtam. Az a titka, hogy
1) rendes GPU driver kell
2) a fontsimítást és hintinget rendesen be kell állítani, hogy az adott kijelzőn a legjobban nézzen ki
3) fel kell tenni normális fontokat. -
Frawly
veterán
válasz
ubyegon2
#63296
üzenetére
Ha Antergoson 3 mp.-et mértél, akkor az Archon sem lesz kevesebb (hacsak nem hekkelsz még hozzá).
A stopperral kitételen sikerült átsiklanom olvasás közben, mea culpa. De az egész csak azt demonstrálja, hogy igazam van, mert ha ezen a Core i gépen 3-6 mp. a boot, akkor C2D-val be lehet menni 10 környékére, közelebb a 10-hez, mint a 35-höz. Innen indultunk, és ide térünk vissza mindig.
Egyébként ez a 3-6 mp. boot már az a kategória, hogy mindenféle sleepet és hibernálást feleslegessé tesz.
Nekem egyébként hiányzik az Openbox, ha lesz majd waylandes klónja, akkor felrakom. Most Gnome van, de legközelebb a Swayt teszem fel, ha addig nem lesz *box wayland klón, ami helyesebben van már most is, de még nagyon kezdetleges projekt: Waybox.
-
Frawly
veterán
válasz
ubyegon2
#63293
üzenetére
Ott rontottad el, hogy nem Arch klónt kell feltenni, hanem tiszta Archot a Wiki alapján. Ha elakadsz, akkor az Arch-topikban jelentkezel, segítünk. Az fdisk -l megmondja milyen partíciós séma van az SSD-n.
Mentás Cinmanótól nem rossz az 5,9 mp. bootidő, de mint már felhívtam a figyelmed, a systemd-analyze általában fals értékeket ad vissza, stopperrel mérd a bootmenütől (BIOS bootmenü, vagy GRUB, vagy ami van) indítva. A systemd-analyze értékeit inkább relatív összehasonlításként érdemes csak kezelni.
-
Frawly
veterán
válasz
shapphire
#63233
üzenetére
Hát sajnos a SIS VGA-k elég szutyokak voltak. Én már a maguk idejében is kerültem őket. Nem is tudom hirtelen, hogy Linuxon arra milyen driverek vannak. Gondolom van valami kernelbe épített nagyon alap cucc, amiben nem lesz hardveres gyorsítás, még 2D-ben sem, nem hogy 3D-ben.
-
Frawly
veterán
válasz
ubyegon2
#63230
üzenetére
De ugye ezeket az eredményeket nem systemd-analyze segítségével mérted, mert az totál bullshitet szokott mutatni. A bootmenütől, GRUB-tól, stb. kell mérni, rendes stopperral (lehet telefonos app is), és ott kell megállítani, ahogy az asztal megjelent az összes panel, ikon betöltődött. Ha közben be kell jelentkezni, jelszót kell beírni, arra az időre meg kell állítani a stoppert, majd tovább folytatni a mérést.
Az a 2,7 mp azért is hihetetlen, mert még NVMe SSD-nél sem elérhető szerintem most már, mert a kernel, amíg detektálja a hardvereket, annak is van egy minimális átfutási ideje, ami nem az SSD-n múlik.
-
#63229
Frawly
veterán
ArthurShelby
#63203
Frawly
veterán
válasz
ArthurShelby
#63203
üzenetére
Na, ez már azért közelít, de szerintem még mindig lehet ebből pár másodpercet faragni, ha a systemd-analyze blame kimenetekből megfejted mi lassítja le, esetlen a Xorg-os problémát megoldod.
(#63204) ubyegon2: az a 2,7 és 3,2 mp. az elég badass, gondolom még systemd nélkül volt az a pár éve. A Linux is egyre jobban bloatosodik.
Persze itt nem is arról volt szó, hogy 1 mp. alatt kell bootolni, de onnan indultunk, hogy a kollégának 3 perc volt a boot. Ez lement 35 másodpercre, most már 20-nál tartunk. Már ha ennél gyorsabb nem is lesz, az már 900%-os javulás.
-
#63202
Frawly
veterán
ArthurShelby
#63197
Frawly
veterán
válasz
ArthurShelby
#63197
üzenetére
Annak MATE-tel mindenképp be kéne mennie 10 mp alá. Lehet nem sokkal, de be kéne. Igaz MATE-et rég nem tettem fel. Nálam a MATE-nél sokkal bloatabb Gnome3 van, a tiednél gyengébb i7-2620M procival 8-9 mp. körül, az SSD-m is sima középkategóriás MX300, ami nem gyorsabb a tiédnél. Lehet nálam az is számít, hogy Arch-on van a rendszer, neked meg valami bloatabb disztrón. Arch Openboxszal 4 mp. körül volt a boot, ami leromlott később 5 mp-re, igaz ez kicsi WM-mel volt.
uby: te is ugyanazt írod, amit én. Említed, hogy 20 mp alá nem megy, aztán meg 15-öt írsz, ami meg valóban közelebb van a 10-hez, mint a 35-höz, pont ahogy én jósoltam. A 35 mp. mindenképp sok, ahhoz képest a 20 is jelentős ugrás lenne.
Tapasztalatom szerint leglassabban a KDE és a Unity bootol. Aztán a Gnome. Cinmanót és Ma Téj-t nem próbáltam már rég. Xfce ebben a szempontból erősen közepes. Az Openbox, IceWM, i3wm, dwm bootolása pedig villám.
-
Frawly
veterán
válasz
ubyegon2
#63193
üzenetére
Tudom, a gép sem villám, régi C2D proci, azért is írtam, hogy közelebb van a 10-hez, mint a 35-höz. Core i procival lenne 10 mp. alatt is akár. Azt mindenképp elismerem, hogy a régi proci, főleg, ha gyengébb széria, nem tudja kihajtani az SSD-t. Emiatt mindenképp lassabb lesz ilyen gépekben.
-
#63179
Frawly
veterán
Flowtation
#63169
Frawly
veterán
válasz
Flowtation
#63169
üzenetére
Szerk.: látom már törölted a fájlt.
(#63178) ubyegon2: a snap-pal nekem is az a bajom, hogy belehányt a rendszerbe, ami eltávolítás után sem tűnt el. A flatpakkot még nem próbáltam, de félő, hogy az is ilyen. Én is a hivatalos tárolóból telepítek. Ha nagyon nagy a kényszerűség, akkor külső tárolóból. Az már nagyon ritka, ha valamihez binárist szedek le, vagy forráskódból forgatom.
-
Frawly
veterán
válasz
CPT.Pirk
#63159
üzenetére
Ezt igazából a driver okozza, nem az S-video kimenet. Az Intel driverek egyre x@rabbak sajnos. A Xorg-Intel drivert nem nagyon gondozzák. A kernel modesetting drivert meg nem szereti a Xorg újabban. Én is ezért váltottam Waylandra, abból is a Gnome tűnt a legműködött alternatívának, de talonban van tartva a Sway (i3wm-klón Waylandre). A Wayland teljesen jól elvan a kernel modesetting driverrel.
Nálam a Wayland is szórakozik egy ideje, néha nem áll le a GDM, 1 perc 39 másodpercig tart, mire leálláskor néha lelövi a rendszer, ilyen A stop job is running jeligével számol vissza. Ezt sajnos meggyorsítani sem tudom, pedig átírtam a systemd konfigjában (DefaultTimeoutStopSec értékét levettem az /etc/systemd/system.conf-ban), de nem segít, állítólag ezt csak a systemd újrafordításával lehet rövidíteni. Be kéne vezetniük erre egy billkombót, aminek a lenyomása után azonnal lelőlné az adott folyamatot. Mert így is kilövi, szabálytalan leállítással (sigterm helyett sigkill), csak sokat kell rá várni. Pöcstering dolgozhatna még ezen.
Még az is lehet, hogy a GDM Xorg-emulációt használ, nem Waylandet, és ez amiatt van. Az biztos, hogy driver gond, de más baj nincs vele, a képi megjelenés tökéletes, fagyások sincsenek, sem más anomália, csak néha leragad ennél leállításkor.
-
Frawly
veterán
Igen, a fontméret is lehet baj, van olyan font, ami nem tud túl kicsi méretre skálázódni.
Próbáld meg növelni a font hintinget, meg esetleg még kalibrálni a font rendering subpixeles beállításait, mert tuti lehet ezen a renderelésen még javítani, a Linux nem csak ennyit tud, ami ezen a képen látszik.
Szerk.: nekem sem jutott volna eszembe a DPI-t állítani, pedig tényleg érdemes ránézni még akkor is, ha nem látszik baj a rendereléssel. Alapból sokszor nem a jó értéken áll, nem a kijelzőnek megfelelő.
-
Frawly
veterán
Ez attól van, hogy a weboldalon használt font nincs meg a rendszereden, ezért a böngésző egy másik fallback fonttal helyettesíti, de abban meg nincsenek rendes magyar ékezetek. Vagy rakd fel az MS-féle fontcsomagot, vagy valami normálisabb TrueType, OpenType fontot állítsd be a böngészőben alapértelmezettként (Ubuntu, DejaVu, Linux Libre, Liberation, UWR, Adobe, vagy hasonló fontok), ezek szokták támogatni az Unicode-karaktereket, közöttük a magyar ékezeteket is, és simán a tárolókból feltehetők csomagból, nem kell neked összevadásznod weboldalakról meg kézzel telepíteni.
Én az ms-core-fonts-ot soha nem teszem fel, mivel külön felüdülés, ha nem az agyonunt MS-os fontokat kell bambulni, azokat néztem már eleget az elmúlt 10-25 évben, annyi elég is volt belőlük egy életre. Windows alatt is az első, hogy felteszek normális fontokat.
Nálam most Gnome-ban az alap Cantarell font van, böngészőben és egyéb progikban talpas és talpatlan fontnak DejaVu/DejaVu Sans, fix szélességű fontokat használó progikban (terminál, text editor) meg Fantasque Sans Mono.
-
Frawly
veterán
Gnome Files-ban (alapértelmezett fájlkezelő) rámegyek egy olyan fájlra, aminek az alapértelmezett megnyitását akarom átállítani, jobb klikk, Open with Other Application, és ott mentem, mint Default.
De a Gnome Settings - Details - Default Applications részben is tudsz néhányat közvetlenül állítgatni, igaz csak általános jelleggel, nem fájltípusok szerint.
Írtad neked Mate van, azon nem tudom. Rég használtam.
A Double Commanderben lehet állítani Commander szintjén is, hogy mit mivel nyisson meg, de ez csak arra vonatkozik, amit ebből indítasz.
-
Frawly
veterán
Double Commander?
Engem az ilyen automatikus megnyitós alkalmazásoknál az zavar Arch Gnome-on, hogy beállítok X alkalmazást, hogy Y formátumot azzal nyisson meg. Ez működik is, de ahogy frissül egy Z alkalmazás, ami szintén meg tudja nyitni azt az Y formátumot, akkor frissítéskor annak a post install scriptje őhozzá rendeli át az alapértelmezett megnyitást. Aztán állítgathatom át megint, hogy X alkalmazás nyissa meg.
-
Frawly
veterán
válasz
Shyciii
#63044
üzenetére
Bizony, kell az acpi hozzá. Ezért kell nagyon tüzetesen Arch Wiki-t olvasni, ott ezek a dolgok le vannak írva. Tudom, nehéz hozzászokni, de majd ahogy belejössz, egyre kevésbé kell majd a Wiki. Eleinte viszont az lesz a Biblia. Nem véletlen van az a dakota közmondás, amit Viktorunk is előszeretettel idéz: RTFM (Read The F***ing Manual)!
Egyébként én simán csak a login managert szoktam visszahívni zárolásra (LightDM esetén: dm-tool lock). Az i3lock nekem túl fapados.
-
#63038
Frawly
veterán
southernsun
#63023
Frawly
veterán
válasz
southernsun
#63023
üzenetére
Beletoldod a scriptedbe az lsusb | grep bla-bla megoldást, hogy visszaadja az USB eszközazonosítót, így a script tud vele dolgozni.
(#63026) cigam: a HUP eleve nem volt linuxos portal, azért is Unix Portal van benne a nevében. Igaz eredetileg opensource dolgokkal foglalkozott, de mostanában már van rajta mindenféle hír, windowsos, mobilos, stb.. De a törzsközösség valóban linuxos.
Magyar oldalról nem tudok, külföldiek közül ezeket érdemes nézni azokon kívül, amit már írtak:
phoronix.com
kernel.org
kernelnewbies.org
lwn.net
lkml.org -
Frawly
veterán
válasz
Shyciii
#63005
üzenetére
Akkor felhasználói nevet, jelszót nem csináltál rendesen az alaprendszerre a LightDM telepítése és systemd-s engedélyezése előtt. Mást nem tudok elképzelni, mert úgy alapból mennie kell, ahogy írtam.
Ha ilyen pervezióid vannak, azt a jövőben az Arch-topikba kéne írni, mert nem kezdő téma, és konkrétabb disztróhoz kötődik.
-
Frawly
veterán
válasz
Shyciii
#62977
üzenetére
Tiszta Arch-csal továbbra is tudsz próbálkozni, mondjuk virtuális gépben tudsz vele gyakorolni. Ha belejössz, feltelepíted fő rendszernek.
Az ilyen scriptes csodainstallerekkel az a baj, hogy nem fogsz belőle tanulni. Feltelepíted, megy. De nem fogod tudni mitől. Ez kiváltképp akkor baj, ha véletlenül mégis valami gikszer üt be, nem megy valami, akkor meg azt nem fogod érteni, hogy miért nem megy, és nehezebb lesz kideríteni, hogy mi lett elcsesszerintve.
Egyébként pure Openboxszal is szívsz majd egy csomót, mert önmagában annyira fapados, hogy semmi nincs benne, csak egy szürke háttér, meg egy jobb kattintásos menü. Se panel, se ikonkezelés, se menü/dokk, se redshift, se clipboard kezelés, se témakezelés, se háttérkép, semmi, egy csomó mindent neked kell hozzá feltenni meg felkonfigurálni.
-
Frawly
veterán
válasz
Shyciii
#62971
üzenetére
Valamit elszúrsz. Nem kell sem xinit, sem startx. Feltelepíted az Openboxot. Majd feltelepíted a LightDM-et. A login managert be is kell aktiválni, ehhez az ArchWiki LightDM cikkét nézd meg, de lényegében a fontos sor:
systemctl enable lightdm.serviceMajd újraindítás után eleve a LightDM-nek kéne bejönnie, amiben már alapból ott kéne lennie az indítható Openboxnak. Semmit nem kell hozzá hackelni.
Szerk.: á, látom feladtad, és Zen installerrel oldottad meg. Mindegy, majd a jövőben újra nekifutsz. Ha még ennyire friss Linux user vagy, hogy csak nemrég váltottál Windowsról, akkor lehet nem is volt itt az ideje a pure Archnak. Egyébként pont ez a lényege, ha megtanulod rajta ezeket az alapokat, mint az alaprendszer telepítése, bootolás megoldása, login manger, DE/WM feltelepítése, beállítása, akkor többet nem leszel semmilyen másik disztróra meg installerre rászorulva. Szóval megéri vele szívni, később ez nagyon sokat fog kamatozni.
-
Frawly
veterán
válasz
ubyegon2
#62960
üzenetére
Szerintem szinte soha nem saját hibából történik. Legtöbbször még a környezet sem oka. Egyszerűen a háttértárak nem az örökkévalóságnak készülnek. Elfáradnak, kopnak. 5 évnél tovább nem is érdemes alapozni egy HDD-re. Persze ha olyan a környezet, az is betehet nekik, szar táp, nem jól szellőző ház, mechanikai behatás, stb..
-
-
Frawly
veterán
válasz
Shyciii
#62833
üzenetére
Az i3wm egy billentyűzetes irányításra tervezett tiling WM. Abban aztán csak kész, elindított progik felületére tudsz kattintgatni. Valószínű még nem vagy olyan advanced power user szinten, hogy használni tudd, vagy csak szimplán sok doksit kéne olvasnod hozzá meg beletanulnod. Nem is azt írtam, hogy feltétlenül ezt ajánlom neked, hanem hogy még egy ilyen fapados ablakkezelőnél is megoldhatók azok a dolgok, amiket szeretnél.
Próbálkozz Openboxszal, az esélyesebb lesz neked. Igaz elsőre az is nagyon fapados, mert mindenről neked kell gondoskodnod, tálcáról, menüről vagy dokról, dbus, stb. támogatásáról, kompozitorról. Tehát igazából csak annyival leszel vele előrébb az i3wm/Sway-hez képest, hogy egérrel is tudsz kattintgatni, meg nem csempékbe rendezi az ablakokat, de majdnem ugyanolyan fapados.
-
Frawly
veterán
válasz
Shyciii
#62809
üzenetére
Igazából ezeket bármilyen DE-n vagy WM-en be lehet állítani, de terminálban kell hozzá .conf fájlokat hekkelni. Lásd Arch Wiki ACPI és Power Management és egyes DE/WM-kről írt összefoglaló cikkeit. Én ezeket sima Openbox, IceWM, i3wm alatt is be tudtam állítani, nem olyan nagy művészet.
-
-
Frawly
veterán
Ott valami probléma van boot során, mert egy Xfce-s bootnak még egy P4-en sem kéne 10 percig tartania. Próbálj boot közben Esc-et nyomni, hátha látszanak a kernel kiírásai, ha nem, akkor a Grub az adott sor indításánál ki kell szerkeszteni a quiet és splash paramétereket. Így meg lehet nézni, hogy hol ragad le a bootfolyamat.
Ha az Xfce is túl sok lenne annak a gépre, próbáld LXDE-s, Openbox vagy IceWM felületű disztrót. Ezek egyre fapadosabbak, de kevesebb a hardverigényük.
-
Frawly
veterán
Ez nem fog menni, előre szólok. Az segíthet ideiglenesen, ha a resolv.conf-ba ezeket beírod. De ahogy újrabootoltatod a gépet, vagy a NetworkManagert újraindítod, felül fogja írni a resolv.conf-ot a default tartalommal, ott van a resolv.conf elején:
Generated by resolvconf vagy
Generated by NetworkManager -
Frawly
veterán
A kernelben lévő PowerVR driver csak 2D-ben működik (van kép, meg minimális energiagazdálkodási funkciók), 3D és hardveres gyorsítás, vsync, stb. nincs benne. Nekem is volt hasonló procim, hasonló GPU-val (N2600-as Atom GMA3600-zal, 1 GB RAM-mal), és egy hulladék, mindent szoftverből kellett kompozitorral megoldani, már azt is, hogy ne legyen tearing. De a 3D-s alkalmazások nem mentek. Win7 alatt sem a kiadott driverrel.
Vegyél egy használt 2-3. genes ThinkPadet olcsón, ezt a hulladékot meg hajítsd ki a kukába, nem sok mindenre jó. Arra a gépre vagy csipketerítőt virágvázával vagy virágföldet kell tenni, nem Linuxot vagy Win7-et.
-
-
-
Frawly
veterán
válasz
ubyegon2
#62626
üzenetére
Nem, nem kell őket együtt használni. Nagy segítség az uBlock Origin egymagában is. Ha meg van NoScript, az meg kivált megint egymagában mindenféle más blokkolót. Ami miatt az utóbbit nem használom, az szintén az, hogy idegesít, hogy minden oldalon külön kell engedélyezni rajta minden sz@rt, nincs időm arra, hogy a netezém fele whitelist-hez hozzáadogatással menjen el. De ha nagyon régi gépen próbálnak netezni, és nem sokféle oldalt látogatnak, azon csodát tehet a NoScript.
-
Frawly
veterán
Nyugodtan titkosíts gyenge gépen is. Ryzenben meg modern procikban van AES utasításkészlet, ott eleve nem is okoz lassulást. Amelyik prociban meg nincs ilyen, ott sem okoz nagy lassulást. Én használtam tartósan AES256-os LUKS-ot egy marha gyenge T1400 CPU-s laptopon, és alig van mérhető lassulás (ilyen 1-3% közötti), kisebb az overheadje egy AES256 XTS LUKS-nak ext4-gyel, mint egy titkosítatlan NTFS-3G-vel hajtott NTFS kötetnek. Nem kell tőle tartani, ha az adataid fontosak, titkosítani érdemes.
SSD-ken is csak arra kell figyelni, hogy a TRIM-et engedd ki a LUKS-on, ehhez van leírás az Arch, Gentoo Wikijeiben.
(#62619) malnabokor: elvileg a Bodhi is jó lehet rá, a másikat nem ismerem, amit írtál. Én Sparky Linuxot tennék rá IceWM-mel, esetleg szintén IceWM-mel AntiX-ot vagy MX-Linuxot. A Vistához képest mindenképp hasítania kell. Főleg, ha vesztek bele egy olcsó 120 gigás SSD-t 6-8 ezer környékén, amit később újabb gépbe is át lehet tenni.
Az ilyen korú gépeken nem is a proci a szűk keresztmetszet, hanem az 1 giga RAM, az tud túl gyorsan fogyni böngészéskor.
-
Frawly
veterán
Pedig egy szinten túl csak úgy fejlődsz, ha mindent beállítasz, kiismersz. Eleinte valóban elkaphat az agyvérzés, de utána ahogy mindent kiismertél, onnantól szabad leszel, mindegy lesz milyen disztrót használsz, mert mindegyiket be tudod lőni ugyanolyanra, úgy, hogy minden működjön és ugyanúgy nézzen ki. Onnantól már csak az fog dönteni, hogy mennyire friss csomagokat akarsz, melyik disztró tárolójában találod meg a neked kellő összes csomagot, meg mit szeretnél, milyen séma mentén frissüljön a disztró (rolling vagy kiadás alapokon).
Én erre a fajta tanulásra az Archot ajánlom. Annyival másabb a Debiannál, hogy nincs telepítője, meg frissebbek a csomagok, és nem kell ilyen non free tárolók külön engedélyezésével kínlódni. De elvileg ugyanott vagy, ha Debian netinstall-lal, vagy Ubuntu Minimal-lal próbálkozol, csak Debian-nál azzal kell kezdeni, hogy 0. lépésben engedélyezni kell az összes non free tárolót.
De erre egy szint fölött érdemes már csak rámenni, mikor már nem vagy olyan teljesen kezdő, hogy egy egyszerű terminálozás gondot okozzon, kisismerted a mapastruktúrát (mit hol keress, /etc, /tmp, stb.), meg kitapasztaltad, hogy milyen progikra, csomagokra van szükséged.
-
Frawly
veterán
Lánynak, ilyen gyenge gépre ne nyújts egyáltalán supportot. Főleg nem Linuxot. Mindegy mit teszel fel neki, frissítéskor bármi eltörhet más disztrókon is (Windowson is, de ahhoz vidéken könnyebben talál segítséget). Ha fent van a Debian, azon oldd meg, hogy jelszó nélkül frissüljön, ezt passzolom, attól is függ, hogy milyen grafikus felületet tettél fel. Meg engedélyezd a non free tárolókat.
-
Frawly
veterán
Ha új gép, ami tudja az UEFI-t (valószínű), akkor csak fel kell telepíteni a két OS-t tetszőleges sorrendben. A másodiknak telepítendő OS-nek kell hagyni particionálatlan helyet.
Régebbi MBR+BIOS only gépeken is csak arra kellett figyelni, hogy először kellett a Windowst telepíteni, utána a Linuxot. Ellenkező esetben a másodjára települő Windows bootloadere felülírta a Linux rendszerbetöltőjét.
Esetleg havernak elmagyarázni, hogy ha saját maga feltelepíteni nem tudja, meg gondolom a Win-hez sincs legális kulcsa, akkor ne legyenek extra igényei, hogy ő még TempleOS-t meg PC-DOS 3.30-at is akar rá. Linuxszal ismerkedhet virtuális gépben is, vagy akár pendrive-ra, külső HDD-re vagy SSD-re is fel lehet telepíteni utólag.
-
Frawly
veterán
válasz
Shyciii
#62268
üzenetére
Ez elég hihetetlen. Rövid időn belül már a második vagy a topikban, aki ilyen karakterkódolási problémába fut bele. Lehet én tudom rosszul, de ma már mindegyik disztrónak UTF-8-at kéne default használnia.
Az a beállítás jó, amit írsz. A /etc/locale.conf-ot szerkeszted. Lehet kell a locale-gen futtatása után egy újraindítás is.
Esetleg locale-gen futtatása előtt nézd meg az /etc/locale.gen fájlt is, hogy abban mi van kikommentelve, ez egy teljesen másik fájl a locale.conf-hoz képest.
Én is lokalizálatlan amerikain használom az Archot, Wiki alapján konfigurálva, így UTF-8 kódolásban (locale.conf a LANG=en_US.UTF-8 sort tartalmazza, a locale.gen fájlban meg az en_US.UTF-8 UTF-8 sor van a kommentezésből kivéve), amerikai és magyar billentyűzetkiosztással, és még soha egyik programban sem volt probléma, hogy ne lettek volna jók a karakterek, vagy valami karaktert ne tudtam volna begépelni (pedig a magyar ékezetek mellett egy csomó Unicode-karaktert is be szoktam vinni, nyomdai, fonetikai, matematikai jelek, és ilyen weboldalakon, pdf-ekben a japán, kínai, stb. jelek is helyesen jelennek meg). Vagyis volt egy meghajtó, amin az ékezetes karaktert tartalmazó fájlnevek nem jelentek meg rendesen, de az még talán XP-vel létrehozott NFTS partíció volt, franc tudja milyen régi Total Commanderrel rágányolt fájlokkal, gondolom az még nem UTF-et használt, de windowsos megoldástól nem is vártam más. Annak ellenére, hogy az UTF-8 ma már minden modern Windows verzión (7-től felfelé) alap.
-
Frawly
veterán
válasz
Prowler
#62220
üzenetére
Ezek elég morbid tünetek, amit írsz. Még ha nincsenek is fent a magyar nyelvi csomagok, de ha telepítéskor magyar nyelvet jelöltél be, akkor eleve magyarul kéne a legtöbb proginak futni, meg ékezetekkel sem lenne szabad bajnak lennie, mivel UTF-8-at használ a legtöbb disztró alapból. Így max. 1-2 progiban lehet az (pl. Firefox), meg rendszerbeállítások, meg ilyesmik, ahol külön nyelvi csomag híján angolul jelennek meg a dolgok, de ezeket a nyelvi csomagokat is egyszerűen telepítheted a tárolókból a csomagkezelővel.
A nem induló programokat próbáld terminálból indítani. Tudom, írtad, hogy a terminál nem nyílik meg, próbáld menüből indítani. Ha máshogy nem megy, Ctrl+Alt+3 kombóval hozz elő egy konzolt, és úgy próbáld ezeket futtatni. Ha nem is indul el valami, látszani fog a hibaüzenet.
-
Frawly
veterán
válasz
Shyciii
#62174
üzenetére
Általában az automatán generált fstab jó szokott lenni.
discard használható, de attól is függ milyen SSD-d van és milyen fájlrendszert használsz rajta. Ha nem olyan SSD, ami feketelistán van queued TRIM ügyileg a kernelben, vagy esetleg olyan fájlrendszerről van szó, amit az fstrim nem támogat, akkor oké, ellenkező esetben az fstrim jobb megoldás.
-
Frawly
veterán
válasz
Shyciii
#62171
üzenetére
Lehet ezek szerint a Linux is kezeli a FAT32-es boot partíciót. Bár szerintem akkor is felesleges. FAT32 az UEFI-nek kell, de az egész más fájlokat is tesz rá, .EFI végződéssel. Nekem ez az utánozzuk BIOS bootkor is az EFI partíciót nagyon gagyi hatást kelt. Működni működik ezek szerint, csak minek.
Abban biztos vagy, hogy nem UEFI-s lapos? Mert néha BIOS-os, karakteres felületes kinézetűek az UEFI-k, főleg régebbi notikon, és ebből valaki azt hiheti, hogy BIOS-os.
-
Frawly
veterán
válasz
Shyciii
#62162
üzenetére
Pedig ez lesz a megoldás, hogy up-ba tenni a kártyát. lsmod mit mutat, milyen ath-s modulok futnak? Kéne tudnia kezelnie azt az Atheros kártyát.
A bootra rosszul emlékezhetsz, mert FAT32 partíció pont az UEFI bootnak kell, de ha azt a géped nem támogatja, akkor FAT32 partíció sem kell. Ennek hiányában a /boot mehet a rendszerpartícióra vagy külön (nem FAT32-es, hanem ext4 vagy ext2) bootpartícióra.
Új hozzászólás Aktív témák
Hirdetés
A topik célja: Segítségnyújtás a Linux disztribúciókkal még csak ismerkedők számára. A szerveres kérdések nem ebbe a topicba tartoznak.
Kérdés előtt olvasd el a topik összefoglalóját!
Haladó Linuxos kérdések topikja.
Linux felhasználók OFF topikja
Milyen program ami... [link]
Shell script kérdésekkel látogassatok el a topikjába
- Vélemény Ubuntu 20.04 LTS
- Vélemény Linux Mint Debian Edition 4
- Tudástár MX-Linux 19
- Bemutató Linux a mindennapokban: Manjaro KDE
- Bemutató Linux a mindennapokban
- Hír Zöld utat adott a nyílt forráskódú Linux meghajtóknak az NVIDIA
- Hír A Steam Play hozza el a Windowsra írt játékokat Linuxra
- Hír Hova jut a világ? Linuxot kínál a Windows Store!
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Vírusirtó, Antivirus, VPN kulcsok
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- BESZÁMÍTÁS! ASUS ROG STRIX Z390-E GAMING alaplap garanciával hibátlan működéssel
- BESZÁMÍTÁS! ASRock Z370 i5 8500 16GB DDR4 512GB SSD 2060 Super 8GB Zalman Z9 Plus Enermax 750W
- Üzleti Fujitsu Lifebook u7510 15,6" FHD IPS 2021/08. havi gyártás
- Microsoft Surface Laptop 3 - 15 col - Fekete
- Országosan a legjobb BANKMENTES részletfizetési konstrukció! Lenovo ThinkPad X13 Gen 5
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest