This post is part two of my DebConf thoughts series, first post here. At DebConf we also attended three talks directly related to something we use quite often in Maemo and Mer: cross-compilation. The first was by Riku Voipio/suihkulokki about Scratchbox 2 (mirrored by me as I can't find the original URL) - which was also a maemo.org talk like ours, as well as the round-table session on Multiarch and a talk by Wookey on Crossbuilding on Debian for a derived distro.
Scratchbox 2 is the successor of Scratchbox 1 - which most of you know from Maemo SDK. It is different from SB1 in many ways. It operates with the concept of a host tools distribution - tools which are used to accelerate certain parts of a compilation process. Comparing to SB1, with their devkits and such, this approach is much more flexible in terms of maintaining the tools distribution and keeping it up to date with current packages to match your target. This was previously difficult to maintain in SB1 and has been the source of much headache for developers on Maemo to having to deal with old and broken tools which no longer was able to build 'modern' packages.
Multiarch is the term being used to refer to the capability of a system to run applications of multiple different binary targets on the same system. This means that the different architecture files (libraries, binaries, development headers etc) are hosted in the same file system. The proposal also includes ability to have cross-architecture dependancies of packages. This would mean it would be easier in the same system (such as Debian) to build packages for different architectures within one system. It would however often also mean that you would need same package versions in all architectures as the one you're targetting.
This problem leads me to what I intend to discuss: The builder approach of cross-compilation vs a user environment approach for cross-compilation.
A cross-compilation environment has to user-level emulate as much as to make the cross-compilation of the Debian package succeed.
A user environment will have to provide a full environment with interactive shell, editors, etc - and emulate 'being' the target architecture system. This imposes a greater strain on emulation and is more difficult to achieve.
What most Maemo developers encounter, is the Scratchbox SDK. It is a development environment for all your needs and supports different targets both native and foreign architectures. It provides an emulated Maemo environment for developers to test in and should be enough to develop for the Maemo platform.
Marius Vollmer once wrote a post on "The cardinal sin of Scratchbox". It mentions the overreaching redirection that SB2 inherited from SB1 - that almost everything from doctools to python is redirected in the Python environment. This sin extends to the emulated Maemo environment - and that's what harms developers. The emulated Maemo environment is skewed by the redirection of the cross-compilation environment, to the point that Scratchbox Maemo has little to do with how Maemo on device works.
In Mer we began back in the Maemo Reconstructed proposal to ponder how SDK could be different. What we ended up on is that the entire Mer system should be able to run on a given host for development. We currently do this through chroots and virtual machines. This means, when you develop and test your applications - you develop them natively, first for your host architecture and then test it on your host.
The host is a 'real' Mer environment like on every other device and should behave the same no matter device or architecture. Once you're done developing, you can either send the source package to a builder farm (in our case, OpenSUSE Build Service) - which will spit out cleanly built x86, ARM etc. packages for us to put on our devices and test or cross-compile locally with an automated cross-compilation environment. With Mer, it's even possible to build for ARM on your own ARM device - it's just a Debian/Ubuntu laying underneath the surface.
We've had great success with the builder approach of cross-compilation in Mer. Might it be worth considering making - in abstract terms X86 chroot tar.gz's/VMDKs of full Maemo (themes, icons, etc) for developers to use to match the experience without inference by the cross-compilation environment?
One for development - dpkg-buildpackage is possible (coreutils instead of busybox) and one that matches a typical Maemo device. And then when you want to build for a different architecture, abstract it away in a one-liner that takes a source package as input.
Thursday, August 20, 2009
Monday, August 3, 2009
DebConf thoughts
Recently, zenvoid and I recently participated in DebConf9 and presented an one hour BoF session on Mer - made possible by sponsorship by Nokia for our travel and accommodation.
Arriving in Caceres, Spain - after an exhausting and 20 hour journey from Denmark (train, flight, metro, and then train again) and meeting up with my local travel companion zenvoid - we found our hotel, which had free WiFi - with working power saving management, a must for tablet users. :)
At our first day there was a talk on 'HP and Debian' where some abstractions were presented that apply very well to the Mer project. Quote from presentation:
Another part of this presentation is the angle of HP - what it wants and a comparison to what Debian developers want. Many comparisons between maemo.org and Nokia/Maemo Devices can be drawn in this part. HP needs revenue, growth, differentiation and corporate reputation. Differentiation is a word often heard in a negative context when speaking of closed source parts of Maemo. The reason why differentation is needed - is the fact that those 20% closed source parts together with the hardware is what generates the revenue, growth that makes it possible to have the 80% open source (and free) software such as Hildon and other Maemo APIs exist. And have active developers developing on them.
This is the reason why we, in Mer, realize that differentiation is needed to compete in the mobile device market. However, like Android, we provide a full base system - and understand that device developers needs to differentiate on top with extra bits. What we're trying to do in our vendor social contract is to have both a open system and yet allow the users of their devices to remix and alter their devices, even though closed source bits (codecs, firmware, special applications for vendor, added value) exist and are needed for full functionality. It would make the user able to use their devices even to the fullest even after the vendor has long given up on the device in question.
In the second day, we had our presentation - in the BoF room, no projector and a deadly hot room with noisy aircondition- but 20 people approx showed up to hear the talk. The TuxBrain/Freerunner buzzfix people were friendly and recorded the session on video (TBA). What we did was to put Mer on Freerunner, N810, N800, 770, SmartQ5 and simply line them up - and after the talk invite people to come and play with the devices and Mer.
I'm often very critical of my own talks - but all in all it went well, even though I did forget the one key element to any presentation: telling people where they can find out more about your project :). People seemed to poke curiously at our touchscreen devices and ask questions about them. One thing to notice about DebConf was the large amount of Nokia tablets and Neo Freerunner's represented.
After our session the OpenMoko buzzfix party went on, where we showed Mer on Freerunner to different people - and saw how people used their Freerunners. Something that really caught my eye was Qalee , which is a Qt-based environment for the Freerunner. Seems like the guy making it sure has a talent for both code and UI design. See screenshots here
In between the talks, we spent most of our time in the hacklabs, - where we met people like suihkulokki (Riku Voipio) and p2 (Peter de Schrijver) from Maemo Devices - and we even saw a N810 debug board with JTAG and serial ports.
In order to get to talk to people, we put out all our gadgets running Mer on the table, and began hacking - hoping it'd attract. And it did. - we met and talked to a lot of people and we hope that they think of Mer next time they'd like to have an environment for their tablet-like devices - or if they talk to someone who would.
Debhelper in Maemo is fairly old - we saw a talk 'not your grandpa's debhelper' - where it's shown how simple a debian/rules file can look these days with a modern debhelper. What really impressed me was this example:
This is the first out of a small bunch of posts about experiences from DebConf (this is the first), and thoughts on communities creating technology.
Arriving in Caceres, Spain - after an exhausting and 20 hour journey from Denmark (train, flight, metro, and then train again) and meeting up with my local travel companion zenvoid - we found our hotel, which had free WiFi - with working power saving management, a must for tablet users. :)
At our first day there was a talk on 'HP and Debian' where some abstractions were presented that apply very well to the Mer project. Quote from presentation:
A key attribute of Linux and many Free Software applications is that they are developed and supported “by the community”The Mer project likewise consists of a lot of different contributors from different device communities. Some are testers, some are developers, some are artists and some are users. Mer is effectively the result of a long tail of contributions from these people. Our innovation is the mix of this long tail of contribution - and the responsibility of the project is to direct future contributions in the right direction that will encourage new contributors to join in, maintain current contributors, mentor new developers and to encourage users to actually use our software.
What does that mean?Innovation often comes from surprising places, thanks to “the long tail of contribution”
- No one company in charge
- A range of contributors with varied interests, abilities, and motivations
Another part of this presentation is the angle of HP - what it wants and a comparison to what Debian developers want. Many comparisons between maemo.org and Nokia/Maemo Devices can be drawn in this part. HP needs revenue, growth, differentiation and corporate reputation. Differentiation is a word often heard in a negative context when speaking of closed source parts of Maemo. The reason why differentation is needed - is the fact that those 20% closed source parts together with the hardware is what generates the revenue, growth that makes it possible to have the 80% open source (and free) software such as Hildon and other Maemo APIs exist. And have active developers developing on them.
This is the reason why we, in Mer, realize that differentiation is needed to compete in the mobile device market. However, like Android, we provide a full base system - and understand that device developers needs to differentiate on top with extra bits. What we're trying to do in our vendor social contract is to have both a open system and yet allow the users of their devices to remix and alter their devices, even though closed source bits (codecs, firmware, special applications for vendor, added value) exist and are needed for full functionality. It would make the user able to use their devices even to the fullest even after the vendor has long given up on the device in question.
In the second day, we had our presentation - in the BoF room, no projector and a deadly hot room with noisy aircondition- but 20 people approx showed up to hear the talk. The TuxBrain/Freerunner buzzfix people were friendly and recorded the session on video (TBA). What we did was to put Mer on Freerunner, N810, N800, 770, SmartQ5 and simply line them up - and after the talk invite people to come and play with the devices and Mer.
I'm often very critical of my own talks - but all in all it went well, even though I did forget the one key element to any presentation: telling people where they can find out more about your project :). People seemed to poke curiously at our touchscreen devices and ask questions about them. One thing to notice about DebConf was the large amount of Nokia tablets and Neo Freerunner's represented.
After our session the OpenMoko buzzfix party went on, where we showed Mer on Freerunner to different people - and saw how people used their Freerunners. Something that really caught my eye was Qalee , which is a Qt-based environment for the Freerunner. Seems like the guy making it sure has a talent for both code and UI design. See screenshots here
In between the talks, we spent most of our time in the hacklabs, - where we met people like suihkulokki (Riku Voipio) and p2 (Peter de Schrijver) from Maemo Devices - and we even saw a N810 debug board with JTAG and serial ports.
In order to get to talk to people, we put out all our gadgets running Mer on the table, and began hacking - hoping it'd attract. And it did. - we met and talked to a lot of people and we hope that they think of Mer next time they'd like to have an environment for their tablet-like devices - or if they talk to someone who would.
Debhelper in Maemo is fairly old - we saw a talk 'not your grandpa's debhelper' - where it's shown how simple a debian/rules file can look these days with a modern debhelper. What really impressed me was this example:
#!/usr/bin/make -fWhich would autodetect if the package used autotools, setuputils, etc, and then build the package according to this. It obviously supported overriding things as well, and in a fairly simple manner.
%:
dh $@
This is the first out of a small bunch of posts about experiences from DebConf (this is the first), and thoughts on communities creating technology.
Subscribe to:
Posts (Atom)