« April 2003 | Main | June 2003 »
May 29, 2003
Spirited Away, annd The Duel
Recent movie rentals have included Spirited Away, and The Duel.
The Duel - a Hong Kong film about a challenge from one swordmaster to another, with a murder mystery surrounding the whole event. I had rented it hoping to see some interesting shots of sword handling, but was sorely disappointed. Each shot was in close on facial expressions, and provided little to no sense of skill. It was disappointing.
Spirited Away - wow. I didn't have a chance to see this while it was in theaters, and now really regret that (on the other hand I may not have appriciated it as much). While it is an animation, the story, characters, and imagination in this film are just astounding. It's worth renting, possibly buying. I don't know if I can say anything more about it, outside of go rent this film.
Posted by Dan at 09:14 AM | Comments (3)
May 23, 2003
PHP, ODBC, and everything in between
For about the last two years I've been threatening to rewrite large portions of ext/odbc (the Unified ODBC module) for PHP. Frighteningly enough, I've started. The basic goal is to provide a more modern interface, reflecting interface functionality found in some of the more popular database extensions (i.e. MySQL, pgsql), and a series of other improvements.
Work progresses and I believe the new functionality options have all been hammered out to the point of being static. The goal is to have this finished for inclusion in PHP5, as it readily breaks backwards compatibility completely. The problem with this is I've no real indicators of how many people use the ODBC extension anymore, nor does anyone really give me feedback when requested. I take the silence as being acceptance of the proposed changes, and will implement features/functionality that I deem necessary.
Essentially I've only added a few functions, but have drastically changed the underlying code to do this. For example you can now gain access to the odbc_environment, providing a larger amount of control to an ODBC developer. The first step was to upgrade from ODBC v2 to something more substantial (like ODBC v3.5). This transition is proving to be a bottleneck of sorts, but not the largest of them.
The largest bottleneck so far hasn't been a code issue, but rather my ODBC driver manager. When Apple introduced Jaguar they began to bundle a version of iODBC, but provided their own interface (Applications -> Utilities -> ODBC Manager) to it. Unfortunately, the Apple interface is poorly lacking in documentation, labeling, and ease of use. It seems as if the standard Apple development guidelines were thrown out, beaten with the ugly stick, abandoned, and left for dead when this gem was in the test and release phase. This becomes a problem when one is unable to diagnose why a DSN is not being found by the system.
Originally I had an installation of iODBC working with the Virtuoso database and was happily plugging along developing ODBC based test cases and systems. My upgrade to Jaguar bothered nothing. Eventually I decided to move to PostgreSQL to do some work on a more functional database. Exit usability, enter problems. I built the pgsqlodbc driver just fine for iODBC. After plugging in the appropriate values, I discover that iODBC cannot connect to pgsql installation. Thinking I built the binary wrong I recompile it and try again. The same result. More interesting is that the odbctest program cannot identify any DSN I've previously had entered now (???).
Further testing provides no solutions. I re-install the iODBC manager to discover that it too is still fubar, and does not recognize anything either. Now neither iODBC nor the Apple ODBC Manager seem to be working, leaving me high on dry on the development front. The iODBC help forum admins have suggested I've built PHP wrong, but when even their odbctest program doesn't work, I don't believe it's a PHP issue (I've also rebuilt numerous times since then). It seems others are having the same problems on the board too. Apple's help system seems to be devoid of any information regarding the ODBC Manager and how to make it work properly.
So I'm asking for help from those of who read this. I know OpenLink provides a driver to connect to pgsql back-ends, but charge a fee for this binary to which I can't/won't pay. I'd be willing to move to unixODBC, but have been stopped by the dreaded dlopen issue (and no I don't want to install dl_compat). I'd really like to know what has gone wrong here, and how to fix it.
Help.
Posted by Dan at 09:19 PM | Comments (6)
May 19, 2003
Surreal letdown?
With a huge deadline looming over one's head, what is the best possible means to procrastinate? Why, goto a new movie of course! With that in mind, I saw the Matrix Reloaded.
The movie on the whole was mediocre, and left me rather annoyed really. The constant re-use of bullet time effects for fight sequences became tiresome. The bits of the story that I enjoyed from the first were almost completely destroyed, but I do believe that was the point. It leaves the third and final installment to build a new world, which is fairly likely to happen.
The highway scene was fun, but as far as story elements went seemed rather useless. Much of the fighting seemed to become really unnecessary at times.
The real let down of the movie? The Burley Man scene. The scenario is seen in all the trailers. You know, the one with Neo fighting a mob scene's worth of Agent Smiths. The animation actually began to look too cartoonish for me, with motion blurs that stood out tremendously. Things that also didn't fit: at times facial mappings just seemed to be off by a few pixels, making each participants face look long and extended, or disconnected from the body. I think the scene would have flowed better with less bullet time as well, but each slowed down smack to a cranium caused the interactive theater experience to spring to life so I guess it did it's job. All in all the scene felt like it was a video game (the kind with repeating villains), not a movie clip.
Posted by Dan at 10:10 PM | Comments (1)
May 14, 2003
OSX and ext2 updates
Brian tells me that the first major step has happened: The project has been branched! This important first stepped happened a few (read May 2nd) days ago, and provides the MacOSX community with a 1.0 release for reading and writing to an ext2 file system. A nice little happy KEXT :) Now go forth, download, use, test, and report back any bugs!
Work yet to be done:
ext3 support (me)
NFS exportability (Brian)
ACLs should work... sooner rather than later... (Brian)
We would have branched sooner but there was a delay in the most recent exts2fs libraries release.
Posted by Dan at 08:32 AM | Comments (0)
MAC spoofing on OSX
Something I've been meaning to look into, read, and try recently but haven't had the time to do. This guy seems to have had the time and opportunity. Wondering how well it works, and if anyone else out there has tried it.
Posted by Dan at 08:27 AM | Comments (0)
Summary
This photo summarizes pretty much the past 10 days for me.
Posted by Dan at 07:45 AM | Comments (1)
May 07, 2003
bundled software
Sterling has put some serious effort (to which I'm insanely jealous of the free time) into integrating libxml with PHP to the point of requesting that it now replace the expat library, thus requiring it to be bundled. In the past, one of my constant arguments on the internals@ (then php-dev@) list has been to stop this practice as it provides no added benefit to the system as a whole. The interesting bit is Brad and I had run this discussion before. The end result was to not bundled libxml, but did not really resolve any technical merits either. Let me explain my stance on this a bit.
- Advantage one: bundling ensures a specific base version of some library.
The problem isn't wanting to establish a base version of library code, but rather trying to keep in sync with an actively maintained library. One could argue that it need only be updated when the community as a whole requests/requires it. Unfortunately, this doesn't take into consideration the power of a squeaky wheel that will complain feature XYZ doesn't exist in your software, but does in product ABC. In the case of an actively maintained software it may become a full time position to have someone maintain concurrent source (libxml is actively developed). In the world of open source software requiring a developer to do anything is not an exceptionally prosperous route for any.
- Advantage two: bundling allows fixes/patches to the code
A very true idea, but shouldn't such patches be passed back to the maintainers? In the case where they have been ignored (i.e. libgd), shouldn't this be reason enough to branch the code base in question and provide a new venue of distribution? It makes little to no sense to create a proprietary version of a code base, when the work could be useful to others. This also ties into a problem found in Advantage 3.
- Advantage three: bundling allows my software to ensure functionality
Typically in a server based software, those installing it are cognizant of what they are trying to accomplish. With this in mind, an installer will (typically) take the time to read what is required and necessary for such functionality to be enabled, i.e. FAQs, configure help, and potentially the manual. I won't say that all installers do, as one can quickly scan the PHP mailing lists to prove me wrong. This type of reasoning though leads to a downward spiral that, in my mind, ends with an application of an enormous size.
Where does the line get drawn for what libraries get bundled and what libraries don't? If you're really worried about providing a base line functionality always, it surely would be best to bundle every external dependency, right? The point being this is what a configure script is designed to do. Locate, identify, and use the requested functionality. When the necessary support is not found, throw up an error and give the person installing a chance to correct the error or remove the configure option from their install.
Leaving the installation of external dependencies to the user base has a few added side benefits. First, it only requires that maintainers of the interface to the library keep up to speed with any API changes, which typically should be few and far between (given for any amount of usability).
Second it removes the onus on your software from the point of blame. As with all software today, bugs and holes are rather prevalent no matter what QA process is employed. The hope is to keep these to a minimum and their impact even less. By bundling external software you are now (potentially) adding functionality to a system without the sysadmins knowledge. This is a dangerous path to take with respect to system security, and is ( in some cases) considered a trojan horse. If a vulnerability is discovered in this software, it now becomes the library bundlers fault for including the piece of vulnerable software. More importantly if a sysadmin does not realize that this software is installed, they may not upgrade a vulnerable library leading to system compromise. In either case, the onus of a non-secure software is placed upon a project. This is a stigma that is near impossible to remove once the seed has been planted.
Third if a vulnerability is discovered in the bundled software, getting users to upgrade an entire product installation for one library provides no added benefit. Wasn't this the point of using shared libraries in the first place? If you have already made customizations to the bundled software, the end user cannot just simply grab the latest version and update it.
So why not just unbundle everything?
Realize that unbundling an already established element becomes increasingly difficult. Within the PHP project there is a mindset that can be summed up with the idea of 'if it exists now it should exist always'. AKA the breaking of user perceived rules (i.e. expat bundled) is something that shouldn't be broken, and this is typically a good mantra to take for providing backwards compatibility.
On the one hand I agree with this, an established user base is hard to steer towards a new goal. On the other hand, I'd rather see PHP be minimalist. :) In either case I think libxml should not be bundled...
Posted by Dan at 07:52 AM | Comments (1) | TrackBack
May 06, 2003
RSS Corruption?
One of the many features I've enjoyed about RSS feeds is the presentation style simplicity. No visual distractions from changing images or bad design layouts. No having to readjust click patterns because the interface has changed. No possible confusion as to the beginning of an article due to interleaved ads. Just pure text with exactly what I've wanted to read. This is exactly what has made Google so nice to use, and partially a reason for it's popularity (search result accuracy coming in a distant first).
So why am I now starting to see a number of my favorite RSS feeds inserting advertisements into them? Is this the future of the RSS feed? To become a convoluted collection of text, some useful, some an advert?
I'd like to ask that this be put to rest right now and stopped by any of you considering this. There is a lot more I'd like to add to this, but I don't have the time at the moment. Stay tuned for full reasoning why this is bad... but in the meantime consider it a valid point.
Posted by Dan at 04:53 PM | Comments (0)