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

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

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

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

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

BFE>·>Зачем это делать браузеру?
BFE>Чтобы разгрузить сервера.
Давай подробнее. Вот захожу я фоточки поглядеть, новости почитать, в форуме пофлеймить. Как найти у кого уже есть такие же фоточки? Как запросить сквозь всякие всевозможные firewalls? А что если запрос потеряется, какой у меня будет latency? Ждать по пол минуты пока 10кб файлик найдётся?

emule это всё-таки для раздачи больших файлов. Закинул закачку, пришел завтра — оно выкачано. Как это ложиться на какой-нибудь новостной сайт, twitter, блог, интернет-магазин, etc — неясно.

BFE>·>Для этого есть кеширующие прокси и cdn.
BFE>Вот именно.
И?

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

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

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

Как в мобилках — сайт не нужен.
Нужен сервис и приложение к нему.

Или как изначально задумывались Java-апплеты и .Net — подгружаемая исполняемая прога.
Хорошую идею сгубили недостатки безопасности...

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

·> Как найти у кого уже есть такие же фоточки?
Сервер знает.
Ещё можно по UUID сделать.

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

·>А что если запрос потеряется, какой у меня будет latency? Ждать по пол минуты пока 10кб файлик найдётся?
А запрос сразу ко многим идёт, как и сейчас (в eMule).

·>emule это всё-таки для раздачи больших файлов. Закинул закачку, пришел завтра — оно выкачано.
Не, чем больше скачивающих, тем выше скорость.

·>Как это ложиться на какой-нибудь новостной сайт, twitter, блог, интернет-магазин, etc — неясно.
Да так же, но для коротких мессаджей, типа twitter это, понятно, не нужно.

BFE>>·>Для этого есть кеширующие прокси и cdn.
BFE>>Вот именно.
·>И?
Если бы я проектировал веб, то эти костыли были бы не нужны.

·>И тебе будет ок, если твой браузер будет прокачивать какое-нибудь условное детское порно через твой комп?
Вполне может быть, что и сейчас это происходит — я же не контролирую все возможные ресурсы интернета, к которым обращается браузер, когда я захожу на https://rsdn.org.
Можно подумать, что вы побайтово контролируете весь трафик проходящий через ваш компьютер...

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

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

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

BFE>·>А что если запрос потеряется, какой у меня будет latency? Ждать по пол минуты пока 10кб файлик найдётся?
BFE>А запрос сразу ко многим идёт, как и сейчас (в eMule).
На масштабах текущего веба всё тихо ляжет.

BFE>·>emule это всё-таки для раздачи больших файлов. Закинул закачку, пришел завтра — оно выкачано.
BFE>Не, чем больше скачивающих, тем выше скорость.
Потому что файлы большие. С одномегабайтными фоточками не пройдёт. Засеки сколько времени занимает выкачать 1мб из мула и 1мб с cdn-хостинга.

BFE>·>Как это ложиться на какой-нибудь новостной сайт, twitter, блог, интернет-магазин, etc — неясно.
BFE>Да так же, но для коротких мессаджей, типа twitter это, понятно, не нужно.
Осталось выяснить для чего же конкретно это вообще нужно-то?

BFE>·>И?
BFE>Если бы я проектировал веб, то эти костыли были бы не нужны.
Это не костыли, а вполне себе самая адекватная реализация фичи.

BFE>·>И тебе будет ок, если твой браузер будет прокачивать какое-нибудь условное детское порно через твой комп?
BFE>Вполне может быть, что и сейчас это происходит — я же не контролирую все возможные ресурсы интернета, к которым обращается браузер, когда я захожу на https://rsdn.org.
Тут уже цепочка доверия. Я доверяю, что rsdn.org не распространяет всякую фигню. Например, служба безопасности mybank.com мониторит и контролирует содержимое страниц.

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

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

·>Сервер должен хранить список запущенных в данный момент браузеров по всему миру? Трекать содержимое их кешей? Как?
Серьёзно не понимаете?
Если сервер секунду назад отослал пакет по адресу X, то наверное у X есть то, что ему отослали? Элементарно же. Нет?

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

·>А главное зачем? С какого перепугу васе пупкину хотеть забивать свой исходящий канал?
Ну так простаивает же.

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

·>На масштабах текущего веба всё тихо ляжет.
С чего бы?

·>Потому что файлы большие. С одномегабайтными фоточками не пройдёт. Засеки сколько времени занимает выкачать 1мб из мула и 1мб с cdn-хостинга.
Хмм. Затрудняюсь понять, как мне измерить это время.

·>Осталось выяснить для чего же конкретно это вообще нужно-то?
Сейчас, если сервер лёг, то — всё, а при распределённой модели всё продолжит работать.

·>Это не костыли, а вполне себе самая адекватная реализация фичи.
Точно не бага?

·>Тут уже цепочка доверия.
И чем, принципиально, "тут" отличается от предлагаемой схемы? Цепочка всегда есть.

·>В целом, да. Не побайтово, конечно.
Не верю.

·>Но до какого-то предела можно найти ответственных и призвать к отвественности.
Скорее всего, нет, нельзя.
Да и как можно призвать к ответу за то, что вам не известно?

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

BFE>·>Сервер должен хранить список запущенных в данный момент браузеров по всему миру? Трекать содержимое их кешей? Как?
BFE>Серьёзно не понимаете?
BFE>Если сервер секунду назад отослал пакет по адресу X, то наверное у X есть то, что ему отослали? Элементарно же. Нет?
Конечно, нет. Ты сетевые приложения никогда не разрабатывал что-ли?
X мог банально сломать или потерять пакет. Более того, даже одну секунду назад у X был пакет, через минуту его может не стать, т.к. кеш переполнится, например.
Далее. Сервер за секунду отослал пакет тысяче клиентов. Он должен список из тысячи клиентов хранить? Где? Как долго?

BFE>>>Вот если бы я делал веб firewall'ам пришлось бы открывать некоторые порты на вход.
BFE>·>Т.е. открывать новые дыры в безопасности? Не, спасибо.
BFE>Зачем открывать дыры? Порт можно отрыть, а вот дыры — зачем?
Каждый открытый порт — потенциальная дыра.

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

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

BFE>·>На масштабах текущего веба всё тихо ляжет.
BFE>С чего бы?
Придётся вместо одного запроса слать дубликаты. Увеличится нагрузка на сеть и количество round-trips — просядет производительность.

BFE>·>Потому что файлы большие. С одномегабайтными фоточками не пройдёт. Засеки сколько времени занимает выкачать 1мб из мула и 1мб с cdn-хостинга.
BFE>Хмм. Затрудняюсь понять, как мне измерить это время.
Ну можно оценить по числу раунд-трипов и хопов. В случае cdn — запрос в dns (кешируемый), и один раундтрип до ближайшего cdn узла. В emule — не знаю, но думаю на порядок больше.

BFE>·>Осталось выяснить для чего же конкретно это вообще нужно-то?
BFE>Сейчас, если сервер лёг, то — всё,
чо?! Фермы вер-серверов и cdn это не один сервер.

BFE>·>Это не костыли, а вполне себе самая адекватная реализация фичи.
BFE>Точно не бага?
Точно.

BFE>·>Тут уже цепочка доверия.
BFE>И чем, принципиально, "тут" отличается от предлагаемой схемы? Цепочка всегда есть.
В emule — peer-to-peer. За то что делает каждый peer — ты никак не контролируешь, и всё анонимно. А ещё и всякие зловреды, DDoS-атаки какие-нибудь...

BFE>·>Но до какого-то предела можно найти ответственных и призвать к отвественности.
BFE>Скорее всего, нет, нельзя.
BFE>Да и как можно призвать к ответу за то, что вам не известно?
Мне известно имя dns, можно найти владельца, как минимум для некоторых имён. Я знаю кто отвечает за содержимое какого-нибудь условного google.com. Если я не знаю кто такой warez.io, то понимаю, что рискую.

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

O>Каждой странице свою виртуальную машину с WinXP, пусть скачивает туда бинарники на C++ и C#.

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

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

vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
Ну, проблема веба номер 1 — 4 байта на IP адрес, что мало. Когда перейдут нормальнор на v6 — хз. А так эти NAT костыли влияют в том числе и на скорость и мешают создание именно что децентрализованных сетей.

А так, все остальное вроде как вполне нормально. У меня особо ничего не тормозит и вполне доволен. Даже на железе 15 летней давности могу без проблем пользоваться инетом. Единственное что на том железе если видео смотреть на FullHD с двукратном ускорением, то начинаются лаги и приходится либо уменьшать разрешение, либо пользоваться обычной скоростью.

А так, вся эта любовь к лучшему в мире языку программирования JS, на котором молодежь предлагает писать в том числе и бекэнд, а то и вообще операционные системы — это пройдет. И это достаточно легко поправить даже сейчас, перейдя на WebAssembly хотя бы, а то и ему замену можно придумать, не вопрос.

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

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

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

G>>Здравствуйте, Baiker, Вы писали:
B>>>А в IE 3.0 без скриптов он будет работать?

G>>Не будет. А должен?

B>Должен. Но не потому, что "люди сидят в IE", а потому, что IE — это просто! Это минималистичный набор инструментов, который ЛЕГКО РЕНДРИТЬ и не закапываться в тонны JS/CSS.
Неубедительно.

B>Строго говоря, RSDN вообще спокойно может прожить без единой строчки JS. ЗАЧЕМ ОН ТУТ??
Точно? Главная будет работать? Деревья будут раскрываться?

B>Плюс, если чел будет общаться через смарт, ему не нужны будут гигабайтные телефоны — на простом iPhone-2 можно запросто читать/писать.
Да и сейчас RSDN на слабом канале работает неплохо.

B>Если посмотреть на тулбар окна редактирования сообщения, то в принципе это и есть тот набор, который должен использоваться при вёрстке сайта! Жирный, италик, картинки, списки... что вам ещё нужно?? HTML уже вам всё дал — посмотрите, сколько всего можно засунуть между <form></form>! Но нет, люди изгаляются, строчат 100-строчные CSS, лезут в каждый элемент со своими стилями... оно мне надо? Просто сделай <button type="submit"> — всё, я буду счастлив!
Ты будешь, другие — нет. Да и как предпросмотр сделать только с <button type="submit"> ?

B>Не так сложен веб, как буйна фантазия разрабов. Сайт должен ориентироваться в первую очередь на простоту (влекущую малый объём и скорость) и только потом на красоту.
Аминь.

Только при чем тут IE 3 ?
Ты ошибочно думаешь, что если сайт заработает в IE3, то он заработает и более новых браузерах. Это верно лишь отчасти, для маленького подмножества HTML и CSS. Но этих возможностей категорически не хватит чтобы RSDN заработал даже с 30% функций.
А если сделать 100% функций RSDN в IE3, то это все не заработает в современных браузерах.

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

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

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

В том-то и дело, что веб перестал быть вебом, а превратился в виртуальную машину, в которую загружается сайт.
Вот лучше бы веб оставался ГИПЕРТЕКСТОВЫМ. А не аппликацией для браузера.

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

B>>Должен. Но не потому, что "люди сидят в IE", а потому, что IE — это просто! Это минималистичный набор инструментов, который ЛЕГКО РЕНДРИТЬ и не закапываться в тонны JS/CSS.
G>Неубедительно.

Напиши HTML-рендерер для стандарта 1.0 и 5.0 — сам убедишься, насколько это разные задачи!

B>>Строго говоря, RSDN вообще спокойно может прожить без единой строчки JS. ЗАЧЕМ ОН ТУТ??
G>Точно? Главная будет работать? Деревья будут раскрываться?

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

G>Ты будешь, другие — нет. Да и как предпросмотр сделать только с <button type="submit"> ?
Невелика задача. Неужели кто-то додумался её делать на JS?! Превью элементарно делается в отдельном окне (не мешая редактору), где текст коммента отсылается на сервер, санитайзится и выдаётся готовый СТАТИЧЕСКИЙ html. Чё тут сложного-то?

B>>Не так сложен веб, как буйна фантазия разрабов. Сайт должен ориентироваться в первую очередь на простоту (влекущую малый объём и скорость) и только потом на красоту.
G>Аминь.
Вот именно. Современное говно только хоронить, ибо изменению не подлежит.

G>Только при чем тут IE 3 ?

Как упрощённая аналогия "взять минимальный HTML движок". Не нравится IE — возьми Mosaic!

G>Ты ошибочно думаешь, что если сайт заработает в IE3, то он заработает и более новых браузерах

Тем хуже для сайта.

G> Это верно лишь отчасти, для маленького подмножества HTML и CSS. Но этих возможностей категорически не хватит чтобы RSDN заработал даже с 30% функций

Да господи, откуда столько пафоса?! Что твой РСДН такого делает, чего нельзя сделать на HTML 1.0??? Ты прям козла за иноходца продаёшь!
РСДН — это статьи и форум. Большинство фич делается вычислениями на сервере. И уж форумы — самое элементарное, что делали ещё на заре Тырнета!

3. Гипервизор

S>Т.е., как сказал один чел, браузер превратится в вирт. машину + графический движок.
Да, это неизбежно. От стороннего нативного кода в браузере (ActiveX, NaCl) в своё время отказались, ибо разломать всё к чертям не составляло никакого труда, сколько слоёв паллиативной псевдозащиты не наворачивай. Гипервизор, "кольца", и строго очерченные и стандартизированные ниточки системных вызовов к браузеру изменили бы печальную ситуацию.

V>В базе данных клиентская программа может хранить скачанные с серверной программы данные. Причём делать оно это может оптимальным образом, перезаписывая данные транзакциями, чтобы ускорить запись на порядок или даже порядки, а так же не насиловать лишний раз диск, в особенности SSD.

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

Как говорится, если очень захотеть, можно в суп нас..ть и съесть база данных тоже есть IndexedDB называется. Но да, надо сознательно захотеть использовать индексируемое хранилище, само себя оно не запустит.

fk0>Вот лучше бы веб оставался ГИПЕРТЕКСТОВЫМ. А не аппликацией для браузера.
А как тогда гигабайты дрыгающегося спама вкрячивать?

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

BFE>>·>Сервер должен хранить список запущенных в данный момент браузеров по всему миру? Трекать содержимое их кешей? Как?
BFE>>Серьёзно не понимаете?
BFE>>Если сервер секунду назад отослал пакет по адресу X, то наверное у X есть то, что ему отослали? Элементарно же. Нет?
·>Конечно, нет. Ты сетевые приложения никогда не разрабатывал что-ли?
Разрабатывал и разрабатываю.

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

·>Далее. Сервер за секунду отослал пакет тысяче клиентов. Он должен список из тысячи клиентов хранить? Где? Как долго?
В кэше. До вытеснения или изменения данных.

·>Каждый открытый порт — потенциальная дыра.
Каждое интернет соединение — потенциальный эксплоит.


·>Не у всех и не всегда.
И что с того?

·>В роуминге трафик ограниченный и дорогой.
Если человек не может себе позволить web, значит не может. Я не понял причём тут роуминг.

·>Придётся вместо одного запроса слать дубликаты. Увеличится нагрузка на сеть и количество round-trips — просядет производительность.
Пфф! В случае ошибок дубликаты и сейчас шлются.

BFE>>·>Потому что файлы большие. С одномегабайтными фоточками не пройдёт. Засеки сколько времени занимает выкачать 1мб из мула и 1мб с cdn-хостинга.
BFE>>Хмм. Затрудняюсь понять, как мне измерить это время.
·>Ну можно оценить по числу раунд-трипов и хопов. В случае cdn — запрос в dns (кешируемый), и один раундтрип до ближайшего cdn узла. В emule — не знаю, но думаю на порядок больше.
Это не время, это что-то другое. В случае peer-to-peer операции выполняются параллельно, так что их число может и не влиять на время.

BFE>>Сейчас, если сервер лёг, то — всё,
·>чо?! Фермы вер-серверов и cdn это не один сервер.
Вот именно, что серверы-то приходится дублировать.

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

BFE>>·>Тут уже цепочка доверия.
BFE>>И чем, принципиально, "тут" отличается от предлагаемой схемы? Цепочка всегда есть.
·>В emule — peer-to-peer. За то что делает каждый peer — ты никак не контролируешь, и всё анонимно.
Анонимно? В интернете нет ничего анонимного.

·> А ещё и всякие зловреды, DDoS-атаки какие-нибудь...
Вот и DDoS-атаки — это как раз не к peer-to-peer, а к современной архитектуре WEB.

BFE>>Да и как можно призвать к ответу за то, что вам не известно?
·>Мне известно имя dns, можно найти владельца, как минимум для некоторых имён.
Во-первых, нет, в общем случае найти владельца DNS нельзя (но какой-то контакт найти можно), но дело не в этом. Вы не знаете и не можете знать, что проходит в зашифрованном трафике через ваш компьютер. Да вы можете отследить с кем устанавливались соединения, но вот что передавалось — нет. Так что условный google.com может передавать через ваш браузер детское порно с одного web адреса на другой web адрес, но проверить, что он этого не делает возможности нет.

·>Я знаю кто отвечает за содержимое какого-нибудь условного google.com.
И кто же отвечает? И за что?

·>Если я не знаю кто такой warez.io, то понимаю, что рискую.
Нет, риск есть всегда.

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

BFE>·>X мог банально сломать или потерять пакет. Более того, даже одну секунду назад у X был пакет, через минуту его может не стать, т.к. кеш переполнится, например.
BFE>Ничего страшного.
Это значит будут дорогие cache misses и всё будет тормозить.

BFE>·>Далее. Сервер за секунду отослал пакет тысяче клиентов. Он должен список из тысячи клиентов хранить? Где? Как долго?
BFE>В кэше. До вытеснения или изменения данных.
Представь размер такого кеша для какого-нибудь популярного сайта.

BFE>·>Каждый открытый порт — потенциальная дыра.
BFE>Каждое интернет соединение — потенциальный эксплоит.
BFE>
Верно. Поэтому у тебя будет одно соединение с условным google.com, а не хз сколько с чужими браузерами.

BFE>·>Не у всех и не всегда.
BFE>И что с того?
Что неясно почему кто-то будет по своей воле загружать свой канал.

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

BFE>·>Придётся вместо одного запроса слать дубликаты. Увеличится нагрузка на сеть и количество round-trips — просядет производительность.
BFE>Пфф! В случае ошибок дубликаты и сейчас шлются.
Только в случае ошибок! Т.е. очень редко на практике, а ты предлагаешь всегда, притом многократно дублировать.

BFE>>>Хмм. Затрудняюсь понять, как мне измерить это время.
BFE>·>Ну можно оценить по числу раунд-трипов и хопов. В случае cdn — запрос в dns (кешируемый), и один раундтрип до ближайшего cdn узла. В emule — не знаю, но думаю на порядок больше.
BFE>Это не время, это что-то другое. В случае peer-to-peer операции выполняются параллельно, так что их число может и не влиять на время.
Не могут. Ты вначале должен найти пиров, договориться что у кого есть.

BFE>>>Сейчас, если сервер лёг, то — всё,
BFE>·>чо?! Фермы вер-серверов и cdn это не один сервер.
BFE>Вот именно, что серверы-то приходится дублировать.
Ты так и не ответил на вопрос "для чего же конкретно это вообще нужно-то?". А то в итоге получится, что серверы всё равно придётся дублировать.

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

BFE>>>И чем, принципиально, "тут" отличается от предлагаемой схемы? Цепочка всегда есть.
BFE>·>В emule — peer-to-peer. За то что делает каждый peer — ты никак не контролируешь, и всё анонимно.
BFE>Анонимно? В интернете нет ничего анонимного.
Анонимно в том смысле, что слишком дорого найти концы.

BFE>·> А ещё и всякие зловреды, DDoS-атаки какие-нибудь...
BFE>Вот и DDoS-атаки — это как раз не к peer-to-peer, а к современной архитектуре WEB.
Как ты решишь ddos в твоей архитектуре?

BFE>·>Мне известно имя dns, можно найти владельца, как минимум для некоторых имён.
BFE>Во-первых, нет, в общем случае найти владельца DNS нельзя (но какой-то контакт найти можно), но дело не в этом. Вы не знаете и не можете знать, что проходит в зашифрованном трафике через ваш компьютер. Да вы можете отследить с кем устанавливались соединения, но вот что передавалось — нет. Так что условный google.com может передавать через ваш браузер детское порно с одного web адреса на другой web адрес, но проверить, что он этого не делает возможности нет.
Зачем гуглу передавать с одного их хоста на другой их хост через мой браузер? Это бессмысленно, проще им будет передать напрямую. Поэтому неясно в чём риск.
В твоей "архитектуре" у тебя будет передаваться порно с сайта твоему соседу через твой браузер.

BFE>·>Я знаю кто отвечает за содержимое какого-нибудь условного google.com.
BFE>И кто же отвечает? И за что?
https://policies.google.com/

BFE>·>Если я не знаю кто такой warez.io, то понимаю, что рискую.
BFE>Нет, риск есть всегда.
Конечно, но риск — это не бинарная величина.

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

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

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

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

И это только те соединения, которые Firefox соизволил показать. А есть и другие...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

B>>>Должен. Но не потому, что "люди сидят в IE", а потому, что IE — это просто! Это минималистичный набор инструментов, который ЛЕГКО РЕНДРИТЬ и не закапываться в тонны JS/CSS.
G>>Неубедительно.

B>Напиши HTML-рендерер для стандарта 1.0 и 5.0 — сам убедишься, насколько это разные задачи!
Неубедительно что надо сайты делать исключительно под IE3

B>>>Строго говоря, RSDN вообще спокойно может прожить без единой строчки JS. ЗАЧЕМ ОН ТУТ??
G>>Точно? Главная будет работать? Деревья будут раскрываться?

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

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


G>>Только при чем тут IE 3 ?
B>Как упрощённая аналогия "взять минимальный HTML движок". Не нравится IE — возьми Mosaic!
Тут как нельзя кстати аксиома Эскобара.


G>> Это верно лишь отчасти, для маленького подмножества HTML и CSS. Но этих возможностей категорически не хватит чтобы RSDN заработал даже с 30% функций
B>Да господи, откуда столько пафоса?! Что твой РСДН такого делает, чего нельзя сделать на HTML 1.0??? Ты прям козла за иноходца продаёшь!
Я выше написал, но ты объявил это ненужным.

B>РСДН — это статьи и форум. Большинство фич делается вычислениями на сервере. И уж форумы — самое элементарное, что делали ещё на заре Тырнета!
Тем не менее rsdn не заработает в IE3. При этом работает весьма прилично как на телефоне, так и на компе.
Какой смысл ориентироваться на старые стандарты, если на новых можно сделать неплохо?