Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : How high will Microsoft fly? -- Ignore unavailable to you. Want to Upgrade?

To: dybdahl who wrote (52079)	10/23/2000 5:17:29 PM
From: sandeep	Read Replies (2) \| Respond to of 74651

dybdahl, you are comparing apples and oranges to suit your need to criticize Microsoft. The linux OS that boots from a floppy and runs in 4MB doesn't have most of the functionality of the win2k that doesn't run in 64MB. In fact the embedded NT product does allow proper componentization to achieve smaller footprint at the expense of functionality.

To: dybdahl who wrote (52079)	10/23/2000 5:39:20 PM
From: Michael Do	Read Replies (1) \| Respond to of 74651

<Message #52079 from dybdahl at Oct 23, 2000 4:56 PM The Linux OS can boot from a floppy disk and works well in 4MB RAM. Windows 2000 doesn't run well in 64MB RAM. The next version of Linux does NOT use more memory. Windows 2000 uses much more memory than Windows NT.> When RAM is < $1 per Meg no one will care if the OS need 64mb or 4mb. Linux might be relevant in the server and embedded market but will never be significant in the desktop market even if it free. Mike

To: dybdahl who wrote (52079)	10/24/2000 4:34:33 AM
From: Nick Kline	Read Replies (2) \| Respond to of 74651

Regarding: I once took a 200MB database from a Microsoft SQL Server and stored the data in an Access database. That reduced the data amount to 30MB. I was quite surprised. Then I exported the data to ASCII. 5MB. Then I zipped it. 1MB. Then I started to wonder what MS SQL server does to the data... The database was not especially selected for this experiment. There must have been a reason why this happened. Some reasons why it might have happened: 1. sql server allocates a certain amount of blank space per page, so that inserts won't always lead to splits. Users can specify this value. Maybe it was high in this case. 2. sql server allows you to preallocate space in files (if you so desire) so that when a table grows, the pages will be contiguous, avoiding the need for fragmenting 3. were the indexes the same? if there were special indexes in sql server, such as clustered or extra indexes not present in access, then the space usage would be much less. If you just store the info in the table without indexes, then you will need much less space. These indexes make your queries run faster. You can't make a tradeoff of space vs efficiency without being more specific about what is going on. Databases do lots of complex things to make queries run faster. 4. space efficiency - databases make lots of tradeoffs for speed vs space. Just because you can compress something down doesn't mean that it would be faster. Databases may precompute certain statistics or queries, or many other things just so that the results are available faster (not saying anything about what sql server does or does not do here :-)) 5. if the data was all zeros, it is possible that some special compression algorithm could squeeze it down quite a bit (think some dictionary based approach like limpel-zev - did I spell limpel right?) Bottom line - there is no way that a table in sql server would take so much more space than these other mechanisms, unless there was something special going on, like access didn't have the same indexes as sql server. Disclaimer: I work at ms on sql server, but I am definitely not paid to read this newsgroup (I read it on my own free time - lets hope the stock goes up :-)). I work on the optimizer (query procesor) for sql server, not marketing. Perhaps I haven't been invited to join the secret ram conspiracy yet, but I am not aware of any effort to use more ram than necessary - really. -nick