Tôi cũng xếp hàng.

Ngay cả trong các dịch vụ chat dùng mô hình ngôn ngữ, họ cũng có thể dùng logprop hoặc perplexity để hiển thị mức độ chắc chắn của câu trả lời, nhưng chắc là họ cố tình không làm vậy. Vì mỗi lần phải hiện kiểu như “Câu trả lời này không hoàn toàn chính xác đâu” thì sẽ không có lợi cho hình ảnh thương hiệu của họ.

Cả Docker lẫn podman đều....

securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL

securityContext:
runAsNonRoot: true
runAsUser: UID

Nhìn phần nói về vấn đề của phương pháp đánh giá,
chợt nhớ hồi đại học dù chẳng biết gì vẫn cứ viết linh tinh vào giấy thi.
Hóa ra ngay cả trước thời có LLM thì mình cũng đã tạo ra hallucination rồi;;;

Nếu ca ngợi Namuwiki thì chắc sẽ có cảm giác như thế này

Dạo này Wikipedia cũng chẳng mấy khi xuất hiện trên các công cụ tìm kiếm... cảm giác như việc cập nhật cũng rất chậm nữa..

conductor, viber và nhiều ứng dụng GUI khác cũng đang xuất hiện.

https://vi.news.hada.io/topic?id=22576
Có vẻ họ đã đổi tên từ Claudia.

Hóa ra trước đây chỉ hỗ trợ màn hình di động thôi à?

Bayesian Neural Network là tương lai.

Ý kiến cá nhân thêm là, việc ép phải đổi IDE (KIRO) chỉ vì một mục đích duy nhất là SDD có vẻ là một yêu cầu hơi quá.

Cá nhân tôi nghĩ, với vai trò là công cụ hỗ trợ, có lẽ hình thức như extension cho IDE, ứng dụng bổ trợ hoặc CLI sẽ phù hợp hơn.

Nếu mọi người có thể chia sẻ thông tin về các công cụ SDD mà mình biết thì có lẽ cũng sẽ là sự trợ giúp rất lớn cho những ai đang tham khảo.

Ồ đúng là như vậy. Tôi cũng nghĩ phương pháp Spec Driven vẫn còn ở giai đoạn chập chững, và bản thân các spec đó dường như cũng còn nhiều điểm cần tiếp tục phát triển.

Việc chia sẻ các công cụ và tài liệu theo dạng này có vẻ rất quan trọng ở thời điểm hiện tại.

Vừa xem qua bộ công cụ SDD tên là spec-kit, ở đây cũng thấy nhắc đến SDD. https://github.com/github/spec-kit

Thực tế là khả năng tương thích với Docker không tốt nên tính tiện dụng cũng không cao lắm...
Tôi từng chuyển sang Podman vì nghĩ đến chế độ rootless, rồi lại quay về Docker.
Như người khác đã nói, nếu dùng với Kubernetes thì cứ dùng containerd là xong.

Tôi hơi có thắc mắc là nếu Docker compose không hoạt động tốt, còn ưu điểm là tương thích với Kubernetes, thì chẳng phải dùng luôn Kubernetes ngay từ đầu sẽ hợp lý hơn sao?
Tôi cũng định thử dùng, nhưng vì nó không chạy được ngay một lần là xong và cũng không thể tự map các cổng dưới 1024, nên cuối cùng tôi dùng kết hợp k3s với nerdctl để build image.

Tôi thì đang làm 775... thỉnh thoảng là 776 nữa. 996... thật lòng mà nói, nếu bắt tôi đi làm lúc 6 giờ thì có lẽ còn được, nhưng nếu bảo tan làm lúc 9 giờ thì chắc là quá sức.

So với Hàn Quốc, nơi cứ hô hào thứ Hai thứ Ba thứ Tư thứ Năm thứ Sáu thứ Sáu thứ Bảy...
Thì ở đây hẳn hoi còn được nghỉ những một ngày.

Tôi muốn làm kiểu 777 nhưng chẳng có công ty nào cho làm như vậy vì luật cả hu hu

Tôi vẫn luôn muốn chuyển đổi vào một lúc nào đó, nhưng khi đã thử trước đây thì trái với những gì các lập trình viên nói, có quá nhiều dự án docker compose không hoạt động đúng cách...

Vấn đề là AI khiến những thứ này trở nên quá dễ dàng, nhưng thực ra điều làm người ta kiệt sức còn là những phản hồi hời hợt hơn cả AI.

Đây cũng là vấn đề của chính hệ thống issue/PR mở. Từ trước đến nay, tôi cũng nhiều lần cảm thấy xót xa khi thấy những maintainer chính làm việc một mình dần kiệt quệ và trở nên cay đắng vì các issue và báo cáo lỗi hời hợt, trùng lặp.