Пишу для себя, но хочу использовать более-менее общепринятые практики. Допустим, есть функция

def create_directory() -> bool:
  rc = create_directory_and_return_rc
  return rc

Она используется в основной функции

def main():
  if create_directory():
    create_file_in_directory()
    ...

Если основная задача функции create_directory не в возврате rc, а именно в выполнении чего-то (создания директории), а rc просто используется для контроля за выполнением, правильно ли называть функцию create_directory или нужно называть is_directory_created (условно) или вроде того? Главное условие, что нельзя разделить функцию на две функции (создание + проверка). В основном у меня этот вопрос возникает в связи с использованием subprocess, когда rc я могу получить только из функции, где этот subprocess используется.

Сейчас использую calc, но работает это все хуже. Смысл: есть документ состоящий из 2 листов. На 1 листе (лист данных) ежедневно заношу данные в 10 колонок. На 2 листе (лист анализа) некоторые расчеты (средние, максимумы/минимумы, медианы и прочее). Периодически требуется что-то дополнительно посчитать, что требует написания формул на 2 листе, отличных от тех, что там обычно. Чем дальше, тем больше во всем этом тормозов. Сейчас данными заполнено всего около 7 тыс. ячеек, расчетами около 50. Чтобы мне заполнить ячейку и увидеть результат перерасчетов требуется секунд 5. Причем почти не важно, на каком железе это делаю (самое производительное - ryzen 5900x с nvme и 64 Гб ОЗУ). Работать некомфортно, а данные надо заполнять дальше. Разбивать их на разные документы неудобно, потому что постоянно требуется сравнение из анализа на 2 листе, в котором должны быть все данные сразу, а периодические расчеты требуют выделения областей (слайсов) и их анализ + графики.

Вопрос: чем заменить calc при таком сценарии использования и сохранении максимального удобства использования или как разогнать calc до нормальной производительности? Я смотрел в сторону заполнения базы данных, вроде sqlite, и обработки данных на python через pandas, но это требует постоянной возни с кодом из-за потребности периодически досчитывать что-то дополнительно и строить графики. Какие есть еще варианты?

Дополнение. Данные нужно периодически предоставлять для ознакомления другим людям, поэтому должна быть выгрузка в человекочитаемые форматы. Лучше pdf. Если идти через python+sqlite это еще одна проблема.

Нубские вопросы. Никогда в эту тему не влезал, сейчас потребовалось.

Родное дистрибутивное ядро (дистрибутив slackware 15 x86_64), 5.15. В этом ядре нет поддержки моего оборудования. Оно есть в ядрах 6.2. Попытка сборки ядра 6.2 оборачивается руганью на версию glibc 2.33. Требует минимум 2.34.

Вопрос: ручное обновление до 2.34 что-то сломает в системе? Те программы, которые собирались с 2.33 будут работать с 2.34?

Вытекающий вопрос: как правильно выбрать firmware для ядра? То есть ядро 6.2. С момента выхода этой версии ядра могло выйти несколько «сборок» firmware (https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git). Я могу взять любую сборку firmware, и ОС загрузится без проблем или нужно искать самую последнюю совместимую с версией ядра сборку? Или на версию firmware можно не смотреть и брать в разумных пределах где-то около? Конечно, с учетом того, что сборки firmware, которые я беру, включают поддержку моего железа.

Bookworm с последними обновлениями. Сессия вейленд (иксы не тестировал пока). Раз примерно из 15-20 при выходе из сна gdm глючит, курсор еле едет, пароль вводится по одному символу раз в 10 секунд. После логина та же ситуация на десктопе. Приложения тормозят. Переключение между окнами по несколько секунд, фреймрейт при этом очень низкий (пара фпс, наверное).

В ресурсах проблемы нет. По htop нагрузки на цпу/раму/диск/сеть не больше чем обычно (почти нет), своп задействован по минимуму (свопа столько же, сколько рамы).

В логах такое:

May 31 11:44:02 imladris gnome-shell[2169]: Window manager warning: last_focus_time (217143187) is greater than comparison timestamp (217143137).  This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW.  Trying to work around...
May 31 11:44:02 imladris gnome-shell[2169]: Window manager warning: last_user_time (217143187) is greater than comparison timestamp (217143137).  This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW.  Trying to work around...
May 31 11:44:02 imladris gnome-shell[2169]: Window manager warning: W10 appears to be one of the offending windows with a timestamp of 217143187.  Working around...
May 31 11:44:02 imladris gnome-shell[2169]: Window manager warning: W947 appears to be one of the offending windows with a timestamp of 217143187.  Working around...
May 31 11:44:02 imladris kernel: [drm] Fence fallback timer expired on ring sdma0
May 31 11:44:02 imladris kernel: [drm] Fence fallback timer expired on ring gfx
May 31 11:44:03 imladris kernel: [drm] Fence fallback timer expired on ring sdma0
May 31 11:44:03 imladris kernel: [drm] Fence fallback timer expired on ring gfx
May 31 11:44:03 imladris kernel: [drm] Fence fallback timer expired on ring sdma0
May 31 11:44:04 imladris kernel: [drm] Fence fallback timer expired on ring sdma0
May 31 11:44:04 imladris kernel: [drm] Fence fallback timer expired on ring gfx
May 31 11:44:04 imladris kernel: [drm] Fence fallback timer expired on ring sdma0
May 31 11:44:04 imladris kernel: [drm] Fence fallback timer expired on ring gfx
May 31 11:44:05 imladris kernel: [drm] Fence fallback timer expired on ring gfx
May 31 11:44:05 imladris kernel: [drm] Fence fallback timer expired on ring gfx
May 31 11:44:06 imladris kernel: [drm] Fence fallback timer expired on ring sdma0
May 31 11:44:06 imladris kernel: [drm] Fence fallback timer expired on ring gfx

До перезагрузки производительность не восстанавливалась. Релогин не помогал.

Железо - ноутбук на 4600u на встройке, 16 гб рамы, нвме (по смарту живой). В какую сторону смотреть? Пробовать другое ядро?