Who uses Ruby might be interested to try this interesting multiplatform library that allows the development of GUI (Graphic User Interface) with a considerable visual impact and compatible with the three most popular Operating Systems: Linux (via GTK) Windows (with Native controls) and OSX (via Aqua). (This article is also available for italian users)

Usually need install the wxGTK libraries and the gem wxruby (or wxruby-ruby19 if using ruby 1.9) and start creating your own scripts.

$ sudo zypper in wxGTK wxGTK-gl
$ sudo gem install wxruby

But sometimes we could find an Error for a wrong compatibilty between the installed version of the wxGTK libraries and the wrapper library included in the gem.

/usr/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-linux/lib/wxruby2.so:
symbol _ZN13wxAuiNotebook14ShowWindowMenuEv, version WXU_2.8.5 not defined in file libwx_gtk2u_aui-2.8.so.0 with link time reference -
/usr/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-linux/lib/wxruby2.so

When an error like this appear, the unique solution is recompile the gem.

What we need:

• rubygems: Tool for manage the ruby’s gems;
• rake: the Ruby’s version of the popular make, will help us to compile wxRuby;
• wxGTK, wxGTK-gl, wxGTK-devel: Library and headers needed for run our scripts and produce the object’s file;
• SWIG: Build the wrapper classes in Ruby from the C++ sources, wxRuby 2.0.1 need the version 1.3.8;
• gcc-c++: The C++ compiler used for build the wrapper library;
• wxRuby: We have to download the source’s package directly from Rubyforge.

Added the repository which contains the Ruby extensions (warning to the portion of the address that refers the version of openSUSE), we can proceed with the installation confirming the request of the dependent packages:

$ sudo zypper ar http://download.opensuse.org/repositories/devel:/languages:/ruby:/extensions/openSUSE_11.3/ RubyExtensions
$ sudo zypper ref
$ sudo zypper install rubygems rubygem-rake gcc-c++ wxGTK-devel rubygem-ffi-swig-generator make

It’s time to download the sources of SWIG version 1.3.38 from sourceforge, then uncompress and install it:

tar -xvf swig-1.3.38.tar.gz
cd swig-1.3.38
./configure && make
sudo make install

All the packages are ready, we have to set some environment variables before continue:

export SWIG_CMD=/usr/local/bin/swig
export WXRUBY_EXCLUDED=GLCanvas
export WXRUBY_VERSION=2.0.1

The second instruction is important for ignore all the references to the openGL library, which are not availables in unicode version.

The next step is download the wxRuby’s source from Rubyforge and start to compile

tar -xvf wxruby-2.0.1.tar.gz
cd wxruby-2.0.1
rake

After this procedure end you can remove the old gem and build & install the new:

rake gem
sudo gem install wxruby-2.0.1-x86-linux.gem

Personally, I needed recompile wxRuby in openSUSE 11.2; with the new version (11.3) standard packages work fine, anyway i wished share my experience for someone could meet the same trouble in the future :))

Собираем все вместе - systemd

• socket/сокет: данный модуль реализует сокет, расположенный в файловой системе или в Интернете. В настоящее время поддерживаются сокеты AF_INET, AF_INET6, AF_UNIX типов stream, datagram и последовательных пакетов (sequential packet). Также поддерживаются классические буферы FIFO. Каждый модуль типа «сокет» имеет соответствующий ему модуль «сервис», который запускается при попытке установки соединения с сокетом или буфером FIFO. Пример: nscd.socket при установке соединения запускает nscd.service.  
• device/устройство: этот модуль реализует устройство в дереве устройств Linux. Если устройство описано через правила udev, оно будет представлено в systemd как модуль устройство. Набор параметров устройства, установленный udev, будет использоваться systemd как исходный в определении зависимостей для этого типа модулей. 
• mount/точка монтирования: модуль реализует точку монтирования в файловой системе. systemd контролирует все точки монтирования (их подключение и отключение), а также может быть использована для монтирования и размонтирования отдельных файловых систем. Файл /etc/fstab используется как дополнительный источник конфигурации для них, подобно тому, как сценарии инициализации SysV могут быть использованы в качестве дополнительного источника конфигурации для модулей service. 
• automount/точка монтирования с автоматическим подключением: модуль реализует точку монтирования с автоматическим подключением файловой системы. Каждый такой модуль имеет соответствующий ему модуль типа mount, который запускается (т.е. подключается), как только монтируемая файловая система становится доступной. 
• target/указатель: данный тип модулей используется для логической группировки других модулей: на самом деле сам по себе он ничего не делает, он просто указывает на другие модули, которыми таким способом можно управлять вместе. В качестве примера можно привести модули multi-user.target, который играет роль 5-го уровня запуска в классической схеме SysV, и bluetooth.target, активируемый, как только становится доступен Bluetooth-адаптер, и запускающий сервисы, имеющие отношение к Bluetooth (которые обычно не запущены - bluetoothd и obexd) (т. е. по сути это придет на смену традиционным уровням запуска SysV - прим. перев.). 
• snapshot/снимок: подобно предыдущему типу модулей снимки также ничего не делают сами, и их единственное преданзначение заключается в ссылке на другие модули. Снимки могут быть использованы для сохранения состояния и возможности отката назад состояния всех служб и модулей системы инициализации. Он, главным образом, предназначен для двух случаев. Первый, чтобы позволить пользователю временно перевести систему в какое-то специфичное состояние, например, однопользовательский режим с остановкой всех работающих сервисов, а затем легко вернуться в предыдущее состояние с одновременным запуском тех сервисов, которые были перед этим запущены. Второй вариант его использования - поддержка режима suspend: достаточно много сервисов не могут корректно работать с этой системой, и зачастую их лучше остановить перед засыпанием, а потом просто запустить.

Состояние разработки

Предполагаемые направления развития

Вы хотите увидеть systemd в действии?

Написание демонов

Часто задаваемые вопросы

Кто основные разработчики?

Большая часть кодовой базы - моя собственная работа, Lennart Poettering (Red Hat). Однако, общий дизайн и его отдельные детали - это результат моего взаимодействия с Kay Sievers (Novell). Также в проекте участвуют Harald Hoyer (Red Hat), Dhaval Giani (бывший сотрудник IBM), и многие другие из таких компаний как Intel, SUSE and Nokia.

 

Это проект Red Hat?

Нет, это мой персональный проект. И позвольте мне подчеркнуть: мнение, отраженное в данной статье - это только мое мнение. Это ни мнение моего работодателя, ни Рональда МакДональда, ни кого бы то ни было еще.

 

Увидим ли мы это в Fedora?

Если наши эксперименты покажут что наши подходы работают, если сообщество Fedora выскажется в поддержку, тогда да, мы увидим systemd в Fedora.    

 

Увидим ли мы это в OpenSUSE?

Этим занимается Kay, но думаю, что все будет также же, как и в Fedora.

 

Увидим ли мы это в Debian/Gentoo/Mandriva/MeeGo/Ubuntu/[Моем_любимом_дистрибутиве]?

Это вопрос к их разработчикам. Мы можем только приветствовать их интерес и помочь с интеграцией.

 

Почему бы не добавить все вышеперечисленное в Upstart, зачем было изобретать что-то новое? 

Недостатки Upstart приведены выше, так же было показано, что ее основной дизайн, по нашему мнению, ущербен. Этот проект выглядит, как имеющий кучу недостатков в своей основе. Однако, имейте в виду, что это не помешало нам найти много идей для вдохновения в кодовой базе Upstart.

 

Если вам так нравится launchd, почему было бы просто не адаптировать ее?

launchd - прекрасное изобретение, но я не уверен, что она хорошо впишется в Linux, более того, она вообще никак не вяжется по своему дизайну ни с его (Linux) масштабируемостью, ни с его гибкостью.    

Это проект NIH?

(Тонкий укол, намекающий на то, что разработчики пошли по собственному пути только по причине того, чтобы начать свой собственный проект. Проект ради проекта. Прим. перев.)

Я надеюсь, что ясно пояснил текстом выше, почему мы пошли по своему собственному пути, вместо того, чтобы использовать как основу Upstart или launchd. Мы начали разработку по техническим, а не политическим причинам. И не забывайте, что это Upstart, а не systemd, включает библиотеку NIH (которая является, своего рода, новой релизацией glib).    

 

Будет ли systemd работать на [моей_любимой_операционной_системе_отличной_от_ Linux]?

Маловероятно. Выше мы отметили systemd использует много специфичных для Linux API (таких как as epoll, signalfd, libudev, cgroups и т.п.), поэтому портирование его на другую операционную систему выглядит (по нашему мнению), как не стоящий своих затрат. Мы, разработчики проекта, не заинтересованы в работе, предполагающей портирование на другие платформы. Для тех, кто заинтересован в этом, мы можем только сказать, что git хорошо поддерживает концепцию ветвей (branches).

Скажу больше, портируемость ограничивается не только окружением, в котором работает systemd: нам нужны самые последние версии ядра Linux, glibc, libcgroup и libudev.

Если кто-либо хочет сделать нечто подобное для других операционных систем, можем предложить приемлемый режим взаимодействия: мы поможем вам определить какие интерфейсы являются общими с вашей системой, сделаем немножко легче жизнь тех, кто будет писать демоны для systemd и ее аналога. Мы можем помочь идеями, но не кодом.    

 

Я слышал, что [система загрузки Gentoo, initng, Solaris SMF, runit, uxlaunch, что-то еще] - это реально классная система инициализации, которая также позволяет параллелизовать запуск, почему бы не использовать ее как основу?

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

Помощь проекту 

Сообщество 

Каждая Unix-система имеет процесс со своим специальным идентификатором, равным 1. Этот процесс запускается ядром прежде всех остальных и является родительским процессом для всех процессов, которые не имеют собственного родителя. Благодаря этому он может делать много чего такого, что не могут остальные процессы. Например отвечает за такие вещи, как инициализация и поддержка работы пользовательского пространства в процессе загрузки системы.

• Запустить минимум необходимого.
• Попытаться запустить параллельно всё остальное.

Динамическое изменение аппаратного и программного обеспечения

Параллелизация запуска сервисов, зависящих от сокетов (socket service)

Слежение за процессами

• Владимира Крюкова - менеджера Canonical по контактам с OEM-партнерами в регионе EMEA;
• Вашего покорного слуги с информацией о том, какие вообще направления обучения предлагает Canonical;
• И в заключение Torsten Splinder (Canonical Senior System Engineer) поведает всем присутствующим об изменениях в достаточно популярном направлении Ubuntu Enterprise Cloud. Как вы, наверное, догадываетесь, Торстен не говорит по-русски, поэтому задать ему вопросы можно будет только на английском языке :). Ну или на его родном немецком ;).

The openSUSE GNOME team has launched itself full throttle into preparations for openSUSE 11.4, which will be released with GNOME 2.32 as one of the desktops. Along the way, we decided on our focus points for the upcoming release:-

• New packages: More applications for a richer desktop experience
  While there are a large number of excellent GNOME/Gtk-based apps in openSUSE already, this looked like a great time to start getting more apps catering to a variety of requirements into the GNOME:Apps and GNOME:Factory build service projects. Since deciding on this, several new packages have already been worked on and are now available in the corresponding repositories. The status of new applications is tracked here. Many of these applications will, subject to review, reach Factory and a few might even become part of the default openSUSE GNOME desktop.
  You are welcome to request the packaging of applications you have found particularly useful or impressive, and if you are in earnest, why not join us at #opensuse-gnome and start packaging them for yourself? Requests for new applications may be made through comments here, on the mailing-list or at irc, but the best way to do this would be to open a feature request and tag it as “gnome-wishlist-packages”.

• The GNOME Pet Peeves Project: Dealing with minor irritants on the desktop
  I bet there have been times when you have come across a little but pesky irritant or a usability issue that left you feeling “this could have been done so much better…” We decided to track down such issues and try to have them fixed before the next release. Thus the GNOME Pet Peeves Project, where we note and research such issues, their workarounds and solutions. As you can see, we have located a few of these already, and started working on them.
  We invite you to report your pet peeve with GNOME through comments here or otherwise. Of course, the good Samaritan is more than welcome to help with the process of solving such problems as well by providing fixes, pointing to existing upstream patches or even nudging upstream developers at bugzilla or irc, to ensure a more polished GNOME desktop on openSUSE.

• There is much to celebrate about, in GNOME-land come March 2011… and we hope to join the party, as well, with an (unofficial) GNOME3 take on openSUSE 11.4 to be released on the GNOME3 release day!

That and more… indeed there is so much to look forward to, with the launch of 11.4, from the GNOME desktop user’s perspective. With your feedback and other contribution, you can help shape that perspective while also having a lot of fun.

Now that ARM support in the OBS is getting more mature, here a report on the Status of PowerPC and MIPS builds using QEMU. They are implemented similiar to the ARM solution, and use QEMU Usermode (to allow speedup with x86 based cross compilers like we do for ARM).

First of all, PowerPC native builds do work since a long time (3+ years). At the beginning, only XEN virtualization was available for OBS, and XEN did not work on PowerPC hardware. Recently, KVM autosetup was added to OBS with release 1.8. KVM also works on PowerPC machines, so there are now fully functional PowerPC native builds with virtual machine support available.

QEMU Usermode builds for PowerPC are working on 32bit targets. They had been tested on all linux distribution targets using 32bit PowerPC mode (all Debian or Ubuntu PowerPC have working builds). Due to the lack of some functions in QEMU, these builds do not work with QEMU inside a KVM virtual machine (the build results cannot be extracted due to a missing ioctl emulation on PowerPC). Since currently Fedora as well as openSUSE have dropped PowerPC support in their distros, this leaves only 32bit targets on Debian based packaging to be supported. Anyway, should someone need 64bit support, he can use a native machine to work with that.

QEMU Usermode builds for MIPS had also made the first beep inside OBS. They support currently Debian 4.0 mips and mipsel 32bit builds, and Debian 5.0 mips builds (mipsel currently fails on QEMU). It seems there is no RPM based distro available anywhere, so I had no chance to test this case. 64bit MIPS Usermode seems to be broken in QEMU, so it would need fixing. Also, QEMU Usermode hangs for MIPS builds when running in a KVM virtual machine.

A QEMU used for both the above cases is available now for quite a while in the OBS project openSUSE:Tools:MeeGo. The qemu package there is named qemu-deploy. The other small changes in osc, build and obs-server code needed are already in git master and will roll out with OBS 2.1.

In case you would like to help me enhance the support for PowerPC or MIPS and close missing parts (get MIPSEL working, fix KVM builds), feel free to contact me.