RAM-hiba hátráltatja Linust a kernelkarbantartói munkájában

Kernel

Linus egy, az LKML-re küldött válaszlevelében felfedte, hogy az AMD Threadripper processzoros fő fejlesztői desktop gépét RAM-hiba sújtja néhány napja, ezért a beolvasztási munkákat jelenleg az Apple M2 processzoros gépén végzi, így nagyon lassan halad a várakozási sorában levő patchek feldolgozásával.

Pár napja arra lett figyelmes, hogy a felhasználói térben (user space) véletlenszerűen felbukkanó memóriakorrupciók miatt az allmodconfig kernelfordításai véletlenszerűen elhaltak a fordítóprogramban előjövő belső hibák miatt. Először a beolvasztási időablakban bemutatkozó új bugra (ami azért elő szokott fordulni) gyanakodott, de most nem ez volt a helyzet.

Egy régi kernel bootolásával és egy éjszakát átölelő Memtest86+ futtatásával sikerült igazolni, hogy hibás RAM modul(ok) okozzák a véletlenszerű fordítási hibákat. A RAM-ok 2,5 éven keresztül hibátlanul tették a dolgukat, eddig.

Linus megrendelte az új modulokat, amelyek kiszállítás alatt vannak, így várhatóan hamarosan visszatérhet az új kernel fejlesztése a megszokott kerékvágásba.

Részletek Linus levelében.

kesleltetes, DDR4 3200 a proci nevleges savszelesege ugyhogy min ennyi kene.

A linkelt RAM CL16 kent van hirdentve, van ilyen vagy jobb ECC -vel ?

Nem ECC elmegy 3600Mhz/CL14 ig is.
https://www.alza.cz/EN/g-skill-32gb-kit-ddr4-3600mhz-cl14-trident-z-neo…

ECC -bol CL22 a gyakori.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az ECC modulok nem pont erre vannak kihegyezve, a registered verziók meg pláne nem. Egyrészt amit egy szerver memó tud, azt a szabvány 1.2V-on tudja, és nem 1,35 vagy 1,45V-on, másrészt sávszélben gondolkodnak.

Amit hirtelen találtam micronéktól az CL22-es, és speciel outofstock: https://store.supermicro.com/16gb-ddr4-3200-mem-dr416l-cv03-eu32.html

Sima ECC 2933-as CL21, nem meglepő módon.

A harmadik szempont, hogy adott gyártó igényéhez igazítódnak, nincsen végtelen számú opció, mint gamerfronton. Egyébként a Crucialnál nézted, hogy hátha gyártanak valami jófélét?

Node ott nem is lesz neked 3600MHz-ed. Aszondja: https://www.gskill.com/specification/165/326/1562839114/F4-3600C14Q-32G…

"SPD Speed (Default) 2133 MT/s"

Ez tippre 2133MHz-et jelent, bár arról nem szólnak, hogy a CL16 hol lesz szerintük. A helyzet tényleg az, hogy van késleltetés kell, és akkor kisebb a sávszél, vagy sávszélt szeretnél. Ha a kettő együtt, akkor jön a feszkóemelés, meg a plusz fogyasztás, és 24/7-es üzemet tekintve sérülő üzembiztonság.

Ráadásul az alza 1.45V-ot, a gyártó 1,4V-ot ír, bár még az is lehet, hogy nem tökéletesen ugyanaz a típus.

"Intel XMP 2.0 (Extreme Memory Profile) Ready"

Be kell kapcsolni biosban akkor lesz hirdetett nagyobb mode.

Ez a CL16 1.2V on

https://www.memorybenchmark.net/ram.php?ram=Crucial+Technology+BLS16G4D…

vagy ez
https://www.alza.cz/EN/kingston-fury-64gb-kit-ddr4-3200mhz-cl16-beast-b…

szerk:
itt 1.35 V -nek irjak az elsot:
https://www.servertechsupply.com/bls16g4d32aest/
memorybenchmark.net irta 1.2V -nak.

adatlap 2x32GB hez:
https://www.kingston.com/dataSheets/KF432C16BBK2_64.pdf

Hmm, ez tenyleg novel voltot, a hirdetet nagyobb sebbesghez.

1.35V, ECC az mar DDR5.

Szoval ha 1.2V  DDR4 en nincs ilyen sebesseg, akkor felejtos az ECC valtozat ?

Azt ertem hogy serverbe, nem feltetlen akkarnak 1.2V  fele menni, de vannak workstation -ok is,
ahol mar el szokas menni teljestimeny fele a fogyasztas rovasara..

JEDEC enged 20CL -t 3200MT/s -en.
https://en.wikipedia.org/wiki/DDR4_SDRAM

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

DDR5 ECC helyzet jobban nez ki, mar ha ez igazi ECC ;-)
https://assets.website-files.com/5cdb2ee0b102f96c3906500f/6244ba18dde51…
https://www.alza.hu/patriot-viper-venom-32gb-kit-ddr5-6200mhz-cl40-d715…

"Unlike DDR4, all DDR5 chips have on-die ECC, where errors are detected and corrected before sending data to the CPU."

Akkor a kereso miert irta tobbire hogy nem ECC, erre meg hogy igen.
"There still exist non-ECC and ECC DDR5 DIMM variants; the ECC variants have extra data lines to the CPU to send error-detection data, letting the CPU detect and correct errors that occurred in transit"

DDR5 ugyan az a kutya lesz, vagy tuning vagy ECC amit vehetsz ;-(

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

ahogy olvastam, a ddr5 on-die az inkább olyan, mint a háttértáraknál a hibajavítás... ahhoz kell, hogy ne csak tökéletes példányt árulhassanak, jobb legyen a kihozatal. Aztán lehet, hogy egyébként is jót tesz...  de így nem kell tökéletesnek lennie minden chipnek, hanem belefér kis hiba, ami kifelé nem látszik, hanem a chip mindig korrigálja. A normál értelemben vett ecc továbbra is külön lesz.

Eleg nagy bunkosag volt ECC -nek hivni ill. reklamozni.

Ugy nez ki hogy ECC memorianal van hogy lehet feszultseget emelni es overclockolni:
https://www.reddit.com/r/Amd/comments/6ze285/overclocking_ecc_memory_fo…

Mar csak az kell hogy valaki megsugja melyik modulon vannak a jo chippek ;-)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

CL18-ig mentek a memoriak a szabvanyos feszultsegen 3200MHz-en, aztan jott egy technologiai "fejlodes", onnantol volt ugyan CL16, de vagy 2400MHz-en megy szabvanyos feszultsegen, vagy megemelt feszultsegen 3200MHz-en. illetve vannak CL22-es memoriak amik a szabvanyos feszultsegen mennek 3200MHz-en. ebbol valaszthatsz, vagy esetleg hasznaltan tudsz venni regebbit. nalam mindharom fele van sajnos, en szivesen maradtam volna CL18-on.

neked aztan fura humorod van...

https://www.synopsys.com/designware-ip/technical-bulletin/error-correct…
For every 128 bits of data, DDR5 DRAMs has 8 additional bits for ECC storage.

Ez tenyelg ECC.
Kozmikus sugarzas ellen mar ez is ved, buszon levo hibakotol nem.
Szerintem nekem eleg lehet.

Ebbol szervezodesbol arra gondolnek hogy 128 bitnel kisebb adatmozgasra nem szamitanak, ami 16 bitten egy Burst 8, 32 bitten burst 4.
ddr5 ujdonsag burst length 16  tamogatas.

Ha tenyleg 100% hibas bittek elfedes miatt van benne az ECC, akkor viszont a kozmikus sugarzas ha rosz helyre jon akkor para van.
Ha gigabitenkent <~64k bit full hibas meg minidg 100-ad akkora az esely arra hogy a menyko hibat okoz.
Ebbe nincs bele szamolva, hogy ddr5 -nek valoszinuleg kisebb menyko is bitflippet okoz, mint ddr4 -nel.

Kerdes, ddr5 chip megmondja -e mikor volt on-die ECC esemeny ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Second, on-die ECC does not signal
an error-correction event or report error syndromes"

https://arxiv.org/pdf/2009.07985.pdf

"We use BEER to identify the ECC functions of 80 real
LPDDR4 DRAM chips with on-die ECC from three major
DRAM manufacturers."

Ez meg ddr5 elotti cikk, on-die ECC ezek szerint volt elotte.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"1.35V, ECC az mar DDR5."

az "nem igazi ecc" .

DDR5 6400 1.1V talan mar most standard, varhatolag 7200 1.1V az lesz valamikor.

7200 1.4V  high end gamer ramkent van jelenleg, 2025 -re varhato hogy alacsonyabb feszultsegen kaphato legyen.
https://www.tomshardware.com/news/samsung-talks-1tb-ddr5-modules-ddr5-7…
https://www.tomshardware.com/news/teamgroups-speedy-ddr5-7200-c34-ram-h…

6400 -ra fel lehet huzni az AM5 -s rendszereket,  nevlegesen ez alatt vannak jelenlegi procik.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

PS. And yes, my system is all set up for ECC - except I built it
during the early days of COVID when there wasn't any ECC memory
available at any sane prices. And then I never got around to fixing
it, until I had to detect errors the hard wat. I absolutely *detest*
the crazy industry politics and bad vendors that have made ECC memory
so "special".
 

tl;dr: ECC-t szokott használni, de a COVID-alatt, amikor a gépet építette, hiánycikk volt, legalábbis értelmes áron. 

trey @ gépház

Megfigyelésem alapján minél több pénze van valakinek, annál jobban megnézi hogy mire mennyit költ.

Az hogy megtehetné hogy elcsűr egy raklap pénzt egy éppen akkor az egekbe árazott RAM-ra, de mégsem teszi, nem kifogás, hanem racionális viselkedés. Dolgozni tudott vele ugyanúgy. Eddig. :)

Exactly.

A tehetős emberek általában nem úgy lesznek tehetősek, hogy irgalmatlanul sok pénzük van, és ezt két kézzel szórják, és még ennek ellenére is sok marad, hanem úgy, hogy jól megfontolják, hogy mire költsenek - így marad bőven. (az első verzió is létezik persze: ők azok a fogalmatlan arcok, akikre eleinte hull a pénzeső - aztán amikor eláll a pénzeső, akkor ott maradnak letolt gatyával)

Vagyont több generáció alatt lehet legegyszerűbben építeni.

Feltéve, ha nem jön közbe háború, padlássöprés, népirtás, üldöztetés, államosítás. Ez a baja K-Európának, azért nincs sokaknak vagyona, mert nem éppen békések a körülmények ahhoz, hogy több generációra előre lehessen tervezni.

Jogos, de:

  1. A vagyonépítésnek nemcsak az a része, hogy az n. generáció vagyona mindig több legyen, mint az n-1 generációé. Simán lehet, hogy több generációra nézve jobb volt üres zsebbel disszidálni, és ebből következik a második:
  2. Nem sikerül mindenkinek vagyonosnak lennie, több generáció alatt sem, csak jobb esélyei vannak, mintha csak a saját életedben kellene megoldani.

Semmi gond, akkor most pótolja. Egyébként meg szerintem elég ritka, ha RAM csak úgy tönkremegy. Ha túl van hajtva, vagy túlmelegszik, vagy túl öreg (8-10 éves kor fölött, mikor más ált. sulis), akkor előfordul. Legrosszabb és legritkább esetben a prociban lévő memóriavezérlő is hibázhat, azt még drágább mulatság lecserélni, mármint az egész proci megy ilyenkor a kukába. Szerintem még pénzébe sem kerül, ha tényleg csak RAM-csere, alig pár éves modulok, még garanciásoknak kéne lenniük.

Egyébként abban nincs igaza, hogy az ECC memóriának alapnak kéne lennie. Átlag usernek csak drágítaná a memóriát. Nem azt mondom, hogy nem lenne haszna, ha alap feature lenne, de nem annyira kritikus, mint azt néhányan a saját speciális felhasználásuk mentén beállítják. Ha jól tudom, DDR5-ben már van egyfajta hibakezelés, a nem ECC-s verzióban is, igaz kapható ECC is belőle. Ez van, az ECC mindig is prémium volt. AMD engedi már néhány éve a legtöbb asztali Ryzen-nél is, de a memória továbbra sem olcsó hozzá.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Annak idején a Windows Vistánál majdnem alapkövetelmény lett, legalább is ajánlott, mondjuk nagyobb probléma volt szerintem a sok Via meg SiS szutyok, (bár, ha a gyártó megeröltette magát, akkor jó lapok is voltak ilyen chipsettel, és sok gyengus RAM is forgott a kiskerben. Tudom a Vista szutyok volt ( amíg meg nem jelent az SP Win7 néven :) ) de gondolom, nem akarták, hogy a drivergondok mellett még hibázó RAM miatt is lehúzzák a "népszerűségét"

( azbest | 2022. 10. 11., k – 09:09 )

Hm, teljesen megértem, hogy nem akar felfújt áron venni ramot... mondjuk otthonra, privát használatra. De munkára? 

Rajtam nem múlik a fél világ sokmilliárdos üzlete, mégis volt mindig használható tartalék gépem munkához... sőt, általában kettő azonos vagy közel azonos gépem szokott lenni, hogy szükség esetén könnyű legyen a váltás vagy alkatrészforrás legyen kéznél. 

Közben rákerestem, hogy is van ez az ecc ddr5-nél, mert több helyről hallottam, hogy alapból lesz bennük valamilyen ecc. Viszont most úgy látom, hogy valójában az "on-die-ecc" csak arra szolgál, hogy gyártáskor ne kelljen kidobniuk a kicsit bizonytalanabb chipeket sem, hanem a háttértárakhoz hasonlóan belefér némi hiba, elfedi a chip korrekciója. Ami végülis jó, de nem helyettesíti a rendes ecc-t. 

Nem értem a rantodat. Semmilyen milliárdos üzlet nem múlik azon, ha Linus egy héttel vagy akár hónappal később release-el egy kernelt. Számtalanszor tolja el akár egy-két héttel is a release-t. Saját belátása szerint alakítja a kiadási ciklus végét. Általában 7 prerelease-t (-rc kernelt) csinál, de akkor sincs baj, ha 8 vagy több lesz. Tehát semmi sem múlik azon, ha 1-2-3 hetet csúszik egy új stable kernel kiadása. Semmilyen elvárás nincs felé.

Ráadásul, itt most nem egy stable kernel kiadása a soron következő, hanem a merge window lezárása. Ezzel a kis közjátékkal együtt is benne van, hogy simán tudja tartani megszokott kiadási ciklus időt. De mivel semmilyen kényszere nincs erre, akár el is tolhatja.

Mondd, szerinted milyen milliárdos üzlet múlik azon, ha a következő stable kernel mondjuk 1 héttel, vagy hónappal később kerül a kernel.org-ra?

trey @ gépház

szimplán csak arról van szó, hogy munkához kell legyen munkaeszköz. Vállalkozás szinten filléres tétel, több évente egyszer költ ilyenre. Egyébként sem túl jó, ha egy emberen múlik a teljes cég működése.

Linusnak értem, hogy ez mindegy, de akik új kernel verzióra várnak, hogy újabb hardverek támogatását megkapják, számítógépgyártók, na azoknak nem mindegy.

de akik új kernel verzióra várnak, hogy újabb hardverek támogatását megkapják, számítógépgyártók, na azoknak nem mindegy.

Egyrészt, kérjék vissza a pénzüket. Másrészt, ha ennyire fontos/gyártók/stb. akkor küldjenek ECC RAM-ot Linusnak. Harmadrészt, említettem, hogy ettől a kiadási dátum nem feltétlen változik.

trey @ gépház

Privát használatra is simán megengedhetne magának akármennyi RAM-ot, akár négyszeres áron is. Nem magyar fizetésből él. Adományban is kapna, ha kérné, vagy ha vesz, mivel munkára használja, szerintem még az adóból is leírhatná. Főleg ilyen 32-64 gigányi nem tétel, 4 modulosával sem (hogy kihajtsa quad channelben a Threadripper), annyit simán én is kifizetnék, ha szükségem lenne annyi RAM-ra, pedig nem vagyok gazdag, és annyi kernelfejlesztéshez elég. De még 128 giga sem annyira húzós, 250-350 USD között megy most az amerikai eBay-en, valami normális, akciósabb PC-s boltban tuti olcsóbban is van.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( STP | 2022. 10. 11., k – 14:40 )

Nagyobb gáz lenne, ha a Rum hátráltatná.

( Csab | 2022. 10. 11., k – 16:50 )

Szerkesztve: 2022. 10. 11., k – 16:50

Csak nekem tűnik irreálisnak a sztori, hogy Linus gépe lefagy, ezért nincs új kernel release?

Nem tudott volna kölcsönkérni egy másik gépet?

 

Kb. olyan, mintha nem tudnék dolgozni menni, mert a portásnak elfogyott a cigije és dühében nem nyitja ki az irodát. Új adag cigi meg jövő héten érkezik a kisboltba...

az ugye megvan hogy ezen a gepen nemcsak a gitmerge-t futtatja, hanem a forrason buildel egy kernet is, aztan azzal csinal ezt-azt? igy mar nagyon nem mindegy hogy 5 perc vagy 15 perc alatt lesz egy vmlinuz.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Egy `make -j`processzeit hogy dobod szet egy 10 node-os build farm node-jain? Egy hiba eseten egy elmeny lehet vadaszni a logokat, hogy hol mi failelt.

A tesztelendo forraskodot korbemasolod a node-okon vagy mindegyik kulon leklonozza a repot es hozza a patchet? Vagy vmi shared storage-ot hasznalva (NFS)? Nyilvan ennek a sebessege messze elmarad egy lokalis NVMe/PCIe SSD-tol.

Az ilyen build farm VM-eket erdemes lekapcsolni, amig idle. Viszont nem nagy elmeny lehet varni egy percet mire osszeall ujra a cluster reggelente, ebed utan, etc.

Ha jol gondolom, az az 5 perc build ido az a clean build. Ha csak egy par soros patchet probal ki egy modulon, akkor siman lehet hogy par masodperc alatt lefut a `make -j`. Erre overkill a buildfarm.

https://manpages.ubuntu.com/manpages/trusty/man7/icecream.7.html

https://en.wikipedia.org/wiki/Distcc

Manapság persze, mivel nagyon gyorsak a gépek, így már egyen is elég jó időt futhat.

Nem tudom, hogy megy náluk a fejlesztés, de más projekteken jellemző, hogy a patcheket eleve build farm teszteli le, hogy fordul-e, különböző szempontok alapján megfelelőe és teszteket is futtat rajta.
És nem unatkozik a build farm, hanem folyamatosan pörög, mert mennek befelé a változtatások.

Siman el tudom kepzelni, hogy a linux kernel mogott is van egy komplex CI, ami leforditja minden letezo architekturara es rabootolnak gepeket, futtatnak teszteket, etc.

De itt nem hiszem hogy errol lenne szo. Ez a gep Linus workstation-je. Ezen fejleszt, debugol. Siman el tudom kepzelni, hogy ha van egy patch, akkor abba beleirogat, kiprobalja ugy, mer performance-ot, crash-et elemez, megprobalja rekrealni a hibat, ilyesmik. Nyilvan nem akar minden egyes par soros modositasra PR-t nyitni maganak es varni a CI-ra, hogy egyszer majd vegez, ha a lokalis `make -j` lefut par masodperc alatt.

Nem a különálló processzeket kell szétdobni. Hanem ha ő X féle konfiggal akar kernelt buildelni, ahhoz nem kell a saját gépe, ahhoz a build farm X gépe megcsinálja neki a buildet. Amely build farm gépei lehetnek erősek.

Nem is értem, hogy a Linux Foundation erre miért nem tart fel infrastruktúrát, miért van SPOF a rendszerben Linus gépe által.

Szerintem nem ez a use-case, inkabb errol lehet szo: https://hup.hu/comment/2840253#comment-2840253

miért van SPOF a rendszerben Linus gépe által

Most megy a rinya par napos csuszason/kesesen, maskor siman eltolja a kiadast egy-ket hettel, mert konferencian/nyaralni van. Szoval nem a Linus gepe a SPOF, hanem Linus maga.

miért van SPOF a rendszerben Linus gépe által

A SPOF nem ott kezdődik, hanem a villamos hálózatnál. Maradjunk annyiban, hogy életemben több áramszünetet láttam mint RAM hibát, még sincs minden "kurva fontos" személy gépe alatt 2 különböző szolgáltatótól villamos betáp, komoly szünetmentes és dízel generátor. Szóval az első SPOF a villany, a második az internet kapcsolat lesz (nem, a mobilhálózatok sem mennek egy idő után, ha nincs villany) ...

trey @ gépház

( dotnetlinux | 2022. 10. 11., k – 23:32 )

Csak nekem fura hogy nem felhoben megy ez az egesz cucc? Linusnak van egy gepe, es azon mulik a linux kernel? 

A publikus felhokben futo VM-ek sebessege elmarad egy izmos workstationhoz kepest. Egyreszt cloudokban nem szoktak >5.0 Ghz-es CPU-kat hasznalni, masreszt a SAN volume-ok sebessege is elmarad a lokalis NVMe SSD-ktol.

Feltehetoen a development workflow-ja is olyan, hogy lokalban (talan emailbol?) vannak a patchek, nem akar meg a feltoltogetessel is bibelodni.

( uid_17626 | 2022. 10. 12., sze – 07:43 )

Hol vannak az Apple rajongók? Linus most jelentette ki, hogy az M2 lassabb, mint az AMD. :)

Szerintem most mellélőttél ezzel a fanboy szöveggel. Azért egy 32 magos, 64 szálas Threadripper nem azonos fajsúlyú egy akármilyen Macbookkal, nem egy ligában játszanak. Elromolni is el tud minden, Macbook is hibásodik meg, M1 és M2 szériából is tuti látott már az emberiség hibás darabot. Ezt nem is rónám fel egyik gyártónak sem, mivel a selejteket 100%-ban nem tudják kiszűrni, minden egyes darabot annyira alaposan tesztelni, ezért is van rá a gépekre, hardverelemekre jótállás minden gyártónál. Normálisabb RAM-okra általában élettartam-garancia is szokott lenni.

Ez a Threadripper gép annyiból mindenképp előnyösebb, hogy ha ezen megy tönkre valami, simán tudod cserélni, akár saját magad is. Ha a RAM a Macbookon megy tönkre, ott kuka az egész alaplap (mivel a SoC-ban van integrálva, ami meg oda van forrasztva az alaplapra), és csak hivatalos Apple szerviz foglalkozhat vele, plusz az ECC RAM azon nem opció. Semmi hírértéke nincsen ennek, szerintem itt a HUP-on is mindenkinek van több gépe, min. 2-3, ha az egyik elromlik, addig lehet használni valami másikat. Nekem is van ilyen esetre egy régi, ütött-kopott ThinkPad, meg extra asztali gép, stb.. Pont az ilyen esetre, ha befekszik az egyik, szervizben van, másikat nem veszek, addig se maradjak gép nélkül. Vagy még a gépnek sem kell tönkremenni, elég ha megfekszik rajta az OS, épp nincs időm újratelepíteni, van másik, amit beizzítok.

Torvalds helyzete annyiból más csak, hogy ő tehetősebb is, meg neki cégek is szoktak PR-ból gépeket küldeni, van neki két asztalnyi, meg nem tudom hány szekrénnyi, hegyekben állnak rajta a gépek, elrakott merevlemezek, vele készült interjúkon láthatod, mikor az otthoni dolgozószobáját mutatják. Nála aztán tényleg nem tétel, ha valami tönkremegy, ha ez az M2-es gép is megfekszik neki, leemel valami másik hasonló, márkásabb, drágább lapost. Neki ez fogyóeszköz, mint irodákban a toll és a gémkapocs.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Az az M2 nem azért van hogy legyőzze a top desktop procit, hanem azért hogy még akkor se kelljen napközben töltőt használnod, ha sokat dolgozol a laptopoddal.

+1

Nekem egyetlen oka van, amiért anno idő előtt váltottam M1-es gépre, éspedig az, hogy levelezőn csinálok épp egy képzést, és van, hogy szombatonként 8:45-től 17:45-ig ki kellene húzni egy töltéssel. Ezt bőven teljesíti anélkül, hogy ebédszünetben konnektorra kellene vadásznom, meg ilyen hülyeségek.