Re: WHY

aaron_kempf_at_hotmail.com
Date: 12/27/04 

Date: Mon, 27 Dec 2004 13:55:04 -0800

yeah, like it takes a doctorate to explain IBM's family of operating
systems.

the bottom line is that they don't have consistent offerings; they are
confusing; they are not consistent.

they are the biggest waste of intellectual capital of all time.

i had read that 7 out of 10 CS graduates worldwide goes to work for IBM.

I just think that it is ridiculous that they have 20 different operating
systems.

And re: Windows OS; i only know of ONE Windows-- that is Windows 2000. I
haven't used 9x since uh.. 95.. NT workstation was always preferable to me--
since it was stable; and it was fast.

Windows 2003 is a different version of the same OS-- it's not like you need
to rewrite everything in order to upgrade a webserver to 2003.

2003 has some AWESOME performance and security benefits.

and from what I've seen with databases; there is no point in keeping a dozen
mainframe administrators around in order to write RPG reports and bs like
that.

I don't argue that Microsofts' approach is FLAWLESS. But it is a much
better VALUE than anything else on the market-- even mySql costs a crapload
of money for commercial use.

MSDE-- Microsoft Data Engine-- this is a truly free database backend; and
the next version is going to clean up market share like you've never seen
before.

<hrlngrv@aol.com> wrote in message
news:1104179706.476661.63370@z14g2000cwz.googlegroups.com...
> aaron_kempf@hotmail.com wrote...
> >yes, I do expect you to believe that.
>
> ??!
>
> >SQL Server on commodity hardware is always a better price-performance
> >proposition than being tied into one mainframe vendor.
>
> mySQL or PostgreSQL running under Linux or [Free/Net]BSD on commodity
> hardware is even better price-performance, which is why it's dominant
> on the web. You're also ignoring (or ignorant of) sunk costs. Companies
> that already have mainframes (owned or leased) and a stock of tested
> mainframe software would find the price-performance of sticking with
> existing procedures much better than change for change's sake alone.
>
> >i'm sorry that IBM wants you to change the OS every other year; I
> think that
> >is kindof comical
>
> Change the OS? The mainframes I have worked with and still work with
> have all run MVS (I also had a brief stint using CMS under VM). Are you
> confusing MVS version updates with changing OSs? And Microsoft doesn't
> expect the same thing to happen each time they release a new Windows
> version? Or are you referring to mainframe versions of Linux, which are
> almost always run under VM (which has been around for over two decades)
> along with MVS and even DOS/360 for some real legacy stuff? If so,
> Linux on mainframes is a replacement, and under VM runs along side
> preexisting OSs.
>
> So adding proof of your ignorance of mainframes to your demonstrated
> ignorance of supercomputers and clusters. Well done!
>
> >And, no... i analyzed billions of records with subsecond response
> times
> >using this technology called OLAP. recordcount becomes irrelevent
> once you
> >start storing aggregations in multi-dimensional structures.
> ...
>
> No it doesn't. You have possibly many CPUs. Each of those CPUs has a
> max data throughput no faster than its clock speed. If you have 4 CPUs
> running in parallel each with 2GHz clock speeds, the fastest you could
> run through 1 billion records each of 100 bytes would be 3 1/3 seconds.
> That assumes no OS overhead, no parallel processing synchronization
> overhead, and 32-bit word throughput equal to clock speed. No way!
>
> What would almost certainly be going on is caching of intermediate
> results and indexing to skip unneeded records. Definite benefits to
> that, but such benefits could be achieved by other means as well. But
> the speeds you're reporting are *not* the result of querying the
> underlying database.
>
> That's the way Essbase and Applix TM/1 work, and (FWLIW) the way VP
> Planner's 'Multidimensional Database' worked back in the late 1980s.
>
> >I just know that most of these accounting and finance problems that
> you
> >think are _SO_COMPLEX_ are easily solveable using industry-standard
> >databases.
>
> Really? How do you use a database to hedge a commercial bond portfolio
> against liquidity and call risk using interest rate derivatives? How do
> you use databases to calculate risk based capital for banks or
> insurance companies requiring estimates of confidence intervals of
> statistical distributions? How do you use a database to decide between
> alternative aircraft designs using different types of jet engines with
> different thrust and fuel consumption characteristics? How do you use a
> database to construct the optimal course schedule for a university for
> a given term, where optimality is the measured as the greatest number
> of students able to take the greatest number of their first choice
> courses given class size and/or classroom seating constraints?
>
> There really are real world problems that require more than counting
> and totalling. No question databases would often be the ideal storage
> subsystems for such applications, but most of the real work would need
> to be done by procedural or functional code. Not necessarily
> spreadsheets, but neither via SQL nor OLAP.
>
> >And everyone would be better off to stop using Excel and to start
> using
> >Access.
>
> For database-like tasks, agreed as long as they have Access. In case
> you've missed this point in previous messages, not every version of
> Office comes with Access, but all come with Excel. One can only use the
> tools one has.
>
> For decidedly non-database tasks, it'd be pure foolishness to use
> Access. Which is why you'd use it.
>
> >I know that the RDBMS solutions are a better way to analyze records
> and
> >build reports than using Microsoft excel.
>
> Granted. However, to repeat yet again, not everything done in Excel
> involves generating reports from records. It may be theoretically
> possible to bludgeon any application's data into normalized tables and
> create data structures from SQL queries, but it makes no more sense to
> do so for most non-report spreadsheets than it would to use an RDBMS to
> implement an bitmap drawing package or compressed file archiver.
>
> >You don't need to try to slam my experiences.. You're the one that is
> >obsolete kid
>
> So far you've demonstrated that you don't know
>
> 1. what an amortization table is,
> 2. what calculation-intensive software (what's run on supercomputers
> and clusters) is,
> 3. how to structure currency conversion rate tables,
> 4. anything about financial services businesses,
> 5. what MDX really provides (as opposed to what you believe it
> provides) compared to Excel,
> 6. any statistics beyond what an average is,
> 7. any DBMS other than SQL Server under Windows,
> 8. any real time systems,
> 9. details of the history of the dot.com bubble and bust,
> 10. what people outside the IT departments really do beyond generating
> regular, repetitive reports.
>
> Maybe you have business experience beyond writing database reporting
> apps that any other moderately competent DB programmer could have
> written, but you haven't demonstrated any subject knowledge, not even
> any detailed SQL knowledge (your pathetic attempt at a rough
> description of how you'd put together an amortization table in a DBMS
> was particularly indicative of the shallowness and narrowness of your
> capabilities).
>