Комментарии 40
Долго думал, к чему тут 25 лет, и почему именно 7 утра… Не у всех UTC+4 (^_-)
UTC+4, т.е. московское время: проблема наступит в 3:14 UTC (несложно запомнить, да) 19 января.
Пока гром не грянет мужик не перекрестится.
Ух, захватывающая история!
Автор, хороший слог. Интересно а что делать через 25 лет в 7 утра тем кто будет лететь в самолете? :)
Планету собрали, пусть и с третьего раза.
Отличная фраза. :)
Отличная фраза. :)
Звучит как дебаг 2645 года и проблемы с 128bit int.
Звучит как продолжение известной серии книг.
Вспомнился случайно замеченный комментарий в чейнджлоге Far Manager:
www.farmanager.com/svn/trunk/unicode_far/changelog
drkns 17.12.2010 18:58:27 +0200 — build 1762
1. Поступили слухи, что в диалоге атрибутов некорректно отображались пятизначные года.
Вот это забота о будущих поколениях, а не какая-то там ошибка 2000 или 2038 года, и даже не 2645. Особенно радует оптимизм авторов консольного файлового менеджера.
www.farmanager.com/svn/trunk/unicode_far/changelog
drkns 17.12.2010 18:58:27 +0200 — build 1762
1. Поступили слухи, что в диалоге атрибутов некорректно отображались пятизначные года.
Вот это забота о будущих поколениях, а не какая-то там ошибка 2000 или 2038 года, и даже не 2645. Особенно радует оптимизм авторов консольного файлового менеджера.
У меня тоже не всегда с первого раза собиралась.
emerge -vuDN world
Примерно так же республиканцы с демократами тянули до последнего вопрос договоренности по бюджету на фоне потенциального фискального обрыва. Проблемы парламентской неавторитарной среды.
А какой умник вообще додумался идентефикатор держать в int? По-моему, базовых знаний о базах должно хватать, чтобы понимать абсурдность таких действий.
Не судите строго, когда у вас 2^31 объектов, то на какие только оптимизации не идешь, чтобы сэкономить пару сотен Gb.
И на чем же? )))
Если рассматривать в «чистом» виде, то разница в 4 байта — это ровно 16 гиг экономии (на максимальных 2^32 рекордах). Экономить на строках надо.
Однако, если мне не изменяет память, то для 64-ехразрядных систем что int, что long, занимают одинаково — по 8 байт. Представить себе приличный НЕ 64-ехразрядный сервер сложно… Не знаю ни какая база, ни какая система, но предполагаю, что возможна ситуация, когда памяти выделено что на инт, что на лонг одинаково, однако из-за того, что объявлен был инт, банально стоит ограничитель индексов. Вот это засада!
Если рассматривать в «чистом» виде, то разница в 4 байта — это ровно 16 гиг экономии (на максимальных 2^32 рекордах). Экономить на строках надо.
Однако, если мне не изменяет память, то для 64-ехразрядных систем что int, что long, занимают одинаково — по 8 байт. Представить себе приличный НЕ 64-ехразрядный сервер сложно… Не знаю ни какая база, ни какая система, но предполагаю, что возможна ситуация, когда памяти выделено что на инт, что на лонг одинаково, однако из-за того, что объявлен был инт, банально стоит ограничитель индексов. Вот это засада!
Однако, если мне не изменяет память, то для 64-ехразрядных систем что int, что long, занимают одинаково — по 8 байт. Представить себе приличный НЕ 64-ехразрядный сервер сложно… Не знаю ни какая база, ни какая система, но предполагаю, что возможна ситуация, когда памяти выделено что на инт, что на лонг одинаково, однако из-за того, что объявлен был инт, банально стоит ограничитель индексов. Вот это засада!
Опасаюсь, что ваша память вам всё-таки изменяет.
Но вот зачем OSMу отрицательные идентификаторы, я и сам не понимаю.
Соглашусь с первым комментатором — экономия на спичках. 32-битные системы — тоже не оправдание — для идентификатора не нужно сложной математики, вроде умножения или деления. Ну будет 8 тактов вместо 5 для сравнения для ARM.
Подозреваю —обычный быдлокод непродуманность архитектуры.
Подозреваю —
Обработчики данных OSM стараются как можно больше загрузить в память. База сейчас приближается к половине терабайта. Поэтому те, кому это критично, экономят. Своп — не выход. Например, роутинговая библиотека OSRM хранит весь дорожный граф в памяти.
Хотя в большинстве случаев, конечно, причиной простая безалаберность: редко в реальной жизни встречаются такие большие числа, забываешь.
Хотя в большинстве случаев, конечно, причиной простая безалаберность: редко в реальной жизни встречаются такие большие числа, забываешь.
Нод, который сломал планету
www.openstreetmap.org/browse/node/2147483648
www.openstreetmap.org/browse/node/2147483648
Скорее эта нода:
www.openstreetmap.org/browse/node/2147483647
www.openstreetmap.org/browse/node/2147483647
Чертовы французы, спустя 200 лет опять за свое!
Мда, ничему жизнь не учит… Спасибо за историю! И смех и грех, как говорится)
Сам использую OSM, поэтому для меня тема очень актуальна.
Только я что-то пропустил, последние добавленные точки похерили старые? В итоге все живы?
Сам использую OSM, поэтому для меня тема очень актуальна.
Только я что-то пропустил, последние добавленные точки похерили старые? В итоге все живы?
Интересно, а какой процент всех этих данных составляет мусор: неточные, устаревшие и просто бесполезные (в стиле «гараж Васька») данные?
Если Васёк нарисовал свой гараж значит не так уж это и бесполезно. Неточности уточняются, устаревшие удаляются. А идентификаторы инкрементируются только вперед. Карма наверное.
А что делать с неоправданной детализацией, создающей на карте кашу? Я, например, давно имею зуб на автора вот этих паутинных разрывов в полигонах, обозначающих, видимо, муравьиные тропы: osm.org/go/0zPIkCLAK-
А ещё люди полагаются на «уникальность» всяких там GUID, MD5, SHA1 и прочих. Вероятность совпадения посчитать-то просто, но мало кто думает, что будет, если это всё-таки случится в какой-нибудь системе, к каким электронным «взрывам» это приведёт.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Неизбежность нодокалипсиса