This issue is my last with Linux Journal. Don Marti, formerly technical editor of Linux Journal and editor in chief of Embedded Linux Journal, will be stepping into the role of editor in chief. As you must already know, you will be in most capable hands with Don, and I can assure you it will never be boring.
Few things inspire close human relationships like shared labor. Creating Linux Journal on a monthly basis and tackling the various other projects that come with being on the editorial staff of SSC make for a rigorous schedule and a lot of unused vacation time. As the LJ staff is a small one, we've gotten to know one another quite well. I've come to appreciate them not only for their competence and willingness to go the extra mile, but for their qualities as wonderful human beings. I'm a better person for having worked with them, and I feel confident they will continue to serve the magazine's readers very well.
Though I've been editor of Linux Journal for two years, I have met personally only two of our contributing editors. Yet, working with them on a monthly basis, I feel about them much as I feel about our in-house editorial staff. Many times their help and contributions go far beyond writing their monthly column—though their pay doesn't. I've abused and taken advantage of them, rewarding them with nothing more than my gratitude (I told them all I'd be their best friend) and LJ shwag, and they've accepted it graciously.
On this same page in the 100th issue, I cited the goodwill of the Linux community as something that makes working for this magazine a rewarding experience. That generosity made our 100th issue possible and is one more thing that makes leaving this job difficult. Our authors invest a lot of time and energy into providing information that is both accurate and useful, and believe me, they don't do it for the money. In many of the article proposals we receive, the potential author states a feeling of obligation to contribute to the community as the principal motivation for writing.
Given that our writers are, in most cases, our readers, we have the advantage of getting to know our audience very well. This makes saying good-bye more difficult, but my thanks more genuine.
So good-bye and sincere thanks to the staff, contributors and readers of Linux Journal. It's been a memorable two years.
Richard Vernon is former editor in chief of Linux Journal.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Introduction to MapReduce with Hadoop on Linux
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?