GitHub Actions seharusnya hanya untuk menyiapkan environment (OS, toolchain build, …) dan menjalankan skrip (shell, Python, bat, ps1…). Meski GitHub down, selama environment-nya siap, build harus bisa dilakukan di mana saja. Kalau lihat workflow GitHub Actions belakangan ini, rasanya jadi berpikir apa perlu sampai repot-repot mencari dan memakai hal seperti itu. Dulu sekali (?) Ansible juga begitu lalu gagal.
Saya rasa Rust akan menjadi pengganti C++ ketimbang C. C pada praktiknya adalah satu-satunya (atau mungkin yang terakhir) bahasa yang memungkinkan kita memperkirakan kode yang akan dihasilkan compiler…
Sepertinya ini bukan terjemahan harfiah tanpa parafrasa seperti yang biasanya diharapkan dari penerjemah.
Saya mencoba memasukkan teks perkenalan Claude Cowork, dan seperti di bawah ini, emoji dan bullet list pun muncul.
(Asli)
How is using Cowork different from a regular conversation? In Cowork, you give Claude access to a folder of your choosing on your computer. Claude can then read, edit, or create files in that folder. It can, for example, re-organize your downloads by sorting and renaming each file, create a new spreadsheet with a list of expenses from a pile of screenshots, or produce a first draft of a report from your scattered notes.
(Terjemahkan dengan ChatGPT)
🧠 Perbedaan Cowork dan percakapan biasa
Di Cowork, Anda memberi Claude izin untuk mengakses folder tertentu di komputer Anda yang Anda pilih sendiri. Claude kemudian dapat membaca, mengedit, atau bahkan membuat file baru di folder tersebut.
Misalnya, Claude dapat
merapikan file-file di folder unduhan dan mengganti namanya,
membuat spreadsheet baru dengan daftar pengeluaran dari sekumpulan tangkapan layar, atau
menyusun draf awal laporan berdasarkan catatan Anda yang tercecer.
Saya terus memakai Gemini; tepat setelah dirilis memang sangat bagus, tetapi makin lama justru terasa makin menurun kecerdasannya.
Salah satu penyebab utamanya adalah 'merujuk ke percakapan sebelumnya', dan jika sampai ditambah kecerdasan yang dipersonalisasi, sepertinya akan makin memburuk.
Sebenarnya, bahkan meningkatkan performa 2~3 kali lipat dengan merombak seluruh kode pun sudah sulit, jadi sungguh luar biasa bisa mencapai peningkatan hingga 400 kali lipat hanya dengan mengubah beberapa baris saja.
Kalau jadi 2 kali lebih cepat, mungkin itu karena melakukan sesuatu yang cerdas, dan kalau jadi 100 kali lebih cepat, itu cuma karena berhenti melakukan hal yang bodoh
Menurut saya itu bukan perkataan yang sepenuhnya salah, tetapi dalam kasus yang terkait dengan kernel, saya rasa bahkan menyadari bahwa itu lambat pun pasti benar-benar sulit.
Bagaimana kalau memisahkan perangkat khusus untuk game? Saya sendiri hampir tidak main game jadi tidak melakukannya, tetapi orang-orang yang memang bermain biasanya hampir seperti itu.
Ah, saya lulus pada Februari tahun ini dari jurusan yang berkaitan dengan komputer dan sampai sekarang masih belum punya pekerjaan. Saya sudah menggunakan Linux sejak 2015, bahkan sebelum mulai belajar pengembangan!
Pada akhirnya, meski tidak disebutkan secara langsung dalam artikel ini, ini sama saja dengan mengakui bahwa strategi Apple untuk membangun lingkungan AI pada level yang mereka inginkan secara in-house di dalam ekosistem Apple telah gagal.. (setelah Apple Car juga) Rasanya jadi berpikir, bagaimana kalau mereka bergerak sekitar 2 tahun lebih cepat.
Terima kasih atas materi dan ringkasannya yang detail. Awalnya saya kira ini mirip dengan Capabilities di Linux, tetapi ternyata pendekatannya mencakup hingga analisis dinamis.
task_plan.mdtampaknya sama dengan metode yang saya gunakan saat ini. Akan sangat praktis kalau ini bisa dilakukan secara otomatis.GitHub Actions seharusnya hanya untuk menyiapkan environment (OS, toolchain build, …) dan menjalankan skrip (shell, Python, bat, ps1…). Meski GitHub down, selama environment-nya siap, build harus bisa dilakukan di mana saja. Kalau lihat workflow GitHub Actions belakangan ini, rasanya jadi berpikir apa perlu sampai repot-repot mencari dan memakai hal seperti itu. Dulu sekali (?) Ansible juga begitu lalu gagal.
Saya rasa Rust akan menjadi pengganti C++ ketimbang C. C pada praktiknya adalah satu-satunya (atau mungkin yang terakhir) bahasa yang memungkinkan kita memperkirakan kode yang akan dihasilkan compiler…
Era ketika Architecture dan QA Engineer akan bertahan hidup akan datang. Menilai apakah ini benar atau tidak benar....
Sepertinya ini bukan terjemahan harfiah tanpa parafrasa seperti yang biasanya diharapkan dari penerjemah.
Saya mencoba memasukkan teks perkenalan Claude Cowork, dan seperti di bawah ini, emoji dan bullet list pun muncul.
(Asli)
How is using Cowork different from a regular conversation? In Cowork, you give Claude access to a folder of your choosing on your computer. Claude can then read, edit, or create files in that folder. It can, for example, re-organize your downloads by sorting and renaming each file, create a new spreadsheet with a list of expenses from a pile of screenshots, or produce a first draft of a report from your scattered notes.
(Terjemahkan dengan ChatGPT)
🧠 Perbedaan Cowork dan percakapan biasa
Di Cowork, Anda memberi Claude izin untuk mengakses folder tertentu di komputer Anda yang Anda pilih sendiri. Claude kemudian dapat membaca, mengedit, atau bahkan membuat file baru di folder tersebut.
Misalnya, Claude dapat
Dalam ulasan Claude Cowork yang ditulis Simon Willison juga ada kekhawatiran soal serangan prompt injection, dan ternyata memang cepat terjadi.
Saya rasa akan lebih baik jika diterapkan pemfilteran agar domain tertentu sama sekali tidak bisa diposting.
Itu tergantung pada kemampuan kompiler.
Kalau merakit kode yang sama, hasilnya akan terlihat.
Orang-orang ffmpeg sepertinya berpikir bahwa Rust bukan berarti lebih cepat daripada C wkwk https://www.memorysafety.org/blog/rav1d-perf-bounty/
Saya terus memakai Gemini; tepat setelah dirilis memang sangat bagus, tetapi makin lama justru terasa makin menurun kecerdasannya.
Salah satu penyebab utamanya adalah 'merujuk ke percakapan sebelumnya', dan jika sampai ditambah kecerdasan yang dipersonalisasi, sepertinya akan makin memburuk.
Sebenarnya, bahkan meningkatkan performa 2~3 kali lipat dengan merombak seluruh kode pun sudah sulit, jadi sungguh luar biasa bisa mencapai peningkatan hingga 400 kali lipat hanya dengan mengubah beberapa baris saja.
Luar biasa sekali.
Menurut saya itu bukan perkataan yang sepenuhnya salah, tetapi dalam kasus yang terkait dengan kernel, saya rasa bahkan menyadari bahwa itu lambat pun pasti benar-benar sulit.
Yah. Mungkin cuma sebatas penolakan dari para pengguna berat.
Sangat membantu 👍👍
Bagaimana kalau memisahkan perangkat khusus untuk game? Saya sendiri hampir tidak main game jadi tidak melakukannya, tetapi orang-orang yang memang bermain biasanya hampir seperti itu.
Ah, saya lulus pada Februari tahun ini dari jurusan yang berkaitan dengan komputer dan sampai sekarang masih belum punya pekerjaan. Saya sudah menggunakan Linux sejak 2015, bahkan sebelum mulai belajar pengembangan!
Sepertinya apakah Google mampu membangun dan menyediakan infrastruktur yang diinginkan Apple juga sangat memengaruhi pilihan tersebut.
Pada akhirnya, meski tidak disebutkan secara langsung dalam artikel ini, ini sama saja dengan mengakui bahwa strategi Apple untuk membangun lingkungan AI pada level yang mereka inginkan secara
in-housedi dalam ekosistem Apple telah gagal.. (setelah Apple Car juga) Rasanya jadi berpikir, bagaimana kalau mereka bergerak sekitar 2 tahun lebih cepat.Siri... masih bocah, sih.
Terima kasih atas materi dan ringkasannya yang detail. Awalnya saya kira ini mirip dengan Capabilities di Linux, tetapi ternyata pendekatannya mencakup hingga analisis dinamis.