« August 2003 | Main | October 2003 »
September 30, 2003
Important truths
A word to the wise, do NOT let your roommate break out Halo when you have deadlines looming overhead. There went another 5 hours without noticing (yikes).
Posted by Dan at 09:06 PM | Comments (0)
September 29, 2003
blogroll additions
Politech recently had a post announcing the start of a blog by Warren Slocum revolving around the concept of accountable elections. Check it out, it's worth reading. You'll also find it on the right.
Posted by Dan at 12:36 PM | Comments (0)
September 24, 2003
Structural Enginneering humor
I was pointed to this article today: A Stress Analysis of a Strapless Evening Gown. A good laugh for those of you engineering oriented (despite it's lack of photos).
Posted by Dan at 01:43 PM | Comments (0)
Birth of a meme
A mailing list I'm on currently began a small discussion on the history of Murphy's Law, it's birth, original meaning, and rise to popularity. One of the members noted that Oxford English dictionary keeps a record of the earliest mention of such phrases, and can point it back to 1955, suggesting that everything in this article is actually kept to date. Oddly enough the article also (makes small indirect) mentions of this later on.
All of this began with someone posting a link to a piece of this article, which mentions the book Murphy's Law And Other Reasons Why Things Go Wrong published in 1977 that sparked the authors original interest. The article itself is a completely fascinating read on the history of a phrase so commonly used today. A personal favorite part of mine is the General Yeager quote about the Tom Brokaw's book, The Greatest Generation.
The timing of this article falls inline almost perfectly with Richard Dawkins recent article on wired.com about the birth of a new meme: bright. It seems someone has decided that the word bright should no longer represent what has traditionally been associated with it, but rather to represent those people in life whom do not follow a religion. I am not entirely sure I agree with this change in term, nor do I even see how this connotation will become popular. In the case of Murphy's Law, it became instantly recognizable to most engineers, had a humorous note to it, and began to penetrate the psyche. I don't see bright making it much past the world of academia. If you were to ask any college student about life, you'd come to realize that academia isn't associated with the world beyond the academic walls. I guess this is my chance to watch and see if/how a meme will expand into the thought-space of everyone else.
Posted by Dan at 01:41 PM | Comments (0)
Libtool...
devil spawn or uncharted circle of hell?
The past few weeks have seen me arguing with making libtool operate on systems that it doesn't support. The port of libtool appeared to be easy enough that it took almost no time to complete code wise, the problem became linking (due to a crt1.o missing on the EROS system). That was the easy part.
The hard part is making other build systems that depend upon libtool to work properly. Under EROS there is no dynamic library support yet implemented for the system, so all libraries must be static (meaning bundled into the application). This causes for applications to have a much larger footprint on disk when built versus when using a dynamic library. There are arguments on both sides if this should be supported or not, but the fact remains right now that I'm rather unbiased as disk space is cheap and both should work equally well for what we're trying to do.
Unfortunately though it seems that libtool likes to automatically assume that dynamic libraries exist, which is a fact on most GNU based operating systems. I don't state all because EROS is a GNU licensed OS (as I'm sure there are others). Allow me to explain the problem at hand.
The issues with crt1.o missing have been plaguing us for months now, to the point where it causes any and all configure scripts to fail. Why? Because configure likes to build it's test functions utilizing libraries it does not need. The solution to this problem was to run configure on the linux host system, and hack the resulting makefiles into something usable by EROS. This mainly entails changing the CC variable, adding in a CPPFLAG and a LDFLAG, updating the 'ar', 'as', 'objdump', 'ranlib', and a few other pieces. It also requires to visually ensure that each Makefile builds a static library and NOT a shared library. This isn't as easy as it sounds once you start having to deal with libtool, which seems to just become a shell wrapper for standard compiler commands.
The resulting libtool files of types .la and .lo provide little help. While I can look into each, it seems more often than not, each will still produce a shared library as the end result. At first the idea was to try and use the Linux libtool to work around this. It should be able to work equally fine for both systems as long as the same compiler is being used, right? Well, sort of. The compiled objects would still be the same, but the system now thinks it has access to the libraries in use for Linux itself. This would be fine, but again EROS does not support dynamic libraries, so adding in < name random library here>.so for linking won't work.
The next step has been to try and port of libtool for use on EROS and insert it into the EROS XENV build tools. This was going just fine (it's the 8th such tool I've had the joy of starting to port) until we reached the linking phase and realized that, once again, we need crt1.o. That leaves a decision, wait until someone can figure out where our crt1.o has gone to before moving on, or try doing something really drastic and parallel like ripping out all references for libtool usage in the generated Makefiles. Being the stubborn headed fool that I am, I've opted for the latter, mainly because the former would cause a serious amount of downtime that would be hard to make up.
It seems that libtool, though, does some extra magic behind the scenes in it's linking phase that causes a hand linking to fail. While I could be doing something wrong on my end, I find it unlikely given the amount of time I've been pouring over Makefiles recently.
I'm open to any suggestions on means around this.
Posted by Dan at 12:15 PM | Comments (0)
September 13, 2003
Song for the Day
Posted by Dan at 06:39 AM | Comments (1)
September 12, 2003
Talk: networks and games
I attended the first technical talk I've had in a long time this past week. The presentation was conducted by Dr. Christos Papadimitriuo of UC Berkeley on the topic of computer networks, game theories, and how the two mixed can be used in conjunction to build a better network infrastructure. After looking through his web-page, I believe the discussion was a 50 minute introduction to the concepts he will be discussing in his CS294 seminar at UC Berkeley.
As a warning note there were points during the presentation that I could not hear Dr. Papadimitriuo, as such I may have missed some important details and my interpolated details may not be correct at all.
The talk begin with a basic introduction to game theory and some of the more popular concepts within, i.e. the penny game, etc. The main points I picked out of this talk revolved around the concept that, while the shortest path is always the desired route, sometimes taking the initially longer path will result in better performance, and the challenges of adding these to the current network traffic patterns. His best example used sample routes and had the attendees calculate out the optimal routes. The fastest route was easily found, not because it was obvious, but rather because we could see the future routes and predict around them.
At this point he began to discuss the challenges of adding this logic to routing, the games that need to be applied, and the theories of how/way this works. It was also at this point that an audience member challenged his theory, by stating that the theory works great but the reality is completely different (and well documented/understood). It was at this point that I could no longer hear the exchange occurring between the two, but it placed enough of a seed in my own mind to question the validity of the research. Thanks to this interaction the time frame for the lecture had to be compressed into a much more condensed version.
One of the parting questions asked was what would happen if an entity were actively trying to exploit the system. In a sense, the proposal he had given was for the induction of a benevolent monarch to control in a fair manner, and continue to push the expedient routes. The question revolved around this monarch being replaced with one who's intention was not to keep the fastest routes, but rather the most optimal? Or more importantly what would happen if one of the routes decided to act against the orders from above, how would that impact the overall network strategy? Unfortunately these questions went not really answered/explained due to time constraints.
[EDIT: typo corrections]
Posted by Dan at 01:13 PM | Comments (0)
September 09, 2003
Fun With WiFi
After all the trouble, the Ti Airport Whip Antenna has finally arrived in all it's non-splendor. Initial inspection showed that it wasn't exactly how I had figured it would be. From the literature I had understood (somehow) that the antenna was a removable piece, so that you didn't need to always having it hanging out of your laptop. The other bit I understood to be true was that you could continue to use the internal antenna already installed. Neither understanding proved to be true in the end.
Installation took a few minutes of time. Most of it was trying to detach my Airport card to make life easier while installing the new antenna (this isn't a required step). Once installed I ran the provided iStumbler program, noticed that I was able to get more than just one network, but rather I was now picking up 3 (a LinkSys and a 3Com). It's taken a little bit of work, but I've narrowed the "default" (LinkSys) network down to a access point across the street that is completely open. I've been enjoying the across street Internet access for a little bit now.
Now some of the problems with it, beyond the wire sticking out of my pretty TiBook. It seems that WiFi generally slows down the entire computer more than I've realized, and has really confused the Mail.app (click "Send Later" and then again, and again and again and... ). This can be seen with Mail.app's retrieval of mail, Solitaire Till Dawn's animations, and even in general websurfing. Many of the faults/problems of web surfing are also apparent again with page requests not always being sent the initial time, but the browser understanding them as having been sent. The bigger problem is that my Airport seems to at random not be able to sync with the base station. For example it will lose it's DNS, or the uptime of my local base station. Once this happens of course the entire wireless connection is worthless and needs to be restarted. I haven't figured out what's causing this yet.
Posted by Dan at 02:16 PM | Comments (1)
September 02, 2003
customer service pt2
Small Dog Electronics and I have finally had a resolution to our battle of shipping, but it took a bit more effort on my part to accomplish this. While I'm not completely thrilled at the route taken, I'm very happy to have my order arriving in the next day or two according to the UPS tracking system. In the end, I had to follow the links on the side panel to the Better Business Bureau and discover their BBB representative. Once I found this out, I composed an email that wasn't angry, more disappointed, and asking for help. Now the catch is there are two addresses listed, for what seem to be the same person, only one of them is valid. You get to guess which one.
Anyhow after sending this email, I received a response within 20 minutes, which politely informed me exactly the same information that my earlier two emails told me. I replied yet again, and was informed that it was my bank (not their service) that was in the wrong (failed logic paraphrased: they do this everyday, so it can't be them). A few minutes later I received a phone call from the person running my order and everything was resolved in a matter of minutes.
In the end they seem like nice people, but it will probably be a little while before I order from them again. They do seem to be over worked and understaffed.
Posted by Dan at 07:38 AM | Comments (0)