Showing posts with label Linux. Show all posts
Showing posts with label Linux. Show all posts

Sunday, January 15, 2012

What's New in Linux 3.2?

What better way to kick off the new year than with a brand new kernel, fresh out of Kernel.org? Linus Torvalds released the 3.2 kernel on January 4th, with improvements in the Ext4 and Btrfs filesystems, thin provisioning features, a new architecture, and CPU bandwidth control.

The last major kernel release was in late October of last year. That release, if you recall, included support for OpenRISC, Near-Field Communications, and the cpupowerutils project.

Last week, Torvalds pushed 3.2 out into the world with a pretty short announcement and opened the merge window for Linux 3.3. Naturally, this release has the usual fixes and new drivers, but also some notable new features that are worth taking a look at.

Let’s face it, users have an insatiable desire for more and more storage. Which means larger and larger hard drives. Unfortunately, the maximum filesystem block for Ext4 systems has been stuck at 4KB, which is a bit of an inconvenience for users who are working primarily with larger files. With the 3.2 release, users can increase the block size to a maximum of 1MB.

Btrfs has seen a fair number of small improvements with 3.2 as well. For example, Btrfs now gives more detailed messages when it encounters bad blocks or other errors. In addition, you can now do a manual inspection of the filesystem, so you can query Btrfs about what files belong to bad blocks.

Linux adding a new architecture is not unusual, but the Hexagon Processor from Qualcomm is a bit different. Most of the CPUs supported by Linux are like the x86/AMD64 architecture that most of us use in our desktop/laptop machines or servers. (“Like,” in that they are for a wide range of general purpose machines.)

The Hexagon is a “general-purpose digital signal processor designed for high performance and low power.” It can be used for things like processing video, or could be used for the OS and digital signal processing. You probably won’t be running Linux Mint on this one anytime soon, but it might be in your next set-top box or something else that requires a lot of processing power for media but not general purpose computing.

On the TCP side, Google really wants to get search results to you a bit faster. So much so, in fact, that they have developed a better packet recovery algorithm for TCP. Google’s algorithm, “Proportional Rate Reduction,” is meant to improve latency.

As time goes on, the Linux kernel just gets more and more flexible when it comes to fine-tuning resource control. The 3.2 kernel has two notable features that will be very useful in this regard.

The first is the CPU bandwidth control, which allows admins to specify how much CPU time a process group can use in a period of time. For example, users could use the scheduling features to limit a group to N CPUs runtime in a specific period (measured in milliseconds), or limit groups to a fraction of a CPU. When the group hits its limit, it’s scaled back until the next time period starts.

For instance, you could give a time period of 1000ms and a quota of 1000ms. That would give a group 1 CPU worth of runtime. Or you could give the group a quota of 100ms with a time period of 1000ms, which would limit the group to 1/10th of a CPU runtime.

The second feature allows over-provisioning of storage so that space isn’t wasted. Wait, what? How is over-provisioning a good thing?

Imagine you have a system with 500 users given a storage quota of some arbitrary amount, like 15GB. You give each user the maximum amount of storage you think is reasonable or necessary, but the odds are in many cases that users will only use a fraction of the storage. For instance, in a lot of Web hosting scenarios you might provision users with 10GB of storage but in reality many users are only going to use a few hundred MB, not 10GB.

The thin provisioning features added to the Linux Device Mapper allow admins to over-provision, so you don’t have to have enough storage to cover the maximum storage scenario. This allows companies to avoid spending a lot of money on storage that they don’t need – an especially nifty feature now, considering the rising prices of hard drives.

Kernel development never sleeps, so while 3.2 is making its way out into the world kernel folks are busily hacking on 3.3 and beyond.

One of the more interesting features that we might see in 3.3 (remember, no promises) is a lot of Android integration. Greg Kroah-Hartman wrote in mid-December that “the next linux-next Linux kernel release should almost boot an Android userspace, we are only missing one piece, ashmem, and that should hopefully land in my staging-next tree next week. The patches are still being tested and cleaned up by others… hopefully, by the 3.3 kernel release, the majority of the Android code will be merged.”

That won’t mean a complete Android kernel in mainline Linux. Hartman says that there’s still more work to do, but it’s significant progress nonetheless.

By the way, if you’re into “ancient” kernels, Kroah-Hartman also released the 2.6.32.53 kernel on Friday, January 6th.

Comments (0)Add Comment
You must be logged in to post a comment. Please register if you do not have an account yet.
busy

View the original article here

How to Craft a Killer Cover Letter for Linux Jobs

You're certified, bona fide, and active in your favorite open source project, but how do you craft the clever cover letter that lands your next Linux job?

If you're lucky, your reputation precedes you and dream job offers land in your in-box every other day. If you're like the rest of us, a well-crafted cover letter can make the difference between getting a phone call, or getting shuffled to the bottom of the resume pile. Before prospective employers look down the list of Linux skills and open source project experience you've laid out on your resume, they'll do a quick read of your cover letter, which is your one chance to make a fabulous first impression.

I've long hated writing cover letters. Once you've written your resume, it's pretty much good to go, with occasional updates or tweaks to highlight skills that would appeal to specific employers. Cover letters, on the other hand, need to be written with a specific employer or position in mind. And knowing that these few paragraphs need to say more than your resume does can be nerve wracking. With a few rules in mind, you can take the torture out of writing and focus on why you are the only logical solution to an employer's high-tech needs.

First, the good news: No one wants to read your dissertation. Instead, keep your cover letter brief, yet meaty (like this rule).

Before writing anything, research the company and position for which you are applying. Read the press releases on the official company site, search the web to learn more about what others are saying about the company, and consider how your skill set will be an asset to the employer. Remember that the employer wants to know how you will meet his or her needs, so don't focus on why this job would meet your needs (unless your needs are all about focusing on the needs of your prospective employer).

In her Dice.com article called How to Target A Cover to Get the Manager’s Attention, Leslie Stevens-Huffman explains, "Don't belabor points or regurgitate the information in your resume. Create a short, compelling narrative that proves you understand the company’s needs and describes how you intend to meet them."

Gayle Laakmann McDowell, author of The Google Resume and Cracking the Coding Interview, says that how you discuss your open source work depends on the type of job for which you are applying. "If you're applying for a coding role, you should focus on the code you wrote (that is, the features)," she says. "If you're applying for a Program Management job, you should focus on the leadership aspects."

Instead of going into detail in the cover letter, you could put this open source experience under a Projects section of your resume or under Work Experience, particularly if you've spent a substantial amount of time on an open source project. "Additionally, providing a link to your GitHub page or another page where a resume screener can learn more about your coding experience is always useful," she adds.

"As a hiring manager for software engineers, I'm always happy to see that a candidate is a contributor to open source projects," says Jenson Crawford, Director of Engineering at Fetch Technologies. "Participation in open source projects tells me that technology is a passion for the candidate and it's not just a job. It also shows that the candidate is interested in making things better than they were found," he says.

Crawford agrees with McDowell when it comes to including open source experience on a cover letter. "If a candidate's open source contributions can demonstrate that the candidate has the needed qualifications or experience, include the contributions to make the connection to the hiring company's needs," he explains. "If there isn't a direct connection between the candidate's open source contributions and the qualifications listed in the job posting, or if the candidate is applying to a company without a specific job posting, include information about the contributions in a general way. Perhaps something like: I'm passionate about technology and contribute the open source projects X, Y, Z."

Let's say you are applying to be a web developer and you're interviewing for a company that requires Drupal experience. Here's your opportunity to show that you've researched the company and have the exact skills they seek. The job description says:

Experience with and a high degree of competency in Drupal is a must, including development of modules and themes, and familiarity with the Drupal API, hook system, form API, etc.

So your response to this job requirement might be something like, "In addition to developing more than two dozen Drupal modules and themes for my current employer, I'm also active in the Drupal community and recently gave a DrupalCon Lightning talk about submitting patches." Now the prospective employer knows that your resume includes required skills, but you've also added something more personal about your specific skills, which brings us to the next rule.

Showing your personality in a resume is no easy feat, so be sure to do it in your cover letter. "Not only do you want to show that you're a good fit for the position, but you also want the reader to like you," explains Kim Isaacs, Monster Resume Expert. "Appropriate use of humor, combined with a friendly and professional tone, can help endear you to the hiring manager." Still, keep in mind that the cover letter is a formal document and not an email to your BFF, so keep the tone professional, too.

If you're sloppy on your cover letter, employers can safely assume you'll be sloppy in your code or work habits. In addition to spell checking your letter, consider having a friend or colleague proofread it, too. Reread the job description and your letter — have you shown that you understand the position for which you are applying and that you're the ideal candidate for the role?

You have as long as you need to proof the cover letter before sending it in, so be sure that it doesn't make a trip to the circular file because it's sloppy.

If you're not quite ready to apply for that great Linux job, consider ways to get involved in the community at events or with Linux training opportunities.

What other advice do you have for crafting clever cover letters? Share your success stories (or horror stories) in the comments below.

Comments (0)Add Comment
You must be logged in to post a comment. Please register if you do not have an account yet.
busy

View the original article here