You cannot compile code using an ABI. You compile code using a compiler and the compiler used is gcc on Linux (normally) and clang on OSX.
And the compiler targets a specific ABI. Clang (even the Apple builds) can target the 64-bit Apple Mach-O ABI and the 32-bit PE/COFF Windows ABI. The code running in WINE is a mixture of the host platform's ELF or Mach-O binary format and PE/COFF binaries in the Windows ABI, with thunks to go between them.
This is handled in Wine's C headers. But as mentioned before regular compilers are used so in 64 bit Wine sizeof(long) is 8 (as required by the native libraries that Wine uses), and sizeof(LONG) is 4. So no. No magic! On careful coding.
These stubs can be machine generated. The fact that WINE isn't doing so tells you more about the quality of WINE code than anything else - other projects have managed it quite happily.
Trivially zero-extended or not, code like psecurity_attribute->lpSecurityDescriptor will have to be rewritten because lpSecurityDescriptor is a 64 bit pointer but the psecurity_attribute structure coming in from the application only contains a 32 bit field. If you think going through 1 million lines to fix all such instances is a week-end project then please by all means feel free to send your patch on monday!
Why would it need to? Code using that field will mostly be running in the 32-bit ABI. Only things communicating with the outside world need to be 64-bit and these will access structures via machine-generated thunks. Writing a static analyser plugin that will check for cross-ABI structures not accessed via thunks is a few hours work.
I have no interest in contributing to WINE since they changed the license though, so someone else will have to do it.
I don't think anyone here can talk for Windows, but as far as I know the Linux kernel does not use "machine generated" code to handle thunking from 32 bit applications. Also the Linux kernel ABI is ridiculously small compared to the Windows userland API. And I'd like to see efficient thunking when the parameter you get is a pointer to a structure with pointers to other structs with pointers... The Windows API sucks in this way. but yes, _some_ can be generated automatically (but will then likely have to be maintained by hand).
No idea about Linux, but on FreeBSD we do exactly that. For the project that I work on, we machine-generate all of these thunks for 128-bit pointers as well. We also handle ioctls, which have a really horrible design (type information is severely lacking and the values are passed by opaque pointers).
The $2.5bn estimate includes that. It's a lot cheaper than that to develop and run clinical trials on a single drug, but you have to do it a lot of times before you find the one that actually works.
I read that article when it came out, but it seems to be missing the root cause of the problem: oversupply of workers in certain industries. Why are people being steered towards qualifications for careers for which the supply massively outstrips the demand? My students typically find summer placements working in technology companies where they're typically paid a salary of around £45K/year pro-rated for the term of the internship (usually 2-3 months). A few weeks ago I was at a dinner sitting with second-year economics students. They have internships at city companies and make my students look badly paid in comparison. Companies are willing to pay this because they want to hire good people and having a 3-month interview period where they can determine with high accuracy whether someone is competent and can have an extended period to pitch the company to the student as a place to work at the end of their degree is one of the cheapest way of hiring.
Perhaps making universities publish the average monthly amount that their students make from internships and the percentage that get internships would go a long way. Drop the number of people wanting to go into fashion or journalism by 80% and you'll see unpaid internships go away as companies scrabble around to find the best potential employees.
Here is the deal. No work experience NO JOB!! No references NO JOB! No one gives a shit about your fancy piece of paper called a degree
That wasn't my experience. I had a few offers straight out of my undergraduate degree, but decided to do a PhD instead. During the PhD, I did some consulting on the side. After that, I continued worked freelance (I was making enough during my PhD to cover my cost of living even without the stipend) for five years and had no shortage of clients from word-of-mouth referrals (I didn't advertise and very rarely actively solicited work). I applied to Google and was offered a job, but decided to go back into academia for a bit (much more fun, much less money). At this point, I had nothing on my CV that looked like a job. I stayed there for 6 years and then was headhunted by an industrial research lab, where I'll be starting next month. Before I went back to academia, I had never held a proper job (and many would argue that I still haven't), but that didn't stop me from getting an offer from both Google.
Oh, and neither my undergraduate degree nor my PhD was from an institution that most people will have heard of and my PhD was in an area that is almost completely unrelated to anything I've worked on since. Companies want some evidence of competence but they're generally in the business of getting stuff done and there's a lot more stuff that needs doing than there are people to do it.
I wish there would be a card-reader option for web browsers so we could have card-present transactions for online purchases and stop the frequent sharing of card numbers and CV codes. I'd be happy for it to be impossible for merchants to perform recurring charges after one encounter with a card, as well as stopping all the fraud that can happen when card numbers are stolen out of merchant systems.
About seven or eight years ago, a company produced credit cards that had a button on them that would generate a one-time code displayed on a small LCD on the card. The battery was good for a couple of years of normal use and the code could be used as the CVV for CNP payments - each generated code is good for one transaction and is then not generated again for at least a few hundred transactions. It was trialled in, as I recall, Singapore, but at the end of the trial banks decided that the more expensive cards would cost them more than just eating the fraud as part of the cost of doing business.
The closest thing today for online payments is Apple Pay. When you buy something online using Apple Pay from an iOS device, it runs the full EMV protocol with your endpoint being a software implementation running in the Secure Element. The Secure Element is also responsible for verifying fingerprints, so the entire process can be locked using your fingerprint. In theory, no code running on the application processor (i.e. iOS and iOS processes) are unable able to interfere (other than to attempt to MITM the connection between the secure element and the remote site) and the private key never leaves the secure element. Some Android phones implement Google Pay using a similar mechanism with TrustZone protecting the EMV endpoint. It would have been nice if the TPM spec had included a mechanism for running an EMV endpoint for standard x86 machines.
This assumes you can implement a 32 bit Linux application, one that uses 32 bit pointers throughout, on top of the 64 bit system kernel ABI, 64 bit C library, 64 bit X11 library, 64 bit OpenGL library, etc. Assuming that's even possible, which I doubt, that's really not much better!
Of course you can. WINE is already handling a different ABI to the host system. Code running inside WINE is compiled using the Visual Studio ABI, which is different in a lot of ways (including the size of long on Win64) to the host environment, which typically uses the SysV ABI. WINE includes code that is responsible for loading the EXE and all DLLs, for mapping them into the address space, and for handling relocations between them. When a process all of its libraries, stacks and heap are all mapped into the bottom 4GB of the address space, any 32-bit pointer inside the WINE environment can be trivially zero extended to 64 bits when being passed to other code. You will need thunks, but these can be machine generated in all except a few cases - that's what most operating systems do at the system call layer in for running 32-bit binaries on top of a 64-bit kernel already.
You can't possibly discuss what you think profit is, without understanding how many $2.5bn FAILURES they had to endure before they achieved success with one. If one in 20 drugs make it, that's a bad business model. If it's more like one in 4 or so, this could be a more reasonable model.
The $2.5bn number includes failed attempts. It's a lot less than that if the first drug you try makes it all the way through clinical trials, but that doesn't happen very often.
There was a paper published last week showing a whole raft of trivial attacks on this system, and that's ignoring the fact that it runs on phones that are likely to have at least one remotely exploitable security vulnerability. It basically works because most of the users don't have enough money to be interesting targets for theft.
Replay wouldn’t work either since the transaction challenge contains a pseudo random number that is signed by the card along with payment information. The number is different for each transaction.
The second half of that is true. The first half is what the spec says, but a significant number of uses use an incrementing counter, so if you do two transactions in a shop you can predict the value. Oh, and I seem to remember that it's only a 16-bit value, so if you can trick the card into doing a bunch of retries (which isn't too difficult, because the protocol doesn't allow the card to authenticate the bank, only the bank to authenticate the card) then you can just get the card to generate all possible signatures for a transaction and present the on that the bank asks for.
Note that although most of the EMV attacks were demonstrated several years ago, we've not seen any evidence that they are in widespread use, because the equipment required to do them is fairly complex. If you're going to that much effort, then there are ways of stealing much more money with the same probability of being caught.
I'm perfectly happy using chip-only and stopping the pointless signatures. But, I shall retain the right to view my statement and dispute a fraudulent charge. I refuse to use a PIN when the banks try to bundle that with a shift in liability and a presumption that their little toys are invulnerable to fraud.
That's not how the liability shift worked, in the UK at least. If you use a contactless payment (which is limited in amount) or if you use a PIN, it's the bank's liability if it's fraudulent. If you use a signature, it's the merchant's liability. It's never the cardholder's liability (at least on paper - there have been a couple of cases where banks have tried to pretend it's impossible for the fraud to take place. Fortunately, those of my colleagues involved in demonstrating weaknesses in the EMV protocol were happy to turn up as expert witnesses and inform the court that the banks were full of shit).
It is my understanding that there is some sort of handshake between the card company and the chip to authenticate
This is half true. The EMV protocol allows the bank to authenticate the card, but doesn't allow the card to authenticate the bank. This makes some forms of attack possible if you MITM the connection.
Chip and pin systems were introduced in France at around that time, but the system was patented. Most of non-French banks didn't want to license the patent and so waited until it expired before rolling it out across the continent. I guess your country either didn't sign the relevant IP treaties or was happy paying royalties to France for every transaction.
A lot of the 'dumping' occurs as a result of having large areas of ice. Ice is white and reflects sunlight back to space (rather than absorbing it and reradiating it as IR, which is then trapped by the atmosphere). If a change in the ocean flow means that the ice caps cool, then it will cause more polar ocean water to freeze, which will result in more heat being dumped into space. I have neither the data nor the required spare supercomputer to tell you to what degree this will happen.
But... yeah, they would have done financially much better selling a $20K a year drug to keep Hep-C at bay for these same customers for the rest of their lives.
Maybe. It's worth noting that the drug in question was part of an acquisition, so if Gilead didn't buy Pharmasset then that wouldn't have stopped the drug coming to market. It's also worth noting that they get that $20K/year right up until the point someone else develops either a cheaper treatment or a cure. If you don't go through the fast-track process, it takes, on average, 12 years to get FDA approval from a new drug, so even if you don't patent it then you get at most 8 years of exclusivity in the average case, before generic manufacturers can make the same drug without having to pay any of the R&D costs. Any hiccups along the way and it may only be 4-6, though the FDA guarantees 5 for completely new drugs (much less for old drugs with new uses), irrespective of patent status.
Sofosbuvir made it through the fast track process, because it was a cure for a disease with no existing cure, and so was approved only 6 years after discovery, giving them 14 years of exclusivity. No on else is going to try to develop a cure in that time, because it won't get fast-track approval and so they're likely to end up with 2 years of trying to compete on price before they lose entirely when generic Sofosbuvir hits the market. No one is going to bother developing treatments, because there's no market for a treatment for a disease when a cure exists. That means that they have either 14 years or until the disease is eradicated, whichever is shorter, with to make a profit from a complete monopoly.
Now imagine instead spending $2.5bn (average cost for bringing a drug to market) and 12 years on approval for a treatment. You get 8 years of exclusivity on the treatment, but you also have to compete with other people producing treatments for the same disease. Does that sound like a better financial bet?
A back of the envelope calculation for the drug mentioned in TFS indicates that their profit over a 10-year period (including the first 5 years prior to FDA approval) was around ten times the cost of developing the drug. Even if they make no sales ever again, that sounds like a pretty good ROI. Or, to put it another way, with the profits from one cure, they can bring 10 more drugs to market. They're also in an unassailable position because there is now no market for treatments for the disease cured by their drug and there is no point anyone else trying to develop a cheaper cure because anyone who does won't make enough money to cover their costs (they won't get fast-track approval if there's an existing cure, so unless they're already in clinical trials they have a few years before 2030 when the patent on the existing cure expires and they have to compete with generic alternatives).
The cost of bringing a drug to market is around $2.5bn. That includes R&D and approval, and the R&D costs include the dead ends that you go down before you find something that actually works. Making 'only' around $25bn from a $2.5bn investment doesn't sound like too bad a business model to me...
The other part of it is time-limited patents. The drug TFS obliquely refers to is Sofosbuvir. It was discovered in 2007, patented in 2010, and approved in 2013. Patents last 20 years from filing data and, in addition, the FDA grants 5 years of exclusivity (irrespective of patent status) for five years.
The cost of bringing a new drug to market is estimated at $2.5bn (R&D, failed attempts that you have to try before you find something that works, regulatory approval), so the sales in 2015 completely covered the R&D costs with $10bn split between manufacturing costs and profit. The cost of producing Sofosbuvir is around $300 for a course of treatment (at least, that's their target price point for generic versions in developing countries) and the price is over $30K (sometimes a lot more, depending on locale), so production costs amount to around 1% of the revenue. Let's be generous and say that it's 5%, to include distribution and so on. That leaves a little over $9bn profit, after all R&D costs are paid, in their best year. This year, all of the R&D costs are already paid off, so that $4bn is 95% profit. If they completely eradicate the disease this year to the extent that there are no further sales, they will have made well over $20bn in profits, from an investment of around $2.5bn.
Now, I don't work for GS, but I'd be quite happy with a 1000% ROI over a period of 10 years (from discovery to peak) sounds pretty good. That works out at an annualised 25% ROI. If GS can recommend a place where I can get a better return on investment, then I'd be very happy to hear about it!
If they didn't cure the disease, then they'd still have exclusive rights until 2030, but they certainly wouldn't be able to charge as much (people won't pay as much for a treatment as a cure). They wouldn't have made it through the fast-track FDA approvals process, so they probably wouldn't have made any money yet, because they'd still be in phase 2 trials. And they'd have a product whose value could be wiped out instantly if a competitor did produce a cure.
Again, sounds like a cure is a better business model to me. Now that there is a cure, I bet no one is investing in producing an alternative, because by the time it's approved (no fast track if there's an existing cure) they'll only have a few years before generic versions of Sofosbuvir flood the market at $300 per course of treatment.
Usenet. The system you're referring to is Usenet. It's federated, it has data and identity portability, and NNTP is a well documented protocol.
Not Usenet. Usenet doesn't have any notion of identity and doesn't have any form of authentication. The federation mechanism doesn't provide any mechanism for attestation of original identity, so it is trivial to forge. It doesn't have any form of restricted sharing other than creating a private group (which is then not federated and so everyone must be using the same server to use it). It also doesn't provide any standard mechanism for sharing things that are not 7-bit ASCII, though there are lots of non-standard (incompatible) extensions for sharing binaries.
Also, having implemented an NNTP client, I can say with some confidence that it is a truly horrible protocol that deserves to be consigned to the dustbin of history.
No, stop. If they charged even one cent per month, statistically nobody would use it because of the hassle.
WhatsApp grew to a few hundred million users charging $1/year. They were free for the first year, but most people were happy to pay after that. $1/year actually buys a surprising amount of hosting if you're buying in bulk. Cloud storage is now about $2-4/TB/month, so that's about 3GB/user of storage (more for content that hasn't changed for ages) and transfer costs on top of that are negligible for most users.
I think you underestimate the number of people willing to make in-app purchases. You and I may only install apps from F-droid, but most people give their credit card details to either Apple or Google immediately after turning on a new phone and have a mechanism set up to pay small amounts to app developers.
Bingo. The problem here is not that Uber drivers are considered self-employed contractors, it's that treating them as such removes a bunch of responsibilities from Uber. This hasn't mattered in the past, because self employment was traditionally something that only people in skilled trades or professions did. We recently hired a self-employed carpenter. He set his own price and I think he makes a pretty good living at it because his skills are in demand. The balance of power in negotiations between payer and payee is tilted towards the contractor there, because his skills are in sufficient demand that he can turn down work. I was self employed for about five years working for companies across the world and I frequently turned down work that didn't sound fun (or put my price up so much that either they client decided to go with someone else or I got to take a few months off after doing the work for them).
I believe that the key differentiator between someone who is beneficially self employed and someone who is self employed because they're being exploited is whether they can afford to turn down work. If an Uber driver can decide Uber isn't paying enough and make a reasonable amount of money driving only for Lyft, then they may be beneficially self employed. If they can't, then worker protections for self employed individuals need tightening.
Yes, because I should vote for a Left that is beyond convinced that we are greedy, racist, sexist, homophobe morons who hate science and love Hitler. All the leftist sects agree - they have found the revealed truth, and imposing it upon the benighted normals like us is so transcendently important that they are relieved of any moral limitations
There's something wonderfully ironic about someone describing the left in terms of right-wing straw-man ideas and simultaneously objecting to the left's straw-man depiction of the right.
In 2015, Uber drivers averaged $19 per hour. That is more than twice the minimum wage.
$19/hour is not too awful as a wage for unskilled work, but $19 as a contracting rate is terrible. IRS mileage rates are around $0.50/mile (expected to cover fuel, maintenance and depreciation on the vehicle), so assuming 20 miles per hour (city driving, lots of stopping) that's $10 gone up front to cover the maintenance, which would not be counted as income for a salaried employee. Now you're looking at $9/hour, and that's before you start covering things like insurance (Uber requires that drivers pay their own insurance for operating a commercial vehicle), health insurance (not part of salary, treated as a separate benefit in the US), and other costs associated with accountancy and overheads for a sole proprietorship.
First, like email, it needs to support federation. If there is a single provider, then it's still a data-mining goldmine. We've seen from Facebook's acquisition of WhatsApp that strong privacy policies can be eroded after a takeover and users don't like to leave the network that everyone else is on. That's less of a danger if there are hundreds of interoperable providers. Don't like new GMail policies? Move to Hotmail, Fastmail, Yahoo Mail, or one of a few hundred other providers, or host your own mail server. Don't like a new realpeople.io policy? Move to a completely different network and have no way of communicating with your existing contacts.
Second, it needs data and identity portability. A user needs to be able to decide at any time that they don't like their current provider and move elsewhere. With email, if I own a domain I can just point it at another provider. Moving social network providers needs to be this easy.
Finally, it needs well-documented protocols. For email, we have multiple implementations of the client and server parts of the system. A social network that isn't backed by a huge company with bottomless pockets needs people to be able to write new versions of the back-end that meet specific needs. It needs people to be able to write custom clients that expose the data (or some interesting subset of the data) in new ways.
Network effects. As Google learned, the service provided by Facebook has almost no value. The fact that other people are using the same service is the sole reason that Facebook seems useful. Imagine trying to start a new phone network now, if you weren't allowed to connect to the existing one. Think you'd get many users?
Slashdot Mirror
You cannot compile code using an ABI. You compile code using a compiler and the compiler used is gcc on Linux (normally) and clang on OSX.
And the compiler targets a specific ABI. Clang (even the Apple builds) can target the 64-bit Apple Mach-O ABI and the 32-bit PE/COFF Windows ABI. The code running in WINE is a mixture of the host platform's ELF or Mach-O binary format and PE/COFF binaries in the Windows ABI, with thunks to go between them.
This is handled in Wine's C headers. But as mentioned before regular compilers are used so in 64 bit Wine sizeof(long) is 8 (as required by the native libraries that Wine uses), and sizeof(LONG) is 4. So no. No magic! On careful coding.
These stubs can be machine generated. The fact that WINE isn't doing so tells you more about the quality of WINE code than anything else - other projects have managed it quite happily.
Trivially zero-extended or not, code like psecurity_attribute->lpSecurityDescriptor will have to be rewritten because lpSecurityDescriptor is a 64 bit pointer but the psecurity_attribute structure coming in from the application only contains a 32 bit field. If you think going through 1 million lines to fix all such instances is a week-end project then please by all means feel free to send your patch on monday!
Why would it need to? Code using that field will mostly be running in the 32-bit ABI. Only things communicating with the outside world need to be 64-bit and these will access structures via machine-generated thunks. Writing a static analyser plugin that will check for cross-ABI structures not accessed via thunks is a few hours work.
I have no interest in contributing to WINE since they changed the license though, so someone else will have to do it.
I don't think anyone here can talk for Windows, but as far as I know the Linux kernel does not use "machine generated" code to handle thunking from 32 bit applications. Also the Linux kernel ABI is ridiculously small compared to the Windows userland API. And I'd like to see efficient thunking when the parameter you get is a pointer to a structure with pointers to other structs with pointers... The Windows API sucks in this way. but yes, _some_ can be generated automatically (but will then likely have to be maintained by hand).
No idea about Linux, but on FreeBSD we do exactly that. For the project that I work on, we machine-generate all of these thunks for 128-bit pointers as well. We also handle ioctls, which have a really horrible design (type information is severely lacking and the values are passed by opaque pointers).
The $2.5bn estimate includes that. It's a lot cheaper than that to develop and run clinical trials on a single drug, but you have to do it a lot of times before you find the one that actually works.
I read that article when it came out, but it seems to be missing the root cause of the problem: oversupply of workers in certain industries. Why are people being steered towards qualifications for careers for which the supply massively outstrips the demand? My students typically find summer placements working in technology companies where they're typically paid a salary of around £45K/year pro-rated for the term of the internship (usually 2-3 months). A few weeks ago I was at a dinner sitting with second-year economics students. They have internships at city companies and make my students look badly paid in comparison. Companies are willing to pay this because they want to hire good people and having a 3-month interview period where they can determine with high accuracy whether someone is competent and can have an extended period to pitch the company to the student as a place to work at the end of their degree is one of the cheapest way of hiring.
Perhaps making universities publish the average monthly amount that their students make from internships and the percentage that get internships would go a long way. Drop the number of people wanting to go into fashion or journalism by 80% and you'll see unpaid internships go away as companies scrabble around to find the best potential employees.
Here is the deal. No work experience NO JOB!! No references NO JOB! No one gives a shit about your fancy piece of paper called a degree
That wasn't my experience. I had a few offers straight out of my undergraduate degree, but decided to do a PhD instead. During the PhD, I did some consulting on the side. After that, I continued worked freelance (I was making enough during my PhD to cover my cost of living even without the stipend) for five years and had no shortage of clients from word-of-mouth referrals (I didn't advertise and very rarely actively solicited work). I applied to Google and was offered a job, but decided to go back into academia for a bit (much more fun, much less money). At this point, I had nothing on my CV that looked like a job. I stayed there for 6 years and then was headhunted by an industrial research lab, where I'll be starting next month. Before I went back to academia, I had never held a proper job (and many would argue that I still haven't), but that didn't stop me from getting an offer from both Google.
Oh, and neither my undergraduate degree nor my PhD was from an institution that most people will have heard of and my PhD was in an area that is almost completely unrelated to anything I've worked on since. Companies want some evidence of competence but they're generally in the business of getting stuff done and there's a lot more stuff that needs doing than there are people to do it.
I wish there would be a card-reader option for web browsers so we could have card-present transactions for online purchases and stop the frequent sharing of card numbers and CV codes. I'd be happy for it to be impossible for merchants to perform recurring charges after one encounter with a card, as well as stopping all the fraud that can happen when card numbers are stolen out of merchant systems.
About seven or eight years ago, a company produced credit cards that had a button on them that would generate a one-time code displayed on a small LCD on the card. The battery was good for a couple of years of normal use and the code could be used as the CVV for CNP payments - each generated code is good for one transaction and is then not generated again for at least a few hundred transactions. It was trialled in, as I recall, Singapore, but at the end of the trial banks decided that the more expensive cards would cost them more than just eating the fraud as part of the cost of doing business.
The closest thing today for online payments is Apple Pay. When you buy something online using Apple Pay from an iOS device, it runs the full EMV protocol with your endpoint being a software implementation running in the Secure Element. The Secure Element is also responsible for verifying fingerprints, so the entire process can be locked using your fingerprint. In theory, no code running on the application processor (i.e. iOS and iOS processes) are unable able to interfere (other than to attempt to MITM the connection between the secure element and the remote site) and the private key never leaves the secure element. Some Android phones implement Google Pay using a similar mechanism with TrustZone protecting the EMV endpoint. It would have been nice if the TPM spec had included a mechanism for running an EMV endpoint for standard x86 machines.
This assumes you can implement a 32 bit Linux application, one that uses 32 bit pointers throughout, on top of the 64 bit system kernel ABI, 64 bit C library, 64 bit X11 library, 64 bit OpenGL library, etc. Assuming that's even possible, which I doubt, that's really not much better!
Of course you can. WINE is already handling a different ABI to the host system. Code running inside WINE is compiled using the Visual Studio ABI, which is different in a lot of ways (including the size of long on Win64) to the host environment, which typically uses the SysV ABI. WINE includes code that is responsible for loading the EXE and all DLLs, for mapping them into the address space, and for handling relocations between them. When a process all of its libraries, stacks and heap are all mapped into the bottom 4GB of the address space, any 32-bit pointer inside the WINE environment can be trivially zero extended to 64 bits when being passed to other code. You will need thunks, but these can be machine generated in all except a few cases - that's what most operating systems do at the system call layer in for running 32-bit binaries on top of a 64-bit kernel already.
You can't possibly discuss what you think profit is, without understanding how many $2.5bn FAILURES they had to endure before they achieved success with one. If one in 20 drugs make it, that's a bad business model. If it's more like one in 4 or so, this could be a more reasonable model.
The $2.5bn number includes failed attempts. It's a lot less than that if the first drug you try makes it all the way through clinical trials, but that doesn't happen very often.
There was a paper published last week showing a whole raft of trivial attacks on this system, and that's ignoring the fact that it runs on phones that are likely to have at least one remotely exploitable security vulnerability. It basically works because most of the users don't have enough money to be interesting targets for theft.
Replay wouldn’t work either since the transaction challenge contains a pseudo random number that is signed by the card along with payment information. The number is different for each transaction.
The second half of that is true. The first half is what the spec says, but a significant number of uses use an incrementing counter, so if you do two transactions in a shop you can predict the value. Oh, and I seem to remember that it's only a 16-bit value, so if you can trick the card into doing a bunch of retries (which isn't too difficult, because the protocol doesn't allow the card to authenticate the bank, only the bank to authenticate the card) then you can just get the card to generate all possible signatures for a transaction and present the on that the bank asks for.
Note that although most of the EMV attacks were demonstrated several years ago, we've not seen any evidence that they are in widespread use, because the equipment required to do them is fairly complex. If you're going to that much effort, then there are ways of stealing much more money with the same probability of being caught.
I'm perfectly happy using chip-only and stopping the pointless signatures. But, I shall retain the right to view my statement and dispute a fraudulent charge. I refuse to use a PIN when the banks try to bundle that with a shift in liability and a presumption that their little toys are invulnerable to fraud.
That's not how the liability shift worked, in the UK at least. If you use a contactless payment (which is limited in amount) or if you use a PIN, it's the bank's liability if it's fraudulent. If you use a signature, it's the merchant's liability. It's never the cardholder's liability (at least on paper - there have been a couple of cases where banks have tried to pretend it's impossible for the fraud to take place. Fortunately, those of my colleagues involved in demonstrating weaknesses in the EMV protocol were happy to turn up as expert witnesses and inform the court that the banks were full of shit).
It is my understanding that there is some sort of handshake between the card company and the chip to authenticate
This is half true. The EMV protocol allows the bank to authenticate the card, but doesn't allow the card to authenticate the bank. This makes some forms of attack possible if you MITM the connection.
Chip and pin systems were introduced in France at around that time, but the system was patented. Most of non-French banks didn't want to license the patent and so waited until it expired before rolling it out across the continent. I guess your country either didn't sign the relevant IP treaties or was happy paying royalties to France for every transaction.
A lot of the 'dumping' occurs as a result of having large areas of ice. Ice is white and reflects sunlight back to space (rather than absorbing it and reradiating it as IR, which is then trapped by the atmosphere). If a change in the ocean flow means that the ice caps cool, then it will cause more polar ocean water to freeze, which will result in more heat being dumped into space. I have neither the data nor the required spare supercomputer to tell you to what degree this will happen.
But... yeah, they would have done financially much better selling a $20K a year drug to keep Hep-C at bay for these same customers for the rest of their lives.
Maybe. It's worth noting that the drug in question was part of an acquisition, so if Gilead didn't buy Pharmasset then that wouldn't have stopped the drug coming to market. It's also worth noting that they get that $20K/year right up until the point someone else develops either a cheaper treatment or a cure. If you don't go through the fast-track process, it takes, on average, 12 years to get FDA approval from a new drug, so even if you don't patent it then you get at most 8 years of exclusivity in the average case, before generic manufacturers can make the same drug without having to pay any of the R&D costs. Any hiccups along the way and it may only be 4-6, though the FDA guarantees 5 for completely new drugs (much less for old drugs with new uses), irrespective of patent status.
Sofosbuvir made it through the fast track process, because it was a cure for a disease with no existing cure, and so was approved only 6 years after discovery, giving them 14 years of exclusivity. No on else is going to try to develop a cure in that time, because it won't get fast-track approval and so they're likely to end up with 2 years of trying to compete on price before they lose entirely when generic Sofosbuvir hits the market. No one is going to bother developing treatments, because there's no market for a treatment for a disease when a cure exists. That means that they have either 14 years or until the disease is eradicated, whichever is shorter, with to make a profit from a complete monopoly.
Now imagine instead spending $2.5bn (average cost for bringing a drug to market) and 12 years on approval for a treatment. You get 8 years of exclusivity on the treatment, but you also have to compete with other people producing treatments for the same disease. Does that sound like a better financial bet?
A back of the envelope calculation for the drug mentioned in TFS indicates that their profit over a 10-year period (including the first 5 years prior to FDA approval) was around ten times the cost of developing the drug. Even if they make no sales ever again, that sounds like a pretty good ROI. Or, to put it another way, with the profits from one cure, they can bring 10 more drugs to market. They're also in an unassailable position because there is now no market for treatments for the disease cured by their drug and there is no point anyone else trying to develop a cheaper cure because anyone who does won't make enough money to cover their costs (they won't get fast-track approval if there's an existing cure, so unless they're already in clinical trials they have a few years before 2030 when the patent on the existing cure expires and they have to compete with generic alternatives).
The cost of bringing a drug to market, including the failed attempts, is estimated at $2.5bn.
The cost of bringing a drug to market is around $2.5bn. That includes R&D and approval, and the R&D costs include the dead ends that you go down before you find something that actually works. Making 'only' around $25bn from a $2.5bn investment doesn't sound like too bad a business model to me...
The cost of bringing a new drug to market is estimated at $2.5bn (R&D, failed attempts that you have to try before you find something that works, regulatory approval), so the sales in 2015 completely covered the R&D costs with $10bn split between manufacturing costs and profit. The cost of producing Sofosbuvir is around $300 for a course of treatment (at least, that's their target price point for generic versions in developing countries) and the price is over $30K (sometimes a lot more, depending on locale), so production costs amount to around 1% of the revenue. Let's be generous and say that it's 5%, to include distribution and so on. That leaves a little over $9bn profit, after all R&D costs are paid, in their best year. This year, all of the R&D costs are already paid off, so that $4bn is 95% profit. If they completely eradicate the disease this year to the extent that there are no further sales, they will have made well over $20bn in profits, from an investment of around $2.5bn.
Now, I don't work for GS, but I'd be quite happy with a 1000% ROI over a period of 10 years (from discovery to peak) sounds pretty good. That works out at an annualised 25% ROI. If GS can recommend a place where I can get a better return on investment, then I'd be very happy to hear about it!
If they didn't cure the disease, then they'd still have exclusive rights until 2030, but they certainly wouldn't be able to charge as much (people won't pay as much for a treatment as a cure). They wouldn't have made it through the fast-track FDA approvals process, so they probably wouldn't have made any money yet, because they'd still be in phase 2 trials. And they'd have a product whose value could be wiped out instantly if a competitor did produce a cure.
Again, sounds like a cure is a better business model to me. Now that there is a cure, I bet no one is investing in producing an alternative, because by the time it's approved (no fast track if there's an existing cure) they'll only have a few years before generic versions of Sofosbuvir flood the market at $300 per course of treatment.
Usenet. The system you're referring to is Usenet. It's federated, it has data and identity portability, and NNTP is a well documented protocol.
Not Usenet. Usenet doesn't have any notion of identity and doesn't have any form of authentication. The federation mechanism doesn't provide any mechanism for attestation of original identity, so it is trivial to forge. It doesn't have any form of restricted sharing other than creating a private group (which is then not federated and so everyone must be using the same server to use it). It also doesn't provide any standard mechanism for sharing things that are not 7-bit ASCII, though there are lots of non-standard (incompatible) extensions for sharing binaries.
Also, having implemented an NNTP client, I can say with some confidence that it is a truly horrible protocol that deserves to be consigned to the dustbin of history.
No, stop. If they charged even one cent per month, statistically nobody would use it because of the hassle.
WhatsApp grew to a few hundred million users charging $1/year. They were free for the first year, but most people were happy to pay after that. $1/year actually buys a surprising amount of hosting if you're buying in bulk. Cloud storage is now about $2-4/TB/month, so that's about 3GB/user of storage (more for content that hasn't changed for ages) and transfer costs on top of that are negligible for most users.
I think you underestimate the number of people willing to make in-app purchases. You and I may only install apps from F-droid, but most people give their credit card details to either Apple or Google immediately after turning on a new phone and have a mechanism set up to pay small amounts to app developers.
Bingo. The problem here is not that Uber drivers are considered self-employed contractors, it's that treating them as such removes a bunch of responsibilities from Uber. This hasn't mattered in the past, because self employment was traditionally something that only people in skilled trades or professions did. We recently hired a self-employed carpenter. He set his own price and I think he makes a pretty good living at it because his skills are in demand. The balance of power in negotiations between payer and payee is tilted towards the contractor there, because his skills are in sufficient demand that he can turn down work. I was self employed for about five years working for companies across the world and I frequently turned down work that didn't sound fun (or put my price up so much that either they client decided to go with someone else or I got to take a few months off after doing the work for them).
I believe that the key differentiator between someone who is beneficially self employed and someone who is self employed because they're being exploited is whether they can afford to turn down work. If an Uber driver can decide Uber isn't paying enough and make a reasonable amount of money driving only for Lyft, then they may be beneficially self employed. If they can't, then worker protections for self employed individuals need tightening.
Yes, because I should vote for a Left that is beyond convinced that we are greedy, racist, sexist, homophobe morons who hate science and love Hitler. All the leftist sects agree - they have found the revealed truth, and imposing it upon the benighted normals like us is so transcendently important that they are relieved of any moral limitations
There's something wonderfully ironic about someone describing the left in terms of right-wing straw-man ideas and simultaneously objecting to the left's straw-man depiction of the right.
In 2015, Uber drivers averaged $19 per hour. That is more than twice the minimum wage.
$19/hour is not too awful as a wage for unskilled work, but $19 as a contracting rate is terrible. IRS mileage rates are around $0.50/mile (expected to cover fuel, maintenance and depreciation on the vehicle), so assuming 20 miles per hour (city driving, lots of stopping) that's $10 gone up front to cover the maintenance, which would not be counted as income for a salaried employee. Now you're looking at $9/hour, and that's before you start covering things like insurance (Uber requires that drivers pay their own insurance for operating a commercial vehicle), health insurance (not part of salary, treated as a separate benefit in the US), and other costs associated with accountancy and overheads for a sole proprietorship.
First, like email, it needs to support federation. If there is a single provider, then it's still a data-mining goldmine. We've seen from Facebook's acquisition of WhatsApp that strong privacy policies can be eroded after a takeover and users don't like to leave the network that everyone else is on. That's less of a danger if there are hundreds of interoperable providers. Don't like new GMail policies? Move to Hotmail, Fastmail, Yahoo Mail, or one of a few hundred other providers, or host your own mail server. Don't like a new realpeople.io policy? Move to a completely different network and have no way of communicating with your existing contacts.
Second, it needs data and identity portability. A user needs to be able to decide at any time that they don't like their current provider and move elsewhere. With email, if I own a domain I can just point it at another provider. Moving social network providers needs to be this easy.
Finally, it needs well-documented protocols. For email, we have multiple implementations of the client and server parts of the system. A social network that isn't backed by a huge company with bottomless pockets needs people to be able to write new versions of the back-end that meet specific needs. It needs people to be able to write custom clients that expose the data (or some interesting subset of the data) in new ways.
Network effects. As Google learned, the service provided by Facebook has almost no value. The fact that other people are using the same service is the sole reason that Facebook seems useful. Imagine trying to start a new phone network now, if you weren't allowed to connect to the existing one. Think you'd get many users?