исполнение Windows промышленных проектов под Wine
Добавлено: 14 мар 2013, 19:54
Вот такой вопрос: имеет ли смысл выполнение промышленных проектов под Wine?
Вопрос откуда произошёл:
- меня пригласили в девелоперскую фирму, достаточно крупную и с достаточно хорошей историей, производящей некоторые разные комплексные системы... это некоторые системы ... регистрации (на HDD) потоков принимаемых сеансов GSM мобильной связи;
- ними произведено новое оборудование, превосходящее по производительности предыдущее поколение ... раз в ~5, при этом потоки по TCP/IP (входные и внутри системы, между программными модулями) и на HDD теперь достигают критических для аппаратуры величин ... 20 Мбайт/сек. и заметно более;
- есть вариант "размасштабировать" программную систему "погоризонтали" - разнести разного уровня обрабатывающие модули (сам сервер обработчик-регистратор, его визуализатор, администрирование и управление БД и др.) по разным хостам (благо, модули сделали "по уму", взаимодействующие по TCP/IP) ...
- и для улучшения (по производительности, надёжности, конфигурируемости, прозрачности, ...) перевести самые напряжённые модули-хосты (сервер обработчик-регистратор) на Linux - естественно, всё это раньше крутилось на едином хосте Windows ...
- программно эти модули в сумме - это крупный долгосрочный проект, развивавшийся и изменявшийся лет 5 или несколько более, трудоёмккостью в несколько десятков человеко-лет, писанные (кто из модулей на чём: Visual C++, C++ Builder, прикомпоновано ExtremeDB и графика DevExpress, многопоточность с использованием библиотек Boost ... и т.д.).
И вот вопрос, совершенно не тривиальный:
- а не имеет ли смысл такой и другие такие (!) проприетарные проекты просто эксплуатировать в Linux под Wine?
- вместо того, чтобы переписывать код проекта ... "портировать" то, что не портруемо
- по крайней мере (в первую очередь) те серверные компоненты проекта, которые не имеют графического пользовательского интерфейса (GUI)...
- при том, что к сфере Wine по традиции относят запуск игрушек ... ну и ещё, так уже сложилось, 1С-Бухгалтерию...
Т.е. вместо того, чтобы переписывать крупную программную систему, просто начать её эксплуатировать "как есть", не терять на переписывание времени, а уже какую-то следующую версию начать писать исключительно под Linux, "с чистого листа", начиная с архитектурной проработки под POSIX.
При этом с Wine в Linux, предполагаю, такое исполнение может получить все основные преимущества Linux, и не притягивая за собой минусов родного исполнения в Windows:
- Linux стек TCP/IP производительнее и, главное, он прозрачный, хорошо конфигурируемый, и имеющий огромный инструментарий диагностики и контроля...
- но делается всё это конфигурирование (в смысле QoS и др.) средствами ОС, извне программы, так, что она и не заметит, что ей из-под Wine подсунули другой стек;
- обращения (по буферизации на обработке) к HDD в файловой системе NTFS (которые нужны в "рандомном" а не последовательном режиме к файлам) - крайне избыточны, но теперь можно а). использовать высокопроизводительные ФС без журналирования, ext2 ту же + б). можно перепробовать и десяток разных более подходящих файловых систем (ufs, zfs и т.д.);
- можно вообще легко использовать просто вместо файлов неразмеченные дисковые устройства: /dev/sdb, или разделы: /dev/sdb3 ... с такой же лёгкостью как и файлы.
P.S. При этом только не нужно упускать (для правильной оценки), что Wine не есть система виртуализации. Это а). механизм вызовов Win32 DLL + б). подмена системных DLL (kernel32.dll, user32.dll и мн. др.) с тем, чтобы системные вызовы Win32 API ретранслировать в системные вызовы POSIX. При этом не должно происходить существенного снижения ни производительности, ни надёжности.
Таким способом многие промышленные проекты прежних лет могут просто получить новую жизнь под Linux.
Это всё - вопрос интересный, и совсем не очевидный: что выигрывает и что проигрывает при таком решении разработчик?
Вопрос откуда произошёл:
- меня пригласили в девелоперскую фирму, достаточно крупную и с достаточно хорошей историей, производящей некоторые разные комплексные системы... это некоторые системы ... регистрации (на HDD) потоков принимаемых сеансов GSM мобильной связи;
- ними произведено новое оборудование, превосходящее по производительности предыдущее поколение ... раз в ~5, при этом потоки по TCP/IP (входные и внутри системы, между программными модулями) и на HDD теперь достигают критических для аппаратуры величин ... 20 Мбайт/сек. и заметно более;
- есть вариант "размасштабировать" программную систему "погоризонтали" - разнести разного уровня обрабатывающие модули (сам сервер обработчик-регистратор, его визуализатор, администрирование и управление БД и др.) по разным хостам (благо, модули сделали "по уму", взаимодействующие по TCP/IP) ...
- и для улучшения (по производительности, надёжности, конфигурируемости, прозрачности, ...) перевести самые напряжённые модули-хосты (сервер обработчик-регистратор) на Linux - естественно, всё это раньше крутилось на едином хосте Windows ...
- программно эти модули в сумме - это крупный долгосрочный проект, развивавшийся и изменявшийся лет 5 или несколько более, трудоёмккостью в несколько десятков человеко-лет, писанные (кто из модулей на чём: Visual C++, C++ Builder, прикомпоновано ExtremeDB и графика DevExpress, многопоточность с использованием библиотек Boost ... и т.д.).
И вот вопрос, совершенно не тривиальный:
- а не имеет ли смысл такой и другие такие (!) проприетарные проекты просто эксплуатировать в Linux под Wine?
- вместо того, чтобы переписывать код проекта ... "портировать" то, что не портруемо
- по крайней мере (в первую очередь) те серверные компоненты проекта, которые не имеют графического пользовательского интерфейса (GUI)...
- при том, что к сфере Wine по традиции относят запуск игрушек ... ну и ещё, так уже сложилось, 1С-Бухгалтерию...
Т.е. вместо того, чтобы переписывать крупную программную систему, просто начать её эксплуатировать "как есть", не терять на переписывание времени, а уже какую-то следующую версию начать писать исключительно под Linux, "с чистого листа", начиная с архитектурной проработки под POSIX.
При этом с Wine в Linux, предполагаю, такое исполнение может получить все основные преимущества Linux, и не притягивая за собой минусов родного исполнения в Windows:
- Linux стек TCP/IP производительнее и, главное, он прозрачный, хорошо конфигурируемый, и имеющий огромный инструментарий диагностики и контроля...
- но делается всё это конфигурирование (в смысле QoS и др.) средствами ОС, извне программы, так, что она и не заметит, что ей из-под Wine подсунули другой стек;
- обращения (по буферизации на обработке) к HDD в файловой системе NTFS (которые нужны в "рандомном" а не последовательном режиме к файлам) - крайне избыточны, но теперь можно а). использовать высокопроизводительные ФС без журналирования, ext2 ту же + б). можно перепробовать и десяток разных более подходящих файловых систем (ufs, zfs и т.д.);
- можно вообще легко использовать просто вместо файлов неразмеченные дисковые устройства: /dev/sdb, или разделы: /dev/sdb3 ... с такой же лёгкостью как и файлы.
P.S. При этом только не нужно упускать (для правильной оценки), что Wine не есть система виртуализации. Это а). механизм вызовов Win32 DLL + б). подмена системных DLL (kernel32.dll, user32.dll и мн. др.) с тем, чтобы системные вызовы Win32 API ретранслировать в системные вызовы POSIX. При этом не должно происходить существенного снижения ни производительности, ни надёжности.
Таким способом многие промышленные проекты прежних лет могут просто получить новую жизнь под Linux.
Это всё - вопрос интересный, и совсем не очевидный: что выигрывает и что проигрывает при таком решении разработчик?