Holy crap, I can hardly believe this topic. Who in their right mind would want FM opinion on anything? This is really puzzling to me.
There's a saying that applies: Know your enemy.
I doubt anyone will be fooled into thinking his arguments are unbiased, or correct, and adopt the mindset he's pushing. (If nothing else, there will be PLENTY of warnings from posters in the discussions. B-) ) So this is a chance to do a little research: Find out what arguments are being brought into court and congressional cloakrooms by those opposed to innovation and competition from outside of established corporate monoliths, so we can get ready with counter arguments.
As an independent software developer, how can I avoid getting dragged into a patent lawsuit? How can I leverage my rights to ensure others aren't exploiting my patents?
You can't.
A patent is just a license to sue.
It licenses others to sue you if they think you might be infringing their stuff (or they can get you to pay them to go away even if you aren't). It licenses you to sue others who are infringing your patents. That's all it is.
If you want protection for your creations, you have to be ready to put on the armor and walk into the arena to defend them.
I'm pretty sure that Battlefield is a UDP not TCP protocol so does UDP have the 'intelligence' to discard duplicate packets?
No it doesn't. UDP is just minimalist port-number-multiplexed, checksummed, access to the underlying IP protocol. It delivers the packets as they arrive, with no sorting out at all. (The underlying IP layer handles fragmentation and reassembly, but that's about it.)
That is why the SERVER and CLIENT that USE UDP have to, themselves, handle the dropping, reordering, and duplication of packets.
I don't know if there's something already available and free, so here's how I'd build it.
It'd startt with OpenVPN. (Mosly because it's the only hackable VPN I'm familiar with that's currently supported.)
I'd first take advantage of the fact that servers and clients are SUPPOSED to be able to handle duplicated and reordered packets and do it the simple way: Just hack it to throw each packet down both pipes, and at the receiving end just forward both copies.
Then, if the server and/or the client DON'T handle the duplication gracefully, I'd add sequence numbering to the VPN wrapping (if it isn't there already) and a mechanism at the receiving end to keep a small amount of history of what has gone out and drop the slower copy (if it arrives before the history of its other copy has timed out).
Data structure might be a small tree or heap of ranges-of-packets-that-have-left (pruned to drop older stuff when getting too nodefull or near sequence-number-wrap-around due to good packet weather), or maybe a rotation of three hash tables - "now", "recent", and "being cleared / cleared and waiting for rotation" - with the first two in use.
I find it hard to imagine that it would (at least routinely) be faster than using his current wireless setup to route his traffic from his desktop... through his cable modem... through his ISP... through a remote datacenter (somewhere)... to the Battlefield servers
I have no problem at all believing that. The OP says he is using two MOBILE access devices from two (wireless) carriers and is (if I read him right) experiencing substantial intermittent (but separate) delay and/or drop events in both of them. If he throws each packet down both of them and the first one to arrive at the data center gets to the game server, the packets that are lost or delayed on BOTH paths will be very much rarer and his gaming experience will be substantially improved.
Yes, he'll get a little extra latency on the fast packets - which is most of them. But server farms generally have fat and blazingly fast backbone connections, so it shouldn't be a lot added. A small price to pay to make almost ALL packets arrive reasonably quickly and almost NONE experience big delays or loss.
Absolutely not. Nor does it expect that to usually happen. The routes in opposite directions are often different. (For starters, they're based on the local knowledge of the routers at opposite ends of the path, which are typically familiar with their neighborhood and may have no clue about what things are like near the other end.)
The routes of diffetrent packets in the same direction are often different, too (like for load-balancing by throwing alternate packets down two slower links to get an effectively faster link). Every packet is potentially routed differently (though routing protocols like label switchingmay often set up connection-like shortcuts that make consecitve packets take the same path - to speed things up).
What matters is just that they get to the same ENDPOINT. Some may be silently lost. Some may be duplicated. Some may arrive out of order (like when a route changes and later packets get there faster).
It's been like this since IP, UDP, and TCP were invented. It was a core principle of their invention.
= = = =
Having said that:
Deviation (other than packet drops) from simple first-in-first-out packet flow tend to be rare. So not all servers and/or clients handle them well. (TCP will sort out missing and misordered packets on the receiving end - sometimes at substantial cost in buffering and latency. UDP will not - for simplicity, speed, and for when occasional lost packets are less of a problem than high latency and occasional long delays. So if the server and/or client can't handle transmission problems well, performance may suffer or functionality simply fail.)
Many networking company customers of high-speed router makers make the additional requirement that a stream of packets coming in one particluar interface from one particular source and going out another particular interface to a particular destination are not reordered. That's a pain when the router's guts are a sea of little processors each handling packets individually, so additional special purpose hardware may be added to track packet order and insure things don't get reordered between input and output queues.
The situation in the American South is totally different though, right?
Nice rhetorical scoring, but, yes, it *is* totally different. Comparing the poverty, lack of trust in government workers and dysfunctional healthcare system in the US South to those factors in Africa is like comparing the neighborhood pool to Lake Erie.
How about the situation at the US southern border for illegal immigrants?
The US takes them into custody. It puts them in crowded rooms - standing room only - for hours to days, with lots of others recently apprehended or who turned themselves in, and inadequate sanitary facilities (and inadequate instruction for those who don't know how to use the ones that ARE there). That looks to me like an ideal way to insure that if ONE of them has Ebola, dozens or hundreds will be exposed.
Then, after carefully NOT taking any information like fingerprints (which might be used to identify and collect them later), it busses them (in crowded vehicles) all over the country and resettles them - typically with alleged "family" who often living in crowded conditions and with incentives to avoid authorities - especially any that come looking for them.
[Hospital sent home the ebola patient in Dallas, though he had classic ebola symptoms and had traveled to Liberia.]
Yep, especially when they deny all of the screening questions.. That's helpful.
He denied the screening questions at the airport. ('Let's see. If I answer yes you won't let me fly and will throw me in with everybody else who answered yes. Of COURSE I didn't have contact with Ebola!)
He DIDN'T deny the questions at the hospital. They knew he'd been to Liberia recently. But their bureaucracy didn't get that info to the person who made the release decision.
an educated population is one of the best defenses against mindless wars. That's why it's so important to the corrupt governments that want to wage those wars to have control of the education systems in their societies.
Because MISeducating their population is key. "Give them a light, and they'll follow it anywhere."
But this needs another caveat: If the population in general doesn't have any effective power over the goverenment, they can know exactly what's going on, be against it, but be utterly unable to change it. If some of them attempt to make such change, it just separates them out from those who will knuckle under, for easy removal from the herd.
No. Current solar absorption (accounting for albedo) is on the order of 50PW. By comparison, current peak world wide energy production is a paltry few TW. We're several orders of magnitude away from the point where our civilization's thermal output becomes a concern.
Not to mention that we woudl stop putting carbon dioxide from energy production into the atmosphere (and could, if it became an issue, use some of that fusion power to freeze some of it OUT of the atmosphere and do things like turn it back into coal and bury it.)
If human industry generated CO2's contribution to the greenhouse effect IS significant, we could pull that "gift that keeps on giving captured solar heat" back out of the air and put it into the bottle - at least until we reach pre-industrial levels. (Beyond that we probably don't want to go, because of the detrimental effect of low CO2 levels on plants.)
In the atmosphere there's a situation: The weather all happens down near the surface, in a region called the troposphere. Here the density/temperature gradients can result in instabilities, where a parcel of air that is, say, lighter than its sourroundings can become MORE ligher-than-its surroundings as it moves up (and vice-versa). Above that is another (set of) layer(s) called the "stratosphere", where everything is most stable right where it is. Nothing very exciting happens there except when something coming up REALLY fast from below coasts up a bit before it stabilizes and moves back down.
The oceans do something similar, but upside down:
Water has an interesting property: Like most materials it gets more dense as it gtss colder - but only up to a point. As it approaches freezing the molecules start hanging out in larger groups, working their way toward being ice crystals. The hydrogens on one molecule attract the oxygens on another, and because of the angle between the hydrogens bondended to the oxygen in each molecule, the complexes are somewhat LESS dense than liquid. As a result, with progressively lower temperatures the density reaches a maximum, then the water begins to expand again. When it actually freezes it is so much less dense than near-freezing liquid that the ice floats. With fresh water the maximum density happens about 4 degrees C. Salt disrupts the crystalization somewhat so the maximum density is a tad cooler (and varies a bit with salt concentration - and thus depth), but the behavior is similar.
The result is that, when you have a mix of cooler and hotter blobs of fresh water, the water closer to 4 degrees sinks and that farther from it rises. The result is that, absent a heat or impurity source below, the bottom (and much of the volume) of a deep lake tends to be stable, stratified, water at about 4 degrees year around, while all the deviations from it and "weather" activity is in no more than about the top 300 feet: Wave action, ice, hot and cold currents, etc. are all above the reasonably abrupt "thermocline" boundary. Below that things are very slow, driven mostly by things like volcanic heat. (Diffusion is REALLY slow in calm water. It takes decades for, say, dissolved impurities to move a couple inches.)
The ocean is much like that, too, but a little cooler and with some temperature ramps spreading out the thermocline due to variations in salt concentration.
So global warming/cooling/weather, whatever would NOT be expected to affect deep water temperatures. This would all be happening in the top few hundred feet. If, say, the ocean were heating up without the surface water temperature changing, this would take the form of the thermocline gradually lowering near the equator and/or rising near the poles, rather than the deep water becoming warmer.
Shouldn't the oceans fall under the NOAA's domain?
NASA has a mandate to figure out what's with a variety of planets throughout the universe. They only have a few samples nearby, and this is the only one they can measure REALLY thoroughly, to test and refine their models and theories.
They also have the technology to do measurements from space. AND they work closely with NOAA (including launching and operating observation satellites for them).
I posted: There are many jobs in TEM if you hold an H1B (and are willing to work for less than it would cost for someone with .
I meant to post: There are many jobs in TEM if you hold an H1B (and are willing to work for less than it would cost for someone with the same qualifications who is native-born.)
(The keybord and trackpad on this recent LeNovo z710 are driving me nuts.)
Either shorten it to TEM or mention that there are many jobs under the STEM categories, but S-cience is experiencing total glut.
There are many jobs in TEM if you hold an H1B (and are willing to work for less than it would cost for someone with . But substantially more newe H1Bs are being issued than new TEM jobs created. This means that the number of citizens in such jobs is dropping.
Last I heard about 1/3 of the citizens qualified for TEM jobs are actually so employed, and recent grads mostly need not apply.
(And then the newsies wring their hands and wonder why students - especially women - are largely uninterested in completing a Computer Science or other TEM degree.)
I'm not saying that C is 2% faster than C++ in fact C++ might be faster but if C were faster... go C for a core functionality.
But what about new functionality? Suppose it takes an extra three months to get the next new thing working in C than it would in C++. That's two million users times three months productivity lost because the feature wasn't there if you stuck with C. And then there's the feature after that, and the next one... The future gets here sooner. Some of those "features" save lives.
Not that it matters: Some teams will use C. Some will use C++. Some will use [insert other language here]. Eventually some will use whiffy-spim-bam that hasn't been invented yet. Getting to release of a working product first is a big factor in displacing the competition and becoming a dominant paradigm.
What strikes me as ludicrous is that we're having this discussion centered around a variant of unix. In case you weren't aware, operating systems USED to be written entirely in assembler, long after vritually all applications were coded entirely, or all-but-critical-stuff, in compiled languages. What made UNIX different is that it was the first major OS that was coded primarily in a compiled language:
As of System 6, which was the big source code leak from the University of New South Wales, the kernel was 10,000 lines (including a lot of added blank lines to make modules come out on 50-line boundaries for easy listing in a textbook). Of that, 8,000 lines - mostly machine independent stuff - was in C and 2,000 - mainly memory management and interrupt vectoring - was still in assembler. As time went on virtually all of the rest migrated to C.
The kernel being tiny, the bulk of it being in C, the availability of good free and/or cheap C compilers for new architectures, and some interesting intellectual property licensing policies by Bell Labs, led to UNIX being rapidly ported to new chip architectures, enabling an explosion of "unix boxes" and wide adoption of UNIX.
All during that time we had EXACTLY this same argument - with assembler taking the role of C and C taking the role of C++. And then, as now, the argument didn't matter, because C won on the merits, despite being a few percent slower than good assembler code. B-)
(Note that this was BEFORE the RISC revolution, when it was discovered that, in actual production code, assembly code, on the average, actually ran slower than compiler output - because compilers knew only MOST of the tricks but they applied them ALL THE TIME, while coders only applied them when they were paying extra attention to something perceived as critical. Want to bet that C++ is REALLY slower than C, across the bulk of production code?)
Looking at the project, I stumbled over the fact they did rewrite an ethernet driver and have rewritten it in C++ with a 2% performance overhead.
Well that makes it easy to determine whether it's worth it.
The David House variant on Moore's Law says processor power doubles every 18 months, and the real world has tracked this very closely for half a century. A 2% improvement doubles after 36 steps, and 18 months is 78 weeks. So in a few hours over 16 days, Moore's law has given you back your loss, and after that it's gravy.
So if having your code base in C++ improves your development process enough that it lets you complete and release your next upgrade (or the one after that, etc.) only a couple weeks earlier, C++ wins.
If it lets you keep gaining on your competition, it wins BIG.
For a short while, the Linux kernel could be compiled as C++. Some developers, I believe Linus included, felt that the stricter type checking offered by C++ would help kernel development. There was no attempt to actually use C++ features though.
The effort did not last long.
Once ANSII had imported C++'s strong type checking into the C standard, and compilers had implemented it, there was no need to use the C++ compiler to get strong type checking.
Since that was the only feature Linus was using, it makes sense to discard the remaining cans of worms unopened. B-)
It won't be time for C++ in the kernel until the standard defines (and the compilers implement) whether you get the base or derived class version of a virtual function if it's called during the initialization, construction, or destruction of a derived class' member variables.
It also won't be time for C++ in the kernel if they DO define it, but they define it to be anything but the base class version. The derived class version should only be called beginning with the first user-written line of the constructor and ending just after the last user-written line of the destructor.
... a good C programmer can look at a piece of C code and have a pretty good idea of the machine code being generated.... that hasn't really been true for a long time now. Modern processors and the related architecture have become so complicated that generating correct, efficient code is an extremely specialist skill...
Yes, these days he might not be able to easly determine what the generated code IS. But with C he can be pretty sure he correctly determined what it DOES - and if it does something else it's a compiler bug.
With C++ you get to override operators, functions, and pretty much everything else. You can redefine the semantics of what they actually DO in various situations. Keeping the semantics analogous when writing overridings is a convention, not something that's forced by the compiler.
Please don't say that in a hiring interview. You are unable to grasp when a copy constructor or an assignment operator is called?
It is impossible to tell, from looking at an assignment, whether it is being done by a native assignment, a copy constructor, an overridden assignment operator, etc. To determine that you must go back to the declarations of the variables to determine their type, maybe hunt through the include files to identify the type behind a typedef (and possibly which typedef is in effect given preprocessor-flag-driven conditional compilation), then (if you're dealing with a class type), studying the class definition (including walking back through and groking its base classes).
Ditto for overridable operators - which is pretty much all of them.
In C you can pretty much look at the code describing what to do and figure out what it does, only going on a snipe hunt when you hit a subroutine or macro invocation.
Do people not debug through object code any more? I've done that so many times when trying to understand a bit of cryptic C++ code or C macrology. There's no mystery possible - just look at the generated object directly if there's any doubt at all what's going on!
I learned to program back in the days when compilers would produce listings with the assembly code for each source line immediately following the source line. It was a given that the programmer would understand it and it often gave insignts into what was going on - and going wrong - in a program.
It was also good training for reverse-engineering from object to source. (I fondly recall reading a piece of a buggy SCSI driver's object code that stored zero in a variable and then tested the value, and realizing that somebody had written "if (a==0)" as "if (a=0)" by mistake.)
But I gave up on this about 1990. RISC instruction sets, with things like the delay slot after a jump, and extreme compiler optimization, made enough of a hash of the object code that determining what it was actually doing became more of a research project than an exercise in reading. Dropping back to inserting instrumentation in the code ended up being far more productive.
The C++ compiler will most certainly be less buggy than something thrown together to cover some element that C lacks.
Unfortunately, C++ includes an explicit non-standard that can inject subtle bugs. This has been present since at least 1988, and has survived at least the first two standards (after which I stopped watching, having moved on to mostly hardware design).
(I DID try to bring it to the attention of the standards committee in both cycles, but it was ignored. Bjarne, in his recent Slashdot Q&A, didn't answer my question on it, either.)
The problem relates to which overriding of a virtual function is called during the initialization of the member variables and the construction of member objects of a derived class (and the corresponding destruction of the member objects during the destructor). The standard permits the calling of the derived class' version of virtual member functions at this time, when the derived class has not initialized, or has dismantled, their underpinning.
Compilers are permitted to cause the call to go to either the base class version (IMHO correct) or the derived class version (IMHO dangerously incorrect). Calling the derived class version is bad, preventing a number of obvious constructions from working as expected, imposing limits on what programming techniques can be used safely, and displaying no warning (so the programmer has to know what not to do). Letting different compilers make different choices is horribly worse, as it makes the behavior unpredictable and compiler dependent.
C++ (especially the early versions, before it became buried in libraries and baroque constructions) came SO close to being a powerful and reliable tool for rapidly writing reliable code on large projects. But this "little bug" brought it all crashing down.
Slashdot Mirror
Holy crap, I can hardly believe this topic. Who in their right mind would want FM opinion on anything? This is really puzzling to me.
There's a saying that applies: Know your enemy.
I doubt anyone will be fooled into thinking his arguments are unbiased, or correct, and adopt the mindset he's pushing. (If nothing else, there will be PLENTY of warnings from posters in the discussions. B-) ) So this is a chance to do a little research: Find out what arguments are being brought into court and congressional cloakrooms by those opposed to innovation and competition from outside of established corporate monoliths, so we can get ready with counter arguments.
As an independent software developer, how can I avoid getting dragged into a patent lawsuit? How can I leverage my rights to ensure others aren't exploiting my patents?
You can't.
A patent is just a license to sue.
It licenses others to sue you if they think you might be infringing their stuff (or they can get you to pay them to go away even if you aren't). It licenses you to sue others who are infringing your patents. That's all it is.
If you want protection for your creations, you have to be ready to put on the armor and walk into the arena to defend them.
I'm pretty sure that Battlefield is a UDP not TCP protocol so does UDP have the 'intelligence' to discard duplicate packets?
No it doesn't. UDP is just minimalist port-number-multiplexed, checksummed, access to the underlying IP protocol. It delivers the packets as they arrive, with no sorting out at all. (The underlying IP layer handles fragmentation and reassembly, but that's about it.)
That is why the SERVER and CLIENT that USE UDP have to, themselves, handle the dropping, reordering, and duplication of packets.
Data structure might be...
Of course, with only two links, you only have to track the packets that have come in on one link but not yet on the other. That makes it even easler.
Similarly, but not quite as simply, with more than two links, with situations where you throw things down some but not all of them, etc.
This isn't possible, nor should it be.
Actually, it's almost trivial.
I don't know if there's something already available and free, so here's how I'd build it.
It'd startt with OpenVPN. (Mosly because it's the only hackable VPN I'm familiar with that's currently supported.)
I'd first take advantage of the fact that servers and clients are SUPPOSED to be able to handle duplicated and reordered packets and do it the simple way: Just hack it to throw each packet down both pipes, and at the receiving end just forward both copies.
Then, if the server and/or the client DON'T handle the duplication gracefully, I'd add sequence numbering to the VPN wrapping (if it isn't there already) and a mechanism at the receiving end to keep a small amount of history of what has gone out and drop the slower copy (if it arrives before the history of its other copy has timed out).
Data structure might be a small tree or heap of ranges-of-packets-that-have-left (pruned to drop older stuff when getting too nodefull or near sequence-number-wrap-around due to good packet weather), or maybe a rotation of three hash tables - "now", "recent", and "being cleared / cleared and waiting for rotation" - with the first two in use.
I find it hard to imagine that it would (at least routinely) be faster than using his current wireless setup to route his traffic from his desktop ... through his cable modem ... through his ISP ... through a remote datacenter (somewhere) ... to the Battlefield servers
I have no problem at all believing that. The OP says he is using two MOBILE access devices from two (wireless) carriers and is (if I read him right) experiencing substantial intermittent (but separate) delay and/or drop events in both of them. If he throws each packet down both of them and the first one to arrive at the data center gets to the game server, the packets that are lost or delayed on BOTH paths will be very much rarer and his gaming experience will be substantially improved.
Yes, he'll get a little extra latency on the fast packets - which is most of them. But server farms generally have fat and blazingly fast backbone connections, so it shouldn't be a lot added. A small price to pay to make almost ALL packets arrive reasonably quickly and almost NONE experience big delays or loss.
Doesn't TCP require it come back on the path too?
Absolutely not. Nor does it expect that to usually happen. The routes in opposite directions are often different. (For starters, they're based on the local knowledge of the routers at opposite ends of the path, which are typically familiar with their neighborhood and may have no clue about what things are like near the other end.)
The routes of diffetrent packets in the same direction are often different, too (like for load-balancing by throwing alternate packets down two slower links to get an effectively faster link). Every packet is potentially routed differently (though routing protocols like label switchingmay often set up connection-like shortcuts that make consecitve packets take the same path - to speed things up).
What matters is just that they get to the same ENDPOINT. Some may be silently lost. Some may be duplicated. Some may arrive out of order (like when a route changes and later packets get there faster).
It's been like this since IP, UDP, and TCP were invented. It was a core principle of their invention.
= = = =
Having said that:
Deviation (other than packet drops) from simple first-in-first-out packet flow tend to be rare. So not all servers and/or clients handle them well. (TCP will sort out missing and misordered packets on the receiving end - sometimes at substantial cost in buffering and latency. UDP will not - for simplicity, speed, and for when occasional lost packets are less of a problem than high latency and occasional long delays. So if the server and/or client can't handle transmission problems well, performance may suffer or functionality simply fail.)
Many networking company customers of high-speed router makers make the additional requirement that a stream of packets coming in one particluar interface from one particular source and going out another particular interface to a particular destination are not reordered. That's a pain when the router's guts are a sea of little processors each handling packets individually, so additional special purpose hardware may be added to track packet order and insure things don't get reordered between input and output queues.
The situation in the American South is totally different though, right?
Nice rhetorical scoring, but, yes, it *is* totally different. Comparing the poverty, lack of trust in government workers and dysfunctional healthcare system in the US South to those factors in Africa is like comparing the neighborhood pool to Lake Erie.
How about the situation at the US southern border for illegal immigrants?
The US takes them into custody. It puts them in crowded rooms - standing room only - for hours to days, with lots of others recently apprehended or who turned themselves in, and inadequate sanitary facilities (and inadequate instruction for those who don't know how to use the ones that ARE there). That looks to me like an ideal way to insure that if ONE of them has Ebola, dozens or hundreds will be exposed.
Then, after carefully NOT taking any information like fingerprints (which might be used to identify and collect them later), it busses them (in crowded vehicles) all over the country and resettles them - typically with alleged "family" who often living in crowded conditions and with incentives to avoid authorities - especially any that come looking for them.
[Hospital sent home the ebola patient in Dallas, though he had classic ebola symptoms and had traveled to Liberia.]
Yep, especially when they deny all of the screening questions.. That's helpful.
He denied the screening questions at the airport. ('Let's see. If I answer yes you won't let me fly and will throw me in with everybody else who answered yes. Of COURSE I didn't have contact with Ebola!)
He DIDN'T deny the questions at the hospital. They knew he'd been to Liberia recently. But their bureaucracy didn't get that info to the person who made the release decision.
an educated population is one of the best defenses against mindless wars. That's why it's so important to the corrupt governments that want to wage those wars to have control of the education systems in their societies.
Because MISeducating their population is key. "Give them a light, and they'll follow it anywhere."
But this needs another caveat: If the population in general doesn't have any effective power over the goverenment, they can know exactly what's going on, be against it, but be utterly unable to change it. If some of them attempt to make such change, it just separates them out from those who will knuckle under, for easy removal from the herd.
This article led me to check what was up with the Navy's work on the Polywell concept, long kept under their hats. I discovered:
The navy just published their results last Sunday!
I haven't time to look into it for the next few hours, but this may be very interesting news on the "are we there yet?" front.
No. Current solar absorption (accounting for albedo) is on the order of 50PW. By comparison, current peak world wide energy production is a paltry few TW. We're several orders of magnitude away from the point where our civilization's thermal output becomes a concern.
Not to mention that we woudl stop putting carbon dioxide from energy production into the atmosphere (and could, if it became an issue, use some of that fusion power to freeze some of it OUT of the atmosphere and do things like turn it back into coal and bury it.)
If human industry generated CO2's contribution to the greenhouse effect IS significant, we could pull that "gift that keeps on giving captured solar heat" back out of the air and put it into the bottle - at least until we reach pre-industrial levels. (Beyond that we probably don't want to go, because of the detrimental effect of low CO2 levels on plants.)
In the atmosphere there's a situation: The weather all happens down near the surface, in a region called the troposphere. Here the density/temperature gradients can result in instabilities, where a parcel of air that is, say, lighter than its sourroundings can become MORE ligher-than-its surroundings as it moves up (and vice-versa). Above that is another (set of) layer(s) called the "stratosphere", where everything is most stable right where it is. Nothing very exciting happens there except when something coming up REALLY fast from below coasts up a bit before it stabilizes and moves back down.
The oceans do something similar, but upside down:
Water has an interesting property: Like most materials it gets more dense as it gtss colder - but only up to a point. As it approaches freezing the molecules start hanging out in larger groups, working their way toward being ice crystals. The hydrogens on one molecule attract the oxygens on another, and because of the angle between the hydrogens bondended to the oxygen in each molecule, the complexes are somewhat LESS dense than liquid. As a result, with progressively lower temperatures the density reaches a maximum, then the water begins to expand again. When it actually freezes it is so much less dense than near-freezing liquid that the ice floats. With fresh water the maximum density happens about 4 degrees C. Salt disrupts the crystalization somewhat so the maximum density is a tad cooler (and varies a bit with salt concentration - and thus depth), but the behavior is similar.
The result is that, when you have a mix of cooler and hotter blobs of fresh water, the water closer to 4 degrees sinks and that farther from it rises. The result is that, absent a heat or impurity source below, the bottom (and much of the volume) of a deep lake tends to be stable, stratified, water at about 4 degrees year around, while all the deviations from it and "weather" activity is in no more than about the top 300 feet: Wave action, ice, hot and cold currents, etc. are all above the reasonably abrupt "thermocline" boundary. Below that things are very slow, driven mostly by things like volcanic heat. (Diffusion is REALLY slow in calm water. It takes decades for, say, dissolved impurities to move a couple inches.)
The ocean is much like that, too, but a little cooler and with some temperature ramps spreading out the thermocline due to variations in salt concentration.
So global warming/cooling/weather, whatever would NOT be expected to affect deep water temperatures. This would all be happening in the top few hundred feet. If, say, the ocean were heating up without the surface water temperature changing, this would take the form of the thermocline gradually lowering near the equator and/or rising near the poles, rather than the deep water becoming warmer.
Shouldn't the oceans fall under the NOAA's domain?
NASA has a mandate to figure out what's with a variety of planets throughout the universe. They only have a few samples nearby, and this is the only one they can measure REALLY thoroughly, to test and refine their models and theories.
They also have the technology to do measurements from space. AND they work closely with NOAA (including launching and operating observation satellites for them).
I posted:
There are many jobs in TEM if you hold an H1B (and are willing to work for less than it would cost for someone with .
I meant to post:
There are many jobs in TEM if you hold an H1B (and are willing to work for less than it would cost for someone with the same qualifications who is native-born.)
(The keybord and trackpad on this recent LeNovo z710 are driving me nuts.)
Either shorten it to TEM or mention that there are many jobs under the STEM categories, but S-cience is experiencing total glut.
There are many jobs in TEM if you hold an H1B (and are willing to work for less than it would cost for someone with . But substantially more newe H1Bs are being issued than new TEM jobs created. This means that the number of citizens in such jobs is dropping.
Last I heard about 1/3 of the citizens qualified for TEM jobs are actually so employed, and recent grads mostly need not apply.
(And then the newsies wring their hands and wonder why students - especially women - are largely uninterested in completing a Computer Science or other TEM degree.)
I'm not saying that C is 2% faster than C++ in fact C++ might be faster but if C were faster... go C for a core functionality.
But what about new functionality? Suppose it takes an extra three months to get the next new thing working in C than it would in C++. That's two million users times three months productivity lost because the feature wasn't there if you stuck with C. And then there's the feature after that, and the next one... The future gets here sooner. Some of those "features" save lives.
Not that it matters: Some teams will use C. Some will use C++. Some will use [insert other language here]. Eventually some will use whiffy-spim-bam that hasn't been invented yet. Getting to release of a working product first is a big factor in displacing the competition and becoming a dominant paradigm.
What strikes me as ludicrous is that we're having this discussion centered around a variant of unix. In case you weren't aware, operating systems USED to be written entirely in assembler, long after vritually all applications were coded entirely, or all-but-critical-stuff, in compiled languages. What made UNIX different is that it was the first major OS that was coded primarily in a compiled language:
As of System 6, which was the big source code leak from the University of New South Wales, the kernel was 10,000 lines (including a lot of added blank lines to make modules come out on 50-line boundaries for easy listing in a textbook). Of that, 8,000 lines - mostly machine independent stuff - was in C and 2,000 - mainly memory management and interrupt vectoring - was still in assembler. As time went on virtually all of the rest migrated to C.
The kernel being tiny, the bulk of it being in C, the availability of good free and/or cheap C compilers for new architectures, and some interesting intellectual property licensing policies by Bell Labs, led to UNIX being rapidly ported to new chip architectures, enabling an explosion of "unix boxes" and wide adoption of UNIX.
All during that time we had EXACTLY this same argument - with assembler taking the role of C and C taking the role of C++. And then, as now, the argument didn't matter, because C won on the merits, despite being a few percent slower than good assembler code. B-)
(Note that this was BEFORE the RISC revolution, when it was discovered that, in actual production code, assembly code, on the average, actually ran slower than compiler output - because compilers knew only MOST of the tricks but they applied them ALL THE TIME, while coders only applied them when they were paying extra attention to something perceived as critical. Want to bet that C++ is REALLY slower than C, across the bulk of production code?)
Looking at the project, I stumbled over the fact they did rewrite an ethernet driver and have rewritten it in C++ with a 2% performance overhead.
Well that makes it easy to determine whether it's worth it.
The David House variant on Moore's Law says processor power doubles every 18 months, and the real world has tracked this very closely for half a century. A 2% improvement doubles after 36 steps, and 18 months is 78 weeks. So in a few hours over 16 days, Moore's law has given you back your loss, and after that it's gravy.
So if having your code base in C++ improves your development process enough that it lets you complete and release your next upgrade (or the one after that, etc.) only a couple weeks earlier, C++ wins.
If it lets you keep gaining on your competition, it wins BIG.
For a short while, the Linux kernel could be compiled as C++. Some developers, I believe Linus included, felt that the stricter type checking offered by C++ would help kernel development. There was no attempt to actually use C++ features though.
The effort did not last long.
Once ANSII had imported C++'s strong type checking into the C standard, and compilers had implemented it, there was no need to use the C++ compiler to get strong type checking.
Since that was the only feature Linus was using, it makes sense to discard the remaining cans of worms unopened. B-)
It won't be time for C++ in the kernel until the standard defines (and the compilers implement) whether you get the base or derived class version of a virtual function if it's called during the initialization, construction, or destruction of a derived class' member variables.
It also won't be time for C++ in the kernel if they DO define it, but they define it to be anything but the base class version. The derived class version should only be called beginning with the first user-written line of the constructor and ending just after the last user-written line of the destructor.
Yes, these days he might not be able to easly determine what the generated code IS. But with C he can be pretty sure he correctly determined what it DOES - and if it does something else it's a compiler bug.
With C++ you get to override operators, functions, and pretty much everything else. You can redefine the semantics of what they actually DO in various situations. Keeping the semantics analogous when writing overridings is a convention, not something that's forced by the compiler.
Please don't say that in a hiring interview.
You are unable to grasp when a copy constructor or an assignment operator is called?
It is impossible to tell, from looking at an assignment, whether it is being done by a native assignment, a copy constructor, an overridden assignment operator, etc. To determine that you must go back to the declarations of the variables to determine their type, maybe hunt through the include files to identify the type behind a typedef (and possibly which typedef is in effect given preprocessor-flag-driven conditional compilation), then (if you're dealing with a class type), studying the class definition (including walking back through and groking its base classes).
Ditto for overridable operators - which is pretty much all of them.
In C you can pretty much look at the code describing what to do and figure out what it does, only going on a snipe hunt when you hit a subroutine or macro invocation.
Do people not debug through object code any more? I've done that so many times when trying to understand a bit of cryptic C++ code or C macrology. There's no mystery possible - just look at the generated object directly if there's any doubt at all what's going on!
I learned to program back in the days when compilers would produce listings with the assembly code for each source line immediately following the source line. It was a given that the programmer would understand it and it often gave insignts into what was going on - and going wrong - in a program.
It was also good training for reverse-engineering from object to source. (I fondly recall reading a piece of a buggy SCSI driver's object code that stored zero in a variable and then tested the value, and realizing that somebody had written "if (a==0)" as "if (a=0)" by mistake.)
But I gave up on this about 1990. RISC instruction sets, with things like the delay slot after a jump, and extreme compiler optimization, made enough of a hash of the object code that determining what it was actually doing became more of a research project than an exercise in reading. Dropping back to inserting instrumentation in the code ended up being far more productive.
The C++ compiler will most certainly be less buggy than something thrown together to cover some element that C lacks.
Unfortunately, C++ includes an explicit non-standard that can inject subtle bugs. This has been present since at least 1988, and has survived at least the first two standards (after which I stopped watching, having moved on to mostly hardware design).
(I DID try to bring it to the attention of the standards committee in both cycles, but it was ignored. Bjarne, in his recent Slashdot Q&A, didn't answer my question on it, either.)
The problem relates to which overriding of a virtual function is called during the initialization of the member variables and the construction of member objects of a derived class (and the corresponding destruction of the member objects during the destructor). The standard permits the calling of the derived class' version of virtual member functions at this time, when the derived class has not initialized, or has dismantled, their underpinning.
Compilers are permitted to cause the call to go to either the base class version (IMHO correct) or the derived class version (IMHO dangerously incorrect). Calling the derived class version is bad, preventing a number of obvious constructions from working as expected, imposing limits on what programming techniques can be used safely, and displaying no warning (so the programmer has to know what not to do). Letting different compilers make different choices is horribly worse, as it makes the behavior unpredictable and compiler dependent.
C++ (especially the early versions, before it became buried in libraries and baroque constructions) came SO close to being a powerful and reliable tool for rapidly writing reliable code on large projects. But this "little bug" brought it all crashing down.
It can take an 80% receiver to finshed in about an hour.
Can it machine a finished receiver from a block of aluminum, even if it takes a few days?