mayton2019

Нет, все утилиты восстановления удаленных файлов копируют данные на новый диск. В теории это возможно конечно, но на практике готового софта нет.

80Тб это значит несколько дисков. В зависимости от того, как на их основе построен архив, можно попробовать по одному диску от архива отсоединять и на него восстаналивать (так не получится если на всех дисках создан один огромный raid массив)

на время восстановления массив не перезаписывать и вообще ничего с ним не делать, т.е. режим только чтения.

Настучать бы тем кто дает советы дробить ОДИН диск на разделы и раскидывать файловую систему linux по нему, причем используя lvm который тут ну совсем не нужен.

Настоятельно рекомендую избавиться от этой формы разбиения диска, сделать резервную копию всего корня / диска (tar, например сделав отдельно для каждого раздела, добавив ключ --one-file-system) и удалить lvm. Абсолютно все фичи, которые дает lvm можно получить с помощью btrfs или zfs, при этом это будет еще и быстрее (снапшоты у этих cow файловых систем бесплатные, а у lvm за 2х понижение записи)

настоятельно рекомендую следующий конфиг:
gpt таблица разделов
* 1Мб biosboot - раздел нужен если используешь legacy mbr в биосе
* 100Мб EFIboot - раздел нужен если используешь UEFI secure boot в биосе
* 512Мб ext4 /boot - раздел не обязательный, нужен только если используется нестандартная фйловая система или странные конфиги (типа bcache ssd кеш для hdd), так же он нужен для дисков больше 2Тб
* сколько надо btrfs / - раздел куда установишь систему
благодаря btrfs можно точно так же наклепать в нем виртуальных разделов для /var /home /tmp причем можно даже не указывать лимиты (будет использоваться общее место)

btrfs прекрасно умеет grub и не считается экзотикой (/boot раздел не требуется)

p.s. кстати, если загрузчик grub можно установить на другой диск (например карта памяти или другой диск), то системный диск nvme даже не придется разбивать на разделы и использовать буквально весь под файловую систему

p.p.s. btrfs мощная файловая система но настоятельно не рекомендую использовать его raid5, он еще нестабилен, хотя критичных багов, ведущих к потере данных нет, но есть сообщения о потерях свободного места в экзотических ситуациях

для софтварного рейда лучше пользоваться mdadm

Вы правы, рекурсию всегда можно заменить циклом. Более того, рекурсия - это и есть цикл, который за вас выполняет движок языка. Главный вопрос - что для вас будет удобнее: рекурсия или цикл.

Зачем нужна рекурсия в реальных случаях?

Чтобы уменьшить количество переменных, указателей, строк, сложность кода, сложность алгоритма, время разработки, сложность отладки.

Начать с математического доказательства (проверки), что для заданной конфигурации решение в принципе существет. А то можно искусственно создать неразрешимую конфигурацию (цветные квадратики отодрали и наклеили в другом порядке). Такое доказательство может в значительной мере определять алгоритм (но это не точно).
Готовые алгоритмы здесь: https://playlab.ru/club/instructions/

Ограничения бывают в софте но только искусственные, созданные к примеру компанией intel для монополизации рынка, отличным примером был sdk (набор инструментов и библиотеки) по работе с камерами-сканерами (3d intel realsense), на старте у них уже в железе были заложены ограничения на usb контроллер через который нужно было подключать камеру плюс проверки в софте (их потом убрали, но как я понял не все)

Повторяю, ограничения искусственные.

На практике софт, собранный с поддержкой только определенного процессора (различные фичи) мог бы не заработать на другом, но это будет верно даже в предела одного вендора но с разными моделями. Обычно чтобы этого не происходило, либо собирают софт с поддержкой сразу нескольких процессоров (как amd так и intel) либо не используют ничего, что могло бы нарушить эту совместимость

1. Если в плюсах class и struct фактически одно и тоже (да у класса по умолчанию все приватное, у структуры открытое, в этом разница), в шарпе это разные вещи.
2. в шарпе классы и так по ссылке передаются, ref class в шарпе аналог **class (указатель на указатель) и ref struct - *struct в плюсах.

Посмотрите логи из перезапускающегося docker containera - можете даже попробовать найти логи от старых контейнеров, которые работали до этого

docker logs -f --until=10s container_id

https://geekflare.com/check-docker-logs/

В чем дело? Да в том, что в рабочем проекте я этого не встречал НИ РАЗУ.

Поддерживаю, никто не использует каррирование в чистом виде. С другой стороны, если учесть, что классы - это частный случай каррирования, то его используют повсеместно.

Ну а вопрос, зачем динамически выполнять то, что ещё на этапе проектирования зафиксировано и статично (я говорю о вызове функций), всегда вводит в ступор адептов каверзных вопросов и ФП.

На Haskell точно используется, т.к. частично применённые функции можно объединять (композиция, функторы, аппликативные функторы...), а как заметил mayton2019, тут и оптимизация возможна.
Посмотрите лекцию Дениса Москвина про оптимизацию.

Каррирование используется в библиотеках. Например, вот этой: https://github.com/substantial/updeep

Предполагаю, что проблема в невозможности сборки TDLib с Musl libc (стандартная библиотека Си, которая используется в Alpine Linux). Попробуйте использовать в качестве основы образа другой дистрибутив Linux.

Как там говорил кто-то из великих "Если вы что-то не можете объяснить 6-летнему ребёнку, вы сами этого не понимаете."
Ну и по вопросу часто понятно уровень спрашивающего.

Сначала заходить в профиль, чтобы посмотреть на вопросы, ответы, комментарии etc.

Современные микросхемы флэш-памяти хранят 2(MLC), 3(TLC) или 4(QLC) бита информации в 1 ячейке. Чем большая плотность хранения, тем меньшая скорость записи. Поэтому большинство современных SSD умеют при записи использовать незадействованные ячейки в режиме SLC-кэша(по 1 биту в ячейку), то есть записывать быстро но в 2-4 раза менее плотно, до исчерпания свободных ячеек. После исчерпания свободных ячеек контроллер переходит в режим плотной но медленной записи. Если вы оставляете X Гбайт неразмеченных, то при записи у вас гарантированно быстро будут записываться X/2(MLC), X/3(TLC) или X/4(QLC) Гбайт.

Потому что в меню графика круче, чем в самой игре.
Высокие фпс вам в меню ни к чему.
А то что греется - ну пусть греется, вам жалко электричества что ли?

читать заголовки файлов, если pnga = есть , если просто png = быть не может