보편적으로 크로스 플랫폼 C ++ 코드를 작성하고 모든 OS에 제품을 제공하는 것이 쉽지 않다고 설명하는 방법은 무엇입니까?


15

우리 회사는 다양한 Windows 용 데스크탑 제품을 제공하고 있으며 많은 Linux 사용자가 포럼에서 Linux 버전의 제품 버전을 작성 했어야한다고 주장하며 그 이유는 다음과 같습니다.

  • 우리는 탐욕스러운 기업입니다
  • 우리의 모든 기술 전문가는 자격을 갖춘 바보입니다

우리의 평균 제품은 3 백만 줄의 C ++ 코드와 같습니다.

나와 동료 분석은 다음과 같습니다.

  • 크로스 플랫폼 C ++ 코드 작성은 쉽지 않습니다
  • 많은 배포 패키지를 준비하고 모든 Linux 버전에서 유지 관리하는 데 시간이 걸립니다.
  • 우리의 추정치는 리눅스 시장은 모든 사용자의 5-15 %와 같으며 그 사용자는 우리의 노력에 대해 지불하기를 원하지 않을 것입니다

이것이 제기되면 우리는 욕심이 부족한 바보이며 모든 것이 올바르게 끝나면 모든 것이 쉽고 고통스럽지 않다는 반응이 다시 나타납니다.

크로스 플랫폼 코드를 작성하고 수많은 배포 패키지를 유지 관리한다는 사실에 대한 평가는 얼마나 합리적입니까? 실제로 얼마나 많은 노력이 필요한지 의심 할 여지없이 실제 이야기를 통해 쉽고 상세하게 분석 할 수있는 곳은 어디입니까?


3
WINE을 타겟팅하고 완료했다고 선언하지 않겠습니까?
btilly

1
@btilly : 이미 WINE에서 작동하지만 WINE이 올바르지 않습니다 .
sharptooth

2
WINE은 많은 경우에 고통이며, 응용 프로그램이 무엇인지에 따라 일반적으로 기본 응용 프로그램만큼 성능이 떨어지거나 예쁘지 않습니다. 광대 한 세상에서 예쁘게 보이는 기본 Linux 앱을 만드는 것은 Linux 자체의 작업입니다.
Matthew Scharley

4
"리눅스 사용자는 지불하고 싶지 않다"는 잘못된 가정이라고 생각합니다. 최종 사용자의 경우 아마도 저작권에 더 관심이 있고 다른 많은 사람들처럼 불법 복제 된 Windows 사본을 사용하지는 않습니다.
ziggystar

3
증오가 싫어. 포럼에서 위너들에 대한 유일한 대답은 (a) 무시하거나 (b) 그들에게 다가 가서 얼굴을 정사각형으로 치는 것입니다. (a) 일반적으로 훨씬 더 실용적입니다.
Tom Anderson

답변:


8

대부분의 사람들은 직원이므로 이익 창출에 관심이있는 세상에 살지 마십시오. 그들은 직장에 나타나고, 일을하고, 집에 가고, 전체 과정이 어떻게 작동하는지 전혀 생각하지 않습니다. 그리고 매우 똑똑하지만 많은 기술자들은 사업에 대해 긍정적으로 무지하며 종종 교리에 의해 눈을 멀게합니다.

물론 그 규모의 x- 플랫폼 소프트웨어를 만드는 것은 간단한 일이 아닙니다. 특히 수십 명의 개발자와 수백만 명의 사용자가있는 회사가 아닌 경우. 그리고 기술적 한계 만이 아닙니다. 비용 대 이익에 관한 모든 것. 예, 내년에 앱을 Linux로 이식하는 데 소비 할 수 있습니다 (물론 WINE에서 이미 실행 가능함). 물론 그 해의 개발 시간은 자유 로워지지 않습니다. 그리고 결국, 당신을 그물 것 어쩌면추가 5-15 %의 사용자 (추정치 기준) 또는 동일한 비용 / 노력을 취하여 새 버전으로 Windows 개발에 집중하거나 마케팅에 모두 적용하고 사용자 기반에 50 %를 추가 할 수 있습니다. 현명한 선택처럼 들리는 것은 무엇입니까? (물론 숫자는 회사에 맞게 사용자 정의해야하며 최종 결과는 이식을 선호 할 수 있습니다).

그것이 '진정한 신자들'을 설득하는데 도움이 될지 모르겠지만, 현명한 사업은 움직입니다. 그리고 현명한 비즈니스 움직임을하지 않으면 비즈니스에서 벗어난 것입니다. 그리고 확실히 리눅스 버전은 없을 것입니다.


16

여기에 고려해야 할 두 가지 사항이 있습니다.

첫 번째는 어떤면에서는 그들이 옳다는 것입니다. 크로스 플랫폼 C ++를 작성 하는 것은 처음부터 계획했다면 그렇게 어렵지 않습니다 . 이것은 당신이보고있는 거의 확실하게 문제입니다. 대부분의 오픈 소스 응용 프로그램 (일반적으로 Linux 사용자가 평균 하루에 사용하는 응용 프로그램)은 플랫폼에 상관없이 터무니 없습니다. 일반적인 Linux 사용자가 매일 C 또는 C ++로 작성하고 Windows 및 Linux뿐만 아니라 x86, x86-64, ARM, SPARC, MacOS, BSD, Solaris 등에서 실행되는 응용 프로그램의 수를 생각하십시오. 이것은 부분적으로 가려움증이있는 사람들이 시스템에서 실행할 코드를 긁기 위해 가려움증이 있기 때문에, 또한 플랫폼 간 이식성을 계획하는 규칙이기 때문입니다.

두 번째는 시장이 생각보다 실행 가능하다는 것입니다. Linux 사용자가 소프트웨어 비용을 지불하고 싶지 않다는 오해가 있습니다. 어떤 사람들에게는 맞을지 모르지만 리눅스를 사용하는 사람들이 많으며 (대부분은 생각합니다) 가격 때문에가 아니라 Linux를 더 잘 사용하기 때문에 Linux를 선호합니다. 또한 회사에서 주로 전문적인 환경에서 사용되는 제품을 생산하는 경우 회사는 Linux 시스템에서 실행할 소프트웨어 비용을 지불하는 데 익숙합니다.

다른 사람들이 말했듯이 패키징에 대한 요점은 실제로 최신 버전의 주요 배포판을 위해 패키지를 생산하면됩니다. 실제로 패키지를 만드는 것이 실제로 어려운 것은 아니며 대부분의 주요 배포판은 데비안 패키지 (데비안, 우분투 등) 또는 RPM (페도라, 수세, 센트, 맨드 라이크)을 사용하므로 일부 스크립트를 수정하는 것은 매우 미미합니다. 기본 .deb 및 기본 .rpm에서 여러 패키지를 생성하기 위해 바이너리 및 추가 정보가 포함 된 타르볼을 포기하는 사람들은 패키지 설치 방법을 알아낼 것입니다. 또는 모든 패키징을 건너 뛰고 bash 또는 perl 스크립트로 단일 tarball을 게시하여 설치를 수행 할 수 있습니다.

Joe Internet이 말했듯이 포럼에서 불만을 제기하는 사용자를 처리하는 방법은 무엇이든 관계없이 불만을 제기하는 사람들의 비율 일 수 있지만 가장 먼저 할 일은 귀하가 크로스 플랫폼 지원을 염두에두고 설계되지 않은 많은 양의 레거시 코드. 둘째, Linux 포트를 만들기 위해 재정적 지원을 할 것인지 솔직히 확인하고 그 결과를 공개하십시오. 마지막으로, 포트가 재정적으로 적합하지 않은 경우 WINE에서 프로그램이 제대로 작동하도록하기 위해 몇 가지 작업을 수행하십시오. WINE이 첫 번째 솔루션이되어서는 안되지만 Linux에서 앱을 사용하려는 사람들에게 큰 돈을주고 전체 포트보다 저렴한 프로젝트 일 수 있습니다. 실제로 프로젝트의 일부로 WINE 코드베이스에 코드를 추가하면 새로운 시장을 개척 할 수있을뿐만 아니라,


플랫폼 간 전달의 고통을 최소화함으로써 실제로 귀하의 답변이 잘못되었다고 생각합니다. 특히 이러한 플랫폼에서 상용 제품을 테스트 하는 문제를 언급하지 않았기 때문 입니다. 여러 플랫폼 을 지원 하는 비용에 대해서도 언급하지 않았습니다 .
davidbak

10

어도비, 너야?

진지하게, 어떤 종류의 현상금을 넣어서 Linux 버전을 선주문 할 수 있습니다. 당신이 시간에 넣어 포트 가치를 만들기 위해 충분한 주문을받을 경우, 그렇지 않으면 그들을 환불하고 당신은 이제 사람들이 가치가 있다고 신경 쓰지 않는다는 증거가 있습니다.

포팅 된 것이 있다면 최신 Ubuntu LTS 릴리스 인 RHEL, SLED를 대상으로하고 다른 것을 사용하려는 경우 tar.gz 사용자가 작업을 시도 할 수 있도록하십시오. 그러면 걱정할 3 가지 패키지가 남게되며 다른 사람은 tar.gz 버전을 사용할 수있을만큼 충분히 알고있을 것입니다.


많은 회사들이 바이너리 만 배포하기를 원하기 때문에 .tar.gz 방법은 아마도 불가능할 것입니다.
David Thornley

4
@David Thornley : tarball이기 때문에 소스 패키지 여야한다는 의미는 아닙니다. 관련 바이너리, 문서 및 README 파일을 tarball로 패키징 한 다음 바이너리와 라이브러리를 설치하고 앱이 작동하도록 시스템 구성을 수행 할 수 있습니다.
Cercerilla

5

크로스 플랫폼 C ++ 코드 작성은 쉽지 않습니다

꽤 대조적 인 것. 크로스 플랫폼 작업을 계획하고 사용하는 플랫폼 별 API에 대한 추상화를 제공 할 때 대부분의 코드는 이미 크로스 플랫폼입니다. Boost, Qt 또는 NSPR과 같은 인기있는 라이브러리를 이미 사용하고 있다면 이미 크로스 플랫폼 빌드가 작동하고 있습니다.

개발주기 후반에 포트를 수행 할 때 가장 일반적으로 발생하는 문제는 직접 사용할 필요가없고 전혀 사용하지 않아야하는 프로그램의 일부에 플랫폼 별 API에 의존하는 코드의 상당 부분이 있다는 것입니다. (좋은 디자인은 모듈을 강력하게 분리 할 것이며, 클래스 그룹은 마음대로 재 작성된 교체로 교체 할 수 있습니다. 주어진 모듈의 경우가 아니라면 코드 냄새가 강합니다.)

쉬운 방법은 종종 "유틸리티"클래스를 작성하고 그 안에 모든 플랫폼 관련 항목을 던지는 것입니다. "쉽고 고통스럽지 않지만"생각보다 덜 어렵습니다.

많은 배포 패키지를 준비하고 모든 Linux 버전에서 유지 관리하는 데 시간이 걸립니다.

이것은 불행한 오해입니다. 여러 플랫폼에 대한 빌드를 유지하려면 추가 일일 노력이 필요하지만 (일부 전용 빌드 서버를 설정하고 특정 배포판을 패키징하는 방법을 배우는 데) 많은 배포를 위해이를 유지해야하는 것은 아닙니다. ]. " 꽤 대조적 인 것. 우분투, 페도라, 그리고 단일 LSB 호환 타르볼과 같은 소량의 패키지 만 유지하면되며 다양한 Linux 커뮤니티가 나머지 작업을 수행하게됩니다. 특히 소프트웨어가 널리 사용되는 경우, 배포판마다 HOWTO가 생성되어 필요한 설정 지침을 제공합니다. 또는 소프트웨어를 자유롭게 배포 할 수있는 경우 (무료 제품아니더라도 할 수 있음)라이센스가 허용하는 한) 인기있는 배포판에는 소프트웨어 사본을 운반하는 대체 저장소가 있습니다.

커뮤니티는 일반적으로 이에 대해 매우 우수하며 숙련 된 사용자는이 레거시를 기꺼이 많이 할 것입니다.

우리의 추정치는 리눅스 시장은 모든 사용자의 5-15 %와 같으며 그 사용자는 우리의 노력에 대해 지불하기를 원하지 않을 것입니다

또 다른 불행한, 매우 잘못된 오해.

Linux 사용자가 운영 체제를 무료로 사용한다고해서 소프트웨어 비용을 지불하지 않으려는 것은 아닙니다. 소프트웨어가 매우 우수하고 수요가 많을 경우, Linux 사용자는 종종 Windows 사용자보다 돈을 더 많이 기꺼이 사용합니다. Linux 사용자가 평균적 으로 Windows 사용자에 비해 사용자 당 두 배 이상을 지불 하는 Humble Indie Bundle을 살펴보십시오 .

또한 해당 분야에 존재하는 기존 소프트웨어의 종류에 따라 다른 플랫폼 (제품을 모른 채 알 수없는)보다 Linux 사용자에게 더 많은 수요가있을 수 있습니다. 당신은 당신이 알고있는 것보다 더 큰 잠재 시장을 가질 수 있습니다.


4

그런 태도로, 나는 그들을 무시할 것입니다. 그것들은 X의 세그먼트처럼 들립니다. 여기서 X는 무엇이든 될 수 있습니다 . Linux 버전을 출시하거나 선택하지 마십시오.


1

엔비디아에서 일한다면 ...

신의 사랑을 위해 그것을 빨아 들이고 이미 괜찮은 운전자를 작성하십시오.

그렇지 않으면 정기적 인 비즈니스 응용 프로그램을 수행하는 경우 향후 프로젝트를 C #에서 실행할 대상으로 지정하십시오.

Mono는 .NET 3.5까지 완벽하게 호환되며 winforms GUI를 사용할 수도 있습니다. 주의해야 할 유일한 모듈은 OS 특정 모듈이지만 그 사이에는 거의 없습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.