No, what Tim Cook said was, "Although we didn’t have a chance to talk about a new Mac Pro at today’s event, don’t worry as we’re working on something really great for later next year." -- that's not saying Apple will release a new Mac Pro; they're working on something different that they think pros will like (or put up with, like Final Cut Pro X).
And, of course, it's also not saying that Apple won't release a new Mac Pro. It's playing its cards a bit close to the chest, which is a bit surprising, as Apple have traditionally been known for being very open about its future plans.:-)
Back when only corporations had computers, Jobs and Woz came out with a computer for the average person.
Smartphones and tablets are almost completely under the control of corporations,
I'm probably missing the snark there, but if you're being serious, "completely under the control of corporations", in that you get what {Apple, Samsung, etc.} make and don't get a choice, is different from "only corporations had computers". Note, BTW, that "...the computer for the rest of us"...
so maybe it's time for somebody to come out with one that is modular, that the average person can build and have full control over.
I would buy one.
...wasn't exactly "one that is modular, that the average person can build and have full control over"; the original Mac was a bit of a sealed box.
I doubt the average person gives a damn about being able to build their own smartphone, even if it were possible to make one that "the average person can build" (electronics manufacturing is a bit more complicated than back in the 1970's).
Turn the ringer off, and don't hook up an answering machine or voicemail. It's still available for an emergency, or to make local and toll-free calls (if conserving cell minutes is a concern).
...and for giving out as a phone number to organizations that require you to provide a phone number when buying from/donating to them online. Then they can call a phone that's never answered. (We left voicemail in place, just in case, and just delete all the hangups - presumably somebody hung up when they got the "leave a message" prompt.)
Perhaps you need to install some "32-bit development support on 64-bit machines" package(s). (My test was on OS X, where there are no special packages of that sort; there's only one set of header files, with #ifdefs used in those cases where you have to do things differently on different platforms, and with libraries distributed as fat binaries; lacking fat binaries, and having a somewhat larger set of platforms to support, Linux distributions may not make 32-bit-target-on-64-bit-host work by default.)
The ABI has to change to change the datatype of time_t.
Does not.
That depends on what you consider a change.
For example, a struct stat contains several time_t values; if the size of time_t changes, the layout of that structure changes, and a program that calls stat() passing it a structure with the layout for 32-bit time_t will not work very well if stat() fills in a structure with the layout for 64-bit time_t.
You could use a similar technique to what Apple did for a number of structure changes, and have a bunch of stat$xxx routines, with different struct stat structures, and hacks to arrange that calls to stat() get turned into calls of the appropriate routine, depending on whether you compile with the "64-bit time_t" flag or not. This doesn't change the ABI for existing routines, although it does introduce new routines to the ABI.
Or you could ship two 32-bit sets of system dynamically-linked libraries, one for 32-bit time_t and one for 64-bit time_t, at which point there's no such thing as "the ABI" or even "the 32-bit ABI", there are two 32-bit ABIs.
If not, then, at least for dynamically-linked binaries, changing the size of time_t, and shipping systems with 32-bit system libraries that expect time_t to be 64-bit, will break binary compatibility.
This is where the "compiler switch" comes in.
This is where the "compiler switch" and library work come in.
time_t was 32-bits on windows until Microsoft updated their compiler to make it 64-bits without breaking compatibility.
Microsoft have the advantage that, as far as I know, no "system APIs" use time_t, so it's used only by the C library and maybe some third-party libraries; I have the impression that executables are either statically linked with the C library or ship with a C library DLL. The "system APIs" are exported by libraries such as kernel32.dll, user32.dll, and the like, and those libraries define the ABI.
Unixland works differently; "system APIs" do use time_t, so either you'd have to statically link with the libraries that provide those ABIs (not supported at all on OS X, doable but no guarantee of binary compatibility on Solaris, dunno what's done on other commercial UN*Xes, dunno how binary-only applications are shipped for various Linux distributions), or you'd have to ship dynamically-linked versions of those libraries (which would still mean you're shipping code that makes assumptions about the implementations of those APIs that are not guaranteed to remain valid from release to release), ship only binaries that work with the 64-bit-time_t 32-bit ABI, or ship both binaries that work with the 64-bit-time_t and the 32-bit-time_t version of the 32-bit ABI.
The first of those is won't work at all on OS X, and is not guaranteed to work from release to release on some platforms. The second of those isn't guaranteed to work from release to release on some platforms, either.
And, unless there's some reason to expect people to care about running 32-bit versions of your application at a time when they need a 64-bit time_t, or you don't have the resources to make your application work in 64-bit mode, you might just want to ship a 64-bit version and be done with it, in which case the vendor might simply not have a strong reason to bother providing that 64-bit-time_t 32-bit ABI.
If a system has 32 bit words, but handles 64 bit nubmers (i.e. starting somewhere in the i386-i586 range? of x86), it's negligably slower. If, however, it has to be emulated via the use of 2 32 bit nubmers...
Then at minimum, you need to perform the op twice.
Then there's overflow checking and handling, 2 more ops, one of which is a branch... or if neither is a branch, the branch will be a third op.
Not in C, there isn't.
so 4-5 ops instead of one, one of which would be a branch.
$ cat foo.c unsigned long long foo(unsigned long long a, unsigned long long b) { return a + b; }
unsigned int bar(unsigned int a, unsigned int b) { return a + b; } $ gcc -m32 -S -O2 foo.c $ cat foo.s .section __TEXT,__text,regular,pure_instructions .globl _foo .align 4, 0x90 _foo: pushl %ebp movl %esp, %ebp movl 16(%ebp), %eax movl 20(%ebp), %edx addl 8(%ebp), %eax adcl 12(%ebp), %edx popl %ebp ret
Nonsense the ABI does not have to break to change the datatype of time_t.
The ABI has to change to change the datatype of time_t.
It can be patched in the compiler with a switch.
And that will magically cause all existing binaries (the "B" in "ABI") to be recompiled to have a 64-bit time_t? If not, then, at least for dynamically-linked binaries, changing the size of time_t, and shipping systems with 32-bit system libraries that expect time_t to be 64-bit, will break binary compatibility.
$ g++ -m32 -Wall -O3 time_t.C In file included from/usr/include/c++/4.7/x86_64-linux-gnu/32/bits/os_defines.h:40:0, from/usr/include/c++/4.7/x86_64-linux-gnu/32/bits/c++config.h:414, from/usr/include/c++/4.7/ctime:43, from time_t.C:1:/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory compilation terminated.
OK, let's try C, instead (I got a linker error when I tried that on my 64-bit Ubuntu 12.04 virtual machine):
$ ed time_t.c time_t.c: No such file or directory a #include <stdio.h> #include <time.h>
int main(void) { printf("On this machine, time_t is %zu bits\n", sizeof(time_t)*8); return 0; } . w 136 q $ gcc -m32 time_t.c $./a.out On this machine, time_t is 32 bits
Even 64-bit isn't good enough to be universal time. It's resolution is one second, so it's useless when trying to measure things less than that.
That's what, for example, struct timeval is for. It's 96-bit on most if not all 64-bit platforms (64 bits of seconds-since-the-Epoch, 32 bits of microseconds since that second), probably padded to 128 bits by the compiler. struct timespec is similar, but with nanosecond resolution.
Too many programmers want to deal with only one universal time domain, hopefully with routines built into their system already so that they don't have to think about it.
You mean like "seconds-since-the-epoch and fractions of a second since the second in question"?
Personally, I think they should have renamed the Unix routines when they went to 64-bit, so that the naive programmer is made aware that this is now a different and distinct time domain.
And it's "now a different and distinct time domain" in what way (other than "it has the same origin, just a bigger range")?
Please note, mainframes and most mini computers went 64 bit in the 1990s. x86 and ARM are the last to do so.
IBM mainframes went 64-bit in 2000. Opteron came out in 2003, so, yes, x86 went 64-bit after System/3x0 did (by 3 years). However, System/3x0 (feel free to set x = 10 for z/Architecture:-)) went 64-bit long after, for example, MIPS did.
But, yes, at least for non-embedded computing, we probably won't have a lot of 32-bit machines, and most if not all 64-bit software platforms that have time_t have a 64-bit time_t.
A quick check of my Solaris 11 (virtual) machine's/usr/include indicates that it defines time_t as a long, so it's 64 bits only for 64-bit code (can't break binary compatibility...), so only 64-bit code avoids the Y2.038K problem on Solaris. A quick check of that machine's host, running OS X Mountain Lion, reveals the same thing (again, can't break binary compatibility...), so only 64-bit code avoids the Y2.038K problem on OS X.
I'm not certain what headers are used when compiling 32-bit on, for example, my (64-bit) Ubuntu 12.04 (virtual) machine, but, if I compile a program that prints sizeof(time_t) with -m32, it prints 4.
So, on two fairly significant UN*Xes, time_t appears to be 64-bit only for 64-bit code. Now, it may well be that, well before 2038, for desktop and server computing, and possibly even smartphone/tablet computing, all libraries and applications will be 64-bit.
However...
So it's not a real problem even on embedded systems
...I wouldn't necessarily assume that. The good news is that truly embedded systems (I don't consider smartphones etc. to be embedded systems, as, even if they don't support development tools running on them, they can run third-party applications, and thus might be subject to binary-compatibility issues) don't have the sort of binary-compatibility issues that would force them to keep time_t 32-bit. However, if they're running a software platform that, by default, makes time_t 32-bit on 32-bit processors, unless they've made an effort to override that default, time_t is 32-bit. Hopefully the lifetime of those embedded systems is sufficiently short (and the developers of those systems sufficiently clueful) that anything with 32-bit time_t gets replaced in time.
All that over and above...
However, even those compiled with 64-bit time_t aren't necessarily safe - you'd probably find most of them assume it's still a 32-bit quantity and end up storing it as such - ignoring the compiler warnings or casting to get rid of them. So even programs of today with 64-bit time_t's won't necessarily make it past 2038 either.
And if stuff like that is done, recompiling does diddly - the bug will still strike despite a 64-bit everything. Hell, someone may have decided during the conversio nto increase the timestamp size from 32 to 64 bit, but didn't realize someone squashed it down to 32-bit upstream.
...what you've already noted, in addition to file formats with 32-bit time stamps (e.g., pcap format; fortunately, pcap-ng format can, with time stamps with nanosecond resolution, last until 2554).
Does the article say if he also plans to clone a bride for him?
TFA (here's the English-language version, although from your name and earlier comments I'm guessing you might be German-speaking and thus don't need a translation) says:
SPIEGEL: How do we have to imagine this: You raise Neanderthals in a lab, ask them to solve problems and thereby study how they think?
Church: No, you would certainly have to create a cohort, so they would have some sense of identity. They could maybe even create a new neo-Neanderthal culture and become a political force.
It means that if we pretend that we don't have a massive income disparity in this country, and that this disparity is causing our educational system to fail, we can then pretend that everything is just fine, right up until the resulting educational problems start causing our national economy to falter and our democratic institutions to become non-functional.
I think what it's intended to mean is, as per the conclusions in the paper, that if we ignore differences in the level of inequality, and assume that the problem is solely that "our schools are failing" (other than "failing" to sufficiently compensate for inequality), we're not necessarily going to be able to improve our standing - maybe we should be spending more effort elsewhere. (The Economic Policy Institute's about page indicates that they're a center-left think tank, so that's not a surprising message.)
(I didn't check all the pages to make sure the HTML version was complete - the last page of the PDF says "page 99" - but I did a quick-and-dirty hack, wherein I selected all the text in the HTML version, copied it and pbpasted it to a file, did the same with the PDF version, applied a tr hack (tr -cs "[:alpha:]" "\n", as per the man page), and then ran wc -w on both files; it reported 45040 for the HTML version and 45596 for the PDF version, so, unless one of those steps severely mangled the document, they're probably the same.)
Copper wire was invented by two Checkpoint* developers fighting over a penny.
The CEO of a company at which I worked, who had a Dutch last name (I don't know how many generations back his Dutch ancestors arrived in the US) told the same joke, but it was "two Dutchmen..." Googling also finds "Scotsmen" and "lawyers" used.
This is nothing about DNS. The slippery slope argument (for good or ill) the major Internet powers used to justify refusal is that treaty language implies that signatory governments have a mutual international obligation to do content monitoring (e.g., deep packet inspection). These clauses were argued to be non-content-neutral, and (for instance) coud allow Iran to insist that the US prohibit blastphemous content (for Shiite Muslim definitions of "blastphemy").
The worst part about that particular complaint is that there is nothing about the internet that requires that other countries use the US's root DNS servers. They are free to implement their own.
The problem is that the root zone is controlled by the US Department of Commerce ("National Telecommunications and Information Administration (NTIA) - which is an office within the United States Department of Commerce - authorizes changes to the root"), so their root servers serve up information that's ultimately US-controlled.
Slashdot Mirror
No, what Tim Cook said was, "Although we didn’t have a chance to talk about a new Mac Pro at today’s event, don’t worry as we’re working on something really great for later next year." -- that's not saying Apple will release a new Mac Pro; they're working on something different that they think pros will like (or put up with, like Final Cut Pro X).
And, of course, it's also not saying that Apple won't release a new Mac Pro. It's playing its cards a bit close to the chest, which is a bit surprising, as Apple have traditionally been known for being very open about its future plans. :-)
Back when only corporations had computers, Jobs and Woz came out with a computer for the average person.
Smartphones and tablets are almost completely under the control of corporations,
I'm probably missing the snark there, but if you're being serious, "completely under the control of corporations", in that you get what {Apple, Samsung, etc.} make and don't get a choice, is different from "only corporations had computers". Note, BTW, that "...the computer for the rest of us"...
so maybe it's time for somebody to come out with one that is modular, that the average person can build and have full control over.
I would buy one.
...wasn't exactly "one that is modular, that the average person can build and have full control over"; the original Mac was a bit of a sealed box.
I doubt the average person gives a damn about being able to build their own smartphone, even if it were possible to make one that "the average person can build" (electronics manufacturing is a bit more complicated than back in the 1970's).
Turn the ringer off, and don't hook up an answering machine or voicemail. It's still available for an emergency, or to make local and toll-free calls (if conserving cell minutes is a concern).
...and for giving out as a phone number to organizations that require you to provide a phone number when buying from/donating to them online. Then they can call a phone that's never answered. (We left voicemail in place, just in case, and just delete all the hangups - presumably somebody hung up when they got the "leave a message" prompt.)
The result I expected was that time_t is 64 bits even in 32 bit ABI for new code.
And you now know that OS X and Linux work the same here (32-bit ABI has 32-bit time_t).
fail in 32 bit mode.
So what are the errors you see?
Perhaps you need to install some "32-bit development support on 64-bit machines" package(s). (My test was on OS X, where there are no special packages of that sort; there's only one set of header files, with #ifdefs used in those cases where you have to do things differently on different platforms, and with libraries distributed as fat binaries; lacking fat binaries, and having a somewhat larger set of platforms to support, Linux distributions may not make 32-bit-target-on-64-bit-host work by default.)
The ABI has to change to change the datatype of time_t.
Does not.
That depends on what you consider a change.
For example, a struct stat contains several time_t values; if the size of time_t changes, the layout of that structure changes, and a program that calls stat() passing it a structure with the layout for 32-bit time_t will not work very well if stat() fills in a structure with the layout for 64-bit time_t.
You could use a similar technique to what Apple did for a number of structure changes, and have a bunch of stat$ xxx routines, with different struct stat structures, and hacks to arrange that calls to stat() get turned into calls of the appropriate routine, depending on whether you compile with the "64-bit time_t" flag or not. This doesn't change the ABI for existing routines, although it does introduce new routines to the ABI.
Or you could ship two 32-bit sets of system dynamically-linked libraries, one for 32-bit time_t and one for 64-bit time_t, at which point there's no such thing as "the ABI" or even "the 32-bit ABI", there are two 32-bit ABIs.
If not, then, at least for dynamically-linked binaries, changing the size of time_t, and shipping systems with 32-bit system libraries that expect time_t to be 64-bit, will break binary compatibility.
This is where the "compiler switch" comes in.
This is where the "compiler switch" and library work come in.
time_t was 32-bits on windows until Microsoft updated their compiler to make it 64-bits without breaking compatibility.
Microsoft have the advantage that, as far as I know, no "system APIs" use time_t, so it's used only by the C library and maybe some third-party libraries; I have the impression that executables are either statically linked with the C library or ship with a C library DLL. The "system APIs" are exported by libraries such as kernel32.dll, user32.dll, and the like, and those libraries define the ABI.
Unixland works differently; "system APIs" do use time_t, so either you'd have to statically link with the libraries that provide those ABIs (not supported at all on OS X, doable but no guarantee of binary compatibility on Solaris, dunno what's done on other commercial UN*Xes, dunno how binary-only applications are shipped for various Linux distributions), or you'd have to ship dynamically-linked versions of those libraries (which would still mean you're shipping code that makes assumptions about the implementations of those APIs that are not guaranteed to remain valid from release to release), ship only binaries that work with the 64-bit-time_t 32-bit ABI, or ship both binaries that work with the 64-bit-time_t and the 32-bit-time_t version of the 32-bit ABI.
The first of those is won't work at all on OS X, and is not guaranteed to work from release to release on some platforms. The second of those isn't guaranteed to work from release to release on some platforms, either.
And, unless there's some reason to expect people to care about running 32-bit versions of your application at a time when they need a 64-bit time_t, or you don't have the resources to make your application work in 64-bit mode, you might just want to ship a 64-bit version and be done with it, in which case the vendor might simply not have a strong reason to bother providing that 64-bit-time_t 32-bit ABI.
Different domain because they cover a different range
With the same origin, just different limits.
aren't interchangeable
32-bit time_t can be trivially converted to 64-bit time_t.
and were intended for different purposes.
No, they aren't.
Oh, and...
depends.
If a system has 32 bit words, but handles 64 bit nubmers (i.e. starting somewhere in the i386-i586 range? of x86), it's negligably slower.
No, nothing was added to support doing 64-bit adds in a single instruction until x86-64.
depends.
If a system has 32 bit words, but handles 64 bit nubmers (i.e. starting somewhere in the i386-i586 range? of x86), it's negligably slower. If, however, it has to be emulated via the use of 2 32 bit nubmers...
Then at minimum, you need to perform the op twice. Then there's overflow checking and handling, 2 more ops, one of which is a branch... or if neither is a branch, the branch will be a third op.
Not in C, there isn't.
so 4-5 ops instead of one, one of which would be a branch.
So more like four instructions instead of 2 ("pushl %ebp; movl %esp, %ebp" is the function prolog, and "popl %ebp; ret" is the function epilog).
Nonsense the ABI does not have to break to change the datatype of time_t.
The ABI has to change to change the datatype of time_t.
It can be patched in the compiler with a switch.
And that will magically cause all existing binaries (the "B" in "ABI") to be recompiled to have a 64-bit time_t? If not, then, at least for dynamically-linked binaries, changing the size of time_t, and shipping systems with 32-bit system libraries that expect time_t to be 64-bit, will break binary compatibility.
Sorry, no workie....
OK, let's try C, instead (I got a linker error when I tried that on my 64-bit Ubuntu 12.04 virtual machine):
Even 64-bit isn't good enough to be universal time. It's resolution is one second, so it's useless when trying to measure things less than that.
That's what, for example, struct timeval is for. It's 96-bit on most if not all 64-bit platforms (64 bits of seconds-since-the-Epoch, 32 bits of microseconds since that second), probably padded to 128 bits by the compiler. struct timespec is similar, but with nanosecond resolution.
Too many programmers want to deal with only one universal time domain, hopefully with routines built into their system already so that they don't have to think about it.
You mean like "seconds-since-the-epoch and fractions of a second since the second in question"?
Personally, I think they should have renamed the Unix routines when they went to 64-bit, so that the naive programmer is made aware that this is now a different and distinct time domain.
And it's "now a different and distinct time domain" in what way (other than "it has the same origin, just a bigger range")?
Please note, mainframes and most mini computers went 64 bit in the 1990s. x86 and ARM are the last to do so.
IBM mainframes went 64-bit in 2000. Opteron came out in 2003, so, yes, x86 went 64-bit after System/3x0 did (by 3 years). However, System/3x0 (feel free to set x = 10 for z/Architecture :-)) went 64-bit long after, for example, MIPS did.
But, yes, at least for non-embedded computing, we probably won't have a lot of 32-bit machines, and most if not all 64-bit software platforms that have time_t have a 64-bit time_t.
The time_t was, in many cases, switched to 64bit even in 32bit OSs.
And, in other cases, apparently not switched to 64-bit on 32-bit platforms.
time_t has also been 64 bit for a number of years now
...on most (all?) 64-bit platforms and on those 32-bit platforms that have gone with 64-bit time_t .
At least as I read the Visual Studio 2012 documentation, time_t is 64-bit by default; you have to define _USE_32BIT_TIME_T to get a 32-bit time_t. This goes back as far as Visual Studio 2005; in Visual Studio .NET 2003, it's a "long integer", which is 32 bits in Microsoftland.
A quick check of my Solaris 11 (virtual) machine's /usr/include indicates that it defines time_t as a long, so it's 64 bits only for 64-bit code (can't break binary compatibility...), so only 64-bit code avoids the Y2.038K problem on Solaris. A quick check of that machine's host, running OS X Mountain Lion, reveals the same thing (again, can't break binary compatibility...), so only 64-bit code avoids the Y2.038K problem on OS X.
I'm not certain what headers are used when compiling 32-bit on, for example, my (64-bit) Ubuntu 12.04 (virtual) machine, but, if I compile a program that prints sizeof(time_t) with -m32, it prints 4.
So, on two fairly significant UN*Xes, time_t appears to be 64-bit only for 64-bit code. Now, it may well be that, well before 2038, for desktop and server computing, and possibly even smartphone/tablet computing, all libraries and applications will be 64-bit.
However...
So it's not a real problem even on embedded systems
...I wouldn't necessarily assume that. The good news is that truly embedded systems (I don't consider smartphones etc. to be embedded systems, as, even if they don't support development tools running on them, they can run third-party applications, and thus might be subject to binary-compatibility issues) don't have the sort of binary-compatibility issues that would force them to keep time_t 32-bit. However, if they're running a software platform that, by default, makes time_t 32-bit on 32-bit processors, unless they've made an effort to override that default, time_t is 32-bit. Hopefully the lifetime of those embedded systems is sufficiently short (and the developers of those systems sufficiently clueful) that anything with 32-bit time_t gets replaced in time.
All that over and above...
However, even those compiled with 64-bit time_t aren't necessarily safe - you'd probably find most of them assume it's still a 32-bit quantity and end up storing it as such - ignoring the compiler warnings or casting to get rid of them. So even programs of today with 64-bit time_t's won't necessarily make it past 2038 either.
And if stuff like that is done, recompiling does diddly - the bug will still strike despite a 64-bit everything. Hell, someone may have decided during the conversio nto increase the timestamp size from 32 to 64 bit, but didn't realize someone squashed it down to 32-bit upstream.
...what you've already noted, in addition to file formats with 32-bit time stamps (e.g., pcap format; fortunately, pcap-ng format can, with time stamps with nanosecond resolution, last until 2554).
Does the article say if he also plans to clone a bride for him?
TFA (here's the English-language version, although from your name and earlier comments I'm guessing you might be German-speaking and thus don't need a translation) says:
Asgard's a place name. You're thinking of Æsir.
Or not.
It means that if we pretend that we don't have a massive income disparity in this country, and that this disparity is causing our educational system to fail, we can then pretend that everything is just fine, right up until the resulting educational problems start causing our national economy to falter and our democratic institutions to become non-functional.
I think what it's intended to mean is, as per the conclusions in the paper, that if we ignore differences in the level of inequality, and assume that the problem is solely that "our schools are failing" (other than "failing" to sufficiently compensate for inequality), we're not necessarily going to be able to improve our standing - maybe we should be spending more effort elsewhere. (The Economic Policy Institute's about page indicates that they're a center-left think tank, so that's not a surprising message.)
If one were to rank comparable classes between the U.S. and the rest of the world, U.S. scores would rise to 4th from 14th in reading (PDF) and to 10th from 25th in math."
Or, if you prefer:
The HTML version includes some links, including a link to a response to a PISA response to the paper, including the PISA response itself (PDF).
(I didn't check all the pages to make sure the HTML version was complete - the last page of the PDF says "page 99" - but I did a quick-and-dirty hack, wherein I selected all the text in the HTML version, copied it and pbpasted it to a file, did the same with the PDF version, applied a tr hack (tr -cs "[:alpha:]" "\n", as per the man page), and then ran wc -w on both files; it reported 45040 for the HTML version and 45596 for the PDF version, so, unless one of those steps severely mangled the document, they're probably the same.)
what use is a tiny computer without a way of controlling it?
What, Bluetooth doesn't count?
At least I was only circumcised so that I'd only feel pain from just my genitals and never pleasure.
I'm sorry your circumcision was so badly botched. It's probably too late to sue for malpractice, unfortunately.
Copper wire was invented by two Checkpoint* developers fighting over a penny.
The CEO of a company at which I worked, who had a Dutch last name (I don't know how many generations back his Dutch ancestors arrived in the US) told the same joke, but it was "two Dutchmen..." Googling also finds "Scotsmen" and "lawyers" used.
On Mac OS X, Unix is a whole lot of Objective-C.
...except for the parts that actually implement Unix behavior, which are mostly C with some amount of C++ and perhaps a small amount of Objective-C.
This is nothing about DNS. The slippery slope argument (for good or ill) the major Internet powers used to justify refusal is that treaty language implies that signatory governments have a mutual international obligation to do content monitoring (e.g., deep packet inspection). These clauses were argued to be non-content-neutral, and (for instance) coud allow Iran to insist that the US prohibit blastphemous content (for Shiite Muslim definitions of "blastphemy").
As per this post at the Center for Democracy and Technology, there's an ITU-T Recommendation "Y.2770: Requirements for Deep Packet Inspection in Next Generation Networks", which is "restricted to TIES users", where "TIES (Telecommunication Information Exchange Service) is a set of networked information resources and services offered by ITU without any charge to ITU Members (Member States, Sector Members, Associates, and Academia) to support their participation in the activities of the Union." Not being a Member State, a Sector Member, an Associate, or a member of Academia, I have no idea what that recommendation says; it might be Very Nice if somebody who did have access to it were to upload it to wcitleaks.org.
The worst part about that particular complaint is that there is nothing about the internet that requires that other countries use the US's root DNS servers. They are free to implement their own.
And many of them have..
The problem is that the root zone is controlled by the US Department of Commerce ("National Telecommunications and Information Administration (NTIA) - which is an office within the United States Department of Commerce - authorizes changes to the root"), so their root servers serve up information that's ultimately US-controlled.