Тази нощ тествах 64-битовата версия на Kubutu и не останах особено трогнат. Не усетих особено бързодействие, но за сметка на това опитах да обновя системата и останах негативно трогнат от архаичните версии на повечето програми.

Нещо, което ме е привличало винаги към Slackware е това, че пакетите му са винаги в актуалните си версии когато Пат го обновява. Иначе просто си тегля изходен код и си компилирам пакети.

Замислям се сериозно да прекомпилирам всички възможни пакети за Slackware от SlackBuild с 64-битови оптимизации и да си врътна едно DVD със Slackware 12/64bit. Хем ще си спестя неприятности с назаднали дистрибуци, хем ще подаря нещо полезно на хората, които търсят това и не са много доверчиви към Slamd64

Ето че се случи отново и не можах да се сдържа да смимам тези красиви водни създания Със сигурност днес вечера ще си ги хапна пържени.

Принципно не обичам особено много риба освен морски дарове от калибъра на: херинга, акулско филе, октопод и шпрота, но тези ще ги тествам дали ще ми харесат.

Вчера си взех дънце ASROCK K8UpgradeNF3 заедно с бокс процесор AMD64 Sempron 2500+. Бях безкрайно щастлив да разбера, че процесорът е с 64 битова технология.

След като машината беше включена си пуснах KDE и реших да тествам кое как работи и… лоша изненада. Няма DRI Настръхнах и си казах, това е от грешно избран модул за AGP. Прекомпилирах ядрото с всички възможни като се колебаех между само два модула в действителност и те бяха: nvidia_agp и amd64-agp. Резултатът беше същият.

Започнах безкрайно търсене в Google и навсякъде попадах на едно и също: ASROCK и ASUS имат k8 дънни платки с разкатан BIOS и в следствие на това собствениците на тези дънни платки обичали да пият по една студена вода. Изтръпнах, но от инат продължих да диря.

Около 5 часа сутринта попаднах на една препратка, която обясни обстойно проблема:

При въпросните дънни платки от ASROCK и ASUS се бъгва информацията в northbridge и Linux тъй като е разумен, чете инфото в BIOS-а и като види, че нещо не е ок в Aperture size се отказва и не зарежда DRI. Грешката, която може да се прочете при: dmesg | grep agpgart е:

Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected AGP bridge 0
agpgart: Setting up Nforce3 AGP.
agpgart: aperture base > 4G

В следствие натова се приготвяте да изпиете чаша студена вода и за момент я оставяте настрани. От тази въпросна препратка изтегляте патч за кернела с име local.2.6.20.2.amd64.diff и прекомпилирате кернела, след като сте патчнали с него. Поне при мен този патч реши наптлно проблема и при следващия boot видях:

Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected AGP bridge 0
agpgart: Setting up Nforce3 AGP.
agpgart: aperture base is (0x00000078)
agpgart: AGP aperture is 128M @ 0xf0000000
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode

Добрите новини бяха, че вече имах графично ускорение и ползвах amd64_agp успешно в комплект с agpgart. Този случай за пореден път ми доказа, че дори и най-сложните проблеми имат лесни решения, стига да знаеш къде да търсиш и какво да търсиш

Вече имам собствена Bluetooth USB тапинка. Марката и е Gembird и е с явно китайски произход. Устройството поддържа USB 1.1 и развива леко по-бавна връзка към телефона от предното такова (около 60KB/sec). Вносителят е за жалост с печалното на българския пазар име К&К Електроникс и се надявам да не се строши в близките месеци, в които за пореден път се очаква да не ми се намират много пари в наличност.Крайната цена е само 9.99лв. Очудващо добра цена. Същият е диска като точи на предното ми устройство, което ми говори за общо китайския характер и на двете.

П.С. Скоро ще продавам процесора и дънната платка върху, които работи две години Jabber сървъра, който по настояще е на bgLinux.org проекта. Време е и аз да се порадвам на малко по-бърза машина.

Винаги съм се радвал, когато съм успявал да спася една база данни с омазани collations. Преди няколко месеца се налагаше да боря два такива случая. Единия беше свързан с форума на XMPP/Jabber сървъра, а другият беше свързан с форума на “Фашън.БГ”. При втория случай конвертирането на базата в utf8 изглеждаше повече от невъзможно и се отказах да рискувам.

Тази нощ се наложи да помогна на един приятел с неговата Wordpress база данни. В този случай Wordpress беше настроен да си пише информацията в базата в UTF8 докато базата и таблиците и бяха с cp1251_bulgarian_ci collation. Това, което са измислили добре в последните версии на блог софтуера е, да се експортва съдържанието на блога в xml формат. За жалост не са направили възможно това да се икспортват и потребителите и настройките им.

Експортирах съсдържанието и вдигнах още един Wordpress, който вързах към база в utf8_general_ci и импортирах съдържанието на xml-а в новия блог. През phpMyAdmin-а експортнах вече ремонтираната база и редактирах на ръка sql файла добавяйки потребителите от стария омазан backup. Всичко заработи перфектно