Что действительно случилось с Vista: инсайдерская ретроспектива

https://blog.usejournal.com/what-really-happened-with-vista-an-insiders-retrospective-f713ee77c239
  • Перевод

Традиционно группа разработчиков Windows подписывает постер (в данном случае изображение DVD) с выпуском новой версии Windows. Ко времени окончания вечеринки по поводу релиза на нём будут сотни или тысячи подписей

«Опыт — это то, что ты получаешь только после того, как он тебе понадобится» — Стивен Райт

Мне понравился содержательный блог Терри Кроули («Что действительно случилось с Vista»). Терри работал в группе Office и проделал фантастическую работу, описывая сложные козни вокруг Windows Vista и связаного, но заброшенного проекта Longhorn — с точки зрения внешнего наблюдателя.

Он верно подметил многие из проблем, которые преследовали проект, и я не хочу повторять о них снова. Я только подумал, что будет честно изложить инсайдерский взгляд на те же события. Не рассчитываю на такое же красноречивое или исчерпывающее изложение, как у Терри, но надеюсь пролить некоторый свет на то, что пошло не так. Прошло десять лет с момента выхода первой версии Windows Vista, но эти уроки сейчас кажутся актуальными как никогда.

Windows — это монстр. Тысячи разработчиков, тестеров, менеджеров программ, специалистов по безопасности, дизайнеров UI, архитекторов и т.д. И это не считая обслуживающего персонала из отдела кадров, рекрутеров, ребят из маркетинга, продажников, юристов и, конечно, множества менеджеров, директоров и вице-президентов по каждому из перечисленных направлений. Вся эта группа окружена многими тысячами сотрудников у наших партнёров (как внутри, так и за пределами Microsoft), которые поставляли всё: от оборудования и драйверов устройств до приложений, работающих на платформе.


Аэросъёмка группы разработки Windows на футбольном поле в Microsoft

В то время организационно Windows на самом деле делилась на три группы: Core, Server и Client. Группа Core поставляла «каркас»: все ключевые компоненты операционной системы, общие для всех версий Windows (само ядро, система хранения, безопасность, сетевая подсистема, драйверы устройств, модель установки и обновлений, Win32 и проч.). В свою очередь, серверная группа сосредоточивалась на технологиях для серверного рынка (службы терминалов, кластеризация и бесперебойная работа, инструменты корпоративного управления и др.), а клиентская группа отвечала за технологии, связанные с десктопной и пользовательской версией (веб-браузер, медиаплеер, графика, оболочка и др.).

Конечно, происходило много реорганизаций, но основная структура всегда сохранялась, даже когда популярность Windows выросла, а сами группы увеличились в размере. Также будет справедливо сказать, что с культурной и организационной точки зрения группа Core была ближе к серверной, чем к клиентской группе — по крайней мере, так было до выхода Vista.

Ко времени моего прихода в Microsoft в начале 1998 года Windows означало Windows NT — архитектурно, организационно и в отношении самого продукта. От кодовой базы Windows 95 по большей степени отказались, а Windows NT внедрили для каждой разновидности Windows — от ноутбуков до серверов в кластере. Спустя два года кодовую базу Windows 95/98 должны были воскресить для одного последнего релиза — той самой Windows ME, о которой так много злословили — но этот проект вела маленькая группа, в то время как абсолютное большинство работало на кодовой базе NT. Мне повезло провести более десяти лет в чреве монстра. Я начал в разгар разработки Windows 2000 и оставался до завершения Windows 7.

Первые семь лет я провёл в группах, ответственных за систему хранения, файловые системы, бесперебойную работу/кластеризацию, сетевые протоколы файлового уровня, распределённые файловые системы и связанные технологии. Позже я провёл год или два в группе управления безопасностью Microsoft. Она включала в себя всё от технологий безопасности в Windows до антивирусных продуктов, маркетинг безопасности и экстренное реагирование, такое как выпуск обновлений безопасности. Это было ближе к концу жизненного цикла Vista, когда вирусы и черви поставили Windows на колени и когда репутация Microsoft как разработчика защищённого и безопасного программного обеспечения подверглась массовому избиению на публике.

Последние три или четыре года, во время подготовки выпуска Windows 7, я управлял всей разработкой группы Core в Windows. Это означает владение практически всеми технологиями, которые работают «под капотом» и используются и серверной, и клиентской группой. После выпуска Vista всю команду Windows организовали по направлениям и по триадам (Dev, Test, PM) на всех уровнях организации, так что у меня было двое соучастников по преступлению. Я руководил группами разработки, в то время как они руководили, соответственно, группами тестирования и группами менеджмента.

Команда Windows в прошлом нередко пыталась осилить амбициозные и массивные проекты, которые спустя несколько лет забрасывали или перепрофилировали. Предыдущий пример — амбициозный проект Cairo, который в итоге распотрошили: спаслись лишь некоторые его части, включённые в состав Windows 2000.

По моему скромному мнению, до сих пор крупнейшей проблемой с выпуском Windows была продолжительность каждого релиза. В среднем каждый релиз занимал три года от начала разработки до завершения, но только 6-9 месяцев этого времени занимала разработка «нового» кода. Остальное время уходило на интеграцию, тестирование, альфа- и бета-этапы — каждый по несколько месяцев.

Некоторым проектам требовалось больше шести месяцев на ключевую разработку, так что они создавались параллельно и сливались с основной кодовой базой по завершении. Это означает, что основная ветка всегда была в подвешенном состоянии по мере того как в неё добавляли или меняли большие куски функциональности. При разработке Windows 7 установили гораздо более жёсткий контроль, чтобы гарантировать непрерывно здоровую и функционирующую кодовую базу, но предыдущие версии были в постоянно нездоровом состоянии с нестабильностью в течение нескольких месяцев подряд.

Хаотическая природа разработки часто приводила к тому, что группы разработки играли в опасные игры с расписанием. Они убеждали себя и других, что их код в лучшем состоянии, чем другие проекты, что они могут «отшлифовать» оставшиеся фрагменты точно в срок, так что им позволяли поставить свой компонент в полуготовом виде.

Трёхлетний цикл релиза означал, что мы редко представляли себе, как будет выглядеть конкурентный ландшафт и внешняя экосистема на момент релиза. Если разработка функции не успевала к релизу, то от неё совсем отказывались (поскольку она вряд ли имела смысл через 6 лет после начала разработки) или, что хуже, её «отсылали в Сибирь», то есть продолжали разработку компонента, который по большей части игнорировала вся остальная организация и который был обречён на неудачу или бесполезность — но группа или руководство просто не могли принять решение об отказе от разработки. Я лично нёс ответственность за несколько таких проектов. Зрение при взгляде в прошлое становится стопроцентным.

Учитывая, что каждая команда была занята продвижением в релиз собственного плана и набора функций, она зачастую манкировала интеграцией с другими компонентами, пользовательским интерфейсом, end-to-end тестированием, а также такими неприятными и утомительными вещами как обновление, оставляя эти трудные вещи на потом. В свою очередь, это означало, что некоторые группы быстро становились узким местом всей разработки, и в последнюю минуту все бежали им на помощь в завершении работы над UI или тестированием механизма обновления.

В каждый момент времени в разработке находилось несколько крупных релизов, а также многочисленные побочные проекты. Разные группы отвечали за кодовые базы в разном состоянии готовности, что со временем приводило к результату, где «богатый становится богаче, а бедный — беднее». Группы, которые начинали отставать, по той или иной причине, обычно так и оставались позади.

Когда проект приближался к завершению, программные менеджеры начинали составлять требования к следующему релизу, а группы в «здоровом» состоянии (богатые) начинали внедрять новый код, тогда как бóльшая часть организации (бедные) по-прежнему копалась с текущим релизом. В частности, группы тестирования редко освобождались до выпуска релиза, так что в начале проектов новый код не был тщательно протестирован. «Нездоровые» группы всегда отставали, делая последние штрихи для текущего релиза и отставая всё дальше и дальше. Именно в этих группах зачастую трудились разработчики с самым низким уровнем морального состояния и наиболее истощённые. Это значит, что новые сотрудники групп [взамен ушедших истощённых — прим.пер.] наследовали хрупкий код, который они не писали и поэтому не понимали.

На протяжении почти всего срока разработки Vista/Longhorn я нёс ответственность за систему хранения и файловые системы. Это значит, что я был вовлечён в проект WinFS, хотя его вели преимущественно сотрудники группы SQL СУБД, родственной структуры для команды Windows.

Билл Гейтс лично участвовал в проекте на очень детальном уровне, его даже в шутку называли «менеджером проекта WinFS PM». Сотни, если не тысячи человеко-лет потратили на проработку идеи, чьё время просто ушло: что если объединить возможности запросов СУБД и функциональность файловой системы по потоковой передаче и хранению неструктурированных данных — и открыть это как парадигму программирования для создания уникальных новых насыщенных приложений.

Задним числом теперь очевидно, что Google умело решила эту проблему, обеспечив прозрачную и быструю индексацию неструктурированных данных. И они сделали это для всего интернета, а не только для вашего локального диска. И вам даже не нужно переписывать свои приложения, чтобы воспользоваться преимуществами этой системы. Даже если бы проект WinFS завершился успехом, понадобились бы годы на переписывание приложений, чтобы они могли воспользоваться её преимуществами.

Когда Longhorn отменили, а из её тлеющих углей поспешно собрали Vista, систему WinFS уже выкинули из релиза ОС. Группа SQL ещё несколько лет продолжала работу над ней как над отдельным проектом. К этому времени в Windows появился встроенный движок индексации и интегрированный поиск — реализованный чисто на стороне без необходимости изменения в приложениях. Так что необходимость в WinFS стала ещё более неясной, но проект по-прежнему продолжался.

Массивные архитектурные изменения, связанные с безопасностью в Longhorn, продолжались в рамках проекта Windows Vista после «перезагрузки» Longhorn. Мы многое узнали о безопасности в быстро расширяющейся вселенной интернета и хотели применить эти знания на архитектурном уровне ОС для улучшения общей безопасности всех пользователей.

У нас не было выбора. Windows XP показала, что мы стали жертвами собственного успеха. Спроектированная для удобства система явно не соответствовала требованиям безопасности, столкнувшись с реальностью интернет-эпохи. Для решения этих проблем безопасности требовалось создание параллельного проекта. Windows XP Service Pack 2 (несмотря на своё название) стал огромной затеей, которая высосала тысячи ресурсов из Longhorn.

В нашем следующем крупном релизе ОС мы точно не могли сделать шаг назад в требованиях к безопасности. Так что Vista стала намного более безопасной, чем любая другая ОС, которую когда-либо выпускала Microsoft, но этот процесс умудрился сломать совместимость приложений и драйверов устройств на беспрецедентном уровне для экосистемы. Пользователи ненавидели её, потому что их приложения не работали, а наши партнёры ненавидели её, потому что им казалось, что у них недостаточно времени для обновления и сертификации своих драйверов и приложений, поскольку Vista торопилась к релизу для конкуренции с возродившейся Apple.

Во многих смыслах эти изменения безопасности требовали от сторонних приложений внесения глубоких архитектурных изменений. А большинство вендоров экосистемы не были готовы так много вкладывать в изменение своих легаси-программ. Некоторые из них применили нетрадиционный подход для изменения структур данных и даже инструкций в ядре, чтобы реализовать свою функциональность, обойти штатные API и для многопроцессорной блокировки, что часто вызывало хаос в системе. На каком-то этапе около 70% всех «синих экранов» Windows были вызваны этими сторонними драйверами и их нежеланием использовать штатные API для реализации своей функциональности. Особенно часто такой подход использовали разработчики антивирусов.

Я как руководитель отдела безопасности в Microsoft лично потратил несколько лет, объясняя производителям антивирусов, почему мы больше не разрешим им «патчить» инструкции ядра и структуры данных в памяти, почему это представляет риск для безопасности и почему им в дальнейшем следует использовать штатные API, что мы больше не будем поддерживать их легаси-программы с глубокими хуками в ядро Windows — теми самыми методами, которые применяют хакеры для атаки пользовательских систем. Наши «друзья», производители антивирусов, развернулись и подали на нас в суд, обвинив нас в том, что мы лишаем их средств к существованию и злоупотребляем своим монопольным положением! С такими друзьями кому нужны враги? Они просто хотели, чтобы их старые решения продолжали работать и дальше, даже если это означает снижение безопасности наших общих пользователей — а ведь именно эту безопасность они должны были улучшать.

За эти годы произошло так много кардинальных изменений в компьютерной индустрии — приход интернета, распространение мобильных телефонов, появление облачных вычислений, создание новых бизнес-моделей на базе рекламы, вирусный рост социальных медиа, неумолимое шествие закона Мура и популярность свободного программного обеспечения. Это лишь некоторые факторы, которые атаковали Windows со всех сторон.

Ответ был вполне логичным для дико успешной платформы: упрямо продолжать курс и постепенно улучшать существующую систему — дилемма инноватора в двух словах. Чем больше мы добавляли кода, тем сложнее становилась система, тем больше увеличился штат сотрудников, тем больше росла экосистема и тем сложнее было наверстать растущее отставание от конкурентов.

Словно нажима конкуренции было недостаточно, в одно время целые армии наших инженеров и программных менеджеров тратили бесчисленные часы, дни, недели и месяцы на общение с представителями Министерства юстиции и корпоративными адвокатами, чтобы задокументировать существующие API от предыдущих релизов для выполнения правительственных антимонопольных постановлений.

Суровая реальность в том, что на тот момент жизненного цикла понадобилось примерно три года, чтобы выпустить основной релиз Windows и это было слишком долго для быстро меняющегося рынка. WinFS, безопасность и управляемый код — вот лишь некоторые из массивных проектов, которые стояли на повестке Longhorn. А были сотни более мелких ставок.

Когда у вас организация из многих тысяч сотрудников и буквально миллиарды пользователей, то нужно предусмотреть абсолютно всё. Тот же релиз ОС, который предполагалось запустить на планшетах и смартфонах, также должен был работать на вашем ноутбуке, на серверах в дата-центре и во встроенных устройствах типа сетевых хранилищ, коробочек “Powered by Windows” — не говоря уже о работе поверх гипервизора (HyperV) в облаке. Эти требования тянули команду в противоположные стороны, поскольку мы пытались добиться прогресса на всех сегментах рынка одновременно.



Невозможно рассматривать Longhorn и Vista по отдельности. Они имеют смысл только в сочетании с версиями непосредственно перед и после них — Windows 2000 и XP с одной стороны, Windows Server 2008 и Windows 7 с другой — и полным пониманием широкого контекста индустрии в ретроспективе.

Windows стала жертвой собственного успеха. Она успешно покорила слишком много рынков, и бизнес в каждом из этих сегментов теперь проявлял некоторые влияние на дизайн операционной системы и тянул его в разных направлениях, часто несовместимых друг с другом.

Исключительно успешная в 90-е годы архитектура просто захлебнулась спустя десятилетие, потому что мир вокруг изменялся слишком быстро, пока организация пыталась за ним успеть. Для ясности, мы видели все эти тренды и усиленно пытались соответствовать им, но если позволите смешать метафоры, трудно развернуть воздушный лайнер в противоположную сторону, если вы на втором году беременности своего трёхлетнего релиза.

Вкратце, то что мы знали три-четыре года назад при планировании данного релиза ОС, стало смехотворно устаревшим, а иногда явно неправильным, когда продукт наконец-то вышел. Лучшее, что мы могли сделать — это перейти на постепенную и безболезненную доставку новых облачных сервисов на всё упрощающееся устройство. Вместо этого мы продолжали добавлять функции в клиентскую монолитную систему, что требовало многих месяцев тестирования перед каждым релизом, замедляя нас тогда, когда мы должны были ускоряться. И конечно, мы не заботились об удалении старой функциональности, которая нужна для совместимости с приложениями от старых версий Windows.

Теперь представьте поддержку одной и той же ОС на протяжении десяти лет или больше для миллиардов пользователей, миллионов компаний, тысяч партнёров, сотен вариантов использования и десятков форм-факторов — и вы начнёте вступать в кошмар поддержки и обновления.

Глядя в прошлое, Linux оказался более успешным в этом отношении. Несомненной частью решения стало сообщество open source и такой подход к разработке. Модульная и подключаемая архитектура Unix/Linux — тоже значительное архитектурное улучшение в этом отношении.

Рано или поздно любая организация начинает выдавать в качестве продукта свою организационную диаграмму, и Windows не исключение. У open source нет такой проблемы.


«Военная комната» Windows, позже переименованная в «мостик» (ship room)

Если хотите, добавьте к этому внутреннюю организационную динамику и личности. У каждого из нас были свои любимые фичи, партнёры из нашей собственной экосистемы подталкивали нас к поддержке новых стандартов, чтобы помочь им пройти сертификацию на платформе, добавить API для их конкретных сценариев. У каждого были амбиции и желание доказать, что наша технология, наша идея победит… если только мы включим её в следующий релиз Windows и мгновенно доставим миллионам пользователей. Мы верили в это достаточно сильно, чтобы вести битвы на ежедневных совещаниях в наших военных комнатах. У каждого также был менеджер, который жаждал повышения и расширения сферы своего влияния — или количества своих сотрудников как промежуточного шага на этом пути.

Группы разработчиков и тестировщиков часто вступали в противоречия. Первые настаивали на окончании проверки кода, в то время как вторые вознаграждались за нахождение всё более сложных и эзотерических тестовых случаев, которые не имели сколько-нибудь реального сходства с клиентскими средами. Внутренняя динамика была сложной, мягко говоря. Как будто этого недостаточно, как минимум раз в год компания претерпевала масштабную реорганизацию — и имела дело с новой организационной динамикой.

Кстати, ничего из этого не должно быть принято как извинения или оправдания. Речь не об этом.

Сделали ли мы ошибки? Да, в избытке.

Принимали ли мы специально неверные решения? Нет, я не могу вспомнить ни одного.

Был ли это невероятно сложный продукт с невероятно гигантской экосистемой (крупнейшей в мире на то время)? Да, был.

Могли мы справиться лучше? Да, ещё как.

Приняли бы мы сегодня иные решения? Да. Зрение при взгляде в прошлое становится стопроцентным. Тогда мы не знали того, что знаем сейчас.

Должны ли мы смотреть в прошлое с разочарованием или сожалением? Нет, я предпочитаю усвоить полученные уроки. Уверен, никто из нас не допустил таких же ошибок в последующих проектах. Мы получили уроки из того опыта — а значит, в следующий раз допустим совершенно другие ошибки. Человеку свойственно ошибаться.
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 169
  • –25
    у микрософта странная закономерность, пользовался с win98 до win10.1, так вот через одну — выпускают глючный ОС, виста попала посерединке (между стабильными)… 98ок, 2000 не ок, хр ок, виста не ок, вин7 ок)…
      • +30
        Неоднократно наблюдал, как за упоминание этой закономерности огребали минусов, потому что она несколько натянута. Например, в данном случае потеряна ME, непонятно как быть с параллельной линейкой NT, нужно ли рассматривать 98 и 98 SE как две разные системы, спорный вопрос негодности Win2k, на какой момент считать годной XP и т.д.

        Хотя вообще такая неравномерность логически объяснима. Негодными получаются в основном те версии, которые многое меняют, последующая версия закрепляет. Вносимые изменения требуют резкого пересмотра привычек, замены железа, обкатки технологий в конце концов. В свете этого может и неплохо, что теперь изменения в десятке выходят два раза в год и без серьезных скачков.

        И только ME мне сложно объяснить. Новая модель драйверов, несовместимости и низкая стабильность, на фоне перехода на NT-ядро в параллельной ветке. Я не очень понимаю, зачем ее вообще выпустили? Разрабатывали 9х-линейку и решили не сворачивать, а заработать немного денег?
        • +3
          И только ME мне сложно объяснить. Новая модель драйверов, несовместимости и низкая стабильность, на фоне перехода на NT-ядро в параллельной ветке.

          Наверное, все дело в том, что линейка NT на тот момент была еще не готова для внедрения на компьютерах "обычных" пользователей, а линейка 9х уже слишком устарела для эффективного использования современного на тот момент железа.
          В результате и появился "линолеум", временное решение, которое должно было позволить дожить до пользовательского релиза NT, которым в итоге стала ХР.
          Кстати, был он не столь страшен, как малюют, и при всех своих проблемах был лучшим доступным решением на тот момент.
          Я перешел на линолеум сразу, как он стал доступен. Хотя я и ругался по поводу некоторых моментов (особенно доставляла падучесть, которая возникала при любой попытке выхода за рамки роли пишущей машинки), но желание возвратиться на более стабильную 98 SE почти не испытывал (хотя бы по поичине поддержки большего парка устройств и более человеческой поддержки USB и видеокарт).
          NT4 и 2000 в то время страдали от недостатка доайверов на разнообразное экзотическое железо, которое поставщики пихали в "бытовые" компьютеры.

          • 0
            Ох и огребу же сейчас.
            Я перешел на линолеум сразу, как он стал доступен.

            Делал «финт ушами» — прикручивал драйвер флешек от «линолеума» к 98-ой. То еще удовольствие. Но работало.
            • 0
              Ох и огребу же сейчас

              За что?


              Делал «финт ушами» — прикручивал драйвер флешек от «линолеума» к 98-ой. То еще удовольствие. Но работало

              Тоже пробовал такое, но лень победила (слишком много драйверов надо было вытащить и прикрутить). Проще было закидоны МЕ терпеть.

              • 0
                Работал с организациями в которых невозможно было обновить систему. Просто нельзя. Вот и изгалялся.
              • 0
                Был один хитрый софт, который умело падал на операциях с плавающей точкой, но 98 позволяла отключить «сопроцессор» и перейти в режим эмуляции. Софт переставал падать и все было нормально, т.к. переключать надо было не часто.
                Появилась машина с ME — на которой, внезапно, эмуляция сопроцессора была напрочь поломана. Там где должны рисоваться окружности — рисовались линии. О_о
                Глючнее ME из всей линейки не видал.
                • –1
                  Я правильно понял, хитрый софт не умел обращаться с сопроцессором, а виновата Windows?
              • 0
                Я также не разделяю истерии по поводу линолеума. Может мне сборка такая попалась и железо до кучи — не знаю. Win98 и Win2000 меня раздражали куда больше. Особенно последний: если на линолеуме мой TV-тюнер K-World нормально работал, то Win2000 падал при каждом третьем переключении канала. WinXP поселился у меня спустя полтора-два года. А под Win98 тюнер K-World просто не работал.
                Но надо сказать честно: WinXP SP1 — это уже была серьёзная весьма стабильная система (про защиту от вирусов ничего не говорю). В те же годы Mandrake 5/Redhat/Suse/Slackware — не отличались ни дружественностью, ни простотой настройки, ни той же стабильностью.
                Win10, как оказалось на поверку — местами хуже даже Win8.1 (но местами и приятней). Но не лучше любого популярного Linux.
                • 0
                  Кстати да, WinMe мне нравилась тем, что ее наконец-то отвязали от DOS, и она не была такой тормозной, как 2000. А при всех проблемах помогал софт ресет — а именно вырубить explorer в диспетчере задач :)
                  • +1
                    Это кто ж её от DOS-то отвязали? Там был точно такой же DOS, как и в Windows 9X, только ему запретили загружать что-либо, кроме Windows (что, впрочем, при необходимости легко обходилось).

                    Назвать это «отвязали» — это какую фантазию нужно иметь???
              • +3
                Пожалуй, есть более простая закономерность, и, скорее, правило использования: не переходить на новую систему до первого сервис-пака.
                • +1
                  Я так понимаю на Win10 вы не перейдете.
                  • +6
                    Сарказм чую здесь я какой-то. Там изменилась модель обновлений?
                    И да, скорее всего не перейду, — полтора года как на Ubuntu пересел.
                    • 0
                      Да. Однако cumulative update с именем собственным вполне можно считать за SP. Threshold 1 (Inital Release), Threshold 2 (November update), Redstone 1 (Anniversary Update), 2 (Creators Update), 3 (Fall Creators Update)…
                      • +2

                        Они купили майнкрафт чтобы взять из него идею давать такие имена обновлениям винды.

                        • 0
                          3й, в отличие от предыдущих, оказался самым глючным, как ни странно
                        • +5
                          Скоро узнаете то же самое для Linux: пользоваться только [предыдущей] LTS, или для FreeBSD: пользоваться релизами которые заканчиваются как минимум на *.1
                          • 0
                            пользоваться только [предыдущей] LTS

                            но при этом не переходить на новый LTS пока не выйдет следующий апдейт (через полгода после релиза LTS)
                            • +1
                              На самом деле и в мире Windows и в мире Linux идёт обратный процесс. У нас недавно перешли с Ubuntu LTS на Debian testing.

                              Что увеличило количество запросов в техподдержку, но устранило пики, когда раз в два года всё «стоит на ушах» из-за выхода очередной версии.

                              Windows нонче, фактически, выходит два раза в год (и горе тем, кто этого не понимает: у моей сестры ноут застрял на «November Update» 1511 и мне потребовалось немало времени, чтобы «убедить» его переехать на Fall Creators Update).
                              • 0
                                А сам он постепенно накатить обновления до Annv->Creators->Fall Creators не смог последовательно?
                                • +1
                                  Сам он яростно пытался накатывать Fall Creators напрямую. То есть даже при запуске любого «старого» установщика оно лезло в интернет, выясняло, что есть более новая версия и качало и устанавливало именно её. Что неизменно кончалось тем, что после двух часов бурной деятельности и нескольких перезагрузок появлялась надпись в духе «ну не шмогла я, не шмогла».

                                  Скачав несколько ISO'шек и отрубив Internet удалось убедить установкщиков делать обновления последовательно.
                                  • 0
                                    Еще 1 камень в огород тех, кто придумывал алгоритм обновлений.
                                    • 0
                                      Ну тут смешанные чувства. С одной стороны — оно-таки не вставало. С другой — все изменения, сделанные в процессе, после обнаружения проблем автоматически и корректно откатывались.

                                      Это лучше, чем в случае возникновения проблем при обновлениях Android'а, iOS или Linux'а. Скорее всего в подобных случаях обновления бы окирпичивали железку — а тут происходил всего лишь аккуратный откат всего на исходные позиции.

                                      В конце-концов проихсодил апгрейд с уже не поддерживаемой системы, так что моя сестра отчасти ССЗБ…
                                      • 0
                                        ХЗ, к примеру у 1С процесс обновления автоматизирован, в т.ч. с неподдерживаемой обновляешься до следующей, потом дальше и дальше. Прямо-таки иногда целая цепочка обновлений, если пропущено много релизов.
                                        Что помешало им сделать здесь такое же — ума не приложу.
                                        Может, человек в море был? Или в тюрьме сидел? Или в Африке был? Да мало ли по какой причине можно пропустить пару-тройку обновлений.
                                        • 0
                                          Ну так они и попытались это поддержать. Просто… Хотели как лучше (избавить человека от необходимости выкачивать гигабайты промежуточных версий), а получилось, как всегда (попытка пропустить два года обновлений привела к тому, что обновиться не получалось в принципе).
                                    • 0
                                      хм, а что там может пойти не так? начиная в восьмёрки distr-upgrade сводится к бэкапу юзерских данных, разворачиванию свежего образа и восстановлению бэкапа
                                      несколько раз обновлял десятку как минимум через две ступени, иногда вставало сразу, иногда требовало решения каких-нибудь проблем, типа нехватки места, неконсистентности файловой системы или какой-нибудь вредной софтины или драйвера
                                      • 0
                                        хм, а что там может пойти не так? начиная в восьмёрки distr-upgrade сводится к бэкапу юзерских данных, разворачиванию свежего образа и восстановлению бэкапа
                                        Не совсем. После этого свежая винда стартует и что-то там пытается сделать. Доходит до 30% (кажется, точно не помню), перезагруждается, доходит до 40%, перезагружается ещё раз, после чего третий раз не загружается, думает минут пять (видимо срабатывает какой-то watchdog), перезагружается ещё раз и идёт накатывать старый образ обратно.

                                        Тут скорее не к людям, которые придумывали процедуру обновления, а к тем, которые придумывали процедуру миграции данных — что-то там при прямом апгрейде «не прокатывает».

                                        Как я уже сказал к пуговицам претензий нет — ошибки в процедуре обновления обрабатываются отлично.
                                        • 0
                                          У меня похожим образом 10-ка пыталась обновиться, когда на жёстком диске бэды появились где-то в системной области появились.
                                          • 0
                                            А её удалось обновить после этого поэтапно? У меня оно на SSD стояло, про бэды как-то не подумал…
                                            • 0
                                              Нет, пришлось полностью сносить.
                                              • 0
                                                В меня через 3 ISOшки при отключении интернета в нужные моменты оно обновилось, так что тут явно другая история.
                                  • 0
                                    У нас недавно перешли с Ubuntu LTS на Debian testing

                                    Т.е. вы огребёте при выходе нового релиза, если в sources.list у вас testing вместо имени будущего релиза: после «разморозки» testing плющит и таращит от двух недель до месяца из-за обновления всех core пакетов и DE. Соответственно какое-то время приходится отсиживаться на новом stable, который тоже не всегда такой, как называется.
                                    • –1
                                      Для этого есть команда, которая настраивает наши локальные «зеркала».

                                      Мы и раньше, собственно, не использовали «чистый» Ubuntu LTS релиз — ядро, как правило, приходилось брать более новое через год-полтора после релиза, так как «замороженное» ядро не поддерживало некоторые новые железки.
                              • 0
                                Конечно. Теперь не существует SP как такового.
                                Так как винда отказалась от новых цифр в версии Виндовс, то теперь выходят так называемые сезонные обновления(по аналогу сезонных ДЛС для игры).
                                Считать их СП можно с большой натяжкой, чисто для успокоения своего.

                                P.S. Ubuntu тоже стабильностью не страдает. Даже LTS лучше использовать чуть погодя после релиза, а лучше вообще версию .1 сразу ждать. По аналогии с СП ;)
                          • 0
                            Возможно это проявление регрессии к среднему. Отношение к каждой следующей версии винды смещается от отношения к текущей версии в сторону нормального.
                          • +6
                            Классическая ветвь: 95 — не ок, 95OSR2 — ок, 98 — не ок, 98SE — ок, ME — не ок. Тут скорее «фиксы выходят спустя некоторое время после релиза и все начинает работать нормально»
                            NT-ветвь: 3.51 и 4.0 не застал, 2000 очень ок (лучшая из всех, пожалуй), XP — не ок, XP SP2/SP3 (даже автор статьи сказал, что это по сути дела другая система, плюс см. предыдущую строку) ок, Vista не ок, 7 ок, 8 не ок, 8.1 вполне ок, 10 -тут rolling release, первые версии не ок, те что новее ок.
                            • 0
                              Дополню: NT3.5 — не ок, NT 4.0 — ок (стабильнее чем 2000), 2000 до SP2 — не ок, SP3 — приемлимо, SP4 — ок
                              XP SP2 — очень много глюков приехало из лонгхорна — в том числе IPv6 отключался в настройках адаптера вплоть до SP3, ибо с включенным IPv6 и адресе IPv4 + Link-Local IPv6 на работал интернет (неверно маршрутизировались Scope).
                              • +1

                                Вы пропустили Windows NT 3.51, которая была стабильнее любой предыдущей и последующей версии системы.

                                • 0
                                  Тогда NT4.0 до SP2 — не ок. Я ещё помню как NT 4 с дискет ставился (был такой вариант дистрибутива на 114 дискет) и возникновение ошибки вроде «Дискета 113 не читается, замените дискету и начните установку заново» приводила к преждевременной седине в 12 ночи :) Нетварь, впрочем, прекрасно работала поверх тогдашней NT.
                                  • 0
                                    Ещё можно припомнить древнюю шутку про сервиспаки nt4 — «SP5 — кумулятивный, SP6 — фугасный» :-)
                                    • 0
                                      А с SP6.5a прилетал IE6, который можно было без особых плясок с бубном обновить до IE7, но это уже было в 2004 или 2005 году. Ну и фидошная нода имела на четвертой NT почти 12 лет аптайма.
                                      • 0
                                        но при этом там кажется так и не появилось нормального USB…
                                        • –1
                                          Это было политическое решение. DigitalPersona выпускала USB-биометрию, подключавшуюся по USB и работавшую с NT 4… И файлики драйверов некоторые имели надпись Copyright Microsoft.

                                          Так что поддержка USB для NT4 была создана, но не была релизнута…
                                          • 0
                                            Некторые устройства USB 1.1 работали, во всяком случае мышка ипервая флешка на 32 метра (большая такая, от Transcend) виделись, не без бубна. На некоторых материнках USB 1.1 делился с PS/2 и переключался джампером, соответсвтенно втыкалось это все на тот момент не стандартным разъемом в материнке, на отдельную интерфейсную заглушку. Pentium 2 я не застал, а на Pentium 3 уже активно использовался Windows 2000.
                                            • 0
                                              khim lirein отвечу сразу обоим

                                              под «нормальным usb» я имею в виду работу хоть какой-то версии протокола без внезапных бсодов и танцами с бубном. насмотрелся в НИИ этих шаманских действий, когда на хроматографе контроллер на НТ4 стоял, и втыкание флешки требовало перезагрузки
                                • +1
                                  Vista по слухам вроде тоже стала в итоге ок после скольких-то обновлений.
                                  • 0
                                    Скажу так — скорее всего основное «не ок» было именно в проблемах совместимости программ и драйверов, и именно из-за этого система получила столько негатива… Ещё один неприятный момент — это повышенные требования к памяти, особенно по сравнению с XP: при старте виста у меня сжирала порядка 900 мегабайт оперативы. Особых изменений(за 3,5 года обитания на висте) я в плане производительности и использования оперативной памяти не заметил.
                                    • 0
                                      Я на момент выхода Vista работал в компьютерном магазине. Как-то резко появилось в продаже очень много ноутбуков на этой ОС с ОЗУ 1 или даже 0,5 Гб (в бюджетном секторе, конечно). Сколько мы наслушались от покупателей. А заранее предупреждать было чревато. Расскажешь, что конфигурация этого ноута не подходит этой ОС и всё будет работать плохо покупатель просто уйдёт (т.к. могло просто не оказаться другого варианта по устраивающей цене), а уж если нарвёшься при этом на «тайного покупателя» (такой засланный администрацией казачёк с целью проверить работу сотрудников) так можно было вообще нарваться на настойчивую рекомендацию написать по собственному. Если начнёшь советовать нарастить памяти вполне можно было нарваться на обвинение в «навязывании товара или услуги», что уже повод для жалобы в общество защиты прав потребителей.
                                      • 0
                                        Я думаю, на такие конфиги производители ставили Висту либо под нажимом MS, либо получая от нее хорошие скидки на лицензию.
                                        • 0
                                          Что интересно стоимость лицензии предустановленной винды около 14 баксов (было по тем временам). Было несколько случаев, когда покупатели настаивали на продаже ноутбука без предустановленной винды (долго, муторно и через руководство продажной компании, т.к. ПО системы для оформления продажи не предусматривала такой возможности). Тогда у них на глазах форматировали винт, отдирали наклейку (куда её потом делали логисты — хз) и снижали цену продажи на эти 14 баксов (условные 14, поскольку уже за давностью лет не помню точно).
                                    • +2

                                      Vista это бета-версия Win7, нормальной стала после перехода в состояние релиза.

                                      • 0
                                        Vista SP2 уже была рабочей системой.
                                        • 0

                                          Может быть, но семёрка была рабочей системой ещё в предрелизной версии.

                                      • 0
                                        Торрентокачалка на атоме (первом) с лицензионной вистой. Работает. На рабочем компе стояла несколько лет (на Core2 каком-то) и тоже ок, ни одного BSOD. Так что бывает.
                                      • 0
                                        интересно, в чём по-вашему разница 8 и 8.1
                                        • 0
                                          В 8.1 вернули кнопку «пуск» — стало можно нажимать на нее, а не целиться в угол экрана. А еще в том же месте на стартовом экране разметили кнопку которой можно его закрыть.

                                          А еще в диспетчер задач была добавлена колонка с загрузкой диска.
                                          • 0
                                            А ещё изменили минимальные требования к фичам процессора.
                                            Часть машинок уже не смогла в принципе обновиться с 8.0 на 8.1 (и 2012 на 2012 R2 тоже, кстати)
                                    • –5
                                      О, да. Виста. Моя любимая операционка)
                                      • 0

                                        У людей сломан природный определитель сарказма. :)

                                    • +10
                                      «Они просто хотели, чтобы их старые решения продолжали работать и дальше, даже если это означает снижение безопасности наших общих пользователей...» Ну да, хотели — а Мелкомягкие что-нибудь предложили взамен старых хаков в системе? Я по сих пор вздрагиваю, когда вспоминаю, сколько усилий у нас ушло на переработку нашего НДИС драивера под Виста — и только потому, что мелкомягкие забили на разработчиков с самого начала.
                                      • +1
                                        И за что минусуете человека? Имеете опыт безболезненного переписывания драйверов под Vista? В статье же не зря упоминаются судебные процессы — очень похоже было на зачистку поля под Security Essentials.
                                        • +6
                                          NDIS подсистема в Windows вообще была неудобна с самого начала. Для написания любого более-менее вменяемого драйвера надо бы очень сильно изворачиваться, а для того, чтобы добавить функционал перехвата, легальным SDK вообще нельзя было пользоваться — вот и писали обмотки из кучи всяких хаков. Я написал целый дизассемблер в драивере, чтобы кошерно перехватывать входы. Когда вышла Виста, все эти обмотки работать перестали из-за запретов в ядре. Но SDK Microsoft практически не поменяла — поэтому большинство разработчиков подобных продуктов оказались перед неприятным выбором — уходить из бизнеса или давить на Microsoft и требовать нормальной поддержки разработки в ядре. А те, кто много разрабатывал в этой области могут еще и скупую слезу уронить по почившему в бозе Softice — погибшему по той же причине. А Microsoft до сих пор никакого решения для отладки в ядре, кроме ужасного kdb, не дали…
                                        • +6
                                          Очень полезный экскурс в историю и отличный перевод!

                                          Не имею отношения к MS, но в масштабных (200+ человеко-лет) проектах с моим участием примерно так и было.
                                          Амбициозные планы, от которых отваливаются громадные куски на 2-м или 3-м году…
                                          Промежуточные релизы текущих версий, на которые оттягивается половина команды…
                                          Интеграция, требующая в 3-е больше ресурсов, чем разработка…
                                          Процедура апдейта и миграции данных пишется в последний момент…
                                          Впихивание мега-фич ближе к концу (все равно уж опаздываем)…

                                          Ностальгия :-)
                                          Как раз фейлы таких мега-проектов и способствовали развитию Agile — они объективно перестали срастаться.
                                          • +2
                                            Вот у вас вроде и комментарий интересный, но толком непонятно ни о чём он, да и о каких конкретно годах идёт речь тоже приходиться догадаться.
                                            Т.е. кажется что вам есть что сказать и я реально готов платить, но скажите Б)
                                            • +1
                                              *платить=почитать, простите, телефон считает что лучше меня знает что я хочу сказать)
                                              • +1
                                                На самом деле, в статье очень много анти-паттернов управления продуктами и проектами.
                                                Просто учебник «как делать не надо». Я лишь подчеркнул некоторые из них.
                                                В моем случае это было порядка 10 лет назад.

                                                Приняли бы мы сегодня иные решения? Да. Зрение при взгляде в прошлое становится стопроцентным. Тогда мы не знали того, что знаем сейчас.


                                                Причем, для некоторых проблем я не вижу решения даже сейчас.
                                                Например, разработка новой версии платформы и новой версии продукта на базе этой платформы в одном релизном цикле.
                                                В теории, надо бы сначала стабилизировать платформу, но на практике она устареет к следующему релизному циклу. Да и многие проблемы начнут вылазить только во время интеграции.
                                                Т.ч. эволюция выглядит предпочтительнее революций в плане предсказуемости результатов, но часто проигрывает в продуктивности.
                                                • 0
                                                  Ещё раз прошу прощения, невнимательно прочитал ваш комментарий. Удалить не могу, а прошлое уточнение не успело пройти модерацию.
                                                  Вашу мысль понял, в целом согласен.
                                                  • –1
                                                    Т.ч. эволюция выглядит предпочтительнее революций в плане предсказуемости результатов, но часто проигрывает в продуктивности.
                                                    Зависит от масштаба проекта.

                                                    Если человек может, условно говоря, «загрузить» проект себе в голову и «в одно рыло» переписать его — то революция почти всегда лучше.

                                                    Если у вас десятки тысяч разработчиков, то вы рискуете увязнуть в тестировании — в сложных случаях настолько, что революция просто «захлебнётся».

                                                    Где проходит граница? Этого я до сих пор не знаю…
                                                    • 0
                                                      Например, разработка новой версии платформы и новой версии продукта на базе этой платформы в одном релизном цикле.

                                                      Есть вариант отвязать релизные циклы и сдвинуть платформу на пол года назад например. Получится платформа уже более стабильной к моменту интенсивного использования.
                                                • 0
                                                  но в масштабных (200+ человеко-лет) проектах с моим участием примерно так и было.

                                                  Оно и в более мелких проектах частенько так бывает.
                                                  Только и разницы, что народа на порядки меньше задействовано.

                                                • 0

                                                  Для терминов "военная комната" и "корабельная комната" дословный перевод не подходит, а адекватных аналогов я не знаю. "War room" в контексте компании по разработке ПО означает комнату, где идёт активное обсуждение проекта и принятие оперативных решений. Это очень характерно для компаний с open space планировкой, потому что кто бы что ни говорил, а для нормальной продуктивной работы нужна отдельная комната. Сам термин действииельно связан с военными, но правильный перевод в таком случае — ситуационный центр. Это такой зал, который показывают в фильмах, где сидит президент и думает, отдавать приказ о тотальной анигиляции или нет. "Ship room" я вижу впервые, но, опять же, в контексте разработки программ "ship" означает очередную публикацию изменений, обычно его применяют в случае, когда ПО обновляется по методу rolling release, то есть без фиксированных версий.

                                                  • +14
                                                    «военная комната» и «корабельная комната»

                                                    Нет ничего элементарней — «штаб» и «мостик». Вот вам адекватные аналоги
                                                    • 0
                                                      мостик — это другое, для совещаний у моряков есть кают-компания
                                                    • –3
                                                      Имхо, тут уместнее смысловой перевод. «War room» — комната обсуждений, «Ship room» — комната поставки. Как-то так.
                                                      • 0
                                                        Куда поставки?
                                                        • –1
                                                          Клиентам. Заказчикам. Тестерам.
                                                      • 0
                                                        Может, ЦУП?
                                                    • 0
                                                      И в итоге в Win7 пришлось сделать шаг назад или же всё улучшили?
                                                      • +2
                                                        Win7 вышла в гораздо более удачное время. Мало того, что к моменту её выхода прошёл шок от Vista и производители софта и железа уже начали поставлять совместимые решения, так ещё и технобум в области традиционных ПК пошёл на спад (вернее — перешёл в поле смартфонов, с первыми релизами iPhone и Android). В итоге у MS была основная задача исправить проблемы Vista (т.е. фактически отладить релиз), никаких революций на релиз Win7 не планировалось. Он вообще изначально должен был стать чем-то вроде сервис-пака для Висты, только называться по-другому, чтобы не тянуть за собой её испорченную репутацию.
                                                      • 0
                                                        Ого, какие откровения. Интересно, насколько корректно провести аналогию с разработками иных сложных систем, вроде авиалайнеров, заводов, электросетей и т.п., там тоже содержится такое количество «багов»? Или такое сравнение некорректно? Возможно ли применение опенсорц подхода к разработке, например, законов или автомобилей?
                                                        • +2

                                                          Поимерно то же и творится. Баги часто устраняют уже в процессе эксплуатации.
                                                          Некоторые по итогам кстастроф.
                                                          Разве что из-за более жестких наказаний за последствия багов процесс отладки перед релизом более тщательный, а в последний момент могут втиснуть только что-то, не влияющее на основной функционал (например, другой проект забора вокруг АЭС).
                                                          Опенсорс вполне ложится, но оно часто слишком дорого для энтузиастов получается (как по реализации, так и по ответственности), а бизнес не торопится открывать свои секреты.

                                                          • 0
                                                            Думаю, что багов в авиалайнерах и их прошивках на порядок меньше хотя бы потому, что за железо и прошивку отвечает одна и та же команда, а также не требуется совместимость со всем зоопарком железа и ПО, как выпущенным ранее, так и тем, что выпустят в течении следующих нескольких лет.
                                                            • 0

                                                              Если бы все было так просто.
                                                              Если брать уровень конкретного блока и его программы, то да, бардака поменьше, команда одна.
                                                              А если брать самолет в целом, то тушку проектируют одна команда, двигатель — другая, систему управления — третья.
                                                              Для навигационных систем требуется обратная совместимость со всем зоопарком эксплуатирующейся наземной техники.
                                                              Иногда случается, что новый двигатель к релизу не готов. Ничего, прикручивают старый. Иногда даже совместимость со старым закладывается на этапе проектирования.
                                                              Список можно продолжать.

                                                              • +1
                                                                geher А можно статью? С деталями?
                                                                • +2

                                                                  Статью не получится. Для этого надо провести исследования и систематизировать данные.
                                                                  А у меня набор разрозненных фактов, полученных в разное время из разных источников в процессе удовлетворения нездорового любопытства без фиксации пруфов.

                                                                  • +2
                                                                    Возможно не совсем в тему, но неплохо раскрывает некоторые особенности данной сферы habrahabr.ru/post/202184
                                                                    • +1
                                                                      Посмотрите сериал «расследование авиакатастроф», там много на эту тему.
                                                                  • 0
                                                                    не требуется совместимость со всем зоопарком железа и ПО

                                                                    Удачные модели самолетов проходят множество модернизаций за десятилетия эксплуатации, так что зоопарк вполне себе бывает.
                                                                    • 0
                                                                      Один раз поставили индикаторы топлива от других датчиков. Результат — завышенные показания -> авария. После этого вышло требование делать для несовместимых датчиков несовместимые разъемы.

                                                                      Так что зоопарк зоопарком, но представьте что у вас для каждого периферийного устройства свой USB разъем. И если в материнке нет определенного разъема то «извините, ваша флешка не подходит».

                                                                      Я не оправдываю что в авиации все проще. Там наоборот — на много больше ситуаций и защитных механизмов. И «зоопарк» — это потенциальная угроза, поэтому в рамках безопасности его ограничивают списком поддерживаемых узлов и физически совместимых разъемов.
                                                                    • +1
                                                                      Софт для авиалайнеров разрабатывается по немного другим принципам. Там часто V-модель разработки, из которой следуют четко сформулированные требования разных уровней (от самого высокого до самого низкого), что упрощает тестирование и верификацию, жесткие стандарты типа DO-178B/DO-278 для авиации, MISRA для автомобилей, и др.
                                                                      В итоге софт пишется медленно и дорого, но надежно.

                                                                      Что же до промышленной автоматизации, то там бардак бывает похуже описанного в статье, да.
                                                                    • +8

                                                                      Я начинал карьеру с верификации софта авиалайнеров. Там все на столько не похоже, на привычную всем разработку, что описывать не на одну страницу. Фактически от простой идеи подобной "когда в баке заканчивается топливо, нужно заморгать вот этим сообщением" проходит 5-6 стадий на которых создаются и верифицируются разнообразные спецификации.


                                                                      Коротко и в общем эти стадии выглядят так.


                                                                      • Человек понимающий как самолет летает, задает общие параметры для данной подсистемы (в данном случае спецификации и регламенты связанные с минимально допустимым объемом топлива, достаточного для продолжения полета).
                                                                      • Другой авиационный эксперт разбирает эти спецификации и находит конкретные значения и условия примерно в выражениях указанных выше.
                                                                      • Специалист ответственный за понимание логики работы пилотов и взаимодействие экипажа указывает в каком виде необходимо получить оповещение (какой экран, какой звук, уровень критичности и т.д.) и параллельно инициирует процесс изменения летной документации, в том числе карт, если это надо.
                                                                      • Специалист понимающий архитектуру информационной системы самолета описывает какие подсистемы должны участвовать в данном действии и как они взимодействуют
                                                                      • Специалист отвественный за конкретную систему (в данном случае подсистема нотификаций) создаёт общую спецификацию для данной системы.
                                                                      • Другой узкий специалист пишет псевдокод, либо UML в терминах конкретной системы.
                                                                      • А вот и программист. Он либо пишет переводит псевдокод в реальный код, либо его здесь нет, поскольку есть UML генератор.
                                                                      • Программист верификатор сверяет, что спецификация соответсвует коду и покрытие кода 100%

                                                                      На каждом шаге определена процедура ревью. Каждая спецификация проходит прямо или косвенно проходи тестирование, но это процесс параллельный и сильно завязанный на работу с реальным железом или даже реальные полеты. Программисты работают с реальным железками, либо с сертифицированными эмуляторами. Вся эта история жестко зарегламентирована. В частости компания осуществляющая верификацию не должна быть аффилирована с тем кто софт производит. Главная библия это стандарт DO-170b. По нему же работают производители ПО для опасных производств (например атомная станция)

                                                                      • +3
                                                                        Может напишите статью на эту тему?
                                                                        • 0

                                                                          Думаю можно, но уж очень давно я этим занимался (больше 10 лет назад) и моя информация может сильно устареть.

                                                                          • +2
                                                                            Что-то мне подсказывает что от момента начала разработки до выхода системы может пройти и больше 10 лет, по крайней мере в редких случаях.

                                                                            А уж сроки эксплуатации…
                                                                            • 0

                                                                              Может и 10, хотя надо понимать, что аппартная часть, операционные системы и шины данных (как софтовые так и аппаратные) унифицированы в пределах бренда и легко переносяся на сходных пот ТТХ и начинке самолетах. На моей памяти с нуля запускали в производство бизнес джет и на это ушло где-то два года. Понятно, что B787 разрабатывался значительно дольше.

                                                                            • 0
                                                                              Все равно было бы крайне любопытно прочесть. Буду благодарен.
                                                                          • 0
                                                                            Главная библия это стандарт DO-170b
                                                                            Вероятно вы хотели сказать DO-178b?
                                                                            На данный момент он уже в "с" перерос.

                                                                            • 0

                                                                              Очень может быть, уж больше 10 лет как я не в теме

                                                                          • 0
                                                                            Почитайте как-нибудь, что на атомных станциях творится :) В сети есть откровения кое где. Атомные байки всякие. Удивительно, что было мало серьезных инцидентов за всё время.
                                                                            • 0
                                                                              Даже не представляете. Самое лайтовое — это когда что-то не влазит куда-то. Типа, тут у нас по проекту шкаф, а там дверь. Но если поставить туда настоящий шкаф, то дверь не откроется/не закроется) Или вот вам две железки, по проекту одна передаёт другой важные параметры, только вот общих протоколов они не знают. Это все ужа на согласованных проектах. А уж какие чудеса на проектной стадии творятся. Но веселее потом эксплуатации, которая получает г в обертке — на всём сэкономили, а эксплуатировать будьте добры как новое, по документам все чисто, все одобрено, вот вам подписи, сертификаты, согласования.

                                                                              Естественно, в наш век все заводы и электросети пользуются тем же самым софтом, которое пишется по описанным выше методологиям.
                                                                            • –7
                                                                              Отпишитесь, кто прямо сейчас читает эту статью на Висте.
                                                                              • 0
                                                                                Читаю с ноута на семёрке, а на стационарном стареньком — виста стоит (на нём фото видео обрабатываю).
                                                                              • 0
                                                                                Теперь ясно, почему у висты были такие проблемы. Наверное это из разряда, как не надо не просто управлять проектами, а даже и вообще вопросы организации разработки
                                                                                • 0
                                                                                  Рано или поздно любая организация начинает выдавать в качестве продукта свою организационную диаграмму, и Windows не исключение. У open source нет такой проблемы.

                                                                                  Интересно, как закон Конвея проявляется в крупных open source сообществах. Есть у кого-нибудь такой опыт?
                                                                                  • 0
                                                                                    Спасибо за перевод, очень интересная статья! Только мне вот что непонятно — по идее, масштабы использования последующих версий Windows должны были быть ещё больше, значит ли это, что они тоже сталкивались / сталкиваются с такими же проблемами, или же в Microsoft что-то кардинально изменилось с выпуском Vista? Отличается ли процесс разработки Windows 10 от предыдущих версий в контексте проблем, затронутых в статье? И еще интересно, в чём были конкретные отличия Longhorn от Vista, кроме упомянутой WinFS?
                                                                                    • +6
                                                                                      Видел несколько лет назад (еще до интерфейса Win8) на ФБ публикацию карикатуры в ленте бывшего программиста Microsoft с его комментарием «its true». Запомнилось тем, что перед этим он рассказывал несколько поучительных историй о проблемах с менеджментом в Microsoft.
                                                                                      карикатура
                                                                                      image
                                                                                      • 0
                                                                                        Должны ли мы смотреть в прошлое с разочарованием или сожалением? Нет, я предпочитаю усвоить полученные уроки.

                                                                                        Какие уроки Вы усвоили? Ну, или так — какие уроки можно извлечь?
                                                                                        As for me, то вряд ли кто будет судить разработчиков Vista… Когда много проектов в одно время, то очень сложно сфокусироваться на каком-то одном, чтобы сделать его качественно. Да и решение — лепить из старого — мягко говоря, неэффективно…
                                                                                        • 0
                                                                                          — чему мы научись?
                                                                                          — мы научились больше этого не делать. ещё бы знать, что мы сделали…
                                                                                          «после прочтения сжечь»
                                                                                        • 0
                                                                                          Простите.
                                                                                          Перечитал внимательнее и понял, что всё неправильно понял, но удалить свой коммент уже не могу.
                                                                                          Игнорьте плиз, всё что я написал.
                                                                                          • 0
                                                                                            Ужасы какие :0 Дисклеймер хоть ставили бы, читать же больно! Сразу перед глазами вся жизнь разработческая проносится
                                                                                            • 0
                                                                                              проявлял некоторые влияние на дизайн операционной системы и тянул его в разных направлениях

                                                                                              design сущ.
                                                                                              конструкция
                                                                                              устройство
                                                                                              архитектура (software)
                                                                                              структура, программная структура
                                                                                              программная архитектура
                                                                                              системная архитектура
                                                                                              • +1
                                                                                                В последнее время мое мнение о мелкософте все хуже и хуже!
                                                                                                З.Ы. У меня так: 98->Me->XP->7->10->7
                                                                                                • +2
                                                                                                  Ну в чем-то я вас конечно могу понимать, однако без больших подробностей ваш путь больше похож на путь «обиженного».

                                                                                                  Говорю, как обладатель рабочих станций на Win10 и Win7 (дом и офис соот-но).
                                                                                                  Дома перешел на 10 в связи со Skylake, M2, DDR4 — 7-ка на тот момент вот это все поддерживала «не очень». Фиксы вышли, но не сразу.

                                                                                                  Да, по первой 10-ка конечно меня убивала своими дэбильными решениями. Однако со временем (после тьмы апдейтов) + адаптации части софта + нахождения нужного вспомогательного стало полностью ЗБС.

                                                                                                  Теперь у меня и блокировка курсора в пределах одного монитора по хоткею, и разнесение панелей задач по разным мониторам с независимыми приложениями на них (и на 7-ке этот софт есть, просто на 10-ку он не сразу вышел), вышла адаптация аудиомикшера по хоткею в ОС… короче говоря реально отшлифовано стало все. Ну и да, без свопа 10 (64Гб памяти) живет лучше, чем 7.

                                                                                                  А в офисе нет ограничений «сверху» никаких. Просто железо теперь уже устаревшего поколения (обычный SSD, простой 4-х ядерник, 16Гб DDR3). И перенос всего рабочего окружения в новую ОС — это неделя времени на доводку и отладку. Т.е. просто смысла нет.

                                                                                                  А когда будет железо таки обновлено, так и 10 (или что там будет), будет поставлена.

                                                                                                  P.S. 7-ка реально хорошая ОС. С самого начала. Еще с 2008-го стояла, за год до офф.релиза. И сменил только с миграцией на DDR4-stack.
                                                                                                  • 0
                                                                                                    DDR4

                                                                                                    А тут то какая поддержка со стороны ОС нужна?
                                                                                                    • 0
                                                                                                      Семёрка отрубает обновления на процессорах с поддержкой DDR4. Чушь конечно же, никакой поддержки со стороны ОС там не нужно, уверен, что при должном упорстве можно и XP завести.
                                                                                                      • 0
                                                                                                        Чушь конечно же

                                                                                                        Не разбираясь до конце не лезли бы с такими категоричными заявлениями.

                                                                                                        Сама память не при чем. Как бы, только, если включить логику, можно понять, что новый тип памяти ну вообще никак не подходит к старым материнкам.

                                                                                                        Соот-но, материнки только нового поколения, на которых старые ОС вообще не запускались.

                                                                                                        Я заказывал железо в 2015-том. Практически сразу же после того, как оно вообще начало сходить с конвееров. Покупал естественно на Amazon. Потом его привезли в сибирь. Тут я все собрал. И, как это ни удивительно, даже ЦП не подошел к материнке, хотя был заявлен, как «точно совместим».

                                                                                                        Связался с саппортом (материнки). Пообщались. Они сказали, что пока мой заказ ехал, у них вышло 6! внутренних ревизий по прошивке. Отнес в сервис, обновили микрокод в ЦП, обновили прошивку материнки. После этого железо завелось. Но 7-ка при установке падала с ошибкой. Еще раз пообщался. Поставил после этого 10-ку, завелось с пол пинка.

                                                                                                        Сейчас конечно, уже все до конца починили (я так думаю), но смысла в древних (ХР) или старых (7) просто нет никакого.
                                                                                                        • 0
                                                                                                          Не разбираясь до конце не лезли бы с такими категоричными заявлениями.

                                                                                                          Проблемы могут быть только в UEFI и совсем нестандартных драйверах на контролёр диска. Всё остальное в принципе не может мешать поставить старую ОС, переведя UEFI в режим совместимости и используя стандартные драйвера там, где нет специальных.
                                                                                                          но смысла в древних (ХР) или старых (7) просто нет никакого.

                                                                                                          Это для вас нет.
                                                                                                          • 0
                                                                                                            Знаю, что очень запоздалый ответ, однако вы слишком самоуверены.

                                                                                                            Понятное дело, что сейчас есть инструкция, по решения проблем, но тогда её не было + нужно было таки патчить мать, если она была из первых отгрузок.

                                                                                                            На сайте даже отдельная кнопка есть «про проблемы при установке Win7», которые даже сам производитель признает!

                                                                                                            gigabytedaily.blogspot.ru/2015/09/having-trouble-installing-windows-7-by.html

                                                                                                            P.S. А XP на таком железе только в виртуалке гонять — радикально устарела ОС, нет нужных компонентов.
                                                                                                            • 0
                                                                                                              однако вы слишком самоуверены.

                                                                                                              Я лишь говорю о типовой ситуации. Всегда будут исключения, косяки производителей, намеренное создание несовместимости.
                                                                                                              Вы же распространяете свой частный случай на все возможные.
                                                                                                              А XP на таком железе только в виртуалке гонять — радикально устарела ОС, нет нужных компонентов.

                                                                                                              Я говорил только о возможности установки, а не рациональности этого процесса. Впрочем лично я найду, что мне нужно.
                                                                                                            • 0
                                                                                                              Уже есть системы, где uefi в legacy не переводятся. Сервера — лично видел, и плате там уже пара лет.
                                                                                                              К тому же, 7 вполне уже умела uefi…
                                                                                                              • 0
                                                                                                                У семерки все через раз на UEFI, к сожалению.
                                                                                                  • +1
                                                                                                    … её «отсылали в Сибирь», то есть продолжали разработку компонента, который по большей части игнорировала вся остальная организация и который был обречён на неудачу или бесполезность — но группа или руководство просто не могли принять решение об отказе от разработки.


                                                                                                    … и тут же:

                                                                                                    Принимали ли мы специально неверные решения? Нет, я не могу вспомнить ни одного.


                                                                                                    Один я вижу, что вся эта статья — подобие «покаяния», при этом не признавая никакой вины? Неужели узколобое, непрофессиональное «планирование фич» — это из-за «быстро меняющегося мира ИТ»? Чушь, если не сказать резче!

                                                                                                    Скажем прямо: у микрософта всегда была безобразная организация компании, «дешёвый» HR, соответственно и продукты выходили один ужаснее другого. Зато юристы и маркетолухи отрабатывали на 146%!
                                                                                                    • 0
                                                                                                      Есть ли в планах перевести статью Терри Кроули, упомянутую вначале?
                                                                                                    • –1
                                                                                                      В свое время Microsoft всерьез рассматривала создание 128-битной системы написанной полностью с нуля, т.к. стабильность работы системы всегда вызывала вопросы, ну и сами работники признавали то, что архитектура давно морально устарела. Но пошли по пути наименьшего сопротивления, windows 7/8/10 одна и та же операционка, с одним и тем же ядром, с минимальными внутренними изменениями, но с максимальными внешними изменения и как следствие нереальное количество багов и проблем. Находятся даже те кто спорят что это не так, и это разные системы. Но банальное сравнение производительности и разница в 1% всегда говорит об обратном. Печально все это, хотелось бы чего-то действительно революционно нового, впрочем 64-битная архитектура рано или поздно все равно себя изживет, вопрос времени.
                                                                                                      • +1
                                                                                                        Боюсь что после выхода 128 битной системы багов было-б не меньше.
                                                                                                        • +1
                                                                                                          А есть где отсылки про 128-битную архитектуру? Мне это запомнилось только как одна из April's Fools.
                                                                                                          • 0
                                                                                                            Да это просто хабр превратился в пикабу, не обращай внимания.
                                                                                                            • 0
                                                                                                              А, ну тогда ладно — а то подумал, может, внезапно, уже настолько стар, что память совсем ни к чёрту.
                                                                                                              • 0
                                                                                                                С учётом того, что в те времена 128-битная архитектура жила у Microsoft в бухгалтерии — не удивлюсь если разговоры об этом действительно шли…
                                                                                                                • 0
                                                                                                                  Если что, AVX-512 вообще 512бит, но это SIMD инструкции, которыми в самой ОС Windows особо делать нечего.