news...

SUN SEE'S A GRID FUTURE....

i read this article on of the local papers of singapore, which gave me a glimpse of Sun's vision for the future.

the concept of using thin clients running on utility grids will help companies save on energy costs. with a sun ray thin-client workstation, users can view "display over internet protocol" and use the utility gird for services.

And Sun's plans are to have the hosting done at singapore(which wud be the Hub) and have a backup or alternative at scotland....Damn neat!!.

This is what i totally agree with Scoot McNealy, " The real cost of any technology is not in acquiring it, but the cost of moving away from that technology when it becomes obsolete..". Rather than worrying about how much it costs to acquire technology, one should ask how much it costs to get away from it.


Kernel news:

with all the latest talking happening on the kernel side, one that interests me and which i have been a part of it for a few days now is regarding the current stack size in the Linux Kernel.

there have been debates and arguements where lots of hackers have been voting for varied stack size. But why change the stack size??. The need is not absolutely necessary. Some came up with a "play-safe" concept of giving the user the option to pick the stack size during the compilation time. This is a good option, but do we ..actually need to go do the changes cause every other operating system is doing it. currently there are talks about having 4k and 8k stacks.

But one has to test for the stablity("throughput" and "latency") in the kernel once these changes have been done. Adding these feature is just a few lines of code, but the changes in the environment of the kernel is what matters.

Anyway CONFIG_DEBUG_STACKOVERFLOW is not enabled in 2.6.14.4 i386 defconfig. Don't know about vendor kernel kernels though.

Solaris is moving towards having 16k stacks for their 64-bit os. wow wow!!

i was looking for a smarter way to achieve a way to restrict the size of the files being written by the kernel to a hardware device?
if(conf & 1) {
idev->smart = 1;
hwif->atapi_dma = 0;
/* Long I/O's although allowed in LBA48 space cause the
onboard firmware to enter the twighlight zone */
hwif->rqsize = 256;
}
i finally found it in the kernel itself....!!!