Я уже писал на страницах этого блога, что недавно преобрёл роутер D-Link DIR-300/NRU. Мне нужна была недорогая, быстронастраиваемая точка доступа, и хотя я был наслышан о проблемах с устройствами D-Link, привлекательный внешний вид, хороший функционал и цена в 1200 р. сделали своё дело.
Технические характеричтики устройства таковы:
Общие характеристики

• Тип Wi-Fi точка доступа
• Стандарт беспроводной связи 802.11n
• Макс. скорость беспроводного соединения 150 Мбит/с

Прием/передача

• Защита информации WEP, WPA, WPA2
• Мощность передатчика 17 dBM
• Радиус действия внутри помещения 100 м
• Радиус действия вне помещения 400 м

VPN

• Поддержка VPN pass through

Мониторинг и конфигурирование

• Web-интерфейс

Опции точки доступа/моста

• Коммутатор 4xLAN

Маршрутизатор

• Маршрутизатор
• Межсетевой экран (FireWall)
• NAT
• SPI
• DHCP-сервер
• Поддержка Dynamic DNS
• Демилитаризованная зона (DMZ)
• Статическая маршрутизация

Антенна

• Количество внешних антенн 1 x 2 dBi
• Тип внешней антенны съемная

Дополнительно

• Размеры (ШxВxГ) 113x32x148 мм
• Вес 246 г

Вся эта красота выглядит вот так:


Поставляется в небольшой коробке, куда кроме роутера входят: адаптер питания, подставка, настенное крепление, пачкорд, диск быстрой установки (естественно работающий только в Windows), инструкция, гарантийный талон и... текст лицензии GPL v2 (на английском), по которой распространяется программное обеспечение D-Link.
Web интерфейс роутера находится по адресу 192.168.0.1. Оформлен он довольно мило (:)), ориентирован на широкий круг пользователей - опции удобно разбиты по группам, все настройки обернуты в пошаговые мастера установки, но есть и режим для экспертов, где все можно настроить в одном окне.
С настройкой я справился довольно быстро, но в первые три дня выяснилась одна особенность - роутер раз в 10-15 минут разрывал p2p-соединения. Сначала я грешил на программы, ибо DC++ клиент я собственноручно компилил из GIT-репозитория, а Ktorrent стоит из Unstable, но опытным путём (подключением компьютера напрямую, в обход роутера) выяснилось, что виноват всё-таки роутер.
На форумах у людей наблюдался целый ворох проблем, наличие которых зависело от типа соединения и версии прошивки. У меня стояла прошивка версии 2.0.2, а соединения пробовал как через шлюз со статическим IP, так и через PPTP-туннель (провайдер предоставляет оба варианта). На официальном FTP-сервере D-Link я нашел версии прошивок 2.0.1 и 2.0.5beta - с первой проблема осталась, а со второй интернет вообще не поднялся.
Тогда я начал перерывать интернет на предмет наличия сторонних прошивок и набрел на сайт DD-WRT.
По информации с сайта "DD-WRT — это сторонняя разработка прошивки (микропрограммы) под лицензией GPL для множества ieee802.11a/b/g/h/n беспроводных маршрутизаторов, реализованных на чипах Broadcom и Atheros."
Там же я узнал, что мой роутер "основан на чипе Ralink RT3050 SoC, и по всем отчетам, включая «Dlink's FCC test report», его PCBA (печатная плата) точно такая же, как в DIR-600."
Установка сторонней прошивки идентична установке/обновлению оригинальной, с той лишь разницей, что образ берется не с FTP-сервера D-Link, а отсюда.
Установка проходит автоматически, в конце нее роутер перезагрузится и браузер сообщит, что страница недоступна - ничего страшного, просто адрес роутера поменялся на 192.168.1.1
По умолчанию прошивки dd-wrt используют логин admin c пустым паролем, настраивается все тоже быстро, правда тут нет таких мастеров как у D-Link да и язык интерфейса английский, но если уж у Вас хватило умения перепрошить девайс, то и с настройкой Вы легко справитесь.
При переходе по адресу 192.168.1.1 после настройки отображается подобный экран со статистикой устройства:

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

Я уже писал на страницах этого блога, что недавно преобрёл роутер D-Link DIR-300/NRU. Мне нужна была недорогая, быстронастраиваемая точка доступа, и хотя я был наслышан о проблемах с устройствами D-Link, привлекательный внешний вид, хороший функционал и цена в 1200 р. сделали своё дело.
Технические характеричтики устройства таковы:
Общие характеристики

• Тип Wi-Fi точка доступа
• Стандарт беспроводной связи 802.11n
• Макс. скорость беспроводного соединения 150 Мбит/с

Прием/передача

• Защита информации WEP, WPA, WPA2
• Мощность передатчика 17 dBM
• Радиус действия внутри помещения 100 м
• Радиус действия вне помещения 400 м

VPN

• Поддержка VPN pass through

Мониторинг и конфигурирование

• Web-интерфейс

Опции точки доступа/моста

• Коммутатор 4xLAN

Маршрутизатор

• Маршрутизатор
• Межсетевой экран (FireWall)
• NAT
• SPI
• DHCP-сервер
• Поддержка Dynamic DNS
• Демилитаризованная зона (DMZ)
• Статическая маршрутизация

Антенна

• Количество внешних антенн 1 x 2 dBi
• Тип внешней антенны съемная

Дополнительно

• Размеры (ШxВxГ) 113x32x148 мм
• Вес 246 г

Вся эта красота выглядит вот так:


Поставляется в небольшой коробке, куда кроме роутера входят: адаптер питания, подставка, настенное крепление, пачкорд, диск быстрой установки (естественно работающий только в Windows), инструкция, гарантийный талон и... текст лицензии GPL v2 (на английском), по которой распространяется программное обеспечение D-Link.
Web интерфейс роутера находится по адресу 192.168.0.1. Оформлен он довольно мило (:)), ориентирован на широкий круг пользователей - опции удобно разбиты по группам, все настройки обернуты в пошаговые мастера установки, но есть и режим для экспертов, где все можно настроить в одном окне.
С настройкой я справился довольно быстро, но в первые три дня выяснилась одна особенность - роутер раз в 10-15 минут разрывал p2p-соединения. Сначала я грешил на программы, ибо DC++ клиент я собственноручно компилил из GIT-репозитория, а Ktorrent стоит из Unstable, но опытным путём (подключением компьютера напрямую, в обход роутера) выяснилось, что виноват всё-таки роутер.
На форумах у людей наблюдался целый ворох проблем, наличие которых зависело от типа соединения и версии прошивки. У меня стояла прошивка версии 2.0.2, а соединения пробовал как через шлюз со статическим IP, так и через PPTP-туннель (провайдер предоставляет оба варианта). На официальном FTP-сервере D-Link я нашел версии прошивок 2.0.1 и 2.0.5beta - с первой проблема осталась, а со второй интернет вообще не поднялся.
Тогда я начал перерывать интернет на предмет наличия сторонних прошивок и набрел на сайт DD-WRT.
По информации с сайта "DD-WRT — это сторонняя разработка прошивки (микропрограммы) под лицензией GPL для множества ieee802.11a/b/g/h/n беспроводных маршрутизаторов, реализованных на чипах Broadcom и Atheros."
Там же я узнал, что мой роутер "основан на чипе Ralink RT3050 SoC, и по всем отчетам, включая «Dlink's FCC test report», его PCBA (печатная плата) точно такая же, как в DIR-600."
Установка сторонней прошивки идентична установке/обновлению оригинальной, с той лишь разницей, что образ берется не с FTP-сервера D-Link, а отсюда.
Установка проходит автоматически, в конце нее роутер перезагрузится и браузер сообщит, что страница недоступна - ничего страшного, просто адрес роутера поменялся на 192.168.1.1
По умолчанию прошивки dd-wrt используют логин admin c пустым паролем, настраивается все тоже быстро, правда тут нет таких мастеров как у D-Link да и язык интерфейса английский, но если уж у Вас хватило умения перепрошить девайс, то и с настройкой Вы легко справитесь.
При переходе по адресу 192.168.1.1 после настройки отображается подобный экран со статистикой устройства:

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

Я уже писал на страницах этого блога, что недавно преобрёл роутер D-Link DIR-300/NRU. Мне нужна была недорогая, быстронастраиваемая точка доступа, и хотя я был наслышан о проблемах с устройствами D-Link, привлекательный внешний вид, хороший функционал и цена в 1200 р. сделали своё дело.
Технические характеричтики устройства таковы:
Общие характеристики

• Тип Wi-Fi точка доступа
• Стандарт беспроводной связи 802.11n
• Макс. скорость беспроводного соединения 150 Мбит/с

Прием/передача

• Защита информации WEP, WPA, WPA2
• Мощность передатчика 17 dBM
• Радиус действия внутри помещения 100 м
• Радиус действия вне помещения 400 м

VPN

• Поддержка VPN pass through

Мониторинг и конфигурирование

• Web-интерфейс

Опции точки доступа/моста

• Коммутатор 4xLAN

Маршрутизатор

• Маршрутизатор
• Межсетевой экран (FireWall)
• NAT
• SPI
• DHCP-сервер
• Поддержка Dynamic DNS
• Демилитаризованная зона (DMZ)
• Статическая маршрутизация

Антенна

• Количество внешних антенн 1 x 2 dBi
• Тип внешней антенны съемная

Дополнительно

• Размеры (ШxВxГ) 113x32x148 мм
• Вес 246 г

Вся эта красота выглядит вот так:


Поставляется в небольшой коробке, куда кроме роутера входят: адаптер питания, подставка, настенное крепление, пачкорд, диск быстрой установки (естественно работающий только в Windows), инструкция, гарантийный талон и... текст лицензии GPL v2 (на английском), по которой распространяется программное обеспечение D-Link.
Web интерфейс роутера находится по адресу 192.168.0.1. Оформлен он довольно мило (:)), ориентирован на широкий круг пользователей - опции удобно разбиты по группам, все настройки обернуты в пошаговые мастера установки, но есть и режим для экспертов, где все можно настроить в одном окне.
С настройкой я справился довольно быстро, но в первые три дня выяснилась одна особенность - роутер раз в 10-15 минут разрывал p2p-соединения. Сначала я грешил на программы, ибо DC++ клиент я собственноручно компилил из GIT-репозитория, а Ktorrent стоит из Unstable, но опытным путём (подключением компьютера напрямую, в обход роутера) выяснилось, что виноват всё-таки роутер.
На форумах у людей наблюдался целый ворох проблем, наличие которых зависело от типа соединения и версии прошивки. У меня стояла прошивка версии 2.0.2, а соединения пробовал как через шлюз со статическим IP, так и через PPTP-туннель (провайдер предоставляет оба варианта). На официальном FTP-сервере D-Link я нашел версии прошивок 2.0.1 и 2.0.5beta - с первой проблема осталась, а со второй интернет вообще не поднялся.
Тогда я начал перерывать интернет на предмет наличия сторонних прошивок и набрел на сайт DD-WRT.
По информации с сайта "DD-WRT — это сторонняя разработка прошивки (микропрограммы) под лицензией GPL для множества ieee802.11a/b/g/h/n беспроводных маршрутизаторов, реализованных на чипах Broadcom и Atheros."
Там же я узнал, что мой роутер "основан на чипе Ralink RT3050 SoC, и по всем отчетам, включая «Dlink's FCC test report», его PCBA (печатная плата) точно такая же, как в DIR-600."
Установка сторонней прошивки идентична установке/обновлению оригинальной, с той лишь разницей, что образ берется не с FTP-сервера D-Link, а отсюда.
Установка проходит автоматически, в конце нее роутер перезагрузится и браузер сообщит, что страница недоступна - ничего страшного, просто адрес роутера поменялся на 192.168.1.1
По умолчанию прошивки dd-wrt используют логин admin c пустым паролем, настраивается все тоже быстро, правда тут нет таких мастеров как у D-Link да и язык интерфейса английский, но если уж у Вас хватило умения перепрошить девайс, то и с настройкой Вы легко справитесь.
При переходе по адресу 192.168.1.1 после настройки отображается подобный экран со статистикой устройства:

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

Adding files to a SVN server is usually a task done in seconds. However, having several independent SVN repositories and wanting to “combine” them, this is not trivial—especially if you want to preserve the history.

The doc team had had three different, independent repositories on BerliOS (opensuse-ha-doc, opensuse-docmaker, and opensuse-lfl) all holding separate information. This was a bit silly, so my task was to consolidate them into opensuse-doc by keeping all history.

A SVN history is nice as you can see what you or others have done with the files. Loosing the history is the same as starting from scratch — which can be sometimes a good idea. In that case, the doc team wanted to preserve the history as we use it very often. So I had to think of a solution how to merge different SVN repositories into one. I came up with a solution containing the following steps:

1. Create a test repository
2. Create the dump files
3. Filter the dump files and extract trunk only
4. Rename trunk content
5. Edit the dump files
6. Load dump files into test repository

Several tools are needed: svnadmin and svndumpfilter are already available from the subversion package. Additionally, Darix recommended the svndumptool from devel:tools:scm:svn (thanks Darix!). A very convenient tool when dealing with SVN dumps.

Apart from this, all three SVN repositories consist of the usual trunk, branches, and a tags directories.

Step 1: Creating Test Repository

Before I got my hands dirty, I needed a test repository. Luckily, the subversion package contains everything what I need.  In my case, I’ve used the hotcopy command to create this test repository. I’ve logged in to BerliOS and made a hotcopy of my target SVN repository:

# ssh svn.berlios.de
# svnadmin hotcopy /svnroot/repos/opensuse-doc opensuse-doc

I did the same for my other repositories as well, just for safety reasons:

# svnadmin hotcopy /svnroot/repos/opensuse-lfl opensuse-lfl
# svnadmin hotcopy /svnroot/repos/opensuse-docmaker opensuse-docmaker
# svnadmin hotcopy /svnroot/repos/opensuse-ha-doc opensuse-ha-doc

Later, I will use the opensuse-doc hotcopy to test my modifications before I apply them to the production SVN repository. With this method, I wanted to make sure everything is correct. Of course, you have to be sure that nobody commits to your repositories, otherwise any later commits won’t be incorporated.

Step 2: Creating Dump Files

Dump files contain everything what’s inside a repository including SVN properties. However, they don’t contain the configuration or repository hooks from the repository. If you want to keep them, you’ll have to save them manually.

It’s very easy to create a dump file. In BerliOS, everything lives under /svnroot/repos/PROJECT:

# svnadmin dump /svnroot/repos/opensuse-lfl > opensuse-lfl.dump
# svnadmin dump /svnroot/repos/opensuse-docmaker > opensuse-docmaker.dump
# svnadmin dump /svnroot/repos/opensuse-ha-doc > opensuse-ha-doc.dump

The above lines create a dump file for each of my SVN repositories. As the BerliOS server doesn’t have the svndumptool command, I have to copy them to my own machine:

toms@earth:~ > scp shell.berlios.de:~/opensuse-*.dump .

Step 3: Extracting trunk

In most SVN repositories, tags and branches contain information which were at some point in time copied (for tags) or copied and modified later (for branches). I haven’t found a satisfying solution to use svndumptool and take into account these two directories. Anyway, I’ve decided to just concentrate on trunk and manually adjust tags and branches later. This makes it easier when dealing with dump files.

To extract only parts of a dump file, the svndumpfilter command is the right tool. Combined with the needed options and subcommands, I’ve used:

toms@earth:~ > svndumpfilter --renumber-revs --drop-empty-revs \
    include trunk < opensuse-docmaker.dump > docmaker-trunk.dump
toms@earth:~ > cat dumps/opensuse-ha-doc.dump | \
    svndumpfilter --renumber-revs --drop-empty-revs  include "trunk" | \
    svndumpfilter exclude trunk/package > ha-doc-trunk.dump
toms@earth:~ > svndumpfilter --renumber-revs --drop-empty-revs \
    include trunk < opensuse-lfl.dump > lfl-trunk.dump

The commands are not exactly the same, as the SVN repositories are slightly different. For example, the opensuse-ha-doc repo contained a trunk/package directory which I don’t want. Therefor you see the exclude command in svndumpfilter. The resulting dump files contain only trunk, nothing else.

Step 4: Renaming trunk Directory

The last step created dump files which contain only the trunk directory. The dump files can already be loaded into the target SVN repository. However, this is only partly successful. After loading you have to rename and move subdirectories around which is unconvenient. To avoid this cumbersome task, I’ve used the svndumptool command which does the job directly on the dump file!

For example, the former docmaker repository has to appear under trunk/tools/docmaker, not directly under trunk. This can be done with the merge subcommand of svndumptool:

toms@earth:~ > svndumptool merge -o docmaker-trunk-rename.dump \
   -i docmaker-trunk.dump \
   -s '^trunk' 'trunk/tools/docmaker' \
   -d trunk/tools/docmaker

The -d option creates the trunk/tools/docmaker directory in case it doesn’t exist in your target. The -i and -o options are the input and output stream of the dump files, -s contains a regular expression how to rename the source (^trunk) into the target (trunk/tools/docmaker). The other repositories are similar:

toms@earth:~ > svndumptool merge -o ha-doc-trunk-rename.dump  \
  -i ha-doc-trunk.dump \
  -d trunk/documents/ha/ \
  -s '^trunk/books/en' 'trunk/documents/ha/en' \
  -s '^trunk/books' 'trunk/documents'
toms@earth:~ > svndumptool merge -o lfl-trunk-rename.dump  \
  -i lfl-trunk.dump \
  -d trunk/documents/lfl/ \
  -s '^trunk/books/en' 'trunk/documents/lfl/en' \
  -s '^trunk/books' 'trunk/documents'

After this step I have three files, named *-trunk-rename.dump which contains the renamed directories.

Step 5: Editing Dump File

This step is a bit tricky and I haven’t found a better solution yet. Probably this can also be done with cat and sed magic, but I preferred vi. The task is to list the content of the dump files and decide which directory entries need to be deleted. This step is absolutely necessary to avoid any SVN error (something like “directory/file already exists”) when trying to load the dump file into the repository.

1. Get an overview of the contents:

   toms@earth:~ > svndumptool ls ha-doc-trunk-rename.dump
   /trunk
   ...
   toms@earth:~ > svndumptool ls docmaker-trunk-rename.dump
   /trunk
   /trunk/documents

   Usually this is /trunk and probably some other directories (depending on the structure).

2. Modify the dump file(s) and remove any directories which are available in the target SVN repository.
   The renamed directories from the last step contains a single trunk “node” which has to be removed. The same applies for trunk/documents. Both exist already on the BerliOS server. Manually edit the dump files and remove the following lines:

   Node-path: trunk
   Node-action: add
   Node-kind: dir
   Prop-content-length: 10
   Content-length: 10
   PROPS-END
   ...
   Node-path: trunk/documents
   Node-action: add
   Node-kind: dir
   Prop-content-length: 10
   Content-length: 10
     [[ Some other content could be available here ]]
   PROPS-END

3. Save the dump file

Be careful! It is very important not to destroy any structure in the dump file!

I’ve checked the result with “svndumptool ls DUMPFILE”. No lonely trunk directory should be shown anymore. To be on the safe side, I’ve checked the two files with svndumptool check -A DUMPFILE, too.

Step 6: Loading Dump Files into Test Repository

The last step created the dump files with the correct structure. As this was done on my own machine, I have to copy the files back to BerliOS (remember to use the shell.berlios.de server):

toms@earth:~ > scp *-rename.dump  shell.berlios.de:

It’s almost done! Logged into BerliOS and loaded the dump files in my hotcopy test repository (see step 1):

# svnadmin load opensuse-doc  < docmaker-trunk-rename.dump
# svnadmin load opensuse-doc  < ha-doc-trunk-rename.dump
# svnadmin load opensuse-doc  < lfl-trunk-rename.dump

After playing around a bit, everything was successful. So I repeated it, but replaced the opensuse-doc hotcopy with the correct path /svnroot/repos/opensuse-doc.

The remaining pieces are the tags and branches directory. As revision numbers have been changed, the revision number in the original repository and the revision number in opensuse-doc are obviously not the same anymore. Creating tags can only be done with a correct date, because dates are preserved. For this reason, it is convenient to still have the original repositories around to look for the exact date and log message:

$ svn copy -r "{2010-10-20T10:00:00}" -m "..." \
   $BERLIOSURL/trunk/tools/docmaker \
   $BERLIOSURL/tags/tools/docmaker/obs

The branches are a bit different. Maybe the history can be preserved with the same method as with trunk, but I haven’t tried it. Our three repositories hadn’t had meaningful information in branch, or it wasn’t worth the effort.

Conclusion

The steps above showed how to merge different SVN repository into one while keeping the history.  Unfortunately, this task could be easier. Although svndumpfilter is very easy, it is also very limited. Especially when you have to modify the dump file itself, svndumpfilter won’t rescue you. It would be very good, if svndumpfilter could be extended to work with dump files in the same way as svndumptool. That would be fun.

De volta ao trabalho, vamos para a terceira parte do nosso artigo. Conforme havia anunciado, vamos falar agora da instalação de alguns pacotes bem comuns, como plugins do java e do flash, codecs de vídeos, Google Chrome e Adobe Reader. Todos esses pacotes estão disponíveis através dos repositórios listados no artigo anterior.

Os codecs de vídeos estão disponíveis através dos pacotes gstreamer disponíveis na distro. O mesmo ocorre com o flash que possui o pacote (flash-player). Existem duas versões de java disponíveis: A versão da sun (java-1_6_0-sun e java-1_6_0-sun-plugin) e a versão do openjdk (java-1_6_0-openjdk e java-1_6_0-openjdk-plugin). Escolha a sua favorita e instale-a. Instale o pacote chromium para navegar pelo Google Chrome e acroreader para usar o Adobe Reader 9.

Nessa questão não vejo muita diferença entre o OpenSuse e as distros Ubuntu e Fedora. Todas disponibilizam esses programas através de seus próprios repositórios ou de repositórios desenvolvidos pela comunidade, enfim, a única preocupação é encontrar o repositório que possui o pacote desejado, que como vimos no capítulo anterior, é uma vantagem do OpenSuse.

Em breve, mais novidades nessa trajetória.

One of the features we want to include in the next MonoDevelop release is integrated support of Git. I committed a first version of a git add-in some months ago which works by invoking the git command and parsing the results. This solution satisfied some basic needs (Mono was moving to git at that time), but it was done as a short term solution, since parsing git output is not very reliable, and has portability issues.

We have a new place where we collect static documentation like manuals, user guides, quick start pages, developer documentation … and so on.
This new place is: rtfm.opensuse.org doc.opensuse.org.
Our “fabulous manuals” are also accessible at: doc.opensuse.org (in case you don’t like the word “fabulous”).

A few days ago Thomas Schraitle already wrote about this site before it was in a state that we wanted to announce – so sorry for any confusion this might have created.

This site is not meant to be a competitor to the documentation in the wiki. It was rather born from the need to have a central place to publish generated static documentation. Content on rtfm is not meant to be edited. If you want to contribute documentation we very welcome this in the wiki and encourage  you to link back to rtfm where applicable. The pages on rtfm are static but however they will be updated automatically upon changes (new releases of a project or product).

Currently we have published some great user guides and quick start pages for openSUSE (KDE, Gnome, Security, …) and SLES (AppArmor, Admin Guide, kvm, Xen, Security, …) as well as a user and vendor guide for WebYaST. There is also developer documentation available for YaST and Zypp (libzypp, satsolver) development.
In the next days or weeks we will add more documentation as soon as it is ready to be published.

Update:
We changed the domain name of that site. To read the fabulous manuals please use and link only to doc.opensuse.org. The domain docs.opensuse.org will be alias for it – please only link to doc and do not use rtfm anymore. Thanks for your appreciation.

Been doing some work and playing around with opensuse's great build service and as a result, my packages has been accepted by the opensuse team. So, now pensuse has python-flask and a few related packages in there.

Use the devel:languages:python and enjoy.

Alternatively use the search http://software.opensuse.org/113/en to find what you need.

Continuando o artigo, seguem alguns mais tópicos

2.1 Yast
Quem já usou o Suse/OpenSuse em algum momento já deve conhecer o Yast, para quem não conhece, ele é uma ferramenta de configuração do sistema, como o Painel de Controle do Windows, sendo ponto único para as ferramentas de configuração de Hardware, instalação de Software, Administração de Serviços e Contas de Usuários etc. Acho esse modelo melhor do que diversas ferramentas soltas, como o system-config-etc do Fedora/RedHat. Suas ferramentas são módulos que podem ser removidos/adicionados/substituidos sem alterar o ponto central de configuração.

2.1 Repositórios
Configuração de Repositórios extras no OpenSuse é muito legal. Ele já traz um serviço de busca por repositórios da comunidade de forma que pelo próprio Yast2 é possível adicionar/remover repositórios. Não é necessário uma única intervenção por linha de comando. Para usuários menos experientes, isso é ótimo.

Segue a lista dos repositórios que adicionei em minha instalação:

name=Repositório principal (NON-OSS)
baseurl=http://download.opensuse.org/distribution/11.3/repo/non-oss/
name=Repositório principal (OSS)
baseurl=http://download.opensuse.org/distribution/11.3/repo/oss/
name=Repositório principal (Contrib)
baseurl=http://download.opensuse.org/repositories/openSUSE:/11.3:/Contrib/standard/
name=Repositório principal de atualização
baseurl=http://download.opensuse.org/update/11.3/
name=Packman Repository
baseurl=http://ftp.uni-erlangen.de/pub/mirrors/packman/suse/11.3/

Instalação de Programas
O módulo do Yast para Gerenciamento de Software é muito semelhante ao Package-Manager do Fedora, sendo que para que já usa não terá nenhum problema para operar essa ferramenta. Uma pequena diferença fica por conta do solver, um script responsável por resolver os problemas de conflitos de dependências de pacotes. Ele permite maior administração por parte do Administrador do Sistema que pode inclusive ignorar os problemas detectados e manter o ambiente inconsistente. Não acho que isso seja bom para usuários menos experientes. Para usuários mais avançados, existem outras formas de fazer isso. Na minha avaliação, ponto para o Fedora nesse aspecto.

CompizFusion / Sax2

Infelizmente nessa versão, 11.3, o Sax2 ficou de fora. Sax2 é uma ferramenta de configuração de vídeo, e eu achava o diferencial do OpenSuse. Sempre senti falta de uma ferramenta a altura nas outras distros. De qualquer forma, não tive nenhum problema com configuração de vídeo em meu desktop. O hardware foi detectado e não precisei configurar nada, da mesma forma foi com Fedora e Ubuntu. Quanto ao CompizFusion, o OpenSuse já vem com um módulo de configuração dos Efeitos da Área de Trabalho com alguns recursos a mais que Fedora e Ubuntu. Ainda assim é menos completo do que o compizconfig-settings. De qualquer forma, gostei dessa ferramenta, que já vem integrada ao sistema, não é necessário instalar pacotes adicionais para configurar alguns efeitos extras. Ponto para o OpenSuse.

Ao final desse artigo, avalio o OpenSuse, até aqui como um Desktop muito bom, com algumas vantagens em relação ao Ubuntu e ao Fedora, e algumas outras, de forma que deixo os 3 num mesmo nível. No próximo artigo falarei sobre a instalação de plugins e codecs (Java, Flash e Vídeos) Google Chromium e Adobe Reader.

Já algum tempo recebi venho analisando os avanços do OpenSUsE, mas agora resolvi instalar e usar essa grande distro, e começarei a relatar numa série de artigos minha experiência na migração do Fedora para ela.

Incialmente devo dizer que odeio esse modelo de atualização adotado pela distro em que ele baixa e instala cada pacote. Na maioria das outras distros, primeiro baixa-se todos os pacotes para depois instalá-los. Os riscos de gerar uma incosistência no sistema são bem menores dessa forma. Porém há uma maneira simples de solucionar esse problema:

Como root, edite o arquivo /etc/zypp/zypp.conf

Pesquise pela linha com o valor "commit.downloadMode"
Remova o comentário e altere seu valor para "DownloadInAdvance" , sendo que a linha deve ficar assim:

commit.downloadMode = DownloadInAdvance


Dessa forma, durante a atualização ou instalação de pacotes, primeiro é feito o download de todos os arquivos para depois iniciar a instalação dos mesmos.

Por hoje, fico por aqui, em breve mais relatos.