In the March 2010 Point/Counterpoint column, Kyle Rankin pretends that he has to use --prefix to install apache to /usr/local instead of /usr.
Well, he surely hasn't used any ./configure script in the past 15 years, because it goes to /usr/local by default, and apache2 uses /usr/local/apache2 as a default prefix.
One less “point” in favor of Kyle, heh?
Kyle Rankin replies: You are right. When Bill and I do the Point/Counterpoint column, it's all off-the-cuff responses, so I talked about --prefix with ./configure while I was really thinking about --prefix in building and installing RPMs. I didn't realize the default install location for ./configure was /usr/local (although in my opinion, that makes an even stronger argument for /usr/local: it's the default). To be honest, although I compiled many programs back when I started using Linux (it was almost a requirement to compile the kernel at the very least), I rarely compile anything anymore, especially when it's going to be used in production. I think the moment you go down that road, especially when you have a large environment, you lose all the testing benefits you get with distribution packages, and you become a QA department of one. Now, I know that many system administrators still like to do everything by hand, but to me, the risks and maintenance headaches of that far outweigh any benefits. It may be okay with one or two servers, but in my opinion, it doesn't scale. Thanks for the comment.
Mick Bauer's VPN series is long overdue [see Mick's Paranoid Penguin columns starting with the February 2010 issue through this current issue]. But in practice, few medium-to-large companies are going to deploy an OpenVPN server. Their corporate management has at least two requirements it can't meet: simplicity and support. To them, simplicity means a proprietary appliance from a name-brand vendor—they distrust software running on *nix in their infrastructure, never mind that the black-box appliance is probably just software running on embedded BSD or Linux. And, support is a euphemism for “somebody to sue”.
This leaves those of us who need to make VPN connections to multiple clients/partners in the unenviable position of being stuck with one or more computers with a half-dozen incompatible proprietary VPN clients installed (most of which work only on MS Windows).
How about an article on making the OpenVPN client, and/or other open-source VPN
clients, interoperate with servers from some of the popular VPN vendors, such as
Cisco, Juniper, Nortel and so on, and the issues involved in connecting and
authenticating to proprietary VPN servers?
Mick Bauer replies: This particular series of articles was targeted at home/small-office/medium-office administrators; it was no coincidence that all my examples talked about connecting back to my house or that I showed a server configuration allowing only two concurrent connections. But by all means, you're correct, an article on connecting Linux clients to big commercial VPN concentrators would be useful. I'll consider that for a future column!
In the meantime, I can offer a quick hint. Whereas in client mode, OpenVPN can connect only to OpenVPN server processes, the free utility vpnc can connect to Cisco and Juniper/NetScreen VPN servers. Thanks for writing!
Microsoft spends hundreds of millions of dollars on advertising each year, reaching those in the community who own PCs but spend very little time with them. Microsoft's goal is to reinforce that Microsoft and Windows are what everyone uses on their PCs and that's just the way it is. I believe if a survey was taken world-wide on what operating systems were available to home PC users, a large number would say Windows and Mac. So, what's this letter all about? It's about finding ways without spending money to get Linux out to those who have no interest in operating systems in general. How (like Microsoft and Windows) do we reach people and make them aware of the existence of Linux without spending money?
I propose you write a article on the “Best Free Creative
promote Linux. Here's mine. Get your readers to leave old copies of
Journal in doctors' waiting rooms (and similar places) where you have a captive audience
looking for something to read. Maybe run a poll for the best ideas from your
John Van Gaans
John, that's a great idea! Perhaps the Web site is a good place to get feedback.—Ed.
This is a great magazine, and I have learned a great deal from it. I can
safely say that with the help of this magazine, you made this 14-year-old learn
a lot more about Linux, open source and computer management in general. Gotta say,
mad props to you guys—keep the good news going. I look forward to reading the latest
Aw shucks, Alex. It thrills me that a 14-year-old reads Linux Journal! I put my monthly issues in our local school library, but they don't get read nearly as much as I'd like. The rest of the editorial staff isn't very keen on my idea of including a centerfold each month with hot new hardware. It's good to hear that even without such eye candy, the magazine is still appreciated.—Ed.
On my PC running Debian GNU/Linux I use dwm (dwm.suckless.org) as my X window manager, and I like it very much. Now, on Wikipedia, there is an article about dwm (en.wikipedia.org/wiki/Dwm), but there is a discussion going on about deleting the dwm article (en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Dwm). One of the reasons is “This article needs references that appear in reliable third-party publications.”
So, I was wondering if Linux Journal could publish an article about this
small and powerful window manager.
Thanks for bringing this to our attention. We'll take a look at it, and see if it inspires anyone on staff to write about it.—Ed.
Have a photo you'd like to share with LJ readers? Send your submission to firstname.lastname@example.org. If we run yours in the magazine, we'll send you a free T-shirt.
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!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- SourceClear Open
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
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