For highly reliable code, knowing that the code you review is the code you compile with is vital both for stability and security. This can't be done by visual inspection: it requires good provenance at every stage of the game.

This is actually a security problems with many opensource and freeware code repositories. The authors fail to provide GPG signatures for their tarballs, or to GPG sign tags for their code. So anyone who can steal access can alter the code at whim. And anyone who can forge an SSL certificate can replace the HTTPS based websites and cause innocent users to download corrupted, surreptitiously patched code or tarballs.

I'm actually concerned for the day that someone sets up a proxy in front of github.com for a localized man-in-the-middle attack to manipulate various targeted projects.

> Outlook is particularly nasty.

Well, yes. There's a reason that so many partners and clients have swithed to Gmail and Google Docs.

You're quite correct. I've certainly worked with, and given my time for, non-profits who earned the label.

Much of the data is free and available elsewhere. All the public domain content, in fact is freely accessible.

What JSTOR especially provides, and part of what Aaron was reaping wholesale, was its organization and links, basically the indexing and cross-indexing. _That_ is what makes JSTOR so useful, and what people pay JSTOR for: the breadth and searchability of the data. JSTOR is already a non-profit agency, whose fees are quite reasonable for the service they provide. And Aaron kept _breaking_ parts of JSTOR by downloading too much too fast, and overwhelming the servers.

Activism, or hacktivism, is one thing. Breaking critical research tools for millions of customers worldwide is abuse, and clearly criminal in several ways. I'm afraid that Aaron earned prosecution. The extent of the prosecution seems severe, but as best I can tell, the prosecutors were quite willing to "deal" for a a very low sentence, as long as the deal included a felony conviction. I'm afraid that that haggling over the charges and the sentence is _normal_ for prosecutors.

Not usually. the call centers are in India or other countries. A number of my H1B holding colleagues in the US spent some time working in those centers. They were very busy, and wound up learning some useful approaches, in some cases from people like me who walked them through what the real problem was and what we really needed.

Several years ago, while helping a corporate partner's personnel with a printer that their company manufactured and getting it working with Linux, one of their personnel recognized my style and my voice, because he'd come to the US. He was a visiting colleague from the printer company's India location, not an H1B holder, but as I mentioned having contacted the manufacturer about the issue, he recognized my voice and my style from working the call center before his promotion.

We had an interesting chat. He'd apparently been learning more about the systems, and going offscript and taking longer on the calls, which caused him trouble keeping the job. But he was also submitting suggestions to improve the tech support scripts and to cover weird cases, which got him noticed by a wise manager. And he'd worked for, and earned, promotions that now had him visiting the company's main offices to help improve system reliability. He was very much a "hacker" in the old sense of the word, and was delighted to be promoted where he could do more interesting work. I'd have hired him in a minute if my company's contracts did not prevent poaching.

> America has lots of room compared to the rest of the world

And let's keep it that way. A great deal of the rest of the world is having real problems with fresh water, arable land, and pollution. Highly industrialized nations require space, per capita, to provide the energy resources and the comfortable living space they enjoy. There are serious issues with health care costs and manpower for the elderly as the population ages, but H1B visas are not likely to help with that.

> Many, many businesses have learned the hard way that core software development needs to be in close (as in immediate, face-to-face) contact with the business side to translate requirements (often inchoate in the minds of the execs and product managers) into concrete requirements and actual software quickly in a very competitive market place.

Many business are trying to pretend that it's not relevant for IT work, and scatter their IT groups around the world. It's something I've tried to advise against when collaborating with or supporting other groups: the costs can be quie profound.

> Yes, they're all from India. ALL OF THEM! Th

That's because the call center is in India. They're not H1B visa holders. And let's be honest: It's boring, tedious work that does not pay well _of course_ it will be outsourced.

> Not true. A factory is not built where the demand is, but where the labor is available. The goods can be shipped.

These are hardly the only factors. Power, raw materials, and taxation, the cost of land, regulatory restraints on traid, and handling refuse from manufacture also strongly influence factory location. "Goods can be shipped" also ignores the cost of shipping:

> the fall in unemployment follows rather than precedes the liberalization of immigration

The potential fallacy here is called "post hoc, ergo proctor hoc". It means "after, therefore because of". The timing you describe makes sense, but the rise you describe was tied to the creation of the European Union and the easing of trade across all the EU borders. The British were suddenly able to export and import a lot more freely, and _that_ helped with the employment boom.

I'm afraid that the "liminiferous aether" was the medium on which electromagenetic waves were carried. It was disproven by the Michelson Moreley experiment, which led to a lot of _other_ fascinating theories. Phlogiston was no more "thermal energy" than vacuum is what you pour into vacuum tubes. It was what came _out_ of burning substances and was contained in them to leak out as fire.

Please don't rewrite the history of physics and chemistry to try and invent "privatives", the measurable absence of a something found elsewhere, as a a "real" substance.

Perhaps on your projects: on mine, I'm afraid they represent direct expense and lost income

These are new designs, effectively release candidates. It is _extremely_ difficult, and hideously expensive, to pre-test everything in final configuration, and these are very complex systems that are subjected to enormous stresses on launch and recovery. Complex modeling and mechanical specifications cannot hope to catch the surprises that may be found in final reviews and checklists, on the ground, before launching the craft.

  I'm afraid "improve build quality" could be a managerial directive, like "safety first" that doesn't actually describe any real, individual process that's not already in place.

> this being said, I can't really see filing the charges as being more cumbersome than doing the paperwork for letting them go.

I'm afraid it's not uncommon, especially at first. Handwritten documents have room for describing circumstances, many automated systems do not, or lack the necessary categories and wind up with the documents miscategorized or misdirected when first used. It's certainly common with trouble ticket and budget systems: I'm facing several such cases right now.

> Those old and crusty daemon and log management integration tools are simply crap compared to systemd's integrated approach. You obviously don't have any real experience with systemd if you think otherwise. Everything is at least 100 times better than compared to SysVinit/Upstart (and Syslog etc).

Can I safely assume that you never used Dan Bernsteiin's "daemontools", which stayed of the complexities of logging and worked very well for daemon management.? If SysV init was due for replacement, then there are much lighter tools that could have done just _that_ task.

I do not "want to configure systemd". I want to not replace several decades of daemon and log management integration in dozens if not hundreds of distinct environments with an entirely distinct, complex, and poorly integrated system.

The idea that "in a few years, all Linux distros will use it" is completely irrelevant to the upfront cost of switching now.