Hozzászólok Aktív témák

  • #59070464

    törölt tag

    Majd ha megjon az US layout. Nem erre szantam a matricakat. Addigra lehet megjon az Arch logo is a palmrest-re.

  • 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 ! :R

    "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

    addikt

    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 ]

  • slett27

    addikt

    Szoftveres vagy hardveres RAID ? :D

    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. :U

    "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

    őstag

    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.

    „Az Audacity egy kereszt-emelvény többsávos hangszerkesztő”

  • ubyegon2

    nagyúr

    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! ;]

    no offense, but....rágjál lóherét

  • growler

    senior tag

    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/sec

    Az 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

    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/sec

    ez 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 ]

    no offense, but....rágjál lóherét

  • bambano

    titán

    LOGOUT blog

    pont az ellenkezőjére utaltam...

    (#26056) Frawly: egyébként nem ártana valami konkrétummal alátámasztani, hogy az ssd lehet olyan gyors, mint a ramdiszk (én csak az ellenkezőjére találtam tesztet).

    lezso6 szerint a user: rossz számtech karmája van | @netik: There is no Internet of Things. There are only many unpatched, vulnerable small computers on the Internet.

  • inf3rno

    addikt

    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 ]

  • ubyegon2

    nagyúr

    É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. :)

    no offense, but....rágjál lóherét

  • bambano

    titán

    LOGOUT blog

    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.

    lezso6 szerint a user: rossz számtech karmája van | @netik: There is no Internet of Things. There are only many unpatched, vulnerable small computers on the Internet.

  • ubyegon2

    nagyúr

    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 0

    Elméletileg ezekkel az opciókkal érdemes operálni? Most látom a noatime opció is ott van. Az ebben az esetben igen hasznos lehet! :D

    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.

    no offense, but....rágjál lóherét

  • Frawly

    őstag

    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_eZk

    Tudom, 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=ywAAHuCshnA

    Itt 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).

    „Az Audacity egy kereszt-emelvény többsávos hangszerkesztő”

  • bambano

    titán

    LOGOUT blog

    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.

    lezso6 szerint a user: rossz számtech karmája van | @netik: There is no Internet of Things. There are only many unpatched, vulnerable small computers on the Internet.

  • Frawly

    őstag

    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.

    „Az Audacity egy kereszt-emelvény többsávos hangszerkesztő”

  • 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

    őstag

    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.

    „Az Audacity egy kereszt-emelvény többsávos hangszerkesztő”

  • inf3rno

    addikt

    É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 ]

  • bambano

    titán

    LOGOUT blog

    mi akadályoz meg benne, hogy feltegyél egy 52esr-t?

    lezso6 szerint a user: rossz számtech karmája van | @netik: There is no Internet of Things. There are only many unpatched, vulnerable small computers on the Internet.

  • F34R

    veterán

    Mert mar abba is belevagtak a GTK3-t... :P

    Nem tudom miert nem hallgatja meg senki sem a Palemoon ajanlasomat :P

  • ubyegon2

    nagyúr

    Én minap felraktam egy Palemoonos remastert, de az volt a gondom, hogy még régi sync-et használ, ahhoz meg nem voltak meg a jelszavaim. Ha kimentem a FF-et html-be, azt tudom integrálni a Palemoonba? Viszonylag kompatibilisek egymással?

    no offense, but....rágjál lóherét

  • Rimuru

    addikt

    "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? :DDD Egyebkent leteznek meg azok az accountok mozillanal? nem vagyok benne biztos,
    regen valtottak mar a sync megoldast

    Mit mentesz ki html-be? konyvjelzok? azokat a tobbi bongeszo is megerti, szerencse hogy "szabvanyos" a dolog.

    Vigyázat, csalok!

  • F34R

    veterán

    xml-be vagy csv-be kibirod exportalni [link], de szeriten a key3.db minden jelszavad mentve van, azt meg a profild alatt talalod..

    Az elso megoldas biztonsagosabb..

  • 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 ]

    no offense, but....rágjál lóherét

  • Lenry

    nagyúr

    LOGOUT blog

    Mi a péknek nyitsz meg 1000 tabot?

    Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

  • bambano

    titán

    LOGOUT blog

    a helyes kérdés: miért nem zárja be őket? :)

    lezso6 szerint a user: rossz számtech karmája van | @netik: There is no Internet of Things. There are only many unpatched, vulnerable small computers on the Internet.

  • inf3rno

    addikt

    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 ]

  • Frawly

    őstag

    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.

    „Az Audacity egy kereszt-emelvény többsávos hangszerkesztő”

  • Frawly

    őstag

    Pont ezt az addont még nem, majd kipróbálom. Viszont próbáltam hasonlókat, de azok nem működtek, azokkal is betöltötte a Chrome az összes fület.

    „Az Audacity egy kereszt-emelvény többsávos hangszerkesztő”

  • F34R

    veterán

    En is extrem modon gyujtok informaciot, de azert az 1000 tab kozeleben sosem lesz....

    En a fejemben megtartom, vagy ha nagyon nem erek ra akkor konyjelzozom... Amugy sem tul jo mindenbe beleasni magadat..

  • BoB

    addikt

    Ezért vannak a munkaasztalok. Vagy mindenképpen felesleges saját megoldást akarsz? :))

    You may corrupt the souls of men, but I am steel. I am doom.

  • inf3rno

    addikt

    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.

  • Lenry

    nagyúr

    LOGOUT blog

    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 :U

    Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

  • inf3rno

    addikt

    Próbáltam még évekkel ezelőtt, sokkal időigényesebb az a módszer, mint a mostani. Egyébként ennek már nem sok köze van a Linux-hoz...

    [ Szerkesztve ]

  • Lenry

    nagyúr

    LOGOUT blog

    é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-ban

    Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

  • inf3rno

    addikt

    "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 ]

  • Frawly

    őstag

    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.

    „Az Audacity egy kereszt-emelvény többsávos hangszerkesztő”

  • BoB

    addikt

    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 MASQUERADE

    Mivel 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-dhcp

    udv
    letix

    [ Szerkesztve ]

    don't panic! ... http://www.letix.hu - linux parancsok

  • bambano

    titán

    LOGOUT blog

    a kérdésedre a választ a hozzászólásában a "Ezt adtam hozzá az openvpn konfighoz:" sor után találod.

    lezso6 szerint a user: rossz számtech karmája van | @netik: There is no Internet of Things. There are only many unpatched, vulnerable small computers on the Internet.

  • 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.Z

    Az 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
    letix

    don't panic! ... http://www.letix.hu - linux parancsok

  • inf3rno

    addikt

    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.

Hozzászólok Aktív témák