Cygwin: Changing the Face of Windows
I recently found myself working at a company that uses Windows as the desktop environment. I was used to Linux, however, and wanted to have that on my desktop instead. Should you find yourself, for one reason or another, working in a Windows desktop environment but want to use Linux, Cygwin offers the opportunity to do so. Cygwin is a dynamic link library (DLL) that acts as a Linux API emulation layer. Included with the Cygwin suite are most of the common Linux command-line tools and quite a few graphical applications, giving you the look and feel of a Linux machine on top of your MS Windows box. Cygwin provides substantial Linux functionality on all non-beta, non-Release Candidate, x86, 32-bit versions of Windows, starting with Windows95. The only exception is Windows CE.
Cygwin does not convert your Windows machine into a UNIX-compatible one, however. Cygwin does not enable your computer to understand UNIX signals, pseudo-terminals (PTYs) and such; it only provides mappings of UNIX actions to the Windows platform. It is not a way to make native Linux applications run on Windows. If you want an application to run on your Windows workstation, and it is not yet a part of the Cygwin suite, you will have to compile the source. If the application is a graphical one, another solution is to run the application remotely by using X functionality. We discuss the set up for remote display later in this article.
You can download the Cygwin tools freely from the Cygwin Web site. Click on the Install Cygwin Now icon, and save the setup.exe tool somewhere on your hard disk. Then, double-click to install the Cygwin base configuration. You can either install everything directly or download to a directory on your local system and then install from that directory.
When the installation procedure asks to specify the root install directory, it is best to change the default, C:\cygwin, to some other path. Doing so keeps the Cygwin files separated from your native Windows files. There have been problems of this sort in the past, and even though Cygwin developers are 99% sure that no conflicts can happen anymore, it is wise not to take the risk. I installed Cygwin in D:\cygwin.
You can install the Cygwin programs for your own use or for the entire system. If you are not too deeply involved with development on Windows, select the UNIX text file type. If you need text files from your Windows machine, in some cases it is necessary to use DOS file types. In any case, the CYGWIN variable can be set to specify explicitly the text file type that you want to work with, should you need to switch file types at a later time. Compatibility with DOS text files is built in to Cygwin. Details about this and other UNIX-to-Windows mapping specifics can be found in the user guides on the Cygwin Web site.
Next, specify the package directory that should be used for downloading. With Firefox installed on my machine, my directory was C:\Program Files\Mozilla Firefox by default. To connect to the Internet, I had to pass an MS ISA proxy/firewall server--Internet security and acceleration server--which runs on Windows and does not agree with the normal standards. So I had setup.exe import the MS IE5 settings in order to download through the proxy server. This worked, at least in part; I will explain more about the ISA proxy/firewall troubles later.
Usage of a mirror for this part of the download and installation process is required. If you try to download directly from the Cygwin site you encounter errors, so select a mirror near you.
A minimal installation requires the base packages, which include the DLL, a bash shell, the coreutils, findutils, diffutils, documentation, libraries and a couple of basic UNIX tools, such as tar and grep. Select these basic packages and let the setup.exe tool do the rest.
The X server was the most important component for me, because I wanted to be able to do remote display. Unfortunately, the X server is not included in the base package. I was able to install most packages using the setup.exe tool, but my company's proxy/firewall settings prevented me from downloading bigger packages, such as the 75 dpi fonts, with this method. I tried playing with the proxy settings in the setup tool for a while, but to no avail. In the end, I manually downloaded the necessary packages from the mirror to a local directory, using HTTP in my browser, and instructed setup.exe to use that local repository.
After installing all the packages necessary for running X, you can start the server from the bash shell using one of several methods: an MS-DOS batch file, a shell script, the startx command or a direct call to XWin.exe. Example batch files and scripts are included in the Cygwin package. The batch file works the easiest, because it does a lot of things for you, including starting an X terminal.
When the X server is started successfully, the X logo is displayed in the task bar of your Windows desktop. From this moment on, your Windows workstation can display UNIX graphical applications. To test it, log in to a UNIX or Linux host and run a simple and small program, such as xclock or xlogo. When everything proves to work as it should, you can start the applications you need.
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
- SourceClear Open
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Tech Tip: Really Simple HTTP Server with Python
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader 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