- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Nem várt platformon a OnePlus Nord 5
- iPhone topik
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Google Pixel topik
- Honor 400 Pro - gép a képben
- One mobilszolgáltatások
- Magisk
- Poco M3 - felújított állomás
- Honor Magic V2 - origami
-
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
-
vargalex
félisten
válasz
haddent #29515 üzenetére
Én is ezeket értem alatta és pont ezért kérdezem. Viszont ennek ellenére több ügyfelünk is Ubuntut használ production-ban. Van olyan állami ügyfelünk, aki az általunk supportált SLES-t váltotta arra úgy, hogy egyikhez sem ért. Persze, velünk megszüntette a supportot...
És van nagy telekommunikációs ügyfelünk is, ahol production-ban Ubuntu van. Ez utóbbi pedig rendes hely... -
vargalex
félisten
válasz
samujózsi #29410 üzenetére
Bocsánat, akkor félreértettelek. Lehet, hogy haddent kolléga hozzászólásával összemostam a tiédet, mindenesetre én úgy értettem, hogy inkább a bash hiányzik ezeken a rendszereken, mint a python/perl.
Persze, bash nincs, de van busybox ash, elég sok minden megoldható. Viszont 4 MB-os flash-el szerelt routerre nem nagyon lehet python-t/perl-t varázsolni (de még 8 MB-al szereltre is csak nehezen). Attól most tekintsünk el, hogy az OpenWrt csapat dobta is a támogatását az ilyen eszközöknek 19.07-től. -
vargalex
félisten
válasz
samujózsi #29044 üzenetére
A systemd-resolved fallbackDNS-t állítsd be, különben ennek hiányában valóban béna módon publikus DNS-ekre fallback-ol...
-
vargalex
félisten
válasz
samujózsi #29040 üzenetére
Pont ezért kérdezem, hogy tudjak javasolni. Eddig részedről a docker hangzott el korábban, az pl. Arch esetén hivatalos tárolóban van.
-
vargalex
félisten
válasz
samujózsi #29000 üzenetére
Olyannal már találkoztam wifi esetén, hogy a routeren valami energiagazdálkodás miatt viszonylag sok idő kellett, hogy "észbekapjon". A jelenség az volt, mint nálad, URL-t megnyitva néhány másodpercre megállt, majd elkezdte a betöltést. Ilyenkor azt vettem észre, hogy a wifi kliensen (azaz a notebook-on) folyamatos ping-et futtatva (pl. index.hu-ra) megszűnt ez a jelenség. De ez kliens független volt.
-
vargalex
félisten
válasz
Jim Tonic #28656 üzenetére
Nekem az első összerakott home serveremnél ment ennyivel...
-
vargalex
félisten
De, de megoldható, hogy ne így legyen.
-
vargalex
félisten
válasz
togvau #28525 üzenetére
Igaz, hogy sikerült pont olyan részleteket átküldened, amiben nincsenek egyezések. Így csináltam azonosakat. A dupes.txt-t nem módosítottam, a filelist a következő lett:
[gavarga@gavarga-e5540 test]$ cat filelist
0b0d915f1c33b3977d1d93c39f74cfce film/American.Pie.1999.BDRip.x264.HuN-Nimphas/Sample/sample.mkv.part
6b19e41621e1c6b31e2ff1caac3474f9 film/American.Psycho.2000.720p.BluRay.DTS.x264.HuN-TRiNiTY/trinity-american.psycho.720p.mkv
dd3186dd0e3e952f9150d7d6bd407e76 barmi
9193775624021bdea72d5ddcc45b8b21 film/American.Psycho.2000.720p.BluRay.DTS.x264.HuN-TRiNiTY/trinity-american.psycho.720p.nfo
ecdc8cc1401bebc0c6654abd48f08000 akarmi
bd1e39658b19e1fc879949585d1d758d film/American.Psycho.2000.720p.BluRay.DTS.x264.HuN-TRiNiTY/trinity-american.psycho.720p.sfv
És láss csodát, tökéletesen működik:
[gavarga@gavarga-e5540 test]$ join -i <(sort -k 1b,1 dupes.txt) <(sort -k 1b,1 filelist)
dd3186dd0e3e952f9150d7d6bd407e76 barmi
ecdc8cc1401bebc0c6654abd48f08000 akarmi
De akár a sort kapcsolói nélkül is:
[gavarga@gavarga-e5540 test]$ join -i <(sort dupes.txt) <(sort filelist)
dd3186dd0e3e952f9150d7d6bd407e76 barmi
ecdc8cc1401bebc0c6654abd48f08000 akarmi
-
vargalex
félisten
válasz
ubyegon2 #28440 üzenetére
Speciel Arch Linux alatt AUR-ból telepíthető. Persze a "de minek" itt is érvényes.
-
vargalex
félisten
válasz
Mr Dini #28169 üzenetére
Szervert általában nem rak ki közvetlenül a netre az ember (mondjuk desktopot sem). Van előtte egy tűzfal, pont ezért az alap config-ban minden engedélyezett szokott lenni, minek okozzon felesleges terhelést. Még egy tűzfalnak akkor van értelme, ha a saját hálózatodban/hálózatod tűzfalában sem bízol meg.
-
vargalex
félisten
-
vargalex
félisten
válasz
bambano #27875 üzenetére
"ez elméletben így van, gyakorlatban pedig a torrenthez rendszerint előírják a feltöltést is, tehát natolt hálózatban szinte mindenki portforwarddal állítja be a torrent kliensét. Ezért a tracker is meg tudná szólítani a klienst.": gyakorlatban vannak olyan szolgáltatók, aki privát IP-t adnak az előfizetőnek, ott biztosan nem lesz semmilyen port forward beállítva. Mégis tud le/feltölteni a korábban általam írt módon.
"de te egy rendes, jogkövető gyerek vagy, nyilván nem tudod az ilyen részleteket a torrentről": ez így igaz, szigorúan csak linux distrokat töltök le, így a protokolltól tudhatok ezt-azt.
-
vargalex
félisten
válasz
bambano #27872 üzenetére
A tűzfalon alkalmazott reject a kezdeményező oldalon detektálható, hiszen a válasz egy reject lesz, míg drop esetén nincs válasz. Erre próbáltam utalni. Mondjuk pont ezért szokták mondani, hogy inkább drop-ot érdemes alkalmazni, hiszen akkor a "támadó" nem tudja biztosan, hogy az adott IP címen valóban van-e valamilyen eszköz, míg reject esetén ebben biztos lehet.
NAT-olt hálózatban a torrent csak passzív módban működik, azaz a kliens tud kapcsolatot kezdeményezni egy nem NAT-olt hálózatban lévő másik klienssel. Míg aktív esetben őt közvetlenül meg tudják szólítani. Igaz ez a tracker-re is. Ő nem tudja megszólítani a klienst (hogy tudná szerinted?), csak a kliens tud infót küldeni neki, esetleg socketet nyitni, amin persze jöhet vissza irányú adat is, amíg nyitva van. De jellemzően nem TCP-n történik az adatforgalom...
-
vargalex
félisten
válasz
s1999xx #27869 üzenetére
Lehet, hogy az alkalmazás is hibásan van megírva, előfordulhat, hogy a REJECT-ből inkább rájönne. Valamint a trackertől veszi az infót, az pedig kérdés, hogy a tracker mennyi idő után mondja egy kliensről, hogy nincs ott (nyilván attól is függ, hogy a kliens mennyi időközönként közöl infót magáról a trackerrel).
A szerver oldali ellenőrzés nem mindig megvalósítható, ugyanis lehet, hogy a kliens egy NAT-olt hálóban van, így kívülről nem is elérhető...
-
vargalex
félisten
válasz
bambano #27093 üzenetére
A kerberos-nak pedig az LDAP protokollhoz nincs sok köze. Az egyik egy authentikációs protokoll, a másik pedig egy címtár hozzáférési protokoll. Az biztos, hogy az ldap binding, ldap auth, ldap search, stb. megy az AD-nál is szabványos eszközökkel. Az egy dolog, hogy van Kerberos authentikáció (is).
Szóval, abban egyetérthetünk, hogy nem az LDAP-ot magát, hanem az MS által alkalmazott titkosított authentikációs protokollt reverse engineeringelték...
Eddig sem írtam mást... -
vargalex
félisten
válasz
Frawly #27087 üzenetére
Most nem azért, de az LDAP egy MS független protokoll, egyáltalán nem reverse engineering-el készült. A szabványos elérés miatt csinált az MS LDAP API-t is az AD-hez. De máshogy is elérhető a címtár. Vagy ti LDAP alatt általában a címtárakat értitek? Ilyen értelemben sincs köze egymáshoz az OpenLDAP/Novell eDirectory/stb. megvalósításoknak az AD-hez... Annyi, hogy mindegyik egy címtár.
-
vargalex
félisten
válasz
Frawly #26889 üzenetére
Nem tudom mennyire hihető, de nálam mindkét notebook-on, illetve a home szerveren is normálisnak tűnő feszültség értékeket mutat az lm_sensors. Sőt, most a home szerverben az Asrock Q1900-ITX helyet átmenetileg egy Asrock E350M1 van, ott is sokminden látszik:
k10temp-pci-00c3
Adapter: PCI adapter
temp1: +62.9°C (high = +70.0°C)
(crit = +90.0°C, hyst = +87.0°C)
nct6775-isa-0290
Adapter: ISA adapter
Vcore: +1.32 V (min = +0.00 V, max = +1.74 V)
in1: +0.93 V (min = +0.00 V, max = +0.00 V) AL
RM
AVCC: +3.44 V (min = +2.98 V, max = +3.63 V)
+3.3V: +3.44 V (min = +2.98 V, max = +3.63 V)
in4: +1.42 V (min = +0.00 V, max = +0.00 V) AL
RM
in5: +1.81 V (min = +0.00 V, max = +0.00 V) AL
RM
in6: +1.70 V (min = +0.00 V, max = +0.00 V) AL
RM
3VSB: +3.44 V (min = +2.98 V, max = +3.63 V)
Vbat: +3.39 V (min = +2.70 V, max = +3.63 V)
fan1: 0 RPM (min = 0 RPM, div = 128)
fan2: 3515 RPM (min = 0 RPM, div = 8) ALARM
fan3: 0 RPM (min = 0 RPM, div = 128)
fan4: 0 RPM (div = 128)
SYSTIN: +53.0°C (high = +0.0°C, hyst = +0.0°C) AL
RM sensor = thermistor
CPUTIN: +51.5°C (high = +80.0°C, hyst = +75.0°C) se
sor = thermistor
AUXTIN: -11.5°C (high = +80.0°C, hyst = +75.0°C) se
sor = thermistor
cpu0_vid: +0.000 V
intrusion0: ALARM -
vargalex
félisten
Szia!
Chromium-ban megpróbálhatod a 3D gyorsítás erőltetését.
Ahogy a linken olvasható, szükség lehet a
--enable-native-gpu-memory-buffers
kapcsolóra. Illetve szerintem ezen kívül elkelhet még a--enable-features="CheckerImaging"
és a--disable-gpu-driver-bug-workarounds
kapcsolók használata. Ezen kapcsolókat állandóvá is teheted. -
vargalex
félisten
Két ugyanolyan kártya nem feltétlenül pontosan azonos méretre, ezért is kérdeztem.
LE esetén van egy csak olvasható squashfs image az első FAT32-es partíción, amit loop device-ként a /-be mount-ol. És valóban, ezért nem tudod módosítani. A config-okat viszont a második (ext4) partíción tárolja, ezeknek át kell menniük dd-vel. Hacsak első induláskor nem érzékeli hibásnak a partíciót, így formázza. Ezért is kérdeztem a méretet...
-
vargalex
félisten
válasz
Neil Watts #25171 üzenetére
Szia!
Szerintem a titkosítás elviszi a CPU erőforrást (gondolom 1 magot 100%-ban, mivel 1 szálon megy). Nézz közben
top
kimenetet, úgy több kiderül. -
vargalex
félisten
válasz
bucihost #25046 üzenetére
Szia!
Fel kell venned a default-ot is (pl. servername nélkül). Itt olvashatod:
"If no matching ServerName or ServerAlias is found in the set of virtual hosts containing the most specific matching IP address and port combination, then the first listed virtual host that matches that will be used."
-
vargalex
félisten
Van az alaplapon is tüskesor az USB2-nek, illetve USB3-nak. De az nincs kivezetve. A hátlapi USB- be csatlakoztatva viszont működnek az eszközök, ahogy írtam. Sebességet majd alkalomadtán nézek, mert kell szereznem egy PS/2 billentyűzetet. Mert most az USB-s nem játszik.
Dmesg-ben ezzel kapcsolatban annyi van, amit bemásoltam.
Tápot majd még megnézem, mert nem vagyok biztos a PicoPSU-ban... Mondjuk, ha a CPU-nak elég, nehogy kevés legyen már az USB-nek. Persze az egyik 5V-os ág lehet akár hibás is. Azzal nem vagyok tisztában, hogy valamelyiket csak az USB vezérlő kapja-e.
Most kaptam garis cserében a lapot, így ismét van 3 év garim. Viszont mivel igazából működik, visszavinni nem akarom, mert bevizsgálják, majd azt mondják, hogy jó és még én fizethetek... -
vargalex
félisten
Sziasztok!
Még mindig a kis Asrock Q1900-ITX miniPC, Arch Linux-al. Visszakerült a helyére, viszont az a furcsaság van, hogy ha nem fut igazából semmilyen szolgáltatás (na, jó, az sshd-t nyilván nem tiltottam le), akkor is 1-es fölött van a load. A top kimenetében az látszik, hogy a kworker és a ksoftirqd összesen folyamatosan 30% körül eszi az egyik magot:
95 root 20 0 0,0m 0,0m 17,2 0,0 0:47.50 D kworker/0:1
3 root 20 0 0,0m 0,0m 12,6 0,0 0:37.31 S ksoftirqd/0Mitől lehet ez? A korábbi Q1900-ITX-el ilyen problémám nem volt. Lehet, hogy összefügg ezzel (és a korábbi példány szintén nem produkálta) az az, hogy boot-kor USB hibákat látok, pedig nincs is USB-s eszköz csatlakoztatva:
[ 0.991389] usbcore: registered new interface driver usbfs
[ 0.991420] usbcore: registered new interface driver hub
[ 0.991471] usbcore: registered new device driver usb
[ 1.354093] usb 1-1: new low-speed USB device number 2 using xhci_hcd
[ 1.517716] usb 1-1: device descriptor read/64, error -71
[ 1.781358] usb 1-1: device descriptor read/64, error -71
[ 1.991611] usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd
[ 2.164795] usb 1-1: new full-speed USB device number 3 using xhci_hcd
[ 2.485771] usb 1-1: new low-speed USB device number 4 using xhci_hcd
[ 2.486301] usb 1-1: Device not responding to setup address.
[ 2.690117] usb 1-1: Device not responding to setup address.
[ 2.892788] usb 1-1: device not accepting address 4, error -71
[ 3.053072] usb 1-1: new high-speed USB device number 5 using xhci_hcd
[ 3.233273] usb 1-2: new high-speed USB device number 6 using xhci_hcdLTS kernellel nem látszik a top-ban, hogy nagyon enné a kworker és ksoftirqd, de ugyan úgy 1-es a load.
Mi lehet a gond? Én kezdek hardware hibára is gyanakodni. Ugyanakkor az USB-s eszközet (pendrive-ot, logitech receivert próbáltam) felismer, illetve természetesen használható is bármelyik portra csatlakoztatva.
Szerk.: BIOS-ban letiltottam az USB-t és így normalizálódott. Lehet, hogy nem foglalkozom vele, úgyis csak szerver.
-
vargalex
félisten
válasz
Tóniszomszéd #24531 üzenetére
Szia!
Bocs, a bootloader újrahúzása mégis megoldotta. Köszi!
-
vargalex
félisten
válasz
Tóniszomszéd #24529 üzenetére
Azt elfelejtettem írni, hogy a bootloadert már újratelepítettem chroot alatt. Igaz, ez systemd-boot esetén csak másolás (de szerintem a többinél is).
-
vargalex
félisten
Sziasztok!
Számomra egy furcsa problémával fordulok hozzátok. Van egy mini szerverem Asrock Q1900-ITX alaplappal. Egy SSD-n a rendszer (Arch Linux) UEFI módban (korábban gummiboot, majd később systemd-boot bootloaderrel - tudom, miért pont ez...). Az adatok 2 db 2,5" HDD-n RAID0-ban (a tárhely mérete és a sebesség volt a lényeg). Tökéletesen működött 2014 óta egészen július végéig. Szakadó eső/villámlás volt nálunk, kiment a házban az egyik biztosíték is (éppen az a kör, ahova a kis szerver is volt dugva) és az alaplap elhalálozott. Lehet, hogy nem volt összefüggés a kettő között, ezt nem tudom. De ez lényegtelen. Mivel az alaplapon semmi sérülés nem látszott és még garanciális, így "pofátlanul" visszavittem az üzletbe. Bevizsgálták, visszaküldték a gyártónak (legalábbis ezt mondták) és nagyjából 1 hónap átfutási idő múlva kaptam egy új példányt.
Nyilván ugyan azt a rendszert használnám, de ez az alaplap nem látja az SSD-n az EFI partíciót (az SSD-t természetesen igen), így nem is boot-ol róla (a BIOS boot menüjében csak az eszköz látszik, az UEFI partíció nem). A SATA vezérlőket AHCI módba állítottam, próbáltam a SATA II, illetve a SATA III portokat is. Kivettem a notebookomból a HDD-t, azon sem látja (szintén Arch Linux systemd-boot-al). A notebook tökéletesen bootol az SSD-vel is.
Frissítettem BIOS-t is, nem segített.
Ugyanakkor egy pendrive-ra kiírva az Arch telepítőt bootol legacy és UEFI módban is (a BIOS-ban a boot eszköz választásakor látja is az UEFI partíciót).
Találkozott már valaki ilyennel? Mi lehet a probléma? Lehet úgy hibás az alaplap, hogy ilyet produkáljon? Most vigyem ezt is vissza?Bocs, hogy kicsit hosszúra sikeredett...
-
vargalex
félisten
válasz
Mr Dini #24396 üzenetére
Szia!
Valakinek biztosan sikerült, hiszen az OpenWrt repo-ban megtalálható minden platformra. Kiszedhetnéd az armv5-ös binárist az OpenWrt csomagból, vagy akár az arch linux arm csomagból is. Persze az utóbbi nem biztos, hogy uClibc-vel fordult. Vagy mindenképpen az eszközön akarod fordítani?
Szerk.: Bocs, OpenWrt esetén is valószínűleg régebbi repo-ban (pl. AA) kell szétnézni, mert a CC már musl-al megy szerintem.
-
vargalex
félisten
válasz
Mr Dini #24387 üzenetére
Igazán nincs mit!
Azért nem találod ezeket a leírásokban, mert ennek már semmi köze a virtualbox-hoz. Az, hogy a guesten milyen filerendszert használsz, rajtad (és az os-en) múlik. Az pedig, hogy azt hogyan lehet átméretezni (vagy egyáltalán lehetséges-e) magán a filerendszeren.
Lvm méretezésről pl. itt olvashatsz. -
vargalex
félisten
válasz
Mr Dini #24385 üzenetére
Ja, hogy lvm-ed van. Akkor előtte az lvm partíciót kell kihúzni:
sudo lvresize -L +40G /dev/mapper/KStudio--vg-root
vagy ha méretet akarsz megadni, csak 100% méretűre kihúzni:
sudo lvresize -l +100%FREE /dev/mapper/KStudio--vg-root
majd jöhet a
sudo resize2fs /dev/mapper/KStudio--vg-root
-
vargalex
félisten
iptables-re gondolsz? Ha igen, akkor az iprange match extension-el.
Vagy több CIDR-el:
A.B.C.172/30
A.B.C.176/29
A.B.C.184/30
A.B.C.188/31
A.B.C.190/32 -
vargalex
félisten
válasz
Mr Dini #24148 üzenetére
Én utoljára egy Seagate GoFlex net-et használtam, ami szintén kirkwood SoC-al volt szerelve. Ahhoz készítettek egy olyan u-boot-ot, ami képes USB-s, vagy SATA-s eszközről boot-olni. A gyári sajnos nem tudott, nyilván itt is az a helyzet. De mondjuk a gyártónak nem is áll érdekében, hogy ilyet készítsen.
Esetleg próbáld meg, hogy a RAM végébe töltöd soros porton a kernelt, majd módosítod a paramétereket úgy, hogy onnan töltse be.
De valahogy biztos lehet USB-ről boot-olni, hiszen az Arch Linux telepítése is így indul. -
vargalex
félisten
válasz
Mr Dini #24134 üzenetére
Bocs, most vettem észre, hogy elírtam. Helyesen: su-val root shell-t kapsz. A sudo-t úgy írtam, ahogy te is: más user (jellemzően valóban root) jogosultságaival futtatsz parancsokat.
A nagy különbség még, hogy előbbi esetén tudnod kell a root jelszót, utóbbinál csak az user-ét. -
vargalex
félisten
válasz
Mr Dini #24026 üzenetére
A startssl.com is teljesen jó.
-
vargalex
félisten
válasz
gt7100 #23984 üzenetére
Én a CPU terheltségből azt gondolom, hogy azért, mert nem (vagy nem olyan erős tömörítést használ). Ha -z (vagy --compress) kapcsolóval rsync-eztél, akkor tömörített, ha nem, akkor nem.
Persze, ahogy a fentebbi példám is mutatja, még tömörítés mellett sem indokolt olyan kis sebesség, amit írtál. Nálam ugye elvileg picit erősebb a CPU, de ahogy írtam, tömörítéssel is tudott 12 MB/s környékén.
Most gyorsan megnéztem kábelen is. Az eredmény:SCP tömörítés nélkül: 60 MB/s
SCP tömörítéssel: 11.6 MB/sAzaz tömörítésnél már valóban a CPU volt a szűk keresztmetszet wifi esetén is.
-
vargalex
félisten
válasz
gt7100 #23982 üzenetére
Szia
Ha -C kapcsolóval másoltad, akkor ugye jóval magasabb a CPU terhelés a tömörítés miatt. Most kipróbáltam, nálam egy J1900 van használatban. Wifi-n másoltam, akár tömörítéssel, akár nélküle 12 MB/s körül ment a másolás. Viszont, amíg tömörítés nélkül a wifi volt a szűk keresztmetszet (a J1900-on 1 mag 16-18%-ra terhelt), addig tömörítéssel a CPU is, mivel 1 magot 100%-ra kihajtott. Szóval, ha nem tetted, akkor próbáld meg -C nélkül.
-
vargalex
félisten
válasz
LógaGéza #23953 üzenetére
Szia!
Ezt tipikusan virtualhost-al szokták megoldani. A virtualhost-ok ServerName-ját is felveszed CNAME-ként ugyan arra a ddns-re mutatva.
-
vargalex
félisten
válasz
Jim Tonic #23943 üzenetére
Szia!
Elvileg csak erről a két helyről kell kiszedni.
De használhatsz akár (egy, vagy több) USB-serial eszközt is. -
vargalex
félisten
Minden további nélkül:
[gavarga@gavarga-e5540 test]$ ls -la
összesen 4
drwxr-xr-x 2 gavarga gavarga 6 ápr 14 17.08 .
drwxr-xr-x 23 gavarga gavarga 4096 ápr 14 17.08 ..
[gavarga@gavarga-e5540 test]$ ln -s forras cel
[gavarga@gavarga-e5540 test]$ ls -la
összesen 4
drwxr-xr-x 2 gavarga gavarga 16 ápr 14 17.08 .
drwxr-xr-x 23 gavarga gavarga 4096 ápr 14 17.08 ..
lrwxrwxrwx 1 gavarga gavarga 6 ápr 14 17.08 cel -> forras -
-
vargalex
félisten
válasz
bambano #23728 üzenetére
Szia!
Ha böngészőben jelenik meg, akkor az webes. Hacsak nem valami ActiveX, de akkor nem menne csak windowson (esetleg csak IE alatt). A cookie-kkal jó irányba mész, de szerintem curl-al könnyebben megoldható és többre is képes, mint a wget. Nincs valami demo oldal, mert az oldal ismerete nélkül nehéz bármit is mondani (én nezegetném a böngésző developer tool-jában/firebug-ban a hálózati forgalmat, abból minden kiderül).
Új hozzászólás Aktív témák
Hirdetés
- RÉSZLETRE , Bankmentes , kamatmentes Asus Rog Zephyrus G16
- Frederick Forsythe: Isten ökle (nem olvasott)
- Honor 9X Lite 128GB, Kártyafüggetlen, 1 Év Garanciával
- LG 55G3 - 55" OLED evo - 4K 120Hz 0.1ms - MLA - 2000 Nits - NVIDIA G-Sync - AMD FreeSync - HDMI 2.1
- Bomba ár! HP EliteBook 840 G2 - i5-5GEN I 8GB I 256GB SSD I 14" HD+ I Cam I W10 I Garancia!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged