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

BFE>·>Это значит будут дорогие cache misses и всё будет тормозить.
BFE>Почему?
Потому что это сетевой вызов.

BFE>·>Представь размер такого кеша для какого-нибудь популярного сайта.
BFE>Сколько под кэш отведёшь, столько и будет.
Сколько надо-то, чтобы твоя "архитектура" заработала и дала хоть какое-то преимущество?

BFE>·>Верно. Поэтому у тебя будет одно соединение с условным google.com, а не хз сколько с чужими браузерами.
BFE>Рассказывайте!
BFE>Вот я зашёл на rsdn.org
BFE>смотрю network и вижу:
BFE>rsdn.org, www.gravatar.com, www.google-analytics.com
BFE>т.е. понятно, гугл отследил мои действия и записал соответствующий заход в Мой Центр Ада (My Ad Center)
BFE>Для меня чем-то отличается www.google-analytics.com от чужого браузера? Да. google-analytics опаснее, так как он намного больше, чем отдельный никому неизвестный случайный браузер.
Отличается. Я могу его целенаправленно заблокировать, например. Блокировать пиров — неясно как. Либо всё, либо ничего.

BFE>И это только те соединения, которые Firefox соизволил показать. А есть и другие...
Если ты не разбираешься в том, что у тебя на компе происходит, это не значит, что никто ничего не знает.

BFE>·>Что неясно почему кто-то будет по своей воле загружать свой канал.
BFE>Если он не хочет загружать свой канал, то может установить себе прокси, который этим займётся.
А зачем кто-то будет хотеть?

BFE>·>Он может, но чем меньше трафика, тем выгоднее. С какого перепугу тратиться для других?
BFE>Вы хотите поговорить о возможной модели монетизации?
Нет, не хочу.

BFE>>>Пфф! В случае ошибок дубликаты и сейчас шлются.
BFE>·>Только в случае ошибок! Т.е. очень редко на практике, а ты предлагаешь всегда, притом многократно дублировать.
BFE>Зачем многократно-то?
Затем, что ты так сам так предложил: "А запрос сразу ко многим идёт".

BFE>·>Не могут. Ты вначале должен найти пиров, договориться что у кого есть.
BFE>Пиры известны от сервера.
Телепатией? Или дополнительными сетевыми вызовами?

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

BFE>·>А то в итоге получится, что серверы всё равно придётся дублировать.
BFE>Не обязательно. Можно вообще сделать serverless архитектуру. Для получения данных это просто, а вот для передачи от клиента — очень сложно.
А можно вообще чего угодно нафантазировать. Приводи конкретные сценарии.

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

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

BFE>·>Анонимно в том смысле, что слишком дорого найти концы.
BFE>Это плохо или хорошо?
Это факт. В зависимости от того, нравится он тебе или нет — это может быть плохо или хорошо.

BFE>·>Как ты решишь ddos в твоей архитектуре?
BFE>А что вы собираетесь ddos'ить? Исходный сервер? Так ведь не обязательно инфу брать прямого с него.
То что ддосят сейчас.

BFE>·>Зачем гуглу передавать с одного их хоста на другой их хост через мой браузер? Это бессмысленно, проще им будет передать напрямую. Поэтому неясно в чём риск.
BFE>Понятия не имею. Гипотетические ситуации с каким-то детским порно выдумываете вы.
Это ты приводишь идиотские аргументы.

BFE>·>В твоей "архитектуре" у тебя будет передаваться порно с сайта твоему соседу через твой браузер.
BFE>А сейчас порно с сайта передаётся твоему соседу через твоего провайдера. В чём разница?
В том, что это не моя проблема, а провайдера.

BFE>>>И кто же отвечает? И за что?
BFE>·>https://policies.google.com/
BFE>Там написаны какие-то красивые обещания. Мало ли что на заборе пишут. Ответственность заключается в чём?
В том, что это может быть использован в суде с конкретным юридическим лицом, например. А так же репутационные риски и т.п.

BFE>·>Конечно, но риск — это не бинарная величина.
BFE>Сейчас весь риск завязан на нескольких поставщиков сертификатов, а значит опасность выше.
Не завязан. Можешь отвязаться, если вдруг надо.

BFE>А то, о чём вы пишите — это не управление рисками, это вера в большие структуры.
Других вариантов нет.

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

B>Конкретно на РСДН деревья не нужны
Конкретно на форуме деревья ОЧЕНЬ нужны, иначе это просто нечитабельная каша.
Веб UI впрочем всё равно жутко неюзабельный, единственный нормальный способ читать кывт — оффлайновый клиент.

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

BFE>·> Как найти у кого уже есть такие же фоточки?
BFE>Сервер знает.
BFE>Ещё можно по UUID сделать.
Да хоть по хэшу.
Поди угадай у какого DHCP юзера, сидевшего за NAT оно там было.

BFE>·>Как запросить сквозь всякие всевозможные firewalls?
BFE>Вот если бы я делал веб firewall'ам пришлось бы открывать некоторые порты на вход.
Нет, тебя бы просто послали нахрен с такими офигительными идеями.

BFE>А запрос сразу ко многим идёт, как и сейчас (в eMule).
Т.е. нагрузка возрастает чтоб добыть то же самое. Фтопку.

BFE>Не, чем больше скачивающих, тем выше скорость.
Чем больше раздающих а не скачивающих
И опять таки, пусть даже их 100500 но если канал у них так себе то CDN всяко лучше будет.

BFE>Если бы я проектировал веб, то эти костыли были бы не нужны.
Угу, он бы просто не взлетел.

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

BFE>Если сервер секунду назад отослал пакет по адресу X, то наверное у X есть то, что ему отослали? Элементарно же. Нет?
И такиж в общем случае нет.

BFE>Ну так простаивает же.
С чего ты взял?

BFE>Сейчас, если сервер лёг, то — всё, а при распределённой модели всё продолжит работать.
Просто поставь себе клиент IPFS и полюбуйся как оно безумно медленно работает. А ведь это именно то, что ты тут предлагаешь.

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

BFE>·>Представь размер такого кеша для какого-нибудь популярного сайта.
BFE>Сколько под кэш отведёшь, столько и будет.
Ну вот, начинаются проблемки.

BFE>·>Что неясно почему кто-то будет по своей воле загружать свой канал.
BFE>Если он не хочет загружать свой канал, то может установить себе прокси, который этим займётся.
Начнём с того что все входящие на клиентских машинах будут тупо зарублены.

BFE>·>Только в случае ошибок! Т.е. очень редко на практике, а ты предлагаешь всегда, притом многократно дублировать.
BFE>Зачем многократно-то?
У каждого пользователя же.
Кстати тебе ещё надо решить что делать с динамическим контентом и версионностью.

BFE>·>Не могут. Ты вначале должен найти пиров, договориться что у кого есть.
BFE>Пиры известны от сервера.
А с чего ты взял что все они живы, имеют нужный тебе контент да и вообще доступны?

BFE>·>Ты так и не ответил на вопрос "для чего же конкретно это вообще нужно-то?".
BFE>Вы меня спрашиваете зачем нужен веб?
Не веб (что подразумевает конкретную существующую имплементацию) а именно твоя идея реализации.

BFE>·>Анонимно в том смысле, что слишком дорого найти концы.
BFE>Это плохо или хорошо?

BFE>А что вы собираетесь ddos'ить?
Да примерно как emule засирают троянами и спамом.

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

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

Ты банально предлагаешь сделать из браузера некое подобие IPFS over TOR

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

G>Неубедительно что надо сайты делать исключительно под IE3

IE просто как пример того, что было на заре Web'а. На деле весь этот трэд и есть обсуждение того, что современная паутина превратилось в говняную, медленную, разбухшую вермишель и рано или поздно она похоронит сама себя, а RSDN перепишут под html 1.0

B>>Конкретно на РСДН деревья не нужны (это вообще один из самых порочных элементов UI). Тут чё, дюже иерархический сайт? Пяток форумов (не нуждающихся в подфорумах), да статьи. Кому и за каким якодзуном понадобились деревья?!
G>Если все ваше обоснование заключается в том, что "это не нужно", то дальше в общем нечего обсуждать.

Просто слился с темы. Так и запишем: "аргументов нет!".

G>То же самое дерево без JS хоть из возможно в теории (в реальности небольшой js все равно нужен), то это приведет к БОЛЬШЕМУ трафику между клиентом и сервером, так как для обновления состояния клиента придется перекачивать страницу целиком. Если эта страница форума с кучей данных из базы, то тормозить это будет очень сильно.

Форумы не вы и не вчера придумали — они жили ещё когда даже JS не было. И ничё, работало на ТЕХ(!) скоростях без проблем. Тут весь вопрос в usability, которая на РСДН хромает на обе ноги. Ты смотришь на сайт как на большую абстрактную кучу "всего полезного", я вижу лишь форум и статьи. И то, и другое можно значительно упростить, не пытаясь изображать из сайта какой-то фэйсбук (пафос и объём).

G>Я выше написал, но ты объявил это ненужным.
Не написал. Просто слился. Могу ещё раз повторить: РСДН можно сделать кратно проще. А заодно и прикрутить хранилище картинок.

G>Какой смысл ориентироваться на старые стандарты, если на новых можно сделать неплохо?

Ключевое слово не "старые", а "простые"! Весь веб сейчас — это одна большая, бестолковая помойка, которую периодически трясёт жабоскриптами. Этот маразм кончится, потому что это маразм. И вернёмся к Вебу как паблишингу и отдельным миром — веб-приложения. Ну, это моя оптимистичная фантазия технаря, а так веб-макаки могут ещё лет 20 свои говносайты накручивать. Дожили — простейший текст нельзя прочитать без долбаного жабоскрипта!! Позорище всем веб-лабателям.

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

CC>Поди угадай у какого DHCP юзера, сидевшего за NAT оно там было.
Если бы веб был другой, то и NAT работал бы иначе.

CC>Нет, тебя бы просто послали нахрен с такими офигительными идеями.
Когда делали веб "посылать" было некому.

BFE>>А запрос сразу ко многим идёт, как и сейчас (в eMule).
CC>Т.е. нагрузка возрастает чтоб добыть то же самое. Фтопку.
Нет. Чтобы получить разные часть от разных источников параллельно.

BFE>>Не, чем больше скачивающих, тем выше скорость.
CC>Чем больше раздающих а не скачивающих
Нет! Именно, что чем больше скачивающих, тем выше скорость, так как каждый скачивающий == раздающий.

CC>И опять таки, пусть даже их 100500 но если канал у них так себе то CDN всяко лучше будет.
Нет, BitTorrent они не обгонят.

BFE>>Если бы я проектировал веб, то эти костыли были бы не нужны.
CC>Угу, он бы просто не взлетел.
Сейчас всё больше переходят к этой архитектуре в том или ином виде, но теперь это сделать сложно из-за груза предыдущих подходов.

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

CC>С чего ты взял?
Таймауты по потерям пакетов никто не отменял.

BFE>>Сейчас, если сервер лёг, то — всё, а при распределённой модели всё продолжит работать.
CC>Просто поставь себе клиент IPFS и полюбуйся как оно безумно медленно работает. А ведь это именно то, что ты тут предлагаешь.
Возможно. Надо будет посмотреть на реализацию. Надеюсь они на UDP работают.

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

CC>>Поди угадай у какого DHCP юзера, сидевшего за NAT оно там было.
BFE>Если бы веб был другой, то и NAT работал бы иначе.
Дада, конечно!

BFE>>>А запрос сразу ко многим идёт, как и сейчас (в eMule).
CC>>Т.е. нагрузка возрастает чтоб добыть то же самое. Фтопку.
BFE>Нет. Чтобы получить разные часть от разных источников параллельно.
Параллельность тут не даётся бесплатно, так что "платить" за одно и то же но присланое из 15 источников всё равно придётся.

CC>>Чем больше раздающих а не скачивающих
BFE>Нет! Именно, что чем больше скачивающих, тем выше скорость, так как каждый скачивающий == раздающий.
Далеко не каждый раздающий раздаёт на хотя бы той же скорости, да и далеко не каждый скачавший остаётся на раздаче.
Так что нет. Всё зависит от раздающих а не качающих.

BFE>Нет, BitTorrent они не обгонят.


BFE>Сейчас всё больше переходят к этой архитектуре в том или ином виде
Где, покажи пальцем на хоть что то реально работающее

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

vsb>Если резюмировать, что бы я сделал по-другому:

vsb>Приложение должно определяться, как группа ресурсов. При первом открытии приложения вся группа ресурсов должна скачиваться. Обновление не должно быть обязательным, у пользователя должна быть возможность использовать старую версию приложения и обновляться по желанию. К примеру я стою на светофоре и запустил навигатор. Мне нужно, чтобы он запустился моментально, а не скачивал 150 мегабайтов новой версии.

Ты хочешь чтобы каждый сайт стал приложением, которое бы со всеми ресурсами скачивалось на комп, даже если я дальше главной страницы не пойду, а может даже дальше страницы логина? Кинули ссылку с мемасом, ты открываешь и с этого момента хранишь у себя ВСЕ приложение к которому возможно больше никогда не обратишься? Мало того, чтобы один раз взглянуть на картинку или отдельную "страницу" переданную по ссылке и забыть, ты должен будешь подождать пока все приложение, а "страниц" в нем может быть много (начиная от логина и оформления профиля пользователя и заканчивая чтением и написанием комментариев), не загрузится.

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

vsb>>Приложение должно определяться, как группа ресурсов. При первом открытии приложения вся группа ресурсов должна скачиваться. Обновление не должно быть обязательным, у пользователя должна быть возможность использовать старую версию приложения и обновляться по желанию. К примеру я стою на светофоре и запустил навигатор. Мне нужно, чтобы он запустился моментально, а не скачивал 150 мегабайтов новой версии.

FLY>Ты хочешь чтобы каждый сайт стал приложением, которое бы со всеми ресурсами скачивалось на комп, даже если я дальше главной страницы не пойду, а может даже дальше страницы логина? Кинули ссылку с мемасом, ты открываешь и с этого момента хранишь у себя ВСЕ приложение к которому возможно больше никогда не обратишься? Мало того, чтобы один раз взглянуть на картинку или отдельную "страницу" переданную по ссылке и забыть, ты должен будешь подождать пока все приложение, а "страниц" в нем может быть много (начиная от логина и оформления профиля пользователя и заканчивая чтением и написанием комментариев), не загрузится.

Вообще я разделяю сайты и веб-приложения.

Но сложные сайты вроде пикабу в такой интерпретации скорей всего будут приложениями.

Да, хранишь всё приложение. Ровно так же, как ты сейчас у себя хранишь всё приложение пикабу, если хоть раз туда зашёл. В виде набора JS, CSS, картинок и прочего в кеше. И ровно так же кеш неиспользуемых приложений можно и нужно очищать, если пользователь не пользуется приложением и не выразил какого-то явного желания не очищать этот кеш. Это сейчас даже смартфоны делают с мобильными приложениями.

FLY>должен будешь подождать пока все приложение, а "страниц" в нем может быть много (начиная от логина и оформления профиля пользователя и заканчивая чтением и написанием комментариев), не загрузится.
А как же микросервисная архитектура, по которой положено для показа каждой картинки делать своё микроприложение?
И как надо постараться, чтобы бинарник, показывающий 1 страницу, был больше, чем современно-актуальный жабаскрипт, делающий то же самое?

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

O>А как же микросервисная архитектура, по которой положено для показа каждой картинки делать своё микроприложение?
O>И как надо постараться, чтобы бинарник, показывающий 1 страницу, был больше, чем современно-актуальный жабаскрипт, делающий то же самое?
Почему одну страницу, а не весь сайт? Если же приложение будет разбивается на микросервисы, которые в свою очередь отправляют запросы для получения ресурсов, то чем это будет отличаться от того, что мы имеем сейчас?

O>>А как же микросервисная архитектура, по которой положено для показа каждой картинки делать своё микроприложение?
O>>И как надо постараться, чтобы бинарник, показывающий 1 страницу, был больше, чем современно-актуальный жабаскрипт, делающий то же самое?
FLY>Почему одну страницу, а не весь сайт?
По той же причине, что десктопное приложение из многих dll а не 1 большой exe — для возможности замены по частям.
>Если же приложение будет разбивается на микросервисы, которые в свою очередь отправляют запросы для получения ресурсов, то чем это будет отличаться от того, что мы имеем сейчас?
Писанием на человеческом строготипизированном языке и исполнением человеческих скомпилированных бинарников. А не этого жруще-тормозящего конгломерата костылей, который сейчас нагромоздили вокруг запрета запускать бинарники на клиенте, который затевался якобы для безопасности, но всё равно броузер для незнакомых г-сайтов (а лучше для всех) надо запускать в отдельной виртуалке.

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

O>По той же причине, что десктопное приложение из многих dll а не 1 большой exe
Да всё как то больше 1 exe стараются делать везде где только это получается.

O> для возможности замены по частям.
Так никто не делает и на деле никому вообще не нужно.

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

vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают.

vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.

Так надо не веб менять, а десктоп в первую очередь.
Завезти в ОС как минимум следующее:
— унифицированное API для GUI
— запуск приложений в песочнице и раздачу прав примерно как на мобильных ОС
— унифицированные механизмы репозиториев/магазинов. Чтобы не выдумывать разные инсталляторы, обновляторы, экспорты/импорты настроек...

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

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

CC>Дада, конечно!
Архитектурные особенности именно такие.

CC>Параллельность тут не даётся бесплатно, так что "платить" за одно и то же но присланое из 15 источников всё равно придётся.
Платить — да. но не скоростью передачи.

BFE>>Нет! Именно, что чем больше скачивающих, тем выше скорость, так как каждый скачивающий == раздающий.
CC> Далеко не каждый раздающий раздаёт на хотя бы той же скорости, да и далеко не каждый скачавший остаётся на раздаче.
Даже с учётом того, что исходящая пропускная возможность каждого клиента меньше, чем входящая пропускная возможность каждого клиента, суммарная пропускная способность всех исходящих каналов клиентов выше, чем сервера.
Обычно потребители веб страниц не отрубаются от сети сразу после закачки страницы, так что минимум секунда ещё есть, этого достаточно.

CC>Так что нет. Всё зависит от раздающих а не качающих.
Обычно если скачивающий не раздаёт, то его блокируют.

BFE>>Нет, BitTorrent они не обгонят.
CC>
А что смешного? По скорости протокол BitTorrent'а никто не обходит.

BFE>>Сейчас всё больше переходят к этой архитектуре в том или ином виде
CC>Где, покажи пальцем на хоть что то реально работающее
QUIC — вот шаг в данном направлении.
И вообще, distribution networks CDN работают именно на этой архитектуре. То, что эту технологию сегодня крайне сложно распространить на клиентскую часть — проблема начальной архитектуры веб.

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

CC>>Параллельность тут не даётся бесплатно, так что "платить" за одно и то же но присланое из 15 источников всё равно придётся.
BFE>Платить — да. но не скоростью передачи.
Забитость канала естественным путём ограничивает скорость

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

CC>>Так что нет. Всё зависит от раздающих а не качающих.
BFE>Обычно если скачивающий не раздаёт, то его блокируют.
Даже в торрентах от этого давно отказались

BFE>А что смешного? По скорости протокол BitTorrent'а никто не обходит.
В очень специфическмх раскладах.
Ещё раз, тебе надо сравнивать не с торрентом а с IPFS

BFE>QUIC — вот шаг в данном направлении.
А где там то, что ты описываешь с торрент-like потягушками от клиентов?

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

O>Писанием на человеческом строготипизированном языке и исполнением человеческих скомпилированных бинарников.
Чем тогда WASM не устраивает?