powerman
0
с парой секунд ожидания на старте мы готовы мириться.

Если Вы про время старта zsh, то это, вообще-то, проблема решаемая. Я лично не люблю автоматическое обновление плагинов, ни для vim, ни тем более для шелла (помимо прочего, это ещё и немаленькая дыра в безопасности) — я лучше буду делать плагинам git pull когда мне это нужно, ещё и посмотрев при этом git diff. А вот скорость работы я люблю, включая скорость запуска (у меня постоянно запущено под 20 терминалов, и все они автоматом запускаются при загрузке компа).


Если выкинуть сложную и медленную логику обновления разных типов плагинов, то всё остальное можно заоптимизировать при желании на пару порядков относительно "самого быстрого фреймворка":


% time zsh -i -c 'echo ok'
ok

0.037 real  0.025 user  0.009 sys  8MB RAM

Это скорость запуска весьма навороченного конфига (там только моего кода около 1000 строк, плюс кучка плагинов — zsh-completions, syntax highlighting, частично грузится oh-my-zsh, ну и разная мелочь в количествах).

powerman
0

Об этом упомянуто и в статье и в комментах, но при желании это делается и для bash (точнее, для urxvt — плагин confirm-paste плюс http://lists.schmorp.de/pipermail/rxvt-unicode/2017q1/002360.html).

powerman
0

Для выполнимых файлов — безусловно. Но на каталоге setgid чем плох?

powerman
0

Всё верно. :(


Теоретически, можно дать доступ ко всем нужным файлам приложения через права группы и setgid-каталоги, поставить всем umask 0002, тогда через sudo под аккаунтом самого приложения надо будет исключительно его запускать/перезапускать, а работать можно под личным аккаунтом.


Но при попытке применять этот подход на практике постоянно вылезали какие-то шероховатости. Нередко попадаются не очень качественно написанные приложения и скрипты, которые нечаянно удаляют setgid-бит каталогам когда пытаются изменить их права. Или, зачем-то, игнорируют umask и форсируют "безопасные" права. Плюс, имея полный доступ к файлам приложения его возможно запустить под личным аккаунтом, и очень часто по ошибке это и делали. А потом другой юзер не мог прибить процесс чтобы его перезапустить. Последнее, вероятно, проблема решаемая — можно в стартовом скрипте приложения проверять $UID, например, но количество излишних сложностей и потенциальных проблем начинает превышать комфортный уровень, в результате чего все на это забивают и продолжают пользоваться общим аккаунтом.

powerman
0

Поэтому я и написал "… подчитать смогут все, так или иначе". Можно оставить основным шеллом bash или даже sh, просто написать в ~/.bashrc exec fish/tcsh, чтобы они запустились уже с этими переменными, можно загрузить в них эти переменные кучей других способов. Об этом не должна болеть голова при основном администрировании сервера, это вполне может быть личной проблемой тех, кому нужен fish/tcsh — главное, чтобы для них эта проблема была решаемой в принципе.

powerman
+1

Мой практический опыт сводится к тому, чтобы во-первых избегать использования общих админских аккаунтов, и во-вторых стараться на сервера вообще ручками ходить по-реже и делать там по-меньше, а не к тому, чтобы на любом из 1000 серверов было удобно работать в zsh через sudo (в этом плане, кстати, когда на серверах работать неудобно — это скорее плюс, лишний мотив этого избегать в принципе). Удобно работать должно быть на рабочей станции и на 2-3 уникальных серверах, которые админятся по-старинке ручками, а не через ансибл.


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

powerman
0

Угу. Только свои комменты. Именно. У нас здесь вообще-то есть определённый контекст, и обсуждаем мы не SAP. Какое отношение описанное Вами имеет к сложности/неприемлемости установки zsh на 1000 разношёрстных серверов в энтерпрайзе?

powerman
0
Категоричность обычно не является профессионализмом.

Звучит немного категорично, нет? :)


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


А если заведется любитель fish или ipython или tcsh? :)

Переменные окружения заданные в формате posix sh подчитать смогут все, так или иначе. Суть ведь не в том, чтобы сделать удобно всем сразу, а в том, чтобы дать возможность желающим сделать себе удобно самостоятельно.

powerman
0

Общие паттерны здесь не при чём. Хотя они всё-равно всегда есть, просто относятся к инфраструктуре, а не основной задаче сервера: логи, бэкапы, обновления, добавление аккаунтов для новых сотрудников, etc. И если сервер умер или его надо обновить/переустановить — Вы предпочтёте разыскивать уволившегося два года назад сотрудника, который знал что/как/почему надо настраивать на этом сервере, или всё-таки запустить плейбук ансибла который тупо раскатает на новый сервер всё, что необходимо — пусть даже этот плейбук нужно было когда-то написать конкретно для этого сервера?

powerman
–1

Особый общий ENV большинству команд не требуется, но в любом случае это не проблема — если он "общий", то какая разница, поддерживать его в /root/.bashrc или в /etc/profile.d/?
Notes в виде файла на конкретном сервере? Вы так шутите? Ну или это было очень-очень много лет назад. Сейчас для этой цели есть wiki.
Скрипты для bash/zsh/ansible — на то и скрипты, чтобы их можно было запускать всем, вне зависимости от того, какой у кого $SHELL.


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

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

powerman
0
Админ редко один, поэтому нужно находить компромис с коллегами.

Просто не надо использовать общие аккаунты и sudo -i. Если каждый админ использует личный аккаунт и sudo для индивидуальных команд — ему ничего не мешает иметь личный ~/.zshrc. Помимо прочего это намного более здраво в плане безопасности, аудита и контроля доступа отдельных сотрудников.

powerman
+2
… в реальном использовании bash … не настолько менее продуктивен, чтобы ради этого переходить …

С этим я соглашусь. Но это не значит, что переходить нет смысла. Переход на zsh — вопрос не продуктивности, а удобства. И даже если через год вернуться на bash, то оно всё-равно того стоит, потому что вернётесь Вы уже с пониманием, что и как можно сделать удобнее лично для Вас, и часть этого действительно получится реализовать в bash — так что время потраченное на изучение и использование zsh не пройдёт даром (потому что в результате Вам станет удобнее работать в bash).


Вообще, bash штука странная. Умение писать на нём скрипты — является скорее минусом, потому что как только эти скрипты выходят за пределы лично ваших компов, то вас (почти) сразу начинают тыкать носом в "башизмы" в этих скриптах и просить переписать их так, чтобы они работали на любом sh (мне пришлось даже тулзу checkbashisms поставить для упрощения этого процесса). То, что bash "везде установлен" — вообще-то не является правдой, в BSD его обычно из коробки нет, в некоторых линухах вроде OpenWRT тоже нет, etc. А то, что его обычно первым делом устанавливают — ну так ровно с тем же успехом можно было и zsh поставить. Но даже если bash из коробки есть, то вот пакет bash-completion уж точно из коробки отсутствует — а Вы вроде не отрицаете реальную необходимость автодополнения для bash. И снова, в чём принципиальная разница между необходимостью на каждой системе первым делом ставить пакет bash-completion или пакет zsh? То, что "bash везде одинаковый" — тоже не правда, потому что тогда Вам нужно перестать использовать все alias-ы и дополнительные keybinding-и в inputrc. "Голый" bash, без алиасов в .bashrc, без автодополнений и keybinding-ов, который есть почти но всё-равно не везде — это действительно то, чем Вы бы хотели ежедневно пользоваться? И чего ради, чтобы не устанавливать ни одного лишнего пакета, который не нужен для выполнения основных функций сервера?


На мой взгляд в отношении bash/zsh основная проблема скорее в инерции мышления и консерватизме, нежели в реальных причинах предпочитать bash. Примерно так, как было когда-то, когда сайты дизайнили "под IE" а не по стандартам, потому что "IE есть у всех". Там ситуацию, хоть и с громадным трудом, переломили — потому что были заинтересованные в этом крупные игроки. А в отношении bash/zsh таких нет, если мы хотим чтобы нам же было удобнее, то менять ситуацию (читай — ставить везде zsh по умолчанию, просто из вежливости к коллегам) надо нам самим.

powerman
+1

Реальной необходимости нет в абсолютном большинстве нововведений. Любая ОС 15-ти летней давности содержит всё реально необходимое для работы. Даже в хабре нет реальной необходимости для работы "большинства матёрых линуксоидов"… но, тем не менее, Вы зачем-то тут читаете статьи и даже комментируете (а была ли реальная необходимость в Вашем комментарии?). Что касается "красивостей" — то же можно сказать и про абсолютное большинство книг/фильмов/картин/музыки — реальной необходимости в них нет. (Кстати говоря, если говорить абсолютно честно и искренне, не принимая во внимание желание оправдать получаемую зарплату — а есть ли реальная необходимость в большей части Вашей работы? Вы действительно каждый день делаете то, без чего нельзя обойтись, ваши проекты и сервера действительно реально необходимы человечеству?)


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


P.S. Что касается "я матёрый линуксоид, знаю все нужные флаги" — когда на глаза регулярно попадается список флагов при автодополнении, то даже матёрому линуксоиду это позволяет регулярно открывать для себя новые флаги и возможности, без которых можно было бы обойтись, конечно, но которые могут быть полезны/удобны. Я вот полностью список флагов ls и многих других базовых команд первый и последний раз читал примерно в 1994, когда осваивал линух. После этого у меня всегда было чем заняться и без перечитывания этих man-ов в поисках "а нет ли там чего полезного, чего не было в 1994 либо что я в 1994 не оценил/не запомнил".

powerman
0

Подключить плагин dircycle из oh-my-zsh.

powerman
0

Попробуйте это (возможно стоит указать только local-directories, а остальное выкинуть):


zstyle ':completion:*:*:-command-:*:*' group-order \
    local-directories directory-stack named-directories directories
powerman
0

А при запуске zsh -f этот эффект тоже наблюдается?
Если нет — проблема в Ваших конфигах zsh, или в ~/ или в /etc/.
Если да — возможно проблема в каких-то общесистемных вещах, но для начала стоит попробовать обновить zsh на 5.2 или более новую версию.

powerman
0

А можно чуть конкретнее? Что именно тормозит и как Вы это определяете?

powerman
+1
на моем ноуте zsh тормозит конкретно.

Это не zsh. В самом zsh тормозить нечему. Это тормозила чужая навороченная конфигурация с кучей включённых по умолчанию плюшек (вроде oh-my-zsh), которую Вы, вероятно, поставили, чтобы получить "вау-эффект" с первой минуты.

powerman
0

С вариантом на terminfo есть свои проблемы (конкретно в моём случае).
Во-первых, я начитался про то, как у людей подтормаживает zsh при запуске из-за большого количества подключённых модулей/плагинов, поэтому стараюсь изначально не подгружать то, без чего можно обойтись.
Во-вторых, в $terminfo есть далеко не все кнопки, например как через него получить код для Ctrl-PageUp?
В-третьих, у меня в ~/.Xresources есть немаленький блок строчек URxvt.keysym.* задающий конкретные escape-последовательности конкретным кнопкам (без этого часть комбинаций не работает в Vim)… и что-то я сомневаюсь, что $terminfo будет возвращать именно эти комбинации, это было-бы как-то уж слишком волшебно.
Ну и в последних — у меня не так много разнотипных серверов, везде примерно одно и то же, так что файл с результатом zkbd попадёт на сервера вместе с остальными конфигами zsh и будет, я полагаю, вполне корректно работать везде, без необходимости вызывать zkbd на каждом сервере отдельно.

powerman
0

Удобство создаётся не какой-то киллер-фичей, а множеством разных мелочей.


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

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

powerman
0
Я не пытался сделать какие-то претензии к zsh, я просто хочу показать, что его функционал излишен для выполнения работ на удаленных машинах в целях системного администрирования.

Хм. А почему Вы для таких работ используете bash, ведь есть же sh? Разве функционал bash не излишен примерно в той же степени, что и zsh?


Догадываетесь почему? Потому что это нафиг никому не надо — смотреть в непонятный пестрый экран.

Звучит как "виноград кислый", если честно. Я, лично для себя, пока ещё не определился, нравится мне подсветка синтаксиса или нет (но скорее всего надо просто немного поднастроить цвета, может отключить подсветку отдельных элементов). Но я не вижу абсолютно никакой проблемы в том, что при наборе на удалённом сервере я сразу вижу есть ли опечатка в имени команды или не закрытые кавычки, ещё в процессе набора, до запуска команды. Если оно из коробки "пёстрое" — ну так подправьте цвета под свой вкус, отключите подсветку лишних элементов, но в самой идее подсветки синтаксиса абсолютно ничего плохого нет, и продуктивность это обычно повышает.


Люди используют удаленные сессии, как там вообще может удаленный zsh перехватывать буфер обмена?

Хрен его знает. :) Но я только что проверил — через ssh работает, а в screen (даже локальном) — нет.


Не хочется. Для этого я запущу find или xargs, а в самом сложном варианте сделаю через однострочних в цикле for.

А мне вот хочется. Вероятно, это дело вкуса. Я линух админю уже 23 года, но параметры find для меня так и не стали интуитивно понятными, что-то чуть нетривиальное — приходится сначала лезть в man, а потом ещё и экспериментировать немного, чтобы убедиться что команда возвращает нужные файлы. Так что возможность использовать find значительно реже — для меня выглядит довольно привлекательно.


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

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


А зачем? В однострочниках переменные называются интуитивным образом, их не надо дополнять.

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


Просто каждому хотелось бы, чтобы write-only рецепт сработал как на нагруженном сервере, так и на очередной поделке с dd-wrt, так и на локальной машине.

Да. К сожалению, мир устроен иначе. Я вот изредка попадаю на сервера где нет bash. И половина набираемых мной команд, внезапно, перестаёт работать как ожидалось. Знаете, что я в этот момент делаю? Устанавливаю, с матами, bash. А ещё bash бывает разных версий, так что часть привычных конструкций изредка на древних серверах выдаёт не то, что ожидается (такое бывает не часто, да, но всё-равно). Так что Ваша мечта всегда будет только мечтой, к сожалению.


А учить для одного сервера zsh, для того, чтобы на сотне других пользоваться bash, как-то уже совсем не то.

Вот! Именно это и удерживало меня от изучения zsh долгие годы. И именно про это написана статья — чтобы показать, что отличий между bash и zsh не так много, что "учить zsh" это не так масштабно и сложно как кажется на первый взгляд, что практически все команды которые работают в bash будут ровно так же работать в zsh (а если включить SH_WORD_SPLIT — тогда, думаю, вообще все в которых не встречается $BASH…).


Запомнить что в bash нельзя пользоваться флагами/квалификаторами/модификаторами несложно, и даже если что-то такое набрать по привычке случайно в bash — будет не трагедия, а синтаксическая ошибка (как и для сокращённых вариантов if|while|for). Автодополнение в bash будет работать хуже, но это тоже не помешает набирать корректные команды. По большому счёту, основное что может создать проблему помимо SH_WORD_SPLIT — это шаблоны с <число1-число2>, которые bash скорее всего поймёт как перенаправление stdin/stdout.


Если нужно много работать с bash, то Вам никто не мешает включить SH_WORD_SPLIT и забыть про возможность использовать <число1-число2> в шаблонах. Тогда шанс, что привычная по zsh команда некорректно заработает в bash, будет пренебрежимо мал. В общем-то, именно для таких ситуаций в zsh и существуют эти 177 опций, кардинально влияющие на поведение и поддерживаемый синтаксис — чтобы каждый мог работать в такой zsh, которая подходит лично ему, а не в такой же zsh, как у всех.


Наверно, zsh хорошо подходит, если много работаешь именно на локальной машине.

Да. Но, в идеале, на серверах вообще нежелательно ручками работать, для этого есть ansible/chef/etc. Идеал не всегда достижим, конечно, но общая тенденция идёт в этом направлении. Приложения расползаются по docker-контейнерам, в которых вообще не то, что bash, но даже и sh может не быть (хотя бы из соображений безопасности).


Но перекрыть его возможности обычным башем также с легкостью можно.

Это прямая ложь, нехорошо, однако.


я с ним плотно игрался в 2008-2009 (припоминаю, там еще были косяки по unicode)

Да, судя по changelog — было такое. Но сейчас вроде всё ок, так почему наличие багов 8 лет назад является проблемой сейчас?


За все это время с развитием технологий виртуализации, автоматической настройки серверов, я не встречал ни одной крупной организации, где бы в init скриптах на создание очередного сервера стояла автоматическая установка zsh. Я полагаю, это не просто так.

Как я уже выше упоминал, чем дальше мы идём по тропинке виртуализации, увеличения количества серверов и сужения выполняемых ими задач — тем меньше смысла выполнять на этих серверах команды вручную по ssh, они должны управляться через ansible etc. Поэтому там и bash нередко избыточен, не говоря уже про zsh. Так что да, это не просто так.


Shell должен работать быстро везде (за исключением машин в Австралии или подключенных через спутниковый канал=), если появляется лишняя непредсказуемая задержка — она уже сама наводит панику, что какую-то команду я ввел зря.

Угу. Но я пока от zsh задержек не наблюдал. Допускаю, что они бывают, вот эта настройка в oh-my-zsh наводит на такую мысль (но здесь подразумевается индикация причины задержки, так что всё вроде ок):


# Uncomment the following line to display red dots whilst waiting for completion.
COMPLETION_WAITING_DOTS="true"
powerman
+2

Для подсветки разными цветами последовательности действительно отличаются, но: во-первых указанные Вами отвечают не за цвета, а за указание терминалу/screen изменить заголовок окна, а они от шелла не зависят и везде будут одинаковые, а во-вторых в bash даже для смены цвета обычно задаются стандартные последовательности, которые не так удобно читать как "%B%F{red}жирный красный%f%b" в синтаксисе zsh, но зато, опять же, они должны работать одинаково в любом шелле, так что если нет желания переписывать их в синтаксисе zsh — их можно просто скопировать как есть.

powerman
0

И что? Такой bash/sh синтаксис zsh понимает и так, у него очень сильная совместимость с другими шеллами. А вот если вы привыкнете в zsh писать в сокращённой форме:


for i in *.jpg; convert -resize 200x200 $i /tmp/res/`basename $i`.png
# или даже
for i in *.jpg; convert -resize 200x200 $i /tmp/res/${i:t}.png

то всё, что вам грозит при попытке запустить это в bash:


-bash: syntax error near unexpected token `convert'

В общем, если честно, я не вижу трагедии. Ладно шелл, но вот пользоваться на других машинах редактором-убожеством вроде mcedit, nano или не настроенного vim — я "пас" в любом случае. А раз всё-равно приходится везде носить свои настройки для vim, то добавить к ним ещё и настройки для zsh — не сложно.

powerman
+3

Если у Вас за 4 года накопилось 117402 команды, то миллиона хватит лет на 40. Можно, конечно, всё-равно продолжать беспокоиться что миллиона может не хватить, но это уже проблема психологическая, а не техническая.


Автоматический перекодировщик чего конкретно? У Вас там ровно три значения: \u — юзер, \h — хост, \w — текущий каталог. Аналогичные три значения можно найти в доке zsh быстрее, чем мы это обсудим в комментах.

powerman
+1

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


Например, что вставка из clipboard нескольких строк теперь не начинает молча выполняться, а просто показывает вставленный текст и ждёт подтверждения Enter-ом для его запуска; очень быстрая навигация по каталогам — у меня по Ctrl-Shift-Left|Right перебираются последние каталоги (причём не затирая текущую частично набранную команду — изменяется только имя каталога в приглашении перед командой), по Alt-q можно "отложить" текущую набранную команду, выполнить вместо неё другую и тут же автоматически продолжить редактировать отложенную команду с курсором в том же месте, в bash после прерывания по Ctrl-C некоторых команд состояние терминала портилось и нужно было вслепую запускать reset — а в zsh этого не просходит… и там много ещё такого всякого. Давеча у меня rm * внезапно спросил подтверждения… оказывается, есть и такая фича, специально для ситуации когда rm получает одним из аргументов *. В общем, приложение изначально заточенное сделать тебе "удобно" в интерфейсе, и не заточенное — это две большие разницы, и чувствуется это в куче разных мелочей.


Я не хотел всё это перечислять в статье, потому что то, что одному удобно — другого только раздражает, но суть в том, что в zsh слишком много всего и каждый может сделать намного удобнее лично для себя. А к заметно более удобному привыкаешь моментально… так что выкатывание zsh со своими конфигами на сервера становится вопросом времени. :)

powerman
+1

1000 серверов управляется ведь не ручками, а через ansible/chef/etc. Так что раскатать на них zsh с вашими конфигами не должно быть проблемой, было бы желание.

powerman
0

Я сходу не вижу в доке возможности указать -1 для HISTSIZE, но… а Вам реально важно, чтобы она была именно бесконечная? Учитывая что история считывается в память, что занимает время и место, значение HISTSIZE более 1 миллиона вряд ли имеет смысл (это даёт размер файла с историей порядка 50MB, и будет хранить историю примерно за 1 год).


Что касается PS1 — можно точно так же и поставить, разве что escape-последовательности будут другие. Но обычно в zsh для обновления заголовка терминала используют другой подход: существуют функции-хуки precmd и preexec, автоматически вызываемые перед выводом приглашения и перед запуском команды, и обновление заголовка терминала прописывают обычно в них (в частности, это даёт возможность записать в заголовок имя запущенной команды пока она выполняется, а не только текущий каталог). В oh-my-zsh это работает из коробки, в prezto не проверял, но скорее всего тоже.

powerman
0
P.S. в опрос неплохо бы добавить, использовал zsh, но перешел обратно на другой интерпретатор

Да, мне тоже эта мысль недавно пришла в голову. Добавил.

powerman
0

Выше упоминали уже, если Вас напрягают такие вопросы — Вам надо смотреть в сторону OS Plan9 или OS Inferno. Там с оригинальной философией UNIX всё хорошо. Ссылки в тему (про cat, а не ls, но суть примерно та же):
http://harmful.cat-v.org/cat-v/
https://github.com/pete/cats

powerman
0

Не перебор. У меня уже лет 15 после загрузки автоматически создаются 24 виртуальных рабочих стола, и на всех кроме одного запускается по одному приложению распахнутому на весь экран — mc, mutt, pidgin, firefox, rtorrent, tail -f syslog-а и терминалы на всех остальных (часть их них автоматом подключается по ssh к ключевым серверам). Переключаюсь между ними и по Alt-Fx/Alt-Shift-Fx, и по Win, Shift-Win (по кругу вправо/влево) и по Menu (между двумя последними). И друзья, посмотрев как я работаю, себе тоже так настроили, и за все эти годы своего мнения не изменили — им тоже так очень удобно.


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


Более того, все эти приложения запущены в режиме "без рамки окна", так что место на экране не тратится на заголовки окон, кнопки максимизировать/минимизировать/закрыть, etc. Потому что я во время работы почти никогда не закрываю и не запускаю приложения — всё уже запущено на нужных рабочих столах сразу после загрузки компа и остаётся запущенным всегда. Все эти рамки и кнопки нужны для того, чтобы заниматься "менеджментом окон приложений" — т.е. не чем-то полезным и нужным для работы, поэтому я от них и избавился.


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

powerman
0

Я когда-то использовал MatrixSSL. Потому что OpenSSL это, таки да, тихий ужас.

powerman
0

Ещё одна проблема с column — он не умеет учитывать ANSI escape sequence, поэтому есть вывод mount расцвечивается чем-нить вроде grc то фактически
mount | column -t
превращается в
grc /bin/mount | column -t
и колонки ломаются. Починить можно изменив порядок, но это набирать уже не очень удобно:
/bin/mount | column -t | grcat conf.mount

powerman
0

А если команда может выполняться моментально, то внутри do/done не помешает sleep 1.

powerman
+2

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

powerman
0

Не-а. Это не спасёт от получения SIGHUP при отключении. Попробуйте сделать ssh localhost, запустить эту команду, а потом нажать ~. для разрыва ssh-сессии.

powerman
0

На самом деле в процессе разработки архитектуры похожие техники тоже применимы — просто либо ты пытаешься всю архитектуру (или требуемое её изменение) удержать в голове и продумать целиком, либо начинаешь выносить отдельные части наружу (что-то нарисовать, для какого-го мелкого и понятного элемента написать спеку, изменить схему БД в более-менее нужном направлении, провести мелкие нагрузочные тесты каких-то подсистем, почитать более детально доку по малоизвестным фичам ЯП или БД, etc.) и в процессе много проясняется быстрее, чем если делать всё это в голове.

powerman
0
С IPv6 хуже не будет. Наоборот, этот способ с легкостью позволит сократить время загрузки страницы примерно на 10%.

Хуже — вполне может быть. Включение IPv6 открывает новые интересные способы проникновения в вашу сеть (не актуально для одинокого сервера, но если у вас кластер с внутренними сервисами бэкенда или публичный сайт на сервере подключённом к домашней/корпоративной локалке, доступ к которым закрыт файрволом, то могут быть нюансы) — это не фатальный недостаток IPv6, а, скорее, недостаток квалификации по его настройке у многих админов. Так же включение IPv6 активирует кучу дополнительного кода, как в ядре ОС, так и в приложениях, где тоже регулярно находят новые уязвимости. В общем, если вас волнует безопасность, то включать IPv6 надо очень-очень осторожно, а лучше подождать с этим ещё пару лет, пока уязвимости исправят и появится больше хороших мануалов по корректной настройке IPv6.


Что касается ускорения благодаря IPv6 — это звучит довольно странно, интересно, с чем это может быть связано?

powerman
0

Конечно, но мы же здесь не микросервисы обсуждаем, а MVC. Если в микросервисе 10К строк — без какой-то архитектуры (может и MVC) внутри этого микросервиса, в большинстве случаев, будет очень неуютно. А если в нём 50-100 строк, то часто можно архитектурой не заморачиваться.

powerman
0

MVC это архитектурный подход. Его можно применять внутри какого-то модуля/библиотеки, строить по нему отдельное приложение (процесс ОС), и ровно так же строить по нему распределённое приложение состоящее из десятков микросервисов.


Мой изначальный коммент был про то, что когда у нас MVC в рамках одного процесса ОС, то соблюдать границы (не лазить в модель мимо фасада, не пропускать через фасад наружу исходные объекты доменной модели через которые опять же можно узнать лишние детали реализации модели и даже изменять модель мимо фасада, etc.) становится очень сложным т.к. язык/ОС не помогают соблюдать границы и это становится вопросом внутренней дисциплины разработчиков.

powerman
+1
Это не требование, а часто используемая практика. В конце-концов, СУБД тоже своего рода микросервис, которому никто не запрещает иметь несколько клиентов в рамках системы.

Это именно что требование. Как только у микросервисов появляется общая БД и начинаются философские рассуждения о том, что формально СУБД это тоже сервис (на микро он, вообще-то, не тянет) — то "Хьюстон, у нас проблема".


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


Суть микросервисного подхода в том, что пока стабильно работают API сторонних микросервисов и стабильно работает API этого микросервиса — мы можем делать что угодно и как угодно в самом микросервисе, и это гарантированно ничего не сломает в других местах. Поэтому несовместимых изменений API стараются избегать из всех сил, потому что это единственное, что может поломать что угодно и где угодно. Хотя СУБД это безусловно сервис, но у этого сервиса нет стабильно работающего API — я имею в виду достаточно высокоуровневого API, которое бы гарантировало что сделав вот такой запрос в базу я получу нужные мне данные в корректном формате — потому что изменение схемы БД или ошибка в коде изменяющем данные всё это ломают.


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