Здравствуйте, karbofos42, Вы писали:

K>·>ICQ?! Нифига себе. Лет 20 уж не видел. Где ты её нашел и сколько там живых контактов?
K>Всё на том же icq.com.
Мде.

K>·>Ну не все, mattermost например только веб, ну плюс pwa афаир.
K>Так люди в мессенджерах пользуются удобными веб-версиями или качают неудобные нативные приложения в большинстве своём?
Эти аппликухи обычно умеют хоть как-то работать в оффлайне. В отличие от веб-версий. Поэтому не удивительно.

K>·>Затачивают под определённый десктоп, для более широкого функционала.
K>т.е. десктоп таки функциональнее веба?
Да, ибо есть возможность затачивать под конкретный десктоп и работать в оффлайне.

K>·>Я это не говорил. Ты два раза прочитал неправильно. Повторю третий раз: "на десктоп ссылаться нельзя". Обрати внимание на падеж.
K>Ну, тогда и на веб нельзя ссылаться
Можно.

K>·>Что?
K>Ну, говорят, что в iOS приложения в песочнице работают, значит там должно всё медленно работать.
Почему значит?
Про медленность я имел в виду, что клик по ссылке веба тебе выдаёт контент через пару секунд. А в случае десктопа потребуется магазин, установка, пермишенны, етс, то время вырастет на пару порядков. А ещё рано или поздно придётся подчищать всякий установленный хлам.

K>·>Да даже пусть мессенджеры. Вот проходил я недавно кучу интервью. У кого-то zoom, у кого-то в teams, у кого-то ещё что. И всё работало в браузере. Не стал бы я ставить себе такой зоопарк локально ради пары недель.
K>А кто-то заставляет?
Если бы присылали какой-нибудь скайп, который надо ставить, то было бы всё гораздо сложнее.

K>·>В общем суть такова, что идёт всё в веб, а не обратно. Десктоп как временное, пока функциональность не доросла в браузерах. Ну и для массивных вещей. Игрушку на 100гб конечно лучше поставить.
K>А причём тут куда идёт? По факту на горизонте пока нет никаких предпосылок к новой популярности десктопа.
K>Скорее наоборот через всякие WebAssembly его будут дальше добивать и натягивать что попало на веб-технологии.
Угу.

K>Только тема вроде не о том, что есть сейчас по факту
Просто если немного подумать, то что есть по факту — не так уж и плохо, известные альтернативы — хуже. И революции я тут не ожидаю, не вижу возможности прям всё сразу хорошо сделать, а эволюция идёт своим чередом. Самая большая проблема это обратная совместимость.
Ясен пень, что сайты можно делать корявыми, но технологии достаточно развиты, что есть возможность делать и по уму.

Здравствуйте, karbofos42, Вы писали:

K>Веб отличный и замечательный, JS быстрейший
То то некоторым сайтам надо современный проц чтоб приемлемо шевелиться.

Здравствуйте, karbofos42, Вы писали:

K>нативные приложения удобнее в использовании, чем возня в браузере.
Подтверждаю, см подпись

Здравствуйте, ·, Вы писали:

·>Можно.

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

·>Почему значит?

Ну, ты писал, что песочница и все эти разрешения — это медленно и нативный код будет работать на уровне JS.

·>Про медленность я имел в виду, что клик по ссылке веба тебе выдаёт контент через пару секунд. А в случае десктопа потребуется магазин, установка, пермишенны, етс, то время вырастет на пару порядков.

Ну, ты сам придумал, что прямо всё уйдёт из веба в десктоп и для просмотра мемасиков придётся ставить отдельное приложение.
Никто не мешает делать обработку ссылок так, что если есть установленный телеграм, то открывать ссылку в нём, нет — открываем веб-версию в браузере.
Открытие ссылок в браузере за пару секунд проходят только в простейших случаях.
По факту и с браузерами безудержное веселье периодически:
приходит ссылка в мессенджер на какую-нибудь CRM/ERP/... переходишь — она открывается в браузере по умолчанию, но для этого ресурса нужно какое-нибудь ГОСТ-шифрование или доступ через прокси должен идти и потому настроено отдельно в Яндекс.Браузере.
В итоге копируешь ссылку и вручную вставляешь в Яндекс.Браузер, там оказывается, что куки протухли или кэш очищался и автологин отвалился. Перенаправляет на страницу входа. Вводишь таки логин, пароль, а разработчики перенаправление на исходную ссылку не осилили и показывают главную страницу, т.е. нужно опять ту ссылку вручную вставлять.

·>А ещё рано или поздно придётся подчищать всякий установленный хлам.

Как-будто тот же браузер в кэше всякое не собирает и не жрёт память почём зря.

·>Если бы присылали какой-нибудь скайп, который надо ставить, то было бы всё гораздо сложнее.

Ещё раз: я где-то писал, что весь веб нужно убить и вместо него сделать такой же десктоп?
Я лишь написал, что нужно в десктоп завести плюшки из веба и тогда к нему народ потянется.
Хочешь удобство и функционал — ставишь десктопную версию.
Хочешь что-то быстренько посмотреть — используешь урезанную веб-версию.
Что-то подобное и сейчас есть, только у большинства компаний нет денег на десктопную версию и потому выжимают всё из веба и даже не пытаются делать нормальный десктоп.

Здравствуйте, CreatorCray, Вы писали:

BFE>> Ну и логично сразу от клиента направить запрос с дублированием для скорости в случае если один из клиентов не ответит.
CC>Т.е. вместо того, чтоб сразу взять с сайта, у которого канал толщиной с ногу и с которым у тебя уже установлено соединение, ты будешь рассылать запросы на деревню дедушке в надежде что у кого то из них окажется и нужная тебе хреновина и исходящий канал будет толще чем у сервака.
Ну, можно же сделать это и помягче.
Во-первых, сервер может отдавать вместе с данными хинты, типа "реплики данных лежат ещё и вот здесь". Для микро-запросов это будет не очень актуально, а вот когда тянется какой-то большой ресурс, клиент может параллельно дёрнуть ещё несколько вариантов и тащить разные куски с разных адресов через range header. К различным толщинам каналов можно и адаптироваться — c быстрого тащим гигабайт, с медленного 10кб.

Во-вторых, при определённых усилиях сервер может отдавать не все хинты подряд, а выполнять кластеризацию по адресу. Типа "реплики данных лежат ещё и вот у этих твоих соседей"

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

BFE>>Протокол BitTorrent работает поверх веба?
CC>Не то чтобы поверх. Есть extensions которые умеют всяко подтягивать с HTTP но сам протокол к вебу не имеет отношения.

Здравствуйте, Sinclair, Вы писали:

S>а вот когда тянется какой-то большой ресурс
А что в вебе будет считаться большим ресурсом?

S>, клиент может параллельно дёрнуть ещё несколько вариантов и тащить разные куски с разных адресов через range header. К различным толщинам каналов можно и адаптироваться — c быстрого тащим гигабайт, с медленного 10кб.
Т.е. это переизобретение торрента, вот только нету в типичном вебе таких размеров файлов чтоб это было оправдано. А самая большая проблема это то, что клиенты ну совсем не хотят у себя что то хранить и раздавать.

S>Но это всё нужно тщательно просчитывать, и далеко не для всякого типа сетевой нагрузки это вообще подойдёт.
Разумеется.

Здравствуйте, karbofos42, Вы писали:

K>·>Можно.
K>Ссылаются на ресурс, а не на какой-то там веб.
Ссылаются не на какой-то там ресурс, а на веб-ресурс. Или даже веб-приложение.

K>Более того: все ссылки в итоге обрабатывают нативные приложения. Этим приложением может выступать браузер, либо что-то узкоспециализированное.
Это бессмысленное в данном контексте обобщение. Проще уж сразу говори, что те же электроны везде бегают.

K>·>Почему значит?
K>Ну, ты писал, что песочница и все эти разрешения — это медленно и нативный код будет работать на уровне JS.
Я такое не писал. Помню, что я писал почти противоположное — jit позволяет js работать по скорости на уровне натива.

K>·>Про медленность я имел в виду, что клик по ссылке веба тебе выдаёт контент через пару секунд. А в случае десктопа потребуется магазин, установка, пермишенны, етс, то время вырастет на пару порядков.
K>Ну, ты сам придумал, что прямо всё уйдёт из веба в десктоп и для просмотра мемасиков придётся ставить отдельное приложение.
K>Никто не мешает делать обработку ссылок так, что если есть установленный телеграм, то открывать ссылку в нём, нет — открываем веб-версию в браузере.
K>Открытие ссылок в браузере за пару секунд проходят только в простейших случаях.
И этих простейших случаев практически 99.9%, а то и больше, в текущих масштабах.

K>По факту и с браузерами безудержное веселье периодически:
Причём тут браузеры? В данном случае:
K> разработчики ... не осилили
И собственно всё.

K>·>А ещё рано или поздно придётся подчищать всякий установленный хлам.
K>Как-будто тот же браузер в кэше всякое не собирает и не жрёт память почём зря.
Это не то, что заботит типичного юзера. Размер кеша фиксирован и он работает сам, без участия человека. А память жрут все, десктоп, кстати, может жрать менее контролируемо.

K>·>Если бы присылали какой-нибудь скайп, который надо ставить, то было бы всё гораздо сложнее.
K>Ещё раз: я где-то писал, что весь веб нужно убить и вместо него сделать такой же десктоп?
K>Я лишь написал, что нужно в десктоп завести плюшки из веба и тогда к нему народ потянется.
Это нежизнеспособно. Это происходит с другой стороны — в веб завозят плюшки десктопа.

K>Хочешь удобство и функционал — ставишь десктопную версию.
K>Хочешь что-то быстренько посмотреть — используешь урезанную веб-версию.
K>Что-то подобное и сейчас есть, только у большинства компаний нет денег на десктопную версию и потому выжимают всё из веба и даже не пытаются делать нормальный десктоп.
Так ведь большинству компаний и не нужна десктопная версия.

Здравствуйте, CreatorCray, Вы писали:
CC>А что в вебе будет считаться большим ресурсом?
Сотни мегабайт.
CC>Т.е. это переизобретение торрента,
Да, совершенно верно.
CC>вот только нету в типичном вебе таких размеров файлов чтоб это было оправдано.
Во-первых и так есть контент вроде видео. Понятно, что для него можно переключаться на специализированный протокол — те же торренты сейчас более-менее любым плеером играются.
Во-вторых, размеры ресурсов современного типичного веба такие не только в силу объективных обстоятельств, но и в силу архитектуры.
Если мы заменяем JS на бинари, то упаковывать весь сайт в небольшое количество крупных кусков, которые быстро приезжают через торрентоподобный протокол, может оказаться выгоднее, чем резать его на тысячи килобайтных "скриптиков".
CC>А самая большая проблема это то, что клиенты ну совсем не хотят у себя что то хранить и раздавать.
А кто их будет спрашивать? Вон торренты тащат и не жужжат, что во время скачивания они безусловно раздают пирам готовые блоки.
Если итоговые потребительские характеристики такого протокола будут лучше, чем у конкурентов, то включат и будут пользоваться. И будут считать само собой разумеющимся, что код нетфликс-клиента приезжает за долю секунды через сотню запросов по соседям, вместо вот этого "хотите ли поставить обновление? Ждите пять минут.... четыре минуты.... три минуты... десять минут...", когда хочется уже новую серию включить и пиво греется.

Здравствуйте, Sinclair, Вы писали:

S>Если мы заменяем JS на бинари, то упаковывать весь сайт в небольшое количество крупных кусков, которые быстро приезжают через торрентоподобный протокол, может оказаться выгоднее, чем резать его на тысячи килобайтных "скриптиков".
В современном вебе тысячи килобайтных скриптиков, css, gif, и т.п. пакуется с помощью webpack в удобное количество gzip-бандлов и выкладывается в cdn, с тонкой настройкой по топологии и географии Сети. Так что самые обыкновенные бинари с т.з. сети.

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

Здравствуйте, Sinclair, Вы писали:

CC>>вот только нету в типичном вебе таких размеров файлов чтоб это было оправдано.
S>Во-первых и так есть контент вроде видео.
Оно ж всё стриминговое, ну, кроме собственно торрента
Подкачивается нужный кусок и на клиенте не хранится ибо объёмы.
Так что надо ещё найти того, кто смотрит нужный тебе ролик в том же самом месте.

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

S>Если итоговые потребительские характеристики такого протокола будут лучше
Дык пока не похоже чтоб они были.

S> то включат и будут пользоваться.
Тоже очень сомнительно. Инерционность тут огромная.

S>код нетфликс-клиента приезжает за долю секунды через сотню запросов по соседям, вместо вот этого "хотите ли поставить обновление?
Мы всё ещё про веб? Вон, youtube.com никаких обновлений не требует, работает мнгновенно.

Здравствуйте, Shmj, Вы писали:

S>Т.е., как сказал один чел, браузер превратится в вирт. машину + графический движок.

Наивный. Спустя почти 10 лет WebAssembly по-прежнему почти никто не пользуется. В Swift уже минимум 5 лет открытый стандарт toolchain под LVVM на любой ОСи, ну и что — более 90% приложений в AppStore написаны на каком-нибудь Cordova, а под более открытыми ОСями и подавно LVVM не востребован даже среди 1% пользователей, в desktop почти все новые разработки — browser applications.

Здравствуйте, ·, Вы писали:

BFE>>Вот тут он просядет, а вот тут — нет. Ну вот с чего бы, если передаются одни и те же данные?
·>Данные одни, но ты сам сказал, что надо будет посылать запрос нескольким клиентам, на случай если кто-то из них не ответит. Т.е. вместо одного запроса, надо будет слать несколько.
·>И ещё одна весёлость — если таки на запросы начнут приходит ответы от нескольких пиров — у тебя будут входящие дубликаты, пытаясь пролезть через тот же канал.

Забить канал на веб странице — это постараться надо. Там же многократный запас.

·>Иными словами, чтобы твоя система хоть как-то надёжно заработала хотя бы в идеальном случае, данные придётся многократно дублировать, что уменьшит пропускную способность канала.
Это голословное утверждение.

·>А если ещё рассматривать malicious attacks, то "злые" пиры могут просто в ответ всякий мусор слать, ддося твой канал.
Вот когда вы последний раз видели, чтобы забивали канал какого-то одного пользователя? Это и сейчас можно делать. Что мешает-то ?

·>Суть у него примерно та же, что у tcp.
Это смотря, что называть сутью.

BFE>>·>Просто вариация TCP оптимизированная для определённых сценариев.
BFE>>Ну да. Для определённых сценариев.
·>И заметь, никаких peer-to-peer.
Он отлично подойдёт для peer-to-peer.

Здравствуйте, B0FEE664, Вы писали:

BFE>·>Данные одни, но ты сам сказал, что надо будет посылать запрос нескольким клиентам, на случай если кто-то из них не ответит. Т.е. вместо одного запроса, надо будет слать несколько.
BFE>·>И ещё одна весёлость — если таки на запросы начнут приходит ответы от нескольких пиров — у тебя будут входящие дубликаты, пытаясь пролезть через тот же канал.
BFE>Забить канал на веб странице — это постараться надо. Там же многократный запас.
На мобилке? Запросто. А ещё на мобилке нередко бывает тариф платный. Покупаешь 1гб на месяц и тратишь. Если ты будешь слать 5 запросов пирам — то внезапно за эти же 1гб ты увидишь в 5 раз меньше контента.

BFE>·>Иными словами, чтобы твоя система хоть как-то надёжно заработала хотя бы в идеальном случае, данные придётся многократно дублировать, что уменьшит пропускную способность канала.
BFE>Это голословное утверждение.
"Иными словами" это дополнение к уже сказанному выше.

BFE>·>А если ещё рассматривать malicious attacks, то "злые" пиры могут просто в ответ всякий мусор слать, ддося твой канал.
BFE>Вот когда вы последний раз видели, чтобы забивали канал какого-то одного пользователя?
Не любого пользователя, а который зашел на некий ресурс.

BFE>Это и сейчас можно делать.
Как?

Здравствуйте, ·, Вы писали:

·>А если ещё рассматривать malicious attacks, то "злые" пиры могут просто в ответ всякий мусор слать, ддося твой канал.
Там ещё веселее можно сделать: засирать кэш пиров сайта запрашивая с ботнета какой нить из js от страницы чтоб сайт думал что этот js есть у ботнетных нод, а тем, кто на ноды за ними приходит — отдавать малварь

Здравствуйте, CreatorCray, Вы писали:

CC>·>А если ещё рассматривать malicious attacks, то "злые" пиры могут просто в ответ всякий мусор слать, ддося твой канал.
CC>Там ещё веселее можно сделать: засирать кэш пиров сайта запрашивая с ботнета какой нить из js от страницы чтоб сайт думал что этот js есть у ботнетных нод, а тем, кто на ноды за ними приходит — отдавать малварь
Я об этом тоже думал, но от этого легко защититься — контент идентифицировать и проверять криптографическим хешем. Впрочем, это лишняя нагрузка на cpu.