Karpion

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

Самый тупой способ:

1. сделать каждому свою собственную корневую систему со всем деревом папок;
   
2. общие файлы - жёстко слинковать;
   
3. индивидуальные файлы - каждому свои.
   

Система получается неимоверно гибкая: каждому клиенту можно выставить собственный набор файлов, который у него общий с остальными. Т.е. можно поставить трём клиентам один файл, пяти други - другой файл, а мест на диске займут два реальных файла.
Цена этой гибкости - муторное администрирование. Муторно потому, что никому раеально такая гибкость не нужна.

Ещё можно посмотреть в сторону UnionFS, которая может подвесить/смонтировать один каталог к другому.

Ещё можно поиграть с симлинками - их можно делать на каталог, а резолвиться они будут на клиентах.

Если файловая система сервера умеет дедуплицирование хотя бы на уровне файлов - то вообще нет проблемы создавать каждому клиенту свой полноценный каталог.

Короче, Вы напишите, какие каталоги заведомо будут общие; какие с высокой вероятностью будут общие; а какие скорее сего будут раздельные. Тогда будет ясно, какой способ выбрать.

Начнём с аппаратуры:

• пыль в системнике и в блоке питания;
  
• крутиляторы
  
• вздутые конденсаторы на мат.плате, на видюхе и на плате в блоке питания;
  
• термопаста и плотность прилегания радиатора на процессоре и прочих чипах с радиатором;
  

после проверки - отпишитесь, будем думать.

Можно использовать что-то типа document.write - он пишет прямо внутрь документа.

Можно поставить вместо констант - JS-переменные.

Можно создать div и командами JS менять его содержимое.

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

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

Если у программы открыты исходники - то можно поправить их, научив программу работать как Вам надо. Также можно обратиться к автору - с идеей поправок; м.б., они уже реализованы, но не включены в документацию.

Если бы Вы назвали программу - ответ был бы более детальный.

Кластеризация - это весьма многообразная и нетривиальная наука. Если многопроцессорные/многоядерные системы уже стали банальностью - то кластеризация "ещё не устаканилась".

Есть вариант кластеризации, подражающий многопроцессорынм/многоядерным системам:
На каждом компьютере (компьютер при этом называется "нода", т.е. член кластера)) запущено своё собственное ядро с поддержкой кластеризации. Эти ядра регулярно обмениваются между собой на предмет сравнения очередей исполняемых задач (процессов). Если выясняется существенный дисбаланс приоритетов (это долго объяснять, пока пропустим подробности), то ядра затевают перенос задач с одной ноды на другую для выравнивания очередей. При этом надо перенести исполняемый код, данные задачи и управляющие структуры ядра, связанные с этой задачей (например, дескрипторы открытых файлов). Перенос задачи на новую ноду - это тяжёлая работа, так что её затевают если дисбаланс ну очень уж сильный. (Перенос задач между ядрами - тоже затевают пореже; там это проще, то тоже желательно делать это пореже.)
Перенос задачи на новую ноду возможен только если там одинаковые процессоры (либо - если код задачи интерпретируемый; например, байт-код JVM).

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

Но есть и иной тип кластеризации:
На каждой ноде есть программный код, откомпилированный под неё. Программа (которую компилировали под разные ноды) написана так, что она умеет связываться с копиями на остальных нодах (откуда она знает список нод - это вообще отдельная тема) и перераспределять работу. Т.е. исходная задача д.б. оформлена как обработка большого массива данных; причём данные разбиты на куски, которые можно обрабатывать независимо. И вот разные куски данных перераспределяются между нодами.
Например, брутфорс-подбор пароля - как раз такая задача, котрую можно раскидать на разные ноды с процессорами разных архитектур. Там вообще нет сложных потоков данных - есть огромный массив исходных данных в виде "все возможные пароли", и эти данные легко разделить на полностью независимые блоки.

Кажется, я достаточно загрузил Вас. Дальше разговаривать надо после того, как Вы уточните - что за тяжёлые задачи Вы хотите распараллелить.

SSD имеет преимущества в скорости именно на мелких операциях, и то только на тех, которые не укладываются в кэш ни на брюхе диска, ни в операционке (тут отдельный вопрос с чтением и записью - короче, всё сложно). На крупных операциях - HDD вполне нормально конкурирует с SSD.

Правда, есть системы, в которых Flash-память доступна не через SATA-интерфейс, а короче - микросхемы Flash-памяти распаяны либо на PCI-x плате, либо вообще на мат.плате. Эти системы уделывают HDD и по линейным операциям - в силу более широкой шины данных. Вопрос в том, нужна ли людям такая скорость.

SSD (и вообще Flash-память) потребляют намного меньше электричества, особенно в периоды простоя, когда нет работы. HDD при этом всё время крутится; но или даже если он останавливается, то не сразу после прекращения операции, а то он так быстро износится.

SSD (и вообще Flash-память) гораздо меньше боится тряски, ударов и прочих механических воздействий. По той же причине.

SSD (и вообще Flash-память) имеют меньший размер и вес.

Три последних отлиия - важны для портативных устройств с автономным питанием. Планшеты и смартфоны - изначально шли с Flash-памятью, HDD там никогда не было.

Преимущество HDD - только в цене гигабайта. Насколько это актуально - зависит от ситуации: иногда это важнее всего (видеохостинг, огромная БД); иногда вообще неактуально.

Поинтересуйтесь, сколько останется на диске после установки системы. Т.е. надо смотреть на размер операционки.

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

Кстати, если с т.з. BIOS/UEFI загрузочным является SSD - то какие-то элементы начальной загрузки лежат там.
Писюковая система загрузки - это богомерзкая долбанутая на всю голову хрень, где одна легаси сидит верхом на другой, и третьей погоняет. Она кривая до невозможности, а переход от BIOS к UEFI добавил ещё тонну долбанутости.

"H1" или "h1" - это не "заголовок html", а "тег для выделения заголовка в тексте". Их можно ставить как угодно и где угодно.

Есть необязательное правило:

• H1 - это заголовок документа
  
• H2 - это заголовки разделов
  
• H3 - это заголовки подразделов
  

ну и так далее...

Ну, если я правильно понял вопрос.