Традиционно группа разработчиков 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 или тестированием механизма обновления.
В каждый момент времени в разработке находилось несколько крупных релизов, а также многочисленные побочные проекты. Разные группы отвечали за кодовые базы в разном состоянии готовности, что со временем приводило к результату, где «богатый становится богаче, а бедный — беднее». Группы, которые начинали отставать, по той или иной причине, обычно так и оставались позади.
Когда проект приближался к завершению, программные менеджеры начинали составлять требования к следующему релизу, а группы в «здоровом» состоянии (богатые) начинали внедрять новый код, тогда как бoльшая часть организации (бедные) по-прежнему копалась с текущим релизом. В частности, группы тестирования редко освобождались до выпуска релиза, так что в начале проектов новый код не был тщательно протестирован. «Нездоровые» группы всегда отставали, делая последние штрихи для текущего релиза и отставая всё дальше и дальше. Именно в этих группах зачастую трудились разработчики с самым низким уровнем морального состояния и наиболее истощённые. Это значит, что новые сотрудники групп [взамен ушедших истощённых — прим.пер.] наследовали хрупкий код, который они не писали и поэтому не понимали.
На протяжении почти всего срока разработки 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 и мгновенно доставим миллионам пользователей. Мы верили в это достаточно сильно, чтобы вести битвы на ежедневных совещаниях в наших военных комнатах. У каждого также был менеджер, который жаждал повышения и расширения сферы своего влияния — или количества своих сотрудников как промежуточного шага на этом пути.
Группы разработчиков и тестировщиков часто вступали в противоречия. Первые настаивали на окончании проверки кода, в то время как вторые вознаграждались за нахождение всё более сложных и эзотерических тестовых случаев, которые не имели сколько-нибудь реального сходства с клиентскими средами. Внутренняя динамика была сложной, мягко говоря. Как будто этого недостаточно, как минимум раз в год компания претерпевала масштабную реорганизацию — и имела дело с новой организационной динамикой.
Кстати, ничего из этого не должно быть принято как извинения или оправдания. Речь не об этом.
Сделали ли мы ошибки? Да, в избытке.
Принимали ли мы специально неверные решения? Нет, я не могу вспомнить ни одного.
Был ли это невероятно сложный продукт с невероятно гигантской экосистемой (крупнейшей в мире на то время)? Да, был.
Могли мы справиться лучше? Да, ещё как.
Приняли бы мы сегодня иные решения? Да. Зрение при взгляде в прошлое становится стопроцентным. Тогда мы не знали того, что знаем сейчас.
Должны ли мы смотреть в прошлое с разочарованием или сожалением? Нет, я предпочитаю усвоить полученные уроки. Уверен, никто из нас не допустил таких же ошибок в последующих проектах. Мы получили уроки из того опыта — а значит, в следующий раз допустим совершенно другие ошибки. Человеку свойственно ошибаться.
Комментарии (128)
sgenie
31.01.2018 00:15-1«Они просто хотели, чтобы их старые решения продолжали работать и дальше, даже если это означает снижение безопасности наших общих пользователей...» Ну да, хотели — а Мелкомягкие что-нибудь предложили взамен старых хаков в системе? Я по сих пор вздрагиваю, когда вспоминаю, сколько усилий у нас ушло на переработку нашего НДИС драивера под Виста — и только потому, что мелкомягкие забили на разработчиков с самого начала.
RationalBot
31.01.2018 01:23И за что минусуете человека? Имеете опыт безболезненного переписывания драйверов под Vista? В статье же не зря упоминаются судебные процессы — очень похоже было на зачистку поля под Security Essentials.
sgenie
31.01.2018 01:32NDIS подсистема в Windows вообще была неудобна с самого начала. Для написания любого более-менее вменяемого драйвера надо бы очень сильно изворачиваться, а для того, чтобы добавить функционал перехвата, легальным SDK вообще нельзя было пользоваться — вот и писали обмотки из кучи всяких хаков. Я написал целый дизассемблер в драивере, чтобы кошерно перехватывать входы. Когда вышла Виста, все эти обмотки работать перестали из-за запретов в ядре. Но SDK Microsoft практически не поменяла — поэтому большинство разработчиков подобных продуктов оказались перед неприятным выбором — уходить из бизнеса или давить на Microsoft и требовать нормальной поддержки разработки в ядре. А те, кто много разрабатывал в этой области могут еще и скупую слезу уронить по почившему в бозе Softice — погибшему по той же причине. А Microsoft до сих пор никакого решения для отладки в ядре, кроме ужасного kdb, не дали…
RationalBot
31.01.2018 01:07Очень полезный экскурс в историю и отличный перевод!
Не имею отношения к MS, но в масштабных (200+ человеко-лет) проектах с моим участием примерно так и было.
Амбициозные планы, от которых отваливаются громадные куски на 2-м или 3-м году…
Промежуточные релизы текущих версий, на которые оттягивается половина команды…
Интеграция, требующая в 3-е больше ресурсов, чем разработка…
Процедура апдейта и миграции данных пишется в последний момент…
Впихивание мега-фич ближе к концу (все равно уж опаздываем)…
Ностальгия :-)
Как раз фейлы таких мега-проектов и способствовали развитию Agile — они объективно перестали срастаться.
croupier
31.01.2018 01:24Вот у вас вроде и комментарий интересный, но толком непонятно ни о чём он, да и о каких конкретно годах идёт речь тоже приходиться догадаться.
Т.е. кажется что вам есть что сказать и я реально готов платить, но скажите Б)croupier
31.01.2018 01:26*платить=почитать, простите, телефон считает что лучше меня знает что я хочу сказать)
RationalBot
31.01.2018 01:46На самом деле, в статье очень много анти-паттернов управления продуктами и проектами.
Просто учебник «как делать не надо». Я лишь подчеркнул некоторые из них.
В моем случае это было порядка 10 лет назад.
Приняли бы мы сегодня иные решения? Да. Зрение при взгляде в прошлое становится стопроцентным. Тогда мы не знали того, что знаем сейчас.
Причем, для некоторых проблем я не вижу решения даже сейчас.
Например, разработка новой версии платформы и новой версии продукта на базе этой платформы в одном релизном цикле.
В теории, надо бы сначала стабилизировать платформу, но на практике она устареет к следующему релизному циклу. Да и многие проблемы начнут вылазить только во время интеграции.
Т.ч. эволюция выглядит предпочтительнее революций в плане предсказуемости результатов, но часто проигрывает в продуктивности.croupier
31.01.2018 02:04Ещё раз прошу прощения, невнимательно прочитал ваш комментарий. Удалить не могу, а прошлое уточнение не успело пройти модерацию.
Вашу мысль понял, в целом согласен.
khim
31.01.2018 14:21-1Т.ч. эволюция выглядит предпочтительнее революций в плане предсказуемости результатов, но часто проигрывает в продуктивности.
Зависит от масштаба проекта.
Если человек может, условно говоря, «загрузить» проект себе в голову и «в одно рыло» переписать его — то революция почти всегда лучше.
Если у вас десятки тысяч разработчиков, то вы рискуете увязнуть в тестировании — в сложных случаях настолько, что революция просто «захлебнётся».
Где проходит граница? Этого я до сих пор не знаю…
splav_asv
31.01.2018 20:04Например, разработка новой версии платформы и новой версии продукта на базе этой платформы в одном релизном цикле.
Есть вариант отвязать релизные циклы и сдвинуть платформу на пол года назад например. Получится платформа уже более стабильной к моменту интенсивного использования.
geher
31.01.2018 10:12но в масштабных (200+ человеко-лет) проектах с моим участием примерно так и было.
Оно и в более мелких проектах частенько так бывает.
Только и разницы, что народа на порядки меньше задействовано.
mbait
31.01.2018 03:34+1Для терминов "военная комната" и "корабельная комната" дословный перевод не подходит, а адекватных аналогов я не знаю. "War room" в контексте компании по разработке ПО означает комнату, где идёт активное обсуждение проекта и принятие оперативных решений. Это очень характерно для компаний с open space планировкой, потому что кто бы что ни говорил, а для нормальной продуктивной работы нужна отдельная комната. Сам термин действииельно связан с военными, но правильный перевод в таком случае — ситуационный центр. Это такой зал, который показывают в фильмах, где сидит президент и думает, отдавать приказ о тотальной анигиляции или нет. "Ship room" я вижу впервые, но, опять же, в контексте разработки программ "ship" означает очередную публикацию изменений, обычно его применяют в случае, когда ПО обновляется по методу rolling release, то есть без фиксированных версий.
maisvendoo
31.01.2018 07:41«военная комната» и «корабельная комната»
Нет ничего элементарней — «штаб» и «мостик». Вот вам адекватные аналоги
SgtRiggs91
31.01.2018 12:55Имхо, тут уместнее смысловой перевод. «War room» — комната обсуждений, «Ship room» — комната поставки. Как-то так.
perfect_genius
31.01.2018 09:55И в итоге в Win7 пришлось сделать шаг назад или же всё улучшили?
SgtRiggs91
31.01.2018 12:47+1Win7 вышла в гораздо более удачное время. Мало того, что к моменту её выхода прошёл шок от Vista и производители софта и железа уже начали поставлять совместимые решения, так ещё и технобум в области традиционных ПК пошёл на спад (вернее — перешёл в поле смартфонов, с первыми релизами iPhone и Android). В итоге у MS была основная задача исправить проблемы Vista (т.е. фактически отладить релиз), никаких революций на релиз Win7 не планировалось. Он вообще изначально должен был стать чем-то вроде сервис-пака для Висты, только называться по-другому, чтобы не тянуть за собой её испорченную репутацию.
engine9
31.01.2018 10:39Ого, какие откровения. Интересно, насколько корректно провести аналогию с разработками иных сложных систем, вроде авиалайнеров, заводов, электросетей и т.п., там тоже содержится такое количество «багов»? Или такое сравнение некорректно? Возможно ли применение опенсорц подхода к разработке, например, законов или автомобилей?
geher
31.01.2018 10:57Поимерно то же и творится. Баги часто устраняют уже в процессе эксплуатации.
Некоторые по итогам кстастроф.
Разве что из-за более жестких наказаний за последствия багов процесс отладки перед релизом более тщательный, а в последний момент могут втиснуть только что-то, не влияющее на основной функционал (например, другой проект забора вокруг АЭС).
Опенсорс вполне ложится, но оно часто слишком дорого для энтузиастов получается (как по реализации, так и по ответственности), а бизнес не торопится открывать свои секреты.
Germanets
31.01.2018 11:04Думаю, что багов в авиалайнерах и их прошивках на порядок меньше хотя бы потому, что за железо и прошивку отвечает одна и та же команда, а также не требуется совместимость со всем зоопарком железа и ПО, как выпущенным ранее, так и тем, что выпустят в течении следующих нескольких лет.
geher
31.01.2018 11:15Если бы все было так просто.
Если брать уровень конкретного блока и его программы, то да, бардака поменьше, команда одна.
А если брать самолет в целом, то тушку проектируют одна команда, двигатель — другая, систему управления — третья.
Для навигационных систем требуется обратная совместимость со всем зоопарком эксплуатирующейся наземной техники.
Иногда случается, что новый двигатель к релизу не готов. Ничего, прикручивают старый. Иногда даже совместимость со старым закладывается на этапе проектирования.
Список можно продолжать.Oxoron
31.01.2018 13:56+1geher А можно статью? С деталями?
geher
31.01.2018 14:49Статью не получится. Для этого надо провести исследования и систематизировать данные.
А у меня набор разрозненных фактов, полученных в разное время из разных источников в процессе удовлетворения нездорового любопытства без фиксации пруфов.
t-nick
31.01.2018 15:32Возможно не совсем в тему, но неплохо раскрывает некоторые особенности данной сферы habrahabr.ru/post/202184
JediPhilosopher
31.01.2018 13:00не требуется совместимость со всем зоопарком железа и ПО
Удачные модели самолетов проходят множество модернизаций за десятилетия эксплуатации, так что зоопарк вполне себе бывает.
LynXzp
31.01.2018 15:55Один раз поставили индикаторы топлива от других датчиков. Результат — завышенные показания -> авария. После этого вышло требование делать для несовместимых датчиков несовместимые разъемы.
Так что зоопарк зоопарком, но представьте что у вас для каждого периферийного устройства свой USB разъем. И если в материнке нет определенного разъема то «извините, ваша флешка не подходит».
Я не оправдываю что в авиации все проще. Там наоборот — на много больше ситуаций и защитных механизмов. И «зоопарк» — это потенциальная угроза, поэтому в рамках безопасности его ограничивают списком поддерживаемых узлов и физически совместимых разъемов.
F0iL
31.01.2018 14:10Софт для авиалайнеров разрабатывается по немного другим принципам. Там часто V-модель разработки, из которой следуют четко сформулированные требования разных уровней (от самого высокого до самого низкого), что упрощает тестирование и верификацию, жесткие стандарты типа DO-178B/DO-278 для авиации, MISRA для автомобилей, и др.
В итоге софт пишется медленно и дорого, но надежно.
Что же до промышленной автоматизации, то там бардак бывает похуже описанного в статье, да.
acmnu
31.01.2018 14:06+3Я начинал карьеру с верификации софта авиалайнеров. Там все на столько не похоже, на привычную всем разработку, что описывать не на одну страницу. Фактически от простой идеи подобной "когда в баке заканчивается топливо, нужно заморгать вот этим сообщением" проходит 5-6 стадий на которых создаются и верифицируются разнообразные спецификации.
Коротко и в общем эти стадии выглядят так.
- Человек понимающий как самолет летает, задает общие параметры для данной подсистемы (в данном случае спецификации и регламенты связанные с минимально допустимым объемом топлива, достаточного для продолжения полета).
- Другой авиационный эксперт разбирает эти спецификации и находит конкретные значения и условия примерно в выражениях указанных выше.
- Специалист ответственный за понимание логики работы пилотов и взаимодействие экипажа указывает в каком виде необходимо получить оповещение (какой экран, какой звук, уровень критичности и т.д.) и параллельно инициирует процесс изменения летной документации, в том числе карт, если это надо.
- Специалист понимающий архитектуру информационной системы самолета описывает какие подсистемы должны участвовать в данном действии и как они взимодействуют
- Специалист отвественный за конкретную систему (в данном случае подсистема нотификаций) создаёт общую спецификацию для данной системы.
- Другой узкий специалист пишет псевдокод, либо UML в терминах конкретной системы.
- А вот и программист. Он либо пишет переводит псевдокод в реальный код, либо его здесь нет, поскольку есть UML генератор.
- Программист верификатор сверяет, что спецификация соответсвует коду и покрытие кода 100%
На каждом шаге определена процедура ревью. Каждая спецификация проходит прямо или косвенно проходи тестирование, но это процесс параллельный и сильно завязанный на работу с реальным железом или даже реальные полеты. Программисты работают с реальным железками, либо с сертифицированными эмуляторами. Вся эта история жестко зарегламентирована. В частости компания осуществляющая верификацию не должна быть аффилирована с тем кто софт производит. Главная библия это стандарт DO-170b. По нему же работают производители ПО для опасных производств (например атомная станция)
JediPhilosopher
31.01.2018 15:01+1Может напишите статью на эту тему?
acmnu
31.01.2018 15:37Думаю можно, но уж очень давно я этим занимался (больше 10 лет назад) и моя информация может сильно устареть.
LynXzp
31.01.2018 15:58Что-то мне подсказывает что от момента начала разработки до выхода системы может пройти и больше 10 лет, по крайней мере в редких случаях.
А уж сроки эксплуатации…acmnu
31.01.2018 16:29Может и 10, хотя надо понимать, что аппартная часть, операционные системы и шины данных (как софтовые так и аппаратные) унифицированы в пределах бренда и легко переносяся на сходных пот ТТХ и начинке самолетах. На моей памяти с нуля запускали в производство бизнес джет и на это ушло где-то два года. Понятно, что B787 разрабатывался значительно дольше.
ElectroGuard
31.01.2018 17:08Почитайте как-нибудь, что на атомных станциях творится :) В сети есть откровения кое где. Атомные байки всякие. Удивительно, что было мало серьезных инцидентов за всё время.
Iceg
02.02.2018 16:14Даже не представляете. Самое лайтовое — это когда что-то не влазит куда-то. Типа, тут у нас по проекту шкаф, а там дверь. Но если поставить туда настоящий шкаф, то дверь не откроется/не закроется) Или вот вам две железки, по проекту одна передаёт другой важные параметры, только вот общих протоколов они не знают. Это все ужа на согласованных проектах. А уж какие чудеса на проектной стадии творятся. Но веселее потом эксплуатации, которая получает г в обертке — на всём сэкономили, а эксплуатировать будьте добры как новое, по документам все чисто, все одобрено, вот вам подписи, сертификаты, согласования.
Естественно, в наш век все заводы и электросети пользуются тем же самым софтом, которое пишется по описанным выше методологиям.
mathematician90
31.01.2018 11:29Теперь ясно, почему у висты были такие проблемы. Наверное это из разряда, как не надо не просто управлять проектами, а даже и вообще вопросы организации разработки
RationalBot
31.01.2018 11:39Рано или поздно любая организация начинает выдавать в качестве продукта свою организационную диаграмму, и Windows не исключение. У open source нет такой проблемы.
Интересно, как закон Конвея проявляется в крупных open source сообществах. Есть у кого-нибудь такой опыт?
chernish2
31.01.2018 12:12Спасибо за перевод, очень интересная статья! Только мне вот что непонятно — по идее, масштабы использования последующих версий Windows должны были быть ещё больше, значит ли это, что они тоже сталкивались / сталкиваются с такими же проблемами, или же в Microsoft что-то кардинально изменилось с выпуском Vista? Отличается ли процесс разработки Windows 10 от предыдущих версий в контексте проблем, затронутых в статье? И еще интересно, в чём были конкретные отличия Longhorn от Vista, кроме упомянутой WinFS?
Javian
31.01.2018 12:24Видел несколько лет назад (еще до интерфейса Win8) на ФБ публикацию в ленте бывшего программиста Microsoft с его комментарием «its true». Запомнилось тем, что перед этим он рассказывал несколько поучительных историй о проблемах с менеджментом в Microsoft.
карикатура
EliasMath
31.01.2018 13:35Должны ли мы смотреть в прошлое с разочарованием или сожалением? Нет, я предпочитаю усвоить полученные уроки.
Какие уроки Вы усвоили? Ну, или так — какие уроки можно извлечь?
As for me, то вряд ли кто будет судить разработчиков Vista… Когда много проектов в одно время, то очень сложно сфокусироваться на каком-то одном, чтобы сделать его качественно. Да и решение — лепить из старого — мягко говоря, неэффективно…
croupier
31.01.2018 13:35Простите.
Перечитал внимательнее и понял, что всё неправильно понял, но удалить свой коммент уже не могу.
Игнорьте плиз, всё что я написал.
Mortemia
31.01.2018 13:35Ужасы какие :0 Дисклеймер хоть ставили бы, читать же больно! Сразу перед глазами вся жизнь разработческая проносится
MacIn
31.01.2018 18:53проявлял некоторые влияние на дизайн операционной системы и тянул его в разных направлениях
design сущ.
конструкция
устройство
архитектура (software)
структура, программная структура
программная архитектура
системная архитектура
Dark_Purple
31.01.2018 20:11В последнее время мое мнение о мелкософте все хуже и хуже!
З.Ы. У меня так: 98->Me->XP->7->10->7
Skerrigan
01.02.2018 07:44+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.Taciturn
02.02.2018 16:29DDR4
А тут то какая поддержка со стороны ОС нужна?
sumanai
02.02.2018 16:47Семёрка отрубает обновления на процессорах с поддержкой DDR4. Чушь конечно же, никакой поддержки со стороны ОС там не нужно, уверен, что при должном упорстве можно и XP завести.
Skerrigan
02.02.2018 18:28Чушь конечно же
Не разбираясь до конце не лезли бы с такими категоричными заявлениями.
Сама память не при чем. Как бы, только, если включить логику, можно понять, что новый тип памяти ну вообще никак не подходит к старым материнкам.
Соот-но, материнки только нового поколения, на которых старые ОС вообще не запускались.
Я заказывал железо в 2015-том. Практически сразу же после того, как оно вообще начало сходить с конвееров. Покупал естественно на Amazon. Потом его привезли в сибирь. Тут я все собрал. И, как это ни удивительно, даже ЦП не подошел к материнке, хотя был заявлен, как «точно совместим».
Связался с саппортом (материнки). Пообщались. Они сказали, что пока мой заказ ехал, у них вышло 6! внутренних ревизий по прошивке. Отнес в сервис, обновили микрокод в ЦП, обновили прошивку материнки. После этого железо завелось. Но 7-ка при установке падала с ошибкой. Еще раз пообщался. Поставил после этого 10-ку, завелось с пол пинка.
Сейчас конечно, уже все до конца починили (я так думаю), но смысла в древних (ХР) или старых (7) просто нет никакого.sumanai
02.02.2018 18:44Не разбираясь до конце не лезли бы с такими категоричными заявлениями.
Проблемы могут быть только в UEFI и совсем нестандартных драйверах на контролёр диска. Всё остальное в принципе не может мешать поставить старую ОС, переведя UEFI в режим совместимости и используя стандартные драйвера там, где нет специальных.
но смысла в древних (ХР) или старых (7) просто нет никакого.
Это для вас нет.
geekmetwice
31.01.2018 22:32… её «отсылали в Сибирь», то есть продолжали разработку компонента, который по большей части игнорировала вся остальная организация и который был обречён на неудачу или бесполезность — но группа или руководство просто не могли принять решение об отказе от разработки.
… и тут же:
Принимали ли мы специально неверные решения? Нет, я не могу вспомнить ни одного.
Один я вижу, что вся эта статья — подобие «покаяния», при этом не признавая никакой вины? Неужели узколобое, непрофессиональное «планирование фич» — это из-за «быстро меняющегося мира ИТ»? Чушь, если не сказать резче!
Скажем прямо: у микрософта всегда была безобразная организация компании, «дешёвый» HR, соответственно и продукты выходили один ужаснее другого. Зато юристы и маркетолухи отрабатывали на 146%!
forcam
01.02.2018 16:46В свое время Microsoft всерьез рассматривала создание 128-битной системы написанной полностью с нуля, т.к. стабильность работы системы всегда вызывала вопросы, ну и сами работники признавали то, что архитектура давно морально устарела. Но пошли по пути наименьшего сопротивления, windows 7/8/10 одна и та же операционка, с одним и тем же ядром, с минимальными внутренними изменениями, но с максимальными внешними изменения и как следствие нереальное количество багов и проблем. Находятся даже те кто спорят что это не так, и это разные системы. Но банальное сравнение производительности и разница в 1% всегда говорит об обратном. Печально все это, хотелось бы чего-то действительно революционно нового, впрочем 64-битная архитектура рано или поздно все равно себя изживет, вопрос времени.
stychos
01.02.2018 20:56А есть где отсылки про 128-битную архитектуру? Мне это запомнилось только как одна из April's Fools.
DjOnline
02.02.2018 00:19Да это просто хабр превратился в пикабу, не обращай внимания.
stychos
02.02.2018 00:31А, ну тогда ладно — а то подумал, может, внезапно, уже настолько стар, что память совсем ни к чёрту.
khim
02.02.2018 00:36С учётом того, что в те времена 128-битная архитектура жила у Microsoft в бухгалтерии — не удивлюсь если разговоры об этом действительно шли…
DjOnline
02.02.2018 00:55Если что, AVX-512 вообще 512бит, но это SIMD инструкции, которыми в самой ОС Windows особо делать нечего.
khim
02.02.2018 01:38А по ссылкам ходить — уже не модно нонче? 1988й год, AS/400, байткод, 128-битные указатели, да. Никакого SIMD'а.
acmnu
02.02.2018 10:09Ну нужно все таки различать адресуемость памяти и разрядность обычных регистров, а то так и 286 можно 20 битным назвать.
khim
02.02.2018 13:04-1И какой же, я извиняюсь, регистр в 286м имеет размер в 20 бит?
mayorovp
02.02.2018 13:20У него шина адреса была 24 бита же.
khim
02.02.2018 13:30Тогда почему он вдруг 20 битным станет?
acmnu
02.02.2018 13:57Просто кто-то из нас ошибается. Наверное я. Фишка 286 в том, что адресация там больше чем 16 бит за счет дополнительного регистра.
khim
02.02.2018 14:29Там была сложная система адресации. Но завести массив размером в мегабайт было нельзя (хотя можно было имитировать его). На AS/400 завести эксабайтный массив можно (по крайней мере написать такую программу можно… при запуске на сегодняшних, реально существующих, системах памяти не хватит, разумеется).
firk
02.02.2018 15:52Массив там тоже можно было хоть эксабайт, и естественно памяти бы не хватило.
Нельзя там в одной ассемблерной инструкции указать адрес в диапазоне более чем 64кб — да.
Нельзя обратиться к физической оперативной памяти в диапазоне более чем 16мб (любым количеством инструкций) — да.
Объём доступной одновременно виртуальной памяти без перенастройки системных таблиц — уже 1гб. С перенастройкой — зависит только от операционной системы и процессором не ограничено.
Выше была теория, а на практике — fortran (вроде бы ms) вполне прозрачно позволял объявлять массивы больше 64кб и работать с ними.
А указатели на 286-м 32-битные кстати.
acmnu
02.02.2018 13:23В том то и дело что никакой.
khim
02.02.2018 13:33А вот в байткоде AS/400 (сегодня переименованной в IBM System i) все указатели — 128 битные. Разница есть?
И да — мы говорим не о битности процессора, а о битности операционной системы. В системе, в которой все приложения написаны на байткоде, разумно плясать от свойств этого байткода, а не от свойств процессора.
acmnu
02.02.2018 10:07Про 128бит это была первоопрельская шутка. При чем за давностью лет я даже не знаю сам ли MS на это сподобился, или кто-то из новостных агенств.
Просто любому в отрасли понятно, что на широком рынке такая битность не нужна сейчас, а узкоспециализированные решения это не конек MS и Intel
xRay
02.02.2018 14:27Windows 10 и ее система обновлений это видимо вечная бета… После системы обновлений в 7-ке как-то вообще плохо.
Пользователю нельзя выбрать какое обновление ставить. И везде в 10-ке торчат (хотя и стараются спрятать подальше) интерфейсы от 7-ки.khim
02.02.2018 14:30Пользователю нельзя выбрать какое обновление ставить.
Ну это-то как раз хорошо. Именно тот факт, что никогда нельзя было быть уверенным в том, что именно пользователь поставил, а что — решил проигнорировать, было большой проблемой для разработчиков…
sumanai
02.02.2018 16:50После системы обновлений в 7-ке как-то вообще плохо.
Пользователю нельзя выбрать какое обновление ставить.
А разве в семёрку не завезли такие же кумулятивные обновления?
KirEv
у микрософта странная закономерность, пользовался с win98 до win10.1, так вот через одну — выпускают глючный ОС, виста попала посерединке (между стабильными)… 98ок, 2000 не ок, хр ок, виста не ок, вин7 ок)…
maisvendoo
Известная теорема о лысом-волосатом
Iv38
Неоднократно наблюдал, как за упоминание этой закономерности огребали минусов, потому что она несколько натянута. Например, в данном случае потеряна ME, непонятно как быть с параллельной линейкой NT, нужно ли рассматривать 98 и 98 SE как две разные системы, спорный вопрос негодности Win2k, на какой момент считать годной XP и т.д.
Хотя вообще такая неравномерность логически объяснима. Негодными получаются в основном те версии, которые многое меняют, последующая версия закрепляет. Вносимые изменения требуют резкого пересмотра привычек, замены железа, обкатки технологий в конце концов. В свете этого может и неплохо, что теперь изменения в десятке выходят два раза в год и без серьезных скачков.
И только ME мне сложно объяснить. Новая модель драйверов, несовместимости и низкая стабильность, на фоне перехода на NT-ядро в параллельной ветке. Я не очень понимаю, зачем ее вообще выпустили? Разрабатывали 9х-линейку и решили не сворачивать, а заработать немного денег?
geher
Наверное, все дело в том, что линейка NT на тот момент была еще не готова для внедрения на компьютерах "обычных" пользователей, а линейка 9х уже слишком устарела для эффективного использования современного на тот момент железа.
В результате и появился "линолеум", временное решение, которое должно было позволить дожить до пользовательского релиза NT, которым в итоге стала ХР.
Кстати, был он не столь страшен, как малюют, и при всех своих проблемах был лучшим доступным решением на тот момент.
Я перешел на линолеум сразу, как он стал доступен. Хотя я и ругался по поводу некоторых моментов (особенно доставляла падучесть, которая возникала при любой попытке выхода за рамки роли пишущей машинки), но желание возвратиться на более стабильную 98 SE почти не испытывал (хотя бы по поичине поддержки большего парка устройств и более человеческой поддержки USB и видеокарт).
NT4 и 2000 в то время страдали от недостатка доайверов на разнообразное экзотическое железо, которое поставщики пихали в "бытовые" компьютеры.
delvin-fil
Ох и огребу же сейчас.
Делал «финт ушами» — прикручивал драйвер флешек от «линолеума» к 98-ой. То еще удовольствие. Но работало.
geher
За что?
Тоже пробовал такое, но лень победила (слишком много драйверов надо было вытащить и прикрутить). Проще было закидоны МЕ терпеть.
delvin-fil
Работал с организациями в которых невозможно было обновить систему. Просто нельзя. Вот и изгалялся.
Plague
Был один хитрый софт, который умело падал на операциях с плавающей точкой, но 98 позволяла отключить «сопроцессор» и перейти в режим эмуляции. Софт переставал падать и все было нормально, т.к. переключать надо было не часто.
Появилась машина с ME — на которой, внезапно, эмуляция сопроцессора была напрочь поломана. Там где должны рисоваться окружности — рисовались линии. О_о
Глючнее ME из всей линейки не видал.
prospero78su
Я также не разделяю истерии по поводу линолеума. Может мне сборка такая попалась и железо до кучи — не знаю. Win98 и Win2000 меня раздражали куда больше. Особенно последний: если на линолеуме мой TV-тюнер K-World нормально работал, то Win2000 падал при каждом третьем переключении канала. WinXP поселился у меня спустя полтора-два года. А под Win98 тюнер K-World просто не работал.
Но надо сказать честно: WinXP SP1 — это уже была серьёзная весьма стабильная система (про защиту от вирусов ничего не говорю). В те же годы Mandrake 5/Redhat/Suse/Slackware — не отличались ни дружественностью, ни простотой настройки, ни той же стабильностью.
Win10, как оказалось на поверку — местами хуже даже Win8.1 (но местами и приятней). Но не лучше любого популярного Linux.
martin_wanderer
Пожалуй, есть более простая закономерность, и, скорее, правило использования: не переходить на новую систему до первого сервис-пака.
evgenWebm
Я так понимаю на Win10 вы не перейдете.
martin_wanderer
Сарказм чую здесь я какой-то. Там изменилась модель обновлений?
И да, скорее всего не перейду, — полтора года как на Ubuntu пересел.
Areso
Да. Однако cumulative update с именем собственным вполне можно считать за SP. Threshold 1 (Inital Release), Threshold 2 (November update), Redstone 1 (Anniversary Update), 2 (Creators Update), 3 (Fall Creators Update)…
firk
Они купили майнкрафт чтобы взять из него идею давать такие имена обновлениям винды.
LynXzp
Скоро узнаете то же самое для Linux: пользоваться только [предыдущей] LTS, или для FreeBSD: пользоваться релизами которые заканчиваются как минимум на *.1
foxin
но при этом не переходить на новый LTS пока не выйдет следующий апдейт (через полгода после релиза LTS)
khim
На самом деле и в мире Windows и в мире Linux идёт обратный процесс. У нас недавно перешли с Ubuntu LTS на Debian testing.
Что увеличило количество запросов в техподдержку, но устранило пики, когда раз в два года всё «стоит на ушах» из-за выхода очередной версии.
Windows нонче, фактически, выходит два раза в год (и горе тем, кто этого не понимает: у моей сестры ноут застрял на «November Update» 1511 и мне потребовалось немало времени, чтобы «убедить» его переехать на Fall Creators Update).
Areso
А сам он постепенно накатить обновления до Annv->Creators->Fall Creators не смог последовательно?
khim
Сам он яростно пытался накатывать Fall Creators напрямую. То есть даже при запуске любого «старого» установщика оно лезло в интернет, выясняло, что есть более новая версия и качало и устанавливало именно её. Что неизменно кончалось тем, что после двух часов бурной деятельности и нескольких перезагрузок появлялась надпись в духе «ну не шмогла я, не шмогла».
Скачав несколько ISO'шек и отрубив Internet удалось убедить установкщиков делать обновления последовательно.
Areso
Еще 1 камень в огород тех, кто придумывал алгоритм обновлений.
khim
Ну тут смешанные чувства. С одной стороны — оно-таки не вставало. С другой — все изменения, сделанные в процессе, после обнаружения проблем автоматически и корректно откатывались.
Это лучше, чем в случае возникновения проблем при обновлениях Android'а, iOS или Linux'а. Скорее всего в подобных случаях обновления бы окирпичивали железку — а тут происходил всего лишь аккуратный откат всего на исходные позиции.
В конце-концов проихсодил апгрейд с уже не поддерживаемой системы, так что моя сестра отчасти ССЗБ…
Areso
ХЗ, к примеру у 1С процесс обновления автоматизирован, в т.ч. с неподдерживаемой обновляешься до следующей, потом дальше и дальше. Прямо-таки иногда целая цепочка обновлений, если пропущено много релизов.
Что помешало им сделать здесь такое же — ума не приложу.
Может, человек в море был? Или в тюрьме сидел? Или в Африке был? Да мало ли по какой причине можно пропустить пару-тройку обновлений.
khim
Ну так они и попытались это поддержать. Просто… Хотели как лучше (избавить человека от необходимости выкачивать гигабайты промежуточных версий), а получилось, как всегда (попытка пропустить два года обновлений привела к тому, что обновиться не получалось в принципе).
chupasaurus
Т.е. вы огребёте при выходе нового релиза, если в sources.list у вас testing вместо имени будущего релиза: после «разморозки» testing плющит и таращит от двух недель до месяца из-за обновления всех core пакетов и DE. Соответственно какое-то время приходится отсиживаться на новом stable, который тоже не всегда такой, как называется.
khim
Для этого есть команда, которая настраивает наши локальные «зеркала».
Мы и раньше, собственно, не использовали «чистый» Ubuntu LTS релиз — ядро, как правило, приходилось брать более новое через год-полтора после релиза, так как «замороженное» ядро не поддерживало некоторые новые железки.
evgenWebm
Конечно. Теперь не существует SP как такового.
Так как винда отказалась от новых цифр в версии Виндовс, то теперь выходят так называемые сезонные обновления(по аналогу сезонных ДЛС для игры).
Считать их СП можно с большой натяжкой, чисто для успокоения своего.
P.S. Ubuntu тоже стабильностью не страдает. Даже LTS лучше использовать чуть погодя после релиза, а лучше вообще версию .1 сразу ждать. По аналогии с СП ;)
ololowl
Возможно это проявление регрессии к среднему. Отношение к каждой следующей версии винды смещается от отношения к текущей версии в сторону нормального.
Whuthering
Классическая ветвь: 95 — не ок, 95OSR2 — ок, 98 — не ок, 98SE — ок, ME — не ок. Тут скорее «фиксы выходят спустя некоторое время после релиза и все начинает работать нормально»
NT-ветвь: 3.51 и 4.0 не застал, 2000 очень ок (лучшая из всех, пожалуй), XP — не ок, XP SP2/SP3 (даже автор статьи сказал, что это по сути дела другая система, плюс см. предыдущую строку) ок, Vista не ок, 7 ок, 8 не ок, 8.1 вполне ок, 10 -тут rolling release, первые версии не ок, те что новее ок.
Lirein
Дополню: NT3.5 — не ок, NT 4.0 — ок (стабильнее чем 2000), 2000 до SP2 — не ок, SP3 — приемлимо, SP4 — ок
XP SP2 — очень много глюков приехало из лонгхорна — в том числе IPv6 отключался в настройках адаптера вплоть до SP3, ибо с включенным IPv6 и адресе IPv4 + Link-Local IPv6 на работал интернет (неверно маршрутизировались Scope).
africaunite
Вы пропустили Windows NT 3.51, которая была стабильнее любой предыдущей и последующей версии системы.
Lirein
Тогда NT4.0 до SP2 — не ок. Я ещё помню как NT 4 с дискет ставился (был такой вариант дистрибутива на 114 дискет) и возникновение ошибки вроде «Дискета 113 не читается, замените дискету и начните установку заново» приводила к преждевременной седине в 12 ночи :) Нетварь, впрочем, прекрасно работала поверх тогдашней NT.
Stanislavvv
Ещё можно припомнить древнюю шутку про сервиспаки nt4 — «SP5 — кумулятивный, SP6 — фугасный» :-)
Lirein
А с SP6.5a прилетал IE6, который можно было без особых плясок с бубном обновить до IE7, но это уже было в 2004 или 2005 году. Ну и фидошная нода имела на четвертой NT почти 12 лет аптайма.
LoadRunner
Vista по слухам вроде тоже стала в итоге ок после скольких-то обновлений.
Germanets
Скажу так — скорее всего основное «не ок» было именно в проблемах совместимости программ и драйверов, и именно из-за этого система получила столько негатива… Ещё один неприятный момент — это повышенные требования к памяти, особенно по сравнению с XP: при старте виста у меня сжирала порядка 900 мегабайт оперативы. Особых изменений(за 3,5 года обитания на висте) я в плане производительности и использования оперативной памяти не заметил.
aquamakc
Я на момент выхода Vista работал в компьютерном магазине. Как-то резко появилось в продаже очень много ноутбуков на этой ОС с ОЗУ 1 или даже 0,5 Гб (в бюджетном секторе, конечно). Сколько мы наслушались от покупателей. А заранее предупреждать было чревато. Расскажешь, что конфигурация этого ноута не подходит этой ОС и всё будет работать плохо покупатель просто уйдёт (т.к. могло просто не оказаться другого варианта по устраивающей цене), а уж если нарвёшься при этом на «тайного покупателя» (такой засланный администрацией казачёк с целью проверить работу сотрудников) так можно было вообще нарваться на настойчивую рекомендацию написать по собственному. Если начнёшь советовать нарастить памяти вполне можно было нарваться на обвинение в «навязывании товара или услуги», что уже повод для жалобы в общество защиты прав потребителей.
Nimo_tsi
Я думаю, на такие конфиги производители ставили Висту либо под нажимом MS, либо получая от нее хорошие скидки на лицензию.
aquamakc
Что интересно стоимость лицензии предустановленной винды около 14 баксов (было по тем временам). Было несколько случаев, когда покупатели настаивали на продаже ноутбука без предустановленной винды (долго, муторно и через руководство продажной компании, т.к. ПО системы для оформления продажи не предусматривала такой возможности). Тогда у них на глазах форматировали винт, отдирали наклейку (куда её потом делали логисты — хз) и снижали цену продажи на эти 14 баксов (условные 14, поскольку уже за давностью лет не помню точно).
firk
Vista это бета-версия Win7, нормальной стала после перехода в состояние релиза.
DikSoft
Vista SP2 уже была рабочей системой.
firk
Может быть, но семёрка была рабочей системой ещё в предрелизной версии.
ToshiruWang
Торрентокачалка на атоме (первом) с лицензионной вистой. Работает. На рабочем компе стояла несколько лет (на Core2 каком-то) и тоже ок, ни одного BSOD. Так что бывает.
river-fall
интересно, в чём по-вашему разница 8 и 8.1