Windows server admins learn to spread out their server processes so when windows takes a dump, everything is not down. It's better to have 4 domain controllers, 2 mail servers, and 4 file servers if you can guarantee your five 9's. Sure 85%-95% of the capacity goes unused, but when something fails it's not much of a problem to the users.
Unix/Linux/BSD uses clustering much in the same manner, but it's usually not necessary to spread out the load as much.
On a side note, all good engineers over engineer their products.
That's pretty awesome. I've messed around with a lot of different file systems (my latest being IBM's GPFS). I evaluated DrBD and nbd but found it to not perform as I expected. I was using all fiber channel disks and 2Gb fiber interconnects and was getting like 50MB/sec transfers. When we moved to GPFS, i clocked it at around 225MB/sec which is just about right where it should be.
most peering is from one provider to another. it's typically not used as internet transit. so if peerA and peerB have a peering point, traffic from one to the other goes over local network instead of having to go out to the internet and deal with external bandwidth costs. They peer to be closer to each other and to give each other's network a huge performance benefit of being directly connected.
Peering traffic doesn't traverse the internet so it cuts down the costs for both providers.
Therefore, peering has almost nothing to do with being multi-homed. You can have many peers which gives you quick and easy access to those peers, but it does nothing for your external bandwidth to providers you are not peered with.
I agree with you up to the point about the e-mail attachment size. Every mail server I've run has the ability to limit attachment size. If you run a mail server and have the problem of your users sending files that are too large through the server, it is YOUR fault.
Right, for MS, the beta test really starts when they first ship their product. What they send out now is really an alpha release with limited functionality.
I don't think they've ever really made a finished product. DOS was pretty good for what it did, espectially since it wasn't natively internet friendly.
If you were mirroring the data, the exact same data would be on your local drive as the remote one.
So if you render a movie, every bit that gets written to your local drive would also hit the network and get written to the network drive.
Reads could come from your local drive only, but native things like windows swapping would also be written to the network mirror.
I've done this over 10Mb and 100MB links, and at 10Mb, it's almost not usable for most cases. At 100Mb it's much more usable, but I bet with 10 or 100 people using it, it would become a major bottleneck.
Slashdot Mirror
The answer:
Windows.
Windows server admins learn to spread out their server processes so when windows takes a dump, everything is not down. It's better to have 4 domain controllers, 2 mail servers, and 4 file servers if you can guarantee your five 9's. Sure 85%-95% of the capacity goes unused, but when something fails it's not much of a problem to the users.
Unix/Linux/BSD uses clustering much in the same manner, but it's usually not necessary to spread out the load as much.
On a side note, all good engineers over engineer their products.
sounds to me like an apache with php problem.
I don't see how that would make it a linux worm. Does this "worm" also work on Solaris, HPUX, AIX, and other apache and php aware operating systems?
sounds to me like a new version of the old formmail.pl problem.
I will never use an electronic device that forces me to write on it in my own handwriting or any other PDAish grafitti like trash.
You sure about that? Most places i've gone to pay with a credit card require a signature, and quite a few of those use an electronic device.
Never say never.
That's pretty awesome. I've messed around with a lot of different file systems (my latest being IBM's GPFS). I evaluated DrBD and nbd but found it to not perform as I expected. I was using all fiber channel disks and 2Gb fiber interconnects and was getting like 50MB/sec transfers. When we moved to GPFS, i clocked it at around 225MB/sec which is just about right where it should be.
That's a VERY good suggestion. It would take minimal cost, minimal work, and probably provide the best long-term solution.
Be sure to also put in a filter so you're not returning dirty air to the house AC.
Well, if Cliff posted his summary on the topic, it would be Cliff's notes.
There are no restraunts in your zip code.
GOOGLE HAS SPOKEN!
you are partly right.
most peering is from one provider to another. it's typically not used as internet transit. so if peerA and peerB have a peering point, traffic from one to the other goes over local network instead of having to go out to the internet and deal with external bandwidth costs. They peer to be closer to each other and to give each other's network a huge performance benefit of being directly connected.
Peering traffic doesn't traverse the internet so it cuts down the costs for both providers.
Therefore, peering has almost nothing to do with being multi-homed. You can have many peers which gives you quick and easy access to those peers, but it does nothing for your external bandwidth to providers you are not peered with.
I don't think linux runs in 128KB RAM. :)
Anyways, screen is awesome.
cat /proc/sys/kernel/random/uuid | cut -c -16
I agree with you up to the point about the e-mail attachment size. Every mail server I've run has the ability to limit attachment size. If you run a mail server and have the problem of your users sending files that are too large through the server, it is YOUR fault.
Mmmm...just think, out there somewhere, some guy has a mirror copy of mp3.com
wild chicken vs. domesticated cat.
My money's on the chicken
I thought the HAM operators would come in handy during times like these. Where they be?
Right, for MS, the beta test really starts when they first ship their product. What they send out now is really an alpha release with limited functionality.
I don't think they've ever really made a finished product. DOS was pretty good for what it did, espectially since it wasn't natively internet friendly.
There's just something about the medical profession that says it's best to keep them local.
i dunno, I think one that wiped command.com off of the c:\ would be awesome. That way, all win98, win95, winme, win98se, etc would die.
sounds like a logical career path to me.
I don't follow your logic.
If you were mirroring the data, the exact same data would be on your local drive as the remote one.
So if you render a movie, every bit that gets written to your local drive would also hit the network and get written to the network drive.
Reads could come from your local drive only, but native things like windows swapping would also be written to the network mirror.
I've done this over 10Mb and 100MB links, and at 10Mb, it's almost not usable for most cases. At 100Mb it's much more usable, but I bet with 10 or 100 people using it, it would become a major bottleneck.
oh man that would be slow. Think of an office of 50 people all mirroring over 802.11b or g. That would be horrible.
and when your feet stick to the floor, you know it's time to call the maid.
and you can watch a movie in your underwear, and not get kicked out of the theater.
and there's that neat feature called "Pause" that can be used to stop the movie when you get up to go pee.
Then i guess the movie studios win, in an odd sort of way.
1. make sucky movies so no one will bother downloading them.
2. ???
3. profit?
don't assume every network connection is internet-bound. Most traffic is intranet.
Besides, someone that pays $12,000 for a wireless switch device probably already has 1Gb fiber.
yeah, but i'll be the hills of between 4 and 8 years ago as Google maps is a little out of date. Hey, maybe you could see the 2000 bubble pop.
..."cash out and run for the hills".