Копирайтеру неплохо бы изучить историю вопроса по первоисточнику (благо, в официальном блоге её достаточно), прежде чем начинать фантазировать об «утраченном потенциале».
Скажем так, большая часть озвученного не имеет никакого отношения к действительности.
WSL 1 основана не на подсистеме окружения (как на древнем слайде из Википедии), а на пико-процессах. Это совершенно иная реализация с точки зрения архитектуры. POSIX/Interix/SFU действительно были когда-то сделаны как подсистемы, но WSL 1 устроена попросту абсолютно иначе.
Касательно рассуждений о трансляции системных вызовов. Она частично присутствует. Некоторые эмулируются, некоторые пробрасываются через обёртки, а для некоторых (таких как fork), в ядро NT были внесены нативные реализации, которые LXSS дёргает напрямую. И об этом тоже прямо писалось в официальном блоге. Да, теперь NT умеет настоящий никсовый fork/exec, представьте себе. Так что «не умеет» — это не соответствует действительности. Умеет, ещё как, и уже достаточно давно.
Огорчает, что на некогда техническом ресурсе публикуются такие малограмотные спекуляции.
Будучи в те времена админом с довольно большим парком каких угодно персоналок, я себе домой после Селерона, на котором хорошо было тренироваться в разгон 300 до 400 с лишним МГц, взял Athlon XP.
А всё потому, что первые P4, пришедшие ко мне в распоряжение, были не просто медленными, но и прироста производительности при разгоне давали крайне мало, хотя начинали греться как чёрт знает что. От чего периодически и умирали. Кулеры тогда ещё не очень умели делать. (Хуже них дохли только Дюроны — эти вообще при перегреве могли взорваться, потому как кристалл маленький, и без теплораспределительной крышки). Потом получше стали, но полноформатные камни AMD по соотношению цена-производительность их всё равно уделывали.
А вот четырёхъядерный Core 2 у меня в строю до сих пор. Матушка пользуется им в качестве пишущей машинки, с Офисом он вполне справляется.
Во! Бабах получается отличный. А с чёрными дырами такой фокус не пройдёт.
Тут ещё можно порассуждать, что будет, если взаимная скорость в паре окажется достаточно большой для препятствия схлопывания ошмётков в один объект, и порванные куски, разлетаясь, начнут раскукоживаться из вырожденного состояния до нормальной материи. Вот какой минимальный размер нейтронной капли, чтобы она оставалась таковой? Весом в нептун (где-то находил модель, которая это предсказывает), или чуть побольше? И что может натворить такой кусочек в каком-нибудь скоплении, улетая с субсветовой скоростью? Жутко интересно же. И видяшечек на ютюбе про это дело явно маловато.
В данный момент я занимаюсь geospatial аналитикой на Spark в амазоновском облаке, у меня вообще веб-интерфейсика нет… Зато есть расчёт рентабельности проектов, например.
Унификация практик (в разумных пределах) — штука очень хорошая, даёт неплохой выигрыш по себестоимости разработки.
Относительно вреда отдельных команд мало кто понимает, к сожалению. Почему-то управленцы стремятся как раз всех поделить, и приходится тратить кучу сил, чтобы убедить их перестать это делать.
Сложно, это верно. Надо много чего знать, причём сильно в ширину.
Но я, например, имею 15-летний опыт сеньорства в командах размером от 2 до 50 человек, и занимался всем на свете (от скриптования на PHP до оракловых БД, от энтерпрайзщины на EE до автотестов, от техписательства до проектирования UX), включая преподавание. Был техлидом и «архитектором» (не люблю, когда system designer так переводят). Эт помимо редхатовской сертификации по Enterprise Linux и кучи времени, потраченных на geospatial проекты. Поэтому я могу выступать в роли такого методиста, чем и занимаюсь уже который год.
Коллега, вы мыслите в рамках работы с кодом, максимум с технической инфраструктурой.
Я же смотрю на процессы несколько шире. Продукт — это далеко не только код и инфра. Это документация, техподдержка, локализация, бухгалтерия, и ещё куча всякого сопутствующего, включая рекламу в профильных изданиях. Бизнес работает вокруг продукта, а не сугубо технических вещей.
И DevOps — это как раз про автоматизацию бизнеса в целом. Когда все процессы ведутся так, как будто бы это работа с кодом.
Вот скажите, вы точно уверены, что в ваши обязанности входит автоматизация customer relations и автоматизация перевода продукта на 15 языков?
Открою страшную тайну: специалистов широкого профиля, которые так себя позиционируют, крайне немного.
А вот разработчиков, которых заставляют изучать какой-нибудь терраформ, или админов, которым приходится писать инсталляторы — объясняя, что «у нас же DevOps», — намного больше. И мало кому это нравится, жалобы на такие «странные» требования я слышу постоянно.
Но девопс не означает, что стоит требовать от людей заниматься категорически не своим делом. Девопс означает, что operations-инженер должен быть включён в единый процесс, в котором есть место и для админа, и для разработчика, и главное, налажена связь между всеми участниками через общий трекер и, возможно, даже общий репозиторий.
Вы, я так понимаю, специалист именно по operations, и ваш основной фокус — процессы. А я, например, техлид, и мой основной фокус — проектирование, прототипирование, и ревью.
Бизнесам очень сложно осознать, что надо менять процессы (включая процессы руководства бизнесом, конечно же), а не пытаться нанимать людей с неопределённо широким кругом умений, и вешать на них неопределённо широкий круг задач… Как я уже сказал, эт ни фига не работает.
(А «евангелист», между тем, не профессия, и даже не роль, а что-то типа играющего тренера. Тот, кто понимает, как менять процессы.)
DevOps — это набор методических рекомендаций, согласно которым все производственные процессы в компании строятся по таким же принципам, как при работе с кодом. То есть, всё, что только можно, версионируется, автоматизируется, тестируется, и обкладывается сбором статистики. От топологий железа до заключения договоров и техподдержки.
DevOps предполагает сборку единого, управляемого алгоритмически, конвейера доставки конечного продукта. (См. также «жизненный цикл».)
Если у вас есть выделенный человек на «DevOps задачи», значит, вы неправильно понимаете суть данного методического подхода, либо пытаетесь внедрить его в узкой нише, не затронув остальную часть процессов. Но так оно, как правило, не работает.
Также, конкретный инженер не обязан знать всё, что перечисляется на таких вот бессмысленных слайдах. Он может (и должен) заниматься своим делом, но при этом относиться к своей работе как к части конвейера доставки, но иметь представление о, и быть готовым отвечать за его корректное взаимодействие с остальными частями.
Спасибо, что выслушали. Искренне ваш, DevOps-евангелист.
Скажем так, большая часть озвученного не имеет никакого отношения к действительности.
WSL 1 основана не на подсистеме окружения (как на древнем слайде из Википедии), а на пико-процессах. Это совершенно иная реализация с точки зрения архитектуры. POSIX/Interix/SFU действительно были когда-то сделаны как подсистемы, но WSL 1 устроена попросту абсолютно иначе.
Касательно рассуждений о трансляции системных вызовов. Она частично присутствует. Некоторые эмулируются, некоторые пробрасываются через обёртки, а для некоторых (таких как fork), в ядро NT были внесены нативные реализации, которые LXSS дёргает напрямую. И об этом тоже прямо писалось в официальном блоге. Да, теперь NT умеет настоящий никсовый fork/exec, представьте себе. Так что «не умеет» — это не соответствует действительности. Умеет, ещё как, и уже достаточно давно.
Огорчает, что на некогда техническом ресурсе публикуются такие малограмотные спекуляции.
А всё потому, что первые P4, пришедшие ко мне в распоряжение, были не просто медленными, но и прироста производительности при разгоне давали крайне мало, хотя начинали греться как чёрт знает что. От чего периодически и умирали. Кулеры тогда ещё не очень умели делать. (Хуже них дохли только Дюроны — эти вообще при перегреве могли взорваться, потому как кристалл маленький, и без теплораспределительной крышки). Потом получше стали, но полноформатные камни AMD по соотношению цена-производительность их всё равно уделывали.
А вот четырёхъядерный Core 2 у меня в строю до сих пор. Матушка пользуется им в качестве пишущей машинки, с Офисом он вполне справляется.
Тут ещё можно порассуждать, что будет, если взаимная скорость в паре окажется достаточно большой для препятствия схлопывания ошмётков в один объект, и порванные куски, разлетаясь, начнут раскукоживаться из вырожденного состояния до нормальной материи. Вот какой минимальный размер нейтронной капли, чтобы она оставалась таковой? Весом в нептун (где-то находил модель, которая это предсказывает), или чуть побольше? И что может натворить такой кусочек в каком-нибудь скоплении, улетая с субсветовой скоростью? Жутко интересно же. И видяшечек на ютюбе про это дело явно маловато.
И чёрная дыра там получится в конце. Но маленькая, а потому очень злая.
Вот уж где физика экстремальнее всего остального на свете, за исключение может быть Большого Взрыва, но он был давно и один раз, а этих много.
В данный момент я занимаюсь geospatial аналитикой на Spark в амазоновском облаке, у меня вообще веб-интерфейсика нет… Зато есть расчёт рентабельности проектов, например.
Относительно вреда отдельных команд мало кто понимает, к сожалению. Почему-то управленцы стремятся как раз всех поделить, и приходится тратить кучу сил, чтобы убедить их перестать это делать.
Но я, например, имею 15-летний опыт сеньорства в командах размером от 2 до 50 человек, и занимался всем на свете (от скриптования на PHP до оракловых БД, от энтерпрайзщины на EE до автотестов, от техписательства до проектирования UX), включая преподавание. Был техлидом и «архитектором» (не люблю, когда system designer так переводят). Эт помимо редхатовской сертификации по Enterprise Linux и кучи времени, потраченных на geospatial проекты. Поэтому я могу выступать в роли такого методиста, чем и занимаюсь уже который год.
И нас таких немало.
Я же смотрю на процессы несколько шире. Продукт — это далеко не только код и инфра. Это документация, техподдержка, локализация, бухгалтерия, и ещё куча всякого сопутствующего, включая рекламу в профильных изданиях. Бизнес работает вокруг продукта, а не сугубо технических вещей.
И DevOps — это как раз про автоматизацию бизнеса в целом. Когда все процессы ведутся так, как будто бы это работа с кодом.
Вот скажите, вы точно уверены, что в ваши обязанности входит автоматизация customer relations и автоматизация перевода продукта на 15 языков?
Почему тогда вы называете себя DevOps-инженер?
Работает, но когда используется только для кода (без расширения на полный ЖЦ), не настолько эффективно, насколько может.
Что я имею в виду под «полной» поддержкой ЖЦ:
Всё это начинается с CD и строится вокруг него, но наличие CD — эт только начало пути.
И обычно там же и конец, что довольно прискорбно.
А вот разработчиков, которых заставляют изучать какой-нибудь терраформ, или админов, которым приходится писать инсталляторы — объясняя, что «у нас же DevOps», — намного больше. И мало кому это нравится, жалобы на такие «странные» требования я слышу постоянно.
Но девопс не означает, что стоит требовать от людей заниматься категорически не своим делом. Девопс означает, что operations-инженер должен быть включён в единый процесс, в котором есть место и для админа, и для разработчика, и главное, налажена связь между всеми участниками через общий трекер и, возможно, даже общий репозиторий.
Вы, я так понимаю, специалист именно по operations, и ваш основной фокус — процессы. А я, например, техлид, и мой основной фокус — проектирование, прототипирование, и ревью.
(А «евангелист», между тем, не профессия, и даже не роль, а что-то типа играющего тренера. Тот, кто понимает, как менять процессы.)
DevOps — это набор методических рекомендаций, согласно которым все производственные процессы в компании строятся по таким же принципам, как при работе с кодом. То есть, всё, что только можно, версионируется, автоматизируется, тестируется, и обкладывается сбором статистики. От топологий железа до заключения договоров и техподдержки.
DevOps предполагает сборку единого, управляемого алгоритмически, конвейера доставки конечного продукта. (См. также «жизненный цикл».)
Если у вас есть выделенный человек на «DevOps задачи», значит, вы неправильно понимаете суть данного методического подхода, либо пытаетесь внедрить его в узкой нише, не затронув остальную часть процессов. Но так оно, как правило, не работает.
Также, конкретный инженер не обязан знать всё, что перечисляется на таких вот бессмысленных слайдах. Он может (и должен) заниматься своим делом, но при этом относиться к своей работе как к части конвейера доставки, но иметь представление о, и быть готовым отвечать за его корректное взаимодействие с остальными частями.
Спасибо, что выслушали. Искренне ваш, DevOps-евангелист.
Мне было 26. Год ушёл на восстановление. С тех пор я просто не позволяю себе перерабатывать, как бы меня ни пёрло.