boot into CLI, but not by... [explained in thread]

[Snowhog]

Oooh! Yes, I like that. Making the change.

[oshunluvr]

Wow Steve, your screenies are starting to look like Rog's. Well done

[richb]

Nano is a very good cli based editor. It has got me out of trouble when I have borked the display with an error in xorg.conf, (when I used xorg.conf).

[SteveRiley]

That's just a KScreenShot of Yakuake. Rog remains our screen artist-in-residence

[rybnik]

Yikes. Do you pull your fingernails out too?

hahahaha Only on prime-numbered days of the month. ;-) I don't see what makes you say that, though. Vim can be used the same way as nano (which is pretty much what I do at this point, as I'm not yet accustomed to all the shortcuts), the only difference being hitting 'i' in the beginning. And :wq is much more elegant than ctrl-X and then confirming changes.

So to get back to the topic of this thread--I took the first couple suggestions and set my default runlevel to 2. Then when I want a gui, I use

init 5

as root. This is working very well for me.

So I get put into tty1 by default, but issuing "init 5" automatically switches me to tty7. Before issuing "init 5", tty7 is empty--not even a login prompt.

This can help save battery power, right? This was my main motivation for it, so that when I'm just taking notes in my classes (which I do in vim), I don't burn the battery needlessly.

[SteveRiley]

Vim can be used the same way as nano (which is pretty much what I do at this point, as I'm not yet accustomed to all the shortcuts), the only difference being hitting 'i' in the beginning. And :wq is much more elegant than ctrl-X and then confirming changes.

Modal vs. non-modal editors. Choice is good! Wars are silly

So I get put into tty1 by default, but issuing "init 5" automatically switches me to tty7. Before issuing "init 5", tty7 is empty--not even a login prompt.

That's expected. init spawns six instances of getty, one on each of tty1..6. Take a look:

ls -al /etc/init/tty*.conf

I've modified all of mine to include the --noclear option, which prevents the screen from clearing:

steve@t520:~$ [B]cat /etc/init/tty1.conf[/B]
# tty1 - getty
#
# This service maintains a getty on tty1 from the point the system is
# started until it is shut down again.

start on stopped rc RUNLEVEL=[2345] and (
            not-container or
            container CONTAINER=lxc or
            container CONTAINER=lxc-libvirt)

stop on runlevel [!2345]

respawn
exec /sbin/getty -8 38400 [COLOR="#B22222"]--noclear[/COLOR] tty1

issuing "init 5" automatically switches me to tty7. Before issuing "init 5", tty7 is empty--not even a login prompt.

tty7 is blank because no process has been assigned to it. The X display manager, when started, automatically chooses the next available TTY on the system (64 are defined in /dev, numbered 0..63). Because tty7 is the next available, that's where your graphical desktop will start.

This can help save battery power, right? This was my main motivation for it, so that when I'm just taking notes in my classes (which I do in vim), I don't burn the battery needlessly.

Probably not. Graphical compositors only redraw changed portions of the screen. In some ways, they might be more efficient than framebuffers, which is what text-mode TTYs use. But I could be wrong -- you'll need to experiment and find out.

[rybnik]

Choice is good! Wars are silly

Using a free version of vi is not a sin. It's a penance. -Stallman

[rybnik]

This can help save battery power, right? This was my main motivation for it, so that when I'm just taking notes in my classes (which I do in vim), I don't burn the battery needlessly.

Probably not. Graphical compositors only redraw changed portions of the screen. In some ways, they might be more efficient than framebuffers, which is what text-mode TTYs use. But I could be wrong -- you'll need to experiment and find out.

So far, using runlevel2 does seem to conserve battery power, although in light of what you said, I suspect it might be largely because that runlevel does not have networking or wifi.

[SteveRiley]

Yes, disabling network interfaces -- especially those with radios -- will reduce overall power usage.