A used HP LaserJet 4/4+ can often be had for $50. Plus, these things are built like tanks. They last forever and are more than adequate for home office printing needs. I have had one of these for the past four years, and never regretted it. If one of the parts wear down, such as the paper roller assembly, replacing them tends to be cheap and easy, as well.
Are you aware that Telltale Games is trying to recreate Sam & Max adventure games in 3D, and so far is doing a fine job of it? The latest episode, "Reality 2.0," is both uproariously funny and fun to play, especially for old-school gamers. The previous epsiode, "Abe Lincoln Must Die!" is also great fun.
I will grant you that packaging up a product in a Windows installer is a nice thing to have. However, from my point of view developer-friendly also means how easily you can integrate third-party libraries into your application, and in this area Linux has a huge advantage over Windows for a simple reason: there is a standardized ABI for Linux.
On Windows, it is a huge pain to link anything to your applicaton that is not written in plain C. Someone else above already mentioned the Boost libraries. STLPort is another case in point. A C++ project of mine uses libpng, libz, some 3rd-party Fortran code, and lapack. Try linking binaries or even self-compiled versions of these into a Visual Studio project, and you soon will go nuts. Fortran libraries are especially bad, since every Fortran compiler out there seems to have its own conventions for how to do things.
I ended up having to package the source code for libpng, libz, and f2c within the Visual Studio source tree, and dropping lapack altogether in the Windows port. That way, I could at least share the code with a developer who does only Windows. Never mind that he loses numeric stability and performance because of this...
When I tested a 3G phone in Sweden, I was able to hold a conversation, but the frame rates were barely at the low limit of what is intelligible. While this is better than what we have in the USA right now, higher framerates or level of detail in the face would make comprehension much easier, and also cause less strain, as you need to concentrate less to understand the message.
There is no reason that this technology can't be applied to 3G phones, as well, to make sign language conversations even better and more usable.
Sign language using deaf people overwhelmingly prefer to use video if it is available, for the same reasons that hearing people generally prefer a voice talk over having a text conversation. The only reason that the Sidekick and Blackberry are so popular among the deaf in the USA right now is that the US wireless networks are too slow to support signing.
In Sweden and Denmark, where 3G is widely available, it is a whole different world. About *everyone* in the deaf community there uses wireless video on a cell phone to communicate. More evidence: The Sorenson videophones have almost totally displaced TTYs and made a serious dent into instant text messaging. Video blogging has exploded in popularity here, as well, especially since the ruckus around the selection of Gallaudet's 9th president. Rest assured, once signing over wireless video becomes viable in the USA, text messaging will be relegated to a niche among the signing deaf community.
There is a simple reason why deaf people prefer the VP-100 and VP-200 over video chats: Ease of use. The Sorenson phone instantly boots up if it is turned on, allows you to plug in a flasher, so that you can see when it rings, there are no complicated menus and setups to navigate through, and making a relay call is just a button away. All these things may seem like little nits individually, but add them up, and there is just no contest between a computer and a dedicated device like the VP-100.
Plus, being able to use the large TV screen is nice, too.
You just set the phone flat on the table in front of you and angle up the top part, which contains the camera and the display. There is nothing magic about this - deaf users in Sweden do this all the time with their 3G phones.
Some people also hold it with their left hand in front of them and sign with their right. Although signed languages use both hands, deaf people can hold a perfectly intelligible conversation signing with just one hand.
Are you sure that the bookkeeping is the limiting factor in your program? It could also be that you simply run into a memory bandwidth bottleneck. When you have datasets that do not fit in the L2 cache, main memory simply cannot keep up with the amount of data that the CPUs chew through. With multiple cores that all share the same memory link, this problem is going to become only worse.
One more argument in favor of the AMD Opteron architecture, even though for single-threaded applications it is currently slower than Intel's best offerings. At least with the Opteron, you can have dedicated memory for each node.
Don't forget general-purpose GPU computing. For those highly parallelizable applications that do not need to conform to the full IEEE-754 floating point specs, this card is a dream come true.
Yes, a lot of people prefer firing up their webcam or their videophone over textual communication, often for similar reasons why hearing people prefer the phone, but not limited to these.
Also, there are a lot of deaf people who feel far more comfortable with signed languages than with written text. Sadly, literacy is still a big, and contentious, issue in deaf education.
Several examples to back up my point:
In the USA, Internet-based videophones and video relay services have almost completely displaced text telephones, and are preferred over IM for interactive communication.
In Sweden and Denmark, the G3 mobile standard is offered at a very low cost to the deaf population. Deaf people use their cell phones to communicate with each other all the time, despite the fact that framerates still suck, albeit less so than in the USA.
There has been high demand for allowing video content in deaf-oriented discussion forums.
Vblogs are getting hammered like crazy with the turmoil going on at Gallaudet University
If this directive passes, it will severely restrict freedom of speech and expression among deaf sign language users. In the past year or so, sign language videos and video blogs have exploded in popularity and are well on their way to become the primary means of sharing information across the Internet among the deaf.
Video communication would be severely curtailed, compared to voice communication. As ridiculous as it may sound, one unintended consequence of this directive would thus be discrimination against a specific disability, which itself is prohibited under EU law. This needs to be fought tooth and nail, for more than just free speech reasons.
I second the recommendation of this book. Many of the negative reviews on Amazon seem to bemoan that the author shows a sentence classified as bad or ugly, and then shows a sentence with a different topic as an example of good writing, instead of showing how to fix the original sentence. If you belong to the category of people who learn second languages intuitively and by exposure, this is actually a good thing! Otherwise, the Chicago Manual of Style is not a bad choice, I guess.
Sorry, now I have to nitpick. People who use facial expressions incorrectly *are* unintelligible, depending on what function the expression has, because facial expressions function in roles other than paralinguistic.
For instance:
- negation: in ASL the manual marker for "NOT" is optional. The associated facial expression is mandatory. If the manual sign is omitted, the facial expression must extend over the clause being negated.
- temporal: eye aperture can indicate whether an action took place in the past. There is at least one documented instance of where an interpreter misrepresented what a client said in court, because the interpreter was not aware of this usage.
- adverbial: a facial expression modifies the meaning of the verb
- topic marker: essential to denote the subject of the sentence if the word order is any other than SVO.
flags[BB] = BUSY;/* CPU AA clears its BUSY flag at this point in time, so, the while (flags[AA] == BUSY) terminates immediately */ consume(resource);
The problem is that AA is free to reorder its writes. So, the actual order could be:
flags[AA] = FREE;/* from AA */ flags[BB] = BUSY;/* from BB */ consume(resource);/* BB uses the resource */ resource = result of produce_something() call/* writeback from AA is too late */
Oops. BB accesses the resource before AA writes back the current state. Cache coherency does not solve this problem - the problem is that the write to the resource is still pending. That is what the memory barrier is there for.
Argue with facts, don't hide behind oh-so-impressive credentials.
Yeah, this algorithm is fast. Too bad that it does not work. This kind of design is a common mistake by people who do not understand the intricacies of multithreaded programming. In short, it fails miserably when the CPUs are allowed to reorder loads and stores, a.k.a. pretty much any modern CPU. You need a memory barrier between setting and testing of a shared variable.
Google for Dekker's algorithm and memory barrier - you will find better explanations of the problem there than I could type up in my limited time here right now.
SVK works well with subversion, and has support for star merges. The ability to work offline is another cool bonus.
On the flip side, documentation kinda sucks right now, but its command set for every day use works in pretty much the same way as subversion's.
Blitz++'s templates are so convoluted that they cause the compiler to spit out impossible-to-read error messages when something goes wrong during the template instantiation, due to a type mismatch or such. Compare this to Fortran, which gives you a nice one-line error messsage, and it should be obvious why Fortran is still the language of choice for scientific computing.
We tried. Despite our best efforts, our conclusion is that Blitz++ may be fast, but ultimately constitutes an academic exercise that demonstrates the expressive power of templates, which has nothing to do with being usable. We ended up using MTL instead, and eventually replaced that with a mixture of Lapack and our own in-house vector and matrix classes. These perhaps do not reach the speed of Blitz++, but are easier to use, and most important, a hundred times easier to debug.
Slashdot Mirror
A used HP LaserJet 4/4+ can often be had for $50. Plus, these things are built like tanks. They last forever and are more than adequate for home office printing needs. I have had one of these for the past four years, and never regretted it. If one of the parts wear down, such as the paper roller assembly, replacing them tends to be cheap and easy, as well.
This ticket contains a patch that more or less allows you to use Wordpress blogs with UTF-8 encodings.
Good luck in supporting EU member countries such as Bulgaria or Greece, then. You will need it.
Are you aware that Telltale Games is trying to recreate Sam & Max adventure games in 3D, and so far is doing a fine job of it? The latest episode, "Reality 2.0," is both uproariously funny and fun to play, especially for old-school gamers. The previous epsiode, "Abe Lincoln Must Die!" is also great fun.
I will grant you that packaging up a product in a Windows installer is a nice thing to have. However, from my point of view developer-friendly also means how easily you can integrate third-party libraries into your application, and in this area Linux has a huge advantage over Windows for a simple reason: there is a standardized ABI for Linux.
...
On Windows, it is a huge pain to link anything to your applicaton that is not written in plain C. Someone else above already mentioned the Boost libraries. STLPort is another case in point. A C++ project of mine uses libpng, libz, some 3rd-party Fortran code, and lapack. Try linking binaries or even self-compiled versions of these into a Visual Studio project, and you soon will go nuts. Fortran libraries are especially bad, since every Fortran compiler out there seems to have its own conventions for how to do things.
I ended up having to package the source code for libpng, libz, and f2c within the Visual Studio source tree, and dropping lapack altogether in the Windows port. That way, I could at least share the code with a developer who does only Windows. Never mind that he loses numeric stability and performance because of this
When I tested a 3G phone in Sweden, I was able to hold a conversation, but the frame rates were barely at the low limit of what is intelligible. While this is better than what we have in the USA right now, higher framerates or level of detail in the face would make comprehension much easier, and also cause less strain, as you need to concentrate less to understand the message.
There is no reason that this technology can't be applied to 3G phones, as well, to make sign language conversations even better and more usable.
Sign language using deaf people overwhelmingly prefer to use video if it is available, for the same reasons that hearing people generally prefer a voice talk over having a text conversation. The only reason that the Sidekick and Blackberry are so popular among the deaf in the USA right now is that the US wireless networks are too slow to support signing.
In Sweden and Denmark, where 3G is widely available, it is a whole different world. About *everyone* in the deaf community there uses wireless video on a cell phone to communicate. More evidence: The Sorenson videophones have almost totally displaced TTYs and made a serious dent into instant text messaging. Video blogging has exploded in popularity here, as well, especially since the ruckus around the selection of Gallaudet's 9th president. Rest assured, once signing over wireless video becomes viable in the USA, text messaging will be relegated to a niche among the signing deaf community.
There is a simple reason why deaf people prefer the VP-100 and VP-200 over video chats: Ease of use. The Sorenson phone instantly boots up if it is turned on, allows you to plug in a flasher, so that you can see when it rings, there are no complicated menus and setups to navigate through, and making a relay call is just a button away. All these things may seem like little nits individually, but add them up, and there is just no contest between a computer and a dedicated device like the VP-100.
Plus, being able to use the large TV screen is nice, too.
You just set the phone flat on the table in front of you and angle up the top part, which contains the camera and the display. There is nothing magic about this - deaf users in Sweden do this all the time with their 3G phones.
Some people also hold it with their left hand in front of them and sign with their right. Although signed languages use both hands, deaf people can hold a perfectly intelligible conversation signing with just one hand.
What's wrong with CutePDF?
Then that someone in the back was simply following too closely. Don't they teach about safe following distances in driving school anymore?
Okay, that was a rhetorical question. In the DC area they obviously don't.
Are you sure that the bookkeeping is the limiting factor in your program? It could also be that you simply run into a memory bandwidth bottleneck. When you have datasets that do not fit in the L2 cache, main memory simply cannot keep up with the amount of data that the CPUs chew through. With multiple cores that all share the same memory link, this problem is going to become only worse.
One more argument in favor of the AMD Opteron architecture, even though for single-threaded applications it is currently slower than Intel's best offerings. At least with the Opteron, you can have dedicated memory for each node.
Don't forget general-purpose GPU computing. For those highly parallelizable applications that do not need to conform to the full IEEE-754 floating point specs, this card is a dream come true.
Yes, a lot of people prefer firing up their webcam or their videophone over textual communication, often for similar reasons why hearing people prefer the phone, but not limited to these.
Also, there are a lot of deaf people who feel far more comfortable with signed languages than with written text. Sadly, literacy is still a big, and contentious, issue in deaf education.
Several examples to back up my point:
If this directive passes, it will severely restrict freedom of speech and expression among deaf sign language users. In the past year or so, sign language videos and video blogs have exploded in popularity and are well on their way to become the primary means of sharing information across the Internet among the deaf.
Video communication would be severely curtailed, compared to voice communication. As ridiculous as it may sound, one unintended consequence of this directive would thus be discrimination against a specific disability, which itself is prohibited under EU law. This needs to be fought tooth and nail, for more than just free speech reasons.
I second the recommendation of this book. Many of the negative reviews on Amazon seem to bemoan that the author shows a sentence classified as bad or ugly, and then shows a sentence with a different topic as an example of good writing, instead of showing how to fix the original sentence. If you belong to the category of people who learn second languages intuitively and by exposure, this is actually a good thing! Otherwise, the Chicago Manual of Style is not a bad choice, I guess.
What is so bad about the Tyan motherboards, e.g. the Thunder K8W? Rock solid, and quite fast.
Sorry, now I have to nitpick. People who use facial expressions incorrectly *are* unintelligible, depending on what function the expression has, because facial expressions function in roles other than paralinguistic.
...
For instance:
- negation: in ASL the manual marker for "NOT" is optional. The associated facial expression is mandatory. If the manual sign is omitted, the facial expression must extend over the clause being negated.
- temporal: eye aperture can indicate whether an action took place in the past. There is at least one documented instance of where an interpreter misrepresented what a client said in court, because the interpreter was not aware of this usage.
- adverbial: a facial expression modifies the meaning of the verb
- topic marker: essential to denote the subject of the sentence if the word order is any other than SVO.
And so on
nt
See this: http://www.cits.rub.de/MD5Collisions/
It demonstrates the generation of two postscript files with the same MD5 hash that nevertheless display completely differently.
You don't get it about out-of-order writes, do you? Simple scenario, according to your algorithm:
/* CPU AA clears its BUSY flag at this point in time, so, the while (flags[AA] == BUSY) terminates immediately */
/* from AA */ /* from BB */ /* BB uses the resource */ /* writeback from AA is too late */
CPU AA:
resource = produce_something();
turn = BB;
flags[AA] = FREE;
CPU BB:
flags[BB] = BUSY;
consume(resource);
The problem is that AA is free to reorder its writes. So, the actual order could be:
flags[AA] = FREE;
flags[BB] = BUSY;
consume(resource);
resource = result of produce_something() call
Oops. BB accesses the resource before AA writes back the current state. Cache coherency does not solve this problem - the problem is that the write to the resource is still pending. That is what the memory barrier is there for.
Argue with facts, don't hide behind oh-so-impressive credentials.
Yeah, this algorithm is fast. Too bad that it does not work. This kind of design is a common mistake by people who do not understand the intricacies of multithreaded programming. In short, it fails miserably when the CPUs are allowed to reorder loads and stores, a.k.a. pretty much any modern CPU. You need a memory barrier between setting and testing of a shared variable.
Google for Dekker's algorithm and memory barrier - you will find better explanations of the problem there than I could type up in my limited time here right now.
Have you tried a *recent* version of SVK?
SVK works well with subversion, and has support for star merges. The ability to work offline is another cool bonus. On the flip side, documentation kinda sucks right now, but its command set for every day use works in pretty much the same way as subversion's.
Blitz++'s templates are so convoluted that they cause the compiler to spit out impossible-to-read error messages when something goes wrong during the template instantiation, due to a type mismatch or such. Compare this to Fortran, which gives you a nice one-line error messsage, and it should be obvious why Fortran is still the language of choice for scientific computing.
We tried. Despite our best efforts, our conclusion is that Blitz++ may be fast, but ultimately constitutes an academic exercise that demonstrates the expressive power of templates, which has nothing to do with being usable. We ended up using MTL instead, and eventually replaced that with a mixture of Lapack and our own in-house vector and matrix classes. These perhaps do not reach the speed of Blitz++, but are easier to use, and most important, a hundred times easier to debug.