That's very variable. In most places with reasonable levels or regulation, taxi meters are independently regulated subject to random inspection. If the meter isn't showing the correct value, the driver or taxi company can be fined or lose their license. In London, there are 'mystery shoppers' who are paid to take trips in black cabs and can take away the driver's taxi license on the spot if he doesn't go the best route (including avoiding roads with roadworks).
A lot of taxi regulation revolves around identifying ways in which taxis cheat their customers and either providing counter incentives or enforcement to prevent this. Uber has apparently failed to learn lessons that the rest of the industry has spent a century learning.
I've only used Uber once, but I thought a big part of the appeal was that it quoted you the price up-front and it then didn't matter what route the driver took or how busy it was, you paid the same amount? Does the Lagos version charge you per mile instead?
I have a colleague working on formal verification of WebAssembly. Part of this has involved fuzzing various WebAssembly implementations. There are a lot of bugs in all of them, though Edge is by far the worst (reproduceable crashes are hard, because it crashes randomly on most of his test inputs, but at different points).
It's also a pretty horrible design. It's replaced HSAIL as my go-to example for how not to design a good IR.
One thing I forgot to mention: move semantics now mean that it's possible to sensibly use generic containers without having copying semantics. One of the problems with C++98 was that you ended up with a lot of copies for safe code. If you want to put objects into something like a std::vector or std::map, then you had to either copy, or use raw pointers and worry about memory management. With move semantics, you can either move the objects (e.g. for a string you copy the pointer to the buffer and the length and invalidate the old one), or you can use smart pointers. This alone makes C++11 a far better language than C++98 - lots of things that should have always been easy to express now actually are.
I think the point I was trying to make is that many C programmers are conditioned to know that macros can be bloaty. Usually the programmer knows up front that speed or size is important. My experience is that many C++ programmers are conditioned to work fast, and not worry about size or speed because there's always a bigger and faster processor coming soon. I'm not trying to say that all the programmers are this way, but it's a distinct trend I've seen.
I think that's more a function of target rather than language. Programmers writing for resource-constrained environments quickly learn which language features consume those resources quickly. Even on big machines, instruction cache is a fairly scarce resource, so avoiding code size increases on hot paths is important.
I've seen the "one tool fits all" style of thinking in C++ a lot. Ie, if you've got std::map, then that's all you need.
I've seen exactly the same from C programmers. The 4BSD collections (now in Linux, *BSD, and Windows NT kernels) or the UT* ones are the solution to all problems. And that's not a bad thing if it's for prototyping.
if you've got std::map, then that's all you need. I saw someone implement something that should have just been a simple array lookup, a small fixed size array of 5 elements, which could have been done in plain C; but he used std::map for this which made it larger and slower and took more programmer time. Even std::vector would have been preferable. And the programmer knew that space was at a premium.
The nice thing about using a std::map here is that, if you use a typedef or an equivalent using directive, you can replace it with a class that wraps std::array and does linear search without modifying any of the code that uses it. In C, this is much harder to do without your code becoming ugly.
I do like templates if used sparingly and not in an STL style where whole objects are copied into containers instead of just pointers or references. I've used templates that just provided pointer type safety with a more generic underlying library that took void*. I used to like the RogueWave C++ classes, until the STL took hold.
STL was an SGI product, but I'll assume you mean the C++ standard library. There's nothing that requires copying in any of the standard library classes. you need to think about ownership if you use them to store pointers (or references), but you can also use them to store smart pointers and with unique_ptr you get ownership semantics along with no copying (and no run-time overhead). The addition of move semantics in C++11 also means that you can move objects, rather than copying them, so if your object is a small structure containing pointers to something large then the cost of the move is cheap.
Assuming that the original program ran on an x86 PC. Getting data out of programs that only ran on a PowerPC Mac is much harder, though older systems (e.g. most m68k systems, such as Amigas and older Macs) were sufficiently simple that there are now emulators that have decent performance. Unless, of course, the program in question relied on some copy protection mechanism that doesn't work with the emulator. Try getting anything that had a parallel-port dongle to work in DOSBox, for example.
Even then, just being able to read the data in a VM or emulator isn't always that useful - you want to translate it to some other form and so you end up needing a chain of import-export programs, and finding the middle ones can be difficult. I have a bunch of ClarisWorks 1 documents and if I ever want to import them into something new then I think I will need to find a copy of ClarisWorks 3, which can both open them and save in a format that the latest AppleWorks (which still runs in Rosetta on an older OS X on an x86 Mac) can open, and then export them into something else that's actually readable on a modern system. For the word processor documents, ClarisWorks 3 can save them in a format that a modern version of Word can open (ClarisWorks 1 couldn't), though likely with a loss of formatting, but most of them were from the vector graphics program (which worked well as a DTP program, because the text boxes embedded all of the functionality of the word processor) and I've no idea what the path for opening them on a modern system is. Fortunately, I don't really care about most of them.
There are two reasons to avoid the public domain, though they're largely been relaxed over time. The first is that most software licenses include an explicit disclaimer of liability. If you put something in the public domain then you are not providing that, so though you waive the right to sue over copyright infringement no one else waives the right to sue you. That said, I don't believe that there's been a single lawsuit over merchantability of public domain code, and I'd be surprised if one didn't get laughed out of court.
The other is that some jurisdictions either don't recognise that public domain exists, or recognise it only as the state into which works fall after the copyright expires. In particular, there's a lot of jurisdictional difference over moral rights, which either don't exist at all (much of the US - yes the US has bits of copyright law that vary from state to state), aren't transferrable / waivable, or are simply the same as other rights, so depending on the jurisdiction public domain work may still have strong attribution requirements.
The CC0 license avoids all of these issues and so is generally a better choice if you want to ensure that the rights that the recipient of your code has are the same that they'd have in a common interpretation of what public domain means.
The big change is that there is now, for all *NIX platforms, a stable C++ ABI. The HP Itanium ABI was adopted largely as-is by all *NIX systems (with the slight exception of 32-bit ARM, which does exceptions slightly differently and handles pointers to members differently because the low bit in instruction pointers is already in use for thumb interworking). Variations between archs don't matter too much, but changes within an architecture are problematic because they mean that you can't define long-term-stable interfaces in terms of C++. On Windows, for example, all public interfaces are either C or COM because the MS compiler changes ABI across Visual Studio versions. Apple was bitten by this, because they defined kernel (IOKit) interface in terms of the gcc 2.95 ABI and had a lot of pain to move everything to the Itanium ABI (largely motivated by the fact that clang never supported the old ABI).
On a related note, compilers are a lot better at optimising C++ now than they were 20 years ago. All of the companies that employ a lot of LLVM or GCC developers now have huge internal C++ codebases and care more about the performance of these than of their C code. This is a huge shift from 20 years ago, where C++ was a checklist feature for gcc (clang didn't exist) and no one really cared about C++ performance. 20 years ago, renaming a.c file to.cc and compiling it with gcc would often give you slower code. Now, it will give you exactly the same code and performance doesn't get worse as you use more C++ features. For example, both templates and lambdas rely on the inliner a lot and modern C/C++ compilers have tuned their inliners on this use case more than on common C idioms.
In terms of language features, there are a few big ones. The first is lambdas. These can be used in a lot of places where you'd use macros and generate the same code, but be a lot more readable. The other large feature is the addition of move semantics. This is very important for kernel-style code, where you want to have fine control over memory ownership. Things like the standard library unique_ptr template give you a trivial way of expressing unique ownership in the code, in a way that can be transferred between threads, and compiles down to no code but statically checks that you've followed the correct discipline.
There are a few other things that are pretty useful. Generalised constexpr means that you can write functions that should be evaluable at compile time and you can use a trivial template wrapper to force compile-time evaluation. This is very useful in code where you need to reason about run-time complexity, because you can guarantee that the compiler really will evaluate something at compile time or fail to compile.
For the kernel, the improvements to enums in C++11 can also be useful. You can define enums that are actually type safe (i.e. they're not just the equivalent of #defines of int values and assigning the wrong enum is actually an error) and which have a storage type other than int.
The Linux kernel has a really crappy way of handling memory orderings, which basically rely on having macros that map to the different memory barriers on Alpha and having programmers insert them in the right places, so it's not as well suited as something like FreeBSD to adopting C++11 atomics (FreeBSD provides functions that have almost identical semantics to the C++11 acquire-release model), but adopting it exposes a lot more opportunities for compiler optimisations. The current atomics are all implemented as asm volatile statements, which provide a full compiler barrier (the compiler may not move instructions from one side to the other, even if it would be safe to in the memory model). C11 also has support for this, but it's a really ugly copy and paste of the C++11 stuff to C11 and the standard ends up writing volatile in a bunch of places where it means _Atomic, so using them is painful.
Range-based for loops don't give you anything other
Any language feature can be abused, and C has exactly the same problem: macros can cause code bloat. Correctly used, templates let you provide abstractions that are then specialised and inlined and, after optimisation, become one or two instructions inline, where the C equivalent requires a real function call because it's having to handle the generic use cases in a single place.
Oh, and your example of wanting to use == on strings is a good one. Look at the LLVM StringRef class for an example of how to do this sensibly. It defines a non-owning reference to a string, which is a char* and a length. It has a constructor that takes a const char*, and will generate the relevant memcmp / strcmp calls for comparisons. It's defined in a header and is always inlined, so (with optimisations enabled), StringRef(a) == StringRef(b) will compile to a pair of strlen calls (which would be optimised away for compile-time constant strings), and then a memcmp call (with the shortest length) if the lengths are not both 0. If you're mostly dealing with null-terminated strings, you can avoid the strlen calls by using an equivalent where the length is calculated lazily when required, so this use of == would generate the same code as the C version.
Your argument that programmers don't think too hard about what their code is doing and should therefore use C seems quite horrifying.
I have musicpd on my NAS and I also export my music directory as read-only NFS share. I can then plug in any cheap machine with acceptable sound (or a RPi for rooms where sound quality isn't that big a deal) also running musicpd. There are multiple apps (desktop, web, and mobile) for controlling musicpd and I can configure each one to output as a stream as well as to the local speakers, so that the others can either listen to their own queue or be slaved to another. Musicpd is packaged for just about any OS that you might be running. Adding an NFS import to most *NIX systems is a simple matter of a line in fstab.
There's also one crucial advantage of paper ballots: the expertise required to monitor the election is very low. Even a relatively unpopular candidate is able to find enough people who can watch people put pieces of paper into a box and can watch the boxes for signs of tampering throughout the entire process. You can't have a democracy if the mechanism for collecting and counting the votes can only be audited by a select few experts.
Linus isn't irrationally afraid of C++, he's rationally afraid of the state of C++ 20 years ago. I completely agree with him that C++ was a terrible language 20 years ago. He just hasn't bothered to reevaluate his opinions based on more recent versions of both the standards and compiler ABI stability.
Oh, and you missed the horrible non-typesafe macros (look at the list and queue macros, for example), that provide a crappy version of C++ templates, with all of the disadvantages and a few of the advantages.
It's worth repeating this, because that's the standard for bike locks. They're not intended to be unpickable, they're intended to make the tools and time required to pick them more expensive / heavier / harder than simply cutting the chain. A lot of bike chains can be cut with a pair of bold cutters, the more expensive ones with a hand-held battery-powered disc cutter. With the exception of the cheapest, worst, bike locks, no one will bother to pick them because if they want to steal bikes then they'll just cut the chain.
Or they'll do something a bit more organised. Around here there was a group that came through the city a couple of years back with a low loader and a forklift. They'd go to bike parks where bikes were attached to metal hoops held in the ground with a few metal bolts and lift the whole thing up onto the low loader with the forklift. They could get 40 or so bikes in about 5 minutes, and by the time anyone had reported them they'd be long gone.
Remember how Intel killed off most of the workstation architectures? They produced slower chips, but had a lot more volume and so were able to scale up production, giving them a lot more to invest in R&D. Now look at the ARM ecosystem. There are about half a dozen completely independent implementations of the ISA, all competing, and most with a larger volume than Intel individually.
A modern mobile phone CPU is more than adequate for most laptop users and we're starting to see things like Chromebooks shipping with them. That's how companies like SGI and Sun lost their market share: a competitor comes in at the low end and takes that part of the market, then is able to slowly move up. This isn't a new thing for ARM. They started off in Acorn desktops and Apple handhelds, but for most of their existence they were very low-end embedded systems. ARM chips that have been plausible laptop CPUs are a relatively new thing - even the StrongARM chips from the early 2000s were nowhere near competitive with even low-end Pentiums.
1. I'm assuming no VMWare? How well does Xen run on ARM?
Xen has worked well on AArch64 for a long time. I think KVM also works. Bhyve support is almost there.
Can GCC/CLANG optimize for a server profile? I'm assuming that, until now, all the work for the ARM target has been on code compactness and efficiency over performance.
There's very little work done in the compiler on optimising for power. To a first approximation, the best optimisation for power is to finish quickly and let the CPU sleep. This is exactly the same for server and mobile workloads. There are differences in pipeline design, but the LLVM AArch64 back end already supports pipeline-specific tuning for AArch64 targets ranging from dual-issue in-order to wide superscalar out-of-order, so that shouldn't be a problem. I don't know what the ARM status for GCC is now that ARM, Google, and Apple are all investing almost exclusively in LLVM development, but I'd imagine it's not too different there.
Looks like the chip has plenty of available bandwidth, does it have the transactional horsepower to fill it?
I have no idea about this without more microarchitectural details being published, but there's nothing at the ISA level for AArch64 that would prevent it from scaling up to the kind of desired performance.
Most bike locks are absolute crap, and even I can pick them. Most of the expensive ones take a few minutes for most of the competent people in my local lockpicking group. Some have quite astonishing weaknesses: the older Axa locks could all be unlocked with a key blank, for example. I'd challenge you to name one brand of bike lock that's unpickable - most of the good ones are used in competitions and only take a minute or two for the winner.
The main reason you want something else is that Bluetooth is a lot slower than WiFi. It's fine for individual small files, but if you want to send a video file between two devices, for example, then it's painfully slow. It's similarly slow if you want to copy a full album of music, or even a pile of PDFs. You want a protocol that can do the transfer over WiFi, though I seem to recall that there's a protocol for migrating Bluetooth connections to WiFi, which would work.
IR Link was horrible, because most laptop IR transceivers had a very narrow view. It was sort-of okay for PDAs if you held the PDA directly against the IR port, but impossible to align for a pair of laptops reliably.
Bluetooth file transfer is also pretty mature at this point. I've used it between Windows, Mac, and FreeBSD machines and with old Nokia and new Android phones (it probably works with iOS, though it didn't in the original iPhone). Pairing is a bit annoying, but once that's done it's basically drag and drop.
AirDrop is nice because it uses bluetooth to identify nearby machines and to advertise public keys, but then creates a two-device ad-hoc wireless network and transfers at high speed. WiFi direct now provides a somewhat more standard and mature mechanism for doing this.
I'm quite annoyed that Apple, Microsoft, and Google are all developing independent protocols for this though. I want an open protocol that works with all of my devices, not a mess of protocols where I can use one between my laptop and Android phone, one between my laptop and iPad, none between my iPad and Android phone, a different one between Windows devices, and so on.
Are you sure. These vulnerabilities were all found with the same kernel fuzzing tool that, as far as I know, has not been ported to work on other operating systems. It would be great for someone to run the same thing on *BSD and Windows - similar exploits are almost certainly in all systems, the difference is that the Linux ones are now known and fixed.
Not even original - Microsoft did this for IE talking to IIS. I don't remember the exact details, but they were skipping part of the standard TCP handshake to reduce latency, so pages loaded faster with IE, but only if served from a Windows IIS machine.
The old generation is also clueless about privacy in technology, they just can't get the technology to work well enough to invade their privacy this thoroughly.
I'm not sure if you count it as a UI improvement, but the addition of SmartArt to PowerPoint is a huge improvement and is (I think) only about 10 years old. For anyone who hasn't seen this, it maps from an outline view to one of a few dozen pre-defined diagram types. It's a very quick way of turning a slide of text into a slide in a graphical representation.
I am using a Moto G (first generation). It stopped getting first-party updates after about two years, but it's now 4 years old and is getting regular updates from LinageOS. It's actually faster with the most recent Android than when I bought it (the ART compiler has improved a lot), so I imagine that I'll hang onto it for a long time. I may repurpose it at some point (remove the SIM and it's still a reasonable remote control for music and so on), but I anticipate keeping it for at least a couple more years.
The problem with Apple devices is that, once the first party updates stop coming, you're screwed. There won't be any fixes for exploitable security vulnerabilities, so any use that involves connecting it to a network is out unless you want it to be a possible vector for spreading malware onto your LAN. In contrast, it's possible to unlock the bootloader for most Android devices, so it's possible for third parties to keep supporting them.
Slashdot Mirror
The Internet and over TCP/IP are not the same thing. Most phones are doing VoIP now, but that doesn't mean that it's routed over the public Internet.
That's very variable. In most places with reasonable levels or regulation, taxi meters are independently regulated subject to random inspection. If the meter isn't showing the correct value, the driver or taxi company can be fined or lose their license. In London, there are 'mystery shoppers' who are paid to take trips in black cabs and can take away the driver's taxi license on the spot if he doesn't go the best route (including avoiding roads with roadworks).
A lot of taxi regulation revolves around identifying ways in which taxis cheat their customers and either providing counter incentives or enforcement to prevent this. Uber has apparently failed to learn lessons that the rest of the industry has spent a century learning.
I've only used Uber once, but I thought a big part of the appeal was that it quoted you the price up-front and it then didn't matter what route the driver took or how busy it was, you paid the same amount? Does the Lagos version charge you per mile instead?
I have a colleague working on formal verification of WebAssembly. Part of this has involved fuzzing various WebAssembly implementations. There are a lot of bugs in all of them, though Edge is by far the worst (reproduceable crashes are hard, because it crashes randomly on most of his test inputs, but at different points).
It's also a pretty horrible design. It's replaced HSAIL as my go-to example for how not to design a good IR.
One thing I forgot to mention: move semantics now mean that it's possible to sensibly use generic containers without having copying semantics. One of the problems with C++98 was that you ended up with a lot of copies for safe code. If you want to put objects into something like a std::vector or std::map, then you had to either copy, or use raw pointers and worry about memory management. With move semantics, you can either move the objects (e.g. for a string you copy the pointer to the buffer and the length and invalidate the old one), or you can use smart pointers. This alone makes C++11 a far better language than C++98 - lots of things that should have always been easy to express now actually are.
I think the point I was trying to make is that many C programmers are conditioned to know that macros can be bloaty. Usually the programmer knows up front that speed or size is important. My experience is that many C++ programmers are conditioned to work fast, and not worry about size or speed because there's always a bigger and faster processor coming soon. I'm not trying to say that all the programmers are this way, but it's a distinct trend I've seen.
I think that's more a function of target rather than language. Programmers writing for resource-constrained environments quickly learn which language features consume those resources quickly. Even on big machines, instruction cache is a fairly scarce resource, so avoiding code size increases on hot paths is important.
I've seen the "one tool fits all" style of thinking in C++ a lot. Ie, if you've got std::map, then that's all you need.
I've seen exactly the same from C programmers. The 4BSD collections (now in Linux, *BSD, and Windows NT kernels) or the UT* ones are the solution to all problems. And that's not a bad thing if it's for prototyping.
if you've got std::map, then that's all you need. I saw someone implement something that should have just been a simple array lookup, a small fixed size array of 5 elements, which could have been done in plain C; but he used std::map for this which made it larger and slower and took more programmer time. Even std::vector would have been preferable. And the programmer knew that space was at a premium.
The nice thing about using a std::map here is that, if you use a typedef or an equivalent using directive, you can replace it with a class that wraps std::array and does linear search without modifying any of the code that uses it. In C, this is much harder to do without your code becoming ugly.
I do like templates if used sparingly and not in an STL style where whole objects are copied into containers instead of just pointers or references. I've used templates that just provided pointer type safety with a more generic underlying library that took void*. I used to like the RogueWave C++ classes, until the STL took hold.
STL was an SGI product, but I'll assume you mean the C++ standard library. There's nothing that requires copying in any of the standard library classes. you need to think about ownership if you use them to store pointers (or references), but you can also use them to store smart pointers and with unique_ptr you get ownership semantics along with no copying (and no run-time overhead). The addition of move semantics in C++11 also means that you can move objects, rather than copying them, so if your object is a small structure containing pointers to something large then the cost of the move is cheap.
Assuming that the original program ran on an x86 PC. Getting data out of programs that only ran on a PowerPC Mac is much harder, though older systems (e.g. most m68k systems, such as Amigas and older Macs) were sufficiently simple that there are now emulators that have decent performance. Unless, of course, the program in question relied on some copy protection mechanism that doesn't work with the emulator. Try getting anything that had a parallel-port dongle to work in DOSBox, for example.
Even then, just being able to read the data in a VM or emulator isn't always that useful - you want to translate it to some other form and so you end up needing a chain of import-export programs, and finding the middle ones can be difficult. I have a bunch of ClarisWorks 1 documents and if I ever want to import them into something new then I think I will need to find a copy of ClarisWorks 3, which can both open them and save in a format that the latest AppleWorks (which still runs in Rosetta on an older OS X on an x86 Mac) can open, and then export them into something else that's actually readable on a modern system. For the word processor documents, ClarisWorks 3 can save them in a format that a modern version of Word can open (ClarisWorks 1 couldn't), though likely with a loss of formatting, but most of them were from the vector graphics program (which worked well as a DTP program, because the text boxes embedded all of the functionality of the word processor) and I've no idea what the path for opening them on a modern system is. Fortunately, I don't really care about most of them.
There are two reasons to avoid the public domain, though they're largely been relaxed over time. The first is that most software licenses include an explicit disclaimer of liability. If you put something in the public domain then you are not providing that, so though you waive the right to sue over copyright infringement no one else waives the right to sue you. That said, I don't believe that there's been a single lawsuit over merchantability of public domain code, and I'd be surprised if one didn't get laughed out of court.
The other is that some jurisdictions either don't recognise that public domain exists, or recognise it only as the state into which works fall after the copyright expires. In particular, there's a lot of jurisdictional difference over moral rights, which either don't exist at all (much of the US - yes the US has bits of copyright law that vary from state to state), aren't transferrable / waivable, or are simply the same as other rights, so depending on the jurisdiction public domain work may still have strong attribution requirements.
The CC0 license avoids all of these issues and so is generally a better choice if you want to ensure that the rights that the recipient of your code has are the same that they'd have in a common interpretation of what public domain means.
The big change is that there is now, for all *NIX platforms, a stable C++ ABI. The HP Itanium ABI was adopted largely as-is by all *NIX systems (with the slight exception of 32-bit ARM, which does exceptions slightly differently and handles pointers to members differently because the low bit in instruction pointers is already in use for thumb interworking). Variations between archs don't matter too much, but changes within an architecture are problematic because they mean that you can't define long-term-stable interfaces in terms of C++. On Windows, for example, all public interfaces are either C or COM because the MS compiler changes ABI across Visual Studio versions. Apple was bitten by this, because they defined kernel (IOKit) interface in terms of the gcc 2.95 ABI and had a lot of pain to move everything to the Itanium ABI (largely motivated by the fact that clang never supported the old ABI).
On a related note, compilers are a lot better at optimising C++ now than they were 20 years ago. All of the companies that employ a lot of LLVM or GCC developers now have huge internal C++ codebases and care more about the performance of these than of their C code. This is a huge shift from 20 years ago, where C++ was a checklist feature for gcc (clang didn't exist) and no one really cared about C++ performance. 20 years ago, renaming a .c file to .cc and compiling it with gcc would often give you slower code. Now, it will give you exactly the same code and performance doesn't get worse as you use more C++ features. For example, both templates and lambdas rely on the inliner a lot and modern C/C++ compilers have tuned their inliners on this use case more than on common C idioms.
In terms of language features, there are a few big ones. The first is lambdas. These can be used in a lot of places where you'd use macros and generate the same code, but be a lot more readable. The other large feature is the addition of move semantics. This is very important for kernel-style code, where you want to have fine control over memory ownership. Things like the standard library unique_ptr template give you a trivial way of expressing unique ownership in the code, in a way that can be transferred between threads, and compiles down to no code but statically checks that you've followed the correct discipline.
There are a few other things that are pretty useful. Generalised constexpr means that you can write functions that should be evaluable at compile time and you can use a trivial template wrapper to force compile-time evaluation. This is very useful in code where you need to reason about run-time complexity, because you can guarantee that the compiler really will evaluate something at compile time or fail to compile.
For the kernel, the improvements to enums in C++11 can also be useful. You can define enums that are actually type safe (i.e. they're not just the equivalent of #defines of int values and assigning the wrong enum is actually an error) and which have a storage type other than int.
The Linux kernel has a really crappy way of handling memory orderings, which basically rely on having macros that map to the different memory barriers on Alpha and having programmers insert them in the right places, so it's not as well suited as something like FreeBSD to adopting C++11 atomics (FreeBSD provides functions that have almost identical semantics to the C++11 acquire-release model), but adopting it exposes a lot more opportunities for compiler optimisations. The current atomics are all implemented as asm volatile statements, which provide a full compiler barrier (the compiler may not move instructions from one side to the other, even if it would be safe to in the memory model). C11 also has support for this, but it's a really ugly copy and paste of the C++11 stuff to C11 and the standard ends up writing volatile in a bunch of places where it means _Atomic, so using them is painful.
Range-based for loops don't give you anything other
Any language feature can be abused, and C has exactly the same problem: macros can cause code bloat. Correctly used, templates let you provide abstractions that are then specialised and inlined and, after optimisation, become one or two instructions inline, where the C equivalent requires a real function call because it's having to handle the generic use cases in a single place.
Oh, and your example of wanting to use == on strings is a good one. Look at the LLVM StringRef class for an example of how to do this sensibly. It defines a non-owning reference to a string, which is a char* and a length. It has a constructor that takes a const char*, and will generate the relevant memcmp / strcmp calls for comparisons. It's defined in a header and is always inlined, so (with optimisations enabled), StringRef(a) == StringRef(b) will compile to a pair of strlen calls (which would be optimised away for compile-time constant strings), and then a memcmp call (with the shortest length) if the lengths are not both 0. If you're mostly dealing with null-terminated strings, you can avoid the strlen calls by using an equivalent where the length is calculated lazily when required, so this use of == would generate the same code as the C version.
Your argument that programmers don't think too hard about what their code is doing and should therefore use C seems quite horrifying.
I have musicpd on my NAS and I also export my music directory as read-only NFS share. I can then plug in any cheap machine with acceptable sound (or a RPi for rooms where sound quality isn't that big a deal) also running musicpd. There are multiple apps (desktop, web, and mobile) for controlling musicpd and I can configure each one to output as a stream as well as to the local speakers, so that the others can either listen to their own queue or be slaved to another. Musicpd is packaged for just about any OS that you might be running. Adding an NFS import to most *NIX systems is a simple matter of a line in fstab.
There's also one crucial advantage of paper ballots: the expertise required to monitor the election is very low. Even a relatively unpopular candidate is able to find enough people who can watch people put pieces of paper into a box and can watch the boxes for signs of tampering throughout the entire process. You can't have a democracy if the mechanism for collecting and counting the votes can only be audited by a select few experts.
Linus isn't irrationally afraid of C++, he's rationally afraid of the state of C++ 20 years ago. I completely agree with him that C++ was a terrible language 20 years ago. He just hasn't bothered to reevaluate his opinions based on more recent versions of both the standards and compiler ABI stability.
Oh, and you missed the horrible non-typesafe macros (look at the list and queue macros, for example), that provide a crappy version of C++ templates, with all of the disadvantages and a few of the advantages.
They use a crow bar, bolt cutter or angle grinder
It's worth repeating this, because that's the standard for bike locks. They're not intended to be unpickable, they're intended to make the tools and time required to pick them more expensive / heavier / harder than simply cutting the chain. A lot of bike chains can be cut with a pair of bold cutters, the more expensive ones with a hand-held battery-powered disc cutter. With the exception of the cheapest, worst, bike locks, no one will bother to pick them because if they want to steal bikes then they'll just cut the chain.
Or they'll do something a bit more organised. Around here there was a group that came through the city a couple of years back with a low loader and a forklift. They'd go to bike parks where bikes were attached to metal hoops held in the ground with a few metal bolts and lift the whole thing up onto the low loader with the forklift. They could get 40 or so bikes in about 5 minutes, and by the time anyone had reported them they'd be long gone.
Remember how Intel killed off most of the workstation architectures? They produced slower chips, but had a lot more volume and so were able to scale up production, giving them a lot more to invest in R&D. Now look at the ARM ecosystem. There are about half a dozen completely independent implementations of the ISA, all competing, and most with a larger volume than Intel individually.
A modern mobile phone CPU is more than adequate for most laptop users and we're starting to see things like Chromebooks shipping with them. That's how companies like SGI and Sun lost their market share: a competitor comes in at the low end and takes that part of the market, then is able to slowly move up. This isn't a new thing for ARM. They started off in Acorn desktops and Apple handhelds, but for most of their existence they were very low-end embedded systems. ARM chips that have been plausible laptop CPUs are a relatively new thing - even the StrongARM chips from the early 2000s were nowhere near competitive with even low-end Pentiums.
1. I'm assuming no VMWare? How well does Xen run on ARM?
Xen has worked well on AArch64 for a long time. I think KVM also works. Bhyve support is almost there.
Can GCC/CLANG optimize for a server profile? I'm assuming that, until now, all the work for the ARM target has been on code compactness and efficiency over performance.
There's very little work done in the compiler on optimising for power. To a first approximation, the best optimisation for power is to finish quickly and let the CPU sleep. This is exactly the same for server and mobile workloads. There are differences in pipeline design, but the LLVM AArch64 back end already supports pipeline-specific tuning for AArch64 targets ranging from dual-issue in-order to wide superscalar out-of-order, so that shouldn't be a problem. I don't know what the ARM status for GCC is now that ARM, Google, and Apple are all investing almost exclusively in LLVM development, but I'd imagine it's not too different there.
Looks like the chip has plenty of available bandwidth, does it have the transactional horsepower to fill it?
I have no idea about this without more microarchitectural details being published, but there's nothing at the ISA level for AArch64 that would prevent it from scaling up to the kind of desired performance.
Most bike locks are absolute crap, and even I can pick them. Most of the expensive ones take a few minutes for most of the competent people in my local lockpicking group. Some have quite astonishing weaknesses: the older Axa locks could all be unlocked with a key blank, for example. I'd challenge you to name one brand of bike lock that's unpickable - most of the good ones are used in competitions and only take a minute or two for the winner.
The main reason you want something else is that Bluetooth is a lot slower than WiFi. It's fine for individual small files, but if you want to send a video file between two devices, for example, then it's painfully slow. It's similarly slow if you want to copy a full album of music, or even a pile of PDFs. You want a protocol that can do the transfer over WiFi, though I seem to recall that there's a protocol for migrating Bluetooth connections to WiFi, which would work.
IR Link was horrible, because most laptop IR transceivers had a very narrow view. It was sort-of okay for PDAs if you held the PDA directly against the IR port, but impossible to align for a pair of laptops reliably.
Bluetooth file transfer is also pretty mature at this point. I've used it between Windows, Mac, and FreeBSD machines and with old Nokia and new Android phones (it probably works with iOS, though it didn't in the original iPhone). Pairing is a bit annoying, but once that's done it's basically drag and drop.
AirDrop is nice because it uses bluetooth to identify nearby machines and to advertise public keys, but then creates a two-device ad-hoc wireless network and transfers at high speed. WiFi direct now provides a somewhat more standard and mature mechanism for doing this.
I'm quite annoyed that Apple, Microsoft, and Google are all developing independent protocols for this though. I want an open protocol that works with all of my devices, not a mess of protocols where I can use one between my laptop and Android phone, one between my laptop and iPad, none between my iPad and Android phone, a different one between Windows devices, and so on.
Are you sure. These vulnerabilities were all found with the same kernel fuzzing tool that, as far as I know, has not been ported to work on other operating systems. It would be great for someone to run the same thing on *BSD and Windows - similar exploits are almost certainly in all systems, the difference is that the Linux ones are now known and fixed.
Not even original - Microsoft did this for IE talking to IIS. I don't remember the exact details, but they were skipping part of the standard TCP handshake to reduce latency, so pages loaded faster with IE, but only if served from a Windows IIS machine.
The old generation is also clueless about privacy in technology, they just can't get the technology to work well enough to invade their privacy this thoroughly.
I wish this were a joke...
I'm not sure if you count it as a UI improvement, but the addition of SmartArt to PowerPoint is a huge improvement and is (I think) only about 10 years old. For anyone who hasn't seen this, it maps from an outline view to one of a few dozen pre-defined diagram types. It's a very quick way of turning a slide of text into a slide in a graphical representation.
I am using a Moto G (first generation). It stopped getting first-party updates after about two years, but it's now 4 years old and is getting regular updates from LinageOS. It's actually faster with the most recent Android than when I bought it (the ART compiler has improved a lot), so I imagine that I'll hang onto it for a long time. I may repurpose it at some point (remove the SIM and it's still a reasonable remote control for music and so on), but I anticipate keeping it for at least a couple more years.
The problem with Apple devices is that, once the first party updates stop coming, you're screwed. There won't be any fixes for exploitable security vulnerabilities, so any use that involves connecting it to a network is out unless you want it to be a possible vector for spreading malware onto your LAN. In contrast, it's possible to unlock the bootloader for most Android devices, so it's possible for third parties to keep supporting them.
I hope you're not using WiFi...