Sometimes we need to wear our geekery like a badge of blood. Consider yourself EULA'ed.
This may even be possible with Apache Server monkeying, but it shouldn't be necessary. PHP is a great, open source scripting language for changing parts or all of a web page as its delivered. My problem with it? Anything labeled "WebPage.php" sucks. Why does it suck? Because it's not a .php page, it's a .html page created with PHP. Why doesn't it deliver a .html page? Marketing. It's the same reason why we see .asp, .gas, and all the others -- not to even dare mention the horror that is ".cgi?ALongAssStringOfInput" -- while our browsers gallumph along reading pure DHTML. Here's a rule of thumb: build the web open source, because that's how it developed so fast in the first place. What I want is to request WebPage.html, and have PHP make its changes in the back like a good little boy. Then, if I see something cool, I can request WebPage.php and view its source, unmolested, like all good little boys should be.
Quartz Composer is the closest thing to a modern HyperCard. Cracking it open for the first time is eerily thrilling, reminding me of the fun I had creating crappy little games and animations on a Mac Plus when I was eleven. Composing complex, interactive motion graphics becomes a simple process of linking up the inputs and outputs of patches representing everything from drawing a 3D cube to mathematics and logical operations. There's even a patch to execute JavaScript. Anyone who's not thinking "game" at this point is not properly obsessed. The only problem is, Quartz Composer JavaScripts can not store variables. To be more precise, Quartz Composer documents see everything as happening somewhere along an infinitely divisible timeline, executing JavaScript when the rendering pipeline encounters it, then moving it on and throwing it out. ClockSkew has come up with a hack (a value sent to a macro patch's input stays there until changed), but his method could quickly overwhelm the designer of even a simple game. Arrays remain out of reach. Notably, ClockSkew has also posted instructions for creating a custom patch in Xcode. Maybe I should stop wishing and do some programming on an array storage patch.
BitTorrent is very good at serving popular files, but useless at serving unpopular ones. What we need is a BitTorrent server with its own copy of the file. When the torrent is launched, it serves that file in its entirety to a set number of users itself, rather than relying on one user (usually the person who posted the file) to seed from his or her computer. Once that number has been reached, the server shuts down its own seed and reverts to a standard BitTorrent tracker, simply connecting users to other users and once again using very little bandwidth. When, however, it detects that there are no complete seeds, only users stalled out trying to get the rest of the file, it can automatically relaunch a seed of its own. Imagine being able to permanently host a large file on your site without worrying about being slashdotted/boinged/etc.
One of the reasons Apple is moving the Mac line to Intel hardware is that IBM has no general-purpose chip in the works that would be suitable for running a PC. What IBM has instead been focusing on is the Cell chip, which will be powering god knows how many things in the near future, including the PlayStation 3, The X-Box 360 and the Nintendo Revolution. It's a powerful motherfucker. The problem with it is it's only really suited to graphics processing tasks. The kind of code that makes up the meat of most of the software we run -- basically, everything but high-end 3D games -- wouldn't run very well on Cell chips. That said, professional 3D graphics use a lot of the same mathematics that's been pared down and streamlined into running real time 3D engines. The current generation of game consoles are sold at a loss by Sony, Microsoft and Nintendo, with licensing fees from game manufacturers (theoretically) making up the difference. Basically, we're getting expensive hardware cheap as hell -- a system that's not going to change any time soon. Why wouldn't it be possible to mod several next-gen consoles into a small grid computer, and meet a professional animation house's rendering needs desperately on the cheap?
I say "working" because, theoretically, Mac OS X can mount an FTP server in the Finder just like any network disk. I say "theoretically" because simple connection problems hang the entire Finder, its support for variations on the FTP protocol is weak, and -- and this is a Steve Jobs "and" -- access is read-only. Imagine how simple it would be to get AppleScript to regularly back up an expenses spreadsheet or address book to a hidden folder on this site. Why am I imagining that? It's trivial. I shouldn't need a badly designed demoware client like RBrowserLite to do something this basic. Most insulting is that the command line under Mac OS X has a full, functioning, read/write FTP client built in.
"Shareware" is fully-functioning software that can be freely distributed, with the request that the user send a small amount of money if he or she likes it. Period. "Freeware" is fully-functioning software that can be freely distributed. No money, ever. A "demo" is fully-functioning software that can be freely distributed, but in which some or all features will cease to function after a set length of time unless a specified payment is made. When we abuse the language for purposes of marketing, it ceases to function. Or aren't you sick of commercials promising a "better" such-and-such-and-such-and-such without saying better than what? Pay attention. The language is good, your software isn't.
![[ARCHIVE]](ArchiveLink.gif)
Current Addiction: [