Исходное сообщение
"В ночных и бета сборках Firefox включена по умолчанию поддер..." Отправлено timur.davletshin, 21-Мрт-21 09:00
> Странный вы народ: в срачах про микроядро vs монолит вы вовсю кричите > что надо все в юзерспейс. А сейчас (и ещё помню новость > про FUSE) уже ярые противники этого подхода. Для начала, я никогда не кричал такого. Есть просто имеющийся сетевой стек и в нём управление потоком для TCP в ядре, а UDP по дизайну не гарантирует доставку, поэтому там управление потоком и его целостностью должно быть выше. Дело даже не в том, что ядерные алгоритмы оттестированы и не страдают склонностью к вендорлоку, а в том, что процесс, управляющий потоком, работать будет с пользовательским приоритетом, что недопустимо для realtime задачи управления потоком. В загруженных условиях пользовательская реализация будет страдать от той же проблемы, на которую наступил когда-то pulseaudio. Сколько тут было орущих про "икание" звука после перехода на pulseaudio (сама идея вообще хороша)? Так вот, это банально из-за невозможности управления realtime задачей из пользовательского пространства в условиях высокой загрузки. Скрытый же мотив гугла в том, чтобы вынести по максимуму всё в зависящий только от cебя блоб. Даже то же обоснование о том, что мультиплексированный в HTTP/2 поток дропает всё в случае потери пакета, и повышенная пропускная способность UDP на беспроводных, нивелируется тем, что тот же оверхед, необходимый для контроля целостности потока, реализуется уже внутри самого QUIC. И он не меньше, а в реальности даже больше, чем у TCP vs UDP.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Странный вы народ: в срачах про микроядро vs монолит вы вовсю кричите >> что надо все в юзерспейс. А сейчас (и ещё помню новость >> про FUSE) уже ярые противники этого подхода. > Для начала, я никогда не кричал такого. Есть просто имеющийся сетевой стек > и в нём управление потоком для TCP в ядре, а UDP > по дизайну не гарантирует доставку, поэтому там управление потоком и его > целостностью должно быть выше. Дело даже не в том, что ядерные > алгоритмы оттестированы и не страдают склонностью к вендорлоку, а в том, > что процесс, управляющий потоком, работать будет с пользовательским приоритетом, что недопустимо > для realtime задачи управления потоком. В загруженных условиях пользовательская реализация > будет страдать от той же проблемы, на которую наступил когда-то pulseaudio. > Сколько тут было орущих про "икание" звука после перехода на pulseaudio > (сама идея вообще хороша)? Так вот, это банально из-за невозможности управления > realtime задачей из пользовательского пространства в условиях высокой загрузки. > Скрытый же мотив гугла в том, чтобы вынести по максимуму всё в > зависящий только от cебя блоб. Даже то же обоснование о том, > что мультиплексированный в HTTP/2 поток дропает всё в случае потери пакета, > и повышенная пропускная способность UDP на беспроводных, нивелируется тем, что тот > же оверхед, необходимый для контроля целостности потока, реализуется уже внутри самого > QUIC. И он не меньше, а в реальности даже больше, чем > у TCP vs UDP.
	Введите код, изображенный на картинке: