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

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

Тема может заинтересовать и продвинутых пользователей при настройке удаленного доступа и при реализации тонкого клиента. Часто встречаю вполне матерых линуксойдов с утверждениями «на сервере только командная строка, и графику подробнее изучать не планирую, так как это всё нужно для простых пользователей». Но даже знатоки Linux с большим удивлением и радостью открывают для себя опцию «-X» у команды ssh (а для этого полезно понимать работу и функции X-сервера).

Источник

Предлагаю читателям "Хабрахабра" перевод статьи "Why, oh WHY, do those #?@! nutheads use vi?" за авторством John Beltran de Heredia.

Да, даже если вы не можете в это поверить, у редактора vi, увидевшего свет более тридцати лет назад (и его более молодого, всего-то пятнадцатилетнего лучшего клона & большого улучшения — vim) очень много фанатов.

Нет, они не динозавры, которые не хотят идти в ногу со временем — сообщество пользователей vi продолжает увеличиваться: я, который начал только два года назад (после десяти лет работы программистом). Мои друзья переходят на vi сейчас. Черт, большинство пользователей vi даже еще не были рождены, когда он был написан!

Да, есть конкретные причины, почему модель редактирования vi/vim превосходит любую другую. Вам не надо быть экспертом в Unix, чтобы использовать vi — он доступен бесплатно практически для любой существующей платформы; для большинства IDE существуют плагины, позволяющие использовать его возможности. Давайте же развеем некоторые заблуждения и рассмотрим пару примеров, демонстрирующих его превосходство.

Я, к сожалению, не нашел русского перевода этого текста, хотя мне он показался крайне… просветляющим, что ли.

Признак 1: мы не используем sudo

Как CAPS LOCK — «круиз-контроль для крутотенюшки», так и sudo — «костыль для сомневающихся». Если нам нужно сделать что-то от имени root, мы используем su, а не фигню навроде sudo. Если какая-то из Unix-подобных операционных систем заставляет нас использовать sudo, то первое что мы делаем — sudo su и устанавливаем пароль для пользователя root, чтобы комфортно пользоваться su в дальнейшем. Постоянное использование sudo можно сравнить с плаванием c надувным кругом в животе — это безопаснее, да, но лишает необходимости обдумывания поступков.

Настороженно отношусь к непрофильным топикам, но решил написать этот по следующим причинам:

• У жонглирования есть своя теория — стройная и математически привлекательная!
• Мы живем не только работой. Жонглирование — отличное развлечение и разминка после долгого сидения за компом.
• В пятницу приятно немного расслабиться и почитать не очень серьезные статьи. К тому же, будет чем заняться на выходные, особенно если у вас не было определенных планов.

Теория

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

Почему bash?

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

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

Предисловие

Данное руководство сопровождает ShellHarden, но автор также рекомендует ShellCheck, чтобы правила ShellHarden не расходились с ShellCheck.

Bash — не тот язык, где самый правильный способ решить проблему одновременно является самым простым. Если принимать экзамен по безопасному программированию в bash, то первое правило BashPitfalls звучало бы так: всегда используй кавычки.

Главное, что нужно знать о программировании в bash

Маниакально ставить кавычки! Незакавыченная переменная должна расцениваться как взведённая бомба: она взрывается при контакте с пробелом. Да, «взрывается» в смысле разделения строки на массив. В частности, расширения переменных вроде $var и подстановки команд вроде $(cmd) подвергаются расщеплению слов, когда внутренняя строка расширяется в массив из-за расщепления в специальной переменной $IFS с пробелом по умолчанию. Это обычно незаметно, потому что чаще всего результатом становится массив из 1 элемента, неотличимый от ожидаемой строки.