Comments 97
Может такие создаваемые на коленке конвеерные цепочки и не будут претендовать на полноценное и долговременное решение
А как же nvm, rbenv, pyenv и прочие? Очень даже долговременные решения. Чистый шелл, как он есть (местами с костылями =)
Статья - хорошее подспорье для новичков, что, впрочем, не умаляет её ценности.
Было бы интересно для какой-то совершенно новой операционной системы (ну типа Google Fuchsia) спроектировать и реализовать совершенно новую систему командной строки. Полностью перепродумать. Возможно с учетом опыта powershell, современных скриптовых и не только языков программирования и т.д.
Но тут проблема вот в чем. Люди, незнакомые или почти незнакомые с линуксовой командной строкой и скриптами (как я), смотрят на это как на китайскую грамоту. Даже если они программисты. А те кто каждый день пользуется, уже настолько привыкли, что «глаз замылился» и они просто не воспринимают недостатки объективно.
Даже с языками программирования ситуация лучше — их просто больше, периодически появляются новые, в них реализовано много разных подходов и идей, в том числе экспериментальных, и т.д. Что-то оказывается удачным и попадает в мейнстрим. Но уже никто не делает новые проекты на алголе, фортране или коболе…
Баш там вызывается или cmd — это уже дело вкуса и привычки, если сильно хочется поиграться, то командных интерпретаторов хоть попой ешь
Консоль как паровоз: достигла совершенства, и дальнейшая ее замена должна быть построена на других принципах, даже если будет использовать те же рельсы.
Тот же PS собирать в интерпретаторе — это боль, нельзя просто собрать пайп, надо обязательно строить одноразовый обработчик-финализатор, каждый раз, когда меняется пайп. Плюсом он жутко многодлиннословен, но понятности это не добавляет: по буквально каждому командлету и опции приходится гуглить, что это такое и как его использовать.
Если развивать это дальше (консоль), то получится IDE, потом захочется нормальных типов данных, и вот получился уже убогий, но свой; как системный питон, только поменьше и другой.
Но зачем оно, когда питон уже есть?
Собственно, шеллы на питоне и эликсире тоже не первый год существуют.
Если развивать это дальше (консоль), то получится IDE, потом захочется нормальных типов данных, и вот получился уже убогий, но свой; как системный питон, только поменьше и другой.
Perl и Tcl же!
Оба создавались как «sh с наворотами»
Тот же PS собирать в интерпретаторе — это боль, нельзя просто собрать пайп
Хм… Вот я давеча решил-таки наконец грохнуть дубликаты в иерархии директорий с примерно 120,000 изображений. Ровно один пайп в PowerShell. И довольно короткий — две строки (у меня 140 символов). В нём есть всё, чтобы не накосячить с удалением лишнего — сопоставление по размерам файлов, далее совпавшие по размерам сопоставляются по хэшам, и только при совпадении — удаление. Когда я думаю о том, как бы это пришлось делать в терминале FreeNAS (где всё это и хранится, то есть FreeBSD), я понимаю, что именно это-то и было бы болью на фоне PowerShell.
по буквально каждому командлету и опции приходится гуглить, что это такое и как его использовать.
Гуглить? А
Get-Help Cmdlet -Full мало разве? Больше ты всё равно вряд ли нагуглишь :)А Get-Help Cmdlet -Full мало разве?
Если в ней найдутся примеры для нетривиальных случаев — то, возможно, и достаточно. Примерно в той же мере, что и вывода man или ключа --help.
довольно короткий — две строки (у меня 140 символов)
Это 200-300 символов, примерно.
Учитывая формулировку задачи, для нее пайп подходит плохо.
Кроме того, если файл был положен — значит, он там лежит не просто так, и его следует заменить на хардлинк а не просто удалять.
И стоит отфильтровать/траверснуть симлинки и хардлинки, чего вы не сумеете сделать на PS, не воткнув его прямо на FreeNAS.
А так, единственное видимое препятствие сделать то же на шелле — это фильтрация уников, что, вероятно, не слишком сложно сделать используя awk. И символов получится раза в 2-3 меньше.
find -name *.jpeg -exec 'echo {} > `md5 {}`.md5'; cat *.md5 > unique; find -name *.jpeg -exec 'grep {} unique || rm {}'Первая команда запоминает для каждого хэша один из путей к файлу; последняя удаляет все файлы, не вошедшие в список уникальных.
Люди, незнакомые или почти незнакомые с линуксовой командной строкой и скриптами (как я), смотрят на это как на китайскую грамоту.
это вы PowerShell не видели. Вот где китайская грамота. А линуксовый shell -- это так, pidgin english, осваивается довольно просто, синтаксис отночительно читаемый (если думаете, что нет -- посматрите на Perl или на тот же PowerShell).
Shell -- это так, быстро выдернуть нужное из вывода DB, curl или чего угодно. Если нужна сложная обработка -- довольно быстро упираешься в ограничения и идёшь в Python, например.
Вопрос другой, что изначально использовать Python смысла нет, в 90% случаев -- это из пушки по воробьям.
В чем проблема сразу проверять на смесь табов и пробелов перед исполнением и тут же давать алёрт, дескать, файл запоганен несовместимым редактором, я до сих пор не понимаю.
В итоге всё приходит к тому, что или используется pycharm или в любимом редакторе включается подсветка уайтспэйс, да настраиваются только табы/пробелы как отступ.
Самое смешное, что согласно PEP8 пробелы предпочтительнее, хотя намерение вставить отступ решается одним единственным символом табуляции. Зачем редакторы начали внезапно вставлять несколько пробелов по нажатию клавиши tab необъяснимо.
А редактировать код в блокноте — редкий вариант тантрического секса для многих языков, не только питона.
Зачем редакторы начали внезапно вставлять несколько пробелов по нажатию клавиши tab необъяснимо
Это объяснимо и логично. Если где-то надо задать отступ, некратный размеру табуляции, а по PEP8 это везде, табы и пробелы начинают смешиваться при редактировании в любом тупом редакторе
Если бы все редакторы привели к стандарту, что отступ задается одним символом табуляции, то все эти люди при обмене файлами сохранили свое душевное здоровье — их любимый редактор автоматически использовал сдвиг на их любимое число, заданное в настройках.
Стандарт на 4 пробела навязали IDE — Visual Studio, затем подтянулись Java IDE. Для тех языков количество пробелов и табуляций было не важно. Итак, возник стандарт де-факто навязанный кодерами майкрософт: замена табуляции на 4 пробела.
отступ, некратный размеру табуляцииВот, это и неправильно, уровни вложенности должны быть сделаны именно на табуляции. Один таб — одно смещение на уровень. С пробелами же сейчас можно, вообще, ересь творить: в одном месте 1 пробел, в другом 3, еще дальше 5 и т.д. И только на 4 интерпретатор ругнется наконец. Ну, и напоследок разбавить символами табуляции в самых неприличных местах.
Сильно вложенные штуки удобнее писать с двумя пробелами, иначе текст куда-то в правую половину экрана уезжает…
Но, в целом, вменяемый редактор вместо блокнота — решает.
Питон с табуляцией из-за неудобства неявно бы принуждал к декомпозиции.
Впрочем, сейчас такой проблемы нет, хоть по одному пробелу вложенность делай.
Вывод: использовать табуляцию как основной отступ и в краевых случаях — пробелы.
Ну, собственно, многие современные редакторы и IDE вообще скрывают от пользователя табы там или пробелы используются.
За пробелы — одинаковый вид в любом редакторе, за табы — подстройка представления текста в удобном для чтения виде (при поддержке со стороны редактора).
В чем проблема сразу проверять на смесь табов и пробелов перед исполнением и тут же давать алёрт
В Python 3 так и сделали, теперь это "TabError: inconsistent use of tabs and spaces in indentation"
Люди, незнакомые или почти незнакомые с линуксовой командной строкой и скриптами (как я), смотрят на это как на китайскую грамоту. Даже если они программисты. А те кто каждый день пользуется, уже настолько привыкли, что «глаз замылился» и они просто не воспринимают недостатки объективно.
Ну почему же, с недостатками сталкиваемся систематически, и можно описать их в достаточном количестве, например:
Чрезмерная ориентация на авторазделение аргументов вызывает необходимость использовать всякие "$@" (которые сейчас стандартизованы, но появились как срочный костыль для решения проблемы) и играться с IFS. Чуть ослабленный контроль приводит к ситуациям типа <a href="https://bugzilla.redhat.com/show_bug.cgi?id=622655">такой</a>.
Решение о раскрытии globʼов на уровне вызывающего шелла, пригодное для мелких задач типа ls на файлы, начинает давать проблемы там, где, например, перед каждым файлом надо поставить аргумент его типа. Делегировать же это командам уже не получится (если бы не легаси, можно было бы сделать функцию уровня libc, которая бы это делала по запросу).
Проблемы со смешением аргументов и файлов, которые могут быть восприняты как аргументы (решается '--' в строке аргументов, но нужно, чтобы парсер их понимал).
Вообще шелл выглядит логически незамкнутым как язык; три попытки завершить полное замыкание дали Tcl, Rexx и Perl, каждая в своём специфическом стиле.
Pipeline чреват тем, что предыдущий процесс завершился с ошибкой, а следующий "решил", что поток ввода закончен нормально. Нет возможности передать честный EOF. В стандарте нет возможности получить статусы всех команд в конвейере (в bash есть).
Крайне сложно сделать glob для, например, всех записей в каталоге кроме "." и "..". Хотелось увидеть бы какой-нибудь "**" для этого (и "***" вообще для всех записей каталога), но это уже занято в некоторых местах (типа git) под "пути любой длины".
Это только с ходу. Покопавшись, можно ещё пунктов 20 найти. Но: несмотря на все эти уже известные и помеченные флажками грабли, можно работать и часто удобнее, чем в GUI (а если надо повторять несколько раз - так командная строка бесспорно вне конкуренции).
ИМХО главная проблема на сегодня в том, что все «убийцы sh» оказывались в роли интерактивного шелла и интерпретатора простеньких скриптов неудобнее того же bash.
запрос на новый шелл есть, консенсуса в том каким он должен быть — нет.
$ ls -d /usr/ports/shells/*sh | wc -l
24Это ещё и к имеющемуся запросу на новый шелл (об оном запросе я слышу непрерывно с конца 80-х :)
1) интерактив шелл;
2) шелл скрипты.
Если по второму пункту всё довольно ясно — подойдет парадигма любой ЯВУ, что мы и видим в PowerShell. Да, для скриптов PS хорош, но для задачи «интерактив шелл» — полное дно.
Интерактив шелл имеет специфику — пользователь ожидает максимальную лаконичность/эффективность.
Хороший пример unix, команды из двух-трех символов: ls, cp, mv, cat, — быстро набираются (хотя в те времена были ограничения на длину имени файла). Быстро можно склеить с другими командами конвеером, плюс всё суть файл. Всего две парадигмы и масса компактных утилит позволяло решать многие задачи без написания приложений даже без шелл-скриптов.
Сейчас возможности прокачать интерактив шелл ограничиваются устройствами ввода. Добавление манипулятора мышь ничего кардинально не поменяло. А вот когда появится что-то прорывное, как нейроинтерфейс из фантастики, вот тогда и будет новое развитие шелла. А до тех пор развивается только скриптовая часть.
“Как я запущу Фотошоп на этом вашем Линуксе? Мне же нужно работать, а не заниматься ерундой.”
Ответ:
«А склейкой для этих утилит является простой текст, который они принимают на стандартный ввод, модифицируют в рамках своей работы и передают дальше следующим утилитам. Получается своего рода конвейер данных. Простой, без проблем читаемый людьми текст и является тем универсальным интерфейсом передачи информации.»
Чего? Я хотел почитать про это, а не про то, что вам не нужен фотошоп, ведь в линуксе так много маленьких утилит.
Все те социальные сети и мессенджеры, а также многочисленные интернет-ресурсы, без которых мы не мыслим нашу жизнь сегодня, с подавляющей долей вероятности используют Unix-подобные операционные системы для своего функционирования. И во всех этих и многих других приложениях ваши знания будут актуальны и не устареют ещё очень долгое время.
Я вот без знания консоли мессенджером пользуюсь и на сайты захожу. Нет, я знаю консоль, но в мессенджере пока не довелось воспользоваться этими знаниями, там вроде как-то и не надо.
Статья вкратце:
Вы думаете винда всем командует? Нет, всё чем вы пользуетесь работает на линуксах. И поэтому без умения работать в консоли, вы не сможете делать всё то, что вы и так делали до этого. Задумайтесь.
Обожаю линукс, но смысл таких статей от меня ускользает. Здесь нет ничего ни для новичков, ни для виндузятников (какие-то конвейеры, какие-то цепочки, какие-то утилиты, ответов на вопросы в выделенных блоках нет).
Давайте помогу ответом на заголовок статьи:
Зачем уметь работать в командной строке?
Потому что это охуенно.
Чего? Я хотел почитать про это, а не про то, что вам не нужен фотошоп, ведь в линуксе так много маленьких утилит.
Вообще, я натыкался на установщик фотошопа для линукс. Возможно, стоило к этому рассказать про вайн и тот факт, что устанавливать виндовые программы таки можно?
устанавливать виндовые программы таки можно?
Возможность установить и возможность полноценно использовать — это всё-таки не одно и то же. Если ОС для программы не родная, то проблемы один фиг вылезут, если не сразу (при запуске), то в процессе эксплуатации.
Безусловно, но часто с этими проблемами можно будет смириться.
Взять протон, он не идеален, но всё же позволяет играть в большое количество игр на линукс.
часто с этими проблемами можно будет смириться.
Это теоретически. На практике же, пользователи с этим мириться не хотят и используют ту ОС, которая предоставляет им необходимые возможности. Прошло время, когда от пользователя можно было требовать. Теперь, нравится это или нет — нужно подстраиваться под него.
Что же до «большого количества» игр (приложений), то человек просидевший за ПК хотя бы пару лет, уже обычно имеет несколько программ (и игр), которые являются «теми самыми», «необходимыми», и «любимыми». И если нет возможности, полноценно использовать на альтернативной платформе именно их, то скорее всего, он эту платформу проигнорирует.
Все так, только не забывайте, что с таким подходом придется платить деньги. И не вы будете решать сколько.
на установщик фотошопа для линукс.
Я правильно понимаю, что он качает архив с уже установленным Photoshop'ом с чьего-то сайта. Это как-то… недоверительно.
Сегодня мы поговорим о том, зачем учить операционную систему GNU/Linux,
учат только ламеры, все остальные изучают
С другой стороны, сейчас бывает решаю задачи администрирования Линукс методом последовательного копирования заклинательных команд из найденной страницы в первой десятке гуглопоиска. Потому что это бывает раз в год на полчаса, получаю результат и этим доволен.
А всё остальное находится между этими полюсами. Основные мои рабочие задачи разработчика сейчас решаются без применения консоли вообще. Пусть кто-то в ssh управляет тысячами серверов и деплоит что-то куда-то, а я нет. Вот когда понадобится, тогда и поговорим. А изучать надо то, что интересно и пригодится. А вот если человек не хочет изучать то, что решило бы его задачу оптимальнее — то он сам себе враг, вот и всё.
Как бы я не любил командную строку, думаю, при детальном рассмотрении становится очевидным, почему перспективы у такого подхода нет. Суть командной строки - один из множества вариантов взаимодействия компьютера и человека. Любой интерфейс требует от человека навыков работы с ним. Интуитивно понятный интерфейс требует меньше времени на изучение навыков работы с ним. В этом плане командная строка проигрыает любому визуальному интерфейсу. Вы говорите - существует куча репозиториев с утилитами. ОК. Сколько усилий необходимо затратить что бы найти их? :) Разобраться что там, установить, изучить параметры и начать эффективно использовать?
Я понимаю вашу позицию в целом, однако считаю, что ваше стремление показать прелести командной строки сродни попытке убедить людей массово пересесть на лошадей, потому как у них проходимость выше и ресурсов почти не требуют и т.д. Да, определенно найдутся единицы энтузиастов, разделяющих ваше стремление на Дикий Запад, но нужно хорошо понимать, что основная задача производимых инструментов - скрывать сложность, абстрагировать пользователя от этой самой сложности. И на этом пути консольные утилиты проиграют. Или, скорее, уже проиграли.
Вангую что где-то или уже существует или вот-вот появится визуальный интерфейс для компоновки пайпов из консальных утилит. В котором существует группировка утилит по сути выполняемых задач, параметры сразу показыаются пользователю с возможностью выбора предустановленных значений и т.д. И этот инструмент будет делать две важных вещи: все еще предоставлять гибкость, к которой вы так аппелируете и, второе, скрывать от пользователя сложность (а именно необходимость помнить названия, параметры и значения парамеров каждой из тысячи утилит)
И, возможно, этот интструмент тут же заменит масштабная система конекстного поиска, которая по запросу будет сама компоновать пайп, абстрагируя даже необходимость искать конкрктные утилиты внутри группирования.
Но, коннчно же, среди огромной массы людей всегда найдется пара энтузиастов, утверждающих что наличие токарного станка в гараже, дающего гибкие возможности производства цилиндров для вашего авто, это путь к процветанию и познанию дзена. И будет правы. По-своему :)
В качестве дополнительной иллюстрации позволю себе процитировать свежую статью про гильзы:
Самым очевидным плюсом унитарного патрона стало увеличение скорострельности оружия – уже не приходилось совершать кучу операций, как с дульнозарядным оружием. Закинул патрон, закрыл затвор – и стреляй. Потом к оружию начали массово приделывать магазины, ну а затем и вовсе обленились, переложив функцию передёргивания затвора на энергию пороховых газов.
ну а затем и вовсе обленились, переложив функцию передёргивания затвора на энергию пороховых газов.
Отличный пример, как "оскриптовали" действие в железе :))
спасибо за иллюстрацию на пользу командной автоматизации.
В этом плане командная строка проигрыает любому визуальному интерфейсу.
В том-то и дело, что не всегда. Именно поэтому MS и сделала Power Shell в свое время. И именно поэтому Amazon развивает в AWS консольные утилиты. Консоль и GUI сейчас дают альтернативные пути взаимодействия с продуктом и считается хорошей практикой иметь оба варианта.
cloud.google.com/shell/docs/images/equivalent-gcloud-command.png
Сначала натыкиваете создание объекта (например: инстанса), заполняете все параметры, а потом внизу можно ткнуть в Equivalent REST or command line.
не совсем os, но в ms sql management studio почти на все действия можно посмотреть действующий sql-код.
Любой интерфейс требует от человека навыков работы с ним. Интуитивно понятный интерфейс требует меньше времени на изучение навыков работы с ним. В этом плане командная строка проигрыает любому визуальному интерфейсу.
Это крайне однобокая позиция. Почитайте книгу "Интерфейс человек-компьютер" (Коутс, Влейминк) — она старая, но основные описанные там принципы актуальны без изменения, и там описаны лучше всего из известных мне источников.
Визуальный интерфейс даёт "опережающий вопрос" в терминах авторов, давая наглядные альтернативы для действий, но тем самым 1) ограничивает их набор (включая то, что может разместиться на экране), 2) требует выбора каждый раз. Командная строка (любого вида) это "опережающий ответ"; оно хорошо для уже привычных повторяющихся действий, или же для оскриптованных действий, или когда вариантов выбора столько, что подсказать их всех через визуальный интерфейс неудобно (или даже невозможно — как вы зададите выбор имени для файла, когда его ещё нет, он только будет создан?)
Идеальным вариантом, безусловно, является их комбинация. Например, когда-то командный интерфейс Cisco, с автодополнением по Tab и подсказкой о смысле пунктов, побил всех и задал новый отраслевой стандарт (а сейчас он чуть менее, чем везде, разве что подсказки не рисуют). Или есть варианты, где в визуальном редакторе стандартные пункты, а внизу формируемая командная строка, которую можно потом доредактировать по своему вкусу.
ваше стремление показать прелести командной строки сродни попытке убедить людей массово пересесть на лошадей
А никто вроде ж и не требует тотальной пересадки? (Тем более, что это не лошадь, а мощный автомобиль, по сравнению с самокатиком с автопилотом, но требующий ручного управления.)
Надо уметь пользоваться обоими вариантами средств, и смысл статьи в том, что те, кто ограничивают себя только GUI с аналогами, заведомо теряют в возможностях.
Вангую что где-то или уже существует или вот-вот появится визуальный интерфейс для компоновки пайпов из консальных утилит.
Делали. Уже лет 20 назад. И эти средства не выжили, ибо незачем. Оказалось проще научиться набирать несколько конкретных слов — заклинаний.
И, возможно, этот интструмент тут же заменит масштабная система конекстного поиска, которая по запросу будет сама компоновать пайп, абстрагируя даже необходимость искать конкрктные утилиты внутри группирования.
А вот это уже высокий уровень ИИ, до которого пока не дотянулись.
что наличие токарного станка в гараже, дающего гибкие возможности производства цилиндров для вашего авто
Ваша аналогия некорректна. Достаточно правильной аналогией будет не какой-то токарный станок, а разворачиваемый на ходу лёгким движением цех, способный выполнять всё что угодно, что можно получить из его инструментов и станков, и их комбинаций. И тот, кому надоест 100500-й раз повторять одни и те же монотонные действия, оценит это и дальше сможет даже в простых действиях не мучительно искать нужную кнопку, а сразу назвать целевое действие.
Ну а кто не хочет и хочет чтобы ему по-прежнему было "доползите до выбора из 30 пунктов"… кто я такой, чтобы ему мешать? ;)
“Стойте, а как же .Net? Это же очень популярная технология”
И да, я знаю, что .Net и некоторые другие решения активно используются на бекенде многих уважаемых компаний. Однако, это скорее отклонение от нормы, и мировые тенденции скорее говорят об обратном.
Не так. .Нет фреймвор действительно не поддерживает отличные от виндовс операционные системы. Только вот уже давно выпущены .Нет Кор и сам .Нет, которые являются кроссплатформенными решениями с открытым исходным кодом.
Даже если вы не инженер и непосредственно с вашей деятельностью это перекликается слабо, у операционной системы GNU/Linux в запасе много интересных и полезных инструментов, которые имеют не только специфичное “айтишное” применение, но и являются частью всемирного наследия. К таковым, например, можно отнести систему контроля версий Git и систему компьютерной верстки текста TeX.
При чём тут вообще линукс? Не поймите меня неправильно, сам люблю ГНУ/Линукс, сейчас с него пишу, но Тех и гит кроссплатформенны, это не фича линукса. Другое дело --- удобство, вы можете легко устанавливать эти программы и работать с ними самым стандартным путём.
Все эти утилиты операционной системы, вроде текстового редактора vim, командной оболочки bash, системы инициализации systemd и многих других (нужное подчеркнуть) используются только потому, что все еще по старинке предустановлены в большинстве дистрибутивов и только поэтому все еще популярны
Системд? Пардон, вы явно путаете. Системд --- современный набор программ, первый релиз которого состоялся не так давно, в 2010 году.
Был ли .Net кроссплатформенным с самого начала или стал таким под давлением рынка свободного програмного обеспечения?
Git и TeX даны мной как пример технологий, которые не появились бы без Linux и того положительного вклада, который он принес. Они в полной мере отражают его подход к разработке ПО. То, что технологии кроссплатформенны это, конечно, замечательно.
systemd конечно относительно нов, я не мог об этом не знать. Я включил его как пример тех программ, которые наиболее часто вызывают негативную реакцию и отторжение у людей.
Сегодня редко кто использует сам чистый TeX, хотя фанаты такого подхода все еще присутсвуют. Появился он в 1974 году, это правда. А вот LaTeX уже гораздо популярнее и всего 1984-й год, ровесник проекта GNU. А сегодня, зачастую, те, кто работает с этой технологией использует программы вроде LyX. А это уже 1995-й год. И развивается все это до сих пор. Так что "кто на ком стоял" это еще хороший вопрос.
Был ли .Net кроссплатформенным с самого начала или стал таким под давлением рынка свободного програмного обеспечения?
Какая разница? На вопрос "Стойте, а как же .Net?" вы не отвечаете словами, что .Нет уже давно доступен для линукс, а рассказываете про какие-то исключения. Контрпродуктивно.
Git и TeX даны мной как пример технологий, которые не появились бы без Linux и того положительного вклада, который он принес.
Вы вообще знаете, когда Тех появился? Гит, ок, не было бы без линукса, но, внезапно, у гита есть куча альтернатив.
systemd конечно относительно нов, я не мог об этом не знать
Однако, среди всего многообразия мнений переодически встречается и такое, что весь этот подход устарел и его необходимо полностью пересмотреть. Все эти утилиты операционной системы, вроде текстового редактора vim, командной оболочки bash, системы инициализации systemd и многих других (нужное подчеркнуть) используются только потому, что все еще по старинке предустановлены в большинстве дистрибутивов и только поэтому все еще популярны. Если бы не этот сдерживающий прогресс фактор, не оставляющий шансов молодому поколению в их стремлении “сделать мир лучше”, мы бы уже давно пользовались удобными инструментами, а не были бы заложниками этого исторического хлама.
Баш и вим тут тоже потому, что вызывают негативные эмоции?
Нет, товарищ, вы пишите, что все эти технологии до сих пор используются лишь потому, что они банально устанавливаются в дистрибутивы, несмотря на то, что они устарели. Почему же системд заменила старый сисвинит? Его ведь тоже раньше везде пихали.
Я писал о том, что .Net доступен для Linux когда говорил про Mono.
Выше уже спрашивали про TeX и про 1974 год.
То, что вы процитировали это утверждение от обратного. Как бы то, с чем я не согласен. Из контекста предложения видно.
Насчет systemd нужно сказать "спасибо" RedHat. Очень многим это не понравилось и их можно понять. Хотя systemd был определенным шагом вперед.
В любом случае спасибо вам за конструктивную критику.
Я писал о том, что .Net доступен для Linux когда говорил про Mono.
Моно вообще ни при чём. Дело в самом .Нет, который доступен для линукс.
В любом случае спасибо вам за конструктивную критику.
Спасибо за статью.
Хотя systemd был определенным шагом вперед.
“Вперёд” в сторону чего? Без уточнения непонятно, знаешь ли. В качестве примера: “Кругом и вперёд!” — это как бы “Назад!” по своей сути :)
Был ли .Net кроссплатформенным с самого начала или стал таким под давлением рынка свободного програмного обеспечения?
Правильный ответ лежит посередине между этими двумя: .NET ещё не был кроссплатформенным в момент первого релиза, но в то же время возможность переноса на другие платформы изначально была заложена в его архитектуру, и именно как кроссплатформенный рантайм он и задумывался, в качестве прямого конкурента Java. Кроссплатформенный, но тогда ещё нифига не свободный.
И, например, первая его реализация под Linux вышла всего через два года после Windows-версии.
Статья называется: "Шах и мат, виндузятники!," или почему топор войны линуксоидов и маздайцев до сих пор не зарыт.
Либо въ связи съ появленiемъ болѣе приземлённыхъ задачъ вродѣ обезпеченiя семьи, обслуживанiя ипотеки и т.д.
Действительно! Молодёж вся ерундой-с занимается, это от переизбытка сумасбродства-с. (Да, с "ѣ" выглядит круче, но мне лень так писать). Вот Линус Торвальдс в молодости тоже ерундой занимался, заваривал себе чай, шёл писать Linux, про чай забывал, а тот превращался в плесень. А если бы он раньше встретил Туве, они бы взяли ипотеку, завели восьмерых детей, вот это было бы правильно. У него же был Minix? Был. Насколько я помню из его книжки, он даже запускался у него, позволял работать с большим компьютером в универе, где стоял проприетарный Unix. Чего ещё надо?
Почему-то все говорят о командном интерфейсе как о текстовом? Почему интерфейс не может быть командным, но объектным? Или командным и графическим в одном? Почему-то считается, что текстовые конфигурационные файлы в формате "кто как придумал, так и осталось" это так удобно, так гибко? Разве не удобнее было бы, если бы был единый интерфейс работы с конфигурацией что nginx, что учётными записями пользователей, что ftp сервера?
Разве не удобнее было бы, если бы был единый интерфейс работы с конфигурацией что nginx, что учётными записями пользователей, что ftp сервера?
en.wikipedia.org/wiki/Microsoft_Management_Console
Почему интерфейс не может быть командным, но объектным?
ууу, вам в powershell.
Я сам лично в данный момент часто ей пользуюсь потому как не всегда знаю где в GUI находится та или иная кнопка, а иногда она вообще может отличаться в зависимости от оболочки, естественно есть задачи где наглядность ой как нужна, типа текста или разметки диска или там какие нибудь логи читать, конечно удобнее где есть подсветка, разные интересные кнопочки и все такое. Но многие базовые функции для меня удобно по старинке хотя наверное и в силу привычки больше.
На мой взгляд важно отделить понятие "командный" от понятия "текстовый". Командная строка это отлично. Проблема в том, что там "всё есть текст". А должно быть "всё есть объект", что в принципе должно всё так же хорошо сочетаться с другим базовым принципом "всё есть файл". Который, кстати, давно куда-то потерялся или стёрся. Да, есть Plan9, но он не взлетел.
Кто-то на ЛОРе или другом форуме сказал: "Суть философии UNIX не вы том, чтобы утилиты обязательно передавали друг другу текст, и не в том, чтобы это были однонаправленные pipe'ы. Суть в том, что среда пользователя это среда для программирования". Точную цитату не помню, но не важно. Традиционный пользователь Windows работает с системой (да и программами) как с готовым продуктом, использует те функции и в том виде, как это задумал разработчик. Приверженец философии UNIX сам себе разработчик как правило. Он понимает, как работает система и модифицирует её, сам создаёт себе инструменты.
Bash это такой кривой язык программирования, а простые программы это обычные функции с кривым API, т.к. и аргументы и результаты, всё имеет один тип - "строка". При том тип "строка" тоже не особенно прямой, т.к. благодаря использованию для разделения тех же пробелов, что могут быть в самой последовательности, зачастую непонятно, где символ разделитель, а где часть имени файла, например. Приходится городить всякую ерунду из дополнительных экранирующих символов. Сейчас мне опытные пользователи *nix систем скажут, что ничего сложного тут нет. Но с пробелом это только один пример. Ещё бывает забавно, когда имя файла начинается с символа "-". Вообще ситуация чем-то напоминает работу со стоками в языке C. Если бы перед строкой в C хранилась её длина, вместо завершающего символа 0, то не было бы кучи уязвимостей.
Так устарела ли философия UNIX? Конечно нет! Но это если её понимать как "Среда пользователя это и среда программирования". А вот её образующие элементы однозначно пора заменить. Давно пора перейти от передачи текста к передаче неких стандартных объектов или структур. Более того, это надо было сделать давным давно. Возможно тогда и GUI в мире *nix развивался бы иначе.
Программы с графическим интерфейсом в *nix системах вполне такие же, как и в мире Windows (может быть и macOS тоже). Они большие и мало связаны между собой. GUI приложения мало связаны с командной строкой. Почему-то все решили, что когда графический интерфейс отдельно, а командный отдельно, то так и должно быть. Но так быть недолжно. Я не зря написал "командный" вместо "текстовый". Понятие "командный" не ограничивает взаимодействие только вводимыми и выводимыми символами. Например:
ls photos-dir/*.jpg | filter color_mode == CMYK | filter same_face_as='another-photos-dir/my-friend-petya.jpg' | show thumbnailsТ.е. должна быть возможность показать результат работы команд в некотором графическом представлении. Да, это можно сделать и сейчас. Можно написать скрипт, который, например насоздаёт символьных ссылок на результаты работы фильтра. Но это костыль. Гораздо удобнее было было передать список объектов дальше по цепочке так, чтобы его могло прочитать любое приложение и не возникло бы никаких проблем с тем, что там написано в именах, как именно разделяются имена файлов друг от друга и т.п.
А текст? Текст вообще это зло. Например, в GNU/Linux не должно быть /etc но должен быть свой аналог реестра. Да, я догадываюсь, что сейчас юниксоиды могут начать закидывать меня помидорами. Но необязательно переносить все недостатки из Windows. Это может быть множество файлов, а не парочка больших, можно сделать описание параметров, их базовую проверку (диапазоны и списки возможных значений). Комментарии при этом тоже никуда не денутся. И аргумент "текст можно отредактировать чем угодно" не совсем правильный. Текст крайне неудобно редактировать без текстового редактора. Да, они есть везде, но так же везде бы были и средства работы с реестром.
Гораздо удобнее было было передать список объектов дальше по цепочке так, чтобы его могло прочитать любое приложение и не возникло бы никаких проблем с тем, что там написано в именах, как именно разделяются имена файлов друг от друга и т.п.
Посмотрите nu shell, вам должно понравиться.
Говоря же о том почему линукс занял заметное место на серверах — в первую очередь банально из-за денег, он был бесплатным, а закупить у МС сотни или тысячи серверных лицензий, влетало в приличные деньги
ОС, тем более серверных, намного больше чем две — взять хотя бы OpenVMS.
Гуй может быть удобнее только если ты делаешь что-то один раз и все. Если хоть что-то делается больше одного раза, сразу консоль идет вперед. Но не баш из под коробки конечно, я имею ввиду zsh с autojump, autocomplete, fzf и тд. Банальный переход в папку проекта у меня j<пробел><часть имени проекта>. Когда привык к консоли/виму или емаксу/і3, использовать мышь это как говорить с умственно отсталым человеком. Нужно медленно и очень ограниченно говорить простыми предложениями. Как бы можно, но очень неудобно и реально напрягает.
Все это чудовищная трата времени бывает, в сравнении например с каким-нибудь GUI, который при прочих равных будет понятен буквально с 1 взгляда и нескольких потраченных секунд.
Моё любимое ;)
интерфейс doublecmd (кликните для увеличения):
интерфейс totalcmd (по сути такой же)
Все это чудовищная трата времени бывает, в сравнении например с каким-нибудь GUI, который при прочих равных будет понятен буквально с 1 взгляда и нескольких потраченных секунд.
То-то у нас вокруг сплошь мастера фотошопа, моделлинга и верстки, да?
А что вас, простите, удивляет?
Цитата прямо из вас, уже приводилась:
Все это чудовищная трата времени бывает, в сравнении например с каким-нибудь GUI, который при прочих равных будет понятен буквально с 1 взгляда и нескольких потраченных секунд.
Или, начнем с простого, в вашей неумолимой реальности уже все-все делают все-все документы в ворде используя стили? Хотя бы.
А ведь этот понятный буквально с 1 взгляда и нескольких потраченных секунд у некоторых перед глазами уже лет 30. Причем стили и кнопки выравнивания почти два десятилетия были прямо под носом.
Только вот утверждать этого вы не сможете. А значит, вам придется признаться, что вы соврали.
А на том утверждении, постулируемом вами как догма, строится и вся дальнейшая цепочка, которая из типа умного кидания понтов превратится в балаганное скоморошество. И минус ваш из благородной кары, каким вам его хочется представлять, тоже мутирует…
Зачем уметь работать в командной строке?