Anton Chernyshov
posted in
Русский
at
Поскреби Ubuntu, получишь Debian...
Относительно недавно кто-то (не помню кто) из сообщества Debian высказывался, что Ubuntu использует 75% пакетов из Debian без изменений. Вот я и решил поставить один эксперимент, результаты которого приведены ниже.
Итак, берем Ubuntu Alternate CD, вставляем в диск и перезагружаемся. На всякий случай, я все свои эксперименты проводил в виртуалке в Virtualbox. В установщике выбираем режим экспертной установки и ставим только базовую систему. Можно еще в диалоге создания учетных записей разрешить учетную запись root. Меня в Ubuntu больше всего раздражает заблокированная учетка root и неправильно настроенная sudo. После перезагрузки входим в систему и ставим пакет gnome-desktop-environment. Те, кто использует Debian, наверняка знает, что этим метапакетом ставится GNOME.
Затем пускаем службу GDM и получаем вот такую картинку:
После входа в систему наблюдаем вот такой рабочий стол (обратите внимание на расположение кнопок окна):
А чтобы все программы, требующие административных привелегий в GNOME, спрашивали пароль root, а не пользовательский, делаем следующее. Запускаем в терминале gksu-properties и устанавливаем целых две настройки вот так:
Первый раскрывающийся список указывает какую программу запускать при требовании административных привелегий: su или sudo и, соответственно, от этого будет зависеть какой именно из паролей будет запрашиваться. Второй список включает или выключает принудительный захват фокуса окном, требующим привелегий.
Ну а тем, кто хочет восстановить статус-кво, нужно поставить пакет ubuntu-artwork. Получится в итоге вот такое:
Заметьте, что теперь кнопки переехали в левую часть заголовка...
Дальше с этой системой можно делать все, что угодно :) - доустановить нужные пакеты, оформление... Так что мы, практически, получаем почти Debian с более новыми пакетами.
Nagappan Alagappan
posted in
English
at
Hudson X11 Automated GUI Testing
Hudson X11 Automated Testing - To run GUI automated test in Hudson environment. Ara Pulido, demonstrated me, how to setup Hudson and to run some Mago test. The tests were failing, as the ldtp daemon failed to load. When I started poking, I found, the tests can run only in console mode. We need to start a X session, then need to start the test. Even, after this, the tests were failing. Setting DISPLAY doesn't help ! Accessing accessibility service from terminal failed, as AT_SPI_IOR not set from the terminal.
To overcome, this issue, implemented a service and a client, the service runs during the gnome-session startup.
The service (UNIX socket) listens for commands from client, once received execute them in the shell and returns back both stdout and stderr. Just one command per request, not to make things complicated ;-)
During the test, X session will be started with Xvfb, need to evaluate X dummy driver instead. Accessibility, should be enabled and gnome screen saver, should be disabled, before starting the test. Requirement for LDTP tests.
More about this, available here (documented by Ara) and here, also FAQ
Note: Currently tested with GNOME Desktop on Ubuntu Linux using Mago and LDTP from GIT head
Special thanks to Ara Pulido (Ubuntu), Brian Nitz (Sun / Oracle) and Tyller Ballance (Hudson team)
To overcome, this issue, implemented a service and a client, the service runs during the gnome-session startup.
The service (UNIX socket) listens for commands from client, once received execute them in the shell and returns back both stdout and stderr. Just one command per request, not to make things complicated ;-)
During the test, X session will be started with Xvfb, need to evaluate X dummy driver instead. Accessibility, should be enabled and gnome screen saver, should be disabled, before starting the test. Requirement for LDTP tests.
More about this, available here (documented by Ara) and here, also FAQ
Note: Currently tested with GNOME Desktop on Ubuntu Linux using Mago and LDTP from GIT head
Special thanks to Ara Pulido (Ubuntu), Brian Nitz (Sun / Oracle) and Tyller Ballance (Hudson team)
Tejas Guruswamy
posted in
English
at
Member
MasterPatricko
opensync-plugin-kdepim and opensync-plugin-akonadi
Following on from my previous posts [1], [2], here is are the release announcements for the OpenSync plugins I've been working on.
opensync-plugin-kdepim
This is an OpenSync 0.22 plugin to sync with KDEPIM (pre-akonadi, so < 4.5). Using this and the OpenSync framework you can sync your KDE PIM data with mobile devices and other applications. This is ONLY compatible with OpenSync 0.22; not OpenSync 0.3x or above. This code is not guaranteed bug-free; always have a backup of your data. This plugin can sync contacts with KAddressBook, events and todos with KOrganizer, and notes with KNotes (over DBus). If you have akonadi configured this plugin will refuse to sync (you can override this in the config, see the README). IMPORTANT: Note syncing depends on you having a KDE installation where bko#251914 is fixed. This means knotes >= 4.4.7, or use the patch there to recompile.
If you can't get that to work, or if you don't need note syncing, in the patches directory of the source there is a patch that can turn off note syncing and allow it to compile.
opensync-plugin-kdepim on kde-apps.org
libopensync-plugin-kdepim-0.22.tar.bz2 source tarball on the OBS
opensync-plugin-akonadi
This is an OpenSync 0.22 plugin to sync with KDEPIM with akonadi, so > 4.4).
Using this and the OpenSync framework you can sync your KDE PIM data with mobile devices and other applications.
This is ONLY compatible with OpenSync 0.22; not OpenSync 0.3x or above.
This code is not guaranteed bug-free; always have a backup of your data.
This plugin can sync contacts, events, todos, and notes with Akonadi. (There is currently no easy way to view Akonadi notes). Make sure you have at least one akonadi collection of each type before syncing.
opensync-plugin-akonadi on kde-apps.org
libopensync-plugin-akonadi-0.22.tar.bz2 source tarball on the OBS
For both, prerequisites are libopensync-devel and libkdepimlibs4-devel. Compilation is standard
Usage is add plugin to an OpenSync sync group; sync.
Both are available on the OBS in KDE:Unstable:Playground
opensync-plugin-kdepim
This is an OpenSync 0.22 plugin to sync with KDEPIM (pre-akonadi, so < 4.5). Using this and the OpenSync framework you can sync your KDE PIM data with mobile devices and other applications. This is ONLY compatible with OpenSync 0.22; not OpenSync 0.3x or above. This code is not guaranteed bug-free; always have a backup of your data. This plugin can sync contacts with KAddressBook, events and todos with KOrganizer, and notes with KNotes (over DBus). If you have akonadi configured this plugin will refuse to sync (you can override this in the config, see the README). IMPORTANT: Note syncing depends on you having a KDE installation where bko#251914 is fixed. This means knotes >= 4.4.7, or use the patch there to recompile.
If you can't get that to work, or if you don't need note syncing, in the patches directory of the source there is a patch that can turn off note syncing and allow it to compile.
opensync-plugin-kdepim on kde-apps.org
libopensync-plugin-kdepim-0.22.tar.bz2 source tarball on the OBS
opensync-plugin-akonadi
This is an OpenSync 0.22 plugin to sync with KDEPIM with akonadi, so > 4.4).
Using this and the OpenSync framework you can sync your KDE PIM data with mobile devices and other applications.
This is ONLY compatible with OpenSync 0.22; not OpenSync 0.3x or above.
This code is not guaranteed bug-free; always have a backup of your data.
This plugin can sync contacts, events, todos, and notes with Akonadi. (There is currently no easy way to view Akonadi notes). Make sure you have at least one akonadi collection of each type before syncing.
opensync-plugin-akonadi on kde-apps.org
libopensync-plugin-akonadi-0.22.tar.bz2 source tarball on the OBS
For both, prerequisites are libopensync-devel and libkdepimlibs4-devel. Compilation is standard
mkdir build; cd build cmake .. make make install
Usage is add plugin to an OpenSync sync group; sync.
Both are available on the OBS in KDE:Unstable:Playground
Tejas Guruswamy
posted in
English
at
KitchenSync 0.22
As explained in my previous post, something is finally happening with regards to KDEPIM and syncing with mobile devices.
As step 1, I have resurrected KitchenSync - the KDE OpenSync frontend. This application allows for creating, configuring, and syncing OpenSync sync groups among any of the OpenSync plugins (check your distro for opensync-plugin-* or similar).
Basic use should be straightforward - add a sync group, add the members you want to sync between, configure if necessary, sync.
The underlying OpenSync 0.22 framework is showings its age a bit though, and does have some bugs, so if you see a problem in KitchenSync, first make sure that the syncing works with the command-line tool msynctool before reporting a bug in KitchenSync (which, for this version, you can do by directly contacting me here on this blog or via email). Msynctool will also show a bit more debugging output so if something is going wrong, definitely check there first.
I've made binary and source RPMs available for openSUSE 11.1 and newer on the OBS in KDE:Unstable:Playground, which I'll try and keep updated whenever I can.
The source tarball is also available thanks to the OBS. I'll see about getting some publicly accessible source repository soon.
Prerequisites are libopensync-devel, libkde4-devel, and kdepimlibs4-devel or whatever similar name your distro calls them. Compilation instructions are standard KDE SC 4 / cmake stuff.
The release is available on KDE-Apps.org.
In an entirely coincidental event, Quentin Denis has revived the KDE4 + OpenSync 0.40 version of KitchenSync on KDE SVN too. This does not overlap with his work; OpenSync 0.40 is not compatible with OpenSync 0.22. However, I'll be keeping track of his development and backporting any useful fixes (and lending any help I can).
As step 1, I have resurrected KitchenSync - the KDE OpenSync frontend. This application allows for creating, configuring, and syncing OpenSync sync groups among any of the OpenSync plugins (check your distro for opensync-plugin-* or similar).
Basic use should be straightforward - add a sync group, add the members you want to sync between, configure if necessary, sync.
The underlying OpenSync 0.22 framework is showings its age a bit though, and does have some bugs, so if you see a problem in KitchenSync, first make sure that the syncing works with the command-line tool msynctool before reporting a bug in KitchenSync (which, for this version, you can do by directly contacting me here on this blog or via email). Msynctool will also show a bit more debugging output so if something is going wrong, definitely check there first.
I've made binary and source RPMs available for openSUSE 11.1 and newer on the OBS in KDE:Unstable:Playground, which I'll try and keep updated whenever I can.
The source tarball is also available thanks to the OBS. I'll see about getting some publicly accessible source repository soon.
Prerequisites are libopensync-devel, libkde4-devel, and kdepimlibs4-devel or whatever similar name your distro calls them. Compilation instructions are standard KDE SC 4 / cmake stuff.
mkdir build; cd build cmake .. make make install
The release is available on KDE-Apps.org.
In an entirely coincidental event, Quentin Denis has revived the KDE4 + OpenSync 0.40 version of KitchenSync on KDE SVN too. This does not overlap with his work; OpenSync 0.40 is not compatible with OpenSync 0.22. However, I'll be keeping track of his development and backporting any useful fixes (and lending any help I can).
Tejas Guruswamy
posted in
English
at
OpenSync and KDE
Those of you who have used KDE software for a while may remember way, way back when it was announced that KDE would be cooperating with a project called OpenSync to provide PIM data synchronisation to a wide range of devices. The program KitchenSync was brought in as an OpenSync frontend and for a while everything was good - you could sync contacts, events, todos, and notes from KDE 3.5 with your mobile phones and PDAs.
Then the OpenSync project moved away from the stable version 0.22 and started work on a grand new 0.3x branch. They said when they reached 0.40, the project would be stable for end users again. Three years later they are still not ready, with the last release, 0.39, one year ago now. The project still has not been abandoned but things are moving extremely slowly.
Meanwhile KDE moved on as well, to our beloved 4.x series. It was decided to wait for OpenSync 0.40, and then put some effort into porting over the KDE-OpenSync integration - but as KDE release after release went by without OpenSync 0.40 being ready, people got bored of waiting for OpenSync and so KitchenSync was dropped, leaving KDE 4.x users no way of syncing PIM data with mobile devices. Further complicating this is the recent move to akonadi, which adds another layer between your PIM data and where you want it to be - on your mobile device. Compounding this is that all distributions, on the instructions of the OpenSync project, still ship the now-unmaintained and uncared-for OpenSync 0.22 version.
A few technically successful KDE Google SoC projects were undertaken to provide an alternative syncing framework (for example based on SyncML) but they never gained enough polish, or enough device support, to catch anyone's attention.
Now one of my introductions to the F/OSS world was helping a project called SynCE, a framework to talk to Windows Mobile devices from Linux. SynCE had always used OpenSync as the syncing framework and a common question on the SynCE mailing lists was "How can I get my data into KDE?" - and there was no answer. So finally given some free time this summer I decided to do something about it.
In total, I backported the half-finished KitchenSync KDE4 + OpenSync 0.40 port back to OpenSync 0.22 so that it is usable right now. Then I did the same for the KDEPIM plugin - but this only works with KDE SC releases before akonadi was introduced (i.e. < 4.4). Then I wrote a brand-new Akonadi Sync plugin for OpenSync 0.22 - not to be confused with the still-in-development Akonadi / OpenSync 0.40 plugin still available in KDE trunk. I'll do separate release announcements for them all.
Then the OpenSync project moved away from the stable version 0.22 and started work on a grand new 0.3x branch. They said when they reached 0.40, the project would be stable for end users again. Three years later they are still not ready, with the last release, 0.39, one year ago now. The project still has not been abandoned but things are moving extremely slowly.
Meanwhile KDE moved on as well, to our beloved 4.x series. It was decided to wait for OpenSync 0.40, and then put some effort into porting over the KDE-OpenSync integration - but as KDE release after release went by without OpenSync 0.40 being ready, people got bored of waiting for OpenSync and so KitchenSync was dropped, leaving KDE 4.x users no way of syncing PIM data with mobile devices. Further complicating this is the recent move to akonadi, which adds another layer between your PIM data and where you want it to be - on your mobile device. Compounding this is that all distributions, on the instructions of the OpenSync project, still ship the now-unmaintained and uncared-for OpenSync 0.22 version.
A few technically successful KDE Google SoC projects were undertaken to provide an alternative syncing framework (for example based on SyncML) but they never gained enough polish, or enough device support, to catch anyone's attention.
Now one of my introductions to the F/OSS world was helping a project called SynCE, a framework to talk to Windows Mobile devices from Linux. SynCE had always used OpenSync as the syncing framework and a common question on the SynCE mailing lists was "How can I get my data into KDE?" - and there was no answer. So finally given some free time this summer I decided to do something about it.
In total, I backported the half-finished KitchenSync KDE4 + OpenSync 0.40 port back to OpenSync 0.22 so that it is usable right now. Then I did the same for the KDEPIM plugin - but this only works with KDE SC releases before akonadi was introduced (i.e. < 4.4). Then I wrote a brand-new Akonadi Sync plugin for OpenSync 0.22 - not to be confused with the still-in-development Akonadi / OpenSync 0.40 plugin still available in KDE trunk. I'll do separate release announcements for them all.
Tejas Guruswamy
posted in
English
at
Build ATI fglrx RPMs on openSUSE -- part 2
UPDATE 26/09/10: Switch the repositories back to X11:Drivers:Video; thanks to Stefan's work it is updated. Also, a post on the list says that ati-fglrxG01 legacy driver won't work on openSUSE 11.3 even if it builds, due to Xserver incompatibilities :(
UPDATE 24/09/10: I've branched and submitreq'ed the changes back to X11:Drivers:Video. Therefore I've changes the instructions below to checkout my branch instead and avoid the patching.
UPDATE 24/09/10: If you need the ATI legacy driver, for example for Radeon X1400 chipsets, checkout X11:Drivers:Video/ati-fglrxG01 instead. I've patched that to build on openSUSE 11.3 but don't have the hardware to test if it actually works.
In part 1 of this topic, I discussed the current (sad) state of ATI/AMD fglrx video driver RPMs on openSUSE Linux, and suggested that the best, cleanest way to build them was actually via the OBS. Here I cover step-by-step instructions on how to do so.
(Note: I use sudo on my machine, if you don't have it configured, use su)
The first step is to install the OBS command-line frontend, osc.
Then, in a clean working directory (e.g. ~/src):
If you use sudo, make sure to edit the osc configuration file ~/.oscrc to tell it that. Uncomment the line starting with su-wrapper and change the value to suit you.
Now time to build! (Fix distro version/arch as necessary)
Similarly build the X11 drivers.
Incidentally, if you add something useful in these RPMs (spec file, code patch), feel free to submit the changes back to the OBS so everyone can benefit - see OBS Collaboration.
UPDATE 24/09/10: I've branched and submitreq'ed the changes back to X11:Drivers:Video. Therefore I've changes the instructions below to checkout my branch instead and avoid the patching.
UPDATE 24/09/10: If you need the ATI legacy driver, for example for Radeon X1400 chipsets, checkout X11:Drivers:Video/ati-fglrxG01 instead. I've patched that to build on openSUSE 11.3 but don't have the hardware to test if it actually works.
In part 1 of this topic, I discussed the current (sad) state of ATI/AMD fglrx video driver RPMs on openSUSE Linux, and suggested that the best, cleanest way to build them was actually via the OBS. Here I cover step-by-step instructions on how to do so.
(Note: I use sudo on my machine, if you don't have it configured, use su)
The first step is to install the OBS command-line frontend, osc.
sudo zypper in oscThis will also pull in the famous SUSE 'build' script that allows cleanly building rpms.
Then, in a clean working directory (e.g. ~/src):
osc co X11:Drivers:Video ati-fglrxG02Voila! The necessary spec files and patches will be made available in X11:Drivers:Video/ati-fglrxG02.
If you use sudo, make sure to edit the osc configuration file ~/.oscrc to tell it that. Uncomment the line starting with su-wrapper and change the value to suit you.
Now time to build! (Fix distro version/arch as necessary)
mkdir ~/src/packages cd X11\:Drivers\:Video/ati-fglrxG02 sh ./fetch.sh osc build -k ~/src/packages -j 4 openSUSE_11.3 x86_64 ati-fglrxG02.specfetch.sh downloads the ATI driver release you wanted. The osc build will download necessary pacakges, create an entirely separate build system running in a chroot at /var/tmp/build-root - where it cannot affect your main system - and safely build the kernel module rpms, and once built save them in ~/src/packages. You will be asked for the root (or yours, if using sudo) password to create the chroot.
Similarly build the X11 drivers.
osc build -k ~/src/packages -j 4 openSUSE_11.3 x86_64 x11-video-fglrxG02.specNow go to your brand new rpms and install them!
cd ~/src/packages
sudo zypper in -f ati-fglrxG02-kmp-desktop-8.771_*.x86_64.rpm \
x11-video-fglrxG02-8.771-*.x86_64.rpm
This does take a bit of bandwidth (~150 binary packages to download into /var/tmp/osbuild-packagecache), and is slightly slower than compiling the driver yourself, but it's much cleaner and you end up with a better constructed package. The package will automatically change your display driver to fglrx on installing, and when uninstalling will not leave any cruft about your system. This method is also completely applicable to openSUSE 11.2 and previous.Incidentally, if you add something useful in these RPMs (spec file, code patch), feel free to submit the changes back to the OBS so everyone can benefit - see OBS Collaboration.
Tejas Guruswamy
posted in
English
at
Build ATI fglrx RPMs on openSUSE -- part 1
How to install the ATI/AMD fglrx video drivers is one of the first questions many users have when they start up a new distro. The easiest option is an install from the distro's package manager; otherwise you have to manually download and compile from the ATI website.
Although they are evil proprietary binary code, without these drivers, 3d acceleration for games and desktop effects is usually missing or extremely poor performance. In some cases even the 2d performance is quite bad; so most users like to install them as soon as possible.
Traditionally (see SBD:ATI) on openSUSE a YaST/zypper repository has been available at http://www2.ati.com/suse/ (not viewable in a web browser). However in recent releases the ATI driver rpms in this repo have had bugs (originating in the original driver, not in the SUSE packaging); for some time the 64bit version installed files to 32bit locations and so failed to work; with the 11.3 release, the fglrx-10.7 rpms provided simply segfault on boot.
So with openSUSE 11.3 everyone had to fall back to the manual method. Some enterprising openSUSE users have written scripts and workarounds ([1],[2]) that automate at least part of the process; but it still requires installing development tools (kernel-sources, gcc, etc.) on a non-development machine, which I especially dislike.
As it turns out the real source of the ATI rpms (and nVidia rpms BTW, but that's a topic for another day) normally available in the YaST repository is Stefan Dirsch's hard work in the X11:Drivers:Video OBS project. Since the drivers are non-free, the actual source code is not uploaded to the OBS, but it is made available in what as known as a "nosrc" format - including all the build instructions and patches, just missing the source package. Happily, this makes it possible for anyone to build their own video driver RPMs to exactly the same quality that would be available from the repo, and without having to install development packages.
Step by-step instructions are available in part 2 of this post.
Although they are evil proprietary binary code, without these drivers, 3d acceleration for games and desktop effects is usually missing or extremely poor performance. In some cases even the 2d performance is quite bad; so most users like to install them as soon as possible.
Traditionally (see SBD:ATI) on openSUSE a YaST/zypper repository has been available at http://www2.ati.com/suse/ (not viewable in a web browser). However in recent releases the ATI driver rpms in this repo have had bugs (originating in the original driver, not in the SUSE packaging); for some time the 64bit version installed files to 32bit locations and so failed to work; with the 11.3 release, the fglrx-10.7 rpms provided simply segfault on boot.
So with openSUSE 11.3 everyone had to fall back to the manual method. Some enterprising openSUSE users have written scripts and workarounds ([1],[2]) that automate at least part of the process; but it still requires installing development tools (kernel-sources, gcc, etc.) on a non-development machine, which I especially dislike.
As it turns out the real source of the ATI rpms (and nVidia rpms BTW, but that's a topic for another day) normally available in the YaST repository is Stefan Dirsch's hard work in the X11:Drivers:Video OBS project. Since the drivers are non-free, the actual source code is not uploaded to the OBS, but it is made available in what as known as a "nosrc" format - including all the build instructions and patches, just missing the source package. Happily, this makes it possible for anyone to build their own video driver RPMs to exactly the same quality that would be available from the repo, and without having to install development packages.
Step by-step instructions are available in part 2 of this post.
Anton Chernyshov
posted in
Русский
at
Почему нам не нужен третий дистрибутив Linux
Это мой перевод еще одной статьи из блога Novell о том, нужен ли рынку решений дистрибутив Linux от Oracle. Статья мне показалась интересной, хотя бы своим тоном по отношению к недавнему покупателю Sun. Ссылка на оригинал - в конце статьи.
Майкл Аппельбаум, директор по Linux-решениям
Хорошо известно, что Novell и Red Hat по-прежнему задают тон, когда речь идет о Linux для промышленных решений, но Oracle пытается прорекламировать новое решение на Linux, которым она надеется улучшить свое состояние на этом рынке. Изменят ли эти последние новости отношение этого рынка к Oracle? Эксперты с этим не согласны.
Когда дело доходит до корпоративных решений на Linux, Novell и Red Hat по-прежнему доминируют на рынке. В последних результатах, представленных IDC, Novell и Red Hat совместно получают 95% доходов от Linux, причем в прошлом году эта доля была 94%. Oracle же не достигла даже 1% о доходов рынка Linux. Несмотря на заявления Oracle о наличии тысяч клиентов по Linux-направлению, аналитикам еще предстоит увидеть ее хоть сколь-нибудь заметное влияние на рынок. Между тем, доля Novell здесь продолжает расти, увеличившись за последний год на 5 процентов с аналогичным снижением доли Red Hat.
Так почему только эти два дистрибутива Linux из многих существующих сегодня удерживают более 90% коммерческого рынка? Причем, они завоевали множество сегментов рынка и имеют среди своих приверженцев много состоятельных компаний.
Почему же есть только два успешных коммерческих поставщика Linux? Во-первых, для создания и поддержки Linux-дистрибутива корпоративного класса необходимо наличие хорошей инфраструктуры. Не так легко получить право на поддержку сертифицированных приложений, причем тут есть определенный элемент проблемы «курица-яйцо». Только Novell и Red Hat имеют каталог приложений, которые исчисляются тысячами, причем Novell опережает Red Hat по этому показателю в два раза и предлагает более 500 сертифицированных приложений Oracle. Предоставление поддержки корпоративного класса - сложное и дорогое занятие, хоть это и не препятствие для Oracle. И, чтобы сделать такие инструменты как SUSE Studio для развертывания приложений для облачных вычислений, требуются инновационное мышление и ресурсы. Другими словами, для входа на этот рынок есть реальные барьеры, даже если это рынок, которые может кое-кому показаться коммодитизированным (Это термин, который я решил не переводить. Самое нормальное объяснение ему я нашел здесь. Вот цитата оттуда: «Коммодитизация — то, что случается с продуктами, которые становятся достаточно дешёвыми в массовом производстве, и вместо одного уникального товара возникает море из торговых марок. Различий в потребительских качествах между разными брендами не остаётся, так что прежние звёзды теряют при этом свою уникальность. «Компьютер станет также распространён, как микроволновая печь» — это коммодитизация.». - Прим. перев.).
Давайте с вами рассмотрим - имеется ли на рынке потребность в третьем дистрибутиве Linux? Давайте посмотрим на эту ситуацию глазами клиента, купившего поддержку Linux от Oracle:
Будет ли это поставщик решений с бОльшим опытом, чем Novell и Red Hat? Нет.
Будет ли это поставщик, который будет привержен идее Linux-инноваций для всех физических, виртуальных и облачных платформ, которые могут понадобиться клиентам? Нет. В центре интересов Oracle находится только сам Oracle. Если вам потом понадобится купить решение VMware или для мэйнфреймов, что ж надо было думать раньше.
Будет ли это поставщик, заинтересованный в развитии Linux как стратегической платформы и уделяющий особое внимание ее разработке? Опять нет. (Просто попросите кого-нибудь из Oracle объяснить сегменты рынка и указать рекомендуемые области использования Solaris и Oracle Linux, а затем смотрите, как они будут выкручиваться).
В конечном счете, все дело в том, что рынку просто не нужен третий дистрибутив Linux. Наличие двух сильных игроков - Novell и Red Hat - делает рынок достаточно конкурентным, и наши команды по R&D совместно с талантливыми людьми из сообщества ПО с открытым исходным кодом рождают исключительные инновации в таких областях как виртуализация, облачные вычисления, кластеры и HA-решения, управление предприятиями. Хотя, безусловно, в интересах Oracle быть на рынке решений Linux, ведь их доля на рынке отстает.
Конечно, нужно признать историческую роль Oracle в качестве сильного партнера экосистемы Linux, включая Novell, с такими инициативами, как OCFS и тесты баз данных Oracle на разных дистрибутивах Linux, включая SUSE Linux Enterprise Server. Это ключевые элементы, которые делают нынешний Linux таким ярким.
Вопрос: нужен ли клиентам третий дистрибутив Linux? Пока по крайней мере, другого ответа, кроме «нет» найти нельзя.
Anton Chernyshov
posted in
Русский
at
Кто покупает Novell? Делайте ваши ставки!
Мой перевод статьи-размышления от Joe Brockmeier о том, кому может достаться Linux-бизнес Novell
Прошел слух, что Novell достигла предварительного соглашения о продаже, что расколет ее бизнес на две части и продаст ее Linux-отделение "неназванному стратегическому покупателю". Предполагая, что сделка все-таки состоится, кто же этот покупатель, и что это будет означать для SUSE и проекта OpenSUSE ?
Давайте рассмотрим потенциальных покупателей. Novell недавно заключила несколько стратегических соглашений с VMware, и имеет давние партнерские отношения с IBM и SAP. Oracle сейчас также находится в режиме постоянных приобретений, и, вполне возможно, захочет закусить бизнесом SUSE Linux после своей покупки Sun. Но зачем было разрушать нарождающееся сообщество открытого исходного кода (OpenSolaris), когда можно иметь два (OpenSUSE)?
Давайте начнем с Oracle. Oracle имеет свою собственную платформу Oracle VM, имеющую в основе Xen и Red Hat Enterprise Linux(RHEL). Ну хорошо, RHEL с логотипами Oracle. Oracle Unbreakable Linux полностью бинарно совместим с RHEL безо всяких излишних затрат на развитие, которые Red Hat фактически вкладывает свой дистрибутив.
Правда, есть одна маленькая проблема, в грядущем релизе Red Hat просто выкинет Xen в окно, предпочитая ему KVM. Oracle должен будет либо последовать ее примеру и инвестировать в такой переход, или ей придется нарушить совместимость с RHEL после релиза RHEL 6. Если Oracle останется на Xen, ей придется подумать о переходе на другой дистрибутив. Novell по-прежнему до сих пор не вкладывает свои деньги ни в одну платформу, предпочитая стратегию «и нашим и вашим», то есть поддерживая все платформы виртуализации.
Возможно, я излишне оптимистичен, но я считаю маловероятным то, что Oracle собирается поглотить бизнес SUSE. Если это произойдет, я не верю в будущее проекта OpenSUSE. Даже если Oracle все же решит поддерживать его, стиль работы Oracle с сообществом отвратителен. Покупка Oracle сильно затормозит тот прогресс, на который взял курс этот проект, и, кажется, весьма вероятно, что компания увидит «утечку мозгов» подобно той, что произошла после покупки Sun.
IBM - другой претендент. IBM поддерживает партнерские отношения со всеми крупными Linux-компаниями: SUSE, затем Novell, Red Hat и Canonical. Покупка одного из трех и создание своего собственного дистрибутива выглядит не слишком хорошо. Это может даже сделать Red Hat одним из конкурентов IBM, чего никто не хочет. Но IBM и Novell сильно завязаны друг на друге в бизнесе мэйнфреймов, поэтому IBM может решить, что иметь в своем портфеле SUSE будет очень хорошо. Если IBM серьезно относится к форку OpenOffice.org - Symphony, то она также может захотеть заполучить кого-то из разработчиков Novell, участвующих в Go-OO.org. Хотя это, вероятно, подтолкнет HP, Dell и других к Red Hat или другим дистрибутивам. IBM может быть хорошим управленцем для сообщества OpenSUSE; безусловно, гораздо более лучшим, чем Oracle.
Еще один из вариантов - SAP. У нее много стратегических соглашений с Novell/SUSE и много крупных клиентов на SUSE Linux. Но SAP использует также другие продукты Novell, что входит в противоречие со слухом, что компания покупает только Linux-отделение, а все остальное достанется инвестиционным фирмам. Если SAP собиралась бы купить Novell, кажется, более вероятно, что она бы просто купила компанию целиком без лишней суеты.
Все это подводит меня к наиболее вероятному выбору: VMware. VMware в последнее время уже покупала другие решения с открытым исходным (Zimbra, SpringSource), поэтому не будет преувеличением сказать, что эта компания, возможно, захочет добавить SUSE Linux в свой портфель. VMware также может захотеть иметь свой собственный дистрибутив Linux, чтобы помочь своим клиентам и партнерам построить больше готовых решений, которые будут работать на продуктах VMware для виртуализации. И для этого на рынке нет лучшего решения, чем SUSE Studio. Мне кажется, что SUSE Studio - это действительно хорошее дополнение к VMware Appliance Marketplace. Red Hat сейчас только на пути построения своего собственного решения для виртуализации, так что это также помогло бы конкурировать VMware с поставщиком Linux номер один.
Как это отразится на проекте OpenSUSE и SUSE Linux в целом? Думаю, что все будет по крайней мере также, если не лучше, по сравнению с тем периодом, когда у руля стояла Novell. Скорее даже лучше, потому что Novell временами впадает в кризис самоидентификации, когда она пытается разобраться, как все ее бизнес-единицы сочетаются друг с другом. SUSE же идеально впишется в стратегию компании VMware - по крайней мере, на взгляд со стороны.
И в завершение совсем кратко - а что же Microsoft? Вот это точно вряд ли. Мне трудно представить себе, как она собирается действовать, оставаясь в рамках антимонопольного законодательства.
Так кто же скрывается под неизвестным «стратегическим покупателем»?
Я ставлю все, что у меня есть, на VMware, но я вполне могу оказаться неправ. Это могут быть IBM, SAP, или (только не это!) Oracle. Или это кто-то другой, о котором я не подумал. Есть варианты?
Прошел слух, что Novell достигла предварительного соглашения о продаже, что расколет ее бизнес на две части и продаст ее Linux-отделение "неназванному стратегическому покупателю". Предполагая, что сделка все-таки состоится, кто же этот покупатель, и что это будет означать для SUSE и проекта OpenSUSE ?
Краткая отмазка: Novell мой бывший работодатель. Я ушел из компании в конце января, и, насколько я знаю, предложение в 2 млрд. долларов от Elliott Associates тогда еще даже не обсуждалось. Во всяком случае у меня нет какой-либо внутренней информации (позвони же мне, Ян...), так что написанное ниже - всего лишь мои размышления. У меня нет никакой заинтересованности в каком-то определенном покупателе. Я только надеюсь, что мои бывшие коллеги будут работать в компании, которая будет относиться с уважением к ним и проекту OpenSUSE.
Давайте рассмотрим потенциальных покупателей. Novell недавно заключила несколько стратегических соглашений с VMware, и имеет давние партнерские отношения с IBM и SAP. Oracle сейчас также находится в режиме постоянных приобретений, и, вполне возможно, захочет закусить бизнесом SUSE Linux после своей покупки Sun. Но зачем было разрушать нарождающееся сообщество открытого исходного кода (OpenSolaris), когда можно иметь два (OpenSUSE)?
Давайте начнем с Oracle. Oracle имеет свою собственную платформу Oracle VM, имеющую в основе Xen и Red Hat Enterprise Linux(RHEL). Ну хорошо, RHEL с логотипами Oracle. Oracle Unbreakable Linux полностью бинарно совместим с RHEL безо всяких излишних затрат на развитие, которые Red Hat фактически вкладывает свой дистрибутив.
Правда, есть одна маленькая проблема, в грядущем релизе Red Hat просто выкинет Xen в окно, предпочитая ему KVM. Oracle должен будет либо последовать ее примеру и инвестировать в такой переход, или ей придется нарушить совместимость с RHEL после релиза RHEL 6. Если Oracle останется на Xen, ей придется подумать о переходе на другой дистрибутив. Novell по-прежнему до сих пор не вкладывает свои деньги ни в одну платформу, предпочитая стратегию «и нашим и вашим», то есть поддерживая все платформы виртуализации.
Возможно, я излишне оптимистичен, но я считаю маловероятным то, что Oracle собирается поглотить бизнес SUSE. Если это произойдет, я не верю в будущее проекта OpenSUSE. Даже если Oracle все же решит поддерживать его, стиль работы Oracle с сообществом отвратителен. Покупка Oracle сильно затормозит тот прогресс, на который взял курс этот проект, и, кажется, весьма вероятно, что компания увидит «утечку мозгов» подобно той, что произошла после покупки Sun.
IBM - другой претендент. IBM поддерживает партнерские отношения со всеми крупными Linux-компаниями: SUSE, затем Novell, Red Hat и Canonical. Покупка одного из трех и создание своего собственного дистрибутива выглядит не слишком хорошо. Это может даже сделать Red Hat одним из конкурентов IBM, чего никто не хочет. Но IBM и Novell сильно завязаны друг на друге в бизнесе мэйнфреймов, поэтому IBM может решить, что иметь в своем портфеле SUSE будет очень хорошо. Если IBM серьезно относится к форку OpenOffice.org - Symphony, то она также может захотеть заполучить кого-то из разработчиков Novell, участвующих в Go-OO.org. Хотя это, вероятно, подтолкнет HP, Dell и других к Red Hat или другим дистрибутивам. IBM может быть хорошим управленцем для сообщества OpenSUSE; безусловно, гораздо более лучшим, чем Oracle.
Еще один из вариантов - SAP. У нее много стратегических соглашений с Novell/SUSE и много крупных клиентов на SUSE Linux. Но SAP использует также другие продукты Novell, что входит в противоречие со слухом, что компания покупает только Linux-отделение, а все остальное достанется инвестиционным фирмам. Если SAP собиралась бы купить Novell, кажется, более вероятно, что она бы просто купила компанию целиком без лишней суеты.
Все это подводит меня к наиболее вероятному выбору: VMware. VMware в последнее время уже покупала другие решения с открытым исходным (Zimbra, SpringSource), поэтому не будет преувеличением сказать, что эта компания, возможно, захочет добавить SUSE Linux в свой портфель. VMware также может захотеть иметь свой собственный дистрибутив Linux, чтобы помочь своим клиентам и партнерам построить больше готовых решений, которые будут работать на продуктах VMware для виртуализации. И для этого на рынке нет лучшего решения, чем SUSE Studio. Мне кажется, что SUSE Studio - это действительно хорошее дополнение к VMware Appliance Marketplace. Red Hat сейчас только на пути построения своего собственного решения для виртуализации, так что это также помогло бы конкурировать VMware с поставщиком Linux номер один.
Как это отразится на проекте OpenSUSE и SUSE Linux в целом? Думаю, что все будет по крайней мере также, если не лучше, по сравнению с тем периодом, когда у руля стояла Novell. Скорее даже лучше, потому что Novell временами впадает в кризис самоидентификации, когда она пытается разобраться, как все ее бизнес-единицы сочетаются друг с другом. SUSE же идеально впишется в стратегию компании VMware - по крайней мере, на взгляд со стороны.
И в завершение совсем кратко - а что же Microsoft? Вот это точно вряд ли. Мне трудно представить себе, как она собирается действовать, оставаясь в рамках антимонопольного законодательства.
Так кто же скрывается под неизвестным «стратегическим покупателем»?
Я ставлю все, что у меня есть, на VMware, но я вполне могу оказаться неправ. Это могут быть IBM, SAP, или (только не это!) Oracle. Или это кто-то другой, о котором я не подумал. Есть варианты?
Оригинал статьи
От переводчика.
Что не удалось Novell?
Первое: никакой маркетинг. Novell имеет прекрасный набор продуктов для полноценного построения инфраструктуры предприятия любого масштаба - eDirectory, ZenWorks, все сервисы OES. Причем, каждый из этих продуктов пока не имеет конкурентов по полноте охвата всех имеющихся платформ и по своему функционалу.
Второе: слабая работа с сообществом. Пример такой работы следовало бы брать с конкурента номер 1. Novell участвует во многих открытых проектах, но мало кому известны масштабы этого участия.
У Novell реально классные продукты. У нас на курсах многие администраторы с теплом в глазах вспоминали Netware, надежность которой осталась непревзойденной до сих пор. И очень жаль что эта операционная система оказалась вытесненной продуктом гораздо худшего качества.
У Novell реально классные продукты. У нас на курсах многие администраторы с теплом в глазах вспоминали Netware, надежность которой осталась непревзойденной до сих пор. И очень жаль что эта операционная система оказалась вытесненной продуктом гораздо худшего качества.
Anton Cherkasov
posted in
Русский
at
«Веб-лицо» проекта openSUSE. Новая русскоязычная Wiki.
Не секрет, что в наше время визитной карточкой любого проекта или компании является его или её веб-сайт, тем более для проекта из сферы информационных технологий.
Именно поэтому, чтобы соответствовать передовым технологиям, одновременно с выходом новой версии openSUSE обновились и все интернет-порталы проекта. Изменился дизайн, структура, появились модные в эпоху «веб 2.0» округлые элементы, добавились новые сервисы...
Казалось бы, чего ещё желать? А желать есть чего. Дело в том, что эти изменения коснулись преимущественно «стандартных» англоязычных версий порталов, в то время как локализованные версии остались в своем прежнем исполнении и уже не вписываются в единую структуру opensuse.org
За примерами далеко ходить не надо - достаточно сравнить английскую и русскую версии Wiki.
Как видно из скриншотов английская версия выполнена в едином стиле с той же Планетой, например, а русская Wiki выглядит не как часть портала, а как отдельный ресурс.
Но, как гласит известная поговорка: «Будет и на нашей улице праздник!» Совсем недавно специально для локализованных версий Вики был запущен портал languages.opensuse.org
Благодаря активности нашей Wiki-team русскоязычный раздел появился там первым.
Сейчас сайт выглядит вот так:
Видно, что по сути - это создание мультиязычной версии Wiki почти с нуля. Именно поэтому сейчас команде Wiki очень необходима помощь всего сообщества. Объём работ предстоит колоссальный! От своего лица и от лица команды вики призываю всех, кто хочет помочь, и у кого есть свободное время, принять активное участие в наполнении новой Wiki качественным содержимым. Это может быть перевод статей из английской версии, перенос и обновление статей из прежней вики, а также создание новых статей по ещё не освещённым темам.
Из новых сервисов хочу отметить официальную соц-сеть сообщества openSUSE - connect.opensuse.org На текущий момент сервис работает в бета (альфа ?) режиме - пробуются разные движки, меняется набор функций и пр. Но зайти под тестовым аккаунтам иувидеть всё своими глазами можно уже сейчас.
В разговорах на IRC канале я заметил, что не все пользователи знают, какие ресурсы доступны на opensuse.org, поэтому ниже приведу список известных мне сервисов с кратким описанием, если что-то упущу - добавляйте в комментах.
Список ресурсов домена opensuse.org:
Именно поэтому, чтобы соответствовать передовым технологиям, одновременно с выходом новой версии openSUSE обновились и все интернет-порталы проекта. Изменился дизайн, структура, появились модные в эпоху «веб 2.0» округлые элементы, добавились новые сервисы...
Казалось бы, чего ещё желать? А желать есть чего. Дело в том, что эти изменения коснулись преимущественно «стандартных» англоязычных версий порталов, в то время как локализованные версии остались в своем прежнем исполнении и уже не вписываются в единую структуру opensuse.org
За примерами далеко ходить не надо - достаточно сравнить английскую и русскую версии Wiki.
Как видно из скриншотов английская версия выполнена в едином стиле с той же Планетой, например, а русская Wiki выглядит не как часть портала, а как отдельный ресурс.
Но, как гласит известная поговорка: «Будет и на нашей улице праздник!» Совсем недавно специально для локализованных версий Вики был запущен портал languages.opensuse.org
Благодаря активности нашей Wiki-team русскоязычный раздел появился там первым.
Сейчас сайт выглядит вот так:
Видно, что по сути - это создание мультиязычной версии Wiki почти с нуля. Именно поэтому сейчас команде Wiki очень необходима помощь всего сообщества. Объём работ предстоит колоссальный! От своего лица и от лица команды вики призываю всех, кто хочет помочь, и у кого есть свободное время, принять активное участие в наполнении новой Wiki качественным содержимым. Это может быть перевод статей из английской версии, перенос и обновление статей из прежней вики, а также создание новых статей по ещё не освещённым темам.
Из новых сервисов хочу отметить официальную соц-сеть сообщества openSUSE - connect.opensuse.org На текущий момент сервис работает в бета (альфа ?) режиме - пробуются разные движки, меняется набор функций и пр. Но зайти под тестовым аккаунтам иувидеть всё своими глазами можно уже сейчас.
В разговорах на IRC канале я заметил, что не все пользователи знают, какие ресурсы доступны на opensuse.org, поэтому ниже приведу список известных мне сервисов с кратким описанием, если что-то упущу - добавляйте в комментах.
Список ресурсов домена opensuse.org:
- wiki.opensuse.org, оно же en.opensuse.org - новая англоязычная Wiki
- ru.opensuse.org - русскоязычная Wiki
- languages.opensuse.org - новая мультиязычная Wiki
- forums.opensuse.org - форумы openSUSE
- software.opensuse.org - дистрибутивы и пакеты с ПО
- planet.opensuse.org - aггрегатор блогов членов сообщества
- lizards.opensuse.org - аггрегатор блогов openSUSE Members
- hermes.opensuse.org - диспетчер персональных сообщений
- news.opensuse.org - новости из мира openSUSE
- users.opensuse.org - каталог зарегистрированных пользователей
- features.opensuse.org - openFATE, платформа для пожеланий и предложений
- build.opensuse.org - openSUSE Build Service
- connect.opensuse.org - соц-сеть проекта openSUSE
- irc.opensuse.org - IRC-сервер проекта openSUSE