The Linux kernel community learns how to grow more penguins

No readers like this yet.
Hands together around the word trust

The Linux kernel is one of the largest and most successful open source projects today.

report from the Linux Foundation addressing Who Writes Linux (2013) shows that recent releases of the Linux kernel, that happen now at 70-days intervals, include over 10,000 patches, made by more than 1,100 developers, representing over 225 corporations.

Since April 2012, when the previous report was published, almost 92,000 changesets have been merged from 3,738 individual developers representing about 536 corporations, adding close to 2 million lines of code. Cumulatively, the Linux kernel has been the work of more than 11,000 developers collaborating for more than 20 years.

This level of participation and volume of activity is unprecedented, and serves as a model to which most open source projects aspire to. Time has truly been good to Linux and the kernel community, and with time inevitably comes change. This a good thing.

One change happening now to the Linux kernel community is a shift in the demographics of the members.

At a panel held during the Linux Collaboration Summit in 2010, Jonathan Corbet, editor in chief of the Linux Weekly News, asked a group of top Linux kernel developers: "Is the Linux kernel developer crew getting too old?" He was observing the sizes of subsequent generations of developers.

More recently, an analysis of contributions to the Linux kernel Git repository, by software development analysis company Bitergia, revealed that: 

  • Generations are smaller and smaller from about 100-150 (in 2005) to 30-50 per quarter (2013)

  • Older generations are becoming less active

  • Younger generations are quite smaller now than they were six years ago

Maintaining the vitality of this large community does not happen spontaneously. On the contrary, it requires dedication and attention by community members on how to bring new contributors on board, and how to train them and integrate them alongside the well-established developers.

As Jim Whitehurst (Red Hat CEO) put it a recent blog:

Just because people have participated in the past, doesn’t mean they will participate in the future. Engagement has to continue to be stoked and nurtured for participation to be sustained. 

So the Linux Foundation, and others in the Linux community, are undertaking initiatives to bring in new developers to participate in the kernel. For example, reaching out to hobbyist developers to attend the kernel Summit, and adding to the LinuxCon program of activities such as:

  • The newcomers reception: "to give new attendees the opportunity to meet some of the key Linux kernel contributors"

  • The Women in OSS luncheon: "a networking opportunity for women in open source to connect and learn from each other"

  • Scholarships for women who want to attend LinuxCon and CloudOpen but are not sponsored by a company or do not have personal funds to attend

The 2013 report from the Linux Foundation, also mentions that:

The kernel project participated in the Outreach Program for Women for the first time, leading to 41 applications for 7 available positions. During the application process, 374 patches were submitted to the kernel, and over 1/3 of those patches were accepted in the 3.10 kernel release. The intern process is now underway, but the results of that will not start showing up until future kernel releases.

The Outreach Program for Women has been so successful that its contributions to the version 3.12 of the Kernel rank 11th, by number of lines of code, among the top contributing organizations; above IBM and Samsung, for example.

One important aspect of these initiatives is to reduce the barriers of entry, technical and cultural, for new developers to join the Linux kernel community.

A great example is Greg Kroah-Hartman, one of the main developers of the Linux kernel and current maintainer of the stable branch (among many other duties), who wrote the book Linux Kernel in a Nutshell. Greg explains:

I want this book to help bring more people into the Linux kernel development fold. The act of building a customized kernel for your machine is one of the basic tasks needed to become a Linux kernel developer. The more people that try this out, and realize that there is not any real magic behind the whole Linux kernel process, the more people will be willing to jump in and help out in making the kernel the best that it can be.

Greg also observed that many Linux kernel projects, such as his own Linux Driver Project, require little from developers to start, except that their device drivers have the right open source licensing and that their software will compile. Specifically, there's

No barrier to entry into getting code in the staging-tree kernel.

A natural way of promoting the participation of younger people in the Linux kernel development is to reach out to colleges and universities to host training activities where students and faculty learn the ropes of how to contribute to the kernel. This can be particularly focused on understanding the processes and navigating the governance of the kernel. In collaboration with other open source enthusiasts, we have introduced training activities in two college classes that I'm teaching now, and will provide feedback of the experience on

User profile image.
Luis Ibáñez works as Senior Software Engineer at Google Inc in Chicago.


For so long as the individual in charge of the project as a whole is a rude, vindictive, arrogant, bigoted and abusive so and so... No one from my generation will have any interest in being involved on any significant level, and many will be deterred from any participation at all. The Linux community suffers from his, and his direct subordinates entrenchment in the community. Their toxicity is something felt by all involved, heard by everyone with even a passing interest in technology news, and serves to stymie developmental progress and participation by making anything seem like a better alternative than be stuck with someone like that as a boss.


As an older guy on his early 40's here I agree with your point, but I feel forced to elaborate a bit on it.

The older generation, those now in their 60's were more productive in their 20's than my generation and my generation in it's 20's and your generation is less productive than both previous generations.

It is not a matter of employment that I know many of you guys lack opportunities, I talk about productivity when you get the job you want to work with.

That happens because my generations this thing of political correctness was starting and we were shamed to not express ourselves in many aspects. The current younger generation steps in eggs all day long and thus produces next-to-nothing.

It is like a woman that produces herself for 8 hours for a 40 minute dinner and then go home. You are worried more by superficial aspects, not by getting things done. You are the guys that would hire a white buddy that claims how he loves asians but would not hire one that claims how he loves his white girlfriend.

Because das racis.

And then you have only yourselves to blame for the inefficiency, corruption and decadence that will befall your generation and after, because instead of the competent, you selected the one with best appearences according to your prejudices.

I am an operating system developer, age 68. In my 20s I worked on something called a nucleus instead being called a kernel. I take a somewhat different view of the productivity of the generations of kernel coders.

I think that any person working at an intellectual job is more productive and brilliant in their 20s than when they are older. As people age their mental facilities decline. Everybody notices this in old people. (Now what was I talking about, oh, yes.) But when a person is working to the top of their intellectual ability then the decline begins to be noticeable in their 30s. This phenomenon parallels physical decline. Everybody notices that old people become physically decrepit. However the physical decline of professional athletes in noticeable once they reach about 30.

Another consideration is that there is a wide range in individual intellectual abilities just as there is a wide range in people's physical abilities. I don't think that the range of intellectual abilities in the current crop of 20 something people is any different than it was in my hay day. In looking back at my generation of kernel developers we don't remember the mediocrities. We remember Ken Thompson, Brian Kernighan, and Dennis Ritchie. If we compare today's average kernel developer to Thompson, Kernighan, and Ritchie then of course the current generation comes off second best.

I think that the current generation of kernel developers compares fairly well with previous generations. Most people are mediocre and a large portion of the important work is done by a few superstars. Fifty years from now people will only remember the current superstars. So who are the current superstars?

Steve Stites

I was trying to compare the generations in their 20's.

It is not that the current generation lacks the capacity shown by previous generations, sorry if I didn't make that clear, but that political correctness hampers considerably the debate of ideas.

It gets to a point there are so many "quotas for minorities" to fill that you end up with a bunch of incompetents and you are forced do close business.

We should hire the competent and only the competent, no matter what, sometimes I puke just by remembering the smell of some colleagues that didn't like shower, but they were competent and earned their place because they did what they had to do, appearences not entering the equation.

Letting political correctness enter the IT industry will make it grind to a halt. I don't want to work with a bunch of pinkos, I want to work with good coders.

Well, as long as you don't want political correctness, I won't hesitate to point out that that's on one hand a ludicrous irrational notion with no data backing it up, and on the other hand pretty dang fascist.

Fine grandad, when you were young men were real men and women stayed in the kitchen where they belonged and nobody was going around hiring darkies. Whatever, go have your nap, OK?

Actually, when I went through system programming school the majority of students were women. The Viet Nam war was sucking up most young men at the time.

There were a few black people in system programming at the time but they were exceptional as segregation was still in full force at the time.

Steve Stites


Thanks for the insightful comment.

Your point is well taken about the differences in skills at different ages, and the fact that we tend to remember the outstanding participants and forget the rest.

Overall, when communities grow beyond certain size (I would speculate 200 developers), it becomes very important to have a diverse population, that mixes older developers with younger ones, as well a diversity of gender, nationality and educational backgrounds. That combined diversity nourishes the intellectual capacity of the community.

I would avoid stating that some of them are "better" than others, since, it is their combined diversity what makes the community function. In organic terms, we probably wouldn't say that bones are more important than muscles for an athlete. It is not much use to have ones without the other.

That being said, just to address your point: It is tricky to define what "superstars" are, but, if we suggest some quantifiable measures for the Kernel community, we can attempt to answer your question based on:

1) Number of commits contributed
2) Number of lines of code contributed
3) Number of patches reviewed

For those three questions, we can find answers in the Linux Foundation report:

For example, in page 7 and 8, we find:
"The top thirty developers contributed just over 18% of the total", and the tables with the list of developer's names who will be in this top 30, if we measure since the release 2.6, or whether we measure since between 3.10 and 3.12.

Then in page 10 of the report we find the top reviewers. An interesting table that also shows how the community has become more participatory, and relying on a wider number of developers. For example, Linus Torvalds only signed-off in 0.7% of the patches, while Greg Kroah-Hartman does the most sign-off with 12.7%.

A full list of contributors can be found by using scripts that harvest data from the Git repository of the Kernel. You will find this at the end of the report, citing the “gitdm” tool, written by Jonathan Corbet: git://

What we know for sure is that the Kernel can use a lot more of new and younger developers, and that there are plenty of easy patches for them to work on as they learn the ropes. Relating these new developers with more experienced developers is part of the recipe for success. This is one of the things that started to happen at LinuxCon, and probably will continue on a regular basis.

"That happens because my generations this thing of political correctness was starting and we were shamed to not express ourselves in many aspects."

I agree that political correctness has stifled intellectual achievement to a certain extent. I went to college just as political correctness was becoming entrenched in the academic world. In my experience political correctness has been a major drag on intellectual and social progress. The current example of political correctness run amok is the climate change political movement.

Steve Stites

The current example of political correctness run amok is pretending climate change deniers need to be engaged as if they were something other than a sort of heavily funded flat-earther cult.

Steve, posting political views you know many will disagree with pushes people away from your community.

Your point is well taken, and your sentiment is shared.

We have talked often in this forum about the need for mastering soft skills, as a key requirement for fostering the growth and prosperity of an open source community.

This is certainly something that we all can do better in the communities that we participate in. It actually takes training and discipline to be mindful of the human sensitivities in communities.

That said, the popular perception of the Kernel community being harsh, is mostly nourished by the few colored posts from the Linux Kernel Mailing List (LKML: that make waves in the websphere.

The daily reality of the Linux Kernel community is a friendlier and calmer one. One has to realize that the LKML carries more than 17,000 emails per month. (see for example the flow of this last October: This is about 550 emails per day (see for example, today Nov 12: The vast majority of these messages are polite and civilized, and talk about ... well... programming. Out of this collection of thousands of messages, a few, from time to time, go viral and make news, while a massive amount of work from over 1,200 developers flows quietly, in the form of 11,000 patches, into a new release every 70 days.

The efforts for bringing younger generations into the Kernel community (or any other open source community for that matter), would have to focus on creating a safe, friendly and *fun* environment where newcomers are welcomed, and where they can learn the ropes and hone their skills progressively. A great and successful example of one of such initiatives is the Outreach Program for Women [OPW: ]. Where a team of seven interns emerged victorious from the training experience, and became, as a group, the 11th largest contributor to the Linux Kernel release 3.12.

Another important point to grasp is that there are a large number of easy patches that are needed in the Kernel, and that are waiting for newcomers and beginners to work on. These patches can be used as training exercises with relatively small effort.

We will write about similar efforts in a follow up post, where we will talk about training exercises we did for Linux Kernel contributions at two colleges.

...also agree, it is very disappointing to see this abuse taking place. Someone needs to be sent on a leadership course...

f*** you, the linux community needs no moaning *******

And this, ladies and gentlemen, is a live example of Linux community!

Yeah, no.

That is when you screw up badly and you deserve it.

Remember that nerds value competence, not manners. If you wish manners, please get your ass to an hairdresser's course and live merrily.

We have a very serious job to do, if you cut hair wrong at most you will hear some screams and be badmouthed in your town, if we screw up, people may die because of it.

For example,

We don't express ourselves this way when we are creating the conditions for growing a healthy and prosperous community. :-)

The reality on the ground is that the large majority of the conversation in the Kernel Community is flat focused on the code (this is about 17,000 emails per month! : It is true that from time to time there are colorful messages in the community, and they receive a great deal of attention, exactly because they are out of the ordinary. It is not glamorous to report that "Today 650 emails were processed in a civilized manner in a mailing list...". (Granted... probably not all of them went through without their own struggles).

In the meantime, a massive amount of activity happens quietly, and goes mostly uncovered by the online news, except maybe when we look at the annual reports that the Linux Foundation publishes on the enormous level of activity that goes on every release of the Kernel ( For example: In the past 12 months: 2 million lines of code were added to the Linux Kernel.

There is certainly room for many new developers from all sorts to join the community and contribute in their own capacities. In the process they gain experience, develop skills, and the Kernel gets better and better.

This comment was edited to adhere to our Community Behavior Rules which every registered user and commenter agrees to via the site terms and conditions. This comment is on the verge of being removed. We don't tolerate this type of behaviour here on

"You may not post or link to content that is threatening, abusive, defamatory, libelous, derogatory, violent, harassing, bigoted, hateful, profane, obscene, lewd, lascivious, pornographic or otherwise objectionable, that gives rise to civil or criminal liability, or otherwise violates any applicable law."


>This comment was edited to adhere to our Community Behavior Rules ...

Jesus, this is 1984 ipisis litteris.


My comment stating the obvious was deleted for what? It didn't go against any of your rulings.

Stating that you act like 1984, censoring people, is now prohibited by your legal framework too? Can't I complain of your censorship because of what?

Doing such things is as much detrimental to Linux as allowing people to use too many expletives.

If you censor reasonable debate you go totally against what Linux stands for and which you seemed to defend. We don't need your Politically Correct dictatorship. Go do something more useful.

It looks like it was flagged for spam.

We definitely encourage conversation, but on this publication and community, we are going to keep it clean and promote having healthy debates.


Nope Jason,

The message showed up for some time and then you made it disappear.

I've seen you are into marketing. Well, it is expected that telling the truth is not part of your job description, lol.

The more interesting stuff will happen in user space anyway. That is where talent is needed.

It is true that a lot of interesting activity happen in user space, and that talent will be welcomed there.

That said, this shouldn't deter newcomers from taking a peek at the deep Kernel. There is abundant material on easy patches to be done all across the board, and many of them are within the reach of beginning developers. Such patches are excellent material for training new developers.

The work load distribution of open source projects follow the long tail of a power log. This is the 80/20 rule, where 80% of the work is done by 20% of the people ( Which doesn't diminish the importance of the 20% of the work that will be done by 80% of the people, particularly because this is how they will be trained so that some of them become part of that 20% that makes 80% of the changes. In other words, the shape of long tail in the distribution is also a prediction of the demographics of the community across time.

Therefore, there is room for thousands of contributors to make minor changes that could be just a couple of lines of code. These are changes, that more experienced developers could make, but that will distract them from dealing with more complex issues. There is therefore a continuous opportunity to match developers' skills to challenges of specific level, and to create the conditions where everybody wins. The beginners improve their skills, and the code base get better at the same time. This is an ideal situation to use real Kernel patches as training material for any programming classes, and in particular, those on operating systems, or on large software systems.

Luis, thanks for writing this interesting article. I have to agree that some of LInus's more colorful post have been shared all around the internet. That has also kept me away in trying to participate. However Could you follow up with how to get in touch with developers in this community.

I have been a Systems Admin for now 13 years (Starting when I was 17) administering Linux, AIX, and HP-UX and now I find myself very interested in Kernel programing. However I know very little C and currently learning Python, I also don't have any formal programming training on Data Structure and Algorithms..

I also know user space and Web has most of the attention now but kernel programming has been an interest of mine for some time. The problem is that I am looking for a developer that can show me the ropes. I live in Nashville TN and struggle with searching for a mentor.

What advice would you have for someone like me to get started? What books do you recommend, where can I find a good mentor to take me under his wing like an apprentice ship?

I ask because you appear different than the normal people I have ran across with your answers. Normally you get the very gruff person who says go find a project and just start coding. Which is similar to the people that just say RTFM.



Thanks for your comments.

Your point is the perfect transition to the follow up post where we will be describing a set of training activities that took place a couple of weeks ago at the Rensselaer Polytechnic Institute, the Rensselaer Center for Open Source (RCOS) and at the State University of New York at Albany. They were focused exactly on what you are looking for:

"How to get an easy introduction to participating in the Kernel community"

The activities were driven by an enthusiastic team from Red Hat, composed of: Matthew Whitehead and Priti Kumar.

Here is the online version of the material that we used for these training sessions:

This was done with Reveal.js (which we talked about recently here:

The source materials of these training slides are here in Github:

Note that the slides go to the right, and sometimes up / down.

The central point is that:

"It is easy to participate in the Kernel community"

and the key is to start with easy patches.

The presentation above focuses on walking you through the process.

It covers:

A) An easy introduction to Git:
(slides going downward)

B) How to get the source code
(slides going downward)

C) Quick overview of the review process:

D) Easy patches that we did with students:

E) The process of patching:
(slides going downward)

and also

F) References to other materials

In particular, you will find useful the book

Linux Kernel in a Nutshell
that has a full PDF free download (at the bottom of the page):
and the sources are also in Git:

Note that (on purpose),
the patches used in this exercise are very easy ones:

things like replacing "printk(...)" with "printk(KERN_DEBUG....)".

In this way we were able to focus on the process of submitting the patches and not worry about the software architecture of the Kernel itself.

There are thousands of these easy patches, waiting for volunteers to work on them. As Linus Torvalds put it:

"...the trivial patches are among the most important ones -
exactly because they are the "entry" patches for every new developer. ”

We did the exercise with the students using an Ubuntu 13 VM in Amazon EC2 (Using a grant that Amazon kindly provided to SUNY Albany). The setup in the VM was not fancy at all. Just needed to install several development packages. (will be glad to provide a detailed list). I can also point you to a public image of the VM if you would like to clone it.

Please give it a try at the tutorial above, and please share your feedback on what can be improved on it, to make it more accessible, and in particular: more *fun* ! :-)

The process is indeed very easy, so, if anything is confusing in the materials, it will just mean that we haven't got the content right, and therefore we have to fix it. So please don't hesitate to point out any kinks.

Thanks !

Actually if you don't mind would you please provide the list of development packages and the location to the vm.


Here are the commands that we used for preparing the VM:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install tmux

We followed these instructions

sudo apt-get install fakeroot build-essential
sudo apt-get build-dep linux
sudo apt-get install git-core libncurses5 libncurses5-dev libelf-dev asciidoc binutils-dev
sudo apt-get install git-email

The AMI in AWS is: ami-8faaf7e6

Then, the instructions for getting the source code are here:
(slides downward)

Let us know if you run into any issues with any of the pieces.

Thanks !

Thanks Luis. I never really thought about doing just patches to get started. However when thinking about it, that is exactly the type of advice I have been looking for.

It reminds me of exactly the old style apprenticeships where the Master would say before you build a whole sword you must first start here(Such as stoking the fire to get a good heat.)

I will try and work through them this week and next week. I am a very slow reader so it will take a few. But once I am done, I am guessing that somewhere in those documents will be a email address that I can responds back to with comments.

Again thanks for helping people like me get started. I am actually pretty jazzed up about being able to finally get started.

Yes, there are those sentiments in some, but certainly not all.

I am a girl, in my 20's. My kernel experience is primarily on ARM devices and making pieces/patches for new ARM devices.

One of the key issues is that the CS grads are not being pushed into embedded or OS. Its not "cool" or flashy. You typically won't become highly desirable by making a patch to enable a new bus as you would for making an HTML5 or Mobile App that you can Demo to potential companies. Its not a skill set in high demand like application development or integration.

The core subset is getting older. I was just at an embedded linux meeting last night and there were 3 people in their late 20's in a group of 30ish. Most were 40-70 and a couple of people in their 30's. Another thing to think about is that more has been done and just understanding where to add and change is much more involved than it was 15 years ago even.

Core competencies like C and Assembly code are not being taught in your average university more than 1 class. Operating Systems is often not required unless at a top university. That limits the subset of people who can even start to know how a kernel works unless they do so on their own.

Lets talk about some of the people in the community. There are a lot of "pros" and complete noobs just learning about "dd". There are not many who participate that are inbetween. The inbetweeners get boo'd by pros.

Much isn't documented in the lower levels either, especially in a way that can be taught to gifted college students.

Believe me that the problems that have plagued the Analog EE and HAM Radio worlds are the same with Operating Systems. The Baby Boomers did not pass it on. The young ones can learn from the "pros" if you probe them enough. However, it is an intensely personal thing and internet forums are not personal.

You want to learn, find someone in the IRC channels and talk to them. Spend most of the time listening. You will be amazed.

Excellent point Stacy,

You should consider it by another angle, though: how much do you think you can earn once the boomers stop making the basic infrastructure and very few are available that can tackle the problem?

There is enormous opportunity there. App developers there's a dime a dozen, those people will be like the cobol and clipper programmers of the past, they will earn nothing and will be repleaced in the blink of an eye.


You make a very good point,
and it also extend to a lot of infrastructure projects that are now maintained by developers who may be retiring in 10 or so years. Which is barely the window of time that it will take to pair them with younger apprentices so they can mentor them and train them to the point where the youngsters are able to continue maintaining and improving the infrastructure.

One interesting example is:

VistA: The EHR of the Department of Veterans Affairs, which has been widely accepted as one of the most advanced medical records system, but that is also suffering from a lack of younger demographics in its developers community.

If in the context of the Linux Kernel we are concerned that not enough Universities are teaching C, in the case of VistA we are concerned about only a couple of Universities teaching MUMPS, and this being the language used, not only in VistA at the VA, but also in DoD hospitals with CHCS, and in most of the commercial EHR systems, including EPIC. These systems are running in hundreds of hospitals, providing care to millions of patients, and therefore are at the core of critical infrastructure.


I appreciate your point of the importance of building personal connections between the experienced "pros" and the newbies, so that the experience can be pass it on. Fully agree with you in that online communications are insufficient, and that documentation (although useful) can't serve as replacement for that face-to-face interaction.

I have found that bringing people from industry, as invited speakers to classes, helps a bit to create such connections. It is certainly not sufficient, but it is a starting point. Experienced professionals always appreciate the opportunity to talk to younger people and share what they know, while at the same time students enjoy hearing about the "real world" from speakers other than their professors.

Such connections could be extended through HackerSpaces, which I think is something that every University should have, and where local experienced professionals should be involved. This type of informal and unstructured education is a very effective way of "passing on" experience to younger generations.

Ulrich, I agree with you.

I can say that when looking at people to join in my group, that having a solid C background matters.

If you cannot make a library or driver , I have no interest in your Java, C#, HTML5, etc. That may be what is really needed.

So many times issues exist deeper than people realize and "what do you do when the API is broken?".

One possibility here is that also CS does not include ANY requirements of EE. Knowing your hardware and how it works matters, it was par for the course 30 years ago. Now, that level of knowledge has been made into a new degree, Computer Engineering, which also has a focus on computational chip design.

Computer Engineering is also typically one of the hardest engineering majors and not offered at many universities. Companies will try to "lob" CE's into more traditional CS or EE roles when really it should be considered more of an "Embedded Computing", but it is also versitile.

My program I went through was CE and was basically: skip all the beginning coursework of CS and EE ; jump right to the later 200 and 300 level. Complete the highest requirements for both degrees and take 4 courses in Chip/Logic/OS design. The GPA of a CE student will be lower in most cases as they had no "padding", much like your typical Chemical Engineering coursework. It requires deep knowledge of two or more Engineering disciplines.

So maybe here the solution is for the community to make fundamentals fundamental again. Its hard because Deans want shiny programs to show off and impatient students want quick satisfaction.


Thanks for the insightful comments.

I fully agree with you, particularly on the importance of having some understanding of hardware, when it comes to being able to write drivers and low level APIs.

The current popularity of the Raspberry Pi, and similar inexpensive boards (such as the Beagle Bone), provide a promising venue for educating this new generation of engineers who are literate in the continuous range of topics from electronics, controllers, low level interfaces, drivers, and operating systems.

Some Universities see the value on these programs. For example here is the adoption of Raspberry Pis in replacement of textbooks at SUNY Albany:

Your point is well taken, that many University programs are rather interested in the shiny mobile apps that make for great demos because they are highly visual and accessible.

To learn more about "Basic Data Structures and Algorithms in the Linux kernel". See

Link found on hackernews. See


Thanks for sharing these links.
They look very useful indeed !

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.