Best of Technical Support
Is it possible in Linux (I don't care which distribution, I mean the system architecture) to have two screens, i.e., two monitors on the same machine? Also with two graphics cards, of course. Is it possible to have them running together, either in text mode or serving X? And is it possible to have only one actual X desktop, but two virtual ones projected over two different screens? —Eduardo Garcia, firstname.lastname@example.org
The “two screens” support you've mentioned is called multi-headed display support. It is the ability to use two (three and so on) monitors simultaneously and usually make them act as one huge virtual desktop. The commercial X servers such as Accelerated X (http://www.xig.com/) and Metro-X (http://www.metrolink.com/) already have such support, and recently XFree supports this too (but it is not stable enough, in my opinion). Be aware, though, that your hardware (graphics card) must also support this. —Mario de Mello Bittencourt Neto, email@example.com
With XFree 4.0, you can run X on two cards and two monitors, either as independent sessions or as one big screen (Xinerama). It should also be possible to get XFree 4.0 to open one X session on the secondary screen (i.e., not the one Linux is displaying console messages on) and keep text mode in the other monitor, but there isn't a convenient way to switch back and forth between the two screens (you'd have to use CTRL+ALT+FN). Frame buffer (FB) support will also work with two video cards, so my guess is that the FB application gets to say which FB display to write on. —Marc Merlin, firstname.lastname@example.org
As installation of XFree86 4.0 is not for the faint-hearted, you may want to hold off until RPM packages start to appear before trying it. —Erik Ratcliffe, email@example.com
It depends on your X server software. XFree86 version 4 (which is more recent than the version included in your Red Hat distribution) has some support for multi-headed configurations; you can check their release notes under http://www.xfree86.org/. —Scott Maxwell, maxwell@ScottMaxwell.org
What is the scope of fopen? That is, when you use this system call, where exactly does it look for the file we want to open?
If you supply an absolute file name (that is, one that starts with a “/”), then fopen starts at the root directory. Otherwise, the file name is relative, so fopen starts looking for the file in the process's current working directory. This directory is initially the same as the parent process's current working directory (so if you ran the program from a shell, it's whatever directory you were in when you ran it), but the current working directory can be changed by calling chdir or fchdir. By the way, as a pedantic note, fopen is not a system call; it's a C library function. fopen does part of its work in terms of the system call open. —Scott Maxwell, maxwell@ScottMaxwell.org
The fopen library function is the analog of the low-level open system call. You use it mainly for files and terminal input/output. When you need explicit control over devices, you are better off with the low-level system calls, as they eliminate potentially undesirable side effects from libraries, like input/output buffering.
If successful, fopen returns a non-null FILE * pointer. If it fails, it returns the value NULL, defined in stdio.h.
fopen uses the open system call. Here is how the open system call works:
1. When the kernel receives an open system call, it starts the function called sys_open. You can find the code in the kernel source in fs/open.c. sys_open (const char * filename, int flags, int mode)
2. From the file name, sys_open will try to get the associated inode structure. This inode structure is located in the directory where the file is (the directory is a special file). To get the inode of the directory with the relevant information, sys_open will have to recurse by starting to read the current directory to get the inode of the relative directory, and so on.
If the file name starts with a /, the process is the same, except that it will start with inode 2 (inode number of /) on the root partition.
3. Once the inode of the file is found, sys_open will read the file operation associated with the file's inode, and run the open method associated with that inode/file.
This open method may be related to a device module if the file is a device (see major number and /proc/devices) or to a specific file system (df -k filename -> proc swap ext2 ...)
4. This open method returns a “struct file *” which is associated with a file descriptor.
sys_open will return a file descriptor, an integer greater than 0. If sys_open fails, it returns an integer less than 0. fopen will then associate this file descriptor (int) to a file stream (FILE *).
I hope this helps. —Emmanuel-Robert Mayssat, firstname.lastname@example.org
fopen(2) takes two parameters. The first is the file to open, and the second tells the system to open it for reading, writing, reading and writing, and other options. If you do not specify a path to the file to open, fopen() will look for that file in the current directory. —Chad Robinson, Chad.Robinson@brt.com
Feel free to refer to the manual pages: use Chapter 2 for the system calls (e.g., man 2 open) and Chapter 3 for library functions (man 3 fopen). —Alessandro Rubini, email@example.com
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