-
Fototrend
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
-
samujózsi
senior tag
válasz
Dißnäëß
#29784
üzenetére
Érdemes megnézni egyébként az strace kimenetét a cp és a dd használatánál.
Tanulságos... Kis méretű, pár száz, esetleg pár ezer bájtos fájlnál a cp egy darab read és egy darab write-ot hajt végre, a dd meg, ha nem adok neki paramétert 512 bájtonként dobálja át, de látszólag ugyanazzal a művelet párossal.Hát ez most megint olyan, hogy vagy én emlékszem rosszul, ami könnyen lehet, vagy valami változott a linuxban az elmúlt évek során, vagy a "nagy" unixokon működtek másképp ezek a dolgok. Bennem olyan emlékek éltek régről, hogy a cp más rendszerhívásokat használ, mint a dd (a dd alacsony szintű I/O, míg a cp "magas" szintű...), de annyira rég volt, hogy akár még az ellenkezője is igaz lehet.
-
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.
-
samujózsi
senior tag
válasz
Dißnäëß
#29763
üzenetére
Azért is írtam, hogy ez csak a fantázia szülötte... fogalmam sincs, valóban tudja-e.
Főleg most, hogy egy "zfs crc checksum" keresésre nem pont az jött elő, amire számítottam.
Valahogy nálam a checksum és a CRC eltérő fogalmat takartak eddig, de vagy eleve rosszul tudtam, vagy valamit nagyon megkavart itt valaki...
CRC: rövidebb bájtsorozatokhoz egy-két bájtos ellenőrző összeg, a checksum-ot meg leginkább hosszabb adatok, teljes fájlok hash-elésével kapcsoltam össze (lásd md5sum, sha1sum stb.) -
samujózsi
senior tag
válasz
Dißnäëß
#29747
üzenetére
Hogy adat vagy checksum hiba, arra lehet megoldás a duplán tárolt checksum, illetve itt azt hiszem checksum és crc együtt vannak. Ha a crc vagy a checksum tér el, akkor az a hibás, ha mindkettő, akkor adatsérülés.
Azt hiszem... De ez már inkább a fantázia világa, mint konkrét ismeret. -
haddent
addikt
válasz
Dißnäëß
#29714
üzenetére
Cégek (részben pl mi is) azért használnak vSphere -t mert van fizetős support és mert drága és költeni kell. Na meg mert minden nagyrabecsült rencőrgaszda hülye a linuxhoz meg a cli -hez mint a ...
Sose fogom megérteni, főleg, hogy ha meg már vinydósz, akkor ott a hyper-v. Mindkét platformon van natív, jobb alternatíva ![;]](//cdn.rios.hu/dl/s/v1.gif)
Másik kérdésed így most este passzolnám, de érdekelne mi a célod vele, puszta kíváncsiságból
-
haddent
addikt
válasz
Dißnäëß
#29698
üzenetére
Ez már működőképes és rendkívül egyszerű, stabil és nagy hatásfokú. Ezt hívják KVM/qemu -nak. A többi vmware hyper-v meg társaik egy vicc kategória minden téren előbbihez képest.
Nálam pl. egy i7 3770 cpu szerveren fut virtualizálva egy pfSense, átpasszolva neki 4gigabites intel NIC, 0% veszteséggel, a konkrét PCI lane -t megkapja a vm. Mondjuk valszeg a winfos még ezt is el tudja b*#!@ni guest-ként is, de azért akkor is elég jó.
bambano sajnos én viszonylag későn kerültem képbe a linux-szal, éppen egyetem előtt. Egyetemen pedig a (még)továbbtanulós/architektes szakirányon a C# tolták
Ma már semmi pénzért nem tudnék (vagyis nevetségesen mocskosul rengetegért) Wintrágyán élni, lakni itthon vagy azzal dolgozni. Egy konkrét használhatatlan szemétdomb az egész.
Csak egy példa, csak ma: csudálatos májkószofttím DC -ket cserél, mindenhol DNS csere. Az összes linux szerver az enyém, mindegyiken 10 perc alatt lecseréltem, és még csak saltstackemet se vetettem be hozzá. Mivel néhány win szerver gazdája haverom aki szabin van, gondoltam jófej leszek és megcsinálom ott is, ha már van tartományi server adminom is. Ideglelés... 5-10 percig tölt, csinálja a fiókomat, előkészül, mindjárt kész... utána pofándob egy FRISSíTÉS!!!! ablakkal, amin csak egy "ok megnézem" gomb van, nem tudsz neki nemet mondani. Majd nem érzékeli a kattintást (mert ugye milyen cli/tty?!), majd 15 perc elteltével lehet elkezdeni az effektív munkát, amit 15 felugró ablak után el is jutsz az ipv4 konfigig. Egy szánalmas poén windowst használni bármire, kivéve amire kényszerülsz, azaz játékra -
Cyrin
addikt
válasz
Dißnäëß
#29594
üzenetére
ez a "logikátlan gimp" nézőpont kérdése, ha azt tanultad volna meg, és használnád, és áttérnél PS-ra, ugyanezt mondhatnád...
meg fizetős progikat ne ingyenesekkel hasonlítsunk már össze.
most hogy megszűnt a draftsight (2D-s Autocad gyakorlatilag), szétnéztem Autocad helyettesítő programok terén, van akár többet tudó választék linuxra is, csak nem ingyenes (ahogy az ACAD se az) pl BricsCAD.
de ingyenes is van pl. QCAD, vagy LibreCADAz openshot is ingyenes, és van windows-ra is.
Ezt se fizetős winonly programokkal hasonlítsuk össze. Főleg ne egy Sony Vegas-szal (én még így ismertem régről), ami sokkal komlexebb, sokak számára nehezen kezelhető volt anno amikor én foglalkoztam ezzel a témával, még win alatt.
Az openshot a legegyszerűbb ingyenes videoszerkesztő, még ingyenes fronton is vannak jóval komplexebbek. -
-
I02S3F
addikt
válasz
Dißnäëß
#29582
üzenetére
Ugyan Linux párti vagyok, de desktop-on szerintem nem olyan jó programok vannak rá, mint Windowsra. Igaz Windows-nál mindenért is fizetni szükséges. Például Ableton vs a Linuxos megfelelője, vagy az Openshot vs Sonynak a videóvágója.
Ezek azért egy home user-nek is jól tud jönni.
Jelzem, hogy csak a szakdogám írására indítok Windows-t. Minden egyébet Linuxon csinálok.
-
samujózsi
senior tag
válasz
Dißnäëß
#29463
üzenetére
Köszi, de annyit azért tudok, hogy tudatlanul jobb nem piszkálni a netfilter táblázatokat és azt is tudom, hogy nem értek hozzá.
Az ipchains-t még nagyon bátran piszkáltam, aztán jött a netfilter/iptables, azóta csak valami ufw jellegű eszközzel... nagyon ritka, ha másképp hozzá merek nyúlni. -
samujózsi
senior tag
válasz
Dißnäëß
#29366
üzenetére
Nem akartam beleszólni, mert rákeresve az ext4 defrag kifejezésre jött használhatónak látszó találat, inkább hallgattam. De én is úgy tudom, hogy már ext2 óta nincs igazán szükség defragra, mi több, én úgy hallottam, nem is javasolt.
Valaki említette az ntfs-t... én utoljára fat32-t kényszerültem defragmentálni. (Win98) -
Jester01
veterán
válasz
Dißnäëß
#29356
üzenetére
Az is régi bölcsesség, hogy az ext fájlrendszerek nem annyira hajlamosak a fragmentálásra, hogy ezzel foglalkozni kelljen. Pl.
usr: 248667/1310720 files (0.2% non-contiguous), 3049959/5242880 blocks
data: 1747239/7813120 files (3.3% non-contiguous), 105450969/124999728 blocks -
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
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.
-
-
samujózsi
senior tag
válasz
Dißnäëß
#29335
üzenetére
Nem akarok nagyon kötekedni, de ez tényleg túlzott para.
A biztonság, az biztonság, függetlenül attól, hogy privát vagy enterspájz.
Ez a terelés csak hamis biztonságérzetet kelt.
Kb olyan, mint routereken a MAC szűrés.
Ettől nem lesz biztonságosabb.
Ha félted az adataidat, legyen egyetlen, kellő bonyolultságú és hosszúságu jelszavad, a többi slot maradjon üresen és nincs vele gond.
Nézz körül a cvedetails oldalán( [link] ), hogy milyen ismert problémák voltak, esetleg vannak a diszk titkosítással!
Átfutva rajta, maga a LUKS biztonságosnak tűnik, de nem néztem végig egyesével. -
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.
-
inf3rno
nagyúr
válasz
Dißnäëß
#29320
üzenetére
Szerintem teljesen felesleges ezzel bajlódni. Nem jelent számottevő plusz védelmet. A titkosításnak kell jónak lenni, aztán nézheti az NSA is, nem tudják feltörni belátható időn belül, ha nem olyan az algoritmus, ami alapból hibás. Valszeg nem is nagyon fognak próbálkozni vele, hanem megdolgoznak egy kicsit, hogy add meg nekik a kulcsot, ha olyasmiről van szó...
-
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ó.
-
bambano
titán
válasz
Dißnäëß
#29308
üzenetére
a debian telepítője alapértelmezetten tud bootolni titkosított partícióról. minek ehhez usb?
a másik kérdés: ha egy alkalmazás nem támogatja a ha clustert, akkor azt nemigen fogod átteni ha clusterre. olyat, hogy egy san partíciót két helyre mountolj írhatóan, cluster fájlrendszerek tudnak, ha jól emlékszem az ocfs és a gfs ilyen.
inkább azt csináld meg, hogy írsz egy egyszerű programot, ami egy master könyvtárból szétmásolja több alkönyvtárba a fájlokat és ezekre ereszted rá a feldolgozó programokat.
vagy ha nem tudod kikerülni a folyosón a jáva architektedet, akkor az azt fogja mondani, hogy csinálj message queue service-t.
teljesítmény bővítésre mindig a legegyszerűbben járható út először a több ram, utána a nagyobb vas.
-
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.
-
-
samujózsi
senior tag
válasz
Dißnäëß
#29305
üzenetére
Az biztos, hogy van ilyen, de linuxos változatokkal nincs tapasztalatom, sőt... ha nem jön jobb válasz, próbálj körülnézni a wikipedián, a veritas (vxfs?) és az oracle ocfs oldalán. Előbbi fizetős és talán Solarison láttam működni, utóbbi állítólag gpl, de fogalmam sincs, ha nem oracle rdbms van rajta, akkor mennyire használható. Viszont az oldalán vannak hivatkozások más clusteres fájlrendszerekre, ezért javasoltam kiindulási pontként.
-
samujózsi
senior tag
-
samujózsi
senior tag
válasz
Dißnäëß
#29279
üzenetére
1. Én csak az "egyszeri" változatát ismerem. Gyakorlatilag valami hasonlítgatás+cp vagy scp (lokálisan azt hiszem, nem használ ssh-t)
2. Passz. Szerintem ez nem része az rsync-nek, de lehe, hogy hiányosak az ismereteim, valaki tán tud biztosat.
3. Utolsó emlékem, hogy egyirányú, de törölni is tud. (Ha valaki bővebb infóval rendelkezik, remélem, kijavít)
4. Elkezdi másolni, észreveszi, hogy változott, kezdi újra. Van egy limit, hogy hányszor próbálkozzon, utána eldobja. Ha csak nyitva van, de nem módosul a másolás alatt, akkor sikeresnek tekinti a másolást. Ez utóbbi kivédésére lvm snapshotot vagy ha a fájlrendszerben van snapshot funkció, akkor azt javasolnám használni, amit az rsync végén el lehet dobni. De csak akkor, ha a módosítás alatt álló fájlokról mindenképp akarsz másolatot. A példádban említett iso letöltéshez pont nem jó. -
samujózsi
senior tag
válasz
Dißnäëß
#29106
üzenetére
No, kvm, ubuntu 18.04 alatt: virt-manager-ből a diszket át kell állítani SCSI-re és a Performance options alatt a Cache mode-ot writeback-re állítani.
A virtio diszket használva a guest nem tud arról, hogy SSD van alatta, SCSI-re váltva már látható az lsblk -D kimenetében. -
samujózsi
senior tag
válasz
Dißnäëß
#29109
üzenetére
Kvm-hez használd a virt-manager-t(GUI)!
Ott nem pilótavizsgás a beállítás.Virtualbox linux hoston addig viszonylag jó, amíg nincs secure boot. Ha van, akkor kicsit macerás, mert a virtualbox kernelmodult minden kernel update után alá kell írni, plusz kell egy MOK amit felveszel az EFI-ben. Én elég hamar feladtam.
-
samujózsi
senior tag
válasz
Dißnäëß
#29106
üzenetére
Ahogy feljebb írtam, linux guest esetén egy lsblk --discard paranccsal meg tudod nézni, hogy mi a helyzet, csak utána kellene nézni a részleteknek.
Illetve még a hdparm -I is kiírja, ha van TRIM.Kvm/qemu alatt szinte biztos, hogy állítgatni kell valamit, a default opciókkal a guest nem tud a trim létezéséről. Ha nagyon nem találod, szólj, megpróbálom előszedni, hogy en hogy csináltam. Virtualboxról nem tudok mit mondani, annak utána kell nézni.
-
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.
-
samujózsi
senior tag
válasz
Dißnäëß
#29094
üzenetére
Elvileg tud trimet közvetíteni, kvm guest és az ssd közt, de nem tudom, mit kellett beállítani hozzá és költözéskor legyalultam a virtuális gépeket a notebookról.
A guestből az lsblk segítségével meg tudod nézni, alkalmasnak látja-e a virtuális géped a diszket ilyesmire, de erről sincs több emlékem. -
samujózsi
senior tag
válasz
Dißnäëß
#29092
üzenetére
Qemu-ban futtatnád a fizikai vasra telepített windows10-t?
Mert az (szerintem) nem fog menni.
Telepítéskor a windows a hardverhez igazítja magát és a qemu-ban totál más hardverkörnyezetet fog találni. 10-esnél erre nem vennék ugyan mérget, korábbi verziók mind így működtek. -
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.
-
-
válasz
Dißnäëß
#29059
üzenetére
Nem vagyok egy nagy szkript mágus, de ezt szerintem úgy kezdeném, hogy mindennek legenerálom az md5sum-ját. Egy-egy fájlba, aztán onnan kiindulva jöhet a többi funkció megvalósítása.
(#29073) inf3rno A modern fájlrendszerek checksum képessége tényleg hasznos. Sőt én emiatt konkrétan elavultnak tartok bármilyen nem szoftver RAID-et. A hardver RAID vezérlő meghalásától sokkal jobban félnék, mint egy stabil fs-től. A másik meg nyilván az ECC ram, ott ahol fontos adat van mindenképpen ECC ram kell.
A helyzet komolyságától függően lehet a backup-ra is szoftveres RAID-et tenni Ennek normál esetben nem látom értelmét. Ha meg valami tényleg komoly kell, akkor meg georedundancia + backup mágnesszalagra.
-
samujózsi
senior tag
válasz
Dißnäëß
#29059
üzenetére
Nem állítom, hogy pontosan értem, mit szeretnél.
Ha a B alatti könyvtárstruktúra módosítást szeretnéd az A-ra átvezetni, arra szerintem (!!) nem találsz automatizált megoldást.
Van az rsync, amivel azonos könyvtárstruktúrákat tudsz szinkronba hozni, akár úgy is, hogy ami az egyik oldalról hiányzik, azt törölje a másikon is, de ha jól értelek, akkor nálad olyan kellene, hogy x fájlt a sokadik alkönyvtárból fel kéne hozni mondjuk a második szintre (példa: A/s/d/f/x van most az egyik, B/m/x a másik helyen és te az A/s/d/f/x-et törölnéd, helyette lenne A/m/x, de ha az A/s/d/f alatt van olyan, ami a B/m alatt nincs, akkor azt megőriznéd)
Ezt jelen ismereteim szerint csak manuálisan lehet.Illetve még olyat csinálhatsz, hogy ha van elég helyed, hogy A alá visszamásolsz mindent B-ről, az új struktúrának megfelelően, de törlés nélkül és ráküldöd az fdupes parancsot, és ebből válogatod ki a felesleges fájlokat, majd törlöd őket.
Mondom: feltéve, hogy jól értelek és az rsync sem változott túl sokat az elmúlt két évben.
-
samujózsi
senior tag
válasz
Dißnäëß
#29062
üzenetére
Az kimaradt: a RAID nem véd a fájlrendszer sérülése ellen. (Pl zsaroló vírusok, vagy épp egy jól irányzott dd parancs
)
Értelme lehet házi használatnál is, például a sok kis kapacitású diszkből egy nagyot összerakni (ezt szintén kifelejtettem).
Csak mikor olyat látok, hogy valaki fontos adatot és RAID-et említ egy mondatban, akkor feláll a szőr a hátamon. -
Dißnäëß
nagyúr
válasz
Dißnäëß
#29062
üzenetére
Az már érdekesebb kérdés, hogy szükéges-e mindezt az adatot egyszerre, egyben elérni, vagy elég archiválni őket (az archív redundanciájának biztosításáról beszéltünk már?
) , vagy ahogy Te írod, backup, tehát minimum két helyen van aszinkron módon tárolva ugyanaz az adat, az egyik az élő, a másik meg akkor frissül, mikor úgy gondolja a user.Ez jó meglátás, de én itt is hiába vannak mondjuk 2014-es képeim, a kényelmet választottam, hogy bárhol, bármikor elérem őket. Raid van, backup nincs. Raid logikai hiba ellen nem véd, viszont szegmentálva a storage-ot vagy fájlrendszereket vagy könyvtárakat (kinek mi), lehet olyat, hogy aktuál évi adat r/w, tavalyi és régebbi adat r/o -ként mount-olva és akkor ez ad némi biztonságot user hiba ellen is.
De amúgy jogos a felvetés.
-
samujózsi
senior tag
válasz
Dißnäëß
#29060
üzenetére
Félve kérdezem: nincs itt némi kavarodás a fejekben a különböző RAID megvalósítások használatát/célját illetően?
Ami fontos, arról backupot kell készíteni, akár naponta többet is.
A RAID arra van, hogy hardverhiba esetén ne kelljen leállni, illetve egyes variációknál a performancia javítására.
Nem először látok olyat, hogy fontos adat=RAID, csak ezért említem.Ha olyan adatokról van szó, ahol akár pár percnyi adatvesztés is gondot okoz, akkor meg adatbázis, folyamatosan fizikailag másikndiszkre archivált redo logokkal. Vagy ha tud ilyet a btrfs/zfs, akkor akár azt is lehet használni.
-
haddent
addikt
válasz
Dißnäëß
#28662
üzenetére
Ezzel nem teljesen értek egyet. Abban igazad van, hogy egy szolgáltató szolgáltat, ebből él. Tehát ha hiba van, kérés, igény bármi, akkor szólsz és ugranak rá, mert ha nem elvesztenek és elesnek a megélhetésüktől. Abban is igazad van, hogy mivel ők nem egy-kettő netán 100 instancet üzemeltetnek, hanem (száz)ezreket, vagy többet, ezért minden felgyorsul. Nagyobb csapat, egy helyen lévő hiba mindenhol javítódik, stb stb..
Na ezért nem szabad egy problémát megoldani többször, tipikus rabbit hole. Tudni kell keresni, mert 99%, hogy bármi jut eszedbe, már van rá megoldás és jobb, mintha te nekiállsz gányolni egy kis csapattal.Azzal nem értek egyet, hogy ezt lényegében részrehajlóan csak 3rd party hostinggal lehet elérni. Egyrészt elvből kiröhögöm még az olyan Azuret is, amit on-premise kihoz az m$ és ledob a pincédbe. Nálunk a cégnél van ilyen, ehh.. továbbra is az futkos ott amit az m$ akar, ki tudja mi.. Ezzel max. azt lőttük ki, hogy nem megy ki a public netre és nem tudják fizikailag elvinni az m$ telephelyéről. Ezek azért ma már megoldott dolgok szerintem, nem ezen van a hangsúly.
Nem rossz dolog ez, de az agile is kötött, főleg egy kommersz cégnél. Ami sokaknak tetszik (a mazohista hülyék
), épp ez, az előnye is, hogy kötött, az az óriási hátránya is. Míg egy open source projektnél ilyen nincs, ráadásul ott van előtted a programkód, nincs turpisság meg susmus. Szerintem a legjobb választás egy olyan open source implementáció ami mögé már kiépült egy kommersz cég, aki azonban nem az eladásból, hanem a supportból él. Ott megvan a napi szintű pörgés és a community ereje, viszont nem csak a gugli és stackoverflow marad, ha beüt a gatya.. Mindkét világ jósága.Az, hogy a legtöbb cég és kedves kollega 20-25 évvel le van maradva pedig nem azt jelenti, hogy az törvényszerűen csak úgy működhet. Mondom ezt úgy, hogy ELTE -n tanultam papíron formális matematikai nyelven ciklust meg programkódot írni és C/C++ hívő vagyok, csak nem hülye
Simán kiépíthető egy poc/teszt és egy live környezet. Előbbi akár napi szinten automatizálva rángatja a frissítéseket és verziókat, Jenkins CI build + test, amint pass át is csapja livera. Mindezt mondjuk Dockerrel megspékelve gyönyörűen logolható, nyomonkövethető és fenntartható környezetet kapsz ami oda-vissza véresre veri az akár onpremise akár public monumentális nevetséges őskövületi szarokat akik már csak a nevükből élnek, mert más előnyük nem maradt 
Igen, az itt felsorolt megoldások merőben más gondolkodásmódot és szakembereket követelnek meg, mint az összekattintgatom egérrel microsoft jajjdejó megvan a winserver 2016 tanúsítványom elvégeztem a tanfolyamot dege#*menővagyok, de én ebben hiszek. Elismerem és elfogadom a te véleményed is, szerintem kicsit elkanyarodtunk és olyan mélységben tárgyalunk ahol nem feltétlen van megoldás és/vagy objektív igazság, hitvallás kérdése
-
bambano
titán
válasz
Dißnäëß
#28578
üzenetére
igen, teljesen beteg dolog, hogy ezt raid5-tel akarod megcsinálni
azt kellene eldöntened, hogy pontosan mit is akarsz. ha azt akarod, hogy legyen egy realtime másolatod, ami titkosítva van, arra nem ez a megoldás, hanem a crypto blokk device. ha azt akarod, hogy legyen másolatod, arra a korábban említett network blokk device nem alkalmas, mert teljesen döglött és nem vagy nem jól fejlesztett technológia.
ha azt akarod, hogy legyen egy gyors, redundáns, titkosított cuccod, akkor egymásra pakolsz 1-több drbd-t, arra crypto-t majd arra raid1-et. készülj fel rá lélekben, hogy ha systemd alapú oprendszered van, nagyon hosszasan, harsányan és cifrán fogod pöcstering anyját emlegetni. én 4 hónapig tettem
-
Frawly
veterán
válasz
Dißnäëß
#28399
üzenetére
Úgy engedték, hogy tudták, hogy this nice kolléga nem fogja úgyse feltenni a 9-est, mert 2019. július 6-án megjelent a végleges Debian 10. Igaz azzal vigyázni kell, mert még nem 10 évesek benne a csomagok, majd csak 20 év múlva jelenthet ki róla, hogy stabi, és ha használod, akkor nem támad hátba egy t-rex sem.
Itt a Debian Wiki-ben le van írva a lényeg:
apt-get install firmware-linux-nonfree libgl1-mesa-dri xserver-xorg-video-atiBár megjegyzem, hogy az xserver-xorg-video-ati nem feltétlenül kell, attól függ, hogy milyen felületet használsz, X.org vagy Wayland alapút, és hogy a kompozitor használ-e 3D-gyorsítást. Az xserver-xorg-video-ati ahhoz kell, hogy klasszik X.org WM-ek, amelyek nem használnak kompozitort, tudják használni a GPU nyújtotta 2D-s gyorsítást.
-
válasz
Dißnäëß
#28400
üzenetére
Nekem is volt valami ilyen bajom, amikor az ATi VGA-s Acerről költöztettem a Debian Testing-et a T400-asra, ami szintén ATi VGA-s, de van benne egy Intel integrált is. Nem volt kép az Intellel, de SSH-n elértem, így meg tudtam oldani (csak azt nem tudom már, hogy mit csináltam
) Viszont nem vot nehéz, mert meg tudtam oldani Esetleg egy fb=nomodeset ?
@Ubyegon2 : ++++, a non-free kell.
-
válasz
Dißnäëß
#28399
üzenetére
Nagyon nem vagyok hozzáértő, így csak halkan kérdezem egy 15+ éve Debiant használótól, hogy a non-free iso-t írtad ki? Ha már az elején tapasztalsz megjelenítési gondokat, azzal jobb kezdeni, mint később hozzáadni a repohoz.Szerintem a Debian 8 még használta az fglrx-et, míg a 9 már nem......
-
Dißnäëß
nagyúr
válasz
Dißnäëß
#28399
üzenetére
Ja, az eredeti terv annyi lenne a laptoppal mindössze, hogy fejlesztésre használom a strandon. Régi, nem egy izompacsirta, de sokat bír akksival. Távoli asztallal bemegyek az itthoni asztalimra és tolom a dolgot szépen, ennyi.
Esetleg egy céges email nézés, böngészés (nem youtube), ilyen alap dolgok.
Nem várok sokat egy Debian stable-től, csak annyit, hogy mainstream gyártó mainstream video chipsetjén adjon már képet könyörgöm. Ez nem egy S3 Trio, vagy urambocsá, Matrox Mystique.
-
Frawly
veterán
válasz
Dißnäëß
#28377
üzenetére
Ez ugyanúgy működik SSD-n is, ahogy HDD-n. SSD-n csak egy extra dolog van, ha van LVM, akkor azon keresztül kell engedni a TRIM-et, és ha van LUKS, akkor azon is. Ennek a mikéntjét az Arch Wiki leírja.
Kivitelezhető, amit írsz, de én ilyen kamu rendszert nem csinálnék rá, aki ért hozzá, az úgy is tudja, ha randomnak látszó adattal van tele a meghajtó nagy része, az titkosítás. Aki meg nem ért hozzá, annak meg felesleges kamurendszert csinálni rá.
De ha SSD-ről van szó, és az SSD és a gép is támogatja, akkor az SSD saját hardveres titkosítása is használható, igaz ez nem olyan megbízható, mint a LUKS, de az esetek nagy részében ez is elég lehet, és nem kell LUKS-szal meg USB-vel szívni.
-
#28380
Plasticbomb
addikt
Dißnäëß
#28379
Plasticbomb
addikt
válasz
Dißnäëß
#28379
üzenetére
SSD ket cimzest hasznal, egyet ami az oprendszerek fele latszik, illetve egyet ami alapjan tudja, hogy adott oprendszer felul latszodo cimre erkezo keres mely blokkban talalhato. O csak blokkokban latja az adatot.
Oprendszer fele mindket esetben ugyanugy fog latszodni. mas kerdes, ha valaki irni probal az adott cimterulethez tartozo blokkra, mintegy megformazni az "ures" reszt...
Bizonyos SSDk tudnak SSD szintu titkositast, utana neztel azoknak mar? Talan egyszerub lenne, mint kerbe futni elterelosdit jatszani (ertem az elgondolast mogotte, csak tul paranoiasnak erzem..).
-
válasz
Dißnäëß
#28377
üzenetére
Ezt jól megbonyolítottad, legalábbis én egy szót sem értek az egészből. Szerencsédre az SSD vezérlője is így van ezzel, azt csak az érdekli, hogy egy cella tartalmaz-e adatot vagy törlésre van jelölve, utóbbi esetben a TRIM ad a pofájára!
Finoman szólva a vezérlő arra is tojik, hogy particionáltad, ide- oda rejtegetted a biteket! Ő egy osztatlan területet kezel és annyit lát, hogy van adat vagy nincs adat. -
Frawly
veterán
válasz
Dißnäëß
#28186
üzenetére
Mindenképp azt mondom, hogy próbáld ki. Nézd meg mennyivel lett gyorsabb a RAID tömb, mint a szimpla lemezek önmagukban. Onnan fogod látni, hogy ezért a plusz sebességért megéri-e neked RAID-ezni egyáltalán. Ez így elvi síkon eldönthetetlen, hogy melyik lemezed hogy fog tetszeni a szoftveres RAID-nek.
-
bambano
titán
válasz
Dißnäëß
#28182
üzenetére
a bájtméretre nem érzékeny, mert az mindenhol 8 bit
a szektorméret már fogósabb kérdés, a régi diszkeken 512 bájtos fizikai szektorok voltak, az újakon 4096 bájtosak, ezt nem jó keverni, mert csúnyán ronthatja a teljesítményt. igazán alaposan azzal tudod lerontani a teljesítményét, ha nem illeszted 8 szektoros határra a szektorokat. Akkor akár 20MBps-t is ki lehet csikarni egy jó diszkből.
a gpt/mbr tudomásom szerint nem számít ebben a kérdésben. abból semmi gond nincs, ha különböző méretű diszkeken csinálsz ugyanolyan méretű partíciókat és abból raidet.
-
Frawly
veterán
válasz
Dißnäëß
#27931
üzenetére
Pedig attól lennénk előrébb, ha megértenénk mit akarsz PONTOSAN csinálni. Fogadok rá, hogy mindjárt kiderülne, hogy nem kell hozzá semmilyen grafikus felület. Már Windows Serveren is teljesen felesleges. A szerver pont attól szerver, hogy nem fut rajta sallang, nem kötsz rá monitort, nincs grafikus felület, egér, webkamera, egyéb felesleges sallang. Linuxban MINDEN megoldható konzolból, pláne szervernél. Gondolom azért hobbiprojekt, hogy tanulj belőle, nem azért, hogy Linux alapon hozz létre Windows Servert.
-
sonar
addikt
-
#68216320
törölt tag
válasz
Dißnäëß
#27916
üzenetére
Az a bosszantó, hogy kipróbáltam UEFI/MBR win gépek esetében a törlést, de a TestDisk linux live-ról indítva hibátlanul visszahozta. Viszont az mdraid esetében nekem nem sikerült megoldanom a problémát. Persze lehet a "hozzánemértés" áldozata lettem, de sürgetett az idő. Viszont jó lenne megoldani a problémát egy teszt gépen, ha esetleg még 1x valami "zseni" csak úgy lazán eldobja a partíciókat egy új GPT kiírás mellett.
Sürgetett az idő, így is ~10órába telt a resync.
Sose fogom megérteni, főleg, hogy ha meg már vinydósz, akkor ott a hyper-v. Mindkét platformon van natív, jobb alternatíva ![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ma már semmi pénzért nem tudnék (vagyis nevetségesen mocskosul rengetegért) Wintrágyán élni, lakni itthon vagy azzal dolgozni. Egy konkrét használhatatlan szemétdomb az egész.
Új hozzászólás Aktív témák
- EA Sports WRC '23
- LED világítás a lakásban
- Kazy Computers - Fehérvár - Megbízható?
- Az áremelések és a GTA VI késése miatt nem költekeznek a játékosok?
- Debrecen és környéke adok-veszek-beszélgetek
- Autós topik
- Azonnali alaplapos kérdések órája
- Borotva, szakállnyíró, szakállvágó topic
- Elstartolt az AMD munkaállomásokhoz szánt platformja
- gban: Ingyen kellene, de tegnapra
- További aktív témák...
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Assassin's Creed Shadows Collector's Edition PC
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5060 Ti 16GB GAMER PC termékbeszámítással
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
- Üzleti Fujitsu Lifebook u7510 15,6" FHD IPS 2021/08. havi gyártás
- Bomba ár! Dell Latitude E5570 Touch - i5-6300U I 8GB I 256SSD I 15,6" FHD I HDMI I CAM I W10 I Gari
- 120 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!)
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged