Friday, November 1, 2002

Here's a brief tutorial on how to get an older Power Mac working as a home automation box under OS X. Lots of work left to do, but this might be interesting enough to get someone else to make it into something useful. 1:53:56 PM    comment []

Wednesday, October 23, 2002

Mystery Picture Yesterday's image was a close-up of the backside of a pill bug. It was taken with a USB Intel Play QX3 computer microscope using Microscope software running under OS X. Definitely one of the cooler geek toys to come along. Unfortunately, Intel isn't making the microscope anymore, though you can still find them on-line for sale at Amazon and eBay. 4:13:52 AM    comment []

Tuesday, October 22, 2002

Stopping the Sniper I was chatting with a friend this afternoon when an interesting meeting of minds happened. We were on the subject of the Washington sniper when he started a sentence with "If I was a witness to one of those shootings..." and I finished with "... I'd run after the guy as hard as I could." We both agreed that the same sentiment that kept a plane full of hijacked passengers from becoming another guided missile aimed at the Capitol should apply to those near any of the 13 shootings in the DC area. Why aren't people motivated to run down this lone gunman when whole plane loads of passengers wouldn't hesitate for an instant to do the same thing to a hijacker? And while we're on the subject, here's my $.02 on the roadblocks the police keep trying to set up after the fact. Rather than spend 5 or 10 minutes of precious time trying to use police to close interstate on-ramps, etc., why not simply broadcast to all drivers via the radio they're probably already listening to to simply stop driving, put their cars in park, and wait for further instructions? The authorities could shut down every road in the area in a matter of seconds if they adopted this approach, rather than tens of minutes it takes now. Just wondering... 6:45:44 PM    comment []  Mystery Image One of the kids dragged this in this afternoon. Every kid has probably played with one at one time or another. Anyone care to guess what it is? (Note, it's 60x normal size. Answer tomorrow.) 6:38:14 PM    comment []  Don Park: "What I am afraid of is the erosion in the sense of value for software. If OSAF succeeds, consumers will have access to a wide array of high quality software for free. Most likely, every PC will start to ship with them preloaded. Every time a new OSAF product ships, a market segment will dies. OSAF paints a picture of the future where consumers are expected to pay for contents and services, but software is free." The flaws in Don's argument are manifold. The biggest is that OSAF kills market segments. All OSAF does is introduce a new competitor into the marketplace who happens to have a different source of funding their development activities. The capital requirements are the same for development, regardless of whether they are amortized in the retail cost of the product or subsidized by donations to a non-profit organization. Capital flows out of the general economy into the pockets of the developers. It's a safe bet that OSAF will not provide the same level of customer support, documentation, or other amenities that come with buying commercial software. Their economic model won't allow it, not to mention the fact that open source software generally substantiates the "no documentation, no support" contention. So why get your panties bunched up over this? The short answer is you shouldn't, because all we're doing is seeing the introduction of yet another competitor. This one has chosen to compete at a very low price point and very likely with limited support and service. And what's the worst thing that happens? Huge corporations that make owners and shareholders rich will cease to be a viable economic model and lightweight coops of engineers and product specialists will become the norm. The creators of the IP still get compensated either way. Everyone should be glad that someone with a philanthropic bent is actually trying to address one of the most fundamental needs in desktop software -- one that has been woefully underaddressed by the market because everyone perceives it as a commodity. [Scripting News] 8:17:14 AM    comment []

Monday, October 21, 2002

Downloading The Mind [Slashdot] Kurzweil figures we'll have strong AI by 2029 and be able to copy a human mind about a decade after that. I've met Ray on several social occasions and discussed his vision for the future. There is a huge flaw (or blind spot) in his vision. All of his massive advances in AI and general computing functionality are based on extrapolating trends like Moore's Law, Metcalf's Law, etc. into the near future. He infers that because they predict that massive CPU power and network bandwidth will be available, that the software to match it will naturally come along, too. Ray's a hardware guy, for sure. Unfortunately, we've already seen a plateau in the demand for CPU cycles and network bandwidth. Without market forces to drive these trends, why assume they'll be sustained? The problem with depending on hardware and network advances to drive his vision is that software engineering simply cannot keep up with the pace of advances on the hardware front. Anyone who has ever read the "Mythical Man Month" understands this at a basic level. Humans simply cannot organize themselves well enough to tackle software projects of the magnitude that Ray envisions, at least not by 2029. Ray dismisses this argument by saying we'll have software that writes the software. Well, there's a tautology for you. If you can't write the software you need because it's too complicated, how can you possibly be expected to write the software to write that software? Genetic algorithms are useful for some very specific trial and error sorts of problems. But using them to random walk our way to a billion lines of debugged, functional AI code seems a bit of a stretch. My money sure isn't on Ray's pony... 8:27:44 AM    comment []

Friday, September 6, 2002

RSS 2.0 currently has a serious inconsistency in that it diverges significantly in one key area from earlier versions. All previous versions of RSS in this lineage (0.9, 0.91, 0.92, 0.94) have claimed backward compatibility with the previous version. Version 0.91 explicitly disallows HTML mark-up in any content, with the exception of basic entity encoding. Yet we're now confronted with a RSS 2.0 spec that explicitly overrides that critical design decision, instead specifying that the default format for text is HTML. I feel there is a major disconnect here and this has the potential to ruin RSS as a syndication format for use outside of desktop Web browsers. If a renderer wants to add mark-up to a RSS feed and show it, that's fine. But to impose stylistic mark-up on the content before it is delivered to a lightweight device like a pager, phone, or PDA is inappropriate and counter to the original intent of RSS. At least, that's my opinion. I think this issue needs to be thoroughly examined before pronouncing RSS 2.0 "done." 12:27:15 PM    comment []

Wednesday, September 4, 2002

IM URL Syntax Dave writes: But the problem is, according to Brent, who is researching it, there is no standard way to refer to an account on an instant messaging service. It's funny because we didn't know that when we did tcp.im in Radio and Frontier, we just went ahead with this format: service://screenname/, and no one seemed to object (if they did we didn't hear from them). In keeping with the nature of URLs, wouldn't something like: im:aim/YourAIMHandle or im:jabber/YourJabberID or im:/aim/YourAIMHandle or im:/jabber/YourJabberID be more appropriate? It's likely at some point there will be convergence in the IM space and then specifying individual, proprietary services as the protocol portion of a URL will seem silly. Rather, the point is that you want to send an instant message to a particular host (service) for a specific path (user). Here's little-known and oft-disputed historical tidbit regarding URLs. Anyone who's familiar with parser generation will notice and question all the extra tokens in a HTTP style URL. Why is it that the protocol HTTP is separated from the host name by a three character token, "://"? As I recall from the original discussions about URLs being had with the guys at CERN in '91-'92, there WAS a reason. In the original URL scheme, protocols were separated from paths by a ":" token, which is why we see URLs like "telnet:localhost" without all the spurious "/" characters. For HTTP, it was assumed that content may reside on different networks. Anyone who remembers the early Internet (pre-NREN, 1985 or so) will recall that there were LOTS of different, fragmented networks out there. CS-Net, CERFNet, BayNet, SesquiNet, etc. all served their little corners of the world. Some were TCP/IP, some were X.25, some were IBM-based, and all talked through gateways. The space between the slashes in a HTTP URL was originally supposed to be where the gateway or network name was specified. So a URL might have looked like "http:/csnet/www.somewhere.edu/file.html" if the modern Internet hadn't sprung out of its commercialization in 1991. The short portion of the long story is that the URL syntax I proposed above for instant messages falls nicely into the original (if not overcome by events) syntax for URLs as envisioned by the creators of URLs in the first place. 8:19:51 AM    comment []

Monday, September 2, 2002

Clarifications on RSS 0.94 Proposal Dave raises some good points which help clarify my understanding of current practice for RSS. In response to his notes (Dave's in italics): 1. Let's just deal with descriptions and not titles. I agree. It has never been clear to me whether or not titles were intended to be strictly plain text or could have mark-up in them. If it's the former, then there is no need to extend the "type" attribute to cover titles. If titles can contain mark-up, then they should be identical to descriptions, I think. There is one caveat. That's using the type attribute to specify character set or language choice in addition to the media type. This is important for non-Western character sets and languages. In this case, you can argue that any text that may be viewable by the user should be able to have a type attribute that specifies the character set/language as per RFC 2616. Otherwise, RSS is only for syndicating Western content An example is: type="text/html; charset=ISO-8859-4" Of course, an argument against this is that the character set specified in the enclosing XML container defines the character set for all text within titles and descriptions, so maybe it's unnecessary to specify it for individual elements. I guess the question more properly is "Can RSS documents contain titles and descriptions in more than one language?" 2. There's a temptation to turn RSS into something other than what it is. Yep. I assumed there may be arguments to cloud elements or other RSS elements that might be non-text formats, hence the perceived need for the encoding attribute. If everything that can appear in a description field is restricted to textual data of some form that can be encoded using XML entity encoding, then there is no need for an encoding attribute. 3. Then the question is, what are the types? I think the types are "text/*". That is, all registered MIME types that derive from the basic definition of text. Some burden rests with the syndicator to provide a universally readable form if they want the widest distribution. But special purpose syndications (i.e., those aimed at specific clients or devices) shouldn't be precluded from using other text-based mark-ups like RTF, XML, or even something crufty like troff or TeX. Regarding the question about what "treated as plain text" means, I meant that this is text that is assumed to be free of any stylistic or structural mark-up beyond white space. It can be "printf'ed" to the screen without appearing to have embedded tags or extraneous syntax. No parser required. Once XML entities have been removed by the XML parsing process (e.g., angle bracket and quote conversions), the resulting text string is devoid of any mark-up. (Unlike text/html, text/rtf, text/xml, or any other structured text format.) 4. Example 4 provides a good example for comment 2 above. Right. 12:03:19 PM    comment []

© Copyright 2002 Chuck Shotton. Last update: 11/4/02; 4:55:53 PM. This theme is based on the SoundWaves (blue) Manila theme.