The Generation Gap
The people who write open-source software are the hackers—the community that had its origins at the MIT AI Lab.
It began in 1959, when a group of people in the Signals and Power group of the Tech Model Railway Club got access to a small computer—the TX-0. This was different from the big IBM mainframe, where one submitted a deck of punched cards, then waited around for their own job to run. With the TX-0, one could actually sit at a console and deal with the machine directly. The club loved it. They loved the challenge of trying to make it do what they wanted, and the feeling of power when it finally did. They started with practically nothing in the way of an operating system. They wrote their own system functions and simple tools and used them to build better tools.
These were the original hackers—a group of people who thought programming was the most important thing in the world. They were explorers. They were a community. They shared information and ideas, and they shared the belief that if information and ideas move freely, everyone benefits. They shared the product of their work—tools, utilities, experiments, games and jokes. A person's standing in the hacker community was based on almost nothing except that work.
People moved in and out of the community at MIT. Some hackers moved to other institutions and kept in touch via the ARPA-Net (a precursor to the modern Internet). The community became a network community and stopped having a specific geographic location. As Internet access became available to anyone in college, this community grew. The Internet became the focus for many hackers; its infrastructure was developed largely by hackers. Now the focus has shifted to Linux, and the software that runs under it.
As Eric Raymond describes in his paper “Homesteading the Noosphere”, the hacker culture is a gift culture—status within the community is based on what a person creates and gives away. Open-source software is the product of people programming (testing and debugging) and giving away the results. Most of this work is done in the spare time by people who also hold paying jobs.
People contribute to open-source projects for a variety of reasons: fascination with the problem, desire for a meaningful programming project, wanting to participate in the community, an opportunity to prove themselves, or a desire to use the new software personally. They continue to contribute to the community and culture because it works. People who have never physically met, each doing whatever they feel like doing, can in their spare time create great software.
The General Public License is seen as strongly supporting the hacker culture. It can be difficult to attract contributors to a project for software that is not licensed under the GPL. It can be particularly difficult for projects involving components licensed under the MIT license.
In the past, people in the Open Source community were the primary users of open-source software, but this has changed. Many new Linux users are not programmers and many of them will never contribute to open-source projects. Open-source developers don't feel cheated by this; they feel vindicated. To a hacker, the ultimate measure of software's worth is whether people find it useful.
Linux has been very good for the Open Source movement. Huge numbers of people are trying it. Many more are hearing about it. People are pushing for its use where they work. More and more people are learning about the Open Source movement and its values, and becoming involved in open-source projects and a part of the Open Source community. The community benefits from increasing use of open-source software, whether that use directly supports open-source development or not. The community benefits when dentists, for instance, use Linux.
Suppose, however, that a dentist and I want to get together and write an application that implements his top-secret super-duper billing technique. The technique is a trade secret, so the application must be closed source. Now, suppose that as I'm writing it, I want to use an open-source library to do statistics. If this makes my billing application a “derived work” and I'm going to get a bunch of licensing hassles, I'll do something else. I'm not trying to derive a new statistics library—I just want to use it. If it's a good thing for a dentist to run his billing application on Linux, why wouldn't it be a good thing for the application to use open-source parts?
The more people who use open-source components, the more people will decide some component needs a wee change and they should do a little work for the open-source project. If open-source components are used in business applications, businesses will, from time to time, find it in their interest to pay someone to work on the components. This is good for the Open Source movement.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- Interview with Patrick Volkerding
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide