Russian KDE community
Наконец-то увидел свет новый движок портала https://kde.ru, посвященного русскоязычным пользователям KDE и проету KDE в частности. И хотя сам я уже давно KDE не пользуюсь, до сих пор многое связывает меня с этим проектом. Именно с разработки KDE начался мой путь в мир свободного ПО. Еще будучи студентом я познкомился с проетом GNU, Linux и Qt3, а уже после, в Германии – когда я начал работу в SUSE – занимался разработкой и портированием стека KDE4 на openSUSE (больше всего постов в этом блоге именно о KDE и openSUSE). Мы тогда еще сидели на svn, помните что это такое? 🙂
После SUSE я забросил проект KDE, опробовал и пересел на различные window managers. До тех пор, пока не устроился разработчиком LiMux (Kubuntu на основе собственной management-системы на основе LDAP) тут, в Мюнхене. И хотя занимался я в основном security-проектами, было приятно вспомнить и почти весь KDE стек, который мы создавался более чем 10 лет назад.
Это очень интересный проект. Да, он большой, очень большой, и не всегда это хорошо, тем не менее он обладает самой на мой взгляд продуманной архитектурой. Программировать KDE всегда было здорово не только из-за мощи Qt и самым новейшим инструментам, используемым в проекте, но и благодаря идеям, заложенным в основу структуры стека его компонентов. Очень важным в проекте KDE всегда было сообщество людей, его разрабатывающих. Его окружило много молодых инженеров, открытых для новых, а порой даже и для откровенно сумасшедших идей. Это так освежало. Это так вписывалось в природу свободного ПО. Я никогда не забуду эти хиппи-тусовок по всей Европе, куда мы добирались по ночам и самыми сумасшедшими способами, доклады, подготавливаемые и читаемые друг другу просто ради удовольствия.
Я рад, что и в России есть люди, продолжающие разработку и продвигающие этот проект. Хочу пожелать вам, ребята, удачи. Постарайтесь сохранить эту атмосферу, сводящую с ума и увлекающую за собой. Я думаю, это самый большой стимул для разработки ПО. Увлечение процессом, удовольствие от наконец-то найденного решения, восхищение его элегантностью и простотой. Все это KDE, все это – сообщество людей, его продвигающих.
Leap 15.0 Beta testing: Fujitsu U757 Laptop
2 месяца назад нашел незначительный, но все же баг в ядре openSUSE Leap 15.0 (тогда еще это была Beta, build 174). Баг связан с лептопом Fujitsu U757 и воспроизводиться должен во всех дистрибутивах, т.к. проблема в upstream коде ядра.
Суть проблемы связана с поддержкой мультифункциональных клавиш, отвечающих за включение/выключение wifi.
Чтобы удостовериться, что kernel не обрабатывает нажатие клавиш, можно воспользоваться libinput. Это так называемый input device driver для X.org window system. С его помощью можно легко (в userland) отлавливать события, которые должны быть обработаны ядром. Так вот он показывал, что комбинация клавиш Fn+F5 при нажатии не давала никакого эффекта (F5 – это wifi-клавиша).
Тем не менее, при помощи rfkill wireless можно легко включить/отключить:
# rfkill list
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
# rfkill block 0
# rfkill list
0: phy0: Wireless LAN
Soft blocked: yes
Hard blocked: no
Как оно обычно и бывавает, много времени уходит на то, чтобы собрать достаточно материала. Долгое время я не был уверен, что делаю все верно. С толку сбивало и то, что в других дистрибутивах проблема воспроизводилась один в один. Я отключил Bluetooth в BIOS, чтобы только одно устройство влияло на работу LED на корпусе лептопа. Таким образом, LED должен был загораться при включении wireless и наоборот – тухнуть при выключении. Этого не происходило…
Я решил опробовать другие ядра. Я ставил ядро из репозиториев Kernel:stable (на тот момент это было ядро 4.15.13) и Kernel:HEAD (4.16 rc7-1). Это не решило проблему.
Спустя какое-то время я нашел в сети описание этой проблемы и патч. Я отправил bugreport. Такаши, один из разработчиков в Kernel Team, сказал мне, что патч будет принят в upstream в 4.17-rc1. В стандартное Leap-ядро этот фикс сразу же не попал, т.к. баг не слишком критичен, НО Такаши пересобрал ядро с этим исправлением для SLE15 и Leap15. Leap пользователи могут установить его отсюда. Это исправление будет в Leap совсем скоро официально, в виде maintenance update.
После установки этого ядра libinput отлавливает events:
# libinput debug-events -event7 KEYBOARD_KEY +3.51s KEY_RFKILL (247) pressed event7 KEYBOARD_KEY +3.51s KEY_RFKILL (247) released
В качестве заключения я хочу сказать всем разработчикам: слушайте свою интуицию, не давайте никому сбить вас с толку. Полагайтесь в первую очередь на свой опыт. Не слушайте коллег, которые подгоняют логику под увиденный результат. К сожаленью, часто бывает, когда вы стоите в шаге от правильного решения, но все же решаете посоветоваться, коллеги начинают вас переубеждать. Защайтесь. Не ленитесь перепроверить все еще раз.
Удачи! Have a lot of fun =)
Leap 15.0 Beta testing: configuring 802.1x (auth with RADIUS)
В этом посте я попытаюсь рассказать как настроить IEEE 802.1x в openSUSE. Сейчас Leap 15.0 в активной стадии бета-тестирования, поэтому возьмем её и для клиента и для сервера, чтобы убедиться, что все работает как надо, и никаких неприятных сюрпризов в финально-официальном релизе нам ждать не придется.
Если в двух словах, 802.1x это стандарт сетевой аутентификации. Работает на втором OSI уровне и определяет механизм контроля доступа к сети на основе принадлежности к порту и проверки x509-сертификатов. Доступ к сети получают только клиенты прошедшие аутентификацию. В качестве “системы, проверяющей подлинность” или просто аутентификатора я буду использовать CISCO SG300-28 28-Port Gigabit Managed Switch. Для проверки он будет обмениваться сертификатами с authentication server, который мы попытаемся развернуть на отдельной машине и который будет колдовать для нас x509 TLS-сертификаты.
Authentication server
Когда я только задумывал этот пост, я представлял это себе как “пустяковое дело на 20 минут”. Сразу же после установки я понял, что “приключение начинается”. Инсталлер разучился отключать firewall и включать OpenSSH. Фича? Аха щас… BUG! Первый баг. Попался 🙂 Пытался сначала достучаться до людей в IRC, все бестолку. Три дня думал, что я что-то пропустил и искал информацию. Так ничего и не найдя, я заглянул в ML, где меня ждал успех.
Очень не приятно после установки заходить в систему и отключать firewalld и включать sshd… но на сейчашний момент это именно то, что мы имеем:
# systemctl stop firewalld # systemctl disable firewalld # systemctl start sshd # systemctl enable sshd
Напомню, что мы тут просто тестируем 802.1x. На практике отключать firewall конечно же не обязательно, достаточно открыть UDP/1812 и UDP/1813 порты.
Приступаем к установке authentication server. Мы будем использовать freeradius. Последняя стабильная версия – 3.0.16 – вышла два месяца назад. В openSUSE пакет называется freeradius-server. Устанавливаем его:
> sudo zypper in freeradius-server > rpm -qa freeradius-server freeradius-server-3.0.16-lp150.1.3.x86_64
После установки переходим в /etc/raddb/certs. Тут все будем делать от root.
# ll /etc/raddb/certs total 48 -rw-r----- 1 root radiusd 6155 Feb 20 06:18 Makefile -rw-r----- 1 root radiusd 8714 Feb 20 06:18 README -rwxr-x--- 1 root radiusd 2706 Feb 20 06:18 bootstrap -rw-r----- 1 root radiusd 1432 Feb 20 06:18 ca.cnf -rw-r----- 1 root radiusd 1103 Feb 20 06:18 client.cnf -rw-r----- 1 root radiusd 1131 Feb 20 06:18 inner-server.cnf -rw-r--r-- 1 root radiusd 166 Feb 20 06:18 passwords.mk -rw-r----- 1 root radiusd 1125 Feb 20 06:18 server.cnf -rw-r----- 1 root radiusd 708 Feb 20 06:18 xpextensions
Документация о том, как сгенерировать сертификаты (самый минимум) находится в файле README. 3 шага: генерация root-сертификата (ca.pem), генерация сертификата сервера (server.pem) и клиента (client.pem). Необходимые параметры нужно указать в конфиг файлах: ca.cnf, server.cnf и client.cnf соответственно.
Несмотря на то, что все кажется простым и логичным, генерация TLS/SSL сертификатов может быть оказаться достаточно запарным процессом. Особенно если вы нечасто этим занимаетесь. Дело в том, что сообщения об ошибках не всегда понятны. Давайте рассмотрим пару примеров.
Во-первых, нигде не сказано, что пароль в /etc/raddb/certs/server.cnf и /etc/raddb/mods-enabled/eap должен быть один и тот же. Вот в этом месте файла /etc/raddb/mods-enabled/eap надо быть осторожней:
tls-config tls-common {
private_key_password = myTEST1eap
private_key_file = ${certdir}/server.pem
Вот так выглядит часть /etc/raddb/certs/server.cnf файла, где нужно быть чуточку внимательней:
[ req ] prompt = no distinguished_name = certificate_authority default_bits = 2048 input_password = myTEST1eap output_password = myTEST1eap x509_extensions = v3_ca
Если пароли окажутся разными, то при запуске cервера мы получим в логах вот это:
Wed Mar 7 17:08:15 2018 : Info: Debugger not attached Wed Mar 7 17:08:15 2018 : Error: tls: Failed reading private key file "/etc/raddb/certs/server.pem" Wed Mar 7 17:08:15 2018 : Error: tls: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt Wed Mar 7 17:08:15 2018 : Error: tls: error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal error Wed Mar 7 17:08:15 2018 : Error: tls: error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe crypt error Wed Mar 7 17:08:15 2018 : Error: tls: error:0907B00D:PEM routines:PEM_read_bio_PrivateKey:ASN1 lib Wed Mar 7 17:08:15 2018 : Error: tls: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib Wed Mar 7 17:08:15 2018 : Error: rlm_eap_tls: Failed initializing SSL context Wed Mar 7 17:08:15 2018 : Error: rlm_eap (EAP): Failed to initialise rlm_eap_tls Wed Mar 7 17:08:15 2018 : Error: /etc/raddb/mods-enabled/eap[14]: Instantiation failed for module "eap"
Согласитесь, с ходу не ясно в чем тут может быть проблема.
Остальные пароли могут быть (должны быть) разными.
Во-вторых, можно забыть про команду:
# openssl dhparam -out dh 2048
В bootstrap скрипте она есть, но если вы решите сгенерировать сертификаты дважды и отчистите все командой
# make destroycerts
то make удалит и файл /etc/raddb/certs/dh, а при make ca.pem или make server.pem файл dh снова создан не будет. При запуске сервера это приведет к следующему сообщению в логах:
Wed Mar 7 16:18:44 2018 : Info: Debugger not attached Wed Mar 7 16:18:44 2018 : Error: Unable to check file "/etc/raddb/certs/dh": No such file or directory Wed Mar 7 16:18:44 2018 : Error: rlm_eap_tls: Failed initializing SSL context Wed Mar 7 16:18:44 2018 : Error: rlm_eap (EAP): Failed to initialise rlm_eap_tls Wed Mar 7 16:18:44 2018 : Error: /etc/raddb/mods-enabled/eap[14]: Instantiation failed for module "eap"
Обратите внимание, что в README файле написано, что удалять старые сертификаты нужно вот так:
# rm -f *.pem *.der *.csr *.crt *.key *.p12 serial* index.txt*
т.е. без dh файла. Это, пожалуй, единственная проблема, суть которой ясна из сообщения об ошибке.
И вот еще одина проблема, с которой, я надеюсь, никому не придется столкнуться:
failed to update database TXT_DB error number 2
Она возникает по причине того, что CN (Common Name) для генерируемого сертификата такое же как и для CA-сертификата.
Последний шаг настройки RADIUS – прописываем имя, ip и secret клиента (остальное можно оставить как есть) в /etc/raddb/clients.conf. Клиент в данном случае – наш cisco-коммутатор. Шаг простой, но очень важный. Без него RADIUS не будет отвечать коммутатору. Secret тут должен быть как можно сложнее.
После того как все сертификаты созданы, для уверености их можно сверить:
# openssl verify -CAfile ca.pem client.crt client.pem client.crt: OK client.pem: OK
Если все в порядке, запускаем сервер, проверяем созданные им сокеты:
# systemctl start radiusd # lsof -i :1812 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME radiusd 4811 root 7u IPv4 179990 0t0 UDP *:radius radiusd 4811 root 9u IPv6 179994 0t0 UDP *:radius # lsof -i :1813 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME radiusd 4811 root 8u IPv4 179993 0t0 UDP *:radius-acct radiusd 4811 root 10u IPv6 179995 0t0 UDP *:radius-acct # tcpdump -vv -n -i eth0 -S port 1812 -l -A -X
Последняя команда может помочь при отладке. Вы видете, что именно ушло в сеть. Даже если вы подробно не знакомы с EAP, можно заметить отличие удачных попыток авторизации и не очень удачных 🙂 Если по той или иной причине возникли проблемы, log radius-сервера находится в /var/log/radius/radius.log.
Если все же возникнет какая-то новая проблема, которая тут не описана, и вы начнете искать информацию в инете и найдете примеры программы radtest(1) и попытаетесь ее запусить… в openSUSE она лежит в отдельном пакете:
> rpm -qf $(which radtest) freeradius-server-utils-3.0.16-lp150.1.3.x86_64
Я не стал описывать ВСЕ, что мне пришлось пережить за эти пару дней… и так этот пост разбух и стал походить на статью. Возможно я напишу еще что-то о самой openssl в отдельной статье. Тема PKI очень интересная и нужная. Ее понимание требуют многие работадатели.
Но вернемся к нашему тестированию. Переходим к настройке нашего коммутатора. Пока новых жуков не обнаружено 🙂
Authenticator
Настройка аутентификатора (или “системы, проверяющей подлинность”) сводится к простому добавлению в список RADIUS-серверов только что настроенной машины. Security => RADIUS => Add:
В появившемся окне просто добавляем IP-адрес и secret, который мы указывали /etc/raddb/clients.conf на RADIUS-сервере. Secret – это фактически единственный механизм аутентификации между cisco-коммутатором и сервером проверки подлинности (RADIUS). Эта часть сети в 802.1x-схеме подразумевает достаточно доверительные отношения между хостами, т.е. остается практически не защищенной. Поэтому повторюсь – secret должен быть как можно сложнее.
Client
Переходим к последнему шагу – настройке клиента.
Да, друзья мои, в качестве клиента openSUSE сейчас использовать увы, не получится. Для тестирования 802.1x мне пришлось взять какой-то другой GNU-дистрибутив. Но обо всем по порядку.
Сначала я поставил Leap 15.0 Beta с Plasma 5.12 LTS. networkmanagement отказался создавать соединение, и я сначала подумал, что проблема в созданных мной сертификатах. Я потратил несколько дней на проверку и перегенерацию сертификатов. Я устанавливал Leap с GNOME… с Xfce… и вообще без X. Паралельно я проверял все в Tumbleweed, и это меня и сбило с толку. Там соединение тоже не работало и я подумал, что проблема на 8 OSI уровне 🙂
Через несколько дней я попробовал другие GNU-дистрибутивы и оказалось, что, используя те же самые сертификаты и конфиги, там соеднинение удается создать одной командой…
BUUUUG! Да, черт побери, и сидит он так глубоко, что ни одним NM-апплетом его не достать. Он воспроизводится и через nmcli(1):
# cat /etc/NetworkManager/system-connections/LEAP_8021x [connection] id=LEAP_8021x uuid=de2f2a7c-33cc-4d92-ae3b-785575dffddc type=ethernet permissions=user:alex:; [ethernet] auto-negotiate=true mac-address-blacklist= [802-1x] ca-cert=/home/alex/ca.pem client-cert=/home/alex/client.crt eap=tls; identity=GNOME private-key=/home/alex/client.pem private-key-password=GNOME [ipv4] dns-search= method=auto [ipv6] addr-gen-mode=stable-privacy dns-search= method=auto # nmcli con reload # nmcli con up LEAP_8021x
Secrets are required to access the wired network 'LEAP_8021x' Warning: password for '802-1x.identity' not given in 'passwd-file' and nmcli cannot ask without '--ask' option. Error: Connection activation failed: Secrets were required, but not provided
Secret я использую и в конфиге и прописывал его и в апплетах GNOME и KDE. Не принимает ни в какую.
Пробовал испльзовать ‘–ask’, результат тот же: спашивает, вводишь пароль… снова спрашивает, снова вводишь… снова спрашивает…
# nmcli con up LEAP_8021x --ask Secrets are required to access the wired network 'LEAP_8021x' Identity (802-1x.identity): GNOME Secrets are required to access the wired network 'LEAP_8021x' Private key password (802-1x.private-key-password): *****
Secrets are required to access the wired network 'LEAP_8021x' Identity (802-1x.identity): GNOME Secrets are required to access the wired network 'LEAP_8021x' Private key password (802-1x.private-key-password): *****
Я использовал и wpa_supplicant(1). Результат такой же. Он просто повисает.
Чтобы довести дело до конца я взял Kubuntu 17.10. Выбор был не случайным, т.е. это не был “первый дистрибутив, который попался под руку”. Пока я искал инфу по поводу проблем с 802.1x, я нашел этот BUG. Я не уверен, что это именно то, но повеселил меня не тот факт, что проблема в upstream’е, а то, КАК это решили в Ubuntu 🙂 Ребятами из RedHat (хотя там ссылка на GNOME, а оттуда на Debian…) было предложено и другое решение. Следить за изменениями я уже не стал. Хотя разобраться до конца все же стоило бы.
В Kubuntu 17.10 просто кидаешь конфиг в /etc/NetworkManager/system-connections/802.1x и перезапускаешь сеть (без ‘–ask’), как я показал выше. Понадобятся 3 сертификата: клиентские сертификаты client.pem и client.crt (к ним надо знать secret) и root-сертификат CA.pem. При генерировании новых клиентских сертификатов нужно лишь обновить client.cnf (имя и secret) и сделать
# make client.pem
Помните, что в случае повторной генерации root-сертификата придется перенастраивать уже настроенные клиенты.
Итак, ситуация Leap 15.0 пока очень и очень не классная. BUG’ов в beta хватает. О них знают, и можете быть уверенными, друзья мои, их исправят.
Оставайтесь на светлой стороне. И да прибудет с вами удовольствие от работы с openSUSE 🙂
openSUSE Leap 15.0: call for testers
Самый разгар тестирования следующей major-версии openSUSE – Leap 15.0. Beta доступна уже без малого месяц. Как и обычно, качество системы зависит от нас с вами, друзья. Для тех, кто никогда не принимал участия в разработке openSUSE, но хотел бы наконец-то помочь, самое время скачать Leap 15.0, установить и погонять его по самые не балуй 🙂 на своей машине (хотя бы виртуальной) или машине своего коллеги 😀 Помните, что beta-версия нестабильна и может сломаться в самом непредсказуемом месте.
О всех найденных ошибках надо сообщить нам в bugzilla.
Важно понимать, что система разрабатывается силами сообщества, и ее качество в большей мере зависит он нас с вами. Ошибается тот, кто думает, что в Нюрнберге все и так сделают как надо и даже лучше. Там ребята работают главным образом над SLE – тем, что приносит SUSE деньги. Дистрибутив openSUSE отдан сообществу: энтузиастам, дизайнерам, программистам… и простым пользователям. У нас есть права менять его как мы захотим. Более того – от нас этого ожидают. Не будем же делать вид, что это не так.
Итак, что мы имеем на сейчашний момент? На момент написания этого поста актуальным является build139. Второй и третьей официальной beta, как это было когда-то, не будет. Теперь beta меняется по принципу rolling release. Уже где-то через месяц, в апреле/мае, мы перейдем на фазу release candidate. Было бы здорово найти как можно больше и начать работать над исправлениями ДО начала этой фазы.
Так как следующий Leap получится мажором, поддерживаться он будет не 12 (в отличии от минорных релизов, привязанных к SUSE Linux Enterprise Service Packs), а 36 месяцев.
Так что же собственно тестировать? Для каждого из нас есть свои use cases. Кто-то админит самый обычный web- и mail-сервер, кто-то не может представить свою жизнь без какой-то хитроумной конфигурации Kerberos, кто-то в Leap видит исключительно desktop-систему и захочет посмотреть на сколько стабильна в ней работает Plasma 5.12 LTS. Я, к примеру, планирую протестировать sddm c PAM, а так же freeradius сервер со своим 802.1x L3-свитчем. Также будет интересно посмотреть, получится ли обновить свой Leap до нового Leap 15.0.
Кстати, в Leap 15.0 используется новый rpm из Tumbleweed – версии 4.14.1 (с целым вагоном и маленькой тялежкой SUSE-патчей). Возможно там получится что-то найти.
Я оставлю ссылку на эту таблицу. Туда вы можете добавить себя и добавить комментарий, если что-то сломано и не заработало (если заработало, тоже можете оставить комментарий). Помните только, что если что-то не заработало, и вы написали там об этом, мы будем ожидать, что вы откроете report в bugzilla, где и будет проходить дальнейшее обсуждение проблемы.
Возможно вам будет также интересно узнать о состоянии автотестирования.
Актуальное состояние пакетной базы Leap 15.0 можно посмотреть вот тут.
Там же есть ссылка на изменения, которые ожидают Leap 15.0.
Если у вас возникли вопросы, я всегда буду рад помочь вам. Оставляйте комментарии или просто пишите на alexander_naumov @openSUSE.org. Меня так же можно найти на freenode IRC-сервере. Мой ник там – anaumov. Удачи!
openSUSE Conference 2017
В конце прошлого месяца разработчики openSUSE снова собрались в Нюрнберге, чтобы обсудить дальнейшее развитие дистрибутива и просто пообщаться и весело провести время вместе. В последние пару лет проект стал очень быстро меняться. К проекту присоединилось очень много новых людей. Новые идеи, которые они приносят, находят свое место в новых проектах, разрабатываемых для openSUSE. Даже используя все информационные каналы проекта openSUSE, тяжело уследить за всеми новшествами, включаемыми в проект, и просто меняющейся стратегией совета. Поэтому вопрос о посещении конференции, тем более, если вы мейнтейнер, долгого размышления не потребует 🙂
Конференция была открыта докладом Матиаса о LiMux. Краткая история проекта, его взлет, надежды и его падение… Явный пример того, на сколько опасны могут быть политики, пользующиеся властью для удовлетворения собственных предпочтений, и закрывающие глаза на интересы и желания населения. В настоящий момент я как раз работаю над этим проектом в администриции Мюнхена.
На конференции я снова встретился с Дмитрием, занимающимся проектом invis и продвижением Free Software решений на базе 1C в Германии. Беседовали о русскоязычном сообществе openSUSE, и о причинах его столь плачевного состояния. Я очень надеюсь, что сообществу получится преодалеть существующие проблемы и оно снова возьмет курс на развитие, как было в 2008-2010 годах.
Познакомился с Денисом Кондратенко из Киева и его женой. Очень приятная пара. Денис рассказывал о Ceph и EKG в openSUSE, а также о методах обработки метаданных в Elasticsearch. Мой личный опыт использования Elasticsearch ограничивается только BigData/Hadoop, поэтому и тут удалось узнать что-то новое.
Много новых иновационных идей было услышано от Ричарда. Он уже давно стал openSUSE evangelist’ом; его доклады об OBS или openQA можно услышать практически на каждой европейской Free Software конференции, посвященной GNU/Linux. Я всем советую посмотреть его доклад о Containerised Application.
Одним из спонсоров конференции в этом году стал fedora project. Fedora уже не первый год использует нашу систему openQA для автоматического тестирования linux-систем, а сотрудники RedHat уже во второй раз читают свои доклады на openSUSE Conference. В этом году это был доклад How semantic analysis of C and C++ ELF binaries can be used to analyze ABI changes, в прошлом году это были Enforcement of a system-wide crypto policy и Testing complex software in CI.
В общем, как и обычно, конферениция оставила приятное впечатление (пару фоток можно найти тут). И хотя в этом году она длилась всего 3 дня вместо 5, как в прошлом, информации для размышления я пролучил придостаточно. Её посещение в этом году не стоило мне ничего. Спасибо за это TSP. В следующем году она пройдет в Праге, куда я планирую поехать с семьей. Возможно там я встречусь и с теми, кто читает сейчас эти стоки 😉
openSUSE :: kernel of the day
Для тех, кто по той или иной причине хочет использовать последнюю версию ядра, но постоянно пересобирать ее вручную нет ни времени ни желания, openSUSE проект делает это за нас. Идея Kernel Of The Day – предоставить тестерам и прсто kernel инженерам последнюю git-версию ядра в виде RPM пакета. Это devel проект для ядра, в котором собираются версии для последующего тестирования и отправлки в tumbleweed. Делается это также с целью получить feedback от сообщества в виде bugreports или просто в ML/IRC.
Процесс полностью автоматизированный. Вы подключаете репозиторий и обновляетесь (каждый раз как пакет с новым ядром доступен для установки) как и обычно.
Версия unstable, поэтому имеет смысл не перезаписывать каждый раз старое ядро, а добавлять новое. Это не работает автоматически. Для этого надо отредактировать /etc/zypp/zypp.conf. Добавьте две строчки:
multiversion = provides:multiversion(kernel) multiversion.kernels = latest,running
Подробнее о multiple kernel.
Добавлю, что система ломатеся. Ломается достаточно часто. Только что, к примеру, у меня поломался dracut на ядре 4.9.0-2. Я не cмог загрузиться, т.к. он связан с LUKS, а я использую шифрование. Откатился назад на 4.8.13.
Интерсно, что именно сломано, почему и как починить. Это как раз ответ на вопрос “зачем мы этим занимаемся?”. Если бы этого не произошло, я вряд бы ли стал разбираться глубже в dracut. Проект таким способом предоставляет идеальную трейнинг площадку для энтузиастов, где обучение проходит в играющей форме 🙂
Linux Kernel 4.7 Update for openSUSE
Пару дней назад вышло ядро 4.7. В связи с этим наш репозиторий Tumbleweed в скором будущем будет обновлен. Для тех же, кому по той или иной причине нужны самые свежие версии ядер, собраные для openSUSE (не только Tumbleweed), существует специальный kernel-репозиторий. Там лежат ядра, собранные сразу же после официального релиза (в тот же день). Доступны сборки не только для x86, но и для ARM и Power. Есть vanilla.
Установка не предствляет из себя ничего сложного – самое обычное обновление rpm-пакета.
Я только что обновил ядро на одной из своих тестовых систем. Это 32-битный x86 нетбук c установленной (где-то в середине июня) Tumbleweed.
# uname -pr 4.6.2-1-pae i686 # zypper ar -f http://download.opensuse.org/repositories/Kernel:/HEAD/standard/Kernel:HEAD.repo Adding repository 'Kernel builds for branch master (standard)' ...............................[done] Repository 'Kernel builds for branch master (standard)' successfully added Enabled : Yes Autorefresh : Yes GPG Check : Yes Priority : 99 URI : http://download.opensuse.org/repositories/Kernel:/HEAD/standard/ # zypper lr # | Alias | Name | Enabled | GPG Check | Refresh --+---------------------+--------------------------------------------+---------+-----------+-------- 1 | Kernel_HEAD | Kernel builds for branch master (standard) | Yes | ( p) Yes | Yes 2 | openSUSE-20160613-0 | openSUSE-20160613-0 | No | ---- | Yes 3 | packman | packman | Yes | (r ) Yes | Yes 4 | repo-debug | openSUSE-Tumbleweed-Debug | No | ---- | Yes 5 | repo-non-oss | openSUSE-Tumbleweed-Non-Oss | Yes | (r ) Yes | Yes 6 | repo-oss | openSUSE-Tumbleweed-Oss | Yes | (r ) Yes | Yes 7 | repo-source | openSUSE-Tumbleweed-Source | No | ---- | Yes 8 | repo-update | openSUSE-Tumbleweed-Update | Yes | (r ) Yes | Yes
Значит новый репозиторий называется Kernel_HEAD. Хорошо, я хочу обновиться только из него:
# zypper dup -r Kernel_HEAD Retrieving repository 'Kernel builds for branch master (standard)' metadata --------------------[\] New repository or package signing key received: Repository: Kernel builds for branch master (standard) Key Name: Kernel OBS Project Key Fingerprint: 4529410A B52F94C4 03BAB484 ECEEF210 03579C1D Key Created: Mi 22 Apr 2015 14:25:51 CEST Key Expires: Fr 30 Jun 2017 14:25:51 CEST Rpm Name: gpg-pubkey-03579c1d-5537934f Do you want to reject the key, trust temporarily, or trust always? [r/t/a/? shows all options] (r): a Retrieving repository 'Kernel builds for branch master (standard)' metadata ...................[done] Building repository 'Kernel builds for branch master (standard)' cache ........................[done] Loading repository data... Reading installed packages... Computing distribution upgrade... The following 2 NEW packages are going to be installed: kernel-default-4.7.rc7-2.1.g152f160 kernel-pae-4.7.0-1.1.g24f30d5 The following 2 packages are going to be upgraded: kernel-firmware ucode-amd The following 2 packages are going to change vendor: kernel-firmware openSUSE -> obs://build.opensuse.org/Kernel ucode-amd openSUSE -> obs://build.opensuse.org/Kernel 2 packages to upgrade, 2 new, 2 to change vendor. Overall download size: 156.5 MiB. Already cached: 0 B. After the operation, additional 372.8 MiB will be used. Continue? [y/n/? shows all options] (y): y
После установки просто перезагружаемся и наслаждаемся работой нового ядра.
> uname -pr 4.7.0-1.g24f30d5-pae i686
Обновляя ядра, вы не только становитесь привлекательнее для девушек, но и помогаете проекту в качестве beta-тестера. Помните, что Tumbleweed это не самое-самое свежее ПО. Это коллекция уже протестированных вместе компонентов.
“Стоит ли мне учавстовать в этом? А вдруг я себе что-то сломаю?”, – подумает ленивец. Нет, вероятность того, что произойдет креш системы очень мал. Прежде чем ядро официально выпустят, оно пройдет серию тестов.
Если креш все же произошел, всегда можно загрузить старое ядро, в котором вы работали прежде (и где все работало). В этом случае вы очень поможете, если не поленитесь сообщить нам о возникшей проблеме.
Посмотреть список установленных ядер можно вот так:
# zypper se -si 'kernel*' Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository --+-----------------+---------+----------------------+--------+--------------------------------------- i | kernel-default | package | 4.6.2-1.2 | i586 | (System Packages) i | kernel-default | package | 4.7.rc7-2.1.g152f160 | i586 | Kernel builds for branch master i | kernel-firmware | package | 20160712-137.1 | noarch | Kernel builds for branch master i | kernel-pae | package | 4.6.2-1.2 | i686 | (System Packages) i | kernel-pae | package | 4.7.0-1.1.g24f30d5 | i686 | Kernel builds for branch master
Как видете, старое ядро никуда не делось. Я отправляю всех интересующихся к 12 главе нашего руководства. Там описана Multiple Kernel магия для zypper.
Обновившись, я протестировал сейчас, к примеру, LUKS и совместимость с проприетарным broadcom модулем для wireless. Все работает как и прежде, значит я иду дальше – перехожу к обновлению на своих ARM embedded-системах, чтобы удостовериться, что и там все работает как надо. Счастливо 😉
aarch64: SoftIron Overdrive 1000
24 июня, во время openSUSE Conference 2016, Norman Fraser (Chief Executive Officer из компании SoftIron Ltd.) представил новую aarch64 серверную out-of-the-box систему. Overdrive 1000 привлек внимание многих и не только потому, что она продается с предустановленной openSUSE. По словам Нормана, это тчательно продуманная 64-битная ARM® developer-система с AMD Opteron A1100™ процессором. Многие разработчики хотят больше, чем могут предложить обычные development-board embedded системы. Все помнят обсуждение ARM как десктопной архитектуры после LinuxCon Europe в конце прошлого года.
Overdrive 1000 продается с openSUSE Leap 42.1, где уже установленны Apache Web-сервер, MySQL, PHP, Xen, KVM, Docker и openJDK. Таким образом, пользователи могут приступать к работе сразу же после загрузки ОС. Напомню, что для aarch64 существуют установочные образу практически для всех известных дистрибутивов. Пользователи tumbleweed, к примеру, могут скачать установочные образы отсюда.
Overdrive 1000 стоит всего $599. За эти деньги мы получаем:
- Processor cores 4 x 64-bit ARM Cortex A57 Cores
- 2 x RDIMM with 8GB DDR4 DRAM (можно увеличить до 64 GB)
- 1 x 1GBase-T Ethernet
- 2 x USB 3.0 ports
- 2 x SATA 3.0 ports
- 1 x 1TB HDD
- Wirespeed 1Gbps throughput
- Low and predictable energy consumption at 45 watts max
Собираюсь ли я заказывать эту систему? Однозначно ДА! Docker уже поддерживает aarch64 (раз, два), а это был пожалуй единственный вопрос, который меня беспокоил. Пока я работал только с 32-битными ARM системами, пора переходить на 64 😉
openSUSE :: adding static routes in NM
Новичков в openSUSE вводит в заблуждение настройка сети из-за того, что для её управления существует несколько независимых технологий. В openSUSE Tumbleweed сегодня используется NetworkManager и wicked. Первый используется по умолчанию. Если же вам, к примеру, понадобится добавить статический маршрут и вы спросите об этом гугл, скорее всего в первую очередь вы найтдете классический способ сделать это. Помние, этот способ не сработает, если вы используете NM, и наоборот. Также не стоит забывать, что настройки сети в разных дистрибутивах могут отличаться.
Добавить маршрут можно с помощью команды route. В данном примере для доступа в сеть 172.19.0.0/16 я использую рутер 172.20.1.161. Тут стоит помнить лишь о том, что эти настройки пропадут после перезагрузки.
# route add -net 172.19.0.0 netmask 255.255.0.0 gw 172.20.1.161
Чтобы настройки не пропали, нужно прописать их в конфиге NM. Для каждого соединения существуют свои настройки. Загляните в каталог /etc/NetworkManager/system-connections. Там находится список файлов, каждый из которых относиться к тому или иному соединению. Чтобы добавить route правило, о котором я говорил выше, просто добавьте такую строчку в секцию [ipv4]:
route0=172.19.0.0/16;172.20.1.161
Если вы используете KDE Workspace, вы можете добавить эти настройки в KDE NM-апплете. Для этого просто правый клик на иконке, выбираем “Configure Network Connections…”
Появляется список соедининий. Выбираем нужное нам, нажимаем “Edit”. В появившемся окне переходим во вкладку IPv4 и там нажимаем “Routes…”, где можно добавить новые или удалить старые маршруты.
openSUSE :: MySQL & Ruby
Наконец-таки нашел немного времени для знакомства с Ruby. Присматривался к нему уже наверное лет 5. Сначала SUSE стала создавать свои web сервисы на Ruby, потом вышел WebYaST… Что связанно с SUSE, Ruby исползуется повсеместно. Наконец и YaST был переписан на Ruby, а это значит, что openSUSE стал первым дистрибутивом, где установщик полностью написан на этом языке. Сегодня его просто нельзя уже игнорировать. Итак, я собираюсь начать восхождение как можно быстрее. Вы со мной? 🙂
Я покажу, что Leap 42.1 прекрасно подходит для изучения Ruby. В качестве примера рассмотрим работу с MySQL (на работе мне постоянно приходится писать автономные программы, поведение которых зависит от данных в БД); что-нибудь самое простое.
Если вы уже работали с БД, к примеру, в Python или Lisp, то приведенный ниже код поймете сразу. Require подключает модуль mysql. Мы создаем mysql-объект con. С помошью его метода query создаем SQL-запрос. Пробегаемся по выводу при помощи each do, при этом каждой строке из вывода присваиваем имя row. Я использую puts для вывода информации на экран. В Ruby есть и всем известный print. Разница в том, что puts добавляет символ новой строки в конец вывода, а вот print этого не делает. 14-16 строки обрабатывают ошибку (показывают ее вывод, но программа продолжает работу), если такая возникнет при попытке соединиться и получить данные. В конце мы вызываем close, который закрывает соединине.
#!/usr/bin/ruby
require 'mysql'
begin
con = Mysql::new('10.10.10.10',
'login',
'password',
'centreon')
con.query('SHOW columns FROM nagios_server').each do |row|
puts "#{row[0]} #{row[1]} #{row[2]} #{row[3]}"
end
rescue Mysql::Error => e
puts e.errno
puts e.error
ensure
con.close if con
end
При первом запуске (используем свежую Leap 42.1 x86_64) получаем ошибку:
> ./mysql-test.rb
/usr/lib64/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55: \
in `require': cannot load such file -- mysql (LoadError)
from /usr/lib64/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from ./mysql-test.rb:2:in `'
Тут все понятно: require не может найти mysql. Для установки воспользуемся gem. Это аналог Lisp’овского QuickLisp или Python’овского pip.
> gem --help
RubyGems is a sophisticated package manager for Ruby. This is a
basic help message containing pointers to more information.
Usage:
gem -h/--help
gem -v/--version
gem command [arguments...] [options...]
Examples:
gem install rake
gem list --local
gem build package.gemspec
gem help install
Further help:
gem help commands list all 'gem' commands
gem help examples show some examples of usage
gem help platforms show information about platforms
gem help show help on COMMAND
(e.g. 'gem help install')
gem server present a web page at
http://localhost:8808/
with info about installed gems
Further information:
http://guides.rubygems.org
> gem list --local mysql
*** LOCAL GEMS ***
>
Нет ни одной установленной в системе mysql gem.
Обратите внимание на вывод gem’овской help – для команды list сказано только по поводу –local аргумента. Там есть еще –remote. Последний покажет доступные для установки gem’ы. Я не привожу тут вывод, потому что список слишком большой.
Для установки воспользуемся командой install:
# gem install mysql
Fetching: mysql-2.9.1.gem (100%)
Building native extensions. This could take a while...
ERROR: Error installing mysql:
ERROR: Failed to build gem native extension.
/usr/bin/ruby.ruby2.1 extconf.rb
mkmf.rb can't find header files for ruby at /usr/lib64/ruby/include/ruby.h
extconf failed, exit code 1
Gem files will remain installed in
/usr/lib64/ruby/gems/2.1.0/gems/mysql-2.9.1 for inspection.
Results logged to
/usr/lib64/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0/mysql-2.9.1/gem_make.out
И я вам скажу честно – так происходит со многоими gem’ами 🙂
Но на самом деле ничего страшного не случилось. Дело в том, что gem’у нужен файл из RPM-пакета. Какого-то RPM пакета… Вызывать zypper нам придется самим. Какой пакет устанавливать? Мне повезло, я вспомнил, что один RPM-пакет нужно было доустановить и в случае с Common Lisp. В том случае это был libmysqlclient, для Ruby же нужен libmysqlclient-devel. Очень рекомендую еще поставить пакет ruby-devel и весь pattern devel_basis. Там много библиотек, необходимых интерпретору.
> sudo zypper in -t pattern devel_basis > sudo zypper in ruby-devel libmysqlclient-devel
После этого попытаемся установить mysql gem снова:
> gem install mysql Building native extensions. This could take a while... Successfully installed mysql-2.9.1 Parsing documentation for mysql-2.9.1 Installing ri documentation for mysql-2.9.1 Done installing documentation for mysql after 0 seconds 1 gem installed > echo $? 0 > gem list --local mysql *** LOCAL GEMS *** mysql (2.9.1)
Выглядит лучше, правда? Теперь вернемся к коду выше. Придумайте для теста какой-нибудь простой SQL запрос. Что-нибудь типа show tables, к примеру. Вывод скрипта, приведенного выше, выглядит так:
./mysql-test.rb
id int(11) NO PRI
name varchar(40) YES
localhost enum('0','1') YES
is_default int(11) YES
last_restart int(11) YES
ns_ip_address varchar(255) YES
ns_activate enum('1','0') YES
ns_status enum('0','1','2','3','4') YES
init_script varchar(255) YES
monitoring_engine varchar(20) YES
nagios_bin varchar(255) YES
nagiostats_bin varchar(255) YES
nagios_perfdata varchar(255) YES
centreonbroker_cfg_path varchar(255) YES
centreonbroker_module_path varchar(255) YES
centreonconnector_path varchar(255) YES
ssh_port int(11) YES
ssh_private_key varchar(255) YES
init_script_snmptt varchar(255) YES
Для сравнения, вот так выглядит вывод нашего SQL запроса в mysql(1):
> SHOW columns FROM nagios_server;
+----------------------------+---------------------------+------+-----+---------+
| Field | Type | Null | Key | Default |
+----------------------------+---------------------------+------+-----+---------+
| id | int(11) | NO | PRI | NULL |
| name | varchar(40) | YES | | NULL |
| localhost | enum('0','1') | YES | | NULL |
| is_default | int(11) | YES | | 0 |
| last_restart | int(11) | YES | | NULL |
| ns_ip_address | varchar(255) | YES | | NULL |
| ns_activate | enum('1','0') | YES | | 1 |
| ns_status | enum('0','1','2','3','4') | YES | | 0 |
| init_script | varchar(255) | YES | | NULL |
| monitoring_engine | varchar(20) | YES | | NULL |
| nagios_bin | varchar(255) | YES | | NULL |
| nagiostats_bin | varchar(255) | YES | | NULL |
| nagios_perfdata | varchar(255) | YES | | NULL |
| centreonbroker_cfg_path | varchar(255) | YES | | NULL |
| centreonbroker_module_path | varchar(255) | YES | | NULL |
| centreonconnector_path | varchar(255) | YES | | NULL |
| ssh_port | int(11) | YES | | NULL |
| ssh_private_key | varchar(255) | YES | | NULL |
| init_script_snmptt | varchar(255) | YES | | NULL |
+----------------------------+---------------------------+------+-----+---------+
19 rows in set (0.00 sec)
Вот так выглядит мой первый шаг изучения Ruby. После опробывания парочки других библиотек (например SNMP, threading или SMTP), нужно браться за изучения типов данных. Это основа языка. Если приницип работы библиотек практически 1:1 как и в Python, то к отличиям типов данных стоит отнестись серьезнее. Еще меня интересует стиль языка, а именно функциональная парадигма. Ходят слухи, что на нем легче писать функциональный код, чем на python. В этом мне еще только придется убедиться.
На последок скажу, что открытой документации по Ruby очень много. Все больше и больше документации появляется сейчас и на русском. Удачи в изучении. Счастливо 😉
GNU Screen 4.3.0
Мы рады сообщить о релизе GNU screen 4.3.0
Предыдущий стабильный релиз был более года назад (это была версия 4.2.1). Поэтому я решил наконец-то официально сделать “срез”, т.е. выпустить следующую стабильную версию. У нас нет фиксированного release-цикла, но в будущем мы планирую выпускать новые версии почаще. Скажем, 2 или даже 3 раза в год.
Что касается основых изменений:
- X и x escape последовательности теперь будут показывать команду, которую пользователь передал в качестве параметра, при запуске screen.
- Немного улучшена работа с зомби-окнами, хотя остается еще несколько спорных моментов.
- Команда sort теперь упорядочит окна в алфавитном порядке.
- Окна теперь можно перемещать вручную.
- Команда windows позволяет работать с агрументами screen.
- Много bugfixes (в том числе и не для GNU-систем).
Было добавленно несколько патчей из build-систем конкретных дистрибутивов (так как они теперь в git, из пакетов их естественно можно будет удалить). Во-первых, это сэкономит время/силы/нервы мантейнеров, во-вторых, разница между работой screen (одной и той же версии) в разных дистрибутивах теперь будет меньше.
У нас по-прежнему очень много открытых bugreports. Сейчас их более 200 (проект долгое время находился в состоянии летаргического сна). С моей стороны для следующей версии скорее всего будут только bugfixes этих репортов.
Я благодарен всем пользователям, которые уже помогли протестировать/воспроизвести некоторые баги (по моей просьбе) и просто принимали участие в обсуждениях.
Если меня не опередят, до конца следующей недели я постараюсь пересобрать пакеты для openSUSE и послать запросы (submit request) в соответствующие репозитории (c Tumbleweed у нас их получается уже 3).
Если кто-то захочет отравить patch, я напомню – авторство сохраняется и в самом git-комментарии и в git-заголовке author. Особо активные участники сообщества в качестве бонуса заносятся в man page, в раздел CONTRIBUTORS.
Скачать исходники 4.3.0 можно с ftp-сервера GNU.
SUSE Linux Enterprise 12 source packages
Новость неофициальная, поэтому ссылок на источник я не привожу.
В начале этого года (на FOSDEM) стало изветсно, что SUSE собирается опубликовать исходники пакетов для SUSE Linux Enterprise 12. Сами исходники действительно через пару месяцев были опубликованы. Об этом стало известно во время открытия openSUSE Conference, в начале этого месяца.
Открыты только исходники, а сам процесс сборки, т.е. создание репозиториев, ложится на плечи сообщества. SUSE не отвечает за собранные сообществом пакеты (как и RedHat не отвечает за пакеты в репозиториях CentOS).
Итак, чтобы получить репозиторий с необходимыми пакетами, достаточно в своем домашнем проекте создать subproject, который нужно слинковать с одним из двух опубликованных SUSE: SUSE:SLE-12:GA или SUSE:SLE-12:Update.
Пару дней назад я создал новый SLE12-проект, который слинковал с SUSE:SLE-12:GA. OBS до сих пор пересобирает в нем пакеты (их там почти 3000), но почти 2000 уже готовы. Только что я создал еще один проект для SLE-12:Update (их там почти 1000), так что к началу следующей неделе я, возможно, не только смогу удивить коллег, но и использовать SLE у себя дома как и openSUSE 😉
I’m going to openSUSE Conference 2015
Уже менее чем через 2 недели, у нас, разработчиков openSUSE, снова выпадает возможность встретиться всем вместе. На этот раз конференция пройдет в Голландии, в городе Den Haag. Майские праздники пройдут на берегу Северного моря.
На этот раз моё путешествие начнется практически у самого подножия Альп, в Мюнхене, столице Баварии, откуда на рассвете я отправлюсь в столь любимый и родной Нюрнберг. В Нюрнберге, как вы помните, проходила наша первая конференция в 2009 году. Как и обычно, SUSE организует автобус для своих разработчиков и активных участников проекта. На этом поддержка разработчиков не заканчивается: так называемая Travel Support Program поможет с оплатой отеля. Совсем покрыть расходы за счет фонда не получится, но больше половины всей суммы я получаю из-за своего участия в проекте как майнтейнер.
Что из себя представляет эта конференция и почему стоит ее посетить? Сначала о двух главных изменениях, наметившихся за последние годы. Во-первых, конференция стала немного меньше. К сожаленью. Я помню когда ее посещало приблизительно столько же хакеров сколько и FOSDEM. Тем не менее, качество презентаций и вообще организация конференции на мой взгляд ничуть не уступают. Во-вторых, тематика стала намного шире. Если первая конференция целиком и полностью была посвящена openSUSE, то через 5 лет на ней выступают с докладами сотрудники Oracle и других компаний. Ее посещают разработчики как openSUSE так и других GNU-дистрибутивов.
На несколько дней ты погружаешься в эту атмосферу, когда новые люди рассказывают о новых проектах. Субкультура, и тот факт, что в той или иной степени мы относимся к ней, хотя в повседневной жизни об этом не задумываемся. Этот энтузиазм в глазах, любовь своего дела, желание создавать что-то действительно классное, удобное, нужное… Делиться этим! После возвращения состояние транса будет оставаться еще пару недель. Как правило, те, кто работает только ради денег, редко посещают подобные мероприятия.
Для меня лично посещение openSUSE Conference не похоже ни на одну из других Free Software конференций. На ней я встречаю своих бывших коллег, с которыми закончил свое обучение, с которыми прошел столь непростое и в то же время интересное время Novell/SUSE. Там же в это время я получил свой первый реальный рабочий опыт. Принципами, которые использовались там, я пользуюсь в работе до сих пор и вряд ли буду от них отходить в ближайшее время. Очередная конференция, как и любой подобный event, подразумевает обмен опытом, идеями и это всегда новые знакомства.
На openSUSE Conference можно будет сдавать экзамены LPI. Мой шеф обещает перенять расходы за сдачу экзамена. И хотя на подобных конферециях цена за экзамен не превышает и 100€, все равно приятно чувствовать поддержку. Сейчас я делаю уже второй LPI-сертификат, и его наличие обещает мне не только очередное повышение в зарплате, но это просто интересно.
Ну и наконец, конечно же это здорово хотя бы на недельку сменить обстановку, вырваться заграницу, посмотреть новый город, тем более если он расположен на побережье моря, и погулять по пляжу 😉
Common Lisp, MySQL and openSUSE
С недавних пор позволил себе наглость писать на Common Lisp’е (CL) на работе. Добрался до скриптов, которые до меня были написанны на perl’e, а точнее – понадобилось кое-что в них добавить, и я решил, что переписать их на CL будет и быстрее и полезнее для меня. Скажу сразу, что нет ничего, что можно сделать на CL, но нельзя, к примеру, на perl или python. Другим будет лишь подход к решению, несмотря на то, что, к примеру, на python тоже можно очень не плохо писать в функциональном стиле. Именно из-за этого подхода программисты CL находят его использование столь интересным, гибким и выразительным.
В этом посте я постараюсь показать, что в использование CL нет ничего сверхестественного. Дополнительные библиотеки, скачиваемые из интернета, стандартная библиотека языка… постораемся сделать что-то практическое. читать дальше…
⌨ Labor omnia vincit ☮ 
leave a comment