He did apologize for it, quite quickly, and agreed that reverting the change was appropriate. He also asked a good question: why can't pulseaudio deal with other error codes, error codes that might be technically correct, though not in current use?

The developer wasn't being nasty, underhanded, manipulative, etc. It's possible to break user land by fixing broken behavior that userland depends on, and it's been an ongoing issue for all kernels. (Take a look at the history of the egcs variant compiler and Linux kernel compilation.)

> Aren't those documents created or edited by LibreOffice by any chance?

Not in my direct experience. MS Word format has _never_ been fully standardized or had a robust API, standards for which features are compatible with which revisions of MS Word. The result has been absolute chaos with old documents, and is part of the reason that governments have tried to switch to an "open" and documented format such as OpenOffice and LibreOffice use. Microsoft finally published an API, referred to as "OOXML", to get by government requirements for documented formats.

But the history of the lobbying to get OOXML passed as an ISO standard was a horrific abuse of a standards process. It should _never_ have passed in that broken state,and Microsoft _does not follow the standard_ they worked so hard to legislate. The result is disastrous and unpredictable loss of document content. And _LibreOffice can often recover content that MS Word cannot_ in such corrupted documents.

I'll add my support for Notepad++. It's a very powerful and much, much lighter weight tool than Word or LibreOffice, suitable for configuration files, source code, HTML, and most scripting languages. It integrates very will with the file browser, and handles multiple documents and multiple applications opening the same document better than either Word or LibreOffice.

Sadly, training students to gain expertise with such a specific toolkit as MS Word in preference to tools like Notepad++ is a serious error and waste of their limited school time. They _will_ spend much of their document creation time on the colors, the formats, the fonts, the indentation, and the inevitable document losses and downtime during forced upgrades of a too-powerful toolkit that encourages appearance over content.

Google documents are intriguing in their features. I'll be curious to see if they're mature enough, in the next few years, to actually use in the workplace. (My colleagues and business partners have been, unfortunately, tied to MS Word formats for business documents.)

There's the prosecution of Phil Zimmerman for publishing PGP, the failed attempt to publish the "SkipJack" algorighm with all keys held for law enforcment use, the new "Trusted Computing" toolkit with all keys held by Microsoft with no legal assurance of their privacy against warrant-free access under the "Patriot Act", there's the Patriot Act isself, and then there is US federal law at http://www.ecfr.gov/cgi-bin/text-idx?SID=9ae4a21068f2bd41d4a5aee843b63ef1&c=ecfr&tpl=/ecfrbrowse/Title15/15cfrv2_02.tpl#730.

It's frightening reading. Widespread domestic security for electronic documents is being sacrificed to permit government access to communications, both foreign and domestic, with and without court order or knowledge of anyone being monitored. The fiber optic taps in AT&T's core data center planted by the NSA were quite real, quite illegal, and the personnel involved have been given immunity.

Because he's unfortunately typical, and he might be trainable.

Human Resources is not usually a leadership group: they're following practices set forth by the company's management. If they're scheduling events 3 months in advance without an actual date, and setting the date in the last week at their own convenience and not the convenience of the job candidate, that means the problem is a policy one above the pay grade of the individual HR person. A job interview is always a two way process: let this be a strong hint that you'd be merely a cog in a very big machine.

The different nature of the exam than what this candidate expected should not have been a surprise. Concluding the nature of an interview from how far ahead it was scheduled is the sort of extrapolation without data that will waste everyone's time, socially and in programming. Someone who'd been through a few technical interviews would know that such interviews very widely, would do their "due diligence", and find out the nature of the exam in advance. That's why "LinkedIn" is very useful for, both ways: to examine a company through employees whose candid opinions might be helpful, and to get other references about an employee. These references are vital, and can give information that HR or a company brochure would _never_ provide, or might never think to ask for.

One of the best candidates I interviewed had been mishandled by our own HR: poor scheduling and insensitivity to the candidate's needs for confidentiality had almost cost them their current job. (We had VP approval at their current company to interview the candidate, because the department was being closed: but the candidate's supervisor hadn't been told yet. It was a strange situation.) When that candidate arrived, they were very upset. They and I spent almost the whole interview going over how to arrange layers of access to information in _our_ systems, to allow HR to do their jobs but to protect them and us from similar confusion and from possible lawsuits about gender, age, or medical conditions. They came away with the realization that we'd screwed up, but wouldn't repeat the problem, and that we actually _did_ try to treat our employees based on skill, and to treat employees as people. And we saw that they took bad situations as problems to resolve, rather than as personal insults.

We didn't hire them. (They got an internal company transfer, much to their benefit.) But they've worked with us on some projects since then to both our benefit.

There can be many reasons for this, such as empire building (where a manager's pay scale and promotions depend on the number of people they manage). Getting outside review can also sometimes stabilize a project: I, and my colleagues, have sometimes _been_ the consultants brought in to help integrate a new project. There are few projects as doomed to failure as exciting technical innovations that were actually done better years ago, are already available in their existing tools, and they just didn't know how to use them so they've re-invented the wheel.

Can you find out why your manager thinks it needs additional layers of human complexity? Does that manager think your time is too committed and you won't have enough left for all the work? Doing good work on QA and documentation, and making sure you manager knows it's there, might help reduce their need to add layers of consultants and extraneous testing or planning cycles.

You _do_ realize that NAMBLA, the organization, was never convicted of anything? They were effectively sued to death, with numerous prosecutions that were dismissed in court, but drained their limited coffers. And with journalists and the FBI constantly infiltrating their ranks, I assume they knew that anything criminal they did would be reported almost instantly. Their original involvement with gay political groups was effectively ended when they were expelled from those groups.

B4U-ACT is fascinating. They do seem to be encouraging mental treatment of pedophilia as a disorder, recognizing pedophilia as a disorder, and they do not claim that engaging in it physically is proper. Given that prisoners have sometimes died in jail becuase other inmates were told, truthfully or not, that those prisoners were child molesters, I can understand their desire for better education and treatment.

So no, they're not the "same freaks, same message, new management". It's a related issue but very different approach to it.

It means that "social networking" is often expected to be used, not for frank communications, but for company managed advertising. I've actually attended staff meetings where staff were urged to talk up their own company's products and to help drive criticisms of their products to the next page of product reviews. I was not surprised, but saddened: the flaws were very real and could have been used as a great opportunity for the company to address the problems and turn that negative review into a great example of customer support, at a much lower cost in manpower.

Please excuse my language: I just spent a long time with a partner who insisted on doing things _very much_ the hard way.

> I'd bet that most users who don't have SNI supporting browsers don't have access to IPv6 servers either. IIRC IPv6 on windows XP is turned off by default which for most users means it may as well not be there.

Please separate the requirements of their browsers from the requirements of their servers. The need for SNI is primarily due to the difficulties of SSL key handling: when you connect to an IP address for an encrypted SSL connection, which is tied to the IP address and the host's SSL keys associated with that IP address.

SNI provides some useful workarounds for that requirement, but it's often been awkward to scale and to support. Profound difficulties occur when supporting the name-based virtual servers for people and software _who refuse to follow the best practices_. The results can be nightmarish. If I, as a user, use "www.example.com" instead of "example.com" and they're both at the same IP address, I can often wind up with completely different web pages and little hint of what I did wrong, and then call tech support about the problem. Similarly,

It's a problem I, or my colleagues, run into several times a year.

> umm at least with apache there doesn't seem to be much difference. With IP based vitual hosting you tell it what IP you want to go with each site. With name based virtual hosting you tell it a list of names to go with each site.

The difference is that there are often many ways to reach exactly the same IP address with alternative hostnames in the URL, such as DNS aliases, putting a "." on the end of the hostname (which is completely valid in DNS and prevents the addition of an automatic local domain extension), shortened hostnames if your local DNS supports adding the local domain, modified /etc/hosts files on the client, (which is still far too common a practice from very, very old setup documentation), internal DNS versus DNS entries in sites that use load balancers or static NAT, and others. Couple this with old and poorly managed configuration files complex ourtward facing environments, and a long QA and release process, as is common in large environments, and the slightest name-based misconfiguration can corrupt the entire site and be very awkward to trace back.

There is also the very confusing behavior when common software configurations start putting IP address "127.0.0.1" and "::1" in the webserver's /etc/hosts with the fully qualified hostname. This is actually quite common, but it means that the web server itself can't reliably detect whether the web server is running properly running. Going to the IP address by typing it directly is not necessarily the same virtual host, and redirects will go to the /etc/hosts specified "127.0.0.1". This makes testing the primary web service from the same host itself quite chaotic.

The IP based virtual hosting not only allows far easier management of these configurations, it allows vastly simplified packet analysis to trace and analyze the virtual host specific network traffic. For that reasoon alone, I urge partners and colleagues to switch to IPv6 IP based virtual hosts for crowded externally facing virtual hosts, and to feel free to use IPv4 virtual hosts for internal NAT'ed addresses.

Or they can use IPv6 and IP based web servers, instead of the amazing crap that is server name based virtual hosting and which has *never* worked well.. Avoiding the guesswork, rewriting, and redirecting rules of name based virtual hosting is one of the best justifications I know for using IPv6.

The whole field of transmitting the high-frequency trading information seems to be going away in favor of FPGA's sitting right on the fiber leaving Wall Str.

          ftp://ftp.bittware.com/documents/data_sheets/ds-hft.pdf

By putting these sorts of devices directly on leased connections from the stock market, adjacent to the stock market, they eliminate the need for the extremely expensive and often quite unreliable remote high speed connections. I was recently privileged to hear a presentation on the risks of data loss on those lines: they're apparently using multicast for high speed synchronoous transmission, But by the time you've checksummed and re-assembled your data and re-collected the lost packets, it can actually be _slower_ than normal TCP, and the the data verification technologies are often poorly tested.

The key to using the FPGA's is to tune and simplify the models that are stored and processed locally, in place of the expensive remote data centers. And updating those devices doesn't require the low latency and high speed: the analysis of stored data and updates of models can be done remotely and much more slowly.

You've raised several good points, which I'll try to explain.

* The Trusted Computing focus on DRM instead of privacy puts the most critical software keys in the hands of the software vendors, not the computer users. Computer users' keys are designed, in Trusted Computing, to be held in Microsoft's central escrow. The result is that to access your data, and possibly your hardware, you must use Trusted Computing authorized software, and your private keys are accessible to anyone with access to Microsoft's central repository. The result is a direct loss of personal security because both the software keys and yoru personal keys live in Microsoft's hands, not merely your hands. The results for personal privacy are profound: the system ensures authentication and tracking of document creation thorugh review of public and private keys, it does _not_ protect individuals from government or corporate abuse of this central key repository..

* The centralization of the keys and escrow management also means that the keys can be _revoked_, at the software level, denying you access to your previously encrypted private data. Revocation of keys is a critical feature of Trusted Computing, and is rarely addressed for its potential to deny people access to their own Trusted Computing secured data.

* DRM is not for the "owners" of a piece of property. It is for the _vendors_ of that property. They may not actually own a single line of the code, but the particular assemblage of the code which they sell is locked down. This can be useful to prevent cheating in computer games, but it's precisely what TIVO tried to do with patent encumbrance on top of GPL licensed software. It is an ongoing dream of many software vendors who work with "open source" software or proprietary software to lock down their particular implementation and charge whatever the market will bear for that particular version.

* DRM is often a violation of ordinary sales rights to use property. If you can successfully put a codicil in the contract or bill of sale, well and good, but many DRM tools far exceed any reasonable or documented codicil. They grant far too much control to the vendor of the software. (Examine Trusted Computing and the history of Sony's "root kits" for examples of such abuse.)

* RMS has been very careful, and clear, that the people working under GPL are using exactly the right you want: the right to insist that software be used the way the authors want it to be used, or not to be used at all. Many of hsi views are impractical, but that doesn't mean they wouldn't be effective if consistently applied

I actually had the opportunity to speak to RMS a few years ago at a conference. He's a strange man in person, but his approaches to technology and freedom are consistent and well thought out.

It's actually an interesting point. Freedom of software use, and the ownership and ability to access and modify data and software which we purchase, is vital to protecting private data. The "Trusted Computing" technology, for example, is designed to provide secured key access for software and data, and it's being heavily promoted among CPU and motherboard manufacturers and software vendors. It's designed to provide a secure toolchain to authenticate, to encrypt, and to provide software registered access to data.

But careful review of its actual use show thits primary use is DRM, _preventing_ individuals or software from accessing their data in any way other than that specifically authorized by the company issuing the key. The master signature keys for Trusted Computing are held by Microsoft, and they hold most of the private keys in escrow. And the legal guidelines protecting those keys don't seem to exist. I've not been able to find any clear guideline on when, and under what legal requirements, Microsoft will give out or even _subvert_ those keys to install software on computers without the authorization of the owner. This is one of Richard's current concerns: the use of technology to fetter communications and access to your own data and your own resources.

That's a very reasonable point. It's certainly a common one for people who run their own systems. Google has apparently been good about resisting illicit searches, but they do seem to cooperate with legal searches. And a search that is legal can still be inappropriate. (The US Patriot Act is a good example of bad law.)

The difficulty that has strongly reduced my desire for private email systems has been reliability. There are numerous difficulties. Backup and failover, with all traffic preserved, have been awkward.This also includes the bandwidth issues at remote sites, and the resistance to DDOS (distributed denial of service attacks) I've found it very effective to put up with their advertising, or pay a very modest fee for business service, for a service that has an uptime I've never seen in a private service. And I've _run_ or helped integrate and clean up literally dozens of such systems throughout my career.