JANFROG: Takhle funguje technika Orku z Warhammer 40k. Funguje dokud veri ze funguje. To ze ta pistole ma zavarenou spoust a davas do ni naboje co jsou vetsi nez ma vyvrt hlavne je jedno, protoze dokud Ork veri ze funguje, tak funguje. Tohle bude to samy. Lidi veci ze Linux na tom nabehne bez potizi.. a tak proste nabehne.

JANFROG: já vím čím to, je to magie! :)))

LARS_GUNNER: Dve FPGA mam na stole :-) Akorat to vetsi se nedostane dal nez na U-boot. To mensi na bootuje, ale stejne to sem tam lehne. Problem (pravdepodobne) je v tom, ze sem tam DRAM controller neprovede stall pipeliny kdyz data nejsou vcas, takze jadro nacte random garbage z wishbone. A nikdo kolem moc netusi co s tim, ja uz tuplem ne : - ( Takhle my si tady zijeme...

Zajimave je, ze pres tohle vsechno, linux nabootuje, normalne bezi, muzes se na to pripojit pres SSH, lidi na to instalujou komplet LibreBMC a ovladaji tim IBM monstra (=servery). A pritom tak zakladni vec jako memory load je rozbitej.

Me fascinuje, jak je to vubec mozne. A to neni prvni pripad kdy vidim neco podobneho. Neni to tak davno, co nam padala J9 JVM. V QEMU to nepadalo nikdy. Fast forward 6 mesicu, prisli jsme na to, ze problem je M-mode trap handleru pro unaligned load/store, tedy ve firmwaru co bezi jeste pod jadrem OS. A pri tom zase, linux na to nabootuje, prelozis na tom GCC, rozjedes cele GNOME kdyz chces, dokonce i HotSpot na tom bezel bez problemu.

Mohl bych pokracovat, videl jsem toho vic. Jak je mozny, ze tolik SW proste "appears to work" i kdyz veci jsou fundamentalne rozbite je asi nejvetsi mysterium cele cimputer science (ale nikdo to nejak nezkouma).

QWWERTY: Hele, není to ale jen Indie. My jsme měli pár českých kolegů v kanceláři v Mountain View, a ti nám nabrali do týmu jednoho američana (asijské kořeny, ale byl narozený v USA). Prý při interview docela v pohodě.
Měli jsme ho tam asi 3 měsíce, pořád jsme nevěděli co dělá, tak jsem se šéfem dohodli, že udělá nějaký malý task, cca na den. Dělal ho měsíc a předělávali jsme to po něm. Ale šéf se pořád k ničemu neměl. Pak jsme tam byli na služebce a zjistil jsem, že prý už měsíc a půl dělá na jedné feature, ale přitom od něj nebyl jediný commit ani pull request. Tak jsem řekl ať commitne co má. Trvalo asi 3 dny než commitnul a prakticky tam nic nebylo. Tak jsem tu feature napsal od nuly asi za 4 dny a pak ho teprve šéf vyrazil.

Jinak problém s Indama je zpravidla ten, že ti schopní většinou z Indie vypadnou do USA.

KLEINZACH: Jo, to si taky stěžovala, že na všechno kyvou a pak se na to za týden zeptají

hehe az v indii mi doslo jak o moc bliz mam ke germanovi nez k ochotnemu nicmene ponekud laxnimu indovi i kdyz jsem si predtim myslel opak :) byl sem tam na mesic, dva tydny z toho jsem cekal na server (jo prikyvovat to oni umej - at uz tim ci onim zpusobem), tyden prace a tyden na pokoji s total srackou a indickou televizi.. peklo ;]

v kodu delali dost divny veci, pamatuju si akorat ze pred vstupem do funkce vsechny argumenty pretypovali natvrdo (c-cast) na to, co fce ocekavala.

DAVIDOWITCH: "spolupracovnici tam delali jen uplne presne to co se jim reklo ze maj udelat.."
u nas koluji podobny story, jako napr.: ind dostal metodicky pokyny pro praci, hodil do zarizeni commandy z kazdyho kroku a tvarili se, ze hotovo
to, ze uz prvni command vyhodil chybu a neprosel, takze by asi nemel pokracovat, resp. resit proc hned prvni krok selhal, uz ho nejak nenapadlo

podobna situace - nocni Tier3 support mame v Indii. tzn. kdyz se neco hodne rozbije v maintenance window, tak to vetsinou skonci u inda
vsechno mu trva dlouho - i kdyz ten stejny problem potkal uz driv, stejne mu trva treba hodinu, nez aplikuje stejny reseni jako posledne. ignoruje, kdyz se ho clovek snazi postrcit spravnym smerem a odmita sdilet jakykoliv detaily ohledem toho v cem je problem a jak ho resil.
osobne ze to vinim mentalitu kastovniho systemu, kdy ma pocit, ze jako T3 je nad nama a proto se muze tvarit jako nekooperativni autorita
...takhle jsme meli jeden problem, ind se s tim placal pres 2 hodiny, blizil se konec maintenance window, zacali se pripojovat jeho US kolegove a ptat se co se deje
a skoncilo to tak, ze mi rekli, at indovi prestanu vysvetlovat situaci a co je potreba udelat, aby se to spravilo, seberu mu presenter rights a spravim si to sam

podobnych story je asi plny internet, jako napr. tahle 4 dny zpatky
tl;dr:
Two senior indian dev contractors just spent 3.5 months on a feature
even me, a fcking junior with 3 years of experience managed to do it in 1 week.

LARS_GUNNER: Ja to delal necelej rok pri skole. Mam na CVUT FEL vystudovanej HW.. pak sem zjistil ze v Praze je de facto kartel S3, Honeywell a ASICentrum a nastupni plat v roce 2008 by byl pri dobrem vyjednavani 35 tisic hrubeho. S tim ze genericky C++ programatori po skole uz nastupovali vejs. Takze ted sem celkem generickej C++ programator se specializaci na grafiku. :-D

DAVIDOWITCH: FPGA verifikace? Hezky. Krome sebe moc lidi se zkusenostmi s FPGA neznam. Zdalo se mi, ze uz po tomhle neni poptavka.
Jako jo. Taky mi bylo receno, ze me nahradi junior v nejakem projektu a ja budu "jen radit". :-) Myslenka dobra, realita...

LARS_GUNNER: Pripomel si mi jak mama (tehdy uz teda project manazerka, ale pred tim dlouhou dobu programatorka a WinNT admin) si stezovala kdyz jeji Nemecka firma neco outsourcovala do Indie. Odhad byl ze Mnichove by to trvalo 3-4 cloveko-mesice. Outsourcing do Indie celou vec odsunul asi o 6 mesicu. Pak byl nacenen na 2 cloveko-roky. A po prvnim mesici (kalendarnim, takze nekolika cloveko-mesicich) si rekli o 3-4 cloveko-mesice consulting supportu z Mnichova, bez ktereho to nepujde. V kteremzto momente uz to ale bylo rozjety a neslo to zastavit.

Plus teda jeste ze davat testing do Indie se ukazalo jako velmi nemoudre, protoze minimalne ty spolupracovnici tam delali jen uplne presne to co se jim reklo ze maj udelat.. bez takovyho toho dulezityho "hele, a co kdybych zkusil tohle, prezije to ten produkt" coz mi (jakozto byvalymu FPGA verifikatorovi) vzdycky prislo jako naprosto zakladni skill testera.