No, no! It should be:
All your ports are belong to us!
Damn, that sounds like we're getting in the rear.
Hmmm, we are, aren't we?
Re:why would anyone use windows as a server?
on
Broadband Crackdown
·
· Score: 1
In fairness, any OS can cause bandwidth problems.
But, I must agree, it's primarily due to M$ due
to their complete lack of concern when it comes
to worms like Code Red.
My solution: You are allowed to run a server
over broadband IFF 1: you demonstrate technical
competence, and 2: you implement mechanisms to
prevent bandwidth problems. An example would be
to prevent heavy usage during peaks periods, the
peak period being say the evening in your timezone. The ISP must monitor bandwidth usage,
and could throttle and/or block depending upon a reasonable TOS. Code Red would not be impacting
the bandwidth as it is today.
I don't see what all the fuss is about. So what if the ice caps melt, and millions have to relocate. Think about
it, there will be 2 entirely new land masses in which to colonize. Large land masses. The biggest of the
continents, and here we are bitching about it. I'm all for the undiscovered country.
You are misinformed and naive.
First, there is NO land mass under the North Pole.
Second, even if relocation of those flooded out
was not a problem (it would be), we do not know
what would happen to global weather patterns.
Not to mention if the volcanoes of Antartica
were to be more active due to the lack of weight
sitting upon the land mass.
I'd rather have a separate LED panel that I
can hang off the monitor.
If you are stuck on a windoze box, knowing
that the HD is overactive when it should not
can be informative. But if you cannot hear
the HD then you would have to check for HD
activity, and you know what happens
when you proactively check on a problem.
I seriously consider a non-silent HD an
important feature on windoze machines.
Can we expect further marketing efforts of Linux
this fall to counteract those of MS?
The Wintel alliance is expected to spend
over $1 Billion with the XP rollout.
If IBM could spend just a fraction of that
promoting Linux...
Linux on NFL TV broadcasts...
Tux at halftime of the Super Bowl.
If you don't test, failover will fail.
Many Internet eons ago, I dealt with a
system (codenamed Rosewood)
and it's offspring that were fault tolerant.
I learned early on to simulate failures to
exercise the redundant components
to make sure they were functioning. Sometimes daily but at least weekly.
It's less stressful to catch that failure of
the backup, and go back to the primary
while the primary can *still* function.
It also makes life easier on the weekends!
From MEGAN DOSCHER: I am the MSNBC editor at WSJ.com. The British
paper's story about MSNBC editing one of WSJ's articles isn't true -- an early
version of the Microsoft story was published to MSNBC by one of our editors,
and unbeknownst to us, it was never updated with the final version. We got two
pieces of reader mail on Friday morning telling us that MSNBC was "editing"
the story, and we checked and realized the production error and fixed it right
away. We also explained what happened to the two readers who wrote in.
Actually, the version that appeared on MSNBC was also the version that
appeared in both the two-star and three-star editions of the print Wall Street
Journal. It was different only from the (very late) four star.
It's much easier to have an internal versioning
system that allows marketing to have their own
version numbers on top of developments, ex: W.X.Y.Z
where W.X is marketing, and Y.Z is set by
the developers. Marketing can jump the numbers
to a.oh (ex: 5.0) whenever they deem so,
but behind the scenes, development still has
control of the versioning. The only trick is
that you have to make sure the marketing people
can add using positive increments.
It's possibly the same issue.
A traceroute:
traceroute to x.x.x.x (x.x.x.x), 30 hops max, 40 byte packets
1 main2-main1-eth.sjc1.above.net (207.126.96.190) 0.504 ms 1.328 ms 0.424 ms
2 core5-main2-oc12.sjc1.above.net (209.133.31.189) 0.497 ms 0.568 ms 0.460 ms
3 core3-sjc1-oc48.sjc2.above.net (208.184.102.206) 0.586 ms 0.606 ms 0.506 ms
4 iad1-sjc2-oc48.iad1.above.net (216.200.127.25) 68.858 ms 71.203 ms 71.400 ms
5 core3-core1-oc48.iad1.above.net (209.249.203.33) 69.143 ms 68.918 ms 68.825 ms
6 att-iad.iad.above.net (216.200.254.98) 70.522 ms 70.692 ms 71.711 ms
7 gbr2-p50.wswdc.ip.att.net (12.123.8.225) 70.374 ms 69.960 ms 70.624 ms
8 ar1-p310.wshdc.ip.att.net (12.123.194.1) 71.107 ms 70.753 ms 71.323 ms
http://www-db.stanford.edu/~backrub/google.html
Note: the document was written in 1998.
two snipets:
6.3 Scalable Architecture
Aside from the quality of search, Google is designed to scale. It must be efficient in both space and time, and constant factors
are very important when dealing with the entire Web. In implementing Google, we have seen bottlenecks in CPU, memory
access, memory capacity, disk seeks, disk throughput, disk capacity, and network IO. Google has evolved to overcome a
number of these bottlenecks during various operations. Google's major data structures make efficient use of available storage
space. Furthermore, the crawling, indexing, and sorting operations are efficient enough to be able to build an index of a
substantial portion of the web -- 24 million pages, in less than one week. We expect to be able to build an index of 100 million
pages in less than a month.
9.1 Scalability of Google
We have designed Google to be scalable in the near term to a goal of 100 million web pages. We have just received disk and
machines to handle roughly that amount. All of the time consuming parts of the system are parallelize and roughly linear time.
These include things like the crawlers, indexers, and sorters. We also think that most of the data structures will deal gracefully
with the expansion. However, at 100 million web pages we will be very close up against all sorts of operating system limits in
the common operating systems (currently we run on both Solaris and Linux). These include things like addressable memory,
number of open file descriptors, network sockets and bandwidth, and many others. We believe expanding to a lot more than
100 million pages would greatly increase the complexity of our system.
A 64 bit time_t has been discussed for some time now (esp in csy2k). It does not require a 64 bit processor to implement either.
As to changing it to be in milliseconds, that would be a problem as you are then changing the *interpretation* of the time_t, which could require inspection of the code which is much
more work than a re-compile.
Of course a 64 bit time_t will result in extra work if it is stored in a file or database as a 64 bit field/column.
Slashdot Mirror
No, no! It should be:
All your ports are belong to us!
Damn, that sounds like we're getting in the rear.
Hmmm, we are, aren't we?
But, I must agree, it's primarily due to M$ due to their complete lack of concern when it comes to worms like Code Red.
My solution: You are allowed to run a server over broadband IFF 1: you demonstrate technical competence, and 2: you implement mechanisms to prevent bandwidth problems. An example would be to prevent heavy usage during peaks periods, the peak period being say the evening in your timezone. The ISP must monitor bandwidth usage, and could throttle and/or block depending upon a reasonable TOS. Code Red would not be impacting the bandwidth as it is today.
M$ *IS* the problem.
AOL Agrees to Buy IPC for $1.6 Billion_ ipc_aol_dc_2.html
http://dailynews.yahoo.com/h/nm/20010725/bs/media
--
This must be bad. I had to reload the page before any FPs showed up!
--
You are misinformed and naive.
First, there is NO land mass under the North Pole.
Second, even if relocation of those flooded out was not a problem (it would be), we do not know what would happen to global weather patterns. Not to mention if the volcanoes of Antartica were to be more active due to the lack of weight sitting upon the land mass.
--
>Isn't today July 10th?
Not necessarily.
It may be July 11th in your timezone.
--
Wasn't getting the source code and internal documentation an option?
IIRC, by default you only received the object libs.
--
> ... I wonder if you could setup an extension of NNTP with authentication to
> prevent groups being killed in spam and restore the "ad-hocracy"?
You can prevent spam in a given newsgroup via a feature called moderation.
The problem is that it is time consuming to be a moderator.
--
I'd rather have a separate LED panel that I can hang off the monitor.
If you are stuck on a windoze box, knowing that the HD is overactive when it should not
can be informative. But if you cannot hear the HD then you would have to check for HD activity,
and you know what happens when you proactively check on a problem.
I seriously consider a non-silent HD an important feature on windoze machines.
--
This site still has problems, though I doubt they are due to Cisco systems! (Anymore)
Blank pages or comments from a completely different topic appearing sure point to database problems.
But when slashdot is slashdot-ed, you can expect any symptom.
--
Can we expect further marketing efforts of Linux this fall to counteract those of MS?
The Wintel alliance is expected to spend over $1 Billion with the XP rollout.
If IBM could spend just a fraction of that promoting Linux...
Linux on NFL TV broadcasts...
Tux at halftime of the Super Bowl.
--
If you don't test, failover will fail.
Many Internet eons ago, I dealt with a system (codenamed Rosewood)
and it's offspring that were fault tolerant.
I learned early on to simulate failures to exercise the redundant components
to make sure they were functioning. Sometimes daily but at least weekly.
It's less stressful to catch that failure of the backup, and go back to the primary
while the primary can *still* function.
It also makes life easier on the weekends!
--
Perhaps we should just Ask Cyc?
Submit questions as usual, send them to Cyc.
Cyc, is signinst.org a good plan for AI?
Cyc, can you relate to my sig?
Because that is what is HARDCODED in the HTML.
Why don't they update it? That is the question!
Hmmm...
No Taxation without Re-compilation!
Seems the article at the WSJ was updated
today (June 18), and no longer mentions
SUN Microsystems.
From http://www.poynter.org/medianews/letters.htm
From MEGAN DOSCHER: I am the MSNBC editor at WSJ.com. The British paper's story about MSNBC editing one of WSJ's articles isn't true -- an early version of the Microsoft story was published to MSNBC by one of our editors, and unbeknownst to us, it was never updated with the final version. We got two pieces of reader mail on Friday morning telling us that MSNBC was "editing" the story, and we checked and realized the production error and fixed it right away. We also explained what happened to the two readers who wrote in. Actually, the version that appeared on MSNBC was also the version that appeared in both the two-star and three-star editions of the print Wall Street Journal. It was different only from the (very late) four star.
It's much easier to have an internal versioning system that allows marketing to have their own version numbers on top of developments, ex: W.X.Y.Z where W.X is marketing, and Y.Z is set by the developers. Marketing can jump the numbers to a .oh (ex: 5.0) whenever they deem so,
but behind the scenes, development still has
control of the versioning. The only trick is
that you have to make sure the marketing people
can add using positive increments.
No way.
The perl script just needs some debugging.
It's possibly the same issue.
A traceroute:
traceroute to x.x.x.x (x.x.x.x), 30 hops max, 40 byte packets
1 main2-main1-eth.sjc1.above.net (207.126.96.190) 0.504 ms 1.328 ms 0.424 ms
2 core5-main2-oc12.sjc1.above.net (209.133.31.189) 0.497 ms 0.568 ms 0.460 ms
3 core3-sjc1-oc48.sjc2.above.net (208.184.102.206) 0.586 ms 0.606 ms 0.506 ms
4 iad1-sjc2-oc48.iad1.above.net (216.200.127.25) 68.858 ms 71.203 ms 71.400 ms
5 core3-core1-oc48.iad1.above.net (209.249.203.33) 69.143 ms 68.918 ms 68.825 ms
6 att-iad.iad.above.net (216.200.254.98) 70.522 ms 70.692 ms 71.711 ms
7 gbr2-p50.wswdc.ip.att.net (12.123.8.225) 70.374 ms 69.960 ms 70.624 ms
8 ar1-p310.wshdc.ip.att.net (12.123.194.1) 71.107 ms 70.753 ms 71.323 ms
[snipped the rest]
A Universal equation that applies to any group, not just internet related.
Why do you feel that the disk is failing?
You seem upset that the LAN is slow. Please explain.
Why do you not like parity errors. Tell me more.
Why do you feel better when the cpu is less busy?
You seem bothered that processes keep failing.
Please explain why you are upset about this.
If you want to really know how it works.
http://www-db.stanford.edu/~backrub/google.html
Note: the document was written in 1998.
two snipets:
6.3 Scalable Architecture
Aside from the quality of search, Google is designed to scale. It must be efficient in both space and time, and constant factors are very important when dealing with the entire Web. In implementing Google, we have seen bottlenecks in CPU, memory access, memory capacity, disk seeks, disk throughput, disk capacity, and network IO. Google has evolved to overcome a number of these bottlenecks during various operations. Google's major data structures make efficient use of available storage space. Furthermore, the crawling, indexing, and sorting operations are efficient enough to be able to build an index of a substantial portion of the web -- 24 million pages, in less than one week. We expect to be able to build an index of 100 million pages in less than a month.
9.1 Scalability of Google
We have designed Google to be scalable in the near term to a goal of 100 million web pages. We have just received disk and machines to handle roughly that amount. All of the time consuming parts of the system are parallelize and roughly linear time. These include things like the crawlers, indexers, and sorters. We also think that most of the data structures will deal gracefully with the expansion. However, at 100 million web pages we will be very close up against all sorts of operating system limits in the common operating systems (currently we run on both Solaris and Linux). These include things like addressable memory, number of open file descriptors, network sockets and bandwidth, and many others. We believe expanding to a lot more than 100 million pages would greatly increase the complexity of our system.
A 64 bit time_t has been discussed for some time now (esp in csy2k). It does not require a 64 bit processor to implement either.
As to changing it to be in milliseconds, that would be a problem as you are then changing the *interpretation* of the time_t, which could require inspection of the code which is much
more work than a re-compile.
Of course a 64 bit time_t will result in extra work if it is stored in a file or database as a 64 bit field/column.