cmccabe

I work at Cloudera (although not on Impala). I work on HDFS.

Impala was about creating a low-latency SQL engine for Hadoop, so that queries could be done interactively by a human at a keyboard. This is something that you don't really get with Hive (despite all the recent hype) because it simply is too slow, and has high startup costs. That's unlikely to change in the future because of the overhead of spinning up JVMs, starting MapReduce jobs, etc.

It seems like you are trying to target the OLTP market. That's a difficult market to crack. A lot of the value of things like Oracle and Microsoft SQL server is not in the database itself, but in the surrounding software. Performance is nice, but unless you can get orders of magnitude, it's very difficult to compete.

Will anybody ever bridge OLTP and OLAP? The last people who claimed to be trying to do that were Drawn to Scale, and we all know how that turned out. I think it's better to focus on doing one thing well.

Good luck.

Let's try wikipedia:

The three-strikes law significantly increases the prison sentences of persons convicted of a felony who have been previously convicted of two or more violent crimes or serious felonies, and limits the ability of these offenders to receive a punishment other than a life sentence. Violent and serious felonies are specifically listed in state laws. Violent offenses include murder, robbery of a residence in which a deadly or dangerous weapon is used, rape and other sex offenses; serious offenses include the same offenses defined as violent offenses, but also include other crimes such as burglary of a residence and assault with intent to commit a robbery or murder.

So, since speeding is not a felony, it has no relevance here. Shoplifting might be a felony, but it would only invoke three strikes if you already had two prior felonies which also happened to be violent.

By the way, I'm not defending three-strikes laws, just describing them. I think they are a bad idea. I also think the ACLU is whitewashing the records of a lot of the people involved here.

Three-strikes laws are dumb, but so are you. Take your anti-US agenda somewhere else. I suggest North Korea, China, Venezuela, Iran, Russia, or any of the other countries not allied with us, so you can see how much "better" they are.

why not just kill them right away?

Because evidence might come up later that proves them innocent. Because killing someone deprives them of all of the rest of their life, whereas life imprisonment offers them some fraction of it.

I actually do think there are some people we should just hang-- after due process, of course-- but definitely not everyone who has a long sentence.

Also, a "life" sentence usually just means 20 years in the US, for whatever reason.

Most languages that have "traditionally" shipped with a REPL don't feature compilation at all. So yeah-- I guess that's fast? (Before you start, I'm not interested in pedantic arguments about how any language can be compiled. I know.)

If it's "cumbersome" to acquire the state you need for testing, then that sounds like a design problem that you should fix. The best kind of tests are reproducible and part of a test suite anyway.

Maybe I missed it, but I didn't find anything on http://golang.org/doc/code.html#PackagePaths that seems to forbid what you're doing. In fact, it says "in practice you can choose any arbitrary path name, as long as it is unique to the standard library and greater Go ecosystem." But rather than main1 and main2, surely it makes sense to name those directories after the binaries you're building?

I actually kind of like Go's scheme here. One thing I never quite liked in C/C++ was huge directories full of source files where it wasn't clear what code was part of what binaries. If something is only part of one binary, why not make that obvious by putting it in another package?

You don't really need a REPL when compiles take literally only a second or two. It's only the fact that C++ had a static type system where programs took (literally) hours to compile that made dynamic typing look so great in comparison. "Poorly designed static type systems drive people to dynamic typing," as Rob Pike said.

The ChromeBook has been explicitly designed and marketed as a low-cost alternative for people who just want to access the web. Most ChromeBooks are around $100-300.

Windows RT machines are usually between $300-$600, and were marketed as "Windows" machines, which brought with it a set of expectations that Windows RT machines were not able to meet. People assumed that "it runs Windows" meant that it ran their apps, but that just wasn't true in this case.

I am aware that there are some ChromeBooks that are really expensive, and Microsoft introduced desperation price cuts at certain points, but that's the basic story.

Speaking as someone who lived through that period of time, I think anyone using Win9x would scream.

Yeah. One thing that some people seem to miss is that you can have multiple man pages for a topic-- perhaps one that lays out the general outlines, and one for more specific information.

git does this: it has "man gittutorial" and "gitcvs-migration", as well as man pages for each command. It makes a lot of sense and avoids the "giant wall of irrelevant text" approach.

Bash, on the other hand... yeah. Just try finding anything in there.

In the future, Man in Business Suit Levitating will be the only form of communication.

I have had good luck with OpenSUSE. They package the latest stuff (I am on kernel 3.7.10 now). They're also very community-focused.

I work at Cloudera. We work on Hadoop, HDFS, and other open source technologies full-time.

An internet search will give me many different choices of documentation of unknown provenance, authorship, official status, datedness, accuracy, and comprehensibility.

True. But the documentation for GNU programs, both man and info, is often also "of unknown provenance, authorship, datedness, accuracy, and comprehensibility." You even said yourself that the man pages for many of these GNU programs are years out of date on some systems. Official status is not guaranteed either, since anyone can fork an open source program and produce a clone.

Somehow, despite all that, we manage to muddle on. Probably, it's because we're humans, with the ability to filter out bad information and incomprehensible explanations, and find the real information. And in my experience, this is much easier to do with a man page, which usually simply gets to the point, than with a long, meandering info page which treats me like an idiot and yet often fails to mention vital information.

Thank you for the clarification that info pages can support images. Since I have only ever used info in a terminal, I was not aware of this.

In a lot of ways, info reminds me of Microsoft's CHM format, another HTML workalike with limited abilities. CHM can also support images.

Web usage may be monitored, but I suspect that searching for information about open source programs won't reveal anything about me that downloading Linux did not.

There are lots of ways to bribe, and most of them are legal.

Cupertino already is fairly high-density, at least downtown. And I don't think anyone suggested bulldozing anything, just allowing people to build what they want, which they currently have a very hard time doing.

If I want an introduction to complex topic, I usually won't use man pages. I will open up a web browser and search. That will give me web pages that have pictures, diagrams, and possibly even introductory essays about the topic.

There are many more people who know how to write web pages or forum posts than who know how to write "info" pages. There are also great tools for searching the web, but poor tools for search info pages. "info" pages can't even have diagrams or pictures. Consequently, information obtained via "info" tend to be stale, incomplete, and generally unhelpful.

The real question is why "man" pages are still useful in the era of the internet. The answer is that sometimes, you want a concise, accurate, quick reference to what is installed on your system. "man" fills this function admirably. "info" fills that function awkwardly and poorly.

If corporations are banned from trying to persuade people (i.e., advertising), they'll turn to bribing politicians (i.e. hiring lobbyists). Which is worse? I think that's clear.

I don't agree with Comcast's position here, but I think they should be allowed to be heard if they want to be. Democratic societies are strong because they're made up of a lot of strong non-governmental institutions and groups, not just an all-powerful government and powerless individuals.

"They see your mail." Ooh, scary. Email is effectively a postcard. It gets sent in cleartext all over the internet. If you think that email is even slightly private, you are misinformed. I don't see why I should trust LinkedIn any more or less with my emails than Google, Yahoo!, or any of the other companies that run regular old SMTP servers which process and store (possibly forever) tons of my email.

"sharing passwords" isn't a problem with this scheme because it doesn't use your password. It creates a separate IMAP account and links it to your regular account via OAuth.

"I think this programme is being criticised because it intercepts people's mail and inserts content" -- really? A sample comment is "they are spammers." Nothing there about man-in-the-middle, nothing there about email interception. I don't think most of the people bashing LinkedIn here even understand how Rapportive/Intro works.

The particular CSS exploit shown here seems like one that can and will be fixed. Obviously, there are other ways to do phishing via email, including just sending an email that looks like someone else's mail (remember: postcard). A lot of mail services are starting to filter spammy or fake-looking mail, so that may help.

Pretty much everywhere in the San Francisco bay area is sunny year round, except San Francisco itself. So if you have seasonal affective disorder, you could always just live in the east or south bay during the winter months. As a bonus you'd save on rent.

Based on everything I've read, LinkedIn didn't develop this technology. They bought it when they acquired Rapportive (which, by the way, was a Y Combinator startup).

Can someone explain the technical details here a little more? I feel like a few steps are missing in the explanation. Why does Rapportive/Intro need a separate IMAP account attached to the device? How could LinkedIn ever think email could be secure? Email is a plain-text protocol based on trust. Can't people just spoof source addresses and inject whatever they want into the next email server in the chain?

For some reason, a few people at HN seem to have a hard-on for criticizing LinkedIn. I never hear the same criticism of Facebook or Twitter here, even though their privacy policies are just as bad, or worse in many cases, and they also send bulk email.

I get spammed by all the social networks I've joined, and even by a few that I didn't join. I get mail from every newspaper or magazine I've ever subscribed to, and many that I never have. Condemning one business for doing this while praising another is just hypocrisy.

Yeah! We should artificially push the price of rentals down, so that there will be no incentive to increase supply, ever.

I can't see any problems with this plan.

It's Google Island!

www.wired.com/gadgetlab/2013/05/on-google-island/‎

News flash: most technology companies don't really pay dividends. Probably, the main reason is because dividends are taxed at a pretty high rate. It's easier just to keep the money overseas in some tax shelter or other (Apple, Google), or plow it back into the company as investment (Amazon). Microsoft is one of the few tech companies that pays dividends.

Spending money on dividends looks like a poor choice. If your share price is sagging, you can always buy back your own shares with part of your cash hoard, like Microsoft did recently. Investors are always willing to believe that your investment will make the stock more valuable because TECHNOLOGY. And if they aren't, who is to guarantee that the stock will have any value at all next year? Cough-- Nortel Networks-- cough.

Notice how many tech stocks are in here? http://www.forbes.com/sites/dividend/2011/01/24/10-stocks-th...

Hacker News, if anything, is probably to the right of most Americans, due to the number of libertarians and entrepreneurs.

Also, referring to "the Left" as if it were a single thing qualifies you as the "ignorant" one. Even back when the USSR existed, there were differences of opinion. You can look up Marshall Tito and the differences of opinion between Mao and Stalin if you're curious.

Don't be fatuous. If you wrote all of the code, you should be able to tell exactly what it does. If there's some code you're calling that was written by someone else, you have to trust it to do the right thing. Exceptions versus return codes doesn't change that fact.

People usually don't check the return code of fmt.Printf because they simply don't care. Most of the time, you're just logging to a terminal, which basically never fails. And if logging did fail, you wouldn't want to abort the program because of it.

The only time you might want to check the return value of printf is if you're writing a simple utility designed to transform something passed on stdin to something on stdout.

It seems like you missed a lot of the other things he said, such as "testing is built into the language," and "binaries are statically compiled and will work on any reasonable kernel." These may not be sexy features, but they are features that you need to actually make reliable programs.

And frankly, yes, Go's approach to handling errors is a Big Deal. It's counter to the tendency of the last few years to move more and more error handling into exceptions. In retrospect, we can see that that was a mistake, similar to the "natural language programming" dead-end that led to COBOL and HyperCard. Challenging the exception-handling orthodoxy is absolutely something interesting and new.

What makes Go so special other than the lack of deep class hierarchies? This is an "other than that, Mrs. Lincoln, how was the play?" type of comment. Go's type system is absolutely huge in terms of making it special. It would never have attracted the attention it did if it were just another Modula-3 rehash like Java, C++, D, etc.

In the past, GPUs weren't that practical for big data, since they offered a lot of CPU power, but not much in the way of I/O. It's possible that PCI-e 3.0 and 4.0 will change that, since they supposedly offer up to 15 GB/s and 31 GB/s bandwidth.

Big data is more than just querying. There are people running fancy machine learning algorithms. Those are the people most likely to use the flexibility of having a Java (or other programming language) interface.

I'm curious why you think FPGAs will win over GPUs in HPC. I struggle to imagine academics writing Verilog or VHDL. I can just barely see them sending in legions of grad students to try to write CUDA or OpenCL, but RTL design seems a bridge too far. I also haven't heard of any of the big FPGA companies trying to make a splash in HPC, whereas NVIDIA has been very active with Tesla and its other high-end offerings.

I wasn't trying to be negative about FPGAs. I was just pointing out that there are good reasons to use GPUs in some scenarios. If your company can put FPGAs within reach of more people, that would be awesome.

I used to work at a startup company that had a plan to reduce power consumption in data centers by spinning down hard drives when they weren't in use. Too late, we learned that there isn't a lot of money in saving power. The average data center in the US might spend $500k/year on electricity. That sounds like a lot, until you consider that the fully loaded cost of a good engineer will be around $200k/year. Power becomes a factor only when you hit a wall in terms of how much can be delivered to the data center.

I was an electrical engineer in college, and I learned how to write Verilog and do register-transfer-level design. It's something that I don't think most software engineers have the background to do. Currently, I work in the area of big data, on Hadoop.

I cannot deny that Hadoop is not very power-efficient. But it offers some things that are more important to customers: infinite scalability, the ability to run on commodity hardware, and the ability to interface with the system via normal-looking software.

Actually, even writing Java code is too difficult for many Hadoop users now. They prefer to write SQL. (Even SQL is too hard for some, and they use automated tools to generate the SQL and produce charts.)