Jumat, 20 September 2013

Bongkar kardus BandrOS

Alhamdulillah saya dapat mencicipi BandrOS, buah karya LIPI yang sempat dibahas di media massa beberapa waktu yang lalu. Yang saya terima adalah kotak yang belum dibuka sama sekali, alhasil saya berkesempatan untuk mengalami bagaimana membuka kotak BandrOS.

Kesan Pertama

Saat menerima kotaknya, kesan pertama saya bahwa BandrOS pada kondisi ini tidak dimaksudkan untuk tujuan komersial. Hal ini nampak jelas pada desain, warna dan eksekusi kemasan yang agak berbeda dari kemasan komersial. Di satu sisi, nampak tulisan BandrOS dengan gambar latar potongan gambar jembatan(?), dengan disematkan beberapa logo yang kurang jelas maksudnya (ada logo bergambar kujang).


Di sisi baliknya ada gambar perangkat kerasnya yang dilihat dari berbagai sisi. Kemudian di sisi samping ada lagi kumpulan logo-logo teknis dan ada tulisan bahwa perangkat ini adalah sebuah prototipe atas kerjasama LIPI, Ristek, dan KEMKOMINFO.

Isi kotak

Susunan kotak mirip dengan susunan kotak kemasan telepon seluler komersial biasanya. Pesawat telepon ada di sisi atas, menempati kotak kecil yang terbuat dari karton seukuran pesawatnya. Di susunan bawah terdapat perangkat pengisi daya, kabel USB, dan peranti dengar sekaligus mikrofon yang masing-masing dikemas dalam plastik bening.


Pesawat telepon memiliki baterai yang diberi label BandrOS tanpa ada keterangan spesifikasi teknisnya. Baterai ini sudah terisi hampir setengahnya.

Pesawat telepon

Pesawat telepon yang menjadi referensi BandrOS sepertinya produk IMO S79 sebagai mana tertera di stiker yang terdapat di dalam kotak. Pesawat ini memiliki 1 colokan USB mikro, 1 colokan audio 3.5 mm 4 kutub, 1 kamera belakang, 1 kamera depan, dan layar 3.5 inci.


Pesawat ini dibuat di Cina (seperti tertera dalam teks di badannya) dan disablon tulisan BandrOS di belakangnya. Sayang sekali kualitas sablonnya kurang baik.

BandrOS

Saat diboot BandrOS menampilkan logo yang saya kurang dapat menangkap bentuk apa itu sebenarnya, kemudian ada layar bertuliskan HARTEKNAS (mungkin saat peluncurannya), dan ada sepotong klip. Sesaat setelah itu langsung masuk layar pengunci.



Saat dibuka, akan muncul layar depan dengan menampilkan jam dan menu. Jika tombol menu ditekan maka muncul daftar aplikasi yang terpasang. Sudah cukup banyak aplikasi yang terpasang dan kebanyakan adalah layanan dari luar negeri (Skype, Twitter, Yahoo! Messenger, YouTube dan Google Talk). Kemudian ada permainan balap mobil dengan grafik yang cukup bagus dijalankan.

Dengan prosesor Cortex A9 1 GHz, aplikasi-aplikasi dapat dibuka dengan cepat dan responsif. Respon taktil berupa getaran juga terasa dengan baik tanpa latensi yang besar.

Sistem BandrOS sepertinya adalah remaster dari Android Gingerbread versi 2.3.6. Sayang sekali saya tidak dapat menemukan aplikasi khas BandrOS di dalam menu tersebut. Dan saat saya coba menggunakan koneksi nirkabel wifi di rumah, peramban yang terpasang tidak dapat menampilkan halaman yang saya ingin buka.

Jika berniat untuk menuju produksi massal, barangkali adalah suatu ide bagus untuk menggaji desainer grafis dan konsultan merek agar hasilnya lebih baik. Sebab di BandrOS versi 1 ini, masih banyak yang perlu dipoles dan digosok. Selain itu, teks lisensi perangkat lunak yang bebas seperti kernel GNU/Linux tidak disertakan tercetak dalam kotak. Saya belum lihat apakah ada versi digitalnya dalam perangkat.

Jika dipikir-pikir

Target pasar BandrOS adalah target menengah ke bawah dengan anggaran kecil. Pesawat IMO S79 berkisar di harga Rp 650 ribu. Jika BandrOS diproduksi massal dengan kondisi sekarang, saya rasa sulit untuk bersaing dengan anak-anak lama yang saling sikut dan tendang untuk meraih kue di bidang ini.

Namun lain ceritanya jika BandrOS juga dibundel dengan aplikasi-aplikasi khas dan untuk keperluan khusus dan dibutuhkan massal, saya kira kesuksesan BandrOS akan lebih bisa dipastikan. Salah satu contoh, misalnya seluruh PNS di Indonesia wajib menggunakan BandrOS dengan aplikasi khusus PNS, ini bisa jadi langkah berikutnya yang bisa digarap tim LIPI karena ekosistemnya otomatis sudah tercipta.

Mudah-mudahan apa pun strategi berikutnya, dapat membawa hasil yang lebih baik.

Catatan:
Foto-foto lain dapat dinikmati di sini: https://www.dropbox.com/sh/zl1o2j6sa7o79xz/y946hFrYcx#/

Senin, 16 September 2013

Tiga mitos open source



Dari beragam kesempatan bertemu komunitas open source, sering saya dapati pemahaman yang sedikit keliru tentang open source. Hal ini mungkin terjadi karena belum memahami open source secara keseluruhan dan kebetulan faktanya memang sedikit abu-abu. Pemahaman-pemahaman yang agak kurang tepat tersebut berubah menjadi mitos yang berkembang. Namun, memang mitos-mitos tersebut dapat menjadi fakta jika ada hal-hal lain yang menunjang.

Open source itu gratis

Tidak sedikit orang (termasuk pejabat negara) yang mengatakan bahwa open source itu gratis, misalnya: "Selama ini anggaran habis hanya untuk program proprietary, jadi kami sangat tertarik dengan solusi open source yang memang gratis". Hal ini sama sekali tidak benar. Solusi open source bisa jadi dapat diperoleh tanpa biaya sedikit pun, namun ada biaya-biaya lain yang menyertai solusi tersebut. Misalnya:
  • biaya pelatihan, untuk dapat menggunakan solusi open source, sebagaimana solusi lainnya, juga membutuhkan biaya untuk melatih para penggunanya
  • biaya migrasi, jika sistem lama yang akan diganti memiliki format data yang jauh berbeda, maka hal ini membutuhkan biaya migrasi yang tidak sedikit
  • biaya integrasi, jika sistem open source tidak memiliki kapabilitas untuk melakukan hal-hal spesifik yang dibutuhkan pengguna untuk terkoneksi dengan sistem lama, maka perlu memanggil seorang pemrogram untuk menulis modul yang diperlukan.
  • biaya-biaya lain yang tidak terfikirkan sebelumnya, misalnya biaya konsultasi, biaya interoperabilitas, dan lain sebagainya

Open source itu mudah dikembangkan

Pemahaman ini biasanya berdasarkan fakta bahwa kode sumber dapat dilihat oleh pengguna. Memang hal ini lebih mudah, jika si pengguna memang mengerti bahasa pemrograman dan memiliki waktu dan kemampuan untuk memodifikasi sesuai kebutuhan. Namun jika si pengguna awam sama sekali, maka ada atau tidak ada kode sumber itu sama saja. Kembali lagi ke mitos bahwa open source itu gratis. Mitos ini baru bisa menjadi fakta jika si pengguna memiliki tim atau memiliki biaya untuk melakukan modifikasi sesuai kebutuhannya.
Ada juga yang berpendapat bahwa pengembang open source dapat diminta untuk melakukan pengembangan sesuai keinginan kita tanpa biaya, toh open source itu gratis. Hal ini justru bertolak belakang, karena pengembang open source biasanya adalah pengembang-pengembang profesional yang memiliki gaji besar.

Open source itu bebas

Tidak semua perangkat lunak open source bebas. Jika kita bicara perangkat lunak, baik open source atau proprietary, maka kita bicara dua aspek penting:
  • hak cipta, siapa pemilik hak cipta atas kode sumber yang ada. Apakah dimiliki pengembang perangkat lunak atau si pemilik pekerjaan?
  • lisensi, bagaimana perangkat lunak tersebut dapat dimodifikasi, didistribusikan, dijual atau diapakan saja, itu diatur melalui lisensi yang disematkan oleh si pemilik hak cipta
Sering saya dapati pemahaman bahwa jika kita menggunakan perangkat lunak open source, maka otomatis kita memiliki kode sumber tersebut. Padahal belum tentu. Perlu dilihat lagi lisensi apa yang diberikan oleh si pemilik hak cipta. Jika menggunakan lisensi public domain, maka si pemilik hak cipta melepas haknya dan memberikan kode sumber secara keseluruhan ke publik dan terserah publik hendak diapakan kode sumber tersebut. Jika menggunakan lisensi GPL versi 2, maka kode sumber bebas diubah, dipakai, dikembangkan, bahkan dijual, dengan syarat segala perubahan yang dikembangkan juga menggunakan lisensi yang sama. Pemilik hak cipta pun tidak serta-merta beralih ke kita, namun semua yang terlibat melakukan modifikasi memiliki hak cipta atas kode sumber tersebut.

Ada beragam lisensi yang dapat dipilih oleh pemilik hak cipta, beberapa di antaranya dapat dilihat di situs http://opensource.org/licenses.

Di dunia open source, ada beberapa ideologi yang berbeda yang dianut oleh para komunitas pengembang:
  • Ideologi perangkat lunak bebas (free software), yang menjunjung tinggi kebebasan dalam menggunakan, memodifikasi dan mendistribusikan, namun justru mengikat kuat dan membatasi jenis lisensi yang dapat disematkan ke kode sumber. Karya-karya turunan dari kode sumber asli harus menggunakan lisensi yang sama dan melarang menutup kode sumber yang sudah dimodifikasi. Contoh lisensi yang digunakan oleh ideologi ini adalah GPL.
  • Ideologi perangkat lunak liberal, yang menjunjung tinggi kebebasan dalam segala hal, termasuk kebebasan dalam menutup kode sumber. Contoh lisensi yang digunakan oleh ideologi ini adalah BSD dan MIT.
  • Ideologi kode buangan (code drop), yang membuka kode-kode sumber beberapa modul pilihan dan membatasi hak-hak pengguna dalam menggunakan kode sumber tersebut, misalnya kode sumber tersebut tidak boleh dimodifikasi, hanya boleh dipelajari saja, dan sebagainya. Ada banyak perusahaan komersial yang membuka kodenya hanya untuk keperluan studi banding saja. Namun ada juga yang menggunakan lisensi GPL atau lisensi liberal untuk kode buangan ini, intinya, kode-kode ini biasanya memang tidak ditujukan untuk menggunakan model pengembangan open source yang lazim dipakai.

Apa yang harus aktivis lakukan?

Banyak aktivis yang biasanya tidak menyampaikan hal-hal di atas, entah apakah karena memang tidak tahu atau menyembunyikannya. Menurut hemat saya, pemahaman sepenuhnya tentang open source harus disampaikan agar pengguna nanti tidak kecewa. Memang jika kita lihat sekilas, hal-hal di atas dapat menjadi sentimen negatif terhadap open source, namun jangan khawatir. Jika aktivis dapat mendorong pengguna agar mengumpulkan komunitas dengan minat dan menggunakan solusi yang sama, maka biaya-biaya yang disebut di atas serta ongkos pengembangan dapat diatasi secara bergotong royong dan membuka kembali modifikasi yang telah dilakukan ke publik. Inilah ciri utama open source, yaitu kontribusi ke publik, karena open source tanpa kontribusi hanyalah omong kosong.

Minggu, 26 Mei 2013

GNOME Asia 2013

I got back from GNOME.Asia 2013 in Seoul, which was held from 24-25th May, 2013. The conference was not really crowded as I initially expected, however the local attendance is about 90% according to Simon, the head of the organizer. It is actually my first GNOME.Asia and my first visit to Seoul and also my first time being sponsored both by the GNOME Foundation (for flight and hotel) and BlankOn Project (for visa and daily allowance).

There's quite a number of high profile speakers from GNOME in the whole conferences, as well as some other hackers from outside GNOME project. It was interesting how we interacted as one free and open source community, and not as GNOME or not GNOME regardless the conference is about.

There are several talks held in Korean which I unfortunately skipped despite of the topics which are my interest. However, that would be my opportunity to discuss things outside with many new friends. I met Michael Hasselmann, and old friend from Maliit project which I worked with him when I was a Nokia engineer at MeeGo. I have a talk myself talking about Manokwari.


My favorite talk at the conference were:

  • Sandbox Applications by Lennart Poettering
  • The soul'scode on Taiwan campus by Eric Sun
  • Improving cross desktop standard by Cedric Bail 


When the conference ended the speakers had dinner together and had some interesting discussions with some confessions from some folks that they don't use GNOME :D

Rabu, 03 April 2013

Port BlankOn ke ARM

Sebenarnya kalau bilang mau port suatu sistem operasi ke ARM, itu artinya bisa luas sekali. Seperti kita ketahui. ARM itu bukan nama sebuah prosesor, tapi adalah arsitektur prosesor. Arsitektur ini sendiri memiliki banyak versi gugus instruksi, ada ARMv1, ARMv2, dan seterusnya sampai ARMv8. Dan tiap-tiap versi memiliki keluarga implementasi yang berupa-rupa. Misalnya ARMv3 diimplementasikan pada keluarga ARM6 dan ARM7 (perhatikan tidak ada huruf v sekarang), ARMv11 diimplementasikan pada keluarga ARM Cortex-A8, ARM Cortex-A9 dan sebagainya. (Mudah-mudahan tidak pusing :D)

Keluarga ARM tadi juga diimplementasikan oleh beragam pabrik yang memegang hak lisensi ARM. Misalnya untuk ARM Cortex-A9 ada cukup banyak pabrik yang menyediakan sistem dalam chip (System-On-Chip alias SoC), misalnya Amlogic, NVIDIA Tegra 2, ST-Ericsson, dan sebagainya.

Tiap-tiap SoC punya konfigurasi sendiri-sendiri dengan menggunakan sistem jaringan, audio, grafik dan kawan-kawan yang berbeda-beda pula.

Dari keragaman tadi, tentunya berimplikasi bahwa walaupun kita punya satu sistem operasi yang jalan baik di sebuah sistem ARM, belum tentu akan jalan sempurna di sistem ARM yang lain. Tidak seperti di keluarga i386, sebuah sistem Linux dapat dipasang dengan mudah dalam beragam komputer dengan keluarga prosesor yang sama.


Saat melakukan porting, kita akan menentukan lingkup pekerjaan:

  • Seberapa banyak keluarga ARM yang mesti didukung?
  • Seberapa banyak SoC yang mesti didukung?


Lalu kalau kita bilang BlankOn ingin di-port ke ARM, maksudnya apa?

Di sini, kita cukup pilih salah satu keluarga ARM yang ada di tangan para pengembang, dan dari situ sudah cukup klaim bahwa BlankOn di-port ke ARM. Paling tidak saya ada Raspberry Pi (ARM11) dan tablet dengan prosesor Amlogic AML8726-M (ARM Cortex-A9). Jadi kita mulai saja dari kedua sistem tersebut. Ini artinya kita harus mengembangkan dua jenis ARM yang berbeda (ARMv7 untuk ARM Cortex-A9 dan ARMv6 untuk Raspberry Pi).

Lalu bagaimana prosesnya secara umum?
Pertama kali adalah menyiapkan toolchain, yaitu seperangkat alat untuk melakukan kompilasi program. Toolchain harus dikonfigurasikan sesuai dengan jenis prosesor, gugus instruksi, dan varian kompilasi. Sebagai contoh, BlankOn hendak menggunakan konfigurasi hard-float untuk ARMv7 dan ARMv6. Maka, kita perlu dua buah konfigurasi yang berbeda.

Lalu, apa yang mesti dibangun ulang? Mari kita lihat bagan di bawah ini.

Itu adalah bagan sederhana sebuah sistem komputer yang umum. Untuk memastikan port kita berhasil atau tidak, maka kita perlu menyelesaikan port pada semua bagian pada bagan.

Boot loader
Ini adalah sebuah program kecil yang ditanam pada sistem komputer. Program ini dijalankan saat pertama kali komputer dinyalakan, sebelum kernel dimuat. Bootloader ini bertugas memuat sistem operasi atau bahkan memuat bootloader lain. Pada beberapa sistem, bootloader dikunci sehingga tidak dapat memuat sistem operasi lain selain sistem operasi yang disediakan pabrik. Untuk memudahkan pekerjaan kita, lebih baik gunakan perangkat yang bootloadernya tidak terkunci.

Kernel
Kernel adalah jantung sistem operasi. Dia yang mengatur bagaimana sebuah berkas ditulis, bagaimana sebuat paket data dikirim, bagaimana tombol pada papan tik dapat bereaksi, dan seterusnya. Jika perangkat yang kita targetkan memiliki perangkat keras tertentu, maka kita memerlukan penggerak (driver) untuk perangkat keras tersebut agar dapat diatur oleh kernel. Banyak SoC yang memerlukan penggerak dengan lisensi tidak bebas sehingga menyulitkan proses porting.

Userspace
Userspace adalah program-program yang dijalankan sistem dan pengguna akhir. Jika kita sudah memiliki program-program yang dibangun dengan gugus instruksi prosesor yang serupa dengan perangkat target kita, maka kita tinggal menyalin saja program-program tersebut. Namun bila tidak ada, kita harus membangun ulang semua program di userspace dengan gugus instruksi prosesor yang kita gunakan di perangkat target kita. Contohnya, paket-paket yang dikompilasi untuk Raspberry Pi harus dibangun ulang untuk perangkat tablet dengan ARM Cortex-A9.

Dari bagan di atas, bagian-bagian yang diarsir adalah bagian yang spesifik ada di perangkat target kita. Untuk setiap target yang kita inginkan, bagian yang diarsir tersebut harus kita sediakan. Jika kita ingin mendukung 5 buah tablet dengan konfigurasi berbeda, maka kita perlu 5 salinan bagian yang diarsir tadi khusus untuk masing-masing perangkat.

Lalu, setelah semua beres dan sistem dapat melakukan boot ke terminal, apakah kita stop di sini? Tentu saja tidak. Hal-hal yang didiskusikan di atas adalah baru pondasi dari keseluruhan port. Langkah selanjutnya adalah:

  • Memastikan performa perangkat berjalan baik: jaringan berjalan dengan benar dengan kapasitas yang sesuai spesifikasi, memori dan sistem pemberkasan tidak ada yang rusak/korup, tidak ada program yang beku, dan sebagainya
  • Optimasi penggunaan daya
  • Penyesuaian aplikasi. Jika kita menargetkan sebuah tablet, tentu aplikasi-aplikasi kita harus jalan di tablet dengan baik. Jika perangkat kita ada perangkat keras khusus misalnya sensor, maka sensor harus dapat dibaca dari aplikasi dengan baik


Jadi, begitulah kira-kira perjuangan yang harus dilakukan demi mengatakan klaim: Saya melakukan port <masukkan nama distro Anda di sini> ke ARM.

Senin, 01 April 2013

Referensi obyek di JavaScript

Mari jalankan nodejs di terminal lalu ketik:
> a = 12

(tanda > adalah prompt nodejs, tidak perlu diketik).

di layar akan tampil bahwa nilai a adalah 12.

Kemudian kita ketik:
> b = a

Tentu kita harapkan bahwa nilai b adalah sama dengan nilai a, yaitu 12.
Kita bisa pastikan dengan cara mengetik:
> b

Mestinya tampil angka 12.

Lalu bagaimana kalau kita ganti nilai a?
Ketikkan:
> a = 42

Berapa nilai b sekarang? 42 atau tetap 12?
Ketikkan lagi di layar:

> b

Maka akan tampil angka 12. Artinya, nilai b tetap walaupun nilai a diubah.

Mari kita coba lagi dengan jenis lain, yaitu string.
Mari kita ketik:
> a = "saya"

Kemudian kita buat variabel b dan isi dengan nilai a.
> b = a

Kemudian lihat isi nilai b dengan cara mengetik:

> b

Tentu nilai b adalah "saya".
Lalu bagaimana jika kita ubah nilai a?

> a = "sayur"

Periksa isi nilai b:

> b

Maka akan tampil tulisan "saya". Artinya, nilai b juga tidak berubah walaupun nilai a kita ganti.

OK. Sekarang mari kita bikin sebuah obyek.

> a = { nama: "cecep" }

Kemudian kita set variabel b dengan nilai a

> b = a

Kita periksa isi b:

> b
{ nama: 'cecep' }

Kemudian mari kita ubah nilai a menjadi:
> a.nama = "sodikin"

Periksa isi nilai a:

> a
{ nama: 'sodikin' }

Periksa isi b:
> b
{ nama: 'sodikin'}

Oh, ternyata sekarang isi b mengikuti isi a. Apa pun yang kita ubah di a, maka di b turut berubah, tidak seperti sebelumnya. Ini terjadi karena untuk jenis obyek, JavaScript akan menggunakan referensi. Ini mirip dengan pointer di bahasa C/C++. Ibaratnya, variabel b diikat dengan tali ke variabel a. Jika a diubah, maka saat membuka b, JavaScript akan mengikuti tali yang ada hingga ke ujungnya di variabel a, dan isinya dibaca. Jika bukan jenis obyek, isi nilai akan disalin mentah-mentah. Ibaratnya, setiap variabel memiliki kaleng. Setiap diset nilainya, nilai tersebut dimasukkan ke dalam kaleng. Jika nilai variabel yang ada di kaleng a diubah, maka nilai di kaleng di variabel b tidak terpengaruh.

Jika sekarang kita ubah jenis a ke jenis lain, maka jenis b akan tetap sebagai obyek dengan nilai yang tadinya dipegang oleh a.

> a = 12
> b
{ nama: 'sodikin' }

Sekarang bagaimana caranya kalau kita tidak ingin JavaScript mengikatkan tali ke obyek, namun benar-benar berlaku seperti kaleng? Silakan dijadikan PR. (Petunjuk, bisa gunakan Object.keys(b) untuk dapatkan semua kunci di obyek b, kemudian salin isi nilai yang ditunjuk oleh kunci-kunci tersebut ke obyek baru. Jangan lupa ini harus rekursif).

Minggu, 31 Maret 2013

Design and architecture of BlankOn Installer

BlankOn Installer is the central application used in BlankOn Live Media starting from BlankOn 8.0 Rote release. It is a full-screen application intended to take over the desktop when you are not using the live feature of the media.

It is an HTML5 application and the runtime is built with webkitgtk and Vala. The front-end is totally written in HTML, JavaScript and CSS while the back-end is written with various languages bridged by Vala.

The installer slated for BlankOn 9.0 Suroboyo consists of several subsystems below:

  • Partition Editor
  • File System Copier
  • Boot Loader Installer
  • Package Installer
  • File System Configurator

The subsystems are called in sequence according to the stage the user is in. The stage is started with a partition editor and ended with a boot loader installation.
The previous version of installer has similar subsystems but lacks of advanced partition editor and package installer.

Pattern

The software is written using a consistent pattern described as follows. The front-end will call the JS functions defined in the back-end part using JavaScriptCore which is passed in the webkitgtk. The back-end could implement the functionailites by it's own or just call third party libraries or scripts. The JS function defined in the back-end is simply a facade.



To enable developing front-end by just using a web browser, stubs of the JS functions to be defined in the back-end must be provided.

Partition Editor

The installer has an advanced partition editor called PartoEdi. The editor is using KineticJS to make the partition making interactive. The changes in the partitions are accumulated and then played back with libparted in the backend.



The output of the subsystem is a ready to use partition marked for installation and a swap partition. 

File System Copier

This subsystem copies the read only part of the live media into the marked partition. It copies everything without any modifications. The copying is done in the backend using rsync.



The rsync is chosen to get the progress of the copy and to be able to preserve the attributes of the copied files and directories.


File System Configurator

The configurator is run after the installer successfully copied all the files from the media. It creates user and groups defined by the installer. It sets the password. It sets the basic configuration of the system.



The configurations are made by the backend which runs the scripts.


Package Installer

This subsystem, as the name suggests, installs additional packages chosen by user. In the installation, user can choose a certain installation profile. This effectively installs the packages described by the profile. The profile is simply a meta package containing the list of additional packages.



This imperatively says that the packages installed in the live media are the packages shared by all of these profiles. A profile could also ask to remove certain packages installed in the media. The installation is made from local repository self contained in the media itself.

Boot Loader Installer

This subsystem installs the GRUB2 (and optionally with EFI support) into the boot partition.





As you can see the installer is pretty simple and straightforward. At the time of writing this article, the advanced partition, package installer and EFI support is not yet implemented.

Senin, 25 Februari 2013

Running popular mobile platform SDKs in BlankOn 64 bit

For Linux developers, at least both Nokia and BlackBerry suggest to use 32-bit installation. This is to avoid incompatibilities because they only provide their tools in 32-bit. However, it is possible to run them in 64-bit installation by following the guidelines below. The key is to install correct 32-bit packages. These SDKs provided tools are unfortunately very silent when they are missing some packages. The list of packages here were obtained by doing tracing and troubleshooting with strace and ldd tools.

I use 64-bit BlankOn 9.0 Suroboyo alpha daily release. It is compatible with Debian Sid, so the guidelines here applies also to Debian or Ubuntu or other Debian derivatives. The method described here is the multiarch. By using this guide, I can successfully run Nokia Web Tools for Asha and BlackBerry 10 Native Development Kit.

First, we need to register the i386 architecture into the dpkg system:

sudo dpkg --add-architecture i386

Then we need to refresh the package database:
sudo apt-get update
Then we start to install the necessary packages. The packages we install are the GTK+ and friends, Bluetooth, SSL and XUL runner packages:
sudo apt-get  -f -o Dpkg::Options::="--force-overwrite" install ia32-libs gtk2-engines-murrine:i386 libgtk2.0-bin:i386 libgtkmm-2.4-dbg:i386 libbluetooth3:i386 xulrunner-7.0:i386  libstartup-notification0:i386 libssl0.9.8:i386
And that's it. Now you can install the SDKs and enjoy coding for the platforms you desire.



Rabu, 20 Februari 2013

My book is out

Yes, I know many of you think that development environment evolves very quickly and not suitable for printed books, but printed books is still better than having nothing for the developers who have hard time to get a decent internet connection.

Enough said, here it is: GNOME 3 Application Development Beginner's Guide

Minggu, 20 Januari 2013

Icons which are meaningless to (most) people today

Nowadays, too many people in young ages use computers, be it a laptop, smart phone or tablet. Yet, the software are still using icons which are only meaningful to older people. How old? It depends. The line is drawn until a certain person knows or has access to the technology or the metaphors represented by the icons.

Let's see one by one. Note: the icons are not mine, they are from openclipart.org and wikipedia.

Floppy disk for Save

When was the last time you saw this old man's USB stick? Maybe never. Yet, the floppy disk is still used to represent save operation.




Phone handset for Phone


When was the last time you saw this handset? Maybe we still have this in some countries, but I haven't seen it in the last 3 countries I visited in last 3 years (except in museum).




Magnetic tape reel for voice mail

Did you see Mission Imposible TV series in the 1960s? Then you are familiar with the magnetic tape reel :D But how come the object become the voice mail icons?






Hourglass for waiting

This may make sense for most people, but maybe not. In another hand, hourglass shows remaining time left, and not to say that you need to wait. Even if you use hourglass in your apps which the audience is toddlers or kids, maybe they will not get it immediately and will start to hit and punch the device when they're tired of waiting.



Desk calendar for calendar

This is another rarely seen object around the house. If you have the days and dates shown on the icon maybe it is fine, but if just shows tables, maybe it is not.





Rolodex for address book


I personally never seen this in real life, so I event did not get what this thing suppose to mean :D














But hey, we forgot the most important thing. Do we need to keep them or replace them? If we want to replace, replace with what?