edit: the condensed version of this post should read: 'Even in the advent of systemd, "startx" is not obsolete; it just isn't working on Pidora 2014-3.'
I guess I need to clarify my response.
Pidora is a port of Fedora 20 that unfortunately does not work like Fedora 20. Somewhere along the lines of porting F20 to the RPi the behavior of F20 was changed so that Pidora does not behave like F20 upon which it is based. This would suggest that something in the F20 / F20 ARM distribution was broken somewhere along the process of porting it to the older ARM chips (RPi) that are supported by Pidora.
In F20 you can do this: to change modes on the next boot:
# systemctl set-default multi-user.target
# systemctl set-default graphical.target
in doing this, systemctl takes care of the drudgery of manually recreating the symlinks. example:
ln -sf /lib/systemd/system/runlevel5.target /etc/systemd/system/default.target
As you can see, the systemd business looks like a complicated wrapper that's built around changing the default.target to point at runlevel 5. As far as kernel is concerned, runlevel 5 is still runlevel 5.
Insofar as the multi-user.target is analogous to runlevel 3, setting multi-user.target as the default boots up F20 in multi-user (text) mode, previously known as runlevel 3. By design, the TARGET.target system is designed only to configure the target that is used to boot the system, and is not supposed to impose any incompatibility wrt changing runlevels. In other words, you can boot F20 using the multi-user.target, which places you in a text mode console. At your will, you can type startx to invoke the graphical display manager, do your business in X11, and log out of X11 being returned to the text mode console. This is the way linux is supposed to work -- the TARGET.target system is designed to BOOT the computer, not to control what the user does with the computer after it is booted. Starting X11 amounts to nothing more than starting a graphical program in userspace.
Unfortunately Pidora 2014-3 doesn't work this way. If you configure the system to boot into the graphical.target (to properly configure the gdm) and then change the default target to "multi-user.target", and then reboot, you get booted into text mode as expected. but then it's impossible to invoke the gdm from the command line to start X11. (This is abnormal.) The only way to invoke X11 is to set the default target to "graphical.target" and reboot the machine. Once the machine is rebooted, you're taken directly into X11 (as expected) and upon exiting X11 you go back to the gdm logon screen. You can't exit from X11 to text mode. To get back to a text console you have to change the default target back to multi-user.target and reboot.
All of this rebooting business is quite a pain in the side. I guess the Windows crowd has been conditioned to accept this as normal even though it is not. There is no reason that the kernel should have to be reloaded just to change runlevels in userspace. Linux kernels don't work that way. F20 doesn't work that way. Pidora, though it is built on F20, is unique in that it doesn't support the changing of runlevels in userspace. It issues a GUI error screen if you try to do this, because there is a gdm configuration problem, which is presumably created by an error in the target configurations.
I'd really like to find out why this is happening so that I can fix what's broken.
Thanks for your time.