Вас дезинформировали. С каждого второго произведенного Android устройства Microsoft собирает патентные отчисления за использование Android. С непокорными судится.
Под Андроид приложение без разрешения android.permission.READ_CONTACTS не сможет получить доступ к записной книжке. При установки приложения с такими правами пользователь получит уведомление.
Я думаю, тут может иметь место появление какого-нибудь форка Apache. Ну а может быть в какой-то версии в каком-то дистрибутиве поменяли строку идентификации.
Тема статистического обоснования не раскрыта. Если мы (как написано в русской википедии) рассматриваем σ как среднеквадратичное отклонение, то хотя бы понятно, что при нормальном распределении мы с p=0.95 должны попадать шесть сигм, и это легко доказать.
Что можно говорить о «вообще любом» распределении, да и ещё считая размах, я не понимаю. Есть какие-то доказательства на этот счет?
— Всегда нужно улучшать самое плохое звено. Всегда!
— Преждевременная оптимизация — это корень всех бед.
— Даже если UUID вас не устраивает, возьмите 256 битный UUID (+37 порядков).
— При изобретении велосипедов (распределенный непрерывный UUID) следует посчитать стоимость (цена ошибки*вероятность ошибки vs цена разработки). В крупных финансовых системах, скорее всего, не окупится. И на производительности и отказоустойчивости может сказаться.
— Твиттер имеет плохую архитектуру. Именно это объясняет его регулярные отказы и невозможность отобразить более 3200 последних твитов (эта проблема затрагивает на порядки больше людей). То есть разработчикам платили зарплату, пока они создавали свой UUID, а это время можно было потратить на что-то намного более важное.
— Троирование было модно в 70-х, когда вычислительные машины работали намного хуже. Сначала от него отказались в США, потом в СССР. Поверьте человеку, который писал софт для космической отрасли, троирование, может, и встречается где-то, но это экзотика.
— Про работников Google вообще не в тему. То, что BigTable переживает отказ оборудования никак не противоречит использованию UUID. Более того, подозреваю, что внутри AppEngine DataStore живет что-то типа UUID.
— Много хорошего софта имеет архитектуру с вероятностью коллизии. git, zfs, rsync и кучу другого.
— Мне кажется, в вас говорит максимализм (не обижайтесь, пожалуйста).
— Я думаю, мы флудим, если хотите продолжить дискуссию, пишите в личку. Обещаю ответить.
Ну, например, в платежных системах ошибки измеряются, как «деньги, которые пришлось вернуть потерпевшим на каждые $100».
Если мне не изменяет память, для систем типа MasterCard эти потери составляют 7 центов на каждые $100 (а может даже больше).
Как вы понимаете, эти потери несравнимо больше, чем те, которые может (потенциально) вызвать коллизия UUID.
Плюс, вы не берет в расчет то, что я говорю об аппаратных проблемах, которые не были замечены. Понятно, что сбой сервера легко заметить. А вот допустим у вас был искажен бит при генерации UUID. Или, допустим, не сработало условие проверки его на уникальность (потому что условный переход случайно заменился на безусловный).
То есть здесь вы пытаетесь поставить железные двери на одноэтажный дом со стеклянными окнами. Это просто экономически неэффективно.
P.S. Я допускаю, что могут появиться системы, в которых уникальность UUID будет, действительно критична. Но для таких систем, возможно, придется писать новые языки программирования (что-нибудь типа ada с проверкой хэша перед исполнением кода) и использовать очень специфическое железо.
>исследования
Ну, для простоты UUIDv4, пространство значений 2^122. Вероятность коллизии 1.9*10^-37.
Частота ошибок, например, в оперативной памяти (то есть в том числе и в загруженной версии вашей программы) 10^-10 — 10^-17 error/bit·h, то есть ~10^25 (на такт) для одного бита.
Дальше учтите, что программа у вас, скорее всего, длиннее одного бита и выполняются дольше одного такта. Ещё учтите, что ошибки есть на диске, на шине, в памяти и в процессоре.
Но даже в самом худшем случае вероятность коллизии на ~10 порядков меньше.
Во-первых, некоторые схемы включает ID хоста, что делает невозможной коллизию на разных хостах.
Во-вторых, в тех ситуациях, когда вероятность коллизии на десятки порядков меньше вероятности ошибок исполнения кода (я имею в виду ошибки процессора), то можно считать UUID строго уникальными.
В инженерную дискуссию сейчас вступать не готов, т.к. с телефона. Но если кратко: баг определенно затрагивает контроллер тачскрина и/или драйвер. Но к ванильному андроиду никакого отношения не имеет.
Что, правда?
Что касается WinRar и 7zip, то исторически сложилось так, что их называют архиваторами. Хотя это и не вполне точно.
Что можно говорить о «вообще любом» распределении, да и ещё считая размах, я не понимаю. Есть какие-то доказательства на этот счет?
— Всегда нужно улучшать самое плохое звено. Всегда!
— Преждевременная оптимизация — это корень всех бед.
— Даже если UUID вас не устраивает, возьмите 256 битный UUID (+37 порядков).
— При изобретении велосипедов (распределенный непрерывный UUID) следует посчитать стоимость (цена ошибки*вероятность ошибки vs цена разработки). В крупных финансовых системах, скорее всего, не окупится. И на производительности и отказоустойчивости может сказаться.
— Твиттер имеет плохую архитектуру. Именно это объясняет его регулярные отказы и невозможность отобразить более 3200 последних твитов (эта проблема затрагивает на порядки больше людей). То есть разработчикам платили зарплату, пока они создавали свой UUID, а это время можно было потратить на что-то намного более важное.
— Троирование было модно в 70-х, когда вычислительные машины работали намного хуже. Сначала от него отказались в США, потом в СССР. Поверьте человеку, который писал софт для космической отрасли, троирование, может, и встречается где-то, но это экзотика.
— Про работников Google вообще не в тему. То, что BigTable переживает отказ оборудования никак не противоречит использованию UUID. Более того, подозреваю, что внутри AppEngine DataStore живет что-то типа UUID.
— Много хорошего софта имеет архитектуру с вероятностью коллизии. git, zfs, rsync и кучу другого.
— Мне кажется, в вас говорит максимализм (не обижайтесь, пожалуйста).
— Я думаю, мы флудим, если хотите продолжить дискуссию, пишите в личку. Обещаю ответить.
Если мне не изменяет память, для систем типа MasterCard эти потери составляют 7 центов на каждые $100 (а может даже больше).
Как вы понимаете, эти потери несравнимо больше, чем те, которые может (потенциально) вызвать коллизия UUID.
Плюс, вы не берет в расчет то, что я говорю об аппаратных проблемах, которые не были замечены. Понятно, что сбой сервера легко заметить. А вот допустим у вас был искажен бит при генерации UUID. Или, допустим, не сработало условие проверки его на уникальность (потому что условный переход случайно заменился на безусловный).
То есть здесь вы пытаетесь поставить железные двери на одноэтажный дом со стеклянными окнами. Это просто экономически неэффективно.
P.S. Я допускаю, что могут появиться системы, в которых уникальность UUID будет, действительно критична. Но для таких систем, возможно, придется писать новые языки программирования (что-нибудь типа ada с проверкой хэша перед исполнением кода) и использовать очень специфическое железо.
Ну, для простоты UUIDv4, пространство значений 2^122. Вероятность коллизии 1.9*10^-37.
Частота ошибок, например, в оперативной памяти (то есть в том числе и в загруженной версии вашей программы) 10^-10 — 10^-17 error/bit·h, то есть ~10^25 (на такт) для одного бита.
Дальше учтите, что программа у вас, скорее всего, длиннее одного бита и выполняются дольше одного такта. Ещё учтите, что ошибки есть на диске, на шине, в памяти и в процессоре.
Но даже в самом худшем случае вероятность коллизии на ~10 порядков меньше.
Во-вторых, в тех ситуациях, когда вероятность коллизии на десятки порядков меньше вероятности ошибок исполнения кода (я имею в виду ошибки процессора), то можно считать UUID строго уникальными.
Ну и чтобы вы не сомневались, что к ОС баг не имеет отношения: на HTC этого бага нет.
Я боюсь, что его софтом не пофиксить. И, опять же, я не знаю, как часто это случается.
Ну что делать, Samsung. У них такое случается порой.
Баг известный. Случается не всегда и, возможно, не у всех.