- Apple iPhone 16 Pro - rutinvizsga
- Samsung Galaxy A56 - megbízható középszerűség
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
- One mobilszolgáltatások
- Mi nincs, grafén akku van: itt a Xiaomi 11T és 11T Pro
- VoLTE/VoWiFi
- Mobil flották
- Xiaomi 15 - kicsi telefon nagy energiával
- Google Pixel 8a - kis telefon kis késéssel
- Samsung Galaxy S25 - végre van kicsi!
-
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
bambano
#29926
üzenetére
Nem kizárt, hogy neked van igazad, de én erről nem tudok, mérmint hogy systemd-nek megfelelő szutykot tolnának a FreeBSD-sek a rendszerükbe. Valami linket tudsz erről adni?
(#29929) F34R: igen, ez meg a másik, hogy fájlrendszerek támogatása terén is le vannak maradva a BSD-k. Persze megértem őket, mert egy nagyságrenddel kisebb legalább a fejlesztők száma, de lehet van két nagyságrend is. Így meg a szűkös erőforrások nem elengedők ahhoz, hogy mindenben hozzák a linuxos támogatottsági szintet. Ezért van kevesebb tároló és mirror is hozzá. Viszont másik oldalról pont ez a jó is benne, hogy még nem támogatott minden sz@r rajta, meg nincs elbloatosítva.
-
Frawly
veterán
válasz
bambano
#29922
üzenetére
Sajnálattal olvasom én is. A FreeBSD nekem tartalék terv. Ami most még visszatart tőle, hogy a drivertámogatottsága erősen le van maradva a Linuxhoz képest (NetBSD még szimpatikusabb a még kisebb hardverigénye miatt, de az meg még rosszabbul át driverek terén), főleg GPU-knál meg Wi-Fi-nél problémásak a driverek, de amúgy mindenben le van maradva, ami driver, meg van pár szoftver, ami nem érhető el rá, pl. Wine, Steam. Na, meg mindenki kedvence, a systemd, pulseaudio sem érhető el rá., de ez pozitívum
![;]](//cdn.rios.hu/dl/s/v1.gif)
Meg amiatt sem BSD-zek még, mert még a Linuxban sem fejlődtem ki magam, nem használtam még ki minden benne rejlő potenciált. Úgy meg nem akarom elhamarkodottan dobni. De ha nagyon elbloatosodik a Linux, akkor elkerülhetetlen lesz a BSD-re váltás, a Win, MacOS nálam nem játszik.
A Debian éltetésével nem értek egyet. Bármelyik nagyobb, mainstream disztró felhúzható 10 perc alatt grafikus felülettel. Én az Archot 15 perc alatt felhúzom neked, ha nincsenek nagy extra igények, és valami sztenderdebb DE-vel telepítem, ami függőségnek beránt, megold minden szükséges dolgot.
-
Frawly
veterán
válasz
sh4d0w
#29913
üzenetére
Ha 0day attack van, és bejutnak a rendszerre, akkor már úgyis megette a fene, övéké lesz az egész szerver, és nem a jelszó nélküli shutdown lesz a legnagyobb gondod. Ha meg rendesen karbantartott, frissített szerver, akkor elég kicsi az esélye bármilyen támadásnak, nem jut be senki, így jelszó nélküli shutdown-t se tud csinálni.
-
Frawly
veterán
válasz
sh4d0w
#29900
üzenetére
Valóban nem egy jó politika, szerveren ilyeneket jelszó nélkül engedélyezni, de azért nem is akkora tragédia. Szervere válogatja. Egy jól bekonfigurált szerverre még korlátozott felhasználóként sem juthatsz be, hogy kiadd a jelszó nélküli sudo shutdown-t. Abban viszont egyetértek, hogy az MX NEM szervernek készült, hanem asztali disztrónak. Be lehet fogni szervernek, de minden szempontból szuboptimális lesz. Aki meg komolyan üzemeltet szervert, az ért is hozzá, és meg sem fordul a fejében MX-et felrakni.
-
Frawly
veterán
válasz
bambano
#29824
üzenetére
Az RX570-nel nem tudsz mellényúlni. Melyik modellt vetted, 4 gigásat, 8 gigásat, Armor verziót? Ahogy nézem, 3 DP port is van rajtuk, úgyhogy paradicsomban fogod érezni magad. Ráadásul nem túl új kártya, a kernelben lévő amdgpu driver, és a linux-firmware csomagban lévő AMD firmware simán viszi, csak legyen fent a legújabb mesa is, akkor se X.org-os, se waylandes felületek alatt nem lesz gondod se a megjelenítéssel, se a hardveres gyorsítással, se a hardveres dekódolással.
Az RX570-ben még van annyi erő, hogy bármelyik játékot is simán elviszi 1080p 60 fps-sel, high beállításokon (néha médium, némelyik játékban az ultra is sima neki), Vulkan, DXVK, Proton is mind támogatott. Freesync is.
Ha nem játszol rajta, akár alul is feszelheted, underclockolhatod egy kicsit, azt mondjuk nem tudom Linux alatt hogy kell, de csendesebben jár majd tőle.
-
Frawly
veterán
válasz
Frawly
#29819
üzenetére
Persze lehet DVI csatit és HDMI-t is átalakítózni DP-re, de az bajos lehet, főleg, ha magasabb felbontások kellenek.
Sapphire AMD Radeon RX 5xx kártyákon viszont van két DP port, meg az én Gigabyte AMD Radeon RX570-emen is van. De lehet van ilyen NV kártyán is, de nem találok újabb szériákból ilyet.
-
Frawly
veterán
válasz
bambano
#29816
üzenetére
GT 1030 például. Esetleg GTX 1050. Ettől jobb felesleges is, mert mint írtad úgyse játszol. De fontold meg az AMD-t, annak jobb a drivertámogatottsága. Az NV kártyákhoz zárt NV driver kell, az AMD-ket meg viszi a kernelbe beépített nyílt driver.
Ami a jelentősebb megkötés, az a két DP port. Ilyen nem biztos, hogy minden kártyán lesz, ez szerintem gyártófüggő is, azaz NV-n belül is gyártója válogatja. DP szokott lenni majd minden kártyán, meg HDMI is, de hogy pont DP-ből legyen mindjárt kettő, annak nagyon utána kell nézni.
Az a kártya, amit most vettél, az konkrétan milyen? Milyen driverrel hajtod?
-
Frawly
veterán
válasz
bambano
#29787
üzenetére
Wow, ez nekem teljesen új. Nem tudom hogyan másol /dev/null-ba, mikor azon nincs fájlrendszer. Persze ettől még lehet megoldották. Azt sem értem, hogy ha egy fájllal tudja, akkor a több fájlnál mi okoz neki gondot. Valami directory-ra hivatkozik, de nem világos miért.
-
Frawly
veterán
válasz
Dißnäëß
#29773
üzenetére
Néha előveszem. Nem, nem azt, hanem az mc-t
Bár egyre kevesebbszer, mióta Vifm-et használok helyette.Ilyen /dev/null-ba másolást az mc nem tud, mivel azon az eszközön nincs fájlrendszer, ezért felcsatolni sem lehet. De tmpfs-t felcsatolhatsz mount paranccsal, akkor RAM drive lesz belőle, amit megformázhatsz tetszőleges fájlrendszerre és másolhatsz rá. Vagy dd-vel tolod /dev/null-ba. A hdparm -t a a fizikai cache sebességét méri a lemezen, nem magának a lemeznek a sebességét.
-
Frawly
veterán
válasz
samujózsi
#29742
üzenetére
Egyrészt az épp aktuális DDR RAM specifikációkba is be van építve némi hibakorrekció, másrészt a bitflip annyira ritka, hogy csillagászatian kicsi az esélye, nincs gyakorlati jelentősége. Főleg nem egy otthoni NAS-nál, max. csak bankoknál tudnám elképzelni. Meg ha kormánytitokról van szó és az űrben vagy (pl. ISS), és az ionizáló sugárzás miatt ki vagy téve ennek.
Nem csak velem nem fordult elő még ilyen RAM bithiba, de senkivel akit ismerek, vagy olvastam volna róla. Olyanom volt már, meg másnak is, hogy RAM hiba, de az nem bithiba volt, hanem vagy halódó RAM fizikailag vagy halódó alaplaphiba, és nem ilyen bitátbillenésben jelentkezett, hanem komplett memóriarégiót adtak vissza teljesen fals adattömböt, rövid távon csonttá fagyott a gép vele, vagy lépkedtek ki az alkalmazások összeomlással, meg tömörített fájlok kivétel nélkül sorban dobták a CRC hibát, szóval sokkal konzisztensebb, durvább, észrevehetőbb.
Ez az ECC RAM is csak ilyen cégek pánikoltatása elméleti gyengeségen, ugyanolyan ultraparanoia, mint egy HDD-t 100× felülírni /dev/random-mal. Jajj, hú, mert mi van ha bithiba, vége a világnak. Közben meg ha egymillió évenként be is üt egy ilyen bitátbillenős RAM hiba valakinél, akkor sincs gyakorlati jelentősége, mert a fontos adatokat kezelő szoftverekbe, meg az általuk kezelt adatfájlokba és adatbázisokba is be szokott lenni építve külön hibajavító és hibafelismerő mechanizmus, checksum, konzisztenciaellenrőzés, hibajavító bit, stb., meg korábbi backupokból is ki lehet okoskodni, azaz a hibát több rétegben is lehet javítani. Tehát semmi tragédia nincsen, ha nem ZFS meg ECC RAM van a rendszer alatt.
Ez tipikusan megint olyan hype-paranioa, amivel az öltönyös-nyakkendősök egymás tudják szivatni, hogy jajj, nem secure, meg nem minősíthető, mert hű, ha egy bithiba is, hőjjjj, akkormilesz, mindmeghalunk. Közben meg semmi nem lesz, ugyanolyan elméleti vita, mint hogy egy képzeletbeli küzdelmet Bruce Lee vagy Superman nyerne meg, gyakorlatilag meg ugye egyik sem, mert Chuck Norris mindkettő valagát szétrúgja egy pörgőrúgással (két legyen egy csapásra módon) még az összecsapás előtt, és a mérkőzés elmarad.
-
Frawly
veterán
válasz
samujózsi
#29641
üzenetére
Én is keepassx-et használok. A titok, hogy online nem szinkronizálom, hanem helyileg használom linuxos PC-n, meg androidos okostelefonon, az eszközök között kézzel másolgatva a .kdbx fájlt. De erre is csak azért adtam a fejem, hogy multiplatformos legyen, mert ha csak PC-n kéne, akkor simán egy titkosított LUKS vagy VeraCrypt konténerbe vagy titkosított 7-zip-be beletennék egy közönséges jelszavaim.txt fájlt (plain text, UTF-8 kódolás, \n unixos sorvég), 30 karakteres AES256 master jelszóval védve, és ezt vagy felcsatolnám, vagy ramdrive-ra bontanám ki és cat-tel listáznám és ed-del szerkeszteném, hogy a rendszeren semmi nyoma ne maradjon, se backup fájlban, se logban, se semmiben, historyt kell csak üríteni. Csak ez okostelefonon az Android meg a tapicskaképernyő miatt nem lehetséges.
Korábban úgy voltam vele, hogy nem vagyok gyépés, nem ülök fel a hájpnak, nem kell nekem password manager, fejben tartom a jelszavakat, csak úgy egy éve a városban ügyintéznél be kellett volna lépnem az egyik mailfiókomba, ahonnan kellett volna valami, igen ám, de nem emlékeztem a jelszóra, és a meglévőt nem akartam jelszónullázással széjjelqrni, elég kellemetlen volt hazautazni megnézni otthoni gépen. Így beadtam a derekam, és elkezdtem Keepass-t használni.
-
Frawly
veterán
válasz
haddent
#29720
üzenetére
Ezzel nincs is baj, hogy neked a systemd bejön. Nem vesszük le a fejed, mert nekünk meg nem jön be, és nem is akarunk meggyőzni, hogy ne használd, vagy hogy szar lenne. Mindenki azt használ, amit akar. Vagyis akarna. Azt kell érteni, hogy a systemd-ben nem az a rossz, hogy most X embernek tetszik, Y embernek meg nem, hanem hogy annak is használnia kell, aki nem akarja, mert minden disztróban ott van, minden csomag lassan már dependel rá. Így az is szenved miatta, aki nem akarja használni, vagy nem használja. Ez a rettenet gond vele. És ez nem is magának a systemd-nek a hibája, hanem a disztróké, akik mind defaulttá tették, a csomagkészítőknek és szoftverfejlesztőknek, akik mindent erre dependelnek. Szóval azzal nem lenne baj, ha Lénártdőtőke saját magának hülyeségeket írogatna, mert csak egy hobbiprojekt lenne. Hanem mióta mindenki mindent erre dependel, azóta nem lehet megkerülni lényegében. A Linux meg pont arról a szabadságról szólna, hogy modulárisan lecserélheted és kombinálhatod minden részét, olyan kernelt, amilyet akarsz, olyan fordítást és verziót, amilyet akarsz, olyan initrendszert és rendszerlogolót, amilyet akarsz, olyan grafikus felületet, WM-et, DE-t, login managert, display servert, amilyet akarsz, olyan shellt teszel fel, amilyet akarsz, olyan compilert használsz, amilyet akarsz, és még sorolhatnám nagyon sokáig. Na, az, hogy a systemd-re minden dependel már, az pont ezt a szabadságot sérti meg. Mert ja, feltehetsz systemd-mentes disztrót, de szopás van, ha pont egy olyan szoftvert akarsz feltenni, ami meg dependelne rá, nálam meg nincs systemd. És valóban fel lehet tenni systemd-mentes disztróra is ilyen d-re végződő pótmodulokat, elogind, f4×0mtudjamilyend, de ezek a systemd újraimplementálásai, és ha ezeket mindet felteszed, akkor hiába használsz systemd-mentes rendszer, lesz helyette lényegében egy systemd2-pótd-d, és csak áltatod magad, hogy kikerülted, valójában valamilyen formában, eltérő implementációban továbbra is használni kényszerülsz.
Meg az, hogy systemd nem maradt meg egy init rendszernek. Már rég nem csak init-ként szolgál, hanem logolástól elkezdve a hálózat és eszközök, userek kezeléséig, meg egy csomó biztonsági manőverig mindent a saját irányítása alá vett, most a home mappa kezelése következik a homed-vel. Ha csak init-et csinálna, akkor le lehetne cserélni bármilyen initrendszerre, és nem lenne vele gond, használná az, akinek tetszik. De így, hogy lényegében egy miniOS, a kernel és az userspace között, ami önálló életet él, így nem lehet kivágni a rendszerből. Főleg mióta minden erre épít. Egyszerűen a linuxos világ rákfenéje, ezért utálják, egy nagy bloat alrendszer, amibe nem lehet belenyúlni, el van takarva a működése bináris szutykokkal, és nem lehet kiirtani már sehonnan. Egyre inkább átveszi a linuxos rendszer feletti uralmat, lassan a disztrók már nem is Linux disztrók, hanem systemdnix vagy Linuxd vagy Poetterix disztrók. Ez vele a gond. Mi meg a hagyományos, sysvinites, klasszikus Linux rendszert kérnénk vissza helyette, ami teljes választási szabadságot ad minden tekintetben, de ezt már nem lehet, mióta mindenhez systemd kell, és minden erre dependel. Ezért szidjuk, mint a bokrot.
-
Frawly
veterán
válasz
Dißnäëß
#29692
üzenetére
Gratula. Sose késő. Csak azt fogod bánni, hogy nem évekkel ezelőtt lépted meg a váltást, és vártál vele ilyen sokat. Én most ha visszamehetnék az időben, nem 2014-ben váltanék (hagynám el a Windowst) hanem már 1995-2000 környékén. Meg ahogy telik az idő, és lesz egyre ×4rabb a Windows, úgy fogod tapasztalni, hogy semmit nem vesztesz nélküle, és mosolyogva fogod olvasgatni a windowsos userek szívásait, meg vírus/ransomware-beszopásaikat és telemetriás vergődést.
Az Xfce-vel sincs baj, az egyszerűbb DE nem hogy nem igénytelenség, de jobb, mint a még bloatabb DE-k. Minél soványabb valami, minél minimalistább, annál jobb és hatékonyabb.
Ez egyébként, amiről írsz, ez a virtualizációs „modul”, az tulajdonképp mi?
Off-ba tenni meg nem kell semmit ebben a topikban, mert eleve Off topik, és a szakmai On sem Off. Vagyis logikailag az lenne a dupla tagadás miatt, de a topik eleve amiatt a szabadság miatt jött létre, hogy semmit ne kelljen Off-topikba tenni, meg halvány betűkkel olvasni, meg ne legyen az, hogy kimoderálják.
-
Frawly
veterán
válasz
samujózsi
#29633
üzenetére
Nem szűkösek, mert tiling WM köré is tudzs Gnome ökoszisztémát építeni. A Gnome-ban eleve lecserélhető a Mutter nevű WM-jük. De akármilyen tiling WM köré is tudod ugyanazt a Gnome panelt, Gnome alkalmazásokat és appleteket tenni, futtatni, ugyanazokat a billkombókat beállítani.
Amiről itt a végén írsz, azt minden grafikus felület, DE, WM tudja. Az ablak bal felső sarkában lévő ablakgomb egy menüt hoz elő általában, és ott be lehet állítani az Always On Top funkciót, akkor nem tudja kitakarni semmi. De ez csak félmegoldás, mert az ilyen alkalmazást ugyan nem takarja semmi, de ő maga viszont takarhat olyat, amit nem kéne neki. A tilingozás az egyetlen normális megoldás erre, pont erre is van kitalálva.
A Chrome/Chromium meg egy nagy rakás kula. Nem csak amiatt, hogy elveszi a rendes ablakkezelő funkciókat, ez is felesleges hibája persze. Ennek ellenére van rá workaroud, a WM-ben beállítasz az Always On Top funkcióra gyorsbillentyűt, és azt nyomkodod.
-
Frawly
veterán
válasz
samujózsi
#29627
üzenetére
Ezt a koncepciót hívják tiling-nak. Pont ez a lényege, felosztod a képernyőt egymást nem takaró régiókra, úgy, hogy ki van használva az egész képernyőterület. Erre a felhasználásra van kitalálva, amit körbeírtál, hogy a böngésző mellett még más alkalmazások ablakait is teljesen lásd. Elég hatékony tud lenni, ha tényleg nagy a monitorod felbontása.
Nem csak fele-fele alapon lehet felosztani, hanem mindenféle felosztásban, függőlegesen, vertikálisan, akármilyen arányban, vegyítve is a felosztásokat, bináris fa, fibonachi elrendezés, master-stack és egy csomó megoldás van rá, tiling WM-ek általában ezeket tudják, lehet váltogatni e felosztási sémák között, akár menet közben is folyton átvariálva.
A tiling WM-ekből is van kétféle. Az egyik a dinamikus tiling, amikor előre programozott sémák mentén nyílnak eleve a progik, egyfajta előre eldöntött szisztéma szerinti felosztásban, amit te váltogathatsz is. A legtöbb tiling WM dinamikus, nem is sorolom fel őket, mert lényegében szinte mind az.
A másik fajta a manuális/kézi tiling, amikor az adott alkalmazás megnyitása előtt te mondod meg, hogy majd milyen régióba kerüljön, nem egy séma mentén megy. Ilyen tiling WM-ből kevesebb van, a legismertebb az i3wm.
-
-
Frawly
veterán
válasz
haddent
#29576
üzenetére
Pont ezért kell vanilla Linuxot használni, és nem agyonforkolt, agyonpatchelt enterprise valamit, amire már Linus sem ismer rá. Azért egy kvázi sztenderd vanilla kernel + glibc + systemd kombóra lehet építeni. Ugye mivel szerverről van szó, se X, se Wayland, se játék, se Pulseaudio, se semmi nem jön szóba, ami a képbe bezavarna.
(#29577) bucihost: na látod, most sikerült csupa olyat sorolnod, amiből van linuxos alternatíva. Én olyanra céloztam, hogy pl. Adobe Photoshop kell egy spéci plugin miatt, vagy valami spéci vektorrajzos megoldás, amire nem jó a linuxos Inkscape, stb.. Azért ilyesmiket nehezebb házon belül lefejleszteni, mint egy kasszaprogramot. Nincs egy fajsúlyban a kettő.
Egyébként a kasszaprogramnál nem is az a szívás, hogy lefejleszd, meg multiplatformos legyen, hanem hogy a NAV is elfogadja. De ez megint nem a Linux hibája, hogy a NAV-nak is MS kényszere van. Ez pont egy ördögi kör, hogy midenki MS-megoldást használ, mert csak azt támogatja mindenki, és így továbbra is ebbe a körben tartanak mindenkit. Pont ebbe a függőségi játékba nem kell belemenni.
-
Frawly
veterán
válasz
sh4d0w
#29562
üzenetére
De, pont ez az, hogy minden esetben lustaság van a háttérben, visszakövethető. Nyilván egyik rendszer sem tökéletes egyébként, a mai informatikai rendszerek, közöttük a Linux is, annyira komplex, meg annyira gyors ütemben fejleszt mindenki, netes biztonsági rések, hardveres sérülékenységek jönnek-mennek, így minden rendszernek megvannak a hátulütői. Linuxnak például az egyik legnagyobb hátulütője, hogy még mindig sokan nem ismerik, nem bíznak benne, nincs elég jól képzett szakember hozzá, emiatt drága az üzemeltetése.
Aki írt hozzá, és hajlandó rászánni az erőforrásokat, az meg tudja mindig találni az optimális utat, aminek a mentén érdemes berendezkedni, hogy milyen rendszert használjon. Minden csak akarat és szervezés kérdése, egyik céget sem kötelez senki semmire. Nem kötelező se a Windows, se a SAP, se az enterprise Linux. Azt használnak, arra rendezkednek be, amire akarnak.
Maximum csak nagyon elméleti esetben tudom elkézelni, mondjuk egy dizájnstúdiónál, hogy tényleg valami olyan szoftvert használnak, ami csak Windowsra elérhető, semmi másra, és más rendszer alá sem tudnak saját megoldást íratni, mert annyira komplex, hogy a fejlesztést nem tudná a cég fizetni, nem éri meg neki. Ilyen esetben adott valóban mit használjanak, de ez az összes cégnek kb. <1%-át teszi ki, ahol indokoltan használnak azt, amit használnak. A SAP nem ilyen.
-
Frawly
veterán
válasz
kovaax
#29560
üzenetére
Nem kizárt hogy igazatok van a SAP-pal, és még mindig felettébb népszerű. Én nem ezt tapasztalom, de könnyen lehet, hogy én perceptálom a dolgokat hibásan, mert pechemre olyan helyeken fordulok meg, ahol nem használják.
Mondom, régen az álláshirdetések is tele voltak, ahol SAP-os jómunkásembereket kerestek tömegével, ezeknek a száma is lement a béka segge alá. Innen mertem gondolni, hogy nem én járok rossz helyeken, hanem tényleg nem olyan népszerű, leült a hájpja.
Persze én remélem, hogy nem én tévedek, mert egy ritka nagy szutyok a SAP, elég szomorú lenne, ha tényleg ezt használná mindenki nyakra-főre még mindig.
Egyébként itt nem is a SAP a lényeg, hanem a cégek informatikai szemlélete teljesen torz. Nap mint nap látom cégeknél, hogy régi verziós Windowsra ragadnak be, nem frissítenek, még a biztonsági rések javítását sem teszik fel, csak MS only, zárt forráskódú infrastruktúrára rendezkednek be. Ha meg Linuxra vetemednek, azt is a lehető legrosszabbul csinálják, valami ilyen fizetős enterprise disztró van erőltetve, vagy az van, amit München csinált még a Windowsra visszaállás előtt, hogy valami házilag összegányoltatott ezer éves disztrón ragadnak be, pl. Ubuntu 10.04, Debian 6, frissíteni meg megint nem frissítenek, mert valami ósdi, legacy gányolásuk eltörne a frissebb verziókban. Így linuxozni nem érdemes, akkor már tényleg windowsozzanak. Nem jó a Linuxot erőltetni, ha valakinek nincs meg hozzá a nyitottsága, rugalmassága. Egyszerűen nem jó ötlet, csak a szenvedés lesz vele, meg a Linux lesz hibás, mert szar.
-
Frawly
veterán
válasz
felora:)
#29556
üzenetére
Nem kell kurzorozni. Megnyitod ezt a két kérdéses oldalt a böngészőben, hagyod futni. Elindítasz egy feladatkezelőt is, aminek az ablaka maradjon az előtérben. Magára hagyod, megvárod, míg kikapcsol a monitor. Vársz még egy kicsit. Feléleszted, mozgatod az egeret, és nézed a feladatkezelőben a memóriafogyasztást, pont az lesz szem előtt. Majdnem biztos vagyok benne, hogy swap-el a gép. Esetleg csak a CPU-t pörgeti ki valami JS csutkára.
-
Frawly
veterán
-
Frawly
veterán
-
Frawly
veterán
válasz
inf3rno
#29541
üzenetére
A SAP-pal nem is az a baj, hogy outsource, hanem egy zárt forráskódú gányolmány, de még rohadt drága is. Közben meg semmi olyan nem tud, amit nyílt szabványok mentén ne lehetne épp úgy megvalósítani, meg 1001-féle SQL-alapú ügyviteli rendszer ne tudná.
A helyi informatikus gárdát sajnos mindenhol építik le, nem csak M.o.-n, de itt kint Angliában is látom, hogy a cégeknél nincs is helyi rendszergazda, ha valami gond van, telefonálnak, és cégközpontból távvezérléssel teszik helyre a dolgokat, ha ez nem megy, akkor valahonnan vidékről ugrasztanak valami ugri-bugri IT jómunkásember szerencsétlent. Persze várni kell egy csomót, mire rá fog érni, meg kiér, addig meg kerülgetik a hibát, mint egy gőzölgő ×4rkupacot. Ja, ezzel én se értek egyet, többet érne, meg olcsóbb lenne a helyi informatikus. Csak mindenki a kakát rágja, és pont azon spórolnak, amin nem kéne.
-
Frawly
veterán
válasz
sh4d0w
#29539
üzenetére
A bevételüket nem tudom. Én onnan tudom, hogy már nem népszerűek, hogy akik cégeknél jártam az elmúlt évben, sehol sem láttam már, meg a SAP-os emberkéknek szóló álláshirdetések is erősen megtizedelődtek. Mondom, egy 10 éve, még tele volt minden, hogy SAP így, SAP úgy.
Ami miatt a legtöbb cégnél nem csak a rolling, hanem a Linux sem alternatíva egyébként, hogy eleve balfasz módon MS infrastruktúrára rendezkedtek be, Windows és .NET konkrét verziójára gányolt belső szoftver, Sharepoint meg egyéb szemetek. Sajnos szemellenzős látásmód, valahogy sok cégnél benne van az öltönyös-nyakkendősökben, hogy ha PC vagy szerver, akkor csak Windows, mert azon kívül nincs élet.
-
Frawly
veterán
válasz
sh4d0w
#29532
üzenetére
Ja SAP, pont ezt mondom, hogy ilyen szemetet nem kell használni. Aki ilyeneket bevásárolt, meg is érdemli, hogy bizonyos rendszereken ragadjon miatta. Hála istennek már nem annyira divatos a SAP, egy jó évtizete még nagyon ment a cégeknél, azóta leült, gondolom észrevették, hogy egy nagy rakás ...kupac az egész.
Bár egyébként a SAP megy szerintem akármilyen disztrón, csak maga a SAP nem ad akkor hozzá támogatást. Ja, így járás. Én bottal nem piszkálnám meg.
-
-
Frawly
veterán
válasz
bambano
#29512
üzenetére
Ebben nem lennék biztos. Persze abban egyetértek, hogy lehet nem fizetődik ki a vele töltött munka, főleg nem egy cégnél. Bár ez attól függ, hogy ki mire használja.
Én hobbi szinten is gondoltam saját rendszerre, forráskódból forgatva. Ezt nem is disztrónak nevezném, mert akkor disztró valami, ha terjeszted. Én saját rendszernek tervezem, csak a saját használatra, csak saját gépre, csak azokat a progikat fordítani, amiket használok is, minden kifejezetten csak arra a gépre fordítva. Amúgy LFS-szerűen, de nem LFS-sel. Ez annyira egyedi rendszer lesz, ha tető alá is hozom valamikor, hogy senki másnak a gépére nem lesz alkalmas, de pont itt jön a poén, hogy nem is kell alkalmasnak lennie. Pont ez az, a legtöbb disztró keze meg van kötve, mert általános céllal mennie kell sok hardveren, illeszkednie kell sokféle felhasználáshoz. De saját célú rendszeren nincsenek ilyen kötöttségek, hogy Garázs Bt. gépén, meg Gipsz Jakab gépén is mennie kell. Emiatt kihagyhatok a rendszerből minden általam nem használt sallangot, a kernelbe már bele se kell forgatni egy csomó drivert meg szokásos lehetőséget.
-
Frawly
veterán
Persze, tökéletes teszt meg tökéletes garanciák nincsenek semmire. A fizetős, 10 éves támogatású rendszer is épp úgy eltörhet.
A tesztrendszer nem is arra való, hogy hibátlanul teszteljen, hanem teljesen blőd hibákat ki lehessen zárni vele, mikor az egész rendszer csak úgy letérdel zusammen, meg bootképtelen lesz. Tehát nagy szarvashibák kizárására van.
Egyébként nem is annyira a használt rendszer számít, hanem a szakértelem, meg hogy az ember betartsa a szakmai ajánlásokat (redundancia, backupok, snapshotok, tesztelés), és a szoftveres infrastruktúra is minél nyíltabb, minél szabványosabb legyen, és ne ilyen házilag összegányoltatott, csak régi verziókon futó, nem szabványos, zárt kódos dolgokat kell erőltetni, ami pl. szeret akármilyen rendszeren könnyen törni, és akadálya mindenféle frissítésnek. A legtöbb cégnél az utóbbi a probléma, nem is az alatta használt rendszer, hanem az inkompetens gányolás.
-
Frawly
veterán
válasz
sh4d0w
#29505
üzenetére
Nyugodtan szóba jöhet. 3+ éve archozok, ami nem tűnik soknak, de ahhoz képest szép idő, hogy teljesen használhatatlanra még egy rendszer sem tört el. Voltak ritkán kisebb glitchek, amik workaround-ot igényeltek, de mindig abszolválható volt, és ezek is általában olyan asztali DE-komponenst érintettek, meg felhasználói asztali programokat, amik szerveren egyáltalán nem relevánsak.
Rolling frissítéseket is ki lehet tesztelni tesztrendszeren, mielőtt az éles infrastruktúrára ráengeded, meg épp úgy lehet pl. snapshottal is rendszert visszaállítani. Semmiben nem kockázatosabb, csak tudni kell jól használni, nem ész nélkül kell 5 percenként frissíteni.
Igazából ez mind hiedelem, meg preferencia kérdése. Mindenki azt a rendszer akarja feltenni, amit legtöbbet használt, legjobban ismer, legjobban bízik benne. De ez nem azt jelenti, hogy az a rendszer lesz a legjobb. Igazából a rendszer mindegy, a szaktudás számít, amivel üzemelteted. Akár még BSD, Windows Server, meg akármi is szóba jön, aki jó szakember elvisz bármit, aki meg balf4×, annak meg mindegy milyen disztó, mert csak szenvedni fog rajta, meg gányolni.
-
Frawly
veterán
válasz
sh4d0w
#29501
üzenetére
Jó, de milyen olyan risk van egy rolling disztró csomagjában, ami egy hosszú támogatási idejű, kiadás alapú céges disztró névre is teljesen megfelelő csomagjában nincs? Mert leginkább csak a verziók változnak a kettő között, meg a céges disztróknál applikálnak néhány csomagra saját patcht. De attól még ugyanaz a systemd, ugyanaz a PHP, Apache, stb. lesz fent a szerveren, max. csak régebbi verzió. Tényleg nem kötözködni akarok, mert lehet igazatok van, de én nem látom, hogy a céges disztró az mitől lenne jogilag aggálytalanabb.
-
Frawly
veterán
Na, látod, ezt nem kéne tényként kezelni. A rolling semmivel nem alkalmatlanabb, mint a fizetős vállalati disztrók. Ez megint csak marketing miatti sztereotípia. Igazából aki ért hozzá, annak mindegy mit használ, meg tudja válogatni az eszközöket, licenceket, meg ha valami probléma lenne, meg tudja oldani magának. Pont ez a Linux szépsége egy Windows Server ellenében, nem is a licencdíjon spórolos, hanem Linuxon minden problémát tuti meg lehet oldani, sokféle alternatívára lehet azon belül támaszkodni, és nem vagy egy multicég zárt forráskódú megoldására rászorítva, ami vagy működik, vagy nem, újraforgatni nem tudod, alternatívák nincsenek rá.
Én nem is szeretek céges supportra támaszkodni. Mert mi van, ha a supportáló cég tönkremegy, lehúzza a rolót? Vagy épp a supportjuk XY problémánál nem tud segíteni? Akkor sok ilyen felelősségetelhárítós, öltönyös-nyakkendős, hojjdeszupport-de-szupport-100-évig-eltéess lúzereknek nagyon gyorsan megáll az élet, és megy a pánikolás, hogy nem megyen a szerver, maja világvége, rohanjon mindenki a bunkerba túlélni. Aki idióta a dolgokhoz, meg gányol, azon egy support meg egy hosszú támogatási idő sem fog tudni segíteni, tényleg csak arra lesz jó, hogy valaki megpróbálja jogászkodással a felelősséget áthárítani valaki másra.
Szerintem a licenccel sincs probléma, főleg nem szerveren, mert a legtöbb szerveres dolog pont GPL-es opensource. Ez a nonfree csomagok problémája inkább a desktopot, DRM-es és egyéb dolgokat érintik, ezek meg szerveren nem létező probléma. Meg igazából a legtöbb céget nem szokta zavarni a licenc, rezzenéstelen arccal tolják a rendezetlen licencű ZFS-t, meg hasonló megoldásokat. Ahol meg annyira licencfetisiszták, ott meg pont BSD-t szoktak használni Linux helyett, mivel megengedőbb a licence, igaz cserében a leghosszabb támogatási idő BSD-ken 5 év max.
Azt én is néztem, hogy a SUSE-nek a leghosszabb a támogatási ideje, 12 év. Ja az jó hosszú. Persze a CentOS 11,5 éves támogatása se piskóta, szerintem az is overkill kategória erősen.
-
Frawly
veterán
válasz
bambano
#29487
üzenetére
A várással nem értek egyet. Nincs értelme várni, ennyi erővel mindig várhatnánk valamire. Ha most kell OS a szerverre, akkor most kell, azt kell feltenni, ami már most megjelent. Egyébként pont ez is a rolling előnye, nem kell semmilyen kiadásra várni, meg külön disztrófrissítésekre időt dedikálni.
Egyébként meg attól is függ, hogy mekkora támogatottsági időt akar. Ha nagyon hosszú támogatottsági idő kell, akkor a CentOS 8.1 a legjobb jelenleg ebből a szrmponból, az 11 és fél évig támogatott lesz még, ennyi év után meg nem az lesz a szempont, hogy a telepített rendszer elavul (mert az el fog már 2-5 év után avulni nagyon csúnyán, a régi verziók nem fogják tudni semmi újabb szoftvernél kielégíteni a verziófüggőséget), hanem a gép hardverügyileg is teljesen elavultnak fog számítani addigra. Vagyis vannak ennél hosszabb támogatású disztrók is, de azok már fizetősek tudtommal.
-
Frawly
veterán
válasz
samujózsi
#29478
üzenetére
Celeron meg Celeron között óriási különbségek vannak, de a 8 GB RAM-ból úgy tűnik, hogy egy modernebb, DDR3-as vagy DDR4-es rendszer, arra mehet az Ubuntu 18.04 is. De én mindenre Archot teszek, ami támogatja, akár in production szerverre, akár hobbi kenyérpirítóra. Semmilyen gond nincs a stabilitásával, főleg nem szerverre, amikor úgyis csak egy kernel, konzol, tűzfal fut, meg néhány szerver daemon, de nem futtatsz rajta grafikus felületet, meg egy csomó sallangot, így nincs is nagyon mi eltörjön.
A Debian Testinget rég nem néztem, de az Arch stabilitásával semmi baj nincs, én kapásból feltenném mindenre, ami architekturálisan támogatja, akár csak az Arch32-őt, vagy Artixot, és nem túl lassú rajta.
De a szerver is relatív fogalom, milyen szerver, milyen protokollokon szolgál ki, milyen gépeket, hányat? Helyi szerver vagy netre van kötve? Elég sok tényező van.
(#29479) haddent: az Arch komolyságával nincs semmi gond. Vállalatoknál azért nem szeretik, mert sok helyen nem ismerik, nincs hozzá annyi beginner leírás, mint a szokványosabb disztrókhoz, nincs vele tapasztalat annyi évtized, mint a már befutott Ubuntu, Debian, akármi disztrókkal, és az Arch mögött nincs semmilyen corporate háttér, hogy fizetős támogatást, vagy bármi garanciát tudnának hozzá venni. Semmi LTS meg egyéb nincs belőle, sőt, kapaszkodj meg, támogatás sincs hozzá, nem hogy 5-10 év, de 0 év sem. Magadnak támogatod. Ha nem ért hozzá valaki olyan szinten, hogy nem tudja magának támogatni, akkor tényleg ne tegye fel, telepítsen helyette Ubuntut.
A cégek, szervezet egyszerűen konzervatívak, lusták, rugalmatlanok, se frissíteni nem szeretnek, inkább beragadnak egy régi technológiába és egész addig halogatják a frissítést, amíg csak lehet. Ilyen mentalitással nem is való az Arch, nem is annak a hibája, ha valaki nincs rá megérve. Akkor tényleg nem jó ötlet erőltetni.
-
Frawly
veterán
válasz
a.gabriel
#29430
üzenetére
Az mpd.conf fájlban a hangkártya számának átírása után tudsz menteni a Ctrl+X paranncsal, helyesebben ez kilép, de előtte meg fogja kérdezni, hogy mented-e, arra nyomsz egy y billentyűt, majd Enter, és ott újabb Enter a fájlnévre, és ki is lép.
A Synology NAS-t nem ismerem, de az mit takar, hogy nem látod? Hol keresed, milyen formában tudod elérni más OS-ek alól? Samba megosztás, vagy NFS megosztás, vagy hogyan?
Egyébként nem akarlak elkeseríteni, de ezek az audiofil disztrók nagy parasztvakítások. Teljesen szokványos Linux disztrók, annyi, hogy van bennük egy low latency kernel, amitől egyébként megint csak nem lesz jobb a hangzás. Hozzá nem értőket hülyítenek vele, mint az aranyozott csatlakozókkal, meg a 192 kHz-es mintavételezéssel.
Ha kezdő linuxos vagy, kezdj el Mint-et vagy Ubuntut használni. Low latency kernelt azokra is feltehetsz, meg zenelejátszókat, mpd-t, stb., és azokon mindenféle terminálos fájlszerkesztés nélkül állíthatod grafikus felületen, hogy melyik hangkártya lesz a kimenet.
Kiváló hangzásod nem az OS-től lesz, hanem
1) Rendes DAC vagy hangkártya, aminek jó a DAC-ja és kicsi a zaja, torzítása
2) jó erősítő esetleg
3) nagyon jó hangfal vagy fej/fülhallgatóSzoftveres oldalról meg csak annyi a teendőd, hogy ne túl alacsony bitrátás, meg gány encoderrel készült audio anyagokat hallgass.
-
Frawly
veterán
válasz
samujózsi
#29400
üzenetére
Igen, pont ez az, hogy „általában”, meg „plusz lehetőség”. Aztán mindenki máshogy szokta. Eredetileg csak vesszővel választották el, és nem használtak idézőjeles csoportosítást, de végül úgy néz ki, hogy ez lett a szabvány, vagyis csak egy RFC ajánlás, de ez tekinthető kvázi annak, még ha sokan nem is tartják be, és pontosvesszőznek meg minden.
-
Frawly
veterán
válasz
Dißnäëß
#29355
üzenetére
Nem jöttem le a szerről. Azóta elérhetővé vált egy csomó streamszolgáltatás, Netflix, Spotify, játékoknál Steam és GOG akciói, így nagyrészt már nem nagyon szorulok rá torrentezésre. Meg a torrentoldalon is előfizettem prémiumra, szintén akcióban, így már seedállományt sem kell tartanom. Így meg kb. a béka segge alá zuhant vissza a torrentezési mennyiség.
A fájlrendszerek közül sokat közvetlenül is lehet már töredezettségmentesíteni, ext-akárhány, btrfs. Biztosan van még egy csomó. Ez ilyen régi dal, hogy oda-vissza másolással kell töredezettségmentesíteni, még abból az időből maradt vissza, mikor még szinte egyik linuxos fájlrendszeren sem volt defrag tool.
-
Frawly
veterán
válasz
samujózsi
#29349
üzenetére
Lehet az a baj, hogy még régen próbáltam, régi gépen, 2 magos Core Celeroncs proci. Igen, gyorsabb volt a /dev/urand, de még azt is kínzás lett volna kivárni egy ~200 gigás meghajtónál is. Lehet mai normális gépen próbálnám, nem lenne már olyan nagy szám. Lehet egyszer ki is próbálom, akár még dd if=/dev/urand of=/dev/null segítségével is, jó sokáig, hogy mennyit tol át. Hétvégénél előbb nem lesz időm most ilyennel játszani.
Nekem egyébként bőven elég az egy menetes zerofill. Vagy SSD-nél az egy menetes TRIM (egész meghajtóterületen, nem csak a szabad szektorokban).
(#29350) haddent: nálam semmi különös. Régen főleg nagyobb léptékű torrentezés miatt titkosítottam. Ma már sokkal kevesebbet torrentezek, alig valamit, inkább csak személyes doksik vannak a gépen, semmi komoly hadititok. Inkább csak megszokásként maradt rajtam, hogy ha egyszer elérhető titkosítás, meg nem lassít, akkor miért ne használjam. Bár nem mindent titkosítok, próbatelepítéseket pl. nem, mert azokon OS-eket tesztelek, vagy csak 1-2 játék miatt vannak fent, azokon semmi személyeset nem tárolok amúgy sem, meg egy idő után mindig törölve is vannak ezek. Igaz én semmi ultraparanoid szigorítást sem használok hozzá, default beállításokkal titkosítok mindent. Tehát semmi ilyen header nélküliség, meg random felülíráshoz ragaszkodás, stb.. Annyira érdekes dolgaim egyébként sincsenek, hogy valakinek túl sok energiát érdemes lenne beleölni a visszafejtésbe.
Azért valami titkosítást nem árt használni. Engem azért nyugtalanítana, hogy ha valaki idegen ráteszi a kezét a gépre, nézegetheti, hogy mi van a browser historyban (nem, nem fogom törölni minden kilépéskor, kényelmetlen, a weblapokra visszataláláskor hasznos), mit töltöttem le, milyen doksikat írtam, kivel leveleztem. mondom semmi nagy titokról nincs szó, de ne legyen már az életem bárkinek nyitott könyv.
-
Frawly
veterán
válasz
Dißnäëß
#29345
üzenetére
Ebben lehet igazad van. A /dev/random-ot és a /dev/urand-ot egy régi gépen próbáltam anno, azon olyan baromi lassú volt, hogy önkínzás lett volna végigvárni. Lehet sok magos modern gépen már gyorsabb, és kimaxolható vele az I/O sávszél.
LUKS-nál nem kell semmilyen header-t dd-zni, crypsetupban megadható, hogy hová tegye a header-t, ne a disk-re tegye.
Viszont a LUKS format valóban gyorsabb a /dev/urandnál, ha a gép támogatja a hardveres AES gyorsítást, értve ez alatt, hogy a prociban van ilyen extension támogatva.
-
Frawly
veterán
válasz
samujózsi
#29344
üzenetére
Tévedsz. Headerrel sem törtek fel még soha LUKS titkosítást. Lehet akármilyen lelkes akárki. Már a 128 bites AES-t ilyen 8 karakteres jelszóval is csak szuperszámítógéppel tudnak törni és évekig tart, 256 bites AES-t ilyen 20-30 karakteres jelszóval és XTS blokktárolással (ezek a default értékek LUKS-ban) meg kb. soha, esetleg az univerzum végégig tartana. Hacsak nem találnak idővel valami gyengeséget magában az AES algoritmusában, vagy a LUKS blokkezelésében (a CBC-ben találtak, igaz abban is csak elméletileg, azt nem is használja már default semmi).
De nem kell ehhez LUKS sem. Az eredeti UNIX forráskódjában ott maradt néhány UNIX-os fejlesztő felhasználói fiókjához tartozó jelszó hash-e. A legtöbbet megtörték néhány perc-nap alatt, de azok egyszerű jelszavak voltak, 4-5 karakter, és egyéb blődségek. Viszont volt ott pár emberke, akinek a jelszavát már több mint 10 éve nem tudják visszafejteni, pedig számos hobbista dolgozik rajta, ilyen erősen párhuzamosított, csúcs GPU-s / bitcoinbányászatban edzett vasszörnnyel mennek rá, és még mindig semmi eredmény. Pedig ez nem AES, meg SHA512 meg LUKS XTS, csak egy mezei, régi hash, egy 70-es évekbeli rendszerről visszamaradva. Nem is komoly szándékkal törik, csak egyfajta fun hobby projekt, hogy a régi nagy UNIX-szerzők közül ki milyen jelszót használt.
A Secure erase-nek ha van is hiányossága, nehéz kihasználni, mivel az SSD vezérlőjét kell hozzá megkerülni, az meg eleve rettenet nehéz, csak ilyen NSA, CIA szintjén ha lehetséges, és még ott sem garantált a siker, hogy a tényleges töréshez találnak is rajta fogást.
Szóval maradjunk abban, hogy ha el is adok a jövőben háttértárat, az új tulaj lehet bőven lelkes, de hozzáférni maximum a p5sömhöz tud, ha lent van a sliccem, akkor is csak úgy, hogy ha engedem, hogy l3×0pjon kézen állva.
-
Frawly
veterán
válasz
samujózsi
#29331
üzenetére
Akkor is lehetetlen feltörni, ha ott a header. Ezt képtelen vagytok megérteni, nem tudom miért.
Én nem szoktam eladni háttértárat, használom, amíg tönkre nem megy. Ha SSD-t adnék el, akkor vagy security erase-t nyomnék neki hdparm-mal, vagy ha ezt nem tudja, akkor blkdiscard paranccsal végigtrimezném (ez sajnos az overprovisioning területet nem törli, de a gyakorlatban egész jó hatásfokú mégis). Ha HDD-t adnék el, akkor egyszerű dd if=/dev/zero segítségével mennék rajta végig, egyetlen menetben, senki nem talált fogást még ezen a módszeren a gyakorlatban, és sokkal gyorsabb, mint a random adattal teleírás. Ami a legfontosabb: ezt közvetlenül az eladás előtt tenném meg, nem napokkal, hetekkel előre. De itt most nem ez a lényeg. Hanem hogy nem hiszem el, ha egy gépben random teleírt meghajtót látok, hogy eladás a cél. Lehet hogy ti ilyen naivak vagytok, én azonnal tudom, hogy semmilyen eladásra szánás nincs itt, a gép tulajának rejtegetni valója van és titkosít. Ennyi. Nem kell ebbe mindent belegondolni, nem a technikai szintről van itt szó, hanem életszerűségi, élettapasztalati logikáról.
Kb. olyan, mint mikor mindenki veri a mellék, hogy ő csak azért használ torrentet, mert csupa legális anyagot tölt, pl. Linux .iso-k. És bár lehet valóban erre használni, azonnal tudjuk róla, hogy bullshit, mert kifejezetten azért találták ki a torrentet, hogy jogvédett meg fizetős anyagokat tudjanak vele letölteni, és akinek fent van torrentkliens, az 99,9999999999999999999999%-ban nem csak Linux iso-kat tölt. Amivel nincs is semmi baj, csak akkor a bullshit szövegeket nem kell tolni hozzá, pl. én is torrentezek, film, sorozat, néha zene, régi játékok, stb.. Épp így a titkosításban sincs semmi kivetni való, én is használok, csak nem nyomom mellé a kamu dumát, hogy bla-bla, nem tehetek róla, áldozat vagyok, NSA elől bujkálok, eladásra lesz, meg egyéb sóder.
Na, ugyan ez van, hogy ha egy gépben teljesen random teleírt meghajtó van, én tőlem mondogathatja a tulaj, hogy eladás, meg möhöhőő, nem fogok neki hinni. Mert nem vagyok naiv, és tökéletesen tudom, hogy nem vagyok ezzel egyedül, mert itt a szakmailag kompetens kollégák is így gondolják, ismerem őket annyira, hogy ők sem ma jöttek le a falvédőről. De ha akarjátok, nyugodtan ragozzuk még, nyomhatjátok mantrában, hogy biztosaneladás, biztosaneladás, biztosaneladás, meg nincsheader, nincsheader, nincsheadeer, elméletileg, elméletileg, elméletileg, hátha segít az önámításban.
-
Frawly
veterán
válasz
samujózsi
#29329
üzenetére
Onnan fogja tudni, hogy nem hülye. Eladásra szánt diszket kiszednek a gépből és nem hagyják benne. Ha bármilyen gépben olyan háttértárat látsz:
1) amin randomnak tűnő adat van
2) csurig van vele a meghajtó, akár úgy, hogy partíciók sincsenek rajta, vagy egy vagy pár partíció van, és az van tele ilyen adattal.
3) van rajta rendes titkosítatlan partíció és fájlrendszer, de van pár nagyon nagy fájl, amiben megint randomnak látszó adat van.Ezekből rögtön tudod, hogy mivel állsz szemben, egész lemezes titkosítással, partíciótitkosítással vagy konténerfájllal. Ja tudod ki hiszi el, hogy eladás előtt írta felül. Jó vicc. Mondom, ezzel csak azt tudod hülyének nézni, aki tényleg IT analfabéta a dolgokhoz, vagy annyira naiv, hogy hisz még a mikulásban. FBI, CIA, NSA, magyar ügyészség/rendőrség által felfogadott igazságügyi szakértő azonnal fogja tudni, hogy mivel áll szemben. Lehet őket is hülyének nézni, de nem azok, szakemberek ők is, nem most jöttek le a falvédőről.
-
Frawly
veterán
válasz
Dißnäëß
#29320
üzenetére
Túlbonyolítod a gondolkodást. Aki nem hülye hozzá, simán rájön, hogy nem dísznek vagy helykitöltőnek tartasz a gépben olyan meghajtót, ami csurig van írva randomnak látszó adattal. Kapásból levágják, hogy micsoda. Ezzel ilyen ECDL Mancika típusú „magabiztos” felhasználókat tudsz megvezetni maximum, ők meg csak annyit látnak belőle, hogy egy particionálatlan (Raw) meghajtónak látszik Windows alatt.
Jól írják, inkább arra menjél, hogy kulcsfájl helyett jelszót használj, jó hosszút, jó bonyolultat, ne oszd meg senkivel, ne írd le sehova. A titkosítási hasht tiktosítás előtt jól keverd meg, hogy jó random legyen, meg írd végig a meghajtót vagy titkosítás előtt /dev/urand adattal, vagy titkosítás után valamivel teleírva, ennek már randomnak sem kell lennie. Ha nem vétesz hibát, az életben nem töri fel senki. Ha van titkosítási fejléc a meghajtón, ha nincs, ha van rajta kamu rendszer, ha nincs, ha van rajta /boot, ha nincs.
-
Frawly
veterán
válasz
Dißnäëß
#29311
üzenetére
De, épp ezt mondom, hogy aki ért hozzá, rájön mi van rajta. Még a fejléc hiányából még a fajtájára is rájön. Azért mondom, hogy ezzel magadat szivatod, csak a saját helyzeted nehezíted meg. Semmi nincs, ha látja, hogy Linux van rajta. Mit tud vele kezdeni? Épp úgy a titkosított részen csak randomnak látszó adatot lát, amit nem tud visszafejteni az NSA sem. Ezzel a partíciómentes, egész lemezes titkosítással csak azokat tudod megvezetni, aki teljesen idióták hozzá. Sőt, még annak a veszélynek is kiteszed magad, hogy aki laikust átvertél vele, az szépen jóhiszeműen particionálni fogja a lemezt, meg formázni, és hiába az USB drive, az adatoknak bukó.
-
Frawly
veterán
válasz
Dißnäëß
#29308
üzenetére
Azt nem tudom, hogy a Debian telepítő ezt mennyire tudja, de kézzel biztosan meg tudod csinálni ezt Debian minimal netinstall CD-ről kézzel. Kb. úgy, ahogy írtad, titkosítást létrehozod, meg a boot partíciót USB-n, felcsatolod, és onnan indítod a text mode telepítőt.
Én ennek egyébként Arch-csal mennék neki, azzal tuti megcsinálható. De mint tudjuk, az nem lehet olyan stabi, az csak hobbista debileknek van.
Abban igaza van a másik kollégának, hogy attól, hogy titkosított a meghajtó, még nem feltétlen kell a bootot a USB-re tenni, lehet egy titkosítatlan boot partíció a titkosított lemezen is, egy titkosítatlan részen.
USB hamarabb akkor kell, ha azt akarod megvalósítani, amit írtál, hogy az egész meghajtó partíciók nélkül egy nagy LUKS konténer, és titkosítási headert nem akarsz rá, hanem azt is USB-n tárolod. Nem sok értelmét látom az ilyen trükközésnek, mert aki ért hozzá, úgyis levágja, hogy egész lemezes titkosítás van rajta.
-
Frawly
veterán
válasz
samujózsi
#29303
üzenetére
Nem azt írtam, hogy garantáltan nem lesz ütközés, hanem hogy „szerintem” nem lesz, és próbáltam megindokolni. Ezek szerint van, tévedtem, beismerem. Próbáltam reagálni a problémádra, mert nem látszott, hogy már kipróbáltad.
Az RO-ként felcsatolt meghajtók mindig szopófaktor, LUKS, LVM, névütközés nélkül is. Általában nem javasolt így csatolni semmit, kivéve, ha nagyon indokolt, hibás fájlrendszer, vagy a célmeghajtón valami kiritikus fontosságú adat van, ami a csatolás nem tehet tönkre, stb.. Először azt hittem, hogy RO alatt itt most ilyen DVD-t vagy hasonlót értesz.
-
Frawly
veterán
válasz
samujózsi
#29301
üzenetére
Igen. Használtam már több disztrón is, a szóban forgó Ubuntun és Archon is, évekig, ráadásul LUKS titkosítással. Ütközéses helyzetem még nem volt vele. Azt nem állítom, hogy garantáltan nincs ütközés, de ezek szerint van, mert kipróbáltad. Egyébként ha felcsatolod egy Live rendszer alatt, akkor át tudod nevezni az LVM csoportokat és köteteket, nem lesz ütközés. Adatvesztés nélkül átnevezhetők.
Read only médiára úgyse tárolnál le LVM köteteket, az ilyenekre fájl/mappaszinten érdemes menteni, nem low level szinten.
-
Frawly
veterán
válasz
samujózsi
#29296
üzenetére
Szerintem nem lesz névütközés, főleg, ha LUKS is van, mert akkor ilyen /dev/mapper/titkosításnév-lvmgroupnév vagy mi alapján jön létre a dev eszköz a LUKS titkosítás feloldása után. De nem vagyok biztos benne, próbáld ki. El nem tudod rontani, legfeljebb kiírja, hogy nem tudta felcsatolni. Szóval kárt nem okozhat, ingyen van kipróbálni.
-
Frawly
veterán
válasz
CPT.Pirk
#29275
üzenetére
Nagyon helyes. Erre én is törekedni szoktam, hogy Windows csak akkor legyen használva, ha nincs rá linuxos alternatíva egyáltalán, vagy van, de nagyon rossz hatékonyságú. Sajnos ilyen UASP meg SMART kezelése terén el van maradva a Linux, nem is maga az OS, hanem a driverek, meg ezek a userspace toolok, ezeknek a fejlesztői mind Windows onlyságra gyúrnak rá sajnos.
(#29276) samujózsi: erősen chipsetfüggő. Meg lehet adni a smartctl-nek partíciót is, a hozzá tartozó lemezt nézi. Az viszont jó tanács, hogy ha nem megy az alapértelmezett futtatása a smartctl-nek, nem tudna kiolvasni semmit, akkor ingyen van próbálkozni a -d scsi megadásával.
-
Frawly
veterán
válasz
CPT.Pirk
#29263
üzenetére
Ez nem a HDD-n múlik, hanem azon az USB házon, adapteren, amin keresztül a gépre van lógatva. A smartctl sokszor nem tudja kiolvasni a SMART-tot USB-n keresztül. Főleg USB BOT módban nem, UASP módban néha lehetséges, de nem minden ilyen USB-s adaptert támogat. A Windows sokkal esélyesebben ki tudja olvasni a SMART-ot ilyenkor is.
-
Frawly
veterán
válasz
haddent
#29260
üzenetére
Érdekes tanulságösszegzés. Irigylem a problémádat. Szívesen cserélnék veled, hogy az 1 gigás netem nem futja ki magát virtuális gépben. Ehelyett ilyen csóresz 15 mbites neten van, amihez még kaka Wi-Fi jelerősség is társul az albérletben
De legalább qemu-kvm-ben nem lassul, igaz nincs is hova neki, mert akkor átmenne negatívba a sebessége -
Frawly
veterán
válasz
samujózsi
#29257
üzenetére
Szerintem az Android nem kezeli le a fájlnevekben a karakterkódolást, vagyis nem tudja MTP-n rendesen átadni. A Linuxnak tuti nem kell gondot okozzon, ott be lehet állítani a kódolást UTF-8-ra. De majdnem biztos, hogy Android-bug, mert Windowson sem ment, azt írtad.
Egyébként nekem is van néhány számnál zárójel fájlnevekben, és nekem nem volt gondom MTP-n sem, de majd kipróbálom még egyszer, kifejezetten ilyen (0) ... (1) ... (2) fájlokkal.
-
-
Frawly
veterán
válasz
samujózsi
#29248
üzenetére
Biztos, hogy ide van felcastolva, ilyen mtp:host néven? Próbálj meg valami egész mást rámásolni.
Két lehetőség van: egy hosszabb másolás közben x idő után szétdobja a kapcsolatot a teló (pl. bekapcsolódó képernyővédő okoz neki gondot), és ez mindig annál a fájlnál mutatkozik meg.
Vagy abban a DCIM mappában az a fájl sérült a fájlrendszeren. Meg kéne próbálni csak ezt átmásolni. Szigorúan terminálban, cp vagy rsync paranccsal, hogy lehessen látni a folyamat közben, hogy mit ír ki hibaüzenetben. Grafikus alkalmazásnál alapból nem látni, hacsak nincs megint csak terminálból indítva.
-
Frawly
veterán
válasz
samujózsi
#29232
üzenetére
Nálam eddig minden paramétert kiírt az efibootmgr -v (vagy ---verbose a megfelelője a hosszú paramtérnévnél), minden gépen, fizikain és virtuálison is.
Pl. ThinkPad-emen Arch alatt, ebből az első 3 sor, és a legutolsó számít:
[csaba@Piglet ~]$ efibootmgr -v
BootCurrent: 000A
Timeout: 0 seconds
BootOrder: 0019,000A,001A,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0012,0013
Boot0000 Setup FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9)
Boot0001 Boot Menu FvFile(126a762d-5758-4fca-8531-201a7f57f850)
Boot0002 Diagnostic Splash Screen FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380)
Boot0003 Startup Interrupt Menu FvFile(f46ee6f4-4785-43a3-923d-7f786c3c8479)
Boot0004 ME Configuration Menu FvFile(82988420-7467-4490-9059-feb448dd1963)
Boot0005 Rescue and Recovery FvFile(665d3f60-ad3e-4cad-8e26-db46eee9f1b5)
Boot0006* USB CD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55)
Boot0007* USB FDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49)
Boot0008* ATAPI CD0 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35401)
Boot0009* ATA HDD2 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f602)
Boot000A* ATA HDD0 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600)
Boot000B* ATA HDD1 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f601)
Boot000C* USB HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803)
Boot000D* PCI LAN VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)
Boot000E* ATAPI CD1 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35403)
Boot000F* ATAPI CD2 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35404)
Boot0010 Other CD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35406)
Boot0011* ATA HDD3 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f603)
Boot0012* ATA HDD4 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f604)
Boot0013 Other HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f606)
Boot0014* IDER BOOT CDROM PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,1,0)
Boot0015* IDER BOOT Floppy PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,0,0)
Boot0016* ATA HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f6)
Boot0017* ATAPI CD: VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a354)
Boot0018* PCI LAN VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)
Boot0019* Arch HD(1,GPT,068aec4c-eb24-443b-8ae1-ba5782bc6364,0x800,0x32000)/File(\vmlinuz-linux)r.o.o.t.=./.d.e.v./.s.d.a.2. .r.w. .i.n.i.t.r.d.=./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g.Közben ezt megerősítve a /proc/cmdline tartalma:
mitigations=off random.trust_cpu=on initrd=intel-ucode.img initrd=initramfs-linux.img root=PARTUUID=a826f815-4fed-b440-907a-bca1e2633e6e rwA /proc/cmdline is teljesen jó, hiszen az UEFI átadja az összes paramétert, amit te megadtál. Ezzel direkt kisérleteztem, hogy az efibootmgr-es bejegyzéssel nem egyező, illetve ellentétes paramétereket adtam át az EFI shellben a kernelnek és a cat /proc/cmdline helyesen írta ki, hogy milyen paraméterek lettek TÉNYLEGESEN átadva.
-
Frawly
veterán
válasz
samujózsi
#29229
üzenetére
Pedig a QEMU hálókártyáját nekem simán kezeli a defconfigos kernel. Szerintem a soros konzol hiányáról sem ő tehet, ez valami QEMU-s vagy OVMF UEFI firmware-es probléma lesz.
Az efibootmgr -v leközli, hogy milyen paraméterekkel lett felvéve indításra az adott kernel. Ha viszont a jelenleg beboolt rendszeren valami egyszeri, speciális paramétert alkalmaztál, pl. EFI shellből, akkor ezt ezzel a paranccsal tudod lekérdezni:
cat /proc/cmdlineAz efibootmgr mindenféle kamu bejegyzéssel lefut. Az, hogy ez bootkor törlődik-e, azt UEFI BIOS-a válogatja. A legtöbb UEFI törölni szokta azokat a bootbejegyzéseket, amikhez a meghajtó vagy EFI partíció, EFI bináris nem érhető el. De nem mindegyik, egyes UEFI-k meghagyhajták.
-
Frawly
veterán
válasz
Frawly
#29216
üzenetére
Még annyit, hogy úgy tűnhet, hogy az Ubuntut, Mintet, Manjaro-t ekézem, de nem állt szándékomban. Teljesen megértem, hogy miért használnak ezek a disztrók bloatabb, de általánosabb megoldásokat. Pl. GRUB, initramfs, systemd, full extrás DE. Ezek sokfélébb használathoz passzolnak, és sokkal problémamentesebben lehet belőlük hülyebiztosabb megoldásokat gyártani. Hiszen ezen disztrók célközönsége sokkal szélesebb, a mainstreamebb, laikusabb emberkéket szolgálják ki, inkább a kezdőket, és nekik jobb egy olyan általános megoldás, ami teljes körű szolgáltatást nyújt, lefedve mindenféle felhasználási kört, kevesebbféle szituban mond csődöt, cserébe bloat lesz. Ezen disztróknál ez kényszerpálya, nem hibáztatom a disztrókészítőket ezen döntéseikért, teljesen logikus lépés tőlük. Sokkal hülyebiztosabbnak kell lenniük, sokkal univerzálisabbnak. Ha ezt nem teszik, akkor a laikus azonnal úgy érzékeli, hogy xaralinux, meg esse-asse-megyen rajta, és pattintják is vissza a Nyílászárókat. Tehát ezen kezdőbarát disztrók felelőssége sokkal nagyobb, hogy ne taszítsák el a kezdőt, ne szolgáltassanak kudarcélményt, hanem hatékonyan népszerűsítsék a Linuxot.
De van egy olyan pont, amikor ez a túlzott univerzalitás, meg bloatság már egy tudásszint felett felesleges, mint a segédkerekek a biciklire, ergó el kell őket hagyni. Így ha az ember tudja konkrétan, hogy mire van szüksége, akkor csak kizárólag azokból jobb egy egyéni személyre szabott sovány, minimalista rendszert csinálni, sokkal pattogósabb, erőforrás-kímélőbb, sallangmentesebb lesz. Meg szakmailag is nagyobb sikerélmény, és tanulási lehetőség. Mert mennyivel jobb az a rendszer, aminek minden elemében az ember saját maga dönt, nem döntik el helyette, a rendszer minden eleméről pontosan tudja, hogy micsoda, mihez kell, és azt is, hogy tényleg kell, nem váltható ki.
-
Frawly
veterán
válasz
inf3rno
#29218
üzenetére
Neked külön válaszolok: szerintem az lesz, amit írsz, erre én is gyanakodtam már. Ti GRUB-bal próbáljátok, én meg EFI stub boottal, utóbbinál nincs semmilyen külön boot manager. Ez simán lehet oka, hogy esetleg a soros porti konzol nem irányítódik át megfelelően a soros port kimenetére.
-
Frawly
veterán
válasz
bambano
#29219
üzenetére
Az elvileg bele van fordítva. Legalábbis vonatkozót csak a menuconfig - Device Drivers ---> Character devices ---> Serial Drivers részben találok, de itt minden be van kapcsolva:
* 8250/16550 and compatible serial support
* Console on 8250/16550 and compatible serial port
* 8250/16550 PCI device support
* Extended 8250/16550 serial driver options
és még egy csomó ilyen 8250/16550-es dolog: sharing interrupts, autodetect IRQ, RSA serial ports support, Intel LPSS/MID support.Egyedül csak speciális, konkrét UART eszközöknél nincs csak *, mint pl. Altera UART support, ARC UART driver, stb..
Elhiszem pedig, hogy működnie kéne, pl. Ubuntu kernellel. A QEMU verziója sem baj, a legújabb 4.2.0-ás stabil QEMU-t használom, tehát nem elavult, meg nem dev/béta verzió.
-
Frawly
veterán
válasz
samujózsi
#29215
üzenetére
Még egyszer hangsúlyozom: ez minimalista, openrc-s Gentoo base rendszeren kézzel forgatott, defconfigos vanilla kernel, EFI stub bootal, GPT-s meghajtóról, FAT32 EFI partícióról indulva, ext4-es root partíciót használva. Se kernel patch-ek, se GRUB, se initramfs, se systemd, se Gnome, se dbus, semmi, se quiet, se spash screen, se semmi sallang. Nem csak a tanulás miatt szenvedek ilyesmivel, hanem nem akarok mainstream disztrót, mint az Ubuntu, ami tele van vágva 99%-ban számomra teljesen nélkülözhető dologgal. Ha csak az lenne a cél, hogy valami Linux működjön, 2 perc alatt felhúznék egy Ubuntut, Mintet, Manjaro-t, vagy 15-20 perc alatt egy Arch Linuxot. Itt most az a cél, hogy saját magam részére a legminimalistább, de még használható saját disztrót dobjak össze, amiben egy deka sallang nincs.
Egyébként valószínű, hogy ehhez, amit írsz, a kernelbe kéne forgatni valami plusz opciót, hogy működjön, a defconfig nem tartalmazza a szükséges dolgokat. Legalábbis én erre tudok gondolni, mert elhiszem, hogy Ubuntu-n ez simán megy, az ő foltozott, full extrásan fordított kernelükkel.
Kernelparamétereket persze meg tudok adni, az UEFI BIOS-ba belépek Esc-kel, ott a Boot Options-ben el tudom indítani az UEFI vészkonzolt, azzal kapok egy shell-t, ott el tudok navigálni az EFI partíció adott bzImage kernelfájljára, ami egyben egy EFI bináris is, és ott kézzel be tudom adagolni a paramétereket, úgy tudom indítani. Tehát csak az EFI shellben beverem ezt:
fs0:\EFI\Gentoo\bzImage console=/dev/ttyS0 console=ttyA "console=/dev/ttyS0 console=tty" paramétereket próbáltam egyszerre is. A kernel rendben bootol, de átváltva a QEMU serial console-jára, abban csak az UEFI shell látszik, a kernel kimenete nem.
-
Frawly
veterán
válasz
samujózsi
#29211
üzenetére
Nem működik ez a tty. Próbáltam ezeket console=/dev/ttyS0 console=ttyS0 console=tty. Külön-külön persze, nem egyszerre.
Kernelparaméter nincs, se quiet, se semmi. Vagyis root=/dev/sda2 mitigations=off logo.nologo, de ezek kernelfordításkor lettek a kernelbe beleforgatva.
(#29212) Jester01: örömmel olvasom. De nem vagyok benne biztos, hogy ez az a bug. Ugyanis próbáltam rw paraméterrel is root partíciót felcsatolni, és nem működött, de lehet rossz helyen adtam meg. Meglátjuk, két nap van hátra az RC3-ig.
-
Frawly
veterán
válasz
samujózsi
#29200
üzenetére
Igazatok van, egy működő kernel kimenetét csatoltam, de elfelejtettem a hibaüzenet elejét becsatolni. Íme:
Az 1.904...től érdekes:
BUG: kernel NULL pointer dereference, address: 0000000000000Azt a tty-os trükköt még nem próbáltam, amit írtál. A QEMU konzolját viszont néztem, nem látszik benne a kernelkimenet, csak az UEFI BIOS kimenete. De könnyen lehet, hogy ez az én hibám, mert a QEMU-nak még be kéne adagolni valami paramétert, hogy látszódjon.
-
Frawly
veterán
Feltettem pár hozzászólással később a hibaüzenet első felét is. Lényegében a legelső sor volt a lényeg, NULL pointer dereference. Magyarán csak olyan memóriaterületre nyúlt, amihez nem kellett volna, szimpla bug miatt totálisan összefosta magát. Ez még oké is, de akkor a kernel panic végére ne ilyen attempted to kill init baromságot írjon, félrevezetve az embert, hanem írjon akkor unknown error, vagy erre a NULL pointer reference dologra mutató dokumentációs linket.
Az amatőr ügyfélszolgálatok szoktak ilyen baromságokat javasolni, hogy egyszerű netkimaradásnál vagy energiagazdálkodási beállítás miatti gikszernél is újratelepíttetik a Windowst, csak hogy ki legyen zárva a hiba, kényelemből félrevezetik a laikust.
Mondom, nem az a baj, hogy nem ment, mert arra számítani lehetett, hogy a legfrissebb RC nem épp a legstabilabb dolog a világon. Csak akkor ne vezessen félre a hibaüzenet, jól megvezetett, mert még nincs a témában nagy tapasztalatom, és emiatt magamban kerestem a hibát, vergődtem mindenféle konfiggal, partíciócsatolással, init problémával, közben a hibának 0 köze volt ezekhez.
-
Frawly
veterán
-
Frawly
veterán
válasz
Frawly
#29159
üzenetére
Beigazolódott, hogy az 5.5-RC2 kernel.org vanilla kernel bootképtelensége egy kernelbug, nem csesztem el semmit, nincs baj sem az ext4-gyel, sem az init-tel, és nem is a Gentoo hibája. A kernel.org-os 5.5-RC1 simán bootol defconfig-os fordítás után, szintén mindenféle initramfs nélkül. Majd vasárnap vagy hétfő hajnalban megnézem az RC3-mal.
Szerintem a kernelbe bekerült egy regresszió, ami miatt megfekszik QEMU alatt. Natív telepítésben ez a bug lehet elő sem jön, nem is jelentette még senki.
-
Frawly
veterán
válasz
Papooo
#29168
üzenetére
Ja, hát 35k-ból ne akarjon semmit játszani szegény gyerek. Max. pasziánszt, Super Mario-t, esetleg Half Life 1, GTA 3-VC. Ilyen Half Life 2, Far Cry 1, Doom 3 szintű gamma már necces egy 35k-s cuccon. Ha annyira szűkösek az anyagiak, akkor a legolcsóbb játékra venni egy használt PS4-et vagy Xbox-ot, de olyat, aminek tiszta az előélete, nincs bannolva. Esetleg venni valami refurb helyről egy kiselejtezett céges Optiplexet, i5-i7-es proci, 2-3. genes, min. 8 GB RAM, meg mellé venni egy legalább GTX 750 vagy R7-R9 AMD kártyát, ez talán összesen kicsit kevesebből áll meg, de azért jóval több lesz ez is, mint 35k.
A T530-as laptop már egy fokkal jobb próbálkozás, de az is min. i5-ös legyen, és én még kötnék rá eGPU-ként egy szintén GTX 750-1050 szintű használt kártyát, valami olcsót, ami 20k körül vagy azalatt megáll. 35k-ból ez sem fog kijönni, talán a laptop, ha refurb vagy leharcolt, de az eGPU-s megoldás efölé benne fog fájni egy másik ~30k-ba.
A WoT meg egy olyan játék, aminek folyton változik a hardverigénye. A régi verzióknak nem volt nagy, anno, mikor kijött, de fokozatosan fejlesztik a motorját, grafikáját, így egyre combosabb gép kell alá.
-
Frawly
veterán
válasz
Papooo
#29162
üzenetére
Kissrácnak ne laptopot vegyetek gamer-kedni, laptopon gamerkedni luxus. Ilyen ócska E1 procis meg U-s procis laptop nem való amúgy sem játszani, még akkor se, ha diszkrét GPU van benne, a proci thermal vagy power throttling miatt az sem tudja kifutni, amit tudna, és általában az ilyen gépeket ócska TN-es kijelzővel látják el. Az igazi gamer laptopok meg ultra drágák, baromi hangosak, stb..
Vegyetek neki egy jó ár/értékarányú, olcsó Ryzen 1600-2600-os gépet, olcsó B350, B450-es lappal, min. 8 GB RAM-mal, egy használt, piszok olcsó RX570-es GPU-val, meg egy 30k-s FullHD Freesync IPS monitorral. Egy ilyen gépen lehet rendesen játszani, a legtöbb játék 1080p High Graf, 60 fps-sel elfutkároz. Még a legújabb, legbrutálabb játékcímek is. Meg egy ilyen gépet később is könnyű bővíteni, ilyen-olyan upgrade-ekkel használható vagy 10 évig, sokkal gazdaságosabb és jobb egy ilyenen játszani.
-
Frawly
veterán
válasz
Papooo
#29160
üzenetére
Akkor ez bukta. Hacsak szerviz nem tud neked frissíteni. Linux alól nem fogsz tudni frissíteni, a gyártó csak olyan BIOS-t adott ki, ami kizárólag Windows alól frissíthető. A virtuális gép és emulátor meg azért nem jön szóba, mert azoknak meg pont az a lényege, hogy ne férj hozzá a host géphez, ne tudjon a virtualizált vagy emulált szoftver belebarmolni. Tehát nem éred el a gép hardverét.
Bár eolyan ötletem van, hogy a Windows telepítő által tartalmazott .wim lemezképet kézileg felhúzni a merevlemezre. Ugyanis a modern Windows telepítők (Vista és későbbi verziók) nem telepítik már a rendszert, nem építik ki, hanem egy általános, készre telepített lemezképet klónoznak rá a meghajtóra, majd ezt átméretezik akkora méretre, ami a telepítési célpartíciónak megfelel. Ezt viszont te kézzel is meg tudod csinálni, láttam erről egy YouTube videót, ahol a fószer P2-es gépre akart modern Windows húzni, persze nem sikerült neki működőre, de azt mutatta, hogy ilyen .wim lemezképet kézileg is fel lehet húzni. Nem biztos, hogy neked segít, mert ha sikerül is, semmi garancia nincs rá, hogy a Win logó után nem indul az is újra.
-
Frawly
veterán
válasz
Jester01
#29157
üzenetére
Megnéztem közben ezeket. Ezek be vannak kapcsolva. De egyéb oldalról is kizártam a konfighibát. Az 5.5-RC1 Gentoo git kernel ebuild konfigját használtam, amivel bootolt az RC1. Ez az RC2 ezzel sem bootol. Szóval nem a konfig a gond. Szerintem ez egy RC2 specifikus bug. Túl új még az RC2-es kernel, 2 napja sincs, hogy kijött.
Esetleg nem bug, hanem a Gentoo-n van úgy valami megoldva, hogy valami speciális patch-t igényel, amit a kernel.org-os git kernel nem tartalmaz. Bár ezt kevésbé tartom elképzelhetőnek, de azért nem zárható ki.
-
Frawly
veterán
válasz
Papooo
#29117
üzenetére
Egy ötletem van a problémád megoldására. OFF topik, de azért ideírom. Szóval fogsz egy akármilyen OS-t, lehet akármilyen Linux is, Ubuntu vagy Mint vagy ami tetszik. Feltelepítesz rá egy QEMU virtuális gépet, meg hozzá virt-managert. Letöltöd a Win10 legújabb iso-ját a MS oldaláról. A virtuális gépet úgy indítod, hogy odaadsz neki kompletten egy min. 32 gigás pendrive-ot vagy külső HDD-t, vagy külső SSD-t. Feltelepíted erre virtuális gépen a Windows 10-et. Mikor feltelepült, leállítod. Kilépsz a virtuális gépből, a pendrive-ot leválasztod. Újraindítod a gépet, és bootolsz a külső meghajtóról. A Win10 Win to Go módban fog indulni. Ez alól tudsz BIOS-t frissíteni.
A másik még egyszerűbb módszer, hogy szerzel a gépbe egy belső meghajtót. Erre meg pendrive-ról feldobod ugyanezt a Win10 lemezképet. Nem kell termékkulcs sem, mikor kérdezi, akkor arra nyomsz, hogy majd később adod meg. A Windows lehet aktiváció nélkül valami 90 napig vagy meddig használni. Neked elég lesz az az egy nap, amíg BIOS-t frissítesz alóla.
-
Frawly
veterán
A gentoo-s kernelek is bootolnak épp úgy, ext4-ről, initramfs nélkül. Initramfs akkor kell, ha van RAID vagy LVM vagy titkosítás, esetleg a /var, stb. másik partíción lenne a roothoz képest. De ezen speciális esetek EGYIKE SEM áll fenn. Pont azért írom, hogy sima ext4 partíció, semmi extra konfig, semmi extra mount paraméter nem kell. Tehát nem ez a gond. RAID-et sem használok, csak azért lett említve, hogy nem ez a gond, hiába az md-s sorok után hal be. Egy későbbi screenshoton becsatoltam a kernel panic elejét is.
Ezt a tty konzolos mókát ki fogom próbálni. Egyébként nekem nem az a bajom, hogy nem működik, hanem hogy nem írja ki normálisan, hogy mi a baja. Lehet valami kernelfordításkor maradt ki, mert make defconfig-ot használok, de utána végigszaladok rajta egy make menuconfiggal, hogy még beletegyek 1-2 dolgot, de lényegben defconfig az egész.
-
Frawly
veterán
válasz
samujózsi
#29145
üzenetére
Initramfs sincs, nem is kell, anélkül is bootol ugyanezen a virtuális gépen Gentoo rendszeren a 4.9.86 és 5.5-RC1 kernel is. A modulnál már értem mit mondasz. A menconfig - Filesystems - Ext4 mind a négy opciója [*]-gal van (statikusan) belefordítva, nem modulként (ami M lenne).
De valami miatt mégse tudja felcsatolni a root partíciót, pedig biztosan /dev/sda2, a többi kernel, amiket említettem, azok fel is tudják épp így csatolni EFI stub bootban, initramfs nélkül. Csak ez a kernel.org-ról származó 5.5-RC2 nem tudja. Próbáltam úgy is, hogy root=PARTUUID=b14b1a-b1a-b14-b1ab1a formában adom meg, az sem segít. Így most vagy nem találja meg a root-ot, vagy megtalálja, de nem tudja felcsatolni.
Az is biztos, hogy a root partíció sima ext4, és fájlrendszerhibák sincsenek rajta, a működő kernelek is le fsck-zzák és mindent rendben találnak.
Egyébként a müködő kerneleknél ez látszik az md sorok mögött, ennek kéne történnie kernel panic helyett:
-
Frawly
veterán
válasz
samujózsi
#29143
üzenetére
Látod, ez jó kérdés. Szerintem max modulként van benne. Hogy fordítsam bele jobban?
Ahogy nézem, ez a baj. Most el sikerült olvasnom a kernel panic elejét (virtuális gép UEFI firmware-jében vettem fel a felbontást, így több sor marad meg). A RAID detektálás után fullad le. Nem a RAID a baja, mert olyat nem használok, meg letiltottam a raid=noautodetect paraméterrel.
Ami az md RAID betöltése után következne az a root filesystem (egy bootoló kernelnél megnéztem), ezt már nem írja, ehelyett van:
BUG: kernel NULL pointer dereference, address: 0000000000000Tehát az a baja, hogy a root filesystem-et nem tudja csatolni. Igazoltam ezt úgy, hogy megadtam neki kernelparaméterben egy szándékosan kamu rootot: root=/dev/sdb1. Akkor is ugyanilyen kernel panic kíséretében száll el.
Pedig sima GPT partíciókat használok, semmi spéci titkosítás, RAID, LVM vagy hasonló bonyolítás. UEFI EFI stub boot, de a Secure Boot is ki van kapcsolva.
-
Frawly
veterán
válasz
samujózsi
#29141
üzenetére
Nem maradt ki, a root fs ext4, és próbálkoztam már a rootfstype=ext4 kernelparaméterrel bootoláskor, az sem segít. Most a virtio támogatást fordítom bele, mert QEMU virtuális gépen fut.
Megnehezíti a hibakeresést, hogy nem tudok visszagörgetni, így nem látszik a kernelpanic legelső sora.
-
Frawly
veterán
válasz
Frawly
#29139
üzenetére
A net szerint az az oka, hogy nem találja az init-et. A root partíció meg van neki adva, a szokásos módon, root=/dev/sda2, ez működött is az 5.5-RC1 kernelnél, ami viszont Gentoo tárolóban volt. Az persze logikus lenne, hogy az initet nem találja, mert alapból az init=/sbin/init fájlt keresné, de Gentoo-n olyan nincs, /sbin/openrc-init van helyette. De az sem segít, ha megadom bootkor kernelparaméterben, hogy init=/sbin/openrc-init, épp ugyanezt a hibát dobja.
-
Frawly
veterán
válasz
Papooo
#29111
üzenetére
Az ciki, ha ennyire nem lehet életre kelteni rajta semmit. BIOS resetet próbáltál rajta vagy load defaults-ot? Sok laptop tud olyan, hogy vagy már közvetlenül UEFI BIOS-ból tud frissíteni, ha kap címet Ethernet kábelen át DHCP-ről, vagy tudnak olyan módot, hogy bootoláskor ha benyomsz a szájába egy FAT32-re formázott pendrive-on egy új BIOS lemezképet, és nyomsz valami spéci billentyűt, akkor felfrissíti onnan magát. Ezt a konkrét gépet nem ismerem, de meg lehetne próbálni.
Emulátorból és virtuális gépből sose fogsz tudni BIOS-t frissíteni. Esetleg Linux alól, de nem tudom, hogy Lenovo-nál ez megoldható-e, sok esélyt ennek a vonalnak nem adok.
-
#29105
Frawly
veterán
MasterMark
#29104
Frawly
veterán
válasz
MasterMark
#29104
üzenetére
NVMe-n elvileg kikapcsolhatod, nem kell külön TRIM-et futtatni, sem fstrim, sem discard mount opció formájában. A TRIM-elést végző parancs be van építve az NVMe protokollba. Ezt tesztelni is lehet, kikapcsolt TRIM mellett létrehozol egy tesztfájlt, majd letörlöd, és megpróbálod helyreállítani. Ha helyre lehet, akkor nem lett trimelve, ha nem, akkor a trimelésről gondoskodott az NVMe driver.
-
Frawly
veterán
válasz
samujózsi
#29099
üzenetére
Most hogy újra végiggondolom, igazad van. Mégis csak át kéne engedni, különben a fizikai host gépen hiába van TRIM, ha úgy látja, hogy az egész qcow2 fájl foglalja a saját lemezterületét, hiába lett valami törölve belőle, nem szabadul fel a már nem használt blokk belőle.
Ezen a linken az első válaszban adnak meg működő példát.
De a legtisztább az lenne, ha az SSD oda lenne dedikálva fizikailag a virtuális gépnek, mert akkor semmit nem kell átengedni, a guest-en elég simán beállítani a TRIM-et.
Illetve NVMe-n nem tudom hogy lehet megoldani. Mert a TRIM parancs csak PATA/SATA/AHCI SSD-khez van, az UNMAP csak SCSI/SAS/UASP interface-esekhez. NVMe-n viszont a TRIM-et végző parancs bele van integrálva más lemezműveletekbe, ezért külön nem lehet meghívni, meg semmin keresztül átengedni. Na már most nem tudom, hogy a discard átengedése ezen mit segít.
-
Frawly
veterán
válasz
Dißnäëß
#29094
üzenetére
Nem a guest-ben kell a discard-ot beállítani, hanem a host OS fájlrendszerében, amin a qcow2 képfájl van. Kivéve, ha az SSD-t fizikai egészében adod át a virtuális gépnek, mert akkor a guest-en kell állítani, a host pedig nem használja.
(#29097) bambano: robokuty nagyon eltűnt mostanában.
-
Frawly
veterán
válasz
inf3rno
#29086
üzenetére
A snapshot sérült biztosan nem lesz. Legfeljebb egy időállapotot nem konzisztensen mutat. Ja, ez a megoldás sem mindenható, ha az lenne, akkor kihaltak volna a backup szoftverek és mindenki snapshotokat készítene kizárólag.
De mondom, ennek a gyakorlati jelentősége kicsi, mert olyan rendszerről, aminek a tartalma már a backup készítése alatt megváltozhat. Nyilván, ha tudod, hogy neked ilyened van, akkor más megoldás után kell nézni, vagy le kell csatolni a kötetet, és úgy backupolni.
-
Frawly
veterán
válasz
Dißnäëß
#29082
üzenetére
Pont azért egyesítették a két ZFS projektet, hogy ne legyen eltérés a kódok között. ZFS esetén valóban nem szükséges a softraid.
inf3rno: azért az ritka, ha valahol olyan sok tera gyorsan változó adat van, ami már a mentés készítése alatt megváltozik. Eleve a háttértárak korlátozott sávszélessége is korlátozza ennek az előfordulását. Attól is függ milyen adatot akarsz menteni, meg milyen fájlrendszerről.
-
-
Frawly
veterán
válasz
inf3rno
#29067
üzenetére
Nem sarkítás, igazuk van. A RAID a backupot nem váltja ki. Mert hiába a rendelkezésre állás, meg a fájlrendszer checksumja, az ellen nem véd, ha pl. emberi hibából, vagy szoftveres bugból adódóan felülírsz adatot, törölsz, vagy pl. ransomware darálja be. Vagy pl. a RAID és a fs checksum hibakorrekciós képessége is korlátos, ha túl sok lemez esik ki, vagy túl nagy blokknyi adat sérül, arra védelmet nem nyújtanak. Backupnak mindig lennie kell, hiába a redundáns RAID megoldás, utóbbi tényleg arra jó, hogy ha a lemez hibájából esik ki valamennyi, akkor legalább a rendelkezésre állás meglegyen.
Sokan tévesen hiszik, hogy jujj, RAID, akkor teljesen védve vannak, és nem kell backup. De, kell.
-
-
Frawly
veterán
Én jelenleg a QEMU-t használom KVM-mel, ahhoz ha telepíted a ovmf csomagot, és megmutatot a proginak az OVMF_CODE.df binárist, akkor UEFI-t használ, és ahogy a menüjében matattam, Secure Bootot is tud. Viszont én nem ajánlom, hogy Secure Bootot használj, sok előnye nincs, de az OS telepítéseket rendkívül megnehezíti.
-
Frawly
veterán
válasz
samujózsi
#28998
üzenetére
Abban egyetértek, hogy az rkhunternek utánanézhettem volna. De ha ettől boldog vagy, most megtettem. Egy rootkit elemző. Na már most két eset lehetséges. Vagy csak tévesen riasztott be valami heurisztika miatt, vagy a böngészőben futott valami olyan oldal, ami tartalmazott valami rosszindulatúnak minősített ad/miner scriptet. Emiatt én baromira nem aggódnék, hogy Ubuntun rootkitet szedtél volna össze.
Vagy ha mégis sikerült, akkor kitüntetünk, mert te lennél az első, akiről hallottam, hogy összeszedett támogatott desktop Linuxon valami csúnyaságot. Olyanról olvastam, hogy valaki hosszú évek óta nem frissített szerveren szopott be openssl heartbleedet, vagy valami ransomware-t, azt is valahol Kínában, de hogy még jelenleg támogatott desktop disztrón szedje össze valaki, olyanról nem hallottam még.
Ha viszont a GUI lefagy, akkor nem a böngészőben meg a hálózatban kéne a hibát keresni. Először a dmesg logban, journalctl-ben nézném meg, meg a X.org logban.
-
Frawly
veterán
válasz
vargalex
#28988
üzenetére
Az ilyen dolgain ki tudok akadni én is. Látszik, hogy sok mindent windowsos szemmel közelít meg. Azt sem értem, hogy egy shared memory szegmens hogy lehet gyanús.
Én első körben a problémáját érintve, megnézném hányas Firefox, megpróbálnám a Firefoxot safe mode-ban indítani, csinálnék egy pinget belső és külső cím felé is, lefuttatnék egy iw dev eszköznév station dump parancsot.
Hasonlót még az is tud okozni, ha névütközés van a hálózaton, pl. két gépnek azonos a host neve. De őt ismerve, hogy össze-vissza berheli a rendszerét mindenféle saját root-os megoldással, lehet bármi a probléma. Így a legbiztosabb az lenne, hogy egy új, Live Ubuntu-ról is kipróbálni, hogy ott csinálja-e.
-
Frawly
veterán
válasz
inf3rno
#28977
üzenetére
Attól függ, hogy kinek, mire kell. Desktop vagy server, milyen adatintegritási szint kell. Rendszeres biztonsági mentéseket készítő mezei desktop felhasználónak elég egy ext4 is. Esetleg egy btrfs snapshotozással. ZFS átlag desktop felhasználásra overkill, de szerverre meg teljesen jó. Kipróbálhatod most már mind a kettőt, a ZFS is támogatott a kernelben. Én azt még nem próbáltam, csak a btrfs-t, úgy 2 éve, akkor sem volt gondom vele.
Annyit persze még tudnod kell, hogy minél többet tud egy fájlrendszer, annál inkább jobb vas kell alá, meg több memória. Ilyen szempontból az ext4 még lájtos, a btrfs már combosabb, de azon is attól függ, hogy milyen feature-öket kapcsolsz be, a legerőforrásigényesebb a ZFS.
-
Frawly
veterán
válasz
samujózsi
#28966
üzenetére
Ez egy rossz gyakorlat. Ha sok parancs elé kell a sudo, akkor nem sudo -i-t kell kiadni, hanem su parancsot. Az root jogokkal futtat, de nem a /root mappájába szemetel, hanem abban a mappába, amiben épp terminálban dolgozol, ez lehet akármilyen tetszőleges mappa, akár a felhasználód home mappája is.
Ha rám hallgatsz, és desktop linuxról van szó, megfogadod a tanácsaimat. Csak a /home-ot és az /etc mented, meg a csomaglistát. Semmi mást, így mész át az új rendszerre, amit meg elve úgy telepítesz fel, hogy a /home a felhasználói adatokkal és mindenféle más adattal együtt egy adatpartíción legyen, külön partícióra a rendszer, külön bootpartíció, swap az nem kell (arra lehet swapfájlt csinálni), kivéve ha HDD-ről fut a rendszer (de arról nem akarod használni, pár nap híján lassan 2020-at írunk, már pendrive árában kaphatók SSD-k).
/root-ba semmit nem szemetelsz, ezt szokd meg, később sok szívástól megkíméled magad vele, meg ezt a mappát sem kell mentegetni. Felteszel normális, modern e-mailklienst, pl. Thunderbird, vagy ha minimalista kell terminálban, akkor neomutt, utóbbiban oda teszi az e-maileket, amelyik mappába mondod neki, nem kell később /var mappát mentegetni.
Most ezúttal a /var/log-ot se mentsd. Tudom, feltörték a gépet, rajtad van az NSA, most ezzel nem foglalkozol, ha ez a rendszered menni fog a levesbe úgyis. Újra lesz telepítve, normálisan, gányolásmentesen, nem lesz érdekes, hogy egy előző rendszerrel mit volt.
/usr-be semmi fontos nem kerül, ha van is konfigfájlt, akkor azt a ~/.config/ mappába kell tenni. Az /usr/share-ben általában az alkalmazások gyári, példakonfigja van, abban nem érdemes belebarmolni.
Eddig amit írtam, az mind szigorúan desktop linuxra értendő. Ha szerverről van szó, és ennyire nem vagy képben, hogy mi is kell neked, akkor meg az egész linux fájlrendszerről csinálsz egy tar.xz-s mentést a / mappából kiindulva, az a config, log, bináris fájlokat nagyon kicsire összetömöríti. Hosszú távon meg meglátod, hogy ebből mire lesz szükséged később. Mert lassan már az egész linuxos mappastruktúrát felsoroltad, hogy neked mind kell, talán csak a /bin /mnt /run /proc /sys /dev nem írtad, a többit mind sikerült felsorolni. Az /mnt /run mind csak csatolásra szolgál, /bin-be úgyis csak telepítsékor kerül bináris (meg az egy szimbólikus link, ami a /usr/bin-re mutat), a /proc /sys /dev /tmp mind illékony fájlrendszer, azoknak csak az aktuálisan futó rendszer alatt van értelmük. Van még az /srv, ha használod, szerveren el lehet azt is menteni.
-
Frawly
veterán
válasz
Jester01
#28960
üzenetére
Az ilyen script futhat akárhonnan root joggal. Nem kell feltétlen a /root alatt lennie. /root alá betenni akármi fontosat is, felesleges önszopatás.
@samujózsi: én az ilyen mentéseket tar.gz-be csinálom, tar-ral, de ha rendszeres backupot egészítesz ki vele, akkor lehet rsync is.
-
Frawly
veterán
válasz
Frawly
#28958
üzenetére
De ez még Windowson is így van. Ott is lehet úgy üzemeltetni a rendszert, hogy a rendszerpartíción lehetőleg semmi olyan pótolhatatlan ne legyen, amit reinstall előtt mentegetni kéne külön. Tehát érdemes a Dokumentumok mappát áthelyezni, a Thunderbird, Firefox, stb. profilmappákat is adatpartícióra helyezni, Steam játékmappáit is, meg minden hasonlót. Egy kis előrelátással sok időt spórol magának az ember, hogy esetleges reinstallkor kevesebb teendője legyen, és simábban, fájdalommentesebben újrahúzza a rendszert.
-
Frawly
veterán
válasz
samujózsi
#28957
üzenetére
A /var/spool is csak akkor fontos, ha mailserver, vagy régimódi mailkliens oda gyűjti be az e-maileket, meg a szerverről letöltöd őket. De a modern desktop mailkliensek, mint pl. a Thunderbird és társai, már a ~/.whatever mappákba mentegetik a mailokat, a TB pl. ~/.thunderbird/blabla.default/blablaMail mappába, amit ugyebár a /home mentésével eleve kimentettünk.
Én pl. IMAP-pal használom a fiókjaimat, így a levelek a szerveren maradnak, és csak archiváláskor mentek e-mailt, saját mappába. Így nem kell semmit menteni a /var/-ból.
A kérdésed hiába fogalmaztad át, hogy hol lehet lényeges dolog, a véleményem nem változik. Lényeges dolog ott lehet, ahová számodra lényeges dolgot tettél. Nálam a /home egy külön adatpartíción van, így a felhasználói adatokat soha nem kell mentenem, csak a /home partíciót felcsatolni a következő rendszeren telepítéskor. A /home nálam komplett adatpartíció, tehát nem csak a felhasználóm home mappája van rajta, hanem játékok, letöltések, torrentek, dokumentumok, telepítőképek, virtuális gépek, minden kutyafüle.
A /root-ot sem menteném, elég szélsőséges felhasználás az, amikor fontos dolgot tartalmazhat. Nem szabad semmit roottal használni alapvetően, azért.
Amit esetleg menteni lehet, az a bootpartíció, meg GRUB konfig pl. De még ezt sem mindig kell, hiszen ha a boot külön partíció, akkor megmarad, csak fel kell csatolni és a grubot kell újra feltenni. Nálam EFI partíció van, azon is megmaradnak a boot-tal kapcsolatos dolgok, újratelepített rendszeren használom tovább a boot partíciót, még fájlrendszer UUID-ket sem kell átírni, mert PART UUID-ket használok, és az nem változik formázáskor sem.
Tehát további hasznos dolog, hogy ha a rendszert úgy telepíted, úgy szervezed, hogy egy újratelepítéskor a legkevesebb dolgot kelljen lementegetni. Mindenféle hülye mappákba szolgáló telepítéseket és adattárolást mellőzni kell a root partíciót.
Amit még meg lehet nézni az a /opt. Néhány offline installeres progi (főleg játék) ide szereti betenni az adatait. A használatát kerülni kell, de ha mégis lenne benne, ami kell, akkor érdemes ránézni. Menteni azért ezt sem szoktam, mert ezek a progik újra beteszik magukat ide, amikor az új rendszeren újratelepítem őket.
-
Frawly
veterán
válasz
samujózsi
#28953
üzenetére
Nem is kötelező megfogadni. Te kérdezted, hogy mit mentünk, leírtuk. Én még abban is belementem, hogy amit nem mentek, azt miért nem mentem. Ettől te még mentheted, kicsire összetömöríthető úgy is, sok helyet nem foglal, a Mentési Kommandó sem rúgja rád az ajtót miatta, hogy legumibotozzanak, de azt kell észrevenni, hogy csak az elektronikus információ szemetet halmozod vele. Régen én is mentettem sok mindent, egyszer majd jó lesz valamire alapon, hát sose kellettek azok a dolgok semmire.
-
Frawly
veterán
válasz
samujózsi
#28951
üzenetére
Jó, de ezt nem értem, hogy mit segít egy MÁSIK rendszer alatt, ha egyszer már nem annak a logja. Ez épp olyan, hogy Mari néni bemegy a piripócsi kórházba, és Pista bácsi tüdőröntgenje alapján kezdik kúrálni, mert az van meg nekik.
Szóval a logok átvihetők, szövegfájlként jól összetömöríthetők nagyon kicsivé, én csak az értelmét kérdőjelezem meg, hogy mit kezdesz a logokkal. Én pl. majdnem 6 éve linuxozok már (fő rendszer, fizikai telepítés, nem virtuális gép), és sose volt szükségem a logokra rendszerek KÖZÖTT. Adott rendszeren vettem én is hasznát, de egy másik rendszeren már nem volt sose rá szükségem. Egyszer sem törtek fel, sem Windowson, sem Linuxon.
Vírust még Win98 alatt szívtam be vagy 20 éve, könnyelmű kattintással, mert a ZonaAlarm tűzfal process control modulja meg is fogta volna, de reflexből félrekattintottam, és egy foltozatlan KaZaa-kliensen keresztül benyomtak a rendszerbe egy vírust. Meg utoljára talán 2004-ben, mikor SP0-ás XP-t próbáltam feltelepíteni, és azonnal benyalta telepítés utáni első percben a Blaster RPC rebootolós vírust, de azt a rendszert azon nyomban lesikáltam, és még aznap szereztem egy SP1-es telepítőt.
Az ilyen logokat csak szerveren szokás eltenni, pl. webszervernél statisztikának, hogy ki a látógatóközönség, megtalálják-e keresőbotok, támadás alatt van-e. De egy linuxos rendszer logja nem sok mindenre jó egy teljesen másik rendszeren. El lehet menteni, de inkább pótcselekvésnek, meg retró reflexnek nevezném, mint értelmes mentésnek.
-
Frawly
veterán
válasz
samujózsi
#28949
üzenetére
De pont ez az, hogy egyszer volt rá szükséged. Akkor sem újratelepített rendszeren, gondolom. Az újonnan telepített rendszeren mit érdekel téged, hogy a régi (már törölt) rendszer logjai alapján a régit feltörték? Hiszen már addigra egy új rendszert futtatsz.
Meg a Linux ugyebár nem Windows, amit csak úgy feltörnek, meg vírusos lesz.
Most nem azt akarom mondani, hogy a logoknak nincs értelme. Van. De nem egy másik rendszer logjainak. Hanem az aktuális rendszer logjának, szigorúan. Ezért a régit nem érdemes áthozni az új rendszerre. Sőt, az aktuális rendszer logjának is csak addig van haszna, míg a hibát elhárítod.
Ha rendesen telepítesz fel akármilyen Linuxot, betartod a biztonsági ajánlásokat (jelszók, nem futtatsz mindig mindent root jogokkal, hivatalos tárolókból telepítesz, meg megbízható fejlesztői forráskódból forgatsz), akkor nem kell ilyen feltörés, meg vírus miatt aggódnod.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Bár egyre kevesebbszer, mióta Vifm-et használok helyette.
De legalább qemu-kvm-ben nem lassul, igaz nincs is hova neki, mert akkor átmenne negatívba a sebessége 
Új hozzászólás Aktív témák
Hirdetés
- Linux kezdőknek
- Könyvajánló
- Bambu Lab 3D nyomtatók
- Apple iPhone 16 Pro - rutinvizsga
- TCL LCD és LED TV-k
- Argos: Szeretem az ecetfát
- RAM topik
- Intel Core i3 / i5 / i7 / i9 10xxx "Comet Lake" és i3 / i5 / i7 / i9 11xxx "Rocket Lake" (LGA1200)
- sziku69: Fűzzük össze a szavakat :)
- Vicces képek
- További aktív témák...
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Új, bontatlan World of Warcraft gyűjtői kiadások
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- PlayStation Network Card (PSN) ajándékkártyák, egyenesen a Sony-tól!
- Samsung Galaxy Xcover 5 64GB, Kártyafüggetlen, 1 Év Garanciával
- Game Pass Ultimate előfizetés azonnal, élettartam garanciával, problémamentesen! Immáron 8 éve!
- Telefon felvásárlás!! Huawei P20 Lite/Huawei P20/Huawei P30 Lite/Huawei P30/Huawei P30 Pro
- AKCIÓ! Csere-Beszámítás! Manli RTX 3070Ti 8GB GDDR6X Videokártya!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest