By the time they discontinued the 16 GB model, it almost certainly wasn't selling very well. The folks who were buying such an old phone in 2014 were buying it because it was extremely inexpensive or free. Buyers who could afford to spend a hundred bucks more for 16 GB tended to instead spend that hundred bucks on upgrading to a 5c.
An underscore (_) is prepended to
the service identifier to avoid collisions with DNS labels that
occur in nature.
Which is to say that legal DNS labels may not include underscores. They are exclusively allowed for non-hostname types, such as service records, and they specifically chose that character for this use to ensure that it cannot conflict with any legal DNS name.
The real problem is that, yet again, systemd has been involved in critical functionality breaking in an unusual and unexpected way.
No, the real problem is that Netflix violated RFC 1034 section 3.5 and RFC 1035 section 2.3.1, which both explicitly say that hostnames must still conform to the old ARPANET restrictions, which allow only letters, numbers, and hyphens. Underscores have never been legal in DNS hostnames, and in spite of the pain this spec-compliant behavior has caused for some users, the systemd behavior is correct, and Netflix needs to fix whatever broken software they have that incorrectly created an invalid hostname containing an underscore.
The remarkable thing, frankly, is that any DNS resolver resolved that address, and more significantly, that the DNS servers actually responded to the request.
Says she bought it in 2014? They were on the iPhone 6 as of Sept 2014.
Apple doesn't just sell one model of phone at a time. In 2014, Apple was selling the iPhone 6 / 6 Plus, the iPhone 5s, the iPhone 5c (an iPhone 5 with a cheaper, plastic back), and the iPhone 4s.
Who said anything about spoofing? Suppose an attacker manages to crack into one of the servers that provides a domain's DNS. That same server won't provide DNS for the domain that hosts the tech contact's email.
No, from a security perspective, checking only that you control the web server is much, much weaker than checking to see if you're the tech contact for the domain, and IMO, they should never have been allowed to cut that corner. The only reason they had to do that was that they made the decision to use 90-day certs under the bizarre assumption that servers are constantly getting compromised and their keys stolen, and that limiting the window in which stolen certs can be used is more important than preventing someone from creating a fake, valid cert for a domain that isn't getting constantly compromised.
Unfortunately, that decision led to weaker verification, and worse, the same flawed logic led to the clients rekeying every time they recert, thus preventing key pinning (another security technique intended to prevent attackers from being able to spoof domains). So all the problems that I have with LetsEncrypt from a security perspective stem from basically the same bad decision, give or take.
Going to higher bit counts typically means a longer conversion time and potentially a more expensive ADC (for reasons which are obvious if you know how ADCs work but not worth mentioning here, especially as there are different ADC types with different reasons)
I think you mean "or". It means a longer conversion time or a more expensive ADC. If you want, you can build an ADC that is fully parallel, where it generates a complete value in a single clock cycle, or you can build one that is entirely done by successive approximation, where it computes one bit per clock cycle, or anything in between.
Try building a 24bit ADC with a 100MSPS (million samples per second, M=Mega) no one that I know of can do it.
Even for 14 or 16 bits, they use multiple ADCs in parallel, fed by multiple amplifiers in parallel. The EOS-1D X (2012 version) uses a whopping 16 parallel channels to read out an 18.1 MP sensor, which means it does just under 14 million samples per second when shooting at 12 fps. In principle, there's no reason you couldn't use even more parallel ADCs if you have the die size to support it, though that does get crazy at some point.
The reason they don't even consistently do 16 bits is because the extra bit depth beyond about 14 bits per color channel doesn't really buy you much when balanced against the huge cost of storing half again more data per color channel, and half the photographers compress that straight down into 24-bit (8-bit-per-channel) JPEG anyway.
What's interesting is that TI hit 4 megasamples per second at 24-bit depth back in 2008, and the state of the art seems to have stopped improving since then. That tells me there's probably no market for it.
Wait... you actually use an email address at the domain as the contact email for the domain? Yikes.
Or do you mean that you can change the email on the domain? Because that may or may not be true, depending on whether you crack the account of the admin contact, the tech contact, or the billing contact.
That's not entirely true. Other CAs require the owner of the domain to confirm the validity of the request via email. The 90-day renewal period makes that approach more difficult, because nobody would be willing to go through that headache every 90 days. Instead, Let's Encrypt just checks to see if you've managed to convince the registrar or the DNS server to point the domain name at your server. So while they might not choose to do more validation even if there were longer validation periods, they would at least have the option of doing so.
One big reason for the volume of certificate issuance is that LetsEncrypt forces you to update your certificates at least once every 90 days. This means that the number of certificates issued is guaranteed to be at least 4x the number that would be issued by a traditional CA, and realistically, more like 12x or even 20x.
So yes, they should be criticized, but they should be criticized for the ridiculously short certificate expiration times that result in them issuing so many certificates each day, not for the number of certificates per se. That silly policy decision inherently limits the amount of verification that they can do, so even if they wanted to do more, they can't.
Not sure who modded this "troll", but the AC is quite correct.
Image sensors have a number of physical limits other than the ADC. It's easy to get a bigger ADC. Most image sensors only use 14–16 bits these days, whereas 24-bit ADCs are readily available. There's room for improving the dynamic range of the ADC portion of image sensors by more than two orders of magnitude (256x) with relative ease. Camera manufacturers haven't bothered to do so, however, largely because the primary limitations in image sensors are not the fault of the ADC. Rather, they're from things like the full well capacity of the capacitor that stores the analog value for the the pixel itself (which is largely determined by the die size) and the need to read out the pixels and shove the data into storage quickly (which means keeping the data rate and processing delays to a minimum).
Were it not for the latter limitation, we would just sample the sensor ten times as often and sum the values (as I, and no doubt others, have suggested for many years). And I still think that with some interesting on-die DSP, that would be possible, but it isn't feasible right now, as far as I can tell.
And in the audio world, at least in practice, 24-bit audio provides enough bit depth that we can leave the levels low enough to avoid digital clipping without losing precision. IMO, digital clipping hasn't been a major issue in the audio world for at least a decade, though I suppose this will help if you screw up and set the levels too high anyway. It's the gain staging leading up to the ADC that gives folks the biggest headaches these days, and that's caused by getting too close to one of the rail voltages for an amplifier at any point through the chain. And changes to the ADC won't help with that.
I'm sure there are situations where existing ADCs can't cope—perhaps in industrial applications—but audio and photography don't seem like good candidates to me.
This is an interesting approach, and it would work pretty well for things like audio. It might help with the dynamic range of cameras when used at higher ISO settings, but it will not solve the problem by any means. The problem, though, is that in modern cameras, the sensor's pixels also have a maximum capacity, called the full well capacity. The sensor can't physically accumulate more of a charge than its full well capacity, and the DAC is designed so that its clipping point matches the full well capacity of the sensor at its base ISO. So you would still get clipping when the brightness exceeds what would otherwise by the sensor's clipping point at its base ISO, and if it is already at its base ISO, this wouldn't make any difference at all.
IMO, a better approach (which I proposed several years ago) is to sample the sensor and physically cancel out (subtract) the measured charge in the sensor itself, doing this multiple times per exposure to ensure that you don't hit the full well capacity. That approach also has the advantage of letting you do really cool time-based manipulation of the resulting photo. For example, you could do vector-based motion compensation of the individual subframes to dramatically reduce motion blur, compensate for some amount of camera shake, etc.
Even better, if you represent subsequent subframes relative to the previous subframe (e.g. -12 here, +2 there), you'll also usually get a high percentage of zeroes, which means you should be able to losslessly compress the additional subframes to be pretty small on average, potentially giving you the ability to adjust the image motion compensation after the fact to get an image in which motion is blurred more or less, according to taste.
In theory, you could even do bizarre, per-region motion compensation, such as making a baseball appear to be motionless while the bat is swinging at a high speed or vice versa.:-D But I digress.
I am hardly ignoring it when I am the one who has to keep trying to get you to understand that the fast lane is NOT the car to cell tower wireless connection but from the company providing the data.
The sort of hypothetical, magical fast lane that you describe is effectively impossible, both from a business perspective and from a technical perspective. This is the sort of idea that could only be conceived of by someone who has no clue how massive the data going across Internet backbones is, and thus has no concept of how hard it would be to do any sort of prioritization of traffic on its way through those backbones. We don't limit our discussion of fast lanes to the final hop between ISPs and the backbone because we don't know any better. We limit our discussion to that because any attempt to extend a fast lane beyond that point is about as likely as bottling up unicorn farts and using them as fuel for rockets to Mars.
You don't really think that an AV seeking a specific kind of data is going to multicast a request instead of having a connection open to a specific host, do you?
An autonomous vehicle seeking any data that would make sense to send via multicast will almost certainly receive it asynchronously in a broadcast fashion when the data changes, and it won't be over the Internet. It will be from satellite radio, terrestrial broadcast radio, or broadcast SMS (CB). Multicast would be utterly crazy to attempt, because it provides no real advantages over broadcast, and involves enormous technical complexity that has yet to be solved despite lots of very smart people spending about four decades trying.
because the car company would almost certainly pay for permanent network access for their cars as they do now (and thus would be that ISP's customer)
And Comcast's customer may very well be the source of that data.
That's perfectly fine. Paying for an Internet connection is not paid prioritization. Therefore, by continuing to revert to an example that doesn't involve paid prioritization, you have effectively proven that your hypothesis (that paid prioritization for self-driving cars might somehow be helpful) is unsupportable.
By contrast, what you're describing requires A. timing-critical (latency-sensitive) communication to be required between an autonomous vehicle and other, relatively distant autonomous vehicles
I am requiring nothing, and certainly nothing from AV to AV.
Okay, wise-a**. Between an autonomous vehicle and other, relatively distant autonomous vehicle, safety cone, road sensor, or other apparatus that is physically located on or near some road that is on a directed graph between the vehicle's current location and the vehicle's destination. Happy?
The original topic of discussion is the ability to create a paid fastlane for some companies FOR DATA CARRIED OVER THE INTERNET to AVs. Now that you finally admit that the data does, indeed, traverse the internet and not just the "last mile" wireless connection from some cell carrier to the car, maybe you realize that a fast lane for that data is ON THE INTERNET, which net neutrality laws would prohibit.
First, no, net neutrality laws do not prohibit a fast lane. They prohibit paid prioritization, which means granting a fast lane from an ISP's customers to a specific company in exchange for money from that company.
Second, I neither said nor implied that data only traverses the last mile.
So again, congratulations. You just proved a tautology that does nothing to counter anything that I or anyone else on this thread has said.
existing cellular networking is well beyond the point where making latency better is not worth the expense.
And now you're back at considering only the wireless cell carrier connection and not the entire path for the data. I had such high hopes that when you admitted that the data comes over the internet that you might look at the big picture, but sadly, no.
I am looking at the big picture. You're just wildly flailing and making crap up. Here's a quick tutorial in networking in only ten words: A network can never be faster than its slowest link. For the foreseeable future, the slowest link will be the cellular network. Now do you get why nobody even bothers talking about a "fast path" through the entire Internet? Yes, it's theoretically possible for traffic to get slightly delayed at any of the various hops along the way, but that invariably pales in comparison with the huge latency in the last few hops between the customer and the backbone, because that's where ISPs are cutting corners in capacity.
a car must be capable of driving safely without relying on the Internet. That's an indisputable fact.
You say I'm the one making that statement, and then you repeat it again yourself. You deny that there might be any data that can make the car operate more safely that it could get from the internet, and that's just poppycock.
What is wrong with your reading comprehension? Saying that a car must be able to drive safely without relying on the Internet does not mean that an Internet connection cannot make a car safer. It is always possible to make something safer. Always. The fact that it is possible to make something safer DOES NOT MEAN IT IS NOT SAFE.
Your "indisputable facts" are also indisputable opinion.
My indisputable facts are governed by the laws of physics. Unless, of course, you'd like to throw all science out the window, in which case, sure, you might be right, and I might have magically gained the ability to fly because of the sunburn I got last week.
If find "it's obvious" to be a particularly unconvincing argument, especially when it comes to the future.
The only way the things I talked about could possibly not happen would be if nobody ever tried to start any new video-on-demand companies or tried to innovate while doing so. Otherwise, the very existence of paid prioritization fundamentally puts those innovators at a disadvantage because of their size. My argument was not that "it's obvious". My argument was very detailed and thorough. If, after reading it, the correctness of my argument is not obvious to you, the problem is not with my argument, but with your knowledge and understanding of the subject.
from content providers that are not their customers
I think the point is that the data providers on the internet, using Comcast business ISP ser
So the data that it isn't originating comes from somewhere else, right? Like OVER THE INTERNET. Pulling teeth, but we finally got there.
You aren't making any sense. At all. Yes, data that a car obtains over the Internet comes from the Internet. Congratulations. You've just stated a tautolog that has no bearing on the original topic of discussion.
It can't, because it isn't plausible for an autonomous car to need data that is simultaneously both time-critical and coming from something that isn't physically nearby
History is replete with people making grand pronouncements of what is good enough for the future. "All you need is a good ship and a few stars to sail her by." And now we have GPS. "GPS with selective availability is all anyone needs to keep track of where they are." And now SA is turned off and we can do so many more things.
As I've said elsewhere, information is either personalized to the vehicle and its position or it isn't. For information that isn't personalized to the vehicle, there's no benefit of a polling model through a "fast path" over a broadcast model. For information that is personalized to the vehicle, it either is about something nearby or something far away. If it is about something near you, no matter what you do, the laws of physics won't allow you to get the latency down to the point where you can do that via the Internet. And if it is about something far away, timing is not critical. Ostensibly, there might be some slight areas on the fringe where it would occasionally have been better if a device got information slightly earlier, but in the grand scheme of things, this is lost in the statistical noise.
And even if it were detectable above the noise—a whole tenth of a percent—it still wouldn't make sense to use prioritization (paid or otherwise) to achieve it. The thing is, you can always make something better. There comes a point at which making things better is not worth the expense, and for all currently conceivable self-driving car tech, existing cellular networking is well beyond the point where making latency better is not worth the expense. For example, we could theoretically cause two or three extra cars to take a different route around the accident by reducing latency (assuming you don't just use a broadcast model, which makes far more sense than any low-latency polling model), but it wouldn't be worth making a million cars poll the servers four times as often just to save a few minutes for a couple of cars.
"The only data an AV can ever ever need is what it can get from other cars around it" is another such pronouncement.
You're the only one implying that any of us ever said that. What we said was that:
a car must be capable of driving safely without relying on the Internet. That's an indisputable fact.
Some data applies to an entire region (e.g. earthquake early warning). That can and should be broadcast region-wide to avoid wasting precious bandwidth. That's also an indisputable fact.
Apart from such broadcast data, no data can realistically be time-critical unless it is being generated physically close to you, because if you're far away from the incident or whatever, you will still have plenty of time to act on information about it even if the information gets to you later. That's also an indisputable fact.
If information is generated near you, you'll always get the information faster if you get it directly from the source rather than over the Internet. That is also an indisputable fact.
The odds of the universe changing such that I become wrong on any one of those points before the heat death of the universe are only slightly higher than the odds of a self-driving car (not airplane) crashing into the window outside my boss's office (which is not on the ground floor). You're arguing about the possibility
It can't, because it isn't plausible for an autonomous car to need data that is simultaneously both time-critical and coming from something that isn't physically nearby (thus having to go over the cellular network). The importance of quickly finding out about a problem is inversely proportional to the distance between you and that problem. That said, your argument presupposed that such data would someday be needed, so I was starting from that rather implausible assumption for the purposes of argument.
Actually, I just thought of one very narrow example of something that qualifies: warnings about an approaching earthquake. Of course, there's no plausible situation in which that piece of information would need to be personalized to a specific vehicle, so it is more appropriately transmitted as a broadcast rather than using any sort of Internet-based communications.
So let me revise that very, very slightly: It isn't plausible for an autonomous car to need data that is tailored to that vehicle, time-critical, and comes from something that isn't physically nearby. Thus, every possible problem can be solved both more effectively, more efficiently, and more cheaply via some other mechanism besides a so-called "fast lane".
If a vehicle cannot make reasonable decisions without external data, then that means it cannot safely drive unless another vehicle has recently driven the road to provide that data. Such a vehicle might pedantically be described as autonomous, but it is not usefully so.
Wow, you just keep proving how stupid you are. All cars driven by humans are autonomous, and don't need another vehicle to have driven the road before they do.
No, vehicles driven by a human are explicitly not autonomous. Autonomous in the context of vehicles means exactly one thing: capable of operating without a human in control. A vehicle with a human control is precisely the opposite of autonomous. You could maybe argue that the human is autonomous, but I'm pretty sure the Continental Congress declared that self-evident a couple hundred years ago.:-)
We're talking about replacing the driver. That is perfectly doable without any internet connection whatsoever. It's also a current requirement.
Huh? Of course it is doable without any Internet connection. In fact, that's precisely what I said in the text you quoted. A vehicle must be able to drive itself safely without external data (e.g. data obtained over the Internet, data obtained from other nearby vehicles, etc.). If it can't, then it is not a viable autonomous vehicle design.
Only in the relatively short term, before the robots learn to do the surgery themselves.
Besides, that won't require paid prioritization, because those customers will buy end-to-end dedicated fiber links with throughput guarantees. That data will never plausibly see the public Internet, because if it does, hackers will find a way to kill someone with it.
And even if they ran it over the public Internet (yikes!), it still wouldn't fall within the currently very narrow FCC ban on paid prioritization because the hospital's ISP would be charging money to the hospital that is its own customer, not to the hospital at the other end of the connection.
The problem is that the term "fast lane" is a gross misnomer here. It is an exceptionally imprecise description of what the law prohibits, and as a result, it sounds like exceptions would be useful when in fact, they would not. The law bans ISPs from charging money to companies that are not their customers in exchange for providing adequate data throughput between those companies and their customers. It does not ban ISPs from charging money to their own customers in exchange for getting sufficient data throughput.
FYI, a sizable percentage of VoIP-like traffic is over TCP these days, because UDP is too unreliable and suffers too badly from fragmentation, so being able to drop VoIP packets willy-nilly isn't really a safe assumption anymore.
I have a cellular modem. How does the cell company know it isn't in a car? How does the cell company know it isn't data for the onboard entertainment system which isn't as important?
Because car communications systems have IMEI numbers or equivalent indicating that they were built by a car company, and uses a different APN or whatever when providing data for tethering versus non-tethering. That's all pretty trivial.
And how is the cell company originating all this data, and not some company on the internet that is sending it to the car?
??? That question doesn't make sense. The cell company isn't originating anything. It is providing service, with different speeds of service, depending on whether the traffic is originating from the autonomous vehicle portion of a car or not. The direction of data flow is immaterial; what matters is that the car's owner (or the car's manufacturer) is the ISP's customer, and thus purchases service appropriate to the vehicle's data needs.
There's no reason to allow what is at that point a basic consumer need
How can data that isn't needed become a "basic consumer need"?
It can't, because it isn't plausible for an autonomous car to need data that is simultaneously both time-critical and coming from something that isn't physically nearby (thus having to go over the cellular network). The importance of quickly finding out about a problem is inversely proportional to the distance between you and that problem. That said, your argument presupposed that such data would someday be needed, so I was starting from that rather implausible assumption for the purposes of argument.
Wouldn't it be interesting to figure out sometime in the not too distant future that not all data that an AV can use to make a trip safer will be stuff it gets from the car next to it, but might also come from a server somewhere on the internet?
We already know that some data that an autonomous vehicle can use to maybe make a trip slightly safer could conceivably come from the Internet—things like ice on roads, for example. But—and this is a big but:
A vehicle has either detected the problem or it hasn't. If no other vehicle has detected the problem, then the information cannot be obtained, period. So the data won't just come out of nowhere, realistically.
If the two vehicles are close enough together that the second vehicle needs the information within single-digit seconds, it needs to get that information directly from the other vehicle, because server-based networking can't currently relay the data quickly enough (even with all the bandwidth in the world; the hard problem is figuring out who should get the data, not getting the data there).
If the two vehicles are far enough apart that the second vehicle does not need the information within just a few seconds, then it doesn't need prioritization to get the data in time.
Realistically, most road conditions are not sudden. They come on over a period of time. So usually you'll have O(hours) to find out about road conditions. Nobody is going to try to come up with some crazy system in which a server somehow continuously tracks a car by GPS to find out what cars might be near it quickly enough to do rapid messaging via a server, because it is computationally infeasible now, and by the time it is computationally feasible, the network bandwidth will be trivial; the odds of such a colossally expensive and complex scheme providing any real benefit right now are so small that you couldn't possibly justify the cost, and by the time you could justify the cost, networks will be fast enough that paid prioritization would be unnecessary.
The notion of autonomous vehicles benefitting from any significant prioritization really is quite absurd, much less paid prioritization, which as I have said elsewhere, by its very definition can only benefit one car manufacturer over another, and cannot actually benefit consumers.
Also, a paid fast lane is a fast path from vehicles of a specific company to the Internet backbone.
It is a fast lane for a company, on the internet, for data relevant to AVs. Every connection from an AV to the internet goes someplace. "Vehicle to anywhere" has an anywhere to connect to. That "anywhere" is on the internet. Why is this so hard?
It is a fast lane for a specific company, on the Internet, for data relevant to AVs. It's that boldfaced part that you seem to be deliberately ignoring here.
If only the only important thing was getting to the backbone, and not to the data source or sink at the other end of the internet connection. If so, why do people complain so bitterly about congestion at border gateways? They've got their 50Mbps connection to the "backbone", what else is important? Oh, you mean actually getting data over that backbone, all the way from the source to the destination, is an issue?
It's not the only important thing. And that's why paid prioritization is useless except as a workaround for a specific ISP providing inadequate throughput to the backbone. The ISP can't guarantee faster throughput to the destination. All it can do is guarantee faster throughput to the backbone for traffic being sent towards a particular destination, which is what paid prioritization is all about.
It also says that company B, that provides data used by AVs, cannot pay more to get their data prioritized to the AVs. That's the part you keep missing. Data from company B going to ALL and ANY AV is one company getting priority over others.
Yes, and that shouldn't be allowed. What should be allowed is for company B to ask the ISPs to prioritize traffic from all companies to autonomous vehicles without charging money to the autonomous vehicle company.
Yes, which will be the same as the data from Netflix or Google or.... Perhaps you can define how you know what this data (and only you are limiting it to "vehicle navigation data") is and that it is bound for an AV and not another system. Will AVs get allocated a specific address block? Oh, wait, that would be prioritization based on source or destination -- clearly not net neutral.
The usual approach would be for the prioritization to be based on the fact that it is coming from an autonomous vehicle. Prioritization based on source is not and has never been a net neutrality issue. If it were, it would be illegal to charge higher fees for faster Internet service. That's prioritization based on source. Net neutrality just bans ISPs from charging money to companies that are not their customers for better access to their customers.
Thus, the entire concept of paid prioritization would likely be inherently nonsensical in the context of autonomous cars, because the car company would almost certainly pay for permanent network access for their cars as they do now (and thus would be that ISP's customer) and thus would have the right to pay for whatever class or speed of service suited those vehicles.
But even supposing that the individual customers paid for service, there would still be nothing preventing the car companies from creating innovative features that require fast connections, because the customers would have the option of choosing whether or not to pay for that faster class of service to enable such innovative features.
Either way, it would not require paid prioritization, according to the legal (FCC) definition thereof.
The fact is, this is new stuff. We don't have a history of AVs cluttering the highways yet. Those AVs that are out there are few, far between, and in many cases populated by engineers supervising the autonomous behavior. We don't know what kinds of data might be critical to have, yet. That's why we want to allow innovation. Saying
"Real-time" has many meanings when used by humans. It doesn't always means "microseconds."
By any meaningful definition, traffic data is not real-time. It is not a continuous stream of data from radar stations directly to you. Traffic data is only periodically updated, and is delayed significantly as it propagates from system to system and is accumulated, averaged over time, etc., so the traffic data you're seeing is likely minutes old. A single car obtaining traffic data in anything approaching real time would likely bring the cellular network utterly to its knees, much less millions of them. And more importantly, high-speed delivery doesn't usually matter, because the average speed of traffic on a section of road doesn't change very quickly (even when there's an accident, typically, unless a semi flips and blocks all lanes). It takes minutes for a wreck to bring a multi-lane road to a standstill.
When a crash blocks the highway they better slow down ALOT and RIGHT NOW or else they're going to join the fun of an ambulance ride, or watching their cars get towed away. By law, the first cars are supposed to stop to provide assistance.
No kidding. This is why autonomous vehicles have cameras, LIDAR, and orders of magnitude faster response time than any human. That doesn't require fast cellular networking. It doesn't even benefit from it.
By law, the first cars are supposed to stop to provide assistance.
In what country? At least in the United States, as a rule, you are not required to stop for an accident, though I suppose there might be some state that requires doctors/nurses/medical professionals to do so, possibly as part of medical licensure laws. In some states, you're required to render aid if you do stop, but nothing requires you to stop.
That is so stupid that I know you must be trolling at this point. Autonomous does NOT mean "without external data". It means that it makes decisions about how to respond BASED ON EXTERNAL DATA instead of the human making those decisions.
If a vehicle cannot make reasonable decisions without external data, then that means it cannot safely drive unless another vehicle has recently driven the road to provide that data. Such a vehicle might pedantically be described as autonomous, but it is not usefully so.
Do you not understand what "example" means? As in, real-time traffic data is just one example what kinds of data would be useful? Wait, you think "useful" means "mandatory", so no, I don't doubt that "example" is also beyond you.
Getting traffic data slightly sooner is not, in practice, useful, as I already pointed out. And all data that a car could usefully take advantage of falls into one of two categories: things that are happening nearby and that must be reported immediately and things that are not happening nearby and that can wait a long time. The former should absolutely never be sent via cellular data, because A. determining what vehicles are nearby cannot realistically be done over a cellular network reliably enough and quickly enough to not be a huge burden on the network for no good reason, B. even in the best case, it would be way too slow to be practical, and C. such an approach would not work at all if you were outside cellular territory, which means you would necessarily want to provide a local radio fallback anyway, thus making the cellular path only practically useful for the latter—for data that is non-urgent. This will always be the case, necessarily, because the laws of physics don't change.
Those are two examples of data that humans use that would benefit from prioritization, but thinking that's the only data possible is basing a long-term decision on static thinking. We don't know all the kinds of data that AV might make use of because, first of all, YOU are adamant that the AV cannot use it (because if it did it wouldn't be autonomous) and second because they aren't common on the highways yet and we don't know what might be important.
We have autonomous vehicles out there on the roads today, and exactly none of them benefit from prioritization, much less paid prioritization. They barely even use the cellular network. If all those engineers from multiple different companies all have concluded that there's no need for a fast data lane for autonomous vehicles, then it's pretty safe to say that there isn't.
And besides, that is still completely irrelevant, because no data benefits from paid prioritization, which is not about prioritizing based on the type of data at all, but rather based on what company's servers are on the other end. The only "benefit" that can ever come from paid prioritization, by definition, is one company getting priority for their traffic over that of another company's traffic of a similar kind, e.g. Ford getting traffic data to their cars faster than Chevy. There cannot possibly be a benefit to consumers from that, period.
For a specific source, remember. Net neutrality, in the minds of the zealots, means NO differentiation, not that it is ok to slow their email or web browsing down because someone else has a video (or data that an AV can make good use of to mitigate risks) that needs higher priority.
No, this is not what net neutrality means. That's a straw man put forward by minions of major ISPs to give them something to attack. It is almost universally agreed upon by everyone that basic QoS should be allowed under net neutrality—that traffic requiring low jitter/latency should get slight temporal priority over traffic that does not, within reason.
And QoS is explicitly exempt from the paid prioritization ban that Comcast is claiming will someh
Slashdot Mirror
By the time they discontinued the 16 GB model, it almost certainly wasn't selling very well. The folks who were buying such an old phone in 2014 were buying it because it was extremely inexpensive or free. Buyers who could afford to spend a hundred bucks more for 16 GB tended to instead spend that hundred bucks on upgrading to a 5c.
Nope. You misread it. That RFC says:
Which is to say that legal DNS labels may not include underscores. They are exclusively allowed for non-hostname types, such as service records, and they specifically chose that character for this use to ensure that it cannot conflict with any legal DNS name.
No, the real problem is that Netflix violated RFC 1034 section 3.5 and RFC 1035 section 2.3.1, which both explicitly say that hostnames must still conform to the old ARPANET restrictions, which allow only letters, numbers, and hyphens. Underscores have never been legal in DNS hostnames, and in spite of the pain this spec-compliant behavior has caused for some users, the systemd behavior is correct, and Netflix needs to fix whatever broken software they have that incorrectly created an invalid hostname containing an underscore.
The remarkable thing, frankly, is that any DNS resolver resolved that address, and more significantly, that the DNS servers actually responded to the request.
Apple doesn't just sell one model of phone at a time. In 2014, Apple was selling the iPhone 6 / 6 Plus, the iPhone 5s, the iPhone 5c (an iPhone 5 with a cheaper, plastic back), and the iPhone 4s.
No, the iPhone 4s was discontinued in September of 2014 in the United States, and was still sold in some countries as late as 2016.
Who said anything about spoofing? Suppose an attacker manages to crack into one of the servers that provides a domain's DNS. That same server won't provide DNS for the domain that hosts the tech contact's email.
No, from a security perspective, checking only that you control the web server is much, much weaker than checking to see if you're the tech contact for the domain, and IMO, they should never have been allowed to cut that corner. The only reason they had to do that was that they made the decision to use 90-day certs under the bizarre assumption that servers are constantly getting compromised and their keys stolen, and that limiting the window in which stolen certs can be used is more important than preventing someone from creating a fake, valid cert for a domain that isn't getting constantly compromised.
Unfortunately, that decision led to weaker verification, and worse, the same flawed logic led to the clients rekeying every time they recert, thus preventing key pinning (another security technique intended to prevent attackers from being able to spoof domains). So all the problems that I have with LetsEncrypt from a security perspective stem from basically the same bad decision, give or take.
I think you mean "or". It means a longer conversion time or a more expensive ADC. If you want, you can build an ADC that is fully parallel, where it generates a complete value in a single clock cycle, or you can build one that is entirely done by successive approximation, where it computes one bit per clock cycle, or anything in between.
Even for 14 or 16 bits, they use multiple ADCs in parallel, fed by multiple amplifiers in parallel. The EOS-1D X (2012 version) uses a whopping 16 parallel channels to read out an 18.1 MP sensor, which means it does just under 14 million samples per second when shooting at 12 fps. In principle, there's no reason you couldn't use even more parallel ADCs if you have the die size to support it, though that does get crazy at some point.
The reason they don't even consistently do 16 bits is because the extra bit depth beyond about 14 bits per color channel doesn't really buy you much when balanced against the huge cost of storing half again more data per color channel, and half the photographers compress that straight down into 24-bit (8-bit-per-channel) JPEG anyway.
What's interesting is that TI hit 4 megasamples per second at 24-bit depth back in 2008, and the state of the art seems to have stopped improving since then. That tells me there's probably no market for it.
Wait... you actually use an email address at the domain as the contact email for the domain? Yikes.
Or do you mean that you can change the email on the domain? Because that may or may not be true, depending on whether you crack the account of the admin contact, the tech contact, or the billing contact.
That's not entirely true. Other CAs require the owner of the domain to confirm the validity of the request via email. The 90-day renewal period makes that approach more difficult, because nobody would be willing to go through that headache every 90 days. Instead, Let's Encrypt just checks to see if you've managed to convince the registrar or the DNS server to point the domain name at your server. So while they might not choose to do more validation even if there were longer validation periods, they would at least have the option of doing so.
One big reason for the volume of certificate issuance is that LetsEncrypt forces you to update your certificates at least once every 90 days. This means that the number of certificates issued is guaranteed to be at least 4x the number that would be issued by a traditional CA, and realistically, more like 12x or even 20x.
So yes, they should be criticized, but they should be criticized for the ridiculously short certificate expiration times that result in them issuing so many certificates each day, not for the number of certificates per se. That silly policy decision inherently limits the amount of verification that they can do, so even if they wanted to do more, they can't.
Not sure who modded this "troll", but the AC is quite correct.
Image sensors have a number of physical limits other than the ADC. It's easy to get a bigger ADC. Most image sensors only use 14–16 bits these days, whereas 24-bit ADCs are readily available. There's room for improving the dynamic range of the ADC portion of image sensors by more than two orders of magnitude (256x) with relative ease. Camera manufacturers haven't bothered to do so, however, largely because the primary limitations in image sensors are not the fault of the ADC. Rather, they're from things like the full well capacity of the capacitor that stores the analog value for the the pixel itself (which is largely determined by the die size) and the need to read out the pixels and shove the data into storage quickly (which means keeping the data rate and processing delays to a minimum).
Were it not for the latter limitation, we would just sample the sensor ten times as often and sum the values (as I, and no doubt others, have suggested for many years). And I still think that with some interesting on-die DSP, that would be possible, but it isn't feasible right now, as far as I can tell.
And in the audio world, at least in practice, 24-bit audio provides enough bit depth that we can leave the levels low enough to avoid digital clipping without losing precision. IMO, digital clipping hasn't been a major issue in the audio world for at least a decade, though I suppose this will help if you screw up and set the levels too high anyway. It's the gain staging leading up to the ADC that gives folks the biggest headaches these days, and that's caused by getting too close to one of the rail voltages for an amplifier at any point through the chain. And changes to the ADC won't help with that.
I'm sure there are situations where existing ADCs can't cope—perhaps in industrial applications—but audio and photography don't seem like good candidates to me.
This is an interesting approach, and it would work pretty well for things like audio. It might help with the dynamic range of cameras when used at higher ISO settings, but it will not solve the problem by any means. The problem, though, is that in modern cameras, the sensor's pixels also have a maximum capacity, called the full well capacity. The sensor can't physically accumulate more of a charge than its full well capacity, and the DAC is designed so that its clipping point matches the full well capacity of the sensor at its base ISO. So you would still get clipping when the brightness exceeds what would otherwise by the sensor's clipping point at its base ISO, and if it is already at its base ISO, this wouldn't make any difference at all.
IMO, a better approach (which I proposed several years ago) is to sample the sensor and physically cancel out (subtract) the measured charge in the sensor itself, doing this multiple times per exposure to ensure that you don't hit the full well capacity. That approach also has the advantage of letting you do really cool time-based manipulation of the resulting photo. For example, you could do vector-based motion compensation of the individual subframes to dramatically reduce motion blur, compensate for some amount of camera shake, etc.
Even better, if you represent subsequent subframes relative to the previous subframe (e.g. -12 here, +2 there), you'll also usually get a high percentage of zeroes, which means you should be able to losslessly compress the additional subframes to be pretty small on average, potentially giving you the ability to adjust the image motion compensation after the fact to get an image in which motion is blurred more or less, according to taste.
In theory, you could even do bizarre, per-region motion compensation, such as making a baseball appear to be motionless while the bat is swinging at a high speed or vice versa. :-D But I digress.
The sort of hypothetical, magical fast lane that you describe is effectively impossible, both from a business perspective and from a technical perspective. This is the sort of idea that could only be conceived of by someone who has no clue how massive the data going across Internet backbones is, and thus has no concept of how hard it would be to do any sort of prioritization of traffic on its way through those backbones. We don't limit our discussion of fast lanes to the final hop between ISPs and the backbone because we don't know any better. We limit our discussion to that because any attempt to extend a fast lane beyond that point is about as likely as bottling up unicorn farts and using them as fuel for rockets to Mars.
An autonomous vehicle seeking any data that would make sense to send via multicast will almost certainly receive it asynchronously in a broadcast fashion when the data changes, and it won't be over the Internet. It will be from satellite radio, terrestrial broadcast radio, or broadcast SMS (CB). Multicast would be utterly crazy to attempt, because it provides no real advantages over broadcast, and involves enormous technical complexity that has yet to be solved despite lots of very smart people spending about four decades trying.
That's perfectly fine. Paying for an Internet connection is not paid prioritization. Therefore, by continuing to revert to an example that doesn't involve paid prioritization, you have effectively proven that your hypothesis (that paid prioritization for self-driving cars might somehow be helpful) is unsupportable.
Okay, wise-a**. Between an autonomous vehicle and other, relatively distant autonomous vehicle, safety cone, road sensor, or other apparatus that is physically located on or near some road that is on a directed graph between the vehicle's current location and the vehicle's destination. Happy?
First, no, net neutrality laws do not prohibit a fast lane. They prohibit paid prioritization, which means granting a fast lane from an ISP's customers to a specific company in exchange for money from that company.
Second, I neither said nor implied that data only traverses the last mile.
So again, congratulations. You just proved a tautology that does nothing to counter anything that I or anyone else on this thread has said.
I am looking at the big picture. You're just wildly flailing and making crap up. Here's a quick tutorial in networking in only ten words: A network can never be faster than its slowest link. For the foreseeable future, the slowest link will be the cellular network. Now do you get why nobody even bothers talking about a "fast path" through the entire Internet? Yes, it's theoretically possible for traffic to get slightly delayed at any of the various hops along the way, but that invariably pales in comparison with the huge latency in the last few hops between the customer and the backbone, because that's where ISPs are cutting corners in capacity.
What is wrong with your reading comprehension? Saying that a car must be able to drive safely without relying on the Internet does not mean that an Internet connection cannot make a car safer. It is always possible to make something safer. Always. The fact that it is possible to make something safer DOES NOT MEAN IT IS NOT SAFE.
My indisputable facts are governed by the laws of physics. Unless, of course, you'd like to throw all science out the window, in which case, sure, you might be right, and I might have magically gained the ability to fly because of the sunburn I got last week.
The only way the things I talked about could possibly not happen would be if nobody ever tried to start any new video-on-demand companies or tried to innovate while doing so. Otherwise, the very existence of paid prioritization fundamentally puts those innovators at a disadvantage because of their size. My argument was not that "it's obvious". My argument was very detailed and thorough. If, after reading it, the correctness of my argument is not obvious to you, the problem is not with my argument, but with your knowledge and understanding of the subject.
You aren't making any sense. At all. Yes, data that a car obtains over the Internet comes from the Internet. Congratulations. You've just stated a tautolog that has no bearing on the original topic of discussion.
As I've said elsewhere, information is either personalized to the vehicle and its position or it isn't. For information that isn't personalized to the vehicle, there's no benefit of a polling model through a "fast path" over a broadcast model. For information that is personalized to the vehicle, it either is about something nearby or something far away. If it is about something near you, no matter what you do, the laws of physics won't allow you to get the latency down to the point where you can do that via the Internet. And if it is about something far away, timing is not critical. Ostensibly, there might be some slight areas on the fringe where it would occasionally have been better if a device got information slightly earlier, but in the grand scheme of things, this is lost in the statistical noise.
And even if it were detectable above the noise—a whole tenth of a percent—it still wouldn't make sense to use prioritization (paid or otherwise) to achieve it. The thing is, you can always make something better. There comes a point at which making things better is not worth the expense, and for all currently conceivable self-driving car tech, existing cellular networking is well beyond the point where making latency better is not worth the expense. For example, we could theoretically cause two or three extra cars to take a different route around the accident by reducing latency (assuming you don't just use a broadcast model, which makes far more sense than any low-latency polling model), but it wouldn't be worth making a million cars poll the servers four times as often just to save a few minutes for a couple of cars.
You're the only one implying that any of us ever said that. What we said was that:
The odds of the universe changing such that I become wrong on any one of those points before the heat death of the universe are only slightly higher than the odds of a self-driving car (not airplane) crashing into the window outside my boss's office (which is not on the ground floor). You're arguing about the possibility
Either way, you're arguing with someone who agrees with you....
Actually, I just thought of one very narrow example of something that qualifies: warnings about an approaching earthquake. Of course, there's no plausible situation in which that piece of information would need to be personalized to a specific vehicle, so it is more appropriately transmitted as a broadcast rather than using any sort of Internet-based communications.
So let me revise that very, very slightly: It isn't plausible for an autonomous car to need data that is tailored to that vehicle, time-critical, and comes from something that isn't physically nearby. Thus, every possible problem can be solved both more effectively, more efficiently, and more cheaply via some other mechanism besides a so-called "fast lane".
No, vehicles driven by a human are explicitly not autonomous. Autonomous in the context of vehicles means exactly one thing: capable of operating without a human in control. A vehicle with a human control is precisely the opposite of autonomous. You could maybe argue that the human is autonomous, but I'm pretty sure the Continental Congress declared that self-evident a couple hundred years ago. :-)
Huh? Of course it is doable without any Internet connection. In fact, that's precisely what I said in the text you quoted. A vehicle must be able to drive itself safely without external data (e.g. data obtained over the Internet, data obtained from other nearby vehicles, etc.). If it can't, then it is not a viable autonomous vehicle design.
Only in the relatively short term, before the robots learn to do the surgery themselves.
Besides, that won't require paid prioritization, because those customers will buy end-to-end dedicated fiber links with throughput guarantees. That data will never plausibly see the public Internet, because if it does, hackers will find a way to kill someone with it.
And even if they ran it over the public Internet (yikes!), it still wouldn't fall within the currently very narrow FCC ban on paid prioritization because the hospital's ISP would be charging money to the hospital that is its own customer, not to the hospital at the other end of the connection.
The problem is that the term "fast lane" is a gross misnomer here. It is an exceptionally imprecise description of what the law prohibits, and as a result, it sounds like exceptions would be useful when in fact, they would not. The law bans ISPs from charging money to companies that are not their customers in exchange for providing adequate data throughput between those companies and their customers. It does not ban ISPs from charging money to their own customers in exchange for getting sufficient data throughput.
FYI, a sizable percentage of VoIP-like traffic is over TCP these days, because UDP is too unreliable and suffers too badly from fragmentation, so being able to drop VoIP packets willy-nilly isn't really a safe assumption anymore.
Because car communications systems have IMEI numbers or equivalent indicating that they were built by a car company, and uses a different APN or whatever when providing data for tethering versus non-tethering. That's all pretty trivial.
??? That question doesn't make sense. The cell company isn't originating anything. It is providing service, with different speeds of service, depending on whether the traffic is originating from the autonomous vehicle portion of a car or not. The direction of data flow is immaterial; what matters is that the car's owner (or the car's manufacturer) is the ISP's customer, and thus purchases service appropriate to the vehicle's data needs.
It can't, because it isn't plausible for an autonomous car to need data that is simultaneously both time-critical and coming from something that isn't physically nearby (thus having to go over the cellular network). The importance of quickly finding out about a problem is inversely proportional to the distance between you and that problem. That said, your argument presupposed that such data would someday be needed, so I was starting from that rather implausible assumption for the purposes of argument.
We already know that some data that an autonomous vehicle can use to maybe make a trip slightly safer could conceivably come from the Internet—things like ice on roads, for example. But—and this is a big but:
Realistically, most road conditions are not sudden. They come on over a period of time. So usually you'll have O(hours) to find out about road conditions. Nobody is going to try to come up with some crazy system in which a server somehow continuously tracks a car by GPS to find out what cars might be near it quickly enough to do rapid messaging via a server, because it is computationally infeasible now, and by the time it is computationally feasible, the network bandwidth will be trivial; the odds of such a colossally expensive and complex scheme providing any real benefit right now are so small that you couldn't possibly justify the cost, and by the time you could justify the cost, networks will be fast enough that paid prioritization would be unnecessary.
The notion of autonomous vehicles benefitting from any significant prioritization really is quite absurd, much less paid prioritization, which as I have said elsewhere, by its very definition can only benefit one car manufacturer over another, and cannot actually benefit consumers.
It is a fast lane for a specific company, on the Internet, for data relevant to AVs. It's that boldfaced part that you seem to be deliberately ignoring here.
It's not the only important thing. And that's why paid prioritization is useless except as a workaround for a specific ISP providing inadequate throughput to the backbone. The ISP can't guarantee faster throughput to the destination. All it can do is guarantee faster throughput to the backbone for traffic being sent towards a particular destination, which is what paid prioritization is all about.
Yes, and that shouldn't be allowed. What should be allowed is for company B to ask the ISPs to prioritize traffic from all companies to autonomous vehicles without charging money to the autonomous vehicle company.
The usual approach would be for the prioritization to be based on the fact that it is coming from an autonomous vehicle. Prioritization based on source is not and has never been a net neutrality issue. If it were, it would be illegal to charge higher fees for faster Internet service. That's prioritization based on source. Net neutrality just bans ISPs from charging money to companies that are not their customers for better access to their customers.
Thus, the entire concept of paid prioritization would likely be inherently nonsensical in the context of autonomous cars, because the car company would almost certainly pay for permanent network access for their cars as they do now (and thus would be that ISP's customer) and thus would have the right to pay for whatever class or speed of service suited those vehicles.
But even supposing that the individual customers paid for service, there would still be nothing preventing the car companies from creating innovative features that require fast connections, because the customers would have the option of choosing whether or not to pay for that faster class of service to enable such innovative features.
Either way, it would not require paid prioritization, according to the legal (FCC) definition thereof.
By any meaningful definition, traffic data is not real-time. It is not a continuous stream of data from radar stations directly to you. Traffic data is only periodically updated, and is delayed significantly as it propagates from system to system and is accumulated, averaged over time, etc., so the traffic data you're seeing is likely minutes old. A single car obtaining traffic data in anything approaching real time would likely bring the cellular network utterly to its knees, much less millions of them. And more importantly, high-speed delivery doesn't usually matter, because the average speed of traffic on a section of road doesn't change very quickly (even when there's an accident, typically, unless a semi flips and blocks all lanes). It takes minutes for a wreck to bring a multi-lane road to a standstill.
No kidding. This is why autonomous vehicles have cameras, LIDAR, and orders of magnitude faster response time than any human. That doesn't require fast cellular networking. It doesn't even benefit from it.
In what country? At least in the United States, as a rule, you are not required to stop for an accident, though I suppose there might be some state that requires doctors/nurses/medical professionals to do so, possibly as part of medical licensure laws. In some states, you're required to render aid if you do stop, but nothing requires you to stop.
If a vehicle cannot make reasonable decisions without external data, then that means it cannot safely drive unless another vehicle has recently driven the road to provide that data. Such a vehicle might pedantically be described as autonomous, but it is not usefully so.
Getting traffic data slightly sooner is not, in practice, useful, as I already pointed out. And all data that a car could usefully take advantage of falls into one of two categories: things that are happening nearby and that must be reported immediately and things that are not happening nearby and that can wait a long time. The former should absolutely never be sent via cellular data, because A. determining what vehicles are nearby cannot realistically be done over a cellular network reliably enough and quickly enough to not be a huge burden on the network for no good reason, B. even in the best case, it would be way too slow to be practical, and C. such an approach would not work at all if you were outside cellular territory, which means you would necessarily want to provide a local radio fallback anyway, thus making the cellular path only practically useful for the latter—for data that is non-urgent. This will always be the case, necessarily, because the laws of physics don't change.
We have autonomous vehicles out there on the roads today, and exactly none of them benefit from prioritization, much less paid prioritization. They barely even use the cellular network. If all those engineers from multiple different companies all have concluded that there's no need for a fast data lane for autonomous vehicles, then it's pretty safe to say that there isn't.
And besides, that is still completely irrelevant, because no data benefits from paid prioritization, which is not about prioritizing based on the type of data at all, but rather based on what company's servers are on the other end. The only "benefit" that can ever come from paid prioritization, by definition, is one company getting priority for their traffic over that of another company's traffic of a similar kind, e.g. Ford getting traffic data to their cars faster than Chevy. There cannot possibly be a benefit to consumers from that, period.
No, this is not what net neutrality means. That's a straw man put forward by minions of major ISPs to give them something to attack. It is almost universally agreed upon by everyone that basic QoS should be allowed under net neutrality—that traffic requiring low jitter/latency should get slight temporal priority over traffic that does not, within reason.
And QoS is explicitly exempt from the paid prioritization ban that Comcast is claiming will someh