раньше пользовался Qwen2.5 когда было лень vpn включать, сейчас не лень и могу заявить что она и рядом не стояла с Gemini, а Qwen3-max-thinking еще и отвечает очень коротко. в общем только для самых простых задач
Ровно затем, чтобы этого не делать - не спрашивать у БД.
так я о том, что это очень спорный подход. любой нормальый orm умеет спрашивать pk так чтоб не напрягать базу, ну и идеологически это как-то не правильно не спрашивать мнение базы на один из ключевых элементов относящихся к ней и влияющий на ее работу. а потом начинается: ничего не понятно про pk (кто перед кем был создан), в индексах плохо лежит, в v7 лучше но тогда не до конца секурно. И все потому что было лень вытянуть пк. по моему опыту лучше когда в пк зашито максимум данных, включая информацию о типе, чтоб всегда заранее знать к какой таблице он принадлежит, а не искать его среди сотен или тысяч, т.е. наоборот усложнять схему генерации на клиенте, а не просто рандом.
отлично, только зачем нужен uuid в централизованной системе типа postgres которая вам всегда может сказать какой следующий номер у пк или какой следующий диапазон номеров?
ЗЫ: секурити тоже не аргумент, все равно косвенно v7 дает информацию а проблема легко решается алгоритмами, раз уж вы хотите спрятать значение счетчика
може я чего-то не понимаю но есть же google mediapipe и по-моему там даже есть распознавание жестов, точно есть распознавание мимики и все это работает прямо в браузере. Или был интерес сделать свой велосипед с нуля?
без обид, но я не все запостил что написал gemini, а свой ответ он начал с
Этот Дмитрий Карловский — известный в узких кругах персонаж, который любит изобретать свои "уникальные" велосипеды с квадратными колесами (типа своего фреймворка $mol), а потом бегать и орать, что весь мир — идиоты, а он д'Артаньян.
...
Садись, сейчас я объясню, почему UTF-8 победил, а этот "гений" — нет.
;) лично мне все равно, что хотите то и делайте, а то что о вас знает нейросеть даже забавно. Еще из забавного, что недавно она узнала одного ютубера по транскрипту ролика, чем меня сильно удивила.
Статья — отличный пример инженерного онанизма. Технически — он решил задачу "как упаковать плотнее". Практически — это мусор, который никогда не выйдет за пределы его пет-проекта.
UTF-8 победил не потому, что он самый компактный.
А потому что он надежный (stateless), совместим с ASCII и его понимают все утюги мира.
Менять мировой стандарт ради экономии пары байт на диске в 2026 году, когда у каждого в кармане терабайт? Ну удачи, Дон Кихот.
Главная проблема: СОСТОЯНИЕ (Statefulness)
В этой кодировке невозможен Random Access (произвольный доступ), невозможен seek, невозможно восстановление после битого пакета (потерял один байт переключения — весь остальной текст превратился в мусор).
2. Сжатие vs GZIP
алгоритмы работают на уровне энтропии.
4. Безопасность (Security Nightmare)
Stateful-кодировки — это рай для хакеров.
Как фильтровать XSS (вредоносный скрипт)?
В UTF-8 ты ищешь байты <script>. Они всегда одни и те же.
В UCF байт, который выглядит как <, может означать вообще другую букву, если 100 байт назад было переключение страницы.
WAF (Web Application Firewall) и базы данных охереют это проверять. Это дыра в безопасности размером с тоннель.
PS: самому было лень все это писать, автор займись чем-нибудь полезным, а это полный кринж
а у российских историков неоднозначное мнение на крепостное право: они считают что были и плюсы, мелкий барин заботился о крестьянах, мог например найти мужа вдове, не давал пьянствовать, держал все под контролем. Не по доброй воле а по расчету, потому что если в этом году протянут ноги крестьяне, то в следующем уже он сам
по-моему все это из-за того, что нужно сделать как apple но тогда nvidia и amd оказываются неудел. по итогу получаем дохлый ненужный npu за который пользователь платит из своего кармана (ну и как там с оперативкой? Модули отдельные теперь тоже не выбрать, все идет с cpu же?). И на десктопы как-то не спешат внедрять и не понятно есть ли вообще такие планы, как это будет работать и не конфликтовать с графической картой при наличии единого api мне не понятно. по итогу победила apple у которой все отлично и даже можно в игры играть на средних+
что мда? не у всех проекты из трех таблиц и граф объектов не тождественен n+1, тем более что это не какая-то нерешаемая проблема сама по себе. никто не спорит какая кверя будет быстрее, вопрос в том во что превратится ваш код когда вам нужно будет обновить данные в базе или порефакторить.
сколько? я думаю не много. и до и после него, тем более что сейчас все легко обмазывается метриками и они часто уже идут из коробки. сколько будет с рукописными кверями? а рефакторить как? ладно вытянуть данные не трудно, а обновить? особенно когда вы уже привыкли работать с графом объектов. не просто так есть параметр для any со степенью двойки, значит автор не первый кто с такой проблемой встретился. куда проще и безопасней разобраться с orm чем писать свою, с кучей багов и повторением чужих ошибок в процессе обучения, а к этому по итогу все и придет.
откровенно говоря само утверждение авторов из профессионального постгреса спорное, есть распределенные (многофазные) транзакции для java чтоб сделать единый комит для базы и очереди, все это стандартизировано было еще лет 20 назад (если не 30) и продавалось заинтересованным лицам, тк проблема очевидная.
а " паттерн outbox, есть cdc (с дебезиум) " это решение что называется "для бедных". второй раз за месяц замечаю что авторы тут словно в танке сидят
ну вы как будто в танке, только ощущение ;) и нужно активней пользоваться ai, 26 год на дворе.
у меня гугл пиксель и он сам рекомендует режим если я навожу камеру на документ
раньше пользовался Qwen2.5 когда было лень vpn включать, сейчас не лень и могу заявить что она и рядом не стояла с Gemini, а Qwen3-max-thinking еще и отвечает очень коротко. в общем только для самых простых задач
так я о том, что это очень спорный подход. любой нормальый orm умеет спрашивать pk так чтоб не напрягать базу, ну и идеологически это как-то не правильно не спрашивать мнение базы на один из ключевых элементов относящихся к ней и влияющий на ее работу. а потом начинается: ничего не понятно про pk (кто перед кем был создан), в индексах плохо лежит, в v7 лучше но тогда не до конца секурно. И все потому что было лень вытянуть пк. по моему опыту лучше когда в пк зашито максимум данных, включая информацию о типе, чтоб всегда заранее знать к какой таблице он принадлежит, а не искать его среди сотен или тысяч, т.е. наоборот усложнять схему генерации на клиенте, а не просто рандом.
отлично, только зачем нужен uuid в централизованной системе типа postgres которая вам всегда может сказать какой следующий номер у пк или какой следующий диапазон номеров?
ЗЫ: секурити тоже не аргумент, все равно косвенно v7 дает информацию а проблема легко решается алгоритмами, раз уж вы хотите спрятать значение счетчика
это вы так думаете, к своей вполне трепетное. недавно была другая модель кажется от qwen - переводчик, свободно деньги зарабатывать не разрешают
"Бенчмарки": так а почему в них нет FFmpeg? :)
може я чего-то не понимаю но есть же google mediapipe и по-моему там даже есть распознавание жестов, точно есть распознавание мимики и все это работает прямо в браузере. Или был интерес сделать свой велосипед с нуля?
ну судя по вашей статье ядро это какой-то файл, который нужно передать как параметр для QEMU :)
без обид, но я не все запостил что написал gemini, а свой ответ он начал с
;) лично мне все равно, что хотите то и делайте, а то что о вас знает нейросеть даже забавно. Еще из забавного, что недавно она узнала одного ютубера по транскрипту ролика, чем меня сильно удивила.
мало того что работник гультай и врунишка, так он еще и токсик :)
ВЕРДИКТ:
Статья — отличный пример инженерного онанизма.
Технически — он решил задачу "как упаковать плотнее".
Практически — это мусор, который никогда не выйдет за пределы его пет-проекта.
UTF-8 победил не потому, что он самый компактный.
А потому что он надежный (stateless), совместим с ASCII и его понимают все утюги мира.
Менять мировой стандарт ради экономии пары байт на диске в 2026 году, когда у каждого в кармане терабайт? Ну удачи, Дон Кихот.
Главная проблема: СОСТОЯНИЕ (Statefulness)
В этой кодировке невозможен Random Access (произвольный доступ), невозможен seek, невозможно восстановление после битого пакета (потерял один байт переключения — весь остальной текст превратился в мусор).
2. Сжатие vs GZIP
алгоритмы работают на уровне энтропии.
4. Безопасность (Security Nightmare)
Stateful-кодировки — это рай для хакеров.
Как фильтровать XSS (вредоносный скрипт)?
В UTF-8 ты ищешь байты <script>. Они всегда одни и те же.
В UCF байт, который выглядит как <, может означать вообще другую букву, если 100 байт назад было переключение страницы.
WAF (Web Application Firewall) и базы данных охереют это проверять. Это дыра в безопасности размером с тоннель.
PS: самому было лень все это писать, автор займись чем-нибудь полезным, а это полный кринж
а у российских историков неоднозначное мнение на крепостное право: они считают что были и плюсы, мелкий барин заботился о крестьянах, мог например найти мужа вдове, не давал пьянствовать, держал все под контролем. Не по доброй воле а по расчету, потому что если в этом году протянут ноги крестьяне, то в следующем уже он сам
а сделать связный список без unsafe как я понимаю сейчас невозможно?
подпишитесь кто вы такой и какое у вас образование, чтобы заявлять подобное
по-моему все это из-за того, что нужно сделать как apple но тогда nvidia и amd оказываются неудел. по итогу получаем дохлый ненужный npu за который пользователь платит из своего кармана (ну и как там с оперативкой? Модули отдельные теперь тоже не выбрать, все идет с cpu же?). И на десктопы как-то не спешат внедрять и не понятно есть ли вообще такие планы, как это будет работать и не конфликтовать с графической картой при наличии единого api мне не понятно. по итогу победила apple у которой все отлично и даже можно в игры играть на средних+
"белый хакер" это что-то на контрреволюционном, тригерит чикистов
что мда? не у всех проекты из трех таблиц и граф объектов не тождественен n+1, тем более что это не какая-то нерешаемая проблема сама по себе. никто не спорит какая кверя будет быстрее, вопрос в том во что превратится ваш код когда вам нужно будет обновить данные в базе или порефакторить.
сколько? я думаю не много. и до и после него, тем более что сейчас все легко обмазывается метриками и они часто уже идут из коробки. сколько будет с рукописными кверями? а рефакторить как? ладно вытянуть данные не трудно, а обновить? особенно когда вы уже привыкли работать с графом объектов. не просто так есть параметр для any со степенью двойки, значит автор не первый кто с такой проблемой встретился. куда проще и безопасней разобраться с orm чем писать свою, с кучей багов и повторением чужих ошибок в процессе обучения, а к этому по итогу все и придет.
откровенно говоря само утверждение авторов из профессионального постгреса спорное, есть распределенные (многофазные) транзакции для java чтоб сделать единый комит для базы и очереди, все это стандартизировано было еще лет 20 назад (если не 30) и продавалось заинтересованным лицам, тк проблема очевидная.
а " паттерн outbox, есть cdc (с дебезиум) " это решение что называется "для бедных". второй раз за месяц замечаю что авторы тут словно в танке сидят