[jp] Categories in Datebook
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,
> >> 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
> > 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