If iPhone market share rose to the point where they have a dominant market position that can be used to gain advantage in other markets, then the iPhone should indeed become the subject of antitrust investigation. Until then, no.
Here's a nice list of EMV vulnerabilities. The latest one 'wedge' involves a MITM between the card and the bank. Since publishing with a prototype device, the authors have found people manufacturing much smaller ones that can just have a chip from a stolen card popped in them to do fraudulent transactions.
Well, some of Europe. The patent was owned by a French company, so most of Europe waited for it to expire around 10 years ago. Want a good example of the patent system causing economic damage? There's one.
You're missing the latest EMV attack (published around November last year), which relies on the fact that the EMV protocol doesn't authenticate the bank, only the card, making it possible to MITM.
It's not the card that contains the PIN on the European solution, the PIN is validated by the bank.
Well, it's validated by someone. Unfortunately, it turns out that the card reader doesn't contain anything to validate that the remote party is actually the bank, making it vulnerable to all sorts of MITM attacks. Especially fun as a lot of them use poorly-secured WiFi for their last hop...
Yup. The free version in F-Droid is so nice that I donated to the project. I didn't want to pay to fund a crippled open source version, but after seeing how good the open source version is when built without the limitations, I was very happy to donate (more than the Google Play price) to the project.
No, the new thing is that they're integrating it with the main site. Sites like OSRM and OpenRouteService have provided routing from OSM data for years, but now OSM is deploying their code in a central place. They have, for example, two implementations of route finding for cyclists. One gives about as good as Google Maps (i.e. crap), the other gives good routes. Because the database is open, a number of other groups have written routing applications and libraries (including some that run on mobile devices using offline maps, without needing Internet access - again, something that Google Maps doesn't do), so now there's a pool for the core OSM project to pull from incorporate on their site.
Same here. I don't understand the other poster's comment about addresses either - I've had no problem finding directions to a house number when in a country where I definitely don't want to enable data roaming. I have about 2GBs of maps on my phone - they're sufficiently small that I've not bothered deleting them.
Right here, right now, today, OSM believes my location is a country that's at the opposite side of the world from the one I actually am in.
Huh? OSM doesn't know anything about your location. If you're talking about the web page (OSM is a database, the web site is just one view on it), then it will ask your browser for location information if you click on the 'go to my location' button, otherwise it will show you the last location that you looked at. If you're using a mobile application, then it will use your GPS.
That means OSM has fallen at the first hurdle
The first hurdle for you in a map service is that the web page doesn't know your location? Odd. For me, it would be that it didn't allow me to have offline vector maps of a whole country when I'm travelling so that I don't run up roaming charges and here all of the solutions other than OSM fail. I guess it depends on how you use maps...
I've noticed that UX is a keyword that's thrown about by people who have no clue about HCI. I thought this thread might have an exception, but apparently not:
Two clicks where one suffices? That's a reduced UX. Trust me, I have no qualm about losing the 1% of my audience that your like represents. There's simply no upside to the likes of you using my software.
It is really bad for usability to have a non-obvious delay between user action and response (see chapter 1 of pretty much any HCI textbook). It is possible to have a clean UI with the model that you describe, but it's very rare on web apps that I've used because latency to web servers is well above the human-perceptible threshold. If you have a row of checkboxes and then a button (you might want to check your Fitts Law calculation, by the way - it's not totally clear that this is a slower UI, and on a touchscreen it can make it a lot easier to correct accidental mistakes), then there's an expected pause once you hit the submit button.
With a row of buttons doing asynchronous things, you are responsible for providing a visual clue for each one that something is happening. Now, as a user, I need to visually track 20 in-flight operations (see Raskin's Locus of Attention for why this is a bad idea). Oh, and I can't issue an atomic operation to remove them all, so I may end up in a confused state if one of them fails in the middle (HTTP connections drop sometimes as I'm hopping between wireless APs).
The sub contains a nuclear reactor. There's a minimum size that you can make one of those, and you really don't want to put one in a disposable vehicle that you're going to use anywhere vaguely near your own (or your allies') coastline. Without that, the drones are limited to chemical power.
One of the emerging roles for aircraft carriers is effectively big portable charging stations that the drones come back to when their batteries are empty.
Because good programmers know that correct indentation is very important most of the time and a complete pain at other times. Someone higher up mentioned machine-generated code that includes snippets of human-provided code as one place where it's a problem. Code that's going to be interpreted and needs to be sent over the wire efficiently in source form is another. It's also annoying when you have long lines, as it's difficult to distinguish continued lines from indentation that implies code structure.
Code that is intended for human consumption should always be clearly structured and should always have lots of documentation. Would it make sense for the compiler to reject any function that didn't contain a comment ratio above a certain percentage? It might make some code better, but it would make machine-generated code a complete pain to work with and add to the parsing time as the compiler skips past a load of/* added because otherwise the compiler will reject this */ code.
It implies that there are enough girls who want to go to a weekend masterclass and have the ability required to take advantage of the opportunity if it's offered, but when they didn't force schools to offer the places to girls they didn't.
Anecdotes are not data, but here's one from a colleague of mine who was involved with a computer science masterclass series for school-age children:
Each school was invited to send up to two people. In the first year, they almost all sent two boys. When asked why, a large number replied with variations on 'girls can't code.' The second year, they said you can send up to two, but if you send any then you must send at least one girl. That year they got a roughly even gender ratio, with the girls spread roughly evenly across ability (slightly weighted towards the more-able end, but not enough to be statistically significant).
The take-home message that I have from this is that girls who are interested in computer science get a lot of negative feedback at school that needs to be addressed. Boys don't have this problem - there's lots of support available already for boys that want to learn to program.
Look at the same statistics from a country that doesn't have herd immunity from most of them being vaccinated and then say that measles isn't a problem and it would be fine for people not to be vaccinated.
that the government should not regulate what the free market can and should take care of.
The problem with reducing someone's opinions to this degree is that this is something that most politicians agree on. The disagreements come over how effective the free market is in certain cases and what the regulations should be. From the rest of your post, it sounds like he's on the side that believes the free market will eventually fix everything (in spite of evidence to the contrary). At the opposite extreme are people who believe the free market will not fix anything (in spite of evidence to the contrary). In the middle, there's far more ambiguity in the evidence, so it's far harder to see who is actually right (and then often only with the benefit of a lot of hindsight).
No it isn't. Go and talk to a lawyer about the GPL sometime. It has a lot of corner cases that businesses are likely to hit, and if you've actually read the GPL in its entirety and think that it's simple then you're deluding yourself. The fact that almost no one gets full marks on the FSF's own GPL quiz first pass should give you some idea of how clear it isn't. Lots of companies don't want to have to get lawyers involved to use (and contribute to) a library and the ones that do definitely don't want to use something that makes their lawyer nervous.
The Apache license is not GPLv2 compatible. This is fixed with GPLv3 (although in a slightly cumbersome way). Linking GPL'd code with anything that is not GPL (and it has to be the same version, GPLv2 and GPLv3 are incompatible) or BSDL is problematic.
BSD licensed software allows someone to take it, modify it in some meaningful way, and not share those changes back with the community at large
The thing that a lot of GPL advocates usually miss is that this is often an intermediate step. Several big FreeBSD contributors have taken this path. First they take our code and incorporate it into a proprietary product. Then they realise that some of their changes are making merges difficult but are not giving them any competitive advantage, so upstream them. At this point, we're already doing better than if they hadn't used our code in the first place. Over time, the amount of code that they decide isn't part of their core competitive advantage grows until it's almost all of their stuff. In a few cases, their proprietary fork ends up having changes that simply wouldn't make sense for anyone other than them.
The other issue is companies that don't distribute software. Google's modified Linux that runs their datacentres, for example, is never distributed and so they never had to share their changes. I've worked with companies that use GPL'd software in this way but won't admit to it publicly for fear of liability (even though they're completely compliant with the license, as far as I can tell), and so who won't send patches upstream. Meanwhile, the same teams will happily send bug fixes for BSDL'd libraries that they use, because there's no chance that they're infringing the license and so they're happy to admit to using it.
It's also not just proprietary software. For example, the Eclipse license is not GPL compatible, so even if GCC were cleanly structured you wouldn't be able to create a library incorporating GCC code and link it in to Eclipse. The same applies to anything Apache licensed. One of the benefits of LLVM is that you can use the code with projects of any open source license (except, apparently, emacs) and not have to worry about the incompatibility.
We've established that psychopaths are far more successful in modern society, so obviously the first thing anyone who wants the best for their children should do is have them engineered for psychopathy. Empathy is for the weak
No, game theory tells us that sociopaths do well in a society that is primarily composed of non-sociopaths, but do not do so well in a society where they are the majority (and that society also doesn't do well as a whole).
Oh, and one overpriced aircraft carrier with no planes that can fly from it.
It's increasingly unclear that having planes launched from an aircraft carrier is a feature. Drones and missiles are a lot cheaper than manned planes (and require less logistical support).
Britain built a strong navy to protect from the threat of invasion from Spain and France. It kept a strong navy to guard the colonies and, during the cold war, to provide a second-strike capability if the USSR decided to launch nuclear weapons at London. We primarily have one now to provide artillery and logistical support for peacekeeping missions (or ridiculous US-led wars) and to wave the flag at Argentina every decade or so. What do we need a large navy for now?
Slashdot Mirror
If iPhone market share rose to the point where they have a dominant market position that can be used to gain advantage in other markets, then the iPhone should indeed become the subject of antitrust investigation. Until then, no.
Here's a nice list of EMV vulnerabilities. The latest one 'wedge' involves a MITM between the card and the bank. Since publishing with a prototype device, the authors have found people manufacturing much smaller ones that can just have a chip from a stolen card popped in them to do fraudulent transactions.
it means what Europe was using 20 years ago
Well, some of Europe. The patent was owned by a French company, so most of Europe waited for it to expire around 10 years ago. Want a good example of the patent system causing economic damage? There's one.
You're missing the latest EMV attack (published around November last year), which relies on the fact that the EMV protocol doesn't authenticate the bank, only the card, making it possible to MITM.
It's not the card that contains the PIN on the European solution, the PIN is validated by the bank.
Well, it's validated by someone. Unfortunately, it turns out that the card reader doesn't contain anything to validate that the remote party is actually the bank, making it vulnerable to all sorts of MITM attacks. Especially fun as a lot of them use poorly-secured WiFi for their last hop...
But at least the transactions will be secure
This has been repeated a number of times in the thread and I really have no idea why. I find it odd that the USA deploys a technology that was shown to be insecure five years ago and has since been shown to be broken in a lot more ways.
You know, it helps if you read the entire sentence before replying.
Yup. The free version in F-Droid is so nice that I donated to the project. I didn't want to pay to fund a crippled open source version, but after seeing how good the open source version is when built without the limitations, I was very happy to donate (more than the Google Play price) to the project.
No, the new thing is that they're integrating it with the main site. Sites like OSRM and OpenRouteService have provided routing from OSM data for years, but now OSM is deploying their code in a central place. They have, for example, two implementations of route finding for cyclists. One gives about as good as Google Maps (i.e. crap), the other gives good routes. Because the database is open, a number of other groups have written routing applications and libraries (including some that run on mobile devices using offline maps, without needing Internet access - again, something that Google Maps doesn't do), so now there's a pool for the core OSM project to pull from incorporate on their site.
Same here. I don't understand the other poster's comment about addresses either - I've had no problem finding directions to a house number when in a country where I definitely don't want to enable data roaming. I have about 2GBs of maps on my phone - they're sufficiently small that I've not bothered deleting them.
Right here, right now, today, OSM believes my location is a country that's at the opposite side of the world from the one I actually am in.
Huh? OSM doesn't know anything about your location. If you're talking about the web page (OSM is a database, the web site is just one view on it), then it will ask your browser for location information if you click on the 'go to my location' button, otherwise it will show you the last location that you looked at. If you're using a mobile application, then it will use your GPS.
That means OSM has fallen at the first hurdle
The first hurdle for you in a map service is that the web page doesn't know your location? Odd. For me, it would be that it didn't allow me to have offline vector maps of a whole country when I'm travelling so that I don't run up roaming charges and here all of the solutions other than OSM fail. I guess it depends on how you use maps...
It's worse than that. Automatic teller machine is just a tautology. Small small-to-medium sized enterprise is convoluted and nonsensical.
Two clicks where one suffices? That's a reduced UX. Trust me, I have no qualm about losing the 1% of my audience that your like represents. There's simply no upside to the likes of you using my software.
It is really bad for usability to have a non-obvious delay between user action and response (see chapter 1 of pretty much any HCI textbook). It is possible to have a clean UI with the model that you describe, but it's very rare on web apps that I've used because latency to web servers is well above the human-perceptible threshold. If you have a row of checkboxes and then a button (you might want to check your Fitts Law calculation, by the way - it's not totally clear that this is a slower UI, and on a touchscreen it can make it a lot easier to correct accidental mistakes), then there's an expected pause once you hit the submit button.
With a row of buttons doing asynchronous things, you are responsible for providing a visual clue for each one that something is happening. Now, as a user, I need to visually track 20 in-flight operations (see Raskin's Locus of Attention for why this is a bad idea). Oh, and I can't issue an atomic operation to remove them all, so I may end up in a confused state if one of them fails in the middle (HTTP connections drop sometimes as I'm hopping between wireless APs).
The sub contains a nuclear reactor. There's a minimum size that you can make one of those, and you really don't want to put one in a disposable vehicle that you're going to use anywhere vaguely near your own (or your allies') coastline. Without that, the drones are limited to chemical power.
One of the emerging roles for aircraft carriers is effectively big portable charging stations that the drones come back to when their batteries are empty.
Because good programmers know that correct indentation is very important most of the time and a complete pain at other times. Someone higher up mentioned machine-generated code that includes snippets of human-provided code as one place where it's a problem. Code that's going to be interpreted and needs to be sent over the wire efficiently in source form is another. It's also annoying when you have long lines, as it's difficult to distinguish continued lines from indentation that implies code structure.
Code that is intended for human consumption should always be clearly structured and should always have lots of documentation. Would it make sense for the compiler to reject any function that didn't contain a comment ratio above a certain percentage? It might make some code better, but it would make machine-generated code a complete pain to work with and add to the parsing time as the compiler skips past a load of /* added because otherwise the compiler will reject this */ code.
It implies that there are enough girls who want to go to a weekend masterclass and have the ability required to take advantage of the opportunity if it's offered, but when they didn't force schools to offer the places to girls they didn't.
Each school was invited to send up to two people. In the first year, they almost all sent two boys. When asked why, a large number replied with variations on 'girls can't code.' The second year, they said you can send up to two, but if you send any then you must send at least one girl. That year they got a roughly even gender ratio, with the girls spread roughly evenly across ability (slightly weighted towards the more-able end, but not enough to be statistically significant).
The take-home message that I have from this is that girls who are interested in computer science get a lot of negative feedback at school that needs to be addressed. Boys don't have this problem - there's lots of support available already for boys that want to learn to program.
Look at the same statistics from a country that doesn't have herd immunity from most of them being vaccinated and then say that measles isn't a problem and it would be fine for people not to be vaccinated.
that the government should not regulate what the free market can and should take care of.
The problem with reducing someone's opinions to this degree is that this is something that most politicians agree on. The disagreements come over how effective the free market is in certain cases and what the regulations should be. From the rest of your post, it sounds like he's on the side that believes the free market will eventually fix everything (in spite of evidence to the contrary). At the opposite extreme are people who believe the free market will not fix anything (in spite of evidence to the contrary). In the middle, there's far more ambiguity in the evidence, so it's far harder to see who is actually right (and then often only with the benefit of a lot of hindsight).
The license itself is clear:
No it isn't. Go and talk to a lawyer about the GPL sometime. It has a lot of corner cases that businesses are likely to hit, and if you've actually read the GPL in its entirety and think that it's simple then you're deluding yourself. The fact that almost no one gets full marks on the FSF's own GPL quiz first pass should give you some idea of how clear it isn't. Lots of companies don't want to have to get lawyers involved to use (and contribute to) a library and the ones that do definitely don't want to use something that makes their lawyer nervous.
The Apache license is not GPLv2 compatible. This is fixed with GPLv3 (although in a slightly cumbersome way). Linking GPL'd code with anything that is not GPL (and it has to be the same version, GPLv2 and GPLv3 are incompatible) or BSDL is problematic.
BSD licensed software allows someone to take it, modify it in some meaningful way, and not share those changes back with the community at large
The thing that a lot of GPL advocates usually miss is that this is often an intermediate step. Several big FreeBSD contributors have taken this path. First they take our code and incorporate it into a proprietary product. Then they realise that some of their changes are making merges difficult but are not giving them any competitive advantage, so upstream them. At this point, we're already doing better than if they hadn't used our code in the first place. Over time, the amount of code that they decide isn't part of their core competitive advantage grows until it's almost all of their stuff. In a few cases, their proprietary fork ends up having changes that simply wouldn't make sense for anyone other than them.
The other issue is companies that don't distribute software. Google's modified Linux that runs their datacentres, for example, is never distributed and so they never had to share their changes. I've worked with companies that use GPL'd software in this way but won't admit to it publicly for fear of liability (even though they're completely compliant with the license, as far as I can tell), and so who won't send patches upstream. Meanwhile, the same teams will happily send bug fixes for BSDL'd libraries that they use, because there's no chance that they're infringing the license and so they're happy to admit to using it.
It's also not just proprietary software. For example, the Eclipse license is not GPL compatible, so even if GCC were cleanly structured you wouldn't be able to create a library incorporating GCC code and link it in to Eclipse. The same applies to anything Apache licensed. One of the benefits of LLVM is that you can use the code with projects of any open source license (except, apparently, emacs) and not have to worry about the incompatibility.
We've established that psychopaths are far more successful in modern society, so obviously the first thing anyone who wants the best for their children should do is have them engineered for psychopathy. Empathy is for the weak
No, game theory tells us that sociopaths do well in a society that is primarily composed of non-sociopaths, but do not do so well in a society where they are the majority (and that society also doesn't do well as a whole).
Oh, and one overpriced aircraft carrier with no planes that can fly from it.
It's increasingly unclear that having planes launched from an aircraft carrier is a feature. Drones and missiles are a lot cheaper than manned planes (and require less logistical support).
Britain built a strong navy to protect from the threat of invasion from Spain and France. It kept a strong navy to guard the colonies and, during the cold war, to provide a second-strike capability if the USSR decided to launch nuclear weapons at London. We primarily have one now to provide artillery and logistical support for peacekeeping missions (or ridiculous US-led wars) and to wave the flag at Argentina every decade or so. What do we need a large navy for now?