Fedora 18 on ARM retrospective
It’s been a while since I’ve done a general update on Fedora 18 on ARM. Post release always tends to be a good have a look at what’s been achieved, where we are and what we have planned for the next release. At the beginning of last year I was trying to blog weekly on my Fedora involvement, or at least tech involvement that’s related to Linux, I need to get back into that habit, if for no other reason than to stop people bothering me 
. As a result this is a bit of a mammoth post at around 1500 words!
Overall Fedora 18 was a reasonably standard release process for ARM. We had the usual package build issues with lots people scrambling to help us get things fixed even if some took longer than hoped, kernel issues also featured but that’s not unusual as there’s been a lot of upstream ARM churn! The extended release process wasn’t as bad for ARM as it was for some of the other teams as it allowed us to fix up some more bits and get them landed in the release. So what were the major achievements of this cycle?
- Supported Devices: The number of devices we support has actually gone down due to the Efika devices not being updated to run on the newer kernels and then being completely dropped for the 3.7 cycle due to lack of DeviceTree support. That being said the number of devices that work with only little intervention is on the way up and this should increase dramatically over the Fedora 18 life cycle due to the unified kernel. People are also starting to play with remixes for devices and I have some ideas to support this better (see kernel section).
- Packaging: The number of packages that didn’t build out of the total of 12,614 packages in the final F-18 GOLD release was a rather small 280 at mainline release. This has actually gone down since as we’ve had a couple of packages that were blocking a lot more land in the post F-18 updates flurry and more are on the cusp of landing too. I’m working through the remaining packages to document the remaining hold outs and classify them as 1) non ARM arch 2) simple fixes required 3) complex fixes required 4) language bootstrap required 5) unknown or 6) dependent on another package from 1-5.
We’re also working on improving and optimising packages for ARM. Over this release cycle I’ve pushed a number of fixes to improve performance and operation of packages. I expect this to continue for a number of cycles to come as well as enabling more HW device support like UCM support for sound devices in F-19.
- Kernels: I’ve spent an inordinate amount of time this release doing kernel work. I would never consider myself a kernel hacker but clearly I’m able to fool people as I was asked by a kernel developer if my employment by Red Hat was to become the ARM kernel maintainer, while chuffed at the complement I’m really not a kernel hacker!
So what have we achieved in the kernel this cycle? Well we’ve landed the first iteration of the 3.7 “unified” ARM kernel which allows us to boot a single kernel on multiple devices. We have two devices currently supported in 3.7 with the qemu based Versatile Express emulation and Calxeda Highbank being the first candidates that have been tested to work, we have the Marvell mvebu support enabled in 3.7 too but there’s not enough driver support for it to work on real devices. The 3.8 kernel expands this out by adding IMX (yet to be enabled), SunXI (also known as AllWinner A1x) and some other devices. The A1x support is similar to the mvebu in 3.7 in that it’s just core SoC support so not really useful as yet. The unified kernel has allowed us to collapse a number of our kernels into one which has reduced our build times dramatically (one of the bullet points needed for primary arch) but it’s not all completely rosy. The unified kernel is still problematic and I don’t believe this is helped by its current lack of use. This is especially disappointing when Linaro don’t even build unified kernels for testing. It appears Fedora is leading here and I get to feel the pain
Moving forward I’m starting to hack about on a new kernel idea to enable easier support and “Remixes” for non mainline ARM devices. Basically I want to do a remote clone of the Fedora kernel tree and setup a branch for each device we wish to support. From there I plan on pulling in the patches/trees needed to support the device. It’s not going to be pretty as some still use the 3.4 kernel etc but the planned outcome is an automated yum repo with a series of kernels enabling people to build their own install images for a much larger range of devices, a long with a central repo so that when/if the support goes mainline it’s easier for us to merge the changes in. Once this is working I hope for people to be able to submit new platforms via git pull requests. I’ll blog about this more as I get more bits working. I need to upshift my git skills and I suspect this will be an interesting challenge!
- FUDCon and FOSDEM: Unfortunately due to personal commitments I was unable to attend FUDCon NA this year. I was some what amazed at the number of people that contacted me to ask why I wasn’t there and if everything was OK or just to express their disappointment at not catching up with me. Believe me it was unavoidable and I wasn’t just trying to avoid you all! From everything I’ve heard it was a great event with lots achieved both around the ARM and non ARM stuff but others have reported on this so I won’t bore you!
On the plus side I did make it to FOSDEM this year! And what an excellent event it was! It’s an event I’ve been wanting to attend for 5 years or so. I was even recorded in a podcast by the excellent EMEA Cloud Guy talking about ARM, OLPC, all sorts of cloud computing tech as well as other things that I do in my day job. So if you really did miss my voice at FUDCon or are just having problems sleeping you can have a 30 minute odd fix there
There was a lot of things covered on the ARM side from ARM64 (or aarch64) through to the varying state of GPU support. I plan to write up more about this in other posts but it’s certainly going to be an exciting year for ARM development! You can mark my words
- Awareness: I’m constantly surprised about the people that get in contact with me about Fedora ARM support. It’s amazing and exciting the places people are looking to use and actually are starting to use it, it’s nice to know that the thousands of hours I and others are putting into Fedora on ARM aren’t going to waste. The awareness of the project both inside the Fedora community and in the wider Fedora ecosystem is expanding rapidly and that can only be a good thing! For example OLPC announced the XO-4 Touch at CES and it’s running Fedora 18 on ARM to boot.
- Build platform: We’ve finally got enterprise hardware on it’s way. I was kind of hoping we would have made the switch a month a go but any moment now we’ll be moving the koji instance used for ARM builds over to a unified set of enterprise builders based on the Calxeda EnergyCore platform. This is in preparation for a push to promote ARMv7 to primary architecture. I must say, primary or otherwise, I’m really looking forward to having a unified set of builders running on enterprise storage and networking. While the existing platform has served us well it’s really starting to bulge around the edges while building for the three Fedora releases on two architectures. Look for the announcement Real Soon Now or just listen out to me celebrating!
- Dropping armv5tel: We’ve decided to drop ARMv5tel support as of Fedora 19. Both Fedora 17 and 18 will continue to be supported for the entire mainline life cycle. The fact is that ARM themselves, with the introduction of the Cortex-A5, have stated that all cost points and use cases are now covered by the ARMv7 Cortex-A* series of designs and as the memory supported by the v5 series of chips is only DDR1 the devices were getting expensive to make. While there are a number of plug devices out there still the fact is there’s probably less devices there as there were PPC devices when it was decided to drop PPC so I don’t see it as a major issue. The Raspberry Pi is going to be supported by Seneca in a separate ARMv6 secondary arch effort so isn’t going to be left out.
- Anniversary and statistics: Stats are always fun and I noticed the other day that it was in fact my two year anniversary of working on Fedora ARM builds, although like a typical male in a relationship I did forget it! In my defence I have also forgotten my own birthday in the past too
I pushed my first build on January 9th, 2011 and since then I’ve done a mere 82,876 builds via a lot of tasks (koji times out on that query!). I’ve also submitted well over 300 updates for F-17 and at a little over 125 not quite as many for F-18 putting me on the top of the updates list (sorry!) for both releases. They weren’t all for ARM though but I’m very glad F-18 is, currently, a lot less than F-17 which means that we’ve made progress on fixing ARM issues
Look for some more specific, less wordy, ARM related posts soon.
A change of scenery
I’ve been meaning to write this post for a number of months. Almost six in fact, I started writing it well over two months ago because I got an email over the weekend saying that it had been 90 days since I’d started at Red Hat. That’s right, I have a new job! I’d been at my previous employer for nigh on five years and I felt that I was no longer growing and that it was time for a change so when someone approached me about putting on the Red fedora I thought it was a too good an opportunity to pass up!
My official title is Senior Consultant as part of the UKI (United Kingdom and Ireland) and EMEA Infrastructure Professional Services team and I’ll be spending most of my time dealing with Enterprise customers dealing with RHEL and Cloud related things so my role doesn’t directly involve Fedora on a day to day basis. That’s not to say my role won’t involved Fedora as there’s certainly some opportunity there especially with the upstream enterprise related products such as FreeIPA, oVirt and before long OpenStack as well as many many others. It might even one day involve some ARM related work because there’s certainly interest there. Generally it won’t affect or change much in terms of my involvement as all, in most things it will just be business as usual.
One thing that has changed is the amount of travel I do has increased dramatically at least in the short term. Places I’ve been to so far include Helsinki, Munich, Paris and Cairo.
My team is recruiting more people so if you’re possibly interested in joining the Red Hat consulting team in the UK get on contact with me if you want some more information or want to have a chat about the roles.
Fedora ARM on the Google Chromebook
I’ve been asked numerous times about Fedora ARM’s plans to support the Samsung Chromebook so I thought I would do a quick blog post to outline our plans. In short “ABSOLUTELY” and “As soon as possible” are the answers
So of course we plan to support it. As a device the Samsung device is what we’ve all been waiting for in an ARM device in that it’s cheap, nice looking, has relatively decent specs and is all nicely packaged.
Unfortunately initially we’re going to need to support it as a Fedora Remix as there’s some bits that haven’t landed upstream that will require us to fork things and in particular the kernel. So in the short term we’ll do a remix and hope to have a usable version of that out soon and a more stable one not too far behind the Fedora 18 mainline release.
So what is there to be done I hear you ask? That’s a difficult answer but it breaks down roughly as follows:
- uBoot / DevMode and how best to support it (and if we’ll be able to remove the horrible 30 second boot message)
- Kernel support, both initially a fork and then as mainline.
- Xorg / GPU support. We have the basics of this already in Fedora 18 but we want it to go as fast as possible
- Sound. Be aware that at the moment you’re likely to fry your speakers if you try to use it now. We don’t want that. It means we’re going to need to deal with UCM and associated support bits. It’s something I’ve only just found out about and I’m researching what we’re missing. It will be useful for all ARM platforms (and x86 too).
- Improved HW support – basically make sure everything works as expected whether it be HDMI or WiFi.
That’s basically it (and it’s no small amount of work) but most of the rest of Fedora ARM hardfp should run just fine and dandy on it so all of that hard work is done. There’ll likely be some optimisations that can be made so it runs even faster but we should soon be able to support another stunning little device with Fedora ARM
Watch this space
GNOME 3 fall back mode
I’ve been aware of the possibility of gnome fallback mode being dropped for quite some time. I wasn’t aware a decision had been made to definitely do so.
This is somewhat disappointing to me as I know of a lot of users of it. For starters there’s the 2.5 million OLPC XOs that were in the field as of January 2012 (I’m led to believe there’s around 1.5 million more to add from this year) and there’s a lot of ARM devices that have no 3D support because it’s pretty much impossible to use ESGL with gnome-shell at the moment (yes I know there’s plans to refactor mesa and friends to cope with this but that’s not now).
This isn’t designed to be a Federico style rant and if it was it would be aimed as much at the MATE Desktop as the GNOME team. I personally believe MATE would have been better off targeting their resources at properly fixing the GNOME 3 fall back mode to do the things they miss from GNOME 2 as attempting to glue together the GNOME 2 desktop as at least all the core apps are not duplicated and they get to keep the newer code which ultimately will be a lot more maintainable moving forward through the shared development of code. I’m not sure why they went the other route.
Oh well ultimately I believe it will be yet another net loss for GNOME as possibly eventually losing 4+ million odd young users from OLPC deployments (and all the other people such as families that use the devices) when they leave school I think would be a loss for the community moving forward and then add to that the users of it on ARM devices and other old computers in the developing world I think they’re not even aware of the users they have.
N.B. As always the words and thoughts are those of my own and don’t represent anyone else’s opinions.
Well I’ve been meaning on doing a status update on ARM as well as a number of blog posts for quite sometime but I’ve had some personal changes I’ve been settling into (more on that sometime soon).
So first and foremost we’ve announced (a slightly delayed) Fedora 18 ARM alpha. There’s a some of images there for supported devices but if there’s an image you’d like that’s not there feel free to come and help out to make it happen.
We’re looking pretty good for Fedora 18. We’ve got even more packages built than what we had for Fedora 17 and we’ve fixed and improved a lot of issues. I’ve spent a lot of time massaging the kernel into better shape with the help of the Fedora Kernel team and jwb in particular. We have people polishing desktop environments like XFCE and KDE with thanks to some of the XO 1.75s that people received as part of The Fedora Summer of Fun and I look forward to seeing more of the 50 people that received one coming and helping out. Not everything was quite so rosy though as the anaconda newui work has delayed more than just the main Fedora release. We do still have a lot of work to as while the vast majority of packages build and a lot of them even run there’s a lot of testing and optimisation to do.
But it’s not all about Fedora 18 as we’re already working on Fedora 19 (that is after all the reason we branch just prior to Alpha release)! The big thing to note to date is I’ve now landed the first support for a unified kernel. We should be able to boot around 4 different SoC platforms with the 3.7 kernel but expect this to expand rapidly in the 3.8 kernel and by the time Fedora 19 is released with what will probably be the 3.9 kernel I’m hoping we should be able to much easier support a lot more devices with just a couple of kernels.
The last couple of weeks has also been quite mammoth in general ARM news. In the shipping now news the first of the new ARM Cortex-A15 chips has made it to a great and cheap device. We hope to get it running a Fedora Remix soon. It’s the first device and the Samsung SoC based on the A15 and it’s the first of many we’ll see over the next couple of months.
In other not so shipping news it’s been mega ARMv8 / arm64 announcements week. It start with Andrew Haleyannoucing Red Hat is working on openjdk for ARM64. This was followed by Linaro announcing a ARMv8 image based on Open Embedded. Then it was AMD announcing ARMv8 chips and it’s working with Red Hat on them. And then finally today was the announcement of Linaro Enterprise Group. LEG for short (I’m already sick of the puns!). This is great news! And there should be the first starts of the Fedora bring up being available soon and a lot of work to do over the next year too!
Overall it’s been a busy six months in ARM and for me personally. I’ve known about a number of the announcements and it’s finally great to have the cat out of the bag. The soon to be released (hopefully sooner rather than later!) Fedora 18 is another pretty big step forward for ARM on Fedora. The next year is going to be a fun ride!
So one of the things that people often ask me is how do I get involved in ARM stuff. Most of the boring things like builds are mostly automated so I usually recommend to get a device and start using it, hacking on it and testing it. Even the qemu image is a good way to get started. There’s almost 12,000 source packages in Fedora so it’s impossible for us to test all use cases. There’s also a lot of bits of hardware even on the supported devices like the panda boards we don’t have time or the ability to test from GPIO to various sensors etc. So that sort of stuff is a good way to begin!
Using Fedora on your shiny new OLPC XO
So you’ve just received your shiny new OLPC XO 1.75 as part of the awesome Fedora Open Hardware Summer of fun! or you have an existing OLPC XO that you haven’t used for a while and it’s gathering dust. While it’s running Fedora it doesn’t seem to act completely like Fedora and what’s more it’s likely running an ancient Fedora 14 based release and that’s not really cool is it?
Well the first thing to do is to update it to a newer release. There’s XO releases based on both Fedora 17 (stable 12.1.0 release) and devel releases based on Fedora 18 (development 13.1.0 releases). For a XO-1.5 or XO-1.75 the update process is identical. The process I mention here re-images the machine so if there’s anything you need to save back it up first!
It’s relatively straight forward. You basically get the appropriate .zd file, put it on a USB key and away we go. The Fedora 18 based 13.1 images can be found here. You just need the latest .zd (and it’s good practice to grab the .zd.md5 file too) so for 13.1.0 os3 we’d download this file or for F-17 we’d use this one and pop it on a usb key. From there we make sure our XO has battery juice and is plugged into the power. We power it on and instantly hit ESC to get the OFW OK prompt. Plug in the usb key and run the command “fs-update u:\31003o2.zd“. The screen should change to a grid and slowly go all green. Once we’re back at the OK prompt we can type “reboot”. It will take a while to boot the first time as it will update the Open Firmware and do a few other bits but you should eventually be greeted with a Sugar prompt to enter your name. More detailed instructions including for the XO-1 can be found on the OLPC WIKI.
If you wish to move from the Sugar UX to the more familiar GNOME UX you can right click on the little man in the middle, select “My Settings” to get the Control Panel and there’s a icon “Switch to GNOME”. It will ask you to restart X. There’s a matching App in the GNOME menus to switch back.
Next up we want to unblock all updates from the Fedora repositories. The OLPC releases have a specific package NVR set for stability and release just selected updates rather than the usual firehose from Fedora. We generally want all updates available. The one exception to that at the moment is the kernel. So we do the following which removes the OLPC excludes and excludes just the kernel:
vi /etc/yum.repos.d/fedora*
delete this line
include=file:///etc/yum/olpc-exclude
add this line
exclude=kernel
Of course the first thing you want to do now is “yum update” to get the latest and greatest !
Next up is enabling the standard GDM login. This is as simple as yum install gdm and then updating which display manager starts with the following:
rm /etc/systemd/system/display-manager.service
ln -s /usr/lib/systemd/system/gdm.service /etc/systemd/system/display-manager.service
reboot
Finally I suggest joining the Fedora OLPC mailing list. It’s a pretty quiet list but it’s where we copy any release announcements and also a spot to ask XO specific Fedora questions.
So that should get you to something a little more standard and allow you to install some of your favourite bits. Next up of course is getting more involved in both OLPC and ARM things happening in the Fedora community. I look forward to hearing about what works and what doesn’t on the Fedora planet and mailing lists
Also note that the above isn’t just restricted to the ARM based XO 1.75, even the original XO-1 runs Fedora 17 and 18 well so if you have an old XO lying around now is a good time to dust it off.
Allwinner ARM SoCs
Allwinner ARM Systems on a Chip is a cheap SoC producing some cheap and interesting devices. The SoCs themselves are made in China by a company that licensed the Cortex-A8 reference design from ARM, it was one of the earlier ARMv7 chips so isn’t bleeding edge but it is ARMv7 so fully hardfp compatible. They currently produce two widely available chips the Allwinner A10 and A13.
The Allwinner chips are something I’ve been interested in supporting in some form or another on Fedora ARM for a while as they simply have a lot of cheap hardware available that is of reasonable specs. There’s a few things that have stopped me to date. Firstly it doesn’t appear that all their kernel code is upstream as yet so we’d be in a similar situation as we are with the Raspberry Pi. I’ve also not had a lot of time of late (as can be seen by my lack of blog posts recently!) as I’ve had other more pressing things non Fedora ARM things on my plate. Lastly I’ve been concentrating on ensuring Fedora 18 and rawhide remains in reasonable shape, the kernels of the devices we support keep moving forward and I’ve also got some other boards that have upstream kernel support I would like to see being usable on Fedora. Simply put… there’s just not enough hours in the day.
The other day I noticed that the company behind the Allwinner SoC (or some other company) had decided the create a cheap development board similar to that of the Pi, BeagleBoard or some of the other devices on the market. It’s called the CubieBoard.
It’s an interesting board. It’s some what higher speced than the Pi being an 1Ghz ARMv7 Cortex-A8 processor with 1Gb of RAM (or 512Mb), 4Gb of NAND Flash, 100Mb ethernet, most of the usual peripherals and interestingly a onboard SATA port. All for $49.
I contacted the CubieBoard team to see what their plans were for Fedora support and offered my assistance. I’ve since got an email back saying they’ll send me a board to enable us to get it working with Fedora. So once I’m back from holidays I should have a Allwinner A10 board waiting for me which I can start investigating what is required to support the Allwinner devices in Fedora. It seems they’re moving to get the kernel support upstream, there’s also a project to write an open source X driver for the MALI 200 and 400 GPUs. So with luck before long we might have another class of cheap ARM devices for people to play with Fedora on.
Fedora Board and run off voting
Well it seems I was re-elected to the board for a second term. I’m looking forward to driving forward some of the issues I was dealing with and continuing with the projects I was working on. Of course the board is just a small proportion of what I do within the Fedora Project. I believe it’s important to represent the areas of the project I work in such as ARM as well as other wide projects such as OLPC and Sugar Labs that use Fedora as a core base to their projects as well as contributing back to some of the non technical parts of the project.
Of the three board seats that were up for election the third seat was a dead heat so don’t forget there is run off election between the two candidates that ends tomorrow.
Don’t forget to VOTE once again. It literally takes less than a minute to follow the link and make your vote heard. I personally think that this is as important as the first vote to ensure we get the best candidate.
I look forward to working with you all over the next 12 months.
I’d like to announce Sugar on a Stick 7 (Quandong)
There’s been a lot of work go into this release from a lot of communities from Fedora and all the Fedora 17 features that give us new and exciting hardware support to the Sugar Labs community and all the new features that come with the Sugar 0.96 release on which SoaS v7 is based.
Thanks go to all the people that have contributed to this release including Kalpa and Thomas who helped directly with SoaS, the Sugar development team and other Sugar developers. A lot of work has been done to ensure we can get working core Activities like Read and Browse work well. While those Activities look simple there’s been a lot of work from a lot of people to support GTK3 and gobject-introspection bindings, a lot of bugs were fixed with upstream packages to make it all work nicely. The few GTK3 Activities are just the beginning of a long road to convert the entire Sugar interface to newer technologies.
Some of the key new features of this release include:
- Based on Fedora 17 and it’s new features
- Massively improved x86 Mac support
- Sugar 0.96 with initial support for GTK3 Activities and many other improvements
- Return of Browse, now based on WebKit
- The long awaited return of Read and inclusion of GetBooks
- Enhanced hardware support with the 3.3 kernel
- An increase in default Activities by nearly 50%
Almost all of the previous Activities have seen updated releases including but not limited to:
- Abacus 35 (GTK3)
- Record 95
- Physics 9
- TurtleArt 138
Newly added Activities include:
- Browse 137 (GTK3)
- Countries 33
- Finance 7
- GetBooks 11
- Help 14 (GTK3)
- Infoslicer 14
- Labyrinth 12
- Paint 43
- Portfolio 21
- Read 99 (GTK3)
There are many more Activities available through the usual Fedora repositories.
There’s a good getting started guide for Activity developers who wish to work with Fedora 17. It is a step by step guide to getting sugar and the development environment configured to enable a quick head start on development.
The release name, Quandong, continues the tradition of naming releases by types of fruit. The Quandong, or Native Peach, is a native Australian bushfood.
You can download the release from the following link.
http://spins.fedoraproject.org/soas/
It can also be installed as part of a standard Fedora 17 install and is shipped as part of the official Fedora installer DVD and the Fedora Multi Spin Live DVD. It can also be installed from the GUI package tool within a running Fedora install or by command line “sudo yum install @sugar-desktop”.
Board questions and Townhall
What will you be able to accomplish if elected, that you couldn’t as an unelected contributor? Why this post? These are the answers to my board questions which are in the wiki here. The questions and answers from the first Board Elections Townhall meeting are here in the IRC logs. The second one is tonight at 20:00 UTC.
It allows me to contribute back to the project in a more central way than being a contributor and to contribute ideas and direction in a quicker and more direct way. It also allows me to continue on in the work I’ve being doing up until now including working to improve Fedora on cheap devices in particular working to have ARM accepted and promoted to a primary arch. In my last term I worked as part of the ARM team with FESCo to get a set of guidelines for promotion of a new architecture to primary.
What are your goals for your term on the board (in more detail)?
In no particular order:
* Continued expansion of support within Fedora to mobile and low power devices such as ARM to ensure Fedora can lead in the ever expanding mobile and low powered device space and allow Fedora to assist others to innovate in this massive arena.
* Allowing all groups that wish to use Fedora to be able to do so as simply and easily as possible.
* Ensuring all groups work together nicely and think outside their own box and to impact other groups in a good way rather than a “my way or the highway” attitude.
What do you think are the problems and challenges Fedora is currently facing? Do you have solutions for these issues?
There’s a number of challenges facing Fedora and there’s certainly problems.
One of the issues you can get whenever you put a large amount of people of different interests and diversity together. Having travelled to a number of FUDCons and chatted with people online I know Fedora has a wide and diverse community and that is a great thing as it’s what makes Fedora a thriving and diverse community. I would like to see the community be more aware of differences of others within our great community whether that be religion, cultural, sex or even desktop UX of choice. Whether it be on IRC when chatting, in mailing list discussions or face to face at a conference there should be no reason for people to be abused, objectified, yelled at or worse. I don’t believe we should support people in our community that known to do as such. We can do a lot more to improve this.
From a technical perspective there’s a number of things we can do to improve the community. The Fedora Engineering team is leading the charge in some of this such as the great mailing list mock ups, I’m sure community members have more ideas.
From a technical perspective there’s always a lot of challenges and things can be improved including simplification of some of our processes, making the documentation easier to find and read for new contributors and easier to understand when they do read it.
What do you think can be done to attract more people to join the Fedora community as contributors? Do you think Fedora’s visibility needs improvement? If yes, do you have any ideas on how?
I think Fedora has very good visibility already but I’m not sure everyone realises it and we can certainly improve that. For example Fedora runs on the 2.5 odd million OLPC XOs that are currently deployed and the couple of million already scheduled to be deployed this year. They’re probably the widest single deployment of Fedora and will also be one of the first products to ship with Fedora ARM. I also don’t believe we’ve done enough promotion of the work we’ve done with the Raspberry Pi. I’m sure these examples are just a few of where Fedora is used and where we’re leading the curve that people both within and more importantly outside the community realise.
I think we can also do a lot to improve the community involvement for non native English speakers. You just have to look at the size of the two FUDCon APACs to see the size of the community already involved and I’m sure they’re just the tip of the iceberg.
Do you think the issues the Board discusses and the decisions the Board makes are effectively and efficiently communicated throughout the Fedora community? If you believe communication between the Board, the Fedora community, and even the public at large can be enhanced, what first steps or ideas would you propose?
The communication of the board can certainly be improved. I think this is the case for all areas of the community though including but not limited to FESCo and FAmSCo too. I don’t think there’s a single fix for the communication issue, the board over time has tried a number of communication methods some more effect than others but none were perfect. I think it would be good for the board members to communicate more by blog posts as it’s a means of all parts of the community to read when they get time.
