Setau saya PLTN Muria tetap akan dibangun,sekarang dalam masa persiapan2 nya. Baguslah, kita sudah waktunya menggunakan teknologi nuklir. Meskipun dalam pembangunannya pasti akan menelan biaya banyak, tapi secara jangka panjang mustinya lebih efisien untuk menambah Energi. Semoga listrik bisa murah, TDL turun.
Cuman yang agak dikhawatirkan adalah, orang kita, Indonesia itu agak selebor,
sehingga probabilitas terjadinya kerawanan / bencana cukup tinggi. Meskipun teknologi safety system dari Nuklir sudah maju pesat. Mungkin ada 2 hal yang bisa mengakibatkan fatal dari system ini :
1. Biaya pembangunan dikorupsi, sehingga untuk membangun malah kurang, sehingga cuman dibangun fasilitar nuklir alakadarnya, yang mungkin insecure.
2. Pelaksana Operasi ( Daily Operation - Day to day ) kurang disiplin, males belajar, ngantukan, meremehkan sinyal2 sederhana, banyak guyon , bahkan mungkin yang mustinya Reaktor nuklir malah jadi tempat mesum.
Solusinya :
1. Korupsi ya korupsi lah, tapi masalah safety jangan sampai dikorbankan, jadi sebaiknya jangan memotong anggaran tetapi lebih ke Mark Up saja.
2. Disiplin ... nah ini. Please deh.
SAYA SANGAT BERHARAP BAHWA PELAKSANA DISINI SEDAPAT MUNGKIN DARI MILITER, APAPUN ALASANNYA, SEHINGGA PUNYA DISIPLIN TINGGI, JANGAN DARI CIVIL EH SIPIL.
SEKALI LAGI :
PLEASE, BAPAK-BAPAK KALO BISA PELAKSANANYA DARI TENTARA SAJA YANG SUDAH TERBUKTI DISIPLIN TINGGI, SEDANGKAN YANG SIPIL CUKUP ILMUWANNYA.
Wednesday, February 28, 2007
Tuesday, February 20, 2007
Definisi Programmers
“Apapun bahasanya, minumnya teh botol sosro.”
*Khusus Mas Koen, minumnya kopi :-D
Someone said:
“Programmers are lazy people that try to makes everthing automatically. But ironically, they trapped with their codes. The time spended to analyze and check out the codes even more than do it manually…”
On programmer’s dictionary:
Loop /adjv = see RECURSIVE
------------------
From : spagiari
2007-01-08 15:34:35
*Khusus Mas Koen, minumnya kopi :-D
Someone said:
“Programmers are lazy people that try to makes everthing automatically. But ironically, they trapped with their codes. The time spended to analyze and check out the codes even more than do it manually…”
On programmer’s dictionary:
Loop /adjv = see RECURSIVE
------------------
From : spagiari
2007-01-08 15:34:35
Monday, February 19, 2007
Optimization is your enemy
Optimization is your enemy
Some many years ago, as I indicated in the introduction, I worked on a large (16-processor) multiprocessor system. We were using custom-modified PDP-11 minicomputers, which were relatively slow. We were programming them in Bliss-11, which as far as I've been able to tell still holds the record for the world's tightest optimizing compiler (although I've seen some quite impressive optimizations in Microsoft C/C++). After doing some performance measurement, we determined that the paging algorithm was the outstanding performance bottleneck. So our first assumption was that the paging algorithm was faulty. We examined the code, and the paging algorithm maintainer rewrote it, taking our performance data into account, and had a new, and much faster, page management algorithm installed within a week.
Meanwhile, up at MIT, MULTICS was still running. They traced a serious performance problem to the paging system. Because it was written in a PL/1 like language, EPL, the assumption was that because it was written in a high-level language, the code was suboptimal, so they launched an effort to rewrite the page management algorithm in assembly code. A year later, the code was working, and was put into the production system. Performance dropped 5%. Upon inspection, it was found that the fundamental algorithm was at fault. They took the EPL code, rewrote the algorithm, and had the improved algorithm working and installed in a few weeks. The lesson: don't optimize something that is not the problem. Understand the problem first. Then, and only then, do the optimization. Otherwise, the optimization is a waste of time and may even make the performance worse.
In the Bliss compiler, the 'register' attribute on a variable said to the compiler "You will assign this variable to a register". In C, it means "I'd like you to assign this variable to a register". Many programmers decided that they should put certain variables in registers to get better code. But the Bliss compiler was very good; it had a very sophisticated register allocation system, and in the absence of direction from the programmer felt free to assign a variable to a register if that produced the best code. Explicitly assigning a variable to a register meant that the register was not available for common subexpressions, particularly those subexpressions implicit in data structure access. After a fair amount of experiments, we determined that almost invariably adding 'register' attributes to declarations produced significantly worse code than letting the compiler do the assignment. For inner-loop code, many hours of effort would usually result in a small improvement in performance, but it was generally understood by the programmers that unless you studied the generated machine code and did a number of calibrated experiments, any attempts at optimization would make the code worse.
If you've heard of the SPECmark performance, you may also be aware of how they are gamed. In particular, IBM wrote a program that took a FORTRAN program as input, such as the SPEC matrix-multiply benchmark, and produced another FORTRAN program as output, but one which was optimized for the cache architecture of the machine it would run on. A small number of parameters described all the cache strategies of each of the models of the RISC 6000 product line. The "optimized" original FORTRAN program performed on one machine at 45 SPECmarks. After being transformed, it performed on the same machine at over 900 SPECmarks. That's a factor of 20 performance improvement based solely on fourth-order effects, cache line hits. If you're doing image processing, particularly of large images, an awareness of cache issues (even relatively machine-independent) can buy you an order of magnitude performance.
A naive approach, optimizing at the code-line level, is not nearly as effective as higher-order optimizations. Paging optimizations, cache line optimizations, and memory allocation optimizations can often have vastly more significant effects than code-line optimization. Algorithmic optimizations are the next best bet, particularly if your problem is not amenable to paging/cache optimizations. Only after all these have been done, and, of course, you have measured everything in sight, does it make sense to start doing line-level optimizations. And if your problem domain demands it, it can even make sense to recode the inner loops, particularly of such algorithms as convolution algorithms and DSP algorithms, in assembly code, most often to take advantage of the instructions such as for MMX and streaming media.
Perhaps the best example of pure programmer stupidity in "optimizing" code occurred when I was porting a large library we used for our research project. Think of it as a 16-bit-to-32-bit port (it was an 18-bit-to-36-bit port, and the language wasn't C, but the details don't matter--you can write ghastly code in any language, and I've seen C programmers do things just as badly). The port mostly worked, but we had a really strange problem that showed up only under some rare conditions, but which crashed the program using the library. I started looking. The heap was damaged. When I found how the heap was being damaged, it was being damaged via a bad pointer which allowed a store into a random place in the heap. OK, how did that pointer get bad? Four levels of storage damage down, and after 12 solid hours of debugging, I found the real culprit. By why did it fail? Another 5 hours, and I found that the programmer who wrote the constructor code for the data structure had a struct-equivalent something like {char * p1; char * p2;} where the pointers had been 16-bit, and we now used 32-bit pointers. In looking at the initialization code, instead of seeing something like something->p1 = NULL; something->p2= NULL;, I found the moral equivalent of (*(DWORD*)&something.p1) = 0! When I confronted the programmer, he justified it by explaining that he was now able to zero out two pointers with only a single doubleword store instruction (it wasn't an x86 computer, but a mainframe), and wasn't that a clever optimization? Of course, when the pointers became 32-bit pointers, this optimization only zeroed one of the two pointers, leaving the other either NULL (most of the time), or, occasionally, pointing into the heap in an eventually destructive manner. I pointed out that this optimization happened once, at object creation time; the average application that used our library created perhaps six of these objects, and that according to the CPU data of the day before I'd spent not only 17 hours of my time but 6 hours of CPU time, and that if we fixed the bug and ran the formerly-failing program continuously, starting it up instantly after it finished, for fourteen years, the time saved by his clever hack would just about break even with the CPU time required to find and fix this piece of gratuitous nonsense. Several years later he was still doing tricks like this; some people never learn.
-----------------------
Optimization: Your Worst Enemy
By Joseph M. Newcomer.
Some many years ago, as I indicated in the introduction, I worked on a large (16-processor) multiprocessor system. We were using custom-modified PDP-11 minicomputers, which were relatively slow. We were programming them in Bliss-11, which as far as I've been able to tell still holds the record for the world's tightest optimizing compiler (although I've seen some quite impressive optimizations in Microsoft C/C++). After doing some performance measurement, we determined that the paging algorithm was the outstanding performance bottleneck. So our first assumption was that the paging algorithm was faulty. We examined the code, and the paging algorithm maintainer rewrote it, taking our performance data into account, and had a new, and much faster, page management algorithm installed within a week.
Meanwhile, up at MIT, MULTICS was still running. They traced a serious performance problem to the paging system. Because it was written in a PL/1 like language, EPL, the assumption was that because it was written in a high-level language, the code was suboptimal, so they launched an effort to rewrite the page management algorithm in assembly code. A year later, the code was working, and was put into the production system. Performance dropped 5%. Upon inspection, it was found that the fundamental algorithm was at fault. They took the EPL code, rewrote the algorithm, and had the improved algorithm working and installed in a few weeks. The lesson: don't optimize something that is not the problem. Understand the problem first. Then, and only then, do the optimization. Otherwise, the optimization is a waste of time and may even make the performance worse.
In the Bliss compiler, the 'register' attribute on a variable said to the compiler "You will assign this variable to a register". In C, it means "I'd like you to assign this variable to a register". Many programmers decided that they should put certain variables in registers to get better code. But the Bliss compiler was very good; it had a very sophisticated register allocation system, and in the absence of direction from the programmer felt free to assign a variable to a register if that produced the best code. Explicitly assigning a variable to a register meant that the register was not available for common subexpressions, particularly those subexpressions implicit in data structure access. After a fair amount of experiments, we determined that almost invariably adding 'register' attributes to declarations produced significantly worse code than letting the compiler do the assignment. For inner-loop code, many hours of effort would usually result in a small improvement in performance, but it was generally understood by the programmers that unless you studied the generated machine code and did a number of calibrated experiments, any attempts at optimization would make the code worse.
If you've heard of the SPECmark performance, you may also be aware of how they are gamed. In particular, IBM wrote a program that took a FORTRAN program as input, such as the SPEC matrix-multiply benchmark, and produced another FORTRAN program as output, but one which was optimized for the cache architecture of the machine it would run on. A small number of parameters described all the cache strategies of each of the models of the RISC 6000 product line. The "optimized" original FORTRAN program performed on one machine at 45 SPECmarks. After being transformed, it performed on the same machine at over 900 SPECmarks. That's a factor of 20 performance improvement based solely on fourth-order effects, cache line hits. If you're doing image processing, particularly of large images, an awareness of cache issues (even relatively machine-independent) can buy you an order of magnitude performance.
A naive approach, optimizing at the code-line level, is not nearly as effective as higher-order optimizations. Paging optimizations, cache line optimizations, and memory allocation optimizations can often have vastly more significant effects than code-line optimization. Algorithmic optimizations are the next best bet, particularly if your problem is not amenable to paging/cache optimizations. Only after all these have been done, and, of course, you have measured everything in sight, does it make sense to start doing line-level optimizations. And if your problem domain demands it, it can even make sense to recode the inner loops, particularly of such algorithms as convolution algorithms and DSP algorithms, in assembly code, most often to take advantage of the instructions such as for MMX and streaming media.
Perhaps the best example of pure programmer stupidity in "optimizing" code occurred when I was porting a large library we used for our research project. Think of it as a 16-bit-to-32-bit port (it was an 18-bit-to-36-bit port, and the language wasn't C, but the details don't matter--you can write ghastly code in any language, and I've seen C programmers do things just as badly). The port mostly worked, but we had a really strange problem that showed up only under some rare conditions, but which crashed the program using the library. I started looking. The heap was damaged. When I found how the heap was being damaged, it was being damaged via a bad pointer which allowed a store into a random place in the heap. OK, how did that pointer get bad? Four levels of storage damage down, and after 12 solid hours of debugging, I found the real culprit. By why did it fail? Another 5 hours, and I found that the programmer who wrote the constructor code for the data structure had a struct-equivalent something like {char * p1; char * p2;} where the pointers had been 16-bit, and we now used 32-bit pointers. In looking at the initialization code, instead of seeing something like something->p1 = NULL; something->p2= NULL;, I found the moral equivalent of (*(DWORD*)&something.p1) = 0! When I confronted the programmer, he justified it by explaining that he was now able to zero out two pointers with only a single doubleword store instruction (it wasn't an x86 computer, but a mainframe), and wasn't that a clever optimization? Of course, when the pointers became 32-bit pointers, this optimization only zeroed one of the two pointers, leaving the other either NULL (most of the time), or, occasionally, pointing into the heap in an eventually destructive manner. I pointed out that this optimization happened once, at object creation time; the average application that used our library created perhaps six of these objects, and that according to the CPU data of the day before I'd spent not only 17 hours of my time but 6 hours of CPU time, and that if we fixed the bug and ran the formerly-failing program continuously, starting it up instantly after it finished, for fourteen years, the time saved by his clever hack would just about break even with the CPU time required to find and fix this piece of gratuitous nonsense. Several years later he was still doing tricks like this; some people never learn.
-----------------------
Optimization: Your Worst Enemy
By Joseph M. Newcomer.
Thursday, February 15, 2007
Kelapa Hijau untuk atasi Demam Berdarah
Dari: Budi Prakoso
Tanggal: 2007 Feb 15 11:10
Judul: [tangandiatas] OOT: Kelapa Hijau untuk atasi Demam Berdarah
---------------------------------------------------------------------
YTh. Rekan2 milist,
Meningat sekarang sedang Demam Berdarah, berikut saya infokan sharing pengalaman salah seorang rekan milis dalam mengatasi Demam Berdarah , berikut sharingnya :
From: "Dana Yudha"
Mungkin info ini kalo benar bisa berguna.
Mumupung lagi rame2nya masalah DEMAM BERDARAH pada kesempatan ini kalau boleh berbagi /sharing pengalaman pribadi..saya terserang demam berdarah dan sdh stadium akhir...lalu masuk rumah sakit Islam menghabiskan infus 22 botol...waktu itu sdh parah trombosit sdh mencapai 24.000 dan sdh mengalami halusinasi...jangankan makan minum aqua pun mual...dicoba dgn juice jambu klutuk dan pocari swet masih pelan kenaikan trombosit...lalu saya diberi Air Kelapa hijau yg kalau dikupas serabutnya berwarna
merah...saya bisa minum itu kelapa sampai 2 butir...hasilnya menakjubkan trombosit naik dgn amat cepat dan setelah itu pihak rumah sakit juga menanyakan minum apa dan besoknya bisa pulang kerumah...nah ini pengalaman pribadi saya sbg penderita DBD demam berdarah...mungkin ada saudara2 ku yg baca di millis ini andaikata ada tetangga atau kerabat yg menderita DBD bisa diberi air kelapa hijau obat dari alam yg diberikan
oleh TUHAN...Amin
(sumber :http://sehatherbal.blogspot.com - informasi kesehatan dan herbal)
NB: Adik saya juga pernah kena DBD, trombositnya sdh 50ribu, tetapi setelah minum air kelapa hijau kl. setengah botol aqua 500ml trombositnya naik secara bertahap hingga 150ribu.
Sekian, info ini semoga bermanfaat. Dan bila berkenan informasi ini agar disampaikan pula kepada rekan2, keluarga maupun tetangga yg mengalami DBD.
Wasalam,
BP
Tanggal: 2007 Feb 15 11:10
Judul: [tangandiatas] OOT: Kelapa Hijau untuk atasi Demam Berdarah
---------------------------------------------------------------------
YTh. Rekan2 milist,
Meningat sekarang sedang Demam Berdarah, berikut saya infokan sharing pengalaman salah seorang rekan milis dalam mengatasi Demam Berdarah , berikut sharingnya :
From: "Dana Yudha"
Mungkin info ini kalo benar bisa berguna.
Mumupung lagi rame2nya masalah DEMAM BERDARAH pada kesempatan ini kalau boleh berbagi /sharing pengalaman pribadi..saya terserang demam berdarah dan sdh stadium akhir...lalu masuk rumah sakit Islam menghabiskan infus 22 botol...waktu itu sdh parah trombosit sdh mencapai 24.000 dan sdh mengalami halusinasi...jangankan makan minum aqua pun mual...dicoba dgn juice jambu klutuk dan pocari swet masih pelan kenaikan trombosit...lalu saya diberi Air Kelapa hijau yg kalau dikupas serabutnya berwarna
merah...saya bisa minum itu kelapa sampai 2 butir...hasilnya menakjubkan trombosit naik dgn amat cepat dan setelah itu pihak rumah sakit juga menanyakan minum apa dan besoknya bisa pulang kerumah...nah ini pengalaman pribadi saya sbg penderita DBD demam berdarah...mungkin ada saudara2 ku yg baca di millis ini andaikata ada tetangga atau kerabat yg menderita DBD bisa diberi air kelapa hijau obat dari alam yg diberikan
oleh TUHAN...Amin
(sumber :http://sehatherbal.blogspot.com - informasi kesehatan dan herbal)
NB: Adik saya juga pernah kena DBD, trombositnya sdh 50ribu, tetapi setelah minum air kelapa hijau kl. setengah botol aqua 500ml trombositnya naik secara bertahap hingga 150ribu.
Sekian, info ini semoga bermanfaat. Dan bila berkenan informasi ini agar disampaikan pula kepada rekan2, keluarga maupun tetangga yg mengalami DBD.
Wasalam,
BP
Tuesday, February 13, 2007
Film India VS Film Kung Fu
From: olsa Muskita
Date: Sun, 28 Jan 2007 22:16:46 -0800 (PST)
Subject: [g3neration_n3xt] Film India VS Film Kung Fu
--------------------------
Hal-hal yang Ada di Film India Dan Tidak akan Kita temukan sehari-Hari:
1. Seorang pria tidak akan merasa sakit saat melakukan perkelahian sengit namun akan mengaduh sakit saat seorang wanita berusaha membersihkan lukanya.
2. Tokoh jagoannya tak pernah jatuh cinta pada jagoan wanita kecuali sebelumnya mereka menari-nari di bawah hujan.
3. Sekali dipakai make-upnya tidak pernah luntur, saat hujan ataupun saat lainnya.
4. Dua orang kekasih bisa menari-nari ditengah lapang Dan entah dari mana 100 orang lainnya
Akan muncul dari antah berantah Dan Bergabung Menari bersama mereka.(penari latar Michael Jackson aja kalah banyak)
5. Pada babak akhir, sang jagoan akan Menemukan bahwa is tokoh jahat yang Dilawannya Sebenarnya adalah saudara kandungnya, Wanita Tua yang mencarinya adalah ibunya Dan kepala Inspektur adalah ayahnya serta sang hakim Adalah Pamannya Dan seterusnya.
6. Kata-kata Inggris yang biasanya muncul Adalah (biasanya diucapkan keras2 di antara Kalimat) No Problem!, My God!, Get Out!, Shut-up!, Impossible!, Please forgive me!
7. Mereka berguling-guling Dan berputar2 Sambil bernyanyi Dan muncul lagi dengan Pakaian Berbeda.
8. Mereka bisa berlari mengelilingi pohon Kelapa, bernyanyi, saling memandang Dan Memalingkan muka menggoda Dan berganti Pakaian pada waktu yang sama tanpa menarik Nafas....
9. Jagoan gak boleh liat pohon Dan tiang Listrik, pasti joget dulu muter2 Dan tiba2 Wanitanya Muncul, gak heran film India minimal pasti 3 jam Bisa lebih gak rugi sih.
10. Airmata sang jagoan Dan is wanita Gampang mengucur bak keran air, tapi cepat Juga Kering Dan langsung joget mbok, BRAVO...
=======================================================================
Hal-hal yang Ada di Film Kungfu China Dan tidak Akan Kita temukan sehari-Hari
1. Menjadi orangtua sang jagoan selalu Bernasib sial Dan biasanya selalu dibunuh oleh Musuh saat is jagoan masih muda, Dan is Jagoan Akan jadi yatim piatu trus belajar ilmu silat Dan Balas dendam dstnya
2. Ketika seseorang terluka berat Dan sekarat, IA selalu berhasil bertahan hidup Dan Mengucapkan beberapa kalimat untuk Mengungkapkan is pembunuh Sebelum kepalanya terkulai Dan menyatakan
Dirinya telah benar2 mati.
3. Orang-orang yang mahir kungfu mampu Terbang ke atas atap, ke atas pohon Dan Menempuh jarak jauh tanpa berkeringat. Namun saat berjalan ke kota Dan desa-desa Mereka tetap harus berjalan kaki atau
Menunggang kuda.
4. Sang jagoan tak perlu bekerja untukMendapatkan uang, namun selalu memiliki Uang Emas Dan perak untuk membayar makanan Mereka.(minta jatah preman kali ye....)
5. Sang jagoan Dan sang penjahat akan saling Bertemu walaupun Negara mereka sangat luas Dan tak peduli dimanapun mereka berada.(padahal Belon Ada HP)
6. Menyembuhkan luka dalam di tubuh cukup Dengan duduk bersilang kaki, telapak tangan di Lutut Dan ASAP keluar dari kepala.
7. Mereka bisa menyimpan banyak barang di Baju lengan panjang mereka Dan tak pernah menjatuhkannya. Terutama sedemikian banyak Logam2 emas....Dan botol2 obat penyembuh Berbagai racun
8. Jagoan pasti jago minum arak, apalagi Sedang kesel / marah, sekali minum bisa Berdrum2 (5-10 drum) kayak jacky Chan Pendekar Mabuk.
9. Sebelum mati, sang guru bisa mentransfer Tenaga dalam ke muridnya hanya dengan Menempelkan telapak tangan ke pundak is Murid Begitu gampang Dan cepat bahkan Mengalahkan Kecepatan USB cable, infra red Dan bluetooth Jaman sekarang
10. Hebatnya kalo wanita mengenakan kostum Pria, Dan suaranya suara wanita, namun Orang2 Bahkan pendekar2 pria tidak sadar bahwa ituSeorang wanita, harus melalui proses tak Sengaja Menyentuh dada is wanita baru pendekarnya Sadar. (alamak pendekar centil ye...)
love en peace
cikabela
Date: Sun, 28 Jan 2007 22:16:46 -0800 (PST)
Subject: [g3neration_n3xt] Film India VS Film Kung Fu
--------------------------
Hal-hal yang Ada di Film India Dan Tidak akan Kita temukan sehari-Hari:
1. Seorang pria tidak akan merasa sakit saat melakukan perkelahian sengit namun akan mengaduh sakit saat seorang wanita berusaha membersihkan lukanya.
2. Tokoh jagoannya tak pernah jatuh cinta pada jagoan wanita kecuali sebelumnya mereka menari-nari di bawah hujan.
3. Sekali dipakai make-upnya tidak pernah luntur, saat hujan ataupun saat lainnya.
4. Dua orang kekasih bisa menari-nari ditengah lapang Dan entah dari mana 100 orang lainnya
Akan muncul dari antah berantah Dan Bergabung Menari bersama mereka.(penari latar Michael Jackson aja kalah banyak)
5. Pada babak akhir, sang jagoan akan Menemukan bahwa is tokoh jahat yang Dilawannya Sebenarnya adalah saudara kandungnya, Wanita Tua yang mencarinya adalah ibunya Dan kepala Inspektur adalah ayahnya serta sang hakim Adalah Pamannya Dan seterusnya.
6. Kata-kata Inggris yang biasanya muncul Adalah (biasanya diucapkan keras2 di antara Kalimat) No Problem!, My God!, Get Out!, Shut-up!, Impossible!, Please forgive me!
7. Mereka berguling-guling Dan berputar2 Sambil bernyanyi Dan muncul lagi dengan Pakaian Berbeda.
8. Mereka bisa berlari mengelilingi pohon Kelapa, bernyanyi, saling memandang Dan Memalingkan muka menggoda Dan berganti Pakaian pada waktu yang sama tanpa menarik Nafas....
9. Jagoan gak boleh liat pohon Dan tiang Listrik, pasti joget dulu muter2 Dan tiba2 Wanitanya Muncul, gak heran film India minimal pasti 3 jam Bisa lebih gak rugi sih.
10. Airmata sang jagoan Dan is wanita Gampang mengucur bak keran air, tapi cepat Juga Kering Dan langsung joget mbok, BRAVO...
=======================================================================
Hal-hal yang Ada di Film Kungfu China Dan tidak Akan Kita temukan sehari-Hari
1. Menjadi orangtua sang jagoan selalu Bernasib sial Dan biasanya selalu dibunuh oleh Musuh saat is jagoan masih muda, Dan is Jagoan Akan jadi yatim piatu trus belajar ilmu silat Dan Balas dendam dstnya
2. Ketika seseorang terluka berat Dan sekarat, IA selalu berhasil bertahan hidup Dan Mengucapkan beberapa kalimat untuk Mengungkapkan is pembunuh Sebelum kepalanya terkulai Dan menyatakan
Dirinya telah benar2 mati.
3. Orang-orang yang mahir kungfu mampu Terbang ke atas atap, ke atas pohon Dan Menempuh jarak jauh tanpa berkeringat. Namun saat berjalan ke kota Dan desa-desa Mereka tetap harus berjalan kaki atau
Menunggang kuda.
4. Sang jagoan tak perlu bekerja untukMendapatkan uang, namun selalu memiliki Uang Emas Dan perak untuk membayar makanan Mereka.(minta jatah preman kali ye....)
5. Sang jagoan Dan sang penjahat akan saling Bertemu walaupun Negara mereka sangat luas Dan tak peduli dimanapun mereka berada.(padahal Belon Ada HP)
6. Menyembuhkan luka dalam di tubuh cukup Dengan duduk bersilang kaki, telapak tangan di Lutut Dan ASAP keluar dari kepala.
7. Mereka bisa menyimpan banyak barang di Baju lengan panjang mereka Dan tak pernah menjatuhkannya. Terutama sedemikian banyak Logam2 emas....Dan botol2 obat penyembuh Berbagai racun
8. Jagoan pasti jago minum arak, apalagi Sedang kesel / marah, sekali minum bisa Berdrum2 (5-10 drum) kayak jacky Chan Pendekar Mabuk.
9. Sebelum mati, sang guru bisa mentransfer Tenaga dalam ke muridnya hanya dengan Menempelkan telapak tangan ke pundak is Murid Begitu gampang Dan cepat bahkan Mengalahkan Kecepatan USB cable, infra red Dan bluetooth Jaman sekarang
10. Hebatnya kalo wanita mengenakan kostum Pria, Dan suaranya suara wanita, namun Orang2 Bahkan pendekar2 pria tidak sadar bahwa ituSeorang wanita, harus melalui proses tak Sengaja Menyentuh dada is wanita baru pendekarnya Sadar. (alamak pendekar centil ye...)
love en peace
cikabela
Monday, February 12, 2007
IPB Tawarkan LRB Solusi Atasi Banjir
[BOGOR] Pembuatan lubang resapan biopore (LRB) disarankan untuk dibuat di kawasan yang permukaan tanahnya sudah kedap air. Fungsi lubang itu bisa menjadi resapan air,
sehingga ketika hujan, air tidak langsung menggelontor ke selokan dan kali atau sungai, tapi ada yang terserap ke dalam tanah. Lubang resapan biopore itu, menurut Kamir R Brata, pakar dari Institut Penelitian Bogor (IPB), sudah bisa diterapkan setelah diuji coba di sejumlah kawasan oleh para peneliti IPB. Menurut dia, LBR berteknologi sederhana dan biayanya murah. "Banyaknya lahan dan bangunan yang kedap air, menyebabkan air hujan yang turun tidak terserap tanah hingga terjadi penggelontoran air dari hulu ke hilir dan berdampak banjir. Untuk itu diperlukan
solusi dengan teknologi tepat guna, sederhana dan biaya murah serta bisa
dilakukan oleh siapa saja," ujar Kamir di kediamannya di Desa Cibanteng,
Kecamatan Dramaga, Bogor, Kamis (8/2). Bagaimana cara membuat
teknologi LRB untuk atasi banjir itu? Kamir menjelaskan, dengan cara
membuat lubang dengan kedalaman 80 centimeter (cm) dan diameter lubang
sekitar 10 cm. Langkah selanjutnya memasukan sampah lapuk sebanyak 2
sampai 3 kilogram (bergantung jenis sampah) ke dalam lubang atau sumur
itu. "Sampah-sampah ini kemudian diurai oleh organisme pengurai sehingga
terbentuk pori-pori," jelas staf Departemen Ilmu Tanah dan Sumber Daya
Lahan Fakultas Pertanian IPB ini. Dengan cara demikian, lanjutnya, air
hujan yang turun tidak membentuk aliran permukaan melainkan meresap ke
dalam tanah melalui pori-pori. Namun tidak perlu khawatir tanah akan
menjadi lunak karena air yang terserap justru akan tersimpan menjadi
cadangan air bawah tanah. Namun dalam pembuatan teknologi LRB ini
disarankan agar kedalaman lubang yang dibuat kurang dari satu meter. Sebab
apabila lebih dari satu meter, cacing-cacing dan organisme pengurai
lainnya akan mengalami kekurangan oksigen sehingga tidak dapat bekerja
dengan baik. Selain mempraktikan proses pembuatan lubang, Kamir
sempat menunjukkan juga penerapan LRB di lahan percobaan Cikabayan pada
areal Kampus IPB Dramaga Bogor. Di lokasi itu, saluran pembuangan di lahan
tertutup semen dilubangi dengan jarak antar lubang yakni satu meter.
"Teknologi sederhana LRB ini sangat tepat diterapkan pada pemukiman warga
yang umumnya di areal rumah mereka kedap air karena permukaan tanah
tertutup semen," ujarnya. Bencana banjir yang melanda Jabodetabek, baru-
baru ini, pun membuat IPB turut prihatin terhadap bencana alam banjir
itu. Sebenarnya, bencana seperti ini tidak perlu terjadi apabila kita
dapat mengantisipasi sebelumnya. "Bencana dapat diminimalisasikan
secara terintegrasi bersama dan berkeseimbangan, hal ini dapat dijadikan
sebagai bentuk kepedulian kita bersama," kata Kepala Kantor Prohumasi IPB,
drh. R.P. Agus Lelana, SpMP, M.Si secara terpisah. Banyak Masalah
Sementara itu, Staf Pengajar Departemen Silvikultur,
Fakultas Kehutanan - IPB, Dr Supriyanto, yang juga Ketua Gerakan
Penghijauan Peduli Banjir Jakarta dan Sekitarnya (GPPBJS), menegaskan,
permasalahan yang dialami Jabodetabek karena beberapa faktor antara lain,
wilayah itu menjadi Kota Megapolitan, kepadatan penduduk akibat
urbanisasi, polusi baik industri dan kendaraan serta banjir tahunan dari Sungai
Ciliwung dan Sungai Cisadane. Banjir merupakan salah satu masalah
yang sering dialami DKI Jakarta. "Penyebab banjir Jakarta di antaranya
karena curah hujan yang tinggi, adanya lahan kritis dan vegetasi kurang,
resapan air menurun, waduk, situ dan saluran irigasi tidak berfungsi
dengan baik," ungkap Supriyanto. Menurut dia, dari data sebaran curah
hujan di Jabodetabek, curah hujan tertinggi sekitar 3.000-3.500 milimeter
per tahun terjadi di Bogor, dan terendah terjadi di DKI Jakarta dengan
angka 1.700 milimeter per tahun. Untuk Tangerang, Bekasi dan Depok
sekitar 2000-3000 milimeter per tahun. Ditambah lagi kegiatan
pembangunan di DAS Ciliwung yang cenderung mengarah pada penurunan
daya dukung lingkungan berupa penurunan kemampuan lahan dalam meresapkan
air dan peningkatan laju erosi. Kondisi ini menyebabkan tingginya
limpasan air permukaan yang berakibat timbulnya banjir tahunan di DKI
Jakarta. "Oleh karenanya perlu transfer cost (kompensasi) dari daerah hilir
ke hulu. Kompensasi ini, terangnya, sangat diperlukan dalam penanganan
Daerah Aliran Sungai (DAS) Ciliwung dan Cisadane," ujarnya. Luas
lahan kritis sampai dengan tahun 2004 di DAS Ciliwung telah mencapai
sekitar 5.400 hektar, yang tersebar di Kabupaten Bogor sekitar 4.600 hektar,
Kota Bogor sekitar 70 hektar dan Kota Depok sekitar 730 hektar. "Lahan
kritis tersebut perlu dibangun kembali dengan menaman jenis-jenis yang
produktif dan disukai oleh masyarakat. Dengan demikian, penanganan DAS
Ciliwung harus terpadu yang melibatkan dua propinsi, Jawa Barat dan DKI
Jakarta," imbuhnya. Sementara saat ini enam dari 20 situ yang
dimiliki DKI Jakarta telah rusak parah. Yaitu, Situ Rawa Dongkal,
Aneka Elok, Rawa Badung, Ria Rio, Kebon Melati, dan Pluit. Selain tercemar
sampah dan limbah, pendangkalan terjadi oleh tumbuhan air. Solusi
penanggulangan banjir, menurut dia, bukan hanya didasarkan pada civil
engineering tetapi harus didasarkan pula pada agricultural, fisheries dan
forestry engineering. "Salah satunya dengan peningkatan resapan air
melalui rehabilitasi hutan dan lahan (penghijauan)," tandasnya. GPPJS dan
IPB telah melakukan berbagai kegiatan seperti berbagai pelatihan,
pembibitan dan penghijauan sebanyak 284.700 batang ditanam pada lahan 177,75
hektar, pengembangan sumberdaya manusia untuk Green School total
peserta 603 orang, pembentukan kelompok tani. Kepedulian sivitas akademika
juga ditunjukkan Badan Ekskutif Mahasiswa Keluarga Mahasiswa (BEM KM)
IPB, ketika musibah melanda DKI Jakarta, mahasiswa mengumpulkan dana
sukarela dari masyarakat sekitar kampus. [126]
ttp://www.suarapembaruan.com/last/index.html
sehingga ketika hujan, air tidak langsung menggelontor ke selokan dan kali atau sungai, tapi ada yang terserap ke dalam tanah. Lubang resapan biopore itu, menurut Kamir R Brata, pakar dari Institut Penelitian Bogor (IPB), sudah bisa diterapkan setelah diuji coba di sejumlah kawasan oleh para peneliti IPB. Menurut dia, LBR berteknologi sederhana dan biayanya murah. "Banyaknya lahan dan bangunan yang kedap air, menyebabkan air hujan yang turun tidak terserap tanah hingga terjadi penggelontoran air dari hulu ke hilir dan berdampak banjir. Untuk itu diperlukan
solusi dengan teknologi tepat guna, sederhana dan biaya murah serta bisa
dilakukan oleh siapa saja," ujar Kamir di kediamannya di Desa Cibanteng,
Kecamatan Dramaga, Bogor, Kamis (8/2). Bagaimana cara membuat
teknologi LRB untuk atasi banjir itu? Kamir menjelaskan, dengan cara
membuat lubang dengan kedalaman 80 centimeter (cm) dan diameter lubang
sekitar 10 cm. Langkah selanjutnya memasukan sampah lapuk sebanyak 2
sampai 3 kilogram (bergantung jenis sampah) ke dalam lubang atau sumur
itu. "Sampah-sampah ini kemudian diurai oleh organisme pengurai sehingga
terbentuk pori-pori," jelas staf Departemen Ilmu Tanah dan Sumber Daya
Lahan Fakultas Pertanian IPB ini. Dengan cara demikian, lanjutnya, air
hujan yang turun tidak membentuk aliran permukaan melainkan meresap ke
dalam tanah melalui pori-pori. Namun tidak perlu khawatir tanah akan
menjadi lunak karena air yang terserap justru akan tersimpan menjadi
cadangan air bawah tanah. Namun dalam pembuatan teknologi LRB ini
disarankan agar kedalaman lubang yang dibuat kurang dari satu meter. Sebab
apabila lebih dari satu meter, cacing-cacing dan organisme pengurai
lainnya akan mengalami kekurangan oksigen sehingga tidak dapat bekerja
dengan baik. Selain mempraktikan proses pembuatan lubang, Kamir
sempat menunjukkan juga penerapan LRB di lahan percobaan Cikabayan pada
areal Kampus IPB Dramaga Bogor. Di lokasi itu, saluran pembuangan di lahan
tertutup semen dilubangi dengan jarak antar lubang yakni satu meter.
"Teknologi sederhana LRB ini sangat tepat diterapkan pada pemukiman warga
yang umumnya di areal rumah mereka kedap air karena permukaan tanah
tertutup semen," ujarnya. Bencana banjir yang melanda Jabodetabek, baru-
baru ini, pun membuat IPB turut prihatin terhadap bencana alam banjir
itu. Sebenarnya, bencana seperti ini tidak perlu terjadi apabila kita
dapat mengantisipasi sebelumnya. "Bencana dapat diminimalisasikan
secara terintegrasi bersama dan berkeseimbangan, hal ini dapat dijadikan
sebagai bentuk kepedulian kita bersama," kata Kepala Kantor Prohumasi IPB,
drh. R.P. Agus Lelana, SpMP, M.Si secara terpisah. Banyak Masalah
Sementara itu, Staf Pengajar Departemen Silvikultur,
Fakultas Kehutanan - IPB, Dr Supriyanto, yang juga Ketua Gerakan
Penghijauan Peduli Banjir Jakarta dan Sekitarnya (GPPBJS), menegaskan,
permasalahan yang dialami Jabodetabek karena beberapa faktor antara lain,
wilayah itu menjadi Kota Megapolitan, kepadatan penduduk akibat
urbanisasi, polusi baik industri dan kendaraan serta banjir tahunan dari Sungai
Ciliwung dan Sungai Cisadane. Banjir merupakan salah satu masalah
yang sering dialami DKI Jakarta. "Penyebab banjir Jakarta di antaranya
karena curah hujan yang tinggi, adanya lahan kritis dan vegetasi kurang,
resapan air menurun, waduk, situ dan saluran irigasi tidak berfungsi
dengan baik," ungkap Supriyanto. Menurut dia, dari data sebaran curah
hujan di Jabodetabek, curah hujan tertinggi sekitar 3.000-3.500 milimeter
per tahun terjadi di Bogor, dan terendah terjadi di DKI Jakarta dengan
angka 1.700 milimeter per tahun. Untuk Tangerang, Bekasi dan Depok
sekitar 2000-3000 milimeter per tahun. Ditambah lagi kegiatan
pembangunan di DAS Ciliwung yang cenderung mengarah pada penurunan
daya dukung lingkungan berupa penurunan kemampuan lahan dalam meresapkan
air dan peningkatan laju erosi. Kondisi ini menyebabkan tingginya
limpasan air permukaan yang berakibat timbulnya banjir tahunan di DKI
Jakarta. "Oleh karenanya perlu transfer cost (kompensasi) dari daerah hilir
ke hulu. Kompensasi ini, terangnya, sangat diperlukan dalam penanganan
Daerah Aliran Sungai (DAS) Ciliwung dan Cisadane," ujarnya. Luas
lahan kritis sampai dengan tahun 2004 di DAS Ciliwung telah mencapai
sekitar 5.400 hektar, yang tersebar di Kabupaten Bogor sekitar 4.600 hektar,
Kota Bogor sekitar 70 hektar dan Kota Depok sekitar 730 hektar. "Lahan
kritis tersebut perlu dibangun kembali dengan menaman jenis-jenis yang
produktif dan disukai oleh masyarakat. Dengan demikian, penanganan DAS
Ciliwung harus terpadu yang melibatkan dua propinsi, Jawa Barat dan DKI
Jakarta," imbuhnya. Sementara saat ini enam dari 20 situ yang
dimiliki DKI Jakarta telah rusak parah. Yaitu, Situ Rawa Dongkal,
Aneka Elok, Rawa Badung, Ria Rio, Kebon Melati, dan Pluit. Selain tercemar
sampah dan limbah, pendangkalan terjadi oleh tumbuhan air. Solusi
penanggulangan banjir, menurut dia, bukan hanya didasarkan pada civil
engineering tetapi harus didasarkan pula pada agricultural, fisheries dan
forestry engineering. "Salah satunya dengan peningkatan resapan air
melalui rehabilitasi hutan dan lahan (penghijauan)," tandasnya. GPPJS dan
IPB telah melakukan berbagai kegiatan seperti berbagai pelatihan,
pembibitan dan penghijauan sebanyak 284.700 batang ditanam pada lahan 177,75
hektar, pengembangan sumberdaya manusia untuk Green School total
peserta 603 orang, pembentukan kelompok tani. Kepedulian sivitas akademika
juga ditunjukkan Badan Ekskutif Mahasiswa Keluarga Mahasiswa (BEM KM)
IPB, ketika musibah melanda DKI Jakarta, mahasiswa mengumpulkan dana
sukarela dari masyarakat sekitar kampus. [126]
ttp://www.suarapembaruan.com/last/index.html
Wednesday, February 7, 2007
UGM-Sardjito Kembangkan deteksi dini kanker Nasopharynx
Yogyakarta, Kompas - Tim peneliti kanker Nasopharynx Universitas
Gadjah Mada Yogyakarta dan RS Sardjito Yogyakarta berhasil
mengembangkan metode diagnostik deteksi dini kanker Nasopharynx atau
Nasopharynx Cancer (NPC) dengan teknik yang lebih sederhana dan
biaya yang lebih murah. Tingkat spesifitas dan sensivitas deteksi
ini hingga mencapai 90,4 persen.
Ketua Tim Peneliti Fakultas Kedokteran UGM Prof Sofia Mubarika,
Senin (5/2) di UGM, mengemukakan, deteksi dini itu menggunakan
metode Elisa (Enzyme-Linked Immunosorbent Assay) dengan menggunakan
kombinasi dua antigen, yaitu VCA (Viral Capsid Antigen)-p18 dan EBNA
(Epstein Barr Nuclear Antigen 1), yang ditemukan pada orang yang
terinfeksi virus Epstein Barr Virus (EBV), penyebab NPC. "Dengan
kombinasi dua antigen tersebut, tingkat spesifitas dan sensitivitas
menjadi lebih tinggi, mencapai 84,6 persen dan 90,4 persen.
Penggunaan antigen tersebut terbukti lebih efisien dalam pengerjaan
dan biaya yang lebih murah hingga 40 persen dari biaya yang ada,"
katanya.
Teknik Elisa yang dilakukan dengan prinsip pengujian reaksi antara
antigen dan antibodi dipilih karena merupakan teknik yang relatif
sederhana dan hampir semua laboratorium kesehatan di setiap daerah
dapat mengerjakannya. "Kalau tes biasa yang sudah ada, biaya tes
bisa mencapai Rp 500.000, namun melalui metode ini bisa lebih murah
sepertiganya. Kita akan bekerja sama dengan industri untuk
mengembangkan lebih lanjut," ujar Sofia.
Diungkapkan, deteksi dini ini sangat diperlukan karena NPC yang
disebabkan virus EBV tersebut merupakan penyakit dengan tingkat
penderita tertinggi pada laki-laki dan nomor tiga tertinggi pada
wanita. EBV adalah virus DNA yang terbukti telah menginfeksi lebih
dari 95 persen populasi manusia di dunia. Meskipun tidak semua orang
yang terinfeksi EBV akan menderita NPC. (RWN)
http://www.kompas.co.id/kompas-cetak/0702/07/humaniora/3301075.htm
Gadjah Mada Yogyakarta dan RS Sardjito Yogyakarta berhasil
mengembangkan metode diagnostik deteksi dini kanker Nasopharynx atau
Nasopharynx Cancer (NPC) dengan teknik yang lebih sederhana dan
biaya yang lebih murah. Tingkat spesifitas dan sensivitas deteksi
ini hingga mencapai 90,4 persen.
Ketua Tim Peneliti Fakultas Kedokteran UGM Prof Sofia Mubarika,
Senin (5/2) di UGM, mengemukakan, deteksi dini itu menggunakan
metode Elisa (Enzyme-Linked Immunosorbent Assay) dengan menggunakan
kombinasi dua antigen, yaitu VCA (Viral Capsid Antigen)-p18 dan EBNA
(Epstein Barr Nuclear Antigen 1), yang ditemukan pada orang yang
terinfeksi virus Epstein Barr Virus (EBV), penyebab NPC. "Dengan
kombinasi dua antigen tersebut, tingkat spesifitas dan sensitivitas
menjadi lebih tinggi, mencapai 84,6 persen dan 90,4 persen.
Penggunaan antigen tersebut terbukti lebih efisien dalam pengerjaan
dan biaya yang lebih murah hingga 40 persen dari biaya yang ada,"
katanya.
Teknik Elisa yang dilakukan dengan prinsip pengujian reaksi antara
antigen dan antibodi dipilih karena merupakan teknik yang relatif
sederhana dan hampir semua laboratorium kesehatan di setiap daerah
dapat mengerjakannya. "Kalau tes biasa yang sudah ada, biaya tes
bisa mencapai Rp 500.000, namun melalui metode ini bisa lebih murah
sepertiganya. Kita akan bekerja sama dengan industri untuk
mengembangkan lebih lanjut," ujar Sofia.
Diungkapkan, deteksi dini ini sangat diperlukan karena NPC yang
disebabkan virus EBV tersebut merupakan penyakit dengan tingkat
penderita tertinggi pada laki-laki dan nomor tiga tertinggi pada
wanita. EBV adalah virus DNA yang terbukti telah menginfeksi lebih
dari 95 persen populasi manusia di dunia. Meskipun tidak semua orang
yang terinfeksi EBV akan menderita NPC. (RWN)
http://www.kompas.co.id/kompas-cetak/0702/07/humaniora/3301075.htm
Subscribe to:
Posts (Atom)