True, but deep packet inspection will reveal whether your traffic is http or not. If nothing else, this implies you'll need to encapsulate your favorite protocol over a series of http requests, since I imagine "long" http requests might also get slowed.
Fun facts: If everyone in your neighborhood with a land line picked up the phone right now and tried to make a call, probably only 10% to 20% of them would succeed. If everyone in the average American suburb all hopped in their car and tried to get on the road to the nearest Interstate, it'd be gridlock. Traffic would move at speeds no where near the posted limits. We're surrounded by shared resources with capacity that reflects typical usage with a reasonable amount of head room for "normal" peaks, but is far from being able to support the maximum theoretical demand.
Airlines overbook because a certain %age of customers don't show up, and that %age is large enough and stable enough that it makes sense to do so. When too many people do show up for a flight, the airline pays penalties (in the form of travel vouchers and upgrades), so there's incentive to be conservative in the practice. Everyone benefits overall, though. More people get flown from point A to point B. If the airlines sell more seats on a given flight, then they can charge less per seat too.
ISPs are no different. They purchase bandwidth based on a model of "reasonable" network usage and how many subscribers they have. The major difference, though, is that it's very easy for someone to fall well outside the "reasonable" traffic usage. It's quite possible for 1% of the users to take up the majority of the network bandwidth. And I can see this being considered "unreasonable," and the ISP taking steps to make sure that the other 99% of users have a reasonable experience.
What I don't like is that ISPs can advertise something as "unlimited" or as running at a certain speed, when it clearly is limited, and the advertised speed is only a peak speed available in small doses. At least airlines are required to disclose their overbooking policy.
Re:Software Projects vs. Traditional Projects
on
Why New Systems Fail
·
· Score: 1
Completion of the new high level bridge at Zilwaukee will bring to a conclusion some 20 years of planning, designing and construction of one of the biggest and most complex projects ever undertaken by MDOT. It represents a significant engineering accomplishment.
The project has encountered problems, some of them serious and most of them related to the 1982 accident. There have been no serious injuries and no lives lost, however, and the project, including the knowledge gained from the repair process, has provided much engineering experience of value to the entire highways industry.
The bridge, when completed, will be safe, durable and efficient, ready to serve the motoring public for many years to come. It will replace an obsolete, inadequate drawbridge that has caused numerous accidents and endless traffic delays over the years. And it will easily accommodate the more than 31,000 vehicles that travel along that section of I-75 freeway every day.
One of the other big differences between bridge building and software construction is that the scope of the bridge's purpose is well defined: I want to get cars from point A to point B over some obstruction. The unknowns are generally confined to how that end is achieved, rather than the actual end that's being worked for. The Zilwaukee Bridge had well defined success criteria that were in place from the get-go.
When developing a new software project (as I'm doing right now at work), I find that if I ask N people what the exact requirements are, I get N+1 descriptions. In the end, I'm left to find the overlap and do my best to fill the fringes. It's hard to measure success when different stakeholders have different goals in mind, and agreements on said goals are often superficial.
You won't see that on a bridge. "It's supposed to be eight lanes!" "Well, it's seven traffic lanes plus a really broad shoulder. That's a total of eight lanes wide, after all." "That's not what I wanted. Make it wider!"
There are two sets of costs: non-recurring and recurring. The non-recurring costs include all of the engineering effort, R&D, putting together the production facility, etc. The recurring costs are those that you incur for each unit produced.
I find it highly unlikely that the recurring costs are more than $2.1M for the car, unless it was made of solid iridium or something. (Annual production of iridium is something like 3 tons.) I wouldn't find it surprising at all, though, if Bugatti had sunk quite a bit of R&D money into developing the tech in the Veyron, and perhaps a bit of dough on the production facility.
After the release of the car, it has been reported that while each Veyron is being sold for £840,000, the production costs of the car are approximately £5 million per vehicle. This is not the price to produce one vehicle, but rather the cost of the entire Veyron project divided by the number of vehicles produced at that time. As Bugatti, and therefore Volkswagen, are making such a loss, it has been likened by automotive journalist Jeremy Clarkson to Concorde; in that they are test-beds for advancements in technology and developed as exercises in engineering.
So far, the oldest article I've seen claiming these numbers is this one from early 2007. By the end of 2006, fewer than 50 had been produced. If we assume this number applies to the first 50, then that means the total cost to that point was a cool £250million. Yow!
Since then, though, another 150 have been produced. I highly doubt that it cost another £750million. In fact, this article points to most of the costs having been R&D costs with this quote:
The seven-speed semi-automatic gearbox took 50 engineers five years to complete while with all the research and development involved,
That's 250 man-years. If you assume each engineer costs $250K/year for labor, benefits and overhead, that's $62.5M in labor costs developing the transmission alone. Throw in all the machine work and parts and everything else, and I'm sure you easily get up to $100M development costs on the transmission alone.
People keep throwing that £5 million per car number out there, but I seriously believe it's way out of date.
According to Wikipedia, the "Gotha 229" designation refers to the chosen manufacturer for the plane, and the two designations refer to the same plane. When I saw the picture of the plane, I was immediately reminded of the box for that game. Never owned it (my computer wasn't stout enough for it), but I certainly remember seeing it.
Does it run on the iPhone or do I have to go buy proprietary hardware to run the SDK? From what my iPhone-owning (and developing) friend tells me, the SDK won't even run on his dual G5 Mac. He tried to sell it to me, and I'm like "What good is it? Jobs has decreed it obsolete."
Oxygen can be produced by passing CO2 through a zirconia electrolysis cell at 800 to 1000deg C. Twenty to thirty percent of the CO2 dissociates into oxygen and carbon monoxide.
While we focus on atmospheric carbon dioxide a lot, I'm pretty sure carbon monoxide is even worse, if only because it messes up human respiration. Now, this part sounds much more interesting:
A chemical reaction which converts CO2 into methane (CH4) was discovered in 1899. This is known as the Sabatier reaction. Along with the CO2, hydrogen is passed over a finely divided metal catalyst at an elevated temperature. Methane and water vapor are produced.
Now, it sounds like this reaction requires a net energy input, but if we get that energy from solar or wind sources, then we're still ahead of the curve by preventing new carbon from coming into the atmosphere. There will be plenty of devices that use methane as a power source for years to come. If we can use this reaction along with these carbon dioxide harvesting trees to essentially "tread water" with the existing CO2 (cycling it to methane, and then burning that to get back to CO2), rather than extracting more natural gas from the ground and burning it, that would be a lovely step forward that doesn't require everyone to invest in new appliances.
The Earth isn't a closed system, and so the Second Law doesn't even directly apply in the "big picture". We have a net energy input, and so can do things to reduce entropy (ie. lock up carbon dioxide that was released through entropy-increasing processes such as burning).
Burning hydrocarbons releases energy that was stored due to photosynthetic processes that built up more complex molecules from simpler ones. So, yes, the total amount of carbon hasn't changed, but it's gone from a higher potential energy state to a lower potential energy state.
The presence of atmospheric carbon dioxide increases the Earth's average temperature through radiative forcing. Removing carbon dioxide from the atmosphere prevents that from happening.
One way to reduce atmospheric carbon dioxide is to lock it back up in more complex molecules. That also would absorb energy and store it with the carbon dioxide. This is what plants do. Unfortunately, they do it slowly. Alternately, we could do this through artificial means, but we would need to get the energy from somewhere. If we get that energy by burning coal, that would be a net losing process. That's the one part where the Second Law comes in, and is the closest to zzsmirkzz's proposal of turning carbon dioxide back into fuel. It takes a net input of energy to do that, and you can't get ahead if you get that from coal fired power plants. If we got the energy from wind or solar or geothermal processes, then we would yield a net reduction in atmospheric carbon dioxide.
Another way to do this is through sequestration efforts. These CO2-sucking "trees" represent precisely this mechanism. Because they do not try to make more complex molecules out of the carbon dioxide, but rather just change its phase from gaseous to liquid or solid, the process can be powered by coal-fired plants and still come out ahead when measuring total change in atmospheric carbon. It doesn't violate the Second Law and it doesn't require the Earth to receive new energy externally. The stored carbon dioxide doesn't have the potential energy of the original fuel. It's just not in the atmosphere any longer, and that's the important thing in the short run.
Gah. Not only does RS-232 cabling suck, but also the data transfered over that cable sucks as well!
I remember working briefly at an ISP back in 1995. My favorite thing to love to hate was the fact that Global Village modems for the Mac came with a serial cable that lacked flow control signals. The modem was set to run with software flow control only. The problem is, though, at 14.4kbps and up, the round-trip response time for XOFF to actually stop things was way too long and resulted in bits dropped all over the floor. PCs with deep UART FIFOs may've been fine (I don't know), but every Mac owner that had a GV modem was bound to call us shortly after getting set up.
It was an absolute blast telling customer after customer to go spend $30 on a "flow control cable" (since that seemed to be the phrase most likely to cause sales droids to get them the right cable, right up there with "Atari tapes"). "Do you have a Global Village modem?" "Why yes! How did you know?" *headdesk*
Can't they just do what every other free software project does, and just ignore the bloody things?
There are two kinds of infringement under US patent law: Ordinary infringement and willful infringement. Guess which one carries triple damages? If you know something is covered by patent protection and you still infringe upon the patent willfully, you could be liable for triple damages. There are ways to keep the enhanced damages associated with willful infringement at bay (such as "advice of counsel," where you have expert legal advice to the effect that the patent is believed invalid), but that's something of a crap shoot.
So, how you act once a patent has been brought to your attention matters. In this case, it sounds like there are at least a couple.NET related patents that could apply to Mono. Infringing on those patents in the absence of legal counsel advising us that those patents are invalid would amount to willful infringement.
Don't take my necessarily-inaccurate-because-it's-a-sound-bite version's word for it. Here's an interesting article from the American Bar Association on the current state of this ever-evolving topic.
Does that actually work? Seems like there would be a continuum of conditions along the side of the bag, and there would be some point at which "moisture wins" and the bag tears. I can see your point with a paper-bottomed bag though.
Most programmers outside Microsoft have thrown Hungarian notation out the window, [...]
I can imagine the "type calculus" part of Hungarian notation being useful when writing large, complex programs in assembly code, such as much of the early Windows code, or with compilers and languages that don't take type-checking all that seriously (such as older C code). Now that type-checking compilers are widespread, encoding the type into the variable name is pretty much pointless. I don't need to know that piFoo is a pointer to int. If I use "Foo" in a manner inconsistent with pointer-to-int, enabling warnings in a modern C (or C++ or C# or Java or Pascal or.... (replacing 'pointer' with 'reference' as dictated by the language)) compiler will tell me. In other words, at least some aspects of Hungarian notation had their place as a reasonable convention for working around tool and language issues, and those aspects have just naturally gone obsolete. Your comment on VS C++ 3.0 nods towards this, I think, though I haven't ever used it, so I don't really know how good its type-checking and warnings were.
That said, I'm all for having at least some general, broad conventions, such as using i, j, k for loop indices (and ii, jj, kk for sub-indices when 'tiling' loops), leaning toward "verb_object" types of names for functions that act on things, and so on. Likewise, I feel it's helpful to the readability of code to develop local conventions to domains of the code, perhaps in an ad hoc manner, to give a cohesive feel to the program.
I'm talking about things such as common prefixes, or variables that are clearly related by how they're named. For example, I had a number of related parameters that controlled a particular algorithm I was tuning. You can probably see how they were related by how they were named:
uint32_t hmod0, hmod1, hmod2, hmod3;
uint32_t rotl0, rotl1, rotl2, rotl3;
uint32_t coll0, coll1, coll2, coll3;
(PS. If this comment shows up with funky vertical spacing, it's because I added extra <BR> tags to make the preview show up correctly, and even they don't seem to do anything. I don't know if the preview is accurate (unlikely) or b0rked (more likely), and I won't know until I hit ( _Submit_))
Re:Windows has more and more Unix features
on
Unix Turns 40
·
· Score: 2, Interesting
They have a talent for retaining the wrong things and adding more bad things to the bad things they already have. Look at Windows registry files: UTF-16 (not UTF-8) encoding [...]
Well, considering that Windows NT's development largely predates UTF-8, I think that they could be given a pass on that one. (As I understand it, Windows NT was the first Windows to really deeply embed Unicode, and the reason they went with UTF-16 was because that was the best that was available.) UTF-8 came on the scene in early 1993, and Windows NT came out just a few months later.
Or am I misremembering?
Re:Windows has more and more Unix features
on
Unix Turns 40
·
· Score: 2, Informative
And don't forget directories separated by slashes. They would have used forward slashes, except that they had already used forward slashes for flags (inherited from VMS by way of CP/M). And there were pipes, and redirection... Apparently one of the targets for MS-DOS 3.3 was to be compatible with MS's XENIX, with the eventual goal of switching everything over to XENIX. At least, I seem to recall reading that somewhere (Undocumented DOS, perhaps?).
Lots of XENIX fun here.
The random number generator will occasionally pick random strings that have word fragments or small numbers of case transitions or good left-right hand balance or some other attribute that makes it "easier." If you can model "easier" in those terms, then one can focus ones search on the "easier" passwords.
For example, my boss will keep asking for random passwords until she gets one with only a single capital. Well, if a hacker knew a priori that people did that sort of sorting, then they could exploit the lowered entropy.
You can prove this to yourself with an experiment. Imagine, for example, if you decided that digits in increasing order were "easier" than digits in arbitrary orders. Now suppose that users are presented with a dozen random passwords (consisting entirely of digits) to choose from, and they preferentially chose passwords with the longest runs of increasing digits. What does the password distribution look like now among your pool of users?
The important point in my comment was that "you can keep asking it for new random sets until you get one you like." If you ask for a long enough list, you can find whatever password you want. It's then just a battle of wills between you and the computer at that point.
Where I work, the system picks passwords FOR you, randomly generated. Now, it does give you a table of options, and you can keep asking it for new random sets until you get one you like, but that's still way better than letting users come up with their own passwords.
Of course, the resulting selected passwords are significantly weaker than the raw password count implied by "8 characters mixed case alphanumeric" (which has almost 48 bits of entropy if truly random). If you figure that a third of the bits of entropy are lost by letting users pick their own from a list of random passwords, that still leaves a 4 billion password space. You'd have to try 552 passwords/second to crack that one account in 90 days. If there are more effective bits of entropy (which there likely are), then the count only goes up from there.
there appears to be a preferential handedness of spiral galaxies, and the handedness exhibits itself along an axis that is close to the Axis of Evil.
They mention two phenomena: Polarization and the alignment of axes-of-rotation with the Axis. This could be explained if the distortion were a pinch. Imagine you draw a bunch of line segments uniformally scattered on a sheet of paper with uniformally random orientation. Now, view that sheet of paper through a lens that compresses the image horizontally, so that the image is pinched horizontally or stretched vertically. You'll notice a large bias in the orientation of the line segments, such that it appears that there's a fair degree of alignment with the axis of the lens.
That may or may not be the phenomenon we're seeing here with the uneven termination shock. The two observations mentioned in the first article don't seem to rule it out.
They mentioned that directly in the last paragraph of the second link.
And sure enough, Sharpe says astronomers have reported just such a change between two sets of images taken by the WMAP spacecraft, called the WMAP3 and WMAP5 maps.
So yes, they should fluctuate, and we have hints that we've seen it fluctuate. I imagine the fluctuations would be a function of both solar output and variations of density of interstellar mass. It'd be really cool if someone could correlate something like a CME to a "pinch" in the background radiation image.
Short version: You know how stars twinkle because of the Earth's atmosphere? Something similar happens at the boundary of the solar system. The difference there is that the boundary is due to the solar wind as opposed to an atmosphere.
The actual distortion is similar to the ripples of light you see on the bottom of a swimming pool due to ripples in the surface of the water. Because the surface is uneven, the light gets bent unevenly and bunches together in some places and spreads out in others. So, instead of even lighting across the bottom of the pool, you see a pattern of light and dark areas.
Same thing's happening to the cosmic background radiation. It should be evenly distributed, but instead it's brighter and darker in places, and they think it's due to the uneven surface of the termination shock.
Slashdot Mirror
True, but deep packet inspection will reveal whether your traffic is http or not. If nothing else, this implies you'll need to encapsulate your favorite protocol over a series of http requests, since I imagine "long" http requests might also get slowed.
Fun facts: If everyone in your neighborhood with a land line picked up the phone right now and tried to make a call, probably only 10% to 20% of them would succeed. If everyone in the average American suburb all hopped in their car and tried to get on the road to the nearest Interstate, it'd be gridlock. Traffic would move at speeds no where near the posted limits. We're surrounded by shared resources with capacity that reflects typical usage with a reasonable amount of head room for "normal" peaks, but is far from being able to support the maximum theoretical demand.
Airlines overbook because a certain %age of customers don't show up, and that %age is large enough and stable enough that it makes sense to do so. When too many people do show up for a flight, the airline pays penalties (in the form of travel vouchers and upgrades), so there's incentive to be conservative in the practice. Everyone benefits overall, though. More people get flown from point A to point B. If the airlines sell more seats on a given flight, then they can charge less per seat too.
ISPs are no different. They purchase bandwidth based on a model of "reasonable" network usage and how many subscribers they have. The major difference, though, is that it's very easy for someone to fall well outside the "reasonable" traffic usage. It's quite possible for 1% of the users to take up the majority of the network bandwidth. And I can see this being considered "unreasonable," and the ISP taking steps to make sure that the other 99% of users have a reasonable experience.
What I don't like is that ISPs can advertise something as "unlimited" or as running at a certain speed, when it clearly is limited, and the advertised speed is only a peak speed available in small doses. At least airlines are required to disclose their overbooking policy.
Speaking of bridges going badly, the Michigan Department of Transportation issued a great report about the Zilwaukee Bridge. (Site isn't M-DOT, but the it reproduces their report.) It had all sorts of problems during its storied construction, but it eventually was completed and stands tall and strong today. The report's conclusion summarizes:
One of the other big differences between bridge building and software construction is that the scope of the bridge's purpose is well defined: I want to get cars from point A to point B over some obstruction. The unknowns are generally confined to how that end is achieved, rather than the actual end that's being worked for. The Zilwaukee Bridge had well defined success criteria that were in place from the get-go.
When developing a new software project (as I'm doing right now at work), I find that if I ask N people what the exact requirements are, I get N+1 descriptions. In the end, I'm left to find the overlap and do my best to fill the fringes. It's hard to measure success when different stakeholders have different goals in mind, and agreements on said goals are often superficial.
You won't see that on a bridge. "It's supposed to be eight lanes!" "Well, it's seven traffic lanes plus a really broad shoulder. That's a total of eight lanes wide, after all." "That's not what I wanted. Make it wider!"
There are two sets of costs: non-recurring and recurring. The non-recurring costs include all of the engineering effort, R&D, putting together the production facility, etc. The recurring costs are those that you incur for each unit produced.
I find it highly unlikely that the recurring costs are more than $2.1M for the car, unless it was made of solid iridium or something. (Annual production of iridium is something like 3 tons.) I wouldn't find it surprising at all, though, if Bugatti had sunk quite a bit of R&D money into developing the tech in the Veyron, and perhaps a bit of dough on the production facility.
Wikicars says this:
So far, the oldest article I've seen claiming these numbers is this one from early 2007. By the end of 2006, fewer than 50 had been produced. If we assume this number applies to the first 50, then that means the total cost to that point was a cool £250million. Yow!
Since then, though, another 150 have been produced. I highly doubt that it cost another £750million. In fact, this article points to most of the costs having been R&D costs with this quote:
That's 250 man-years. If you assume each engineer costs $250K/year for labor, benefits and overhead, that's $62.5M in labor costs developing the transmission alone. Throw in all the machine work and parts and everything else, and I'm sure you easily get up to $100M development costs on the transmission alone.
People keep throwing that £5 million per car number out there, but I seriously believe it's way out of date.
According to Wikipedia, the "Gotha 229" designation refers to the chosen manufacturer for the plane, and the two designations refer to the same plane. When I saw the picture of the plane, I was immediately reminded of the box for that game. Never owned it (my computer wasn't stout enough for it), but I certainly remember seeing it.
Does it run on the iPhone or do I have to go buy proprietary hardware to run the SDK? From what my iPhone-owning (and developing) friend tells me, the SDK won't even run on his dual G5 Mac. He tried to sell it to me, and I'm like "What good is it? Jobs has decreed it obsolete."
While we focus on atmospheric carbon dioxide a lot, I'm pretty sure carbon monoxide is even worse, if only because it messes up human respiration. Now, this part sounds much more interesting:
Now, it sounds like this reaction requires a net energy input, but if we get that energy from solar or wind sources, then we're still ahead of the curve by preventing new carbon from coming into the atmosphere. There will be plenty of devices that use methane as a power source for years to come. If we can use this reaction along with these carbon dioxide harvesting trees to essentially "tread water" with the existing CO2 (cycling it to methane, and then burning that to get back to CO2), rather than extracting more natural gas from the ground and burning it, that would be a lovely step forward that doesn't require everyone to invest in new appliances.
I, of course, was just trying to be funny.
The Earth isn't a closed system, and so the Second Law doesn't even directly apply in the "big picture". We have a net energy input, and so can do things to reduce entropy (ie. lock up carbon dioxide that was released through entropy-increasing processes such as burning).
Burning hydrocarbons releases energy that was stored due to photosynthetic processes that built up more complex molecules from simpler ones. So, yes, the total amount of carbon hasn't changed, but it's gone from a higher potential energy state to a lower potential energy state.
The presence of atmospheric carbon dioxide increases the Earth's average temperature through radiative forcing. Removing carbon dioxide from the atmosphere prevents that from happening.
One way to reduce atmospheric carbon dioxide is to lock it back up in more complex molecules. That also would absorb energy and store it with the carbon dioxide. This is what plants do. Unfortunately, they do it slowly. Alternately, we could do this through artificial means, but we would need to get the energy from somewhere. If we get that energy by burning coal, that would be a net losing process. That's the one part where the Second Law comes in, and is the closest to zzsmirkzz's proposal of turning carbon dioxide back into fuel. It takes a net input of energy to do that, and you can't get ahead if you get that from coal fired power plants. If we got the energy from wind or solar or geothermal processes, then we would yield a net reduction in atmospheric carbon dioxide.
Another way to do this is through sequestration efforts. These CO2-sucking "trees" represent precisely this mechanism. Because they do not try to make more complex molecules out of the carbon dioxide, but rather just change its phase from gaseous to liquid or solid, the process can be powered by coal-fired plants and still come out ahead when measuring total change in atmospheric carbon. It doesn't violate the Second Law and it doesn't require the Earth to receive new energy externally. The stored carbon dioxide doesn't have the potential energy of the original fuel. It's just not in the atmosphere any longer, and that's the important thing in the short run.
I vote we repeal the Second Law of Thermodynamics. ;-)
At least it's safer than sending nuclear waste, right?
Ok, that got rid of maybe 0.001%... And actually, that'd just be re-releasing it into the atmosphere by way of a Coke can.
Could it work? Now where to put all that liquid CO2?
Gah. Not only does RS-232 cabling suck, but also the data transfered over that cable sucks as well!
I remember working briefly at an ISP back in 1995. My favorite thing to love to hate was the fact that Global Village modems for the Mac came with a serial cable that lacked flow control signals. The modem was set to run with software flow control only. The problem is, though, at 14.4kbps and up, the round-trip response time for XOFF to actually stop things was way too long and resulted in bits dropped all over the floor. PCs with deep UART FIFOs may've been fine (I don't know), but every Mac owner that had a GV modem was bound to call us shortly after getting set up.
It was an absolute blast telling customer after customer to go spend $30 on a "flow control cable" (since that seemed to be the phrase most likely to cause sales droids to get them the right cable, right up there with "Atari tapes"). "Do you have a Global Village modem?" "Why yes! How did you know?" *headdesk*
Will it work on my Commodore?
There are two kinds of infringement under US patent law: Ordinary infringement and willful infringement. Guess which one carries triple damages? If you know something is covered by patent protection and you still infringe upon the patent willfully, you could be liable for triple damages. There are ways to keep the enhanced damages associated with willful infringement at bay (such as "advice of counsel," where you have expert legal advice to the effect that the patent is believed invalid), but that's something of a crap shoot.
So, how you act once a patent has been brought to your attention matters. In this case, it sounds like there are at least a couple .NET related patents that could apply to Mono. Infringing on those patents in the absence of legal counsel advising us that those patents are invalid would amount to willful infringement.
Don't take my necessarily-inaccurate-because-it's-a-sound-bite version's word for it. Here's an interesting article from the American Bar Association on the current state of this ever-evolving topic.
Does that actually work? Seems like there would be a continuum of conditions along the side of the bag, and there would be some point at which "moisture wins" and the bag tears. I can see your point with a paper-bottomed bag though.
I can imagine the "type calculus" part of Hungarian notation being useful when writing large, complex programs in assembly code, such as much of the early Windows code, or with compilers and languages that don't take type-checking all that seriously (such as older C code). Now that type-checking compilers are widespread, encoding the type into the variable name is pretty much pointless. I don't need to know that piFoo is a pointer to int. If I use "Foo" in a manner inconsistent with pointer-to-int, enabling warnings in a modern C (or C++ or C# or Java or Pascal or.... (replacing 'pointer' with 'reference' as dictated by the language)) compiler will tell me. In other words, at least some aspects of Hungarian notation had their place as a reasonable convention for working around tool and language issues, and those aspects have just naturally gone obsolete. Your comment on VS C++ 3.0 nods towards this, I think, though I haven't ever used it, so I don't really know how good its type-checking and warnings were.
That said, I'm all for having at least some general, broad conventions, such as using i, j, k for loop indices (and ii, jj, kk for sub-indices when 'tiling' loops), leaning toward "verb_object" types of names for functions that act on things, and so on. Likewise, I feel it's helpful to the readability of code to develop local conventions to domains of the code, perhaps in an ad hoc manner, to give a cohesive feel to the program.
I'm talking about things such as common prefixes, or variables that are clearly related by how they're named. For example, I had a number of related parameters that controlled a particular algorithm I was tuning. You can probably see how they were related by how they were named:
uint32_t hmod0, hmod1, hmod2, hmod3;
uint32_t rotl0, rotl1, rotl2, rotl3;
uint32_t coll0, coll1, coll2, coll3;
(PS. If this comment shows up with funky vertical spacing, it's because I added extra <BR> tags to make the preview show up correctly, and even they don't seem to do anything. I don't know if the preview is accurate (unlikely) or b0rked (more likely), and I won't know until I hit ( _Submit_))
Well, considering that Windows NT's development largely predates UTF-8, I think that they could be given a pass on that one. (As I understand it, Windows NT was the first Windows to really deeply embed Unicode, and the reason they went with UTF-16 was because that was the best that was available.) UTF-8 came on the scene in early 1993, and Windows NT came out just a few months later.
Or am I misremembering?
And don't forget directories separated by slashes. They would have used forward slashes, except that they had already used forward slashes for flags (inherited from VMS by way of CP/M). And there were pipes, and redirection... Apparently one of the targets for MS-DOS 3.3 was to be compatible with MS's XENIX, with the eventual goal of switching everything over to XENIX. At least, I seem to recall reading that somewhere (Undocumented DOS, perhaps?). Lots of XENIX fun here.
What color is the sky in your world?
The random number generator will occasionally pick random strings that have word fragments or small numbers of case transitions or good left-right hand balance or some other attribute that makes it "easier." If you can model "easier" in those terms, then one can focus ones search on the "easier" passwords.
For example, my boss will keep asking for random passwords until she gets one with only a single capital. Well, if a hacker knew a priori that people did that sort of sorting, then they could exploit the lowered entropy.
You can prove this to yourself with an experiment. Imagine, for example, if you decided that digits in increasing order were "easier" than digits in arbitrary orders. Now suppose that users are presented with a dozen random passwords (consisting entirely of digits) to choose from, and they preferentially chose passwords with the longest runs of increasing digits. What does the password distribution look like now among your pool of users?
The important point in my comment was that "you can keep asking it for new random sets until you get one you like." If you ask for a long enough list, you can find whatever password you want. It's then just a battle of wills between you and the computer at that point.
Where I work, the system picks passwords FOR you, randomly generated. Now, it does give you a table of options, and you can keep asking it for new random sets until you get one you like, but that's still way better than letting users come up with their own passwords.
Of course, the resulting selected passwords are significantly weaker than the raw password count implied by "8 characters mixed case alphanumeric" (which has almost 48 bits of entropy if truly random). If you figure that a third of the bits of entropy are lost by letting users pick their own from a list of random passwords, that still leaves a 4 billion password space. You'd have to try 552 passwords/second to crack that one account in 90 days. If there are more effective bits of entropy (which there likely are), then the count only goes up from there.
They mention two phenomena: Polarization and the alignment of axes-of-rotation with the Axis. This could be explained if the distortion were a pinch. Imagine you draw a bunch of line segments uniformally scattered on a sheet of paper with uniformally random orientation. Now, view that sheet of paper through a lens that compresses the image horizontally, so that the image is pinched horizontally or stretched vertically. You'll notice a large bias in the orientation of the line segments, such that it appears that there's a fair degree of alignment with the axis of the lens.
That may or may not be the phenomenon we're seeing here with the uneven termination shock. The two observations mentioned in the first article don't seem to rule it out.
They mentioned that directly in the last paragraph of the second link.
So yes, they should fluctuate, and we have hints that we've seen it fluctuate. I imagine the fluctuations would be a function of both solar output and variations of density of interstellar mass. It'd be really cool if someone could correlate something like a CME to a "pinch" in the background radiation image.
Short version: You know how stars twinkle because of the Earth's atmosphere? Something similar happens at the boundary of the solar system. The difference there is that the boundary is due to the solar wind as opposed to an atmosphere.
The actual distortion is similar to the ripples of light you see on the bottom of a swimming pool due to ripples in the surface of the water. Because the surface is uneven, the light gets bent unevenly and bunches together in some places and spreads out in others. So, instead of even lighting across the bottom of the pool, you see a pattern of light and dark areas.
Same thing's happening to the cosmic background radiation. It should be evenly distributed, but instead it's brighter and darker in places, and they think it's due to the uneven surface of the termination shock.