hn12

I'd love to see a few examples of the current generation of "good reviews" and comparable "AI slop" from a couple of months ago. While it's entirely appropriate for an article such as this to quote sources' own words, there's also real value in passing on such specific detail.

'Sure looks like a two-for-one deal to me: not only does the DoW announce clearly that only Big Man loyalty, not professionalism or morality, constrains it, _and_ it's a reminder that the Federal government more generally feels free to ignore contracts at any time.

While I sure don't have a solution to offer, I'm glad at least that the Linux Foundation, The Register, and others are documenting the reality.

You have me curious, mountainriver. While I don't understand what you've written, I want to know more. Are you saying that open-source models can't be trusted as well as (some of the?) proprietary ones, and therefore aren't fit for "mission-critical" medical applications?

For me, the salient turning point was the Reagan administration, which began cultivation of the attitude that government collection of routine data on weather, railroad traffic, crime, health, ... was intrinsically suspect, expensive, and partisan, rather than a public service and scientific adjunct.

I'll say this a different way: my personal opinion is that there's at least a whole book that deserves to be written on the documentable underinvestment in government measurements of national characteristics. We've trained a couple of generations--especially the most recent one--that rhetoric, rather than analysis, is the appropriate basis for policy decisions.

Skepticism, or at least reserve, in the face of expertise, can be a healthy impulse. It's simultaneously a leading slogan of the jingoistic playbook of authoritarians. Anti-intellectualism isn't a solvable problem: it's an ongoing temptation that every society needs to address in contemporary terms.

This is good reporting: that is, SJVN usefully summarizes crucial narratives from inside kernel maintenance. Commercial organizations would do well to make decisions about AI this wisely.

... and energy densities of batteries will _stay_ well below that of tanks of hydrocarbons, as https://web.archive.org/web/20130204210054/http://h30565.www... explains.

I endorse everything Vasudev has written here. In the abstract a couple of other libraries of interest are Java-coded PDFBox and Python-based PDFMiner.

No.

Well, the correct answer to almost any such technical question is "yes and no". This one comes as close as any to a bare "no".

It's a good question. PDF->SVG conversions are quite powerful--when they work. They simply do NOT work, in the general case. I deal with a hundred-thousand PDFs at a time, and they demonstrably don't behave with enough regularity to allow for the kind of general transformation I suspect you have in mind.

As it happens, our little company does quite a bit of business extracting content from specific classes of PDFs http://phaseit.net/claird/comp.text.pdf/PDF_content_extracti... Coincidentally, I also research and deliver advanced SVG effects http://phaseit.net/claird/comp.text.xml/SVG_examples.html I certainly am sympathetic to your aim. To be successful, you need to specify your situation more precisely.

What's cool? Ah, that's a different question. Prob'ly Go. See also http://www.infoworld.com/d/application-development/10-progra...

I'm lost, absconditus. If you're waiting for a follow-up, please detail what you need. I think you might be saying something like, "Expect is cool, indeed, but why would someone post a link to its Wikipedia article in HN?" That one, I can't answer.

All true.

One of the difficulties with Expect is that it's hard to explain its usefulness to newcomers. Expect itself is easy enough to understand; but a common initial reaction is, "So?"

Part of the difficulty is that Expect particularly shines in occasional circumstances that no one wants to repeat. It's a tool, more than a product--like a funny little jig that looks peculiar, but saves HOURS when you are doing particular operations with a drill press.

Network devops, for instance, might need to monitor and update hundreds of devices spread across multiple datacenters for a particular task accessed through a command-line interface (CLI). The CLI is "easy", in that it only takes thirty seconds to do one instance of the chore--but a royal nuisance to repeat for hour after hour. A "correct" answer probably involves setting up authentication key pairs and ... well, you can see where this is going. How "correct" is that kind of configuration, though, when it might have to be done only once in the lifetime of the datacenters? This is a typical case where twenty minutes of Expect scripting can save HOURS, and sometimes days, of error-prone typing. It would easily be worth hundreds of dollars to have Expect on hand for this one use. No one will ever pay for Expect, though, because it helps most for these pesky side-tasks that no one really budgets.

I can give lots of examples of good uses for Expect--but each single example will only apply to a handful of people around the world. Nearly everyone needs Expect in some way, but each instance is highly idiosyncratic.

Expect is a little like duct tape or WD-40.

https://bitbucket.org/djarvis/jexpect is an example. 'Need others?

I couldn't agree more.

I'm sufficiently involved with Expect that I've collected enough material for an entire book on the subject (serious--I do a lot of writing, and am well aware of what's involved in such a publication); at the same time, I know that jlgreco is EXACTLY right that Expect use is a symptom of a larger problem. Much of what I've already published through the years about Expect is how a particular task that used to be done with Expect now can better be handled with automation-interface-X.

I'm the author of the original article. I didn't think of the content itself as "contrarian", but the headline certainly turned out that way--and of course "contrarian" has different meanings to different people.

Plenty went wrong. Plenty went right.

Hand-recounted votes aren't such a bad thing, in my personal view; more objectively, I think it's only fair to note how often they happen in the US, Canada, the UK, ...

Yes and no. You're absolutely right to ask these questions, and they're ones the article would have addressed more specifically with just a bit more depth.

Folklore has it that Google/Bing/... do give at least small bumps for correct use of microformats. SEO is such a mess--so non-deterministic, among other things--that we perhaps should leave this for another time. There is evidence for SEO, but it's generally smaller than "five spots ..."

Detection of telephone numbers ... well, I find it a challenge, especially when working across national borders. I totally accept that it might be a non-problem for you: the applications on iPhones or other leading handsets do everything you need for your US-oriented Web site.

I appreciate you giving the article a fair reading. Microformats are indeed rather foggy to figure out; do they truly matter? It sounds as though, for you, they might not, at the moment. If you're doing much internationalization, though, or working with calendars, or would benefit from automation of contact exchange, or ..., then it's worthwhile to experiment at least a little.

I'm not responsible for the visuals.

There is indeed nothing new; it's surprised me, though, to learn from recent conversations how few people understand Amazon's drive to compete on price, and what a tiny incident this really was. I felt obliged to document the basic background.

I'll say that, absolutely: databases should NOT store authentication information, but only salted hashes.

It's an equal certainty that there'll be implementations around for as long as humans remain that stupidly include un-hashed authentication data.

I'm the submitter. I'll write a little of what I know.

joshu, you wrote, "notice that OP doesn't really post things they are not involved with". In this case, I think you intend me when you write, "OP". At this point, http://news.ycombinator.com/submitted?id=hn12 seems to tally sixteen items I've submitted to HN. The first fifteen were to pieces I'd written: the tiny minority of all I'd written in the past couple of years that I thought would particularly interest HN, but certainly related to me. The sixteenth, and most recent item, was the one which spawned this thread. In my mind, I had nothing to do with the piece on introversion, and know nothing about the author, but it's true that I write sporadically for the same site.

I submit rarely to HN in part because I don't understand it. While I scan it, I don't feel familiar enough with its ethos even to qualify myself as a lurker. I frequently post--mostly pieces I have not written--to Reddit, DZone, Stackoverflow, and so on, because I am far more comfortable with what "works" there.

My main personal conclusion from my submission is that I'm surprised--astounded, even--and pleased with the quality of the comments that have followed. I've found them more meaningful, in aggregate, than those for any other submission I've read in HN. This encourages me to believe that there must be much more to HN than I've found, and I simply need to approach it some different way.

joshu, in a nearby comment you suggested I "disclose". Please provide detail: how do you recommend I have submitted the article on introversion?

joshu, in a nearby comment you write about "chasing pageviews and not reputation". When I posted the piece on introversion, I was "chasing" neither pageviews NOR reputation; as I've suggested above, I understand the latter only dimly. I thought the article would interest HN readers.

I underline: rsmiller, hn12, and the author of the introversion piece are three different people. I suspect the three of us have never met each other, although of course I'm in no position to be certain of the other two.

I'm unsure what you mean, joshu, by "the submittor works for the submitted blog". I occasionally write for the HPIO site. It's possible I'll never do so again; I certainly am not an employee or otherwise related to HPIO with a duty to submit articles from the site to HN.

I'm the author of the article. I, too, was disappointed that Mr. Bellard chose not to answer questions. I could have investigated him more deeply with more interviews of others; I chose, for this time, to respect his modesty and not do that. Perhaps there'll be an occasion in the future for a different treatment.