SOURCE
By: Don Reisinger
2009-07-24
NEWS ANALYSIS: Open-source software is coming to the enterprise in a big way. Is it time for companies to start considering it? What does this mean for Microsoft Windows?
Open source. It's the fruit of much labor by many people. It follows the tech world's latest trend of wanting everything and anything to be "open." It could also be a boon for the enterprise.
Open source, by its very nature, makes a program's code available to companies, consumers, or organizations to modify it as they wish. It's a great concept. It means that the community can put more eyes on issues, helping patch security holes sooner. It also means that the software could become more robust as people find unique ways to exploit the code. Microsoft, a company that has stayed notoriously closed since its inception, has said that having a handful of experts constantly searching for security holes in software is more reliable. It's a self-serving comment. And one that probably doesn't hold up too well when we consider the security of Linux, an open-source platform, compared to Windows.
More companies are realizing that. So, they're becoming more willing to release open-source software. Google's Chrome OS will be open source. IBM announced recently that a new "Office in a Box" concept will be open source. Even Adobe is getting in on the action. The company announced recently that it has open-sourced some Flash components. For more about open-source software, please click here.
So, it seems the market is pushing companies toward open-source applications. But are they really best for the enterprise? Every situation is different, but one thing is certain -- companies should consider adopting open-source applications in their operations. Here's why:
1. Trust the community
Some trust needs to be placed in the community. With open source, the users of a respective application are constantly finding ways to improve the software. Some of those people might have far more knowledge than a handful of people collecting a salary from a developer. The community has a vested interest in improving the software. Trust it.
2. Updates come sooner
There's nothing better than having software that's updated constantly. With open source applications, that's possible. As long as a company is actively engaged in the community, the software it's using is far more likely to be updated. Whether it's a security hole that needs to be patched or some added features that the community wants, open-source development cycles tend to bring the updates sooner.
3. Customization
Open-source software allows companies to tailor an application to meet its desire. So, if a company wants to add a feature to a software package or eliminate some extras, it can. That's not possible in closed applications.
4. Cost-effectiveness
Although many open-source applications aren't free, they are more cost-effective, in general, than their closed counterparts. Open-source software tends to be cheaper, since the developer doesn't need to focus on support or development as heavily as it would with closed platforms. It saves them some money, which is then transferred to the end user.
5. Security
Open-source software tends to be more secure. Whenever a security outbreak occurs, it can take as little as a few minutes for someone in the community to develop a patch and release it to the others. There's power in numbers and the open-source community relies upon that to keep everyone safe.
6. Design matters
In a closed application, design isn't always best. And since it's closed, companies will need to suffer with the poor development. In an open-source environment, the same isn't true. Sure, there are some bad designs, but for the most part, companies can tweak the application's look and feel to make it a little more user-friendly. That's refreshing.
7. Simple license management
One of the biggest issues many IT managers face with closed platforms is license management. How many legal downloads can a company use before it needs to buy yet another license? With open-source software, that worry is practically eliminated. Companies can download the software once and start adding it to computers network-wide. Of course, this isn't universal and there are some open-source applications that break that rule, but license management is not nearly as major of a concern as it is in closed environments.
8. Support is everything
Although closed-application developers contend that they provide better support, those claims aren't quite accurate. In an open-source environment, users can query the community, which, in most cases, provides outstanding feedback in little to no time. I've found that open-source support is superior to closed support.
9. High-quality software
For the most part, open-source software is robust, reliable, and of higher quality than many software applications available from developers who keep their programs closed. It's quickly becoming trusted in the enterprise.
10. It's the future!
More and more companies are moving to open-source software. Google is leading that charge, but as major enterprise players like IBM, Adobe, and even Microsoft keep moving that way, it could only be a matter of time before most (if not all) enterprise software turns to open source.
Make sure you're ahead of the curve.
SOURCE
Wednesday, July 29, 2009
Sunday, July 26, 2009
Troubleshooting Ubuntu Server
By Kyle Rankin and Benjamin Mako Hill
Jul 24, 2009
Sample Chapter is provided courtesy of Prentice Hall
SOURCE
This chapter covers some of the general steps you can take to isolate the cause a wide range of Ubuntu Server problems and work out their solutions.
Jul 24, 2009
Sample Chapter is provided courtesy of Prentice Hall
SOURCE
This chapter covers some of the general steps you can take to isolate the cause a wide range of Ubuntu Server problems and work out their solutions.
Troubleshooting is a topic that is near and dear to me. While there are many other areas of system administration that I enjoy, I don’t think anything compares to the excitement of tracking down the root cause of an obscure problem. Good troubleshooting is a combination of Sherlock Holmes–style detective work, intuition, and a little luck. You might even argue that some people have a knack for troubleshooting while others struggle with it, but in my mind it’s something that all sysadmins get better at the more problems they run into.
While this chapter discusses troubleshooting, there are a number of common problems that can cause your Ubuntu system to not boot or to run in an incomplete state. I have moved all of these topics into their own chapter on rescue and recovery and have provided specific steps to fix common problems with the Ubuntu rescue CD. So if you are trying to solve a problem at the moment, check Chapter 12 first to see if I have already outlined a solution. If not, come back here to get the more general steps to isolate the cause of your problem and work out its solution.
In this chapter I’m going to discuss some aspects of my general philosophy on troubleshooting that could be applied to a wide range of problems. Then I will cover a few common problems that you might run into and introduce some tools and techniques to help solve them. By the end of the chapter you should have a head start the next time a problem turns up. After all, in many organizations downtime is measured in dollars, not minutes, so there is a lot to be said for someone who can find a root cause quickly.
General Troubleshooting Philosophy
While there are specific steps you can take to address certain computer problems, most troubleshooting techniques rely on the same set of rules. Below I will discuss some of these rules that will help make you a better troubleshooter.
Divide the Problem Space
When I’m faced with an unknown issue, I apply the same techniques as when I have to pick a number between 1 and 100. If you have ever played this game, you know that most people fall into one of two categories: the random guessers and the narrowers. The random guessers might start by choosing 15, then hear that the number is higher and pick 23, then hear it is still higher. Eventually they might either luck into the right number or pick so many numbers that only the right number remains. In either case they use far more guesses than they need to. Many people approach troubleshooting the same way: They choose solutions randomly until one happens to work. Such a person might eventually find the problem, but it takes way longer than it should.
In contrast to the random guessers, the narrowers strategically choose numbers that narrow the problem in half each time. Let’s say the number is 80, for instance; their guesses would go as follows: 50, 75, 88, 82, 78, 80. With each guess, the list of numbers that could contain the answer is reduced by half. When people like this troubleshoot a computer problem, their time is spent finding ways to divide the problem space in half as much as possible. As I go through specific problems in this chapter, you will see this methodology in practice.
Favor Quick, Simple Tests over Slow, Complex Tests
What I mean here is that as you narrow down the possible causes of a problem, you will often end up with a few hypotheses that are equally likely. One hypothesis can be tested quickly but the other takes some time. For instance, if a machine can’t seem to communicate with the network, a quick test could be to see if the network cable is plugged in, while a longer test would involve more elaborate software tests on the host. If the quick test isolates the problem, you get the solution that much faster. If you still need to try the longer test, you aren’t out that much extra time.
Favor Past Solutions
Unless you absolutely prevent a problem from ever happening again, it’s likely that when a symptom that you’ve seen before pops up, it could have the same solution. Over the years you’ll find that you develop a common list of things you try first when you see a particular problem to rule out all of the common causes before you move on to more exotic hypotheses. Of course, you will have problems you’ve never seen before, too—that’s part of the fun of troubleshooting—but when you test some of your past solutions first, you will find you solve problems faster.
Tuesday, July 21, 2009
Redmond Releases Code to Linux Kernel Community
Paul Krill, InfoWorld
Jul 21, 2009 4:13 am
Source
Source
Microsoft, which has been at odds with the Linux community over the years because of intellectual property issues, said on Monday it has released 20,000 lines of Linux code to the Linux kernel community.
Available for inclusion in the Linux tree, the code includes three Linux device drivers; it will be available to both the Linux community and customers. It will enhance the performance of the Linux operating system when virtualized on Microsoft Hyper-V Server 2008 virtualization software, according to Microsoft. Code will be offered under the GNU General Public License 2.
[ About two and a half years ago, Microsoft forged a Linux partnership with Novell that still generates controversy. ]
"We are seeing Microsoft communities and open source communities grow together, which is ultimately of benefit to our customers," said Microsoft's Sam Ramji, senior director of platform strategy in the company's Server and Tools organization, in a statement released by the company. "The Linux community, for example, has built a platform used by many customers. So our strategy is to enhance interoperability between the Windows platform and many open source technologies, which includes Linux, to provide the choices our customers are asking for."
"Today's release would have been unheard of from Microsoft a few years ago but it's a prime example that customer demand is a powerful catalyst for change," said Ramji.
Indeed, Microsoft has been involved in ongoing disagreements with open source advocates, with Microsoft claiming open source projects like Linux violate 235 Microsoft patents.
Ramji also cited the current economic climate as a driving force. "Many companies are turning to Microsoft more frequently to help them succeed in a heterogeneous technology world because we understand that reducing complexity is a key factor to reducing cost. We are seeing interoperability as a lever for business growth," Ramji said.
In a statement, the executive director of the Linux Foundation saw Microsoft's effort as validation of open source.
"We see the move by Microsoft to submit its device driver code to the Linux kernel as a validation of the open source development model and the GPLv2 license," said Executive Director Jim Zemlin. "Even if a bit overdue, we applaud Microsoft for recognizing the value of collaboration in order to compete in today's IT market."
An industry analyst concurred that the move was precedent-setting.
"This is a logical but precedent-setting decision for Microsoft. Credit Microsoft for recognizing the reality that a sizable portion of its customer base was going to be running Linux and Microsoft side by side in virtualized environments, so it would be important to be competitive on an interoperability front," said Stephen O'Grady, analyst at Redmonk.
"For all of its logic, however, this is a move that would have been inconceivable a few years ago, meaning that the glasnost of Microsoft vis a vis open source continues," O'Grady said.
Continuing a recent mantra of accommodations for open source, Tony Hey, corporate vice president of the external research division at Microsoft Research, will address the O'Reilly OSCON (Open Source Convention) audience in San Jose, Calif. this Thursday about the company's commitment to open access, open tools and interoperability in the "heterogeneous world of research," according to a statement from the company. Hey will discuss tools for scientists to process and analyze massive amounts of data to accelerate scientific discovery.
Microsoft also is highlighting on Monday its ongoing investment in optimizing PHP on Windows Server and the Microsoft SQL Server database. The company has had work ongoing on a SQL Server driver available for PHP to support more native features in SQL Server 2008. Microsoft also has partnered with PHP tools vendor Zend Technologies to boost PHP.
Friday, July 3, 2009
New Linux patch could circumvent Microsoft's FAT patents
Microsoft's recent lawsuit against TomTom, alleging infringement of filesystem patents, has left many questions unanswered about the legal implications of distributing open source implementations of Microsoft's FAT filesystem. A new Linux kernel patch that was published last week offers a workaround that might make it possible to continue including FAT in Linux without using methods that are covered by Microsoft's patents.
The patent dispute erupted in February when Microsoft sued portable navigation device maker TomTom. Microsoft claimed that TomTom's Linux-based GPS products infringe on several of its patents, including two that cover specific characteristics of FAT, a filesystem devised by Microsoft that is widely used on removable storage devices such as USB thumb drives and memory cards. The dispute escalated when TomTom retaliated with a counter-suit, but it was eventually settled in March when TomTom agreed to remove the relevant functionality.
Subscribe to:
Posts (Atom)
