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

Re: Linux on the desktop *not* imminent


2004-01-10 11:58:49 AM
kylix2
Eugene Mayevski [SecureBlackbox] wrote:
Quote
pNichols wrote:

>You do not have to supply source code for a make. See post to JQP.
>If you have ever installed DB/2 on Unix, makes are exactly what IBM is
>using.

Do they ship .o(bj) files? And how does this help them to solve the
problem with different versions of different libraries? For me it looks
like the old "good" DLL hell

That last part is true (dll hell), and that is what a make file script will
do. If a application is delivered correctly (IBMs stuff is BTW), they
should look for various lib files and if it cannot find that lib, install
it, or go to a source where it can be installed (ie internt, intranet, or
deleivery medium such as CDRO or DVD). Oracle uses the same concept, they
just hide most of the details behind a Java GUI,
Not all of make need to be in a obj format either. There can be fully
compiled modules that are linked with certain precompiled objs or libs that
are linked in the final build/install. Common practice in the Unix world.
 
 

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

Eugene Mayevski [SecureBlackbox] wrote:
Quote
pNichols wrote:

>If a developer cannot type make <filename>at a terminal, then I would
>not call them a developer <G>. If a person has never done conditional
>linking and compiling, even on and including Windows, I think I would
>refer to them as a point and click Guru, not a developer <G>.

You see, our goal (from vendor's point of view) is to sell the goods
(software), no matter whether we think that those developers are dummies
that must go take some classes first. Unfortunately, there are way too
many lazy "programmers" who prefer point-and-click.

There are, unfortunately, alot of people who call theselves programmers,
whose entire "claim to fame" is that they can go to VB, Delphi, or some
other RAD tool and drop a few components on a form and call themselves
"programmers":):).
I like RAD too, it saves time, but it sure has muddied the waters as to what
constitutes a real programmer (no I am not an EMACs junkie either, I stay
away from such "true programmer" editors if I can help it <G>).
A programmer should know basic OS things, and not be totally dependent on
some point and click interface. If they do not know what a batch file or
shell script is, I question whether they are truly programmers. Component
assemblers might be a better term in this PC age <LOL>.
I would think, however, that if a person can type something like
function RunProgram(ProgramName:String):boolean
var
pi:TProcessInformation
si:TStarupInfo;
sec:TSecurityAttributes;
waitReult:DWord;
exitCode:DWord;
begin
FillMemory(@simsizeOf(si),0);
si.cb:=sizeOf(si);
sec.NLength:=sizeOf(sec);
sec,lpSecuityDescriptor:=nil
sec.bInhereitHandle:=true;
if(CreateProcess(nil,PChar(ProgramName),
@sec,@sec,true,NORMAL_PRIORITY_CLASS,
nilnil,pi,si)=true) then
waitResult=WaitForSingleObject(pi.hProcess,100);
.....
....
return result;
end;
they sure as hell can type:
home/>make /usr/local/myapp/Make
<HUGE G>
I do understand your dilemna however. Yes, we all want to "sell what we
write" and making it as easy as possible to install and use should be a
priority. Good instructions and adequate documentation that is clearly
written, is what is missing I believe, more than degree of difficulty.
In fact I had one customer who wanted me to automate Network installations
as a part of our client srver application process. I explained to them if I
could do that, I would not be working for them or anyone else :)
I can understand that a user coming from Windows, is not going to know
everything they need to about Linux within the first week. But I seriously
doubt that those who have been using Windows, grabbed a mouse their first
day and started instaling their own programs, editing configuration files
directly or through Control Panel, either.
Quote

If you have a zoo of compilers like I do (Delphi 2-8, C++Builder 3-6,
VC++ 5-7.1, eVC 3.0 (for 4 platforms), CW 7-9 and a bunch of Javas), you
will see how much trouble can simple "make <filename>" cause :). Once I
spent a couple of hours trying to find out, why under certain conditions
library built with eVC 3.0 didn't work. It appeared, that eVC's make
took environment var. from VC 7.1. which was called before eVC.

Now there I think we can find full and absolute agreement. Another reason
why I don't think MS' NET does all languages, is going to be the citadel of
hope some believe it is.. A Tower of Babel perhaps, better describes it
<G>.
I am not laying this as an odious omen at the feet of MS alone, by any means
either. This IS a problem all can have, when are dealing with a Babel of
languages, compilers, and the like. I have worked in far too many
Enterprises where it takes an army to update an application, simply because
they used hump{*word*249} dozen languages to write it in (many of which have long
ago vanished). My motto usually is, why bastardize, when it is unnecessary.
Of course, I understand, I am not everyone. <G>
Quote
Yes, but you have to tell this to users. When we offered our ElPack
components, people complained that FocusRect (that dotted rectangle
around the text) looks different from standard TButton, so they won't
buy ElPack. And you think those people (developers, BTW!) will change
their cool seat and cool salary to Linux?

Well soon, it may be immaterial want they want to do. Linux is growing
rapidly, and it is only a matter of time before you learn to code for it,
or be on the outside looking in. I am not saying Linux will kill MS, but I
do believe they will co-exist. Linux already has a larger Server
marketshare than Windows, and the client side has overtaken Mac already.
Oracle and IBM are pushing Linux big time. Last time I looked, IBM was the
largest IT company in the world, and Oracle is number three software
company. They did not get that way by being stupid. <G>
There are tons of developers who lamented having to move away from DOS,
Windows 3.z to 95, and look on the NGs for those disavowing that they will
ever code in Java or NET. However, necessity is the mother of all invention
:)
Quote
>BTW, nearly all modern Linux distros have point and click RPM
>installation routines.

This is worth looking at, as soon as we deliver something for linux.


Suse, Mandrake, Lycoris, Red Hat all have this. I do know that RHat has
(like the others) auto_update features, that wil install pratically
everything for you, under the covers via RPMs and Makes. Debian and Gentoo
probably have the best package installation routines. Apt-Get is hard to
beat!
Have a great day!!
 

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

Eugene Mayevski [SecureBlackbox] wrote:
Quote
Hmm? How? I am not a newbie with linux, right now I am trying to think
from (a) vendor's (not coder's) and (b) user's point of view.

OK, fine, from vendor's point of view; a vendor should have coders,
packagers and so on..people who specialize in this sort of things. As
I have mention before that the Linux shared object system and the
rules that govern application execution are extremely simple and
flexible. If you (someone) follow these rules and do things the Linux
way then you can accommodate most any Linux application without
creating problems for the application and or other application on the
system.
Any Linux application has its own requirements and will run only if
all this requirements are met. If you want to create installation
package and/or install an application into Linux box then the first
thing you (one) need to know (precisely) what this application
requires. If you know exactly what this application needs and why,
then the next important step is to provide to this application all
these ingredients, to make it happy, but (and this is extremely
important) according to rules the Linux system is govern. You cannot
just use your hard earned Windows experience or dump into the system
your files and expect miracles. The first obvious rule is to provide
for this application all it needs and the second rule is not to brake
anything on the system for other application to run.
Oh well, easy to say, but how to do this? To make it all possible,
there is Linux shared objects versioning system and there are rules
for proper positioning of shared objects, links usage and creation.
The developer (packager) needs just to follow these rules and to know
what the ld.so.conf file is for, what are the ways the Linux loader is
searching for shared objects and where, for what is the PATH,
LD_LIBRARY_PATH, LD_PRELOAD and so on.., that by definition Linux is
network based multiuser operating system build with security in mind;
and other basic information.
The software vendor, packager, developer needs to know all of these in
order to deliver to the customer (user) the software in a most
convenient reliable form as possible. No matter if it will be in a
form of distro-version specific RPM package or distro-agnostic
installation package.
Quote
one should tell this to customers. Our goal is to sell them the product,
no matter how dumb or uneducated they are. If the user wants Linux
solutions, he must either educate himself, or the vendor must find a way
to help the user avoid problems. Right now I see it easier to create
complex scripts in Wise than to build custom installations on Linux.
Moreover, the user finds it easier to use *Installation Wizard* than RPM
manager or Make script. That is the problem.

Right...except that I believe that the customers are never dumb, at
last they are smart enough not to buy dumb products. ;-)
From user's point of view; The best way for a person who are not yet
very much familiar with all the Linux internals is to stick to the
precompiled RPMs his distribution provides (distribution-version
specific). For example each time a new version of Mandrake is
released along it there are released thousands of ready to use
(precompiled with the same compiler against the same set of libs)
programs, many of them are in fact commercial software. It is
reasonable to expect that all this distro-specific RPM packages will
perform satisfactory and will not create conflicts. (If they do or
because of security concerns then the fix is provided, in days or
hours via the automatic upgrade system ).
Often, installing to the Linux system alien RPMs will also work, but
you may brake a few things as well, it is your (user) choice.
Installing application from a source is also possible and often use,
but the user has to be aware of many requirements the compilation and
linking process demands. In this situation on the Linux box needs to
be installed the compiler as well many other essential to the program
making process utilities (development environment) So, again for the
novice user it is best to wait until someone will prepare a ready RPM
for this particular distro or just ask the developers or someone who
has experience with it for help. (works every time)
I absolutely agree that the commercial software vendor should create
an easy way to install and use the software for all the intended
supported platforms. How difficult it is? The level of difficulties
are very relative. For example once you have the SRPM created then in
most cases to make a new version is a matter only of compiling it
again in the environment you want to support (the new distro-version).
As for Kylix made applications there is no major problem with glibc or
installing/running it on wide spectrum of Linux distros. The problems
are mostly related only to Kylix by itself do to lack of fixes and
upgrades.
juliusz
--
InstallMade - Kylix-specific installer/builder
www.superobject.com/installmade/
www.superobject.com/imoe/download.html
 

{smallsort}

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

juliusz 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"
Hmm? How? I am not a newbie with linux, right now I am trying to think
from (a) vendor's (not coder's) and (b) user's point of view.
Quote
. Even if I am a smart user with knowledge of A, B and C, most likely I
will give up.
Linux is a very powerful flexible, simple, yet complex operating sytem.
Smartens, intelligence or such has not much to do with the necessary
skills required to prepare installation packages, do administrative or
other tasks and these skills one cannot acquire over night, it is
usually a very long and never ending learning process.
one should tell this to customers. Our goal is to sell them the product,
no matter how dumb or uneducated they are. If the user wants Linux
solutions, he must either educate himself, or the vendor must find a way
to help the user avoid problems. Right now I see it easier to create
complex scripts in Wise than to build custom installations on Linux.
Moreover, the user finds it easier to use *Installation Wizard* than RPM
manager or Make script. That is the problem.
--
Eugene Mayevski
EldoS Corp., CTO
Security and networking solutions
www.eldos.com
 

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

Eugene Mayevski [SecureBlackbox] wrote:
Quote
JQP wrote:

>For example, I've been unable to find a good US payroll system for Linux.
>Dozens are available for Windows with varying price tags and capabilities
>to fit almost any need.

From vendor's point of view - how can he be able to distribute
commercial software for linux, when he needs to build against a number
of versions of libc and other libraries used?

From customer's point of view -- I am trying to install a binary of
some application and this binary requires libraries A (version 2.5+),
library B (version not higher than 3.0) and library C (which is supposed
to be in most recent version, but that version is unstable and will
crash another application I use). Even if I am a smart user with
knowledge of A, B and C, most likely I will give up.

use rpm or don't use exernal library... the exe will be bigger...
 

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

pNichols wrote:
Quote
I can understand that a user coming from Windows, is not going to know
everything they need to about Linux within the first week. But I seriously
doubt that those who have been using Windows, grabbed a mouse their first
day and started instaling their own programs, editing configuration files
directly or through Control Panel, either.
Anyway I think it's easier for them to understand the concept of
point-and-click -- this is what 6-month-old babies do. Those babies
don't go typing "make ..." <bg>
Quote
Well soon, it may be immaterial want they want to do. Linux is growing
rapidly, and it is only a matter of time before you learn to code for it,
or be on the outside looking in. I am not saying Linux will kill MS, but I
do believe they will co-exist. Linux already has a larger Server
marketshare than Windows,
Already? I thought it always had larger marketplace -- Windows not so
long ago became a server vendor. Actually, in 1996, when NT 4 was
released (WinNT 3.5 was a so-so server, although internally it was
better than the next versions).
Quote
There are tons of developers who lamented having to move away from DOS,
Windows 3.z to 95, and look on the NGs for those disavowing that they will
ever code in Java or NET. However, necessity is the mother of all invention
and what about .NET on linux? It seems to be a good candidate, and in
this case why learn linux if .NET is there?
Quote
Suse, Mandrake, Lycoris, Red Hat all have this. I do know that RHat has
(like the others) auto_update features, that wil install pratically
everything for you, under the covers via RPMs and Makes. Debian and Gentoo
probably have the best package installation routines. Apt-Get is hard to
beat!
Redhat doesn't release end-ser systems anymore, IIRC.
--
Eugene Mayevski
EldoS Corp., CTO
Security and networking solutions
www.eldos.com
 

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

Eugene Mayevski [SecureBlackbox] wrote:
Quote
pNichols wrote:


>I can understand that a user coming from Windows, is not going to know
>everything they need to about Linux within the first week. But I
>seriously doubt that those who have been using Windows, grabbed a mouse
>their first day and started instaling their own programs, editing
>configuration files directly or through Control Panel, either.

Anyway I think it's easier for them to understand the concept of
point-and-click -- this is what 6-month-old babies do. Those babies
don't go typing "make ..." <bg>

>Well soon, it may be immaterial want they want to do. Linux is growing
>rapidly, and it is only a matter of time before you learn to code for it,
>or be on the outside looking in. I am not saying Linux will kill MS, but
>I do believe they will co-exist. Linux already has a larger Server
>marketshare than Windows,

Already? I thought it always had larger marketplace -- Windows not so
long ago became a server vendor. Actually, in 1996, when NT 4 was
released (WinNT 3.5 was a so-so server, although internally it was
better than the next versions).

>There are tons of developers who lamented having to move away from DOS,
>Windows 3.z to 95, and look on the NGs for those disavowing that they
>will ever code in Java or NET. However, necessity is the mother of all
>invention

and what about .NET on linux? It seems to be a good candidate, and in
this case why learn linux if .NET is there?

Because Mono NET is not compatible with MS' NET for one thing, it is not
finished for another, and will no doubt always lag behind MS' version.
The only thing MONO NET can do, is to go its own way and forget 100 %
compatibility. Then it becomes just another framework, where you recode and
compile for different platforms (unless you are going to load the NET
runtimes for Mono on Windows, instead of using MS' NET CLR). Then it
becomes kind of another C++.
Besides, I do Java work everyday. Java is truly XPlatform, but there are
always system calls you will need to make at one time or another. Yes,
using as framework like Java or NET can separate many of these issues in
platform switching for you, but not in toto.
Quote
>Redhat doesn't release end-ser systems anymore, IIRC.

Redhat has really put a dagger through their hearts, IMHO. There is the free
Fedora core, and some will use it, but personally, I feel the best bet on
Linux is going to be Novell's Suse Linux. That is what Sun is using on its
Java Desktop and they have been selling the hell out of it. Also, IBM has
made a deal with Suse to make it their desktop platform, and they already
use Suse on all their non Intel based servers and offer both RedHat and
Suse on their Intel line of servers. Sun has also made a deal with AMD for
the 64 bit Atlon, running Suse Linux and/or Solaris.
Oracle supports both Suse and Red Hat, as does CA. It is a personal choice
of course, but Novell's purchase of Suse gives it alot of momentum.
 

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

"pNichols" < XXXX@XXXXX.COM >wrote in message
Quote
Redhat has really put a dagger through their hearts, IMHO.
Either that or Red Hat knows something that you don't (or you won't admit).
I'd bet on the latter.
 

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

Eugene Mayevski [SecureBlackbox] wrote:
Quote
pNichols wrote:


>I can understand that a user coming from Windows, is not going to know
>everything they need to about Linux within the first week. But I
>seriously doubt that those who have been using Windows, grabbed a mouse
>their first day and started instaling their own programs, editing
>configuration files directly or through Control Panel, either.

Anyway I think it's easier for them to understand the concept of
point-and-click -- this is what 6-month-old babies do. Those babies
don't go typing "make ..." <bg>

I agree GUI is more intuitive. That is why many new Linux distros, are
getting more to point and click. My point was, however, that one is not
inherently more difficult than the other. We still have to tell people how
to use exloere and how to create a new folder on Windows. That too,
requires some typing. Is typing a folder name on the root C:\ drive really
more difficult to explain that click the terminal icon, go to the directory
and type Make MakefileName?
Quote
Already? I thought it always had larger marketplace -- Windows not so
long ago became a server vendor. Actually, in 1996, when NT 4 was
released (WinNT 3.5 was a so-so server, although internally it was
better than the next versions).

>There are tons of developers who lamented having to move away from DOS,
>Windows 3.z to 95, and look on the NGs for those disavowing that they
>will ever code in Java or NET. However, necessity is the mother of all
>invention

Linux is much more a newcomer to the OS scene than Windows actually.
Windows entered the server market with NT 3.5. No one expcept the real
"fringe" hacker started using Linux until kernel 2.2.
If you are thinking "UNIX" rather than "Linux", you would be correct.
Quote
and what about .NET on linux? It seems to be a good candidate, and in
this case why learn linux if .NET is there?

NET is a wait and see thing. We know that currently there are
incompatibility issues with Mon.NET and MS.NET. If these inconsistencies
continue (and it is likely they will), then you will still wind up with two
code bases, one for Linux/Mono and one for MS. I really do not see this as
an advantage over Java, which truly provides xplatform.
Mon does not yet have a full version ready. How long will it be before they
get version 1.0 spec out. MS has already released a later spec. Mono will
never keep up with MS. Eventually, you will have to decide if you want to
go full Mono.NET or MS.NET.
Quote
Redhat doesn't release end-ser systems anymore, IIRC.

Redhat cut their own throats, IMHO, with that brilliant move <G>. I see the
winner of the distro wars emerging, and it looks as though it will be
Novell/Suse. Sun has made a deal with Suse for the Java Desktop and they
have already sold over 4,000,000 copies of it. They also made a deal with
Novell/Suse about the Athlon 64 bit chip and with AMD. Currently, Suse is
the only distro certified to run on AMD's Athlon 64 and 64FX.
In addition, IBM uses Suse almost exclusively on non x86 processors. It
supports everything from their x86 line to their monster OS390 Mainframes.
Red Hat does not. They (IBM) will also promote Suse for their desktop
systems. IBM will offer either Red Hat or suse for their x86 server
offerings, as will HP.
Novell also has good name recognition in the Enterprise world and an
installed base to work from. That will not hurt Suse either.
 

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

pNichols wrote:
Quote
inherently more difficult than the other. We still have to tell people how
to use exloere and how to create a new folder on Windows.
Why create folders? Does average user needs them? He puts documents to
"My documents" and that's all. He can even know nothing about folders.
Quote
Linux is much more a newcomer to the OS scene than Windows actually.
Windows entered the server market with NT 3.5. No one expcept the real
"fringe" hacker started using Linux until kernel 2.2.
NT 3.5 ... I remember it being a server (used to administrate it in
1995-96). A hybrid of hippopotamus and unicorn. It wasn't really a
server, at least for more than 10-15 computers. And when did kernel 2.2
appear?
Quote
continue (and it is likely they will), then you will still wind up with two
code bases, one for Linux/Mono and one for MS. I really do not see this as
an advantage over Java, which truly provides xplatform.
.NET for me has a much better (although bound to Windows) design than
Java. No wonder, - they've taken most from VCL.
Quote
In addition, IBM uses Suse almost exclusively on non x86 processors. It
supports everything from their x86 line to their monster OS390 Mainframes.
Red Hat does not. They (IBM) will also promote Suse for their desktop
systems. IBM will offer either Red Hat or suse for their x86 server
offerings, as will HP.
Maybe, maybe ...
--
Eugene Mayevski
EldoS Corp., CTO
Security and networking solutions
www.eldos.com
 

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

"Eugene Mayevski [SecureBlackbox]" < XXXX@XXXXX.COM >wrote in message
Quote
Why create folders? Does average user needs them? He puts documents to
"My documents" and that's all. He can even know nothing about folders.
Give it up. *nix heads just don't seem to get it. While they debated the
virtues and logic of the command line, MS stole the whole market. And they
still don't understand how or why it happened.
 

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

Quote
>While i'm agree with you about developer qualification i'm disagree with
>entrie concept of "make" and/or "rpm". It require some actions and
>knowledge from people, while that knowledge and actions actually not
>required. Installation package and OS already have all information they
>required for installing, so why someone from end-users (even when it is
>developers) should learn that stupid concepts of make and rpm? Clicking
>on setup.exe is most simple and obvious thing, any complication from that
>point is perversion.
pNichols wrote:
And if you use a Windows installation program, then you have to know
something about InstallShield or Wise scripting. So what is the differece
between that and builidng a Make script file,or packaginf an RPM, or
(better yet) an XML file using something like Apache's Ant? I really do
not see much of a difference.
As far as clicking on a setup.exe, how is typing in "/>make setup"
different? Do you mean it is easiser to find that Windows explorer icon,
locate the drive or CD-ROM, and click on a directory and/or icon, than it
is to click on a terminal icon, and type make? How it one more difficult
than the other? Different yes, degree of difficulty=SAME.
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)
If something goes wrong on any stages of that installation process, ordinary
user never understand what is happened.
Quote
>p>So, you swapped kernels or the GDI and/or Windows GUI front end,
>p>without having to buy a new Windows? That is pretty amazing.. Mind
>p>telling us how you did this? <VBG>....
>
>Changing kernels... h-m-m-m... life experience said that it bring only
>problems like compatibility with existing software. Occasionally it give
>support to new types of hardware.
Not only that, but you could have any number of issues resolved in
recompiling kernels.
That could range to optimization algorytms as per CPU
instructions, graphics throughput, enhanced or bug fixed I/O connectivity,
or enhanced security. As far as GDI, you can update and upgrade your GDI
for speed enhancements, bug fixes, etc, and optimize settings for CPU and
Graphics card instructions, without having to write to the lowest common
denominator. Windows offers zilch for this.
Since Windows builit on microkernel architecture 99.99% of problems and/or
enhancements may be fixed/introduced through installing of appropriate
drivers.
Quote
Another aise, what if you discover a major bug in the new release that was
not present in a former release? What can you do about it with a
proprietary OS? (1) You wait until the OS distribution team get ready to
relese q patch for it, or (2) You go back a version, meaning yet another
fresh installl. What do you do on an open source OS? go to var/backup and
recompile the kernel or download another version and make it.
I will rollback only bad driver. Nothing more.
Quote
>p>I am not talking about swapping out the entire OS, that was the
>p>point. I was talking about incrementally building and/or updating the
>p>OS, without having to do a new install.
>
>You will laugh, but this is not necessary. Completely. Tell to me single
>reason why i should change kernel of Windows NT (except for movement from
>single processor kernel to multiple processor kernel).
Well is Windows MT better or worst than Windows 2000, XP, or 2003? Are not
the kernels in each of these versions different? If they are not, then why
upgrade?
No one force you to upgrade. You may stay with Windows NT as long as you
want (actually, as you have drivers for new hardware). Correctly written
Windows application should flawlessly work in all versions of Windows
NT/2K/XP. Because there is only two major lines of Windows 9x and NT, there
is very easy to tune application to work with both.
Quote
If they are, and you do not care anything about the eye candy of
XP Themes, then why should I have to upgrade my entire OS, when I only
want new i/o speed up operations and security/stability enhancements?
Because OS is not only kernel. OS is kernel, APIs, services and tools.
However, you may not upgrade. Upgrade only drivers and you will be Ok.
Quote
Many people are running Red Hat 6.2 on a 2.4.18 or higher kernel. They may
be running XWindows 4.18 and KDE 3.2.x or Gnome 2.0 on that basic Red Hat
6.2 build. How can they do this? Because they can recompile, recompile,
recompile.
I'd better install latest entrie MDK instead of building that "OS
card-home". Less compatibility problems, no time spent on regular partial
upgrade, in case of total failure of drives i don't need to remember what
components was installed or upgraded and what is not.
Quote
To put it simply, proprietary OSes puts control and process in the hands
of X company. Openm Source puts the power and control in the hands of
(dare we say it, or even think it? :)), the user(s).
And that's why Microsoft now earning millions while Linux still in the
{*word*249}ager state.
Quote
>In fact i'm encountered opinion that states that entrie OS should
>represent monolithic unchangeable module programmed in the ROM. Want new
>OS, buy memory stick with that OS.
>Just imagine advantages:
>1. No virusses in the OS.
>2. No corrupted libraries and executables.
>3. No compatibility problems.

There has never been such an animal as bug free OS, nor bug free
applications. Some are better than others, but the bugs, they be there. So
everyone would be updating EProms <G>.
Advantages that i abovementiones still stay.
 

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

pNichols wrote:
Quote
requires some typing. Is typing a folder name on the root C:\ drive really
more difficult to explain that click the terminal icon, go to the
directory and type Make MakefileName?
Yes. More difficult. For end-user. If they expirience troubles even with
understanding "how to copy file", they deffinitely will have troubles with
command line.
 

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

juliusz 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.
 

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

Quote
Give it up. *nix heads just don't seem to get it. While they debated the
virtues and logic of the command line, MS stole the whole market.
By stealing the ideas from Xerox <g>.
Quote
And they
still don't understand how or why it happened.
They still refuse to believe how brain dead the average user is <g>.
-Michael