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

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

С вебкамерами и прочим -- это уже сложнее. Интернет вещей ещё не вовсю шагает по планете, но вроде как это всё не за горами.

> 2. Сложность разработки распределённых и удалённого
> ПО. Современный веб-стек - это "боль". Фреймвёрки, тормоза,
> жрущие раму "виртуальные машины" в виде браузеров для запуска
> удалённого кода (js). Разорванные по-середине приложения, часть
> кода которых выполняется в браузере, часть на сервере,
> взаимодействующее всё это через рыхлый http. По идее всё
> это (только сделать по-человечески) нужно спрятать в протокол ОС,
> а наверх отдать простые интерфейсы.

Нет. Виртуальные машины -- это не так уж и плохо. То, что некоторые из них (типа js) сконструированы однопоточными и тормознутыми, а некоторые (типа java) не в себя жрущими -- не доказывает, что это так уж плохо. И они, тем не менее, в рынок-то идеально вписались.

Что часть выполняется в браузере, а часть на сервере -- это вполне нормальный подход в плане оптимизации использования вычислительных ресурсов. Безусловно, всё можно выполнять на сервере. Просто не у всех есть деньги на такой сервер. А каковы претензии к http? Этот протокол лёгок в реализации и дебаге, и если уж совсем честно, это по сути тот же email, только снабжённый всякой веб-специфичной семантикой.

>[оверквотинг удален]
> сигналы приложению + сокеты, если приложение таки решило их
> создавать и слушать (но что посылать в эти сокеты и как - всё на
> откуп разработчикам). В винде - это монструозные com-объекты, с
> которыми может работать только винда. А по-хорошему, опять же
> спрятать это в ОС, чтобы приложение экспортировало себя через
> файловые интерфейсы во вне с лёгким доступом к ним как со стороны
> ПО так и людей (из консоли). Для серверного ПО это частично
> реализуется с помощью микросервисов и REST/SOAP. Но по-хорошему
> это должно быть единообразным и простым и встроенным в ОС как
> естественная парадигма взаимодействия между ПО.

Ну вообще-то, в виде файлухи это уже есть. Это plan9, это /dev/tcp/<hostname>/<port>... Естественно, юзерспейсный протокол придётся прописать. Это не такая уж большая проблема. Проблема, имхо, в том, что нынче расплодилось "типа программистов", для которых lex/yacc -- это страшные слова.

>[оверквотинг удален]
> спрятать от ПО - пусть ОС этим занимается, предоставляя ПО и
> пользователю - единую безопасную среду, когда можно общаться с
> удалёнными ресурсами так, как буд-то они находятся/запущены
> локально - будь то место на диске в автомобильной
> мультимедия-системе или его же gps-приёмник, веб-камера телефона
> или gsm-модем его же. Или же вычислительные мощности удалённого
> кластера или же запущенное в интернете приложение, которе
> экспортирует себя и свои сервисы в виде файловой системы, которую
> прозрачно и безопасно можно включить в своё вычислительное
> пространство.

Это ж просто повторение п.3, просто иными словами. Разве что, мне всё же надо добавить тут, что от того, что вы перенесёте http в из библиотеки в ОС, на какой-нибудь новый сетевой уровень между 3м и 4м -- от этого сложность его меньше не станет. Свести всё к примитиву "подключись и работай" не получится.

>[оверквотинг удален]
> взгляд - достойная задача для создания новой ОС. А то, что делают
> зачастую - это перепевание одной и той же песни на новый лад с
> новым логотипом производителя. Хотя по большому счёту всё
> вышеназванное уже реализовано в Plan9/PlanB/Inferno. Но вот
> только почему-то даже при наличии ситуации, когда эти проблемы
> увидели, решили и реализовали это решение в коде - всё ещё есть
> люди и корпорации, которые не то что пытаются решить эти проблемы
> заново (это бы ничего), но не видят их и решают проблемы прошлого
> века. Проблемы времён создания Linux/Minix/Unix/NT. Проблемы
> прошлого века решают теми же концепциями из прошлого века.

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

А что нужно сейчас? Ну вот Хуавею сейчас нужна ОС, которая позволит Китаю и дальше ссориться с США. И Китай с радостью оплатит её создание. Разве что-то не так? Все живут, все развиваются, всё идёт по плану. Жаль, конечно, что не по девятому, но по плану. ))