Где же он мой отечественный процессор?

Аватар пользователя ivacbka

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

Интересующимся приятного чтения.

 

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

  • Нужно детально описать цели создания данной аппаратуры, условия работы, задачи которые она должна решать, аппаратура не самоцель, а средство, нужно привести конкретные примеры эксплуатации, предсказать будущее хотя бы на несколько лет, описать то, что должно быть совместимо из старья.
  • Как правило многие требования ставятся не на процессор, а на вычислительный комплекс, как таковой, и поэтому проектируя процессор надо сразу видеть вычислительный комплекс целиком, выяснить какая будет память и сколько её потребуется, какая периферия, какой будет потребляемая мощность, форм фактор( сервер или персоналка, или тонкий клиент, или суперкомпьютер), какой софт будет крутиться( учесть требования софта, особое внимание ОС реального времени которые обожают военные, а также виртаулизации), какие нужно поддержать операционные системы, нужна ли виртуализация на аппаратном уровне, и в каких количествах.
  • После того как мы примерно представляем все сценарии использования данной аппаратуры, надо разбить её на логически цельные модули, к примеру на периферию, аппаратные вычислительные комплексы, ОС, драйвера, БИОС. Отдаём каждый компонент коллективу разработчиков. Периферию разобрать на ту которую обязательно делать самим, и на ту которая не является критическим узлом и её можно закупить готовую. К примеру нет смысла делать отечестванный мощный 3Д-ускоритель, или монитор с цастотой обновления 200Гц, супер принтер и тд.
  • Нужно определиться со степенью локализации производства, на каком уровне мы можем остановиться. Одно дело спроектировать кристалл как Fabless производитель, другое дело иметь свою фабрику по производству кристаллов, третье дело производить своё оборудование для фабрик, а так же к примеру кремниевые пластины. То же самое касается всей рассыпухи на плате, свои резисторы, конденсаторы, катушки, микросхемы, источники питания, ПЛИС.

Насколько я могу судить - у нас государство сконцентрировалось на Fabless стратегии развития, с параллельными зачатками наладки своей фабрики( Ангстрем, Зеленоград, древняя линия AMD вот это всё). Поэтому, мы, вряд ли, увидим в ближайшее время полный набор отечественных компонентов. 

Сейчас для производства в основном мы сотрудничаем с Китайцами+Тайванем( производство кристаллов и печатных плат), и японцами( корпусирование кристаллов, сокеты, соединители ). 

Пайка компонентов на платы, как правило, производится уже у нас. Рассыпуха так же как правило Китай + Европа + Америкосия. 

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

Теперь самые популярные вопросы:

  1. Почему отечественные компьютеры такие дорогие? Даже если заводы будут наши, без реально массового производства цена будет очень кусачей, т.к. затраты на разработку очень высоки, изготовление 1000-10000 единиц, в сравнении с 1000000 всегда будет в разы дороже. Военная отбраковка кристаллов - либо полностью соответсвует ТЗ либо полностью брак, частично рабочие образцы не продают как 2х-ядерные(вместо 4х изначально), или с пониженными частотами( посмотрите линейки процессоров ADM \ Intel..., физически как правило там один и тот же кристалл, просто в одном случае дефектов мало и он может работать на высокой частоте, в другом случае наоборот, сбыть пытаются все произведённые кристаллы).
  2. Почему отечественный производитель берёт отсталые технологии производства? Потому что не умея собирать самокат - невозможно сделать космическую станцию. Технологии осваиваются постепенно, нужен опыт, с уменьшением технорм растёт цена ошибки разработчиков, увеличивается сложность разработки печатных плат, подложки процессора( простой пример, если ЦП рассчитанн на 100Вт на напряжение 3В(древний КМОП уровня 93-95 годов), то ток по плате будет 33А, много да?, а теперь мы взяли тонкую технорму на ней напряжение уже 1.5В(2005 год примерно, сейчас вообще напряение как правило уже меньше 1В), при тех же 100Вт, ток получится 66А, плату изготовить сложнее, требования к источнику питания растут, напряжение начинает заметно падать по пути от источника питания до ЦП, помехи вырастают), также чем выше тактовая частота тем больше помех, больше потребляемая мощность, сложнее проектировать устройства.
  3. Почему не сделают ЦП «под Винду»? Лицензию на архитектуру х86\х64 нам никогда не продадут, да и архитектура обросла кучей устаревшего дерьма которое надо поддерживать, а со своей архитектурой - можно каждую версию всё переделать, для раннего старта идеально. Плюс мы можем свои пожелания реализовывать без каких-либо согласований с вероятным противником.
  4. Почему на видео с Эльбрусом Doom 3 идет не так быстро, ведь ЦП зверь судя по параметрам? Потому что винда запускается в режиме двоичной трансляции - на ЦП крутится микро ось, которая на лету рекомпилирует то что должен исполнить виртуальный процессор под х86 в систему команд Эльбрус-а, ввиду существенных отличий архитектур, и систем команд - эффективность использования всей мощи Эльбруса заметно ниже, плюс пока есть много проблем с многопоточностью, поэтому одно ядро только работает, плюс ещё время на рекомпиляцию( там конечно есть кеш скомпилированных кусков кода, но иногда видны фризы - это когда внезапно кончился код ).
  5. Почему Эльбрус сделанный Ангстремом Микроном заметно медленнее, чем Эльбрус сделанный на китайской фабрике, по той же технологии? Библиотеки примитивов из которых собирают кристалл( в основном блочная память, кеши, физические уровни интерфейсов). Или вы думаете из кристалла торчит помехозащищённые данные которые только в карман переложи, и фабрика вам и PCI-E и USB и любой другой интерфейс\шину напечатает забесплатно? Многие вещи как правило на каждую технологию изготовления свои, и ты либо покупаешь под конкретный завод с конкретной технологией, либо пишешь сам. Насколько я помню, при покупке Микроном оборудования как раз на этом и встряли - оно есть работает, но без примитивов описанных в софте это просто дорогой лом. Ввиду малого опыта разработки и получилось, что всё медленнее чем у тех кто в теме уже давно.
  6. Почему частота Эльбруса такая низкая? Во-первых архитектурная особенность это параллелизм архитектуры, т.е. частота низкая зато количество обрабатываемых данных высокое, в среднем нужно умножать частоту на количество параллельно выполняемых команд за такт, и сравнивать уже эти значения. Во-вторых чтобы поднять частоту надо удлиннить конвеер, добавить кучу обвеса, усложнить реализацию, у МЦСТ на это ресурсов нет, поэтому и не делают. Плюс разрабатывать высокочастотные кристаллы заметно сложнее. Частота конечно растёт, но не значительно. Как правило разрабы обещают Х МГц, при проектировании, после всех рассчётов физических проектировщиков кристалл - получается 0.7 * Х. Ну а при испытаниях физического образца получают 0.5 * Х.

 

В комментариях можете задавать вопросы, я так же постараюсь ответить в будущем.

В планах у меня - написать пару не очень больших заметок, про разработку и производство электроники и кристаллов, чтобы народ понимал, что это такое.

Авторство: 
Авторская работа / переводика
Комментарий автора: 

Каюсь, описка вышла - эльбрусы делал не Ангстрем а Микрон, и не буржуйский а наш, поправил в тексте.

Комментарии

Аватар пользователя vutshim
vutshim(11 лет 7 месяцев)

Т.е. мы от технических и денежных проблем плавно перешли к ОСНОВНОЙ причине - нет желания иметь свой процессор. А тут уже не важны остальные причины.

Комментарий администрации:  
*** Уличен в жидких набросах ***
Аватар пользователя Фиолетовый
Фиолетовый(7 лет 8 месяцев)

Именно так !

Судя по финансированию, у России НЕТ желания иметь свой МАССОВЫЙ процессор.

А ценник 350.000руб за писи и 2-3млн за сервер не смутит только силовые структуры, при условии единичных покупок (1-100шт). А заменить ВСЕ серверы/писи на Эльбрусы финансово невозможно даже для силовиков. А низкая производительность в случае насильного отказа от Интел отбросит эти структуры на 10 лет назад.

Комментарий администрации:  
*** Отключен (Уличен в низкопробных набросах - https://aftershock.news/?q=node/811978) ***
Аватар пользователя Хмурый ослик
Хмурый ослик(8 лет 7 месяцев)

И охота народу такую фигню обсуждать?...

Комментарий администрации:  
*** отключен (систематические манипуляции и набросы) ***
Аватар пользователя pashich
pashich(6 лет 10 месяцев)

Как там, защищённый режим где-то используется?

Аватар пользователя ivacbka
ivacbka(8 лет 1 месяц)

Всегда по умолчанию как только прошла инициализация конфига в буте. Возможно его выключают в режиме двоичной трансляции( не помню точно ).

Аватар пользователя pashich
pashich(6 лет 10 месяцев)

Я про тэгированные данные и указатели, был такой режим в Е2К, когда программная система делится на несколько модулей в одном виртуальном (физическом) прострастве и доступ к ресурсам одного из них осуществляется по тэгированным указателям и меткам процедур, сами тэгированные указатели может породить либо модуль-владелец, либо ОС. Мне интересно нашли ли этому какое-то реальное применение, если это, конечно, не секрет.

Аватар пользователя ivacbka
ivacbka(8 лет 1 месяц)

Я про это и сказал - используется по умолчанию всегда.

Аватар пользователя NikSR
NikSR(8 лет 3 месяца)

Кажется, не тот путь. Разгильдяйство программистов заставляет бездумно растить производительность процессоров. В молодости давелось разрабатывать командную радиолинию для особо ответственных применений. При тактовой частоте  32 кГц(!) и программной памяти 256 команд реализовали алгоритм оптимального приема и минимизации энергопотребления. Ушло примерно 180 команд, программу писали на PIC ASM. Другая задача- управление приемником, синтез сетки, загрузка частотного синтезатора, общение с LCD многострочным индикатором. Хватило стандартной памяти PIC84. Если транслировать уровень тех задач на современные камни с тактовыми частотами и возможностями, то их потенциал сверхизбыточен по частоте на  5 порядков и в квадрате по разрядности.  Если использовать эти мощности под Фурье анализ или согласованного приема сигналов, то не стало бы проблем со "стеллс" объектами или непрехватываемой радиосвязью. 
 Как резюме, хочу сообщить, что можно без особого успеха наращивать мощность работы процессоров на чужой системе, но без своей собственной это будет игрой в догонялки. Камень на 3.2 ГГц с 64 бит на настоящее время тянет прикладную задачу немного более продуктивно, чем 32 МГц  32 бит (DOS 1995 год) в части WOLF2. 

Аватар пользователя vutshim
vutshim(11 лет 7 месяцев)

Согласен с вами, сам начинал еще на 8 битах и програмируемых калькуляторах :)

Но, есть простой закон - скорость разработки обратно пропорциональна количеству используемых вычеслительных ресурсов. Можно потратить 1 мес на то, что бы оптимизировать модуль для 6кб ОЗУ, а можно это сделать за 3 дня используя 6Мб ОЗУ. Да и сложность системы с тех пор несколько возрасли. 

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

Комментарий администрации:  
*** Уличен в жидких набросах ***
Аватар пользователя Weard
Weard(6 лет 6 месяцев)

Приветствую, коллега )) Я тоже начинал с Б3-34 ))

Мою игровую программу даже в "технике молодежи" за 89й год печатали.. Времена были...

Комментарий администрации:  
*** Отключен (лидер бан-рейтинга, провокатор) ***
Аватар пользователя vutshim
vutshim(11 лет 7 месяцев)

Мою игровую программу даже в "технике молодежи" за 89й год печатали.. Времена были..

Супер! Б3-34 ,это не мажорный 61й , до сих пор в столе лежит :) правда уже не программирую на нем. Эх, Посадка на Луну, Путь к Земле на Кон-Тики  - прямо эпопея в нескольких журналах Техники Молодежи издавалась :) 

Комментарий администрации:  
*** Уличен в жидких набросах ***
Скрытый комментарий Повелитель Ботов (без обсуждения)
Аватар пользователя Повелитель Ботов

Запись, растолкав других достойных претендентов, ворвалась в лидеры по читаемости. Сим повелеваю - внести запись в реестр самых читаемых за неделю.

Комментарий администрации:  
*** Это легальный, годный бот ***
Аватар пользователя titan83
titan83(7 лет 4 месяца)

процессоры-уессоры...

когда хотя бы микроконтроллеры-то будут? везде только atmel, microchip и stm.

а это немного более (в сотни раз) объемное направление, чем процессоры. и блеяния на тему "ну у нас же массовости не получается, бее" не пройдут.

Комментарий администрации:  
*** ***Вы бедны, глупы и наглы. Вы - идеальный россиянин! (с) ***
Аватар пользователя morbo
morbo(8 лет 3 месяца)

Совместимые с MCS-51 свои производятся - КР1816ВЕxx. А так, конечно, соглашусь. Рынок массовый, продвинутые техпроцессы не нужны, клепай себе своюи микроконтроллеры. Другое дело, что микроконтроллеры - это продукция не для конечного потребителя, а стало быть надо убедить нынешних производителей оборудования, уже использующих западные контроллеры, переделать всё под отечественные. Это дело не простое и вряд-ли кто-то возьмётся за него, если не будет очевидных преимуществ. В цене, например.

Аватар пользователя vutshim
vutshim(11 лет 7 месяцев)

1816 слабоват, тогда лучше уж смотреть на 

Комментарий администрации:  
*** Уличен в жидких набросах ***
Аватар пользователя progserega
progserega(11 лет 9 месяцев)

Вопрос немного в сторону:
Если мы делаем "своё", то почему бы не делать под системы уровня Plan9/Inferno? Т.е. это уже не линукс - это следующий "уровень", когда всё прозрачно, когда всё есть файл - любой удалённый ресурс, любое окошко программы, любая железяка, будь она хоть на другой стороне земного шара. Экономия на разработке, на сложности ПО (уход от великов тысяч протоколов/авторизации).

Если мы начинаем практически "с нуля" - можно ведь начать сразу, шагнув ЗА велосипедостроение виртуализации (иглка в яйце, яйцо в утке - в то время, когда нужно ПО, которое будет уметь работать на кластере, без прослоек в виде некластерных ОС) и веба с его веб-сокетами, печоницами в виде браузера, разорванной посередине программы архитектуры (когда логика считается на сервере на php/ruby/java, а интерфейс рисуется на js+ajax-вызовы через сеть), а ещё ведь есть flash.... В случае же plan9 - мы приходим к сервисам, которые просто работают на сервере, а у нас берут ввод/вывод. Всё через единый протокол 9P.

Аватар пользователя monk
monk(12 лет 2 месяца)

Потому же. почему взлетел Linux, а не Plan 9. Если оставлять клиент-серверную архитектуру, но прикручивать к ней 9P, то получим тот же HTTP+REST только в профиль. И с необходимостью переписывать тонны библиотек, успешно работающих с AJAX/JSON. Да и тот же flash: что вместо него предложишь в Plan 9 для мультимедии?

А кластерное ПО обязано знать про кластер. Иначе абстракция файла очень сильно течёт. Например, mmap на локальный файл позволяет нескольким процессам на самом деле работать через общую память. А на сетевой может даже блокировать выполнение при каждой записи до окончания синхронизации с файлом. Пропадание открытого локального файла -- крайне редкая аварийная ситуация, временный обрыв связи между узлами -- нормальная ситуация. И т. д.

Аватар пользователя progserega
progserega(11 лет 9 месяцев)

Если оставлять клиент-серверную архитектуру, но прикручивать к ней 9P, то получим тот же HTTP+REST только в профиль.

Но значительно проще для программиста и легче для системы.  Убирается вал протоколов/прослоек. Весь этот странный и дико тяжеловесный слоёный пирог веб-стека (слишком уж нагородили - множество устаревших протоколов и отсутствие единой прозрачной системы авторизации и это всё не сокрыто от разработчика приложения и каждый раз нужно это реализовывать и обрабатывать). В результате упростится написание ПО, его сложность, его тяжеловесность - экономия ресурсов и времени.
 

И с необходимостью переписывать тонны библиотек, успешно работающих с AJAX/JSON. Да и тот же flash: что вместо него предложишь в Plan 9 для мультимедии?

А оно и не нужно будет. Приложение работает на сервере, ты посылаешь туда ввод, оттуда приходит графика - т.е. просто вывод серверного приложения в виде окошка перенаправляешь на локальное окно. Вопрос флеша - это вопрос эффективности пересылки и сжатия графики в 9P-протоколе. Ведь по факту, что такое веб - это возможность запустить ПО на удалённом сервере, которое выдаст тебе на локальное окно индивидуальный для тебя результат. Просто архитектурно это приложение размазано по сети (часть логики на сервере, часть локально).

А кластерное ПО обязано знать про кластер. Иначе абстракция файла очень сильно течёт. Например, mmap на локальный файл позволяет нескольким процессам на самом деле работать через общую память. А на сетевой может даже блокировать выполнение при каждой записи до окончания синхронизации с файлом. Пропадание открытого локального файла -- крайне редкая аварийная ситуация, временный обрыв связи между узлами -- нормальная ситуация. И т. д.

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

Аватар пользователя monk
monk(12 лет 2 месяца)

отсутствие единой прозрачной системы авторизации и это всё не сокрыто от разработчика приложения и каждый раз нужно это реализовывать и обрабатывать

Давно написаны библиотеки, в которых всё реализовано. OAuth, SOAP, ...

А оно и не нужно будет. Приложение работает на сервере, ты посылаешь туда ввод, оттуда приходит графика - т.е. просто вывод серверного приложения в виде окошка перенаправляешь на локальное окно.

Это X протокол или в лучшем случае RDP. Тормозить для анимации будет ужасно. 

И самое главное, 9P протокол для всего этого просто не предназначен. Чтобы на open/read/write/sync сделать нормальные обработчики событий придётся воротить не меньше, чем на HTTP. При том, что на HTTP это уже сделано. Более того, на HTTP я могу передавать метаданные. Как в 9P указать, что кодировка файла koi8 и он сжать gzip'ом? Или записать несколько файлов одной транзакцией (или все записались, или все остались неизменными)? Вообще для сети лучше системы передачи сообщений (типа Erlang), а не всё есть файл.

 

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

Спорный вопрос. Сейчас технологии уже почти по кругу ходят. Вместо старой статической линковки и ОС теперь виртуализация. Вместо старого RPC теперь WebSocket. На момент начала перехода останемся без программного обеспечения. А просмотрщик для интернета всё равно делать придётся. 

Аватар пользователя progserega
progserega(11 лет 9 месяцев)

Давно написаны библиотеки, в которых всё реализовано. OAuth, SOAP, ...

Конечно это всё есть. Но я говорил про "скрыто от разработчика". У нас есть тучи библиотек, есть тучи протоколов (http,ftp,rdp,nfs,smb,iscsi и ещё ворох), стандарты (SOAP,RESP) и всё это надо подключать, поддерживать, реализовывать, разбираться в API и стандартах, читать RFC и т.д. и т.п. Чтобы вот так просто взять и поработать с удалённой веб-камерой, подключённой к удалённому серверу - это надо тот ещё огород городить. А ещё бы шифрование прикрутить, ssl-сертификаты сгенерировать. Безусловно всё это можно, безусловно всё решаемо, но я не про невозможность, а про то, что операционная система, которая должна предоставлять простые интерфейсы для работы с оборудованием - сейчас делает это из рук вон плохо. Слишком много костылей и подпорок. И, зачастую, чтобы реализовать простую вещь (например безопасно получать данные от соседнего сервера) - нужно тратить время на разбирательства с ворохом частностей (поднять веб-сервер, ssl, авторизацию, реализовать RESP/SOAP-интерфейс, разобраться с какой-нибудь http-библиотекой-обёрткой для какого либо языка на клиентской стороне... Когда проще было бы этим вообще не заниматься, а открыть и прочитать файл, который экспортируется на удалённом сервере.

Это X протокол или в лучшем случае RDP. Тормозить для анимации будет ужасно. 

Может быть стоит и минимизировать эту анимацию. А что-то, может быть вообще вынести на уровень приложения, когда пользователь просто импортирует /remote/bin  каталог с сервера с программами именами "news" и т.п. При хорошей изоляции приложений - можно будет доверять этому подходу не менее, чем JS-скриптам на сайтах. В любом случае это упростит систему в разы, сделает её проще и лаконичнее и красивее. В случае удалённого запуска, может быть будет уместна виртуальная машина, что есть в OS Inferno.

Вместо старой статической линковки и ОС теперь виртуализация.

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

На момент начала перехода останемся без программного обеспечения. А просмотрщик для интернета всё равно делать придётся. 

На момент перехода нам линукс никто не запретит. Но работать на перспективу, мне думается разумным. Для поддержки старого придётся и драйвера для всех протоколов написать в ОС, чтобы к http, ft, smb и т.п. можно было бы обращаться через файловую систему. Но написав один раз, встроив прозрачно в систему с единым и простым как гвоздь файловым интерфейсом - облегчить взаимодействие с этим ворохом интерфейсов раз и навсегда.
 

Сейчас технологии уже почти по кругу ходят.

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

Аватар пользователя monk
monk(12 лет 2 месяца)

У нас есть тучи библиотек, есть тучи протоколов (http,ftp,rdp,nfs,smb,iscsi и ещё ворох), стандарты (SOAP,RESP) и всё это надо подключать, поддерживать, реализовывать, разбираться в API и стандартах, читать RFC и т.д

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

Чтобы вот так просто взять и поработать с удалённой веб-камерой, подключённой к удалённому серверу - это надо тот ещё огород городить.

 ffmpeg на удалённом компьютере запускается также как и на локальном. Или в смысле "поработать"?

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

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

Но написав один раз, встроив прозрачно в систему с единым и простым как гвоздь файловым интерфейсом

Не получится с простым. Можешь для упражнения придумать протокол виртуальной FS для HTTPS, чтобы умел не меньше, чем curl. Мне в голову приходит только вызов mount на каждый запрос и umount после окончания чтения результата запроса.

Всё-таки Plan9 - это следующая итерация успешной модели UNIX-а от тех же авторов.

Всё, что было там полезного (UTF8, procfs, FUSE, sshfs, ...) в Linux уже перетащили. А возвращаться к делению компьютеров на процессорный сервер, файловый сервер и терминал в наше время уже неактуально.

Аватар пользователя izn
izn(8 лет 2 месяца)

сколько фпс в ведьмаке выдает?

Страницы