Kejahatan terhadap GitHub dan perangkat lunak

 (eblog.fly.dev)
1 poin oleh GN⁺ 22 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • GitHub digunakan layaknya inti dari infrastruktur pengembangan, tetapi dinilai bahwa keandalan dasarnya terguncang karena insiden yang sering terjadi, halaman yang lambat, dan kerusakan di browser
  • Microsoft mengatakan lonjakan beban terjadi karena agentic workflows, tetapi kritik juga membesar bahwa GitHub mendorong penggunaan dengan secara langsung menyisipkan fitur Copilot dan agent ke dalam layanannya
  • Dalam eksperimen repositori minimal, GitHub mengunduh 291 request dengan respons terkompresi 15MiB dan hasil ekstraksi 544.564 baris, sangat kontras dengan 11 request milik Codeberg
  • Dalam pengukuran frontend, GitHub menggunakan heap normal sekitar 69MiB, dan halaman pull request rust-lang memakai 148MiB, sehingga dinilai sangat boros untuk halaman yang berpusat pada teks
  • Kesimpulannya, pemborosan GitHub bukan sekadar penurunan mutu produk, melainkan kegagalan perangkat lunak yang mendahulukan fitur AI dan prioritas yang berpusat pada investor alih-alih menyelesaikan masalah pengguna

Keandalan dan prioritas GitHub

  • GitHub digunakan layaknya inti dari infrastruktur pengembangan perangkat lunak, tetapi keandalan dasarnya dipertanyakan karena downtime, penurunan performa, dan masalah kompatibilitas browser
  • Catatan GitHub Status menunjukkan puluhan insiden setiap bulan, dan bahkan menurut halaman status resmi serta standar SLA, ada kondisi yang dapat dianggap sebagai pelanggaran
  • GitHub disebut sering rusak di Firefox dan Safari, halaman komentar dan review pull request lambat, serta penggunaan RAM dan lonjakan heap dinilai berlebihan
  • GitHub Actions dinilai lambat dan kurang terdokumentasi, sementara tampilan log disebut telah menyebabkan kebocoran memori dan browser crash selama bertahun-tahun
  • Perilaku cache pada action dasar seperti setup-go juga dinilai tidak memiliki invalidasi atau terlalu sederhana
  • Ada situs seperti githubstars.com yang secara terbuka mengiklankan penjualan bintang, dan dikutip pula frasa dari makalah Carnegie Mellon bahwa “fake stars are highly related to malicious activities”
  • Sasaran yang seharusnya dituju GitHub adalah sistem terdistribusi berperforma tinggi, sangat tersedia, dan berkapasitas besar, tetapi produk nyatanya dinilai memprioritaskan fitur AI dan alur agent ketimbang keandalan dasar

Beban “agentic” dan tanggung jawab Microsoft

  • Dalam ‘an update on github availability’, GitHub menyatakan bahwa sejak paruh kedua Desember 2025, agentic development workflows meningkat tajam, begitu pula pembuatan repositori, aktivitas pull request, penggunaan API, otomasi, dan workload repositori besar
  • Penjelasan ini memperlakukan kenaikan beban seolah fenomena eksternal, tetapi memicu kritik bahwa GitHub dan perusahaan induknya Microsoft justru secara langsung mendorong penggunaan AI dan “agents” dengan menyisipkannya ke berbagai produk
    • Hampir semua bilah atas halaman GitHub memiliki 3 tombol AI, dan 2 di antaranya khusus untuk memulai agent, sementara banyak halaman memiliki 4 tombol
    • Di area kanan atas halaman landing repositori biasa, ada 4 cara untuk menjalankan Copilot
    • GitHub selama bertahun-tahun mensubsidi biaya penggunaan alat untuk mendorong adopsi, dan sebuah tautan kritik menyebut hal itu setara dengan mensubsidi denial of distributed service terhadap dirinya sendiri
  • Microsoft menjelaskan bahwa satu pull request dapat menyentuh repositori Git, pemeriksaan kemungkinan merge, branch protection, GitHub Actions, pencarian, notifikasi, izin, webhooks, APIs, pekerjaan latar belakang, cache, dan database
  • Pada skala besar, efisiensi kecil pun dapat berujung pada pendalaman antrean, cache miss, beban DB, keterlambatan indeks, dan amplifikasi lalu lintas retry, tetapi inefisiensi GitHub dinilai bukan pada tingkat “kecil”, melainkan raksasa dan sangat berlebihan
  • Microsoft mengatakan “availability first, then capacity, then new features”, tetapi dalam changelog publik GitHub, selama 30 hari setelah pembaruan tersebut, catatan patch memunculkan “copilot” 59 kali, “agent” 8 kali, dan “performance” serta “reliability” 0 kali
    • Filter changelog memiliki kategori copilot tersendiri, tetapi tidak memiliki kategori performance dan reliability
    • Visual Studio Code juga terintegrasi langsung dengan GitHub dan fitur “agentic”, dan dikritik karena terus menambah fitur agent bahkan saat fungsi dasar seperti terminal bawaan justru memburuk
  • Pernyataan Microsoft bahwa mereka sedang mengurangi unnecessary work, memperbaiki caching, mengisolasi layanan penting, menghapus single point of failure, memindahkan jalur sensitif performa, mengurangi keterkaitan tersembunyi, membatasi blast radius, dan menerapkan graceful degradation ditafsirkan sebagai pengakuan bahwa desain sistemnya salah

Mengapa frontend memberi petunjuk tentang masalah backend

  • Akar masalah keandalan GitHub berada di backend dan database, tetapi itu tidak terlihat dari luar; yang bisa diamati justru kode frontend seperti HTML, JavaScript, dan CSS yang diunduh setiap kali
  • Seperti sulit mempercayai dapur restoran bersih jika terlihat tikus di ruang makannya, kerusakan mencolok pada frontend GitHub dipandang mengisyaratkan masalah backend, meski tidak membuktikannya
  • Halaman landing repositori GitHub, GitLab, dan Codeberg terdiri dari daftar tautan, elemen UX kecil, tombol, tab, dan kotak pencarian, dengan sangat sedikit elemen mahal seperti media interaktif atau gambar
  • Halaman seperti ini semestinya bisa berjalan dengan murah di hampir semua komputer atau ponsel bahkan tanpa koneksi internet yang baik, dan disebut bahwa GitHub dulu benar-benar berfungsi seperti itu bahkan pada iPhone 4 dan koneksi 3G
  • Jika fungsinya sama, kode terbaik didefinisikan sebagai kode yang paling sedikit menggunakan bandwidth jaringan, waktu CPU, dan RAM, serta memiliki bug paling sedikit
  • Jumlah bug frontend tidak bisa diketahui langsung, tetapi riset historis menyatakan jumlah bug biasanya sebanding dengan jumlah baris kode
    • Steve McConnel, Code Complete, 2nd Ed (2004) dikutip menyebut rata-rata industri untuk perangkat lunak yang dikirimkan adalah 1–25 error per 1.000 baris kode
    • Microsoft Applications Division dikutip pernah mengalami 10–20 defect per 1.000 baris kode selama pengujian internal, dan 0,5 defect per 1.000 baris pada produk yang dirilis

Desain eksperimen dan metode pengumpulan

  • Untuk mengurangi variabel perancu, kecepatan internet dibatasi ke koneksi “fast 3G”
    • Ini adalah pengaturan untuk mengurangi dampak perubahan kondisi jaringan dan mensimulasikan pengalaman pelanggan GitHub di situasi yang kurang ideal seperti wilayah pedesaan
  • Ketiga layanan menggunakan repositori minimal yang sama, ghsucks
    • Satu branch master
    • Satu file README.md
    • 0 elemen tambahan seperti issue dan tag
  • Browser dan komputer yang digunakan sama
    • Firefox
    • Apple Macbook Pro M5 Max
    • RAM 48GiB
  • Empat jenis halaman diperiksa pada tiap layanan
    • Halaman “landing”: tata letak kode
    • Halaman “pull requests” atau “merge requests”
    • Halaman “issues”
    • Halaman “settings”
  • HAR HTTP dikumpulkan dalam keadaan cache bersih untuk menganalisis request jaringan, lalu snapshot heap diambil setelah pemuatan selesai untuk memperoleh estimasi penggunaan RAM dalam kondisi stabil
  • Untuk analisis HAR digunakan anhar buatan sendiri, untuk analisis dukungan kompresi digunakan testcompress, dan untuk verifikasi silang digunakan pagespeed.web.dev

Penggunaan heap dan pemborosan memori

  • Penggunaan heap pada halaman repositori default diukur sebesar GitHub 69MiB, GitLab 68MiB, Codeberg 14MiB, dan eblog.fly.dev 1.3MiB
  • Merender halaman issue pertama di https://github.com/rust-lang/rust/pulls menggunakan RAM sebesar 148MiB
  • 148MiB adalah memori yang lebih besar daripada iPhone asli, dan dinilai sebagai pemborosan yang sangat parah untuk halaman yang berfokus pada teks dengan beberapa tautan
  • Memori perangkat yang dijadikan pembanding antara lain Apple iphone 1 128MiB, iphone 4 512MiB, Sony playstation 2 32MiB, dan Nintendo wii 88MiB

Perbandingan jumlah request dan skala respons

  • anhar adalah program Go yang mem-parsing HAR JSON, lalu otomatis memformat HTML·CSS·JavaScript dari respons dengan deno fmt, kemudian menghitung ukuran request·respons, total per MIME, waktu muat, dan jumlah baris respons
  • Metrik utamanya adalah ukuran request, ukuran respons terkompresi yang benar-benar diterima, ukuran dan jumlah baris respons setelah diekspansi usai penerapan deno fmt, Content-Load sebagai waktu muat HTML dasar, dan Load sebagai waktu muat seluruh konten
  • Halaman repositori Codeberg diukur dengan total 11 request, request 9KiB, respons 1MiB, respons ekspansi 1MiB, hasil ekspansi 3.480 baris, Content-Load 2.934s, dan Load 3.172s
  • Halaman repositori GitHub diukur dengan 291 request, request 178KiB, respons terkompresi 15MiB, respons ekspansi 22MiB, hasil ekspansi 544.564 baris, Content-Load 843ms, dan Load 21.330s
    • application/javascript: 214 request, respons 12MiB, respons ekspansi 19MiB, hasil ekspansi 481.849 baris
    • text/css: 42 request, respons 2MiB, hasil ekspansi 60.016 baris
    • GitHub pulls: 266 request, terkompresi 14MiB, ekspansi 20MiB, hasil ekspansi 487.922 baris, Content-Load 592ms, Load 6.754s
    • GitHub settings: 255 request, terkompresi 14MiB, ekspansi 20MiB, hasil ekspansi 486.067 baris, Content-Load 778ms, Load 6.963s
  • GitLab lebih kecil daripada GitHub, tetapi tetap berat
    • Repositori GitLab: 78 request, respons 8MiB, hasil ekspansi 101.682 baris, Content-Load 6.880s, Load 12.941s
    • GitLab merge_requests: 65 request, respons 7MiB, hasil ekspansi 90.567 baris, Content-Load 6.947s, Load 12.096s
    • GitLab edit: 117 request, respons 7MiB, hasil ekspansi 71.916 baris, Content-Load 6.964s, Load 13.302s
  • GitHub mengambil sekitar 540 ribu baris kode dan data bahkan untuk menampilkan repositori kosong, yang dibandingkan lebih banyak daripada DOOM 35 ribu baris, Windows Quake 120 ribu baris, MS-DOS 4.0 332 ribu baris, dan Zig toolchain 460 ribu baris
  • Struktur yang membuat setiap halaman mengambil 40 file CSS dan ratusan JavaScript dinilai sebagai masalah
  • Pemecahan chunk di Webpack secara teori bisa memisahkan fungsi inti dan fungsi opsional serta menguntungkan untuk caching·CDN, tetapi di sini ditafsirkan menghasilkan perlambatan pemuatan karena setiap file memerlukan request HTTP terpisah
  • Menunggu 22 detik hanya untuk melihat halaman kosong dinilai sulit diterima, dan bahkan pada koneksi fiber lebih dari 1GiB/s serta prosesor konsumen berperforma tinggi, dibutuhkan lebih dari 1 detik sampai repositori bisa mulai cukup bisa digunakan

Perbandingan dukungan kompresi

  • Kompresi disajikan sebagai cara berguna untuk menurunkan beban pada klien, server, dan jalur perantara
  • gzip adalah standar kompresi yang sudah terbukti dan seharusnya didukung semua situs web, sementara zstd memiliki karakteristik performa yang baik tetapi lebih modern sehingga dukungannya dipandang sebatas “kalau ada bagus”
  • testcompress adalah program Go yang menguji apakah URL mendukung kompresi gzip dan zstd, dan bila tidak didukung, langsung mengompresi body respons untuk menunjukkan potensi penghematan
  • eblog.fly.dev/startingsystems3.html: encoding yang didukung zstd gzip, asli 575.77KiB, gzip 67.64KiB, zstd 60.17KiB
  • github.com/ef0xa/ghsucks: encoding yang didukung gzip, asli 224.70KiB, gzip 43.27KiB, zstd 37.96KiB
  • gitlab.com/efronlicht/ghsucks: encoding yang didukung gzip, asli 43.08KiB, gzip 11.48KiB, zstd 11.34KiB
  • codeberg.org/efronlicht/ghsucks: encoding yang didukung n/a, asli 43.88KiB, gzip 13.00KiB, zstd 12.79KiB

Hasil PageSpeed mobile

  • Pada pengukuran mobile pagespeed.web.dev, Codeberg mendapat PASS dengan First Contentful Paint 1.2s, Largest Contentful Paint 1.3s, dan Interaction to Next Paint 86ms
  • eblog.fly.dev mendapat PASS dengan First Contentful Paint 1.1s, Largest Contentful Paint 1s, dan Interaction to Next Paint N/A
  • GitHub mendapat FAIL dengan First Contentful Paint 1.8s, Largest Contentful Paint 2.1s, dan Interaction to Next Paint 242ms
  • GitLab mendapat FAIL dengan First Contentful Paint 2.1s, Largest Contentful Paint 2.4s, dan Interaction to Next Paint 243ms

Penilaian per layanan

  • GitHub

    • Mengambil sekitar 300 file, sekitar 550.000 baris kode dan data, dengan perkiraan jumlah bug sebanyak 550
    • Content-Load diringkas sekitar 800ms, Load keseluruhan sekitar 7s, dan heap steady-state sekitar 69MiB
    • Mendukung gzip tetapi tidak mendukung zstd
    • Mendapat nilai F, dengan penilaian bahwa bobot kodenya sangat besar
    • GitHub dikritik karena memuat semua tema di semua halaman, terlepas dari apakah tema itu digunakan atau tidak
    • Karena pagespeed.web.dev menunjukkan bahwa 528KiB JavaScript dan CSS sama sekali tidak terpakai, bagian ini dinilai bisa mulai dikurangi terlebih dahulu
    • Jika tetap harus berada di GitHub, muncul saran untuk menilai bahwa ini melanggar SLA GitHub sendiri dan mengajukan tiket dukungan untuk meminta pengembalian dana

  • GitLab

    • Content-Load sekitar 7s, Load sekitar 13s, dan memuat 7MiB dalam lebih dari 70 file, sekitar 10.000 baris
    • Heap steady-state sekitar 68MiB, dan mendukung gzip tetapi tidak mendukung zstd
    • Mendapat nilai D+, dengan penilaian bahwa meski tidak seboros GitHub, layanan ini tetap mengambil terlalu banyak sumber daya dan tidak memanfaatkannya dengan baik
    • Mengambil lebih dari 1MiB JavaScript dan CSS, tetapi ada bagian yang sama sekali tidak digunakan dalam praktik, dan bahkan pada kode yang dipakai pun ada chunk 3MiB yang memerlukan 255ms hanya untuk parsing
    • Dinilai bahwa halaman landing tidak memerlukan 55.000 baris CSS, dan baik CSS maupun JavaScript kemungkinan bisa dikurangi hingga sepersepuluh dari tingkat saat ini

  • Codeberg/Forgejo

    • Content-Load 2,9s, Load 3,1s, serta memuat 1MiB dalam 11 file, sekitar 1.100 baris
    • Heap steady-state sekitar 14MiB, dan tidak mendukung gzip maupun zstd
    • Mendapat nilai C+, dengan penilaian bahwa dasar-dasarnya ada, tetapi kurang perhatian pada detail dan pengalaman
    • Tidak melakukan minify HTML dianggap masalah kecil, tetapi tidak mendukung kompresi dinilai sebagai kekurangan besar
    • Sebagian besar JavaScript dan CSS tidak diperlukan untuk merender halaman, tetapi masalahnya adalah keduanya dimuat dengan cara yang menghalangi rendering
    • Muncul saran untuk menggabungkan payload JavaScript dan CSS guna mengurangi jumlah request, serta mendukung kompresi gzip dan zstd pada payload HTTP termasuk HTML
    • Karena merupakan perangkat lunak bebas, kemampuan untuk pindah ke instance lain atau self-hosting disajikan sebagai kelebihan

  • eblog.fly.dev

    • eblog.fly.dev/startingsystems3.html diukur dengan Content-Load 76ms, Load 1,1s, 766KiB dalam 5 file, dan sekitar 3.800 baris
    • Satu file HTML berukuran 576KiB dan dapat dikompresi hingga sekitar 70KiB dengan zstd
    • Heap steady-state sekitar 11MiB, serta mendukung zstd dan gzip
    • Mendapat nilai A-, dengan penilaian bahwa secara keseluruhan bagus, tetapi HTML-nya tetap besar dan berulang meski sudah mempertimbangkan kompresi, dan halaman yang seharusnya bisa selesai dengan satu request justru membutuhkan 5 request

Bukan sekadar penurunan mutu produk, tetapi masalah biaya

  • “enshittification” diringkas sebagai proses ketika produk yang awalnya menguntungkan pengguna dan pelanggan bisnis kemudian berubah merugikan pengguna, lalu juga merugikan pelanggan bisnis, dan akhirnya menguntungkan operator
  • Microsoft dan GitHub memang tidak sepenuhnya terlepas dari Embrace, Extend, Extinguish, tetapi masalah di sini dinilai berbeda karena bukan hanya menciptakan biaya bagi pengguna dan pelanggan bisnis, melainkan juga bagi Microsoft
  • Codebase yang membengkak secara langsung meningkatkan biaya server dan bandwidth, serta secara tidak langsung menghabiskan waktu engineer untuk memelihara codebase yang tidak stabil dan terlalu besar
  • Jika diasumsikan GitHub memiliki sekitar 800 engineer, dan masing-masing bekerja 40 jam per minggu selama 48 minggu per tahun, itu setara dengan 1.536.000 jam-engineer per tahun
  • Sebagian besar masalah frontend dinilai bisa diperbaiki atau setidaknya diredam oleh engineer yang kompeten dalam waktu kurang dari seminggu hanya dengan mengikuti rekomendasi pagespeed
  • Alasan perbaikan tingkat rendah yang dapat menghemat biaya tetap dibiarkan ditafsirkan sebagai salah satu dari ketidakpedulian, ketidakmampuan yang ekstrem, atau kondisi terhambat oleh kepemimpinan yang berpusat pada AI dan investor
  • Perangkat lunak digambarkan sebagai alat yang kuat dan indah karena jika sekali ditulis dengan benar, ia bisa disalin secara sempurna, selamanya, dan gratis sehingga semua orang dapat menggunakannya
  • Kesimpulannya, pemborosan dan ketidakmampuan GitHub serta layanan serupa bukan sekadar produk yang buruk, melainkan kejahatan terhadap perangkat lunak

Bacaan terkait

1 komentar

 
GN⁺ 22 jam lalu
Opini Lobste.rs

  • Akan bagus jika Trac dan Sourcehut juga dimasukkan dalam perbandingan ini

  • Empat tombol agen AI itu lucu, dan angka-angka relatif dalam tulisan ini juga menarik, tetapi meski saya sama sekali tidak bermaksud membela GitHub, beberapa detail dalam tulisan ini terasa kurang konteks sehingga tidak cukup kuat untuk mendukung argumen penulis
    Penggunaan memori idle bisa jadi menandakan bahwa GitHub melakukan lebih banyak hal daripada Codeberg, tetapi sulit menarik kesimpulan yang bermakna dengan membandingkan penggunaan RAM absolut pada komputer dengan RAM 48GB dengan komputer pemandu Apollo
    Memformat bundel JavaScript yang sudah diminifikasi untuk memperkirakan jumlah baris kode lalu membandingkannya dengan jumlah baris proyek Zig tanpa dependensi juga seperti membandingkan apel dengan jeruk. Coba dekompilasi executable Zig-nya dan lihat jadi berapa baris
    Saya juga tidak paham rekomendasi bahwa Codeberg “harus menggabungkan payload JavaScript dan CSS untuk mengurangi jumlah request”. Dari cara penulis membahas “overhead tambahan” dari request HTTP, saya jadi ragu apakah penulis paham HTTP/2
    Masih banyak yang bisa dibahas soal performa halaman web, tetapi akan saya tulis terpisah; untuk sudut pandang yang lebih baik soal topik serupa, saya sarankan membaca lagi tulisan Danluu tahun 2017 tentang web bloat: https://danluu.com/web-bloat

  • Jika penulis sedang membaca ini, mungkin ada baiknya melihat perdebatan Casey Muratori dan Uncle Bob. Yang pertama menemukan penurunan performa yang sangat menarik
    “Saya tidak bisa menahan diri lalu melihat capture performa Chrome, dan saya tahu siapa pelakunya :) Ternyata itu ‘emoji picker’!”
    “Saya hanya melihat sekilas kodenya, tetapi sepertinya masalahnya adalah setiap kali karakter dimasukkan, ‘emoji picker’ menelusuri balik untuk memeriksa apakah yang baru diketik itu emoji”
    Aduh. Meski begitu, dalam kasus ini pelakunya mungkin bukan kode frontend GitHub, melainkan browser berbasis Chromium

  • Ungkapan bahwa “Codeberg adalah produk yang bergantung pada donasi independen dan disediakan oleh relawan bebas” tidak akurat
    Codeberg bergantung pada anggota. Bukan hanya dari iuran, tetapi juga secara kebijakan, dan saat ini iuran saja belum cukup untuk mempekerjakan karyawan penuh waktu sehingga mereka sangat bergantung pada relawan, tetapi setahu saya mereka juga punya kontraktor
    Saya tidak mengikuti Codeberg terlalu dalam (saya lebih condong ke sourcehut), tetapi fakta bahwa ini adalah koperasi merupakan salah satu inti proposisi nilainya. Mereka juga berusaha memublikasikan pengeluaran secara transparan. Contoh: https://blog.codeberg.org/codebergs-budget-of-2026.html
    Jika Anda memakai Codeberg, mungkin ada baiknya mempertimbangkan menjadi anggota sekarang: https://join.codeberg.org/

  • Saya benar-benar benci GitHub. Masalah saya bukan uptime, tetapi betapa lambatnya dan boros memorinya. “Diff sebesar ini tidak ditampilkan secara default”, serius?
    Ini juga rusak untuk alur kerja pengembangan yang wajar. Jika PR di-rebase, umpan balik review dan komentar hilang, dan jika commit di-squash, umpan balik review dan komentar juga hilang
    Bahkan jika ada tautan ke komentar tertentu, jika commit terkait hilang maka komentarnya juga ikut hilang \o/
    Kalau ada perbaikan bug, mereka menyuruh membuat PR, dan bahkan jika bug itu sudah diperbaiki oleh perubahan lain, karena PR dan bug berada di level yang sama maka PR mati tetap selamanya berada di antrean review
    Jika saya ingin tahu commit ini memperbaiki bug apa, yang ditampilkan hanya riwayat PR. Seolah-olah yang harus dilihat itu PR, bukan bug, dan kalau ingin tahu bug-nya Anda harus mencarinya sendiri

    • Konsep “pull request” sendiri, seperti git, berasal dari pengembangan kernel Linux. Alurnya adalah meminta maintainer kernel untuk “pull” patch ke mainline
      GitHub membuat alur ini lebih mudah dengan tombol “fork”, menambahkan username terpusat agar lebih “sosial”, lalu menempelkan pelacak isu dan wiki sampai akhirnya menguasai dunia. Secara bisnis, memang itu langkah yang jenius
      Tetapi keseluruhan alurnya masih cocok untuk pengembangan open source di mana orang-orang terpisah meminta patch mereka di-“pull”
      Saya tidak paham kenapa tim pengembangan yang rapat, dengan mekanisme nyata berupa “mendiskusikan branch dan menyetujui merge”, harus memakai “pull request”. Pull dari apa? Semuanya ada di repositori yang sama, dan perubahannya juga sudah di-push
      Bahkan terlepas dari soal istilah, tidak adanya perubahan kumulatif, komentar yang stabil, dan diff untuk kumpulan perubahan itu tidak masuk akal
      Maaf jadi ikut mengeluh panjang soal GitHub. Apakah ada alternatif yang lebih baik? Tentu saja tidak ada yang bisa memaksa orang lain memakainya…

  • Saya beberapa kali melihat reaksi “grafik tanpa label sumbu atau titik data individual selalu mencurigakan” terhadap grafik yang dipublikasikan GitHub
    Nilai maksimum memang ditampilkan di grafik, jadi secara visual kita bisa memperkirakan bahwa nilai tengah sumbu y masing-masing sekitar 45M, 0.7B, dan 10M. Tentu saja, kecuali diam-diam itu skala log dan bebannya bukan naik 100000 kali lipat
    Saya sendiri tidak akan menyebut grafik buruk di sini sebagai sesuatu yang “mencurigakan”; saya menganggapnya hanya komunikasinya buruk. Secara pribadi, output ggplot mentah selalu lebih saya suka
    Saya setuju dengan sentimen umumnya, tetapi pada bagian soal kuda gemuk dan banyak tabel saya agak sulit mengikutinya. Meski begitu, kalau saya harus membuat daftar semua cacat GitHub, mungkin saya juga akan mulai bermimpi menunggang kuda gemuk menuju matahari terbenam
    Saya juga pernah mulai membuat daftar serupa lalu menyerah ketika masalah UX/performa sudah mencapai kira-kira 12 poin. Analisis mendetail dalam tulisan ini bagus, dan saya berharap tim GitHub benar-benar meninjaunya
    Seperti yang pernah saya katakan, Microsoft perlu menugaskan beberapa insinyur performa ke GitHub. Sampai metrik performa benar-benar masuk ke KPI inti, pembengkakan ini akan terus berlanjut dan platform lain akan terlihat makin menarik. Jika nanti ada CEO GitHub berikutnya, saya harap ini dijadikan prioritas

    • Anda berasumsi sumbu y pada grafik dimulai dari 0. Dalam grafik gaya bisnis seperti ini, sering kali tidak begitu
      Sangat umum melihat klaim “pertumbuhan luar biasa” dengan garis grafik melintang diagonal di seluruh area gambar, padahal sumbu y-nya hanya bergerak dari 100 ke 101

  • Saya setuju dengan komentar bahwa “log GitHub Actions bocor memori dan sudah bertahun-tahun membunuh browser saya, dan sampai sekarang juga belum ada cara untuk sekadar me-pipe stdout ke suatu tempat”
    Sayangnya Forgejo juga mewarisi ini. Kadang saya menerima notifikasi build gagal dan ingin cepat melihatnya dari ponsel, tetapi dalam banyak kasus browser ponsel saya bahkan tidak bisa memuat outputnya sama sekali

  • Saat membuka tulisan ini saya sepenuhnya mengira ini hanya akan jadi keluhan lain soal uptime GitHub, tetapi ternyata ini adalah tulisan yang dengan tenang dan masuk akal menilai masalah GitHub, GitLab, dan Codeberg saat ini lalu bahkan mengusulkan solusi, jadi saya terkejut dengan cara yang menyenangkan
    Akan bagus jika Tangled juga dimasukkan dalam perbandingan
    Penulis sebaiknya menulis sedikit CSS agar situsnya bisa dibaca di ponsel juga. Saya harus memakai mode baca browser
    Satu-satunya bagian yang tidak saya setujui adalah klaim bahwa tidak ada situs yang boleh memuat lebih dari satu file JavaScript/CSS
    Jika 550 ribu baris JavaScript itu semuanya ada dalam satu file, parsing dan eksekusinya akan memakan waktu jauh lebih lama. CSS mungkin boleh dibundel, tetapi misalnya pola satu chunk umum dan satu chunk per-rute bisa berguna. Pendekatan seperti ini atau yang mirip sepertinya akan tetap banyak dipakai

  • Halaman ini tidak bisa dibaca
    Dan kalau tidak suka GitHub ya jangan dipakai. Mengejutkan bahwa orang punya waktu untuk mengumpulkan daftar keluhan sepanjang ini. Kalau dipakai untuk kerja ya dibayar, kalau tidak ya pakai yang lain