I write this in English so that all people around the world could get a chance to know what's going on in one of the biggest Chinese Linux forum linuxsir.org. On SUSE Linux sub-forum of linuxsir.org, there were some threads talking about MS and Novell's deal recently. But unfortunately, someone with high privilege in the forum combined these threads and moved them to a place that few people visit. So people won't see it in its original place. Moreover, people can't found it through the link provided in the reply-notification email linuxsir.org mailed to them. The pictures below illustrate this: Unless you are familiar with the operation of vBulletin or use search function of the forum you won't see it again. So the discussion discontinued, or rather _stopped_ by external and yet irresistible force. Then someone expressed angriness about this in SUSE sub-forum, and more people followed him. The discussion went on. However, this thread again is "combined" now. …
http://www.novell.com/linux/microsoft/community_open_letter.html Highlights: We disagree with the recent statements made by Microsoft on the topic of Linux and patents. Importantly, our agreement with Microsoft is in no way an acknowledgment that Linux infringes upon any Microsoft intellectual property. When we entered the patent cooperation agreement with Microsoft, Novell did not agree or admit that Linux or any other Novell offering violates Microsoft patents.
Here is the problem's description: In audacious-plugins' current implementation, when saving MP3's tags, unicode is enabled unconditionally. In save_cb() function in http://svn.atheme.org/audacious-plugins/trunk/src/mpg123/fileinfo.c, [ ^] there are two function calls: taglib_set_strings_unicode(1); and taglib_set_id3v2_default_text_encoding(); However, when reading MP3's tags, if chardet is enabled, unicode will be disabled. In fill_entries() function in the same file, there is a conditional compilation: #ifdef USE_CHARDET taglib_set_strings_unicode(FALSE); #endif
This may not affect English only users. But for CJK users, this discrepancy of dealing with chardet will lead to MP3's title and artist being rendered as garbled characters.
First you have to setup a break point. (gdb) b 'server::Checks::chkCleardigits(ost::Script::Line*, ost::ScriptImage*)' don't forget the leading ' before server, so that gdb can complete the whole function prototype for you.
Check breakpoint info (gdb) info b Num Type Disp Enb Address What 1 breakpoint keep y 0x080565f4 in server::Checks::chkCleardigits(ost::Script::Line*, ost::ScriptImage*) at checks.cpp:624 breakpoint already hit 1 time
Run the program, and then you find that there are so many calls to this function. However, you are only interested in one particular call. And most importantly, you know a condition which is unique to this call, line->argc>1
Set condition: (gdb) condition 1 line->argc>1 (gdb) info b Num Type Disp Enb Address What 1 breakpoint keep y 0x080565f4 in server::Checks::chkCleardigits(ost::Script::Line*, ost::ScriptImage*) at…
I was asked to analyze the usage of this "select.span" command. However, I've no idea wtf the so-called span is. What's worse, it seems that nobody else here could explain to me what it is. I am a totally newbie in this area(I mean IVR), and I think it is known to everyone. However, I did find some clue. I found normally those span should be initialized in the driver. Take capi20's driver as an example, BayonneSpan object is newed in Driver::startDriver(). But unfortunately, the synway's bayonne driver is not complete at this moment. The driver is in bayonne-nonfree package. In my opinion, the biggest problem now is this incomplete synway bayonne driver. If it is finished, many problems will not exist any longer.
PS: This "select" thing is discovered by me, when I analyzing "connect". In startDialing() which is called by scrConnect(), there is a call to getPointer() with a single parameter in the form "select.%s". Then I found the co…
According to e-zone, a Hong Kong magazine, PS3 60GB version will be sold at HK$ 3780 in Hong Kong starting from Nov 17. This price is equal to 56,810 Yen according to the exchange rate on Nov 1, while the expected price of Japan version is 60,000 Yen. This price is also lower than that of US version. The 20GB version will be available in December in Hong Kong. The price will be HK$ 3180.
The price is lower than I expected. However, I won't act before Winning Eleven PS3 version is out. :)