He is a victim. The people who deployed inadequately trained police officers in high-stress situations with live firearms are going to escape justice completely.
There's an old saying: 'may as well be hanged for a sheep as for a lamb'. If you hit someone with a car while driving dangerously, and the penalty is the same whether they die or not, then you have no incentive to stop and make sure that they're alive, call an ambulance, and so on. In fact, backing up over them again and driving off will not increase the penalty but will reduce the chances that you'll get caught, so you should probably do that.
Everyone coming off the plane heads for rentals and shuttle usually. Even in San Francisco where I know there's Bart service, I don't necessarily know if it's running that day or how many hours to wait or where to get the tickets and so forth. In that sense, the locals are still more likely to use the transit but it's not a common thing.
I've travelled to SFO a few times, and from the perspective of a foreigner:
Buying a ticket for the BART is easy at the airport - there are machines and ticket counters. You really want to get a Clipper Card though. I didn't think you could get one at the airport (I flew into San Jose when on the trip where I got mine, so I've never tried), but a quick check on the clipper card web site shows four locations inside SFO where you can get one.
Once you have a clipper card with some credit, just tap it to use BART, MUNI, or CalTrain.
The BART runs every day. The only slightly confusing thing is that after 9pm or all day at weekends there's a direct connection to Millbrae, but during the week before 9pm you have to go to San Bruno and then change to the red line if you want to go back to Milbrae. Although both BART and CalTrain have stops in San Bruno, they're about 10-15 minutes walk apart (as I discovered, when I got off the CalTrain at San Bruno expecting to get on the BART, on my way to the airport, on a very hot day) and the only place where the two join up is Millbrae. This only matters if you're heading south, if you're heading into San Francisco then just take the other direction.
There are a lot of hotels near BART stops, but there's also a lot of the city that's nowhere near the BART. These are mostly accessible by bus / tram (clipper card works on all of these), but the routing can be confusing.
Add to that, if you're coming into London to any station other than Paddington, it's likely to be the fastest way of getting to the airport. From Kings Cross, it's about an hour on the Picadilly line to Heathrow. If you time it just right, then it's slightly faster to take the tube to Paddington and then the Heathrow Express (which takes 20 minutes and runs roughly every 20 minutes), but if you time it slightly wrong then you end up spending enough time waiting that you don't get there any faster and you spend £25 more. Plus you have to change trains in the middle, which is annoying with luggage.
Leaving in the morning or arriving in the afternoon at rush hour, it's even better because after the first few stops you're travelling in the opposite direction to most commuters, but the trains are still running one every 2-3 minutes, so you end up with lots of space.
From the places I've visited in the last few years:
London: Tube and Heathrow Express goes to Heathrow, national rail services go to Stansted (station is underground, directly below terminal), not sure about Gatwick.
Paris: Charles De Gaul has direct rail links to the centre.
New York: From JFK, you have to take the Skytrain for a few minutes, then you're at the metro. From Newark, you take a train for about half an hour and then you're in the middle of Manhattan.
San Francisco: BART terminal in SFO, one stop to connections to the CalTrain (though in a weirdly confusing way where you sometimes have to double back on yourself on the BART). I think San Jose airport is only accessible by car / taxi, but it's not very far to the nearest CalTrain stop.
San Diego: Entire city is confused by the idea of transport options other than a car - the nearest bus stop to our hotel was accessible only by car.
Minneapolis: Light rail connections directly to the airport. There was then a bus to my hotel from the nearest light rail stop, but I'm not lazy enough to take a bus to avoid a 15 minute walk (especially not one in their indoor walkway thingy).
Ottawa: When I was there, there were regular (cheap) busses to the town centre and they were building an underground system that should have reached the airport by now.
Seattle: Apparently it's better if you're heading downtown, but heading to Redmond it was a pain - really manky busses that don't give change or receipts and then drop you in a 'transit centre' that's miles away from anything useful, doesn't have busses running to hotels, and is serviced by massively overpriced taxies (getting Uber back to the airport from the hotel cost slightly more than getting a taxi from the Redmond transit centre to the hotel in Redmond).
Tokyo: Narita Express takes you right to the middle of town.
Istanbul: I think taxis were the only option here.
Edinburgh: Cheap bus service to the middle of town.
Barcelona: Very confusing airport, but serviced by both overground and underground trains and we eventually ended up on a sensible one.
Not sure how representative this sample is, but most of the places I can remember visiting had good public transport links to the area that they were servicing.
I work in the security group in one of the top computer science departments in the world, and I think I'm the only one on the corridor that has an Android phone. It helps that one of my colleagues wrote a bunch of the code that they use for sandboxing, but we work with both the Apple and Android security teams and there's no way any of us would trust important data to an Android phone.
High-end Android phones increasingly don't come with removable batteries either. It's amusing to watch the older Samsung Galaxy ads. It took a whole year to go from a removable battery being the flagship feature that they mocked Apple for not having to the next device in the same series not having one.
There are client certificates and they've been supported by all major browsers for well over a decade. There's also a standard for generating them from JavaScript, which is less well supported, but is quite a nice way of doing client authentication (after first login, create a client cert and register it for use on that site and you never need to transmit the password from that computer to the server again).
That said, the most common implementation is to have a different client cert for each service, so it doesn't really help tracking (unless you're using a Google client cert for all ad fetches but you're remembering to delete Google cookies).
The nice thing about Let's Encrypt is that they are not just a CA, they are also a well-specified protocol (with multiple implementations) for automatically deploying certs. Lots of low-value sites are secured by Let's Encrypt, but once you've got the infrastructure in place then it's relatively easy to switch to any other CA that implements the ACME protocol.
Requests are encrypted. Everything that flows over the TCP connection is encrypted - request and response. The things that are not encrypted are the DNS queries and the IP address of the endpoints.
The PROBLEM is that this is pure security theater to make people feel safer! HTTPS is easily broken by the NSA
Not true. Without HTTPS, an attacker needs the ability to inspect traffic on one hop between you and the server. Stick a tap on a bunch of data centres and you've got pervasive monitoring. With HTTPS, an attacker has two choices:
Option one, they can compromise the server's private key. This requires either cooperating with the provider (if you can lean on them with a national security letter or similar), or hacking the server and exfiltrating the key. There's nothing you can do about this kind of attack, but it's infeasible to do this on all connections.
Option two, they can do an active MITM attack, where they send a valid cert to you, which is signed by a trusted CA that they can lean on to provide arbitrary certs. There are a bunch of defences against this, but the simplest is Certificate Transparency, which makes it easy for you to see that the cert that you're seeing is not the cert that everyone else is seeing. For example, you can check the logs for Slashdot and see that they're using Let's Encrypt, but there seems to be a slightly suspicious cert issued by Amazon that some people are seeing. Chrome integrates these checks, so will warn you of suspicious activity and the server administrator can inspect them and see if any of their users have been attacked in this way. You can also now add CAA records to DNS that indicate which CAs should be trusted for your domain (only useful if you use DNSSEC), which means that they'd have to lean on a specific CA - if you get your cert signed by a US CA, then it's unlikely that the FSB or Chinese intelligence agencies will be able to get a fake certificate, for example.
If you think turning an easy passive attack into a difficult active attack is security theatre then I hope you never work in security.
If you work in security, I really hope I never have to deal with any of the companies you've worked for.
Https means it can't be loaded from your ISP or company's cache, making popular sites slower
Talk to ISPs. This was a huge deal 10-15 years ago, when the popular subset of the Internet was small enough to fit into caches. Now, the vast majority of fetches miss in caches anyway and a lot of ISPs have stopped running them.
With a fast link, the overhead of having to do two TCP handshakes (one to the cache, then one from there to the real site when it misses) plus the latency of forwarding the response via userspace outweighs the gains, so even if your ISP is running a caching proxy, you'll probably find that it's faster to not use it.
The things that consume a lot of bandwidth these days are videos and these are distributed via a CDN, which will have an endpoint in your ISP's POP or one hop away at their upstream exchange. And these support HTTPS. Netflix, for example, is around 30% of all US Internet traffic and now sends all of their data over HTTPS (from OpenConnect appliances running FreeBSD, able to serve 40Gb/s on a single core using HTTPS). YouTube is typically the same, though this benefits less from caching because there's more of a long tail (a huge number of Netflix viewers watch the same things, so it does get some benefit from caching, and they fetch the most popular shows to the caches in advance).
It also prevents corporate security or your own router / firewall from seeing the malware or whatever that some hacker added to the page, and generally keeping an eye out for security problems
Absolute nonsense. It prevents an attacker from performing a MITM and injecting malware. This includes ISPs (or anyone who controls one of the hops between you and the server) injecting ads into web sites that you visit (which has happened).
If the attacker controls the endpoint, then they can force you to use HTTPS anyway by sticking in a 302 response code in the HTTP request, so you lose nothing from having non-malicious sites use HTTPS as well.
You're describing a setup where network security relies on perimeter security (bad idea) and where perimeter security relies on the attacker cooperating and sending readily identifiable malware in plaintext. That setup would fail a security audit by anyone moderately competent.
There *is* the argument that it makes it harder for governments to know which pages you're viewing on a site, but they still see which sites you connect to.
Nope, they'll see which IPs you've connected to, and possibly which DNS queries you've made (though that depends a bit on TTLs and caching). With a lot of sites hosted using vhosts, the IP doesn't tell you very much. You are right that there's more to be done on DNS cloaking. You are wrong that the only adversary of note is a government though - your ISP (who, in the US, is now allowed to collect and sell this data to third parties) can record every site that you visit.
Uh, what? DVD players have always had a lot of software. The closest to a hardware DVD player is one that does iDCT and motion compensation in fixed-function hardware and the rest of MPEG-2 in software on a DSP. All of the menus, UDF filesystem parsing, VOB file parsing, player UI and so on were always software.
that were instantly available and didnt have to boot up
At home, I use VLC on a media centre / NAS computer to play DVDs. It's there instantly. Over Christmas, I'm visiting my mother who has a single-function DVD player. It takes about a minute between power on and being able to insert a DVD.
You're conflating two issues. Should you automate a job, and what do you do with the displaced workers?
The answer to the first is almost always yes, because the total gain to society almost always outweighs the loss. In the industrial revolution, we went from 4 people each doing a week's worth of work in turn to produce a metre of cloth to 50 people in a factory producing hundreds of metres of cloth a day. The gain from poor people being able to afford to own more than one set of clothes was huge. The overall gain from suddenly having a load of workers available to do things like build railways, dig canals, and all of the rest of the jobs that spurred the industrial revolution was also huge.
In contrast, the human cost of all of the carders, spinners, weavers, and so on being displaced was high. The lack of labour protection laws meant that factories exploited workers and there was a dip in quality of life for a lot of people.
The problem is that the people responsible for the technology and the people responsible for the safety net are different. Self-driving trucks are coming and trying to prevent that is no more feasible than Ludd's Lads preventing the industrial revolution by smashing the machines 200 years ago. What we can do, is learn from the experiences of the past and make sure that there's enough of a tax on new technologies like this that they're still cheaper, but there is enough money in the budget for retraining, unemployment pay, and other things to move these people into new jobs.
The solution isn't to prevent technology that improves economic efficiency from being produced, it's to make sure that the improvements in the economy benefit everyone. Won't happen in the US though: wealth redistribution is a dirty word there, wealth is only allowed to flow to the people that already own a lot of capital.
The problem is not authoritarian governments building these systems, it's less-authoritarian governments building systems and forgetting that their successors might abuse it. Google's panopticon was largely built by well-meaning people who knew that they wouldn't abuse it and so didn't see the potential for abuse.
Skynet was a neural network, it made decisions based on the training data. The training data in the lab led it to believe that every problem could be solved by turning the system off and on again.
Give them a horse analogy. With a little bit of training, a horse will take you from A to B, stopping at traffic junctions and following the road. The 'AI' that we're using for self-driving cars is about as good as a horse at one of the many things that a horse can do. It's taken about 20 years with the current approaches to get to be as good as a horse at a single purpose. Making an AI that can completely simulate the behaviour of a dog or a horse is still far beyond us and (we believe, at least, that) there's a quantitative difference between how a dog thinks and how a human thinks. If your job could be done by a dog, but it's cheaper to train a human, then you should watch out.
It wasn't. It was created by a couple of guys who grew up in the USSR and wanted a platform that they could use to communicate with friends and family abroad, without anyone being able to spy on it. They even had a decent business model: the service was free for a year (so people got used to it and made their friends sign up) and then $1/year after that (cheap enough that it wasn't worth caring about, but more than the cost of providing the service, by quite a large amount). Unfortunately, then Facebook bought them. They're currently in some legal difficulty in the EU, because one of the conditions of allowing the takeover to proceed was that Facebook wouldn't share data between Facebook and WhatsApp. Now Facebook is saying that this is too hard and so they're not going to do it.
The main thing in 14 that was useful is auto parameters on lambdas. You can delete a bunch of copied-and-pasted code with them, where it's not quite enough to be worth a separate templated function, and with 11 you can't factor it out into a lambda because one of the parameters has a different type. The most fun new things in 17 are structured bindings (multiple return values can be decomposed from a pair / tuple), std::optional, std::variant, and std::any.
The version in ports is broken in many ways, based on an old version of Docker, and really shouldn't be there. Docker has now refactored a bunch of their code to provide a sandbox daemon that's responsible for managing isolation and has an abstraction layer for OS-specific services. We are working with them to provide a back end that uses jails.
Note that this is true only for Linux. Docker supports Windows, macOS and Solaris targets, and sort-of supports some BSD flavours. On Windows and macOS, they have ported the FreeBSD hypervisor and run a Linux VM. On Solaris, they use Zones for isolation. If the FreeBSD version is ever finished, they'll use jails.
Why? My projector at home projects a smaller image, but I sit closer so the field of view is similar. My home audio system is set up for people sitting on the sofa that I normally sit on when I'm watching films and doesn't have the base turned up so much that it causes distortions in the speakers (unlike the last cinema I went to). What do I get in the cinema that I don't get at home? If I want to watch a film with more people, I can invite some friends over and, best of all, they bring beer.
This is no different than competing against VHS rental
I disagree. DVD was the game changer: you can blow a DVD up on a projector and not be bothered by the quality, and you often get exactly the same sound track as in a cinema. For a few hundred quid, I bought a DVD player, projector and surround sound system over 10 years ago, which gave me a similar field of view and better sound than my local cinema. The cinemas were only competitive because a ticket was £3-4, whereas a new DVD was £10-20. DVD rental subscriptions shifted this, and for about £10/month, I could rent films 3 at a time through the post. At the same time, the price of a cinema ticket went up to about £6, so two people going to the cinema cost more than renting for a month.
Since then, the quality of projectors has gone up and you can stream HD video. The cinema doesn't offer anything of additional value.
Slashdot Mirror
He is a victim. The people who deployed inadequately trained police officers in high-stress situations with live firearms are going to escape justice completely.
There's an old saying: 'may as well be hanged for a sheep as for a lamb'. If you hit someone with a car while driving dangerously, and the penalty is the same whether they die or not, then you have no incentive to stop and make sure that they're alive, call an ambulance, and so on. In fact, backing up over them again and driving off will not increase the penalty but will reduce the chances that you'll get caught, so you should probably do that.
Everyone coming off the plane heads for rentals and shuttle usually. Even in San Francisco where I know there's Bart service, I don't necessarily know if it's running that day or how many hours to wait or where to get the tickets and so forth. In that sense, the locals are still more likely to use the transit but it's not a common thing.
I've travelled to SFO a few times, and from the perspective of a foreigner:
Buying a ticket for the BART is easy at the airport - there are machines and ticket counters. You really want to get a Clipper Card though. I didn't think you could get one at the airport (I flew into San Jose when on the trip where I got mine, so I've never tried), but a quick check on the clipper card web site shows four locations inside SFO where you can get one.
Once you have a clipper card with some credit, just tap it to use BART, MUNI, or CalTrain.
The BART runs every day. The only slightly confusing thing is that after 9pm or all day at weekends there's a direct connection to Millbrae, but during the week before 9pm you have to go to San Bruno and then change to the red line if you want to go back to Milbrae. Although both BART and CalTrain have stops in San Bruno, they're about 10-15 minutes walk apart (as I discovered, when I got off the CalTrain at San Bruno expecting to get on the BART, on my way to the airport, on a very hot day) and the only place where the two join up is Millbrae. This only matters if you're heading south, if you're heading into San Francisco then just take the other direction.
There are a lot of hotels near BART stops, but there's also a lot of the city that's nowhere near the BART. These are mostly accessible by bus / tram (clipper card works on all of these), but the routing can be confusing.
Add to that, if you're coming into London to any station other than Paddington, it's likely to be the fastest way of getting to the airport. From Kings Cross, it's about an hour on the Picadilly line to Heathrow. If you time it just right, then it's slightly faster to take the tube to Paddington and then the Heathrow Express (which takes 20 minutes and runs roughly every 20 minutes), but if you time it slightly wrong then you end up spending enough time waiting that you don't get there any faster and you spend £25 more. Plus you have to change trains in the middle, which is annoying with luggage.
Leaving in the morning or arriving in the afternoon at rush hour, it's even better because after the first few stops you're travelling in the opposite direction to most commuters, but the trains are still running one every 2-3 minutes, so you end up with lots of space.
London: Tube and Heathrow Express goes to Heathrow, national rail services go to Stansted (station is underground, directly below terminal), not sure about Gatwick.
Paris: Charles De Gaul has direct rail links to the centre.
New York: From JFK, you have to take the Skytrain for a few minutes, then you're at the metro. From Newark, you take a train for about half an hour and then you're in the middle of Manhattan.
San Francisco: BART terminal in SFO, one stop to connections to the CalTrain (though in a weirdly confusing way where you sometimes have to double back on yourself on the BART). I think San Jose airport is only accessible by car / taxi, but it's not very far to the nearest CalTrain stop.
San Diego: Entire city is confused by the idea of transport options other than a car - the nearest bus stop to our hotel was accessible only by car.
Minneapolis: Light rail connections directly to the airport. There was then a bus to my hotel from the nearest light rail stop, but I'm not lazy enough to take a bus to avoid a 15 minute walk (especially not one in their indoor walkway thingy).
Ottawa: When I was there, there were regular (cheap) busses to the town centre and they were building an underground system that should have reached the airport by now.
Seattle: Apparently it's better if you're heading downtown, but heading to Redmond it was a pain - really manky busses that don't give change or receipts and then drop you in a 'transit centre' that's miles away from anything useful, doesn't have busses running to hotels, and is serviced by massively overpriced taxies (getting Uber back to the airport from the hotel cost slightly more than getting a taxi from the Redmond transit centre to the hotel in Redmond).
Tokyo: Narita Express takes you right to the middle of town.
Istanbul: I think taxis were the only option here.
Edinburgh: Cheap bus service to the middle of town.
Barcelona: Very confusing airport, but serviced by both overground and underground trains and we eventually ended up on a sensible one.
Not sure how representative this sample is, but most of the places I can remember visiting had good public transport links to the area that they were servicing.
I work in the security group in one of the top computer science departments in the world, and I think I'm the only one on the corridor that has an Android phone. It helps that one of my colleagues wrote a bunch of the code that they use for sandboxing, but we work with both the Apple and Android security teams and there's no way any of us would trust important data to an Android phone.
High-end Android phones increasingly don't come with removable batteries either. It's amusing to watch the older Samsung Galaxy ads. It took a whole year to go from a removable battery being the flagship feature that they mocked Apple for not having to the next device in the same series not having one.
There are client certificates and they've been supported by all major browsers for well over a decade. There's also a standard for generating them from JavaScript, which is less well supported, but is quite a nice way of doing client authentication (after first login, create a client cert and register it for use on that site and you never need to transmit the password from that computer to the server again).
That said, the most common implementation is to have a different client cert for each service, so it doesn't really help tracking (unless you're using a Google client cert for all ad fetches but you're remembering to delete Google cookies).
Netflix uses HTTPS for streaming their movies.
The nice thing about Let's Encrypt is that they are not just a CA, they are also a well-specified protocol (with multiple implementations) for automatically deploying certs. Lots of low-value sites are secured by Let's Encrypt, but once you've got the infrastructure in place then it's relatively easy to switch to any other CA that implements the ACME protocol.
Requests are encrypted. Everything that flows over the TCP connection is encrypted - request and response. The things that are not encrypted are the DNS queries and the IP address of the endpoints.
The PROBLEM is that this is pure security theater to make people feel safer! HTTPS is easily broken by the NSA
Not true. Without HTTPS, an attacker needs the ability to inspect traffic on one hop between you and the server. Stick a tap on a bunch of data centres and you've got pervasive monitoring. With HTTPS, an attacker has two choices:
Option one, they can compromise the server's private key. This requires either cooperating with the provider (if you can lean on them with a national security letter or similar), or hacking the server and exfiltrating the key. There's nothing you can do about this kind of attack, but it's infeasible to do this on all connections.
Option two, they can do an active MITM attack, where they send a valid cert to you, which is signed by a trusted CA that they can lean on to provide arbitrary certs. There are a bunch of defences against this, but the simplest is Certificate Transparency, which makes it easy for you to see that the cert that you're seeing is not the cert that everyone else is seeing. For example, you can check the logs for Slashdot and see that they're using Let's Encrypt, but there seems to be a slightly suspicious cert issued by Amazon that some people are seeing. Chrome integrates these checks, so will warn you of suspicious activity and the server administrator can inspect them and see if any of their users have been attacked in this way. You can also now add CAA records to DNS that indicate which CAs should be trusted for your domain (only useful if you use DNSSEC), which means that they'd have to lean on a specific CA - if you get your cert signed by a US CA, then it's unlikely that the FSB or Chinese intelligence agencies will be able to get a fake certificate, for example.
If you think turning an easy passive attack into a difficult active attack is security theatre then I hope you never work in security.
Https means it can't be loaded from your ISP or company's cache, making popular sites slower
Talk to ISPs. This was a huge deal 10-15 years ago, when the popular subset of the Internet was small enough to fit into caches. Now, the vast majority of fetches miss in caches anyway and a lot of ISPs have stopped running them. With a fast link, the overhead of having to do two TCP handshakes (one to the cache, then one from there to the real site when it misses) plus the latency of forwarding the response via userspace outweighs the gains, so even if your ISP is running a caching proxy, you'll probably find that it's faster to not use it.
The things that consume a lot of bandwidth these days are videos and these are distributed via a CDN, which will have an endpoint in your ISP's POP or one hop away at their upstream exchange. And these support HTTPS. Netflix, for example, is around 30% of all US Internet traffic and now sends all of their data over HTTPS (from OpenConnect appliances running FreeBSD, able to serve 40Gb/s on a single core using HTTPS). YouTube is typically the same, though this benefits less from caching because there's more of a long tail (a huge number of Netflix viewers watch the same things, so it does get some benefit from caching, and they fetch the most popular shows to the caches in advance).
It also prevents corporate security or your own router / firewall from seeing the malware or whatever that some hacker added to the page, and generally keeping an eye out for security problems
Absolute nonsense. It prevents an attacker from performing a MITM and injecting malware. This includes ISPs (or anyone who controls one of the hops between you and the server) injecting ads into web sites that you visit (which has happened).
If the attacker controls the endpoint, then they can force you to use HTTPS anyway by sticking in a 302 response code in the HTTP request, so you lose nothing from having non-malicious sites use HTTPS as well.
You're describing a setup where network security relies on perimeter security (bad idea) and where perimeter security relies on the attacker cooperating and sending readily identifiable malware in plaintext. That setup would fail a security audit by anyone moderately competent.
There *is* the argument that it makes it harder for governments to know which pages you're viewing on a site, but they still see which sites you connect to.
Nope, they'll see which IPs you've connected to, and possibly which DNS queries you've made (though that depends a bit on TTLs and caching). With a lot of sites hosted using vhosts, the IP doesn't tell you very much. You are right that there's more to be done on DNS cloaking. You are wrong that the only adversary of note is a government though - your ISP (who, in the US, is now allowed to collect and sell this data to third parties) can record every site that you visit.
I long for the hardware DVD players of old
Uh, what? DVD players have always had a lot of software. The closest to a hardware DVD player is one that does iDCT and motion compensation in fixed-function hardware and the rest of MPEG-2 in software on a DSP. All of the menus, UDF filesystem parsing, VOB file parsing, player UI and so on were always software.
that were instantly available and didnt have to boot up
At home, I use VLC on a media centre / NAS computer to play DVDs. It's there instantly. Over Christmas, I'm visiting my mother who has a single-function DVD player. It takes about a minute between power on and being able to insert a DVD.
The answer to the first is almost always yes, because the total gain to society almost always outweighs the loss. In the industrial revolution, we went from 4 people each doing a week's worth of work in turn to produce a metre of cloth to 50 people in a factory producing hundreds of metres of cloth a day. The gain from poor people being able to afford to own more than one set of clothes was huge. The overall gain from suddenly having a load of workers available to do things like build railways, dig canals, and all of the rest of the jobs that spurred the industrial revolution was also huge.
In contrast, the human cost of all of the carders, spinners, weavers, and so on being displaced was high. The lack of labour protection laws meant that factories exploited workers and there was a dip in quality of life for a lot of people.
The problem is that the people responsible for the technology and the people responsible for the safety net are different. Self-driving trucks are coming and trying to prevent that is no more feasible than Ludd's Lads preventing the industrial revolution by smashing the machines 200 years ago. What we can do, is learn from the experiences of the past and make sure that there's enough of a tax on new technologies like this that they're still cheaper, but there is enough money in the budget for retraining, unemployment pay, and other things to move these people into new jobs.
The solution isn't to prevent technology that improves economic efficiency from being produced, it's to make sure that the improvements in the economy benefit everyone. Won't happen in the US though: wealth redistribution is a dirty word there, wealth is only allowed to flow to the people that already own a lot of capital.
The problem is not authoritarian governments building these systems, it's less-authoritarian governments building systems and forgetting that their successors might abuse it. Google's panopticon was largely built by well-meaning people who knew that they wouldn't abuse it and so didn't see the potential for abuse.
Skynet was a neural network, it made decisions based on the training data. The training data in the lab led it to believe that every problem could be solved by turning the system off and on again.
Give them a horse analogy. With a little bit of training, a horse will take you from A to B, stopping at traffic junctions and following the road. The 'AI' that we're using for self-driving cars is about as good as a horse at one of the many things that a horse can do. It's taken about 20 years with the current approaches to get to be as good as a horse at a single purpose. Making an AI that can completely simulate the behaviour of a dog or a horse is still far beyond us and (we believe, at least, that) there's a quantitative difference between how a dog thinks and how a human thinks. If your job could be done by a dog, but it's cheaper to train a human, then you should watch out.
It wasn't. It was created by a couple of guys who grew up in the USSR and wanted a platform that they could use to communicate with friends and family abroad, without anyone being able to spy on it. They even had a decent business model: the service was free for a year (so people got used to it and made their friends sign up) and then $1/year after that (cheap enough that it wasn't worth caring about, but more than the cost of providing the service, by quite a large amount). Unfortunately, then Facebook bought them. They're currently in some legal difficulty in the EU, because one of the conditions of allowing the takeover to proceed was that Facebook wouldn't share data between Facebook and WhatsApp. Now Facebook is saying that this is too hard and so they're not going to do it.
Who owns WhatsApp?
The main thing in 14 that was useful is auto parameters on lambdas. You can delete a bunch of copied-and-pasted code with them, where it's not quite enough to be worth a separate templated function, and with 11 you can't factor it out into a lambda because one of the parameters has a different type. The most fun new things in 17 are structured bindings (multiple return values can be decomposed from a pair / tuple), std::optional, std::variant, and std::any.
The version in ports is broken in many ways, based on an old version of Docker, and really shouldn't be there. Docker has now refactored a bunch of their code to provide a sandbox daemon that's responsible for managing isolation and has an abstraction layer for OS-specific services. We are working with them to provide a back end that uses jails.
Note that this is true only for Linux. Docker supports Windows, macOS and Solaris targets, and sort-of supports some BSD flavours. On Windows and macOS, they have ported the FreeBSD hypervisor and run a Linux VM. On Solaris, they use Zones for isolation. If the FreeBSD version is ever finished, they'll use jails.
Why? My projector at home projects a smaller image, but I sit closer so the field of view is similar. My home audio system is set up for people sitting on the sofa that I normally sit on when I'm watching films and doesn't have the base turned up so much that it causes distortions in the speakers (unlike the last cinema I went to). What do I get in the cinema that I don't get at home? If I want to watch a film with more people, I can invite some friends over and, best of all, they bring beer.
This is no different than competing against VHS rental
I disagree. DVD was the game changer: you can blow a DVD up on a projector and not be bothered by the quality, and you often get exactly the same sound track as in a cinema. For a few hundred quid, I bought a DVD player, projector and surround sound system over 10 years ago, which gave me a similar field of view and better sound than my local cinema. The cinemas were only competitive because a ticket was £3-4, whereas a new DVD was £10-20. DVD rental subscriptions shifted this, and for about £10/month, I could rent films 3 at a time through the post. At the same time, the price of a cinema ticket went up to about £6, so two people going to the cinema cost more than renting for a month.
Since then, the quality of projectors has gone up and you can stream HD video. The cinema doesn't offer anything of additional value.