Slashdot Mirror

When a company decides they are no longer going to spend any money, time or capital on developing a software product, they should immediately re-license it under an Open Source compatible license, and give it away to the community.

THEY may not be interested in developing it any further, but that doesn't mean that WE aren't! (that, and we have already been supporting thousands of their users for over 12 years now).

Message to "New Palm": Get your head out of your ass and do the community some good will, by giving the OS away.. rip out all of the components which are patented and licensed to other incompatible third-parties, and let us rewrite those bits, and FIX the OS to continue to support the userbase.

No problem... let them snoop. Now I'll just be twiddling the "Encrypt and sign all outgoing email" box on my MUA, and finally start using GPG full-time for all of my incoming and outgoing email, instead of with just my friends and close colleagues.

There are plugins for Evolution, pine, mutt, Thunderbird and just about every other Mail User Agent you can find out there.

Another great benefit, is that I can automatically block/quarantine/delete any and all email that does not contain a gpg-signed component (i.e. 99.999% of all email out there, mostly spam). dspam does an amazing job, but being able to just reject it at the MTA level would be great.

And for those that wish to converse with me, please make sure to use my GPG key to do so (also available here with detailed instructions).

Why not just block everyone EXCEPT Firefox users?

What about everyone using IceWeasel on Debian? Is he blocking them too?

What about those using Mozilla, or Epiphany (both using the same XUL and underlying Gecko HTML engine)?

How is he blocking them? By UserAgent? That's assinine, because you can just change it, and be done with it (or remove it altogether).

Why not block MSIE also? Their HTTP request objects are malformed, and they do not follow the specifications. Not to mention, they don't properly support standards, CSS, or HTML properly.

Blocking browsers is futile, and all we ended up doing by posting this to Slashdot, was bring attention to his ad-ridden blog, generating him a ton of cash, negating the whole point in the first place.

Sigh, kids. What they should do, is learn proper SEO, and how to write and market a website properly, to generate actual revenue from people who WANT to click on the ads you present to them. Plenty of my pages are precisely that.

Tip #1: Use a Palm OS device.

I'm sure you realize that PalmOS devices store *ALL* of their data in cleartext, right? Marking those records private and protecting them with a password?

Futile, just fetch the records directly (and pilot-link is the de-facto tool for this) and open it in an editor, or run strings(1) across it to see everything in cleartext.

There are applications, such as GNU/Keyring and others that can help you secure your passwords, memos, data and whatever else you want on PalmOS devices.

In short, never trust the vendor's default application suite to do what you want, or be as secure as you need.

For those of you interested, I'm happily synching the Treo 650 with JPilot over a bluetooth connection to my Laptop running Ubuntu Linux. This article was helpful getting this setup:

http://howto.pilot-link.org/bluesync/fb.html

The keyring software I run to securely store passwords also happily syncs with Jpilot.

"I do know that OpenBSD runs on the PalmOne Treo 600"

I call bullshit. Show me a citation with working links to back up your assertion here please.

The Treo 600 works WITH NetBSD, just like it works with Linux, FreeBSD, and OSX... but the Treo 600 does not RUN NetBSD... and nobody that I know of has ported it over to do so. I would know, I manage this little project, and I'd be one of the first to find this out.

Both KDE and GNOME have sync GUI's if you need that kind of thing.

I've got a clie, and have had a palm V. Most of the Palms are supported I think. Check it out -> http://www.pilot-link.org/

pilot-link has languages bindings for Perl, Python, Java, and TCL. We've got support for the latest Palm handhelds, including the Tungsten T5, LifeDrive and Tungsten E2.

pilot-link supports writing to external storage (SD cards, CompactFlash, MemoryStick), and we support libusb as well for a nice 600% speedup over the standard usb->serial layers present in Linux. Darwinusb uses native usb by default (no serial layers involved).

If you're interested in seeing the code, we've got a public CVS, Doxygenized code output, CVS statistics, and many other things.

Don't forget our mailing lists as well, if you're interested in following the discussions. I've written some detailed HOWTO documents as well to help users with their Palm devices.

I just released 0.12.0-pre4 a few days ago. Try it out... we need feedback and testers. (Bugs go here).

If you want to talk to us real-time, we're out on irc.pilot-link.org in #pilot-link. We'd love to hear from you...

pilot-link has languages bindings for Perl, Python, Java, and TCL. We've got support for the latest Palm handhelds, including the Tungsten T5, LifeDrive and Tungsten E2.

pilot-link supports writing to external storage (SD cards, CompactFlash, MemoryStick), and we support libusb as well for a nice 600% speedup over the standard usb->serial layers present in Linux. Darwinusb uses native usb by default (no serial layers involved).

If you're interested in seeing the code, we've got a public CVS, Doxygenized code output, CVS statistics, and many other things.

Don't forget our mailing lists as well, if you're interested in following the discussions. I've written some detailed HOWTO documents as well to help users with their Palm devices.

I just released 0.12.0-pre4 a few days ago. Try it out... we need feedback and testers. (Bugs go here).

If you want to talk to us real-time, we're out on irc.pilot-link.org in #pilot-link. We'd love to hear from you...

pilot-link has languages bindings for Perl, Python, Java, and TCL. We've got support for the latest Palm handhelds, including the Tungsten T5, LifeDrive and Tungsten E2.

pilot-link supports writing to external storage (SD cards, CompactFlash, MemoryStick), and we support libusb as well for a nice 600% speedup over the standard usb->serial layers present in Linux. Darwinusb uses native usb by default (no serial layers involved).

If you're interested in seeing the code, we've got a public CVS, Doxygenized code output, CVS statistics, and many other things.

Don't forget our mailing lists as well, if you're interested in following the discussions. I've written some detailed HOWTO documents as well to help users with their Palm devices.

I just released 0.12.0-pre4 a few days ago. Try it out... we need feedback and testers. (Bugs go here).

If you want to talk to us real-time, we're out on irc.pilot-link.org in #pilot-link. We'd love to hear from you...

pilot-link has languages bindings for Perl, Python, Java, and TCL. We've got support for the latest Palm handhelds, including the Tungsten T5, LifeDrive and Tungsten E2.

pilot-link supports writing to external storage (SD cards, CompactFlash, MemoryStick), and we support libusb as well for a nice 600% speedup over the standard usb->serial layers present in Linux. Darwinusb uses native usb by default (no serial layers involved).

If you're interested in seeing the code, we've got a public CVS, Doxygenized code output, CVS statistics, and many other things.

Don't forget our mailing lists as well, if you're interested in following the discussions. I've written some detailed HOWTO documents as well to help users with their Palm devices.

I just released 0.12.0-pre4 a few days ago. Try it out... we need feedback and testers. (Bugs go here).

If you want to talk to us real-time, we're out on irc.pilot-link.org in #pilot-link. We'd love to hear from you...

pilot-link has languages bindings for Perl, Python, Java, and TCL. We've got support for the latest Palm handhelds, including the Tungsten T5, LifeDrive and Tungsten E2.

pilot-link supports writing to external storage (SD cards, CompactFlash, MemoryStick), and we support libusb as well for a nice 600% speedup over the standard usb->serial layers present in Linux. Darwinusb uses native usb by default (no serial layers involved).

If you're interested in seeing the code, we've got a public CVS, Doxygenized code output, CVS statistics, and many other things.

Don't forget our mailing lists as well, if you're interested in following the discussions. I've written some detailed HOWTO documents as well to help users with their Palm devices.

I just released 0.12.0-pre4 a few days ago. Try it out... we need feedback and testers. (Bugs go here).

If you want to talk to us real-time, we're out on irc.pilot-link.org in #pilot-link. We'd love to hear from you...

pilot-link has languages bindings for Perl, Python, Java, and TCL. We've got support for the latest Palm handhelds, including the Tungsten T5, LifeDrive and Tungsten E2.

pilot-link supports writing to external storage (SD cards, CompactFlash, MemoryStick), and we support libusb as well for a nice 600% speedup over the standard usb->serial layers present in Linux. Darwinusb uses native usb by default (no serial layers involved).

If you're interested in seeing the code, we've got a public CVS, Doxygenized code output, CVS statistics, and many other things.

Don't forget our mailing lists as well, if you're interested in following the discussions. I've written some detailed HOWTO documents as well to help users with their Palm devices.

I just released 0.12.0-pre4 a few days ago. Try it out... we need feedback and testers. (Bugs go here).

If you want to talk to us real-time, we're out on irc.pilot-link.org in #pilot-link. We'd love to hear from you...

pilot-link has languages bindings for Perl, Python, Java, and TCL. We've got support for the latest Palm handhelds, including the Tungsten T5, LifeDrive and Tungsten E2.

pilot-link supports writing to external storage (SD cards, CompactFlash, MemoryStick), and we support libusb as well for a nice 600% speedup over the standard usb->serial layers present in Linux. Darwinusb uses native usb by default (no serial layers involved).

If you're interested in seeing the code, we've got a public CVS, Doxygenized code output, CVS statistics, and many other things.

Don't forget our mailing lists as well, if you're interested in following the discussions. I've written some detailed HOWTO documents as well to help users with their Palm devices.

I just released 0.12.0-pre4 a few days ago. Try it out... we need feedback and testers. (Bugs go here).

If you want to talk to us real-time, we're out on irc.pilot-link.org in #pilot-link. We'd love to hear from you...

pilot-link has languages bindings for Perl, Python, Java, and TCL. We've got support for the latest Palm handhelds, including the Tungsten T5, LifeDrive and Tungsten E2.

pilot-link supports writing to external storage (SD cards, CompactFlash, MemoryStick), and we support libusb as well for a nice 600% speedup over the standard usb->serial layers present in Linux. Darwinusb uses native usb by default (no serial layers involved).

If you're interested in seeing the code, we've got a public CVS, Doxygenized code output, CVS statistics, and many other things.

Don't forget our mailing lists as well, if you're interested in following the discussions. I've written some detailed HOWTO documents as well to help users with their Palm devices.

I just released 0.12.0-pre4 a few days ago. Try it out... we need feedback and testers. (Bugs go here).

If you want to talk to us real-time, we're out on irc.pilot-link.org in #pilot-link. We'd love to hear from you...

http://pilot-link.org/

pilot-link is a suite of tools used to connect your Palm or PalmOS® compatible handheld with Unix, Linux, and any other POSIX-compatible machine. pilot-link works with all PalmOS® handhelds, including those made by Handspring, Sony, and Palm, as well as others. pilot-link includes userspace "conduits" that allow you to syncronize information to and from your Palm device, as well as libraries of Palm-compatible functions that allow other applications to take advantage of the code included in pilot-link. There are also several language "bindings" that allow you to use your favorite development language with pilot-link, such as Java, Tcl, Perl, and Python.

I've just tried to get my handspring visor to sync with gnome-pilot under CentOS 4 (i.e. RedHat EL4) and it wasn't straight forward, or solvable in a simple google search (mostly because udev is new I guess). Here are the links that helped me out:

http://lists.pilot-link.org/pipermail/pilot-link-g eneral/2004-November/002084.html

http://pilot-link.org/README.usb

I've just tried to get my handspring visor to sync with gnome-pilot under CentOS 4 (i.e. RedHat EL4) and it wasn't straight forward, or solvable in a simple google search (mostly because udev is new I guess). Here are the links that helped me out:

http://lists.pilot-link.org/pipermail/pilot-link-g eneral/2004-November/002084.html

http://pilot-link.org/README.usb

This is terrible. How did this even make it past the /. editors/censors?

My friend, I have one word for you - "google".

Support for PalmOS based units is ROCK SOLID on Linux, especially the USB based units. And it has been for years. I am a PalmPilot user from the 1990s, and while I admit that there were issues in the first few years, today they simply dont exist, not with stuff like Jpilot around. The guys who run the Pilot Link project have been doing fantastic work over the years making sure that things work, and there must be a zillion Linux users out there who benefit daily from their work.

A totally elementary Google search would have brought up EVERYTHING you would need to get things going.

On a tangent - why was this post allowed through in first place? It now sits on the front page of Slashdot, and gives all those guys who never RTFA or read comments more misguidance, leaving them with the impression that what is written in that post is actually true.

And it will poison search engines for a long time, so that anyone who ACTUALLY does a google search before posting gets this post thrown up before any real information.

BAH!

I still use my Palm m125, which I bought in 2002. I use Pilot-Link (I'm a Linux person) and my Sandisk SD card reader to do all my Palm file transfers. Pilot-link is cool, works so much nicer than Palm's crappy desktop application.

"They are very conscious of the GPL and will make sure they are in compliance. I thought I had noticed a GPL violation and got two people there in a panic, only then to realize it was a false alarm. I am satisfied that they understand the problem."

Are you sure about that? I know Sony has been in violation of the GPL for at least 3 years with their infringing use of the PalmOS Emulator source code. I've reported it several times, and they basically said "Go ahead, sue us, we're Sony. Now go away."

Palm very recently released an IDE called "PODS", based on Eclipse, but neglected to properly adhere to the licensing with Eclipse, and the plugins associated with it, which were covered under the GPL, were of course, not shipped with source. Requests for the source were denied by several of my peers, pending "We're trying to release an update with some fixes" or some such response. Of course, this is ridiculous, since the plugins for the released version were already out there, sans source.

I haven't revisited the issue in a few months, and now there is a 1.1 release, but I certainly hope they've cleaned up that issue, and their other underlying internal issues with "borrowing" other parts of projects without proper adherence to the license.

As it stands, there are currently 5 commercial companies openly and knowingly violating the license of pilot-link for example, without any regard for the license or hard work that goes into making such a project function. Calls to those companies are met with failure or ignorance.

I see this time and time again. Instead of working with us, they directly work against us. I just don't understand that business acumen.

We've been down this road already with the GPL case for Plucker v. "Bluefish Wireless" with Wendy, and I really don't want to have to deal with ignorant, incompetent companies like that again (incidentally, that case may be expanding exponentially, since Bluefish is now apparently shipping a suspisciously-compatible version of an app that we found them in violation of the GPL in ROM on these new PalmOS devices. If that turns out to be true, pa1mOne, Palmsource, and Bluefish Wireless are in an enormous world of hurt. We're still investigating the matter.)

"You know, multisync on Linux handles the Palm fine, and the Palm protocols are standards-based."

I'm not sure what Palm devices you're referring to here, but they certainly can't be the ones running PalmOS. Palm's protocol is absolutely, most-definately, NOT standards-based, unless you include that to mean developed using proprietary, undocumented APIs. Everything has to be reverse-engineered using wire-level traces and actual physical devices (the Emulator and Simulator aren't enough, they don't model exactly how certain chipsets deal with packets and framing).

But thanks to our hard work with pilot-link, projects like Multisync can continue to function and talk to Palm devices.

The more we continue to reverse-engineer, the more PalmOS-based devices these kinds of projects can continue to support.

I only hope that this move from Palmsource, includes opening up the bits of their protocol that can enable us to better support them without having to violate the DMCA or tear apart their devices on the wire to do it.

ln -s /dev/ttyUSB0 /dev/pilot

My SuSE install came with several ways to achieve this syncing, but kPilot is likely best for the new folks. The database syncs you asked about work fine, but there is a bug in the Palm's software that prevents my Tungesten T from completely backing up everything (Pilot-link.org says this bug is now fixed, so get a distribution with this updated code). Also more here (scroll down to the section heading 'Synchronising the Palm and the PC').

To date, I know of nothing that does your second request. I generally just use the memo pad, and the text files do transfer across just fine.

Can't help with the last item.

-AD

"Besides the palmone spec page says - full mac support"

We still support more platforms, Palm devices, and other things than Palm themselves supports. Sure, we can't afford to go out and buy every new device the day they're released, but we catch up fast.

We're already significantly faster (20% to 60% in most cases) than Palm's own implementation on OSX and Linux and Unix (three platforms they don't support at all!).

Contrary to what Palm states, they do not support Mac/OSX at all. Mark/Space (endorsed by Palm) does through their MissingSync product, but... Mark/Space's product relies on our code to function. How ironic is that ;)

I use evolution with my sony clie, im using LFS, and I connect with USB. Check out http://www.pilot-link.org. It syncs my contacts, task list, appointments, notes, and sends mail for me. The only catch is I have to press the hotsync button on the cradle BEFORE I start gpilotd (which is backwards accoring to the gpilotd docs). I'm also using udev+hotplug so the ttyUSB devices that are needed arent created until I press the hotsync button, and are removed when the sync is over. I haven't quite figured out how to start gpilotd automatically yet ;)

Hmm, I was hoping to learn something in terms of placement. Your pages look cleaner and less cluttered, but I think the major reason for high rankings has to do with the topic of the Palm howto pages.

For example, going over here I find the ads very relevant and very specific. If I am interested in Palms or Palm development (I am not, since I own a Pocket PC and have done some Zaurus development before) I would definitely click there as the offer "Palm Pilot PDAs cheap" just looks good, even if I am not urgently looking to buy one.

1. Project Sites

   1. gnu-designs, inc.
      Plucker
      Plucker Wiki
      OpenURLs PDA Portal
      pilot-link
      pilot-link Portal
      J-Pilot
      J-Pilot Wiki
      

   HOWTO Documents

   1. Syncronize your PalmOS(R) Handheld with Evolution
      Synchronize your PalmOS(R) Handheld over Bluetooth in Linux
      Syncronizing your PalmOS(R) handheld device over Infrared (IrDA)
      Connecting your PalmOS(R) handheld device to the Internet via PPP
      

1. Project Sites

   1. gnu-designs, inc.
      Plucker
      Plucker Wiki
      OpenURLs PDA Portal
      pilot-link
      pilot-link Portal
      J-Pilot
      J-Pilot Wiki
      

   HOWTO Documents

   1. Syncronize your PalmOS(R) Handheld with Evolution
      Synchronize your PalmOS(R) Handheld over Bluetooth in Linux
      Syncronizing your PalmOS(R) handheld device over Infrared (IrDA)
      Connecting your PalmOS(R) handheld device to the Internet via PPP
      

1. Project Sites

   1. gnu-designs, inc.
      Plucker
      Plucker Wiki
      OpenURLs PDA Portal
      pilot-link
      pilot-link Portal
      J-Pilot
      J-Pilot Wiki
      

   HOWTO Documents

   1. Syncronize your PalmOS(R) Handheld with Evolution
      Synchronize your PalmOS(R) Handheld over Bluetooth in Linux
      Syncronizing your PalmOS(R) handheld device over Infrared (IrDA)
      Connecting your PalmOS(R) handheld device to the Internet via PPP
      

1. Project Sites

   1. gnu-designs, inc.
      Plucker
      Plucker Wiki
      OpenURLs PDA Portal
      pilot-link
      pilot-link Portal
      J-Pilot
      J-Pilot Wiki
      

   HOWTO Documents

   1. Syncronize your PalmOS(R) Handheld with Evolution
      Synchronize your PalmOS(R) Handheld over Bluetooth in Linux
      Syncronizing your PalmOS(R) handheld device over Infrared (IrDA)
      Connecting your PalmOS(R) handheld device to the Internet via PPP
      

1. Project Sites

   1. gnu-designs, inc.
      Plucker
      Plucker Wiki
      OpenURLs PDA Portal
      pilot-link
      pilot-link Portal
      J-Pilot
      J-Pilot Wiki
      

   HOWTO Documents

   1. Syncronize your PalmOS(R) Handheld with Evolution
      Synchronize your PalmOS(R) Handheld over Bluetooth in Linux
      Syncronizing your PalmOS(R) handheld device over Infrared (IrDA)
      Connecting your PalmOS(R) handheld device to the Internet via PPP
      

1. Project Sites

   1. gnu-designs, inc.
      Plucker
      Plucker Wiki
      OpenURLs PDA Portal
      pilot-link
      pilot-link Portal
      J-Pilot
      J-Pilot Wiki
      

   HOWTO Documents

   1. Syncronize your PalmOS(R) Handheld with Evolution
      Synchronize your PalmOS(R) Handheld over Bluetooth in Linux
      Syncronizing your PalmOS(R) handheld device over Infrared (IrDA)
      Connecting your PalmOS(R) handheld device to the Internet via PPP
      

pilot-link has Python bindings which may jumpstart you towards making it work well. You might have to make changes to the core C sources to support these new devices, but the baseline working code is already there.

You could always help us with pilot-link to get it working properly for these devices. It builds fine, it works with serial devices on OSX, and it supports these newer Palm devices. The only piece missing is the IOKit changes to make it work with the OSX'ish USB device notification.

CondMgr.dll
HSAPI.dll
install.js
mozABConduit.dll
palmsync.dll
PalmSyncInstall.exe
PalmSyncProxy.dll
palmSync.xpt

That obviously won't work on OSX, FreeBSD and Linux systems. I've been working on the SDK for pilot-link, but it isn't quite ready yet... that doesn't mean it can't be used to develop a cross-platform conduit to do this, however, or even a Java-based one (Yes, we support that too!).

This brings us much closer though.

"Of course, my decision was really made for me this time 'round: I use a Mac at home, and Palm is the only company that really supports Mac OS"

Don't be so sure. Their partners are dropping Mac support like flies. Metrowerks has already dropped their Mac support for their CodeWarrior IDE for PalmOS development, orphaning off the Mac developers. Expect to see more and more of this in the very near future.

Thankfully, many of them are beginning to see that there IS still support for Linux, Unix, Mac/OSX, and Windows users, through a Free Software project called pilot-link, so they're moving in that direction instead.

Free, Open, Available, and most-of-all, friendly. Many things Palm and partners are not.

This isn't needed anymore.

Actually, this has absolutely nothing to do with pilot-link. It has to do with the way USB on any hardware is handled. You have to make the physical electrical connection between Palm handheld and Cradle before the hardware (your computer) can see the device, map a driver against the device, and allow you to communicate across it.

That being said, the pilot-link maintainer (hey, that's me!) has fixed this in a pseudo-fashion by adding a sleep() loop in the latest CVS code that I can see, which means you can launch pilot-link first, or hit the HotSync button on your Palm/Cradle first, and it will "Just Work".

KDE's Kpilot works like this, Gnome has a similar application too.

Both of these tools, built on top of the libraries provided by pilot-link, provide their own daemon process; kpilotDaemon from KPilot in KDE-land, and gnome-pilot (gpilotd) in GNOME-land, which polls for device creation in /proc, and binds accordingly.

Other than being built upon pilot-link, these applications have nothing whatsoever to do with the pilot-link codebase. This means, for those who don't run GNOME or KDE (a growing percentage from what I understand), this is not an option, so they use pilot-link and J-Pilot (also built upon libraries provided by pilot-link).

This isn't needed anymore.

Actually, this has absolutely nothing to do with pilot-link. It has to do with the way USB on any hardware is handled. You have to make the physical electrical connection between Palm handheld and Cradle before the hardware (your computer) can see the device, map a driver against the device, and allow you to communicate across it.

That being said, the pilot-link maintainer (hey, that's me!) has fixed this in a pseudo-fashion by adding a sleep() loop in the latest CVS code that I can see, which means you can launch pilot-link first, or hit the HotSync button on your Palm/Cradle first, and it will "Just Work".

KDE's Kpilot works like this, Gnome has a similar application too.

Both of these tools, built on top of the libraries provided by pilot-link, provide their own daemon process; kpilotDaemon from KPilot in KDE-land, and gnome-pilot (gpilotd) in GNOME-land, which polls for device creation in /proc, and binds accordingly.

Other than being built upon pilot-link, these applications have nothing whatsoever to do with the pilot-link codebase. This means, for those who don't run GNOME or KDE (a growing percentage from what I understand), this is not an option, so they use pilot-link and J-Pilot (also built upon libraries provided by pilot-link).

This isn't needed anymore.

Actually, this has absolutely nothing to do with pilot-link. It has to do with the way USB on any hardware is handled. You have to make the physical electrical connection between Palm handheld and Cradle before the hardware (your computer) can see the device, map a driver against the device, and allow you to communicate across it.

That being said, the pilot-link maintainer (hey, that's me!) has fixed this in a pseudo-fashion by adding a sleep() loop in the latest CVS code that I can see, which means you can launch pilot-link first, or hit the HotSync button on your Palm/Cradle first, and it will "Just Work".

KDE's Kpilot works like this, Gnome has a similar application too.

Both of these tools, built on top of the libraries provided by pilot-link, provide their own daemon process; kpilotDaemon from KPilot in KDE-land, and gnome-pilot (gpilotd) in GNOME-land, which polls for device creation in /proc, and binds accordingly.

Other than being built upon pilot-link, these applications have nothing whatsoever to do with the pilot-link codebase. This means, for those who don't run GNOME or KDE (a growing percentage from what I understand), this is not an option, so they use pilot-link and J-Pilot (also built upon libraries provided by pilot-link).

This isn't needed anymore.

Actually, this has absolutely nothing to do with pilot-link. It has to do with the way USB on any hardware is handled. You have to make the physical electrical connection between Palm handheld and Cradle before the hardware (your computer) can see the device, map a driver against the device, and allow you to communicate across it.

That being said, the pilot-link maintainer (hey, that's me!) has fixed this in a pseudo-fashion by adding a sleep() loop in the latest CVS code that I can see, which means you can launch pilot-link first, or hit the HotSync button on your Palm/Cradle first, and it will "Just Work".

KDE's Kpilot works like this, Gnome has a similar application too.

Both of these tools, built on top of the libraries provided by pilot-link, provide their own daemon process; kpilotDaemon from KPilot in KDE-land, and gnome-pilot (gpilotd) in GNOME-land, which polls for device creation in /proc, and binds accordingly.

Other than being built upon pilot-link, these applications have nothing whatsoever to do with the pilot-link codebase. This means, for those who don't run GNOME or KDE (a growing percentage from what I understand), this is not an option, so they use pilot-link and J-Pilot (also built upon libraries provided by pilot-link).

This isn't needed anymore.

Actually, this has absolutely nothing to do with pilot-link. It has to do with the way USB on any hardware is handled. You have to make the physical electrical connection between Palm handheld and Cradle before the hardware (your computer) can see the device, map a driver against the device, and allow you to communicate across it.

That being said, the pilot-link maintainer (hey, that's me!) has fixed this in a pseudo-fashion by adding a sleep() loop in the latest CVS code that I can see, which means you can launch pilot-link first, or hit the HotSync button on your Palm/Cradle first, and it will "Just Work".

KDE's Kpilot works like this, Gnome has a similar application too.

Both of these tools, built on top of the libraries provided by pilot-link, provide their own daemon process; kpilotDaemon from KPilot in KDE-land, and gnome-pilot (gpilotd) in GNOME-land, which polls for device creation in /proc, and binds accordingly.

Other than being built upon pilot-link, these applications have nothing whatsoever to do with the pilot-link codebase. This means, for those who don't run GNOME or KDE (a growing percentage from what I understand), this is not an option, so they use pilot-link and J-Pilot (also built upon libraries provided by pilot-link).

This isn't needed anymore.

Actually, this has absolutely nothing to do with pilot-link. It has to do with the way USB on any hardware is handled. You have to make the physical electrical connection between Palm handheld and Cradle before the hardware (your computer) can see the device, map a driver against the device, and allow you to communicate across it.

That being said, the pilot-link maintainer (hey, that's me!) has fixed this in a pseudo-fashion by adding a sleep() loop in the latest CVS code that I can see, which means you can launch pilot-link first, or hit the HotSync button on your Palm/Cradle first, and it will "Just Work".

KDE's Kpilot works like this, Gnome has a similar application too.

Both of these tools, built on top of the libraries provided by pilot-link, provide their own daemon process; kpilotDaemon from KPilot in KDE-land, and gnome-pilot (gpilotd) in GNOME-land, which polls for device creation in /proc, and binds accordingly.

Other than being built upon pilot-link, these applications have nothing whatsoever to do with the pilot-link codebase. This means, for those who don't run GNOME or KDE (a growing percentage from what I understand), this is not an option, so they use pilot-link and J-Pilot (also built upon libraries provided by pilot-link).

This isn't needed anymore.

Actually, this has absolutely nothing to do with pilot-link. It has to do with the way USB on any hardware is handled. You have to make the physical electrical connection between Palm handheld and Cradle before the hardware (your computer) can see the device, map a driver against the device, and allow you to communicate across it.

That being said, the pilot-link maintainer (hey, that's me!) has fixed this in a pseudo-fashion by adding a sleep() loop in the latest CVS code that I can see, which means you can launch pilot-link first, or hit the HotSync button on your Palm/Cradle first, and it will "Just Work".

KDE's Kpilot works like this, Gnome has a similar application too.

Both of these tools, built on top of the libraries provided by pilot-link, provide their own daemon process; kpilotDaemon from KPilot in KDE-land, and gnome-pilot (gpilotd) in GNOME-land, which polls for device creation in /proc, and binds accordingly.

Other than being built upon pilot-link, these applications have nothing whatsoever to do with the pilot-link codebase. This means, for those who don't run GNOME or KDE (a growing percentage from what I understand), this is not an option, so they use pilot-link and J-Pilot (also built upon libraries provided by pilot-link).

This isn't needed anymore.

Actually, this has absolutely nothing to do with pilot-link. It has to do with the way USB on any hardware is handled. You have to make the physical electrical connection between Palm handheld and Cradle before the hardware (your computer) can see the device, map a driver against the device, and allow you to communicate across it.

That being said, the pilot-link maintainer (hey, that's me!) has fixed this in a pseudo-fashion by adding a sleep() loop in the latest CVS code that I can see, which means you can launch pilot-link first, or hit the HotSync button on your Palm/Cradle first, and it will "Just Work".

KDE's Kpilot works like this, Gnome has a similar application too.

Both of these tools, built on top of the libraries provided by pilot-link, provide their own daemon process; kpilotDaemon from KPilot in KDE-land, and gnome-pilot (gpilotd) in GNOME-land, which polls for device creation in /proc, and binds accordingly.

Other than being built upon pilot-link, these applications have nothing whatsoever to do with the pilot-link codebase. This means, for those who don't run GNOME or KDE (a growing percentage from what I understand), this is not an option, so they use pilot-link and J-Pilot (also built upon libraries provided by pilot-link).

This isn't needed anymore.

Actually, this has absolutely nothing to do with pilot-link. It has to do with the way USB on any hardware is handled. You have to make the physical electrical connection between Palm handheld and Cradle before the hardware (your computer) can see the device, map a driver against the device, and allow you to communicate across it.

That being said, the pilot-link maintainer (hey, that's me!) has fixed this in a pseudo-fashion by adding a sleep() loop in the latest CVS code that I can see, which means you can launch pilot-link first, or hit the HotSync button on your Palm/Cradle first, and it will "Just Work".

KDE's Kpilot works like this, Gnome has a similar application too.

Both of these tools, built on top of the libraries provided by pilot-link, provide their own daemon process; kpilotDaemon from KPilot in KDE-land, and gnome-pilot (gpilotd) in GNOME-land, which polls for device creation in /proc, and binds accordingly.

Other than being built upon pilot-link, these applications have nothing whatsoever to do with the pilot-link codebase. This means, for those who don't run GNOME or KDE (a growing percentage from what I understand), this is not an option, so they use pilot-link and J-Pilot (also built upon libraries provided by pilot-link).

Pilot-link works nicely. Note that USB links are a bit tricky - you need to start pilot-xfer shortly after you start the hotsync, but not too long or too short.

Have you read README.usb yet? It should get you started. I also have a bunch of HOWTO documents I've written that may also help you get things working.

Are you running 0.11.7 of pilot-link (which is required for USB to work with any of the other apps, KPilot, J-Pilot, gnome-pilot, etc.) I'll be releasing 0.11.8 shortly.

Is your kernel recent enough to support it? Use 2.4.20 or later, but not 2.5, if you want the most stable. Previous kernels had issues with the visor driver crashing, which have been resolved in 2.4.20 and later kernel versions.

Considered a donation to the project?

Good luck.

Have you read README.usb yet? It should get you started. I also have a bunch of HOWTO documents I've written that may also help you get things working.

Are you running 0.11.7 of pilot-link (which is required for USB to work with any of the other apps, KPilot, J-Pilot, gnome-pilot, etc.) I'll be releasing 0.11.8 shortly.

Is your kernel recent enough to support it? Use 2.4.20 or later, but not 2.5, if you want the most stable. Previous kernels had issues with the visor driver crashing, which have been resolved in 2.4.20 and later kernel versions.

Considered a donation to the project?

Good luck.

Have you read README.usb yet? It should get you started. I also have a bunch of HOWTO documents I've written that may also help you get things working.

Are you running 0.11.7 of pilot-link (which is required for USB to work with any of the other apps, KPilot, J-Pilot, gnome-pilot, etc.) I'll be releasing 0.11.8 shortly.

Is your kernel recent enough to support it? Use 2.4.20 or later, but not 2.5, if you want the most stable. Previous kernels had issues with the visor driver crashing, which have been resolved in 2.4.20 and later kernel versions.

Considered a donation to the project?

Good luck.

Have you read README.usb yet? It should get you started. I also have a bunch of HOWTO documents I've written that may also help you get things working.

Are you running 0.11.7 of pilot-link (which is required for USB to work with any of the other apps, KPilot, J-Pilot, gnome-pilot, etc.) I'll be releasing 0.11.8 shortly.

Is your kernel recent enough to support it? Use 2.4.20 or later, but not 2.5, if you want the most stable. Previous kernels had issues with the visor driver crashing, which have been resolved in 2.4.20 and later kernel versions.

Considered a donation to the project?

Good luck.