<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Ali Abbas</title>
	<atom:link href="http://alouche.net/feed/" rel="self" type="application/rss+xml" />
	<link>http://alouche.net</link>
	<description>Unix - Networking - News</description>
	<lastBuildDate>Fri, 04 May 2012 17:41:18 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
		<item>
		<title>Git :: Removing files from all commits</title>
		<link>http://alouche.net/2012/05/04/git-removing-files-from-all-commits/</link>
		<comments>http://alouche.net/2012/05/04/git-removing-files-from-all-commits/#comments</comments>
		<pubDate>Fri, 04 May 2012 17:41:18 +0000</pubDate>
		<dc:creator>Ali Abbas</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[git commit]]></category>

		<guid isPermaLink="false">http://alouche.net/?p=1468</guid>
		<description><![CDATA[Alright&#8230; this is just a tiny hint on the process I used to nuke some committed files from all commit history git filter-branch &#8211;index-filter &#8220;git rm -rf &#8211;cached &#8211;ignore-unmatch my_files&#8221; HEAD rm -rf .git/refs/original/ git reflog expire &#8211;all git gc &#8211;aggressive &#8211;prune git origin +master And here comes the explanation: # git filter-branch &#8211;index-filter &#8220;git [...]]]></description>
		<wfw:commentRss>http://alouche.net/2012/05/04/git-removing-files-from-all-commits/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>The so-called Skype SDK IP leaks</title>
		<link>http://alouche.net/2012/04/29/the-so-called-skype-sdk-ip-leaks/</link>
		<comments>http://alouche.net/2012/04/29/the-so-called-skype-sdk-ip-leaks/#comments</comments>
		<pubDate>Sun, 29 Apr 2012 20:13:56 +0000</pubDate>
		<dc:creator>Ali Abbas</dc:creator>
				<category><![CDATA[Networking]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[TCP/IP]]></category>
		<category><![CDATA[ip]]></category>
		<category><![CDATA[leak]]></category>
		<category><![CDATA[sdk]]></category>
		<category><![CDATA[skype]]></category>

		<guid isPermaLink="false">http://alouche.net/?p=1455</guid>
		<description><![CDATA[For the last few days, there has been a buzzing news in the community, following the recent discovery of a so-called information leak in the skype SDK. zhovner@github, published a python code sample &#8220;exploiting this vulnerability&#8221; https://github.com/zhovner/Skype-iplookup/ using a de-obfuscated SDK and published a demo site @http://skype-ip-finder.tk/. More related information on the skype-open-source project can [...]]]></description>
		<wfw:commentRss>http://alouche.net/2012/04/29/the-so-called-skype-sdk-ip-leaks/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Mercedes Museum</title>
		<link>http://alouche.net/2012/04/22/mercedes-museum/</link>
		<comments>http://alouche.net/2012/04/22/mercedes-museum/#comments</comments>
		<pubDate>Sun, 22 Apr 2012 20:21:46 +0000</pubDate>
		<dc:creator>Ali Abbas</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[fun mercedes museum]]></category>

		<guid isPermaLink="false">http://alouche.net/?p=1445</guid>
		<description><![CDATA[Here are a few snaps from my visit at the Mercedes Museum this weekend in Stuttgart &#8211; for those visiting Germany, it is definitely worth the stop. It was both cultivating and a lot of fun]]></description>
		<wfw:commentRss>http://alouche.net/2012/04/22/mercedes-museum/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Lower initial TCP RTO &#8211; Redhat kernel patch</title>
		<link>http://alouche.net/2012/02/24/lower-initial-tcp-rto-redhat-kernel-patch/</link>
		<comments>http://alouche.net/2012/02/24/lower-initial-tcp-rto-redhat-kernel-patch/#comments</comments>
		<pubDate>Fri, 24 Feb 2012 19:56:39 +0000</pubDate>
		<dc:creator>Ali Abbas</dc:creator>
				<category><![CDATA[Kernel]]></category>
		<category><![CDATA[Unix / Linux]]></category>
		<category><![CDATA[init RTO]]></category>
		<category><![CDATA[Patch]]></category>
		<category><![CDATA[tcp]]></category>

		<guid isPermaLink="false">http://alouche.net/?p=1415</guid>
		<description><![CDATA[I have recently back-ported the rfc2988bis changes (initRTO=1 and fallack) to the redhat 2.6.32 kernel &#8211; find the patch on my github account at @ https://github.com/alouche/redhat-2.6.32-kernel-patches/blob/master/rfc2988bis.patch On short lived connections with a lot of 3WHS, a lower initial RTO will improve 3WHS latency by 2*2000ms*X% (X% being the average of packet drops of a specific [...]]]></description>
		<wfw:commentRss>http://alouche.net/2012/02/24/lower-initial-tcp-rto-redhat-kernel-patch/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Linux CFS Algorithm and Virtual Runtime</title>
		<link>http://alouche.net/2012/02/04/linux-cfs-algorithm-and-virtual-runtime/</link>
		<comments>http://alouche.net/2012/02/04/linux-cfs-algorithm-and-virtual-runtime/#comments</comments>
		<pubDate>Sat, 04 Feb 2012 13:21:08 +0000</pubDate>
		<dc:creator>Ali Abbas</dc:creator>
				<category><![CDATA[Kernel]]></category>
		<category><![CDATA[Unix / Linux]]></category>
		<category><![CDATA[cfs]]></category>
		<category><![CDATA[linux scheduler]]></category>

		<guid isPermaLink="false">http://alouche.net/?p=1389</guid>
		<description><![CDATA[Since the 2.6.23 kernel, the Linux kernel process scheduler previously O(1) was replaced by CFS &#8211; a Completely Fair Scheduler. CFS uses a red-black tree as data-structure and unlike previous Unix process scheduler does not account a traditional time slice of process execution but accounts what is referred as the process virtual runtime, expressed in [...]]]></description>
		<wfw:commentRss>http://alouche.net/2012/02/04/linux-cfs-algorithm-and-virtual-runtime/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>DCB 101 &#8211; Priority-based Flow Control</title>
		<link>http://alouche.net/2012/01/13/dcb-101-priority-based-flow-control/</link>
		<comments>http://alouche.net/2012/01/13/dcb-101-priority-based-flow-control/#comments</comments>
		<pubDate>Fri, 13 Jan 2012 13:39:12 +0000</pubDate>
		<dc:creator>Ali Abbas</dc:creator>
				<category><![CDATA[DCB]]></category>
		<category><![CDATA[Networking]]></category>
		<category><![CDATA[dcb]]></category>
		<category><![CDATA[fcoe]]></category>
		<category><![CDATA[pfc]]></category>
		<category><![CDATA[ppc]]></category>

		<guid isPermaLink="false">http://alouche.net/?p=1368</guid>
		<description><![CDATA[DCB &#8211; Data Center Bridging is set of standard which defines 4 set of independent technologies/concepts to pretty much make Ethernet lossless, hence to support storage traffic. We will not go into a debate over FCoE, whether you should consider a single fabric for both storage and &#8220;standard/Ethernet&#8221; traffic in your data center design strategy [...]]]></description>
		<wfw:commentRss>http://alouche.net/2012/01/13/dcb-101-priority-based-flow-control/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Yes Diffie-Hellman is secure</title>
		<link>http://alouche.net/2011/10/31/yes-diffie-hellman-is-secure/</link>
		<comments>http://alouche.net/2011/10/31/yes-diffie-hellman-is-secure/#comments</comments>
		<pubDate>Mon, 31 Oct 2011 20:24:31 +0000</pubDate>
		<dc:creator>Ali Abbas</dc:creator>
				<category><![CDATA[Cryptography]]></category>
		<category><![CDATA[encryption]]></category>
		<category><![CDATA[logarithm]]></category>

		<guid isPermaLink="false">http://alouche.net/blog/?p=1265</guid>
		<description><![CDATA[When it comes to the Diffie-Hellman algorithm, there seem to be many confusions from newbies in Cryptography as to whether an attacker could easily recompute the shared key by intercepting the prime numbers + public keys. While the answer is &#8220;no&#8221;, understanding why, requires an understanding the discrete logarithm problem. So here we go. Discrete Logarithm [...]]]></description>
		<wfw:commentRss>http://alouche.net/2011/10/31/yes-diffie-hellman-is-secure/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>RXDSK &#8211; RapidDisk &#8211; Ram Block Device</title>
		<link>http://alouche.net/2011/10/12/rxdsk-rapiddisk-ram-block-device/</link>
		<comments>http://alouche.net/2011/10/12/rxdsk-rapiddisk-ram-block-device/#comments</comments>
		<pubDate>Wed, 12 Oct 2011 20:17:09 +0000</pubDate>
		<dc:creator>Ali Abbas</dc:creator>
				<category><![CDATA[Unix / Linux]]></category>
		<category><![CDATA[kernel]]></category>
		<category><![CDATA[ram]]></category>
		<category><![CDATA[ramfs]]></category>
		<category><![CDATA[tmpfs]]></category>
		<category><![CDATA[zxdsk]]></category>

		<guid isPermaLink="false">http://alouche.net/blog/?p=1251</guid>
		<description><![CDATA[RXDSK is a project currently in development which is worth checking out and keeping an eye on. It is quiet similar to ZRAM (previously compache) and TMPFS/RAMFS but has some minor differences which renders it more flexible for generic usage. ZXDSK allows for example an export of the ram disk to a physical disk, making [...]]]></description>
		<wfw:commentRss>http://alouche.net/2011/10/12/rxdsk-rapiddisk-ram-block-device/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>RedHat/CentOS 6 Xen Kernel RPMs</title>
		<link>http://alouche.net/2011/09/08/redhat-centos-6-xen-kernel-rpms/</link>
		<comments>http://alouche.net/2011/09/08/redhat-centos-6-xen-kernel-rpms/#comments</comments>
		<pubDate>Thu, 08 Sep 2011 16:57:10 +0000</pubDate>
		<dc:creator>Ali Abbas</dc:creator>
				<category><![CDATA[Redhat/Centos]]></category>
		<category><![CDATA[Unix / Linux]]></category>
		<category><![CDATA[dom0]]></category>
		<category><![CDATA[el6]]></category>
		<category><![CDATA[kernel]]></category>
		<category><![CDATA[xen]]></category>

		<guid isPermaLink="false">http://alouche.net/blog/?p=1216</guid>
		<description><![CDATA[I have created a working Red Hat/CentOS 6 Xen Dom0 Kernel including backport patches. I had to hack to the blktap driver hooks to finalize support of the module due to the interface changes in the recent vanilla kernel. But all is working. [root@blackhole1 ~]# uname -rsm Linux 2.6.32-131.12.1.el6.alouche.xen.dom0.x86_64 x86_64 [root@blackhole1 ~]# xm list Name                                        [...]]]></description>
		<wfw:commentRss>http://alouche.net/2011/09/08/redhat-centos-6-xen-kernel-rpms/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Padhye et. al. Equation and TCP performance</title>
		<link>http://alouche.net/2011/09/03/padhye-et-al-equation-and-tcp-performance/</link>
		<comments>http://alouche.net/2011/09/03/padhye-et-al-equation-and-tcp-performance/#comments</comments>
		<pubDate>Sat, 03 Sep 2011 20:02:31 +0000</pubDate>
		<dc:creator>Ali Abbas</dc:creator>
				<category><![CDATA[TCP/IP]]></category>
		<category><![CDATA[equation]]></category>
		<category><![CDATA[performance]]></category>

		<guid isPermaLink="false">http://alouche.net/blog/?p=932</guid>
		<description><![CDATA[If you are not familiar with the Mathis Equation, I recommend you quickly go over my post article Mathis Equation and TCP Performance. This is necessary since the Padhye et. al. Equation is an extension to the Mathis Equation for accuracy of TCP throughput calculation over multiple scenario of packet loss. As simply put, the Padhye [...]]]></description>
		<wfw:commentRss>http://alouche.net/2011/09/03/padhye-et-al-equation-and-tcp-performance/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

