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 : LINUX -- Ignore unavailable to you. Want to Upgrade?

To: Charles Tutt who wrote (1448)	4/15/1999 10:14:00 AM
From: E. Charters	Respond to of 2615

The SPARC 20 is 1994-1995. Many ISP's installed these at 20K a pop and added all kinds of hardware and software to bring the cost to about 28,000 or more. A comparable machine running cheap rack IDE's would cost about $5,600 running BSDI or Linux and it would outperform it by 100%!. If you add raid to either system then you have a cost increase of a factor. To really run database properly you need hot swappable raid SCSI. It is not really worth it to buy a server class machine either as the off the shelf put together clone stuff is superior quality. You can buy kinston ram and asus boards and fujitsu scsi drives and wire it your self and get a superior product to anything with a name tag. If you do raid the transactions per second in real world terms are useful to look into. Its serious apples and oranges out there if you need a really fast system. Linux will support the fastest class of server machines but if you want hordes of tiny processes served you might be better to write your own heap and ram indexed managed database. If you have a rapidly updating database and and want broad fast process client access it would be a mistake to try to administer the standard databases as they frequently put you in record and page locking hell (MS access). Writing your own time stamped system that would not lock page or record during update is preferrable. After all peering at records by clients does not need record locking if the record is updating by the second and the client knows that. All he needs to look at is a copy of the record as of a time. A chron process can update him on update back at the record ranch. This way records are not constantly locked out from others as they are updated. Old copies are gladly served. You could call it the warm-is-good-enough coffee-record bar. More on this as the mighty bizLinux product grows and grows. EC<:-}