Linux tmpfs

Tmpfs was pioneered in Solaris is designed primarily as a performance enhancement to allow short lived files to be written and accessed without generating disk or network I/O. Tmpfs maximizes file manipulation speed while preserving UNIX file semantics. It does not require dedicated disk space for files and has no negative performance impact. The most brilliant idea, that was somewhat reminiscent of Multics,  was to use  virtual memory system facilities for file storage and access. Tmpfs files are written and accessed directly from the memory maintained by the kernel; they are not differentiated from other uses of physical memory. This means tmpfs file data can be ‘‘swapped’’ or paged to disk, freeing VM resources for other needs. General VM system routines are used to perform many low level tmpfs file system operations. This reduces the amount of code needed to maintain the file system, and ensures that tmpfs resource demands may coexist with other VM resource users with no adverse effects. As such it is more advanced then ramdisk, and more dynamic. tmpfs can use both RAM and swap file pushing inactive files to disk. It was invented in Solaris and reimplemented in linux is slightly different form.

Linux reimplementation of tmpfs is somewhat more flexible then Solaris. It coexists with older concept of ramdisk which was borrowed from MS DOS.  Ramdisk is a block device that requires a mkfs  command or similar command before you can use it. tmpfs is a filesystem, not a block device; you just mount it, and it is usable instantly. In this sense it is more like virtual folder then virtual filesystem. 

The most brilliant idea:  use VM to store files

tmpfs is also known as the "virtual memory filesystem".  Virtual memory consists of pages that reside in RAM and swap devices. The VM subsystem in the kernel allocates these resources  transparently moving RAM pages to swap and vice-versa depending of thier usage. This idea actually originated in Multics, which served as one of Unix prototypes. 

The tmpfs filesystem requests pages from the VM subsystem to store files. tmpfs itself doesn't know whether these pages are on swap or in RAM; it's the VM subsystem's job to make those kinds of decisions.

Not a block device

 tmpfs does not exist on top of an underlying block device. Because tmpfs sits on top of VM directly, you can create a tmpfs filesystem with a simple mount command:

# mount tmpfs /mnt/tmpfs -t tmpfs

After executing this command, you'll have a new tmpfs filesystem mounted at /mnt/tmpfs, ready for use. Note that there's no need to run mkfs.tmpfs; in fact, it's impossible, as no such command exists. Immediately after the mount  command, the filesystem is mounted and available for use, and is of type tmpfs. This is very different from how Linux ramdisks are used; standard Linux ramdisks are block devices, so they must be formatted with a filesystem of your choice before you can use them. In contrast, tmpfs is a filesystem. So, you can just mount it and go.

Tmpfs advantages

Dynamic filesystem size

You're probably wondering about how big that tmpfs filesystem was that we mounted at /mnt/tmpfs, above. The answer to that question is a bit unexpected, especially when compared to disk-based filesystems. /mnt/tmpfs will initially have a very small capacity, but as files are copied and created, the tmpfs filesystem driver will allocate more VM and will dynamically increase the filesystem capacity as needed. And, as files are removed from /mnt/tmpfs, the tmpfs filesystem driver will dynamically shrink the size of the filesystem and free VM resources, and by doing so return VM into circulation so that it can be used by other parts of the system as needed. Since VM is a precious resource, you don't want anything hogging more VM than it actually needs, and the great thing about tmpfs is that this all happens automatically.

Speed

The other major benefit of tmpfs is its blazing speed. Because a typical tmpfs filesystem will reside completely in RAM, reads and writes can be almost instantaneous. Even if some swap is used, performance is still excellent and those parts of the tmpfs filesystem will be moved to RAM as more free VM resources become available. Having the VM subsystem automatically move parts of the tmpfs filesystem to swap can actually be good for performance, since by doing so, the VM subsystem can free up RAM for processes that need it. This, along with its dynamic resizing abilities, allow for much better overall OS performance and flexibility than the alternative of using a traditional RAM disk.

No persistence

While this may not seem like a positive, tmpfs data is not preserved between reboots, because virtual memory is volatile in nature. I guess you probably figured that tmpfs was called "tmpfs" for a reason, didn't you? However, this can actually be a good thing. It makes tmpfs an excellent filesystem for holding data that you don't need to keep, such as temporary files (those found in /tmp) and parts of the /var filesystem tree.

Using tmpfs

To use tmpfs, all you need is a 2.4 series kernel with "Virtual memory file system support (former shm fs)" enabled; this option lives under the "File systems" section of the kernel configuration options. Once you have a tmpfs-enabled kernel, you can go ahead and mount tmpfs filesystems. In fact, it's a good idea to enable tmpfs in all your 2.4 kernels, whether you plan to use tmpfs or not. This is because you need to have kernel tmpfs support in order to use POSIX shared memory. System V shared memory will work without tmpfs in your kernel, however. Note that you do not need a tmpfs filesystem to be mounted for POSIX shared memory to work; you simply need the support in your kernel. POSIX shared memory isn't used too much right now, but this situation will likely change as time goes on.

Avoiding low VM conditions

The fact that tmpfs dynamically grows and shrinks as needed makes one wonder: what happens when your tmpfs filesystem grows to the point where it exhausts all of your virtual memory, and you have no RAM or swap left? Well, generally, this kind of situation is a bit ugly. With kernel 2.4.4, the kernel would immediately lock up. With kernel 2.4.6, the VM subsystem has in many ways been fixed, and while exhausting VM isn't exactly a wonderful experience, things don't blow up completely, either. When 2.4.6 gets to the point where it can't allocate any more VM, you obviously won't be unable to write any new data to your tmpfs filesystem. In addition, it's likely that some other things will happen. First, the other processes on the system will be unable to allocate much more memory; generally, this means that the system will most likely become extremely sluggish and almost unresponsive. Thus, it may be tricky or unusually time-consuming for the superuser to take the necessary steps to alleviate this low-VM condition.

In addition, the kernel has a built-in last-ditch system for freeing memory when no more is available; it'll find a process that's hogging VM resources and kill it. Unfortunately, this "kill a process" solution generally backfires when tmpfs growth is to blame for VM exhaustion. Here's the reason. Tmpfs itself can't (and shouldn't) be killed, since it is part of the kernel and not a user process, and there's no easy way for the kernel to find out which process is filling up the tmpfs filesystem. So, the kernel mistakenly attacks the biggest VM-hog of a process it can find, which is generally your X server if you happen to be running one. So, your X server dies, and the root cause of the low-VM condition (tmpfs) isn't addressed. Ick.

Low VM: the solution

Fortunately, tmpfs allows you to specify a maximum upper bound for the filesystem size when a filesystem is mounted or remounted. Actually, as of kernel 2.4.6 and util-linux-2.11g, these parameters can only be set on mount, not on remount, but we can expect them to be settable on remount sometime in the near future. The optimal maximum tmpfs size setting depends on the resources and usage pattern of your particular Linux box; the idea is to prevent a completely full tmpfs filesystem from exhausting all virtual memory and thus causing the ugly low-VM conditions that we talked about earlier. A good way to find a good tmpfs upper-bound is to use top to monitor your system's swap usage during peak usage periods. Then, make sure that you specify a tmpfs upper-bound that's slightly less than the sum of all free swap and free RAM during these peak usage times.

Creating a tmpfs filesystem with a maximum size is easy. To create a new tmpfs filesystem with a maximum filesystem size of 32 MB, type:

This time, instead of mounting our new tmpfs filesystem at /mnt/tmpfs, we created it at /dev/shm, which is a directory that happens to be the "official" mountpoint for a tmpfs filesystem. If you happen to be using devfs, you'll find that this directory has already been created for you.

Also, if we want to limit the filesystem size to 512 KB or 1 GB, we can specify size=512k and size=1g, respectively. In addition to limiting size, we can also limit the number of inodes (filesystem objects) by specifying the nr_inodes=x parameter. When using nr_inodes, x can be a simple integer, and can also be followed with a k, m, or g to specify thousands, millions, or billions (!) of inodes.

Also, if you'd like to add the equivalent of the above mount tmpfs command to your /etc/fstab, it'd look like this:

tmpfs	/dev/shm	tmpfs	size=32m	0	0

Mounting on top of existing mountpoints

Back in the 2.2 days, any attempt to mount something to a mountpoint where something had already been mounted resulted in an error. However, thanks to a rewrite of the kernel mounting code, using mountpoints multiple times is not a problem. Here's an example scenario: let's say that we have an existing filesystem mounted at /tmp. However, we decide that we'd like to start using tmpfs for /tmp storage. In the old days, your only option would be to unmount /tmp and remount your new tmpfs /tmp filesystem in its place, as follows:

#  umount /tmp
#  mount tmpfs /tmp -t tmpfs -o size=64m

However, this solution may not work for you. Maybe there are a number of running processes that have open files in /tmp; if so, when trying to unmount /tmp, you'd get the following error:

umount: /tmp: device is busy

However, with recent 2.4 kernels, you can mount your new /tmp filesystem without getting the "device is busy" error:

# mount tmpfs /tmp -t tmpfs -o size=64m

With a single command, your new tmpfs /tmp filesystem is mounted at /tmp, on top of the already-mounted partition, which can no longer be directly accessed. However, while you can't get to the original /tmp, any processes that still have open files on this original filesystem can continue to access them. And, if you umount your tmpfs-based /tmp, your original mounted /tmp filesystem will reappear. In fact, you can mount any number of filesystems to the same mountpoint, and the mountpoint will act like a stack; unmount the current filesystem, and the last-most-recently mounted filesystem will reappear from underneath.

Bind mounts

Using bind mounts, we can mount all, or even part of an already-mounted filesystem to another location, and have the filesystem accessible from both mountpoints at the same time! For example, you can use bind mounts to mount your existing root filesystem to /home/drobbins/nifty, as follows:

#  mount --bind / /home/drobbins/nifty

Now, if you look inside /home/drobbins/nifty, you'll see your root filesystem (/home/drobbins/nifty/etc, /home/drobbins/nifty/opt, etc.). And if you modify a file on your root filesystem, you'll see the modifications in /home/drobbins/nifty as well. This is because they are one and the same filesystem; the kernel is simply mapping the filesystem to two different mountpoints for us. Note that when you mount a filesystem somewhere else, any filesystems that were mounted to mountpoints inside the bind-mounted filesystem will not be moved along. In other words, if you have /usr on a separate filesystem, the bind mount we performed above will leave /home/drobbins/nifty/usr empty. You'll need an additional bind mount command to allow you to browse the contents of /usr at /home/drobbins/nifty/usr:

#  mount --bind /usr /home/drobbins/nifty/usr

Bind mounting parts of filesystems

Bind mounting makes even more neat things possible. Let's say that you have a tmpfs filesystem mounted at /dev/shm, its traditional location, and you decide that you'd like to start using tmpfs for /tmp, which currently lives on your root filesystem. Rather than mounting a new tmpfs filesystem to /tmp (which is possible), you may decide that you'd like the new /tmp to share the currently mounted /dev/shm filesystem. However, while you could bind mount /dev/shm to /tmp and be done with it, your /dev/shm contains some directories that you don't want to appear in /tmp. So, what do you do? How about this:

# mkdir /dev/shm/tmp

# chmod 1777 /dev/shm/tmp

# mount --bind /dev/shm/tmp /tmp

In this example, we first create a /dev/shm/tmp directory and then give it 1777 perms, the proper permissions for /tmp. Now that our directory is ready, we can mount /dev/shm/tmp, and only /dev/shm/tmp to /tmp. So, while /tmp/foo would map to /dev/shm/tmp/foo, there's no way for you to access the /dev/shm/bar file from /tmp.

As you can see, bind mounts are extremely powerful and make it easy to make modifications to your filesystem layout without any fuss. Next article, we'll check out devfs; for now, you may want to check out the following resources.

NEWS CONTENTS

• 20160225 : What Is -dev-shm And Its Practical Usage ( March 14, 2006 , cyberciti.biz )
• 20160225 : Recommend readings: ( )
• 20110810 : fstab - ArchWiki ( fstab - ArchWiki, Aug 10, 2011 )
• 20110809 : Create turbocharged storage using tmpfs by Kevin van Zonneveld (kvz) ( Kevin van Zonneveld )

Old News ;-)

[Feb 25, 2016] What Is -dev-shm And Its Practical Usage

March 14, 2006 | cyberciti.biz

/dev/shm is nothing but implementation of traditional shared memory concept. It is an efficient means of passing data between programs. One program will create a memory portion, which other processes (if permitted) can access. This will result into speeding up things on Linux.

shm / shmfs is also known as tmpfs, which is a common name for a temporary file storage facility on many Unix-like operating systems. It is intended to appear as a mounted file system, but one which uses virtual memory instead of a persistent storage device.

If you type the mount command you will see /dev/shm as a tempfs file system. Therefore, it is a file system, which keeps all files in virtual memory. Everything in tmpfs is temporary in the sense that no files will be created on your hard drive. If you unmount a tmpfs instance, everything stored therein is lost. By default almost all Linux distros configured to use /dev/shm:
$ df -h
Sample outputs:

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/wks01-root
                      444G   70G  351G  17% /
tmpfs                 3.9G     0  3.9G   0% /lib/init/rw
udev                  3.9G  332K  3.9G   1% /dev
tmpfs                 3.9G  168K  3.9G   1% /dev/shm
/dev/sda1             228M   32M  184M  15% /boot

Nevertheless, where can I use /dev/shm?

You can use /dev/shm to improve the performance of application software such as Oracle or overall Linux system performance. On heavily loaded system, it can make tons of difference. For example VMware workstation/server can be optimized to improve your Linux host's performance (i.e. improve the performance of your virtual machines).

In this example, remount /dev/shm with 8G size as follows:

# mount -o remount,size=8G /dev/shm

To be frank, if you have more than 2GB RAM + multiple Virtual machines, this hack always improves performance. In this example, you will give you tmpfs instance on /disk2/tmpfs which can allocate 5GB RAM/SWAP in 5K inodes and it is only accessible by root:
# mount -t tmpfs -o size=5G,nr_inodes=5k,mode=700 tmpfs /disk2/tmpfs
Where,

• -o opt1,opt2 : Pass various options with a -o flag followed by a comma separated string of options. In this examples, I used the following options:
  • remount : Attempt to remount an already-mounted filesystem. In this example, remount the system and increase its size.
  • size=8G or size=5G : Override default maximum size of the /dev/shm filesystem. he size is given in bytes, and rounded up to entire pages. The default is half of the memory. The size parameter also accepts a suffix % to limit this tmpfs instance to that percentage of your pysical RAM: the default, when neither size nor nr_blocks is specified, is size=50%. In this example it is set to 8GiB or 5GiB. The tmpfs mount options for sizing ( size, nr_blocks, and nr_inodes) accept a suffix k, m or g for Ki, Mi, Gi (binary kilo, mega and giga) and can be changed on remount.
  • nr_inodes=5k : The maximum number of inodes for this instance. The default is half of the number of your physical RAM pages, or (on a machine with highmem) the number of lowmem RAM pages, whichever is the lower.
  • mode=700 : Set initial permissions of the root directory.
  • tmpfs : Tmpfs is a file system which keeps all files in virtual memory.

How do I restrict or modify size of /dev/shm permanently?

You need to add or modify entry in /etc/fstab file so that system can read it after the reboot. Edit, /etc/fstab as a root user, enter:

# vi /etc/fstab

Append or modify /dev/shm entry as follows to set size to 8G

none      /dev/shm        tmpfs   defaults,size=8G        0 0

Save and close the file. For the changes to take effect immediately remount /dev/shm:
# mount -o remount /dev/shm
Verify the same:
# df -h

Recommend readings:

• See man pages of mount regarding tmpfs options.
• Details regarding tmpfs is available in /usr/share/doc/kernel-doc-/Documentation/filesystems/tmpfs.txt file.

[Aug 10, 2011] fstab - ArchWiki

atime options

The use of noatime, nodiratime or relatime can help disk performance for ext2, ext3, and ext4 filesystems. Linux by default keeps a record (writes to the disk) every times it reads from the disk atime. This was more purposeful when Linux was being used for servers; it doesn't have much value for desktop use. The worst thing about the default atime option is that even reading a file from the page cache (reading from memory instead of the disk) will still result in a disk write! Using the noatime option fully disables writing file access times to the disk every time you read a file. This works well for almost all applications, except for a rare few like Mutt that need the such information. For mutt, you should only use the relatime option. Using the relatime option enables the writing of file access times only when the file is being modified (unlike noatime where the file access time will never be changed and will be older than the modification time). The nodiratime option disables the writing of file access times only for directories while other files still get access times written. The best compromise might be the use of relatime in which case programs like Mutt will continue to work, but you'll still have a performance boost because files will not get access times updated unless they are modified.

Note: noatime already includes nodiratime. You don't need to specify both options.

tmpfs

tmpfs is a temporary filesystem that resides in memory and/or your swap partition(s), depending on how much you fill it up. Mounting directories as tmpfs can be an effective way of speeding up accesses to their files, or to ensure that their contents are automatically cleared upon reboot.

Some directories where tmpfs is commonly used are /tmp, /var/lock and /var/run. Do NOT use it on /var/tmp, because that folder is meant for temporary files that are preserved across reboots.

By default, a tmpfs partition has its maximum size set to half your total RAM, but this can be customized. Note that the actual memory/swap consumption depends on how much you fill it up, as tmpfs partitions don't consume any memory until it is actually needed.

To use tmpfs for /tmp, add this line to /etc/fstab:

File: /etc/fstab

.....
tmpfs /tmp      tmpfs nodev,nosuid,noexec                 0 0
.....

You may or may not want to specify the size here, but you should leave the mode option alone in these cases to ensure that they have the correct permissions (1777). In the example above, /tmp will be set to use up to half of your total RAM. To explicitly set a maximum size, use the size mount option:

File: /etc/fstab

.....
tmpfs /tmp      tmpfs nodev,nosuid,noexec,size=2G          0 0
.....

See the mount command man page for more information.

Reboot for the changes to take effect. Note that although it may be tempting to simply run mount -a to make the changes effective immediately, this will make any files currently residing in these directories inaccessible (this is especially problematic for running programs with lockfiles, for example). However, if all of them are empty, it should be safe to run mount -a instead of rebooting (or mount them individually).

After applying changes, you may want to verify that they took effect with findmnt:

$ findmnt --target /tmp

TARGET SOURCE FSTYPE OPTIONS
/tmp   tmpfs  tmpfs  rw,nosuid,nodev,noexec,relatime

To use tmpfs for /var/lock and /var/run, you can simply symlink them to /run. Make sure to close anything important before doing this, because you will have to reboot, and daemons may not stop cleanly.

# ln -sf /run/lock /var/lock # ln -sf /run /var/run # reboot

Note: Arch will likely do this by default in the future. See https://bugs.archlinux

[Aug 09, 2011] Create turbocharged storage using tmpfs by Kevin van Zonneveld (kvz)

Kevin van Zonneveld

As told before, you probably already have a /dev/shm on your linux system. So just copy a file to it:

cp -af /root/100mb.bin /dev/shm/

And now it's in your RAM! Using this file will be 30 times faster than before!

Enlarge current volume

But maybe the limit of half of your physical RAM just does not cut it for you. Then you might want to increase the maximum size of this volume to 4GB:

mount -o remount,size=4G /dev/shm

Create a new volume

Another possibility is to create a brand new memory device. We can do this with the filesystem type: tmpfs. Let's say you want to create a tmpfs instance on /var/www/www.mysite.com/ramdrive that can allocate a max of 500MB RAM and that can only be changed by root, but accessed by everyone (like Apache):

mkdir -p /var/www/www.mysite.com/ramdrive
mount -t tmpfs -o size=500M,mode=0744 tmpfs /var/www/www.mysite.com/ramdrive

Restore that volume everytime your server boots

Easy, just make sure the directory exists, and add the following line to your /etc/fstab :

tmpfs /var/www/www.mysite.com/ramdrive tmpfs size=500M,mode=0777 0 0

This will create a ramdrive of max 500MB in /var/www/www.mysite.com/ramdrive everytime your server boots. The mode 0777 will give it full access for everybody on your system, so just change that to a suitable umask.

Recommended Links

Softpanorama Recommended

Top articles

Sites

tmpfs - Wikipedia, the free encyclopedia

Storing Files-Directories In Memory With tmpfs HowtoForge - Linux Howtos and Tutorials

tmpfs and bind mounts are relatively new and for the most part undocumented new kernel features, the best way to learn more about them is to study relevant parts of the Linux kernel sources.

tmpfs entries in fstab (Page 1) - Mandriva - EeeUser Forum

8.2. Creating the -etc-fstab File

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019