LINUX.ORG.RU
ФорумTalks

ОС и сайты будущего [моё ИМХО]

 ,


0

1

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

Disclaimer: автор данного поста весьма плохо разбирается в теории, не говоря уж о практике

На мой субъективный взгляд, развитие современных операционных систем заходит в тупик. Всё сильнее прослеживается тенденция превращения системы в пускалку браузера, в котором уже выполняется большинство повседневных задач. Облачные сервисы и социальные сети прочно вошли в обиход многих пользователей, и всё это весьма плохо интегрировано в ОС, оставаясь где-то внутри браузера.
С другой стороны можно наблюдать мобильные ОС, где на замену сайтам созданы клиенты к тем же социальным сетям и облачным хранилищам, и эти клиенты уже куда удобнее в использовании (как минимум лучшей интеграцией в ОС).
Разве это не замечательно — заменить сайты на локальные приложения с обменом данными с серверами? Для чего же насиловать JS и HTML, изобретая всё новые костыли и всё сильнее удаляясь от натива, получив взамен дизайн «кто во что горазд» и страшные тормоза?

Добро пожаловать в моё видение будущего ОС и веба:

  • Никаких сайтов. Операционная система пускает браузер. Браузер запускает приложения и сервисы, максимально абстрагированные от внутреннего устройства ОС, используя API самого браузера.
  • Сам браузер — это связка оконного менеджера, тулкита и стандартного интерфейса (типа стартовой страницы).
  • Интерфейс приложений пишется на декларативном языке, логика на скриптовом, библиотеки, требующие оптимизации, (в идеале) компилируются в язык типа LLVM, который транслировался бы в бинарный код уже на машине клиента; если такое невозможно, то распространяются в виде бинарных пакетов для конкретных платформ, на которых запускается браузер.
  • Приложение может работать в двух режимах: удалённом и локальном. В удалённом режиме приложение хранится на сервере, клиент получает файл интерфейса, браузер его отрисовывает, взаимодействие между интерфейсом и библиотеками происходит через какой-нибудь WebSocket. Как только мы хотим загрузить приложение себе на локалхост, чтобы можно было работать с ним в оффлайне, браузер получает и хранит у себя связку интерфейса и логики приложения, с определённой периодичностью опрашивая сервер на наличие новой версии.

Важный момент — максимальная абстракция приложений в браузере от ОС при сильной привязке к архитектуре браузера. Т.е. в идеале приложения одинаково работают хоть под линуксом, хоть под виндой, просто внутри браузера, за которым не видно остальной ОС, который по сути своей подменял бы графический интерфейс той ОС, которая его запустила (если таковой вообще был).
Язык написания интерфейсов должен быть абстрагирован от пикселей в пользу физических величин типа тех же сантиметров. При этом создающий дизайн должен сам учитывать пропорции экрана, размеры и банальные интерфейсы взаимодействия пользователя и системы (будь то тачскрин, трекпад, мышка, клавиатура или даже в отдельных случаях геймад — учитывать надо как можно большее количество вариантов).
Сам браузер должен быть хорошо масштабируем под самые разные устройства. Для упрощения масштабирования приложений крайне желательно экспортировать меню приложения в браузер, чтобы он сам выбирал, как и где его отрисовывать в зависимости от устройства.
Теперь об облаках и том, каким должен быть браузер:

  • Браузер должен быть своеобразным провайдером различных сервисов. Будь то социалки типа вк и твиттера, будь то облачные хранилища типа Google Drive или Dropbox, будь то даже магазины музыки типа iTunes или игр типа Steam. Всё, что должен делать браузер — это быть провайдером ко всем этим сервисам, позволяя этим сервисам сильно интегрироваться в среду.
  • Что я понимаю под интеграцией? Положим, у вас есть несколько устройств, залогиненных под одним мета-аккаунтом. Предположим, вы выбрали некий сервис для хранения файлов в облаке. Тогда, как только вы добавите файл на одном устройстве, он сразу появится на другом. Разумеется, поведение должно быть настраиваемым. Возможно, вы не хотите автозагрузки файла, возможно, даже идея автоматической синхронизации всего вас не обрадует. Т.е. вы сами должны выбрать, что и как синхронизировать, главное — это максимальная абстракция от самих сервисов. Просто прокликал, в каких сервисах и на каких устройствах держать файлы и всё, они уже там.
  • Подобным же образом должны работать социальные сети. Общий фид новостей, фотографии изо всех социалок в одном месте, даже фотографии друзей рядом. Список мета-контактов с выбором, каким образом с человеком связаться, вместо тысяч разных клиентов со своим поведением.
  • Максимально возможная абстракция от файловой системы. Метки вместо каталогов.
  • Поисковик можно рассматривать уже с другой стороны. Представьте себе смесь маркета с обычным поиском. Т.е. контент будет искаться по сервисам, представленным в магазине, открываться будет в соответствующих приложениях. Разумеется, должна быть возможность иметь несколько магазинов (поисковиков), но крайне желательно наличие при этом центрального типа Google Play.
  • Сами приложения должны открываться как сайты нынче. Т.е. в магазине банально хранятся ссылки и отзывы к ним. Эдакий расширенный индекс сайтов. При отсутствии приложения в магазине, оно должно открываться банальным набором его адреса в адресной строке. А установленные приложения — это по сути закладки. Если приложения совсем-совсем нет в сети, то оно банально перетаскивается в систему примерно так же, как оно сделано в макоси, разве что в нашем случае перетащить нужно просто на локальную систему, а не конкретно в приложения, ибо браузер разберётся, куда класть контент.
  • И, разумеется, должна быть поддержка тех, кто боится слежки. Возможность синхронизации через домашний сервер или объединением в сеть нескольких устройств с одним ключом. Как быть с покупкой приложений в таких случаях — спорный вопрос.

Из всего этого можно получить систему, ведущую себя примерно одинаково что на телефонах, что на планшетах, что на ноутах и ПК.

Как-то так. Идея не претендует всем понравиться, сама она действительно сильно напоминает какую-нибудь ChromeOS, разве что в основе её лежит идея децентрализации сервисов, а не наоборот. Хотелось бы заняться реализацией всего этого, да пока знаний не хватает, сижу вот, читаю Real World Haskell.

Deleted

Ответ на: комментарий от Deleted

Вкратце — в жопу сайты, в жопу JS и WebGL, даёшь локальные клиенты, интеграции и синхронизации всего и вся.


Поздравляю , Кевин, ты только что изобрел Виндовс8.
Как это ты догадался, через джва года то?

Deleted
()
Ответ на: комментарий от mono

От перестановки языков с HTML на QML и с JS на Python ничего качественно не поменяется.

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

Deleted
()
Ответ на: комментарий от Deleted

только что изобрел Виндовс8.

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

Deleted
()
Ответ на: комментарий от Deleted

Почитай обзоры и послушай что Балмер говорил.
именно приложения МодернУИ построены по такому принципу. :-)
Изоляции и синхронизации.

Другой реализации, в промышленных масштабах, уже оттестированной, на этой Планете нет.

Deleted
()
Ответ на: комментарий от Deleted

Всё-таки нативно исполняющийся код — он быстрее

Что Python, что JS, оба языка одинаково нейтивны.

недаром же NaCl начали городить в хроме.

Это совсем не аргумент, NaCl до сих пор выключен по дефолту, за столько то времени, это говорит о том, что гугл сам не знает что с ним делать.

mono ★★★★★
()
Ответ на: комментарий от Deleted

именно приложения МодернУИ построены по такому принципу

А почему ж так убого-то? Где описанная мною интеграция с социальными сетями? Почему все приложения в магазине, и их надо качать, и иногда они весьма внушительных размеров?

Deleted
()
Ответ на: комментарий от mono

Что Python, что JS, оба языка одинаково нейтивны.

Python может вызывать сишный код, например. JS так может?

Это совсем не аргумент, NaCl до сих пор выключен по дефолту, за столько то времени, это говорит о том, что гугл сам не знает что с ним делать.

Потому что не с той стороны подошли к вопросу :)

Deleted
()
Ответ на: комментарий от Deleted

Python может вызывать сишный код, например. JS так может?

Это не свойство языка, а свойство реализации. JS в браузере так не может из-за вопросов безопасности, а не потому что это невозможно, в принципе.

mono ★★★★★
()
Ответ на: комментарий от mono

Это не свойство языка, а свойство реализации. JS в браузере так не может из-за вопросов безопасности, а не потому что это невозможно, в принципе.

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

Deleted
()
Ответ на: комментарий от Deleted

А без этого веб вечно будет изолированный и, как следствие, прожорливый и медленный.

Логическая цепочка аналогична «Зачем мне холодильник, если я не курю.»

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

Ты декларируешь проблему «веб тормозной и прожерливый», потом у тебя возникает мысль, которая автоматически считается истиной «во всем виноваты html + js», и из этого всего ты делаешь вывод, если заменить это на QML + Python, все автоматически будет хорошо.

Начинать нужно не с выбора инструментов для решения, а с понимания причин проблемы, которого у тебя нет даже на самом высоком уровне.

mono ★★★★★
()
Ответ на: комментарий от Deleted

Инферно может запускаться как в нативном режиме, так и в качестве гостевой системы поверх план9, линукса и винды. Так что с драйверами проблем нет.

harm
()
Ответ на: комментарий от mono

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

Deleted
()

Глобальные конструкции годны только для интертейтмента etc

В молодые годы была у меня дискуссия с чуваком, предлагавшем в качестве идеи что-то подобное твоей. Подробностей прямо счас не вспомню, дело было давнее. Речь шла о распределённой безсерверной гибкой модели управления информационными процессами. Я тогда был повёрнут на секьюрности и категорически не принимал «глобальщину», да ещё и гибкую. Считал, что «большой шкаф громко падает». Знаний у меня тогда не было никаких, только предыдущий жизненный опыт =)
Чувак набирал команду для реализации прожэкта. Срослось или нет, я не знаю.

Deleted
()
Последнее исправление: rht (всего исправлений: 1)
Ответ на: комментарий от Deleted

Дело в кривых руках и засевших в голову стереотипах. Хороших и быстрых веб-приложений полно, и WebGL, сам по себе, работает очень быстро. Интеграции различной тоже выше крыши.

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

mono ★★★★★
()
Ответ на: комментарий от Deleted

Нет, ты серьёзно?

Да.

Всё это тормозное нечто

У большинства не тормозит.

с огромным расходом памяти по пустякам

Этот фактор пользователей не интересует.

весь этот аляповатый интерфейс

Он сейчас в моде.

и полное отсутствие интеграции в систему

Неправда. С каждым годом интеграция улучшается. Я могу на заливалку файлов на сайте перетаскивать файлы с файлового менеджера, например. Скачивать файлы на жёсткий диск. Запускать программы по URL (например torrent при щелчке по magnet link). Какого рода интеграция ещё нужна?

Legioner ★★★★★
()
Ответ на: комментарий от Deleted

Неправильно понимаете. На базе обычных дивов легко делается довольно производительный 2d тулкит. А на javascript можно писать довольно быстрый компонентный код. Просто другое дело, что люди так обычно не поступают, и используют веб как веб. А вот что важно, так это то, что подходящие языки эти же люди будут использовать также, как веб, а значит будет тормозить. Если вы возьмёте наваяете простыню объектов и будете её ворочить, без разбивания хотя бы на группы, то тормозить будет даже сишечка.

ixrws ★★★
()
Ответ на: комментарий от Deleted

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

Sociopsih ★☆
()
Ответ на: комментарий от mono

Хороших и быстрых веб-приложений полно, и WebGL, сам по себе, работает очень быстро. Интеграции различной тоже выше крыши.

Примеры перечисленного. Желательно, чтобы были хотя бы сопоставимы с десктопными аналогами.

Deleted
()
Ответ на: комментарий от Legioner

Этот фактор пользователей не интересует.

Ровно до тех пор, пока память не заканчивается. А она таки может.

Я могу на заливалку файлов на сайте перетаскивать файлы с файлового менеджера, например. Скачивать файлы на жёсткий диск. Запускать программы по URL (например torrent при щелчке по magnet link).

Вот это интеграция, дааа.

Какого рода интеграция ещё нужна?

Работа с облачной файловой системой как с локальной, отсутствие явной разницы между облаком и локалхостом, фотки из соцсетей вместе с остальными фотками, общий фид новостей, мета-контакты (есть на андроиде, но никак не синхронизируется). Как пример.

Deleted
()
Ответ на: комментарий от ixrws

Может, есть всё-таки причина, почему на js так криво пишут? Или прям вот большинство веб-разработчиков — идиоты, а js не виноват?
Касательно HTML вообще сказка, городить костыли для браузеров, не умеющих в стандарт. А потом эти костыли выносят в js, а потом это всё начинает тормозить…

Deleted
()
Ответ на: комментарий от Sociopsih

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

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

Deleted
()
Ответ на: комментарий от Deleted

Примеры перечисленного.

Google Docs.

Желательно, чтобы были хотя бы сопоставимы с десктопными аналогами.

Ты пытаешься совместить несовместимое. Десктопные приложения создаются под конкретную платформу с максимальным использованием возможностей, которые предоставляет данная платформа. У web-приложений задача иная - работать везде, максимально абстрагируясь от кокретной платформы.

Скрещивать ужа с ежом конечно можно, но цель этих действий не очень понятна, на двух стульях все-равно не усидишь.

mono ★★★★★
()
Ответ на: комментарий от Deleted

js достаточно быстрый язык, если его сравнивать с анлогичными, а некоторых и гораздо быстрее, скажем перлов и питонов. Быстрее разве что lua. Что до кривизны,то почитайте всякий интерпрайзный код на java, да и вообще, поинтересуйтесь как пишутся проекты чисто под сдачу, за бабки, тут и вскроются причины быдлокода, скоростного писательства и наплевательства на будущее. Про костыли всё не так просто. Да, веб уже давно состоит из множества стандартов, как ласкутное одеяло, а html это как много разных подходов в одной бочке. Но то, что учитывать эти разности обязательно начинать тормозить - это не факт. Есть и довольно быстрые реализации svg для старых браузеров или для ie. Есть и движки 2д графики поверх дивов, которые резво работают. И куча всего в таком духе. А вот почему это не используется, почему люди по прежнему ваяют портянки жуткого кода для написания формочек, вместо использования какого-нибудь amplesdk? Думаете дав им в руки только QtQuick всё изменится? Я вот думаю нет, думаю что и на нём они напишут свой html с костылями и будут весь код писать в один файл.

ixrws ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.