* Gearhead: Disk drives: We’re driven to drink * Backspin: The Fourth Annual Golden Turkey Awards * Gibbsblog: The past 7 days
Gearhead: Disk drives: We’re driven to drink
Disk storage is notoriously fickle. One minute your drive is humming happily, and the next it’s screaming like a banshee and trying to turn into a lathe – or simply dies. Whatever the issue, at that point the unprepared probably will start swearing, invoking the gods of hardware, sacrificing chickens and, eventually, drinking heavily. We did.
To read this week’s Gearhead, click here.
Backspin: The Fourth Annual Golden Turkey Awards
Good evening ladies and gentlemen. Welcome to the Fourth Annual Golden Turkey Awards.
As usual, our goal is to celebrate individuals and entities that don’t, won’t or can’t come to grips with reality, maturity, ethical behavior or social responsibility because of their blindness, self-imposed ignorance, thinly veiled political agenda, rapaciousness and greed, or blatant desire to return us to the Dark Ages. Without further ado, here are the targets of our righteous anger, barely concealed wrath, withering opprobrium and general disgust…
To read this week’s Backspin, click here.
Gibbsblog: The past 7 days
Web Applications Demo: Tag Clouds by ZoomClouds
This is a demo of a tag cloud created using the ZoomClouds service which will be discussed in the forthcoming November 20th issue of the Network World on Web Applications newsletter.
Please Allow 10 Business Days for What?!
Yep, IT has a tough job. We’re supposed to implement business processes in software and the assumption is that they will work better than the version that was delivered by people and the expectations of users are often higher than we can practically deliver. But not all business processes are hard. Some of these, such as getting information to customers via e-mail, is actually pretty easy.
Marriott, for example, is good at sending out newsletters (which they insist on calling “eNewsletters” — how 1990’s of them) and information about their services. Score one for Marriott IT.
Unfortunately when it comes to unsubscribing it appears that the task is much, much harder. I just unsubscribed from Marriott’s newsletters and got a Web page with the following response:
***
Email Confirmation
You have chosen not to receive Marriott email.
Email address: SOMEONE@SOMEWHERE.COM
Please allow 10 business days for processing.
***
Score minus one million for Marriott IT.
Can someone tell me what the hell takes ten days for an unsubscribe to be processed? Are these people using Sinclair ZX80’s for the job?
There may be some rational explanation such as we batch them and run them through our mainframe-based list management system once per week but that only sounds rational if you think that qualifies as a business best practice (if you know of a better reason, do enlighten me).
Guys, an unsubscribe should be immediate as in at most the same day it is requested. Anything longer and it simply shows that you don’t know what you’re doing.
Getting Rid of Robot Exclusion Protocol
In a recent edition of my Network World on Web Applications newsletter titled Belgians want REP replaced with ACAP I discussed an initiative to replace the established Robot Exclusion Protocol (REP) with another as yet undefined standard named Automated Content Access Protocol which is being promoted by a coalition of publishers.
ACAP is explained as “a system by which the owners of content published on the World Wide Web can provide permissions information (relating to access and use of their content) in a form in which it can be recognized and where necessary interpreted by a search engine ‘crawler’, so that the search engine operator (and perhaps, ultimately, any other user) is enabled systematically to comply with such a policy or licence.”
The wording “enabled systematically to comply with such a policy or licence” is a dead giveaway because the circumlocutory wording really boils down to is constraining search engines by giving ACAP legal teeth which would be defined by publishers in the first place!
Anyway, Mark Bide, the ACAP Project Co-ordinator, dropped me a note following the issue’s publication (Bide works for Rightscom Limited, which describes itself as “a consultancy that specializes in the provision of solutions for the management, trading and protection of intellectual property rights and digital content in the network environment” … in other words digital rights management).
***
Bide’s letter read as follows:
As the project co-ordinator of the ACAP pilot project, I am writing in response to your article “Belgians want REP replaced with ACAP”, since it contains a couple of misunderstandings which it might be helpful to your readers to correct.
The first is the most important. ACAP has no intention of replacing REP; REP has proved itself a valuable protocol over more than a decade, and there is no intention on the part of publishers to dump it. However, REP has a limited scope, and is unable to reflect the much more complex business relationships that already exist between publishers and intermediaries (including search engines) on the network. ACAP is intended to create a machine-interpretable policy language to manage those more complex relationships (where the binary “on/off” nature of REP is inadequate to the requirement).
The second is rather more a reflection of the headline than the text, inasmuch as it becomes clear in the text that this is not a Belgian initiative, and its launch in proximity to the Belgian court case is coincidental – although the fact that the Belgian case was brought at all could be seen as demonstrating that the requirement exists. ACAP is being created and supported by publishers globally not simply in Belgium or even in Europe. It is also being seen by search engines and other intermediaries as having the potential to deal with otherwise intractable problems of scale in the management of what are, after all, business relationships.
***
My response to Bide’s letter is:
Thanks for writing. Your response raises some interesting issues.
The first issue is about these “relationships that already exist between publishers and intermediaries.” This implies that these already existing relationships require more definition which begs the question of what kind of “relationships” are these and how are they inadequately defined.
The second issue is that the details of ACAP are completely unspecified in anything other than a hand waving sort of way. My distrust of what ACAP appears to be doing stems from the assertions that “something is needed” and the “otherwise intractable problems of scale in the management of … business relationships” without any specifics of what the real problem might be and what a “solution” might entail.
Your FAQ, for example, is long on generalities and woefully short on details which makes ACAP look more like some kind of digital rights management exercise that could only be enforced by law; something that would be a highly undesirable.
One thing is certain; if ACAP is aiming for legally enforced Web content DRM you have a long battle ahead of you. I look forward to some hard details about what ACAP will really be about.
