I'd say that in terms of evilness, Mao > Current Chinese Government >> America.
The American government, BTW, isn't holding it's own citizens in gitmo, just people who where a) foreign and b) captured in a war figthing out of uniform for the other side. Back in WWII, spies and saboteurs where routinely shot not just held in dubious conditions. Traitors too actually, which would cover anyone in gitmo with US citizenship if they fought for the wrong side. So gitmo is actually an improvement on WWII. That said, people probably got tortured there, which I can't condone.
But the Chinese government is holding and torturing thousands of people without any pretence of a legal process. It also doing it to it's own citizens purely for peaceful opposition, which the American one doesn't. I'd guess that if you're American, you're not in mortal danger for criticising the US gov your last post, which wouldn't be true if you were Chinese. Also, unlike in America, the orders for the repression are absolutely linked to the people in power - read the Tiananmen Papers if you're interested. Now some memo could pop up tomorrow linking Rumsfeld to torture of course, but if it did it would be covered by the media (unlike China), people would lose their jobs and/or go to jail (ditto) and the US government would end up apologising and paying compensation. So the two US and Chinese government aren't really comparable morally.
And in any case, the misdeeds of the American government in a war isn't really the point here. Democracies do some highly questionable things to their enemies in wars, but dictatorships need to do much worse to their citizens just to survive. And you need to keep in mind that the democracies conduct in recent wars is less questionable than in WWII, where Kabul&Baghdad would have been levelled to the ground, and the people in gitmo would have been summarily executed.
And this is not a 'my country right or wrong' patriotic thing btw, since America isn't my country. I just think it's important to realise that there are good guys and bad guys, even if the good guys are not exactly perfect.
Oppression in a dictatorship is about keeping people from complaining about the ruler's bad behaviour by threatening them with death or torture, and I can't see how anyone can see that as anything but evil. Plus, once you go down that route, the rulers will get worse and worse as time goes by, partly to keep people in line, and partly because they can get away with it.
This marks all the pages on the per app free list as invalid, so you are guaranteed to get clobbered if you touch them. I'd bet there is a AppCompatibility flag in the registy which does the opposite somewhere, i.e. it keeps freed blocks valid for longer (for ever?). That way, if they find some 'commercially important' application would break with the new heap allocation algorithm when they test it, they can set the flag and no one will see a problem. Except the company who wrote it, who presumably get an error report.
The argument that we somehow owe Africa because of slavery is pretty bogus. Slavery was ubiquitous all over the world in ancient times, practised in every society, including Africa and Europe.
In Europe in gradually disappeared in the middle ages as societies moved from feudalism into capitalism. Africa stayed at the feudal level and so still had slaves. Once the Europeans could build ships and travel they world they bought African slaves, but it was in Britain that the movement to abolish slavery started. So the British abolished slavery, first in their own societies and then eventually in the whole world.
"While it was difficult to defend the conduct of Europeans in the slave trade, that of Africans in bartering each other was even more reprehensible."
Fact is, the Finnish dude is right, most African societies are on short bus to nowhere. And before I get a load of people calling me a racist, it's the society that's retarded, not the people. Africans in Europe/America/anywhere but Africa behave in a civilised way, and I suspect Europeans in some lawless hellhole will turn into barbarians pretty quickly.
And you could probably find some way to bootstrap a civil society in most of the direst parts of Africa, given a bit of ingenuity.
I had a look at the CPRM documents, and it seems to depend on two things, firstly that the protected material is always encrypted. The second is more subtle - that software that plays it needs to license the keys, and the company that makes it will need to sign an agreement not to provide unencrypted content to get the license.
Of course someone could pay up the cash or get hold of the keys and create a libuncprm. But then I think the compromised keys could be revoked, and that someone could get sued. If you copied the encrypted data, it won't decrypt because the media id is hashed into the decryption key, so changing media will break the decryption process. Also, at least in the US the DMCA would criminalise parts of the cracking process.
And they've learnt from CSS too - the keys may be secret, but the encryption algorithms are open sourced and peer reviewed, so the encryption won't have flaws like CSS did.
I've done mostly coding up to now, but I reckon I could do brain surgery. You've got all the knives and skull saws already right? Most importantly, do you have really good liability insurance.
Dude, maybe it's like a conspiracy and shit. I mean the companies make loads of cash off tobacco, and they own the government. You think we'd have invaded Iran if we were all stoned? That's why they don't want you smokin' weed, man. Hence all the lies.
That's not any less secure than a real CRC32 function in terms of how hard it is to fake.
In both cases, if you modfy the data you just need to change a couple of bytes to fix up the checksum. Admittedly you only need to change 1 byte in this algorithm versus 4 for a CRC32, but either way it is a couple of minutes work. It is worse at spotting errors - notably that you could swap a couple of bytes and it wouldn't notice, unlike CRC32.
Mind you, in a underpowered embedded system (clock speed speed to slow to use the non table CRC in real time, not enough ram for the CRC tables), a checksum like this is probably better than nothing and cheaper than a CRC computationally. Imagine a microcontroller USB bootloader for example. Compared to no checksum, this would catch errors like broken RAM or a bad uart, both of which tend to completely destroy data, but it can still receive as fast as the host can send, whereas a real CRC would be a bottleneck limiting speed somewhat.
Good page on CRC's - you can usually use either the non table version - fast CPU, no much RAM, or the table one - slow CPU clock, at least 1K of Ram or Rom available.
I got the same thing with my laptop Intel graphics chip. It even pointed me to the location of an updated driver on the Intel website.
It's a nice idea actually - the minidump contains a stackframe, version info and the exception code, and it's probably pretty easy to write a script to spot known errors if you have that.
The really slick thing is that the machine didn't crash - it switched back to the VGA driver in 640x480x16 colour and displayed a dialog box telling me to save. Then I shut down and it contacted Online Crash Analysis which popped up a web page with the updated driver. Apparently some versions of the driver would get stuck in a loop, and XP knows how to detect that.
I wouldn't worry about it - the Nazis tried to get me in Return to Castle Wolfenstein, but I kicked ass. Just make sure you have the chain gun, and lots of grenades and ammo and you'll do ok.
But you could sandbox processes without locking them to a core.
E.g. I read somewhere that Longhorn will do it for Internet Explorer. Threads from it will still run on any core, but they will be have very low security permissions. But that implies that every dangerous API function be tested to make sure that it respects the permissions, or if it depends on something else which respects them, that it handles the error gracefully.
It's actually kind of fascinating in a morbid way to watch them try to secure IE, despite the fact that things like ActiveX are not really designed with security in mind.
It's a different methodolgy, but most likely one that works as well. I appreciate the Linux one better-- the "normal" 32-bit stuff lives in the "normal" places-- that way, you don't *need* an emulation layer for the 64-bit unaware apps. Rather, 64-bit aware apps know to look in the correct location for the libraries (well, they are told by the OS, anyways). The Linux Way (TM) is slightly more backward compatible, me thinks. You'll *never* experience a problem with a 32-bit app on a 64-bit linux system, while there are some bugs in WoW64 which will probably never be fixed, rather, they'll be 'phased out', in the usual MS fashion (ignored until irrelevant).
I think you still need to have an emulation layer somewhere. E.g consider a 32 bit application on a 64 bit OS.
Imagine it calls open and passes a 32 bit pointer to a filename as the first argument. If the kernel is 64 bit, someone needs to translate the pointer.
In this case, and probably 99% of the time, this is just a sign or zero extension on the pointer parameters but if you have a function which takes a pointer to a structure containing pointers to other structures, it's much less trivial. But unless you want to have a kernal with two paths, one for 32 bit and one for 64, you have to do the translation somewhere.
64bit operations - there are a lot of places where you can make use of 64 bit vs 32 bit integers to reduce (halve) the number of instructions you execute. This assumes that your performance is instruction bounded rather than memory bounded, which is sometimes the case.
Not sure that many real applications are limited by instruction fetches to be honest. I'm sure you find some pathological cases, but not many.
Generally, there's no benefit to locking to (or against) a given core, but if you've one core designated for supervisor operations, you don't want applications to interfere with it. In many-way SMP clusters, you also don't want threads geographically spread too far, or you'll lose performance.
I've seen some embedded systems which lock time critical stuff to one core - you probably have one in your cellphone. Then again, the 'cores' in this case are very different from the main processor - different address space, instruction set and so on.
But for normal desktop stuff on a SMP system, you're better off just letting the kernel do it's stuff with scheduling. You can give it some hints with priority, but locking threads to a CPU is likely to make things worse in the long run - imagine if you have two applications which decide that processor 1 is their 'supervisor' processor and lock all their time critical threads on it. They would have been better off not locking an getting the chance to run the supervisor stuff on any processor.
My back of the envelope calculation says that we should get 25x the energy density in fat based power source. Which is pretty impressive. Mind you, getting all the energy out of burning fat would be tricky. Plus, it's a nasty idea.
Personally, I like the idea of running laptops on butane or propane - you could buy lighter fuel like pressurised containers from a shop, and burn the contents in some suitable engine - maybe a gas turbine or a Stirling engine connected to a dynamo.
Slashdot Mirror
I'd say that in terms of evilness, Mao > Current Chinese Government >> America.
The American government, BTW, isn't holding it's own citizens in gitmo, just people who where a) foreign and b) captured in a war figthing out of uniform for the other side. Back in WWII, spies and saboteurs where routinely shot not just held in dubious conditions. Traitors too actually, which would cover anyone in gitmo with US citizenship if they fought for the wrong side. So gitmo is actually an improvement on WWII. That said, people probably got tortured there, which I can't condone.
But the Chinese government is holding and torturing thousands of people without any pretence of a legal process. It also doing it to it's own citizens purely for peaceful opposition, which the American one doesn't. I'd guess that if you're American, you're not in mortal danger for criticising the US gov your last post, which wouldn't be true if you were Chinese. Also, unlike in America, the orders for the repression are absolutely linked to the people in power - read the Tiananmen Papers if you're interested. Now some memo could pop up tomorrow linking Rumsfeld to torture of course, but if it did it would be covered by the media (unlike China), people would lose their jobs and/or go to jail (ditto) and the US government would end up apologising and paying compensation. So the two US and Chinese government aren't really comparable morally.
And in any case, the misdeeds of the American government in a war isn't really the point here. Democracies do some highly questionable things to their enemies in wars, but dictatorships need to do much worse to their citizens just to survive. And you need to keep in mind that the democracies conduct in recent wars is less questionable than in WWII, where Kabul&Baghdad would have been levelled to the ground, and the people in gitmo would have been summarily executed.
And this is not a 'my country right or wrong' patriotic thing btw, since America isn't my country. I just think it's important to realise that there are good guys and bad guys, even if the good guys are not exactly perfect.
Oppression in a dictatorship is about keeping people from complaining about the ruler's bad behaviour by threatening them with death or torture, and I can't see how anyone can see that as anything but evil. Plus, once you go down that route, the rulers will get worse and worse as time goes by, partly to keep people in line, and partly because they can get away with it.
Actually freed blocks go on a per application list, and on Win2k an up they go at the top of the list so they will be allocated next time you malloc
= /library/en-us/apcompat/apcompat/do_not_read_or_wr ite_from_freed_memory_blocks.asp
= /library/en-us/dnappcom/html/AppVerifier.asp
http://msdn.microsoft.com/library/default.asp?url
This exposed bugs where applications touch a freed block, so they came up with app verifier
http://msdn.microsoft.com/library/default.asp?url
This marks all the pages on the per app free list as invalid, so you are guaranteed to get clobbered if you touch them. I'd bet there is a AppCompatibility flag in the registy which does the opposite somewhere, i.e. it keeps freed blocks valid for longer (for ever?). That way, if they find some 'commercially important' application would break with the new heap allocation algorithm when they test it, they can set the flag and no one will see a problem. Except the company who wrote it, who presumably get an error report.
http://www.javaworld.com/javaworld/jw-12-1997/jw-1 2-volanomark-p2.html
The argument that we somehow owe Africa because of slavery is pretty bogus. Slavery was ubiquitous all over the world in ancient times, practised in every society, including Africa and Europe.
m l
r egory.html
In Europe in gradually disappeared in the middle ages as societies moved from feudalism into capitalism. Africa stayed at the feudal level and so still had slaves. Once the Europeans could build ships and travel they world they bought African slaves, but it was in Britain that the movement to abolish slavery started. So the British abolished slavery, first in their own societies and then eventually in the whole world.
http://www.royal-navy.mod.uk/static/pages/5801.ht
And yet 200 years later, there are still slaves in Africa.
http://www.leaderu.com/ftissues/ft9605/articles/g
As Voltaire put it
"While it was difficult to defend the conduct of Europeans in the slave trade, that of Africans in bartering each other was even more reprehensible."
Fact is, the Finnish dude is right, most African societies are on short bus to nowhere. And before I get a load of people calling me a racist, it's the society that's retarded, not the people. Africans in Europe/America/anywhere but Africa behave in a civilised way, and I suspect Europeans in some lawless hellhole will turn into barbarians pretty quickly.
And you could probably find some way to bootstrap a civil society in most of the direst parts of Africa, given a bit of ingenuity.
So you're saying that Horton here's a Microsoft Ho?
1) Copy one
This is ok - you're allowed to do that.
2) Remove protection
This won't work - the copy is encrypted.
I had a look at the CPRM documents, and it seems to depend on two things, firstly that the protected material is always encrypted. The second is more subtle - that software that plays it needs to license the keys, and the company that makes it will need to sign an agreement not to provide unencrypted content to get the license.
Of course someone could pay up the cash or get hold of the keys and create a libuncprm. But then I think the compromised keys could be revoked, and that someone could get sued. If you copied the encrypted data, it won't decrypt because the media id is hashed into the decryption key, so changing media will break the decryption process. Also, at least in the US the DMCA would criminalise parts of the cracking process.
And they've learnt from CSS too - the keys may be secret, but the encryption algorithms are open sourced and peer reviewed, so the encryption won't have flaws like CSS did.
http://www.intel.com/standards/case/case_cp.htm
Be afraid, be very afraid.
I've done mostly coding up to now, but I reckon I could do brain surgery. You've got all the knives and skull saws already right? Most importantly, do you have really good liability insurance.
Dude, maybe it's like a conspiracy and shit. I mean the companies make loads of cash off tobacco, and they own the government. You think we'd have invaded Iran if we were all stoned? That's why they don't want you smokin' weed, man. Hence all the lies.
Stop bogartin' that blunt man and, pass it over.
That's not any less secure than a real CRC32 function in terms of how hard it is to fake.
c rc/node6.html#SECTION00060000000000000000
In both cases, if you modfy the data you just need to change a couple of bytes to fix up the
checksum. Admittedly you only need to change 1 byte in this algorithm versus 4 for a CRC32,
but either way it is a couple of minutes work.
It is worse at spotting errors - notably that you could swap a couple of bytes and it
wouldn't notice, unlike CRC32.
Mind you, in a underpowered embedded system (clock speed speed to slow to use the non table CRC
in real time, not enough ram for the CRC tables), a checksum like this is probably better than nothing
and cheaper than a CRC computationally. Imagine a microcontroller USB bootloader for example. Compared
to no checksum, this would catch errors like broken RAM or a bad uart, both of which tend to completely
destroy data, but it can still receive as fast as the host can send, whereas a real CRC would be
a bottleneck limiting speed somewhat.
Good page on CRC's - you can usually use either the non table version - fast CPU, no much RAM,
or the table one - slow CPU clock, at least 1K of Ram or Rom available.
http://www.cl.cam.ac.uk/Research/SRG/bluebook/21/
English grammar is more like a scandinavian language than German. And the vocabulary is completely different.
I'd say that but German, Scandinavian and English probably do share a common ancestor. Which is more than can be said for English and Latin.
Incidentally, all this reminds me of a great post in alt.religion.kibology
http://www.angelfire.com/la/carlosmay/Chomp.html
I got the same thing with my laptop Intel graphics chip. It even pointed me to the location of an updated driver on the Intel website.
It's a nice idea actually - the minidump contains a stackframe, version info and the exception code, and it's probably pretty easy to write a script to spot known errors if you have that.
The really slick thing is that the machine didn't crash - it switched back to the VGA driver in 640x480x16 colour and displayed a dialog box telling me to save. Then I shut down and it contacted Online Crash Analysis which popped up a web page with the updated driver. Apparently some versions of the driver would get stuck in a loop, and XP knows how to detect that.
I wouldn't worry about it - the Nazis tried to get me in Return to Castle Wolfenstein, but I kicked ass. Just make sure you have the chain gun, and lots of grenades and ammo and you'll do ok.
At least we're not afraid to call a Schwarzenegger a Schwarzenegger.
But you could sandbox processes without locking them to a core.
E.g. I read somewhere that Longhorn will do it for Internet Explorer. Threads from it will still run on any core, but they will be have very low security permissions. But that implies that every dangerous API function be tested to make sure that it respects the permissions, or if it depends on something else which respects them, that it handles the error gracefully.
It's actually kind of fascinating in a morbid way to watch them try to secure IE, despite the fact that things like ActiveX are not really designed with security in mind.
So your machine can be completely infested with spyware and viruses, but at least they only use cycles on one processor?
I think you still need to have an emulation layer somewhere. E.g consider a 32 bit application on a 64 bit OS.
Imagine it calls open and passes a 32 bit pointer to a filename as the first argument. If the kernel is 64 bit, someone needs to translate the pointer.
In this case, and probably 99% of the time, this is just a sign or zero extension on the pointer parameters but if you have a function which takes a pointer to a structure containing pointers to other structures, it's much less trivial. But unless you want to have a kernal with two paths, one for 32 bit and one for 64, you have to do the translation somewhere.
Yeah, no one would be stupid enough to do a nasty paging scheme to get more than 4GB on a 32 bit system ;-)
I've seen some embedded systems which lock time critical stuff to one core - you probably have one in your cellphone. Then again, the 'cores' in this case are very different from the main processor - different address space, instruction set and so on.
But for normal desktop stuff on a SMP system, you're better off just letting the kernel do it's stuff with scheduling. You can give it some hints with priority, but locking threads to a CPU is likely to make things worse in the long run - imagine if you have two applications which decide that processor 1 is their 'supervisor' processor and lock all their time critical threads on it. They would have been better off not locking an getting the chance to run the supervisor stuff on any processor.
That's odd, because it's fitta in Swedish, which is a completely unrelated language as far as I know.
But the spambot could just _pretend_ that it didn't understand.
;-)
Plus you're discriminating against autistic people who can read the steganographic messages in jpg files
ATP isn't an energy storage molecule - it's more like an energy transfer one. Fats are the main long term energy store.
e mical/
IIRC fats do almost as well as Gasoline, which is very good indeed, 30x better than Lithium ion batteries.
http://www.tinaja.com/glib/energfun.pdf
http://hypertextbook.com/physics/matter/energy-ch
My back of the envelope calculation says that we should get 25x the energy density in fat based power source. Which is pretty impressive. Mind you, getting all the energy out of burning fat would be tricky. Plus, it's a nasty idea.
Personally, I like the idea of running laptops on butane or propane - you could buy lighter fuel like pressurised containers from a shop, and burn the contents in some suitable engine - maybe a gas turbine or a Stirling engine connected to a dynamo.
[ESCAPE] : q ! [RETURN]
Easy to remember
ESCAPE this
COLON thing, (The colon-thing is a nickname for vi.)
Quit and do
NOT (slang for "!". Here used in the meaning "never".)
RETURN
Dijstra was a quiche eater