Оргранизация Linux Foundation опубликовала отчёт (PDF (http://go.linuxfoundation.org/value-of-ltsi.pdf)) с оценкой экономической эффективности проекта LTSI (http://ltsi.linuxfoundation.org/) (Long Term Support Initiative), в рамках которого ряд производителей скооперировались для совместного длительного поддержания веток ядра Linux. В отчёте также подробно рассмотрены затраты, необходимые на тестирование и сопровождения сторонних патчей для ядра Linux.
Коллективные затраты на поддержание и развитие каждого выпуска LTSI-ядра оцениваются в 3 млн долларов. Так как работа ведётся совместно, данные затраты распределяются среди всех участников проекта. Без использования LTSI, производители вынуждены бы были нести полные издержки, связанные с тестированием, сопровождением и бэкпортирвоанием изменений, дублируя работу друг друга. Кроме того, рассчитана экономическая эффективность продвижения патчей в основную ветку ядра. Каждый включенный в основное ядро патч может сэкономить компании до 250 тысяч долларов в год.
В разработке LTSI-ветки участвует ряд крупных производителей потребительских устройств, среди которых Hitachi, LG Electronics, Renesas, NEC, Sony, Panasonic, Qualcomm, Samsung и Toshiba, договорившихся о совместной работе по поддержке определённых версий ядра Linux с целью снижения затрат и более эффективного использования ресурсов, которые ранее приходилось тратить на выполнение работ, дублирующих аналогичную работу в других компаниях. Использование ветки LTSI, обновления для которой выпускаются в течение двух лет, позволяет производителям обеспечить актуальность ядра в прошивке на протяжении всего жизненного цикла продукта, без самостоятельного бэкпортирвоания и тестирования исправлений.
URL: https://www.linux.com/news/featured-blogs/202-noriaki-fukuya...-
Новость: http://www.opennet.me/opennews/art.shtml?num=38098
Если уволить весь не нужный планктон, в количестве 10 менеджеров на одного программиста,
то экономия станет равна годовой прибыли.
тогда уж сразу печатный станок поставить, оптимизировать, дак до конца :)
> тогда уж сразу печатный станок поставить, оптимизировать, дак до конца :)Печатный станок уже давно стоит, где надо, и оптимизирован, как надо ;)
> планктон как тазFAIL.
> не видят дальше носа своего
Плох тот программист который не мечтает стать PM'ом.
Программиста до менеджера повышать нет смысла.
Не программиста а кодера. Все остальные обычно вырастаю в должности.
> Не программиста а кодера. Все остальные обычно вырастаю в должности.до уровня некомпетентности, как полагается.
Судите по собственному опыту?
> Судите по собственному опыту?Это широко известное среди вменяемых менеджеров правило, если что. Точную формулировку уже не помню, но смысл таков, что карьерный рост идёт именно до достижения некомпетентности.
Это Принцип Питера, и судя по нему если человек не поднялся выше кодера, то он некомпетентен даже как кодер.
> Это Принцип Питера, и судя по нему если человек не поднялся выше
> кодера, то он некомпетентен даже как кодер.Нет, его некомпетентность не "доросла" до менежора.
Человек, работающий в любой иерархической системе, повышается в должности до тех пор, пока не займёт место, на котором он окажется не в состоянии справиться со своими обязанностями.
Инфа из педивикии.
И почему я еще не президент США, там мозги вроде как не нужны=))
> И почему я еще не президент СШАпотому что не негр преклонных годов.
> Это Принцип Питера, и судя по нему если человек не поднялся выше
> кодера, то он некомпетентен даже как кодер.Может, закон Паркинсона?
Закон Паркинсона описывает взаимоотношения между человеком и работой, так что вряд ли.
держи карман шире
бабла у РМ может и поболе, но работа на порядки отвратней
В больших компаниях, специализирующихся на разработке софта, менджмент среднего и низшего звена неслабо спасает рядовых программистов от мозгоебле со стороны топов с их оху*тельными видениями разрабатываемых продуктов, принимая весь удар на себя, выдавая наружу нормальные задачи. Иногда их, конечно, бываем многовато, но избыток в самых запущенных случаях всего лишь двухкратный.
А основной геморрой приносит не количество менеджеров, в объем бюрократии, которую в безумных количествах может сгенерировать и один человек.
В больших компаниях - топ-менеджмент вообще не знает, что такое разработка.
У них три функции - ДА, НЕТ и БЫСТРЕЕ!
Большие компании, как ни странно, тоже бывают разными.
В больших компаниях программист это раб который знает три слова - ДОЛГО, ТРУДНО и НЕВОЗМОЖНО.
В больших СОФТВЕРНЫХ компаниях - еще как знают.
А средние - еще и прикрывают от странностей клиентов. Которые тоже ни разу не сахар.Умиляют товарищи, которые не понимают объема действий, нужных большой конторе чтобы хотя бы не развалиться, не говоря о какой-либо полезной деятельности. И да, для больших проектов нужны именно большие конторы. Способные, например, при аврале бросить на задачу лишнюю сотню человек.
Да, об этом в "мифическом человекомесяце" говорится. Чем больше программистов привлекается для аврала, тем отчетливее надвигается трындец. Программистам еще и знакомиться с продуктом надо, и обмениваться информацией. На этот обмен тратится уйма времени.
Вы, видимо, уверены, что иных авральных задач, кроме разработки, не бывает...
а, Вы про субботники - убирать прилегающую территорию :) ( или выезд на картошку всем НИИ ). Да, в советское время такое было
Если авралом разрабатывать хорошо специфицированные куски на известном фреймворке - особых проблем нет. Естественно, придется все закрывать тестами с ног до головы.
Авральная разработка _всегда_ влечет проблемы, хотя они не всегда идут бруксовской траекторией и не всегда возникают в краткосрочный период.Кладбище компаний и команд, задавленных технической задолженностью, много обширнее кладбища тех, кто сорвал сроки по проекту.
Угу. Только в реальной жизни авралы таки бывают. Внешние условия - они отнюдь не всегда предсказуемо меняются, и иногда заказчику вдруг нужно, чтобы всё было готово "вчера". И, собственно, именно за возможность разнообразных перестраховок и есть смысл перплачивать большим конторам.А технический долг потом можно поправить в более спокойном режиме - сотрудничество обычно длится годами и авралом отнюдь не заканчивается. Это ж не "написали и разбежались", а полноценный аутсорсинг разработки.
> А технический долг потом можно поправить в более спокойном режименет на свете более долгоживущего кода, чем тот, который помечен как «временное решение! обязательно переписать в ближайшее время!»
Ну, в случае, о котором я говорю - таки приводили в порядок потом. Впрочем, там особого ужаса и не было - просто гора тупой работы, которую вдруг понадобилось сделать быстро.
Во времена написания "человекомесяца" (а это начало семидесятых - совсем детство IT) не было ни развитых фреймворков, ни UML, ни понимания, как писать спецификации и организовывать модульность. А для тестирования и подавно людей привлечь не проблема. Вы просто не видели таких ситуаций.
Черт, вы открыли мне глаза. Вот же она, золотая пуля: каркасы, UML и модульность.
Как ни странно, для энтерпрайзов во многих случаях - она самая и есть. Сложность там невелика как правило, там объемы здоровенные - и кода, и данных. Это ж не авионика какая. Да, дорого. Да, тормозно. Но дубово.
> Умиляют товарищи, которые не понимают объема действий, нужных большой конторе чтобы хотя
> бы не развалиться, не говоря о какой-либо полезной деятельности. И да,
> для больших проектов нужны именно большие конторы. Способные, например, при аврале
> бросить на задачу лишнюю сотню человек.ведь всем известно, что если ребёнок нужен срочно — то надо взять девять женщин вместо одной, и сроки разработки ребёнка сократятся до месяца!
> А средние - еще и прикрывают от странностей клиентов. Которые тоже ни
> разу не сахар.
> Умиляют товарищи, которые не понимают объема действий, нужных большой конторе чтобы хотя
> бы не развалиться, не говоря о какой-либо полезной деятельности. И да,
> для больших проектов нужны именно большие конторы. Способные, например, при аврале
> бросить на задачу лишнюю сотню человек.Прикрывание от странностей клиентов - это что-то из сферы бодишопов. В софтверных компаниях, разрабатывающих софт для рынка, с клиентами общаются только сейлзы и техсаппорт.
И, насчет авралов - гарантированно избежать аврала при его приближении может только смягчение требований к функциональности либо перенос сроков. Других способов не бывает. Сотни новым сотрудникам надо въехать в имеющийся код и инфраструктуру, а уже работающим надо тратить время на новичков, в итоге, удельная производительность новичка в масштабах проекта отрицательна, что в свете аврала проблему не уменьшает.
> Способные, например, при аврале бросить на задачу лишнюю сотню человек.У нас это называется "завалить проблему мясом". Не работает это ни хрена, проблем создает массу, но часть руководства (естественно самая "дальняя" от разработки) упорно верит, что так проблемы и решаются, хотя жизнь раз за разом и доказывает обратное.
>Если уволить весь не нужный планктон, в количестве 10 менеджеров на одного программиста,то экономия станет равна годовой прибыли
Но если вы их всех уволите то годовая прибыль следующего года оказажется равной количеству уволеных управленцев. Вас устроит 10 любых денег годового дохода?
Павлик, кажется ты немного погорячился, совсем-то без манагеров тоже нельзя. Кто же будет отбивать атаки клиентуры и прикрывать тебя своей волосатой грудью ? Хотя конечно кровь манагеры тоже любят пить, но тут взаимный симбиоз получается - ты им немного крови, а они тебе рабочее место.
Ладно, это уже философия...
> Ладно, это уже философия...Как тебе сказать? Основная проблема фрилансеров которые работают сами на себя - это то что приходится иметь дело с больными на всю голову му..ками.
> Основная проблема фрилансеров которые работают сами на себя - это то
> что приходится иметь дело с больными на всю голову му..ками.Не надо этого делать. Время, сэкономленное при помощи отказа в отслуживании гигантским дятлам, обычно приносит гораздо больше плодов (и не меньше дохода), будучи потраченным с нормальными людьми, даже если таковые попадаются реже. А в какой-то момент оказывается, что вместо того, чтобы вариться среди тех, кого цензурно назвать не можешь -- общаешься и работаешь с людьми, среди которых дятлы -- редкое и досадное исключение.
Удачи.
Плюсую, «приходится иметь дело с больными на всю голову» — это проблема лишь неразборчивых фрилансеров, хватающихся за всё подряд. Делать только то, что интересно делать, и иметь дело только с людьми как минимум не отталкивающими — залог здоровья, хорошего настроения и в результате большей отдачи.
Они любят ни сколько кровь пить, сколько бабло получать. То которое наробил программист и прочие ИТР. Причём получать любят в количествах больших, чем те кто его наробил. А так то да. У них конечно есть свои реальные задачи в общей структуре производства.
Выгода от продвижения патча в основное ядро Linux составляет до 250 тысяч долларов в год... и несколько десятков нервных клеток Линуса Торвальдса. Давайте теперь все закоммитим по патчу!
Может даже несколько десятков сэкономленных нервных клеток, кстати - потому что патчи, как ни крути, решают какие-то реальные проблемы.
> Выгода от продвижения патча в основное ядро Linux составляет до 250 тысяч
> долларов в год... и несколько десятков нервных клеток Линуса Торвальдса. Давайте
> теперь все закоммитим по патчу!Выгода в данном случае - это не доход 250000, а неистраченные 250000. Почуствуйте разницу...
Очень хорошая новость. А-то помнится некоторые удивлялись тому, что L. Torvalds не хочет вставлять бинарники в ядро.Кстати, новость ещё полезна тем, что даёт количественный аргумент в пользу публикации драйверов под GPL.
>> тратить на выполнение работ, дублирующих аналогичную работу в других компанияхРаботники компании зарабатывающие копипастом
> Работники компании зарабатывающие копипастомТак 90% тех, у кого в названии должности гордое "программист", этим и зарабатывают. Либо копированием, либо дублированием.
я закоммитил патч в ядро, где можно получить мои 250 тысяч?
Обращаться к своему менеджеру,при отсутствии такового-вы лохонулись.
> я закоммитил патч в ядро, где можно получить мои 250 тысяч?Посмотрел: ты врёшь - нет там твоего коммита.
Откуда взята цифра?
> Откуда взята цифра?Какая именно цифра в приведённых числах тебя интересует?
Высосана из пальца. Подробнее:Ситуация А: все компании делают доработки независимо друг от друга. Каждая платит зар.плату программистам. Средние суммарные расходы (и как они их посчитали?) на зар.плату по всем компаниям составляют 250 т.$ на каждый патч.
Ситуация Б: компания за свой счёт сделала необходимые доработки и выложила их в публичный доступ, остальные компании не стали тратить время и деньги, т.е. получили конкурентное преимущество.
Итог: ситуация Б в целом выгоднее ситуации А на 250 т.$.
Авторы статьи не знают (или сознательно "забывают") о такой элементарной вещи, как аналоги парадокса Браеса, сформулированные для финансов.
Тем не менее, большинство компаний предпочитают жилить свои патчи, используя ядро только в своих целях. Всяческие производители железа, андроидоклепатели.
Они еще предпочитают юзать древнее ядро, например могильник Ubuntu
> Они еще предпочитают юзать древнее ядро, например могильник UbuntuАга, Сталина на них нет.
> Тем не менее, большинство компаний предпочитают жилить свои патчи, используя ядро только
> в своих целях. Всяческие производители железа, андроидоклепатели.и Red Hat со своим одностраничным мегапатчем, СПЕЦИАЛЬНО затрудняющим анализ патченного кода ядра Linux.
http://www.opennet.me/opennews/art.shtml?num=29807
///---
Начиная с RHEL 6 поставляется только один общий архив с ядром, все патчи в котором неразделимо смешаны, что не позволяет выявить отдельные патчи и практически полностью сводит на нет возможность стороннего анализа.
---///
> Тем не менее, большинство компаний предпочитают жилить свои патчи, используя ядро только
> в своих целях. Всяческие производители железа, андроидоклепатели.Их проблемы.
Учитывая количество различных дистрибутивов Линя - у энтузиастов количество ресурсов до фига и больше.
> Учитывая количество различных дистрибутивов Линя - у энтузиастов количество ресурсов до
> фига и больше.В будние дни на сон уходит 8 часов и еще столько же на работу. Остальное время - твое. А ведь есть еще и выходные.
> В будние дни на сон уходит 8 часов и еще столько же
> на работу. Остальное время — твое. А ведь есть еще и
> выходные.а ещё — далеко не всем надо отрабатывать на галерах.
Вот эта выгода и есть основная сила, которая движет компаниями, участвующими в разработке OpenSource продуктов. А вовсе не сила лицензии GPL(как в это свято верует Столлман). Проекты становятся всё сложнее, и пилить проекты уровня ядра Linux в одиночку не под силу даже компаниям уровня Google и Oracle. Рано, или поздно, и Microsoft не осилит развитие Windows в одиночку. OpenSource победит не благодаря своей идеологии. Бизнесу(эффективному бизнесу) наплевать на идеологию, и даже на мораль. OpenSource победит благодаря выгоде от совместной разработки очень сложных проектов.
> как в это свято верует Столлманон сам тебе это сказал? круто!
А я бы порадовался. Наконец-то пацаны догадались, зачем нужна GPL крупному бизнесу. А ещё лет через 10 они наверняка догадаются, что дедушка Столлман таки продумал пару ходов вперёд. ("в 30 лет мои родители резко поумнели" :-)
дык вот rms достаточно умён, чтобы не заниматься ерундой вроде «святоверования». я об этом, собственно.
> я об этом, собственно.Понятно дело. Но ты как-то без оптимизма смотришь в будущее. А ведь осталось ещё каких-то 10 лет, и дойдёт!
> Понятно дело. Но ты как-то без оптимизма смотришь в будущее.наоборот, очень даже с оптимизмом: мы все скоро умрём.
Есть такая дисциплина Test-driven development (TDD). Если ей следовать, то затраты на поддержку и развитие унаследованного кода минимальны. ;)
> Есть такая дисциплина Test-driven development (TDD). Если ей следовать, то затраты на
> поддержку и развитие унаследованного кода минимальны. ;)…потому что все усилия уходят на написание тестов.
Круто.
toshiba же отдалась hitachi вроде бы. Или это только нжмд-производство?