An example of one game type with the game and music sped up a bit can be seen here on Youtube:

Audiosurf - Tank! (Live)

I have some European heavy metal that is insanely difficult on the medium and high settings. A great way to kill 20 minutes of time once in a while.

On the other end of the spectrum is a game still under development called “fl0wer”. From some of the people behind the flash game “fl0w” the game fl0wer is more of a meditation tool than what many would recognize as a game.

Here is a great video that shows off the basics:

An HD version of this video and other videos can be found on the GameTrailers website under fl0wer.

In my opinion fl0wer is something that could really only be enjoyable with a HDTV and modern sound system. The fact the game is coming out for the PS3 is not a coincidence.

Study Finds Young People Remain Apathetic About Office Politics

In the Network World article “Comcast pitches IPv6 strategy to standards body” the Cable ISP discusses their current plans on how to migrate their customers to IPv6.

The summary of what happens once Comcast runs out of IPv4 address to give to its customers:

Customers get a new cable modem or router device that does real routed IPv6. You get a real IPv6 address or range of IPv6 addresses and your home network is a directly connected fully functional member of the IPv6 world.

Newer customers won’t get their own IPv4 address anymore. Existing customers would retain their ability to get an IPv4 address for a while but nothing is guaranteed. The modem or home router will hand out private addresses to your home computers and devices. Any attempt to contact the outside IPv4 world will be blindly tunneled over IPv6 to a NAT router that Comcast runs in one of their data centers. Multiple customers will share the same IPv4 address and NAT will be used for all IPv4 connections. This will hurt or possibly prevent many forms of P2P over IPv4. Assuming they didn’t firewall off all incoming IPv6 connections these P2P tools would work normally over IPv6.

At a quick glance it doesn’t seem like an unworkable plan. Of course being NATed by your ISP and not by a router you control will just plain suck. I’d strongly suspect any “NAT” solution they implement on their servers will have to do some inspection of connections (similar to Linux’s conntrack modules) and do a bit more than straight NAT to work around common application problems. Unfortunately if the ISP can’t get any new IP allocations at a reasonable cost and is truly out of IPv4 address then the customer is crap out of luck. The question is exactly under which conditions the transition would start and what restrictions they would place on the IPv6 end of things. And I hope they will read their RFCs and hand out the RFC recommended number of IPv6 IPs to every customer. That is half the point of IPv6 after all.

Update: Comcast’s approach seems to be covered in the IETF document Dual-stack lite broadband deployments post IPv4 exhaustion. On the topic of NAT and IPv4 application compatibility the document says:

Most applications that today work transparently through an IPv4 home
gateway NAT should keep working the same way. However, it is not
expected that applications that requires specific port assignment or
port mapping from the NAT box will keep working. Details and
recommendations for application behavior are outside the scope of
this document and should be discussed in the behave working group.

Translation: We chose not to care.

If you believe “RPM Hell” already exists and say things like “Apt is better than RPM” you just announced to the world that you do not know what you are talking about. YOU ARE WRONG.

“RPM Hell” is a reference to the difficulty of taking a package file from one distribution family and trying to use it on the other. Newsflash: That was always a retarded idea. If the package wasn’t made for your distribution don’t freaking do it.

I don’t care what wizbang distribution you are using it, it’s always a bad idea. If it isn’t in the repository for your distribution and the software’s upstream provider doesn’t like your distribution enough to have a package for you, then sorry, you’ve just discovered the one way the Linux development model sucks. Whine at the people maintaining your distribution or pick a new one. The package management system we’ve all come to love was clearly designed with only server admins and developers in mind. And there is clearly no financial interest in making a desktop friendly system or someone would have paid to have it done already. Sorry, thems the breaks.

The Debian world has the same problem as it’s advocates claim “RPM” (what? tar.gz gets a pass?) has if you try to mix packages between distributions and versions. The only “Hell” that exists is when people do a google search and random grab a package from some random FTP site and give it a try. DON’T DO THAT. Apt will murder kittens and refuse to do anything for you ever again if you don’t uninstall the crap so don’t do it. Older versions of Yum will sulk at you and swear at you with a python traceback.

Why? You have taken a dependency management system and violated it. You’ve corrupted it. The relationships are no longer sane. There is a sad reality in why Windows and Mac apps carry so many libraries with them. This crap is hard and no one has figured out how to make it friendly to Joe Sixpack without compromising security by design with every app carrying around a complete library set which may never get updated or patched.

As a “workaround” any desktop distribution worth using has a massive repository enabled by default. And for those “questionable” things where you may or may not be violating federal law everyone “knows” of the ONE *cough*unofficial*cough* repository that you need. If you want a newer version of something from an upstream provider and they don’t have a dpkg or rpm file for your distribution version and you don’t want to compile it, sorry, you’ll have to do without.

If this is too hard for you, then sorry, Linux desktop is a failure for your use case. I feel for you, seriously. May I suggest an appliance or device if you really want an open source desktop? I hear EEEPCs have a decent out of the box experience if you want to buy something with Linux preinstalled. If you want an actual laptop maybe Dell installs media crap out of the box for Ubuntu. I would certainly hope they do.

And as for the other statement saying “Apt is better than RPM” is like saying “Fedex is better than a cardboard box”. Hello? Yum? Ever hear of it? It’s been around for years. Seriously, it’s god damn ignorant to make that statement. Please educate yourself if you’ve ever said this.

This public service announcement has been brought to you by the “Coalition for Schooling Ubuntu Fanatics That Spew This Crap In Response To Genuine Technical Complaints About Ubuntu’s Shitty Kernel Maintenance.” Hmm. Perhaps I should shorten that up a bit.

Time for me to go back to figuring out why on Hardy I can’t use two mac80211 stack using wireless drivers at the same time without hundreds of lines of crap in dmesg and nothing happening.

(Update: OK, I forgot to include the profanity.)

If we have any hope of getting out of the NAT trap how does IPv4 become painful enough to compel the transition? Will hitting NAT scalability issues be enough? Or will the attractiveness of forcing end-users to be consumers and not producers by making servers and p2p impossible through multiple layers of NAT mean IPv4/NAT will be attractive to upstream providers involved with media organizations? (Hello, Time Warner!)

• Enterprise Linux 5.0 to 5.1
• Enterprise Linux 5.1 to 5.2 risk report

The blog posts cover the effects of various exploit mitigation technologies. Sadly it seems the same software keeps having security holes over and over again. It would be a good idea not to use a web browser from an important server (No duh!). It also seems like Samba and Kerberos related daemons have some major issues and should be locked down with a MAC system like SELinux and removed from any system where they are not specifically needed.

#!/usr/bin/python
import mechanize

b = mechanize.Browser()

b.open("https://www.bloglines.com/export")

b.select_form(name="login")
b["email"] = “email@address”
b["password"] = “password”
b.submit()

print b.response().read()

Hopefully this will save someone else a few minutes of their time…

I’m beginning to give up on the idea of using the same wireless SSID for both 802.11a and 802.11b/g radios. On all three platforms that I care about getting the wireless driver to prefer 802.11a over 802.11b/g is a waste of time. The vast majority of drivers for all three platforms seem to blindly check the SNR (Signal to Noise Ratio) of all visible APs advertising the desired SSID and ignore which band they are on. Because signals in 2.4ghz attenuate less than 5ghz signals this means 802.11b/g radios will always have the highest SNR and thus will always be preferred with a simple SNR check. This means the band you really want your users to use more is used the least.

On Windows you can manually configure some drivers to prefer 802.11a for the same SSID shared between 802.11a and 802.11b/g radios but it’s specific to the driver and many drivers do not even offer the option. And some drivers that do offer the option sometimes choose to ignore it for reasons unknown. (I’m looking at you Intel.) On Mac none of this is exposed in the UI and I’ve yet to even get Google to cough up a command line way of influencing what band and channel to pick.

On Linux it depends on if you choose to use NetworkManager and let the wireless driver select the channel itself. Depending on the driver quality you have the ability to specify the channel manually. To do this requires you to set it each time you wish to use wireless and this prevents roaming in many cases. It also turns what should be a two click and wait operation into something involving multiple manual commands and watching dmesg. It’s simply not a viable option for anyone except the network administrator himself.

So I’ve given up on that front and I’ve decided the best thing to do is to just offer an SSID that is only served from 802.11a radios. Within most of our buildings 802.11a signal should be sufficient for roaming so while it’s not a great solution its a usable one at least. So now we have the usual SSID that is advertised from all of our 802.11b/g and 802.11a AP radios and in addition to that we have an SSID labeled with “(802.11a)” thats only advertised from 802.11a radios. The Aruba gear we use makes it pretty trivial to have both SSIDs dump clients onto the same VLANs with the same AAA profiles so all it takes is about 5 lines of configuration to have no outside visible differences between the SSIDs.

I really wish there was a more auto-magical way to get clients to prefer 802.11a but I’ve yet to find a viable way to do it. So for now the SSID kludge will have to do.

import string

print [devip for devip in map(string.strip, open("iplist.txt", "r").readlines())
    if not [True for device in dmd.Devices.getSubDevices() if device.manageIp == devip]]

This is useful for those cases where you are sure Zenoss discovery missed a few network switches due to a network administrator screwup and find that it’s too time consuming to find the handful among hundreds the manual way.

As for the code quality I beg forgiveness from the Pythonic gods for thinking a list comprehension within a list comprehension with a map thrown in was a good idea. But then again I’m sure there are some Ruby fanatics out there that think that looks like Hello World.

Update on May 13th: A kind poster pointed out the presence of find() in zendmd and thus dmd.Devices.findDevice(). That means one can just do this instead:

import string

print [devip for devip in map(string.strip, open("iplist.txt", "r").readlines())
    if not dmd.Devices.findDevice(devip)]

Not only is it shorter its also a magnitude of order faster which shouldn’t be too surprising considering the evil in the original version. Thanks Erik!