John,

<< A bunch of us have been waiting about 2 years for this! >>

I understand, but I was unaware at the time that I gave the answers that I
did, that there would such an issue with getting Kylix to work with the
newer distributions.  We can't possibly release support for a product that
isn't being supported anymore, especially if it doesn't work without a lot
of issues, or simply doesn't work at all.  It would be a support nightmare
to give any of our customers the idea that it would work.

<< Trying to read "between the lines," I had been guesstimating/hoping that
you'd release Kylix/Linux support right after 1.06... >>

I'm hoping to get on to the FreePascal/Linux target after the .NET data
provider is complete.   We at least have to target a compiler that is still
viable on the Linux platform.

<< You asked me back in January or February if I'd be willing to work with
the Kylix version (on this newsgroup somewhere I think...). I should have
answered YES immediately!!  But I'm swamped with other stuff, as already
bemoaned in this thread.  I may change that answer to YES VERY SOON THOUGH.
Give me a day or so to contemplate exactly how nuts I am. If you think
another motivated developer's involvement (my efforts, that is) could
influence your decision on Kylix support, that could influence my decision
and all-in-all get very recursive...  please mention it...  Though
maybe you want feedback from other Kylix users first... >>

The issues are what I mentioned above.  If you want to try EDB with Kylix
right now, I can get you the source code to do so now - EDB has the Linux
stuff in it already and basically just needs some minor tweaks and the
package support done.  If you want to give it a try, just let me know and
I'll email you the source code.

<< EVEN MORE IMPORTANTLY THOUGH: (Whew!) That statement of yours quoted
above isn't actually true, though you have to jump through 73 hoops reciting
the right incantations during the auspicious phases of the moon, dressed
like a Druid, to discover it. There are a number of geniuses out there that
discovered AND FIXED the major problems. (They even involved some Linux
kernel developers at points.) And it works beautifully once you apply those
fixes (and mess with the environment like preventing KDE "focus stealing"
etc.) >>

I understand, but it is one of the primary reasons why the Kylix support for
EDB was "put aside".  As a bottom-line requirement, we can only sell
products for environments that are being actively supported.

<< Quite a few people gave up on Kylix because of those problems, but with
the wider dissemination of that information (perhaps even on your site), and
active support from tools like yours and libraries like TDBF, Synapse, and
others, I wouldn't be surprised at a significant resurgence. >>

I would like to think that this is the case also, but at some point isn't
Linux simply going to break Kylix for good ?  I mean, Kylix can only stay
static (while Linux moves on) for so long before it literally becomes
obsolete.

Meanwhile, I'll give K3 another try on OpenSuse 10 and see what I can find
out.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> I understand, but I was unaware at the time that I gave the answers
> that I did, that there would such an issue with getting Kylix to work
> with the newer distributions.

Completely understood, *but* those issues are less problematic than
they appear (though that wasn't immediately obvious), can be solved in
several ways (ranging from easy to a-little-bit-tricky—-others have
already done the heavy lifting), and once solved open the doors to some
wonderful efficiencies (like using our copious Delphi code on bunches
of Linux servers, with a high-quality compiler).

First of all, the issues you're referring to only relate to the Kylix
IDE. The generated programs run just fine on later kernels. The first
and easiest way to cope with the problem is just to use an older distro
on the Kylix development machines. In fact, that's just what I did
until discovering the other ways. It's a no-fuss, no-muss way to a
perfectly acceptable development environment that produces code for all
the latest kernels, and in fact "automatically" reaps their benefits,
like better threading.

Following the instructions on those web links I gave you gets us the
rest of the way if we want to run the IDE under later kernels. [BTW, I
also needed to reorder the list of include files in
"ptrace_interpose.c" for my Slackware installation. You can find
details at http://andy.jgknet.de/oss/kylix/Forum/viewtopic.php?t=237 ]


> We can't possibly release support for
> a product that isn't being supported anymore, especially if it
> doesn't work without a lot of issues, or simply doesn't work at all.
> It would be a support nightmare to give any of our customers the idea
> that it would work.

Well, *Elevate* wouldn't be responsible for getting *Kylix* to work on
any particular distro anyway; and customers presumably wouldn't be
interested in a Kylix tool if they didn't have working compiler
installations...  So it should be a pretty self-selecting clientele.

> As a bottom-line requirement, we
> can only sell products for environments that are being actively
> supported.

Some people would argue that FreePascal isn't that well supported (by
report, I have extremely little experience with it, by choice), and
Elevate does support old versions of Delphi...  and us Kylix developers
are a determined lot...  In addition, I've seen a number of developers
try FreePascal, and then run back to Kylix expressing extreme
frustration, making statements to the effect that they didn't expect
FPC to ever match Kylix. This was a while ago... and I personally have
never used FPC, though I look at their web site occasionally, have
helped with others' FPC code, and do see conversations about it in
various forums (where I've seen some *very* weird stuff mentioned,
including recently). The wide platform support seems appealing, but the
rest of what I've seen and heard doesn't--at least in comparison with
our favorite Borland tools. (Recognizing that I'm most likely to hear
about problems.) (Hmmm... that "wide platform support" might put the
chosen categories of your survey
http://www.elevatesoft.com/scripts/vote.dll?action=viewresults in a
different light.


As for FPC, one often gets the impression that the major overriding
concept for many users is "Free" in the financial, pecuniary sense, not
so much in the "open source" sensibilities. Which might not be the best
for a tool vendor. But hey, things are different now... On the
technical side, when you look at the postings of strange problems,
often when people are porting code to FPC, or references like
http://wiki.lazarus.freepascal.org/Code_Conversion_Guide  ...  porting
might not be as straightforward as one might hope...  Though the only
way to know is to do it.



> We at least have to target a compiler that is still viable on
> the Linux platform.

 -- and --

> I would like to think that this is the case also, but at some point
> isn't Linux simply going to break Kylix for good ?  I mean, Kylix can
> only stay static (while Linux moves on) for so long before it
> literally becomes obsolete.

Several of us came to the conclusion, some years ago and independently,
that Kylix, along with quite a few other tools could be considered
"evergreen," just as LOTS of Delphi developers consider their old
versions of Delphi MORE than enough for their work. We weren't too sure
of that conclusion at first, even though we'd seen plenty of evidence
to support it (including clients using very old Delphi or other dev
platforms; and the fact that lots of Linux programs were, and still
are, created by tools that seem the equivalent of stone tablets and
chisels). There were numerous important and large kernel changes, since
K3, that triggered all sorts of angst among Kylix developers, like the
move to NPTL threads... that ended up not only being non-issues... but
directly and immediately benefited Kylix programs with no effort on our
part! For example: Instead of losing threads, as some feared, we got
radically faster and more efficient threads just by running on a later
kernel.

Linux kernel developers understandably do try to maintain API
consistencies and accommodate older code.

More than "evergreen," now that Intel-type processors will be showing
up in Linux handhelds, and other small and embedded environments, I
expect Kylix to have more development targets with each passing month.

One can view Kylix's "static nature" as a benefit as well! Some of us
even felt relief that one of the ever-faster treadmills came to a
stop!! Especially since the nature of the tool is to give us full
access to the OS anyway, and we can code what we need if necessary, OR
get tools for the task. [Aside: One nice way to develop for Kylix, is
to do a lot of the work under Delphi where we have certain benefits
such as access to certain FastMM features not available under Kylix,
and do only the OS-specific stuff on Kylix itself. I actually prefer
that to using CrossKylix, since when I'm working on Kylix/Linux I like
having access to the right help files and support tools, and the real
testing and debugging environment.]


Although we enjoyed and marveled at the improvements to Borland's tools
over a couple decades, the marginal utility of later compilers
definitely seems to be declining---whether that's really true, or just
due to the fact that we can't possibly use everything in these enormous
tools, and it takes us time to catch up (while we're producing work of
our own).  (Let's ignore the subject of compiler/IDE releases that were
downright COUNTER-productive.)  That "catch up" time may well be a
major factor that Kylix didn't do better in the market at the time.
I've seen a number of very recent postings on web sites, etc. where
people are just taking up, or porting to Kylix, in the last year or so,
and are *excited* about it. It took some of us a while to "get" Linux
and Kylix, and believe that it would be a viable platform. [And as you
probably know, certain other tool vendors do sell Kylix tools, though
some of their support is now limited to sales and the tools are
also static... which again, isn't always bad. One vendor shut down
operations years ago, but still sells the tools with the understanding
of "no further development."]


If you've already got the code in EDB to support Kylix, I would be
inclined to make it available for that platform, perhaps with (sales)
caveats. I suspect it will be much easier than a port to FPC, it's
already (mostly) done work, and I'd bet that a lot of those who voted
for Linux in your poll pretty much expected the compiler to be Kylix...
and are waiting for it.  Though I am pretty surprised that no one else
has expressed such an interest in this thread, though these messages
are camouflaged under a "Unicode" title



The opinions about Kylix you can find online range pretty drastically,
and some of the more prominent ones (like on Wikipedia) are pretty
(amazingly) negative. (I skipped K1 and K2, thus saving some agita.)
While there are definitely elements of truth, you've got to wonder
about some of the authors' motivations. For lots of types of programs,
Kylix is wonderful, and you do find some pretty good endorsements, such
as:

http://delphi.newswhat.com/geoxml/forumhistorythread?groupname=borland.p
ublic.kylix.linuxapi&messageid=4098fc19$2@newsgroups.borland.com



> The issues are what I mentioned above.  If you want to try EDB with
> Kylix right now, I can get you the source code to do so now - EDB has
> the Linux stuff in it already and basically just needs some minor
> tweaks and the package support done.  If you want to give it a try,
> just let me know and I'll email you the source code.

I think we'll do that, but while I'm willing and able to consider Kylix
3 evergreen (with nearly 20 years of dev leading up to it, and the
nature of the tool, our investment in such code, and the number of
users...), we're not too sure about potentially having to do that with
EDB, at least until it's reached a certain level of maturity (whose
metric is yet unknown we may have already passed that point). If
you tend to agree with some of the viewpoints expressed here, and if
things work out with installing the compilers on later kernel versions
for you, and since you've got most of the OS code probably done... you
might consider it worth "supporting" the platform. That might end up
meaning very little additional work since you designed Kylix support in
from the start, and had an operational foundation to begin with.

While you're considering and experimenting, I'll try to rearrange
things here. I need to wrap up some sub-projects (need to finish a few
threads to save some mental context switches). Don't know how long
that'll take, but probably not too long, though I've got some family
issues too. I'll then need to start a couple web service
implementations (whose instructions are only a few hundred pages long),
which I'll start with a completely new database. In all likelihood
that'll be EDB, which will be my first contact with it, and will need
some ramping up time (both on Windows and Linux). In fact, I need to
buy it too. With any luck I won't be pestering the newsgroups with too
many newbie questions


> Meanwhile, I'll give K3 another try on OpenSuse 10 and see what I can
> find out.

Good Luck! I'll help if I can.

John,

<< Well, *Elevate* wouldn't be responsible for getting *Kylix* to work on
any particular distro anyway; >>

No, but our servers need to work on multiple distros, and they are
applications that have similar issues to the Kylix IDE in terms of getting
them to run.  All of this comes back to us, and is especially difficult for
customers that just want to run our servers on a Linux box and don't have a
lot of Linux experience.

<< and customers presumably wouldn't be interested in a Kylix tool if they
didn't have working compiler installations...  So it should be a pretty
self-selecting clientele. >>

Yes, and unfortunately that makes the whole thing even less appealing to us.
As much as we like to help people out, we have to spend our resources on the
items that stand to make us the most money and frankly, the whole Kylix
support has never really made us any money.

<< Some people would argue that FreePascal isn't that well supported (by
report, I have extremely little experience with it, by choice), and Elevate
does support old versions of Delphi...  and us Kylix developers are a
determined lot...  In addition, I've seen a number of developers try
FreePascal, and then run back to Kylix expressing extreme frustration,
making statements to the effect that they didn't expect FPC to ever match
Kylix. This was a while ago... and I personally have never used FPC, though
I look at their web site occasionally, have helped with others' FPC code,
and do see conversations about it in various forums (where I've seen some
*very* weird stuff mentioned,
including recently). The wide platform support seems appealing, but the rest
of what I've seen and heard doesn't--at least in comparison with our
favorite Borland tools. (Recognizing that I'm most likely to hear about
problems.) (Hmmm... that "wide platform support" might put the chosen
categories of your survey
http://www.elevatesoft.com/scripts/vote.dll?action=viewresults in a
different light. >>

I can't really comment on FPC at this point since I haven't actually
attempted a port yet.  However, there is always the possibility that it will
stink and require that we support Kylix if we want to provide Linux support.

<< If you've already got the code in EDB to support Kylix, I would be
inclined to make it available for that platform, perhaps with (sales)
caveats. I suspect it will be much easier than a port to FPC, it's already
(mostly) done work, and I'd bet that a lot of those who voted for Linux in
your poll pretty much expected the compiler to be Kylix... and are waiting
for it.  Though I am pretty surprised that no one else has expressed such an
interest in this thread, though these messages are camouflaged under a
"Unicode" title >>

Well, as I said before, we really haven't had much interest in the Kylix CLX
products for DBISAM.  There's been a little, but Borland shot themselves in
the foot by practically abandoning the product so soon.

<< I think we'll do that, but while I'm willing and able to consider Kylix 3
evergreen (with nearly 20 years of dev leading up to it, and the nature of
the tool, our investment in such code, and the number of users...), we're
not too sure about potentially having to do that with EDB, at least until
it's reached a certain level of maturity (whose metric is yet unknown
we may have already passed that point). >>

EDB is at least as stable or more stable than DBISAM at this point.  It had
the benefits of all of the DBISAM tests along with a completely different
design that eliminates a lot of the issues that DBISAM had in terms of
architecture.

<< If you tend to agree with some of the viewpoints expressed here, and if
things work out with installing the compilers on later kernel versions for
you, and since you've got most of the OS code probably done... you might
consider it worth "supporting" the platform. That might end up meaning very
little additional work since you designed Kylix support in from the start,
and had an operational foundation to begin with. >>

I would *like* to agree with you on everything, however I still have to get
K3 working under OpenSuse 10 before I can comment any further.

Thanks for the input,

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> No, but our servers need to work on multiple distros, and they are
> applications that have similar issues to the Kylix IDE in terms of
> getting them to run.

Ahhh... <yet another bulb lights> Some similar Linux app issues, yes;
but the ones that were causing the problems we were just discussing
would seem quite distant, like debugger support, WINE compatibility...


> All of this comes back to us...

A *very* big and understandable point; and one of the same reasons
other tool vendors stopped further development on Kylix products. I was
operating under the assumption that these issues were relatively worked
out for DBISAM Kylix support, and would not be much different for EDB.
My impression was also that the nature of a DB server would lend itself
to an easier port, and deployments.


> and is especially difficult for customers that just want to run our
> servers on a Linux box and don't have a lot of Linux experience.

Well, invoking the theory that "obstacles are really opportunities in
disguise," if that difficulty can be overcome (particularly if
automated), Linux servers are a *rapidly* growing market!


> Yes, and unfortunately that makes the whole thing even less
> appealing to us. As much as we like to help people out, we have to
> spend our resources on the items that stand to make us the most
> money and frankly, the whole Kylix support has never really made
> us any money.

I read this several times, in context of what you were responding to,
and I'm still not sure I'm getting it, though I suspect it's related to
a calculus that Borland made too. I'm probably assuming that developers
are responsible for getting their own environments to work (especially
since they can choose from so many distros, and desktop environments on
those distros, and so on...). BUT your experience may be that you end
up providing support for all sorts of things having nothing to do with
Elevate's offerings. This could possibly be dealt with by stating firm
boundaries of support in sales agreements??

My guesstimation is that with the passage of time, more developers are
now able to take care of that themselves, but you have valid data
points to work from, where I'm inferring from much squishier input


> Well, as I said before, we really haven't had much interest
> in the Kylix CLX products for DBISAM.

That says a lot.


> There's been a little, but Borland shot themselves in the foot
> by practically abandoning the product so soon.

The conspiracy theorists propose this was part of a quid pro quo for
the MS investment If so, we can only hope there was an expiration
in the agreement!


> EDB is at least as stable or more stable than DBISAM at this point...

Heh... Up until this paragraph, I was sure you were leaning further
against bringing out a Kylix version... which may still be the case...
and I was already mulling over the alternatives, which of course
include DBISAM...


> I would like to agree with you on everything

Same here, but then we're very agreeable guys.  Your hard data,
experience, and potential costs are worth far more than my wishful
thinking though!


Thanks for considering the possibilities, and I wish you, your family,
and everyone here a very Happy Thanksgiving!

John,

<< A *very* big and understandable point; and one of the same reasons other
tool vendors stopped further development on Kylix products. I was operating
under the assumption that these issues were relatively worked out for DBISAM
Kylix support, and would not be much different for EDB. My impression was
also that the nature of a DB server would lend itself to an easier port, and
deployments. >>

It is if we only provide a command-line-only server, which may be a viable
option.

<< Well, invoking the theory that "obstacles are really opportunities in
disguise," if that difficulty can be overcome (particularly if
automated), Linux servers are a *rapidly* growing market! >>

I understand, but when they can't just copy it onto the box and run it, it
really starts to eat into our profit fairly quickly when aggregated over
multiple customers.

<< I read this several times, in context of what you were responding to, and
I'm still not sure I'm getting it, though I suspect it's related to a
calculus that Borland made too. I'm probably assuming that developers are
responsible for getting their own environments to work (especially since
they can choose from so many distros, and desktop environments on those
distros, and so on...). BUT your experience may be that you end up providing
support for all sorts of things having nothing to do with Elevate's
offerings. This could possibly be dealt with by stating firm boundaries of
support in sales agreements?? >>

Well, agreements are all well and good, but in reality they mean very little
since I'm not about to refuse to answer a question from a customer regarding
the implementation of our product within the OS.  I just simply don't do it.

<< That says a lot. >>

Unfortunately, yes.   Especially since it means that the money that normally
might be able to go to us may be going to MS first instead.

<< The conspiracy theorists propose this was part of a quid pro quo for the
MS investment If so, we can only hope there was an expiration in the
agreement! >>

Who knows, nobody will ever fess up.

<< Thanks for considering the possibilities, and I wish you, your family,and
everyone here a very Happy Thanksgiving! >>

Thanks, and the same to you and your family.

--
Tim Young
Elevate Software
www.elevatesoft.com