You might need a current version of the setup.prc since it's been awhile (though I doubt that would be the problem here).
Remove any firewalls that your computer might be running.
Also, make sure that the USB box under connections in Hotsync Manager (for Windows) is not checked off, only Network (TCP/IP) should be checked.
Good luck.
Addison,
Lol, guess I'm a noobier (is noob a word? Is noobier a word?) user than I previously thought. I'd been attempting to use an older method to install epocrates (attempting to do it directly from the internal SD card) which had worked for me before. Hotsyncing worked like a charm, though. Thank you!
Anyone with the inside scooper if we'll be seeing a Beta 5?
I'm kind of worried this time around about the expiration date.
I was kind of worried about this also. Then I had an idea, not sure how that happened, I started thinking since the software is data/time aware if you change the daate time on the handheld to a time before the expirations date it starts up and stays running even if you change the time back to the current time while the software is running.
I know the "date" command is available via command line but I could not figure out how to change the date by the command line "date.
It would be fairly easy to write a shell script that would get the current date at time then save as a variable, change the date previous to the expiration, then run the GarnettVM, then at the end of the script change it back to time it is.
If someone here is familiar with options on maemo's date command and can let me know what it is I should be able to write a shell script for it. If there are any volunteers that would be able to write this script I say go for it
If someone here is familiar with options on maemo's date command and can let me know what it is I should be able to write a shell script for it. If there are any volunteers that would be able to write this script I say go for it
That it not a good idea at all. If you change the date like that you will change the date for the whole device, and if you do there are a lot of things that will just stop working.
Many parts of the system (particularly those related to graphics) work something like this:
while (forever) { gettimeofday(); if ((now - then) greater than 5 minutes) then do_something }
If you set the date back then the above will hang forever. I know there's stuff like that in the X server, for example.
Instead, what you want to do is something much more elegant: You write a little library which provides the library calls to the system time functions. Then you use a wrapper script to start the application, but first setting the LD_PRELOAD environment variable to point to this library. It will override the time call(s) in the normal runtime library.
Fortunately this has already been done for you, or at least when someone ports the datefudge or the faketime Debian packages. This can just possibly be done by a simple recompile.
However, if the next beta comes with an expiration date I'm done with GVM, I won't bother with it anymore - I'm out.
The only reason I see for ACCESS not to update GVM is that the N900 is an smartphone now and thus competition to their core market. Which is a good reason IMHO....
That it not a good idea at all. If you change the date like that you will change the date for the whole device, and if you do there are a lot of things that will just stop working.
Many parts of the system (particularly those related to graphics) work something like this:
while (forever) { gettimeofday(); if ((now - then) greater than 5 minutes) then do_something }
If you set the date back then the above will hang forever. I know there's stuff like that in the X server, for example.
Instead, what you want to do is something much more elegant: You write a little library which provides the library calls to the system time functions. Then you use a wrapper script to start the application, but first setting the LD_PRELOAD environment variable to point to this library. It will override the time call(s) in the normal runtime library.
Fortunately this has already been done for you, or at least when someone ports the datefudge or the faketime Debian packages. This can just possibly be done by a simple recompile.
However, if the next beta comes with an expiration date I'm done with GVM, I won't bother with it anymore - I'm out.
Yeah, this is why I was thinking of perhaps rolling back the year and just leaving it like that.
I'll deal with the rest of the fallout from doing that if needed, but without GVM, I'll need to carry around another handheld.
That it not a good idea at all. If you change the date like that you will change the date for the whole device, and if you do there are a lot of things that will just stop working.
Many parts of the system (particularly those related to graphics) work something like this:
while (forever) { gettimeofday(); if ((now - then) greater than 5 minutes) then do_something }
If you set the date back then the above will hang forever. I know there's stuff like that in the X server, for example.
Instead, what you want to do is something much more elegant: You write a little library which provides the library calls to the system time functions. Then you use a wrapper script to start the application, but first setting the LD_PRELOAD environment variable to point to this library. It will override the time call(s) in the normal runtime library.
Fortunately this has already been done for you, or at least when someone ports the datefudge or the faketime Debian packages. This can just possibly be done by a simple recompile.
However, if the next beta comes with an expiration date I'm done with GVM, I won't bother with it anymore - I'm out.
Very good point, I did not think about that. Your idea does sound like a better solution. I will try to look at this in the next few days and see if I can understand it.
Yeah, this is why I was thinking of perhaps rolling back the year and just leaving it like that.
If you do, then you will get into strange problems with web sites that use certificates. For a period we had several problem reports here which turned out to be caused by an unexplained date/time change on the device (i.e. correct the clock, problem fixed). I ran into that once myself too.
Originally Posted by
I'll deal with the rest of the fallout from doing that if needed, but without GVM, I'll need to carry around another handheld.
I definitely understand the problem. I still carry both my T3 and my N800, and I'll probably have to continue doing that for the foreseeable future.
