-
Fototrend
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
slett27
addikt
Egy egyszerű kérdéssel fordulnék hozzátok. Samba 3-as (Ubuntu 14.04 LTS) szervert szeretnék migrálni (öreg a régi szerver, ez a cég lelke, újabb vasat kapna). Meg lehet oldani ? Semmi leírást nem találtam erre vonatkozóan, ezért kérném a segítségeteket. Nagyon sok a felhasználó, a hozzá kapcsolódó jogosultság, könyvtár. Vagy újra fel kell venni minden felhasználót egyenként a jogosultságokkal, könyvtárakkal együtt ?
Köszönöm előre is !
"Ismerősöm szerint az ő Logitech Z-623-as rendszere (bizonyos esetekben) jobban szól, mert felére feltekerve is adja a mélyet, szétveri a házat a gettób@szó számokban !" by Rasiel :DDD
-
inf3rno
nagyúr
válasz slett27 #26053 üzenetére
Mi a kérdés? Elvileg kicsi az esély arra, hogy ne működjön, ha csak simán átpakolod a lemezeket az újba. Talán akkor lehet gond, ha nagyon új a hardver és a 2014-es kernelbe nem lett belefordítva a hozzá való driver, de ezt csak laikusként mondom. Ha tesztelni akarod, akkor clonezillával tudsz másolatot készíteni a rendszerről, de az is leállással fog járni szerintem. Ha upgradelni akarod a rendszert, akkor szerintem az is megoldható, de abban inkább valaki szakértő adjon tanácsot.
Nekem is van kérdésem ezzel kapcsolatban, ha RAID1-be tenném a rendszert és utána átraknám egy másik gépbe az egyik lemezt, akkor az egyenértékű a clonezillás klónozással?
[ Szerkesztve ]
Buliban hasznos! =]
-
slett27
addikt
válasz inf3rno #26054 üzenetére
Szoftveres vagy hardveres RAID ?
Amúgy az lenne a cél, hogy a felhasználókkal és könyvtárakkal valamint konfigurációs fájlokkal együtt MÁSOLOM a Samba-t a másik szervergépre. Elvileg ezt nem lehet így megcsinálni, mert a jogosultságokat, csoportokat és a csoportokhoz kapcsolt könyvtárakat nem lehet másolni.
"Ismerősöm szerint az ő Logitech Z-623-as rendszere (bizonyos esetekben) jobban szól, mert felére feltekerve is adja a mélyet, szétveri a házat a gettób@szó számokban !" by Rasiel :DDD
-
Frawly
veterán
válasz ubyegon2 #26046 üzenetére
Azt csak hiszed, hogy nem közelíti meg. Bechmarkokban tényleg sokkal jobb a RAM, meg az elérése is pár nagyságrenddel gyorsabb, de a gyakorlatban majdnem azonos sebességet hoznak, mint a SATA SSD-k. Ha nem hiszed, próbáld ki. Az oka az, hogy ha a lemezműveletek ideje elér egy kritikusan alacsony szintet, onnantól a proci a szűk keresztmetszet, nem a lemezműveletek sebessége. Ezért van az is, hogy gyakorlatban, átlag felhasználásnál nem érezni a sebességkülönbséget a SATA SSD-k és az NVMe-s SSD között.
Abban viszont egyetértek, hogy az SSHDD-nek nem sok értelme van, menjen a rendszer SSD-re, a nem sebességkritikus adatok meg HDD-re.
-
ubyegon2
nagyúr
válasz Frawly #26056 üzenetére
Igazad lehet, nekem ebben valóban nincs gyakorlati tapasztalatom, de teljesen logikus amit írsz, meg bambano is erre utalt. Olvas az ember sok mindent, de valóban más a hétköznapi gyakorlat!
Ezért van az is, hogy gyakorlatban, átlag felhasználásnál nem érezni a sebességkülönbséget a SATA SSD-k és az NVMe-s SSD között.
Én erősen érezném itt a különbséget azért.....az NVMe nehezen találna csatlakozást a gépeimben!
-
growler
őstag
válasz Frawly #26056 üzenetére
sudo hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 8264 MB in 2.00 seconds = 4133.06 MB/sec
Timing buffered disk reads: 386 MB in 3.01 seconds = 128.27 MB/secAz alsó érték egy 30 GB-os SATA2-es SSD olvasási sebessége. (szerintem valós)
A felső érték a RAM olvasási sebességére utalhat ? -
ubyegon2
nagyúr
válasz growler #26058 üzenetére
Valami hasonló értékre utalhat, azért ezek az értékek picit különböznek így elsőre mégiscsak. Ezek a mérések is igazolhatják a gyanúdat, mert a másodiknál is hasonló az első érték, az egy HDD:
/dev/sda:
Timing cached reads: 4660 MB in 2.00 seconds = 2329.97 MB/sec
Timing buffered disk reads: 1222 MB in 3.00 seconds = 407.31 MB/sec/dev/sdb:
Timing cached reads: 4610 MB in 2.00 seconds = 2305.18 MB/sec
Timing buffered disk reads: 544 MB in 3.00 seconds = 181.12 MB/secez is valami hasonlót ír amúgy:
Difference between buffered disk reads and cached reads? -forrás
-T
Végezze el a gyorsítótár olvasási idejét összehasonlító és összehasonlító célokra. Jelentősebb eredmények elérése érdekében ezt a műveletet 2-3 alkalommal meg kell ismételni egy egyébként inaktív rendszerben (nincs más aktív folyamatok) legalább egy darab megabájt szabad memóriával. Ez azt mutatja, hogy az olvasás sebessége közvetlenül a Linux puffer-gyorsítótárból érkezik lemez nélküli hozzáférés nélkül. Ez a mérés lényegében a processzor, a gyorsítótár és a vizsgált rendszer memóriájának áteresztőképességét jelzi. Ha a -t flag is meg van adva, akkor a -t művelethez kapott eredménybe beépítjük a -T kimenetén alapuló korrekciós tényezőt.
-t
Végezze el az eszközök olvasási idejét összehasonlítási és összehasonlítási célokra. Jelentősebb eredmények elérése érdekében ezt a műveletet 2-3 alkalommal meg kell ismételni egy egyébként inaktív rendszerben (nincs más aktív folyamatok) legalább egy darab megabájt szabad memóriával. Ez azt jelzi, hogy az olvasás sebessége a tárcsa gyorsítótárban a lemezen előzetes adatrögzítés nélkül történik. Ez a mérés azt jelzi, hogy a meghajtó mennyire képes a Linuxon futó szekvenciális adatokat olvasni, fájlrendszer nélkül. A pontos mérések biztosítása érdekében a puffer gyorsítótárat a BLKFLSBUF ioctl használatával átöblítjük. Ha a -T flag is meg van adva, akkor a -T kimenetén alapuló korrekciós tényezőt beillesztjük a t művelethez kapott eredménybe.[ Szerkesztve ]
-
bambano
titán
-
inf3rno
nagyúr
válasz slett27 #26055 üzenetére
Van különbség RAID1-nél? Azt hittem az csak lemásolja a másik lemezre ugyanazt, ami az egyiken van...
Google rengeteg találatot dob Samba-val kapcsolatban: http://lmgtfy.com/?q=migrate+samba, nézegetted már őket?
[ Szerkesztve ]
Buliban hasznos! =]
-
ubyegon2
nagyúr
válasz bambano #26060 üzenetére
Értem, akkor csak jól értelmeztem eddig a dolgokat, Frawly jól összezavart most, igazából azt gondoltam, hogy ezek a piszok gyors NVMe SSD-k már ilyen gyorsak az én öreg Intel 520-asomhoz képest, de ez a terminalos parancs lefuttatás megint helyrerakta a dolgokat a fejemben szerencsére. Csak sata3-as SSD- vel operálgattam eddig Frawly koma meg már tanácsadó az SSD topikban, gondoltam csak jobban tudja, mint én. Akkor marad a tmpfs..... köszi, hogy helyretettük a dolgot megint.
-
bambano
titán
válasz ubyegon2 #26062 üzenetére
nem követtem, hogy mi a probléma, de a leggyorsabb diszk elérés az lesz, ha sok szabad ramod van, amiben elterpeszkedhet a diszk block cache. az általam látott teszteredmények szerint egy gyors pörgős diszk és egy ssd között 3-5x, egy ssd és a ramdiszk között 10-15x sebességkülönbség van.
a legjobban akkor jársz, ha hagyod, hogy a kernel optimalizálja a ramot és ehhez van bőven ramod. elméletben igaz, hogy bejöhet processzor limit, csak ennek olyan tág a határa, hogy sose érjük el.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
ubyegon2
nagyúr
válasz bambano #26063 üzenetére
https://logout.hu/tema/a_nagy_linux_topic/hsz_26040-26043.html#msg26043
Még mindig ugyanez a thread, nem volt probléma most.
a legjobban akkor jársz, ha hagyod, hogy a kernel optimalizálja a ramot és ehhez van bőven ramod
#tmpfs to .cache
#tmpfs /home/ubyegon/.cache tmpfs noatime,nodev,nosuid,size=800M 0 0# Modification for SSD
#tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
#tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0
#tmpfs /var/spool tmpfs defaults,noatime,mode=1777 0 0
#tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0Elméletileg ezekkel az opciókkal érdemes operálni? Most látom a
noatime
opció is ott van. Az ebben az esetben igen hasznos lehet!8GB fizikai memónál használnád valamelyiket az elsőn kívül desktopban? Az OK, hogy a logok elvesznek, most az nem számít ebben az esetben.
-
Frawly
veterán
válasz bambano #26060 üzenetére
Ott rontottátok el, hogy beszoptátok a marketingbullshitet és a szemfényvesztő benchmarkeredményeket.
Tessék, íme videók, amelyeken SATA és NVMe-s SSD-t hasonlítanak össze betöltési időkben fej-fej mellett:
https://www.youtube.com/watch?v=l6Y6VdXO5es
https://www.youtube.com/watch?v=ecCA0gx_eZkTudom, erre azt mondjátok majd, hogy YouTube-os hülyék, de akkor álljon itt egy PH-teszt is. A 4. oldalon szépen látszik, hogy pl. bootidőben csak alig 1-2 mp. van a SATA-s és NVMe-s modellek között.
Itt ramdrive és SSD van összehasonlítva, szépen látszik, hogy csak tizedmásodperces különbségek vannak betöltési időkben:
https://www.youtube.com/watch?v=ywAAHuCshnAItt a néni el is magyarázza, hogy miért van ez. Játékról beszél, de ez van bootkor és minden más program betöltésénél is.
De ki lehet próbálni otthon. Ramdrive-ra feltenni egy-két programot, vagy virtuális gépet, és lemérni az indulási időket. 1 mp-es vagy azon belüli eltérések lesznek. Vagy pl. lehet forráskódból forgatásnál is megnézni, nálam a kernelfordításnál tizedmásodpercre azonos idő alatt fordult le a kód ramdrive-on és SATA SSD-n is. Linux alatt még a kevés különbség se jön ki, mert a kernel minden I/O-műveletet és fájlrendszert agyoncache-el orrba-szájba.
Amit meg itt a sudo hdparm -Tt kiadásával mértek, az cache nyers sebessége.
A RAM vs. NVMe vs. SATA sebesség azoknál számít, akik több gigás nagy fájlokkal dolgoznak, pl. videót vágnak, vagy virtuális lemezképekkel zsonglőrködnek egész nap, átlag felhasználásnál nem jön ki a különbség. A mai gépeket már nem a lemezműveletek sebessége fogja vissza (hacsak nem HDD van a gépben, mert az csúnyán visszafogja).
-
bambano
titán
válasz Frawly #26065 üzenetére
először is velem szemben mellőzd az ilyen igék használatát, nem őriztünk együtt libát.
másodszor azok a videók, amiket linkeltél:
- az első címe: "NVMe vs SATA SSD vs HDD - Game load and file copy times tested"
- a második címe: "Samsung 960 Pro vs SATA SSD - game loading times tested"
a címük alapján, és a tartalmába is belenézve, teljesen indifferensek az állításaimhoz képest.az én állításom az volt, hogy a ram gyorsabb, mint az ssd. hogy a ram szóból te hogy keveredtél át az nvme csatolós ssd-khez, az a te belső magánügyed, én nem tudom, de nem is érdekel.
de hogy legyen ontopic teszt is:
[link] és [link]
ezek már reálisabb tesztek abból a szempontból, hogy azokat az eseteket teszteli, amikkel kapcsolatban állítottam valamit, nem pedig indifferens témákat.a számok magukért beszélnek, az állításod tévedés.
most nem akarom azt firtatni, hogy az ablakos rendszer mennyiben hivatkozási alap itt. azt se firtatnám, hogy egy kézmodell magyarázata mennyire szakmai és/vagy helytálló, annyi köze van a témához, hogy az ő főnökének a keresztneve is Linus. a vezetékneve már nem stimmel, de borítsunk fátylat ilyen apróságokra.
"Vagy pl. lehet forráskódból forgatásnál is megnézni, nálam a kernelfordításnál tizedmásodpercre azonos idő alatt fordult le a kód ramdrive-on és SATA SSD-n is. ": megmérted kétszer egymás után a ramdrive-ot és nullaszor az ssd-t? maradjunk annyiban, hogy a véleményed nem lesz általánosan népszerű itt.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Frawly
veterán
válasz bambano #26066 üzenetére
Pedig nem akartam beszólogatni, de sajnos erről van szó, nem tudsz elszakadni a benchmarkoktól. Felvetted a szemellenzőt, és nem bírod levenni. Írtam, hogy igazából gyorsabb a ramdrive, mint az NVMe, és az NVMe gyorsabb, mint a SATA. Ez tény. Ez a sebességkülönbség ki is jön, de
1) csak benchmarkok alatt (az általad linkelt videókon is CSAK benchmark van) vagy
2) ha nagyon nagy fájlokkal dolgozik valaki egész nap (megélhetésből videót vág, vagy nagy virtuális lemezképekkel zsonglőrködik).Az első kategória nem érdekes, a Benchmark Matyik lehet csak benchmarkra veszik a gépüket, de értelmes ember, aki használni is akarja a gépet, inkább olyan hardvereket vesz, amikkel a gyakorlatban tényleg nyer (valós gyorsulás, kihasznált feature/tárterület, stb.).
A második kategória már bír gyakorlati jelentőséggel, de elég kevés ember használja ilyesmire a gépet, lényegében csak szakemberek. A felhasználók többi 99,9%-a csak használja a gépet, és náluk a ramdrive/dimmdrive, NVMe, SATA SSD kb. egyformán teljesít, nem lesz nagy eltérés sem a bootidőben, sem a programok betöltődésénél, sem böngészésnél, sem játékoknál, sem semmiben, ilyen tized másodperces diffik szoktak lenni, legrosszabb esetben 1-2 másodperc, de akkor már egy spécibb alkalmazásról van szó, vagy egy nagyon lassan bootoló, bloat OS telepítésről. Mondom, ne a benchmarkokon rugózz, én a gyakorlati felhasználásról és ténylegesen észlelt sebességkülönbségről beszélek.
Windows nem is volt téma, nem windowsosok már kb. 4 éve. Csak azért szerepel a legtöbb videón windowsos rendszer, mert a legtöbben azt használnak, meg megemlítettem emellett, hogy a Linux rommá is cache-el mindent, ha van elég RAM. Linus-os videót meg nem azért linkeltem, mert köze lenne Torvaldshoz vagy a Linuxhoz, hanem csak épp ez foglalkozott a tényleges sebességek mérésével, a csóka neve nem releváns, hívjuk akkor Jóska Pistának.
Nem véletlen írjuk már vagy öten az SSD-s topikban, hogy nem érdemes NVMe SSD-t venni átlag felhasználásra, mert nem lesz tőle gyorsabb semmi, csak benchmarkokban villogásra jó. A legtöbb embert ez teljesen meglepi, mert az hiszik, hogy ha benchmarkokban gyorsabb, akkor a gyakorlatban is ki fog jönni a difi. Nem fog. Ennek ellenére ezt néhány ember nem hiszi el, inkább megveszik a méregdrága NVMe SSD-t kétszer annyiért, és csak 0,5-1 mp-et nyernek bootkor vagy nagyobb szoftverek betöltődési idejénél (ezt érzetre észre sem venni, csak ha stopperral leméred), pedig nyugodtan vehettek volna SATA-sat, ugyanazon az áron kétszer akkora tárterületűt kaptak volna, vagy ugyanazt a tárterületet megkapták volna fele áron, és gyakorlati sebességben az sem maradt volna el, a rendszerük lényegében épp olyan gyors lett volna (10 mp alatti bootidő, a legtöbb szoftver azonnal indul pöccre, 0 lag). Sőt, még az NVMe-vel bevállalják azt is, hogy melegszik meg throttlingol az SSD, meg a boottal is szenvedni kell, főleg ha nem támogatja az alaplap, míg a SATÁ-val ilyen gond nincs.
Az is leírtam, hogy miért áll elő ez a paradox helyzet, miszerint nagyságrendekkel gyorsabb háttértárak között nem vagy alig jön ki a különbség a gyakorlatban, érdekes, erre az érdemi részre nem reagálsz, csak hajtogatod a benchmarkokat. Nem a lemezműveletek sebessége a szűk keresztmetszet egy szinten túl, hanem a proci meg egyéb hardverek sebessége. Ezt a kritikus szintet pedig egy nem márkás, low budget SATA SSD is hozza már. Hiába használna valaki a RAM-nál is még ezerszer gyorsabb háttértárat, az nem tudná kifutni ezt a sebességkülönbséget, nem lenne a rendszere tőle gyorsabb, csak nagyon extrém scenáriókban jönne ki a különbség, amibe a legtöbb ember nem fut bele. Persze, ha te is benchmarkra veszed a géped, akkor semmi gond. Elhiszem, hogy szép benchmarkok alatt látni, hogy 1 ns alatt van az elérési idő meg 5-10 gigás másodpercenkénti átviteli értékek vannak, tényleg szép látvány, szinte sokkoló, egész addig, míg az ember rá nem jön, hogy csak cirkuszi mutatvány, nem sok gyakorlati relevanciával.
-
kmisi99
addikt
Sziasztok SAMBA val kapcsolatban van egy marha fura problémám.
Diszró: Dietpi (raspberryre való)A célom vele. Több felhasználó hozzárendelés, adott felhasználó csak adott megosztást érhet el.
Amit csináltam.
Csináltam új felhasználótkat az # adduser paranccsal
Ezzel a paranccsal hozzáadtam a samba-hoz a felhasználót #sudo smbpasswd -a felhasznalonev
Az smb.conf-ban pedig a valid users = felhasznalo az adott megosztáshoz.De az istenért nem jön össze. Kéri a felhasználó jelszót a windows, de azt írja, hogy unable accees, illetve nincs jogosultságom hozzá, ha be akarok lépni. Viszont "elfogadja" a jelszót, mert ha elgépelem, akkor egyértelműen bejön, hogy írjam be újra a jelszót mert rosszat írtam be, szóval elfogadja csak valami jogosultság baja van.
Forceuser = root al se jó.Ha kitörlöm a valid users részt, vagy hozzáadom a root-ot akkor viszont működik. Megnyitható a megosztás.
Azaz a root felhasználóval gond nélkül hozzá tudok férni. (A sima user /home/felhasznalo mappájához se enged hozzáférni, ott nyilván van jogosultságom azzal a felhasználóval)
Ami megint érdekes, hogy a smbpasswd -a root al megváltoztatom a root jelszavát, onnantól a root is olyan státuszba lépett, hogy még a \\server\ re se engedett fel, hiába adtam meg a root új jelszavát ismét ugyan úgy unable to access, nincs jogosultság.
Csakis akkor jó ha visszaállítom az eredeti alap jelszavát.
Vajon mi lehet ez? Hol lehet a hiba? Órákat töltöttem el a próbálkozásokkal, túrtam a netet, de semmi.
Itt a hibaüzi.
[ Szerkesztve ]
-
#59070464
törölt tag
Azt hiszem en befejeztem a heavy bloated Firefox-al.
surf - azt hiszem a source code mindossze 1700 sor[ Szerkesztve ]
-
Frawly
veterán
válasz #59070464 #26069 üzenetére
Az a baj, hogy a mai böngészők már kvázi OS-ként funkcionálnak az OS-en belül. Kazalnyi protokollt, hardveres és biztonsági dolgot kell támogatniuk, és mindenféle multimédiás szir-szart. Emiatt nem lehetnek pehelykönnyűek.
Hiába is váltasz minimalista böngészőre, azokkal egy csomó oldal nem fog normálisan menni. A FF tényleg bloat, meg egyre inkább cseszik el, emiatt váltottam én is Chrome-ra, de az meg még bloatabb, annyi az előnye, hogy annyira minimalista, hogy nincs mit rajta elrontani, meg gyors.
Plusz csak részben a böngészők hibája, az oldalak is nagyon szarul vannak megírva, csomó flashes tartalom, nagy kazal kép, tonnányi JS, már ezek egymagukban meg tudják enni a világ összes hardverét, ha kellő számú fül van megnyitva. Egy-egy indexes meg facebookos oldal már megákban mérhető kódméretben, memóriaméretben meg ennek százszorosa.
-
inf3rno
nagyúr
válasz Frawly #26070 üzenetére
Én is észrevettem, hogy a Firefox kezd hulladék lenni. Folyamatosan kerültek elő hibák az elmúlt évben, amiket csak nagy sokára javítottak, ha egyáltalán megtették. Régen azért stabilabb életérzés volt. FF nálam olyan 1GB-ot eszik cirka 1000 nyitott tabbal. Nem igazán érzem át, hogy kevés lenne a RAM vagy CPU neki. Inkább az zavar, hogy 5 percenként szétcsúszik benne a flash játék, amivel tolom. Már váltottam flash-el MSIE-re, az csak összeomlik fél óránként, de legalább úgy működik rajta a cucc, ahogy kell.
[ Szerkesztve ]
Buliban hasznos! =]
-
Rimuru
veterán
válasz ubyegon2 #26077 üzenetére
"régi sync-et használ, ahhoz meg nem voltak meg a jelszavaim" - remelem itt nem arra gondolsz hogy a mozilla szerverein levo accountra akartal csatlakozni palemoonsok szerveren? Egyebkent leteznek meg azok az accountok mozillanal? nem vagyok benne biztos,
regen valtottak mar a sync megoldastMit mentesz ki html-be? konyvjelzok? azokat a tobbi bongeszo is megerti, szerencse hogy "szabvanyos" a dolog.
Vigyázat, csalok!
-
ubyegon2
nagyúr
& (#26078) colomb2
Köszi a tippeket! Fene se emlékszik már rá, de a régi FF-os sync-szerű volt, de akkor a javasoltak alapján ránézek majd!
Véletlenül nem tudjátok, van-e halott link jelző most a FF-ra, mert nem akarom mind a 60ezret átrakni, ha fele halott úgyis.
Mit mentesz ki html-be? konyvjelzok? Igazából minden kéne, amit csak át lehet hozni.
[ Szerkesztve ]
-
inf3rno
nagyúr
Elkezdek valamiről olvasni, megnyitok 50 tabot, amit google kidob. Elkezdem nézni, marad 20, mire találok valami specifikusabbat azzal kapcsolatban, amit kerestem. Arra is rákeresek az új kulcsszavakkal, megint 50 új cikk, és így tovább. Valamikor rászánok pár órát, hogy lezárjak egy-egy témát, és átnézek párszáz tabot egyszerre, de legtöbbször csak gyűlik a cucc különböző témákban. Most írok szoftvert, amivel témákhoz tudom majd kötni a munkameneteket, és így nem kell annyinak nyitva lenni egyszerre. De szerintem csak jövőre fog elkészülni, amilyen ütemben haladok vele. Ezt tudom ajánlani, ha valaki sok tabbal dolgozik Firefox-al, életmentő tud lenni, ha összeomlik az app: [link]
[ Szerkesztve ]
Buliban hasznos! =]
-
Frawly
veterán
válasz inf3rno #26083 üzenetére
Az 1000 tab mindenképp extrém, de az 50-es példád megállja a helyét. Sokszor csak lusták az emberek bezárni a tabokat, egyfajta könyvjelzőként hagyják kint, én is így csinálom. Így ha megnyitom a böngészőt, akkor látom a füleken, hogy mi volt megnyitva, mit akartam azokkal, melyik böngészési szálat kell folytatni. Könyvjelzőknél ezt nem látni, csak ha külön lenyitja az ember.
A modern böngészők amúgy is csak az utoljára használt 1-3 tabot töltik be induláskor, aztán a többit egyesével, ha átvált oda az ember. Kivéve a Chrome, mert annál minden fül külön folyamat, és betöltögeti az összeset, ez is a bajom vele. Egyébként a FF sokkal takarékosabban bánik a memóriával, mint a Chome.
-
inf3rno
nagyúr
Olyasmi kell, ami szerverről megy többféle kliensen (vegyesen Windows és Linux) és szinkronizál a kliensek között. Pl elkezdek nézni valamit az asztali gépen, aztán a tableten vagy laptopon folytatom később ugyanazt a munkamenetet akár egy netkávézóban vpn-en keresztül, ha olyanom van. Ezen kívül függeni sem szeretnék felhős ingyenes szolgáltatásoktól, amik bármikor megszűnhetnek, illetve abból élnek, hogy rólam információkat adnak el.
@F34R: Én könyvjelzőbe csak azt gyűjtöm, amit már elolvastam, és hasznosnak találtam. A többi csak ideiglenes tárolóba megy, azért vannak nyitott tabokban.
Buliban hasznos! =]
-
Lenry
félisten
válasz inf3rno #26089 üzenetére
A többi csak ideiglenes tárolóba megy, azért vannak nyitott tabokban.
vagy akár létrehozhatsz egy temp mappát a könyvjelzőid közt és odamented őket, aztán törlöd, amikor már nem kell
Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
Lenry
félisten
válasz inf3rno #26091 üzenetére
értem, csak fel nem foghatom. többektől olvastam már hogy így csinálják, de náluk is, nálad is szinte biztos vagyok, hogy 1000 tabból az utolsó 950-et valószínűleg úgysem fogod soha elolvasni.
ennek már nem sok köze van a Linux-hoz...
ezért van OFF-banGvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
inf3rno
nagyúr
"többektől olvastam már hogy így csinálják, de náluk is, nálad is szinte biztos vagyok, hogy 1000 tabból az utolsó 950-et valószínűleg úgysem fogod soha elolvasni."
Ezt mire alapozod? 5+ éve böngészek így, nagyon sokszor voltam már nullánál...
[ Szerkesztve ]
Buliban hasznos! =]
-
Frawly
veterán
Azzal egyetértek, hogy az 1000 tab azért is sok, mert áttekinthetetlen. Ilyen mennyiség mellett a tabok eleve olyan kicsik, hogy max. csak az oldalikon látszik, az oldalak nevei egyáltalán nem. Kb. 100-ig könnyű átlátni mik vannak nyitva, afölött káosz, persze felbontástól is függ, meg hogy a fülsáv vízszintes vagy függőleges.
-
BoB
veterán
válasz inf3rno #26093 üzenetére
Mondjuk azt nem értem hogy ha keresel egy témában, minek megnyitni a google első kétszáz találatát. Megnézed az elsőt. Ez az? Nem, akkor bezár, nézzük a másodikat.
Főleg hogy közben eszedbe jut nás téma is. Annak is megnyitod az első kétszáz találatát. És így tovább.
Jó lenne látni miket keresel mert első látásra számomra teljesen ésszerűtlennek tűnik így böngészni.
You may corrupt the souls of men, but I am steel. I am doom.
-
n00n
őstag
Sziasztok.
Van egy VPN szerverem, amihez távolról szoktam csatlakozni. Eddig úgy volt beállítva, hogy csatlakozás után elértem a szerver hálózatát.
server 10.8.8.0 255.255.255.0
push "route 10.0.0.0 255.0.0.0"Viszont van egy külső, szóval nem LAN-on lévő szerver, amit szintén a VPN szerveren keresztül szeretnék elérni. Magyarán A.B.C.D IP-jű szerveren whitelistelem a VPN szerverem IP-jét, szerverről curl-lel szépen le is jön, aminek jönnie kell. VPN-en keresztül viszont nem megy. Valószínű tűzfal miatt.
Ezt adtam hozzá az openvpn konfighoz:
push "route A.B.C.D 255.255.255.255"
Iptables szerintem releváns része:
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
-A INPUT -s 127.0.0.1/32 -i eth0 -j DROP
-A INPUT -d 127.0.0.1/32 -i eth0 -j DROP
-A INPUT -s 127.0.0.1/32 -j ACCEPT
-A INPUT -d 127.0.0.1/32 -j ACCEPT
-A INPUT -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j allowedHosts
-A INPUT -i eth1 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -j DROPLOG
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 127.0.0.1/32 -i eth0 -j DROP
-A FORWARD -d 127.0.0.1/32 -i eth0 -j DROP
-A FORWARD ! -s 10.0.0.0/8 -i eth1 -j DROP
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i eth1 -j ACCEPT
-A FORWARD -o eth0 -m state --state NEW -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -o eth0 -m state --state NEW -j ACCEPT
-A OUTPUT -o eth1 -m state --state NEW -j ACCEPT
-A DROPLOG -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
-A DROPLOG -j REJECT --reject-with icmp-port-unreachable
-A POSTROUTING -o eth1 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/8 -o eth1 -j MASQUERADEMivel kellene ezt kiegészítenem, hogy menjen a dolog. Firewalld-vel még csak csak el vagyok, de az iptables kínai nekem. Köszi.
[ Szerkesztve ]
-
letix
aktív tag
Szia n00n,
Nem vagyok nagy szakértője a témának, de hátha nem teljesen hülyeség:
Ha jól értem, van egy harmadik állomás (A.B.C.D) amit el szeretnél érni a VPN hálózatból, ahova becsatlakoztál.
Érdemes lenne megtudni, hogy ha a VPN hálózatban lógsz, akkor ki az átjáród az internet felé.A: a saját kliensed előtti gw. (vélhetően ez az)
B: a VPN szerver, amennyiben ez a beállítás a VPN configban szerepel. (szerintem nem szerepel)Amennyiben az A, akkor szerintem úgy tudod elérni az A.B.C.D-t ha azt az IP-t engeded be rá, bár ez gondolom dinamikus.
Azt gondolom ha a VPN szerver címét engedted A.B.C.D felé, akkor a B variánst kellene elérni úgy, hogy a VPN kliensek teljes forgalma menjen át a VPN szerveren.Valami ilyesmivel:
push "redirect-gateway def1 bypass-dhcpudv
letix[ Szerkesztve ]
don't panic! ... http://www.letix.hu - linux parancsok
-
letix
aktív tag
Üdv,
Van egy érdekes jelenség melynek okára egyelőre nem jöttem rá.
Leledzik egy több ethernet kártyával megáldott Debian gép, a kártyái közül az egyiken (és csak azon) mint dhcp szerver funkcionál.
Fut rajta egy smokeping nevű alkalmazás, mely egy másik kártyán megy ki a net felé és ott is várja vissza a válaszokat.A syslog-ban ilyenek láthatóak,
Oct 3 15:51:12 host01 dhcpd: unexpected ICMP Echo Reply from X.Y.Z.V
Oct 3 15:51:12 host01 dhcpd: unexpected ICMP Echo Reply from V.X.Z.Y
Oct 3 15:51:12 host01 dhcpd: unexpected ICMP Echo Reply from X.V.Z.ZAz ipk ismerősek, a smokeping "végei", az viszont nem értem, hogy hogyan kerülnek kapcsolatba ezen IP-k a dhcpd daemonnal? Miért gondolja hogy az neki szól?
A smokeping egyfolytában pingel, a syslog-ba viszont óránként kerülnek ilyen sorok.Köszönöm előre is.
udv
letixdon't panic! ... http://www.letix.hu - linux parancsok
-
inf3rno
nagyúr
válasz Frawly #26094 üzenetére
El vagy tévedve:
Van tree style tab plugin is, ami aszerint rendezi fába, hogy melyik új tabot melyik másikból nyitottad meg. Egy időben használtam, egész jó volt, de most már általában sorban szoktam menni időben visszafelé, tehát mindig az utolsót nézem, és nem foglalkozok az előzőekkel. Ha valami sürgős, akkor nem nyitok meg addig másikat, amíg nem olvastam át minden vele kapcsolatosat.
@BoB:
Azért te is érzed, hogy az első 200 az erős túlzás, én is csak negyed annyit írtam. Általában ezeknél is megnézem az idézett részt a google-ben mielőtt megnyitnám. Időben visszafele haladva most ezek a témák (30 db, átlag 30-40 tab témánként):
- design by contract
- duplatalpas statikus pipapánt ajtóhoz
- meghajtótitkosítás - dmcrypt, veracrypt, ciphershed, truecrypt, stb...
- unlock luks/dmcrypt via remote ssh, usb pendrive
- Alan Key OOP, message oriented programming, agents, tell don't ask, stb...
- init systems, systemd, relauchd, stb...
- Alpine + Docker, Ubuntu 16 + Docker
- Ubuntu 17
- Devuan, Slackware, systemd, runit, stb...
- Docker remote container management gui
- server control panels
- btrfs
- nodejs repl
- custom interactive shell / nodejs shell
- custom docker shell
- zmq + docker, zmq + nodejs
- docker security, sandboxing docker
- pm2 + docker
- ddd
- rest + hydra
- btrfs backup, rollback
- szájzuhany, elektromos fogkefék, lézeres ínyműtétek, stb.
- raid, fake raid, raid0,1,10,5,6, software raid, btrfs, zfs, stb.
- ajánlott uATX házak
- TDD/BDD + docker
- capturing ARP broadcasts, sleep proxy, TCP proxy, stb.
- search engine domain model, ranking, stb.
- custom firmware, openVPN routers
- custom router firmwares, openWRT, LEDE, Tomato, stb.
- mikroszerver alaplapok, processzorok, memória, komplett gépek, stb...Ezeknek egy kis része olyan, amire már nincs szükség, és be lehetne zárni, pl a mikroszerver hardveres része, router választás, szájzuhany és az init rendszer választás ilyenek, mert velük kapcsolatban már döntöttem. Viszont erőforrást alig foglalnak, mert úgysem tölti be soha őket a Firefox, szóval nincs velük dolgom. Majd ha visszajutok hozzájuk, akkor bezárom őket. A maradékot még át kell néznem, és elolvasni, ami arra érdemes.
Buliban hasznos! =]
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen