Is that unless you are a web application developer, Ruby's basically got nothing to offer. Not only is Rails the killer app for Ruby, it's the only app. That makes me uneasy about picking up the language.
Also, you forgot Django in your mentions of Python web frameworks.
The first program I tried to write in Python was the quick-and-dirty thing I need most: Read a file and parse it using regexes. Perhaps I stumbled upon the one area where Perl shines in comparison with Python, for that is the impression I got. The Python regex methods do not seem a natural fit for the problem.
Well, to be honest, you picked the one task that, above all others, Perl is engineered from the ground up to be good at, and compared it to the same task in another language which doesn't place any special emphasis on that task. If you take a language that specializes intensely in a particular task (and I don't think anyone could claim Perl doesn't place a huge amount of focus on text processing with regexes), it's probably going to be better, for that particular task, than a language that doesn't specialize in that task. In much the same way, if you want to do clean object-oriented programming Python's got Perl beat hands-down; Python is OO to the core, and is now designed to be that way, while Perl's OO is still in the "bolted on" phase. So really, it all depends on the task.
As I understand it this bug in Rails was fixed and no longer affects Typo - since you bring it up I suspect you know more about it than I do? Please clarify.
The leak was in Rails 0.14.1, and it was patched in Rails 1.0RC3; a write-up and links to full details are here. Typo was, so far as I know, the only Rails app which ever managed to trigger it. And I'd say that's because, well, Typo's a bit of a beast. But then I don't particularly care for Rails for any sort of content-management; its application orientation means that for "CMS-style" tasks like blogging you have to bring in all sorts of components (like login generators and admin interfaces) which add overhead. If you're going to do content-management with a framework, use something like a href="http://www.djangoproject.com/">Django which is far better suited to that task (where Rails was extracted from a web application -- Basecamp -- Django was extracted from a newspaper site).
Realistically, if you design an application from the start with even just a little bit of, well. . . design, and consideration for portability and future growth, database independance is not very difficult.
Unfortunately, it's been my experience that most people don't really think beyond the next few hours when they're coding, which means that making things better later on is a huge chore.
Reiterating a comment I made above, and expanding a little:
Sometimes there is a good design reason for not supporting multiple backends; for example, Textpattern, my personal favorite for blogging/lightweight CMS solutions, has long been MySQL-only, not because of laziness or ignorance, but because Postgres doesn't have fulltext indexing by default (requires either of two contrib modules which don't get built in a standard Postgres install), and Textpattern uses fulltext indexing. There's a development branch of Textpattern which has experimental Postgres support (even though the trunk is MySQL-only, Textpattern does use abstraction in its database interface) which may or may not make that available for the future Textpattern 4.1, but I haven't had a chance to play with it, so I don't know how they're working around that problem.
And while I tend to be fairly DB-agnostic, I can understand that deliberate targeting of MySQL is a good way to keep an application like Wordpress manageable; since MySQL is by far the most common DB available for its target market (shared hosting customers), this pleases the most people while keeping the need to worry about inconsistencies between DBs to a minimum.
You might want to check out typo, an open source blog developed in Ruby on Rails. From the overview: "Supported databases: Mysql, Sqlite, and PostgreSQL"
Typo's a bit of a beast, though, in most shared hosting environments. And there was that nasty memory leak in Rails it exposed a while back...
If you're right, and adding PostGRE is the trivial task that you imply, then it should be a snap, and WordPress will be the better for it. If it turns out to be a little too daunting, then you'll have answered your own question of why it hasn't yet been done.
While I don't know about Wordpress, I'm a fairly active Textpattern user and the reason for the lack of Postgres support in the past was always that Textpattern's search function relies on full-text indexing, something Postgres doesn't quite do natively (it requires either the fulltextindex or tsearch module, neither of which are built by default). There's now a development branch of Textpattern with Postgres support, though. I haven't looked at the code, but it may be that they're working around it somehow.
And one other thing, now that I think of it: if IE on Windows and Mac used the same core code, with the only differences being in, say, system calls to the OS, then the defense of "we can't unbundle it, it's a core part of the Windows operating system" would have had even less chance of holding up in court -- it's a core part of the OS, but you just changed a couple things and it runs fine on the Mac?
Long Answer : They probably have (or should have) a "core" which is identical to any system, only the system dependant api, or itnerraction of that core renderer with the system, would change from IE mac to IE Win (read file, allocate memory, render window, call external program etc...). There is no way they would open their "IP" (the core) to the world.
Now it might be that the core is compeltly different from a system to the next. Then I will probably be the first to yell "what the hell were they thinking ???".
IE/Windows and IE/Mac are very different beasts under the hood. IE/Windows uses the same rendering engine (Trident) that it's had since version 5.0, which was a pretty serious rewrite. IE/Mac (and MSN for the Mac) use a completely different rendering engine (Tasman) which was written by a different team. And in its day, IE 5 for the Mac was actually the most standards-compliant browser available; its rendering engine was the first to boast full support for CSS Level 1 (helped in no small part by having Tantek Çelik -- who was Microsoft's representative in the W3C CSS Working Group -- on the development team). It's just that with the alleged end of the browser wars, a culture of stagnation took hold in Microsoft's browser development, and Mac IE was pretty much abandoned; no new standards support has been added to it, that I'm aware of, since version 5.0.
And as far as I know, Office for the Mac is (or, at least, used to be) much the same way; a completely different development team works on it, and it shares very little core code with the Windows version. This might seem wasteful, but a few blogs of current and former Microsoft employees have pointed out that there was always a separate "Mac unit" within MS, and offered a few justifications for it, most prominently the fact that the Windows and Mac environments are so different both for developers and for end users that this was seen as the best way to handle things.
If I was to make an Amazon phishing site, I would have my backend proxy username/password to the Amazon APIs.
The Turk site doesn't ask for my username and password; it shows me my information without my having to enter it> So your hypothetical phishing site also needs an XSS hole in every major browser which allows it to read the cookie Amazon uses to store session info.
To verify the legitimacy of the site, manually type "amazon.com" into your browser's location bar, and hover over the "See all 32 Product Categories" tab. When it pops up the list, click "Web Services" and read the first item listed on that page, which is a press release announcing Amazon Mechanical Turk.
For extra points, do this only a machine which has been booted from a liveCD with DNS utilities and hosts file that you have personally audited.
Or just, you know, look at the fact that the Turk will, by default, display the name and address you've given to Amazon as your contact info, and conclude that yeah, it's an Amazon property.
Amazon now apparently provides web-hosting services. I've only skimmed, since I wanted to type this fast, but, hypothetically, but couldn't it be someone hosted? The fact that I can't navigate to that page from the main Amazon page sends up a red flag to me.
I clicked through to try one of the tasks, and was asked to confirm my full name and mailing address, which were displayed correctly and match exactly the contact information I've provided to Amazon in the past. So either A) someone has cracked Amazon's custoimer database and found a way to hijack the amazon.com domain cookie in every existing browser, or B) it's legit. Which one do you think is more likely?
In practice, the Shuttle, as it's been used, is like a miniature station of its own. It goes up for a week and then comes back.
It goes up and does... what, exactly? The crew talk to some elementary-school kids while all the experiments run automatically. Which is also about all the ISS does. So what's the point of this thing?
But, since we have neither completed station, nor appropriately sized cargo ship, nor appropriately equipped pods, the shuttle actually works out okay as a pricey jack of all trades.
You mean it works out as a pricey jack of one or two trades which occasionally explodes and kills everyone on board.
The ISS doesn't really serve any useful purpose at this point. It exists as a place for the Space Shuttle to go to, and the Space Shuttle exists as a vehicle that gets us to the ISS. Check out this article for more indo.
Let me help you by writing this up in a way you'll find useful:
Today Ubuntu (Ubuntu is a distribution of Linux (Linux is a Free Software (Free Software is software (software is any program which runs on a computer (a computer, actually more properly an "electronic computer" or "digital computer" is an electronic device which performs programmable computational tasks)) which is licensed under the GNU GPL (the GNU (GNU's (GNU's (GNU's (GNU's (GNU's (GNU's (GNU's (GNU's (GNU's (GNU's (GNU's
Of course it has poor support for XHTML: when IE was last released (6.0) XHTML was still brand-new.
Consider these inconvenient facts:
The first working draft of XHTML 1.0 was made public in December of 1998.
XHTML 1.0 became a W3C Recommendation in January of 2000.
Internet Explorer 6 was released in October of 2001.
XHTML 1.0 did not introduce any new tags or attributes, and did not remove any tags or attributes; it is element-for-element identical to HTML 4.01.
Microsoft is a member of the W3C and had access to and input on every single draft of XHTML 1.0.
Even if we decide to be generous and say that Microsoft's IE team couldn't take advantage of the working drafts of XHTML 1.0, that means that they had around twenty months in which to implement something that didn't involve any new tags or attributes, and on which they'd had been providing input and receiving constant updates for nearly three years previously. Would it really have been that hard?
In terms of using screen corners, Windows uses the lower left corner for an applications menu, the lower right corner for system/application information, and the upper right and upper left corners for application control when the app is in full-screen mode.
Ever notice how some of those handy-dandy buttons in the corner are actually a couple pixels away from the edge of the screen? Yeah, that fails Fitts' Law.
Just using the term OS GUI tells me what an amateur the author is, since the OS and its windowing environment are different concepts, and even though one may always be packaged with the other, they are still distinct ideas.
They are distinct ideas to the developer. They do not need to be distinct ideas to the end user; that's kind of the point of having an "interface".
Why are preferences bad? The author makes fun of them without actually making an argument.
Not all preferences are inherently bad, just most that you'll see in the wild. Preferences tend to be used when the developer doesn't know how to design the right interface, and instead leaves it up to the end user to figure it all out; one need look no further than the classic Mozilla suite for a prime example of this.
What about kde? gnome? OS X? how about some examples? or do we just get to hear a bunch of rants?
To be fair, he did knock on the Mac OS a bit, and most of his points aren't Windows-specific. If you want to see the broader view of usability, I'd recommend reading folks like Bruce Tognazzini, who happily tells everybody what they're doing wrong.
apparently, choice is bad, and users should be forcd to one pre-determined mode of operation? is this a joke? yes, i agree that it can be confusing to beginners to have too many ways of accomplishing the same task, but this has to do with throwing too much information at them, not having many choices.
In some contexts, yes, choice is bad; the best interface is one which doesn't require configuration before I can use it. This is also known as the principle of providing sane defaults: if I have to walk through a setup wizard before I can get any work done, something's fundamentally wrong. As for "one way to accomplish a given task", that should be what's built in; instead of listing the names of all the programs which can perform some action, the interface should always go with a default choice, and make it easy for the user to specify what the default will be. For example, a Linux desktop could have a "Web browser" button which defaults to Firefox -- a good choice because of its ease of use and compatibility with existing web sites -- and allow the user easily to select a different default. This is, by the way, an example of a good preference.
so spatial navigation is apparently great, but there was not one mention of nautilus, or how well its spatial navigation was accepted.
The only people I've seen complain about spatial Nautilus are geeks. Maybe that says more about who's using GNOME than anything else, but personally I like spatial Nautilus. Spatial mode makes Nautilus a file manager rather than a file browser, and that's exactly what I need it to do.
But in actuality, you can simply click on the image, select either the ROTATE option, or click on the button with a rotating arrow, then SAVE the image, and then email it. A fairly complex operation that can be done by beginners.
Actually, it's more like this:
Open the file browser and navigate to the image's location in the filesystem.
Double-click to open the image.
Locate the "Rotate" command in the image-manipulation program (hint: those little button icons aren't as
That's funny....I was under the impression that preferences were exactly the answer to this issue.
And that's where you'd fail it. Traditionally, developers solve this problem by just offering an "Advanced" interface that can be turned on with a checkbox, and most geeks think that's fine and dandy because it's what they're used to. There's even a common simile for this: it's like learning to ride a bike, and one day you just take off the training wheels and go.
The problem is that the simile doesn't hold; when you turn on the "Advanced" option you're suddenly presented with an interface that was so hard for people to learn that the developers had to invent a dumbed-down version. To go back to the bike simile, it's as if you take off the training wheels and suddenly you have a unicycle; instead of the same interface with less hand-holding, you've got something entirely new, and much more difficult, to learn. And meanwhile the root problem hasn't been addressed: the original interface created by the developer was too hard for people to learn and work with.
Moral of the story: no amount of preferences and settings can make a bad interface good.
plans are afoot for Microsoft to co-opt RSS and rename it "web feeds"[from El Reg, so take it with a pinch of snuff]
It is a better name, but Microsoft sure didn't come up with it; people in usability have been recommending the "feed" name for quite some time now in order to make feeds more accessible to the general public. The reasoning, of course, is the same as in calling your browser a "web browser" and not an "HTML/XHTML viewer".
Moreover, unless I'm mistaken, If-Modified-Since still causes the whole feed to be transfered, not just the parts that have changed since the time indicated in that header.
What you're unhappy with here is not HTTP or feed formats. You're unhappy with how content-management software commonly handles feeds. It would be trivial for a CMS to either look at the If-Modified-Since header or accept an extra URL parameter for "only items since this timestamp" (e.g., 'example.com/feed/?since=2005-08-16T07:47:19Z') and treat it as a request to only return items newer than the timestamp.
Also, you seem to have a very narrow view of the uses of feeds; "new item at example.com, click this link to read it" is, while a popular use, only one of many uses. For example, the Atom syndication format closely interoperates with the Atom API; Atom feeds contain complete representations of content objects and can be used for a variety of purposes including data import/export for any amount of content up to and including an entire site. So mandating "only send what's changed since time t" would be disastrous.
And perhaps this is a pointless argument to have, but I actually see it as cost/benefit analysis rather the the old "worse is better" debate. Even if pull technology were widely implemented outside of email, the bandwidth cost of a conditional HTTP GET, even the bandwidth cost of millions of conditional HTTP GETs, would not equal the infrastructure cost of implementing a push system for notifications of site updates. So the proposed benefit of implementing that push system would not outweigh its costs, and so it should not be implemented.
"Only send when something has changed" is available and widely implemented right now; it's called the "If-Modified-Since" header. More on why push won't work in a moment.
XML is verbose by design, much as s-expressions are not. And again, with gzip encoding or other compression applied, this is not a problem; feeds compress nicely (and in case you're worried about the performance hit to the server having to gzip the feed, keep in mind you can cache that fairly easily).
I'd rather deal with the bandwidth cost of conditional GET than the headache that would be implementing push. Plus it's really not that much.
IP certainly doesn't care if it's the receiver initiating the dialog (pull), or the sender (push).
No, but if you've got a foolproof way to do push to clients who aren't always-on, or to clients who are behind a variety of NAT and NAT-like configurations, I'd love to see it.
You got your facts wrong. When feed readers use conditional GET and respect HTTP Last-Modified headers, and when feed publishers use gzip encoding (XML, like most plain text formats, compresses wonderfully), the bandwidth requirement for aggregation is minimal; the technologies themselves, then, are not inefficient; the inefficiency is in how they are being used. And the alternative you hint at, push, is nowhere near being "more efficient" since it would require an overhaul of IP, universally adopted, to implement reliably.
What I'm saying is that what CNet did gave Google, the company, no reason not to talk to CNet. And I'm appalled, as a shareholder that the CEO would take a personal animosity like this and use our company to fight about it. If the CEO wants to cut off his nose to spite his face, that's his perogative, but cutting off my nose to spite his face isn't.
You're a publicly-traded company. A news outlet bypasses the conventions of journalistic ethics to run a hatchet job against your company without contacting you for comment in any way. And no matter what you do, the news outlet in question is going to continue running attack pieces against you; if you comment they'll use it against you. If you don't comment they'll use it against you. So why should you legitimize their tactics by giving them your time and attention?
In other words, despite how much fun it is to theorize that Eric Schmidt is fulfilling some sort of personal vendetta, this can be explained much more easily by Google doing the only thing that makes sense in this situation.
And as a shareholder I'm appalled that Google would engage in such petty behavior just because Cnet offended the CEO.
Actually, CNet violated the canon of journalistic ethics. When you're going to run a negative story about a person or company, you always, always, always call the person or company and see what they have to say; this is known as "reporting the whole story". Often in a story like this all you'll end up with is a blurb that "calls to Google were not returned" or "officials at Google had no comment", but ethics demands you at least try to get a comment from them. CNet didn't, because journalistic ethics would have gotten in the way of their snarky story, and now Google's shutting them out as retaliation.
And note that in some countries, this is actually enshrined in law as the "right of reply", which, oddly enough, CNet hates.
Slashdot Mirror
Is that unless you are a web application developer, Ruby's basically got nothing to offer. Not only is Rails the killer app for Ruby, it's the only app. That makes me uneasy about picking up the language.
Also, you forgot Django in your mentions of Python web frameworks.
Well, to be honest, you picked the one task that, above all others, Perl is engineered from the ground up to be good at, and compared it to the same task in another language which doesn't place any special emphasis on that task. If you take a language that specializes intensely in a particular task (and I don't think anyone could claim Perl doesn't place a huge amount of focus on text processing with regexes), it's probably going to be better, for that particular task, than a language that doesn't specialize in that task. In much the same way, if you want to do clean object-oriented programming Python's got Perl beat hands-down; Python is OO to the core, and is now designed to be that way, while Perl's OO is still in the "bolted on" phase. So really, it all depends on the task.
The leak was in Rails 0.14.1, and it was patched in Rails 1.0RC3; a write-up and links to full details are here. Typo was, so far as I know, the only Rails app which ever managed to trigger it. And I'd say that's because, well, Typo's a bit of a beast. But then I don't particularly care for Rails for any sort of content-management; its application orientation means that for "CMS-style" tasks like blogging you have to bring in all sorts of components (like login generators and admin interfaces) which add overhead. If you're going to do content-management with a framework, use something like a href="http://www.djangoproject.com/">Django which is far better suited to that task (where Rails was extracted from a web application -- Basecamp -- Django was extracted from a newspaper site).
Reiterating a comment I made above, and expanding a little:
Sometimes there is a good design reason for not supporting multiple backends; for example, Textpattern, my personal favorite for blogging/lightweight CMS solutions, has long been MySQL-only, not because of laziness or ignorance, but because Postgres doesn't have fulltext indexing by default (requires either of two contrib modules which don't get built in a standard Postgres install), and Textpattern uses fulltext indexing. There's a development branch of Textpattern which has experimental Postgres support (even though the trunk is MySQL-only, Textpattern does use abstraction in its database interface) which may or may not make that available for the future Textpattern 4.1, but I haven't had a chance to play with it, so I don't know how they're working around that problem.
And while I tend to be fairly DB-agnostic, I can understand that deliberate targeting of MySQL is a good way to keep an application like Wordpress manageable; since MySQL is by far the most common DB available for its target market (shared hosting customers), this pleases the most people while keeping the need to worry about inconsistencies between DBs to a minimum.
Typo's a bit of a beast, though, in most shared hosting environments. And there was that nasty memory leak in Rails it exposed a while back...
While I don't know about Wordpress, I'm a fairly active Textpattern user and the reason for the lack of Postgres support in the past was always that Textpattern's search function relies on full-text indexing, something Postgres doesn't quite do natively (it requires either the fulltextindex or tsearch module, neither of which are built by default). There's now a development branch of Textpattern with Postgres support, though. I haven't looked at the code, but it may be that they're working around it somehow.
And one other thing, now that I think of it: if IE on Windows and Mac used the same core code, with the only differences being in, say, system calls to the OS, then the defense of "we can't unbundle it, it's a core part of the Windows operating system" would have had even less chance of holding up in court -- it's a core part of the OS, but you just changed a couple things and it runs fine on the Mac?
IE/Windows and IE/Mac are very different beasts under the hood. IE/Windows uses the same rendering engine (Trident) that it's had since version 5.0, which was a pretty serious rewrite. IE/Mac (and MSN for the Mac) use a completely different rendering engine (Tasman) which was written by a different team. And in its day, IE 5 for the Mac was actually the most standards-compliant browser available; its rendering engine was the first to boast full support for CSS Level 1 (helped in no small part by having Tantek Çelik -- who was Microsoft's representative in the W3C CSS Working Group -- on the development team). It's just that with the alleged end of the browser wars, a culture of stagnation took hold in Microsoft's browser development, and Mac IE was pretty much abandoned; no new standards support has been added to it, that I'm aware of, since version 5.0.
And as far as I know, Office for the Mac is (or, at least, used to be) much the same way; a completely different development team works on it, and it shares very little core code with the Windows version. This might seem wasteful, but a few blogs of current and former Microsoft employees have pointed out that there was always a separate "Mac unit" within MS, and offered a few justifications for it, most prominently the fact that the Windows and Mac environments are so different both for developers and for end users that this was seen as the best way to handle things.
With a lot of useful tips on how things work in the real world: Mobile Web Design: The Series.
The Turk site doesn't ask for my username and password; it shows me my information without my having to enter it> So your hypothetical phishing site also needs an XSS hole in every major browser which allows it to read the cookie Amazon uses to store session info.
To verify the legitimacy of the site, manually type "amazon.com" into your browser's location bar, and hover over the "See all 32 Product Categories" tab. When it pops up the list, click "Web Services" and read the first item listed on that page, which is a press release announcing Amazon Mechanical Turk.
For extra points, do this only a machine which has been booted from a liveCD with DNS utilities and hosts file that you have personally audited.
Or just, you know, look at the fact that the Turk will, by default, display the name and address you've given to Amazon as your contact info, and conclude that yeah, it's an Amazon property.
I clicked through to try one of the tasks, and was asked to confirm my full name and mailing address, which were displayed correctly and match exactly the contact information I've provided to Amazon in the past. So either A) someone has cracked Amazon's custoimer database and found a way to hijack the amazon.com domain cookie in every existing browser, or B) it's legit. Which one do you think is more likely?
It goes up and does... what, exactly? The crew talk to some elementary-school kids while all the experiments run automatically. Which is also about all the ISS does. So what's the point of this thing?
You mean it works out as a pricey jack of one or two trades which occasionally explodes and kills everyone on board.
The ISS doesn't really serve any useful purpose at this point. It exists as a place for the Space Shuttle to go to, and the Space Shuttle exists as a vehicle that gets us to the ISS. Check out this article for more indo.
Let me help you by writing this up in a way you'll find useful:
Consider these inconvenient facts:
Even if we decide to be generous and say that Microsoft's IE team couldn't take advantage of the working drafts of XHTML 1.0, that means that they had around twenty months in which to implement something that didn't involve any new tags or attributes, and on which they'd had been providing input and receiving constant updates for nearly three years previously. Would it really have been that hard?
Ever notice how some of those handy-dandy buttons in the corner are actually a couple pixels away from the edge of the screen? Yeah, that fails Fitts' Law.
They are distinct ideas to the developer. They do not need to be distinct ideas to the end user; that's kind of the point of having an "interface".
Not all preferences are inherently bad, just most that you'll see in the wild. Preferences tend to be used when the developer doesn't know how to design the right interface, and instead leaves it up to the end user to figure it all out; one need look no further than the classic Mozilla suite for a prime example of this.
To be fair, he did knock on the Mac OS a bit, and most of his points aren't Windows-specific. If you want to see the broader view of usability, I'd recommend reading folks like Bruce Tognazzini, who happily tells everybody what they're doing wrong.
In some contexts, yes, choice is bad; the best interface is one which doesn't require configuration before I can use it. This is also known as the principle of providing sane defaults: if I have to walk through a setup wizard before I can get any work done, something's fundamentally wrong. As for "one way to accomplish a given task", that should be what's built in; instead of listing the names of all the programs which can perform some action, the interface should always go with a default choice, and make it easy for the user to specify what the default will be. For example, a Linux desktop could have a "Web browser" button which defaults to Firefox -- a good choice because of its ease of use and compatibility with existing web sites -- and allow the user easily to select a different default. This is, by the way, an example of a good preference.
The only people I've seen complain about spatial Nautilus are geeks. Maybe that says more about who's using GNOME than anything else, but personally I like spatial Nautilus. Spatial mode makes Nautilus a file manager rather than a file browser, and that's exactly what I need it to do.
Actually, it's more like this:
And that's where you'd fail it. Traditionally, developers solve this problem by just offering an "Advanced" interface that can be turned on with a checkbox, and most geeks think that's fine and dandy because it's what they're used to. There's even a common simile for this: it's like learning to ride a bike, and one day you just take off the training wheels and go.
The problem is that the simile doesn't hold; when you turn on the "Advanced" option you're suddenly presented with an interface that was so hard for people to learn that the developers had to invent a dumbed-down version. To go back to the bike simile, it's as if you take off the training wheels and suddenly you have a unicycle; instead of the same interface with less hand-holding, you've got something entirely new, and much more difficult, to learn. And meanwhile the root problem hasn't been addressed: the original interface created by the developer was too hard for people to learn and work with.
Moral of the story: no amount of preferences and settings can make a bad interface good.
It is a better name, but Microsoft sure didn't come up with it; people in usability have been recommending the "feed" name for quite some time now in order to make feeds more accessible to the general public. The reasoning, of course, is the same as in calling your browser a "web browser" and not an "HTML/XHTML viewer".
What you're unhappy with here is not HTTP or feed formats. You're unhappy with how content-management software commonly handles feeds. It would be trivial for a CMS to either look at the If-Modified-Since header or accept an extra URL parameter for "only items since this timestamp" (e.g., 'example.com/feed/?since=2005-08-16T07:47:19Z') and treat it as a request to only return items newer than the timestamp.
Also, you seem to have a very narrow view of the uses of feeds; "new item at example.com, click this link to read it" is, while a popular use, only one of many uses. For example, the Atom syndication format closely interoperates with the Atom API; Atom feeds contain complete representations of content objects and can be used for a variety of purposes including data import/export for any amount of content up to and including an entire site. So mandating "only send what's changed since time t" would be disastrous.
And perhaps this is a pointless argument to have, but I actually see it as cost/benefit analysis rather the the old "worse is better" debate. Even if pull technology were widely implemented outside of email, the bandwidth cost of a conditional HTTP GET, even the bandwidth cost of millions of conditional HTTP GETs, would not equal the infrastructure cost of implementing a push system for notifications of site updates. So the proposed benefit of implementing that push system would not outweigh its costs, and so it should not be implemented.
No, but if you've got a foolproof way to do push to clients who aren't always-on, or to clients who are behind a variety of NAT and NAT-like configurations, I'd love to see it.
Time to ditch the World Wide Web, right?.
You got your facts wrong. When feed readers use conditional GET and respect HTTP Last-Modified headers, and when feed publishers use gzip encoding (XML, like most plain text formats, compresses wonderfully), the bandwidth requirement for aggregation is minimal; the technologies themselves, then, are not inefficient; the inefficiency is in how they are being used. And the alternative you hint at, push, is nowhere near being "more efficient" since it would require an overhaul of IP, universally adopted, to implement reliably.
You're a publicly-traded company. A news outlet bypasses the conventions of journalistic ethics to run a hatchet job against your company without contacting you for comment in any way. And no matter what you do, the news outlet in question is going to continue running attack pieces against you; if you comment they'll use it against you. If you don't comment they'll use it against you. So why should you legitimize their tactics by giving them your time and attention?
In other words, despite how much fun it is to theorize that Eric Schmidt is fulfilling some sort of personal vendetta, this can be explained much more easily by Google doing the only thing that makes sense in this situation.
Actually, CNet violated the canon of journalistic ethics. When you're going to run a negative story about a person or company, you always, always, always call the person or company and see what they have to say; this is known as "reporting the whole story". Often in a story like this all you'll end up with is a blurb that "calls to Google were not returned" or "officials at Google had no comment", but ethics demands you at least try to get a comment from them. CNet didn't, because journalistic ethics would have gotten in the way of their snarky story, and now Google's shutting them out as retaliation.
And note that in some countries, this is actually enshrined in law as the "right of reply", which, oddly enough, CNet hates.