Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от opennews (??), 22-Авг-20, 11:57
Компания Google приступила к реализации в Chrome нового API Raw Sockets, позволяющего web-приложениям  устанавливать прямые сетевые соединения с использованием протоколов TCP и UDP. В 2015 году консорциумом W3C уже была предпринята попытка стандартизации API TCP and UDP Socket, но участники рабочей группы не достигли консенсуса и разработка данного API была остановлена... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53582
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+32 +/–
Сообщение от Аноним (1), 22-Авг-20, 11:57
Ддос-боты на жаваскрипте уже были? Теперь точно будут
Ответить | Правка | Наверх | Cообщить модератору

2. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+31 +/–
Сообщение от Аноним (2), 22-Авг-20, 12:02
Звучит адски опасно. Нужно блокировать.
Ответить | Правка | Наверх | Cообщить модератору

3. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+46 +/–
Сообщение от Michael Shigorin (ok), 22-Авг-20, 12:06
Гуголь -- ведущий специалист по ящикам Пандоры.
Ответить | Правка | Наверх | Cообщить модератору

	66. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–2 +/–
	Сообщение от Константавр (ok), 22-Авг-20, 18:04
	Интересно, есть ли у пользователя возможность всё это блокировать? И даже не на уровне браузера, а на уровне операционки хотелось бы.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от n80 (?), 22-Авг-20, 18:25
	> Интересно, есть ли у пользователя возможность всё это блокировать? И даже не > на уровне браузера, а на уровне операционки хотелось бы. Можно начать с man firejail. Хотя лучше, конечно, начать с конкретизации того, что именно подразумевается под «всё это».
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от гугль (?), 22-Авг-20, 18:50
	есть, только ни один сайт кроме опеннета работать не будет.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	167. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от rvs2016 (ok), 25-Авг-20, 16:09
	> И даже не на уровне браузера, а на уровне операционки хотелось бы. Слово "операционка" знают только такие старики, как мы. А остальным вместо "операционка" говорят - "прошивка"! 😲
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	74. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–5 +/–
	Сообщение от КПСС (?), 22-Авг-20, 20:15
	А ведь у Миши куча альтернатив. Тока сд-диски с ними не читаются.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	76. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+15 +/–
	Сообщение от Тот_Самый_Анонимус (?), 22-Авг-20, 21:00
	Нелюбовь к Шигорину настолько велика, что заставляет критиковать верные его утверждения. И ведь в нашей стране вся оппозиция такая.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (129), 23-Авг-20, 15:24
	Мы воюем с людьми, а не с идеями. Если П*тин скажет "не жрать младенцев" - тем хуже для младенцев.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+2 +/–
	Сообщение от Брат Анон (?), 24-Авг-20, 08:50
	Давай-ка, брат анон -- за себя. Столько ответственности берёшь, что не унесёшь.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–2 +/–
	Сообщение от Аноним (129), 24-Авг-20, 12:27
	Кто не готов брать на себя ответственность - так и останется ведомым барашком в стаде. И отправится с остальным стадом на заклание, если ответственные люди решат, что так лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Брат Анон (?), 26-Авг-20, 11:08
	> Кто не готов брать на себя ответственность - так и останется ведомым > барашком в стаде. Ещё раз тебе повторяю: отвечай за себя. Я уже давно половозрелый мальчик.
	Ответить | Правка | Наверх | Cообщить модератору

	204. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
	Сообщение от Тот_Самый_Анонимус (?), 03-Сен-20, 08:00
	> Ещё раз тебе повторяю: отвечай за себя. Я уже давно половозрелый мальчик. Возможно и половозрелый. Тогда должен понимать что большинство протестунов именно такие, как описанно выше. И мы не обязаны перелопачивать гору нечистот, только потому что в ней может оказаться пара алмазов. Ведь вероятность этого стремится к нулю.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Kusb (?), 23-Авг-20, 09:23
	Я умею читать сд-диски. Но только там, где надписи и этикетка.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	152. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (-), 24-Авг-20, 14:08
	>сд-диски с ними не читаются. это Вы что сейчас написали - короткое SMS-сообщение, да?
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	154. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+3 +/–
	Сообщение от Аноним (154), 24-Авг-20, 15:41
	"Гуголь" не изобрел ничего нового. Просто поймите, в корпоративном сегменте в 2020-ом году одновременно окончательно умирают Internet Explorer и лучший друг его Flash Player. Тем временем задачи, которые решала эта парочка никуда не умирают и не могут быть портированы даже на WebSocket. Нет, ну, если вы критикуете, то предлагайте, ну или хотя бы участвуйте в обсуждениях. ИМХО, уж лучше переделать адаптировать сокеты Flash Player под новую реальность и адаптировать концепцию доверенных зон сайтов из IE (хром, на минуточку, её уважает), чем продолжать использовать IE и Flash в 2021-ом. Тут главное, чтобы был выдан запрет на всё это по умолчанию, если разрешение не выдано явно и чтобы список разрешений лежал не только в опциях, но также контролировался через Ansible, GPO. Все эти технологические решения помимо бизнес-приложений тянет VoIP. В мире VoIP необходимо не просто замерить MOS, важно разделить его на отрезки. Как вы поймете причину деградацию WebRTC-звонка без анализа потерь на отрезке Браузер <-> Блютус-гарнитура? В условиях, когда используется протокол ICE, необходимо по факту завершения звонка понять, где была деградация. Веб приложение и его Rich Client должны по-разному действовать, если у человека гарнитура разряжается или есть проблема с TURN сервером, через который пошел медиапоток или там вообще TURN-сервера нет и проблема на стыке двух ISP или может во всем виноват IPv6, который работает на клиенте, но имеет высокий Jitter по вине рукопопости провайдера последней мили. И как прикажете принимать такие решения без доступа к Bluetooth? Ну и я не говорю о том, что в связи с грядущим RTP over QUIC https://tools.ietf.org/html/draft-rtpfolks-quic-rtp-over-qui... Я даже не уверен, что в реалиях HTTP3 от самого WebRTC вообще что-то останется, потому что не понятно, зачем сигнализацию тогда уже гнать отдельно, да и это API в сочетании с QUIC в перспективе отправляет на свалку весь WebSocket. Я даже не предлагаю сделать лучше, хотя бы предложите.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	155. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от freehck (ok), 24-Авг-20, 17:06
	Плюсую. Данный аноним дело говорит. Раньше Flash предоставлял возможности работы с TCP/UDP-сокетами. Этим пользовались, и до сих пор пользуются. В частности, многие flash-игры с клиент-серверной архитектурой зависят от этого функционала: и одно дело переписать клиент, потому как flash умер де факто, а совсем другое -- переписать ещё и сервер, потому что старый протокол общения уже никак не реализовать. Это уже другие деньги, и подобная инициатива, быть может, спасёт малые проекты, которые не могут себе позволить столь масштабные изменения.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (162), 24-Авг-20, 20:36
	> Я даже не предлагаю сделать лучше, хотя бы предложите. Сделать из браузера ChromeOS или есть же Android. И да, сделать лучше, кому? ;)
	Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

	168. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от rvs2016 (ok), 25-Авг-20, 16:14
	> Тут главное, чтобы был выдан запрет на всё это по умолчанию, > если разрешение не выдано явно Идея запроса разрешений у пользователя в основном бесполезна потому, что когда для нормальной работы программы на пользователя наваливают большую кучу запросов на предоставление прав, то абсолютное большинство пользователей не читает тексты запросов, а ищет быстрее кнопочки типа "да", "предоставить", "разрешить" для того, чтобы быстрее прорваться через лес этих запросов и наконец-то запустить нужную ему программу. Т.е. идея запросов разрешений у пользователя с виду вроде бы хороша, но по факту - в основном бесполезна.
	Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

	211. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (-), 09-Янв-21, 17:09
	Как они представляют себе вообще запросы к DHT c подтверждениями? Это ж каждую секунду по десяток подтверждений во все стороны придется.
	Ответить | Правка | Наверх | Cообщить модератору

4. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от Аноним (4), 22-Авг-20, 12:07
localhost уже не безопасно?
Ответить | Правка | Наверх | Cообщить модератору

	9. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+3 +/–
	Сообщение от Аноним (9), 22-Авг-20, 12:18
	давно уже. с читым tcp/udp это вообще кошмар будет - локалки и прочие дмз будут ломаться на раз два в гугле какие-то долбоящеры работают:)
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (9), 22-Авг-20, 12:57
	если что dmz бывают (хоть и редко) с globally routable адресами
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Онаним (?), 22-Авг-20, 21:55
	Оно без спросу не полезет. Ну и для админов всегда оставляли возможность отключить.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	103. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+2 +/–
	Сообщение от admgoat (?), 23-Авг-20, 06:43
	ну да а потом читаем что-то типа WebRTC leak local address
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (154), 25-Авг-20, 21:47
	>  WebRTC leak local address Меня всегда удивляло пещерное скудоумие вокруг этой темы, но, видимо, это неизбежно. Телефонные протоколы уже лет 10 как дошли до такой стадии, что обычный системный администратор их не понимает. Протокол задумывался 15 лет назад, а существует и стандартизирован как раз 10 лет назад. Последняя ревизия вот: https://tools.ietf.org/html/rfc8445 Есть некий протокол установки сессий не важно WebRTC это или SIP, и он отвечает за установку сессий в пиринговой сети. Задача установить оптимальное соединение между n-участниками сессии. Логика в том, что нет смысла устанавливать внешний маршрут, если участники в одной и той же подсети. Нет смысла устанавливать сессию IPv4, если все поддерживают v6. А если используется IPv4 NAT, то нужно его обойти, вне зависимости от 1001 вида параметров NAT устройств и параметров на стороне роутеров и стороне провайдера. Вот протокол и собирает все IP адреса на всех сетевых адаптерах, включая и TAP, и TUN за минусом: - Loopback - туннельные адреса v6 6to4/6in4/Teredo - v6 link-local - v6 с поддержкой location tracking Помимо прочего туда попадут адреса, которые вернут STUN и TURN Дальше начинаем попарно пробовать установить соединение в форме звезды, учитывая приоритеты кандидатов. Обыватель обычно спрашивает, зачем так сложно. Дурак начинает бочку гнать на VoIP, даже не подозревая, насколько там всё устандартизировано до морковкина заговенья по сравнению с, внезапно, NAT. Если бы NAT был жестким стандартом, который бы одинаково выполняли бы все вендоры, если бы бараны-вендоры не городили ALG для SIP/RTP каждый по-своему ломая спецификацию и если была только одна версия IP, то не было бы никаких ICE. Увы, если бы да кабы, то во рту бы выросли грибы и был бы не рот, а целый огород. Собственно, этим ртом все и будут жрать оверинжиниринг в виде протоколов ICE+STUN+TURN. Кушайте с маслом, не обляпайтесь. =) И вот эти чудилы опять выходят на связь, ноя про утечку их локального IP. Что только не придумают, лишь бы фаервол не настраивать. Запомните, люди: 1. IP-адрес - это не секрет. Он на то и адрес, чтобы с ним можно было связаться. 2. NAT - это средство подмены адресов в заголовках пакетов, а не средство безопасности. Для безопасности есть цепочки INPUT и FORWARD и не только на роутере, а в первую очередь на самом ПК. 3. ICE запрещает трекинг хоста, но не даёт анонимности. В телефонии нет и не может быть анонимности по-определению и по закону (исключение разве что США, но ни в РФ, ни в ЕС нельзя скрываться). Там очень много сделано именно для того чтобы удостоверять пользователя. Мир интернета уже один раз совершил ошибку, попытавшись переизвобрести SIP и ему смежные протоколы. Попытка кончилась провалом (XMPP Jingle). При разработке WebRTC они взяли нормальные телефонные стандарты и гляньте, взлетело. Осталось только выкинуть слово Web из WebRTC и куча проблем решится.
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
	Сообщение от admgoat (?), 26-Авг-20, 03:44
	вкключи WebRTC и отключи UBO и зайди сюда.. https://browserleaks.com/webrtc появился ЛОКАЛЬНЫЙ адрес? хорошо файервол настроен? )) нравится что "обычная" связь с WEB сервером якобы по HTTP идентифицирует тебя внутри твоей подсети?
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (154), 26-Авг-20, 11:57
	Прочитай то что написано выше. Оно ДОЛЖНО выдать твой серый IP. Это протокол такой в этом его смысл. На тебя, видимо, чарующе подействовало, как и на других недалёких, что сайт угадал твой серый IP. Но это не ошибка и не угроза безопасности. Твой браузер сообщил этот IP на сервер в чем проблема то? Софтфоны, например, все сделают так же. > нравится что "обычная" связь с WEB сервером якобы по HTTP идентифицирует тебя внутри твоей подсети? Во-первых да. Это сильно не выпускает пиринговые соединения из LAN в WAN. Во-вторых, сделайте домашку перед тем как распространять паранойю. В-третьих, "якобы по HTTP" - это ложь. WebRTC это VoIP поверх HTTP. Вы так говорите будто интернет браузер - это такой софт для работы с протоколом HTTP. Святая наивность... юноша, вы хоть новость прочитайте... подумайте, причем тут HTTP.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+3 +/–
	Сообщение от Аноним (129), 23-Авг-20, 15:25
	> Оно без спросу не полезет. Ну и для админов всегда оставляли возможность отключить. Все запросы и подтверждения будут выпилены через пару релизов Chrome для улучшения user experience. Возможность отключить - ещё через пару релизов, как "невостребованная".
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

5. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+19 +/–
Сообщение от аноним еще один (?), 22-Авг-20, 12:08
Не пора ли вернутся к истокам выкинуть из браузеров все кроме html ? Остальное только через дополнения, тем кому нужно будет.
Ответить | Правка | Наверх | Cообщить модератору

	11. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от A.Stahl (ok), 22-Авг-20, 12:18
	Вот-вот. Предполагаю, что все те два десятка действительно полезных применеий ЯваСкрипта (вроде сортировки таблиц и... гхм, ну, наверное, ЯваСкрипт может делать что-то ещё полезное) можно впихнуть в HTML.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Ананимас008 (?), 23-Авг-20, 05:35
	сортировку таблиц тормозным жабаскриптом можно заменить нативной сортировкой с атрибутами для table и тегами внутри его. sortonclick и вот это все. давно пора сделать замену скриптокостылям и включить наиболее используемые в стандарт, чтобы не было идиотизма вроде лефтпада.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–3 +/–
	Сообщение от admgoat (?), 23-Авг-20, 06:44
	XMLHttpRequest надо...
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	108. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от A.Stahl (ok), 23-Авг-20, 07:24
	> XMLHttpRequest надо... <form action method> тебе хватит.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от admgoat (?), 23-Авг-20, 13:23
	>> XMLHttpRequest надо... > <form action method> тебе хватит. не хватит! каким образом мне избежать сабмита формы и перезагрузки страницы?
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от A.Stahl (ok), 23-Авг-20, 14:06
	Никак. Да и не надо это. Странная хотелка-то изначально.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (159), 24-Авг-20, 19:36
	Еще скажи что все эти RIA приложение или как они там писанные на Angular и React это все сплошной кошмар.
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
	Сообщение от admgoat (?), 25-Авг-20, 19:10
	> Никак. Да и не надо это. Странная хотелка-то изначально. аргументы будут или продолжишь фуфло свое пихать?
	Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

	169. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от rvs2016 (ok), 25-Авг-20, 16:19
	> XMLHttpRequest надо... Он же существует не первый десяток лет. Вот XMLHttpListen(ListenPort, callback) давно нужен, но его до сих пор нет...
	Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

	176. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от n80 (?), 25-Авг-20, 17:04
	> Вот XMLHttpListen(ListenPort, callback) давно нужен, но его до сих пор нет... А для чего нужен-то, какую распространённую задачу предполагается решить?
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от rvs2016 (ok), 25-Авг-20, 17:45
	>> Вот XMLHttpListen(ListenPort, callback) давно нужен, но его до сих пор нет... > А для чего нужен-то, какую распространённую задачу предполагается решить? Вот тут в разделе в конце сообщения в разделе "вот зачем" я привёл пример одной из задачек: https://www.opennet.dev/openforum/vsluhforumID3/121647.html#177 На счёт распространённости такого типа задачек я обольщаться не буду, но мне простые методы решения таких задачек не помешали бы. ps: Макс, ну отмени проверку сообщения капчей, если в сообщении есть ссылки только на опеннет. :-)
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от n80 (?), 25-Авг-20, 18:09
	Угу, я там ответил более-менее подробно, если что — могу ещё постараться расписать. Вкратце: это решение немного не на том уровне, а на более подходящих уже есть некоторые решения (и дошли до следующей ступени, с новыми проблемами).
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от admgoat (?), 25-Авг-20, 19:09
	>> XMLHttpRequest надо... > Он же существует не первый десяток лет. > Вот XMLHttpListen(ListenPort, callback) давно нужен, но его до сих пор нет... так прошла говноидея его отменить ))) а слушать порт не получится.. кто будет его за NAT пробрасывать и/или открывать порт файервола?
	Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

	184. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от rvs2016 (ok), 25-Авг-20, 19:58
	>>> XMLHttpRequest надо... >> Он же существует не первый десяток лет. >> Вот XMLHttpListen(ListenPort, callback) давно нужен, но его до сих пор нет... > так прошла говноидея его отменить ))) > а слушать порт не получится.. > кто будет его за NAT пробрасывать и/или > открывать порт файервола? Как связаться с за-NAT-овскими браузерами - дайте программисту возможность порешать эти занимательные и прелюбопытнейшие задачки самостоятельно. Не отнимайте у него эту возможность предложением решить эти задачки вместо него кому-то. :-)
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от n80 (?), 25-Авг-20, 21:08
	> Как связаться с за-NAT-овскими браузерами - дайте программисту возможность порешать эти > занимательные и прелюбопытнейшие задачки самостоятельно. Не отнимайте у него эту возможность > предложением решить эти задачки вместо него кому-то. :-) Уже давали. Один FTP (на самом деле ещё IRC, SIP и ещё пачка протоколов, «замечательных» с точки зрения настройки шлюза) у нас уже есть, хватит. Иногда лучше всё-таки отнять, к сожалению. Да, я помню в какие годы эти протоколы появлялись и что тогда таких проблем и близко не было. Но то что до сих пор приходится страдать и городить костыли — очень показательно. Пусть программисты всё-таки решают прикладные, пользовательские задачи, а удовлетворение своего технического зуда оставят на уровне хобби. Тем более, если у кого-то в рамках его увлечения получается что-то достойное, оно таки найдёт своё применение (тут можно вспомнить разные удачные P2P программы, которые [были] настолько хороши, что всё-таки нашли своих пользователей, не смотря на всякие «ни бум-бум»).
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от admgoat (?), 26-Авг-20, 03:48
	>>>> XMLHttpRequest надо... >>> Он же существует не первый десяток лет. >>> Вот XMLHttpListen(ListenPort, callback) давно нужен, но его до сих пор нет... >> так прошла говноидея его отменить ))) >> а слушать порт не получится.. >> кто будет его за NAT пробрасывать и/или >> открывать порт файервола? > Как связаться с за-NAT-овскими браузерами - дайте программисту возможность порешать эти > занимательные и прелюбопытнейшие задачки самостоятельно. Не отнимайте у него эту возможность > предложением решить эти задачки вместо него кому-то. :-) что за абсурд вы несете сударь? бразуер предоставляет апи, которое не работает.. например UPnP вырублен. вывод нам не нужно нах такое апи.. а куда вас понесло я в душе не ебу
	Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

	12. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (12), 22-Авг-20, 12:27
	Часть CSS всё равно придётся оставить.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	20. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–3 +/–
	Сообщение от Онаним (?), 22-Авг-20, 13:29
	Выкинуть вместе с жабаскриптом и вернуться к запросу на каждое изменение поля ввода :D Вот веселуха-то будет. Желающие выкинуть первыми взад (в зад?) попросятся.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+5 +/–
	Сообщение от Аноним (22), 22-Авг-20, 13:33
	CSS это как отображать, а HTML что отображать. Т.е. Жабоскрипту оно, как-то, ортогонально.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Онаним (?), 22-Авг-20, 21:56
	Не важно, всё равно выкинуть. Какой ещё вам CSS, и даже пропертю style выкинуть. К истокам, так к истокам.
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Навальный (?), 24-Авг-20, 09:10
	Только plane text, только хардкор!
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от A.Stahl (ok), 25-Авг-20, 09:11
	> Только plane text, только хардкор! Хардкор то твой английский :)
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от rvs2016 (ok), 25-Авг-20, 16:21
	> Только plane text, только хардкор! Gopher? :-)
	Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

	21. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–2 +/–
	Сообщение от Онаним тот самый (?), 22-Авг-20, 13:30
	Который научили делать почти всё, что делалось жабаскриптом
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	36. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
	Сообщение от Козлетто (?), 22-Авг-20, 14:47
	Пришло время вернуться в Фидонет!
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	45. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (45), 22-Авг-20, 15:43
	Gopher.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от A.Stahl (ok), 22-Авг-20, 15:48
	Hamster. Xhamster.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+2 +/–
	Сообщение от asdf (?), 22-Авг-20, 16:23
	отключить розетку
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (85), 22-Авг-20, 23:24
	Обязательно гипертекстовый, как вещает камрад Мицгол.
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	160. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (159), 24-Авг-20, 19:37
	Ну велком че https://github.com/vit1251/golden
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+3 +/–
	Сообщение от Fff (?), 22-Авг-20, 16:21
	Проще выкинуть html.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	171. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
	Сообщение от rvs2016 (ok), 25-Авг-20, 16:22
	> Проще выкинуть html Ну да. Есть же емайл. До сих пор жив. Хотя молодёжь со своими вацапо-инстаграмами о нём и не знает уж.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–2 +/–
	Сообщение от Аноним (124), 23-Авг-20, 14:20
	Да и html стоит заменить на что-то более лаконичное и человекопонятное, вроде QML.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	156. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от freehck (ok), 24-Авг-20, 17:10
	> Не пора ли вернутся к истокам выкинуть из браузеров все кроме html? Да как бы гофер всё ещё существует. Бога ради, пользуйтесь. Там правда нет нифига, но тем не менее.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

6. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+3 +/–
Сообщение от grayich (ok), 22-Авг-20, 12:11
учитывая что localhost часто не фаерволится и вообще открыто всё... будет интересно как хром будет долбить 127.0.0.1
Ответить | Правка | Наверх | Cообщить модератору

7. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+3 +/–
Сообщение от Аноним (7), 22-Авг-20, 12:15
>Для предотвращения DDoS-атак интенсивность обращений через Raw Sockets будет лимитирована. И это говорят эксперты Гугла? Как это защитит сервер от клиентов, собранных без этого говнокода?
Ответить | Правка | Наверх | Cообщить модератору

	91. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Cred (??), 23-Авг-20, 02:24
	Что значит собранного без этого говнокода? Если клиент собрал "другое" вместо установки из кошерных сорцов или валидного пакета, то чем это отличается от установки (и самописания) вообще любой тулзы умеющией в DDOS и к браузеру не имеющий никого отношения. Более того, если так рассуждать, и допускать такие формулировки, то что мешает давать юзеру "свой хромиум с Херандексом и botnet-client на борту" без всяких там стандартов и рассуждений.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Аноним (119), 23-Авг-20, 11:10
	>>Для предотвращения DDoS-атак интенсивность обращений через Raw Sockets будет лимитирована. > И это говорят эксперты Гугла? Как это защитит сервер от клиентов, собранных без этого говнокода? Действительно, не подумали как-то... Значит придётся закрыть исходники.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

8. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
Сообщение от Урри (?), 22-Авг-20, 12:18
Я и в прошлый раз говорил, и сейчас говорю - вебсокетс кривое поделие студентов двоешников (сами гляньте "стандарт" - офигеете от кривости и убогости) и его давным-давно надо менять и, желательно, на что-то самое простое. Но в прошлый раз победили идиоты под глупым соусом "тогда всех заддосят". Посмотрим кто выиграет в этот раз.
Ответить | Правка | Наверх | Cообщить модератору

	131. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (129), 23-Авг-20, 15:28
	Если и менять, то на что-то ещё более кривое и убогое. Надеюсь, гугл и в этот раз не подведёт.
	Ответить | Правка | Наверх | Cообщить модератору

10. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от Аноним (10), 22-Авг-20, 12:18
То есть простые сокеты не безопасны, давайте добавимв веб сокеты?
Ответить | Правка | Наверх | Cообщить модератору

	84. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+3 +/–
	Сообщение от Аноним (84), 22-Авг-20, 22:35
	Им нужна прибыль, а это новые приложения, а на вашу безопасность они сс...
	Ответить | Правка | Наверх | Cообщить модератору

13. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
Сообщение от Аноним (22), 22-Авг-20, 12:55
В помощь т. майору для деанонимизации пользователей в луковых сетях.
Ответить | Правка | Наверх | Cообщить модератору

15. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
Сообщение от user (??), 22-Авг-20, 13:09
В каких браузерах это можно будет отключить?
Ответить | Правка | Наверх | Cообщить модератору

	77. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (84), 22-Авг-20, 21:46
	пс я из будущего, в тех в которые дабавят это Апи и функцию его отключения
	Ответить | Правка | Наверх | Cообщить модератору

16. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+9 +/–
Сообщение от Аноним (16), 22-Авг-20, 13:17
> Web-разработчики положительно отозвались о новом API и высказали много новых идей об его применении ... (от создания браузерных клиентов для SSH, RDP, IMAP, SMTP, IRC и протоколов вывода на печать до разработки распределённых P2P-систем с DHT (Distributed Hash Table), поддержки IPFS и взаимодействия со специфичными протоколами IoT-устройств). web-разработчики как раковая опухоль - всё хотят поглотить. А браузер так и не могут написать.
Ответить | Правка | Наверх | Cообщить модератору

	92. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Cred (??), 23-Авг-20, 02:30
	Лихо вы веб-разработчиков в разработчиками браузера смешали. Как раз браузер уже давно ок, но ненасытным веб-разработчикам все мало, им и webasm не помешает сделать текстовый сайт где поле ввода текста будет лагать из-за обработки колбэк ада на js повешенного на каждый чих курсора.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
	Сообщение от Lex (??), 23-Авг-20, 07:13
	Производительность вебасма нынче выше только на этапе парсинга...
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (124), 23-Авг-20, 14:23
	Браузер совсем не ок.
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

17. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+9 +/–
Сообщение от Аноним (-), 22-Авг-20, 13:22
Да почему приложения должны быть в браузере? Зачем пихать в него всё? ОС тогда на что?
Ответить | Правка | Наверх | Cообщить модератору

	19. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–4 +/–
	Сообщение от Онаним (?), 22-Авг-20, 13:28
	Потому что удобно, и нет проблем с обновлением пользователей - не надо держать кучу слоёв совместимости с легаси.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+4 +/–
	Сообщение от Аноним (23), 22-Авг-20, 13:47
	Мой провайдер имеет приложение для IPTV и доступа к пиратским фильмам. Так вот это приложение отказывается работать если оно не самой последней версии и сразу же обновляется. Steam вроде так же поступает. А, что мешает Вам?
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Роман (??), 22-Авг-20, 14:14
	Зато приложение не отказывается работать в отличие от этого Стима и приложения провайдера. Кстати, подскажите, что за провайдер такой чудесный?
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (23), 22-Авг-20, 14:18
	> Кстати, подскажите, что за провайдер такой чудесный? Очень мелкий провайдер Омска. Сам удивляюсь как они ещё не спалились со своей фильмотекой.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+10 +/–
	Сообщение от n00by (ok), 22-Авг-20, 14:23
	> Сам удивляюсь как они ещё не спалились со > своей фильмотекой. Очень просто: раньше Вы не хвалились фильмотекой.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (141), 24-Авг-20, 03:53
	>> и нет проблем с обновлением пользователей > обновлением пользователей "А чего с вами знакомиться? Вы каждый год новые."©
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

18. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от Онаним (?), 22-Авг-20, 13:27
Неужели таки можно будет нормальный сип-клиент сделать без угрёбища под названием websockets?
Ответить | Правка | Наверх | Cообщить модератору

	47. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от think (ok), 22-Авг-20, 16:07
	а чем вебсокета не достаточно? такой же raw сокет, только с хендшейком по хттп
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Онаним (?), 22-Авг-20, 19:44
	Тем, что это костыль, поверх которого укладывается SIP. И RTP напрямую не загнать, надо городить очередные извращения. Оно и так поверх NAT едва ходит, а с вёбсокетами это вдвойне приключение.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Аноним (84), 22-Авг-20, 22:06
	Теперь появятся SIP клиенты на Electron и браузерные p2p botnet
	Ответить | Правка | Наверх | Cообщить модератору

24. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+3 +/–
Сообщение от Онаним (?), 22-Авг-20, 13:49
Уроды
Ответить | Правка | Наверх | Cообщить модератору

25. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+2 +/–
Сообщение от Аноним (25), 22-Авг-20, 13:54
Это было реализовано в API флеша ещё 100 лет назад. Некоторые потом даже делали костыли - обменивались через JS с флешкой, которая держала сокет открытым. И стоило убивать флеш, когда огромные портянки скриптов в html-страничках до сих пор не могут его превзойти?
Ответить | Правка | Наверх | Cообщить модератору

	40. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от n80 (?), 22-Авг-20, 15:03
	Стоило ли убивать проприетарную вечно дырявую (потому что такой подход к разработке, а не инструменты плохие) реализацию? Конечно же стоило. А вот на спецификацию API могли бы и посмотреть,  а не городить тотальный NIH. Но, видимо, за такое нынче засудят или хотя бы все нервы вымотают.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Kusb (?), 23-Авг-20, 09:22
	Зато оно производительное, позволяет делать очень красивые/стильные вещи, наверное потому, что наверное более понятно художникам. Имеет средства разработки, даже то, что оно не смешивается так с html это отчасти хорошо, потому что нам же нужна платформа для документов и приложений? Вот пусть документы останутся документами, а приложения - приложениями, просто внутри документа.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Ordu (ok), 22-Авг-20, 16:12
	> стоило убивать флеш Стоило. Мир стал чище без флеша.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	75. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
	Сообщение от Дон Ягон (ok), 22-Авг-20, 20:51
	Только, судя по текущей новости, ненадолго. И, как по мне, лучше уж флэш, чем это. Его хотя бы выпиливать было просто (а на некоторых ОС он был выпилен из коробки и завести его там можно было разве что через приседания с линуксулатором (это не точно, могу врать, ибо сам никогда не заводил там флэш)). А можно ли будет тривиально отключить сие, глобально - это ещё вопрос.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Ordu (ok), 23-Авг-20, 00:13
	> И, как по мне, лучше уж флэш, чем это. Его хотя бы > выпиливать было просто (а на некоторых ОС он был выпилен из > коробки и завести его там можно было разве что через приседания > с линуксулатором (это не точно, могу врать, ибо сам никогда не > заводил там флэш)). А можно ли будет тривиально отключить сие, глобально > - это ещё вопрос. Это сомнительный аргумент. Отключить всё лишнее ты можешь, взяв links. Или не совсем всё, если взять какой-нибудь netsurf. Проблема ведь не в том, что невозможно отключить, проблема в том, что отключать очень не хочется: половина интернета не работает, когда из браузера выкинуто всё. Таким образом, если мы сравниваем флеш с тем, что есть, то мы сравниваем пропиетарь с опенсорцом. Причём пропиетарь от Adobe, который в безопасность не умеет от слова совсем. И не умел никогда. > Только, судя по текущей новости, ненадолго. Мои основные претензии к флешу -- пропиетарность и дырявость, превосходящая не только все разумные границы, но и несколько неразумных тоже. Закрытую пропиетарь я ужасно не люблю, потому что она очень ограничивает в том, что можно с системой делать. Собственно я использую amd'шные видеокарты не потому, что они чем-то лучше, а потому что я когда-то наелся дровами от нвидии: они тогда ставились проще чем атишные, и поэтому я их использовал, но всё равно, как только появилась возможность свалить от них подальше, я свалил. Ну а уж дырявость уровня флеша... У меня флеш никогда не стоял и не работал. Я его даже ни разу не выносил из системы, потому что ни разу не ставил его туда. На мой взгляд такую дырищу ставить добровольно в систему -- это элементарно недопустимо. Пропиетарь ещё можно поставить, если очень хочется, но ставить в систему дыру нельзя никак.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
	Сообщение от Дон Ягон (ok), 23-Авг-20, 03:28
	> Это сомнительный аргумент. Отключить всё лишнее ты можешь, взяв links. Или не совсем всё, если взять какой-нибудь netsurf. Проблема ведь не в том, что невозможно отключить, проблема в том, что отключать очень не хочется: половина интернета не работает, когда из браузера выкинуто всё. Таким образом, если мы сравниваем флеш с тем, что есть, то мы сравниваем пропиетарь с опенсорцом. Причём пропиетарь от Adobe, который в безопасность не умеет от слова совсем. И не умел никогда. Я бы с радостью пользовался чем-то легковесным, типа links, если бы бОльшая часть сайтов там корректно работала бы. Увы, это не так. Без флэша прожить вполне можно было. Не помню, чтобы мне приходилось как-то обламваться из-за того что у меня нет flash и когда я выпилил его себе я был тольо рад. Ну может на паре сайтов не мог видео посмотреть из-за слишком хитрожопого устройства, обычо же тривиально получалось выдрать прямые ссылки на видеофайлы. Ценность флэша сильно преувеличена. > Мои основные претензии к флешу -- пропиетарность и дырявость, превосходящая не только все разумные границы, но и несколько неразумных тоже. Дырявость - прямое следствие того, что он пытается делать в браузере то, что должно делаться в нативных приложениях - это достаточно сложная задача, чтобы сразу сделать всё хорошо, даже если ты талантлив. Ну вот будет у нас теперь опенсорсный, а не проприетарный кусок возможностей флэша, в бразузере абсолютно не нужный. И даже если каким-то чудом получится сделать всё без вопиющих дыр - всё равно, зачем? Зачем это нужно? КМК, потенциал для злонамеренного использования подобных технологий огромный, а польза нулевая. Альтернатива проприетарному флэшу - это отсутствие флэша, а не опенсорсный флэш.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Ordu (ok), 23-Авг-20, 11:08
	>> Это сомнительный аргумент. Отключить всё лишнее ты можешь, взяв links. Или не совсем всё, если взять какой-нибудь netsurf. Проблема ведь не в том, что невозможно отключить, проблема в том, что отключать очень не хочется: половина интернета не работает, когда из браузера выкинуто всё. Таким образом, если мы сравниваем флеш с тем, что есть, то мы сравниваем пропиетарь с опенсорцом. Причём пропиетарь от Adobe, который в безопасность не умеет от слова совсем. И не умел никогда. > Я бы с радостью пользовался чем-то легковесным, типа links, если бы бОльшая > часть сайтов там корректно работала бы. Увы, это не так. > Без флэша прожить вполне можно было. Не помню, чтобы мне приходилось как-то > обламваться из-за того что у меня нет flash и когда я > выпилил его себе я был тольо рад. Ну может на паре > сайтов не мог видео посмотреть из-за слишком хитрожопого устройства, обычо же > тривиально получалось выдрать прямые ссылки на видеофайлы. Ценность флэша сильно преувеличена. Благодаря тому, что html/css и js догоняли флеш, флеш не стал необходимостью. Если бы этого не случилось, сегодня ты бы ставил бы флеш по той же причине, по которой сегодня ты не пользуешься links. >> Мои основные претензии к флешу -- пропиетарность и дырявость, превосходящая не только все разумные границы, но и несколько неразумных тоже. > Дырявость - прямое следствие того, что он пытается делать в браузере то, > что должно делаться в нативных приложениях - это достаточно сложная задача, > чтобы сразу сделать всё хорошо, даже если ты талантлив. Ой ну не надо, а? Там была куча дурацких дыр которые возникали потому, что Adobe было начхать, и потому что Adobe просто не умеет мыслить системно. > Ну вот будет у нас теперь опенсорсный, а не проприетарный кусок возможностей > флэша, в бразузере абсолютно не нужный. И даже если каким-то чудом > получится сделать всё без вопиющих дыр - всё равно, зачем? Зачем > это нужно? КМК, потенциал для злонамеренного использования подобных технологий огромный, > а польза нулевая. Нет, не нулевая. Я могу работать с сайтами-приложениями. Я не спорю с тем, что разработчики сайтов часто путают тёплое с мягким, и из сайтов-документов они делают сайты-приложения, хотя это не нужно совершенно. Но глянь хотя бы на google-docs: что-то подобное на нативных приложениях замутить можно только в наивных фантазиях. В реальности же что бы ты не сделал -- не взлетит. А значит не будет возможности создать документ, доступный всем, кому надо на чтение/редактирование.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (23), 23-Авг-20, 20:27
	>Но глянь хотя бы на google-docs: что-то подобное на нативных >приложениях замутить можно только в наивных фантазиях. Слов цензурных на Вас не хватает. То есть если мы возьмём полноценный html-движок, который не будет тянуть из сети ничего кроме изменений в документе и переписав код так, чтобы использовать нативный API вместо браузерного. То у нас получиться тыква, а не нативный клон google-docs? Разница лишь в том, что любой другой офис нужно установить в систему, gdocs работает в любом браузере. Что позволило ему влезть на рынок офисов во времена, когда Chrome не был браузером по умолчанию.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (137), 23-Авг-20, 21:47
	> Разница лишь в том, что любой другой офис нужно установить в систему, gdocs работает в любом браузере. Что позволило ему влезть на рынок офисов во времена, когда Chrome не был браузером по умолчанию. Совершенно верно. Именно поэтому нативный офис подходит разве что для индивидуальной работы. Совместный доступ к документам будет выполняться через гуглодоки с гуглодиском.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (23), 24-Авг-20, 05:52
	> Совместный доступ к документам будет выполняться через гуглодоки с гуглодиском. Главном MS об этом не говорить. https://support.microsoft.com/ru-ru/office/я│п╬п╡п╪п╣я│я┌п╫п╬п╣-я─п╣п╢п╟п╨я┌п╦я─п╬п╡п╟п╫п╦п╣-п╦-я│п╬п╡п╪п╣я│я┌п╫п╟я▐-я─п╟п╠п╬я┌п╟-п╫п╟п╢-п╢п╬п╨я┐п╪п╣п╫я┌п╟п╪п╦-ee1509b4-1f6e-401e-b04a-782d26f564a4
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (23), 24-Авг-20, 05:54
	Парсер зараза. В общем ms офис тоже так умеет.
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Ordu (ok), 25-Авг-20, 23:57
	> Парсер зараза. В общем ms офис тоже так умеет. Не знаю чего он там так умеет. Ссылка не работает, как ты уже заметил. Но я слышал, что ms пилит онлайн-версию своего офиса -- я что-то не то слышал? Память подводит?
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (23), 26-Авг-20, 03:32
	> ms пилит онлайн-версию своего офиса Ну надо же как то продавать свои облака. Ведь у офиса также проблема, что и у винды. Никто не хочет повторно платить за новые версии. Нынешний офис умеет в совместное редактирование документов лежащих на OneDrive. google: ms office совместное редактирование.
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Д1110ма (?), 25-Авг-20, 22:15
	Можно и не устанавливать. Есть переносимые варианты и достаточно просто запустить экзешник.
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

	193. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Ordu (ok), 25-Авг-20, 23:59
	> Можно и не устанавливать. Есть переносимые варианты и достаточно просто запустить экзешник. Хыхы. Лол. То есть я профессору должен заслать экзешник, чтобы тот его использовал, чтобы почитать мой диплом? Приемлимость ссылки на гуглодоки я могу обговорить, и как подсказывает опыт, это в большинстве случаев прокатывает. И, кстати, мне это гораздо удобнее, чем возиться с несовместимостями между MSO и LO. Но вот экзешник профессору я не рискну отправлять.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Д1110ма (?), 18-Дек-20, 12:16
	>> Можно и не устанавливать. Есть переносимые варианты и достаточно просто запустить экзешник. > Хыхы. Лол. То есть я профессору должен заслать экзешник, чтобы тот его > использовал, чтобы почитать мой диплом? Приемлимость ссылки на гуглодоки я могу > обговорить, и как подсказывает опыт, это в большинстве случаев прокатывает. И, > кстати, мне это гораздо удобнее, чем возиться с несовместимостями между MSO > и LO. Но вот экзешник профессору я не рискну отправлять. Да, но получется что одну монополию (Microsoft) заменяем на дргую (Google с его Хромым), а поскольку web–технологии говно и все web–макаки должны исчезнуть , то нужно выбирать меньшее из зол. Следовательно ты должен использовать Microsoft Word и документы отправлять в его формате.
	Ответить | Правка | Наверх | Cообщить модератору

	210. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Ordu (ok), 21-Дек-20, 01:56
	> Да, но получется что одну монополию (Microsoft) заменяем на дргую (Google с его Хромым) То есть с этой точки зрения без разницы. > а поскольку web–технологии говно и все web–макаки должны исчезнуть , то нужно выбирать меньшее из зол Я не собираюсь выбирать офисный пакет по идеологическим причинам. Если те программисты, которые не веб-маками и пользуются неговнистыми технологиями, не могут выкатить конкурента GoogleDocs, то значит это у них технологии гoвно, а не у веб-макак. > ты должен использовать Microsoft Word и документы отправлять в его формате. Это какой-то стёб такой? Я не очень представляю себе, как запускать Microsoft Word в линуксе, при этом, как я описал выше, он совершенно непригоден для совместной работы над документами. Ты бы ещё сказал, что я должен использовать Midnight Commander -- он тоже непригоден для совместной работы над документами, зато идеологически выдержан.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Дон Ягон (ok), 23-Авг-20, 20:30
	> Благодаря тому, что html/css и js догоняли флеш, флеш не стал необходимостью. Если бы этого не случилось, сегодня ты бы ставил бы флеш по той же причине, по которой сегодня ты не пользуешься links. Он никогда и не был необходимостью. Аналогичные по смыслу вещи можно было делать с помощью java fx или сервелата. Только хоть сколько-то полезных приложений не было ни на одном из фреймворков этих. И если бы не засилие js и всяческих уеб-приложений, я преспокойно бы пользовался links. И, по правде говоря, я и хотел бы, чтобы как-то так и было. > Ой ну не надо, а? Там была куча дурацких дыр которые возникали потому, что Adobe было начхать, и потому что Adobe просто не умеет мыслить системно. Одно другого никак не отменяет. > Нет, не нулевая. Я могу работать с сайтами-приложениями. Я не спорю с тем, что разработчики сайтов часто путают тёплое с мягким, и из сайтов-документов они делают сайты-приложения, хотя это не нужно совершенно. Но глянь хотя бы на google-docs: что-то подобное на нативных приложениях замутить можно только в наивных фантазиях. В реальности же что бы ты не сделал -- не взлетит. А значит не будет возможности создать документ, доступный всем, кому надо на чтение/редактирование. Никогда не пользовался гуглодоками и подобных намерений не имею. Но если ты про совместное редактирование документов (не могу, правда, представить зачем, но не в первый раз уже про это слышу - наверное кому-то нужно), то кмк никаких проблем сделать то же самое нативно нет. Просто никто даже не пытается, ведь наговнякать очередное уеб-приложение куда легче и веселее, да и вообще это мэйнстрим. Да и можно опубликованные документы поисковым ботом проиндексировать, а потом в поисковую выдачу добавить их - разве не "удобно"?) Сплошная безопасность и забота о пользователе!)
	Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

	136. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (137), 23-Авг-20, 21:44
	> никаких проблем сделать то же самое нативно нет Сделать, может, и нет проблем. Но не взлетит. Если онлайн офис не доступен всем, то нафиг он нужен такой хоть кому-нибудь?
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Дон Ягон (ok), 23-Авг-20, 23:56
	Я не знаю, мне точно не нужен. Ни как веб приложение, ни как доп. функция в нативном. Но кмк установить нужное для работы ПО - не такая большая проблема. В утверждении "веб-офис пдходит всем потому что не нужно ничего устанавливать" тоже скрыто лукавство - ресурсов оно жрёт не в пример больше (правда, скорее в сравнении с офисом от ms, по крйней мере, если речь о старых версиях, типа xp-2003, более свежими я не пользовался. lo/oo - адовы тормозные монстры, да) и не работает без сети. Имхо, продукты гугла имеют успех в значительно бОльшей степени из-за агрессивной дистрибуции, чем из-за того, что безальтернативно хороши.
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Ordu (ok), 25-Авг-20, 23:54
	> Но кмк установить нужное для работы ПО - не такая большая проблема. Это проблема. Мне хочется скинуть ссылку человеку, чтобы тот посмотрел и внёс правки, если ему что-то не нравится, но заодно мне надо отправить ему setup.exe? Или ссылку на сайт, где он может скачать этот setup.exe? Да ну нахрен. Если просто ссылкой не удастся, то я лучше отправлю ему docx, потому что уж MSO-то у него установлен, наверное? Ссылкой лучше, потому как не будет плодиться тысяч версий файла, в которых я потом неизбежно запутаюсь, и внесу кучу правок не в ту версию, и потом буду мергать вручную правки оттуда и отсюда. Естественно я что-нибудь пропущу, и потом мне будут выговаривать, что "я же исправлял тебе как надо, почему ты вернул как было?" Бр-р-р... Но лучше так, чем пытаться всем установить какую-то магическую программу. Или если мне нужно по-быстрому организовать распределённый сбор данных -- запилил табличку, написал коммент как данные вносить, открыл доступ по ссылке, разослал ссылку всем кому нужно, и вперёд, понеслась. Потом, при необходимости, можно подправить форматирование, дополнить скриптами, для валидации данных или для форматирования, или для заполнения полей, которые можно посчитать. И всё это _просто_ _будет_ _работать_. И не нужно создавать специальный сайт, не нужно пилить приложение, не нужно устанавливать всем какой-то экзотический софт. Это всё _просто_ _будет_ _работать_. Хочется быстро узнать мнение группы по какому-то вопросу? GoogleForms спешат на помощь! Запилил опросничек, отправил ссылку всем кому надо, каждый в удобное для него время заполнил опросник, и вот у тебя уже как все сырые данные, так и некоторая статистика по ним посчитана уже. Ах, ну да же. Презентации: не нужны флешки, не нужен специальный софт, не нужно даже со своим ноутбуком лезть подключаться к проектору. Достаточно чтобы на том компьютере, к которому проектор подключён, был бы браузер. С девизом "установить нужное для работы ПО - не такая большая проблема" шансов конкурировать с онлайн-офисами будет ровно ноль.
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Дон Ягон (ok), 26-Авг-20, 02:38
	Я офисом не пользуюсь, так что в полной мере не могу оценить боль от проблем с версионированием. Очевидно, что для коллективного редактирования удобнее какая-то клиент-серверная модель. Мне представляется что-то типа svn только для офиса как удачное решение. Т.к. офисная специфика мне малознакома, не знаю, насколько затратно будет сделать такое, есть ли такие решения - тоже не знаю. Но так или иначе, сервер, хранящий историю правок и отдающий её клиентам в виде документов, а не перегруженными злыми js html-страницами не видится мне какой-то космической технологией. "Просто работает" - это примерно единственный плюс веб приложений. Да и то, только если у тебя хромиум, в основном. Нравится - ради бога, я же намереваюсь продолжать считать веб-приложения говном, которым можно пользоваться только от безысходности.
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Ordu (ok), 26-Авг-20, 09:07
	> Но так или иначе, сервер, хранящий историю правок и отдающий её клиентам в виде документов, а не перегруженными злыми js html-страницами не видится мне какой-то космической технологией. Тут потребуется какой-то особый протокол общения клиентского приложения с сервером. И вот мы приходим, что у всех должно стоять одно и то же клиентское приложение. И вот оно уже взлетает со скрипом, потому что оно не будет никому нужно, пока не взлетит, а не взлетит, пока не будет нужно всем. > я же намереваюсь продолжать считать веб-приложения говном, которым можно пользоваться только от безысходности. Моя позиция, между прочим, не противоречит твоей. Нет ничего лучше веб-приложений, для такого рода вещей, но из этого не следует, что веб-приложения идеальны.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Д1110ма (?), 18-Дек-20, 12:09
	>[оверквотинг удален] > ему setup.exe? Или ссылку на сайт, где он может скачать этот > setup.exe? > Да ну нахрен. Если просто ссылкой не удастся, то я лучше отправлю > ему docx, потому что уж MSO-то у него установлен, наверное? Ссылкой > лучше, потому как не будет плодиться тысяч версий файла, в которых > я потом неизбежно запутаюсь, и внесу кучу правок не в ту > версию, и потом буду мергать вручную правки оттуда и отсюда. Естественно > я что-нибудь пропущу, и потом мне будут выговаривать, что "я же > исправлял тебе как надо, почему ты вернул как было?" Бр-р-р... Но > лучше так, чем пытаться всем установить какую-то магическую программу. Всёе так, но посколько все эти гугл доки — ущербное говно, то его не должно существовать и пользоваться им не надо. Ну и вышеописанные проблемы нессколько нивелируются тем что почти у всех Окна и те кто занимается вот такой вот „бумажной“ работой и так уже имеют установленный пакет офисных программ.
	Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

	209. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Ordu (ok), 18-Дек-20, 17:38
	Десктопные офисные пакеты не заменяют онлайн-офиса. Они совершенно не годятся для совместной работы над документом. Чё ты думаешь, когда я таким образом работал с документами, у всех стоял зоопарк ОСей и офисных пакетов и использовали? Не, все сидели в венде, я один такой был в линуксе. Но они использовали google docs, и я с удовольствием присоединился. Google Docs удобнее, чем все эти ваши либры да MSO. Я вообще не представляю как можно совместно работать над документом в MSO. То есть даже если googledocs хуже по всем остальным параметрам, всё равно он будет удобнее.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Д1110ма (?), 25-Авг-20, 22:18
	>Но глянь хотя бы на google-docs: что-то подобное на нативных приложениях замутить можно только в наивных фантазиях. Бред, бред, бред.
	Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

	190. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Ordu (ok), 25-Авг-20, 23:07
	>>Но глянь хотя бы на google-docs: что-то подобное на нативных приложениях замутить можно только в наивных фантазиях. > Бред, бред, бред. Попробуй. Если не веришь попробуй. Седым стариком, так и не достигнув успеха, ты поймёшь о чём я говорю. На ошибках учатся, пойди и соверши эту ошибку, или так и останься дураком.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Cred (??), 23-Авг-20, 02:34
	Сравнил проприетарный плагин с открытым стандартом.
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	98. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
	Сообщение от Дон Ягон (ok), 23-Авг-20, 03:30
	> Сравнил проприетарный плагин с открытым стандартом. Пока его использование не обязательно - пускай хоть и проприетарный. Мне безразлична лицензия ПО, которое я не намерен использовать в любом случае.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+2 +/–
	Сообщение от гугль (?), 22-Авг-20, 17:07
	конечно стоило - там были просто бесполезные (нам) дыры, которые к тому же легко было выключить вместе с флэшом. А теперь это технологические отверстия, которые вы заткнуть не можете, потому что это же браузер, и их тут - мильен. А кому они могут оказаться в будущем полезны - мы вполне можем определиться в процессе.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

26. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от Аноним (26), 22-Авг-20, 13:56
>неприятие производителями других браузеров, что может привести к проблемам с совместимостью. >WebKit разве вебкит не гугл разрабатывает?
Ответить | Правка | Наверх | Cообщить модератору

	53. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (53), 22-Авг-20, 16:39
	Нет. Гугл - блинк, яблоко - вебкит
	Ответить | Правка | Наверх | Cообщить модератору

27. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от fdght (?), 22-Авг-20, 14:13
>Для предотвращения DDoS-атак интенсивность обращений через Raw Sockets будет лимитирована, а отправка запросов возможно только после взаимодействия пользователя со страницей. UDP-пакеты, полученные с хостов, не одобренных пользователем, будут игнорироваться и не доходить до web-приложения. Кем игноироваться? Системой, а это нагрузка. Так что, это теперь лишь вопрос силы DDoS-атаки.
Ответить | Правка | Наверх | Cообщить модератору

	54. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (54), 22-Авг-20, 16:39
	Очевидно что хромой реализацией этого API и будет.
	Ответить | Правка | Наверх | Cообщить модератору

29. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от Ingener (??), 22-Авг-20, 14:14
Ну и хорошо. А я пользуюсь Мозиллой. Мне нравится. Уже лет десять. Все устраивает. Все (или почти все) стандарты поддерживает. Только новенькие фишки отстают. Да и шут с ними. Хромом пользоваться не буду.
Ответить | Правка | Наверх | Cообщить модератору

	32. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
	Сообщение от microsoft (?), 22-Авг-20, 14:30
	Мы не спрашиваем, мы заставляем
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от гугль (?), 22-Авг-20, 17:08
	А вы тут причем? Я вас уже давно тоже не спрашиваю. Вы можете заставить только выбрать цвет шкурки к нашему браузеру.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Аноним (127), 23-Авг-20, 15:00
	У Мозиллы: 1. Беда с руководством. 2. Маленькая аудитория по сравнению с хромом. Так что рано или поздно *все* стандарты гугла, даже самые отбитые, переползут в огнелис. Просто потому, что альтернатива - потерять аудиторию и сдохнуть.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

33. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
Сообщение от Аноним (33), 22-Авг-20, 14:33
какая красота...
Ответить | Правка | Наверх | Cообщить модератору

34. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+4 +/–
Сообщение от Ананоним (?), 22-Авг-20, 14:34
Кто то там обеспечивал безопасность операционной системы? Теперь забудьте про неё! Запустишь браузер и откроешь сайтик, и хана!
Ответить | Правка | Наверх | Cообщить модератору

	59. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Microsoft (?), 22-Авг-20, 17:10
	это только в операционных системах, где нет нормального файрволла для приложений, а есть только бестолковые пакетные фильтры, еще и абсолютно неуправляемые нормальным пользователем. В НАШИХ - вы можете заблокировать проклятому гуглю все порты, кроме 443. Не то чтобы панацея, но от многих проблем, действительно, поможет.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Ананоним (?), 22-Авг-20, 18:03
	Ваши сами вам отправят всё что вам интересно.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
	Сообщение от Microsoft (?), 22-Авг-20, 18:55
	Жизнь хомячков нам совершенно неинтересна.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Ананоним (?), 22-Авг-20, 23:55
	Расказывайте эти сказки бабушкам.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–2 +/–
	Сообщение от Аноним (84), 22-Авг-20, 22:23
	плюсик
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	151. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (151), 24-Авг-20, 13:43
	Ага, в ваших операциооных системах файервол абсолютно управляемый. Наставил галочек, а там хз что он делает, где он там это в недрах реестра сохранил. Не посмотреть правлила, не проверить.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	94. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
	Сообщение от Cred (??), 23-Авг-20, 02:37
	Пользуй snap в нем приложение не имеет прямой доступ к ресурсам ОСь, и можно рулить connections plugs давая или запрещая что либо.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

35. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+2 +/–
Сообщение от Ананоним (?), 22-Авг-20, 14:41
Ну а чо, скоро JS скрипты напрямую окна на XServer-e рисовать будут.
Ответить | Правка | Наверх | Cообщить модератору

	38. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Annoynymous (ok), 22-Авг-20, 14:54
	И можно будет запускать браузер в браузере.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Андрей (??), 22-Авг-20, 15:21
	systemd интегрируют в Chromium и ядро будет сразу грузить браузер. В нём уже давно запускается Qemu. Только через него можно будет пользоваться старым добрым десктопным окружением.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–2 +/–
	Сообщение от Cred (??), 23-Авг-20, 02:38
	ChromeOS - с разморозкой!
	Ответить | Правка | Наверх | Cообщить модератору

37. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+14 +/–
Сообщение от Annoynymous (ok), 22-Авг-20, 14:53
> Пользователь должен будет явно подтверждать первую попытку соединения для нового хоста. Заходишь на сайт: «Разрешите сайту присылать уведомления» «Разрешите сайту узнать ваше местоположение» «Мы используем Cookie» «Вы используете блокировщик рекламы» «Подпишитесь на нашу рассылку» «Разрешите сайту доступ к микрофону» «Разрешите сайту доступ к вебкамере» «Разрешите сайту доступ к сетевым соединениям» «Остались вопросы? Оставьте свой номер телефона и мы перезвоним через 20 секунд!» … PROFIT, ой, то есть контент.
Ответить | Правка | Наверх | Cообщить модератору

	43. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+4 +/–
	Сообщение от Аноним (43), 22-Авг-20, 15:13
	> «Остались вопросы? Оставьте свой номер телефона и мы перезвоним через 20 секунд!» Ну ктож так делает? Так только неудачники делают. Надо так «Введите ваш номер телефона (и подтвердите серез СМС) на случай, если у вас возникнут вопросы. Мы честное слово никому его не скажем.(*)» И пока не введут и не подтвердят к контенту не пускать. А то что им за дарма н котиков смотреть чтоли?
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от магазин перекресток (?), 22-Авг-20, 17:13
	вот дятлы! Что, вот так, каждый может ввести номер телефона и не поделиться? УЧИТЕСЬ, сынки, как на самом деле надо: прежде, чем выслать вам sms, угадайте-как на всякий случай все светофоры. И, пожалуй, велосипеды. И гидранты. Ок...не, не ок - вот еще автобусы! Ну вот, теперь гугль точно знает кто вы, можете прочитать свою sms. P.S. да, мы всего лишь дрянной магазин тухлятины с хреново работающей доставкой. Никуда вы от нас не денетесь. P.P.S. нет, ну разумеется вы могли и не обучать гуглосеть пол-часа. Достаточно было просто не выходить из акаунта.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Kusb (?), 23-Авг-20, 09:49
	Вы используете устаревшую прошивку BIOS с которой наш сайт может работать неправильно. Разрешить сайту загрузить и установить прошивку? Разрешить сайту доступ к GDI? Неизвестная версия winapi, сайт может работать неправильно. Этот сайт хочет установить программу libressl-tools-pokemon-dev, разрешить? Этот сайт пытается напрямую управлять устройствами компьютера, такими как видеокарта, wifi и иные устройства. Это может быть потенциально опасно, нажмите "разрешить", только если вы действительно доверяете ресурсу. Разрешить выполнение кода в контексте ядра? Этот сайт использует собственный web движок (что это такое) (больше не показывать). Разрешить сайту доступ к нейрошунту? Потенциально это может позволит узнать ваши мысли и ассоциации.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	126. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Ананоним (?), 23-Авг-20, 14:50
	Разрешите установидь видеонаблюдение в вашей спальне, ванной, туалете и трусах? Мы собираем статистику размножения и возбеждения. Данный будут использоваться полностью анонимно, честно-честно! Зубы даём!
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от user (??), 22-Авг-20, 16:40
	Быстрое опознавание говносайтов - это хорошо. Предпочитаю paywall.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	61. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
	Сообщение от магазин перекресток (?), 22-Авг-20, 17:14
	> Быстрое опознавание говносайтов - это хорошо. А мы и не прячемся. Что, жрать сегодня не будешь по этому поводу? P.S. учти, у озона еще хуже сайт
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+2 +/–
	Сообщение от Онаним (?), 22-Авг-20, 19:45
	- «Вы используете блокировщик рекламы» На этом месте лично моё общение с сайтом заканчивается.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	122. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Gefest (?), 23-Авг-20, 14:03
	Так это ... Надо  дополнение сделать: ну чтобы оно между пользователями обменивалось списками таких сайтов и устраивало им DDOS. затем продавать абонемент на невключение в списки...
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

39. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
Сообщение от Француз (?), 22-Авг-20, 14:57
Таким образом скоро все новые ОС будут работать через вэб-броузер. И даже ядро ОС будет вэб-приложением, а броузерный движок будут встраивать прямо в процессор.
Ответить | Правка | Наверх | Cообщить модератору

	41. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Ананоним (?), 22-Авг-20, 15:10
	На этом не остановятся. Найдуться абстракционисты следующих уровней. Это когда ядро ОС запускать будут в браузере, который работает на ядре ОС в браузере... Ну вы понели.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Ананоним (?), 22-Авг-20, 15:11
	Вот к чему приводит отрыв от BIOS.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Lex (??), 23-Авг-20, 07:46
	А возможно - просто выпустят новую архитектуру процов, у которых JS будет нативным.. и тогда заживём
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	115. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Kusb (?), 23-Авг-20, 10:26
	Как-то так?: Js будет нативным, html будет командами графического терминала, то есть языком для общения с аппаратурой, много аппаратных ускорителей/asic для всего в вебе, включая CSS и DOM. Web asm будет компилироваться в понятный процессору вид, Js. Http станет уровнем сети osi, маршрутизаторы будут работать на уровне http. Все соединения будут через http. Html тоже станет уровнем osi, но я не пытаюсь особенно объяснить каким образом язык разметки может оказаться в таком качестве. Потому что сам не слишком понимаю. Придётся принять это. Самой популярной ОС будет электрон. Устройства будут иметь url, драйвера будут общаться с ними довольно часто тоже по http. Адресация глобальная, при ошибке возможно обращение к устройству другого компьютера, но грань между pci/usb и сетью почти сотрется. Впрочем обычно умные устройства такие как жесткий диск будут иметь свой веб-сервер. Диски будут выбирать в том числе по файловому менеджеру который крутится на нем м доступен по веб. Обычно для доступа к файлам будет использоваться именно он. Компьютер будут называть браузером. Visul studio code будет самым популярным языком программирования.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Lex (??), 24-Авг-20, 10:38
	> Как-то так?: Js будет нативным, html будет командами графического терминала, то есть > языком для общения с аппаратурой, много аппаратных ускорителей/asic для всего в > вебе, включая CSS и DOM. Web asm будет компилироваться в понятный > процессору вид, Js. На самом деле, было бы интересно на подобное глянуть.. На процы, где "нативными" инструкциями являются, даже не JS, поскольку не очень универсально, а LLVM-байткод. На процы, где дурацкий стек растет не вверх и запросто достигает "потолка", а является по сути бездонным.. А то, у многих уже мозги костенеть начали и некоторые всерьез считают, что все это - нормально и вообще, чуть ли не единственно-правильный вариант. п.с: разве JIT и его подобия по сути своей не примерно так и работает - "на лету" преобразует инструкции одной архитектуры( для которой может и не быть реального воплощения проца "в железе", а может и быть ) в другую ? Притом, неважно, команды какой "архитектуры" у него на входе - JS / ARM( привет, x86, на которых иногда подобные проги требуется погонять ) / x86( привет, Эльбрус ) / итд - это вопрос лишь первичной обработки, по итогу которой алгоритмы "пережевываются" в нечто абстрактное и на выходе получается коши под иную архитектуру, т.е большой вычислительный ресурс тратится именно на преобразование. Или к разговору о том, насколько быстро и эффективно в плане потребления ресурсов будет работать приложение под x86 при его запуске с бубнами( QEMU ) на ARMовом железе и наоборот, т.е запущенное на "чужой" архитектуре с подобиями эмуляции родной или преобразования к "чужой" на лету.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (172), 25-Авг-20, 16:40
	Здравствуйте, меня зовут NetBSD, и у меня есть такое ядро.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	89. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от xm (ok), 23-Авг-20, 00:16
	Совершенно верно. Процесс идёт уже не первый год.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	161. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (159), 24-Авг-20, 19:44
	Заметь причем вытеснили всех игроков с мировой арены и сделал использование их языков и API катастрофический не выгодным. Зачем делать приложения на C#, Swift, C++ (Qt/GTK), когда можно взять наговнокодить HTML+JS+CSS на каком-то фреймворке и упаковать в Electorn. К сожалению, эти парни из Microaoft / Apple / FSF они сами подписали себе смертный приговор и не знаю уже поняли это или нет, но с каждым днем все меньше декстоп приложений.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (162), 24-Авг-20, 20:59
	Прямо таки сами? Или может быть кто то подталкивает? Гугель например.
	Ответить | Правка | Наверх | Cообщить модератору

48. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от Аноним (48), 22-Авг-20, 16:10
Отличная идея для клиентских сред. Использование WebSockets Proxy для доступа к  VNC создает задержки, избыточную сложность и уменьшает надежность. Однако пугает умение хрома делать скриншоты. Нужна облегченная версия хрома без избыточного функционала и с меньшими аппетитами. Для работы с публичными временными виртуальными машинами самое оно.
Ответить | Правка | Наверх | Cообщить модератору

	52. Скрыто модератором	+4 +/–
	Сообщение от ананасус (?), 22-Авг-20, 16:27
	>Использование WebSockets Proxy для доступа к  VNC создает задержки, избыточную сложность и уменьшает надежность. Использование веб-макак вместо программистов создаёт задержки, избыточную сложность и уменьшает надёжность.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
	Сообщение от Дон Ягон (ok), 23-Авг-20, 02:24
	> Однако пугает умение хрома делать скриншоты. Если опасения связаны с тем, что он заскриншотит что-то приватное вне хрома, то можно попробовать воспользоваться untrusted cookies (подробности гуглить по "X11 Security extension" и в man xauth). Авторизованный таким образом клиент не будет иметь возможность сделать снимок экрана. Правда, аппаратное ускореение, например, тоже не будет работать.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

56. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+2 +/–
Сообщение от Аноним (56), 22-Авг-20, 16:51
Остановитесь!
Ответить | Правка | Наверх | Cообщить модератору

62. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от Аноним (62), 22-Авг-20, 17:47
П№сы конченные. То есть со временем обеспечить безопасность какой-нибудь сеточки на много пользователей будет просто нереально. Только открыть всем доступ по всем портам-протоколам. А что они остановились только на этом. Пусть ещё сделают проверку на нат. И если по пути есть нат - отказываться работать. Мало ли что на тех железках плохие дяденьки навертят.
Ответить | Правка | Наверх | Cообщить модератору

63. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от Аноним (63), 22-Авг-20, 17:49
>создания браузерных клиентов для SSH, RDP, IMAP, SMTP, IRC так это всё уже давно существует
Ответить | Правка | Наверх | Cообщить модератору

	64. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (64), 22-Авг-20, 18:03
	Через браузерное расширение и NaCl? Или с использованием чего-то там, дополнительно установленного на сервере?
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Аноним84701 (ok), 22-Авг-20, 23:47
	>>создания браузерных клиентов для SSH, RDP, IMAP, SMTP, IRC > так это всё уже давно существует В давно существующем есть целых два фатальных недостатка: 1. NIH 2. Результирует из первого -- данные проходят совершенно мимо единственно-верного браузера (сотни миллионов в разработку и вытеснение всех конкурентов из Inter^W GoogleNet вкладывались сугубо из альтруистических побуждений!) и не могут анализироваться э-э-э ... полностью анонимно исключительно, сугубо, единственно в целях безопасности! Непорядок! Безопасность п̴р̴и̴б̴ы̴л̴е̴й̴ ̴а̴к̴ц̴и̴о̴н̴е̴р̴о̴в̴ ̴ пользователей под угрозой!
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

68. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от Аноним (68), 22-Авг-20, 18:40
Наконец то можно будет напрямую общаться с базой данных, без прослоек в виде бека
Ответить | Правка | Наверх | Cообщить модератору

	117. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Kusb (?), 23-Авг-20, 10:38
	> Наконец то можно будет напрямую общаться с базой данных, без прослоек в > виде бека Обращаемся к базе и на клиенте все рисуем. Http не нужен. Только фронтенд. Только база.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (144), 24-Авг-20, 07:19
	Я таким макаром делал интересные юзерскрипты. Но возни многовато, да и в паблик не выложишь. А зачем там напрямую?
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

71. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
Сообщение от Аноним (53), 22-Авг-20, 19:05
Что может не только клиента но ещё давайте серверную часть что б можно было ещё и на портах слушать.
Ответить | Правка | Наверх | Cообщить модератору

81. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
Сообщение от Аноним (84), 22-Авг-20, 22:11
Отличный botnet получится
Ответить | Правка | Наверх | Cообщить модератору

96. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от Аноним (96), 23-Авг-20, 03:04
Может хватит из браузера делать ось?
Ответить | Правка | Наверх | Cообщить модератору

	100. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+2 +/–
	Сообщение от Аноним (-), 23-Авг-20, 06:32
	Emacs с тобой несогласен.
	Ответить | Правка | Наверх | Cообщить модератору

101. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от Аноним (101), 23-Авг-20, 06:38
Почему то просьба витает в мыслях всем кто ро против этого, а напомню недавние обстоятельства Линукс уже крутил 4K и 8K с видео в 128 256 цветов в то время как винда пришла к этому года через три. Вы хотите скатить весь прогресс к видео 360 15 фпс и бегать потом по форумам со своим ря смотрите моя протоплазма жрет всего 300 мб потому что ей теперь не нужны все это качество и быстрота кодирования.
Ответить | Правка | Наверх | Cообщить модератору

105. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
Сообщение от Аноним (105), 23-Авг-20, 06:51
Нехило они таким образом функционал своего ChromeOS хотят повысить
Ответить | Правка | Наверх | Cообщить модератору

110. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
Сообщение от Kusb (?), 23-Авг-20, 09:13
Мне эта идея кажется очень странной. И сейчас пишу, это может быть даже дырой в безопасности. Даже если будет всплывающая штука "этот сайт хочет в Интернет, разрешить?" Зато можно дичайшие веб-приложения  делать, наверное. P2P прикручивать. Email, torrent, вообще многое, и с webasm.
Ответить | Правка | Наверх | Cообщить модератору

	114. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (114), 23-Авг-20, 09:53
	Можно будет эксплоиты для локальной сети тестировать на подопытных не выходя из браузера.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Kusb (?), 23-Авг-20, 10:28
	> Можно будет эксплоиты для локальной сети тестировать на подопытных не выходя из > браузера. Локальная сеть? Ха! Теперь глобальная!
	Ответить | Правка | Наверх | Cообщить модератору

121. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
Сообщение от Аноним (121), 23-Авг-20, 13:33
Эта новость разжигает гнев, возбуждает ненависть и вражду.
Ответить | Правка | Наверх | Cообщить модератору

	128. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (127), 23-Авг-20, 15:03
	Вэлкам то XXI век. Тут везде так.
	Ответить | Правка | Наверх | Cообщить модератору

132. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от Google (?), 23-Авг-20, 15:56
> но участники рабочей группы не достигли консенсуса и разработка данного API была остановлена Нас это не волнует. Нет в стандарте? Всё равно приступаем к реализации, всем остальным ничего не останется, как последовать за нашей _эталонной реализацией_ и согласиться с нами. Viva monopoly!
Ответить | Правка | Наверх | Cообщить модератору

133. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
Сообщение от Аноним (133), 23-Авг-20, 18:28
В Китае WeChat обогнал веб по числу пользователей, а по пользовательским поисковым вопросам раз в 10-20. http://amp.gs/wU9m Не пора ли этот "гугловеб" послать куда подальше? Зачем он нужен такой?
Ответить | Правка | Наверх | Cообщить модератору

138. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от BrainFucker (ok), 23-Авг-20, 22:47
> API Raw Sockets будет допускать сетевые обращения только инициированные с согласия пользователя и ограниченные списком разрешённых пользователем хостов. Пользователь должен будет явно подтверждать первую попытку соединения для нового хоста. Вот такой из коробки должна быть операционная система.
Ответить | Правка | Наверх | Cообщить модератору

	150. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (150), 24-Авг-20, 13:36
	Если б не было бы дыр На вендах и вёдрах, Никогда б не знали мы Этих дней весёлых.
	Ответить | Правка | Наверх | Cообщить модератору

146. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от аноним12345 (?), 24-Авг-20, 09:03
Еще один зонд
Ответить | Правка | Наверх | Cообщить модератору

153. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	–1 +/–
Сообщение от user90 (?), 24-Авг-20, 15:12
Вот так вот обезьянки и наживете себе еще одну проблемку, гг. Гугл конечно единственный адекватный (-полу) поисковик, но и только. А у вас ведроид.. полный зашквар.
Ответить | Правка | Наверх | Cообщить модератору

	157. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от Аноним (144), 24-Авг-20, 17:38
	О чём ты? Самый бесполезный и никчёмный продукт гугла это поисковик. Уже 10+ лет вся выдача забита проплаченными ссылками, первые 3-5 страниц не содержат ничего релевантного (даже на конкретный запрос, другие поисковики почему-то справляются), а цензура давно перешла все границы. Переводчик ещё ничего, тем более что бесплатно, но остальное никуда не годится.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от Michael Shigorin (ok), 24-Авг-20, 17:44
	Так переводчик ещё дообучают, поди.
	Ответить | Правка | Наверх | Cообщить модератору

164. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от Аноним (164), 24-Авг-20, 21:02
Правильно, нужно больше костылей, больше граблей и тупых технологий. А то как-то мало шлака в браузере. Ни пользовался, не пользуюсь и не собираюсь.
Ответить | Правка | Наверх | Cообщить модератору

166. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от rvs2016 (ok), 25-Авг-20, 16:03
> Начальная реализация не предусматривает > создания слушающих сокетов Тю. Вообще бесполезная система. Исходящие-то соединения я и через Ajax наваяю. Входящие нужны! > но в будущем не исключается предоставление > вызовов для приёма входящих соединений > с localhost или списка известных хостов Известных - кому?! Гуглу?
Ответить | Правка | Наверх | Cообщить модератору

	173. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от n80 (?), 25-Авг-20, 16:41
	> Тю. Вообще бесполезная система. Исходящие-то соединения я и через Ajax наваяю. Под Ajax подразумевается XHR? Ну наваяй через него банальный чат реального времени без долбёжки сервера постоянным опросом, посмотрим (без костылей типа BOSH). Или, скажем, ещё веселее, звонки в духе урезанного SIP. Не то это, совершенно не то. Впрочем, то что происходит с внедрением всё новых и новых API в браузеры — тоже жесть, конечно. > Входящие нужны! Зачем? Закладываться на наличие у пользователя белого IP (ещё и не порезанного межсетевым экраном провайдера или работодателя) — уже давно безумие.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от kkostintimur (ok), 25-Авг-20, 16:52
	>> Тю. Вообще бесполезная система. Исходящие-то соединения я и через Ajax наваяю. > Под Ajax подразумевается XHR? Ну наваяй через него банальный чат реального времени > без долбёжки сервера постоянным опросом, посмотрим (без костылей типа BOSH). Или, > скажем, ещё веселее, звонки в духе урезанного SIP. > Не то это, совершенно не то. Впрочем, то что происходит с внедрением > всё новых и новых API в браузеры — тоже жесть, конечно. >> Входящие нужны! > Зачем? Закладываться на наличие у пользователя белого IP (ещё и не порезанного > межсетевым экраном провайдера или работодателя) — уже давно безумие. тут столько агрессии...ужасно
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от n80 (?), 25-Авг-20, 17:03
	> тут столько агрессии...ужасно Эм, вообще-то её тут примерно ноль. Эмоции вообще не очень-то сочетаются с техническими обсуждениями. Замечания, критика (почти конструктивная) — да, присутствуют, но как тут можно увидеть агрессию — затрудняюсь представить.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от rvs2016 (ok), 25-Авг-20, 17:05
	>> Тю. Вообще бесполезная система. Исходящие-то соединения я и через Ajax наваяю. > Под Ajax подразумевается XHR? Ну наваяй через него банальный чат реального времени > без долбёжки сервера постоянным опросом Долбёжка постоянным опросом - это, конечно, нехорошо. Но я в браузере запускаю: let eventSource = new EventSource("урл_к_моему_cgi_скрипту"); и после этого браузер держит с моим cgi-скриптом постоянный канал связи и даже переустанавливает его сам, если канал разрывался. А серверный cgi-скрипт каждые N секунд шлёт в этот канал данные: Вот пример, в котором серверный cgi-скрипт ежесекундно секунд шлёт в браузер номер пакета и его время, а через 5 пакетов завершает свою работу, закрывая тем самым канал: Серверный Perl: foreach my $num (1..5) {   my $t = time();   print "data: num = $num, t = $t<BR>\n";   sleep 1; }; print "data: <HR>\n\n"; Браузерный JavaScript: let eventSource = new EventSource("урл_к_моему_cgi_скрипту"); eventSource.onmessage = function(event) {   console.log(event.data);   if (а не закрыть ли нам канал?) {      // а закрыть!      eventSource.close()   } else {      // а не надо! :-)      // NOOP   } } Браузер-то потом автоматически переоткрывает этот канал повторным запросом к cgi-скрипту, если в браузерном JavaScript не остановить автоматической восстановление канала, когда он уже не нужен: Это простейший пример - отправка в браузер пакета ежесекундно. А можно ж не ежескундно, а по другим условиям - например, когда пакет сформировался - хоть через час, хоть через сутки, хоть через месяц, год, век. >> Входящие нужны! > Зачем? Закладываться на наличие у пользователя белого IP (ещё и не порезанного > межсетевым экраном провайдера или работодателя) — уже давно безумие. Вот зачем: Мне нужно отправить юзеру пакет. Обычно это в браузерах 30 лет делают так: Браузер шлёт пакет на сервер, а получатель пакета в другом браузере получает этот пакет с сервера. Но сервер же может отвалиться. Может отвалиться даже кластер серверов. И когда не останется ни одного доступного сервера-посредника, тогда надо иметь возможность отправить пакет из браузера в браузер напрямую без посредников в виде веб-серверов. А если такая возможность будет, то веб-серверы для межбраузерного обмена информацией будут и не нужны (кроме начальных этапов типа построения в браузерах таблиц/списков других браузеров, готовых участвовать в межбраузерном обмене пакетами).
	Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

	179. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от n80 (?), 25-Авг-20, 18:05
	> А серверный cgi-скрипт каждые N секунд шлёт в этот канал данные А теперь представим, что клиентов подключено хотя бы 1000. Решение хорошо знакомое, классическое, даже рабочее, но по многим причинам дикое. А ещё EventSource — довольно бестолковая штука, ИМХО: в дикой природе я его не встречал и сам так нигде и не применил (хотя и были порывы). С одной стороны, требует довольно нового браузера (к счастью, теперь-то IE уже закапывают официально, но сколько лет к этому шли), с другой — всё равно мало что даёт (одно направление, прибитый гвоздями формат сообщений и т.д.). Так что если важны клиенты, используют long polling с GET/POST-запросами, а если можно надеяться на свежий браузер у клиента, давно есть WebSocket'ы, в которых возможностей куда больше при той же нагрузке на сервер и клиент. Только не надо рассказывать про то что это плохо совместимо со столь родными CGI-скриптами, с которыми прожил много лет и не поднимается рука выкинуть, это несерьёзно. Затраченные в прошлом ресурсы не должны быть определяющим аргументом в пользу оставлять/не оставлять. Да, себя иногда тоже на подобном ловлю, но стараюсь пресекать. > Мне нужно отправить юзеру пакет. > Обычно это в браузерах 30 лет делают так: Браузерам в современном понимании «немножко» меньше 30 лет, на минуточку. Не могу не позанудствовать в данном вопросе, пардон. > Браузер шлёт пакет на сервер, а получатель пакета в другом браузере получает этот пакет с сервера. Эту задачу WebSocket прекрасно решает. В смысле, уже лет пять (если не восемь, а до этого аналогичное делалось на Flash и тому подобных отвратительных, но работающих технологиях), как для решения такой задачи браузер не шлёт пакет на сервер. Устанавливает соединение один раз при заходе на сайт и дальше через него может получать пакеты от сервера в любой момент (пока соединение не отвалится или сервер, но это уж с каждым может случиться). > И когда не останется ни одного доступного сервера-посредника, тогда надо иметь возможность отправить пакет из браузера в браузер напрямую без посредников в виде веб-серверов. А если такая возможность будет, то веб-серверы для межбраузерного обмена информацией Так ведь такая возможность давно есть. Локальные браузер-совместимые peer-to-peer программы (типа IPFS или Mastodon) уже давно существуют, в сами браузеры WebRTC тоже завезли уже довольно давно. Т.е. разные возможности есть, организовать транспорт — не проблема. Проблемы возникают куда более интересные, особенно с активным содержимым (скриптами и тому подобным), ну и банально с тем что контент нужно где-то хранить, а его очень много.
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от rvs2016 (ok), 25-Авг-20, 19:42
	> А теперь представим, что клиентов подключено хотя бы 1000. > Решение хорошо знакомое, классическое, даже рабочее, > но по многим причинам дикое. Согласен. Для большей нагрузки решения нужны более элегантные, чем простой, топорный EventSource. > браузер у клиента, давно есть WebSocket'ы, > в которых возможностей куда больше > при той же нагрузке на сервер и клиент. Вебсокеты - технология какая-то странная с привязкой к http, если даже не вообще к https вроде - точнее не помню: успел не применить их у себя нигде, а теперь благодаря сабжу их время/эпоха подходит к концу. А если мне надо отправить запрос на 110-й порт моего_почтового_сервера? Или на любой другой порт, если меня на другом конце ждёт моя программа-сервер, работающая хоть по телнету и обрабатывающая мои команды на моём спец-языке? Ну это я всё клоню к тому, что нужна просто простая штука для просто подключений на указанный хост по указанному порту без всяких странных наворотов. Ну типа как просто берёшь, например, tcpcat и "горя не знаешь": pkg info tcpcat ... Description    : From the tcpcat README: Tcpcat is a simple program that is like `cat' but it works over TCP streams to allow you to cat from one host to another. The host common way to use this program whould be something like this: on host a: $ tcpcat -l 93255 | gzip -dc | tar xvf - on host b: $ tcpcat -h hosta:93255  file.tar.gz Another good use for this program is debugging network stuff. When debugging a newtork client or server you can pipe the output of tcpcat to a hex dump (I recomend xxd which comes with vim). Also it can act as a crude telnet server when invoded with --listen, --input, and --output, this mode is quite useful for network program debugging as well. > Браузерам в современном понимании «немножко» меньше 30 лет, > на минуточку. Не могу не позанудствовать в данном вопросе, пардон. Конечно-конечно! 30 - это сильно приблизительно! С небольшой погрешностью лет в 7. :-) (для браузеров в современном понимании, когда во 2-й половине 90-х уже пошли Нетскейпы после Мозаик да Арахн :-) ) > Так ведь такая возможность давно есть. > Локальные браузер-совместимые peer-to-peer программы Тут "прикол" в том, что требуется работа с пользователями, которые даже слова "браузер" не знают (хотя пользуются им), а не только слова типа "Локальные браузер-совместимые peer-to-peer программы". :-) Слушаешь, бывает, юзера по телефону. Он говорит - запускаю Интернет! И думаешь - какой ещё интернет он там запускает, если у него сеть давно настроена? Переподключается что ли к провайдеру? Оказывается, что интернетом юзер называет браузер. Поэтому требуется такие задачки решать в среде, в которой люди, уж извините, ни бум-бум в том, что такое компьютер и программы, которые им нынче теперь называют: "устройство" вместо "компьютер", "приложения" вместо "программы". И так далее. > в сами браузеры WebRTC тоже завезли уже довольно давно Попытался я, было, в своё время возрадоваться появлению WebRTC. Но какой-то он мутный. Это не простые прямые соединения, а через кучу каких-то странных предварительных настроек. Этот WebRTC со своей не простой системой установки связи между браузерами напоминает мне старую историю из тех же 90-х, когда программисты ("до изобретения Delphi") для создания окна в Windows читали страниц пять толстой книги по программированию в ней. :-) Вот так и WebRTC. Хочу открыть исходящее соединение по адресу хост:порт. Ну сделайте простую функцию с этой парой аргументов (хост, порт) ну и возможно с назначением callback и т.п., если что, да и всё. Так нет же. Там нужны ещё сервера сигнальные и TURN. И объясняют всю эту сложность в WebRTC - необходимостью гарантированного пробивания NAT. А если мне не надо пробивать NAT и оба браузера находятся в одной локальной сети, даже не подключенной к интернету? Браузеру_А надо подключиться к браузеру_Б на порт_Б: взять бы просто да подключиться, если я точно знаю (а это я программно решу сам), что браузер_Б уже слушает порт_Б. Так нет же - иди бери бубен, и танцуй с ним вокруг сигнальных и TURN-серверов. :-)
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от n80 (?), 25-Авг-20, 20:59
	>> А теперь представим, что клиентов подключено хотя бы 1000. >> Решение хорошо знакомое, классическое, даже рабочее, но по многим причинам дикое. > Согласен. Для большей нагрузки решения нужны более элегантные, чем простой, топорный EventSource. Гм, аргумент с нагрузкой относился к CGI, а не к EventSource (который сам по себе имеет весьма малые накладные расходы). Мне это показалось очевидным, ну да ладно. > Вебсокеты - технология какая-то странная с привязкой к http, если даже не вообще к https вроде - точнее не помню: успел не применить их у себя нигде Да, с привязкой к HTTP(S) (HTTP поверх SSL/TLS всё-таки не стоит считать отдельным протоколом), но в контексте браузера это не очень-то большая проблема. На самом деле эта привязка очень мало мешает (в т.ч. потому что клиентскую сторону на JS всё равно писать придётся, а серверную можно обернуть в вебсокеты, готовых решений полно). ИМХО, существенно она мешает только там, где не то что HTTP(S) не очень-то подходит, а и вообще TCP (так что начинаются всякие SCTP или, напротив, Enet). > а теперь благодаря сабжу их время/эпоха подходит к концу. Хе-хе, сабж если когда-нибудь и внедрят, то очень нескоро, особенно с учётом армии пользователей с мобильных устройств, которые никогда уже не обновятся. Некоторые и на десктопе предпочитают сидеть либо на неподдерживаемых версиях браузера (опасные люди, практически вредители, ибо ловят эксплоиты, а потом другим жизнь портят), либо на особо порезанных (не от хорошей жизни), где вся подобная функциональность зарезана. Тут и про вебсокеты-то до сих пор лишний раз приходится подумать, внедрять или опять извернуться и обойтись без него, а уж это — дожить бы. > А если мне надо отправить запрос на 110-й порт моего_почтового_сервера? Оффтоп, но как же у меня припекает от пользователей POP3: вот вообще ничем он не лучше IMAP4, но всё равно находятся упёртые странные пользователи, которые будут страдать, но продолжать заставлять меня держать лишний сервис на сервере, да загаживать логи своим опросом, не говоря уж про прочие неудобства («пошли мне это письмо ещё раз, а то оно на домашнем компе забралось»). Понимаю, что просто пример, но аргх. > Или на любой другой порт, если меня на другом конце ждёт моя программа-сервер, работающая хоть по телнету и обрабатывающая мои команды на моём спец-языке? ИМХО, лучше всё-таки с такой программой-сервером общаться не через браузер. И так у браузера слишком много функций и это трагично. > Ну это я всё клоню к тому, что нужна просто простая штука для просто подключений на указанный хост по указанному порту без всяких странных наворотов. Такая штука упростит жизнь нескольких разработчиков (хочется сказать каких, ну ладно), но сильно испортит жизнь остальным, т.к. открывает большой просто для злоупотреблений. Тут и так умудряются всякие XSS проворачивать, а с такой штукой (надо быть честным с собой и не верить в то что пользователи будут умные и будут раздавать права только на нужное) открываются невообразимые возможности делать ботнеты на ровном месте. А если вводить аналоги same origin policy и CORS, штука будет довольно бесполезная (и всё равно будут возможности злоупотребления). > Ну типа как просто берёшь, например, tcpcat и "горя не знаешь" Да-да, netcat, socat и т.д. Это всё прекрасно в локальной сети (сам часто пользуюсь), но в дикой природе кроме горя ничего так и не познать. > Конечно-конечно! 30 - это сильно приблизительно! С небольшой погрешностью лет в 7. > :-) (для браузеров в современном понимании, когда во 2-й половине 90-х > уже пошли Нетскейпы после Мозаик да Арахн :-) ) Да, я именно про конец 90-х (а то и начало 2000-х), а это всё-таки совсем не 30 лет. > Оказывается, что интернетом юзер называет браузер. > Поэтому требуется такие задачки решать в среде, в которой люди, уж извините, > ни бум-бум в том, что такое компьютер и программы, которые им > нынче теперь называют: "устройство" вместо "компьютер", "приложения" вместо "программы". > И так далее. Вот именно из-за необходимости ориентироваться на таких пользователей, браузерные (да и вообще сетевые) технологии и стали такими, какие есть. Они (технологии) могут выглядеть жутко, дико, непонятно для разбирающегося на низком уровне, но это результат тяжёлого труда по поиску компромиссов. > Вот так и WebRTC. Хочу открыть исходящее соединение по адресу хост:порт. Ну > сделайте простую функцию с этой парой аргументов (хост, порт) ну и > возможно с назначением callback и т.п., если что, да и всё. В современном мире прежде чем хотеть чтобы что-то появилось, нужно сначала хорошенько подумать: а кто и как этим может злоупотребить? Потому что если что-то может пойти не так, оно обязательно пойдёт худшим из возможных сценариев. Нужно ли разворачивать эту мысль применительно к этому конкретному желанию? > Так нет же. Там нужны ещё сервера сигнальные и TURN. [...] > И объясняют всю эту сложность в WebRTC - необходимостью гарантированного пробивания NAT. И абсолютно правильно объясняют. В современном мире (опять, хех) даже если какой-то провайдер вдруг даёт белый IP, по умолчанию часто на него нельзя подключиться даже с хоста из той же подсети (!). А всё почему? Потому что «требуется такие задачки решать в среде, в которой люди, уж извините, ни бум-бум», отсюда и умолчания соответствующие. > А если мне не надо пробивать NAT и оба браузера находятся в одной локальной сети, даже не подключенной к интернету? То это настолько специфичное исключение, что админ этой корпоративной/институтской сети может обойти (не обязательно ногами) оба этих ПК и установить и настроить там не только браузер, но и другой нужный софт. --- На самом деле, всё ещё намного хуже: в современном мире приходится учитывать не только то что проблемных пользователей и порезанных окружений большинство, так ещё и что программисты по большей части криворуки и не думают о последствиях (а некоторые ещё и при этом очень великого о себе мнения, ведь они не орган собачий, а что-то там писали на чистом WinAPI, ууу), поэтому массовые технологии приходится, гм, делать очень ограниченными и дуракоустойчивыми (как следствие, довольно усложнёнными). Это печально, но приходится смириться с тем что усидеть на всех стульях (чтобы решение было в 5 строчек, и работало устойчиво, и нужды 99% пользователей покрывало) не выйдет и искать компромиссы, выжимая 80% пользы с помощью 20% усилий, а не наоборот.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от rvs2016 (ok), 26-Авг-20, 15:44
	> Гм, аргумент с нагрузкой относился к CGI, а не к EventSource (который > сам по себе имеет весьма малые накладные расходы). Мне это показалось > очевидным, ну да ладно. Ну правильно ж. EventSource пусть себе расходы накладные в браузере несёт весьма малые. Но если этих EventSoure начнёт одновременно набираться тысячами для долбёжки cgi-скрипта, то у машины с веб-сервером, на котором этот скрипт трудится, может появиться напрряг - ну смотря как систему настраивать, конечно. >> а теперь благодаря сабжу их время/эпоха подходит к концу. > Хе-хе, сабж если когда-нибудь и внедрят, то очень нескоро, особенно с учётом > армии пользователей с мобильных устройств, которые никогда уже не обновятся. Есть такая идея, что мобильные, как раз быстрее обновляют свои железки, чем десктопные, т.к. мобилы нынче делают так, что не успел повернуться, а уже "устройство исчерпало память, будет работать плохо, медленно, прегадко и т.д." - после этого простые смертные (которые ни разу не программисты) просто выбрасывают свои мобилы и идут покупать новые. Конечно, какая-то часть населения железяки свои не обновляет. Но это во многом - не платёжеспособная часть населения, которая многим сайтам, увы, всё-равно бесполезна. >> А если мне надо отправить запрос на 110-й порт моего_почтового_сервера? > Оффтоп, но как же у меня припекает от пользователей POP3: вот вообще > ничем он не лучше IMAP4, но всё равно находятся упёртые странные > пользователи, которые будут страдать, но продолжать заставлять меня держать лишний сервис > на сервере, да загаживать логи своим опросом, не говоря уж про > прочие неудобства («пошли мне это письмо ещё раз, а то оно > на домашнем компе забралось»). Понимаю, что просто пример, но аргх. Ну "для сэбэ трошки" POP3 при грамотной настройке работает нормально. И проблем не возникает, если грамотно настроить маршрутизацию почты так, чтоб она была доступна везде в нужных местах. Но это, повторю, верно "для сэбэ трошки" - для людей, умеющих работать грамотно - програмимстов, сисадминов и т.п. А для смертных в промышленных масштабах про POP3 сказать ничего не могу - не работал с почтой масштабно аки крупный почтовый провайдер. >> Или на любой другой порт, если меня на другом конце ждёт моя программа-сервер, работающая хоть по телнету и обрабатывающая мои команды на моём спец-языке? > ИМХО, лучше всё-таки с такой программой-сервером общаться не через браузер. И так > у браузера слишком много функций и это трагично. Если задача стоит так, что общаться должен только браузер (юзеру ж не скажешь - установи себе программу какую-то), то получается, что надо именно браузер заставлять коннектиться к серверу. >> Ну это я всё клоню к тому, что нужна просто простая штука для просто подключений на указанный хост по указанному порту без всяких странных наворотов. > невообразимые возможности делать ботнеты на ровном месте. А если вводить аналоги > same origin policy и CORS, штука будет довольно бесполезная (и всё > равно будут возможности злоупотребления). Да-да. Я тоже думал про то, что эти фичи упростят жизнь злоумышленникам. И тоже думал про то, что нужны ограничители, которые регулирует не юзер (которые макисмальные разрешения навыдаёт), а такие, которые помогают коннкетиться только к "своему сайту/домену" - для многих задач этого достаточно. Ну, например, чат без сервера. Ну не будут же браузеры участников чата коннкетиться куда попало, если им сообщения надо гонять только в своём чате. > Да, я именно про конец 90-х (а то и начало 2000-х), а > это всё-таки совсем не 30 лет. Да это я просто грубо с плеча рубанул - получилось аж 30 лет. Ну по сильно грубому прикиду и без апроксимаций. :-) >> А если мне не надо пробивать NAT и оба браузера находятся в одной локальной сети, даже не подключенной к интернету? > То это настолько специфичное исключение, что админ этой корпоративной/институтской сети > может обойти (не обязательно ногами) оба этих ПК и установить и > настроить там не только браузер, но и другой нужный софт. Ну браузеры внутри одной локалки - это сильно упрощённый пример. А я ж могу точно знать, что у юзера, например, в Уфе браузер на белом IP и к нему можно отправить запрос, например, из Магадана. Я же точно знаю, что NAT между обоими браузерами отсутствует. Ну откуда я это знаю - это "по условиям задачи". Но не смотря на это всё-равно получается так: "мы вам упростили жизнь и теперь вам самим не надо пробивать NAT" (даже если никаким NAT'ом по дороге и не пахнет). Да это ж какая-то медвежья услуга получилась: NAT пробивать не надо, а всё-равно фичи пробивания в нагрузку бери, пожалуйста, и не сетуй. :-) > На самом деле, всё ещё намного хуже: в современном мире приходится учитывать > не только то что проблемных пользователей и порезанных окружений большинство, так > ещё и что программисты по большей части криворуки Эх, да... Мир сложен... Работает, бывает, хороший сайт и через некоторое время работать нормально перестаёт - после прихода на работу в этот сайт вебмастера, который начальству говорит: мой предшественник - профан и мне теперь придётся у вас тут всё перенастроить по другому. Результат - сайт нормально работать перестаёт. Да и не только сайт и не только компьютеры. Во всех отраслях такое бывает... Беда прям...
	Ответить | Правка | Наверх | Cообщить модератору

	203. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от n80 (?), 29-Авг-20, 19:07
	> > Гм, аргумент с нагрузкой относился к CGI, а не к EventSource (который > > сам по себе имеет весьма малые накладные расходы). Мне это показалось > > очевидным, ну да ладно. > Ну правильно ж. EventSource пусть себе расходы накладные в браузере несёт весьма малые. Но если этих EventSource начнёт одновременно набираться тысячами для долбёжки cgi-скрипта, то у машины с веб-сервером, на котором этот скрипт трудится, может появиться напрряг - ну смотря как систему настраивать, конечно. Всё сильнее ощущение, что меня (сравнительно тонко) троллят. Ведь очевидно же, что накладные расходы клиента здесь вообще не являются тем, о чём имеет смысл беспокоиться, да и вообще: клиентов тысячи, а сервер на них один. Равно как и очевидно, что CGI не годится для долгоживущих соединений чуть более, чем совсем. Да и вообще ни для чего (кроме махрового legacy и некачественных сайтов, особенно внутренних) не годится, как ни настраивай систему. Можно сколько угодно оптимизировать fork+exec (vfork+exec, spawn, не важно), подгонять размер стека потоков ядра, подстраивать планировщик и всё равно это будет много хуже (в плане отношений полезной работы к потребляемым ресурсам как сервера, так и разработчика/поддержки), чем сразу делать по уму. Но да, CGI — одна из «святых коров» закостенелых админов (не старых, не опытных, а именно закостенелых, это не от возраста зависит), не желающих даже смотреть на что-либо новое, ведь позволяет писать серверную часть абы как и долго не замечать (читай, игнорировать) проблемы разной степени серьёзности (вплоть до чего-нибудь типа повреждения кучи). А если под «cgi-скриптом» подразумевалось вообще любое серверное ПО для генерации динамики (а не конкретно используемые через CGI программы) — лучше так всё-таки не вводить в заблуждение, у термина есть вполне конкретное значение. > Есть такая идея, что мобильные, как раз быстрее обновляют свои железки, чем десктопные, т.к. мобилы нынче делают так, что не успел повернуться, а уже "устройство исчерпало память, будет работать плохо, медленно, прегадко и т.д." - после этого простые смертные (которые ни разу не программисты) просто выбрасывают свои мобилы и идут покупать новые. > > Конечно, какая-то часть населения железяки свои не обновляет. Но это во многом - не платёжеспособная часть населения, которая многим сайтам, увы, всё-равно бесполезна. Идея интересная, но дело-то не в железках, а в софте. И если на десктопе вроде как программы так или иначе обновляются регулярно (хотя ещё не так давно на это рассчитывать не приходилось), то лепить новые мобильные устройства со старым вшитым софтом (и не выпускать обновления) производители ох как любят. Это не говоря уж про изначально урезанные версии софта по сравнению с исходными версиями. Отдельного гнева, кстати, заслуживает то что в новых версиях мобильных ОС из-за засилья низкосортных кодеров (ну и по коммерческим причинам, конечно) всё сильнее продавливают использование push-уведомлений (в т.ч. в браузере, с необходимостью использовать соответствующий API) вместо поддержания долгих соединений самим приложением. Доходит до того, что очень многие разработчики свято верят, что если программа (какой-нибудь XMPP или IMAP клиент, например) для получения данных с сервера без задержки не использует push-уведомления, то обязательно должна выжирать батарею на глазах (в итоге в свежих версиях ОС уже и нет возможности без этого обойтись, а балбесы и рады). Вот это случай, когда действительно программистов ограничили не по делу, хотя умом и понятно, что «рыночек порешал». > Ну "для сэбэ трошки" POP3 при грамотной настройке работает нормально. И проблем не возникает, если грамотно настроить маршрутизацию почты так, чтоб она была доступна везде в нужных местах. Но это, повторю, верно "для сэбэ трошки" - для людей, умеющих работать грамотно - програмимстов, сисадминов и т.п. А для смертных в промышленных масштабах про POP3 сказать ничего не могу - не работал с почтой масштабно аки крупный почтовый провайдер. Ну начинается. Вкратце — нет, не работает. Можно сколько угодно обкладывать старый протокол костылями (там маршрутизацию подстроить, там плюнуть, тут подпереть, опросом сервер задолбить, опять же), но это называется «закат Солнца вручную». Т.е. вместо того чтобы сразу взять нормальный протокол (который тоже не сказать, что сильно молодой, между прочим) и получить массу полезных фич бесплатно, начинается накостыливание ради, вероятно, поддержки чувства собственной важности. В итоге полученный франкенштейн и будет заведомо хуже работать (не иметь ряда полезных возможностей, создавать лишнюю активность на сервере), и ресурсов будет тратиться (как на настройку/поддержку, так и сервером и клиентами на работу) куда больше. Причём, тут не надо никаких масштабов крупного провайдера. Даже для переписки двух человек важно иметь нулевую (за вычетом собственно времени перекачки по каналам связи) задержку получения новых сообщений (да здравствует достающаяся по сути бесплатно возможность общаться в режиме чата, никак не ломающая возможность общения и в более традиционном формате) и возможность иметь с любого устройства доступ к своим перепискам, заботливо рассортированным по папкам (причём, и отправленные письма, и ответы на них хранятся вместе и отображаются цепочками, ровно как тут на форуме, без всяких нелепых костылей, типа Bcc на себя). Попытка изобразить эту функциональность на базе POP3 обречена на провал, хотя формально часть (но только часть) возможностей и можно кое-как накостылить дополнительными телодвижениями (теша себя тем что, чай, не простой смертный, а ого-го какой нормальный пользователь). Нет ни одной разумной причины использовать POP3 вместо IMAP4 (даже миф про разницу в потреблении трафика оказался мифом), ровно так же как и нет ни одной разумной причины использовать EventStream вместо WebSocket. Есть разве что одна полуразумная причина «у меня так уже было настроено и работает, мне не нужны фичи и я очень не хочу ничего сломать», но это применимо только к машинно-машинному взаимодействию, а для живых пользователей всё-таки плохо подходит (рано или поздно вносить изменения приходится и нужно заранее представлять их цену в случае одной реализации и другой). И уж точно не нужно тащить это барахло в новые инсталляции. Да, очень часто новые технологии хуже старых (в чём-то или, нередко, вообще во всём), регулярно такое вижу, но эти примеры — редкий случай, когда это точно не так, но находится целая армия упирающихся тупо ради своих, сугубо субъективных причин. И вот это явление, называемое «закат Солнца вручную» много где проникает. И полбеды что люди своё время тратят на такую кочергу, так ещё и другим частенько этим создают неудобства. > Если задача стоит так, что общаться должен только браузер (юзеру ж не скажешь - установи себе программу какую-то), то получается, что надо именно браузер заставлять коннектиться к серверу. Как это не скажешь (если только это не восточный пользователь, у которого все сайты через мини-приложения внутри одного комбайна под названием gosuslugi^W WeChat), столько лет ставили программы и продолжают ставить (хотя и всё менее охотно). Успех ряда проприетарных программ (неэтично их лишний раз называть, но мы понимаем о каких программах для обмена сообщениями и файлами, просмотра карт и, например, удалённого доступа к рабочему столу может идти речь) ясно показывает, что если оно того стоит и сделано по уму — пользователь ещё как поставит. Как тут не вспомнить слова (цитирую по памяти, так что не совсем дословно, но суть должна была сохраниться) из полурекламной статьи одного хостера: «не стоит недооценивать пользователей; по нашему опыту, нет таких скриптов, с установкой которых на сервер не разобралась бы очередная instagram-дива ради накрутки +30% like'ов на своих фотографиях». > Да-да. Я тоже думал про то, что эти фичи упростят жизнь злоумышленникам. И тоже думал про то, что нужны ограничители, которые регулирует не юзер (которые максимальные разрешения навыдаёт), а такие, которые помогают коннектиться только к "своему сайту/домену" - для многих задач этого достаточно. Ну, например, чат без сервера. Ну не будут же браузеры участников чата коннкетиться куда попало, если им сообщения надо гонять только в своём чате. А совсем без сервера не получится в любом случае, проблему bootstrap'а никто не отменял. Т.е. либо придётся на старте вбивать адреса руками (опять закатываем вручную?), либо пользоваться своим сервером, либо общественным (к этому в т.ч. относится использование DNS, например). Причём, «либо» тут в смысле неисключающего или. А если полагаться на общественную инфраструктуру, то использование общедоступных STUN/TURN серверов для начального соединения не сильно отличается от того чтобы полагаться на работу DNS. Это не говоря уж про такие занятные штуки, как mDNS. > Ну браузеры внутри одной локалки - это сильно упрощённый пример. Он не столько упрощённый, сколько ИМХО самый распространённый пример такого стечения обстоятельств. > А я ж могу точно знать, что у юзера, например, в Уфе браузер на белом IP и к нему можно отправить запрос, например, из Магадана. Я же точно знаю, что NAT между обоими браузерами отсутствует. Ну откуда я это знаю - это "по условиям задачи". Это замечательно, верю, но теперь нужно не забыть прикинуть, кому нужны именно так построенные задачи. Даже если таких случаев в окружении много (и потому кажется, что их вообще много), они составляют невесомые доли процента от общего числа пользователей. И если дать возможность такие задачи решать так, как этого хочется отдельным, гм, специфичным разработчикам, хорошо жить станет долям процентов, зато остальным участникам процесса (т.е. многим девяткам) станет хуже. Т.е. повторюсь, когда речь идёт о массовых решениях, нужно думать не только о возможной пользе для лично себя и ближайшего окружения, но и потенциальных проблемах для остальных. > Но не смотря на это всё-равно получается так: "мы вам упростили жизнь и теперь вам самим не надо пробивать NAT" (даже если никаким NAT'ом по дороге и не пахнет). Да это ж какая-то медвежья услуга получилась: NAT пробивать не надо, а всё-равно фичи пробивания в нагрузку бери, пожалуйста, и не сетуй. :-) Опять же, ИМХО, эти фичи достаются бесплатно. Т.е. когда они не нужны, они ничего плохого и не делают, а когда нужны (и тут слишком много девяток) — просто работают. Да, есть некоторое неприятное ощущение от того что нужно или иметь свой сервер сигнализации, или пользоваться любыми общественными (а их более чем достаточно, чтобы совсем уж без связи не остаться, не говоря уж про возможность в этом случае поднять свой на любом из хостов участников, раз они все по условию задачи без NAT), но сейчас (в мире отсутствия полного глобального запрета на торренты и прочий P2P) наличие общедоступного STUN/TURN сервера является чем-то столь же само собой разумеющимся, как и наличие работающего DNS. Так что, ИМХО, не тот случай, когда нужно воротить нос и из-за заморачивания по поводу мелкой потенциальной проблемы устраивать реальную и большую (ударение и так, и так). > Работает, бывает, хороший сайт и через некоторое время работать нормально перестаёт - после прихода на работу в этот сайт вебмастера, который начальству говорит: мой предшественник - профан и мне теперь придётся у вас тут всё перенастроить по другому. Результат - сайт нормально работать перестаёт. Да и не только сайт и не только компьютеры. Отож, классика жанра, к сожалению. Но, справедливости ради, у таких историй есть, как минимум, две стороны. Одна (вина которой чаще всего очевидна) — пришедший профан, который полез вносить изменения, не удостоверившись в понимании что, как и _зачем_ было сделано, в наличии бекапов (и того что восстановление из них работает) и, собственно, плана постепенных изменений (включающего в т.ч. некоторое понимание того, что делать, если в какой-то момент поведение системы идёт не по плану). Вторая — предыдущий админ, который мог неограниченно копить технический долг (не устанавливать обновления, втыкать всё новые и новые костыли, регулярно вручную «подшаманивать» отваливающиеся куски системы, борясь вручную с симптомами вместо исправления проблем, настраивать что-то без понимания копипастой и т.д.; и всё это документировать, в лучшем случае, только в унесённой с собой тетрадке, а то и вообще в голове, да и то через раз). Пока такой админ регулярно занимается своим «закатом Солнца вручную», снаружи может быть обманчивая иллюзия идиллии (которая и откладывается в голове у начальства, так что вина этой стороны может быть крайне неочевидной), но настроенная таким образом система имеет свойство быстро и, что важно, неожиданно (через недели или месяцы после ухода шамана) ломаться сама, даже без всяких изменений. А кому не повезёт в этот момент оказаться рядом, на того все шишки и посыпятся, даже если он и бекапами озаботился и разобраться пытался, прежде чем менять. А в силу отсутствия документации и ряда чудом работавших решений (которые даже сам предыдущий админ не понимает как работали) такие системы очень трудно чинятся и, тем более, переносятся на новую платформу. Клубок очень легко запутывается и очень трудно распутывается, скажем так. Бывает, впрочем, и третья сторона, которая наблюдает со стороны и, в силу устройства своей психики (это вообще довольно стандартный защитный механизм у мозга, просто в разной мере проявляется), легко забывает о прошлых проблемах и столь же легко раздувает нынешние, в итоге текущий админ постоянно (до самого его ухода в более здоровое место) поливается отборными помоями и по делу, и без дела, но когда он становится бывшим админом, то новому получателю помоев постоянно упоминается как пример идеала. Это уже, конечно, не из технической области фактор, но тоже важный для полноценного рассмотрения вопроса. Как говорится, плавали, знаем.
	Ответить | Правка | Наверх | Cообщить модератору

	205. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от rvs2016 (ok), 04-Сен-20, 18:03
	> CGI не годится для долгоживущих > соединений чуть более, чем совсем. Что годится для соединений долгоживущих? > CGI — одна из «святых коров» закостенелых админов (не старых, > не опытных, а именно закостенелых, это не от возраста зависит), не > желающих даже смотреть на что-либо новое, ведь позволяет писать серверную часть > абы как и долго не замечать (читай, игнорировать) проблемы разной степени > серьёзности (вплоть до чего-нибудь типа повреждения кучи). > А если под «cgi-скриптом» подразумевалось > вообще любое серверное ПО для генерации > динамики (а не конкретно используемые через CGI программы) Чем на сервере генерируют динамику незакостенелые админы? >> Ну "для сэбэ трошки" POP3 при грамотной настройке работает >> нормально. И проблем не возникает, если грамотно настроить >> маршрутизацию почты так, чтоб она была доступна везде в >> нужных местах. Но это, повторю, верно "для сэбэ трошки" >> - для людей, умеющих работать грамотно - програмимстов, >> сисадминов и т.п. А для смертных в промышленных масштабах >> про POP3 сказать ничего не могу - не работал с почтой >> масштабно аки крупный почтовый провайдер. > ради, вероятно, поддержки чувства собственной важности. Возможно, что где-то такие конфигурации используются по причине поддержки этого чувства. Но мой случай более прост: Мне надо сделать, чтоб система работала. Я так сделал. Других задач у меня нет. :-) > Нет ни одной разумной причины использовать > POP3 вместо IMAP4 (даже миф про разницу в > потреблении трафика оказался мифом), ровно > так же как и нет ни одной разумной причины > использовать EventStream вместо WebSocket. Для настройки WebSocket в браузере хорошие описания по интернетам существуют. А для настройки серверной стороны хороших описаний, показывающих простоту настройки, нет. Вот загрузилась, например, в браузер страница с веб-сервера Апач. Из страницы с помощью WebSocket отправляется по некому адресу запрос на установку соединения. Пока всё хорошо, т.к. действия из пары предыдущих предложений выполнить очень легко. Дальше начинается что-то мало понятное: Кто на сервере должен принять запрос на установку соединения WebSocket? Ну первоначально-то запрос может принять и Апач: ну, например, Апач принял запрос, отдал его обработку моему перл-скрипту, который выдал правильные заголовки, включающие Upgrade и т.п. А дальше что да как? В обычной системе браузер отсылает запросы на веб-сервер отдельными подключениями и веб-сервер даёт на них ответы, после чего соединение сразу же закрывается. А когда соединение из браузера по протоколу WebSocket установлено и является продолжительным, то кто на сервере может это соединение держать и работать с ним? Тут уже хорошие примеры по интернетам на глаза не попадаются. Кто-нибудь может по шагам описать простую и понятную схему настройки серверной части для работы с WebSocket?
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от rvs2016 (ok), 04-Сен-20, 19:14
	> Кто-нибудь может по шагам описать простую и понятную > схему настройки серверной части для работы с WebSocket? По этой части моего доклада сообщаю: В Апач можно из браузера WebSocket'ное соединение и не отправлять. Оно-то и так понятно, что Апач не обязателен. Но просто по привычке хотелось сперва замутить серверную часть с его применением. Многие советы в интернетах советуют запускать сервер на nodejs. Но "не нравится мне этот гусь". :-) Запустил сервер простеньким перловым скриптом с использованием этого: use AnyEvent::Socket; use AnyEvent::Handle; use Protocol::WebSocket::Handshake::Server; use Protocol::WebSocket::Frame; Помогли немного получше осознать "происходящее" примеры со страницы Прагматик перла аж за 2015-й год: http://pragmaticperl.com/issues/26/pragmaticperl-26-%D1... В 15-то году я эту статью читал, но тогда дальше чтения дело не пошло. А нынче руки дошли ещё и до запуска примеров у себя. В примерах там будьте внимательны. Если клиента и сервера запускаете на разных хостах, то в клиенте замените ws://localhost:3000 на ws://хост_вашего_websocket_сервера:3000 А то я и сам на этом сперва попался: сервер работал нормально и локально я к нему телнетом на 3000-й порт подключался успешно, а Файрфоксом со своей рабочей станции подключение к этому не локальному серверу не срабатывало (ибо он же не на моей станции подключения ожидал), пока в клиенте не исправил адрес вебсокетного сервера. А то уже даже на браузер грешить почти начиал уж. :-)
	Ответить | Правка | Наверх | Cообщить модератору

202. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
Сообщение от Linuxforse (ok), 26-Авг-20, 17:08
Сколько бы не критиковали тут эту инициативу - это вполне закономерный и ожидаемый шаг со стороны компаний разрабатывающих мобильные ОС.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема