We love simple solutions to problems, and this falls into that category.
A Reddit user has posted a pair of scripts to switch between two displays (a monitor and a TV) in Ubuntu 12.04, but these should be usable in many other versions of Linux as well. He writes:
I currently have a 40″ TV on HDMI (we’ll call this HDMI) and a 22″ monitor (DVI). I don’t want to dual screen these, I simply want one on at a time.
After a bit of difficulty at the start, this is what he came up with.
To switch the monitor off and the TV on:
#!/bin/bash
xrandr --output DVI --off
xrandr --output HDMI --auto
exit
To switch the TV off and the monitor on:
#!/bin/bash
xrandr --output HDMI --off
xrandr --output DVI --auto
exit
Be sure to make the scripts executable before running them.
Although many Ubuntu users seem to hate the Unity Launcher in the most recent versions of Ubuntu, some folks are thinking that it might make a great program launcher for use with a LIRC-compatible remote control, if only the remote could actually navigate the launcher. While no one seems to have brought this idea entirely to fruition, there are apparently ways to make it mostly work:
There are two ways to enable a SOCKS5 proxy at startup in Ubuntu. For either to work, you must have previously configured ssh public/private key authentication, so make sure that works and that you can do a “normal” ssh login without entering a password. Note that the second method described below is better because it is persistent – if the connection goes down, it will attempt to reconnect automatically.
Method 1 (Ubuntu and similar versions of Linux only):
I’ll briefly show the first method, but keep in mind that if the ssh connection is lost, it will not automatically reconnect.
First install screen from the standard repository if you have not done so already, and change the permissions of /run/screen to 775.
In Ubuntu’s Startup Applications Preferences, add this command, replacing the italicized parts with the correct values:
“tunnel” can be any word you like, “username” is your account name on the remote server, “server_address” is the address of the remote server, and “local_socks_proxy_port” is the port number your local software will use when connecting to the SOCKS proxy (7777 is a frequently-used choice).
Ubuntu users, first go into the Ubuntu Software Center and search for autossh (other Linux users, check your repository for the autossh package):
If you click “More Info” you can read the description:
Go ahead and install it, and after installation it will show you which programs can be run:
Mac OS X users, there is an autossh package for recent versions of OS X among the Rudix packages. Be sure to select your version of OS X in the left-hand sidebar, then download the autossh package for your version of OS X and then click on the downloaded package to run the installer:
Click Continue and you will see an “Important Information” screen, the text of which is copied to the bottom of this article in case you want to review it. Note that you do NOT need to do the build procedure shown there; you just continue the installation as you would any other OS X software you have downloaded.
Whether you are installing in Linux or OS X, after you complete the installation the next thing to do is open a terminal window and run autossh manually one time. Remember, you must have previously configured ssh public/private key authentication for this to work. The reason for running autossh manually the first time is that a window will pop up asking you to approve the connection and accept the RSA key. So open a terminal window and run a line of this form:
Ubuntu: autossh -f -N username@server_address -D local_socks_proxy_port Mac OS X: autossh -M 0 username@server_address -D local_socks_proxy_port
As in the first method, “username” is your account name on the remote server, “server_address” is the address of the remote server, and “local_socks_proxy_port” is the port number your local software will use when connecting to the SOCKS proxy (7777 is a frequently-used choice, but it can be any unused port numbered 1080 or above). If the popup appears asking you to approve the connection, answer “yes”, and that should be the last time you see that dialog (unless, perhaps, some drastic changes are made at the server).
Note that under OS X, we could not get the -f option to work, even though it’s supposed to. When we tried to use it, no ssh connection was opened (as determined by watching Activity Monitor). So, unfortunately, you will need to leave a terminal or iTerm window open with autossh running in it, unless you can figure out some way to make backgrounding it work. This was in OS X Lion; perhaps the -f option works in other versions. Feel free to experiment.
After running autossh from a terminal window, open your browser and make sure the SOCKS proxy works. How you configure it will vary by browser. For example, under Firefox you’d open the Preferences pane, select Advanced, click the Network tab, and then click the Settings button. In the window that opens you’d select Manual Proxy Configuration, then for SOCKS Host you can use localhost, and for Port the local_socks_proxy_port number you set when you started autossh. Select SOCKS v5 as the proxy type. In the “No Proxy for:” window, enter some sane values for your network — generally these will include your local machine and other addresses on your local network. For example (assuming your local network addresses are in the 192.168.x.x range):
localhost, 127.0.0.1, 192.168.0.0/16
In Google Chrome you can use an extension such as Proxy SwitchySharp to configure your proxy settings.
After saving those settings, go to a site that will show you the IP address that it thinks you are coming in from, such as http://ipchicken.com/ – make sure that the address it shows is that of the system you are using for your proxy, and not your local address.
Once you are sure it is working, in Ubuntu you can open Ubuntu’s Startup Applications Preferences and add the same line you typed in the terminal window.
Under OS X it’s a little more complicated. If you use iTerm, you could create a Profile (similar to a bookmark) and for the command use the same command you used in the terminal window, but specify the full path to autossh, e.g.:
Name your profile something meaningful, and make sure that when you click on the profile in the sidebar to runs autossh and opens the connection. The use the AppleScript Editor to build a script that will start iTerm and open the profile. Your script could look something like this:
tell application "iTerm"
activate
tell the current terminal
launch session "Profile_name"
delay 3
tell the last session
set name to "Profile_name - SOCKS proxy using autossh"
end tell
end tell
end tell
Substitute the name you gave the profile for the two occurrences of Profile_name in the sample script. Compile the AppleScript and when it compiles with no errors, save it as an Application. Make sure it works as intended (starts up iTerm and loads the Profile that runs autossh), then simply set that application to run at startup (Under System Preferences | Users & Groups | (select current user) | Login Items).
Now your SOCKS5 proxy should start up each time you reboot your system, and if the tunnel goes down it should reconnect within a few minutes. To learn more about autossh, open a terminal window and type man autossh, or see any of these articles (note that some of them overly complicate the process of setting up the tunnel):
autossh is a program to start a copy of ssh and monitor it, restarting
it as necessary should it die or stop passing traffic.
The original idea and the mechanism were from rstunnel (Reliable SSH
Tunnel). With version 1.2 the method changed: autossh now uses ssh to
construct a loop of ssh forwardings (one from local to remote, one
from remote to local), and then sends test data that it expects to get
back. (The idea is thanks to Terrence Martin.)
With version 1.3, a new method is added (thanks to Ron Yorston): a
port may be specified for a remote echo service that will echo back
the test data. This avoids the congestion and the aggravation of
making sure all the port numbers on the remote machine do not
collide. The loop-of -forwardings method remains available for
situations where using an echo service may not be possible.
autossh has only three arguments of its own:
-M [:echo_port], to specify the base monitoring port to use, or
alternatively, to specify the monitoring port and echo service
port to use.
When no echo service port is specified, this port and the port
immediately above it (port# + 1) should be something nothing
else is using. autossh will send test data on the base monitoring
port, and receive it back on the port above. For example, if you
specify "-M 20000", autossh will set up forwards so that it can
send data on port 20000 and receive it back on 20001.
Alternatively a port for a remote echo service may be
specified. This should be port 7 if you wish to use the
standard inetd echo service. When an echo port is specified,
only the specified monitor port is used, and it carries the
monitor message in both directions.
Many people disable the echo service, or even disable inetd,
so check that this service is available on the remote
machine. Some operating systems allow one to specify that the
service only listen on the localhost (loopback interface),
which would suffice for this use.
The echo service may also be something more complicated:
perhaps a daemon that monitors a group of ssh tunnels.
-M 0 will turn the monitoring off, and autossh will only
restart ssh on ssh exit.
For example, if you are using a recent version of OpenSSH, you
may wish to explore using the ServerAliveInterval and
ServerAliveCountMax options to have the SSH client exit if it
finds itself no longer connected to the server. In many ways
this may be a better solution than the monitoring port.
-f Causes autossh to drop to the background before running ssh. The
-f flag is stripped from arguments passed to ssh. Note that there
is a crucial a difference between the -f with autossh, and -f
with ssh: when used with autossh, ssh will be *unable* to ask for
passwords or passphrases. When -f is used, the "starting gate"
time (see AUTOSSH_GATETIME) will be set to 0.
-V to have autossh display its version and exit.
All other arguments are passed to ssh. There are a number of
other settings, but these are all controlled through environment
variables. ssh seems to be appropriating more and more letters for
options, and this seems the easiest way to avoid collisions.
autossh tries to distinguish the manner of death of the ssh process it
is monitoring and act appropriately. The rules are:
- If the ssh process exited normally (for example, someone typed
"exit" in an interactive session), autossh exits rather than
restarting;
- If autossh itself receives a SIGTERM, SIGINT, or a SIGKILL
signal, it assumes that it was deliberately signalled, and exits
after killing the child ssh process;
- If autossh itself receives a SIGUSR1 signal, it will kill the child
ssh process and start a new one;
- Periodically (by default every 10 minutes), autossh attempts to pass
traffic on the monitor forwarded port. If this fails, autossh will
kill the child ssh process (if it is still running) and start a new
one;
- If the child ssh process dies for any other reason, autossh will
attempt to start a new one.
Startup behaviour:
- If the ssh session fails with an exit status of 1 on the very first
try, autossh will assume that there is some problem with syntax or
the connection setup, and will exit rather than retrying;
- There is now a "starting gate" time. If the first ssh process fails
within the first few seconds of being started, autossh assumes that
it never made it "out of the starting gate", and exits. This is to handle
initial failed authentication, connection, etc. This time is 30 seconds
by default, and can be adjusted (see the AUTOSSH_GATETIME environment
variable below).
- NOTE: If AUTOSSH_GATETIME is set to 0, then BOTH of the above
behaviours are disabled. This is useful for, for example,
having autossh start on boot. The "starting gate" time is
also set to 0 with the -f flag to autossh is used.
Continued failures:
- If the ssh connection fails and attempts to restart it fail in
quick succession, autossh will start delaying its attempts to
restart, gradually backing farther and farther off up to a
maximum interval of the autossh poll time (usually 10 minutes).
autossh can be "prodded" to retry by signalling it, perhaps with
SIGHUP ("kill -HUP").
Connection Setup
----------------
As connections must be established unattended, the use of autossh
requires that some form of automatic authentication be set up. The use
of RSAAuthentication with ssh-agent is the recommended method. The
example wrapper script attempts to check if there is an agent running
for the current environment, and to start one if there isn't.
It cannot be stressed enough that you must make sure ssh works on its
own, that you can set up the session you want before you try to
run it under autossh.
If you are tunnelling and using an older version of ssh that does not
support the -N flag, you should upgrade (your version has security
flaws). If you can't upgrade, you may wish to do as rstunnel does, and
give ssh a command to run, such as "sleep 99999999999".
A monitor port value of "0" ("autossh -M 0") will disable use of
the monitor ports; autossh will then only react to signals and the
death of the ssh process.
Environment Variables
---------------------
The following environment variables can be set:
AUTOSSH_DEBUG - sets logging level to LOG_DEBUG, and if
the operating system supports it, sets
syslog to duplicate log entries to stderr.
AUTOSSH_FIRST_POLL - time to initial poll (default is as
AUTOSSH_POLL below).
AUTOSSH_GATETIME - how long ssh must be up before we consider
it a successful connection. Default is 30
seconds. If set to 0, then this behaviour
is disabled, and as well, autossh will retry
even on failure of first attempt to run ssh.
AUTOSSH_LOGFILE - sets autossh to use the named log file,
rather than syslog.
AUTOSSH_LOGLEVEL - log level, they correspond to the levels
used by syslog; so 0-7 with 7 being the
chattiest.
AUTOSSH_MAXLIFETIME - Sets the maximum number of seconds the process
should live for before killing off the ssh child
and exiting.
AUTOSSH_MAXSTART - specifies how many times ssh should be started.
A negative number means no limit on the number
of times ssh is started. The default value is -1.
AUTOSSH_MESSAGE - append a custom message to the echo string (max 64
bytes).
AUTOSSH_NTSERVICE - when set to "yes" , setup autossh to run as an
NT service under cygrunsrv. This adds the -N flag
for ssh if not already set, sets the log output
to stdout, and changes the behaviour on ssh exit
so that it will restart even on a normal exit.
AUTOSSH_PATH - path to the ssh executable, in case
it is different than that compiled in.
AUTOSSH_PIDFILE - write autossh pid to specified file.
AUTOSSH_POLL - poll time in seconds; default is 600.
If the poll time is less than twice the
network timeouts (default 15 seconds) the
network timeouts will be adjusted downward
to 1/2 the poll time.
AUTOSSH_PORT - set monitor port. Mostly in case ssh
appropriates -M at some time. But because
of this possible use, AUTOSSH_PORT overrides
the -M flag.
Logging and Syslog
------------------
autossh logs to syslog using the LOG_USER facility. Your syslog may
have to be configured to accept messages for this facility. This is
usually done in /etc/syslog.conf.
The APC PowerChute utility will only run in Windows, but if you are running Ubuntu Linux (or some variation thereof) you can have pretty much the same thing by following the instructions in this article:
The article suggests you install gapcmon but you probably don’t need to do that, because Ubuntu already includes a Power Statistics utility that works well enough for most users.
If you have problems getting it to work, make sure the USB cable is plugged into the correct jack on the UPS (with some models it’s easy to plug it into a network cable jack by mistake). From the command prompt issue the command lsusb and it will tell you what is connected to your USB ports — you should see an entry for “American Power Conversion Uninterruptible Power Supply” if the cable is correctly connected.
This article includes a small bit of text that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission.
If you have ever tried to access a Linux system using VNC, and your host computer wasn’t particularly fast, you may have noticed that things slow down considerably – you definitely know you’re accessing the computer remotely, even if the access is via a local network link. And even if you don’t have that issue, you might want to know about this alternative.
You can install the NX Free Edition server and client from Nomachine and it works great! Note that NX does not work in precisely the same way as VNC – while VNC lets you take control of the current desktop on the target machine, NX lets each login have its own session and desktop. So you could be using your Linux box and let another family member come into it via NX, and each of you would have your own desktop and session.
Those instructions are somewhat geared toward users of Debian-based distributions such a Ubuntu, Linux Mint, etc. but there are also packages available for systems that utilize RPM or compressed TAR packages rather than DEB. Most experienced Linux users should have no problem figuring out how to adjust the instructions for their particular distribution.
Former title: Installing Ubuntu Linux (or Mythbuntu) in place of OS X on a Mac Mini (changed because this article is now less specific to Ubuntu or the Mac Mini).
Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
All computers have their day in the sun, and then something new comes along that makes them less desirable. I have a Mac Mini that I acquired sometime around the time OS X Leopard came out, probably in 2009. As time went by it became slower and slower and I finally replaced it. However, it seemed a bit of a shame to have it just sitting in a closet doing nothing, so I decided to see if I could put Ubuntu Linux 12.04 (at that time the most recent LTS version) on it. I started out by trying to follow the instructions on this page (the Single Boot/MBR option) but ultimately it turned out to be not nearly that complicated. NOTE THAT THIS WILL NOT GIVE YOU A DUAL BOOT SYSTEM; THIS IS REPLACING OS X WITH UBUNTU LINUX, AND ALL YOUR EXISTING DATA ON THE HARD DRIVE WILL BE ERASED!!! YOU HAVE BEEN WARNED!!!
Also: THIS IS FOR EXPERIMENTAL AND INFORMATIONAL PURPOSES ONLY. This is what worked for ME. This MAY or MAY NOT work for you. It may even brick your system (if that should happen, try doing a PRAM reset before you totally panic). It did not do that to me, and I have never heard of anyone having that problem, but your hardware may be a bit different than mine, so I make NO guarantees!!! Here’s all I wound up having to do:
Connected a USB keyboard and mouse.
Before proceeding I made sure I had the latest firmware upgrade – that is very important since you can’t do it once you have installed Ubuntu, and the rest of this might not work if you have old firmware. Another thing you can’t do is disable the startup chime so if you don’t want that after Linux is installed, find a way to turn it off before proceeding (I wanted it, and it’s used in the instructions that follow, so I didn’t search for a way to disable it, and I don’t recommend you do either).
Inserted my old OS X Leopard installation CD (any OS X installation CD that works with the Mac should be fine for this procedure)
Rebooted while holding down the “C” key
Accepted the default language (English) and pressed Enter
From the top menu bar, I selected Utilities | Disk Utility
In Disk Utility I selected the internal hard drive in the left hand side panel. You have to select the drive itself (it shows the brand name of your drive), not the partition
Clicked the Partition tab, selected 1 Partition under the Volume Scheme (instead of Current)
Clicked the Options button and selected “Master Boot Record”
Clicked the Continue button (this erases the hard drive)
When the above finished, I quit Disk Utility, then quit the installer
The Mac rebooted — at that point I clicked and held the leftmost mouse button until the CD ejected
Inserted the Ubuntu Install CD, then power cycled the Mac Mini
At the startup chime I pressed the “C” key to boot from the CD
When the Ubuntu CD boots, you are given the option to install Ubuntu directly, or to try Ubuntu (which takes you to the Ubuntu desktop). As it turns out, I could have simply ran the installer. Instead, I did it from the desktop because I was following some instructions that said you have to type in some things during the install, and you need to have access to a terminal window to do that. But when I tried to type those things in, Ubuntu rejected them with errors, so I just let it complete the install (answering the questions it asked during the install). I did NOT select any special partitioning, etc. – I pretty much did a plain vanilla installation, generally accepting the defaults except where they weren’t appropriate or weren’t what I wanted.
Important
NOTE: If, when you boot into the Ubuntu installation CD, you are greeted with a screen that asks you to “Select CD Rom boot type” but you cannot select anything because neither the keyboard nor the mouse are functional, or if you get a black screen at some point early in the install process, then you may need a special build of Linux intended for use with 64-bit Macs that use a 32-bit EFI. Such models were mostly manufactured in the last half of the 2000’s. In that case you can try the solution offered here, if you can understand the instructions, or you can see if you can find a suitable ready-made .iso file at Matt Gadient’s site (note that even though it says “late 2006 models” in the title, those builds should work with late 2006 and later 64-bit Macs that use a 32-bit EFI).
When the install was finished (after quite some time), I rebooted. The only unusual thing was that after the reboot, the screen remains white for about 20-30 seconds right at the start of the reboot. Then after that delay, it finally decides it will load Ubuntu. That still happens and while it makes the startup take a bit longer, I’ve seen worse. The reason for this (and a possible fix) can be found here: Reducing the 30 second delay when starting 64-bit Ubuntu in BIOS mode on the old 32-bit EFI Macs.
Oh, and the sound was muted by default for some reason, and the volume slider set all the way down. After I unmuted it and turned up the volume slider, the sound worked normally.
The wired network connection worked fine. I don’t use WiFi here so I did not test that. If you have issues with those, or any other issues see GNU/Linux Debian on a Macbook Pro 11-1, which contains some additional hints that may make things run more smoothly (or work at all) after installation. I would use any hints on that page only if you have one of the specific issues that the author had. Another page with possibly useful additional hacks to make this work is Mac book pro 11.3 Linux customization (2): grub and hardware, which may be helpful if you have issues with an unrecognized Intel Iris GPU or Thunderbolt, but again I would only use these if you really need them, since this article is from 2014 and such hacks may no longer be necessary (by the way, this blog has several other pages of rather technical hacks for using Linux on a Mac Book Pro, and while many users will not need any of them, you can search that site for the phrase “Mac book pro 11.3 Linux customization” to find the other articles).
The only real hitch I found was that it wouldn’t boot if I didn’t have a video display connected! I have no idea why that was the case but there is a hardware workaround described on this page. Hope you didn’t misplace your Mac Mini’s DVI to VGA adapter! I had a 100 Ω resistor handy and that seems to work fine (it’s probably about 40 or 50 years old but what the heck, carbon resistors don’t change value that much just sitting in a junk box). If you can’t find the DVI to VGA adapter, I have read that at least one user placed a resistor directly into the DVI port between pins C2 and C5; you can use this pinout diagram to find those pins. However, I have not tried this, so I make no guarantees. Either way, the point is that the resistor goes between the analog green signal output and the analog ground return. If you can’t find the adapter, can’t get this to work, or if you just don’t want to mess around with a resistor, you can try a DVI Emulator/Dummy Plug that includes an EDID chip, that may be available from Amazon or eBay. A DVI 1920×1080 or 1920×1200 model should be sufficient. Such a device fools the Mac Mini into thinking a display is connected.
After I had this running for a year or two I read that Ubuntu doesn’t control the system fan properly. You can do this in some newer versions of Ubuntu (and possibly other Linux builds) to get fan control to work. First, try using your chosen Linux distribution’s Software Center or package manager to search for and install the macfanctld package (after you check for updates). If that doesn’t work, try this (assuming you’re using a Ubuntu or Debian based distribution):
sudo apt install -y macfanctld
On my system at least, it appeared that this did cause the fan to run a bit faster but not enough that I really noticed it. Once it is installed, you can type man macfanctld at a Linux command prompt to get configuration instructions. Changes to temperature limits and minimum fan speed are made in the file /etc/macfanctl.conf.
Also, although I have not personally done this, I have read on a couple of pages that you can enable automatic reboot after a power interruption by adding one line to /etc/rc.local (this may be Ubuntu-specific, but you can always remove it if it doesn’t work):
setpci -s 0:1f.0 0xa4.b=0
If you have smb or samba installed (it is installed by default in many distributions) and find that your samba/smb log files fill up with complaints such as “Unable to connect to CUPS server localhost:631 – Connection refused”, here is a workaround. In the [global] section of /etc/samba/smb.conf add these lines:
printing = bsd
printcap name = /dev/null
Then from a command prompt restart samba:
sudo service smbd restart
Long ago I read a post on Reddit where the author said, “After months of headaches and tinkering I’ve finally found the stupid way to let Linux work properly on Macs. Just add acpi_osi=Darwin as boot parameter.” Unfortunately I did not save a link to that post so I have no idea if still valid advice, and therefore I would only try it if something (particularly Thunderbolt) isn’t working right and you can’t resolve it any other way. If you understand Linux kernel stuff see the final paragraphs of this page for a discussion of this setting, also see Section 2 on this page. If you don’t use the Thunderbolt port then you probably don’t need this, and you may not anyway.
By the way, I had intended to try Linux Mint but they no longer offer a version that fits on a CD, and I still have about a gazillion blank CDs (plus I already had Ubuntu 12.04 burned to CD) and since the Mac Mini doesn’t have a BIOS in the traditional sense, there is no way to install from a USB stick, so Ubuntu it was. For what I plan to do with this, having Mint would be no advantage. Many older Macs have issues booting from a USB memory stick, although one site I read said that they might be able to if you use UNetbootin to transfer the Linux image file to the USB stick. I did not attempt that, so I cannot say whether that works. I got it to work using a CD, but I do realize that CD and DVD burners are becoming somewhat of a scarce item these days.
Note that nowhere above did I mention a program called rEFIt, nor did I mention BootCamp. I didn’t need either of those.
Had this not worked I could have always reinstalled Leopard, but again, for what I was doing with this system (running a Tvheadend backend, for one thing) Linux was probably a better choice, but I still wanted to be able to use this as a backup regular desktop computer, should the need ever arise.
One final note: This is the xorg.conf I used with my “headless” system. It came from this blog post and I did have to save it as /etc/X11/xorg.conf and not the filename shown in the post (in newer versions of Linux I believe this location may have moved yet again, so you may need to search to find the correct location for the xorg configuration for your distro). Note this is only something you might consider using if you have installed a version of Linux that includes a desktop; you don’t need this if you have a server-only version of Linux that has no desktop installed (one where you do everything from a Linux command prompt):
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
Unity 2D from Ubuntu 11.04 (Photo credit: Wikipedia)
If you hate the Unity interface in the latest version of Ubuntu, try this. From a terminal prompt, enter:
sudo apt-get install gnome-session-fallback
I’d assume that you could also install gnome-session-fallback from Synaptic if you prefer. Then, choose “GNOME Classic” at signon.
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
Image via Wikipedia
Here’s a program that may be useful for those of you who, like me, sometimes find ourselves at a Linux command prompt trying to recall the syntax of a command we use frequently (because, you know, it would never have occurred to the designers of Linux to actually implement commands with names that have a clear meaning in plain English):
Alias are a great tool to help increment your productivity on the terminal with bash (or any shell program you’re using), but usually we are too lazy to think at what are the most common, or long commands that we use frequently and prepare an alias for them.
And so someone has done a small piece of software to do this job: aliaser
Aliaser helps you identify frequently typed commands and creates bash aliases for them. Aliaser analyses your bash history and helps you identify commands that you use frequently.
One thing they forgot to mention is that once you’ve added an alias, it won’t actually be available for use until you log out and then log back in. Also, you can delete the aliaser file and temporary directory from your /tmp directory once installation is complete. If you ever want to uninstall aliaser, just remove the three lines added to your .bashrc file, remove the ~/.aliaser directory, and remove the /usr/bin/aliaser file.
One way I find this useful is to make commands I can’t remember into ones that that I can remember. For example, I did this:
aliaser add processes “ps awx”
The Linux purists are probably rushing to comment that I just turned a six character command into a nine character one. Yes, BUT, I can actually remember the word “processes”, whereas I cannot remember the options I need to use after “ps” to get the output I want. The designers of Linux seem to not realize that some of us users have really bad memories. Another use for this is turning arcane Linux commands into the equivalent Windows commands that you’re familiar with. You could do this:
aliaser add dir “ls -al”
So that when you type “dir”, you get a directory listing similar to what you are used to.
If you can’t even remember the aliases you’ve created (yeah, my memory really is that bad some days), just use aliaser show to see all the aliases you’ve added.
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
If you are a Mac user, you’ve probably heard of Little Snitch. It’s a commercial (as in, not free) program that lets you allow or deny connections to the Internet from individual applications. One reason for using such a program is to detect software that should have no reason to connect to the Internet nevertheless attempting to do so. For example, you download a free screensaver (dumb move to start with) and it sends all the personal information it can find on you to some group of hackers on the other side of the world. A program like Little Snitch would let you know that the screensaver is trying to connect to the Internet, and allow you to deny that connection. In the Windows world, I believe that ZoneAlarm has a similar capability, and it’s also a commercial (as in, not free) program.
Leopard Flower personal firewall for Linux OS screenshot
It appears that these is a similar program for Linux users, and it IS free! It’s called Leopard Flower and it’s described as a “Personal firewall for Linux OS (based on libnetfilter_queue) which allows to allow or deny Internet access on a per-application basis rather than on a port/protocol basis.”
Looking at the screenshot it appears to have very much the same per-application blocking functionality you’d get in one of those other programs. I have not personally tried it yet, but I wanted to create a post about it so if someday in the future I am trying to remember the name of this program, I’ll know where to find it (yes, this blog does sort of serve as my long-term memory!). 🙂
Douane personal firewall for GNU/Linux screenshotDuane configurator screenshot
The only downside to this one is that as of this writing the only available package is for Arch Linux but if you want to try to build it for a Ubuntu or Debian system, they provide a page showing the needed dependencies.
There is an older similar program called TuxGuardian but apparently is hasn’t been updated since 2006, so I have no idea if it will even work with current versions of Linux. And as for you Android users, try the NoRoot Firewall app.
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
Image via CrunchBase
I’ve seen this happen several times now on Ubuntu-Linux based systems that have NVIDIA graphics. What happens is that “Update Manager” pops up and tell you there are updates for your software, and you accept them. It then tells you that your system has to be rebooted. And when you do that, you get no video, or text only. What probably happened was that the updates you installed included an update to the Linux kernel, and the NVIDIA graphics driver currently installed on the system was compiled against the OLD kernel.
Note that this generally can only happen if you manually updated the NVIDIA graphics driver at some point. If you always installed it from the standard repositories for your distribution, you’ll probably never see this issue. So a word to the wise — when you finally get around to doing an upgrade of your Linux distribution, try to avoid manually installing the NVIDIA graphics driver. Instead, let the distribution pull it from its repository. After that, you should not have this issue in the future. By the way, if you currently are running Ubuntu, we recommend upgrading to Linux Mint rather than a newer version of Ubuntu. Linux Mint is very similar to Ubuntu, but leaves out some of the things that users seem to hate about newer releases of Ubuntu. More to the point, they are not currently talking about switching their base graphics system from the X window server system to a new display manager, which I have a feeling might cause problems for some NVIDIA graphics users.
But if you’re not yet ready to do a full reinstall of Linux, the fix for this problem is easy IF you had the foresight to set up SSH access to your Linux system BEFORE the trouble started. If you didn’t, and you’re not a true Linux geek, you may be kind of screwed. So if you’re reading this and your system is working fine, and you haven’t yet set up SSH access, you may want to do that. There are several sites that tell you how to do that; here are two that I found using Google:
If you didn’t do this beforehand, you may still be able to do it if you can get to a command prompt.
Anyway, the actual fix is to (re-)install the latest NVIDIA driver for your system. They will be compiled against the new Linux kernel and then everything should work fine. To find the correct NVIDIA driver, go to the NVIDIA Driver Downloads page, and use the dropdowns to select the correct driver for your system. Download it to your local system, then upload it to your Linux PC (if you have SSH access working then you can use an SFTP client, such as WinSCP or Transmit, to upload your driver file). Once you have it on your PC, from a command prompt navigate to the directory where you put the driver and then change the permissions to make it executable:
sudo chmod +x driver_upgrade_script_filename
Now try running the script (it should have a .run extension):
sudo ./driver_upgrade_script_filename
It should not complain that the Gnome Display Manager or KDE Display Manager is running (if it were, you wouldn’t be in a state of near-panic right now), but if you were just doing a regular update you’d have to do this when the GDM/KDM is stopped. For a guide that covers that scenario, see How To Install Official Nvidia Drivers in Linux, or just know that to stop the display manager,
sudo /etc/init.d/gdm stop
should stop the Gnome Display Manager, or if you’re using KDE then the command would be
sudo /etc/init.d/kdm stop
Most sources I’ve seen suggest that you answer yes to any questions the installer may ask. The only one I’d be cautious about is letting it create a new xorg.conf if you are using a customized one (which you may well be if you’ve used any of my previous HTPC-related articles). If you have edited xorg.conf, then I’d make sure you at least have a backup before letting the installer create a new one, so you can revert back to your custom one (or compare the two and insert your customizations into the new one) if necessary.
Under Ubuntu, you may get a message similar to “Provided install script failed”. That will happen every time you update the NVIDIA driver this way and it is normal. Just ignore it and continue the installation. If you get “Error locating kernel source”, run sudo apt-get install kernel-source from the command prompt, then run the driver upgrade script again.
When the installer has successfully finished, reboot the system and when it comes back up, hopefully you should be happy again!
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy
Recent Comments