А мне Балхаш 9 запомнился жутчайшей жарой и просто бешеными комарами. Каждую ночь был выбор - сдохнуть от жары или открыть окно, но быть сожранным заживо кровососами. А еще запомнился приторно-сладкий запах каких-то цветущих кустов похожих на акацию - единственное что там росло. Запах настолько приторный, что меня до сих пор, спустя 35 лет, от него мутит.
У Вас в какой‑то момент «создали» превратилось в «совершили революцию». Эльбрус создали, он производится и является разработкой мирового класса. Это очевидно.
Возможно это мои личные ощущения, но тот пафос с которым десятилетиями заявлялось о грядущем российском процессоре, говорит о претензии на революцию.
Является ли процессор Эльбрус разработкой мирового класса? Как таковой - наверно. Но если он не доступен повсеместно, причем на вменяемых экономических условиях, не имеет развитой поддержки производителей прочего железа, то это не имеет значения. Получается как по Лескову - да, у нас есть Левша и он может, только толку от этого никакого. Блоха подкована, но прыгать не может. Хотя к талантам Левши никаких претензий.
Стал ли он революцией — отдельный вопрос. Вообще‑то, на мой взгляд, — стал.
30-лет назад, из-за сложности и стоимости всего процесса от дизайна до производства, рынок сводился к десятку универсальных процессоров. И рождавшийся в 90е Эльбрус претендовал на конкуренцию именно на этом поле. Сегодняшний рынок, помимо универскльных камней, ориентируется на выпуск широчайшей гаммы специализированных процессоров, которые наиболее эффективны в своих областях. Вполне возможно, что в определенных областях Эльбрус не знает себе равных. Возможно, что принятные в нем решения воистину революционны. Возможно. Но для разработчиков систем его практически не существует на рынке. Пусть он трижды гениален, уникален и вообще - продукт космических технологий. Но фактически его нет. Тем более, если он позиционируется как универсальный процессор. Так что если революция и была, то ее никто не заметил.
Даже Байкал, IMHO более успешен в этом плане, хотя ни в чем не революционен.
Эльбрус - как вычислительный комплекс? - проект скончался в начале 90х, так и не пойдя в серию.
Эльбрус - процессор? Долгострой, который обещал порвать всех, вот скоро-скоро, вот уже сейчас, уже почти... да, он вышел в середине 2000 и развивается до сих пор, но никакой революцией не пахло. Насколько он используется в военке я не знаю.
В 1999 от НИИВК мы ездили в МЦСТ покупали спарки. Забавно, что получается у исторических конкурентов (МЦСТ это контора Бабаяна, которая была конкурентом НИИВК Карцева). Нам тогда в МЦСТ восторженно рассказывали про убийцу пентиумов. Но...
Забавно. Я помню М10 в НИИВК на Волгина, это одни из самых детских воспоминаний. И машинный зал помню, и жутко гудящий этаж с оборудованием охлаждения. И М13 в новом здании НИИВК на Беляево помню. И на одной из станций слежения бывал, на Балхаше в Казахстане. А в самом НИИВК я работал в 2000м году, но сам НИИВК тогда выглядел уже как фидо в 2026 году.
Почему не создали машину на совренной базе? Потому что были 90е, потому что часть станций слежения ушли вместе с бывшими республиками, потому что костяк архитекторов и инженеров этих машин поехал в туристическую поездку в Вену, но назад так и не вернулся...
Благодарю за перечисление регалий, но, простите, не впечатляет как аргумент. Мое виденье основывается не на "булшит презентациях", как вы изволили выразиться, а на опыте внедрении FTTH/FTTB/FTTO нашей компанией - одним из трех основных французских операторов (AS5410) с 4,6М абонентов FTTH и с 36,5М развернутых точек подключения. То, что вы заявляете как безусловную истину, не учитывая ни технические, ни бизнес особенности других стран/регионов, ставит точку в вопросе весомости ваших аргументов.
Позвольте не согласиться. FTTB требует активного оборудования в оконечном здании, со всеми соответствующими требованиями по питанию, вентиляции, защите доступа и т.д. Если оборудование является частью сети провайдера, то на него ложатся все задачи по мониторингу, обслуживанию, плановой замене оборудования, что сотавляет весомую часть CAPEX. В этом плане PON проще и дешевле.
Второй момент - FTTB интересен в случае больших зданий с большой плотностью потенциальных абонентов. В случае одно- и малоэтажной застройки FTTB принципиально невыгоден.
Спасибо за своевременную статью. Мы как раз в процессе тестового развертывания мониторинга BGP через BMP и я во многом основываюсь на опыте опубликованном в упомянутой статье, особенно во второй части https://habr.com/ru/companies/ozontech/articles/861376/.
Потому вопрос. Елена в своей статье указывает на выбор GoBMP, хотя ссылается на баги, в частности на баг с ASN32. Ее статья вышла в ноябре 2024, значит ли что этот баг не был пофиксен? Или вы не тестировали GoBMP?
Вы отдали предпочтение pmacctd. Были ли какие-нибудь трудности/баги/подводные камни с этим коллектором?
Так же указывалось, что pmacctd активно развивается, хотя последний релиз 1.7.9 датируется агустом 2024.
Конечно. Хотя боюсь, что если не вдаваться в подробности обсуждения деталей конкретных функций, то получится банальный список преимуществ с которых начинается любая книга по IPv6. Но тем не менее: стройный и оптимизированный для обработки сетевым оборудованием формат заголовка; механизм расширяемости заголовка, что позволяет развивать протокол и адаптировать под принципиально новые цели (пример - SRv6); многотиповая адресация, включающая обязательную локальную адресацию, что вместе с автоконфигурированием SLAAC (причем как базовая часть самого протокола) решает вопрос автономной работы сегмента сети, изначальное сосуществование различных префиксов на одном интерфнйсе дает значительную гибкость архитектуры; философия резделения префикса и интерфейсной части адреса где интерфейсная часть предусматривает избыточное колличество адресов в подсети, позволяет избежать пререадресации подсети из-за нехватки адресов; изначальная четкая административная иерархия адресов, что позволяет качественно агрегировать маршруты в таблице маршрутизации и тем снизить их общее число, а следовательно снизить время конвергенции; почти полное избежание фрагментации, что положительно сказывается на производительности и проч. проч. проч. ...завершая сегментной маршрутизацией SRv6, которая заменяет костыль MPLS и упрощает программирование путей (traffic engineering), что, с учетом упрощения стека протоколов управления сетью, выглядит эффективнее SR/MPLS и тем более RSVP-TE, а с другой стороны дает новые возможности маршрутизации согласно различным критериям (network slicing).
Нельзя сказать, что каждое из перечисленных преимуществ является уникальным и/или революционным именно благодаря IPv6. Большинство из них имеют в том или ином виде реализацию в существующем IPv4 / MPLS. Изящество IPv6 заключается в том, что лучшие идеи и решения, наработанные за последние полвека, складываются в единую стройную систему, которая тем не менее оставляет возможность дальнейшей эволюции протокола без костылей и патовых ситуаций обратной несовместимости. С определенной точки зрения, IPv6 это работа над ошибками и переосмысление всего опыта построения сетей.
Это в общем виде. А далее, если говорить о изяществе, то стоит обсуждать конкретные решения/функции/фичи в частности.
Микрософт вообще убрал в W10/W11 возможность добавлять пользовательские панели в таскбар, что просто бесит, особенно если вы привыкли пользоваться ими в течении десятилетий. Подобная программа решает именно эту проблему.
Не совсем понимаю откуда берется "на порядок". На бумаге все корректно, но это было справедливо четверть века назад, в эпоху коаксиала и хабов. С тотальным распространением коммутаторов и микросегментации (когда в сегменте находятся только сам коммутатор и единственный хост, к тому же работающие в дуплексе) говорить о конкуренции доступа к передаче - бессмысленно. Пропускная будет зависить от тактовой частоты, алгоритма модуляции, межкадровых интервалов. Но откуда отимизация на порядок? Или я что-то упустил?
Однако это не меняет сути дискуссии. На мой взгляд, повторюсь, черезмерная интеграция разных функций в одной программе (особенно при остутствии модульности) является плохой практикой, приводящей к ожирению продукта со всеми вытекающими последствиями - неэффективному использованию рессурсов, к усложнению продукта, к ухудшению процесса разработки и поддержки. Но это я уже формулировал выше.
Мне кажется вы ошибаетесь. Bloatware - это всякий дополнительный софт, устанавливаемый вместе с основной программой, часто без согласия пользователя. Зачастую эти программы вообще мало соотносились с основной. Как "книга в нагрузку", в советские времена. Мы же говорим о программах, которые стали включать внутрь себя кучу фич, которые не связаны напрямую с изначальным назначением основной программы.
Около 25% пользователей Opera Presto использовало встроенный почтовый клиент. Так что это очень большая доля.
Позвольте с вами не согласиться. На тот момент уровень оптимизации приложений был выше нежели сегодня. По причине меньших обьемов пвмяти, меньшей мощности процессоров, меньшего уровня промежуточных абстракций API.
Базовый уровень был приемлим для большинства пользователей? Прекрасно. Только для дускуссии было бы хорошо если бы вы привели статистику доли от этих пользователей, которые использовали эти дополнительные функции Оперы, в частности почтовый клиент. У меня такой статистики нет, но есть сомнения, что встроеный почтовый клиент был так же широко востребован как сам навигатор. Именно из-за скудности его функционала по сравнению с повсеместно используемыми в России TheBat'ом и Outlook'ом. Именно это могло бы быть аргументом в дискусии комбинированных решений против набора отдельных специализированных приложений.
Но ключевое опущение в вашей аргументации это "на тот момент". То, что Опера 7 реализовывала насколько функций как таковых не говорит о том, что эти функции были реализованы на приемлимом уровне (по сравнению с реализациями тех же функций в отдельных приложениях), но тем более не говорит о том, что такое комбинирование является эффективным решением на сегодняшний день - именно как единая среда для большинства каждодневно используемых приложений (включая помимно навигатора почтовый клиент, мессенджеры, текстовый редактор, графический редактор, ssh клиент и проч. - у каждого свой собственный список). Реализовать базовый набор функций не сложно, все проблемы начинаются вместе с нюансами, когда к функции появляются специфичные требования. В этом плане отдельные приложения в состоянии предоставить эти специфичные возможности, комбинированные приложения - нет. А если и пытаются охватить специфичные требования, то быстро монстроизируются. К тому же, замедляется реакция разработчиков на развитие таких комбайнов - требуется охватывать изменения в гораздо более широком списке областей, с отдельной проблематикой в каждой области. Хорошо если успевают латать дыры, а дожидаться новых или специфичных функций можно годами. Разработчики приложения для отдельной области куда более оперативны и гараздо лучше владеют своей темой.
Разумеется, комбинированные решения тоже имеют свою нишу и востребованы. Я использовал ту же Оперу как портабельный тулкит в поездках. Но речь идет не о конкретном приложении, а именно о самом подходе как таковом и единственный (пусть даже удачный) пример не является достаточной аргументацией. Outlook тоже комбайн, но большинство своих функций он выполняет очень плохо.
Не очень понял ваш довод. Размер файлов браузера это один из параметров, причем один из самых незначительных. Скорее вопрос как он обходился с памятью, с ресурсами CPU и мультипоточностью, что у него с правами и ограничением доступа к файлам на диске, к камере, к usb? Не говоря уже о том, насколько этот гигантский функционал был реально функционален, и не являлся свистелками и перделками (по сравнению с отдельными решениями каждой из фич на тот момент)? И как-то странно говорить про решение эффективное 20 лет назад с точки зрения технологий и требований сегодняшнего дня. OS/2 тоже была прекрасна 30 лет назад, но как-то странно ее сравнивать с сегодняшними ОС и теми задачами которые они решают.
"Уважаемые пассажиры! Добро пожаловать на борт нашего нового авиалайнера. На первом этаже расположены салон, боулинг и ресторан, на втором этаже - библиотека, бар и джакузи, на третьем - солярий и поле для минигольфа.
А теперь просим занять свои места и мы попробуем взлететь со всей этой херней."
А если серьезно, то я согласен с предыдущим оратором. Как показывает история, попытка впихнуть все в единую среду всегда приводит к монстроидальности и тяжеловесности. Уже проходили с джавой и различными методами виртуализации, направленными на абстрагирования от уровня OS и железа. Преимущества были (и остаются) очевидными - кросплатформенность, стандартизация среды разработки и выполнения, и т.д. и т.п., но... мировой революции так и не произошло. Потому что у всякой палки всегда находится другой конец, такой как проблемы производительности, проблемы оптимального использования ресурсов, проблемы управления доступом к ресурсам и проч.
В этом плане UNIX-way мне импонирует куда больше. Под каждую задачу - свой инструмент. Колоть орехи микроскопом можно, но лучше все же взять орехоколку.
...и вся красота заканчивается в момент разворачивания IPv6. Когда выясняется, что OSPFv2 не поддерживает IPv6 и надо параллельно разворачивать OSPFv3. Не переходить с одного на другой, а именно разворачивать параллельно, ибо обновленный OSPFv3 не в состоянии поддерживать 2 семейства адресов в рамках одного процесса, так что придется поднимать либо OSPFv2+OSPFv3, либо 2хOSPFv3 (один для IPv4, другой - для IPv6).
В действительности просветление часто настуавет раньше, с переходом на IS-IS.
Использую на двух списаных ноутбуках Dell X1 20-летней давности в качестве переносных консолей для подключения к маршрутизаторам в датацентре. Нужны только эмулятор терминала и wireshark. Есть и современные ноуты, но Dell X1 во многом идеален и не хочу выкидывать из сентиментальных чувств. Прочие минималистичные дистрибутивы притормаживают, TinyCore летает.
Понравилась организация работы с приложениями, где каждое приложение монтируется как маленькая файловая система. Своеобразная контейниризация.
Ничего необычного в моем кейсе нет, но позволило продлить жизнь старому прекрасно работающему железу.
Сгорело все. В 2004 году. Вот здесь есть фотки и воспоминания. https://safiullin.livejournal.com/710.html
А мне Балхаш 9 запомнился жутчайшей жарой и просто бешеными комарами. Каждую ночь был выбор - сдохнуть от жары или открыть окно, но быть сожранным заживо кровососами. А еще запомнился приторно-сладкий запах каких-то цветущих кустов похожих на акацию - единственное что там росло. Запах настолько приторный, что меня до сих пор, спустя 35 лет, от него мутит.
Возможно это мои личные ощущения, но тот пафос с которым десятилетиями заявлялось о грядущем российском процессоре, говорит о претензии на революцию.
Является ли процессор Эльбрус разработкой мирового класса? Как таковой - наверно. Но если он не доступен повсеместно, причем на вменяемых экономических условиях, не имеет развитой поддержки производителей прочего железа, то это не имеет значения. Получается как по Лескову - да, у нас есть Левша и он может, только толку от этого никакого. Блоха подкована, но прыгать не может. Хотя к талантам Левши никаких претензий.
30-лет назад, из-за сложности и стоимости всего процесса от дизайна до производства, рынок сводился к десятку универсальных процессоров. И рождавшийся в 90е Эльбрус претендовал на конкуренцию именно на этом поле. Сегодняшний рынок, помимо универскльных камней, ориентируется на выпуск широчайшей гаммы специализированных процессоров, которые наиболее эффективны в своих областях. Вполне возможно, что в определенных областях Эльбрус не знает себе равных. Возможно, что принятные в нем решения воистину революционны. Возможно. Но для разработчиков систем его практически не существует на рынке. Пусть он трижды гениален, уникален и вообще - продукт космических технологий. Но фактически его нет. Тем более, если он позиционируется как универсальный процессор. Так что если революция и была, то ее никто не заметил.
Даже Байкал, IMHO более успешен в этом плане, хотя ни в чем не революционен.
Эльбрус - как вычислительный комплекс? - проект скончался в начале 90х, так и не пойдя в серию.
Эльбрус - процессор? Долгострой, который обещал порвать всех, вот скоро-скоро, вот уже сейчас, уже почти... да, он вышел в середине 2000 и развивается до сих пор, но никакой революцией не пахло. Насколько он используется в военке я не знаю.
В 1999 от НИИВК мы ездили в МЦСТ покупали спарки. Забавно, что получается у исторических конкурентов (МЦСТ это контора Бабаяна, которая была конкурентом НИИВК Карцева). Нам тогда в МЦСТ восторженно рассказывали про убийцу пентиумов. Но...
Забавно. Я помню М10 в НИИВК на Волгина, это одни из самых детских воспоминаний. И машинный зал помню, и жутко гудящий этаж с оборудованием охлаждения. И М13 в новом здании НИИВК на Беляево помню. И на одной из станций слежения бывал, на Балхаше в Казахстане. А в самом НИИВК я работал в 2000м году, но сам НИИВК тогда выглядел уже как фидо в 2026 году.
Почему не создали машину на совренной базе? Потому что были 90е, потому что часть станций слежения ушли вместе с бывшими республиками, потому что костяк архитекторов и инженеров этих машин поехал в туристическую поездку в Вену, но назад так и не вернулся...
Благодарю за перечисление регалий, но, простите, не впечатляет как аргумент. Мое виденье основывается не на "булшит презентациях", как вы изволили выразиться, а на опыте внедрении FTTH/FTTB/FTTO нашей компанией - одним из трех основных французских операторов (AS5410) с 4,6М абонентов FTTH и с 36,5М развернутых точек подключения. То, что вы заявляете как безусловную истину, не учитывая ни технические, ни бизнес особенности других стран/регионов, ставит точку в вопросе весомости ваших аргументов.
Позвольте не согласиться. FTTB требует активного оборудования в оконечном здании, со всеми соответствующими требованиями по питанию, вентиляции, защите доступа и т.д. Если оборудование является частью сети провайдера, то на него ложатся все задачи по мониторингу, обслуживанию, плановой замене оборудования, что сотавляет весомую часть CAPEX. В этом плане PON проще и дешевле.
Второй момент - FTTB интересен в случае больших зданий с большой плотностью потенциальных абонентов. В случае одно- и малоэтажной застройки FTTB принципиально невыгоден.
Ха! До МК61 был Moon Lander на ЭВМ СМ-4 со световым пером.
Спасибо за своевременную статью. Мы как раз в процессе тестового развертывания мониторинга BGP через BMP и я во многом основываюсь на опыте опубликованном в упомянутой статье, особенно во второй части https://habr.com/ru/companies/ozontech/articles/861376/.
Потому вопрос. Елена в своей статье указывает на выбор GoBMP, хотя ссылается на баги, в частности на баг с ASN32. Ее статья вышла в ноябре 2024, значит ли что этот баг не был пофиксен? Или вы не тестировали GoBMP?
Вы отдали предпочтение pmacctd. Были ли какие-нибудь трудности/баги/подводные камни с этим коллектором?
Так же указывалось, что pmacctd активно развивается, хотя последний релиз 1.7.9 датируется агустом 2024.
Конечно. Хотя боюсь, что если не вдаваться в подробности обсуждения деталей конкретных функций, то получится банальный список преимуществ с которых начинается любая книга по IPv6. Но тем не менее: стройный и оптимизированный для обработки сетевым оборудованием формат заголовка; механизм расширяемости заголовка, что позволяет развивать протокол и адаптировать под принципиально новые цели (пример - SRv6); многотиповая адресация, включающая обязательную локальную адресацию, что вместе с автоконфигурированием SLAAC (причем как базовая часть самого протокола) решает вопрос автономной работы сегмента сети, изначальное сосуществование различных префиксов на одном интерфнйсе дает значительную гибкость архитектуры; философия резделения префикса и интерфейсной части адреса где интерфейсная часть предусматривает избыточное колличество адресов в подсети, позволяет избежать пререадресации подсети из-за нехватки адресов; изначальная четкая административная иерархия адресов, что позволяет качественно агрегировать маршруты в таблице маршрутизации и тем снизить их общее число, а следовательно снизить время конвергенции; почти полное избежание фрагментации, что положительно сказывается на производительности и проч. проч. проч. ...завершая сегментной маршрутизацией SRv6, которая заменяет костыль MPLS и упрощает программирование путей (traffic engineering), что, с учетом упрощения стека протоколов управления сетью, выглядит эффективнее SR/MPLS и тем более RSVP-TE, а с другой стороны дает новые возможности маршрутизации согласно различным критериям (network slicing).
Нельзя сказать, что каждое из перечисленных преимуществ является уникальным и/или революционным именно благодаря IPv6. Большинство из них имеют в том или ином виде реализацию в существующем IPv4 / MPLS. Изящество IPv6 заключается в том, что лучшие идеи и решения, наработанные за последние полвека, складываются в единую стройную систему, которая тем не менее оставляет возможность дальнейшей эволюции протокола без костылей и патовых ситуаций обратной несовместимости. С определенной точки зрения, IPv6 это работа над ошибками и переосмысление всего опыта построения сетей.
Это в общем виде. А далее, если говорить о изяществе, то стоит обсуждать конкретные решения/функции/фичи в частности.
Микрософт вообще убрал в W10/W11 возможность добавлять пользовательские панели в таскбар, что просто бесит, особенно если вы привыкли пользоваться ими в течении десятилетий. Подобная программа решает именно эту проблему.
Я пользуюсь другой - TrayToolbar'ом https://github.com/brondavies/TrayToolbar/, он полегче, портабельный.
Не совсем понимаю откуда берется "на порядок". На бумаге все корректно, но это было справедливо четверть века назад, в эпоху коаксиала и хабов. С тотальным распространением коммутаторов и микросегментации (когда в сегменте находятся только сам коммутатор и единственный хост, к тому же работающие в дуплексе) говорить о конкуренции доступа к передаче - бессмысленно. Пропускная будет зависить от тактовой частоты, алгоритма модуляции, межкадровых интервалов. Но откуда отимизация на порядок? Или я что-то упустил?
Вы продолжаете пользоваться встроенным в вивальди почтовым клиентом?
Принято
У меня нет причин не верить вам на слово.
Однако это не меняет сути дискуссии. На мой взгляд, повторюсь, черезмерная интеграция разных функций в одной программе (особенно при остутствии модульности) является плохой практикой, приводящей к ожирению продукта со всеми вытекающими последствиями - неэффективному использованию рессурсов, к усложнению продукта, к ухудшению процесса разработки и поддержки. Но это я уже формулировал выше.
Мне кажется вы ошибаетесь. Bloatware - это всякий дополнительный софт, устанавливаемый вместе с основной программой, часто без согласия пользователя. Зачастую эти программы вообще мало соотносились с основной. Как "книга в нагрузку", в советские времена. Мы же говорим о программах, которые стали включать внутрь себя кучу фич, которые не связаны напрямую с изначальным назначением основной программы.
Любопытно. Это ваша оценка или есть источник?
Позвольте с вами не согласиться. На тот момент уровень оптимизации приложений был выше нежели сегодня. По причине меньших обьемов пвмяти, меньшей мощности процессоров, меньшего уровня промежуточных абстракций API.
Базовый уровень был приемлим для большинства пользователей? Прекрасно. Только для дускуссии было бы хорошо если бы вы привели статистику доли от этих пользователей, которые использовали эти дополнительные функции Оперы, в частности почтовый клиент. У меня такой статистики нет, но есть сомнения, что встроеный почтовый клиент был так же широко востребован как сам навигатор. Именно из-за скудности его функционала по сравнению с повсеместно используемыми в России TheBat'ом и Outlook'ом. Именно это могло бы быть аргументом в дискусии комбинированных решений против набора отдельных специализированных приложений.
Но ключевое опущение в вашей аргументации это "на тот момент". То, что Опера 7 реализовывала насколько функций как таковых не говорит о том, что эти функции были реализованы на приемлимом уровне (по сравнению с реализациями тех же функций в отдельных приложениях), но тем более не говорит о том, что такое комбинирование является эффективным решением на сегодняшний день - именно как единая среда для большинства каждодневно используемых приложений (включая помимно навигатора почтовый клиент, мессенджеры, текстовый редактор, графический редактор, ssh клиент и проч. - у каждого свой собственный список). Реализовать базовый набор функций не сложно, все проблемы начинаются вместе с нюансами, когда к функции появляются специфичные требования. В этом плане отдельные приложения в состоянии предоставить эти специфичные возможности, комбинированные приложения - нет. А если и пытаются охватить специфичные требования, то быстро монстроизируются. К тому же, замедляется реакция разработчиков на развитие таких комбайнов - требуется охватывать изменения в гораздо более широком списке областей, с отдельной проблематикой в каждой области. Хорошо если успевают латать дыры, а дожидаться новых или специфичных функций можно годами. Разработчики приложения для отдельной области куда более оперативны и гараздо лучше владеют своей темой.
Разумеется, комбинированные решения тоже имеют свою нишу и востребованы. Я использовал ту же Оперу как портабельный тулкит в поездках. Но речь идет не о конкретном приложении, а именно о самом подходе как таковом и единственный (пусть даже удачный) пример не является достаточной аргументацией. Outlook тоже комбайн, но большинство своих функций он выполняет очень плохо.
Не очень понял ваш довод. Размер файлов браузера это один из параметров, причем один из самых незначительных. Скорее вопрос как он обходился с памятью, с ресурсами CPU и мультипоточностью, что у него с правами и ограничением доступа к файлам на диске, к камере, к usb? Не говоря уже о том, насколько этот гигантский функционал был реально функционален, и не являлся свистелками и перделками (по сравнению с отдельными решениями каждой из фич на тот момент)? И как-то странно говорить про решение эффективное 20 лет назад с точки зрения технологий и требований сегодняшнего дня. OS/2 тоже была прекрасна 30 лет назад, но как-то странно ее сравнивать с сегодняшними ОС и теми задачами которые они решают.
"Уважаемые пассажиры! Добро пожаловать на борт нашего нового авиалайнера. На первом этаже расположены салон, боулинг и ресторан, на втором этаже - библиотека, бар и джакузи, на третьем - солярий и поле для минигольфа.
А теперь просим занять свои места и мы попробуем взлететь со всей этой херней."
А если серьезно, то я согласен с предыдущим оратором. Как показывает история, попытка впихнуть все в единую среду всегда приводит к монстроидальности и тяжеловесности. Уже проходили с джавой и различными методами виртуализации, направленными на абстрагирования от уровня OS и железа. Преимущества были (и остаются) очевидными - кросплатформенность, стандартизация среды разработки и выполнения, и т.д. и т.п., но... мировой революции так и не произошло. Потому что у всякой палки всегда находится другой конец, такой как проблемы производительности, проблемы оптимального использования ресурсов, проблемы управления доступом к ресурсам и проч.
В этом плане UNIX-way мне импонирует куда больше. Под каждую задачу - свой инструмент. Колоть орехи микроскопом можно, но лучше все же взять орехоколку.
...и вся красота заканчивается в момент разворачивания IPv6. Когда выясняется, что OSPFv2 не поддерживает IPv6 и надо параллельно разворачивать OSPFv3. Не переходить с одного на другой, а именно разворачивать параллельно, ибо обновленный OSPFv3 не в состоянии поддерживать 2 семейства адресов в рамках одного процесса, так что придется поднимать либо OSPFv2+OSPFv3, либо 2хOSPFv3 (один для IPv4, другой - для IPv6).
В действительности просветление часто настуавет раньше, с переходом на IS-IS.
Использую на двух списаных ноутбуках Dell X1 20-летней давности в качестве переносных консолей для подключения к маршрутизаторам в датацентре. Нужны только эмулятор терминала и wireshark. Есть и современные ноуты, но Dell X1 во многом идеален и не хочу выкидывать из сентиментальных чувств. Прочие минималистичные дистрибутивы притормаживают, TinyCore летает.
Понравилась организация работы с приложениями, где каждое приложение монтируется как маленькая файловая система. Своеобразная контейниризация.
Ничего необычного в моем кейсе нет, но позволило продлить жизнь старому прекрасно работающему железу.