Board index » kylix » Re: Bill Todd's comments in Delphi Informant

Re: Bill Todd's comments in Delphi Informant


2003-07-14 12:03:21 AM
kylix1
In borland.public.kylix.non-technical, JQP < XXXX@XXXXX.COM >wrote in message
<3f116f40$ XXXX@XXXXX.COM >...
Quote
If they really want to accommodate, they should do some compatibility
testing in order to avoid breaking commercial products like Kylix every few
months. Welcoming gestures aside, the overall message being sent by the
current approach to development and distribution of Linux is pretty clear:

"Commercial software ... we don't need no stinkin' commercial software".


Which is why Linux remains a marginal player.
--
***Posted by Jake's Custom Newsgroup Reader***
Posted using Jake's Super Newsreader 0.9.2.1007
 
 

Re:Re: Bill Todd's comments in Delphi Informant

JQP wrote:
Quote
Hence, commercial Linux software and opportunities are severely limited.
The only hope I can see is the Mono project.
You see, your comment is a non-sense. You *like* Mono because it is
based on MS technology. it is Open source, and most likely will share
the same issues that other open sources have. Your problem is that you
do not like Unix/Linux/Solaris, anything that is not MS.
Rosimildo.
 

Re:Re: Bill Todd's comments in Delphi Informant

RdS>You see, your comment is a non-sense. You *like* Mono because it is
RdS>based on MS technology. it is Open source, and most likely will
RdS>share the same issues that other open sources have. Your problem
RdS>is that you do not like Unix/Linux/Solaris, anything that is not
RdS>MS.
I think JQP has very simple and clear logic. Assume you have an contract to
create some kind of information system. You should decide what base will be
used Linux or Windows. Then you have to estimate how much time you need, how
big expences will be, how many new things you should to evaluate and to use,
how difficult deployment and maintenance process will be when you create
this system.
At current moment if you select Windows, you will see that solution of many
and many problems is simplier and easier on Windows than Linux.
Some time ago our company was participant of tender. We received long list
of requirements. There was two types requirements - for functional
characteristics (i.e. list of possible operations) ~75%, and for technical
and maintenance characteristics (connectivity with other software, ability
of other software to interact with ours, data formats, reporting, easy of
use and maintenance, etc) ~25%. We read it and understand that if our
software was Windows based we may count this 25% completed with minimal
efforts from our side. But our soft is Linux based and we have to work on
this 25% of requirements.
Fortunately, our main competitors use Solaris. They have poorer position
than we. :-)
 

{smallsort}

Re:Re: Bill Todd's comments in Delphi Informant

"Rosimildo da Silva" < XXXX@XXXXX.COM >wrote in message
Quote
it is Open source, and most likely will share
the same issues that other open sources have.
Actually, the fact that Mono is Open Source may encourage distro vendors
(for the first time<g>) to perform some compatibility testing. If Mono
becomes popular enough, it may become unthinkable for any new Linux version
to fail to support it. Since Mono is Open Source, the distro vendor can do
his own unique build if necessary. Whatever it takes. As a commerical
vendor, all I really care about is a decent solution to the compatibility
issue.
Quote
Your problem is that you do not like Unix/Linux/Solaris, anything that is
not MS.
And your problem is that you prefer to sidestep the issue by talking
personality.
 

Re:Re: Bill Todd's comments in Delphi Informant

JQP wrote:
Quote
Actually, the fact that Mono is Open Source may encourage distro vendors
(for the first time<g>) to perform some compatibility testing. If Mono
becomes popular enough, it may become unthinkable for any new Linux version
to fail to support it. Since Mono is Open Source, the distro vendor can do
his own unique build if necessary. Whatever it takes. As a commerical
vendor, all I really care about is a decent solution to the compatibility
issue.
So the venerable, DLL Hell in windows, has never been a problem for you,
I suspect. Compatibility issue is a problem, of how often release are
made, and whether people update their systems in different times. In
Linux that the source code is widely available, having many systems that
have been updated at different times, is more common.
Quote
>Your problem is that you do not like Unix/Linux/Solaris, anything that is

not MS.

And your problem is that you prefer to sidestep the issue by talking
personality.
And you aren't ?
Rosimildo.
 

Re:Re: Bill Todd's comments in Delphi Informant

Ender wrote:
Quote
RdS>You see, your comment is a non-sense. You *like* Mono because it is
RdS>based on MS technology. it is Open source, and most likely will
RdS>share the same issues that other open sources have. Your problem
RdS>is that you do not like Unix/Linux/Solaris, anything that is not
RdS>MS.

I think JQP has very simple and clear logic. Assume you have an contract to
create some kind of information system. You should decide what base will be
used Linux or Windows. Then you have to estimate how much time you need, how
big expences will be, how many new things you should to evaluate and to use,
how difficult deployment and maintenance process will be when you create
this system.

At current moment if you select Windows, you will see that solution of many
and many problems is simplier and easier on Windows than Linux.

Some time ago our company was participant of tender. We received long list
of requirements. There was two types requirements - for functional
characteristics (i.e. list of possible operations) ~75%, and for technical
and maintenance characteristics (connectivity with other software, ability
of other software to interact with ours, data formats, reporting, easy of
use and maintenance, etc) ~25%. We read it and understand that if our
software was Windows based we may count this 25% completed with minimal
efforts from our side. But our soft is Linux based and we have to work on
this 25% of requirements.

Fortunately, our main competitors use Solaris. They have poorer position
than we. :-)
I am discarting what you have written, because from your post, you are
most likely on of these people that believe on the MS report that TCO on
windows is a lot less than Linux. <g>
Rosimildo.
 

Re:Re: Bill Todd's comments in Delphi Informant

JQP wrote:
Quote
"Rosimildo da Silva" < XXXX@XXXXX.COM >wrote in message
news:3f119f70$ XXXX@XXXXX.COM ...

>So the venerable, DLL Hell in windows, has never been a problem for you,
>I suspect.


Comparatively speaking, it's not a major problem. In my experience, the
biggest perpetrator of "DLL hell" is VB which I've always avoided.

Let's use Borland as an example vendor just to add some perspective. A 6
year old release of Delphi (v3) runs just fine on the lastest version of
Windows, I use it all the time. As evidenced here, a 6 month old release of
Kylix (v3) has significant problems with the latest Linux versions.
I am glad that you brought this up, because I want made Delphi to have
less DLL problems on Windows, was the fact that the applications were
static linked. VB had to deal more with OCX/DLLs and the problem
increases exponentially.
The same is happening with Kylix, I suspect. People that releases static
linked applicatons on linux have very little probably among distros.
But, to link something static on linux, you have to develop code using
GCC, and borland made a classic mistake of not supporting GCC at binary
level.
You are blaming linux for a problem that is most likely a Borland problem.
Quote
The problem is not the frequency of releases, it's the frequent lack of
binary compatibility between releases and the apparent lack of concern for
same.
Everywhere API changes. Want has made the life easier of Delphi
developers on windows is the fact that applications are linked staticly,
and you basically remove the depedencies when you compile your code. Try
to use any form of dynamic loaded modules, and the problems will appear.
If Kylix could link staticly with GCC code, all these problems would
most likely would go away.
Quote

>And you aren't ?


No, you're the one who started addressing "my" problem instead of "the"
problem.
Ok, sorry about that.
Rosimildo.
 

Re:Re: Bill Todd's comments in Delphi Informant

"Rosimildo da Silva" < XXXX@XXXXX.COM >wrote in message
Quote
The same is happening with Kylix, I suspect. People that releases static
linked applicatons on linux have very little probably among distros.
It should come as no surprise that Linux is focused on *source* (not
*binary*) compatibility. Without source, any app is likely to have
problems.
People that release major *open source* applications have very few problems
because the distro vendors tweak and re-build as necessary to include with
each of their new releases. Without the source they can't do this so
commercial vendors are on their own.
 

Re:Re: Bill Todd's comments in Delphi Informant

juliusz wrote:
Quote
Rosimildo da Silva wrote:
>The same is happening with Kylix, I suspect. People that releases static

>linked applicatons on linux have very little probably among distros.
>But, to link something static on linux, you have to develop code using
>GCC, and borland made a classic mistake of not supporting GCC at
>binary level.


>.. Everywhere API changes. Want has made the life easier of Delphi
>developers on windows is the fact that applications are linked
>staticly, and you basically remove the depedencies when you compile
>your code. Try to use any form of dynamic loaded modules, and the
>problems will appear.
>
>
>If Kylix could link staticly with GCC code, all these problems would
>most likely would go away.
>


In general Kylix has two groups of problems.

The first one is that it is utilizing transplanted windows technology
(wine) it makes the whole system extremely environment dependent,
sometimes just changing the settings of X-server makes Kylix to act
funny. Also, for the same reasons to make any upgrades and do the QA
testing on any patches (I guess) become too expensive. I think Borland
boxed itself in to the corner by going the easy way and porting the
Windows software and ideas to Linux instead to go the harder way and
create a native IDE and native de{*word*81}... the Linux way.. It would
pay off on the long run, since to make any adjustments to accommodate
changing Linux environment will be a snap, as it is for many other
commercial native software... and secondarily the acceptance of Kylix
will be much greater because of a stable and snappier IDE.

The other one is that Kylix is using Pascal (sorry Delphi) originated
code. This require additionally some sort of interface in order for the
code to link or call to a C++ libraries as the Qt is. This by design
solution creates additional level of complexity. It would be not much
of a problem if Borland was able to provide some sort of a mechanism to
compensate for the necessity of using unique sets of interfaces to the
Qt libraries normally present on many systems; instead they choose to
providing only a one set of it, unique to Kylix compiled with gcc 2.95.

The latest version of Kylix improved the deployment sytuation because
these two libraries the interface and the Qt library was renamed and
melted together to create a one file (very clever, indeed), but still it
needs to be deployed with the Kylix Qt GUI application. Anyway, Kylix
is still using the antiquate version of the Qt 2.x series library and
the whole warld is using Qt 3.1 and soon 3.2 .. and compiled with GCC
3.2. Ironically, this situations actually improves the deployment in
some situations,specially for Kylix 1 and Kylix 2 applications since if
deployed to a modern Linux distribution the provided Borland's qt 2
library does not conflict with normally present on the system qt library
and in some situations the use of a starting script is not necessary.


In regard of the trouble free "one file" deployment for any Kylix
application the solutions are there, even it is not necessary to look
for them too far .. ;-)
Thanks for your detailed report.
Rosimildo.
 

Re:Re: Bill Todd's comments in Delphi Informant

"juliusz" wrote
Quote

In general Kylix has two groups of problems.
Interesting reading! thanks.
Kristofer
 

Re:Re: Bill Todd's comments in Delphi Informant

"Rosimildo da Silva" < XXXX@XXXXX.COM >wrote in message
Quote
JQP wrote:

So the venerable, DLL Hell in windows, has never been a problem
for you,
I suspect.
The DLL Hell problem is primarily a VB problem
or a broken 3rd party vendor problem. If you don't
use 3rd party vender DLLs without source it's not
a problem. OTOH Linux distros bring their own .so
hell problem.
--
Hilton Evans
-----------------------------------------------
ChemPen Chemical Structure Software
www.chempensoftware.com
 

Re:Re: Bill Todd's comments in Delphi Informant

Hilton Evans wrote:
Quote
"Rosimildo da Silva" < XXXX@XXXXX.COM >wrote in message

The DLL Hell problem is primarily a VB problem
or a broken 3rd party vendor problem. If you don't
use 3rd party vender DLLs without source it's not
a problem. OTOH Linux distros bring their own .so
hell problem.
When you link your application staticly, there is no .so. The problem is
solved using the same principle that delphi does on windows. So, the
problem is not linux. <g>
Rosimildo.
 

Re:Re: Bill Todd's comments in Delphi Informant

RdS>I am discarting what you have written, because from your post, you
RdS>are most likely on of these people that believe on the MS report
RdS>that TCO on windows is a lot less than Linux. <g>
I never read such reports, they all bought by one or another company. But i
tend to believe in this report. Because i see (judging by personal
expirience) that for very big amount of small companies Windows creates alot
lesser techical and maintenance problems that Linux. From "we need to print
this document right now" to "we bought this server and want to use it's IDE
RAID capabilities".
 

Re:Re: Bill Todd's comments in Delphi Informant

Quote
It depends from, who is making the decision.
If you are (the programer) then most likely the best solution will be
that one you are most familiar with. If you are trained with Windows
the most likely you will spend lest time learning, resolving problems
on Windows . If you know Linux well and you are comfortable with this
operating system and you will not spend to much time to try to figure
out how things work then the obvious choice would be Linux for you,
that is.
Here is example: Oracle database & classic clients to it. Pretty standard
soft.
1. Oracle is same for both as for server as for docs. Note: Oracle much easy
(simple) to deploy on windows. Even installation if written in Java, there
are plenty nuances that should be counted for Linux and none for Windows.
2. Oracle development tools. Plenty for Windows, none for Linux. There are
TORA for Linux, but year ago this was very weak product. Currently it is
good but still so good as, for example, TOAD.
2. Client software. Language & IDE. Variants.
Windows:
2.1 Delphi or MS Visual C++ through ADO or Delphi through ODAC. Very fast
and flexible tools.
Linux:
2.2. Kylix (buggy, uncertainity) & dbExpress (buggy, so buy drivers from
Core Lab), and you still not reach Delphi productivity
2.3. GCC/EMACS||KDevelop/Qt/OCI||OCCI (released not so long)||OCL (Core
Lab) - thank you very much i'm tried this already. Delphi variant still
looks better. Did you tried to execute single SQL from OCI? How much lines
of code? ;-)
Quote
If you are the decision makers and your priorities are cost,
effectiveness and security and you have a professional objective
advice, and you don't care who you hire to do the job a Windows
programer or Linux programer as long as the provided solution will be
cost effective and have a lower TCO on a longer period of time then
the final decision to use most likely will be Linux. And that's what
commonly hapends..
Please forgive me but i'm not understand why TCO of Linux based system is
deffinitely lower. I'm see only one thing - initially Linux is cheapier and
this may be look attractive.
 

Re:Re: Bill Todd's comments in Delphi Informant

Quote

At current moment if you select Windows, you will see that solution of many
and many problems is simplier and easier on Windows than Linux.
Right, if exclude any kind of security problems.
-Michael