Мне с этим надо работать, а не разбираться в подробностях. Конкретно, мне надо сделать так, чтобы columnstore не считало пустую строку NULL, tmux мне нужен для не валящейся сборки в облаке, а он не работает, и сборка валится. У меня согласование изменений в 150 файлах исходников на C++, а я с tmux должен возиться.
ПМСМ, программист, не желающий бороться с энтропией.... как бы это так поаккуратнее выразиться, чтобы никого не обидеть.... давно перерос уровень решаемых им задач :)
Я тщательно стараюсь сохранять фокус. Это очень тяжело даже без отвлечения на непонятно, что, непонятно, где. С отвлечением на исправление ошибок в связке GCP/WSL2+Ubuntu+MariaDB+ColumnStore+tmux+ядро-линукса я никогда не завершу порученное мне исправление всего лишь columnstore.
Это не совсем шутка. Ну, неужели не нашлось программиста попроще, кому ковыряние в потрохах билдсистемы и тмукса было бы в кайф? А вы бы им могли, к примеру, поруководить.
С нетипизированным языком с функциями высшего порядка с временем проверки изменений от минут и дольше - это не нормальный полёт.
Я подозреваю, вы внутрь nix не залезали.
Типичная цитата живущих с nix: "Кстати, тут никто не сталкивался с проблемой что cabal прекращал находить пакеты в nix-shell после обновления до самых последних nixpkgs?"
Бывало что и залезал. Для хаскелла есть таки haskell.nix и он достаточно хорош, хотя и там разные гитики есть, я тут недавно имплементил добавление произвольных зависимостией.
Все равно лучше пока ничего не придумали, правильный подход - пинить версии nixpkgs, home-manager, методом собрались, вылили, проверили, не работает - откатились. И да, у меня везде per project версии запинены, вышанаписаное - про "общую систему" (а так - nixpkgs/haskell.nix/naersk прибитые в flake.lock на попроектной основе)
1) можно код менять на данные. Мой любимый пример вот тут: https://github.com/MariaDB/server/tree/10.9/strings Это, практически, finite state transducers, выраженные в коде. А можно было бы выразить их через данные и вовсе в базе данных хранить.
Но для этого надо разбираться во многом, в тех же FST, и, вообще, знать систему от и до.
Что подводит нас к
2) можно использовать всё по минимуму и тогда, вместо подтягивания бесконечных пакетов, можно будет иметь ровно то, что требуется для системы и не более того.
да, с типизированым языком было бы лучле, но имеем что имеем.
Все равно тут два разных независимых кейса - 1) dev shell для проекта (с нужной версией компилятора, линтера, форматтера итд - и либами, отлично решает проблему с сищными/плюсовыми либами и их версиями, у каждого проекта/ревизии свой зоопарк. 2 кейс - система (+ дотфайлы) в том числе для некомпьютерных ни разу членов семьи. Мне _очень_ нравится что оно не ломается в процессе обновлений, оно легко отстраиваетяся на новом железе, если старый тазик помер, а так же что я могу подготовить все апдейты у себя, и разом их вылить за 10-15 минут.
Какую вы мне альтернативу предлагаете? Убунту?
PS Это если есть желание подискутировать, если нет, то ну его и замнем тему ;)
Девушки любят Mac, сын Windows. Мне бы убунту, но я в WSL2 застрял.
А про dev shell я уже высказался.
И повторю другую мою мысль: пакеты в ПО это то, что в американском законотворчестве называется riders. Соответственно, управление пакетами это управление "законами", многие из которых друг другу противоречат (пакеты не могут быть применены одновременно - две версии поддержки SSL, сколько же я с этим боролся) или содержат ненужное прямо тут и сейчас (OpenFST содержит WFST).
"nix, лучше которого ничего не придумали" это способ хоть как-то лавировать в этом лабиринте. Вместо исправления проблемы он предлагает паллиатив - "вот тут гвоздиками прибьём вот это вот, вы даже не заметите".
Что-нибудь в их бэгтрекере про это сказано?
Reply
Не знаю, что про это сказано и сказано ли.
Мне с этим надо работать, а не разбираться в подробностях. Конкретно, мне надо сделать так, чтобы columnstore не считало пустую строку NULL, tmux мне нужен для не валящейся сборки в облаке, а он не работает, и сборка валится. У меня согласование изменений в 150 файлах исходников на C++, а я с tmux должен возиться.
Reply
Reply
А так, я собираюсь завтра создать машинку с ubuntu 20. Ибо! И если там tmux работать не будет, то вообще на rockylinux перейду. Или вовсе на SUSE.
Reply
Reply
Я тщательно стараюсь сохранять фокус. Это очень тяжело даже без отвлечения на непонятно, что, непонятно, где. С отвлечением на исправление ошибок в связке GCP/WSL2+Ubuntu+MariaDB+ColumnStore+tmux+ядро-линукса я никогда не завершу порученное мне исправление всего лишь columnstore.
Reply
Reply
Я всё лелею надежду упростить весь этот невыносимый ужас.
Буду завтра читать код K.
Reply
Reply
Не заставите.
Поработал я с nix, я лучше вообще работать не буду, чем с ним. Незатыкаемый фонтан поводов разочарований.
Reply
У меня 5 лет нормального полета, и потихоньку двигаем в массы
Reply
Я подозреваю, вы внутрь nix не залезали.
Типичная цитата живущих с nix: "Кстати, тут никто не сталкивался с проблемой что cabal прекращал находить пакеты в nix-shell после обновления до самых последних nixpkgs?"
Reply
Все равно лучше пока ничего не придумали, правильный подход - пинить версии nixpkgs, home-manager, методом собрались, вылили, проверили, не работает - откатились.
И да, у меня везде per project версии запинены, вышанаписаное - про "общую систему" (а так - nixpkgs/haskell.nix/naersk прибитые в flake.lock на попроектной основе)
Reply
Но для этого надо разбираться во многом, в тех же FST, и, вообще, знать систему от и до.
Что подводит нас к
2) можно использовать всё по минимуму и тогда, вместо подтягивания бесконечных пакетов, можно будет иметь ровно то, что требуется для системы и не более того.
Reply
Все равно тут два разных независимых кейса - 1) dev shell для проекта (с нужной версией компилятора, линтера, форматтера итд - и либами, отлично решает проблему с сищными/плюсовыми либами и их версиями, у каждого проекта/ревизии свой зоопарк.
2 кейс - система (+ дотфайлы) в том числе для некомпьютерных ни разу членов семьи. Мне _очень_ нравится что оно не ломается в процессе обновлений, оно легко отстраиваетяся на новом железе, если старый тазик помер, а так же что я могу подготовить все апдейты у себя, и разом их вылить за 10-15 минут.
Какую вы мне альтернативу предлагаете? Убунту?
PS Это если есть желание подискутировать, если нет, то ну его и замнем тему ;)
Reply
Девушки любят Mac, сын Windows. Мне бы убунту, но я в WSL2 застрял.
А про dev shell я уже высказался.
И повторю другую мою мысль: пакеты в ПО это то, что в американском законотворчестве называется riders. Соответственно, управление пакетами это управление "законами", многие из которых друг другу противоречат (пакеты не могут быть применены одновременно - две версии поддержки SSL, сколько же я с этим боролся) или содержат ненужное прямо тут и сейчас (OpenFST содержит WFST).
"nix, лучше которого ничего не придумали" это способ хоть как-то лавировать в этом лабиринте. Вместо исправления проблемы он предлагает паллиатив - "вот тут гвоздиками прибьём вот это вот, вы даже не заметите".
Не могу с таким подходом согласиться.
Reply
Leave a comment