Проблем с F1 2012 и Logitech Driving Force GT Wheel

Наскоро си закупих ето това чудо Logitech Driving Force GT и естествено го тествах с демото на F1 2012. Оказва се, че първоначалните настройки са объркани и воланът е прекалено чувствителен и е много трудно да се играе. Поиграх си с настройките и успях да го докарам до положение в което реагира както очаквам.

Ето какво точно съм сменил:

В Logitech Profiler направих радиуса на волана да е заключен на 271 градуса.
В Logitech Profiler направих Centering wheel на 45%.

В настройките на F1 2012 промених следните неща:

Driving Controls -> Override Input Device Type -> Steering Wheel
Driving Controls -> Advanced Wheel Settings -> Steering Deadzone - 1%
Driving Controls -> Advanced Wheel Settings -> Steering Saturation - 0%
Driving Controls -> Advanced Wheel Settings -> Steering Linearity - от 60 до 65% (в зависимост как ви харесва, при мен е на 60%)

Всичко останало на 0% (освен deadzone опциите които за всеки човек настройките са различни).
Много е важна опцията Override Input Device Type, тъй като вградените настройки на DFGT в F1 2012 са сбъркани и воланът е прекалено чувствителен.

Интересно е да се отбележе, че на F1 2011 този проблем го няма с настройките по подразбиране на този волан.

rFactor също се държи идеално.

Ако имате по-добри настройки/предложения за настройки за F1 2012 пишете в коментарите.

Редактирано 07.01.2013:

Още една примерна конфигурация която се държи дори по-добре от гореописаната:

В Logitech Profiler направих радиуса на волана да е заключен на 310 градуса.
Driving Controls -> Override Input Device Type -> Steering Wheel
Driving Controls -> Advanced Wheel Settings -> Steering Deadzone - 1%
Driving Controls -> Advanced Wheel Settings -> Steering Saturation - 10%
Driving Controls -> Advanced Wheel Settings -> Steering Linearity - 63%

Outlook 2010 reported error (0x800CCC0F) : Outlook cannot synchronize subscribed folders"

Outlook 2010 reported error (0x800CCC0F) : Outlook cannot synchronize subscribed folders"

С новият MS Office 2010 пакет идват и нови проблеми. При upgrade на Outlook до 2010 и използване на IMAP акаунт се получава следната грешка:

Outlook reported error (0x800CCC0F) : Outlook cannot synchronize subscribed folders"

Оказва се че Outlook 2010 при изтриване на съобщение при IMAP акаунт емейла се маркира като изтрит, но освен това се опитва да го премести в папка за изтрити съобщения. Старата версия на Outlook просто ги маркираше като изтрити без да ги мести никъде (и при purge се изтриваха).

Оказва се че по подразбиране на Outlook 2010 не е указана папката в която да се местят при изтриване съобщенията и при всеки опит да се провери пощата, Outlook се опитва да премести всички изтрити съобщения (които не са purged) в несъществуваща папка.

За да оправим този проблем е нужно следното, отиваме в Account Settings -> Advanced Account Settings след което избираме tab-a "Deleted Items". Избираме опцията "Mark items to delete but not move them", цъкаме на ок и всичко е наред.

Как работи DNS, част 3 - инсталация на DNS cache сървър.

Преди да прочетете тази статия, би било добре първо да се запознаете със статията: "Как работи DNS, част 1 - Resolvers и Cache сървъри" - линк към блога ми или линк към linux-bg.org.

Преди инсталацията, трябва да решим кой dns сървър да инсталираме. Ето кратък списък с най-разпространените dns сървъри: BIND, djbdns, PowerDNS, MaraDNS, Windows DNS  (Изследване за DNS софтуера ползван в България).

В примерите ще използвам паралелно инсталация и конфигурация на  най-разпространеният dns сървър - BIND, както и този, който използвам и препоръчвам аз - djbdns под Debian.

Инсталация на BIND като cache сървър

В Debian stable (6.x, squeeze в момента) BIND го има на пакет. Инсталираме го:

# apt-get install bind9

Конфигурацията на bind се намира в /etc/bind/ - директорията, като файла се казва named.conf. В Debian този файл е разделен на няколко файла, като във всеки от тях се конфигурират отделни неща. Ето:

# cat named.conf
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

Както се вижда, настройките се правят в няколко отделни файла. Тъй като ние искаме да конфигурираме само cache сървър, файлът който ни интересува е named.conf.options.

# cat /etc/bind/named.conf.options
options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        // forwarders {
        //      0.0.0.0;
        // };

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };

    allow-recursion { 172.20.20.0/24; 172.20.30.3; };

};

С този ред разрешяваме recursive запитвания към dns cache сървъра от мрежата 172.20.20.0/255.255.255.0 както и от IP адреса 172.20.30.3. Съответно - променяте ги на ip/мрежите които ще го ползват като dns cache сървър.

# /etc/init.d/bind9 restart

Вече имате работещ BIND dns cache сървър.

Инсталация на djbdns cache сървър

В Debian stable (6.x, squeeze в момента) djbdns не е включен, но го има в testing/unstable. Ако искате, можете да си направите пакет (http://geroyblog.blogspot.com/2012/09/how-to-install-djbdns-in-debian-squeeze.html), или да го инсталирате от http://cr.yp.to/djbdns.html. Ще разгледаме втория вариант. За целта е нужно да имате следните пакети инсталирани - daemontools (как се инсталира), ucspi-tcp. Следваме инструкциите за инсталация на djb:

# wget http://cr.yp.to/djbdns/djbdns-1.05.tar.gz
# zcat djbdns-1.05.tar.gz|tar xvf -
# cd djbdns-1.05
# echo gcc -O2 -include /usr/include/errno.h > conf-cc
# make
# make setup check

Djbdns пакета съдържа няколко програми, като всяка от която върши определена работа:

tinydns - authoritative dns сървър - udp
axfrdns - authoritative dns сървър - tcp
dnscache - dns cache сървър
както и няколко други които в случая няма да бъдат разяснявани.

Тъй като ще инсталираме dns cache сървър, ще разгледаме dnscache и програмата за конфигуриране, която върви към него - dnscache-conf. Синтаксиса на програмата е следния:

dnscache-conf: usage: dnscache-conf acct logacct /dnscache [ myip ]

където:
acct - нужен е да се създаде потребителски акаунт, с който ще се стартира dnscache;
logacct - нужен е да се създаде потребителски акаунт, с който ще се стартира multilog, който ще записва log - файловете на dnscache;
/directory - в коя директория да бъдат създадени стартиращите/log - файлове на dnscache
myip - на кое IP ще "слуша" dnscache.

# useradd dnscache
# useradd dnslog
# dnscache-conf dnscache dnslog /etc/dnscache 172.20.20.1

Остава да укажем от кои ip/мрежи е разрешен да се ползва dns cache сървърът. Това се прави в директорията /etc/dnscache/root/ip/, като в нея се създават празни файлове с имената на мрежи/ip адреси от които може да се ползва сървъра.

# touch /etc/dnscache/root/ip/127.0.0.1
# touch /etc/dnscache/root/ip/172.20.20

Както следва, dnscache може да се използва от 127.0.0.1 ip адреса и от мрежата 172.20.20.0/24
Остава само да стартираме dnscache. Това става, като направим symbolic link към /etc/services директорията:

# ln -s /etc/dnscache /etc/service/dnscache

# svstat /etc/service/dnscache /etc/service/dnscache/log
/etc/service/dnscache: up (pid 1273) 3 seconds
/etc/service/dnscache/log: up (pid 1277) 3 seconds

Конфигурационната директория на djbdns се намира в /etc/dnscache/env, като всички променливи са в отделни файлове.

# ls -l /etc/dnscache/env/
-rw-r--r-- 1 root root    8 Sep  9  2008 CACHESIZE
-rw-r--r-- 1 root root    8 Sep  9  2008 DATALIMIT
-rw-r--r-- 1 root root   15 Sep  9  2008 IP
-rw-r--r-- 1 root root    8 Sep  9  2008 IPSEND
-rw-r--r-- 1 root root   23 Sep  9  2008 ROOT

По подразбиране CACHESIZE е 1000000 байта, което е твърде малко и трябва да бъде променено на по-голяма стойност в зависимост от свободната памет с която разполагате.
DATALIMIT се използва от програмата softlimit, която ограничава dnscache да използва определен ресурс памет. DATASIZE трябва да е по-голям от CACHESIZE.
ROOT указва в коя директория се намират dns root hints.
IP указва на кой IP адрес ще отговаря dnscache при запитвания.
IPSEND указва от кой адрес да се изпращат рекурсивните заявки.

# echo 134217728 > /etc/dnscache/env/CACHESIZE
# echo 154000000 > /etc/dnscache/env/DATALIMIT

Тези стойности указват 128mb за cache на dns запитванията и 154mb като цяло заделена памет за програмата dnscache. Ако по някакви причини самата програма се опита да заеме повече от тази памет, програмата softlimit ще върне грешка "out of memory".

Остава да конфигурирате PC-то си да използва този DNS, и това е всичко. Вече имаме работещ dns cache сървър.

Кеширането става само в паметта, тоест нищо не се пише по диска, от което следва, че при всяко рестартиране на dns cache сървъра кешираните данни се губят.

Ако искате dnscache сървъра ви да поддържа DNSCurve протокола (предложен от Dan Bernstein), използвайте ето този patch и инструкциите към него: http://shinobi.dempsky.org/~matthew/patches/djbdns-dnscurve-20090602.patch