Никакого возврата не возникает, так как «домашнему пользователю» вообще всё равно, что у него там, IPv4 или IPv6 или что-то ещё, если оно «просто работает».
IPv6 без NAT жизнь весьма и весьма тяжела
Ну, во-первых, это уже не тот NAT, который подразумевается, когда мы говорим о домашних роутерах и IPv4. Тот называется masquerade и в IPv4 необходим, чтобы выжить, в IPv6 же достаточно простого DNAT, проброса портов. А во-вторых, при желании можно на домашнем сервачке завести свой DynDNS клиент, сделав ему свое имя, и тогда даже никакой DNAT не нужен.
В первом сообщении было написано, что главная проблема IPv6 — незапоминаемые адреса. Но на самом деле это вообще не проблема: если бы провайдеры массово поддерживали IPv6, переход уже состоялся бы, невзирая на то, хотите лично вы IPv6, или нет. Если вы думаете, что провайдеры не поддерживают IPv6 только потому, что их админы не хотят запоминать новые адреса, вы сильно ошибаетесь. Они действительно не хотят их запоминать, просто им это вообще не нужно, дело вообще совсем не в этом. И вообще никому это не нужно, кроме дебага каких-то своих локальных проблем с DNS.
Т.е. основная проблема — это именно нежелание провайдеров разбираться с настройкой IPv6 у себя, и с поддержкой IPv6 у клиентов. И в общем можно их понять, потому что всегда найдется процент клиентов, у которых что-то не заработает и им надо «срочно всё починить», сами они ничего не понимают, но их знакомый что-то понавертел в настройках, а пароль от роутера они не знают и вообще раньше всё работало, верните как было.
Только вот чем больше клиентов, тем больше этот процент, и откладывание на потом лишь отсрочит это, но не исправит. В остальном же сделать так, чтобы IPv6 работал так же plug'n'play, как сейчас IPv4, совершенно реально, и никакие адреса запоминать для этого не требуется.
Он предусмотрен, просто не нужен. Всё, что можно сделать при помощи NAT в IPv6, можно сделать и без него. Единственная причина его использовать — это «ну очень хочется». Причин хотеть его использовать нет, особенно если вы не сетевой инженер какой-нибудь организации, а настраиваете сеть дома.
Чтобы не светить напрямую, и нужен файрволл. Более того, я сильно подозреваю, что в большинстве поддерживающих IPv6 домашних роутеров это сделано по умолчанию, также как и NAT для IPv4.
домен отдельный поднимать и поддерживать задолбаешься
А как решалась бы эта же задача в IPv4 с NAT, когда провайдер выдает не подсеть, а всего один адрес? В самом типовом случае пробросом портов. В IPv6 делаешь ровно то же самое, и всё схлопывается в один адрес, который вполне можно «поднять и поддерживать», а через DynDNS это делается вообще автоматически.
NAT — это тот самый костыль, который обязан существовать в v4, потому что адресов на всех на самом деле не хватает уже сейчас. «Удобнее» он только потому что все роутеры настроены на его использование по умолчанию и не надо с этим возиться руками. К тому же, NAT != firewall, см. например habr.com/ru/post/134638. И именно правильно настроенный файрволл от этого защищает. А настраивать FW на каждой машине внутри сети не нужно: достаточно правильно настроенного FW на роутере.
Очередная теория заговора? Не надоело сочинять ещё?
IPv6 никто не саботирует, просто по IPv4 сейчас работает и умеет работать практически всё, от «умных» лампочек до чего угодно. Если я буду открывать интернет магазин, который работает по v6-only, туда никто не придёт, потому что распространение IPv6 среди пользователей слишком низкое, вот и всё. С обратной стороны та же ситуация: провайдеры не занимаются настройкой IPv6, потому что не хотят себе новых проблем на ровном месте.
Единственный стимул будет тогда, когда появится нужная всем штука, которая не работает по IPv4. Пока же ситуация ровно обратная: github, к примеру, не доступен по IPv6.
Во-первых, как уже ответили, DynDNS решает, во-вторых, проблема-то сейчас не в том, чтобы получить доступ к файловому архиву, ведь правда? Проблема в том, что я не могу у себя дома даже настроить его по IPv6, потому что провайдер не даёт IPv6.
Т.е. проблема с запоминанием адресов, возможно, есть, да только вот это далеко не самая главная проблема, и уж точно не нерешаемая. К примеру, у меня провайдер даёт динамический белый IPv4 — я даже не знаю, какой он у меня сегодня (надо в настройки роутера или на 2ip идти), так что теперь, может IPv4 надо на свалку отнести?
Глупости. Это вообще наименьшая из проблем. В IPv6 на самом деле много сделано, чтобы необходимости запоминать адреса у нормальных пользователей вообще не возникало, и частично от этого и возникают проблемы с переходом на него. Просто к IPv4 все уже привыкли, все знают что такое DHCP, как работает и зачем применяется, а как только выясняется, что в IPv6 можно обойтись без вот этого всего, начинается ступор и непонимание.
Основная же проблема в том, что до недавнего времени IPv6 не был никому нужен. Пользователям — потому что нет сайтов, которые не доступны по IPv4, сайтам — потому что распространение IPv6 никакое. Как только появится очередной фейсбук или амазон IPv6-only, провайдеры мгновенно зачешутся, у себя IPv6 настроят и роутеры всем обновят, некоторые — может даже бесплатно.
Это будет выглядеть как оправдание и никакого положительного PR эффекта не принесёт, поэтому обычно крупные компании не комментируют слухи, если только не произошел (или не произошел) какой-то инцидент.
Зачем нужны опровержения, которым все равно мало кто поверит, если можно самостоятельно сходить на собеседование и всё узнать?
На самом деле с кодировками всё не так уж сложно, и я бы рекомендовал прочитать статью Joel Spolsky, или вот эти статьи на хабре: раз и два. Если вкратце, тут не одна проблема, а как минимум две (если оставить в стороне всякие юникодные комбинации и смайлики):
— соответствие элементов языка и управляющих конструкций числам
— способ хранения этих чисел в памяти
По сути, когда заданы два этих отображения, мы уже можем интерпретировать байты в памяти машины как какой-то текст в определенной кодировке. И слово «юникод» на самом деле по своей сути относится к первой из этих проблем, а «UTF-8» или «UTF-16» — ко второй. А дальше возникает проблема в том, что какой-нибудь древний файл представляет из себя поток байт без указания на то, каким именно способом осуществлялись эти два преобразования. Если прочитать файл, записанный в кодировке KOI8-R, в память и интерпретировать его через CP-1251, мы получим некий «текст» в виде очень странной последовательности русских букв. А если его интерпретировать через CP-1252, получатся «кракозябры», так как в этой странице на месте байт, соответствующих русским буквам находятся всякие буквы с закорючками (диакритическими знаками). При сохранении в юникоде все эти символы останутся «как есть», но станут занимать не один байт, а несколько. При попытке их прочитать в другой кодировке начнутся проблемы.
Но самое печальное происходит, когда в кодировке, в которой сохраняется файл, отсутствует часть символов. В этом случае ничего не остаётся, как заменить их на какой-то «пустой» символ, и часть информации теряется.
В целом никак не отношусь, по-моему в каждом конкретном случае надо смотреть, насколько оно помогает или наоборот вредит. Если утечек памяти нет и её потребление в целом стабильно, не вижу в overcommit ничего плохого.
А вообще я не то чтобы большой специалист по настройке всех этих параметров, просто рассказал то, что знаю, так как кому-то может помочь и сэкономить часть времени на поиск несуществующих проблем в своем приложении. Что, кстати, усугубляется невозможностью простыми средствами наподобие iotop узнать топ процессов по IO на конкретное блочное устройство.
Для тех, кому интересно, что могло быть причиной повышенной дисковой активности: сама по себе нехватка памяти. При увеличении memory pressure сначала начинают сбрасываться дисковые кэши, I/O растёт как из-за сброса грязных страниц, так и из-за уменьшения размеров кэшей, а когда и этой меры оказывается недостаточно, ядро начинает выгружать страницы, занятые отображенными в память файлами программ. Когда программе передаётся управление и поток исполнения доходит до такой страницы, он снова начинает читать её с диска, и т.д.
В общем, при острой нехватке памяти ядро (ну, по крайней мере Linux) пытается сделать всё, чтобы выжить, хотя на самом деле непонятно, действительно ли это так необходимо, поскольку, с одной стороны, процессу с утечкой в любом случае уже ничем не помочь (если есть утечка, память однажды всё равно закончится), а с другой стороны, подобные попытки сохранить жизнь утекающему процессу и отложить вызов OOM-Killer иногда приводят к такому замедлению системы, что проше сразу всю машину ребутнуть, потому что она десятки минут обрабатывает даже ввод с клавиатуры. Вспомним известный баг 12309, говорят, его аналог и в недавних версиях ядра ещё стреляет.
Определения — это не что-то отлитое в граните, всякое определение кто-то однажды придумал для того, чтобы им воспользоваться. Здесь и возникает вопрос удобства. Если можно использовать другое определение без существенной потери смысла, но при этом новое определение удобнее — почему нет?
Пи — это просто обозначение (не определение), оно здесь ни при чём. Хотя и утверждение про «мы же не округляем» тоже неверно само по себе, потому что во многих случаях всё-таки округляем.
«число 1 формально соответствует определению простого числа, кроме того оно имеет еще ряд дополнительных интересных „свойств“»
Соответствует или нет — зависит только от определения. Если в каких-то случаях (пример в статье про множества с бесконечным количеством обратимых элементов) удобнее считать простыми только необратимые элементы, а во всех остальных это не играет роли, то почему бы не использовать одинаковое определение везде? Собственно, я так понимаю, что современное определение простого числа как раз учитывает эту особенность и единица из множества простых исключается.
Ну да, можно сказать что причина практическая, но ведь в этом и есть суть определения — им должно быть удобно пользоваться.
Ну, во-первых, это уже не тот NAT, который подразумевается, когда мы говорим о домашних роутерах и IPv4. Тот называется masquerade и в IPv4 необходим, чтобы выжить, в IPv6 же достаточно простого DNAT, проброса портов. А во-вторых, при желании можно на домашнем сервачке завести свой DynDNS клиент, сделав ему свое имя, и тогда даже никакой DNAT не нужен.
Т.е. основная проблема — это именно нежелание провайдеров разбираться с настройкой IPv6 у себя, и с поддержкой IPv6 у клиентов. И в общем можно их понять, потому что всегда найдется процент клиентов, у которых что-то не заработает и им надо «срочно всё починить», сами они ничего не понимают, но их знакомый что-то понавертел в настройках, а пароль от роутера они не знают и вообще раньше всё работало, верните как было.
Только вот чем больше клиентов, тем больше этот процент, и откладывание на потом лишь отсрочит это, но не исправит. В остальном же сделать так, чтобы IPv6 работал так же plug'n'play, как сейчас IPv4, совершенно реально, и никакие адреса запоминать для этого не требуется.
А как решалась бы эта же задача в IPv4 с NAT, когда провайдер выдает не подсеть, а всего один адрес? В самом типовом случае пробросом портов. В IPv6 делаешь ровно то же самое, и всё схлопывается в один адрес, который вполне можно «поднять и поддерживать», а через DynDNS это делается вообще автоматически.
NAT — это тот самый костыль, который обязан существовать в v4, потому что адресов на всех на самом деле не хватает уже сейчас. «Удобнее» он только потому что все роутеры настроены на его использование по умолчанию и не надо с этим возиться руками. К тому же, NAT != firewall, см. например habr.com/ru/post/134638. И именно правильно настроенный файрволл от этого защищает. А настраивать FW на каждой машине внутри сети не нужно: достаточно правильно настроенного FW на роутере.
IPv6 никто не саботирует, просто по IPv4 сейчас работает и умеет работать практически всё, от «умных» лампочек до чего угодно. Если я буду открывать интернет магазин, который работает по v6-only, туда никто не придёт, потому что распространение IPv6 среди пользователей слишком низкое, вот и всё. С обратной стороны та же ситуация: провайдеры не занимаются настройкой IPv6, потому что не хотят себе новых проблем на ровном месте.
Единственный стимул будет тогда, когда появится нужная всем штука, которая не работает по IPv4. Пока же ситуация ровно обратная: github, к примеру, не доступен по IPv6.
Т.е. проблема с запоминанием адресов, возможно, есть, да только вот это далеко не самая главная проблема, и уж точно не нерешаемая. К примеру, у меня провайдер даёт динамический белый IPv4 — я даже не знаю, какой он у меня сегодня (надо в настройки роутера или на 2ip идти), так что теперь, может IPv4 надо на свалку отнести?
Эм. Нет, всё же это именно нежелание копнуть поглубже.
Основная же проблема в том, что до недавнего времени IPv6 не был никому нужен. Пользователям — потому что нет сайтов, которые не доступны по IPv4, сайтам — потому что распространение IPv6 никакое. Как только появится очередной фейсбук или амазон IPv6-only, провайдеры мгновенно зачешутся, у себя IPv6 настроят и роутеры всем обновят, некоторые — может даже бесплатно.
Зачем нужны опровержения, которым все равно мало кто поверит, если можно самостоятельно сходить на собеседование и всё узнать?
— соответствие элементов языка и управляющих конструкций числам
— способ хранения этих чисел в памяти
По сути, когда заданы два этих отображения, мы уже можем интерпретировать байты в памяти машины как какой-то текст в определенной кодировке. И слово «юникод» на самом деле по своей сути относится к первой из этих проблем, а «UTF-8» или «UTF-16» — ко второй. А дальше возникает проблема в том, что какой-нибудь древний файл представляет из себя поток байт без указания на то, каким именно способом осуществлялись эти два преобразования. Если прочитать файл, записанный в кодировке KOI8-R, в память и интерпретировать его через CP-1251, мы получим некий «текст» в виде очень странной последовательности русских букв. А если его интерпретировать через CP-1252, получатся «кракозябры», так как в этой странице на месте байт, соответствующих русским буквам находятся всякие буквы с закорючками (диакритическими знаками). При сохранении в юникоде все эти символы останутся «как есть», но станут занимать не один байт, а несколько. При попытке их прочитать в другой кодировке начнутся проблемы.
Но самое печальное происходит, когда в кодировке, в которой сохраняется файл, отсутствует часть символов. В этом случае ничего не остаётся, как заменить их на какой-то «пустой» символ, и часть информации теряется.
А вообще я не то чтобы большой специалист по настройке всех этих параметров, просто рассказал то, что знаю, так как кому-то может помочь и сэкономить часть времени на поиск несуществующих проблем в своем приложении. Что, кстати, усугубляется невозможностью простыми средствами наподобие iotop узнать топ процессов по IO на конкретное блочное устройство.
В общем, при острой нехватке памяти ядро (ну, по крайней мере Linux) пытается сделать всё, чтобы выжить, хотя на самом деле непонятно, действительно ли это так необходимо, поскольку, с одной стороны, процессу с утечкой в любом случае уже ничем не помочь (если есть утечка, память однажды всё равно закончится), а с другой стороны, подобные попытки сохранить жизнь утекающему процессу и отложить вызов OOM-Killer иногда приводят к такому замедлению системы, что проше сразу всю машину ребутнуть, потому что она десятки минут обрабатывает даже ввод с клавиатуры. Вспомним известный баг 12309, говорят, его аналог и в недавних версиях ядра ещё стреляет.
Пи — это просто обозначение (не определение), оно здесь ни при чём. Хотя и утверждение про «мы же не округляем» тоже неверно само по себе, потому что во многих случаях всё-таки округляем.
Соответствует или нет — зависит только от определения. Если в каких-то случаях (пример в статье про множества с бесконечным количеством обратимых элементов) удобнее считать простыми только необратимые элементы, а во всех остальных это не играет роли, то почему бы не использовать одинаковое определение везде? Собственно, я так понимаю, что современное определение простого числа как раз учитывает эту особенность и единица из множества простых исключается.
Ну да, можно сказать что причина практическая, но ведь в этом и есть суть определения — им должно быть удобно пользоваться.