The middle-click mechanism (selection buffer) on X11 is a lot closer to a drag and drop event than a copy and paste event. There is no intermediate holding a buffered copy and there is bidirectional communication for negotiating content type. If Wayland actually implements copy and paste as you've described, then I can only assume that the developers have never written a GUI application on a platform where people actually use drag and drop.
What does 'support' mean to you? To me, it means 'if I find a bug that critically affects my business, someone will fix it'. For any given open source package, I can usually find a dozen companies willing to offer me that service, with varying cost / levels of competence. With a proprietary product, I can find at most one, and usually their 'support' option is 'please buy the next version, yes I know the UI has changed, just add it up to your retraining budget'.
There, there is not even real distinction between copy+paste and drag+drop. All data is offered by the origin client via "wl_data_source::offer". The only actual param this accepts is the MIME type
You're not really explaining why that's a terrible design decision. The reason is that drag-and-drop (and the X11 selection buffer) are bidirectional operations, whereas copy-and-paste is unidirectional. When you copy something, you are providing it to the pasteboard service, which must then store every representation that it might want to contain. The receiver of the paste operation then checks which type it wants. You're limited by storage space and by processing time to a relatively restricted set of types. In contrast, drag-and-drop involves live content type negotiation. The sender advertises a potentially huge set of types, the receiver filters out the ones that it doesn't understand and then selects the one that it most wants. This gives a lot more flexibility, because the dragged object may be something that's comparatively expensive to generate / huge (for example, you might offer video in a load of different codecs and resolutions and have a drop target that picks the ideal one, but you wouldn't want to be spending half a second each preparing all of them when the user hits copy and then asking the pasteboard to store a few GBs of data).
Chrome was released a bit earlier, but Google started putting massive amounts of Chrome advertising everywhere about two years ago. It's advertised on TV, and it's advertised on the Google front page. Mozilla isn't coming close to matching this.
Does Apple care about ARM chips other than what's in their phones?
No, but that still covers ARMv7 and ARMv8. The amount of microarchitectural tuning for specific cores within these families is a very small part of the code. And, as I said, Apple is not the only company throwing resources at the ARM back end. Google and ARM are both spending a lot of resources improving LLVM. So is Qualcomm, so is Linaro, and so is Samsung.
But still, Clang/LLVM is too new
You realise that LLVM is over a decade old and Clang is almost this old? And that both are more actively developed than GCC and have been for the last few years? How old does a compiler have to be before it is not 'too new' in your estimation?
if you want stability right now you stick to GCC instead of jumping ship because some PC users are in love with something else.
By 'some PC users', I presume you mean the toolchain group and senior management at ARM Ltd.? You know, the ones who have replaced ARMcc with Clang in their toolchain and are recommending LLVM for all of their customers?
Recent LLVM / Clang needs a moderately compliant C++11 compiler to work. I think that means gcc 4.8 or newer, though it could be 4.9. There are some weird things that you sometimes hit with g++ / libstdc++ and C++11 (I was recently bitten by the fact that initialiser lists don't seem to work with std::tuple), but LLVM has buildbots that try to build it with gcc and so avoids these features.
The problem was that Apple wanted features, and GCC wouldn't allow those features to be built. So finally Apple just gave up and built their own.
This was not the issue. Apple maintained their own branch of GCC in the FSF's svn repository for a long time. Lots of features (e.g. blocks support, some Objective-C features) never made it back into the FSF's branch, but this was not a problem for Apple. The problem was that GCC could not be used, for both technical and legal reasons, in some of the places where Apple wanted to use it. Syntax highlighting was one simple example. GCC does constant folding in the front end, so by the time that you have anything like an AST, you can't distinguish between 3+4 and 7 in the source code - that made working out how to colour the tokens difficult. Even if this were addressed, you could only embed GCC in a GPLv3 IDE, and Apple didn't want to have to release XCode under GPLv3.
LLVM "IR" format, which is a mostly machine-independent Intermediate Representation
LLVM IR is target agnostic, not target independent. The format itself is the same across all targets, but various things (e.g. calling conventions - how you split structs between registers and the stack) will be different for different targets.
The grandparent is partly right. You can do this for microarchitectural optimisations. I believe that Apple now does this for their app store: if you upload the app as LLVM IR then they will generate versions specialised for each of the ARM cores that they've shipped. This can be quite a big difference (costs of different vector operations on different cores means that you can have quite different decisions in the autovectoriser, for example). You can't do it for different architectures, even if LLVM IR were perfect for the task, if you start with a C-like language. By the time that you've run the C preprocessor, your source code is no longer architecture agnostic. Things like va_list, intptr_t and htons are defined in such a way that encodes pointer size, endian, and variadic calling convention. Things like jmpbuf and ucontext_t encode the architecture fairly precisely.
ARM has a lot more people working on LLVM than they do on GCC and they're slowly transitioning everything across. Their customers fell into two categories: ones that don't care about the license and ones that won't touch GPLv3. If you want a compiler with long-term support for ARM, then GCC probably isn't your best bet.
Have you benchmarked it recently? I tried this on our build machines (32 cores, 256GB of RAM, 512GB SSD split mostly as L2ARC with a small amount as log device, 3TB spinning rust in a ZFS mirror) a while ago. The amount of I/O that actually goes to the spinning rust is tiny (object files are written out, but never read back), pretty much all I/O comes from the buffer cache. Putting it on a RAM drive reduced the writes, but there's no synchronisation required for them so they never became a bottleneck. In a couple of cases (some of our builds produce about 40-50GB of object code), the RAM drive made things slower because now you had a copy in the buffer cache and a copy in the RAM drive, whereas previously the authoritative copy is on the spinning rust and the copy that you actually used was on the RAM drive, so using a RAM drive triggered swapping, whereas not using one just had some bursts of 100MB/s streaming writes to the disk.
TL;DR: If you've got enough RAM, the OS should be able to satisfy reads from RAM irrespective of what the backing store is.
C++. For efficiency, you often need to put small methods in the headers. If they're templates, then you don't have an option if you want to share them between compilation units. Change a template in a header and you can easily trigger recompilation of a few hundred C++ files.
Apple, whose most profitable product lines all include ARM chips, has a large compiler team working on Clang and LLVM. Google, which doesn't ship any ARM products, but does have a huge investment in the ARM ecosystem, also employs a lot of people contributing to LLVM. They contributed most of the ARMv8 back end. ARM also has several large teams working on LLVM (I think that they've largely consolidated them now - they used to have separate C, OpenCL-ARM, and OpenCL-Mali teams all working largely independently on LLVM) and is now (as the other poster says) using LLVM for their proprietary toolchain (which is mostly expensive because of the debugging / tracing tools), so they're contributing a lot. There are a lot more ARM developers working on LLVM than clang. IBM has people working on PowerPC support, Imagination Tech on MIPS support. SPARC is largely volunteers these days, but Oracle seems to be killing SPARC as a thing anyone else might care about.
Replace them by coopting people who do not actively seek power over others to work as representatives of the people, rather than holding a popularity contest with entry tickets costing a few million dollars.
The reason we are no longer allowed to carry large volumes of liquids onto planes is because they caught the terrorist plot before it could be used
The 'terrorist plot' involved mixing nitroglycerine in the plane toilet. The technique that they were planning on using needs several hours on a steady workbench to be used. If, by some miracle, they'd managed to stay in the toilet for a couple of hours without anyone noticing, then the first bit of turbulence or vibration in the airframe would have resulted in an explosion just large enough to take off the hands (and, given how small aeroplane toilets are, probably more delicate parts) of the terrorists, but had no other effect.
In other words, stopping the 'plot' cost us a propaganda victory of being able to say 'Al Quaeda, the idiots who blew themselves up in a toilet last year' in every story related to them. It's pretty hard to spread terror when you're a laughing stock.
Explain to your friends that any competent programmer who attacks the problem can devise an uncrackable communications system
That's a really bad argument, because to most of the population programmers are wizards who understand the magic that goes on inside the magic boxes that they use. More importantly, you can go to a library, read a book about encryption, and use a pencil and paper to encrypt messages in a way that they can't be decrypted (it's a bit time consuming, but there's nothing involved beyond high-school maths) and, because it's offline and not subject to timing attacks or side channels, it's going to be far more secure and harder to intercept via trojans than anything that involves using a computer. Oh, and there are also a lot of simple steganographic tricks (linguistic steganography is particularly fun, permuting a copy-and-paste troll in such a way that it looks as if you're just trying to get around a forum's spam filter, but are actually encoding a hidden message) that can be done without using a computer to do anything other than post the result somewhere.
Which, of course, is exactly what was done. You, the citizen, had to bring your own weapon, your own powder, and on a specific date, perform drills.
That's not quite right. Often, guns and powder would be provided by someone wealthy, who would raise a militia as a show of civic responsibility. They'd fund the training and buy most of the equipment.
TFA seems to be completely missing the point. We're not teaching programming because we expect everyone to be a full-time programmer, we're teaching programming because it's an important life skill. Even if they just learn that there are some tasks that can be automated and when to ask a professional programmer to do it (and, ideally, what tasks can't easily be automated) then that's a huge win. If they can do the simple automation tasks themselves, that's even better.
How often have to seen people in admin jobs spending ages doing something in MS Office that half a dozen lines of VBA could have done in under a second? Eliminating that is the kind of productivity win that we expect to see from teaching everyone a little bit of programming. The argument makes as much sense as saying 'most people won't become novelists, we shouldn't teach English', or 'most people won't become accountants, we shouldn't teach mathematics'.
(Speaking from the perspective of a UK academic, may vary between countries) There is no pressure to publish, as an abstraction. There is pressure to demonstrate impact. The easiest way to demonstrate impact is to publish in top-tier publications. Publishing in a new journal or conference is always a big gamble - if the journal does well later then you may retroactively benefit from a later assessment of its impact, but typically it's in the noise of all of the spammy journals.
Actually, a number of studies in the last decade have shown that this is not the case. Most people will balance self-interest with the interests of the people that they perceive as their tribal group (which, for some people, can be very large). The other interesting result is that most people project their own motivations onto others, so almost all sociopaths believe that everyone else is motivated solely by self interest.
There was a study from Google a while ago looking at hard disk failure modes. Very short summary: SMART errors generally indicate that a drive is about to fail, lack of SMART errors in no way indicates that a drive is not about to fail. Large numbers of spinning rust drives fail abruptly with no warning. Some do give warnings, but often it's too late for anything other than recovering the data from a RAID array - by the time you see user errors, the drive is likely to already have stored corrupted sectors.
I presume that this would be integrated with some kind of app on the receiver end. When the truck is dispatched (or, if the depot is in range, when the parcel is ready for direct dispatch), you'd get a message telling you the time window when it will be available. You then signal that you're ready to receive it and give some GPS coordinates. It's then dispatched and sends another message when it's a few hundred metres away. You then go outside (or stand on a balcony) and wait for it to be delivered directly to you. Once it's very close, it can use WiFi from your phone (send your MAC address to the drone and the SSID that you're associated with - or create an ad-hoc network if you're out of range and it can home in on you) to check that it's actually landing by the correct person. Then just tap the 'delivery received' button and it will fly away.
Slashdot Mirror
The middle-click mechanism (selection buffer) on X11 is a lot closer to a drag and drop event than a copy and paste event. There is no intermediate holding a buffered copy and there is bidirectional communication for negotiating content type. If Wayland actually implements copy and paste as you've described, then I can only assume that the developers have never written a GUI application on a platform where people actually use drag and drop.
What does 'support' mean to you? To me, it means 'if I find a bug that critically affects my business, someone will fix it'. For any given open source package, I can usually find a dozen companies willing to offer me that service, with varying cost / levels of competence. With a proprietary product, I can find at most one, and usually their 'support' option is 'please buy the next version, yes I know the UI has changed, just add it up to your retraining budget'.
There, there is not even real distinction between copy+paste and drag+drop. All data is offered by the origin client via "wl_data_source::offer". The only actual param this accepts is the MIME type
You're not really explaining why that's a terrible design decision. The reason is that drag-and-drop (and the X11 selection buffer) are bidirectional operations, whereas copy-and-paste is unidirectional. When you copy something, you are providing it to the pasteboard service, which must then store every representation that it might want to contain. The receiver of the paste operation then checks which type it wants. You're limited by storage space and by processing time to a relatively restricted set of types. In contrast, drag-and-drop involves live content type negotiation. The sender advertises a potentially huge set of types, the receiver filters out the ones that it doesn't understand and then selects the one that it most wants. This gives a lot more flexibility, because the dragged object may be something that's comparatively expensive to generate / huge (for example, you might offer video in a load of different codecs and resolutions and have a drop target that picks the ideal one, but you wouldn't want to be spending half a second each preparing all of them when the user hits copy and then asking the pasteboard to store a few GBs of data).
Chrome was released a bit earlier, but Google started putting massive amounts of Chrome advertising everywhere about two years ago. It's advertised on TV, and it's advertised on the Google front page. Mozilla isn't coming close to matching this.
Does Apple care about ARM chips other than what's in their phones?
No, but that still covers ARMv7 and ARMv8. The amount of microarchitectural tuning for specific cores within these families is a very small part of the code. And, as I said, Apple is not the only company throwing resources at the ARM back end. Google and ARM are both spending a lot of resources improving LLVM. So is Qualcomm, so is Linaro, and so is Samsung.
But still, Clang/LLVM is too new
You realise that LLVM is over a decade old and Clang is almost this old? And that both are more actively developed than GCC and have been for the last few years? How old does a compiler have to be before it is not 'too new' in your estimation?
if you want stability right now you stick to GCC instead of jumping ship because some PC users are in love with something else.
By 'some PC users', I presume you mean the toolchain group and senior management at ARM Ltd.? You know, the ones who have replaced ARMcc with Clang in their toolchain and are recommending LLVM for all of their customers?
That's fine, as long as your program never has any changes to the requirements after the 1.0 release. i.e. in no code ever.
It's been hugely improved in the last couple of releases. Linaro did quite a bit of work on the vectoriser, as did Apple.
Recent LLVM / Clang needs a moderately compliant C++11 compiler to work. I think that means gcc 4.8 or newer, though it could be 4.9. There are some weird things that you sometimes hit with g++ / libstdc++ and C++11 (I was recently bitten by the fact that initialiser lists don't seem to work with std::tuple), but LLVM has buildbots that try to build it with gcc and so avoids these features.
The problem was that Apple wanted features, and GCC wouldn't allow those features to be built. So finally Apple just gave up and built their own.
This was not the issue. Apple maintained their own branch of GCC in the FSF's svn repository for a long time. Lots of features (e.g. blocks support, some Objective-C features) never made it back into the FSF's branch, but this was not a problem for Apple. The problem was that GCC could not be used, for both technical and legal reasons, in some of the places where Apple wanted to use it. Syntax highlighting was one simple example. GCC does constant folding in the front end, so by the time that you have anything like an AST, you can't distinguish between 3+4 and 7 in the source code - that made working out how to colour the tokens difficult. Even if this were addressed, you could only embed GCC in a GPLv3 IDE, and Apple didn't want to have to release XCode under GPLv3.
LLVM "IR" format, which is a mostly machine-independent Intermediate Representation
LLVM IR is target agnostic, not target independent. The format itself is the same across all targets, but various things (e.g. calling conventions - how you split structs between registers and the stack) will be different for different targets.
The grandparent is partly right. You can do this for microarchitectural optimisations. I believe that Apple now does this for their app store: if you upload the app as LLVM IR then they will generate versions specialised for each of the ARM cores that they've shipped. This can be quite a big difference (costs of different vector operations on different cores means that you can have quite different decisions in the autovectoriser, for example). You can't do it for different architectures, even if LLVM IR were perfect for the task, if you start with a C-like language. By the time that you've run the C preprocessor, your source code is no longer architecture agnostic. Things like va_list, intptr_t and htons are defined in such a way that encodes pointer size, endian, and variadic calling convention. Things like jmpbuf and ucontext_t encode the architecture fairly precisely.
GCC supports ARM, and ARM supports GCC
ARM has a lot more people working on LLVM than they do on GCC and they're slowly transitioning everything across. Their customers fell into two categories: ones that don't care about the license and ones that won't touch GPLv3. If you want a compiler with long-term support for ARM, then GCC probably isn't your best bet.
Have you benchmarked it recently? I tried this on our build machines (32 cores, 256GB of RAM, 512GB SSD split mostly as L2ARC with a small amount as log device, 3TB spinning rust in a ZFS mirror) a while ago. The amount of I/O that actually goes to the spinning rust is tiny (object files are written out, but never read back), pretty much all I/O comes from the buffer cache. Putting it on a RAM drive reduced the writes, but there's no synchronisation required for them so they never became a bottleneck. In a couple of cases (some of our builds produce about 40-50GB of object code), the RAM drive made things slower because now you had a copy in the buffer cache and a copy in the RAM drive, whereas previously the authoritative copy is on the spinning rust and the copy that you actually used was on the RAM drive, so using a RAM drive triggered swapping, whereas not using one just had some bursts of 100MB/s streaming writes to the disk.
TL;DR: If you've got enough RAM, the OS should be able to satisfy reads from RAM irrespective of what the backing store is.
C++. For efficiency, you often need to put small methods in the headers. If they're templates, then you don't have an option if you want to share them between compilation units. Change a template in a header and you can easily trigger recompilation of a few hundred C++ files.
Apple, whose most profitable product lines all include ARM chips, has a large compiler team working on Clang and LLVM. Google, which doesn't ship any ARM products, but does have a huge investment in the ARM ecosystem, also employs a lot of people contributing to LLVM. They contributed most of the ARMv8 back end. ARM also has several large teams working on LLVM (I think that they've largely consolidated them now - they used to have separate C, OpenCL-ARM, and OpenCL-Mali teams all working largely independently on LLVM) and is now (as the other poster says) using LLVM for their proprietary toolchain (which is mostly expensive because of the debugging / tracing tools), so they're contributing a lot. There are a lot more ARM developers working on LLVM than clang. IBM has people working on PowerPC support, Imagination Tech on MIPS support. SPARC is largely volunteers these days, but Oracle seems to be killing SPARC as a thing anyone else might care about.
Replace them by coopting people who do not actively seek power over others to work as representatives of the people, rather than holding a popularity contest with entry tickets costing a few million dollars.
The reason we are no longer allowed to carry large volumes of liquids onto planes is because they caught the terrorist plot before it could be used
The 'terrorist plot' involved mixing nitroglycerine in the plane toilet. The technique that they were planning on using needs several hours on a steady workbench to be used. If, by some miracle, they'd managed to stay in the toilet for a couple of hours without anyone noticing, then the first bit of turbulence or vibration in the airframe would have resulted in an explosion just large enough to take off the hands (and, given how small aeroplane toilets are, probably more delicate parts) of the terrorists, but had no other effect.
In other words, stopping the 'plot' cost us a propaganda victory of being able to say 'Al Quaeda, the idiots who blew themselves up in a toilet last year' in every story related to them. It's pretty hard to spread terror when you're a laughing stock.
Explain to your friends that any competent programmer who attacks the problem can devise an uncrackable communications system
That's a really bad argument, because to most of the population programmers are wizards who understand the magic that goes on inside the magic boxes that they use. More importantly, you can go to a library, read a book about encryption, and use a pencil and paper to encrypt messages in a way that they can't be decrypted (it's a bit time consuming, but there's nothing involved beyond high-school maths) and, because it's offline and not subject to timing attacks or side channels, it's going to be far more secure and harder to intercept via trojans than anything that involves using a computer. Oh, and there are also a lot of simple steganographic tricks (linguistic steganography is particularly fun, permuting a copy-and-paste troll in such a way that it looks as if you're just trying to get around a forum's spam filter, but are actually encoding a hidden message) that can be done without using a computer to do anything other than post the result somewhere.
Which, of course, is exactly what was done. You, the citizen, had to bring your own weapon, your own powder, and on a specific date, perform drills.
That's not quite right. Often, guns and powder would be provided by someone wealthy, who would raise a militia as a show of civic responsibility. They'd fund the training and buy most of the equipment.
TFA seems to be completely missing the point. We're not teaching programming because we expect everyone to be a full-time programmer, we're teaching programming because it's an important life skill. Even if they just learn that there are some tasks that can be automated and when to ask a professional programmer to do it (and, ideally, what tasks can't easily be automated) then that's a huge win. If they can do the simple automation tasks themselves, that's even better.
How often have to seen people in admin jobs spending ages doing something in MS Office that half a dozen lines of VBA could have done in under a second? Eliminating that is the kind of productivity win that we expect to see from teaching everyone a little bit of programming. The argument makes as much sense as saying 'most people won't become novelists, we shouldn't teach English', or 'most people won't become accountants, we shouldn't teach mathematics'.
(Speaking from the perspective of a UK academic, may vary between countries) There is no pressure to publish, as an abstraction. There is pressure to demonstrate impact. The easiest way to demonstrate impact is to publish in top-tier publications. Publishing in a new journal or conference is always a big gamble - if the journal does well later then you may retroactively benefit from a later assessment of its impact, but typically it's in the noise of all of the spammy journals.
*Everyone* acts in their self-interest
Actually, a number of studies in the last decade have shown that this is not the case. Most people will balance self-interest with the interests of the people that they perceive as their tribal group (which, for some people, can be very large). The other interesting result is that most people project their own motivations onto others, so almost all sociopaths believe that everyone else is motivated solely by self interest.
For most users, there is no warning
There was a study from Google a while ago looking at hard disk failure modes. Very short summary: SMART errors generally indicate that a drive is about to fail, lack of SMART errors in no way indicates that a drive is not about to fail. Large numbers of spinning rust drives fail abruptly with no warning. Some do give warnings, but often it's too late for anything other than recovering the data from a RAID array - by the time you see user errors, the drive is likely to already have stored corrupted sectors.
The world also needs less stupid people, though making people less stupid by blowing them up is probably not going to work very well.
I presume that this would be integrated with some kind of app on the receiver end. When the truck is dispatched (or, if the depot is in range, when the parcel is ready for direct dispatch), you'd get a message telling you the time window when it will be available. You then signal that you're ready to receive it and give some GPS coordinates. It's then dispatched and sends another message when it's a few hundred metres away. You then go outside (or stand on a balcony) and wait for it to be delivered directly to you. Once it's very close, it can use WiFi from your phone (send your MAC address to the drone and the SSID that you're associated with - or create an ad-hoc network if you're out of range and it can home in on you) to check that it's actually landing by the correct person. Then just tap the 'delivery received' button and it will fly away.