- Végre bemutatkozott a Google Pixel 4a
- Honor Magic6 Pro - kör közepén számok
- Samsung Galaxy Watch7 - kötelező kör
- Samsung Galaxy Z Fold4 - egyre megy, honnan nézed
- Samsung Galaxy Watch6 Classic - tekerd!
- Fotók, videók mobillal
- 7000 mAh fölé lőne a következő OnePlus Ace
- Milyen okostelefont vegyek?
- iPhone topik
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
-
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
-
vicze
félisten
Idézőjel okkal van ott.
Az hogy homályos, vagy hogy mennyire az a monitor FW-jétől függ, sajátom so-so, nem vészes, jobb mint a 100% CPU...A töredék skálázás maga működik, ezt senki se cáfolja, csak az overheadje ultra brutális...
Ráadásnak én VM-eket is futtatok, azzal teljessen leheteten bármilyen SW skálázás. -
vicze
félisten
válasz
Vasti74
#34447
üzenetére
Linux nem tud skálázni nem egész szozóval, HW gyorítottan. Egyikse se KDE, se Gnom, se Xfce, semmi. Wayland se megoldás.
4éve szívok a 4K-val. (Halmozottan szívok mert 2db 4K.) Egész pontosan 0 értelmes megoldás van.
Egyetlen "értlmes" megoldás, hogy amennyiben a monitorod támogatja kisebb a skálázásnak megfelelő felbontást azt állítod be. Pl. WQHD. (Igen igen tudom, minek vettél nagyobbat akkor...)Ez a alrendszer alap hibája a skálázással, bármi ami nem egész többszörös a render a CPU-ra van terhelve, tök mindegy hogy Intel, AMD, nV, és hogy milyen driver. Mindennel próbáltam már.
Kisebb felbontásonnis jelen van, csak ott lényegesen kisebb a CPU overhead és nem laggol, és nem feltűnő.
Bocs hogy nem segít, de sajnos ez a realitás.
Néha nekifutok, hog változott-e, de eddig 0 valós megoldással találkoztam. -
vicze
félisten
válasz
roseben
#34210
üzenetére
Pontosan, letöltöd a telepítőt és ennyi. Kell pár hét/hónap, hogy a driverek a kernelbe kerüljenek, ez minden HW-val így van. Zen APU-k teljes fagyás mentes támogatására kb. fél évet kellett várni. Qualcomm is 6 hónapot célzott meg, hogy mainline-ba kerüljön minden. Karácsonyra veheted gond nékül.
-
vicze
félisten
válasz
roseben
#34203
üzenetére
A kérdés alapból hibás. Bármi fut amit lefordísz rá. ARM nem újdonság ősiők óta támogatott.
Linaro megkapta a kernel karbantartását(Qualcomtól), szóval ahogy Android esetében úgy itt is idővel ők rakják majd a mainline-ba, amit Torvalds enged(Qualcom megnyit), de Linaro kernellel minden menni fog.[ Szerkesztve ]
-
vicze
félisten
válasz
sh4d0w
#34008
üzenetére
Csodás clickbait cím...
Schleswig-Holstein megint megpróbálkozik a Linux-szal. Jól haladnak 2021 óta...
Majd 2027-ben lesz cikk, hogy már 35000 PC-t váltanak...Az egészben az a leghumorosabb, hogy a német közigazgatás még minding 90%-ban papíron zajlik. Szóval végső soron nem Windowsról váltanának, hanem papírról.
Mondjuk úgy hogy egyik állam se költ lószart se digitális átállásra, ja lehet az open Source olcsóbb lesz, de ahogy szokásos megint nem...Szerk: Azt hiszem elolvastam életem legszebb német mondatát.
"Die Zukunft der Verwaltung ist cloudifiziert, automatisiert, algorithmisiert und datenbasiert. "[ Szerkesztve ]
-
vicze
félisten
-
vicze
félisten
válasz
#79484416
#33901
üzenetére
Valószínű nem fog változni.
Bár OPAL 2.0-os SSD-t azt csináltam Linux-on, de az egy elég egyszerű dolog. Bár csak tesztnek és használva sose lett végülNekifutottam már 1-2x a LUKS TPM dolognak 4-5éve, de valamilyen támogatás minding elcsúszott. Vagy GRUB oldalon vagy LUKS oldalon. Mostanában nem néztem lehet már egyszerűbb és működik.
-
vicze
félisten
válasz
#79484416
#33897
üzenetére
Elég kicsi esélyt adok rá, hogy bárki is használja itt.
Mire tudod használni? Kulcsokat tárolhatsz benne, pl SSH kulcsokat.
Használhatod SSD titkosításra ha OPAL 2.0-as, vagy simán LUKS-hoz. Lockolhatod vele egyéb titkosított tárolókat.
Használhatod véletlen szám generátornak, vagy csak kulcs generátornak. Jelentősen gyorsabb mintha CPU-ból csinálni. -
vicze
félisten
válasz
f_sanyee
#33834
üzenetére
ClearOS elsősorban "Windows Small Business Server" alternatíva szeretett volna lenni RHEL alapokon és a HP micro és kisebb szerverekhez ajánlották főként, vagy legalábbis ahhoz opció volt. Direktben nem a HP-é, de nagyrészt ők pénzelték, de van/volt, saját termékük ClearBox néven (leginkább router vagy storage-nak).
A felhő elvitte őket nagyrészt.Clear Linux OS az egy másik distro, ami Intelhez köthető, de még öregebb.
-
vicze
félisten
válasz
janos666
#33593
üzenetére
Teljesen lényegtelen, egy értelmes NAND-os ~100MB-t tudó USB-n se fog egy "live" rendszer gyorsabban menni, mert RAM-ban lesz alapból. Az hogy presistens rész kiírásához kikapcsoláskor 20mp-t vagy 50mp-t kell várni már édes mindegy valószínűleg.
Amiket irkáltok ezer éve megoldott problémák. -
vicze
félisten
válasz
5leteseN
#33582
üzenetére
Tessék, van egy raklap.
SSD-k óta nem érdekel senkit. Az USB boot distro-k, mind nagyrész RAM-ban futnak, egyszerűen csak csinálj egy persistens USB boot installt és pont ezt fogja csinálni, amit leírtál. Extrába csinálhatsz temp RAM driveokat. -
vicze
félisten
"Szeretnék fejlődni linuxos adatbiztonság terén."
Egész pontosan mi itt a cél?
Amit leírtál az hálózati biztonság elsősorban és nem Linux. Ha egy szegregálatlan hálózaton ül valaki, admin joggal akkor a továbbjutás elsősorban idő kérdése, de otthoni user eszközök 99%-ban botnetnek vannak használva és nagyon senkit nem fog időt és energiát fektetni abba, hogy bármi mást csináljon vele.IT biztonság eléggé átfogó kell legyen és folyamatos, nem pedig 1-1 esetleges lyuk tömködése. Az hogy van-e valamin pl. SSH, attól nem lesz kevésbé biztonságos, a kérdés inkább az, hogy az SSH biztonságosan van-e beállítva.
Ha azt akarod megtudni, hogy mi van esetlegesen rosszul beállítva a hálózatodon és az eszközökön, akkor Tenable Nessus Essentials ingyen van 16 IP-ig, szerintem pár óra alatt elsajátítható pár videóval a használata(kezdetnek). Vulnerability assessment-et lehet vele csinálni külső, belső és authentikált szempontból, futtatható CIS Bench vele, így elég átfogó képet ad az esetleges problémákról. Viszont az eredmények megfelelő értelmezése időt és tanulást igényel.
-
vicze
félisten
Az hogy mitt tud a rendszer inicializáló, kizárólag egy méretkorlát. Vannak UEFI-k teljes böngészővel és rengeteg funkcionalitással, meg vannak tök fapadok.
"Btw ARM esetén pl. microcode sincs, mert RISC."
Van mirokód, csak be van égetve a CPU-ba ezért van annyi javíthatatlan sérülékenység iPhoneokon, több Qualcomm SoC-on is és nem lehetett a különböző spekulatív támadásokat HW szinten javítani ARM-en, csak SW-ből. Ez igen jelentős security probléma ARM oldalon.
De FW ugyan úgy van rengeteg SoC komponenshez, így ott is frissülgetnek az FW-k elég nagy rendszerességgel."kernel úgyis felupgradeli early boot-ban ha régi."
A CPU mikrokódot lefrissíti runtimeban is gond nélkül.Viszont a Linux kernel maga nem fog semmilyen más FW-t frissíteni, mert olyan méretnövekedést jelentene, ami monolitikus felépítés miatt nem lehetséges. Kernel csak a Firmware API-t adja. Ami linuxon FW-t frissít az fwupd az LVFS közreműködésével. LVFS nélkül ugyan ott vagy, hogy le kell tölteni és kézzel frissíteni bármit. Amíg nem volt pár évvel ezelőttig az LVFS, valami iszonyat kínszenvedés volt a különböző FW-k frissítése Linux-on(főleg tömegben), ha egyáltalán lehetséges volt bármilyen formában.
A fent felsorolt sérülékenységek 99%-ka LVFS-en keresztül BIOS update formájában fog javítódni, mert nemes egyszerűséggel nem adják ki a gyártók más formában az FW-ket. -
-
vicze
félisten
válasz
bambano
#33443
üzenetére
Ezekhez a gyártók már tegnap elkezdték kiadni a BIOS frissítéseket jó pár hibára, de brutál bonyolult a mennyiség miatt, hogy mi érintett.
pl. Lenovo (Valaki nagyon jól szórakozott a táblázatokon az tuti...)Ezek a hibák: AMD-SB-4003, AMD-SB-7005, INSYDE-SA-2023018, INSYDE-SA-2023034, INSYDE-SA-2023036, INSYDE-SA-2023038, INSYDE-SA-2023039, INSYDE-SA-2023047, INSYDE-SA-2023048, INTEL-SA-00813, INTEL-SA-00828, INTEL-SA-00836, INTEL-SA-00837, INTEL-SA-00783
Nem néztem végig mind(rohadt sok), de kernerlből szinte egyikre se lesz workaround. pl. az InsydeH2O-nél az egész BIOS-t frissíteni kell nyilván.
-
-
vicze
félisten
Egy kis tisztázás, hülyeséget írtam "fenti bit fix kerül bele"-al, elég zavaros, hogy ez megy jelenleg. Nincs benne semmi ilyesmi.
Szóval ha jött bárkinek mikrokód frissítés, az egy általános bundle és csak a Roma-hoz van benne valós javítás. Tehát az egyetlen javított mikrokód a 0x0830107A, minden más ami, a "3.20191218"-ban van az nem a Zenbleed-re vonatkozik. pl. Family=0x17 Model=0x08 és Model=0x01 Zen és Zen+ modellek, amik nem érintettek a hibában.Szóval amíg nincsenek kernel frissítések backportokkal (nem dev-en vagy RC3-mal), a korábban írt/linkelt workaround elvileg megoldja, amíg nem jön bármi más.
-
vicze
félisten
válasz
sh4d0w
#33420
üzenetére
Microcode még csak is kizárólag Rome-hoz van, (az lenne ez), a többihez még nincs. A linkek nem tudom mit szeretnének mutatni(egyik egy példa egy 4éves mikrokód frissítésre, a másik leírja, hogy csak Rome-ához van), az AMD hivatalos target ideje október-december.
Tehát még egyszer Rome-ot kivéve semmire nincs ebben a pillanatban javítás mikrokód szinten, Linux 6.5 RC3-ba a bit állítás és a Roma mikrocode kivétel került bele, de ezen a verzión elég kevesen vannak...Aki telepíteni akarja a workoround-ot akkor ennyit kell csinálni:
apt install msr-tools (ki milyen csomagkezelőt használ)
modprobe msr
wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))A bit egy nem dokumentált kapcsoló, és AMD-n kívül senki se tudja, hogy mit csinál...
Remélem hamarosan elárulják, mert így elég érdekes CPU beállítást módosítani...Az SW oldali fix-ek nagy eséllyel (főleg böngésző) előbb lesznek mint mikrokód, AGESA, vagy bármi más.
Szerk:
Engem is ott cseszeget tegnap óta:
amd64-microcode/focal-updates,focal-security 3.20191218.1ubuntu1.1 amd64 [upgradable from: 3.20191218.1ubuntu1]
Ettől nem lesz a hiba kijavítva, nem lesz javított mikrokód, csak a fenti bit fix kerül bele, amit nem tudja senki, hogy mit csinál... Állítólag javítja, reméljük igen, és nem okoz más problémát.[ Szerkesztve ]
-
vicze
félisten
válasz
sh4d0w
#33418
üzenetére
Jelenleg egy a 6.5 rc3-ba került egy előzetes bejegyzés és ellenőrzésre az új mikrokódhoz(ez elég tiszta elolvasva a commitot), mivel AMD még nem készült egy a javítással, így nincs javítva. Pláne nem jött frissítés.
[ Szerkesztve ]
-
vicze
félisten
válasz
bambano
#33392
üzenetére
Te is leírtad és már többen is, hogy kiadja annak aki használja, és olyanok akik értenek a GPL-hez és a joghoz is (ilyen valószínűleg akad a Red Hat-nél is, úgy tippre), hogy nem sértenek semmilyen licencet főleg nem GPL-t.
"redhat kivett a nagy közösből"
Továbbra is a "nagy közösbe" elég nagy mennyiséget rakott és rak bele. Továbbra is olyan dolgokról beszélünk, aminek csak legacy szempontból van értelme és a valós fejlesztéshez nincs. -
vicze
félisten
Nagyon úgy néz ki, hogy te nem érted miről van szó.
Azt várod el, hogy RH neked minden kompenzáció nélkül backportoljon kernelbe és alkalmazásokba. Itt 0 azaz 0 fejlesztésük kerül bele bármibe, mivel nem LTS Linux kerenelt használnak, és nem LTS-ek az adott SW-k. Tehát minden amit csinálnak kizárólagosan az ő környezetükben (és deriváltjaiban) használható és nem lesz valósan hozzáadott értéke semmi máshoz.
RH fejlesztése és a FOSS-ba és a közösségbe visszaadott értek továbbra is ott van Cent OS-ben és Fedorában. Kevés nagyobb baromságot lehetne állítani, mint hogy RH nem ad vissza mikor ők az egyik legtöbbet hozzáadó fejlesztői a kernelnek, egyéb projektekről nem is beszélve.Te kizárólagosan ingyen ebédet vársz, azt hogy valami támogatott legyen 10évig anélkül, hogy neked bármit is tenned kéne. Az Open Source mocskosul nem így működik, és pontosan ezért van szükség az Enterprise distro-kra, mert semmilyen cég nem tudna lépést tartani a Open Source tempójával.
#33386 f_sanyee: Az dev licence tesztelni nem prod-ban használni, nagyon nem ugyanaz. Ennyi erővel Windows is ingyen van...
[ Szerkesztve ]
-
vicze
félisten
-
-
vicze
félisten
Tehát akkor az egy óriási korlátozás számodra, hogy egy ingyenes dev accountot kell regisztrálnod, hogy hozzáférj a kódhoz?
Ebben a jelnelegi lépésben semmi egetremgtően szörnyű nincs, csak aki nem ért hozzá kavarja a ... és állít hülyeséget.Már elég sok IBM lépés volt a felvásárlás óta, ami nemtetszést váltott ki és egyre nagyobb RH ellenességet gerjeszt. Akár okkal akár ok nélküli.
[ Szerkesztve ]
-
vicze
félisten
válasz
sztivo
#33231
üzenetére
Csak tipp, nincs saját tapasztalat.
Pop! OS nvidia verzió? Általában elég jó főleg a nV kártyákkal, és alapból működik minden bármi mókolás nélkül. Illetve van 165Hz-s nV-s laptopjuk, így gondolom mennie kéne. Szóval szerintem egy Live-val is kipróbálhatod.Azt nem tudom, hogy tudod-e, de csak natív portokban megy G-Sync, és semmilyen Wine/Proton-on keresztül futtatottal nem fog működni az emuláció miatt.
[ Szerkesztve ]
-
#33210
vicze
félisten
Neil Watts
#33209
vicze
félisten
válasz
Neil Watts
#33209
üzenetére
Ubuntu Pro-val most már ESM-t is kapsz igen sok csomagra. (5 gépig ingyenes, kinyul Canonicalhoz.)
Védelemhez, meg nézd végig a CIS benchmarkot, elsőkörben.
#33208 sh4d0w: ClamAV nyilván megoldható residensnek, ettől még nem ajánlanám AV-nak, hanem valami értelmesebbet, de az nyilván fizetős.
-
-
vicze
félisten
válasz
#68216320
#33169
üzenetére
Válasz olyan szolgáltatót aki támogatja alapból, különben alapból leheltelen, mivel a kulcsot be kell, írd és az rendszer előtt van, tehát low level interaktív web console kell, ami nem mindenhol adott.
Linod-on használtam és jól működik, illetve ott kb. bármit meg lehet csinálni.
Másik lehetőség ha a szolgáltató támogat low level interaktív konzolt, és enged image-et akkor egyszerűen feltölthetsz egyet. Amazonnál ha jól tudom adott ez is rescue móddal, de ott még nem csináltam. -
vicze
félisten
válasz
#68216320
#33097
üzenetére
Csak biztonságos titkosítást engedélyezz. (Chipher suite)
Nyilván a privát kulcs legyen jelszavas.
Az MFA-t mondták, erre vannak jó OTP pluginek.Jelszavas privát kulcs + MFA és egy támadó bejutási esélye elég alacsony, konvergál 0-hoz.
Nézz egy CIS Benchmark-ot az adott distro-ra ott még lesz pár javasolt beállítás SSH-hoz, de nagyrészt PAM-re lesz, illetve PAM hardening.Nagyon HC akarsz lenne akkor újraforgatod OpenSSH-t, hogy kikapcsold a service bannerét, amit sajnos nem lehet anélkül. (bár ez okozhat problémát elvileg, ha jól emlékszek)
-
-
vicze
félisten
Én úgy fogalmaznék, hogy hashcat+OpenCL pain in the but, megnyugtatlak Windowson is kész szenvedés.
Ha Hashcat lenne a célprogram és Linux desktop az a tolerancia szintedtől függöen két szék közé esete. CUDA lényegesen gyorsabb mint OpenCL csak le kell nyerni a zárt drivert és néhány hülyeségét, mindenképp Nvidia ha Hashcat a SW.Szerk: Hashcatnél nagyon fontos hogy mertartsd a régi verziókat is mert tudnak érdekes változtatásokat csináni, amitől egy adott driver verzióval nem működik.
[ Szerkesztve ]
-
-
vicze
félisten
válasz
inf3rno
#32619
üzenetére
Ne nekem írd.
"driver támogatásuk is nagyon jó"
Hát ööö ebben azért nem adnák igazat, a AMD oldali támogatás elég foghíjas sokéves termékekre is. RAID, HBA, NIC-nél is nagyon oda kell figyelni mit vesz az ember, és minding csekkolni az adott verzió HW comp listáját. Ez tök érthető a közösség mérete miatt ahogy írtad, de tényleg minding meg kell nézni.
Pár éve sikerült pont elnézzek egy számot egy NetXtreme II-nél, hát jó pár óra volt mire rájöttem, hogy el***sztam. -
vicze
félisten
válasz
bambano
#32607
üzenetére
"láthatóan nem ragaszkodik,"
Te magad váltottál testing kernelre nem ez az alap beállítás. És még egyszer így már nem lesz stabil rendszered és több inkompatibilitás is eredményez az alap repoval.Thunderbird azért lett kényszerből frissítve mert az utóbbi hónapokban nagyon sok high és kritikus sebezhetőséget találtak benne.
De még egyszer, nem hitvitát szeretnék, mindenki úgy és azt használ ahogy szeretne, a leírtak az én személyes véleményem, és teljesen elfogadom, hogy valaki másképp vélekedik erről.
"ahol a mikrotik is versenyez, a pc egyértelműen mindig gyorsabb routernek"
Akár igaz is lehet ez az állítás, csak a ár többszörös lesz egy cél HW-hoz képest, nem említve a fogyasztást és egyéb apróságokat. Egy Intel QAT kártya 30W-ből oldja meg az amit egy Epyc 200-ból...
Cél HW vs. általános compute:
[ Szerkesztve ]
-
vicze
félisten
Nagyon fárasztó bocs...
"A pfSense nem használhat DPDK-t, mert az Linux only szoftver."
LOL, legalább egy Goole keresést megejthetnél. Ahogy ezzel úgy a többivel is elég nagy tévedésben élsz. A Linux onlyság konkrétan ott szerepel a DPDK tévhitek listájában...
Aha... A kernel a full nevet használja helyesen, te meg rosszul rövidíted még minding...
x86 a 32bit-et jelöli, amit már szinte senki se használ. -
vicze
félisten
válasz
bambano
#32602
üzenetére
Írták, hogy az nem a Debian stable, az 5.10 és marad jó ideig
A 6.0-kal egy csomó kompatibilitási problémát behozol, ha csak nem testingen vagy.Igen BSD-t tök poénból használják tűzfalnak, hogy minél lassabb legyen. Egy router OS-en nem éppen a stock kernel rohangál.
"pc-kből épített routerekben a linux és az x86 végzi a routingot."
Nem azt írtam, hogy nem végezheti, hanem az, hogy rohadt lassú lesz egy HW gyorsítotthoz képest. Amit konkrétan az előbb meg is erősítettél. -
vicze
félisten
Értem, hogy elolvastad a DPDK marketinganyagot nagyszerű. Értem a flexibilitását és a használhatóságát, de egy HW gyorsított rendszer elég nyilván valóan 10x-100x sebesség növekedés, ezt nem értem miért nem lehet megérteni.
Dedikált HW minding gyorsabb lesz és a DPDK is használ gyorsítókat, akár GPU-t is.
pfSense is DPDK használ 7éve, semmi extrát nem nyújt, csak state of the art teljesítményt ennyi.Mutatnál egy darab switchet/routert, ami Linux HW gyorsítás nélkül?
x86_64 ha nagyon akarod, de semmiképp se x86, mert az már nem létezik vagy 10éve(mióta nincs 32bites Atom), általánosan x64-nek van rövidítve.
-
vicze
félisten
"A Linux+DPDK az ami képes ilyen 100 gigágat is routolni/szűrni, sima x86-on."
Még minding nagyon nem. Nem a Linux végzi és nem az x64 végzi a routingot semmilyen formában olvass már utána kérlek.
Amúgy Intel oldaláról vannak külön networking Xeon SKU-k, amikbe integrálva van a QuickAssist gyorsító, esetleg az megállja a helyét önmagában.BSD szintekkel gyorsabb routing és fűzfalban, nem véletlen lett az használva tűzfalakban nagyon sokáig bare metal telepítésekben, amíg nem volt a CPU-kben olyan sok dedikált gyorsító. Még egyszer a lényeg a HW gyorsításon van nem azon, hogy milyen kernelt használsz, gyakorlatban nincs jelezősége ha HW gyorsított a hálózatkezelés.
Amúgy Netgate-től a nagyvállalati TSNR már egy tök sima Ubi alap, de tök lényegtelen mert az egész stack le van cserélve sajátra. -
vicze
félisten
válasz
sh4d0w
#32564
üzenetére
Mindenki nyilván azt és úgy használja ahogy akarja semmi közöm hozzá.
De személy szerint úgy érzem, hogy Debian igen nagy mértékben hozzájárul ahhoz, hogy Linux ne fejlődjön olyan mértékben ahogy kéne és nagyon sok új technológia nagyon-nagyon lassan adoptálódik a Debian extrém konzervatív hozzáállása miatt. És nem azt mondom, hogy egy Arch legyen YOLO módjára, de van ésszerű középút.
Már a legtöbb LTS distro is belátta, hogy értelmetlen visszatartani a kernelt, mert ahhoz vezet hogy újabb HW-n használatlan lesz. Még a legfrissebb Linux kernel is sok esetben lemaradásokkal küzd, az utóbbi 4-5évben.Amúgy akkor szerinted DDoS egy fűzfal esetében nem security probléma?
-
vicze
félisten
Linkeljem végig a Cisco, Dell, stb. saját chipjeit?
x64 csak az OS-t futtatja, esetleg nagyon kicsi részfeladatokat végez, de minden amit csak lehet offloadolva van dedikált HW-ra.
De egy pont felett már hálókártyára is kellhet FPGA."ASIC-el nem szűrsz forgalmat
"
Aha...Elég sok éve pfSense-ezek és ha nincs Intel server kártya rendes HW offloaddal( vagy egyéb HW offload) a gépben, alap dolgokkal szenved. 20-30 user után használatlan.
-
vicze
félisten
válasz
sh4d0w
#32560
üzenetére
Azért Debian nem éppen egy "cutting edge" distro, kb. az egyik legkonzervatívabb és legvisszamaradottabb. Nyilván megvan ennek is az előnye, de a jelenlegi frissítési tempó nagyon nem ez. (A májusi RHEL 9 újabb kernel verzión van, mint az augusztusi Bullseye.)
Sajnos van egy olyan következménye, hogy mivel sok minden épül Debianra, így minden mást is visszatart.
[ Szerkesztve ]
-
#32519
vicze
félisten
fatpingvin
#32517
vicze
félisten
válasz
fatpingvin
#32517
üzenetére
Nem feltétlenül, az ACL egy elég általános IT fogalom, amióta multi user rendszerek vannak, azóta így hívják. User nyilván fájlrendszereken találkozik vele leginkább, de más IT rendszerekben is jelen van.
-
#32516
vicze
félisten
fatpingvin
#32515
vicze
félisten
válasz
fatpingvin
#32515
üzenetére
Semmi köze Win-hez, ACL Linuxon is elég alap dolog és bármilyen biztonságos rendszerben kötelezően kell legyen.
-
#32514
vicze
félisten
fatpingvin
#32513
vicze
félisten
válasz
fatpingvin
#32513
üzenetére
Access Control List, jogosultságkezelés a fájlrendszeren ebben az esetben.
Sima FAT-on nincs ACL, de NFTS, EXT4 stb. van.exFAT esetében Windows-on van, Linuxon nincs vagy legalábbis drivertől fog függeni az implementáció. 5.13-tól van a natív nyitott licence támogatás alapján, szóval nem tudom az évek alatt változott-e valami, pl. Androidon is van ACL rajta, szóval passz, hogy lett implementálva.
[ Szerkesztve ]
-
vicze
félisten
válasz
bambano
#32491
üzenetére
Ahogy Torvalds is mondata csak 1 a sok közül, lényegében az 5.20-at átnevezték, mert túl magas lett a szám a végén.
5.18-cal sokkal több újdonság és javítás jött mint a 6.0-lal.6.1 lehet hoz Rust drivereket, ha túléli a tiltakozás hullámot...
#32495 Archttila: Kösz ezt kipróbáljuk.
[ Szerkesztve ]
-
#32489
vicze
félisten
Speeedfire
#32488
vicze
félisten
válasz
Speeedfire
#32488
üzenetére
Akkor bármilyen Chromecast receiver app megteszi.
-
#32487
vicze
félisten
Speeedfire
#32486
vicze
félisten
válasz
Speeedfire
#32486
üzenetére
Mármint egy Linuxon futó "Youtube-ot" akarsz távolról vezérelni és engedni, hogy mások irányítsák? -> Bármilyen app ami Chromecast receiverként működik.
-
-
vicze
félisten
válasz
_kovi_
#32380
üzenetére
Biztos hogy routert akarsz setupolni, és nem csak egy proxy-t?
"egy forward gép"
Ez max. proxy-ra igaz, egy routerre nem.Bár mind a két esetben csak akkor kell két hálókártya, ha két külön fizikailag szegreált hálózatról beszélünk. Logikai VLAN-ok esetében se kell két hálókártya.
Nekem nagyon úgy tűnik hogy előbbiről van szó, különben nem kellene az egész. Ha meg szegreált hálózatok, biztos, hogy össze lehet kötni őket? Általában okkal van a szegregáció. -
vicze
félisten
válasz
bambano
#32378
üzenetére
Az egy csöppet bonyolultabb, MS SQL egy máshogy működik, 1port van és a szerveren futó Agent szolgálja ki a kéréseket és named pipe-hoz csatlakozol. 1 instance setében nem kell Agent, mert akkor csak 1 porton kommunikál.
#32373 _kovi_:
"Az lenne a feladat, hogy egy gépről ezen a CentOS7-en keresztül két különböző Windows SQL serverhez csatlakozzak.
Azért kellett a két hálókártya a CentOS7-ben, ha a forrás gépről a centOS-nek az egyik hálókártyájára csatlakozunk SQL management studióból"
Ennek a lírásnak így konkrétan semmi értelme. Hol fut akkor az SQL Server? Honnan hova csatlakozol.1. Ha Win-en futnak az MS SQL-ek és SSMS-el csatlakozol Linux-ról, akkor nem értem mi a probléma, lényegtelenek a hálókártyák, max akkor kell, ha két szegreált hálózatról van szó.
2. Ha Linux-on fut az MS SQL Server és SSMS-el Windows-ról csatlakozol, akkor is értelmetlen mert multi instance MS SQL-ben tök máshogy működik.Szóval nem ártana egy kicsit pontosítani, hogy mit is szeretnél, honnan hova.
-
vicze
félisten
Sapphire Rapids-ben nem lesz E-core és túl sok értelme nincs is szerverben, mert kizárólag azért van rá szükség, hogy Intel minél több magot tudjon odaírni, és beleférjen a 65W-be a 15W osztályos CPU, meg fele TDP-ket hazudhassanak.
5.18-cal jött be az Intel Thread Director, hogy támogatva legyenek az E magok, de egy AMD hatékonyabb lesz egy E maghoz képest is.... Fizika az fizika...
Egyszóval használni használni fogja a Linux, de semmivel nem lesz takarékosabb, nem arra van az E mag.[ Szerkesztve ]
-
#32348
vicze
félisten
lionhearted
#32347
vicze
félisten
válasz
lionhearted
#32347
üzenetére
Akárhogy is olvasom, de ez pont az.
-
vicze
félisten
válasz
bambano
#32343
üzenetére
- Nincs AP mode support már elég rég.
- Dragon csak Windows gaming driver a Reltek chipsetekhez, szóval az adott chip supportját nézd meg az adott Linux kernelben, a Dragon márkajelzés lényegtelen. (Csak prioritást csinál játékoknak alacsonyabb késleltetésért.)
- Intel I225-V volt csak hibás mást nem érintett, és az is javítva lett. Nem feltétlen lesz jó egyből lehet, hogy frissíteni kell. -
vicze
félisten
Leírtál egy non issue-t, ahogy vargalex írta. Még egyszer teljesen mezei OpenSSH van Windowsban pontosan ugyanaz mint Linuxban semmi különbség nincs. Továbbra is megváltás volt Puttyhoz képest.
A Putty egy mára borzasztóan elavult és korlátozott terminál emulátor, sokszor bosszantó korlátozottsággal.[ Szerkesztve ]
-
vicze
félisten
Sima OpenSSH van Windowsban, kliens szerver és agent-tel, mint bármelyik linuxon, nagyon akarsz be sshzhatsz rá gond nélkül. Konfig és minden más 100% ugyan az. Nem használtam Putty-t 2éve, felesleges.
Mellesleg van konverter, ami a Putty regkeyeket átrakja sima ssh configba, sokkal egyszerűbb, használatod simán WLS-ben is.Esetleg nem ártana az auth logot megnézni szerver oldalon, hogy pontosan mi a hiba.
-
vicze
félisten
válasz
Siriusb
#32135
üzenetére
Amennyiben van infrastruktúrád(kulcs manageelés) a OPAL 2.0-t kezelni, gyorsabb mivel natív. Annak függvényében milyen SW titkosítás van a LUKS-on X CPU időt elvesz, még egyszer ez nagyon függ a tokosítástól, mert ha olyat választasz ami HW gyorsított mint pl. AES akkor nem feltétlen érezhető. LUKS alap titkosítás jelenleg aes-xts-plain64 512-es kulccsal, szóval erősebb mint a self encrypting.
SED-del kapcsolatban annyit megjegyeznék, hogy pl BitLocker már nem támogatja, és még támogatott Windows verziókon MS nem ajánlja.
LUKS lehet sokkal biztosságosabb attól függően, hogy van implementálva, pl. sleep-nél visszazár az adott tároló, persze akkor nem minden titkosított ami egyéb problémákat vet fel, meg a teljes rendszer titkosításhoz Grubot is titkosítod, ami külön probléma, vagy Grub nélkül csinálod, stb stb stb...
-
vicze
félisten
Legyen akkor nincs "upgrade" csak folyamatosan frissül szünet nélkül.
Mellesleg továbbra is ahogy írtam ez Deksptop OS-eken leheleten, mert különben új HW nem lenne támogatva és már így is probléma hogy a Linux nagyon lassan adoptál új HW-t. Az Ubuntu LTS valahol egy járható középút szerintem, ezért is HWE (Hardware Enablement) kernel frissítések vannak 6 havonta.4.4 még 2 hétig támogatott pontosan. 6 év minden LTS-nek jelölt kernel, minding 6 éves lesz a legöregebb.
-
vicze
félisten
válasz
bambano
#31887
üzenetére
Igen az is frissítés mivel az adott LTS kernelbe is backportolják az új dolgokat, csak megmarad a biztos kompatibilitása és ki nem vesznek semmit, ritkán de frissítve vannak rendszeresen, minden bugfix security fix, driverek mind backportolva vannak.
De egy 6évig támogatott kernel muszáj frissíteni más csak az új HW-k támogatása miatt is, de ott vannak a biztonsági problémák is. Főleg a jelenlegi Kernel frissítési tempó mellett lehelten lenne bármilyen régi verzión maradni backport nélkül. Egy nevében 5.10-es kernel viszonylag friss is lehet.@ivana: Lást amit írtam.
"ubuntu LTS egyik legnagyobb hibája a kernel upgradelgetése szvsz"
Ha nem ezt csinálnák konkrétan nem használnák desktopon attól a pillanattól, mivel 5éves HW-kon futna csak kb. Mondjuk csak 20.04-gyel változott most sűrűbbre(főverziókhoz illesztés), de a kernel fejlesztési tempója jelenleg olyan, hogy meg is értem."fedora, meg a centos"
Gyakorlatban mind a kettő rolling(CentOS teljesen, Fedoránál 6 hónapod van, de lehet már rosszabb ott is), csak némileg késeltetve, pont az a feladatuk, hogy teszteljék az RH-hoz a stabilitást. RH pont úgy frissül mint bármilyen más LTS kernel(azaz nem mert 10év+ a support), de ott még külön bakportcolnak elég sok mindent ha kell. Amúgy kínkeserves dolog néha a kernel patch RH-ban."openSUSE Leap"
Adott verzió support ideje 6 hónap és csá, ez elég messze van az LTS-től, csak a kernel ősrégi benne.SUSE EL deto RH.
Szóval nincs olyan, hogy a kernel nem frissül, max. olyan van hogy ritkábban frissül és nincs benne nagyobb újítás.
-
vicze
félisten
-
vicze
félisten
Mind a kettő általad linkelt inkább alap vizsgák, és kb. egyenrangúak(korábban csereszabatosak voltak), a kettő együtt biztos, hogy felesleges. CompTIA kicsit elismertebb, de az is a "meh" kategória.
Csak bólogatni tudok, amit f_sanyee mond.
Annyit hozzátennék, hogy az RH vizsgák gyakorlatiak és nem egy sima multiple choise mint amiket linkeltél. Pont emiatt sokkal elismertebbek. -
vicze
félisten
válasz
Sub-ZeRo
#31702
üzenetére
PopOS! elsősorban System76 gépekre van. Az egyik ok hogy nem támogatják az MS által aláírt bootloadert, az egyrészt proprietary így nem összeegyeztethető a teljesen nyílt filozófiával, több System76 gép is Coreboot-ot használ, így ott értelmetlen, az Nvidia driver amit használnak nem támogatja a Secure Boot-ot.
Szóval röviden PopOS egyáltalán nem támogatja "hivatalosan" a dualbootot amit gondolom csinálni akarsz.
Secure Boot ennek ellenére megoldható, a korábban linkelt Arch leírás alapján, de eléggé értened kell, hogy mit csinálsz. -
vicze
félisten
válasz
Sub-ZeRo
#31693
üzenetére
Mindegyik Ubuntu legalább 15-óta(lehet régebben, nem emlékszem) alapból secure bootos, Canonicalnak MS irja alá. A boot kernel kell aláírva legyen így mindegy melyik GUI verziót használod.
Gyakorlatilag bármelyik Linux lehet secure bootos, csak be kell rakni a kulcsait UEFI-be, jó pár éve nem probléma.
Esetleg kell pár beállitást csinálni UEFI-ben hogy setup modba rakd a kulcs tárolót.
Itt elég részletesen. -
vicze
félisten
válasz
yoogie
#31644
üzenetére
Amennyire látom Zabbix max. RegEx-es keresést tud, de nézd meg annyira nem ismerem. Szóval első körben GrayLog, ha az nem jön be akkor Elastic. (Ha Winlogbeat-et használsz kliensnek az átállás is egyszerű.) GrayLog kisebb erőforrás igényű, Elastic többet tud.
Amúgy elemzés nincs gyűjtés nélkül, szóval az alapból meglesz, max. nem tárolsz olyan nagy időintervallumot.
Azért figyelmeztetnék, hogy ha sok a gép(log forrás) kell ennek izom (főleg RAM) bőven. -
vicze
félisten
válasz
yoogie
#31642
üzenetére
Mind a kettő amit említettük ingyenes. Azonos a modelljük a Zabbix-hoz, termék ingyen van, de support fizetős. Elastic kicsit bonyolultabb ilyen szempontból, mert sok komponensből áll össze, viszont ők mindent adnak, Graylog esetében a log küldést valamivel meg kell old(Nxlog, Winlogbeat) legalábbis windowson, de ez mindenre igaz lesz, hogy kell valamilyen kliens ahogy Zabbix esetében is. Zabbix is képes a log gyűjtésre abban nem sokban különbözik. Tényleg az a kérdés, hogy mit szeretnél, milyen mély az elemzés rész amit ki akarsz hozni belőle.
-
vicze
félisten
válasz
Fecogame
#31640
üzenetére
Logstash csak gyűjteni fog és az elemzés részhez tovább kell küldeni valamibe, ami vagy Elasticsearch vagy Kibana. Elk stack jobb nyilván csak hamarabb fut bele az ember fizetős részekbe, mint Graylog esetében. (Graylog-ról váltottunk Elastic-ra.)
Nyilván pénztárca függvényében van sok kulcsrakészebb megoldás is. -
vicze
félisten
válasz
Fecogame
#31636
üzenetére
Semennyire, mármint 0 rizikó.
Van egy Primary GPT a partíció elején és egy másodlagos a partíció végén redundanciának.
Bármilyen particionáló tool autofixeli.Ha LVM nagyobbítsd meg a különben nem fogod látni az új méretet. (gondolom át lett méretezve a disk)
[ Szerkesztve ]
-
vicze
félisten
válasz
f_sanyee
#31590
üzenetére
BSD(többség viszonylag modern jól használható), Solaris (fú hát kínszenvedés volt, mint ha középkorba repültem volna vissza egy modern Linux után), és BSD deriváltként ott a MacOS, de már távozóban x86-ról. Szóval az első kettő marad, amivel találkozhatna bár Solarist kétlem.
Mondjuk ha valaki érte HP-UX és AIX-hoz akkor az jó pénz, azokhoz pont jó egy 94-es könyv.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Szerk: Ups, Solaris 10 támogatása x86-on már csak 2024-ig van onnan már csak Sparc, szóval egyedül a BSD marad x86-ra semmi más.
[ Szerkesztve ]
-
#31576
vicze
félisten
tonermagus
#31573
vicze
félisten
válasz
tonermagus
#31573
üzenetére
Nem engedélyezik, ez az egyik különbség az olcsó lakossági és a drága üzleti előfizetés között. A lakossági szerződés része hogy nem üzemeltethetsz szervert pl. T-nél:
"a Hálózati végpont szerinti címen kívüli helyen történő megosztása, szerverüzemeltetés nem megengedett"Egyik ok, hogy ne tudja bárki halálra spemmelni a netet kvázi random IP-ről otthonról.
De ahogy bambano írja, a szolgáltatóddal kell ezt leboxold.
[ Szerkesztve ]
-
vicze
félisten
válasz
tasiadam
#31512
üzenetére
Csak, hogy egy kicsit bővebb legyen. Szóval ez egy HW probléma.
Tiger-ig az Intel U-s procik DP 1.2-t használnak az USB-C/TB3-on kimenetnek és így 4K-t tudja, de két WQHD-t már nem.
Azzal orvosolni tudod, hogy az egyik kijelzőt HDMI-n kötöd rá és nem a dokkon keresztül, bármilyen hülye megoldás is. -
vicze
félisten
válasz
#68216320
#31463
üzenetére
Hát igen azt is szettnéd, hogy valaki meg is kapja a levelek és ne csak úgy az éterbe menjenek, akkor egy kicsit bonyolultabb. Jobb esetben megy spam-be rosszabban meg se kapja senki meg elég rövid idő alatt blokkolják az IP-t.
Kulcsszavak: MX, SPF, DKIM, DMARC
Még számít, domained kategorizálása / domain reputation, persze a fentiek függenek, hogy hova akarsz e-maileket küldeni.
Most a különböző mail fejlécek odabiggyesztésébe nem megyek bele.Amit hcl leírt az az egyszerűbb sokkal, bár ott is lehetnek buktatók, a Gmailed biztonsági szintjétől függően. Gamil amúgy napi 500-as napi limittel rendelkezik(sima nem üzleti) és asszem van /perc limit is.
[ Szerkesztve ]
-
vicze
félisten
válasz
kraftxld
#31458
üzenetére
Csak, hogy értsd. Linuxnak nagyjából mindegy mi fut alatta, hacsak az alkalmazásnak nem kell valami nagyon speciális a HW-ból(USB kulcs pl.).
Lényegében, ahogy bambano írta boot valamiről, át synceled a fájlrendszert a virtuálisba és gond nélkül kéne bootoljon, mint itt.
Pontosan ezt csinálják a backup alkalmazások csak jelen esetben manuálisan kell csináld.[ Szerkesztve ]
-
vicze
félisten
válasz
#68216320
#31322
üzenetére
"FakeRAID
This type of RAID is properly called BIOS or Onboard RAID, but is falsely advertised as hardware RAID. The array is managed by pseudo-RAID controllers where the RAID logic is implemented in an option rom or in the firmware itself with a EFI SataDriver (in case of UEFI), but are not full hardware RAID controllers with all RAID features implemented. Therefore, this type of RAID is sometimes called FakeRAID. dmraid from the official repositories, will be used to deal with these controllers. Here are some examples of FakeRAID controllers: Intel Rapid Storage, JMicron JMB36x RAID ROM, AMD RAID, ASMedia 106x, and NVIDIA MediaShield."
Bár OPAL 2.0-os SSD-t azt csináltam Linux-on, de az egy elég egyszerű dolog. Bár csak tesztnek és használva sose lett végül
Remélem hamarosan elárulják, mert így elég érdekes CPU beállítást módosítani...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Laptopnál nem árt...
Annyit hozzátennék, hogy az RH vizsgák gyakorlatiak és nem egy sima multiple choise mint amiket linkeltél. Pont emiatt sokkal elismertebbek.
Új hozzászólás Aktív témák
- LEGO klub
- One otthoni szolgáltatások (TV, internet, telefon)
- TCL LCD és LED TV-k
- Lakáshitel, lakásvásárlás
- Milyen cserélhető objektíves gépet?
- PlayStation 5
- Társasjáték topic
- Végre bemutatkozott a Google Pixel 4a
- Honor Magic6 Pro - kör közepén számok
- AMD Navi Radeon™ RX 7xxx sorozat
- További aktív témák...
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- World of Warcraft Mists of Pandaria Collector s edition
- Karácsonyi akció: ESET termékek hivatalos forgalmazója / NOD32 / Internet Security / stb.
- Játékkulcsok a legjobb áron: Steam
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest