dd if=/dev/random of=/dev/null bs=always

I am writing to announce the release of my Linux RAM disk kernel module. Yes, the Linux kernel has the brd module already integrated into it, and also the zram module it the staging tree. And yes, you can instead utilize ramfs or tmpfs for RAM based file systems. But RapidDisk or rxdsk is a bit different.

Unlike brd or zram all attached RAM disk are populated on-the-fly with any user defined size and not during the module’s insertion (i.e. typically system bootup) with a fixed size. When you attach a new RAM disk, you can define sizes as little as 16 Mbytes and in theory as large as 1 TByte and possibly above and it is designed to allocate new kernel pages as needed; so it won’t steal all memory when the RAM disk is created.

Unlike ramfs or tmpfs, an rxdsk volume can easily be exported as a physical device across a SAN or simply allocated as a SWAP space which would become more ideal when the LZO compression is completed and stabilized.

This type of technology could be used for quick I/O storage (configured as a DRAM-based SSD with enabled syncing to persistent storage) and mounted as a block device labeled with a traditional file system and functioning as a traditional storage device; Application and/or database caching; File system meta-data caching; Virtualization (when data compression is developed and/or while running another data deduplication solution on top of the RAM disk); and as mention above, a CompCache replacement for enabling compressed swap space into RAM (again, when compression is developed).

For more details, please do not hesitate to visit the project’s wiki page. Here you will find details on how to check the source code out from the git repo, build & install it, among other things including performance numbers (writing 1 GByte sizes in 3 seconds!!!) to community involvement. The kernel module is licensed under the GPLv2 while the management utility is licensed under the GPLv3.

Note - So far this has only been tested and seen as fully functional on the 2.6.32 and 2.6.35 kernels.

I am just writing to announce the official release of my SCSI Bus Analyzer Module (scsitrace) 1.0 Beta for the Linux 2.6 kernels. A patch has been released for the Linux 2.6.35.4 kerne

Every now and then, when surfing the blogosphere, I come across waves after waves of postings stating how “Linux needs to rely less on the CLI” or “Windows is perfect for basic users because everything can be done with the GUI”…blah, blah, blah. In fact it was this article that prompted this posting. It gets tiring reading the same things over and over again, but it hasn’t stopped me from adding my 2 cents.

First and foremost, I live by the command line and rarely do things from a graphical interface. Whether it be on a Linux-based operating system, UNIX or Windows, I always have one or two command line terminals open to make my life easier; so be warned that this posting may be a bit biased.

Second, I do not care what a Microsoft Windows user has to say. Even in a Windows operating system, there are those cases when things are accomplished a lot more efficiently on the command line. That is, dealing with network connections via ipconfig, managing storage devices via diskpart to even reconfiguring your power settings via powercfg and more. There are just some things that is much more easily accomplished from the command line in Windows than it is with their graphical interface.

This also includes automation via the traditional DOS-style batching or even with a higher level interpreter such as Python or Perl. When forced to use nothing but Windows in the corporate world, I would always have an installation of Cygwin on the system and prefer working out of that instead.

But a normal user will never have to deal with this in Windows and again that same user would never have to deal with it in Linux; but most of the people I have been hearing complain is the Windows IT administrator. They routinely ask: “Why should I have to open up the command line to do XYZ?” My first response to them has always been, “and you never opened up the command line to release/renew your IP settings with ipconfig?”

Let us stop playing games here and realize that the CLI is not what is hurting Linux’ advancement. The countless amount of graphical interfaces provide all of the general functionality that most basic users rely on. Do these same users use a CLI when configuring their routers, settings television programs to record on their DVRs, manage their applications on their Android products, etc.? Nope. Linux has already proven itself to be very useful without the CLI.

Now the question is, how do we move past these age-old stereotypes and move ahead? Is Google pioneering the way with the Android and what is the, soon to be available, Chrome OS? Is Canonical pioneering the way with Ubuntu? What can we do to defeat these stereotypes and bring Linux to the mainstream? Marketing (since none really exists outside of magazine and Internet advertisements)? I am just tired of reading the same complaints. The CLI is never going to disappear (even on Windows). The GUI is just going to get better but will always lack in the productivity and efficiency brought forth by the CLI. It is what it is, so let us now move on.