15 November 2011

Debat Tanenbaum – Torvalds seri 2


Catatan: Tulisan ini dibuat dari karya berjudul: Open Sources - Voices from the 
Open Source Revolution (Kode-Sumber Terbuka - Suara-suara dari Revolusi Kode-Sumber
Terbuka) penerbit O'Reilly yang merupakan esai pilihan dari beberapa pengarang tentang dunia 
Kode-Sumber Terbuka. Tulisan ini diambil dari Apendiks A dan dibuat dalam 
beberapa seri (saya belum tahu akan menjadi berapa postingan) karena cukup panjang. 
Terjemahan dari karya ini diusahakan mendekati nada dalam tulisannya dan berusaha 
menggunakan bahasa yang sejelas mungkin. Saya hanya berharap karya ini dapat dinikmati 
seperti membaca karya aslinya dalam bahasa inggris. So, selamat menikmati tulisan ini.

HAK CIPTA

"Piranti-Lunak Bebas" adalah Hak Cipta (c) 1998 Richard M. Stallman

Salinan utuh (verbatim) dan duplikasi diijinkan dalam berbagai bentuk media
selama mencantumkan pernyataan ini.

"Riwayat Singkat Tradisi Peretas" dan "Balas Dendam Sang Peretas" adalah
Hak Cipta (c) 1998 Eric S. Raymond

Tulisan ini bebas; anda dapat mendistribusikannya dan/atau mengubahnya
dibawah ketentuan GNU Lisensi Publik Umum seperti yang dipublikasikan
oleh Yayasan Piranti-Lunak Bebas; baik versi 2 dari Lisensi itu, atau
(sesuai pilihan anda) versi selanjutnya.

Tulisan ini disebarluaskan dengan harapan dapat berguna, tetapi
TANPA GARANSI; juga tanpa jaminan DAPAT DIPERJUALBELIKAN atau
SESUAI UNTUK TUJUAN TERTENTU. Lihat GNU Lisensi Publik Umum
untuk jelasnya.

Lihat Apendiks B untuk sebuah salinan dari GNU Lisensi Publik Umum,
atau kirimkan pertanyaan kepada Yayasan Piranti-Lunak Bebas,
59 Temple Place, Suite 330, Boston, MA 02111-1307, USA

  Eric Raymond
  esr@thyrsus.com
  6 Karen Drive
  Malvern, PA 19355

"Piranti-Lunak Kode-Sumber Terbuka" adalah bebas;
anda dapat mendistribusikannya dan/atau mengubahnya
dibawah ketentuan GNU Lisensi Publik Umum seperti yang dipublikasikan
oleh Yayasan Piranti-Lunak Bebas; baik versi 2 dari Lisensi itu, atau
(sesuai pilihan anda) versi selanjutnya.

Tulisan ini disebarluaskan dengan harapan dapat berguna, tetapi
TANPA GARANSI; juga tanpa jaminan DAPAT DIPERJUALBELIKAN atau
SESUAI UNTUK TUJUAN TERTENTU. Lihat GNU Lisensi Publik Umum
untuk jelasnya.

Lihat Apendiks B untuk sebuah salinan dari GNU Lisensi Publik Umum,
atau kirimkan pertanyaan kepada Yayasan Piranti-Lunak Bebas,
59 Temple Place, Suite 330, Boston, MA 02111-1307, USA

  Bruce Perens
  bruce@pixar.com
  c/o Pixar Animation Studios
  1001 West Cutting #200
  Richmond, CA 94804

Semua tulisan yang tidak dicantumkan di atas, bebas disebarluaskan
TANPA MODIFIKASI selama pernyataan ini disertakan.
Seluruh materi memiliki hak cipta (c) 2000 O'Reilly & kolega.
Semua Hak dilindungi.

Apendiks A: Debat Tanenbaum-Torvalds seri 2

Dari: kevin@taronga.taronga.com (Kevin Brown)
Bahasan: Re: Sistim LINUX usang
Tanggal: 4 Feb 92 08:08:42 GMT
Organisasi: University of Houston

Dalam tulisan kt4@prism.gatech.EDU (Ken Thompson) menulis:

>sudutpandang boleh jauh dalam hal ketidakterkaitannya dari kegunaannya.
>Banyak, jika bukan sebagian besar, dari piranti-lunak yang kita gunakan
>mungkin usang menurut kriteria desain terbaru. Kebanyakan pengguna mungkin
>tidak peduli jika internal dari sistim operasi yang mereka gunakan, sudah
>usang. Mereka berhak lebih tertarik dalam kinerjanya dan kemampuannya di
>tingkat pengguna.
>
>Saya biasanya setuju bahwa mikrokernel adalah gelombang masa depan.
>Bagaimanapun, menurut hemat saya, lebih mudah mengimplementasikan kernel
>monolitik. Hal ini lebih mudah juga membuatnya menjadi kekacauan ketika
>terburu-buru saat memodifikasinya.

Seberapa sulit sebenarnya membuat struktur dari pohon sumber-kodenya kernel monolitik dimana sebagian besar perubahan tidak menimbulkan dampak negatif besar pada sumber-kodenya? Bahaya apa saja ketika menjalankannya, dan saran apa dari anda untuk menghadapinya?

Saya kira yang saya tanyakan ini: seberapa sulit untuk mengatur sumber-kode sehingga sebagian besar perubahan pada kernel tetap terlokalisasi dalam cakupan, meski kernelnya sendiri adalah monolitik?

Saya pikir anda memiliki pengalaman bertahun-tahun dengan kernel monolitik :-), jadi saya rasa anda punya jawaban terbaik untuk pertanyaan seperti ini.

Kevin Brown

Dari: rburns@finess.Corp.Sun.COM (Randy Burns)
Bahasan: Re: Sistim LINUX usang
Tanggal: 30 Jan 92 20:33:07 GMT
Organisasi: Sun Microsystems, Mt. View, Ca.

Dalam tulisan ast@cs.vu.nl (Andy Tanenbaum) menulis:

>Dalam tulisan torvalds@klaava.Helsinki.
>FI (Linus Benedict Torvalds) menulis:

>Tentu saja 5 tahun dari sekarang akan berbeda, tetapi 5 tahun dari sekarang
>setiap orang akan jalankan GNU bebas pada 200 MIPS, 64M komputer Sparc-5 mereka.

Yah, saya orangnya yang _senang_ bila hal ini benar-benar terjadi

>>Faktanya adalah bahwa linux lebih portabel daripada minix. Apa? saya dengar
>>kata anda. Itu benar – tapi bukan seperti yang ast (Andrew S Tanenbaum)
>>artikan: saya membuat linux menurut standar yang saya tahu caranya (tanpa
>>memiliki standar POSIX apapun di depan saya). Memindahkan hal ke linux
>>umumnya /lebih/ mudah daripada memindahkannya ke minix
………
>Maksud saya adalah menulis sebuah sistim operasi baru dimana terikat erat dengan
>bagian perangkat-keras tertentu, terutama yang aneh seperti jalur Intel, pada
>dasarnya salah.

Pertama-tama, bagian dari Linux yang setelannya paling bagus pada mesin 80×86 adalah kernel dan perangkatnya. Perasaan saya sih bahkan bila Linux hanyalah ukuran sementara untuk kita semua jalankan piranti-lunak GNU, itu masih bermanfaat memiliki kernel yang setelannya bagus untuk arsitektur yang paling banyak digunakan saat ini.

>Sebuah OS sendiri harus mudah dipindahkan ke landasan perangkat-keras baru.

Yah, satu-satunya bagian Linux yang tidak portabel adalah kernel dan pengendalinya (driver). Bandingkan dengan kompilator, perkakas, system tampilan dan sebagainya (compilers, utilities, windowing system etc). Ini benar-benar kecil usahanya. Karena Linux punya derajat besar dari kompabilitas pemanggilan dengan banyak OS portabel, saya tidak akan berkomentar jauh. Saya pribadi sangat berterimakasih memiliki OS yang sepertinya membuat beberapa dari kita dapat mengambil keuntungan dari piranti-lunak yang datang dari Berkeley, FSF, CMU dan sebagainya. Mungkin juga dalam 2-3 tahun saat ultra-BSD murah dan Hurd berkembang pesat, Linux mulai menjadi usang. Kembali, saat ini Linux memotong drastis biaya menggunakan alat seperti gcc, bison, bash yang berguna dalam mengembangkan OS seperti ini.

Dari: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Bahasan: Re: Sistim LINUX usang
Tanggal: 31 Jan 92 10:33:23 GMT
Organisasi: University of Helsinki

Dalam tulisan ast@cs.vu.nl (Andy Tanenbaum) menulis:

>Keterbatasan dari MINIX berhubungan sedikitnya sebagai bagian menjadi seorang
>profesor: Sebuah design yang terang-terangan untuk membuatnya berjalan di
>perangkat keras murah sehingga para mahasiswa dapat membelinya.

Baiklah: titik teknis nyata, dan satu yang membuat beberapa komentar saya tidak dapat dibenarkan. Tetapi pada saat yang sama, anda menembak diri sendiri sedikit di kaki: Sekarang anda mengaku bahwa banyak kesalahan minix karena terlalu portabel: termasuk mesin yang tidak benar-benar dirancang untuk jalankan unix. Asumsinya menuju ke fakta dimana minix sekarang tidak dapat ditambah untuk punya, katakan, seperti proses-laman (paging), bahkan untuk mesin yang mendukungnya. Ya, minix portabel, tapi anda bisa menulis ulang seperti “tidak mengunakan fitur apapun”, dan masih benar.

>Sebuah sistim berkas banyak-jalinan (multithreaded file system) adalah
>terobosan-singkat kinerja.

Salah. itu terobosan-singkat kinerja /pada mikrokernel/, Tetapi itu fitur otomatis saat anda menulis kernel monolitik – satu area dimana mikrokernel tidak bekerja terlalu baik (seperti yang saya tunjukkan dalam surat pribadi ke ast). Ketika menulis sebuah unix cara “usang”, anda otomatis dapat kernel banyak-jalinan (multithreaded kernel): setiap proses menjalankan tugas masing-masing, dan anda tidak harus membuat hal jelek seperti antrian-pesan untuk membuatnya bekerja efisien.

Selain itu, ada orang yang mempertimbangkan “hanya terobosan-singkat kinerja” penting: kecuali anda punya cray-3, saya rasa setiap orang akan capek menunggu depan komputer sepanjang waktu. Saya tahu karena saya sudah gunakan minix (dan ya, saya lakukan dengan Linux juga, dan itu /jauh/ lebih baik).

>Saya tetap berpandangan bahwa merancang sebuah kernel monolitik di tahun
>1991 adalah kesalahan mendasar. Bersyukurlah anda bukan mahasiswa saya.
>Anda tidak akan pernah dapat nilai tinggi untuk desain semacam itu :-)

Yah, saya mungkin tidak mendapatkan nilai terlalu bagus bahkan tanpa anda: Saya ada adu-mulut (sepenuhnya tidak berhubungan – bahkan tidak terkait dengan OS) dengan orang di universitas ini yang mengajar desain OS. Saya ingin tahu kapan saya akan belajar :)

>Maksud saya adalah menulis sebuah sistim operasi baru dimana terikat erat dengan
>bagian perangkat-keras tertentu, terutama yang aneh seperti jalur Intel, pada
>dasarnya salah.

Tapi poin /saya/ adalah bahwa sistim operasi /tidak/ terikat pada jalur prosesor: UNIX berjalan paling banyak dengan prosesor nyata kenyataannya. Ya, /implementasinya/ memang spesifik-perangkat-keras, tapi itu BESAR bedanya. Anda menyebutkan OS/360 dan MS-DOG sebagai contoh desain yang buruk karena tergantung pada perangkat kerasnya, dan saya setuju. Tetapi ada perbedaan besar antara ini dengan linux: API linux portabel (bukan karena saya pintar desain, tapi karena fakta bahwa saya memutuskan mengikuti OS yang cukup-baik-dipikirkan-masak-masak dan teruji: unix.)

Jika anda menulis program untuk linux hari ini, anda seharusnya tidak mendapat terlalu banyak kejutan saat anda cuma mengkompilasinya untuk Hurd di abad 21. Seperti yang telah tercatat (bukan hanya oleh saya), kernel linux merupakan bagian kecil dari sebuah sistim lengkap: kode-sumber penuh untuk linux yang saat ini berjalan sekitar 200kB terkompresi – kode-sumber penuh untuk tampaknya pengembangan sistim lengkap sedikitnya 10MB terkompresi (dan dengan mudah nambah, dan nambah lebih besar). Dan semua kode-sumber itu portabel, kecuali untuk bagian kernel mini ini yang anda dapat (mungkin: saya sudah lakukan) menulis ulang dari awal, kurang dari setahun tanpa /ada/ memiliki pengetahuan sebelumnya.

Nyatanya /seluruh/ kernel linux jauh lebih kecil daripada mesin-tergantung-386 dalam mach: i386.tar.Z untuk versi saat ini dari mach melebihi 800kB terkompresi (823391 bytes menurut nic.funet.fi). Memang, mach “agak” lebih besar dan punya fitur lebih banyak, tetapi itu seharusnya tetap mengatakan pada anda sesuatu.

Linus

Dari: kaufman@eecs.nwu.edu (Michael L. Kaufman)
Bahasan: Re: Sistimm LINUX usang
Tanggal: 3 Feb 92 22:27:48 GMT
Organisasi: EECS Department, Northwestern University

Saya sudah coba untuk mengirimkan dua tulisan ini dari tempat kerja, tapi saya rasa mereka tertelan. Jika anda sudah pernah melihatnya, maaf.

——————————————————————–

Andy Tanenbaum menulis artikel menarik (juga menarik mengetahui bahwa dia benar-benar membaca grup ini) tetapi saya pikir dia melupakan poin penting.

Dia Menulis:

>Seperti banyak kalian ketahui, untuk saya MINIX adalah sebuah hobi, …

Yang juga mungkin benar sebagian besar, jika bukan seluruhnya, untuk orang yang terlibat dalam Linux. Kami tidak mengembangkan sebuah sistim untuk mengambil-alih pasar OS, Kami cuma menghabiskan waktu dengan baik.

> Yang akan terjadi adalah mereka secara bertahap akan mengambil alih dari
> garis 80×86. Mereka akan jalankan program lama MS-DOS dengan
> menginterpretasikan 80386 di dalam piranti-lunak.

Nah jika ini terjadi, jika saya tetap ingin bermain dengan Linux, saya hanya tinggal jalankan saja di emulator 386 saya.

> Minix dirancang untuk mudah berpindah, dan telah berhasil dipindahkan
> dari sistim Intel ke sistem 680×0 (Atari, Amiga, Macintosh), SPARC,
> dan NS32016. Linux cukup terikat kuat dengan 80×86. Tidak dapat
> kemana-mana.

Itu bagusuntuk orang-rang yang punya mesin itu, tapi tidak ada makan siang yang gratis. Portabilitas itu didapat dari biaya beberapa kinerja dan beberapa fitur pada mesin 386. Sebelum anda memutuskan LINUX itu jangan digunakan, anda seharusnya berpikir tentang apa yang akan digunakan. Saya akan menggunakannya untuk memjalankan memori dan perhitungan intensif program grafik pada mesin 486 saya. Buat saya, kecepatan dan memori lebih penting baru ke depannya kedalaman-seninya dan portabilitas.

> Tetapi, sejujurnya, saya akan menyarankan mereka yang ingin sebuah OS
> “bebas” yang **CANGGIH** mencoba yang berbasis mikrokernel, OS
> portabel, mungkin seperti GNU atau sejenis seperti itu.

Saya tidak tahu basis mikrokernel bebas lainnya, portabel OS lain. GNU tetap piranti-lunak-ada-tidak-tidakjadipun-tidak (vaporware), dan kemungkinan tetap seperti itu untuk waktu ke depan. Apakah anda benar-benar punya satu untuk rekomendasi, atau anda hanya mempermainkan saya? ;-)

—————————————————————————

Dalam artikel ast@cs.vu.nl (Andy Tanenbaum) menulis:

>Maksud saya adalah menulis sebuah sistim operasi baru dimana terikat erat dengan
>bagian perangkat-keras tertentu, terutama yang aneh seperti jalur Intel, pada
>dasarnya salah. Sebuah OS sendiri harus mudah dipindahkan ke landasan
>perangkat-keras baru.

Saya pikir saya melihat dimana saya tidak setuju dengan anda sekarang. Anda melihat desain OS sebagai akhir dalam dirinya. Minix baik karena portabel/Mikro-kernel/dan sebagainya. Linux tidak baik karena monolitik/terikat erat dengan Intel/dan sebagainya. Itu bukan seikap yang aneh untuk seseorang dalam dunia akademis, tetapi itu juga bukan sesuatu yang anda harapkan dapat dibagikan secara universal. Linux tidak ditulis buat alat mengajar, ataupun buat latihan abstrak. Dia ditulis untuk semua orang untuk jalankan piranti-lunak jenis GNU _saat ini_. Fakta bahwa dia tidak boleh digunakan lima tahun lagi kurang penting dari fakta bahwa hari ini (Yah, sampai April mungkin) Saya dapat jalankan jenis piranti-lunak yang mau saya jalankan. Anda terus mengatakan Minix lebih baik, tetapi jika dia tidak dapat menjalankan piranti-lunak yang saya ingin jalankan, dia benar-benar tidak bagus (buat saya) sama sekali.

>Saat OS/360 ditulis dalam bahasa assembly untuk PC 360 IBM 25 tahun yang
>lalu, mungkin masih bisa dimaafkan. Saat MS-DOS ditulis khusus untuk 8088
>10 tahun lalu, ini kurang dari kata cerdas, seperti IBM dan Microsoft
>sekarang, hanya terlalu menyakitkan untuk menyadarinya.

poin sama. MSoft tidak datang dengan Dos untuk “menjelajahi batas-batas penelitian os”. Mereka lakukan untuk mendapatkan uang. dan mengingat fakta bahwa MS-DOS mungkin masih menjual lebih banyak dari orang lain meski dikumpulkan bersama, Saya tidak pikir seperti yang anda katakan mereka gagal _dalam tujuan mereka_. Bukan karena MS-Dos OS terbaik dalam hal apapun, tapi karena dia melayani kebutuhan mereka.

Michael

15 November 2011

Debat Tanenbaum – Torvalds seri 1


Catatan: Tulisan ini dibuat dari karya berjudul: Open Sources - Voices from the 
Open Source Revolution (Kode-Sumber Terbuka - Suara-suara dari Revolusi Kode-Sumber
Terbuka) penerbit O'Reilly yang merupakan esai pilihan dari beberapa pengarang tentang dunia 
Kode-Sumber Terbuka. Tulisan ini diambil dari Apendiks A dan dibuat dalam 
beberapa seri (saya belum tahu akan menjadi berapa postingan) karena cukup panjang. 
Terjemahan dari karya ini diusahakan mendekati nada dalam tulisannya dan berusaha 
menggunakan bahasa yang sejelas mungkin. Saya hanya berharap karya ini dapat dinikmati 
seperti membaca karya aslinya dalam bahasa inggris. So, selamat menikmati tulisan ini.

HAK CIPTA
"Piranti-Lunak Bebas" adalah Hak Cipta (c) 1998 Richard M. Stallman

Salinan utuh (verbatim) dan duplikasi diijinkan dalam berbagai bentuk media
selama mencantumkan pernyataan ini.

"Riwayat Singkat Tradisi Peretas" dan "Balas Dendam Sang Peretas" adalah
Hak Cipta (c) 1998 Eric S. Raymond

Tulisan ini bebas; anda dapat mendistribusikannya dan/atau mengubahnya
dibawah ketentuan GNU Lisensi Publik Umum seperti yang dipublikasikan
oleh Yayasan Piranti-Lunak Bebas; baik versi 2 dari Lisensi itu, atau
(sesuai pilihan anda) versi selanjutnya.

Tulisan ini disebarluaskan dengan harapan dapat berguna, tetapi
TANPA GARANSI; juga tanpa jaminan DAPAT DIPERJUALBELIKAN atau
SESUAI UNTUK TUJUAN TERTENTU. Lihat GNU Lisensi Publik Umum
untuk jelasnya.

Lihat Apendiks B untuk sebuah salinan dari GNU Lisensi Publik Umum,
atau kirimkan pertanyaan kepada Yayasan Piranti-Lunak Bebas,
59 Temple Place, Suite 330, Boston, MA 02111-1307, USA

  Eric Raymond
  esr@thyrsus.com
  6 Karen Drive
  Malvern, PA 19355

"Piranti-Lunak Kode-Sumber Terbuka" adalah bebas;
anda dapat mendistribusikannya dan/atau mengubahnya
dibawah ketentuan GNU Lisensi Publik Umum seperti yang dipublikasikan
oleh Yayasan Piranti-Lunak Bebas; baik versi 2 dari Lisensi itu, atau
(sesuai pilihan anda) versi selanjutnya.

Tulisan ini disebarluaskan dengan harapan dapat berguna, tetapi
TANPA GARANSI; juga tanpa jaminan DAPAT DIPERJUALBELIKAN atau
SESUAI UNTUK TUJUAN TERTENTU. Lihat GNU Lisensi Publik Umum
untuk jelasnya.

Lihat Apendiks B untuk sebuah salinan dari GNU Lisensi Publik Umum,
atau kirimkan pertanyaan kepada Yayasan Piranti-Lunak Bebas,
59 Temple Place, Suite 330, Boston, MA 02111-1307, USA

  Bruce Perens
  bruce@pixar.com
  c/o Pixar Animation Studios
  1001 West Cutting #200
  Richmond, CA 94804

Semua tulisan yang tidak dicantumkan di atas, bebas disebarluaskan
TANPA MODIFIKASI selama pernyataan ini disertakan.
Seluruh materi memiliki hak cipta (c) 2000 O'Reilly & kolega.
Semua Hak dilindungi.

Apendiks A: Debat Tanenbaum-Torvalds

Apa yang dibahas apendiks ini adalah yang komunitas kenal sebagai debat Tanenbaum/Linus “Sistim Linux usang”. Andrew Tanenbaum adalah peneliti yang disegani yang hidup berkecukupan dari memikirkan sistim operasi dan desain sistim operasi. Di awal 1992, memperhatikan bagaimana diskusi Linux memenuhi seluruh diskusi dalam forum comp.os.minix, dirinya memutuskan inilah waktunya untuk berkomentar tentang Linux.

Walau Andrew Tanenbaum dikonotasikan negatif karena kerasnya dan salah persepsinya akan kernel Linux, namun reaksi terhadap Tanenbaum tidak berimbang. Ketika Linus mengetahui bahwa kami menyertakan perdebatan ini, Dia ingin meyakinkan dunia mengetahui bahwa dirinya tidak menyimpan kebencian terhadap Tanenbaum dan sebenarnya tidak akan menyetujui dimasukkannya tulisan ini jika kita tidak bisa menyakinkan dia bahwa hal itu akan menunjukkan bagaimana dunia berpikir tentang desain OS pada saat itu.

Kami merasa dengan memasukkan apendiks ini akan memberikan perspektif yang baik bagaimana hal itu ketika Linus berada di bawah tekanan karena ia mengabaikan ide mikrokernel dalam dunia akademis. Ketiga tulisan pertama dari Linus membahas ini lebih lanjut.

Salinan elektronis dari debat ini tersedia di Jaringan dan dengan mudah ditemukan melalui mesin pencari apapun. Menyenangkan membaca dan mencatat siapa yang bergabung dalam diskusi ini. Anda dapat melihat peretas seperti Ken Thompson (salah satu pembuat Unix) dan David Miller (yang merupakan peretas Linux kernel utama saat ini), dan juga lainnya.

Untuk menempatkan diskusi ini ke dalam perspektif, saat hal ini terjadi pada tahun 1992, 386 adalah chip yang mendominasi dan 486 belum keluar di pasar. Microsoft masih merupakan perusahaan kecil yang menjual DOS dan Word untuk DOS. Lotus 123 menguasai pasar lembar lajur (spreadsheet) dan WordPerfect dalam pasar pengolah kata. DBASE adalah supplier basis data yang dominan dan banyak perusahaan yang banyak dikenal hari ini – Netscape, Yahoo, Excite – sama sekali tidak ada.


Sistem Linux usang

Tanenbaum

Wajah Andy Tanenbaum (diambil dari Wikipedia. Hak Cipta dilindungi.)

Dari: ast@cs.vu.nl (Andy Tanenbaum)
kelompokberita (newsgroup): comp.os.minix
Bahasan: Sistim LINUX usang
Tanggal: 29 Jan 92 12:12:50 GMT
Organisasi: Fac. Wiskunde &h; Informatica, Vrije Universiteit, Amsterdam

Saya sebelumnya berada di U.S selama beberapa minggu, jadi saya belum sempat berkomentar banyak tentang LINUX (walau saya tidak akan berkomentar banyak seandainya ada), tetapi demi kebaikan, saya ada beberapa komentar sekarang. Seperti banyak kalian ketahui, untuk saya MINIX adalah sebuah hobi, sesuatu yang saya lakukan ketika bosan menulis buku, atau tidak ada berita perang, revolusi, atau dengar-pendapat senat yang ada di televisi. Pekerjaan saya sesungguhnya adalah profesor dan peneliti di bidang sistim operasi. Sebagai bagian pekerjaan saya, saya pikir saya tahu sedikit tentang akan ke arah mana sistim operasi akan menuju dalam sepuluh tahun ke depan. Dua aspek muncul:

1. Sistim Mikrokernel dan Monolitik

Kebanyakan sistim operasi tua adalah monolitik, yang artinya, seluruh sistim operasi adalah satu berkas a.out yang berjalan dalam ‘moda kernel’. Binari ini berisi manajemen proses, manajemen memori, sistim berkas dan lainnya. Contoh sistim seperti ini adalah UNIX, MS-DOS, VMS, MVS, OS/360, Multics, dan banyak lagi.

Alternatif lainnya adalah sistim berbasis mikrokernel, dimana sebagian besar OS berjalan dalam proses terpisah, kebanyakan diluar kernel. Mereka berkomunikasi melalui kirim pesan. Tugas kernel adalah mengatur proses kirim pesan ini, proses menyela (interupsi), manajemen proses tingkat-rendah, dan kemungkinan contoh I/O dari desain ini adalah RC4000, Amoeba, Chorus, Mach, dan Window/NT yang belum dirilis.

Sementara saya dapat bercerita panjang lebar tentang manfaat relatif dari dua desain tersebut, cukuplah mengatakan bahwa di antara mereka yang sesungguhnya mendesain sistim operasi, perdebatan ini pada intinya sudah berakhir. Mikrokernel menang. Bantahan yang nyata untuk sistim Mikrokernel hanyalah kinerja, dan cukup bukti yang memperlihatkan bahwa sistim mikrokernel dapat melaju kencang seperti sistim monolitik (contohnya Rick Rashid telah mempublikasikan tulisan yang membandingkan Mach 3.0 dengan sistim monolitik) dimana artinya seluruhnya sudah berakhir kecuali teriakan kesal.

Minix adalah sistim berbasis mikrokernel. sistim berkas dan manajemen memori adalah proses terpisah, berjalan di luar kernel. Pengendali I/O (I/O drivers) juga proses terpisah (di dalam kernel, tetapi hanya karena sifat alami CPU Intel yang sudah tetap yang membuat sulit jika sebaliknya). LINUX adalah sistim bergaya monolitik. Ini merupakan langkah mundur besar ke tahun 1970-an. Itu seperti mengambil yang sudah ada, program C yang berjalan baik, dan menulisnya kembali dalam BASIC. Buat saya, menulis sebuah sistim monolitik di tahun 1991, benar-benar ide yang buruk.

2. Portabilitas (Kemampuan dipindah ke sistim lain)

Pada awalnya, hanya ada CPU 4004. Ketika tumbuh, menjadi 8008. Kemudian menjalani operasi plastik, dan jadi 8080. Dia melahirkan 8086, yang melahirkan 8088, yang melahirkan 80286, yang melahirkan 80386, yang melahirkan 80486, dan selanjutnya sampai generasi ke-N. Sementara itu chip RISC dibuat, dan beberapa dari mereka berjalan di atas 100 MIPS (jutaan instruksi per detik). Kecepatan 200 MIPS dan lebih akan lebih banyak di tahun mendatang. Hal ini tidak akan tiba-tiba lenyap. Yang akan terjadi adalah mereka secara bertahap akan mengambil alih dari garis 80×86. Mereka akan jalankan program lama MS-DOS dengan menginterpretasikan 80386 di dalam piranti-lunak. (Saya bahkan menulis sendiri simulator IBM PC dalam C, dimana anda dapat mendapatkannya dengan FTP dari ftp.cs.vu.nl = 192.31.231.42 dalam direktori minix/simulator) Saya pikir adalah kesalahan berat untuk mendesain sebuah OS untuk arsitektur spesifik, karena itu tidak akan bertahan lama.

Minix dirancang untuk mudah berpindah, dan telah berhasil dipindahkan dari sistim Intel ke sistem 680×0 (Atari, Amiga, Macintosh), SPARC, dan NS32016. Linux cukup terikat kuat dengan 80×86. Tidak dapat kemana-mana.

Jangan salah, saya tidak senang dengan LINUX. Dia akan membuat semua orang yang ingin beralih dari MINIX ke BSD UNIX di belakang saya. Tetapi, sejujurnya, saya akan menyarankan mereka yang ingin sebuah OS “bebas” yang **CANGGIH** mencoba yang berbasis mikrokernel, OS portabel, mungkin seperti GNU atau sejenis seperti itu. Andy Tanenbaum (ast@cs.vu.nl) P.S. Hanya sebagai sisi acak, Amoba memiliki emulator UNIX (berjalan dalam sisi pengguna), tetapi jauh dari lengkap. Jika ada yang tertarik untuk mengusahakan hal itu, silahkan beritahu saya. Untuk jalankan Amoeba, anda memerlukan beberapa buah 386, satu perlu 16M memori dan semuanya memerlukan kartu eternet WD.


Torvalds

Wajah Linus Torvalds (diambil dari Wikipedia. Hak Cipta dilindungi.)

Dari: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Bahasan: Re: LINUX is obsolete
Tanggal: 29 Jan 92 23:14:26 GMT
Organisasi: University of Helsinki

Nah, dengan bahasan seperti ini, saya takut saya harus membalasnya.
Permintaan maaf untuk pengguna-minix yang telah mendengar tentang Linux ya.
Ingin rasanya untuk dapat “mengabaikan pancingan itu”, tapi … saatnya untuk luapan-ramai-ramai (flamefesting) serius!

Dalam tulisan ast@cs.vu.nl (Andy Tanenbaum) mengatakan:

>
>Saya sebelumnya berada di U.S selama beberapa minggu, jadi saya belum
>sempat berkomentar banyak tentang LINUX (walau saya tidak akan berkomentar
>banyak seandainya ada), tetapi demi kebaikan, saya ada beberapa komentar
>sekarang.
>
>Seperti banyak kalian ketahui, untuk saya MINIX adalah sebuah hobi,
>sesuatu yang saya lakukan ketika bosan menulis buku, atau tidak ada berita
>perang, revolusi, atau dengar-pendapat senat yang ada di televisi.
>Pekerjaan saya sesungguhnya adalah profesor dan peneliti di bidang sistim
>operasi.

Anda menggunakan ini sebagai alasan untuk keterbatasan minix? Maaf, tetapi anda kedodoran: Saya punya banyak alasan dari yang anda miliki, dan linux tetap mengalahkan ‘celananya’ minix hampir di semua area. Belum lagi kenyataan bahwa sebagian besar kode PC minix yang bagus, tampaknya ditulis oleh Bruce Evans.

Jwb 1: anda buat minix sebagai hobi – lihat siapa yang mencari uang dari minix, dan siapa yang memberikan linux secara gratis. Lalu bicara tentang hobi. Buat minix tersedia bebas, dan satu dari keluhan terbesar saya akan hilang. Linux memang sangat jelas sebagai hobi (tapi yang serius, jenis terbaik) buat saya: Saya tidak mendapatkan uang darinya, dan itu bahkan juga bukan bagian dari studi saya di universitas. Saya selesaikan semua itu dalam waktu saya sendiri, dan dengan mesin saya sendiri.

Jwb 2: pekerjaan anda menjadi profesor dan peneliti: Itu satu dari alasan baik terburuk dari beberapa cacat-otak dari minix. Saya hanya dapat berharap (dan berasumsi) bahwa Amoeba tidak payah seperti minix.

>1. Sistim Mikrokernel dan Monolitik

Benar, linux monolitik, dan saya setuju mikrokernel lebih baik. Dengan bahasan yang kurang argumentatif, saya mungkin setuju dengan sebagian besar yang anda katakan. Dari titik pandang teoritis (dan estetik) linux kedodoran. Jika GNU kernel sudah siap musim semi lalu, saya tidak perlu repot-repot untuk memulai proyek saya bahkan: nyatanya tidak, dan sampai sekarang tidak. Linux menang telak dari titik karena tersedia sekarang juga.

> Minix adalah sistim berbasis mikrokernel. [dihapus, karena tidak seperti
> anda melewatkan poinnya] LINUX adalah sistim bergaya monolitik.

Jika ini hanya satu-satunya kriteria untuk “kebaikan” sebuah kernel, anda bisa jadi benar. Yang anda tidak sebutkan adalah minix tidak menjalankan pekerjaan micro-kernel dengan sangat baik, dan punya masalah-masalah dengan banyak-tugas (multitasking) yang sebenarnya (di dalam kernel). Jika saya membuat sebuah OS yang punya masalah-masalah dengan banyak-jalinan (multithreading) sistim berkas, saya tidak akan begitu cepat mencela yang lain: Yang pasti, saya lakukan yang terbaik untuk membuat yang lain melupakan kegagalan saya.

[ ya, saya tahu bahwa ada terobosan-singkat (hacks) untuk banyak-jalinan minix, tetapi mereka semua cuma terobosan-singkat, dan bruce evans mengatakan pada saya banyak terjadi kondisi-balapan ]

>2. PORTABILITAS

“Portabilitas adalah untuk orang yang tidak bisa menulis program baru”

-saya, sekarang ini (dengan bercanda)

Faktanya adalah bahwa linux lebih portabel daripada minix. Apa? saya dengar kata anda. Itu benar – tapi bukan seperti yang ast (Andrew S Tanenbaum) artikan: saya membuat linux menurut standar yang saya tahu caranya (tanpa memiliki standar POSIX apapun di depan saya). Memindahkan hal ke linux umumnya /lebih/ mudah daripada memindahkannya ke minix.

Saya setuju bahwa portabilitas adalah hal baik: tapi hanya apabila benar-benar memiliki arti. Tidak ada ide yang mencoba untuk membuat sebuah sistem operasi terlalu portabel: mengikuti API portabel sudah cukup baik. Yang paling /ide/ dari sistem operasi adalah menggunakan fitur perangkat keras, dan sembunyikan mereka dibalik lapisan dari panggilan kelas diatasnya. Itu adalah apa yang sebenarnya linux kerjakan: dia hanya menggunakan subset lebih besar dari fitur 386 daripada kernel lain yang biasanya lakukan. Tentu saja ini membuat kernel itu jelas tidak dapat dipindahkan (unportable), tapi itu juga membuat untuk sebuah desain /jauh/ lebih sederhana. Harga-pertukaran (trade-off) yang bisa diterima, dan satu yang membuat linux mungkin di tempat pertama.

Saya juga setuju bahwa linux membawa tidak-dapat-dipindahkan ke sebuah ektrim: Saya mendapat 386 saya Januari lalu, dan linux merupakan bagian dari proyek untuk mengajarkan saya tentangnya. Banyak hal yang seharusnya selesai lebih portabel jika itu adalah proyek sesungguhnya. Saya tidak akan membuat terlalu banyak alasan tentang itu meski: itu adalah sebuah keputusan desain, dan april lalu ketika saya mulai hal ini, saya tidak berpikir bahwa orang-orang akan benar-benar menggunakannya. Saya senang mengabarkan saya salah, dan selama sumber saya tersedia bebas, setiap orang bebas untuk mencoba memindahkannya, walaupun itu tidak akan mudah.

Linus

PS. Saya meminta maaf dimana saya kadang terdengar terlalu keras: minix cukup bagus jika anda tidak punya pilihan. Amoeba mungkin bagus jika anda punya 5-10 mesin 386 tergeletak tidak digunakan, tetapi sudah pasti bukan saya. Saya tidak biasanya begitu meluap, tapi saya sensitif begitu menyangkut linux :)


Dari: ast@cs.vu.nl (Andy Tanenbaum)
Bahasan: Re: Sistim LINUX usang
Tanggal: 30 Jan 92 13:44:34 GMT

Dalam tulisan torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) menulis:

>Anda menggunakan ini [sebagai seorang profesor] sebagai alasan untuk keterbatasan minix?

Keterbatasan dari MINIX berhubungan sedikitnya sebagai bagian menjadi seorang profesor: Sebuah design yang terang-terangan untuk membuatnya berjalan di perangkat keras murah sehingga para mahasiswa dapat membelinya. Secara khusus, selama bertahun-tahun berjalan pada PC biasa 4.77 MHz tanpa piringan keras (harddisk). Anda bisa lakukan apapun di sini, termasuk mengubah dan mengkompilasi ulang sistimnya. Hanya sebagai catatan, sejak 1 tahun lalu, ada dua versi, satu untuk PC (360K disket) dan satu lagi untuk 286/386 (1.2M). Versi PC mengalahkan penjualan versi 286/386 dengan 2 banding 1. Saya tidak punya gambaran tapi dugaan saya adalah pecahan dari 60 juta PC yang ada yaitu mesin 386/486 dibandingkan 8088/286/680×0 dan lain lain, adalah kecil.
Di antara mahasiswa hal itu bahkan lebih kecil. Membuat piranti-lunak gratis, tetapi hanya untuk mereka dengan cukup uang untuk membeli perangkat keras kelas satu adalah konsep manarik. Tentu saja 5 tahun dari sekarang akan berbeda, tetapi 5 tahun dari sekarang setiap orang akan jalankan GNU bebas pada 200 MIPS, 64M komputer Sparc-5 mereka.

>Jwb 2: pekerjaan anda menjadi profesor dan peneliti: Itu satu dari alasan
>baik terburuk dari beberapa cacat-otak dari minix. Saya hanya dapat berharap
>(dan berasumsi) bahwa Amoeba tidak payah seperti minix.

Amoeba tidak dirancang untuk jalan pada sebuah mesin 8088 tanpa piringan keras.

>Jika ini hanya satu-satunya kriteria untuk “kebaikan” sebuah kernel, anda
>bisa jadi benar. Yang anda tidak sebutkan adalah minix tidak menjalankan
>pekerjaan micro-kernel dengan sangat baik, dan punya masalah-masalah dengan
>banyak-tugas (multitasking) yang sebenarnya (di dalam kernel). Jika saya
>membuat sebuah OS yang punya masalah-masalah dengan banyak-jalinan
>(multithreading) sistim berkas, saya tidak akan begitu cepat mencela yang
>lain: Yang pasti, saya lakukan yang terbaik untuk membuat yang lain
>melupakan kegagalan saya.

Sebuah sistim berkas banyak-jalinan (multithreaded file system) adalah terobosan-singkat kinerja. Ketika hanya ada satu pekerjaan aktif, kasus biasa pada PC kecil, tidak menguntungkan apapun dan hanya menambah kompleksitas pada kodenya. Pada mesin yang cukup cepat untuk mendukung banyak pengguna, anda mungkin punya cukup tembolok penyangga (buffer cache) untuk memastikan tingkat penggunaan tembolok, dimana dalam hal ini banyak-jalinan tidak menguntungkan apa-apa. Ini hanya menguntungkan ketika ada beberapa proses melakukan proses nyata piringan I/O. Pertanyaan apakah perlu membuat sistem itu menjadi lebih rumit untuk kasus ini, setidaknya dapat diperdebatkan.

Saya tetap berpandangan bahwa merancang sebuah kernel monolitik di tahun 1991 adalah kesalahan mendasar. Bersyukurlah anda bukan mahasiswa saya. Anda tidak akan pernah dapat nilai tinggi untuk desain semacam itu :-)

>Faktanya adalah bahwa linux lebih portabel daripada minix. Apa? saya dengar
>kata anda. Itu benar – tapi bukan seperti yang ast (Andrew S Tanenbaum)
>artikan: saya membuat linux menurut standar yang saya tahu caranya (tanpa
>memiliki standar POSIX apapun di depan saya). Memindahkan hal ke linux
>umumnya /lebih/ mudah daripada memindahkannya ke minix

MINIX dirancang sebelum POSIX, dan sekarang menjadi (secara perlahan) di-POSIX-kan seperti tiap orang yang mengikuti kelompok-berita ini tahu. Setiap orang setuju bahwa standar tingkat pengguna adalah ide bagus. Sebagai selingan, saya ucapkan selamat kepada anda karena bisa menulis sebuah sistem mengikuti POSIX tanpa punya standar POSIX di hadapan anda. Saya saja masih merasa cukup sulit setelah mempelajari standar-nya sejauh ini.

Maksud saya adalah menulis sebuah sistim operasi baru dimana terikat erat dengan bagian perangkat-keras tertentu, terutama yang aneh seperti jalur Intel, pada dasarnya salah. Sebuah OS sendiri harus mudah dipindahkan ke landasan perangkat-keras baru. Saat OS/360 ditulis dalam bahasa assembly untuk PC 360 IBM 25 tahun yang lalu, mungkin masih bisa dimaafkan. Saat MS-DOS ditulis khusus untuk 8088 10 tahun lalu, ini kurang dari kata cerdas, seperti IBM dan Microsof sekarang, hanya terlalu menyakitkan untuk menyadarinya. Menulis sebuah OS baru hanya untuk 386 di tahun 1991 membuat anda mendapat nilai ‘F’ kedua untuk semester ini. Tapi jika anda benar mengerjakan ujian akhir, anda tetap dapat lulus mata kuliah ini.

Prof. Andrew S. Tanenbaum (ast@cs.vu.nl)


Dari: feustel@netcom.COM (David Feustel)
Bahasan: Re: Sistim LINUX usang
Tanggal: 30 Jan 92 18:57:28 GMT
Organisasi: DAFCO – An OS/2 Oasis

ast@cs.vu.nl (Andy Tanenbaum) menulis:

>Saya tetap berpandangan bahwa merancang sebuah kernel monolitik di
>tahun 1991 adalah kesalahan mendasar. Bersyukurlah anda bukan mahasiswa
>saya. Anda tidak akan pernah dapat nilai tinggi untuk desain semacam itu :-)

Itu oke. Einstein dapat nilai buruk dalam matematika dan fisika.


Dari: pete@ohm.york.ac.uk (-Pete French.)
Bahasan: Re: Sistim LINUX usang
Tanggal: 31 Jan 92 09:49:37 GMT
Organisasi: Electronics Department, University of York, UK

Dalam tulisan , meggin@epas.utoronto.ca (David Megginson) mengatakan:

>
> Dalam tulisan feustel@netcom.COM (David > Feustel) menulis:
>
>Itu oke. Einstein dapat nilai buruk dalam matematika dan fisika.
>
> dan Dan Quayle dapat nilai rendah dalam ilmu politik. saya pikir banyak
> orang-orang seperti Dan Quayles daripada Einstein di luar sana… ;-)

Suatu pikiran yang mengerikan !

Tapi pada poin tentang mikrokernel vs monolitik, bukankah ini bagian dari peninggalan dari bahasa yang digunakan ? MINIX mungkin bagus bisa dirancang sebagai sebuah sistim mikrokernel, tapi pada akhirnya juga tetap berurusan dengan potongan besar data binari monolitik yang dimuat dalam “OS itu”. Bukankah itu ditulis sebagai program terpisah, mudah karena C tidak mendukung ide dari banyak proses dalam satu potongan kode monolitik. Adakah perbedaan nyata antara sebuah mikrokernel yang ditulis dalam beberapa potongan C dengan sebuah monolitik yang ditulis dalam sesuatu seperti OCCAM ? Saya akan berpikir bahwa dalam kasus ini, monolitik desain akan lebih baik daripada gaya mikrokernel, mengingat dari keuntungan bahasa konkuren (dijalankan-bersamaan) yang sudah-terpasang (built-in) dimana kernel tersebut bahkan dibuat modular daripada MINIX sendiri.

Siapapun untuk MINIX :-)

-bat.


Dari: kt4@prism.gatech.EDU (Ken Thompson)
Bahasan: Re: Sistim LINUX usang
Tanggal: 3 Feb 92 23:07:54 GMT
Organisasi: Georgia Institute of Technology

sudutpandang boleh jauh dalam hal ketidakterkaitannya dari kegunaannya. Banyak, jika bukan sebagian besar, dari piranti-lunak yang kita gunakan mungkin usang menurut kriteria desain terbaru. Kebanyakan pengguna mungkin tidak peduli jika internal dari sistim operasi yang mereka gunakan, sudah usang. Mereka berhak lebih tertarik dalam kinerjanya dan kemampuannya di tingkat pengguna.

Saya biasanya setuju bahwa mikrokernel adalah gelombang masa depan. Bagaimanapun, menurut hemat saya, lebih mudah mengimplementasikan kernel monolitik. Hal ini lebih mudah juga membuatnya menjadi kekacauan ketika terburu-buru saat memodifikasinya.

Salam,
Ken

13 November 2011

GNU FDL

sepertinya saya akan memulai babak baru dengan menulis atau menterjemahkan 
semua buku berlisensi GNU FDL untuk kemajuan IT di sini :) 
dimulai dari menterjemahkan lisensi-nya dulu yah ha ha ha

Saya menambahkan disclaimer bahwa terjemahan ini tidak resmi dan sementara 
saya memperbarui tulisan ini, proses mengajukannya sebagai terjemahan resmi 
sedang dilakukan.
 
Ini adalah terjemahan tidak resmi dari GNU Lisensi Dokumentasi Bebas ke dalam 
bahasa Indonesia. Terjemahan ini tidak dipublikasikan oleh Yayasan 
Piranti-Lunak Bebas dan tidak sah secara hukum menyatakan ketentuan 
pendistribusian untuk piranti-lunak/dokumentasi yang menggunakan GNU FDL-
hanya teks asli berbahasa Inggris dari GNU FDL yang sah. Namun, kami berharap 
bahwa terjemahan ini akan membantu pengguna bahasa lain mengerti GNU FDL lebih baik.
 
GNU Lisensi Dokumentasi Bebas (GNU Free Documentation License)
versi 1.3, 3 Nov 2008 

Hak Salin (C) 2000, 2001, 2002, 2007, 2008
Yayasan Piranti-Lunak Bebas (Free Software Foundation, Inc)
<http://fsf.org/>

Setiap orang diijinkan untuk menyalin dan mendistribusikan
salinan utuh dari lisensi dokumen ini, tetapi mengubah isi tidak diperbolehkan.

0. PEMBUKAAN

Tujuan dari lisensi ini, adalah membuat manual (cara pakai), buku text (textbook),
dan dokumen yang penting dan berguna menjadi "bebas" (free), dalam
artian merdeka (freedom): Untuk memastikan setiap orang mendapatkan kebebasan
untuk menyalin dan menyebarluaskan, dengan atau tanpa mengubah dokumen,
secara komersial atau tidak-komersial. Kedua, Lisensi ini melindungi pengarang
dan penerbit cara untuk mendapatkan penghargaan (credit) untuk hasil karyanya,
tanpa dituding bertanggungjawab atas setiap perubahan yang dilakukan oleh pihak lain. 

Lisensi ini adalah salah satu jenis "Hak Bebas Salin" (copyleft), yang artinya
setiap karya turunan (derivative) dari dokumen harus juga bebas dalam pengertian
serupa. Lisensi ini melengkapi GNU Lisensi Publik Umum (the GNU General Public License),
dimana ini adalah lisensi bebas salin (copyleft) yang dirancang untuk
piranti-lunak bebas.

Kami telah merancang Lisensi ini untuk dapat menggunakannya
dalam manual (cara pakai) piranti-lunak bebas, karena piranti-lunak bebas
memerlukan dokumentasi bebas: sebuah piranti-lunak bebas seharusnya
ada manual yang menyediakan kebebasan yang sama seperti
piranti-lunak bebasnya. Tetapi Lisensi ini tidak membatasi untuk manual
(cara pakai) piranti-lunak bebas; Dia dapat juga digunakan untuk karya tekstual,
terlepas dari topiknya (subject) atau apakah akan diterbitkan sebagai
hasil cetakan (printed book). Kami merekomendasikan Lisensi ini
pada prinsipnya untuk karya yang bersifat petunjuk ataupun referensi.

1. PENERAPAN DAN DEFINISI

Lisensi ini berlaku bagi setiap manual atau karya lain, dalam media apapun,
yang memuat pemberitahuan (notice) dari pemegang hak salin (copyright)
bahwa karya ini dapat didistribusikan dibawah ketentuan lisensi ini.
Pemberitahuan (notice) seperti ini, berlaku dalam skala-luas (world-wide),
lisensi bebas-royalti, tanpa batasan dalam durasi, untuk menggunakan
karya ini dibawah ketentuan yang dijelaskan di sini.
"Hasil Karya" (the "Document"), dijelaskan dibawah, berarti setiap karya
ataupun manual. Setiap anggota dari khalayak umum adalah pengguna lisensi (licensee),
dan itu ditujukan sebagai "anda". Anda menerima lisensi ini
jika anda menyalin, mengubah, atau membagikan karya tersebut
yang selazimnya membutuhkan ijin dibawah ketentuan hukum yang berlaku.

Sebuah "Versi Modifikasi" (Modified Version) dari Hasil Karya (Document)
berarti setiap karya yang mengandung Hasil Karya atau porsi tertentu darinya,
baik disalin utuh, atau dengan modifikasi dan/atau diterjemahkan dalam bahasa lain.

Sebuah "Bagian Sekunder" (Secondary Section) adalah pemberian apendiks atau
bagian awalmuka dari Hasil Karya (Document) yang mengatur secara ekslusif
hubungan antara penerbit dan pengarang Hasil Karya terhadap keseluruhan
topik Hasil Karya (ataupun topik yang berhubungan) yang tidak melenceng
dari keseluruhan topik (subject) yang dibahas. (Jadi, jika Hasil Karya
adalah bagian dari buku-teks Matematika, sebuah Bagian Sekunder tidak boleh
membahas Matematika). Hubungan bisa jadi koneksi historis yang berhubungan
dengan topik yang dibahas, atau sisi legal, komersial, filosofis, etis,
atau politis tentangnya.

Sebuah "Bagian Invarian" (Invariant Section) adalah sejenis Bagian Sekunder
dimana pemberian judul didesain, sebagai Bagian Invarian (tidak berubah),
dalam pemberitahuan yang mengatakan Hasil Karya ini dirilis dibawah Lisensi ini.
Jika sebuah bagian tidak sesuai dengan definisi Bagian Sekunder di atas,
maka tidak boleh disebut sebagai Bagian Invarian. Hasil Karya tidak boleh ada
Bagian Invarian. Jika Hasil Karya tidak mengidentifikasikan
Bagian Invarian apapun maka Hasil Karya tersebut tidak ada Bagian Invarian.

Sebuah "Teks Sampul" (Cover Texts) adalah sebaris kalimat pendek yang dicantumkan,
sebagai Teks Sampul Depan (Front-Cover Texts) atau Teks Sampul Belakang
(Back-Cover Texts), dalam pemberitahuan yang mengatakan Hasil Karya dirilis
dibawah Lisensi ini. Teks Sampul Depan dapat memuat paling banyak 5 kata,
dan Teks Sampul Belakang paling banyak 25 kata.

Sebuah salinan "Transparan" (Transparent) dari Hasil Karya berarti
salinan yang-dapat-dibaca-mesin (machine-readable), dihadirkan dalam suatu
format yang spesifikasinya tersedia buat publik umum, dimana cocok
untuk penyuntingan karya secara langsung dengan piranti-lunak
penyunting tulisan biasa atau (untuk citra-gambar tersusun dari piksel)
piranti lunak pengolah citra-gambar biasa atau (untuk gambar)
piranti-lunak pengolah gambar, dan dimana sesuai untuk masukan menjadi
format teks atau untuk otomatis penterjemahan dalam berbagai format
yang cocok buat masukan menjadi format teks. Sebuah salinan yang dibuat
dalam format lembar Transparansi lainnya dimana sintaks-yang-ditandai (markup)
atau tidak menggunakan sintaks-yang-ditandai (absence of markup),
yang sengaja diatur untuk mencegah atau menyulitkan perubahan berikutnya
oleh para pembaca, adalah tidak Transparan. Sebuah format citra-gambar
dikatakan tidak Transparan jika digunakan buat menggantikan sejumlah teks.
Sebuah salinan yang tidak "Transparan" disebut "Buram" (Opaque).

Contoh dari format yang sesuai untuk salinan Transparan termasuk ASCII-sederhana
tanpa sintaks-yang-ditandai (markup), format masukan Texinfo, format masukan LaTex,
SGML atau XML menggunakan DTD yang tersedia untuk umum, dan standar HTML sederhana,
PostScript atau PDF yang didesain untuk penyuntingan oleh manusia. Contoh dari
format citra yang Transparan adalah PNG, XCF dan JPG. Format Buram (opaque)
termasuk format tertutup (proprietary) yang hanya bisa dibaca dan disunting
oleh pengolah kata tertutup (proprietary), SGML atau XML dimana DTD dan/atau
utiliti pengolah lainnya tidak tersedia secara umum, dan HTML-yang-dihasilkan-mesin,
PostScript atau PDF yang dibuat dari pengolah kata hanya untuk hasil pemrosesan.

"Judul Halaman" berarti, untuk buku cetakan, adalah judul halaman itu sendiri,
ditambah seperti halaman berikutnya yang diperlukan untuk menampilkan materi
Lisensi ini yang muncul dalam judul halaman. Untuk karya dalam format dimana
tidak ada judul halaman, "Judul Halaman" berarti semua teks terdekat sebagai
juduk sebuah karya, mendahului awal isi teks.

"Penerbit" berarti setiap entitas atau orang yang menyebarluaskan salinan
dari Hasil Karya kepada umum.

Sebuah bagian "Diberi Judul XYZ" berarti pemberian subunit dari Hasil Karya
dimana judul bisa mengandung tepat XYZ atau mengandung XYZ dalam tanda kurung
yang menterjemahkan XYZ dalam bahasa lain (Disini XYZ sebagai sebuah bagian
spesifik nama yang dicantumkan seperti dibawah, seperti "Ucapan Terima Kasih",
"Persembahan Untuk", "Pengesahan", atau "Riwayat"). Untuk "Melindungi Judul"
seperti bagian dimana anda mengubah Hasil Karya berarti judul ini harus
ditaruh dalam bagian "Diberi Judul XYZ" menurut definisi bagian ini.

Hasil Karya boleh jadi mencantumkan Tanpa Garansi didekat pernyataan
yang menyatakan Lisensi ini berlaku pada Hasil Karya ini. Tanpa Garansi
ini dimaksudkan untuk disertakan sebagai referensi dalam Lisensi ini,
tetapi hanya sebagai penolakan untuk memberikan garansi: setiap implikasi lain
dari Tanpa Garansi bisa jadi tidak berlaku dan tidak memiliki efek
dalam arti terhadap Lisensi ini.

2. SALINAN UTUH

Anda boleh menyalin dan membagikan Hasil Karya dalam media apapun,
baik untuk kepentingan komersial atau tidak komersial, yang disediakan
Lisensi ini, pernyataan Hak Salin dan pernyataan lisensi ini yang mengatakan
Lisensi berlaku pada Hasil Karya yang dihasilkan dalam semua bentuk salinan,
dan menyatakan bahwa anda tidak menambahkan syarat, apapun bentuknya,
pada karya yang menggunakan Lisensi ini. Anda tidak diperbolehkan
menggunakan cara teknikal tertentu untuk menutup atau mengendalikan bacaan
atau penyalinan lebih lanjut dari salinan yang anda buat atau bagikan.
Bagaimanapun, anda boleh menerima kompensasi sebagai ganti dari salinan.
Jika anda membagikan dalam jumlah besar salinan anda wajib mengikuti syarat
dalam bagian 3.

Anda boleh meminjamkan salinan, dibawah kondisi yang dinyatakan di atas,
dan anda boleh menampilkan salinan kepada umum.

3. PENYALINAN DALAM JUMLAH TERTENTU

Jika anda mempublikasikan salinan (atau salinan dalam media yang biasanya
terdapat sampul cetak) dari Hasil Karya, dalam jumlah lebih dari 100,
dan lisensi Hasil Karya tersebut mengatakan membutuhkan Teks Sampul,
maka anda harus menyertakan salinan dalam sampul-sampul yang membawa,
secara jelas dan dapat dibaca, semua Teks Sampul: Teks Sampul Depan
pada sampul depan dan Teks Sampul Belakang dalam sampul belakang.
Kedua sampul wajib secara jelas dan dapat dibaca, mengidentifikasi anda
sebagai penerbit dari salinan ini. Sampul depan wajib menampilkan judul penuh
dengan semua kata-kata dari judul yang setara khalayak mengerti dan terlihat jelas.
Anda boleh menambah materi lain dalam sampul sebagai tambahan.
Penyalinan dengan perubahan terbatas pada sampul, selama hal itu
melindungi judul dari Hasil Karya dan memenuhi syarat, dan dapat dianggap
sebagai salinan utuh yang dapat diterima.

Jika teks yang dibutuhkan, untuk kedua sampul terlalu banyak untuk tetap terbaca,
anda wajib meletakkan yang pertama tercantum (sebanyak yang dapat dimuat)
pada sampul sebenarnya, dan melanjutkan sisanya pada halaman berikutnya.

Jika anda mempublikasikan atau membagikan salinan "Buram" (opaque)
dari Hasil Karya dalam jumlah lebih dari 100 salinan, anda wajib,
baik menyertakan salinan "Transparan" yang-dapat-dibaca-mesin bersama
setiap salinan "Buram" (opaque), atau mencantumkan dalam atau dengan
setiap salinan "Buram" sebuah jaringan komputer dimana
setiap jaringan komputer umum memiliki akses untuk mengunduh
menggunakan protokol jaringan standar umum,sebuah salinan "Transparan" lengkap,
bebas dari materi yang ditambahkan. Jika anda memilih yang terakhir,
anda harus mengambil langkah hati-hati, ketika anda mulai
pendistribusian salinan "Buram" dalam jumlah tertentu,
untuk menjamin bahwa salinan "Transparan" akan selalu ada,
dan dapat diakses pada lokasi yang ditentukan selama sedikitnya
satu tahun setelah waktu terakhir anda membagikan sebuah
salinan "Buram" (langsung atau melalui agen atau ritel)
dari edisi tersebut kepada umum.

Hal ini diminta, tetapi tidak wajib, dimana anda memberitahu pengarang
dari Hasil Karya sebelum anda membagikan salinan dalam jumlah besar,
untuk memberikan mereka kesempatan memberikan anda versi terbaru dari
Hasil Karya tersebut.

4. MODIFIKASI

Anda boleh menyalin dan membagikan sebuah "Versi Modifikasi" dari Hasil Karya
dibawah syarat dalam bagian 2 dan 3 di atas, yang mencantumkan bahwa
anda harus merilis "Versi Modifikasi" ini, TEPAT DALAM LISENSI INI,
dengan "Versi Modifikasi" memenuhi bagian dari Hasil Karya, sehingga distribusi
lisensi dan modifikasi atas "Versi Modifikasi" kepada siapapun yang memiliki
salinan. Sebagai tambahan, anda wajib melakukan tindakan berikut
dalam "Versi Modifikasi":

  A. Gunakan dalam "Judul Halaman" (dan pada sampulnya, jika ada)
sebuah judul terpisah dari Hasil Karya, dan juga untuk versi sebelumnya
(yang wajib, jika ada, dicantumkan dalam bagian sejarah dari Hasil Karya).
Anda boleh menggunakan judul yang sama seperti sebelumnya jika penerbit
asalnya memberikan ijin untuk itu.

  B. Cantumkan pada "Judul Halaman", sebagai pengarang, satu atau lebih orang
atau entitas yang bertanggungjawab untuk kepemilikan-karangan dari modifikasi
dalam "Versi Modifikasi", bersama dengan sedikitnya lima dari pengarang inti
dari Hasil Karya (semua pengarang intinya, jika kurang dari lima), atau
tidak perlu jika mereka membebaskan anda dari kewajiban ini.

  C. Cantumkan dalam "Judul Halaman", nama dari penerbit "Versi Modifikasi",
sebagai penerbit.

  D. Lindungi semua Hak Salin yang dinyatakan dalam Hasil Karya.

  E. Tambahkan sebuah pernyataan hak salin sewajarnya pada modifikasi anda
dibawah pernyataan hak salin lainnya.

  F. Masukkan, segera setelah pernyataan Hak Salin pada modifikasi anda,
sebuah pernyataan lisensi yang memberikan ijin kepada umum untuk menggunakan
"Versi Modifikasi" dibawah ketentuan Lisensi ini, dalam bentuk
seperti Addendum dibawah.

  G. Lindungi dalam lisensi itu pernyataan dari semua daftar "Bagian Invarian"
dan memerlukan "Teks Sampul" yang tercantum dalam pernyataan
lisensi Hasil Karya tersebut.

  H. Masukkan salinan yang tidak diubah dari Lisensi ini.

  I. Lindungi bagian yang bertanda "Riwayat". Lindungi Judulnya,
dan tambahkan sebaris informasi yang menyatakan sedikitnya judul, tahun,
pengarang baru, dan penerbit dari "Versi Modifikasi" seperti yang tercantum
dalam "Judul Halaman". Jika tidak ada bagian yang bertanda "Riwayat"
dalam Hasil Karya tersebut, buat satu yang menyatakan judul, tahun, pengarang,
dan penerbit dari Hasil Karya sepertu yang tertulis pada "Judul Halaman"-nya,
kemudian tambahkan bagian yang menjelaskan "Versi Modifikasi" seperti yang
dinyatakan kalimat sebelumnya.

  J. Lindungi lokasi jaringan, jika ada, yang tercantum dalam Hasil Karya
untuk akses umum kepada sebuah salinan "Transparan" dari Hasil Karya,
dan lokasi jaringan sejenis untuk versi sebelumnya dimana Hasil Karya ini berasal.
Hal ini bisa ditaruh dalam bagian "Riwayat". Anda boleh tidak mencantumkan
lokasi jaringan untuk karya yang dipublikasikan sedikitnya empat tahun
sebelum Hasil Karya tersebut, atau jika penerbit asalnya dari versi tersebut
memberikan ijin.

  K. Untuk setiap bagian yang ditandai "Ucapan Terima Kasih"
atau "Persembahan Untuk", Lindungi Judul dari bagian ini dan
lindungi dalam bagian semua substansi dan warna dari setiap
ucapan terima kasih kontributor dan/atau persembahan untuk
yang tercantum.

  L. Lindungi semua "Bagian Invarian" (Invariant Sections) dari Hasil Karya,
tidak mengubah teks dan judul dalamnya. Bagian penomoran atau yang sama,
tidak dianggap sebagai bagian dari judul.

  M. Hapus semua yang ditandai sebagai "Pengesahan" (endorsement). Bagian seperti itu
boleh tidak disertakan dalam "Versi Modifikasi"

  N. Jangan memberi ulang judul setiap bagian bertanda "Pengesahan" (Endorsements)
atau hal yang menyebabkan konflik antara judul dengan Bagian Invarian (Invariant Section)

  O. Lindungi pernyataan Tanpa Garansi

Jika "Versi Modifikasi" menyertakan bagian awalmuka baru atau appendiks
yang termasuk sebagai "Bagian Sekunder" dan tidak mengandung meteri
yang disalin dari Hasil Karya, anda boleh memilih merancang beberapa
atau semua bagian ini sebagai tetapan (invariant). Untuk melakukan ini,
tambahkan judulnya dalam daftar Bagian Invarian dalam
pernyataan lisensi "Versi Modifikasi". Judul ini harus terpisah dari
semua judul bagian lain.

Anda boleh menambahkan sebuah bagian bertanda "Pengesahan", yang menyatakan
bahwa pengesahan dari Versi Modifikasi dilakukan oleh banyak pihak--sebagai contoh,
pernyataan dari ulasan satu pihak atau bahwa teks yang dimaksud telah
disetujui oleh sebuah organisasi sebagai definisi otoritatif dari
sebuah standar.

Anda boleh menambahkan sebuah baris sampai dengan lima kata sebagai
Teks Sampul Depan, dan sebaris sampai dengan 25 kata sebagai Teks Sampul Belakang,
sampai akhir dari daftar Teks Sampul dalam Versi Modifikasi. Hanya
satu baris dari Teks Sampul Depan dan satu dari Teks Sampul Belakang
boleh ditambahkan oleh (atau melalui perjanjian yang dibuat) lebih
dari satu entitas. Jika Hasil Karya telah menyertakan sebuah tulisan
sampul dari sampul yang sama, sebelumnya ditambahkan oleh anda atau
dengan perjanjian oleh entitas yang sama sebagai bagian dari anda,
anda tidak boleh menambahkan yang lain, tetapi anda boleh mengganti yang lama,
dengan ijin tertulis dari penerbit sebelumnya, menambahkan yang lama.

Dengan Lisensi ini, Pengarang dan penerbit dari Hasil Karya tidak berarti
memberikan ijin untuk menggunakan nama mereka untuk publisitas atau
meyakinkan, atau menyiratkan pengesahan dari Versi Modifikasi.

5. PENGGABUNGAN HASIL KARYA

Anda boleh menggabungkan Hasil Karya dengan karya lain yang dirilis
dibawah Lisensi ini, dibawah ketentuan yang sudah didefinisikan
dalam bagian 4 diatas mengenai Versi Modifikasi, tersedia dimana
anda memasukkan dalam kombinasi semua Bagian Invarian dari semua karya asli,
tidak dimodifikasi, dan mendaftarkan semuanya sebagai Bagian Invarian dari
karya gabungan anda dalam pernyataan lisensinya, dan mewajibkan anda
melindungi semua pernyataan "Tanpa Garansi"-nya.

Karya gabungan hanya memerlukan tersedia satu salinan dari Lisensi ini,
dan banyak Bagian Invarian yang identik boleh diganti menjadi satu salinan.
Jika ada banyak Bagian Invarian dengan nama sama tetapi berbeda isinya,
maka buatlah judul dari setiap bagian unik dengan menambahkan di akhirnya,
dalam kurung, nama pengarang asalnya atau penerbitnya pada bagian tersebut
jika tahu, atau berikan nomor unik. Buat penyesuaian yang sama dari bagian judul
dalam daftar Bagian Invarian dalam pernyataan lisensi dari karya gabungan.

Dalam gabungan, anda harus menggabungkan setiap bagian bertanda "Riwayat"
dalam setiap karya asalnya, membentuk satu bagian bertanda "Riwayat",
Hal yang sama juga berlaku untuk menggabungkan setiap bagian bertanda
"Ucapan Terima Kasih", atau setiap bagian bertanda "Persembahan Untuk".
Anda harus menghapus semua bagian bertanda "Pengesahan".

6. KUMPULAN HASIL KARYA

Anda boleh membuat sebuah kumpulan yang terdiri bagian Hasil Karya dan
karya lainnya yang dirilis dalam Lisensi ini, dan mengganti tiap salinan
dari Lisensi ini dalam karya yang banyak tersebut menjadi satu salinan
yang dicantumkan dalam kumpulan tersebut, memastikan bahwa anda mengikuti
aturan dari Lisensi ini untuk salinan utuh dari tiap karya tetap terjaga.

Anda boleh melepas satu karya dari kumpulan tersebut, dan membagikannya
sendiri sendiri dibawah lisensi ini, dimana anda memasukkan satu salinan
dari Lisensi ini kedalam karya yang dilepas tersebut, dan mengikuti Lisensi
ini dengan tetap menghormati sesuai dengan salinan utuh dari karya tersebut.

7. PENYATUAN DENGAN KARYA INDEPENDEN

Sebuah kompilasi dari Hasil Karya atau turunannya dengan karya atau
kreasi terpisah dan independen, dalam atau pada satu isi kumpulan atau
media distribusi, disebut "penyatuan" (aggregate) jika hak salin yang
dihasilkan dari gabungan tidak digunakan untuk membatasi hak legal dari
pengguna kompilasi dibalik apa yang diijinkan karya masing-masing.
Ketika Hasil Karya dimasukkan dalam sebuah penyatuan, Lisensi ini
berlaku dalam karya penyatuan dimana karya lain tersebut bukanlah
karya turunan dari Hasil Karya.

Jika Teks Sampul yang terdapat pada bagian 3 dapat diterapkan untuk salinan
dari Hasil Karya, maka jika Hasil Karya sedikit dari setengah dari
keseluruhan penyatuan, Teks Sampul Hasil Karya boleh diganti pada
sampul yang memuat Hasil Karya dalam penyatuan, atau setara elektronik
dari sampul jika Hasil Karya dalam bentuk elektronik. Jika tidak,
mereka harus tampil pada sampul cetak yang memuat seluruh penyatuan.

8. TERJEMAHAN

Terjemahan dianggap sebagai jenis modifikasi, jadi anda boleh membagikan
terjemahan dari Hasil Karya dibawah ketentuan bagian 4. Mengganti Bagian Invarian
dengan terjemahan membutuhkan ijin dari pemegang hak salin, tetapi anda
boleh memasukkan terjemahan sebagian atau seluruhnya dari Bagian Invarian
sebagai tambahan dari versi asli dari Bagian Invarian ini. Anda boleh memasukkan
terjemahan dari Lisensi ini, dan seluruh lisensi yang tercantum dalam Hasil Karya,
dan semua pernyataan Tanpa Garansi, dimana anda juga memasukkan versi Inggris aslinya,
dari Lisensi ini atau mencantumkan bahwa jika ada masalah terjemahan, versi aslinya
yang akan dipakai.

Jika sebuah bagian dalam Hasil Karya yang bertanda "Ucapan Terima Kasih",
"Persembahan Untuk", atau "Riwayat", kebutuhan (bagian 4) untuk melindungi
judulnya (bagian 1) biasanya memerlukan untuk merubah judul sebenarnya.

9. PENCABUTAN LISENSI

Anda tidak bolen menyalin, mengubah, melakukan sublisensi, atau
membagikan suatu Hasil Karya kecuali seperti yang tercantum dibawah Lisensi ini.
Setiap usaha selain untuk menyalin, mengubah, melakukan sublisensi, atau
mebagikannya batal, dan otomatis membatalkan hak anda dibawah lisensi ini.

Bagaimanapun, jika anda mengakhiri semua pelanggaran dari Lisensi ini,
maka lisensi anda dari pemegang hak salin tertentu dipulihkan
(a) sementara, jika tidak dan sampai pemegang hak salin secara terbuka
dan akhirnya memutuskan mengakhiri lisensi anda, dan (b) secara tetap,
jika pemegang hak salin gagal untuk mengingatkan anda tentang pelanggaran
setelah 60 hari setelah anda memperbaiki pelanggaran anda.

Lebih jauh, lisensi anda dari pemegang hak salin dipulihkan secara tetap
jika pemegang hak salin memberitahu anda tentang pelanggaran yang anda lakukan,
dan ini merupakan yang pertama kali terjadi dimana anda menerima peringatan
akan pelanggaran dari Lisensi ini (untuk setiap karya) dari pemegang hak salin,
dan anda sudah memperbaiki pelanggaran tersebut dalam waktu kurang dari 30 hari
setelah menerima teguran.

Pencabutan dari hak anda dibawah aturan ini tidak membatalkan lisensi dari
pihak-pihak yang telah menerima salinan atau hak dari anda dibawah Lisensi ini.
Jika hak anda dicabut dan selamanya tidak dipulihkan, tanda terima
dari sebuah salinan, sebagian atau keseluruhan materi, tidak memberikan
anda hak untuk menggunakannya.

10. PERBAIKAN LISENSI INI DI MASA MENDATANG

Yayasan Piranti-Lunak Bebas (Free Software Foundation) boleh menerbitkan
Lisensi baru, versi perbaikan dari GNU Lisensi Dokumentasi Bebas
(GNU Free Documentation License). Setiap lisensi baru akan sama
dalam semangatnya dengan versi saat ini, tetapi berbeda sedikit
dalam detilnya untuk memasukkan pengaturan masalah atau perhatian baru.
lihat http://www.gnu.org/copyleft/

Setiap versi Lisensi ini dibedakan dengan penomoran versi.
Jika suatu Hasil Karya mencantumkan versi tertentu dari Lisensi ini
"atau versi terakhir" yang digunakan, anda memiliki pilihan sesuai
syarat dan ketentuan, yaitu menggunakan versi saat ini, atau versi
selanjutnya yang sudah diterbitkan (bukan baru rencana pematangan)
oleh Yayasan Piranti-Lunak Bebas. Jika Hasil Karya mengemukakan
bahwa sebuah proksi dapat memutuskan Lisensi versi mendatang
mana yang akan digunakan, pernyataan proksi tersebut kepada umum
akan menetapkan secara tetap versi yang digunakan dalam Hasil Karya.

11. MELAKUKAN LISENSI ULANG (RELICENSING)

"Situs Kolaborasi Masif Banyak Pengarang" (atau "situs MMC") artinya
setiap layanan jaringan skala luas yang mempublikasikan karya yang
menggunakan hak salin dan juga menyediakan fasilitas yang dikenal luas
untuk setiap orang menyunting karya tersebut. Sebuah situs wiki umum
dimana setiap orang dapat menyunting adalah salah satu contoh dari
layanan tersebut. Sebuah "Kolaborasi Masif Banyak Pengarang" (atau "MMC")
yang terdapat dalam sebuah situs, berarti setiap kumpulan karya
yang mengandung hak salin, yang dipublikasikan pada situs MMC tersebut.

"CC-BY-SA" artinya Lisensi Milik Bersama dengan atribusi Saling Berbagi
versi 3, dipublikasikan oleh Lembaga Milik Bersama, sebuah lembaga nirlaba
dengan pusat bisnisnya berada di San Francisco, California sama seperti
lisensi versi masa mendatang-nya hak bebas salin (copyleft),
yang dipublikasikan oleh lembaga yang sama.

"Menyatukan" (Incorporate) artinya, mempublikasikan atau menerbitkan ulang
sebuah Hasil Karya, secara keseluruhan atau sebagian,
sebagai bagian dari Hasil Karya lain.

Sebuah MMC dapat "boleh untuk melakukan lisensi kembali" (relicensing)
Jika karya tersebut dibawah Lisensi ini, dan Jika semua karya yang pertama kali
diterbitkan dalam Lisensi ini di tempat lain selain dari MMC ini,
dan selanjutnya menyatukan (incorporated) dalam keseluruhan atau
sebagian kedalam MMC, (1) tidak memiliki teks sampul atau Bagian Invarian,
dan (2) jika disatukan sebelum tanggal 1 November 2008.

Operator dari situs MMC boleh menerbitkan ulang dalam situs MMC dibawah
lisensi CC-BY-SA pada situs yang sama kapan pun sebelum tanggal 1 Agustus 2001,
dimana MMC diperbolehkan melakukan lisensi ulang

ADDENDUM: Bagaimana menggunakan Lisensi ini dalam karya anda

Untuk menggunakan Lisensi ini dalam suatu karya yang anda tulis,
masukkan sebuah salinan dari lisensi ini dalam karya tersebut,
dan letakkan hak salin berikut dan pernyataan lisensinya
setelah judul halaman:

  Hak Salin (c) TAHUN NAMA ANDA
  Dengan ini, anda diijinkan untuk menyalin, membagikan dan/atau mengubah
  karya ini dibawah ketentuan dari GNU Lisensi Dokumentasi Bebas (GNU Free
  Documentation License), versi 1.3 atau versi berikutnya yang diterbitkan
  oleh Yayasan Piranti-Lunak Bebas(Free Software Foundation);
  dengan tanpa Bagian Invarian, tanpa teks Sampul Depan, dan tanpa teks
  Sampul Belakang. Sebuah salinan dari lisensi dimasukkan dalam bagian yang
  ditandai "GNU Lisensi Dokumentasi Bebas" (GNU Free Documentation License)

Jika anda memiliki Bagian Invarian, Teks Sampul Depan dan Teks Sampul Belakang,
ganti baris "dengan....Teks" dengan kalimat ini:

  dengan Bagian Invarian yang mencantumkan Judulnya, dengan Teks Sampul Depan
  dicantumkan, dan dengan Teks Sampul Belakang dicantumkan.

Jika anda memiliki Bagian Invarian tanpa Teks Sampul, atau kombinasi lain
dari ketiga hal, gabungkan dua alternatif di atas agar sesuai dengan situasinya.

Jika karya anda mengandung kode program yang bekerja penuh, maka kami menyarankan
untuk menerbitkan contoh ini secara paralel dibawah lisensi Piranti Lunak Bebas,
seperti GNU Lisensi Publik Umum, untuk memberikan ijin penggunaannya
dalam piranti lunak bebas.

---------------------------------------------------------------------------

                GNU Free Documentation License
                 Version 1.3, 3 November 2008

 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
     <http://fsf.org/>
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other
functional and useful document "free" in the sense of freedom: to
assure everyone the effective freedom to copy and redistribute it,
with or without modifying it, either commercially or noncommercially.
Secondarily, this License preserves for the author and publisher a way
to get credit for their work, while not being considered responsible
for modifications made by others.

This License is a kind of "copyleft", which means that derivative
works of the document must themselves be free in the same sense.  It
complements the GNU General Public License, which is a copyleft
license designed for free software.

We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free
program should come with manuals providing the same freedoms that the
software does.  But this License is not limited to software manuals;
it can be used for any textual work, regardless of subject matter or
whether it is published as a printed book.  We recommend this License
principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that
contains a notice placed by the copyright holder saying it can be
distributed under the terms of this License.  Such a notice grants a
world-wide, royalty-free license, unlimited in duration, to use that
work under the conditions stated herein.  The "Document", below,
refers to any such manual or work.  Any member of the public is a
licensee, and is addressed as "you".  You accept the license if you
copy, modify or distribute the work in a way requiring permission
under copyright law.

A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of
the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall
subject (or to related matters) and contains nothing that could fall
directly within that overall subject.  (Thus, if the Document is in
part a textbook of mathematics, a Secondary Section may not explain
any mathematics.)  The relationship could be a matter of historical
connection with the subject or with related matters, or of legal,
commercial, philosophical, ethical or political position regarding
them.

The "Invariant Sections" are certain Secondary Sections whose titles
are designated, as being those of Invariant Sections, in the notice
that says that the Document is released under this License.  If a
section does not fit the above definition of Secondary then it is not
allowed to be designated as Invariant.  The Document may contain zero
Invariant Sections.  If the Document does not identify any Invariant
Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed,
as Front-Cover Texts or Back-Cover Texts, in the notice that says that
the Document is released under this License.  A Front-Cover Text may
be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the
general public, that is suitable for revising the document
straightforwardly with generic text editors or (for images composed of
pixels) generic paint programs or (for drawings) some widely available
drawing editor, and that is suitable for input to text formatters or
for automatic translation to a variety of formats suitable for input
to text formatters.  A copy made in an otherwise Transparent file
format whose markup, or absence of markup, has been arranged to thwart
or discourage subsequent modification by readers is not Transparent.
An image format is not Transparent if used for any substantial amount
of text.  A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain
ASCII without markup, Texinfo input format, LaTeX input format, SGML
or XML using a publicly available DTD, and standard-conforming simple
HTML, PostScript or PDF designed for human modification.  Examples of
transparent image formats include PNG, XCF and JPG.  Opaque formats
include proprietary formats that can be read and edited only by
proprietary word processors, SGML or XML for which the DTD and/or
processing tools are not generally available, and the
machine-generated HTML, PostScript or PDF produced by some word
processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself,
plus such following pages as are needed to hold, legibly, the material
this License requires to appear in the title page.  For works in
formats which do not have any title page as such, "Title Page" means
the text near the most prominent appearance of the work's title,
preceding the beginning of the body of the text.

The "publisher" means any person or entity that distributes copies of
the Document to the public.

A section "Entitled XYZ" means a named subunit of the Document whose
title either is precisely XYZ or contains XYZ in parentheses following
text that translates XYZ in another language.  (Here XYZ stands for a
specific section name mentioned below, such as "Acknowledgements",
"Dedications", "Endorsements", or "History".)  To "Preserve the Title"
of such a section when you modify the Document means that it remains a
section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which
states that this License applies to the Document.  These Warranty
Disclaimers are considered to be included by reference in this
License, but only as regards disclaiming warranties: any other
implication that these Warranty Disclaimers may have is void and has
no effect on the meaning of this License.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License applies
to the Document are reproduced in all copies, and that you add no
other conditions whatsoever to those of this License.  You may not use
technical measures to obstruct or control the reading or further
copying of the copies you make or distribute.  However, you may accept
compensation in exchange for copies.  If you distribute a large enough
number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and
you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly have
printed covers) of the Document, numbering more than 100, and the
Document's license notice requires Cover Texts, you must enclose the
copies in covers that carry, clearly and legibly, all these Cover
Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
the back cover.  Both covers must also clearly and legibly identify
you as the publisher of these copies.  The front cover must present
the full title with all words of the title equally prominent and
visible.  You may add other material on the covers in addition.
Copying with changes limited to the covers, as long as they preserve
the title of the Document and satisfy these conditions, can be treated
as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto adjacent
pages.

If you publish or distribute Opaque copies of the Document numbering
more than 100, you must either include a machine-readable Transparent
copy along with each Opaque copy, or state in or with each Opaque copy
a computer-network location from which the general network-using
public has access to download using public-standard network protocols
a complete Transparent copy of the Document, free of added material.
If you use the latter option, you must take reasonably prudent steps,
when you begin distribution of Opaque copies in quantity, to ensure
that this Transparent copy will remain thus accessible at the stated
location until at least one year after the last time you distribute an
Opaque copy (directly or through your agents or retailers) of that
edition to the public.

It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to
give them a chance to provide you with an updated version of the
Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under
the conditions of sections 2 and 3 above, provided that you release
the Modified Version under precisely this License, with the Modified
Version filling the role of the Document, thus licensing distribution
and modification of the Modified Version to whoever possesses a copy
of it.  In addition, you must do these things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct
   from that of the Document, and from those of previous versions
   (which should, if there were any, be listed in the History section
   of the Document).  You may use the same title as a previous version
   if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities
   responsible for authorship of the modifications in the Modified
   Version, together with at least five of the principal authors of the
   Document (all of its principal authors, if it has fewer than five),
   unless they release you from this requirement.
C. State on the Title page the name of the publisher of the
   Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications
   adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice
   giving the public permission to use the Modified Version under the
   terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections
   and required Cover Texts given in the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled "History", Preserve its Title, and add
   to it an item stating at least the title, year, new authors, and
   publisher of the Modified Version as given on the Title Page.  If
   there is no section Entitled "History" in the Document, create one
   stating the title, year, authors, and publisher of the Document as
   given on its Title Page, then add an item describing the Modified
   Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for
   public access to a Transparent copy of the Document, and likewise
   the network locations given in the Document for previous versions
   it was based on.  These may be placed in the "History" section.
   You may omit a network location for a work that was published at
   least four years before the Document itself, or if the original
   publisher of the version it refers to gives permission.
K. For any section Entitled "Acknowledgements" or "Dedications",
   Preserve the Title of the section, and preserve in the section all
   the substance and tone of each of the contributor acknowledgements
   and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document,
   unaltered in their text and in their titles.  Section numbers
   or the equivalent are not considered part of the section titles.
M. Delete any section Entitled "Endorsements".  Such a section
   may not be included in the Modified Version.
N. Do not retitle any existing section to be Entitled "Endorsements"
   or to conflict in title with any Invariant Section.
O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no material
copied from the Document, you may at your option designate some or all
of these sections as invariant.  To do this, add their titles to the
list of Invariant Sections in the Modified Version's license notice.
These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains
nothing but endorsements of your Modified Version by various
parties--for example, statements of peer review or that the text has
been approved by an organization as the authoritative definition of a
standard.

You may add a passage of up to five words as a Front-Cover Text, and a
passage of up to 25 words as a Back-Cover Text, to the end of the list
of Cover Texts in the Modified Version.  Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or
through arrangements made by) any one entity.  If the Document already
includes a cover text for the same cover, previously added by you or
by arrangement made by the same entity you are acting on behalf of,
you may not add another; but you may replace the old one, on explicit
permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to assert or
imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified
versions, provided that you include in the combination all of the
Invariant Sections of all of the original documents, unmodified, and
list them all as Invariant Sections of your combined work in its
license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and
multiple identical Invariant Sections may be replaced with a single
copy.  If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of the original
author or publisher of that section if known, or else a unique number.
Make the same adjustment to the section titles in the list of
Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History"
in the various original documents, forming one section Entitled
"History"; likewise combine any sections Entitled "Acknowledgements",
and any sections Entitled "Dedications".  You must delete all sections
Entitled "Endorsements".

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other
documents released under this License, and replace the individual
copies of this License in the various documents with a single copy
that is included in the collection, provided that you follow the rules
of this License for verbatim copying of each of the documents in all
other respects.

You may extract a single document from such a collection, and
distribute it individually under this License, provided you insert a
copy of this License into the extracted document, and follow this
License in all other respects regarding verbatim copying of that
document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate
and independent documents or works, in or on a volume of a storage or
distribution medium, is called an "aggregate" if the copyright
resulting from the compilation is not used to limit the legal rights
of the compilation's users beyond what the individual works permit.
When the Document is included in an aggregate, this License does not
apply to the other works in the aggregate which are not themselves
derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one half of
the entire aggregate, the Document's Cover Texts may be placed on
covers that bracket the Document within the aggregate, or the
electronic equivalent of covers if the Document is in electronic form.
Otherwise they must appear on printed covers that bracket the whole
aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of section 4.
Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include
translations of some or all Invariant Sections in addition to the
original versions of these Invariant Sections.  You may include a
translation of this License, and all the license notices in the
Document, and any Warranty Disclaimers, provided that you also include
the original English version of this License and the original versions
of those notices and disclaimers.  In case of a disagreement between
the translation and the original version of this License or a notice
or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements",
"Dedications", or "History", the requirement (section 4) to Preserve
its Title (section 1) will typically require changing the actual
title.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document
except as expressly provided under this License.  Any attempt
otherwise to copy, modify, sublicense, or distribute it is void, and
will automatically terminate your rights under this License.

However, if you cease all violation of this License, then your license
from a particular copyright holder is reinstated (a) provisionally,
unless and until the copyright holder explicitly and finally
terminates your license, and (b) permanently, if the copyright holder
fails to notify you of the violation by some reasonable means prior to
60 days after the cessation.

Moreover, your license from a particular copyright holder is
reinstated permanently if the copyright holder notifies you of the
violation by some reasonable means, this is the first time you have
received notice of violation of this License (for any work) from that
copyright holder, and you cure the violation prior to 30 days after
your receipt of the notice.

Termination of your rights under this section does not terminate the
licenses of parties who have received copies or rights from you under
this License.  If your rights have been terminated and not permanently
reinstated, receipt of a copy of some or all of the same material does
not give you any rights to use it.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the
GNU Free Documentation License from time to time.  Such new versions
will be similar in spirit to the present version, but may differ in
detail to address new problems or concerns.  See

http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number.
If the Document specifies that a particular numbered version of this
License "or any later version" applies to it, you have the option of
following the terms and conditions either of that specified version or
of any later version that has been published (not as a draft) by the
Free Software Foundation.  If the Document does not specify a version
number of this License, you may choose any version ever published (not
as a draft) by the Free Software Foundation.  If the Document
specifies that a proxy can decide which future versions of this
License can be used, that proxy's public statement of acceptance of a
version permanently authorizes you to choose that version for the
Document.

11. RELICENSING

"Massive Multiauthor Collaboration Site" (or "MMC Site") means any
World Wide Web server that publishes copyrightable works and also
provides prominent facilities for anybody to edit those works.  A
public wiki that anybody can edit is an example of such a server.  A
"Massive Multiauthor Collaboration" (or "MMC") contained in the site
means any set of copyrightable works thus published on the MMC site.

"CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
license published by Creative Commons Corporation, a not-for-profit
corporation with a principal place of business in San Francisco,
California, as well as future copyleft versions of that license
published by that same organization.

"Incorporate" means to publish or republish a Document, in whole or in
part, as part of another Document.

An MMC is "eligible for relicensing" if it is licensed under this
License, and if all works that were first published under this License
somewhere other than this MMC, and subsequently incorporated in whole or
in part into the MMC, (1) had no cover texts or invariant sections, and
(2) were thus incorporated prior to November 1, 2008.

The operator of an MMC Site may republish an MMC contained in the site
under CC-BY-SA on the same site at any time before August 1, 2009,
provided the MMC is eligible for relicensing.

ADDENDUM: How to use this License for your documents

To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and
license notices just after the title page:

    Copyright (c)  YEAR  YOUR NAME.
    Permission is granted to copy, distribute and/or modify this document
    under the terms of the GNU Free Documentation License, Version 1.3
    or any later version published by the Free Software Foundation;
    with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
    A copy of the license is included in the section entitled "GNU
    Free Documentation License".

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
replace the "with...Texts." line with this:

    with the Invariant Sections being LIST THEIR TITLES, with the
    Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other
combination of the three, merge those two alternatives to suit the
situation.

If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License,
to permit their use in free software.
8 November 2011

Abstraksi dan Konsep 2

Saya menemukan algoritma tertua yang pernah ada, untuk mencari akar pangkat dua, he he he.

Resep orang Babilonia, untuk mencari akar pangkat dua dari 250 ( ataupun sembarang angka ):

1. Bagi 250 dengan asal tebak angka

2. Cari rata-rata dari asal tebak angka dan hasil pembagiannya

3. Ulangi sampai dapat tingkat ketelitian yang diinginkan

What?? ndak mudeng aku?

misal, saya asal tebak angka 10, untuk akar pangkat dua dari 250. Ini rincian perhitungannya !

Tebakan

Pembagian

Rerata

Tebakan Berikutnya

10

250/10 = 25

(25+10)/2=17.5

17.5

17.5

250/17.5 = 14.285

(17.5+14.285)/2=15.89

15.89

15.89

250/15.89 = 15.73

(15.89+15.73)/2=15.81

15.81

23 September 2011

abstraksi dan konsep

Jika saya harus menulis pendek untuk menggambarkan abstraksi dan konsep, maka ini-lah yang saya tulis:

Saya belajar waktu kecil, satu tambah satu sama dengan dua.
Orang tua saya bilang, satu buah tambah satu buah sama dengan dua buah.
Teman saya bicara, satu menit tambah satu menit sama dengan dua menit.
Akuntan menghitung, satu juta tambah satu juta sama dengan dua juta.
Aljabar menunjukkan pada saya abstraksi dan konsep: satu n tambah satu n sama dengan dua n.

Tag:
9 Agustus 2011

Kolaborasi..Saat Ini Juga

Disclaimer: Semua tulisan saya hanya mewakili konsep dalam bahasa paling awam, untuk menggambarkan konsep rumit yang digunakan Teknologi Informasi. Referensi lebih lanjut bisa anda cari di Internet atau source yang lebih valid daripada saya :)

Real-time collaboration? Pertama kali saya mendengar istilah ini, pikiran saya terlintas teknologi yang rumit, setidaknya, melibatkan teknik yang jelimet. Saya terpesona ketika pertama kali Google memperkenalkan istilah ini dan mendemonstrasikan secara langsung dengan Wave-nya. dan buat saya, ini adalah pengalaman ‘wow’ saya yang membuat saya merinding (damn, mereka benar-benar pintar cipta-in sesuatu :p) Sayang baby project ini tidak sempat berkembang menjadi real aplikasi karena sambutan yang tidak terlalu banyak untuk menggunakannya. Semenjak itu banyak orang mencoba menawarkan tekniknya untuk membuat suatu web bisa menjadi lebih real-time.

Namun waktu membuat saya untuk memahami-nya bahwa teknik ini, sebenarnya, tidak terlalu rumit (walau dulu-nya saya menganggap bahwa ada teknik ‘sulap’ tingkat tinggi untuk bisa membuat hal seperti itu, atau bahasa teknis-nya adalah, bagaimana membuat dua (atau lebih) pemakai berbeda, saling berkirim pesan sedemikian rupa, sehingga saling memperbarui konten yang mereka buat?)

Saya berpikir (dulu) bahwa infrastruktur mereka pasti bagus, setidaknya ada protokol XMPP dibalik teknik seperti ini. Dan tebakan saya tidak terlalu meleset, bahwa hal seperti ini membutuhkan infrastruktur teknologi. Sampai satu ketika, waktu mengenalkan saya dengan HTTP REST, salah satu infrastruktur yang saya sebut-sebut tadi. REST sendiri adalah akronim dari REpresentational State Transfer yang artinya Pertukaran Keadaan yang Terwakilkan. Bingung? bahasa awam-nya adalah, data-dalam-banyak-rupa, tetapi sama secara isi/konteks, dan dapat dipertukarkan dengan mengubahnya menjadi format yang diinginkan (tanpa bentuk fisik sebuah file yah). Bayangkan begini, anda punya data dalam bentuk CSV (kumpulan data dengan pemisah koma) seperti ini:

Nama depan, Nama belakang, Alamat surel
Budi, Doe, budidoe@contoh.com
Tuti, Doe, tutidoe@contoh.com

Nah, untuk menukar data, katakanlah, cabang anda menggunakan sistem yang hanya membaca format XML sehingga kita perlu mengubah data kita, menjadi format yang diperlukan, dan dibaca oleh orang yang kita berikan datanya (dalam contoh ini, cabang anda) . Kita akan mengubah data-nya menjadi format seperti ini:

<?xml version="1.0" encoding="utf-8" ?>
<data>
<record>
<nama depan>Budi</nama depan>
<nama belakang>Doe</nama belakang>
<alamat surel>budidoe@contoh.com</alamat surel>
</record>
<record>
<nama depan>Tuti</nama depan>
<nama belakang>Doe</nama belakang>
<alamat surel>tutidoe@contoh.com</alamat surel>
</record>
</data>

Jelas sekali terlihat bagaimana data berubah bentuk tanpa kehilangan isi (baca: state) yang dikandungnya, dalam hal ini konversi CSV menjadi XML. Inilah state yang dimaksud dan coba dijelaskan oleh konsep REST, bahwa data dapat berubah (transisi) , dan disebut state, dan dapat dipertukarkan dengan mudah antar sistem. Tidak ada file fisik yang menyimpan data itu karena semuanya hasil olahan dari basis data yang kita gunakan. Dan jika ditambahkan dengan HTTP menjadi HTTP REST, ini berarti maksudnya…, yup, benar sekali, pertukaran lewat protokol HTTP.

Pernah mencoba Amazon Web Service? (disclaimer: saya bukan marketing-nya :p) Saya sudah. Saya menggunakannya untuk meng-upload data saya, berupa berkas, atau gambar, atau musik atau lainnya dan semuanya melalui jalur protokol HTTP. Artinya, anda mengirim data, dan mengaksesnya melalui sebuah alamat URL, katakanlah: http://contoh.com/datasaya/gambar/koleksi1. Walau ini sedikit membahas Cloud Computing, namun yang saya mau coba jelaskan adalah konsep bagaimana melakukan pertukaran melalui protokol HTTP. Anda bisa menambahkan album dari koleksi1 menjadi koleksi2 dan dapat mengaksesnya di alamat url: http://contoh.com/datasaya/gambar/koleksi2. keren? yup, Hal ini yang benar-benar mengubah saya dan membuat saya berhasil menyingkap teknik yang mungkin, untuk aplikasi semacam Wave.

Belum ‘ngeh’ dengan penjelasan saya, bagaimana mungkin kolaborasi real-time dapat dilakukan sejauh ini? Bung, bagaimana pengguna dapat berkomunikasi, kalau setiap request harus dibuka ulang? (protokol http bilang, anda hanya di-ijinkan melakukan request POST atau GET dengan membuka ulang halaman web) Anda juga harus melewati larangan untuk mengirim AJAX request, seandainya anda menggunakan AJAX, melewati domain yang berbeda atau lintas domain.

Jawabannya, adalah melalui teknik AJAX (untuk teknik ini, pembahasannya mungkin lain kali ya) Push Server-side Proxy. Untuk melewati domain, anda membutuhkan proxy untuk melakukan request yang membuat server mengira anda adalah server. Umumnya, browser adalah client yang melakukan request (meminta) halaman kepada server untuk ditampilkan. Maksudnya istilah client di sini adalah, selama anda masih di-url, katakanlah, http://contoh.com, anda dapat bebas mengakses halaman(resource) di http://contoh.com. Kalau anda anda di-url http://contoh.com dan melakukan request dari http://contoh.com ke http://example.com (ilustrasi) langsung dari browser, maka anda akan mendapatkan pesan error mengabarkan bahwa anda melakukan panggilan lintas domain (dan tidak bisa untuk alasan keamanan). Ada banyak teknik untuk meng-akali kondisi ini seperti menggunakan IFrame atau melakukan long-polling (Anda bingung kenapa browser sekarang ini reloadnya seperti lama karena indikator-nya berjalan terus? ini mungkin artinya, website itu melakukan teknik long-polling dengan membuka terus connection-nya) . Saya sendiri menemukannya mudah jika menggunakan server proxy.

Itu artinya, begini:

  • Saya harus menulis proxy-call untuk website saya
  • Saya harus mengamankan port-nya untuk Unauthorized Request (artinya, private hanya untuk saya yang guna-in)
  • Saya harus meng-enkripsi datanya
  • Saya harus mengompress data-nya untuk menghemat bandwitdh dan storage
  • Saya harus membangun REST Server saya pribadi
  • Saya harus membangun AJAX-call service di server saya
 
Sebelum checklist saya menjadi bertambah panjang, itulah daftar yang harus saya kerjakan, sebelum saya membangun tutorial Menulis Source Real-Time di website saya. Dan dengan ini saya memperkenalkan sebuah demo aplikasi real-time pertama saya :p, yaitu: 
Chilik Channel <http://goo.gl/wveJO>


Creative Commons License 
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. 
6 Agustus 2011

Lisensi, kuatir.. atau tidak kuatir? itulah pertanyaannya

Ceritanya begini, saya membuat framework untuk satu bahasa, kemudian merilisnya dengan lisensi, katakanlah lisensi ‘A’. Nah, untuk publisitas, tentu saja saya langsung promosi di forum terbesar Indonesia untuk menjangkau pengguna framework ini ke depan-nya untuk bertambah. Lumayan besar antusias-nya terbukti dari jumlah traffic yang saya analisa maupun jumlah yang men-download framework ini. Kemudian timbullah satu pertanyaan dari penghuninya, kenapa lisensi ‘A’?  ada yang meminta lisensi Chilik Framework diubah saja, dari lisensi ‘A’ yang strict menjadi yang lebih ‘fleksibel’.  bahkan ada yang nekat ‘memaksa’. Hehehe… ada ada saja nih ulah mereka, pikir saya dalam hati.

Mengenai lisensi, saya sudah lama mengetahuinya dan merupakan concern saya untuk sedapat mungkin, tidak merugikan pihak lain. Kesadaran ini tentu saja bukan datang tiba-tiba. Banyak artikel yang saya baca untuk ‘menjaga’ saya, jika saya terantuk dengan masalah lisensi. Namun menarik bercerita sedikit tentang lisensi, terutama yang saya bahas tentu saja tentang lisensi software.

Lisensi untuk piranti lunak sendiri berkaitan dengan hak cipta, yaitu hak atas kekayaan intelektual penemunya. Biasanya seorang penemu akan mendaftarkan paten, spesifik mengenai hal/teknik/metode/produk yang ditemukannya, dan mengenakan biaya dengan menerbitkan  lisensi bagi yang  menggunakan hasil temuannya. Hal ini menjamin penghargaan (dalam hal ini sejumlah uang) atas hasil temuannya dan mendorong orang lain menemukan solusi lain dari yang sudah ditemukan. Hal itu bagus bukan?

but, we live in imperfect world, and corrupted implementation. Sedemikian pintar-nya orang sampai dapat ‘mengeksploitasi’ paten ini menjadi senjata menakutkan. Alih-alih paten mendorong kemajuan (khan mengharuskan untuk mencari solusi lain untuk masalah yang sama), pada praktiknya beberapa perusahaan menggunakan-nya untuk menjegal perusahaan lain. Nah, disinilah kita menggunakan definisi proprietary untuk melabeli mereka yang memiliki hak ekslusif, yaitu paten. Satu perusahan mengajukan tuntutan karena satu produk terlalu populer (ingat Nokia vs Apple?) , atau satu perusahaan menjegal popularitas satu piranti lunak (SCO vs. Linux (IBM))  ataupun yang terbaru saat ini bersatu membentuk konsorsium (mengumpulkan modal membeli paten) mencegah kepemilikan suatu paten oleh satu perusahaan (lihat Novell dan Nostrell paten).  so, bisa dilihat, dunia proprietary adalah dunia dimana satu sama lain saling menuntut (hahaha, bener gak yah tarik benang merahnya :p).

Paten sendiri bisa berakhir, but jangan terlalu berharap untuk piranti lunak saat ini karena rentang waktunya yang masih panjang. Setiap paten yang ditemukan biasanya akan berakhir selama hidup penemunya plus 60 tahun. Paten akan ber-umur 95 tahun dari tahun dirilisnya/ dipublikasikan atau 120 tahun dari waktu pembuatannya.  Tariklah angka 100 tahun untuk setiap paten, maka bisa dikatakan setiap 1 abad kemudian kita akan menemukan suatu produk, paten-nya berakhir… dan masuk dalam Public Domain (Wilayah Publik). Ketika suatu produk masuk dalam Public Domain, maka royalti dan hak cipta tidak dapat dikenakan lagi sehingga satu karya menjadi bebas digunakan tanpa ijin sekalipun (misalnya, karya Sherlock Holmes-nya Conan Doyle atau karya Shakespeare).

Seseorang bisa saja menaruh karya-nya dalam Public Domain sebebas orang memberikan piranti lunaknya kepada orang lain. Artinya ‘memberikan cuma-cuma’ tanpa biaya. Namun hal ini tidak menjamin apapun, karena bisa saja si pemberi berubah pikiran dan mengenakan charge. Atau, ternyata piranti lunak-nya penuh bug atau membuat hardware-nya rusak. Hal ini tentu saja akan berakhir di pengadilan dengan tuntutan kepada si pemberi-nya. Hmm, tentu bukan hal ini khan yang di-inginkan? maka muncullah kata-kata yang harus disertakan, yang kurang lebih bunyinya seperti ini, ” …diterima APA ADANYA, DENGAN HARAPAN DAPAT BERGUNA TANPA MENYEDIAKAN JAMINAN, TERTULIS ATAUPUN TIDAK, ATAUPUN SESUAI DENGAN KEBUTUHAN BISNIS TERTENTU ATAU SPESIFIK. TIDAK ADA SATU ALASAN APAPUN DAPAT MEMBAWA PENULISNYA ATAUPUN PEMILIK HAK CIPTA DALAM SATU TUNTUTAN ATAU KLAIM.. “. Nah, inilah yang mendorong bermunculan lisensi seperti lisensi BSD-like, atau Apache atau MIT (perbedaannya hanya sedikit, misalnya harus mencantumkan nama pembuatnya, dll).

But, tentu saja dalam prakteknya, kita menemukan orang-orang oportunis yang memanfaatkan kebaikan seperti ini, dengan membuatnya menjadi  proprietary karena dia telah menaruh ‘resep’ spesial dan membuat fitur baru yang super (bombastis nih bahasanya :p). Tidak ada satupun lisensi yang saya singgung di-atas dapat melakukan tindakan apapun terhadap orang-orang tipe ini, selain satu lisensi yaitu GPL(General Public License). kenapa tidak bisa? karena hanya satu-satunya lisensi yang mengharuskan semua karya yang dirilis dalam lisensi GPL, selalu menggunakan lisensi: GPL.

Lalu, Chilik framework menggunakan lisensi apa? you know, lah :)

 

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

27 Juli 2011

Chilik, satu (lagi?) MVC Framework lokal

Pencarian ini bermula dari keperluan saya untuk membuat mock-up template dari sebuah web aplikasi toko online. Untuk fully-worked website, saya biasanya mengandalkan CodeIgniter, lebih lengkap semua fitur-nya. But, sekali lagi, ini khan hanya mock-up template? (buat yang masih asing dengan istilah mock-up, adalah seperti prototipe/purwarupa dari satu hal).

Butuh cepat pembuatannya dan ringan, sekaligus tidak murahan. Itu pertama yang ada di pikiran saya. Googling punya Google ternyata berujung membawa saya ke satu site, KissMVC. Pembuatnya, Erik Koh (sepertinya anak Singapura – cuma nebak), menawarkan satu PHP MVC framework style yang enteng. Hmm, cocok!

Saya ikuti pembahasan di dokumentasinya, tweaking, dan yap, berhasil jalan. So, saya begitu senang ternyata masalah saya terpecahkan, sebuah live mock-up template di server localhost. Sampai saya membuat direktori di folder controller-nya dan, celaka, tidak terdeteksi. Oalah, ternyata controller dari core-nya hanya menggunakan routing:

<controller>/<action>/<parameter>.

Dan jika saya menggunakan cara routing seperti ini:

<directory1>/.../<controller>/<action>/<parameter>,

hanya membuat saya mematahkan rule routing-nya dan membuat bootstrap-nya tidak membaca. Satu lagi yang paling menganggu saya, semua controller-nya harus dimulai dengan awalan function _index(), padahal biasanya function index(). Dan satu hal lagi, ternyata view-nya tidak memisahkan business logic dan presentation, jadi spaghetti code campuran syntax html, css, php. So, ini memaksa saya berpikir ulang, dan mendapatkan ide, apa susahnya kalau saya bikin sendiri?

Ternyata susah, euy!

Banyak hambatan dan tantangan yang saya temui selama memikirkan dan mematangkan konsep dan implementasi MVC Framework yang ringan ini. Ternyata parsing routing ini termasuk faktor yang mempengaruhi begitu banyaknya MVC framework yang muncul. Pendekatan masing-masing ternyata berbeda satu sama lain. kode Controller dari Kiss saya rombak total. View-nya saya ubah total, bahkan saya membuat versi JSON-output ataupun Smarty-output. Not bad-lah buat pemula penulis framework! Untuk kode Model-nya, absolutely cocok untuk keperluan saya. saya memakainya.

so, jadilah Chilik framework, sebuah rangka PHP dengan pendekatan Model-View-Controller lokal (pertama?) yang dibuat saya. Dan saya puas dengan hasil-nya :).

 
Tertarik dengan Chilik MVC Framework, anda dapat mengunduh link ini karena saya membuka source-nya dan dibawah lisensi GNU GPL. 3. Silahkan anda merubahnya dan memberikan pendapat untuk pengembangannya.

Catatan:

selain kekurangan, tak elok-lah jika saya tidak mencantumkan kelebihannya.

Mudah

  • Hanya menggunakan 1 file inti, terdiri dari 3 class fungsi MVC (Kissmvc_core.php) .

Kecil

  • (maka saya menggunakan kata cilik untuk framework saya) File Inti hanya sebesar 12KB jika dikompres, atau 3.5KB jika dikompres.

Minimalis

  • Hanya fungsi esensial yang di-dukung

Kokoh

  • Inti kode sangat kecil dan mudah untuk diaudit dan diamankan dengan cepat
  • proteksi injeksi SQL karena menggunakan PDO (paling tanpa cacat menurut saya kode Modelnya).

Tidak mengikat

  • Tidak ada batasan untuk menggunakan library lain seperti PEAR dan Object Relational Mapping.
  • Semua parameter global PHP dapat diakses.

Fleksibel

  • Abstraksi PDO memudahkan pilihan macam macam database (mendukung MySQL, PostgreSql, dan SQlite).
  • Kode Inti MVC dapat ditambahkan dan diturnkan dengan mudah menggunakan Inheritance dalam Pemrograman berorientasi objek.
  • Pilihan untuk menggunakan prosedural atau pendekatan OOP, atau keduanya!

Cepat

  • Tidak ada fitur, kode atau framework yang memberatkan.
  • Bahkan lebih cepat jika digunakan semacam PHP Accellerator seperti APC.

Gratis

  • Open-source, dan piranti lunak bebas yang dirilis dibawah lisensi MIT.
  • Anda bebas melakukan apapun pada kodenya selama tidak menghapus tulisan lisensi di kodenya.

15 Juli 2011

Zip ID, ya, Kode Pos seluruh Indonesia dan.. web aplikasi bag. 1

Sebenarnya proyek ini termasuk proyek yang sudah lama menjadi, yang saya namakan, proyek rintisan. Proyek awal yang kelihatan mudah namun sebenarnya terdiri dari potongan-potongan pengalaman dalam membuat sebuah web aplikasi. Jujur saja, untuk datanya saja, saya harus menghabiskan waktu, lumayan banyak. Kenapa? Yup, saya melakukan pengumpulan data secara manual, alias manuallycrawlingweb kode pos, hasil googling di internet!

Lama dong? Ya bener, harus saya akui ini pekerjaan menantang. Dan untungnya, saya lakukan ini sudah lama, beberapa tahun yang lalu, jadi tidak terlalu malu untuk diceritakan di blog ini. Saya benar-benar tidak habis pikir, kenapa tidak ada orang Indonesia yang mau membagikan datanya gratis, maksud saya, tentu saja data publik, seperti kode pos, nama jalan, kurs bi, data saham misalnya, di internet sehingga saya tidak perlu kerjakan manual, copy-save yang menghabiskan banyak waktu?

Dengan pemikiran seperti ini, saya mendesain aplikasi web saya (belakangan diberi nama ZipID) supaya datanya mudah di-share. Data kode pos ini, saya rancang untuk dapat dibagikan hanya dalam kurang dari 1 menit. Haha.. terlalu ambisius? Nope. Dalam perjalanan, saya menemukan cara yang memudahkan saya.

Beberapa tahun yang lalu, mungkin format untuk pertukaran data yang banyak dipakai di internet adalah XML. Namun trend beberapa tahun terakhir, ternyata sudah berpindah ke JSON, karena lebih mudah dimengerti dan ramah dibaca orang (bukan hanya mesin). Dan saya benar-benar ter-inspirasi dengan gerakanNoSQL untuk mengerti konsep JSON secara menyeluruh (saya berencana untuk membahasnya sebagai topik selanjutnya). NoSql adalah konsep baru yang ditawarkan untuk menanggulangi besarnya data dan skala aplikasi, seperti yang dihadapi Google, Facebook atau Twitter. Agak panjang untuk menjelaskan, mungkin kesempatan lain saya bisa membahasnya secara mendalam.

So, akhirnya saya berhasil mengetahui tentang JSON dan NoSql movement. Karena dengan 2 hal ini saya dapat mem-bagikan data saya, dengan mudah dan cepat tentunya. Desain saya untuk format kode pos format JSON, adalah seperti ini:

{“zipID”:”welcome”,”version”:”1.0″}

dan untuk format isinya(content) yang dibagikan:

{ “status”:”OK”,

 "rows_affected":6,
 "results":[
 {"kode_pos":"10110","kelurahan":"Gambir","kecamatan":"Gambir","kota-kabupaten":"Jakarta Pusat","provinsi":"DKI Jakarta"},
 {"kode_pos":"10120","kelurahan":"Kebon Kelapa","kecamatan":"Gambir","kota-kabupaten":"Jakarta Pusat","provinsi":"DKI Jakarta"},
 {"kode_pos":"10130","kelurahan":"Petojo Utara","kecamatan":"Gambir","kota-kabupaten":"Jakarta Pusat","provinsi":"DKI Jakarta"},
 {"kode_pos":"10140","kelurahan":"Duri Pulo","kecamatan":"Gambir","kota-kabupaten":"Jakarta Pusat","provinsi":"DKI Jakarta"},
 {"kode_pos":"10150","kelurahan":"Cideng","kecamatan":"Gambir","kota-kabupaten":"Jakarta Pusat","provinsi":"DKI Jakarta"},
 {"kode_pos":"10160","kelurahan":"Petojo Selatan","kecamatan":"Gambir","kota-kabupaten":"Jakarta Pusat","provinsi":"DKI Jakarta"}
 ]
 }

 Dan saya mendesain hasil JSON ini untuk dibagikan hanya dengan 1 url:

 http://freelancecode.cz.cc/api/fluks/zip/search?id=101

 bersambung …

15 Juli 2011

Hello world!

Sorry, interrupted.

Hello World of WordPress. So, ini adalah jurnal pertama saya, yang rencananya akan menceritakan segala hal menarik dari dunia saya, dunia programming. so, enjoy my posts :)

Welcome to WordPress.com. After you read this, you should delete and write your own post, with a new title above. Or hit Add New on the left (of the admin dashboard) to start a fresh post.

Here are some suggestions for your first post.

  1. You can find new ideas for what to blog about by reading the Daily Post.
  2. Add PressThis to your browser. It creates a new blog post for you about any interesting  page you read on the web.
  3. Make some changes to this page, and then hit preview on the right. You can alway preview any post or edit you before you share it to the world.
Ikuti

Get every new post delivered to your Inbox.