Linus Jumps Kernel Ahead to 3.0

Last week it looked like we were, finally, going to get a version bump from 2.6 to 2.8. Instead, Linus Torvalds has bitten the bullet and tagged the first release candidate of the next kernel to 3.0.

That’s right — it looks like the next kernel release is going to go all the way to 11, er, 3.0. If you missed the discussion last week, this isn’t because the kernel is gaining massive new functionality (as it did from the 1.x to 2.0.x series), but because “it will get released close enough to the 20-year mark, which is excuse enough for me.” Sounds like a good enough reason here, too.

To be clear, 3.0 will not be a radical change. According to Torvalds, “Sure, we have the usual two thirds driver changes, and a lot of random fixes, but the point is that 3.0 is *just* about renumbering, we are very much *not* doing a KDE-4 or a Gnome-3 here. No breakage, no special scary new features, nothing at all like that. We’ve been doing time-based releases for many years now, this is in no way about features. If you want an excuse for the renumbering, you really should look at the time-based one (“20 years”) instead.”

Want to test the new kernel, check for it in the /pub/linux/kernel/v3.0 directory, though the git tree is still linux-2.6.git for now.

If we follow the “once per decade” model, it looks like we’ll have Linux 4.0 sometime in 2020.

 

Ubuntu Oneiric Ocelot: Next after Natty?

The naming of cats is a difficult matter

It isn’t just one of your holiday games.

– T S Eliot, The Naming of Cats

For the next cycle, I think we’ll leave the oceanic theme behind. The “oddball octopus”, for example, is a great name but not one we’ll adopt this time around. Perhaps in 13 years time, though!

The objective is to capture the essence of our next six months work in a simple name. Inevitably there’s an obliquity, or offbeat opportunism in the result. And perhaps this next release more than most requires something other than orthodoxy – the skunkworks are in high gear right now. Fortunately I’m assured that if one of Natty’s successors is a skunk, it would at least be a sassy skunk!

So we’re looking for a name that conveys mysterious possibility, with perhaps an ounce of overt oracular content too. Nothing too opaque, ornate, odious or orotund. Something with an orderly ring to it, in celebration of the crisp clean cadence by which we the community bring Ubuntu forth.

There’s something neat in the idea that 11.10 will mark eight years since Ubuntu was conceived (it took a little longer to be born). So “octennial” might suit… but that would be looking backwards, and we should have an eye on the future, not the past. Hmm… an eye on the future, perhaps ocular? Or oculate? We’re certainly making our way up the S-curve of adoption, so perhaps ogee would do the trick?

Alternatively, we could celebrate the visual language of Ubuntu with the “orange okapi”, or the welcoming nature of our community with the “osculant orangutan”. Nothing hugs quite like dholbach, though, and he’s no hairy ape.

What we want is something imaginative, something dreamy. Something sleek and neat, too. Something that has all the precision of T S Eliot’s poetry, matched with the “effable ineffability” of our shared values, friendship and expertise. Something that captures both the competence of ubuntu-devel with the imagination of ayatana.

Which leads us neatly to the Oneiric Ocelot.

Oneiric means “dreamy”, and the combination with Ocelot reminds me of the way innovation happens: part daydream, part discipline.

We’ll need to keep up the pace of innovation on all fronts post-Natty. Our desktop has come together beautifully, and in the next release we’ll complete the cycle of making it available to all users, with a 2D experience to complement the OpenGL based Unity for those with the hardware to handle it. The introduction of Qt means we’ll be giving developers even more options for how they can produce interfaces that are both functional and aesthetically delightful.

In the cloud, we’ll have to tighten up and make some firm decisions about the platforms we can support for 12.04 LTS. UDS in Budapest will be full of feisty debate on that front, I’m sure, but I’m equally sure we can reach a pragmatic consensus and start to focus our energies on delivering the platform for widespread cloud computing on free and flexible terms.

Ubuntu is now shipping on millions of systems from multiple providers every year. It makes a real difference in the lives of millions, perhaps tens of millions, of people. As MPT said, “what we do is not only art, it’s performance art”. Every six months the curtains part, and we have to be ready for the performance. I’d like to thank the thousands of people who are actively participating in the production of Natty: take the initiative, take responsibility, take action, and your work will make a difference to all of those users. There are very few places in the world where a personal intellectual contribution can have that kind of impact. And very few places where we have such a strong social fabric around those intellectual challenges, too. We each do what we do for our own reasons, but it’s the global impact of Ubuntu which gives meaning to that action.

Natty is a stretch release: we set out to redefine the look and feel of the free desktop. We’ll need all the feedback we can get, so please test today’s daily, or A3, and file bug reports! Keep up the discipline and focus on the Narwhal, and let’s direct our daydreaming to the Ocelot.

Originally posted by Mark Shuttleworth here on Monday, March 7, 2011.

 

Ubuntu 9.10 reaches end-of-life on April 30 2011

Ubuntu announced its 9.10 release almost 18 months ago, on October 29, 2009. As with the earlier releases, Ubuntu committed to ongoing security and critical fixes for a period of 18 months. The support period is now nearing its end and Ubuntu 9.10 will reach end of life on Friday, April 29, 2011. At that time, Ubuntu Security Notices will no longer include information or updated packages for Ubuntu 9.10.

The supported upgrade path from Ubuntu 9.10 is via Ubuntu 10.04. Instructions and caveats for the upgrade may be found at https://help.ubuntu.com/community/LucidUpgrades. Ubuntu 10.04 LTS continues to be actively supported with security updates and select high-impact bug fixes. All announcements of official security updates for Ubuntu releases are sent to the ubuntu-security-announce mailing list, information about which may be found at https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce.

Since its launch in October 2004 Ubuntu has become one of the most highly regarded Linux distributions with millions of users in homes, schools, businesses and governments around the world. Ubuntu is Open Source software, costs nothing to download, and users are free to customise or alter their software in order to meet their needs.

Originally sent to the ubuntu-announce mailing list by Kate Stewart on Tue Mar 29 02:55:03 UTC 2011

 

Becoming an Ubuntu Developer: a short guide

I’ve heard and/or read a number of complaints over the past while about how the process of becoming an Ubuntu Developer is difficult, so I thought I’d write up a short guide to one of the many paths to becoming a developer. I send this to the Ubuntu Developers list for maximum distribution, although I realise that many of you are already developers, so won’t find this as useful: please skip past it, or pass it on to those you know that are currently interested in becoming Ubuntu Developers (or extending the set of packages to which they have been granted upload rights).

Step 1: Membership
While it’s not required to be an Ubuntu Member before applying to be a developer, it is required that the criteria of Membership be met to be approved as a developer. In short, this means being actively involved with and contributing to Ubuntu for some time (usually about a development cycle, although it can be shorter for those with very strong contributions). Spend time interacting with other members of the community, and learn as much about how Ubuntu works and how it is created as possible. Those with a specific interest in development may find that the Masters of the Unseeded or the Bug Squad are good places to start, if there is no other team with whom they have a natural affinity. Those of more general involvement may obtain membership through any number of other sorts of contributions. More information on the requirements for Membership are available on the wiki at https://wiki.ubuntu.com/Membership

Step 2: Start working in the area for which you want upload rights
We have an increasing number of packagesets, each targeting a specific area of development, and the negative space of all packagesets, where we tend to focus mostly on archive quality. Find an area that interests you, and get to know the developers actively working in that area. Start working on things that fit within your area of interest, building both expertise with the work you have selected and close relationships with others working in the same area. For example, if you wish to be a server developer, start working to fix bugs in packages in the server packageset, working closely with the Ubuntu Server team. Alternately, if you wish to be a core developer, start working to fix bugs in packages in the core packageset, working closely with other core developers. Your goal in this step is to become a peer to the other members of the relevant team. You may find it useful to review https://wiki.ubuntu.com/UbuntuDevelopers to see some of the descriptions of the various sorts of developers.

Step 3: Prepare an application
Follow https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess to create your application. Clearly document your work in the areas of interest. Be especially sure to provide links to work done upstream (including in Debian) on packages in the target area, and any work where you were one of several contributing to a single uploaded revision, as the automated upload tracker in launchpad only reports those packages for which you have sole changelog credit. Documenting a few different types of work, or work in different parts of the release cycle (where different choices were required) can help show a broader understanding. The more specific you can be in every section of your application, the better: for example, a future plan to ensure Ubuntu provides the best possible turnkey PBX solution for the next LTS will often receive more credence than a short listing of “more of the same” for someone previously working on the VoIP stack, especially if it includes some details. If you are working on blueprints, listing your outstanding blueprint-related tasks here (with links) is a great way to provide detail. When seeking endorsements for your application, a good strategy is to ask anyone who suggests you should apply to endorse your application, and ask anyone sponsoring your work to endorse you (best to ask at the time they are sponsoring it). If someone says they haven’t seen enough of your work to endorse you, ask them for a task or two: helping folk with their work is nearly guaranteed to get you good endorsements.

Step 4: Apply
Check https://wiki.ubuntu.com/DeveloperMembershipBoard for upcoming meeting dates and times, and send a notification of your application to the mailing list at least a week before the meeting you wish to attend. Be prepared to answer a few questions: these are usually related to your prior work, other information on your application, or Ubuntu development policies and procedures. If your application is deferred for some reason, contact the DMB members who were not yet convinced, and ask them to help you develop a plan to meet their expectations: many current Ubuntu Developers were deferred at first pass, but it is a rare case that someone actively involved was unable to complete the expectations within a few months, and for some it is possible to address the outstanding issues in time for the following meeting.

Good luck. If you’re feeling stuck along the way, feel free to ask other developers with whom you work regularly for guidance or suggestions. Failing that, ask generally in #ubuntu-devel at freenode, or contact a member of the DMB.

Originally sent by Emmet Hikory to the ubuntu-devel mailing list on Thu Jan 27 05:01:01 UTC 2011

Linux: pmap command

Sometimes for me, when looking for which libraries was loaded by an application (mainly java libraries) I use on Linux a command that make the work easy; first of all, get the PID of the desired application:

$ ps -ef | grep java
ccardozo  3987 3964  2 11:10 pts/0    00:00:26 /opt/java/bin/java -Dprogram.name=run.sh -server…

Inspect it using pmap command…

$ pmap -x 3987 | grep jdbc
8dc02000       0       4       0 r-xs-  jboss-xa-jdbc.jar
8dc20000       0       4       0 r-xs-  tmp3817347529030789342jboss-xa-jdbc.rar
8dc21000       0       4       0 r-xs-  jboss-local-jdbc.jar
8dc22000       0       4       0 r-xs-  tmp7198301414175265274jboss-local-jdbc.rar
8dc23000       0       4       0 r-xs-  jboss-ha-xa-jdbc.jar
8dc24000       0       4       0 r-xs-  tmp3456161463617988766jboss-ha-xa-jdbc.rar
8dc25000       0       4       0 r-xs-  jboss-ha-local-jdbc.jar
8e600000       0       4       0 r-xs-  tmp9010150622292579202jboss-ha-local-jdbc.rar
8eb80000       0      12       0 r-xs-  jboss-common-jdbc-wrapper.jar

it’s all!