This is old news by now. But recently I came across quite a few people who are suffering from various problems because of repetitive stress. Goggling for ergonomics is going to give you tons of results. So here's a quick summary of what I do to avoid these problems (hopefully !).
In a book titled C How to Program by Deitel and Deitel, computer languages are classified into three types as follows:
1. machine language
2. assembly language
3. high-level language
Well, everything started with single-user batch processing system. In this system, a batch of jobs are queued to be processed by the system one at a time. The system itself is usually operated by one operator. An owner of a job has to wait for the result to be produced by the system.
I believe every new student studying Computer Science or Information Technology will be introduced to the sub-systems of computers, which are Input Unit, Output Unit, Arithmetic and Logic Unit, Central Processing Unit, Storage Unit (Primary Storage Unit/Main Memory and Secondary Storage Unit). I always thought that the most amazing part of a computer was its processor (i.e., ALU and CPU).
I have my e-mail forwarding set up in FSF's mail server to my account in Yahoo!'s mail server.
I tune into several mailing lists, and I noticed that frequently the e-mails came out-of-order if not delivered at all.
How does the IP receiving mechanism assemble fragmented datagrams?
First of all, this writing is based on Linux kernel 18.104.22.168.
When I looked into
ip_frag_reasm() that was commented with
/* Build a new IP datagram from all its fragments. */ in
net/ipv4/ip_fragment.c, I could not find the code that I had looked for, specifically, the code to construct a new big SKB and copy all data fragments in the received SKBs into the new big SKB. Of course, if I had found what I had looked for, it would have meant that
ip_frag_reasm() was so inefficient (i.e., dumb). Instead,
ip_frag_reasm() only prepared the chain of the SKBs to be processed by
skb_copy_datagram_iovec() as I have described here.
Information on skb_copy_datagram_iovec()
This writing is based on Linux kernel 22.214.171.124.
This function is defined in
net/core/datagram.c. The main task of this function is to copy the data of an skb in the kernel-space to a memory location in the user-space. Usually, this function will be the one who finally satisfies
recvmsg() system call and its variants, which are
recvfrom(). Nevertheless, this main task also carries one unique responsibility: taking care of fragmentation.
As mentioned in Rusty's Unreliable Guide to Kernel Locking, the Linux kernel has three contexts of thread executions: hard-IRQ context, soft-IRQ context, and user/process-context. As on July 10, 2008, the guide does not mention anything about the boundaries between those contexts. So, I studied the source code of Linux kernel 126.96.36.199. From my study, it is clear that the boundaries are queues. It represents the classical IPC problem: the Producer-Consumer Problem.
During my work on the ATN TP4/CLNP Networking Suite, I helped a friend of mine to be able to capture Ethernet frames destined to unusual Ethernet multicast addresses. What I mean by unusual is that it is not the common IANA's range for multicast addresses, which is from 01-00-5e-00-00-00 to 01-00-5e-ff-ff-ff.
On 17 September 1991 Linus Torvalds was announcing the first version of Linux 0.0.1.
The rest is history.
here is more info about dusting off the linux 0.0.1 on modern distributions
and how to run in qemu
Upgraded to Firefox 3, and downgraded back in an hour. Why? Because the native look and feel of FireFox 3 was making me suffocate. It may have been working fast, may have been consuming less memory, but it did remind me of the good old Konqueror as a web browser, which I never liked. FF3's font rendering on Linux platform is simply unimaginably awful.