GitHub Actions có thể còn tốt hơn rất nhiều
(blog.yossarian.net)- GitHub Actions hữu ích về năng suất và tính năng, nhưng khi viết workflow thực tế, độ trễ khi debug, sai sót bảo mật, thiếu kiểu dữ liệu và thiếu action chính thức thường xuyên dẫn đến mất thời gian lặp đi lặp lại
- Ngay cả với chỉnh sửa nhỏ cũng phải lặp lại
git add; git commit; git pushvà kiểm tra log trên trình duyệt; đã có trường hợp một workflow phát hành đơn giản cần tới 4 lần commit và các bản phát hành thất bại - Mở rộng
${{... }},pull_request_target, quyền mặc định rộng củaGITHUB_TOKEN, và tham chiếu SHA từ fork đều là những điểm bảo mật dễ mắc lỗi; đặc biệt SHA của fork có thể trông như commit của kho lưu trữ dự định - Input của action không có xác thực
type:, và phạm vi hỗ trợ cũng khác nhau giữaworkflow_callvàworkflow_dispatch, nên thay vì input dạng mảng/đối tượng, người dùng phải tự xử lý chuỗi kiểu CSV hoặc input đã được làm phẳng - Xác thực tại thời điểm push, kiểm tra bảo mật lúc runtime, thu hẹp quyền token mặc định cho kho riêng tư, kiểm tra kiểu nghiêm ngặt hơn và nhiều action chính thức/bán chính thức hơn có thể giúp tăng độ tin cậy của workflow
Hữu ích nhưng liên tục cản trở với GitHub Actions
- GitHub Actions là công cụ đã giúp ích rất nhiều cho năng suất và độ yên tâm, đến mức được dùng hằng ngày từ năm 2019 trong cả dự án chuyên nghiệp lẫn dự án cá nhân
- Việc mở rộng tính năng cũng diễn ra đều đặn
- Dù vậy, trong quá trình phát triển thực tế, nó cũng có thể trở thành nguyên nhân gây thất vọng lớn và lãng phí thời gian
Debug quá nặng nề ngay cả với lỗi nhỏ
- Đã có trường hợp trong quá trình thiết lập workflow phát hành, chỉ để bắt một lỗi nhỏ mà cần tới 4 lần commit và 4 lần phát hành thất bại
- Không dùng
${{ ... }}ở nơi cần thiết - Bỏ sót quan hệ
needs:
- Không dùng
- Chu kỳ debug hiện tại có quá nhiều bước, ngay cả khi chỉ kiểm tra một lỗi đơn giản
- Phải chuyển từ môi trường phát triển sang trình duyệt
- Phải tìm đúng tab
- Phải nhấp vào phần tóm tắt và màn hình trạng thái của Actions
- Phải làm mới log console đã được đệm để tìm lỗi tiếp theo
- Ngay cả thay đổi nhỏ cũng có thể mất hơn 30 giây cho toàn bộ quá trình
-
Hướng cải thiện
- Cần cung cấp shell debug tương tác, hoặc ít nhất phải có cách chạy lại workflow với thay đổi nhỏ mà không cần
git add; git commit; git push - Cần có khả năng từ chối workflow rõ ràng là sai ngay tại thời điểm push bằng thiết lập của kho lưu trữ
- Cú pháp không thể hoạt động
- Tham chiếu tới job hoặc step không tồn tại
- Tình huống workflow âm thầm không chạy vì YAML sai
- Cần cung cấp shell debug tương tác, hoặc ít nhất phải có cách chạy lại workflow với thay đổi nhỏ mà không cần
Sai sót bảo mật xảy ra quá dễ dàng
- Trong GitHub Actions, workflow do người dùng viết rất dễ trở nên dễ tổn thương ngoài ý muốn
- Khi dùng mở rộng
${{ ... }}trong shell hoặc ngữ cảnh thực thi khác, nếu giá trị mở rộng là input do người dùng kiểm soát thì có thể dẫn đến chèn mã độc- Trong ví dụ, mã được chèn qua
inputs.frobvà$MY_IMPORTANT_SECRETcó thể bị rò rỉ
- Trong ví dụ, mã được chèn qua
pull_request_targetrất khó dùng an toàn trong những workflow không hề đơn giản- Trường hợp sử dụng dự kiến có vẻ chỉ là phạm vi hẹp như gắn nhãn hoặc để lại bình luận cho PR đến từ fork
- Nhưng trên thực tế nó lại lộ ra như một foot-gun lớn
- Quyền ở mức workflow và job cũng dễ bị thiết lập quá rộng
- Quyền truy cập mặc định của
GITHUB_TOKENthông thường là rất rộng - Trong kho của tài khoản cá nhân, người ta thường quên thu hẹp quyền token mặc định
- Do không biết chính xác cần phạm vi quyền nào, người dùng dễ cấp quyền token quá mức cần thiết
- Quyền truy cập mặc định của
- Mô hình quyền của GitHub càng gây nhầm lẫn khi bị ép vào một trục đơn
read/write/noneid-token: writecho phép đọc token OpenID Connect của workflow- Một số thao tác
GETcủa security advisory yêu cầu quyềnwrite, trong khi thao tác khác chỉ cầnread
Action ghim theo SHA có thể bị nhầm với commit từ fork
- Một tham chiếu như
actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18enhìn thì giống commit của khoactions/checkout, nhưng thực tế có thể không phải vậy - SHA đó là commit nằm trong một fork thuộc mạng
actions/checkout, và vì GitHub dùng alternates nên nó có thể trông như thuộc kho cha - Bài viết liên quan của Chainguard chia vấn đề thành ba phần
- Tham chiếu SHA của fork và tham chiếu SHA của kho đích không được phân biệt bằng hình thức hiển thị
- GitHub REST API
/repos/{user}/{repo}/commits/{ref}trả về phản hồi JSON như thể chỉ tham chiếu{user}/{repo}, ngay cả khi{ref}chỉ tồn tại trong fork - Nếu không phân biệt được SHA của fork và SHA không phải fork, có thể lách giới hạn nguồn tin cậy của GitHub Actions
- Cho tới nay, phản hồi của GitHub chủ yếu mới dừng ở mức thêm một đoạn ghi chú vào tài liệu
-
Hướng cải thiện
- Cần một chế độ paranoid workflow security để từ chối workflow rõ ràng không an toàn ngay tại thời điểm push
- Tương tự như cơ chế giám sát runtime kiểu AddressSanitizer, cần có khả năng đánh fail các mẫu nguy hiểm về bảo mật trong lúc workflow đang chạy
- Ví dụ: fail nếu dùng
actions/checkoutvới ref không thuộc kho đích trongpull_request_target
- Ví dụ: fail nếu dùng
- Cũng có thể xem xét phương án ngừng hỗ trợ hoặc loại bỏ
pull_request_target - Ngay cả trong kho cá nhân, cũng cần có khả năng cấu hình phạm vi
GITHUB_TOKENmặc định hạn chế hơn như ở tổ chức/doanh nghiệp - Action ghim SHA mà SHA đó không có trong kho được tham chiếu mà chỉ có trong fork thì mặc định phải bị từ chối
Hệ thống kiểu thiếu tính nhất quán và khả năng biểu đạt
- Custom GitHub Action có thể định nghĩa input dưới
inputs:, nhưng input của action không có ép kiểu - Khai báo như
type: numberkhông hoạt động với input của action - Ngay trong nội bộ GitHub Actions, nơi hỗ trợ kiểu cũng không nhất quán
workflow_call: hỗ trợboolean,number,stringworkflow_dispatch: hỗ trợboolean,choice,number,string- action inputs: không hỗ trợ kiểu
- Ngay cả những input có hỗ trợ kiểu cũng không hỗ trợ cấu trúc dữ liệu phức hợp như mảng hoặc đối tượng
- Không thể có input mảng như
paths: [foo, bar, baz] - Không thể có input đối tượng với cấu trúc phân cấp dưới
headers:
- Không thể có input mảng như
- Thay vào đó, tác giả action buộc phải yêu cầu các định dạng input tạm bợ
- Tự triển khai parsing kiểu CSV như
paths: foo,bar,baz - Làm phẳng cấu trúc tự nhiên thành
header-foo,header-baz
- Tự triển khai parsing kiểu CSV như
- Cách làm này đều không tốt cho cả khả năng bảo trì lẫn bảo mật
- Phải tự quản lý một namespace input phẳng duy nhất
- Cuối cùng lại tạo ra một ngôn ngữ không đặc tả tùy tiện cho input phức tạp
-
Hướng cải thiện
- Người viết action và workflow cần có thể dùng
type:ở mọi nơi choicecũng không nên chỉ bị giới hạn trongworkflow_dispatchmà phải dùng được ở mọi nơi- Khi có thể suy luận kiểu tĩnh, thay đổi workflow sai kiểu phải bị từ chối ngay tại thời điểm push
- Cần có
type: objectvàtype: array - Dù không thể hoàn hảo vì kiểu nội bộ có thể không đồng nhất, vẫn có thể tốt hơn hiện tại
- Nếu cần, có thể truyền dưới dạng chuỗi đã được tuần tự hóa JSON
- GitHub Actions đã có sẵn hàm
fromJSON(...)
- Người viết action và workflow cần có thể dùng
Action chính thức gắn trực tiếp với niềm tin vào nền tảng
- Hệ sinh thái bên thứ ba của GitHub Actions có rất nhiều action chất lượng cao
- Bên dưới đó là các action chính thức do GitHub duy trì
- Tác vụ
gitcốt lõi:actions/checkout - Tác vụ GitHub và quản lý kho:
actions/{upload,download}-artifact,actions/cache,actions/stale - Thiết lập thiết yếu:
actions/setup-python,actions/setup-node
- Tác vụ
- Những action này có tính phổ dụng và tầm quan trọng cao, nên việc có triển khai chính thức được duy trì mang lại giá trị lớn
- Nhưng số lượng action chính thức lại ít, và ngay cả những tác vụ kết nối trực tiếp tới tính năng GitHub đôi khi cũng không được cung cấp dưới dạng action chính thức
- Ví dụ: action để thêm pull request vào merge queue theo cách lập trình
- GitHub CLI có
gh pr merge, nhưng không được phơi bày thành action
-
Các ví dụ action chính thức bị ngừng duy trì
actions/create-release: ngừng duy trì từ tháng 3/2021- Người dùng được khuyến nghị chuyển sang workflow do cộng đồng duy trì
- Một ví dụ tiêu biểu là
softprops/action-gh-release actions/upload-release-asset: bị đánh dấu ngừng duy trì cùng thời điểm vớiactions/create-releaseactions/setup-ruby: ngừng duy trì từ tháng 2/2021- Người dùng được khuyến nghị chuyển sang
ruby/setup-ruby - Bản thân việc chuyển đổi tương đối ít đau đớn, nhưng cảm giác rằng các thành phần cốt lõi có thể bị bỏ rơi lại ảnh hưởng xấu đến niềm tin vào nền tảng
- Nếu thiếu các action chính thức chất lượng cao, người dùng sẽ tiếp tục trực tiếp xử lý bề mặt API của GitHub và tiếp tục mắc lỗi bảo mật
-
Hướng cải thiện hệ sinh thái
- Những tác vụ kết nối trực tiếp các phần khác nhau của hạ tầng GitHub, và hiện vẫn phải làm thủ công bằng gọi REST API hoặc chạy
gh, rất đáng được cung cấp dưới dạng action chính thức - Có thể hợp tác với các action lớn của bên thứ ba để tạo ra một tổ chức bán chính thức như
community-actions- Các action đã được GitHub rà soát
- Tuân thủ các thực tiễn tốt nhất về bảo mật kho lưu trữ
- Cập nhật semantic version
- Có lộ trình tin cậy rõ ràng cho các action quan trọng trong hệ sinh thái
- Những tác vụ kết nối trực tiếp các phần khác nhau của hạ tầng GitHub, và hiện vẫn phải làm thủ công bằng gọi REST API hoặc chạy
Các công cụ hiện có và lộ trình GitHub
- Nhiều người đã đề xuất
nektos/act, công cụ mô phỏng GitHub Actions cục bộ- Hữu ích để lặp nhanh và debug workflow đơn giản
- Nhưng do image và event đôi khi không hoàn toàn giống môi trường thực của GitHub, nó bị xem là công cụ có độ sai lệch
rhysd/actionlintđược dùng cho lint cục bộ và lint bảo mật- Hạn chế là chỉ lint được workflows chứ không lint được actions
- GitHub Actions extension for VS Code cung cấp lint trong editor và tích hợp workflow của kho
- Dựa trên JSON schema công khai
- Cung cấp hiển thị workflow đang chạy, hoàn thành biến, v.v.
- Nhưng vẫn có những lỗi không phát hiện được như gõ sai tên secrets hoặc gõ sai tên output được tạo động, nên việc debug kiểu add-commit-push vẫn còn cần thiết
- Julian Dunn, người phụ trách quản lý sản phẩm của GitHub Actions, đã chia sẻ một số tính năng đang được phát triển và các ưu tiên
- Debug tương tác có trong lộ trình công khai của GitHub Actions
- Việc chuyển từ workflow pinning dựa trên tag/SHA sang phương thức bất biến hơn cũng nằm trong lộ trình công khai
- GitHub coi sức khỏe và chất lượng của hệ sinh thái action chính thức là ưu tiên, và đang theo đuổi chiến lược giữ số lượng action chính thức ở mức nhỏ để có thể dành đủ công sức bảo trì và quan tâm cho từng action
1 bình luận
Ý kiến trên Hacker News
Có hai cách tiếp cận với workflow của GitHub Actions. 1) “Lập trình” bằng GitHub Actions, thậm chí những việc như gửi email cũng gắn thêm công cụ từ marketplace; YAML phình lên 500–1000 dòng, đầy rẫy câu điều kiện và trở nên khó hiểu
2) Chỉ dùng GitHub Actions để “cấu hình”, và liên tục tự hỏi “có thể đẩy độ phức tạp YAML này sang script không?”. Nếu cả việc gửi email cũng đưa vào script, workflow chỉ còn khoảng 50–60 dòng, có thể debug script ở local, nên gần như loại bỏ vòng lặp push-debug-commit ngớ ngẩn. Mỗi lần vào một đội mới, tôi đều nói cách 1 là con đường điên rồ còn cách 2 mới hợp lý, nhưng khoảng một nửa vẫn chọn cách 1. Thiếu công cụ debug và vendor lock-in cũng ít trở thành vấn đề hơn nhiều nếu chọn cách 2
Tuy vậy, nhiều khi chỉ đẩy mọi thứ sang một ngôn ngữ lập trình đàng hoàng vẫn chưa đủ. Có những trường hợp phải dùng tính năng riêng của nhà cung cấp trong GHA, biểu diễn phụ thuộc giữa các job, hoặc gọi các REST API đã được trừu tượng hóa tốt thành action. Có thể tự triển khai lại bằng ngôn ngữ mình muốn, nhưng vendor dependency cũng không biến mất và vẫn mong manh. Rốt cuộc, đề xuất giá trị vendor lock-in của GHA rất mạnh, nên để thuyết phục mọi người theo cách 2 cần có lợi thế mạnh hơn
Điều này không chỉ đúng với GHA mà với mọi build server. Build server nên là một trình chạy script bổ sung lịch sử, quản lý artifact, quyền hạn/audit; còn quy trình build thực tế nên được ủy thác cho repository của thứ cần build
Tham khảo: có nektos/act để tái hiện hành vi của GHA ở local: https://github.com/nektos/act
Build/test/ký/phát hành... nên được viết thành script càng portable càng tốt, và các script này luôn phải chạy được ở local. Tôi chỉ xem GitHub là nơi tự động chuẩn bị môi trường để chạy các script đó và thực sự thực thi chúng
Vòng lặp git commit, push, wait là một trải nghiệm người dùng tệ hại. Người dùng xứng đáng có pipeline có tính di động chạy được ở mọi nơi, kể cả máy local. Act giải quyết phần nào vấn đề này, nhưng nhìn chung không đại diện đúng hoàn toàn cho môi trường thật
Có nhiều pipeline không thể chạy ở local như production, nhưng ở các giai đoạn phát triển ít quan trọng hơn thì không có lý do gì không capture những workflow như vậy và chạy chúng ở local. Garden cung cấp pipeline portable và thêm caching trên toàn bộ đồ thị phụ thuộc. Một số khách hàng giảm thời gian chạy hơn 80%, và lập trình viên có thể biết ngay test pass/fail mà không cần push lên git trước. Đây là open source: https://github.com/nektos/act, https://docs.garden.io
make releaseHoàn toàn đồng cảm với nỗi khổ khi debug các lần chạy GH Actions. Công cụ có được chỉ là bật debug rồi chạy lại. Có quá nhiều commit rác được tạo ra chỉ để sửa hoặc debug pipeline, mà phần lớn chỉ ở mức ném bừa vào xem có chạy không
Ngay cả những việc rất cơ bản như logic có thể tái sử dụng cũng bị làm phức tạp không cần thiết hoặc tài liệu quá tệ. Khi biết rồi thì khá dễ, nhưng tài liệu của GitHub thì thật tệ. Trông như muốn có khả năng tái sử dụng thì phải công khai action hoặc đặt nó ở một repository khác, nhưng thực ra có thể tạo một file YAML mới chứa logic tái sử dụng. Chỉ có điều nó phải nằm ở root của thư mục workflows thì mới hoạt động. Làm việc với GH Actions thật sự rất đau khổ, nhưng một khi đã chạy được thì rất tiện. Ước gì có một local runner để test action trước khi commit và push
Đây cũng không chỉ là vấn đề riêng của GitHub. Các nền tảng CI lớn khác cũng chẳng tốt hơn mấy về workflow và tích hợp. Giờ tôi script hóa mọi thứ tối đa có thể
GitHub Actions là một hệ thống CI/CD tệ hại. Không thể chạy song song các bước trên cùng một VM, và các tác vụ dựa trên container bị đối xử như công dân hạng hai
Vì vấn đề thứ nhất, không thể song song hóa việc thiết lập credential cục bộ hoặc dependency môi trường. Nhìn
google-github-actions/setup-gcloudmất hơn 1 phút là bực mình. Vì vấn đề thứ hai, rất khó cấu hình theo kiểu dùng Dockerfile trong repository để mô tả môi trường CI; khi nội dung image thay đổi thì CI build lại image và cho các workflow phụ thuộc vào image đó chờ, còn nếu nội dung không đổi thì không build lại mà chạy ngay với các dependency đã cài sẵn. Với GitHub Actions, rốt cuộc lần nào cũng phải cố nạp lại cache. Cache bị giới hạn 5GB, trả tiền cũng không tăng được, và bị đẩy ra theo FIFO, nên nếu vượt 5GB thì thực tế cũng như không có. Tôi thật sự nhớ Concourse. Nó làm được những thứ như job song song, trigger pipeline tùy chỉnh, SSH vào môi trường CI để debug, chạy tác vụ một lần không cần pipeline, truyền nội dung thư mục giữa các job mà không cần tạo artifact. GitHub Actions gần giống một CI/CD đồ chơi nổi lên nhờ ngưỡng vào thấp: chỉ cần thêm một file vào.github/workflowslà dùng được ngay. Tốt để lôi kéo người dùng, nhưng khi vượt qua các tính năng ban đầu thì chưa đủ mạnh để gọi là “tốt nhất”Debug bằng SSH và các tác vụ một lần đúng là như mơ
Tôi không hiểu sao việc GitHub không phân biệt được tham chiếu SHA từ fork và non-fork, khiến fork có thể vượt qua thiết lập bảo mật của GitHub Actions, đến giờ vẫn chưa được giải quyết
Nếu có thể dễ dàng vượt qua kiểm soát bảo mật thì đó là vấn đề bảo mật nghiêm trọng. Đúng là phải thuyết phục ai đó dùng SHA của mình, nhưng social engineering thường là phần dễ hơn
Nói thật là tệ đến mức đáng xấu hổ. Việc lỗi build không liên quan lại tình cờ chỉ gửi thông báo cho maintainer mới nhất vừa merge cuối cùng cũng rất kỳ lạ. Nếu maintainer mới được thêm không báo qua Matrix, có khi tôi còn không biết update/build của mình đã fail suốt một tuần
cache action nhìn bằng mắt cũng thấy rõ là hỏng, nhưng dường như không có người quản lý. Nếu UI hỏng hoặc tab bị unload thì cũng không thể tail build log của bước đó. Gần như không có abstraction nào để làm workflow có thể portable giữa các node worker. Image mặc định gần như là thảm họa. Ban đầu tôi chỉ bực vì nó quá cồng kềnh, nhưng càng đào sâu càng có cảm giác “việc này chắc do người Microsoft không biết Linux phụ trách”. Không có nỗ lực nào cung cấp image nhẹ hơn cho người dùng Nix hoặc Docker. Tôi đang rời khỏi GitHub, và lý do chính là Actions đã khiến tôi tỉnh hẳn. Lý do tôi không lập trình bằng YAML là vì tôi xem YAML như một nỗi ô nhục được tạo ra khi tiền VC đổ vào một hệ sinh thái không biết những công nghệ hiện đại và thực sự hữu ích
Rất khuyến nghị https://pre-commit.ci. Tôi không liên quan gì đến dự án, chỉ là một người dùng hài lòng
Ý tưởng là viết hoặc dùng các hook hiện có để kiểm tra mã trước khi commit và sửa nếu có thể; sau khi push, CI sẽ kiểm tra lại và nếu cần thì tự động tạo cả commit sửa lỗi. Caching tự động rất tốt nên nhanh đến mức khó tin, và vì dùng cùng một cấu hình trên máy phát triển cục bộ và CI nên giảm được rất nhiều vấn đề debug. Miễn phí cho mã nguồn mở. Nó không làm những việc như phát hành tự động, chỉ kiểm tra thôi, nhưng làm việc kiểm tra đó rất tốt
Nếu muốn kiểm tra chính mã nguồn, có thể chạy cả kiểm tra tĩnh với
skip_install = True. Chỉ cần chạy trong một container đã cài tox như công cụ toàn cục và có đủ các phiên bản Python cần thiết. Ví dụ có image như https://github.com/georgek/docker-python-multiversion. Nó không còn được bảo trì, nhưng cập nhật thì dễ. Boilerplate kiểu đặtpre-commit run --all-files --show-diff-on-failuretrong[tox] envlist = py{310,311},[testenv],[testenv:check]là đủSau khi trải qua vòng lặp
git commit; git push; repeatquá nhiều lần, tôi phát hiện https://github.com/mxschmitt/action-tmate. Nó mở kết nối shell giữa các bước nên không giải quyết được mọi vấn đề, nhưng đôi khi chắc chắn làm giảm đau khổCá nhân tôi muốn có thể gắn báo cáo HTML vào action run mà không cần dùng những thứ như
actions/upload-artifacthiện nayĐặc biệt trong các build test, nhiều lúc chỉ muốn xem nhanh báo cáo HTML đầu ra. Cách tôi biết hiện tại là upload-artifact hoặc GH Pages, nhưng GH Pages không lý tưởng khi có nhiều báo cáo đầu ra trong cùng một repository, hoặc khi muốn xem nhanh một báo cáo cũ chứ không phải bản mới nhất. Sẽ rất tốt nếu có một action
attach-reportđơn giản, gắn link báo cáo HTML vào phần tóm tắt job và khi bấm vào thì render HTML. Các hệ thống CI/CD tự động khác hỗ trợ sẵn việc thu thập và xem báo cáo HTML phong phú hơn nhiều$GITHUB_STEP_SUMMARYmà không cần qua bước upload artifact hay tương tựTôi xem GH Actions về cơ bản khá giống một bản đổi thương hiệu của “Azure Pipelines” từ Microsoft. Từ góc nhìn của người đã dùng mọi dạng trước đây của pipeline build và release trong TFS/VSTS/AzDO, đội này không giỏi việc này
Azure Pipelines cuối cùng cũng tạm dùng được là vì mọi cách tiếp cận họ thử trước đó đều thất bại đúng nghĩa. Từng có cả một dự án chạy pipeline cục bộ để có vòng lặp edit-run-debug trong môi trường cá nhân mà không cần commit, nhưng dĩ nhiên đã bị hủy: https://github.com/microsoft/azure-pipelines-agent/pull/2687/files#diff-570b52bcb927a5365c22d17a21e8e19e1ba3427c7f3ec16ea64b7b3d14e4ee20. Dù vậy vẫn có các công cụ cải thiện chất lượng cuộc sống. Ví dụ extension VS Code nhận biết cú pháp: https://marketplace.visualstudio.com/items?itemName=ms-azure-devops.azure-pipelines. Nói hơi gây tranh cãi một chút, nếu dùng XML thay vì YAML thì chỉ với khai báo xmlns ở đầu, hầu hết trình soạn thảo mã tốt đã có thể tự kiểm chứng mà không cần người dùng can thiệp thêm. XML rất kinh khủng, nhưng khi vứt bỏ tất cả, chúng ta cũng đánh mất nhiều tính năng hữu ích đi kèm