Put the knife down and take a green herb, dude. (c) Ruffin Bailey 2001-2018

Over at ye ole Salon we find a somewhat ramblerific article on software evolution which pretends it's mostly about "Meir 'Manny' Lehman", apparently the first guy to do a paper on software evolution, in his case OS/360 at IBM.

Ole Manny apparently came to the following conclusion:
OS/360 was heading over a cliff. IBM, in stressing growth over source-code maintenance, would soon be in need of a successor operating system.

IBM reportedly ignored his report, but 3 years later were splitting OS/360 into two more manageable branches.

The bottom line of Manny's theory, which is apparently relatively hotly disputed in the right circles, is that software tends to grow in a curve that's the inverse (I think... been a while since I had geometry) of Moore's law (which has processor power growing at a geometric rate). The blame seems to be laid at the feet of programmers, who'd rather add something new than test something old, making larger software projects grow into a more chaotic system, in a fashion, when it comes to "bugs over time". In other words, any program that's been around long enough, unchecked, left to software developers' own devices, " all software programs are ultimately doomed to succumb to their own internal inertia" (From Frederick P. Brooks' "The Mythical Man Month", quoted by the above article, and reportedly based on ole Manny's work). Without adding energy to the system, in a sense, specifically for the removal of this chaos, software development produces poorer progress per unit of work added over time.

That software developers like to add new instead of understanding old isn't a new idea. Old man Joel has said something similar about refactoring code instead of rewriting it. Strangely, though, it would seem that keeping old code, according to Manny, would make it so that keeping this old code puts you on a one way course towards "succumbing to your own inertia", so to speak.

I'd guess Joel's response would be that most people aren't working on OS/360 or a likeminded project, and that you're generally much better off keeping what you've got [and the lessons the code's already learned]. There's also the obvious possibility that we're talking apples and oranges -- developers would prefer to add something new than to fix something old, which I believe is a complaint of the open source software movement (that things are added all the time, but not well-tested).

But the apples and oranges arguement aside, it would seem that if there was only a system where many programmers could add their "fresh, new, inertialess" code to a living whole, you wouldn't find yourself smacked on the head by the continually more complicated vortex products like [traditionally created] operating systems or Microsoft Words possibly produce.

Hrm. That process sounds familiar, doesn't it?

Another poorly edited ramble by ole Rufbo there.

I've been reading SAMS' Programming Data-Driven Web Applications with ASP.NET written by the two dudes that run dotnetjunkies. So far the book is thorough in the number of elements it touches and attempts to explain, but very surface level. "Here's widget A, here's a description B of widget A, here's an example code dump of me using widget A's closest cousin to 'Hello World!'."

That's not bad, but so far has had about 250 pages that have involved nothing more than skimming. I like a book with more tofu (trying not to offend anyone other than my own sense of taste, there), but it could be that I'm just that far along with my knowledge of ASP 3.0 and html that this is pretty much all old ideas.

Anyhow, the point of the post is that I notice these two dudes, who I often hold up as the representation of the archetypal higher-end ASP.NET programmer, have a bad habit of having 8 lines of asp.net code where one of html would do. For exmaple, here's what they do to place a name/title over top of a list of checkboxes:

<asp:Label
width="100%"
runat="server"
text="<center>Pick Products</center>"
BackColor="white"
ForeColor="Navy"
Font-Bold="true"
Font-Size="13"
/>

Why not just use <center>Pick Products</center>? Maybe couch in header tags? Backcolor is white over the whole page already... Anyhow, here's the code you get on the page:

<span style="color:Navy;background-color:White;font-size:13pt;font-weight:bold;width:100%;"><center>Pick Products</center></span>

At least MS uses css for the boldness, but shouldn't they double tag? (ie, use b tags in the middle) I don't know.

The big idea is that there are so many places for expressing personal preference in how html is rendered, I just can't imagine leaving it all up to MS. Even then, we're adding the "center" tag to this label's text attriubte. Seems wacked.

I also wonder about learning to add tags like the above with all these attributes defined within. That is, with codebehind you're supposed to be able to place all the code for a page in a page the web designer never has to see. Should this part of the code be for the web designer or shouldn't it? Shouldn't you just have a "label" there and let the web designer's stylesheet determine how it's displayed? Set/change the text and font, etc, in codebehind, and then only if you have to.

Phew, that was a poorly directed rant.

Oh yeah, my port of furthurnet to Mac OS 9 is coming along. No word from the devvers about my bug questions as of this morning though.

title: Put the knife down and take a green herb, dude.	descrip: One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!! Back-up your data and, when you bike, always wear white.
x MarkUpDown is the best Markdown editor for professionals on Windows 10. It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support. Features you won't find anywhere else include... MarkUpDown Multiline Table & Bootstrap Grid support. Beautiful Easy Actions that keep the Markdown flowing. HTML paste to paste HTML source into your documents. You've wasted more than $15 of your time looking for a great Markdown editor. Stop looking. MarkUpDown is the app you're looking for. Learn more or head over to the 'Store now!

Thursday, April 25, 2002
It's taken me a while to figure it out conceptually, but Visual Basic 6.0 really is analogous to those quick console applications "real" programmers like to make. When a traditional C++ programmer might slap together something without a user interface to accomplish a task that'd be quicker to code than to do with other tools, not worrying about whether his/her code is exactly to spec, Windows programmers will use VB. VB hacks are weird things to see. Logic is tied to the GUI, a huge traditional taboo, and layout is about as ugly as it could get. Everything's named the default,Textbox1 and List3, making it more difficult for anyone to follow what's going on. But the point is that it works, and works quickly. Click, drag, slap in a few lines of code, and you've made an app that's just as accessible to users addicted to GUIs as command-line apps are to "real power users". Though VB support is going to start going away in a few years, it's still a great engine for creating useful, accessible, and horribly ugly applications that don't require typing "foo --help" to understand and get working. You can still make "real" apps in VB, but it's difficult. Even more difficult is making a good "GUI + logic" app (where the two are separated) the right way with a team of true VB programmers. All these slapdash bad habits are going to make their way into your code, and at some point you're just going to have to throw your hands up and accept it. Remember, the idea of separating logic from UI, an essential programming point, is a completely foreign concept to the traditional VB programmer. Good luck. ;^) Of course there's the option of creating all of your logic in one COM or .NET object and use VB solely for the UI. This is the right way to do things, even if managers don't always understand why. In .NET, the Windows Forms classes should be used to create UI and are basically supposed to fill the role VB 6.0 once provided for Windows programmers. But VB.NET isn't VB 6.0, and there are going to be some growing pains. Having separate logic/UI teams are one good way to avoid headaches. posted by ruffin at 4/25/2002 10:38:00 AM
0 comments
Wednesday, April 24, 2002
Quick! Before they learn that there's more than one browser in the world! Check out this demo from the kinda, capitalistic folk at richtextbox.com using a browser like Mozilla, or even Netscape 6, or how about the browser engine being used in the latest AOL beta? Once again, I emailed the offending .NET fellers. Speaking of, let's see how dotnetjunkies is doing with Moz and it's dynamic menus. Whaddya know? It's the exact same slack problem they had before. I hope AOL/Gecko catches like wildfire. True html programmers will be as in demand as COBOL guys in Q4 [calendar] 1999. posted by ruffin at 4/24/2002 02:51:00 PM
0 comments
IE on Windows has a neat feature that allows you to pop open a page you're looking at and hack on the source in the editor of your choice. Sorta. Most of MS's tools automatically register in the "Tools \| Internet Options \| Programs \| HTML Editor" drop down, but vim's a little outta luck. Luckily all your problems are solved for integrating vim as your HTML editor in IE on Windows here. I just wish visvim did what it sounds like it should do -- provide an alternative, truly integrated editor for VS. I'd like to have vim pop up in Visual Basic 6.0. I hate taking the hands from the keys. Mice. Crimminy. :^) posted by ruffin at 4/24/2002 11:47:00 AM
0 comments
VB.NET is entirely different from VB6. The only similarities are skin deep. For heaven's sake, yes, he's got it. Just read a horrible article in aspnet Pro magazine (or something similar; I'm bad with names) purporting to help you decide which language to use in your .NET coding. "If you like C#, use C#; if you like VB.NET, use VB.NET." It makes me sick. :^) This article is much quicker and, surprise, more useful. The above article does a great job very quickly showing why you should [probably] use C#. In brief [imo] the points are that the .NET team uses C# to build .NET, the example apps from MS are C# first and VB.NET rewrites when there's time, and that VB.NET is nothing more than a thinly veiled syntax rewrite lain on top of C#'s structure. "Upgrade" a VB 6.0 app to VB.NET using Visual Studio.NET and see for yourself. posted by ruffin at 4/24/2002 09:48:00 AM
0 comments
Friday, April 19, 2002
What's best about .NET? MS is bringing the same "paradigm" from the client to their web services. This might give MS a leg up on the server side, but well programmed replacements for their "uplevel-specific" controls that aim for alternative OS browsers [as well as Windows browsers] mean that you're only one .NET server from bringing MS sellouts into an alternative OS world. One of the reasons MS is so successful is b/c it has so many programmers. Now, thanks to .NET, those programmers aren't tied in to MS clients to get across expected functionality. posted by ruffin at 4/19/2002 04:56:00 PM
0 comments
Thursday, April 18, 2002
Know how to program? Want to learn C# ASAP? Go here. Okay, okay, it's not quite as nice as I'd've liked, and it brags about not having many comments even though a few well-placed comments would have made this much more useful, but if you already program this one file will show you how to port your console-app logic to C# in a minimum of time. And it's cheaper than buying a book. posted by ruffin at 4/18/2002 10:15:00 AM
0 comments
Wednesday, April 17, 2002
Why is writing less code something to brag about when it comes to new technologies? IBM fights Microsoft on who can write a pet store with the fewest lines (1 to none, depending on who you believe), ASP.NET trainers brag about how .NET is misunderstood and you can write whole apps with tiny amounts of code... Are there really that many apps out there that are prototypes that are never updated? Sure, you can make a WordPad replacement in VB 6.0 by hitting "Next" in a Wizard until you get to the "Finish" button, but does that make VB a better langauge than C? Sheesh. posted by ruffin at 4/17/2002 11:16:00 AM
0 comments
Tuesday, April 16, 2002
BLOGSPAM DAY!!! Been using vim as my main text editor (on Windows, even -- well, gvim) for a while now, and I think I oughta write an article for somewhere entitled, "How the mouse destroyed productivity". Oh, I know, all the graphics designers and spatial data people will pitch a fit, but when it comes to programming for the web and just in general, the mouse is a productivity killer. Kinda like web logs. Anyhow, I suppose now is when I mention Cream for Windows, which is self-styled as... ... a configuration [read: "incarnation" -R] of the famous Vim text editor to make it easier to use, like Apple or Windows software you already know. At first it sounds like a neat enough idea, but it ain't. Here's a goal that shows as much, from the Things [the cream dude] hates about vim: We've all heard this fabrication that GUIs are slower than text entry, but this simply isn't true for anyone other than a developer level expert. Who else does text entry with a text editor? And if you want a text editor with groovy features that make it a cinch to learn, why are you using Vim? If you're stuck on a dial-up and simply must edit text, try the "PIne COmposer", or "pico" (ignore the bit about using emacs in that doc). Admittedly, when I started using gVim I wished that I had more of the commands at my fingertips like I usually do when I have a drop-down menu -- often all through keyboard transversal (eg, alt-f-s to save). But after you finally get what the keys mean in your head, you're much better off and working much more quickly (with less carpal as well). If you're thinking about using Cream, use a well-tested, well engineered project that's quite similar and already finsihed, UltraEdit. If you want vim, you don't want Cream. posted by ruffin at 4/16/2002 10:56:00 AM
0 comments
While web programmin', I'm finding that Mozilla might be a tester's best friend. I'm quite impressed with how well behaviour of a particular build works across platforms. Does it work in Windows? Well then you can nearly take it to the bank it'll work the same way on MacMoz or UNIX, which also makes you feel pretty good about being able to get your "advanced dhtml functionality" to the maximum users. Heck, Moz even runs on Mac OS 9. I'm almost to the point that I'd stop testing Moz xplat and know I've got something working, but that's a pretty big no-no even to a lazy feller like myself. Here's one place where a little dhtml code shows that the browsers are still on different platforms (and any change in behaviour is good to spot). This is a javascript function that I'm using to change the way a cursor looks on a web page when something's loading. `function changeCursor(menuOff) { if (document.layers) { daMenuOff = document.layers[menuOff]; } else if (document.all) { daMenuOff = document.all(menuOff).style; } else if (document.getElementById) { // DOM1 daMenuOff = document.getElementById(menuOff).style; } //alert(daMenuOff.cursor); if (daMenuOff.cursor == 'wait') { daMenuOff.cursor = 'crosshair'; } else { daMenuOff.cursor = 'wait'; } }` Half-way expected the wait cursor to be an hourglass in Moz on Mac (like it is on Windows), even though Mac IE 5 shows a watch, like a "good Mac should". Nope. Moz is making a native API call in both builds. Interesting. Wonder how they wrap those calls in an xplat API -- or if they do? Also makes you wonder what other, less innocuous native calls are going on in other places... Anyhow, just a reminder that you write once, test everywhere, write again, keep testing everywhere. posted by ruffin at 4/16/2002 10:19:00 AM
0 comments
From another 15 seconds list post: ..Where MyControls:body is the webcontrol I'm writing, how do I access the stylesheet data from within my control? I would have thought it would be something like.. string fontsize = this.Style("font-size"); ..but that doesn't seem to work. I've also tried working with the .ControlStyle and .CssClass properties but to no avail. There's something wrong with a set-up that makes it difficult for a web programmer to find out how to set cascasding style sheet properties. That's right, it's our friend .NET. posted by ruffin at 4/16/2002 09:32:00 AM
0 comments
Monday, April 15, 2002
Interesting Q&A with Blogger owner dude at Internet Magazine, whatever that site is: Q: Tell us a little about the premium product on offer and how takeup/feedback has been so far. After talking about it for two years or so, we finally launched Blogger Pro at the end of January this year. So far, it's just Blogger with a few add-on features -- things like spellcheck, image uploading, email out, etc. It's also a bit faster and more reliable than the free version because it runs on separate servers for the most part, and if there are any scaling problems, Pro users get priority. The plan is for it to be much more, so the uptake for just starting out has been great. I didn't really expect a ton of subscribers until we launched some of the cooler stuff we have in the works, so I'm happy with how it's doing. It's a testament that people will pay for web services that are important to them or make their lives easier. Kinda scary that it's that easy to sell web services to the masses. Looks like Ballmer and Co. (and whoever that guy was that just got released) are right. posted by ruffin at 4/15/2002 11:47:00 AM
0 comments
Who'd've thunk forcing a web page to print in a landscape layout would have been so tough, even in IE ( which requires an ActiveX script). Usually at least IE lets you do crazy stuff like this, so that you can create a prototype to show the team before saying, "So there it is. And that's never going to work crossplatform." They usually like that answer a lot better than, "Forget it." So am I advocating a better user experience in IE than in other browsers, the same way .NET does? Um, tell me why I shouldn't in this case (were there some non-ActiveX way of doing it). Anyhow, this looked promsing, but no go (unless you really like Opera). More links brought to you by the letter E, the number 3, and Matt. posted by ruffin at 4/15/2002 11:44:00 AM
0 comments
Wednesday, April 10, 2002
By far the most interesting series of articles I've read in a while, this group of jive on IBM's future and its dependence on Java is a great read. This bit was featured on Slashdot, but don't stop at the article entitled When Will IBM Buy Sun, or, even worse, at the title of the article like so many Slashdot posters seemed to have. The idea that IBM would buy Sun in a hostile takeover is just an extended metaphor for what kind of power IBM needs. The author continues this line of thinking by showing how IBM doesn't need to buy Sun, it's only got to get Java open sourced or changed into a true open standard, though that article is more about how IBM's used open source as a weapon to make its proposed standards into de facto ones before any ruling body has a chance to change the proposal. Here's a key quote on that subject: If Sun, the Java Community Process, or the other ebXML supporters had any objections, it wouldn't matter. When code like this is given away, it has the same effect on developers that the price of Microsoft's Internet Explorer (free) has on end users. A standard is born. Clever, eh? Overall incredibly interesting. "Personal revelations" from the list included... * Me finally figuring out just how ballsy the name Eclipse is for IBM's open source competitor to Sun's Netbeans (duh, sun, eclipse, even if IBM claims the name was a coincidence) * IBM's Standard Widget Toolkit is doing what got yesterday's article author so fired up about the Mac, but in a much more cross-platform friendly manner. Both are intended to make Java a true player on the client-side to compete against Windows. * Lingua franca means "a common language consisting of Italian mixed with French, Spanish, Greek, and Arabic that was formerly spoken in Mediterranean ports", according to Merriam-Webster Online (which gives a little more meaning than my previous understanding which was limited to "a common lang"). I think I knew that before, but it doesn't matter if I'd forgotten. * Netscape 6.2 for Win2k has real issues with cleaning up after you close a window, pegging the processor. This problem is compounded when you have multiple windows open at once to read all these articles. Enjoy. posted by ruffin at 4/10/2002 11:14:00 AM
0 comments
Tuesday, April 09, 2002
Somebody on the java-dev list at Apple (for discussion Java development on the Mac, no less) posted a link to this article on eweek strangely titled, "Hot Java Revives Mac Programming". At the end, the author asks for reasons why he shouldn't go back to the Mac based on how great Java is now in OS X, and the poster on java-dev said it'd be great if we all emailed him with reasons why he should stay with the Mac. Whoops. I, of course, emailed the dude with what I really thought. Here are some bits [of my email to the author]. ... it's important to remember that most iBooks and many PowerBooks don't have a video card that's powerful enough to take advantage of this graphics acceleration [that Apple has built into its virtual machine that got the eweek guy so excited], so those users (not to mention any poor schmoe with OS X on an unupgraded Rev A-C iMac) are still in performance purgatory.... The bottom line is you now need to know not only that you're running on OS X but what hardware you're using -- turning HWaccel on when you're on a less than optimal system has reportedly caused slowdowns on some machines... "Write on the Mac, 'Run anywhere,'" is definitely not the take home message to me from Apple's HWaccel implementation. ... [vent about Project Builder compliments in the article, mention Java 3D is lacking and no release date for Java 1.4 on Mac -- and I started with the general perception that speed of Java on Mac is too slow, causing some programmers not to release for OS X]... Hey, I love the Mac. I use a dual-USB iBook at home to test and program Java apps, and I've always been happy with the user experience Apple provides. But to program with anything less than the highest end, 1 GHz DP system running Netbeans (okay, now I'm trolling a little), much less to expect your finished product to run well on any client with OS X, is giving Apple too much credit. There's a lot of work ahead before you get me to give up Windows as a development, not just target, platform. So there you have it. Just spent so danged long writing that I thought I'd blog. posted by ruffin at 4/09/2002 06:20:00 PM
0 comments
Abstract ADO.NET is trying to make ADO.NET more JDBC-like. Why? Here's a pretty insightful quote. The most heinous problem is the exception heirarchy. No matter what goes wrong in JDBC, you will get a SQLException. In ADO.NET, depending on the underlying provider is what type of exception you will get. [sic] Using the SqlClient classes, you will get SqlException. Using the OleDb classes, you will get OleDbException. Using the Oracle classes, you will get OracleException. And so on and so forth. The ADO.NET architecture really is only half-done. As long as you're only using one type of backend, things are great, but one of the best parts of "classic" ADO is the ability to transfer [again, "classic"] ASP 3.0 code from a, say, SQL 7.0 backend to Access 97 with the change of a connection string (problems with the way Jet handles date strings, etc, ignored for now). JDBC is similar. It'll be interesting to see how Abstract ADO.NET works out, and how they'll write code so that it doesn't lose some of the advantages gained by having finely tuned object models for many different rdbms systems, not to mention how it'll handle 3rd party ADO.NET connectors written in the future. posted by ruffin at 4/09/2002 03:07:00 PM
0 comments
Monday, April 08, 2002
Over at ye ole Salon we find a somewhat ramblerific article on software evolution which pretends it's mostly about "Meir 'Manny' Lehman", apparently the first guy to do a paper on software evolution, in his case OS/360 at IBM. Ole Manny apparently came to the following conclusion: OS/360 was heading over a cliff. IBM, in stressing growth over source-code maintenance, would soon be in need of a successor operating system. IBM reportedly ignored his report, but 3 years later were splitting OS/360 into two more manageable branches. The bottom line of Manny's theory, which is apparently relatively hotly disputed in the right circles, is that software tends to grow in a curve that's the inverse (I think... been a while since I had geometry) of Moore's law (which has processor power growing at a geometric rate). The blame seems to be laid at the feet of programmers, who'd rather add something new than test something old, making larger software projects grow into a more chaotic system, in a fashion, when it comes to "bugs over time". In other words, any program that's been around long enough, unchecked, left to software developers' own devices, " all software programs are ultimately doomed to succumb to their own internal inertia" (From Frederick P. Brooks' "The Mythical Man Month", quoted by the above article, and reportedly based on ole Manny's work). Without adding energy to the system, in a sense, specifically for the removal of this chaos, software development produces poorer progress per unit of work added over time. That software developers like to add new instead of understanding old isn't a new idea. Old man Joel has said something similar about refactoring code instead of rewriting it. Strangely, though, it would seem that keeping old code, according to Manny, would make it so that keeping this old code puts you on a one way course towards "succumbing to your own inertia", so to speak. I'd guess Joel's response would be that most people aren't working on OS/360 or a likeminded project, and that you're generally much better off keeping what you've got [and the lessons the code's already learned]. There's also the obvious possibility that we're talking apples and oranges -- developers would prefer to add something new than to fix something old, which I believe is a complaint of the open source software movement (that things are added all the time, but not well-tested). But the apples and oranges arguement aside, it would seem that if there was only a system where many programmers could add their "fresh, new, inertialess" code to a living whole, you wouldn't find yourself smacked on the head by the continually more complicated vortex products like [traditionally created] operating systems or Microsoft Words possibly produce. Hrm. That process sounds familiar, doesn't it? Another poorly edited ramble by ole Rufbo there. posted by ruffin at 4/08/2002 02:11:00 PM
0 comments
Thursday, April 04, 2002
I've been reading SAMS' Programming Data-Driven Web Applications with ASP.NET written by the two dudes that run dotnetjunkies. So far the book is thorough in the number of elements it touches and attempts to explain, but very surface level. "Here's widget A, here's a description B of widget A, here's an example code dump of me using widget A's closest cousin to 'Hello World!'." That's not bad, but so far has had about 250 pages that have involved nothing more than skimming. I like a book with more tofu (trying not to offend anyone other than my own sense of taste, there), but it could be that I'm just that far along with my knowledge of ASP 3.0 and html that this is pretty much all old ideas. Anyhow, the point of the post is that I notice these two dudes, who I often hold up as the representation of the archetypal higher-end ASP.NET programmer, have a bad habit of having 8 lines of asp.net code where one of html would do. For exmaple, here's what they do to place a name/title over top of a list of checkboxes: <asp:Label width="100%" runat="server" text="<center>Pick Products</center>" BackColor="white" ForeColor="Navy" Font-Bold="true" Font-Size="13" /> Why not just use <center>Pick Products</center>? Maybe couch in header tags? Backcolor is white over the whole page already... Anyhow, here's the code you get on the page: <span style="color:Navy;background-color:White;font-size:13pt;font-weight:bold;width:100%;"><center>Pick Products</center></span> At least MS uses css for the boldness, but shouldn't they double tag? (ie, use b tags in the middle) I don't know. The big idea is that there are so many places for expressing personal preference in how html is rendered, I just can't imagine leaving it all up to MS. Even then, we're adding the "center" tag to this label's text attriubte. Seems wacked. I also wonder about learning to add tags like the above with all these attributes defined within. That is, with codebehind you're supposed to be able to place all the code for a page in a page the web designer never has to see. Should this part of the code be for the web designer or shouldn't it? Shouldn't you just have a "label" there and let the web designer's stylesheet determine how it's displayed? Set/change the text and font, etc, in codebehind, and then only if you have to. Phew, that was a poorly directed rant. Oh yeah, my port of furthurnet to Mac OS 9 is coming along. No word from the devvers about my bug questions as of this morning though. posted by ruffin at 4/04/2002 05:33:00 PM
0 comments
Tuesday, April 02, 2002
Talk about your interesting and useful but not necessarily "short-term productive" timesinks. Some Randmo AIMer sent me news that KaZaa included a pseudo Trojan horse that's potentially about to be activated on its users' computers. This thing will turn "unused" hard drive space and bandwidth into a commodity that KaZaa's partner, the makers of the piggyback app, can use freely. It's all in the KaZaa license and I'd guess nothing illegal is happening, but it's a little sneaky. But the more I think about it, the cooler the concept of mainstreaming distributed computing seems. SETI@home really pioneered the modern [or is that "post-modern" now?] version of this idea from where I'm sitting, and some good work with everything from finding these aliens to cures for cancer to compounds to kill Anthrax have received help from all those computers that are sitting around the nation idle. Heck, I've done 545 work units for SETI@home -- and counting. Though I'm not big on KaZaa's slick introduction of the piggyback distributing computing app, if you think about it, it's a very very good idea. Why not employ what's traditionally a client as a server? Every new PC sold today is more powerful than the traditional web servers of three or four years ago, I'd think. As long as the server part is backgrounded (given a low priority when it comes to gaining processor time) when you're, say, playing Quake, it's a great use of resources. As noted on slashdot by another poster, let's face it, this unused processor time and bandwidth is a huge, untapped resource, and has every trait needed to be a traded commodity like pork bellies or something similar. [colorful, eh?] I'm actually finding myself happy to hear this idea has left the desks of researchers at Microsoft looking for a new way to employ operating systems (another great idea, imo) and has hit Main Street. That said, I'm not planning to use anything other than Furthurnet to get new music for the cost of bandwidth and hard drive space online for the foreseeable future! posted by ruffin at 4/02/2002 11:01:00 AM
0 comments