Xin đừng phá hỏng phần mềm này bằng vibe
(github.com/RsyncProject)- Vấn đề này đã kết thúc ở trạng thái Closed, và vì đây là một bài nêu vấn đề không có bước tái hiện hay đề xuất sửa lỗi trong phần nội dung nên không thấy các nhánh, PR hay mốc phát hành liên quan
- Lo ngại ban đầu là rsync đang nhận vào các thay đổi có AI can dự, làm lung lay tính ổn định, và nội dung bài đăng chủ yếu là hình ảnh chứ không có phần giải thích bằng văn bản
- Một người dùng báo cáo rằng vì log2ram dùng rsync nên máy in 3D của họ đã chạy ở mức CPU 100%, và mô tả rằng AI theo cách nào đó đã đưa lỗi này vào robot
- Một người dùng khác cho rằng rsync là công cụ ổn định vốn chỉ cần cập nhật bảo mật và sửa lỗi, chứ không cần tính năng mới hay viết lại, và ở hai bản phát hành vá gần đây đã phát sinh vấn đề lẽ ra không được làm thay đổi hành vi sẵn có
- Một người dùng sử dụng rsync cho công việc DFIR giải thích rằng chỉ riêng việc AI có tham gia vào bản cập nhật cũng đủ khiến nó bị xem là “công cụ AI” theo chính sách nội bộ, nên phải qua khâu rà soát bổ sung
- Ở phía phản đối, có ý kiến cho rằng issue tracker không phải nơi để bày tỏ bất mãn mang tính lan truyền; nếu không có báo cáo lỗi cụ thể hay bước tái hiện thì nên chuyển sang Discussions hoặc tự fork
- Xung đột cốt lõi leo thang giữa một bên cho rằng “đây là phần mềm miễn phí, không thích thì cứ fork”, và bên kia cho rằng rsync đã là công cụ hạ tầng cốt lõi, nên ngay cả việc phải bàn đến chuyện pin bản hay fork ở downstream cũng đã là tín hiệu có vấn đề
- Một số người dùng nhắc đến việc viết lại bằng Rust hoặc fork, nhưng người khác phản bác rằng lý do rsync được yêu thích là vì tính ổn định và hoạt động y nguyên như cũ, còn viết lại phải là một dự án riêng
- Phía ủng hộ việc dùng AI cho rằng không nên quy mọi nhắc đến AI thành “vibe slop”, và yêu cầu phải trực tiếp kiểm tra commit log từ sau tháng 3 để xác nhận lý do của các thay đổi
- kaithar giải thích rằng các công việc gần đây bao gồm sửa lỗi và gia cố các khiếm khuyết bảo mật, như đọc bộ nhớ chưa khởi tạo, tràn/thiếu tràn giao thức wire, timestamp 32-bit, cùng các điều chỉnh liên quan đến chuẩn C
- Bình luận đó cũng phản bác rằng nếu cố định ở các bản phát hành cũ như 3.4.1 thì có thể sẽ bị kẹt ở phiên bản chứa nhiều CVE, còn hồi quy có thể phát sinh từ những edge case mà test đã bỏ sót
- Kết cục, issue này không hội tụ thành việc sửa một lỗi cụ thể, mà còn lại như một cuộc tranh luận về cách xử lý niềm tin, khả năng kiểm toán và quản trị của phát triển có AI hỗ trợ trong hạ tầng ổn định lâu năm như rsync
1 bình luận
Ý kiến trên Hacker News
Kiểu kéo bầy này thật sự rất kỳ quặc, và một số người dường như đang hành xử thiếu lý trí. Tôi phần nào hiểu động cơ muốn “thắng” trong cuộc chiến này, nhưng cách làm này thì hoàn toàn không ổn và chỉ khiến họ trông như những kẻ cuồng tín
Chỉ cần 5 phút là đủ để tìm kiếm regression trong trang issue và lướt qua 17 kết quả. Có thể còn nhiều hơn trong hệ thống theo dõi trước đây, từ trước khi chuyển sang GitHub
Kiểu hành xử này cực kỳ ngớ ngẩn, và có vẻ như mọi người đang bám víu vào bất cứ thứ gì có thể để biện minh cho sự căm ghét AI. Như thể họ quên mất rằng ngay cả trước thời AI, con người cũng vẫn mắc sai lầm
Nếu có bằng chứng cho thấy AI đã làm tăng đáng kể số issue chưa được giải quyết của rsync thì hãy đưa ra. Khi đó tôi sẵn sàng đổi ý
Có thể đây không phải nguyên nhân trực tiếp của commit lần này, nhưng có thể là phản ứng trước những vấn đề tích tụ khác, và bản thân điều đó cũng cần được cân nhắc
Có vẻ như mọi người đã mệt mỏi vì phải miễn cưỡng nuốt những câu chuyện kiểu “AI là thứ tuyệt vời nhất kể từ [phép ví von văn hóa]”, nên họ cố bám lấy bất kỳ cọng rơm nào để phản kháng, và tôi nghĩ đó là phản ứng khá bình thường
Nếu không ai lên tiếng về mối lo rằng người dùng không tin AI, thì người bảo trì làm sao biết được? rsync từng rất ổn định. Chẳng lẽ mọi người phải lặng lẽ chuyển sang Openrsync rồi không nói gì sao?
Một trong các liên kết ở đó dẫn tới nơi tổng hợp lớn hơn về các lỗi được báo cáo từ các bản phân phối nhánh dưới (https://github.com/void-linux/void-packages/issues/60825)
Xét tới danh tiếng của phần mềm vibecoding, cơn giận dữ này là rất hợp lý. Ngay cả những chuyên gia mà tôi yêu thích cũng nói kiểu “muốn tránh tạo ra bug thì phải xử lý nó theo một cách rất cụ thể, và có lẽ chỉ nên dùng cho bản 0 để phác họa domain”
Thế mà ở đây, công cụ lõi cho sao lưu theo chuẩn ngành lại đang bị người bảo trì rút tấm thảm dưới chân người dùng theo một cách rõ ràng là không an toàn, chỉ vì ý định “thêm nhiều tính năng hơn”
Trong thread Timeshift cũng có nội dung kiểu “sau khi cập nhật rsync, mức dùng CPU trong lúc sao lưu hằng ngày trở nên quá nặng đến mức tôi phải dừng timeshift vì nó chạy mãi không xong”
Nói cách khác, mọi người đang thất vọng và tức giận vì công cụ mà họ đã giao phó việc sao lưu và dữ liệu của mình đang phá vỡ toàn bộ hạ tầng sao lưu bằng một số lượng khổng lồ lỗi hồi quy và bug mới, và nguyên nhân là vì nhà phát triển cốt lõi đang vibecoding
Ngay cả chuyên gia vibecoding như Simon Wilson cũng nói rõ rằng điều này chỉ khả thi “khi xử lý công cụ theo một cách nhất định”, nên либо người bảo trì này không làm vậy, либо nhận định đó không đúng
Nếu thực sự đọc thread đó thay vì chỉ lướt qua đoạn hai người cãi nhau, sẽ thấy có nhiều báo cáo rằng người dùng trong môi trường công nghiệp và chính phủ phải làm lại toàn bộ quy trình chỉ để cập nhật phần mềm này. Bởi vì phần mềm đã ngay lập tức trở nên không còn đáng tin cậy, gây hại trực tiếp cho người dùng và phá vỡ chính lý do tồn tại của nó
Nếu tôi cũng giao cho phần mềm này việc sao lưu hơn 500GB thì chắc tôi cũng sẽ nổi giận, và tôi sẽ tự hỏi còn có bao nhiêu vấn đề nữa đã lọt vào mà sẽ không lộ ra cho đến khi một công ty không kiểm thử sao lưu thường xuyên phải chịu tổn thất dữ liệu trị giá 10 triệu đô la
Thật sự không hiểu nổi
Có phần mềm vững chắc được vô số người và dịch vụ sử dụng. Nó hoạt động tốt, làm đúng vai trò của mình, và thỉnh thoảng chỉ cần vài bản cập nhật sửa lỗi nhỏ
Vậy ở đây cần AI để làm gì?
Hơn nữa, tôi cũng không hiểu vì sao mọi người lại nói “hãy fork ra và dùng phiên bản cũ”. Đáng ra phải ngược lại mới đúng. Hãy tạo một nhánh fork song song kiểu
younamethetool-aivà đừng đụng vào bản gốcGiờ tôi phải fork và tự duy trì toàn bộ các công cụ hệ thống của mình sao?
Việc than phiền trên issue tracker rằng AI đang phá hỏng phần mềm mà không có bằng chứng là một dạng quấy rối người đóng góp mã nguồn mở thường được bàn đến trên Hacker News [1]
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
“Issue tracker không phải nơi để thu hoạch các bài đăng mạng xã hội đang lan truyền. Hãy báo cáo lỗi có thể hành động được hoặc tự fork lấy. Việc trút bực về lựa chọn của nhà phát triển không mang lại hiệu quả gì”
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
“@II-Paulus-II dừng lại đi. Bạn chẳng biết gì cả. Bạn chưa tự tay phát hành được chức năng nào. Không ai phụ thuộc vào code của bạn cả. Bạn chỉ là kiểu người chỉ tay hô ‘AI viết cái này’ rồi núp sau cảm giác thượng đẳng đạo đức vì tự viết các dự án đồ chơi và script từ đầu. Bạn không phát hành được, không thích nghi được, và cũng không hiểu rằng issue tracker không phải chỗ cho kiểu thái độ này”
[1] https://news.ycombinator.com/item?id=43077833
Tôi chưa đọc kỹ, nhưng câu “6 CVE đã được sửa trong bản phát hành này. Cả sáu đều do VulnCheck chỉ định với tư cách CNA. Trong mọi trường hợp, các phiên bản bị ảnh hưởng đều là 3.4.2 trở xuống” có vẻ là một câu trả lời khá mạnh cho câu hỏi “tại sao?”
https://download.samba.org/pub/rsync/NEWS#3.4.3
Phản ứng đầu tiên chắc hẳn sẽ là muốn bảo họ biến đi chỗ khác
Nếu “công chúng” muốn tiếp quản và duy trì dự án thì họ có thể fork, nhưng đó là công việc ít được ghi nhận
Hơn nữa, trong một dự án mã nguồn mở, việc thay đổi công cụ họ sử dụng cũng không cần phải có lý do, và họ cũng chẳng nợ bạn lời giải thích nào
Cách issue đó được mở ra thực sự rất khó chịu, nhưng tôi không hiểu vì sao mọi người lại có cảm giác như các maintainer đã thả AI vào rsync. Tại sao lại làm vậy? Khi bạn đã có danh tiếng và sự tin cậy, là người dẫn đầu trong một ngách cụ thể, không chịu nhiều áp lực thị trường, mọi người yêu thích công cụ đó, và nó làm chính xác, rất tốt việc nó cần làm, thì tại sao lại thử mấy thứ linh tinh còn tương đối mang tính thử nghiệm?
Nó giống như đoạn độc thoại ngắn trong Matrix về việc tâm trí nguyên thủy của con người không thể chấp nhận thiên đường. Họ đã dùng một công cụ hoàn hảo, đã thắng, gần như không thể thay thế trong ngách của mình, đáng tin cậy, và theo nghĩa bóng thì đã trở thành cái tên ai cũng biết. Đem nó ra đánh cược hay đụng chạm vào nó chẳng có ý nghĩa gì với bất kỳ ai và thật sự rất khó hiểu
Dù vậy, làm như thế trên issue tracker chính thức vẫn là hành vi thực sự khó chịu. Thái độ tệ và có vẻ chẳng có thiện ý gì
Nhưng bây giờ tôi không thấy AI là điều hoàn toàn tích cực ở bất cứ đâu, và tôi xem phản ứng dữ dội này với việc dùng AI tạo sinh là một sự điều chỉnh hướng đi tích cực của công chúng
Có những bài viết nói về sự thỏa mãn tức thì của LLM, và tôi nghĩ càng tương tác nhiều với những người dùng công cụ này thì càng thấy đây có thể thật sự là vấn đề cốt lõi. Sinh học của chúng ta không chịu nổi nó
Tôi thấy những người vốn rất thông minh lại làm những việc cực kỳ ngớ ngẩn chỉ vì máy kéo xèng bảo thế, rồi còn được huấn luyện để trở nên bất lực khi máy kéo xèng đó thất bại
Tôi bị xem như một kẻ Luddite không thấy được tiến bộ, trong khi nhìn đồng nghiệp tạo ra những benchmark vô nghĩa rồi gắn lên các biểu đồ đẹp do AI làm
Thế là tôi phải chọn một trong hai: cười và giả vờ đó là việc tốt, hoặc mắng họ rằng benchmark đó vô nghĩa vì nó đang kiểm thử một đoạn đã bị đóng đinh thành hằng số. Dù chọn cách nào thì tôi cũng đang đối xử với họ không phải như đồng nghiệp thông minh, mà như trẻ 7 tuổi
Dù các maintainer của rsync nằm ở đâu trên phổ từ hoàn hảo và có trách nhiệm cho tới bất tài như trẻ con, thì thực ra chúng ta không biết
Nhưng chấp nhận hơi lạc đề một chút, tôi có suy nghĩ này. Bỏ qua chuyện phần mềm trưởng thành như Rsync không cần kiểu vận động như số dòng code thay đổi, giả sử các maintainer đang quản lý dự án với ý định tốt nhất
Nếu chuyện này đang xảy ra trong mã nguồn mở, thì chất lượng phần mềm đóng hiện đang ở mức nào?
Mức độ sử dụng AI, tức lượng prompt nhập vào, đang được đưa vào đánh giá nhân viên như một chỉ số thành công, và mọi người thì hoảng loạn trước nguy cơ bị AI gây ra sa thải hàng loạt
Thật chóng mặt
https://github.com/RsyncProject/rsync/issues/929#issuecommen... cho thấy rằng nó không còn chạy trên Darwin cũ và Linux < 5.6 nữa, mà Linux 5.6 là phiên bản đã được lên lịch ngừng hỗ trợ từ năm 2020. Ngoài ra còn có vài lỗi khác
Không thể kỳ vọng maintainer vừa hỗ trợ các hệ thống cũ, vừa biết hết mọi tác động mà thay đổi sẽ gây ra. Dùng AI hay làm thủ công cũng vậy
Nhân tiện, chính lỗi đó được đưa vào ở commit 30656c5e do Claude Code tạo ra, và có lẽ đi kèm với việc review và test không phù hợp từ một ai đó
https://github.com/RsyncProject/rsync/commit/30656c5e
Có người đã dùng AI để bisect rsync gần đây: https://github.com/themgt/rsync-compare-link-dest-341-343-re...
Có người khác đang cố sửa bằng thêm Claude Code: https://github.com/RsyncProject/rsync/pull/930
Ticket liên quan: https://github.com/RsyncProject/rsync/issues/915
Tôi khuyên nên thêm kiểm thử hồi quy vào commit ngay trước 30656c5e, rồi rebase tiến lên phía trước trong khi vẫn giữ nguyên chức năng
Đây không phải là “tính năng mới không mong muốn”. Tridge đang sửa một vấn đề bảo mật liên quan đến báo cáo lỗi. Tôi thông cảm. Tất cả chúng ta đều đang bị các vấn đề bảo mật đấm vào mặt. Sửa chúng không phải là chuyện tùy chọn
Tôi sẽ không nói rằng quay lại xử lý việc này trên phần mềm 10 năm tuổi là vui vẻ gì, nên việc tridge đang cố gắng đã đủ gây ấn tượng rồi
Tôi cũng có tội dùng LLM để vượt qua đống hỗn loạn này. Tôi không biết tridge làm thế nào, nhưng tôi kiểm tra từng dòng mã mà LLM nhả ra. Dù vậy, nguy cơ lỗi lọt vào rõ ràng vẫn rất lớn
Tôi đã không nhìn vào đoạn mã đó từ rất lâu, và cũng không còn quen thuộc với nó như trước nữa. Vì vậy chuyện lỗi lọt vào không phải điều gì quá đáng ngạc nhiên
Điều kỳ lạ trong vụ bùng nổ này là người đưa ra phàn nàn ban đầu có vẻ cực kỳ muốn bảo vệ hệ thống sao lưu của mình, nhưng commit của tridge mới chỉ có từ 2 tuần trước. Tôi biết tridge rất giỏi, nhưng chẳng phải kiểu này hiển nhiên nên được đối xử như phần mềm alpha sao? Người đó đã nghĩ gì vậy? Có lẽ chính họ cũng cần học thêm một chút về cách xây dựng hệ thống đáng tin cậy
Nếu là vài năm trước, xác suất một bài kiểu này lên trang chủ Hacker News hẳn gần như bằng 0. Bất kể nội dung đúng hay sai, khi đó ở đây chưa đầy những người bình thường không hiểu hành vi nào là không thể chấp nhận được
Điều đang được nói tới ở đây là ngôn từ bạo lực của issue đó. Nhưng giờ chúng ta lại bị bao quanh bởi những người thậm chí không phân biệt nổi cả điều hiển nhiên nhất
Đó không phải là cách để nói với maintainer rằng bạn không đồng ý với hướng đi của dự án. Issue đó hoàn toàn vô dụng. Thà gửi một báo cáo bug về việc “bị phá hỏng vì vibe coded” còn hơn
Câu này đánh trúng trọng tâm. Không có báo cáo bug nào thậm chí cố ghi lại hồi quy
--compare-dest=đã được nêu. Dù Ctrl-F cũng chẳng thấy ai nhắc lại “compare-dest”Những người đăng bình luận giận dữ vô ích về AI hoàn toàn có thể bảo Opus 4.8 chạy rsync 3.4.3 và 3.4.1 để ghi nhận kỹ lưỡng hồi quy, rồi dùng
git bisecttìm commit gây hỏng để tạo ra một báo cáo bug chuyên nghiệp và hữu ích hơn gấp 1000 lầnNếu xã hội muốn xem công việc của con người có giá trị hơn công việc của AI, thì tốt nhất nên tránh những hành vi ngớ ngẩn mà chỉ con người mới làm được
Chẳng phải có khả năng nó lên trang chủ vì người khác cũng cảm thấy tương tự về phần mềm mà họ dùng hằng ngày cho công việc quan trọng sao?
Đúng là issue trên GitHub này rất sáo mòn, và rõ ràng là một việc khó được cảm ơn, nhưng thực tế rsync là nền tảng của nhiều pipeline nhạy cảm
Nếu thực sự tin rằng nó quá lạc đề, thì phản hồi lịch sự là đóng issue lại
Tôi vẫn chưa hiểu rõ điều gì lại hiển nhiên đến thế. Với tôi, câu “dừng lại đi. anh không biết gì cả. anh chưa từng tự tay phát hành nổi 0 tính năng. không ai phụ thuộc vào code của anh cả” còn mang tính bạo lực hơn nhiều so với “please do not vibe fuckup this software”
Có ai trong thread của issue đó thực sự giải thích vấn đề không? Ý tôi là các bước tái hiện, hành vi kỳ vọng và hành vi thực tế
Đây là thứ được đưa vào issue tracker. “Trong commit message có nhắc đến Claude, và ai đó trên Bluesky nghĩ rằng một vấn đề không xác định mà họ gặp có liên quan đến các commit đó” thì không phải là một issue có thể hành động được
Gác toàn bộ phần tranh luận còn lại sang một bên, nếu là dự án của tôi thì tôi sẽ đóng và khóa nó với lý do “thiếu thông tin tái hiện”. Các cuộc thảo luận chung về AI, fork và xả giận có nơi phù hợp hơn
Người dùng Linux < 5.6 không thể build từ GitHub. Với tôi đây có vẻ là một hồi quy khá nhỏ. Những ai dùng nhánh bảo trì của 5.6, chủ yếu là các bản mở rộng bảo mật, hẳn maintainer distro của họ có thể phát hiện lỗi build và sửa kịp thời
Việc siết chặt để chống tấn công path traversal gây ra lỗi cho người dùng chạy giao thức rsync gốc mà không dùng chroot. Trớ trêu là
chroot = novốn đã không được khuyến nghị mạnhCó lẽ thậm chí nên khuyên rằng đừng dùng rsync gốc theo cách tự động hóa, hoặc tốt hơn là đừng dùng nó luôn. CVE mà commit đó sửa áp dụng chính xác cho trường hợp sử dụng này
https://www.cve.org/CVERecord?id=CVE-2026-29518
Cần daemon + no chroot. “daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false.”
Vì vậy workflow bị ảnh hưởng lại chính là workflow dễ tổn thương nhất, thế mà mọi người đang khuyên quay về phiên bản cũ
Hơn nữa, nếu lẽ ra kiểm thử hồi quy phải bắt được việc này, thì bài test đó phải được viết từ trước rồi
Có vẻ một số người đã quên mất FOSS project là gì
“15. Từ chối bảo hành
Trong phạm vi pháp luật hiện hành cho phép, chương trình này không có bảo hành. Trừ khi được nêu khác đi bằng văn bản, chủ sở hữu bản quyền và/hoặc các bên khác cung cấp chương trình ‘nguyên trạng’, không đưa ra bất kỳ bảo hành nào, dù rõ ràng hay ngụ ý. Điều này bao gồm nhưng không giới hạn ở các bảo hành ngụ ý về khả năng thương mại hoặc sự phù hợp cho một mục đích cụ thể. Toàn bộ rủi ro về chất lượng và hiệu năng của chương trình thuộc về bạn. Nếu chương trình có lỗi, bạn phải tự chịu mọi chi phí cho dịch vụ, sửa chữa hoặc khắc phục cần thiết”
Tôi giữ quyền được phàn nàn, càu nhàu, chỉ trích, nổi giận hoặc bình luận theo cách khác về mọi quyết định, commit, patch, marketing hay quyết định khác mà dự án đưa ra. Những bình luận đó không bảo đảm sự phù hợp cho bất kỳ mục đích nào, cũng không bao gồm bảo đảm ngụ ý rằng chúng đúng, hữu ích hay tử tế. Nếu bình luận của tôi hóa ra là không mong muốn, bạn giữ quyền nhét nó vào nơi không có nắng chiếu tới
Bạn cứ in điều khoản miễn trừ này ra để tham khảo khi gặp phải những lời chỉ trích FOSS project không mong muốn
Tôi không hiểu vì sao mọi người không nhận ra thái độ “họ có thể làm điều họ muốn” là con đường hai chiều. Người dùng cũng có thể làm điều họ muốn. Nếu không thích thì họ có thể nói ra
Một bình luận trong issue nói thế này
“Việc bạn cho người vô gia cư súp miễn phí không có nghĩa là bạn được phép đái vào đó”
Issue đó vốn đã thành mớ hỗn độn rồi, và luận điểm của bạn cũng đã xuất hiện ở đó. Ai cũng có thể xử lý tốt hơn, nhưng việc mù quáng trích dẫn câu chữ pháp lý sẽ không giải quyết hay cải thiện được gì cả
Đây là lần thứ ba tôi đọc một bài HN về chủ đề này. Mỗi lần cũng chỉ lặp lại cùng một tweet, hoặc bài đăng kiểu Mastodon/Bluesky đó. Có ai thực sự debug vấn đề này chưa?
Nguyên nhân là do mã được tạo ra cẩu thả, hay là một bản vá bảo mật thật sự đã vô tình làm hỏng nó? Theo cách mà con người cũng hoàn toàn có thể mắc phải
Cơn cuồng chống AI này là một kiểu hoảng loạn đạo đức điển hình
Như mọi cơn hoảng loạn đạo đức khác, việc bước 1 có đúng hay không hoàn toàn chỉ là thứ yếu. Điều cốt lõi là người ta gần như đạt được một cảm giác giải tỏa mang tính dục từ bước 2
Trong trường hợp này, tôi biết rsync có mã do AI tạo ra. Giống như phần lớn phần mềm hữu ích vào thời điểm này vậy. Nhưng trên mạng, ngày nào cũng thấy săn phù thủy, và như mọi cuộc săn phù thủy khác, việc lời tố cáo có đúng hay không chẳng mấy quan trọng. Bản thân cơn cuồng loạn mới là mục đích
Cơn giận dữ quanh AI không phải vì công chúng hiểu sai hay vì thông điệp bị lệch, mà là vấn đề của thực tế vật chất
Thứ này đang được dùng làm cái cớ cho các đợt sa thải hàng loạt, các CEO công nghệ gần như ngày nào cũng nói rằng họ sẽ lấy luôn việc làm của tất cả những người khác, và các công ty cloud lớn thì đang hút sạch oxy trong căn phòng. Ngay cả ngành game cũng không an toàn
Xem đây là “chỉ là một cơn hoảng loạn đạo đức điển hình” cũng giống như nhìn thấy biển rút theo một hướng rồi lại cắm đầu chạy thẳng về phía đó
Đọc tiếp lại thấy chính bạn cũng dùng những từ ngữ cảm tính như “săn phù thủy”, “cuồng loạn”
Đây thật sự là săn phù thủy sao? Và bạn có thể biết những người ở bên kia Internet có đang tiến gần đến cảm giác giải tỏa tình dục hay không sao?
Chẳng phải bạn cũng đang phản ứng với ngôn ngữ cảm tính và lối suy nghĩ lỏng lẻo của người khác theo đúng cách tương tự sao?
Từ bao giờ GitHub Issues thành nơi đăng ảnh chụp màn hình bài đăng từ nền tảng khác vậy?
Tôi chỉ thấy kiểu hành xử này ở những chỗ đăng meme hay nội dung giải trí
Không có báo cáo lỗi có thể hành động được hay yêu cầu tính năng nào cả. Cũng không có bản chữ. Thậm chí không có cả liên kết đến bài gốc
Người đăng cái này có nhầm GitHub Issues với tài khoản Twitter cá nhân của mình không?