Why should it be Google's problem if people are superficial?
Basically an loading tool with a bug I knew from testing, you could set it correctly once in production but if you set it twice every user was f*cked up and could only be fixed from the web interface by about 5 clicks per user, no programmatic solution. And of course we had an error in the production setup, I altered that part - which I could - but forgot to take out the "you can run this only once" settings. Hundreds of users borked and the vendor support would take forever or claim there's no other way, what do?
This was a consulting company, trying to bill this would look bad on both our vendor and ourselves and it pretty much broke everything so we gave a benched consultant the assignment from hell. Click here, here, browse, pick, save in this somewhat less than instant web interface. Now do that all day, every day for all users until you're done. Personally I'd be ready to jump off the roof after an hour, but apparently she stuck to it for three days and finished. I don't think we won any popularity points with her though.
Or pulling the network cable. You have to plan for idiots, because there will be idiots. And odds are, they will outrank you.
Since this was a server unless he was at the console copying it off to a USB stick he'd probably hook the server back up to the network so he could copy it to his client.
The problem is that the overall experience is more of a PITA than just shoving fuel in the tank. Obviously this assumes you ignore externalities, but that's the norm so it's a safe assumption. Once more of these issues are ironed out then there will be less anxiety and more purchases.
He's got so many problems in that video that it's probably staged for click bait, so it can be linked to by EV opponents. Like the cable, that's staged. Every charger map has a filter and you only need to set it right once. I don't know anyone else who hasn't been able to pay for power, usually they have all the ordinary credit/debit/cell phone payment options in addition to the EV-specific cards. With broken chargers and drive problems, well that's bad luck on top of everything else. Not to mention he's trying for something the car's not planned for at all.
First of all, it has a 74 mile range and he's planning a 350 mile drive. The last 20% is really slow, so in practice the fill-ups will be 60 miles max so he'll need at least five full recharges even assuming they're perfectly spaced and he'll run close to zero range. If you want a 5 mile margin and estimating that the chargers are 5 miles from where you'd like them to be 50 miles is more realistic. That's six 80% recharges in a day, at least half an hour each so three hours total. Any sane person would say let's not do that, just rent a Tesla/ICE or take the plane or whatever.
He's abusing the range extender to carry on, but I like the basic idea that if there's a screw-up you can solve it with a little gas instead of being stranded or stuck on a slow charger. Like big boats also have small rescue boats, you know in case of emergency. Hopefully more EVs will come with that option.
Then you lack a moral compass and need t get some help. I'm suggesting that when you know the fucker is guilty, you put his ass in jail, not defend him.
If your defense lawyer won't offer competent counsel it won't ever be a fair trial. Everybody speculates, even defense lawyers. The prosecutor, the judge, the jury members, the journalists, everyone on the peanut gallery got a personal opinion. You can pick one from the lynch mob as judge, jury and executioner and you got the court of personal opinion instead of the court of public opinion, it's still a shitty system.
That's why we have a system built on evidence. The prosecutor lays out the evidence in favor, the defense lawyer the evidence against, the judge is the referee and the jury decides if it's proven beyond a reasonable doubt. Now certainly there's a lot of subjective evaluation on what testimony is credible, evidence is reliable, theories are plausible and so on.
It's not supposed to be gut feel speculation based on superficial appearance and behavior, maybe you get an impression he's creepy and sleazy "hood rat" but that doesn't make him more guilty.than a slick smooth talker in a suit. At least it's not supposed to, but that's what personal opinion often is - how well the person in front of us matches the mental image we have of "that kind" of person.
If people care enough about it to allow it to affect how they judge the man today, then it still has at least some historical significance... if for no other reason than to give the people that this man meets the tools with which to know what the truth is. In the end, if he has genuinely repented, then it will still be up to each and every person he meets to evaluate the man for how he presents himself today, and it is THEIR problem, not Google's if they might still judge him harshly for it.
Compared to DirectX, OpenGL is a terribad API to work with.
If you are using an engine such as Unreal or Unity with multiple back ends, then OpenGL becomes somewhat feasible. Otherwise developers are better off choosing DirectX and going Windows only, targeting 95% of the gaming PC market.
Oh goody. So it's no different than any other monadic polymorphized differential functor system utilizing monoidal categories and parameterized applicative type expressions.
Whew. Lucky me. I was worried about finding something to do over the holiday weekend.
. If purchased outright, the ballasts would have paid for themselves in just a couple of years so it was a really sweet deal for the leasing company.
Unless the company goes out of business before the lease is up.
Both of you are wrong and so is Dustin Kirkland (whoever he is). The core of your error is in this statement:
Only secrets can be used as token for authentication.
That sentence is true, as stated, but only because it includes the word "token". Yes if you're using secret tokens for authentication, then the tokens must be secret. But exchanging secrets (or proof of possession of secrets, which is what most cryptographic authentication protocols do) is not the only way to do authentication. Not by a long shot. In fact, humans hardly ever use secrets for authentication.
How do you identify and authenticate your mom? Do you ask her for a secret password? Of course not. You use the same tools for both identifying and authenticating her, and those tools are a set of biometric markers. The same set of tools are also used in high security situations. Back when I was a security guard in the Air Force, I was trained that personal recognition is the very best form of authentication. Not only is it not necessary to check the badge of an individual you know personally, badge-checking is inferior to personal recognition for authentication (note that badge-checking may still be important for authorization, verifying that the person who has been identified and authenticated actually has permission to enter. Thus I was trained to always check the access control list before allowing someone near nuclear weapons).
With respect to user authentication in electronic contexts we generally use secrets because computers don't (or at least haven't) had the ability to use the sorts of biometric authentication that humans use quite effectively. But, when we equip them with biometric sensors, they can.
HOWEVER, this does not mean that biometrics are useful for authentication in all circumstances.
Secret-based authentication has the advantage that -- assuming the secret has sufficient entropy and can be assumed not to have leaked nor been intercepted and cannot be rerouted (note that that's a pretty long list of criteria, some of which are hard to establish) -- you don't have to worry about the possibility that the authentication could be spoofed. An attacker who doesn't know the secret can't fake knowing the secret.
Biometrics, though, are not secrets. They are public knowledge. This means that an attacker must be expected to have access to copies of our fingerprints or faces. The biometric authentication process is different, though. It does not rely on secrecy of the authenticator, but instead on non-replayability. If we can be certain that (for example) the fingerprint placed on the scanner belongs to the person we wish to authenticate, and that the stored template we match against belongs to the person we wish to authenticate, then we can perform a good authentication. The fact that the fingerprint is not secret does not matter.
Where biometrics fail is if (a) we can't be certain that the livescan data acquired from the sensor belongs to the person trying to authenticate or (b) the stored template belongs to the person we wish to authenticate. Part (a) is particularly difficult to validate in many contexts because faking the input isn't necessarily hard to do, and in some cases an attacker can even bypass the sensor entirely and simply inject a digital copy.
This doesn't mean biometrics are worthless, it just means they're only useful in certain contexts. And, again, their utility for authentication has nothing to do with their secrecy. And rotation is likewise irrelevant and silly to discuss. You need to rotate secrets because you can't be certain they have stayed secret and because if they have low-ish entropy they may have been brute forced. None of that applies to biometrics because they're not secrets and their utility as authenticators does not depend on secrecy.
Can we please kill this incorrect meme about biometrics as identifiers, not authenticators? They can be either, or both, and are used as both, by billions of people, every day, with high effectiveness and reliability. Whether or not they provide security depends on the context.
With respect to credit card payments, fingerprint and facial recognition biometrics are pretty reasonable tools. This is especially true if the sensors are provided by the retailer, and the consumer is providing a traditional electronic authentication (cryptographic challenge-response) with their smartphone or smart card. It's not quite as good if the smartphone is also providing the fingerprint scanner and camera, because in the event of an attempted fraudulent transaction that means the attacker is in control of those components.
But you also have to consider the model that is being replaced. Is fingerprint plus face recognition better than a signature which is theoretically matched by a non-expert human, but in practice never checked at all? Absolutely. Is it better than a four-digit PIN? That's debatable, but it's at least in the same ballpark.
I tried Inbox, but wasn't impressed. It strips so much of gmail away that it is basically "Gmail for beginners". You want filters, labels, etc, then it is worthless.
Actually, Inbox is Gmail for power users, for people who have massive volumes of e-mail to manage. It takes a little bit of work to figure it out and set it up, but once you have, it's awesome. There are some features it lacks, like complex filters (simple filters are very easy to set up; you just move a message to a label and Inbox asks if you want to always do that. Click "yes" and you have a new filter rule), vacation auto-responder and the like, but you can always use the Gmail UI when you need to set stuff like that up.
The Inbox features that that make it great for heavy e-mail users are:
Many people use their e-mail inbox at least partially as a task list, especially their work e-mail. This results in having to keep e-mails that for you can't work on yet sitting in your inbox, cluttering it up and making it harder to process new e-mail. When you snooze an e-mail, it goes away until some point in the future. You can pick a date and time, or even a location (requires using the Inbox app on your mobile device). Heavy application of snooze with well-chosen times/locations lets you clear all of the stuff you can't do yet out of the way, knowing it will come back later when you can handle it.
Bundles are just Gmail labels, but with an additional setting that tells Inbox to group them in the inbox. This is fantastic for high-volume mailing lists. With Gmail you can get almost the same effect by setting a filter to apply a label and skip the inbox, but then you have to remember to actually go look at the label from time to time. With bundles, you get the same grouping effect but the bundles show up in your inbox so you don't forget to go look. The reason that grouping (by whichever mechanism) is useful is because when you have large volumes of email, most of which you don't actually need to read, it's much faster to scan through a list of subject lines and evaluate what's important and what isn't when you already know the context.
My process for plowing through a busy mailing list is to scan the subject lines and click/tap the "pin" icon on the few that are interesting, then "sweep" the rest. A single click or gesture archives all unpinned items in a bundle. Then I handle (or snooze until I can handle) the pinned items.
I also have a bundle (label) called "Me" that is applied by a filter that looks for my name or username in the To line or the body of the message. This helps me to be sure that I notice e-mails where people are mentioning me or asking me questions. It's the first bundle I look for every time I check my e-mail. Similarly, I have a bundle that extracts e-mails that reference my project's name. That's the second bundle I look at. Other high priority bundles are e-mails from the code review system and e-mails from the bug tracker.
Obviously there are many e-mails that mention both my project and me. That's fine; bundles are labels not folders, and it's perfectly reasonable for an e-mail to be in more than one of them. When I archive a message in one bundle, it disappears from the others. So, often I'll look at Inbox and see the "Me", project, code review and bug tracker bundles displayed, but by the time I've processed everything in the "Me" bundle, the other three have disappeared.
I think this vies with snooze as the killer feature of Inbox. By default, a bundle appears in the inbox whenever you receive new mail with that label. But there's lots of stuff, at least in my inbox, that I don't need to see immediately. Having low-priority stuff displayed instantly distracts me from my work, or obscures truly urgent e-mail. Also, it's more efficient to handle low-priority e-mail in bulk. So, you can specify that a bundle should only appear once per day, or once per week. Inbox will accumulate e-mail in delayed bundles and only show the bundle at the specified time.
When I start work in the morning I have a dozen or so bundles containing low-priority e-mail. I can quickly scan each of them, pinning the items I care about and sweeping the rest. I have a few bundles for purely informational mailing lists which are set to display once per week, so I only see them on Monday morning.
I'd like a little more granularity on this feature. Specifically, I'd really like to be able to set some bundles to show, say, every three hours. Then I'd only allow the highest-priority bundles to show immediately, giving me larger blocks of uninterrupted time but with the knowledge that I'll still get notified of truly urgent stuff immediately.
It took me a while to realize just how valuable this is, but it's really great that the mobile and web UIs for Inbox are virtually identical. I don't have to have two different flows for handling e-mail on mobile vs desktop. The mobile UI is a tiny bit better because of the gestures a touchscreen interface can provide, but my process for using it is the same.
One common complaint about Inbox vs Gmail is that Gmail's more compact; you can fit a lot more stuff on the screen with the Gmail UI. I find that isn't a problem, because the Inbox workflow mostly eliminates the need to scan through a big list of messages visually, looking for something in particular. The need to do that arises mostly (for me, anyway) when I'm keeping a lot of stuff hanging around in my inbox. With Inbox, I don't do that. I snooze it or I archive it, so my inbox is empty nearly all the time. If I need to find something that I've snoozed or archived, I search for it.
Bottom line: If you're a heavy user of Gmail, you should really take a good look at Inbox. Odds are you'll never go back.
n one sense of the term secrecy is in itself a hostile action...
Care to tell me what hostile act wearing clothes in public constitutes? Clothes, after all, cover up your body... keep it hidden from view. That's secrecy.
Wanting to keep something private isn't a hostile act... wanting to know something that somebody was trying to keep private can be, however.
Your line of reasoning parrots those who would say that if you've done nothing wrong, you have nothing to hide...
Except that almost everyone *DOES* have something to hide. Not because they've done anything wrong, but because they have things that are private or personal.
Again, I stress that *EVEN IF* absolutely everything was working exactly as such a government intended...
This is because laws don't actually *stop* people from breaking them, they only ensure that something that is considered appropriate punishment will follow when people do. Unfortunately, such punishment cannot always negate the effects of the harm that was done while someone broke the law in the first place.
And again, this is even *IF* their system for eavesdropping on encrypted communications was function as best as they can possibly intend.
So hey, Mr. Cameron.... I can sincerly appreciate that you might have the very best of intentions, but your goals will deprive entirely innocent people of the ability to even have the most rudimentary protections from people that will use the same abilities that the government has, however illegally, to cause very harm to people who have done nothing wrong except to follow a law that says they are not allowed to take precautions against such means.
Furthermore, even if they would manage to return the blocks to the pool in a couple of years, it would both be too late and too little and the demand for address space far outpaces the supply that ipv4 can offer.
This. We got 7 billion people - probably closer to 10 before it peaks, and as a minimum I should have one IP address at home, at work and for my cell phone. So 3*10 billion is 30 billion, IPv4 can offer 4 billion. And that's not counting every other odd thing I might want, like remote-controlled alarm/heating/whatever at my cabin or my car, servers of various kind and maybe IoT will become good for something.
Of course they probably could have just done it much, much simpler by making a dotted quad a dotted quint:
For compatibility each host under 184.108.40.206.x is granted 256 ports IPv4 ports mapped from x*256 to (x+1)*256-1 to a designated "IPv4 compatibility ports" like say the last ports from 65279 to 65535. So 220.127.116.11.1 can either be fully addressed by quint-capable equipment or 18.104.22.168:256-511 that'll be mapped to 22.214.171.124.1:65279-65535. And 126.96.36.199.2 will have 188.8.131.52:512-767 mapped to 184.108.40.206.2:65279-65535 and so on. You could use the same technique to provide a virtual IPv4 interface for legacy software, it thinks it is listening to 220.127.116.11:256 but it's really listening at 18.104.22.168.1:65279 - and any application it tells to connect to 22.214.171.124:256 would work.
That would have led to a gradual 256-times expansion of the address space without any hard switch-offs. But instead they decided to solve everything and now 19 years after the IPv6 standard we're still only barely in motion.
If the robot must be moving (typically, when you're teaching the robot the path it should follow), then every single person in the workcell must have an active deadman switch (anyone lets go, the robot emergency-stops). And you run the program at 10% speed so that you have time to trip the deadman or get out of the way. The workcell itself is fenced off, usually with either a tripwire or electric-eye switch that will e-stop the robot if triggered.
I used to work for a robot company, and we enforced these rules religiously. When I went to visit plants and work on the robots, they issued me my own padlock and tags for lockout/tagout. Someone had to have skipped some safety procedures in this case.
Indeed, in most places, a bug where the system crashes is the most severe possible bug. When dealing with robots, that's only the second most severe. The most severe were "unexpected motion" bugs, where the robot didn't follow the path in the correct way or otherwise didn't behave predictably. Those got everybody's attention.