- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- ZIDOO médialejátszók
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Gaming notebook topik
- BIOS topic
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- A partnerektől függ, hogy lesz-e Arc csúcs-VGA az aktuális generációban
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Androidos fejegységek
- SONY LCD és LED TV-k
-
PROHARDVER!
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
#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.
-
Zahze
csendes tag
Sziasztok,
Lehet nem jó topikban kérdezek, de mivel Linux rendszeren tapasztalom az alábbiakat ezért itt is szerencsét próbálok.
A szolgáltatómnál sávszélesség növelés miatt router is lett cserélve egy F@AST 3890 V3 -as modellre. A régebbi routeremnél nem jelentkezett az alábbi hiba így valószínűsíthető hogy a mostanival "nem kompatibilis" a rendszerem (Linux Mint 19.1 Cinnamon)
Hiba leírás: A laptop felcsatlakozik a routerem wifijére, és kb 10másodpercenként elmegy ~5-10 mp-re a netem (a wifi kapcsolatom fixen megvan).
Ha indítok egy ping-et mondjuk a 8.8.8.8-as címre akkor pontosan látszik mikor van netem (kb 10 icmp üzenetig), és mikor "megy el".
Ezen felül érdekességképpen megemlíteném hogy ha mobilon rácsatlakozok ugyan erre a wifire akkor a router címét könnyedén elérem, míg laptopon ez nem igaz (ERR_CONNECTION_REFUSED).
Más eszközzel nincs ilyen probléma, csak egy adott laptoppal. Ha másik laptopon de ugyan úgy Linux mint rendszerrel csatlakozok fel ugyan arra a wifire, akkor azon se kerül elő ilyen hiba.
Ez mitől lehet ? -
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.
-
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.
-
samujózsi
senior tag
válasz
Jester01
#29782
üzenetére
Azt tudom, de Dißnäëß ragaszkodott a mc másoláshoz.
Egyébként abban nem vagyok biztos, hogy a dd korrekt eredményt ad (persze mihez képest), mert valami rémlik, hogy megkerül bizonyos fájlkezelő funkciókat, emiatt gyorsabbnak mutatja a másolást, mint amit valójában tudna a rendszer.
(de lehet, hogy keverem a dd if=/dev/sda ... formával, ahol eleve a device-t adom meg inputként) -
-
samujózsi
senior tag
-
Dißnäëß
nagyúr
válasz
samujózsi
#29774
üzenetére
Természetesen
de egyből overwrite kérdés, majd másol és a végén a hiba, hogy nincs joga (még szerencse, root-ként képes lenne felülvágni).. 
1 fájllal.
Ha viszont 2+ fájllal csinálom ezt, vagy fájlok-könyvtárak vegyesen, devnull már nem is adható meg, mert eleve ugat, hogy könyvtárat kér
-
Dißnäëß
nagyúr
Kicsit más: van itt olyan elvetemült, aki szereti az MC-t néha elővenni ?
Arra lennék kíváncsi, hogyan tudok vele /dev/null-ba másolni (magyarul fájl másolás valós sebességet mérni). Ezt régen mintha tudta volna, vagy lehet keverem a Far Manager (?) "nul" target-jével ?
Parancssorból oké, most csak így MC-re specifikusan kérdem.
-
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.
-
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.) -
Dißnäëß
nagyúr
válasz
samujózsi
#29749
üzenetére
Nem mondom, hogy nincs igazad, de én úgy tudom, 1 drive mellett nincs zfs integritás-kezelés még. Nemrég rágtam át magam n+1 doksin és leíráson, szerintem kell hozzá a kettő. De megoldható 1 drive-on valahogy, valami nyakatekert trükkel, lehet. Csak úgy out-of-the box nem.
Zfs-en már az is előny, hogy az ellenőrző blokkok nem ugyanott vannak, mint egy dm-integrity esetén az adott adat blokkban, hanem máshol, így ha adat blokk sérül (jó eséllyel fizikai hiba miatt), annak az ellenőrzője nem ott lesz és ha van másik adatblokk +1 diszken (és annak ellenőrzője), 3-ból már egyértelmű, mi a jó és mi a rossz.
De 2 diszkkel nem csak redundáns, hanem golyóálló is lesz a motyó, az biztos
Amúgy lehet ECC nélkül is élni, de nonstop bekapcsolt gépnél sok csillagnak kell úgy állnia az égen, hogy nagyon ritkán történjen bithiba. Mindenesetre jó cucc, egy ASUS lapban Ryzen 3500-el most állok át ECC-re. (Szívom is a fogam, tuning RAM-ok ki, szottyadt 2400-asok be aranyáron, de legalább ECC, majd ellenőrzöm is, ha kicsit túl feszesre veszem gyáriról a timing-okat, ahol már kezd hibázgatni, hogy hogyan viselkedik).
-
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. -
Dißnäëß
nagyúr
Btrfs felejto, beszoptam vele meg onalloban is, raid amugyis bugos (0,1 stabilnak mondott, 5-6 gaz, de szvsz az egesz btrfs gaz).
ZFS csak ECC mellett, lasd elozo hsz-ek. De ha van ECC, ez egy rohadt jo filerendszer, de kicsit erteni kell hozza, kulonben a performancia nem lesz valami top. Backupra nem hasznalnam onallo meghajton.
Esetleg ext4-hez nezz egy dm-integrity -t is, bar van ahol kellhet es van ahol nem.
A 4T-s Seagate NAS HDD-m melle vettem meg egyet, tokugyanolyan parameteru WD40PURX-et.
A seagate-en van on-the-fly error correction, igy ott kisebb a valsege a rossz bit olvasasnak, mert mar hardver szinten korrigalja a HDD. A WD nem csinal ilyet (okkal, mert surveillance hdd), ergo annal mar felnek.
ZFS mirrort epitek, desktop lap, ECC RAM, igy ez sima liba, de backupra nincs sok ertelme a ZFS-nek, ha integritast nem tud szamolni 1 drive eseten: ha nem stimmel az adat es annak checksum-ja, mi alapjan donti el a ZFS, hogy melyik a szar, az adat vagy a checksum ?
Csak 2+ diszknel van ertelme ennek, ott el tudja mar donteni, es korrigal is. Szoval vagy ecc-s gepen zfs mirrort hasznalsz backup-ra ( = 2 diszk minimum), vagy elfelejted.2 hdd + ecc = zfs es jol parameterezni a pool-t letrehozaskor, ne defaulttal.
1 hdd = ext4.
-
samujózsi
senior tag
Az egy hibát csinál, nem görgeti végig a fájlrendszeren. Pár éve nyűglődött egy ismerősöm hasonló témával, akkor körülnéztem a google-n és találtam egy oldalt, ami sorolt pár ellenérvet ellenük.
Az egyik az volt, hogy ECC RAM nélkül veszélyes a crc/checksum használat ezeken a fájlrendszereken, mert ha a memóriában elállítódik egy bit, annak alapján automatikus javításba kezd(het?), ami viszont sokkal nagyobb adatvesztéshez vezethet, mintha csak az az egy bit sérülne.
Sajnos már nincs meg a bookmark
Ha ott hülyeséget irtak, mea culpa! -
samujózsi
senior tag
válasz
growler
#29741
üzenetére
Csak nem "on the fly", amennyire látom
A btrfs és a zfs ezt menet közben csinálja, csak én részben emiatt sem szeretem őket. ECC RAM viszonylag ritka az otthoni gépeken, ugyanakkor egy bithiba miatti automatikus javítás könnyen vezethet adatvesztéshez. (Jó, biztosan nagyon ritka a bithiba a memóriában)
-
_Dumber_
őstag
Sziasztok!
Arch linux- kde:
GTK 3 appok betűtipusát szeretném beállítani.
.config/gtk-3.0/settings.ini szerkesztésével sikerült mindent beállítani, de logout/login után ezt a filet visszaírja a szerkesztés előttire. (.gtkrc-2.0-t is )Mi a nyavaja írhatja vissza? Mi alapján írja vissza (mi az alapfile)?
-
Az /etc/sshd/sshd_config az egyetlen, ahol engedélyezni/tiltani lehet, hogy ki férhet hozzá a szerverhez SSH-n keresztül?
Van néhány CentOS alapú szerver, ami Active Directory/LDAP alapon authentikál. Aki bent van egy adott csoportban, őket beengedi, illetve ezen felül még a local usereket. Most az a feladat, hogy hozzáadjunk még egy LDAP usert, aki hozzáférhet adott gépekhez (de nem adhatjuk hozzá az előbb említett csoporthoz).
Az sshd_config fájlban nincs semmi erre utaló jel, a csoport csak a sudoers fájlban van megemlítve, semmi több.
Hol lehet a megoldás?
-
samujózsi
senior tag
válasz
haddent
#29722
üzenetére
Akkor ez debian/ubuntu specifikus?
Mert nekem rendre felülírta a resolv.conf tartalmát és miután sikerült rábeszélni, hogy az én szerveremet használja, még akkor is csak úgy, hogy a rendszerem (egy része?) a 127.0.0.53:53 dns-t keresi és az megy tovább a sajátomra, ha úgy látja jónak.
Ebből következik pár hibaüzenet a logban, meg az, hogy egyes módosítások a host nevekben nem mindig érvényesülnek azonnal.Apropó log: jó szokása a journalnak, hogy szabálytalan leállásnál megsérül.
-
haddent
addikt
válasz
samujózsi
#29721
üzenetére
Minden esetben, jelenleg is saját dns -t használok vele. Mi ezzel a probléma? Arch -on van egy systemd-networkd és egy másik ami netctl használ, egyiknél sincs probléma, nem nyúl soha hozzá az /etc/resolv -hoz. Ha szerverre gondolsz, az is van, bind szerver, ahhoz sem nyúl.
Melóban Suse esetén meg úgyis az a bánat Yast kezel mindent
Igen, na ez jogos. Szeret várakozni 1-2 percet ha megrogyik valami requirement boot során. Utána viszont ad egy recovery root shellt aztán uccu. Én ezt eddig nem tapasztaltam a kellőnél irritálóbbnak, hogy őszinte legyek, de igen, ez lehetne jobb -
samujózsi
senior tag
válasz
haddent
#29720
üzenetére
Próbáltál már saját dns-t használni vele? Lehetőleg úgy, hogy a systemd teljesen ki legyen iktatva a névfeloldásból?
Egy agyrém.
Kihagyni azt hiszem, nem is lehet.
Jó másfél éve, hogy szoptam vele, aztán tegnap, hogy előjött a systemd téma, kicsit nézelődtem a google-n és ez eszembe juttatta, mert más is panaszkodik rá.
Vagy... Amikor bootnál/shutdown-kor elakad valami. Mondjuk épp nem érhető el bootkor a dhcp szerver és képes percekig várni rá...
Persze, lehet módosítani a timeoutot, csak esetenként tojik rá. Stb.
A szerverem már szénné hackeltem miatta, így most működik, csak ritkán kergül meg, de ha legközelebb összefutok valami hasonlóval, majd leírom. -
haddent
addikt
Én továbbra is teljes tisztelettel kezelem a véleményetek, de szintén újra úgy érzem le kell írjam, hogy számomra viszont baromi kényelmes, flexibilis, agilis és könnyen kezelhető az egész systemd. Kifejezetten tetszik a .service, .socket .stb.. szisztéma, a konfigjai, a journald/journalctl jól kereshető, illetve csökkenti a logok méretét, néhány apró minimál cucc amit akkor használok ha csak 1 static ip vagy 1 dhcp client kell (systemd-networkd pl.) tök jó, komolyabb feladatra ezek egyelőre nem elegek de simán van és lehet mást használni..
Én nagyon örülök neki, hogy lett és van, mert legalább egy dologban "kiegyeztek" (nagytesók rákenyszerítették) a sok idióta 26ezer kis distrot, hogy ugyan használjanak már valami egységeset, ami fentebb sorolt indokokból ráadásul (nekem) tök jól jött kezelés, karbantartás ügyileg.
Nem kell egyetérteni, nem vitaindító, nem vita. Én elfogadom teljes mértékben a véleményetek illetve a "lelki"/filozófiai indokokkal részben egyet is tudok érteni, de részemről amíg f.o.s.s., addig hibátlan. Legyen ilyen tapasztalat is
-
bambano
titán
válasz
#23196416
#29716
üzenetére
az első és legfontosabb gond, hogy nem volt probléma. a systemd olyan problémát akart megoldani, ami nincs.
ezt viszont rendkívül alacsony minőségben sikerült.
a másik gond, hogy az init rendszer migrálása minden admintól sok munkaórát követel, amelynek rendes helyen költsége van. ki fizeti ki? ki adott felhatalmazást pöcsteringnek, hogy pénzt költsön más cégek büdzséjéből?nem, nem élek systemd migrálásból. egyszer akartam belenyúlni a systemd-be, kiderült, hogy a doksijának a zöme téves, a systemd egyáltalán nem úgy működik, mint a kottája. négy hónapomat vitte el. kinek számlázhatom?
a gond az, hogy van jól működő init rendszer. a legkirályabb migráció az, ha hagyod a régit békében. mindenkinek tisztában kellene lennie a munkavégzés első számú törvényével: az el nem végzett munka aranyat ér!
-
samujózsi
senior tag
Ha már systemd...
Surviving a security audit with enterprise linux
-
#23196416
törölt tag
válasz
bambano
#29688
üzenetére
Programozó, hogyne lenne nagy arca... Szerintem egy elavultan kezelt problémára adott egy új, jó, hatékony választ. Bughalmaz? És ha mindaz amit a szoftver tud, összeszeded egyes különálló komponensekből és kiegészíted saját scriptekkel mire nagyjából ugyanazt tudod hozni, mekkora lesz a kód és mekkora lesz a bughalmaz? Ha ebből élsz, és rengeteg munkaórát öltél enterprise környezetben sysv systemd migrálásra, bizonyára busásan megfizettek érte, egy egy erős win szituáció. De rajtam ne múljon, remélem a közösség hamarosan összefog a sötét nagyúr ellen, forkolja ördögi gyermekét, és a nap örökké ragyogni fog az új fork felett ami minden csorbát kiköszörül, hiszen mi is gátolna meg bárkit ebben?
-
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
-
Dißnäëß
nagyúr
válasz
haddent
#29713
üzenetére
Na ez nagyon jó, a vasamon most egy QEMU/KVM van az XFCE Virtual Machine Manager-e szerint, úgy pár hónapos Debian rendszer, ezt kezdem belakni. Nem gondoltam volna, hogy egy cégben is használt vSphere-el szemben ez labdába rúghat, az azért elég durvi cucc, ahogy láttam, csak itthon nem szórakoztam még el vele.
A tervem az, hogy a host-ot és annak fizikai hálókártyáját ugyan az ASUS router-em LAN portjára kötöm, de lesz egy VM, ami egy teljes saját alhálónak (a többi VM-nek) lenne a tűzfala, router-e, VPN koncentrátora, mindene (egy OPNSense, én most azt tanulgatom, iptables kézzel írás után elég nyakatekert, de szokható). És pár egyéb VM egy kicsivel nagyobb projektecske környezeteinek, amibe végre belevágok.
Amúgy eredetileg nem ezért jöttem ide, csak már reflektálok és köszi a visszajelzést.
--------------------------------------------------------------------------------------------------------------------------------------------
És akkor amiért jöttem: a jövőben szeretném a gépet Pendrive-ról boot-olni.
Van 3 teljesen új, teljesen egyforma, síkugyanolyan, egyszerre vettem.1. Mindegyikre tegyem ki a /boot-ot és a végén dd-vel másoljam át 1-es tartalmát 2-3-ra
VAGY
2. MD RAID1-ezzem be őket ? Egyedülállóan is boot-olnak ilyenkor nyilván. De szerintem ez csak komplikálja a dolgokat, mert minek.Nyilván ha a rendszeren upgrade-et ill. full-upgrade-et tervezek letolni, feltétlen beteszem az egyik pendrive-ot és mount-olom a /boot-ba, majd upgrade lefut, frissebb kernel a boot-on (a pendrive-on), a pendrive-ot ismét átmásolom a másik kettőre, frissítve így őket is aktuális boot-olóra és kész, kivehetem (a /boot-ot meg umounttal egyidőben egy HDD alapú kamu /boot-al helyettesítem - vagy nem kell egyáltalán, full tökelvan a gép apt upgrade-et nem cseszegetve /boot nélkül ? Mert akkor ha umount-olom a pendrive-os /boot-ot és kihúzom a kütyüt, nem is tökölnék a helyettesítésével amúgy. Ha minek).
-
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 -
kovaax
őstag
válasz
bambano
#29703
üzenetére
Sajnos a munkahelyi munkaállomásokon windows van, és úgy, hogy minden nap leállítom, másnap elindítom, az XP sp2 volt az első, amivel nem volt különösebb stabilitási problémám (az más kérdés, hogy egy csomó mindenben rám akarják erőltetni a f@szságaikat azóta is). Megkacsáztam, 2004 augusztus 25-én jött ki, kb. fél év után kaphattuk meg. Szóval addig stabilabb volt az otthoni linuxom...
-
Dißnäëß
nagyúr
válasz
bambano
#29703
üzenetére
Na jó, nem 24. 16-18 ? 96-ban Netscape navigátoroztam faternál a cégben és néztem a DOS után az űrtechnikát, utána jött egy ősrégi SUSE, amivel elkezdtem kapizsgálni egyáltalán, mi az a Linux, utána jöttek az első szopások VMWare-el, hát az ja, úgy kb. 2000-es évek első fele, pont gimi után. Akkoriban még jobban érdekelt az IT, mint a punci, érdekes módon.
-
-
kovaax
őstag
válasz
I02S3F
#29696
üzenetére
Nem, de ha hozzászoktál, hogy a linux aktuális lehetőségeihez vásárold a hardvert, sok szopástól meg tudtad magad kímélni. Plusz alapból unixokon dolgoztam akkoriban is már, így egészen másfajta elvárásaim voltak a "deszktoppal" szemben is (= X + böngésző + sok szöveges terminál).
Az más kérdés, hogy nem regular hanem character special.
Csak 2+ diszknel van ertelme ennek, ott el tudja mar donteni, es korrigal is. Szoval vagy ecc-s gepen zfs mirrort hasznalsz backup-ra ( = 2 diszk minimum), vagy elfelejted.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- Vírusirtó, Antivirus, VPN kulcsok
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Üzleti Fujitsu Lifebook u7510 15,6" FHD IPS 2021/08. havi gyártás
- PlayStation Network Card (PSN) ajándékkártyák, egyenesen a Sony-tól!
- Konzol felvásárlás!! Xbox Series S, Xbox Serries X
- HATALMAS AKCIÓK! GARANCIA, SZÁMLA - Windows 10 11, Office 2016 2019 2021,2024, vírusírtók, VPN
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7600X 32/64GB RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest