I don't get it.
If they ask what can be arbitrarily stored in the 4339bits available then there you can store 4339 arbitrary bits. It's a rule of compression. If they are asking for an English language compression program there are plenty better out there. Also if the goal is compression of English text and they aren't including the program size in the tweet then the competition can easily be cheated using a dictionary in the program that can be looked up.
At the winner it's not a particularly good compression algorithm. It doesn't even seem to take bayesian probability of characters into account. I can't see any arithmetic coding (mathematically the perfect entropy encoder) either.
Low end stuff.
It simply can't do the high end stuff even when clocked at 2+Ghz as ARM is still a 32bit processor (there are some 64bit instructions but we're talking memory bus here).
I'm not aware of any ARM that can address more than 4GB of memory.
Sounds like your problem is in having to support different drivers for every different piece of hardware.
How the heck is Virtualisation going to help you? Even if you have a Virtual machine that emulates a standard config of hardware what are you going to run the Virtualisation software on? You are still going to have different hardware to account for at some level. Whether it's a hypervisor or the OS itself somewhere down the chain the differences in hardware are going to have to be accounted for.
That and the Xms memory option. If Xms is set high enough Java will do 1 call to malloc throughout the life of the program. Not that that's a huge improvement as Java doesn't call malloc much anyway.
I'll get around to trying boehm gc one day but I'm pretty sure i'd see a speedup over a naive implementation (bulk allocations and frees are always faster than allocating in a loop) but it wouldn't be as good as an implementation that uses a memory pool (millions of the same type of object for a DMC compression algorithm - it's essentially made to be memory pooled).
Similar to the Java scenario.
I don't think that's what he was getting at. I think he means you can avoid that much malloc/free-ing.
Memory pooling and allocating outside of tight loops comes to mind.
Actually i've found the opposite. Java tends to be really good at transparent memory re-use. From experience if i have ~1,000,000 objects of the same type with the some constantly being deleted and replaced Java will run that program faster than a non-memory pooled C implementation (of course the memory pooled C implementation will be faster again).
In fact many of the benchmarks around that you see claiming Java is faster than C will use an example of a program that creates and destroys objects in a tight loop. The C program will be as written with tons of calls to malloc/free, the Java program will simply reuse the same parts of memory again and again without any system calls. These benchmarks are a bit misleading as the C program isn't optimised with memory re-use whereas the Java Garbage collector tends to do that implicitly.
Just so people know, the arrest of that Rio Tinto executive happened days after the Chinese government company Baosteel failed in a bid to take over the Australian Rio Tinto company. http://www.guardian.co.uk/business/2007/dec/04/riotinto.china
Essentially the message is, if you move your company to China you agree to everything they want, takeover offers, cheaper pricing etc. Otherwise you will be arrested.
I'm not sure why i'm being modded down here. Speak up someone.
Bing maps doesn't require Silverlight. I'm looking at it right now on a non-Silverlight machine.
Newegg were on top of this pretty early.
They never denied there being a problem although they took a day to figure out what was happening.
They have already apologized, announced they are sending out replacements and announced they are getting a new distributor a couple of days ago.
People are going to call you paranoid for that but it's pretty much true. Sodium Nitrite's one of the first that comes to mind.
Sodium Nitrite has medical uses but to get the chemical approved for use as a treatment it has to go through a ton of tests.
It is also used as a food preservative. For use in food the chemical is allowed until it is proven harmful. http://en.wikipedia.org/wiki/Sodium_nitrite
I have made DirectX games a long time ago but apart from simple examples i haven't looked into shaders much. I actually had a look just then and you are right. Obviously by design they don't allow any shaders (even the compute shaders) to access memory using pointers. So you can't arbitrarily write to some memory location on the system bus as i feared. It's obvious they wouldn't allow that even on trusted applications as your could break the whole trust system locally even. I feel silly now.
I still have an issue of the DirectX API as a whole running through the browser though.
Let me put it this way; this game API allows you to write a game, get inputs from the user, presumably via DirectX's direct input (it does imply full DirectX11 support in the blurb) and send out network outputs based on those inputs. Now i know for a fact Direct Input is very useful for capturing all keyboard input, if a key is down direct input can record that even if the current application is running in the background. Perfect for a keylogger.
There's so many little things like this they'll have to deal with before exposing the DirectX API to the web.
Shaders these days are fully programmable and DirectX allows access to them. I can't see any reason why a shader run off of a webpage couldn't do whatever it wants.
Graphics cards don't have any privilege ring security like x86s do. They simply trust that whatever shader that is sent to run on them is as trusted as the application running on the CPU that sends them the shader.
With this plan your browser will be sending your graphics card shaders to run from whatever website you visit.
Either they are going to have to prune the API down a lot before it is safe (without shaders you may as well be using an earlier version of DirectX), or they are going to have a security nightmare.
No, pretty much all a card skimmer does is record the data on the magnetic stripe.
They don't care what the data is or how the machine uses that data.
A typical mag card reader that you can legally buy off the shelf will happily record the info on your drivers license or preferred customer card every bit as easily as on your credit card. Mag stripe cards have the data in plain ASCII text, credit cards included.
If you've ever written a program that reads text data off a serial port and saves that data to a file you have all the knowledge you need to create a credit card skimmer that won't get confused based on what card is inserted.
The Royal Society that funded both Cook and Darwin was a privately established organisation.
It receives some funding from government grants but i think National Geographic does too. So essentially both organisations historically fill the same niche for different countries.
What chemicals are in these plants that give them insecticide properties? Finding a chemical that harms insects but doesn't harm humans is a tricky problem and it's why fly spray companies and the like have R&D departments.
If they are releasing a new never before ingested product onto the market shouldn't they be forced into similar regulations as pharmaceuticals?
I don't get it.
If they ask what can be arbitrarily stored in the 4339bits available then there you can store 4339 arbitrary bits. It's a rule of compression. If they are asking for an English language compression program there are plenty better out there. Also if the goal is compression of English text and they aren't including the program size in the tweet then the competition can easily be cheated using a dictionary in the program that can be looked up.
At the winner it's not a particularly good compression algorithm. It doesn't even seem to take bayesian probability of characters into account. I can't see any arithmetic coding (mathematically the perfect entropy encoder) either.
Well that's my point. That sort of thing is what the ARM will be good at. Low end stuff.
Low end stuff.
It simply can't do the high end stuff even when clocked at 2+Ghz as ARM is still a 32bit processor (there are some 64bit instructions but we're talking memory bus here).
I'm not aware of any ARM that can address more than 4GB of memory.
But further down this thread there's a study showing the opposite for those under 40. http://www.sciencedaily.com/releases/2009/01/090126082343.htm
Imagine if corporations could simply buy moon advertisements.... We'd be seeing crap like [KRAFT CHEESE] and other crap.
That'd be fucking awesome!!!
Sounds like your problem is in having to support different drivers for every different piece of hardware.
How the heck is Virtualisation going to help you? Even if you have a Virtual machine that emulates a standard config of hardware what are you going to run the Virtualisation software on? You are still going to have different hardware to account for at some level. Whether it's a hypervisor or the OS itself somewhere down the chain the differences in hardware are going to have to be accounted for.
I don't get what you are trying to accomplish.
If you think it's bad I'm guessing you don't vote republican then? Seeing as though they are part of a larger international political organisation.
http://en.wikipedia.org/wiki/International_Democrat_Union
That and the Xms memory option. If Xms is set high enough Java will do 1 call to malloc throughout the life of the program. Not that that's a huge improvement as Java doesn't call malloc much anyway.
I'll get around to trying boehm gc one day but I'm pretty sure i'd see a speedup over a naive implementation (bulk allocations and frees are always faster than allocating in a loop) but it wouldn't be as good as an implementation that uses a memory pool (millions of the same type of object for a DMC compression algorithm - it's essentially made to be memory pooled).
Similar to the Java scenario.
I don't think that's what he was getting at. I think he means you can avoid that much malloc/free-ing.
Memory pooling and allocating outside of tight loops comes to mind.
Actually i've found the opposite. Java tends to be really good at transparent memory re-use. From experience if i have ~1,000,000 objects of the same type with the some constantly being deleted and replaced Java will run that program faster than a non-memory pooled C implementation (of course the memory pooled C implementation will be faster again).
In fact many of the benchmarks around that you see claiming Java is faster than C will use an example of a program that creates and destroys objects in a tight loop. The C program will be as written with tons of calls to malloc/free, the Java program will simply reuse the same parts of memory again and again without any system calls. These benchmarks are a bit misleading as the C program isn't optimised with memory re-use whereas the Java Garbage collector tends to do that implicitly.
Just so people know, the arrest of that Rio Tinto executive happened days after the Chinese government company Baosteel failed in a bid to take over the Australian Rio Tinto company.
http://www.guardian.co.uk/business/2007/dec/04/riotinto.china
Essentially the message is, if you move your company to China you agree to everything they want, takeover offers, cheaper pricing etc. Otherwise you will be arrested.
I'm not sure why i'm being modded down here. Speak up someone.
Bing maps doesn't require Silverlight. I'm looking at it right now on a non-Silverlight machine.
"Bing seems nice, but Moonlight crashes the browser on any machine I use"
That doesn't make any sense. Why use moonlight for a JavaScript application?
Newegg were on top of this pretty early.
They never denied there being a problem although they took a day to figure out what was happening.
They have already apologized, announced they are sending out replacements and announced they are getting a new distributor a couple of days ago.
People are going to call you paranoid for that but it's pretty much true. Sodium Nitrite's one of the first that comes to mind.
Sodium Nitrite has medical uses but to get the chemical approved for use as a treatment it has to go through a ton of tests.
It is also used as a food preservative. For use in food the chemical is allowed until it is proven harmful.
http://en.wikipedia.org/wiki/Sodium_nitrite
You still need bind variables mentioned by the gp if using HQL.
http://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection
You already trust them 100% if you let them have access to your box
/That sounded wrong somehow
I have made DirectX games a long time ago but apart from simple examples i haven't looked into shaders much. I actually had a look just then and you are right. Obviously by design they don't allow any shaders (even the compute shaders) to access memory using pointers. So you can't arbitrarily write to some memory location on the system bus as i feared. It's obvious they wouldn't allow that even on trusted applications as your could break the whole trust system locally even. I feel silly now.
I still have an issue of the DirectX API as a whole running through the browser though.
Let me put it this way; this game API allows you to write a game, get inputs from the user, presumably via DirectX's direct input (it does imply full DirectX11 support in the blurb) and send out network outputs based on those inputs. Now i know for a fact Direct Input is very useful for capturing all keyboard input, if a key is down direct input can record that even if the current application is running in the background. Perfect for a keylogger.
There's so many little things like this they'll have to deal with before exposing the DirectX API to the web.
Shaders these days are fully programmable and DirectX allows access to them. I can't see any reason why a shader run off of a webpage couldn't do whatever it wants.
Graphics cards don't have any privilege ring security like x86s do. They simply trust that whatever shader that is sent to run on them is as trusted as the application running on the CPU that sends them the shader.
With this plan your browser will be sending your graphics card shaders to run from whatever website you visit.
Either they are going to have to prune the API down a lot before it is safe (without shaders you may as well be using an earlier version of DirectX), or they are going to have a security nightmare.
That's why the minimum wage should be higher. If everyone was paying a livable wage you wouldn't be paying extra from one gas station to the next.
No, pretty much all a card skimmer does is record the data on the magnetic stripe.
They don't care what the data is or how the machine uses that data.
A typical mag card reader that you can legally buy off the shelf will happily record the info on your drivers license or preferred customer card every bit as easily as on your credit card. Mag stripe cards have the data in plain ASCII text, credit cards included.
If you've ever written a program that reads text data off a serial port and saves that data to a file you have all the knowledge you need to create a credit card skimmer that won't get confused based on what card is inserted.
The Royal Society that funded both Cook and Darwin was a privately established organisation.
It receives some funding from government grants but i think National Geographic does too. So essentially both organisations historically fill the same niche for different countries.
No, the small intestine uses alkaline digestion passed to it by the pancreas.
http://en.wikipedia.org/wiki/Pancreatic_juice
What chemicals are in these plants that give them insecticide properties? Finding a chemical that harms insects but doesn't harm humans is a tricky problem and it's why fly spray companies and the like have R&D departments.
If they are releasing a new never before ingested product onto the market shouldn't they be forced into similar regulations as pharmaceuticals?