[jp] Categories in Datebook

Adam Richard g4c9z at unb.ca
Wed Jan 26 21:01:14 EST 2005

Quoting "Mikkel L. Ellertson" <mikkel at access4less.net>:

> Adam Richard wrote:
> > Quoting "David A. Desrosiers" <hacker at gnu-designs.com>:
> > 
> > 
> >>>I also found that strange.  Does PalmSource release their data 
> >>>format or not?
> >>
> >>	In most cases, no. 
> >>
> >>
> >>>If not, it explains why synchronizing seems so buggy,
> >>
> >>	Synchronization can be "buggy" for any of about 2-dozen 
> >>reasons. Here are the top 6:
> >>
> >>	1.) Kernels with patches (stock kernels ALWAYS work, IMHO)
> > 
> > 
> > It's not an opinion, and I doubt they do.  Surely a bug was found in the Linux
> kernel at
> > some point.
> > 
> You are missing what he is saying - J-Pilot works with stock kernels, 
> but not necessarly with patched kernels. So, if you are using a patched 
> kernel, and J=Pilot doesn't work for you, you have to provide details if 
> you want anyone to try and fix it. And it may be the people that created 
> the patch that have to fix things, because their patch broke something...

OK.  Is it only when the patch to the kernel is broken that J-Pilot doesn't work?

> >>>and further I would expect J-Pilot to give a disclaimer that it can 
> >>>only make guesses and can't be sure synchronization works due to 
> >>>lack of co-operation from PalmSource.  If so, the phrase "reverse 
> >>>engineering" isn't true.
> >>
> >>	The problems aren't entirely Palmsource's fault. Vendor OEM 
> >>changes are also a major hurdle (Treo90/Treo300, Sony Clie models, 
> >>etc.) 
> >>
> >>	We do what we can, but Palm<etc> keeps changing things on us, 
> >>without warning, and without documenting those changes. For each new 
> >>device, it takes a user or developer to find the bugs. Sometimes its 
> >>after-the-fact, and sometimes not. We never know up-front, what kinds 
> >>of issues we'll face. udev and the FC3 kernel breakage was one of the 
> >>more-recent issues that are starting to affect people.
> >>
> >>	Its a lot like "whittling wood". You start with a block of 
> >>wood, and remove piece by piece, until you have something worthy of 
> >>using or looking at. Eventually, all of the "bugs" will go away 
> >>(until, of course, they change things or introduce new bugs).
> >>
> >>	No disclaimer required. 
> > 
> > 
> > I think a disclaimer is required whenever you have to guess at something, in other
> words
> > whenever you have no way of verifying whether your software works.
> > 
> In other words, there should be a disclaimer for at least half the Linux 
> device drivers, 


More information about the Jpilot mailing list