Jak wyjaśnić, że pisanie uniwersalnego, wieloplatformowego kodu C ++ i produktów wysyłkowych dla wszystkich systemów operacyjnych nie jest takie łatwe?

Nasza firma dostarcza szereg produktów komputerowych dla systemu Windows, a wielu użytkowników Linuksa narzeka na forach, że wiele lat temu powinniśmy napisać wersje naszych produktów dla systemu Linux, a powodem, dla którego tego nie robimy, jest

• jesteśmy chciwą korporacją
• wszyscy nasi specjaliści techniczni są niedoświadczonymi idiotami

Nasz przeciętny produkt to około 3 miliony linii kodu C ++.

Analiza moja i moich kolegów jest następująca:

• pisanie wieloplatformowego kodu C ++ nie jest takie łatwe
• przygotowanie wielu pakietów dystrybucyjnych i utrzymanie ich dla wszystkich popularnych wersji Linuksa zajmuje dużo czasu
• szacujemy, że rynek Linuksa stanowi około 5-15% wszystkich użytkowników i ci użytkownicy prawdopodobnie nie będą chcieli płacić za nasz wysiłek

kiedy się o tym wspomina, ponownie pojawia się odpowiedź, że jesteśmy chciwymi niedoszacowanymi idiotami i że kiedy wszystko jest zrobione dobrze, wszystko jest łatwe i bezbolesne.

Jak rozsądne są nasze oceny faktu, że pisanie kodu między platformami i utrzymywanie licznych pakietów dystrybucji wymaga dużego wysiłku? Gdzie możemy znaleźć łatwą, ale szczegółową analizę z historiami z prawdziwego życia, które pokazują bez cienia wątpliwości, jaki dokładnie wysiłek wymaga?

Pamiętaj, że większość ludzi to pracownicy, dlatego nie żyją w świecie, w którym muszą dbać o zysk. Pojawiają się w pracy, robią swoje i idą do domu, nigdy tak naprawdę nie zastanawiając się, jak działa cały proces. I choć są bardzo inteligentni, wielu techników jest pozytywnie ignorantami na temat biznesu i często jest zaślepionych przez dogmaty.

Oczywiście masz rację, tworzenie oprogramowania X-platform o takiej skali nie jest prostą sprawą. Zwłaszcza, gdy nie jesteś firmą, która ma dziesiątki programistów i miliony użytkowników. I to nie tylko ograniczenia techniczne. Chodzi przede wszystkim o koszt w porównaniu do korzyści. Tak, mógłby wydać w przyszłym roku, a następnie przenoszenie aplikacji do Linuksa (mimo, jak można zauważyć, że już runable winem). Oczywiście ten rok rozwoju nie przychodzi za darmo. I w końcu może cię zarobićdodatkowe 5-15% użytkowników (na podstawie szacunków). Lub możesz podjąć te same pieniądze / wysiłek i skoncentrować się na rozwoju systemu Windows jako nowej wersji, lub umieścić to wszystko w marketingu i dodać 50% do bazy użytkowników. Który brzmi jak mądry wybór? (oczywiście liczby muszą być dostosowane do Twojej firmy, a ostateczny wynik może sprzyjać przeniesieniu).

Nie wiem, czy to pomoże przekonać „prawdziwych wierzących”, ale jest to mądry ruch biznesowy. A jeśli nie wykonasz sprytnych ruchów biznesowych, nie będziesz miał interesu. A potem na pewno nie będzie wersji Linux.

Myślę, że należy rozważyć dwie rzeczy:

Po pierwsze, w pewnym sensie mają rację. Pisanie między platformami C ++ nie jest trudne, jeśli planujesz to od samego początku . To prawie na pewno problem, który widzisz. Większość aplikacji typu open source (większość aplikacji, które użytkownik Linuksa dotyka przeciętnego dnia), jest absurdalnie wieloplatformowa. Pomyśl o liczbie aplikacji, z którymi przeciętny użytkownik Linuksa wchodzi w interakcję na co dzień, które są napisane w C lub C ++ i działają nie tylko na Windowsie i Linuksie, ale także na MacOS, BSD, Solaris itp. Na x86, x86-64, ARM, SPARC, itd. Jest to częściowo spowodowane tym, że ludzie, którzy mają ochotę podrapać port, uruchamiają kod w swoich systemach, ale także dlatego, że wtedy konwencja polega na planowaniu przenośności między platformami.

Po drugie, rynek może być bardziej opłacalny niż myślisz. Istnieje ogromne nieporozumienie, że ludzie w Linuksie nie chcą płacić za oprogramowanie. Dla niektórych osób może to być prawda, ale jest wiele osób (większość, jak sądzę), które używają Linuksa, ponieważ działa dla nich lepiej i wolą, nie ze względu na cenę. Ponadto, jeśli twoja firma produkuje produkt, który jest używany głównie w środowisku profesjonalnym, firmy są dobrze przyzwyczajone do płacenia za oprogramowanie do działania na systemach Linux.

Jeśli chodzi o kwestię pakowania, tak jak mówili inni, naprawdę wystarczy wyprodukować paczki dla najnowszej wersji głównych dystrybucji. W rzeczywistości tworzenie pakietów nie jest wcale takie trudne, a większość głównych dystrybucji używa pakietów Debiana (debian, ubuntu itp.) Lub RPM (fedora, suse, centos, mandrake), więc modyfikacja niektórych skryptów jest bardzo niewielka aby stworzyć wiele pakietów z podstawowego pliku .deb i podstawowego pliku .rpm, a dla wszystkich innych po prostu wyrzuć plik tar z binariami i plikiem readme, ludzie wymyślą, jak go zainstalować. Alternatywnie, możesz pominąć całe pakowanie i po prostu opublikować jeden plik archiwum ze skryptem bash lub perl, aby wykonać instalację.

Jeśli chodzi o to, w jaki sposób zwracać się do użytkowników na twoich forach, którzy narzekają, jak powiedział Joe Internet, może to być tylko odsetek ludzi, którzy będą narzekać, bez względu na wszystko, ale najpierw postaram się wyjaśnić, że masz duża ilość starszego kodu, który nie został zaprojektowany z myślą o obsłudze wielu platform. Po drugie, szczerze sprawdź, czy byłoby to wsparcie finansowe, aby stworzyć port Linux, i bądź otwarty na wyniki. Wreszcie, jeśli port nie jest wykonalny finansowo, zobacz, jak wykonać pewne prace, aby program działał dobrze z WINE. WINE nie powinno być pierwszym rozwiązaniem, ale może równie dobrze ułagodzić ludzi, którzy po prostu chcą korzystać z Twojej aplikacji w systemie Linux, i być tańszym projektem niż pełny port. W rzeczywistości, jeśli dodasz kod do bazy kodów WINE w ramach projektu, nie tylko możesz otworzyć się na nowy rynek,

Adobe, czy to ty?

Poważnie, jednak wystawcie nagrodę, aby mogli wstępnie zamówić wersje dla systemu Linux. Jeśli dostaniesz wystarczającą liczbę zamówień, aby uczynić port wartym poświęcenia czasu, w przeciwnym razie zwróć je, a teraz masz dowód, że nie ma wystarczającej liczby ludzi, aby warto.

Jeśli jednak coś zostanie przeniesione, po prostu celuj w najnowszą wersję Ubuntu LTS, RHEL, SLED, a być może udostępnisz plik tar.gz, który ludzie mogą spróbować uruchomić, jeśli chcą użyć czegoś innego. To daje ci 3 pakiety do zmartwienia, a każdy inny prawdopodobnie wie wystarczająco dużo, aby uruchomić wersję tar.gz.

pisanie wieloplatformowego kodu C ++ nie jest takie łatwe

Wręcz przeciwnie. Kiedy planujesz pracę na wielu platformach i udostępniasz abstrakty dla interfejsów API specyficznych dla platformy, których używasz, zdecydowana większość kodu jest już na różnych platformach. Jeśli korzystasz już z popularnej biblioteki, takiej jak Boost, Qt lub NSPR, jesteś już bardzo blisko posiadania działającej wersji na wiele platform.

Problem najczęściej spotykany podczas wykonywania portu na późnym etapie cyklu programowania polega na tym, że istnieją znaczące części kodu oparte na interfejsach API specyficznych dla platformy w częściach programu, które nie muszą ich używać bezpośrednio i prawdopodobnie nie powinny. (Dobry projekt będzie miał silnie odsprzężone moduły, a grupy klas można dowolnie wymieniać z przepisanymi zamiennikami. Jeśli tak nie jest w przypadku danego modułu, jest to silny zapach kodu).

Łatwym wyjściem jest często napisanie klasy „Utility” i wrzucenie tam wszystkich rzeczy związanych z platformą. Nie jest to „łatwe i bezbolesne”, ale z pewnością mniej trudne, niż mogłoby się wydawać.

przygotowanie wielu pakietów dystrybucyjnych i utrzymanie ich dla wszystkich popularnych wersji Linuksa zajmuje dużo czasu

To niefortunne nieporozumienie. Chociaż prawdą jest, że utrzymywanie kompilacji dla wielu platform wymaga dodatkowego wysiłku (w konfigurowaniu dedykowanego codziennego serwera kompilacji i uczenia się, jak pakować dla określonej dystrybucji), nie jest prawdą, że trzeba je utrzymywać dla „dużej liczby dystrybucji [s ]. ” Wręcz przeciwnie. Potrzebujesz tylko niewielkiej garści pakietów - powiedzmy być może Ubuntu, Fedora i jednego tarballa kompatybilnego z LSB - a różne społeczności Linuksa zajmą się resztą pracy. Zwłaszcza jeśli twoje oprogramowanie jest popularne, HOWTO pojawią się przy każdej dystrybucji, dostarczając niezbędnych instrukcji konfiguracji. Lub, jeśli twoje oprogramowanie może być swobodnie dystrybuowane (co możesz zrobić, nawet jeśli nie jest to darmowy produkt, pod warunkiem, że zezwala na to licencja), bardziej popularne dystrybucje będą miały alternatywne repozytorium zawierające kopie oprogramowania.

Społeczności są na ogół bardzo dobre w tym względzie, a doświadczeni użytkownicy chętnie wykonają za Ciebie dużo pracy, jeśli im na to pozwolisz.

szacujemy, że rynek Linuksa stanowi około 5-15% wszystkich użytkowników i ci użytkownicy prawdopodobnie nie będą chcieli płacić za nasz wysiłek

Kolejne niefortunne i bardzo błędne nieporozumienie.

To, że użytkownicy Linuksa otrzymują system operacyjny za darmo, nie oznacza, że ​​nie chcą płacić za oprogramowanie. Jeśli oprogramowanie jest bardzo dobre i istnieje duże zapotrzebowanie na niego, użytkownicy Linuksa będą często bardziej skłonni do dzielenia się pieniędzmi niż użytkownicy Windowsa. Wystarczy spojrzeć na Humble Indie Bundles , w których użytkownicy Linuksa płacili średnio ponad dwa razy więcej za użytkownika niż w systemie Windows.

Możliwe jest również, że Twój produkt może mieć większe zapotrzebowanie wśród użytkowników Linuksa niż na innych platformach (których nie wiemy bez znajomości Twojego produktu), w zależności od tego, jakie oprogramowanie istnieje na tej arenie. Możesz mieć większy potencjalny rynek, niż ci się wydaje.

Przy takich postawach po prostu zignorowałbym je. Brzmią jak segment X, gdzie X może być czymkolwiek , co narzeka bez względu na to, co robisz. Wypuść wersję Linuksa lub nie, to twój wybór, nie ich.

Jeśli pracujesz dla Nvidii ...

Na miłość boską, zrób to i napisz już porządnych kierowców.

W przeciwnym razie, jeśli robisz zwykłe aplikacje biznesowe, kieruj przyszłe projekty na C #.

Mono jest w pełni zgodny z .NET 3.5 i może nawet korzystać z GUI WinForm. Jedynymi modułami, na które musisz uważać, są te specyficzne dla systemu operacyjnego, ale jest ich niewiele i są bardzo odległe.