Commercial Linux Transforming the Community? Or Do They Need a Wakeup Call?
Last week, I had the privilege of addressing the North Texas Linux Users Group. Ralph Green asked me to present information on my upcoming book called "Linux System Administration" by O'Reilly. I only had the digital images of the cover and gallies, since the book actually goes to press in early March. So, I showed my digital images.
While this may seem like a plug, the vast majority of Linux authors make little to no money on their books and other publications. So, consider this particular book more of an effort of documentation like you would on a OSS project.
Back to the presentation. I have noticed over the years that proprietary user groups have become common. Few, if any members of those communities offer code to the operating system or application projects. These communities such as Amiga, Mac, Java, Microsoft, etc. are truly USER GROUPS.
I asked for a show of hands in a rather large audience of Linux users how many of them were Linux System administrators. Not a single hand went up. That's the response I expected having done surveys on marketing. The Linux community today, for the most part, reflects the validity of the name Linux Users Groups (LUGs).
Last week I interviewed, by invitation, with one of the two major Linux commercial vendors in the US. I wanted to see what occurs in that environment since almost everything they say about their work is "No Comment". I found out a great deal since I researched the people scheduled to interview me.
I would characterize the interview as one of the most humiliating experiences I can remember. The interview process reminded me more of a cattle round-up. The people conducting this process just ran us through like you would herd cattle into a feed lot.
The group manager's original correspondence prior to the trip seemed full of enthusiasm. I thought from that correspondence that I would actually interview face to face for a position for which I had several telephone interviews.
I made a day trip out of the travel since I don't like to pack even for a 1500 mile, 15 hour excursion. When I arrived, I soon discovered the company had no plans to conduct a normal interview. I had taken a trip to a major city on the east coast to become a member of a feed lot for cattle.
I found an absence of a coordinator. My schedule didn't fit the one sent to me. People other than those scheduled interviewed me. They did not have my resume. Before the trip, I spent a few hours filling in an interview form that I "had to bring". No one asked for the form and they interviewed me from nothing on paper.
Many of the people I met had worked for companies such as HP, IBM, Dell, etc. They had approximately two years of experience on average. To them, Linux was another product like any other they had sold before.
One of the key decision makers decided she didn't feel like making my interview. That may have occurred as a result of the receptionist ordering me into an interview room in the most discourteous manner as the decision maker watched.
I did have a heavy dose of importance of the decision makers interviewing me. The head of the Federal group had no idea of the work I had done in the Government arena and didn't have time to ask me about that. I suppose that in a 30 minute interview, he had to spend a majority of the time allotted to his own grandeur (sic).
If I thought my feedback would make a difference, I would consult this company about the gross process I endured and how it could have worked. All in all, it did not work. As a business process it demonstrated immaturity, thoughtlessness and serious disorganization.
One of the more interesting claims dealt with the company's self importance. According to one of my interviewers, the Linux development community has gone to hell. No one is left. The non-commercial Linux users lack the ability to produce anything of real value.
We're only a user group and we cannot afford the products offered by our commercial Linux friends. Well, bless these folks. While they have convinced themselves they have won, I can only reflect on the concept of history repeating itself. People who believe they have arrived, will fall. And the cause of that fall will come from a place they never anticipated.
So, back to the book. One thing our team at O'Reilly wanted to accomplish involves a different kind of Linux book. We haven't written and will not publish another version of running Linux. We wanted to take the Linux power user to the next level. LSA is about servers and making our readers into admins who have to build servers and administrate them.
Linux has a rich history of turning hobbyists into professionals. You can continue to use the desktop to run a web browser, send emails and post comments to news sites. If you want to move on, consider what it takes to administer Linux and you'll only have one job opportunity according to the people who interviewed me - them. Them as in full of themselves.
And that's all I have to say about that.
- God bless the child thats got his own - Billie Holiday
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!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
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