Установка всех компонентов в режиме непривилегированного пользователя / Денис Каледин

Если при выполнении шагов, описанных в Главе 5, вы будете зарегистрированы в системе как root, есть вероятность, что некоторые файлы системы будут заменены файлами, которые будут скомпилированы в Главе 5. На это есть ряд причин, неопределенная переменная $LFS – одна из них. Замена файлов на вашей системе скорее всего приведет к возникновению всякого рода проблем, поэтому рекомендуется выполнять шаги Главы 5 от имени непривилегированного пользователя. Для чистоты эксперимента создадим новую учетную запись «lfs», которую будем использовать на стадии компиляции со статическими ссылками. Для добавления новой учетной записи, выполните следующие команды в режиме пользователя root:

useradd -s /bin/bash -m lfs && passwd lfs

Теперь скорректируем права на директорию $LFS/static, чтобы пользователь «lfs» имел к ней доступ на запись:

chown -R lfs $LFS/static

Теперь войдите в систему под учетной записью «lfs». Это можно сделать двумя способами: через новую виртуальную консоль или оконный менеджер, или командой su – lfs. После этого выполните следующие команды от имени пользователя «lfs» для создания благоприятной среды:

cat > ~/.bash_profile << «EOF» umask 022 LFS=/mnt/lfs LC_ALL=POSIX CC='gcc -s' export LFS LC_ALL CC EOF source ~/.bash_profile

Этот профиль устанавливает umask равным 022, чтобы созданные файлы и директории автоматически получали правильные права. Настоятельно рекомендуется использование этой установки на протяжении всей инсталляции LFS. Также были заданы переменные $LFS, $LC_ALL, и $CC. Про переменную $LFS мы уже не раз говорили. Переменная $LC_ALL используется для интернационализации.

Если на вашем базовом дистрибутиве установлена библиотека glibc версии 2.2.4 и ранее, и на протяжении Главы 5 переменная $LC_ALL определена не как "C" или «POSIX», могут возникнуть проблемы при выходе повторном входе в среду chroot в Главе 6. Для того чтобы быть уверенным в том, что в среде chroot все будет работать корректно, присвойте этой переменной значение «POSIX» ("C" is an alias for «POSIX»).

Использование переменной $CC вызвано необходимостью предотвратить компиляцию отладочных символов в статические пакеты. Таким образом экономится дисковое пространство и существенно сокращается время компиляции.

1.8.39. Заземляющие устройства / Валентин Викторович Красник

Вопрос 156. Каков общий объем проверки заземляющих устройств?

Ответ. В данный объем проверок входит:

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

проверка цепи между заземлителями и заземляемыми элементами. Следует проверить сечения, целостность и прочность проводников, их соединений и присоединений. В заземляющих проводниках, соединяющих аппараты с заземлителем, не должно быть обрывов и видимых дефектов. Надежность сварки проверяется ударом молотка (п. 2);

проверка состояния пробивных предохранителей в электроустановках до 1 кВ. Пробивные предохранители должны быть исправны и соответствовать номинальному напряжению электроустановки (п. 3);

проверка цепи фаза-нуль в электроустановках до 1 кВ с системой TN. Проверка производится одним из следующих способов:

непосредственным измерением тока однофазного замыкания на корпус или нулевой защитный проводник;

измерением полного сопротивления цепи фазанулевой защитный проводник с последующим вычислением тока однофазного замыкания (п. 4);

измерение сопротивления заземляющих устройств. Значения сопротивления заземляющих устройств с подсоединенными естественными заземлителями должны удовлетворять значениям, приведенным в табл. 1.8.38 (п. 5);

измерение напряжения прикосновения. Напряжение прикосновения измеряется в контрольных точках, в которых эти значения определены расчетом при проектировании (п. 6).

Таблица 1.8.38

Наибольшие допустимые значения сопротивлений заземляющих устройств

* расчетный ток замыкания на землю;

** Соответственно при линейных напряжениях 660, 380 и 220 В;

*** Полный ток замыкания на землю.

1.3. Обзор модели зрелости процессов разработки / Владимир Рябикин

Хотя зачастую инженеры-разработчики и менеджеры хорошо осведомлены о своих проблемах, их взгляды на то, какие усовершенствования являются наиболее важными, могут быть различными. Без организованной стратегии усовершенствования трудно достичь согласия между профессионалами-разработчиками и руководством по вопросу, какие именно работы по усовершенствованию следует выполнять первыми. Для того чтобы усилия по усовершенствованию процессов принесли долговременные результаты, необходимо разработать эволюционный путь развития, поэтапно увеличивающий зрелость производственного процесса организации. Концептуальная структура зрелости производственного процесса [Humphrey 87a] упорядочивает эти стадии таким образом, что усовершенствования на каждой предшествующей стадии являются фундаментом усовершенствований последующей стадии. Таким образом, стратегия усовершенствования, предлагаемая концептуальной структурой зрелости производственного процесса, обеспечивает наиболее прямой путь постоянного улучшения производственного процесса. Эта стратегия призвана руководить усовершенствованиями и выявлять недостатки организации; она не предназначена для быстрого «латания дыр» неудачного проекта.

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

Многоуровневая структура CMM основывается на принципах обеспечения качества продукта, выработанных за последние шестьдесят лет. В начале тридцатых Валтер Шеварт (Walter Shewart) опубликовал работу, в которой изложил принципы статистического контроля качества. Его идеи были развиты, а их успешное применение было продемонстрировано в работах В. Эдвардса Деминга (W. Edwards Deming) [Deming 86] и Джозефа Джурана [Juran 88, Juran 89]. Эти принципы были развиты институтом SEI в виде концептуальной структуры зрелости процессов, формирующей управленческий и инженерный фундамент для количественного контроля над производственным процессом, что является основой для его непрерывного усовершенствования.

Структура зрелости процессов, в которую вошли эти принципы качества, была впервые намечена Филиппом Кросби в его книге «Quality is Free» [Crosby 79]. Сетка зрелости управления качеством, приведенная Кросби, описывает пять эволюционных фаз во внедрении системы управления качеством. Эта структура зрелости была адаптирована для производственного процесса Роном Радиком (Ron Radice) и его коллегами, работающими под руководством Уотса Хэмфри (Watts Humphrey) из компании IBM [Radice 85]. Хэмфри предложил свою структуру зрелости SEI в 1986 г., добавив концепции уровней зрелости и разработав основу для их текущего использования в программной отрасли.

Ранние версии структуры зрелости процессов разработки, предложенные Хэмфри, описаны в технических отчетах SEI [Humphrey 87a, Humphrey 87b], статьях [Humphrey 88] и в его книге «Managing the Software Process» [Humphrey 89]. Предварительный опросный лист для выявления уровня зрелости [Humphrey 87b] был выпущен в 1987 г. в качестве инструмента, позволяющего организациям определить уровень зрелости их производственных процессов. Для получения характеристик зрелости программного процесса в 1987 г. были разработаны методы внутренней и внешней оценки производственного процесса. Начиная с 1990 г., институт SEI с помощью многих энтузиастов из правительственных и отраслевых структур еще более развил и усовершенствовал эту модель, основываясь на опыте нескольких лет совершенствования производственных процессов.

12 / А. Лущанов

Это предупреждение опубликовано с разрешения CIAC и Кевина Обермана. CIAC настояла на публикации следующего заявления:

«Этот документ был подготовлен в результате работы агентства Правительства Соединенных Штатов. Ни Правительство США, ни университет Калифорнии, ни один из служащих этих институтов не несет никаких гарантий, специальных или предполагаемых, и не принимает на себя никаких законных обязательств и никакой ответственности за точность, полноту или пригодность любой информации, приборов, продукта или описания процесса, и не гарантирует, что их использование не станет нарушением закона о частной собственности. Имеющиеся ссылки на любые специальные коммерческие продукты, процессы или услуги, обозначенные торговым именем, торговой маркой, названием производителя или как-либо иначе, не обязательно являются или требуют их подтверждения, рекомендации или предпочтения Правительством Соединенных Штатов или университета Калифорнии. Точка зрения и мнение авторов не обязательно являются или выражают точку зрения или мнение Правительства Соединенных Штатов или университета Калифорнии, и не могут быть использованы в целях рекламы или поддержки какой-либо продукции».

(обратно)

Использование конструкции while(true) / Джесс Либерти

В качестве условия, проверяемого при переходе на очередную итерацию цикла, может выступать любое выражение, корректное с точки зрения синтаксиса языка C++. Цикл выполняется до тех пор, пока это выражение истинно. Для организации так называемых бесконечных циклов в качестве такого выражения применяется логическая константа true. Листинг 7.5 демонстрирует пример бесконечного цикла, выполняющего счет до десяти.

Листинг 7.5. Еще один пример использования оператора while

1: // Листинг 7.5.

2: // Пример "бесконечного" цикла

3:

4: #include <iostream.h>

5:

6: int main()

7: {

8:    int counter = 0;

9:

10:   while (true)

11:   {

12:     counter++;

13:     if (counter > 10)

14:       break;

15:   }

16:   cout << "Counter: " << counter << "\n";

17:   return 0;

18: }

Результат:

Counter: 11

Анализ: Понятно, что условие продолжения цикла, заданное в строке 10, будет выполняться всегда. В теле цикла (строка 12) значение переменной counter увеличивается на единицу. Работа цикла продолжается до тех пор, показначение counter не превысит 10. Выполнение цикла прерывается оператором break в строке 14, и на экран выводится значение переменной counter (строка 16).

Несмотря на то что данная программа работает, ее структуру нельзя назвать оптимальной. Это типичный пример некорректного использования оператора while. Правильным решением была бы организация проверки значения counter в условии продолжения цикла.

Гибкий синтаксис языка C++ позволяет решить одну и ту же задачу множеством различных способов. Поэтому важно научиться выбирать средство, наиболее подходящее в конкретной ситуации.