Установка разрешения экрана в grub2 при помощи 915resolution

Когда я был молод и глуп, я извращался с grub-ом, пытаясь получить родное разрешение в консоли linux на своем недобуке. Сейчас, благодаря поддержке KMS в ядре, это нафиг никому не нужно. Но ебанут красноглазым нет покоя! Итак устанавливаем родное разрешение непосредственно для grub-а, чтобы не оскорблять свой ясный взор "замыленными" шрифтами, при выборе вариантов загрузки.
На моем MSI Wind u100 конфиг загрузчика изменился так:

$ diff -urU 4 grub.cfg-old grub.cfg
--- grub.cfg-old        2010-08-19 18:35:57.000000000 +0300
+++ grub.cfg    2010-08-19 18:08:23.000000000 +0300
@@ -36,8 +36,10 @@
 insmod ext2
 set root='(hd0,msdos1)'
 search --no-floppy --fs-uuid --set d38f73d1-1c4b-4854-b640-4d80bd808903
 if loadfont /usr/share/grub/unicode.pf2 ; then
+  insmod 915resolution
+  915resolution 41 1024 600
   set gfxmode=1024x600
   load_video
   insmod gfxterm
 fi

В debian-е для этого мне понадобилось изменить 2 файла: /etc/default/grub и /etc/grub.d/00_header (я слышал за это могут и руки оторвать).
И да, перед экспериментами лучше запастись чем-нибудь вроде загрузочной флэшки, так как есть вероятность получить незагружаемую систему.

В итоге:

(как обычно, фотографировал на калькулятор)

Usbmount - автоматическое монтирование флешки

В современных linux-дистрибутивах автоматическое монтирование флешек успешно реализуется с помощью HAL (или что-там-теперь-будет-вместо-него) и DE. Те бедолаги, которые не пользуются KDE/GNOME, в качестве альтернативы, могут выбрать halevt (HAL-озависимый) или autofs (его конфиги явно не самые дружелюбные).
Отдельные умники пишут свои, порой довольно изощренные, наборы правил для udev (правда сами разработчики udev предостерегают от такого подхода). А наиболее ортодоксальные линуксоиды, возможно, все еще используют записи в fstab, наизусть помнят все опции mount, при этом брезгливо косятся в сторону HAL …и выгребают ряд проблем при одновременном подключении нескольких флешек, или при подключении незнакомых флешек с причудливыми таблицами разделов; и вообще ни про какое автоматическое монтирование здесь речь уже не идет.
Оказывается, в сторонке, довольно давно, стоит готовый велосипед под названием usbmount (http://usbmount.alioth.debian.org/). По сути это все те же скрипты, запускаемые через udev. Одновременное подключение флешки и телефона с 2-мя разделами прошло гладко. В общем, закомментировал пережитки прошлого в fstab (хотя usbmount его вполне уважает), и, надеюсь, забыл про монтирование флэшек на ближайшие несколько лет (хотя стоп! тут же exFAT наступает).

(Не)надежность master-master репликации в mysql

Перед нами встала задача обеспечить быструю и надежную работу клиентов с одной базой данных на 2-х географически удаленных объектах. В качестве одного из вариантов рассматривалась работа с 2-мя mysql серверами, которые бы реплицировались по принципу master-master. Далее рассматривается (не)надежность такой системы при одновременном изменении одних и тех же данных.

Настроим master-master репликацию (о том как это делается можно узнать из статей об основах репликации и мульти-мастер репликации).

Проведем небольшой эксперимент. Создадим таблицу
сервер1:
mysql> CREATE TABLE `new_table` (
`field1` varchar(32),
`field2` varchar(32),
`field3` varchar(32)
);
и внесем в нее начальные данные
сервер1:
mysql> SELECT * FROM new_table;
+--------+--------+--------+
| field1 | field2 | field3 |
+--------+--------+--------+
| value0 | value0 | value0 |
+--------+--------+--------+

После того как мы убедимся что БД реплицируется в обе стороны, разорвем соединение между серверами и изменим одну и ту же запись таблицы одновременно на обоих серверах.
сервер1:
mysql> UPDATE new_table SET field1='value1', field2='value1';
mysql> SELECT * FROM new_table;
+--------+--------+--------+
| field1 | field2 | field3 |
+--------+--------+--------+
| value1 | value1 | value0 |
+--------+--------+--------+
сервер2:
mysql> UPDATE new_table SET field2='value2', field3='value2';
mysql> SELECT * FROM new_table;
+--------+--------+--------+
| field1 | field2 | field3 |
+--------+--------+--------+
| value0 | value2 | value2 |
+--------+--------+--------+

После возобновления соединения и синхронизации серверов вырисовывается следующая картина:
сервер1:
mysql> SELECT * FROM new_table;
+--------+--------+--------+
| field1 | field2 | field3 |
+--------+--------+--------+
| value1 | value2 | value2 |
+--------+--------+--------+
сервер2:
mysql> SELECT * FROM new_table;
+--------+--------+--------+
| field1 | field2 | field3 |
+--------+--------+--------+
| value1 | value1 | value2 |
+--------+--------+--------+
Наблюдаем нарушение целостности данных и различия в репликах.

Альтернативные методы решения поставленной задачи можно найти в комментариях к вышеуказанным статьям (например, настройка master-slave репликации с использованием mysql-proxy или использование Multi-Master Replication Manager).

Проверка UMTS-оператора в chatscript-е

Подключаюсь к ОГО безлимит-мобильный, в котором безлимит - при регистрации в сети Utel, и помегабайтная оплата в роуминге Киевстар после превышения 40Мб лимита. Естественно есть желание проверять, в сети какого оператора зарегистрировался модем. Виндовая версия Utel-овской приблуды отображает оператора в статус-баре, линуксовую версию (найденный на просторах сети Mobile Partner) устанавливать не стал.

Подключаюсь при помощи pppd и chat. На одном буржуйском сайте, был найден список AT-команд, где есть такое:

Command: AT+COPS?,
Response: +COPS: (<mode>,[<format>,<oper>[,<act>]]),…, (<moden>,[<formatn>,<opern>[,<actn>]])
Description: Get/set current GSM/UMTS network operator, list available operators. This can be used to change for example access type and switch network.

Example:

AT+COPS=?
+COPS: (2,”3″,”3″,”24004″,2),(1,”3″,”3″,”24008″,0),(3,”Sweden 3G”,”Sweden3G”,”2)


Воспользовавшись этой информацией можно написать свой chatscript:


'' ATZ
OK-AT-OK "AT+COPS=?" UTEL3G ''
OK-AT-OK AT+CGDCONT=1,"IP","unlim.utel.ua"
OK-AT-OK "ATDT*99***1#"
CONNECT ''
'' \d\c