Yeah? So does this mean you think Linux is POSIX compliant?
For the most part? Yes. It's not fully POSIX compliant, but close enough. Patches exist in the wild that make it 100% POSIX. It's actually been a pretty big thing to the Linux community to reach a compliant state.
If so, then maybe you should spend more time coding than posting drivel on./
I'm sorry, is your point that SO_[SND|RCV]BUF wasn't in 2.4? Or 2.2? Because (as we can see from this pretty manpage for Linux 2.0) it was. So there's no reason to get all upset over things. You thought one thing, it's actually another way. Such is life.
Indeed. That's why I found a better calculator. (Yes, I'm still being lazy.;-))
The center of the thermosphere can get as hot as 2,000C
Which only makes the problem worse in the other direction. 2,000C in "air" would produce a speed of 2,138 mph. Thus the Shuttle would only be travelling ~Mach 8 as it passes through the hotter parts of the thermosphere.
but where the shuttle is, it will probably just be a few hundred degrees kelvin on average (depending on solar conditions).
At 200K, the calculator gives a result of ~634 mph. Of course, one has to be cognizant of the different gasses, but that's probably not too bad as an estimation. The "Mach 25" number might be correct if the atmosphere were right around 240 Kelvins. Which it may be on occasion. But it certainly isn't stable, and the Space Shuttle orbits at a variety of altitudes. Like I said, the "Mach 25" number is just silly.:-)
But yes, representing the Shuttle's speed in relation to mach number is pretty silly;) I prefer good 'ol km/s.
Long answer: Mach is simply a multiple of the speed of sound. As a result it changes with altitude and atmospheric conditions. NASA has a nice calculator for divining the approximate value for Mach at a given altitude.
I thought about mentionting that it's a near vaccuum, but I figured it was pretty much irrelevant to my point. The Space Shuttle orbits with an approximate velocity of 17,321 mph. (Relative the the Earth, of course.) For that to be Mach 25, the Space Shuttle's altitude would have to be about 25,000 feet! Yet the Shuttle orbits at an altitude of over 100 miles (>528,000 feet). The highest my calculator goes is 250,000 feet. At that altitude, the speed of sound is only 602 mph, making the Shuttle's velocity Mach 28. Now I'm far too lazy to whip out the mathematical models to determine how fast sound travels at 100 miles and up, but it's a guarantee that it's far, far lower than the 692ish mph that's used to calculate Mach 25.
Or in other words, using Mach to determine the Shuttle's velocity (rather than engineering design) is nonsensicle.:-)
The Linux kernel automatically doubles the buffer for its own use. In the article:
Within the Linux 2.6 kernel, the window size for the send buffer is taken as defined by the user in the call, but the receive buffer is doubled automatically. You can verify the size of each buffer using the getsockopt call.
Linux assumes that half of the send/receive buffer is used for internal kernel structures; thus the sysctls are twice what can be observed on the wire.
The article could have better explained that in context. For the most part it's automatic though, so don't worry about it.
Because most of us know more than you think you do?;-)
What should an article about an API designed in 1983 in a language dating back to 1972 supposed to look like?
Old.
Barring that, defintitely not "News for Nerds" or "Stuff that Matters".
And I doubt the poster actually read it considering it describes features specific to Linux 2.6 (e.g. I don't think 2.4 actually supported setting SO_{SND,RCV}BUF).
You do realize that SO_SNDBUF and SO_RCVBUF are part of the POSIX standard, don't you? They've been in Linux for as long as I can remember. At least as long as the 2.x kernels have been in production. The socket man page tells you what new features were added during development:
VERSIONS
SO_BINDTODEVICE was introduced in Linux 2.0.30. SO_PASSCRED is new in Linux 2.2. The sysctls are new in Linux 2.2. SO_RCVTIMEO and SO_SNDTIMEO are supported since Linux 2.3.41. Earlier, timeouts were fixed to a protocol specific setting, and could not be read or written.
And wonders upon wonders, it even tells you about the buffer doubling!
NOTES
Linux assumes that half of the send/receive buffer is used for internal kernel structures; thus the sysctls are twice what can be observed on the wire.
Who'd have thunk that you could check the online documentation to get such amazing info?!
Yes, I'm being horribly sarcastic. I probably shouldn't be, so I apologize in advance. But I stand by my contention that there's nothing about this article that makes it news worthy. Especially not as a front page story.
I only need one TV tuner. Just set it to SciFi on Friday and hit record. Go to bed, and you should have all the TV that's currently worth watching the next day. Of course, if I could get BBC(3?), I'd need another tuner for the good Doctor.
Actually, given that it's 2006, I would have thought that the socket layer would be smart enough to perform these sorts of "optimizations" for you automatically
To a certain degree, they are optimized. Since most network activity occurs through a higher level networking API (e.g. HTTP), the network performance is already optimized by the library. It's not all that often that you have to open a direct socket unless you happen to be writing such a library or server.
Which just further points out how much this article is NOT news and DOESN'T matter.:-)
One of the great things about computers is they allow different implementations of the same idea. Because of this, someone who knows how to tune the networking on one OS may not know how to on Linux.
Now if only the article actually covered something specific to Linux, I'd agree with you. About the most useful thing it does is tell you the location of the same parameters that you muck with on every other system in existence. This info has only been around for Linux for, oh, more than a decade. Pick up any book or tutorial on TCP/IP for the same info.
Do you also complain when the weather report comes on the local news, because you've seen a weather report before?
No more than I complain that I just ate dinner yesterday. But I do tend to get annoyed when TV Networks show reruns of my favorite TV shows in slots that they're supposed to be showing new episodes! (Star Trek: Enterprise was probably the worst at this. You never know when they were actually going to show something new. I didn't even consider it "one of my favorite TV Shows," and it was still annoying.)
Sure it did. Consumers just never saw it. You see, Sun enticed Microsoft into selling them exclusive rights to produce Windows NT for the SPARC architecture. Given how popular SPARC was, Microsoft thought they'd won a major victory and signed the contract. Sun then sat on their exclusive rights and laughed at Microsoft for the rest of the 90's.
I'm assuming that you meant that when you said a Sun box.
I'm not sure that's a fair assumption. Sun has produced various Intel/AMD boxes throughout it history, including:
* SunPCI (a complete PC inside your Sun) * Cobalt (x86 webservers) * Java Workstations (AMD Opertron Machines that are Windows certified)
Though I do agree that he was probably referring to the Digital Alpha machines. Either that or he ran Internet Explorer and Outlook on his Sun box and thought it was "great". (*shudder*)
This reads like an article from the 90's. This being 2006 and all, I would hope that programmers know how to make effective use of TCP/IP sockets. I wonder if maybe they just yanked an article from 1995 and did a search/replace on s/Windows/GNU Linux/g.
You know, I just realized that you're looking at a different event. This article is the one where AT&T "explains" the problem of the '98 outage. If the Wayback machine ever comes back online, you should be able to find the official statement http://www.att.com/press/0498/980414.bsa.html">her e.
To which two articles are you referring? The one I posted was in 1998 (a few months before I began working with AT&T). If you're referring to the Wired article, that was a gaffe with Sprint. Hardly the same event as "The Day the World Disappeared." (The nickname many people gave to the AT&T outage.)
As I said, the scuttlebutt claimed it was actually a backhoe.
I imagine that the reality was probably more complex. i.e. A severing of a connection could have started the cascading failure. Or it could have been one big cooincidence. But internally, the blame was placed squarely on a backhoe.:-)
Anyone remember back in the late 90's when AT&T lost its ENTIRE frame-relay network? Some 6,000 or so customers suddenly lost network connectivity?
According to the scuttlebutt around AT&T a piece of construction machinery backed into some sort of switching station and took the whole thing out. 6,000 customers, just like *that*. Try beating that one.
Apple has, at the very least, shown it's operating system to be more flexible (or morphable) than Microsoft's Windows.
Apple has always kept the Intel jump as an Ace card in its back pocket. Rhapsody was developed for both Intel and PowerPC, and Apple kept Darwin x86 up to date. For many of us, the only surprise was that Apple actually made the jump, not that they could do it.
It changed within the last few years. Apple used to cream Intel chips on battery life, regularly producing laptops that could run for up to four hours. Intel laptops, OTOH, were quickly dwindling in battery life all the way down to 2 hours or less.
Intel noted this issue and produced the Pentium M processor (part of their whole "Centrino" push), which significantly reduced processor power usage on mobile computers. In the meantime, Apple was unable to convince IBM to produce low power G5's as they had gotten Motorola to do in the past. Apple was thus stuck with older processor technology for its laptops.
Season 4 was defintiely "better", but not "OH WOW!" better. Better as in, "Gee, maybe they should have tried this in the first season?" By Season 4 of TNG, the show had already written television history with some of the best Sci-Fi ever aired. (Best of Both Worlds, anyone?) Even DS9 and Voyager had managed to find grooves at that point. But Enterprise? It was just barely getting started.
Even then, the better scripts couldn't make up for the bad acting, bad plot, and bad continuity. B&B tried to make a Star Trek that wasn't Star Trek (because they wanted to do something "different", but were too lazy to make their own show) and we the fans paid for it.
Yeah, I hear [Star Trek: Enterprise] was a good show.
You're being sarcastic, right? Please tell me you're being sarcastic. The only good part about it was the First TV Drama website. Too bad he started slacking.
Oh, and the last episode sucked. Someone tell me again why Trip had to die a senseless death?
They're doing it all wrong. What they need is commitment from the advertisers to support a new show. To get commitment from the advertisers, they need commitment from the fans to watch the show in the given time slot. To get commitment from the fans, they need to ink a deal with Fox that would guarantee a non-preemtable timeslot so that fans can make their decision. To sweeten the pot for advertisers, they might even set something up so that the fans will receive a mailing or two from the advertisers.
Basically, you need to make the network and advertisers smell money. There's no way you'll get that much money out of the fans directly, but you can certainly do it via the advertisers.
Slashdot Mirror
Yeah? So does this mean you think Linux is POSIX compliant?
./
For the most part? Yes. It's not fully POSIX compliant, but close enough. Patches exist in the wild that make it 100% POSIX. It's actually been a pretty big thing to the Linux community to reach a compliant state.
If so, then maybe you should spend more time coding than posting drivel on
I'm sorry, is your point that SO_[SND|RCV]BUF wasn't in 2.4? Or 2.2? Because (as we can see from this pretty manpage for Linux 2.0) it was. So there's no reason to get all upset over things. You thought one thing, it's actually another way. Such is life.
That calculator is intended for airplanes.
;-))
:-)
;) I prefer good 'ol km/s.
:-D
Indeed. That's why I found a better calculator. (Yes, I'm still being lazy.
The center of the thermosphere can get as hot as 2,000C
Which only makes the problem worse in the other direction. 2,000C in "air" would produce a speed of 2,138 mph. Thus the Shuttle would only be travelling ~Mach 8 as it passes through the hotter parts of the thermosphere.
but where the shuttle is, it will probably just be a few hundred degrees kelvin on average (depending on solar conditions).
At 200K, the calculator gives a result of ~634 mph. Of course, one has to be cognizant of the different gasses, but that's probably not too bad as an estimation. The "Mach 25" number might be correct if the atmosphere were right around 240 Kelvins. Which it may be on occasion. But it certainly isn't stable, and the Space Shuttle orbits at a variety of altitudes. Like I said, the "Mach 25" number is just silly.
But yes, representing the Shuttle's speed in relation to mach number is pretty silly
Glad we agree.
Short answer: No.
Long answer: Mach is simply a multiple of the speed of sound. As a result it changes with altitude and atmospheric conditions. NASA has a nice calculator for divining the approximate value for Mach at a given altitude.
LEO's hardly a vaccuum.
:-)
I thought about mentionting that it's a near vaccuum, but I figured it was pretty much irrelevant to my point. The Space Shuttle orbits with an approximate velocity of 17,321 mph. (Relative the the Earth, of course.) For that to be Mach 25, the Space Shuttle's altitude would have to be about 25,000 feet! Yet the Shuttle orbits at an altitude of over 100 miles (>528,000 feet). The highest my calculator goes is 250,000 feet. At that altitude, the speed of sound is only 602 mph, making the Shuttle's velocity Mach 28. Now I'm far too lazy to whip out the mathematical models to determine how fast sound travels at 100 miles and up, but it's a guarantee that it's far, far lower than the 692ish mph that's used to calculate Mach 25.
Or in other words, using Mach to determine the Shuttle's velocity (rather than engineering design) is nonsensicle.
You forgot one: The Space Shuttle travels at Mach 25. In orbit. In a vacuum. With, like, no air. No sound. No speed of sound to multiply by. Mach 25.
Would someone like to explain that one to me?
From the MAN page:
The article could have better explained that in context. For the most part it's automatic though, so don't worry about it.
Because most of us know more than you think you do?
What should an article about an API designed in 1983 in a language dating back to 1972 supposed to look like?
Old.
Barring that, defintitely not "News for Nerds" or "Stuff that Matters".
And I doubt the poster actually read it considering it describes features specific to Linux 2.6 (e.g. I don't think 2.4 actually supported setting SO_{SND,RCV}BUF).
You do realize that SO_SNDBUF and SO_RCVBUF are part of the POSIX standard, don't you? They've been in Linux for as long as I can remember. At least as long as the 2.x kernels have been in production. The socket man page tells you what new features were added during development:
And wonders upon wonders, it even tells you about the buffer doubling!
Who'd have thunk that you could check the online documentation to get such amazing info?!
Yes, I'm being horribly sarcastic. I probably shouldn't be, so I apologize in advance. But I stand by my contention that there's nothing about this article that makes it news worthy. Especially not as a front page story.
I only need one TV tuner. Just set it to SciFi on Friday and hit record. Go to bed, and you should have all the TV that's currently worth watching the next day. Of course, if I could get BBC(3?), I'd need another tuner for the good Doctor.
I'd guess that it is, in fact, one of the hottest PVRs ever built!
Not to mention over 1TB of recorded shows, and STILL nothing to watch!
Actually, given that it's 2006, I would have thought that the socket layer would be smart enough to perform these sorts of "optimizations" for you automatically
:-)
To a certain degree, they are optimized. Since most network activity occurs through a higher level networking API (e.g. HTTP), the network performance is already optimized by the library. It's not all that often that you have to open a direct socket unless you happen to be writing such a library or server.
Which just further points out how much this article is NOT news and DOESN'T matter.
One of the great things about computers is they allow different implementations of the same idea. Because of this, someone who knows how to tune the networking on one OS may not know how to on Linux.
Now if only the article actually covered something specific to Linux, I'd agree with you. About the most useful thing it does is tell you the location of the same parameters that you muck with on every other system in existence. This info has only been around for Linux for, oh, more than a decade. Pick up any book or tutorial on TCP/IP for the same info.
Do you also complain when the weather report comes on the local news, because you've seen a weather report before?
No more than I complain that I just ate dinner yesterday. But I do tend to get annoyed when TV Networks show reruns of my favorite TV shows in slots that they're supposed to be showing new episodes! (Star Trek: Enterprise was probably the worst at this. You never know when they were actually going to show something new. I didn't even consider it "one of my favorite TV Shows," and it was still annoying.)
NT never ran on SPARC boxes
Sure it did. Consumers just never saw it. You see, Sun enticed Microsoft into selling them exclusive rights to produce Windows NT for the SPARC architecture. Given how popular SPARC was, Microsoft thought they'd won a major victory and signed the contract. Sun then sat on their exclusive rights and laughed at Microsoft for the rest of the 90's.
I'm assuming that you meant that when you said a Sun box.
I'm not sure that's a fair assumption. Sun has produced various Intel/AMD boxes throughout it history, including:
* SunPCI (a complete PC inside your Sun)
* Cobalt (x86 webservers)
* Java Workstations (AMD Opertron Machines that are Windows certified)
Though I do agree that he was probably referring to the Digital Alpha machines. Either that or he ran Internet Explorer and Outlook on his Sun box and thought it was "great". (*shudder*)
This reads like an article from the 90's. This being 2006 and all, I would hope that programmers know how to make effective use of TCP/IP sockets. I wonder if maybe they just yanked an article from 1995 and did a search/replace on s/Windows/GNU Linux/g.
Slashdot auto-screws that second link. Here it is in plain text:
r ess/0498/980414.bsa.html
http://web.archive.org/web/*/http://www.att.com/p
You know, I just realized that you're looking at a different event. This article is the one where AT&T "explains" the problem of the '98 outage. If the Wayback machine ever comes back online, you should be able to find the official statement http://www.att.com/press/0498/980414.bsa.html">her e.
To which two articles are you referring? The one I posted was in 1998 (a few months before I began working with AT&T). If you're referring to the Wired article, that was a gaffe with Sprint. Hardly the same event as "The Day the World Disappeared." (The nickname many people gave to the AT&T outage.)
As I said, the scuttlebutt claimed it was actually a backhoe.
:-)
I imagine that the reality was probably more complex. i.e. A severing of a connection could have started the cascading failure. Or it could have been one big cooincidence. But internally, the blame was placed squarely on a backhoe.
A whole building? Pff. That's nothing.
Anyone remember back in the late 90's when AT&T lost its ENTIRE frame-relay network? Some 6,000 or so customers suddenly lost network connectivity?
According to the scuttlebutt around AT&T a piece of construction machinery backed into some sort of switching station and took the whole thing out. 6,000 customers, just like *that*. Try beating that one.
Apple has, at the very least, shown it's operating system to be more flexible (or morphable) than Microsoft's Windows.
Apple has always kept the Intel jump as an Ace card in its back pocket. Rhapsody was developed for both Intel and PowerPC, and Apple kept Darwin x86 up to date. For many of us, the only surprise was that Apple actually made the jump, not that they could do it.
Canada isn't part of North America? Could've fooled me.
:-P
I should know! I'm Canadian!
Well that explains everything, eh?
It changed within the last few years. Apple used to cream Intel chips on battery life, regularly producing laptops that could run for up to four hours. Intel laptops, OTOH, were quickly dwindling in battery life all the way down to 2 hours or less.
Intel noted this issue and produced the Pentium M processor (part of their whole "Centrino" push), which significantly reduced processor power usage on mobile computers. In the meantime, Apple was unable to convince IBM to produce low power G5's as they had gotten Motorola to do in the past. Apple was thus stuck with older processor technology for its laptops.
Does that help explain things?
You give her too much credit.
Well, no accounting for poor taste. :-P
Season 4 was defintiely "better", but not "OH WOW!" better. Better as in, "Gee, maybe they should have tried this in the first season?" By Season 4 of TNG, the show had already written television history with some of the best Sci-Fi ever aired. (Best of Both Worlds, anyone?) Even DS9 and Voyager had managed to find grooves at that point. But Enterprise? It was just barely getting started.
Even then, the better scripts couldn't make up for the bad acting, bad plot, and bad continuity. B&B tried to make a Star Trek that wasn't Star Trek (because they wanted to do something "different", but were too lazy to make their own show) and we the fans paid for it.
Worst. Hour. Of. Television.
Ever.
Yeah, I hear [Star Trek: Enterprise] was a good show.
You're being sarcastic, right? Please tell me you're being sarcastic. The only good part about it was the First TV Drama website. Too bad he started slacking.
Oh, and the last episode sucked. Someone tell me again why Trip had to die a senseless death?
They're doing it all wrong. What they need is commitment from the advertisers to support a new show. To get commitment from the advertisers, they need commitment from the fans to watch the show in the given time slot. To get commitment from the fans, they need to ink a deal with Fox that would guarantee a non-preemtable timeslot so that fans can make their decision. To sweeten the pot for advertisers, they might even set something up so that the fans will receive a mailing or two from the advertisers.
Basically, you need to make the network and advertisers smell money. There's no way you'll get that much money out of the fans directly, but you can certainly do it via the advertisers.