Except that it is a problem. Soon, the only "skilled job" left that robots won't easily be able to replace (or will they?) will be as a prostitute. I sure hope you can "adapt your skills" adequately.
I disagree. I think we would fix a ton of other problems that are strongly resistant to other solutions if just about the only thing we did focus on was income inequality. The problem is, right now, we don't do anything at all about income inequality except allow it to get worse every year for the last 40 years.
I don't get it, it looks like a horrible scooter, a horrible briefcase, and a horrible travel case. It probably weighs a ton to carry, and it costs $6,000?
This looks like an idea better left in a cartoon. It's not compatible with the real world.
Maybe, but a lot is probably the police thinking twice and reserving the situations where they "lose the footage" for rare occasions. They can still abuse it, sure, but it's not worth abusing it most of the time, it looks better and is easier to just do what they're supposed to in most cases. Like if they have to explain why the footage is missing, that's awkward, there are questions. The questions might not leave the department, but it's still a pain to even be asked.
Also, I could point out that requiring validation of TLS certificates for SPDY/HTTP2 prevents actual shared hosting from opportunistically encrypting all the zillions of sites they host, which would be trivial right now (chances are they DO have a certificate installed... in the ISP's name... but not for every site they host). While this wouldn't allow real trusted "HTTPS" connections, it would allow for a LOT of sites to suddenly be using encryption routinely without either the site owners or the end users even knowing it. All the hosting provider would need to do would be to enable SPDY, or later HTTP2, on their servers, and it would start opportunistically encrypting all the hosted sties using the hosting provider's certificate.
This is the same question as what to do with "HTTP" (not HTTPS) requests when transported over HTTP2 (which is supposed to be all TLS) and SPDY (which is already all TLS, and which HTTP2 is based on). Usually it's framed in the context of "do we need to authenticate and verify TLS certificates when the user didn't originally request HTTPS?"
Some people are of the opinion that "TLS is TLS, and if you can't 100% trust it, there's no point." And I can see the logic in that. Obviously that should always be the case when you've explicitly requested an HTTPS connection, and ideally, at some point in the future, it would be nice to be the case for all network connections, all the time.
But when you step back, you have to realize that those connections are currently completely unencrypted and untrusted - they're HTTP, not HTTPS. And that the march to encryption is slow. The majority of websites have no TLS encryption capability at all, maybe as many as 20% of the remainder are self-signed, and quite lot of the rest may have certs which don't match the domain being requested. (The same is no doubt true of apps, mobile or otherwise.) And the latter problem, particularly, is quite difficult to solve for technical reasons in a lot of cases critical to the orderly and economical operation of the internet, such as CDNs.
This goes beyond the usual lament that sites will need to pay $100+ per year to get a cert - that's not really the problem, though from my experience most site owners will have to be dragged kicking and screaming before they bother to install a cert and get HTTPS running properly. Even if a cert is installed, most of them want to redirect back to HTTP at any opportunity.
Besides performance, cost, and administrative hassle, the big problem is the royal pain that it can be to take care of all the issues of trusted certs across hosting providers, CDNs, lead generation partners, etc. That's because in a lot of cases, those providers are hosting assets under a variety of domains - sometimes hundreds or thousands of domains - on single shared servers (or many copies of shared servers), each with a single IP address shared among the various domains. It's shared hosting all over again, this time writ large across global CDNs and the like. Even with your own hosting provider, you might face the same problem on development and staging environments even if not on production, making testing difficult. And while they're working on the problem, so far HTTPS does not play well with shared hosting. (On top of that, a lot of ad networks don't support HTTPS at all, so they introduce the mixed content problem into your pages. If your site depends on ads, you might not be able to serve them over HTTPS connections, which is why some sites offer HTTPS only to paying customers.)
The whole idea of SPDY or HTTP2 being "TLS-only" is laudable, to gain opportunistic encryption even when the user didn't request HTTPS. But by so thoroughly breaking sites with mixed content or untrusted certificates (either expired or self-signed or for the wrong hostname or whatever), I'm of the opinion that all it's doing is delaying the adoption of TLS for websites. Rather than going "oh well, to get HTTP2, we'll have to fix this", most sites, faced with the hassle and resulting broken pages, will drag their heels adding HTTPS or enabling HTTP2, forcing downgrades to HTTP 1 for many years to come.
Encryption absolutists portray the question in simple terms: why would you not want to trust your encrypted connection? You'll be vulnerable to man in the middle attacks, therefore they should always be authenticated and verified. But the real question is: when users haven't specifically requested HTTPS, is it better to have those connections mostly be COMPLETELY unencrypted and untrusted (which are even more susceptible to MITM), but when they are encrypted to trust them (even if the user can't see that they're encrypted or trusted)? Or for a larger proportion of them to be encrypted, but not necessarily always trusted in the f
No, not at all, and I'm fairly sure Comcast has not been.
Previously, Netflix had to go through a middleman to get to Comcast (Cogent, as well as Level 3 and others). They already had to pay those middlemen, and the connections they were getting to Comcast were increasingly congested, probably due to transit providers not wanting to pay for peering even if they were sending a lot more traffic in one direction than the other, and thus the other end not wanting to invest in additional infrastructure to handle that increased one-way traffic. This is typical, has been the standard practice for the life of the Internet, and has nothing to do with "Comcast vs Netflix" or "net neutrality" etc. Peering agreements are supposed to assume roughly equal traffic in both directions from both parties, otherwise the one causing the imbalance in traffic is expected to pay.
Now, Netflix are paying Comcast directly to cut out the middleman and get better, less-congested, direct connections. This means they don't have to pay the other transit providers for the traffic they'll now be sending directly to Comcast, AND it seems their payments to Comcast will be less than what they were paying Cogent et al for the same bandwidth.
So for Netflix, this is win-win: they can cut their bandwidth bill AND get better performance and less congestion streaming movies to Comcast customers. What's the problem?
Net neutrality is a real concern, but this particular case is not an example of it.
You'd be making a mistake then, because Netflix's total bandwidth bill just went DOWN with this arrangement. They were always paying for the traffic to Comcast (as they pay for traffic to everyone), only now they are paying Comcast less for a direct (and better-performing) connection to their network than they were previously paying Cogent, Level 3, et al for more indirect (and increasingly congested and poor-performing), connections to Comcast's network.
Net neutrality is a real issue, but this is not an example of it, it's just Internet infrastructure working as it always has and as it's intended to.
Previously, Netflix did not have a direct peering arrangement with Comcast, so they paid Cogent and others for transit to Comcast.
Now, they have arranged to directly connect their network to Comcast (which was NOT the case before), and, since they are not supplying the roughly equal traffic in both directions typical of "no-pay" peering agreements, they have agreed to pay Comcast for this arrangement.
What they are paying Comcast for direct peering appears to be LESS than what they were paying Cogent et al previously for transit to Comcast... And they have a more direct, and presumably better performing, set of connections now.
This is a win-win for everyone, and has nothing to do with net neutrality. It's a simple arrangement to implement more direct and lower-cost traffic relaying.
First, emissions per capita is a worthless measure. The only one that makes sense is CO2 per $GDP.
I guess the $GDPs are the only thing that matters? That's nice to know, it won't be a problem once all the people of the world are gone, leaving only the $GDPs behind to enjoy the mess.
Then the IOC (and NBC, etc.) should reimburse the US and other governments for the costs for that security. They're the one putting on the event, hyping it up, selling the tickets, they should pay for its costs.
As a cord-cutter, I simply decided I have no interest in watching anything that I'm getting snubbed from. I'm too busy anyway, it's a great excuse not to be watching TV. If it eventually shows up on Netflix, I might eventually watch it (but in the case of the Olympics, probably not). Otherwise, I don't care and it might as well not be happening. I didn't watch the Super Bowl, and I won't be watching the Olympics, and frankly, despite years of religiously thinking I always needed to watch major events like these, I don't miss either in the slightest. (Or the Grammys/Oscars, etc.)
If I'm curious about the ads from the Super Bowl, I can watch them on YouTube, if I don't get bludgeoned with them over and over for the next year anyway. (So far I don't care enough to even look, but isn't it sad that the commercial advertisements are like 10x more interesting than the actual event? Oh wait, the ads ARE the event, the whole reason they want you to watch, like with all television, it's just the Super Bowl is the only place that's made blatantly obvious...)
There's a lot more useful in jQuery than just covering up browser differences, but sure, writing for a single platform definitely eases some of the pain of writing and testing jQuery-less Javascript.
Such as what? Well sure, you can write your web apps in C using G-WAN if sheer performance is your primary concern, as opposed to PHP, Perl, Python, Ruby, Java, C#, etc. But there's a reason people moved from C to other languages: quite simply, developer time is waaaaay more expensive than server time for all but the heaviest uses. (On the other hand, Node.js is very fast for high concurrency transactions and can cut server costs as a result, so you can have both.)
NodeJS is an attempt to get cheaper backend programmers because everyone has extra front end developers lying around for projects.
From this statement it seems you don't know much about NodeJS or why it exists. One thing that's different is that Node.js IS the server, and its pervasively asynchronous, non-blocking, event-driven IO is not something other web servers or language ecosystems offer. JavaScript is a good match for that kind of programming, there are many developers with experience in asynchronous JavaScript programming from the web front end (not all of whom are completely stupid), and Google's V8 engine (which compiles to machine code) is not exactly slow. People are using Node because it is faster than other web backends for transactional responses with high concurrency - AND it happens to be easy to develop for too, compared to, say, Java (at least according to PayPal and others working with it).
if the web were developed for the advanced developer (read: computer scientist), the "web" as we know it would be confined to a few geek niche markets and the rest of us would be using some Microsoft- or Adobe-pushed proprietary technology instead.
Exit relays are trickier to host than just normal relays, because they're the ones police will come asking about when (probably not if) they discover something of interest came from it or was requested by it.
Indeed. But if you read the case study linked from here, you'll see that a major Target initiative over the past decade has been centralizing all of their internal systems, from inventory to pharmacy to in-store security to point-of-sale, into a single physical server per store running Microsoft Server 2008 and Hyper-V virtualization. Furthermore, the virtualization, OSes (some are AIX) and applications are all maintained and updated centrally, not by anyone physically in each store. (Target employs local contractors for in-store installation and maintenance.)
Thus, anyone who is able to access the central source for updates could compromise every IT function running in all Target stores.
The phrase "With Adobe Flash" that starts the review is orthogonal to the book and its content, which never anywhere mentions either "Adobe" or "Flash" as far as I can tell, and is unrelated to the rest of the review. The whole thing would be far better if it just started with "It’s possible to quickly get a pretty web site up and running", despite the somewhat awkward wording, since it's got everyone off on an unrelated tangent. (Neither of the words "Adobe" or "Flash" are found by an Amazon "search within this book", in the Table of Contents or Index of the book, or in a search of the free first-chapter PDF linked in the review.)
The review submitted here is identical to a customer review by the same person on Amazon. It's not bad as customer reviews go, aside from the irrelevant lead-in mentioning Flash, which is now thankfully dead for delivering actual content on most websites. Since this is one of many web content strategy books available, in addition to related books on user experience, usability and information architecture, I'm not sure how newsworthy it is, though prompting clients to think seriously about content strategy, etc. is definitely something all web designers, developers and project managers should be doing, as there are still far too many pretty(-ish) sites lacking readable, useful, or well-organized content.
So? Neither do any other salary figures you see anywhere. Did you think private-sector salaries you hear about were after taxes and health insurance and 401k deductions? Seriously, sometimes the paycheck amount is literally only 50% of the total salary "paid" during that pay period.
It's not improbable. A large amount of CSS in use today, and necessary to achieve the perfectly-reasonable and working results you see on websites, will not pass W3C standard CSS validation without errors. Vendor prefixes, for instance.
Slashdot Mirror
Except that it is a problem. Soon, the only "skilled job" left that robots won't easily be able to replace (or will they?) will be as a prostitute. I sure hope you can "adapt your skills" adequately.
I disagree. I think we would fix a ton of other problems that are strongly resistant to other solutions if just about the only thing we did focus on was income inequality. The problem is, right now, we don't do anything at all about income inequality except allow it to get worse every year for the last 40 years.
I don't get it, it looks like a horrible scooter, a horrible briefcase, and a horrible travel case. It probably weighs a ton to carry, and it costs $6,000?
This looks like an idea better left in a cartoon. It's not compatible with the real world.
Why does anyone think the opinion of a tasteless money-grubbing opportunist matters on this topic?
Maybe, but a lot is probably the police thinking twice and reserving the situations where they "lose the footage" for rare occasions. They can still abuse it, sure, but it's not worth abusing it most of the time, it looks better and is easier to just do what they're supposed to in most cases. Like if they have to explain why the footage is missing, that's awkward, there are questions. The questions might not leave the department, but it's still a pain to even be asked.
the majority of police are good people with a genuine desire to do good in the world
So are the majority of "criminals".
Also, I could point out that requiring validation of TLS certificates for SPDY/HTTP2 prevents actual shared hosting from opportunistically encrypting all the zillions of sites they host, which would be trivial right now (chances are they DO have a certificate installed... in the ISP's name... but not for every site they host). While this wouldn't allow real trusted "HTTPS" connections, it would allow for a LOT of sites to suddenly be using encryption routinely without either the site owners or the end users even knowing it. All the hosting provider would need to do would be to enable SPDY, or later HTTP2, on their servers, and it would start opportunistically encrypting all the hosted sties using the hosting provider's certificate.
My apologies, the second to last paragraph should read "in order to use SPDY or HTTP2 even for "HTTP" requests"...
The extra "HTTPS" is nonsensical in this context and should not be there.
This is the same question as what to do with "HTTP" (not HTTPS) requests when transported over HTTP2 (which is supposed to be all TLS) and SPDY (which is already all TLS, and which HTTP2 is based on). Usually it's framed in the context of "do we need to authenticate and verify TLS certificates when the user didn't originally request HTTPS?"
Some people are of the opinion that "TLS is TLS, and if you can't 100% trust it, there's no point." And I can see the logic in that. Obviously that should always be the case when you've explicitly requested an HTTPS connection, and ideally, at some point in the future, it would be nice to be the case for all network connections, all the time.
But when you step back, you have to realize that those connections are currently completely unencrypted and untrusted - they're HTTP, not HTTPS. And that the march to encryption is slow. The majority of websites have no TLS encryption capability at all, maybe as many as 20% of the remainder are self-signed, and quite lot of the rest may have certs which don't match the domain being requested. (The same is no doubt true of apps, mobile or otherwise.) And the latter problem, particularly, is quite difficult to solve for technical reasons in a lot of cases critical to the orderly and economical operation of the internet, such as CDNs.
This goes beyond the usual lament that sites will need to pay $100+ per year to get a cert - that's not really the problem, though from my experience most site owners will have to be dragged kicking and screaming before they bother to install a cert and get HTTPS running properly. Even if a cert is installed, most of them want to redirect back to HTTP at any opportunity.
Besides performance, cost, and administrative hassle, the big problem is the royal pain that it can be to take care of all the issues of trusted certs across hosting providers, CDNs, lead generation partners, etc. That's because in a lot of cases, those providers are hosting assets under a variety of domains - sometimes hundreds or thousands of domains - on single shared servers (or many copies of shared servers), each with a single IP address shared among the various domains. It's shared hosting all over again, this time writ large across global CDNs and the like. Even with your own hosting provider, you might face the same problem on development and staging environments even if not on production, making testing difficult. And while they're working on the problem, so far HTTPS does not play well with shared hosting. (On top of that, a lot of ad networks don't support HTTPS at all, so they introduce the mixed content problem into your pages. If your site depends on ads, you might not be able to serve them over HTTPS connections, which is why some sites offer HTTPS only to paying customers.)
The whole idea of SPDY or HTTP2 being "TLS-only" is laudable, to gain opportunistic encryption even when the user didn't request HTTPS. But by so thoroughly breaking sites with mixed content or untrusted certificates (either expired or self-signed or for the wrong hostname or whatever), I'm of the opinion that all it's doing is delaying the adoption of TLS for websites. Rather than going "oh well, to get HTTP2, we'll have to fix this", most sites, faced with the hassle and resulting broken pages, will drag their heels adding HTTPS or enabling HTTP2, forcing downgrades to HTTP 1 for many years to come.
Encryption absolutists portray the question in simple terms: why would you not want to trust your encrypted connection? You'll be vulnerable to man in the middle attacks, therefore they should always be authenticated and verified. But the real question is: when users haven't specifically requested HTTPS, is it better to have those connections mostly be COMPLETELY unencrypted and untrusted (which are even more susceptible to MITM), but when they are encrypted to trust them (even if the user can't see that they're encrypted or trusted)? Or for a larger proportion of them to be encrypted, but not necessarily always trusted in the f
No, not at all, and I'm fairly sure Comcast has not been.
Previously, Netflix had to go through a middleman to get to Comcast (Cogent, as well as Level 3 and others). They already had to pay those middlemen, and the connections they were getting to Comcast were increasingly congested, probably due to transit providers not wanting to pay for peering even if they were sending a lot more traffic in one direction than the other, and thus the other end not wanting to invest in additional infrastructure to handle that increased one-way traffic. This is typical, has been the standard practice for the life of the Internet, and has nothing to do with "Comcast vs Netflix" or "net neutrality" etc. Peering agreements are supposed to assume roughly equal traffic in both directions from both parties, otherwise the one causing the imbalance in traffic is expected to pay.
Now, Netflix are paying Comcast directly to cut out the middleman and get better, less-congested, direct connections. This means they don't have to pay the other transit providers for the traffic they'll now be sending directly to Comcast, AND it seems their payments to Comcast will be less than what they were paying Cogent et al for the same bandwidth.
So for Netflix, this is win-win: they can cut their bandwidth bill AND get better performance and less congestion streaming movies to Comcast customers. What's the problem?
Net neutrality is a real concern, but this particular case is not an example of it.
You'd be making a mistake then, because Netflix's total bandwidth bill just went DOWN with this arrangement. They were always paying for the traffic to Comcast (as they pay for traffic to everyone), only now they are paying Comcast less for a direct (and better-performing) connection to their network than they were previously paying Cogent, Level 3, et al for more indirect (and increasingly congested and poor-performing), connections to Comcast's network.
Net neutrality is a real issue, but this is not an example of it, it's just Internet infrastructure working as it always has and as it's intended to.
Previously, Netflix did not have a direct peering arrangement with Comcast, so they paid Cogent and others for transit to Comcast.
Now, they have arranged to directly connect their network to Comcast (which was NOT the case before), and, since they are not supplying the roughly equal traffic in both directions typical of "no-pay" peering agreements, they have agreed to pay Comcast for this arrangement.
What they are paying Comcast for direct peering appears to be LESS than what they were paying Cogent et al previously for transit to Comcast... And they have a more direct, and presumably better performing, set of connections now.
This is a win-win for everyone, and has nothing to do with net neutrality. It's a simple arrangement to implement more direct and lower-cost traffic relaying.
First, emissions per capita is a worthless measure. The only one that makes sense is CO2 per $GDP.
I guess the $GDPs are the only thing that matters? That's nice to know, it won't be a problem once all the people of the world are gone, leaving only the $GDPs behind to enjoy the mess.
The US is destroying democracy because in practice voting anywhere outside of the US is useless.
Voting inside the US is useless too. Do you seriously think the US is still a functioning democracy at the federal level?
Then the IOC (and NBC, etc.) should reimburse the US and other governments for the costs for that security. They're the one putting on the event, hyping it up, selling the tickets, they should pay for its costs.
As a cord-cutter, I simply decided I have no interest in watching anything that I'm getting snubbed from. I'm too busy anyway, it's a great excuse not to be watching TV. If it eventually shows up on Netflix, I might eventually watch it (but in the case of the Olympics, probably not). Otherwise, I don't care and it might as well not be happening. I didn't watch the Super Bowl, and I won't be watching the Olympics, and frankly, despite years of religiously thinking I always needed to watch major events like these, I don't miss either in the slightest. (Or the Grammys/Oscars, etc.)
If I'm curious about the ads from the Super Bowl, I can watch them on YouTube, if I don't get bludgeoned with them over and over for the next year anyway. (So far I don't care enough to even look, but isn't it sad that the commercial advertisements are like 10x more interesting than the actual event? Oh wait, the ads ARE the event, the whole reason they want you to watch, like with all television, it's just the Super Bowl is the only place that's made blatantly obvious...)
There's a lot more useful in jQuery than just covering up browser differences, but sure, writing for a single platform definitely eases some of the pain of writing and testing jQuery-less Javascript.
There are faster languages for server side
Such as what? Well sure, you can write your web apps in C using G-WAN if sheer performance is your primary concern, as opposed to PHP, Perl, Python, Ruby, Java, C#, etc. But there's a reason people moved from C to other languages: quite simply, developer time is waaaaay more expensive than server time for all but the heaviest uses. (On the other hand, Node.js is very fast for high concurrency transactions and can cut server costs as a result, so you can have both.)
NodeJS is an attempt to get cheaper backend programmers because everyone has extra front end developers lying around for projects.
From this statement it seems you don't know much about NodeJS or why it exists. One thing that's different is that Node.js IS the server, and its pervasively asynchronous, non-blocking, event-driven IO is not something other web servers or language ecosystems offer. JavaScript is a good match for that kind of programming, there are many developers with experience in asynchronous JavaScript programming from the web front end (not all of whom are completely stupid), and Google's V8 engine (which compiles to machine code) is not exactly slow. People are using Node because it is faster than other web backends for transactional responses with high concurrency - AND it happens to be easy to develop for too, compared to, say, Java (at least according to PayPal and others working with it).
It is certainly not anything like ASP.
if the web were developed for the advanced developer (read: computer scientist), the "web" as we know it would be confined to a few geek niche markets and the rest of us would be using some Microsoft- or Adobe-pushed proprietary technology instead.
FTFY.
Exit relays are trickier to host than just normal relays, because they're the ones police will come asking about when (probably not if) they discover something of interest came from it or was requested by it.
Indeed. But if you read the case study linked from here, you'll see that a major Target initiative over the past decade has been centralizing all of their internal systems, from inventory to pharmacy to in-store security to point-of-sale, into a single physical server per store running Microsoft Server 2008 and Hyper-V virtualization. Furthermore, the virtualization, OSes (some are AIX) and applications are all maintained and updated centrally, not by anyone physically in each store. (Target employs local contractors for in-store installation and maintenance.)
Thus, anyone who is able to access the central source for updates could compromise every IT function running in all Target stores.
The phrase "With Adobe Flash" that starts the review is orthogonal to the book and its content, which never anywhere mentions either "Adobe" or "Flash" as far as I can tell, and is unrelated to the rest of the review. The whole thing would be far better if it just started with "It’s possible to quickly get a pretty web site up and running", despite the somewhat awkward wording, since it's got everyone off on an unrelated tangent. (Neither of the words "Adobe" or "Flash" are found by an Amazon "search within this book", in the Table of Contents or Index of the book, or in a search of the free first-chapter PDF linked in the review.)
The review submitted here is identical to a customer review by the same person on Amazon. It's not bad as customer reviews go, aside from the irrelevant lead-in mentioning Flash, which is now thankfully dead for delivering actual content on most websites. Since this is one of many web content strategy books available, in addition to related books on user experience, usability and information architecture, I'm not sure how newsworthy it is, though prompting clients to think seriously about content strategy, etc. is definitely something all web designers, developers and project managers should be doing, as there are still far too many pretty(-ish) sites lacking readable, useful, or well-organized content.
How do we know that's what they are SUPPOSED to be doing? Did they ever ask us if that's what we wanted them to be doing?
So? Neither do any other salary figures you see anywhere. Did you think private-sector salaries you hear about were after taxes and health insurance and 401k deductions? Seriously, sometimes the paycheck amount is literally only 50% of the total salary "paid" during that pay period.
It's not improbable. A large amount of CSS in use today, and necessary to achieve the perfectly-reasonable and working results you see on websites, will not pass W3C standard CSS validation without errors. Vendor prefixes, for instance.