Meet The Gimp -- via bittorrent

Hebrew:

מישהו טרח ואסף את 100 סרטוני ההדרכה החופשיים והמצויינים אודות GIMP ויצר DVD הניתן להורדה בנחשול הביטים. פרטים נוספים בבלוג של רולף. הציפו את הביטים...

English:

The excellent and free video tutorials about the GIMP were collected on a DVD available for download via bittorrent. Further details on the blog of Rolf. Spread the bits...

HOWTO: Shift MS-Exchange users to sane (TZID) time zones

All invitations I got to a specific (MS using) company were shifted ~10 hours.

Since I was pretty familiar with MS software time-zone related oddities I ignored it for a while. But then as a curiosity I decided to look into the attached meeting content (vcs file). Lo and behold, it was saying: "Pacific Standard Time" ... as if our life at the middle east were really pacific ;-(

MS inventing their own "standards" is..., well, pretty standard. However, being a KDE user I was thinking if I can make korganizer understand their terminology:

• An strace proved korgranizer was obediently trying to convert the time by searching for /usr/share/zoneinfo/Pacific Standard Time
• So I tested a simple workaround (which worked):

ln -s America/Los_Angeles "/usr/share/zoneinfo/Pacific Standard Time"

• A little search showed some organization already made a formal map between LaLa-Land and the real world (even including an XML representation).

It was easy enough to generalize it by creating a small package that install a links-farm to do all these mappings. It simply uses the XML data together with a small perl script to create these links during build.
(hint, hint, review, review ;-)

People from other distros can grab the script here.

If all MS kinks were as simple as this...

[BTW: I am fully aware that this can be generated by modifying the source of tzdata -- I was looking for a simple solution with minimal disruption of existing packages].

“please get a newer Subversion client”

An old problem -- a new trick...

This error message is familiar to any Subversion user. The error is the result of trying to access a new working copy (WC) with an old subversion client.

An example scenario:

• Your Subversion WC is shared between several hosts.
• You work on the WC from one host (e.g: Centos5).
• You access the WC by mistake from another (e.g: Fedora11).
• The next time you try accessing your WC from the old host, you get this error message.

This behavior is pretty dumb:

• Subversion silently upgrade your WC metadata.
• It doesn't bother asking your permission to do so.
• It does it even for supposedly non-modifying actions like 'svn status'.
• The official FAQ says your only recourse is to upgrade the client...
• And you may "loose" many uncommitted changes!
  

Previously, I didn't have any better idea than this:

• Check out a clean working copy to a temporary directory.
• Use: diff -ru -x .svn damaged-wc/ fresh-wc/
• Manually merge files from damaged-wc/ to fresh-wc/
• Keep working from fresh-wc/
• Remove damaged-wc/

I just found a very nice workaround that was briefly mentioned:

rsync -r --progress \
--include='*/' --include '.svn/**' --exclude '*' \
fresh-wc/ damaged-wc/

That post only mentioned that emsearcy from OSUOSL is the source of this nice trick -- after googling I found it in an IRC log (big one).

So, this should serve as another documentation for this.

USB mouse + hibernation

My laptop (smolt) works nicely, but I have one quirk -- whenever the laptop wakes up from hibernation (suspend to disk), the external USB mouse does not function at all (while the synaptics touchpad works flawlessly).

My workaround was always to plug it after the wakeup (or if it was plugged before, simply take it out and re-plug it). Few weeks ago I stumbled on a nicer workaround:

1. Run lsusb (the mouse doesn't show, but...)
   
2. It works
3. Running lsusb again, for verification, shows the mouse.

It seems like the bug is in the host controller driver, or is it?
Can somebody shed more light about the real bug?

monitoring fetchmail

I use fetchmail to pull mail from several accounts in several places.
After my ISP had some "technical difficulties" it was obvious I should monitor
the logs for fetchmail errors.

Surprisingly enough, I didn't find anything ready for logwatch. So now there is ;-)

Also opened a bug report with links to the script + config file and their installation
directories.

Enjoy,

OO.o misterious freeze isn't a mistery anymore

I wonder how many more languages (beside Hebrew) are affected by this...

Ilan Shavit (Hebrew) posted about an OpenOffice.org "freeze" and a workaround:

• Whenever someone started writing something in Hebrew in an OO.o session there was a noticeable freeze of the application for several seconds. After this first freeze everything would be back to normal and you could open/edit/close Hebrew documents without further freezes.
• Ilan pointed to a thread in some local (Hebrew) forum containing somewhere a link to improved Hebrew myspell dictionary. (prepared by the good guys from Tk Open Systems that work on improving Hebrew support in OO.o on behalf of the Israeli government).
  

It turns out that what they did is convert the dictionary from ISO-8859-8 encoding to UTF-8.
A quick test on one of my computers:

1. Run oowriter, started writing the word שלום (Peace in Hebrew). It freezes after the second letter.
2. Close oowriter and repeat step 1 three times (to eliminate caching effects).
3. Measured the freeze -- it lasted for about 10 seconds.
4. Replace he_IL.aff and he_IL.dic with the "fixed" ones.
5. Repeating step 1 now freeze for less than 1 second. WOW!
   

Questions:

• What is the exact conversion process? The .aff file is textual, so it's easy with iconv(1), however I don't know the myspell toolchain (maybe translate-toolkit has the correct tools, didn't check).
• Do other languages have similar problems? Maybe only CTL languages affected?
• How hard it would be for package maintainers to fix this until upstream rolls it out?
  

HOWTO: Sendmail authentication against your ISP

After the trouble I had with incoming mail, I decided to migrate my sendmail configuration to use the big ISP mail server -- this documents establishing SMTP authentication against an ISP.

What I already had:

• SMART_HOST configured in my /etc/mail/sendmail.mc:



define(`SMART_HOST',`smtp:mail.actcom.co.il')



• Masquerade definitions, as I use a fictitious domain on my internal network.



MASQUERADE_AS(`actcom.co.il')dnl The domain of my ISP
... some optional features...
FEATURE(masquerade_entire_domain)dnl
... The domains that are masqueraded
MASQUERADE_DOMAIN(localhost.localdomain)dnl
MASQUERADE_DOMAIN(my.internal.domain)dnl




• The sendmail m4 macro package installed. In Fedora it is packaged
  as sendmail-cf

The only changes in /etc/mail/sendmail.mc were:

• Updating the SMART_HOST to the new mail server (out.bezeqint.net).
• I did not need to update the MASQUERADE_AS, since my mail address remained the same.
• Adding a new FEATURE:



FEATURE(authinfo)dnl

Now I had to create a new file /etc/mail/authinfo and make it readable only by root:

cd /etc/mail && touch authinfo && chmod 600 authinfo

The content of this file (for my ISP) is:

AuthInfo:server "R:realm" "U:user" "P:pass" "M:mechanisms"

Details:

• server - the name or IP of your ISP mail server (out.bezeqint.net for my ISP)
  
• realm - the domain of your ISP (bezeqint.net for my ISP). I first didn't set it and it caused obvious auth failures, as the default was my fictitious internal domain.
• user - for me it was different than 'oron' because the ISP modified the internal names of the users when it acquired Actcom.
• pass - guess what?
• mechanisms -- the default is a list of secure mechanisms (GSSAPI, etc.) obviously my ISP doesn't use anything like that so I had to give it explicitly as: "M:LOGIN PLAIN"
• The quotes around each items are mandatory!
  

For anyone who want the gory details, just make sure you have the sendmail-cf package installed and search authinfo (ignoring case)
in /usr/share/sendmail-cf/README.

Last but not least. They seem to be using Postfix, but don't support TLS, which means the users password is transmitted in the clear every time she send mail. Please don't tell this to Wietse_Venema so he won't get a heart attack.

Big ISP's and what they cost us

I was using the same small ISP (Actcom) since ~1997. An important reason was that it was founded and managed by Amir Plivatzky, which at the beginning of the 80's while studying for Masters degree at the Technion managed the BSD-4.1/4.2 systems in the Technion -- For me as an EE freshmen at the time, people like him should be blamed for sending me down the *NIX road ;-)

About a year and a half ago, Actcom was bought by one of the big players in our ISP pond (Bezeqint). I was worried, but since they promised to keep the status-quo, decided to wait and see how it goes.

To their credit, they did try to leave things as they are, but without the original knowledgeable people that's hard to do.... so things slowly deteriorated:

1. One of the first things to go was the web-app enabling a customer to securely manage its own mailbox. So to change your mailbox password, you have to call their support and tell them the wanted password :-O
   
2. Webmail (which I use when out of country) was also migrated to their systems. Problem? the link to it leads you to an 'http:' login screen -- as I don't want to send my password as cleartext across the globe it became a non-starter for me.

Last week I got another blow. Some mails I expected from people didn't show up. At first I didn't suspect anything unusual since I did get other mails. A few days later I dug my maillog and saw fechmail got a lot of 'Host unreachable' errors. A quick perl script found that in the last two weeks, only 3 out of 20 connection attempts per hour succeeded. The total amount of received mail was also very low. Emergency mode now starts... calling their support.

They were clueless as expected but they do deserve to be credited as they were:

1. Quick to answer the phone, polite and making an effort to help the best they could.
2. Didn't panic when finding out I didn't use Outlook but fetchmail (which they didn't heard of before). I explained them the problems and walked with them over the tests I did (resolving the mail server name to IP, pinging, testing the IMAP port number via telnet, testing POP3 as fallback).

They admitted they can barely manage Actcom's original mail server and advised me to work against their normal mail server. A quick change in my fetchmail parameters and >700 delayed mails landed in my mailboxes (I host 3 of them).

All good? Not so quick. Two days later I found that my mails stream is thin again. My logs show it was an authentication problem now. Quick call to the support line. The result? I had to change the internal user name of the mailbox with some prefix they assigned to Actcom customers. Still a bit unexplained:

• How it managed to suck >700 mails with the original names?
• Of the three mailboxes, two authenticate only with the new name, one authenticate only with the old. Go figure...

As you can understand I'm in damage control mode now and I haven't even thoroughly tested yet the outgoing mail path...

One small benefit. I wrote a quick and dirty logwatch plugin for fetchmail so at least I'll be alerted on time. I'll upload it somewhere (and try to push it to fetchmail Fedora package) when things calm down a little.

Microsoft Contributes...

In my previous post I forgot to mention another patch MS people should make to their code base:

find . -type f | xargs sed -i 's/Patent Promise/Patent License/g'

Microsoft Contributes Linux Drivers to Linux Community

Welcome Microsoft to our GPL club. Let's try to help you with some tips:

• While taking help from a prominent kernel contributor as g-k-h was very wise and he, no doubt, prevented you from falling in many pitfalls; you would still need a lot of patience. It takes time until people review your patches, ask questions in LKML, propose different approach, ask for rational etc, etc. Take your time, it's nothing personal against you -- it's simply the (somewhat) painful process for including code in the Linux kernel.
• Also, many times the results of this process generate a very different outcome than what the initial coder was thinking. You can just ask Ingo Molnar (as an example) how much time he's been working on the RT patches, how many iterations has passed and how much the result differ from the initial code contributed by MontaVista.
• In some cases the code may have to be maintained outside of the official kernel for a long time. Don't take it personally, it happened to the best/biggest Linux companies. Take as an example GFS2 and OCFS2 -- two clustering filesystems that are in active use by customers of RedHat and Oracle respectively for several years. Both are still not part of the Linux kernel (you can dig LKML for the gory details).
• There were even some extreme cases where code was not (shock, panic, awe...) merged at all! Even after IBM (which is one of the 3 biggest kernel contributors) invested a lot of time into EVMS (yes, it was long time ago..), its solution never made it to the official kernel. LVM2 took its place. Sometimes life can be tough. If worst happens and your code is left out in the cold -- don't despair, maybe next time...

Ah, and just another detail. There would be no doubt people in our community who would raise the patents issues and use them as an argument to reject your patches. While I cannot offer you a complete solution to this problem (until the patent system is revised to the ground), a small and simple idea may mitigate your problem -- make every patch sent to LKML contain the magic line:

Signed-off-by: Steve Ballmer

Cheers,


Yes: this post was written with a tongue in the cheek.
However: all claims are valid -- nobody has promised a free ticket into the kernel to any company who is willing to contribute code...

עברית בפדורה 11

כאשר שוחררה פדורה 11, כל מי שניגש לדף הראשי בעברית היה משוכנע ששוב דחו את מועד השחרור.

זוהי כמובן אשמתו של עבדכם הנאמן שמצא זמן לעדכן את התרגום רק עתה.

ובאותו נושא, חנוכת הגרסה החדשה של מערכת התרגום היא הזדמנות מצויינת להזכיר שיש עוד עבודה ומתנדבים אף פעם לא מיותרים. כמה הערות:

• אם אתם עסוקים בתרגום של פרוייקטים במעלה הזרם, התעלמו מבקשתי. תמשיכו לעזור לתומר במוזילה, לדיאגו ב-KDE לאנשי אופן-ולכל שאר האנשים הטובים שבזכותם נמנעת עבודה כפולה ומיותרת בכל ההפצות.
• עדיין אינכם מתרגמים? נו למה אתם מחכים? גם מעט תרגום סולל את הדרך להרבה אנשים, אז קדימה לעבודה.
  
• אם אתם משתתפים בפרוייקט תוכנה חופשית, אולי תרצו לחבר אותו למערכת Transifex של פדורה. כל התרגומים של המערכת יוכנסו ישירות למערכת ניהול הגרסאות בה אתם משתמשים (git, svn, mercurial, וכו'). העקרון המנחה בפדורה הוא לא ליצור פיצול מהפרוייקט במעלה הזרם אלא להזין אותו ישירות -- זה נכון גם לקוד וגם לתרגומים.

אז באיזה מרכיב אתם מתחילים?

זבל, האם אפשר להתגבר עליו?

קבוצת מתנדבים באסטוניה ניקו את המדינה:

• מבצע של יום אחד!

• כ-10,000 טון אשפה מאתרי טבע!

• הפעילו 50,000 מתנדבים.

• בעלות של כחצי מיליון יורו.

להשוואה:

• יחסית לאוכלוסיה, שקול לכ-15 מיליון מתנדבים בארה"ב.

• אם המדינה היתה צריכה לבצע, היה לוקח כ-3 שנים וכ-22 מיליון יורו.

והקשר לקוד פתוח...

Internet Draft: Transport Layer Security (TLS) Evidence Extensions

[mail to ietf@ietf.org]

I was worried by the information about a new Internet Draft which
seems to be troubled by patent claims even before its approval.

So, I decided to read a bit before forming a final opinion.

First I've read the following link from 19-Nov-2008

IANL but the language looks too familiar...

"RedPhone Security agrees to grant licenses for such uses in a fair
and nondiscriminatory manner. This statement applies to the
Disclosed Patent Information, including all amendments in all
nations as published during the course of prosecution."

I'm sure you are well aware that "fair and nondiscriminatory manner"
is the usual "newspeak" term for discriminating free software.
E.g: if someone only ask 10$ per-copy it means you cannot
distribute without having some copy counting mechanisms in place.

Looking further I've read the following link from 26-Nov-2008

So, about two weeks later, the same company says:

"Any party wishing to request a license under the patent
applications listed in Schedule A and/or any issued patents
from such applications is encouraged to contact RedPhone Security."

Which clarifies they reserve the right to provide licenses on a case
by case basis (yes, under the non-yada-yada etc). This is very different
from cases where comprehensive blanket licenses are given by relevant
companies for inclusion of their technologies in standard setting papers.

Which begs the question -- why all this is disclosed barely two months
before the (supposed) approval of this draft standard? To hush
criticism? To make IETF think harder about withdrawing after investing
a lot of time and work into this?

Regretfully, we already saw in some industries the advent of litigious
companies messing with industry standards (a sad refresher is here)

Not long ago, we saw other important standard bodies loses much
of their credibility due to similar tactics (I obviously refer to
the ISO/IEC DIS 29500 farce).

I obviously don't want IETF to fall into a similar trap. It's
important to reject this proposal so all of us can trust any RFC
or STD for what they are -- a free specification for anybody to
implement as they see fit.

Furthermore. Patent disclosure at the end of the process instead
of the beginning is not an example of honesty (do you think
they "forgot" they applied for these patents?)

IMHO, the only way for the IETF to protect itself and its reputation
from such predatory behaviour is to apply a mechanism to deter such
companies. Maybe something along the line of:

"You made us work X months without trusting us with your secret plan?
Good. You lost our trust for the next X months. You are welcome
to come back with different proposal *after* this time lapse."

I urge you to reconsider and not risk the great achievements of
Internet in general and the IETF in particular for a short term "gain".

Thank you very much for all your efforts,

[This mail was prepared and sent by free software, running on a
free operating system, abiding by freely available Internet standards]