История изменений
Исправление DRVTiny, (текущая версия) :
Автоматизированное развёртывание конфигураций на основе формализованных правил.
Puppet, Chef, Cfengine... Не слышали?
Я это к тому, что оркестр машинок на Debian не только управляется легче, но и работает лучше, чем разномастный зоопарк из *nix'ов.
В особенности учитывая тот факт, что различия в устройстве стека TCP/IP между Linux/FreeBSD/HP-UX конечному потребителю/пользователю будут куда менее заметны, чем, например, разница между Oracle+Exadata на современных дисках и PostgreSQL+RAID из древних, как говно мамонта, SCSI-дисков мизерного объёма.
Я уж не говорю о разнице в производительности качественного кода на C++ и говёного - на Java. Вроде бы банально, но факт: никакая гипер-оптимизация сети и железа не «вылечит» тот говнокод, с которым будет в конечном итоге иметь дело пользователь. То есть по моему личному скромному глубокому убеждению оптимизация IT-инфраструктуры обязана начинаться не с низкоуровневых вещей, когда речь идёт уже о микросекундах, а с «верхушки» стека. Потому что если тормозное веб-приложение тратит 364 мс на то, чтобы сложить 2+2 и вывести это в span'е, то в общем вряд ли бешенная оптимизация производительности дисковой подсистемы, сети и пр. - сильно повлияет на крайне негативное впечатление конечного потребителя о качестве предоставленной ему услуги.
Исходная версия DRVTiny, :
Автоматизированное развёртывание конфигураций на основе формализованных правил.
Puppet, Chef, Cfengine... Не слышали?
Я это к тому, что оркестр машинок на Debian не только управляется легче, но и работает лучше, чем разномастный зоопарк из *nix'ов.
В особенности учитывая тот факт, что различия в устройстве стека TCP/IP между Linux/FreeBSD/HP-UX конечному потребителю/пользователю будут куда менее заметны, чем, например, разница между Oracle+Exadata на современных дисках и PostgreSQL+RAID из древних, как говно мамонта, SCSI-дисков мизерного объёма. Я уж не говорю о разнице в производительности качественного кода на C++ и говёного - на Java. Вроде бы банально, но факт: никакая гипер-оптимизация сети и железа не «вылечит» тот говнокод, с которым будет в конечном итоге иметь дело пользователь. То есть по моему личному скромному глубокому убеждению оптимизация IT-инфраструктуры обязана начинаться не с низкоуровневых вещей, когда речь идёт уже о микросекундах, а с «верхушки» стека. Потому что если тормозное веб-приложение тратит 364 мс на то, чтобы сложить 2+2 и вывести это в span'е, то в общем вряд ли бешенная оптимизация производительности дисковой подсистемы, сети и пр. - сильн повлияет на крайне негативное впечатление конечного потребителя о качестве предоставленной ему услуги.