Re: Linux, X, ld, gcc, linking, shared libraries and stuff

Frankie say:
> \\o/annabee wrote:
> > How the hell to select one ?
>
> Good question. What I observe is that Gnome seems to be
> "prettier", KDE seems more "businesslike". I don't know any
> of the others. KDE is the larger package (to my surprise),
> but seems much faster than Gnome. (this may be a
> "configuration" or "resolution" issue)

KDE is aimed at being a "complete desktop", it should be noted...that is,
it also includes a bunch of "K" applications to go along with it...such as
"Konqueror", which is basically trying to be a lot like "Explorer" in
Windows...you know, it's a browser and file manager at the same
time...generates "file previews" and has a bunch of browser "side
panels"...it's a bit slow, though...and perhaps guilty of "trying to do too
much", if you know what I mean...

One nice feature, though, is that you can open up a "split screen" between
the "file manager" stuff - the Explorer-like "icons" - and a terminal
window at the bottom (and when you click on folders to move around, it
automatically enters the "cd" commands in the terminal window :)...now that
can be very handy for development...because, you know, some things are
better done with the "icons" (selecting an "irregular" bunch of files, that
there's no simple "wildcard" equivalent)...and some things better with the
terminal (entering command-lines to run NASM and LD and such :)...but the
"built-in browser" is really annoying and probably the thing that makes it
run so slowly...I think it's better to keep that out of there and have a
dedicated browser program...you know, it wasn't just the DoJ who thought
that "integrating" IE into Windows was a bad idea...

But, yeah, KDE's kind of "goal" is to try to develop a "complete desktop"
with all the "standard applications" and so forth, as well as the "window
manager"...because I guess they feel the "weakness" with Linux is that it's
too "piecemeal" and complicated for "newbies"...so, it's going for an "all
in one" thing...I think the "audience" they are trying to grab, if you
like, is the "new to Linux" crowd...indeed, the way things like "Konqueror"
are suspiciously similar to Explorer in places...well, probably a case of
being "familiar" to ex-Windows users not deemed a "bad thing"...

One of the interesting things with KDE, though, is that they've made the
"look and feel" thing work via "plug-ins"...which makes it incredibly
customisable...and there are two "cheeky" themes provided: "Redmond", which
mimics the Windows' way of doing things, and another one for the Mac, which
even puts the "menubar" across the top of the screen, in the Apple Mac
style...but clearly included to "ease transitition" and "provide
familiarity"...

Indeed, KDE's "plug-in look and feel" thing is very customisable, Frank,
that if you play around with it, you don't just get "business-like"...you
can get pretty much anything out of it...

And this is probably the reason why it's so large...it's not that the
"window manager" itself is so large but the fact that KDE also includes all
these "standard applications" and there's all the "plug-ins" for
alternative "look and feel" options to throw into the file size too...

Personally, I'm not sure if KDE are actually achieving what they are
setting out to do (but, then, I suppose they are still working on it)...but
I like the idea...and, strictly, with the "plug-ins" for the "look and
feel" then, ideally, KDE could run and then you change "styles" with
"plug-ins", not changing "window managers"...I think, though, that this
idea might actually fail because they've added too much...that the
"Konqueror" is too over-featured...you know, the problem being that you
can't so easily get to run more "minimally"...if there was some
"minimalistic KDE" then that work real well, I reckon...

But, then, this "window manager" thing is all about "personal taste"...for
instance, you say GNOME looks "prettier" but I'm not sure I entirely agree
with that...not that it's awful or anything but - this might sound a bit
weird - it's like it's being "too slick and smooth"...not enough
"physicality" to it...you know, you want to _know_ when you've clicked a
button, where one button stops and the next starts and so forth...

You should play around with KDE a while, Frank...just to see all its
"options" because it actually has a lot of them (that whole "plug-in look
and feel" thing)...you can "customise" it away from that "business-like"...

> If you mean "how to do it", rather than "how to decide"...
> ummm, there's a configuration file that determines what
> "startx" does, I think, but I'd have to search around to
> find it. Once found, it's fairly "obvious" how to switch,
> IIRC, but I don't remember details. Normally, it's something
> you'd only do once, and then only if you "guessed wrong" on
> the initial install...

Yeah...basically, the "window manager" is actually just a program that's
automatically booted up to provide the "look and feel" / "organising the
windows" stuff...like Frank, I don't remember the exact details...but,
basically, some "shell script" somewhere just automatically starts running
it, as part of starting up X...

This might be complicated by one of those "welcome screen" GUI login
things...which I can say from experience, having selected the "GUI" option
during install (not realising, at the time, that what this option did was
automatically "startX" during boot-up that it goes straight into X and the
"welcome" screen straight away)...and then needing X completely disabled
and not running in order to get the nVidia driver installed...a little more
complicated than it sounds because the "Welcome screen" - for security
reasons - can't actually be shutdown by an ordinary user...you know, if you
try to "kill" it then it restarts automatically...a "security" thing, you
know..."root" can disable it by changing the right "configuration
files"...but, yeah, I had to trawl with Google to find the exact
instructions to do it...

In a sense, this is Linux in a nutshell...it has all the options and,
usually, you can "configure" just about anything to do whatever you
like...and have a wide set of "options" for your "window manager"...and
your distro comes with tons of "packages" installed...

But, ironically, that's kind of the problem...too many "choices", too many
"configuration files", too many "packages" and "options" and
"utilities"...at least, what I mean is: "too much to begin with"...you can,
of course, work your way through it all and learn how it all works...it's
all usually easily done and that there's some "configuration file" or
"window manager" somewhere that does exactly what you want...but, well,
initially, it's like being lost in the middle of a rainforest...too many
bloody trees everywhere!! :)

So, yes, the:

> How the hell to select one ?

....question is a good one...but, in a sense, isn't "too many options that I
have no idea what to choose" a better kind of "problem" to have than "no
choice whatsoever evil locked-in oppression"?

Perhaps the answer is simply: "Roll a dice"...you know, take _ANY_ of the
"options" to begin with...and then try it for a while...if you don't much
like it, then switch and try another one...eventually, you'll hit something
that you kind of like :)...

If you like Windows, then perhaps, indeed, the suggestion is "try KDE and
switch on the 'Redmond' theme"...this "mimics" the Windows "look and feel"
(to a degree; The KDE "panel" is far more customisable and powerful...and
you can stick a couple of "buttons" on either end that gives you "one click
disappearance"...that's nice...you click on the little arrow button and
then the "panel" just slides off to one side (with only another small
"arrow button" left on the screen, for clicking to get it back again :),
emptying the screen of any "taskbar" crap...and you can directly stick
buttons there to launch applications...for example, I've got an icon I
added that when you click on it, opens up a "Start"-like menu of just my
"development" programs (text editor, console window, file manager, etc.
:)...and you can add on as many or as few of those as you like...and then
I've added a "wood grain" effect (you can use any "pixmap" you like and a
bunch of "materials" pixmaps are provided, which are cool :) to it...so, it
looks like a plank of wood at the bottom of the screen...though, I'm
thinking maybe a "black marble" look might be a "classier" look...and I'm
torn in "loyalty" between putting a "menubar" across the top like on an
Apple Mac (and on the "GEM" desktop I used to have on the Atari ST, that
I'm "familiar" with this style from those places :)...but I've been
"Windowsized" over the years because when I switch it on, I just can't get
used to it and switch it back off again ;)...

> > I want my linux apps, if I ever rewrite something in
> > Linux, to run on Linux. Period. I dont want to educate the users to
> > download and install this and that distro, and this and that shell
> > (window) manager. That seems just a horrible situation.
>
> Agreed... and I don't think it *is* the situation. Sevag
> mentions that some Gnome apps won't run under KDE... I think
> they "ought" to... Perhaps we can figure out "why not".
>
> I understand that you can write Windows programs that will
> run on win98 but not on XP, or vise versa. If you write the
> program "right", and "obey the rules", your program will run
> on 98 *or* XP. I suspect we may be encountering a similar
> situation here.

Yeah, I think that's the basic "gist" of it...the programs which aren't
working are, no doubt, "assuming" they are running on KDE or whatever and
then "blindly" trying to access some KDE "feature" directly...and, of
course, when it isn't there, this is just not going to work...

Which, in a sense, would be kind of like writing an NT program that uses
the "W" UNICODE API and then trying to run it on 9x (which doesn't actually
support UNICODE directly)...Jeremy Gordon has some "UNICOW" DLL or
something with GoAsm that "accounts" for this or whatever...same kind of
situation, as Frank suggests...if you "do it properly", then this should
never actually be a problem (you _CAN_ run GNOME apps under KDE because
I've done it with GEDIT and others :)...

And if you write "raw Xlib" code - like my example - then there's really no
possible way you could fail (though, yeah, this is a little
"unadventurous", maybe...but it'll always work :)...but the "exact details"
of this is what I'll be searching out and will try to add onto that
documentation that's already on our CVS...

Reading chapter 14 of the Xlib documentation (which mentions the "standard"
ways of communicating to the "window manager" to, you know, let it know
what "icon" and "titlebar text" to use for the window :), there's a
"standard" for this by the X Consortium that ensures that this all happens
in a "standard" way, so it'll work with many "window managers"...most
likely, those programs which don't work are, in some way, "breaking the
rules" of this "standard"...

> > Do Linux entusiast have a faintes clue at how fast even advanced users
> > will bail out at even the smallest problem theese days ?
>
> I can see your and Betov's reaction to it. I also observe
> that several posters appear to be using it as their
> "everyday" OS. Perhaps we're the "less advanced" users... It
> seems that some people can install and use Linux with little
> trouble, other people have real trouble, and don't like it.
> Sorta like some people think RosAsm is great, and some
> people think HLA is great. Could it be that the same
> "eyeglasses prescription" isn't right for all of us???

Where could you have gotten that idea from? ;)

Wannabee's quite right, though, to a degree...you know, whether it's
"right" to "bail out" at the first sign of trouble...well, it's "human
instinct", isn't it?

And, truth be told, that's _EXACTLY_ what I did at first too...I'd done
some UNIX / Linux / X stuff in university and that was "okay" (that is,
once I found out "what's what", it was "nice enough" and not too
"problematic" at all :)...but, you know, doing "assignments", I didn't look
beyond what was needed to get the assignments done...

But, of course, the discussions with Rene about "RosAsm for Linux" and then
Frank setting up the LuxAsm project...I thought "yeah, that'll be
cool"...and, again, as I said, I've found that the more and more I use
Linux, the more and more impressed I get...which is very "refreshing"
because, truthfully, I've become less and less productive since coding with
Windows (which, by the way, was since 16-bit Windows 3.x time...using C
mostly because, like many at that time, I hadn't heard of any "assembly
language" using Windows...I did all the ASM stuff on DOS instead...oh, and
I was only basically doing that thing of "let's just try out this Windows
coding to see how it works" because, though Windows was now beginning to be
the "default", things were still mostly done in DOS...there wasn't much
call for "Windows programming" but Windows had started to get "interesting"
enough to warrant at least a "how does this work?" investigation :)...

Windows just oppresses and depresses more and more...while Linux / X are
"liberating"...now, there could be a touch of "it's new" to this...that
because it's "new" and I'm learning, it's bound to have a bit of "freeing"
influence, in comparison to the thing that I've used so long now, that,
well, "familiarity breeds contempt" in itself, even if Microsoft compound
that by "breeding contempt" from just being Microsoft too...but I don't
think that's all it is...because, you know, I can see that there's a
possibility to use all these "window managers"...all the
"toolkits"...perhaps make my own...there's much more possibilities...and
it's all "open"...while Microsoft is all "closed"...and the Linux / X stuff
really does have little "tricks" and "possibilities" that Microsoft don't
have...

Really, perhaps, trying to nail down what the "problem" is, I think Linux's
problem may simply be that it's still "growing up"...

The graphics options are an example...Linus didn't put any "graphics
driver" in there at all, really...it was "text mode" stuff, so he didn't
bother...so, then XFree86 was written with "direct access" to the
hardware...and "SVGAlib" handled the graphics outside X...but, really - as
things like "DirectFB" might make commonplace (you can get an XFree86 that
uses "DirectFB") - what's needed is that underlying "graphics driver" that
X can use - which has "accelerations" - but can also be used outside
too...a common "graphics driver" so that it stops, you know, being
"mutually exclusive"...it'll be interesting to see where it goes - and I've
not yet really looked into it - but if "DirectFB" can be this "underlying
graphics driver" and that "accelerations" are understood by it and then X
can rest on top of it...well, this might bring all the "graphics stuff"
together because, true enough, due to "history", it's all a bit "fractured"
at the moment...

The "apparent chaos" is just different "options" fighting it out...

For those who don't remember before the PC and Windows "owning" the
universe, then this was not "unusual" at all...it's, you know, simply
"competition"...lots of people make word-processors and, well, the best
ones will win through ("survival of the fittest")...lots of people propose
"standards" and the best ones people eventually go with...it's simply
"competition"...just "progress"...nothing more than "evolution"...

This was what Microsoft killed...there is no "competition"...and if anyone
tries, then they will "bundle", they will "preinstall", they will do
anything and everything to "eliminate" progress, to eliminate choice, to
eliminate freedom...you know, like some deranged Dalek: "Exterminate!
Exterminate! Exterminate!" :)

> > I can guarantie
> > you, that any application that isnt able to run and start and work, by
1
> > click, will never attract end users in the long run.
>
> Would you settle for a "doubleclick"? Well, you can
> configure your window manager (all of 'em? AFAIK, yes.) to
> start an app with either a single click or a doubleclick.

But most applications do work by a single (or double, depending on your
"options" ;) click...the ones that don't are few in number and must be
"doing something wrong"...

Basically, what the "window manager" does is rather simple...when an
application creates a window, it becomes a "child window" of the "window
manager"...

That is, the "window manager" creates a window...and then it draws the
"window frame" inside that window (the sizing border, the titlebar, the
buttons or whatever "scheme" the "window manager" offers for its "window
frame" :)...then the application's window becomes a "child window" of this
inside the "frame" (in the area that Windows calls the "client area" :)...

So, simply, when you move the mouse over the window's "frame", this part is
implemented by the "window manager"...and the application's window simply
becomes a "child window" of this window (and any "events" over this part of
the window go to the application)...

Basically, the "window manager" and application are kind of "sharing" the
window...but, note, that they are both basically just X "client"
programs...the "window manager" is also calling Xlib and has an "event
queue"...the difference is that this X progam has, you know, the
"responsibility" for handling the "look and feel" stuff...so, you know,
when the user moves over the titlebar and drags the window, the "window
manager" handles moving the window...and the resizing...and that kind of
thing...

And, elsewhere, it's also dealing with the "desktop"...you know, the icons
and "background wallpaper" and that when you right-click a "context menu"
appears with "Configure desktop..." on it, that runs an "applet" for
setting desktop options when you click on it...starts up some "panel"
program for across the bottom of the screen, if it's a "window manager"
that has that kind of thing...

But, if done properly, there should be no problem with this...you know, the
application happily sitting as a "child window" of _ANY_ window manager's
"window frame"...this _SHOULDN'T_ be a problem...if and when programs don't
seem to work then something somewhere has gone wrong...you know, KDE offers
some extra API and the program blindly calls it - assuming it "must" be
running on KDE - and, well, calling a window manager that isn't actually
there? It crashes and fails to run...

That's the application's fault, though, for doing something "window manager
specific"...ideally, I suppose, "window managers" would all be the same so
this is never a problem...but, you know, KDE want to offer some "context
help" functionality or the ability for applications to "add options to the
right-click menu"...and then this new "functionality" is "KDE
specific"...some application calls into it blindly...so, when it's not
there, it fails miserably...

I don't think, though, you would ever encounter any "compatibility" problem
writing an X application that you yourself didn't cause...as Frank said, if
you "write carefully" then this is not a problem...

The division between "X protocol" and "window manager and such are clearly
defined...and there are "standards" to be followed...you know, X is
designed properly that this should NOT make the slightest bit of
difference...the problem is coming from "window managers" offering "extras"
that are specific to it and then applications written to blindly depend on
them...the programs are written to be "KDE specific" or "GNOME specific"
and, hence, understandbly fail when the correct "window manager" isn't
there...but the problem is not X, the problem is "window manager specific
coding" (mind you, there _COULD_ be legitimate reasons for this in some
cases...KDE also offers a lot of "standard applications" that are
delibrately all "integrated" into its "look and feel"...for instance, the
"control panel applet" that sets up all the KDE "look and feel" options or
the "desktop configuration"? By definition, this is going to be "KDE
specific" because their entire purpose is to be a "configuration GUI" for
the "window manager" itself...running it under GNOME inherently makes
little sense...so, you know, some programs are _legitimately_ doing "KDE
specific" things...the problem is that some appear to be doing that when
they really shouldn't be...that's where your problem is really coming
from...

You know, if you're going to have lots of "window managers", there needs to
be a "standard" that they all "comply" with (and there is: The
"inter-client communication" standards :)...but "window managers" _can_
offer "extras" (they are just programs themselves, after all)...these are
"non-standard" and dependence on them is "window manager specific"...but
the application brings that upon itself...if you want your program to be
"generic" to all "window managers" then you simply write a "standard"
program...

> > Installing a seperate
> > window manager just to try out an app is completly insane.
>
> Agreed. AFAIK, you should be able to choose *a* window
> manager, based on your preferences, and run any app under
> it. To the extent that this isn't true, "something's wrong",
> I think. It *does* happen - an app might ask to dynamically
> load a shared library that doesn't exist. A Windows program
> might ask to load a .dll that isn't there. Maybe we can have
> a "religious war" over whether ".dll Hell" or "Deep in .so
> ***" is worse. :) In either case, I think if you want to
> solve the problem, there's probably a solution. If you
> prefer to complain about it, then "... sucks!".
>
> In order to *build* a "Gnome app" - that is, something that
> uses the "Gnome Toolkit" - I had to install four or five
> other things - in a particular order. (what you've "already
> got" depends on which distro, and on choices you made in the
> install process, I assume) But I don't need to be running
> the Gnome window manager to run 'em. Maybe some of those
> other shared libraries *are* required to just run 'em...
>
> One thing I just noticed... Checking into the fact that
> Beth's example behaves differently depending on whether you
> exit by "press any key" or by "click on the little X up in
> the corner"... I noticed that the "gnome example" (NoDot's
> version, but derived from Jonathan's book) *doesn't* quit
> when you "click on the X" (the existance and location of the
> "X to close" is highly configurable - I'm assuming we're
> configured "like Windows", approximately). I suggested to
> Beth that we *didn't* get an "event" about this, but that
> must be wrong. (if I try to quit Netscape composer right
> now, I get a "do you want to save" box, so there *must* be a
> way to intercept it)

Well, the thing is that this isn't an X "event"...the "window manager" is
also a "client" program, just like the application...and to "communicate"
with each other, there's a "inter-client communication" method...I need to
get more details (there is some "standard" about this from the X
Consortium, apparently :) but the very "basic stuff" is outlined in chapter
14 of the Xlib documentation on the CVS (I've just added "<PRE>" tags to
make these pages readable until I get around to proper HTML formatting on
them :)...and you'll see that the application sets the "icon" and "titlebar
text" by setting "standard" window properties...

The point, if you like, is that this is NOT "X" (as in "the X protocol" or
"Xlib") which is responsible for this...this is "higher-level" and is to do
with the "window manager"...so, this will be dealt with by "inter-client
communication" with the "window manager"...

X (as in "X protocol" and "Xlib") provides the "raw" GUI services to
applications (indeed, I've heard many say that the terms "client" and
"server" are the wrong way around with X...I don't think so...I think
people are just not looking at X the right way...the "X server" is
"serving" "GUI services" to "clients"...it's a "GUI server"...I suppose the
problem is that, normally, programs call "servers" to "do all the hard
work"...hence, they are normally asking for the "processing" to happen on
the server...but, well, X isn't a "processing server", it's a "GUI
server"...so, what it dishes out are windows, not "results to complex
calculations" or anything :)...

Think of it this way: The "window manager" can implement any "look and
feel" it likes, right? Okay, so it _DOES NOT HAVE_ any "close
button"...this isn't as "unusual" as you may think...earlier versions of
Windows did not have "close" on the actual window but hidden away in the
"window / system menu" (two names because *ahem* Microsoft decided to
change its name at one point ;)...so, X can't really "presume" and add some
"CloseButtonEvent"...or some new "window manager" could "invent" some
"context help" button (you know, like you see on some Windows dialogue
boxes...a question mark that you click on and then click on a control to
get "context help" on it :)...X obviously can't "pre-empt" all possible
"window managers" features from now until the end of time and "guess" that
some "window manager" out there might need a "ContextHelpEvent"...

Hence, X simply does not "guess" at all...it sticks to just the raw "GUI
services"...creating windows, moving windows, "expose events", drawing
graphics, etc....anything "above" that - at a "higher level" - is a "window
manager" responsibility...so, you "talk" to the "window manager" about it
(with the "inter-client communication" stuff :)...

Though, as you can see in chapter 14, there are "standards" about how this
is done exactly...and "standard" things like "WM_ICON_NAME", "WM_NAME",
"WM_ICON_SIZE" (yes, it's an "ironic coincidence" that they also start with
"WM_" like Windows' messages do...of course, in this case, it stands for
"Window Manager", not "Windows message" ;)...but chapter 14 really is only
covering the "basics" and it mentions an "X Consortium standard" that has
"further details" on all this "inter-client communication" stuff...I will
endeavour to find out more about this...and if I find a good text on it,
then expect this to also be thrown into the "X documentation"...as,
basically, I'm trying to compile a "one-stop reference", as you might have
guessed, so that it's all there in the "Xdoc" :)...

Johannes Kroll made a "guess" on the LuxAsm list that perhaps the "window
manager" sends a "signal" to the application for this...I have no idea at
the moment how accurate that "guess" is...but, hmmm, it does sound kind of
"convincing" to me at the moment...but I'll have a look at that
"inter-client communication convention" thing, if I can find it...unlike
the "sparse" stuff in chapter 14 (which is ONLY considering "application
talking to window manager" and has nothing about the other way around :),
it's got to also detail "window manager -> application" communication, as
well as "application -> window manager"...at that point, it'll all become
"clear"...I Hope :)...

> Difficult to compare examples made with a "toolkit" with
> examples using "raw Xlib" - the overall "structure" differs
> - but I'll try to see what the difference is with these
> "quit" situations...

That's a bit of a problem with the "toolkits"...they "hide" what they are
actually doing "under the hood"...that, of course, is half the point of
them: You call the "toolkit" to _SAVE_ yourself from knowing how to do the
"raw Xlib" for it all...but, well, in our situation, we need to "delve
deeper"...

Time to pull out our "stock phrases", I think, Frank: "We need to
investigate further" and "We'll eventually sort this all out between us"
;)...

> Linux offers a lot of options - maybe more than Windows -
> which may be a Good Thing overall, but it *does* increase
> the "confusion factor"... I hope ReactOS works out well so
> there will be an OS to suit "each" (not "all") of us!

Yes; That's kind of the "gist" of it...the "problem" is "too many
options"...which is a weird kind of problem...especially coming from "no
choice at all" Windows...but it's not that Linux and X are "lacking"
anything...on the contrary, they aren't "lacking features" enough!

And as for "maybe more than Windows"...it's probably safe to actually say
"more than Windows" and, just like Tony Blair, take those "caveats" out of
there...it's not just this "window manager" stuff...check out, for example,
the Linux "IPC" mechanisms...with "shared memory" and "message queues" (not
to be confused with GUIs...well, it is the same idea but, you know, you can
use them more "generically" for any purpose, as they are a "IPC primitive"
that's offered by the kernel for use :)...this is also a similar "does what
Windows does...and then some extra things too" situation...

In a sense, the problem isn't that Linux / X can't do things...but, well,
think of it this way: How many X examples can you generally find out there?
In assembly, effectively none...even in C - the "native" language for UNIX
stuff - there's not that much more...compare to Windows? Windows wins hands
down...how many developers are developing for Linux and X? How many are
developing for Windows? After all, Windows does "own" a 90+% share of all
desktops on the planet...it's a bit of an "unfair comparison"...

Because, also, a good GUI application isn't just about the programming, is
it? The really good ones are also about excellent "interface design" and
even simply "good artist skills" for drawing "cool graphics"...it's not the
whole story but you have to consider if there's only "x" amount of
developers with Linux / X (pardon the pun)...then how many Linux coders are
doing X stuff rather than "command-line only" stuff? How many of those that
are, are doing stuff that has good "user interface design"?

Are you seeing my point? There's a kind of "catch-22" involved...there are
not many users because there needs to be more applications with "good
interfaces" and that kind of thing (you know, more "configuration" by
"dialogue box" rather than by editing text files ;)...but there's only a
few developers working on these things because, you know, why write for the
platform without the users?

The fact that Linux - from a "hobby" by a lone student - has made it to
where it is currently - fighting the world's richest company, who are
utterly, utterly ruthless in maintaining their "monopoly" - without the
"automatic hardware coverage" Windows gets (everything in Linux is there
through "hard slog") to be able to "compete" with, let's face it, an OS
that has "monopoly", that has a decade or so "head start", that has the
richest company with resources available to it that rivals _SMALL
COUNTRIES_...

The fact that Linux can even "register", let alone "compete" seriously
enough to scare and worry Microsoft....that is simply a _MIRACLE_...it is,
to me, complete vindication that "open source" - when it works - works to
unbelievable levels...and, yes, some say "well, Linux development is
slowing down"...well, yeah: The bigger you make it, the harder it is to
make that much bigger again...putting one brick on top of another brick?
Easy...putting an extra 10 levels onto a 100 storey sky-scraper? Not so
easy...that, by the way, is _ENTIRELY TRUE_ for Windows or any other
program there is...

Which is what intrigues me...have you noticed that there's lots of
"established wisdom" and "rumour" about Linux and X that actually isn't the
slight bit true? Microsoft are known to employ the "FUD tactics" that they
learnt off IBM...to plant a "vicious rumour" and then sit back, watching
the "gossip" turn into supposed "fact"...

Oh, like any really good "FUD", there's a "grain of truth"...only a grain
but it give sit "credence"...so, you know, okay, X isn't the easiest
thing...but, somehow, it becomes "more complex than making space rockets
while performing brain surgery on monkeys at the same time"...it's not that
complicated...and then you hear people say "yes, but 'open source' is
slowing down now that Linux is getting bigger and more
complex"...true...but then this is true for _ANY_ program...Windows has
"slowed down" too...I mean, what's XP? 2K with new graphics and some
"compatibility modes" added (note: "compatibility" is hardly a "great
feature"...if not forced to "upgrade" in the first place then you wouldn't
need "compatibility", would you? Kind of like: "we have a great new feature
to stop blood loss" / "why do I need that feature?" *BANG!* "Arrgh, I've
been shot!" / "this is why you need our new 'blood loss prevention feature'
to cope with us shooting you arbitrarily, for no particular reason" / "oh,
thank you, Microsoft, you are so kind!" ;)...98 was 95 with "USB support"
added and IE forced into the OS, to just annoy everyone that you couldn't
get rid of it....

I'm wondering - as we're seeing the "reality" instead of the "rumours" -
just how much might be caused by "FUD"? You know: "open source looks good
now but it will slow down!!" (yeah, so does "closed source" too...but nice
"scare tactic")..."applications in X always fail!" (no, only the ones that
depend on things they shouldn't..._exactly like_ "MSVC40.DLL is missing"
errors or trying to use UNICODE under 9x...oh, we forgot about that, did
we? The _EQUAL AMOUNT_ of Windows programs that _ALSO FAIL_ because someone
was using "VB.net" to program it and the DLLs on their system just ain't on
your system...but, again, the "scare tactics" pretend that only Linux and X
have "DLL hell" problems...sorry, with things like the RPM system (which
works out "dependencies" as part of the install to let you know if you need
any other "packages" first :), you get _less_ "DLL hell" than you do with
Windows...also, with Linux, it's all "open source"...if you need a
"package", then you just download it...they are all freely
downloadable...can we say the same about every DLL for Windows? I think
not...if an ".so" is missing, find out what it is and then download
it...there, end of problem...if a DLL is missing, then it might be ever so
_ILLEGAL_ to be downloading it, if you can ever work out where
"XY65DJS.DLL" comes from in the first place...just sitting there in
"C:\Windows"...it could be a virus, for all we know ;)...that somehow Linux
/ X has "less power" or "not as many features"...on the contrary, it's
quite the reverse...Windows is the one stuck in "single party state
Communism" with the only "choice" of Microsoft or Microsoft or
Microsoft...and, as demonstrated before, NOT the "best implementation" by
any means...you know, _WHY_ is Windows sending "every single message, every
single time"? Anyone got a _REASON_ for that? Other than "can't design a
logical system to save their lives"...

I am now starting to _EXACTLY SEE_ why Linux users become so "evangelical"
and "enthusiastic"...it's because they've got one heck of an "open secret"
to share with everyone but no-one's listening because the "myths and
legends" tell them it couldn't possibly be true...imagine you'd just
discovered - indisputably - "Cold Fusion" or "the missing link"...and then
you tried to tell people about it but absolutely no-one was
listening...you'd also become a bit "in your face" about things...you know:
"Look! Look, damn you, look! It's Cold Fusion right here...just look!! It's
right there...why aren't you fracking looking? Are you mad?!? Look! LOOK!!!
Just look...just one second of your time, that's all...please, please,
please...will you just please _LOOK_...just once...that's
all...LOOK!!!!"...and still no-one does...instead, they tell all about
these "myths and legends" they heard: "Have you actually used Linux and X?"
/ "No, no...of course not...the myths and legends tell me there's no point"
/ "But if you ain't looked, how do you know the myths and legends are
true?" / "Well, they must be...Microsoft told me they were true"...oh, so,
an "unbiased opinion", then? ;)...

Beth :)


.