And yet, where do people want to be treated when they contract Ebola? What nations have active R&D for an Ebola vaccine? A Malaria vaccine? And in India, who actually uses the state run healthcare when private is an option? And in the U.K., how do you skip the NHS wait queue for something like hernia surgery? And in Canada, where do you go when the government health care system refuses to fix your knee because you're a computer programmer, and having a working knee is not necessary to your job function?

I guess there is room for a *little* privatization...

I'll consider filing bug reports for them, although I feel that it's probably more of a job for a QA person being paid by Google to do the work, rather than my job, seeing as I am not currently with Google. At present, none of the projects where I had considered using Go have used Go because of these deficiencies, so I have no real incentive to do the legwork for free, if it's going to take me away from other work.

Here's a partial list of interfaces that are implemented in the Libc portion of Libsystem, rather than directly as system calls, and are therefore unavailable to call from Go:

bsd_signal, confstr, creat, crypt, encrypt, ftw, gethostid, gettimeofday, getwd, killpg, nftw, semctl, setpgrp, setregid, setreuid, shmctl, sigsetmask, sigblock, sigpause, sighold, sigrelse, sigignore, statvfs, tcgetsid, uname, utmpx
etc., including all 32 POSIX1e ACL related commands, almost all pty related code, much of termios.

Here's a partial list of system calls which use an additional parameter/error checking/descriptors at the user/kernel boundary, and therefore randomly exhibit POSIX non-compliant behaviour when called from Go programs:

posix_spawn, posix_spawnp, pthread_create, pthread_mutex_lock, pthread_mutex_unlock, fork, kill, sigaction, sigvec, etc. ...like I said, a job for a QA person to identify them all.

Ideally, what would happen, is that The Open Group VSU, VSX, VSTH, and VSRT tests, at a minimum, would be converted to Go, and verified that they get the same results as their C language counterparts when run against any UNIX or UNIX-like platform. Barring that (due to licensing expense), the Open Source LSB-FHS, LSB-VSX, and LSB-OS tests would be used instead.

One valid reason for enterprise side loading is if the App is not offered through iTunes in your region. In many cases, it's not offered worldwide, due to all sorts of regulatory restrictions; this is the same as for music you get from iTunes, where the developer wants market segmentation, or the regulators (government, etc.) in a given area wants segmentation or control.

In those cases, the only way to get the app for your region is to pirate it. For example, in China, as in Russia and the Ukraine, as well as other countries, there are regulations against having strong encryption which does not contain a government back door. In other places, they don't want you to be able to use a particular type of VPN to get around the government firewall which is content based, and media companies don't want you using VPNs to get around regional distribution schemes. As an example, RIAA and MPAA have been trying very hard to get VPNs to be declared illegal, or to declare their actual origin of the their customers, in Australia, the U.K., and elsewhere.

So there are valid political free speech reasons you might want to do this, and there are commercial unavailability reasons you might want to do this. Both of these are internal grey or black market reasons, while being externally viewed as white or grey market, at worst.

Not that that's not what's happening here with the prirate app stores in China that are using voluntary enterprise enrollment in order to install pirate copies of apps on peoples iPhones.

No. Anyone who wants to can put up an Android app store, or sell an android app with malware in it for side-loading onto the Android phone. Android is *much* more vulnerable, depending on who you trust; trust the wrong person/company, and you're compromised.

To get that enterprise provisioning on your iPhone, you have to give up all other enterprise provisioning and sign up as a device enrolled as an "employee" of that App store, and you do it knowing full well that you're doing it to get pirated apps at a cut rate or free pricetag because you are a criminal.

No, you can't. They have to be one of:

(A) signed by Apple (e.g. anything from the App store)
(B) a developer signed binary running on a device enrolled under the developer's key as one of a limited number of devices
(C) enterprise enrolled and signed with the enterprise key

The exploit takes advantage of pirate App stores in china which require you to accept enterprise enrollment in their enterprise key, and then download binaries from their "App Store" after paying a reduced rate for them (they're pirated) that happen to have had malware installed into the app bundle prior to being signed by the enterprise key belonging to the store (and the store is not checking the apps it puts up for sale, because they are all purchased and then uploaded from jailbroken iPhones).

So it takes a lot of work, and most of the people at risk from this are in China and basically stealing Apps.

And controlling access to content. "Oh woe is me! I can watch Dr. Who on the BBC website and you can't! How can I fix it?!?!?".

Hi Ian.

When I was working at Google, I walked over and talked to the developers in person.

They didn't see it as a big problem, and preferred to be able to do static linking, which Apple (where I worked prior to working for Google) prefers you don't do (prefer as in intentionally make it impossible by leaving the necessary bits out of their development tools). It was more or less "irreconcilable difference" territory, even when I offered to do all the necessary dyld/dyle glue code for them (I wrote the kernel exec code on Mac OS X, so I am very familiar with the C runtime code up in user space).

This is a case of a problem they are were unwilling to fix at the time; they may be willing now, but find themselves unable (the code for the runtime interaction with the dynamic binding required for libSystem for a new language binding is pretty dense).

The bottom line is that it's practically useless for the kind of user space code I'd like to be able to write with the language.

For Yahoo or Google, it's pretty easy to do; just call up their business internet services group as if you had a domain being hosted by them. For Hotmail, I have no idea; I'm pretty sure that Microsoft doesn't host third party domains.

But since his problem is going to be DMARC policy plus SPF/DKIM records anyway (which he would have known, if he'd just Googled the problem), it's not going to help him, because he's trying to do something they don't want him to do anyway, and whining about that instead of doing things they way they want him to do them isn't going to change their policy decision, or cause them to make an exception just for him.

The don't give a Flying-F*** about your SPF if your DKIM is wrong or if you are using an @yahoo.com email address.

What they care about is that they've updated their DMARC record to reject @yahoo.com emails in the From: address if they aren't sent by yahoo.com servers.

You should have googled this.

https://help.yahoo.com/kb/mail...

Language bindings still broken on Mac OS.

It's not that surprising, since they implement their own system call stubs, rather than linking the Go runtime against the system C language bindings.

The definition of the system call boundary on Mac OS X is "at the top of libSystem", *NOT* at the user/kernel boundary.

As a consequence, the language bindings used by Go omit information and parameters needed by the actual system calls.

For example, the "kill" system call on Mac OS X takes 3 parameters, while the "kill" libSystem routine is POSIX compliant, and takes two parameters. The third parameter is used to provide a behavioural hint to the OS as to whether you want traditional Mac OS X behaviour, or whether you want strict POSIX behaviour. One of these places is where a signal is sent to a process group of which the sender is a member (done by using a negative PID to indicate via the sign bit that the PID is actually a PGROUP).

What that means is that whatever the hell happens to be in the third parameter register determines whether sending a kill to your own PGROUP also sends the kill to yourself (POSIX) or you sit around on your thumb waiting for a kill that's never going to come, because you wrote to the POSIX behaviour, but selected the traditional Mac OS X behaviour instead.

There are about 40 of these "gotcha's" in the Go use of direct system call bindings that the Go developers failed to take into account on Mac OS X; I can only believe that there are similar issues on other platforms (mostly because I know of two of those issues on BSD platforms).

It's pretty much a given that composite APIS that use descriptors to avoid changing the user visible implementation underlying the upper level code (based on a contract change between the C library and the kernel, without a contract change between the C library and the application) also fall into that category. This includes most of the pthread_attr_t using/providing APIs, posix_spawn, POSIX semaphores, and so on.

I have a great deal of respect for Rob Pike as a language designer, but I have to say, the way language bindings have been handled in Go is pretty abysmal.

Only if by "biology is hard to change" you are referring to the biological fact of who your parents are, rather than race. I agree that you can't pick your relatives, but I don't see that as being meaningful to the discussion.

The study was over sending out resumes with various names on them, and the likelihood of a callback for an interview. It had nothing to do with actual race, and to the extent that it had anything to do with race, rather than economic class at all, then it was about "*perceived* race of a given name".

NB: Others have made cogent arguments that the names selected gave economic and social class indicators, and that it was in fact a class bias rather than a race bias, and that the white male would have been just as discriminated against had the name they used for that subject been, for example, "Jethro Bodine" instead.

If your perceived race based on your name is a problem - *change it!*, and by doing so, change that perception. Once you have the call back, it's too late for them to be racist in that part of the hiring process.

Let me be the first to welcome Google to these 100 cities!

Should you? No. Do children have to pay for their parents poor decisions anyway? Yes, all the damn time.

From fetal alcohol syndrome, to asthma and other health problems from second hand smoke, to childhood obesity, to living one block into the wrong zoning area resulting in a bad school district vs. a good one, to a lack of delayed gratification causing privation due to larger than sustainable family size.

So yes: all the damn time. Children pay for poor parental decisions.

Because this conversation has already given up on that idea by declaring discrimination *so* completely systemic that having the wrong name is enough to prevent you getting 50% of normal callbacks on job applications. The reductio ad absurdum of that position is that you change your name, or get yourself the right nickname, and your job prospects will improve.

Because, you know, we are all, after all, defined by our jobs and the amount of money we do or don't make.

The human race is saved!

If no one else does anything about global climate change, at least the human race will survive in Denmark!

You know ... because of microclimates ... and stuff ...

So the fix is simple, right?

Pick the right names for your kids; problem solved.