I recently stumbled upon F.lux, an application for Windows, Mac OS X and Linux that changes the color temperature of your display depending on the time of day. Although changing your color temperature is nothing new, F.lux makes it completely seamless: Just set your location and your desired color temperatures (optional), then forget about it.
From the author:
Ever notice how people texting at night have that eerie blue glow? Or wake up ready to write down the Next Great Idea, and get blinded by your computer screen? During the day, computer screens look good—they’re designed to look like the sun. But, at 9PM, 10PM, or 3AM, you probably shouldn’t be looking at the sun.
F.lux fixes this: it makes the color of your computer’s display adapt to the time of day, warm at night and like sunlight during the day. It’s even possible that you’re staying up too late because of your computer. You could use f.lux because it makes you sleep better, or you could just use it just because it makes your computer look better.
Get it here.
Many NAT firewalls time out idle sessions after a certain period of time to keep their trunks clean. Sometimes the interval between session drops is 24 hours, but on many commodity firewalls, connections are killed after as little as 300 seconds. To avoid having your SSH sessions become unresponsive after e.g. 5 minutes, do the following:
On Windows (PuTTY)
In your session properties, go to Connection and under Sending of null packets to keep session active, set Seconds between keepalives (0 to turn off) to e.g. 300 (5 minutes).
On Linux (ssh)
To enable the keep alive system-wide (root access required), edit /etc/ssh/ssh_config; to set the settings for just your user, edit ~/.ssh/config (create the file if it doesn’t exist). Insert the following:
Host *
ServerAliveInterval 300
ServerAliveCountMax 2
You can also make your OpenSSH server keep alive all connections with clients by adding the following to /etc/ssh/sshd_config:
ServerAliveInterval 300
ServerAliveCountMax 2
These settings will make the SSH client or server send a null packet to the other side every 300 seconds (5 minutes), and give up if it doesn’t receive any response after 2 tries, at which point the connection is likely to have been discarded anyway.
From the ssh_config man page:
ServerAliveCountMax
Sets the number of server alive messages (see below) which may be sent without ssh(1) receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session. It is important to note that the use of server alive messages is very different from TCPKeepAlive (below). The server alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by TCPKeepAlive is spoofable. The server alive mechanism is valuable when the client or server depend on knowing when a connection has become inactive.
The default value is 3. If, for example, ServerAliveInterval (see below) is set to 15 and ServerAliveCountMax is left at the default, if the server becomes unresponsive, ssh will disconnect after approximately 45 seconds. This option applies to protocol version 2 only; in protocol version 1 there is no mechanism to request a response from the server to the server alive messages, so disconnection is the responsibility of the TCP stack.
ServerAliveInterval
Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will send a message through the encrypted channel to request a response from the server. The default is 0, indicating that these messages will not be sent to the server, or 300 if the BatchMode option is set. This option applies to protocol version 2 only. ProtocolKeepAlives and SetupTimeOut are Debian-specific compatibility aliases for this option.
By far the easiest way to set up a simple connection proxy is to use the SSH tunneling feature of either PuTTY on Windows or SSH on Linux. This lets you establish connections to servers and ports that you might not be able to access (e.g. from work), as long as you can connect to your server’s SSH service (e.g. myserver.com port 22). This might be for privacy reasons, to connect to MSN from work, to browse a blocked website, et cetera.
On Windows Machines
- Download and open PuTTY
- In the fields ‘Address’ and ‘Port’, enter the address and port for your SSH server
- Go to ‘Connection’ -> ‘SSH’ -> ‘Tunnels’ on the left-hand side
- In ‘Source port’, enter 31337, then click the button ‘Dynamic’ and then ‘Add’
- Go back to the main ‘Session’ screen
- In the ‘Saved Sessions’ text box, enter e.g. “My Shell” and click ‘Save’
- Double-click “My Shell” to establish a connection, then log in to your shell
- In any application that supports connecting through a proxy, set the following settings:
- Proxy type: SOCKS 5
- Proxy server: 127.0.0.1
- Proxy port: 31337
You can also set these as your global proxy settings in Windows (via ‘Control Panel’ -> ‘Internet Properties’ -> ‘Connections’ -> ‘LAN settings’ -> “Use a proxy server for your LAN” -> ‘Advanced’ -> ‘Socks’: 127.0.0.1:31337. This will cause most applications to connect through the SSH tunnel to your server.
In the future, just open PuTTY and double-click “My Shell” to open your shell and activate the SSH tunneling.
On Linux Machines
- Open a terminal
- Enter e.g.:
ssh -D31337 myuser@myserver.com -N
- Log in to your shell
- In any application that supports connecting through a proxy, set the following settings:
- Proxy type: SOCKS 5
- Proxy server: 127.0.0.1
- Proxy port: 31337
Alternatively, enter e.g.: ssh -L 31337:patrickmylund.com:80 myuser@myserver.com -N. Here, you specify the target host and port before-hand; the result is that all connections to 127.0.0.1 port 31337 will be tunneled through your server, myserver.com, using your username, myuser, to the target machine, patrickmylund.com, port 80.
The SSH tunnel will stay active until you close the terminal window or hit CTRL+C (Linux), or close PuTTY (Windows).
Grab your windbreaker jacket cause it’s a cold, stormy day in hell. Microsoft is going to release the Windows 7 USB/DVD download tool under the GNU General Public License, the de facto Open Source license.
Okay, so they might have a strong moral, even legal, obligation to do so since the tool contains code licensed under the GPL already (you cannot change source code licensed under the GPL without making your changes publicly available under the same terms) — still, it’s the thought that counts, ..right?
See Microsoft Open Source Community Manager Peter Galli’s official announcement and the original license violation claim by Rafael Rivera Jr. for more information.
Ninite lets you construct a custom installation package containing different software of your choice. This package then installs all of the applications in one go, using their default settings — it also tries to skip any toolbar installations and other annoyances automatically.
Automatix was a dangerous abomination, code-wise, but its concept was noble. Ninite seems to be striving for something similar (albeit saner) on Windows. If you’re lazy, and you don’t mind trusting a third party too much, you should give it a try.
outSSIDer is the lonely little application that’s there for you when you drop your phone in the big city and you really need to twitter about it. Get the laptop, open outSSIDer, close the lid, then start walking around. When it makes a successful connection to a wireless network, it’ll make a ding sound. If it is then successful in retrieving a file (in this case, Google’s favicon) from the great internet, it’ll start dinging frantically. If not, well, it’s the hi-hat, of course.
Download it here.
I wasn’t joking about closing the laptop lid, by the way — you stand out a little when you walk around looking at an open laptop making cymbal noises.
outSSIDer is based on inSSIDer, a Wi-Fi diagnostics tool.
You are sitting at your PC, relaxed and minding your own business. Happy. Suddenly and without warning, Windows decides to throw a fit and bombards you with the infamous Blue Screen of Death! You get angry — furious, in fact — and perhaps a little scared. You never got a chance to see what happened at the dreadful moment.
With Minilyzer and Microsoft’s Debugging Tools for Windows, you can easily and quickly figure out what caused a blue screen (or a seemingly spontaneous reboot), by analyzing what is called a Minidump, a file that is created by Windows whenever there is a STOP error (blue screen).
Analyzing the Minidump
Follow the steps below to generate a report containing the details of the blue screen.
- Download and install the 32-bit or 64-bit version of Microsoft’s Debugging Tools for Windows. If you are not sure what version to get, get the 32-bit version.
- Download the minilyzer.cmd script to somewhere convenient (like the desktop).
- If you want to analyze the latest blue screen and are running Windows XP (or Vista/Windows 7 with UAC disabled), run minilyzer.cmd and skip to step 6.
- Navigate to the C:\Windows\Minidump folder and find the latest Minidump file, e.g. Mini012309-01.dmp.
- Copy the Minidump file to your desktop, then click and drag it onto the minilyzer.cmd script that you downloaded.
- Don’t be frightened by all of the information displayed in the window that pops up. If it’s the first time you are using Minilyzer, this will take a while. Relax, grab a drink and a powerbar, and wait until the Minilyzer report is opened.
Finding the Cause
When the report is opened, scroll to the very bottom and look at the last three lines: DEFAULT_BUCKET_ID, MODULE_NAME and IMAGE_NAME. These are what will usually tell you what has happened.
Here’s what they might look like:
- DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
- MODULE_NAME: L1E60X64
- IMAGE_NAME: L1E60X64.sys
Okay, so there’s something wrong with one of our drivers, but what is L1E60X64? A quick search on Google will show that it is the 64-bit version of the Atheros AR8121/AR8113/AR8114 ethernet driver. We have our culprit!
Fixing the Problem
In most cases, a simple driver update will fix problems like these. You can usually find drivers on your PC manufacturer’s website, the manufacturer of your motherboard, or directly from the manufacturer of the device itself. In the case above, installing the Atheros AR81Family 1.0.0.40 driver from Atheros’ drivers page solved the problem.
Of course, not every blue screen happens because of a driver issue. If you are not able to find out what caused a crash, the reports generated by Minilyzer are detailed enough to send to a geeky friend and/or a technical support service. You can find the reports in the folder where you saved minilyzer.cmd.
Cleaning Up
When you are done using Minilyzer, you can safely delete minilyzer.cmd and the Debugging Symbols folder that was created. If you think you might need to analyze more Minidumps in the future, you can keep minilyzer.cmd and the Debugging Symbols folder in the same folder to speed up any future analyses.
To find out more about Minilyzer, have a look at the Minilyzer project page.
