Пока они тихо выживают в своих узких маргинальных нишах. Бравурные релизы последних несколькиз лет, 64bit, 128 ядер — но… сугубо специализированные дробилки для сетевого оборудования. Или дешёвые WiFi AP и роутеры. Пока нет признаков что «восстанут роботы из атомного пепла».
Может быть косяк не только с USB, но и с драйверами ethernet. А также наложение их взаимных проблем.
Помню заказчик очень хотел от нашего NAS (платформа XScale IOP, ARM тоже) скорость в iSCSI 35Mb/Sec.
Затыков с SATA не было — он стабильно давал 50MB/Sec (2006-2007 года, давно, SATA2), контроллер был заведён через шину PCI.
А вот сеть — на гигабите еле-еле выдавала больше 10-12 MB/Sec. Косяки как выяснилось — в марвеловском драйвере ethernet.
Если ждёте много ядер, то скорее смотрите не количество ядер, а какие они. Всё таки Cortex A7 vs A15 показывают совсем разные цифры. Не говоря уже о более старом Cortex A9.
Просьба исправить: «С октября 2013 года Intel такжеснова обладает лицензией на производство ARM чипов.» :)
См Intel XScale. Серия IOP долго жила в в специализированном варианте ARM-серверов (Network Attached Storage).
Вход ARM на рынок General Purpose серверов был только вопросом времени. Как только был анонсирован Cortex A15 и его плюшки ), big.LITTLE и другие аппаратные виртуализации — появление ARM-серверов стало только вопросом времени и консерватизма топовых производителей. Плюс сроки разработки железа и софта в Embedded — от года и дольше.
Мне очень любопытно, сможет ли ARM вытащить на свет божий паровозиком другие, в прошлом, серверные архитектуры. Такие как MIPS. У них энергоэффективность ещё выше. Можно вспомнить Cobalt Raq — изумительный был агрегат. IDE-диски, обычная SIMM-память, 1U — и… CPU MIPS на борту.
Отдельные безумно богатые семьи есть, но не все же 2-5 миллиона человек, принадлежащих к этой касте.
Наши ребята все скорее напоминали выходцев из европейского среднего класса (внешне и по воспитанию).
Непохоже, начиная с «можно собрать 12 человек со средней ставкой 30 баксов в час». Проблемой всегда было даже качественных 3-4 исполнителей найти. Я всегда работаю напрямую с HR своих компаний (хобби такое, неофициально), и знаю каково положение на рынке труда (очень перегрет, много лет подряд, проектов больше чем возможных исполнителей).
Технический долг может накапливаться, если лепят worlarounds. А если хреначат единственно разрешённым способом, без возможности обойти спущенные сверху догмы по инструментарию, организации кода, стилю и архитектуре — то тут единственное что может не удасться — это в срок накодить все фичи. В некоторых модулях упомянутой мной системы — не всё успевали, и выборочно выкашивали из первой итерации функционал.
Менеджмента на нашем Zerg Rush было не больше чем на типичном проекте разработки в западном стиле. Аналитики — тоже не так много, документация верхнего уровня написана ими, документация уровня подпроекта — тимлидами, документация уровня модуля — рядовыми исполнителями. Так уж получилось — что я документацию вычитывал. Помню, что качество линейно зависело от должности автора доки в иерархии компании :).
Стоимость внесения изменений? Везде одинаковая, куда не плюнь идентичный однообразный код.
Количество issues — стандартное, индусам не давали разгуляться в фантазиях.
Насколько мне известно — заказчик (крупный вендор производящий телекоммуникационное оборудование) систему принял. И продолжает сотрудничество с нашими любимыми индусами. Не путайте качество работы конечных исполнителей с качеством организации разработки системы в целом. Зерг-раш на тестирование тоже думаю проводился неоднократно.
Касательно вашего bad experience работы с индусами — после вояжа в Flextronics я убедился, что нужен специально обученный на индусов менеджмент, с пониманием их менталитета и особыми палочно-конвейерными методами преодоления хаоса, который они порождают при работе. Некоторые наши ребята вернулись расистами, просто не в силах понять разницу между тем, что у них творится в голове и что творится у индусов.
Некачественный код — заложен в управляемые риски проекта и преодолевается примивитизацией операций, используемых конечными исполнителями. Это высокий полёт по управлению проектами, без всякой иронии.
Пару крутых историй из хроники той поездки:
1. Молодой, красивый и инициативный парень Gunjan, в компании с 3-4 подельниками, по telnet хуячили под одной учётной записью и в одной рабочей копии несколько недель изменения в базовое API. Без коммитов, за несколько недель до релиза. Но их поймал наш любимейший Ramakrishna Pulivendla (PM этого модуля), и раскалённой кочергой внутри-анально принудил к коммиту. Гунджан с подельниками вынужден был править последствия своего авантюризма в режиме 14 часов в день/7 дней в неделю. И из офиса они в понедельник, 12 декабря, в день релиза первой итерации, вышли в 6 утра.
2. Вишну получил задание — надо в логах сделать перенос строки. Чтобы между записями была отбивка 1 строка. Вишну открыл файл с сообщениями (да, система правильно спроектирована), и добавил в 200 сообщений '\n'. Я уверен что вручную, т.к. замене по регулярным выражениям в vim их перед стартом проекта не учили. Этот триумф усидчивой жопы над мозгами увенчивает факт, что было достаточно в макрос вывода логов добавить '\n'. Но, что характерно, задача была решена и это решение даже ничего не сломало :).
Архитектура была не очень сложная. И, судя по всему, типовая для этой конторы. Мне показалось что они уже делали подобные проекты. Было в составе одна или две звезды разработки, которые обитали где-то на верхних уровнях иерархии и спускали сверху правильные стратегические решения. Плюс менеджмент, меня больше всего удивил менеджмент сего зерг-раша. Вот где скилл! Как принципиально не-западное мышление и поведение исполнителей интегрировать в западную модель разработки с предсказуемыми рисками и сроками.
Да, браминов. Они вкалывали, как проклятые, 12-14 часов в день, а когда сроки сгустились — и без выходных. Другое дело что мозга в этом зерг-раше было мало.
Рядом с офисом на тротуаре спят бездомные. А за стеной вокруг офиса — находится шикарная свалка на N гектар, где за пищевые отбросы конкурируют семьи бомжей и коровы. Я не сгущаю, достаточно было подняться на крышу офиса конторы в Гургаоне (город-спутник Дели) — чтобы получить вид на то как живёт остальная страна. Думаю это стимулирует.
Границы применимости — есть у любой методики разработки.
Кстати, я не упомянул, но на весь проект была документация, которую заставляли писать.
Как и у всего проекта в целом — её качество падало в зависимости от уровня. Высоко-уровневые архитектурные вещи — описаны отлично, чем ближе к коду — тем хуже и out of date. Ну и код — то хуже всего :).
Для действительно больших и масштабных проектов — мне кажется вполне конкурентоспособен. Для типичных аутсорсеров из Восточной Европы и ex-USSR — они просто не смогут собрать такое дикое количество исполнителей на один проект. Плюс эти исполнители сравнительно малооплачиваемые и очень держатся за свою работу (рядом с офисом на улице на тротуарах спят бездомные, за стеной офиса — свалка, где коровы и бомжи конкурируют за отбросы).
Приемлимого качества продукта в целом с помощью такого модифицированного итерационного waterfall-конвейера можно добится к 4-5 итерации. Есть ниши для подобных долгоиграющих проектов. Как писал незабвенный Брукс в «Мифическом человеко-месяце» — на больших проектах на первый план выходят вопросы организации труда и взаимодействия внутри и между проектных команд, входящих в коллектив проекта.
Я предлагаю ещё более крутое название. «Атака Браминов-Зомби».
100% программистов в Aricent были из касты браминов. Это связано полагаю с невозможностью получить высшее образование представителям других каст. Плюс пониженная доступность нормальных школ, из которых можно поступить на IT-специальности.
К сожалению — не всё так однозначно. Возможно мне стоит написать отдельный пост на тему конвейерного метода организации программирования. И назову её «Домик из говна. Правильный способ производства ПО в индийских условиях».
У меня был личный опыт участия в подобном, в бытность стажировки в Индии в 2005 году. Сейчас эта структура называется Aricent, тогда это был Flextronics Software Systems (CMMI-5).
Огромный проект для телекома, целевая платформа Solaris 8. Его делает большая толпа (>120 человек) малоквалифицированных исполнителей (что всем очень понравится — индусов) с тоненькой прослойкой тимлидов уровня нормальных программистов (тоже индусов) и индусский менеджмент. Плюс группка стажёров, заброшенных с Украины и Беларуси чтобы оторвать кусок проекта в ту сторону.
Был устроен фабричный конвейер в чистейшем незамутнённом виде:
— Перед включением в проект — ПТУ. «Дети, знакомьтесь — это проект, проект — это дети». Серия тренингов об архитектуре проекта и всему инструментарию сверху до низу (включая vim, version control ClearCase, разбиение на модули, как входить на девелоперский сервер и т.д.), плюс вводная как это должно реализовываться. Для самого конечного исполнителя с сонным выражением лица стоящего в строю.
— API и архитектура — прибиты гвоздями заранее.
— Система спроектирована таким образом, что всё сделано через FSM. Исполнители кодят функции переходов между состояниями И ВСЁ. В худшем случае производительность участника можно оценивать количеством написанных функций в день. Их сотни и они одинаковые. Индусы радостно копипейстят одно и тоже.
непридуманный диалог со standup daily meeting:
PM — Ритика, сколько функций ты вчера написала?
Ритика — 17
PM — Плохо! А ты Вишну?
Вишну — Я написал 36 функций!
PM — Молодец, Вишну! Всем тоже писать 36 функций в день!
— проект для рядового исполнителя разбит на стадии:
а. 2-3 месяца кодим, и только кодим. Вся команда кодит. 120 человек. Даже компиляция проверяется весьма эпизодически
б. 2 недели — юнит тесты. За программирование — бьют по рукам, только пишем тесты. Code coverage проверяется и прочие вещи.
в. 2 недели системная интеграция, заставляем модули работать вместе
В итоге через полгода работы (включая фазы подготовки людей, проектирования и непосредственно реализации) — имеем первую версию системы. За полгода 120 человек написали маштабируемую 3G VoIP телефонию (HA, расширяемость, все дела). На тестах первая итерация системы поддерживает только 2 (!) пользователей и всегда зависает на 35 звонке. Тимлиды возвращаются с показов заказчику седыми.
Но… Начинается следующая итерация «проектирование» ->«кодинг»->«юнит тестирование»->«системная интеграция». И я полностью уверен, что после 5 итерации система заработала в полном обьёме. Её тупо массой задавили и грамотным использованием неквалифицированных исполнителей в правильно выстроенным для них процессе.
Мои аплодисменты менеджменту и проектировщикам. Как выстроить людей, допускающих ДИЧАЙШИЕ косяки и особенно не умеющих программировать, в конвейер. И получить результат.
У печатных книг длинный цикл подготовки, а если она ещё и переводная…
Publication Date: August 19, 2013 — дата выхода оригинала. И к выходу готовилась как мне кажется минимум полгода. Итого — получаем декабрь 2012 как конец работы над текстом. Внимательно смотрим в wiki.ubuntu.com/Releases — вуаля, 12.04 — LTS образца 2012 года :).
Хотел бы отметить, что IPMItool, но за исключением Fujitsu OEM extensions к протоколу.
Есть FreeIPMI, но в нём поддержка OEM extensions для Fuji кажется заканчивается на версии iRMC S2. Это, если мне не изменяет память, доисторические времена и ThreadX в качестве управляющей RTOS. С тех пор расширения разрослись вширь.
Понимаю, что для большинства бытовой автоматизации и IPMI 2.0 достаточно, но в расширениях много всяких вкусных возможностей было. Power History например посмотреть не только на процитированной выше картинке, но и в пакетном режиме.
Помню заказчик очень хотел от нашего NAS (платформа XScale IOP, ARM тоже) скорость в iSCSI 35Mb/Sec.
Затыков с SATA не было — он стабильно давал 50MB/Sec (2006-2007 года, давно, SATA2), контроллер был заведён через шину PCI.
А вот сеть — на гигабите еле-еле выдавала больше 10-12 MB/Sec. Косяки как выяснилось — в марвеловском драйвере ethernet.
Если ждёте много ядер, то скорее смотрите не количество ядер, а какие они. Всё таки Cortex A7 vs A15 показывают совсем разные цифры. Не говоря уже о более старом Cortex A9.
такжеснова обладает лицензией на производство ARM чипов.» :)См Intel XScale. Серия IOP долго жила в в специализированном варианте ARM-серверов (Network Attached Storage).
Вход ARM на рынок General Purpose серверов был только вопросом времени. Как только был анонсирован Cortex A15 и его плюшки ), big.LITTLE и другие аппаратные виртуализации — появление ARM-серверов стало только вопросом времени и консерватизма топовых производителей. Плюс сроки разработки железа и софта в Embedded — от года и дольше.
Мне очень любопытно, сможет ли ARM вытащить на свет божий паровозиком другие, в прошлом, серверные архитектуры. Такие как MIPS. У них энергоэффективность ещё выше. Можно вспомнить Cobalt Raq — изумительный был агрегат. IDE-диски, обычная SIMM-память, 1U — и… CPU MIPS на борту.
Наши ребята все скорее напоминали выходцев из европейского среднего класса (внешне и по воспитанию).
Технический долг может накапливаться, если лепят worlarounds. А если хреначат единственно разрешённым способом, без возможности обойти спущенные сверху догмы по инструментарию, организации кода, стилю и архитектуре — то тут единственное что может не удасться — это в срок накодить все фичи. В некоторых модулях упомянутой мной системы — не всё успевали, и выборочно выкашивали из первой итерации функционал.
Менеджмента на нашем Zerg Rush было не больше чем на типичном проекте разработки в западном стиле. Аналитики — тоже не так много, документация верхнего уровня написана ими, документация уровня подпроекта — тимлидами, документация уровня модуля — рядовыми исполнителями. Так уж получилось — что я документацию вычитывал. Помню, что качество линейно зависело от должности автора доки в иерархии компании :).
Стоимость внесения изменений? Везде одинаковая, куда не плюнь идентичный однообразный код.
Количество issues — стандартное, индусам не давали разгуляться в фантазиях.
Касательно вашего bad experience работы с индусами — после вояжа в Flextronics я убедился, что нужен специально обученный на индусов менеджмент, с пониманием их менталитета и особыми палочно-конвейерными методами преодоления хаоса, который они порождают при работе. Некоторые наши ребята вернулись расистами, просто не в силах понять разницу между тем, что у них творится в голове и что творится у индусов.
Некачественный код — заложен в управляемые риски проекта и преодолевается примивитизацией операций, используемых конечными исполнителями. Это высокий полёт по управлению проектами, без всякой иронии.
Пару крутых историй из хроники той поездки:
1. Молодой, красивый и инициативный парень Gunjan, в компании с 3-4 подельниками, по telnet хуячили под одной учётной записью и в одной рабочей копии несколько недель изменения в базовое API. Без коммитов, за несколько недель до релиза. Но их поймал наш любимейший Ramakrishna Pulivendla (PM этого модуля), и раскалённой кочергой внутри-анально принудил к коммиту. Гунджан с подельниками вынужден был править последствия своего авантюризма в режиме 14 часов в день/7 дней в неделю. И из офиса они в понедельник, 12 декабря, в день релиза первой итерации, вышли в 6 утра.
2. Вишну получил задание — надо в логах сделать перенос строки. Чтобы между записями была отбивка 1 строка. Вишну открыл файл с сообщениями (да, система правильно спроектирована), и добавил в 200 сообщений '\n'. Я уверен что вручную, т.к. замене по регулярным выражениям в vim их перед стартом проекта не учили. Этот триумф усидчивой жопы над мозгами увенчивает факт, что было достаточно в макрос вывода логов добавить '\n'. Но, что характерно, задача была решена и это решение даже ничего не сломало :).
Рядом с офисом на тротуаре спят бездомные. А за стеной вокруг офиса — находится шикарная свалка на N гектар, где за пищевые отбросы конкурируют семьи бомжей и коровы. Я не сгущаю, достаточно было подняться на крышу офиса конторы в Гургаоне (город-спутник Дели) — чтобы получить вид на то как живёт остальная страна. Думаю это стимулирует.
Кстати, я не упомянул, но на весь проект была документация, которую заставляли писать.
Как и у всего проекта в целом — её качество падало в зависимости от уровня. Высоко-уровневые архитектурные вещи — описаны отлично, чем ближе к коду — тем хуже и out of date. Ну и код — то хуже всего :).
Например программирование организованное как конвейерное производство (см мой большой комментарий выше) :).
Я приходил в Guest House после работы и падал в кровать лицом вперёд не раздеваясь. И засыпал мгновенно.
Приемлимого качества продукта в целом с помощью такого модифицированного итерационного waterfall-конвейера можно добится к 4-5 итерации. Есть ниши для подобных долгоиграющих проектов. Как писал незабвенный Брукс в «Мифическом человеко-месяце» — на больших проектах на первый план выходят вопросы организации труда и взаимодействия внутри и между проектных команд, входящих в коллектив проекта.
100% программистов в Aricent были из касты браминов. Это связано полагаю с невозможностью получить высшее образование представителям других каст. Плюс пониженная доступность нормальных школ, из которых можно поступить на IT-специальности.
У меня был личный опыт участия в подобном, в бытность стажировки в Индии в 2005 году. Сейчас эта структура называется Aricent, тогда это был Flextronics Software Systems (CMMI-5).
Огромный проект для телекома, целевая платформа Solaris 8. Его делает большая толпа (>120 человек) малоквалифицированных исполнителей (что всем очень понравится — индусов) с тоненькой прослойкой тимлидов уровня нормальных программистов (тоже индусов) и индусский менеджмент. Плюс группка стажёров, заброшенных с Украины и Беларуси чтобы оторвать кусок проекта в ту сторону.
Был устроен фабричный конвейер в чистейшем незамутнённом виде:
— Перед включением в проект — ПТУ. «Дети, знакомьтесь — это проект, проект — это дети». Серия тренингов об архитектуре проекта и всему инструментарию сверху до низу (включая vim, version control ClearCase, разбиение на модули, как входить на девелоперский сервер и т.д.), плюс вводная как это должно реализовываться. Для самого конечного исполнителя с сонным выражением лица стоящего в строю.
— API и архитектура — прибиты гвоздями заранее.
— Система спроектирована таким образом, что всё сделано через FSM. Исполнители кодят функции переходов между состояниями И ВСЁ. В худшем случае производительность участника можно оценивать количеством написанных функций в день. Их сотни и они одинаковые. Индусы радостно копипейстят одно и тоже.
непридуманный диалог со standup daily meeting:
— проект для рядового исполнителя разбит на стадии:
а. 2-3 месяца кодим, и только кодим. Вся команда кодит. 120 человек. Даже компиляция проверяется весьма эпизодически
б. 2 недели — юнит тесты. За программирование — бьют по рукам, только пишем тесты. Code coverage проверяется и прочие вещи.
в. 2 недели системная интеграция, заставляем модули работать вместе
В итоге через полгода работы (включая фазы подготовки людей, проектирования и непосредственно реализации) — имеем первую версию системы. За полгода 120 человек написали маштабируемую 3G VoIP телефонию (HA, расширяемость, все дела). На тестах первая итерация системы поддерживает только 2 (!) пользователей и всегда зависает на 35 звонке. Тимлиды возвращаются с показов заказчику седыми.
Но… Начинается следующая итерация «проектирование» ->«кодинг»->«юнит тестирование»->«системная интеграция». И я полностью уверен, что после 5 итерации система заработала в полном обьёме. Её тупо массой задавили и грамотным использованием неквалифицированных исполнителей в правильно выстроенным для них процессе.
Мои аплодисменты менеджменту и проектировщикам. Как выстроить людей, допускающих ДИЧАЙШИЕ косяки и особенно не умеющих программировать, в конвейер. И получить результат.
Publication Date: August 19, 2013 — дата выхода оригинала. И к выходу готовилась как мне кажется минимум полгода. Итого — получаем декабрь 2012 как конец работы над текстом. Внимательно смотрим в wiki.ubuntu.com/Releases — вуаля, 12.04 — LTS образца 2012 года :).
Есть FreeIPMI, но в нём поддержка OEM extensions для Fuji кажется заканчивается на версии iRMC S2. Это, если мне не изменяет память, доисторические времена и ThreadX в качестве управляющей RTOS. С тех пор расширения разрослись вширь.
Понимаю, что для большинства бытовой автоматизации и IPMI 2.0 достаточно, но в расширениях много всяких вкусных возможностей было. Power History например посмотреть не только на процитированной выше картинке, но и в пакетном режиме.