В 2021 году Linux выглядит как никогда привлекательно. Я собираюсь написать материалы, в которых расскажу о 21 способе использования Linux. А в этой статье я хочу поговорить о том, почему так много программистов выбирают Linux.
Когда я начал пользоваться Linux, я работал в сфере кинопроизводства. Я выбрал Linux из-за того, что эта ОС замечательно поддерживала работу с мультимедийными данными. Мы выяснили, что обычные коммерческие приложения для редактирования видео не способны обрабатывать большинство тех записей, которые мы извлекали из практически любых устройств, оснащённых камерами. Тогда я не знал о том, что Linux имеет репутацию операционной системы, рассчитанной на серверы и на программистов. Чем больше задач я решал с помощью Linux, тем сильнее мне хотелось научиться управлять всеми свойствами этой ОС. В итоге я выяснил, что компьютер показывает всю свою мощь тогда, когда его пользователь способен «говорить» на его языке. Через несколько лет после перехода на Linux я уже писал скрипты для автоматического редактирования видео, для объединения аудиофайлов, для пакетного редактирования фотографий, и для решения любых задач, которые мне удавалось сформулировать, и для которых удавалось найти решение. Мне не потребовалось много времени на то, чтобы понять, почему программисты любят Linux. Но именно Linux научила меня любить программирование.

Оказалось, что Linux — это отличная платформа для программистов, и для начинающих, и для опытных. Нельзя сказать, что Linux необходима для того, чтобы писать программы. Успешные разработчики пользуются самыми разными платформами. Но у Linux есть много такого, что она может предложить разработчикам. Кое о чём из этого я и хочу рассказать.
1. Логичность Linux
Linux построена вокруг идеи автоматизации. Основные приложения Linux совершенно осознанно сделаны такими, чтобы их можно было бы, как минимум, запустить из терминала, указав дополнительные опции. А часто их можно и полностью использовать тоже из терминала. Эту идею иногда ошибочно считают чем-то вроде примитивной модели организации вычислений, так как существует распространённое (и неправильное) мнение о том, что писать программы, работающие из терминала, это значит — прилагать абсолютный минимума усилий к тому, чтобы получить работающее приложение. Это — печальный результат непонимания того, как работает программный код, но многие из нас периодически страдают таким вот непониманием. Мы думаем, что больше — это всегда лучше, поэтому приложение, содержащее 1000 строк кода должно быть в 100 раз лучше, чем приложение, содержащее 10 строк кода. Так? Но правда заключается в том, что, при прочих равных условиях, лучше выбрать приложение, отличающееся большей гибкостью, при этом то, из скольких строк кода оно состоит, значения не имеет.
В Linux решение некоей задачи вручную может занять, например, час. То же самое можно, воспользовавшись подходящими инструментами командной строки, сделать буквально за минуту, а возможно — и за меньшее время, если прибегнуть к GNU Parallel. Для того чтобы к этому привыкнуть, нужно определённым образом изменить взгляд на то, как именно работают компьютеры, нужно научиться мыслить не так, как прежде. Например, если задача заключается в том, чтобы добавить к 30 PDF-файлам обложки, можно решить, что приемлемая последовательность действий будет выглядеть так:
- Открыть PDF-файл в редакторе.
- Открыть файл с обложкой.
- Присоединить PDF-файл к файлу с обложкой.
- Сохранить полученный документ в виде нового PDF-файла.
- Повторить эти действия при обработке остальных старых файлов (а вот новые файлы, полученные из старых, обрабатывать уже не нужно).
Эта последовательность действий вполне согласуется со здравым смыслом, и хотя в ней много неприятных повторений, она позволяет достичь цели. В Linux, правда, можно организовать работу гораздо разумнее. Процесс размышлений над этой задачей, учитывающий возможности Linux, похож на процесс размышлений над «ручным» способом решения задачи. А именно, всё начинается с поиска последовательности действий, необходимых для получения нужного результата. Проведя некоторые изыскания, можно узнать о команде
pdftk-java
, а потом выйти на простое решение:$ pdftk A=cover.pdf B=document_1.pdf cat A B output doc+cover_1.pdf
После того, как удастся убедиться в работоспособности команды при обработке одного документа, надо будет вложить некоторое время в изучение утилит для обработки наборов данных. В ходе изучения можно обнаружить команду
parallel
:$ find ~/docs/ -name "*.pdf" | parallel pdftk A=cover.pdf B={} cat A B output {.}.cover.pdf
Тут представлен подход к размышлениям над задачами, несколько отличающийся от обычного, так как «код», который мы пишем, обрабатывает данные не так, как мы привыкли. Обычно мы ограничены представлениями о последовательной ручной обработке данных. Но выход за границы старых представлений важен для того чтобы позже писать соответствующий код. А побочным полезным эффектом такого «выхода» является получение возможности писать более эффективные программы, чем раньше.
2. Возможности по управлению связями кода
Неважно, для какой платформы вы программируете, вводя в редакторе код. Всё сводится к тому, что программист плетёт сложную сеть из невидимых связей между множеством различных файлов. Практически во всех случаях, за исключением каких-то совсем уж экзотических, код, чтобы стать полноценной программой, обращается к заголовочным файлам и использует внешние библиотеки. Это происходит на всех платформах, но Linux подталкивает программиста к тому, чтобы он сам бы во всём этом разобрался, а не доверял бы заботу обо всём этом исключительно инструментам разработчика для некоей платформы.
Надо сказать, что нет ничего плохого в том, чтобы доверять инструментам разработчика решение задач по нахождению библиотек и по включению в состав программ внешних файлов. Это, наоборот, полезная возможность, наличие которой должно вызывать у программиста лишь чувство благодарности. Но если программист совершенно ничего не понимает в том, что происходит, ему будет гораздо сложнее взять управление всем этим на себя в том случае, если инструменты разработчика просто не будут знать о том, как справиться с некими проблемами.
Это имеет отношение не только к Linux, но и к другим платформам. В Linux можно писать код, который планируется запускать и в Linux, и в других операционных системах. Понимание того, как именно компилируется код, помогает программисту в достижении его целей.
Надо признать, подобным вещам нельзя научиться, просто пользуясь Linux. Можно счастливо писать код в хорошей IDE и никогда даже не задумываться о том, какая версия некоей библиотеки была установлена, или о том, где именно находятся какие-то заголовочные файлы. Но Linux ничего не скрывает от программиста. Очень просто углубиться в недра системы, найти в ней то, что нужно, и прочитать соответствующий код.
3. Удобство работы с существующим кодом
Полезно знать о том, где находятся заголовочные файлы и библиотеки, но возможность видеть их код — это ещё один пример дополнительного преимущества программирования в Linux. В Linux можно посмотреть код практически всего, о чём можно подумать (за исключением приложений, работающих на Linux, но не являющихся опенсорсными). Невозможно переоценить полезность этой особенности Linux. По мере того, как некто всё лучше и лучше осваивает программирование в целом, или разбирается с чем-то новым для себя, он может многое узнать, читая существующий код в своей Linux-системе. Многие программисты научились делать своё дело, читая опенсорсный код других людей.
При работе с системами, код которых закрыт, можно найти документацию, ориентированную на разработчиков и содержащую примеры кода. Это хорошо, документация — это важно, но это не сравнить с возможностью обнаружить именно тот функционал, который планируется реализовать, и с возможностью найти исходный код, демонстрирующий то, как это сделано в приложении, которым вы пользуетесь каждый день.
4. Прямой доступ к периферии
Я, после того, как разрабатывал на Linux программы для медиакомпаний, иногда принимаю как должное возможность доступа к периферийным устройствам. Например, при подключении к Linux-компьютеру видеокамеры можно загрузить входящие данные из
/dev/video0
или из подобного устройства. Всё что нужно, можно найти в /dev
, и это — всегда кратчайший путь из точки A в точку B.А вот на других платформах это не так. Подключение к системам, находящимся за пределами ОС — это всегда лабиринт, построенный из SDK, библиотек с закрытым кодом, а иногда — и из соглашений о конфиденциальности. Ситуация, конечно, не везде одинакова, она зависит от того, для какой именно платформы пишет код программист, но другим системам сложно поспорить с простотой и предсказуемостью интерфейса Linux.
5. Хорошо продуманные абстракции
Linux, в то же время, даёт нам и разумный набор слоёв абстракции, применимых в ситуациях, когда прямой доступ к чему либо или ручное написание некоего кода может вылиться в больший объём работы, чем тот, к которому готов программист. Много удобных инструментов можно найти в Qt и Java, есть целые стеки вспомогательных технологий, вроде Pulse Audio, Pipewire и gstreamer. Linux стремится к тому, чтобы её пользователи могли бы заниматься программированием, и не скрывает этого.
Итоги
Есть гораздо больше причин того, что программировать в Linux — это удовольствие. Некоторые из них представляют собой широкомасштабные концепции, некоторые — мельчайшие детали, которые избавили меня от многих часов тяжких поисков решения неких задач. Linux — это место, в котором приятно находиться, при этом неважно — на какой именно платформе будет запускаться код, который пишут в Linux. Кем бы вы ни были — человеком который только начал осваивать дело написания программ, или опытным кодером, который ищет себе новый цифровой дом, нет лучше места для программирования, чем Linux.
Какой ОС вы пользуетесь при написании программ?

moskIToff
Множество программистов со стажем сидят на Линуксе/macos (все же unicode как ни как). я же слишком привык к окну (да и в программировании новичок). думаю для тех кто не может решиться, лучше сначала попробовать поставить линукс на виртуалку oracle (говорят слишком много подводных камней при паралельной установке винды и линукса).
argamidon
Вот я пересел на линух недавно. Тоже попробовал установить рабочее окружение на виртуалку. программировал на этой виртуалке меньше дня. и вдруг понял что я просто рыба в воде. Хотя на винде сидел всю жизнь
Теперь имею дуал лоад. Винду оставил на всякий случай( пока не всё умею делать под линухом)
leniviy_ramvas
Я тоже имею дуал-лоад, но на винде по большей части сижу только из-за игр, а программирую в основном в линукс, хотя временами возникают некоторые проблемы,
Catslinger
Нет там никаких подводных камней, кроме одного: при использовании EFI нужно создать отдельный EFI раздел для линукса, потому что винда с мажорными обновлениями форматирует свой иногда.
MikalaiR
Последние версии винды даже научились сохранять линуксовый загрузчик.
justhabrauser
Это довольно оперативно восстанавливается с помощью USB Live Linux.
У меня на макбуке EFI всегда слетает при обновлении macOS (там еще и EFI нелюдский).
15 минут работы и снова всё нормально (до следующего обновления macOS, ага).
Vitaly83vvp
всё же интересно, что же там за камни? не раз ставил параллельно. работают.
ZuOverture
Огрёб в своё время ворох проблем на организации общего доступа из разных ОС к рабочим файлам. Windows не умел писать на ext, а специальный драйвер ext2fsd не уследил за какими-то обновлениями ext, что вылилось в потерю части файловой системы. Не камень, но на гравий потянет.
qandak
Общий доступ можно организовать с помощью любого ntfs раздела (системный виндовый или другой). Ядро линукса умеет читать ntfs с коробки. Для полноценной работы есть мультиплатформенный опенсорсный драйвер ntfs-3g, который доступен в репозиториях дистрибутивов и устанавливается как пакет.
Vitaly83vvp
Знакомо. Поэтому, теперь, общие данные на ФС NTFS. Для Windows это родная ФС, а семейство Linux умеет его поддерживать. Есть одно «НО» — если Windows не завершил работу, а ушёл в один из энергосберегающих режимов. Тогда, диск (в частности, системный) доступен только для чтения. Очень неприятно.
Almighty_Goose
Я когда-то сам использовал не ext2fsd, а другой проект — ext2ifs.
Но я не включал его постоянно, только когда нужно было какие-то документы с раздела Linux достать.
В те далекие времена, также, исследовал какие ФС читаются обеими ОС и можно использовать для обмена. Список был удручающе мал: нативно поддерживаются FAT32 и UDF, еще через FUSE можно подключить NTFS и exFAT. Сейчас поддержку exFAT добавили в ядро, можно использовать его.
На данный момент использую драйвер WinBtrfs, т.к. Proton от Steam использует симлинки и просто так игры, расположенные на NTFS/exFAT, запустить под линуксом не удалось. Но последнее время думаю о том, чтобы снести винду полностью, а освободившееся место использовать под BCache.
oldbie
На самом деле немало, но когда постоянно используешь просто забываешь об этом и не считаешь подводными камнями. Навскидку
JerleShannara
Лулзы некоторые в том, что в ext* совершенно спокойно живут файлы с именами '?' и '*', а вот в ntfs…
klirichek
Это ограничение windows, а не ntfs. Из-под линукса/мака на разделе с ntfs замечательно создаются и работают файлы с практически любыми символами в именах (очень удобно хранить электронные книги с полным именем издания в качестве имени файла). Но вот когда потом под windows пытаешься открыть файл вида "QNX_UNIX: анатомия параллелизма.pdf" — эти ограничения вылезают.
JerleShannara
Странно, у меня при попытке по *nix на ntfs записать что-то в '*' или '?'.
arxont@potex /run/media/arxont/0C6C0A526C0A36CC $ echo "ZZZZ" > "?"
bash: ?: Недопустимый аргумент
arxont@potex /run/media/arxont/0C6C0A526C0A36CC $ echo "ZZZZ" > "*"
bash: *: Недопустимый аргумент
arxont@potex /run/media/arxont/0C6C0A526C0A36CC $ cd ~
arxont@potex ~ $ echo "ZZZZ" > "*"
arxont@potex ~ $ echo "ZZZZ" > "?"
первое — ntfs, второе — ext4
klirichek
Зависит от *nix, видимо. На маке я могу писать звёздочки и вопросики, но не могу двоеточия. На убунте (сейчас попробовать не могу, нет под рукой) двоеточия, насколько помню, можно.
Ну и вишенкой на торте остаются разные "магические" имена вроде prn, lpt1 и т.д., которые винда по старинке считает именами спец. устройств и приходит в замешательство, когда сталкивается с файлами с именно такими именами, но на диске. Это тоже, очевидно, ограничения ОС, а не ФС.
JerleShannara
Двоеточие у меня тоже в пролёте.
Эх, сколько народа пыталось у меня с локальной помойки скачать файл по адресу /video/porno/Teens/[удалено цензурой]/*.avi…
kai3341
Экранирование? Не, не слышал :)
Отрабатывает без ошибок. Главное теперь не забыть экранировать при удалении
ZuOverture
polearnik
как раз закончил свою дипломную работу и перед тем как скинуть ее на флэшку попробую ваш вариант создания и удаления
JerleShannara
Кхем, а "" по вашему я зачем там вводил?
Vitaly83vvp
На счёт первого пункта, винда, через некоторое время, приходит в себя и дата показывается актуальная.
Второй пункт — бесит. Особенно, когда нужно по-быстрому, что-то скопировать на системный раздел. Выручают несистемные диски.
С третьим пока не сталкивался или просто не особо пользовался «общими» данными. Возможно, что основная система у меня Linux. А Windows — вспомогательная, своего рода замена wine.
А четвёртый — я просто предпочитаю AMD. Ни разу не брал Nvidia, поэтому не могу сказать как они ведут себя.
Говоря о том, что не сталкивался с подводными камнями, я имел в виду не их взаимодействие, а о том, что они без особых проблем ставятся на одну машину и живут своей жизнью.
excuseme777
Ни разу не слышал о подводных камнях в линукс-системах. Вот в дистрибутивах — возможно. Кстати, можно установить виртуалку на линукс, кто уверенно хочет использовать её, но и винду жалко оставлять без внимания)
kuznetsovkd
Каждой задаче свой инструмент. Если у вас разработка под линукс, то логично в качестве среды разработки выбрать линукс/macos так как процесс развертывания будет один и сюрпризов можно не ждать.
Так что если вы разрабатываете под win, то и не стоит ничего менять.