Следуя такой логике, все immutable структуры не могут иметь каких либо ограничений.
Требуется пояснительная бригада.
Так языки вроде C++ и Java и работают: не выполнился конструктор - нет объекта.
Не совсем. В этих языках доступны аллокации без выполнения конструктора.
Конечно, для этого нужно использовать api, не рекомендуемое к применению. Но всё же это api есть и им пользуются.
Тут можно спорить, и я не стану утверждать, что на 100% прав.
С таким же успехом можно доказать, что Си истинно immutable, ведь с точки зрения компилятора SSA представление таковым и является.
SSA иммутабельно только на уровне переменных. Записи по поинтеру (которые компилятор не распознал как переменные) вполне себе разрешены и используются. Так что, SSA не является «иммутабельным языком».
И всё же вы упускаете контекст. Я несколько раз повторил, что Хаскель мутабелен с точки зрения его же Garbage Collector. И привёл пример языка (вернее даже, рантайма), который настолько иммутабелен, что и GC это вполне себе использует.
Неужели где-то вводят налог на состояние? Афигеть!!! Это ведь единственный действительно нужный налог. Единственный налог с правильной механикой: возвращать замороженные на счетах богатеев деньги обратно в экономику.
Ну смотрите: если бы вы взяли просто сеть Фейстеля, то вы получили бы такую же надежность, но с гораздо более простым кодом. Ибо большинство манипуляций с поворотом Mi для профессионального криптографа - пустой звук. Он видит лишь, чтобы суммировали его с функцией от M[i^1] и ключа.
(M[(i+1)&1] - это M[i^1] . Что ещё раз намекает, что вы не очень понимаете, что делаете, и разводите сложность на пустом месте).
А вот то, что вы шныряете по массиву ключа в зависимости от содержимого M[i^1] - это хороший подарок криптографу в виде side channel по таймингу. Если уж программную реализацию AES на этом смогли подловить, то с вашей поделкой совсем проблем не будет.
Ну и главное: может быть я не внимательно прочитал, но я ни где не увидел, какой Cycles вы рекомендуете? Если это те 10000, что упоминаются в примере README, то, наверное, трудно оспорить то, что оно зашифрует. Но, блин, в любой день недели я вместо выполнения 10000 циклов вашего мудреного шифра возьму 32 цикла шифра Speck, который прост, как табуретка, и тщательно проанализирован десятком криптографов. (Да, сообщество отвергло Speck, т.к. не доверяет NSA, но на мой взгляд, это случай, когда паранойя возобладала над здравым смыслом.)
Банкротств среди подрядчиков Пентагона очень мало, и в основном среди мелких. Пока ChatGPT является лучшей универсальной моделью, деньги у OpenAI не кончатся.
В выкладках есть одно спорное предложение: что достичь низкого процента брака - это дорого. А из высокого процента брака и стоимости «переналадки» вытекает завышенная стоимость эксплуатации роботов.
Увы, но наблюдая за скоростью развития ИИ и робототехники, я бы не сделал ставку на то, что эта гипотеза останется верной долгое время.
И начальная настройка будет всё дешевле, и само-дообучение позволит роботу избегать повторного брака без «переналадки». Точно так же, как происходит адаптация у человека к своим косякам, она будет происходить и у робота.
Я не говорю, что так будет уже завтра. Но я уверен, что доживу до этих мрачных времён.
Глупый вопрос: а нет ли прямоугольных свитчей? Почему-то все свитчи квадратные. А ведь в «глубина» (или «высота»?) на самом деле не нужна такая же, как ширина. Я спокойно бы попадал по клавишам, у которых соотношение сторон было бы 3/4 или даже 2/3. За то на ту же глубину, что сейчас занимают 3 ряда, можно было воткнуть 4 ряда. И пальцам было бы меньше перемещаться по частым клавишам.
Пока что у Apple самые дешевые ARM компьютеры, если считать на единицу мощности. Конечно, памяти у младших моделей немного. Но любые другие ARM за ту же цену обычно медленнее.
Конечно, это я навскидку. Если вдруг я ошибся, не бейте, пожалуйста.
Тема квартернаной логики не раскрыта, как мне показалось.
Если реально запоминать факт ошибки и обрабатывать дальше запрос, то действительно можно выбрасывать ошибку пользователю, если она не отфильтровалась.
Правда в примере с пушем предиката на нижний уровень, механизм тернарной логики не был бы задействован: на уровнях выше нет выражений/фильтров, зависящих от упавшего приведения типа. Нужно было бы запомнить все таплы с прикрепленными к ним ошибками (по одной на каждый тапл), отсортировать их, поджойнить, и только после лимита смотреть, не попался ли результирующий тапл с прикрепленной ошибкой.
Самое противное, что у каждого тапла может быть своя ошибка, и её текст нужно вернуть пользователю. А значит, придётся материализовать все ошибки. Что несёт большой оверхед.
Второй противный момент, что фильтр перестаёт работать: нужно проталкивать наверх все таплы с ошибками.
Может быть, имеет смысл перехватывать ошибки? (CAST(val as int) RESCUE false) или (CAST(val as int) RESCUE SKIP)
Может я что-то не то говорю. Комент ведь генерила белковая нейросеть, а её возможности ограничены.
Я - не шпион. Но я хочу читать компьютерные новости и документацию. И проблема с двух сторон: часть новостных сайтов блокирует РКН, другая часть и новостных сайтов, и сайтов проектов сама себя блокирует для российских IP.
Можно было бы поставить кодекс сжатия в конце — однопоточно перед файловой системой сжимать странички. Но это бы разрушило параллелизм на месте записи на файловую систему.
Вот если бы это место распараллелить!
Кмк, можно было бы сжимать даже по несколько страниц WAL за раз.
При этом раскидывать эти пачки страниц по сжимающим воркерам. Дожидаться результата сжатия в правильном порядке и уже результат сбрасывать на диск.
И вообще тогда в памяти (в буферах WAL) можно было бы не возиться с хедерами страниц, как мне кажется. И не привязываться к границам страниц. Заголовки с чексуммами можно было бы добавлять уже к сжатым блобам, содержащим много записей.
Но это усложняет переиспользование WAL файлов: PostgreSQL сейчас выделяет место под файлы один раз, а потом их просто переименовывает и переписывает. Отвязавшись от границ страниц, будет проблематично вписываться в границы файлов.
Ну и плюс ещё обработка Switch WAL: специального хака, чтобы перейти по скорее к следующему файлу. Он используется для того, например, чтобы текущий файл можно было поскорее отправить в архив. Что очень удобно при создании резервной копии. Сейчас Switch WAL - это просто запись, сигнализирующая, что до конца текущего файла WAL не будет других записей. Если же мы начнём сжимать записи, то Switch WAL станет несколько более высокоуровневой штукой. Писатель WAL должен будет понимать, где произошёл Switch WAL, и самостоятельно переходить к следующему файлу.
Возвращаясь к теме переиспользования файлов, имя файла WAL перестанет быть таким простым. Сейчас PostgreSQL точно знает, какие LSN попадут в файл, и исходя из этого именует файл. Если же мы контейнеризируем записи, то определить заранее, с какого LSN начётся файл, очень трудно. А значит, переименовывать придётся непосредственно перед началом записи в файл.
Либо отказаться от переиспользования файлов, и писать каждый раз новые. Тогда можно и отвязаться от фиксированного размера файла (правда, у этого есть свои минусы). Скорее всего, сама запись станет медленнее: теперь кроме записи данных придётся обновлять и метаданные (о выделении места и размере). Т.е. обращений к диску на запись станет в 2-3 раза больше на каждой синхронизации. А синхронизация нужна в конце каждого коммита. Но может быть умелым пайплайнингом эту проблему можно нивелировать? Не знаю, если честно. Таких замеров не делал.
Простите за поток сознания. Долго копил, хотелось выговориться.
btw, Tarantool делает какую-то компрессию WAL именно по множеству записей. Но детали я не знаю, и в код не вчитывался.
PS. Блин, насколько бы проще было бы экспериментировать, будь в PostgreSQL потоки (threads).
Требуется пояснительная бригада.
Не совсем. В этих языках доступны аллокации без выполнения конструктора.
Конечно, для этого нужно использовать api, не рекомендуемое к применению. Но всё же это api есть и им пользуются.
Тут можно спорить, и я не стану утверждать, что на 100% прав.
SSA иммутабельно только на уровне переменных. Записи по поинтеру (которые компилятор не распознал как переменные) вполне себе разрешены и используются. Так что, SSA не является «иммутабельным языком».
И всё же вы упускаете контекст. Я несколько раз повторил, что Хаскель мутабелен с точки зрения его же Garbage Collector. И привёл пример языка (вернее даже, рантайма), который настолько иммутабелен, что и GC это вполне себе использует.
Странный вы человек. Вам говорят «ollama так работает плохо, vllm - хорошо». А вы в ответ «нет, vllm будет плохо».
Вам рассказывают, что попробовали, вы же отрицаете, не попробовав.
Странно это.
Предложат вернуть возможность оплаты Эппл Стор, закрытую а Апреле?
Неужели где-то вводят налог на состояние? Афигеть!!! Это ведь единственный действительно нужный налог. Единственный налог с правильной механикой: возвращать замороженные на счетах богатеев деньги обратно в экономику.
Простите за глупый вопрос, я не местный…
А если создавать типы и методы под кратковременные нужды, то ненужные уже типы и методы рантайм когда-нибудь соберёт? Или это будет утечкой?
Ну смотрите: если бы вы взяли просто сеть Фейстеля, то вы получили бы такую же надежность, но с гораздо более простым кодом. Ибо большинство манипуляций с поворотом Mi для профессионального криптографа - пустой звук. Он видит лишь, чтобы суммировали его с функцией от M[i^1] и ключа.
(M[(i+1)&1] - это M[i^1] . Что ещё раз намекает, что вы не очень понимаете, что делаете, и разводите сложность на пустом месте).
А вот то, что вы шныряете по массиву ключа в зависимости от содержимого M[i^1] - это хороший подарок криптографу в виде side channel по таймингу. Если уж программную реализацию AES на этом смогли подловить, то с вашей поделкой совсем проблем не будет.
Ну и главное: может быть я не внимательно прочитал, но я ни где не увидел, какой Cycles вы рекомендуете? Если это те 10000, что упоминаются в примере README, то, наверное, трудно оспорить то, что оно зашифрует. Но, блин, в любой день недели я вместо выполнения 10000 циклов вашего мудреного шифра возьму 32 цикла шифра Speck, который прост, как табуретка, и тщательно проанализирован десятком криптографов. (Да, сообщество отвергло Speck, т.к. не доверяет NSA, но на мой взгляд, это случай, когда паранойя возобладала над здравым смыслом.)
Простите, тоже увлекаюсь фантазированием на тему криптографии. Потому знаю некоторые распространенные приемы и техники.
И ваш код выглядит как попытка «security through obscurity». Минимум применения проверенных практик, максимум «операций ради операций».
Ну или вы не смогли объяснить, что как и для чего вы сделали. А без вашего объяснения трудно это понять со стороны.
Присоединюсь: рефакторинг без интеграционных тестов - это путь «безумства храбрых».
Программа ведь как-то работала, ею пользовались. Значит у неё было видимое снаружи поведение.
Вот это видимое поведение и нужно было зафиксировать в тестах. Хотя бы основные моменты.
Впрочем, мне всегда везло: я ввязывался только в проекты с существующими тестами. И тогда рефакторил «без страха и упрёка».
Ну, военным не код писать нужно. Я потому и вставил слово «универсальная».
Банкротств среди подрядчиков Пентагона очень мало, и в основном среди мелких. Пока ChatGPT является лучшей универсальной моделью, деньги у OpenAI не кончатся.
Простите, но Пентагон уже
зависит отявляется заказчиком OpenAI. Так что, деньги у OpenAI не закончатся.В выкладках есть одно спорное предложение: что достичь низкого процента брака - это дорого. А из высокого процента брака и стоимости «переналадки» вытекает завышенная стоимость эксплуатации роботов.
Увы, но наблюдая за скоростью развития ИИ и робототехники, я бы не сделал ставку на то, что эта гипотеза останется верной долгое время.
И начальная настройка будет всё дешевле, и само-дообучение позволит роботу избегать повторного брака без «переналадки». Точно так же, как происходит адаптация у человека к своим косякам, она будет происходить и у робота.
Я не говорю, что так будет уже завтра. Но я уверен, что доживу до этих мрачных времён.
Молодость не прощает. Она записывает в долговую книжечку. А зрелость и старость по этой книжечке будет взыскивать.
Ну вот мне кажется, что какой-нибудь 18x12 был бы идеален (18 - ширина, тут уж пальцы у меня уже не станут). С colstag было бы шикарно.
Тяжело сделать кустомный вариант кейкапа?
Глупый вопрос: а нет ли прямоугольных свитчей? Почему-то все свитчи квадратные. А ведь в «глубина» (или «высота»?) на самом деле не нужна такая же, как ширина. Я спокойно бы попадал по клавишам, у которых соотношение сторон было бы 3/4 или даже 2/3. За то на ту же глубину, что сейчас занимают 3 ряда, можно было воткнуть 4 ряда. И пальцам было бы меньше перемещаться по частым клавишам.
Пока что у Apple самые дешевые ARM компьютеры, если считать на единицу мощности. Конечно, памяти у младших моделей немного. Но любые другие ARM за ту же цену обычно медленнее.
Конечно, это я навскидку. Если вдруг я ошибся, не бейте, пожалуйста.
Да, значит я не совсем корректно понял.
Тема квартернаной логики не раскрыта, как мне показалось.
Если реально запоминать факт ошибки и обрабатывать дальше запрос, то действительно можно выбрасывать ошибку пользователю, если она не отфильтровалась.
Правда в примере с пушем предиката на нижний уровень, механизм тернарной логики не был бы задействован: на уровнях выше нет выражений/фильтров, зависящих от упавшего приведения типа. Нужно было бы запомнить все таплы с прикрепленными к ним ошибками (по одной на каждый тапл), отсортировать их, поджойнить, и только после лимита смотреть, не попался ли результирующий тапл с прикрепленной ошибкой.
Самое противное, что у каждого тапла может быть своя ошибка, и её текст нужно вернуть пользователю. А значит, придётся материализовать все ошибки. Что несёт большой оверхед.
Второй противный момент, что фильтр перестаёт работать: нужно проталкивать наверх все таплы с ошибками.
Может быть, имеет смысл перехватывать ошибки?
(CAST(val as int) RESCUE false)или(CAST(val as int) RESCUE SKIP)Может я что-то не то говорю. Комент ведь генерила белковая нейросеть, а её возможности ограничены.
Я - не шпион. Но я хочу читать компьютерные новости и документацию. И проблема с двух сторон: часть новостных сайтов блокирует РКН, другая часть и новостных сайтов, и сайтов проектов сама себя блокирует для российских IP.
Впрочем, полагаю это был сарказм с вашей стороны.
Вот если бы это место распараллелить!
Кмк, можно было бы сжимать даже по несколько страниц WAL за раз.
При этом раскидывать эти пачки страниц по сжимающим воркерам. Дожидаться результата сжатия в правильном порядке и уже результат сбрасывать на диск.
И вообще тогда в памяти (в буферах WAL) можно было бы не возиться с хедерами страниц, как мне кажется. И не привязываться к границам страниц. Заголовки с чексуммами можно было бы добавлять уже к сжатым блобам, содержащим много записей.
Но это усложняет переиспользование WAL файлов: PostgreSQL сейчас выделяет место под файлы один раз, а потом их просто переименовывает и переписывает. Отвязавшись от границ страниц, будет проблематично вписываться в границы файлов.
Ну и плюс ещё обработка Switch WAL: специального хака, чтобы перейти по скорее к следующему файлу. Он используется для того, например, чтобы текущий файл можно было поскорее отправить в архив. Что очень удобно при создании резервной копии. Сейчас Switch WAL - это просто запись, сигнализирующая, что до конца текущего файла WAL не будет других записей. Если же мы начнём сжимать записи, то Switch WAL станет несколько более высокоуровневой штукой. Писатель WAL должен будет понимать, где произошёл Switch WAL, и самостоятельно переходить к следующему файлу.
Возвращаясь к теме переиспользования файлов, имя файла WAL перестанет быть таким простым. Сейчас PostgreSQL точно знает, какие LSN попадут в файл, и исходя из этого именует файл. Если же мы контейнеризируем записи, то определить заранее, с какого LSN начётся файл, очень трудно. А значит, переименовывать придётся непосредственно перед началом записи в файл.
Либо отказаться от переиспользования файлов, и писать каждый раз новые. Тогда можно и отвязаться от фиксированного размера файла (правда, у этого есть свои минусы). Скорее всего, сама запись станет медленнее: теперь кроме записи данных придётся обновлять и метаданные (о выделении места и размере). Т.е. обращений к диску на запись станет в 2-3 раза больше на каждой синхронизации. А синхронизация нужна в конце каждого коммита. Но может быть умелым пайплайнингом эту проблему можно нивелировать? Не знаю, если честно. Таких замеров не делал.
Простите за поток сознания. Долго копил, хотелось выговориться.
btw, Tarantool делает какую-то компрессию WAL именно по множеству записей. Но детали я не знаю, и в код не вчитывался.
PS. Блин, насколько бы проще было бы экспериментировать, будь в PostgreSQL потоки (threads).