I live in Belgium. If I go to the supermarket I pay with a credit card. The company I buy it will not be able to do any profiling as they do not keep the card info, only the transaction info. That is why they really want me to use a store card with points. I do not do that.
Not true. From talking to the head of IT at one of the big supermarket chains, they won't keep your CC info (PCI compliance prevents this), but they will keep a salted hash of your card number and there's no rule against them also storing your name (so if they see two people with the same name but different cc hashes at the same store, they can aggregate them).
Perhaps more interesting: they don't actually do anything with this data. Knowing about you is of very little value to them. The want to know about aggregates, because the kind of decisions that they're making is which lines to stock in limited shelf space in each store. The only time that knowing about individuals is useful is when they own a large store and a small store that you shop at, so they can correlate the things that you buy at the large store with things that they don't stock at the small store and start carrying those things in the small store.
the other risks that is not considered is falling into debt. If you are not careful, you will be robbed by banks with late fees and high interest rates
You don't have to be that careful. Set the credit card to be paid automatically from your bank account, make sure that you have as much money in that account as your card's credit limit. You then get 15-45 days of interest-free loan, where you can be earning interest on the money (which you don't get if you're carrying cash). You also then get an itemised list of exactly where and when you spent the money.
People don't fall into debt with cash, but they do with credit cards.
Not even slightly true. A common pattern for people who go into debt is to take small amounts out of cash machines, spend it, get 2/3 of the way through the month, not be able to tell where their money has gone because they're not keeping detailed records of their spending (with cash it's so easy to make a purchase and forget - there's no automatic record) and then need to borrow money for recurring expenses at the end of the month (e.g. rent).
Credit cards can easily be used to rack up a few hundred to thousands in debt before you get to cancel them, and getting the old one cancelled and the new one delivered is a time-robbing pain.
From this, I can tell that either you've never actually been through this process, or your card issuer is truly terrible.
If someone steals my cash, that's all they've got; if someone gets my credit card, I'm not so sure.
I've had my card cloned three times[1]. Each time, my card company called me to query transactions, I identified the ones that were not mine, and they refunded them before issuing my bill, so the total cost to me was about 5 minutes on the phone.
[1] Two times after trips to the USA: you guys suck at card security - here a merchant is in violation of the merchant bank's T&Cs if the card is ever out of the owner's possession, there waiters normally walk away with it, don't do the transaction in realtime, and rely on a piece of paper with a hand-scrawled amount to indicate it. The third time was after a place I'd shopped at had its DB compromised.
There was a study a few years back that was linked on Slashdot. The take-home was that the relative cost of accepting cash vs credit cards differs depending on the size of your business. Credit cards charge a flat n% of your takings, though for a sufficiently large business that n will be lower. Cash requires employee time to balance the tills, managing change, extra accounting time (or more expensive tills that count cash automatically), on-site security, security to transport the cash to the bank, liability for counterfeits (fake £20s are surprisingly common in the UK and US notes seem to be specifically designed to be easy to forge - a single person spending $200 with counterfeit notes that you don't notice but your bank does costs you more than $6500 spent on credit cards), and so on. Most of these costs are quite low if you have a low turnover, but grow quickly. I don't remember where the inflection point was, but it was smaller than I'd have thought.
I've not seen a credit card like this, but the Visa Electron and Mastercard Maestro both do. They're debit cards, but ones that are only allowed for realtime-verified transactions. They're given to people under 18 (who can't legally go into debt, so if they go overdrawn the bank has no legal means to reclaim the money) and people with bad credit. A normal debit card may be used for offline purchases, where the merchant files the request with the bank later, so multiple transactions hitting at the same time can cause an account to be overdrawn and the bank will still honour them. Instead, these cards will have transactions declined if they can't atomically deduct the money from your account and have you not go overdrawn. The mechanical readers are intrinsically incompatible with this model and so they're not embossed to ensure that they're never accidentally used with them.
Your $500 Android is more valuable to them than a couple of tens or twenties
Depends on whether they're opportunistic or if they've been doing it enough to have contacts with fences (a fairly small proportion of muggers, according to a criminologist friend). In the US and EU, you can block a phone from being able to connect to any mobile network very quickly after it's been stolen, so most legitimate second-hand phone shops will not pay cash for a phone from a walk in - it may turn into a brick before they can sell it. The only people that will buy a known stolen mobile are people with contacts that can ship them abroad, typically to the middle east (where the operators don't bother with the block lists, because locally stolen phones are not a big issue and a lot of their customers have phones stolen abroad and would be unhappy if they stopped working). They'll typically only pay the thief $20 for that $400 phone, so the $20 in your wallet is more valuable because they don't have to go to the fence to be able to spend it.
posix_spawn still does the fork/exec. It is a library function after all, not a system call.
That's true on FreeBSD, and I think it's true on Linux. It's not true on NetBSD, XNU or Solaris, and I don't think it's true on AIX either. posix_spawn was designed to be possible to implement as a library routine, but (particularly in the presence of threads) it's much more efficient to implement it in the kernel.
And it doesn't take as long as you seem to think to mark things COW.
On a system designed for it, no it's not terribly expensive (though the IPIs required for synchronising the page tables across multiple cores actually add quite a bit to the cost on modern hardware), but on a kernel not designed for fork (such as Windows NT), it's expensive to do it post factor.
It only marks open file descriptors, not devices. A much shorter list. Usually only three, stdin/stdout/stderr. There can be more though, but rarely over 5.
Not even slightly true.
One of the reasons Windows isn't used for supercomputers
And that's where I can tell that you have no idea what you're talking about. Thread creation time is completely irrelevant to supercomputing (as are most OS processes). Supercomputing workloads aim to spend 100% of their time in the userspace code that's actually solving the problem. They usually run the entire network stack in userspace to avoid kernel entry (Infiniband has supported this for decades, modern Ethernet NICs do now for low-end systems), set one thread per core, pin it, and avoid entering the scheduler. They also typically try to avoid any I/O. There are several reasons why Windows isn't used in supercomputers (license fees, difficulty of customisation by third parties), but that's definitely not one of them.
Fork is heavily optimised on *NIX operating systems, because it's the primary way of creating new processes. Unfortunately, it's also a completely brain-dead one. It originates from old systems that had the running process in one form of storage and switched by writing it out to another. Fork made sense then, because you'd create the new process by writing out your current state and still have a copy of it in online storage for free. On modern systems, you need to mark all of the memory copy-on-write, create copies of the file descriptor table in the kernel (incrementing reference counts for all open devices) and do fairly complex things with each thread.
Windows post-dates the systems where fork made sense as an abstraction and so combines creating and launching a new process into the same operation (modern *NIX systems do this with posix_spawn as well). Implementing fork on Windows requires emulating all of the behaviour of fork: you have to create a new process with a copy of the current file descriptor set and then set up CoW shared memory mappings for all of your memory. If you're then doing an exec afterwards, then this is entirely wasted effort.
This issue didn't exist, so someone went and added synchronisation around the tear-down process. Why? People don't generally add mutexes at random, so this was probably done because they found a race condition in process tear-down that resulted in either a resource leak or kernel data structure corruption. Simply removing the mutex will probably fix this problem, but make the computer either run out of some kind of resources or crash. Probably not the correct fix...
Often, it isn't. Harassment implies sustained pattern of behaviour, but the legal definition (at least in the UK) does not and the problem with this is that it often trivialises real problems. Humans are pack animals and a sustained pattern of behaviour that isolates someone from their pack and demeans them can have real mental health consequences. Calling someone an asshat once almost certainly won't (unless everyone does it to the same person). Counting the two in the same category does a serious disservice to people who are actually harassed.
I've replied above, but I don't think you do want to buy software and expect it to work. If you did, then you'd only buy formally verified software and accept that it cost 30-1000 times (NICTA's estimates to NASA's) as much. You have three choices:
Option one, buy an OS that will cost around $3,000 - $10,000 per license if you can get enough people to buy it that the volumes are similar to Windows, more otherwise. You'll get a formally verified system and can be sure that it works as intended.
Option 2, buy a cheap COTS OS, such as Windows, Linux or *BSD, and expect that there are bugs. These will be fixed on a triage basis, with the ones that affect the most people being fixed first. If you want to have more control over which ones are fixed then buy a support contract for an open source system that explicitly states that the bugs that affect you will be prioritised (this will likely cost more than a Windows license, and will be a recurring cost, but at least you'll be affected by fewer bugs).
Option 3, buy a verified but much simpler (no power management, no multicore support, no GPU support, few drivers, trivial filesystem) OS for around the same price as a COTS OS ($0-200ish).
You, and most other people, have chosen option 2. You're not willing to pay the cost of developing correct complex software and you're not willing to put up with the limitations of software that's simple enough to be cost effective to verify.
My response to that is that they should have ironed out enough of the bugs to where they can say that the product is fit for sale as advertised... or not sold the software at all
A number of the security fixes in Windows (and *NIX) over a typical deployment are against attacks that didn't exist when the product first shipped. Are you saying that they should have a QA system that predicts which future attack vectors will exist and protects against them? Other bugs only show up when software does sequences of operations that no software in existence at the time of shipping performed. Some of these can be found with fuzz testing, but that's always a probabilistic approach because the total sequence of possible combinations is infeasible (within the lifetime of the universe) to search exhaustively.
Are you willing to pay for it? The current cost record for a formally verified system is held by the NICTA team behind seL4. Their development methodology costs a mere 30 times as much as a current best-practices QA setup. Would you pay $3,000 for a Windows license? Because that's the absolute minimum that it would cost for a bug-free Windows version (and that's assuming that the verification techniques used by seL4 would scale linearly in cost from a 10KLoC project up to a multi million LoC project like Windows).
The flip side of this is that people want a one-time payment but not a one-time purchase. They don't want to just buy Windows, they want to buy Windows and a multi-year supply of security and bug fixes. This seems like a better model to me: it hopefully gives Microsoft a financial incentive to keep versions of Windows that people actually want to use supported, rather than killing them and pushing people to buy new ones if they want security updates.
In the real world, spectrum would be property and interference would be trespassing, as was being developed in the courts before the government laid claim on the entire spectrum.
Without a government-enforced license, how do you treat spectrum as property? I own all electromagnetic radiation that passes through my land (with no limit on altitude?) and can block anything that I want? How would you ever create a mobile network if that were the case?
The growth in use of permissive licenses (particularly if you look at github) over restrictive ones is a demonstration of pragmatism and the idea that not everything must be free and we can have non-free and free components working together and cooperating rather than focussing on a pure free software ideology.
I wouldn't necessarily even go that far. I am entirely in favour of a world in which all software comes with the FSF's four freedoms. The reason I release code under FreeBSD / MIT licenses is that this seems like a path that has an actual transition plan. If there's a BSDL project available that does 90% of what you need, then you can adopt it and add the remaining 10% without needing to change your business model. Most of the time, it's then cheaper to release the code. If it doesn't give you a competitive advantage, then upstreaming your changes means that your maintenance costs go down (and, often, other people will fix your bugs, in exchange for being able to use your new features).
If there's only a GPL'd project available, then I've worked with a lot of companies that aren't 100% sure that they will never want to do anything that the GPL prohibits and so will instead write a proprietary version (if you're lucky, you can persuade them to write a permissively licensed version). The GPL'd project doesn't ever enter the company (particularly with GPLv3, where anyone who owns patents gets very nervous) and so they never see the benefits of Free Software. It doesn't provide them with a transition path.
This transition path is particularly important because around 90% of all software developers are employed by companies that are not primarily computer companies. They are developing software for in-house use and so implicitly have all of the four freedoms (because they own the copyright), but don't contribute anything to the wider ecosystem (other than money to Microsoft, Oracle, SAP, and so on). Getting them to start using, contributing to, and then preferring open source solutions can unlock a lot of developer resources.
The initial ban (at least in the UK) was not on leaded petrol, but on the sale of new petrol vehicles that could not run on unleaded. That sounds pretty similar to the current ban under discussion to me.
That's not always true. Different plants have different growing requirements and often the ones that are good for making oil can grow in land that isn't particularly suitable for growing food crops. This becomes even more apparent when you factor in algae (currently the most energy efficient crop for producing oil, though not economical because of the infrastructure required), which doesn't compete at all with the kinds of land that are good for most food plants that people want to eat (various forms of seaweed are particularly nutritious, but not very popular, though they're increasingly being used as a base and source of nutrients in various forms of processed food).
Many of those processes can use vegetable oils just as easily though. When you start with crude oil, you first have to split it into different hydrocarbon chain lengths, and you then crack and polymerise it until you have the lengths that you actually want. There's a lot less variation in vegetable oils than in crude, and it's just a matter of energy to transform them - the nice thing about crude oil is that there's often enough energy from burning the bits that have too high an energy cost to want to transform into useful hydrocarbons to power a lot of these processes. If you have another abundant energy source, then the cost of shipping crude oil from the middle east may outweigh the cost of producing the hydrocarbons that you want from locally grown oil crops.
That variation is already present in every linked program anyway.
To a degree, yes, though in practice it's fairly deterministic and so you tend to only explore a smallish part of the overall space by accident.
This just changes the dice-roll from only once at build time to each and every boot time. Surely it would suck more to get a randomly slow link at build time and then be stuck with it?
Not really - predictable slowness is a lot easier to reason about and work around than unpredictable slowness. On a single machine, knowing that something will take 12 minutes is a lot easier to deal with than finding that yesterday it took 8 but today will take 12. Trying to debug a performance problem in userspace code can be very painful if the OS is unpredictable. In a networked system, if every node takes 100ms to respond, that's annoying, but if they all take 80-120ms to respond then your overall performance is typically limited by the 120ms (Twitter is a good example of this: their response time was limited by the fact that, on average, at least one of the machines that needed to respond to create a page for the user would be in the middle of a GC cycle and so respond a lot more slowly than the rest. They fixed it by forcing GC on a fixed interval so that all machines were slow for a few ms, then fast again for a while until the next GC tick).
This is a concern. The work appears to be based on work from UPenn, which compiled everything with -ffunction-sections and -fdata-sections (if you don't do this, it turns out that you leak enough information to find gadgets quite easily) and re-linked programs in a random order on each run (there's a lot of subsequent work on doing it more often, such as the ReRANZ paper at VEE this year). It's not too difficult to debug, because you record the random number seed with the binary and include it in core dumps, which lets someone else reconstruct the exact implementation. The other concern is that randomising the link order has been shown (ASPLOS 2015) to have around a plus or minus 20% impact on performance. Having that variation across reboots for the kernel could be quite frustrating.
Slashdot Mirror
I live in Belgium. If I go to the supermarket I pay with a credit card. The company I buy it will not be able to do any profiling as they do not keep the card info, only the transaction info. That is why they really want me to use a store card with points. I do not do that.
Not true. From talking to the head of IT at one of the big supermarket chains, they won't keep your CC info (PCI compliance prevents this), but they will keep a salted hash of your card number and there's no rule against them also storing your name (so if they see two people with the same name but different cc hashes at the same store, they can aggregate them).
Perhaps more interesting: they don't actually do anything with this data. Knowing about you is of very little value to them. The want to know about aggregates, because the kind of decisions that they're making is which lines to stock in limited shelf space in each store. The only time that knowing about individuals is useful is when they own a large store and a small store that you shop at, so they can correlate the things that you buy at the large store with things that they don't stock at the small store and start carrying those things in the small store.
the other risks that is not considered is falling into debt. If you are not careful, you will be robbed by banks with late fees and high interest rates
You don't have to be that careful. Set the credit card to be paid automatically from your bank account, make sure that you have as much money in that account as your card's credit limit. You then get 15-45 days of interest-free loan, where you can be earning interest on the money (which you don't get if you're carrying cash). You also then get an itemised list of exactly where and when you spent the money.
People don't fall into debt with cash, but they do with credit cards.
Not even slightly true. A common pattern for people who go into debt is to take small amounts out of cash machines, spend it, get 2/3 of the way through the month, not be able to tell where their money has gone because they're not keeping detailed records of their spending (with cash it's so easy to make a purchase and forget - there's no automatic record) and then need to borrow money for recurring expenses at the end of the month (e.g. rent).
Credit cards can easily be used to rack up a few hundred to thousands in debt before you get to cancel them, and getting the old one cancelled and the new one delivered is a time-robbing pain.
From this, I can tell that either you've never actually been through this process, or your card issuer is truly terrible.
If someone steals my cash, that's all they've got; if someone gets my credit card, I'm not so sure.
I've had my card cloned three times[1]. Each time, my card company called me to query transactions, I identified the ones that were not mine, and they refunded them before issuing my bill, so the total cost to me was about 5 minutes on the phone.
[1] Two times after trips to the USA: you guys suck at card security - here a merchant is in violation of the merchant bank's T&Cs if the card is ever out of the owner's possession, there waiters normally walk away with it, don't do the transaction in realtime, and rely on a piece of paper with a hand-scrawled amount to indicate it. The third time was after a place I'd shopped at had its DB compromised.
There was a study a few years back that was linked on Slashdot. The take-home was that the relative cost of accepting cash vs credit cards differs depending on the size of your business. Credit cards charge a flat n% of your takings, though for a sufficiently large business that n will be lower. Cash requires employee time to balance the tills, managing change, extra accounting time (or more expensive tills that count cash automatically), on-site security, security to transport the cash to the bank, liability for counterfeits (fake £20s are surprisingly common in the UK and US notes seem to be specifically designed to be easy to forge - a single person spending $200 with counterfeit notes that you don't notice but your bank does costs you more than $6500 spent on credit cards), and so on. Most of these costs are quite low if you have a low turnover, but grow quickly. I don't remember where the inflection point was, but it was smaller than I'd have thought.
I've not seen a credit card like this, but the Visa Electron and Mastercard Maestro both do. They're debit cards, but ones that are only allowed for realtime-verified transactions. They're given to people under 18 (who can't legally go into debt, so if they go overdrawn the bank has no legal means to reclaim the money) and people with bad credit. A normal debit card may be used for offline purchases, where the merchant files the request with the bank later, so multiple transactions hitting at the same time can cause an account to be overdrawn and the bank will still honour them. Instead, these cards will have transactions declined if they can't atomically deduct the money from your account and have you not go overdrawn. The mechanical readers are intrinsically incompatible with this model and so they're not embossed to ensure that they're never accidentally used with them.
Your $500 Android is more valuable to them than a couple of tens or twenties
Depends on whether they're opportunistic or if they've been doing it enough to have contacts with fences (a fairly small proportion of muggers, according to a criminologist friend). In the US and EU, you can block a phone from being able to connect to any mobile network very quickly after it's been stolen, so most legitimate second-hand phone shops will not pay cash for a phone from a walk in - it may turn into a brick before they can sell it. The only people that will buy a known stolen mobile are people with contacts that can ship them abroad, typically to the middle east (where the operators don't bother with the block lists, because locally stolen phones are not a big issue and a lot of their customers have phones stolen abroad and would be unhappy if they stopped working). They'll typically only pay the thief $20 for that $400 phone, so the $20 in your wallet is more valuable because they don't have to go to the fence to be able to spend it.
posix_spawn still does the fork/exec. It is a library function after all, not a system call.
That's true on FreeBSD, and I think it's true on Linux. It's not true on NetBSD, XNU or Solaris, and I don't think it's true on AIX either. posix_spawn was designed to be possible to implement as a library routine, but (particularly in the presence of threads) it's much more efficient to implement it in the kernel.
And it doesn't take as long as you seem to think to mark things COW.
On a system designed for it, no it's not terribly expensive (though the IPIs required for synchronising the page tables across multiple cores actually add quite a bit to the cost on modern hardware), but on a kernel not designed for fork (such as Windows NT), it's expensive to do it post factor.
It only marks open file descriptors, not devices. A much shorter list. Usually only three, stdin/stdout/stderr. There can be more though, but rarely over 5.
Not even slightly true.
One of the reasons Windows isn't used for supercomputers
And that's where I can tell that you have no idea what you're talking about. Thread creation time is completely irrelevant to supercomputing (as are most OS processes). Supercomputing workloads aim to spend 100% of their time in the userspace code that's actually solving the problem. They usually run the entire network stack in userspace to avoid kernel entry (Infiniband has supported this for decades, modern Ethernet NICs do now for low-end systems), set one thread per core, pin it, and avoid entering the scheduler. They also typically try to avoid any I/O. There are several reasons why Windows isn't used in supercomputers (license fees, difficulty of customisation by third parties), but that's definitely not one of them.
Fork is heavily optimised on *NIX operating systems, because it's the primary way of creating new processes. Unfortunately, it's also a completely brain-dead one. It originates from old systems that had the running process in one form of storage and switched by writing it out to another. Fork made sense then, because you'd create the new process by writing out your current state and still have a copy of it in online storage for free. On modern systems, you need to mark all of the memory copy-on-write, create copies of the file descriptor table in the kernel (incrementing reference counts for all open devices) and do fairly complex things with each thread.
Windows post-dates the systems where fork made sense as an abstraction and so combines creating and launching a new process into the same operation (modern *NIX systems do this with posix_spawn as well). Implementing fork on Windows requires emulating all of the behaviour of fork: you have to create a new process with a copy of the current file descriptor set and then set up CoW shared memory mappings for all of your memory. If you're then doing an exec afterwards, then this is entirely wasted effort.
This issue didn't exist, so someone went and added synchronisation around the tear-down process. Why? People don't generally add mutexes at random, so this was probably done because they found a race condition in process tear-down that resulted in either a resource leak or kernel data structure corruption. Simply removing the mutex will probably fix this problem, but make the computer either run out of some kind of resources or crash. Probably not the correct fix...
Starbucks sells coffee now?
it's psychological violence
Often, it isn't. Harassment implies sustained pattern of behaviour, but the legal definition (at least in the UK) does not and the problem with this is that it often trivialises real problems. Humans are pack animals and a sustained pattern of behaviour that isolates someone from their pack and demeans them can have real mental health consequences. Calling someone an asshat once almost certainly won't (unless everyone does it to the same person). Counting the two in the same category does a serious disservice to people who are actually harassed.
Option one, buy an OS that will cost around $3,000 - $10,000 per license if you can get enough people to buy it that the volumes are similar to Windows, more otherwise. You'll get a formally verified system and can be sure that it works as intended.
Option 2, buy a cheap COTS OS, such as Windows, Linux or *BSD, and expect that there are bugs. These will be fixed on a triage basis, with the ones that affect the most people being fixed first. If you want to have more control over which ones are fixed then buy a support contract for an open source system that explicitly states that the bugs that affect you will be prioritised (this will likely cost more than a Windows license, and will be a recurring cost, but at least you'll be affected by fewer bugs).
Option 3, buy a verified but much simpler (no power management, no multicore support, no GPU support, few drivers, trivial filesystem) OS for around the same price as a COTS OS ($0-200ish).
You, and most other people, have chosen option 2. You're not willing to pay the cost of developing correct complex software and you're not willing to put up with the limitations of software that's simple enough to be cost effective to verify.
My response to that is that they should have ironed out enough of the bugs to where they can say that the product is fit for sale as advertised... or not sold the software at all
A number of the security fixes in Windows (and *NIX) over a typical deployment are against attacks that didn't exist when the product first shipped. Are you saying that they should have a QA system that predicts which future attack vectors will exist and protects against them? Other bugs only show up when software does sequences of operations that no software in existence at the time of shipping performed. Some of these can be found with fuzz testing, but that's always a probabilistic approach because the total sequence of possible combinations is infeasible (within the lifetime of the universe) to search exhaustively.
Are you willing to pay for it? The current cost record for a formally verified system is held by the NICTA team behind seL4. Their development methodology costs a mere 30 times as much as a current best-practices QA setup. Would you pay $3,000 for a Windows license? Because that's the absolute minimum that it would cost for a bug-free Windows version (and that's assuming that the verification techniques used by seL4 would scale linearly in cost from a 10KLoC project up to a multi million LoC project like Windows).
The flip side of this is that people want a one-time payment but not a one-time purchase. They don't want to just buy Windows, they want to buy Windows and a multi-year supply of security and bug fixes. This seems like a better model to me: it hopefully gives Microsoft a financial incentive to keep versions of Windows that people actually want to use supported, rather than killing them and pushing people to buy new ones if they want security updates.
In the real world, spectrum would be property and interference would be trespassing, as was being developed in the courts before the government laid claim on the entire spectrum.
Without a government-enforced license, how do you treat spectrum as property? I own all electromagnetic radiation that passes through my land (with no limit on altitude?) and can block anything that I want? How would you ever create a mobile network if that were the case?
The growth in use of permissive licenses (particularly if you look at github) over restrictive ones is a demonstration of pragmatism and the idea that not everything must be free and we can have non-free and free components working together and cooperating rather than focussing on a pure free software ideology.
I wouldn't necessarily even go that far. I am entirely in favour of a world in which all software comes with the FSF's four freedoms. The reason I release code under FreeBSD / MIT licenses is that this seems like a path that has an actual transition plan. If there's a BSDL project available that does 90% of what you need, then you can adopt it and add the remaining 10% without needing to change your business model. Most of the time, it's then cheaper to release the code. If it doesn't give you a competitive advantage, then upstreaming your changes means that your maintenance costs go down (and, often, other people will fix your bugs, in exchange for being able to use your new features).
If there's only a GPL'd project available, then I've worked with a lot of companies that aren't 100% sure that they will never want to do anything that the GPL prohibits and so will instead write a proprietary version (if you're lucky, you can persuade them to write a permissively licensed version). The GPL'd project doesn't ever enter the company (particularly with GPLv3, where anyone who owns patents gets very nervous) and so they never see the benefits of Free Software. It doesn't provide them with a transition path.
This transition path is particularly important because around 90% of all software developers are employed by companies that are not primarily computer companies. They are developing software for in-house use and so implicitly have all of the four freedoms (because they own the copyright), but don't contribute anything to the wider ecosystem (other than money to Microsoft, Oracle, SAP, and so on). Getting them to start using, contributing to, and then preferring open source solutions can unlock a lot of developer resources.
The initial ban (at least in the UK) was not on leaded petrol, but on the sale of new petrol vehicles that could not run on unleaded. That sounds pretty similar to the current ban under discussion to me.
That's not always true. Different plants have different growing requirements and often the ones that are good for making oil can grow in land that isn't particularly suitable for growing food crops. This becomes even more apparent when you factor in algae (currently the most energy efficient crop for producing oil, though not economical because of the infrastructure required), which doesn't compete at all with the kinds of land that are good for most food plants that people want to eat (various forms of seaweed are particularly nutritious, but not very popular, though they're increasingly being used as a base and source of nutrients in various forms of processed food).
Many of those processes can use vegetable oils just as easily though. When you start with crude oil, you first have to split it into different hydrocarbon chain lengths, and you then crack and polymerise it until you have the lengths that you actually want. There's a lot less variation in vegetable oils than in crude, and it's just a matter of energy to transform them - the nice thing about crude oil is that there's often enough energy from burning the bits that have too high an energy cost to want to transform into useful hydrocarbons to power a lot of these processes. If you have another abundant energy source, then the cost of shipping crude oil from the middle east may outweigh the cost of producing the hydrocarbons that you want from locally grown oil crops.
That variation is already present in every linked program anyway.
To a degree, yes, though in practice it's fairly deterministic and so you tend to only explore a smallish part of the overall space by accident.
This just changes the dice-roll from only once at build time to each and every boot time. Surely it would suck more to get a randomly slow link at build time and then be stuck with it?
Not really - predictable slowness is a lot easier to reason about and work around than unpredictable slowness. On a single machine, knowing that something will take 12 minutes is a lot easier to deal with than finding that yesterday it took 8 but today will take 12. Trying to debug a performance problem in userspace code can be very painful if the OS is unpredictable. In a networked system, if every node takes 100ms to respond, that's annoying, but if they all take 80-120ms to respond then your overall performance is typically limited by the 120ms (Twitter is a good example of this: their response time was limited by the fact that, on average, at least one of the machines that needed to respond to create a page for the user would be in the middle of a GC cycle and so respond a lot more slowly than the rest. They fixed it by forcing GC on a fixed interval so that all machines were slow for a few ms, then fast again for a while until the next GC tick).
This is a concern. The work appears to be based on work from UPenn, which compiled everything with -ffunction-sections and -fdata-sections (if you don't do this, it turns out that you leak enough information to find gadgets quite easily) and re-linked programs in a random order on each run (there's a lot of subsequent work on doing it more often, such as the ReRANZ paper at VEE this year). It's not too difficult to debug, because you record the random number seed with the binary and include it in core dumps, which lets someone else reconstruct the exact implementation. The other concern is that randomising the link order has been shown (ASPLOS 2015) to have around a plus or minus 20% impact on performance. Having that variation across reboots for the kernel could be quite frustrating.
You might want to read the username before you feed the trolls next time.
And this is a change from ten years ago how?
Huh? There are dozens of manufacturers and they are still buying parts from the same 2-3 companies that they were before the regulations came in.