There are times when you might need to drop back to a full screen terminal session from a graphical desktop environment when running Linux. One example that I have encountered is the installation of Nvidia’s own graphics drivers on either Ubuntu or Linux Mint. Another happened to me on Arch Linux when a Cinnamon desktop environment update left me without the ability to open up a terminal window. Then, the full screen command allowed me to add in an alternative terminal emulator and Tech Drive-in’s list came in handy for this. there might have been something to sort on a FreeBSD installation that needed the same treatment. This latter pair happened to me on sessions running within VirtualBox and that has its own needs when it comes to dropping into a full screen command line session and I will come to that later.
When running Linux on a physical PC, the keyboard shortcuts that you are CTRL + ALT + F1 for entering a full screen terminal session and CTRL + ALT + F7 for returning to the graphical desktop again. When you are running a Linux guest in VirtualBox and the host operating system also is Linux, then the aforementioned shortcuts do not work within the virtual machine but instead affect the host. To get the guest operating system to drop into a full screen terminal session, the keyboard shortcut you need is [Host Key] + F1 and the default host key is the right hand CTRL key on your keyboard unless you have assigned to something else as I have. The exit the full screen terminal session and return to the graphical desktop again, the keyboard shortcut is [Host Key] + F7.
All of this works with GNOME and Cinnamon desktop environments running in X sessions and I cannot vouch for anything else unless alternatives like Wayland come my way. Hopefully, this useful functionality applies to those other set-ups too because there are times when a terminal session is needed to recover from a mishap, rare though those thankfully are and they need to be very rare if not non-existent for most users.
During the latter part of last year, the magazine Linux Format suffered a staff clear-out and I was left wondering why. It was as if a load of folk left at once and, even if I have seen that sort of thing happening at my current place of work, I was asking if something went wrong at Future Publishing.
What had passed me by was that the then staff of Linux Format were working on starting up their own magazine. They then went about crowdfunding the thing on Indiegogo and it only was the appearance of Linux Voice on a shelf in the Macclesfield branch of WHSmith’s that alerted me to what was happening in previous months.
It does sound risky to have an entire bunch of folk from one publisher’s magazine go off on their own and do their own variant of it, especially in these digital days when magazine publishing is not as secure as it once was. The mention of someone being held by no-compete covenant that reminded me of the mindset of where I work for a living. Quite what their old employers must make of it would make interesting reading because mine might be tempted to see me in court if I did something similar, assuming that was a possibility; I too would be bound by a covenant for six months after leaving.
As for the magazine itself, the content is good like it needs to be. There may be the occasional misspelling but articles on OwnCloud and Arch Linux installation would draw my attention along with reviews of Mageia 4 and FreeBSD 10. A lot of the old names from Linux Format appear too so there’s an air of continuity there. The design of the new upstart is less flashy than its longer standing predecessor and it will be interesting to see how they coexist.
It will take time for any new ideas to come to fruition and I wish the new magazine well. Its intentions are good in that half if profits are to go to open source software projects and articles are to be made available to all under a Creative Commons licence. First though, it needs to stay financially viable and the coming months could be interesting. The collective experience of who is behind the magazine should help though and that might stop it becoming like Walking World Ireland and Cycling World, other magazines whose appearance in newsagents is occasional. Having support from an enthusiastic community is a bonus too and there may come a time when I have to decide between Linux Voice and Linux Format as is the case with Linux Magazine and Linux User & Developer. For what is supposed to be a niche operating system, users of Linux are not badly served when it comes to magazines.
Within the last week, I set up virtual web server using Arch Linux to satisfy my own curiosity since the DIY nature of Arch means that you can build up exactly what you need without having any real constraints put upon you. What didn’t surprise me about this was that it took me more work than the virtual server that I created using Ubuntu Server but I didn’t expect ProFTPD to be missing from the main repositories. The package can be found in the AUR but I didn’t fancy the prospect of dragging more work on myself so I went with vsftpd (Very Secure FTP Daemon) instead. In contrast to ProFTPD, this is available in the standard repositories and there is a guide to its use in the Arch user documentation.
However, while vsftpd worked well just after installation, connections to the virtual FTP soon failed with FileZilla began issuing uninformative messages. In fact, it was the standard command line FTP client on my Ubuntu machine that was more revealing. It issued the following message that let me to the cause after my engaging the services of Google:
500 OOPS: priv_sock_get_cmd
With version 3.0 of vsftpd, a new feature was introduced and it appears that this has caused problems for a few people. That feature is seccomp sandboxing and it can turned off by adding the following line in /etc/vsftpd.conf:
That solved my problem and version 3.0.2 of vsftpd should address the issue with seccomp sandboxing anyway. In case, this solution isn’t as robust as it should be because seccomp isn’t supported in the Linux kernel that you are using, turning off the new feature still needs to be an option though.
While you can add Windows fonts to Linux installations, I have found that their display can be flaky to say the least. Linux Mint and Ubuntu display them as sharp as I’d like but I have struggled to get the same sort of results from Arch Linux while I am not so sure about Fedora or openSUSE either.
That has caused me to look at web fonts for my websites with Google Web Fonts doing what I need with both Open Sans and Arimo doing what I need so far. There have been others with which I have dallied, such as Droid Sans, but these are the ones on which I have settled for now. Both are in use on this website now and I added calls for them to the web page headers using the following code (lines are wrapping due to space constraints):
<link href=”http://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,700italic,400,300,600,700” rel=”stylesheet” type=”text/css“>
<link href=’http://fonts.googleapis.com/css?family=Arimo:400,400italic,700,700italic‘ rel=’stylesheet‘ type=’text/css‘>
With those lines in place, it then is a matter of updating font-family and font declarations in CSS style sheets with “Open Sans” or “Arimo” as needed while keeping alternatives defined in case the Google font service goes down for whatever reason. A look at a development release of the WordPress Twenty Twelve theme caused me to come across Open Sans and I like it for its clean lines and Arimo, which was found by looking through the growing Google Web Fonts catalogue, is not far behind. Looking through that catalogue now causes for me a round of indecision since there is so much choice. For that reason, I think it better to be open to the recommendations of others.
Though it isn’t the recommended approach, I have ended up upgrading to Linux Mint 12 from Linux Mint 11 using an in situ route. Having attempted this before with a VirtualBox hosted installation, I am well aware of the possibility of things going wrong. Then, a full re-installation was needed to remedy the situation. With that in mind, I made a number of backups in the case of an emergency fresh installation of the latest release of Linux Mint. Apache and VirtualBox configuration files together with MySQL backups were put where they could be retrieved should that be required. The same applied to the list of installed packages on my system. So far, I haven’t needed to use these but there is no point in taking too many chances.
The first step in an in-situ Linux Mint upgrade is to edit /etc/apt/sources.list. In the repository location definitions, any reference to katya (11) was changed to lisa (for 12) and the same applied to any appearance of natty (Ubuntu 11.04) which needed to become oneiric (Ubuntu 11.10). With that done, it was time to issue the following command (all one line even if it is broken here):
sudo apt-get update && sudo apt-get upgrade && sudo apt-get
Once that had completed, it was time to add the new additions that come with Linux Mint 12 to my system using a combination of apt-get, aptitude and Synaptic; the process took a few cycles. GNOME already was in place from prior experimentation so there was no need to add this anew. However, I need to instate MGSE to gain the default Linux Mint customisations of GNOME 3. Along with that, I decided to add MATE, the fork of GNOME 2. That necessitated the removal of two old libraries (libgcr0 and libgpp11, if I remember correctly but it will tell you what is causing any conflict) using Synaptic. With MGSE and MATE in place, it was time to install LightDM and its Unity greeter to get the Linux Mint login screen. Using GDM wasn’t giving a very smooth visual experience and Ubuntu, the basis of Linux Mint, uses LightDM anyway. Even using the GTK greeter with LightDM produced a clunky login box in front of a garish screen. Configuration tweaks could have improved on this but it seems that using LightDM and Unity greeter is what gives the intended set up and experience.
With all of this complete, the system seemed to be running fine until the occasional desktop freeze occurred with Banshee running. Blaming that, I changed to Rhythmbox instead though that helped only marginally. While this might be blamed on how I did the upgraded my system, things seemed to have steadied themselves in the week since then. As a test, I had the music player going for a few hours and there was no problem. With the call for testing of an update to MATE a few days ago, it now looks as if there may have been bugs in the original release of Linux Mint 12. Daily updates have added new versions of MGSE and MATE so that may have something to do with the increase in stability. Even so, I haven’t discounted the possibility of needing to do a fresh installation of Linux Mint 12 just yet. However, if things continue as they are, then it won’t be needed and that’s an upheaval avoided should things go that way. That’s why in situ upgrades are attractive though rolling distros like Arch Linux (these words are being written on a system running this) and LMDE are moreso.