Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
As has been stated repeatedly before, elsewhere, I wish I had mod points right now.
With that in mind, the first two statements pretty much sum it up. "Because I want to change it" is not a good reason, nor really is a designer saying "I don't like how it looks" if, while ugly, it's intuitive for the user to figure out.
I think I've taken all of half a dozen looks at the beta site, and without fail, my response is "get me the f*** out of here", not because it's unfamiliar (though it is), but because what I see is a jumbled mess that makes following LKML in message-received order when there are multiple heated discussions going on in parallel an easy task.
With that said, I don't consider JS to be the harbinger of death and otherwise all that is evil. Some designers & developers have never heard of progressive enhancement though, causing problems left and right. There are things that can be added to the current UI without completely breaking it that make things more convenient ("Load more comments" is actually one I use regularly, because I'm also aware of how broken the pagination of comments happens to be - but then again, threaded commenting doesn't lend itself to pagination without complete disposal of context. I'd rather read the comment threads and if that means a bit of script, so be it.)
Link to Original Source
Yup. It's sure the first result on Yahoo. Of course, the last update prior to yesterday that I can find has approximately nothing to do with this "Android Data" thing.
A bit more research, and you'll find: The site was last updated yesterday. The content that was there at it's last indexing on Google and MSN is the same as what is currently up at www.pushpuppets.net. As well, android-data.com (the actual domain for the "product") was registered on 2009/04/20; it's been around for a grand total of 12 days. The site that was there before, according to archive.org: it's a parking page for someone else operating a business by the name of "Android Data Services", though checking androiddata.com on archive.org gets you the same site: defunct since 2006, with it's last update being 2003/01/23. Searching for android-data.com gets you no site whatsoever, on Google, Yahoo, or MSN.
This reads to me as though truth is more idiotic than fiction. Nefarious is more likely the case: everything I've been able to tell suggests that the name and product have been dead for at least 3 years, if not more likely 6 years. Looks more like a case of "I might be able to sue Google for lots of money" than anything. The likelihood of actually winning any lawsuit there, suing over a product that nobody has ever heard of, on a trademark that nobody has ever heard of (until today)... um, right. Maybe if he were actually developing & promoting that product, then he'd have something to say.
Wind, solar, and hydrogen all have their issues: wind and solar are unreliable over time, because they both ultimately depend on the weather conditions, and hydrogen isn't an energy source. Free H2 uses a lot of energy to obtain, unless it's obtained from fossil fuels, which, while potentially better for the environment, still leaves us with a non-renewable resource.
Link to Original Source
The realm is only half of the identifying element - the URL requesting authentication is the other half. For basic authentication (RFC 2617, section 2), the realm value is only for the server sending it; if another server (identified typically by [ http/https, hostname, port ]) sends me a WWW-Authenticate header with the same realm name specified, for the purposes of authentication it is a different realm. In digest authentication (section 3), it is possible to have credentials go across multiple servers, but such servers have to be specified in the initial WWW-Authenticate header in a "domain" parameter; otherwise, the authentication is again only available to the server sending the WWW-Authenticate header in the first place.
Ultimately, unless your system, DNS server, proxy server (if you're using one), gateway, or the target server, have been broken into, obtaining the credentials for any given realm is going to be difficult; if your system has been broken into, this is pointless because they could just as easily install a keylogger to capture the authentication information as it's being entered; if your gateway has been broken into, then unless you're performing all authenticated transactions over HTTPS and/or not using HTTP Basic authentication, the information is going across there in cleartext anyway, and tcpdump is all that's needed to extract it. Since the proxy server tends to exist at the gateway level anyway, the same issues apply there. As far as the target server goes - you can either capture the authentication info there, or, since you've got permissions to do anything the webserver is capable of, including generally accessing the authentication DB, just grab the authentication information and be done with it.
So... good luck at attempting to reuse the exact realm of another server - since, for the purposes of comparing authentication realms, the realm name is little more than a token which identifies a given protection space on a single server (or multiple explicitly specified servers in HTTP Digest, but that's still explicit).