This mail is a reminder for today´s meeting for French ambassadors and
_every_ interested people.
2009-05-24 / 18:30 UTC
Ce mail est un rappel pour la réunion des ambassadeurs francophones,
qui aura lieu ce dimanche (24 mai.) à 20h30 heure de Paris sur
IRC (freenode) #fedora-meeting .
L'ordre du jour est disponible depuis cette page :
N'hésitez pas à le modifier pour rajouter des sujets qui vous semblent
Merci de répondre à ce message en cas d'indisponibilité.
I'd like to ask everyone to take a look at upcoming events for Q2 and Q3 here.
For the Q2 events we really need to deal with budgets so if you are
the owner (or one of the owners) please try to have ready a request
for funds if you will need funding for the event by the next FAmNA
meeting on June 2.
Some of the events in Q2 and Q3 do not yet have owners listed. If you
are able and willing to take ownership of these events please do.
Also if you want Fedora to Sponsor any of these events (in either Q2
or Q3) please do make those requests now. Depending on budget
availability and other needs it might be possible to sponsor a Q3
event from Q2 funds more easily than waiting for Q3. Early sponsorship
has added benefits in terms of advertising usually as well.
Thanks for all the great work being done at events by ambassadors.
Below is the the text of the interview, didn't really think about the
lead it, but thats trivial...
*1. Please introduce yourself and what you do and how you got started
working on virtualization.*
I'm one of the lead developers for the libvirt project and am actively
involved in many related areas of open source development (qemu/kvm,
xen, gtk-vnc, virt-manager, to name but a few). I also co-maintain many
of these packages in Fedora and RHEL, along with many others in Red
Hat's virtualization team.
More than three years ago (shortly after transferring into Red Hat's
Engineering team, from consulting services) I was working on the OLPC
project. We needed a way to easily test the OS images we were building
without needing real hardware. As a proof of concept, I hacked up a
simple GTK application to run images them under QEMU. At around the same
time Daniel Veillard had started the libvirt project and there was a
desire for a desktop application to manage Xen using libvirt. So I
switched over to the virtualization team, wrote virt-manager for Fedora
6, and my involvement in all areas of open source virtualization grew
*2. Many people view the work being done on virtualization as a feature
set of major importance and significance. Can you give us a brief
overview of some of the changes that we can expect to see in F11?
The open source virtualization development effort is so large now, that
it is useful to discuss each stream in turn.
At the lowest layer is obviously the Linux kernel & KVM/QEMU. There has
been a major acceleration of development in QEMU and push to merge KVM
into the official QEMU source repository. There's ever continuing work
on performance, stability, scalability & reliability in KVM. PCI device
passthrough is one new feature we're highlighting for Fedora 11. The
return of Xen Dom0 was not to be, as the Dom0 paravirt_ops merge with
the upstream Linux kernel is still an ongoing process.
At the middle layer is libvirt, providing a consistent management API
across different virtualization technologies. New features in libvirt,
since F10, include PCI device passthrough for Xen and KVM, the sVirt
security driver using SELinux to protect KVM guests from each other,
thread safety of all libvirt APIs, improved scalability, reliability and
debugging for the libvirtd daemon and support for SCSI HBAs and
copy-on-write volumes in the storage management APIs.
The top layer covers end user tools such as virt-install & virt-manager.
virt-manager is undergoing a significant (and ongoing) overhaul of its
user interface. The first improvements arriving for Fedora 11 are in the
guest installation process and storage management capabilities. As guest
installation is first task most users try, ensuring this is simple and
reliable is key to making a good first impression. Guest desktop
interaction is another historical pain point which has been a focus for
improvements in Fedora 11.
With every release we also try to make a significant step forward in
security of the virtualization stack. In Fedora 11 the focus has been
on SELinux to protect guests from each other and SASL to authenticate
*3. There have been some large changes in virt-manager and libvirt,
which are at the core of the user experience when it comes to
virtualization. Can you talk to use about those some more?*
The guest installation process and desktop interaction are the most
critical areas for making a good first impression. In the virt-manager
re-design the wizard used for installing new guests has been
streamlined, cutting out three redundant steps. Where possible, it will
automatically detect the type of operating system being installed and
choose the best configuration options to optimize for this OS, no longer
requiring the user to figure this out for themselves. The installation
process now directly utilizes the libvirt storage management APIs to
allow easy creation of files in a variety of formats (raw, qcow2, vmdk,
etc), allocation of new local disk partitions or LVM volumes and access
to LUNs exported by iSCSI targets. This is particularly useful when
remotely managing virtualization hosts, allowing regular administrator
tasks to be performed from the virt-manager UI without resorting to
command line SSH sessions.
The mouse pointer has been a constant source of trouble for
virtualization management applications. Getting the guest mouse pointer
to track the host pointer is essentially impossible with the standard
emulated PS/2 mouse. The solution is to provide a pointer device that
supports absolute motion events, instead of relative events that the
PS/2 mouse provides. For KVM and Xen, this means adding a USB tablet
device, but historically Xorg has not been able to automatically
configure this correctly. This is resolved with Fedora 11 guests,
finally providing a guest pointer that moves in perfect sync with the
host, not requiring the pointer to be confined to the guest window.
Users with non-US layout keyboards have also had a hard time getting
their guests to support input of accented/special characters. The VNC
protocol has now been extended to allow the hardware keycodes to be
passed directly from the VNC client to the guest OS without any
intermediate translation step. This should allow the guest OS complete
control over the keyboard layout mapping, without a need for any special
settings on the host.
The final piece of work was to increase the guest desktop resolution.
The real Cirrus video card that QEMU emulates would never have done more
than 800x600, but there are tricks that can be done in a virtual world.
Thus a simple change to the Xorg cirrus driver allows it to detect that
it is using a Cirrus card emulated by QEMU and increase the guest
desktop resolution to 1024x768. Still not great by today's standards,
but better than before. Longer term plans involve replacing the cirrus
driver in QEMU with something more virtualization friendly.
*4. Also, as people should take note of, there has been a lot of work
done surrounding KVM and getting that well integrated into the whole
virtualization setup in Fedora. How has that work been going and has
anything significant been done in that area in this release?*
Fedora was the first major Linux distribution to integrate KVM back in
the Fedora 7 release. It became the default virtualization technology in
Fedora 9, when it became clear we could no longer maintain the separate
Xen host kernel until it was merged in the upstream Linux kernel. The
great benefit of KVM from an distro integration point of view, is that
it is there by default in all new Linux kernels. All that was required
in Fedora was to turn on the module build and make sure the modules are
always loaded when compatible CPUs are found. libvirt and virt-manager
have also both supported KVM since it was first added to Fedora. Thus
there hasn't been a need for much additional integration work for KVM.
The focus has simply been on improving features available to KVM users
via libvirt and virt-manager.
5. Glauber Costa has also done significant work merging KVM and QEMU.
Can you explain to us what QEMU is and why the choice was made to merge
it with QEMU and how that is of benefit to the user base?*
Earlier Fedora releases have have suffered from the divergence of QEMU
and KVM code bases. Upstream QEMU has had releases almost 1 year apart,
while KVM has been releasing at least once a month, if not more, using
snapshots of the QEMU source repository. Thus the features available in
QEMU were far behind those available in KVM even though they both shared
the same fundamental code base and upstream development stream. It also
doubled the work package maintainers had todo for security & bug fixes.
Since Fedora 10 though, the upstream QEMU community has accelerated its
release schedule significantly and many of the KVM features have been
merged back into the main QEMU code base. Thus we judged that the time
was right to attempt to ship a single package containing both QEMU and
KVM built from a single code base. For users this means that parity of
features between QEMU and KVM, while the reduced burden on our Fedora
package maintainers, ensures more timely security and bug fixes. Glauber
also took the opportunity to split out all the virtual BIOS files and
ROMs from QEMU into separate packages and ensure all are fully built
from source using appropriate upstream source releases.
*6. Virtualization and Security are two things that are being discussed
more or less hand in hand these days, as the ability to create and use
virtualized machines expands there are many security risks involved. Can
you speak a bit to the work that was done one improving security both at
the kernel level (sVirt) and also the user level with things like SASL
for VNC Auth?*
In each Fedora release we try to make at least one significant step
forward in the security of our virtualization technology. In Fedora 8,
libvirt gained support for secure remote management using TLS for
encryption and x509 client certificates for authentication, while
GTK-VNC, QEMU, KVM and Xen were also all extended to add a VNC extension
for TLS encryption providing a secure remote desktop. In Fedora 9
libvirt was further extended to support SASL enabling secure remote
managment with Kerberos for authentication and PolicyKit for local
desktop authentication. Fedora 9 and 10 also increased use of SELinux to
protect the host operating system from a compromised or malicious
The latter still did not provide any protection between guests, so one
compromised QEMU process would still potentially be able to compromise
another on the same host. Thus James Morris started work on a project
known as sVirt, the first results of which are appearing in Fedora 11.
The focus has been to provide isolation between guests running on a
single host. libvirt directly integrates with SELinux to ensure every
QEMU process it launches runs within a dedicated security context, only
able to access its own assigned disk images. This protection is enabled
by default on all Fedora 11 hosts using libvirt for management. As well
as the security benefits, the end user experiance is improved because
libvirt will automatically manage SELinux labelling for all guest disks,
eliminating a major source of bug reports from previous Fedora releases.
*7. These features have all evolved over time and over the previous
Fedora releases and Fedora, as a distribution, has always been a leader
in the virtualization realm. Can you talk a bit now about the actual
process of developing these features and how many of the improvements
and enhancements to virtualization have come about as a direct result of
the work done previously? Also, what does the future look like?*
Virtualization technology in Fedora is reaping the benefit of very
active upstream projects and the significant developer resources of Red
Hat's Virtualization Engineering team. The combination of these provide
great opportunities for new features to have their debut in Fedora releases.
The ideas for new features come from many sources, some from Fedora
end-user experiances & consequent bug reports, some magically arrive on
cue from upstream projects, while others are things that look to be
important for future RHEL releases. With the PCI device passthrough
feature in F11, the core support was all already done by the upstream
KVM community. This is a important feature for future RHEL, so Red Hat
put resources into a F11 feature to add support to libvirt for PCI
passthrough with KVM and Xen and then expose this in virt-manager.
The feature aiming to improve the guest desktop interaction was a result
of the persistent stream of bug reports from Fedora users. We had been
considering ways to address this over course of several Fedora releases,
but it was not until Fedora 11 that all the pieces of the solution
finally came together from the various upstream projects.
The security improvements in virtualization have a different origin.
Very few end users ever file explicit bug reports asking for the
addition of more authentication / encryption features or to use more
SELinux. If anything users ask for ability to more easily turn off
existing security features. This is a case where the user is not always
right. They do want more security, but they just don't know it yet!
As a developer it is neccessary to be very proactive with security
improvements. This can be particularly challenging work because the
solutions often involve working across multiple upstream communities.
Take the VNC SASL authentication feature in Fedora 11 as an example. The
first step was to write a specification for a new VNC security
extension, have it reviewed & get a code for it allocated by RealVNC.
Work on QEMU was required to implement the server side. Work on GTK-VNC
was needed for client side. For management tools, work on libvirt was
required to get the new security type enabled for guests it launches and
finally virt-manager was extended such that it knows how to login.
That's give different projects involved for one feature. This is only
practical by having a close working relationship with all the upstream
communities and carefully coordinating the work there so it all arrives
in time for the next Fedora release.
For the future we're happy that libvirt gained support for managing
VirtualBox recently and likely to soon have a driver for the Open
Nebular cloud management project. Expect more advancements in sVirt,
allowing for tighter controls on what a virtual machine can do, for
example, ability to restrict network access of guests. libvirt will also
gain the ability to manage host network configuration in Fedora 12,
removing the need to manually configure bridge devices. Container based
virt may make a more formal appearance in Fedora 12 as the native Linux
container (LXC) support improves in the kernel and libvirt. The overhaul
of the virt-manager user interface also continues.
*8. Working on Virtualization must be awfully time consuming and very
involved. Do you enjoy it? What do you do to get away from the
pressures of hacking?*
Working on open source virtualization technology is a great experiance
because it is a really interesting & challenging field, having plenty of
talented developers to work with & learn from. There is plenty of work
still to be done at all levels of the stack from kernel/hypervisor right
through to end user applications & not nearly enough time todo it all.
I'm fortunate to be able to spread my work between upstream projects,
the Fedora community and RHEL releases and maintainence. As for free
time ? What free time :-) I try to find time for a photography, with 4
out of my 5 cameras still using film, rather than digital.
I'd like to put a call out for any ambassadors in the land down under
I have access to facilities in Melbourne, Adelaide and Perth, (they're
basically classrooms, I work for a college and have full support of our IT
management to run any fedora events at any of our campuses). Free wi-fi is
available at our main campus in Melbourne (thanks to
could also be organised at other locations), I could organise a projector,
plus duplication of F11 install media etc, and put on light refreshments.
I don't have the time to organise an event on my own, is there anyone else
that would like to assist?
I wonder when should be the good time to mirror Fedora 11 final release?
Since our mirror HDD is not very large, I would like to mirror just the final one and all further updates, not the preview/beta ones.
We should wait until the 2nd of June or any time?
An Interview on Fedora 11's enhanced Audio Control with Lennart Poettering
Where would we be without sound? It's the most primitive of
communication methods, and yet it has spawned so much technology around
it. Whether you're a musician, a DJ, riding a bus to work, or even just
stuck in a cubicle listening to the radio somewhere, sound has become an
integral part of your daily experiences. When Fedora 11 lands, along
with it will land a number of enhancements to the sound subsystem,
including unified volume control, per stream and per device monitoring,
and proper Bluetooth audio support. I recently caught up with Lennart
Poettering, Red Hat Desktop Team Engineer and resident audio guru.
Here's what he had to say about the upcoming improvements and what the
*1. Please introduce yourself and give us a brief intro to how you
started working on the upcoming audio improvement in F11.*
I am Lennart Poettering and have been working for Red Hat in the Desktop
Group for two years now this month. I live in Berlin, Germany.
PA has been part of Fedora since F8. Since then we used to ship two
volume control appications: the GNOME volume control and a PA (Pulse
Audio) specific tool (pavucontrol). The latter was mostly a showcase
what can be done with PA and I wrote it mostly as a demo, not because I
thought it was any good as an UI.
Of course having these two volume control UIs in Fedora was a situation
that badly needed fixing. Especially since both UIs exposed too many
unnecessary options: the GNOME volume control exposed a lot of low-level
hardware-specific features that only a tiny minority of people actually
really understood, and the PA volume control exposed a lot of low-level
software features that a slightly larger minority of people only
actually really understood.
Now during the last year we reached a point were the feature set of PA
for volume controls became very complete (with such things as arbitrary
meta data on every stream/device, per-stream and per-device monitoring,
hardware volume range extension, "flat" volumes and lots of other stuff)
and Jon McCan with help from Bastien Nocera finally took up the work to
fix the UI situation.
They basically designed the new UI from scratch with input from
usability experts. It implements many of the features the old
pavucontrol tool did, but in a much nicer, streamlined way. Also it
integrates sound theme/event sound control with general audio
configuraton and volume control in a single UI tool.
*2. Can you give us some background on the upcoming changes to the audio
subsystem in the Fedora 11 Release?*
If you want to know more about the Volume Control, I'd just refer to the
We moved PA 0.9.15 into F11, a nice overview over the new features you
can find here:
However that overview is a bit out-of-date. There are quite a few
additional features that went into 0.9.15, most prominently full
Bluetooth Audio support: Together with Bastien Nocera and the BlueZ guys
I worked to make Bluetooth audio easily accessible -- the bluetooth
applet now exposes an easy dialog that allows you to pair and activate a
bluetooth headset. After that is done it will automatically appear in
PulseAudio. If you need to reactivate it later, you can do that with a
simple click in the applet menu. It works surprisingly well. It even
works fine for lip-sync video. Which is kind of magic, given that
Bluetooth Audio doesn't actually offer any timing interfaces, so syncing
up audio with video is not really possible. I spent a lot of time to
make sure it does work nonetheless, and it seems to work on the majority
of headphones although I cannot say for sure if it does for all of them.
*3. Where did the ideas to change all this stuff come from? Didn't audio
always work in Fedora?*
Depends what you mean by 'work'. Sure, basic audio output worked. But in
many ways what we had on Linux was not comparable to what MacOS or
Windows supported. And it still isn't in many ways. However in other
ways we have now surpassed those competitors.
A lot of the changes we introduced with PA are not directly visible to
the user. For example the so called 'glitch-free' logic in PA is very
important for a modern audio stack, however the normal user will never
notice it -- except maybe because when we introduced it initially a lot
of driver bugs got exposed that people were not aware of before because
that driver functionality (usually timing related) was not really
depended on by any application. In fact even now many of the older
drivers expose broken timing that makes usage with PA not as much fun as
it could be.
A more detailed explanation of this 'glitch-free' logic you may find here:
Both Windows Vista and MacOS X have similar g-f logic in their audio
stacks, however with PA we brought it to the next step. For example, we
implemented this logic in a zero-copy fashion and with arbitrary sample
types. This allows us to pass PCM data through our pipelines without
ever having to copy/convert it unless we really have to.
So yes, as you might have noticed I spend a lot of time to get low-level
internals right. And I like to speak about it, even though most people
are not aware of all those technical details and how awesome this all
is. ;-) That said, this stuff isn't perfect yet and could need more
But it's not all just in the low-level details. Also on higher levels we
got inspired by how our competitors do things. For example the new
"flat" volume logic was pioneered in Vista, and we have now adopted a
similar logic in PA. It's a great way to reduce the complexities of
volume control by 'merging' a few of the sliders in the pipeline. It
thus solves the "So which slider is now causing my volume to be too
low?" a bit. But also here, there's more work to be done.
It's not all just getting inspired by our competitors. There are a lot
of genuinely new features in PA that none of them have (at least to my
knowledge). For example, in PA we have 'spatial' event sounds. I.e. if
an event sound sound is triggered by a mouse click/dialog at the left
side of the screen the sound is generated more from the left speakers,
and similar for the right side. This is of course mostly a toy. But I
think a useful one ;-) .
Listing all the fancy features PA has would certainly be a bit too much
for this interview. So I'll leave it with this... ;-)
Generally, we get inspiration from everywhere. And sure, as long as the
most basic music playback was enough for you audio did always work in
Fedora. But OTOH, when we started with the integration of all of these
new audio features into Fedora two years ago the audio stack was still
at a point of what was modern in the 90's. With the new features of the
new volume control and PA we are working on bringing Linux audio to what
is modern today.
*4. Can you also give us a comparison of our new audio framework in
reference to other audio frameworks and audio subsystem models that are
There are many frameworks out there. On Free Software systems PA doesn't
really have any competitor. Some people think that JACK is one, but it
actually is not. JACK is clearly focussed on audio production and not
very useful on the desktop otherwise. For example, it is strictly
designed to provide very low-latency at the price of power consumption.
This is the right thing to do for audio production but not on the
general desktop. Logic like 'glitch-free' (see above) makes a lot of
sense for the usual desktop audio since it allows flexible adjusting of
the latency to what is needed. If used properly it can be used to
decrease the interrupt rate to 1/s, while still allowing instant
reaction to user input. Since most PCs these days are laptops theses
kind of power consumption related features are very important.
One of the current weaker points of Audio on Linux is that we have this
clear separation of JACK for audio production and PA for
desktop/embedded. Other operating systems have managed to make this a
bit smoother by having a single stack for both. This however actually
has both advantages and disadvantages.
To improve the situation for now we focussed on making PA and JACK
cooperate better. In F11 when JACK needs low-level access to an audio
device it will tell PA so and PA will comply and release the device.
This should make switching between the two sound systems easier though
of course this is no perfect solution. Given the lack of manpower
further integration is unlikely to happen anytime soon -- though both
the JACK guys and I seem not generally opposed to something like that.
Now, if you compare our audio stacks with those of the big other
operating systems (Windows and MacOSX), then besides the fact that they
usually integrate desktop audio and audio production better than we do
(as mentioned) there are many things we are better in and many they are
better in. We certainly have more flexibility: i.e. depending on your
application you can access audio on a lot of different levels: you can
access ALSA directly if you need very low-level control, or via PA for
desktop level control. You have APIs like GStreamer for media streaming
and so on.
This flexibility however translates to more complexity in many ways, and
a hodgepodge of API styles. (OTOH Apple's CoreAudio actually isn't as
streamlined as many MacOS proponents like us to think.) The
documentation for our APIs is usually much worse then theirs. We really
need some improvements in that area. Featurewise, PA usually has better
networking related features then those counterparts. But there's a lot
of features they have right now we lack.
Other Unixes, such as FreeBSD and OpenSolaris are still stuck with OSS
(Open Sound System) audio. In F11 we finally switched OSS off by default
(though you can still reenable it via some minor hackery). OSS was the
predecessor of ALSA. Thankfully it is now fully obsolete on Linux. OSS
is mostly a design from the early nineties. It has received only minor
updating since then. It is no way comparable to what we now have on
Linux or even what MacOS or Windows provide. (Although is has some very
vocal fans which like to write me hate mails because I say things like this)
*5. This work all started in earlier releases dating all the way to even
Fedora 8, if I am correct. How has all this stuff progressed and evolved
from then? What was done in previous releases that enabled building upon
for this release?*
Fedora 8 was the first release where we integrated PA. In Fedora 9 we
stabilized PA support. In F10 we integrated the 'glitch-free' logic
which turned out to be quite a bumpy ride given that it exposed a lot of
timing related driver bugs. In F11 g-f has now been made more robust and
most of the more modern audio drivers should now be fixed. Also we have
now started to push PA support more into the UI, like with this new
*6. What are the plans for the future, if any, in this particular space
in the distro?*
I am working on multiple things for F12. Firstly there will be a couple
of more low-level changes to PA. The core will be made more threaded.
Right now, we run most things in one 'main' thread and do low-level
audio I/O in one thread for each audio card. My plan for F12 is to split
that one 'main' thread up into as many threads as possible. This should
make PA more robust for a couple of operations, and make latencies more
Then, I am working on considerably beefing up PA's usage of the
low-level hardware volume controls. For example, many cards have
seperate low-level volume sliders for "Speaker", "Master", "PCM" (and
more) that are in the line from the PCM data we stream to the speakers.
PA currently exposes only one of those sliders (usually "Master"). My
plan is to 'multiply' those sliders and create a single 'product'
virtual slider from them that has a better granularity and a larger
range. This rework will also introduce input/output switching and
What has already landed in PA's git repository is support for UPnP A/V.
When used in conjunction with Zeeshan Ali's Rygel UPnP MediaServer
implementation this allows streaming any application's audio to a any
UPnP MediaRenderer (including PS3/Xboxes and all those 'Internet Radio'
devices). This is actually pretty neat. Later on we hope to make PA a
Media Renderer as as well as a MediaServer. This nicely compliments our
current Apple RAOP support.
And there's a lot of other things planned. We'll see how much of that
will be ready for F12. I don't like to talk too much about upcoming
features and planned code if I don't have anything to show yet, so I'll
leave it at this.
And then there's always a little project of mine that is called
'libsydney' that is intended to be a portable, modern and friendly PCM
API. During the last months I focussed more on PA itself though.
*7. Do you feel that work like this helps enhance the desktop experience
on Linux in general and strengthens the cause of the Linux Desktop, or
is it more all in day's work?*
I think that PA is the way forward for audio on the Linux desktop. It
may have its deficiencies -- but everything has. We still have some way
to go, but I believe that a modern audio layer is really important for
the Linux Desktop to succeed.
And no, it doesn't feel at all in a day's work. It always is a great
feeling to see how PA got incorporated into so many distributions and
how it is now used by so many people. I am pretty sure that only if you
hack on Linux software you get this in this ways.
*8. Speaking of all in a days work, what are things do you usually work
on? What do you most enjoy doing outside of work.*
Red Hat basically hired me to help improving audio on Linux. So that's
what I am doing during work.
Outside of work spend my time with photopgraphy. And I am trying my best
to travel to interesting places as much as I can and my time off allows.
Thank you Lennart for an excellent interview, ideas and insight. We look
forward to hearing more from you. Get it--hearing more, he works on
sound, okay I give up.
I thought let me share you the efforts of people like us and success
story , the introduction of open source mainly LINUX is now part of
official syllabus of Gujarat 12th standard computer subject.
Here are some Q/A with Mr. Harshal Arolkar.
Behalf of VGLUG I got chance to have small Q/A with Mr. Harshal
Arolkar ( He is a part of committee and played lead role in
designing the text book for Gujarat 12 th standard Computer
subject ). Due to their team efforts now open source is a part of
computer subject in 12th standard in Gujarat. */
Don't you thing this is a great moment for all who are promoting
Linux and opens ource and a major step in Gujarat for Open source
Excited !!! well here are the questions the answers are at
Although after some conversation I added few more questions.
Many many Thanks to Mr. Harshal Arolkar.
Redhat Channel Partner and Training Partner
Ahmedabad: 404,Maulik Arcad,Nr. Mansi cross Road,Satellite Rd
Baroda : 25, The Emperor, Fatehgunj
a way to spreading fedora to users with slow connection.
My idea is the user search a local Ambassador and send him a usb stick
and attach the postage to send the stick back.
And the Ambassador can easy create the USB stick with the
And a little paper with the architecture and the gui gnome/kde.
This way is very cheap for the fedoraproject and a simple way for the user.
Only a little idea :).