Здравствуйте, vsb, Вы писали:
vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
Отобрал бы у разработчиков навороченные компы и выдал бы каждому средний пользовательский терминал.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Не сайты медленные, а браузеры, которые как раз и есть десктопные приложения.
Сайт не может быть быстрым или медленным. Это всего лишь текст. Медленным может быть тот кто текст оьрабатывает
vsb>Десктопные приложения пошустрей работают. vsb>что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
Каждой странице свою виртуальную машину с WinXP, пусть скачивает туда бинарники на C++ и C#.
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают.
vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
1) сделать загрузку контента однопоточной.
на целероне с одним ядром cel 540M очень даже заметно )) как ютуб прогружается.
при этом сам ноут заточен под 64бит. недавно перестал грузиться с двумя плашками. теперь 890МБ + 128МБ видео.
все это 2008 года выпуска.
при этом убунта 2009 летает. xp летает. и даже IE летает(видимо потому что не умеет в многопоточность). правда не грузить почти ничего.
а вот ФФ 102 открывает ютуб минут 5 минимум. а вот видео без тормозов воспроизводится.
2) запретить делать рич контент.
никаких скриптов на клиенте. голый html. я бы даже css запретил. пусть будут только нативные контролы.
тогда гарантированно будет летать. и тут же очевидный плюс — сайт будет выглядеть так как удобно пользователю,
а не коммерсам и дизайнеру.
а сколько кислорода сбережем! привет гуглам и прочим зеленым реактивщикам.
никакой реактивности!
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают. vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
Я бы сделал быстрые сайты. При текущем уровне развития веба это сделать можно. RSDN же быстро работает.
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают.
vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
В том-то и дело, что веб перестал быть вебом, а превратился в виртуальную машину, в которую загружается сайт.
Вот лучше бы веб оставался ГИПЕРТЕКСТОВЫМ. А не аппликацией для браузера.
Здравствуйте, B0FEE664, Вы писали:
BFE>·>Потому что это сетевой вызов. BFE>С чего бы?
А какой ещё? Телепатический?
BFE>>>Для меня чем-то отличается www.google-analytics.com от чужого браузера? Да. google-analytics опаснее, так как он намного больше, чем отдельный никому неизвестный случайный браузер. BFE>·>Отличается. Я могу его целенаправленно заблокировать, например. Блокировать пиров — неясно как. Либо всё, либо ничего. BFE>Вы пробовали блокировать?
Открой для себя adblock.
BFE>>>И это только те соединения, которые Firefox соизволил показать. А есть и другие... BFE>·>Если ты не разбираешься в том, что у тебя на компе происходит, это не значит, что никто ничего не знает. BFE>Не значит, но есть те, кто говорит, что знает, а сами даже не пытались блокировать "подозрительный" трафик.
Ну во всяких крупных банках, например, стоят всякие zscaler и прочие, вплоть до тупого whitelists.
BFE>>>Если он не хочет загружать свой канал, то может установить себе прокси, который этим займётся. BFE>·>А зачем кто-то будет хотеть? BFE>А зачем кому-то пользоваться web-ом?
Ну порнушку смотреть например.
BFE>·>Затем, что ты так сам так предложил: "А запрос сразу ко многим идёт". BFE>Ну да. Вот, допустим, заходите на сайт, там 5 картинок, про которые сайт знает, что эти 5 картинок сервер только что (секунду назад) отдал вот тем 5-ти клиентам, о чём он и сообщает новому клиенту, а этот клиент уже спрашивает у тех о картинках. Ну и логично сразу от клиента направить запрос с дублированием для скорости в случае если один из клиентов не ответит.
Ок. Ты идёшь на сервер, который стоит в соседнем здании, между вами 10gb оптика, а эти другие 5 клиентов — мобильники в Австралии. Продолжать или сам хоть немного задумаешься?
BFE>>>Пиры известны от сервера. BFE>·>Телепатией? Или дополнительными сетевыми вызовами? BFE>Зачем телепатией? Зачем дополнительные сетевые вызовы? Сервер знает, кто к нему обращался.
Клиент не знает куда ему обращаться. А в http ладе есть keep alive, и есть возможность всё выкачать по тому же сокету.
BFE>·>Нет. Ты опять контекст забыл. Напоминаю, ты сказал, что "для коротких мессаджей, типа twitter это, понятно, не нужно.", но так и не написал для чего конкретно эта твоя архитектура нужна. BFE>Нужно для любого общего данного, чей размер не укладывается в один UDP пакет.
Ок. Для интернет-банкинга нужно? Скольким клиентам ты готов раздать информацию о своих счетах?
BFE>>>Не обязательно. Можно вообще сделать serverless архитектуру. Для получения данных это просто, а вот для передачи от клиента — очень сложно. BFE>·>А можно вообще чего угодно нафантазировать. Приводи конкретные сценарии. BFE>Ага. А следующим вопросом будет, ну покажи как ты это напишешь?
Нет, не будет.
BFE>·>Ага. И часто работают _поверх_ текущего веба. BFE>Протокол BitTorrent работает поверх веба?
Без веб-сайтов типа piratebay оно бессмысленно. И нужно оно для раздачи больших файлов. Вебу ну никак не поможет.
BFE>·>Это факт. В зависимости от того, нравится он тебе или нет — это может быть плохо или хорошо. BFE>Значит это не аргумент.
Не аргумент к чему?
BFE>·>То что ддосят сейчас. BFE>Сейчас ддосят исходные сервера.
У тебя тоже будет исходный сервер, сам же пишешь: "Вот, допустим, заходите на сайт, там 5 картинок".
BFE>·>Это ты приводишь идиотские аргументы. BFE>Это я придумал про детское порно?
Детское порно — валидный аргумент. Не все хотят пускать через себя произвольный трафик. Это реальный факт, нравится она тебе или нет.
BFE>·>В том, что это не моя проблема, а провайдера. BFE>А с чего это проблема провайдера?
А чья?
BFE>·>В том, что это может быть использован в суде с конкретным юридическим лицом, например. А так же репутационные риски и т.п. BFE>Нет, не может. Посмотрите на судебную практику.
Куча законов о персональных данных. И в целом — работают.
BFE>·>Не завязан. Можешь отвязаться, если вдруг надо. BFE>Нет, это невозможно практически.
Возмжоно, но не нужно практически.
BFE>>>А то, о чём вы пишите — это не управление рисками, это вера в большие структуры. BFE>·>Других вариантов нет. BFE>В том-то и дело, что есть.
Альтернативы — нет. Надо будет доверять хоть каким-то структурам в любом случае.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, B0FEE664, Вы писали:
BFE>Ну да. Вот, допустим, заходите на сайт, там 5 картинок, про которые сайт знает, что эти 5 картинок сервер только что (секунду назад) отдал вот тем 5-ти клиентам, о чём он и сообщает новому клиенту, а этот клиент уже спрашивает у тех о картинках.
А оттуда 5 байт в секунду или вообще тишина. И чо дальше? Ты только что зря потратил и канал и время.
BFE> Ну и логично сразу от клиента направить запрос с дублированием для скорости в случае если один из клиентов не ответит.
Т.е. вместо того, чтоб сразу взять с сайта, у которого канал толщиной с ногу и с которым у тебя уже установлено соединение, ты будешь рассылать запросы на деревню дедушке в надежде что у кого то из них окажется и нужная тебе хреновина и исходящий канал будет толще чем у сервака.
BFE>Зачем телепатией? Зачем дополнительные сетевые вызовы? Сервер знает, кто к нему обращался.
Вот только он не знает кто из них вообще ответит и к тому же ещё и отдаст нужную фиговину быстрее чем он сам.
BFE>Протокол BitTorrent работает поверх веба?
Не то чтобы поверх. Есть extensions которые умеют всяко подтягивать с HTTP но сам протокол к вебу не имеет отношения.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vaa, Вы писали:
vaa>1) сделать загрузку контента однопоточной.
Глупость. Без разницы, когда и как ты загрузишь допы, главное — чтобы браузер умел рендрить главную страницу до всяких картинок.
vaa>2) запретить делать рич контент. никаких скриптов на клиенте
Здесь абсолютно солидарен, скрипты на%ер не нужны. HTML — это гипертекст, он никогда не нуждался ни в какой динамике, это же паблишинг в чистом виде.
vaa> я бы даже css запретил
эээ! Ну ты это, выдыхай, бобёр! Не нужно впадать в крайности, CSS как раз много дал для ЛОГИЧЕСКОЙ вёрстки и реюзабельности.
Нам нужен "паблишинговый" WWW отдельно от "прикладного". Газеты, порносайты, блоги — всё спокойно верстается на HTML 1.0; Это и должен быть "мир гипертекста". А для "приложений в браузере", увы, мы опять придём к тому, что каждое недо-веб-приложение будет пытаться всё больше вылезти за пределы песочницы и "подёргать нативный API". Поэтому НАХРЕН все эти жабосрипты и вебассембли — берите C# и пишите нормальные MSIL-приложения! Они и на ведроиде смогут работать, и на линуксе, и в эппло-диктатуре.
Здравствуйте, gandjustas, Вы писали:
G>Неубедительно что надо сайты делать исключительно под IE3
IE просто как пример того, что было на заре Web'а. На деле весь этот трэд и есть обсуждение того, что современная паутина превратилось в говняную, медленную, разбухшую вермишель и рано или поздно она похоронит сама себя, а RSDN перепишут под html 1.0
B>>Конкретно на РСДН деревья не нужны (это вообще один из самых порочных элементов UI). Тут чё, дюже иерархический сайт? Пяток форумов (не нуждающихся в подфорумах), да статьи. Кому и за каким якодзуном понадобились деревья?! G>Если все ваше обоснование заключается в том, что "это не нужно", то дальше в общем нечего обсуждать.
Просто слился с темы. Так и запишем: "аргументов нет!".
G>То же самое дерево без JS хоть из возможно в теории (в реальности небольшой js все равно нужен), то это приведет к БОЛЬШЕМУ трафику между клиентом и сервером, так как для обновления состояния клиента придется перекачивать страницу целиком. Если эта страница форума с кучей данных из базы, то тормозить это будет очень сильно.
Форумы не вы и не вчера придумали — они жили ещё когда даже JS не было. И ничё, работало на ТЕХ(!) скоростях без проблем. Тут весь вопрос в usability, которая на РСДН хромает на обе ноги. Ты смотришь на сайт как на большую абстрактную кучу "всего полезного", я вижу лишь форум и статьи. И то, и другое можно значительно упростить, не пытаясь изображать из сайта какой-то фэйсбук (пафос и объём).
G>Я выше написал, но ты объявил это ненужным.
Не написал. Просто слился. Могу ещё раз повторить: РСДН можно сделать кратно проще. А заодно и прикрутить хранилище картинок.
G>Какой смысл ориентироваться на старые стандарты, если на новых можно сделать неплохо?
Ключевое слово не "старые", а "простые"! Весь веб сейчас — это одна большая, бестолковая помойка, которую периодически трясёт жабоскриптами. Этот маразм кончится, потому что это маразм. И вернёмся к Вебу как паблишингу и отдельным миром — веб-приложения. Ну, это моя оптимистичная фантазия технаря, а так веб-макаки могут ещё лет 20 свои говносайты накручивать. Дожили — простейший текст нельзя прочитать без долбаного жабоскрипта!! Позорище всем веб-лабателям.
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают. vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
Я считаю, что веб хорош как есть. Проблема в браузерах и в нежелании разработчиков сайтов заниматься оптимизацией своего кода.
Здравствуйте, Baiker, Вы писали:
B>Ну так предложи! Спрашивать любой дурак может!
Ну ок, вот мои мысли.
Прежде всего мне не хватит мозгов, чтобы действительно предложить что-то прорывное. Поэтому я попробую проанализировать разные варианты и сравнить их.
Итак, в чём суть проблем.
Начну с покомпонентного рассмотрения Web.
Web по моему мнению это TCP + TLS + HTTP + HTML + CSS + JS.
TCP + TLS + HTTP имеют некоторые известные проблемы. Эти проблемы решены переходом на UDP + QUIC. Вряд ли их можно решить лучше. Поэтому тут всё оптимизировано.
HTML это просто XML-подобный язык. В целом тут придираться особо не к чему. Про всякие семантические теги сейчас рассуждать не буду, к производительности это в любом случае не относится. Единственное, на чём можно остановиться — HTML это не строгий язык, причём в стандарте описано, как нужно парсить невалидный HTML. На мой взгляд это лишнее. Будь моя воля, я бы запретил все вольности. Всякие самозакрывающиеся теги, атрибуты без кавычек и прочее. Но, полагаю, что в разрезе производительности это ни на что не влияет.
CSS это штука сложная. Однозначно вижу одну из проблем веба именно тут.
Во-первых CSS заточен на страницу и не заточен на компоненты. В то время, как в программировании компонентный подход это, как говорится, наше всё.
Во-вторых в CSS собрано слишком много функционала. Я бы предложил его разделить как минимум на две части: собственно стили (шрифты, цвета, границы, тени и тд) и layout (размеры, флоаты, flex, grid и тд).
В-третьих layout движок в CSS по моему мнению настолько сложен, что мало людей вообще способны осознанно с ним работать. Понятно, что от наследия никуда не деться. Но если про него забыть, то layout было бы правильней создать с нуля, используя опыт мобильных приложений. Там с ним всё куда проще.
JS — тут сложный вопрос. С одной стороны язык однозначно неудачный. С другой стороны современные реализации его умеют выполнять с умопомрачительной скоростью. WebAssembly тут даёт некоторую альтернативу, хотя он и не доделан на мой взгляд. Не уверен, что если бы вместо JS был, к примеру Python, веб был бы лучше.
Таким образом могу только согласиться с мнением, что в браузере уже всё есть и ничего принципиально лучшего изобрести нельзя. Но веб тем не менее плох и не похоже, чтобы он становился лучше, несмотря на весь прогресс. То бишь ответа в улучшении каких-то отдельных компонентов веба не найти.
Рассмотрим мобильные приложения. Это относительно новое явление и они решают задачи, похожие на задачи, которые решают веб-приложения. В целом считается, что у них лучше UX и я с этим соглашусь. Хотя в теории я не вижу ничего, что мешало бы делать веб-приложения такими же удобными, как мобильные приложения, на практике большинство мобильных приложений удобней большинства веб-приложений. Значит что-то в них отличается.
Во-первых мобильные приложения, как правило, скачиваются сразу целиком. То бишь у пользователя есть раздельные фазы — сначала он скачивает сто мегабайтов непонятно чего и потом уже не скачивает. В веб-приложениях скачивание ресурсов обычно так или иначе размазано. Что приводит к тому, что страницы грузятся дольше.
Во-вторых в мобильных приложениях упомянутый layout сделан гораздо проще. Это тема большая и обширная, но сам факт остаётся фактом. Помимо прочего интерфейс в мобильных приложениях обычно проектируют визуальным редактором. В вебе до сих пор интерфейс в 99% случаев пишут текстом. Хотя дельфи была 30 лет назад. Это однозначно сказывается на скорости разработки.
В-третьих мобильные приложения используют заранее скомпилированный и более оптимизированный код. Тут вебу противопоставить нечего. Даже хвалёный webassembly требует относительно долгого времени для компиляции в native вид. Я не знаю, как "установить" сайт со 100 MB кода на webassembly и скомпилировать его в x64 один раз, чтобы потом пользоваться им без задержек при запуске. На маленьких примерах это не заметно, на больших объёмах компиляция начинает занимать ощутимое время. Тут можно ожидать прогресса в браузерах, к примеру подхода, как в Java — сначала работаем интерпретатором и компилируем только "горячие" функции, причём в фоне. Но всё равно это будет не так эффективно, как с мобильными приложениями. Ну или браузеры научатся кешировать скомпилированный машинный код, наверное это не должно быть так уж сложно.
Если резюмировать, что бы я сделал по-другому:
Сам формат HTML был создан для документов, а не для приложений. То бишь лучше всего вообще забыть про него, если речь идёт про приложения. А создать параллельный стек технологий, работающий в том же браузере.
Приложение должно определяться, как группа ресурсов. При первом открытии приложения вся группа ресурсов должна скачиваться. Обновление не должно быть обязательным, у пользователя должна быть возможность использовать старую версию приложения и обновляться по желанию. К примеру я стою на светофоре и запустил навигатор. Мне нужно, чтобы он запустился моментально, а не скачивал 150 мегабайтов новой версии.
Код должен доставляться как webassembly и сразу по завершении доставки компилироваться и сохраняться в нужных кешах, при повторных запусках код должен сразу выполняться. WebAssembly должен быть доработан, к примеру должна быть поддержка GC со стороны браузера, должен быть прямой доступ к вызовам API, в целом эта работа ведётся и сейчас, просто надо на ней сфокусироваться и всё доделать.
Для интерфейса должен использоваться отдельный язык разметки. XML-подобный, но никакой семантики. Простой и минималистичный. С хорошей поддержкой компонентов.
Для стилизации должны использоваться темы. Что-то вроде CSS. В целом стилизация должна делаться внутри компонента, а тема задаёт некие входные параметры для стилей.
Для layout должен использоваться отдельный механизм. Для вдохновения можно посмотреть на готовые решения из iOS, Android, Flutter, React Native.
Есть соблазн дать приложению пустой canvas и сказать: рисуй как хочешь. А там фреймворки разберутся. Но считаю это неправильным подходом. Браузер будет работать быстрей, чем код в песочнице. А также есть такие моменты, как accessibility, которые проще обеспечивать, имея унифицированный подход к интерфейсу. Extensions тоже своё место в вебе имеют.
Также нужно продумать многопоточность. Современная программа должна её использовать более активно. В современном вебе с этим тухловато. Ну тут вопрос больше к WebAssembly, наверное. В общем должна быть возможность легко убирать код в фоновый поток и получать результаты. Также layout и DOM должны быть полностью асинхронными и использовать многопоточность по максимуму. Обработка пользовательского ввода должна вестись в отдельном потоке, у кода приложения не должно быть возможности "заморозить" или хоть как-то повлиять на интерфейс.
Также нужно продумать хороший API для анимаций, плавные анимации это очень важная часть в восприятии пользователями скорости работы приложения, а удобный API это то, что позволит делать эти анимации без лишних усилий. Ну тут, думаю, тоже особо выдумывать ничего не надо, посмотреть, как сделали другие и взять лучшее. Тут я не особо разбираюсь, честно говоря, понимаю только то, что это важно.
Здравствуйте, ·, Вы писали:
vsb>>·>А почему managed в вебе не взлетел? Типа JVM? Почему не смогли аналог java-апплетов до ума довести? vsb>>У Java безопасность была неудовлетворительная. Постоянно находили эксплоиты. Флеш Джобс решил в айфоне не поддерживать, наверное это был последний гвоздь, хотя там тоже с безопасностью вроде было не супер. ·>Понятно, что были дыры в конкретных реализациях. Непонятно почему сам подход с верифицируемым байт-кодом не взлетел. Или просто что первое выстрелило, то и прижилось?
Ну WebAssembly можно считать следующей попыткой по сути. А так — хз, попыток наверное не особо много было. Внутрь браузера никто не пускает. Подходы вроде апплетов, сильверлайта требуют установки плагинов, зачастую обвешаны окошками подтверждения, в общем это не тот пользовательский опыт, который бизнес хочет видеть.
Здравствуйте, B0FEE664, Вы писали:
vsb>>А вот что бы вы сделали по-другому? BFE>Я бы сделал его децентролизованным, как eMule. Ничто не мешает каждому браузеру раздавать из кэша куски неизменяемых данных.
Зачем это делать браузеру? Для этого есть кеширующие прокси и cdn.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, B0FEE664, Вы писали:
BFE>Я бы сделал его децентролизованным, как eMule. Ничто не мешает каждому браузеру раздавать из кэша куски неизменяемых данных.
Более того, это дыра в privacy и безопасности. Можно будет видеть что у кого в кешах личного браузера.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Более того, это дыра в privacy и безопасности. Можно будет видеть что у кого в кешах личного браузера.
Или нельзя, если данные идут не напрямую.
Здравствуйте, B0FEE664, Вы писали:
BFE>·>Зачем это делать браузеру? BFE>Чтобы разгрузить сервера.
Давай подробнее. Вот захожу я фоточки поглядеть, новости почитать, в форуме пофлеймить. Как найти у кого уже есть такие же фоточки? Как запросить сквозь всякие всевозможные firewalls? А что если запрос потеряется, какой у меня будет latency? Ждать по пол минуты пока 10кб файлик найдётся?
emule это всё-таки для раздачи больших файлов. Закинул закачку, пришел завтра — оно выкачано. Как это ложиться на какой-нибудь новостной сайт, twitter, блог, интернет-магазин, etc — неясно.
BFE>·>Для этого есть кеширующие прокси и cdn. BFE>Вот именно.
И?
BFE>·>Более того, это дыра в privacy и безопасности. Можно будет видеть что у кого в кешах личного браузера. BFE>Или нельзя, если данные идут не напрямую.
И тебе будет ок, если твой браузер будет прокачивать какое-нибудь условное детское порно через твой комп?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·> Как найти у кого уже есть такие же фоточки?
Сервер знает.
Ещё можно по UUID сделать.
·>Как запросить сквозь всякие всевозможные firewalls?
Вот если бы я делал веб firewall'ам пришлось бы открывать некоторые порты на вход.
·>А что если запрос потеряется, какой у меня будет latency? Ждать по пол минуты пока 10кб файлик найдётся?
А запрос сразу ко многим идёт, как и сейчас (в eMule).
·>emule это всё-таки для раздачи больших файлов. Закинул закачку, пришел завтра — оно выкачано.
Не, чем больше скачивающих, тем выше скорость.
·>Как это ложиться на какой-нибудь новостной сайт, twitter, блог, интернет-магазин, etc — неясно.
Да так же, но для коротких мессаджей, типа twitter это, понятно, не нужно.
BFE>>·>Для этого есть кеширующие прокси и cdn. BFE>>Вот именно. ·>И?
Если бы я проектировал веб, то эти костыли были бы не нужны.
·>И тебе будет ок, если твой браузер будет прокачивать какое-нибудь условное детское порно через твой комп?
Вполне может быть, что и сейчас это происходит — я же не контролирую все возможные ресурсы интернета, к которым обращается браузер, когда я захожу на https://rsdn.org.
Можно подумать, что вы побайтово контролируете весь трафик проходящий через ваш компьютер...
Здравствуйте, ·, Вы писали:
·>Сервер должен хранить список запущенных в данный момент браузеров по всему миру? Трекать содержимое их кешей? Как?
Серьёзно не понимаете?
Если сервер секунду назад отослал пакет по адресу X, то наверное у X есть то, что ему отослали? Элементарно же. Нет?
BFE>>·>Как запросить сквозь всякие всевозможные firewalls? BFE>>Вот если бы я делал веб firewall'ам пришлось бы открывать некоторые порты на вход. ·>Т.е. открывать новые дыры в безопасности? Не, спасибо.
Зачем открывать дыры? Порт можно отрыть, а вот дыры — зачем?
·>А главное зачем? С какого перепугу васе пупкину хотеть забивать свой исходящий канал?
Ну так простаивает же.
·>А если у него трафик мобильный и дорогой роуминг?
А я помню время, когда и входящий был платный.
Причём тут роуминг?
·>На масштабах текущего веба всё тихо ляжет.
С чего бы?
·>Потому что файлы большие. С одномегабайтными фоточками не пройдёт. Засеки сколько времени занимает выкачать 1мб из мула и 1мб с cdn-хостинга.
Хмм. Затрудняюсь понять, как мне измерить это время.
·>Осталось выяснить для чего же конкретно это вообще нужно-то?
Сейчас, если сервер лёг, то — всё, а при распределённой модели всё продолжит работать.
·>Это не костыли, а вполне себе самая адекватная реализация фичи.
Точно не бага?
·>Тут уже цепочка доверия.
И чем, принципиально, "тут" отличается от предлагаемой схемы? Цепочка всегда есть.
·>В целом, да. Не побайтово, конечно.
Не верю.
·>Но до какого-то предела можно найти ответственных и призвать к отвественности.
Скорее всего, нет, нельзя.
Да и как можно призвать к ответу за то, что вам не известно?
Здравствуйте, Osaka, Вы писали:
O>Каждой странице свою виртуальную машину с WinXP, пусть скачивает туда бинарники на C++ и C#.
Вот, да, все к тому и идет. Весь гемор от того, что веб задумывался для отображения текста, а реально рынок стал тяготеть к полноценному десктоп-функционалу.
Типа как если изначально проектировали самолет, но все больше используют для землеройных работ.
Здравствуйте, B0FEE664, Вы писали:
BFE>·> Как найти у кого уже есть такие же фоточки? BFE>Сервер знает. BFE>Ещё можно по UUID сделать. Да хоть по хэшу.
Поди угадай у какого DHCP юзера, сидевшего за NAT оно там было.
BFE>·>Как запросить сквозь всякие всевозможные firewalls? BFE>Вот если бы я делал веб firewall'ам пришлось бы открывать некоторые порты на вход.
Нет, тебя бы просто послали нахрен с такими офигительными идеями.
BFE>А запрос сразу ко многим идёт, как и сейчас (в eMule).
Т.е. нагрузка возрастает чтоб добыть то же самое. Фтопку.
BFE>Не, чем больше скачивающих, тем выше скорость.
Чем больше раздающих а не скачивающих
И опять таки, пусть даже их 100500 но если канал у них так себе то CDN всяко лучше будет.
BFE>Если бы я проектировал веб, то эти костыли были бы не нужны.
Угу, он бы просто не взлетел.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Поди угадай у какого DHCP юзера, сидевшего за NAT оно там было.
Если бы веб был другой, то и NAT работал бы иначе.
CC>Нет, тебя бы просто послали нахрен с такими офигительными идеями.
Когда делали веб "посылать" было некому.
BFE>>А запрос сразу ко многим идёт, как и сейчас (в eMule). CC>Т.е. нагрузка возрастает чтоб добыть то же самое. Фтопку.
Нет. Чтобы получить разные часть от разных источников параллельно.
BFE>>Не, чем больше скачивающих, тем выше скорость. CC>Чем больше раздающих а не скачивающих
Нет! Именно, что чем больше скачивающих, тем выше скорость, так как каждый скачивающий == раздающий.
CC>И опять таки, пусть даже их 100500 но если канал у них так себе то CDN всяко лучше будет.
Нет, BitTorrent они не обгонят.
BFE>>Если бы я проектировал веб, то эти костыли были бы не нужны. CC>Угу, он бы просто не взлетел.
Сейчас всё больше переходят к этой архитектуре в том или ином виде, но теперь это сделать сложно из-за груза предыдущих подходов.
Здравствуйте, Osaka, Вы писали:
O>По той же причине, что десктопное приложение из многих dll а не 1 большой exe
Да всё как то больше 1 exe стараются делать везде где только это получается.
O> для возможности замены по частям.
Так никто не делает и на деле никому вообще не нужно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Дада, конечно!
Архитектурные особенности именно такие.
CC>Параллельность тут не даётся бесплатно, так что "платить" за одно и то же но присланое из 15 источников всё равно придётся.
Платить — да. но не скоростью передачи.
BFE>>Нет! Именно, что чем больше скачивающих, тем выше скорость, так как каждый скачивающий == раздающий. CC> Далеко не каждый раздающий раздаёт на хотя бы той же скорости, да и далеко не каждый скачавший остаётся на раздаче.
Даже с учётом того, что исходящая пропускная возможность каждого клиента меньше, чем входящая пропускная возможность каждого клиента, суммарная пропускная способность всех исходящих каналов клиентов выше, чем сервера.
Обычно потребители веб страниц не отрубаются от сети сразу после закачки страницы, так что минимум секунда ещё есть, этого достаточно.
CC>Так что нет. Всё зависит от раздающих а не качающих.
Обычно если скачивающий не раздаёт, то его блокируют.
BFE>>Нет, BitTorrent они не обгонят. CC>
А что смешного? По скорости протокол BitTorrent'а никто не обходит.
BFE>>Сейчас всё больше переходят к этой архитектуре в том или ином виде CC>Где, покажи пальцем на хоть что то реально работающее QUIC — вот шаг в данном направлении.
И вообще, distribution networks CDN работают именно на этой архитектуре. То, что эту технологию сегодня крайне сложно распространить на клиентскую часть — проблема начальной архитектуры веб.
Здравствуйте, B0FEE664, Вы писали:
BFE>·>Канал у типичного юзера, как правило, один. BFE>Так он у него так и так один.
Вот именно. Пакеты пойдут по тому же каналу и просядет перформанс.
BFE>>>Так при peer-to-peer для скорости нужен UDP с гарантией, на TCP всё будет тормозить. Вот поэтому QUIC — шаг в данном направлении. BFE>·>"UDP с гарантией" называется TCP, внезапно. BFE>Нет. TCP и QUIC — это два разных протокола "внезапно".
thus earning the QUIC protocol the occasional nickname "TCP/2".
Просто вариация TCP оптимизированная для определённых сценариев.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, karbofos42, Вы писали:
R>>Скриншот сообщения не может быть валидным, потому что его можно подделать. Пересланное сообщение подделать нельзя. K>Ну, в моём понимании, если что-то прямым путём нельзя сделать, но можно окольными путями — это уязвимость. K>Если я заблокировал пересылку сообщений, то вероятно я хочу, чтобы они ни к кому больше не попали,
Чтобы кому-то попали ссылки их надо явно переслать.
K>а не так, что их можно посмотреть по ссылке, потому что у кого-то там какая-то концепция
Ссылка не появится сама по себе ниоткуда.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, karbofos42, Вы писали:
K>·>Такое "счастье" можно обеспечить просто соответствующей настройкой сертификатов в браузере. Но это неюзабельно в масштабах веба. K>Неюзабельно = нельзя, т.к. никто это делать не будет.
Собственно оно и будет работать подобно десктопу. Поэтому и веб популярнее, т.к. более юзабелен.
K>·>Нет, не вижу С т.з. пользователя это какие-то неясные кнопки, которые нужно просто всегда нажимать чтобы всё заработало. Ведь все эти кнопки уже привычно нажимались при установке другого софта, а иногда и просто при обновлении или установке на других устройствах. K>Только у пользователя может не быть прав на установку ПО, а вот перейти на рандомный сайтик ему никто не запретит.
Я вроде zscaler уже упоминал. И прочие проксяки.
K>·>Думаешь почему всякие activex сдохли? Ведь там тоже надо было кучу страшных кнопок нажимать, типа для секьюрности... K>Их было неудобно делать и они были дырявые. Только я не понял причём тут они. ActiveX — это скорее подгрузка стороннего ПО в свой процесс, что уже идеологически не выглядит безопасно.
Это детали. его можно подгружать и в отдельный процесс, но проблема та же — неконтролируемый бинарник.
K>Расскажешь в чём секьюрность страдает, если по ссылке откроется не универсальный браузер, а специализированное приложение и каким боком тут ActiveX?
Ты умалчиваешь момент распространения установки этих самых специализированных приложений. Именно это и "Неюзабельно = нельзя, т.к. никто это делать не будет.".
ActiveX — это как раз попытка сделать лёгкий способ доставки приложений. Ещё можно вспомнить java web start и подобнеые исторические казусы.
K>·>Как я понял, ты предлагаешь переводить какие-то приложения из веба в десктоп. Если я не правильно тебя понял, то плз сформулируй свой тезис. K>Я предлагаю сделать более удобный кроссплатформенный десктоп, чтобы люди охотнее под него писали, а не как сейчас — по остаточному принципу.
Я понимаю, что ты против всего плохого и за всё хорошее. Но ты как-то умалчиваешь детали, как же этого добиться? Пишут по остаточному принципу потому, что десктоп это фактически "неюзабельно = нельзя".
K>·>Точнее сказать, что если в десктопе урлы таки есть, то он становится удобнее. В пример та же телега — возможность послать сообщение как урл — очень полезна. Я телегу никогда не ставил и вообще в глаза не видел, но если кто-то мне кинет урл, я смогу прочитать без всяких "нужно что-то установить, выдать права и т.д.". K>Но, между тем, телега есть десктопная и она более функциональна.
Но десктопная телега была бы никому не нужна без веб-версии.
K>Напоминаю, что я про урлы вообще ничего не говорил и это ты мне начал рассказывать, что десктоп плохо, т.к. в нём нет урлов и нельзя на что попало ссылаться.
Ты всё перепутал. Наоборот, проблема что на десктоп ссылаться нельзя (твой пример с 1С это фейспалм какой-то). Поэтому нужна именно в первую очередь веб-аппликуха, а потом уж ценителей и профессионалов заманивают в десктоп дополнительной функциональностью.
K>·>Именно что _условно_. K>Условно, потому что какая-нибудь Java или .NET — это не нативные приложения.
Это какой-то не тот контекст. Тут нативность важна лишь в том, что у типичных десктопных приложений больше возможностей, т.к. доступно, как правило, больше, чем в браузере.
Если ты начнёшь устраивать песочницы и магазины как ты собирался, то в итоге это преимущество исчезнет. В итоге получится тот же самый веб по возможностям, но ограниченный недостатками десктопа.
K>·>Т.е. у тебя по сути претензия только к js. Ок, согласен. Ждём wasm. K>Попробуй стартовое сообщение хотя бы прочитать в этой теме чтоли.
Там было про шустрость. Причём тот js неясно. Современный js умеет jit, поэтому не сильно отличается от нативщины. Главная проблема шустрости в вебе, что оно всё сетевое.
K>·>Это разве неочевидно? Сейчас у каждого приложения как правило есть сайт. Но не наоборот. Веб гораздо массивнее приложений. K>Ну, вот я и говорю, что бедных больше, чем богатых, значит бедные лучше.
Тут другая логика. Зачем платить больше, если можно платить меньше с тем же результатом?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, B0FEE664, Вы писали:
BFE>>>·>Канал у типичного юзера, как правило, один. BFE>>>Так он у него так и так один. BFE>·>Вот именно. Пакеты пойдут по тому же каналу и просядет перформанс. BFE>Да щаз! BFE>Вот тут он просядет, а вот тут — нет. Ну вот с чего бы, если передаются одни и те же данные?
Данные одни, но ты сам сказал, что надо будет посылать запрос нескольким клиентам, на случай если кто-то из них не ответит. Т.е. вместо одного запроса, надо будет слать несколько.
И ещё одна весёлость — если таки на запросы начнут приходит ответы от нескольких пиров — у тебя будут входящие дубликаты, пытаясь пролезть через тот же канал.
Иными словами, чтобы твоя система хоть как-то надёжно заработала хотя бы в идеальном случае, данные придётся многократно дублировать, что уменьшит пропускную способность канала.
А если ещё рассматривать malicious attacks, то "злые" пиры могут просто в ответ всякий мусор слать, ддося твой канал.
BFE>·>thus earning the QUIC protocol the occasional nickname "TCP/2". BFE>Мало ли как его обзывают, написан он поверх UDP.
Суть у него примерно та же, что у tcp.
BFE>·>Просто вариация TCP оптимизированная для определённых сценариев. BFE>Ну да. Для определённых сценариев.
И заметь, никаких peer-to-peer.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, B0FEE664, Вы писали:
BFE>·>thus earning the QUIC protocol the occasional nickname "TCP/2". BFE>Мало ли как его обзывают, написан он поверх UDP.
Кстати, написан он поверх UDP не от хорошей жизни, а для совместимости со существующей инфраструктурой. Добавлять поддержку нового протокола транспортного уровня в оборудование и софт всего мира займёт лет 200 как минимум.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, 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>Что-то подобное и сейчас есть, только у большинства компаний нет денег на десктопную версию и потому выжимают всё из веба и даже не пытаются делать нормальный десктоп.
Так ведь большинству компаний и не нужна десктопная версия.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sinclair, Вы писали:
S>Если мы заменяем JS на бинари, то упаковывать весь сайт в небольшое количество крупных кусков, которые быстро приезжают через торрентоподобный протокол, может оказаться выгоднее, чем резать его на тысячи килобайтных "скриптиков".
В современном вебе тысячи килобайтных скриптиков, css, gif, и т.п. пакуется с помощью webpack в удобное количество gzip-бандлов и выкладывается в cdn, с тонкой настройкой по топологии и географии Сети. Так что самые обыкновенные бинари с т.з. сети.
У торрента совсем другое предназначение. Это когда куча всяких пиров на хилых каналах, но с большими дисками пытаются хоть как-то чем-то обменяться.
В вебе же есть жирный ha-сервер и куча слабеньких клиентов на мобилках.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают. vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
1. Отвязаться от интерпретатора JS. WebAssembly — не плохое решение.
2. Добавить для WebAssembly полноценный доступ к DOM и видеокарте (на уровне GLSL).
Но вообще все к тому и идет — вопрос времени.
Т.е., как сказал один чел, браузер превратится в вирт. машину + графический движок.
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают.
Вы видели как работал flash. Так же и веб он утилизирует типовые ресурсы. Если они чуть ниже тормозит, если выше вроде терпимо.
Такое отношение к ресурсам.
vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
Что называется удобством. Что разработку можно разбить по разным узкоспециализированным специалистами и делать деньги.
Что бы что-то делать по другому надо сформулировать цели которых хочется достичь.
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают.
Давай для начала разделим.
1. Клиентская программа имеет базу данных.
2. Клиентская программа не имеет базы данных.
В базе данных клиентская программа может хранить скачанные с серверной программы данные. Причём делать оно это может оптимальным образом, перезаписывая данные транзакциями, чтобы ускорить запись на порядок или даже порядки, а так же не насиловать лишний раз диск, в особенности SSD.
Так вот особенность браузеров в том, что у них нет базы данных, у них есть кеш для данных. И поскольку они не знают схему данных, не имеют вспомогательных данных для блокировок, таких как оптимистические и прочие, то и обновить данные оптимальным образом они не могут.
А ещё в вебе нет разницы между данными и графикой, что при каждом запросе накладывает дополнительные расходы на получение данных.
Потому фактически есть всего лишь два выхода.
1. Создаётся какая-то особая клиент-серверная программа и она идеально управляет данными и их обменом как на сервере, так и на клиенте. В случае распределённой программы разницы между клиентом и сервером может как таковой и не быть.
2. Продолжаем использовать обычный веб. А это заметь тоже клиент-серверные программы, которые являются стандартом лишь потому, что их считают стандартом, а в реальности вместо них можно нагородить всё, что угодно. Но в этом случае уменьшаем поток данных, то есть оптимизируем веб. Убираем оттуда лишний текст, ненужные клиентские скрипты и прочее.
Думаю никто не будет спорить, что во втором варианте с вебом можно достичь выдающихся результатов насколько это возможно, когда каждый раз для обновления нужно отправлять запрос на сервер.
Вот только есть одно но, в первом случае программа может сохранять данные на клиенте или в случае распределённой программы клиент сервере. Причём оно может делать это с теми же веб-страничками, конечно по умному нужно сохранять содержимое, а не обрамляющую графику, скрипты, рекламу и прочий мусор.
В итоге программа, которая синхронизируется с сервером, а часть данных оптимально хранит в базе данных очевидно будет превосходить программу кэширующую случайные данные, такое как браузер. А как это сделать описано в книге Мартина Фаулера "Архитектура корпоративных программных приложений". Но то, что мы это знаем никак не отменит тот же традиционный веб.
И я ещё раз подчеркну следующее обстоятельство. Сам html и css это формат данных и это одно. Его можно хранить в базе данных той же распределённой программы. А вот http это совершенно другое. Проблема именно в http, не в html и css, потому и отказываться нужно будет от http, но не от html и css.
Теперь давай предположим, что некто создал вариант с распределённым обменом. Пользователю дали возможность настроек, сохранять ли только изменения, сохранять всё, ничего не сохранять, сохранять только просмотренное и так далее. У него есть возможность видеть занятые у него на диске данные и выборочно чистить всё, что он хочет с помощью мощного фильтра.
То есть мы дошли до стадии, когда можно хранить полные зеркала сайтов с одной стороны, и ничего не хранить с другой. И каждый раз формат данных оптимален без лишнего мусора, дублирований и прочего. Но теперь возник вопрос, нужно будет продвинуть эту технологию в народ.
А здесь мы приходим к тому, что какой-то браузер есть везде, но вот такой клиент-серверной программы может и не быть. Для заманивания всё равно придётся делать обмен по http со всеми его минусами. Так же эплы могут посчитать, что такой программе не место на их платформе. Тоже самое с сони, нинтендо и прочими.
И только, если создатель интернет ресурса создаст его на этом движке, а пользователи скачают клиент, опять же в случае распределённого приложения они скачают тоже, что установлено на сервере, то есть клиент-сервер в одном флаконе, только тогда появятся все те самые эффективные особенности, которых нет в http.
Фактически нужно создать CMS, причём оптимальным выбором будет C++, которая заменит как сервер, так и клиент. А сама она ко всему прочему будет воплощать как протокол распределённого обмена, так и традиционный файловый и http доступ. Вот насколько эта CMS распространится, настолько и удачным будет замена или дополнения традиционного http.
И ещё раз повторюсь html и css вполне можно продолжить использовать в полях документа, даже если отображение идёт с помощью сторонних виджетов десктопного приложения, наглядный пример Qt. А как создать разные виды для десктопа и веб так же описано в той же книге Мартина Фаулера.
Потому думаю финальный ответ на твой вопрос новый вид CMS, что, кстати, вполне доступно очень крутым разработчикам C++, коих мало и к коим лично я не отношусь, но всё же.
Здравствуйте, Нomunculus, Вы писали:
Н>Не сайты медленные, а браузеры, которые как раз и есть десктопные приложения. Н>Сайт не может быть быстрым или медленным. Это всего лишь текст. Медленным может быть тот кто текст оьрабатывает
Ведущий разработчик Яндекс.Деньги Андрей Мелихов (также редактор/переводчик сообщества devSchacht) на примере движка V8 рассказывает о том, как и через какие стадии проходит программа, прежде чем превращается в машинный код, и зачем на самом деле нужен новый компилятор.
Напоминаю, что движок V8 используется в Chrome/Chromium и Node.js.
УП>Отобрал бы у разработчиков навороченные компы и выдал бы каждому средний пользовательский терминал.
Сразу видно, что учил в институте философию еще в СССР...
Бытие определяет сознание — оно самое и есть!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Сразу видно, что учил в институте философию еще в СССР... LVV>
Не, не дорос я тогда до изучения философии, еще в школе учился, когда СССР не стало.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
LVV>>Сразу видно, что учил в институте философию еще в СССР... УП>Не, не дорос я тогда до изучения философии, еще в школе учился, когда СССР не стало.
Вот она — советская школа!
Как мои первые выпуски 1999-2003 года — все в советской школе учились, все умные!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
O>>Чтобы все сайты стали пальцем деланные? УП>Колхозный фронтэндщик в теме? Да, лучше пальцем, чем тем местом, которым вы код пишете.
Почему у тебя от этой фразы так взбомбануло?
We made a server-less virtual Linux environment that runs unmodified Debian binaries in the browser. This is powered by CheerpX, a WebAssembly virtualization platform.
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают.
vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
Ну вот возьмем для примера MAUI, Flutter, React Native. В том же направлении надо двигаться и браузерам c Webassembly.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают.
А почему managed в вебе не взлетел? Типа JVM? Почему не смогли аналог java-апплетов до ума довести?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
vsb>>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают. ·>А почему managed в вебе не взлетел? Типа JVM? Почему не смогли аналог java-апплетов до ума довести?
У Java безопасность была неудовлетворительная. Постоянно находили эксплоиты. Флеш Джобс решил в айфоне не поддерживать, наверное это был последний гвоздь, хотя там тоже с безопасностью вроде было не супер.
Здравствуйте, vsb, Вы писали:
vsb>>>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают. vsb>·>А почему managed в вебе не взлетел? Типа JVM? Почему не смогли аналог java-апплетов до ума довести? vsb>У Java безопасность была неудовлетворительная. Постоянно находили эксплоиты. Флеш Джобс решил в айфоне не поддерживать, наверное это был последний гвоздь, хотя там тоже с безопасностью вроде было не супер.
Понятно, что были дыры в конкретных реализациях. Непонятно почему сам подход с верифицируемым байт-кодом не взлетел. Или просто что первое выстрелило, то и прижилось?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Понятно, что были дыры в конкретных реализациях. Непонятно почему сам подход с верифицируемым байт-кодом не взлетел. Или просто что первое выстрелило, то и прижилось?
Неправильный подход к безопасности. java runtime api спроектировано для работы без ограничений, и в нем понатыкано проверок на права. JS пошел с другой стороны — API изначально спроектировано для работы в песочнице. Флеш по-моему на те же грабли наступил.
Здравствуйте, Baiker, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>Я бы сделал быстрые сайты. При текущем уровне развития веба это сделать можно. RSDN же быстро работает.
B>А в IE 3.0 без скриптов он будет работать?
Не будет. А должен? Много пользователей RSDN сидит на IE 3? Я думаю примерно ноль.
vsb>Прежде всего мне не хватит мозгов, чтобы действительно предложить что-то прорывное. Поэтому я попробую проанализировать разные варианты и сравнить их.
Ну, не прибедняйся уж так. На самом деле причина просто выпирает из веба своими бородавками: противоречие между вебом в изначальной задумке (как ГИПЕРТЕКСТ, т.е. паблишинг с переходами) и его современным применением для ИМИТАЦИИ приложений, но через убогую веб-страничку. И кстати далее ты это упомянул.
vsb>Будь моя воля, я бы запретил все вольности. Всякие самозакрывающиеся теги, атрибуты без кавычек и прочее. Но, полагаю, что в разрезе производительности это ни на что не влияет.
Ещё как влияет!! Попробуй написать движок для "вольного HTML" и для строгого XML — очевидно, что последний будет стократ надёжнее и быстрее.
vsb>CSS это штука сложная
+1, его надо сократить до уровня "цвет-шрифт-отступы" и этого будет достаточно за глаза.
vsb>В-третьих layout движок в CSS по моему мнению настолько сложен
Его там вообще не должно быть. Лэйаут — это к HTML. Внешний вид — CSS.
vsb>JS — тут сложный вопрос
Вообще не сложный. JS must die. Кто не согласен, пусть сожрёт ведро горчицы.
vsb>Таким образом могу только согласиться с мнением, что в браузере уже всё есть и ничего принципиально лучшего изобрести нельзя
Ровно наоборот — в браузере реализована такая ПОМОЙКА технологий, что даже бывалые зубры не отважатся создать браузер с нуля. А что уж творится внутри Chromium даже сами разрабы хромого не все понимают.
vsb>Рассмотрим мобильные приложения
Не хочу. Они сюда вообще никаким боком.
vsb>Сам формат HTML был создан для документов, а не для приложений. То бишь лучше всего вообще забыть про него, если речь идёт про приложения. А создать параллельный стек технологий, работающий в том же браузере.
ВОТ! Здравая мысль. Отделить обезьян-жабописак от паблишинга и вернуть Вебу былую скорость и компактность.
А для приложений — я уже писал, Silverlight был прекрасной технологией. Но она не имеет смысла В БРАУЗЕРЕ. Поэтому инсталлируем везде .NET Framework и не ипём мозга — всё канпеляем в MSIL и вообще не паримся.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Baiker, Вы писали: B>>А в IE 3.0 без скриптов он будет работать?
G>Не будет. А должен?
Должен. Но не потому, что "люди сидят в IE", а потому, что IE — это просто! Это минималистичный набор инструментов, который ЛЕГКО РЕНДРИТЬ и не закапываться в тонны JS/CSS.
Строго говоря, RSDN вообще спокойно может прожить без единой строчки JS. ЗАЧЕМ ОН ТУТ??
Плюс, если чел будет общаться через смарт, ему не нужны будут гигабайтные телефоны — на простом iPhone-2 можно запросто читать/писать.
Если посмотреть на тулбар окна редактирования сообщения, то в принципе это и есть тот набор, который должен использоваться при вёрстке сайта! Жирный, италик, картинки, списки... что вам ещё нужно?? HTML уже вам всё дал — посмотрите, сколько всего можно засунуть между <form></form>! Но нет, люди изгаляются, строчат 100-строчные CSS, лезут в каждый элемент со своими стилями... оно мне надо? Просто сделай <button type="submit"> — всё, я буду счастлив!
Не так сложен веб, как буйна фантазия разрабов. Сайт должен ориентироваться в первую очередь на простоту (влекущую малый объём и скорость) и только потом на красоту.
Здравствуйте, scf, Вы писали:
scf>·>Понятно, что были дыры в конкретных реализациях. Непонятно почему сам подход с верифицируемым байт-кодом не взлетел. Или просто что первое выстрелило, то и прижилось? scf>Неправильный подход к безопасности. java runtime api спроектировано для работы без ограничений, и в нем понатыкано проверок на права. JS пошел с другой стороны — API изначально спроектировано для работы в песочнице. Флеш по-моему на те же грабли наступил.
Ну в браузерах по итогу та же модель, например, firefox в about:config, pref/lockPref и по всему коду проверки на установленность соответствующих ключей конфига.
Аналог java.lang.SecurityManager по сути...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Не знаю. Может веб это ошибка. Сейчас большинство людей используют смартфоны, где принято скачивать и использовать приложения. Кто знает, может это и есть правильный путь?
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают. vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому?
Как в мобилках — сайт не нужен.
Нужен сервис и приложение к нему.
Или как изначально задумывались Java-апплеты и .Net — подгружаемая исполняемая прога.
Хорошую идею сгубили недостатки безопасности...
Здравствуйте, 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>Можно подумать, что вы побайтово контролируете весь трафик проходящий через ваш компьютер...
В целом, да. Не побайтово, конечно. Но до какого-то предела можно найти ответственных и призвать к отвественности.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, 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, то понимаю, что рискую.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, 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, то это все не заработает в современных браузерах.
Здравствуйте, 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 называется. Но да, надо сознательно захотеть использовать индексируемое хранилище, само себя оно не запустит.
Здравствуйте, ·, Вы писали:
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. При этом работает весьма прилично как на телефоне, так и на компе.
Какой смысл ориентироваться на старые стандарты, если на новых можно сделать неплохо?
Здравствуйте, 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 впрочем всё равно жутко неюзабельный, единственный нормальный способ читать кывт — оффлайновый клиент.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, B0FEE664, Вы писали:
BFE>Если сервер секунду назад отослал пакет по адресу X, то наверное у X есть то, что ему отослали? Элементарно же. Нет?
И такиж в общем случае нет.
BFE>Ну так простаивает же.
С чего ты взял?
BFE>Сейчас, если сервер лёг, то — всё, а при распределённой модели всё продолжит работать.
Просто поставь себе клиент IPFS и полюбуйся как оно безумно медленно работает. А ведь это именно то, что ты тут предлагаешь.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, B0FEE664, Вы писали:
BFE>·>Представь размер такого кеша для какого-нибудь популярного сайта. BFE>Сколько под кэш отведёшь, столько и будет.
Ну вот, начинаются проблемки.
BFE>·>Что неясно почему кто-то будет по своей воле загружать свой канал. BFE>Если он не хочет загружать свой канал, то может установить себе прокси, который этим займётся.
Начнём с того что все входящие на клиентских машинах будут тупо зарублены.
BFE>·>Только в случае ошибок! Т.е. очень редко на практике, а ты предлагаешь всегда, притом многократно дублировать. BFE>Зачем многократно-то?
У каждого пользователя же.
Кстати тебе ещё надо решить что делать с динамическим контентом и версионностью.
BFE>·>Не могут. Ты вначале должен найти пиров, договориться что у кого есть. BFE>Пиры известны от сервера.
А с чего ты взял что все они живы, имеют нужный тебе контент да и вообще доступны?
BFE>·>Ты так и не ответил на вопрос "для чего же конкретно это вообще нужно-то?". BFE>Вы меня спрашиваете зачем нужен веб?
Не веб (что подразумевает конкретную существующую имплементацию) а именно твоя идея реализации.
BFE>·>Анонимно в том смысле, что слишком дорого найти концы. BFE>Это плохо или хорошо?
BFE>А что вы собираетесь ddos'ить?
Да примерно как emule засирают троянами и спамом.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, B0FEE664, Вы писали:
BFE>·>Более того, это дыра в privacy и безопасности. Можно будет видеть что у кого в кешах личного браузера. BFE>Или нельзя, если данные идут не напрямую.
Твоя архитектура только что стала ещё кривее
Ты банально предлагаешь сделать из браузера некое подобие IPFS over TOR
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>С чего ты взял?
Таймауты по потерям пакетов никто не отменял.
BFE>>Сейчас, если сервер лёг, то — всё, а при распределённой модели всё продолжит работать. CC>Просто поставь себе клиент IPFS и полюбуйся как оно безумно медленно работает. А ведь это именно то, что ты тут предлагаешь.
Возможно. Надо будет посмотреть на реализацию. Надеюсь они на UDP работают.
Здравствуйте, B0FEE664, Вы писали:
CC>>Поди угадай у какого DHCP юзера, сидевшего за NAT оно там было. BFE>Если бы веб был другой, то и NAT работал бы иначе.
Дада, конечно!
BFE>>>А запрос сразу ко многим идёт, как и сейчас (в eMule). CC>>Т.е. нагрузка возрастает чтоб добыть то же самое. Фтопку. BFE>Нет. Чтобы получить разные часть от разных источников параллельно.
Параллельность тут не даётся бесплатно, так что "платить" за одно и то же но присланое из 15 источников всё равно придётся.
CC>>Чем больше раздающих а не скачивающих BFE>Нет! Именно, что чем больше скачивающих, тем выше скорость, так как каждый скачивающий == раздающий. Далеко не каждый раздающий раздаёт на хотя бы той же скорости, да и далеко не каждый скачавший остаётся на раздаче.
Так что нет. Всё зависит от раздающих а не качающих.
BFE>Нет, BitTorrent они не обгонят.
BFE>Сейчас всё больше переходят к этой архитектуре в том или ином виде
Где, покажи пальцем на хоть что то реально работающее
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vsb, Вы писали:
vsb>Если резюмировать, что бы я сделал по-другому:
vsb>Приложение должно определяться, как группа ресурсов. При первом открытии приложения вся группа ресурсов должна скачиваться. Обновление не должно быть обязательным, у пользователя должна быть возможность использовать старую версию приложения и обновляться по желанию. К примеру я стою на светофоре и запустил навигатор. Мне нужно, чтобы он запустился моментально, а не скачивал 150 мегабайтов новой версии.
Ты хочешь чтобы каждый сайт стал приложением, которое бы со всеми ресурсами скачивалось на комп, даже если я дальше главной страницы не пойду, а может даже дальше страницы логина? Кинули ссылку с мемасом, ты открываешь и с этого момента хранишь у себя ВСЕ приложение к которому возможно больше никогда не обратишься? Мало того, чтобы один раз взглянуть на картинку или отдельную "страницу" переданную по ссылке и забыть, ты должен будешь подождать пока все приложение, а "страниц" в нем может быть много (начиная от логина и оформления профиля пользователя и заканчивая чтением и написанием комментариев), не загрузится.
Здравствуйте, rFLY, Вы писали:
vsb>>Приложение должно определяться, как группа ресурсов. При первом открытии приложения вся группа ресурсов должна скачиваться. Обновление не должно быть обязательным, у пользователя должна быть возможность использовать старую версию приложения и обновляться по желанию. К примеру я стою на светофоре и запустил навигатор. Мне нужно, чтобы он запустился моментально, а не скачивал 150 мегабайтов новой версии.
FLY>Ты хочешь чтобы каждый сайт стал приложением, которое бы со всеми ресурсами скачивалось на комп, даже если я дальше главной страницы не пойду, а может даже дальше страницы логина? Кинули ссылку с мемасом, ты открываешь и с этого момента хранишь у себя ВСЕ приложение к которому возможно больше никогда не обратишься? Мало того, чтобы один раз взглянуть на картинку или отдельную "страницу" переданную по ссылке и забыть, ты должен будешь подождать пока все приложение, а "страниц" в нем может быть много (начиная от логина и оформления профиля пользователя и заканчивая чтением и написанием комментариев), не загрузится.
Вообще я разделяю сайты и веб-приложения.
Но сложные сайты вроде пикабу в такой интерпретации скорей всего будут приложениями.
Да, хранишь всё приложение. Ровно так же, как ты сейчас у себя хранишь всё приложение пикабу, если хоть раз туда зашёл. В виде набора JS, CSS, картинок и прочего в кеше. И ровно так же кеш неиспользуемых приложений можно и нужно очищать, если пользователь не пользуется приложением и не выразил какого-то явного желания не очищать этот кеш. Это сейчас даже смартфоны делают с мобильными приложениями.
FLY>должен будешь подождать пока все приложение, а "страниц" в нем может быть много (начиная от логина и оформления профиля пользователя и заканчивая чтением и написанием комментариев), не загрузится.
А как же микросервисная архитектура, по которой положено для показа каждой картинки делать своё микроприложение?
И как надо постараться, чтобы бинарник, показывающий 1 страницу, был больше, чем современно-актуальный жабаскрипт, делающий то же самое?
Здравствуйте, Osaka, Вы писали:
O>А как же микросервисная архитектура, по которой положено для показа каждой картинки делать своё микроприложение? O>И как надо постараться, чтобы бинарник, показывающий 1 страницу, был больше, чем современно-актуальный жабаскрипт, делающий то же самое?
Почему одну страницу, а не весь сайт? Если же приложение будет разбивается на микросервисы, которые в свою очередь отправляют запросы для получения ресурсов, то чем это будет отличаться от того, что мы имеем сейчас?
O>>А как же микросервисная архитектура, по которой положено для показа каждой картинки делать своё микроприложение? O>>И как надо постараться, чтобы бинарник, показывающий 1 страницу, был больше, чем современно-актуальный жабаскрипт, делающий то же самое? FLY>Почему одну страницу, а не весь сайт?
По той же причине, что десктопное приложение из многих dll а не 1 большой exe — для возможности замены по частям. >Если же приложение будет разбивается на микросервисы, которые в свою очередь отправляют запросы для получения ресурсов, то чем это будет отличаться от того, что мы имеем сейчас?
Писанием на человеческом строготипизированном языке и исполнением человеческих скомпилированных бинарников. А не этого жруще-тормозящего конгломерата костылей, который сейчас нагромоздили вокруг запрета запускать бинарники на клиенте, который затевался якобы для безопасности, но всё равно броузер для незнакомых г-сайтов (а лучше для всех) надо запускать в отдельной виртуалке.
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают.
vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
Так надо не веб менять, а десктоп в первую очередь.
Завезти в ОС как минимум следующее:
— унифицированное API для GUI
— запуск приложений в песочнице и раздачу прав примерно как на мобильных ОС
— унифицированные механизмы репозиториев/магазинов. Чтобы не выдумывать разные инсталляторы, обновляторы, экспорты/импорты настроек...
Десктоп настолько неудобен в поддержке, что даже корпоративные ERP, CRM и т.п. делают на веб технологиях.
Хотя нативные десктопные приложения и быстрее и удобнее в работе, но этим в итоге жертвуют и пользователи в принципе даже привыкли уже.
Здравствуйте, B0FEE664, Вы писали:
CC>>Параллельность тут не даётся бесплатно, так что "платить" за одно и то же но присланое из 15 источников всё равно придётся. BFE>Платить — да. но не скоростью передачи.
Забитость канала естественным путём ограничивает скорость
BFE>Даже с учётом того, что исходящая пропускная возможность каждого клиента меньше, чем входящая пропускная возможность каждого клиента, суммарная пропускная способность всех исходящих каналов клиентов выше, чем сервера.
Для этого очень много клиентов должны быть онлайн, и содержать нужные данные, что в масштабе всего веба маловероятно.
CC>>Так что нет. Всё зависит от раздающих а не качающих. BFE>Обычно если скачивающий не раздаёт, то его блокируют.
Даже в торрентах от этого давно отказались
BFE>А что смешного? По скорости протокол BitTorrent'а никто не обходит.
В очень специфическмх раскладах.
Ещё раз, тебе надо сравнивать не с торрентом а с IPFS
BFE>QUIC — вот шаг в данном направлении.
А где там то, что ты описываешь с торрент-like потягушками от клиентов?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Osaka, Вы писали:
O>Писанием на человеческом строготипизированном языке и исполнением человеческих скомпилированных бинарников.
Чем тогда WASM не устраивает?
O>>Писанием на человеческом строготипизированном языке и исполнением человеческих скомпилированных бинарников. FLY>Чем тогда WASM не устраивает?
Это который эмулятор виртуальной машины в обычном броузере на том же самом жабаскрипте? У которого хелловорлд грузит 5Mb на клиент? Нет, хочу запуск скачанного бинарника 20kb в аппаратной виртуализации как в VMWare, только чтобы выглядело как запуск в окне броузера.
Здравствуйте, karbofos42, Вы писали:
vsb>>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас. K>Так надо не веб менять, а десктоп в первую очередь. K>Завезти в ОС как минимум следующее: K>- унифицированное API для GUI K>- запуск приложений в песочнице и раздачу прав примерно как на мобильных ОС K>- унифицированные механизмы репозиториев/магазинов. Чтобы не выдумывать разные инсталляторы, обновляторы, экспорты/импорты настроек... K>Десктоп настолько неудобен в поддержке, что даже корпоративные ERP, CRM и т.п. делают на веб технологиях. K>Хотя нативные десктопные приложения и быстрее и удобнее в работе, но этим в итоге жертвуют и пользователи в принципе даже привыкли уже.
Веб силён в первую очередь урлами. Чтобы я мог тебе бросить ссылку "зацени" и ты кликнув через пару секунд уже видел готовую страничку с тем, что я тебе послал. Притом этим может быть и фоточка, и видосик, и точка на карте, и игрушка, и меню в ресторане, и бложик, и товар в магазине, и данные клиента в CRM, и исходники ядра, и вообще что угодно.
Реализуется ли это всё полноценными песочницами, приложениями и магазинами — я очень сомневаюсь. А если оно и реализуемо и таки допилить возможно, то оно ничем принципиально от текущего веба отличаться не будет.
После того как наконец-то сделали веб-сокеты, ещё могло бы быть полезным добавить какой-нибудь multicast... но с другой стороны, довольно нишевая штука.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Веб силён в первую очередь урлами.
Ага. Особенно это удобно для фишинга.
·>Чтобы я мог тебе бросить ссылку "зацени" и ты кликнув через пару секунд уже видел готовую страничку с тем, что я тебе послал.
Как-то так?
·>Притом этим может быть и фоточка, и видосик, и точка на карте, и игрушка, и меню в ресторане, и бложик, и товар в магазине, и данные клиента в CRM, и исходники ядра, и вообще что угодно.
А зачем фоточки и видосики из веба убирать? Они кому-то мешают и с ними какие-то проблемы?
·>Реализуется ли это всё полноценными песочницами, приложениями и магазинами — я очень сомневаюсь.
Ну, сейчас в той же винде просто запись в реестре вида "протокол:" добавляет обработчик урлов нужного протокола. Так работают и торренты и почтовики (mailto и ссылки на телегу. Всякие Microsoft Store как-то умеют в принципе обрабатывать ссылки нужного домена, а не отправляют в браузер.
·>А если оно и реализуемо и таки допилить возможно, то оно ничем принципиально от текущего веба отличаться не будет.
с безопасностью несколько лучше и производительностью, а так конечно никаких отличий.
Здравствуйте, karbofos42, Вы писали:
K>·>Веб силён в первую очередь урлами. K>Ага. Особенно это удобно для фишинга.
Это уже другой вопрос — вопрос безопасности. С предложенными тобой магазинами приложений таких вопросов на порядок больше.
K>·>Чтобы я мог тебе бросить ссылку "зацени" и ты кликнув через пару секунд уже видел готовую страничку с тем, что я тебе послал. K>Как-то так?
Типа того, но чтоб работало, а не "c:/users/Melkov_A"
K>·>Притом этим может быть и фоточка, и видосик, и точка на карте, и игрушка, и меню в ресторане, и бложик, и товар в магазине, и данные клиента в CRM, и исходники ядра, и вообще что угодно. K>А зачем фоточки и видосики из веба убирать? Они кому-то мешают и с ними какие-то проблемы?
Потому что нет чёткой границы, где фоточки в вебе ок, а где уже надо серьёзную аппликуху. Если фоточку посмотреть это веб? А если ещё чтобы можно было перевернуть? А яркость подкрутить? А надпись добавить? А макет открытки нарисовать для заказа? А надписи распознать? Всё ещё веб или уже десктоп-приложение надо?
K>·>Реализуется ли это всё полноценными песочницами, приложениями и магазинами — я очень сомневаюсь. K>Ну, сейчас в той же винде просто запись в реестре вида "протокол:" добавляет обработчик урлов нужного протокола. Так работают и торренты и почтовики (mailto и ссылки на телегу. Всякие Microsoft Store как-то умеют в принципе обрабатывать ссылки нужного домена, а не отправляют в браузер.
Безопасность-то откуда возьмётся? Пришёл тебе урл "mai1to:" — и дальше что, будем ставить неясные аппликухи?
K>·>А если оно и реализуемо и таки допилить возможно, то оно ничем принципиально от текущего веба отличаться не будет. K>с безопасностью несколько лучше и производительностью, а так конечно никаких отличий.
Если оно будет работать в песочнице, то никакого "лучше" не будет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Это уже другой вопрос — вопрос безопасности. С предложенными тобой магазинами приложений таких вопросов на порядок больше.
Ага. А урлы настолько удобны и нужны людям, что во всех современных браузерах адресную строку совместили с поисковой.
Даже вот не знаю почему в той же телеге не дают копировать урл, чтобы потом нужному человеку отправить, а добавили кнопку переслать, которая сама это делает.
Урл — это дешёвый и кривой способ. Многие люди даже не понимают что это такое и каждый раз к себе вконтактик входят через поиск в яндексе.
·>Типа того, но чтоб работало, а не "c:/users/Melkov_A"
В 1С так принято, для них это нормально, т.к. речь про файловую БД.
Это был лишь намёк на то, что в десктопные приложения тоже можно навигацию добавить, если это нужно пользователям.
·>Потому что нет чёткой границы, где фоточки в вебе ок, а где уже надо серьёзную аппликуху. Если фоточку посмотреть это веб? А если ещё чтобы можно было перевернуть? А яркость подкрутить? А надпись добавить? А макет открытки нарисовать для заказа? А надписи распознать? Всё ещё веб или уже десктоп-приложение надо?
А нужна эта граница и нужно кого-то как-то заставлять и ограничивать?
Я лишь говорю о том, что разработку и поддержку десктопных приложений нужно сделать более удобными и тогда тяжеловесные штуки будут писаться нативно.
Сейчас десктоп настолько неудобен, что всё подряд на веб-технологиях пилят.
Не будут этим заниматься — не будет тяжеловесного веба, не будет претензий, что браузер всю память выжрал и всё еле работает.
·>Безопасность-то откуда возьмётся? Пришёл тебе урл "mai1to:" — и дальше что, будем ставить неясные аппликухи?
Ну, нормального человека должно заинтересовать почему это по ссылке не уже установленная программа открылась, а вышла ошибка.
И зачем ему нужно идти в какой-то левый репозиторий и оттуда ставить программу, которая у него уже установлена?
А вот не обратить внимания на ссылку, т.к. сайт выглядит так, как всегда — это легко.
·>Если оно будет работать в песочнице, то никакого "лучше" не будет.
Ну, ок. Не так выразился. Дают там копировать урл, но основной механизм таки — переслать.
Если за пределами телеги нужно на том же кывте поделиться инфой, то тут ссылка нужна.
Внутри телеги нет смысла оперировать ссылками.
Здравствуйте, karbofos42, Вы писали:
K>Здравствуйте, rollcoin, Вы писали:
K>Ну, ок. Не так выразился. Дают там копировать урл, но основной механизм таки — переслать. K>Если за пределами телеги нужно на том же кывте поделиться инфой, то тут ссылка нужна. K>Внутри телеги нет смысла оперировать ссылками.
Так ссылка работает и вне телеги. Вот скопированная ссылка на пост из скриншота выше https://t.me/projs_ru/256495
ты можешь открыть его прямо в браузере, перейдя по ссылке.
Здравствуйте, rollcoin, Вы писали:
R>Вообще-то есть. Начиная с того, чтобы отмотать любой канал/группу на самое начало — берем ссылку на сообщение и меняем на первое.
Зачем? Разработчики телеги добавили кнопку "вниз", чтобы перейти к последнему сообщению. Никто им не запрещает сделать такую же кнопку "вверх".
Если в канале первое сообщение будет удалено, тогда способ сработает?
R>Заканчивая тем, что пересылку СВОИХ сообщений можно запретить, тогда их нельзя будет переслать, а ссылки запретить нельзя.
Здравствуйте, karbofos42, Вы писали:
K>Здравствуйте, rollcoin, Вы писали:
K>Если в канале первое сообщение будет удалено, тогда способ сработает?
Да, перемотает к первому не удаленому.
R>>Заканчивая тем, что пересылку СВОИХ сообщений можно запретить, тогда их нельзя будет переслать, а ссылки запретить нельзя.
K>т.е. уязвимость?
Пересланное ообщение имеет природу аттача. Если отправитель удалит исходное сообщение, в пересланном сохранится его копия.
Ссылкой это не работает. Ссылка на удаленное собщение не покажет сообщения, потому что его больше нет.
Так что запрет на пересылку, это именно для этого.
Скриншот сообщения не может быть валидным, потому что его можно подделать. Пересланное сообщение подделать нельзя.
Здравствуйте, karbofos42, Вы писали:
K>·>Это уже другой вопрос — вопрос безопасности. С предложенными тобой магазинами приложений таких вопросов на порядок больше. K>Ага. А урлы настолько удобны и нужны людям, что во всех современных браузерах адресную строку совместили с поисковой.
Э... И? Урлы-то так и остались. Более того, ты почему-то забыл, что урлы нужны не только людям, но и программам.
K>Даже вот не знаю почему в той же телеге не дают копировать урл, чтобы потом нужному человеку отправить, а добавили кнопку переслать, которая сама это делает.
Ну, как оказалось, лишь потому, что ты телегой пользоваться не умеешь.
K>Урл — это дешёвый и кривой способ.
Более прямых способов пока не придумали.
K>Многие люди даже не понимают что это такое и каждый раз к себе вконтактик входят через поиск в яндексе.
Т.е. предлагаешь судить полезность технологии по пользователям вконтактика?
Более того, ты почему-то забыл, что в том же контактике будут те же самые урлы на всевозможные другие сайты и именно урлы позволяют через яндекс выйти в вконтактик, а потом и во весь веб.
K>·>Типа того, но чтоб работало, а не "c:/users/Melkov_A" K>В 1С так принято, для них это нормально, т.к. речь про файловую БД. K>Это был лишь намёк на то, что в десктопные приложения тоже можно навигацию добавить, если это нужно пользователям.
Если это ты привёл как пример, как делать не надо, то я полностью согласен, 1С — убогая программа, не могут веб-интерфейс осилить.
K>·>Потому что нет чёткой границы, где фоточки в вебе ок, а где уже надо серьёзную аппликуху. Если фоточку посмотреть это веб? А если ещё чтобы можно было перевернуть? А яркость подкрутить? А надпись добавить? А макет открытки нарисовать для заказа? А надписи распознать? Всё ещё веб или уже десктоп-приложение надо? K>А нужна эта граница и нужно кого-то как-то заставлять и ограничивать?
Ты вроде предлагаешь веб "правильным" десктопом заменять. Или я не понял твоей идеи?
K>Я лишь говорю о том, что разработку и поддержку десктопных приложений нужно сделать более удобными и тогда тяжеловесные штуки будут писаться нативно.
Ты не определил какие именно штуки считать тяжеловесными. По каким критериям? Вот в моём примере выше про фоточку где тяжеловесность начинается?
K>Сейчас десктоп настолько неудобен, что всё подряд на веб-технологиях пилят.
Потому что веб-технологии удобнее.
K>Не будут этим заниматься — не будет тяжеловесного веба, не будет претензий, что браузер всю память выжрал и всё еле работает.
Будет претензии, что некая десктопная прога выжрала всю память и комп еле работает.
K>·>Безопасность-то откуда возьмётся? Пришёл тебе урл "mai1to:" — и дальше что, будем ставить неясные аппликухи? K>Ну, нормального человека должно заинтересовать почему это по ссылке не уже установленная программа открылась, а вышла ошибка. K>И зачем ему нужно идти в какой-то левый репозиторий и оттуда ставить программу, которая у него уже установлена?
Если как ты мечтаешь мы перетащим хотя бы десятую часть веба в десктоп, то там будет столько всего, что каждая вторая ссылка будет показывать "ошибку" и требовать левые репозитории.
K>А вот не обратить внимания на ссылку, т.к. сайт выглядит так, как всегда — это легко.
Так ведь ты тут сам выше утверждаешь, что урлы люди не понимают, а магические ссылки значит будут понимать внезапно?
K>·>Если оно будет работать в песочнице, то никакого "лучше" не будет. K>Будет
Мечтать не вредно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, CreatorCray, Вы писали:
CC>>>Параллельность тут не даётся бесплатно, так что "платить" за одно и то же но присланое из 15 источников всё равно придётся. BFE>>Платить — да. но не скоростью передачи. CC>Забитость канала естественным путём ограничивает скорость
Так ведь каждый пакет пойдёт по своему каналу.
BFE>>Даже с учётом того, что исходящая пропускная возможность каждого клиента меньше, чем входящая пропускная возможность каждого клиента, суммарная пропускная способность всех исходящих каналов клиентов выше, чем сервера. CC>Для этого очень много клиентов должны быть онлайн, и содержать нужные данные, что в масштабе всего веба маловероятно.
С чего бы это маловероятно? Если сайт посещаемый, то на нём всё время кто-нибудь да "весит".
CC>Ещё раз, тебе надо сравнивать не с торрентом а с IPFS
Почему именно с IPFS? У IPFS у каждого файла один идентификатор на всю планету (так?) — это совсем другая скорость поиска.
CC>А где там то, что ты описываешь с торрент-like потягушками от клиентов?
Так при peer-to-peer для скорости нужен UDP с гарантией, на TCP всё будет тормозить. Вот поэтому QUIC — шаг в данном направлении.
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Платить — да. но не скоростью передачи. CC>>Забитость канала естественным путём ограничивает скорость BFE>Так ведь каждый пакет пойдёт по своему каналу.
Канал у типичного юзера, как правило, один.
CC>>А где там то, что ты описываешь с торрент-like потягушками от клиентов? BFE>Так при peer-to-peer для скорости нужен UDP с гарантией, на TCP всё будет тормозить. Вот поэтому QUIC — шаг в данном направлении.
"UDP с гарантией" называется TCP, внезапно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
BFE>>·>Это значит будут дорогие cache misses и всё будет тормозить. BFE>>Почему? ·>Потому что это сетевой вызов.
С чего бы?
BFE>>Сколько под кэш отведёшь, столько и будет. ·> Сколько надо-то, чтобы твоя "архитектура" заработала и дала хоть какое-то преимущество?
Больше — лучше, но делать точный расчёт мне сейчас лень.
BFE>>Для меня чем-то отличается www.google-analytics.com от чужого браузера? Да. google-analytics опаснее, так как он намного больше, чем отдельный никому неизвестный случайный браузер. ·>Отличается. Я могу его целенаправленно заблокировать, например. Блокировать пиров — неясно как. Либо всё, либо ничего.
Вы пробовали блокировать?
BFE>>И это только те соединения, которые Firefox соизволил показать. А есть и другие... ·>Если ты не разбираешься в том, что у тебя на компе происходит, это не значит, что никто ничего не знает.
Не значит, но есть те, кто говорит, что знает, а сами даже не пытались блокировать "подозрительный" трафик.
BFE>>Если он не хочет загружать свой канал, то может установить себе прокси, который этим займётся. ·>А зачем кто-то будет хотеть?
А зачем кому-то пользоваться web-ом?
BFE>>Зачем многократно-то? ·>Затем, что ты так сам так предложил: "А запрос сразу ко многим идёт".
Ну да. Вот, допустим, заходите на сайт, там 5 картинок, про которые сайт знает, что эти 5 картинок сервер только что (секунду назад) отдал вот тем 5-ти клиентам, о чём он и сообщает новому клиенту, а этот клиент уже спрашивает у тех о картинках. Ну и логично сразу от клиента направить запрос с дублированием для скорости в случае если один из клиентов не ответит.
BFE>>·>Не могут. Ты вначале должен найти пиров, договориться что у кого есть. BFE>>Пиры известны от сервера. ·>Телепатией? Или дополнительными сетевыми вызовами?
Зачем телепатией? Зачем дополнительные сетевые вызовы? Сервер знает, кто к нему обращался.
·>Нет. Ты опять контекст забыл. Напоминаю, ты сказал, что "для коротких мессаджей, типа twitter это, понятно, не нужно.", но так и не написал для чего конкретно эта твоя архитектура нужна.
Нужно для любого общего данного, чей размер не укладывается в один UDP пакет.
BFE>>·>А то в итоге получится, что серверы всё равно придётся дублировать. BFE>>Не обязательно. Можно вообще сделать serverless архитектуру. Для получения данных это просто, а вот для передачи от клиента — очень сложно. ·>А можно вообще чего угодно нафантазировать. Приводи конкретные сценарии.
Ага. А следующим вопросом будет, ну покажи как ты это напишешь?
BFE>>·>Ты ошибаешься. Другую архитектуру ты так и не предложил. "Делать всё быстро, распределённо и параллельно" — это не архитектура, а фантазия. Просто попробуй продумать хотя бы кто какие запросы куда идут, что делать когда что-то теряется и сравни. BFE>>Другие архитектуры давно существуют, работают и придуманы не мной. ·>Ага. И часто работают _поверх_ текущего веба.
Протокол BitTorrent работает поверх веба?
·>И вообще бы наступил мир во всём мире и всеобщее счастье.
Наоборот.
·>Это факт. В зависимости от того, нравится он тебе или нет — это может быть плохо или хорошо.
Значит это не аргумент.
BFE>>·>Как ты решишь ddos в твоей архитектуре? BFE>>А что вы собираетесь ddos'ить? Исходный сервер? Так ведь не обязательно инфу брать прямого с него. ·>То что ддосят сейчас.
Сейчас ддосят исходные сервера.
·>Это ты приводишь идиотские аргументы.
Это я придумал про детское порно?
·>В том, что это не моя проблема, а провайдера.
А с чего это проблема провайдера?
·>В том, что это может быть использован в суде с конкретным юридическим лицом, например. А так же репутационные риски и т.п.
Нет, не может. Посмотрите на судебную практику.
BFE>>Сейчас весь риск завязан на нескольких поставщиков сертификатов, а значит опасность выше. ·>Не завязан. Можешь отвязаться, если вдруг надо.
Нет, это невозможно практически.
BFE>>А то, о чём вы пишите — это не управление рисками, это вера в большие структуры. ·>Других вариантов нет.
В том-то и дело, что есть.
Здравствуйте, ·, Вы писали:
·>Канал у типичного юзера, как правило, один.
Так он у него так и так один.
BFE>>Так при peer-to-peer для скорости нужен UDP с гарантией, на TCP всё будет тормозить. Вот поэтому QUIC — шаг в данном направлении. ·>"UDP с гарантией" называется TCP, внезапно.
Нет. TCP и QUIC — это два разных протокола "внезапно".
Здравствуйте, rollcoin, Вы писали:
R>Скриншот сообщения не может быть валидным, потому что его можно подделать. Пересланное сообщение подделать нельзя.
Ну, в моём понимании, если что-то прямым путём нельзя сделать, но можно окольными путями — это уязвимость.
Если я заблокировал пересылку сообщений, то вероятно я хочу, чтобы они ни к кому больше не попали,
а не так, что их можно посмотреть по ссылке, потому что у кого-то там какая-то концепция
Здравствуйте, karbofos42, Вы писали:
K>Здравствуйте, rollcoin, Вы писали:
R>>Скриншот сообщения не может быть валидным, потому что его можно подделать. Пересланное сообщение подделать нельзя.
K>Ну, в моём понимании, если что-то прямым путём нельзя сделать, но можно окольными путями — это уязвимость. K>Если я заблокировал пересылку сообщений, то вероятно я хочу, чтобы они ни к кому больше не попали, K>а не так, что их можно посмотреть по ссылке, потому что у кого-то там какая-то концепция
Здравствуйте, ·, Вы писали:
·>Э... И? Урлы-то так и остались.
Браузер открывает любые урлы, приложения очевидно обработают только своё (примерно так же, как обрабатывают аргументы командной строки).
Будет странно в интернет-банк добавлять обработку фишинговых ссылок и сливать данные.
·>Более того, ты почему-то забыл, что урлы нужны не только людям, но и программам.
Ни программам, ни людям они не нужны.
Ты по rsdn вот через адресную строку ходишь? Набиваешь ручками номер темы может?
Или максимум — rsdn.org набрал, а дальше уже по ссылкам жмёшь и плевать на урлы?
Чем-то принципиально взаимодействие с урлами отличается от запуска приложения через ярлык/командную строку/поиск на компьютере?
·>Ну, как оказалось, лишь потому, что ты телегой пользоваться не умеешь.
ну, молодец, раскусил
·>Т.е. предлагаешь судить полезность технологии по пользователям вконтактика?
Я предлагаю не называть реализацию тем, что нужно пользователям.
У меня вот ни в интернет-банке, ни в приложении трелло очень важный урл не отображается постоянно на экране.
Даже не знаю как это всё может работать, если такой важный элемент реализации не показывать пользователю.
·>Более того, ты почему-то забыл, что в том же контактике будут те же самые урлы на всевозможные другие сайты и именно урлы позволяют через яндекс выйти в вконтактик, а потом и во весь веб.
А когда пользователь это всё открывает на своём компьютере, то данные у него лежат по каким-то адресам памяти.
Может тогда за указатели тоже переживать будем? Ведь без них ПО бы не работало, значит они нужны людям и обязательно им их показывать нужно.
·>Если это ты привёл как пример, как делать не надо, то я полностью согласен, 1С — убогая программа, не могут веб-интерфейс осилить.
Ты же хотел ссылки — я тебе показал то, про что вспомнил, где есть ссылки.
Хотя мог просто намекнуть, что браузер — десктопное приложение и они таки как-то ссылки умеет обрабатывать.
Или только браузерам можно?
·>Ты вроде предлагаешь веб "правильным" десктопом заменять. Или я не понял твоей идеи?
Веб и сейчас заменяют десктопом, но это дорого, поэтому позволить могут не все.
Соц. сети, мессенджеры, интернет-банки и т.д. и т.п. почему-то не остановились на веб-сайтах, а делают нативные клиенты.
Может потому что они быстрее и удобнее?
А урлы даже не знаю почему там не показывают. Захожу в приложение посмотреть остаток денег и прямо не по себе, т.к. не знаю адрес отображаемой "страницы".
Среди этих приложений ещё много неправильных десктопов — когда сайтик в Electron завернули и типа нативное приложение.
Но даже такое, как правило, удобнее, чем сайт.
·>Ты не определил какие именно штуки считать тяжеловесными. По каким критериям? Вот в моём примере выше про фоточку где тяжеловесность начинается?
А я должен это определять? Ну, возьми мой любимый телеграмм, там со скольки-то мегабайт видео в браузере не показывает и отправляет в десктопный клиент.
Запиши этот объём и не забудь: начиная с него — всё делаем только в виде десктопа, т.к. тяжеловесное.
·>Потому что веб-технологии удобнее.
Вот так новость
·>Если как ты мечтаешь мы перетащим хотя бы десятую часть веба в десктоп, то там будет столько всего, что каждая вторая ссылка будет показывать "ошибку" и требовать левые репозитории.
Не я мечтаю, а ты за меня что-то там придумал. Не нужно путать.
·>Так ведь ты тут сам выше утверждаешь, что урлы люди не понимают, а магические ссылки значит будут понимать внезапно?
Тайну открою: урлы не обязательно показывать пользователю.
Твои любимые веб-ссылки сейчас не модно просто так показывать, везде стараются превьюшку подгрузить.
Людям так нужны урлы, они хотят ими любоваться, а в итоге эти бесполезные превьюшки показываются — заговор какой-то (я наверно всех подговорил и это первый шаг против урлов).
Но в десктопных приложениях запрещено превьюшки делать, там обязательно нужно урлы показывать.
Здравствуйте, karbofos42, Вы писали:
K>·>Э... И? Урлы-то так и остались. K>Браузер открывает любые урлы, приложения очевидно обработают только своё (примерно так же, как обрабатывают аргументы командной строки). K>Будет странно в интернет-банк добавлять обработку фишинговых ссылок и сливать данные. Ты разберись в сущности фишинга. Добавляют не в интернет-банк, а добавляют uнtернет-бaнk.
K>·>Более того, ты почему-то забыл, что урлы нужны не только людям, но и программам. K>Ни программам, ни людям они не нужны. K>Ты по rsdn вот через адресную строку ходишь? Набиваешь ручками номер темы может? K>Или максимум — rsdn.org набрал, а дальше уже по ссылкам жмёшь и плевать на урлы? Противоречие детектед. Ссылки как раз и содержат урлы. И, очень часто, за пределы rsdn.org, на соверешнно другие ресурсы.
K>Чем-то принципиально взаимодействие с урлами отличается от запуска приложения через ярлык/командную строку/поиск на компьютере?
Например тем, что урлы глобальны, по всему миру, а не ограничены твоим компьютером. И ещё есть ряд принципиальных отличий, которые тут уже упоминались.
K>·>Т.е. предлагаешь судить полезность технологии по пользователям вконтактика? K>Я предлагаю не называть реализацию тем, что нужно пользователям.
Если пользователям вконтакта нужно мало, это не означает, что только это нужно всем пользователям.
K>У меня вот ни в интернет-банке, ни в приложении трелло очень важный урл не отображается постоянно на экране. K>Даже не знаю как это всё может работать, если такой важный элемент реализации не показывать пользователю.
Ну так разберись наконец-то. А то получится как с телегой.
K>·>Более того, ты почему-то забыл, что в том же контактике будут те же самые урлы на всевозможные другие сайты и именно урлы позволяют через яндекс выйти в вконтактик, а потом и во весь веб. K>А когда пользователь это всё открывает на своём компьютере, то данные у него лежат по каким-то адресам памяти. K>Может тогда за указатели тоже переживать будем? Ведь без них ПО бы не работало, значит они нужны людям и обязательно им их показывать нужно.
Их показывать нужно если это даёт какое-то преимущество. С показанным адресом ничего полезного сделать нельзя. С урлом — можно.
K>·>Если это ты привёл как пример, как делать не надо, то я полностью согласен, 1С — убогая программа, не могут веб-интерфейс осилить. K>Ты же хотел ссылки — я тебе показал то, про что вспомнил, где есть ссылки.
Лучше бы и не показывал это.
K>Хотя мог просто намекнуть, что браузер — десктопное приложение и они таки как-то ссылки умеет обрабатывать. K>Или только браузерам можно?
Я уже вроде говорил, что урлы умеют обрабатывать не только браузеры.
K>·>Ты вроде предлагаешь веб "правильным" десктопом заменять. Или я не понял твоей идеи? K>Веб и сейчас заменяют десктопом, но это дорого, поэтому позволить могут не все.
Вот ты сам ещё одно преимущество веба выдал — веб дешевле.
K>Соц. сети, мессенджеры, интернет-банки и т.д. и т.п. почему-то не остановились на веб-сайтах, а делают нативные клиенты.
Под мобилки что-ли? Мобильные приложения это не десктоп, по определению. Десктопных приложений для банков мне видеть не доводилось практически.
K>Может потому что они быстрее и удобнее?
Потому что ты тезис подменил.
K>А урлы даже не знаю почему там не показывают. Захожу в приложение посмотреть остаток денег и прямо не по себе, т.к. не знаю адрес отображаемой "страницы". K>Среди этих приложений ещё много неправильных десктопов — когда сайтик в Electron завернули и типа нативное приложение. K>Но даже такое, как правило, удобнее, чем сайт.
Вот только количество веб-сайтов на порядки больше, чем мобильных и уж тем более десктопных.
K>·>Ты не определил какие именно штуки считать тяжеловесными. По каким критериям? Вот в моём примере выше про фоточку где тяжеловесность начинается? K>А я должен это определять? Ну, возьми мой любимый телеграмм, там со скольки-то мегабайт видео в браузере не показывает и отправляет в десктопный клиент. K>Запиши этот объём и не забудь: начиная с него — всё делаем только в виде десктопа, т.к. тяжеловесное.
Это проблема телеграмма. В каком-нибудь ютубе с размерами видео проблем нет.
K>·>Потому что веб-технологии удобнее. K>Вот так новость
Угу, полно сценариев, когда удобнее. Конечно, есть и исключения.
K>·>Если как ты мечтаешь мы перетащим хотя бы десятую часть веба в десктоп, то там будет столько всего, что каждая вторая ссылка будет показывать "ошибку" и требовать левые репозитории. K>Не я мечтаю, а ты за меня что-то там придумал. Не нужно путать.
А что же ты придумал-то?
K>·>Так ведь ты тут сам выше утверждаешь, что урлы люди не понимают, а магические ссылки значит будут понимать внезапно? K>Тайну открою: урлы не обязательно показывать пользователю.
Тут ведь как, можно не показывать, а можно и показывать! Зависит от кривизны рук разработчиков.
K>Твои любимые веб-ссылки сейчас не модно просто так показывать, везде стараются превьюшку подгрузить.
Превьюшка собственно подргужается благодаря вебу же, а не магически.
K>Людям так нужны урлы, они хотят ими любоваться, а в итоге эти бесполезные превьюшки показываются — заговор какой-то (я наверно всех подговорил и это первый шаг против урлов).
Чтобы показать превьюшку нужно чтобы был урл.
K>Но в десктопных приложениях запрещено превьюшки делать, там обязательно нужно урлы показывать.
Чё?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·> Ты разберись в сущности фишинга. Добавляют не в интернет-банк, а добавляют uнtернет-бaнk.
Если у меня установленный десктопный интернет-банк внезапно не умеет обрабатывать ссылки на uнtернет-бaнk, то кто их будет обрабатывать, чтобы уже у пользователя наконец учётные данные украсть смогли?
·>Например тем, что урлы глобальны, по всему миру, а не ограничены твоим компьютером. И ещё есть ряд принципиальных отличий, которые тут уже упоминались.
Зачем мне глобальный урл на транзакцию по оплате проезда в метро, которая в интернет-банке отображается?
Ну, а вот ещё часто в чатиках можно ссылку на пользователя добавить через @имя_пользователя.
Там не url используется, но пользователь таки отмечается, получает уведомления и достаточно всё удобно.
Зря они это сделали и нужно было туда url на профиль пользователя вставлять, а не это непотребство, которое вообще не соответствует стандарту url и не глобальное?
·>Вот ты сам ещё одно преимущество веба выдал — веб дешевле.
Я вообще-то по сути с этого начал
·>Под мобилки что-ли? Мобильные приложения это не десктоп, по определению.
И чем же мобильные приложения принципиально отличаются от десктопа?
·>Потому что ты тезис подменил.
Это какой я тезис подменил?
·>Вот только количество веб-сайтов на порядки больше, чем мобильных и уж тем более десктопных.
А бедных больше, чем богатых.
·>Превьюшка собственно подргужается благодаря вебу же, а не магически.
т.е. если у меня в десктопном клиенте, в каком-нибудь чатике есть в сообщении что-то типа "[-client=50]",
то я не могу посредством SQL-запроса обратиться к БД и запросить информацию по клиенту с ИД = 50 и на каком-нибудь Canvas нарисовать какую-нибудь превьюшку в виде визитки?
Прямо обязательно веб подтягивать нужно?
Здравствуйте, B0FEE664, Вы писали:
CC>>Забитость канала естественным путём ограничивает скорость BFE>Так ведь каждый пакет пойдёт по своему каналу.
У юзера всего один канал, и он не резиновый. Особенно у мобильных юзеров.
BFE>С чего бы это маловероятно? Если сайт посещаемый, то на нём всё время кто-нибудь да "весит".
BFE>Почему именно с IPFS? У IPFS у каждого файла один идентификатор на всю планету (так?) — это совсем другая скорость поиска.
Ну дык у твоего сайта каждый скачиваемый элемент надо будет искать у кого из всей планеты он ещё есть.
BFE>Так при peer-to-peer для скорости нужен UDP с гарантией, на TCP всё будет тормозить. Вот поэтому QUIC — шаг в данном направлении.
Не, на UDP ты просто строишь все гарантии поверх врукопашную. И можешь построить более гибко чем то, что давным давно отлили в TCP в граните.
В QUIC же встроили TLS, что сделало handshake быстрее.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, karbofos42, Вы писали:
K>·> Ты разберись в сущности фишинга. Добавляют не в интернет-банк, а добавляют uнtернет-бaнk. K>Если у меня установленный десктопный интернет-банк внезапно не умеет обрабатывать ссылки на uнtернет-бaнk, то кто их будет обрабатывать, чтобы уже у пользователя наконец учётные данные украсть смогли?
Откуда у тебя возьмётся установленный? Оттуда же установишь и uнtернет-бaнk. Ты правда не понимаешь что такое фишинг?
K>·>Например тем, что урлы глобальны, по всему миру, а не ограничены твоим компьютером. И ещё есть ряд принципиальных отличий, которые тут уже упоминались. K>Зачем мне глобальный урл на транзакцию по оплате проезда в метро, которая в интернет-банке отображается?
Обычно для конкретно этой ситуации может и не надо. Но в принципе послать ссылку своему бухгалтеру, чтобы он налоги правильно посчитал — вполне полезно.
И ты почему-то приводишь какой-то конкретный сценарий, закрывая глаза на тучи других сценариев, когда глобальный урл очень полезен.
K>Ну, а вот ещё часто в чатиках можно ссылку на пользователя добавить через @имя_пользователя. K>Там не url используется, но пользователь таки отмечается, получает уведомления и достаточно всё удобно.
Круто, но причём тут урлы? А ещё урлы кофе варить не умеют и тапочки не приносят.
K>Зря они это сделали и нужно было туда url на профиль пользователя вставлять, а не это непотребство, которое вообще не соответствует стандарту url и не глобальное?
Кому нужно?
K>·>Вот ты сам ещё одно преимущество веба выдал — веб дешевле. K>Я вообще-то по сути с этого начал
Теперь попробуй понять почему собственно веб дешевле.
K>·>Под мобилки что-ли? Мобильные приложения это не десктоп, по определению. K>И чем же мобильные приложения принципиально отличаются от десктопа?
Условия другие, модель распространения, возможности, етс.
K>·>Потому что ты тезис подменил. K>Это какой я тезис подменил?
Говорил про десктопы, потом внезапно переключился на мобилы.
K>·>Вот только количество веб-сайтов на порядки больше, чем мобильных и уж тем более десктопных. K>А бедных больше, чем богатых.
Очередной неадекватный аргумент?
K>·>Превьюшка собственно подргужается благодаря вебу же, а не магически. K>т.е. если у меня в десктопном клиенте, в каком-нибудь чатике есть в сообщении что-то типа "[-client=50]", K>то я не могу посредством SQL-запроса обратиться к БД и запросить информацию по клиенту с ИД = 50 и на каком-нибудь Canvas нарисовать какую-нибудь превьюшку в виде визитки? K>Прямо обязательно веб подтягивать нужно?
Веб нужно когда в твоём десктопном клиенте юзеру нужно сослаться не на твоего клиента в твоей бд, а на ресурс из совершенно другого источника, про который ты, как разработчик, даже и не слышал что существует. Что предложишь? CORBA или DCOM?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Откуда у тебя возьмётся установленный?
Из репозитория или магазина, которому нужно будет выдать соответствующие разрешения, дождаться установки, настроить учётную запись.
·>Оттуда же установишь и uнtернет-бaнk. Ты правда не понимаешь что такое фишинг?
Ты правда не видишь разницы между переходом по ссылке, где человека встречает знакомый интерфейс входа и переходом по ссылке, которая указывает на то, что нужно что-то установить, выдать права и т.д.?
·>Обычно для конкретно этой ситуации может и не надо. Но в принципе послать ссылку своему бухгалтеру, чтобы он налоги правильно посчитал — вполне полезно. ·>И ты почему-то приводишь какой-то конкретный сценарий, закрывая глаза на тучи других сценариев, когда глобальный урл очень полезен.
Ты почему-то мне предъявляешь претензии, как будто я призываю отказаться от веба, ссылок и всё перевести в десктоп.
Куча задач, где веб и ссылки совершенно не нужны.
Нужно — делаешь, не нужно — зачем эти ненужности?
·>Круто, но причём тут урлы? А ещё урлы кофе варить не умеют и тапочки не приносят.
При том, что и без них прекрасно обходятся и есть более удобные внутренние вещи. Не обязательно всё на урлах лепить.
·>Кому нужно?
Ну, ты мне рассказываешь, что десктоп плох, т.к. в нём нет урлов и нужно всё в вебе делать.
·>Теперь попробуй понять почему собственно веб дешевле. ·>Условия другие, модель распространения, возможности, етс.
Понятно. Чукча не читатель.
·>Говорил про десктопы, потом внезапно переключился на мобилы.
Потому что в контексте исходного вопроса там нет разницы.
Что десктоп, что мобилы — это условно нативные приложения, а веб — это когда в браузере вертится и обрабатывается всякими JS.
·>Очередной неадекватный аргумент?
А что по-твоему говорит о том, что сайтов больше, чем приложений?
·>Веб нужно когда в твоём десктопном клиенте юзеру нужно сослаться не на твоего клиента в твоей бд, а на ресурс из совершенно другого источника, про который ты, как разработчик, даже и не слышал что существует. Что предложишь? CORBA или DCOM?
Здравствуйте, karbofos42, Вы писали:
K>·>Откуда у тебя возьмётся установленный? K>Из репозитория или магазина, которому нужно будет выдать соответствующие разрешения, дождаться установки, настроить учётную запись.
Такое "счастье" можно обеспечить просто соответствующей настройкой сертификатов в браузере. Но это неюзабельно в масштабах веба.
K>·>Оттуда же установишь и uнtернет-бaнk. Ты правда не понимаешь что такое фишинг? K>Ты правда не видишь разницы между переходом по ссылке, где человека встречает знакомый интерфейс входа и переходом по ссылке, которая указывает на то, что нужно что-то установить, выдать права и т.д.?
Нет, не вижу С т.з. пользователя это какие-то неясные кнопки, которые нужно просто всегда нажимать чтобы всё заработало. Ведь все эти кнопки уже привычно нажимались при установке другого софта, а иногда и просто при обновлении или установке на других устройствах.
Думаешь почему всякие activex сдохли? Ведь там тоже надо было кучу страшных кнопок нажимать, типа для секьюрности...
K>·>Обычно для конкретно этой ситуации может и не надо. Но в принципе послать ссылку своему бухгалтеру, чтобы он налоги правильно посчитал — вполне полезно. K>·>И ты почему-то приводишь какой-то конкретный сценарий, закрывая глаза на тучи других сценариев, когда глобальный урл очень полезен. K>Ты почему-то мне предъявляешь претензии, как будто я призываю отказаться от веба, ссылок и всё перевести в десктоп. K>Куча задач, где веб и ссылки совершенно не нужны. K>Нужно — делаешь, не нужно — зачем эти ненужности?
Как я понял, ты предлагаешь переводить какие-то приложения из веба в десктоп. Если я не правильно тебя понял, то плз сформулируй свой тезис.
K>·>Круто, но причём тут урлы? А ещё урлы кофе варить не умеют и тапочки не приносят. K>При том, что и без них прекрасно обходятся и есть более удобные внутренние вещи. Не обязательно всё на урлах лепить.
Вот только чтобы эти внутренние вещи кто-то заметил, их надо как-то сделать внешними.
K>·>Кому нужно? K>Ну, ты мне рассказываешь, что десктоп плох, т.к. в нём нет урлов и нужно всё в вебе делать.
Точнее сказать, что если в десктопе урлы таки есть, то он становится удобнее. В пример та же телега — возможность послать сообщение как урл — очень полезна. Я телегу никогда не ставил и вообще в глаза не видел, но если кто-то мне кинет урл, я смогу прочитать без всяких "нужно что-то установить, выдать права и т.д.".
K>·>Говорил про десктопы, потом внезапно переключился на мобилы. K>Потому что в контексте исходного вопроса там нет разницы. K>Что десктоп, что мобилы — это условно нативные приложения,
Именно что _условно_.
K>а веб — это когда в браузере вертится и обрабатывается всякими JS.
Т.е. у тебя по сути претензия только к js. Ок, согласен. Ждём wasm.
K>·>Очередной неадекватный аргумент? K>А что по-твоему говорит о том, что сайтов больше, чем приложений?
Это разве неочевидно? Сейчас у каждого приложения как правило есть сайт. Но не наоборот. Веб гораздо массивнее приложений.
K>·>Веб нужно когда в твоём десктопном клиенте юзеру нужно сослаться не на твоего клиента в твоей бд, а на ресурс из совершенно другого источника, про который ты, как разработчик, даже и не слышал что существует. Что предложишь? CORBA или DCOM? K>URL, так же, как и сейчас
О чём спор тогда? Впрочем, почему тогда "[-client=50]"? Квадратные скобочки лучше двоеточия? Если что, то client:50 это уже валидный урл.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Такое "счастье" можно обеспечить просто соответствующей настройкой сертификатов в браузере. Но это неюзабельно в масштабах веба.
Неюзабельно = нельзя, т.к. никто это делать не будет.
·>Нет, не вижу С т.з. пользователя это какие-то неясные кнопки, которые нужно просто всегда нажимать чтобы всё заработало. Ведь все эти кнопки уже привычно нажимались при установке другого софта, а иногда и просто при обновлении или установке на других устройствах.
Только у пользователя может не быть прав на установку ПО, а вот перейти на рандомный сайтик ему никто не запретит.
·>Думаешь почему всякие activex сдохли? Ведь там тоже надо было кучу страшных кнопок нажимать, типа для секьюрности...
Их было неудобно делать и они были дырявые. Только я не понял причём тут они. ActiveX — это скорее подгрузка стороннего ПО в свой процесс, что уже идеологически не выглядит безопасно.
Расскажешь в чём секьюрность страдает, если по ссылке откроется не универсальный браузер, а специализированное приложение и каким боком тут ActiveX?
·>Как я понял, ты предлагаешь переводить какие-то приложения из веба в десктоп. Если я не правильно тебя понял, то плз сформулируй свой тезис.
Я предлагаю сделать более удобный кроссплатформенный десктоп, чтобы люди охотнее под него писали, а не как сейчас — по остаточному принципу.
·>Точнее сказать, что если в десктопе урлы таки есть, то он становится удобнее. В пример та же телега — возможность послать сообщение как урл — очень полезна. Я телегу никогда не ставил и вообще в глаза не видел, но если кто-то мне кинет урл, я смогу прочитать без всяких "нужно что-то установить, выдать права и т.д.".
Но, между тем, телега есть десктопная и она более функциональна.
Напоминаю, что я про урлы вообще ничего не говорил и это ты мне начал рассказывать, что десктоп плохо, т.к. в нём нет урлов и нельзя на что попало ссылаться.
Теперь оказывается, что в десктопе есть урлы и это удобно.
·>Именно что _условно_.
Условно, потому что какая-нибудь Java или .NET — это не нативные приложения.
·>Т.е. у тебя по сути претензия только к js. Ок, согласен. Ждём wasm.
Попробуй стартовое сообщение хотя бы прочитать в этой теме чтоли.
·>Это разве неочевидно? Сейчас у каждого приложения как правило есть сайт. Но не наоборот. Веб гораздо массивнее приложений.
Ну, вот я и говорю, что бедных больше, чем богатых, значит бедные лучше.
·>О чём спор тогда? Впрочем, почему тогда "[-client=50]"? Квадратные скобочки лучше двоеточия? Если что, то client:50 это уже валидный урл.
Ну, это ты ко мне с урлами пристал и споришь, хотя похоже, что даже не осилил прочитать моё первое сообщение.
Здравствуйте, ·, Вы писали:
·>Собственно оно и будет работать подобно десктопу. Поэтому и веб популярнее, т.к. более юзабелен.
Ну, вот это удобство и приводит к тому, что людей периодически обманывают.
С десктопом это несколько сложнее.
·>Я вроде zscaler уже упоминал. И прочие проксяки.
т.е. десктопное приложение ставить — это ужас, а прокси — элементарщина, каждая домохозяйка этим занимается?
·>Это детали. его можно подгружать и в отдельный процесс, но проблема та же — неконтролируемый бинарник.
Много на телефонах людей возникает неконтролируемых бинарников?
·>Ты умалчиваешь момент распространения установки этих самых специализированных приложений. Именно это и "Неюзабельно = нельзя, т.к. никто это делать не будет.".
Если бы ты начал с чтения, то в моём первом сообщении было указано, что сейчас на десктопе неудобно устанавливать и обновлять приложения и это одна из причин его непопулярности сегодня.
·>ActiveX — это как раз попытка сделать лёгкий способ доставки приложений. Ещё можно вспомнить java web start и подобнеые исторические казусы.
ActiveX — это была попытка сделать франкенштейнов, когда в приложение на Delphi можно встроить компонент, написанный на C++ и наоборот.
А ещё придумали засунуть это в IE, где уже и во весь рост проявилась дырявость подхода.
Потом это заменили на сервелат.
Теперь вот WebAssembly на смену пришёл.
Веб отличный и замечательный, JS быстрейший, но народ всё ещё пытается в браузере нативный код выполнять.
·>Я понимаю, что ты против всего плохого и за всё хорошее. Но ты как-то умалчиваешь детали, как же этого добиться? Пишут по остаточному принципу потому, что десктоп это фактически "неюзабельно = нельзя".
Ещё раз: я в первом своём сообщении в этой теме указал, что десктоп неудобен, поэтому все ушли в веб.
Собственно и посыл был в том, что нужно делать более удобным десктоп.
·>Но десктопная телега была бы никому не нужна без веб-версии.
Мессенджеры начинались с десктопных и мобильных java приложений. Аська и вот это всё.
Почему-то людям они были нужны, хотя веб-версий не было.
·>Ты всё перепутал. Наоборот, проблема что на десктоп ссылаться нельзя (твой пример с 1С это фейспалм какой-то). Поэтому нужна именно в первую очередь веб-аппликуха, а потом уж ценителей и профессионалов заманивают в десктоп дополнительной функциональностью.
Это что-то новое в технологиях. А когда я на ftp-сервер ссылаюсь — это веб или десктоп? А ссылка на расшаренный файл — это к чему относится?
·>Это какой-то не тот контекст. Тут нативность важна лишь в том, что у типичных десктопных приложений больше возможностей, т.к. доступно, как правило, больше, чем в браузере. ·>Если ты начнёшь устраивать песочницы и магазины как ты собирался, то в итоге это преимущество исчезнет. В итоге получится тот же самый веб по возможностям, но ограниченный недостатками десктопа.
Это твои фантазии, которые ничем не подкреплены.
·>Там было про шустрость. Причём тот js неясно. Современный js умеет jit, поэтому не сильно отличается от нативщины. Главная проблема шустрости в вебе, что оно всё сетевое.
А ещё постоянно одно и то же по сети гоняется, поэтому придумали всякие CDN и много другого веселья.
·>Тут другая логика. Зачем платить больше, если можно платить меньше с тем же результатом?
т.е. у тебя ни на компе, ни на телефоне нет нативных приложений и используешь только веб-версии, т.к. они удобнее?
Здравствуйте, karbofos42, Вы писали:
K>·>Собственно оно и будет работать подобно десктопу. Поэтому и веб популярнее, т.к. более юзабелен. K>Ну, вот это удобство и приводит к тому, что людей периодически обманывают. K>С десктопом это несколько сложнее.
Ясен пень. В чём твой поинт-то? Суть в том, что если ты сделаешь десктоп доступнее и юзабельнее, то там так же увеличится риск обмана.
K>·>Я вроде zscaler уже упоминал. И прочие проксяки. K>т.е. десктопное приложение ставить — это ужас, а прокси — элементарщина, каждая домохозяйка этим занимается?
Ты контекст подменяешь ловко. Это было в контексте "Только у пользователя может не быть прав на установку ПО" — домохозяйки по-твоему настраивают права?
K>·>Это детали. его можно подгружать и в отдельный процесс, но проблема та же — неконтролируемый бинарник. K>Много на телефонах людей возникает неконтролируемых бинарников?
Зависит от.
K>·>Ты умалчиваешь момент распространения установки этих самых специализированных приложений. Именно это и "Неюзабельно = нельзя, т.к. никто это делать не будет.". K>Если бы ты начал с чтения, то в моём первом сообщении было указано, что сейчас на десктопе неудобно устанавливать и обновлять приложения и это одна из причин его непопулярности сегодня.
Угу. Если ты сделаешь установку и обновление такое же простое как в вебе, то получишь тот же веб с теми же рисками.
K>·>ActiveX — это как раз попытка сделать лёгкий способ доставки приложений. Ещё можно вспомнить java web start и подобнеые исторические казусы. K>ActiveX — это была попытка сделать франкенштейнов, когда в приложение на Delphi можно встроить компонент, написанный на C++ и наоборот. K>А ещё придумали засунуть это в IE, где уже и во весь рост проявилась дырявость подхода. K>Потом это заменили на сервелат. K>Теперь вот WebAssembly на смену пришёл. K>Веб отличный и замечательный, JS быстрейший, но народ всё ещё пытается в браузере нативный код выполнять.
Согласен. Но магазины типа google play проблему не решает. Это очень узкая ниша если сравнивать с масшабом веба.
K>·>Я понимаю, что ты против всего плохого и за всё хорошее. Но ты как-то умалчиваешь детали, как же этого добиться? Пишут по остаточному принципу потому, что десктоп это фактически "неюзабельно = нельзя". K>Ещё раз: я в первом своём сообщении в этой теме указал, что десктоп неудобен, поэтому все ушли в веб. K>Собственно и посыл был в том, что нужно делать более удобным десктоп.
О чём я и говорю, что это неизбежное зло. Суть этого неудобства в том: "репозитория или магазина, которому нужно будет выдать соответствующие разрешения, дождаться установки, настроить учётную запись.". Если от этого неудобства избавиться, получится веб.
K>·>Но десктопная телега была бы никому не нужна без веб-версии. K>Мессенджеры начинались с десктопных и мобильных java приложений. Аська и вот это всё.
И благополучно вымерли, как и activex.
K>Почему-то людям они были нужны, хотя веб-версий не было.
Веб был очень слаб, браузеры ничего не умели и воевали друг с другом, сетевые каналы хилые. Ну не можешь ты аську реализовать в IE3 в принципе. А в FF107 — можешь.
K>·>Ты всё перепутал. Наоборот, проблема что на десктоп ссылаться нельзя (твой пример с 1С это фейспалм какой-то). Поэтому нужна именно в первую очередь веб-аппликуха, а потом уж ценителей и профессионалов заманивают в десктоп дополнительной функциональностью. K>Это что-то новое в технологиях. А когда я на ftp-сервер ссылаюсь — это веб или десктоп?
FTP умер. Впрочем, был частью веба. ftp-ссылка — внезапно является урлом.
K> А ссылка на расшаренный файл — это к чему относится?
Это не приложение. Мы вроде веб vs десктоп приложения сравниваем...
K>·>Это какой-то не тот контекст. Тут нативность важна лишь в том, что у типичных десктопных приложений больше возможностей, т.к. доступно, как правило, больше, чем в браузере. K>·>Если ты начнёшь устраивать песочницы и магазины как ты собирался, то в итоге это преимущество исчезнет. В итоге получится тот же самый веб по возможностям, но ограниченный недостатками десктопа. K>Это твои фантазии, которые ничем не подкреплены.
Это реальное положение дел. А вот у тебя фантазии: "сделаем песочницу, введём самый правильный стандарт на UI и наступит счастье".
K>·>Там было про шустрость. Причём тот js неясно. Современный js умеет jit, поэтому не сильно отличается от нативщины. Главная проблема шустрости в вебе, что оно всё сетевое. K>А ещё постоянно одно и то же по сети гоняется, поэтому придумали всякие CDN и много другого веселья.
Одно и то же, но не одним и тем же клиентам. Времена когда у семьи был один на всех компьютер давно прошли. Сейчас у каждого по несколько девайсов. Вкорячивать аппы на каждый из них из магазинов без CDN ты тоже не сможешь.
K>·>Тут другая логика. Зачем платить больше, если можно платить меньше с тем же результатом? K>т.е. у тебя ни на компе, ни на телефоне нет нативных приложений и используешь только веб-версии, т.к. они удобнее?
Есть, по минимуму. Отношение по количеству на порядка три отличается. На десяток десктопных аппов будут десятки тысяч посещённых сайтов. Представь себе если на каждый сайт придётся "выдать соответствующие разрешения, дождаться установки, настроить учётную запись."
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ты контекст подменяешь ловко. Это было в контексте "Только у пользователя может не быть прав на установку ПО" — домохозяйки по-твоему настраивают права?
С Windows Vista в винду завезли UAC по умолчанию и на всякое разное отдельно запрашиваются админские права. В линуксах ещё раньше подобное.
·>Угу. Если ты сделаешь установку и обновление такое же простое как в вебе, то получишь тот же веб с теми же рисками.
Или не с теми же. А даже если и с теми же, то нативные приложения удобнее в использовании, чем возня в браузере.
Браузер удобен в сёрфинге, а если чем-то постоянно пользуешься, то уже возникают вопросы.
Вот уже и PWA придумали, чтобы веб был ближе к нативности.
·>Согласен. Но магазины типа google play проблему не решает. Это очень узкая ниша если сравнивать с масшабом веба.
А зачем его сравнивать?
·>И благополучно вымерли, как и activex.
Кто вымер? Даже аська живее всех живых. У всех, известных мне мессенджеров, есть и десктопные и мобильные и веб-версии.
При этом не знаю ни одного человека, который бы на постоянке сидел в вебе. Или это не пользователи телеги по ссылке переходят чисто новость глянуть, либо какие-то разовые манипуляции.
·>Веб был очень слаб, браузеры ничего не умели и воевали друг с другом, сетевые каналы хилые. Ну не можешь ты аську реализовать в IE3 в принципе. А в FF107 — можешь.
Так а зачем сейчас деньги тратят на разработку десктопных версий, если веб — супер удобно и круто?
·>FTP умер. Впрочем, был частью веба. ftp-ссылка — внезапно является урлом.
Я был бы рад, если бы умер, но он живее всех живых.
Какой же это веб, если я в десктопном "проводнике" ссылки открываю, а в современных браузерах не получается (раньше в Опере вот был ftp-клиент)?
·>Это не приложение. Мы вроде веб vs десктоп приложения сравниваем...
Ну, ты говоришь, что десктопе нет ссылок. Вот я и спрашиваю как так их нет, если я их открываю в десктопных приложениях.
·>Это реальное положение дел. А вот у тебя фантазии: "сделаем песочницу, введём самый правильный стандарт на UI и наступит счастье".
т.е. iOS медленнее, чем Android работает из-за песочницы?
·>Одно и то же, но не одним и тем же клиентам. Времена когда у семьи был один на всех компьютер давно прошли. Сейчас у каждого по несколько девайсов. Вкорячивать аппы на каждый из них из магазинов без CDN ты тоже не сможешь.
·>Есть, по минимуму. Отношение по количеству на порядка три отличается. На десяток десктопных аппов будут десятки тысяч посещённых сайтов.
А если не сайты считать, а то, что ежедневно используется или часто?
Ну, мессенджеры там, интернет-банки, офисные приложения,... ?
·>Представь себе если на каждый сайт придётся "выдать соответствующие разрешения, дождаться установки, настроить учётную запись."
Зачем мне этот бред представлять? Это ты придумал, что в живых должен остаться только один, я такого не предлагал.
Здравствуйте, karbofos42, Вы писали:
K>·>Ты контекст подменяешь ловко. Это было в контексте "Только у пользователя может не быть прав на установку ПО" — домохозяйки по-твоему настраивают права? K>С Windows Vista в винду завезли UAC по умолчанию и на всякое разное отдельно запрашиваются админские права. В линуксах ещё раньше подобное.
Ага. Но права у домохозяйки таки есть, обязательно надо нажать "да, ясен пень" в диалоге элевации, иначе, каждая домохозяйка знает, ничего не заработает.
K>·>Угу. Если ты сделаешь установку и обновление такое же простое как в вебе, то получишь тот же веб с теми же рисками. K>Или не с теми же. А даже если и с теми же, то нативные приложения удобнее в использовании, чем возня в браузере. K>Браузер удобен в сёрфинге, а если чем-то постоянно пользуешься, то уже возникают вопросы. K>Вот уже и PWA придумали, чтобы веб был ближе к нативности.
Причём тут нативность? Просто по сути отдельная иконка на десктоп, которая открывает тот же браузер, просто без рамочки.
K>·>И благополучно вымерли, как и activex. K>Кто вымер? Даже аська живее всех живых. У всех, известных мне мессенджеров, есть и десктопные и мобильные и веб-версии.
ICQ?! Нифига себе. Лет 20 уж не видел. Где ты её нашел и сколько там живых контактов?
K>При этом не знаю ни одного человека, который бы на постоянке сидел в вебе. Или это не пользователи телеги по ссылке переходят чисто новость глянуть, либо какие-то разовые манипуляции.
Ну не все, mattermost например только веб, ну плюс pwa афаир.
K>·>Веб был очень слаб, браузеры ничего не умели и воевали друг с другом, сетевые каналы хилые. Ну не можешь ты аську реализовать в IE3 в принципе. А в FF107 — можешь. K>Так а зачем сейчас деньги тратят на разработку десктопных версий, если веб — супер удобно и круто?
Затачивают под определённый десктоп, для более широкого функционала.
K>·>FTP умер. Впрочем, был частью веба. ftp-ссылка — внезапно является урлом. K>Я был бы рад, если бы умер, но он живее всех живых.
Legacy.
K>Какой же это веб, если я в десктопном "проводнике" ссылки открываю, а в современных браузерах не получается (раньше в Опере вот был ftp-клиент)?
В браузерах его просто отключили.
K>·>Это не приложение. Мы вроде веб vs десктоп приложения сравниваем... K>Ну, ты говоришь, что десктопе нет ссылок. Вот я и спрашиваю как так их нет, если я их открываю в десктопных приложениях.
Я это не говорил. Ты два раза прочитал неправильно. Повторю третий раз: "на десктоп ссылаться нельзя". Обрати внимание на падеж.
K>·>Это реальное положение дел. А вот у тебя фантазии: "сделаем песочницу, введём самый правильный стандарт на UI и наступит счастье". K>т.е. iOS медленнее, чем Android работает из-за песочницы?
Что?
K>·>Одно и то же, но не одним и тем же клиентам. Времена когда у семьи был один на всех компьютер давно прошли. Сейчас у каждого по несколько девайсов. Вкорячивать аппы на каждый из них из магазинов без CDN ты тоже не сможешь. K>·>Есть, по минимуму. Отношение по количеству на порядка три отличается. На десяток десктопных аппов будут десятки тысяч посещённых сайтов. K>А если не сайты считать, а то, что ежедневно используется или часто? K>Ну, мессенджеры там, интернет-банки, офисные приложения,... ?
Не знаю точно, не считал. По ощущениям в браузере я провожу больше времени, чем в других приложениях, по крайней мере не на работе. На работе, ясно, IDE основное.
K>·>Представь себе если на каждый сайт придётся "выдать соответствующие разрешения, дождаться установки, настроить учётную запись." K>Зачем мне этот бред представлять? Это ты придумал, что в живых должен остаться только один, я такого не предлагал.
Да даже пусть мессенджеры. Вот проходил я недавно кучу интервью. У кого-то zoom, у кого-то в teams, у кого-то ещё что. И всё работало в браузере. Не стал бы я ставить себе такой зоопарк локально ради пары недель.
В общем суть такова, что идёт всё в веб, а не обратно. Десктоп как временное, пока функциональность не доросла в браузерах. Ну и для массивных вещей. Игрушку на 100гб конечно лучше поставить.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
BFE>>·>Канал у типичного юзера, как правило, один. BFE>>Так он у него так и так один. ·>Вот именно. Пакеты пойдут по тому же каналу и просядет перформанс.
Да щаз!
Вот тут он просядет, а вот тут — нет. Ну вот с чего бы, если передаются одни и те же данные?
·>thus earning the QUIC protocol the occasional nickname "TCP/2".
Мало ли как его обзывают, написан он поверх UDP.
·>Просто вариация TCP оптимизированная для определённых сценариев.
Ну да. Для определённых сценариев.
Здравствуйте, ·, Вы писали:
·>ICQ?! Нифига себе. Лет 20 уж не видел. Где ты её нашел и сколько там живых контактов?
Всё на том же icq.com.
·>Ну не все, mattermost например только веб, ну плюс pwa афаир.
Так люди в мессенджерах пользуются удобными веб-версиями или качают неудобные нативные приложения в большинстве своём?
·>Затачивают под определённый десктоп, для более широкого функционала.
т.е. десктоп таки функциональнее веба?
·>Я это не говорил. Ты два раза прочитал неправильно. Повторю третий раз: "на десктоп ссылаться нельзя". Обрати внимание на падеж.
Ну, тогда и на веб нельзя ссылаться
·>Что?
Ну, говорят, что в iOS приложения в песочнице работают, значит там должно всё медленно работать.
·>Да даже пусть мессенджеры. Вот проходил я недавно кучу интервью. У кого-то zoom, у кого-то в teams, у кого-то ещё что. И всё работало в браузере. Не стал бы я ставить себе такой зоопарк локально ради пары недель.
А кто-то заставляет?
·>В общем суть такова, что идёт всё в веб, а не обратно. Десктоп как временное, пока функциональность не доросла в браузерах. Ну и для массивных вещей. Игрушку на 100гб конечно лучше поставить.
А причём тут куда идёт? По факту на горизонте пока нет никаких предпосылок к новой популярности десктопа.
Скорее наоборот через всякие WebAssembly его будут дальше добивать и натягивать что попало на веб-технологии.
Только тема вроде не о том, что есть сейчас по факту
Здравствуйте, 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 быстрейший
То то некоторым сайтам надо современный проц чтоб приемлемо шевелиться.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Ссылаются на ресурс, а не на какой-то там веб.
Более того: все ссылки в итоге обрабатывают нативные приложения. Этим приложением может выступать браузер, либо что-то узкоспециализированное.
·>Почему значит?
Ну, ты писал, что песочница и все эти разрешения — это медленно и нативный код будет работать на уровне JS.
·>Про медленность я имел в виду, что клик по ссылке веба тебе выдаёт контент через пару секунд. А в случае десктопа потребуется магазин, установка, пермишенны, етс, то время вырастет на пару порядков.
Ну, ты сам придумал, что прямо всё уйдёт из веба в десктоп и для просмотра мемасиков придётся ставить отдельное приложение.
Никто не мешает делать обработку ссылок так, что если есть установленный телеграм, то открывать ссылку в нём, нет — открываем веб-версию в браузере.
Открытие ссылок в браузере за пару секунд проходят только в простейших случаях.
По факту и с браузерами безудержное веселье периодически:
приходит ссылка в мессенджер на какую-нибудь CRM/ERP/... переходишь — она открывается в браузере по умолчанию, но для этого ресурса нужно какое-нибудь ГОСТ-шифрование или доступ через прокси должен идти и потому настроено отдельно в Яндекс.Браузере.
В итоге копируешь ссылку и вручную вставляешь в Яндекс.Браузер, там оказывается, что куки протухли или кэш очищался и автологин отвалился. Перенаправляет на страницу входа. Вводишь таки логин, пароль, а разработчики перенаправление на исходную ссылку не осилили и показывают главную страницу, т.е. нужно опять ту ссылку вручную вставлять.
·>А ещё рано или поздно придётся подчищать всякий установленный хлам.
Как-будто тот же браузер в кэше всякое не собирает и не жрёт память почём зря.
·>Если бы присылали какой-нибудь скайп, который надо ставить, то было бы всё гораздо сложнее.
Ещё раз: я где-то писал, что весь веб нужно убить и вместо него сделать такой же десктоп?
Я лишь написал, что нужно в десктоп завести плюшки из веба и тогда к нему народ потянется.
Хочешь удобство и функционал — ставишь десктопную версию.
Хочешь что-то быстренько посмотреть — используешь урезанную веб-версию.
Что-то подобное и сейчас есть, только у большинства компаний нет денег на десктопную версию и потому выжимают всё из веба и даже не пытаются делать нормальный десктоп.
Здравствуйте, CreatorCray, Вы писали:
BFE>> Ну и логично сразу от клиента направить запрос с дублированием для скорости в случае если один из клиентов не ответит. CC>Т.е. вместо того, чтоб сразу взять с сайта, у которого канал толщиной с ногу и с которым у тебя уже установлено соединение, ты будешь рассылать запросы на деревню дедушке в надежде что у кого то из них окажется и нужная тебе хреновина и исходящий канал будет толще чем у сервака.
Ну, можно же сделать это и помягче.
Во-первых, сервер может отдавать вместе с данными хинты, типа "реплики данных лежат ещё и вот здесь". Для микро-запросов это будет не очень актуально, а вот когда тянется какой-то большой ресурс, клиент может параллельно дёрнуть ещё несколько вариантов и тащить разные куски с разных адресов через range header. К различным толщинам каналов можно и адаптироваться — c быстрого тащим гигабайт, с медленного 10кб.
Во-вторых, при определённых усилиях сервер может отдавать не все хинты подряд, а выполнять кластеризацию по адресу. Типа "реплики данных лежат ещё и вот у этих твоих соседей"
Но это всё нужно тщательно просчитывать, и далеко не для всякого типа сетевой нагрузки это вообще подойдёт.
BFE>>Протокол BitTorrent работает поверх веба? CC>Не то чтобы поверх. Есть extensions которые умеют всяко подтягивать с HTTP но сам протокол к вебу не имеет отношения.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>а вот когда тянется какой-то большой ресурс
А что в вебе будет считаться большим ресурсом?
S>, клиент может параллельно дёрнуть ещё несколько вариантов и тащить разные куски с разных адресов через range header. К различным толщинам каналов можно и адаптироваться — c быстрого тащим гигабайт, с медленного 10кб.
Т.е. это переизобретение торрента, вот только нету в типичном вебе таких размеров файлов чтоб это было оправдано. А самая большая проблема это то, что клиенты ну совсем не хотят у себя что то хранить и раздавать.
S>Но это всё нужно тщательно просчитывать, и далеко не для всякого типа сетевой нагрузки это вообще подойдёт.
Разумеется.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали: CC>А что в вебе будет считаться большим ресурсом?
Сотни мегабайт. CC>Т.е. это переизобретение торрента,
Да, совершенно верно. CC>вот только нету в типичном вебе таких размеров файлов чтоб это было оправдано.
Во-первых и так есть контент вроде видео. Понятно, что для него можно переключаться на специализированный протокол — те же торренты сейчас более-менее любым плеером играются.
Во-вторых, размеры ресурсов современного типичного веба такие не только в силу объективных обстоятельств, но и в силу архитектуры.
Если мы заменяем JS на бинари, то упаковывать весь сайт в небольшое количество крупных кусков, которые быстро приезжают через торрентоподобный протокол, может оказаться выгоднее, чем резать его на тысячи килобайтных "скриптиков". CC>А самая большая проблема это то, что клиенты ну совсем не хотят у себя что то хранить и раздавать.
А кто их будет спрашивать? Вон торренты тащат и не жужжат, что во время скачивания они безусловно раздают пирам готовые блоки.
Если итоговые потребительские характеристики такого протокола будут лучше, чем у конкурентов, то включат и будут пользоваться. И будут считать само собой разумеющимся, что код нетфликс-клиента приезжает за долю секунды через сотню запросов по соседям, вместо вот этого "хотите ли поставить обновление? Ждите пять минут.... четыре минуты.... три минуты... десять минут...", когда хочется уже новую серию включить и пиво греется.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
CC>>вот только нету в типичном вебе таких размеров файлов чтоб это было оправдано. S>Во-первых и так есть контент вроде видео.
Оно ж всё стриминговое, ну, кроме собственно торрента
Подкачивается нужный кусок и на клиенте не хранится ибо объёмы.
Так что надо ещё найти того, кто смотрит нужный тебе ролик в том же самом месте.
S>А кто их будет спрашивать? Вон торренты тащат и не жужжат, что во время скачивания они безусловно раздают пирам готовые блоки.
Ха, только вот сидов фиг найдёшь порой.
S>Если итоговые потребительские характеристики такого протокола будут лучше
Дык пока не похоже чтоб они были.
S> то включат и будут пользоваться.
Тоже очень сомнительно. Инерционность тут огромная.
S>код нетфликс-клиента приезжает за долю секунды через сотню запросов по соседям, вместо вот этого "хотите ли поставить обновление?
Мы всё ещё про веб? Вон, youtube.com никаких обновлений не требует, работает мнгновенно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 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 есть у ботнетных нод, а тем, кто на ноды за ними приходит — отдавать малварь
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>·>А если ещё рассматривать malicious attacks, то "злые" пиры могут просто в ответ всякий мусор слать, ддося твой канал. CC>Там ещё веселее можно сделать: засирать кэш пиров сайта запрашивая с ботнета какой нить из js от страницы чтоб сайт думал что этот js есть у ботнетных нод, а тем, кто на ноды за ними приходит — отдавать малварь
Я об этом тоже думал, но от этого легко защититься — контент идентифицировать и проверять криптографическим хешем. Впрочем, это лишняя нагрузка на cpu.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
