Re: Much Anticipated?



Today NoStop commented courteously on the subject at hand

On Tuesday 21 March 2006 05:06 pm, Mark had this to say in
microsoft.public.windowsxp.general:

SEATTLE (Reuters) - MS said it plans to delay the consumer
launch of its Windows Vista until January 2007.

And that, gents, reminds me of the ol' song by singer
Lefty Frizell - "Always Late..."

With Microsoft it appears that "always a bridesmaid but
never a bride" holds true. While GNU/Linux streams along
with new versions every 6 months with more and more
powerful options and innovations, Windoze clunks along with
years and years before its next big marketing push.

I have yet to see /anything/ developed by M$ to be state-of-
the-art for innovation. Why do they need to?

Today
it is safe to conclude that anyone still running Windoze is
running the old technology of computers. A technology that
is still using old, insecure and unstable models. To think
that people actually pay for this is the amazing thing.

And, Windoze gets bigger, slower, and buggier at every
release. I think M$ uses a variant of "computers will double
in power at half the price every two years" binary rule to
/assume/ that new users will buy more CPU and more memory just
in time for the latest and greatest bloatware.

I've seen performance for CPU, memory, and disk access go like
this: DOS lightning fast, Win 3.1 not bad, Win 95/98 slower
but still OK, XP slower yet, SP2 like molassis.

Of course, Win 3.1 was written in ordinary C and assembler.
Don't know what XP is written in but Visual C++ wouldn't
suprise me. It used to be that it was possible to optimize
code. Now, the millions of lines of code and huge development
teams preclude any optimization beyond what the compiler does.

Let's see, in 2 years, I'll be able to run a 7-10 GHz CPU,
have 32 gig memory, and a 100,000 rpm HD, so Longhorn ought to
run about the same as my AMD 3700 and 4 gig do today. Sounds
like a plan to me!

Sorry, but for me, Linux is still not ready for prime time on
the desktop. I use my PC to do useful work, not to play with
it, so I don't have the time, energy, or inclination to spend
an entire night rebuilding my system as my nephew does a
couple times a month trying to fix something that went bump in
the night. And, while there's plenty of open source software
to take the place of commercial Windoze apps and utilities,
the major development houses are still eschewing porting their
code to Linux - a varient of the old advertising saying
"nobody gets it until everybody wants it" - meaning, "I won't
port my code until everybody has Linux but mainstream users
won't "buy" Linux until their existing hardware and software
runs".

Oh, well, we each have to float our boats to what suits us.
Have a good one!

--
ATM, aka Jerry

"Whether You Think You CAN Or CAN'T, You're Right." ? Henry
Ford
.



Relevant Pages

  • Re: X performance
    ... >> under my linux X. ... But saving memory or CPU cycles are ... The memory it nominally consumes will be reclaimed pretty soon as it ... Red Hat 8or 9 may have increased memory needs. ...
    (comp.os.linux.misc)
  • Re: [FC4] System locks up when booting installation DVD
    ... be of help if you'd describe your system (motherboard make, hard drives, ... Doesn't matter whether I boot 'linux' or 'linux text'. ... CPU: Athlon XP ... Memory: 256 MB ...
    (Fedora)
  • Re: Porting from Linux to FreeBSD (procfs question)
    ... that is present under /proc in Linux. ... I have the same problem with the memory (how much memory is cached, ... CPU info: (vendor, model, clock speed, stepping, cache size, ... See misc/cpuid for a port that extracts this from the CPU. ...
    (freebsd-hackers)
  • Re: How analyze the system bottleneck using shell tools
    ... Linux Debian system in which there is a bbs system running there. ... You have to determine if it's I/O, memory, network or CPU. ... Look at the CPU, and see if the CPU is busy with system, user or idle. ...
    (comp.unix.shell)
  • Re: Why is this so slow?
    ... If you have memory read+write accesses you're bound to be slower than if you just have write access, because in the first case, well, the CPU has to access the memory, make the calculation and store the result. ... If your DIB is in AGP memory, then things could get really ugly since AGP memory isn't cached: the write-only code would be able to make use of write combiners, but the read/write code wouldn't, so if it were slower by a factor of 32 to 64 it wouldn't be surprising. ...
    (borland.public.delphi.language.basm)