Adamos

Ещё вариант -- корневую ФС установить на маленький раздел на SSD, /home на винт, остаток SSD включить во flashcache. В дебиане flashcache входит в дистрибутив, настроек -- минимум, скорость доступа к часто используемым файлам -- как к SSD. Сам использую такую конфигурацию больше трёх лет, с одним и тем же винтом и SSD.
SSD -- INTEL SSDSC2CT240A3, полёт нормальный, статистика SMART:

Vendor Specific SMART Attributes with Thresholds: 
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0032   100   100   000    Old_age   Always       -       2
  9 Power_On_Hours_and_Msec 0x0032   000   000   000    Old_age   Always       -       916104h+32m+02.410s
 12 Power_Cycle_Count       0x0032   098   098   000    Old_age   Always       -       2093
181 Program_Fail_Cnt_Total  0x0032   000   000   000    Old_age   Always       -       2
182 Erase_Fail_Count_Total  0x0032   000   000   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       2093
225 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       658878
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
233 Media_Wearout_Indicator 0x0032   100   100   000    Old_age   Always       -       0
241 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       658878
242 Host_Reads_32MiB        0x0032   100   100   000    Old_age   Always       -       561297
249 NAND_Writes_1GiB        0x0013   100   100   000    Pre-fail  Always       -       21915

unix.stackexchange.com/a/20830

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

В том же PHP можно изменить private свойство какого-либо объекта через Reflection.
Предположу, что такое же можно делать в других языках.

Важно само понимание, что можно изменять в программе.

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

Как осуществляется написание платежной системы касательно visa и mastercard или для конкретного банка? что делается в данном случае? (Допустим требуется работа со сбербанком и альфабанком).

Из личного опыта:
a. Приезжаете в офис банка у которого есть услуга "интернет эквайринг", показываете своё юрлицо, уставные документы, бенефициаров, обороты от 50 млн в месяц.
* некоторые работают и с меньшими оборотами, но % будет крайне не выгодным.
** без запущенного и работающего проекта идти в банк бессмысленно.
b. Ждете 2-6 недель пока СБ банка проверит все.
c. Ждете 2-4 недели пока банк подпишет договор
d. Получаете реквизиты и документацию API конкретного банка.
e. Реализуете
f. Ждете 1-2 недели пока банк проверит что у Вас все согласно их протоколу.
g. Получаете боевые реквизиты.

Учтите что:
1. Если Ваши объемы меньше чем 50млн+ в месяц - с вероятностью 99% Вам будет СИЛЬНО выгоднее работать через посредника. Посмотрите на uniteller.ru , payture.com/ru , payler.com - если Вы будете достаточно убедительны на переговорах, вполне реально сторговать их до 2-2.5% даже на маленьких оборотах (1млн-5млн)

2. Прямые API банков мягко говоря не современны. Как правило там не будет ни удобного личного кабинета, ни вменяемой службы поддержки - ничего. Зато будут проверки, требования бумажной отчетности и прочие милые сердцу советского бюрократа вещи.

3. Риски при работе через посредника - по факту минимальны. Все приведенные выше делают выплаты ежесуточно, т.е даже если посредник накроется - Вы максимум рискуете дневным оборотом.

С учетом данных пунктов, по моему мнению прямой договор с банком имеет смысл если у Вас настолько большие обороты - что разница в десятые доли процента окупает весь этот геморрой.
По факту есть море проектов с большими оборотами (mamba, badoo, etc) кто продолжает работать через агрегатор, минимизируя расходы на юристов, бухгалтеров, техническую поддержку работы шлюза итд итп.

Хардварные ограничения: текущий стандарт адресации (2003 года) LBA-48 требует 48-битные абреса блоков, т.е. 2^48 блоков - устройства до 128 ПиБ.

По софту:
Старый MBR ограничен в 2,2Тб, есть такое. Размечать диск надо будет в GPT, там 64-битные адреса.
Debian - это вам не странные windows, а нормальный Linux. Никаких бредовых ограничений на использование GPT нет. Хоть системный, хоть загрузочный, хоть с UEFI, хоть с BIOS - ему всё равно. Будет загружаться и работать как ни в чём не бывало.

for i in `find /yourdirectory -type f`;do sed -i 's/чтоменять/начтоменять/g' $i;done
с gui вот скрипт:
a=`zenity --entry --text="Что меняем" --entry-text=""`
b=`zenity --entry --text="На что меняем" --entry-text=""`
for i in `find /yourdirectory -type f`;do sed -i "s/${a}/${b}/g" $i;done

MySQL не поддерживает ASSERTION.
Используйте триггеры BEFORE INSERT и BEFORE UPDATE.

Все просто - если ваш программист может сделать этот бизнес без вас, значит любой другой тоже это может сделать\скопировать\разреверсить. От копирования вы уже ничем себя не защитите, можете даже не строить иллюзий - меняется название софта, немного правится интерфейс и, вуаля, другой проект к которому не подкапаешься. Если вас проект легко скопировать, подумайте, а стоит ли вообще им заниматься?

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

Внутри Docker только Linux, и, экспериментально, FreeBSD. Запускается нативно под Linux и, экспериментально, под FreeBSD. Под MacOSX, Windows - через виртуальную машину.

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

Это почти виртуальная машина. Почти, да не совсем.

Есть такое понятие "ад зависимостей". Любое ПО устанавливаемое на компьютер, тянет за собой зависимости (конфигурационные файлы, статические файлы называемые обычно asset, вспомогательные утилиты/сервисы, библиотеки и пр.). Ряд из этих библиотек/утилит/сервисов несовместим друг с другом. А с учетом того, что каждая из этих библиотек/утилит/сервисов имеет и свои зависимости - ситуация еще хуже.

Например, мы используем Yandex.Cocaine, которая нормально компилируется только на Ubuntu 14.04 (и, вроде, на Debian 7). Но не под CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 и пр. - скомпилировать его невозможно. Запускаем в этих операционных системах в Докере.

С другой стороны, и одновременно с этим, вам необходимо установить другое, более современное ПО. И одновременно более старое. Причем речь даже не идет об серьезно отличающихся версиях Linux. Например, одно ПО требует не менее Ubuntu 14.10, а другое не более Linux 14.04.

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

Таким образом, мы имеем бинарный файл запускаемый как бы в своей операционной системе.

Вы можете сказать - ба, да это же давно известная виртуальная машина. Но нет, это не так. Это так называемые контейнера. Никакой виртуальной машиной там и не пахнет. За исключением Windows и MacOSX, где работа без виртуальном машины пока экспериментально возможно только, а нормой в этих ОС является использование Докера внутри полноценной виртуальной машины.

Но виртуальные машины с Докером используются только для разработки. Для запуска в production виртуальные машины с Докер не используются.

Докер использует контейнеры операционной системы. LXC в Linux, Jails в FreeBSD. Контейнер - это область операционной системы, изолированная от основной части операционной системы. В контейнере свое дерево каталогов (включая системные /dev, /bin, /sbin и пр.), свои сетевые порты и пр. и пр.

Но при этом не используется полная виртуализация. Что существенно экономит ресурсы. Запустить 100 полноценных виртуальных машин вряд ли получится даже на мощном сервере. А вот запустить 100 контейнеров Docker даже на слабом домашнем компьютере - возможно.

Правда использование не полной виртуализации ограничивает использование операционных систем внутри контейнеров. Как правило, это специально подготовленные версии Linux или FreeBSD. Именно специально подготовленные. Windows - в принципе в контейнере запустить невозможно.

Контейнеры существовали и до Docker. Докер, строго говоря, это всего лишь очень удобный набор инструментов, собранных воедино, для управления контейнерной виртуализацией. Но очень удобный.

Зачем это используется?

Ребята из всяческих Dropbox, Facebook и и пр. гигантах, запускающие по 1 млн. различных программ в своих сервисах, столкнулись, что невозможно везде гарантировать идентичные настройки операционной системы. А это критично.

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

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

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

Это позволяет гарантировать гораздо большую идентичность среды разработки и среды исполнения.

До этого люди мучались, придумывали хитрые инсталяторы...

Потом плюнули на попытки упорядочить окружение в ОС - и сейчас концепция такова - устанавливать программы на сервера вместе со своими индивидуально настроенными под них операционными системами - то есть внутри контейнеров. 1 контейнер = 1 настройка ОС = 1 программа внутри.

Другими словами:

• Докер-контейнер нужно использовать для отладки.
  
• Тот же Докер-контейнер нужно использовать и на сервере.
  

Это позволяет не трудиться с настройками "под сервер" локально на машине разработчика. Это позволяет разрабатывать на машине разработчика совершенно разные программы одновременно, которые требует несовместимых настроек операционной системы. Это позволяет давать гораздо больше гарантий, что программа на сервере будет вести себя также как и на машине разработчика. Это позволяет разрабатывать под Windows/MacOSX с удобным "прозрачным" тестированием под Linux.

Докер применим к созданию/настройке только серверного программного обеспечения под Linux (экспериментально под FreeBSD). Не для смартфонов. А если десктопов - то только программное обеспечение без GUI.

Посколько Докер позволил одним махом упростить работу разработчикам и админам и повысить качество результата - сейчас бум на Докер. Придумано огромная гора инструментов для управления развертыванием приложений созданных с Докером. Если раньше чтобы запустить 10 000 программ на 1000 серверах нужно было как минимум 3 высококвалифицированнейших девопса, которые писали кучу описаний как это сделать на Puppet, Salt, Chef, Ansible, да и то не было гарантий, это все тестилось месяцами. То сейчас с Докер даже один квалифицированных девопс может рулить миллионами программ на десятках тысяч серверов. С куда как большей гарантией, что все это заведется нормально.

UPD:

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

Разработчик отдает весь свой результат в систему CI (обычно через git)
CI на каждый новый коммит делает с помощью Docker образ для тестирования.
Если тесты проходят успешно, то этот же самый Docker образ, отправляется на развертывание в production.
Или, чуть иначе в компилируемых системах, где исходники не нужны в production: в Docker производится развертывание среды для компиляции, а для тестирования разворачивается второй образ с уже откомпилированным добром, который уже отправляется в production.

То есть при правильной огранизации дела разработчик не может/не должен влиять на то, какой будет образ.
А вот в тестовой среде (запускаемом на сервер, недоступном разработчику в больших командах) и в production как раз используется один и тот же образ.

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