- Xiaomi 14T Pro - teljes a család?
- Befutott a megígért HRV-mérés a Withings órájára
- Egy szenzor, két zoomkamera: újraírta a Huawei a mobilfotózás történetét
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Elkészült és telepíthető az Android 16
- Apple Watch Sport - ez is csak egy okosóra
- iPhone topik
- MIUI / HyperOS topik
- One mobilszolgáltatások
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
-
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
-
#32599
bambano
titán
fatpingvin
#32586
bambano
titán
válasz
fatpingvin
#32586
üzenetére
az összes első generációs ccr-ük tilera volt. a ccr1009-től a ccr1072-ig mind. nekem egy 9 magos van itthon, érződik, hogy nem "outputtal" gurigáztak, amikor összerakták azt a cpu-t.
-
x64 nincs és sose volt. Mindenki csak x86 hívja szakmai körökben. A kiterjesztés neve x86-64.
Nem a Linux végzi és nem az x64 végzi a routingot semmilyen formában olvass már utána kérlek. De, ez a state of the art. Közvetlenül a network kártyából mennek ki a csomagok userspace-be, meg onnan vissza.
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ó. A BSD gyorsabb volt 15 éve, azóta sok minden történt.
[link] Itt vannak performance tesztek.
-
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. -
inf3rno
nagyúr
Már milyen szempontból vicc? Létezik pl. olyan kernel, ami bizonyítottan csak hardver hibától dől be, mert nincs benne logikai hiba és nincs 1MB az egész. [link] Ha ez a fő szempont, akkor ehhez képest minden más vicc.
Ha a használhatóság, támogatottság a fő szempont, akkor meg ez a kernel vicc. -
A Debian ad egy stabil alapot, amit úgy alakítasz, ahogy tetszik. Linux Mint, Ubuntu pont ezt teszik (más tészta, hogy szarul). Ha haladóbb kell, RHEL, SLES, vagy ezek vmilyen deriváltja.
Amúgy akkor szerinted DDoS egy fűzfal esetében nem security probléma?
Ezt a fasságot honnan sikerült leszűrni?
-
#32594
fatpingvin
addikt
vicze
#32592
fatpingvin
addikt
kíváncsian várom a példákat. az ésszerű középút meglátásom szerint a Fedora és az OpenSUSE képében jelen van, érdekes módonm az előbbinek mintha lenne valami köze a RHEL-hez... ja hogy a Debiant szívesebben használják mert support nélkül is megy amire elindítod, az uborkát meg inkább hagyjuk is, az mindennek a megtestesülése amit irtani kéne a desktop Linuxból.
-
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.
-
válasz
inf3rno
#32572
üzenetére
Információbiztonságban általában úgy megy, hogy megveszik a hardvert, ami tud annyi sávszélességet, aztán kalap. Kicsiben, ha több ezer node-ot kell deployolni akkor már elkezdenek inkább konfigurálni
Otthonra egyet értek amúgy a BSD alapú megoldásokban. 
(#32579) bambano Tudtommal mindenki DPDK-t használ ([link]) magas szintű szűrésre. Ehhez kell egy Linux kernel, meg valami jó brutál vas. Az ilyen arm, meg mips 1 gigára jó ha elég.
(#32583) vicze1 Ma már olyan brutál erősek az x86 procik, hogy nem igazán kell FPGA. Akár virtuális gépen elmegy ilyesmi, csak kell neki adni megfelelő hálózati kártyát. De régen is FPGA volt, ASIC-el nem szűrsz forgalmat
-
sonar
addikt
válasz
bambano
#32584
üzenetére
Ebben csak az a vicces, hogy a mai komolyabb 10G, 40G, 100G switchekben már intel proci dübörög
Néztem is nagyot mikor egy 10G-s mellanoxot pár éve szétkaptunk és sima kommersz intel proci volt benne.De a poén, hogy autóiparban is egyre több az intel Atom-ra épült SOC.
-
#32587
Lenry
félisten
fatpingvin
#32586
válasz
fatpingvin
#32586
üzenetére
-
bambano
titán
válasz
inf3rno
#32582
üzenetére
oké, amiben "purpose built" asic van, azt elfogadom hardveres tűzfalnak.
tudtommal a mikrotiknek nincs ilyenje. én mostanában ids/ips-t sem láttam tőlük. alapvetően wireles isp beszállítóként indultak és azóta lett switch meg router termékvonal is. kb. az a szint, mint a cisco linksyses termékcsaládja, vagy annál kicsit jobb. -
bambano
titán
"L7 matcher collects the first 10 packets of a connection or the first 2KB of a connection and searches for the pattern in the collected data. If the pattern is not found in the collected data, the matcher stops inspecting further."
emlékeim szerint azt a kernel is tudja, hogy stringeket keres a csomagban.
de oké, legyen igazad, létezik szűrési lehetőség.
főleg, ha a "szűrési lehetőség" kifejezést elég tágan értelmezzük. -
bambano
titán
válasz
sh4d0w
#32576
üzenetére
az l7 tűzfalak, szerintem, mind valamilyen applikáción keresztül szűrik a magasabb szintű forgalmat. Nagyon-nagyon alap szintű l7 szűrést lehet csinálni a kernellel is, de nem feltétlenül érdemes.
a mikrotikben szerintem nincs l7 szűrési lehetőség. azok egyébként viszonylag sztenderd arm magos, korábban mips magos cpu-kon futó nagyjából sztenderd linux kernelek.
-
bambano
titán
válasz
inf3rno
#32574
üzenetére
a pc-ben nehézsúlyú processzor van, ahhoz képest viszonylag rendes buszokkal. a "hardveres" tűzfalakban vagy valami gagyi intel proci van (asa500-ban celeron, 100 megás depca kártyákkal anno, rotfl), vagy a mikrotikben mips, újabban arm architektúrájú proci(mago)k, és viszonylag kevés darab.
teljesen biztos vagyok benne, hogy egy pc tovább bírja, mint pl. egy mikrotik. A mikrotik korábbi csúcsgépében 72 magos tilera proci volt, ezt is leveri egy 16c32t amd pc. A mostani elérhető árú (fél milleren innen) mikrotikekben 4 magos 2GHz-es arm alapú proci van, a csúcsgépben 16 magos arm.
Nem, ez soha nem éri utol a pc-t. Akkor lehet vele teljesítményt elérni, ha a routerben valamiért van rendes switch is, és a switch chip elég okos, akkor jöhet az a szint, hogy egy mikrotik elkezd összemérhető eredményt elérni egy pc-vel. A komolyabb szolgáltatók (pl. netflix) most ott tartanak pc-vel, hogy 400-800 Gbps között tudnak https forgalmat egy pc-ből.
én egyébként szeretem a mikrotiket, de két hónapnyi kísérletezés után most egy efficient mag csinálja a hálózati kapcsolatomat.
-
bambano
titán
válasz
Shyciii
#32565
üzenetére
el tudod magyarázni nekem, hogy hogyan fektetsz meg egy otthoni nast úgy, hogy nincs előtte tűzfal, de nat mögött van (mint manapság gyakorlatilag minden otthoni gép)?
egyébként megnyugodhatsz, egy normális pcnek mindegy, hogy ip- vagy nftables, mindkettőt elviszi szokásos otthoni internet kapcsolatot feltételezve. sőt, azt is ki merem jelenteni, hogy hálókártyától, drivertől is mindentől függetlenül az otthoni pc elé állított (például) huawei vagy tplink dobozka sokkal hamarabb adja fel, mint a mögötte levő pc.
nyugodj meg, arra, hogy átlag béla beírja az ő három darab tűzfal szabályát a kernelbe, teljesen megfelelő az iptables is, mint ahogy az eredeti állítás volt.
azt javaslom figyelembe venni, hogy itt senki nem diktál. még te sem.
-
inf3rno
nagyúr
Információbiztonságban általában úgy megy, hogy megveszik a hardvert, ami tud annyi sávszélességet, aztán kalap. Hogy azon belül hogyan van megoldva, azzal kevesen foglalkoznak. Hogy otthonra ki mit mókol össze magának, az megint más kérdés. Én pl. simán OPNsense vagy pfSense megoldást csinálnék, de a Linux sem annyira rossz.
-
válasz
sh4d0w
#32569
üzenetére
Szervert nem szoftveres tűzfallal védünk elsősorban, hanem hardveressel. Ha kell az otthoni szerver, tegyél elé rendes eszközt: Bitdefender, WatchGuard, Mikrotik, Netgear - és akkor nem probléma, hogy az iptables kicsit többet eszik a CPU-dból, mint az nftables
Hülyeség, egy mai Linux bőven megállja a helyét közvetlen az interneten. Lassan a core network routerek 100%-a Linuxot futtat. Plusz a dedikált firewall eszközök is általában Linuxal mennek.
Különösebb baj amúgy nincs az iptables-el. Ami szerintem nagy hibája az a teljesen külön IPv4 és IPv6 stack. De mivel amúgy mindkettő netfilter module akár egyszerre is használhatod a kettőt.
-
válasz
Shyciii
#32565
üzenetére
Oké, mivel szemmel láthatóan erőlteted, hogy magas lóról oszd az észt, hasonló stílusban válaszolok.
Szervert nem szoftveres tűzfallal védünk elsősorban, hanem hardveressel. Ha kell az otthoni szerver, tegyél elé rendes eszközt: Bitdefender, WatchGuard, Mikrotik, Netgear - és akkor nem probléma, hogy az iptables kicsit többet eszik a CPU-dból, mint az nftables.
Ez egy. Kettő: ha a te otthoni hálózatodat DOS/DDOS-olják, akkor nincs az a szoftveres tűzfal, amivel talpon maradsz - nftables-szel sem. Az xmas TCP floodot is illik felismernie egy korrekt hardveres eszköznek. Nem mellesleg az ISP-d is érdekelt abban, hogy megállítson egy ilyen támadást.
Egyáltalán maga a feltételezés hogy egy tűzfal, vagy bármilyen biztonsági eszköznél nem számít a performance...ez nagyon az úristen kategória.
Ad egy, olyan dolgokat tulajdonítasz nekem, amit nem mondtam. Ad kettő: otthoni környzetben lásd fentebb.
Bocs, de pont ezért nem válaszoltam értelmesen, mert ez a dőlt betűs részed borzalmasan leírja, hogy mi a véleményed a biztonságról, és a hozzá kapcsolódó technológiáról, és működéséről. Amivel nem is lenne baj, csak akkor nem feltétlenül neked kellene diktálnod ebben a kérdésben, főleg nem egy haladó topicban.
Maradjunk inkább annyiban, hogy azért nem válaszoltál értelmesen, mert fingod sincs erről, FUD-olsz. Azt meg végképp nem neked kell bizonyítanom, mi az én hozzáállásom a cyber security-hez. Vannak, akiknek a véleményére adok, de momentán te nem tartozol közéjük. Tanácsot kértek, adtam, de nem diktáltam senkinek sem - mindenki úgy védi meg magát, ahogy a szája ízének, vagy a rizikótűrő képességének megfelel.
Részemről itt ez befejezve, ha folytatni akarod, hozzál nekem egy friss CVE-t, 0day-t, vagy egy működő POC-ot arra, hogy az iptables nem biztonságos egy up-to-date Debian stable-ön.
-
f_sanyee
senior tag
válasz
sh4d0w
#32558
üzenetére
Red Hat, Fedora itt pl igy van.
RHEL8 óta van nftables btw.iptables vs nftables:
igazábol kár ezen vitázni, ha valaki megszokta és ragaszkodik a legacy toolokhoz, használjon iptables, nslookup, ifconfig, meg hasonló deprecated parancsokat amíg teheti, aki pedig inkább tanulna valami újat, annak ott az nftables... -
Shyciii
veterán
válasz
sh4d0w
#32564
üzenetére
Debian cutting edgelése (Testing verzióra gondoltál ugyebár) nem csak stabilitás vész oda, hanem a biztonsági frissítések azonnali megkapása is, ugyanis nem egy időben kapja meg a Stable verzióval. Bár ezt nem említetted, de biztos tudod, ha már 8 éve Debian-t használsz ugyebár, és ha már konkrétumokat vársz...
Értem, hogy az iptables nem skálázódik jól, esetleg lehetnek vele performance problémák (a mai hw környezetben ez tényleg számít?), de hogy jön ide a biztonság?
Jössz a performance-al, ami mai hw környezetben nem számít. Jaj...Először is, ha csak nem rendelkezel Google féle szerverparkkal, akkor te, vbagy az általad üzemeltetett gép, nas, home szerver pillanatok alatt megfexik DOS, vagy DDOS alatt, de ha xmas tcp-vel floodolnak akkor is. Egyáltalán maga a feltételezés hogy egy tűzfal, vagy bármilyen biztonsági eszköznél nem számít a performance...ez nagyon az úristen kategória. Csak úgy közlöm, hogy igencsak baromira számít a performance mind szoftveres oldalon, mind hardveres oldalon. Ugyanis az sem mindegy, hogy milyen hálókártyád van, és ahhoz milyen drivert használsz.
Az meg hogy "hogy jön ide a biztonság" kérdésed egy tűzfalas beszélgetésnél, meg végképp vicc. Bocs, de pont ezért nem válaszoltam értelmesen, mert ez a dőlt betűs részed borzalmasan leírja, hogy mi a véleményed a biztonságról, és a hozzá kapcsolódó technológiáról, és működéséről. Amivel nem is lenne baj, csak akkor nem feltétlenül neked kellene diktálnod ebben a kérdésben, főleg nem egy haladó topicban. -
Nofene, csak nem (8 éve Debian a fő rendszerem)?
Egyébként meg, Debian alapon is lehet cutting edge-en lenni, csak akkor pont odavész az a stabilitás, amit a kitesztelt csomagok adnak.@Shyciii: komolyan kérdeztem, milyen security issue-k jönnek, ha iptables-t használsz? Ha most sem válaszolsz értelmesen, akkor úgy veszem, hogy Te sem tudod, csak megemlítetted, hátha valaki összecsinálja magát. Nekem megfelel bármilyen publikusan olvasható link (a paywallos nem ilyen), ha nem akarsz túl sokat gépelni.
-
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.
-
Shyciii
veterán
válasz
sh4d0w
#32560
üzenetére
Akkor másképp írom. A BTRFS is már régóta van, mégis "csak" most kezd szélesebb rétegben elfogadottá válni, a pipewire is van egy ideje, de csak most kezdett bizonyos distrokon default lenni. Ugyanez van az nftables-el is. El kellett érnie egy olyan "szintet", hogy azt mondják rá, hogy oké, stabil, gyors, biztos fogják fejleszteni sokáig, lehet ez a default most már.
Értem, hogy az iptables nem skálázódik jól, esetleg lehetnek vele performance problémák (a mai hw környezetben ez tényleg számít?), de hogy jön ide a biztonság?
Nah, ha ez egy komoly kérdés volt részedről, akkor teljesen felesleges ezt megválaszolnom, és így már értem, hogy miért tök mindegy neked egy tűzfal esetén, hogy egy elavult technológiájú iptables, vagy friss nftables. -
válasz
Shyciii
#32559
üzenetére
Már akkor téma volt az nftables, amikor Debian 10-et raktam a 9-es után... Mi több, 2014 óta van kernel támogatása, mégsem mainstream.
Értem, hogy az iptables nem skálázódik jól, esetleg lehetnek vele performance problémák (a mai hw környezetben ez tényleg számít?), de hogy jön ide a biztonság? -
Shyciii
veterán
válasz
sh4d0w
#32556
üzenetére
Ha jobban megnézed, akkor azaz iptables, az valójában iptables-nft és külön van legacy. Értem én, hogy fel kell tenni az nftables csomagot, de valójában már a Bullseye-ban felkészítették a kivonásra az iptables-t. Jelen állapot szerint a következő verzióban végleg ki is kapják. Amúgy meg nem a Debian-t venném alapnak technológia kérdésekben, mert mindig le van maradva, főleg ha a stable verziót nézzük (nézd csak meg a btrfs filerendszert. Máshol már az a default, míg a Debian a közelében sincsen).
Szal egy többszörösen régi, és már "elavultnak" tekinthető tűzfalat én nem ajánlanék senkinek, már a munkámból kifolyólag sem, és biztonság miatt sem. Főleg hogy nem csak hogy többre képes az nftables, de még csak nem is rémesen bonyolultabb, mint az iptables. -
togvau
senior tag
Van egy headless házi szerverem, amin futtatnék egy gui alkalmazást, ssh-n belépve x11 forwarddal, amit szeretnék ha futásban maradna akkor is, ha bezárom a kliensgépen az ablakot, mintha mi se történt volna.
Valahogy úgy mint a tmux, amiben indított konzolos programok futásban maradnak detach után is, és későbbi attach-al az egész konzol tartalmát látom.
Ilyet hogy lehet? -
inf3rno
nagyúr
Érintős dolgokkal van valakinek tapasztalata? Mint 20.3 + XFCE, aminél az érintőképernyőt be akarom állítani. Az a kínom vele, hogy Windows-nál megszoktam, hogy egy érintésre ha húzom, akkor scrolloz, kettőre meg lehet drag-dropolni ugyanígy vagy keretet húzni. Ha hosszan nyomom, akkor meg kijön a menü a fájlra. Valami hasonlót szeretnék elérni XFCE alatt is, de csak azt tudja, hogy egy érintésre klikkel ezerrel meg keretet húz, ami nekem teljesen alkalmatlan munkára vagy bármire. A touch pad-et sikerült beállítani a menüből, ott is ugyanez volt a default (nem tudom kinek a hülye ötlete volt ez), de ott sem találtam ilyen Windows-hoz közeli megoldást, ami működött, hogy "kattintás érintésre bepipálva" és "jobb oldalt scrollozzon". Tulképp nekem ez a touch screenen is elmenne talán, ha nem akarok nagyon a szélén kijelölni dolgokat. Már ha nem lehet az eredeti működését visszaállítani. Furcsállom, hogy aki ért hozzá annak ezt nem egy bonyolult dolog leprogramozni, talán pár nap lehet onnantól, hogy érzékeli a cucc az érintést, húzást, ezek időtartamát, és valahogy mégsem támogatott menüből a beállítása a Windows-al azonos viselkedésnek. Valami olyasmire gondolok, hogyha menüből nem is, de talán valami libinput konfig fájl írással esetleg megoldható. Tudtok ilyet?
-
Penty
aktív tag
Üdv!
Adott egy mappa, benne sok almappa és bennük többféle kiterjesztésű fájl. Szeretnék a mappákban lévő *.ARW és *.MP4 fáljokról sha256sum-ot készíteni, mondjuk úgy, hogy ha a script talál egy mappában .ARW és/vagy .MP4 fájlokat, akkor oda készítsen egy sha256sum.txt nevű fájlt, benne az checksum infókkal.
Pár perc alatt addig jutottam el, hogy készít egy "központi" sha256sum.txt" nevű fájlt, és abba rak bele mindent, amit talál. Hogyan kellene módosítanom, kiegészítenem az alábbi kis rondaságot, hogy oda készítsen egy-egy ilyen fájlt, ahol megtalálja ezeket az ARW és MP4 fájlokat?find /home/penty/Photo/ -type f \( -name "*.ARW" -o -name "*.MP4" \) -exec sha256sum {} \; > sha256sum.txt -
#32541
lionhearted
őstag
erdeidominik
#32533
válasz
erdeidominik
#32533
üzenetére
Key interval csökkentése (-> nagyobb sávszélesség igény), kliens oldalon buffer csökkentése.
Egyébként velejáró dolog, ha nem csak I frameekben kapod, akkor össze kell őket várni, és utána lekódolni (megint csak 2 key frame közötti mennyiséget egyszerre), majd kitolni a nagyvilágba. Ha kliens oldalon van buffering, akkor ott is várni fog, hogy folyamatos legyen a lejátszás. (Jitter vs latency) -
CPT.Pirk
Jómunkásember
-
Krystal_s
addikt
válasz
f_sanyee
#32538
üzenetére
Igen, azt tudom, hogy képes rá.....
Nagyon sokszor futtattam Live Linuxokat pendrive-on, de magától egyik sem írt a gépben lévő meghajtókra (ssd,hdd), de én simán megtudtam nyitni onnan fájlokat és menteni is tudtam. Szóval képes volt bármire, csak azt nem magától tette, hanem az én beavatkozásommal. -
f_sanyee
senior tag
válasz
Krystal_s
#32535
üzenetére
ami csak pendrive-on van, alapból semmi jogosultsága, hogy bármilyen másik rendszerlemezre írjon.
na itt tévedsz, bármiről bootolhatsz, hozzá fog férni az összes diskhez, az más kérdés ha pl titkositott a filerendszer, akkor nem hoz létre rajta semmit, de nyugodtan le tudja törölni a particiót/disket, ha meg nem titkositott akkor bármit... itt nincs jogosultságkezelés. -
Krystal_s
addikt
válasz
CPT.Pirk
#32536
üzenetére
Igen, csak mobilon is az egy telepített rendszer a saját jogosultságaival. Ez meg egy Live rendszer, aminek csak azon a pendrive-on volt jogosultsága, amin én futtattam. (nem volt telepítve)
A Bliss OS-t (android) is ugyanígy futtattam, az sem hozott létre semmit.
Szerinted, akkor nem szükséges emiatt újratelepítenem a rendszert, elég csak törölni azokat a mappákat?
-
-
Krystal_s
addikt
Megpróbálok itt is tanácsot kérni, hátha valaki itt jobban képben van, mert az Androidos topikban megkaptam, hogy ez OFF és Windows téma. 😀 Na mondom....
Évek óta nagyon sokféle Linux LIVE rendszert próbáltam és sosem volt semmi gond.
Tegnap Android (Az Android Linux kernelt használó op.rendszer) LIVE rendszereket próbáltam csakis LIVE módban, ami csak pendrive-on van, alapból semmi jogosultsága, hogy bármilyen másik rendszerlemezre írjon.
Mivel Linux alap remélem nem olyan hatalmas gond, hogy itt kérdezni merek, az alap működés ua.
Van többféle Android, amiket PC-n is lehet használni. Az egyik ilyen a Prime OS volt, simán csak pendrive-on LIVE módban. Amikor kihúztam a pent és indítottam a saját rendszerem, ledöbbentem láttam, hogy a C: rendszer (Windows) és a D: Adat partíciómra is írt. Kb 10 mappát (Music, Documents, Pictures...) bennük fájlokkal (pl *.db nomedia és hasonlók, amiket láttam). Ez hogy lehetséges egy LIVE rendszernél?
Amit szem előtt volt azokat töröltem, de attól félek, hogy akár a Windows rendszerembe is beleírhatott valamit? Vagy csak ezeket a médiás mappákat hozta létre?
Köszönöm, ha valaki segítő módon válaszol! -
#32534
gregory91
senior tag
erdeidominik
#32533
gregory91
senior tag
válasz
erdeidominik
#32533
üzenetére
Vagy növelni a sávszélen(számolni kell azzal hogy stabil kapcsolatot követel a hálózat szempontjából) vagy a "lejátszandó félen" a bufferméretet letolni.
-
#32533
erdeidominik
csendes tag
erdeidominik
csendes tag
Sziasztok!
Ffmpeg-el szeretnék ip kamera streameket mozaik elrendezésben streamelni. Addig el is jutottam, hogy az rtsp h265-ös streameket bepakolom egy mozaikba és a kimenet pedig egy szintén rtsp stream lesz viszont ott már csak h264 kellene, ez működik is szépen, viszont sajnos nagyon nagy a késeltetés. Ami a bejövő streamen történik az a kimenőn 3-4mp múlva látszódik. Lehet ezen valahogy csökkenteni vagy a restream miatt ez egy vele járó dolog? -
CPT.Pirk
Jómunkásember
amdgpu 0000:08:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0011 address=0x2b17c0000 flags=0x0000][drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out![drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out![drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring comp_1.2.0 timeout, signaled seq=11613, emitted seq=11614[drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process GameThread pid 12775 thread GameThread pid 12824amdgpu 0000:08:00.0: amdgpu: GPU reset begin!amdgpu 0000:08:00.0: amdgpu: failed to suspend display audioamdgpu 0000:08:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring kiq_2.1.0 test failed (-110)[drm:gfx_v10_0_hw_fini [amdgpu]] *ERROR* KCQ disable failed[drm] free PSP TMR bufferCPU: 14 PID: 9847 Comm: kworker/u64:0 Not tainted 5.19.14-1-MANJARO #1 bb381310e9735642d17ffd4df21276ec37bc90d1Hardware name: ASUS System Product Name/TUF GAMING B550M-PLUS, BIOS 2803 04/27/2022Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched]Call Trace:<TASK>dump_stack_lvl+0x48/0x60amdgpu_do_asic_reset+0x2a/0x45d [amdgpu d7f739a1ec9af0997b0d6a34c65113fb23857f42]amdgpu_device_gpu_recover_imp.cold+0x492/0x8ea [amdgpu d7f739a1ec9af0997b0d6a34c65113fb23857f42]amdgpu_job_timedout+0x18f/0x1c0 [amdgpu d7f739a1ec9af0997b0d6a34c65113fb23857f42]drm_sched_job_timedout+0x7a/0x110 [gpu_sched 8e6237b7f67240ecaa97abe8a787d3c1d71c0d32]process_one_work+0x1c7/0x380worker_thread+0x51/0x390? rescuer_thread+0x3b0/0x3b0kthread+0xde/0x110? kthread_complete_and_exit+0x20/0x20ret_from_fork+0x22/0x30</TASK>amdgpu 0000:08:00.0: amdgpu: BACO resetamdgpu 0000:08:00.0: amdgpu: GPU reset succeeded, trying to resume[drm] PCIE GART of 512M enabled (table at 0x0000008000E10000).[drm] VRAM is lost due to GPU reset![drm] PSP is resuming...[drm] reserve 0x900000 from 0x817e600000 for PSP TMRamdgpu 0000:08:00.0: amdgpu: RAS: optional ras ta ucode is not availableamdgpu 0000:08:00.0: amdgpu: RAP: optional rap ta ucode is not availableamdgpu 0000:08:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not availableamdgpu 0000:08:00.0: amdgpu: SMU is resuming...amdgpu 0000:08:00.0: amdgpu: use vbios provided pptableamdgpu 0000:08:00.0: amdgpu: smc_dpm_info table revision(format.content): 4.5amdgpu 0000:08:00.0: amdgpu: SMU is resumed successfully![drm] kiq ring mec 2 pipe 1 q 0[drm] VCN decode and encode initialized successfully(under DPG Mode).[drm] JPEG decode initialized successfully.amdgpu 0000:08:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0aamdgpu 0000:08:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0amdgpu 0000:08:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0amdgpu 0000:08:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0amdgpu 0000:08:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0amdgpu 0000:08:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0amdgpu 0000:08:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0amdgpu 0000:08:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0amdgpu 0000:08:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0amdgpu 0000:08:00.0: amdgpu: ring kiq_2.1.0 uses VM inv eng 11 on hub 0amdgpu 0000:08:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0amdgpu 0000:08:00.0: amdgpu: ring sdma1 uses VM inv eng 13 on hub 0amdgpu 0000:08:00.0: amdgpu: ring vcn_dec uses VM inv eng 0 on hub 1amdgpu 0000:08:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 1 on hub 1amdgpu 0000:08:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 4 on hub 1amdgpu 0000:08:00.0: amdgpu: ring jpeg_dec uses VM inv eng 5 on hub 1amdgpu 0000:08:00.0: amdgpu: recover vram bo from shadow startamdgpu 0000:08:00.0: amdgpu: recover vram bo from shadow done[drm] Skip scheduling IBs![drm] Skip scheduling IBs!amdgpu 0000:08:00.0: amdgpu: GPU reset(1) succeeded![drm] Skip scheduling IBs![drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!Van nekem ez a problémám, mikor egyszer csak minden előjel nélkül meghal a GPU (leginkább játék alatt), megpróbálja resetelni magát de nem jut vele sokra és kénytelen vagyok újraindítani a gépet... Írtam már róla korábban, nem tudom kihez kellene fordulnom ezzel.
Azóta egy 2. gépen is reprodukáltam ezt a problémát (ez a dmesg kimenet is onnan van), ugyanolyan, de nem ugyanazzal a Sapphire Pulse 5600XT kártyával. Szóval a számítógép egyéb hardverelemeit szerintem ki lehet zárni a képből, ez valami szoftveres dolog, ami az 5600XT-t érinti.
Ebben a gépben egy két generációval öregebb RX570 vga hibátlanul működött éveken át. A furcsa az, hogy mindkettő vga-t ugyanaz az AMDGPU driver hajtja.*Manjaro KDE, 5.19-es kernel.
-
AcCEsS
senior tag
Huhhh, ez nekem semmit nem mond:
read(7, "\34\0\200\0\300\6\0\0\254\1\0\0\36op\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = 64
getpid() = 20186
poll([{fd=3, events=POLLIN}, {fd=3, events=POLLOUT}, {fd=4, events=POLLIN}, {fd=5, events=0}, {fd=6, events=0}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}], 8, -1) = 1 ([{fd=3, revents=POLLOUT}])
write(3, "S\353}a\227\303\211\246\355\334\271\305!_ \352:q\322\235\315D\243\233\356'j\230\226\210\333O"..., 100) = 100
poll([{fd=3, events=POLLIN}, {fd=3, events=0}, {fd=4, events=POLLIN}, {fd=5, events=0}, {fd=6, events=0}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}], 8, -1 -
AcCEsS
senior tag
Már korábban átváltottam x11-re, mert a forrás számítógépre nem működött a vnc, meg nem tudtam a "mailto:" linkeket használni a Thunderbirdre, mert ahelyett, hogy nyitott volna egy új, küldés ablakot, azt mondta, hogy thunderbird is already running. Sos-sok "infótúrás" után derült ki, hogy a Wayland az oka. Váltottam X11-re, és az megoldotta ezeket a problémákat. De most ez az slogin vs ssh. Hááát ilyet még nem láttam. Főleg, hogy symlink...
-
AcCEsS
senior tag
Egy elég különös problémám van az X11forwarddal. A távoli gépen indított böngésző képe nem jelenik meg ha slogin -X felhasználónév@gépnév paranccsal jelentkezek be. Viszont az ssh -X felhasználónév@gépnév paranccsal megy jól. És ez azért furcsa, mert az slogin egy sima symlink a /usr/bin/ssh-ra. A távoli gépen egy Debian Bullseye fut, amire nincs teljes X felhúzva, csak azok a függőségek, amiket a Firefox és a Chrome telepítése igényelt. A lokális gép meg egy Ubuntu 22.04, bár ennek nem hiszem, hogy van jelentősége. Bármelyik böngészőt indítva, a parancs alatt villog a kurzor és semmi nem történik. -vvv paraméterrel indítva az ssh bejelentkezést, csak ennyi látszik:
debug3: fd 8 is O_NONBLOCK
debug1: channel 2: new [x11]
debug1: confirm x11
debug3: send packet: type 91
debug2: channel 2: rcvd adjust 46568
debug2: channel 2: rcvd adjust 35352
debug2: channel 2: rcvd adjust 46004
debug2: channel 2: rcvd adjust 35916és itt megáll. slogin helyett ssh bejelentkezéssel meg folytatódik a sor random számokkal és egyéb dolgokkal, majd bejön a böngésző. Számomra totál megfoghatatlan a dolog, van valami tippetek?
-
#32520
ivana
Ármester
fatpingvin
#32517
válasz
fatpingvin
#32517
üzenetére
Igen
A wines és a Linuxos nem ugyan olyan. A wines amúgy tradicionálisan okosabb (mármint az NT), de ma már linuxon is vannak bonyolultabb permissionok is, a szokasos unixon felül. -
#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.
-
Dißnäëß
nagyúr
Kézzel mount-olok, nem fstab-ban még.
Default..
exfatprogs version : 1.1.3Logokban nincs nyoma a chown-os operation not permitted-nek, az egész /var/log összes fájlja közül egyedül auth.log és syslog frissült ebben a percben, hogy megint rápróbáltam és semmi köze hozzá dolgok vannak benne (cron mindegyikben a hülyeségeivel).
Szerintem feladom, lesz ntfs akkor. Azért köszönöm.
-
Dißnäëß
nagyúr
válasz
bambano
#32505
üzenetére
szerintem az ext4 is csinál ilyet.
nem, azzal tök simán megy minden.
mountolás után újra add ki a chown-t. emlékeim szerint elég egyszer.
sudo-zva sem engedi a mount-olt /mnt/valami könyvtár permission-jét állítani mindaddig, míg alatta az exfat/mnt-ben állva és be van mount-olva alá az exfat:
valami@desktop:/mnt$ sudo chown -v valami:users sam870evo1t
chown: changing ownership of 'sam870evo1t': Operation not permitted
failed to change ownership of 'sam870evo1t' from root:root to valami:users
valami@desktop:/mnt$
Ugyanez csont nélkül lefut, ha nincs alá mount-olva az exfat, VAGY ext4 van (például) alatta. -
Dißnäëß
nagyúr
Sziasztok, segítenétek kérlek megfejteni, mi a lóhere van ? Valamit nagyon benézhetek.
- /mnt/ -ben létrehozok egy könyvtárat egy új Samsung SSD-nek
- beállítom user-nek a desktop módú linuxon használt user-emet, group-nak a "users"-t
- még nincs mount-olva fs ugye...
- sudo mkfs.exfat /dev/disk/by-id/ata-Samsung....... -> létrehozom a fájlrendszert, amit Windows-ból is láttatni akarok (dual boot), ezért exfat
- lemegy, minden oké
- sudo mount /dev/disk/by-id/ata-Samsung....... /mnt/valami - mount-olás megtörténik
- létrehoznék könyvtárat - permission deniedKintebb lépek eggyel és látom, hogy amint az exfat-ot fel-mount-olom a neki létrehozott könyvtár alá, a /mnt/valami könyvtáram permission-je átvált root/root-ra, amint umount-olom alóla az exfat-ot, ismét user/group.
ext4-el nem csinál ilyen hülyeséget, gyönyörűen elérem mountolás után az új fájlrendszert a mezei user alól read/write.
Hogy lehet ezt kikerülni ? (még fstab-nál nem tartok, csak konzolban küszködök).
És a durva, hogy sudo-zva sem engedi a mount-olt /mnt/valami könyvtár permission-jét állítani mindaddig, míg alatta az exfat. Ha umount-olom, akkor azonnal viszi sudo-val is, csak felesleges, mert visszaáll az üres könyvtárra a user/group jog.
Nem értem.
(Debian) -
Archttila
veterán
válasz
bambano
#32498
üzenetére
bambano
Fogalmam nincs, de egyszer majd megnezem.vicze1
Igazan nincs mit, de en is kivancsi vagyok a ti tapasztalataitokra...
Egyebkent ha mar 6.1:- EXT4 Rolls Up Some Fixes & Performance Optimizations For Linux 6.1
- Btrfs Brings Some Great Performance Improvements With Linux 6.1fatpingvin
Az kov. Ryzen gent szerintem en is kihagyom
Ha a használhatóság, támogatottság a fő szempont, akkor meg ez a kernel vicc.
Otthonra egyet értek amúgy a BSD alapú megoldásokban. 
Ubuntu dettó. Arch-ot meg sem említem... 
Új hozzászólás Aktív témák
Hirdetés
- Xiaomi 14T Pro - teljes a család?
- HiFi műszaki szemmel - sztereó hangrendszerek
- E-roller topik
- Apple asztali gépek
- Hobby elektronika
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- bitpork: Augusztus 2- szombat jelen állás szerint.
- Tőzsde és gazdaság
- Vezetékes FEJhallgatók
- Milyen notebookot vegyek?
- További aktív témák...
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Gyors, Precíz, Megbízható TELEFONSZERVIZ, amire számíthatsz! Akár 1 órán belül
- AKCIÓ! GIGABYTE GA-Z170X-UD3 Z170 chipset alaplap garanciával hibátlan működéssel
- AKCIÓ! PC Specialist Recoil VIII 17 notebook - i9 14900HX 16GB RAM 2TB SSD RTX 4060 8GB WIN11
- LG OLED Televíziók: FRISS SZÁLLÍTMÁNY -30%
- LG 25GR75FG - E-Sport Monitor - FHD 360Hz 1ms - NVIDIA Reflex + G-sync - AMD FreeSync - HDR 400
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest