Re: OT: my new PC rocks!!
From: john chung (johnc_at_xybase.com)
Date: 12/25/03
- Next message: john chung: "Re: OT: my new PC rocks!!"
- Previous message: Frank Kotler: "Re: handling exceptions in msdos"
- In reply to: Beth: "Re: OT: my new PC rocks!!"
- Next in thread: Frank Kotler: "Re: OT: my new PC rocks!!"
- Reply: Frank Kotler: "Re: OT: my new PC rocks!!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 25 Dec 2003 18:33:00 +0800
On Tue, 23 Dec 2003 11:27:05 -0000, "Beth"
<BethStone21@hotmail.NOSPICEDHAM.com> wrote:
>Ben Yates wrote:
>> Beth wrote:
>> > Mind you, I _still_ can't get Linux installed on my "Linux box"
>second
>> > machine...it's only a 450MHz...I checked the jumper settings and
>they
>[ snip ]
>> > then I can't get any Linux version (not even the old one I still
>kept
>> > on CDs) to get back on there...
>>
>> Well, if you ask a Linux expert (or in a Linux group), they are
>likely
>> to tell you that you are a Windoze user who doesn't understand
>Linux,
>> and they have never had any issues, and there machine uptime
>measures
>> in years, not months, and etc...... ad nauseam.
>
>Yeah, well, there is a _reason_ why I've not bothered to ask a Linux
>"expert" on a Linux group...they are very pre-occupied with their
>"voodoo black magic" stuff, aren't they?
>
Some of the mailing lists that I subscribe to has real
attitude problem. Notably the FreeBSD mailing groups. Quite often the
questions newbies post up there are not answer. There are of course
some of them that helps but way too few of them there.
>"Install problems, you say? Ah, did you sacrifice a chicken and pour
>its blood all over the CDs first? What?!? How can you claim to
>'understand' anything when you don't even comprehend this simple
>MXYZLYQPTIK ritual? What's 'MXYZLYQPTIK', you say?!? Why, that's the
>'intuitive' command name for the chicken sacrifice utilities you
Some of their "help" is pure sarcasim. Example:
One guy had a blank screen after starting "startx". One of the
members suggested that he pull up the contrast button to the fullest!
Well, this really sucks..........
>should run (oh, just remember NOT to say the word backwards aloud...or
>else all your data disappears back to the 29th dimension ;) - in a
>_specific sequence_, dictated by the passage of the Moon and planets
>at the time of the summer equinox - before reversing the polarity of
>your anti-matter warp drives...what's that? Yes, I am also a Trekkie,
>as it happens...how did you guess? Sorry, I don't understand...what
>does this 'meaningless techno-babble' phrase mean, as I'm unfamiliar
>with it? Anyway, you should easily fix up your install problems by
>following the rituals...oh, and you have to edit a few configuration
>files too...about a hundred of them, that's all...ah...yes...then
>there's also the tachyon re-calibration procedure...but it's all
>pretty much fool-proof, as long as your particle accelerator is
>aligned...what?!? You don't have a particle accelerator in your
>basement? What sort of clueless newbie are you?!? What's that? No, I
>don't think I am familiar with the term 'assembly language' and who on
>Earth are all these computer companies you mention? Computers didn't
>exist before 1995, _everyone_ knows that!! Really? You have to
>'program' the things, eh? No, no...I don't recognise any of
>this...anyway, it's _you_ who's the 'clueless newbie' in not
>appreciating that - for no particular reason that I can mention or
>even, really, comprehend - computer systems _must_ be this complicated
>and convoluted"...blah-blah-blah...unfortunately, I started to fall
>asleep at this point - even though it _is_ just a fictious Linux
>expert I've just made up rather than a real one - so can't continue
>this "enthralling" monologue any further ;)...
>
>> That is the reaction I got when I asked about the same issue with
>Red
>> Hat.
In previous year, RH has just gotten worst on me.......
>You got off lightly...now, if they'd _actually_ tried to help you then
>_that_ is when the real punishment begins; Make sure to stock up on
>ritual chickens for sacrifice, have a gigantic notepad to jot down all
>the bizarre "intuitive" utility names and don't forget to pop down to
>"Radioshack" to see if they've got "tachyon emitters" before you begin
>;)...
>
>> I'm not saying they are wrong, but I've gotten use to operating
>> systems that don't crash during installation... Like Windoze,
>OpenVms,
>> etc...
>
>No, they _all_ crash on occasion, to be fair...Windows just tends to
>do better than most, simply because they have all the hardware
>manufacturers working specifically for them, as part of their
>"protection racket" Maffia thing they've got going (for example,
>Microsoft basically "owns" the ACPM thing and has the hardware
>manufacturers dancing to their tune...Linux and others, though, have
>to attempt to unravel and reverse engineer badly written documentation
>to fathom what drugs Microsoft are on today...which, understandably,
>isn't the most reliable process in comparison to what Microsoft are
>doing...heck, _by definition_, Microsoft can't be wrong...if you ain't
>complying with the "PC 2027" specifications then it's the _hardware
>manufacturer_ who's "in the wrong" for not complying, Microsoft are
>blameless by definition ;)...
>
>Plus, knowing Microsoft, it's _still_ DOS (which itself uses the BIOS
>for practically everything ;) doing all the work and the "Windows" bit
>is merely the pretty graphics and mouse pointer routines to stare at
>while it installs...and they've had almost two decades to perfect that
>same old DOS code...I, again, point to the mouse pointer itself as a
>clear example that Microsoft employ "code re-use" to silly levels,
>while - in their marketing hype - pretending that they've re-coded the
>whole thing from scratch...
>
>The Windows 3.x mouse pointer (it might even have been present for
>Windows 2.x, mind you...I just never saw anything but screenshots of
>that version, though, as I "joined the PC" at this point, so haven't
>actually seen it up and running to test if this "bug" is even older
>than I'm crediting it for ;) had a pretty pathetic cosmetic
>"bug"...when you moved it to a window edge, then the pointer would
>change...now, for one frame, the mouse pointer changes shape but
>_still_ is displayed at the old mouse pointer's "hot spot"...then, the
>frame after that, it corrects itself and displays it at the correct
>new "hot spot"...and this happens each and every time the mouse
>pointer is changing shape...it's only a "cosmetic bug" and doesn't
>really cause any problems, except for a distinctly amateurish "jerk"
>when the mouse pointer changes shape (and I mean "amateurish", as this
>is almost certainly easily fixed in a matter of five minutes, just to
>make sure that the "hot spot" changes at the same time as the cursor
>shape...I've always foudn the "amateurishness" of this and other
>Windows visuals - such as the titlebar that flickers as you're
>resizing (this one is still present; Select "show contents while
>dragging" - which is the default these days - and then grab the
>bottom-right corner and just move that mouse pointer around with wild
>abandon, keeping it constantly moving...now, look at the
>titlebar...it'll be flickering every so often...the reason for this is
>that Windows GDI is directly writing the graphics straight onto the
>screen - no "off-screen" buffer, despite this being a _clear case_
>where "overdraw" will occur - and it first wipes out all the pixels of
>the titlebar with the background then goes back and _overdraws_ the
>titlebar text...this is a case of "overdraw" - writing to the same
>pixels multiple times on the actual visual screen the user can see
>(rather than hiding this away on an "off-screen" buffer so that the
>user doesn't suffer seeing it) - and can be solved in two ways: either
>use a small off-screen buffer to draw the graphics completely
>off-screen and then blit it into view...or, if you prefer, ensure that
>the titlebar drawing routine _only_ ever writes to a particular pixel
>_once_...that is, don't just clear the whole thing with the background
>but write the background and text at the same time...some sort of "is
>this pixel part of the text? Yes, draw it in the text colour...No?
>Then draw the background" routine...note that calculating the new
>"anti-aliased" edge would be completely in-keeping with doing both at
>the same time...rather than writing, reading, modifying, writing...to
>cut a long story short, these many, many "cosmetic bugs" throughout
>Windows and the dreadful operation of GDI and how switching back and
>forth to DirectX often corrupts graphics (both the desktop and / or
>the DirectX full-screen game you're running)...well, all these
>conspire to tell me that they either don't have a graphics programming
>specialist...or the ones they've got are simply crap and should be
>sacked...this stuff is "graphics 101" and they can't get any of it
>right...in fact, I've been watching and the pattern is clear: they
>don't sit down and work out what's needed...instead, you can watch
>them "trial and error" the whole thing over successive versions until
>there's a "oh, crap...this'll have to do" solution sitting on your
>desktop ;) - fills me with zero confidence in their programmers'
>abilities ;)...
>
>Anyway, this same mouse pointer problem appears in Windows 95 and
>Windows 98 and, basically, covers at least a decade of their
>products...now, I simply don't believe that they were "recoding from
>scratch" and, coincidentally, making the same simple, idiotic mistake
>every single time (and, if they were, that's _more condemning_ rather
>than less so..."consistent repeated coincidental incompetence" (which
>is so highly unlikely as the reason, you'd need a few hundred decimal
>places to write out all the zeroes in the odds of this actually
>happening "by accident" ;) would be the only "defence" and that's
>actually _worse_ than what I am going to accuse them of ;)...hence,
>the mouse pointer code's little "cosmetic bug" shows that those
>routines responsible for this were NOT altered (even though there is
>clearly a "bug" inside them, just looking at the visual output ;) for
>at least a decade...the titlebar dragging has been there from Windows
>95 (note that only with the Windows 95 "Plus" pack could you actually
>select "show contents while dragging"...hence, the titlebar has
>probably been "overdrawn" since the very first Windows version but
>only with 95 could you _visually expose_ their amateurishness for all
>to see :) and this one _still_ isn't fixed even today...
>
>And the mouse pointer "bug" has only been fixed, not because Microsoft
>wanted to remove the bug...but, in order to allow for the "mouse
>pointer shadow" effect they've introduced, they must have re-coded the
>mouse routines and, this time, not made that same idiotic "hot spot"
>mistake...so, it _is_ fixed in XP now but only because of the
>introduction of "shadows" (a case of "keeping up with the Joneses"
>because other GUIs were introducing such features...I doubt they'd
>have bothered at all unless there wasn't that small bit of "pressure"
>on them...so, yes, some _competition_ to keep Microsoft on their toes
>and stopping them being complacent does exist...but, unfortunately,
>not in sufficient measure, I don't believe, that they can cite this as
>some sort of "defence" that they aren't a monopoly...but you can
>understand them trying that one on with the judges in the DoJ
>case..."worth a try", I suppose, right? ;)...
>
>What gets to me most is not just that Microsoft have a string of such
>"incidents" to mention (you could start up a _daily_ magazine on the
>issue and never run out of contributions ;)...but the much more
>sinister side of it...that people have been trained to be "tolerant"
>of such amateurishness..._everyone_ who's used Windows between 3.x and
>XP, at least, must have - even if only subconsciously because they
>aren't looking directly for it - _seen_ their mouse pointer doing this
>bizarre little "dance" whenever they tried to move the mouse pointer
>near the edge...heck, there must be a heck of lot of "newbies" out
>there, struggling to learn how to use a mouse and getting used to the
>delicate positioning needed to be on the small 3-pixel or so "border"
>where the mouse pointer changes, only to have been startled to find
>the mouse jumping around the screen willy-nilly...
>
>Unfortunately, indeed, humans have an amazing capacity to "get used
>to" practically anything...so, everyone moves the mouse pointer and
>their mind "edits out" these quite appalling visual "glitches"...well,
>I used GUIs before coming to Windows and when I saw that happen, I was
>shocked by...well, there's no other way to describe it...the complete
>incompetence displayed...mouse pointers, of all things, should not
>suddenly do little "dances" because the pointer is changing shape...in
>fact, when the pointer is changing shape, this is a visual signal that
>the area the mouse is hovering over has some significance...thus, for
>it to start "jerking" about the place at the very point when it's
>supposed to be signalling the significance of an area as small (3
>pixels or so) as the border, it's a complete betrayal of all the
>principles of human / machine interaction and good interface
>design...to me, this signals a complete abandonment of any care for
>quality whatsoever...I mean, you've got to make sure to change the
>"hot spot" at the same time as you change the image so that the new
>image is drawn in the right place (but, consistently, with this bug,
>there's _always_ a frame displayed where the mouse is in the wrong
>place...it's not even an intermittent visual bug...so, literally, it's
>changing the "hot spot" in a _completely different_ frame to changing
>the pointer shape...there's _no legitimate excuses_ here that can
>explain it, other than simply: Microsoft don't give a crap :)...fixing
>this took a decade, while it almost certainly - being a minor
>"updating the variables" timing problem - would have been a "five
>minute job" to fix...
>
>The code is being "re-used" to extreme levels without doubt here...the
>"going 32-bit" sounds impressive but really just meant feeding the
>same _BUGGY_ C source code into a 32-bit compiler rather than a 16-bit
>one...so, all the same logical bugs are alive and well...as the fact
>that the Windows 3.x mouse pointer bug transferred perfectly to
>Windows 95 / 98 / NT without a single error being fixed...the bugs are
>now 32-bit bugs rather than 16-bit ones...but, if you look at the
>screen, the exact same incompetence is displayed with faultless
>precision (literally, the bug is logical and the bug in the logic has
>not been altered one bit by "going 32-bit" so it's _exactly the same
>bug_, just the code that faultlessly implements the bug uses "EAX"
>rather than just "AX", while it happily does everything wrongly all
>over again ;)...
>
>Hence, the fact that installs are somewhat generally less prone to
>crashing (but certainly not "guaranteed not to do so" by any
>means...Windows _does_ crash on install too, I can assure you
>;)...well, that's all down to religious "code re-use" and simply lots
>of "trial and error" hacked "quickfixes"...after all, even starting
>with the most incompetent code you can imagine, having two decades
>worth of "hack here, hack there" and religious "code re-use" _will_
>eventually get you something "mostly" reliable (bloody awful code with
>no proper structure, mind you...but after coding in the 900th
>"exception to the rule IF statement" into it, you eventually have code
>that ducks and dives practically all potential problems ;)...
>
>But this sword is double-edged...because, by the same token, this
>religious "code re-use" (or more commonly known as "laziness"; Bill
>Gates said it outright: "if the bug isn't profit threatening, then
>we'll leave it alone"...so, as long as no-one switches over to Linux
>because of the repeated Blue Screens of Death, then Bill ain't going
>to do a blessed thing to remove those BSODs at all...XP desparately
>tries to fix all these bugs _two decades too late_ because, yes,
>Windows really had begun to have such a bad, bad reputation that a
>small "exodus" over to Linux was beginning...without that threat, we'd
>probably _still_ be wondering when Microsoft would make good on their
>promise to "merge the 9x and NT streams with a reliable NT kernel" to
>this day...they delayed it once because things died down a little on
>the DoJ case front...if the threat had vanished then MS would have
>returned to what they always do: "The Line of Least Resistance"
>(A.K.A. "laziness"...if they can still make money selling crap then
>they'll carry on blissfully selling crap without a second
>thought...the simple mantra: "aim for _no_ costs but total
>profits"...maintenance _costs_ so do as little as is possible...and,
>you can bet they'd do _NONE AT ALL_, if it weren't for the fact that
>people would certainly then "wise up" to Microsoft's tricks and all
>install OS/2 or something instead...so, "new" versions where they've
>changed the graphics and added a whole bunch of useless API that
>no-one needs or wants anyway, just to give them something to show and
>say: "hey, look! We really have changed it"...but this "change" is no
>more useful than if Microsoft just dumped an extra 3 Gigbytes of
>random data in files into the "Windows" directory that does nothing
>useful at all...I often suspect with Windows' gargantuan size if,
>indeed, they actually _really did_ do that once or twice...is there
>any actual code inside some of these DLLs or are they just files full
>of random data loaded by Microsoft applications merely to "give the
>appearance" that they are OS components? For instance, what _does_
>"cnbjmon.dll" or "ixsso.dll" actually do? Are they really "important
>system components" or just "printf" and "strlen" bundled into a DLL
>full of junk to pad it out to an impressive-looking size, just to make
>you think Microsoft have been doing lots of "really important but
>difficult to understand" work all this time? I mean, there's bloody
>thousands of the things...are there really that many "important system
>things" to be done that _requires_ so many gigabytes and tens of
>thousands of API? Especially when we know that _drivers_ are the sole
>components responsible for _actual hardware access_ (otherwise, you'd
>have "violated" the principles of "safe", "protected" layered OS
>design...again, a case of "either I'm right and it's awful...or, in
>fact, the alternative actually suggests things are _even worse_ than I
>imagined"...damned if they do, damned if they don't ;)...so, again,
>what are these things actually doing? What use are they providing?
>Does any software not written by Microsoft ever load in the
>"cfmondhfke.dll" file? If not, then isn't this taking major Liberties
>with our hard drive space just to accomodate Microsoft applications?
>
>Hey, there may be a use for Rene's "re-assembler" after all in
>answering such questions...not that I'd, of course, suggest that
>anyone should in any way breach their EULA which specifically - in a
>highly paranoid way (what they hiding? ;) - prohibits reverse
>engineering...phrased in such a way that it sounds like you'd get the
>death penalty simply for thinking about doing it...but, well, you know
>what these "cracker" types are like...I'm not encouraging or condoning
>such actions at all...it's just that if someone does do it anyway off
>their own backs of their own freewill, unrelated to any comments I may
>have made, then simply answering "Yes, it _is_ full of useless junk,
>merely to impress people" with no more details than that given, it
>wouldn't really be a breach of their intellectual property rights at
>all to provide a simple "yes" or "no" answer to the "are we all being
>shafted big-time by a bunch of crooks?" question...
>
>Beth :)
>
- Next message: john chung: "Re: OT: my new PC rocks!!"
- Previous message: Frank Kotler: "Re: handling exceptions in msdos"
- In reply to: Beth: "Re: OT: my new PC rocks!!"
- Next in thread: Frank Kotler: "Re: OT: my new PC rocks!!"
- Reply: Frank Kotler: "Re: OT: my new PC rocks!!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]