'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.
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.
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.
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.
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.
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.
