-
Mobilarena
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
-
Frawly
veterán
Semmi érdekes nincs benne. A 3.13 még a dinoszauruszok korából való. Backportolják persze ebbe az ágba is a javításokat, de nem villámgyors ütemben. Lehet olyan spéci fordítóval fordították már a -141-es buildet, ami a Spectre1 ellen véd, de a retpoline nincs még bele visszaportolva, ezért Spectre2 ellen nem.
Még az is lehet, hogy én is védve vagyok Spectre1 ellen, mert ugyan azt mutatja, hogy 70-nél kevesebb LFENCE utasítást talált a kernelben, de észre kell venni, hogy ez egy önkényes, hasraütésszerű szám. Először 63 darab volt nálam a 4.14.14-től kezdve, majd a 4.15.0-ától kezdve 61, de ezek a számok annyira közel esnek a 70-hez, hogy talán már elégséges védelmet nyújtanak, csak ez a teszter minősíti le, mert a 70-es tippjét nem teljesíti. Azért azt lássuk be, hogy különösen 69 LFENCE-kódnál hülyeség azt mondani, hogy sérülékeny, 70-nél meg nem, nem hinném, hogy egyetlen kódbeli eltéréstől az egész kernel sérülékeny lesz. Emiatt amondó vagyok, hogy ha nem túl alacsony az LFENCE opkódok száma (mondjuk 15 vagy az alatt), akkor valószínű annyi már elég, hogy az ember ténylegesen ne legyen sérülékeny.
Ezzel az online checkerrel a böngészőt lehet tesztelni, de csak Spectre ellen, de azt sem tudom, hogy ez csak egyik Spectre ellen nézi vagy mindkettő ellen. 58+ FF, és 64+ Chrome elvileg foltozva kéne hogy legyen. A böngésző különösen fontos, mert Linuxnál, ha valaki csak a hivatalos tárolót használja, akkor nem jut be a gépére olyan kód, ami a sérülékenységet ki tudná használni, egyedül a böngésző az, ahol ilyen kód lefuthatna, de ha a böngésző foltozva van, akkor gyakorlatilag az egész gép is. Ráadásul ez a teszt a tényleges sérülékenységet nézi a böngészőn, míg a többi Spectre-Meltdown checker nem azt nézi, hogy a gép valójában sérülékeny-e (ehhez a sérülékenységet kihasználó kódot kéne futtatni), hanem csak a proci típusát, a mikrokód kiadási dátumát, és a kernel bizonyos tulajdonságait vizsgálja, és ezek alapján próbál visszakövetkeztetni, hogy ELVILEG sérülékeny-e. Ha arra is jut, hogy minden megfelelőnek néz ki, GYAKORLATILAG még akkor is elképzelhető, hogy a sérülkényeséget kihasználó kód sikerrel futtatható, és fordítva is lehetséges. Ezért ezek a teszterek nem sokat érnek, legfeljebb csak az ember lelkiismeretét nyugtathatják, hogy fent vannak a szükséges patchek.
-
Frawly
veterán
válasz
growler
#57969
üzenetére
Melyik SM checkerrel nézed? A speed47-félével? Hányas verzió?
A 4.15-nek Spectre2 és Meltdown ellen foltozva kéne lennie Retpoline-nal és (K)TPI-vel. Spectre1 ellen csak a 4.16-ban lesz patch, addig meg még az emberek többsége sebezhető marad.
Én is felpasszintottam Arch stagingből a 4.15-öt, nálam ezt írja:
Spectre and Meltdown mitigation detection tool v0.33+
Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-1-ARCH #1 SMP Mon Jan 29 04:41:41 UTC 2018 x86_64
CPU is Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: NO
> STATUS: VULNERABLE (only 61 opcodes found, should be >= 70, heuristic to be improved when official patches become available)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: NO
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Retpoline enabled: YES
> STATUS: NOT VULNERABLE (retpoline mitigates the vulnerability)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability) -
Frawly
veterán
Ez nem derült ki. Ha csak Chrome alatt ilyen, az egy speciális szoftver ebből a szempontból, mert nem az ablakkezelő beállításait használja ebben a tekintetben, hanem az Xorg-szerverét, így a ~/.Xdefaults fájlba kell szerkeszteni, nálam ez van benne, de nálad nem biztos, hogy ezek lesznek a legjobb beállítások:
Xft.autohint: 0
Xft.antialias: 1
Xft.hinting: true
Xft.hintstyle: hintslight
Xft.dpi: 96
Xft.rgba: rgb
Xft.lcdfilter: lcddefaultMásrészt lehet oka az is, hogy mscorefonts-ból Times New Romant használsz. Nagyon nem javaslom, a Linuxnak pont az a lényege, hogy nem Windows, egy csomó minden normálisabb benne, közöttük a grafikus felületek és betűtípusok is, de azok simítása is jobb, mint Windowson.
-
Frawly
veterán
Igen, attól lehet, hogy a noti ki van kötve monitorra. Ha nincs, akkor a saját kijelzőjén is ilyen recés a font rendering? Ha sima Ubuntu Unity felülettel, akkor Gnome Tweak Toolt tegyed fel (benne van a hivatalos tárolókban), és ott a Fonts (vagy Betűtípusok) kategóriánál az utolsó két beállítás a kiemelés és a simítás, mindkettőnek van köze recék kiigazításához, de leginkább az utóbbi a fontosabb.
-
Frawly
veterán
válasz
CPT.Pirk
#57928
üzenetére
Így van. Vagy az X-ben kell beállítani a TearFree opciót, hogy azzal használja az amdgpu drivert, vagy még inkább jobb, ha kompozitor be van kapcsolva (ilyenkor átlátszósági effekteket, árnyékokat, stb. is hozzá lehet adni a megjelenítéshez), bekapcsolt vsync-kel, és akkor nem fog csíkozni a képernyő görgetéskor és videólejátszáskor.
Szerintem OpenCL helyett OpenGL-re gondolt, azt használnak általában a kompozitorok, de tudnak DRI-t is, ami a driverrel jön. Az OpenCL teljesen másra való, nagyon valószínű az nem kell neki. OpenGL-hez a Mesa csomagot kell feltenni.
-
Frawly
veterán
válasz
szuszinho
#57921
üzenetére
Egyszerre két kártya kapcsolódik ugyanahhoz a monitorhoz? Vagy két külön monitorhoz? Most nem arról volt szó, hogy nem kell neked az integrált, és letiltod BIOS-ból?
Nekem nincs AMD kártyám, de a kimenetben nem tetszik az „ati” szó, mert az egy régi zárt driver, csak az amdgpu-nak kéne benne szereplnie szerintem, de ezt majd gyurmafigura legfeljebb cáfolja.
Az i3-as gépnél meg még mindig nem írtad meg, hogy KONKRÉTAN mire kell neked az OpenCL. Azzal nem megyünk semmire, hogy gyengébb gép, jó lenne, ha lenne OpenCL is, mert még mindig nem tudjuk, hogy mibe is kéne besegítenie. Ha csak hardveres videódekódolásba, akkor arra elég a libva. Ha meg bitcoint bányászol, az meg megint más téma.
-
Frawly
veterán
válasz
szuszinho
#57892
üzenetére
Szerintem nagyon el vagy tévedve. Szerverbe nem kell dedikált kártya, és grafikus felületet sem kell rátelepíteni (se Xorg, se GUI). Biztos hogy szerverről van szó, és nem mást nevezel annak? Ha meg HTPC-be kell, arra vannak speciális disztrók (OpenELEC, LibreELEC, stb.).
Az OpenCL konkrétan mihez kell neked? Mert azt csak a zárt driver támogatja (amdgpu pro), a nyílt driver (2D-ben amdgpu kernelmodult használ, 3D-ben Mesa-t) VA-API-t támogat (libva), de ez is elég ahhoz, hogy videókat hardveresen dekódoljon a kártya.
A PPA-t, amit javasoltak, azt hagyjad egyelőre. Ha nem segített elsőre a problémán, akkor később sem fog. Persze egy PPA-t nem elég hozzáadni, még telepíteni is kell róla a szükséges csomagokat.
-
Frawly
veterán
válasz
Rimuru
#57868
üzenetére
A „letakarítani” kitételt úgy értettem, hogy külön particionálós szoftverrel előtte eltávolítani mindent. Ha annyira Windows kell rá (itt jó indulattal feltételezzük, hogy legális, dobozos Windowsról van szó, rendes, buherálatlan telepítővel és érvényes termékkulccsal), akkor annak a telepítője eltakarítja majd. Nem kell még előtte külön „sikálgatni” Vimes drótkefével, meg dd if=/dev/zero-zni, meg a fene tudja mit szoktak még kitalálni a kedves felhasználók, csak hogy „tutira” menjenek, hogy a régi rendszernek az írmagja se maradjon ott.
Az Endless OS-t nem ismerem. Azt a topik alapján vágom, hogy valami Linux-alapú valami lehet. Azzal egyetértek, hogy elég bénák ezek az előtelepített rendszerek, de bajt szerintem nem okoznak.
Azt is értem, hogy ez itt OFF-nak tűnik, meg nem linuxos téma, windowsos topikba való, de azért fér el itt mégis, mert sok laikus felhasználó azt hiszi erről a problémakörről, hogy ez is a Linux hibája, pedig köze sincs hozzá. Ezért nem teszem ezt a hozzászólást sem OFF-ba.
-
Frawly
veterán
Sose értettem miért kell „letakarítani” az új gépet. Ha mindenképp Windowst akarsz a linuxos rendszer helyére, akkor szépen ráküldöd a Windows telepítőt, végigmész a telepítési folyamaton. Mikor a particionálásos részhez érsz, ott majd particionálja neked a Windows, meg ad arra is lehetőséget, hogy te hozz létre partíciókat. Semmit nem kell lesikálni, meg /dev/sdb1-ezni Gparteddel. Semmi köze nincs ahhoz, hogy milyen OS volt rajta előtte.
Egyébként milyen gép, milyen Windows pontosan. Ha nem látja a lemezt, nem tudja particionálni a Windows-telepítő, akkor az nem attól van, hogy Linux volt rajta előtte, hanem a lemezvezérlő drivere kell neki, de ez csak akkor jön elő, ha Win7 vagy annál régebbi Win-t telepítesz.
Szerk.: á, most olvasom, hogy a telepítő sem indul. Sima partíciót meg a BIOS egyébként sem fog látni. Írd ki a Windows-telepítőt Rufusszal UEFI módban.
-
#57841
Frawly
veterán
legenda007
#57839
Frawly
veterán
válasz
legenda007
#57839
üzenetére
Az Ubuntuval vagy a Minttel nem nagyon tudsz mellényúlni kezdőként. A sokféle verzió azért van, mert mindegyiknek más a grafikus felülete, erről YouTube-on találsz videókat (vagy kipróbálod ezeket a disztrókat telepítés nélkül Live módban), nézelődj melyik tetszik. Attól is függ, hogy mennyire gyenge a gép, mekkora RAM-mak, gyengébbre érdemes lájtosabb grafius felületet választani, igaz az fapadosabb is lesz.
-
Frawly
veterán
válasz
CPT.Pirk
#57795
üzenetére
Egyetértek, i5-i7-es laptopokon is ezt tapasztaltam 8-16 GB RAM mellett!!! Főleg az 5400 rpm-es HDD fogja vissza nagyon a rendszer sebességét. Amíg nem voltak ennyire lemezintenzívek az OS-ek, addig megtette egy ilyen HDD is, de ma már az SSD sem drága, akár használtan akkora méretben, amire csak a rendszer fér fel. A Win10 csak annyival speciálisabb, hogy az tényleg kiemelkedik ebben, tényleg csak az ellenségemnek kívánom, hogy HDD-vel használják.
-
Frawly
veterán
válasz
tboy93
#57792
üzenetére
Az akkor egy nagyon régi gép lehet, vagy nagyon alsó kategóriás. Már jó ideje van az olcsóbb noteszgépeken is vagy HDMI, vagy DP port, legalább egy alacsonyabb verziószámú, ami a FullHD-t kihajtja. A VGA port eléggé köhög ilyen nagy felbontásnál, meg nagyon elcseszi a képminőséget.
RDP-ben nem tudok segíteni, nem használok ilyen alkalmazást.
-
#57783
Frawly
veterán
King Unique
#57764
Frawly
veterán
válasz
King Unique
#57764
üzenetére
Igen, ezt 5400 rpm-es 2,5 colos HDD-vel tapasztaltam (a Win7, KDE-s Linux, nagyobb Mint-Ubuntu kiadások sem villám sebességüek az ilyeneken, de azért vállalhatók, míg a Win10 teljes tarkón lövés volt, használhatatlanul lassú), de feltételezem, hogy asztali 7200 rpm-es HDD-vel sem sokkal rózsásabb a helyzet.
-
Frawly
veterán
válasz
tboy93
#57753
üzenetére
A Linux jobban fut HDD-ről, mivel modernebb, kevésbé töredező, kevésbé belassuló fájlrendszerek vannak rajta, meg a kernel cache-elése is profibb, mint Windowson. Emiatt kevésbé hallod darálni a lemezt, gördülékenyebben használja azt. Viszont az SSD-t a Linux is meghálálja, ma már elég alap, régi gépbe is érdemes venni. Akár egy olcsó, márkátlan TLC SATA SSD is elég bele, csak ne HDD legyen benne.
Windowsnál meg a Win7 még elmegy HDD-ről, de a Win10 annyira lemezintenzív OS, hogy használhatatlan HDD-vel, csak SSD-vel használható tűrhető sebességgel.
-
Frawly
veterán
válasz
Frawly
#57716
üzenetére
Meggondoltam magam, nem dobom még az X-et. Nem mintha a Waylanddel bármi baj lenne, mert KDE5 alatt nem volt vele problémám egyáltalán, de az alkalmazások többsége mindig X-es. Azzal nem leszek előrébb, ha ezek XWayland emulációval futnak, csöbörből vödörbe szitu, akkor inkább hagyom.
-
Frawly
veterán
válasz
lev258
#57713
üzenetére
Na, arról szó sem lehet sajnos. Nem hinném ráadásul, hogy megoldaná, vagy ha megoldaná, akkor olyan áron, hogy beragadnék egy régi verziós kernelbe.
Wayland alatt úgyse használható az Xorg Intel driver, igaz nem Waylanden vagyok (az Openbox nem támogatja), hanem Xorg-on, de a Xorg drivert nem támogatják már egy ideje rendesen, szóval nem lenne értelme kitartani mellette.
Ez kicsit arra hasonlít, mint mikor az AMD befejezte a zárt driver kiadását újabb Xorg-verziókhoz. Abban a szituban is sokan próbáltak kitartani a régi Xorg mellett egy konzervatív disztróban, azt hitték, hogy majd megússzák az idők végezetéig a váltást, aztán minden disztróba eljött a 1.18-as Xorg (már az 1.19-es is), és végleg kampó lett a zárt AMD drivernek, mindenkinek át kellett állni nyíltra. Na, ugyanez lesz az Intel Xorg driverrel, csak még nem jelentették be hivatalosan, de már egyre több ember a modeset drivert használja helyette, és nem halogatja a váltást akkorra, amikor már elkerülhetetlen lesz.
-
Frawly
veterán
Talán nem kezdő kérdés, de kezdő is belefuthat. Arch Linuxon, Intel HD 3000-es GPU-s (prociba integrált GPU) gépen el kellett távolítanom a nyílt Intel drivert, mivel néha 1-2 percre beakasztotta a login managereket, és néha a leállítást, ilyen drm atomic helper flip out-os hibaüzenetre hivatkozva, amit a video=S-VIDEO1:d kernelparaméter sem oldott meg. Helyette most a 2D-s modesetting kernel Intel driver fut (meg 3D-ben továbbra is a Mesa 17.3.3 Direct Renderer). Sok disztró wikije írja azt, hogy elavult, nem tartják rendesen karban, nem érdemes már használni az xf86-video-intel drivert.
A gond az, hogy mióta a modesetting driver fut, azóta az mpv kimenete nem néz ki jól. Kásásabbak, zajosabbak a videók, míg a feliratok, OSD feliratai rendben vannak. Mintha kicsit rosszabb minőségű lenne a kép, pedig épp úgy opengl-hq kimenetet/profilt használok, lanczos skálázókkal, ahogy előtte. Érdekes, hogy csak mpv-ben van ez, VLC most nincs fent, böngészőkben oké maradt a képminőség. Leginkább alacsonyabb felbontású videókon jön elő, amik előtte szebben néztek ki. A nagyobb felbontásúakkal (720p és felette) nincs gond.
Mit lehetne ezzel tenni, hogy jobb legyen a képminőség? A gpu, gpu-hq kimenetet nem engedi használni.
-
Frawly
veterán
Ja, hogy még arra vonatkozott. Elnéztem a hivatkozási számot. Akkor meg van oldva, a 830 és a 850 is támogatja a hardveres AES titkosítást, és be lehet állítani hozzá ATA jelszót.
Elég összetett téma egyébként az ATA jelszó is. Röviden: nem érdemes a BIOS-ra bízni, de mégis abban kell először lejelszavazni, megnézni hogyan kezeli a jelszót (escape szekvenciákkal vagy nem), milyen karaktereket enged. Aztán ha ez megvan, törölni kell a BIOS-ban az ATA jelszót (ezzel minden adat elveszik a lemezről) és hdparm-mal újra jelszavazni, de úgy, hogy a master és user password is egyedi legyen, akár egybe is eshet. A BIOS-ra azért nem érdemes bízni, mert sok BIOS master passwordnak valami előre generált, utólag reprodukálható kódot generál, igaz az adatokhoz ezzel sem lehet hozzáférni, de a meghajtót nullázni lehet.
A másik, hogy a BIOS-nak is támogatni kell az ATA jelszót, igaz a legtöbb támogatja. Harmadrészt veszélyes művelet, mert ha az ember elbarmolja, nem jó a jelszó, a BIOS nem fogadja el, vagy elfelejti valaki, akkor kizárja magát az SSD-jéből örökre, és nem lehet feltörni (hacsak nem ilyen generált BIOS-os master jelszó van hozzá), ki lehet dobni az SSD-t a kukába, nem veszélytelen játék.
Ha érdekli core2-őt, tudok linkeket betenni. Fél éve csináltam ilyet két SSD-vel is, mindkettő Crucial MX300 (fél és egy terás modellek), egy X220-as ThinkPad-en BIOS-szal jelszavaztam le, egy másik Dell Latitude gépen meg hdparm-mal.
Szoftveres titkosításnál meg arra kell vigyázni, hogy menjen a TRIM, bár az meg a titkosítást gyengíti, de az SSD-nek kell a normális működéséhez. Ugyanis egész lemezes szoftveres titkosításnál az SSD egész felülete feltöltődik pszeudorandom titkosított adattal, és az SSD vezérlője úgy látja, hogy tele van a meghajtó hasznos adattal, és nem működik alapból a TRIM (ezt meg lehet oldani), meg nem tud működni a wear leveling.
Az SSD-nek ez az egy hátránya, nem jóbarátja a titkosításnak, de megoldható. Minden megoldásnak megvan az előnye és a hátránya is.
-
Frawly
veterán
Szerintem gyurmafigura keverte itt a szálakat. Angelotti a Samsung N145 Plus netbookjához keresett disztrót. Ahhoz ajánlottam, meg megemlítettem a bővítési lehetőségeket, hátha nem gondolt még rá. Szó sem volt SSD-ről, bár lehet van benne. Direkt visszamentem az előző oldalra, de ott sem találtam utalást a 830-as vagy 850-es Samura. Lehet még korábban volt róla szó, de 100 oldalt nem fogok visszaolvasni.
Angelotti: a Google mindig kever valamit a YouTube motorjában, hogy kicselezze a reklámblokkolókat, és le tudja tolni a felhasználók torkán a reklámot. Ezeket a variálásokat a youtube-dl leköveti, ezt használja az mpv lejátszó, az mpv-re meg az SMPlayer és az SMTube húz fel grafikus felületet. Pont most volt róla szó egy másik itteni topikban, hogy ezért kell mindig frissen tartani a youtube-dl-t, de néha az mpv/SMPlayer-t sem árt frissíteni. Erősebb gépen mindegy, mert lehet böngészőből tolni, és ott minden laptöltésnél frissül, de gyengébb gépen natív lejátszó szükséges, azt meg frissen kell tartani. A multimédia, netes dolgok ilyen műfaj.
-
Frawly
veterán
Nem látom hol írta, de legyen. SSD mindenképp kell egy ilyen gépbe, gyenge gépeken egy SSD sokkal többet gyorsít, mint az erősebb proci vagy több RAM. Elég bele egy legolcsóbb, noname TLC-s SSD is, csak ne HDD legyen benne. A 850-es Samu már túl jó egy ilyenbe, drágább, mint az egész gép, amibe belerakod, és nem tudja magát kifutni egy ilyen gyenge gépen, pénzpazarlás újonnan ilyet venni egy ilyen nethulladék gépbe.
growler: meg lehet próbálni a zram-tömörítést bekapcsolni, lehet segít egy kicsit, de nagy csodát nem kell várni tőle. Esetleg a swapiness-t lehet még levenni, hogy ne azonnal görcsöljön rá a swapra, de sokat ezzel sem lehet nyerni. A swapoláson még az SSD segíti a legtöbbet. Kevés RAM-ból nem lehet várat építeni, ahogy a dakota közmondás tartja.
-
Frawly
veterán
válasz
Angelotti
#57682
üzenetére
Hányas verziókat használsz ezekből? Terminálból indítva oda mit ír ki, miért nem viszi? Ha mpv backendet használ (ezt is nézd meg a beállításoknál, ne mplayer legyen, ha kell, tedd fel az mpv csomagot is), akkor tedd fel a youtube-dl csomagot is. Kellene vinnie, nálam a 18.1.0-ás SMPlayer/SMTube simán viszi. Ha gyorsan kell valami, amíg ezt meg nem oldod, addig a Minitube-ot is meg lehet próbálni, bár azt nem tudom, hogy az most hogy áll, leköveti-e a Google YouTube-os variálásait.
-
Frawly
veterán
válasz
Angelotti
#57673
üzenetére
Használtam ilyesmi gépet Arch Linux LXDE-vel. Neked mégse ezt ajánlom, mert a telepítésével gondjaid lehetnek (meg nincs belőle 32 bites már), helyette Sparky Linux konkrétan LXDE, Openbox, IceWM felületek valamelyikével, vagy AntiX. Esetleg ahogy írják, Lubuntu (ez Ubuntu LXDE felülettel), ezek lájtosabbak és gördülékenyebben futnak, mint egy SP3-as/POSReady XP. Szigorúan csak 32 bites disztró jön szóba, elég RAM nincs a 64 bites OS-hez. Xfce, LXQt, Mate, Cinnamon, Gnome3 felület már túl sok egy ilyen gépre.
Böngészőnek sem nem Firefox, sem nem Chrome/Opera. Helyette Pale Moon, ha rendszeresen kifutnál a memóriából, akkor Midori vagy QupZilla, esetleg Slimjet. Pale Moont csak arra érdemes használni, amit ezek nem nyitnak meg. 2-3 fülnél többet nem bír el egy ilyen gép egyik böngészővel sem.
YouTube-ozásra SMTube SMPlayerrel (mpv backenddel), videólejátszásra szintén ez. Max. 480p-s videók lejátszására képes a gép, a 720p már akadhat erősen, főleg teljes képernyőn.
Office-nak felmehet ugyan a LibreOffice, hátha valamit csak az tud normálisan megnyitni, de kínzóan lassú lesz a sok swapelés miatt. Így alap Office-ozásra inkább a AbiWord és Gnumeric legyen fent alapértelmezett alkalmazásként.
Intel Mesa driver legyen fent, és Compton kompozitor a grafikus felület mellé, hogy ne legyen képcsíkozás görgetés és videók alatt.
Esetleg ha nem forrasztott az alaplapon, és lehetséges bővíteni, érdemes bele venni +1 GB RAM-ot (DDR2-es van ezekben úgy tudom), és egy olcsó kínai SATA SSD-t (Kingfast, SanDisk, vagy márkásabb használtan) kisebb méretben, hogy ne legyen kínzóan lassú a gép. Ezek a kisebb bővítések nem drágák, ha online rendeled olcsó helyről vagy használt cikkes oldalakról.
-
Frawly
veterán
válasz
CPT.Pirk
#57622
üzenetére
Akkor meg is van a hiba. Nem az mplayer vagy mpv sara, hanem régi verziós a youtube-dl. Azt is rendszeresen kell frissíteni, mivel a Google néha naponta variál a YouTube rendszerében, ami érinti a letöltéseket is, és ezt a youtube-dl csapata mindig le is követi, csak a legújabb verziót kell használni belőle. Ha nem tudsz másképp frissíteni, mert a disztróban nem frissül, töltsd le kézzel a youtube-dl-t (nem bináris, hanem script alapú, függőségeket nem érint), és azt szintén kézileg lehet update-elni. Azt viszont nem tudom, hogy az mpv-t hogy lehet rávenni, hogy a külön letöltött youtube-dl-t használja. Lehet csak a /bin-ben kell symlinket csinálni neki.
Az a 15-ös SMPlayer elég régi, már a 18.1-es is kint van. Ezért nem jó konzervatív meg LTS disztrókat használni, hiába állítják, hogy a régi csomagok stabilabbak, de az elavultságuk miatt többet szívhat az ember, mint az új, instabilnak titulált (valójában viszont semmivel nem instabilabb) csomagokkal, disztrókkal.
Szép példa volt most erre az Ubuntu LTS is, a 4.4-es LTS kernelben a Meltdown/KTPI javítás először bootproblémákat okozott, míg az „instabil”, verzióhajhász disztrók (Arch, Fedora, stb.) friss kerneleiben (4.14.11-től felfelé, jelenleg 4.14.13) nem történt ilyen, pedig ott 24 óra alatt javították, míg a Canonicalnak majd egy hétbe tellett. Egyáltalán nem igaz, hogy ha a csomagok régiek, akkor kiforrottabbak és stabilabbak.
Mesa drivernél is láttunk olyat nem egyszer, hogy a régi verzióval megjelenítési hibák jöttek elő, míg a friss 17.2 és 17.3-as verzióval meg megjavult.
-
Frawly
veterán
válasz
#04441088
#57592
üzenetére
Ezt annyi ember beszopja, hogy el sem hiszed. Ez az rfkill lett volna a következő tippem. Mondjuk látom egyedi megoldások felé indultál el, de örülök, hogy működik, és nem kellett dmesg kimenet meg hasonlók.
Bluetooth is megoldódott ezzel? Mert vannak laptopok, ahol vagy külön kapcsoló van a BT-hoz, vagy a Wi-Fi kapcsolójával együtt kapcsolgatható ki-be.
-
Frawly
veterán
válasz
#04441088
#57582
üzenetére
A Bluetooth-hoz nem értek, de az Intel 2200-ás Wi-Fi kártyának mennie kéne, mert benne van a kernelben a drivere már elég régóta. Ha kell is hozzá firmware, azt a Lubuntunak tartalmaznia kéne.
Hányas Lubuntut próbálod? Terminálban a dmesg | ipw2200 parancs kimenete hogy néz ki?
-
Frawly
veterán
válasz
ubyegon2
#57566
üzenetére
A feltett mikrókódot ne szedd le, mert létező hibákat javítottak benne, nem dísznek adták ki. Ártani nem árt, nem lassít, ha fent van, legfeljebb nem aktiválódik, vagy aktiválódik, de a Spectre ellen nem lesz hatással. Várni kell szép fegyelmezetten, míg ki nem jön az összes csomag retpoline fordítással.
-
-
Frawly
veterán
válasz
#20749568
#57553
üzenetére
Azt ugye tudod, hogy az MS Office feltehető Wine alá? Esetleg ha anomáliába ütközöl, benyomod virtuális gép alá. Én azért nem kukáznék egy jól működő, komplett Linux rendszert, mert Állami Mancika elfingotta magát, hogy neki csak a Word a jó. Amúgy meg szoktasd őket szoba/PDF-tisztaságra. Küldözgetni a PDF való, mert azt nem kell a célállomáson újratördelni, minden gépen és mindenféle felbontás, képernyőméret mellett ugyanúgy néz ki, platformfüggetlen, nyomtatni is könnyebb. Ha nem akar beleszerkeszteni, akkor arra a PDF való. Tudom, semmi közöm hozzá, csak megjegyeztem a margón kívül.
-
Frawly
veterán
válasz
ubyegon2
#57535
üzenetére
Ez nálam is ilyen, Spectre1-2-vel szemben én is sebezhető maradtam sajnos. A Linux kernel egyelőre csak a Meltdown elleni patcht kapta meg (KPTI).
A Spectre1 és Spectre2 elleni sebezhetőségre nem elég az OS-t patchelni, hanem új mikrokód kell a CPU-ra (ez kvázi hardveres patch), vagy BIOS formájában (ami épp úgy az új mikrokódot kapja meg), vagy kernellel lehet betölteni. Ezzel csak az a baj, hogy az Intel csak az 5 évnél nem régebbi procikra ad ki új mikrokódot, az ennél régebbiek sebezhetők maradnak (ilyen pl. az én 2. gen. i7-em az ThinkPad X220-as notimban), AMD-nél nem tudom mit javítanak. Erre találta ki a Google a retpoline módszert (amit ez a teszter is említ), ez tisztán szoftveres megoldás (nem kell mikrokód, ennél a programkódban az ugrásokat olyan trükkel oldják meg, hogy a CPU elágazásbecslése a spekulatív végrehajtásnál ne tudja előre kitalálni az elágazásokat, ne tudja használni, így sebezhető sem lesz ez a mechanizmus), ez még nem érkezett meg a disztrók kerneleibe. Ez a retpoline amúgy sem konkrét patch a kódban, hanem a fordítókat patchelik (pl. gcc), és azok így oldják meg az elágazásokat, a lefordítandó forráskód nem változik, csak a lefordított gépi kódot optimalizálják máshogy, de mindent újra kell fordítani, az összes csomagot ezzel a módszerrel.
A jó hír, hogy alaptalanul riogatta a Meltdown-patch miatt, hogy -30% teljesítményvesztés. A gyakorlatban több mint egy hét után semmilyen lassulást nem tapasztalok. Phoronixos teszt szerint a retpoline-nak kiegészítve sem várható jelentős lassulás átlag felhasználásánál.
-
#57492
Frawly
veterán
God Vazzeg
#57489
Frawly
veterán
válasz
God Vazzeg
#57489
üzenetére
Nem kernelfüggő, már a negyedik gépen tapasztalom mindenféle disztró és kernel alatt, az asztali környezet is mindig eltérő, KDE, LXDE, Openbox alatt előjött, az is mindegy neki, hogy Gtk-s vagy Qt-s DC. Az a baj, hogy még bugként sem tudom lejelenteni, mert ki kell tölteni a bugreportnál egy olyan mezőt, hogy a bug reprodukálása, és ott nem tudok mit írni, hogy mit kell hozzá csinálni, hogy biztosan előjöjjön a hiba. Egy ideig a fülkezelésre gyanakodtam, mert mindkét panelen sok fület használok, de mióta rájöttem, hogy néha magától is csinálja, így ezt elvetettem.
-
Frawly
veterán
Szívesen. Viszont ha már itt egy kolléga, aki szintén DC-t használ, akkor megkérdezném, hogy nálad is csinálja-e, hogy néha elkezdi az egyik prociszálat maximumra pörgetni? Nálam ez a bug már vagy egy éve jelen van, és egyre súlyosabb, a Qt-s és Gtk-s verzióban is tapasztaltam. Néha csak meg kell nyitnom, nem csinálok vele semmit, és elkezdi a procit pörgetni. Nyilván csak egy szálon, mivel a többszálas végrehajtást nem támogatja a DC. Mindig csak arra leszek figyelmes, hogy süvít a laptopventi mint az állat.
-
-
Frawly
veterán
válasz
ubyegon2
#57454
üzenetére
Igen, mert még időben észrevette, hogy tévesen értelmezte a linket. Én viszont nem szerkesztettem ki, mert a kérdezőnek tanulságos lehet belőle megérteni a probléma természetét. Mikor még azt a hozzászólást írtam, még ott volt a link a hozzászólásából, aztán láttam, hogy kiszerkesztette, de így is jobbnak láttam nem kiszerkeszteni az enyémet.
-
Frawly
veterán
válasz
Rimuru
#57451
üzenetére
Ez nem azt csinálja. Egy egy meghajtóra csinál két bootolható rendszert, ilyet lehet, eleve az Arch.iso is ilyen. Mikrobi kollégának is ilyen van, bootol is neki UEFI-vel és BIOS MBR-rel is, 5 féle OS. De ő egyszerre akarja bootkor látni az összes rendszert, pedig tudtommal ilyet nem lehet, mert mire eljutunk a bootmanagerig, addigra már a gép kiválasztotta vagy az UEFI vagy a BIOS módot, de akkor már a meghajtón lévő bootképes rendszerekből már csak az ennek az aktív módnak megfelelő rendszereket látja és indítja. Ha viszont valaki a BIOS boot menüt indítja (tipikusan F12-vel), akkor még egy olyan ponton avatkozik be a folyamatba, amikor még mindkét mód aktív, és lehet az összes bootlehetőség közül választani.
-
Frawly
veterán
Olyan bootmanager nincs, ami az UEFI-s és BIOS-os rendszereket is tudja indítani, csak az F12-es megoldás játszik. BIOS-ban hiába állítod be, hogy UEFI + Legacy / Both bootot, az is csak azt csinálja, hogy először megnézi az UEFI boothoz talál-e bootképes GPT-s meghajtót (esetleg MBR-eset), ha nem talál bootképes meghajtót, akkor Legacy BIOS módban bootol MBR-t és aktív partíciót keresve, de akkor meg az UEFI módot kapcsolja ki. Olyan nem tud, hogy egyszerre kezel ilyet és olyat is.
XP-t száműzni tudnád virtuális gépre, ott is ki tudod próbálni a programodat, meg hogy küld-e trackinget. A MacOS meg csak UEFI-vel megy, igaz azt is be lehet tolni virtuális gépre.
-
#57367
Frawly
veterán
herdsman12
#57366
Frawly
veterán
válasz
herdsman12
#57366
üzenetére
fstab-ban hogy vannak csatolva a partíciók? Azt másold be. Amúgy meg a beleütközünk egy problémába (csíkozó képernyő, valószínű tearing), akkor megoldjuk, és nem váltunk helyette egy régi, támogatatlan verzióra, mert összességében csak még több, súlyosabb problémával találjuk szemben magunkat. Meg kell tanulni a problémákat megoldani az aktuális, támogatott verzión. Ahogy egy ismerősöm mondaná, ilyen ez a popszakma.
-
Frawly
veterán
Várjál, most trollkodás meg beszólogatás megy, nem illik ilyenkor holmi felesleges ontopik kérdésekkel zavarni a nagyérdeműt, még ha a topikcím az ellenkezőjére is buzdít
Amúgy ha van is Flash terület a WLAN kártyában, az csak a firmware felírással módosul. A disztrók a wpa_suplicant-os és/vagy NetworkManageres konfigfájlokban tárolják a legutóbb használt SSID-ket és jelszavakat, azért marad meg boot után. Ha live disztrót használsz, akkor nem marad meg, minden bootkor újra meg kell adni az SSID-t és a jelszót is. Nyilvánvalóan nem csak Win only feature, meg a Windows sem írogat az eszköz Flash-ébe ehhez az eltárolási művelethez.
-
Frawly
veterán
válasz
ubyegon2
#57352
üzenetére
Valóban nem kell felrakni, mert a kezdőknek szánt desktopbarát disztróba általában már minden fontos csomag bele van integrálva, kernel firmware csomag is, Mesa, Xorg, kompozitor, minden, ami csak kellhet, egészen a Flashig és a Javáig bezárólag, hogy kezdőbb felhasználónak ne azzal kelljen vergődni, hogy nem megy neki semmi, nincs kép, vagy van, de csíkoz vagy hullámzik, jajjmertnemmegysemmise, mert akkor a legtöbbnek elmegy egy életre a kedve a linuxozástól, és cuppantják vissza a Nyílászárók fedőnevű förmedvényt, meg jönnek a fórumra, hogy szaralinux, mert nem támogat lófügyköstsem, meg nem volt fejlődés 20 év alatt, mikor meg vindózalattbezzegmindenmegy.
Csakhogy mikrobi kolléga úgy döntött, hogy bepróbálkozik a haladóbbaknak szánt Fedorába, és ott nem uborkás életkép fogadja, hanem minden csomag nagyon friss, sok minden alapból nincs fent, és kicsit otthon kell lenni a konfigolásban is. Azt ettől függetlenül értem, hogy most Ubuntu alatt sem ment neki, abban nem tudok neki segíteni, ahogy írtam is, hogy a kernelnek ne kelljen nomodeset paraméter.
-
Frawly
veterán
válasz
ubyegon2
#57350
üzenetére
Az Ubuntu live-ról nem tudok nyilatkozni, AMD-s GPU-n nem próbáltam újabb Uborkát, még a 9.x-es időkben utoljára még 9600-as dedikált radeonnal használtam olyat, akkor nem volt vele gondom, de akkor még nem is használtam napi szinten linuxot fő rendszernek, Windows volt a fő rendszerem.
Annyiból speciális lehet az ő esete, hogy már a kernel driver sem megy normálisan, ezért kell nomodeset-eznie. Én meg arról beszélek, ha megy majd végre a kernel driver, és nem kell nomodeset, akkor is a Gallium nevű csoda vendégszeretetét fogja élvezni VMware in khórporétöd logó alatt, ha nincs fent a Mesa, vagy fent van, de nincs normálisan konfigolva.
-
Frawly
veterán
válasz
ubyegon2
#57350
üzenetére
Igen, csak akkor miért szerepel a te kimenetedben is a Mesa string? Azt a manók rejtették bele pofátlan módon a disztróidba, mikor senki nem nézett oda. Azért beszélek félre ilyen irányban. Majd próbáld ki, hogy távolítsd el a mesa csomagot, és nézd meg úgy hogyan fogod tudni használni a disztróidat.
-
Frawly
veterán
válasz
ubyegon2
#57347
üzenetére
Igen ám, mert a disztród úgy jött, hogy kapásból benne volt a Mesa driver, azért nem kellett külön semmit feltenned. Viszont a kolléga Fedorával akar próbálkozni, és abban lehet alapból nincs. Archban alapból nincs Mesa. Nem a kernelben van, fel kell rakni. Nem dísznek van nálad is az OpenGL stringben a neonfénnyel kivilágított Mesa 17.2.4 made in Vietnam logó. Másik variáció, hogy fent van a Mesa driver, csak valami konfig nincs rendben, és kéne módosítani. Addig meg VMware Gallium 0.4 llvmpipe című szopás lesz belőle, nomodeset-tel és anélkül is. Persze lehet annyit tévedek, hogy a kernelben is lehet gubanc, ki kell próbálni más verziójú kerneleket is.
-
Frawly
veterán
Nagy tévedés. A kernel driver csak 2D-s megjelenítésre szolgál, max. arra jó, hogy bebootoljon, meg legyen kép. Abban a pillanatban, ahogy 3D-s alkalmazást akarsz futtatni, vagy akarsz vsyncet (tearing ellen), vagy kompozitort használnál (szintén vsynchez vagy 3D asztali effektekhez, és ez kell a Compiznak is) ahhoz rendes hardveres gyorsításos 3D-s driver kell, az meg nincs benne a kernelben egyik GPU-hoz sem.
Tudom mit beszélek, annak idején ugyanezt kínlódtam végig Intel-vonalon egy szutyok GMA 3600-as GPU-val, az is CPU-ba integrált csoda. Annál ugyanígy van, van a kernelbe beépített driver, de az csak 2D-re jó, meg alap energiagazdálkodásra. Minden másra annál is kellett a rendes Direct Renderinget (DRI-nek vagy DRM-nek is nevezik) használó hardveres gyorsításos driver, amit fel is tettem, csak semmi nem támogatta, a Mesa sem, így a Mesa-ból a fallback software-es render futott, ezért ugyanezt a szoftveres VMware Gallium 0.4 llvmpipe drivert használta, amit nálad is ír, és ezzel se hardveres gyorsítás, se DRI, se vsync (még kompozitorral sem) sincs. Csak arra volt jó, hogy legyen egyáltalán kép korlátozott felbontásokban (ami nekem mákomra elég volt, de azért hiányzott a rendes driver).
A 16.04-es meg annál régebbi uborkák még régi Xorg-ot használtak, meg gondolom már Live módban is bennük volt a régi Catalyst driver, így kapásból ment minden. Csak azóta mennek a fejlesztések, léptetik a verziókat, az AMD meg nem támogatja többé a Catalyst/glrfx drivert, helyette a Mesa-ba segít be.
-
Frawly
veterán
válasz
ubyegon2
#57338
üzenetére
Azért van ott WMware, mert az a cég kezdte fejleszteni a Mesa drivert. Annak is főleg a szoftver render részét. Azóta beszállt az AMD és az Intel is. Ha rendesen megy a hardveres gyorsításos driver, ami használja a GPU-t, akkor nem VMware-t, meg Galliumot ír ki, hanem Intel Mesa-t, vagy AMD-t ír ki (ahogy nálad is).
Semmilyen kernelverzióra és bugreportra nem kell várnia a kollégának, ez inkább a xorg verziójától függ. Fel kell rakni a szükséges csomagokat, és menni fog.
-
Frawly
veterán
Persze, hogy ezt kapod, mert Live alatt nincs fent az a szükséges videódriver, ami az AMD APU-nak kell. Az Gallium 0.4 on llvmpipe (LLVM 4.0, 128 bits) azt jelenti, hogy csak szoftveres (nem hardveres gyorsításos) render van, ami egyfajta falback vészmegoldás csak, és egyáltalán nem használja a GPU-t. Rendesen fel kell telepíteni a disztrót a gépre, nomodeset-tel bebootolni, feltenni a megfelelő AMD drivert, és utána mennie kell nomodeset nélkül is. AMD-nél nem tudok túl sokat segíteni, mert azzal nincs linuxos tapasztalatom, de annyit kihámoztam neked gyorsan a netről, hogy
1) Az A10-es CPU-dban AMD HD 7760d-s videóchip van
2) Mivel ez CGN4-est támogat
3) Ezért a mesa-amdgpu drivert kell feltenni hozzá (röviden csak mesa a csomag neve)
4) Ha nem lenne fent, kell hozzá a linux-firmware csomag is
5) Miután fent van a driver, nem szabad nomodeset-et használni
6) Mivel ez a kártya Southern Island kódnevű, az initramfs-t használó disztrókban (és itt rohadt nagy mázlid van, hogy nem csak az Arch az, hanem Fed Dórika is ilyen, fetrenghetsz vele egy plusz kört) az mkinitcpio conf-jának a MODULES résznél tartalmaznia kell "amdgpu radeon" modult az ELSŐ helyen, amit életbe kell léptetni mkinitcpio futtatásával is.
7) Nem feltétlenül szükséges, de a vulkan-radeon libva-mesa-driver libva-vdpau-driver mesa-vdpau csomagokat is fel lehet tenni, ha szükséged van ezekből valamire, az első Vulkan-os játékokhoz kell, a többi meg hardveres kódoláshoz (videólejátszás, kódolás, brute-force progik, stb.).
8) Nem feltétlenül szükséges, ezt csak én javaslom, de nézd meg, hogy abban a DE-ben, WM-ben, amit használsz, megy-e a kompozitorRészletekért kérdezze meg kezelőorvosát, vagy az Arch Wikit. Fedora alatt ezeket a csomagokat lehet kicsit másképp hívják, de nem kéne gyökeresen eltérőnek lennie a csomagneveknek, itt-ott egy szó vagy kötőjel különbség az Arch-hoz képest. Régi Uborka alatt szerintem meg még régi Catalyst driver volt, de attól mindenki könnyes búcsút intett onnantól fogva, hogy xorg 1.18 és attól újabb verziókon NEM támogatott többé, és nem is lesz.
-
Frawly
veterán
válasz
ubyegon2
#57302
üzenetére
A CoD-ról nem tudok nyilatkozni, azt nem néztem, csak a MoHAA-t. Ahogy viszont bogarásztam az opensource portos játéklistákat, nem rémlik CoD-port.
Szerk.: Most így utánanézve, nincs linuxos portja. Ez elég gáz, mert elég lenne vagy a MoH vagy a CoD valamelyik verziójához egy portot rendesen megcsinálni egyszer, és annak mintájára már könnyű lenne tovább portolni a két sorozat szinte összes részéhez. Ahogy a Doom, Duke32, Quake1-3 portok is használhatóak nem csak a vonatkozó alapjátékokhoz, de az összes kiegészítőhöz és ráépülő játékok többségéhez.
Egyébként sose értettem, hogy játékstúdióknak, kiadóknak minek kell rajta ülni 15-20 éves abandonware játékok kódján, miért nem lehet opensource-ként kiadni, ahogy az ID software szokta (tette a Quake, Doom, stb. sorozattal). Annyira szívesen nyomnám pl. a Mafiát, Far Cry-t ilyesmiket Linuxon, de nincs hozzájuk natív port, Wine alatt meg vagy bugosan futnak vagy sehogy. Miért nem lehet kiadni ezeknek a forráskódját? Nem lopná el senki, ilyen régi játéktechnológiákkal már nem lehet komoly pénzt keresnie a konkurenciának sem, meg ettől a játék maga nem válna ingyenessé (pályák, textúrák, hangfájlok továbbra is szerzői jogi védelem alatt maradnak), csak portok készülnének ezekhez a game-ekhez, ami a kiadónak sem lenne hátrányos, úgy könnyebben árulhatná őket minden platformon. Egyszerűen szarrágás, hogy nem adnak ki hozzá linuxos binárist, de azért a kódon is rajta ülnek, hogy más se tudjon, dögöljön meg a szomszéd lova is. Ráadásul kiadott forráskódnál nem csak linuxos port készülne, hanem MacOS-től kezdve az Androidon át mindenre megcsinálná a közösség. Egy ilyen MoHAA-szintű, korú game-et már egy alsó kategóriás mai olcsó, kínai MTK-s okostelefon is röhögve elvisz.
-
Frawly
veterán
válasz
ubyegon2
#57294
üzenetére
A MoHAA-t nemrég próbáltam natívban Arch Linuxon, és nekem nem futott rendesen. Van ugyan hozzá Open MoHAA, de túl régi bináris. Le lehet forgatni forráskódból, de azzal is problémába futottam. Pedig szeretnék vele játszani én is. Elindul, de nincs hang. Egy elavult, OpenAL-es extension hiányzik neki alutLoadMP3_LOKI néven. Ennek nincs megfelelője modern rendszereken, és a forráskódból forgatásnak is gátja.
-
#57297
Frawly
veterán
tordaitibi
#57260
Frawly
veterán
válasz
tordaitibi
#57260
üzenetére
Igen, ezzel a tárolón kívül telepítésnek van egy csomó nyűgje, kapásból, hogy a függőségek is túl régiek lehetne.
Próbáld meg archívumkezelővel megnyitni a deb fájlt, és kibontani egy tetszőleges könyvtárba. Majd onnan indítsd az Opera 36-ot.
-
Frawly
veterán
válasz
lev258
#57250
üzenetére
Videója válogatja. Amúgy ami nem akad, az is csíkozni fog, lehet nem használta még addig, hogy feltűnjön neki. Sajnos az Atom procik nem csak gyengék, hanem tényleg szarrock is, ez a kettő modell meg ezzel a GPU-val durván kiemelkedik. Amit mostanában még kerülni kell azok az Intel N-es procik, na azok még olyan hulladékok, hogy egy nagyobb Facebook-oldaltól letérdelnek akármelyik böngészőben, bár azokban legalább használhatóbb GPU van beleintegrálva, nem PowerVR-os szar, de azért hulla gyenge cucc az egész a mai kor követelményeihez képest, és akkor mi lesz még 3-5 év múlva.
-
Frawly
veterán
válasz
Tarill
#57251
üzenetére
Tapasztalatom szerint a kisebb bitrátás YouTube 720p-s videókat viszi, a nagyobb bitrátás 720p-t, és afölött meg reménytelen. Csak csíkozni fog a képernyő. A kompozitor ezen valamennyit tompíthat (Xfce-nek, MATE-nek van saját kompozitora, a többihez a Compton-t ajánlom), de nem tünteni el, mert tearing ellen vsync kell, vsynchez meg direct renderinget használó rendes 3D-s driver kell, ami meg nincs ezekhez a GPU-khoz. Értem, hogy ezek rossz hírek neked, pont azért hívom fel a figyelmet, hogy nem érdemes vele szívni, tapasztalatból tudom.
Az még jobb, ha nem laptop, hanem csak ITX lap, akkor vegyél bele egy normális ITX-es lapot valami olcsóbb, régebbi generációs i5-ös procival, azzal nem fog akadni semmi (jó, a 4K az lehet, de pl. 1080p-ből még a legdurvább bitrátás, 60 fps-ses anyag sem fog akadni), lesz mindenhez driver, nem fog válogatni RAM terén sem.
A Mint Mate, Mint Xfce, Lubuntu, stb. nem butított, mert teljes értékű disztró, csak a grafikus felület egyszerűbb rajta, nem annyira csilivili, így pedig a RAM igénye lényegesen kisebb, kicsit a CPU-igénye is.
-
Frawly
veterán
válasz
Tarill
#57240
üzenetére
Az Atom N2600 és a D2700 a legszutyokabb proci, amit elmúlt 15 évben kiadtak, és a beleintegrált GMA3600 és GMA3650 pedig a két legszutykosabb VGA-lassító chip, amit a földkerekségen valaha kiadtak, még a hulladék PowerVR-os chipek között is a létező legocsmányabbak. Linuxra abszolút nincs hozzájuk 3D/DRI driver, csak 2D-s szoftver renderes driver a kernelben, egyáltalán nem lesz Vsync vele, nem fognak menni a 3D-s alkalmazások, még a böngésző sem tudja majd használni a 3D-s gyorsítást, tearingelni fog a kirajzolás még kompozitorral is, nem csak görgetés közben, de videólejátszás alatt is.
Ezekhez elvileg Windows 7-re vannak csak driverek, de már az alatt sem működik, mert látszólag felmegy, de ott is tearing van, meg nem futnak a 3D-s alkalmazások, képi hibák vannak, meg lefagynak, vagy el sem indulnak. Ezek a hulladékok Windows alatt is használhatatlanok. Dobd ki a szemétre, komolyan mondom. Tudom miről beszélek, volt ilyenem nekem is. Vegyél helyette egy olcsó, használt, refurbished X220, X230-as Thinkpadet, vagy Dell 6230-at, elég olcsóak ezek már, és normálisabb CPU/GPU-val kapod (ami tényleg normálisan működik minden OS alatt, 64 biten is), meg több giga RAM-mal, és csak 2 inch-csel nagyobbak, mint a 10 inches, semmire nem jó atomos netbookok, és alig drágábbak. Az említett üzleti subnotik tartósabbak, gyorsabbak, nem avulnak el még sok évig. Ezek az atomos netbook-hulladékok már a kiadásul pillanatában használhatatlan és elavult szutykok voltak, sem nem megbízható, sem nem tartós, de terméktámogatás, se driver. Jó, hogy már nem gyártják őket, tényleg a legalját képviselték mindennek.
-
#57248
Frawly
veterán
tordaitibi
#57230
Frawly
veterán
válasz
tordaitibi
#57230
üzenetére
Írja, hogy milyen csomagok hiányoznak neki (openjdk-6-jre, java2-runtime), ezeket kéne felrakni sudo apt-get install paranccsal, majd újra próbálkozni sudo dpkg -i Opera36-csomagja.deb-bel. Fontos, hogy tényleg ne legyen megnyitva a csomagkezelő másik példányban, mert lock-olásra fog hivatkozni megint.
-
Frawly
veterán
Pontosan milyen gépről is van szó? De nem úgy értem, hogy régi, vagy új, meg hogy kocka alakja van, meg virágváza van-e rajta, hanem pontosan mik vannak a konfigban. Milyen disztróval voltak teljesítményproblémáid? Ne csak disztrónevet írj, verziót is.
Egyébként ha teljesítményproblémát érzékelsz, az vagy videókártya driver problémájára utal, vagy az adott géphez (CPU+RAM) nem illő grafikus felület erőltetését.
-
#57220
Frawly
veterán
tordaitibi
#57205
Frawly
veterán
válasz
tordaitibi
#57205
üzenetére
Az az oldal valóban nem működik, csak a legújabbat engedi letölteni. Itt van a 36-oshoz működő link az Opera fájlszerveréről. Elvileg Mint alatt a grafikus csomagkezelő vagy archívumkezelő meg fogja nyitni, ha az első nyitja meg, akkor telepíteni kell, ha a második nyitja meg, akkor tetszés szerinti helyre ki kell bontani. Vagy terminálból a dpkg -i paranccsal telepíteni.
Amúgy ezen még rugóznék, hogy pontosan milyen NPAPI plugin miatt kell? Mert ha Flash, az nem a DVR-en múlik, hanem a Pepperflasht kéne feltenni, és működni fog tovább a Flash-kontent az eszköz webes felületén.
Szerk.: ha ActiveX kell, az nem fog menni semmilyen más böngésző alatt, az csak IE/Edge only. Akkor lehet azt csinálni, hogy Wine-t telepítesz, abban van legacy IE, és az talán tud ActiveX-et.
-
#57207
Frawly
veterán
tordaitibi
#57205
Frawly
veterán
válasz
tordaitibi
#57205
üzenetére
Választani kell a lenyíló két listában disztrót és csomagformátumot, a két vastagított sor alatt. De ne tedd! Fő szabály, főleg kezdőknek, hogy tárolón kívüli forrásból nem telepítünk semmit sem. Esetleg ha nem is fő hivatalos tároló, de valami megbízhatóbb PPA, vagy annak megfelelő külsős tároló. Ilyen-olyan oldalról összevadászott szoftvereket nem használunk.
A böngésző meg pláne egy olyan műfaj, hogy csak új verziót használunk belőle, mert az egyrészt benne van a tárolókban, és magától is fog frissülni a jövőben, másrészt meg a web mindig változik, tartani kell a lépést feature-ben, és foltozottságban biztonságilag.
Kezdjük ezért az elején. Mi az, amihez neked 36-os Opera kell és nem jó a legújabb? Melyik disztróhoz is kéne ez neked?
-
Frawly
veterán
Ne haragudj, de annyi szakmaiatlan dolgot írtál, hogy nem bírom ki, hogy ne válaszoljak. Valahogy az tűnik ki az írásodból, hogy te nem tudod mit beszélsz.
Linuxon nincs szükség drivernyilvántartásra, mivel nem kell vele egyáltalán vergődni, de a legrosszabb esetben is max. a hálókártyához VAGY Wi-Fi-kártyához ÉS a videókártyához kell driver, hangsúlyozom, a legrosszabb esetben, mert reálisabb esetben ezek közül is csak egy egyikhez vagy egyikhez sem. Ehhez nem kell nyilvántartani semmit, friss kernelt kell használni meg frissített rendszert, és a rendszerrel frissülni fog a driver is, együtt a többi alkalmazással, egyenesen az ellenőrzött tárolóból. Egyébként Linuxon is lehet listába rendezni (grafikus és konzolos felületen is), hogy milyen csomag van fent, milyen verzió, mik a függőségei, hogyan került fel, ez kb. helyettesíti azt a listát, amit említettél. Nyilván nem teljesen olyan, mint Windowson, de szükség sincs rá, mert a Linux nem Windows, eleve más elvek mentén működik, nincs exe/dll, nincs registry, más forrásból kerülnek fel az alkalmazások és rendszerösszetevők, máshogy kezelik a drivereket, stb..
Aki meg CMS-t, Drupalt, PHP-t azért használ, fejleszt Windowson, mert van rendszer-visszaállítási pont, az egy kontár. Egyrészt erre rendes fejlesztőkörnyezetben a verziókövető rendszerek valók, másrészt meg Linuxon is vannak a visszaállítási pontoknak megfelelő mentésekre megoldások, kapásból a Btrfs, ZFS fájlrendszerekben van snapshot funkció, ami megbízhatóbban működik, mint a Windows visszaállítója, utóbbi vagy sikerrel állít vissza, de sokszor nem. Saját szememmel láttam, hogy Windowsok nem is olyan régi, utolsó visszaállítási pontot nem tudnak visszaállítani, mikor kéne, és elég hozzá egy elcseszett drivert feltenni, hogy aztán se csökkentett módban, se korábbi visszaállítási ponttal se lehessen visszahozni a működő rendszert (max. csak lemezképből). És ezt úgy írom, hogy nem csak az XP-t meg a 7-est ismerem valamennyire, hanem az összes eddig megjelent verziót, jó, talán a 8.x-et és a Server kiadásokat kicsit felszínesebben.
Linuxhoz az oktatóanyagokat el lehet felejteni. Eleve a tananyagok tradicionálisan nehezen követik le a változásokat, és a 99%-uk még a systemd előtti időkből való, már csak emiatt is nem valami hasznosak, de a többség mindig is elavult és túl elméleti volt. Linuxot, ahogy más dolgokat is az IT-ben, gyakorlatban kell tanulni, fel kell tenni, ha más nem egy tesztrendszerre vagy virtuális gépre és használni. Úgy lehet menet közben megismerni, meg egyes problémák megoldásakor apránként utánaolvasni, hogy mi micsoda a rendszerben, miben tér el a Windowstól. Hangsúlyozom, hogy a felmerülő problémákat megoldani kell, és nem megkerülni windowsos dualboottal meg Wine-os megoldásokkal, mert úgy nem a Linuxot fogja a delikvens megtanulni, hanem a dualboot és a menekülőutak művészetét. Használni kell és nem szabad feladni. Plusz nem szabad elvárni, hogy úgy működjön, ahogy a Windows.
-
#57012
Frawly
veterán
tordaitibi
#56999
Frawly
veterán
válasz
tordaitibi
#56999
üzenetére
Erre a parancsra tudsz asztali ikont csinálni vagy hotkeyt rendelni:
sleep 1 && xset dpms force offEz kikapcsolja a monitort 1 másodpercnyi várakozás után, játszhatsz az értékkel. Elvileg lehet 0 is, de az rendellenes működéshez vezethet.
A hibernáláskor a RAM tartalmát kiírja lemezre és úgy teszi stand by-ba a gépet. Felfüggesztéskor (sleep) a RAM-ban hagy mindent és úgy megy le stand by-ba, viszont ha áramszünet van, vagy lemerül az akksi, és emiatt elveszik a RAM tartalma, akkor nem tud visszajönni a rendszer, hanem újra kell bootoltatni.
A youtube-dl használata terminálból tényleg körülményes, de én pont azért szeretem, mert nagyon jól meg lehet adni, hogy mit töltsön le, és ez mindig jól szedi le a videót, a megfelelő változatot, nem úgy mint a különböző kamu downloader meg one-click szoftveres baromságok, és mindig leköveti a Google variálásait, sose avul el. Ha annyira zavar, hogy kényelmetlen, akkor van hozzá grafikus frontend youtube-dl-gui néven vagy van egy másik megoldás youtube-dlg.
-
Frawly
veterán
válasz
okoska74
#56959
üzenetére
Nincs igazad, hidd el. Kezdőnek jobb a DE, minden bele van drótozva, hálózatkezelés, hangerő, vezérlőpult, login manager, kompozitor, stb.. WM-nél erről mindről az embernek saját magának kell gondoskodni, tudom miről beszélek, magam is Openboxot használok.
Az mc, vi megint csak olyan, amivel egy kezdőt nem érdemes összezavarni, csak megutálja a Linuxot és húz vissza Windowsra. Persze, néha elengedhetetlen a terminálozás, de akkor abból elég egy nano szintű valamit meg a csomagkezelőt ismerni. Az mc egyébként még oké az mcedittel együtt, ha Windowson is használt kétpaneles fájlkezelőt, vagy DOS-on valami hasonló anno.
Mai gépeken meg nem nyersz sokat, ha minden hozzá van forgatva a géphez. Az, hogy a binárisok mérete fele akkora lehet, megint nem tétel, terabájtos háttértárak vannak, SSD-ből is a min. 120 gigások elterjedtek, nem számít, hogy a rendszer 4 vagy 8 gigát foglal, esetleg 20-at. Plusz a repók binárisai azért nagyobbak, mert általában debug symbol és minden szar bele van fordítva, ezeket ki is lehet szedni belőle, csak nem érdemes szenvedni vele. Ezt leszámítva mai modern gépen sebességben sem nyersz, ha saját magad fordítasz mindent. Lehet még a P2-P3-as korszakban számított, most már a C2D-s korszak óta felesleges ezzel gyűrődni. Kernelt is ezért nem forgat már senki, pedig nem bonyolult kezdőnek sem, forráskód letölt, tar xf kiadásával kibont, make menuconfig - default config kiválaszt (de talán már erre sincs szükség), make és 15 percnél kevesebb idő alatt lefordul egy modern procin (csúcs, high-end procin 3 perc körül), csak minek. Már csak akkor forgatnak ilyesmit, ha nagyon speciális igényekhez kell, vagy azt benchmarkozzák, hogy mennyi idő alatt fordul le a kód. Messze vagyunk már attól, mikor egész nap, vagy egész éjszaka fordult a kernelkód, és külön fekete mágia volt konfigurálni a fordítást.
Plusz ha valami rollingos disztrót használsz, akkor gyakran jönnek a frissítések és új verziók, nagy szopás mindegyiket forrásból fordítgatni, csak időmilliomoséknak ajánlott.
-
Frawly
veterán
válasz
Norby86
#56861
üzenetére
Csak ezért ne kezd el módosítani. Annyira mellényúlni az MBR-rel sem tudsz. Arról is lehet másolatot készíteni a dd paranccsal, és azt tárolod egy másik diszken, de akár még egy HDD-re ragasztott matricára is ráírhatod, hogy hányadik szektortól a hányadikig húzódott rajta a partíció és mi volt a típusa, ennek alapján újra lehet kreálni a partíciós táblát abban az esetben is, ha elveszne. Adattárolós HDD-nél szinte mindegy melyiket használod, GPT vagy MBR, hitvallás, ízlés kérdése. Ha így működik MBR-rel, akkor ne piszkáld.
-
#56863
Frawly
veterán
Core2duo6600
#56858
Frawly
veterán
válasz
Core2duo6600
#56858
üzenetére
Az mkfs (konzolban vagy terminálban) valamelyik változatával lehet partíciós tábla és partíció nélkül fájlrendszert létrehozni. Tehát vagy mkfs.ext4 vagy mkfs.ntfs, célnak meg a /dev/meghajtó_nevét adod meg számozás nélkül, pl. sudo mkfs.ext4 /dev/sdb és ennyi. De mondom, hogy ez csak Linux alatt működik, esetleg BSD-k alatt, de ebben már nem vagyok biztos.
Windowsban is lehet hasonlót, Lemezkezelőben rámész a meghajtóra, esetleg törlöd róla a meglévő partíciókat, és kiválasztod hozzon létre az egész meghajtón ún. dinamikus kötetet (vigyázat, ilyenkor nem NTFS fájlrendszer kerül a meghajtóra). Amint kiválasztottad, utána figyelmeztet is a Windows, hogy később ezt nem tudod más fájlrendszerré konvertálni, meg bla-bla. Ez a fajta windowsos dinamikus kötet meg más OS alatt nem működik, mert fájlrendszer nélküli meghajtónak látszik (RAW fájlrendszer).
Egyik megoldás sem ajánlott, csak annak, aki tényleg tudja mit csinál, és tényleg erre van szüksége.
-
Frawly
veterán
válasz
Smiley
#56842
üzenetére
Szerintem azért nem lovagolunk, szakmai dolgokat beszélünk meg pro és kontra, erre lenne való a fórum.
Valóban játszik az a lehetőség is, hogy mindjárt az egész lemezen legyen a fájlrendszer, mindenféle partíció és partíciós tábla nélkül, ez pont fel is merült itt a topikban korábban, amikor a kolléga véletlenül formatált sdb1 helyett /dev/sdb-re. Linux alatt ez simán működik, de pl. Windows nem tud mit kezdeni a particionálatlan meghajtóval (kivéve ha a saját RAW formátuma), meg BSD sem tudom mit szól hozzá.
-
Frawly
veterán
Ezt jó tudni, elteszem későbbre. Nekem anno nem sikerült, próbáltam Legacy bootot GRUB2-vel GPT-s diskről és nem ment, nem talált a BIOS bootolható eszközt. A GRUB2 feltelepült, beírta magát a lemez elejére, de nem ment a boot. A net azt írja, hogy lapfüggő, melyik BIOS viszi a GPT-s bootot.
HDD-nél ha gépben van, akkor egyrészt a GPT előnye, hogy EFI bootkor gyorsabban detektálja az UEFI a lemezmeghajtókat, kevesebb POST tesztet végez, ezért bekapcsolási időben lehet nyerni fél-egy-két másodpercet, lapfüggő. Meg ott a másolat a partíciós tábláról a lemez végén. GPT-nél további előny, hogy nem kell elsődleges és bővített/logikai partíciókkal szívni, meg nincs ott a 4 elsődleges partíció korlátja, hanem lehet 128 partíció kapásból. Nyilván 128-ra nincs szükség reálisan, de mondjuk 5-6 partíciónál már kényelmesebb lehet, mint az MBR.
USB-s HDD-nél viszont tényleg mindegy, hogy MBR vagy GPT van rajta, mérethatártól függ, kell-e rá 2,2 TB-nál nagyobb partíció, vagy inkább több 2,2 TB-nál kisebb partíciókra osszák fel. Attól is függ, hogy használják-e ezt a HDD-t régi OS-sel.
Ökölszabályként azt mondanám, hogy ha nem szükséges túl régi gépeken használni vagy régi OS-sel, akkor érdemes mindent GPT-vel használni ma már, haladni kell a korral. MBR-t csak a legszükségesebb esetekben kéne már csak használni, mikor tényleg valami nyomós ok van rá.
-
#56781
Frawly
veterán
King Unique
#56780
Frawly
veterán
válasz
King Unique
#56780
üzenetére
Így van. Ezt mondom mióta. Hiába írja a Windows, hogy 931 GiB szabad, ha pl. kapásból ott a frissen formázott partícióból azt mutatja, hogy néhány száz mega kapásból foglalt. Akkor már eleve nem 931, hanem 930 egész valamennyi. Az biztos, hogy az ext4 overheadje nagyobb, mint az NTFS-nek, de nem hinném, hogy 1 terás vinyónál számítana az a 10 GiB-nyi különbözet, azon már semmi nem múlik. Sokkal többet számít, hogy az ext4 nem töredezik annyira, meg fejlettebb a naplózása, míg az NTFS egy nagyon erősen töredező, elavult, koros fájlrendszer. A kettő között fényévek vannak technológiailag.
-
Frawly
veterán
válasz
Norby86
#56770
üzenetére
931-ed soha nem lesz. Ha még ki is kapcsolod a tartalékolást, meg kikapcsolod a naplózást, a fájlrendszernek akkor is van valamekkora overheadje, az ext4-nek csak 1-2%, de ahhoz pont elég, legyen egy kis híja a 931-nek. Én NTFS-nél sem hiszem el, hogy 931 van szabadon, mivel annak is van overheadje (fájltárolási táblák, metaadatok, journal foglal némi helyet az érdemi adatok kárára). NTFS overheadre 100 MB-os partíciónál 4 MB-ot ad meg a MS, de ebből nem következik, hogy 931 GiB-nál ez mennyi, le kell mérni, de lefogadom nem 4 MB, hanem lényegesen több.
Overheadje van a partíciós táblának, meg lejön az első partció előtt hagyott partícionálatlan terület is (általában 1MB), igaz ez nem GB-ban kifejezhető, de már ez is elég arra, hogy ne 931 GB-nyi szabad hely maradjon.
Ha pedig levonod az overheadet, kapsz egy számot (hasamra ütök, legyen mondjuk 917 GB), akkor még azt sem tudod mind kihasználni, mert fájlvégi töredékek is lefoglalnak egy egész tárolási egységet (egy fájlba tömörítve mindent ez elkerülhető), így mindig lesz egy kis pocsékolás, sose lesz az adattárolás 100%-os hatékonyságú. Persze azt értem, hogy a laikus beszalad a boltba a 1 terás HDD-ért vagy SSD-ért, és még haza sem ér vele, gondolatban már fel is tölti 1024 GiB hasznos adattal, aztán csalódás lesz a vége. Ökölszabályként úgy lehet rá tekinteni, hogy 1 terás meghajtóra kb. 900 GiB adatot tudsz kb. tenni, ha nem tárolsz rajta túl sok kis fájlt.
-
Frawly
veterán
válasz
Apollyon
#56722
üzenetére
Nem értem milyen pendrive-ról van szó, egyterás HDD-t emlegetett a kérdező, nem látom be, hogy arra minek ext2. Még pendrive-ra sem tennék már ext2-őt, ha csak sima adattárolós pendrive, elfér a kevés naplózás, annyiba nem hal bele, és inkonzisztenica esetén visszahozhatók az adatok. Az ext2 akkor jön jól, ha rendszert telepítünk pendrive-ra, és minden bájt számít, hogy kevesebb írást kapjon, vagy valami nagyon régi géphez csatlakoztatják, ilyen ősrégi 2.2-2.4-es kernellel, ami nem kezeli jól az ext4-et, de még talán az ext3-at sem, és muszáj legacy ext2-t (most jól írtam, esküszöm) használni.
ubyegon: nem vagyok SSD doktor. Csak beleástam magam a témába, a neten sok bullshitet lehet sajnos olvasni. Sokáig nem volt SSD-m, amit meg is bántam, sokkal előbb áldoznom kellett volna rá. Már nem olyan nagyon drágák, nem éri meg ilyen kisebb tételeken rágni a barnást, meg HDD-vel és pendrive-val szenvedni, ha nem muszáj. Nyilván azért ezeknek is megmarad a használati köre az SSD-vel szemben, csak szűkül.
A FreeDOS-ról kiderült, hogy nem támogat UEFI bootot, akkor viszont nem tudom mi célt szolgál a külön Legacy image. Kiírtam dd-vel a normál .iso-t, átállítottam a Bootot EFI + Legacy-ra, és úgy sem bootolt szégyen szemre. Úgy kellett az SSD-re QEMU virtuális gép alól feltelepíteni a FreeDOS Base-t, és úgy már bootolt Legacy boottal.
-
Frawly
veterán
válasz
Norby86
#56713
üzenetére
Az szerintem egyterás vinyó lesz, egy r-rel. A terra földet jelent. Izgulni egyébként sem volt okod a maximális fájlméret miatt, mert nincs rá szükség, hogy 1 terás HDD-t ext2-re formázz, mikor ott van rá az ext4, aminél a maximális fájlméret 16 TiB alapértelmezett 4k-s blokkmérettel.
-
Frawly
veterán
válasz
lajos0001
#56704
üzenetére
Nem használok MBR-es configot. Ha esetleg a kezem közé kerülne egy, akkor nyilván azon GRUB-ot használnék (megint csak pár másodperces telepítési időkkel), mivel azon az EFI stub boot nem fog menni. A saját gépeimen mind UEFI van EFI boottal. Nem is tervezem visszaváltani MBR Legacy bootra. Másnak sem ajánlom, hogy 2017-2018 fordulóján MBR boottal szenvedjen. A legacy boot arra való, ha valaki mindenáron régi OS-t akar futtatni, mint pl. XP és társai. Win7-től felfelé, modern MacOS, Linux, BSD alatt nincs rá szükség.
Egyszer volt szükségem MBR bootra a nem túl távoli múltban, mikor DOS 3.30-at bootoltam be, amit előzőleg QEMU virtuális gépen telepítettem fel SSD-re, majd újraindításkor az UEFI-ben beállítottam, hogy Boot Type: Both (EFI + Legacy), és szépen indult. Egy kísérlethez kellett, megnéztem, hogy egy modern gépen melyik az a legrégebbi PC-s OS, ami elindul. Az MS/PC-DOS 3.30 az. A 3.0-ásnak még kéne elméletileg bootolnia, de nem ment, az 1-2-es DOS meg eleve reménytelen, mivel csak MFM vezérlőkkel indul.
Egyébként pont most fogok mindjárt FreeDOS 1.2-őt bootolni a nevezett SSD-ről, az egyik laposon BIOS-t frissítek, ami Windows alól nem ment (kiírta, hogy előkészíti a frissítést, meg hogy újra fogja bootolni a gépet, de restart után semmi nem történt, megint betöltött a Win10 frissítetlen BIOS-szal), EFI FAT32-es partícióról nem ismerte fel a BIOS (pedig támogatja ezt a frissítési módot), így a FreeDOS-os megoldás maradt. Természetesen a FreeDOS is bootol már UEFI-vel, igaz van hozzá külön Legacy .iso-kép is.
-
Frawly
veterán
válasz
ubyegon2
#56700
üzenetére
Nem 2 dollár ugyan, hanem 36 átszámolva, de az még bőven olcsó megoldás. 100 darabot azért nem vennék belőle, mert minek. Ez ami van, évekig fogja húzni. MLC-s SSD 1,5 TB írással, még kb. 1 PB mehet rá, de csak néhány .iso-t küldök rá, meg egy-két tesztrendszert telepítek (de abból aztán mindenfélét, volt már rajta Arch, MS-DOS 3.30 retró kísérletnek, 17-es TrueOS, Ubuntu 17.10), nem írok rá sokat, meg nem is használom minden nap. Ami miatt elméletileg bedögölhet, az az, hogy ezek az asztali SSD-k nem szeretik, ha le vannak húzkodva áramforrásról (mert hiába választom le, azért mégis csak kihúzom az USB-ből, ami hirtelen árammegvonás), de egyelőre bírja jó fél éve. Ha még fél évet kibír, ami nagyon sanszos, nettó haszon volt megvenni, ha megdöglik, veszek másikat, átalakítót ahhoz már nem kell venni. Még az átalakító árát sem kéne beleszámolnom, mert az jó SATA 2,5 colos HDD-khez is pl., nem csak emiatt éri meg megvenni.
Ilyen multibootos megoldást nem használok, egy rendszernél többre nincs szükségem. Az mindegy, hogy live/telepítő vagy feltelepített rendszer, csak bootolni lehessen róla vészesetben. Persze aki attól boldog, hogy multibootos rendszere van, annak egészségére. Plusz nem syslinuxozok, nem GRUB-ozok, hanem tisztán EFI stub systemd bootot használok. Kivéve ha olyan disztrót telepítek fel rá, aminek a telepítője alapból GRUB-bal telepít (pl. Uborka spinek, Mint, stb.).
A pendrive-val meg nem csak az a baj, hogy lassú, hanem kevesebb írást bír ki és megbízhatatlanabb, mivel nincs rajta wear leveling, mindig csak a szabad cellák terhelődnek, főleg akkor nyíródik nagyon, ha rendszer fut róla. Persze azért, mert mobil adattárolónak találták ki a pendrive-okat, nem rendszerlemeznek, ennek ellenére sokan használják erre a célra is, nem csak a peneket, de pl. SD kártyák különböző típusait is. Működni működnek, csak nem kell csodálkozni, ha gyorsan read onlyvá válnak, meg csak hibával lehet mountolni, vagy már fel sem lehet csatolni/formázni. Ezek ilyen fogyóeszközök, mint régen a floppy és az újraírható optikai lemezek.
-
Frawly
veterán
válasz
ubyegon2
#56628
üzenetére
Igen, el kell keserítselek. Hiába csak SATA2-es, ami szekvenciálisan korlátoz (meg az USB3.0 is korlátoz amúgy is), random read/write, access time terén nem marad le a SATA3-as meghajtóktól, és rojtosra ver akármilyen pendrive-ot. Az .iso kiírási idők olyan max. 8 másodpercesek, a telepítési idők 1-2 percesek mindössze, a rá telepített rendszerek is 5-8 másodperc alatt bootolnak róla. És 1,8 colos (nem 2,5), alig valamivel nagyobb mint egy hitelkártya, tehát még zsebre is tudnám tenni, átalakítóstól súlyra is alig nagyobb, mint egy pendrive.
Megint más, hogy ha valahová pendrive-on kell cuccot vinni, nem ezt használom, de nem azért, mert nem lenne rá alkalmas, csak egyrészt vigyázok rá, nem hurcibálom ki utcára, másrészt meg ha IT analfabéta kezébe kerül, akkor fosni fog, mert nem tudja micsoda, jajj, ezt ne rakjuk be a gépbe, mert elroncsalyanekilye. Tehát nem dobtam ki a pendrive-okat sem, de ha OS-sel kapcsolatos dolog van, azt erről a külső SSD-ről oldom meg. Valóban nem olyan esztétikus, mint egy pendrive, de nem foglal sok helyet, és már néhány hónap alatt most tett annyi jószolgálatot, hogy megérte az árát (átalakítóstól kemény 10,5k magyar pengőnek megfelelő fontot fizettem érte, eBayről rendeltem helyből, UK-n belülről, ingyenes kiszállítással), alig volt néhány ezerrel drágább, mint egy Tesco Value vagy kínai noname USB2-es 32-64 gigás pendrive.
Habár átalakítót még egyszer venni fogok hozzá, mert ez a mostani nem visz át egy csomó ATA-parancsot (TRIM, SMART, stb.), amit amúgy az SSD támogat. Azt hiszem ezt pont veled beszéltük az egyik SSD-s topikban.
Annyira elkapott ez az SSD láz, hogy tervezek venni még egy SSD-t, egy nagyobbat, ezt is külső SSD-nek, meg ha megdöglik az SSD valamelyik gépben, akkor tartaléknak is jó. Olcsóbb SanDisket néztem ki, de mivel egy Flash SSD topikban pont most jött szembe egy túl nagy write amplification-nel rendelkező bugos SanDisk, így egyelőre letettem róla, és más gyártók modelljeit nézegetem egyelőre.
-
Frawly
veterán
Csak egy jótanács. Pendrive helyett az ilyen multiboot varázslásokra vegyél inkább egy olcsó SATA SSD-t (lehet használt is), és használd azt filléres SATA-USB átalakítóval. Egyrészt százszor gyorsabb lesz, mint akármelyik fostos pendrive, másrészt megbízhatóbb lesz, mivel több írást visel el. Kicsit lehet drágábbra jössz ki néhány ezressel, de nem fogod megbánni. Én is így tettem, elegem volt az évek során a gagyi pendrive-okból, a jobbak meg túl drágák, ezért vettem egy 10-esért egy használt SATA2-es 1,8 colos SSD-t, 64 gigásat, meg egy ezer forintos átalakítót hozzá, USB3 porton pendrive-nak használom, erre írom ki az OS-ek telepítőjét, meg erre telepítek rendszert, ha valamit tesztelni kell. Villámgyors, megbízható, nincs több szopás, szárazabb érzés, akár 50%-kal dúsabb szempillák, pont erre van a Mastercard.
-
Frawly
veterán
Ez akkor meg biztos, hogy user error, nem hoztál létre partíciókat rajta. Elvileg lehet lemezt partíciók és particiós tábla nélkül használni egyben, mindjárt egy fájlrendszert tenni rá, ez elvben működhet, de ahogy az eseted is mutatja, lehetnek belőle gondok. Rendesen particionáld meg azt a lemezt.
-
Frawly
veterán
Az msdos partíciós tábla (lánykori nevén MBR) biztosan nem lehet gond. Arra figyelj, hogy többféle UUID van. Van egyszer a lemez UUID, van a partíció UUID, és van a fájlrendszernek is külön UUID-je, fdisk mutatja a partíciókét, lsblk a fájlrendszerekét, a lemez UUID-t megint valami particionálóprogrammal lehet ellenőrizni, erre már nem emlékszem. Arra is vigyázni kell, hogy ha bent van a régi HDD, akkor ne szerepeljenek azonos UUID-k az új HDD-vel, mert akkor ütközés miatt produkálhat furcsa hibákat. Egyébként nem is értem, hogy miért kell neked ugyanaz az UUID.
-
Frawly
veterán
válasz
Geripapa
#56561
üzenetére
A Ctrl+Alt+F2-vel nyitott konzolnál mindjárt bejelentkezést kéne adnia, és csak el kell kezdeni írni a felhasználói nevet, aztán a jelszót. Majd ha bejelentkezett, akkor ezt a parancsot kell írni (loginctl unlock-session 1), amit a képernyő ír németül. Bár szerintem a hivatkozott parancs csak ideiglenesen segít a probléma megoldásában, mindig be kell irkálni minden ilyen esetben. Nálad inkább azt kéne elkerülni, hogy ne forduljon elő többet ez a hibaüzenet.
-
Frawly
veterán
válasz
ubyegon2
#56560
üzenetére
Nálam az összes partíción van discard TRIM, míg az fstrim az első FAT32-es EFI partíción nem fut le, mivel azt nem támogatja. De a többi partíciót alaposabban trimmeli. Ezt csak azért írom le, mert erről még nem publikált senki.
A disks tényleg hulladék, azt nem szabad használni. A smartctl viszont tényleg támogatott értékeket mutat. Minden SSD-nél mást, pl. Crucial meghajtóknál nincs 233: Media Wear Indicator, helyette 202: Percent Lifetime Used attribútum van. Általában a RAW value nem mérvadó, nagyon kevés kivételtől eltekintve (hőmérséklet, írt adatmennyiség, stb.). Fő szabályként az is elmondható, hogy ha baj van a meghajtóval, akkor a program külön is jelezni fogja, hogy valamelyik már FAIL.
-
Frawly
veterán
válasz
ubyegon2
#56557
üzenetére
Én nem így tudom. A smartctl -a /dev/meghajtó_neve (smartmontools csomagból, rendszergazdai jogokkal kell meghívni) csak azokat a SMART adatokat jeleníti meg, amelyeket a meghajtó támogat, ilyen GMR fej amplitúdót még nem is láttam SSD-nél.
Az viszont igaz, hogy van néhány elavult program, ami mutathat hülyeségeket, mert vagy nem jól olvassa ki a SMART adatait, vagy kiolvas olyat is, amit a meghajtó nem támogat. A kérdező esetében viszont nem ez e helyzet, mert van értelme a 0-ás értéknek és a smartctl nem hoz le nem támogatott értékeket.
Linuxra még van HD Sentinel, ingyenes, de csak parancssoros. Viszont azt nem szeretem, mert nem minden SMART adatot mutat azok közül, amit a meghajtó támogat, másrészt meg szereti a kondíciót eléggé a saját szájíze szerint mutatni, több értéket kombinálva, nem pedig a SMART-beli kondícióértéket kiírni, és ez így megtévesztő lehet néhány SSD-nél.
-
Frawly
veterán
Ha már SSD és Linux. A Crucial MX300-on kb. fél évig a fstrim -a -v parancsot használtam trimmelésre. Pár hete váltottam az /etc/fstab fájlban discard-os mountra, hogy ezzel is legyen tapasztalatom. E néhány hét után nekem úgy tűnik, hogy az fstrim hatékonyabban trimmel, hiába van folyamatos discard TRIM, mindig talál a kézzel futtatott fstrim trimmelni valót. Ennek ellenére feltehetőleg elég az egyik fajta TRIM, mondjuk a discard, mert gondolom azért annyira megtrimmeli az is a meghajtót, hogy idővel ne lassuljon be, de az fstrim előnyösebbnek tűnik, mivel
1) hatékonyabb
2) minden SSD-n megy, ami támogatja a TRIM parancsot
3) több fájlrendszer támogatja (1-2 kivétellel)Hátránya is van:
1) nem minden fájlrendszer támogatja (pl. a FAT-rendszerek csak discardot támogatnak)
2) kevésbé egyértelmű a használata, bár mióta van fstrim.timer systemd service, azóta nem kell a cron-nal kínlódni. -
#56556
Frawly
veterán
herdsman12
#56554
Frawly
veterán
válasz
herdsman12
#56554
üzenetére
Nem kell aggódnod. Az a nagy szám a RAW érték, és minden meghajtónál más. Azt írják, hogy ez a Media Wear Indicator 0-ról indít, majd felmegy 100-ra, majd onnan esik egyesével, ahogy öregszik a meghajtó, végül 1-en állapodik meg. Azaz nálad azt jelzi a 0-val (normalizált érték, vagy csak simán érték), hogy új még az SSD, kevés írást kapott (100%-os kondíciójú).
-
Frawly
veterán
Olvastam már olyan esetkörről, hogy még EFI partíció sem volt, és úgy is ki lehet okoskodni az EFI-bootot, de egyrészt ennek a működését nem értem, meg initramfs mellett nem működik. Már pedig initramfs kötelező, ha a disztró csak azt támogatja, vagy nem csak azt támogatja, de LVM, szoftveres titkosítás, vagy hasonló van használatban.
EFI partíció viszont szabvány szerint kell EFI-bootkor, mivel a többi OS telepítője is oda akar majd írni.
-
Frawly
veterán
Akkor nem szolgál bootként, ha van másik boot is, de felesleges még az EFI-n kívül pl. GRUB-ot is feltenni, csak eggyel több lépcső, felesleges bonyolítás, mindenféle előny nélkül. Ha EFI partíció van, akkor lehet nyugodtan arról bootolni, és akkor /boot-ként is szolgál. Sok UEFI támogatja az MBR-t, de csak amolyan Legacy módként, hacsak nem használ az ember régi OS-t, mint XP és társai, már pedig az ellenjavallott. Érdemes UEFI bootot használni (már csak azért is, mert ilyenkor sok UEFI-rendszer gyorsabban detektálja a lemezeket, nem végez el sok hagyományos BIOS POST tesztet, emiatt lehet nyerni 1-2 másodpercet bootidőben). Gyanítom itt az okozza a problémát, hogy EFI bootra van állítva az UEFI (nagyon helyesen), és a telepítő valami miatt nem szereti. Már pedig EFI bootnál kötelező az EFI partíció, amit ugyan nem kötelező /boot-ként használni, de érdemes.
Mindebből azt akartam kihozni, hogy nem muszáj sok partíciónak lenni. Emlékszem egy másik fórumon az egyik fórumozó vért hugyozott, mire Fedora alatt átvitte a régi linuxos rendszerét az új SSD-jére úgy, hogy bootoljon is. Maga a klónozás egyszerűen ment neki rsync-cel, de a Fedora háromszoros bootot használ EFI bootnál, EFI-ről indítja a Shim-et (first stage boot, fallbacknek, ha a GRUB-bal valami baj lenne, de igazából ez az EFI miatt elve second stage boot), a Shim indítja a GRUB-ot, a GRUB a rendszert. Na, ez az ami felesleges, nálam az UEFI-ben kézzel hozzáadott EFI bejegyzéssel mindjárt az Arch EFI-fájlja indítja az initramfs-t, az EFI partíció van /boot alatt. Ha nincs initramfs, akkor még egyszerűbb. Nem is értem, hogy a telepítők minek bonyolítják az életet mindenféle bootmanagerrel, mikor az EFI-nek pont az a lényege, hogy szabványosított bootmanager, és nem kell rá újabbat felhúzni.
-
#56524
Frawly
veterán
bandras0226
#56519
Frawly
veterán
válasz
bandras0226
#56519
üzenetére
Igen, UEFI-s bootnál kell egy EFI partíció (ami egyben boot partícióként is szolgál, és kötelező rá FAT32-es fájlrendszert tenni), illetve a partíciós tábla GPT-s legyen. Swap partíció nem muszáj (csak ha btrfs-t használsz), használhatsz helyette tetszőleges partíción lévő swapfájlt (aminek a mérete rugalmasan alakítható). A home-ot sem muszáj külön partícióra, de azért erősen célszerű.
-
Frawly
veterán
válasz
#21078528
#56492
üzenetére
Maradjunk abban, hogy a FAT tábládat nagyon benézted, nem bántásból írom. Elég gáz, hogy nem ismered be. Ezt az fdisket én néztem be, azt hittem, hogy a windowsos fixbootot kevered az fdisk-es /mbr KAPCSOLÓVAL, nem olvastam figyelmesen, hogy parancsról volt szó, nem is értem miért írtam én is parancsot, éjszakás műszak után hajnalban nem jó ötlet fórumoznom. Bevallom, hogy még sose használtam fdisk alatt az x-et, nem azért, mert nem vagyok expert, de még nem volt rá szükségem. cfdisk alatt csináltam hasonlót (s gomb), de ott csak megjelenítésben kavarodtak össze a partíciók (amit még egy reboot is megoldott volna), ilyen not in order hibaüzenettel nem találkoztam.
Lognál meg nem használtam még addig a hsz-ig syslogd-t, de ha most vigasztal, pont ezen héten volt rá szükségem először egy display manager hibával kapcsolatosan kellett a logokba beleolvasnom (nem érte meg, nem lettem tőle okosabb), előtte csak logfájlokat néztem, azok addig elégnek bizonyultak, ha valami gond volt. 2 éve használok csak systemd-s disztrókat, és még nem volt szükségem eddig a syslogd-re.
Viszont az SSD-knél azt az érvet buktad, miszerint annyi írást adnak a logok, hogy az nyírná ki a cellákat. Olvastál róla valamit, hogy az SSD-ket kímélni kell, de nem számoltál utána, hogy miből mennyit írsz. Ezért nem elég csak olvasgatni, kérdezgetni, ahogy te mondanád, meg kell nézni hogy működik a gyakorlatban (nagyon helyesen írtad, hogy kísérletezgetni), mennyi az az annyi, smartctl -l devstat futtatásával szépen nyomon tudod követni. De nyugodtan cáfolj meg, állítsd vissza a logolást az SSD-re, és mutass statisztikákat, hogy tényleg annyival dobja meg az írásokat. Legrosszabb esetben is azt tudom elképzelni, ha valami miatt logolási kergekort kap a rendszer (a legtöbb desktop usernél az életben nem fordul elő, de legyen), akkor teleírja azt az SSD partíciót, amin a /var/log van, de arról úgy is értesülsz, hogy elfogyott a hely, abból észreveszed, hogy túlhízott a log, és ilyen nem történik minden nap. Általában a /var/log a root partíción van, ami meg rendszerint nem szokott egy komplett SSD-t kapni (hacsak nem valami korai 32-64 gigás modell, amit nem éri meg partíciókra osztogatni). De tegyük fel a példa kedvéért, hogy csak egy boot és egy root partíció van az SSD-n, elszabadul a logolás, teleíródik az egész SSD (a boot általában kicsi, kerekítsük most 0-ra). Egy SSD-nek egy egyszeri plusz teleírás meg sem kottyan, akkor sem, ha csak valami budget TLC modell. Az access time használatánál sem tudtad megmutatni, hogy mérhetően belassulást okozna. Nem is csodálom, mert nem lassul be.
Ez a noatime varázslás pendrive-okra, memóriakártyákra van kitalálva, mert azoknál egy nagyságrenddel kisebb szokott lenni az írási terhelhetőség még egy TLC-s SSD-hez képest is (persze modelltől, Flash-típustól is függ), és főleg, ha valami noname kínai cucc, akkor még a papírforma szerinti írásokat sem szokta kibírni, hanem idő előtt tönkre szoktak menni. Ámbár ilyen adattárolóknál is csak akkor számít, ha rendszert futtatsz rajtuk, ha csak fájltárolásra használod (ahogy pl. én szoktam), akkor elfér az access time-ok okozta írást. Ha rendszert akarok telepíteni, arra tartok külső SSD-t (nem azért, mert strapabíróbb, hanem mert gyorsabb, mint egy pendrive, és használtan vagy belépőszinten elég olcsók már az SSD-k is, ha nem kell nagy tárterület), a noatime-ot azon sem kapcsolom ki. Egyszerűen le kell szokni erről a kíméljük az SSD-t litániáról, illetve, ha annyira ragaszkodsz hozzá, akkor a tiédet kíméld, de itt fórumon ne vezess félre embereket, hogy kímélni kell, mert nem kell.
-
Frawly
veterán
válasz
#21078528
#56467
üzenetére
Már én is néztem mit irkálsz itt, csak feltételeztem, hogy elírás. De most már a második tévedést írod. A fdisknek nincs fix/extra parancsa. Se a DOS-osnak, se a linuxosnak. Szerintem a DOS-os fdisk /mbr kapcsolóra gondoltál, de a partíciós táblához az sem nyúl, az MBR-ben csak az OS-indító kódot cseréli le. Persze a partíciós tábla is az MBR-ben van (feltéve, hogy nem GPT-s tábla), de az az első 446 bájt után következik csak.
Partíciós táblát emberünk úgy tud létrehozni, ha particionálja a lemezt. Ettől még használhatja az fdisket, csak akkor ne a DOS-osat, ha már linuxos topik. A DOS-os elavult, csak MBR-t támogat, csak FAT16-32-es partíciókat tud létrehozni, azt is elég kötött sémák mentén. Ha már linuxos fdisk, inkább szoktam ajánlani a cfdisket, mert kicsit interaktívabb, felhasználóbarátabb. Vagy ha valami Live rendszert használ grafikus módban, akkor a Gparted még barátságosabb lehet.
-
Frawly
veterán
válasz
#73749248
#56439
üzenetére
Itt is azt írják pont a Wear Level Count attribútumra 840 Prónál, hogy a normalizált érték számít, nem a raw.
Egyébként azt furcsállom, hogy több éves az SSD-d (hiába a fél év kihagyás), és csak 103 nap üzemidőt mutat. Nálam fél év alatt keletkezett 58 nap. Ennyi idő alatt sok az a 7TB-os írás. Nem önmagában, de ilyen kevés napra elosztva az napi 69 GB írás, ami jóval az átlag felett van. Említetted a virtuális gépet, mondjuk attól lehet, ha futtatsz rajta egy komplett virtuális rendszert, ami sokat használsz, meg frissítesz.
Nyilvánvaló, hogy nem fog ilyen 50 évig menni igazából egyik SSD sem, mert hiába bírnák még a cellák, a vezérlő ki fog alóla rohadni. Semmi nem megy örökké. Akkor sem, ha kímélve van.
-
Frawly
veterán
válasz
#73749248
#56435
üzenetére
Itt azt írják, hogy nem a RAW értéket kell nézni ennél az attribútumnál.
Nem kell kép, szépen látszik ezen az oszlopos táblázaton. Képet csak azért szoktam kérni, mert a szöveges kimenetet rosszul szokta tördelni a fórummotor. 98% százalék nálad a kondíció. Ez több éves SSD-nél, 7 TB írással a háta mögött egy nagyon jó érték. Ezzel az ütemmel még vagy 50 évig kitart még az szerencsétlen meghajtó.
-
Frawly
veterán
válasz
growler
#56432
üzenetére
Mondjuk ebben igazad van, foglaltságtól is függ, nem csak írásmennyiségtől. Ezeket, amiket én mértem, 54%-os foglaltság mellett mértem. Ez alapján hetente kéne TRIM-elnem, és kb. ennyire is szokott kijönni, mivel kb. hetente kézzel futtatom az fstrim-et (nem szeretem az automatikus dolgokat, nekem akkor a systemd fstrim.service ne fstrimmeljen, miközben lehet valami másra használom épp a meghajtót), de nem minden héten, volt, hogy elfelejtetettem, és egy meg másfél hónapig nem volt trimelve, és akkor sem volt baja, nem lassult be. Megfogadtam, hogy legalább egy évig fstrim-mel tesztelem, majd áttérek discard TRIM-re, hogy össze tudjam hasonlítani, hogy melyik hogy érinti az SSD teljesítményét, de már a látatlanban is azt várom, hogy mindegy, mindkettő egyformán jól működik szerintem, ha a meghajtó támogatja, nagyon valószínű, hogy egyik sem lassít a meghajtón, mindkettő megtrimeli, amit kell.
Olvastam nem egy emberről, akik XP alatt használnak SSD-t, mindenféle TRIM nélkül évek óta, és még nem lassult be nekik. Pedig XP alá is vannak olyan gyári szoftverek, amikkel lehet kézi trimet csinálni, vagy be lehet bootolni live linuxra, és ott kiadni a sudo fstrim -a -v parancsot néha napján.
-
Frawly
veterán
válasz
#73749248
#56431
üzenetére
A RAW értéket nem kell nézni, csak a sima értéket, amit mutat rá, a 98-at. 98%-os SMART kondícióval az még teljesen új SSD, gondolom az első százalék akkor ment le, mikor akármit is írtál rá, a következő meg x írás után, nem tudom mennyit TBW-t mutat most a meghajtót, hány GB-ot.
Az élettartamnak megint nem szabad hinni, azt az egyes programok a kondícióból, összes írásból, egyéb SMART jellemzőkből kombináltan kalkulálják egyéni szájíz alapján, emiatt különböző szoftverek eleve más élettartamot jósolnak. A HD sentinel még a kondíciót is átszámolja még más SMART adatok mentén, sokszor emiatt különböző értéket mutat, mint amit a SMART vagy az SSD gyártójának a diagnosztikai programja, ez utóbbi kettő a mérvadó.
Nem hinném, hogy aggódnod kéne, a 250 gigás 850 EVO-nál 75 GB TBW, az 500+ gigásnál 150 GB TBW van megadva, ezt nagyon sokára fogod elérni, már ha egyáltalán eléred, meg ha eléred és túl is léped, akkor sem lesz semmi baja, csak garancia nem lesz rá. Elég mindig az írási mennyiséget nézni a meghajtón, meg hőmérsékletet, meg az error countokat. A kondíciónál nem érdekes mit mutat, hacsak nem túl drasztikus az esése, mert akkor rá kell nézni mi miatt van.
-
Frawly
veterán
válasz
#73749248
#56429
üzenetére
Azóta a kernelek ezt kezelik, lásd a kernel forráskódjának a vonatkozó része (a 4526. sortól jön a lényeg a TRIM-feketelistára vonatkozóan). A 4537. sorban szerepel a Samsung 8XX-es széria. Tehát semmilyen adatvesztés nincs azóta.
Azért is írok róla mindig ennyit, mert az SSD-ket még mindig rettenet sok tévhit övezi, és ebből a laikusnak az jön le, hogy agyon kell kímélni, meg speciális beállítások tömkelegét kell alkalmazni, hogy működjön. Lassan már az jön, hogy ránézni sem szabad, mert szemlenyomatos lesz, és az is árt neki, csökkenti az élettartamát.
Az a gyártón múlik, hogy a SMART-ban a health percentage értékét milyen ütemben csökkenti. Van olyan SSD, amire ha újonnan egyetlen bájtot is kiírsz, lemegy azonnal a kondíciója 99%-ra, de ez nem jelenti azt, hogy még 99 bájt után kuka lesz az SSD, mert adott esetben a következő százalékra esés mondjuk újabb 1-10 TiB írása után következik be. Ezt mindig az adott gyártó dönti el, hogy milyen ütemben veszi le a százalékokat. Ezért nem jelent semmit, hogy nálad a virtuális gép máris csökkentett 1%-ot. Nálam pl. most 738 GiB-nyi írás után (napi átlag 4,4 GiB írás, nincs semmilyen kímélő vagy optimalizáló beállítás, torrentet is kap, egyetlen meghajtó a gépben) a kondíció még mindig 100%-os. A kondícióesést akkor kell komolyan venni, ha gyorsan esik túl sok százalékot, ilyen pár hét leforgása alatt 20-50%-ot, akkor el lehet kezdeni aggódni.
Ú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!
- Netflix
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Spórolós topik
- Honor Magic5 Pro - kamerák bűvöletében
- Medence topik
- exHWSW - Értünk mindenhez IS
- MasterDeeJay: H110-es lapban 10.gen Comet Lake működhet?
- EA Sports WRC '23
- Bestbuy játékok
- AMD Navi Radeon™ RX 7xxx sorozat
- További aktív témák...
- Bomba ár! Dell Inspiron 15 5578 2in1: i7-7GEN I 16GB I 256SSD I 15,6" FHD Touch I Cam I W11 I Gari!
- AKCIÓ! nVidia Quadro P4000 8GB GDDR5 videokártya garanciával hibátlan működéssel
- Használt Intel procik - Core 2 - Dual Core
- Lenovo Thunderbolt 3 kábel (4X90U90617)
- Telefon felvásárlás!! iPhone 12 Mini/iPhone 12/iPhone 12 Pro/iPhone 12 Pro Max
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged