А может, оно и к лучшему...? "Причешем" сами...?]]>
Он сидел на зарплате?
конечно нет. если б он сидел на зарплате, ему никто не разрешил бы такое вытворять
]]>тот же Фабрис Беллар, убил кучу времени на бесполезный порт qemu на javascript, просто потому что ему было интересно, остановив реально нужную разработку оптимизации использования hugepages в qemu. все уже давно сделано, но тогда это могло сорвать сроки поставки версии
Он сидел на зарплате?
]]>тот же Фабрис Беллар, убил кучу времени на бесполезный порт qemu на javascript, просто потому что ему было интересно, остановив реально нужную разработку оптимизации использования hugepages в qemu. все уже давно сделано, но тогда это могло сорвать сроки поставки версии
]]> Да я не гоню ни на RedHat ни на Каноникал. Я в убунте недавно, да и говорю не про продакшен. Но. Вы правы. Стандарты - должны быть. Причём, независимо от дистрибутива и цели его выпуска. Сколько уже об этом говорилось...
должны быть стандарты и управление. без этого все превращается в дикий абсурд. я сейчас ковыряю openstack, в котором нет конкретного лидера, и это изрядная проблема. программисты проводят 90% времени не в написании кода, а в спорах по поводу того нужен ли их фичер или патч. старый, корявый код отстаивается авторами, которые ни armorácia не смыслят в виртуализации и облаках, но которые были в проекте раньше, а значит и авторитет у них выше.
короче бардак ужаснейший, хотя и стандартизация кое-какая есть. если бы и ее не было, мне страшно подумать насколько все было бы плохо
Я в убунте недавно, да и говорю не про продакшен. Но. Вы правы. Стандарты - должны быть. Причём, независимо от дистрибутива и цели его выпуска. Сколько уже об этом говорилось... 
]]>А он и присутствует сейчас. Кто возмётся за эту стантартизацию? Бюрократы? Тогда сто лет. Марк? Да ему не до этого... Тут бы успеть до следующего релиза... Ракета медленнее летает
я не знаю как там в каноникле обои клепаются, но в RH, все процессы очень четкие. есть разработчики, перед ними ставятся технические задачи тимлидами, которым общие задачи и направления ставят продакт манагеры, которые в свою очередь контактируют с клиентами и продаванами (которые тоже постоянно общаются с клиентами). Получается с одной стороны движение в сторону требований клиентов, с другой стороны порядок и стандартизация в поставляемых продуктах
]]>каждый делает что хочет, обязательно будет бардак.
А он и присутствует сейчас. Кто возмётся за эту стантартизацию? Бюрократы? Тогда сто лет. Марк? Да ему не до этого... Тут бы успеть до следующего релиза... Ракета медленнее летает
Изучают бизнесс (к примеру) процессы и уже под них подбирают оптимум с учетом экономической выгоды. А не подстраивают эти процессы под стандарты it (ну, или я такого еще не видел)
это интеграторы. или по терминологии RH solution architects. Но они опять же подгоняют готовые решения стараясь свести кастомизацию к минимуму, а не разрабатывают велосипеды
Т.е. сами it стандарты далеко не покрывают все стороны деятельности, особо в свете бурного роста it индустрии. Я не говорю про разработчиков, которые пилят продукты на рынок крупных игроков. Им да, оптимально работать в единой среде.
ну так стандартов много, фирма решает для себя какие ей подходят, но когда их нет, и каждый делает что хочет, обязательно будет бардак.
]]>RH приносит стабильность и стандартизацию.
Изучают бизнесс (к примеру) процессы и уже под них подбирают оптимум с учетом экономической выгоды. А не подстраивают эти процессы под стандарты it (ну, или я такого еще не видел). Т.е. сами it стандарты далеко не покрывают все стороны деятельности, особо в свете бурного роста it индустрии. Я не говорю про разработчиков, которые пилят продукты на рынок крупных игроков. Им да, оптимально работать в единой среде.
]]>Во многих конторах так и происходит потому, что
1. Нет оптимального дистрибутива
2. Нет управления it
3. Недостаточная кометенция тех, кто прикладывает к it руку
ну, как бы, для нормального софта есть нормальные решения, без самосборов и самописов. Я и сам иногдаловлю себя на том что лезу в код проекта который отказывается работать из коробки, но я не считаю это нормальным, всегда открываю баг у авторов, и когда появляется исправление, сношу свою поделку и ставлю нормальный пакет.
IT должен быть управляемым и легковоспроизводимым. Если этого нет, то фирма в самой настоящей опасности, и таких админов и их начальство надо гнать.
1. ~90% в soho и smb ничего не документируется
2. Согласен
3. ~70% в soho и smb
Я к чему? Я к тому, что бесмысленно говорить, что RH это оптимум, а всё остальное сливать в унитаз. Из примеров видно: самая большая проблема - человеческий фактор.
RH приносит стабильность и стандартизацию. Вы правы, проблемы человеческого фактора нельзя решать техническими средствами, но если дать человеческому фактору адекватные инструменты с одной стороны, и жестко ограничить в идиотизме^W самодеятельности с другой (а это и есть стандартизация) остальное уже получает возможность встать не места само по себе, за неимением возможности уйти из под контроля. Элементарное огранничение на горожение зоопарка из ОС уже сильно упрощает жизнь, стандартизируемся на определенном наборе софта, желательно стандартного, без экзотики, и вуаля - огромная куча проблем исчезает сама по себе, или, если все нормально планировать - не имеет возможности появиться.
RH не панацея, но набор решений отлично покрывает нужды практически любых организаций, так что стандартизация уже готова, из той самой коробки. Добавляем возможность ставить центос там где бюджет жмет, сертификацию админов (причем вполне настоящую, а не бумажки как MCSE) и получаем тот самый, стандартизированный, легкопроизводимы процесс айти.
Ну, не совсем. Софт - это кирпичи. Сам по себе он мало чем полезен, как правило. Обычно хотят такой функционал, который упирается в сзязывание десятка софта в единую систему. Вот это процесс связывания и есть то, кто никто толком не знает кроме того, кто это делал.
тоже не верно. есть вполне стандартные связки, которые покрывают 99% нужд, которые известны и не требуют лишних телодвижений. Они зачастую довольно сложны, но от этого не менее стандартны.
Ага, вот прямо так в лёгкую и играючи На каждом рабочем месте.
при знании продукта - легко и играючи. я вот oVirt или Zimbra, могу за час развернуть в полноценный production, потому что делал это много, часто, и продукт знаю досконально. сейчас делаю автоматические установки openstack - все было сложно поначалу, но процесс только ускоряется по мере того как все меньше приходится смотреть в документацию (и да, в код тоже к сожалению)
]]>навесим сверху edeploy или foreman, и можно реплицировать такие серверы тысячами. прикручиваем satellite или puppet и можно управлять их настройками
Ага, вот прямо так в лёгкую и играючи На каждом рабочем месте.
оки, я собрал на коленке LFS, понаписал конфигов и распихал всякие самосборные из сорса бинарники по всем дырам. потом уволился (или убился об стенку).
Во многих конторах так и происходит потому, что
1. Нет оптимального дистрибутива
2. Нет управления it
3. Недостаточная кометенция тех, кто прикладывает к it руку
Да, LFS это ты загнул в целом. Но идея понятна. Идём в гугл и видим 100500 админских бложиков с рецептами на центосах: configure && make && make install, запуск сервисов через rc.local и т.д и т.п. 21 век однако. Но, дистрибутив -то не причем, правильно?
приходит другой админ, смотрит на это чудо велосипедостроения, и имеет три выхода
1. попытаться во всем этом разобраться, если КАЖДЫЙ шаг не был документирован, то это почти невозможно
2. все снести и поднять свое - нормально или велосипед - это уже каждый ССЗБ
3. оставить как есть и приносить до конца своих дней в жертву по черному козлу, чтоб все не упало, и что страшнее - чтоб не пришлось менять или апдейтить.
1. ~90% в soho и smb ничего не документируется
2. Согласен
3. ~70% в soho и smb
Я к чему? Я к тому, что бесмысленно говорить, что RH это оптимум, а всё остальное сливать в унитаз. Из примеров видно: самая большая проблема - человеческий фактор.
я могу еще много примеров привести, все сводится примерно к тому же - велосипеды работают пока над ними копошится их разработчик, без него - все разваливается. Нормальный, поддерживаемый софт работает вне зависимости от того кто им управляет, были бы руки прямыми.
Ну, не совсем. Софт - это кирпичи. Сам по себе он мало чем полезен, как правило. Обычно хотят такой функционал, который упирается в сзязывание десятка софта в единую систему. Вот это процесс связывания и есть то, кто никто толком не знает кроме того, кто это делал.
]]>А вы для такой системы документацию писать не будете???! Я бы для такой системы, как минимум для себя, написай бы доку ибо через месяц что-то отвалиться я ж нифига не вспомню что я там крутил!
P.S. Извиняюсь за ошибки.
отлично. док написан. портянка длиной в тору с новым заветом в придачу. сделаем вид что каждый админ сидит и пишет свой собственный gentoo book, так же подробно и пошагово.
что то отвалилось, надо восстановить систему с нуля - будем повторять все шаги, пока юзеры вопят? сколько это займет? а теперь сравним сколько это же займет на нормальной системе, с пакетами и готовыми конфигами. навесим сверху edeploy или foreman, и можно реплицировать такие серверы тысячами. прикручиваем satellite или puppet и можно управлять их настройками, апдейтами и состоянием вообще до упора. Только все эти вкусности для самосбора не годятся.
]]>Эм и какой для себя выбрали альтернативный дистрибутив ?
На работе на серверах Debian 7. На домашнем сервере и на рабочей машине Gentoo. Если Debian 8 в стабильную ветку выйдет с systemd то буду пытать начальство на предмет железа помощней и ставить генту. Собсна ни кого не хочу обидеть, но если бы на работе было норм железо давно была бы гента. Просто так получилось что свое знакомство с Linux я начал с Gentoo и привык к ней. Debian мне нравиться для простеньких задач типа шлюз, маршрутизатор, проксик и т.д. его как винду "Next -> Next -> ok" ставишь и он работает, генту для таких задач, даже stage4, разворачивать лень xD
оки, я собрал на коленке LFS, понаписал конфигов и распихал всякие самосборные из сорса бинарники по всем дырам. потом уволился (или убился об стенку).
приходит другой админ, смотрит на это чудо велосипедостроения, и имеет три выхода
1. попытаться во всем этом разобраться, если КАЖДЫЙ шаг не был документирован, то это почти невозможно
А вы для такой системы документацию писать не будете???! Я бы для такой системы, как минимум для себя, написай бы доку ибо через месяц что-то отвалиться я ж нифига не вспомню что я там крутил!
P.S. Извиняюсь за ошибки.
]]>