Описание:  Командная строка, командная оболочка, командный скрипт или сценарий – эти фразы вызывают неоднозначную реакцию у тех, кто в той или иной степени использует компьютеры. Опытные пользователи Unix (к которым я причисляю и себя) понимающе улыбаются и одобрительно кивают головой. Те, кто застал MS-DOS, недовольно морщатся. Поколение Windows смотрит с недоумением и пожимает плечами. Впрочем, опытные администраторы Windows понимают, о чём идёт речь, но особого энтузиазма не выказывают.

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

Источник ITShaman - Сайт для АЙТИшников!

Русификация qutIM, установка смайлов и звуков от QIP

После первоначальной установки клиент мгновенных сообщений qutIM не пригоден для комфортной работы, так как не имеет русского интерфейса, стандартных смайликов (колобков QIP`а) и привычных звуков. Это было сделано авторами проекта, скорее всего, ради свободы выбора конечного пользователя.

В этой статье собрана информация, которая поможет «допилить» qutIM до требуемого состояния.

Дата публикации: 08.07.2009 Автор: Mut@NT
Источник

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

Каждый уважающий себя системный администратор должен уметь управлять своим временем. Если этого качества у него нет, то рано или поздно, при большом объеме работ и стрессов, он попросту «сгорит», перестанет получать удовольствие от  своей работы и возненавидит пользователей. Можно сказать, забьет все гвозди на крышке гроба своей замечательной и когда-то любимой профессии.

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

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

NFS сервер на Ubuntu 9.10

Загадка расширенного раздела

Почти детективная история

Глава 1. Завязка тайны.

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

Спор завязался относительно механизма создания и функционирования логических разделов на жестких дисках. Суть дела вкратце такова.

Всем известно, что главная таблица разделов (Partition Table - PT), находящаяся в Главном загрузочном секторе (MBS или MBR), содержит только четыре строки, по 16 байтов каждая, для описания разделов жесткого диска. Соответственно и разделов этих (они называются первичными) может быть только четыре. Меньше - пожалуйста, а вот больше - никак. По мере роста объемов жестких дисков, встала проблема увеличения количества разделов, ведь жесткие диски были очень дороги, а разбив их на разделы, можно было как бы увеличить их количество. Да и информацию удобно было "разложить по полочкам" разных разделов.

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

Предметом нашего спора стал механизм создания и адресации этих самых логических разделов.

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

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

"Первый сектор расширенного раздела тоже содержит таблицу разделов, подобную таблице из MBR. Однако из четырех возможных указателей на разделы используется только два: один используется для задания логического раздела, другой - для определения еще одного расширенного раздела. Два оставшихся указателя не используются. Каждый следующий расширенный раздел имеет свою таблицу разбиения, в которой, как и в первичном расширенном разделе, используются только две строки, задающие один логический и один расширенный раздел.
Таким образом, получается цепочка из таблиц разделов, где первая описывает три основных раздела, а каждая следующая - один логический раздел и положение следующей таблицы. Эта цепочка и определяет разбиение диска на разделы. Еще раз подчеркнем, что расширенный раздел как на физическом диске, так и в расширенном разделе вложенного расширенного раздела (предыдущего уровня) может быть только один..."

Редактор требовал исправления статьи в духе своих убеждений.

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

Автор тоже пошел на принцип, дескать, статья будет опубликована только в авторской редакции, или не будет опубликована вообще, короче говоря, спор разгорелся. ... читать дальше

Под таким заголовком появилась статья Дэвида Вилера еще в марте 2001 года на просторах англоязычного Интернета. Спасибо Антону Чернышову, преподавателю учебного центра R-Style, сертифицированному преподавателю ALT Linux, любезно предоставившему этот перевод нам. Итак, сама статья.

David A. Wheeler
26 марта 2001 c небольшими изменениями на 11 сентября 2006

1. Контейнеры в Qt

Qt предоставляет свои реализации строк, контейнеров и алгоритмов в качестве упрощенной кроссплатформенной альтернативы для STL

Как и в STL, контейнеры Qt используют шаблоны C++ и позволяют хранить элементы нужного типа. Например, QLinkedList<T> – шаблон связного списка; если требуется связный список целых чисел, то используется QLinkedList<int>.

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

QList<T> list1;
QList<T> list2;

list1 << a << b << c; // элементы a, b, c заносятся в list1

list2 = list1; // содержимое списков совпадает

list2[0] = d; // теперь list1 копируется;
 // list2 изменен, но не list1

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

У всех контейнеров есть некоторые общие методы:

int size() const; // число элементов
void clear(); // удалить все элементы
bool isEmpty() const; // true, если size() == 0

Также везде перегружены операторы сравнения == и !=. Подразумевается, что для типа элементов будет перегружен оператор ==. Контейнеры с последовательным хранением элементов сравниваются с учетом порядка, остальные контейнеры порядок не учитывают.