Jumlah Hari Tanpa Insiden GitHub

• Days Without GitHub Incidents adalah halaman yang menampilkan jumlah hari yang telah berlalu tanpa incident GitHub
• Saat ini, area jumlah hari hanya ditampilkan sebagai ... days, sehingga jumlah harinya yang spesifik tidak bisa diketahui
• High Score ditampilkan sebagai 2026
• Angka kunci yang bisa dilihat di halaman tersebut adalah jumlah hari saat ini dan High Score
• Jumlah hari saat ini muncul bukan sebagai angka, melainkan dalam bentuk placeholder

[GN⁺]

Opini Hacker News

• Belakangan ini saya memindahkan semua proyek ke instance Forgejo yang di-host sendiri, dan sejauh ini cukup puas. Juga lebih cepat
  Kalau sedang mencari alternatif GitHub, ini layak dilihat, dan pilihannya memang ada

  • Memang bukan tren lagi, tetapi Phabricator juga pantas disebut sebagai alternatif GitHub yang bisa di-host sendiri
    Justru UI yang “jadul” terasa seperti kelebihan ketika banyak UI lain sekarang sangat buruk
  • Saya selalu kurang sreg dengan GitHub, tetapi git sendiri sudah terasa mengesankan sejak pertama kali saya mencobanya
    Saya memindahkan proyek pribadi dari instance Gitea lama ke Forgejo dan sangat puas
  • Bagaimana dengan Gitea?

• Menyatukan seluruh platform menjadi satu angka menurut saya tidak adil. Mirip seperti menjumlahkan seluruh AWS menjadi satu angka

  • Di sisi lain, saat mengoperasikan deployment yang cukup kompleks, kita mudah tenggelam dalam dashboard CPU, memori, I/O, metrik aplikasi, pendaftar, pengguna/sesi aktif
    Jadi, memikirkan cara mengekspresikan kondisi keseluruhan sistem sebagai satu angka tunggal itu berguna. Misalnya, sesi pengguna aktif dibagi jumlah koneksi database lalu disesuaikan dengan kapasitas memori
    Jika berupa satu digit, kita bisa terbiasa dengan rentang normalnya dan menaruhnya di tempat yang selalu terlihat. Memang tidak menunjukkan detail, tetapi kalau nilainya berubah kita tinggal masuk ke metrik spesifik, jadi ini bisa bekerja baik sebagai ringkasan dasar untuk mengecek “apakah semuanya normal?”
  • Kalaupun halaman status dipecah seperti sekarang dan gangguan git push serta git pull dilacak terpisah, jika itu hanya cukup menjadi lelucon yang sedikit dibesar-besarkan, maka itu mendekati tipu daya dan penggelembungan SLA dan tidak seharusnya dibiarkan
    Ada area inti yang dipakai hampir semua orang seperti Git, issue, pull request, dan Actions, dan kalau salah satunya rusak, berarti situsnya rusak. Halaman status seharusnya menunjukkan seberapa sering ini terjadi
  • Ini jelas situs meme, dan semakin rendah angkanya, semakin lucu memenya
    Orang yang benar-benar mencari informasi akurat akan pergi ke halaman status resmi
  • Jika hanya S3, EC2, EKS, dan RDB saja punya uptime yang mirip dengan seluruh GitHub saat ini, semua orang pasti akan tahu
    Masalah pada wiki repositori, statistik commit, atau gist tidak terlalu penting. Yang penting adalah kombinasi layanan seperti PR, Actions, dan Discussions yang dipakai bersama dan saling bergantung
    Bahkan jika dibuat satu persentase tunggal untuk tiap komponen dari kedua sistem itu, GitHub tetap akan tertinggal. Mungkin hari tanpa gangguannya bisa bertambah beberapa hari, tetapi ini bukan perbandingan yang sesederhana itu
  • Dari sudut pandang pengguna, perhitungan seperti ini masuk akal. Namun dari sudut pandang MSFT atau GitHub, angka ini adalah metrik yang cukup memalukan
    Mereka tentu ingin membuat orang memakai semua fitur platform dan menciptakan ketergantungan yang kuat, tetapi jika sebagian fiturnya terus rusak, pengguna sulit merasa percaya diri untuk mengadopsi lebih banyak fitur
    Semakin banyak yang dipakai, semakin besar kemungkinan salah satunya bermasalah, tetapi bagi perusahaan-perusahaan seperti ini tampaknya keandalan bukan lagi tujuan

• Bagi kami ini adalah masalah kelangsungan bisnis yang nyata. Kami cukup terikat dengan GitHub Enterprise, tetapi jika keadaan seperti ini terus berlanjut, mungkin kami harus pindah dari cloud ke on-premise

  • Kalau memang mengarah ke sana, sebaiknya semua Actions yang dibutuhkan di-cache secara lokal. Kalau tidak, hasilnya tidak akan jauh lebih baik

• Saat ini saya sedang menyiapkan Knot yang di-host sendiri untuk dipakai di tangled.org
  Alasan utamanya memang karena AtProto keren dan self-hosting itu menyenangkan, tetapi juga karena saya ingin bergerak ke arah memiliki sendiri infrastruktur yang meng-host proyek saya
  Sistem Knot milik Tangled terasa seperti abstraksi yang kuat dalam hal ini. Datanya di-host di AtProto Repository, tetapi hosting dan pengelolaan AtProto Application yang menampilkannya ke dunia bisa diserahkan ke pihak ketiga
  Bahkan jika Tangled hilang, saya bisa membawa login AtProto saya ke platform lain dan mengarahkannya ke Knot saya, sementara pengaturan hosting bisa tetap seperti semula. Jauh lebih praktis daripada harus meng-host sendiri seluruh web app yang terisolasi di sudut internet

• Ada banyak komentar yang membela GitHub di sini. Membela perusahaan bernilai miliaran dolar saja sudah agak aneh, apalagi perusahaan yang memegang sebagian besar perangkat lunak open source
  Mungkin ini karena rasa simpati. Tetapi selalu sulit diterima bahwa untuk berkontribusi pada proyek yang kita cintai, kita harus menerima politik internal dan praktik perusahaan besar. Saya tidak merasa berutang pada GitHub
  Terutama jika mereka sendiri gagal memenuhi bagian mereka dalam kesepakatan. Dengan setumpuk besar kredit Azure, mereka pada dasarnya mendapatkan akses bebas ke repositori perangkat lunak dunia

  • Kalau pertanyaannya dibalik, apa alasan untuk menentang GitHub sampai-sampai sesama manusia yang berjuang menjaga operasional tidak pantas mendapatkan kebaikan dan rasa hormat yang paling minimal?
    Tidak bisakah kita memisahkan bisnis dari orang-orang yang bekerja keras di belakangnya?
    Mereka juga tahu bahwa orang-orang seperti kita bergantung pada mereka. Mereka tahu layanan mereka adalah “nada sambung” bagi kapasitas pengembangan perangkat lunak dunia, dan sangat peka terhadap dampaknya
    Ke mana perginya #hugops? Apakah itu langsung hilang hanya karena orang-orang itu bekerja di perusahaan yang tidak disukai?
  • Tepatnya, yang dibela adalah Microsoft, perusahaan bernilai triliunan dolar
  • Menurut saya itu tergantung apakah kita membayar atau tidak. Kalau membayar, wajar punya ekspektasi tinggi dan menuntut akuntabilitas
    Kalau menerima layanan gratis, marah juga masuk akal, tetapi pada saat yang sama memang itulah yang didapat sesuai yang dibayar
  • Mengejutkan bahwa persepsi terhadap GitHub tidak banyak berubah bahkan setelah akuisisi
    Bersamaan dengan WSL, bagi banyak orang hal itu seolah menyeimbangkan keadaan dan menempatkan Microsoft kembali ke kubu “boleh dicoba dipercaya dulu”
    Kejadian kali ini bukan hanya menggerus biaya operasional, tetapi juga banyak goodwill yang sudah terkumpul. Tiba-tiba pemberitaan buruk jadi lebih mudah terlihat dan lebih sulit diabaikan
  • Dua kelompok yang paling gigih membela perusahaan bernilai miliaran dolar adalah pengguna HN dan para penggemar Nintendo

• Katanya commit GitHub naik 14x dibanding tahun lalu

  • Apakah ini karena agen AI mendorong spam?
  • Commit atau push? Dari sudut pandang pengukuran beban, jumlah commit bukan metrik yang terlalu berarti
  • 14x itu gila. Terutama karena kualitas dan jumlah perangkat lunak dunia nyata nyaris tidak bergerak
    Orang sempat berharap kemampuan coding ala agen yang baru ini bisa menghasilkan nilai nyata dan memperbaiki kualitas. Namun yang terlihat justru enshittification dan stagnasi. Sebenarnya semua token ini dipakai untuk apa?
  • Commit GitHub naik 14x dibanding tahun lalu, lalu kenapa?
    Kalau Microsoft tidak bisa melakukan scale, siapa lagi yang bisa? Kalau belum mampu menyediakan layanan, mereka seharusnya berhenti menjualnya sampai benar-benar siap
    Ini pengulangan fiasco nada sibuk AOL dial-up pertengahan 90-an. Hanya saja kali ini, alih-alih marah, orang malah membuat alasan untuk perusahaan triliunan yang malang dan kewalahan itu
  • Saya benar-benar sulit memahami klaim bahwa ini karena commit AI dan sepenuhnya soal volume trafik
    Kenaikan beban satu digit, yaitu sekitar 14x, seharusnya tidak menyebabkan gangguan separah ini
    Jika membandingkan apa yang dilakukan GitHub dan throughput-nya dengan perusahaan media sosial, pembayaran, atau platform video, penjelasan bahwa ini murni masalah beban terasa tidak masuk akal
    Ini tampaknya jauh lebih mirip platform yang sejak awal sudah punya masalah mendasar, lalu diperparah oleh kenaikan beban

• Lelucon ini berhasil karena semua orang diam-diam menerima risiko konsentrasi yang cukup besar demi kenyamanan

• https://repo.autonoma.ca/treetrek
  Ini karya saya: penampil Git mentah berbasis PHP yang gratis, open source, fitur minimal, tanpa cache, tanpa dependensi, tanpa autentikasi maupun otorisasi
  Saya membuatnya karena GitList meledakkan ruang disk dan memori hosting bersama akibat bug cache, dan saya ingin menyatukan repositori GitHub, BitBucket, dan GitLab
  Ada kepuasan tersendiri dari self-hosting dan tidak dikendalikan oleh perubahan hati pihak ketiga

• Aplikasi ini juga kemungkinan besar adalah aplikasi vibe coding yang ikut berkontribusi pada gelombang aplikasi vibe coding yang menjatuhkan GitHub
  Saya kasihan pada para pegawai GitHub yang berusaha mati-matian menjaga kapal ini tetap mengapung, sementara Microsoft tampak melakukan semua hal yang bisa dilakukan untuk menenggelamkan kapalnya sendiri