Đóng góp kernel đầu tiên của tôi bị đánh cắp
(ariel-miculas.github.io)- Ariel Miculas đã lần theo sự cố debug đa luồng bằng gdbserver bị hỏng trên PowerPC32 và tìm ra một lỗi hỏng bộ nhớ trong Linux kernel, nhưng bản sửa cuối cùng được đưa vào dưới dạng một patch riêng của maintainer và anh chỉ nhận được credit
Reported-by - Manh mối là một thread email cũ nói về cùng triệu chứng và commit thay đổi vị trí
thread_struct threadtrongtask_struct; một số thread bị kẹt ở trạng thái tiến trình sai, khiến gdbserver mất quyền điều khiển - Việc phân tích nguyên nhân sử dụng
pahole, ftrace và hardware breakpoint dựa trên DABR của PowerPC; qua đó xác nhận buffer overflow trongptrace_put_fprghi đè các trường nhưtask_struct.__state - Overflow xảy ra do áp dụng chỉ số dành cho phần tử 32-bit lên mảng 64-bit; phía người dùng là gdbserver có thể ghi vượt ra sau mảng
fp_state.fprvốn chỉ có 32 mục tới tối đa 256 byte - Maintainer PowerPC Michael Ellerman đã áp dụng bản sửa của riêng mình; các phản hồi sau đó có lời xin lỗi rằng chỉ gắn
Reported-bylà chưa phản ánh đúng đóng góp và lẽ ra nên cùng phát triển patch
Debug bằng gdbserver bị hỏng trên PowerPC32
- Khoảng một năm rưỡi trước, Ariel Miculas đã xin thời gian tại công ty cũ để điều tra một vấn đề đang chặn tính năng debug của dự án
- Vấn đề là gdbserver không thể debug đúng các ứng dụng đa luồng trên kiến trúc PowerPC32
- Kết nối gdbserver bị ngắt và không thể tiếp tục điều khiển phiên debug
- Không chắc nguyên nhân nằm ở toolchain, gdbserver, Linux kernel hay các patch kernel tùy biến
- Sau khi điều tra và tìm kiếm các thông tin có sẵn, anh tìm thấy một thread email nói về cùng triệu chứng
- Thread này cũng chỉ ra commit gây ra vấn đề
- Patch đó là thay đổi chuyển định nghĩa
thread_struct threadtừ giữatask_structxuống cuối
Manh mối thu hẹp từ trạng thái thread đến hỏng bộ nhớ
- Theo phân tích trước đó của Holger Brunck, gdbserver gửi
SIGSTOPtới kernel cho từng thread và chờ phản hồi, nhưng trong tình huống lỗi, kernel chỉ phản hồi một phần tín hiệu - Ở mức thấp hơn, sau khi tương tác với gdbserver, một số thread rơi vào trạng thái tiến trình sai và gdbserver sau đó mất quyền điều khiển
- Ariel đọc mô tả các commit liên quan đến PowerPC và các thay đổi quanh
task_structtrong 3–4 ngày để kiểm tra liệu vấn đề đã được giải quyết ở các phiên bản kernel sau hay chưa, nhưng không tìm thấy giải pháp - Anh thay đổi vị trí của
thread_struct threadđể kiểm tra điều kiện tái hiện, và dùng pahole để xem layout củatask_struct - Dùng ftrace để theo dõi khi nào các thread của tiến trình đang debug được schedule
- Các thread bị treo chỉ được schedule một lần, khác với các thread khác
- Quan sát này khiến anh xem xét lại khả năng hỏng bộ nhớ
Nguyên nhân thực sự được tìm ra bằng hardware breakpoint
- Anh xác nhận rằng PowerPC cũng có tính năng tương tự debug registers của x86 thông qua DABR register
- Sau khi tìm hiểu cách dùng hardware breakpoint trên Linux, anh triển khai một kernel module dựa trên câu trả lời trên Stack Overflow
- Với module này, anh đặt hardware breakpoint trên trường
task_struct.__stateđể truy vết ai ghi giá trị vào đó - Kernel module tùy biến hiển thị stack trace của vị trí ghi vào
task_struct.__state, trong đó một đường dẫn bất thường dẫn tới buffer overflow trongptrace_put_fpr ptrace_put_fprđược dùng trong POKEUSER API, và overflow ghi đè các trường quan trọng củatask_structnhư__state__statelưu trạng thái tiến trình- Kernel cũng dùng trường này khi theo dõi các tiến trình bị debugger dừng lại
Ghi mảng có thể vượt tới 256 byte
- Nguyên nhân overflow là một chỉ số được thiết kế để dùng với mảng phần tử 32-bit lại bị áp dụng cho mảng phần tử 64-bit
- Chỉ số trỏ tới FPR có 64 giá trị, và phạm vi truy cập tính theo phần tử 64-bit là
64 * 8 = 512byte - Trong thực tế, mảng
fp_state.fprchỉ có 32 entry, nên bộ nhớ khả dụng là32 * 8 = 256byte - Kết quả là người dùng, tức gdbserver, có thể ghi vượt qua cuối mảng tới tối đa 256 byte
Gửi upstream và tranh cãi về credit
- Ariel cho rằng vấn đề hỏng bộ nhớ có thể ghi đè bộ nhớ trạng thái tiến trình có thể có tác động bảo mật, nên đã gửi patch tới
security@kernel.org- Mailing list này là riêng tư nên không thể liên kết tới patch đã gửi ban đầu
- Maintainer PowerPC Michael Ellerman liên hệ riêng và trả lời rằng ông sẽ xử lý vấn đề
- Ariel gửi hai patch sửa lỗi
- Patch ban đầu gửi tới mailing list bảo mật
- Một phiên bản patch khác phản ánh các đề xuất cho bản gửi ban đầu
- Patch thứ hai dựa trên mã kernel hiện có dùng để mô phỏng hành vi PowerPC32 trên PowerPC64, và mã đó xử lý đúng việc đánh chỉ số FPR
- Michael Ellerman không chấp nhận cả hai patch mà tự triển khai bản sửa riêng
- Ariel muốn patch của mình được chấp nhận để được ghi nhận công lao sửa vấn đề này và trở thành người đóng góp kernel lần đầu; anh cũng sẵn sàng gửi phiên bản tiếp theo dựa trên feedback
- Credit thực tế nhận được chỉ là tag
Reported-by, và Ariel cảm thấy điều đó không công bằng so với công sức bỏ ra cho phân tích nguyên nhân, sửa lỗi, kiểm thử, xác minh, phản ánh feedback nội bộ và áp dụng lên kernel mới nhất- Theo tài liệu Linux,
Reported-bylà tag ghi nhận người tìm và báo cáo bug - Vấn đề này thực ra đã từng được báo cáo 6 năm trước đó
- Theo tài liệu Linux,
Cập nhật và phản hồi xin lỗi
- Một người dùng Hacker News chỉ ra email trong đó Michael Ellerman viết: “Cảm ơn patch của bạn, nhưng tôi muốn sửa theo cách khác. Bạn có thể thử patch bên dưới và xác nhận liệu bug đã được sửa chưa không?”
- Email này cho thấy Michael Ellerman đã chọn tự triển khai thay vì review patch của Ariel, rồi yêu cầu Ariel kiểm thử patch đó
- Ariel tìm lại patch ban đầu đã gửi tới mailing list bảo mật và chuyển tiếp thread email sang linuxppc-dev
- Bản cập nhật sau đó bao gồm phản hồi xin lỗi về cách xử lý patch
- Nội dung có câu “Lẽ ra tôi nên dành nhiều thời gian hơn để cùng phát triển patch của bạn”
- Cũng có nội dung rằng tag
Reported-bykhông phản ánh đúng đóng góp của Ariel
1 bình luận
Ý kiến trên Hacker News
Dù không chấp nhận toàn bộ bản vá, việc ghi công cho Ariel Miculas vẫn sẽ phù hợp hơn
Vấn đề bảo mật này rất có thể sẽ không ai sửa nếu anh ấy không tìm ra và gửi bản sửa
Nếu Michael đọc bản vá của anh ấy, chỉ thay đổi một phần phong cách rồi gửi dưới tên mình, thì việc không ghi công là phi đạo đức; và dù mã có tệ đến đâu thì đó vẫn là một sự cộng tác, nên nếu bị đối xử như vậy tôi sẽ không muốn làm việc cùng nữa
Cách sau ít ra vẫn còn
Co-Authored-By, nhưng chỉ đến khi có người dump mã dự án của tôi vào kho riêng của họ mà không có lịch sử commit rồi gọi đó là “fork”, tôi mới nhận ra với tư cách người đóng góp thì đó là một trải nghiệm khá chua chátDù mã ban đầu có dở, bản sửa đã được refactor và merge sẽ không tồn tại nếu không có mã đó, và câu “phiên bản của tôi tốt hơn” có thể bị cảm nhận như một thái độ khá coi thường
Tuy nhiên, nhìn câu trả lời có liên kết đến phản hồi thực tế của maintainer thì câu cuối không còn đúng nữa
Nhưng trong trường hợp này, người viết bài gần với vai trò đồng tác giả của bản vá hơn
Nếu so với xuất bản học thuật, giống như bạn gửi preprint cho ai đó, rồi người đó xuất bản bài báo cùng chủ đề và chỉ đưa bạn vào lời cảm ơn chứ không đưa vào danh sách đồng tác giả
Ở đây không phải xuất bản mà là phát triển kernel, nhưng việc ghi tên tác giả vẫn quan trọng trong hồ sơ nghề nghiệp
Phản hồi về tính nhất quán của style và cấu trúc là cần thiết, nhưng một maintainer tốt là người ghi nhận công lao và âm thầm giúp mọi việc trôi chảy
Khi đó Ted Tso hài lòng với tính đúng đắn của phần tôi làm nên đã đưa bản vá vào, còn tôi không đòi hỏi cũng không nhận ghi công
Điều tôi quan tâm chỉ là cải thiện kernel, không phải để lại tên mình
Vài năm sau tên tôi cũng được đưa vào danh sách contributor vì việc khác, nhưng dù theo hướng nào tôi cũng không bận tâm
Reported-by: Ariel Miculas, và trông có vẻ chính xácBản vá của maintainer tốt hơn
fpidx < (PT_FPSCR - PT_FPR0)trong trường hợp 32-bit*data = child->thread.fp_state.fpscr;được dùng khifpidxnằm ngoài phạm vi trong hàmputFPRINDEXkhông cần thiết, vốn rút gọn thành đồng nhất thức khiTS_FPRWIDTHlà 1Thông điệp commit của bản vá ban đầu nói “trên PPC32 có thể giả định
TS_FPRWIDTHlà 1”, nhưng vẫn đưa vàoFPRNUMBER,FPRHALF,FPRINDEXChỉ vì tìm được một lỗi lệch mảng có thể sửa được không có nghĩa là phải chấp nhận nguyên xi một bản vá có lỗi
Tuy vậy, maintainer lẽ ra nên thừa nhận rằng Miculas không chỉ báo cáo đơn thuần, mà đã điều tra, tìm ra nguyên nhân gốc, và thậm chí tạo phiên bản sửa đơn giản gần như tương tự của riêng mình
Reported-bykhông chính xác nếu muốn truyền tải sắc thái rằng bên liên quan đã điều tra kỹ lưỡng và xác định được cả nguyên nhânVới người đóng góp mới, các dự án thường làm như vậy, và đó là cách đúng
Đó là quá trình dạy và giúp người ta thích nghi; nếu cứ tự làm lại công việc thì sẽ làm nản lòng người đóng góp và tước đi cơ hội học hỏi của họ
Viết phiên bản thứ hai bao giờ cũng dễ hơn
Gọi đây là một bản sửa đơn giản là không hiểu khối lượng công việc phải bỏ ra để sửa lỗi trong phát triển phần mềm
Ở đây Michael cũng thừa nhận ban đầu không tái hiện được và về sau mới xác nhận
Điều đó cho thấy rất rõ khối lượng công việc OP đã bỏ ra cho debug và sửa lỗi, và tước đi công lao đó là không đúng
Trong bài gốc, tác giả nói rằng mình muốn bản vá được chấp nhận để được ghi công và trở thành contributor của kernel, đồng thời sẵn sàng gửi phiên bản tiếp theo sau khi tiếp thu phản hồi
Maintainer chỉ cần checkout mã của OP, thực hiện các thay đổi mong muốn, rồi dành khoảng 2 phút cần thiết để commit với tư cách đồng tác giả
Như vậy bản sửa tốt nhất được merge và công sức của người khác cũng được ghi nhận
Đặc biệt vì OP đã nói rõ rằng mình muốn được ghi công, đó sẽ là cách tốt nhất
Dù vậy, có vẻ các maintainer kiểu này thường bỏ sót phép lịch sự xã hội, nên cũng không ngạc nhiên
PR thường không được chấp nhận vì nhiều lý do, nhưng tôi không bận tâm
Tôi gửi PR để công khai mã, chứ không dành thời gian làm cho nó “đủ tốt” để được merge
Cứ đưa ra đó, nếu ai đủ thích thì người đó xử lý quy trình
Có cái được merge nguyên trạng, có cái được chủ kho sửa một chút rồi merge
Tôi viết mã nguồn mở vì thích, không phải vì vinh quang hay độ nổi tiếng
Nhớ thập niên 80 và 90 quá
Kernel Linux không phải là phần thưởng, và dù cảm thông với OP, cộng đồng đúng khi ưu tiên một giải pháp dễ bảo trì hơn phiên bản đến từ OP
Vì vậy maintainer vẫn hành động trong phạm vi quyền hạn của mình
Tuy nhiên, việc ghi nhận công lao cho người đã góp phần vào bản sửa là rất dễ
Trong Node.js, chúng tôi ghi công trong release notes, và khi lấy một phần công việc từ PR rồi chỉnh sửa, chúng tôi cố gắng thêm
Co-Authored-By:Khi làm maintainer lâu năm, công trạng trở nên ít quan trọng hơn với bản thân, nên dễ quên rằng với người đóng góp mới, điều đó rất quan trọng
Trong trường hợp này, việc chia sẻ công lao vừa quan trọng với OP vừa là điều xứng đáng, nên việc không tinh tế hơn là một mất mát cho cả OP lẫn khu vực Linux đó
Đó không phải là cách để một dự án dựa vào nỗ lực của cộng đồng có thể bền vững
Với một dự án lớn và được tôn trọng như kernel Linux, tôi đã nghĩ sẽ có những người vừa biết lo cho lợi ích tốt nhất của dự án, vừa biết tôn trọng người đóng góp mới
Sẽ không ai nói rằng nên chấp nhận một giải pháp không tối ưu chỉ vì người đó là người đóng góp mới
Cách đúng là review patch, giải thích cái gì có vấn đề và vì sao, đề xuất nên viết lại thế nào, và nếu cần thì cùng viết phần đó để trở thành đồng tác giả
Làm vậy mới tạo được dòng người đóng góp tiếp tục quan tâm trong tương lai
Reported-ByTài liệu kernel định nghĩa
Suggested-bylà một trong các quy ước về tagTag
Suggested-by:cho biết ý tưởng của patch là do người đó đề xuất, và đảm bảo ghi công cho ý tưởng đóĐặc biệt, tài liệu nói rằng nếu ý tưởng đó không được đăng trên một diễn đàn công khai thì không nên thêm tag này khi chưa có sự cho phép của người đề xuất
Tài liệu cũng nêu ý rằng nếu ghi nhận công lao một cách thiện chí cho người báo ý tưởng, khả năng họ tiếp tục giúp đỡ trong tương lai sẽ cao hơn
Trong tình huống này,
Suggested-bycó thể đã phù hợp hơnNó truyền đạt tốt hơn rằng người đó đã tìm ra giải pháp cho vấn đề, nhưng vì chưa quen với dự án nên cú pháp chính xác của patch không được giữ nguyên
Tham khảo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Một bên đặt trong
ifdefbên ngoàiif, bên kia đặt trong câu lệnhifbên trong; tức đây không phải khác biệt kỹ thuật mà là khác biệt về styleNếu vậy, tác giả đã làm nhiều hơn rất nhiều so với việc chỉ “đề xuất” ý tưởng patch
Người đó đã debug issue và viết toàn bộ patch, rồi nó được chấp nhận chỉ với một thay đổi nhỏ
1: https://news.ycombinator.com/item?id=37672558
Với vấn đề bảo mật, tốc độ và độ chính xác quan trọng hơn hình thức, và các maintainer kernel đã xử lý đúng khi ghi công bằng
Reported-bySuggested-bycó thể nhỉnh hơn một chút, nhưng đó không phải điều OP muốn; OP dường như muốn có dấu hiệu “người đóng góp cho kernel” dựa trên một patch rất nhỏNhìn vào một số phản ứng trong luồng này, tôi thật sự mong vài người đừng quản lý các lập trình viên junior hay trung cấp
Nếu trong đội có một junior nhiệt huyết, đưa ra một PR giúp giải quyết một vấn đề nào đó nhưng chất lượng còn thiếu, thì việc quở trách rằng “chưa đủ tốt”, vứt bỏ code rồi tự viết lại là cách phản ứng tệ nhất
Nó làm mất tinh thần, lãng phí thời gian của cả người đó lẫn của bạn, khiến họ chẳng học được gì, lần sau không thể cải thiện hay đóng góp có ý nghĩa, và cũng ngại nhờ giúp đỡ hoặc tự nguyện đóng góp
Ngay cả khi họ lao vào một vùng code phức tạp, vẫn có cách tương tác tốt hơn
Junior trong đội được kỳ vọng sẽ ở lại một thời gian, và qua phỏng vấn thì năng lực cơ bản cũng đã được xác nhận ở mức nào đó, nên có thể tin vào khả năng phát triển của họ
Một người ngẫu nhiên trên Internet không có nghĩa vụ ở lại, và phần lớn các bản sửa kiểu “ghé qua làm rồi đi” như vậy sẽ không ở lại
Ta cũng không biết người đó thực sự có năng lực gì, hay sẽ phản ứng thế nào trước yêu cầu chỉnh sửa
Một trong những điều gây bực bội nhất từ góc độ quản lý là ai đó đặt một người ngẫu nhiên vào tuyến báo cáo của mình và bắt mình chịu trách nhiệm về hiệu suất của người đó
Giờ hãy tưởng tượng một người nào đó trên Internet với cảm giác mình có quyền được đáp ứng đã bỏ vài ngày làm ra một bản sửa chất lượng thấp, rồi tôi phải huấn luyện người đó như quản lý của họ; phép ví von này không hợp lý
Trước đây tôi từng thắc mắc vì sao khi host dự án trên GitHub lại ầm ĩ vì những PR không mong muốn, nhưng giờ thì tôi hiểu
Nếu không muốn xử lý các PR ngẫu nhiên mà bị buộc tội là “quản lý tồi làm người khác mất tinh thần và lãng phí thời gian của họ” thì đó là cảm giác được quyền đòi hỏi quá mức
Ví dụ: https://news.ycombinator.com/item?id=25940799
Trở thành người chuyên nghiệp cũng là học cách tách bản thân khỏi sản phẩm công việc của mình, và hiểu rằng đồng nghiệp không có kế hoạch ác ý nhằm cản trở mình
Ai cũng từng có dự án làm vài tháng bị hủy, và từng nhận những nhận xét gay gắt trong code review
Chấp nhận và học từ những việc như vậy là phần việc của một người chuyên nghiệp
Tất nhiên những người thẳng thắn đến mức thô lỗ cũng cần học rằng thái độ đó sẽ phá hỏng nhiều mối quan hệ
Chúng ta không phải nghệ sĩ, mà là người chuyên nghiệp
Nếu một kỹ sư xây dựng junior thiết kế một cây cầu có lỗi kết cấu và người senior nói “xin lỗi, nhưng cái này giờ khó cứu rồi nên phải làm lại toàn bộ”, thì người senior không có vấn đề gì
Tôi không muốn lái xe qua một cây cầu ọp ẹp chỉ để giữ lòng tự trọng cho junior
Có vẻ nhiều bình luận không có nhiều kinh nghiệm duy trì các dự án mã nguồn mở lớn nên nhìn maintainer như thể đặc biệt cay nghiệt
Nếu từng duy trì một dự án mã nguồn mở nhỏ, bạn sẽ thấy nhận PR từ người ngẫu nhiên là rất nhiều việc, và thường tốn nhiều thời gian hơn tự làm
Mất rất nhiều thời gian để review code kỹ, trao đổi với contributor để sửa vấn đề, và đưa về đúng chất lượng cũng như quy ước kỳ vọng
Junior ở nơi làm việc đã qua phỏng vấn, còn ở đây là một người lạ ngẫu nhiên yêu cầu thay đổi
PR bị từ chối thì buồn, nhưng tôi hiểu lập trường của cả hai bên
Nhìn cuộc trao đổi của maintainer thì không thấy đặc biệt xấu tính hay thô lỗ
Gần như có cảm giác như một luồng tệ trên LKML
Người đó theo nghĩa đen đã làm 95% công việc, vậy mà lại bị chỉ trích vì muốn được ghi nhận công lao
Tôi thật sự không hiểu vì sao lại như vậy
So sánh hai bản vá thì thấy có khác biệt rõ ràng
Đóng góp trong bài được liên kết thay đổi hành vi của cả hai nhánh
if...else, còn đóng góp cuối cùng chỉ thay đổi đường đi trong nhánhifHẳn maintainer có lý do khi thay đổi code
Dù vậy, phần sửa thực tế gần như được sao chép 100%, nên việc ghi công lao cho tác giả bản vá gốc là phù hợp
Kết quả ban đầu trên kiến trúc PPC32 không có
flush_fp_to_threadvà cũng không có điều kiệnelseBản vá cuối cùng gọi
flush_fp_to_thread(child);, xử lý tùy theoCONFIG_PPC32bên trong kiểm tra phạm vifpidx, rồi nếu nằm ngoài phạm vi thì gánfpscrVì vậy giữa hai cách giải có khác biệt thực sự
Tôi không thể nói bên nào đúng hay tốt hơn, nhưng rõ ràng là kết quả khác nhau
Nó cũng có thể cho thấy sự chưa thành thạo với C
Bảo trì codebase lớn một nửa là dập lửa, một nửa là tránh xung đột tên
Bản vá đó khá khác, và tôi ước gì mình đã lưu nó ở đâu đó để có thể cho xem
Đây là một phần bình thường của việc đóng góp cho kernel
Thường thì cách truyền đạt vấn đề ngắn gọn nhất là một bản patch, nên bạn gửi patch, và kỳ vọng nên là họ sẽ không dùng chính patch đó
Nghĩ nhanh thôi thì chuyện như vậy đã xảy ra với tôi ít nhất ba lần [1][2][3]
Thành thật mà nói tôi chưa từng nghĩ đến việc nổi giận, vì mục tiêu chính của tôi là sửa lỗi và tôi vui vì lỗi đã được sửa
Lời khuyên chân thành dành cho OP là nên xóa bài blog này. Sau này bạn sẽ hối hận
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Tôi khá ngạc nhiên khi thấy tên của người khác
Trong các dự án mã nguồn mở, chuyện này luôn xảy ra, và cuối cùng chỉ làm người ta mất động lực đóng góp thêm
Năm ngoái tôi nhận một issue đã mở suốt vài năm, tạo PR, sửa cả test code, rồi còn làm thêm một phần việc riêng để sửa vấn đề build
Maintainer chỉ lấy PR sửa vấn đề build và đơn giản là phớt lờ issue ban đầu
Tôi hoàn toàn không có khả năng sẽ lại dành thời gian đóng góp cho dự án đó
Bạn mở PR và nhận comment yêu cầu thay đổi
Vài ngày sau khi có thời gian sửa, PR đã bị đóng bởi một PR khác của một người thường xuyên đóng góp
Nhìn PR đó thì gần như giống hệt code của bạn, chỉ đổi một tên biến, và được approve ngay theo kiểu review “bạn bè”
Nhìn profile của người đó thì gần như mọi đóng góp đều là sao chép code của người khác
Tôi cố giúp họ chỉnh lại cho phù hợp với phần còn lại của codebase, nhưng đây là phần khó nhất
Vì hầu hết developer chỉ muốn đẩy phần họ đã sửa vào, thay vì học các quy ước của dự án trước
Dù vậy, nếu code đại khái đúng và sau khi merge tôi chỉ cần khoảng 15 phút chỉnh lại rồi thêm chút test là đủ, tôi sẽ nhận
Trường hợp này cũng có vẻ là tình huống như vậy, và maintainer lẽ ra nên làm thế
Contributor nhận được ghi nhận, maintainer chỉ cần vài phút dọn dẹp cần thiết để đủ được upstream chấp nhận, và mọi người đều vui
Câu “phiên bản của tôi tốt hơn” là rất ngạo mạn và thiếu chuyên nghiệp, dù thực tế có tốt hơn hay không
Nếu sau 6 năm kể từ khi issue được báo cáo lần đầu mà vẫn chưa sửa được, thì phải thừa nhận rằng nếu không có đóng góp của người đó, bản sửa của bạn cũng sẽ không tồn tại
Sau khi đã thấy “lời giải” rồi lấy bản sửa đó thì trên thực tế gần như là ăn cắp
Mọi người thường coi việc code của mình không được nhận hoặc bị viết lại là chuyện cá nhân, nhưng lại bỏ qua rằng viết code chỉ là một phần nhỏ trong việc vận hành một dự án
Tôi thường xem qua bug report và merge request để ước lượng patch sẽ được đối xử như thế nào
Với những dự án trông không thân thiện với đóng góp, tôi đã bỏ qua rất nhiều bản sửa bug; Linux kernel năm 2003 cũng là một ví dụ như vậy
Một số dự án đơn giản là như thế, tốt hơn là đừng dây vào, và thường chỉ lãng phí thời gian
Giờ đây, sau cuộc cách mạng AI, giấy phép mã nguồn mở đang bị vi phạm trên diện rộng, nên từ đó tôi đã không gửi code mã nguồn mở nữa và sau này cũng sẽ không
Tôi thật sự khó hiểu nổi mức độ độc hại ở đây
Những câu kiểu “không nên làm vì sự công nhận, sao, phần thưởng hay CV” nghe như điên rồ
Những người nói vậy có việc làm không? Nếu có, để nhất quán thì họ nên làm hoàn toàn miễn phí
Tiền lương cũng là một hình thức công nhận cho đóng góp
Cá nhân tôi nghĩ dù lời giải cuối cùng đã khác với đề xuất ban đầu, nếu nó dựa trên việc phát hiện ra lời giải ban đầu thì thêm đồng tác giả là việc rất nhỏ
Tác giả có lý do chính đáng để phàn nàn về điểm này, và đây sẽ không phải lần đầu cũng chẳng phải lần cuối ai đó cảm thấy đóng góp của mình không được ghi nhận
Dù bản patch tự nó kém hơn, nỗ lực debug thì tuyệt đối không hề kém
Trong quan hệ lao động, người sử dụng lao động và nhân viên có thỏa thuận rằng sẽ làm việc để đổi lấy thù lao
Nếu bạn bất ngờ bước vào một công ty nào đó và bắt đầu làm một việc không ai yêu cầu, thì hầu như chẳng ai cho rằng mình có quyền được trả thù lao
So sánh chính xác hơn với chuyện đã xảy ra với OP là trường hợp này
Cách phản hồi kiểu “Xin lỗi, nhưng phiên bản của tôi tốt hơn. Nếu bạn muốn trở thành người đóng góp cho kernel Linux thì đây là một issue bạn có thể sửa” là một cách rất hay để khiến ai đó không bao giờ muốn giúp nữa và làm nản lòng cả những người khác
Maintainer nói rằng ông không tái hiện được crash bằng
gdbserver, nhưng có một test case cho thấy bug nên đã xác nhận và thử bản sửa; ông viết: “Cảm ơn vì patch, nhưng tôi muốn sửa theo cách khác. Bạn có thể thử patch dưới đây và xác nhận xem bug đã được sửa chưa không?”https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
Ngoài ra còn có các comment review khác không được nhắc tới
Nội dung là không rõ macro chỉ dành cho PPC32 có lợi ích gì, nên tránh
#ifdefnếu có thể, và patch của Michael dễ hiểu hơnhttps://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
OP đang nhét lời vào miệng người khác rồi nổi giận với điều đó; đây không phải là chiến lược hay, đặc biệt trong giao tiếp bằng văn bản
OP khiến cuộc trao đổi trông như thể đã thô lỗ, nhưng thực ra không phải vậy