Hạn chế kích thước cụm với mô-đun nguồn đóng trong chương trình nguồn mở


10

Tôi làm việc trong một viện nghiên cứu học thuật phụ thuộc rất nhiều vào điện toán hiệu năng cao. Trong 10 năm, chúng tôi đã phát triển mã Fortran của riêng mình, được đánh giá rất tốt và có thể chạy trên các cụm rất lớn. Để có được cộng đồng nghiên cứu lớn hơn được hưởng lợi từ mã, chúng tôi đang xem xét biến nó thành nguồn mở. Tuy nhiên, vì kinh phí của chúng tôi phụ thuộc rất nhiều vào nghiên cứu mà chúng tôi có thể thực hiện với mã, chúng tôi sẽ tự bắn vào chân mình.

Một trong những ý tưởng là giới hạn số lượng CPU mà mã có thể chạy, ví dụ: tối đa 1000 CPU thay vì 100.000 chúng tôi sử dụng. Bằng cách đó, cộng đồng nghiên cứu toàn cầu có thể hưởng lợi từ mã, nhưng chúng ta sẽ có lợi thế về quy mô của các vấn đề chúng ta có thể chạy.

Là một tính năng như vậy về mặt khái niệm có thể? Và làm thế nào một tính năng như vậy có thể được thực hiện? Về cơ bản, chúng tôi muốn mã nguồn mở hoàn chỉnh, nhưng giới hạn việc song song hóa (sử dụng MPI) cho một số luồng MPI cố định, ví dụ như sử dụng mô-đun (nguồn đóng).


Chính xác thì mô-đun nguồn đóng đó sẽ làm gì? Làm thế nào khó khăn cho người khác để thực hiện lại nó?
Svick

Câu trả lời:


16

Bạn đang cố gắng để cho cộng đồng nghiên cứu được hưởng lợi bằng cách họ có thể làm những gì bạn làm, mà không cần họ có thể làm những gì bạn làm. Nghe có vẻ như bạn chưa thực sự lựa chọn nguyên tắc nào.

Các giải pháp phần mềm như thế trong phần mềm nguồn mở không có khả năng hoạt động: xét cho cùng, mã là nguồn mở. Điều đầu tiên mà các tổ chức khác sẽ làm là tách ra bit nguồn đóng, thay thế nó bằng một bit nguồn mở mà không có giới hạn như vậy, và sau đó mọi người sẽ sử dụng nó.

thể có một thỏa hiệp có thể: không mở phần mềm, nhưng bán giấy phép. Các tổ chức có giấy phép cũng có quyền đọc và sửa đổi mã, nhưng không được phân phối nó. Phí trên cơ sở hàng năm. Bằng cách đó, bạn có thể bù đắp cho sự mất mát tài trợ bằng cách lấy một số của họ.

Một tùy chọn khác là phát hành một phiên bản cũ hơn, mà bạn luôn cập nhật nhưng luôn bị tụt lại sau một số năm. Tuy nhiên, một cộng đồng nguồn mở có thể chiếm dự án và phát triển các tính năng mới nhanh hơn bạn (hoặc có thể không; hầu hết mọi người đánh giá quá cao sự quan tâm của người khác đối với phần mềm của họ).

Hoặc chỉ phát hành nó và sử dụng công việc người khác làm trên đó. Bạn sẽ luôn là chuyên gia hàng đầu về phần mềm.


4

Điều này thực sự không thể được thực hiện.

Ý tưởng đằng sau nguồn mở là nguồn mở , nói cách khác, mọi người sẽ có quyền truy cập vào nó. Từ Wikipedia :

Trong sản xuất và phát triển, nguồn mở như một mô hình phát triển thúc đẩy truy cập toàn cầu thông qua giấy phép miễn phí đối với thiết kế hoặc kế hoạch chi tiết của sản phẩm và phân phối lại toàn bộ thiết kế hoặc kế hoạch chi tiết đó, bao gồm cả những cải tiến tiếp theo cho bất kỳ ai.

Bằng cách cung cấp quyền truy cập chung vào thiết kế hoặc kế hoạch chi tiết, ngay cả khi phiên bản phát hành chỉ giới hạn ở 1000 lõi, sẽ rất dễ dàng để thay đổi số đó thành 100000 hoặc một cái gì đó.


Dưới đây là một số tùy chọn về những gì bạn có thể làm thay thế:

  • Xem xét việc phát hành mã theo giấy phép hạn chế người dùng mã của bạn
  • Phát hành thư viện API nguồn đóng cho phép các nhà nghiên cứu khác có được chức năng của bạn mà không cần truy cập vào chính mã.

Chính xác. Nếu bạn đặt mã vào đó để nói "kiểm tra số lượng CPU và không sử dụng đúng hơn X của chúng" thì bất kỳ ai khác cũng có thể lướt qua nguồn mở của bạn, xóa kiểm tra đó và biên dịch lại.

4

Bạn có thể làm rất ít để hạn chế những gì người khác sẽ làm với mã nguồn của bạn. Họ có thể tạo ra một mô-đun khác từ đầu có thể mở khóa khả năng đa xử lý, hoặc thậm chí cải thiện nó: nó sẽ tốn thời gian và chuyên môn nhưng nếu nó quan trọng với họ, họ sẽ làm điều đó.

Với mười năm đầu, bạn vẫn có cơ hội sử dụng kinh nghiệm và kiến ​​thức về mã của mình để tiếp tục thực hiện nghiên cứu tốt nhất, ngay cả khi bạn cung cấp cho người khác mã nguồn cho phép họ sao chép thử nghiệm của bạn. Các nhà tài trợ của bạn thậm chí có thể có nhiều lý do hơn để tìm đến bạn, vì tác động nghiên cứu của bạn có thể lớn hơn nếu bạn là nhà lãnh đạo của một dự án nguồn mở được sử dụng tại một số trường đại học.

Thay vì nguồn mở, bạn có thể cố gắng hạn chế người khác một cách hợp pháp, bằng cách xuất bản nguồn của bạn nhưng đặt các hạn chế độc quyền trên giấy phép nguồn. Tôi có thể nghĩ về một số dự án đã thực hiện điều này: Ghostscript, AT & T Unix, Microsoft .NET và Xerox PARC Smalltalk-80. Mặc dù những cái đó cuối cùng đã đi đến nguồn mở hoàn toàn, tôi hy vọng rằng có những cái khác ít được biết đến hơn vẫn còn hạn chế về cách người được cấp phép sử dụng mã nguồn. Tất nhiên, trong khi xuất bản nguồn của bạn sẽ có nghĩa là những người ít tôn trọng luật pháp có thể vi phạm các điều khoản, điều đó sẽ khiến các nhà nghiên cứu hàn lâm không thể chạy mã của bạn trên các siêu máy tính mạnh như của bạn.



@musiKk Năm 2002, nhánh rẽ nhánh của lõi .NET khởi đầu là 'nguồn chia sẻ' độc quyền , nhưng phần lớn gần đây của nguồn thương mại đã được xuất bản theo giấy phép tham chiếu , và sau đó, tại phiên bản 4.6, nguồn mở hoàn toàn . Tôi đã không nhận ra sự sắp xếp chia sẻ nguồn của Microsoft phức tạp như thế nào .
dcorking 20/03/2015

1
Bạn thực sự làm trái tim tôi nhảy lên. Tôi nghĩ rằng tôi đã đào ra một câu trả lời 13 tuổi. Đừng bận tâm rằng SO đã được đưa ra vào năm 2008 ... Đủ công bằng rồi.
musiKk 20/03/2015
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.