Apart from the "someone's basement", as objected to in this thread, it also doesn't say they acquired "commodity hardware"; I took it to suggest the opposite, presumably for good reason.
> it also doesn't say they acquired "commodity hardware"; I took it to suggest the opposite, presumably for good reason.
This seems entirely like wishful thinking. They were using a 12 year old server that was increasingly unfit for the day-to-day task of building Android applications. It doesn't seem like they were in a position to acquire and deploy any exotic hardware (except to the extent that really old hardware can be considered exotic and no longer a commodity). I'd be surprised if the new server is anything other than off the shelf x86 hardware, and if we're lucky then maybe they know how to do something useful with a TPM or other hardware root of trust to secure the OS they're running on this server and protect the keys they're signing builds with.
I'm just reading what was written, especially "the specific components we needed", and assuming they're not as incompetent as is being suggested, given they've served me well. Perhaps you haven't been tendering for server hardware recently, even bog-standard stuff, and seen the responses that even say they can't quote a fixed price currently. At least, that's in my part of the world, in an operation buying a good deal of hardware. We also have systems over ten years old running.
In most of the cases I've seen where people felt the need for intrinsics, GCC will vectorize it -- at least if it's allowed to use the same potentially-incorrect semantics as the intrinsics version -- and potentially for multiple micro-architectures with GCC's target_clones attribute. GCC's -fopt-... flags can give you a lot of information on vectorization and other optimizations, if maybe couched in somewhat compiler-internal jargon, and other compiler probably do something similar. Vectorizing compilers have existed for 50-ish years, so it's well-established stuff.
No, see (even the new) Fowler's Modern English Usage. British usage is -yse, but right-and-proper Oxford spelling uses -ize, not -ise, for words with a Greek root.
1970s-ish capability systems with support in hardware/firmware include CAP, Flex, System/38, Plessey System 250 (which a former colleague worked on) -- the last two commercial; see https://en.wikipedia.org/wiki/Capability-based_security.
I'd like to think their time has come, given vulnerabilities I see.
Not relevant to GCC, but one use for an old A68 compiler was apparently to be adapted for the old NA Software Fortran 90 compiler, I was told by a former colleague. I'd have expected Ada to be a closer fit, and I don't know how well the decision worked out.
It's worth noting that Stallman had earlier proposed a design for Emacs "to handle all the world's alphabets and word signs" with similar requirements to UTF-8. That was the etc/CHARACTERS file in Emacs 18.59 (1990). The eventual international support implemented in Emacs 20's MULE was based on ISO-2022, which was a reasonable choice at the time, based on earlier Japanese work. (There was actually enough space in the MULE encoding to add UTF-8, but the implementation was always going to be inefficient with the number of bytes at the top of the code space.)
AD was invented by Microsoft, gluing together Kerberos (from MIT) and LDAP (from UMich). If it was from MIT, we wouldn't have had Windows 2000's infamous proprietary PAC.
Apart from the "someone's basement", as objected to in this thread, it also doesn't say they acquired "commodity hardware"; I took it to suggest the opposite, presumably for good reason.