Therefore, you have no way of submitting the hash problem TO the sender,
I could be wrong on this but having looked at the hash cash site I think that no communication from receiver to sender is necessary. The problem is based on the message body and the recipient name. The sender knows these at the beginning.
The costs to ISPs in the short term will be no worse than at present. In the long term costs to ISPs will fall as spam traffic declines.
You are right that adoption is a problem but that is no reason not to start now. Of the 10% of messages I get that are not spam, almost all are from relatively knowledgeable people who can upgrade to the latest version of Pine or whatever to get hash postage. For other users, it just needs AOL or Microsoft to put out a new release, which as likely as not will be an automatic update. Attaching postage to your message increases CPU load, but only for a few seconds per message sent, and even that can happen in the background.
The advantage over the status quo is that legitimateness of a message can be checked *automatically*. That is the point, you don't have to have your time wasted by checking and deleting spam, this job can be done by the computer. Children do not have to look at pornographic messages, etc etc. Saving time for humans, not computers, is the most important thing. Though like I said, in the long term making spam uneconomical will reduce the load on ISPs as well.
And unlike Bayesian filtering there is no way around it, the message has to cost a few seconds of CPU time or else the postage will not be valid. (Assuming the hash function is cryptographically secure in the sense there is no easy way to get either partial or total collisions with a given hash value.)
I wasn't thinking of the cost to the SMTP server but of the human cost of spam - wasted time in deleting it and the fact that people are turned off email altogether because of it. This, IMHO, is a much more serious problem than wasted bandwidth.
Also, note that if payment for messages (whether real cash or hash cash) becomes widely adopted, spam will stop because there won't be any money in it any longer. So the problem of costs to the ISP is also dealt with.
Of course it is possible for ISPs to configure their mail servers to check hash postage on each message and drop them if it's not valid. This would save the storage costs of spam. And if a particular other host always sends messages with bad postage you could stop accepting connections from that host. But all this is optional: I feel a postage system has the best chance of getting started if it is adopted from the bottom up by mail user agents rather than ISPs' mail servers. Both is better though.
I don't think that hash cash works by having a problem sent from the recipient to the sender which the sender must then generate the answer to. Rather, you have a one-way function where it is hard to generate the answer but easy to check that the answer is correct. The 'problem' includes the recipient's email address and the message content - so you cannot reuse the same postage for two messages.
The recipient just has to look at the message body, the To: header and the postage, and verify that the postage is a correct answer (which can be done quickly).
Like I said, that 'spam zapping headquarters' AOL runs costs money. Corporations tend to avoid things that cost them money. If AOL knew that adding antispam measures to their mail client would (in the long run) let them avoid the expense of filtering spam manually, they would add this feature very quickly (no matter how incompetent they may be in other areas that don't have a direct financial impact).
On the contrary, it will not be possible for a spammer to use a proxy or other system to add hashcash postage to large numbers of messages, simply because the amount of postage is chosen to limit the number of messages that can be processed in one second.
For example suppose the standard postage amount is a problem which typically requires five seconds of CPU time on modern systems. Then no proxy even if it were taken over by crackers could send out more than one spam every five seconds. This is a greatly reduced rate of spam and probably low enough to make spamming not worth the effort.
Your solution is simple, but it requires changes to the Internet's mail infrastructure. SMTP would have to be replaced.
Enforcing postage on the client side is much easier to roll out: people can gradually switch to hashcash-enabled mail readers and only a few years down the line start dropping mail without postage (or putting it into a special low-priority mailbox, or sending an automatic reply asking for manual confirmation, etc).
The real problem with spam is the economics: it costs next to nothing to send a message, the only real cost (time) is borne by the recipient. Fix that problem and spam will go away. It doesn't need legislation, which in any case could apply in just one jurisdiction.
A system like Hash Cash could solve the problem. The most popular free mail clients could start including hash-cash postage with each sent message, and then in a couple of years' time start to drop incoming messages that don't have postage paid. AOL could include hash cash in their mail client easily. *Easily*. That spam-detection centre they run is not cheap. Even Microsoft would add hash cash to Outlook, Outlook Express and Hotmail, since it's another encouragement to upgrade to a new Outlook release (which of course requires a new Windows version).
Getting the whole world to upgrade its mail clients is a hard task, but getting every government in the world to pass anti-spam laws and enforce them is much harder. Goodness knows it's bad enough trying to get _one_ legislature to take a sane view on anything technology-related.
If we think realistically about most of the world's commercial software not as "software" in the abstract but as x86 binary code, then it becomes apparent that improvements to the x86 ISA represent one of the most practical and cost-effective ways to advance and expand the x86 software market.
If you think of existing software as 386 binary code, then obviously it's not going to benefit from any improvements to the x86 architecture. Moving to Athlon 64 will not magically make Windows 95 run faster any more than a move to Itanium would. It'll give a performance improvement only if 'compatibility mode' is faster than existing 32-bit CPUs.
A large base of installed software is an argument for keeping compatibility with the x86 instruction set, but not an argument per se for moving to some new instruction set which is a bit like x86 but not quite.
Anyway, existing software will be 'old software' very soon and so it won't matter that much how fast it runs, any new CPU will be fast enough. (Do I care whether WordStar runs a hundred times faster than it did on a PC-AT or a thousand times faster?) Any app for which performance really matters will be recompiled for the new processor anyway.
Hmm... DSP hardware gets cheaper all the time. If GNU Radio can tune radio stations in software on a general-purpose PC, surely a few dollars' worth of DSP hardware in a Walkman could do a similar job. You need a fair amount of computing power to decode MP3s/Oggs/digital radio broadcasts anyway.
If you're saying 'it's insane, you'd need a vector supercomputer to do this job in real time' then I agree it's not a practical solution. If you are just saying 'you'll need at least a 2GHz CPU' then the hardware costs should be no difficulty at all in a few years' time.
But many distros do come with an install program that recognizes and downloads dependencies. For example apt (Debian and Conectiva) or urpmi (Mandrake). It just needs these to be more smoothly integrated with third-party software.
Already some developers are saying 'add these two lines to your apt.sources and then you will be able to install my package with all dependencies automatically'. That is a smooth, automated install process, it just isn't graphical enough. If there is a one-click way to add a new apt package repository, perhaps containing one or two packages for some program you're interested in, that would solve the problem.
- Two transmitters in two different places, but with an overlapping range, both broadcast on the same frequency.
- A receiver is halfway between the two transmitters and so within range of both.
- The receiver has two or more antennae, each antenna has some directionality. You do a lot of DSPing in software to distinguish the two signals even though they are both on the same frequency.
But in many Linux distributions, can't you just double-click an RPM or dpkg file, press 'OK' and off it goes?
'Every time I download something that's not part of Debian' - this is the problem. It needs to be made much easier for developers to provide Debian packages (or RPMs, etc) of their software. Ideally there should be some way to make Debian packages without needing Debian installed.
It would be great to have a self extracting executable with the dependancy.so or other programs already in it. It should be the job of the os or package installer and not the user to take care of this.
I partly agree - but would add, it should be the job of the OS or package manager, not the user *and not the application being packaged* to take care of this. That means that there should _not_ be extra.so files for dependencies in the package. That way lies Windows-style DLL hell where every app includes slightly different versions of libraries and they get scattered across different places. The app should just say 'I require libfoo version 2.3' and the package manager will make sure that 2.3 or a later 2.x release is installed. This is what packaging systems like rpm and dpkg provide; unfortunately if you run them directly from the command line they will only tell you what needs to be done, not do it themselves. Tools like apt or Mandrake's urpmi will take care of downloading and installing the necessary dependencies as well.
About your problem with downgrading to perl 5.6: what's really needed, I think, is a package manager which downloads dependencies and rebuilds from source if necessary. So when you say to rpm 'please replace perl 5.8 with 5.6', it should look at all the packages which currently depend on 5.8, get their source packages, recompile for 5.6 and then in one fell swoop replace perl 5.8 and all packages that use it with the older version. If there is some application which requires perl 5.8 or later, you would obviously have to uninstall that before downgrading to the earlier perl version.
I don't understand why many people seem to assume 'tar good, rpm/dpkg bad'. For example, the article says:
Although some Linux flavors such as Red Hat and Debian come with their own package management utilities (rpm and apt-get, respectively) that are as efficient as Stow, they work only on specific packaging formats (.rpm and.deb, respectively). When it comes to managing applications simply packaged in.tar files, Stow is the best bet.
Why is a tar file any more 'simple' than an RPM or Debian package? If you are just storing a bunch of files, then yes. But what about metadata? That is, the information on dependencies (what libraries the package needs), where to get the source code, who the packager was, which version of the software these files represent, whether this packge conflicts with any other packages that might be installed, and all the other things that a decent package manager keeps track of automatically so you don't have to check them by hand, or get nasty surprises when you've installed a package and only later find a necessary library is the wrong version.
If you use tar files then you'd need to have an extra metadata file inside storing this information: then you need to decide a format for that file and write a tool to parse it. And you've then reinvented rpm or dpkg, only with the spurious 'improvement' that people on other systems can unpack the archive if they have tar installed. As if anyone running a different system would need to unpack someone else's binary packages.
Perhaps you could argue it would have been better for rpm to be based around tar.gz format, with the package details stored in the tarball as a script of some kind. But then it would become much slower to query a large directory of packages. Maybe that is important, maybe not. Also you have digital signatures to worry about, it's not clear how to do those with a tar archive (unless you have one tarball containing another tarball plus its PGP signature). Perhaps things could have been done differently, but the mere fact that the rpm and dpkg developers chose to make their own format rather than use tar is not an excuse for committing much more serious wheel-reinvention in making a kewl Yet Another packaging format.
I'm not meaning to knock Gentoo here, that distribution really does do something new (building everything from source), and they perhaps had good reason to make a new packaging format. (Although it might have been worthwhile to investigate whether building from source could fit in with rpm or Debian source packages.) And Slackware has used tgz packages since the beginning, and doesn't seem that bothered about automatically tracking dependencies.
But for most uses, I just don't see why 'simple packaging with tar' is particularly simple in the long run or much of an advantage. It sounds like those Freshmeat projects which say 'this is yet another MP3 player but it has the advantage that it doesn't use GTK or Qt but implements its own user interface code instead'.
Remember back when Corel decided Java was the future, and said it would be rewriting its office suite in Java?
Then a few years later it was Linux. Asked by an interviewer whether the Linux thing was just a passing obsession for Corel like Java had been, a spokesman asserted that no, this was different, Corel was really committed to Linux.
Then they got almost-bought by Microsoft, dumped Linux and started going on about.NET, again threatening to port the by now rather cobwebby Corel Office to the new platform.
Now that too has gone and XML is the big thing? Whatever next?
The logical next step is for McD's to provide computers as well. Something like a McTablet PC, with a touch-sensitive screen and a completely smooth surface to make it easy to clean. At the end of your meal you hand it back and they put it through the wash.
I think that typeglobs have been removed in perl6. So that * does not signify a glob. It signifies taking all the arguments into a single list, I think, so you can call print(1, 2, 3) and @list will have three elements. A similar syntax with * is used in Python and probably other languages.
I don't see similar comments saying how it's incredibly confusing that '(' and ')' mean different things in different places, or comma, or backslash. The same character in two different contexts can mean different things. If you had to invent a new character for every possible language construct you'd soon run out of keyboard space.
Sorry, I thought (from reading online news sources) that SCO's complaint was a mixture of trade secrets, patents, and whatever other stuff they could think of. Looks like this is not the case.
Hmm, good question. Maybe they are infringing copyright (in a way) by distributing GPLed code but then ignoring the GPL's stipulations about patent licences. But if they get sued over that, the case probably wouldn't be very clear-cut (is that part of the GPL enforceable?) and the damages might be a lot less than they're hoping to get out of IBM. IANAL and all that.
They don't have to convince judges that Linux is 'a derivative of' UNIX. At least not for patent infringement lawsuits. With patents, you are still infringing even if you independently come up with the same idea. This is one reason why patents suck when applied to software, where coming up with new ideas is not the difficult part so much as the implementation, even though patents may give a net economic benefit in other fields of endeavour.
The C++ string class also lets you interface with C strings with minimal effort. The c_str() method will return the string's content as a char * (though you must be careful if the string contains NUL characters, of course).
You ought to benchmark before claiming that C++'s ostrstream is slower than glib or other ways of writing formatted output. I haven't, but I know that Stroustrup's book is full of all sorts of chest-beating about how C++'s language features and its standard library, particularly streams, are efficient and comparable to their C equivalents. So I'd imagine that formatted output with ostrstream is pretty respectable.
In any case, a possible increase in speed for formatting some data into a string is not a good enough reason to stop using the standard 'string' type and reinvent the wheel with glib.
In the case of KDE it is different because they already have their own not-invented-here-ism (inherited from Qt) using QString instead of the standard std::string. Nonetheless two different string classes are not as bad as three.
But C++ is superior to C-with-GObject. If it really were possible to get C++'s features (template containers, defining new concrete types such as 'string' and 'complex', language support for OO with inheritance and polymorphism) by adding extensions to C, there would have been no need to make a new language. Don't forget that the original C++ developers (Stroustrup and colleagues) were experienced C programmers.
The reason most often given for using C is as a least common denominator with bindings to lots of languages, but since so many of the languages commonly used (Perl, Python, Ruby, Java, Lisp, heck even Ada) have language support for OO, and many of those can be integrated directly with C++ code, this isn't 100% convincing.
Do the KDE people use Qt's container classes rather than the C++ standard library?
Maybe Qt itself should be split into separate libs for GUI, containers (which most C++ developers would avoid, using the STL instead), database access and all the other kitchen sink stuff Troll Tech likes to put in there.
Slashdot Mirror
I could be wrong on this but having looked at the hash cash site I think that no communication from receiver to sender is necessary. The problem is based on the message body and the recipient name. The sender knows these at the beginning.
The costs to ISPs in the short term will be no worse than at present. In the long term costs to ISPs will fall as spam traffic declines.
You are right that adoption is a problem but that is no reason not to start now. Of the 10% of messages I get that are not spam, almost all are from relatively knowledgeable people who can upgrade to the latest version of Pine or whatever to get hash postage. For other users, it just needs AOL or Microsoft to put out a new release, which as likely as not will be an automatic update. Attaching postage to your message increases CPU load, but only for a few seconds per message sent, and even that can happen in the background.
The advantage over the status quo is that legitimateness of a message can be checked *automatically*. That is the point, you don't have to have your time wasted by checking and deleting spam, this job can be done by the computer. Children do not have to look at pornographic messages, etc etc. Saving time for humans, not computers, is the most important thing. Though like I said, in the long term making spam uneconomical will reduce the load on ISPs as well.
And unlike Bayesian filtering there is no way around it, the message has to cost a few seconds of CPU time or else the postage will not be valid. (Assuming the hash function is cryptographically secure in the sense there is no easy way to get either partial or total collisions with a given hash value.)
I wasn't thinking of the cost to the SMTP server but of the human cost of spam - wasted time in deleting it and the fact that people are turned off email altogether because of it. This, IMHO, is a much more serious problem than wasted bandwidth.
Also, note that if payment for messages (whether real cash or hash cash) becomes widely adopted, spam will stop because there won't be any money in it any longer. So the problem of costs to the ISP is also dealt with.
Of course it is possible for ISPs to configure their mail servers to check hash postage on each message and drop them if it's not valid. This would save the storage costs of spam. And if a particular other host always sends messages with bad postage you could stop accepting connections from that host. But all this is optional: I feel a postage system has the best chance of getting started if it is adopted from the bottom up by mail user agents rather than ISPs' mail servers. Both is better though.
I don't think that hash cash works by having a problem sent from the recipient to the sender which the sender must then generate the answer to. Rather, you have a one-way function where it is hard to generate the answer but easy to check that the answer is correct. The 'problem' includes the recipient's email address and the message content - so you cannot reuse the same postage for two messages.
The recipient just has to look at the message body, the To: header and the postage, and verify that the postage is a correct answer (which can be done quickly).
Like I said, that 'spam zapping headquarters' AOL runs costs money. Corporations tend to avoid things that cost them money. If AOL knew that adding antispam measures to their mail client would (in the long run) let them avoid the expense of filtering spam manually, they would add this feature very quickly (no matter how incompetent they may be in other areas that don't have a direct financial impact).
On the contrary, it will not be possible for a spammer to use a proxy or other system to add hashcash postage to large numbers of messages, simply because the amount of postage is chosen to limit the number of messages that can be processed in one second.
For example suppose the standard postage amount is a problem which typically requires five seconds of CPU time on modern systems. Then no proxy even if it were taken over by crackers could send out more than one spam every five seconds. This is a greatly reduced rate of spam and probably low enough to make spamming not worth the effort.
Your solution is simple, but it requires changes to the Internet's mail infrastructure. SMTP would have to be replaced.
Enforcing postage on the client side is much easier to roll out: people can gradually switch to hashcash-enabled mail readers and only a few years down the line start dropping mail without postage (or putting it into a special low-priority mailbox, or sending an automatic reply asking for manual confirmation, etc).
'Using email intelligently' consists of having multiple email addresses and trying to keep them secret? WTF?
The real problem with spam is the economics: it costs next to nothing to send a message, the only real cost (time) is borne by the recipient. Fix that problem and spam will go away. It doesn't need legislation, which in any case could apply in just one jurisdiction.
A system like Hash Cash could solve the problem. The most popular free mail clients could start including hash-cash postage with each sent message, and then in a couple of years' time start to drop incoming messages that don't have postage paid. AOL could include hash cash in their mail client easily. *Easily*. That spam-detection centre they run is not cheap. Even Microsoft would add hash cash to Outlook, Outlook Express and Hotmail, since it's another encouragement to upgrade to a new Outlook release (which of course requires a new Windows version).
Getting the whole world to upgrade its mail clients is a hard task, but getting every government in the world to pass anti-spam laws and enforce them is much harder. Goodness knows it's bad enough trying to get _one_ legislature to take a sane view on anything technology-related.
If you think of existing software as 386 binary code, then obviously it's not going to benefit from any improvements to the x86 architecture. Moving to Athlon 64 will not magically make Windows 95 run faster any more than a move to Itanium would. It'll give a performance improvement only if 'compatibility mode' is faster than existing 32-bit CPUs.
A large base of installed software is an argument for keeping compatibility with the x86 instruction set, but not an argument per se for moving to some new instruction set which is a bit like x86 but not quite.
Anyway, existing software will be 'old software' very soon and so it won't matter that much how fast it runs, any new CPU will be fast enough. (Do I care whether WordStar runs a hundred times faster than it did on a PC-AT or a thousand times faster?) Any app for which performance really matters will be recompiled for the new processor anyway.
Hmm... DSP hardware gets cheaper all the time. If GNU Radio can tune radio stations in software on a general-purpose PC, surely a few dollars' worth of DSP hardware in a Walkman could do a similar job. You need a fair amount of computing power to decode MP3s/Oggs/digital radio broadcasts anyway.
If you're saying 'it's insane, you'd need a vector supercomputer to do this job in real time' then I agree it's not a practical solution. If you are just saying 'you'll need at least a 2GHz CPU' then the hardware costs should be no difficulty at all in a few years' time.
But many distros do come with an install program that recognizes and downloads dependencies. For example apt (Debian and Conectiva) or urpmi (Mandrake). It just needs these to be more smoothly integrated with third-party software.
Already some developers are saying 'add these two lines to your apt.sources and then you will be able to install my package with all dependencies automatically'. That is a smooth, automated install process, it just isn't graphical enough. If there is a one-click way to add a new apt package repository, perhaps containing one or two packages for some program you're interested in, that would solve the problem.
I dunno, what about:
- Two transmitters in two different places, but with an overlapping range, both broadcast on the same frequency.
- A receiver is halfway between the two transmitters and so within range of both.
- The receiver has two or more antennae, each antenna has some directionality. You do a lot of DSPing in software to distinguish the two signals even though they are both on the same frequency.
But in many Linux distributions, can't you just double-click an RPM or dpkg file, press 'OK' and off it goes?
'Every time I download something that's not part of Debian' - this is the problem. It needs to be made much easier for developers to provide Debian packages (or RPMs, etc) of their software. Ideally there should be some way to make Debian packages without needing Debian installed.
About your problem with downgrading to perl 5.6: what's really needed, I think, is a package manager which downloads dependencies and rebuilds from source if necessary. So when you say to rpm 'please replace perl 5.8 with 5.6', it should look at all the packages which currently depend on 5.8, get their source packages, recompile for 5.6 and then in one fell swoop replace perl 5.8 and all packages that use it with the older version. If there is some application which requires perl 5.8 or later, you would obviously have to uninstall that before downgrading to the earlier perl version.
Why is a tar file any more 'simple' than an RPM or Debian package? If you are just storing a bunch of files, then yes. But what about metadata? That is, the information on dependencies (what libraries the package needs), where to get the source code, who the packager was, which version of the software these files represent, whether this packge conflicts with any other packages that might be installed, and all the other things that a decent package manager keeps track of automatically so you don't have to check them by hand, or get nasty surprises when you've installed a package and only later find a necessary library is the wrong version.
If you use tar files then you'd need to have an extra metadata file inside storing this information: then you need to decide a format for that file and write a tool to parse it. And you've then reinvented rpm or dpkg, only with the spurious 'improvement' that people on other systems can unpack the archive if they have tar installed. As if anyone running a different system would need to unpack someone else's binary packages.
Perhaps you could argue it would have been better for rpm to be based around tar.gz format, with the package details stored in the tarball as a script of some kind. But then it would become much slower to query a large directory of packages. Maybe that is important, maybe not. Also you have digital signatures to worry about, it's not clear how to do those with a tar archive (unless you have one tarball containing another tarball plus its PGP signature). Perhaps things could have been done differently, but the mere fact that the rpm and dpkg developers chose to make their own format rather than use tar is not an excuse for committing much more serious wheel-reinvention in making a kewl Yet Another packaging format.
I'm not meaning to knock Gentoo here, that distribution really does do something new (building everything from source), and they perhaps had good reason to make a new packaging format. (Although it might have been worthwhile to investigate whether building from source could fit in with rpm or Debian source packages.) And Slackware has used tgz packages since the beginning, and doesn't seem that bothered about automatically tracking dependencies.
But for most uses, I just don't see why 'simple packaging with tar' is particularly simple in the long run or much of an advantage. It sounds like those Freshmeat projects which say 'this is yet another MP3 player but it has the advantage that it doesn't use GTK or Qt but implements its own user interface code instead'.
Remember back when Corel decided Java was the future, and said it would be rewriting its office suite in Java?
.NET, again threatening to port the by now rather cobwebby Corel Office to the new platform.
Then a few years later it was Linux. Asked by an interviewer whether the Linux thing was just a passing obsession for Corel like Java had been, a spokesman asserted that no, this was different, Corel was really committed to Linux.
Then they got almost-bought by Microsoft, dumped Linux and started going on about
Now that too has gone and XML is the big thing? Whatever next?
The logical next step is for McD's to provide computers as well. Something like a McTablet PC, with a touch-sensitive screen and a completely smooth surface to make it easy to clean. At the end of your meal you hand it back and they put it through the wash.
I think that typeglobs have been removed in perl6. So that * does not signify a glob. It signifies taking all the arguments into a single list, I think, so you can call print(1, 2, 3) and @list will have three elements. A similar syntax with * is used in Python and probably other languages.
I don't see similar comments saying how it's incredibly confusing that '(' and ')' mean different things in different places, or comma, or backslash. The same character in two different contexts can mean different things. If you had to invent a new character for every possible language construct you'd soon run out of keyboard space.
You can?
Why didn't anyone say so before? I've never seen this in Perl code until now.
Sorry, I thought (from reading online news sources) that SCO's complaint was a mixture of trade secrets, patents, and whatever other stuff they could think of. Looks like this is not the case.
Hmm, good question. Maybe they are infringing copyright (in a way) by distributing GPLed code but then ignoring the GPL's stipulations about patent licences. But if they get sued over that, the case probably wouldn't be very clear-cut (is that part of the GPL enforceable?) and the damages might be a lot less than they're hoping to get out of IBM. IANAL and all that.
They don't have to convince judges that Linux is 'a derivative of' UNIX. At least not for patent infringement lawsuits. With patents, you are still infringing even if you independently come up with the same idea. This is one reason why patents suck when applied to software, where coming up with new ideas is not the difficult part so much as the implementation, even though patents may give a net economic benefit in other fields of endeavour.
The C++ string class also lets you interface with C strings with minimal effort. The c_str() method will return the string's content as a char * (though you must be careful if the string contains NUL characters, of course).
You ought to benchmark before claiming that C++'s ostrstream is slower than glib or other ways of writing formatted output. I haven't, but I know that Stroustrup's book is full of all sorts of chest-beating about how C++'s language features and its standard library, particularly streams, are efficient and comparable to their C equivalents. So I'd imagine that formatted output with ostrstream is pretty respectable.
In any case, a possible increase in speed for formatting some data into a string is not a good enough reason to stop using the standard 'string' type and reinvent the wheel with glib.
In the case of KDE it is different because they already have their own not-invented-here-ism (inherited from Qt) using QString instead of the standard std::string. Nonetheless two different string classes are not as bad as three.
What do glib's strings provide that the C++ standard library 'string' class doesn't?
But C++ is superior to C-with-GObject. If it really were possible to get C++'s features (template containers, defining new concrete types such as 'string' and 'complex', language support for OO with inheritance and polymorphism) by adding extensions to C, there would have been no need to make a new language. Don't forget that the original C++ developers (Stroustrup and colleagues) were experienced C programmers.
The reason most often given for using C is as a least common denominator with bindings to lots of languages, but since so many of the languages commonly used (Perl, Python, Ruby, Java, Lisp, heck even Ada) have language support for OO, and many of those can be integrated directly with C++ code, this isn't 100% convincing.
Do the KDE people use Qt's container classes rather than the C++ standard library?
Maybe Qt itself should be split into separate libs for GUI, containers (which most C++ developers would avoid, using the STL instead), database access and all the other kitchen sink stuff Troll Tech likes to put in there.