Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 13591 сообщений
Cообщения с меткой

linux - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

[Перевод] 10 приёмов работы в терминале Linux, о которых мало кто знает

Понедельник, 21 Августа 2017 г. 14:29 (ссылка)

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



Читать дальше ->

https://habrahabr.ru/post/336060/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[recovery mode] Установка и использование GNU/Linux вместо Chrome OS на Toshiba Chromebook 2

Понедельник, 21 Августа 2017 г. 12:34 (ссылка)

Привет всем! Некоторое время назад я приобрёл себе Chromebook модели Toshiba Chromebook 2 CB35-B3330 и заменил на нём Chrome OS на традиционный GNU/Linux. Это была не установка через crouton, а именно «чистая» установка с полным удалением Chrome OS. Борьба с плохой поддержкой Линуксом этого хромбука заняла неожиданно много времени (несколько вечеров), но в итоге все проблемы решились и хромбук стал полноценной рабочей машиной.



В итоге я решил написать статью, в которой:




  • Очень кратко описан сам хромбук и мои впечатления от железа.

  • Описаны основные проблемы по установке GNU/Linux на данную конкретную модель и пути их решения.

  • Очень кратко описано, каким образом я сам его использую после установки Линукса.




Читать дальше ->

https://habrahabr.ru/post/336044/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Переосмысление PID 1. Часть 3

Суббота, 19 Августа 2017 г. 12:36 (ссылка)

В продолжение второй части…



Распараллеливание заданий файловой системы



Если вы посмотрите график загрузки текущих дистрибутивов, увидите больше точек синхронизации чем просто запуски демонов: больше всего времени отнимают задания, связанные с ФС: монтирование, проверка ФС на ошибки (fsck), квотирование. Сейчас, во время загрузки много времени тратится в ожидании, пока все диски, указанные в /etc/fstab не появятся в дереве устройств, а далее проверены на ошибки, примонтированы и применены квоты (если конечно они включены). Только после всего этого мы сможем пойти дальше и в действительности начнется загрузка служб.



Можем ли мы улучшить этот процесс? Выходит, что можем. Гарольд Хойер пришел с идеей использования достопочтенной autofs для улучшения процесса.
Читать дальше ->

https://habrahabr.ru/post/335780/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] История Linux (1993–2003): испытание дистрибутивов

Пятница, 18 Августа 2017 г. 13:31 (ссылка)

Уникальная особенность опенсорсных проектов заключается в том, что жизнь их никогда по-настоящему не заканчивается. Образы дисков, по большей части, доступны для загрузки из интернета, их лицензии не истекают. Поэтому довольно просто совершить прыжок в прошлое, установив Linux из 90-х на виртуальной машине.



Как это было? Как воспринимаются сегодня древние дистрибутивы Linux? Что изменилось за годы развития? Выясним это. Первым пунктом нашего путешествия станет ОС Slackware 1.01, оправленная в группу новостей comp.os.linux.announce 20 лет назад.
Читать дальше ->

https://habrahabr.ru/post/335898/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Chromebook для удаленной работы. Настраиваем VPN и RDP

Понедельник, 14 Августа 2017 г. 10:56 (ссылка)

image


Привет! Удаленную работу часто можно описать как два технических требования от исполнителя: первое, доступ в интернет, и второе, ноутбук. А если у вас есть удаленный сервер, на котором вы работаете, то все, что вам нужно: тонкий клиент для доступа к нему. В этой статье я расскажу, как я выбирал и настраивал тонкий клиент для удаленной работы, и почему хромбук отлично справляется с этой задачей.



Требования



Итак, вот основные требования, которые я определил для себя:




  • Хороший экран — в него мы будем смотреть часами

  • Автономность — жизнь на батареи более 5-6 часов

  • Вес — мобильность важный показатель для поездок и путешествий

  • Цена — разбить или потерять ноутбук за $300 будет не так накладно/обидно как за $1500



Выбор устройства



С выбором я не заморачивался, открыл Амазон и нашел все модели хромбуков в категории до 300 долларов. Мой выбор пал на модель Acer Chromebook 14 (CB3-431). Для теста выбрал восстановленный (Refurbished) ноутбук за 185 долларов. Справедливости ради нужно отметить, что восстановленный хромбук ничем не отличался от нового, кроме как отсутствием оригинальной упаковки и 3-мя месяцами гарантии.



Настройка VPN и RDP в хром ос



Итак, красивый и тонкий ноутбук в руках, настраиваем VPN и RDP для удаленной работы.



VPN проблема



Читаем много статей по настройке VPN и понимаем, что все плохо, настроить подключение через ovpn файлы практически невозможно. Нужно разбивать ovpn файлы на части и конвертировать в особый формат, что, в итоге, тоже не сработало. Мой хромбук поддерживает андроид приложения, но оказалось, что и они не могу работать с TAP-интерфейсом, описанным в ovpn файле.



VPN решение



Для решения этой проблемы, нам нужно получить рут права и воспользоваться уже встроенным openvpn клиентом. Как получить рут права описано здесь.



Теперь, чтобы поднять наш VPN, нам нужно выполнить следующее.

Заходим в терминал: Ctrl+Alt+T, вводим команду shell. Далее нам нужны команды:



openvpn --mktun --dev tap0
openvpn --config /usr/local/vpn/openvpn.ovpn --dev tap0
openvpn --rmtun --dev tap0


Первая строка создает тоннель, вторая запускает подключение (здесь, указываем путь к вашему ovpn файлу), третья нужна после завершения подключения.

Проблема VPN решена.



RDP проблема



Для удаленного доступа можно использовать множество решений, таких как Google Remote Desktop или TeamViewer. Но для меня они не подошли, в силу разных причин, и я решил сосредоточиться на настройке RDP.



На хром ос можно запустить ChromeRDP, вроде работает, но плохо живет на медленном канале связи и настроек маловато.



RDP решение



Для решения этой задачи нам потребуется хороший RDP-клиент и линукс. Самый простой способ получить полноценный линукс на хромбуке это Crouton. Он устанавливается просто и работает параллельно с хром ос. Подробная статья о настройке Crouton хабрится здесь.



Имея доступ к apt-get в линукс, мы можем установить Remmina. Remmina — это удобный и быстрый RDP клиент.



Итак, программа минимум выполнена и мы можем работать.



Итоги



Успел поработать в таком режиме больше месяца. В целом работать достаточно удобно, хоть и понадобилось время чтобы привыкнуть к клавиатуре.



Плюсы:




  • Цена вопроса, в моем случае это ~$200 (с учетом доставки из США)

  • Достаточно хорошие характеристики для целевой задачи: 4gb RAM, 32gb SSD, IPS 14" FULL HD, 1.5kg

  • Длительное время автономной работы, в моем случае 9-10 часов от батареи

  • Возможность установки андроид приложений + полноценный линукс

  • Отсутствие каких либо тормозов в хром ос и при использовании RDP



Минусы:




  • Нужно инвестировать время в настройку системы

  • Если нужно подключение к удаленному серверу, то без интернета — работа стоит



В целом, опыт использования хромбука для работы получился интересный, и если у вас есть время и желание, рекомендую попробовать. Я так же понял, что хром ос — идеальный вариант для дедушек и бабушек, для просмотра YouTube и погоды :)

Надеюсь, эта статья была полезна, удачи!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335566/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Переосмысление PID 1. Часть 2

Суббота, 12 Августа 2017 г. 16:48 (ссылка)

В продолжение первой части…



Распараллеливание служб сокетов



Этот вид синхронизации при загрузке приводит к опоследовательности (последовательный запуск служб) существенной части процесса загрузки. Не было бы круто если бы мы могли избавиться от цены синхронизации и опоследовательности? Что ж, мы можем на самом деле избавиться. Для этого, нам необходимо понять, что на самом деле службы (демоны) требуют друг от друга, и почему их запуск откладывается. Для традиционных демонов (служб) Unix, есть только один ответ на этот вопрос: они ждут до тех пор, пока демон предоставляющий свои службы не будет готов принимать соединения. Обычно это AF_UNIX сокет в файловой системе, но это может таже быть AF_INET сокет. Для примера: клиенты D-Bus ждут /var/run/dbus/system_bus_socket, чтобы сконнектиться к нему, клиенты syslog ждут /dev/log, клиенты CUPS ждут /var/run/cups/cups.sock и NFS точки монтирования ждут /var/run/rpcbind.sock и порт IP портмаппера и т.д. А теперь задумайтесь об этом, на самом деле есть только одна вещь чего ждут остальные.



Так как это лежит в основе того, что следует далее, позвольте мне сказать это снова, но другими словами: если вы запускаете syslog и различных клиентов syslog одновременно, что произойдет в схеме обозначенной выше, так это то, что сообщения от клиентов будут добавлены в буфер /dev/log. До тех пор, пока буфер не переполнится, клиенты не должны ждать пока syslog закончит загрузку, они вытащат все сообщения из очереди и обработают их. Другой пример: мы запускаем D-Bus и несколько клиентов одновременно. Если отправлен синхронный запрос к шине, следовательно, будет ожидаться ответ, также синхронно, и произойдет то, что клиент будет заблокирован, тем не менее только один единственный этот клиент (пославший синхронный запрос) и только до тех пора пока D-Bus не отловит запрос и не обработает его.



В общем, буфер сокетов ядра помогают увеличить распараллеливание, и упорядочивание и синхронизация делается ядром, без какого-либо вмешательства юзерспейса! Но если все сокеты будут доступны до момента загрузки демонов, управление зависимостями также становится избыточным (по крайней мере второстепенным): если демон нуждается в другом демоне, он просто сконнектится с ним. Если другой демон уже запущен, это незамедлительно будет успешным. Но если другой демон еще не запущен, а находится в процессе запуска, первый демон даже не должен ждать его, пока он не сделает синхронный зарос. Даже если другой демон вообще не запущен, он может быть запущен автоматически. С точки зрения первого демона для него нет никакой разницы, следовательно, управление зависимостями становится практически ненужным или второстепенным, и все они оптимально распараллелены и опционально с загрузкой по требованию. На верхушке сего, все еще круче, потому что сокеты остаются доступны, тогда как на самом деле демон может стать временно недоступным (может быть вследствие «обрушения»). В действительности, вы можете запуститься, а затем остановиться (или упасть), и снова запуститься, и снова остановиться (и так далее), и все это без оповещения клиентов и потери каких-либо запросов с стороны клиентов.



Хороший момент, чтобы сделать паузу и пойти налить себе еще кофейка, и будьте уверены, что далее нас ждет материал еще более интересный.



Но в начале, давайте проясним несколько вещей: это какая-то новая логика? Нет, конечно же нет. Наиболее многообещающая система, которая работает как эта — это launchd от Apple: в MacOS прослушивание сокетов и запуск всех демонов делает launchd. Следовательно, все службы (демоны) могут запуститься параллельно и без необходимости в сконфигурированных зависимостях. И это в действительности изобретательное решение и главная причина почему MacOS предоставляет фантачтическое время загрузки. Я крайне рекомендую это видео где ребята из launchd объясняют, что и как они это делают. К сожалению, эта идея не была признана за пределами кампуса Apple.



Идея, на самом деле старее чем launchd. До launchd многоуважаемый inetd работал в схожем стиле: сокеты в основном создаются в демонах, которые запускает реальную службу (основной так сказать функционал), передавая дескриптор файла сокета функции exec(). Тем не менее, фокус inetd в основном был направлен не на локальные службы и демоны, а на службы Интернета (поздние реализации также поддерживают AF_UNIX сокет). inetd не был инструментом распараллеливания процесса загрузки системы или даже полезным для того чтобы получить правильные зависимости.



Для сокетов TCP inetd в основном использовался следующим образом: для каждого входящего соединения создавался новый экземпляр демона. Это означает, что для каждого соединения инициализировался и создавался новый процесс, что не назовешь рецептом для высокопроизводительных серверов. Тем не менее, с самого начала inetd также поддерживал и другой режим работы, где единственный демон создавался на первом соединении, и этот единственный экземпляр принимал последующие соединения (вот для чего был опции wait/nowait в inetd.conf, и эта была очень плохо документированная опция, к сожалению). Запуск демона на каждое соединение послужило для inted плохой репутацией как слишком медленного. Но это не совсем справедливо.



Распараллеливание служб шины



В современных службах в Linux прослеживается тенденция предоставлять службы через D-Bus взамен плоским AF_UNIX сокетам. Теперь, вопрос в следующем, можем ли мы применить ту же логику распараллеливания логики, как и для традиционных служб сокетов? Да, мы можем, D-Bus уже имеет все нужные механизм для этого: используя шину активации служба может быть запущена, когда в первый раз к ней обратятся. Шина активации также предоставляет нам минимальные функции синхронизации на каждый запрос, необходимый для запуска провайдеров и потребителей служб D-Bus одновременно: если мы хотим запустить Avahi одновременно с CUPS (отвлеченная заметка: CUPS использует Avahi чтобы обнаружить mDNS/DNS-SD принтеры), тогда мы можем запустить их одновременно, и если CUPS быстрее чем Avahi через логику активации шины, D-Bus поставит в очередь запрос до тех пора, пока Avahi занят, тем чтобы установить свое сервисное имя на шине.



Итак, таким образом: сокет-основанные активация службы и шина-основанная активация службы, вместе позволяют нам запустить все демоны параллельно, без какой-либо дальнейшей синхронизации. Активация также позволяет нам делать «ленвиую» загрузку сервисов: если служба (демон) редко используется, мы можем просто запустить его на первое обращение к сокету или к имени на шине, вместо того чтобы запустить его во время загрузки системы.



И если это не великолепно, то тогда я не знаю, что великолепно!



Продолжение следует…
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335488/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<linux - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda