LINUX.ORG.RU
ФорумTalks

Перестать натягивать сову на глобус: ваши идеи?

 , , , ,


0

4

Современный браузер - это миллионы строк кода.

  • Прорисовка HTML / CSS и выполнение JS - лишь очень малая часть того, что браузер сегодня умеет. Он так же должен быть:
    • Аудио и видео плеером, проигрывателем шифрованного контента, просмотрщиком изображений, базой данных, p2p и p2s транспортом, библиотекой для: работы с VR девайсами, геймпадами / определения геолокации, положения девайса, его движения / нескольких механизмов аутентификации / системы оплаты и десятков других вещей, которые в лучшем случае должны быть фичами application layer / частями 3rd party библиотек.
    • Что хуже, количество фич продолжает расти. Не исключаю, что браузеростроители намеренно усложняют стандарт, чтобы не вылететь с браузеростроительного бизнеса.
  • Помимо этого, результатом превращения просмотрщика документов в платформу для приложений является огромное количество подпорок для исправления уязвимостей того или иного рода.
  • А добавление поддержки каждого нового типа устройства в браузер - это таки годы обсуждений и ещё столько же запила.

При этом есть и положительные стороны:

  • Compile once, run everywhere.
  • Каждое приложение имеет адрес. Т.е. может быть найдено даже без включения в разного рода «каталоги» (app store'ы).
  • Относительно малый размер и отсутствие необходимости скачивать приложение целиком, чтобы решить - пользоваться или нет.
  • Возможность поделиться результатом работы приложения (например, ссылку на твит можно опубликовать в лицокниге).
  • Есть зачатки контроля используемых девайсов, звука и т.д. Далеко от идеала, но сказать «не используй мой микрофон / камеру, не сри в мою localDB, заткни свой звук» можно.

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

Ключевые слова: JVM, WASM (может выполняться по мере загрузки и оптимизирован под минимальный размер), CIL, Snap, Flatpack (имеет гибкую настройку доступа к устройствам и сети, но использует Linux специфичные фичи), WebGL.

Перемещено leave из development



Последнее исправление: RedJohn (всего исправлений: 6)

Docker + CRIU

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

ugoday ★★★★★
()

Ты очень заманчиво обрисовал светлое будущее, но я не понял, что конкретно ты хочешь?

Серьезно, выглядит твоя идея (или зачатки идеи) интересно, может ты в самом деле пророк. Так что давай излагай, интересно обсудить.

I-Love-Microsoft ★★★★★
()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)

Идеи - Выкинуть к чертям все и вернуть браузер к состоянию HTML парсера.

Deleted
()

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

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

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

Для эстетики и индивидуального оформления плеера. Всё во славу свистелок и перделок, как всегда. Хомячки их очень любят и жить без них не могут.

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

На ноуте работает НТ 4.0. Ну, мне нужно, ноут хоть и старый, но вполне работоспособный. А софт написан в годы могущества Win2k, и переписывать его лень. Работает, и нормально.

Показываю ноут хомяку. Вижу недовольство. Недостаточно гламурный интерфейс, видите ли =)

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

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

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

Я уже видел мелких хомячков, которые хрюшу не застали. Так им хрюша не удобна, подавай семерочку или десяточку.

peregrine ★★★★★
()
Ответ на: Docker + CRIU от ugoday

Docker - просто обёртка над несколькими фичами ядра Linux. Чтобы оно работало в Windows используется гипервизор. А в Android'е, как мне подсказывает DuckDuckGo, всё ещё хуже ввиду отсутствия необходимых модулей (впрочем, результаты старые, может что-то поменялось?). В любом случае, Flatpack всяко лучше в качестве песочницы для недоверенного кода (он для этого создавался, по крайней мере).

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

1. Ну, что ж, пользователям маргинальных и устарелых ОС придётся пострадать. А андроид в будущем и поправить можно.

2. Учитывая тенденции, поднять виртуалку в гипервизоре будет и быстрее, и менее ресурсоёмко, чем пытаться эмулировать гипервизор и операционную систему в браузере.

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

Нахрена делать машину с колёсами, вдруг мы на эскалаторе поедем

zolden ★★★★★
()

Перестать натягивать сову на глобус: ваши идеи?

Писать нормальный натив и уже добавочно разработать несколько стандартов API для всех перечисленных задач. Пусть будут реализации разные и на разных платформах и будут иметь свой интерфейс, но каждый будет иметь дополнительно реализацию стандартного API который гарантированно реализован/эмулирован.

И да Compile once, run everywhere подходит только для мелких приложух, большие программы весящие под 100/200 метров тут уже не катят, увольте, не хочу качать по ссылке с фейскниг на посмотреть приложения.

Пишите нормальный нативный софт и не страдайте хернёй, да, многое уже можно в вебе, но границы иметь то надо

Dron ★★★★★
()

Проблема в том, что это самый простой способ клепать «приложения». Поэтому electron и взлетел. Ибо просто работает, пусть и медленно. Ну и гигантская экосистема в виде JS. При этом, это чудо на смеси C++ и JS умудряется работать быстрее чем Java, что уже само по себе забавно.

Нужна нормальная GUI либа, которая будет легко встраиваться в другие языки. Но на данный момент такой нет.

Есть конечно Qt, но там С++, а значит никто к нему даже прикасаться не будет. Есть ещё QML, но он как-то не взлетел + кривой. При этом Qt Project забили на десктоп и ушли в embedded.

В общем всё плохо.

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

Проблема в том, что это самый простой способ клепать «приложения». Поэтому electron и взлетел.

Так в обсуждаемой альтернативе браузеру в принципе всё так же можно будет подцепить библиотеку отрисовывающую html / css и делать интерфейс с помощью неё, если это действительно удобно. Просто платформа не обязана будет знать обо всех стандартах последних тегов, только как запускать и изолировать приложения.

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

Если я правильно понял, то play market аналог?

Не исключено. Дитя play market и браузера. Часть генов от папы. А децентрализованность, только правильная от другого папы.

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

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

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

Протокол файловой системы? Оно разве решает проблему запуска недоверенных приложений?

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

подцепить библиотеку отрисовывающую html / css

Она называется chromium. Там конечно много лишнего, тем не менее.

А чистый html/css - нафиг не нужен, ибо кривой и не предназначен для GUI.

RazrFalcon ★★★★★
()

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

ой, да очень просто. предлагать сайт как приложение. пример пакета в дебиане

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

Я тут, на днях, у одной девчонки в инсте видел искпишечку на ноуте, так чуть не заплакал от «умиления». Она, наверное, ещё сидит на 2 гигах и «иксплорере», под который до сих пор злые менеджеры требуют писать веб приложухи.

И да, это боль!

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

Она, наверное, ещё сидит на 2 гигах и «иксплорере»

И не тормозит от отличие от современного жирного Linux.

anonymous
()

Хорошую траву курил топикстартер.

Можно начать с более простого вопроса:

Какие существуют языки (и стоящие за ними технологии) разметки интерфейса, которые:

  • Не являются хреновой адаптацией языка разметки документов к задачам разметки интерактивных графических интерфейсов и не тянут за собой легаси размером с Эверест. (Как HTML.)
  • Не обслуживают нужды конкретного тулкита, который помрёт так же незаметно, как появился. (Как Glade XML)
  • Не пытаются решать сразу все задачи мироздания разом. (Как липс-скобочки, которые могут означать что угодно.)
Deleted
()

А добавление поддержки каждого нового типа устройства в браузер - это таки годы обсуждений и ещё столько же запила.

Без стандартизации («годы обсуждений») невозможна совместимость платформ. Будут у тебя веб-страницы которые, скажем, на венде и макоси с плеером совместимы, а на линуксе нет

annulen ★★★★★
()

есть браузер с его фишками. хочу ништяковую %somename% со всеми фишками браузеров, но без их недостатков.
и конечно же, у %somename% никогда не будет своих недостатков. т.е. мы не поменяем шило на мыло. нет. всё будет прекрасно.

на деле, если прочесть твой пост, то всё очевидно. «Минималистичное»+«минимальный размер» == пациент с core2duo 4gb ram мечтает о светлом будущем.
всем срать на минималистичность. компьютер существует чтобы пользоваться софтом (как и ОС)
и если софт требует петабайт оперативной памяти — значит тебе нужен компьютер с петабайтом ram, или не нужен этот софт. period.

system-root ★★★★★
()

Нужен универсальный метапротокол самого высокого уровня для обмена данными. От сайтов будут приходить данные в стандартном виде, которые клиент будет как хочет парсить. Всё будет однообразно отличаться будут только названия полей/тип передаваемых данных. Клиент же - набор приложений и/или тех же комбайном, НО без внешнего высера от сервера в виде html/css/js. Всё реализуется на стороне клиента так или иначе, а не тянется из сети в непотребном виде. От сервера, же будет в спецполе выдаваться информация, какие фичи клиента ему нужны, а фичи будут строчками вида mozilla.graphon.webgl.2_0 или google.web.chat.httpchat и клиент уже будет говорить умеет он в вебгл от mozillы или в чатики от гугла или нет. Конечно, какие-нибудь чатики от гугла могут быть совместимы с чатиками от лисы, что можно указать, можно делать свои компоненты, отдельные приложения для ведра/иос, указывать, с чем они совместимы и т.д.

Ps. Типы данных - тоже будут описываться метапротоколом, то есть будет какое-нибудь web.audio.mp3/acc/wav/flac web.plain_text, web.xml, web.html и т.д. в разных вариациях, с потомками и они могут быть несовместимы между собой и конвертироваться из одного вида в другой.

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

Хорошую траву курил топикстартер.

Можно начать с более простого вопроса:

Какие существуют языки?

Нормальных - никаких, всё говно, а жизнь - тлен. Следовательно: JavaScript'у нет аналогов и не может, потому что это вершина эволюции и развития CS. Стало быть ничего, кроме JS не нужно.

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

Вот электрон в самом деле интересная штука. И если честно, я ожидал что вторая инкарнация QML будет именно как электрон для возможности сайтостроения, но не случилось. Может QML однажды всё же шагнет в след электрону...

I-Love-Microsoft ★★★★★
()

При этом есть и положительные стороны:

...

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

JVM + самописный загружатор софта из сети с поддержкой DNS, на той же Java и написанный. Мне даже кажется, кто-то что-то такое уже делал. Вот почему не взлетело - стоит подумать.

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

Для труЪ-консольного линуксоида семёрочка однозначно удобнее хрюши. Можно запускать программы с клавиатуры: нажал <Win>, начинаешь набирать имя программы, и система тебе автокомплитом предлагает варианты. В хрюше такого не было. Ещё хоткеи навигации по окнам добавили, не такие, как в awesome, но всё-таки.

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

JavaScript'у нет аналогов и не может, потому что это вершина эволюции и развития CS. Стало быть ничего, кроме JS не нужно.

А ведь когда-то это анекдот был:

Один пацан писал все на JavaScript, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно.

EternalNewbie
()
Ответ на: комментарий от I-Love-Microsoft

QML даже в системный шрифт не может, куда ему.

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

Большинство этого покрывает webassembly, canvas, rest json api. Просто никому это не нужно.

Реплика человека не понимающего о чём речь чуть больше, чем абсолютно.

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

Это не Ъ. Для Ъ надо нажимать на TAB после набора первых букв.

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

Ну потрудись объяснить, почему здесь не хватит конвертации любого языка в webassembly и рисования любой графической либой на canvas или через webgl, используя в качестве стандарта передачи json с заданной json schema. Насчет передачи данных, так давно уже много апишек работает, что пишется схема. А насчет того, чтобы передавать наличие или отсутствие поддержки какой-то фичи, так это вообще все браузеры так работают, если не знал. И к нормальным апишкам сейчас в заголовках это передается, плюс версия апи.

Tark ★★
()
Последнее исправление: Tark (всего исправлений: 2)
Ответ на: комментарий от Tark

Ну потрудись объяснить, почему здесь не хватит конвертации любого языка в webassembly и рисования любой графической либой на canvas или через webgl, используя в качестве стандарта передачи json с заданной json schema.

А что с этим делать, если это всё никуда не пойдёт дальше одного ресурса? Что делать с ресурсами, где нет rest api?

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

И чо? Это делает их пригодными для обработки данных? Я не могу на _браузере_ просто взять данные из одного магазина и запихать их во второй, хоть там будут все нужные api. Он не может управлять потоками данных. Я не видел такой системы.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 2)

Разделить Web на несколько частей:

  • Необходим ANSI/ISO/IEEE стандарт Web TeX, который позволит вёрстку научных статей для их последующего отображения в Сети;
  • Необходим ANSI/ISO/IEEE стандарт для разработки кроссплатформенных приложений (базирующихся на Desktop GUI библиотеках и прочем) с рядом разрешений, подобных тем, что мы имеем на ОС Android (доступ к устройствам аудио- и видеозахвата, доступ к сети [причём с разделением по интерфейсам], доступ к системам вывода [к GUI, к принтеру, к CLI], доступ к файловой системе [необходимо ещё и здесь провести разделение, чтоб срать можно было либо только в свою папку конфигов/рабочую папку приложения], системам распр. вычислений [например, GPGPU, в виде WebCL], и т.п.), основанных на кроссплатформенной ВМ, подобной WASM или JVM, и с применением кроссплатформенной системе вывода аудио- и видеосигнала, т.е. WebGL, WebAL. Соответственно должен быть стандартизованный манифест для данных приложений.

Это всё, конечно, хочется, но потянуть продавливание этого всего дерьма даже одной очень крупной компании будет практически нереально.

Обычные люди пошлют всё в зад и будут создавать N+1 дистрибутив с тем подмножеством вышеперечисленного, которое им нужно. Не потянут, забросят, всё тлен и прочие гадости.

Говорить о том, что мы тут что-то можем сделать силами LOR'а не приходится, ибо сил LOR'а практически не существует, все сами по себе.

Ах да, работа с манифестами приложений должна происходить через «магазин приложений» операционной системы, а не определенной компании. Т.е. как в текущих нормальных дистрибутивах, компания - есть репа с приложениями, а не целый магазин с херстоуном и новами.

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

Ъ-консольный линуксоид будет юзать терминал в текстовом режиме, который с семёрки поломали, а с восьмёрки выпилили окончательно. Так что XP рулит.

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

хоткеи навигации по окнам добавили

Убогие, в AquaSnap круче, и работает он даже на XP.

bodqhrohro_promo
()

А что там не так было с java-апплетами?

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