I was thinking more in terms of durability than performance. Traditional hard drives are still recommended for swap because they don't wear out quite so easily in write-heavy workloads.
Performance may be better as well, though; just because it's possible to saturate a SATA link with multiple SSDS on one particular workload, doesn't mean that they're fast for every workload. For instance, you can't write to flash without zeroing out the surrounding chunks. It might be handy to have a place on the drive that can handle small writes without the extra overhead.
If PCM is faster but more expensive than traditional flash, it sounds like it might be useful to incorporate into SSDs as a cache, or alternatively as a separate partition to use as swap or to store the filesystem journal.
Is there some reason why this wouldn't work (besides relative unavailability an expense at present)? Is PCM better able to deal with many erasure cycles (which is why SSDs aren't recommended for swap)?
And they were right. All of those things did de-humanize war (as if it were humanized to begin with). Of course winning is often more important than the human element, but we should think carefully about the trade-offs, so we can decide if it's worth it in any particular circumstance.
I saw this set up at SC09 (they happened to have a booth next to ours). The enclosure is set up to make it easy to work on without making too much of a mess; the servers are mounted vertically, and they can be pulled up and set on their side over the top of the tub, so they're just dripping back into the tank. The technicians will probably have to wear gloves to keep from getting oil on their hands, but otherwise it didn't seem like the mess would be a big deal.
The 1.8 million fares represent a tiny fraction of a total 360 million trips over the 26-month period in question.
Taxi drivers are people. People make mistakes. One mistake per two hundred trips does not seem unreasonable, especially considering that the frequency of incidents per driver probably follows a power-law distribution and the median number of mistakes per driver is likely much lower. Another way of looking at it is that 25% of drivers didn't make a single mistake in more than two years of driving.
Which isn't to say that these were all honest mistakes. However, I don't see this as the massive systematic fraud the article seems to be suggestion. A 0.5% chance of being overcharged just doesn't seem like something to get excited about (even if I lived in New York, which I don't).
it didn't seem right for a *million* inbound links to have a *million* times the effect compared to a single inbound link
Pagerank isn't just a citation count; it's defined recursively, such that a link from a page with a high pagerank is worth more than a link from a page with low pagerank. Similarly, a link from a page with many outlinks is worth less than a link from a page with the same rank but few outlinks.
It does turn out to be more of a popularity contest than a quality metric, though. I think you're absolutely right about that.
I'm aware of the difference, but even so, C programmers typically call them functions, not procedures, and I've been a C programmer for a lot longer than a functional programmer, so that's what I (and many imperative programmers) are accustomed to calling them. It isn't as if I don't think it's important to use words correctly, but I don't think it's productive to argue about who is using what word in the wrong way if my meaning is clear. If it isn't, then that's my mistake, then.
Very true. However, I have found that programs I write in functional languages tend to have significantly fewer bugs. I don't know how much of this to attribute to the functional style of programming without side-effects, or the very strict Hindly-Milner type system I'm accustomed to working with in ML-derived languages like Ocaml and Haskell.
I did not mean to imply that functional programs don't need to be tested, and I fear my post came across that way. Rather, the testing effort is usually much shorter, as there are fewer iterations of "find bug, fix bug, re-test".
To say a language is "functional" does not mean the same thing as the common usage of the word, which is to say "useful" or "utilitarian", though in my experience with Ocaml, Haskell, and Erlang, they are that as well if you take the time to learn to use them well. Fortran and F# have just about nothing in common.
The name "functional" is a little confusing, since imperative languages are heavily based on functions as well, though they are not typically used in the same way. For instance, in a functional language it is usually much easier to write functions that compute useful things without causing side effects, such as modification of shared state. They also usually support such features as tail call optimization (which causes certain forms of recursion to require constant rather than linear stack space), closures, the ability to declare functions within other functions, and the ability to call a function with less than its expected number of arguments, yielding a function of the remaining arguments.
Another common trait of functional languages is the absence of looping constructs, in favor of recursion and library functions like map and fold.
Another thing I'm curious about (I expect it's probably addressed in the paper) is that they're comparing military personnel with PTSD against civilians without PTSD. Did they include any military personnel without PTSD, or civilians with PTSD? I would not be surprised if simply being in the military (I.e. the different discipline, training, lifestyle, experiences, etc... ) would alter the brain in a measurable way, and they would have to be careful that that isn't what they're seeing.
Hydrogen is used because it's low molecular weight allows it to accelerate much more quickly than other gases. It's just pressurized hydrogen; they don't combust it because then it would turn into a high-molecular weight gas which would have too much of its own inertia. According to Hunter, compressed hydrogen guns have the record for the highest velocity projectiles, far surpassing gunpowder or magnetic devices (i.e. rail guns).
The projectile has a heat shield, some of which burns off as it leaves the atmosphere. Outside the atmosphere, the shield is jettisoned, and a single stage rocket kicks in. The cannon shoots the projectile at more than orbital velocity, but there's enough atmospheric drag that the rocket is needed. It will have active guidance, and presumably dock with an orbital fuel or cargo depot of some kind. (The primary use would be to get rocket fuel into orbit for cheaper than it costs to lift it with multistage rockets.)
Adapting electronics to high-g is not as hard as it sounds. Most consumer electronics can withstand a pretty strong shock, and the parts that don't are easy to modify.
I never took a statistics class as an undergrad. In retrospect, I think it would have been very useful, probably more so than the calculus I took (which I think is also a very good thing to know, but stats tend to be used more often).
Here's where I think the main problem actually is: We actually send home some who do want to stay.
I absolutely agree. The NSF, DARPA, NIH, etc.. have paid for the education of many a foreign grad student, only to have them booted out of the country after they finish their degree. (A lot of them end up moving to Canada.)
Some of the grad students I knew had to do some crazy things like leave the country periodically, and then apply to get let back in, just because that's what the bureaucracy required.
How much does a typical developer cost versus a potential saving of 1000 servers? What is the human to server runtime cost ratio? And how many developers would it take to actually replace and maintain php with C/C++ code? (It would probably take more than the number of PHP programmers, and they'd probably cost more per person, and I question whether it would be as maintainable)
In any case, it wouldn't be as simple an analysis as the article implies. That much is certain.
I think most of the analysis I've seen so far implies that it's a simple cost tradeoff - more programmers versus more servers. It's more complicated than that, and you have identified one of the reasons why: maintainability. The kind of programs Facebook needs written are just plain easier to write in PHP than in C or C++, for many reasons (though PHP was probably not the best language they could have chosen, it's not an awful choice, either). If they wrote it in C or C++, not only would it be more expensive, but (and this is the important part) it would take longer to write and test. Web companies can't afford to waste a couple years re-writing their core infrastructure. They also can't afford to be stuck with a tool that's hard to modify.
Also, it's not as if Facebook is an all-PHP shop. They've invested a lot of effort writing an open source tool called thrift, which allows programs in any of the (12 or so) supported languages to communicate easily with each other. If they decide it makes sense for them, they can change languages.
Well, I suppose the summary might mean plain old FM radio (i.e. as opposed to AM radio).
Also, the 2-meter and 70cm ham bands tend to be exclusively FM, though calling them "the FM band" isn't sufficiently specific and would probably get you some funny looks from ham operators.
There's more to it than that. I have read that (and someone please correct me if this is wrong) Gnome has actually been much more attractive to 3rd party developers of proprietary software, because GTK is LGPLed and therefore developers could link their apps against GTK, whereas QT was (eventually) GPLed, but commercial software developers had to buy a commercial license for QT.
In that sense, Gnome was not only based on free software from an earlier date, it imposed less restrictions on its users. It was more free because it didn't force its own idea of freedom on developers.
Why? Wouldn't it be more screwed up to say "gosh, Mr. inventor, I don't have to pay you for a license, because I'm going to use your invention for my own use"
I think the patent system is screwed up, but not based on anything in your description. Namely, the patent process strongly favors those with deep pockets, programmers waste a lot of time just trying to figure out what is and is not patented, a small company (and even some large ones) can be sued out of existence just for infringing a patent they never knew existed, and the twenty year duration is a veritable eternity in the software industry. (Granted, this discussion is about a hardware device, but a lot of the animosity against patents in general comes from frustration with software patents.*)
We are, however, very fortunate that patent duration has not followed the same trend as copyright, else we would still be paying licensing fees for inventions from the nineteenth century.
* I once took a poll of users on a site with a fair number of highly technical users, asking if anyone had written a useful (in their estimation) program that they did not release because of patent concerns. I was surprised by how many said yes. (The results were 7 yes versus 11 no: not a large enough sample size to extrapolate a trend, but interesting.)
That's pretty much the only thing you can do with a patent, stop someone else from using it. (Licensing is just an agreement not to exercise that power.)
I see several explanations for Google applying for a patent:
They want licensing revenue (unlikely)
They want to patent the technique before someone else does (possible, but they could have simply published the technique)
They want an arsenal of patents they never intend to enforce, but they can use as a threat against companies whose patents Google is infringing (more likely - this is pretty much standard practice in the corporate world these days)
They patented the technique out of pure bureaucratic inertia - it's just what corporations typically do in this situation, as it's the least-risk choice (also likely)
I wouldn't consider any of these particularly evil, but it is inconvenient for smaller organizations who might want to use the technique, but don't want to go through the hassle of negotiating with Google (who might just ignore their request for licensing).
I guess I was thinking more of the fairly universal concept that you can use the result of one function as an argument to another without giving it a name. For instance:
result = f(g(x))
instead of
foo = g(x); result = f(foo)
Haskell applies a points-free style in more cases than we're used to seeing in other languages, which is sometimes useful but I agree it is just as often an annoyance to those who are trying to understand someone else's code. I was thinking of a rather looser definition of points-free, which is present to some degree in all the programming languages I'm familiar with.
Fair enough. I have learned, through experience, that one must make sure that the result of the computation based on hGetContents is fully evaluated before closing the file.
Slashdot Mirror
I was thinking more in terms of durability than performance. Traditional hard drives are still recommended for swap because they don't wear out quite so easily in write-heavy workloads.
Performance may be better as well, though; just because it's possible to saturate a SATA link with multiple SSDS on one particular workload, doesn't mean that they're fast for every workload. For instance, you can't write to flash without zeroing out the surrounding chunks. It might be handy to have a place on the drive that can handle small writes without the extra overhead.
If PCM is faster but more expensive than traditional flash, it sounds like it might be useful to incorporate into SSDs as a cache, or alternatively as a separate partition to use as swap or to store the filesystem journal. Is there some reason why this wouldn't work (besides relative unavailability an expense at present)? Is PCM better able to deal with many erasure cycles (which is why SSDs aren't recommended for swap)?
And they were right. All of those things did de-humanize war (as if it were humanized to begin with). Of course winning is often more important than the human element, but we should think carefully about the trade-offs, so we can decide if it's worth it in any particular circumstance.
I saw this set up at SC09 (they happened to have a booth next to ours). The enclosure is set up to make it easy to work on without making too much of a mess; the servers are mounted vertically, and they can be pulled up and set on their side over the top of the tub, so they're just dripping back into the tank. The technicians will probably have to wear gloves to keep from getting oil on their hands, but otherwise it didn't seem like the mess would be a big deal.
Taxi drivers are people. People make mistakes. One mistake per two hundred trips does not seem unreasonable, especially considering that the frequency of incidents per driver probably follows a power-law distribution and the median number of mistakes per driver is likely much lower. Another way of looking at it is that 25% of drivers didn't make a single mistake in more than two years of driving.
Which isn't to say that these were all honest mistakes. However, I don't see this as the massive systematic fraud the article seems to be suggestion. A 0.5% chance of being overcharged just doesn't seem like something to get excited about (even if I lived in New York, which I don't).
I like to think of the current state of the Internet as the Wild West phase.
Pagerank isn't just a citation count; it's defined recursively, such that a link from a page with a high pagerank is worth more than a link from a page with low pagerank. Similarly, a link from a page with many outlinks is worth less than a link from a page with the same rank but few outlinks.
It does turn out to be more of a popularity contest than a quality metric, though. I think you're absolutely right about that.
I totally agree, the call graphs are very helpful. (Note: graphviz needs to be installed for this to work.)
I'm aware of the difference, but even so, C programmers typically call them functions, not procedures, and I've been a C programmer for a lot longer than a functional programmer, so that's what I (and many imperative programmers) are accustomed to calling them. It isn't as if I don't think it's important to use words correctly, but I don't think it's productive to argue about who is using what word in the wrong way if my meaning is clear. If it isn't, then that's my mistake, then.
Very true. However, I have found that programs I write in functional languages tend to have significantly fewer bugs. I don't know how much of this to attribute to the functional style of programming without side-effects, or the very strict Hindly-Milner type system I'm accustomed to working with in ML-derived languages like Ocaml and Haskell.
I did not mean to imply that functional programs don't need to be tested, and I fear my post came across that way. Rather, the testing effort is usually much shorter, as there are fewer iterations of "find bug, fix bug, re-test".
What if you need a complex program that's very reliable? I know it can be done in C and Python, but usually not without rigorous testing.
To say a language is "functional" does not mean the same thing as the common usage of the word, which is to say "useful" or "utilitarian", though in my experience with Ocaml, Haskell, and Erlang, they are that as well if you take the time to learn to use them well. Fortran and F# have just about nothing in common.
The name "functional" is a little confusing, since imperative languages are heavily based on functions as well, though they are not typically used in the same way. For instance, in a functional language it is usually much easier to write functions that compute useful things without causing side effects, such as modification of shared state. They also usually support such features as tail call optimization (which causes certain forms of recursion to require constant rather than linear stack space), closures, the ability to declare functions within other functions, and the ability to call a function with less than its expected number of arguments, yielding a function of the remaining arguments.
Another common trait of functional languages is the absence of looping constructs, in favor of recursion and library functions like map and fold.
Another thing I'm curious about (I expect it's probably addressed in the paper) is that they're comparing military personnel with PTSD against civilians without PTSD. Did they include any military personnel without PTSD, or civilians with PTSD? I would not be surprised if simply being in the military (I.e. the different discipline, training, lifestyle, experiences, etc... ) would alter the brain in a measurable way, and they would have to be careful that that isn't what they're seeing.
I just watched that a couple of days ago.
Interesting details:
Hydrogen is used because it's low molecular weight allows it to accelerate much more quickly than other gases. It's just pressurized hydrogen; they don't combust it because then it would turn into a high-molecular weight gas which would have too much of its own inertia. According to Hunter, compressed hydrogen guns have the record for the highest velocity projectiles, far surpassing gunpowder or magnetic devices (i.e. rail guns).
The projectile has a heat shield, some of which burns off as it leaves the atmosphere. Outside the atmosphere, the shield is jettisoned, and a single stage rocket kicks in. The cannon shoots the projectile at more than orbital velocity, but there's enough atmospheric drag that the rocket is needed. It will have active guidance, and presumably dock with an orbital fuel or cargo depot of some kind. (The primary use would be to get rocket fuel into orbit for cheaper than it costs to lift it with multistage rockets.)
Adapting electronics to high-g is not as hard as it sounds. Most consumer electronics can withstand a pretty strong shock, and the parts that don't are easy to modify.
Most of the hydrogen is re-captured and re-used.
I never took a statistics class as an undergrad. In retrospect, I think it would have been very useful, probably more so than the calculus I took (which I think is also a very good thing to know, but stats tend to be used more often).
I absolutely agree. The NSF, DARPA, NIH, etc.. have paid for the education of many a foreign grad student, only to have them booted out of the country after they finish their degree. (A lot of them end up moving to Canada.)
Some of the grad students I knew had to do some crazy things like leave the country periodically, and then apply to get let back in, just because that's what the bureaucracy required.
The F-1 Process Explained
I have an oscilloscope made by them. I use it to tune my piano.
I think the world is better off when people use the language that meets their needs rather than the language that makes them look smart.
I think most of the analysis I've seen so far implies that it's a simple cost tradeoff - more programmers versus more servers. It's more complicated than that, and you have identified one of the reasons why: maintainability. The kind of programs Facebook needs written are just plain easier to write in PHP than in C or C++, for many reasons (though PHP was probably not the best language they could have chosen, it's not an awful choice, either). If they wrote it in C or C++, not only would it be more expensive, but (and this is the important part) it would take longer to write and test. Web companies can't afford to waste a couple years re-writing their core infrastructure. They also can't afford to be stuck with a tool that's hard to modify.
Also, it's not as if Facebook is an all-PHP shop. They've invested a lot of effort writing an open source tool called thrift, which allows programs in any of the (12 or so) supported languages to communicate easily with each other. If they decide it makes sense for them, they can change languages.
Also, the 2-meter and 70cm ham bands tend to be exclusively FM, though calling them "the FM band" isn't sufficiently specific and would probably get you some funny looks from ham operators.
There's more to it than that. I have read that (and someone please correct me if this is wrong) Gnome has actually been much more attractive to 3rd party developers of proprietary software, because GTK is LGPLed and therefore developers could link their apps against GTK, whereas QT was (eventually) GPLed, but commercial software developers had to buy a commercial license for QT.
In that sense, Gnome was not only based on free software from an earlier date, it imposed less restrictions on its users. It was more free because it didn't force its own idea of freedom on developers.
I think the patent system is screwed up, but not based on anything in your description. Namely, the patent process strongly favors those with deep pockets, programmers waste a lot of time just trying to figure out what is and is not patented, a small company (and even some large ones) can be sued out of existence just for infringing a patent they never knew existed, and the twenty year duration is a veritable eternity in the software industry. (Granted, this discussion is about a hardware device, but a lot of the animosity against patents in general comes from frustration with software patents.*)
We are, however, very fortunate that patent duration has not followed the same trend as copyright, else we would still be paying licensing fees for inventions from the nineteenth century.
* I once took a poll of users on a site with a fair number of highly technical users, asking if anyone had written a useful (in their estimation) program that they did not release because of patent concerns. I was surprised by how many said yes. (The results were 7 yes versus 11 no: not a large enough sample size to extrapolate a trend, but interesting.)
That's pretty much the only thing you can do with a patent, stop someone else from using it. (Licensing is just an agreement not to exercise that power.)
I see several explanations for Google applying for a patent:
I wouldn't consider any of these particularly evil, but it is inconvenient for smaller organizations who might want to use the technique, but don't want to go through the hassle of negotiating with Google (who might just ignore their request for licensing).
I guess I was thinking more of the fairly universal concept that you can use the result of one function as an argument to another without giving it a name. For instance:
result = f(g(x))
instead of
foo = g(x); result = f(foo)
Haskell applies a points-free style in more cases than we're used to seeing in other languages, which is sometimes useful but I agree it is just as often an annoyance to those who are trying to understand someone else's code. I was thinking of a rather looser definition of points-free, which is present to some degree in all the programming languages I'm familiar with.
Fair enough. I have learned, through experience, that one must make sure that the result of the computation based on hGetContents is fully evaluated before closing the file.