WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 | 2 || 4 | 5 |   ...   | 11 |

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

Если система предназначена для решения комплекса типовых задач (например, WWW-сервер + почта + межсетевой экран), под каждую из них находится готовое решение, с большей или меньшей степенью удовлетворяющее потребителя. Поэтому нет необходимости в том, чтобы администратор имел квалификацию разработчика.

Как правило, обслуживание таких систем — также комплекс типовых действий оператора, не требующий, за редким исключением, квалификации администратора. В этом случае удобна «шаблонная» организация интерфейса (например, в виде кнопок и меню), ориентированная на выбор готового решения из множества. «Конструктивная» же организация интерфейса (например, изменение файла настроек), напротив, неудобна, так как ориентирована на самостоятельную постановку и решение задачи.

Обычные методы организации «шаблонного» интерфейса: Webmin, LinuxConf, DrakX и т. п. созданы, по всей видимости, по единой схеме замены действий администратора их наглядным представлением. Следствием такой схемы обычно является жёсткая привязка интерфейса к реальным элементам управления. Каждое дополнение такого продукта функциональностями требует повторения процесса разработки и интеграции их в готовую программу. Всё это приводит к очень негибкой, целиком зависящей от коллектива разработчиков структуре.

Цель проекта Alterator — создание полностью открытого инструмента, который позволит перевести на пользовательский уровень процедуру настройки и сопровождения типовых решений на основе UNIXподобной ОС и её служб. Задача проекта — упростить процедуру разработки таких решений на всех стадиях, от формирования пользовательской модели и создания интерфейса до задания команд, непосредственно управляющих системой.

Для этого в проекте предусмотрено разделение потока управления на уровни: горизонтальные (интерфейс—модель—реализация) и вертикальные (соответственно задачам). Каждый элемент такой сетки — отдельная программа, получающая данные со стандартного ввода и/или в командной строке.

Горизонтальное деление предполагает, что модели среды и языки представления данных и заданий на всех уровнях различны и соответствуют терминологии, используемой, соответственно, дизайнером, оператором и системным программистом. Верхний уровень (модель представления, язык LOO) заведует тем, как объекты и действия над ними отображаются в конкретном варианте GUI. Центральный уровень (пользовательская модель, язык WOO) соответствует задаче в терминах «неподготовленного пользователя». Нижний уровень (модель реализации, язык HOO) реализует конкретные действия над системой и её объектами, которые надо произвести для решения задачи.

Вертикальное деление предполагает, что любая WOO-команда может обрабатываться сразу несколькими обработчиками-трансляторами WOO в HOO (commander), каждый из которых использует только необходимую часть передаваемого WOO-объекта. Для этого они регистрируют типы обрабатываемых WOO-объектов и команд в интегрирующем модуле (chooser).

Неизбежные при этом конфликты в результирующем потоке HOOкоманд разрешаются при помощи упорядочивания по зависимостям формальной проверки на непротиворечивость. Стоит отдавать себе отчёт, что обратное преобразование (низкоуровневого HOO в высокоуровневый WOO) далеко не всегда возможно, однако каждый commander может сделать некоторые предположения на основании результата работы всей очереди HOO-команд и знания породившей её WOO-команды.

Для унификации интерфейса HOO-команд используется AdmFS, виртуальная файловая система, верхняя половина которой — стандартное файловое API, а нижняя — вызов соответствующей программыhook, которая и производит специфические для конкретной операционной системы действия.

Таким образом, компоненты к Alterator можно разрабатывать на любом языке программирования. Для этого достаточно соблюдать текстовые протоколы управления WOO и HOO, использовать интерфейс командной строки, файловое API.

Добавление очередной функциональности (новый commander) в Alterator не требует изучения внутренности других commander’ов, достаточно соблюдения протоколов WOO и HOO. Добавления дополнительных системных (hook) и интерфейсных (look) модулей может вообще не потребоваться, и в любом случае их можно разрабатывать независимо друг от друга.

Наконец, разделение по уровням позволяет адаптировать Alterator к конкретной версии операционной системы, изменяя один только уровень hook (под AdmFS), а к конкретному внешнему виду — только уровень look (над chooser).

Необходимые для Alterator механизмы были частично реализованы в пилотном проекте «ИВК Кольчуга».

13:00–13:Дмитрий Левин Москва, ALT Linux Проект: ALT Linux Team hasher: технология безопасной сборки пакетов Аннотация:

Рассматривается задача безопасной воспроизводимой сборки пакетов в большом репозитории на примере Sisyphus, изучаются требования, накладываемые этой задачей на архитектуру системы сборки, рассматривается архитектура hasher’а и существенные моменты её реализации. Приводятся примеры производных решений на базе hasher’а.

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

Со временем инструментальные дистрибутивы выросли в размере, увеличилось число принимающих участие в разработке дистрибутивов, и в результате сборка дистрибутива в хост-системе стала небезопасной, ненадёжной и неудобной.

Требования к сборочной технологии Технология сборки элементов дистрибутива (пакетов) должна:

• не снижать уровень безопасности хост-системы;

• обеспечивать собственную безопасность от атак со стороны пакетов;

• обеспечивать безопасность сборки пакетов от атак со стороны других пакетов;

• гарантировать надёжность (воспроизводимость) результатов сборки;

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

Архитектура hasher’а В основе архитектуры hasher’а лежит трёхпользовательская модель:

вызывающий непривилегированный пользователь (C) и два непривилегированных вспомогательных псевдопользователя; первый (R) играет роль root в порождаемой сборочной среде, второй (U) — обычного пользователя, собирающего программы.

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

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

Путь пакета через сборочную систему в общих чертах выглядит следующим образом:

1. Пользователь C порождает среду (aptbox) для работы с apt.

2. Полностью удаляется сборочная среда, возможно оставшаяся от предыдущей сборки. Удаление происходит последовательно в chroot пользователем U, в chroot пользователем R и, наконец, пользователем С.

3. Пользователь C создаёт каркас новой сборочной среды, состоящий из вспомогательных каталогов и вспомогательных статически слинкованных программ (ash, find и cpio). С помощью вспомогательной привилегированной программы создаётся фиксированный набор устройств, достаточный для нормального функционирования сборочной среды и при этом не несущий угрозы host-системе.

4. Порождается базовая установочная среда, представляющая собой набор средств, необходимых для штатной установки пакетов в эту среду. Пользователь C с помощью apt определяет набор пакетов, необходимых для порождения базовой установочной среды. Пользователь R с помощью вспомогательных статически слинкованных программ распаковывает эти пакеты.

5. Порождается базовая сборочная среда, представляющая собой набор средств, необходимых для сборки любого пакета.

Пользователь C с помощью apt определяет набор пакетов, пользователь R устанавливает их.

6. Порождается сборочная среда для данного пакета. Пользователь U извлекает сборочные зависимости пакета, пользователь C с помощью apt определяет набор пакетов для установки, и пользователь R устанавливает их.

7. Пользователь U осуществляет сборку пакета.

Такая схема призвана исключить атаки вида UR, UC, RC, а также все виды атак на root.

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

С помощью средств apt реализована возможность использования собранных ранее пакетов для сборки последующих пакетов.

beehive: распределённая сборка с помощью hasher’а.

Благодаря свойству воспроизводимости результатов сборки hasher можно использовать для параллельной сборки большого числа пакетов на нескольких серверах. Таким образом удаётся достичь разумного времени сборки при средних вычислительных ресурсах. Открывается возможность организовать регулярное тестирование на пересобираемость большого репозитория пакетов, что и было сделано на примере Sisyphus с помощью средства параллельной сборки beehive.

30 июля Утреннее заседание 10:00–11:Секция (Председатель — Александр Боковой) 10:00–10:Дмитрий Тараканов Москва, Intel Разработка эффективных приложений для r процессоров семейства Intel© XScaleTM Аннотация:

Доклад посвящён основным характеристикам, возможностям и преимуществам процессоров семейства XScaleTM. Будут приведены данные тестирования производительности процессоров семейства XScaleTM и других процессоров.

R Рынок для процессоров Intel© XScaleTM. Процессоры семейства PXA2xx для карманных устройств:

• RISK архитектура;

• Высокая производительность — частоты до 600Mhz;

• Низкое потребление;

• Интерфейс с видео/фото камерами ;

• Полная линейка процессоров для решений разного уровня;

• Объединение коммуникационной и вычислительной функциональности;

• Портирование приложений традиционных для десктопа на карманные устройства.

Архитектура ARM*:

• 16 32-битных регистра общего назначения • 4Гб адресного пространства • Байтная адресация • 8/16/32 битные инструкции чтения записи • Требуется выравнивание данных • Упрощённый набор команд • 32-битные опкоды, выравненные на 32 бита • Вся арифметика 32-битная целая • Нет FPU, нет деления, нет call/return, нет стека • Дополнительные команды доступны через сопроцессоры MMU/MPU, cache control, FP, DSP etc.

Сравнение XScaleTM vs. P4;

Среда разработки: Windows* 2000/XP R Целевые процессоры: Intel© PXA25x/26x R Следующие поколения процессоров Intel© XScaleTM Целевые ОС:

Windows* CE 3.0/.NET Symbian* OS Palm* OS R Библиотеки поддержки: Intel© IPP Поддержка приложений сторонних разработчиков: ARM ADS Microsoft* Windows* CE.NET Platform Builder / eMbedded* Visual C++* GNU R Почему рекомендуется использовать компилятор Intel© Разработан производителем процессора:

R • Полная поддержка микроархитектуры Intel© XScaleTM • Получение оптимизированного кода • Первоочередная поддержка новых особенностей аппаратуры • Совместим с компилятором Microsoft* C++ compiler R • Приложения Intel© дополняют и развивают приложения Microsoft для MS Platform Builder (разработка систем) для MS eMbedded Visual C++ (разработка приложений) R • Intel© C++ compiler может быть легко выключен/включён.

Совместим с компилятором Microsoft По синтаксису опций, например:

{1|2|3}— установка уровня оптимизации;

/Zi— создание отладочной информации;

По синтаксису прагм, например:

#pragmaoptimize("[optlist]",{on | off} ) R Компилятор Intel© запускает компилятор Microsoft для генерации файлов PCH для просмотра исходных текстов (source browser).

Возможность смешивания объектных модулей Intel и Microsoft*;

Объектный формат совместим с Microsoft*; Компоновка прикладных объектов с библиотеками MS*;

• Поддержка режима Thumb компании ARM* (16-бит) • Включение в проекте ARM: опция/Q_cgopt=thumb • Полностью Thumb проект: создаётся обычным путём в eMbedded Visual C++ • Нет необходимости прикомпоновывать специальную библиотеку • Доступен для Microsoft Windows CE.NET • Предоставляется дополнительная оптимизированная библиотека run-time • Быстрая эмуляция операций FP, целочисленное деление • Оптимизированные версии strcmp, strcpy • Замещает стандартные библиотеки MS* Top 5 полезных советов:

1. Исправьте ошибки перед тем как начинать оптимизацию.

2. Используйте компилятор Intel! • Лучшие run-time библиотеки.

• векторизация и оптимизация.

• Помогите компилятору! 3. Используйте VTune для анализа производительности и поиска узких мест! 4. Оптимизируйте использование кэша! • Кэш-промах стоит 150 циклов.

• Используйте preload() (works on ARM, too).

• Advanced: XScaleTM имеет дополнительный mini cache и позволяет замораживать данные в кэше.

5. Ручная оптимизация критических мест.

• Используйте DSP-расширения, iMPT, WMMX.

• Оптимизируйте ветвления.

• Оптимизируйте циклы.

6. Используйте оптимизированные IPP/GPP библиотеки.

10:25–10:Никита Винокуров Москва, IBM Восточная Европа/Азия, Центр компетенции Linux Linux on POWER Аннотация:

Цели, ближайшие перспективы и проблемы развития ПО с открытым исходным кодом и ОС Линукс в частности на платформе PowerPC.

Взгляды компании IBM на процесс портирования и использования ОС Линукс на PowerPC. Особенности архитектуры PowerPC.

Взгляд IBM на развитие Linux on Power Технология POWER присутствует на рынке уже более 13 лет и используется в промышленной эксплуатации среди 64-битных серверов с 1994 года. Linux — это зрелая, защищённая и проверенная операционная система. Фактически — это самая быстрорастущая операционная система, поддерживаемая сегодня на серверах.

IBM продолжает фокусировать свои действия на помощи клиентам в переходе на открытые ИТ-системы, помогая им снизить стоимость их владения. Использование POWER-архитектуры простирается от игровых приставок до суперкомпьютеров. IBM активно участвует в усилении Linux-on-Power как надёжной, открытой и мощной вычислительной платформы.

Поддержка разработчиков Компания IBM, продвигая Power как более быструю и надёжную платформу для запуска Linux-приложений нежели Intel, заинтересована в том, чтобы разработчики портировали свои приложения с IntelLinux и Windows архитектур на PowerPC+Linux и всячески поддерживает этот процесс. Например, организован форум разработчиков, осуществляющих миграцию, который также поддерживается разработчиками из Linux Technology Center компании IBMhttp://linuxppc.org. В регионах работают центры инноваций, включённых в программу тестирования Linux-приложений на технике IBMhttp://www.developer.ibm.

com/spc/, помогая разработчикам ПО тестировать свои приложения без покупки техники.

Линейка продуктов Вычислительные системы, основанные на архитектуре PowerPC, представлены на рынке в виде двух линеек серверов eServer: iSeries и pSeries. Эти две серии машин используют, фактически, один тип процессора — Power4. Различаются они только лишь позиционированием на рынке и способностью организовывать логические разделы (LPAR).

Сейчас появились новые версии машин iSeries, работающих на Power5.

Дистрибутивы В данный момент, основными дистрибьюторами ОС Linux, которые заявили о поддержке платформы PowerPC являются SuSE, RedHat, TurboLinux, YellowDogLinux и Gentoo. Причём, компания IBM, в свою очередь, объявила поддерживаемыми только три из них: SuSE, RedHat и TurboLinx. Во все эти дистрибутивы входит набор для кросскомпиляции приложений в 64-битный код (кроме Gentoo, где 64-х битная платформа является "родной"), поскольку основная масса приложений, кроме ядра и нескольких системных утилит работает в 32-битном режиме.

Приложения Все приложения, входящие в названные выше дистрибутивы портированы на платформу PowerPC. Практически все они работают в 32-битном режиме. Портированы также ключевые продукты компании IBM:

Pages:     | 1 | 2 || 4 | 5 |   ...   | 11 |






















© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.