Audacious. Проблема с кириллицей в плейлисте

Столкнулся с тем, что информация из mp3-тэгов в плейлисте проигрывателя Audacious отображается некорректно. Проблема наблюдается в том случае, если тэги записаны в кодировке cp1251. Но есть решение: В параметрах проигрывателя выбрать раздел "Список воспроизведения". "Язык для автоматического определения кодировки" из выпадающего одноимённого списка не выбирается, но ниже есть поле "Кодировка по умолчанию". В это поле вписываем utf-8, Windows-1251; закрываем параметры, пересоздаём список воспроизведения. Нужный результат достигнут! Система Ubuntu 11.10 x64, LXDE, Audacious 2.4.4

MATE в ubuntu 12.04

Увидел новость, что вышла ubuntu 12.04. Сам в свое время перешел на Centos потому, что Gnome в ubuntu обновился до 3-й версии, а она мне совсем не понравилась. Пробовал CInnamon - тоже не то, и ресурсов надо поболее чем для второго гнома. Но 12 убунта будет LTS, поэтому очень хотелось бы использовать именно ее. Так возникла идея поставить на нее второго гнома. Точнее MATE.

Сам MATE был взят из репозиториев Linux Mint. Возникли определенные трудности, поэтому опишу свои действия.

Сначала добавляю репозиторий и обновляю систему

add-apt-repository 'deb http://packages.linuxmint.com/ lisa main upstream import'

apt-get update

Тут я получил сообщение, что нет ключа GPG от Linux Mint, поэтому добавил его сам

apt-key adv --recv-key --keyserver keyserver.ubuntu.com 3EE67F3D0FF405B2


Обновился нормально. Следом устанавливаю сам MATE

apt-get install mint-meta-mate

Это как бы все. После перелогина в списке появляется пункт с MATE. Но появился побочный эффект: перестали запускаться некоторые приложения, например software-center. Случилось это из-за того, что установка приложения из Linux Mint изменила данные в файле /etc/lsb-release. Его содержимое должно быть таким:


DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=Precise
DISTRIB_DESCRIPTION="Ubuntu 12.04"

wine on x64

Когда не работает wine под 64-битной системой

$ wine
bash: /usr/bin/wine: No such file or directory

решением является переустановка ELF загрузчика:

$ sudo apt-get install --reinstall libc6-i386

via Romy4

Ограничения стека протокола TCP/IP в Windows

Здесь нет никакого открытия, так что инфа из серии “спасибо кэп”, но до сих пор приходится сталкиваться с вопросами, почему в хрюше ака Windows XP перестает работать интернет или бродилка, при большом числе одновременных закачек ftp, или тем более работе торрент клиента.

Дело в том, что у Windows XP SP2 имеются ограничение на число одновременных сессий tcp (а точнее сессий согласования TCP half-open), установленное в режим 10. Сделано это было мелкомягкими умышленно, для ограничения распространения червяков и дос-атак, которые с выходом Windows XP расцвели буйным цветом, и в первоначальной версии Windows XP этого ограничение отсутствовало, но мелкомягкие посчитали, по своей обычной традиции, что нет смысла бороться за живучесть системы, и проще зарезать число конкурирующих сессий.  Причем в XP это реализовано на уровне системного файла TCPIP.SYS, который необходимо патчить с помощью программы: EventID 4226 Patcher Version 2.23d , которая увеличит это число до 50.

Для того чтобы увеличить до максимума число возможных сессий в виндовой сетке, следует сделать следующее: запустить глобальные политики CTRL+R -> gpedit.msc ->Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Параметры безопасности -> Интерактивный вход в систему -> выставляем его в 0 (отключение ограничения)
или же внести правки в следующий ключ реестра:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\CachedLogonsCount,
изменив значение CachedLogonsCount на 50 или 0.

В Vista SP2 и Windows 7 это ограничение уже было убрано из драйвера протокола, но в системе имеется ограничение на использование сетки для шаринга и печати, установленное в 20 соединений. Проверить это можно, вбив в dos-promt  (CTRL+R -> cmd) команду net config server, которая выведет максимальное число пользователей.

Максимальное число входящих подключений к IIS, которое можно настроить через ключ реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpNumConnections (тип: DWORD, задав его от 5000 до 65536).

via anchous

Проблема с Symantec System Console

На одном из контролеров домена (они же являются первичными серверами Symantec Antivirus для подразделений) запускаю Symantec System Console, но не могу разблокировать группу серверов. Логин/пароль правильные. Консоль рисует ошибку типа "Can't connect bla-bla-bla".
Перепробовал и рестарт службы Symantec Antivirus, и рестарт самого контролера - ничего не помогает. Оказывается, надо в ветке реестра HKEY_LOCAL_MACHINE\SOFTWARE\Intel\LANDesk\VirusProtect6\CurrentVersion\ScsComms\LocalData в ключе LoginCaCertIssueSerialNum сбросить значение в "1" и рестартовать службу Symantec Antivirus.
Толкового объяснения по этому поводу у Symantec не нашёл.

Pidgin - mail.ru agent. Fedora16-x64

Пакет для Pidgin, чтобы Mail.ru агент работал.

mrim-prpl-0.1.28-2.fc16.R.x86_64.rpm Fedora 16 Download Mirrors

Установка программ групповыми политиками

Надысь возникла задача привести к единой версии используемое в рабочей сети ПО.

Решил начать с малого - Adobe Reader и Firefox, ибо версий этих продуктов в политиках ограниченного запуска программ прописано очень много.

Поскольку админы - существа не просто ленивые, а очень ленивые, то решил переложить задачу распростаранения ПО на юзвергские машины на хрупкие плечи групповой политики.

Придумано - сказано - сделано!

Создал сетевой ресурс (шару) на доступном сервере, выложил туда msi-пакеты, создал объект групповой политики, который будет отвечать за распространение ПО, привязал его к нужным подразделениям в Active Directory, прописал хэши исполнимых файлов в политике ограниченного запуска программ. Вроде готово. Но заработало не всё и не сразу.

Вот нюансы, которые следует учитывать при планировании и разворачивании групповой политики распространения ПО:

1. При создании сетевого ресурса к разрешениям и безопасности надо добавлять группу “Компьютеры домена”.
2. При указании пути во время создания установочного пакета в политике имя сетевой путь к серверу следует указывать не по ip-адресу, а по полному имени сервера (FDQN), то бишь не \\192.168.0.1\шара\папка\пакет.msi, а \\сервер.имя.домена\шара\папка\пакет.msi.
3. Дистрибутив Firefox поставляется производителями в виде exe-файла. msi-пакет брал тут - http://www.frontmotion.com/Firefox/download_firefox.htm.
4. С дистрибутивом Adobe Reader ситуация сложнее. Решил поставить самую-пресамую последнюю версию на сегодняшний день. msi-пакет брал у производителя - ftp://ftp.adobe.com/pub/adobe/reader/win/10.x/10.1.0/ru_RU/AdbeRdr1010_ru_RU.msi. На сегодняшний день самая последняя русская версия - 10.1.0. Заодно скачал пакет обновлений до версии 10.1.2 - ftp://ftp.adobe.com/pub/adobe/reader/win/10.x/10.1.2/misc/AdbeRdrUpd1012.msp. Теперь немного магии командной строки:

msiexec /a <путь к пакету msi>\AdbeRdr1010_ru_RU.msi

Этой командой создаём административную установку. Соглашаемся, на вопрос о пути указываем путь к папке, которая выступает сетевым ресурсом (например, d:\Distribute\Adobe_Reader\).

msiexec /a <путь к пакету msi из каталога административной установки>\AdbeRdr1010_ru_RU.msi /p <путь к пакету msp>\AdbeRdrUpd1012.msp

Этой командой применяем патч-обновление до версии 10.1.2
5. Рекомендую перед разворачиванием политики распространиения ПО на весь домен протестировать её на отдельно взятом подразделении. У меня “хомячками” были ребята из техподдержки :) .

Вот и всё.
Про обновление установленного ПО напишу после того, как сам распространю обновления.

Кросспост из моего ЖЖ.

---