If the top-most hash is regularly saved to a secure write-only location, the full chain is authenticated by it. Manipulations by the attacker can hence easily be detected.
They abandoned the old Red Hat Linux distro years ago and now they sponsor Fedora, but it's essentially a community project. Red Hat don't provide support; indeed the Fedora project itself only supports ~one year worth of releases.
The vast majority of their efforts clearly go into Red Hat Enterprise Linux.
That's not true. UMTS signalling traffic is actually a big worry too.
Setting up and tearing down radio resource connections all the time has a burden on the network. Mobile applications, with their diverse update patterns (e.g. polling every 30 minutes (email apps), or minute or even few seconds (e.g. IM apps)), can make it difficult for carriers to set up their RRC inactivity timers and various other settings in a way that minimises signalling load on the network.
I can't compile programs written in the Java language to Dalvik?
You need to differentiate between the bytecode and the virtual machine. Anyway, the answer is no, not directly. The "Java language" or Java bytecode does not run on the Dalkiv virtual machine.
Desktop: The Java language is compiled to Java bytecode and run on the Java virtual machine.
Android: The Java language is compiled to Java bytecode. Using an Android tool, Java bytecode is transformed to Dalvik bytecode, which is then run on the Dalvik virtual machine.
I don't believe the patents in this case have anything to do with the Java language, the Java compiler, the Dalvik translator, or the Dalvik bytecode format. Sun's patents generally regard the virtual machine technology. Google have implemented an incompatible virtual machine, but of course with similarities to Java.. that's where the problems appear to lie.
No it's not. Nor is the JVM compatible with the Java language.
The Java language != Java bytecode != Dalvik bytecode
Dalvik... was created both to be Java compatible and also under the assumption that Sun was friendly towards open source systems.
Google wrote an entire new, incompatible bytecode language and virtual machine to circumvent licensing any Java components from Sun. So I doubt Google made any assumptions about the "open source friendliness" of Sun.
Android apps don't necessarily have to have a launcher icon (e.g. services, live wallpapers etc.).
Apps can also run automatically at boot time, therefore unless the user somehow discovered that the installed app was malicious and manually uninstalled it, they'd be stuck with this malware forever — assuming Google didn't have this remote-removal functionality.
You get 140 bytes of data per SMS, so with the default GSM 7-bit alphabet that gives you 160 characters.
I can't remember how alternative encodings work, but I seem to recall you get about 70 characters when you text with extended character sets, suggesting that it's some sort of UTF-16 like encoding scheme. That number drops if you start doing message concatenation.
Some of that is true, but XML and the XMPP protocol are highly compressible.
XMPP uses a long-lived TCP connection between servers, so the continued exchange of <message from="foo@wavesandbox.com/Wave" to="bar@example.com/Wave"> will compress to substantially fewer bytes on the wire.
The XMPP Foundation has done a lot of work on this, and continues to work on scalability issues; particularly between federated servers. Indeed, XMPP has reached a point where it's a fairly mature, secure and speedy technology — clearly making it desirable for companies such as Google to use as a foundation for interesting applications such as Wave.
I never quite understood the HTTP/S detection, as I would have thought it'd be simpler to do "//google-analytics.com/..." (i.e. no explicit protocol). Though again I don't know what standard, if any, defines that behaviour. But if it is/was standard, then you could have a single script block. But of course, as you say, developers who call _gat from elsewhere (such as myself) would have to know when the content had loaded. So, er yeah.. forget all of that!:)
I guess inconsistent browser is also why they disabled gzip support? Though I would have thought it would be trivial to Vary by User-Agent.
Something's (more) broken than usual. Currently the drop-down for this story says 6 comments with score 3, but if you select it, only 1 comment appears.
The years-old bug of not showing the correct number of comments at lower scores is still there too (e.g. currently reading at score 3 and the drop-down claims there's 6 comments for *all* scores 3 and under).
Indeed now I remember Pidgin also gets a bit confused/ignores the config with certain combinations of "Use old SSL method" (which can be used to bypass the SASL problem) and a custom port.
I believe it was a bug in Openfire and Pidgin's SASL implementation was doing things strictly correctly (as far as I remember).
If you trawl across the Pidgin and Adium tracs and through the Openfire forums there's a workaround in Openfire to do with explicitly setting the xmpp.domain property or something similar. Though I believe Adium added in a workaround at their end too.
I would say this is an overall benefit to users searching for information, given the awful state of many sites' internal search functionality (including Slashdot).
e.g. Search for the story a few days ago about India voting against OOXML. After a while, Slashdot gives you this. Note the lack of the article in question
Compare this with Google's site: results. Indeed Google seem to index more frequently and deeper than most sites' own search systems do.
Using Google's search-within-a-search (or site: for those who know about it) is many times faster than searching for a site, going to it, locating where their search box (or page) is, using it and waiting for the results. Another benefit of Google at this point being that the results are already sorted into a decent order and use a familiar layout.
From what I've seen via a friend who went to Glasgow Caledonian University, the MS-hosted student email seems horrible. No different to the usual Hotmail experience, it would appear.
Watching this setup video shows that not only do students see the usual Hotmail welcome page complete with adverts, but Microsoft also makes them verify (on a suddenly non-SSL page) that they're not spammers by completing a CAPTCHA!
Slashdot Mirror
I imagine it costs less to defend against and clean up after DDoS or XSS attacks on a static page, than it does against an active web site.
n/t
From the linked document:
Yes, of course it does.
Here, have a look at the protocol:
http://applidium.com/en/news/cracking_siri/
Yes, really.
They abandoned the old Red Hat Linux distro years ago and now they sponsor Fedora, but it's essentially a community project. Red Hat don't provide support; indeed the Fedora project itself only supports ~one year worth of releases.
The vast majority of their efforts clearly go into Red Hat Enterprise Linux.
Yeah, I'm sure they have never have thought of that problem...
Or, if you just read their website, it says that the company gets the customer's CLI as normal.
Yes.
Privacy > Customise Settings > Preview my Profile.
By default it shows what "most people" (i.e. strangers) see. You can then customise it for individual friends on your list.
Newer Android devices, especially tablets, have HDMI output.
There. Now you can copy movies with your non-rooted device.
True, although it costs 40 cents more - plus the cost of an SMS - than buying a regular stamp.
That's not true.
UMTS signalling traffic is actually a big worry too.
Setting up and tearing down radio resource connections all the time has a burden on the network. Mobile applications, with their diverse update patterns (e.g. polling every 30 minutes (email apps), or minute or even few seconds (e.g. IM apps)), can make it difficult for carriers to set up their RRC inactivity timers and various other settings in a way that minimises signalling load on the network.
You need to differentiate between the bytecode and the virtual machine. Anyway, the answer is no, not directly.
The "Java language" or Java bytecode does not run on the Dalkiv virtual machine.
Desktop: The Java language is compiled to Java bytecode and run on the Java virtual machine.
Android: The Java language is compiled to Java bytecode. Using an Android tool, Java bytecode is transformed to Dalvik bytecode, which is then run on the Dalvik virtual machine.
I don't believe the patents in this case have anything to do with the Java language, the Java compiler, the Dalvik translator, or the Dalvik bytecode format.
Sun's patents generally regard the virtual machine technology. Google have implemented an incompatible virtual machine, but of course with similarities to Java.. that's where the problems appear to lie.
Calm down, dear.
No it's not. Nor is the JVM compatible with the Java language.
The Java language != Java bytecode != Dalvik bytecode
Google wrote an entire new, incompatible bytecode language and virtual machine to circumvent licensing any Java components from Sun.
So I doubt Google made any assumptions about the "open source friendliness" of Sun.
Clicking on that link and reading the heading "Gloda is an index, not a data store" would suggest yes.
Android apps don't necessarily have to have a launcher icon (e.g. services, live wallpapers etc.).
Apps can also run automatically at boot time, therefore unless the user somehow discovered that the installed app was malicious and manually uninstalled it, they'd be stuck with this malware forever — assuming Google didn't have this remote-removal functionality.
You get 140 bytes of data per SMS, so with the default GSM 7-bit alphabet that gives you 160 characters.
I can't remember how alternative encodings work, but I seem to recall you get about 70 characters when you text with extended character sets, suggesting that it's some sort of UTF-16 like encoding scheme. That number drops if you start doing message concatenation.
Actually, I've always said Lexus is like the Japanese Mercedes.
Some of that is true, but XML and the XMPP protocol are highly compressible.
XMPP uses a long-lived TCP connection between servers, so the continued exchange of <message from="foo@wavesandbox.com/Wave" to="bar@example.com/Wave"> will compress to substantially fewer bytes on the wire.
The XMPP Foundation has done a lot of work on this, and continues to work on scalability issues; particularly between federated servers. Indeed, XMPP has reached a point where it's a fairly mature, secure and speedy technology — clearly making it desirable for companies such as Google to use as a foundation for interesting applications such as Wave.
Ah, didn't realise only IE supported defer!
I never quite understood the HTTP/S detection, as I would have thought it'd be simpler to do "//google-analytics.com/..." (i.e. no explicit protocol). Though again I don't know what standard, if any, defines that behaviour. But if it is/was standard, then you could have a single script block. But of course, as you say, developers who call _gat from elsewhere (such as myself) would have to know when the content had loaded. So, er yeah.. forget all of that! :)
I guess inconsistent browser is also why they disabled gzip support? Though I would have thought it would be trivial to Vary by User-Agent.
Or they could probably just use the "defer" attribute on the script tag.
Something's (more) broken than usual. Currently the drop-down for this story says 6 comments with score 3, but if you select it, only 1 comment appears.
The years-old bug of not showing the correct number of comments at lower scores is still there too (e.g. currently reading at score 3 and the drop-down claims there's 6 comments for *all* scores 3 and under).
Ah, thanks for the info!
Indeed now I remember Pidgin also gets a bit confused/ignores the config with certain combinations of "Use old SSL method" (which can be used to bypass the SASL problem) and a custom port.
I'll have to check Trac when it comes back up..!
I believe it was a bug in Openfire and Pidgin's SASL implementation was doing things strictly correctly (as far as I remember).
If you trawl across the Pidgin and Adium tracs and through the Openfire forums there's a workaround in Openfire to do with explicitly setting the xmpp.domain property or something similar. Though I believe Adium added in a workaround at their end too.
I would say this is an overall benefit to users searching for information, given the awful state of many sites' internal search functionality (including Slashdot).
e.g. Search for the story a few days ago about India voting against OOXML. After a while, Slashdot gives you this. Note the lack of the article in question
Compare this with Google's site: results. Indeed Google seem to index more frequently and deeper than most sites' own search systems do.
Using Google's search-within-a-search (or site: for those who know about it) is many times faster than searching for a site, going to it, locating where their search box (or page) is, using it and waiting for the results. Another benefit of Google at this point being that the results are already sorted into a decent order and use a familiar layout.
From what I've seen via a friend who went to Glasgow Caledonian University, the MS-hosted student email seems horrible. No different to the usual Hotmail experience, it would appear.
Watching this setup video shows that not only do students see the usual Hotmail welcome page complete with adverts, but Microsoft also makes them verify (on a suddenly non-SSL page) that they're not spammers by completing a CAPTCHA!
Also, there is no hand crank on the machine. It was an idea originally, but was not implemented.
See: http://en.wikipedia.org/wiki/OLPC_XO-1#Intentionally_omitted_features