Comments 34
«Yes, I use xmpp-client as my jabber client,» Soghoian wrote.
«Да, я использую xmpp-клиент Jabber для переписки», – пишет Согхоян.Божественный перевод
устаревшие почтовые клиентыНет, старые. Но не устаревшие.
Я вот ни разу не специалист по IT-безопасности, но тоже пользуюсь mutt. Причина простая: гораздо удобнее и мощнее большинства GUI-клиентов.
На счет мощнее — спорный вопрос. Та же сортировка по папкам ведь не средствами клиента делается? ;)
Или mutt уже дошел до жизни такой, что procmail не нужен?
Или mutt уже дошел до жизни такой, что procmail не нужен?
Не знаю, я никогда procmail не использовал. Но мощность же, как раз, в unix way — очень просто письма отправлять на произвольную внешнюю обработку.
А как вы тогда письма сортируете?
При помощи sieve на сервере.
Ну всё равно же не средства mutt'a. Так что нельзя говорить, что он «мощнее большинства клиентов», сам по себе он не так уж и много может.
Зато, он может самое главное — относительно адекватно работать с внешними программами.
А графические клиенты что, все этого не умеют? В той же летучей мыши была возможность отдать информацию внешнему обработчику и принять её.
Хотя я уже давно на всё это забил, сейчас количество почты в разы меньше, чем лет десять-пятнадцать назад, потому вполне хватает вебинтерфейса с десятком фильтров и нормальным поиском.
А большинству людей и фильтры не нужны при их объемах почты…
Хотя я уже давно на всё это забил, сейчас количество почты в разы меньше, чем лет десять-пятнадцать назад, потому вполне хватает вебинтерфейса с десятком фильтров и нормальным поиском.
А большинству людей и фильтры не нужны при их объемах почты…
Не знаю. Может быть, и умеют. Но эти настройки зарыты где-то глубоко в глубинах менюшек. А в том же mutt я просто набираю
Казалось бы мелочь, но экономит кучу умственных усилий и времени на цепочке: выделить, открыть, скопировать, вставить, придумать куда сохранить, сохранить, отправить и так далее.
И вот эти разнообразные shell-оut-ы прямое наследие CLI. Для GUI было бы неплохо придумать похожие механизмы, мне кажется. Но пока, максимум, что у нас есть — это mime.
| ssh http@host tee tmp/pdf/ и pdf-ка из письма улетает сразу на сервер. Аналогично можно патчить что-нибудь или отсылать куски кода на исполнение. Много сценариев. Можно, конечно разбор по mime настроить, но это не гибко. Иногда pdf-ку надо открыть для просмотра, а иногда просто выложить на сервер по ssh.Казалось бы мелочь, но экономит кучу умственных усилий и времени на цепочке: выделить, открыть, скопировать, вставить, придумать куда сохранить, сохранить, отправить и так далее.
И вот эти разнообразные shell-оut-ы прямое наследие CLI. Для GUI было бы неплохо придумать похожие механизмы, мне кажется. Но пока, максимум, что у нас есть — это mime.
Зашел сюда с мыслью — да какие же они спецы по безопасности, если сами пользуются устаревшим софтом. А оказывается, софт-то у них, что называется, up-to-date, да только он без всяких рюшечек и финтиплюшечек. М — мастерство заголовка. Тогда и я пользуюсь «устаревшим» софтом bash и vim.
Если дело только в количестве кода, то может писать почтовики на вероятностных языках?
«Вероятностное программирование в компьютерном зрении: 31 строка кода вместо тысяч» — https://geektimes.ru/post/248988/
«Вероятностное программирование в компьютерном зрении: 31 строка кода вместо тысяч» — https://geektimes.ru/post/248988/
Все эти спецы как-то забывают сказать, что mutt сам по себе довольно ограничен. Фактически, это только приёмник. Даже чтоб отправлять сообщения, вам потребуется ставить что-то ещё.
И если GUI-клиент — это всё в одном, то тут вам потребуется для полноценной работы с почтой кроме самого mutt, в котором действительно мало кода и мало уязвимостей, ставить и настраивать ещё SMTP-клиент, текстовый редактор, кучу расширений, которые наверняка потянут за собой Perl/Python. И вот уже количество строк кода начинает приближаться к монолитному мейл-клиенту.
А потом все эти разрозненные модули нужно как-то состыковать друг с другом, чтоб всё работало, причём вот эти стыки между модулями и есть самое настоящее решето. В монолитном клиенте модули состыкуют сами разработчики, и если на стыках что-то не так — рано или поздно все эти уязвимости выловят. В случае же mutt каждый остаётся один на один с теми уязвимостями, которые он сам создал на стыках.
И если GUI-клиент — это всё в одном, то тут вам потребуется для полноценной работы с почтой кроме самого mutt, в котором действительно мало кода и мало уязвимостей, ставить и настраивать ещё SMTP-клиент, текстовый редактор, кучу расширений, которые наверняка потянут за собой Perl/Python. И вот уже количество строк кода начинает приближаться к монолитному мейл-клиенту.
А потом все эти разрозненные модули нужно как-то состыковать друг с другом, чтоб всё работало, причём вот эти стыки между модулями и есть самое настоящее решето. В монолитном клиенте модули состыкуют сами разработчики, и если на стыках что-то не так — рано или поздно все эти уязвимости выловят. В случае же mutt каждый остаётся один на один с теми уязвимостями, которые он сам создал на стыках.
Все эти спецы как-то забывают сказать, что mutt сам по себе довольно ограничен. Фактически, это только приёмник. Даже чтоб отправлять сообщения, вам потребуется ставить что-то ещё.
Не соглашусь с вами. В нем есть реализация работы с протоколами pop3, imap4, smtp.
Не знаю, чем он там ограничен… Я им пользуюсь с девяностых, сейчас вот заглянул в .muttrc, в .mailcap, в /etc/portage/patches/mail-client/mutt/ — вот всё, что накопилось за столько лет:
- в
.muttrcодна строка (в смысле, запускающая внешние команды — а сам.muttrcу меня по-больше одной строки :)) динамически определяющая список mailboxes из существующих файлов в~/Mail/:find … | sort … | sed … - в
.mailcapцелых 3 строки: просмотр html-писем внутри mutt черезlynx -dump, и запуск просмотрщиков для картинок и pdf - дополнительных патчей у меня для mutt целых два: один добавляет мелкую фишку для юзабилити (автоматическое добавление настраиваемого приветствия/подписи в зависимости от, например, получателя), а второй добавляет поддержку s/mime
Ну и разбором входящих писем по отдельным папкам занимается не mutt — ну так оно вроде так и задумано в *NIX. Никаких "расширений" тянущих perl/python нет. Что касается необходимости в текстовом редакторе — да, это серьёзно. Действительно, кому был бы нужен текстовый редактор, если бы не этот чёртов устаревший mutt. :-)
Вообще предпочитаю консольный софт вместо гуевого: почта — mutt, torrent — rtorrent, XMPP — CenterIM, RSS — Newsbeuter, был бы браузер с поддержкой всех фишек html5 тоже использовал бы консольный. Все это счастье очень удобно держать в screen на удаленном сервере и подключаться практически с любого устройства на любом качестве канала, к комбинациям клавиш очень быстро привыкнуть и все выходит в разы быстрее чем тыкать мышкой, потребляет минимум ресурсов, бережет батарею ноутбука и главное не тормозит. Очень жалею что развитие софта идет не в сторону функционала и удобства быстрого пользования, а в сторону гуйни, где на функцию в пару килобайт наворочено фреймворков и гуев с рюшечками на сотни мегабайт, все это тупит, в каждой версии нескучные обои и новые расположения кнопок, зато дизайнеры могут самовыражаться.
А торрентом Вы тексты песен и субтитры качаете да? Так вышло, что человеку проще работать с графическим представлением информации. Да, можно пересилить себя и научиться делать всё в консоли, но профит уж очень сомнительный.
А чем консоль является не графическим представлением? Та же графика без гор лишних рюшечек и тормозов, да я вижу только информацию и только ту что мне необходимо видеть, кучи кнопочек, иконок, чекбоксов и прочего GUI не загораживают мне основные возможности софта, возможно для вас будет открытием но есть нормальные консольные плееры, хотя фильмы я все-же предпочитаю смотреть на телевизоре через Kodi. Тот же mutt я могу в пару команд подружить с procmail и вся почта будет удобно разгребаться по правилам, а не как в графическом софте есть фильтр А и фильтр Б, а все что в них не входит, ну не повезло терпи, зато когда почта отправляется красивую анимацию посмотри, красивую анимацию смотреть приятней чем какие-то фильтры настраивать, так что не парься, дизайнер так видит. А пересиливать себя не нужно, если вас устраивает ваша скорость работы с текущим софтом, то значит все хорошо и нет смысла ничего менять, но мне проще запомнить 10 комбинаций клавиш которыми я пользуюсь каждый день в слепую и один раз отредактировать текстовый конфиг, чем искать нужны настройки в каждой новой версии в новом месте и тыкать 20 выпадающих списков. Сложно объяснить тому, кто никогда не пользовался, ну разве что посмотрите на ютьюбе работу в консольном vim того для кого это ежедневный рабочий инструмент и сравните с возможностями графического стандартного блокнота любой ОС а главное со скоростью работы над текстом.
Ок, убедили. А зачем Вам браузер с поддержкой всех фишек HTML5 в консоли?
Ютьюб смотреть :). А если серьезно, чтоб современные сайты корректно открывались и работали, вот открыл такой браузер на сервере с нужными вкладками и ходи откуда угодно смотри, читай с того же места, я знаю что в большинстве браузеров сейчас есть синхронизация, но работает она приотвратительно, как минимум с задержкой сильной, ну и авторизироваться надо заново на многих сайтах с вводом капчи и в лучшем случае откроет ту же страницу, но не на том же месте где я закончил читать, на маке более менее работает, но только в сафари, к которому нет кучи нужных мне плагинов и который завязан на продукцию яблока, в ФФ и Хром куча косяков. Консольные приложения не значит древний хлам, который ничего не умеет, это такие же приложения с вполне современными возможностями, но где вместо GUI использован псевдографический интерфейс или командная строка, благодаря чему становится возможным управление из удаленного терминала по SSH, требования к каналу ниже, работать быстрее, ничего не отвлекает внимание от основной функции приложения, опять-же возможность запуска в скриптах, попробуйте без секса написать простейший скрипт к GUI приложению который в определенном порядке зайдет и нажмет в нем нужные кнопки, можно но сложно и неудобно. Мои сценарии работы ближе всего к работе на мэйнфрейме, когда все что надо крутится на мощном сервере, с хорошей сетью, большим количеством места, рейдами, бэкапами, ключами авторизации и т.п. я же просто с различных устройств подключаюсь туда и работаю, при этом я могу подключиться с мобильного канала в лесу или вообще с чужого рабочего места при этом мне надо иметь под рукой полностью развернутое окружение для работы, а не парится с установкой и настройкой инструментов на месте.
В природе, кстати, существуют графические консоли. Посмотрите, например, на блокнотный интерфейс той же Wolfram Mathematica. Крайне мощная штука.
Тут всё дело не собственно в графике, а в том, что для консольных приложений есть инструменты составления из них композиций (pipe-ы всякие, shellout-ы или просто функциональная композиция, как в Mathematica), а для GUI ничего похожего нет, разве только буфер обмена, но его толком не автоматизируешь.
Поэтому, в реальности, человеку, который хоть немного понимает в программировании удобнее, как раз, работать с консольными интерфейсами, а не с GUI. Так обрабатывать информацию и проще, и быстрее. Другое дело, что мозгу человека не-программиста по некоторым нейропсихологическим причинам гораздо проще работать с мышкой и GUI. Поэтому, собственно, GUI и является основным типом интерфейсов. Но за эту простоту приходится расплачиваться скоростью работы с информацией.
Тут всё дело не собственно в графике, а в том, что для консольных приложений есть инструменты составления из них композиций (pipe-ы всякие, shellout-ы или просто функциональная композиция, как в Mathematica), а для GUI ничего похожего нет, разве только буфер обмена, но его толком не автоматизируешь.
Поэтому, в реальности, человеку, который хоть немного понимает в программировании удобнее, как раз, работать с консольными интерфейсами, а не с GUI. Так обрабатывать информацию и проще, и быстрее. Другое дело, что мозгу человека не-программиста по некоторым нейропсихологическим причинам гораздо проще работать с мышкой и GUI. Поэтому, собственно, GUI и является основным типом интерфейсов. Но за эту простоту приходится расплачиваться скоростью работы с информацией.
Вообще-то, всё зависит от типа обрабатываемой информации. Пока вы живёте в мире простого текста — то да, может с ним и проще в текстовой консоли ковыряться. Но когда дело доходит хотя бы до форматирования текста, то тут уже простая консоль не прокатит.
Не, может вы и можете читая теховские теги сразу представлять, как будет выглядеть текст. Но не большинство людей. Им проще выделить абзац, вставить формулу или нарисовать табличку мышкой в GUI.
Не, может вы и можете читая теховские теги сразу представлять, как будет выглядеть текст. Но не большинство людей. Им проще выделить абзац, вставить формулу или нарисовать табличку мышкой в GUI.
Так командная консоль не обязательно должна быть исключительно текстовой. Ещё во времена lisp-машин в консоли можно было свободно работать с графикой.
Современный вариант реализации идеи в Wolfram Language:
Собственно, основной смысл консольного CLI не в тексте, а в развитых средствах композиции утилит и приложений. Если в GUI нужно постоянно заполнять какие-то формочки, да ещё и не факт, что среди них есть нужные, то в CLI, благодаря средствам композиции программ, мы просто описываем то, что хотим. И в этом мощь и удобство.
А что касается TeX, то он с этой точки зрения, скорее GUI, чем CLI. Средства композиции там взрывают мозг на каждом шаге, поэтому, единственный доступный обычному пользователю вариант работы — использование ограниченного набора стандартных форм. Так что, TeX — это такое GUI в не самом лучшем варианте.
Современный вариант реализации идеи в Wolfram Language:
Собственно, основной смысл консольного CLI не в тексте, а в развитых средствах композиции утилит и приложений. Если в GUI нужно постоянно заполнять какие-то формочки, да ещё и не факт, что среди них есть нужные, то в CLI, благодаря средствам композиции программ, мы просто описываем то, что хотим. И в этом мощь и удобство.
А что касается TeX, то он с этой точки зрения, скорее GUI, чем CLI. Средства композиции там взрывают мозг на каждом шаге, поэтому, единственный доступный обычному пользователю вариант работы — использование ограниченного набора стандартных форм. Так что, TeX — это такое GUI в не самом лучшем варианте.
А теперь попытайтесь уговорить фотографа заняться ретушью при помощи текстовых команд, а не мыши. Вон, в автокаде есть командная строка — но что-то не вижу тех, кто постоянно бы ей пользовался.
GUI хорош тем, что, во-первых, он интерактивен — вы двигаете ползунок и в реальном времени видите изменения картинки (к примеру). Во-вторых, менее дискретен — вам не надо думать о том, что «надо поставить курсор в 1,1 или на 30 символ строки». Вы просто ставите курсор куда надо. В-третьих, в формочках можно встроить проверку при вводе — или вообще заблокировать возможность вводить фигню (выпадающий список, например), а в текстовых конфигах для проверки придется их парсить. Да и то, иногда с синтаксической точки зрения всё нормально, а в итоге получается фигня из-за того, что в конце строки был пробел…
GUI, в целом, одинаков — достаточно читать названия пунктов и пояснения к ним. В командной строке вам придется учить команды для каждой программы.
С GUI вы просто показываете что хотите. С CLI — вы пытаетесь описать, но не на живом языке, а на языке той программы, с которой общаетесь. Который еще и выучить надо…
И т.д., и т.п.
Наличие GUI не отменяет наличия CLI. GUI — это интерактив, «непрерывная» работа. А CLI — либо диалог, когда вы даёте команды, получаете ответы, обдумываете их и даёте новые команды, либо автоматизация, когда ответы вас не волнуют.
И говорить о превосходстве одного над другим в отрыве от конкретной задачи нельзя.
GUI хорош тем, что, во-первых, он интерактивен — вы двигаете ползунок и в реальном времени видите изменения картинки (к примеру). Во-вторых, менее дискретен — вам не надо думать о том, что «надо поставить курсор в 1,1 или на 30 символ строки». Вы просто ставите курсор куда надо. В-третьих, в формочках можно встроить проверку при вводе — или вообще заблокировать возможность вводить фигню (выпадающий список, например), а в текстовых конфигах для проверки придется их парсить. Да и то, иногда с синтаксической точки зрения всё нормально, а в итоге получается фигня из-за того, что в конце строки был пробел…
GUI, в целом, одинаков — достаточно читать названия пунктов и пояснения к ним. В командной строке вам придется учить команды для каждой программы.
С GUI вы просто показываете что хотите. С CLI — вы пытаетесь описать, но не на живом языке, а на языке той программы, с которой общаетесь. Который еще и выучить надо…
И т.д., и т.п.
Наличие GUI не отменяет наличия CLI. GUI — это интерактив, «непрерывная» работа. А CLI — либо диалог, когда вы даёте команды, получаете ответы, обдумываете их и даёте новые команды, либо автоматизация, когда ответы вас не волнуют.
И говорить о превосходстве одного над другим в отрыве от конкретной задачи нельзя.
1. А зачем мне заставлять фотографа это делать? Никто же не отрицает, что есть ситуации, в которых клавиатура не является самым удобным средством ввода. Мышка тоже бывает полезной. В AutoCAD есть AutoLisp, которым активно народ пользуется для формирования сложных параметризованных профилей. Этому даже архитекторов учат. Некоторые вещи очень сложно мышкой накликать.
2. Так современные CLI давным давно позволяют выбирать из списков, пользоваться автоподстановками и прочими радостями. А конкретную строку и позицию для редактирования я указывал единственный раз, когда баловался с редактором ed. Было, кстати, не так уж и плохо. Но в любом нормальном текстовом редакторе для консоли развиты средства быстрой навигации по коду. Обычно есть система маркеров, по которым можно очень быстро прыгать. Гораздо эффективнее прокрутки и прицельных кликов в нужное место.
3. Это как раз с CLI указываю то, что хочу. Люди, на самом деле, весьма неплохи в деле освоения новых языков. Тем более, в реальной жизни надо запоминать не так уж и много команд. Это не сложно. А вот в GUI мне постоянно приходится искать и вспоминать, где оно расположено. Я, конечно, в итоге, запоминаю, где необходимый мне пункт зарыт в меню, но это всегда долгая навигация по дереву.
И, собственно, никакой интерактивности в этом нет. В большинстве GUI мы имеем дело всё с тем же диалогом и командами с параметрами, просто вместо нажимания кнопок мы должны ещё подвести курсор мышки и кликнуть на виртуальном аналоге клавиатурной кнопки. Лишние накладные расходы, мне кажется.
Кстати, пример из жизни. Раньше платежи за квартиру принимали на почте. И раньше у них была система для регистрации платежей, которая работала в текстовом терминале SCO. И там был шикарно продуман workflow, был правильно выбран набор команд с клавиатуры, и кассирши очень быстро обслуживали очереди. А потом им поставили Windows, GUI и всякие вот эти выпадающие менюшки: вместо того, чтобы нажать одну кнопку для выбора типа платежа, им пришлось выбирать это всё мышкой из меню, вместо последовательного ввода идентификаторов клиентов, им пришлось тыкать мышками в нужные поля формы, и так далее. Очереди сразу существенно выросли. И так и держались до тех пор, пока они не перешли на штрих-коды.
Даже в обработке изображений командный интерфейс иногда удобнее. Например, если речь идёт о выборе оптимальных параметров фильтра. Я обычно просто пишу цикл по диапазону параметров, генерирую кучу картинок, а потом на глаз выбираю наилучший вариант. С ползунком проход по диапазону затянулся бы для меня надолго, потому что я плохо чувствую, в какую сторону и что надо менять. А так, запустил imagemagick, и просматриваешь галерею с разными возможными вариантами. Ну, и примерно, за 2-3 итерации можно найти лучшие параметры.
4. Конечно же мышка и прочие устройства подобного ввода необходимы. Но я повторюсь, что основная фишка CLI — это не собственно возможность настукивать всё на клавиатуре, а наличие механизмов для композиции программ. Для организации их совместной работы. В этом мощь. В современных же GUI нет никаких подобных механизмов вообще. Поэтому они и кажутся лично мне неуклюжими: одна и та же функциональность по N раз реализована в N приложениях и все N раз кривовато, и не подправить никак. А в CLI, даже если что-то криво, то подправить зачастую можно. В этом преимущество.
5. Надо работать над симбиозом каким-то между CLI и GUI, а не разделять их. В Lisp-машинах хорошо было сделано, мне кажется.
2. Так современные CLI давным давно позволяют выбирать из списков, пользоваться автоподстановками и прочими радостями. А конкретную строку и позицию для редактирования я указывал единственный раз, когда баловался с редактором ed. Было, кстати, не так уж и плохо. Но в любом нормальном текстовом редакторе для консоли развиты средства быстрой навигации по коду. Обычно есть система маркеров, по которым можно очень быстро прыгать. Гораздо эффективнее прокрутки и прицельных кликов в нужное место.
3. Это как раз с CLI указываю то, что хочу. Люди, на самом деле, весьма неплохи в деле освоения новых языков. Тем более, в реальной жизни надо запоминать не так уж и много команд. Это не сложно. А вот в GUI мне постоянно приходится искать и вспоминать, где оно расположено. Я, конечно, в итоге, запоминаю, где необходимый мне пункт зарыт в меню, но это всегда долгая навигация по дереву.
И, собственно, никакой интерактивности в этом нет. В большинстве GUI мы имеем дело всё с тем же диалогом и командами с параметрами, просто вместо нажимания кнопок мы должны ещё подвести курсор мышки и кликнуть на виртуальном аналоге клавиатурной кнопки. Лишние накладные расходы, мне кажется.
Кстати, пример из жизни. Раньше платежи за квартиру принимали на почте. И раньше у них была система для регистрации платежей, которая работала в текстовом терминале SCO. И там был шикарно продуман workflow, был правильно выбран набор команд с клавиатуры, и кассирши очень быстро обслуживали очереди. А потом им поставили Windows, GUI и всякие вот эти выпадающие менюшки: вместо того, чтобы нажать одну кнопку для выбора типа платежа, им пришлось выбирать это всё мышкой из меню, вместо последовательного ввода идентификаторов клиентов, им пришлось тыкать мышками в нужные поля формы, и так далее. Очереди сразу существенно выросли. И так и держались до тех пор, пока они не перешли на штрих-коды.
Даже в обработке изображений командный интерфейс иногда удобнее. Например, если речь идёт о выборе оптимальных параметров фильтра. Я обычно просто пишу цикл по диапазону параметров, генерирую кучу картинок, а потом на глаз выбираю наилучший вариант. С ползунком проход по диапазону затянулся бы для меня надолго, потому что я плохо чувствую, в какую сторону и что надо менять. А так, запустил imagemagick, и просматриваешь галерею с разными возможными вариантами. Ну, и примерно, за 2-3 итерации можно найти лучшие параметры.
4. Конечно же мышка и прочие устройства подобного ввода необходимы. Но я повторюсь, что основная фишка CLI — это не собственно возможность настукивать всё на клавиатуре, а наличие механизмов для композиции программ. Для организации их совместной работы. В этом мощь. В современных же GUI нет никаких подобных механизмов вообще. Поэтому они и кажутся лично мне неуклюжими: одна и та же функциональность по N раз реализована в N приложениях и все N раз кривовато, и не подправить никак. А в CLI, даже если что-то криво, то подправить зачастую можно. В этом преимущество.
5. Надо работать над симбиозом каким-то между CLI и GUI, а не разделять их. В Lisp-машинах хорошо было сделано, мне кажется.
1. Ну если уж говорите про тотальное превосходство CLI…
2. А что мешает вам в том же ворде по содержанию перемещаться, а не прокручивать экраны?
3. То есть текстовые команды нескольких программ вы помните, а кнопки и пункты меню вы постоянно забываете? Ну так поиском пользуйтесь, для кого справка придумана?
4. А оно надо? Не вам лично, не программистам, а людям вообще? Табличка из 1С в эксель через буфер вставляется без проблем и дальше обрабатывается средствами экселя. Если надо, потом импортируется обратно в 1с. И не надо никакой командной строки.
2. А что мешает вам в том же ворде по содержанию перемещаться, а не прокручивать экраны?
3. То есть текстовые команды нескольких программ вы помните, а кнопки и пункты меню вы постоянно забываете? Ну так поиском пользуйтесь, для кого справка придумана?
4. А оно надо? Не вам лично, не программистам, а людям вообще? Табличка из 1С в эксель через буфер вставляется без проблем и дальше обрабатывается средствами экселя. Если надо, потом импортируется обратно в 1с. И не надо никакой командной строки.
2. Просто не знаю, как там это можно сделать, и даже не знаю, по каким ключевым словам искать помощь.
3. Не понимаю, в чём проблема запомнить связь между буквами и действиями. Это намного проще, чем запомнить маршурт в дереве вариантов меню. Да и сам выбор нужного пункта — дело более сложное: открываем, читаем, наводим мышку, открываем, читаем, и так далее. Вместо того, чтобы сразу вспомнить, что надо написать ключик из пары буковок.
Кстати, у CLI есть ещё одно достоинство: в сложных случаях по примерному тексту команды можно нагуглить решение. С GUI придётся долго придумывать комбинацию из правильных ключевых слов. Помнится, как я с настройками Eclipse в своё время мучился. Это гораздо сложнее было, чем просто в командной строке указать нужный ключ для препроцессора.
4. Я думаю, что надо. Сейчас в GUI постоянно нарушается принцип: don't make a human do a machine job. Очень много всего можно автоматизировать при помощи довольно простых утилит с тривиальными настройками в несколько параметров, если бы их можно было бы как-нибудь компоновать стандартными методами. Но вместо этого частенько приходится всё повторять и повторять один и тот же выбор, проматывая длинные списки иерархических меню. Да, блин, если бы даже в GUI просто добавили бы возможность и кнопочку универсальную: запомни или воспроизведи мой ввод здесь (как это сделано в большинстве CLI, где есть история команд) — жизнь бы стала намного проще. Особенно на смартфоне.
3. Не понимаю, в чём проблема запомнить связь между буквами и действиями. Это намного проще, чем запомнить маршурт в дереве вариантов меню. Да и сам выбор нужного пункта — дело более сложное: открываем, читаем, наводим мышку, открываем, читаем, и так далее. Вместо того, чтобы сразу вспомнить, что надо написать ключик из пары буковок.
Кстати, у CLI есть ещё одно достоинство: в сложных случаях по примерному тексту команды можно нагуглить решение. С GUI придётся долго придумывать комбинацию из правильных ключевых слов. Помнится, как я с настройками Eclipse в своё время мучился. Это гораздо сложнее было, чем просто в командной строке указать нужный ключ для препроцессора.
4. Я думаю, что надо. Сейчас в GUI постоянно нарушается принцип: don't make a human do a machine job. Очень много всего можно автоматизировать при помощи довольно простых утилит с тривиальными настройками в несколько параметров, если бы их можно было бы как-нибудь компоновать стандартными методами. Но вместо этого частенько приходится всё повторять и повторять один и тот же выбор, проматывая длинные списки иерархических меню. Да, блин, если бы даже в GUI просто добавили бы возможность и кнопочку универсальную: запомни или воспроизведи мой ввод здесь (как это сделано в большинстве CLI, где есть история команд) — жизнь бы стала намного проще. Особенно на смартфоне.
Да. И ещё пришло в голову. Вот Вы говорите — можно поискать в помощи. Но на самом деле, что такое поиск? Это мы берём и вводим некий поисковый запрос в виде текста в некоторую строку. В командной строке мы делаем то же самое, по большому счёту. Дальше операционка ищет программу по названию, а программа необходимую функцию по указанному ключу. Да, с командными строками всё более формально и жёстко, но принцип тот же. В итоге, всё так же сводится к запоминанию определённых ключевых слов. Работают те же самые отделы мозга.
Развитие софта идет в сторону извлечения прибыли. А консольный почтовый клиент уже сделан, на нем не заработать :)
Из своих наблюдений я бы сказал, что опытных админов, безопасников и вообще технических спецов, отличает не привычка использования mutt (это редкость), а привычка отключать html отображение писем и нелюбовь к почтовым веб интерфейсам в принципе.
> Количество уязвимостей, найденных в mutt за последние 10 лет, ничтожно мало по сравнению с уязвимостями в браузерах вроде Firefox и Chrome и почтовых клиентах, таких как Outlook и Thunderbird.
А сколько человек, ищущих уязвимости в mutt приходится на тысячу тех кто ищет уязвимости в хромиуме или мозилле?
А сколько человек, ищущих уязвимости в mutt приходится на тысячу тех кто ищет уязвимости в хромиуме или мозилле?
«Минималистичный» не есть «устаревший».
Устаревший софт это тот разработка которого завершилась много лет назад. Но тот же mutt продолжает развиваться
Sign up to leave a comment.
Почему эксперты по безопасности предпочитают устаревшие почтовые клиенты