The Zen of Python



Abstract
    Long time Pythoneer Tim Peters succinctly channels the BDFL's
    guiding principles for Python's design into 20 aphorisms, only 19
    of which have been written down.


The Zen of Python

  1.     Beautiful is better than ugly.
  2.     Explicit is better than implicit.
  3.     Simple is better than complex.
  4.     Complex is better than complicated.
  5.     Flat is better than nested.
  6.     Sparse is better than dense.
  7.     Readability counts.
  8.     Special cases aren't special enough to break the rules.
  9.     Although practicality beats purity.
  10.     Errors should never pass silently.
  11.     Unless explicitly silenced.
  12.     In the face of ambiguity, refuse the temptation to guess.
  13.     There should be one-- and preferably only one --obvious way to do it.
  14.     Although that way may not be obvious at first unless you're Dutch.
  15.     Now is better than never.
  16.     Although never is often better than *right* now.
  17.     If the implementation is hard to explain, it's a bad idea.
  18.     If the implementation is easy to explain, it may be a good idea.
  19.     Namespaces are one honking great idea -- let's do more of those!

The Python logo is a trademark of the Python Software Foundation


Windows 3.1 is still being used in the most important networks and systems today

I was really surprised when I read this news from zdnet :
"A Paris airport was forced to shut down earlier this month after a computer running Windows 3.1, a prehistoric operating system from 23 years ago, crashed in bad weather."
But old is not necessary bad as the article says:
 "A few years ago we did a complete analysis of our entire network. Cyber engineers found out that the system is extremely safe and extremely secure on the way it's developed,"

"Those older systems provide us some, I will say, huge safety, when it comes to some cyber issues that we currently have in the world,"


Read the full report on the below given link.

Practical sed commands

I am posting a summary of my  commands after a bit of Googling and after playing on my CentOS VM with sed.

WARNING & ADVICE: 
1. Always backup your files before playing with sed

2.The -i option in sed will replace the original file. So I recommend you run your
sed commands without the -i option first. Once you get the desired results of your sed command you
can then use the -i option.



append after <body>

sed  '/<body>/a Hello World' sample.html
sed -i  '/<body>/a Hello World' sample.html

append contents of file header-js.txt after <body>

sed -i '/<body>/ r header-js.txt' sample.html
sed -i '/<\/body>/ r footer-js.txt' sample.html

Some tests before proceeding further (tip: don't ignore the single quote)

[root@localhost mydir]# find . -name '*.html'
./sample2.html
./sample3.html
./sample.html


combine find with sed for mass modifications

find . -iname '*.html' -exec sed -i '/<body>/ r header-js.txt' '{}' \;
find . -iname '*.html' -exec sed -i '/<\/body>/ r footer-js.txt' '{}' \;

append at beginning of file

sed -i '1s/^/my script goes here\n/' file

Bandwidth vs Speed Part 2

In one of my earlier posts I wrote about bandwidth vs speed using the road and car analogy.

This post has been written by Chandan Singh Takuli from CISCO.

Too fast Too furious - who doesn't like speed, especially when we talk about the internet or network connectivity? But the real question is, which is better to have: fast speed or more bandwidth? Although these terms are inter-related, they're not same. As an internet or network user, "fast speed" means a faster rate of data communications. That sounds good, because who doesn't want a fast network connection? But when we start thinking about it as network engineers, things change a little bit as we talk about bandwidth over WAN and speed over LAN. Many network engineering friends of mine ask me, "What’s the difference?" So let’s dive into it.

The data traveling speed over media is a different concept than the speed of network we are talking about here. When we say "high speed network," we are not talking about data signals' traveling speed over network media, but we are talking about data transfer speed or rate across the network. Seem a little confusing? 

Let’s look at an example of water flowing through a tap. If a bucket can be filled with water from the tap in 5 minutes, that means we can fill 12 buckets of water in 1 hour, which gives us a rate/speed of 12 buckets/hour. Now if you double the width of the tap pipe and mouth, you will notice that the time taken to fill a single bucket is shortened by almost half and we can fill 24 buckets/hour. So our rate is doubled. (Remember that the water is flowing at the same speed inside the pipe as it was earlier.) The same concept applies in networking: the tap pipe is your link or media, the width of the pipe is your bandwidth, and the water is your data. The rate of data transfer depends on many factors, among which bandwidth is one of them.


“Bandwidth is the capacity and speed is the transfer rate”

More bandwidth does not mean more speed. Yep, you read that right. Suppose you have double the width of the tap pipe, but the water rate is still the same as it was when the tap pipe was half as wide. It will not result in any improvement in speed. When we talk about WAN links, we mostly talk about bandwidth; when we talk about LAN, we mostly talk about speed. This is because we are most limited by costly cable bandwidth over WAN rather than hardware and interface data transfer rates (or speed) over LAN.



I think the main confusion lies in the fact that we were users before we were network engineers. ISPs advertise their high bandwidth services as faster speeds, which gives users a wrong perception of bandwidth. So later on when we see things as network engineers, we get really confused. But I hope this helps clear up for you the difference between bandwidth and speed. Thanks for taking your valuable time to read this.

Cisco - Sending Syslog Messages As SNMP Traps and Informs

The following is an extract from the book Cisco IOS Cookbook,2nd edition (available online)

Problem

You want to send syslog messages as SNMP traps or informs.

Solution

You can configure the router to forward syslog messages to your network management server as SNMP traps instead of syslog packets with the following configuration commands:
Router#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#logging history informational
Router(config)#snmp-server enable traps syslog
Router(config)#snmp-server host 172.25.1.1 ORATRAP syslog
Router(config)#end
Router#
To forward syslog messages as SNMP informs, use the following configuration commands:
Router#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#logging history informational
Router(config)#snmp-server enable informs 
Router(config)#snmp-server host 172.25.1.1 informs version 2c ORATRAP syslog
Router(config)#end
Router#

Discussion

Cisco routers normally forward syslog messages via the syslog facility by using UDP port 514. However, in networks that support SNMP traffic only, Cisco routers can encapsulate their syslog messages into SNMP traps before sending them.
This feature is most useful if your network management software doesn’t support the syslog protocol. However, since routers can produce many more syslog messages than SNMP traps, we recommend using syslog when possible.