А ещё новый "skype for linux" не поддерживает 32-бит режим вообще, кажется (по крайней мере при скачивании безальтернативно предлагается ссылка на 64-бит версию), что уже достаточно давно и по-моему намного важнее.
Ну что за передёргивание опять.
ЭТОТ закон не про шифрование, он про обход блокировок. Пока вы не предоставляете публичного прокси-сервиса (с помощью хоть VPN, хоть web-proxy — пофиг), он вас не касается. Может быть есть или будут какие-то другие, но речь то не о них.
линкедин заблокировали из-за детской порнографии?
Линкедин заблокировали за отказ делать локальный российский сегмент и это не скрывалось. Причём тут порнография?
Не вдаваясь в политические детали, можно заметить, что они передёргивают факты. Никто не собирался запрещать их корпоративные VPN'ы, речь там идёт совершенно о другом.
Да и вообще, предназначение VPN это вовсе не проксирование трафика и прочие фокусы с адресами, как видимо думает ряд малограмотных личностей, а организация защищённой виртуальной локалки без привязки к физическим каналам. То, что некоторые научились туннелировать через VPN траффик с целью обмана фильтров траффика — побочное следствие её функционала и претензии в законе именно к нему. Точно так же как у множества легальных гражданских предметов есть способы незаконно их применять (например у кухонных ножей).
Каким это образом платёжные системы стали неотслеживаемыми? Думаю там каждая операция записана — кто, когда, откуда, кому отправил, и кто, когда, где получил, и хранится это условно бессрочно.
Статью не осилил, но недовольство безналом поддерживаю. Считаю что любые безнал доходы надо сразу переводить в нал и пользоваться только им, таким образом показывая например магазинам нужность нала и ненужность банковских терминалов на кассах.
А что вы хотите от ethernet? Свою задачу — передавать цифровые пакеты по витой паре либо по оптоволокну (это как минимум две разные технологии, кстати) между двумя портами — он выполняет нормально. И ничего большего, кажется, не требует. Всё остальное — софт на устройствах с этими портами.
Забавно наблюдать сначала "отчёт о том как я вставлял память в материнку" а потом — муки "какую же память выбрать".
Так же странно видеть подряд утверждения "много занятых слотов — меньше скорость, поставлю ка лучше одну планку большого объёма" а потом "поставлю планки во все слоты поровну, так лучше". Дело даже не в том, что первое утверждение неверное (этого автор мог просто не знать), а в том, что первое и второе утверждения прямо друг другу противоречат и автора это кажется не смущает.
Вы знаете кучу умных слов, но совершенно не понимаете как принципы построения сетей, так и механизм работы своего любимого блокчейна. Впрочем от блокчейн-адептов другого ждать не приходится.
Прелесть всего этого в отсутствии необходимости в IP в целом.
А если написать программу для выполнения операций сложения и прочей арифметики, то можно будет делать компы без процессоров и с этой программой вместо них.
Про IP адрес маршрутизатора в роут-таблице, в целом, вопрос понятный: чтобы не перенастраивать всю сеть при замене роутера.
Так речь как раз о том, что "всей сети" этот адрес вообще не нужен. Для включённого в порт компьютера есть "адрес маршрутизатора" — он шлёт пакеты в подключённый к нему кабель, а куда они пойдут дальше — уже должно быть делом свитча. Но вместо этого работает legacy-схема где свитч эмулирует шину с кучей неструктурированных участников, по которой они договариваются самостоятельно с использованием ненужных по сути протоколов.
Избавляться от заголовков ethernet только ради избавления, рискуя сломать себе сеть, потратив деньги и ничего не получив взамен, никто не будет.
Ну да.
В вашей схеме не решен, по крайней мере, вопрос нехватки адресов v4,
Да, это был ответ на статью, в которой рассказывается про некоторые другие "проблемы", кроме адресов.
а также непонятен профит в материальном выражении для организации от замены всех сетевых железок на другие.
Например можно немного сэкономить те же адреса, не выделяя их на адреса сеетй, броадкасты и адреса маршрутизаторов. А так же такая система по-моему работает более прозрачно.
Любой основополагающий широко используемый протокол будет сложно заменить (это про IP). А всякие надстройки над ним, о которых сокрушается автор, заменить очень легко, но никому обычно не нужно — всё и так работает.
Статья несколько сумбурная и с водой. Практически всё то, что он ставит в минусы имеющихся протоколов (IPv4 ARP TCP итд) — элементарно исправляется без затрагивания самих протоколов, сменой алгоритмов работы сетевого железа (возможно тут и нет преимущества по деньгам перед ipv6, но тут не ломается глобальная совместимость с остальным интернетом).
Я тоже не понимаю зачем писать адрес шлюза в виде ip-адреса, а не mac-ом и зачем вообще эмулировать шину на современном железе, где её фактически нет. Но вот например решение, которое практически убирает эти ненужные детали, не ломая никаких совместимостей: вся сеть предприятия логически организуется как один диапазон, в прошивку свитчей встраивается ARP-заглушка, чтобы отдавать хоть какой-то ответ на запросы от клиентов, а весь реальный роутинг делается по полям адреса IP-заголовка. При этом с вопросами типа "где шлюз", "куда слать пакеты для внешнего инета" разберётся уже сам апгрейднутый свитч, не грузя этим клиентские устройства и не генерируя лишние броадкасты. MAC-адреса при этом можно (но не обязательно) использовать свитчами для автоконфигурации клиентов, игнорируя и заменяя заглушками большую часть DHCP-протокола, а так же для дополнительного небольшого слоя безопасности, если надо.
При этом изменить надо только прошивку сетевого железа (да, это может быть затратно), а всё остальные железки могут продолжать, что находятся в традиционой IPv4-сети и ничего не заметят.
Ну а потом, имея уже вышеописанный вариант сетевой инфраструктуры, можно постепенно и неторопясь вырезать из клиентов уже ненужный функционал типа ARP (если он беспокоит).
Точно так же его фиксирует любой гос. реестр. Оператор данной базы данных, как бы вы её ни называли, всегда сможет что-то в ней изменить и никакие криптохеши ему в этом не помешают.
if ((uintptr_t)p >= (uintptr_t)regionStart &&
(uintptr_t)p < (uintptr_t)regionStart + (uintptr_t)regionSize)
Этот вариант, в целом, хороший, но иногда может и создать проблему, если кто-то захочет использовать вместо реального regionSize какое-то абстрактное большое число (допустимость этого — отдельная тема). А ещё он может доставить проблемы уже в полностью законном случае — если конец проверяемой области памяти совпадает с концом адресного пространства (p+regionSize=0x100000000 для 32бит превратится в 0). Вариант, который ничем не уступает процитированному, но лишен указанного недостатка:
if ((uintptr_t)p >= (uintptr_t)regionStart &&
(uintptr_t)p - (uintptr_t)regionStart < (uintptr_t)regionSize)
А если сделать -fno-strict-overflow то можно ещё и опустить первую половину условия (но это уже некоторые могут посчитать плохим).
Хорошо, теперь мы можем построить контрпример. Пусть regionStart = 0101:0000, а regionSize = 0x00020000.
Пример (и весь его последующий анализ, соответственно) некорректен, в 16-бит системе не может быть regionSize больше чем 0x10000 (на самом деле и это число не влезет в 16-битный size_t, но это уже проблемы языка, а сегмент такого размера сделать всё же можно, а вот больше — нет). Селектор это индекс сегмента в весьма произвольной таблице, а не линейный номер участка памяти.
А ещё новый "skype for linux" не поддерживает 32-бит режим вообще, кажется (по крайней мере при скачивании безальтернативно предлагается ссылка на 64-бит версию), что уже достаточно давно и по-моему намного важнее.
Ну что за передёргивание опять.
ЭТОТ закон не про шифрование, он про обход блокировок. Пока вы не предоставляете публичного прокси-сервиса (с помощью хоть VPN, хоть web-proxy — пофиг), он вас не касается. Может быть есть или будут какие-то другие, но речь то не о них.
Линкедин заблокировали за отказ делать локальный российский сегмент и это не скрывалось. Причём тут порнография?
Вам никаких претензий и не предъявят, если всё как вы говорите.
Если запретители считают что VPN = прокси то это некомпетентность, да. Но я не интересовался этими деталями.
То вы наверно правительство Китая. Собственно, в этом случае и остальные проблемы тоже решатся.
Не вдаваясь в политические детали, можно заметить, что они передёргивают факты. Никто не собирался запрещать их корпоративные VPN'ы, речь там идёт совершенно о другом.
Да и вообще, предназначение VPN это вовсе не проксирование трафика и прочие фокусы с адресами, как видимо думает ряд малограмотных личностей, а организация защищённой виртуальной локалки без привязки к физическим каналам. То, что некоторые научились туннелировать через VPN траффик с целью обмана фильтров траффика — побочное следствие её функционала и претензии в законе именно к нему. Точно так же как у множества легальных гражданских предметов есть способы незаконно их применять (например у кухонных ножей).
Каким это образом платёжные системы стали неотслеживаемыми? Думаю там каждая операция записана — кто, когда, откуда, кому отправил, и кто, когда, где получил, и хранится это условно бессрочно.
Статью не осилил, но недовольство безналом поддерживаю. Считаю что любые безнал доходы надо сразу переводить в нал и пользоваться только им, таким образом показывая например магазинам нужность нала и ненужность банковских терминалов на кассах.
А что вы хотите от ethernet? Свою задачу — передавать цифровые пакеты по витой паре либо по оптоволокну (это как минимум две разные технологии, кстати) между двумя портами — он выполняет нормально. И ничего большего, кажется, не требует. Всё остальное — софт на устройствах с этими портами.
Забавно наблюдать сначала "отчёт о том как я вставлял память в материнку" а потом — муки "какую же память выбрать".
Так же странно видеть подряд утверждения "много занятых слотов — меньше скорость, поставлю ка лучше одну планку большого объёма" а потом "поставлю планки во все слоты поровну, так лучше". Дело даже не в том, что первое утверждение неверное (этого автор мог просто не знать), а в том, что первое и второе утверждения прямо друг другу противоречат и автора это кажется не смущает.
Вы знаете кучу умных слов, но совершенно не понимаете как принципы построения сетей, так и механизм работы своего любимого блокчейна. Впрочем от блокчейн-адептов другого ждать не приходится.
Адепты блокчейнов добрались и сюда.
А если написать программу для выполнения операций сложения и прочей арифметики, то можно будет делать компы без процессоров и с этой программой вместо них.
Так речь как раз о том, что "всей сети" этот адрес вообще не нужен. Для включённого в порт компьютера есть "адрес маршрутизатора" — он шлёт пакеты в подключённый к нему кабель, а куда они пойдут дальше — уже должно быть делом свитча. Но вместо этого работает legacy-схема где свитч эмулирует шину с кучей неструктурированных участников, по которой они договариваются самостоятельно с использованием ненужных по сути протоколов.
Ну да.
Да, это был ответ на статью, в которой рассказывается про некоторые другие "проблемы", кроме адресов.
Например можно немного сэкономить те же адреса, не выделяя их на адреса сеетй, броадкасты и адреса маршрутизаторов. А так же такая система по-моему работает более прозрачно.
Любой основополагающий широко используемый протокол будет сложно заменить (это про IP). А всякие надстройки над ним, о которых сокрушается автор, заменить очень легко, но никому обычно не нужно — всё и так работает.
Статья несколько сумбурная и с водой. Практически всё то, что он ставит в минусы имеющихся протоколов (IPv4 ARP TCP итд) — элементарно исправляется без затрагивания самих протоколов, сменой алгоритмов работы сетевого железа (возможно тут и нет преимущества по деньгам перед ipv6, но тут не ломается глобальная совместимость с остальным интернетом).
Я тоже не понимаю зачем писать адрес шлюза в виде ip-адреса, а не mac-ом и зачем вообще эмулировать шину на современном железе, где её фактически нет. Но вот например решение, которое практически убирает эти ненужные детали, не ломая никаких совместимостей: вся сеть предприятия логически организуется как один диапазон, в прошивку свитчей встраивается ARP-заглушка, чтобы отдавать хоть какой-то ответ на запросы от клиентов, а весь реальный роутинг делается по полям адреса IP-заголовка. При этом с вопросами типа "где шлюз", "куда слать пакеты для внешнего инета" разберётся уже сам апгрейднутый свитч, не грузя этим клиентские устройства и не генерируя лишние броадкасты. MAC-адреса при этом можно (но не обязательно) использовать свитчами для автоконфигурации клиентов, игнорируя и заменяя заглушками большую часть DHCP-протокола, а так же для дополнительного небольшого слоя безопасности, если надо.
При этом изменить надо только прошивку сетевого железа (да, это может быть затратно), а всё остальные железки могут продолжать, что находятся в традиционой IPv4-сети и ничего не заметят.
Ну а потом, имея уже вышеописанный вариант сетевой инфраструктуры, можно постепенно и неторопясь вырезать из клиентов уже ненужный функционал типа ARP (если он беспокоит).
Достаточно лучше следить за исполнением законов о запрете скрытой съёмки, вместо придумывания технических мер противодействия.
Точно так же его фиксирует любой гос. реестр. Оператор данной базы данных, как бы вы её ни называли, всегда сможет что-то в ней изменить и никакие криптохеши ему в этом не помешают.
Этот вариант, в целом, хороший, но иногда может и создать проблему, если кто-то захочет использовать вместо реального regionSize какое-то абстрактное большое число (допустимость этого — отдельная тема). А ещё он может доставить проблемы уже в полностью законном случае — если конец проверяемой области памяти совпадает с концом адресного пространства (p+regionSize=0x100000000 для 32бит превратится в 0). Вариант, который ничем не уступает процитированному, но лишен указанного недостатка:
А если сделать -fno-strict-overflow то можно ещё и опустить первую половину условия (но это уже некоторые могут посчитать плохим).
Пример (и весь его последующий анализ, соответственно) некорректен, в 16-бит системе не может быть regionSize больше чем 0x10000 (на самом деле и это число не влезет в 16-битный size_t, но это уже проблемы языка, а сегмент такого размера сделать всё же можно, а вот больше — нет). Селектор это индекс сегмента в весьма произвольной таблице, а не линейный номер участка памяти.
Я может чего-то не понимаю, но разве 256 AS не сделают как минимум столько же узлов в tcp/ip трассировке, на которую всё не хватит никакого TTL?