Board index » kylix » Re: Linux on the desktop *not* imminent

Re: Linux on the desktop *not* imminent


2004-01-12 06:17:17 PM
kylix0
Quote
>And they
>still don't understand how or why it happened.
Michael Schnell wrote:
They still refuse to believe how brain dead the average user is <g>.
It is pleasure to think that one is smart, when others are stupid. This is
the source of enthusiasm of linuxist.
 
 

Re:Re: Linux on the desktop *not* imminent

"Michael Schnell" < XXXX@XXXXX.COM >wrote in message
Quote
They still refuse to believe how brain dead the average user is <g>.
It's not that the average user is necessarily brain dead, it's just that
his/her interests often lie elsewhere. The computer is a tool, a means to
an end, not an end in itself. Fiddling with the computer is a diversion, a
distraction that takes time from their primary objective.
It's a philosophical issue. Should users adapt to the computer or should the
computer adapt to the user? If you actually want people to use your
product, you'd better think more along the lines of the latter.
 

Re:Re: Linux on the desktop *not* imminent

Ender wrote:
[...]
Quote
You described only final action of installation. :-) I never saw Linux
applications prepared to such level of automation of installation. Usually
you got something ...tar.gz. You unpack this package, then:
1. configure
2. some libs, tools not found, use rpm to install it from distribution
CD-rom
3. make
3.1. Wait from few minutes to few hours depending from size of app and
your CPU horsepowers
4. make install
5. guess how to run that program now (there is no such thing as system
meny in Linux)
[...]
Oh dear, Ender, you are not really thinking.
I can think of a few which does not require the above,
Kylix!, Quake, Opera, VMware (to an extent), Lotus Notes etc.
It can be done if the developers and the end users want it.
I personally don't, I prefer to know what exactly the install
is doing.
B
--
www.mailtrap.org.uk/
 

{smallsort}

Re:Re: Linux on the desktop *not* imminent

BG>Oh dear, Ender, you are not really thinking.
BG>I can think of a few which does not require the above,
BG>Kylix!, Quake, Opera, VMware (to an extent), Lotus Notes etc.
BG>It can be done if the developers and the end users want it.
BG>I personally don't, I prefer to know what exactly the install is
BG>doing.
Please read letters above. pNichols trying to tell that using _make_ is not
difficult than clicking on setup.exe. I'm disagree with him. Of course it is
possible to create easy and simple deployment routines under Linux, but many
developers won't do that.
Some time ago i wrote client-server (Delphi + Firebird) app for network of
small shops. They was low level customers and was unable to pay much. The
deployment routines was extremely simple. Install Interbase - few mouse
clicks. Copy application on the clients. Copy database template on the
server. Enter single setup string at the program first start. That
deployment was successfully executed many times by the girl - manager. I'm
pretty sure that for Linux she will not be able to install anything - even
with RPM. This means more time & money cost for them and probably they just
refuse to deal with me if Linux was used.
 

Re:Re: Linux on the desktop *not* imminent

Ender,
Quote
You described only final action of installation. :-) I never saw Linux
applications prepared to such level of automation of installation. Usually
you got something ...tar.gz. You unpack this package, then:
1. configure
2. some libs, tools not found, use rpm to install it from distribution
CD-rom
3. make
3.1. Wait from few minutes to few hours depending from size of app and your
CPU horsepowers
4. make install
5. guess how to run that program now (there is no such thing as system meny
in Linux)

That is where "distribution" can help. For example, with Gentoo you do "emerge openssh" and it does steps 1-4 of your description in one sweep (some computers are faster then others <g>) action to install ssh client/server, and you don't have to worry about "distribution CD-ROMs" or "some libs".
Mind you, you have to know how to use it (see step 5.), or, alternatively, you can read the manual <g>...
Alex
 

Re:Re: Linux on the desktop *not* imminent

Why would IT suppliers not be interested. There are different levels
of desktop support. For large corporates that only need an office
package and in house corporate software (most of which runs on
mainframes anyway) there is a very lucrative market. Hence the entries
of Novell and Sun into these markets. Close down the desktop and have
a central server dictating what applications can run. Already the
Chinese government has committed to buying 1 million java desktops from
sun.
Cheers
Dean
JQP wrote:
Quote
"Michael Schnell" < XXXX@XXXXX.COM >wrote in
message news: XXXX@XXXXX.COM ...
>So the IT suppliers might not be interested. This move is driven by
>the customers.

Without more support from IT suppliers, most business customers won't
be interested either.

Maybe government. Government has a long history of poor
decision-making when it comes to IT.
 

Re:Re: Linux on the desktop *not* imminent

"Dean Hill" < XXXX@XXXXX.COM >wrote in message
Quote
Why would IT suppliers not be interested.
Several reasons --- all of which add up to a lack of commercial opportunity.
Look around. Where are all the companies jumping on the bandwagon to
produce Linux desktop software?
Quote
Hence the entries of Novell and Sun into these markets.
Both of whom have been losing money and are desperately looking for ways to
turn things around. If they succeed, maybe others will follow but it's too
early to declare success in either case.
Quote
Close down the desktop and have
a central server dictating what applications can run.
Entirely possible but what you're describing is more of a network terminal
rather than a desktop computer.
Quote
Already the Chinese government has committed to buying 1 million java
desktops from sun.
If you look at the official press release, you'll see that the Chinese
government agreed to buy *up to* 1 million Java desktops. How many they
actually buy is anyone's guess ... one, a dozen, a hundred. Any of these
satisfy the agreement.
The intentionally vague wording and the fact that there was no mention of
the expected value of the deal leads me to believe that it was mainly just a
marketing stunt orchestrated by Sun. They were hoping for people to do
exactly as you did --- take the number given as an upper limit and run with
it.
 

Re:Re: Linux on the desktop *not* imminent

Ender wrote:
Quote
>The Linux shared object system and the rules that govern application
>execution is extremely simple and flexible. If you follow these rules
>and do things the Linux way then you can accommodate most any Linux
>application without creating so called "DLL.hell"
There is no "DLL hell" from Windows 2000 times.
What did they do - abandoned DLL concept? Where there is DLL, there is
DLL hell. Don't tell me about DLL cache (a) it is applied only to system
DLLs, and not to commonly used third party ones, (b) it can be turned
off and most often IS turned off to save 250 Mb of space.
--
Eugene Mayevski
EldoS Corp., CTO
Security and networking solutions
www.eldos.com
 

Re:Re: Linux on the desktop *not* imminent

Quote
>There is no "DLL hell" from Windows 2000 times.
EMS>What did they do - abandoned DLL concept? Where there is DLL, there
EMS>is DLL hell.
Do you have better concepts than DLLs? Maybe it located in Linux? Ha! Same
thing, and Borland demonstrated to us how unprotected Linux from stupid
actions. I'm tried to install that "libqt.so.2" into the system (not only
for Kylix apps). Everything Qt2 dependent immediately crashed. Same DLL
hell, it's just has other name - SO Hell.
EMS>Don't tell me about DLL cache
Why don't tell? There are two mechanisms to prevent DLL Hell - DLL cache and
private DLLs.
EMS>(a) it is applied only to system DLLs,
Uncontrolled changing system DLLs was cause of failures in 9 of 10 times.
EMS>and not to commonly used third party ones,
There are "private DLL" concept.
EMS>(b) it can be turned off
Well hands of stupid admin can ruin the whole installation of every OS. It
is like to make all files writable by anyone and then claim that there is no
access rights and file protection in Windows NT because they may be turned
off.
EMS>... and most often IS turned off to save 250 Mb of space.
Speak for youself please. Maybe you turn it off most of time ("I'm claim
that every idiot that 'upgrade' core libraries to get his program running is
smarter than guys from the microsoft. And i want that installation of that
idiot 'upgrade' my libraries, kernel, etc." Signed.), but i'm do not do this
and many people i know do not do this.
Please read "Windows Storage System technical articles: The End of DLL Hell"
by the Rick Anderson.
As addition i'm never encountered any signs of DLL hell from the times of
W'2K.
 

Re:Re: Linux on the desktop *not* imminent

Ender wrote:
Quote

Do you have better concepts than DLLs? Maybe it located in Linux? Ha! Same
thing, and Borland demonstrated to us how unprotected Linux from stupid
actions. I'm tried to install that "libqt.so.2" into the system (not only
for Kylix apps). Everything Qt2 dependent immediately crashed. Same DLL
hell, it's just has other name - SO Hell.


Well, as a matter of fact Linux provides mechanisms to help overcome
problem as you mention above, that the nature of Kylix and Kylix's
made applications requirements combined with provided with it
deployment instructions, it licensing constrains and other factors may
create difficulties in deploying Kylix applications.
The concept of shared objects in not new and serves well in many
different operational systems for computers. So, where exactly was the
problem with deployment of Kylix applications? One would ask.
To make a long story short; Borland choose to provide a unique
enhanced Qt library with Kylix, what was not bad idea at all, but they
call it exactly like a commonly present on many Linux systems regular
Qt library. As a result of it the Borland's special QT shared object
could be shared only by a group of Kylix made application and it
couldn't be deployed in a way like many other Linux shared objects are
deployed if follow the Linux shared objects naming convention.
Furthermore, to make things worst most of Kylix output files, like
binary executables, shared objects, packages as well many supplied
with Kylix (and required for deployment) redistributables has
hard-coded libqt.so.2 link name in it. One could rename the Borland's
QT library and recreate the link, but it was not possible (license
constrains) to change the the hard-coded links in all of those files
in question..
Consequentially, an unaware Kylix user when attemptes to deploy his
first Kylix Qt application according to the Kylix deployment
suggestions, had only 1 in 3 chance to be successful, and only because
many of the installed on the system qt based programs could tolerate
the Borland's Qt or Kylix made program could tolerate the original
system Qt (only do to coincidentally matching ABI of QT library and
libqtintf interface). Many other users faced a significant
difficulties in running Kylix made application outside the Kylix IDE.
The Kylix Qt library couldn't be deployed to any of the common shared
objects specific areas of the Linux system, those who unknowingly did
this often crashed other KDE/Qt applications or the Kylix application
did not work. (As we can see, employing superior windows concepts and
methods in that unperfect Linux world, as explained above, could
indeed create a small version of the Windows dll hell <g>)
Kylix 3 improves things. Borland provides its own version of Qt
library as usual, but also provides a new concept, a new version of
it, that new shared object combines somehow the Pascal->C++ interface
former libqtintf with the Qt lib and it is uniquely named.
Incidentally, one other factor which actually improved the
deployability of Kylix programs comes form the Linux side of the
fence; it was that Linux distributions start using more current
(newer) Qt 3.x libraries commonly linked by libqt.so.3 than the used
by Kylix ancient Qt 2.x. The naming conflict disappeared with
disappearance of the libqt.so.2 and Kylix 1, 2 and Kylix 3
application started working. Linux outgrows this Kylix application
deployment problem.
Going back to the subject; indeed Linux is a very versatile system and
because of it was and it is possible to deploy Kylix 1, Kylix 2 and
Kylix 3 application to most any commonly used Linux distribution in
the past and in the present, it was just more complicated for Kylix 1,
and for Kylix 2 application than it should be. In general the solution
for this problem was utilization of the capability of Linux system to
provide unique values to a set of system variables, to a new created
process and heavy use of LD_LIBRARY_PATH to direct the Linux loader
to take interest with these specific to kylix shared objects first..
Linux is a really cool system - used and abused and keep on going...
juliusz
--
InstallMade - Kylix-specific installer/builder
www.superobject.com/installmade/
www.superobject.com/imoe/download.html
 

Re:Re: Linux on the desktop *not* imminent

Eugene Mayevski [SecureBlackbox] wrote:
Quote

Well, .NET makes the DLL hell more hard to create by adding version to
the "sign of uniqueness" of the shared object. Including version to the
name and using symlinks is also a good idea (if file system supports this).

It is one of those examples how Microsoft is trying to improve the
design of own systems by innovating/borrowing old concepts and methods
from the Unix/Linux world. ;-)
juliusz
--
InstallMade - Kylix-specific installer/builder
www.superobject.com/installmade/
www.superobject.com/imoe/download.html
 

Re:Re: Linux on the desktop *not* imminent

Ender wrote:
Quote
EMS>What did they do - abandoned DLL concept? Where there is DLL, there
EMS>is DLL hell.
Do you have better concepts than DLLs?
Well, .NET makes the DLL hell more hard to create by adding version to
the "sign of uniqueness" of the shared object. Including version to the
name and using symlinks is also a good idea (if file system supports this).
Quote
EMS>(a) it is applied only to system DLLs,
Uncontrolled changing system DLLs was cause of failures in 9 of 10 times.
This doesn't cnacel DLL hell for another 10% of times.
Quote
EMS>and not to commonly used third party ones,
There are "private DLL" concept.
there are shared DLLs offered by dev.tool vendors. Like different
runtimes, shared libs (symantec and borland are the examples) etc. They
are not covered by DLL cache. and they are subject to the problems.
Quote
Speak for youself please. Maybe you turn it off most of time ("I'm claim
that every idiot that 'upgrade' core libraries to get his program running is
smarter than guys from the microsoft. And i want that installation of that
idiot 'upgrade' my libraries, kernel, etc." Signed.), but i'm do not do this
and many people i know do not do this.
Boy, check your words before sending a letter to public place.
--
Eugene Mayevski
EldoS Corp., CTO
Security and networking solutions
www.eldos.com
 

Re:Re: Linux on the desktop *not* imminent

Quote
>Speak for youself please. Maybe you turn it off most of time ("I'm
>claim that every idiot that 'upgrade' core libraries to get his
>program running is smarter than guys from the microsoft. And i want
>that installation of that idiot 'upgrade' my libraries, kernel, etc."
>Signed.), but i'm do not do this and many people i know do not do
>this.
EMS>Boy, check your words before sending a letter to public place.
:-)))
To other guys, below is untranslateable play of words in russian. But
nothing offending.
Може?объяснитьс?по русски. Ты чт?то принял личн?на свой счет? ?моей
точк?зрения попытк?изменени?системны?библиоте?прикладной программой -
чистый идиотизм. Ты не согласен?
 

Re:Re: Linux on the desktop *not* imminent

JQP wrote:
Quote
Several reasons --- all of which add up to a lack of commercial
opportunity. Look around. Where are all the companies jumping on
the bandwagon to produce Linux desktop software?
IBM are pushing the company I work for in just that direction (with
Java). The question of whether there is a viable market has yet to be
decided, but things are moving in the right direction. It will not be
long before there is a result one way or another. I think that the
push will come more from the developing nations. Most of these cannot
afford to spend an additional $200 for an OS. My sisters company is
already using Open Office on all computers without any problems. Not a
big company (7 computers) but in South Africa this cost is a
substantial saving. Although I own MS Office, I use Open Office at
home. I find it much lighter. This is the way things are moving. If
MS was only charging $30 per seat for Windows XP. Linux would not have
even made it onto SlashDot <g>. I agree that the jury is still out.
At lease 20%-30% of companies in South Africa still have Windows 95
installed on their computers in my experience. Price is an issue.
Quote

>Hence the entries of Novell and Sun into these markets.

Both of whom have been losing money and are desperately looking for
ways to turn things around. If they succeed, maybe others will
follow but it's too early to declare success in either case.
They are both in a quandry. Novell is betting the company on Linux.
The Red Carpet solution is what I am leaning towards. Already there
are a lot of developers building Web Based applications. This is
because there are deployment issues and the like. These types of moves
play into Novell's hand.
Quote

>Close down the desktop and have
>a central server dictating what applications can run.

Entirely possible but what you're describing is more of a network
terminal rather than a desktop computer.

If Novell can produce a clean desktop (Suse) and good server deployment
(Ximian Red Carpet), they have an answer. Most companies don't need
anything more then an Office Suite, a Web Browser, E-Mail and a
mainframe session / corporate application. For corporates, a office
suite terminal is all they need.
Quote
>Already the Chinese government has committed to buying 1 million
>java desktops from sun.

If you look at the official press release, you'll see that the Chinese
government agreed to buy *up to* 1 million Java desktops. How many
they actually buy is anyone's guess ... one, a dozen, a hundred. Any
of these satisfy the agreement.

The intentionally vague wording and the fact that there was no
mention of the expected value of the deal leads me to believe that it
was mainly just a marketing stunt orchestrated by Sun. They were
hoping for people to do exactly as you did --- take the number given
as an upper limit and run with it.
That sounds plausible.
 

Re:Re: Linux on the desktop *not* imminent

The same could be said for .Net too. I don't see wide adoption
happening until after Longhorn ships, sometime in 2007!
JQP wrote:
Quote


www.sdtimes.com/download/images/SDTimes093.pdf

"The adoption of Linux as a Windows desktop alternative is not imminent ..."

SD Times, Jan 1, 2004 by Andrew Binstock, principal analyst at Pacific Data
Works LLC, a company that specializes in technology assessments and market
analyses for the high-tech industry.



--
Thomas Miller
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
sourceforge.net/projects/dbexpressplus