Say NO to OOXML

http://www.noooxml.org/

Sign the petition!

Rak 19 inci

1U = 1.75" = 44.45mm

Kapan Kita Perlu Memakai SNMP versi 2?

Kita biasa mengukur trafik sebuah interface dengan konfigurasi MRTG berikut:

Target[nama_target]nomor_interface:community@target:
MaxBytes[nama_target]: 1234567
dst ...

Pengukuran biasa dilakukan dengan selang waktu 5 menit. Apabila interface yang diukur adalah fast ethernet (100Mbps), maka selama 5 menit, data yang lewat maksimum sebesar ~3.5 giga bytes. Dengan sebuah pencacah (counter) 32 bit, yang mampu menyimpan nilai sampai dengan 2^32-1 (4.294.967.295), setiap 5 menit pencacah tersebut hanya mungkin overflow dua kali. MRTG mampu mengkoreksi overflow tunggal, sedangkan untuk kasus overflow ganda, kita hanya bisa berdoa semoga tidak terjadi :D.

Bagaimana kalau interface yang diukur bertipe ethernet gigabit? Data yang lewat bisa mencapai ~35 GB, dan pencacah 32 bit bisa mengalami overflow sampai dengan 9(?) kali. Dan anda akan memperoleh grafik trafik yang aneh: seolah-olah link gigabit anda masih lengang karena trafik jarang lebih dari 120 Mbps. Apa solusinya? Apabila sampling dipersering, misalnya setiap 30 detik, maka overflow antar sampel maksimum hanya sekali, akan tetapi anda tidak lagi dapat memanfaatkan cron untuk men-drive MRTG, karena resolusi cron minimum 1 menit. Kalaupun ada metoda alternatif cron yang memiliki resolusi 30 detik, boleh jadi trafik query SNMP nilainya menjadi signifikan, karena berlipat 10 dari sebelumnya.

Solusi yang lebih elegan adalah memakai SNMP versi 2. Ada OID bertipe Counter64 (ifHCInOctets dan ifHCOutOctets, menggantikan ifInOctets dan ifOutOctets yang bertipe Counter32) yang tidak bakal mudah overflow walaupun dipakai untuk mencacah data yang lewat pada interface gigabit. Konfigurasi MRTG yang memanfaatkan SNMPv2 hanya sedikit berbeda dari konfigurasi default:

Target[nama_target]nomor_interface:community@target:::::2

Three Steps To IPv6

Preparation Phase - Present to December 2008
  In the Preparation Phase, entities prepare to provide 
  Internet-facing services via IPv6-based connectivity
  while continuing to provide Internet-facing services
  via IPv4 connectivity.

Transition Phase - January 2009 to December 2010
  In the Transition Phase, entities provide Internet-facing services
  via IPv6-based connectivity in addition to IPv4-based connectivity.

Post-Transition Phase - January 2011 to the Future
  In the Post-Transition Phase, entities provide all Internet-facing 
  services via IPv6-based connectivity.

So, what are you waiting for?

ps: The draft I refered to was changed several days after I wrote this. New draft is v01 which add one year delay for first phase ending, compared to draft v00.

Asus EEE atau Medison Celebrity?

Belum genap sebulan posting Harry Sufehmi mengajak belanja laptop 200$ dari Asus (yang disambut dengan sangat antusias oleh lebih dari 800 orang), tiba-tiba muncul pesaing yang lebih menggiurkan: Medison Celebrity. Harganya hanya 150$, dengan spek yang sangat menarik.

                    Asus EEE Pc 701            Medison Celebrity
price               199                        150
processor           Intel Pentium M 900 Mhz    Intel Celeron M 1.5 Ghz
display size        7”                         14”
display resolution  ?                          1280 x 768
RAM                 512 MB DDR2-400            256 MB
RAM max             ?                          1 GB
storage             4 GB SSD                   40 GB PATA
video controller    Intel 910                  VIA PN800
NIC                 10/100 Mbps ethernet       10/100 Mbps ethernet
modem               56k                        -
wifi                802.11b                    802.11g
USB                 3x USB 2.0                 3x USB 2.0
PCMCIA              -                          1x Type II
camera              0.3 Mpixel                 -
audio               HDA, builtin speaker + mic AC'97 2.2, builtin speaker + mic
battery             5200 mAh 4 cell            4000 / 4400 mAh 6 cell
dimension           225×165×21~35 mm           333×243×24~33 mm
weight              890 g                      2200 g

Jadi, pilih mana?

Hati-hati, ada kemungkinan Medison Celebrity adalah scam

Berbalas Pantun Di Milis Kernel Linux

Rusty Russel menulis kode untuk lguest dengan gaya yang unik. Lguest adalah salah satu dari sekian banyak alternatif virtualization untuk Linux.

Patch yang dikirim Rusty Russel dikomentari oleh Andrew Morton:

But I worry that you're proposing adding what appears to be new Documentation-related machinery and infrastructure when there's already increased activity in that area from other people and we might all be headed in different directions and stuff.

So first I think we'd best form a kernel kommittee and mull this for a while (preferably months) to screw you around as much as poss, OK? ;)

yang ditimpali oleh Linus Torvalds:

On Tue, 24 Jul 2007, Rusty Russell wrote:
>
> Indeed, no code changes, and I feel strongly that it should go into
> 2.6.23 because it's *fun*. And (as often complained) there's not
> enough poetry in the kernel.

There's a reason for that.

There once was a lad from Braidwood
With a wife and a hatred for FUD
He hacked kernels for fun,
couldn't get them to run.
But he always felt that he should.

dan dibalas tanpa rasa takut:

There once was a virtualization coder,
Whose patches kept getting older,
Each time upstream would drop,
His documentation would slightly rot,
SO APPLY MY FUCKING PATCHES OR I'LL KEEP WRITING LIMERICKS.

Thanks!
Rusty.

Source Tree Kernel Linux x86 32-bit dan 64-bit Mulai Digabung

The topic of sharing more x86 code has been discussed on LKML a number of times. Various approaches were discussed and we decided to advance the discussion by implementing a full solution that brings the transition to a shared tree to completion.

Warning: our approach is quite a bit more extreme than what has been suggested before.

The core idea behind our project is simple to describe: we introduce a new arch/x86/ and include/asm-x86/ file hierarchy that includes all the existing 32-bit and 64-bit x86 code and allows the building of either a 32-bit (i386) kernel or a 64-bit (x86_64) kernel.

In this initial implementation the old arch/i386 and arch/x86_64 trees are removed _immediately_, in the same commit, and all future x86 development goes on in the new, shared tree. So the transition right now is one atomic operation.

As a next step we plan to generate a gradual, fully bisectable, fully working switchover from the current code to the fully populated arch/x86 tree. It will result in about 1000-2000 commits. We are releasing our current solution because it 100% represents the finally resulting arch/x86 source tree already, and we first wanted to make sure that the new architecture layout works fine and folks are happy before we go and do the (even more complex) fine-grained work.

A git tree is available from:

git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git

One (large!) combo patch is available at:

http://kernel.org/pub/linux/kernel/people/tglx/linux-x86.2.6.22-git-ede13d.combo.patch.bz2

the patch is against this upstream -git head:

commit ede13d81b4dda409a6d271b34b8e2ec9383e255d

It makes little sense to apply this patch to anything else because these architectures are such a fast-moving target....