К сожалению, это сложно осуществить просто потому, что копать придется довольно глубоко. Если считать, что радиус Земли 6370 км, а от Москвы до Ленинграда 650 км, то в средней точке глубина тоннеля будет порядка 8290 м (да, 8 с лишним километров). Поддерживать инфраструктуру там тоже сложновато будет.
P.S. Для тех, кто не читал Перельмана, напомню, что упомянутый проект — это попытка прокопать тоннель по хорде земного шара (в отличие от "обычного" пути по дуге).
У меня вопрос к знающим, такой алгоритм сокрытия пароля, это часть какого-то стандартного алгоритма шифрования (я имею ввиду сейчас применимого в программах, а не исторически) или его именно так, скорее всего, задумали разработчики?
Сервис отправляет оператору мобильной связи по реквизитам, указанным в договоре между ними, запрос о наличии или отсутствии в базах данных сведений об абоненте по указанному номеру.
Собственно, а почему сведений об абоненте не должно быть, если симка работает (т.е. зарегистрирована в сети)? Насколько я понимаю, в законе (как минимум, пока) ничего не говорится о проверке соответствия данным абонента в базе тем данным, которые пользователь вводит при регистрации (должны только проверять, есть ли в принципе номер в базе).
интернет вещей дает корпорациям возможность знать, чем живут их клиенты. А это, в свою очередь — огромные возможности для аналитики потребительского поведения
Что самое печальное, не только для аналитики.
P.S. Здесь должна быть минутка заботы от НЛО.
Это не очень хорошая идея, потому что разрешение не обязано быть 1080p или 1440p. (Вот лично мне, например, 720p до сих пор достаточно.) Поэтому лучше было бы что-то типа
resolution='1920x1080'
или еще лучшк
screen_width=1920,screen_height=1080
А всякие 1080p и т.п. — по сути, синтаксический сахар.
на дорогах можно ехать слегка под градусом, все превышают и перестраиваются через сплошную даже перед полицией.
Если верить Википедии, то на Кипре смертность в ДТП в 3,5 раза ниже, чем в России, если считать на 100000 человек населения, и в 6 раз ниже, если считать на 100000 автомобилей (если сравнивать Кипр с Украиной/Белоруссией, то примерно в 2,5 и 4 раза).
Может быть, это у нас что-то делают не так?
> А вот в comparison словообразование пошло другим путём. Исключительным.
Оно по факту из французского comparaison (кстати, в liaison тот же суффикс), а французкое -ison также от латинского -atio (франц. comparaison < лат. comparatio(nem), аналогично liaison < ligatio(nem))
Тут нужны не decimal, а int (по факту, числа с фиксированной точкой) — т.е. данные хранятся в самых мелких единицах (копейках, центах и т.п.). Так и об округлении не нужно думать, как правило
Тем не менее, у инфлюкса есть и преимущества (перед тем же кликхаусом, например) — опыт показал, что при хранении большого количества (несколько сотен на таблицу) метрик InfluxDB выигрывает благодаря двум основным причинам:
Пустые значения не хранятся. То есть, если одна метрика (например, данные по одному датчику) приходят условно 10 раз в секунду, а другая — раз в минуту, то во второй колонке в отсутствующие моменты времени ничего нет (даже NULL). Поэтому размер базы довольно сильно сокращается.
Не нужно создавать схему базы данных. Это особенно хорошо, когда данные приходят в формате <время> - <название метрики> - <значение метрики>, причем заранее может быть неизвестно, сколько всего метрик и как они называются (и какой у них тип данных). В Clickhouse в таких случаях нужно каждый раз создавать строку и заполнять все отсутствующие значения NULL-ами (а они там появились только сравнительно недавно), не говоря уже о том, что приходится лишний раз проходить по набору данных (хорошо еще, если они исторические, а не в реальном времени приходят), чтобы определить набор колонок и их типы.
> В моем случае данные имеют финансовую составляющую и обрабатывать их хотелось бы с высокой точностью.
«Уж сколько раз твердили миру», что для финансовых данных числа с плавающей точкой не годятся — а поскольку чего-то по типу decimal в influxdb нет, то лучшим выбором пока остаются целые числа.
P.S. Конечно, это не значит, что проблемы с точностью нет.
По-моему, здесь все-таки уместнее писать «микроконтроллер», а не «микропроцессор» (как-никак, у описываемых в статье штуковин и внешние интерфейсы есть, чего у процессоров нет). А в широком смысле к микропроцессорам и CPU относятся.
К сожалению, это сложно осуществить просто потому, что копать придется довольно глубоко. Если считать, что радиус Земли 6370 км, а от Москвы до Ленинграда 650 км, то в средней точке глубина тоннеля будет порядка 8290 м (да, 8 с лишним километров). Поддерживать инфраструктуру там тоже сложновато будет.
P.S. Для тех, кто не читал Перельмана, напомню, что упомянутый проект — это попытка прокопать тоннель по хорде земного шара (в отличие от "обычного" пути по дуге).
Этот "стандартный алгоритм" называется Security through obscurity (безопасность через неясность). Многие наивно полагают, что если криптоаналитик не знает алгоритм, то не сможет вскрыть и сам шифр.
Простейший пример: у кого-то есть база госномеров, но нет базы телефонных номеров, или наоборот.
Собственно, а почему сведений об абоненте не должно быть, если симка работает (т.е. зарегистрирована в сети)? Насколько я понимаю, в законе (как минимум, пока) ничего не говорится о проверке соответствия данным абонента в базе тем данным, которые пользователь вводит при регистрации (должны только проверять, есть ли в принципе номер в базе).
Они абсолютно правильно поступили в том плане, что надо время от времени выкидывать легаси.
Что самое печальное, не только для аналитики.
P.S. Здесь должна быть минутка заботы от НЛО.
Это не очень хорошая идея, потому что разрешение не обязано быть 1080p или 1440p. (Вот лично мне, например, 720p до сих пор достаточно.) Поэтому лучше было бы что-то типа
или еще лучшк
А всякие 1080p и т.п. — по сути, синтаксический сахар.
Jim Phisher :)
Ну видимо да, неправильно выразился — минусы получил за дело.
Ну вообще, Base64 сложно назвать шифрованием как таковым. А вот MD5, если солить пароли (со случайной солью), в принципе вполне подойдет.
Если верить Википедии, то на Кипре смертность в ДТП в 3,5 раза ниже, чем в России, если считать на 100000 человек населения, и в 6 раз ниже, если считать на 100000 автомобилей (если сравнивать Кипр с Украиной/Белоруссией, то примерно в 2,5 и 4 раза).
Может быть, это у нас что-то делают не так?
Видимо да
Оно по факту из французского comparaison (кстати, в liaison тот же суффикс), а французкое -ison также от латинского -atio (франц. comparaison < лат. comparatio(nem), аналогично liaison < ligatio(nem))
Тут нужны не decimal, а int (по факту, числа с фиксированной точкой) — т.е. данные хранятся в самых мелких единицах (копейках, центах и т.п.). Так и об округлении не нужно думать, как правило
Тем не менее, у инфлюкса есть и преимущества (перед тем же кликхаусом, например) — опыт показал, что при хранении большого количества (несколько сотен на таблицу) метрик InfluxDB выигрывает благодаря двум основным причинам:
<время> - <название метрики> - <значение метрики>, причем заранее может быть неизвестно, сколько всего метрик и как они называются (и какой у них тип данных). В Clickhouse в таких случаях нужно каждый раз создавать строку и заполнять все отсутствующие значения NULL-ами (а они там появились только сравнительно недавно), не говоря уже о том, что приходится лишний раз проходить по набору данных (хорошо еще, если они исторические, а не в реальном времени приходят), чтобы определить набор колонок и их типы.«Уж сколько раз твердили миру», что для финансовых данных числа с плавающей точкой не годятся — а поскольку чего-то по типу decimal в influxdb нет, то лучшим выбором пока остаются целые числа.
P.S. Конечно, это не значит, что проблемы с точностью нет.