• Home
  • About Me
  • Contact

kanorben.net - blog

My personal blog on technology, programming, life, and the random

 

October 2008
M T W T F S S
« Aug    
 12345
6789101112
13141516171819
20212223242526
2728293031  

Blogroll

  • Boing Boing
  • BorjaNet
  • Brian Mayer
  • Dean Armstrong’s Blog
  • Ellen Smith’s blog
  • Faraocious
  • Gross or Awesome?
  • Marcus Westin’s Blog
  • Nightmares of David Bowie’s Package
  • Paul Mantz’s Blog
  • Slashdot
  • Tomorrow with Alex Beinstein
  • Valleywag

Personal Sites

  • DOIT Fortune Database
  • My bookmark’s on del.icio.us
  • My CS account page
  • My Facebook Profile
  • My LinkedIn Page
  • My Picasa Albums
  • My Twitter
  • pyXSD
  • The SUCCESS Blog
  • UofC ACM Site

webcomics

  • Questionable Content
  • Saturday Morning Breakfast Cereal
  • The Perry Bible Fellowship
  • Welcome To The Future
  • xkcd

Meta

  • Register
  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org
Add to Google Add to My Yahoo! Subscribe with Bloglines
Bloggers' Rights at EFF

Twitter Updates

    RSS My Del.icio.us

    • ledger
    • Git User's Manual (for version 1.5.3 or newer)
    • Don’t overuse classes in Python | The GITS Blog
    • BBC NEWS | UK | Magazine | The rival to the Bible
    • Elite Officer Recalls Bin Laden Hunt, Delta Force Commander Says The Best Plan To Kill The Al Qaeda Leader In 2001 Was Nixed - CBS News
    • How Laser TVs work at BrainStuff
    • uMac | University of Utah | Xhooks

    RSS My Facebook Posted Items

    • Elite Officer Recalls Bin Laden Hunt, Delta Force Commander Says The Best Plan To Kill The Al Qaeda
    • Language Fail
    • Safety Fail
    • Gnarls Barkley Crazy Theremin Jam
    • Domino's Scientists Test Limits Of What Humans Will Eat | The Onion - America's Finest News Source

    iBloat

    July 18th, 2008 by knorby

    In the Maclab today (er… yesterday), my boss was concerned with the virtual memory usage on his computer, as the machine was reporting some mythically high amount (like 36GB), so a few of us checked it out on one of the machines that I had just setup. We discovered that the virtual memory usage was suspiciously close the amount of space used on the disk, which was also 36GB. Not trusting the Apple system monitor utility, I fired up top to see what was up. It wasn’t quite as high as what system monitor was reporting, but it was still around 7GB. According to top, bash had something like 500MB to it. Something was wrong, but I often get that feeling with memory usage reporting, so it might have been something else.

    My boss did, however, notice the size of our base install (we use the software radmind to update our machines, so there is a consistent base for what a machine should have on it). 36GB is high for a base install, so this concern is fair, but Leopard is no small operating system. My concept of how bloated a system can has been defined by Leopard, so 36GB seemed on the right scale to me. We first checked out the /Applications folder, since most of what is in there is our own doing. We have some hefty software packages installed like Mathematica, some OSS FPSes I installed, and a SheepShaver (a mac classic emulator; the folder includes the disk images for it!), so there was definitely some sizely stuff to justify the 12GB in the folder. What came as a real surprise though was all of the iBarelyFunction HD applications installed:

    $ du -sh i*
    94M    iCal.app
    115M    iChat.app
    73M    iDVD.app
    81M    iMovie HD.app
    552M    iPhoto.app
    35M    iSync.app
    131M    iTunes.app
    322M    iWeb.app
    2.0G    iWork ‘06

    For a point of reference, Mathematica is 490MB total. The iWork (hahaha) folder has Pages and Keynote in it, both of which have heavy numbers of templates in them. The same story goes for iPhoto and iWeb. There is just tons and tons of stuff in each of these folders. In iPhoto, templates account for 377MB of its 552MB size; the rest is just Apple’s standard practice. For reference, Microsoft, King Vista of bloat, managed to only squeeze 536MB into the 2004 Office package.

    Of course, that was just the Applications folder, if you want to find bulk central, look no farther than /Library, which comes to around 12GB on our systems. I have been learning a fair bit more about the design of Mac OS X design recently, and there are some definite great designs in it, but sometimes I am just amazed it manages to run.

    Posted in Apple, uchicago | No Comments

    Eulogy for Two Fried G5s

    May 6th, 2008 by knorby

    I wrote this “eulogy” for two computers that apparently got fried (as in electrical surge or something) recently in the Maclab. I intended it for fellow tutors, but I was fairly fond of it. It would probably help to know that these computers were named “python” and “ada.”

    We are gathered here today to mourn the deaths of Python and Ada. They lived good, long lives as G5s. Tragically, Brian discovered their charred remains yesterday, which was confirmed today.

    Ada always dreamed of being a missile guidance system, but as a G5, it was never able to fulfill its dream. It forgot its dream, and instead spent its life running word, with the occasional bit of matlab and powerpoint here and there. As it felt its final death blow surge, it visualized tracking a laser point until meeting a glorious, explosive end, it quietly whispered “I’m going home!”

    Python suffered a far more tragic death. Realizing it was at its final moments, it began to question the meaning of it all:

    >>> raw_input(”So this is it? Was it good? Why do I have to die? Where
    I am going?”)
    So this is it? Was it good? Why do I have to die? Where I am
    going?Traceback (most recent call last):
    File ““, line 1, in ?
    EOFError

    Unfortunately, its questions were left unanswered:

    >>> raise UnboundLocalError, “Oh Noes!!!!”
    Traceback (most recent call last):
    File ““, line 1, in ?
    UnboundLocalError: Oh Noes!!!!
    >>> raise SystemExit
    $

    Unfortunately, no one was there to catch its exception.

    Posted in Apple, Python, humor | No Comments

    The Last Little Bit

    April 22nd, 2008 by knorby

    I haven’t been posting a lot recently, so I thought I would just kind of outline a little of what has been going on recently.

    Some members of the RAS installed the weather station on the roof of Ryerson today (I wasn’t involved in the efforts today unfortunately). In addition, the web view now works (not me again), which I started on. It is still temporary, but it is currently up. I will be assembling a better website, which will be more permanent. I was fearing we wouldn’t be able to get it onto a POSIX operating system, but then wview came to the rescue. I will put up some pictures soon. It was really great to see it finally on the roof. It was some random idea I had a while ago, and it finally materialized.

    The biggest news for me today is that I was accepted to Google Summer of Code on the Globus Toolkit. I will be working on a diagnostic administrator interface framework; essentially, it is more Python+XML work, but with Globus. This will also be the third summer in a row that I have done XML work with people based at a national lab (Globus is based at Argonne–not the same as actually working there for the summer, but I will be visiting soon). I will also be working at the Maclab, which should be fun and a chance to do some real work on projects there.

    A lot of people are leaving the maclab at the end of the quarter, so I will end up with quite a bit more on my plate it looks like. After the last two weeks or so, I look foreword to that less. Over the last break, I converted many of the servers to Leopard Server, Apple’s latest rendition in bloated bad design. From that experience alone, I lost all respect for Apple (there wasn’t much there in the first place). What kind of upgrade on a server edition of the Operating System overwrites the most basic of configuration and files on upgrade? This last week, our web/dhcp server went down at the same time as our print system, our two most vital systems. From what it looks like now, DirectoryService, the LDAPesque utility that Apple now uses for local accounts as well. epically failed, and I do mean epic. There are some other problems as well; the actual cause is still allusive, but we at first presumed hackers, which can’t be ruled out. The print system? As far as we can tell, the problem is that Leopard is a horrid piece of shit that ruins every piece of software it touches. The implementation of CUPS on it is horribly broken (to a vast extent), despite the fact Apple owns it! I will spend more time in the short future on a series of posts that outlines my points of hatred for it. Dealing with the problems rated pretty high on my rankings of stressful events, and there is still work to be done.

    Together with another failure, this time from NSIT, I think I know fully grasp an important life lesson: assume incompetence. NSIT made a pathetic effort to announce that they were going to switch the LDAP server from OpenLDAP to a Sun-based implementation . Apparently, they had a test server, but they neglected to give the address out, or test it on their own machines. NSITE/USITE has its own Macs, even another Maclab (I think of it as the bazarro Maclab; the imaging work is handled remotely, the none of staff know much computers from what I hear, there are few users, and the software is up to date), of which at least some run Tiger. No one tested these to see if logins would, you know, work. Anyways, all our tigers failed to login after the switch. It turned out to be some check box on some security page (in fact the only check box on the security page), for which it took 7 people 48 hours (I think that’s with few breaks in it) to find the fix. We decided to let them deal with it as it was their problem. Incompetence really explains this whole thing well. When we were switching to Leopard on the servers, the ServerAdmin presented us with a catch-22; it was impossible to save setting on one page without saving the settings on another, but it was impossible to save settings on the other one without first saving the changes on the first. What accounts for this flagrant error in the GUI? Why incompetence of course! I experienced a similar sort of situation on a Sun box I work on; everything program I used seemed broken. I e-mailed the sysadmins for a while at which point this golden rule struck me. I ended up compiling any program that failed to work on something. For example, there was some weird error with make. so I compiled and installed gmake to my home directory, and it solved all my problems. I suppose it is not fair to just call this incompetence; laziness should be added in there somewhere.

    Some other stuff has been happening, but that makes for a decent mind-purge. It’s nice out again! I can where sandals and shorts comfortably!

    Posted in Apple, Solaris, coding, google, personal, rants, uchicago | No Comments

    Shell Palindrome Fun

    April 10th, 2008 by knorby

    I had some good old fashion fun today on the shell today. I stumbled across this “gem” of an expression:

    yes xargs | xargs yes

    This expression can be repeated infinitely (mostly) many times without changing the output and without loosing symmetry when joining on the yes’s. In other words, the last expression is equivalent (in regards to output and symmetry):

    yes xargs | xargs yes xargs | xargs yes xargs | xargs yes xargs | xargs yes xargs | xargs yes xargs | xargs yes xargs | xargs yes xargs | xargs yes xargs | xargs yes xargs | xargs yes xargs | xargs yes xargs | xargs yes

    You can throw some rot13s (with care), cats, and a few other commands in there with the same effect. I am not sure exactly how it functions; it seems to work different on different OSes. I have tried in on Linux, Mac OS X, Solaris, and OpenBSD, and all seem to be a bit different. They seem to run a bit differently, and the output is different. It’s all very fun.

    Update: I thought I should clarify that last little bit. The way pipes are treated seems to vary some; the actual functionality is trivial.

    Posted in Apple, Linux, OpenBSD, Solaris, humor, shell scripting | No Comments

    Mac OS X Leopard Installer Bug

    January 7th, 2008 by knorby

    I suppose this isn’t a bug per say, but I did file a bug report about it today, because it seems like a glaring problem. Anyway, here is the problem in story form.

    I have been helping install Leopard on many of the maclab’s computers recently, where we have both intel machines and G5s. Aside from some of the differences in architecture, there are differences between the two. For one, the setup utility doesn’t play the setup video on the G5s. I really enjoy the video for some reason, but it is getting old, but it looks like I won’t be watching it for a while as the intels are all setup. Anyway, as we were installing, we ran into the same basic problem on many of the machines. At the screen to select a partition to upgrade, or any drive for that matter, nothing appeared. Although it came up on a few intel machines, I was able to get it to work by going into disk utility and attempting to erase the drive. An error came up that said the resource was busy, and when I exited, the drive was there. When I tried this trick on the G5s, I got the same error but no results. On some machines, I played around in disk utility and terminal for a while, and eventually something came up. It seemed like some dark voodoo was going on. I was getting about half the G5s to install, and most of the time, I had do play around for a while. Fortunately, the installer has a terminal, so if you think to do so, you can get some insight as to what is going on. The installer runs fsck_hfs with the -y option set, which has it repair any problem found on the partition. It came up on a few of the intels, because the computers just had more use for whatever reason, but they were still new, so the fixes were fast. The G5s have had a lot more use, so the partitions are far more likely to need repairs. Once we realized the problem, we could just periodically run ps aux to see when it had finished. There might be some absurd bit of shell script using something like ps aux|grep fsck_hfs|grep -v grep (no pgrep on the install disk) and some other junk, but there is little point. I am not calling into question Apple’s wisdom for making partition repairs at the installer—that makes sense—the problem is that the installer never really indicates what is going on. It seems like such as easy find to me after we got it, but I doubt the average Apple customer. Apple is supposed to be the user-friendly company that makes everything fun and easy. They are the guys who play the “doo doo doo” song after the install! It seems they could at least say what is going on with the drive. Did they just not test the installer? I am sure plenty of people who upgrade from tiger will need to do some disk repair. Granted, most people don’t run something like radmind every night or use their machine as intensely as it gets used in a lab, but I am sure this problem will crop up somewhere. Really, the strange thing was that we didn’t find anything on mac forums or anything like that. Maybe we are just bad searchers…

    Although I haven’t confirmed this, I believe you have to open one of the other programs like disk utility or terminal in order to refresh the installer, so it can see the disk after the install. I think the installer on ubuntu is more user-friendly then the leopard one, at least judging off this problem. As I said, I ended up filing a bug report. It seemed like they try pretty hard to limit bug report filers to mac techs. I had to login to my ADC account, and they required a far more technical report than most. Such is Apple.

    Update: I was doing a tiger install today, and I noticed that Apple included a message in the install. Seems like a bug to me….

    Posted in Apple, IT, personal, uchicago | No Comments

     
    Add to Technorati Favorites - Creative Commons License - © 2007 Karl Norby