Sounds like you're the deluded one. Removing the need for hardware by using software is novel and unique, Qualcomm didn't do it, and thus Qualcomm shouldn't have had any fucking win related to that.
You can't generally work around a patent by implementing the patented functionality in software rather than hardware, or vice versa.
It was completely fine for Apple to implement the functionality in software (or hardware, whatever), as long as they paid the appropriate royalties to the patent holder. Or, alternatively, Apple could have found a different approach to solve the problem that didn't infringe on the patent. Having failed to do both, Qualcomm will be awarded whatever remedies the court deems appropriate.
I don't think there's any risk that Gmail will drop support for mail filtering rules that forward email. Or for POP3 or IMAP4, if you want to use those mechanisms.
Duh. You're the only one I see here claiming there is.
The claim is just that some bullets are a little safer that others, which is absolutely true.
Good, secure, reliable and maintainable code is only produced by good, experienced and talented coders.
So you're saying there is a silver bullet: Good, experienced and talented coders. Except, you know what? That bullet is also silver-plated at best. Electroplated, even. Good, experienced and talented coders also write insecure code. They write less of it, certainly, but they're not perfect.
You know what works the best? A layered strategy:
1. Top-notch programmers
2. A security-focused development culture
3. A focus on architectural defense in depth, so one vulnerability by itself isn't enough.
4. A focus on security by design.
5. Good secure implementation choices -- which includes picking languages and tools that make insecure implementation harder.
6. Thorough design reviews, by other top-notch programmers
7. Thorough code reviews, by other top-notch programmers
8. Third-party security testing, however accomplished (contracting with security firms, open source + bug bounties, etc.)
9. Fast patching of identified vulnerabilities (because even after doing all of the above, you're still going to have vulnerabilities).
There is no silver bullet, true. Which is why all of the above are required -- and they still aren't really enough. Hiring rare, expensive programmers is not sufficient. And it's not actually necessary (though it's crucial to have access to at least some of them), and that's good because rare, expensive programmers are not scalable.
You're trying to substitute a different premise to tilt the argument in your favor. That sort of underhanded argumentation is obnoxious and you should avoid such assholery if you want to be taken seriously.
This false belief is at the root of the current mess, were more and more effort is poured into languages with no real effect
Except there has been a real effect. Modern, typesafe, bounds-checked programming languages and well-designed libraries cause demonstrably fewer security vulnerabilities to be written, and the vulnerabilities to be less severe. This is because these languages inherently make whole classes of vulnerabilities impossible. Comparing, say, Java and C, there is no vulnerability you could write in Java that you can't write in C, but there are large classes of vulnerabilities -- including the most critical remote code execution vulns -- that you cannot write in Java. This comes at a cost... there are also classes of programs you cannot write in Java but can write in C, and Java programs tend to be much larger and consume much more memory.
This means that while Java programmers still have to think about security, there are many kinds of potential security mistakes that they do not have to think about. This is positive progress.
I do crypto, and bad crypto APIs (like those provided by Java) are huge source of vulnerabilities. Better, simpler APIs like Tink or libsodium make a big difference, and programmers write far better code when they use them. This doesn't eliminate the need for programmers to understand cryptography, but it does eliminate the need for them to be crypto experts. Perhaps the best thing ever to happen in this space is TLS. There are still plenty of things to screw up, but if you need private, authenticated network connections, there is almost never a better answer than "Use TLS, and follow these rules to configure it correctly", except, maybe "Use TLS and use <library> to configure it" (e.g. Use OkHttp on Android).
Or are you seriously going to try to tell me that a Good Programmer should be able to design and implement secure crypto code from scratch, and that if they'll just think they'll do fine? If you believe this, please, please, never write any code that implements or uses any form of cryptography.
In what language does writing "x = y" when you meant "y = x" not lose the value of x, which you intended to keep?
Everything *MUST* *BE* unit-tested for type-correctness
While I prefer static typechecking, I respect the Python view that everything must be tested for correctness anyway, and that static typechecking just lulls the programmer into thinking that less testing needs to be done than is really the case.
I will say that the worst, most opaque code I have ever encountered was written in Python, but I blame the programmer who wrote it, not the language for making it possible. Bizarre, incomprehensible, even misleading code is possible in any language, only the techniques differ.
(The code I mention created a set of pure interfaces, then instantiated them and called their methods... and they worked! There was machinery that intercepted the instantiations and chose appropriate concrete types. Essentially it was a particularly opaque dependency injection framework. Think Guice, if you're familiar with that, but with absolutely nothing in the code to indicate that dependency injection was happening.)
However, part of it is modern coding in general. The last several "Agile" places I worked at were in permanent sprints, and the job of the developers is to get a feature that marketing already sold to the customer into the product.
Nothing about that situation is related to "modern coding" or "Agile"... that's just bad project management and bad business. It was extremely common when I first started doing software in the late 80s.
Is wire fraud? I guess that means they will arrest time warner representitives for sending me false statements. Or are there two sets of laws? One for me and one for big soulless tax evading corporations.
I think knowingly (this is what gets Time Warner off the hook; they claim error, not intentional fraud) sending false bills might be mail fraud. I suspect the wire fraud is for actions relating to accepting the payment -- e.g. setting up accounts in false names, etc.
As far i know, sending unsolicited bills for unsolicited services to businesses is totally legal, at least in my part of the world.
Unsolicited bills for unsolicited services that you actually provide, sure. I'm pretty sure that mailing bills for services you didn't provide constitutes mail fraud.
Exchanges are the dirty little secret that makes Bitcoin's (and every cryptocurrency's) model "work".
Bitcoin, yes. Most, perhaps even all, other extant cryptocurrencies as well. But I'd be careful not to exclude the possibility that it's possible to design a cryptocurrency that actually does scale, and could therefore achieve liquidity without exchanges.
Would you care to share the name of the company that you work for and which jobs that you have that you cannot fill with American talent?
Google (er, Alphabet). Software engineers.
And to be clear, it's not that there isn't any American talent, it's that there isn't enough. Google hires at a voracious pace, hundreds per week, about half of them SWEs. And not because of turnover, because of growth. To sustain that rate, and maintain a high bar for talent, Google's recruiters have to find 50K-100K new prospects every week. You can't do that if you restrict yourself to 1/26th of the world's population.
And I don't think the problem is the Bay Area. There are lots of Google engineering sites around the country, and all of them struggle to hire enough SWEs to keep up with demand. Google teams are perpetually understaffed. The Bay Area sites do struggle a little more, but not much more.
That's the sad song I hear over and over but it's pure lies. I've worked with hiring groups that had listings for speciality tech workers in small US towns in states no one wants to live.
My employer has engineering offices in ~40 US cities, including a dozen or so major metropolitan areas.
Sigh,/. is dead. It's like none of the posters even looked at the code.
For anyone who's interested, the encryption used here is very poor. He leaves the mode and padding unspecified for both the asymmetric (RSA) and symmetric (AES) encryption operations. That causes the provider defaults to be used. In the case of the RSA step that's not terrible, since every provider I'm aware of uses PKCS#1 v1.5 padding. This isn't great, since PKCS#1 v1.5 is vulnerable to an adaptive chosen ciphertext attack, but in this usage that doesn't really matter.
The bigger problem is that AES typically defaults to ECB mode. Using ECB means that any repeated 16-byte blocks of plaintext will encrypt to identical 16-byte blocks of ciphertext. This can often expose enough structure to allow the file contents to be partially recovered. It's particularly bad in this case since the same key is used to encrypt all of the files. If AES were in any way vulnerable to brute force, this would almost certainly provide many "cribs" (known plaintext/ciphertext pairs) which could be used to discover the key and decrypt everything else. AES-256 is not, however, vulnerable to brute force, and won't be until computers are made of something other than matter and occupy something other than space (anyone catch the reference?).
Overall, I suppose the chosen encryption was adequate to the task, but it was very sloppy.
Do you think he'd accept a pull request to fix it up?
The minimum required changes are small. I'd use "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" for the RSA operation, just because, and "AES/GCM/NoPadding" for the AES op. It would also be necessary to get the IV (let the provider generate it) and prepend it to each encrypted file. The files would be 28 bytes larger (12 for IV, 16 for tag), but secure.
Also, I'd process files in chunks rather than reading a whole file into memory and then encrypting and writing it back out. It could then handle files of any size. His code just skips any files larger than 20 MB. That's actually the biggest flaw in the implementation; given file sizes today, lots of stuff would just be skipped. All of my RAW photos would be safe, for example. The JPEGs would get encrypted, but who cares about them?
Oh, one more problem: Most systems these days don't overwrite in place, so the plaintext file will be left on the drive, available for recovery. Granted that recovery is not trivial, but still, the data will be there. Fixing this would require doing something like filling the drive with garbage files, forcing the drive to overwrite all free blocks. Overwriting multiple times might be a good idea, too, though that's probably not necessary. Some systems offer free space shredding as a feature; on those that could be used to ensure destruction of the plaintext.
Not from where I'm sitting. We hire all the Americans we can find, but we just can't find enough who can meet our requirements. We pay very well, have great benefits, etc. Doesn't matter. It's not a problem of finding people willing to work, it's a problem of finding people who can do the job. The only way to get enough good people is to hire globally. If that means more teams have to be based outside of the US, so be it.
If the process continues for long enough that our teams are primarily based outside of the US, then that will mean that Americans who want those jobs will have to move out of the country to get them. Assuming the other countries don't decide to reciprocate on the visa policies... if they do, then the Americans will just be SOL.
There are body shops that hire H1-Bs because they can get them cheap, but there are also plenty of companies who don't. Google, for example, pays all of its technical staff well, where they're from doesn't matter. But the H1-B crunch it's forcing a lot more international hires to be located outside of the US, where in the past they'd be brought in. I know a few who are in the US now on H1-Bs and are going to have to move because they can't get their visas renewed. These are people making $250K to $500K per year, so money clearly isn't the issue. So, Google will pay to relocate them, pay to fly them to the US regularly for team meetings and continue paying them well in their new location.
Really, if you want to fix the H1-B "problem", just set a minimum salary requirement (including bonus, equity, etc.) of $150K.
Old movies...Who's had a tire 'blow out' in there lifetime?
I did, about two years ago. A nearly new, high-end Michelin tire. Sidewall burst. It still happens, though it is a lot less common.
Remember 'sawing on' the steering wheel to take-up linkage slack?
Or you're middle-aged and your parents had old cars when you learned to drive. I'm 50 and when I learned to drive in 1985 it was on vehicles built in the early 70s. Both the car and the truck had that loose linkage, though the truck ('71 F150 IIRC) was a lot worse. I was amazed at how awesome the steering was when I drove my friend's 86 Celica. So tight!
They don't let us blind people fly, but I do believe that the sequence is aviate, navigate, communicate. I don't think you are supposed to diagnose until you are in controlled flight. But that's problematic if you can't stick and rudder fly so you'll never get to diagnosis.
Well, if something is going wrong with the plane, you will often need to diagnose so you know how to aviate, i.e. what you have to compensate for.
But with an active map of all super chargers within range, with how many bays are free/occupied shown, I usually dont follow the optimized route Tesla has planned. I prefer relaxed driving, and taking breaks.
Heh. In the mountain west the superchargers aren't dense enough to make this an option most of the time. In most cases, the road networks aren't dense enough to make this an option... usually there are only one or two reasonable routes between point A and point B, and often only one of them has superchargers. For example, from my home in Morgan, UT to Las Vegas, Google Maps proposes two routes: one that's 6:23 and 464 miles down I-15 and one that's 7:49 hours and 525 miles taking I-80 out to Wendover, then down through Ely. But, not only is that second route longer, there are no superchargers on the 363-mile segment between Wendover and Vegas. You could probably make it in a P100 if you drive carefully, but Tesla won't tell you to try it.
Charged again there before going over the mountains, while having dinner. Because, I know all the energy spent climbing will be recovered while descending. But missus would be disconcerted by the battery meter readings along the way. So plugged in, to avoid anxiety.
You should pop up the energy display in trip mode, so it shows the expected SoC over the trip, including the end. Do that regularly and the missus will get comfortable with the idea that the car is really good at predicting how much energy it takes to drive the planned route (because the car is, in fact, really good at it!).
When they did win the vote, no one really knew how to proceed from there, so they mostly just choose a path of maximum conflict to avoid having to make the hard decisions.
OT, but I think this is the story of Trump's presidency as well.
Nobody who is innocent has an alibi ready to go. Real people in the real world don't have documentation putting them elsewhere most of the time because they don't expect to need it. People who have that documentation ready to go, especially for a large number of incidents, made sure they'd have it to prove their innocence which means they aren't innocent at all.
I could easily produce lots of data to support alibis that I didn't previously know I needed, because I log lots of my life. Google Maps tracks my phone's location all the time, and it's basically never further from me than the next room. I use a sleep tracker, and that data is logged to Fitbit. What I eat is also logged to Fitbit, with timestamps. Same for my workouts. My meditation sessions are logged by Headspace. My work is logged in EMACS org mode, down to a resolution of a few minutes... and much of that can be corroborated with git commit timestamps, Google Docs version history, Web history, email and chat logs (I archive everything; delete nothing). A large percentage of my time is scheduled in Google Calendar... including a lot of info about who I'm supposed to meet, so after the fact it would be easy to dig up witnesses to corroborate those meetings. If I find out quickly enough about the need for an alibi, my home surveillance video camera history may have data to help.
That's just off the top of my head; I'm sure if I had reason to put some thought into it, I could find a lot more digital breadcrumbs from which I could gather data to alibi myself. And non-digital ones as well. Receipts, for example.
Having a lot of digital history to draw on just means that you're okay with being tracked, and perhaps even aid it. It's possible that's foolish, but it in no way implies you're a criminal.
If you’re specifically targeted as an individual, you could reasonably argue it probably doesn’t help much.
Even if you're not targeted specifically, but just a target of opportunity.
But at a minimum you’re increasing the complexity of what is necessary for someone to own your machine - and it’s basically painless so why not take that extra step?
No argument there, though I still maintain that protecting the machine is close to irrelevant. What matters is the data on the machine.
Slashdot Mirror
Sounds like you're the deluded one. Removing the need for hardware by using software is novel and unique, Qualcomm didn't do it, and thus Qualcomm shouldn't have had any fucking win related to that.
You can't generally work around a patent by implementing the patented functionality in software rather than hardware, or vice versa.
It was completely fine for Apple to implement the functionality in software (or hardware, whatever), as long as they paid the appropriate royalties to the patent holder. Or, alternatively, Apple could have found a different approach to solve the problem that didn't infringe on the patent. Having failed to do both, Qualcomm will be awarded whatever remedies the court deems appropriate.
With all the asshattery going on, I wouldn't be surprised if it becomes mainstream in the near future, warts and all.
Really, you wouldn't be surprised? I'd be shocked.
I don't think there's any risk that Gmail will drop support for mail filtering rules that forward email. Or for POP3 or IMAP4, if you want to use those mechanisms.
There is no silver bullet
Duh. You're the only one I see here claiming there is.
The claim is just that some bullets are a little safer that others, which is absolutely true.
Good, secure, reliable and maintainable code is only produced by good, experienced and talented coders.
So you're saying there is a silver bullet: Good, experienced and talented coders. Except, you know what? That bullet is also silver-plated at best. Electroplated, even. Good, experienced and talented coders also write insecure code. They write less of it, certainly, but they're not perfect.
You know what works the best? A layered strategy:
1. Top-notch programmers
2. A security-focused development culture
3. A focus on architectural defense in depth, so one vulnerability by itself isn't enough.
4. A focus on security by design.
5. Good secure implementation choices -- which includes picking languages and tools that make insecure implementation harder.
6. Thorough design reviews, by other top-notch programmers
7. Thorough code reviews, by other top-notch programmers
8. Third-party security testing, however accomplished (contracting with security firms, open source + bug bounties, etc.)
9. Fast patching of identified vulnerabilities (because even after doing all of the above, you're still going to have vulnerabilities).
There is no silver bullet, true. Which is why all of the above are required -- and they still aren't really enough. Hiring rare, expensive programmers is not sufficient. And it's not actually necessary (though it's crucial to have access to at least some of them), and that's good because rare, expensive programmers are not scalable.
No. You cannot force people to think.
You're trying to substitute a different premise to tilt the argument in your favor. That sort of underhanded argumentation is obnoxious and you should avoid such assholery if you want to be taken seriously.
This false belief is at the root of the current mess, were more and more effort is poured into languages with no real effect
Except there has been a real effect. Modern, typesafe, bounds-checked programming languages and well-designed libraries cause demonstrably fewer security vulnerabilities to be written, and the vulnerabilities to be less severe. This is because these languages inherently make whole classes of vulnerabilities impossible. Comparing, say, Java and C, there is no vulnerability you could write in Java that you can't write in C, but there are large classes of vulnerabilities -- including the most critical remote code execution vulns -- that you cannot write in Java. This comes at a cost... there are also classes of programs you cannot write in Java but can write in C, and Java programs tend to be much larger and consume much more memory.
This means that while Java programmers still have to think about security, there are many kinds of potential security mistakes that they do not have to think about. This is positive progress.
I do crypto, and bad crypto APIs (like those provided by Java) are huge source of vulnerabilities. Better, simpler APIs like Tink or libsodium make a big difference, and programmers write far better code when they use them. This doesn't eliminate the need for programmers to understand cryptography, but it does eliminate the need for them to be crypto experts. Perhaps the best thing ever to happen in this space is TLS. There are still plenty of things to screw up, but if you need private, authenticated network connections, there is almost never a better answer than "Use TLS, and follow these rules to configure it correctly", except, maybe "Use TLS and use <library> to configure it" (e.g. Use OkHttp on Android).
Or are you seriously going to try to tell me that a Good Programmer should be able to design and implement secure crypto code from scratch, and that if they'll just think they'll do fine? If you believe this, please, please, never write any code that implements or uses any form of cryptography.
In what language does writing "x = y" when you meant "y = x" not lose the value of x, which you intended to keep?
Everything *MUST* *BE* unit-tested for type-correctness
While I prefer static typechecking, I respect the Python view that everything must be tested for correctness anyway, and that static typechecking just lulls the programmer into thinking that less testing needs to be done than is really the case.
I will say that the worst, most opaque code I have ever encountered was written in Python, but I blame the programmer who wrote it, not the language for making it possible. Bizarre, incomprehensible, even misleading code is possible in any language, only the techniques differ.
(The code I mention created a set of pure interfaces, then instantiated them and called their methods... and they worked! There was machinery that intercepted the instantiations and chose appropriate concrete types. Essentially it was a particularly opaque dependency injection framework. Think Guice, if you're familiar with that, but with absolutely nothing in the code to indicate that dependency injection was happening.)
However, part of it is modern coding in general. The last several "Agile" places I worked at were in permanent sprints, and the job of the developers is to get a feature that marketing already sold to the customer into the product.
Nothing about that situation is related to "modern coding" or "Agile"... that's just bad project management and bad business. It was extremely common when I first started doing software in the late 80s.
Is wire fraud? I guess that means they will arrest time warner representitives for sending me false statements. Or are there two sets of laws? One for me and one for big soulless tax evading corporations.
I think knowingly (this is what gets Time Warner off the hook; they claim error, not intentional fraud) sending false bills might be mail fraud. I suspect the wire fraud is for actions relating to accepting the payment -- e.g. setting up accounts in false names, etc.
As far i know, sending unsolicited bills for unsolicited services to businesses is totally legal, at least in my part of the world.
Unsolicited bills for unsolicited services that you actually provide, sure. I'm pretty sure that mailing bills for services you didn't provide constitutes mail fraud.
Exchanges are the dirty little secret that makes Bitcoin's (and every cryptocurrency's) model "work".
Bitcoin, yes. Most, perhaps even all, other extant cryptocurrencies as well. But I'd be careful not to exclude the possibility that it's possible to design a cryptocurrency that actually does scale, and could therefore achieve liquidity without exchanges.
I know, right? It's mostly nostalgia for the old days that keeps me around here. I should probably give up my /. habit.
Would you care to share the name of the company that you work for and which jobs that you have that you cannot fill with American talent?
Google (er, Alphabet). Software engineers.
And to be clear, it's not that there isn't any American talent, it's that there isn't enough. Google hires at a voracious pace, hundreds per week, about half of them SWEs. And not because of turnover, because of growth. To sustain that rate, and maintain a high bar for talent, Google's recruiters have to find 50K-100K new prospects every week. You can't do that if you restrict yourself to 1/26th of the world's population.
And I don't think the problem is the Bay Area. There are lots of Google engineering sites around the country, and all of them struggle to hire enough SWEs to keep up with demand. Google teams are perpetually understaffed. The Bay Area sites do struggle a little more, but not much more.
That's the sad song I hear over and over but it's pure lies. I've worked with hiring groups that had listings for speciality tech workers in small US towns in states no one wants to live.
My employer has engineering offices in ~40 US cities, including a dozen or so major metropolitan areas.
Sigh, /. is dead. It's like none of the posters even looked at the code.
For anyone who's interested, the encryption used here is very poor. He leaves the mode and padding unspecified for both the asymmetric (RSA) and symmetric (AES) encryption operations. That causes the provider defaults to be used. In the case of the RSA step that's not terrible, since every provider I'm aware of uses PKCS#1 v1.5 padding. This isn't great, since PKCS#1 v1.5 is vulnerable to an adaptive chosen ciphertext attack, but in this usage that doesn't really matter.
The bigger problem is that AES typically defaults to ECB mode. Using ECB means that any repeated 16-byte blocks of plaintext will encrypt to identical 16-byte blocks of ciphertext. This can often expose enough structure to allow the file contents to be partially recovered. It's particularly bad in this case since the same key is used to encrypt all of the files. If AES were in any way vulnerable to brute force, this would almost certainly provide many "cribs" (known plaintext/ciphertext pairs) which could be used to discover the key and decrypt everything else. AES-256 is not, however, vulnerable to brute force, and won't be until computers are made of something other than matter and occupy something other than space (anyone catch the reference?).
Overall, I suppose the chosen encryption was adequate to the task, but it was very sloppy.
Do you think he'd accept a pull request to fix it up?
The minimum required changes are small. I'd use "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" for the RSA operation, just because, and "AES/GCM/NoPadding" for the AES op. It would also be necessary to get the IV (let the provider generate it) and prepend it to each encrypted file. The files would be 28 bytes larger (12 for IV, 16 for tag), but secure.
Also, I'd process files in chunks rather than reading a whole file into memory and then encrypting and writing it back out. It could then handle files of any size. His code just skips any files larger than 20 MB. That's actually the biggest flaw in the implementation; given file sizes today, lots of stuff would just be skipped. All of my RAW photos would be safe, for example. The JPEGs would get encrypted, but who cares about them?
Oh, one more problem: Most systems these days don't overwrite in place, so the plaintext file will be left on the drive, available for recovery. Granted that recovery is not trivial, but still, the data will be there. Fixing this would require doing something like filling the drive with garbage files, forcing the drive to overwrite all free blocks. Overwriting multiple times might be a good idea, too, though that's probably not necessary. Some systems offer free space shredding as a feature; on those that could be used to ensure destruction of the plaintext.
Not from where I'm sitting. We hire all the Americans we can find, but we just can't find enough who can meet our requirements. We pay very well, have great benefits, etc. Doesn't matter. It's not a problem of finding people willing to work, it's a problem of finding people who can do the job. The only way to get enough good people is to hire globally. If that means more teams have to be based outside of the US, so be it.
If the process continues for long enough that our teams are primarily based outside of the US, then that will mean that Americans who want those jobs will have to move out of the country to get them. Assuming the other countries don't decide to reciprocate on the visa policies... if they do, then the Americans will just be SOL.
There are body shops that hire H1-Bs because they can get them cheap, but there are also plenty of companies who don't. Google, for example, pays all of its technical staff well, where they're from doesn't matter. But the H1-B crunch it's forcing a lot more international hires to be located outside of the US, where in the past they'd be brought in. I know a few who are in the US now on H1-Bs and are going to have to move because they can't get their visas renewed. These are people making $250K to $500K per year, so money clearly isn't the issue. So, Google will pay to relocate them, pay to fly them to the US regularly for team meetings and continue paying them well in their new location.
Really, if you want to fix the H1-B "problem", just set a minimum salary requirement (including bonus, equity, etc.) of $150K.
Old movies...Who's had a tire 'blow out' in there lifetime?
I did, about two years ago. A nearly new, high-end Michelin tire. Sidewall burst. It still happens, though it is a lot less common.
Remember 'sawing on' the steering wheel to take-up linkage slack?
Or you're middle-aged and your parents had old cars when you learned to drive. I'm 50 and when I learned to drive in 1985 it was on vehicles built in the early 70s. Both the car and the truck had that loose linkage, though the truck ('71 F150 IIRC) was a lot worse. I was amazed at how awesome the steering was when I drove my friend's 86 Celica. So tight!
Meritocracy isn't perfect, but it works when you do that one thing; don't give up.
So you're saying that luck didn't give you brains or looks, it gave you grit. And that luck is where your merit comes from.
(No, I don't entirely believe that; but there is an element of truth to it.)
They don't let us blind people fly, but I do believe that the sequence is aviate, navigate, communicate. I don't think you are supposed to diagnose until you are in controlled flight. But that's problematic if you can't stick and rudder fly so you'll never get to diagnosis.
Well, if something is going wrong with the plane, you will often need to diagnose so you know how to aviate, i.e. what you have to compensate for.
But with an active map of all super chargers within range, with how many bays are free/occupied shown, I usually dont follow the optimized route Tesla has planned. I prefer relaxed driving, and taking breaks.
Heh. In the mountain west the superchargers aren't dense enough to make this an option most of the time. In most cases, the road networks aren't dense enough to make this an option... usually there are only one or two reasonable routes between point A and point B, and often only one of them has superchargers. For example, from my home in Morgan, UT to Las Vegas, Google Maps proposes two routes: one that's 6:23 and 464 miles down I-15 and one that's 7:49 hours and 525 miles taking I-80 out to Wendover, then down through Ely. But, not only is that second route longer, there are no superchargers on the 363-mile segment between Wendover and Vegas. You could probably make it in a P100 if you drive carefully, but Tesla won't tell you to try it.
Charged again there before going over the mountains, while having dinner. Because, I know all the energy spent climbing will be recovered while descending. But missus would be disconcerted by the battery meter readings along the way. So plugged in, to avoid anxiety.
You should pop up the energy display in trip mode, so it shows the expected SoC over the trip, including the end. Do that regularly and the missus will get comfortable with the idea that the car is really good at predicting how much energy it takes to drive the planned route (because the car is, in fact, really good at it!).
When they did win the vote, no one really knew how to proceed from there, so they mostly just choose a path of maximum conflict to avoid having to make the hard decisions.
OT, but I think this is the story of Trump's presidency as well.
Whenever people cheer that FB is blocking "bad things", that makes it more tempting to thing, "If it is allowed on FB, it must be good!"
The slippery slope fallacy is called a fallacy for very good reason.
Nobody who is innocent has an alibi ready to go. Real people in the real world don't have documentation putting them elsewhere most of the time because they don't expect to need it. People who have that documentation ready to go, especially for a large number of incidents, made sure they'd have it to prove their innocence which means they aren't innocent at all.
I could easily produce lots of data to support alibis that I didn't previously know I needed, because I log lots of my life. Google Maps tracks my phone's location all the time, and it's basically never further from me than the next room. I use a sleep tracker, and that data is logged to Fitbit. What I eat is also logged to Fitbit, with timestamps. Same for my workouts. My meditation sessions are logged by Headspace. My work is logged in EMACS org mode, down to a resolution of a few minutes... and much of that can be corroborated with git commit timestamps, Google Docs version history, Web history, email and chat logs (I archive everything; delete nothing). A large percentage of my time is scheduled in Google Calendar... including a lot of info about who I'm supposed to meet, so after the fact it would be easy to dig up witnesses to corroborate those meetings. If I find out quickly enough about the need for an alibi, my home surveillance video camera history may have data to help.
That's just off the top of my head; I'm sure if I had reason to put some thought into it, I could find a lot more digital breadcrumbs from which I could gather data to alibi myself. And non-digital ones as well. Receipts, for example.
Having a lot of digital history to draw on just means that you're okay with being tracked, and perhaps even aid it. It's possible that's foolish, but it in no way implies you're a criminal.
The whole point of Firefox is that it was supposed to be a "platform"... but one which was lightweight, and you added in more functionality.
Not initially.
If you’re specifically targeted as an individual, you could reasonably argue it probably doesn’t help much.
Even if you're not targeted specifically, but just a target of opportunity.
But at a minimum you’re increasing the complexity of what is necessary for someone to own your machine - and it’s basically painless so why not take that extra step?
No argument there, though I still maintain that protecting the machine is close to irrelevant. What matters is the data on the machine.