Pull to refresh

Comments 40

UTC+4, т.е. московское время: проблема наступит в 3:14 UTC (несложно запомнить, да) 19 января.
Тут, скорее, это время запомнится благодаря другому слову, которое на ц заканчивается:)
UFO just landed and posted this here
Пока гром не грянет мужик не перекрестится.
Главное, что с хэпиэндом :)
Автор, хороший слог. Интересно а что делать через 25 лет в 7 утра тем кто будет лететь в самолете? :)
К тому времени перейдут на 64-битные парашуты
Громко читать «Канон молебный ко Господу нашему Иисусу Христу и Пречистой Богородице при разлучении души от тела» наизусть.
Планету собрали, пусть и с третьего раза.

Отличная фраза. :)
Звучит как дебаг 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. Особенно радует оптимизм авторов консольного файлового менеджера.
UFO just landed and posted this here
У меня тоже не всегда с первого раза собиралась.

emerge -vuDN world
Из хабры уже, я смотрю, давно, некоторые комментаторы, пытаются сделать 9fag.
Примерно так же республиканцы с демократами тянули до последнего вопрос договоренности по бюджету на фоне потенциального фискального обрыва. Проблемы парламентской неавторитарной среды.
А какой умник вообще додумался идентефикатор держать в int? По-моему, базовых знаний о базах должно хватать, чтобы понимать абсурдность таких действий.
Не судите строго, когда у вас 2^31 объектов, то на какие только оптимизации не идешь, чтобы сэкономить пару сотен Gb.
И на чем же? )))
Если рассматривать в «чистом» виде, то разница в 4 байта — это ровно 16 гиг экономии (на максимальных 2^32 рекордах). Экономить на строках надо.
Однако, если мне не изменяет память, то для 64-ехразрядных систем что int, что long, занимают одинаково — по 8 байт. Представить себе приличный НЕ 64-ехразрядный сервер сложно… Не знаю ни какая база, ни какая система, но предполагаю, что возможна ситуация, когда памяти выделено что на инт, что на лонг одинаково, однако из-за того, что объявлен был инт, банально стоит ограничитель индексов. Вот это засада!
Однако, если мне не изменяет память, то для 64-ехразрядных систем что int, что long, занимают одинаково — по 8 байт. Представить себе приличный НЕ 64-ехразрядный сервер сложно… Не знаю ни какая база, ни какая система, но предполагаю, что возможна ситуация, когда памяти выделено что на инт, что на лонг одинаково, однако из-за того, что объявлен был инт, банально стоит ограничитель индексов. Вот это засада!

Опасаюсь, что ваша память вам всё-таки изменяет.

Но вот зачем OSMу отрицательные идентификаторы, я и сам не понимаю.
Отрицательными числами многие программы — например, редакторы, — нумеруют объекты, которых нет в базе OpenStreetMap. Новые или временные. При обработке существующих данных они едва ли нужны: так, роутинговые библиотеки везде используют unsigned int.
Соглашусь с первым комментатором — экономия на спичках. 32-битные системы — тоже не оправдание — для идентификатора не нужно сложной математики, вроде умножения или деления. Ну будет 8 тактов вместо 5 для сравнения для ARM.

Подозреваю — обычный быдлокод непродуманность архитектуры.
Обработчики данных OSM стараются как можно больше загрузить в память. База сейчас приближается к половине терабайта. Поэтому те, кому это критично, экономят. Своп — не выход. Например, роутинговая библиотека OSRM хранит весь дорожный граф в памяти.

Хотя в большинстве случаев, конечно, причиной простая безалаберность: редко в реальной жизни встречаются такие большие числа, забываешь.
2147483647 помещается в 32-битное знаковое целое, а вот 2147483648 — уже нет
Чертовы французы, спустя 200 лет опять за свое!
Мда, ничему жизнь не учит… Спасибо за историю! И смех и грех, как говорится)
Сам использую OSM, поэтому для меня тема очень актуальна.
Только я что-то пропустил, последние добавленные точки похерили старые? В итоге все живы?
Интересно, а какой процент всех этих данных составляет мусор: неточные, устаревшие и просто бесполезные (в стиле «гараж Васька») данные?
Если Васёк нарисовал свой гараж значит не так уж это и бесполезно. Неточности уточняются, устаревшие удаляются. А идентификаторы инкрементируются только вперед. Карма наверное.
А что делать с неоправданной детализацией, создающей на карте кашу? Я, например, давно имею зуб на автора вот этих паутинных разрывов в полигонах, обозначающих, видимо, муравьиные тропы: osm.org/go/0zPIkCLAK-
Как обычно в таких случаях — связаться и обсудить. Показать как надо. Чутка надавить, потребовать треки в конце концов. Думаю компромисс будет найден.
А ещё люди полагаются на «уникальность» всяких там GUID, MD5, SHA1 и прочих. Вероятность совпадения посчитать-то просто, но мало кто думает, что будет, если это всё-таки случится в какой-нибудь системе, к каким электронным «взрывам» это приведёт.
Sign up to leave a comment.

Articles