def collatz(n:BigInt):Stream[BigInt] =That was a fun little diversion!
if (n == 1) {
Stream(1);
} else {
def next(n:BigInt):BigInt = if ((n % 2) == 0) (n / 2) else (n * 3 + 1);
Stream.cons(n, collatz(next(n)));
}
Friday, March 5, 2010
Collatz
After seeing the xkcd on the Collatz Conjecture, I had to write an example in Scala.
Friday, February 5, 2010
A little less noise, please.
If you work in big corporate America, like I somehow find myself these days, then the server hosting your Git depot has a really annoying /etc/issue file, which you see every time you clone/push/pull/fetch. In my case, it's 20+ lines of noise.
Finally found the magic to suppress the issue. Put the following lines in your ~/ssh/config file.
Finally found the magic to suppress the issue. Put the following lines in your ~/ssh/config file.
Host git-depot-serverEnjoy :-)
LogLevel ERROR
Monday, February 1, 2010
IDEA + git, without the passwords
Git is my new favorite in source control. IntelliJ IDEA has long been my favorite IDE.
A nuisance lately has been IDEA prompting me for my SSH key password every time I Commit and Push. Since forever, Ubuntu has added my key to ssh-agent every time I login, giving me both good security and password-less pushing from the command line.
I finally found the config tweak to push from IntelliJ without the prompt.
By using the native SSH client, you take advantage of native key management, like ssh-agent.
A nuisance lately has been IDEA prompting me for my SSH key password every time I Commit and Push. Since forever, Ubuntu has added my key to ssh-agent every time I login, giving me both good security and password-less pushing from the command line.
I finally found the config tweak to push from IntelliJ without the prompt.
Settings-->Version Control-->VCSs-->Git
SSH Executable: Native
By using the native SSH client, you take advantage of native key management, like ssh-agent.
Friday, October 2, 2009
Agreement
Yes! I mean No! I mean I Agree!
in reference to:"Any statics whatsoever Implementation inheritance (subclassing) Primitives Unnecessary boilerplate"
- noop - Project Hosting on Google Code (view on Google Sidewiki)
Monday, September 22, 2008
Mouse broke in Fedora 9? Here's a fix!
Last Friday, I was greeted by the unfortunately behaviour that my mouse stopped working. I checked my yum logs, and the culprit looked to be some recent updates to Xorg.
Looks like I guessed correctly. Someone was nice enough to post details about the problem, and how to fix it.
Thank you twilightomni!
Looks like I guessed correctly. Someone was nice enough to post details about the problem, and how to fix it.
Thank you twilightomni!
Friday, September 19, 2008
Changing the gnome-keyring-password on Fedora 9
Fedora 9 improved its integration with the Gnome Keyring Manager over Fedora 8, in that your login password is used to automatically unlock the login keyring.
Which works great... until you change your login password. Changing the keyring password is similar to what one would do on Ubuntu, but a bit different.
Which works great... until you change your login password. Changing the keyring password is similar to what one would do on Ubuntu, but a bit different.
- Install seamonkey
sudo yum -y install seamonkey - Run it
seamonkey - Edit->Preferences->Password Keyrings
- Select the 'login' keyring, and click 'Change Unlock Password'
Saturday, February 23, 2008
Living in a virtual world
I have been extremely happy running Fedroa 8 on my ThinkPad T61. Dual screen works when I'm docked; wireless works around the house; all Linux, all the time. There are, unfortunately, a couple of minor hiccups.
The IT department at work is very Windows centric. The wireless is WPA2, using MSCHAP/PEAP for authentication. This should work with F8, but I can't quite get the config right. Then there's the VPN - it's this Windows only CheckPoint client. I think this is standard IPSec/IKE, so I should be able to divine out the config necessary to setup OpenSWAN. But I've yet to be successful figuring it out.
I've kept the Windows partition around for those few apps that I use that are Windows only. When I need wifi at the office, or VPN on the road, I just boot into Windows and I get it. But there's all of this Linux-y goodness on my laptop that's inaccessible; potential waiting to be tapped. And since I used LVM, not even tools that allow reading ext3 partitions work.
So what's a guy to do? I finally decided to try booting my Linux partition within VMWare, with Windows as the host OS. Things worked out much better than I expected.
For those adventurous enough to try this themselves, let me cover a few of the highlights.
Take ample backups before you begin. It's entirely possible that you could trash your Windows partition, your Linux partition, or even both. A small USB/Firewire drive and an hour or two to run the backups are all you'll need for the peace of mind that you can recover from such a dangerous undertaking.
Be sure your system boots into Linux by default. Windows is the VMware host, and with this setup, you could boot the very same partition under the VMware guest. This would wreak untold havoc, and is best avoided. Even if you configure the bootloader to prompt forever asking you to make a choice, make sure that the default choice is not the VMWare host. Besides, you only run Windows when you have to; right :-)
Be prepared to tweak your X settings. X configuration is probably the last bit of voodoo/black magic/unholy art within the usual operation of a Linux server that I know almost nothing about. (Well, that and Sendmail. Oh, yeah, and Bind. Maybe I'm not as smart as I thought...) But, as soon as you boot into VMware, X will fail to startup and you'll be staring at X's debug messages, thinking that a world of 80x24 really couldn't be all that bad. I was able to get to a not-quite-miserable place, where I can get displays to work for both native and VMware boots, with only a single line change to a config file when needed. (And a special thanks to the Gentoo guys who already did this sort of thing).
Use a NAT network interface instead of a bridge. Normally, in VMware, you want your guest NIC to be bridged. However, on a laptop this is less than ideal. I'm not sure the virtual NIC will adjust as the real network adjusts. And I'm certain that it would not have access to the VPN, which is the main point of this exercise. So go with a NAT interface. You won't be able to access the virtual guest from anywhere but the VMware host, and you will have trouble with non-NAT friendly protocols. But I'm willing to bet that's less trouble than the alternative.
Disable snapshots. While the VMware snapshot facility sounds nice, it doesn't work so well when you boot directly into the virtual guest. Go ahead and turn it off in the virtual machine settings; you won't miss it.
Add a sound device. With this and fullscreen mode, you'll be asking yourself "Is it live, or is it VMware?"
I was surprise that I didn't have any more trouble than I did. I have the Windows partition mounted within Linux, but it recognized that it wasn't cleanly unmounted and refused to mount. The VMWare NIC shows up as eth1. I didn't even have to install VMware Tools for the mouse to auto-transition to and from the VMware console.
The IT department at work is very Windows centric. The wireless is WPA2, using MSCHAP/PEAP for authentication. This should work with F8, but I can't quite get the config right. Then there's the VPN - it's this Windows only CheckPoint client. I think this is standard IPSec/IKE, so I should be able to divine out the config necessary to setup OpenSWAN. But I've yet to be successful figuring it out.
I've kept the Windows partition around for those few apps that I use that are Windows only. When I need wifi at the office, or VPN on the road, I just boot into Windows and I get it. But there's all of this Linux-y goodness on my laptop that's inaccessible; potential waiting to be tapped. And since I used LVM, not even tools that allow reading ext3 partitions work.
So what's a guy to do? I finally decided to try booting my Linux partition within VMWare, with Windows as the host OS. Things worked out much better than I expected.
For those adventurous enough to try this themselves, let me cover a few of the highlights.
Take ample backups before you begin. It's entirely possible that you could trash your Windows partition, your Linux partition, or even both. A small USB/Firewire drive and an hour or two to run the backups are all you'll need for the peace of mind that you can recover from such a dangerous undertaking.
Be sure your system boots into Linux by default. Windows is the VMware host, and with this setup, you could boot the very same partition under the VMware guest. This would wreak untold havoc, and is best avoided. Even if you configure the bootloader to prompt forever asking you to make a choice, make sure that the default choice is not the VMWare host. Besides, you only run Windows when you have to; right :-)
Be prepared to tweak your X settings. X configuration is probably the last bit of voodoo/black magic/unholy art within the usual operation of a Linux server that I know almost nothing about. (Well, that and Sendmail. Oh, yeah, and Bind. Maybe I'm not as smart as I thought...) But, as soon as you boot into VMware, X will fail to startup and you'll be staring at X's debug messages, thinking that a world of 80x24 really couldn't be all that bad. I was able to get to a not-quite-miserable place, where I can get displays to work for both native and VMware boots, with only a single line change to a config file when needed. (And a special thanks to the Gentoo guys who already did this sort of thing).
- move /etc/X11/xorg.conf to xorg.conf.bak
- restart X (init 4; init 5)
- login; run system-config-display
- configure the display as you like it, this will generate a new xorg.conf
Use a NAT network interface instead of a bridge. Normally, in VMware, you want your guest NIC to be bridged. However, on a laptop this is less than ideal. I'm not sure the virtual NIC will adjust as the real network adjusts. And I'm certain that it would not have access to the VPN, which is the main point of this exercise. So go with a NAT interface. You won't be able to access the virtual guest from anywhere but the VMware host, and you will have trouble with non-NAT friendly protocols. But I'm willing to bet that's less trouble than the alternative.
Disable snapshots. While the VMware snapshot facility sounds nice, it doesn't work so well when you boot directly into the virtual guest. Go ahead and turn it off in the virtual machine settings; you won't miss it.
Add a sound device. With this and fullscreen mode, you'll be asking yourself "Is it live, or is it VMware?"
I was surprise that I didn't have any more trouble than I did. I have the Windows partition mounted within Linux, but it recognized that it wasn't cleanly unmounted and refused to mount. The VMWare NIC shows up as eth1. I didn't even have to install VMware Tools for the mouse to auto-transition to and from the VMware console.
Subscribe to:
Posts (Atom)
