Cuteness and familiarity. Most people rarely come into contact with lambs. I grew up in a village surrounded by farms and I remember that a number of children wouldn't eat lambs because they were cute (although the ones that grew up on the farms mostly didn't have this objection). Most people in the west either have owned a dog or have a friend who owns one though and so it's much harder to regard a dog as food. If you come from somewhere where dogs are not kept as pets and the wild ones are just disease-carrying creatures that prey on your livestock, then it's much easier to eat them.
Cuteness in the abstract, without direct contact, isn't enough.
As I said earlier, it means that the C code can't call any functions. It also can't handle the exceptions. You could do every function call in an inline asm block (making sure that every live variable in the function was in input argument to the block, so that you can ensure that they're preserved) and then have that block set a variable that you then branched on, but then you're combining the worst of both worlds. You're not getting the 'zero cost' bit of 'zero cost exceptions', because you're testing whether an exception was thrown after each call. You're also not getting the low-cost-when-used properties of normal C error code checking, because to get to the error path you're having to go through the (very slow) generic stack unwinder.
To efficiently make use of zero-cost exceptions in C, by which I mean having an error-handling path that does not incur any cost (including branch predictor state) when not used, you'd have to write your entire try/catch block in the inline assembly. At that point, you're not writing C, you're writing assembly and just using a C compiler.
No what doesn't? You obviously have no idea how a modern (or even not-so-modern) compiler works. The vast majority of optimisations depend on having an accurate control flow graph. Inline asm is assumed to have no flow control (it's allowed to call functions, but it must either not return at all, or must return at the end of the block). Function calls are expected to have no intraprocedural flow control unless you are compiling a language with native exceptions, in which case they are expected to branch to either a continue basic block or an exception handling block.
Most importantly to write the CFI directives required for zero-cost exception handling, you need to know what registers are live, what stack slots need preserving, and so on. The unwinder will walk the tables generated from these directives and ensure that everything is where it's expected to be when it jumps into the exception handler. You can't just stick this in inline asm, because the information that you need doesn't exist until the compiler has finished register allocation.
The veterinary school here (Cambridge) is also trying to increase male intake. It's currently the department with the least equal gender ratio, although skewed towards women.
Graphics drivers have been mostly userspace for a while. Modern GPUs have multiple command queues and IOMMU support (since AGP on x86). The kernel is responsible for allocating a command queue and mapping it to the userspace program's address space, and for setting up shared memory (either in system RAM or in the device's memory, or both, depending on the GPU architecture) that are accessible via DMA from the device and mapped into the process's address space. After that, it gets out of the way. The in-process device driver is responsible for sending commands directly to the card and telling the card to DMA directly to or from the shared segments. The kernel is still responsible for the protection (it defines which bits of memory the GPU is allowed to access), but aside from that it does very little.
Not necessarily. With IOMMUs and various virtualisation features, it's increasingly easy to delegate direct access to the device to userspace code without having to go through the kernel at all. On a multicore system, having a userspace program on one core talking directly to devices and not having to interact with any kernel locking can be quite a bit faster. See, for example, the Barrelfish research OS or the Sandstorm work at SIGCOMM this year for a couple of examples.
To implement the exception handling logic in assembly requires flow control outside of the inline asm block, which is not legal in GNU C (and inline asm is not part of standard C). For zero-cost exception handling to work, you must emit unwind tables that contain information about the locations (on the stack or in registers) of every local variable at each call site. You also make every call a branching (local) flow control construct, which changes the valid compiler transforms you can do. You can, in theory, do this in GNU C by making your entire function an inline asm block that takes the function arguments as input parameters (ooops, might run out of registers if any need to be passed on the stack), but you'll then have to be as good as the compiler at optimising because the optimisers won't touch your code.
The fragile base class problem isn't really specific to C++. Any time you change the size of a kernel struct, you risk breaking the KBI. It's also easier to solve in a language like C++: you can encode the field offsets as relocations so that either the static linker will resolve them if you're in the same binary as the type was declared, or the run-time linker will resolve them at load time for other binaries. This can also give you link-time checking that the fields that you think exist really do.
There already is a de-facto ABI standard that is maintained by most interested parties (i.e. everyone except Microsoft) and nominally edited by CodeSourcery / Mentor Embedded. As the grandparent said, the important point is to have an ABI standard, not a name mangling standard. Having compatible name mangling but different object and vtable layouts would cause far more pain than it would solve. Different compilers would generate incompatible object files, but they'd still link.
No, I also don't understand the COM hate. It's just a standard for vtable layouts and a few other things. It's not even a large standard - compare it to CORBA some time. Apparently some developers don't like well-specified binary interfaces or separation of interface and implementation. Their code is probably best avoided.
In the FreeBSD kernel, we use an object system implemented in C ('KObj'), but the functionality it provides is pretty close to COM, it's just less well documented and doesn't have an IDL (it's only really meant to be used in C). I keep threatening to add a clang C++ ABI that compiles to KObj interfaces...
Apple was burned by this earlier. The IOKit interface for device drivers on OS X used the GCC 2.95 C++ ABI and so they've been forced to add support for this in clang and maintain it. Name mangling isn't the issue though, it's vtable layouts, which are sort-of standard now, in that everyone (except Microsoft) either uses the CodeSourcery Itanium C++ ABI or (in the case of ARM) something with small diffs against that ABI.
The big argument against C++ in the kernel is that it's hard to use the C++ type system without templates and it's hard to use templates without generating so much code that you'll blow your i-cache away. It's fine in a lot of userspace code, where you'll want to spend a lot of time in the template code and so this cost is amortised, but in the kernel (where you typically want to quickly do a small thing) having to pull a lot of code into i-cache and displace a load of userspace code is far from ideal.
Can you clarify? My WP maintains three synced calendars - one for my Exchange work account, one for my personal Google account, and one for Facebook.
Three proprietary protocols for syncing with three entities. No support for either CardDAV / CalDAV so you (or your corporate IT folks) can run your own server, or local sync with a PC so that you can sync without any clouds involved.
It's there in 8.1, just not enabled out of the box. Install the "Files" app from the Store (it's an official app, but for some mysterious reason not preinstalled) - then you can just navigate the folders and open files from them with whatever app subscribed to opening that type of file.
Not entirely sure what you see is missing, but contacts and calendar stuff is synced via your Microsoft account automatically
So you need to store your calendar and contacts with Microsoft to sync? No thank you. iOS doesn't require that you share things with Apple and on Android the default is to share with Google but there are other options.
, and when you open the Office app there is a "phone" option which opens documents on your phone (including the folder which you copy stuff to over USB).
Didn't seem to work. Do you have to copy the files to a specific location?
My girlfriend has a Windows phone (bought in spite of Windows, not because of it - it's the phone with the best camera currently available), so I've spent a bit of time playing with it. I'm really impressed with a lot of what Microsoft has done in terms of usability, but there are lots of obvious omissions in terms of basic functionality. For example, no easy way of syncing calendars or contacts (this is also true on Android if you don't drink the Google Koolaid, but at least there are third-party sync adaptors for CalDAV and CardDAV. iOS supports these open protocols natively, albeit with a few, uh, interesting interpretations of some parts of the protocol). Some things are just really odd omissions. You can plug the phone into a computer and copy PDFs and Word documents to it. It comes with applications that are designed for reading PDFs (Adobe Reader) and editing Word documents (MS Word), but there is no way for these applications to open the things that you've just copied into the phone's documents folder. It really feels like a beta product that should be good by the time it's released - except that Microsoft has been building smartphone operating systems for over a decade.
You're completely misunderstanding the problem. It has nothing to do with flash drives, it has to do with USB devices, some of which happen to appear as block devices. Every USB device that you plug in has a controller chip, which runs a small program (the firmware) that implements the client part of the USB specification. Some of these are quite complex. There was an attack a few years ago on USB keyboards: some models come with 128KB of flash but only use 65KB for the firmware. You can replace the firmware with something malicious and have 31KB to cache keylog data for emptying when you plug in a specific device.
The firmware on the controller chips is not public, not audited, and generally written by people who have no idea about security. If there's a bug in it that allows a compromise, then you can use the controller to attack the host system. Lots of USB drivers behave poorly in the presence of malformed USB protocol messages, so all you need is to find one buffer overflow and you've got a kernel-mode exploit. Worse, some of the vulnerabilities are not in the drivers, but in the firmware of the USB host controller chip on the motherboard. If you can compromise that, then you can sniff a load of messages going across the bus in a way that's completely undetectable from the OS.
The problem with suing people who have lots of money is that they can afford good lawyers - and it shouldn't take a very good lawyer to get something this stupid thrown out of court. Typically when people do this, they want to have an out-of-court settlement, where Google agrees to pay $1 (cheaper than a few minutes of lawyer time) and neither side is allowed to disclose the terms of the settlement. They can then go to the next company and say 'Google didn't feel able to fight this in court and agreed to a settlement where they paid us compensation, you have less money to spend on lawyers than them, so you should pay us compensation too'.
A big part of IBM's legal policy of millions for defence, not one dollar for tribute, is that they used to be the company that everyone went to for this kind of (not legally binding, but useful for marketing) precedent. Once you get a reputation for fighting every case and countersuing if you win, then fewer trolls bother you...
People in the UK make fun of the intelligence of the Irish and then say that the single-transferable vote system (used in Ireland) would be too complicated for the English voter, so don't be too surprised.
The dhcp client in OS X runs sandboxed (I believe), so there's less potential for an attacker to exploit it if they can make it run arbitrary things - it doesn't have general filesystem access.
Currently I am using the local calendar adapter for Google calendar, from F-droid. Works well. There is a similar CalDAV adapter too - doesn't it work nicely with owncloud? I was hoping to use it some day.
The issue I'be had with it is that it doesn't really do merging, it does 'server always wins'. This means that if you delete an event locally, on the next sync it will reappear. It's fine for new events created on the device and for events created elsewhere if you just want to view them on the device. I use owncloud on the server and iCal on my laptop and editing things on either of those is fine.
Anyway, that was my point. Google and the other big 4, really do good UI - much as I hate to expose my data for their inspection.
The reason I stopped using the search engine was that they made a UI that pissed me off enough to make me quit. I've not found Google UIs to be particularly well designed in general - I could file a few hundred UI bug reports on the general Android system, including a lot that are regressions.
One use case that's often touted for this kind of thing is having appliances that can work on spot pricing for electricity. Over the course of the day, you get spikes from solar and wind (and tidal and so on) production when electricity is cheap. You get periods when power plants need to reduce capacity for maintenance when it is expensive. There are massive power storage facilities that profit from this: there is one near where I used to live that pumps water up a hill into a reservoir when electricity is cheap and then lets it flow down again and generate power when it's expensive. Now imagine if your fridge or freezer could get this information in real time and could run the compressor a bit more when electricity is very cheap, then use the cooled coolant to keep your food cold when the price goes up.
Almost 50% of the electricity generated in the USA is wasted because the supply can't adapt to demand fast enough. There are some very big savings to be made by having demand adapt to supply.
It's not abusing anything Google apps work better and use less resources than the competitors which is 1 reason why they are doing this.
Really? About the only Google app that I haven't replaced with something better (and open source, so money / distribution rights are not an issue) is Google Play, and that's only because my bank and a few other companies only make their app available via Google Play.
A few of the HTC apps were nicer than the AOSP versions and the same is true of the Motorola ones. The problem for people who don't drink the Google kool-aid is that hardly anyone is working on the AOSP versions of most apps. If you buy a new Android device, there's no calendar app that can talk to a CalDav server (which, for example, any iOS device and most open source calendar apps for desktop can do out of the box). F-Droid has one that is designed to, but it has a terrible UI and doesn't integrate nicely with the rest of the system. There are a couple of sync adaptors, but Google has increasingly broken the sync APIs for things that are not Google.
I completely agree. If you try to become involved with an open source project because you think it would be fun, your enthusiasm will likely fizzle out fairly quickly. If you try to become involved with an open source project because you actually want to use it and want want to improve it, then every time that it doesn't do something that you need then you'll find yourself with a project. One of the nice things about a project like FreeBSD (to give an example of a project that I'm heavily involved in - there are others that have this attribute) is that there are enough small parts that it's easy to find small projects in the individual components to keep yourself occupied.
The real problem has nothing to do with types, it has to do with design compromises to work around the fact that UNIX lacked shared libraries. Rather than provide a glob function that everyone could use (as with later versions of UNIX, after shared libraries were added), they put globing in the shell. This meant that the shell became responsible for handling some arguments, the command for handling others. As a natural consequence, you needed to provide a mechanism to escape the command-line arguments that you didn't want the shell to get at. And then you start using shell invocations as your mechanism of running programs (via the system() C library call) and now you need double escaping or triple escaping and so on.
Slashdot Mirror
Cuteness and familiarity. Most people rarely come into contact with lambs. I grew up in a village surrounded by farms and I remember that a number of children wouldn't eat lambs because they were cute (although the ones that grew up on the farms mostly didn't have this objection). Most people in the west either have owned a dog or have a friend who owns one though and so it's much harder to regard a dog as food. If you come from somewhere where dogs are not kept as pets and the wild ones are just disease-carrying creatures that prey on your livestock, then it's much easier to eat them.
Cuteness in the abstract, without direct contact, isn't enough.
As I said earlier, it means that the C code can't call any functions. It also can't handle the exceptions. You could do every function call in an inline asm block (making sure that every live variable in the function was in input argument to the block, so that you can ensure that they're preserved) and then have that block set a variable that you then branched on, but then you're combining the worst of both worlds. You're not getting the 'zero cost' bit of 'zero cost exceptions', because you're testing whether an exception was thrown after each call. You're also not getting the low-cost-when-used properties of normal C error code checking, because to get to the error path you're having to go through the (very slow) generic stack unwinder.
To efficiently make use of zero-cost exceptions in C, by which I mean having an error-handling path that does not incur any cost (including branch predictor state) when not used, you'd have to write your entire try/catch block in the inline assembly. At that point, you're not writing C, you're writing assembly and just using a C compiler.
No what doesn't? You obviously have no idea how a modern (or even not-so-modern) compiler works. The vast majority of optimisations depend on having an accurate control flow graph. Inline asm is assumed to have no flow control (it's allowed to call functions, but it must either not return at all, or must return at the end of the block). Function calls are expected to have no intraprocedural flow control unless you are compiling a language with native exceptions, in which case they are expected to branch to either a continue basic block or an exception handling block.
Most importantly to write the CFI directives required for zero-cost exception handling, you need to know what registers are live, what stack slots need preserving, and so on. The unwinder will walk the tables generated from these directives and ensure that everything is where it's expected to be when it jumps into the exception handler. You can't just stick this in inline asm, because the information that you need doesn't exist until the compiler has finished register allocation.
The veterinary school here (Cambridge) is also trying to increase male intake. It's currently the department with the least equal gender ratio, although skewed towards women.
Graphics drivers have been mostly userspace for a while. Modern GPUs have multiple command queues and IOMMU support (since AGP on x86). The kernel is responsible for allocating a command queue and mapping it to the userspace program's address space, and for setting up shared memory (either in system RAM or in the device's memory, or both, depending on the GPU architecture) that are accessible via DMA from the device and mapped into the process's address space. After that, it gets out of the way. The in-process device driver is responsible for sending commands directly to the card and telling the card to DMA directly to or from the shared segments. The kernel is still responsible for the protection (it defines which bits of memory the GPU is allowed to access), but aside from that it does very little.
Not necessarily. With IOMMUs and various virtualisation features, it's increasingly easy to delegate direct access to the device to userspace code without having to go through the kernel at all. On a multicore system, having a userspace program on one core talking directly to devices and not having to interact with any kernel locking can be quite a bit faster. See, for example, the Barrelfish research OS or the Sandstorm work at SIGCOMM this year for a couple of examples.
To implement the exception handling logic in assembly requires flow control outside of the inline asm block, which is not legal in GNU C (and inline asm is not part of standard C). For zero-cost exception handling to work, you must emit unwind tables that contain information about the locations (on the stack or in registers) of every local variable at each call site. You also make every call a branching (local) flow control construct, which changes the valid compiler transforms you can do. You can, in theory, do this in GNU C by making your entire function an inline asm block that takes the function arguments as input parameters (ooops, might run out of registers if any need to be passed on the stack), but you'll then have to be as good as the compiler at optimising because the optimisers won't touch your code.
The fragile base class problem isn't really specific to C++. Any time you change the size of a kernel struct, you risk breaking the KBI. It's also easier to solve in a language like C++: you can encode the field offsets as relocations so that either the static linker will resolve them if you're in the same binary as the type was declared, or the run-time linker will resolve them at load time for other binaries. This can also give you link-time checking that the fields that you think exist really do.
There already is a de-facto ABI standard that is maintained by most interested parties (i.e. everyone except Microsoft) and nominally edited by CodeSourcery / Mentor Embedded. As the grandparent said, the important point is to have an ABI standard, not a name mangling standard. Having compatible name mangling but different object and vtable layouts would cause far more pain than it would solve. Different compilers would generate incompatible object files, but they'd still link.
No, I also don't understand the COM hate. It's just a standard for vtable layouts and a few other things. It's not even a large standard - compare it to CORBA some time. Apparently some developers don't like well-specified binary interfaces or separation of interface and implementation. Their code is probably best avoided.
In the FreeBSD kernel, we use an object system implemented in C ('KObj'), but the functionality it provides is pretty close to COM, it's just less well documented and doesn't have an IDL (it's only really meant to be used in C). I keep threatening to add a clang C++ ABI that compiles to KObj interfaces...
Apple was burned by this earlier. The IOKit interface for device drivers on OS X used the GCC 2.95 C++ ABI and so they've been forced to add support for this in clang and maintain it. Name mangling isn't the issue though, it's vtable layouts, which are sort-of standard now, in that everyone (except Microsoft) either uses the CodeSourcery Itanium C++ ABI or (in the case of ARM) something with small diffs against that ABI.
The big argument against C++ in the kernel is that it's hard to use the C++ type system without templates and it's hard to use templates without generating so much code that you'll blow your i-cache away. It's fine in a lot of userspace code, where you'll want to spend a lot of time in the template code and so this cost is amortised, but in the kernel (where you typically want to quickly do a small thing) having to pull a lot of code into i-cache and displace a load of userspace code is far from ideal.
Can you clarify? My WP maintains three synced calendars - one for my Exchange work account, one for my personal Google account, and one for Facebook.
Three proprietary protocols for syncing with three entities. No support for either CardDAV / CalDAV so you (or your corporate IT folks) can run your own server, or local sync with a PC so that you can sync without any clouds involved.
It's there in 8.1, just not enabled out of the box. Install the "Files" app from the Store (it's an official app, but for some mysterious reason not preinstalled) - then you can just navigate the folders and open files from them with whatever app subscribed to opening that type of file.
Thanks!
I don't think she's seen an automatic update, what's the procedure for updating?
Not entirely sure what you see is missing, but contacts and calendar stuff is synced via your Microsoft account automatically
So you need to store your calendar and contacts with Microsoft to sync? No thank you. iOS doesn't require that you share things with Apple and on Android the default is to share with Google but there are other options.
, and when you open the Office app there is a "phone" option which opens documents on your phone (including the folder which you copy stuff to over USB).
Didn't seem to work. Do you have to copy the files to a specific location?
My girlfriend has a Windows phone (bought in spite of Windows, not because of it - it's the phone with the best camera currently available), so I've spent a bit of time playing with it. I'm really impressed with a lot of what Microsoft has done in terms of usability, but there are lots of obvious omissions in terms of basic functionality. For example, no easy way of syncing calendars or contacts (this is also true on Android if you don't drink the Google Koolaid, but at least there are third-party sync adaptors for CalDAV and CardDAV. iOS supports these open protocols natively, albeit with a few, uh, interesting interpretations of some parts of the protocol). Some things are just really odd omissions. You can plug the phone into a computer and copy PDFs and Word documents to it. It comes with applications that are designed for reading PDFs (Adobe Reader) and editing Word documents (MS Word), but there is no way for these applications to open the things that you've just copied into the phone's documents folder. It really feels like a beta product that should be good by the time it's released - except that Microsoft has been building smartphone operating systems for over a decade.
You're completely misunderstanding the problem. It has nothing to do with flash drives, it has to do with USB devices, some of which happen to appear as block devices. Every USB device that you plug in has a controller chip, which runs a small program (the firmware) that implements the client part of the USB specification. Some of these are quite complex. There was an attack a few years ago on USB keyboards: some models come with 128KB of flash but only use 65KB for the firmware. You can replace the firmware with something malicious and have 31KB to cache keylog data for emptying when you plug in a specific device.
The firmware on the controller chips is not public, not audited, and generally written by people who have no idea about security. If there's a bug in it that allows a compromise, then you can use the controller to attack the host system. Lots of USB drivers behave poorly in the presence of malformed USB protocol messages, so all you need is to find one buffer overflow and you've got a kernel-mode exploit. Worse, some of the vulnerabilities are not in the drivers, but in the firmware of the USB host controller chip on the motherboard. If you can compromise that, then you can sniff a load of messages going across the bus in a way that's completely undetectable from the OS.
The problem with suing people who have lots of money is that they can afford good lawyers - and it shouldn't take a very good lawyer to get something this stupid thrown out of court. Typically when people do this, they want to have an out-of-court settlement, where Google agrees to pay $1 (cheaper than a few minutes of lawyer time) and neither side is allowed to disclose the terms of the settlement. They can then go to the next company and say 'Google didn't feel able to fight this in court and agreed to a settlement where they paid us compensation, you have less money to spend on lawyers than them, so you should pay us compensation too'.
A big part of IBM's legal policy of millions for defence, not one dollar for tribute, is that they used to be the company that everyone went to for this kind of (not legally binding, but useful for marketing) precedent. Once you get a reputation for fighting every case and countersuing if you win, then fewer trolls bother you...
People in the UK make fun of the intelligence of the Irish and then say that the single-transferable vote system (used in Ireland) would be too complicated for the English voter, so don't be too surprised.
The dhcp client in OS X runs sandboxed (I believe), so there's less potential for an attacker to exploit it if they can make it run arbitrary things - it doesn't have general filesystem access.
Currently I am using the local calendar adapter for Google calendar, from F-droid. Works well. There is a similar CalDAV adapter too - doesn't it work nicely with owncloud? I was hoping to use it some day.
The issue I'be had with it is that it doesn't really do merging, it does 'server always wins'. This means that if you delete an event locally, on the next sync it will reappear. It's fine for new events created on the device and for events created elsewhere if you just want to view them on the device. I use owncloud on the server and iCal on my laptop and editing things on either of those is fine.
Anyway, that was my point. Google and the other big 4, really do good UI - much as I hate to expose my data for their inspection.
The reason I stopped using the search engine was that they made a UI that pissed me off enough to make me quit. I've not found Google UIs to be particularly well designed in general - I could file a few hundred UI bug reports on the general Android system, including a lot that are regressions.
One use case that's often touted for this kind of thing is having appliances that can work on spot pricing for electricity. Over the course of the day, you get spikes from solar and wind (and tidal and so on) production when electricity is cheap. You get periods when power plants need to reduce capacity for maintenance when it is expensive. There are massive power storage facilities that profit from this: there is one near where I used to live that pumps water up a hill into a reservoir when electricity is cheap and then lets it flow down again and generate power when it's expensive. Now imagine if your fridge or freezer could get this information in real time and could run the compressor a bit more when electricity is very cheap, then use the cooled coolant to keep your food cold when the price goes up.
Almost 50% of the electricity generated in the USA is wasted because the supply can't adapt to demand fast enough. There are some very big savings to be made by having demand adapt to supply.
It's not abusing anything Google apps work better and use less resources than the competitors which is 1 reason why they are doing this.
Really? About the only Google app that I haven't replaced with something better (and open source, so money / distribution rights are not an issue) is Google Play, and that's only because my bank and a few other companies only make their app available via Google Play.
A few of the HTC apps were nicer than the AOSP versions and the same is true of the Motorola ones. The problem for people who don't drink the Google kool-aid is that hardly anyone is working on the AOSP versions of most apps. If you buy a new Android device, there's no calendar app that can talk to a CalDav server (which, for example, any iOS device and most open source calendar apps for desktop can do out of the box). F-Droid has one that is designed to, but it has a terrible UI and doesn't integrate nicely with the rest of the system. There are a couple of sync adaptors, but Google has increasingly broken the sync APIs for things that are not Google.
I completely agree. If you try to become involved with an open source project because you think it would be fun, your enthusiasm will likely fizzle out fairly quickly. If you try to become involved with an open source project because you actually want to use it and want want to improve it, then every time that it doesn't do something that you need then you'll find yourself with a project. One of the nice things about a project like FreeBSD (to give an example of a project that I'm heavily involved in - there are others that have this attribute) is that there are enough small parts that it's easy to find small projects in the individual components to keep yourself occupied.
The real problem has nothing to do with types, it has to do with design compromises to work around the fact that UNIX lacked shared libraries. Rather than provide a glob function that everyone could use (as with later versions of UNIX, after shared libraries were added), they put globing in the shell. This meant that the shell became responsible for handling some arguments, the command for handling others. As a natural consequence, you needed to provide a mechanism to escape the command-line arguments that you didn't want the shell to get at. And then you start using shell invocations as your mechanism of running programs (via the system() C library call) and now you need double escaping or triple escaping and so on.