Linux Public Trust?
Many of you may not remember, but there was a fight over the Linux trademark a few years back. It turns out that a person who had nothing to do with Linux registered the trademark, then asked all the businesses in the Linux community for 10% of their gross sales for the use of “his” trademark.
What happened next was one of the best examples of what Linux is all about. A group of us, coordinated by Linux International, put together a cooperative effort to rescue the trademark. In spite of being competitors and having different ideas as to what the right disposition of the trademark was, we all cooperated—both in our appearance of unity, and financially—to rescue the trademark and get it into the hands of the good guys. As I'm sure you are aware, the rescue effort was a success.
What's important here is why we cooperated. It would be nice to say that everyone involved was just a nice person (or a nice company). While I have a lot of respect for most of the people involved, there is more to it. We all saw the potential of Linux, and realized that if deployment of Linux could go forward, we all could grow our businesses. Time has proved this to be correct.
While Linux has been commercial to the extent of businesses selling products to the Linux community since 1993, a significant change happened in 1999. With existing public companies such as Informix, IBM, HP and Compaq getting on the Linux bandwagon and IPOs from previously private companies in the Linux space, the rules of the game have changed. We now have significant players in the Linux arena whose primary responsibility is to their shareholders, and it is not likely that shareholders in companies such as IBM have more interest in the future of Linux than in their own personal gain.
The good news is that members of the Linux community can recognize this and treat them appropriately. Sure, we want these new players, but we also realize that what is best for our community and what is best for a big corporation with a Linux sideline are not necessarily the same thing.
To me, the bigger concern is what could happen with our own players. While the scenario I outline below could happen with any Linux distribution manufacturer, I use Red Hat as an example because they are in the news again with their purchase of Hell's Kitchen Systems.
Red Hat has done a good job of establishing their brand so that many see Red Hat and Linux as synonymous. This is very similar to the earlier practice of referring to computers as IBM machines. It makes business sense on Red Hat's part, but also helps them grow at the expense of at least the other Linux distribution vendors. I feel it is also at the expense of the Linux community as a whole because, taken to the extreme, we end up with a fragmented Linux market competing against Microsoft.
How can this happen? I don't know Red Hat's plans, but if they decide to turn Cygnus and HKS into “Red Hat-only” companies, producing software that runs on only the Red Hat flavor of Linux, then we start to produce this problem. The direct effect is that other Linux distribution vendors lose market share. That is the short-term problem, but not the significant one.
The next thing that happens is other software vendors see Linux as a less-viable platform for a port of their software, because there is no longer one Linux to port to. While this may sound good, the consumer then sees less of a choice in selecting a Linux distribution. This is hard to sell to a consumer who has been advised to flee Microsoft because they don't offer a choice.
I feel there is. The first step was establishing the Linux Standards Base project. This is an effort to create a core functionality made available by Linux. Once in place, vendors will be able to port to this standard and test their software against a standard distribution. If their software runs against the standard, then it should run on any Linux distribution subscribing the the LSB standards effort. Unfortunately, LSB could be too late.
In the meantime, I think a good alternative is possible. It is time to cooperate again. I believe it's time to start what I will call “The Linux Company”. It would be a for-profit company, owned by other Linux distribution manufacturers. It would then invest in (or possibly purchase) companies that would benefit the whole Linux community. For example, if SoftLogik, a company that produces a layout program, were to commit to a port of their software to Linux, The Linux Company could chose to invest. One condition would be, of course, that the Linux port would run on all Linux distributions represented by The Linux Company.
I don't see this idea as a replacement for the LSB effort. I see it as something that would help the effort along. LSB is primarily technical. This would be a tool that would help move the importance of those technical issues into the realm of corporate leaders.
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!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Returning Values from Bash Functions
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Rogue Wave Software's Zend Server
- Doing for User Space What We Did for Kernel Space
- 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