Як пояснити, що писати універсальний міжплатформний код C ++ та доставку продуктів для всіх ОС не так просто?

Наша компанія постачає цілий ряд настільних продуктів для Windows, і багато користувачів Linux скаржаться на форумах, що ми повинні були писати версії наших продуктів для Linux років тому, і причина, чому ми цього не робимо, це

• ми жадібна корпорація
• всі наші технічні фахівці - недокваліфіковані ідіоти

Наш середній продукт - це щось на зразок 3 мільйонів рядків коду С ++.

Аналіз мого та моїх колег полягає в наступному:

• написати кросплатформенний код C ++ не так просто
• підготовка багатьох пакетів дистрибуції та підтримка їх для всіх поширених версій Linux потребує часу
• ми вважаємо, що ринок Linux - це на зразок 5-15% усіх користувачів, і ці користувачі, ймовірно, не захочуть платити за наші зусилля

коли це виховується, знову відповідає, що ми жадібні недокваліфіковані ідіоти і що коли все робиться правильно, все це легко і безболісно.

Наскільки обґрунтовані наші оцінки того факту, що написання крос-платформного коду та підтримка численних пакетів розподілу вимагає багато зусиль? Де ми можемо знайти простий, але детальний аналіз з реальних історій життя, які показують поза тінню сумнівів, яку саме кількість зусиль потрібно?

Майте на увазі, що більшість людей є працівниками, і тому вони не живуть у світі, де їм потрібно дбати про отримання прибутку. Вони з’являються на роботі, роблять свою справу та йдуть додому, ніколи не замислюючись над тим, як працює весь процес. І хоча вони дуже розумні, багато техніків позитивно не знають про бізнес і часто осліплюють догми.

Ви маєте рацію, звичайно, виготовлення програмного забезпечення x-платформи такого масштабу - справа не проста. Особливо, коли ви не компанія, яка має багато десятків розробників і мільйони користувачів. І це не лише технічні обмеження. Все про вартість та вигоду. Так, ви можете витратити потім наступний рік, переносячи додаток на Linux (незважаючи на те, як зазначаєте, він уже працює у WINE). Звичайно, той рік розвитку не виходить вільним. І врешті-решт, можливо, вас зачиститьдодаткові 5-15% користувачів (на основі вашої оцінки). Або ви можете взяти ті самі гроші / зусилля і зосередити їх на розробці Windows як нову версію, або ввести все це в маркетинг, і додати 50% до своєї бази користувачів. Що звучить як розумний вибір? (очевидно, що номери потрібно підганяти до вашої компанії, і кінцевий результат може сприяти перенесенню).

Я не знаю, чи це допоможе переконати "справжніх віруючих", але її розумний бізнес-крок. І якщо ви не робите розумних бізнес-рухів, ви не працюєте. І тоді точно не буде версії Linux.

Тут я думаю, що слід враховувати дві речі:

Перше полягає в тому, що вони певним чином мають рацію. Написання крос-платформи C ++ не так складно, якщо ви планували це з самого початку . Це майже напевно проблема, яку ви бачите. Більшість програм з відкритим кодом (більшість програм, до яких користувач Linux зачіпає в середньому за день), є абсурдно крос-платформою. Подумайте про кількість додатків, з якими пересічний користувач Linux взаємодіє щодня, які написані на C або C ++ і працюють не лише в Windows і Linux, але і MacOS, BSD, Solaris тощо на x86, x86-64, ARM, SPARC, Це частково тому, що люди з сверблячкою подряпають код порту для роботи в своїх системах, а також тому, що тоді умовою є планування переносимості між платформами.

Друга річ, ринок може бути більш життєздатним, ніж ви думаєте. Існує величезна помилка, що люди в Linux не хочуть платити за програмне забезпечення. Для деяких людей це може бути правдою, але є дуже багато людей (більшість, я думаю,), які використовують Linux, оскільки це працює для них краще, і вони віддають перевагу, а не через ціну. Крім того, якщо ваша компанія виробляє продукт, який використовується в першу чергу в професійних умовах, компанії добре звикли платити за програмне забезпечення, що працює на системах Linux.

Що стосується того, що ви робите щодо упаковки, то, як говорили інші, вам потрібно просто виготовити пакети для останньої версії основних дистрибутивів. Насправді виготовлення пакетів насправді не так вже й складно, і більшість основних дистрибутивів використовують або пакети debian (debian, ubuntu тощо), або RPM (fedora, suse, centos, mandrake), тож змінити деякі сценарії дуже незначно. для створення декількох пакетів з базової лінії .deb та базової лінії .rpm, а для всіх інших просто киньте тарбол із бінарними файлами та ридмеєм, люди зрозуміють, як його встановити. Крім того, ви можете пропустити всю упаковку і просто опублікувати один тарбол зі скриптом bash або perl, щоб зробити інсталяцію.

Що стосується того, як звертатися до користувачів на ваших форумах, які скаржаться, як сказав Джо Інтернет, вони можуть бути просто відсотком людей, які збираються скаржитися, незважаючи ні на що, але перше, що я повинен зробити, це спробувати пояснити, що у вас є велика кількість застарілого коду, який не був розроблений з урахуванням підтримки на платформі. По-друге, чесно подивіться, чи не вдасться це зробити фінансовою підтримкою для створення порту Linux, і будьте відкриті до результатів цього. Нарешті, якщо порт не є фінансово здійсненним, погляньте на те, щоб виконати певну роботу, щоб програма добре працювала з WINE. WINE не повинен бути першим рішенням, але це може спричинити загрозу для людей, які просто хочуть використовувати ваш додаток в Linux, і бути менш дорогим проектом, ніж повний порт. Насправді, якщо ви додасте код до кодової бази WINE як частина проекту, ви не тільки зможете відкрити себе на новий ринок,

Adobe, це ти?

Однак, якщо серйозно, виставляйте якусь нагороду, щоб вони могли замовляти версії Linux. Якщо ви отримаєте достатню кількість замовлень, щоб зробити порт вартим його вчасно, інакше поверніть їх, і тепер у вас є доказ недостатньої кількості людей, які турбуються, щоб зробити його вартим.

Якщо ви щось перенесли, просто націліть на останню версію Ubuntu LTS, RHEL, SLED та, можливо, надайте tar.gz, люди можуть спробувати налагодити роботу, якщо хочуть використовувати щось інше. Це залишає вам три пакунки, і хтось ще, мабуть, знає достатньо, щоб отримати версію tar.gz.

написати кросплатформенний код C ++ не так просто

Зовсім навпаки. Коли ви плануєте роботу між платформами та надаєте абстракції для API, який ви використовуєте для певної платформи, переважна більшість вашого коду вже є кросплатформенною. Якщо ви вже використовуєте таку популярну бібліотеку, як Boost або Qt або NSPR, ви вже дуже близькі до створення робочої міжплатформової збірки.

Проблема, яка найчастіше виникає при виконанні порту в кінці циклу розробки, полягає в тому, що існують значні частини коду, які покладаються на API, орієнтовані на платформу, в частинах програми, які не повинні використовувати їх безпосередньо і, ймовірно, не повинні взагалі. (Хороший дизайн матиме сильно відокремлені модулі, і групи класів можуть бути замінені переписаними замінами за бажанням. Якщо це не стосується даного модуля, це сильний кодовий запах.)

Найпростіший вихід - це просто написати клас "Утиліта" і кинути все там, що стосується вашої платформи. Це не "легко і безболісно", але, безумовно, менш важко, ніж можна подумати.

підготовка багатьох пакетів дистрибуції та підтримка їх для всіх поширених версій Linux потребує часу

Це прикрою помилкою. Незважаючи на те, що підтримка збірок для декількох платформ вимагає додаткових зусиль (під час налаштування виділеного сервера щоденної збірки та навчання упаковки для певного дистрибутива), але неправда, що вам потрібно підтримувати їх для "великої кількості розповсюдження [s ]. " Зовсім навпаки. Вам потрібно підтримувати лише невелику кількість пакетів - скажімо, мабуть, Ubuntu, Fedora та один єдиний LSB-сумісний тарбол - і різні спільноти Linux візьмуть на себе всю роботу. Особливо, якщо ваше програмне забезпечення користується популярністю, HOWTO з'являться для кожного розповсюдження, надаючи необхідні інструкції з налаштування. Або якщо ваше програмне забезпечення можна вільно розповсюджувати (що ви можете зробити навіть якщо це не безкоштовний продукт, за умови, що це дозволяє вам ліцензування), більш популярні дистрибутиви матимуть якесь альтернативне сховище з копіями вашого програмного забезпечення.

Громади, як правило, дуже добре ставляться до цього, і досвідчені користувачі охоче зроблять багато цієї роботи для вас, якщо ви дозволите їм.

ми вважаємо, що ринок Linux - це на зразок 5-15% усіх користувачів, і ці користувачі, ймовірно, не захочуть платити за наші зусилля

Ще одне прикро, і дуже помиляється уявлення.

Просто те, що користувачі Linux отримують свою операційну систему безкоштовно, не означає, що вони не бажають платити за програмне забезпечення. Якщо програмне забезпечення дуже гарне і існує широкий попит на нього, користувачі Linux часто будуть більш готові розлучитися зі своїми грошима , ніж користувачі Windows , будуть. Подивіться лише на Humble Indie Bundles , де користувачі Linux в середньому платили більше вдвічі більше за користувача, порівняно з користувачами Windows.

Можливо також, що ваш продукт може користуватися більшим попитом серед користувачів Linux, ніж на інших платформах (що ми не можемо знати, не знаючи про ваш продукт), залежно від того, який тип наявного програмного забезпечення є на цій арені. У вас може бути більший потенціал ринку, ніж ви усвідомлюєте.

Маючи таке ставлення, я б просто їх ігнорував. Вони звучать як сегмент X, де X може бути чим завгодно , на що скаржишся , що б ти не робив. Випустіть версію Linux чи ні, це ваш вибір, а не їхній.

Якщо ви працюєте в Nvidia ...

Для любові до Бога, висмоктуй це і напиши вже пристойних водіїв.

В іншому випадку, якщо ви робите звичайні бізнес-програми, націліть майбутні проекти на запуск C #.

Mono повністю сумісний з .NET 3.5 і навіть може використовувати графічний інтерфейс winforms. Єдині модулі, на які потрібно стежити, - це конкретні ОС, але їх небагато та між ними.