You can use the arrow keys for scrolling without too much trouble in addition to panning by clicking on the minimap. It's one of the more windowed-mode friendly games I've played, really.
Most normal PDF readers (incl. Okular) only work when the actual text is included in the PDF to begin with. When the source isn't computer-generated but scanned in, there's only image data to work with (no text). Actual OCR is pretty much the only choice in this case...
You joke, but sometimes complete rewrites aren't such a bad thing. I recently rediscovered a game that I had enjoyed playing with a few years back that was basically dead. As a short summer project I spent some time rewriting it in my language of choice, doing some major code refactoring as well (C to OO can be an interesting conversion!). In the end I came away with an awesome understanding of the original code (it's OSS)
I just checked the Gizmo5 size, and I can't say that I see what everybody is complaining about. The Linux client is still prominently displayed on the download page, although I imagine it wasn't there when the article was published. Even so, looking at the release date, I think I can see why they've been considering removing it- its still at version 3 which was released in 2007.
Still, I've yet to find a phone that doesn't do this. My Palm Centro gets quite hot when using the antenna for any extended period of time (streaming a video or something). Every now and then it gets so hot I have to pull the battery out to wait for it to cool down.
Maybe the pink glow is a creative way to make the best out of an unavoidable problem?:)
I'm glad to hear that Firefox has finally improved its memory usage. Although my system has plenty of memory, I still find that the amount of memory FF3 requires causes a very annoying slowdown.
Of late, I've been using Midori as an alternative. With it's current git version and a recent WebKit build (r44951), I've found it to perform better than any other browser I've used (opera, konqueror, firefox). Although it does have a few minor kinks, it supports pretty much every site I've come across and works considerably better with mozilla plugins (namely, flash) than Konqueror and Opera.
Currently with an instance I've been using for the last few days, Midori is using 77 MBs of memory (for comparison, my other running browsers: opera- 120 MBs, Konqueror- 91 MBs, Firefox- 119 MBs). I didn't do any even moderately sophisticated benchmarks suck as those in the article, but that beats the average and final amounts of memory of FF3.5 as shown in the article. Obviously this is not Windows-friendly, but I'd say Midori deserves some more attention, considering that (for me, at least) it outperforms all the other major browsers.
I've been using NetBeans lately for C/C++ development, and (for the most part) it has it's usual awesome editor features. Unfortunately, the C/C++ plugin only works with the Cygwin/MinGW development tools on Windows.
I'd say that it's most useful editing feature is it's code completion- it completes quite a few of the usual syntactical characters, and it enters them for you in a way that makes sense. Compare that to Eclipse, which only fills in (as far as I know) parenthesis and some brackets. Being accustomed to the completion NetBeans offers, I found the way Eclipse completes characters to be more frustrating than helpful.
For example, if you have this mostly-typed statement (')' autocompleted by editor):
some_function(something()[cursor]) ...you might think that pressing the ';' key should make the cursor jump to the end and skip over the ')'. NetBeans will do the small things like this, where I haven't seen Eclipse do it.
I haven't used Eclipse as much as NetBeans, so I may have missed the "turn this feature on" checkbox, but I've always found NetBeans to be a more intuitive editor. I'm not an expert C/C++ programmer (Java is my main language), so I could just be making assumptions that may be true for one language but not another. Either way, its just my $0.02.
I only pay for an unlimited data plan through Sprint, but I can use DUN over bluetooth for free with my Palm Centro. I would only have to pay an additional cost to use a cable and "special" (windows only!) software.
I just:
# rfcomm connect 0 3 &
# wvdial
...And I can get pretty fast connections (around 200 KB/s). My only issue is that wvdial disconnects a lot, so I just run the command in an infinite loop.
Notice at 00:24 in the second video- where the program run is named "decode8char". The decoded word was "password", which was 8 characters long.
Its possible that they needed it to stop after n characters (possibly to disable the antenna in some way?), where ctrl+c would just stop the program.
Also, I would imagine decoding the characters would take a fair amount of time- there can be a LOT of noise to sift through.
I don't know what the sensor looks like, but I'd imagine it would be somewhat difficult to put it on shoelaces:)
Anyway, from the article:
Since only authorized garments are configured to electronically pair with authenticated sensors, a user (or manufacturer) can be assured that the sensing data received by the sensor is both accurate and consistent with its intended use (a sensor designed for use with running shoes can not properly be used with dance shoes, for example).
That actually makes sense- its really just a check to ensure calculations are accurate. But I would hardly think that it is patent worthy.
Still, the actual patent application doesn't even mention DRM, or that it tries to prevent "sneaker hacking"- its just validating data.
Jython is a scripting language in java (see the Java scripting project). As per the specification for Java scripting languages, you can run Java code just like code written in the scripting language (jython, in this case)
I can't help but agree. Unfortunately, I don't think many people are able to get over themselves while trying to analyze the differences.
A prior post stated:
BSD ensures freedom of the *producer* of the code to do what they want.
- GPL ensures freedom of the *recipient* of the code to do what they want.
A later post stated, in response:
It would be the other way around.
(sorry about referencing, but I thought this fit better here; see the original context.)
The problem here is that they are both right. What some people don't seem to realize (or just ignore) is that neither license is fully restrictive to either the "producer" or the "recipient", and that seems to be the main argument. This flamewar, despite everyone's trying to get past their differences of opinion, is simply stating the same thing, albeit with some occasional added insight.
Ask yourself, what's keeping Linux from taking over? All those Windows applications that people need to be able to run. If Linux ever displaces Windows, most of its users will be running software on top of WINE. And developers will be able to target Linux without learning a new API.
WINE could easily outlive the platform it was designed to emulate. Emulators often do.
I agree- theres a few games I can only play on emulators that were written on systems like the Commodore 64, Windows 3.1, and so on.
I'd say the same for the NES, but I still have a working console:)
Other than porting, compatibility layers or emulators are the best ways to keep old software running. Instead of wasting time porting each and every program, you can write a single program that can essentially make everything work.
There's nothing wrong with backwards compatibility, but I think that there are better ways than going about it than others (emulators, compatibility layers, etc).
Slashdot Mirror
Seriously. I'd bet it's only a trial, too.
You can use the arrow keys for scrolling without too much trouble in addition to panning by clicking on the minimap. It's one of the more windowed-mode friendly games I've played, really.
Most normal PDF readers (incl. Okular) only work when the actual text is included in the PDF to begin with. When the source isn't computer-generated but scanned in, there's only image data to work with (no text). Actual OCR is pretty much the only choice in this case...
You joke, but sometimes complete rewrites aren't such a bad thing. I recently rediscovered a game that I had enjoyed playing with a few years back that was basically dead. As a short summer project I spent some time rewriting it in my language of choice, doing some major code refactoring as well (C to OO can be an interesting conversion!). In the end I came away with an awesome understanding of the original code (it's OSS)
I just checked the Gizmo5 size, and I can't say that I see what everybody is complaining about. The Linux client is still prominently displayed on the download page, although I imagine it wasn't there when the article was published. Even so, looking at the release date, I think I can see why they've been considering removing it- its still at version 3 which was released in 2007.
Seriously, what sort of article is this? The "generation" this story so fondly speaks of accounts for a pretty significant portion of the /. crowd.
Still, I've yet to find a phone that doesn't do this. My Palm Centro gets quite hot when using the antenna for any extended period of time (streaming a video or something). Every now and then it gets so hot I have to pull the battery out to wait for it to cool down.
Maybe the pink glow is a creative way to make the best out of an unavoidable problem? :)
I'm glad to hear that Firefox has finally improved its memory usage. Although my system has plenty of memory, I still find that the amount of memory FF3 requires causes a very annoying slowdown.
Of late, I've been using Midori as an alternative. With it's current git version and a recent WebKit build (r44951), I've found it to perform better than any other browser I've used (opera, konqueror, firefox). Although it does have a few minor kinks, it supports pretty much every site I've come across and works considerably better with mozilla plugins (namely, flash) than Konqueror and Opera.
Currently with an instance I've been using for the last few days, Midori is using 77 MBs of memory (for comparison, my other running browsers: opera- 120 MBs, Konqueror- 91 MBs, Firefox- 119 MBs). I didn't do any even moderately sophisticated benchmarks suck as those in the article, but that beats the average and final amounts of memory of FF3.5 as shown in the article. Obviously this is not Windows-friendly, but I'd say Midori deserves some more attention, considering that (for me, at least) it outperforms all the other major browsers.
I've been using NetBeans lately for C/C++ development, and (for the most part) it has it's usual awesome editor features. Unfortunately, the C/C++ plugin only works with the Cygwin/MinGW development tools on Windows.
I'd say that it's most useful editing feature is it's code completion- it completes quite a few of the usual syntactical characters, and it enters them for you in a way that makes sense. Compare that to Eclipse, which only fills in (as far as I know) parenthesis and some brackets. Being accustomed to the completion NetBeans offers, I found the way Eclipse completes characters to be more frustrating than helpful.
For example, if you have this mostly-typed statement (')' autocompleted by editor):
...you might think that pressing the ';' key should make the cursor jump to the end and skip over the ')'. NetBeans will do the small things like this, where I haven't seen Eclipse do it.
some_function(something()[cursor])
I haven't used Eclipse as much as NetBeans, so I may have missed the "turn this feature on" checkbox, but I've always found NetBeans to be a more intuitive editor. I'm not an expert C/C++ programmer (Java is my main language), so I could just be making assumptions that may be true for one language but not another. Either way, its just my $0.02.
I only pay for an unlimited data plan through Sprint, but I can use DUN over bluetooth for free with my Palm Centro. I would only have to pay an additional cost to use a cable and "special" (windows only!) software.
...And I can get pretty fast connections (around 200 KB/s). My only issue is that wvdial disconnects a lot, so I just run the command in an infinite loop.
I just:
# rfcomm connect 0 3 &
# wvdial
Notice at 00:24 in the second video- where the program run is named "decode8char". The decoded word was "password", which was 8 characters long.
Its possible that they needed it to stop after n characters (possibly to disable the antenna in some way?), where ctrl+c would just stop the program. Also, I would imagine decoding the characters would take a fair amount of time- there can be a LOT of noise to sift through.
Anyway, from the article:
Since only authorized garments are configured to electronically pair with authenticated sensors, a user (or manufacturer) can be assured that the sensing data received by the sensor is both accurate and consistent with its intended use (a sensor designed for use with running shoes can not properly be used with dance shoes, for example).
That actually makes sense- its really just a check to ensure calculations are accurate. But I would hardly think that it is patent worthy.
Still, the actual patent application doesn't even mention DRM, or that it tries to prevent "sneaker hacking"- its just validating data.
Jython is a scripting language in java (see the Java scripting project). As per the specification for Java scripting languages, you can run Java code just like code written in the scripting language (jython, in this case)
I can't help but agree. Unfortunately, I don't think many people are able to get over themselves while trying to analyze the differences.
A prior post stated:
BSD ensures freedom of the *producer* of the code to do what they want. - GPL ensures freedom of the *recipient* of the code to do what they want.
A later post stated, in response:
It would be the other way around.
(sorry about referencing, but I thought this fit better here; see the original context.)
The problem here is that they are both right. What some people don't seem to realize (or just ignore) is that neither license is fully restrictive to either the "producer" or the "recipient", and that seems to be the main argument. This flamewar, despite everyone's trying to get past their differences of opinion, is simply stating the same thing, albeit with some occasional added insight.
Ask yourself, what's keeping Linux from taking over? All those Windows applications that people need to be able to run. If Linux ever displaces Windows, most of its users will be running software on top of WINE. And developers will be able to target Linux without learning a new API.
WINE could easily outlive the platform it was designed to emulate. Emulators often do.
I agree- theres a few games I can only play on emulators that were written on systems like the Commodore 64, Windows 3.1, and so on.
I'd say the same for the NES, but I still have a working console :)
Other than porting, compatibility layers or emulators are the best ways to keep old software running. Instead of wasting time porting each and every program, you can write a single program that can essentially make everything work.
There's nothing wrong with backwards compatibility, but I think that there are better ways than going about it than others (emulators, compatibility layers, etc).