Ну и правда, не совсем понятно, как будет выглядеть рынок, когда все пилят одно и то же и у всех одинаковая подписка на ChatGPT. Думаю, это решится естественным образом - будут очень дорогие и очень дешевые нейросети. Богатые будут богатеть, а бедные беднеть.
Мой персональный адочек с целочисленными преобразованиями:
off64_t lseek64(int fd, off64_t offset, int whence); lseek64(fd, -sizeof(envelope)-0x10, SEEK_END);
Работает на 64-битных системах и не работает на 32-битных. Понимаете, почему?
Я конечно же рукожоп и сам виноват. Но мое мнение - неявные преобразования между знаковыми и беззнаковыми надо запретить или хотя-бы ограничить. Человек должен явно все прописать и понимать, что он делает.
Нода - это ядро. Та сущность, которая исполняет один тред. Нумеруем все сервера, в каждом сервере нумеруем все процессоры, там нумеруем все ядра, получаем уникальный node_id. Все это нужно, чтобы избежать синхронизации при доступе к counter(node_id).
В целом, то на то и выходит, правда 256 бит перебор, UUID 128 бит, наверное вы его имели ввиду.
Надо было просто написать "Y = AES(secret_key, X) - отображение из 16 байт в 16 байт", но я решил выебнуться.
Кстати, я тут подумал, что в AES смысла особого нет.
Если честно да. И проблемы с ротацией ключей тоже есть. Более того, 128-битный UUID это слишком дофига. А рандом в UUID нехорошо для индексации в БД.
Короче, разумным выглядит использовать внутри системы 64-битный аналог UUID без рандома, типа Snowflake ID, а наружу уже выдавать что-то типа n || AES(secret_key[n], UUID)
В том-то и дело, что вы не понимаете и считаете меня несколько туповатым, либо попросту меряете по себе. Я больше ничего не буду писать, ибо уже и так написал половину комметариев. Было бы ради чего. Идеи описываются вполне тривиальные.
Конструкция node_id || timestamp || counter(node_id) || random - это аналог Snowflake ID. Вычисления ведутся на каждой ноде (моя нода - это ядро процессора) независимо и без необходимости синхронизации. counter(node_id) - это свой отдельный счетчик у каждой ноды.
На этот Snowflake ID навернули AES, чтобы скрыть внутреннюю структуру. Это отдельная идея. Это можно и не делать.
secret_key - один для всех и навсегда зафиксирован. Y = AES(secret_key, X) - это AES в режиме ECB, который отображает 256-битовую строку X в 256-битовую строку Y биективно (то есть, one-to-one) и не отличим вычислительно от случайно выбранного отображения.
Где вы увидели косяки с secret_key? secret_key задаем мы. Как вам вообще в голову пришло, что я допускаю различные secret_key? Тогда Y = AES(secret_key, X) не будет работать как биективное отображение и будут коллизии.
В целом мне уже больше нравится раздавать из выделенного микросервиса диапазоны UUID, как в Ticket Server с Pre-Generated Blocks. Это сильно проще в плане корректности, меньше нюансов, нет дрочева с timestamp.
Как минимум две идеи из индустрии я сегодня "изобрел" - аналог Snowflake ID и Ticket Server с Pre-Generated Blocks. То есть это нихера не тупые идеи, а вполне рабочие.
Окей, UUIDv7 тоже работает с вероятность 99.9...9%, а не 100%. Мне очень не нравится использовать вероятностный алгоритм там, где можно сделать детерминистический.
Второй абзац не совсем понял. Да, у меня все детерминистическое. Рандом там лишь для красоты и надежности, а не для защиты от повторов. Уникальность достигается за счет: 1) Уникальных и фиксированных node_id. 2) Достаточно точного timestamp. 3) Перезапуск ноды с обнулением counter(node_id) происходит с задержкой, за которую успеет измениться timestamp. 4) Переполнение counter(node_id) тоже учитывается.
Ключ AES навсегда фиксирован и одинаков для всех. Он для обфускации, чтобы UUID выглядел как рандом и не выдавал инфу.
В целом, что-то сложно напридумывал. Можно сделать тупо микросервис, который раздает нодам достаточно большие диапазоны UUID, чтобы не было слишком частых запросов, но достаточно маленькие, чтобы не потратить все UUID в обозримом будущем. Ну и AES для обфускации.
Просто вы в самом начале грозились уволить всех, кто причастен к микросервису по генерации UUID.
А потом предложили типа свои хорошие решения, которые так или иначе тоже являются микросервисом по генерации UUID.
Более того, сильно подозреваю, что сделать надежно (не тупо random) с нодами без априорных знаний не получится без того самого микросервиса в том или ином виде. Навскидку, в решениях, которые я вижу, он нужен: 1) Либо для раздачи точного времени. 2) Либо для раздачи уникальных node_id. 3) Либо для раздачи непересекающихся диапазонов UUID. Доказать строго не могу, но чуечка подсказывает.
Это хорошо, если у вас БД проверяет на уникальность UUID и сразу же выдает ошибку. И при этом можно без проблем сделать новый UUID и поворить попытку. Это надежная система, которая работает всегда.
Или если ваша БД генерирует UUID при вставке - тоже замечательно.
В обоих вышеописанных случаях ваша БД по сути и есть тот самый микросервис для генерации UUID. Просто называется иначе.
А вот что, если нет? Где-то есть системы, где любая централизованная БД станет бутылочным горлышком и поэтому уникальные UUID надо генерирововать полностью независимо и без какой-либо синхронизации. А что, если ошибка из-за коллизии UUID вылезет уже потом, когда уже поздно что-то менять?
В первую неделю новый техдир обнаружил, что в стартапе заведён специальный микросервис для генерации UUID. Все остальные команды были проинструктированы передавать запросы на генерацию «безопасных» UUID именно в этот сервис. Новый сотрудник начал разбираться и обнаружил, что сервис — это запросы в отдельную базу данных, которая и хранила все до этого выданные UUID.
Ну кстати хорошее надежное решение, которое работает всегда, а не с вероятностью 99.9...9%.
А если все же нужна высокая скорость и децентрализация, я бы сделал что-то типа UUID=AES(secret_key, node_id || timestamp || counter(node_id) || random). node_id задать так, чтобы на каждом сервере каждое ядро имело свой уникальный фиксированный node_id и к нему прилагалась своя копия counter(node_id), которая считает с нуля после загрузки. Тогда можно избежать синхронизации между ядрами.
Но тут потенциально есть проблема сбитых часов)) Еще нужно обработать теоретически возможное переполнение counter, добавив живительный sleep.
Да может и хер с ним с этим AGI. Уже текущее состояние дел приведет к фундаментальным изменениям в экономике. А технический прогресс даже и не думает останавливаться.
Не понимаю, о чем тут идет речь? Я только слышал про hardware-backed key attestation. Это серьезная хрень, которая требует аппаратной поддержки в SoC (TrustZone и аналоги) и серьезной инфраструктуры для attestation key provisioning. То есть не стоит ожидать, что в дешевом китаефоне это будет работать.
В любом случае все обходится фермой смартфонов. В худшем случае у мошенника лежит тупо нерутованный смартфон под управлением ИИ, который тапает по экрану и делает логин. Да, наверное это дорого. Но теоретически возможно.
Ну ок, т.е. речь уже идет не про то, что это невозможно, а про то, что массово сделать нерентабельно? Я почему-то думаю, что у специалистов это все схвачено. Тупо есть поставщики небитых-некрашеных проксей за приемлемый прайс.
И на кой черт мне каждый раз регать новый телеграм клиент с новым api_id? Я буду запускать настоящий Telegram с ломаного Android-телефона с подменой идентов. Причем на один телефон будет много независимых инстансов Telegram и каждый будет видеть свои иденты.
Тут из подозрительного только одно - что с одного IP слишком много запросов на логин одновременно. Но читаем выше. Ну и блин, настоящих людей, сидящих с VPN никто не отменял. То есть, некоторый уровень логинов с одного IP - это нормально.
Пресловутая Телега как-то же делает MITM и пропускает трафик через себя? И работает же. В чем принципиальная разница?
А кто мешает делать такой же фишинг и логиниться, например, в Telegram с backend? Ну то есть, если оригинальный клиент телеграм может залогиниться, то и мы можем, там в нем нет ничего секретного.
Можно как-то с этим бороться, лимитировать запросы на один IP, но это все тлен.
P.S. Не могу комментировать чаще, чем раз в час. Я статью почитал, ничего не понял. Нужны детали. С теоретической точки зрения никто не мешает у себя под кроватью запустить ферму с Android-мобилами с Telegram и делать все на 100% легитимно. Это конечно же overkill, думаю, все решается в разы проще и эффективнее.
Не только НДФЛ, но могут и НДС насчитать. Типа того, что человек, занимающийся незаконной предпринимательской деятельностью, формально работает по общей системе налогообложения. А всякие УСН имеют заявительный характер. Нет заявления - ты на общей схеме, и платишь НДФЛ+НДС. Уот так уот.
Да ладно, программист - это пока еще не самый хреновый вариант.
Думаю, уже совсем хреново всяким иллюстраторам от IT или там диджитал креаторам. Ты задрачивал условный фотошоп годами, а нейросеть делает сходу и в разы качественнее и сочнее.
Профессиональным переводчикам пора готовиться к машинным рилтайм переводам голоса. А текст уже и так давно переводят вполне качественно.
Кто-то возможно надеется, что всегда можно поработать руками. Но проблема в том, что экономике не нужно такое количество курьеров, плиточников, сантехников и онлифанщиц. Таксисты и дальнобойщики не в счет, им тоже надо готовиться на выход.
Не понимаю шквал критики и злорадства по поводу ИИ.
Это совершенно удивительная технология.
У меня в реверс-инжиниринге ИИ - это как помощник с огромным кругозором.
Подсказывает всякие заковыристые штуки, о которых я никогда не слышал.
В математике уже тоже начинаются серьезные подвижки.
То что оно еще не умеет в полный цикл разработки - ну так блядь радуйтесь, что дали пожить нормально.
Ну и правда, не совсем понятно, как будет выглядеть рынок, когда все пилят одно и то же и у всех одинаковая подписка на ChatGPT.
Думаю, это решится естественным образом - будут очень дорогие и очень дешевые нейросети.
Богатые будут богатеть, а бедные беднеть.
А че, статические анализаторы не умеют такое обнаруживать?
memcpy в буфер без должной проверки размера?
int32_t rpchdr[128 / sizeof(int32_t)];int32_t *buf;...buf = rpchdr;...if (oa->oa_length) {memcpy((caddr_t)buf, oa->oa_base, oa->oa_length);Мой персональный адочек с целочисленными преобразованиями:
off64_t lseek64(intfd, off64_toffset, intwhence);lseek64(fd, -sizeof(envelope)-0x10, SEEK_END);Работает на 64-битных системах и не работает на 32-битных.
Понимаете, почему?
Я конечно же рукожоп и сам виноват.
Но мое мнение - неявные преобразования между знаковыми и беззнаковыми надо запретить или хотя-бы ограничить. Человек должен явно все прописать и понимать, что он делает.
Нода - это ядро. Та сущность, которая исполняет один тред. Нумеруем все сервера, в каждом сервере нумеруем все процессоры, там нумеруем все ядра, получаем уникальный node_id. Все это нужно, чтобы избежать синхронизации при доступе к counter(node_id).
Надо было просто написать "Y = AES(secret_key, X) - отображение из 16 байт в 16 байт", но я решил выебнуться.
Если честно да. И проблемы с ротацией ключей тоже есть. Более того, 128-битный UUID это слишком дофига. А рандом в UUID нехорошо для индексации в БД.
Короче, разумным выглядит использовать внутри системы 64-битный аналог UUID без рандома, типа Snowflake ID, а наружу уже выдавать что-то типа
n || AES(secret_key[n], UUID)
Хеш конечно же нельзя, это необратимая функция.
В том-то и дело, что вы не понимаете и считаете меня несколько туповатым, либо попросту меряете по себе. Я больше ничего не буду писать, ибо уже и так написал половину комметариев. Было бы ради чего. Идеи описываются вполне тривиальные.
Конструкция node_id || timestamp || counter(node_id) || random - это аналог Snowflake ID.
Вычисления ведутся на каждой ноде (моя нода - это ядро процессора) независимо и без необходимости синхронизации.
counter(node_id) - это свой отдельный счетчик у каждой ноды.
На этот Snowflake ID навернули AES, чтобы скрыть внутреннюю структуру.
Это отдельная идея. Это можно и не делать.
secret_key - один для всех и навсегда зафиксирован.
Y = AES(secret_key, X) - это AES в режиме ECB, который отображает 256-битовую строку X в 256-битовую строку Y биективно (то есть, one-to-one) и не отличим вычислительно от случайно выбранного отображения.
Где вы увидели косяки с secret_key? secret_key задаем мы.
Как вам вообще в голову пришло, что я допускаю различные secret_key?
Тогда Y = AES(secret_key, X) не будет работать как биективное отображение и будут коллизии.
В целом мне уже больше нравится раздавать из выделенного микросервиса диапазоны UUID, как в Ticket Server с Pre-Generated Blocks. Это сильно проще в плане корректности, меньше нюансов, нет дрочева с timestamp.
Нет, мы походу нашли самого ограниченного кодера в треде.
Расширяйте сознание и не хамите незнакомым людям в интернете.
https://dilipkumar.medium.com/design-a-system-to-generate-a-unique-id-1517dc624975
https://en.wikipedia.org/wiki/Snowflake_ID
Как минимум две идеи из индустрии я сегодня "изобрел" - аналог Snowflake ID и Ticket Server с Pre-Generated Blocks. То есть это нихера не тупые идеи, а вполне рабочие.
Окей, UUIDv7 тоже работает с вероятность 99.9...9%, а не 100%.
Мне очень не нравится использовать вероятностный алгоритм там, где можно сделать детерминистический.
Второй абзац не совсем понял.
Да, у меня все детерминистическое. Рандом там лишь для красоты и надежности, а не для защиты от повторов.
Уникальность достигается за счет:
1) Уникальных и фиксированных node_id.
2) Достаточно точного timestamp.
3) Перезапуск ноды с обнулением counter(node_id) происходит с задержкой, за которую успеет измениться timestamp.
4) Переполнение counter(node_id) тоже учитывается.
Ключ AES навсегда фиксирован и одинаков для всех.
Он для обфускации, чтобы UUID выглядел как рандом и не выдавал инфу.
В целом, что-то сложно напридумывал.
Можно сделать тупо микросервис, который раздает нодам достаточно большие диапазоны UUID, чтобы не было слишком частых запросов, но достаточно маленькие, чтобы не потратить все UUID в обозримом будущем. Ну и AES для обфускации.
Да блин, нормально я читаю.
Просто вы в самом начале грозились уволить всех, кто причастен к микросервису по генерации UUID.
А потом предложили типа свои хорошие решения, которые так или иначе тоже являются микросервисом по генерации UUID.
Более того, сильно подозреваю, что сделать надежно (не тупо random) с нодами без априорных знаний не получится без того самого микросервиса в том или ином виде.
Навскидку, в решениях, которые я вижу, он нужен:
1) Либо для раздачи точного времени.
2) Либо для раздачи уникальных node_id.
3) Либо для раздачи непересекающихся диапазонов UUID.
Доказать строго не могу, но чуечка подсказывает.
Ой, опять тот самый микросервис?
Это хорошо, если у вас БД проверяет на уникальность UUID и сразу же выдает ошибку.
И при этом можно без проблем сделать новый UUID и поворить попытку.
Это надежная система, которая работает всегда.
Или если ваша БД генерирует UUID при вставке - тоже замечательно.
В обоих вышеописанных случаях ваша БД по сути и есть тот самый микросервис для генерации UUID. Просто называется иначе.
А вот что, если нет?
Где-то есть системы, где любая централизованная БД станет бутылочным горлышком и поэтому уникальные UUID надо генерирововать полностью независимо и без какой-либо синхронизации.
А что, если ошибка из-за коллизии UUID вылезет уже потом, когда уже поздно что-то менять?
Ну кстати хорошее надежное решение, которое работает всегда, а не с вероятностью 99.9...9%.
А если все же нужна высокая скорость и децентрализация, я бы сделал что-то типа UUID=AES(secret_key, node_id || timestamp || counter(node_id) || random).
node_id задать так, чтобы на каждом сервере каждое ядро имело свой уникальный фиксированный node_id и к нему прилагалась своя копия counter(node_id), которая считает с нуля после загрузки. Тогда можно избежать синхронизации между ядрами.
Но тут потенциально есть проблема сбитых часов)) Еще нужно обработать теоретически возможное переполнение counter, добавив живительный sleep.
Да может и хер с ним с этим AGI. Уже текущее состояние дел приведет к фундаментальным изменениям в экономике. А технический прогресс даже и не думает останавливаться.
Не понимаю, о чем тут идет речь?
Я только слышал про hardware-backed key attestation.
Это серьезная хрень, которая требует аппаратной поддержки в SoC (TrustZone и аналоги) и серьезной инфраструктуры для attestation key provisioning. То есть не стоит ожидать, что в дешевом китаефоне это будет работать.
В любом случае все обходится фермой смартфонов.
В худшем случае у мошенника лежит тупо нерутованный смартфон под управлением ИИ, который тапает по экрану и делает логин. Да, наверное это дорого. Но теоретически возможно.
Ну ок, т.е. речь уже идет не про то, что это невозможно, а про то, что массово сделать нерентабельно? Я почему-то думаю, что у специалистов это все схвачено. Тупо есть поставщики небитых-некрашеных проксей за приемлемый прайс.
И на кой черт мне каждый раз регать новый телеграм клиент с новым api_id? Я буду запускать настоящий Telegram с ломаного Android-телефона с подменой идентов. Причем на один телефон будет много независимых инстансов Telegram и каждый будет видеть свои иденты.
Тут из подозрительного только одно - что с одного IP слишком много запросов на логин одновременно. Но читаем выше. Ну и блин, настоящих людей, сидящих с VPN никто не отменял. То есть, некоторый уровень логинов с одного IP - это нормально.
Пресловутая Телега как-то же делает MITM и пропускает трафик через себя? И работает же. В чем принципиальная разница?
А кто мешает делать такой же фишинг и логиниться, например, в Telegram с backend?
Ну то есть, если оригинальный клиент телеграм может залогиниться, то и мы можем, там в нем нет ничего секретного.
Можно как-то с этим бороться, лимитировать запросы на один IP, но это все тлен.
P.S. Не могу комментировать чаще, чем раз в час.
Я статью почитал, ничего не понял. Нужны детали. С теоретической точки зрения никто не мешает у себя под кроватью запустить ферму с Android-мобилами с Telegram и делать все на 100% легитимно. Это конечно же overkill, думаю, все решается в разы проще и эффективнее.
Не только НДФЛ, но могут и НДС насчитать.
Типа того, что человек, занимающийся незаконной предпринимательской деятельностью, формально работает по общей системе налогообложения. А всякие УСН имеют заявительный характер. Нет заявления - ты на общей схеме, и платишь НДФЛ+НДС. Уот так уот.
https://www.advgazeta.ru/ag-expert/advices/fns-o-priznanii-deyatelnosti-fizlitsa-predprinimatelskoy-i-prinuditelnom-vzyskanii-nalogov/
Пора уже вводить organic coding.
Программисты из плоти и крови кушают вкусную здоровую пищу, ходят в тренажерку и пишут код руками по всем канонам.
За отдельную плату все программисты белые.
Реально пофиг. Бизнесу пофиг. Экономике пофиг.
А где не пофиг - поставят костыль, шоб работало.
Да ладно, программист - это пока еще не самый хреновый вариант.
Думаю, уже совсем хреново всяким иллюстраторам от IT или там диджитал креаторам.
Ты задрачивал условный фотошоп годами, а нейросеть делает сходу и в разы качественнее и сочнее.
Профессиональным переводчикам пора готовиться к машинным рилтайм переводам голоса. А текст уже и так давно переводят вполне качественно.
Кто-то возможно надеется, что всегда можно поработать руками. Но проблема в том, что экономике не нужно такое количество курьеров, плиточников, сантехников и онлифанщиц. Таксисты и дальнобойщики не в счет, им тоже надо готовиться на выход.