At UDS we return to the subject of those drivers we are carrying which are specific to Ubuntu, why they are not yet upstream and what we can do about it. Union Filesystems are a key technology in producing the live CD environment used to allow both non-destructive testing and the graphical installer. This technology has long been a contentious subject as the patch sets have been extensive and intrusive to the VFS. Worse there have been a number of camps all disagreeing as to the most sensible solution.
For a number of series we have carried the AUFS/AUFS2 patch kit as an Ubuntu add on. This has been a solid performer in this space and served our purposes well. About a year ago now talk began upstream on what approach would be acceptable to upstream. This has resulted in a proposed for an integrated VFS based solution for union filesystems called union-mounts. Patches have been circulating for the best part of a year and we skirted with them for the Lucid cycle, at that time they were feature incomplete preventing full testing.
Recently updated patches have been circulated which should be feature complete, and we are planning to provide kernels enabled for union-mount for testing in a PPA. Should testing there prove good we will consider switching to this solution for our live CDs. Watch this space as they say.
Tuesday, 1 June 2010
Sunday, 16 May 2010
Maverick UDS: the hangover
What a mad week. Finally UDS is over and at least some of us are back home, dispite the efforts of a certain Icelandic volcano and of Eurostar. For me this has been one of the most valuable I have attended. I suspect in large part this is due to my being more experienced in the 'one hour to rule the world' mentality. The rather fetching five minute warning popups were pretty handy to focus the mind on getting the pertinent actions into the gobby seance.
Last cycle I was Kernel Release Manager, this meant that I had responsibility for all of the core kernel blueprints and meant I was tied to the kernel track almost exclusively. With that responsibility passing to Leann I found myself free to rove to other tracks and stick my nose in. I attended a number of X/graphics related discussions. It was great to meet those behind the IRC nicks which I deal with so very often.
More on what we are going to be playing with once the hangover dissipates, in the meantime some Guitar Hero me thinks.
Friday, 23 April 2010
Lucid Kernel Final Configuration
Now that release is fast approaching it was thought appropriate to advertise the final kernel configurations for all of the main distro and ports kernel flavours. The purpose is to expose the main configuration changes to scrutiny and to provide pointers to the full configurations where those are of interest.
For Lucid we have aimed primarily on stabilisation and supportability. As such we do not expect there to be any radical configuration changes in these kernels. There has been a drive to commonise and standardise options between architectures and flavours where at all possible to help standardise the experience. There has also been a drive to pull out to modules some sub-systems which are commonly replaced by users, such as HID, and also pulling out the majority of the PATA and SATA drivers as it is most common to only require a single one of these. We have also enabled KMS for all graphics hardware where it is supported.
To aid in this comparison we have generated a delta report between Karmic and Lucid which shows all items which have changed and how the value has changed. This report can be found at the URL below:
https://wiki.ubuntu.com/KernelTeam/Configs/KarmicToLucid
To facilitate series to series comparison we include pointers to both the full Karmic and Lucid configurations for each flavour, all of which can be found at the URL below:
http://kernel.ubuntu.com/~kernel-ppa/configs/
For Lucid we have aimed primarily on stabilisation and supportability. As such we do not expect there to be any radical configuration changes in these kernels. There has been a drive to commonise and standardise options between architectures and flavours where at all possible to help standardise the experience. There has also been a drive to pull out to modules some sub-systems which are commonly replaced by users, such as HID, and also pulling out the majority of the PATA and SATA drivers as it is most common to only require a single one of these. We have also enabled KMS for all graphics hardware where it is supported.
To aid in this comparison we have generated a delta report between Karmic and Lucid which shows all items which have changed and how the value has changed. This report can be found at the URL below:
https://wiki.ubuntu.com/KernelTeam/Configs/KarmicToLucid
To facilitate series to series comparison we include pointers to both the full Karmic and Lucid configurations for each flavour, all of which can be found at the URL below:
http://kernel.ubuntu.com/~kernel-ppa/configs/
Enjoy!
Thursday, 11 March 2010
Lucid Kernel Freeze
Today, March 11th 2010, marks Kernel Freeze for the Lucid kernel.
This means that the kernel moves from active development into its
stabilisation phase. All planned kernel features are now set, included,
and enabled and the kernel team focus now moves from new enablement
to testing, bug isolation, and fixing of issues found in the kernel.
The kernel will now transition over to the stable maintenance team,
they will be responsible for patch acceptance from here on.
What does this transition mean for you. Now is the time to test things you
care about and report any issues in Launchpad against the linux package.
If you have bugs open found earlier in the cycle please retest with the
latest and greatest kernel and report back whether those bugs are still
present and where you tested. The upcoming Beta-1 release is an ideal
test platform.
Additionally this transition means that is will be much harder to make a
change the kernel. From today patches will need to meet the same criteria
as would be required for SRU[1] to a released kernel. That means that
the patch must have a Launchpad bug open, it must be a fix for an actual
bug being experienced in the field, it must be sent to the kernel-team
email list for review, it must recieve two ACKs from kernel team members,
and finally you must test the updated kernels and report back.
Lucid will be with us for a long time so please help us make this the
best kernel possible. Please test beta-1 and report your issues. Thanks!
[1] https://wiki.ubuntu.com/KernelTeam/StableKernelMaintenance
Friday, 5 March 2010
Lucid DRM Update
After much discussion within the Ubuntu Kernel team, the Ubuntu X team,
and with the various Graphics upstreams it has become clear that the
2.6.32 drm stack is not of sufficient quality to form a good basis for a
LTS release. 2.6.32 does not contain Nouveau so we are already committed
to a backport of that for KMS there. Upstream is essentially saying
ATI Radeon KMS support in 2.6.32 is so bad that the recommendation is to
disable it globally. Finally i915 does not support the latest chipsets
well, and backports are already extremely painful; chipsets which are
slated to become prevalent over the next few months.
The recommendation from upstream is to use the 2.6.33 drm stack if we
desire KMS to be enabled generally, a clear goal for Lucid. Following a
review it does appear that the drm subsystem is sufficiently self contained
that it is possible to backport just that subsystem into our 2.6.32 tree.
This gives us a hybrid kernel gaining the long-term stable support backing
for the main kernel (a major bonus as this has to be supported for 5
years on servers) while gaining the more stable 2.6.33 graphics support
for desktop use. Additionally upstream is essentially rejecting 2.6.32
as a supportable stack, and is committing to longer support for 2.6.33
as their stable version. We are therefore planning to upload a hybrid
2.6.32 kernel containing the 2.6.33 drm backported.
From an Ubuntu stable maintenance standpoint we should be able to track a
hybrid of 2.6.33.y for drm and 2.6.32.y for the remainder of the kernel and
due to the separation that drm enjoys we hope to avoid major conflicts.
Plug gaining the longest possible support from upstream for each part.
This will also remove the requirement to install an LBM package to get
Nouveau cleaning up the install significantly. It seems likely that
Debian and other distros will be following a similar hybrid approach
allowing us to share the maintenance burden.
and with the various Graphics upstreams it has become clear that the
2.6.32 drm stack is not of sufficient quality to form a good basis for a
LTS release. 2.6.32 does not contain Nouveau so we are already committed
to a backport of that for KMS there. Upstream is essentially saying
ATI Radeon KMS support in 2.6.32 is so bad that the recommendation is to
disable it globally. Finally i915 does not support the latest chipsets
well, and backports are already extremely painful; chipsets which are
slated to become prevalent over the next few months.
The recommendation from upstream is to use the 2.6.33 drm stack if we
desire KMS to be enabled generally, a clear goal for Lucid. Following a
review it does appear that the drm subsystem is sufficiently self contained
that it is possible to backport just that subsystem into our 2.6.32 tree.
This gives us a hybrid kernel gaining the long-term stable support backing
for the main kernel (a major bonus as this has to be supported for 5
years on servers) while gaining the more stable 2.6.33 graphics support
for desktop use. Additionally upstream is essentially rejecting 2.6.32
as a supportable stack, and is committing to longer support for 2.6.33
as their stable version. We are therefore planning to upload a hybrid
2.6.32 kernel containing the 2.6.33 drm backported.
From an Ubuntu stable maintenance standpoint we should be able to track a
hybrid of 2.6.33.y for drm and 2.6.32.y for the remainder of the kernel and
due to the separation that drm enjoys we hope to avoid major conflicts.
Plug gaining the longest possible support from upstream for each part.
This will also remove the requirement to install an LBM package to get
Nouveau cleaning up the install significantly. It seems likely that
Debian and other distros will be following a similar hybrid approach
allowing us to share the maintenance burden.
Saturday, 25 July 2009
Wibble Wobble Gwibber
It happens to us all in the end. "No there is no point in being on FaceBook, Twitter is pointless", you know the drill. You are certain you do not need these things in your life but you sign up just "to be in touch with so and so". Before you know it you have about 20 accounts and no idea which one to check when, and little inclination to do so as time is so in short supply. Gah!
I have recently discovered Gwibber. A simple little desktop application which does all that checking for you and shoves all the interesting titbits in one box. Gwibber reads all your incoming updates and shoves them into a single personal timeline, even colour coding the entries so you can tell them apart. Want to reply to something just hit the reply icon and it sends the reply to the right place without you even needing to know which service they are from. What more could a minimalist want I ask you? Struggling with your feeds, give it a go.
I have recently discovered Gwibber. A simple little desktop application which does all that checking for you and shoves all the interesting titbits in one box. Gwibber reads all your incoming updates and shoves them into a single personal timeline, even colour coding the entries so you can tell them apart. Want to reply to something just hit the reply icon and it sends the reply to the right place without you even needing to know which service they are from. What more could a minimalist want I ask you? Struggling with your feeds, give it a go.
Friday, 24 July 2009
Bookmark Knots
I have bookmark knots in my life. I have a laptop, a new netbook, oh another laptop, a media server on my TV. Err, plus my bookmarks are different on every single one of them. In fact I have given up cause I could never find the right one and deleted them from all but my day-to-day machine.
Gaining a new netbook has brought a new urgency to solving this problem. I want to be able to take my netbook away to conferences and yet I need that to be a workable environment. Bookmarks are key to my finding anything it seems, so I need to get those synchronised on both these boxes. As I am already owned by Google I started out evaluating the google task bar. It looks ok I guess but it adds a taskbar which on a netbook is like stealing half the screen, it also does not have sidebar support. On my netbook I have taken to removing all the taskbars and using the bookmarks side bar instead to gain some space, so whatever I found really needed to support those.
Enter GMarks. This Firefox extension basically replicates the Bookmarks menu and sidebar but synchronised with google bookmarks. It even seems to support a toolbar though I have yet to find out how one gets that to display. So far so good. I will let you know how I get on with it.
Gaining a new netbook has brought a new urgency to solving this problem. I want to be able to take my netbook away to conferences and yet I need that to be a workable environment. Bookmarks are key to my finding anything it seems, so I need to get those synchronised on both these boxes. As I am already owned by Google I started out evaluating the google task bar. It looks ok I guess but it adds a taskbar which on a netbook is like stealing half the screen, it also does not have sidebar support. On my netbook I have taken to removing all the taskbars and using the bookmarks side bar instead to gain some space, so whatever I found really needed to support those.
Enter GMarks. This Firefox extension basically replicates the Bookmarks menu and sidebar but synchronised with google bookmarks. It even seems to support a toolbar though I have yet to find out how one gets that to display. So far so good. I will let you know how I get on with it.
Subscribe to:
Comments (Atom)