Hirdetés
- Nagy "hülyétkapokazapróktól" topik
- "A homoszexualitás természetellenes" 😠
- Ingyen kellene, de tegnapra
- PLEX: multimédia az egész lakásban
- Asszociációs játék. :)
- DVB-T/T2/C+FM+DAB USB tuner stick
- Android másképp: Lineage OS és társai
- Fűzzük össze a szavakat :)
- Építkezünk 6. rész (2024)
- Szárítógép szösszenet (hogy Te ne járj pórul)
-
LOGOUT.hu
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
Külön elnézést a bele kotyogásért.
FDE nem fogja megölni az SSD-t, sőt szinte semmi más se, az SSD vezérlő 99,9%-kal előbb fog meghalni és ez az SSD halálozások fő oka. A NAND-ot kímélni értelmetlen a gyakorlatban, max. a fejekbe rakódott alaptalan félelem.
Az hogy milyen szinten titkosítasz csak attól függ, hogy mit és mi ellen akarsz védeni.
A legbiztosabb ha a boot is le van biztosítva mert oda nagyon könnyen helyezhető malware, ami után az FDE-nek vagy bármi másnak semmi értelme.
Ha biztosra akarsz menni FDE+Boot titkosítás, minden más csak részleges védelmet nyújt 1-1 specifikus támadás forma ellen. Ez csak az egyéni belátásod, hogy hol akarod meghúzni a vonalat.[ Szerkesztve ]
-
vicze
félisten
válasz Frawly #30547 üzenetére
"elmozgatnak azokból a tartalmakból is, amik korábban legalább elérhetőek voltak az adott régióban"
Nézz utána egy kicsit hogyan működik a audiovizuális tatalom jogrendszere. Netflix csak azt tudja örökre megtartani ami a sajátja, minden más egyszer lejár. És ez országonként más."lementett (értsd előre letöltött) videókat próbáltam ingázás közben nézni telón, és behányta rendszeresen az 1043-as hibát"
Letöltött videókra 7naponta meg kell újítani a licencet, ha már elkezdted nézni akkor 48óra után. Ez annyit tesz hogy rábök arra hogy renew és kész.
Egészen mellesleg egy tartalom csak akkor letölthető, ha a jogtulajdonos ezt engedélyezi, vagy oszt rá ilyen jellegű licencet."Amazon Prime-ra, de azt mondják az se jobb"
Mivel Amazon is pontosan ugyan azon jogszabályokhoz van kötve mint minden más streaming szolgáltató.
Amazon Prime előfizetésben nézhető tartalom kb. hetente naponta változik, és borzasztó dinamikus, kivéve nyilván saját tartalom."HBO-t utálom"
Megsúgom, hogy HBO sincs UK-ben. Sky a WB tartalmak jogtulajdonosa UK-ben, és NowTV a szolgáltatásuk. -
vicze
félisten
válasz Frawly #30549 üzenetére
Semmilyen formában nem kioktatásnak számtan, nem tudhatom, ki mivel van tisztában.
Abban teljesen igazad van, hogy Netflix sokkal transzparensebb lehetne a le és felkerülő tartalommal, ez egy abszolút valós probléma. A többi szolgáltató ezt jobban csinálja, bár ott sokkal rövidebb ideig vannak fenn a tartalmak. Upflix-et használom erre a problémára.
Lassan 6éve használom Netflixet napi szenten nem kevés letöltéssel, és 1x találkoztam szerver oldali hibával, az egyik legstabilabb szolgáltatás amit valaha használtam.
De ha ilyen problémáid vannak Netflix-szel, a Prime Video-val lényegesen több problémád lesz, kezdve a rengeteg fizetős tartalom arcodba tolásával.
Jelenleg a jogrendszerrel nem lehet túl sokat kezdeni. A vége az lesz, hogy minden tartalom gyártó saját szolgáltatással rendelkezik majd és mindre előfizethetsz, ez a "végjáték".
A Linux támogatottság sajnálatos (főleg hogy Android is csak egy Linux), de részben érthető a piac mérete miatt. Bár nekem is működik az említett plugin és megy 1080p. Passz.
[ Szerkesztve ]
-
vicze
félisten
válasz I02S3F #30776 üzenetére
Olyan kismillió megoldás létezik windowed(á lá RDP) vagy seamless (csak az appot látod).
Pl. Amazon WorkSpaces, Desktop as a service modellje, 9$/hó + a mérettől függő /óra használat PAYG-ba.
Nagyon sok szolgáltató kínálja ezt. Ha csak appot akarsz akkor a "seamless remote app" szavakra keress rá.[ Szerkesztve ]
-
vicze
félisten
válasz Dißnäëß #30886 üzenetére
Csak egy kérdés, miért nem csak USB-re rakod a kulcsot és jo napot? Miért kell szenvedni a teljes boot-tal? Nem vagy semmivel se előrébb ha a kernel külön van, cak egy csomó problémát okoz.
USB-n a kulcsfile-t viheted magaddal és a gép mehet tovább, a boot-ot kiveszed akkor meg nem éppen. -
vicze
félisten
válasz kovaax #30922 üzenetére
Sajnos LVFS (Linux Vendor Firmware Service)-nek jelenleg csak a Thinkpadek részei. Mivel Lenovo nem ad a te modelledhez még DOS-os BIOS update-et se kizárólag egy darab Win10-es UEFI Capsule Update van, így ez a rögösebb út marad. Mivel a modelled nincs felsorolva, így nem biztos, hogy működik, passz.
UEFI Capsule Update talán segít valamit a keresgélésben.
-
vicze
félisten
válasz kovaax #30933 üzenetére
Letöltöttem és futtattam, a 2. exe az egy UEFIc headerrel rendelkező file szóval biztos UEFI Capsule Update, csak az a kérdés, hogy a fenében lehet belőle fwupd által kezelt formátumot varázsolni.
De akkor próbáltad az innoextract-ot, ahogy a linken van és nem működött?
Sajnos ha mással van csomagolva akkor van probléma és valahogy ki kell vakarni az exe-ből a cap-et.[ Szerkesztve ]
-
vicze
félisten
Hát ezt egy kicsit túl bonyolítottam.
Szóval a BIOS telepítő végre kell egy /ext commandline-ban és kicsomagolja önmagát és egyből meg is kapod a BIOS.cap-et onnantól már egyenes az út. Wine alól is mennie kéne szerintem.[ Szerkesztve ]
-
vicze
félisten
válasz kovaax #30941 üzenetére
Itt valami félreértés van.
Amit Lenovo oldaláról letöltesz, az kicsomagolja magát és vagy nem csinál semmit, vagy elindítja a telepítőt, ahhoz nem kell semmi tool. Ez 1db TDK pack-errel csomagolt exe-t csomagol ki, C:/DRIVERS/Flash/xxxx mappába, ez cmd-ben /ext-el szintén kicsomagolja saját magát gond nélkül, a már standard BIOS flash fájlokra, amik között ott a .cap és onnantól mehetnek az itt leírtak fwupdate-tel.
Olvasd végig és gondold át mit kell változtatni a te rendszeredhez, mert EFI commandline-ba ragadni én biztos nem akarnék... -
vicze
félisten
válasz kovaax #30955 üzenetére
Fedorának is borzasztó rövid a támogatása és pont ugyanaz a baj vele mint a Streammel, hogy nem LTS. Tehát nem hogy csak vad, de pont ugyan ott vagy vele mint Streammel.
Oracle Linux az a szívom a fogam szint. (Oracle miatt nem az OS miatt.)
Debian se éppen egy LTS OS, így kb. marad Ubuntu LTS-nek szerveren, ami ööö szívom a fogam, csak más miatt.CentOS-nek amúgy nagyon magas a részesedése, Ubuntu után a legtöbbet használt free LTS OS. Szóval elég sok embernek okoz ez elég nagy fejtörést. Főleg úgy, hogy a 8-as alól kb. kihúzzák a szőnyeget hirtelen.
[ Szerkesztve ]
-
vicze
félisten
BSD-vel általánosan a legnagyobb probléma a HW support.
Ha supportolt HW-n vagy akkor többnyire ok.
AMD-n kiváló.@kovaax: Azért nem elég az 5 mert mire váltasz már csak 3 marad belőle. 1évet minimum várni kell hogy stabil legyen egy új verzió és meglegyen support. 2x futottunk ki már support időből, egy appliance setében, ami nem tőlem függ.
[ Szerkesztve ]
-
vicze
félisten
Fogalmak összefoglalva, csak, hogy egyszerűsítse a keresést.
MST = Multi-Stream Transport.
A linkelt eszköz egy MST splitter/hub. Pont ilyen van Daisy chain monitorokba építve és legtöbb dokkolókban/hubokban. (Félreértések elkerülése érdekében: az USB-A dokkolók virtuális SW csatlakozókat csinálnak és drivert igényelnek, USB-C esetében sajnos nem minding egyértelmű, hogy natív DP van-e, Thunderbolt minding natív.)Arra nem árt figyelni, hogy milyen MST felbontásokat és darabszámot támogat az adott port DP verziója.
-
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." -
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 #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 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 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 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.
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 ]
-
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 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 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 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 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 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
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
-
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
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 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
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
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
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
válasz lionhearted #32347 üzenetére
Akárhogy is olvasom, de ez pont az.
-
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 ]
Új hozzászólás Aktív témák
Hirdetés
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest