FOSS.in Project Day 2 (Day 2)
Here is a report of FOSS.in Project Day 2 (day 1 report is available here):
Fedora: Freedom is a Feature
Rahul Sundaram spoke on the importance of Freedom (as in free speech). He gave a great example that insisting on Freedom drives innovation and interoperatibility, as in the case where SUN opened up the Java platform (as Simon Phipps wanted it to run on Debian and Fedora as a first class package and insistence by Fedora and Debian on the issue of Freedom worked towards them opening up the platform).
Rahul also indicated that Free software is a developer magnet and good for end users. One good benefit in this regard (given that the dynamics of Free Software is different from proprietary software) are time based releases (Release is more important then features) which allow for quicker development and an iterative development cycle. When considering that Fedora pushes pushes patches and problems upstream, this allows for code quality of packages in Fedora to improve much quickly compared to proprietary software.
At this point, Rahul notes that OLPC runs a modified version of Fedora 
From a user perspective, the Freedom from being able to modify Fedora allows for innovation to fit user requirements. He showed us Vixta, a fork of Fedora, which looks very much like Microsoft Windows Vista, except that looks like Windows. The point here being that the right to freedom allowed for innovation that may end up benefiting the end user.
There was a discusson about the freedom to fork: it keeps Fedora honest, it allows user generated innovation, it provides transparency, it builds diversity in the software ecosystem, and perhaps most importantly, it serves as a preemptive strike against proprietary vendor tactics.
Next up was a discussion on features vs integration. Some cases where Free software facilitates integration include FUNC (Fedora Unified Network Controller), Smolt (Metrics, hardware profiles, hardware compatibility), SElinux, Exec-shield and virtualization all indicate areas where free software is leading innovation.
Impressive localization statistics were presented:
- 2000 translators
- 65 projects
- 70 languages
- 4 million characters
Of course, such localization success could only be possible through Freedom that the distribution provides.
On questions from the audience, Rahul mentioned that Fedora has no certification involved so in the case where scientific applications are not supported, getting involved with the Fedora community will get problems solved relatively quickly. On another question of Anaconda (the Fedora installer) not showing diskspace in Fedora, Rahul simply asked the questioner to file a bug in BugZilla. Heh
Personal thoughts: Good talk, I am a strong believer in Freedom (as in free speech) and the fact that Fedora keeps its ideals strong is a continuing reason for me to use the distribution. Rock on, guys!
OpenOffice.org programmability – at a glance
Juergen Schmidt of Sun Microsystems spoke about having extensions lower the entrance barrier for developers (extensions being encapsulated mini projects). He then started talking about UNO being a component model (better then RMI/DCOM/CORBA). UNO was started in 1997 as no sufficient component technology was available then.
UNO is touted as being language independent with its API being defined in UNOIDL. UNO supports inter-process communication (remotely even) with remote transparency and perhaps most importantly, it is independent from office (look up URE, the UNO runtime environment).
UNO has no or minimal code generation, with only type definitions (for example, interfaces and abstract classes in C++, normal Java interfaces in Java). Implementations are exchangeable, multi-threaded, with Unicode and error handling.
Jeurgen mentioned that the design goal is to have one API for everything internally for better modularization, allow for macros, remote automation, to be able to exchange or modify components and extend functionality by new components (extensions).
Extensions effectively extend office functionality and future work in this area is to allow online updates via HTTPS in OO.o 2.4, digital signatures support, license support (simple EULA’s), and to support extensions repository and online accessbility features.
Some future plans in the area of programatic extensions include extendable help, allowing for semi-automatic updates, automatic notification about updates, provide information about new extensions (from a repository), GUI redesign, bundled extensions, improved NetBeans and more UNO AWT controls.
In the area of UI integration, it is possible via XML configuration (which is clearly context dependent only, for example in Writer or Calc only). Top level menus/toolbars, merging existing menus and/or toolsbars, internationalization support, supporting in OO.o API plugin for NetBeans.
Personal thoughts: While Juergen presented well on the programmatic aspects of OpenOffice.org, I was expecting more code on screen. No matter, later on in the day, there was code to be seen!
Fedora architectures
Tom “spot” Callaway from RedHat spoke about architectures that Fedora supports. He gave the example of Aurora Sparc Linux which takes the RedHat source tree, removes the trademark, compiles the packages and puts it back online.
In Fedora, three architectures are supported (x86, x86_64 and PPC). The PPC userbase is small, so instead of Fedora deciding to dropping the PPC architecture, they decided instead to create and support Secondary Architectures.
Tom defined a primary architecture as an architecture as one that has a majority of users (x86, x86_64, PPC). On primary architectures, build failures are fatal. A secondary architecture, in comparison, have motivated maintainer teams and build hardware (SPARC, alpha, ia64, ARM, s390) and build failures on secondary architectures are not fatal. If packages build correctly, then they are pushed to the repositories. The architectures are second only in number of users, not in quality.
Each secondary architecture is built and maintained by a team of architecture maintainors. Each team will hae a lead, who is ultimately responsible for Fedora on that architecture. Several communities exist (alphacore - Fedora on alpha, Aurora Sparc Linux (Fedora on Sparc), Fedora ia64)and- all officially can make a fedora release.
All packages must be generated from sources and the spec files are kept in the Fedora CVS. Secondary arch maintainers get special access to the Fedora CVS, so they can fix archecture specific bugs (”with great power comes great responsibility”)
iSecondary arch usually take longer to build then primary architectures and as such, milestones may be slightly delayed for secondary architectures. Secondary architectures that repeatedly fail to meet major milestones will be dropped.
Fedora does not currently have the available disk space to carry copies of secondary architecture releases. As such, each secondary architecture will have to provide their own storage and hosting for releases. Secondary architecture torrents can be linked from the main fedora torrent page, though.
Tom went on to show how contributors can start a secondary architecture:
Step 1: Form the architecture team
Step 2: Get hardware for the architecture
Step 3: Bootstrap the architecture
Step 4: Set up a Koji buildserver cluster
Step 5: Create a tracker bug in Fedora bugzilla
Step 6: Create a a mailing list
Step 7: Connect the architecture buildserver cluster to the primary cluster
Step 8: Get cvs access for the architecture team, set milestones
Seems easy enough!
Personal thoughts: Since I use only x86, this talk was an eye opener!
Fedora Spin
Rahul Sundaram spoke on the diversity of distributions. The freedom to fork allows for different tastes for distributions. There is not much to comment on this talk as it was fairly basic and I did not take down too many notes