• Владимира Крюкова - менеджера 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.

• TCP transport which pangdudu coded a year ago. At that time I did not feel familiar enough with the library, and the test suite was much smaller too, so that's why it took me so long.
• Enabled test code coverage report (rcov)
• Classes should not share all interfaces (Ticket#36/Issue#5)
• Ruby 1.9 compatibility (Ticket#37, by Myra Nelson)

Введение

Критерии оценки

Источники информации

Наиболее важные инновации в области ПО: 

Часть 1 (1837-1960) 

Часть 2 (1960-1970) 

Часть 3 (1970-1980) 

Часть 4 (1980-2004)

Патенты на ПО

Какие инновации в ПО не самые главные?

Выводы

Приложение: Инновации в ПО, которые стоит принять во внимание

Things that can eat up way too much time:

• Given a bug id #, going to its URL
• Searching bugzilla

To save time, frustration, and get more done (since it's no longer time-consuming and frustrating), I added a few, special bookmarks. They contain a keyword, which you can type in the URL bar to go to the bookmark, and a %s, which is replaced by whatever you type after the keyword in the URL bar. In Firefox, you can right click a bookmark and edit its Properties to add a keyword.

Here are the ones I use most, and examples of what you can type in the URL/Awesome bar:

• Go to a bug: bgoid
  bgoid 585112
• Search BGO: bgo
  bgo product:banshee os:windows
  bgo product:hyena status:needinfo
  Other search fields you can use
• Search Banshee bugs by summary: bbug
  bbug startup crash
  bbug metadata

Enjoy!

One and a half year is now gone since I posted about my work for ARM support in the OBS and the work for a port of openSUSE to ARM. Lots of things had happened in the meantime that are related, from my limited view most notably Nokia and Intel joining Moblin and Maemo to MeeGo (MeeGo is currently working on a number of Atom and ARM based devices), chosing to use OBS as build system and last but not least myself joining The Linuxfoundation (you will be not surprised to hear that I work at LF on OBS). In the meantime there had also been a major new OBS release 1.8/2.0 with a bunch of new features.

Interesting is the fact that we adapted the cross build system for OBS to MeeGo, first developed for use in Maemo and openSUSE @ ARM. An improved version for the standard MeeGo releases, and for the MeeGo weekly snapshots is used in the MeeGo OBS System to build all ARM releases of MeeGo (the cross toolchain will later get part of the MeeGo SDK @ ARM), thanks to Jan-Simon Möller (In the openSUSE ML, the issue of reactivating openSUSE:Factory ARM builds were brought up. So it might be a good variant to backport Jan-Simons new solution back into openSUSE @ ARM for that purpose). All the MeeGo related OBS installations will move sooner or later to OBS 2.1.

But now to the most recent work, Access Control support. A preview was shipped with OBS 1.8. Now an own OBS version, 2.1, will be dedicated to the introduction of this single new feature into the OBS mainline: Access Control (or abbrevated ACL for Access Control Lists). ACL means that there is control by the user on a per project or per package basis to protect information, source and binaries from the read access of other users in an OBS system and to hide projects or packages.

What is the intended audience of ACL? ACL is intended for installations of OBS that require protection of projects or packages during work. This can be but is not limited to commercial installations of OBS, or semi public installations of OBS.

How does ACL work? ACL sits on top of two features introduced with OBS 2.0: Role and Permission Management as well as freely definable user groups. ACL uses 4 specifically defined permissions (‘source_access’ for read access to sources, ‘private_view’ for viewing package and project information, ‘download_binaries’ for read access to binaries and ‘access’ permission to protect and hide everything and all from read access and viewing) on a user or group in the Role and Permission management. Also, the preexisting roles “maintainer”, “reader” and “downloader” had been modified with specific predifined permissions (which can at any time changed with the role and permission editor dynamically). And last but not least 4 new flags (namely ‘sourceaccess’ to signal a project/package has read protected source code, ‘binarydownload’ to signal it has read protected packages, ‘privacy’ to signal information/logfiles or status cannot be read and ‘access’ to hide and protect a project or package completely in all possible OBS API calls) had been added to the project and package descriptions to signal that some information is only readable by specific users or groups, or that information is hidden.

How do I use ACL? There are 4 steps to use ACL (a part of them a optional and can only be performed by the Administator of an OBS instance). Step one is to assign the listed permissions to a role, user or group (this step can be done only by the admin, and is not needed for the predefined roles “maintainer”, “reader” and “downloader”). Step two is to add a group for special users to projects which are intended to be run with ACL (this operations can only be performed by the admin). Step three is to protect a project with appropriate protection flags at project creation by adding them to the project meta. Step four is to add other users or groups with one of the new predefined roles that has ACL permissions added to the project meta.

What information can be protected by ACL? The protected information is grouped into 4 categories. Category 1 (flag ‘sourceaccess’) is source code. Category 2 (flag ‘binarydownload’) is binary packages or logfiles or builds. Category 3 (flag ‘privacy’) is project or package information like build status. Category 4 (flag ‘access’) is all viewable or accessable information to any project or package (full blocking of all access and information).

Example of a project configuration using ACL:

<user userid="MartinMohring" role="maintainer" />
<!-- grant user full write and read access -->

<group groupid="MeeGo-Reviewer" role="maintainer" />
<!-- grant group full write and read access -->

<group groupid="MeeGo-Developers" role="reader" />
<!-- grant group full source read access -->

<group groupid="MeeGo-BetaTesters" role="downloader" />
<!-- grant group access to packages/images -->

  <sourceaccess>
    <disable/>
  </sourceaccess>
  <!-- disable read access - unless granted explictely.
          This flag will not accept arch or repository arguments. -->

  <binarydownload>
    <disable/>
  </binarydownload>
  <!-- disable access - unless granted explictely -
          to packages/image and logfiles -->

  <access>
    <disable/>
  </access>
  <!-- disable access - unless granted explictely-,
          project will not visible or found via search,
          nor will any source or binary or logfile be accessable.
          This flag will not accept arch or repository arguments. -->

  <privacy>
    <enable/>
  </privacy>
  <!-- project will not visible.
          This flag will not accept arch or repository arguments. -->

What is the current status of the ACL implementation? The current status is that the complete API of the OBS git master had been instrumented with ACL code, critical portions of the API controllers had been code inspected and a big portion of these API calls now have a testcase in the OBS testsuite. Work is ongoing to make ACL as secure as possible. A code drop of current git master is under test in some bigger OBS systems, most notably the openSUSE Buildsystem. You can find snapshots of this codebase as usual in the OBS project openSUSE:Tools:Unstable. Adrian Schröter updates these “Alpha Snapshots” relatively often, on a 1-2 weekly basis, and runs the testsuite on git master daily. Thanks to Jan-Simon Möller for putting in many of the testcases into the testsuite for the ACL checks. On OBS Testing in general, read also Development and Test.

What is next? Code is tested and debugged against granting unwanted access due to some concepts inside OBS that are “working against ACL”, like project or package links, aggregates or kiwi imaging. We will inform you interested user of course about beta releases and an official 2.1 release.

Stay tuned.