Нет, не увеличивает. Вы не сможете, как с IPv4, просканировать /64 за вменяемое время, если там сидит RFC 4941, а оно там сидит везде по дефолту уже давно.
А я ещё застал времена, когда vk.com был доступен по IPv6.
Простейший пример - протокол FTP, активный режим. Там приложение говорит: мой адрес такой-то, подключайся.
Так FTP в активном режиме сквозь NAT не заработает и в IPv4, так что приходится городить костыли с вмешательством в контрольное соединение или принудительно всех заставлять работать в пассивном режиме.
Хотя, вообще, FTP в 2024 году это уже позор позорный, при наличии всяческих SFTP, rsync и прочего.
Из книжки в книжку и из статьи в статью эту хрень бездумно переписывают :(
Виртуальная память позволяет системе исполнять код приложений, используя больший объем памяти, чем физически доступно. Это достигается путем сброса неиспользуемых блоков памяти приложений на диск
А если диска нет (тонкий клиент, например), или свопинг вообще отключен, то что тогда с виртуальной памятью происходит? Она ведь как-то всё равно продолжает работать?
А философия Линукс в случае заключается в том, что всегда следует стремиться сделать данные человеко-читаемыми. И отступать от этого только если обстоятельства не позволяют (например производительность).
Вот эти линукс-философы на ранней стадии развития Интернета понапридумывали человеко-читаемых протоколов, все эти HTTP/SMTP/POP3/IMAP/IRC/Telnet/SIP/XMPP и, прости г-ди, FTP, кое-где даже нарушая разделение сетевой модели на уровни. Плюс извращения вроде того, что кошерный SMTP обязательно должен влезать в 7-битный ASCII, так что извольте сексоваться с MIME туда-сюда.
А сейчас не могу не заметить явную тенденцию, что всё, что приходит им на смену -- сплошная бинарщина. Не отдельные изолированные случаи нехватки производительности, а просто везде. http/3,grpc,mtproto,ssh и всё в этом же духе.
Как, глядя на данные, мне нужно понять, что их надо представлять в машино (компиляторо) нечитаемом виде?
Очень просто. Вы же знаете, кто эти данные будет читать, исходя из ТЗ и архитектуры проекта? Ну вот в таком виде и представляйте.
Тем более, я конкретные примеры привёл.
статья про код.
Статья -- да. А конкретно эта ветка -- про особенности текстового представления десятичных дробей и смежные проблемы. Ваш экскурс в компиляторы вообще не уместен.
Ну, в вашем случае, возможно. Но, честно говоря, для меня и сам по себе CSV это какое-то извращение. Есть же protobuf, есть bson, да куча всего есть. Да даже json, если вам человеко-читаемость так сильно упёрлась -- там точка закреплена стандартом.
Не спешите расписываться за всю науку. Я довольно много работал с сырыми данными миссий SRTM да и вообще с DEM моделями, как для пет-проектов, так и для муниципальных. И не было там никаких точек и десятичных разделителей вообще. Чистая бинарщина, двухкоординатный меш из 16-bit signed big-endian. Что есть архитектурно правильно.
Вы предлагаете всю эту систему сломать
Нет. Я предлагаю хотя бы называть вещи своими именами. Кривое легаси -- кривым легаси.
В противном случае можно закончить насильственным внедрением системы СИ, например, в США - ради общего блага, естественно.
А вы в курсе, что в этих самых США однажды всю космическую индустрию вместе с NASA взяли да и принудительно перевели как раз таки на систему СИ?
Потому что до того кто-то там посчитал параметры Mars Climate Orbiter в одной неметрической системе, а кто-то другой -- в другой, но тоже неметрической и в результате корабль был потерян с концами. Это к вопросу о том, нужно ли стандарты соблюдать или делать «как привычно».
Нет, не увеличивает. Вы не сможете, как с IPv4, просканировать /64 за вменяемое время, если там сидит RFC 4941, а оно там сидит везде по дефолту уже давно.
Не сложность, а лень админов. Ничего принципиально сложного в v6 нет.
Вот так и про UTF говорили. Мол значительно сложнее считать длину, зачем это нужно, всё ж и так работает...
А я ещё застал времена, когда vk.com был доступен по IPv6.
Так FTP в активном режиме сквозь NAT не заработает и в IPv4, так что приходится городить костыли с вмешательством в контрольное соединение или принудительно всех заставлять работать в пассивном режиме.
Хотя, вообще, FTP в 2024 году это уже позор позорный, при наличии всяческих SFTP, rsync и прочего.
А вы можете эту сложность выразить в каких-нибудь измеримых значениях?
Из книжки в книжку и из статьи в статью эту хрень бездумно переписывают :(
А если диска нет (тонкий клиент, например), или свопинг вообще отключен, то что тогда с виртуальной памятью происходит? Она ведь как-то всё равно продолжает работать?
Хорошим тоном в статьях считается расшифровывать аббревиатуры там, где они встречаются впервые в тексте.
Баадера-Майнхоф?
Вы не доверяете подсчётам, а предпочитаете верить. Но требуете всё же почему-то не амулет на удачу, а близкую к 100% вероятность.
Так не смотрите новости, делов-то. Если в этом проблема.
А то ведь шанс быть сбитым машиной на улице на порядки выше, но вас это от выхода из дому не останавливает же.
Не только в Боингах. Вообще вся авиация использует футовые эшелоны (кроме некоторых стран Средней Азии)
https://en.wikipedia.org/wiki/Flight_level
Ага, чемоданы денег заносят разработчикам, чтобы они, не дай бох, не изобретали новые текстовые форматы обмена данными.
Вот эти линукс-философы на ранней стадии развития Интернета понапридумывали человеко-читаемых протоколов, все эти HTTP/SMTP/POP3/IMAP/IRC/Telnet/SIP/XMPP и, прости г-ди, FTP, кое-где даже нарушая разделение сетевой модели на уровни. Плюс извращения вроде того, что кошерный SMTP обязательно должен влезать в 7-битный ASCII, так что извольте сексоваться с MIME туда-сюда.
А сейчас не могу не заметить явную тенденцию, что всё, что приходит им на смену -- сплошная бинарщина. Не отдельные изолированные случаи нехватки производительности, а просто везде. http/3,grpc,mtproto,ssh и всё в этом же духе.
Не спроста это жжж.
Вам от этого легче станет?
Ну окей, я был неправ по поводу того, что "нет там такого".
Остальное всё в силе.
Очень просто. Вы же знаете, кто эти данные будет читать, исходя из ТЗ и архитектуры проекта? Ну вот в таком виде и представляйте.
Тем более, я конкретные примеры привёл.
Статья -- да. А конкретно эта ветка -- про особенности текстового представления десятичных дробей и смежные проблемы. Ваш экскурс в компиляторы вообще не уместен.
Попытался представить себе условный нетфликс, который стримит фильмы в текстовом потоке...
Эти принципы, как и любые другие, имеют свою область применимости. И не следует возводить их в абсолют.
Признак: данные, которые подвержены национально-специфичному форматированию.
Например, локализованные названия дней недели, месяцев, метки am/pm, да даже банальный DD-MM-YYYY или MM-DD-YYYY.
Нет, не такие. А к чему вопрос?
Нет там такого.
А покажите, пожалуйста, где именно в Линуксе это считается лучшей практикой.
Ну, в вашем случае, возможно. Но, честно говоря, для меня и сам по себе CSV это какое-то извращение. Есть же protobuf, есть bson, да куча всего есть. Да даже json, если вам человеко-читаемость так сильно упёрлась -- там точка закреплена стандартом.
Не спешите расписываться за всю науку. Я довольно много работал с сырыми данными миссий SRTM да и вообще с DEM моделями, как для пет-проектов, так и для муниципальных. И не было там никаких точек и десятичных разделителей вообще. Чистая бинарщина, двухкоординатный меш из 16-bit signed big-endian. Что есть архитектурно правильно.
Нет. Я предлагаю хотя бы называть вещи своими именами. Кривое легаси -- кривым легаси.
А вы в курсе, что в этих самых США однажды всю космическую индустрию вместе с NASA взяли да и принудительно перевели как раз таки на систему СИ?
Потому что до того кто-то там посчитал параметры Mars Climate Orbiter в одной неметрической системе, а кто-то другой -- в другой, но тоже неметрической и в результате корабль был потерян с концами. Это к вопросу о том, нужно ли стандарты соблюдать или делать «как привычно».
Если компиляторы занимаются чтением и обработкой данных, которые подвержены национально-специфичному форматированию -- то да, иначе -- нет.