Первое знакомство

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

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

Технический директор компании PingWin Software Вячеслав Калошин (а он-то уж наверняка разбирается в предмете) утверждает, что затраты на миграцию примерно равны 75—80% от годовой стоимости используемых проприетарных продуктов компании Microsoft. Однако известны случаи, когда переход на СПО либо не приносил ожидаемого эффекта, либо расходы компании даже возрастали. И сомневаться в валидности подобных данных тоже нет никаких оснований.

Так и напрашивается простая аналогия. Кто-то, занявшись зимним купанием, радикально улучшает собственное здоровье. А кто-то попадает в больницу с воспалением легких. Так что миграция показана далеко не всем. Это, во-первых.

Во-вторых, очень многое зависит не только от идеи, но и от ее реализации. В СНГ эта истина должна быть хорошо известна — мы не раз оказывались в ситуации, когда неплохая задумка трансформировалась во что-то совершенно непотребное именно по причине плохого исполнения.

Как же провести миграцию так, чтобы риск оказаться “на бобах” был минимален? Разумеется, конкретных алгоритмов тут нет. Но некую общую схему нарисовать все-таки можно. Именно этим мы и займемся.

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

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

Наиболее известный инструмент для этого дела — LiveCD. Идея, без сомнения, хорошая, однако для первого знакомства такой способ подходит весьма условно. Прежде всего надо учитывать скорость работы — она у “живых дисков” невысока, что не может не раздражать. В результате субъективное впечатление от Linux может оказаться не таким положительным, как это могло быть при нормальной инсталляции.

Несколько шустрее работают системы, загружаемые с USB-накопителей. Однако их надо либо покупать в готовом виде, либо скачивать образ и записывать самостоятельно, что требует уже какого-то уровня подготовки пользователя. Грубо говоря, через стандартный “Проводник” Windows этого сделать нельзя.

Но есть еще один способ, практически лишенный недостатков. Всё, что требуется от пользователя, — подготовить примерно пять свободных гигабайтов в любом разделе Windows. А затем в этот раздел установить Linux, как обычную программу.

Именно этот путь предлагает проект Wubi (Windows-based Ubuntu Installer). Чтобы установить Linux без необходимости заново разбивать диск на разделы, требуется только скачать со страницы wubi-installer.org исполняемый в среде Windows файл, размером примерно полтора мегабайта.

При запуске программы пользователю будет предложено выбрать раздел для установки системы, язык интерфейса, а также вид десктопа — Ubuntu, работающую в среде GNOME, Kubuntu с KDE, Xubuntu с XFCE или мультимедийный центр Mythbuntu. Это, кстати, один из доводов в пользу именно Wubi. Все-таки обычному пользователю важно не название дистрибутива (Mandriva, Red Hat или Ubuntu), а рабочее окружение. Предлагаемый путь позволит посмотреть на все популярные интерфейсы и выбрать тот, который больше понравится.

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

В результате получится “полноценная” Ubuntu. Разумеется, некоторые ограничения есть, но для первого знакомства они не очень существенны: не поддерживается гибернация, файловая система неустойчива к внезапному выключению машины и заметно небольшое уменьшение производительности из-за фрагментации FAT32/NTFS. Тем не менее рабочая среда вполне работоспособна и позволяет выполнять все операции, доступные из системы, установленной штатным способом.

При этой установке не создается никакой виртуальной машины с некими абстрактными устройствами. Таким образом, если использовать Wubi на более-менее стандартном для предприятия компьютере, то можно сразу выяснить, как обстоит дело с поддержкой “железа” без необходимости искать информацию в Сети по каждой составной части.

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

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

Полностью доступен репозитарий Ubuntu. Поэтому ничто не мешает установить новые программы и попробовать их в деле. Даже украшательства в виде трехмерного рабочего стола будут работать нормально.

Впрочем, какие-то советы методического характера тут явно неуместны. Главная цель этого этапа — получить какие-то субъективные впечатления от системы. Если есть уверенность, что она не будет вызывать явного отторжения, то можно двигаться дальше.

А установленную систему удалить, чтоб не занимала место на диске. Сделать это можно при помощи стандартного для Windows инструмента — через “Панель управления” в секции “Установка и удаление программ”.

Оценка целесообразности

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

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

Следующий этап — оценка “мигрантопригодности” предприятия. Вдруг получится так, что овчинка не будет стоить выделки. Чтобы избежать бессмысленной работы, надо провести ревизию рабочих станций предприятия и используемого на них ПО.

Установленное ПО можно условно разбить на три категории:

• программы, имеющие равноценные свободные аналоги;
  
• программы, не имеющие равноценных свободных аналогов;

• уникальные программы, используемые внутри предприятия.

Проще всего с первыми двумя категориями. Очевидно, что в первом случае замена программ на свободные аналоги возможна, а во втором — нет. А вот в третьем случае предстоит серьезная подготовительная работа.

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

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

Дело в том, что некоторые приложения, написанные для Windows, прекрасно работают в среде WINE. Причем, чем древнее программа, тем больше вероятности, что она запустится без проблем. Однако заранее что-то сказать невозможно, поэтому потребуется тестирование.

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

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

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

Рабочие станции можно разбить на три категории по используемому ПО:

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

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

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

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

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

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

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

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

Например, анализ показал, что рабочую станцию секретаря можно полностью переводить на СПО. Но это в теории. На практике все может оказаться несколько сложнее. Например, сотрудник пользуется МФУ. Он привык, что факсы отправляются очень просто — посредством “печати” на специальный принтер. В Linux это тоже можно сделать, но потребуются дополнительные усилия и соответственно расходы. А уж сколько крови могут попортить системным администраторам жалобы пользователей на то, что из трея пропала иконка, показывающая, кто именно звонит по телефону...

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

Переход на Linux: первые решения

Если вы убедились, что переход на Linux экономически оправдан, то можно двигаться дальше. А именно — принять ряд решений, которые будут в общих чертах определять весь ход проекта.

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

Дистрибутив и интегратор

Одна из самых серьёзных ошибок — рассматривать две стороны этого вопроса независимо друг от друга. Безусловно, нельзя дословно применять к корпоративному сектору известный тезис о том, что самый лучший дистрибутив — тот, которым пользуется сосед, но учитывать это все равно необходимо.

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

Вполне может получиться так, что вариант, который казался наиболее выгодным при поверхностном рассмотрении вопроса, в действительности приведет к серьезным дополнительным расходам. Например, отдав предпочтение какому-нибудь экзотическому дистрибутиву, внедряемому небольшой компанией за небольшие деньги, вы рискуете, что через некоторое время интерес этой фирмы к СПО иссякнет и вам придётся искать замену. А это связано с новыми затратами.

С другой стороны, можно выбрать Red Hat, соблазнившись их фирменной технической поддержкой, и заплатить серьезные деньги на подписку и ее ежегодное обновление. Но потом окажется, что аналогичного результата можно было достичь и при меньших затратах. Например, установив Ubuntu и заключив договор с каким-нибудь местным интегратором.

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

Разумеется, если интегратор ответит, что Linux — он и есть Linux, и ему безразлично, какой именно дистрибутив обслуживать, то к таким заявлениям следует относиться со значительным скепсисом. Дело в том, что у каждого продукта есть своя специфика. Понятно, что опытный специалист сможет в ней разобраться, но это потребует времени. Значительно лучше, если подрядчик уже имеет практический опыт решения проблем конкретной системы, а не собирается учиться “на вас”.

Таким образом, вопрос о дистрибутиве и интеграторе решается так: “лучший дистрибутив” — тот, который поддерживает больше всего интеграторов; “лучший интегратор” — тот, кто поддерживает больше всего дистрибутивов (с учетом вышесказанного — не просто декларирует поддержку, а может сослаться на практический опыт).

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

Пилотный проект

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

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

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

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

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

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

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

Очевидно, что было бы лучше для пилотного проекта выбрать меньше школ, но переводить их на СПО целиком, а не только один кабинет. В этом случае вряд ли появилось бы заявление компании “Линукс ИНК” (одного из участников проекта), в котором говорилось, что созданные в соответствии с условиями проекта дистрибутивы отвечают только требованиям обеспечения образовательного процесса, да и то ограниченно, но не других сторон деятельности учебного заведения.

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

Осторожное начало

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

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

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

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

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

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

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

Допустим, есть некий сотрудник, который по роду своей деятельности использует только браузер, почтовый клиент и офисный пакет. Разумеется, это будут Internet Explorer, Outlook и MS Office. Предположим, по каким-либо причинам руководство решило, что ему будет сложно сразу освоить три новые программы, да еще и работающие в незнакомой операционной системе.

В этом случае миграцию можно разбить на следующие этапы:

• с Internet Explorer на Firefox;

• с Outlook на Thunderbird;

• с MS Office на OpenOffice.org;

• с Windows на Linux.

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

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

Несмотря на то что на первый взгляд сложнее всего заменить офисный пакет (просто потому, что он большой), практика может быть совершенно иной. Например, если MS Office использовался для просмотра прайс-листов и написания небольших служебных записок, то переход на OpenOffice.org произойдет практически безболезненно. А миграция на Firefox может оказаться вообще невозможной, если пользователь работает с сервисами, корректно функционирующими только в Internet Explorer.

Поскольку в общем виде действия системного интегратора вряд ли можно как-то формализовать, то в качестве примера рассмотрим некоторые аспекты перехода с браузера Internet Explorer на Firefox. Разумеется, на практике все можно быть совсем иначе, поэтому не стоит считать написанное ниже каким-то конкретным рецептом.

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

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

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

После того как эта работа закончена и пользователя устроил результат, следует импортировать закладки, журнал, пароли и т. д. из Internet Explorer. Эта функция в Firefox полностью автоматизирована, поэтому никаких проблем возникнуть не должно. Кстати, это весомый аргумент в пользу того, что не стоит начинать миграцию с удаления Windows. Ведь тогда настройки браузера придется восстанавливать вручную, что вряд ли удобно.

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

А доброжелательный пользователь — это как минимум половина успеха. Не стоит этим пренебрегать.

Завершение работы

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

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

В качестве дистрибутива выбираем Linux Mint. Не потому, что он какой-то особенный, просто чтобы избежать упреков в скрытой рекламе какого-либо коммерческого продукта. 

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

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

Установка Linux Mint не должна вызвать проблем даже у только начинающего пользователя. Особенно, если предполагается, что она будет на машине в единственном числе (т. е. именно наш случай). Процедура полностью автоматизирована — разве что язык придется выбрать самому.

А вот с настройкой придется немного помучиться (кстати, гораздо меньше, чем в случае с Windows). Чтобы быть предельно конкретным, скажу, что система Linux Mint устанавливалась на ноутбук Toshiba Satellite A200 с адаптером беспроводной сети Intel Wireless WiFi Link 4965AGN и видеокартой Nvidia. Кстати, не самый простой вариант для Linux.

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

Затем запустите “Центр управления” и в разделе “Система” активируйте инструмент “Локализации”. Русский язык уже назначен основным, дело только за нужными модулями поддержки. Они установятся по нажатии одной кнопки.

Для активации драйвера Nvidia запустите в “Центре управления” утилиту “Драйверы устройств”. Выберите рекомендованный модуль и нажмите на кнопку “Активировать”. И эта операция будет выполнена.

Основное сделано, можно заняться мелочами. Если вас не устраивает, что тачпад не реагирует на клики, то включите соответствующую опцию в разделе “Мышь” “Центра управления”. Только сперва хорошенько подумайте — удобно ли будет, ведь во время набора текста это будет серьезно мешать. А для клика можно использовать кнопки — для чего-то они в конце концов нужны.

Браузер Firefox, почтовый клиент Thunderbird и офисный пакет OpenOffice.org устанавливаются в систему по умолчанию. Причем они автоматически обновятся до актуального состояния. Между прочим, в отличие от Windows, где это приходится делать отдельно для каждого приложения.

И получается, что привыкший к СПО пользователь если и заметит какие-то перемены, то только к лучшему. По крайней мере он может позабыть о вирусах, что весьма немаловажно.

Впрочем, пока рано радоваться, ведь десктоп еще далек от совершенства. В частности, вряд ли кому-то понравится набор шрифтов. Справедливости ради, следует признать, что в Windows они более-менее симпатичные (а может быть — просто привычные).

Но и в Linux можно использовать те же самые шрифты, что и в Windows. Перед удалением Windows скопируйте куда-нибудь шрифты TTF, а потом подключите их к новой системе простым кликом мыши. И, конечно, не забудьте зайти в раздел “Внешний вид” “Центра управления”, чтобы указать, что именно вы ходите видеть на экране.

Поскольку браузер и почтовый клиент уже были подготовлены к миграции на Linux, то настройка этих программ не вызовет труда. Например, в Firefox потребуется только установить расширения Xmarks и заменить закладки локальной машины на закладки, хранящиеся на сервере.

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

Кстати, даже если серверы переведены на Linux, то все равно в большинстве случаев для удаленного доступа используется SAMBA, а не NFS. Это связано с тем, что в сети все равно есть машины с Windows (например, в бухгалтерии), поэтому деваться по сути дела некуда.

Тем не менее Linux прекрасно себя чувствует в Windows-сети. Чтобы войти на удаленный ресурс запустите штатный файловый менеджер и кликните на “Сеть”. Дальнейшие действия полностью аналогичны тем, к которым уже привык пользователь Windows.

Однако может получиться (и даже наверняка получится) так, что названия рабочих групп не совпадут. Если это так, то откройте файл /etc/samba/smb.conf любым текстовым редактором от имени администратора системы (для этого в Linux Mint применяется sudo) и исправьте параметр workgroup в секции [global].

А что делать, если доступ к SAMBA-ресурсу хочется получить не только через штатный файловый менеджер с графическим интерфейсом, но и из консоли? Кстати, эта задача вовсе не надуманна, что станет ясно из следующего примера.

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

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

С другой стороны, понятно желание пользователя совместить приятное с полезным. А именно — прослушивание записей с просмотром новостных лент. И чтобы интерфейс проигрывателя не маячил на экране и не отвлекал от работы, он выбирает MOC в качестве штатного плейера MP3-файлов, установив его командой sudo aptitude install moc moc-ffmpeg-plugin.

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

Однако MOC — это консольная программа. И найти SAMBA-ресурс в файловой системе не так просто, как кажется на первый взгляд. Более того, поскольку программа настроена так, что не показывает скрытые каталоги, то это сделать вообще невозможно без изменений в конфигурационном файле. Но это в свою очередь приведет к тому, что в управляющем окне будут отображаться все служебные каталоги, которых очень много, и найти нужное будет совсем сложно.

Практический выход из ситуации такой. Запустите штатный файловый менеджер, отметьте нужный вам SAMBA-ресурс и в разделе “Правка” главного меню активируйте опцию “Open in Terminal”. И вам сразу станет ясно, где искать нужный каталог.

Однако он скрыт от программы MOC, поэтому создайте ссылку на него командой ln [имя файла] [имя ссылки]. И спокойно слушайте звуковые файлы, находящиеся на сервере.

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

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