Jabber domains are not like email domains. s2s connections are verified with a reciprocal DNS lookup and (in the newer revisions of the protocol) can be authenticated. If your server only accepts connections from servers authenticated with a valid certificate, spammers will spend time and money obtaining certificates for their domains which can then be banned in a few seconds. Even valid domain names cost actual money, as opposed to email messages with fake sender address.
Ah yes, I figured out what was wrong the first time: the "hl" language setting has to be English. It's kind of odd as it was thought of as the display language (there is an explicit search language setting), but now it affects results as well. Not nice.
It's basically the same, with more syntactic sugar, more slack on execution safety and hence more shoot-yourself-in-the foot factor. And the class library is a bit less coherent. In short, it's an improvement on Java, sort of, for smaller scale projects and/or programmers.
#1 All applications store their configuration data together in one place
Wrong. GConf storage can be decentralized, and the default storage backend lays out configuration values into a corresponding file tree. If you want the data scattered over your filesystems and remote locations for that extra reliability, well, you need a custom backend.
#2 Configuration data is not human readable or editable.
Wrong. The default XML GConf backend keeps data in text files that are reasonably readable and editable (but you should take care to shutdown and restart the GConf server). Even better, you can tweak every single value using command line tools, and the effect will be immediate on the applications that care.
#3 Configuration data is not designed to be easily read and manipulated by other UNIX tools (All Data is an XML markup format and can only be manipulated by tools which are schema aware and schema compliant)
Install xsltproc from your favorite distribution and read xsltproc(1). No, it isn't schema aware, and it doesn't have to be. You'll need to learn XSLT, but that's little different from other UNIX tools which all have partially similar, but incompatible syntaxes and corresponding learning curves. A point in favor of the XML format is that transformations can be made reliably, while regex-based manipulations are easy to screw up.
They can't, it has KHTML derivative as a browser engine (the Apples fork)
Quite frankly, I don't get it. Build your platform around one stack, then pull in another one (Qt/KDE) just for the browser? In a device like this, they ought to be more rigorous about storage space and RAM usage.
Oh, sorry, I didn't see the reversed parameters. Well, there may be cases when the developer meant this, however bad style it is. I guess it wasn't worth making it a special case in the inheritance/override rules, they are complicated enough already.
You seem to forget the budding Java ME support on mobile devices. Even Motorola MPx 220 running Windows Mobile Smartphone 2003 has a Java machine in ROM, yet I haven't found.NET CF anywhere on it.
They still leave a gaping hole for confusion between UCS-2 and UTF-16 (and beween UCS-4 and UTF-32) by defining "unicode encoding form" as "encoded in UTF-8, UTF-16 or UTF-32" but "legacy encoding" as "any character encoding not based on Unicode."
I believe they are consistent here. UCS is a set of Unicode characters as abstract codes, and UTFs are representations of those characters with actual byte streams. There is no such thing, officially, as UCS-2 "encoding".
I've already bought the nice heavy wooden bat. I'll be painting "text encodings" and "clue" on it in the coming holidays, and I'm still very tempted to add some nails.
Actually, it adds markup capabilities to a Unicode text stream, something that previous markup/structured data representation technologies had troubles to do in a robust and standardized manner (even XML 1.0 itself has issues with that).
I've got XSL transformations which I use to add and remove entries within the Jabber config file in a safe and robust way. Ever tried to pull that for Apache with perl scripts? Ugh.
When I used Windows XP "Compression Wizard" for the last time, I was trying to unzip a 500K archive from a Windows network volume in the same office. It went sluggish with very slow progress for minutes and used network like crazy. Dropped that, installed 7-zip, it completed the work in a few seconds.
Its asm syntax etc is different from amd64 on *purpose* which was to create to incompatible 64bit system where Intel would keep AMD out of the market.
I can't see your logic here. How ould that possibly keep AMD out of the market? And, is this your only argument as to how Itanium is "broken by design"?
Slashdot Mirror
Jabber domains are not like email domains.
s2s connections are verified with a reciprocal DNS lookup and (in the newer revisions of the protocol) can be authenticated. If your server only accepts connections from servers authenticated with a valid certificate, spammers will spend time and money obtaining certificates for their domains which can then be banned in a few seconds. Even valid domain names cost actual money, as opposed to email messages with fake sender address.
Ah yes, I figured out what was wrong the first time: the "hl" language setting has to be English. It's kind of odd as it was thought of as the display language (there is an explicit search language setting), but now it affects results as well. Not nice.
Oh! Google read my every move, I knew this! (Runs away for a tinfoil hat).
<iq from='you@yourdomain.net/resource' type='set' id='blah'>
<item type='jid'
<query xmlns='jabber:iq:privacy'>
<list name='block-the-entire-fucking-spammer-domain'>
value='bigger-penis.net'
action='deny'
order='1'/>
</list>
</query>
</iq>
Tried "Godspeed You Black Emperor". No luck, although the regular links are plenty and relevant. Guess they're not popular at all.
It's basically the same, with more syntactic sugar, more slack on execution safety and hence more shoot-yourself-in-the foot factor. And the class library is a bit less coherent. In short, it's an improvement on Java, sort of, for smaller scale projects and/or programmers.
#1 All applications store their configuration data together in one place
Wrong. GConf storage can be decentralized, and the default storage backend lays out configuration values into a corresponding file tree. If you want the data scattered over your filesystems and remote locations for that extra reliability, well, you need a custom backend.
#2 Configuration data is not human readable or editable.
Wrong. The default XML GConf backend keeps data in text files that are reasonably readable and editable (but you should take care to shutdown and restart the GConf server). Even better, you can tweak every single value using command line tools, and the effect will be immediate on the applications that care.
#3 Configuration data is not designed to be easily read and manipulated by other UNIX tools (All Data is an XML markup format and can only be manipulated by tools which are schema aware and schema compliant)
Install xsltproc from your favorite distribution and read xsltproc(1). No, it isn't schema aware, and it doesn't have to be. You'll need to learn XSLT, but that's little different from other UNIX tools which all have partially similar, but incompatible syntaxes and corresponding learning curves. A point in favor of the XML format is that transformations can be made reliably, while regex-based manipulations are easy to screw up.
grammar nazi-ism.
You should have spelled it just 'nazism'.
Holy shit, the Wired website has timed out on me.
And we thought being linked from Slashdot alone is bad...
They can't, it has KHTML derivative as a browser engine (the Apples fork)
Quite frankly, I don't get it. Build your platform around one stack, then pull in another one (Qt/KDE) just for the browser? In a device like this, they ought to be more rigorous about storage space and RAM usage.
Oh, sorry, I didn't see the reversed parameters.
Well, there may be cases when the developer meant this, however bad style it is.
I guess it wasn't worth making it a special case in the inheritance/override rules, they are complicated enough already.
Tried to run this, did you?
Your Bar::foo does override Foo::foo, the lack of virtual specifier notwithstanding.
if only Sun would do something like writing a new faster classfile verifier.
They do: since (1.)5.0, JRE classes come preloaded in a shareable file.
You seem to forget the budding Java ME support on mobile devices. .NET CF anywhere on it.
Even Motorola MPx 220 running Windows Mobile Smartphone 2003 has a Java machine in ROM, yet I haven't found
The selling point being "Hey! It's not WinAPI! ::hallelujah::"
Only, it's still WinAPI under a thin veil of managed classes.
Eclipse SWT is just like that, though, and it's cross-platform.
Actually, it adds markup capabilities to a Unicode text stream, something that previous markup/structured data representation technologies had troubles to do in a robust and standardized manner (even XML 1.0 itself has issues with that).
'Taikonaut' is a media invention. The word that's used in China is yuhangyuan .
Read up on what Platonic ideal means.
I've got XSL transformations which I use to add and remove entries within the Jabber config file in a safe and robust way.
Ever tried to pull that for Apache with perl scripts? Ugh.
When I used Windows XP "Compression Wizard" for the last time, I was trying to unzip a 500K archive from a Windows network volume in the same office. It went sluggish with very slow progress for minutes and used network like crazy. Dropped that, installed 7-zip, it completed the work in a few seconds.
Continuations have made their way into Apache Cocoon, too.
HAL is not bound to GNOME in any way. KDE can use it for its benefit, too.
Its asm syntax etc is different from amd64 on *purpose* which was to create to incompatible 64bit system where Intel would keep AMD out of the market.
I can't see your logic here. How ould that possibly keep AMD out of the market?
And, is this your only argument as to how Itanium is "broken by design"?