In the commercial world, because of restrictions on software distribution, there is no single place to go for patches.
Restrictive software licenses have no impact upon the distribution of patches, and Microsoft Update is designed to distribute third party patches as well as Microsoft's own.
The list slowly gets bigger, as Trepia "finds" people close to me. Not a single one was in the same town as me, though a few were about 30-45 minute drives away.
Well, you're doing better than me. I'm in Oxford (UK); and I see people from Australia, California, Iowa, Arizona, and Quebec.
The people who absolutely must have the latest gadgets bought them during the first few months; the rest of us haven't had any reason to buy them.
Next year, there will probably be better operating system and application support, and at that point tablets will actually be useful; but until then the only market which exists is already saturated.
If you've already got the hardware you're going to use, and it doesn't have any caches, then you're absolutely right.
But if you have the option of choosing your hardware, you can buy memory which is smaller and faster; and if your hardware has a caching subsystem, you certainly gain from using a smaller address space.
oops. I need some sleep. I meant "Random access to an n-bit address space takes O(n) time", of course.
Your uniform-access-time machine will have memory which is the same speed as the equally sized memory of a nonuniform-access-time machine. Accessing one word out of 2^n requires O(n) gate delays; this is why Intel uses small L1 caches.
(Technically, it also requires O(2^(n/2)) propagation time, provided that we assume a two dimensional layout; but that usually turns out to be unimportant.)
And any 2nd year Computer Science student who stayed awake during his lectures knows that, given a source of random bits, the probability of quicksort taking more than O(n log n) time is zero for any input.
I'm interested by what the authors say about 'modern universal hash functions' and how they are immune from attack. Does this mean you pick a random string and XOR against it before computing each hash value, or something like that? It would seem there could still be some way to discover the exact hash function being used by means of timing attacks (you can tell when an input has caused a hash collision because the response time might be slightly slower).
If you use a strong keyed hash function (eg, keyed MD5) then there is no known method to recover the hash key with a chosen plaintext attack. In other words, even if you know exactly what each of your inputs hashes to, you still won't be able to predict the hash of anything else (or, consequently, create collisions).
Incidentally, hash functions are only O(1) average case under bogus assumptions. Random access to an n-bit address space takes O(log n) time.
Basically, the paper says this: If you have a hash table into which attackers can insert arbitrary keys, you'd better be using a hash function for which they cannot easily generate collisions.
I don't know if anyone has *published* this before, but it's certainly not new.
They claim to present a new method of low-bandwidth denial of service attack, but it looks like they're demonstrating quite an old, high-bandwidth, denial of service.
Is this a stack overflow, or just a crazy use of recursion?
The following COMException has been caught
eslo.core.jni.COMException: 0x80004005 E_FAIL [FACILITY_NULL "Unspecified error "] (Get records failed. talkProtocol.store_cards() failed with errorstate 2.)
eslo.core.jni.COMException: 0x80004005 E_FAIL [FACILITY_NULL "Unspecified error "] (Get records failed. talkProtocol.store_cards() failed with errorstate 2.) at eslo.core.bibliotek.IBibTalkPtr.GetCards(Native Method) at eslo.cell.utils.BibUtils.getCards(BibUtils.java:29 8) at eslo.cell.utils.BibUtils.getCard(BibUtils.java:387 ) at eslo.cell.content.ArticleInit.init(ArticleInit.jav a:31) at eslo.cell.site.WebPageInitBase.Process(WebPageInit Base.java:37) at eslo.core.pagetemplating.PTContentHandler.ProcessC omponent(PTContentHandler.java:1422) at eslo.core.pagetemplating.PTContentHandler.ProcessT ag(PTContentHandler.java:1064) at eslo.core.pagetemplating.PTContentHandler.endEleme nt(PTContentHandler.java:990) at org.brownell.xml.aelfred2.SAXDriver.endElement(SAX Driver.java:732) at org.brownell.xml.aelfred2.XmlParser.parseETag(XmlP arser.java:1122) at org.brownell.xml.aelfred2.XmlParser.parseContent(X mlParser.java:1200) at org.brownell.xml.aelfred2.XmlParser.parseElement(X mlParser.java:1026) at org.brownell.xml.aelfred2.XmlParser.parseContent(X mlParser.java:1205) at org.brownell.xml.aelfred2.XmlParser.parseElement(X mlParser.java:1026) at org.brownell.xml.aelfred2.XmlParser.parseContent(X mlParser.java:1205) at org.brownell.xml.aelfred2.XmlParser.parseElement(X mlParser.java:1026) at org.brownell.xml.aelfred2.XmlParser.parseDocument( XmlParser.java:499) at org.brownell.xml.aelfred2.XmlParser.doParse(XmlPar ser.java:151) at org.brownell.xml.aelfred2.SAXDriver.parse(SAXDrive r.java:309) at eslo.core.pagetemplating.PageTemplater.Process(Pag eTemplater.java:352) at eslo.core.pagetemplating.IAmPTComponentPtr.Process (Native Method) at eslo.core.pagetemplating.PTContentHandler.ProcessC omponent(PTContentHandler.java:1363) at eslo.core.pagetemplating.PTContentHandler.ProcessT ag(PTContentHandler.java:1064) at eslo.core.pagetemplating.PTContentHandler.endEleme nt(PTContentHandler.java:990) at org.brownell.xml.aelfred2.SAXDriver.endElement(SAX Driver.java:732) at org.brownell.xml.aelfred2.XmlParser.parseETag(XmlP arser.java:1122) at org.brownell.xml.aelfred2.XmlParser.parseContent(X mlParser.java:1200) at org.brownell.xml.aelfred2.XmlParser.parseElement(X mlParser.java:1026) at org.brownell.xml.aelfred2.XmlParser.parseContent(X mlParser.java:1205) at org.brownell.xml.aelfred2.XmlParser.parseElement(X mlParser.java:1026) at org.brownell.xml.aelfred2.XmlParser.parseContent(X mlParser.java:1205) at org.brownell.xml.aelfred2.XmlParser.parseElement(X mlParser.java:1026) at org.brownell.xml.aelfred2.XmlParser.parseDocument( XmlParser.java:499) at org.brownell.xml.aelfred2.XmlParser.doParse(XmlPar ser.java:151) at org.brownell.xml.aelfred2.SAXDriver.parse(SAXDrive r.java:309) at eslo.core.pagetemplating.PageTemplater.Process(Pag eTemplater.java:352) at eslo.core.pagetemplating.IAmPTComponentPtr.Process (Native Method) at eslo.common.site.SiteApp.Run(SiteApp.java:176)
Re:Esp. when you try to pronounce it
on
fvwm Turns Ten
·
· Score: 1
I think Linus has just as good reasons to make sure "tainted" code doesn't get into Linux
Sure, but he can't afford to hire people to spend 40 hours a week checking up on where code came from.
And Microsoft could just as easily claim something like, "Well, that code was produced by Joe (aside: and he always was a little shifty), but we fired him years ago."
Microsoft has the resources to monitor its employees; because they are more capable of verifying the source of code, they have a greater legal liability.
Furthermore, if they tried to pin the blame of Joe Innocent Programmer, the next step would be to track down Joe Innocent Programmer and interview him; given that Microsoft would have useful things like Joe's full legal name, SSN, bank account information, et cetera, it would be very hard to claim that some code came from a mysterious programmer who can no longer be traced.
With open source software, if a project maintainer claimed that he was sent some code from xyz@hotmail.com, it would be very hard to contradict him.
What a load of crap. He's essentially saying that closed-source code is somehow more guaranteed to be more legitimate.
Personally, I'd agree with that -- not because of the licensing model, but because of the authorship model.
When code gets into Microsoft Windows, it is clearly due to the deliberate action of someone at Microsoft; as a result, Microsoft has a very good reason to make sure "tainted" code doesn't get included.
With a project which accepts code contributions from around the world, there is both less accountability -- Linus can say "I didn't know that code came from SCO" far more convincingly than Microsoft ever could -- and less traceability -- past experiences with license shifts have demonstrated that it is very hard for an open source project to track down its contributors.
I've been using a contactless credit card for years. I type the number into an HTML form, and my card never comes within the same city as the merchant I'm purchasing something from. For that matter, it sometimes isn't in the same city as I am when I'm making the purchase -- for a couple months last year it was on a different continent.
In fact... let me see here... no, I still haven't gotten around to signing the back.
Almost. They still use miles on highway signs; but you'll now find signs telling you that exits are 1/3 or 2/3 of a mile away, so it's clear that they're looking forward to switching to metric units there as well.
(1/3 of a mile is pretty close to 0.5km, so with the signs as they are now, they'd only need to be repainted, rather than being moved.)
Slashdot Mirror
In the commercial world, because of restrictions on software distribution, there is no single place to go for patches.
Restrictive software licenses have no impact upon the distribution of patches, and Microsoft Update is designed to distribute third party patches as well as Microsoft's own.
The list slowly gets bigger, as Trepia "finds" people close to me. Not a single one was in the same town as me, though a few were about 30-45 minute drives away.
Well, you're doing better than me. I'm in Oxford (UK); and I see people from Australia, California, Iowa, Arizona, and Quebec.
When a company claims being "on crack" as a major advantage, I think it's clear that the US war on drugs has failed miserably.
No they didn't; they admitted to having *a nuclear weapons programme*.
They're trying to make nuclear weapons, and they have the resources necessary to do so, but they haven't yet demonstrated any success.
Come on, nobody is going to believe that. You should have written this:
Hah! I just scanned 127.0.0.1 and all your ports are open, prepare for the system halt of your li+++ATH NO CARRIER
The people who absolutely must have the latest gadgets bought them during the first few months; the rest of us haven't had any reason to buy them.
Next year, there will probably be better operating system and application support, and at that point tablets will actually be useful; but until then the only market which exists is already saturated.
Like... dental fillings?
Does anyone know what makes some metal implants worse than others? Is it just a question of size?
If you've already got the hardware you're going to use, and it doesn't have any caches, then you're absolutely right.
But if you have the option of choosing your hardware, you can buy memory which is smaller and faster; and if your hardware has a caching subsystem, you certainly gain from using a smaller address space.
oops. I need some sleep. I meant "Random access to an n-bit address space takes O(n) time", of course.
Your uniform-access-time machine will have memory which is the same speed as the equally sized memory of a nonuniform-access-time machine. Accessing one word out of 2^n requires O(n) gate delays; this is why Intel uses small L1 caches.
(Technically, it also requires O(2^(n/2)) propagation time, provided that we assume a two dimensional layout; but that usually turns out to be unimportant.)
And any 2nd year Computer Science student who stayed awake during his lectures knows that, given a source of random bits, the probability of quicksort taking more than O(n log n) time is zero for any input.
I'm interested by what the authors say about 'modern universal hash functions' and how they are immune from attack. Does this mean you pick a random string and XOR against it before computing each hash value, or something like that? It would seem there could still be some way to discover the exact hash function being used by means of timing attacks (you can tell when an input has caused a hash collision because the response time might be slightly slower).
If you use a strong keyed hash function (eg, keyed MD5) then there is no known method to recover the hash key with a chosen plaintext attack. In other words, even if you know exactly what each of your inputs hashes to, you still won't be able to predict the hash of anything else (or, consequently, create collisions).
Incidentally, hash functions are only O(1) average case under bogus assumptions. Random access to an n-bit address space takes O(log n) time.
Basically, the paper says this: If you have a hash table into which attackers can insert arbitrary keys, you'd better be using a hash function for which they cannot easily generate collisions.
I don't know if anyone has *published* this before, but it's certainly not new.
They claim to present a new method of low-bandwidth denial of service attack, but it looks like they're demonstrating quite an old, high-bandwidth, denial of service.
Is this a stack overflow, or just a crazy use of recursion?
9 8) at eslo.cell.utils.BibUtils.getCard(BibUtils.java:387 ) at eslo.cell.content.ArticleInit.init(ArticleInit.jav a:31) at eslo.cell.site.WebPageInitBase.Process(WebPageInit Base.java:37) at eslo.core.pagetemplating.PTContentHandler.ProcessC omponent(PTContentHandler.java:1422) at eslo.core.pagetemplating.PTContentHandler.ProcessT ag(PTContentHandler.java:1064) at eslo.core.pagetemplating.PTContentHandler.endEleme nt(PTContentHandler.java:990) at org.brownell.xml.aelfred2.SAXDriver.endElement(SAX Driver.java:732) at org.brownell.xml.aelfred2.XmlParser.parseETag(XmlP arser.java:1122) at org.brownell.xml.aelfred2.XmlParser.parseContent(X mlParser.java:1200) at org.brownell.xml.aelfred2.XmlParser.parseElement(X mlParser.java:1026) at org.brownell.xml.aelfred2.XmlParser.parseContent(X mlParser.java:1205) at org.brownell.xml.aelfred2.XmlParser.parseElement(X mlParser.java:1026) at org.brownell.xml.aelfred2.XmlParser.parseContent(X mlParser.java:1205) at org.brownell.xml.aelfred2.XmlParser.parseElement(X mlParser.java:1026) at org.brownell.xml.aelfred2.XmlParser.parseDocument( XmlParser.java:499) at org.brownell.xml.aelfred2.XmlParser.doParse(XmlPar ser.java:151) at org.brownell.xml.aelfred2.SAXDriver.parse(SAXDrive r.java:309) at eslo.core.pagetemplating.PageTemplater.Process(Pag eTemplater.java:352) at eslo.core.pagetemplating.IAmPTComponentPtr.Process (Native Method) at eslo.core.pagetemplating.PTContentHandler.ProcessC omponent(PTContentHandler.java:1363) at eslo.core.pagetemplating.PTContentHandler.ProcessT ag(PTContentHandler.java:1064) at eslo.core.pagetemplating.PTContentHandler.endEleme nt(PTContentHandler.java:990) at org.brownell.xml.aelfred2.SAXDriver.endElement(SAX Driver.java:732) at org.brownell.xml.aelfred2.XmlParser.parseETag(XmlP arser.java:1122) at org.brownell.xml.aelfred2.XmlParser.parseContent(X mlParser.java:1200) at org.brownell.xml.aelfred2.XmlParser.parseElement(X mlParser.java:1026) at org.brownell.xml.aelfred2.XmlParser.parseContent(X mlParser.java:1205) at org.brownell.xml.aelfred2.XmlParser.parseElement(X mlParser.java:1026) at org.brownell.xml.aelfred2.XmlParser.parseContent(X mlParser.java:1205) at org.brownell.xml.aelfred2.XmlParser.parseElement(X mlParser.java:1026) at org.brownell.xml.aelfred2.XmlParser.parseDocument( XmlParser.java:499) at org.brownell.xml.aelfred2.XmlParser.doParse(XmlPar ser.java:151) at org.brownell.xml.aelfred2.SAXDriver.parse(SAXDrive r.java:309) at eslo.core.pagetemplating.PageTemplater.Process(Pag eTemplater.java:352) at eslo.core.pagetemplating.IAmPTComponentPtr.Process (Native Method) at eslo.common.site.SiteApp.Run(SiteApp.java:176)
The following COMException has been caught
eslo.core.jni.COMException: 0x80004005 E_FAIL [FACILITY_NULL "Unspecified error "] (Get records failed. talkProtocol.store_cards() failed with errorstate 2.)
eslo.core.jni.COMException: 0x80004005 E_FAIL [FACILITY_NULL "Unspecified error "] (Get records failed. talkProtocol.store_cards() failed with errorstate 2.) at eslo.core.bibliotek.IBibTalkPtr.GetCards(Native Method) at eslo.cell.utils.BibUtils.getCards(BibUtils.java:2
You don't speak Welsh, do you?
I think Linus has just as good reasons to make sure "tainted" code doesn't get into Linux
Sure, but he can't afford to hire people to spend 40 hours a week checking up on where code came from.
And Microsoft could just as easily claim something like, "Well, that code was produced by Joe (aside: and he always was a little shifty), but we fired him years ago."
Microsoft has the resources to monitor its employees; because they are more capable of verifying the source of code, they have a greater legal liability.
Furthermore, if they tried to pin the blame of Joe Innocent Programmer, the next step would be to track down Joe Innocent Programmer and interview him; given that Microsoft would have useful things like Joe's full legal name, SSN, bank account information, et cetera, it would be very hard to claim that some code came from a mysterious programmer who can no longer be traced.
With open source software, if a project maintainer claimed that he was sent some code from xyz@hotmail.com, it would be very hard to contradict him.
What a load of crap. He's essentially saying that closed-source code is somehow more guaranteed to be more legitimate.
Personally, I'd agree with that -- not because of the licensing model, but because of the authorship model.
When code gets into Microsoft Windows, it is clearly due to the deliberate action of someone at Microsoft; as a result, Microsoft has a very good reason to make sure "tainted" code doesn't get included.
With a project which accepts code contributions from around the world, there is both less accountability -- Linus can say "I didn't know that code came from SCO" far more convincingly than Microsoft ever could -- and less traceability -- past experiences with license shifts have demonstrated that it is very hard for an open source project to track down its contributors.
I've been using a contactless credit card for years. I type the number into an HTML form, and my card never comes within the same city as the merchant I'm purchasing something from. For that matter, it sometimes isn't in the same city as I am when I'm making the purchase -- for a couple months last year it was on a different continent.
In fact... let me see here... no, I still haven't gotten around to signing the back.
The truly amazing part is that the postgresql folks have not arrived yet.
Not at all. Postgresql is a database. This story has absolutely no connection to databases.
Too bad it costs $400 to talk to M$.
Not for security patches. If you install a security patch and it breaks your system, Microsoft will not charge to help you fix it.
Technically, the mass does change when diamond decays into graphite -- by 1.789240343(72) x 10^-10 %.
Almost. They still use miles on highway signs; but you'll now find signs telling you that exits are 1/3 or 2/3 of a mile away, so it's clear that they're looking forward to switching to metric units there as well.
(1/3 of a mile is pretty close to 0.5km, so with the signs as they are now, they'd only need to be repainted, rather than being moved.)
...just define a kilogram in terms of 'x' number of Joules
Because that's how a Joule is defined.
You mean liberated of course.
No, France doesn't have any oil reserves. When France is invaded it will be for the purpose of disarming them.
Thank God!!! Maybe next time France is invaded they will call somebody else.
At the rate things are going right now, the next time France is invaded it will probably be *by* the USA.