• На данный момент для координирования работ используется макрос ExtractModules (тот же, что и в PspoModules). Возможно, впоследствии будет написано нечто более специфичное для данных работ.

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

  0%	Сырой конспект
  20%	Дешифрованный конспект
  50%	Конспект, переведённый на русский язык
  70%	Вычитанный конспект
  90%	Иллюстрирование, расстановка ссылок, перенос в модули
  100%	Результат работ над частью лекций проверен FrBrGeorge

• Как только Вы считаете, что закончили свою часть работы, просьба установить соответствующее количество процентов
• Промежуточное количество процентов в промежуточных сохранениях приветствуется

Пожелания к ролям

• Расшифровка — по возможности полное восстановление структуры и смысла лекции по конспектам и (если есть необходимость) по аудиозаписям. в эту задачу входит расстановка имеющихся иллюстраций (typescript, konsole.log, снимки экрана)

• Перевод на русский — выравнивание стилистки и корректировка владения русским языком. Просьба не очень самовыражаться (чтобы не создавать стилистического разнобоя)

• Вычитка — проверка получившегося текста на (1) соответствие действительности (2) доходчивость (в том числе на предмет нехватки иллюстраций)

CategoryPolicy

Концепция здесь будет одна: может быть, полезно вспомнить ...

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

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

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

Лектор проходил мимо стенда компьютерных курсов, и обнаружил четыре специализации: Фотошоп, Веб-дизайн, программирование. Такой вот странный набор. Теперь можно сопост. эти задачи и список возм. решаемых задач.

Ещё одна причина: попробуем просмотреть все пункты любого меню графического в дистр.

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

Лектор хочет сказать, что эта концепция далеко не общая. Далеко не каждый человек, приобр. компьютер, думает о том, что будет решать все задачи по обр. и перераб. инф. Если у человека не будет перед глазами инструмента, то он будет решать на бумажке. Эта даже более популярная комбинация, чем найти инструмент или его сотворить. Это так сказать креативный подход. И именно с этой т. з. и рассм. Если отвлечься от креативного подхода, то можно рассм. менюшечный подход, но лектора интересует идея, что берутся не только готовые интср., но и констр. новые.

Первая концепция: * Решение задач (обработка и передача информации). Есть ещё мультимедийные задачи, но тем не менее. Ключевое слово --- решение.

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

Задача номер два: построение решений. Что лектор имеет в виду: что-то вроде функц. полноты. Если мы хотим, чтобы задачи действительно решались, у нас в руке должен быть некий инструментарий, который позволяет эти задачи решать. Пример: предположим, что мы хотим написать некую программу, которая перекладывает и переименовывает файлы, и пытаемся сделать это средствами COMMAND.COM. И упираемся в то, что мы не можем эту задачу решить, инструментарий неполный.

Третье, что важно в этом случае: воспроизводимость решения. Если мы задачу как-то решили, то было бы здорово, чтобы в следующий раз задачу решали не мы, а компьютер. Потому что работать должен компьютер, а человек --- думать. Если мы сами создали решение, то оно должно обладать некой гибкостью, чтобы можно было его применять для однотипных задач. Готовые решения должны как-то оформлять, причём эти решения должны быть по возм. удобными.

В ворде есть запись макросов. Для лектора эта штука была как минимум раздражающей. Записываешь действия, а потом записи такие странные...

Давайте на эти пожелания наложим некоторые требования, что мы хотим при этом соблюсти: * Давным давно было требование минимизации апп. зависимости. При мер: пусть у нас есть аппарат для чтения мыслей, он стоит дороже компьютера, но он позволяет управлять компьютером волеизьявлением. Было бы неплохо организовать работу с компьютером таким образом, но он дорогой и не существует. Более того, любая привязка к конкретике, например, к количеству цветов, которое может вывести граф.устройство, очень нехорошее ограничение, которое может повредить в будущем. Тем не менее, сейчас можно запланировать, какое должно быть железо. Тем не менее, это условие очень хорошее, поскольку сейчас линукс начинает применяться на разных мобильных устройствах. * Не требование, а некое предположение. Пусть задачу мы поставили, попробуем наметить пути решения. Попробуем заглянуть на пункты построение решений и воспроизводимость. Давайте в пункт "управление": это взаимодействие компьютера и человека. Мы говорим о чём: мы сами управляем компьютером. И когда лектор говорит про управление, он говорит про то, что придёт он и будет имеющимися у него средствами взаимодействовать с компьютером. Отсюда требование, какими мы будем пользоваться каналами данных. Есть человек, существо с ограниченными каналами данным и с 5 чувствами. Если конкрет. вопрос, и понять, как орг. взаимод., то выяснится, что не так уж много способов орг. взаимод., как им командовать. Мы должны команды поставлять, а он их --- интерпретировать. И вводится допущение, что команда это текст. Это связано вот с чем: связано с решением двух след. наших задач: постр. и формализ. решений. На сегодняшний день мы просто идём к этому, на сегодняшний день ничего, кроме прогр., не придумано. Можно конечно обойтись без предолож, но постр. будет несколько другим. Чёткую и однознач. команду можно представить в виде текста. Никакого другого метода, как лектору кажется, не существует. В случае, когда вып. функций мало, когда каждому элементу упр. обозн. отдельное действие, если функций много, то мы получаем беск. много эл-тов упр, и надо как-то их конструировать, естественным образом это текст. Сейчас практически единственным способом является ввод по клавиатуре. А что касается поиска этого текста среди вариантов, то увидим, что этот текст используется. Команда --- это то, что дают. Основываясь на этом допущении, сделаем ещё ряд допущений.

Предположение номер два: взаимодействие --- команда-результат. Лектор не рассм. другие варианты. Речь идёт о взаимодействии: человек даёт команду, машина даёт результат, человек анализирует, даёт другую команду, машина даёт другой результат. Второе предп.: диагностика (обратная связь) --- тоже текст. Эта самая диагностика тоже может быть предметом анализа, и не исключено, что мы её будем передавать обратно компьютеру.

Утвержд. 3: более строгое. Данные --- текст. Тут надо говорить, что такое текст. Надо дать некоторое опред. Текст: послед. символом, которые человек может прочитать глазами и понять. Смысл третьего утвержд: раз взаимод. осущ. текстовым способом, то и данные должны иметь тестовую форму. В том случае, когда картинки имеют содерж. знач, то неплохо и её выводить в текстовом виде.

Идея: обмен предпочтительно делать текстовым.

Теперь посмотрим, как этак концепция.... какие дополнительные идеи могут сюда быть навешены.

Допустим, наша мечта сбылась: мы нашли место в ОС, в котором всё можно представить в виде текста.

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

Это упростит понимание ситуации и упростит управление.

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

Предположим ситуацию, что все условия выполнены: мы создали богатый набор инструментов. От инструментов очень гибких, до специализированных. Для того, чтобы мы могли перейти к собственно решению задач, мы должны иметь некий удобный способ организации взаимодействия инструментов, построение суперпозиции. Это значит, что задачу мы не решили, мы понапихали сундук чемоданчиков, но пока не изобретём оболочку, в которой мы сможем описывать взаимодействие, таким образом, чтобы конструировать суперпозицию, решение.

Что ещё должны навесить: всё это прекрасно, но должна быть идея о том, что использовать всю эту конструкцию должно быть в достаточной степени удобно. Мы накладываем ограничения, и эти ограничения должны превращаться в удобство работы с компьютером. Очень просто: забудем про слово удобство и вспомним про слово эффективность. В одной из своих лекции лектор пытался аргументировать: удобство субъективно (некоторым удобно то, что они 10 лет, как знают, остальное категорически неудобно), а будем рассм. инструментарий, который позволяет решать задачи быстро и качественно. А если решения создаются медленно и получаются некачественными, то это неудобный инструмент. Когда лектор говорит о быстроте решения, лектор включает последний пункт: не один раз решить быстро, а сто раз решить быстро. Если нужно задачу решить один раз, то можно руками позапускать инструменты, а когда речь идёт о том, что придётся сто, тысячу раз операцию проделать, то мы оцениваем время целиком.

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

Речь идёт о чём: речь идёт о таких вещах, которые некоторым и объяснять-то не надо. Это место, которое совмещает интерфейс данных и инт. упр., причём интерфейс текстовый.

Процесс состоит в том, что мы подаём некий текст, в ответ приходит текстовая же диагностика. Текст этот представляет собой апелляцию к имеющемуся инструментарию. Единый терминал, объект инт. упр. и данных.

Команда --- представляет собой апелляцию к имеющемуся инстр. В случае, кода речь идёт о ИКС, то вид у неё <утилита> <параметры>. Что такое утилита? утилита --- некая программа, которая где-то там лежит, и когда вводится имя, то интерпретатор понимает, что надо её запустить. Команды могут быть встроенными.

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

Остаётся суперпозиция. Можно объединять команды, имеется алгоритмически полный язык, кроме того, он насыщен возможностями, специфичными для интерпретаторы командной строки.

Пример: попробовать написать программу, которая деалет ls | wc. Что делает эта команда: ls выдаёт список файлов, а wc считает количество строк, слов и символов в выдаче.

Всё это будет впереди.

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

Помимо того, что шелл является ЯП, он является средством редактирования командной строки.

Для тех, кто совсем не в танке: для того, чтобы управление происходило компьютером, некоторые вводимые с клавиатуры символы должны воспр. не как текст, а как упр. символы. Например: вводим командную строку, как понять, когда он должен начать интерпретировать. Для этого есть специальный символ: перевод строки. Обычно эти спецсимволы перед. для упр. интерпретаторам, иногда, для управления системой. Пример: запустили что-то, интерпретатор ждёт, программа работает, тогда посылаем Ctrl-C.

... Тем самым мы придерживаемся условия, что интерфейс управления --- текстовый.

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

Осталось 15 минут, и лектор хочет посвятить их проблемам, которые интересны меньшинству:

terminal capabilities

Год назад была лекция, где описывались виды инт., и там разделялся ИКС и терминальный.

В ИКС нет никакого квадратика, есть точка, в которую мы вводим команды, но у нас есть терминал, и он представляет собой прямоугольник.

... и Интерфейсом терминальным, который предст. собой матрицу знакомест. Вопрос: мы вроде только что договорились, что наше терм. устройство умеет передавать байты, то есть, что это точка, а не матрица. Мы ничего не говорили про координаты. Как нам теперь от этого избавиться: избавиться можно, введя две хитрых сущности: первая сущность называется курсор. Что такое курсор: это индикатор того места, куда введётся символ. Второе: помимо наличия курсора, договариваемся, как некоторые символы являются упр для компьютера, так и некоторые выводимые символы управляют терминалом. То есть, есть символы двух родов: управляют компьютером и терминалом. Например, перевод строки он не символ, он переводит строку. Существуют гораздо более хитрые символы: переместить курсор в координаты 20,10. Зачем это нужно: устройство продолжает оставаться тупым. Тем самым, вводя понятие упр. символов терминала, мы избегаем дополнительных апп. ухищрений за искл. того, что терминал должен уметь распознавать символы. Но поскольку байтов разных мало, то есть управляющие последовательности. Есть специальный символ "начало упр. посл.", а за ним могут идти обыкновенные символы, но они интерп. как упр. послед. И вывод упр. последовательности приведёт, например, к изменению цвета или к перемещению курсора. Таких последовательностей чёртова прорва. Хуже всего, что за время сущ. терминалов их накопилось несколько сотен, и в каждом из них упр. посл. разные. Для того, чтобы этим как-то управлять, есть две БД терминалов, termcap и terminfo, в них описаны всевозможные функции терминалов, и какие можно выполнять дейтсвия. Кроме того, у термкапа есть язык программирования свой. Для того, чтобы посмотреть, что умеет конкретно ваш терминал, есть infocmp ,tset. Для того, что бы непоср. в шелле спозиц. курсор, то есть tput, после которого идёт termnfo/termcap capability. Терминал определён в $TERM. Для использования этого в программировании есть библиотека ncurses.