Názory k článku
IBM přesunula zbývající vývoj systému AIX do Indie
-
U tohoto článku jsem si vzpomněl na citát z Red Dwarfu.
Arnold Rimmer, technik druhé třídy. Kapitánovy záznamy: Důstojníci mají takové rčení: „Má-li nějaká práce smysl, má smysl udělat ji dobře. Nemá-li smysl, dejte ji Rimmerovi. “
Co se sleduji ten outsourcing do Indie, tak to rčení by mělo znít : .„Má-li nějaká práce smysl, má smysl udělat ji dobře. Nemá-li smysl, dejte ji Indům. “
-
Nic proti programatorum z Indie, ale tohle je konecna. Podobne jako prodej Informixu firme HCL. A takovej stabilni system to byl, ma unikatni vlastnosti, nektere mel jako prvni, jine Linux doposud neimplementoval.
Ted uz jen budou zdimat penize z tech par poslednich zoufalcu, kteri to jeste pouzivaji.
-
Tak treba dynamicky kernel s mensim mnoztvim parametru, takze neni potreba tak casto ladit nejake parametry kernelu.
Balikovaci system ktery umi rollback, obsahuje databazi znamych bugu a patchu. Takze je mozne pomoci commandline zjistit, za ma danny system patch to urcity bug.
Device manager - vsechna zarizeni maji v OS perzistentni jmena, takze pokud je zarizeni jednou detekovano, tak uz vzdy bude mit v systemu stejne jmeno.
Napr. jmeno disku (sda / hdisk0) je napsano primo na tom disku.
Dalsi vlastnosti Device manageru je to, ze soucasti ovladace jsou i nastroje na detekci danneho zarizeni (neco jako udev pravidla). Tyhle veci se vyviji a dodavaji spolecne. Neni to jako na Linuxu, ze ovladac je soucasti kernelu a udev pravidla soucasti distribuce.Dalsi vlastnosti device manageru je to, ze obsahuje i nastroje pro flashovani firmware, takze AIX kdyz bootuje, tak si behem bootu naflashuje Firmare HW na pozadovanou verzi. V tomhle to ma AIX ale jednodussi protoze HW is SW pochazi od stejne firmy.
Pokud jde o bootovani tak to je rozdelene do dvou fazi, nejdrive z RAM disku a pak z disku. Nektere ovladace zarizeni jsou oznacene jakou bootovatelne jsou nahrana do image RAMdisku. Pokud takovy ovladac aktualizujete, system vam oznami, ze je potreba aktualizovat i RAM disk.
Device location code - AIX ma standartizovany system pro pojmenovavani zarizeni a jejich lokaci v ramci OS i na fyzickem HW. Takze pokud z OS zjistite adapter ma v location code 'P1-C1', tak zezadu na krabici bude nalepka 'P1-C1' a tam ten adapter fyzicky najdete.
-
Pridal bych jeste uz spousty let pred Linuxem zdaleka nejlepsi LVM, protoze na AIXu lze s disky, resp. partitions delat prakticky cokoliv, online kopie PP (physical partition) na dalsi disky (mozno mit dalsi 2 kopie 1 PP), coz je super pri napr. migraci na jine diskove pole apod., proste pridate nove propagovane arrays ze SAN jako PV (physical volume) do stejne VG (volume group) a pak zrcadlite ty PPs, puvodni pak odzrcadlite, vse online, takze prejdes za behu na jine diskove pole, atd. Tam se da kouzlit ;-)
Navic ja s AIXem pracuji uz od verze tusim 4 (a na PowerPC 5 tusim) a osobne - a to prisaham - mi AIX nikdy nevytuhnul, jak to jednou nabootujes (jooo tady si pockas, nez udela vsechny ty HW checks atd, jak pise kolega vyse), ale pak to jede leta... a to nam na tech AIX serverech beha IBM Informix Database Server, v minulosti vcetne 4GL aplikaci, ktere se i na tech serverech kompiluje, runtimes, debuggers, atd.
Proste drzak se vsim vsudy i dnes na Power 9 a AIX 7.2.
-
Ekonomika je nemilosrdna: vsechno programovani pujde casem do prd... Indie. Vidim to u nas ve firme: neco malo jeste koduje par lidi v oficu v Chorvatsku, ale v Indii uz mame nakontraktovano nakejch 200 programatoru.
A bohuzel, dle toho to taky vypada: pridavaji funkce a delaji nove bugy rychleji, nez my reportujeme ty stare. Na vsechno maji jen "yes sr, of kos sr", ale vysledky tragicky. No hlavne ze se usetrilo na platech vyvojaru v EU...
-
No myslím, že si s tímhle poradí ekonomika především tak, že do pr*indie půjde hlavně firma, která nereflektuje úpadek kvality svého produktu po neuváženém outsourcingu.
Pokud má firma špatné vedení, které nevidí, že má vyrazit především manažera, který sleduje jen a pouze okamžitý zisk, ale snaží se firmu z dlouhodobého hlediska evidentně poškodit, pak je v pořádku, že kvalifikovaný personál přejde ke konkurenci a nabídne třeba se svými zkušenostmi nový produkt, který bude původní firmě konkurovat a časem ji zlikviduje.
Samozřejmě to tedy předpokládá nutnost rozumného zákazníka, který utrácí peníze nejen podle ceny, ale i kvality a spolehlivosti, což je bohužel taky čím dál větší vzácnost...
-
Asi záleží na jaké Indy se narazí a hlavně kolik jim ta firma dá peněz, resp. jaké požadavky na ně má. Moje zkušenost s Indy co dělají pro MS Azure je, že jakákoliv komunikace je naprosto ale naprosto ztráta času (ty bych nejraději něčím přetáhnul), ten jejich support je úplně k ho... Ale zase mě ohromně překvapilo školení od MongoDB, kde nám jeden Ind velmi pomohl. Od té doby jsem s házení všech do jednoho pytle opatrný. To ale nic nemění na tom, že tohle rozhodně nebude ten pozitivní příklad, že by překvapili.
-
Moje zkušenosti s IT lidmi (převážně vývojáři) z Indie jsou smíšené. V řadě případů je třeba vidět, že dostanou zadání, seknout se na prvním nebo druhém kroku, a prostě čekají, až se někdo zeptá, proč to ještě není hotové. To od profíka hodně překvapí. Plus samozřejmě nepochopení zadání, slabé znalosti technologie atd. Nicméně jsem viděl i případy, kdy Indové odvedli naprosto skvělou práci, drželi se zadání a byli proaktivní.
Takže souhlas, že nemá smysl je házet do jednoho pytle. Nakonec podobně to funguje i pokud si řekněme německá nebo britská firma najímá lidi v ČR. Řada Čechů mluví anglicky jak Borat, na práci kašlou, a v lepším případě udělají nejméně co je potřeba k tomu, aby nedostali pojeb. Jiní Češi jsou ale fakt třída, s perfektní angličtinou, zápalem pro věc a skvělou znalostí věci. Ti Češi, kteří pracují v IT oddělení řekněme britské firmy, jsou zpravidla z té druhé kategorie. Takže ani nás neházet do jednoho pytle :)
-
Přitom ten platový rozdíl není zase tak propastný. U nás ve firmě lidi v Indii vydělávají tak 2/3 toho, co my tady. Akorát v té Indii je to asi desetinásobek průměrné mzdy. Mezi kolegy z Pune je celkem běžné mít osobního řidiče, protože mu neplatí ani desetinu svého platu. Osobního řidiče nemá v Americe ani CEO celé naší firmy. :)
-
Nepůjde. Pokud se ted v Indii nenaučí vyvíjet ale problém je, že většina schopných Indů záhy zmizí na Západ. Ony to totiž ty firmy zkoušejí, ale i mickey-mouse manažerům obvykle po čase dojde (i když některým až v okamžiku, kdy skončí na koberečku u jejich nadřízeného), že to ve výsledku stojí víc peněz, než to ušetřilo.
Tohle není nic nového. A navíc jde jenom o korporáty.
-
Všetky tieto problémy mal riešiť software, ktorý ich nakoniec ešte zhoršil. A ten software písali Indovia, ktorí s tým nemali skúsenosti. Boeing svojich skúsených programátorov v USA prepustil a dal to vyvíjať Indom.
A takto dopadne aj AIX. Najprv ušetria a nakoniec to bude stáť IBM ešte viac ako by boli náklady v USA.
-
L.Stříbrný podporovatel
Ale houby (slušně řečeno). Jednak letecké nehody nemají skoro nikdy jen jednu příčinu, ale je potřeba řetězec selhání:
- (Možnost) napojení systému jen na jedno čidlo
- Podcenění dopadu nového systému (piloti o něm nic neměli v materiálech na přeškolení)
- Nikdo nepodchytil zvyšující se fyzickou náročnost manuálního (fyzického) trimu
- Nedostatečný výcvik posádky pro zvládání situací, kde je potřeba fyzický trim (rollercoaster manévr)Jak si můžeš všimnout, nikde tam není položka "SW psali Indové" a dokonce ani "SW měl chybu". Všechno to jsou manažerská selhání.
Jinak, systém MCAS, jehož "zbláznění" bylo klíčovým faktorem, nebyl vyvinut přímo pro MAX, ale byl už předtím na vojenském tankeru KC-46 Pegasus. Tam byl ale napojen vždy na dvě čidla a proto tam k podobnému problému nedošlo. Takže je dost možné, že ten SW byl vyvinut ještě před přesunem vývoje SW Boeingu do Indie.
-
To všetko viem. Ak software opakovane pretláča pilota a tlačí lietadlo k zemi, tak veľmi ťažko s tým dokáže niečo pilot urobiť. SW tlačil lietadlo k zemi, hoci iný systém hlásil blízkosť zeme. Pilot sa už ani pomodliť nestihol.
O vývoji SW v Boeingu pre 737 Max je niečo tu:
Oficiálne samozrejme Boeing neprizná, že šetrili a preto outsorcovali SW pre 737 Max. Nakoniec zaplatili omnoho viac.
-
L.Stříbrný podporovatel
To jsou ještě větší h*vadiny, než jste psal prve. Žádný SW pilota nepřetlačoval. SW upravoval trim, který se dělá jinou ovládací plochou, ovládanou jinak, než řídící pákou. Obecně upravovat trim neustále ručně je otravné, takže to běžně dělá automatika a to, že se "zblázní", je standardní mimořádná situace, na kterou piloti musí umět reagovat, v tomhle případě dokonce zpaměti, bez konzultace s papírovým checklistem.
No a piloti těch dvou letů na to adekváně reagovat nezvládli z příčin vypsaných v mém předchozím příspěvku. K poruše čidla došlo ve více případech, tam ale piloti zareagovali správně, tak nehodnou skončily jen tyhle dva případy.
Mimochodem, pomodlit se stihli zcela určitě. Hlavní problém byl v tom, že ačkoli postup pro danou situaci jasně říkal, že mají vadný automatický trim vypnout a nechat vypnutý, tak jej opětovně zapnuli, čímž svůj osud zpečetili.
Neříkám, že Boeing nemá máslo na hlavě, ale "nekvalitní indický SW" v téhle kauze roli opravdu nehrál.
-
Musím sa pripraviť na to, že sa po štvrťstoročí moja kariéra IT konzultanta špecializujúceho sa na AIX konči. :-)
Spomínam si na to, ako som už niekedy v 1998 na AIX 4.3 predvádzal presun rootvg (VG kde je umiestnený operačný systém) z jedného disku na druhý a potom som ten pôvodný systémový disk zo stroja vybral. Všetko za chodu a bez rebootu.
ČLÁNKY DO MAILU