Yes you are right, testing has to be done on slow AND fast machines. In a multithreaded application, an example of an annoying performance bottleneck is a deadlock where all threads end up waiting for another, which may only occur in particular environment (CPU, memory, network speed/latency).
Testing must be done on as many configuration variations as possible, and of course, experience helps too.
But that test machine should be a plain windows install without the compiler environment installed on it, because your project might just work only with those special msvc++ dlls...
The problem is that they are running out of large subnets for large organizations and ISPs, so that there now are many organizations and ISPs with multiple smaller subnets. So instead of having one routing table entry for a large subnet, the backbone routers now need multiple entries that point to the same gateway(s) for that single destination...
Of course you may. Very Interesting... Gives IE a lot of Mozilla features that IE alone didn't have.
Just uses the renderer, like Galeon and Phoenix do with the Gecko renderer of Mozilla.
But since I'm now running Mozilla, It should be much better than Mozilla for me to switch back (and it would need to run on Linux too). But it sure does look like a good secondary browser. for, for example mazdausa.com that responds "browser not supported" even though it would probably work just fine if the server thought it was one of the 'supported' ones (I had a 'user-agent'-switch once in Mozilla for that, but lost it after a apt-get dist-upgrade...).
Not for me, I couldn't do without tabbed browsing and popup-ad blocking anymore. And those are just two of the many features that Mozilla has but the exploder doesn't.
Re:Don't read too much into Googles response ...
on
Forget Moore's Law?
·
· Score: 1
You worded it much better than I did, but that what you said was pretty much what I was thinking...
Re:Don't read too much into Googles response ...
on
Forget Moore's Law?
·
· Score: 1
"you suddenly have to have a mechanism that "knows" exactly which db server has the item you're interested in."
That's what they invented hashes for. What do you thing the "q=cache:CjvO3xI_O_EC:" is for on the google URLs for cached pages?
"When you're creating your listing pages, you have to query multiple db servers to complete your listings."
So does google. A search query goes to each machine, and each machine has a subset of the 'google database'. The trick is that they respond quickly because the DBs are fully in RAM and small because of the small data subset it's keeping. Definitely no mirrroring, as no single DB server contains all data, each DB server contains a part of the data. Software expenses are countered by using software that isn't licensed per seat (hint: Google runs on Linux).
"All these things are either non issues are greatly dimished when you have the google type application."
Ebay has a google-type application. Ebay could do exactly the same thing by splitting their database by auction or seller. A search query goes to each db server that has everything in RAM so that it can easily handle the request load.
There are tops only a few dozen of people active per auction, so each server should easily be capable of more than one auction.
Optimizations are possible too: auction distribution could balance the load by making sure that not all auctions for a machine end at the same time.
Grouping by seller reduces the amount of transactions needed when the sellers login and lookup their account stats.
Re:Don't read too much into Googles response ...
on
Forget Moore's Law?
·
· Score: 1
"ebay has one huge one."
No. Ebay has one synchronization requirement per auction item. It could use the google strategy and use small machines that each handle only one or a few auctions (or sellers). Those machines don't need to be synchronized with each other, because their tasks are independent of each other.
No that would not be cool. That would turn this into a lycos, excite, yahoo, or whatsamacallit dot com. Actually, I often do enjoy those sites too, but they are not slashdot and slashdot is not them, neither should it try to be.
Slashdot is cool as it is. Nerd for Nerds, Stuff that Matters. Not 'prechewed and spellchecked news for [selfcensored]'
Don't like it? Go try building a community yourself, and stop bitching here. Or write a (perl) script that detects double stories and filters them for you, then submit that to CmdrTaco for inclusion in the slashcode, with a 'preferences' setting to enable it for the whiners.
The fact that some stories are double simply is not 'stuff that matters'.
It's not even 100% certain he's dead (no body), so he could be dead like spock was... Actually, I think they even did make a backup of Data's brain, so even if the body was destroyed, they can still do a 'tar xzvplf' once they build a new (improved?) body...
Oh, man. I thought about that in way too much detail... I need more beer and sports.
Anyways if these low numbers mean that "Trek" is dead, then Data automatically is too...
Track record baby. Even though this one could've been patched a long time ago, it makes one think of which other security problems are not yet discovered...
I like the PostgreSQL suggestion a lot better. It never even needed the ff-en patch to begin with.
I actually block outgoing port 25 too from all machines except the mail servers. That way, if someone's Windos box gets a nasty outlook virus that goes out and makes its own port 25 SMTP outgoing mail connections, it won't work. It will only work when it uses the mail server as a relay, and then the logs can tell that it happened and whose PC/laptop needs a virusscanner update...
And I'm thinking about installing a transparent proxy, so that people don't have to set it up manually to get faster browsing (yes, even on a fast line a proxy will speed it up, because all the images from the more popular websites will be retrieved with only LAN latency instead of WAN latency. I even use a proxy at home for just myself even though it's a cable modem and I notice a slowdown if I switch it off.
You are probably right for the quality level of your work. However, music of a lower recording/studio quality will still be liked and loved by a lot of people. Just go to a large city with lots of live music, they play in bars on often simple setups, and the people love it.
The current oligopoly setup has pretty successfully supressed that large group of non top-studio-recorded musical performances and the listeners were forced into 'consumer' positions where they were only presented with the 'creme brulee' recordings so to say. But often a grilled steak or beer with wings will taste very well indeed.
Get prepared for a market with lots of music out there performed in studios with, for your standards, sub-standard equipment, professionalism and sound quality. And also be prepared that a lot of listeners will enjoy listening to it. That doesn't mean there won't be any demand left for quality work and equipment. It just means that the artists and fans that aren't big, fast, or rich enough for the good stuff still get to play their game without being blocked out by the 'market' situation. It will probably actually result in more work for you because there will be more bands out there that start small and cheap and that later will be looking into something better. More music will enter the 'funnel', leading to a larger number of bands requiring hours in the high quality studios.
Even though it may not be on a PCI connector, in the chipset or on the motheboard that SCSI controller would also be coupled on the PCI bus, hence it would have to share the theoretical max 132MB/s bandwidth with the grabber cards.
Some serverworks chipsets have more than one PCI bus though...
On a set of 3 5400 IDE disks (two even sharing one cable) and software raid0, I've sustained 40+ MB/s writes across the whole diskspace with a 700Mhz Athlon processor going to 70+ MB/s for a non-cached read of a 4GB datablock (didn't test bigger) on 7200RPMs and 1.4Ghz. And I'm seeing 100MB+ writing through raidware controllers on PCI66/P3-1Ghz to 7200RPM disks (ok, the latter is not low-end hardware, but it's cheap enough these days to not be considered high-end either (much cheaper than a netapp)).
20MB/s is not a lot anymore. Maybe a lot for a single disk, but not in software raid0 on a couple of disks, when using the right OS (linux 2.4), filesystem (ext3), and raid chunk size. With 1GB NICs it can even be sent across a crosswired network cable to a fileserver at higher speeds than that. 1GB cards are less than $50 each these days, and for short runs crosswiring works fine with UTP5. $100 worth of RAM can buffer more than twelve seconds at 20MB/s, which is more than enough to catch temporary slowdowns due to the worst-case bad-track-seeks that should each last less than four times the average seek time. The PCI bus isn't locked during a disk seek, so no data has to be lost at all.
Note these are streams, not database accesses, so the seeking time is pretty much nonexistent due to the 2MB on-disk write buffers in current IDE disks plus with the RAID pivoting it gets you towards the UDMA interface speed instead of the media speed of the disks. (write a burst to the cache with write buffering, and move to next disk while its being transfered to the media with the IDE bus only locked during the quick interface to buffer transfer, not during the buffer to media transfer due to the write buffering of the drives).
Slashdot Mirror
Yes you are right, testing has to be done on slow AND fast machines. In a multithreaded application, an example of an annoying performance bottleneck is a deadlock where all threads end up waiting for another, which may only occur in particular environment (CPU, memory, network speed/latency).
Testing must be done on as many configuration variations as possible, and of course, experience helps too.
But that test machine should be a plain windows install without the compiler environment installed on it, because your project might just work only with those special msvc++ dlls...
And 99% of the spam to one of my old email accounts is korean...
(of course, spamassassing is very effective at filtering that).
"But this doesn't necessarily mean the commercial companies are inferior; they may very well be right in having different priorities."
Like "Making money" instead of "Making users happy"?
[snip] "But what percent of graphic designers are really using the Gimp" [snip] "Unless you can come up with a scheme to fund development" [snip]
Ummm... Film Gimp Chalks Up Another Studio. It happens.
The problem is that they are running out of large subnets for large organizations and ISPs, so that there now are many organizations and ISPs with multiple smaller subnets. So instead of having one routing table entry for a large subnet, the backbone routers now need multiple entries that point to the same gateway(s) for that single destination...
Of course you may. Very Interesting... Gives IE a lot of Mozilla features that IE alone didn't have.
Just uses the renderer, like Galeon and Phoenix do with the Gecko renderer of Mozilla.
But since I'm now running Mozilla, It should be much better than Mozilla for me to switch back (and it would need to run on Linux too). But it sure does look like a good secondary browser. for, for example mazdausa.com that responds "browser not supported" even though it would probably work just fine if the server thought it was one of the 'supported' ones (I had a 'user-agent'-switch once in Mozilla for that, but lost it after a apt-get dist-upgrade...).
Not for me, I couldn't do without tabbed browsing and popup-ad blocking anymore. And those are just two of the many features that Mozilla has but the exploder doesn't.
You worded it much better than I did, but that what you said was pretty much what I was thinking...
"you suddenly have to have a mechanism that "knows" exactly which db server has the item you're interested in."
That's what they invented hashes for. What do you thing the "q=cache:CjvO3xI_O_EC:" is for on the google URLs for cached pages?
"When you're creating your listing pages, you have to query multiple db servers to complete your listings."
So does google. A search query goes to each machine, and each machine has a subset of the 'google database'. The trick is that they respond quickly because the DBs are fully in RAM and small because of the small data subset it's keeping. Definitely no mirrroring, as no single DB server contains all data, each DB server contains a part of the data. Software expenses are countered by using software that isn't licensed per seat (hint: Google runs on Linux).
"All these things are either non issues are greatly dimished when you have the google type application."
Ebay has a google-type application. Ebay could do exactly the same thing by splitting their database by auction or seller. A search query goes to each db server that has everything in RAM so that it can easily handle the request load.
There are tops only a few dozen of people active per auction, so each server should easily be capable of more than one auction.
Optimizations are possible too: auction distribution could balance the load by making sure that not all auctions for a machine end at the same time.
Grouping by seller reduces the amount of transactions needed when the sellers login and lookup their account stats.
"ebay has one huge one."
No. Ebay has one synchronization requirement per auction item. It could use the google strategy and use small machines that each handle only one or a few auctions (or sellers). Those machines don't need to be synchronized with each other, because their tasks are independent of each other.
You'd still have only 2/3rd of the number of chips per wafer.
Nobody says they can't use the kernel code. They can use it and sell it no problem. They just have to release the source too when they do.
Goodwill is worth something too, and that is most often not builtup by receiving moneys.
No that would not be cool. That would turn this into a lycos, excite, yahoo, or whatsamacallit dot com. Actually, I often do enjoy those sites too, but they are not slashdot and slashdot is not them, neither should it try to be.
Slashdot is cool as it is. Nerd for Nerds, Stuff that Matters. Not 'prechewed and spellchecked news for [selfcensored]'
Don't like it? Go try building a community yourself, and stop bitching here. Or write a (perl) script that detects double stories and filters them for you, then submit that to CmdrTaco for inclusion in the slashcode, with a 'preferences' setting to enable it for the whiners.
The fact that some stories are double simply is not 'stuff that matters'.
It's not even 100% certain he's dead (no body), so he could be dead like spock was... Actually, I think they even did make a backup of Data's brain, so even if the body was destroyed, they can still do a 'tar xzvplf' once they build a new (improved?) body...
Oh, man. I thought about that in way too much detail... I need more beer and sports.
Anyways if these low numbers mean that "Trek" is dead, then Data automatically is too...
I like the duck...
Track record baby. Even though this one could've been patched a long time ago, it makes one think of which other security problems are not yet discovered...
I like the PostgreSQL suggestion a lot better. It never even needed the ff-en patch to begin with.
I actually block outgoing port 25 too from all machines except the mail servers. That way, if someone's Windos box gets a nasty outlook virus that goes out and makes its own port 25 SMTP outgoing mail connections, it won't work. It will only work when it uses the mail server as a relay, and then the logs can tell that it happened and whose PC/laptop needs a virusscanner update...
And I'm thinking about installing a transparent proxy, so that people don't have to set it up manually to get faster browsing (yes, even on a fast line a proxy will speed it up, because all the images from the more popular websites will be retrieved with only LAN latency instead of WAN latency. I even use a proxy at home for just myself even though it's a cable modem and I notice a slowdown if I switch it off.
He _has_ the source... So why is he spending so much time making websites, instead of fixing the features he's complaining about?
I guess the best programmers "program" html...
The people in the bars loaded to the brim like it. Duh.
You are probably right for the quality level of your work. However, music of a lower recording/studio quality will still be liked and loved by a lot of people. Just go to a large city with lots of live music, they play in bars on often simple setups, and the people love it.
The current oligopoly setup has pretty successfully supressed that large group of non top-studio-recorded musical performances and the listeners were forced into 'consumer' positions where they were only presented with the 'creme brulee' recordings so to say. But often a grilled steak or beer with wings will taste very well indeed.
Get prepared for a market with lots of music out there performed in studios with, for your standards, sub-standard equipment, professionalism and sound quality. And also be prepared that a lot of listeners will enjoy listening to it. That doesn't mean there won't be any demand left for quality work and equipment. It just means that the artists and fans that aren't big, fast, or rich enough for the good stuff still get to play their game without being blocked out by the 'market' situation. It will probably actually result in more work for you because there will be more bands out there that start small and cheap and that later will be looking into something better. More music will enter the 'funnel', leading to a larger number of bands requiring hours in the high quality studios.
A renaissance for music. It's coming.
Correct. And/or press Ctrl-+ and up goes the Font size. Works in Mozilla and Konqueror.
Even though it may not be on a PCI connector, in the chipset or on the motheboard that SCSI controller would also be coupled on the PCI bus, hence it would have to share the theoretical max 132MB/s bandwidth with the grabber cards.
Some serverworks chipsets have more than one PCI bus though...
On a set of 3 5400 IDE disks (two even sharing one cable) and software raid0, I've sustained 40+ MB/s writes across the whole diskspace with a 700Mhz Athlon processor going to 70+ MB/s for a non-cached read of a 4GB datablock (didn't test bigger) on 7200RPMs and 1.4Ghz. And I'm seeing 100MB+ writing through raidware controllers on PCI66/P3-1Ghz to 7200RPM disks (ok, the latter is not low-end hardware, but it's cheap enough these days to not be considered high-end either (much cheaper than a netapp)).
20MB/s is not a lot anymore. Maybe a lot for a single disk, but not in software raid0 on a couple of disks, when using the right OS (linux 2.4), filesystem (ext3), and raid chunk size. With 1GB NICs it can even be sent across a crosswired network cable to a fileserver at higher speeds than that. 1GB cards are less than $50 each these days, and for short runs crosswiring works fine with UTP5. $100 worth of RAM can buffer more than twelve seconds at 20MB/s, which is more than enough to catch temporary slowdowns due to the worst-case bad-track-seeks that should each last less than four times the average seek time. The PCI bus isn't locked during a disk seek, so no data has to be lost at all.
Note these are streams, not database accesses, so the seeking time is pretty much nonexistent due to the 2MB on-disk write buffers in current IDE disks plus with the RAID pivoting it gets you towards the UDMA interface speed instead of the media speed of the disks. (write a burst to the cache with write buffering, and move to next disk while its being transfered to the media with the IDE bus only locked during the quick interface to buffer transfer, not during the buffer to media transfer due to the write buffering of the drives).