Human Readable   

GNU/Linux Journal  How-Tos and Essays  A Slackware Desktop Enhancement Guide  Home

StartX, Consoles, and Keyboard Shortcuts—Day 26

© Copyright Darrell Anderson.

I might have finally figured out how to “force” the first GUI to open with Alt-F7, despite having only two console terminals assigned in inittab. I edited two files:

In the first file I wrote:

In the second file I wrote:

The “reserve” parameter is an interesting twist to how KDE handles secondary X sessions. With that parameter, the “Start New Session” option appears in the K menu. Without that parameter the option is unavailable in the K menu. However, the latter does not mean all access to secondary X sessions is prohibited, only that the menu option does not appear. Without the menu option one needs to press the appropriate keyboard sequence to toggle to the next X session.

For example, with my previous example, pressing Ctrl-Alt-F8 will toggle to the next X session and the KDM login manager appears. Another difference is without the reserve option, toggling to the next X session does not time out. When using the reserve option, one must login before 60 seconds or KDE cancels the attempt and reverts to the originating X session screen.

Possibly the most important difference is the way KDE allots memory for secondary sessions. When using the reserve option KDE automatically reserves about 20 MB of RAM for each potential secondary X session. When not using that option, KDE adjust the RAM on-the-fly. There are obvious advantages and disadvantages to either choice.

However, I cannot figure out how to enable the right Alt key when outside the GUI, nor have I figured out how to run another GUI session from a different terminal console. The command startx -- :1 does not work! Because my normal preference is a GUI login, I want two terminal sessions that provide a GUI login and a third session available for low level command line login.

One of my long-running complaints about GNU/Linux, but I think more about the open source development process in general, is dependable documentation is lacking. Coders love to code, but don’t ask them to write supporting documentation. Most coders loathe explaining their code. If they do write anything, the documentation more often than not is written in a terse programmatic style, just like code. Often programmers write for other programmers, not end-users. Thus, a lot of important information is missing, much like skipping a step in a geometry proof. Skipping the proof step might be intuitively obvious to mathematicians, but not novices. Similarly, programmers often seldom see both the forest and the trees, which is why tech writers often help this process. Programmers see code and skip a lot of explanatory steps when writing How-Tos. They tend to see code as a coder, not an end-user. I have provided technical writing services for many years, so I am qualified to express myself. Some people might argue that I should not complain but get involved to remedy the situation. I hope to do that one day, but that does not excuse the current situation. Much of the information exists somewhere but is difficult to find.

Perhaps some people think I am spending too much time on trivial aspects of GNU/Linux and I should simply get on with getting connected and being productive. However, recall my original foundations. I am the chief cook and bottle washer with respect to my system. There is no IT staff to magically “fix it” if something fails to work correctly. As I have previously shared, there also is a lot of non-information floating around on the web with respect to finding solutions. Browsing discussion groups also indicates that there are many people who do not use computers as a tool but as a hobby or a simple gateway to the web. I surmise this because often when they experience problems they do not investigate but instead wipe their partitions and reinstall. I cannot imagine doing this on a regular basis nor do I have the time or desire. This practice of regularly reinstalling is supposed to be one of the knocks against Windows, yet here are many people trying to use GNU/Linux doing the same thing.

Yes, I am aware that GNU/Linux rarely needs reinstalling, and except for kernel or module updates, the experienced GNU/Linux person can perform many miracles without rebooting. The inexperienced person lacks that expertise, however, and for the newbie, reinstalling often is the path of least resistance. Building a personal in-depth knowledge base is unimportant to some of these people. They just want to point, click, and surf. Nothing wrong with that perspective, but conversely, I prefer to understand what is happening. My personal and professional data is too important to me to continually play the reinstallation game. Thus, all of these side trips are not only important to me, but to other chief cook and bottle washers reading these essays who are considering migrating to GNU/Linux. There are other people like me who want to migrate and any bump I experience and share is an important note to them.

These side trips are important. I am building foundations here. My “old” NT4 setup works well and rarely crashes. I spend little time worrying about my data or how to rebuild my system if that should happen. I need that same level of confidence with GNU/Linux before I can migrate fully. That means building my knowledge—a tremendously time consuming process. Migrating is strictly philosophical for me. That is, my NT4 system is stable and I don’t need to migrate for technological reasons. Thus, these side trips will continue!

Finis.

Table of Contents

GNU/Linux Journal  How-Tos and Essays
A Slackware Desktop Enhancement Guide
Contact Me  Terms of Use
Search
Home