Focus on Software
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.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Build a Skype Server for Your Home Phone System
- Why Python?
- A Topic for Discussion - Open Source Feature-Richness?
- Tech Tip: Really Simple HTTP Server with Python
- Not free anymore
25 min 41 sec ago - Great
4 hours 12 min ago - Reply to comment | Linux Journal
4 hours 20 min ago - Understanding the Linux Kernel
6 hours 35 min ago - General
9 hours 5 min ago - Kernel Problem
19 hours 8 min ago - BASH script to log IPs on public web server
23 hours 35 min ago - DynDNS
1 day 3 hours ago - Reply to comment | Linux Journal
1 day 3 hours ago - All the articles you talked
1 day 6 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
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?




Comments
I couldn't disagree more...
I used to be an avid Windows fan... Not so much anymore. But one area where I see that Linux needs huge improvement is in its configuration and the storage of the configuration.
Ok, let's face it, the Windows registry isn't that difficult to edit or modify. It's actually no more difficult than the 1000s (ok, may be hundreds) of text-based
conffiles you'll find scattered all over your hard disk in Linux (though 75% of theseconffiles are in/etc). Your grandma probably wouldn't want to learn how to read any one particularconffile and then edit it no more than she would want to learn how to modify the registry and edit that.So we have a draw so far: both systems for managing configuration information aren't that bad, but they're not that great. Here's where Microsoft failed with the Registry idea as many Linux users have already expressed: the Windows Registry is an on-disk binary format file that requires special tools to view and edit. If something happens to the registry, you can no longer boot your operating system. This is a real problem. However, just because there is a problem with its implementation does not mean it's a bad idea.
So here's what I'm thinking. All programs that need configuration data could save that data to one spot: the Linux "Registry". This registry, however, would not be binary in format. It would be text-based so that it could be edited with any old text editor. "Ok", you say, "but you're still sticking your eggs all in one basket!" Here's how we get around that: should something happen to the registry, the programs would be designed in such a way that should the registry be unavailable they could look to another agreed-upon location where a configuration file would be stored. "How exactly does this solve the problem?" you ask. "Wouldn't we just have a million configuration files on the disk then, anyway, as we currently do?" No. Here's why: the program's configuration data primarily resides in the registry. Let's say something happens to said registry...now you're "screwed"--or are you? Nope. You pop in a bootable CD, copy a configuration file to the "failsafe" configuration script directory, and reboot. The program tries to read the corrupted registry, but can't...so it falls back to the preset location to find a configuration file. It finds one and reads the configuration and now is able to load. I would venture to say, however, that if your registry is corrupted, there are probably other things on your disk that are also corrupted; so this is not a big deal in the grand scheme of things and solves the problem of "if your registry is corrupted you can't boot and you're screwed".
Here's another area where the Linux "Registry" would be a good idea: most Linux distros adhere to the Linux File-system Base hierarchy pretty closely, but not 100%. This is often because of different technical issues between distros, sheer distro developer opinion, or out of "tradition" of the distro. In other words, Red Hat's file system layout is different than Debian's which is different than Slackware's. This sometimes causes problems with packages because they have to guess where a certain dependency library is installed. Sometimes, the package is unable to resolve the location of this library. The Linux "Registry" could hold the locations of all the libraries installed on the system so that packages could locate them. Also, this could aid in dependency tracking for the installation/uninstallation of software.
I know that Linux has the
/dev,/sys, and/procfilesystems (andconfigfs) for device configuration (and let's not forgetudevd). I'm not convinced that storing this information in the registry is a good idea, but it's certainly worth at least investigating. I do not advocate "hiding" the/devfilesystem/namespace as Microsoft does with Windows, however.Anyway, these are my thoughts. In summary, a Linux Registry would aid in
In the end, there would be a place to store configuration scripts so that, in the case of the registry becoming unreadable, one could place a temporary configuration script should it become necessary. I would be very interested to hear your thoughts on this further. (BTW, I know that back in 2004 there was an attempt at a project to develop a Linux Registry...it didn't look very promising at the outset. I would hope to avoid its pitfalls.)
Regards,
~ Craig