Время менять корневые разделы...

Переодически, обычно в связи с выходом нового релиза, я переставляю свою систему (моя система - это Gentoo). С одной стороны это полезно для того, чтобы не забыть как это делается. А с другой стороны постоянные обновления всетаки замусоривают систему постепенно. А с третьей стороны - установка системы с нуля, это повод попробовать что нибудь новое.

Система как всегда устанавливается без особых вопросов. Я конечно проделывал это неоднократно, и в хендбук смотрю только для того, чтобы не забыть что нибудь важное. При этом в процесс инсталляции вносятся элементы творчества.

Разбиение дисков у меня особенное. Я честно говоря никогда не видел необходимости отделять boot, usr и var от рута. Их содержимое во многом предсказуемо и на десктопе все они прекрасно размещаются на одном разделе. Эксплуатируя gentoo я вывел для себя следующую схему:

Раздел подкачки располагается у меня в начале диска, ходили слухи, что начало диска работает быстрее. Хотя я думаю что более оптимально располагать раздел подкачки в середине диска, а остальные партиции приближать к разделу подкачки в меру востребованности. Это просто оптимизирует перемещение головок.

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

Сравнительно небольшую партицию - 4-6 гиг я выделяю для /usr/portage. Это позволяет ему не раздуваться, а заодно позволяет использовать его из разных gentoo-систем.

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

Диск у меня небольшой. В этом плане я придерживаюсь такого мнения, что любой объем всеравно когда нибудь кончится, и его придется разгребать. И при выборе диска руководствуюсь больше единовременными потребностями. Мой диск имеет размер 80гиг.

Итак, во второй корневой раздел я залил новую систему. И решил побаловаться с программами мониторинга под KDE. До сих пор я пользовался ksensors, но он помоему древний как KDE1. Я не надеялся что найду что-то идеальное, но к идеалу надо хотя бы стремиться. Программ мониторинга под KDE не много. Помимо указанного выше ksensors можно упомянуть ksim, ksysguard (правда меня мучают сомнения, что ksysguard умеет мониторить датчики lm_sensors) и kima.

Kima - это апплет для панели задач KDE. Умеет мониторить датчики lm_sensors, умеет получать информацию от демона hddtemp и еще среди фич есть мониторинг Thermal Zone CPU. Надо порыть что это за зверь и где собственно стоит. :) Инфрмацию kima отображает непосредственно в панели, во всплывающем окне информации может быть больше.

Хотя конечно на полноценный мониторинг это не тянет, просто информирование пользователя, но выглядит поприятнее чем ksensors. Мониторинг ИМХО должен еще как-то по времени все это отслеживать, тенденции всякие. И вообще, компьютер должен работать.

Многоблирование информации...

Копипастинг зло... все это знают. Грамотные программисты никогда не копируют код просто так. Но даже без явного копипастинга нас окружают многочисленные дублирования информации.

Где-то у меня была прикольная закладочка.. а, вот она - Copy/Paste detector. Но я хотел написать немного о другом.

Начну с того, что мне очень не нравится то, что прототипы функций необходимо выносить в include-файл. По большому счету это просто переписывание. Вполне можно было бы в пределах одного файла разрулить функции на локальные или экспортируемые и вообще отказаться от инклюдов. Во многих языках так и делается. Можно сделать наверное и в си, только тогда это будет уже не си.

Но даже если инклюдить сишники достаточно бессмысленно, то можно генерировать инклюды на основе сишников. :) Логика генерации нужна конечно достаточно наворочанная, но ведь компьютеры и должны работать. Вообще при постановке задачи не стоит думать о технических сложностях с реализацией. Это мешает и ограничивает воображение.

Когда-то файлы библиотек создавались с таким расчетом, чтобы в одном объектном модуле была одна функция. При связывании выполняемого модуля из библиотеки извлекается исключительно то, что необходимо. Но ведь никому не охота для каждой мизерной функции писать отдельный си-файл. Да и не удобно это. Поэтому библиотеки стали набиваться гигазами объектников, неоптимально это. Я тут вынашиваю мысли на тему делить большие сишники на маленькие, компилировать и пихать в библиотеку. Естественно все это должно производиться в автоматическом режиме в процессе сборки. И тестировать модули индивидуально удобнее. Глобальное тестирование неизбежно натыкается на ограничения областей видимости и тд. Но я хотел написать не об этом...

Ковыряюсь тут с одним старым проектом, ошибки исправляю. Хотя весь этот проект представляет из себя одну большую ошибку, которая собирается полтора часа, а функциональности в ней и на 5 минут не наберется. Хотя то, о чем я хочу написать свойственно многим проектам MSVC. Одна из ошибок очень явно это высветила - в одном месте указан старый телефон компании. Начал выяснять где... Для этого пришлось поставить InstallShield, ибо данная информация хранилась в инсталляторе. Телефон больше нигде не хранился, а вот название компании, версия продукта помимо инсталлятора хранится еще и в ресурсах каждого модуля (как я не люблю ресурсы), в диалогах в виде статического текста, иногда в самом тексте программ. Не удивительно что версии везде указаны разные, а название компании в разных формах.

Любую информацию необходимо указывать единожды. Правда я с трудом представляю как это можно сделать в условиях MSVC.

Вот собственно и все, о чем хотел написать.

Абсолютно бесшумный компьютер...

Ну вот и свершилось, на день рождения выпросил в подарок FSP ZEN-400. И последний вентилятор вместе с блоком питания отправился в историю...

Комплект производит очень хорошее впечатление, ну он и стоит 150 баксов :)... Разъемы питания снабжены отжимниками, в комплекте идут липучки для связывание проводов, красота...

Только вот с установкой пришлось повозиться, в корпусе что-то тесно. Чтобы отключить все разъемы мне необходимо выкрутить БП и двигать его туда-сюда. Но старый БП и так необходимо снимать. Хуже оказалось то, что отключиться то он отключился, но вот вытаскиваться абсолютно не захотел, радиатор мешает. Пришлось открутить материнскую плату и двигать туда-сюда ее. Не снимать же радиатор. Пусть даже я поставил его кверхногами и теперь надпись Scythe в нормальном положении системного блока перевернута, о ужас!

Но результат того стоил... Шума вообще никакого не осталось. Винчестер шумит настолько тихо, что даже с открытым корпусом я его слышу только приблизив ухо к месторасположению винта.

Вот интересно, как померять децибелы? микрофоном записывать такой незначительный шум вряд ли получится... Ну да не важно.

А всетаки ksensors - отстойная программа. Оказывается у меня в системе перепутались два температурных датчика, и до сих пор я предполагал что первый датчик показывает температуру CPU, но сопоставив показания ksensors с показаниями sensors из комплекта lm_sensors обнаружил странное расхождение, которое вынудило меня зарыться в /etc/sensors.conf и выяснить что CPU temp - это второй датчик. Но раньше то я не обращал на него особого внимания, и предполагаю что он показывал нечто, болшее 40 градусов... Сейчас он показывает порядка 55-56 под нагрузкой.

И вот еще подумал, существуют ли отдельные комплекты мониторинга состояния компьютера? а то мне явно не хватает датчиков. Мне нужен датчик на БП и на винт желательно тоже... Но пока продолжаю наблюдать за поведением системы. Погода располагает для крэштестов, температура в квартире поднимается до 30 градусов...

Операции над указателями...

Долгая дискуссия заставила призадуматься...

С одной стороны в исходниках gcc я явно обнаружил обмен индекса и указателя, в случае операций с массивами (gcc/gcc/c-types.c):

 if (TREE_CODE (TREE_TYPE (array)) != ARRAY_TYPE
      && TREE_CODE (TREE_TYPE (array)) != POINTER_TYPE)
    {
      tree temp;
      if (TREE_CODE (TREE_TYPE (index)) != ARRAY_TYPE
          && TREE_CODE (TREE_TYPE (index)) != POINTER_TYPE)
        {
          error ("subscripted value is neither array nor pointer");
          return error_mark_node;
        }
      temp = array;
      array = index;
      index = temp;
      swapped = true;
    }

Но загадочности на этом не закончились. На самом деле компилятору действительно пофиг что с чем складывать. указатель с индексом или индекс с указателем, результатом всеравно будет указатель на элемент.

char s[] = "hello"; 
int idx = 3; 
assert (*(s + idx) == 'l' && *(idx + s) == 'l');

Так вот второе выражение смущает меня больше всего.

Понятно что в математике от перемены мест слагаемых сумма не изменяется. Но и простым преобразованием этого объяснить тоже не получается. Попытка сложить два указателя вызовет ошибку компиляции. Модификация указателя всегда производится кратно размеру его элементов. В то время как модификация целого значения всегда кратна единице.

А компилятор, как партизан упорно молчит. Хоть бы варнинг чтоли сделали какой.

Вообще компилятор во многих случаях молчит. Я вот до сих пор считал, что удаление недостижимого кода - это оптимизация. И при компиляции без оптимизации компилятор должен тупо генерить все что написано. Но это оказалось не так.

int i = 10;
if (1) i += 20;
if (0) i -= 30;

$ gcc -O0 -S ...

        movl    $10, -8(%ebp)
        addl    $20, -8(%ebp)

add есть, а вот sub не наблюдаю...

Эта ерунда всплыла у меня когда я тшетно пытался посмотреть код, генерируемый выражениями argc + argv - 1, argv + argc - 1 с помощью BOOST_ASSERT(argc + argv - 1 == argv + argc - 1);. Выражение оказывалось истинным, и BOOST_ASSERT вообще не генерировал никакого кода, не смотря на -O0. Дык он и свертку выполнил безо всякого разрешения.

Может быть у gcc есть какой нибудь волшебный ключик, который позволяет разрешить генерацию недостижимого кода? не знаю точно...