MKLinux a few years back was painful, it still is sort of. I actually had to low-level format my scsi drive or it would cause the kernel to crash at boot-time when trying to scan the bus.
Anyway, I would suggest 2 things when using a unix on the PPC.
use NetBSD, particularly good if you're used to a more BSD way of life. Wasabi has a bootable CD
use Debian. Granted it takes some reading to get a bootable CD going, but there are iso images available now. debian site
The problems I've had with redhat based systems on the PPC (like Linuxppc2000 or YDL) have been numerous, ranging from default installs that don't install dependancies correctly (like kerberos for sshd) to a GCC compiler suite that cores when you try and build anything with a "warning! internal compiler error" message. It's sick.
I just mailed this to a vegan friend who got one of those fish as a graduation present (odd eh?). But after reading it... with all the pork references... I'm begining to wonder if it isn't a somewhat unvegan site, and lets not mention Islam.
An expensive 50 year off tunnel (count planning, engineering, construction, rework due to construction technology changes) is probably not your solution to "shipping is slow, aircraft are costly" Mainly because there isn't all that much cargo that wants to move from alaska to siberia of vice versa. Hence cargo destined elsewhere would have to move to alaska or sibera from its original destination, then under the straight, and then to its final destination. At train speeds, even high-speed (which is so unlikely), it'd take about as long as shipping, and cost more.
So, I suggest a modest investment of a fraction of the proposed cost in: CargoLifter. A decently large fleet wouldn't cost tens of billions, and would provide cheep fast enough cargo service. We could scrap the alaska-siberia issue (being close is not as nescesary), and concentrate on moving stuff between the pacific coastal areas (like San Francisco up to Vancouver (is it?) over to Japan, Hong Kong and some of China). See also: a summary of the cargolifter project.
Now I am a fan of both trains and airships, so ultimately I should like to see both come to pass. But before the bearing-tunnel is a good idea, I should like to see capable, speedy, regular, and affordable rail travel instituted between North American cities at least, then central america and south america too. By regular, I mean Boston to Chicago or Washington at least four times daily (one way), and close locations like Worcester to New York (or even just Boston), or Houston to Dallas, hourly or if they're really close (like an hour appart) then half hourly.
Apple needs to make money so
that it can (repeat after me) continue to stay in business.
That's absolutely correct. And for that we like 'em as much as any other for profit company, tempered of course be the quality of their software.
Hence, we hate MicroSoft because its product sucks and its profit is unfair to a number of nations; we liked Bungie because their products were great and their profit was acceptable; and we're abivolent to Apple because their products in hardware are good, their software is good but slow moving, and their profits used to not exist but are hell bent on getting larger.
But this has nothing to do with the issue at hand, which is that Apple isn't making money from freetype by sueing them (although its costly for all, more so for freetype), but rather apple is enforcing a patent that excludes people from using truetype. This is more an issue of it being rediculous because its not a copyright infringement, and truetype has been around for 5-6 years now. So it comes down to the fact that there shouldn't be patents on such things.
Perhaps apple is scared it will loose whatever it gets from MS for their use of TrueType if they end up managing to do the same as FreeType with a clean-room implementation, or if they figure out how to incorporate FreeType.
ut at least when you buy x86,
you aren't neccesarily funding a company who is spending your money on preventing interoperability
What with Sony? you are so fooling yourself. Besides, Apple will have an all new laptop out soon in January. You'll want it, and you'll cry if you can't get it:). Besides, the people at Freetype knew this was a possibility, so did SDL when it advised about using Freetype.
Oh yes. I had seen the Developer Preview release of Rhapsody at MacWorld in Boston sometime around 1998. That made me think "any day now". I should have remembered the name copland though. Then at some point that became a movie I never saw. Odd isn't it.
I just thought I'd point out, while everyone's arguing how much better than RPM the dpkg system is, that
NetBSD's Package System (pkgsrc) is a particularly great system that has the capacity to hide most everything from you, or not. It works particularly well with source packages, which if you like you can configure with particular options yourself, and it also has a good variety of prebuilt packages.
Its a funny story really:
Some time in 1992 or something (who can recall) apple said it'd go to PowerPC processors for its macintosh line. But it said that it wouldn't be able to do so until it wrote a good operating system for it. This they said was a very good thing as it would give people such wonders as pre-emptive multitasking (an amiga staple, and an anounced feature for windows 95, or chicago (ciaro? I forget)).
So people sort of waited. A year on or so, people really wanted these new wonder macs with the RISC processors, so apple went ahead and made them. All marveled as they ran the same old operating system, just a bit slower than a real 68040. Those in the know said that it's to apple's credit that they wrote such an effective emulator that the enitre operating system could run on it, but they were dismayed at the lack of the good stuff a decent risc processor could have offered, like better memory management and such.
Funny enough, later (1995?) apple released 604 based machines, about the same time Be released its dual 603e machine (BeBox) running a wonderfully capable OS with wonderful hardware features, and no applications. With this new release, apple said in a year, we'll have this new and better OS out... lets call it rapsody. Great!, many people bought 604 machines thinking that soon, they could run rapsody on them.
But that was delayed. Then scraped as OS 8 came out. mind you, os 8 has more native PPC code in it than ever before, such that 8.1 was all PPC and 8.6 was only for PPCs (they dropped the 68040). But still there was no grand OS.
Be OS was rumoured to become part of apple such that it could be used as the foundation for they're next operating system. But then it came to pass that next would actually provide thier next operating system. In a promissed period of 6 months no less.
Okay, there were some developer releases in 6 months of openStep on both intel and PPC, but... that didn't really help any mac users. Then there came os 9, sans pre-emptive multi-tasking. And then eventually the beta for OS X.
In the mean time the PPC machines are selling better than ever, and the old system no longer seems so crippling, mainly cause its not really all that old anymore, just crufty.
I don't think standard clustering would work for this. Considering there are no VST solutions for clustering, and you'd have to write your own anyway, I'd definitly not suggest trying to do the processing in a loosly clustered environment. The problem is that your processing would get a lot of latency, and couldn't be done in real time for you. A better idea would be to have one machine per effect stage and then pass digital audio between them... preferably with a IEEE1394 interface. Of course if you had a tightly clustered system, you shouldn't have too much of a latency problem for the human ear.
Most DVD players are sold with
multiregion hacks preinstalled.
That will be because in Switzerland you have a law that makes regionalized releases and hardware illegal such that a DVD player/must/ have a multiregion "hack" installed to be officially saleable. That's some fairly admirable legislation, recognizing that a nation can be just as threatened by foriegn corporate interests as it can be by foreign national interests. Switzerland still is as expensive as I remember when I lived there, but then, if you were to tack shipping onto a US purchase, you'd be paying about the same price for region one anyway.
The difference here is: the BFS doesn't index its files centrally to some index. Each file has a variable amount of attribute data that can be extended as the user/developer wishes. That attribute information is stored directly in the file system info tree, although if it gets really big its stuck into a hidden file [or extra node/block actually].
This is super-slick because the file system info tree is structured mostly in places where the head of the drive can get to fast, and usually right next to tons of similar information about all the files in a directory or group of directories. This way you can read a couple blocks of file attribute information without ever having to actually skip to the files themselves and search that, thus acheiving a great savings in head movement. Its similar in basic concept to the BSD Fast File System and the Linux Ext2fs, in that they do the same for filenames, sizes, and other attributes. But the BFS has extensible attributes.
So extensible attributes mean:
I downloaded a file from somewhere, besides just a filename=foo.tgz, I could put a from_URL=ftp://ftp.foo.org/pub/foo/src/tgz/ attribute there.
All mail messages have their subject, from, to, reply to, and all that stuff stored as attributes, and all mp3s have their ID3 tags (and possibly more) stored as attributes. So you can just grab stuff that matches the attributes you want. This happens really quickly because the head only has to skip to the general inode information, better yet, any smart OS will cache all that in memory, so a large portion of your search is done without drive head movement.
Large attributes exist too. For example some drawing programs store a scaled down preview in an attribute... fair enough, that is in an extended attribute node/block, but that node/block doesn't have to be searched or then cached unless it's known to contain the key that is being searched for.
So sure, any OS could go ahead and index mp3 id information, cache it, maintain coherancy between it and the fs, and search through it, but for Mac OS, that would take a seperate indexing phase, an extension that pays attention to fs changes and updates the index, and a special extension to a special searcher (the BFS search is just an fs feature with a gui interface) that looks through the special index. And that is just as feature rich, but it lacks the performance considerations that were taken into account when building such things directly into the fs.
I do like the Mac, unfortunately Be sucks for not keeping developers more PPC aware, even if Apple forced them out of developing for G3 [not that that has stopped NetBSD or linux even]. It's a real shame because the BeBox was one of the coolest ideas in a long time, especially because of the OS, but not solely... the PPC is a cool chip (literally too).
-Daniel
P.S. The guy who developed BFS presented it as a talk at WPI (cause he graduated from there), and the guy who developed Ext2 came to talk to the linux group a few weeks earlier over how it worked and what may be done differently for Ext3. Both were very informative
I don't think there's any way that people who play games will stop playing them (unless they grow old and work, but then there's always new people). The only trick is that the expansion of gaming may stop. I mean the PS1 will still sell well for a while, and people may never really need more for playability. If good games continued to be available (like bomberman on the TuroGrafix 16) then They'll be played. Its just that people may end up with their 50 most playable games (WipeOut 3, tetris, other stuff that's replayable) and stop having an interest in FFIX because its just a movie where you have to hit buttons to keep watching and where the plot becomes tediously mysterious or confusing. Granted new games will be made that are playable like crazy taxi, but the point is, people won't want many games, and if they do, they won't want to buy special hardware to play it... not after they have a PC and 3 games systems already.
True. But if you read all the m68k specific NetBSD stuff you'll find that its a hardware issue. Yup, the clock that the system "knows" runs funny over time while on; apparently its behavior is improved or resynched to some other clock through long down times and/or frequent reboots.
Suggested fix: sync to a network clock.
asside from the fact that a product is just no good unless it's bugs are fixed (assuming it has bugs), its really sad that projects that seem promissing and represent a large investment of time get cancelled.
But about making and selling applications with simpler, smaller feature sets, I think you're going to come up against two kinds of reality.
The first is the fact that maintaining mostly essential features is a good thing (yay vi or bbedit) for the user and the programmer (especially in terms of memory, disk and cpu usage).
The second is the fact that no average consumer is capable of passing up a feature, no matter how detrimental to their overall memory, disk, and cpu usage nor their stability. Besides the popularity of word, just take a look at an average permenently connected windows box, and see how many little pieces of crap software they're running at startup and in that little tray area that they jsut don't need, no longer understand, and often cause them to wonder why they keep getting error messages from this or that cryptic application name. They see a cool windows feature/extention on the net, they grab it, they forget.
Ah. I'm not sure how many of you read that as privacy for the company and it's employees, but apparently the intent was more to concern themselves specifically with the impact they have on other's privacy, primarily their customers'. I think that this is a very nice turn of events that there is some form of decision making going on in protecting and ensuring a level of privacy to all the people who deal with the company. This should be done everywhere in a more centralized and overall rational manner.
How about an epic alien opera about dryer lint that lives off space robots and infests our planet with businesses with a quirky and irrevernt personality who are all part of a revolution lead by mexican food and pitched at celebrities who like linux "Just for Fun" such as Linus?
It'd be co-autored by David Diamond in collaboration with Linus's parents of course.
-Daniel
P.S. Seriously though, at this point an autobiography may be a bit much; how about an interesting except from my life revolving around computing issues that have recently become popular. Lots of authors do that and they don't call it an autobiography... Like that cliford stoll book or something, but better.
the only odd thing about the organisation that Debian is is that the docs are a bit bad. They sort of rehash the same old docs and edit just a few things here and there, many of them are not clearly available in any html doc link, and are intended to be read once you've downloaded the installation. I think that a group of people out there specifically working to help keep people informed about where all the config files are and where the links to basic install information is would be quite helpful to those who want to try linux, and have heard that debian is better to use once its running than say red hat. Which is an opinion of course, but it would be a shame if they didn't get to experience the Debian dist just because the redhat dist has clearly addressed newbie issues.
And we'll all be typing in Esperanto on our Dvorak-layout keyboards.
To be sure that no one's confused: Dvorak layout keyboards are layed out to allow better typing of the english language only.
I'm not sure, but I think it'd be safe to say that Dvorak also applied his methods to other langues, and hence it's a shame that the English Dvorak keyboard was simply named Dvorak.
Sometimes I wonder if all that good copper, and other precious metals, in electronics will ever be recycled. Imagine having to start scavanging for copper through a junk heap of electronics; the tedium...
Anyway, Seeing as this thing wieghs tons, there must be a partial ton of copper in there... one has to wonder if there are any plans for reuseablity in this thing.
That's odd, I thought both IEEE 1394 and USB were open. Of course I've been having a hell of a time finding some good info on going about implementing both hardware and software of the former. But then I didn't want to spend close to 100 on a spec book from ieee, and I'm not an EE so I find many of the discussions I've found so far opaque.
-Daniel
I'm pointing this out to serval people in this thread at once; but here first I guess:
Oh, jeeze. UNIX, for Seldon's sake. and the other comment: Unix and C
C wouldn't have meant much without unix, I mean it could have, but I doubt it would have. Unix would never have meant much without it's openness. Leading to its popularity in academic communities and hence fostering BSD, Linux, and a bunch of the comercial unixes. The areas which Unix covers so well are largely a result of collaboration of people who were allowed in by the openness.
Unix would never have been open if the government hadn't/FORCED/ it to be so. The line was: okay, your a monopoly, but you can't start using that to extend your monopoly into the realm of computers, so you must make a license available to other people for anything you develop. And/thats/ how Unix got to be what it is. Notice too that the license used to be cheep, and the price of it just keept going up; still does really.
I believe that there is a domain squatter daemon out there, possibly run by NSI. When looking for a few of the domains we did register (throwawayyourmoney.com; slithy.net, syntaxerr.org) my roomate and I were running a few permutations through NS lookup. We did this for a couple of months, often retesting names to assure persiting availablity (we weren't ready to settle on something yet). Then to our surprise a majority of our previously free names had become registered to various networking consultants, web hosters, and such.
The results were even faster acting for a friend of mine testing our theory that people lie in waiting for any name based on popularity. He however used NSI's domain name checker directly through their web interface, to find that on the 10-12th look up (usually from varying IPs) the name would be claimed.
This of course lead to our script idea, that would generate random crap, distribute a largish list to various clients, and have them all periodcally pick a random on every few mintues and try http://www.--- on it. This would last a week and a new list would be made. Compiled statistics on how many attempts, when and from where had been made on each domain, and when these domains had been claimed would then be sent back to be reported in some parsed form. The new list would then be worked through. We hoped that this would eventually discourage people squatting on this basis, due to cost.
Now I realize that cost may not be a factor for someone like NSI, and I realize that random crap may have to be generated from dictionaries and rules. We were further hoping that through a movie name generator (add the or a small set of adjectives to any noun) would cause enough companies to loose their prefered sites, that there'd be some public out cry.
We didn't ever implement this thoguh. We get paid for other work.
First they raised hopes of a civilization; those hopes were dashed. Then they raised hopes of large quantities of water on the planet; now those hopes are dashed. Someone should just tell those cannals to stop looking hopeful.
Slashdot Mirror
Anyway, I would suggest 2 things when using a unix on the PPC.
The problems I've had with redhat based systems on the PPC (like Linuxppc2000 or YDL) have been numerous, ranging from default installs that don't install dependancies correctly (like kerberos for sshd) to a GCC compiler suite that cores when you try and build anything with a "warning! internal compiler error" message. It's sick.
-Daniel
oops. -Daniel
So, I suggest a modest investment of a fraction of the proposed cost in: CargoLifter. A decently large fleet wouldn't cost tens of billions, and would provide cheep fast enough cargo service. We could scrap the alaska-siberia issue (being close is not as nescesary), and concentrate on moving stuff between the pacific coastal areas (like San Francisco up to Vancouver (is it?) over to Japan, Hong Kong and some of China). See also: a summary of the cargolifter project.
Now I am a fan of both trains and airships, so ultimately I should like to see both come to pass. But before the bearing-tunnel is a good idea, I should like to see capable, speedy, regular, and affordable rail travel instituted between North American cities at least, then central america and south america too. By regular, I mean Boston to Chicago or Washington at least four times daily (one way), and close locations like Worcester to New York (or even just Boston), or Houston to Dallas, hourly or if they're really close (like an hour appart) then half hourly.
-Daniel
Ahhh. The Swiss Rail
That's absolutely correct. And for that we like 'em as much as any other for profit company, tempered of course be the quality of their software.
Hence, we hate MicroSoft because its product sucks and its profit is unfair to a number of nations; we liked Bungie because their products were great and their profit was acceptable; and we're abivolent to Apple because their products in hardware are good, their software is good but slow moving, and their profits used to not exist but are hell bent on getting larger.
But this has nothing to do with the issue at hand, which is that Apple isn't making money from freetype by sueing them (although its costly for all, more so for freetype), but rather apple is enforcing a patent that excludes people from using truetype. This is more an issue of it being rediculous because its not a copyright infringement, and truetype has been around for 5-6 years now. So it comes down to the fact that there shouldn't be patents on such things.
Perhaps apple is scared it will loose whatever it gets from MS for their use of TrueType if they end up managing to do the same as FreeType with a clean-room implementation, or if they figure out how to incorporate FreeType.
-Daniel
What with Sony? you are so fooling yourself. Besides, Apple will have an all new laptop out soon in January. You'll want it, and you'll cry if you can't get it :). Besides, the people at Freetype knew this was a possibility, so did SDL when it advised about using Freetype.
-Daniel
And porn sites obviously popup windows too.
-Daniel
-Daniel
-Daniel
So people sort of waited. A year on or so, people really wanted these new wonder macs with the RISC processors, so apple went ahead and made them. All marveled as they ran the same old operating system, just a bit slower than a real 68040. Those in the know said that it's to apple's credit that they wrote such an effective emulator that the enitre operating system could run on it, but they were dismayed at the lack of the good stuff a decent risc processor could have offered, like better memory management and such.
Funny enough, later (1995?) apple released 604 based machines, about the same time Be released its dual 603e machine (BeBox) running a wonderfully capable OS with wonderful hardware features, and no applications. With this new release, apple said in a year, we'll have this new and better OS out... lets call it rapsody. Great!, many people bought 604 machines thinking that soon, they could run rapsody on them.
But that was delayed. Then scraped as OS 8 came out. mind you, os 8 has more native PPC code in it than ever before, such that 8.1 was all PPC and 8.6 was only for PPCs (they dropped the 68040). But still there was no grand OS.
Be OS was rumoured to become part of apple such that it could be used as the foundation for they're next operating system. But then it came to pass that next would actually provide thier next operating system. In a promissed period of 6 months no less.
Okay, there were some developer releases in 6 months of openStep on both intel and PPC, but... that didn't really help any mac users. Then there came os 9, sans pre-emptive multi-tasking. And then eventually the beta for OS X.
In the mean time the PPC machines are selling better than ever, and the old system no longer seems so crippling, mainly cause its not really all that old anymore, just crufty.
-Daniel
What wierd people
-Daniel
That will be because in Switzerland you have a law that makes regionalized releases and hardware illegal such that a DVD player /must/ have a multiregion "hack" installed to be officially saleable. That's some fairly admirable legislation, recognizing that a nation can be just as threatened by foriegn corporate interests as it can be by foreign national interests. Switzerland still is as expensive as I remember when I lived there, but then, if you were to tack shipping onto a US purchase, you'd be paying about the same price for region one anyway.
-Daniel
The difference here is: the BFS doesn't index its files centrally to some index. Each file has a variable amount of attribute data that can be extended as the user/developer wishes. That attribute information is stored directly in the file system info tree, although if it gets really big its stuck into a hidden file [or extra node/block actually].
This is super-slick because the file system info tree is structured mostly in places where the head of the drive can get to fast, and usually right next to tons of similar information about all the files in a directory or group of directories. This way you can read a couple blocks of file attribute information without ever having to actually skip to the files themselves and search that, thus acheiving a great savings in head movement. Its similar in basic concept to the BSD Fast File System and the Linux Ext2fs, in that they do the same for filenames, sizes, and other attributes. But the BFS has extensible attributes.
So extensible attributes mean: I downloaded a file from somewhere, besides just a filename=foo.tgz, I could put a from_URL=ftp://ftp.foo.org/pub/foo/src/tgz/ attribute there. All mail messages have their subject, from, to, reply to, and all that stuff stored as attributes, and all mp3s have their ID3 tags (and possibly more) stored as attributes. So you can just grab stuff that matches the attributes you want. This happens really quickly because the head only has to skip to the general inode information, better yet, any smart OS will cache all that in memory, so a large portion of your search is done without drive head movement.
Large attributes exist too. For example some drawing programs store a scaled down preview in an attribute... fair enough, that is in an extended attribute node/block, but that node/block doesn't have to be searched or then cached unless it's known to contain the key that is being searched for.
So sure, any OS could go ahead and index mp3 id information, cache it, maintain coherancy between it and the fs, and search through it, but for Mac OS, that would take a seperate indexing phase, an extension that pays attention to fs changes and updates the index, and a special extension to a special searcher (the BFS search is just an fs feature with a gui interface) that looks through the special index. And that is just as feature rich, but it lacks the performance considerations that were taken into account when building such things directly into the fs.
I do like the Mac, unfortunately Be sucks for not keeping developers more PPC aware, even if Apple forced them out of developing for G3 [not that that has stopped NetBSD or linux even]. It's a real shame because the BeBox was one of the coolest ideas in a long time, especially because of the OS, but not solely... the PPC is a cool chip (literally too).
-Daniel
P.S. The guy who developed BFS presented it as a talk at WPI (cause he graduated from there), and the guy who developed Ext2 came to talk to the linux group a few weeks earlier over how it worked and what may be done differently for Ext3. Both were very informative
-Daniel
True. But if you read all the m68k specific NetBSD stuff you'll find that its a hardware issue. Yup, the clock that the system "knows" runs funny over time while on; apparently its behavior is improved or resynched to some other clock through long down times and/or frequent reboots. Suggested fix: sync to a network clock.
But about making and selling applications with simpler, smaller feature sets, I think you're going to come up against two kinds of reality.
-Daniel
-Daniel
It'd be co-autored by David Diamond in collaboration with Linus's parents of course.
-Daniel
P.S. Seriously though, at this point an autobiography may be a bit much; how about an interesting except from my life revolving around computing issues that have recently become popular. Lots of authors do that and they don't call it an autobiography... Like that cliford stoll book or something, but better.
-Daniel
To be sure that no one's confused: Dvorak layout keyboards are layed out to allow better typing of the english language only.
I'm not sure, but I think it'd be safe to say that Dvorak also applied his methods to other langues, and hence it's a shame that the English Dvorak keyboard was simply named Dvorak.
-Daniel
Anyway, Seeing as this thing wieghs tons, there must be a partial ton of copper in there... one has to wonder if there are any plans for reuseablity in this thing.
-Daniel
That's odd, I thought both IEEE 1394 and USB were open. Of course I've been having a hell of a time finding some good info on going about implementing both hardware and software of the former. But then I didn't want to spend close to 100 on a spec book from ieee, and I'm not an EE so I find many of the discussions I've found so far opaque. -Daniel
Oh, jeeze. UNIX, for Seldon's sake. and the other comment: Unix and C
C wouldn't have meant much without unix, I mean it could have, but I doubt it would have. Unix would never have meant much without it's openness. Leading to its popularity in academic communities and hence fostering BSD, Linux, and a bunch of the comercial unixes. The areas which Unix covers so well are largely a result of collaboration of people who were allowed in by the openness.
Unix would never have been open if the government hadn't /FORCED/ it to be so. The line was: okay, your a monopoly, but you can't start using that to extend your monopoly into the realm of computers, so you must make a license available to other people for anything you develop. And /thats/ how Unix got to be what it is. Notice too that the license used to be cheep, and the price of it just keept going up; still does really.
-Daniel
Yes. A distributed.net style client was certainly part of the idea.
-Daniel
The results were even faster acting for a friend of mine testing our theory that people lie in waiting for any name based on popularity. He however used NSI's domain name checker directly through their web interface, to find that on the 10-12th look up (usually from varying IPs) the name would be claimed.
This of course lead to our script idea, that would generate random crap, distribute a largish list to various clients, and have them all periodcally pick a random on every few mintues and try http://www.--- on it. This would last a week and a new list would be made. Compiled statistics on how many attempts, when and from where had been made on each domain, and when these domains had been claimed would then be sent back to be reported in some parsed form. The new list would then be worked through. We hoped that this would eventually discourage people squatting on this basis, due to cost.
Now I realize that cost may not be a factor for someone like NSI, and I realize that random crap may have to be generated from dictionaries and rules. We were further hoping that through a movie name generator (add the or a small set of adjectives to any noun) would cause enough companies to loose their prefered sites, that there'd be some public out cry.
We didn't ever implement this thoguh. We get paid for other work.
-Daniel