- Honor Magic6 Pro - kör közepén számok
- Apple Watch
- Motorola Razr 60 Ultra - ez a kagyló könnyen megfő
- Motorola Edge 50 Pro - több Moto-erő kéne bele
- iPhone topik
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Apple iPhone 16 Pro - rutinvizsga
- A hagyományos (nem okos-) telefonok jelene és jövője
- Keretmentesít a Galaxy S25 FE
- Mobil flották
-
Mobilarena
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
Frawly
veterán
válasz
_kovi_
#31300
üzenetére
Azon kívül, amit a többiek írtak, én megjegyezném, hogy a scripted egy másik oldalról is sántít. Cselesen eltitkoltad, hogy milyen disztró, de pl. a legtöbb disztró systemd-s, és ott kiadod ezt a service parancsot, és képen vág egy service: command not found sorral, hogy a fal adja a másikat.
Látszik, hogy valahonnan összeollóztad a scriptet, kicsit bele is hegesztettél saját kútfőből, és az egész több sebből vérzik. Ez azért is veszélyes, mert ha még le is fut, ha nem jól van megírva, akkor más környezetben vagy egy újratelepített rendszeren nem fogod érteni, hogy miért nem működik.
-
Frawly
veterán
válasz
Sub-ZeRo
#31263
üzenetére
A legtöbb grafikus linuxos program és grafikus felület Gtk-s, LibreOffice, Firefox, Chrome (és azon alapuló megoldások, Opera, Vivaldi, Brave, FB Messenger, Skype, Visual Studio Code, stb.), Audacious, gedit, notepadqq, stb. De vannak Qt-sek is, VLC, qBittorrent, Clementine, Krusader, stb..
Ez a Gtk, Qt grafikus függvénytár, amit az alkalmazások használnak az ablakaik leprogramozására, témázására, stb..
Igazából, ha az Elementary vagy Clear bevált, azt is felrakhatod, hacsak nem a kalandvágy hajt, felesleges bonyolítani, meg újítani. Garuda is érdekes, bár az szerintem a haladóbbakat célozza. Zorint nem ajánlom, bloat, és túlwindowsosított, félig fizetős megoldás felé terelnek, akkor már ebben a műfajban jobb a Mint, Elementary. De ha csak a pénzbeli spórolás hajt, akkor a Win10 kulcs se drága azért a néhány ezresért, csak azért nem szoktam ajánlani a Linuxot, hogy az ember azt a kevés ezrest lespórolja. Pedig jobb a Linux, de csak akkor érdemes feltenni, ha tényleg eleged van a Windowsból, vagy szakmailag is akarsz fejlődni, érdekelnek ezek a szoftveres, informatikai dolgok. Tehát a meggyőződés hajtson, ne az a kevés ezresen spórolás.
-
Frawly
veterán
CentOS semmiképp, kő stabilan most fog megszűnni nem sokára, mindenki vált el róla. Ubuntu LTS még talán okés is lehet, de mint írtam, lehetőleg ne a Gnome-os főverzió.
Bár én eddig sem ajánlottam ezeket, mert szakmailag nem tartom őket jó disztróknak. Azóta becsatlakozott egy másik érv, ami miatt nem fogom ezeket ajánlani senkinek, az pedig politikai ok, a fent nevezett disztrókat kiadó, fejlesztő szervezetek jelenleg RMS üldözésének ürügyén verik szét az FSF-et, hátráltatják a free software ügyét. Már eddig sem állhattam ki őket a bloat, corporate szutykaik miatt (Unity, Gtk, Snap, systemd, pulseaudio és társaik), már számos alkalommal kifejtettem az ellenérzésem az LTS meg egyebek iránt, de ez a legvégső szög volt a koporsójukba nálam, és elég ahhoz, hogy innentől fogva elvi alapon sem fogom ajánlani senkinek.
Írom ezt annak ellenére, hogy engem mindig is hidegen hagyott a politika. Meg ha az ember elér egy szintet, akkor onnantól ez a disztrófetisizmus, disztróhoppolás is mindegyé válik, mert megtanulja bármilyen disztrón beállítani magának azt a grafikus környezetet, szoftveres körítést, workflow-t, amit megszokott. Onnantól a disztrók már csak frissítési-kiadási mechanizmusban, esetleg initrendszer, csomagszám/tükörszám tekintetében különböznek, a többi csak részletkérdéssé válik (installer, default beállítások és default települő csomagok, grafikus felület, téma).
-
Frawly
veterán
válasz
Sub-ZeRo
#31260
üzenetére
Az egy viszonylag modern Celeron, kb. korai mobil Core i3 proci szintje, ha tényleg 8 giga RAM-mal párosul, akkor azon minden normálisan elfut, Win10, akármilyen modern, bloat felületű Linux, Clear is támogatja. Én egyébként a kettő közül az MX-et preferálnám, de a Mate ellen sem tudok sok kifogást felhozni (egyedül a sima, gnome-os Ubuntu van ellenemre a Snap-ok erőltetésével, de ez a Mate-es változatban nincs benne tudtommal). Igazából mindegy, tedd fel azt, ami szimpatikusabb, ha nem jön be, bármikor lecserélheted. Linuxot gyorsabb telepíteni, újratelepíteni, mint Windowst. Akár még Elementary, PopOS, Mint vagy Arco Linux és Manjaro is játszhat, szintén a neked tetsző felületű kiadás, attól függően, hogy milyen felületet preferálsz, többségében Gtk-s vagy Qt-s progikat használnál-e rajta, eddig mit szoktál meg, mennyire akarod, hogy hagyományos windowsos desktopszerűség legyen, stb..
-
Frawly
veterán
válasz
Sub-ZeRo
#31258
üzenetére
Ebből bármelyik jó. Én leginkább az MX-et mondanám, mert az alapból Xfce-s, és systemd-nélküli, így a háromból a legsoványabb megoldás. De az Ubuntu Mate sem vészes.
A Clear Linux határeset, az is jó lehet, ha nem túl régi Celeron, mert a Clear csak az újabb procikat támogatja, az elmúlt 10 évből, meg alapból eddig Gnome-mal jött (bár lehet újabban grafikus felület nélkül települ, és neked kell grafikus felületet telepíteni rá, olyat, amilyet akarsz). A Gnome erőforrás-igényesebb, mint a fentebb említettek, de még talán elfut cerkán is.
Igazából itt az dönt, hogy te melyiket ismered, melyiknek a felülete jön be legjobban. Annyira egyikkel sem tudsz mellényúlni.
-
Frawly
veterán
válasz
attilav2
#31256
üzenetére
tar -cJvf cde-backup.tar.xz ~/cdesktopenv-codeBár az sem tragédia, ha nem binárisként mented, hanem mindig lefordítod, és csak a forráskódját mented egy scripttel, ami a fordítás csinálja gcc-t meghívva, make, stb.. Nincs egy nagy kódbázisa, modern gépen pillanatok alatt fordul. Egyedül csak akkor látom értelmét a bináriskénti mentésnek, ha ilyen Ubuntu és CanonRedHatBullshit disztrókon akarod használni, amiken a fordítás a csomagkiosztás és régi csomagverziók miatt nehézkes.
-
Frawly
veterán
Szerintem nyugodtan írhatod a regisztrációs kérelmet nem céges mailfiókból is. Én is úgy regisztráltam a HUP-ra, hogy senki nem ajánlott, és nem céges, hanem sima gmail.com-os fiókból. Említsd meg, hogy más IT fórumokon 2004 óta regisztrálva vagy, több ezer hozzászólással, nem volt veled probléma, és X éve linuxozol, írd meg a valódi neved, és hová valósi vagy. Ennyi nekem elég volt pár éve.
Én megpróbálhatlak beajánlani, bár lehet úgy nem lesz valami hiteles, hogy nem ismerlek, és nem lesz az ajánlásnak alapja. Ezt az ajánlást nem is tudom hogy kell megejteni, nekem kell írni valami e-mailcímre, vagy neked kell az ottani nickem (Raynes) említeni, vagy hogy megy ez, nincs sehol írva, nem ajánlottam még be senkit.
Mindenesetre szerintem az oldalgazda feleslegesen izmol ezzel az e-mailezős, ajánlós rendszerrel. Nyugodtan mehetne sima online formos reggel, azt a napi pár spambotot egyszerűbb lenne kitiltogatni, nem engedélyezni, mint ilyen pitizős e-maileket elbírálgatni. Annyira nem forgalmas oldal, hogy ne férne még 10× annyi user. Plusz ha valaki úgyse tud hozzászólni szakmai dolgokhoz, meg rendbontó, az úgyis gyorsan kiderül, ráér akkor törölni a nem kívánt regisztrációkat.
-
Frawly
veterán
válasz
ubyegon2
#31231
üzenetére
Nem kell feltétlen Kali, meg Parrot, hanem bármelyik sztenderd disztró tárolójában megtalálhatók ezek a toolok, csak ki kell nyomozni, hogy mi való rá, ami ingyenes, opensource megoldás. Ez az, amihez én is lusta vagyok, főleg, ha csak valamihez egyszer kell.
A Hirens előnye, hogy fut róla minden Live módban, telepítés nélkül is. Régen én is szerettem (egy ideig volt tartva Hirens-es pendrive is), de mióta áttértem Linuxra, felesleges a Hirens, amit az tud, ilyen partíció, fájlrendszerjavítás, mentés, azt a legtöbb disztró Live-ja is simán megcsinálja. Még ilyen windowsos, jelszótörős mókákat is, csak akkor ki kell nyomozni a natív linuxos alternatívát, az már nem szokott default telepítve lenni a Live rendszerekre, hacsak nem Kali tényleg.
A Parrot viszont neked tökéletes, megy a kalózos avatarodhoz
A 2 gigás pennel nem az a gáz, hogy csak 2 giga, vagyis az is, hanem hogy emiatt feltehetőleg egy régi, szutyok lassú, USB2-es drive. Erre tényleg senki ne sajnálja a pénzt, 16 gigás USB3-as penek is jelképes áron mennek, de még egy 60-128 gigás SATA2-SATA3 SSD is kihozható ugyanannyiból, USB-SATA átalakítóstól, és az állva hagy akármilyen szokvány tollhajtányt, és még rendes Linux telepítésre is használható, vagy Windows To Go telepítésre, és gyors is, mint egy belső SSD. 2 gigás pennel ne szenvedjen már 2021-ben senki se. Sok disztró és OS telepítő már 4 giga felett van amúgy is.
-
Frawly
veterán
válasz
bugizozi
#31228
üzenetére
Szerintem túlbonyolítod. Ha alapvetően jól hallasz a BT headsettel, akkor lehet csak annyi kéne, hogy a grafikus hangerő-szabályzóban (pavucontrol) a bemeneti eszközöknél átállítod, hogy ne a laptop mikrofonját használja, hanem a BT eszközét.
#31227 PeachMan: ja, ez nagyon jó ötlet, nekem sem jutott volna eszembe. Alapvetőn a Hirenst nem tartom sokra, de egyszerű jelszótöréshez tényleg lehet, hogy most a legjobb, legegyszerűbb megoldás, nem kell külön rar jelszótörőt keresgetni, meg warez oldalakról kétes windowsos dolgokat levadászni, meg szutykokat feltelepíteni. Persze könnyen meglehet, hogy ha türelmesen utánanéznék, találnék rá natív linuxos opensource alternatívát, ami simán töri a Rar3-at, de összességében tovább tartana, mint egy Hirens-en alapuló gyors partizánakció. Natív, tiszta megoldást akkor érdemes csak kikísérletezni, ha többször fog kelleni, nem csak egy egyszer.
-
Frawly
veterán
válasz
#68216320
#31216
üzenetére
A Rar-verzió csak azért érdekes, mert a 3.x-ig egyszerű CBC-s eljárással titkosított a Rar, meg a WinRar is, és a 4.x-től álltak át AES-re. Ha tényleg 3.80-assal csináltad, akkor mákod van, könnyen törhetőnek kéne lennie, a megfelelő célszoftverrel másodpercek. És azért írom így általánosságban, mert bár csináltam ilyet, hogy 3.x-es .rar archivumról oldottam le a jelszót, de évekkel ezelőtt volt, és akkor Windowst használtam, és arra kiadott célszoftverrel törtem, talán valami Rar Password Cracker vagy már nem is tudom mi volt a neve, pár mp. alatt simán nyitotta az archívumot. Linuxon nem tudom melyik natív tool jó erre.
Az AES256-os zip törése elég reménytelen viszont. Persze, meg lehet próbálni, de mivel csak brute-force lehet, az elég sokáig fog tartani, kivéve ha 12345 vagy password vagy ilyesmi blődség a jelszó.
-
#31214
Frawly
veterán
Speeedfire
#31211
Frawly
veterán
válasz
Speeedfire
#31211
üzenetére
Maga a fájlrendszer, amin az illető fájl van, csak írásvédetten, read only flaggel lett csatolva, vagy mert eleve így volt beállítva, vagy valami fájlrendszerhiba miatt csatolta így. Csatold fel újra, rw módban.
-
Frawly
veterán
válasz
#68216320
#31209
üzenetére
Szerintem nem éri meg erre időt pazarolni. Zip-nél attól függ, hogy milyen Zip progi jelszavazta, milyen titkosítással, Rar-nál meg hogy milyen régi volt a tömörítő. A modern Zip progik (pl. 7-zip), meg a 3-asnál újabb Rar AES-t használ, min. 128 bit, néha 256 bit, plusz pár bites kulcserősítés, így nagyon hosszú brute force-szal törni őket, nem nagyon éri meg. Ha meg is csinálod, akkor se a nyereségvágy, hanem csak a tanulás, szakmai kíváncsiság hajtson.
De ha régi fájlok, amiket régi Zip, főleg pkZip, WinZip csomagolt, meg régi Rar, azokat elég könnyen törik kulcsrakész megoldások, pár másodperce egy átlag desktop gépen.
A Zip-pel a legnagyobb baj, hogy nem biztosan szabványos. Ahány Zip progi, annyi féle megoldást használnak. Rar-ból legalább csak egyféle van.
-
Frawly
veterán
válasz
CPT.Pirk
#31195
üzenetére
Gondolom lassú rajta a NAND, és a kernel a ramcache-ből próbálja rányomorgatni az adatokat, de egyre belassul fizikailag a drive, nem küld visszajelzést, a rendszer meg csak vár-vár rá. Nekem még USB3 adapteres SATA2-es SSD-vel is volt ilyen, pedig az gyorsabb, mint egy pendrive. Ez ilyen, ha nem villám meghajtók, meg tudnak feküdni nagy írásmennyiség után, nem mindig abszolválják.
-
Frawly
veterán
válasz
Predatorr
#31178
üzenetére
Nincs támogatása, mert zárt drivert igényel, amit a legtöbb disztró elvi okból nem tartalmaz. Elérhető rájuk, de akkor neked kell tárolóból feltelepíteni csomagkezelővel, utána jó lesz. Van rá támogatás, de nem alapból. Ha annyira bánt, próbáld meg a PopOS-t, az is épp úgy Ubuntu-alapú, ahogy a Mint, és a PopOS-nek van eleve Nvidiás lemezképe, ami alapból tartalmazza a szükséges drivert.
Az a tunerkártya viszont probléma lesz. Annyira, hogy a neten infót se találok róla, windowsos drivert se, nem hogy ellenőrizni tudja a linuxos támogatást. Nem állítom biztosra, hogy nem fog menni, de nagy rá az esély, hogy az semmilyen disztró alatt nem mukkan meg semennyire.
-
Frawly
veterán
válasz
Predatorr
#31160
üzenetére
Egyik alaplaphoz sincs Linux driver, mert nem kell. Az alaplapon lévő chipsetekhez, SATA vezérlőhöz, stb. meg szokott lenni, eleve beépítve a kernelbe, neked semmilyen extra drivereket nem kell keresni. Az alaplapon sem kell semmit állítani, defaultra se ajánlott, mert az szétcseszheti a Windows bootolását. A tv-tuner viszont kapásból problémás lehet, azokhoz inkább többször nincs driver, mint van.
Jó lenne tisztázni a géped konkrét paramétereit, mert az az érzésem, hogy NV kártyád van, és a Mint nem tudja a default lemezképen meghajtani. Meg kéne próbálni a telepítőt safe módban indítani (a Mint bootmenüjében) ahol megpróbál más videódrivert használni, ezt elég csak a telepítés idejére.
Ha akarod, a PopOS-t meg megpróbálhatod. De azelőtt tisztázni kéne a gép paramétereit, mert ha tényleg NV kártyáról van szó, akkor eleve PopOS-ből is a NV-s lemezképet kéne kapásból letölteni. A GPU pontos típusát emiatt nagyon kéne tudni ahhoz, hogy megoldást javasoljunk konkrétan.
-
Frawly
veterán
Én a hibakimenetet nem irányítanám a /dev/null-ba. Értem miért tetted bele, hogy ha valami olyat talál a find, amit nem tud megnézni, akkor ne dobogasson zavaró hibaüzenet. De én ha ilyen futtatok, szeretném látni, hogy mit nem tudott listázni, törölni, és mit tudott. Valahogy jobban érzeném magam, ha tudom mennyire volt sikeres a művelet.
#31154 Fecogame: egyszerűbb megoldás mindig van, de elég relatív, hogy megéri-e, mit kell hozzá feltenni, mennyi időd van a projektre, stb..
Mert ha pl. az adott mappán belül csak 1 szint mélységben akarod, és fent van valami kétpaneles fájlkezelő, azok tudnak olyan, hogy lemérik a mappák méretét, majd méret alapján csökkenő sorrendbe rendezed, és kijelölöd a nullás mappákat majd törlöd. Van, akinek ez egyszerűbb, mert nem kell egy parancsot hosszabb paramétereznie. De szerintem ez a find a leghatékonyabb, persze kezdő felhasználónak nem ajánlom, mert elgépel valamit, és valami olyan mappáját darálja be, amit nem akart, akkor könnyen bőgés lehet a vége.
-
#31149
Frawly
veterán
zsigomark3
#31147
Frawly
veterán
válasz
zsigomark3
#31147
üzenetére
Nem értem mit nem értesz. Először neked kell megírni a JSON fájlt kézzel, már ha én nem értem félre az általad linkelt oldalakat. Itt találsz egy mintafájlt, amit át tudsz alakítani. Nem muszáj a /usr/akármi/-be mentened, használhatod a felhasználód /home/felhasználónév/ mappáját is, akkor nem kell sudo-zni sem.
Addig a builder neked nem csinál semmit, míg a JSON fájlod be nem adagoltad neki. Esetleg az a baj, hogy a fájlt megcsináltad neki, de txt kiterjesztéssel, és ehelyett metadata.json néven és végződéssel keresné.
-
Frawly
veterán
válasz
totron
#31144
üzenetére
Nálam még tartja magát, hardveres videókódolás az nincs, csak hackre és bugos, úgyhogy nem erőltetem, de nem jelent nagy prociterheléses különbséget. Nekem még megfelel, de régóta nem szeretem már én se, azon a határon táncol, hogy dobjam. Ami miatt megtartom, hogy még így is a kisebbik rossz a Chrome-alapú böngészők ellenében.
Próbáltam egy időben Chrome-ra, Chromiumra, Vivaldira váltani, de borzalmas memóriaigényük van, és bugosabbak is, mint a FF. Plusz nem tudnak olyan alap funkciót még ma sem, mint a text only zoom, tudnak általános text-skálázást, de csak átlalánosan, minden oldalra megadva.
-
Frawly
veterán
válasz
attilav2
#31142
üzenetére
Ebben nincs meglepő, aki ért hozzá, már évek óta figyelmeztet arra a veszélyre, ha az egész webet meg az összes böngészőt a Google uralja, abból baj lesz, el fog velük szaladni a ló, és miután már minden az övék a weben, minden böngészőt az ő motorjuk hajt, akkor bármilyen pofátlanságot megengednek maguknak. A monopólium sose jó, ezért ajánlott inkább Firefoxot használni, van ahhoz is egy csomó jó addon, kevesebb memóriával is beéri. Az sem tökéletes böngésző, de legalább nem a Google-monopóliumot támogatja vele az ember, mint a Chrome, Chromium, Opera, Brave, Vivaldi, stb. böngészőkkel.
-
Frawly
veterán
Lenne itt egy dolog, ami nem probléma, csak nem értem. Néhány disztrómon, gépemen a feh úgy működik, hogy mikor háttérképet állítok vele, a háttérkép megjelenítése után tovább fut a feh process, látszik a folyamatok listájában. A mostani Arch + dwm-es telepítésemnél viszont azt tapasztaltam, hogy indul a feh, kiteszi a háttérképet, de aztán kilép, nem fut tovább, persze a háttérkép az mégis kint marad. Persze, ez egy jó dolog, tetszik, csak nem értem, hogy egyik rendszeren (pl. Artix Linux + Openbox) futva marad, a másikon meg nem. Ez mitől függ? Nem sikerül megfejtenem, egyfajta rejtély.
Ráadásul az sem gond, ahogy indítom, mert mindig & jel van utána, tehát elvileg az indítóscript nem várja be, míg bezáródik. Amire még tippelek, hogy jelenleg az ~/.xinitrc-ből fut, míg Artixon az Openbox ~/.config/openbox/autostart moduljából indítja, ez lenne az oka? Nyilván, a dwm-nek nincs autostartja, így tesztelni nem tudom.
-
Frawly
veterán
válasz
bambano
#31097
üzenetére
Ez így kevés. Addig amatőrnek számítasz, amíg legalább 128 routing táblád nincs, mert az a mennyiség már egymagában elő-routing-táblát igényel a többi routing tábla elé
Persze, azért életszerű a 17 hálózati kapcsolat is, szóval valamilyen szinten tekintsd magad megdicsérve.
És akkor én itt vagyok 1 hálózati kapcsolattal, de az is olyan szarul működik, hogy tekintsük 0,5-nek, de egy komlett routing tábla azért dukál neki
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Frawly
veterán
válasz
Frawly
#31091
üzenetére
Már megvan némileg a másik fele is, az alock nevű progi tudja az alábbi paraméterekkel:
alock -b none -c blank -i noneEzzel megmarad a kép, eltűnik az egérkurzor, és látszólag nem reagál a progi, mikor a jelszót kéri be.
Az viszont még mindig nincs megoldva, hogy ha konzolt hagyok ott, akkor abban a zárolást hogy lehetne automatizálni.
-
Frawly
veterán
Az ideiglenes konzolváltás elvétele megvan, futtatni kell a setxkbmap srvrkeys:none parancsot, majd a zárolás feloldásának végeztével:
setxkbmap -option && setxkbmap -option újrakonfigurálás...A képernyő érintetlenül hagyására viszont még nincs módszer. Egyelőre az suckless-féle slock forráskódját tanulmányozom, hogy a képernyőt módosító részt kiszedjem.
De még ez se biztonságos, mert tegyük fel be vagyok jelentkezve az X-be, de mellette épp egy megnyitott tty konzolon vagyok, és úgy felejtem úgy a gépet. Erre lehetne azt, hogy előbb megnézem, milyen tty-ban futunk, és ha az pts, akkor az X-es zárolást kapcsolom be, ha nem, akkor vlockot. Jól gondolom?
-
Frawly
veterán
Fura kérdéssel hozakodok elő: X vagy konzol alatt az input eszközöket akarom csak blokkolni, a képernyőt nem. Magyarán screenlock kell, de úgy, hogy a képernyőt nem blokkolja.
Eddig erre az X alatt futó WM-hez picom kompozitort használtam, és i3lock-ot, amit picom-ban teljesen transzparensé tettem. Így zárta is a munkamenetet, de mégis lehetett látni azt a teljes képernyős terminálban futó ASCII screensavert, amit kitettem. De most minimalizmusból dobtam a kompozitort, így nincs átlátszóság (a vsync-et megoldottam a X.org konfigjában TearFree kapcsolóval).
Az a baj, hogy a szabványos screenlockerek kitakarják a képernyőt is. Nekem csak olyan kéne, hogy az input eszközöket blokkolni, míg valaki a futtató user vagy a root jelszavát be nem írta.
A másik, szintén kapcsolódó kérdés, hogy hogyan tudnám ideiglenesen elérni, hogy lockolt X mellett ne tudjanak konzolra váltani? Itt hangsúly az ideiglenességen van, míg lockolás van. A neten csak olyan módszert írnak, ami a X.org konfigban állandóra tiltja le a virtuális konzolra váltást, de az meg hasznos, ha beszarik az X, akkor is tudok konzolra váltani.
Az vlock majdnem jó lenne, mert az a konzolváltást is lezárja, de a képernyőt az is kitakarja, letörli. Én azt akarom, hogy a lockoló a képernyőhöz ne nyúljon hozzá. PAM támogatás sem feltétlen kell bele, csak figyeljen a feloldó jelszóra.
Ezekhez tippek?
-
Frawly
veterán
válasz
Frawly
#31073
üzenetére
Itt valami az Artix Linuxszal lesz mégis, mert az ntp nevű SNTP progi se tudja korrigálni az időt, pedig meg lettek neki adva kapcsolók, hogy akármekkora időkorrekciót csinálhat, nem csak időlassítással, de konkrét időbeállítással is. Prioritást is legmagasabbat kapott, sudo-val futtatom, nem tudom mi a bánatot tehetnék még, hogy a gép óráját állítsa, továbbra is 34 mp.-et késik. Ilyet még nem pipáltam.
Szerk.: végül a sudo hwclock -s parancs helyretette. Valami miatt hiába állította a rendszerórát, az nem vezetődött át a tényleges hardverórába. Csak azt nem értem, hogy ezzel a 2020-ban miért nekem kell kézzel ×4rakodni, mi a fészkes bánatért nem tudja az NTP kliens megcsinálni, ha egyszer rá van parancsolva, hogy állítsa azt a genya órát a bránerbe.
-
Frawly
veterán
NTP-ből milyen implementációt ajánlanátok Linxura? Eddig évekig a disztrók saját megoldása mellé OpenNTPD-t raktam fel, ezt néha kézzel futtatva ellenőriztem és korrigáltam az esetleges eltolódásokat. Nagyon szépen bevállt, de mostanra tönkretették. Kivettek belőle egy csomó kapcsolót, lebutították a kimenetét, meg elkezdte az órát se állítani, most pl. 34 másodperccel van lemaradva a gép órája, ami önmagában nagyon durva, erre azt írogatja a sudo ntpd -d, hogy:
cancel settime because offset is negative or close enoughJa, 34 másodperc az close enough, hogy cumiznának le fejen állva. Igaz ha várok, hogy lépjen valamit, akkor hosszabb idő után kiírja, hogy adjusting local clock by 34.587829s, de nem adjustozik lófütyköst sem, 1 óra futás után is 33-34 mp. az eltolódás. A nettel nincs probléma, eléri az uk.pool.ntp.org helyi NTP szervereket, válasz is jön, fel tudja oldani a neveket, tehát nem az, hogy nem férne hozzá az időhöz, hozzáfér, meg látja is a valós eltolódást, de cseszik működni.
Mit lenne érdemes feltenni helyette? Lehetőleg olyan, amiben minél több feature van, és kézzel is ki lehet erőszakolni az óraállítást, ami nem ajánlott, de néha szükséges lehet meglépni.
-
-
Frawly
veterán
válasz
bambano
#31058
üzenetére
Mate-et nem használok, de a legtöbb DE-nél elég a ~/Desktop/ mappát elmenteni, az új rendszerre meg bemásolni a home-odba. Tálcaikonokra passz, max. arra a workaroundra gondolok, hogy kézzel lehúzgálod őket az asztalra, és így mented őket, az új rendszeren meg visszahúzgálod a panelra. Esetleg egy terminálban futtatsz lsof vagy iotop valamelyikét, és hozzáadsz a panelhez egy új alkalmazást, megnézed melyik mappába írja a fájlt, és mented azt a mappát.
Ha a 10.6 Debian akar lenni, akkor szerintem nem kell semmit költöztetni, felveszed bele a testing tárolókat, nyomsz egy frissítést, és elvileg működnie kéne.
-
Frawly
veterán
válasz
Dißnäëß
#30875
üzenetére
A DeaDBeeF jó. Évekkel előtte is próbáltam, de akkor keveset tudott, most már felfejlődött az utóbbi években. Alap konfigban fapadosnak tűnik, ezért rá kell szánni az időt a konfigolására, felpluginezésére.
Ezeknek a formátumoknak nagy része, amit írtál, lossless amúgy is, meg az encoderekeik átveszik akárhonnan a tag-eket, úgyhogy ha ezek közül konvertálsz, akkor mindegy mivel konvertálod, akár még terminálból is csinálhatod. Egyedül a DTS 5.1 lehet, ami nem triviális, meg az mkv, mka konténerekből sáv kiszedése.
Open Cubic Playert sajnos nem tudom telepíteni, mert csak AUR-ban van, és az egyik komponenséhez kéne egy olyan GPG key, amit nem tud befogadni a csomagkezelő, szóval bukta. Bár lehet valami régi binárist valahonan össze tudnék vakarni, de annyit nekem nem ér meg.
Egyébként az AIMP ellen sincs olyan sok kivetni valóm, sokáig használtam telefonon, utóbbi időben csak azért nem használom, mert nem tud közvetlen digitális kimenetet Androidon, így meg nem tudja rendesen meghajtani a külső DAC-om. Windowoson még nem próbáltam. Ami bajom van vele: a Linux nincs a támogatott natív platformok között.
-
Frawly
veterán
válasz
Dißnäëß
#30869
üzenetére
Ja, az már tényleg beteges, ha minden Wine-ban fut, ráadásul duplán, Snap-pal súlyosbítva. Konvertálni tényleg DeaDBeeF-fel érdemes, mert abban fel lehet venni konvertálási profilokat, mint foobar2000-ben és be lehet neki adagolni külső encoder-eket, saját paraméterekkel, így ellenőrzés alá tudod vonni, hogy hogyan konvertál, biztosan nem gányol-e. Illetve könnyű így egész lejátszási listákat, diszkográfiákat konvertálni, tag-eket is normálisan átviszi konvertáláskor, illetve a tag-ek tömegesen is kényelmesen szerkeszthetők, egységesíthetők. Én is csak erre használom a DeaDBeeF-et, konvertálásra és tag editornak, zenét nem nagyon hallgatok vele, arra mpv, esetleg cmus. Kivéve, ha csak 1-1 audiofájlt konvertálok, mert akkor kézzel, terminálból konvertálom, vagy saját encoderrel (lame, oggenc, opusenc, stb.), vagy ffmpeg-gel (ha pl. videóból szedem ki a hangsávot, vagy webm-ről konvertálok más konténerbe).
Cubic Playert lehet én is felteszem, nem is tudtam, hogy Linux alatt is megy Open Cubic formájában. DOS alatt én is nagyon sokat használtam a 90-es évek végén, nagyon kora 2000-es években, és eléggé szerettem.
-
Frawly
veterán
válasz
Dißnäëß
#30858
üzenetére
Ebben egyetértek, a szoftverek meg felhasználói interface-ek sokszor mára már visszafejlődtek, primitív tabletes flat dizájn, lebutított grafikus felületek (asztali ikonok, stb. támogatásának megszüntetése), böngészőket is lebutították ezzel a webextension API-val, így sok régi plugin nem meg (pl. vim-es pluginek), funkciókat vettek ki, mint a több soros fülsáv.
Hála istennek ezeket nem kötelező használni, a Linux pont arról szól, hogy nem kell a nagy butított felületeket és a Chrome-alapú böngészőket használnod, feltehetsz mindenből saját megoldást, széthekkelheted, pluginelheted. Pl. ez a jó a minimialista WM-ekben, nem csak hogy kisebb erőforrást esznek, de ha megdolgoztál vele, beállítottad, akkor elég 1 szál config fájlt menteni, és egy életre megmaradnak a beállításaid, nem kell újrakonfigolni, nem vesznek ki belőle feature-öket, függőségük is minimális ezeknek, mennek minden disztrón.
-
Frawly
veterán
válasz
Archttila
#30857
üzenetére
Wow, ezt nem tudtam, hogy ez a clsid2 már fork. A forkokat illik átnevezni, pl. MPC-HCE vagy -HCR, mint Home Cinema Extended, vagy Home Cinema Reloaded. Ez így zavaró, hogy név alapján a forkot és az eredetit nem lehet megkülönböztetni. Mindenesetre a BE-t jobban ajánlom, mert az több fejlesztést kapott meg az utolsó 3 évben. Meg ezt nem írtam, de ezeket csakis Windowsra ajánlom, csakis olyan usernek, aki ókonzervatív, és ő meg akarja mutatni, hogy ő modern lejátszót nem használ, mert ő nem fog haladni a korral, mert ő különleges, mert ő majd megmutatja ki a legény a gáton. Értelmes ember feltesz modern lejátszót, mpv-t, SMPlayer-t mpv-vel, vagy VLC-t, vagy hasonlót, meg foobar2000-et és az egész ilyen fork, nem fork, WMP vs. MPC vergődést maga mögött hagyja.
-
Frawly
veterán
válasz
Dißnäëß
#30854
üzenetére
Már pedig a Deadbeef tud ilyet, csak alaptelepítésben valami nagyon fapados konfiggal jön, és nincsenek benne telepítve pluginek. Nagy munka testreszabni, de ha megcsinálod, akkor 99%-ban hozza a foobar2000 tudását.
Snap-pal az a baj, hogy rohadt bloat, konténerizált, 50-100× akkora csomagok vannak benne, mint a natív csomagok mérete, és biztonságilag is problémás, meg az lsblk és mount kimeneteit is használhatatlanná teszi a sok kamu csatolásával. Semmi szükség nincs rá, bármilyen disztró alatt, simán a hivatalos tárolóban (értsd úgy, hogy a hivatalos multilib tárolóban, ami nem mindig van default engedélyezve, kézzel kell engedélyezni) lévő natív Wine csomagot telepítve, Wine-ban mindenféle trükközés nélkül lefut a foobar2000 installere, ami feltelepül és működik. Nem kell hozzá semmilyen Snap, ezt az Ubuntu elhiteti veled, hogy kell, meg most ez a menő, meg a hájp, de igazából nem kell, a többi disztró eddig is elvolt nélküle, ezután is el lesz nélküle.
Snap-ot csak annak ajánlok, aki nem talál meg egy adott linuxos szoftvert máshol, nem csak a hivatalos tárolókban nem találja, de külső tárolókban se, meg natív külső csomagokat se talál weboldalon (pl. .deb vagy .rpm csomag), forráskódból forgatáshoz meg vagy a tudása nincs meg, vagy a gépe túl ergya, akkor, és de csakis és kizárólag akkor lehet értelme Snap-pal próbálozni, magyarul ha minden törik-szakad. De Wine van minden disztrón Snap nélkül is, és abban működik a foobar2000 mindenféle Snap nélkül.
-
Frawly
veterán
válasz
Dißnäëß
#30850
üzenetére
foobar2000 Wine-ben futtatása helyett ajánlom a DeaDBeeF-et, ami foobar2000-klón, épp úgy, ahogy text editoroknál a Notepad++ klónja a notepadqq. Esetleg ha valaki Winamp-klónt akar, akkor QMMP vagy Audacious. Illetve jó még a Clementine és egyéb Amarok-forkok, pl. Strawberry. Én nem szeretem őket, de vannak hívei a Rythmboxnak és a Banshee-nek is. De már olyanról is olvastam, aki a Spotify-klienst preferálta, mert az multiplatformos, és lejátszik helyi médiatárból is.
Én már nem is használok zenelejátszót, mert ritkán hallgatok offline zenét PC-n, mikor nagy ritkán mégis, akkor mpv-vel nyitom meg őket, ahogy a videókat is. Utoljára mikor még volt fent dedikált zenelejátszó, akkor cmus-t használtam a terminálos minimalizmus jegyében. Előtte mpd+ncmpcpp kombót, de az nem valami felhasználóbarát, bár a legjobban az pluginelhető meg hekkelhető az összes zenelejátszó közül, amolyan hardcore bázis alakult ki körülötte.
Ha valaki a foobar2000-nél is marad, akkor se Snap-ból telepítse, mert az teleszemeteli szutyokkal a rendszert, helyette Wine-ban kézzel, vagy Winetricksben menüből tegye fel, úgy is teljesen jól működik. Snapból csak akkor érdemes telepíteni a kényelem és lustaság jegyében, ha eleve olyan bloat disztrót használ valaki, ahol alapból telepítve van a Snap, pl. új Ubuntu.
#30851 ubyegon2: én nem ismerem a kollégát, vagy igen, de akkor nem emlékszem már rá. Próbálok azért korrekten reagálni a kérdésére, bár a WMP9-nél gyanút kellett volna fognom. A WMP9 egy vicc, használtam anno egy rövid ideig, XP-n, kb. 15 éve, egy-két olyan formátumhoz, amit akkor nem vitt normálisan a Media Player Classic és az ahhoz tartozó codec-pack. Aztán a hwsw-n egy haladóbb emberkének megesett rajtam a szíve, hogy ilyen fostos codecpakkokkal és WMP-trágyadombokkal küzdök, és megmutatta az mplayer-t, később felfedeztem ahhoz az SMPlayer frontendet és ezt használtam évekig, Linuxon is. VLC-t is próbáltam, de az sose jött be. Mióta meg van mpv, és itt a PH-n valaki ajánlotta, vagy gyurmafigura, vagy kékluficet, azóta azt használom, annak is van már jó 4 éve vagy több. A WMP egyébként a legrosszabb médialejátszó, amit valaha használtam, akármilyen platformon, pedig Androidon is próbáltam már 1-2 nagyon undorítót. Mondjuk úgy, hogy WMP-nél minden jobb. Talán a maga korában az első két verziója a Windows Media Playernek nem volt rossz, de akkor még mplayer-nek és mplayer2-nek hívták. Bár még az 3-5.x-es verziói is tűrhetőek voltak, azok még Media Player néven futottak (ezek ihlették a Media Player Classicot is), az 5.1-5.2 az Microsoft Media Playerként. Onnan lett teljesen használhatatlan, ahonnan elkezdett Windows Media Player néven kijönni, főleg a 8-as verziótól kezdve, ami az XP-vel jött. Azóta rémálom. Az új verziók még inkább. Bár a legeslegutolsót, a 12-est még nem is próbáltam, ahogy látom screenshotokon, a foobar2000-re hajaz már, de csak felszínesen, tudásban gondolom sehol nincs ahhoz képest. Win10 alatt egyébként a foobar2000-et teszem fel, ha kifejezetten zenelejátszó kell, ha nem kifejezetten zenére kell, akkor ott is mpv, amivel a videókat játszom le.
A kollégának ezt a WMP9 fetisizmusát azért sem értem, mert az az SP1-SP2-es XP-n volt csak használható. SP3-mal, ha erre felfrissítette legalább valaki, már a WMP10 jött, Vistával és attól felfelé meg WMP 11-12, és ezeket már nem lehet downgrade-elni 9-esre. Ha valaki ennyire ókonzervatív, akkor is zenére minimum Winamp, videóra meg minimum Media Player Classic Black Edition (MPC-BE), vagy MPC-HC (ezt nem nagyon fejlesztik már).
-
Frawly
veterán
válasz
inf3rno
#30818
üzenetére
Nem, a hibás szektor nem jelent rossz kondíciót. Főleg, ha a vezérlő nem detektálta a hibát még. HDSentinel minősítései kb. semmit nem érnek, csak tájékoztató jellegűek. Sokszor irkál totál baromságot. De maga a SMART se ér sokat. Jelezhet előre meghibásodást, de sokszor van, hogy semmit nem jelez, 100%-osnak látszik a meghajtó, semmi hibára utaló bejegyzés, vagy attribútum, erre egyik napról a másikra megdöglik és tégla lesz belőle. A SMART csak egy ilyen +1 védelmi vonal, ami esetlegesen jelezni tud. Plusz ma már egyik tároló sem megbízható, mióta agyonolcsósították ezeket, redundanciának és/vagy biztonsági mentésnek mindig lennie kell, utóbbi még user errornál is jó, ha valaki beszop egy ransomware-t, vagy letöröl/felülír valamit véletlenül, akkor legyen hova nyúlni, ne bőgés legyen, hogy jajjazadataim, azonvoltanemtudomén, pótolhatatlan, brühű.
-
Frawly
veterán
válasz
sh4d0w
#30816
üzenetére
Igen, ebben biztosan igazad van. Hagyják benne a tömbben a marginálisan jó lemezt, növelve az esélyét, hogy egyszerre több diszk is kidögöljön a tömbből. Mert egy ilyen diszket benne hagyni felesleges rizikó. Azt értem, ha tönkremegy, akkor cserélik, és újraépül a tömb, de nem kell megvárni, míg kileheli ténylegesen is a lelkét, azért van a SMART kitalálva, hogy lépni lehessen már akkor, amikor gyengeségek mutatkoznak.
-
Frawly
veterán
A HDD nem jelöl meg semmit. A HDD-n lévő vezérlő tudja detektálni, ha egy szektor hibás, akkor általában tud cserélni a tartalék területről, egy másik szektort befog helyette (reallocated sector). De ilyen reallocated-es HDD-t már szerveres felhasználásnál nem szoktak megbízhatónak minősíteni, pedig adott esetben még évekig működhet. Az, hogy van-e reallocated szektor, azt a SMART-ban lehet megnézni.
Hagyományosan a rossz szektort az OS is tudja detektálni, hogy az írási-olvasási műveletekre nem jön vissza adat. OS függő, hogy ilyenkor milyen megoldást alkalmaznak. Linux nem csinál semmit, de meg tudod jelölni a szektort fsck futtatásával, olyan opcióval, hogy végigteszteli a meghajtó felületét, és a rossz szektorok listáját frissíted vele. Ugyanezt csinálta a DOS, de az csak formázáskor. A Windows valószínű meg tudja jelölni hibás szektornak, lefuttat rá egy belső scandisk-et, és a fájlfoglalási táblákban nem használja ezt a szektort, kivezeti az erre hivatkozó bejegyzéseket.
De más rétegek is detektálhatják, hogy adatvesztés volt, ha nem stimmel valami checksum, parity, más integritásmutató.
-
Frawly
veterán
válasz
Dißnäëß
#30810
üzenetére
De válasz a kérdésre, csak nem értelmezed. A HDD-n kelekezik hibás szektor. Esetedben LUKS-on fut ZFS zraid, ezek közül a LUKS-on már adatvesztés lehet, de a ZFS zraid redundanciával lehet ezt ki tudja védeni, ha újraépíted a tömböt.
De ha nem ez lenne a felállás, akkor az OS nem is tudna róla, hogy hibás szektor van, mert egy alsóbb réteg gondoskodna a hibajavításról.
-
Frawly
veterán
válasz
bambano
#30792
üzenetére
Lehet csak pongyolán fogalmazok, én hardveres RAID-ről beszélek. Szoftveres RAID-et, meg ZFS poolt, azt valóban lehet bárhova tenni rétegügyileg, ahogy az LVM-et is. Gyanítottam a kollégának hardveres RAID van a LUKS rétege alatt, de abban igazatok van, hogy nem kéne látóasszonykodni, amíg nem tartalmaz a kérdés minden lényeges adatot, addig nem kéne próbálni konkrét választ adni.
-
Frawly
veterán
Ja, a BogoMIPS is felesleges. A kernelben nem, mert az valami időzítéshez használja betöltés közben, de a cpuinfo-ban semmi szükség nincs rá, egy teljesen fals benchmarkérték.
Amúgy meg de, a kernel meg tud szerezni mindenféle infót, a legtöbbet a CPUID-ből tuja kiolvasni, és azt összevetni egy adatbázissal. Meg egyébként is sok infót meg tud szerezni, a modern OS-ek nem nagyon függenek a BIOS-tól. Utoljára a DOS meg a Win9x volt olyan, ami erősen függött tőle, mert egy rakat BIOS-hívást használt.
(#30669) Jester01: elhiszem, hogy a CPUID utasítás ezzel a @ jeles névvel tér vissza, de ezt a kernel lecserélhetné megjelenítéskor, simán regexppel.
-
Frawly
veterán
válasz
vargalex
#30667
üzenetére
Ja, értem. A model name-nél valóban a base clock van, az @ jel kicsit zavaró, mert azt tényleg értheti valaki úgy, hogy az az aktuális, de azt a CPU MHz sorban írja.
Mondjuk erre a /proc/cpuinfo-ra is ráférne már egy kis modernizáció, kb. a 90-es évek óta alig nyúltak hozzá a kernelnek ehhez a részéhez. Eléggé tömör, ködös, ahogy az infókat írja. Nem is ír elég infót, amit ír, azt is helypazarlóan.
Pl. ami közös jellemző, azt nem kéne szálanként elismételni minden egyes alkalommal, elég lenne egy közös infós részben mutatni. Plusz írhatna olyanokat, mint kódnév, foglalat, csíkszélesség, a base clock-on felül turbó órajeleket is, ha van, külön egy és összes magra vonatkozót is, integrált GPU-t, stb.. Az utasításkészleteket is elég nehezen megfejthető, túl tömör formában szokta írni, jó lenne, a valami toolt csinálnának hozzá, ami részletesen kifejti, hogy melyik-melyik, mire való.
-
Frawly
veterán
válasz
vargalex
#30665
üzenetére
Nem tudom, nálam Archon a /proc/cpuinfo-ban is az aktuális órajelet mutatja, szálanként eltérően, külön. Most egy gyors grep /proc/cpuinfo nálam ezt mutatja egy 2,5 GHz-es i5-2520M-en, ami gyárilag 3,2 GHz-re boostol:
cpu MHz : 1292.870
cpu MHz : 1610.595
cpu MHz : 1367.475
cpu MHz : 2015.892Pillanatról pillanatra ingadozik, 800-3198 MHz között bármi előfordul, az aktuális magok, szálak terhelésének függvényében.
-
Frawly
veterán
Eléggé meg leszel szivatva, csak úgy mondom. Nem is konkrétan a appod miatt, hanem ha új feltöltőként csatlakozol a store-jukban, akkor mindenféle regisztrációs díj, meg igazolás, meg lófütyi van állítólag. Én még nem csináltam, de aki ezzel foglalkozik, az azt mondja, hogy állati szopás. Persze ha az appod is olyan, hogy beleesik egy szűrőbe, amiatt is megszivathatnak extrán.
-
Frawly
veterán
Ez meglepett, ezzel a rövidítéssel nem találkoztam, meg kell mondjam. Természetesen utána fogok nézni, mert én a dokumentumformátumra gondoltam nagy hirtelen, de nem baj, adtál vele ötletet, ne röhögjetek. Ne feledjétek, hogy nem NSA szintű titkosításra van szükségem, egy Keepass szintű átlag megoldás elég, csak legyen egyszerűbb. Nem követelmény a katonai fokozatú biztonság. Android eleve biztonsági szinten totál komolytalan, Google nem megbízható, tele a boltjuk ellenőrizetlen fingóappal, amiknél a zárt forráskód miatt meg se tudsz róla győződni, hogy megbízható-e. Szóval ha Android, akkor a biztonság örvénylik lefelé a klozetban. Itt csak arról van szó, hogy telón ne ilyen titkosítatlan formában legyen ott.
Mert még ha tényleg megbízható megoldással is csinálom, pl. 7-zip-ről biztosan tudom, hogy megbízható, de azon kívül, hogy arra overkill, amire én akarom, az vele a baj, hogy nem tudni, hogy a telefonos 7-zip app hogy kezeli le, hová bontja ki a titkosítatlan fájlt, az hol, meddig marad látható, SD kártyára, belső tárolóra kerül-e, vagy memóriában tartja, teljesen lutri az egész. Mert a hajamra kenhetem az AES256-t, ha az app bénán van megírva, kibontja egy nem illékony fájlrendszerre temp fájlként az épp kititkosított cuccot, és onnantól az egésznek nincs értelme, lazán támadható az egész egy kis leleményességgel, nem kell semmilyen bruteforce hozzá.
-
Frawly
veterán
válasz
I02S3F
#30642
üzenetére
Azért, mert ha elhagyom vagy ellopják a telót, akkor azon nincs a háttértár titkosítva. A teló le van zárva, de az meg törhető.
Természetesen ha csak a linuxos gépemre kéne, akkor még egy tiktosítatlan plain text file is megfelelne, mert a háttértáram titkosítva van, rendszer jelszóval védve, lezárva hagyva, más nem fér hozzá, nem tud belematatni, még akkor se megy vele semmire, ha kiszedi belőle az SSD-t, és átrakja másik gépbe.
Itt most arról van szó, hogy a Keepass-nál egyszerűbb megoldások után nézek, mielőtt fölöslegesen feltalálom a kereket, és belenyúlok a kpcli kódjába. De még a gpg-s, vagy opengpg-s megoldás is játszhat, ha kulturáltabb formában meg tudom oldani túl nagy hekkelés nélkül. Itt most csak lényegében lustaságból próbálok plusz munkát megúszni, hátha lehet alapon.
-
Frawly
veterán
Kösz szépen, ezekre rá fogok nézni. Tudtam, hogy rád számíthatok.
A többieknek szép sorban: tudom, kicsit nehéz, hogy spéci igényeim vannak. Azért a haladó topikban kérdeztem. Ha csak az kéne hogy letitkosítsak valamit valahogy, arra van már több multiplatform megoldásom is.
A Java, meg igen, bloat. Headert meg lehetőleg nem akarok, akkor se, ha az AES törhetetlen gyakorlatilag.
Ez a PDF viszont így másodszor belegondolva nem tűnik hülyeségnek! Először nem tetszett az ötlet, de most, hogy belegondolok, a PDF formátum is támogat AES titkosítást, és a PDF-et minden platformon megnyitja egy valamilyen tetszőleges pdf olvasó, nem kell hozzá spéci app meg szoftver. Igaz nem plain text megoldás, de végül is nem is annyira bloat, Zathurával terminálból meg tudom nyitni, nem egy nagy tétel. Szóval ki fogom próbálni, meg megköszönném emvynek is az ötletet, meg hogy foglalkozott a problémával. Még ha ebben a formában, amiben ő írta nem is jön be, de ötlet formájában hasznosulhat ez a megközelítés, és egyszerűbb és időkímélőbb lehet, mint nekem forráskódokba belenyúlkálni. Persze nem tökéletes megoldás, mert headerje meg figyelemfelhívó jellege van a tiktosított pdf-nek is, de a módszer egyszerűsége csábító.
-
Frawly
veterán
Azzal, hogy egy esetleges támadónak segítség, hogy mi van benne. Motiválja a törésre. Ha csak egy bináris fájl lenne, fejléc nélkül, akkor még az se lenne biztos, hogy micsoda ez a fájl, egy szoftverhez tartozó adat, vagy fájltöredék, vagy mi. Így reklámozva van, hogy hülye vagyok, üssetek, gyertek, mindenki, fontos dolgot titkolok, hekkeljetek.
A gpg-vel mint írtam, két gond van. Ha ezt lefuttatod, akkor feldob egy GRAFIKUS jelszókérő ablakot. Ezt ugyan át lehet hekkelni ncurses pinentry agent megoldásra, de megint felesleges bonyolítás, és az Androidon való kititkosítás sem megoldott biztonságos formában, azaz egy validált, auditált app a memóriába bontaná ki, ahonnan azonnal eltüntethető lenne, nem hagyva maga mögött a fájlrendszeren nyomot.
Ezt az openssl-t meg is próbálnám, de így, hogy írod, hogy valami komolytalan, PDF-es megoldás, így az élből nem játszik, meg szerintem androidos, kulturált megoldás nincs rá.
Mondom, bonyásan meg tudom oldani ezt, de én minimalista, terminálos megoldást keresek, jelszóelfelejtés esetére, amibe beverek egy mesterjelszót, terminálkimenetben kiköpi a webes jelszólistát, megnézem, bezárom, és ugyanez Androidon is kivitelezhető legyen, igaz ott nem kell terminálosnak lenni, de legyen rá valami kulturált, ingyenes, reklámmentes app, ami vagy csak simán biztonságos, vagy auditált. Vagy-vagy.
Így lehet az lesz, hogy vagy a kpcli forráskódjába nyúlok bele, hogy jó legyen, vagy fejlesztek ehhez valami ultraminimalista saját megoldást, ami tényleg csak olyan szinten AES256-oz végig egy plain text fájlt, amit Androidon a cryptol app meg tud nyitni. Mert nekem nem kell bonyolítás, nem kell grafikus felület, nem kell random kulcsgenerálás, nem kell adatbázisba szervezés, nem kell limitált ideig vágólapkezelés, nem kell online szinkronizáció, és egyéb bonyolítás.
-
Frawly
veterán
Egyszerű, terminálos, szimmetrikus ki/betitkosító megoldást keresek, ami min. AES256 biztonsági szintű, és létezik hozzá Androidon használható biztonságos megoldás is. Lényegében egy jelszavakat tartalmazó titkosított fájl kezelése lenne csak a feladata, nagyon minimalistán. Erre várok ötleteket.
Ki is próbáltam néhány alternatívát, de egyik sem tetszik. A klasszikus gpg2 csomagból a gpg parancs, de ez alapból mindenféle keyring-et akar használni, amit le lehet tiltani, de pl. a grafikus jelszóbekérő ablakát is hekkelni kell, hogy terminálos legyen, és az androidos kezelése sincs megnyugtatóan megoldva. Eléggé túl van bonyolítva.
Aztán kipróbáltam a ccrypt-et. Ez majdnem megfelelő lenne, egyszerű, terminálos, minimalista, 0 függőség, nincs bonyolítva keyringgel és grafikus elemekkel, de Androidon nincs megoldva a kezelése.
Jött az aescrypt. Ez megint nem teljesen jó. Egyszerűségben, minimalizmusban megfelelne, Androidon is van hozzá kulturált app, de egy dolog nagyon nem tetszik benne. Az általa titkosított fájlokba túl feltűnő headert tesz, ami egy esetleges támadónak felhívás keringőre:
AES... CREATED_BY... aescrypt 3... majd csak ezután jön a titkosított bináris tartalomMegoldhatnám 7-zip-pel, ki-betömöríteni fájlt, és Androidon is működésre lehetne bírni, de a kitömörítés nem lenne biztonságos szerintem, igaz ezzel még kísérletezek. Headert ez is alkalmaz, de kikapcsolható, úgy tudom.
Eddig erre a KeePass-t használtam, ez kezelhető terminálból (kpcli), illetve biztonságos androidos app is van hozzá, de a terminálos kezelőfelülete elég gyopár, nehézkesen kezelhető automatizáltan. Igaz, mivel a kpcli Python-alapú, így beszéltük múltkor, hogy belehekkelhetek, amit lehet meg is teszek, de előtte szétnézek, hogy van-e valami egyszerűbb megoldás helyette.
Ott lenne még a VeraCrypt meg a LUKS dm-crypt, de azok nagyon ágyúval verébre megoldás egyetlen fájl minimalista titkosítására. Kicsit már a jelszavazott 7-zip-ezést is overkillnek érzem.
-
Frawly
veterán
válasz
Jester01
#30596
üzenetére
Akkor én értettem valamit félre, és valóban ez a megoldás, amit keresek. Bár azt még mindig nem értem, hogy a cat parancs, miután átadta a kimenetét a programnak, honnan fogja tudni, mit adagolok be billentyűzetről a program indulása UTÁN. Mert valóban működik, igaz nem a kpcli-vel, de tényleg úgy viselkedik, ahogy mondjátok.
kpcli-vel is csak azért nem működik, mert az mintha kiürítené a bemeneti buffert, gondolom biztonsági okból.
-
Frawly
veterán
válasz
bambano
#30595
üzenetére
Igen, nem lehetetlen, hogy én értek félre valamit, azért nem értem.
Amit ti írtok, az a megoldás azt csinálja, hogy bekéri az előre rögzített fájlinput mellé az én felhasználói billentyűzetinputomat, de mikor azzal végeztem, csak UTÁNA indítja a programot, és mikor már a progi fut, akkor én már NEM tudok utólag beleszólni, más parancsot is bevinni.
Ami nekem kell megoldás, ott a dolgok SORRENDJE teljesen más. Először indul a progi, aztán hajtja végre automatikusan a fájlinputot, amibe az előre beszögelt utasítások vannak (amolyan autorun jelleggel), majd átadja NEKEM az irányítást, mert előre én sem tudom, hogy mit fogok majd bevinni a billentyűzetről, az annak lesz a függvénye, hogy az előre berögzített input alapján mit ír ki a progi.
Abban valószínű igazad van, hogy át kéne írnom a kpcli-t, hiszen csak valóban csak egy Perl-script, és nekem nem is kéne nagy módosítás, csak annyi, hogy induláskor bevegyen több parancsot is, és azok végrehajtása után ne lépjen ki automatikusan. Magyarán nem sok változást kéne a kódban eszközölnöm.
-
Frawly
veterán
válasz
bambano
#30593
üzenetére
Bocsánat, nem láttam, hogy olyan topik is van. Ez a megoldás nem jó. Ugyanis ezzel ugyan nem csak a fájlban eltárolt és az általam kézzel megadott input kerül be, és UTÁNA indul a program. Nekem úgy kéne, hogy a progi induláskor végrehajta a fájlban lévő parancsokat, aztán visszakerül az irányítás hozzám, de úgy, hogy a program NEM lép ki. Ezt félinteraktív módnak nevezik, a terminálos calc progi pl. tud ilyet a -i kapcsolóval, elindul, a proginak előre átadott inputot végrehajtja, majd ha ezzel végzett, visszaadja a felhasználónak az inputot, hogy további parancsokat vihet be.
Jelenleg viszont ez a kpcli csak annyit tud, hogy végrehajt előre megadott parancsot (már ez önmagában problémás, hogy csak egyet), és utána KÖTELEZŐEN kilép, ami nekem baj, ezt akarom megkerülni. Az is igaz, hogy a megoldás se fog segíteni, mert < fájl inputból meg valami miatt cseszik végrehajtani a parancsokat. De a megoldást továbbra is keresem, mert más CLI/TUI alkalmazásoknál is jól tud jönni.
-
Frawly
veterán
Amiért a topikba jöttem, az egy Bash-kérdés. Hogy lehet egy proginak többféle inputot is adni? Mert 1 inputot tudok neki adni, pl. progineve < fájl, a fájlban a bevinni kívánt karakterek. De nekem úgy kéne most, hogy beadagol neki egy ilyen fájlt, ám ha elfogytak a karakterek belőle, akkor a felhasználó is tudjon még billentyűzetről bevinni parancsokat.
A kpcli (KeePass CLI változata) ugyanis nem tud induláskor automatikusan lefutó utasításokat kezelni. Tud nem interaktív módot, fájlból parancsokat beolvasni, de utána kilép, nekem úgy kéne, hogy ne lépjen ki. Ezt úgy akarom kivitelezni, hogy inputként megkapja a fájlt, és a billentyűzetet is. Ha fájl inputtal hívom meg, akkor meg a parancsok elfogyása utána futva marad a program, de nem tudok parancsokat kézzel bevinni.
-
Frawly
veterán
válasz
ubyegon2
#30587
üzenetére
Ezzel sose értettem egyet, hogy új gépeket FreeDOS-szal szállítanak. Azzal a felhasználók 99%-a nem tud mit kezdeni, a másik 1% is biztosan lecseréli. Semmiben nem különbözik attól, mintha OS nélkül jött volna a gép.
A gyártóknak valami népszerű disztrót kéne feltenni, pl. Ubuntu, Mint, vagy ami tetszik nekik, benne olyan hasznos dolgokkal, mint GParted, memtest, hőmérséklet-monitorozó és hasonlók. Nem nagy munka, csinálnak az egyikre telepítést, beállítják, majd a lemezképet felhúzzák az összes gépre.
A Linuxot is sokan lecserélik, persze, de azzal azért használható a gép, míg a user nem telepíti fel rá a saját OS-ét, meg a Linux arra is jó, hogy ki lehet próbálni a gépet, billentyűzet, tapipad működik-e, tesztelni lehet a 3D grafikus képességeket, lehet róla böngészni. Így még az is, aki Linux-ellenes és Windows/Hackintosh-fetisiszta, tudná tesztelni a gépet, és nem saját OS telepítése után veszi észre, hogy ez meg az nem működik.
-
Frawly
veterán
válasz
CPT.Pirk
#30567
üzenetére
Az mindegy, a HP-knak, mivel üzleti gépek, elég jó szokott lenni a linuxos támogatásuk. Mind az Intel GPU, mind a Synaptic touchpad szokott menni probléma nélkül, gyorsgombokkal, fényerőállítással, mindennel együtt. Egyedül Wi-Fi kártya hibádzhat, ha valami nem gyári, spéci modulra lett cserélve. Más gond ezekkel nem szokott lenni. Ha egyik OS alatt sem megy az egér, az hardverprobléma lesz. A Dell-nek meg a Lenovonak is szintén ugyanez igaz az üzleti gépeire, probléma nélkül szokott rajtuk menni bármilyen Linux.
-
Frawly
veterán
válasz
gelbelex
#30555
üzenetére
A jövőben arra is figyelj, hogy nagy évszakos Win10 update-ek sunyi módon vissza szokták kapcsolni a Fast Startup-ot, akkor is, ha te korábban kézzel kikapcsoltad. Ezért néha frissítések után rá kell nézni, hogy nincs-e bekapcsolva. Ha még egyszer gond lesz az NTFS kötetekkel, akkor erre kell gyanakodni az első körben.
-
Frawly
veterán
válasz
gelbelex
#30552
üzenetére
Igen, ez a Fast Startup miatt van, az ugyanis egyfajta félhibernációba teszi le a gépet, nem állítja le a szokásos módon, és nem csatolja le a megnyitott fájlrendszereket, de mikor a Linux bootolna, nem tudja rendesen felcsatolni ezeket, és belekever az NTFS fájlrendszer konzisztenciájába. Windows alatt erőszakolj ki egy fájlrendszerellenőrzést, majd ha ez végzett, javította a hibákat, akkor Linux alól töröld a kérdéses mappákat és fájlokat.
-
Frawly
veterán
Utránanéztem. De pofátlanság, hogy nézek egy 3 évados sorozatot, a 3. évad közepén járok, erre törlik a 3. évadot, ami nemrég jelent meg. Az 1-2 évad bezzeg fent maradt, csak azt törlik, amit néznék.
A letöltéssel is tisztában vagyok, nem kell kioktatni, kösz szépen. Még 14 nap után se gond, ha egy videó akkor lett letöltve. Ha ez lenne a gond, akkor azt írná, hogy érvénytelen letöltés, lejárt az érvényessége, ezzel nem lenne gond. Itt arról volt szó, hogy 1-2 napja letöltött videókat se engedett megnézni, az 1043-as hibakód akkor szokott lenni, ha túlterhelt a szerverük. Na de ne vicceljenek már, pont azért töltöm le ELŐRE, hogy ne függjön szerverterheltségtől, hanem csak a kulcsot kell validálja akkor, az egy pár KB-os letöltés. És nem nézhetem, amiket MÁRIS előre letöltöttem, és a szerverükön sem okoznék vele nagy többletterhelést. Kösz, de nem. Birkának ne nézzenek.
A HBO-t azért utálom, mert mindig is túlárazott volt, és nem tetszettek soha a sorozataik. Azt nem tudtam, hogy nincs UK-ben, de mindegy is, mert mint írtam, amúgy sem érdekelne. Ezért nyergelek át Amazon Prime-ra. Ami szintén lehet nem a legjobb, de legalább nem a Netflix zsebét tömöm.
Illetve az audiovizális tartalom rendszere: a jogkezelés egy dolog, de az, hogy a jogkezelő azt is eldöntse, hogy FullHD-ben csak Ringyózról tudjam nézni, Linuxról ne, meg egyik androidos telón menjen 1080p-ben, a másikon csak 480p-ben, az már a világ legnagyobb pofátlansága, ne haragudj. Ezt nekem senki nem meséli be, hogy ez így rendjén van. Ugyanannyit fizetek érte, ugyanarról az eszközről nézném, és mégis hátrányosan vagyok megkülönböztetve.
Ezt a fajta szemétséget elvből nem engedem, mert mi jön legközelebb? Eldöntik, hogy csak fejen állva nézhetem, vagy csak akkor, ha még a villanyszámlát is ellenőrizhetően kifizettem? Vagy mit találna még ki?
Nem érdekel, szabjanak meg egy árat, ha kell, legyen magas ár, de akkor korlátlanul nézhessek mindent, regionális korlátozások nélkül, eszközfüggő felbontásfüggetlen feltételek mellett. Ne legyek megkülönböztetve, meg előre eldöntve, hogy ezt csak így, csak úgy nézhetem. Nem érdekel, akkor ne 9 font legyen, legyen 19, vagy 39, de nézhessem, amit akarok. De ezek szerint nem kellett nekik a pénzem, mindent megtettek, hogy ne fizessek elő.
Ugyanerre a sorsra jutott a Spotify is. Ott a szar minőség döntött, hogy vissza kellett mondanom. Kikapcsolt normalizáció mellet is tompa, kásás a minősége, minden eszközön, még jobbfajta DAC-kal is. Előfizettem inkább Tidalra, sokkal drágább, de legalább normális a minősége, tényleg CD minőség.
-
Frawly
veterán
válasz
CPT.Pirk
#30546
üzenetére
Akkor most lehet épp megint működik. Egy hónapja teszteltem, mikor mondtam vissza a Netflixet, akkor nem működött Firefoxban. Lagolt vele a videó, meg csak 480p-ben ment. Ezek szerint javították, de nem marad ám ez sokáig így, mert a Netflix érzékelni fogja a logokban, hogy linuxos gépekről megy tömegesen orrba-szájba az 1080p stream, és megint variálni fognak valamit, hogy ne menjen.
Engem nem is érdekel, visszamondtam a Netflixet. Korlátozzák a kínálatot, korlátozzák a felbontást, elmozgatnak azokból a tartalmakból is, amik korábban legalább elérhetőek voltak az adott régióban. De legjobban akkor rágtam be rájuk, mikor lementett (értsd előre letöltött) videókat próbáltam ingázás közben nézni telón, és behányta rendszeresen az 1043-as hibát, hogy a szolgáltatás nem elérhető. Na, itt döntöttem el, hogy ezért nem fizetek, mert ez így lúzerség, hogy lépten-nyomon megaláznak, meg ügyfélként semmibe vesznek, és én még pénzzel is tömöm a zsebüket, jutalomképpen. Múlt hónapban ezért visszamondtam. Majd előfizetek Amazon Prime-ra, de azt mondják az se jobb. HBO-t utálom, a Hulu meg nem elérhető a UK-ben.
Spotify-t is visszamondtam, azzal az volt a baj, hogy Highest Quality-ben (320 kbps-os Ogg Vorbis) is fosadék volt a minősége (pedig maga az ogg tud jó minőséget, főleg 320 kbps-os bitrátán, rendes encoderrel), mindegy milyen jó hangfelszereléssel vagy melyik eszközről hallgattam, egyszerűen tompa, kásás. Próbáltam normalizálást kikapcsolni, de ez se segített. Így átnyergeltem egyelőre Tidal-ra, rohadt drága, de legalább a minősége normális, desktopon losslessben használom, telefonon 320 kbps-os aac beállítással. Keresője, kliensse, webes felülete épp úgy hulladék, mint a Spotify-nak, meg ahogy nézem, a kínálat is korlátozottabb, de egyelőre kárpótol a minőség.
-
Frawly
veterán
válasz
CPT.Pirk
#30541
üzenetére
Nem működik már jó ideje a firefoxos Netflix 1080p addon. Amíg ment, használtam is, de már van majdnem egy éve nem megy. Nincs böngészőhöz kötve, vagyis olyan értelemben, hogy a böngésző a widevine DRM plugint használja, és ezzel kapcsolatos a korlátozás. De ez nem csak Linuxon van, androidos eszközök legtöbbjén is korlátozva van a felbontás, néha még jobban is, mint Linuxon a 720p, pl. a Xiaomi A2 telómon csak 480p-re, mert a gyártó nem tejelt extra pénzt a Netflixnek, emiatt nem kapott meg valami magasabb DRM minősítési levelt, és emiatt csak SD-re van korlátozva. Pedig ugyanaz az Android, egy ugyanolyan SoC procijú másik telón meg viszi az 1080p-t, mert ott a gyártó (pl. Motorola, Samsung, stb.) kipengette a zsarolási sarcot.
Ez nem a szoftverről, meg a Linuxról szól, hanem kő kemény üzlet, stratégia, marketing, jogkezelési keverés. Maga a Linux és Android kiválóan vinné mindegyik ilyen streamszolgáltatást 1080p-ben meg 4K-ban is. De eleve így van lezsírozva, hogy a Microsoft, Apple, prémium androidos gyártók extra pénzt tejeltek, hogy az ő excluzív feature-ök lehessen a FullHD és attól felfelé, és nem akarják, hogy linuxos ingyenjánoska meg énvagyok a programozó típusú Stallman-féle neohippik is gondtalanul tudják élvezni, mikor ők meg nem fizetett érte extra védelmi pénzt. Ez erről szól, maffia az egész stream meg jogkezelés.
Anticheat játékoknál is van fejlődés, ja, de itt számítani kell szívásra. De mint írtam, ez sem a Linuxban vagy Wine-ban lévő technikai korlát, hanem a játék van így szándékosan megcsinálva, tehát pont ez az, hogy olyan jól működik, hogy még azt is felismeri, hogy nem jó platformról fut, és emiatt megtagadja a futást. Ez direkt egy olyan védelmi funkció, ami pont azért tettek bele, hogy még véletlenül se menjen, és ha a kernelesek meg Wine-osok belenyúlnak ebbe, akkor egy ideig mennek ezek a játékok is, míg majd a játékkiadó meg nem unja, kihoz egy újabb frissítést, amibe implementálnak valami másik korlátozó trükköt, hogy ne menjen.
Itt azt kell érteni, hogy nem linuxos inkompetencia miatt nem megy, hanem a játékkiadó nem akarja, hogy Linuxon játssz. Mert azt akarják, hogy Windowson meg konzolon játssz, mert ott mindenféle védelmi meg korlátozó service-t a nyakadba tudnak tenni, amit nem tudsz megkerülni, mert ezek zárt platformok, meg ezekre lett exkluzivitás véve. Félnek, hogy ha Linuxon lehetővé teszik, az egy nyílt, hekkelhető, átlátható rendszer, és megkönnyítik vele a kalózok meg cheaterek dolgát, meg ingyen élvezed azt, amiért más extra pénzt fizetett, mivel a MS, Apple, stb. ezt a védelmi sarcot, amit ők fizettek, beépítette a termék árába, de ha linuxozol, akkor ezt nem fizeted meg, ilyen alapon meg ők gondolják úgy, hogy akkor rohadj meg ingyenélőke, ne használd, szépen szívjál vele.
-
Frawly
veterán
válasz
BeeNiTTo
#30535
üzenetére
Kár volt kiszerkeszteni, főleg hogy azóta a kezdőben sem kérdezted meg. Játék Linuxon: de, igenis sokat változott a helyzet. Lényegében pár kivétellel az összes játék megy már, azok nem mennek főleg, amely játékok valami anti cheat, DRM védelem, hozzáláncolt Win only Launcher (ez is egyfajta DRM) miatt nem mennek, de ne feledd, hogy ez szándékos, nem a Linux hibája, hanem a játékot írták meg szándékosan úgy, hogy Windowson kívül semmi sehol máshol ne fusson. Pedig amúgy mennének ezek is Linuxon, nem lenne technikai akadálya, csak a játékkiadó fél, hogy Linuxon ilyen extra védelmek nélkül könnyű lenne törni a játékot, vagy cheatelni, mivel a Linux közvetlenebb rendszer és hardverhozzáférést tesz lehetővé, és nem kell rejtett szolgáltatásokat kerülgetni, ahogy Windowson.
De ugyanez van videóstreameknél is. A Netflix Linuxon 720p-re van korlátozva, pedig menne az 1080p, önkéntesek meg is csinálták, de a Netflix mindig buherál valamit, hogy ne menjen, mert az 1080p+ Windows/Mac/spéci médiaplatform only, így egyeztek meg a kiadókkal, hogy DRM csak ezeken engedje a nagyobb felbontásokat. Az HBO ennél is rosszabb, az HBO Max eddig ment Linuxon, most pl. sehogy nem megy, mert szándékosan így intézte az HBO, megint DRM védelem és jogkezelés miatt.
-
Frawly
veterán
válasz
Jester01
#30519
üzenetére
Nem tudni mitől döglenek a vezérlők. Szerintem a gyártók méretezik alul tervezett elavulás képpen. Szinte sose a NAND fárad ki, hanem a vezérlő fekszik ki, és ez akkor is megtörténik x időn belül, ha nem írtál a NAND-ra sokat. Nem csak azoknál az SSD-knél, amik a te kezed közé kerültek, hanem kb. az SSD-k 99,9999%-a ilyen.
(#30517) sh4d0w: nem értem, hogy mi ez, ami van. Az SSD vezérlője nem lát partíciókat, meg fájlokat, meg akármiket. Low level szinten kezeli az adatokat, így ezért mindegy, hogy titkosítva van vagy nincs. Vagyis egy esetben nem mindegy: egész lemezes szoftveres titkosításnál külön át kell engedni a TRIM-et a titkosítási rétegen, különben a vezérlő úgy látja, hogy az egész meghajtó be van telve, minden cellában lévő adatra szükség van, nem szabadíthat fel egy cellát sem. Viszont az átengedett TRIM meg gyengíti a titkosítás biztonságát, mivel mintázati támadást tesz lehetővé. Bár csak elméletileg, olyanról nem olvastam, akinek a titkosított adatait megtörték volna emiatt.
Aki SSD-t akar titkosítani, annak inkább hardveres titkosítást ajánlom. Egyetlen buktatója, hogy nem elég az SSD-nek tudnia ezt, hanem az alaplapnak és BIOS-nak is támogatnia kell (vagy nem kell, de akkor bootolni nem lehet róla), és a legtöbb konzumer lap nem támogatja, csak a céges kliensek, munkaállomások, üzleti laptopok, stb.. Meg ugye az SSD gyártójának a zárt hardveres titkosítása mindig megbízhatatlan, mivel nyílt forráskód híján csak bízni tudsz benne, hogy nincs az implementációjában gyengeség vagy kiskapu.
-
Frawly
veterán
válasz
sh4d0w
#30457
üzenetére
Nem sh4d0w-nak szánom, de mégis az ő hsz.-ére nyomom most a választ, mert ide tartozik. Ezt nagyon nem kéne gyerekek. Ezt az övön aluli ütéseket nagyon utálom, gerinctelenség. Hozzászóltam kettőt ebben a topikban, erre a fix.tv-s low latency-re reagálva, erre most látom, hogy szép csendben törölve lett. Tessék tudomásul venni, hogy ez egy fórum, ahol nem mindenki ért egyet, különböző véleményeket írnak be és ütköztetnek az emberek. Ha némileg lazul is egy-két esetben a témához kötöttség, attól még meg kéne hagyni, ha valakit annyira zavar, tegye OFF-ba a hsz-t, vagy kérje meg az embereket, hogy kanyarodjanak vissza szorosabban a témához, vagy ha nagyon feszültség van a véleménykülönbségek miatt, akkor csak hagyják annyiba. Ez lehet óvodában, meg Észak-Koreában divat, hogy a cenzúra malmai szép halkan, észrevétlenül őrülnek, egy nyugathoz tartozni akaró ország legnagyobb informatikai fórumán viszont nagyon gáz. Egyszerűen nem nem korrekt, hanem kifejezetten sunyi húzás, moderátori jog ide vagy oda!!!!!!!!!!!!!!!!!!!!!!!!!!
Tényleg nem a kollégának szánom, csak azért erre a hsz-re írom ezt válaszként, mert eredetileg is az ő hsz-ére reagáltam, ezért oda tartozik.
-
Frawly
veterán
válasz
CPT.Pirk
#30453
üzenetére
Igen, ez tisztán csak a Wine-fejlsztőknek mond valamit, oda bugreportold. Ilyesmiket én is kapok mostanában, mikor Apple iTunes-ből kivett QAAC encodert futtatok Wine alatt:
00b8:fixme:advapi:GetCurrentHwProfileA (0x21e930) semi-stub
qaac 2.69, CoreAudioToolbox 7.10.9.0
00b8:fixme:ver:GetCurrentPackageId (000000000021E480 0000000000000000): stubEmiatt nálam hol működik ez a progi, hol nem (hibás fájlokat gyárt le). Attól függően, hogy épp hogy frissül a Wine.
-
Frawly
veterán
válasz
bambano
#30452
üzenetére
Igen, azért írtam, hogy zenésznek fontos lehet a low latency. Hifista Jóskának viszont nem, és továbbá nem, nem 5 másodperc múlva hallja a zenét, hanem pár ms késéssel, ami nem határoz meg semmit minőségben, mert minden adat ugyanannyi ms-ot fog késni, így jitter sem lesz, a hangminőségbe nem fog beleszólni, recsegés sem lesz, mert amik lennének késés miatt hirtelen egyenetlenségek, azokat a buffer és az azt kezelő eszköz belső órája, szinkronizációja kisimítja.
-
Frawly
veterán
Nekem még semmilyen rendszer alatt nem volt reccsenés a zenében. Sem anno XP alatt, sem 7 alatt, sem 10 alatt, ASIO-val és anélkük sem, sem Linux alatt, normál kernellel sem, disztrótól függetlenül.
Mondom ezt úgy, hogy pl. a Pulseaudio-t utálom, de nem azon fog múlni, meg nem a kernel latencyjén. De ezek szerint csak kellően nagy buffert kell neki adni. Mai 4-32 GB RAM-os gépek korában nem hinném, hogy +/- 1 giga audio buffer okozna gondot bárkinek, vagy a sok magos procik nem bírnák a szoftveres mixelési tempót effektezésnél.
-
Frawly
veterán
Akkor ezek szerint az 1)-es pont alá tartozol, akkor vedd úgy, hogy nem szóltam. Én általában hifistáknál olvasom, hogy tyűűá, asio, meg latency, hogy jól szóljon a FLAC, ez az, amit sose értettem. Ha tényleg szükség van a low latency-re valami spéci felhasználás miatt, akkor oké.
-
Frawly
veterán
válasz
I02S3F
#30443
üzenetére
Szenvedni kell ilyen spéci telepítők meg kernelek telepítésével, ami később egy csomó anomáliához vezet, egy nagy rakás szoftver bugosan működik rajtuk. Ezt a latencyt létező problémaként két felhasználási területen tudom elképzelni:
1) valaki zenész, és effektezett hangszeren nyomja, és fontos, hogy ahogy lenyomta azt a billentyűt, akkor azonnal az a hang szóljon
2) emulátorplatformokon, hogy esetleges emulációs overhead miatt nehogy késsen a hang pár ms-ot a játékbeli akcióhoz, kirajzoláshoz képest.De ezen a latency dolgon pont olyan szoktak vergődni, akiknek igazából nem fontos, nem kötelező Reaperhez sem, meg hifistáknak sem, külső DAC-os bithelyes lejátszáshoz sem kell.
-
Frawly
veterán
Igazából nálam is csak pótcselekvés, meg hoppolás, hogy mindig újratelepítem, mindig másik megoldásokkal fűszerezve. Természetesen a rolling arról szólna, hogy sose kell újratelepíteni, 10 év múlva sem. De én szeretek tiszta lappal kezdeni, úgy, hogy a rendszerbe nincs begyűlve semmi sallang, semmi felesleges csomag, és ilyenkor tényleg megragadom az alkalmat, hogy valami mást is kipróbáljak. Igaz ez is egyre jobban változik, mert ahogy megyek egyre jobban a minimalizmus, terminálalapúság, tiling WM-ek irányába, úgy már egyre kevésbé váltogatom a programokat, mert már nem találok nagyon hatékonyabb megoldásokat.
-
Frawly
veterán
válasz
I02S3F
#30410
üzenetére
Nem, nem mentem. Azért szoktam le a rendszer mentéséről, mert állandóan változnak a felhasználási szokásaim. Kb. fél-egy évente úgyis újrahúzom az Archot, teljesen másik grafikus felülettel, meg pár progit is mindig lecserélek, ezért nem látom értelmét régi rendszert eltenni. Nekem a belakott rendszer nem szent, szeretek tiszta lappal kezdeni, meg különféle dolgokat kipróbálni. A konfigjaim a /home-on viszont el vannak téve, meg mentem őket, azokból fel tudok használni az új rendszer alatt, meg a csomaglistát is elmentem.
-
Frawly
veterán
válasz
vargalex
#30408
üzenetére
Ezt jó tudni, egyik megoldást sem ismerem, szükség esetén meg fogom próbálni. Nálam régen a GetDataBack for NTFS vált be, de az is kb. 10 éve használtam utoljára valakinek a gépén, akinek meghalt a HDD-je.
Mióta Linuxot használok, nem volt ilyenre szükségem. Egyszer írtam felül véletlenül (jó itt korrigálnék, nem véletlenül, hanem szín tisztán a FreeDOS telepítő hibájából) a partíciós táblám (FreeDOS-szal játszottam retrózás képpen), csak a GPT táblát (partíciók érintetlenek maradtak), de azt emlékezetből rekonstruálni tudtam, 100MiB-os EFI partíció, 50 GiB-os ext4, maradék ext4, mindegyik egész MiB-os (2048 db 512 bájtos) szektorhatáron kezdődik, rebootkor már minden működött, minden adat a helyén volt. Igaz volt mentés a felhasználói adatokról, de azért örültem, hogy a rendszert nem kellett újrahúzni, mert az azért melós lett volna, arról nem volt mentés.
-
Frawly
veterán
válasz
Mr Dini
#30404
üzenetére
A testdisket nem ismerem, de ezt Windows alól kéne csinálni, GetDataBack for NTFS nevű progival. Ha lehetséges némi adatot visszahozni, az képes rá, és tud önállóan bootolni, nem kell neki létező Windows telepítés. Mindent nem fog tudni az se helyreállítani, mert mint írtad, az adatok egy része felül lett írva, így a felülírt adatok mindenképpen elvesztek örökre, visszaállíthatatlanul.
Ez egy windowsos probléma, windowsos partíciókkal, felesleges a Linuxot belekeverni. Hiszen NTFS és FAT32 fájlrendszerekről van szó.
Illetve a particionálást ezért nem szabad laikusokra bízni. Főleg, ha a tárolt adatokról nincs biztonsági mentés. Nem véletlenül írja minden particionálóprogram, hogy mekkora méretű lemezt particionálsz, hogy nehogy valami másikat válasszon valaki véletlenül, meg még utána 5× rákérdez, hogy „biztosan akarja?”, „biztosan akarja, minden adat el fog veszni a lemezről”, „biztosan de biztosan akarja?”, „végül: biztos abban, hogy biztosan, de biztosan akarja?”. Ezek a kérdések nem azért vannak, hogy kényelmetlenséget okozzanak, hanem ennek a „véletlen” adatvesztésnek a károkozásait elkerüljék.
-
Frawly
veterán
válasz
inf3rno
#30378
üzenetére
Értem, szóval a bitflip még mindig urban legend, mindenki hallott róla, csak még senki nem tapasztalta. Amit a képen mutatsz, olyat én is láttam már, az nem bitflip, hanem okozhatja meghibásodott háttértár, rossz letöltődés. Persze RAM hiba is, de nem bitflip, hanem en bloc kaka RAM. Ezért kell CRC-ről meg redundanciáról gondoskodni, mert nem csak a RAM lehet hibás, meg nem csak bitflip fordulhat elő, önmagában az ECC sem tesz csodát, csak plusz egy védelmi intézkedés a sok közül.
Félre ne értesetek, nem az ECC RAM ellen vagyok, ha a platformja támogatja és valaki tud szerezni olcsón (pl. DDR3-ból még olcsóbb is az ECC, mert sok szerverből kukázott RAM-ot árulnak használtan), akkor miért ne, plusz egy védelmi vonal, senkit nem vitt még el a mentő, mert ECC-set használt. Én arról beszélek, hogy ez a divathájp, meg tömegpánik, hogy ZFS, jajjaisntem, csak-ECC, jajjmerhamivanhabitflipvanezeréventeegyszer hiszti csak ilyen marketingesek által felfújt baromság. Nem szabad neki bedőlni, van élet az ECC-n túl is.
-
Frawly
veterán
válasz
inf3rno
#30375
üzenetére
De milyen adatvesztéshez? Tegye már fel itt a kezét, aki bitflip miatt vesztett adatot. Mondom kizárólag bitflip miatt, nem teljesen hibás RAM, bedöglött háttértár, villámkár, kártevő miatt, hanem tényleg csak is kizárólag bitflip miatt. Na, ugye, hogy senki.
Arról nem is beszélve, hogy a tömörített fájlok, médiafájlok (kép, videó, audió), SQL adatbázisok, torrentek, komoly fájlrendszerek (mint a Btrfs, ZFS, és társaik, meg az összes többi fájlrendszer, ami használ tömörítést vagy titkosítást) stb. eleve valamilyen szinten mindig használnak valamiféle CRC megoldást, alapból. Tehát maximum nagyon alap fájlrendszereken lévő plain text fájloknál, és binárisoknál vagy kitéve, hogy a bitflip miatt félremehet valami. De binárisoknál is elméleti az esélye, mert ha egy bit is félremegy, az már másik opcode, azonnal crashel a program, vagy fagy az egész gép, nem marad észrevétlen. Plain text fájlokban, úgy, hogy tömörítve sincsenek, azokban nem tárol senki kritikus fontosságú adatot. Forráskódok általában fent vannak git-en, helyileg pedig megint tömöríteni szokták őket. Így maximum logokról meg CSV fájlokról tudom elképzelni, hogy csak így plain text-ben vannak hagyva, natúron.
-
Frawly
veterán
Igen, de ha nem tudok róla, meg nem volt belőle adatvesztés, akkor miért számítana? Általában egy RAM vagy jól működik, vagy nem. Utóbbi esetben sokkal durvább jelei vannak, mint a bitflip. Ha meg működik, akkor meg a bitflipnek nincs gyakorlati jelentősége, annyira ritka.
-
-
Frawly
veterán
válasz
bambano
#30364
üzenetére
Egyetértek. Erről szoftveres rétegben kéne gondoskodni, hogy az ellenőrző-összeg nyilván legyenek tartva, meg összehasonlítva eltárolásnál.
A DDR5 állítólag megszünteti ezt a mizériát, mert abból csak ECC-s lesz, még desktopon is. Megszüntetik ezt a kettős vonalat.
De elvileg a DDR4 vezérlésében már most is vannak olyan elemek, amik valamilyen szintű hibajavításról gondoskodnak, ettől még a non ECC DDR4 RAM nem lesz ECC-s, azt teljesen nem váltja ki, de a semminél jobb.
Egyébként mióta PC-zek, kb. 32 éve, nekem sose volt ilyen bitflip hibám. Volt olyan, hogy a RAM vagy az alaplap volt teljes kaka, akkor sem bitflip volt, hanem azonnal fagyott az egész OS-estől, vagy be sem bootolt, olyan szinten volt hibás. Vagy HDD lett bad sectoros, vagy áramszünet miatt sérült az adatintegritás. De bitflipből még sose lett gondom. Amikor meg nagyon ritkán mégis előfordul valakivel, annak a kivédésére jók a szoftveres megoldások. Ez az ECC-mánia túl van spilázva. Ilyen szintű biztonság max. bankoknál, hadseregnél, CIA-nél, stb. indokolt.
-
Frawly
veterán
A JMS 578 megfelelő chip, az elvileg támogatja az UASP módot, TRIM-et, és SMART-tot is. Nekem is van egy, igaz a SMART talán nem megy, de a TRIM és az UASP mód igen. De rég próbáltam, lehet minden menne ma már vele.
Az fstrim-nek ez a működése. Ha újrabootol a rendszer, akkor a felcsatolt partíciókon az egész szabad helyet végig TRIM-ezi (vagyis nem teszi, csak kiküldi a TRIM parancsot ezekre a szektorokra az SSD vezérlője felé). Viszont ha nem bootolsz újra, akkor második-harmadik, stb. futásnál megjegyzi, és nem TRIM-ezi meg az egész üres szabad helyet, hanem csak azokat a szektorokat, amik a legutolsó fstrim futása után szabadultak fel.
-
Frawly
veterán
Igen, tedd be a /etc/fstab-ba az adott partíciókhoz a discard paramétert. Vagy futtasd időnként kézzel az fstim-et, vagy ütemezd be systemd service-ként systemctl-lel.
Azért létezik a két megoldás együtt, mert kezdetben egyik fájlrendszer ezt a megoldást támogatta, a másik a másikat. Ma már kb. minden fájlrendszer támogatja mindkét módszert, így mára az maradt, hogy ki melyik módszerre esküszik. A Linux disztrók zöme fstrim-et használ systemd-vel beütemezve, az Arch Linux és a rá épülő disztrók fstab discard-ot. Mindegy melyiket használod.
Ami gond lehet még, az az USB-SATA adapter. A TRIM parancsot nem mindegyik engedi át az SSD felé. Az adapterchiptől függ.
-
-
Frawly
veterán
válasz
Krystal_s
#30196
üzenetére
Nem tudom mi lehet a gond. Az rfkill üzenetből ítélve mintha le lenne tiltva a Wi-Fi valami gomb-bal fizikailag a gépen.
Próbáld meg feltelepített Linux alól, ha fent van a gépen. Úgy kivédjük ezeket az rfkill hibákat, és miután kapcsolódott az SSID-hez, jobban erre a csatornamódosításra, HT40+ vagy HT40- kapcsolóra tudunk koncentrálni, hogy az iw dew utána visszaadja-e a 40 MHz-es értéket. Mert most én úgy látom, hogy jelenleg így Live-on nem is tudja egyáltalán használni a Wi-Fi-t. Grafikus felületen tudsz csatlakozni, ahogy szoktál?
-
Frawly
veterán
válasz
Krystal_s
#30194
üzenetére
Próbáld meg parancssor alól. Ha még mindig Ubuntu alatt vagy, ott bontsd a Wi-Fi kapcsolatot kézzel, grafikus menüből.
Majd nyitsz egy terminált, abba (kér root jelszót, meg a Wi-Fi eszköz neve lehet nálad nem wlan0 lesz, hanem wlp-akármi, és a channel sem 1 lesz):
su
systemctl stop NetworkManager
ip link set wlan0 down
iw dev wlan0 set channel 1 HT40+
ip link set wlan0 up
wpa_supplicant -B -i wlan -c <(wpa_passphrase SSIDd WPA2jelszó)
iw devAz utolsó parancs az utolsó előtti sorban írja a width-nél hogy hány MHz-en megy. Majd mérd le, hogy mennyivel megy, megvan-e az a 270 Mbit, amit akarsz. Esetleg ha a fenti parancsok nem segítenek, akkor újrabootolsz. A grafikus felületen megint bontod kézzel a kapcsolatot. Szintén terminálba ezt adod ki:
su
nmtuiEbben bekonfigolod a kapcsolatot, és kapcsolódsz. Nézd meg, hogy itt engedi-e a 20/40 MHz-et állítani. Ha kapcsolódtál az új beállításokkal, akkor iw dev paranccsal nézd meg terminálban, hogy átállt-e 40 MHz-re.
-
Frawly
veterán
válasz
bambano
#30111
üzenetére
Ezt nem tudtam, hogy az is ott van a kernelben. Akkor lehet kipróbálom azt is. Én eddig úgy tudtam, hogy a Xen-t külön fel kell telepíteni.
(#30112) inf3rno: ezt teljesen jól tudod. De ha már VM-ben próbálgat valaki, akkor valós szimulációként próbálkozzon, és maradjon a dedup, cow, tömörítés, mindenféle redundancia stb. bekapcsolva. Ahogy kikapcsolgatsz mindent, meg ilyen minimalista ideálkörnyezetben próbálkozol, az nem fogja visszaadni, amit majd a valóságban tapasztalsz.
-
Frawly
veterán
válasz
bambano
#30109
üzenetére
Nekem meg elsőnek a KVM. Xen csak akkor, ha nem akar valaki még host OS-t is telepíteni, meg konfigurálgatni. De teljesen jó a KVM, nem kell semmilyen extra virtualizációs szoftver, pláne nem fizetős. Ott a KVM a kernelben, azt lehet használni QEMU-ban, tökéletes kombináció ilyen tanulásra szánt VM-ekhez, még a VT-x, VT-d is támogatott benne, ha a gép is támogatja, akkor simán megy.
A Hyper-V-t kipróbáltam anno sima desktop Win10 Prof-on, 64 bitesen, 2. gen i7-es laptopon, hát, lomha, lassú fosch az egész, de a MS-tól nem is vártam mást. Akkora overheadje van, mint az állat (ThinkPad X220 i7-2620M + 16 GB RAM mellett próbáltam). Ezt max. az ellenségemnek ajánlanám. Ha Windowson akar valaki hobbi VM-ezni, akkor VirtualBox, ha az nem tűnik elég stabilnak a feladathoz, akkor VMware Workstation ingyenes verzió.
(#30106) Dißnäëß: de én pont azt mondom, hogy én nem fukarkodnék, ha már virtuális gép, főleg szerver (vagy nem szerver, de valami modern desktop OS), én alapból min. 4GB-ot adok neki RAM-nak, és min. 2 prociszálat. Ezeket emelem is, ha szükséges, mert nem fut kielégítő sebességgel. 1 szál, meg 1 GB RAM nevetséges, annyit max. ilyen retro Win9x-es virtuális gépnek adnék, esetleg WinNT4, Win2k-hoz, de már utóbbiakhoz is belőnék 2 szálat, mert tudják kezelni.
-
Frawly
veterán
válasz
Dißnäëß
#30103
üzenetére
Ja, hobbivirtualizációra, OS-eket tesztelni, meg minimális OS-eket építeni jó az 512 MB RAM egy prociszállal. De ezzel komoly dolgot nem tudsz kezdeni, én VM-nek is minimum 4 GB RAM-ot és min. 2 prociszálat adnék, az is abszolút minimum. Ilyen 1 vCPU meg 512 MB RAM-nál abszolút felejtősek azok a dolgok, amivel dobálózni szoktál, ZFS RAID, meg MySQL InnoDB és társai.
-
Frawly
veterán
válasz
bambano
#30099
üzenetére
Ja, hát ezek a legmodernebb 8-10 genesek már igen, mert az Intel érzi az AMD Ryzen konkurenciának a szorítását, és most bevetnek mindent, mert már nem élhetnek vissza az erőfölényükkel. Így most pakolják bele dögivel a legalsó kategóriás procikba is a sok magot, cache-t, hiányzó utasításkészleteket, hogy ne kelljen lehúzniuk a rolót. De szerintem ezek a modern i3-ak sem érik meg, mert hasonló árban vehetsz helyettük Ryzent.
De a szóban forgó 2-3. gennél még abszolút fölénye volt az Intelnek, és az i3-akból sok mindent letiltott.
-
Frawly
veterán
válasz
Dißnäëß
#30093
üzenetére
i3-mal ne is akarjál semmit, főleg nem szerverben. 2 mag, alacsony órajel, kevés cache, nem csak VT-d-t nem tud, hanem Turbo boostot, AES kiegészítést, stb., sem. Eleve nem is szerverbe meg virtualizálásra szánták, hanem Irodistáné Mancikának Windowst, Internet Explorert, meg Excel-Word-öt futtatni, de nem akarnak a gépbe annyira gyenge Pentium/Celeront rakni, ami már a beszerelés időpontjában elavult.
De a korai genes i3-akat helyenként még egy pár generációval előbbi C2Q is elvert.
Az Intel Core i 2. gen már 9 éves generáció, már a 3. genes i5-i7-es példányok is fillérekért mennek, lehet upgrade-elni. Vagy valami olcsó sok magos Xeon, esetleg 1. genes Ryzen sem rettenet drága, ezek valók szerverbe.
A VT-d meg annyiból trükkös, hogy nem elég a procinak támogatni, az alaplapnak, UEFI BIOS-nak is kell tudnia.
Az i3 max. valami kis forgalmú mikroszerverbe, meg mikrovezérlőnek jó, ahol mindegy mi hajtja a gépet, csak menjen, és ne ilyen RPi szintű SBC legyen.
-
Frawly
veterán
válasz
sh4d0w
#30087
üzenetére
Yeah, systemd. Ráadásul snap-pel súlyosbítva. Meg 10 perces kilövési idővel félrekonfigolva. Bloatot a bloathoz, azt is rosszul konfigolva. Nyamm, egész megkívántam. Ja, nem. Áldom az eget, hogy váltottam systemd-mentes, minimalista disztróra, se systemd, se stop job running genyaság. Csak száguld, mint a szél, jelenleg Void Linuxot használok, a default runit initrendszerrel.
A kétkedőknek, hogy miben jobb, mint a systemd: egyszerűen az runit (ahogy az OpenRC is Gentoo-n) teszi a dolgát. Annyira észrevétlen, annyira nincs az útban, annyira nem bosszant baromságokkal, hogy észre se veszi az ember, hogy van egyáltalán initrendszere. Egyszerűen csak minden megy, szolgáltatások hozzáadhatók egy soros paranccsal, ami lényegében csak egy symlinket csinál. Nem tud sokat, szög egyszerű, de megy, mint a szél, nincs útban. Épp úgy tud párhuzamos service-indítást is, mind az OpenRC, mint az runit. Egyszerűen csak működnek, minden megy, nincs bootkor meg leálláskor várakoztatás semmi baromságra, nincs kitéve az egész Pöttyering évszakonkénti gányolásának, nem bloatosodik. Ez lenne a lényege az initrendszernek, legyen egyszerű, csak tudjon initelni, és kész, semmi mást, ne akarja a világot megváltani, ne legyen az útban, ne legyen benne funkciótenger, meg mindenféle userszopatási lehetőség.
Igazából a hagyományos sysvinit script is teljesen jó, annak csak egy hátránya van mostanság, hogy nem tud párhuzamos indítást, bár lehet a forkjai tudnak. De ahol a villámgyors boot meg leállás nem lényeg, oda a hagyományos sysvinit is több, mint megfelelő.
-
Frawly
veterán
válasz
Dißnäëß
#30037
üzenetére
Ez csak akkor baj, ha desktop funkcióban használsz VM-et, és még ilyenkor is be lehet rajta kapcsolni valahogy hardveres gyorsítást, a részleteket nem tudom, de olvass utána. Sőt, még azt is lehet, ha géped támogatja (inteles platformin a VT-d, AMD-n most fejből nem vágom mi a neve), hogy ha két GPU is van a gépben, pl. dedikált meg integrált, akkor az egyiket odaadod a VM-nek, és telepíthetsz hozzá natív GPU drivert.
Vagy ha csak szerveres funkcióban megy a VM, akkor terminálból SSH konzolt nyitsz, és karakteres felületen vereted be neki a dolgokat, akkor a gyorsítás nélküli videómegjelenítés megint nem játszik szerepet. Szerverre (fájlszerver, webszerver, fordításra használt szerver, stb.) ugyanis hulla felesleges a grafikus felület.
-
-
Frawly
veterán
Valószínű benézed azt, hogy UUID-ből van többféle is.
Van a lemeznek UUID-je. Vannak a partícióknak, ez a PARTUUID. Vannak a fájlrendszereknek, ez a „sima” UUID. Ha klónozol valamit, akkor az összes UUID meg fog egyezni, nem elég a PARTUUID-t megváltoztatni, az UUID megváltozatására is szükség lehet, pl.
sudo tune2fs -U újuuid /dev/sda1 (vagy amelyik partíción van a fájlrendszer). Ez is csak ext2-3-4-en van így, xfs, btrfs, stb. fájlrendszeren más toolok vannak rá. -
Frawly
veterán
válasz
sh4d0w
#29952
üzenetére
De, ide is tartozik ez valamennyire. Első lépésben 18.04-es Xubutu alatt frissíteném a GRUB-ot, ugyanis valószínű, hogy meg fogja találni a Win10-et, és visszateszi a Xubuntu a saját bootmenüjébe. Terminál alatt ezt a parancsot kell kiadni:
sudo update-grubHa ez sem segítene, akkor a Windows 10 telepítőjét kell újra bebootolni, és ott Javítókonzolon helyreállítani a bootolhatóságot, ezen az oldalon részletesen le van írva.
Persze az is igaz, hogy tényleg butaság volt méregből akármit is csinálni. Le kellett volna nyugodni, eljönni a topikba, és leírni, hogy ilyen tálcaalkalmazások hiányoztak, meg leírtuk volna, hogy terminálból biztosan lehet telepíteni a gparted-et sudo apt update && sudo apt install gparted parancsokkal.
Linuxhoz kell a türelem, nem szabad az első nehézségnél feladni, utána kell olvasni, segítséget kell kérni. Érdemes beletenni a munkát, mert később, hosszabb távon viszont meghálálja a beletett időt.
-
Frawly
veterán
Én a linuxos OFF topikban folytatom majd. Elöljáróban sh4d0w kollégával most nagyon egyetértek. Aki systemd-t akar, meg univerzális, egy minden felett bloat megoldásokat, az maradjon Windowson vagy Linuxon, és ne akarjon BSD-zni. Felesleges a BSD-t is elbloatosítani, mikor erre már vannak bejáratott alternatívák, nem kell egy n+1. dolgot is elcseszni hozzá.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Call of Duty: Black Ops 6
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Autós topik
- Milyen légkondit a lakásba?
- Ubiquiti hálózati eszközök
- Honor Magic6 Pro - kör közepén számok
- sziku69: Fűzzük össze a szavakat :)
- Apple Watch
- Milyen videókártyát?
- Motorola Razr 60 Ultra - ez a kagyló könnyen megfő
- További aktív témák...
- Vírusirtó, Antivirus, VPN kulcsok
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- iKing.Hu - Xiaomi 14 Ultra - Ultra White - Használt, karcmentes
- LG 27GR95QL - 27" OLED / Limitált LoL Edition / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync
- Csere-Beszámítás! Sapphire Pure RX 7700XT 12GB GDDR6 Videokártya! Bemutató Darab!
- Okosóra felvásárlás!! Samsung Galaxy Watch 5 Pro, Samsung Galaxy Watch 6 Classic
- BESZÁMÍTÁS! Sony PlayStation4 PRO 1TB fekete konzol extra játékokkal garanciával hibátlan működéssel
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest