Про printf всё очень просто, следующий код завершается аварийно на macOS, даже на Catalina при сборке с использованием Xcode 12:
int main(int argc, char** argv)
{
OverthrowerConfiguratorStep overthrower_configurator(0U);
activateOverthrower(); // Start failing ALL allocations.
printf("Some integer number: %d, some floating point number: %f, some string: %s\n", 100500, 100.500f, "100500");
deactivateOverthrower(); // Do not fail any allocations anymore.
return 0;
}
Ничего нелегального в fprintf, как мы видим, в данном случае не подаётся.
Запуск потока с использованием std::thread в условиях OOM приводит к падениям на macOS старее High Sierra.
Так же сталкивались с, что при попытки динамической загрузки Framework'ов вместо сообщений об ошибках получали падения внутри системных функций.
Но и обрабатывать по-умному ошибку, когда malloc вернул NULL, тоже нельзя, поскольку этот случай толком невозможно протестировать.
Очень даже можно. На Linux'е есть LD_PRELOAD, на macOS DYLD_INSERT_LIBRARIES. Пишем библиотеку которая оборачивает системный malloc. В своей обёртке над malloc'ом вы вольны возвращать NULL когда вам захочется.
Для Windows решение тоже имеется, но реализуется намного сложнее чем на NIX'ах.
Правда вынужден сказать, что заваливание malloc'а достойно переживает только Linux'вый рантайм. На macOS даже printf падает при невозможности выделить память. Эти неприятные мелочи приходится учитывать при тестировании.
Когда-то в прошлом я однозначно поглядывал на данное решение, деталей не помню. Как минимум отсутствует поддержка не десктопных платформ, вторым различие является то, что, как я понял, конвертироваться будут все аппаратные исключения где бы они не случились, а это не всегда то чего хочется. Хочется контролировать в каких секциях try мы этого хотим, а в каких нет. Да, это делает код кудрявее, зато даёт больше гибкости.
Дело было достаточно давно. Я не уверен в каком состоянии тогда был eskdx. На официальном сайте вообще нет ничего датируемого ранее чем 2010 годом. Моё решение изначально предназначалось не только для LaTeX. Если честно, eskdx мне не особо нравится и сейчас.
Да, находились. Но подходили они, разве что, для выполнения студенческих работ. Хотя наш преподаватель по инженерной компьютерной графике никогда бы не принял работы выполненные с их использованием.
Изначально работало под Windows. Потом решил от её поддержки отказаться. В принципе там ничего специфичного нет. Сами утилиты собираются легко с помощью MinGW. Необходим inkscape, кое-где pdftk, GnuWin32. Самая большая проблема была в том, что GNU make не умел работать с русскими именами. Насчёт «показать» у меня изначально был скепсис по поводу того, что это вообще кому-то будет интересно. Поэтому для публичной демонстрации ничего не готовилось. Если реально интересно, пишите в личку.
Лично встречался со случаем когда умирающий блок питания в предсмертной агонии убил почти все комплектующие. К счастью, в тот раз одним из выживших был жёсткий диск. Прожил он, однако, после этого не долго.
Был случай, когда по вине горе-электрика выгорело множество бытовой техники в целом доме. Знаю об этом не понаслышке, т.к. учился с одним из обывателей данного многоквартирного дома. Деньги на новую технику можно попытаться высудить у управляющей компании, но потерянных данных вам никто не вернёт.
Бэкап однозначно должен быть версифицированным. Однажды обнаружил пропажу пары ценных фотографий лишь через несколько месяцев. Хорошо, что было от куда их реанимировать.
Многие мои знакомые (почти все) справедливо считают меня параноиком, но тем не менее бэкап я храню следующим образом:
1. Делаю версифицированный бэкап локально на отдельном жёстком диске. Версифицированность получаю следующим образом: sudo rsync -av -HAX --delete -b --backup-dir="../home--`date +%Y-%m-%d--%k-%M-%S`" /home ./backups;
2. Локальный бэкап периодически целиком переправляю в прекрасное далёко. Оно достаточно далеко для того чтобы авиационный снаряд не смог одновременно уничтожить локальный и удалённый бэкапы;
3. Файлы подлежащие «вечному» хранению делаю «бессмертными» (устанавливаю атрибут immutable на ФС etx4);
4. Периодически уничтожаю ненужные дубликаты файлов появившиеся в следствии версифицированности (с помощью незамысловатых скриптов, использующих fdupes).
Если играть, то я бы порекомендовал ATI. На просторах интернета можно найти список видеокарт, которые точно пробрасываются. С NVIDIA сложнее, т.к. у них гарантированно работают только карты семейства Quadro. Падение быстродействия в ВМ ничтожно мало. Самое главное, что бы была поддержка со стороны процессора (VT-d у Intel, IOMMU у AMD). На некоторых материнских платах могут быть проблемы из-за BIOS (обновление до последней версии обычно помогает).
По поводу перекомпиляции ядра, то теоретически можно обойтись и без неё. В таком случае придётся «отбирать» необходимые для пробрасывания устройства у dom0 после его загрузки.
VNC необходим только для установки. После установки виртуальная машина внешне ни чем не отличается от реальной. К видеокарте подключен монитор (или два), в USB включены клавиатура и мышь. Можно конечно и по RDP работать.
Про
printfвсё очень просто, следующий код завершается аварийно на macOS, даже на Catalina при сборке с использованием Xcode 12:Ничего нелегального в
fprintf, как мы видим, в данном случае не подаётся.Запуск потока с использованием
std::threadв условиях OOM приводит к падениям на macOS старее High Sierra.Так же сталкивались с, что при попытки динамической загрузки Framework'ов вместо сообщений об ошибках получали падения внутри системных функций.
Из личного опыта и объективных результатов тестирования. Если
__cxa_allocate_exceptionне может выделить память мы получаем аварийное завершение работы приложения даже на macOS Mojave: https://travis-ci.org/github/kutelev/overthrower/jobs/734673895На Catalina с последним Xcode этого не происходит.
Очень даже можно. На Linux'е есть LD_PRELOAD, на macOS DYLD_INSERT_LIBRARIES. Пишем библиотеку которая оборачивает системный malloc. В своей обёртке над malloc'ом вы вольны возвращать NULL когда вам захочется.
Для Windows решение тоже имеется, но реализуется намного сложнее чем на NIX'ах.
Правда вынужден сказать, что заваливание malloc'а достойно переживает только Linux'вый рантайм. На macOS даже printf падает при невозможности выделить память. Эти неприятные мелочи приходится учитывать при тестировании.
Когда-то в прошлом я однозначно поглядывал на данное решение, деталей не помню. Как минимум отсутствует поддержка не десктопных платформ, вторым различие является то, что, как я понял, конвертироваться будут все аппаратные исключения где бы они не случились, а это не всегда то чего хочется. Хочется контролировать в каких секциях
tryмы этого хотим, а в каких нет. Да, это делает код кудрявее, зато даёт больше гибкости.Был случай, когда по вине горе-электрика выгорело множество бытовой техники в целом доме. Знаю об этом не понаслышке, т.к. учился с одним из обывателей данного многоквартирного дома. Деньги на новую технику можно попытаться высудить у управляющей компании, но потерянных данных вам никто не вернёт.
Бэкап однозначно должен быть версифицированным. Однажды обнаружил пропажу пары ценных фотографий лишь через несколько месяцев. Хорошо, что было от куда их реанимировать.
Многие мои знакомые (почти все) справедливо считают меня параноиком, но тем не менее бэкап я храню следующим образом:
1. Делаю версифицированный бэкап локально на отдельном жёстком диске. Версифицированность получаю следующим образом: sudo rsync -av -HAX --delete -b --backup-dir="../home--`date +%Y-%m-%d--%k-%M-%S`" /home ./backups;
2. Локальный бэкап периодически целиком переправляю в прекрасное далёко. Оно достаточно далеко для того чтобы авиационный снаряд не смог одновременно уничтожить локальный и удалённый бэкапы;
3. Файлы подлежащие «вечному» хранению делаю «бессмертными» (устанавливаю атрибут immutable на ФС etx4);
4. Периодически уничтожаю ненужные дубликаты файлов появившиеся в следствии версифицированности (с помощью незамысловатых скриптов, использующих fdupes).
По поводу перекомпиляции ядра, то теоретически можно обойтись и без неё. В таком случае придётся «отбирать» необходимые для пробрасывания устройства у dom0 после его загрузки.