Thanks to Billy for letting me know of this web-comic. I've been wasting entirely too much time going through the archives, and many comics are just plain classic!
UPDATE: I recommend reading the comments for this article, as there is an error in the aforementioned webpage's counters which gives misleading figures. My concern that solar energy irradiation is significantly less our demand for energy isn't true, based on new figures from a more accurate and precise source. Thanks to Peter Mortnsen for pointing out the inaccuracies!
A long, long time ago, in a galaxy you happen to be living in right now, mainframe computers dominated the computing scene for decades. They offered the power and I/O bandwidth to handle a wide variety of industrial and academic computing tasks. Later, a two gentlemen by the names of Chuck Peddle and Bill Mensch invented the 6502, the first microprocessor which offered affordable, high performance home computing. Jack Tramiel, Steve Wozniak, and Nolan Bushnell formed the holy triad, Commodore, Apple, and Atari, all of which utilized the 6502 or some variant thereof, to usher in a new era: home computing.
Home computing was distinguished from centralized computing because you ran programs which you installed yourself. The computer owner was (usually) the same person who administered the machine. Additionally, the computer was engineered for minimum administrative load on the part of the owner. In most computers, I/O devices "just worked," or was easily made to do so (the IBM PC lineup was a notable exception to this; not many people realize that the age of DIP switches, IRQ settings, DMA settings, et. al. were all faults of the PC's ISA architecture design; neither Commodore, Apple, nor Atari computers of the same day and age had these woes).
But, as time progressed, and the Internet caught on, long after Commodore and Atari had dropped out of the computer industry, more and more centralization of software services started happening. People started to acquire more satisfaction from using online services than from having to go to their Electronics Boutique store to grab the latest shrink-wrapped edition of Microsoft PaintPad 6.22+ XP Home Edition. It looked like the days of centralized software were back, after several decades of R&R.
Or is it? There exists a product which lets you run Gears-based web applications locally, which restores many of the features of home computing again. While I still think a network connection is necessary to access the remote data store, the fact that the software behind your favorite web application sits locally is the distinguishing factor here -- it means faster loading times, and a resiliency against unexpected UI changes.
It will be interesting to see how this thing plays out and how it affects the "software as a service" industry. Will more vendors offer their web applications in a format suitable for local invokation? Or, will vendors actively work to blockade such attempts? Supposing the former, what we're seeing is the long-sought dream of the Object Management Group, the consortium responsible for the CORBA standard. CORBA will likely see a resurgence of interest, as an API offered as CORBA objects can (and, indeed, has in the past) offer(ed) remote and local filesystem storage transparently to the application, without the abject resource waste that comes with using HTTP as a transport. Indeed, the similarities between CORBA's IIOP and Google's ProtocolBuffers wire format are uncanny. However, since the latter is a better factorization, I expect Protobufs to become the dominant technology in this area.
People who know me know full well I enjoy dome-shaped homes, but, sometimes, I get asked why. These homes come in a variety of flavors; whether monolithic or geodesic really doesn't matter that much to me -- the benefits of both are about the same, more or less.
What do I like about them? Well, they have vastly superior thermal efficiency over a frame house. They have superior artistic freedom on the exterior, in my opinion. And, there is that small detail of being hurricane proof.
And, with books still sitting on the bookshelf in a 2nd floor room.
That is what I like about domes -- superior engineering through simplicity. About the only thing a dome won't stand up to is the apocalypse scheduled to occur in 2012. But, even then, I have a hunch that if any building survives that, it'll be a dome.
BTW, due to subspace interference, you'll need to tweak the coms parameters a bit to get a decent picture from your sensor array. *sigh* You'd think that a society capable of building Heisenberg Uncertainty Compensators for use with transporters would be able to make a communications protocol that is self-locking, but alas, we'll take what we can get!
Republican Assemblyman GEORGE A. PLESCIA is a spammer. I received a "newsletter" from his ... umm ... office?, pertaining to all sorts of things San Diego. Be warned -- he will issue his "newsletters" to anyone, including those who (like me) aren't republicans, and through e-mail addresses gathered through channels covert to you and I. He equally doesn't care if you even live in San Diego, apparently, as I most emphatically don't.
In the company I work for, we tend to use scrum sessions on a daily basis. I find that this works pretty well, provided all engineers firmly understand their weekly goals. However, this morning, I was re-assigned to a new high-priority task (which is fine), except I had no concrete understanding of my assigned requirements (which is bad).
I couldn't help but think that my manager would have been far more successful if he had used index cards or comparably sized stickies to write out user-stories for me. Even though, from my perspective, the manager doubles as an "on-site customer," I find it utterly embarrassing, wasteful of his and my time, and potentially aggravating, to return to him for repeated clarification of his requirements.
I realize this makes me sound immature, like I'm expecting this stuff to be spoon-fed to me. Let's face reality: while I can think for myself, I just cannot read minds, as I discovered when my fellow engineer asked me, "So, what are we really testing here?". We needed additional input from the manager. It pleased me to know that it wasn't just me.
When the manager came over and helped explain his requirements in greater detail, after about 7 rounds of, "But, I still don't understand ______", we eventually amassed a huddle of about 7 engineers around a single computer, each responsible for a different aspect of the manager's goals. What started out as an impromptu scrum ended up a full-on planning game, extreme programming style.
As it turns out, 90% of my task proved already complete as a natural consequence of previously fulfilled, yet documented, stories. The remaining 10% involved making sure the continuous build system exercised the other 90% of the software.
Had the manager's stories been written down in some tangible form, we gain all the benefits of traditional extreme programming: tracking, velocity data acquisition, greater average clarity, et. al. It would have given the manager greater incentive to not waste his time on demands that were already met by previous demands, while not consuming valuable engineering time, trying to guess at what was really intended.
10 REM EXERCISE C64 BASIC V2 GC
20 FOR I=1 TO 80
30 A$=A$+STR$(I):B$=B$+STR$(I):C$=C$+STR$(I):D$=D$+STR$(I):E$=E$+STR$(I)
40 F$=F$+STR$(I):G$=G$+STR$(I):H$=H$+STR$(I):I$=I$+STR$(I):J$=J$+STR$(I)
50 PRINT I,PEEK(51)+PEEK(52)*256 prints the free space memory pointer
60 NEXT I
70 A$=".":B$=".":C$=".":D$=".":E$="."
80 F$=".":G$=".":H$=".":I$=".":J$="."
90 GOTO 20
Watch, as the free space pointer jostles all over hell and creation, as it becomes readily apparent just how frequently BASIC has to collect garbage. And, yet, I have not found one iota of evidence to support the claim that BASIC consumes many seconds to minutes to collect garbage.
Either I'm exercising the GC incorrectly (which I was, see below), or the claims that BASIC's utterly naive GC takes too long to run are just plain BOGUS.
UPDATE
This article, by Jim Butterfield, details the real root of the problem, no pun intended. The C64's GC is O(n^2) with respect to the number of roots you have defined. So, if you DIM A$(255),B$(255), thus creating around 500 strings or so, you've got pretty good odds that your GC will take 20 seconds, regardless of how much garbage actually exists.
With my defining only 10 strings in my original program, I ended up exercising the compactor, but not the root finding. Hence, I never noticed the delay before.
A must-read, and currently freely available, book by Niklaus Wirth: Compiler Construction. It's dense, and fast-paced. But I'm loving every minute of it, particularly since I have ambitions to create my own imperative programming language (other than Forth) for the Kestrel someday (especially considering it's nigh impossible to find a reasonable compiler for the 65816 microprocessor these days).
