Дмитрий Носачев quartz64

И чем набор длинного текста на сплите удобнее

Вы собрались писать длинный текст зачем вам макросы?

вообще на клавиатуру практически не смотрю

#define LSPO_KEYS KC_LSFT, KC_TRNS, KC_LBRC
#define RSPC_KEYS KC_RSFT, KC_TRNS, KC_RBRC

Хорошо, представим что автор фрилансер и работает постоянно с своей рабочей машины. А если появляется необходимость работы за вторым ПК? Мышечная память никуда не девается. А ноутбуки с стандартной клавиатурой?

Ну и последний минус, хоть и не самый значимый, это цена. Цена для компьютерного расходника не на каждый кошелек.

Но сделана была она на совсем уж таком древнем железе что даже есть ограничения на хранимые макросы

Какой-то запредельно жуткий машинный перевод.

хрен потом что-то на стандартной напечатаешь

В RAID-5/6 после выпадения диска нагрузка сильно растёт. Захотели прочитать страйп с данными -> его больше нет -> читаем все страйпы этой строки и восстанавливаем отсутствующий кусок через контрольную сумму. В том числе по этой причине уже давно считается дурным тоном 1) строить RAID-5 из больших по объёму дисков (строгой границы нет, но в большинстве случаев это >1 ТБ, куда попадают все 7200 об/мин диски) 2) строить длинные дисковые группы, больше 10-12 HDD из сплошного RAID-5/6. Надо длиннее — разбиваем на кусочки и делаем RAID-60.

Что значит «другая фича», когда unmap используется в SCSI для тех же целей, что и trim в ATA?
Ситуация с передачей trim в контроллерах Broadcom сейчас такова: https://www.broadcom.com/support/knowledgebase/1211161496937/trim-and-sgunmap-support-for-lsi-hbas-and-raid-controllers

Там всё просто на самом деле. Это тот же RAID-5, но со слегка нарушенной очередностью записи страйпов и контрольных сумм. Выбирается один из накопителей и на него добавляется +1 запись контрольной суммы вне очереди. Из-за такой побочной штуки, как write-penalty (пишем что-то в RAID-5 с размером меньше полного страйпа — получаем необходимость пересчитать и записать новую контрольную сумму), на этот накопитель приходится большая нагрузка на запись. По достижении определённого износа выбирается следующий SSD и так далее.
Я ни разу не наблюдал на практике подтверждения этой фобии равномерного износа (см. выше), а вот минусы этого подхода есть — этот RAID-F1 является проприетарной надстройкой Synology над mdadm, т.е. в случае чего абы где массив не поднять.

По моим наблюдениям (статистика обращений по гарантии и техподдержке почти за 10 лет, серверы и СХД) все эти опасения насчёт одновременного выхода из строя являются чем-то вроде старой городской страшилки. Это было с HDD и доходило до рекомендаций ставить в большие массивы диски непременно 3–4 разных моделей и от разных вендоров (!). Определённые основания такой фобии есть, они связаны с массовым отказом определённой моделей. Но, во-первых, последний очень громкий и действительно массовый случай был с Барракудами 7200.11 и это было 10 лет назад, во-вторых — не надо под серьёзный production собирать массивы из бытовых дисков, и в-третьих — не надо забывать про аксиому «RAID ≠ бэкап».
Видимо с годами эта фобия перекочевала на SSD, но тут на практике вообще ничего не подтверждается. Да, SSD мрут, в том числе и серверные, и любых вендоров/моделей (есть обширная статистика Intel, Micron, Samsung, HGST, Toshiba), но за 10 лет я ни разу не наблюдал этого мифического случая «одновременного износа».

Выравниванием износа, помимо прочих задач, занимается контроллер самого SSD.

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

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