Quite an irony that this very honest and non-jingoistic tweet was made by the Chief Minister of a state that the rest of India is so jingoistic about.
I have been noticing that writing a commit message in git just like I have been doing in svn or CVS gives me a rather colorful output (see the credited link below for a screen grab).
Searching on the web led me to this post about someone else who found it odd and actually posted about it.
Turns out that the vim syntax file is trying to point out git commit messages best practices.
To summarize these:
but I am just noting this here because I generally tend NOt to do this.Spending all my time at work with Redhat’s suite of products and at the same time sticking to having my primary working OS to be Ubuntu was causing too much dissonance. So I finally decided to move to Fedora as my primary OS after 6 years of Ubuntu. My guess was that as a desktop user, beyond packaging issues, the transition is going to be minimal. But as with any new release, there are always some niggling issues, and I am going to document them here in one place as I continue to find them.
SElinux is enforced by default on F15. For once I think I will not fight this. This would be a good opportunity to learn selinux properly. However, there are some application errors because of this:
Fedora 15 includes Gnome 3, which requires a major re-learning for doing every day stuff. The settings applications is missing a lot of config options which I was using earlier in Ubuntu. It turns out that Gnome 3 hides a lot of these settings by design. Unfortunately, this means that people will need to learn additional tools to do what they want.
Lots of Gnome 3 tips at the Archlinux wiki.
The only annoying this I find in the otherwise indispensable GNU Screen is the fact that once you have launched screen (not resume) and have detached and logged off the first time, ssh-agent magic stops working in the screen sessions.
Obviously this is because the next time you login, your ssh agent socket changes but the screen sessions still only have the location of the ssh-agent socket when you launched screen for the first time. The end result is that you start typing out passwords all over again, risking inadvertently revealing them to your colleague while you are showing him some stuff at your workstation.
There are scores of workarounds all over the net of how people have solved this problem. I just wanted to post here about how I work around this.
The work is actually done at the bottom of my .bashrc which reads:
case "$TERM" in
screen)
source ~/.bashrc.ssh
;;
*)
echo "export SSH_AUTH_SOCK=${SSH_AUTH_SOCK}" > ~/.bashrc.ssh
;;
esac
This will ensure that all new shell sessions in screen going forward will have the right ssh-agent socket info. For the sessions which are still open, just do a source ~/.bashrc.ssh whenever you login next and resume screen.
We Indians have been cribbing about ISP data caps for broadband called very insultingly as Fair Usage Policy (FUP), but I have heard few making a very good case about why this is a bad idea for the market. And how the ISP’s justifications of minority data hoggers is a case of Bull*.
But I just heard about a very good case being made against such data caps in the US broadband market. Two prominent Washington DC tech policy groups have asked the Federal Communications Commission to investigate Internet data caps in the US—with a special focus on AT&T.
Unlike competitors whose caps appear to be at least nominally linked to congestions during peak-use periods, AT&T seeks to convert caps into a profit center by charging additional fees to customers who exceed the cap. In addition to concerns raised by broadband caps generally, such a practice produces a perverse incentive for AT&T to avoid raising its caps even as its own capacity expands.
…
The lower cap for DSL customers is especially worrying because one of the traditional selling points of DSL networks is that their dedicated circuit design helps to mitigate the impacts of heavy users on the rest of the network. Together, these caps suggest either that AT&T’s current network compares poorly to that of a major competitor circa 2008 or that there are non-network-management motivations behind their creation.
It is time Airtel and it’s ilk is taken to court for the FUP scam they are running in the broadband market. Thanks to these greedy operators, India still has one of the lowest penetration figures (~7%) for broadband in Asia, forget the rest of the world.
Here is a quick tip which I have gleaned from multiple sources which makes using procmail filters a breeze. I subscribe to dozens of mailing lists, and it really is somewhat of a chore to create filters for every mailing list I signup for so that mails for that list goes to a separate folder.
However, it is possible to setup procmailrc in such a way that you really don’t need to update procmailrc for every new mailing list that you signup for. You essentially use procmail’s regex support to generate folder names.
At the end of procmailrc, you just need to add this rule:
:0 * ^((List-Id|X-(Mailing-)?List): *<\/[^.]*) .list-$MATCH/
This will use the list-id header value, extract the text before the first period (e.g. for a list-id xxxx.lists.sourceforge.net, it will extract xxxx) and generate a folder name called .list-xxxx to store the mail in. If the folder doesn't exist, it will create it.
Now I mention to add this at the end of the procmailrc so that it works kind of like a catch-all recipe. You can have other recipes before this which work differently on incoming mail, which stores mails for lists into folders which don't quite match the list name, etc. Whichever mailing list mail gets past these custom filters, they would hit the recipe given above and go into the "magic" folder for the list.
However, if you really want to keep this recipe at the top of procmailrc and want to restrict this "automatic folder creation" treatment to a select few lists, you can use a variation of the recipe which still saves you some effort.
:0
* ^((List-Id|X-(Mailing-)?List): *<\/[^.]*)
{
LISTID=$MATCH
:0
* LISTID ?? (ilugd|ilugd-announce|bangpypers|linux-india)
.list-$MATCH/
}
Now whenever you subscribe to a new list, edit the line with "??" above, and add a "|listname" before the final brace and you are set. This recipe can stay at the top of the procmailrc, automatically filtering only the lists you mention here. The mails from mailing-lists which don't match these lists will keep looking further down for the rest of the procmail recipes.
I must mention at the end, that if you are using IMAP to access this mail store where procmail is doing something similar to a server-side filtering, then after you incorporate this procmailrc recipe, wait for the first mail to arrive and then use the "subscribe" option of your IMAP client to subscribe to the new folder. Most IMAP clients don't automatically subscribe to new server-side created folders. So even if procmail would be creating the new folder, it won't be visible in your IMAP client unless you subscribe to it, and you might get the impression that the recipe is not working. That is unless you are using procmail's log feature to debug new recipes already.
The European Commission has put into effect a June 2009 agreement stating that major cellphone manufacturers should standardize their charging/data connection ports to the popular microUSB format.
Finally. It took over a decade (in Indian market) to get to this point. I wonder why it took so long. But I am so glad that already my Android phone, Kindle and bluetooth headset all use the same charger.
Starting with Gingerbread, newer Android phones (starting with the Nexus S) will be using the ext4 file system.
Android Arena mentions one of the main advantages:
YAFFS is single-threaded, which would have been a bottleneck when trying to record those full HD video clips, and save them to the flash memory, whereas Ext4 doesn’t have this limitation. Thus the new file system is more suited for usage with the multicore ARM-based chipsets that will be creeping into handsets and tablets next year. Ext4 will actually improve the handling of data loss, if developers make sure their application data is getting to persistent storage on time.
I am wondering what happens to existing mobiles which upgrade to Gingerbread? I would probably need to backup all data and format the card as ext4 myself.
Just a lighthearted reminder that, even if the lure of the connected digital world gets people to skimp on the Gilligan’s Island reruns, that doesn’t necessarily mean their replacement behaviors will be any more productive. They could instead bring an ever greater capacity for distraction and disengagement and slingshot precision.
Interesting article on how the Internet giveth and taketh it away. Our productivity, that is. Yeah, we all knew that, but this article gives out some interesting numbers.
Amazing work by all the people involved!
Venkatesh Hariharan reported on the Linux Delhi mailing list today:
The open standards policy has been finalized and it incorporates many of the suggestions made by the FOSS community in India. In the previous draft dated 25/11/2009, our major objection was to section 4.1.2 of the policy which said,
“4.1.2 The essential patent claims necessary to implement the Identified Standard should preferably be available on a Royalty-Free (no payment and no restrictions) basis for the life time of the standard. However, if such Standards are not found feasible and in the wider public interest, then RF on Fair, Reasonable and Non Discriminatory terms and conditions (FRAND) or Reasonable and Non Discriminatory terms and conditions (RAND) could be considered.”
Our comment on this section reads:
The usage of terms like “preferably” in a section titled, “Mandatory Characteristics” weakens the section and could even render it meaningless. Mandatory characteristics should be laid out clearly and unambiguously. The term “essential patent claims,” is meaningless because a standard cannot be implemented partially. Therefore, the ENTIRE standard should be royalty-free and not just the “essential” parts of it. In other words, ALL patent claims necessary to implement the standard should be royalty-free. Also, RF on FRAND/RAND is self-contradictory. If a Standard is Royalty Free (RF) then it cannot be RAND. Therefore, the wording of this section should be changed to “ALL patent claims necessary to implement the Identified Standard should be available on a Royalty-Free (no payment and no restrictions) basis for the life time of the standard.”
As you can see from the extract below, the points mentioned above have been incorporated In the recently finalized policy. This section now reads:4.1.2 The Patent claims necessary to implement the Identified Standard shall be made available on a Royalty-Free basis for the life time of the Standard.
Overall, I’d say this is a major victory for the Indian FOSS community and more than three years of hard work have paid off. The file can be downloaded from here or from here. (click on the links on the top left hand side).
![[FSF Associate Member]](http://blog.sandipb.net/blog-images/fsf-button.png){kind=small}