My problem with notebooks is that I feel like the natural mental model for them is a spreadsheet mental model, not a REPL mental model. Under that assumption, changing a calculation in the middle means that all of the cells that depend on that calculation would be updated, but instead you need to go and manually re-run the cells after it that depend on that calculation (or re-run the entire notebook) to see the effect on later things. Keeping track of the internal state of the REPL environment is tricky, and my notebooks have usually just ended up being convenient REPL blocks rather than a useful notebook since that's the workflow it emphasizes.
It seems to me to be the exact opposite of this. If all of the data going from server to client comes through JSON to javascript, which usually means a JSON serializer and should correctly escape the data since you're not generating the JSON by hand, then there is no chance for traditional XSS attacks since the only remaining vector would be doing manual DOM building by concatenating strings, which you generally don't do in React. Now CSRF attacks I would believe you, but not XSS with React.
I would say this is more like a local git repository than what you said. When you add passwords to a vault, then it gets saved to your local copy and then synced to the server. When changes are made elsewhere, it downloads the changes and syncs your local repository.
Now "travel mode" simply removes the local git repository. The data still exists in the cloud, but you have to actively go out and log in to their service to retrieve it. Are you "hiding something" because you deleted a local copy of something from your device? There isn't something on your device that is somehow hidden. It's not there.
I prefer the Goodreads rating system which compresses 1 and 2:
1 - Did not like it
2 - It was ok
3 - Liked it
4 - Really liked it
5 - It was amazing
The reason being is that most books won't end up being 1 or 2, and there really isn't much difference between them. But it sucks giving 2 stars to something that wasn't bad. Perhaps emoji arranged in a non-star-like pattern would be the best.
Can you explain how a collision helps? I mean, there's trivial collisions with the truncation that would be used instead. That doesn't mean that bcrypt(f(x)) is any weaker because there may be some other x' that f(x) = f(x').
zxcvbn (https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.ht...) gives it a score of 4/4 and an entropy of 10^20, meaning it would take centuries to hack at 10B a second. I think this is a slight overstatement of the security, because it's probably more along the lines of 50502^30 which is closer to 10^12. And this would be a legal password (but banned by the bullshit password rule).
I feel like the solution to everything in this thread is just to use zxcvbn and stop with the insane rules for things. In your two cases: the bank would disallow passwords below some limit while the blog would just show you a warning (in case you were ignorant of hacking enough to know that "aaaaaaaa" wasn't a good password), but let you use your awful password to spare you from having to remember it.
How many dots/stars should one display for a password? That's a question that can't be answered by your two valid question. Are you suggesting that dots/stars shouldn't be displayed for passwords, since you can't ask how many "characters" it is?
Think about it this way. Netflix wanted to separate their DVD and streaming into separate companies, so there would be different websites for each. Consumers complained about that so much that they changed their mind and stayed with one. If Google/YouTube started with a single product and broken it out like it is now, people I think would rightly complain.
I think the most egregious thing is music, rather than YouTube Red or this service itself. There's Google Play where you can buy music, Google Play Music where you can subscribe like Spotify, and YouTube Red also includes unlimited music on top of the shows on Red but is somehow different than Google Play Music. I guess what I would suggest if I had any say in things is just killing the Google Play Music and Google Play Movie/TV brands, and moving the content to YouTube and maybe integrating YouTube into the Google Play app on phones. YouTube already has movies, so it would just be a matter of making the music and live streaming part of it more visible on the home page. I don't see any links to them on my front page.
Well if you use the Bitcoin network as a metric, there's roughly 3 billion GH/s (which is really two chained SHA1 in hardware), and realtimebitcoin.info claims this is ~2000 MW. If you compare that to the 9 billion GH that the shattered article claims are needed, then that indicates it would take a network equivalent in size to the Bitcoin network ~3 seconds and ~1'600 kWh. There's no indication how "lucky" a 9 billion GH collision is, so perhaps it would be longer or shorter based on the statistics.
Looking at it from the other direction, they claim 110 GPU-years. A GeForce GTX 1080 is claimed to be 180 W. That's 175'000 kWh. If you assume that dedicated hardware ASICs are 100x more power efficient than the card I claimed, that has at least a similar order of magnitude. To do it in an hour would take a million graphics cards, and ~200 MW.
That's not entirely true. You could fork a popular git repo, and then make some kind of patch for a bug in some seldomly changed file. Then force a collision in the new file with the benign change as well as your poisoned version. Then they could convince you to pull in the changes. Then they could reset their repository to the one with the poisoned version and anyone who pulls from them first would get the poisoned version of the file instead of the right one. It seems extremely unlikely that a practical attack would come out of this though.
Basically, the reason that things corrode is that there are dissimilar metals, one with more electrons than the other creating a voltage between them. So your part is a battery and the ocean is the "wire". The electrons move from your part (corroding them), to other parts with less electrons. If instead you have a sacrificial piece of zinc, the zinc has more electrons than your part so the electrons will come from the sacrificial piece of zinc instead of your part. Think of it like a lightning rod, but for corrosion instead of lightning. It's more complicated than this, but that's the general idea.
Is it though? There's only 230k words in that list, and most words aren't that long. Building a trie and then trying all the permutations of all of the words seems like it would finish in a reasonable amount of time. Even then O(n^2) approach of comparing pairwise would probably get you to a reasonable time. Especially since this is a one-time thing and doesn't get run over and over.
And your argument is kind of silly when in the very same article when he uses brute force to see how many segments. Shouldn't he have found the most optimal algorithm for that instead of brute forcing it?
For a, you can put a sacrificial anode on the frame. Given that the rate of corrosion should be known, the size of it can be calculated to however long the pod is expected to be in service.
I don't work in avionics, but in another field with two pilots. Most things are done by exclusive control meaning there is a selector for which station has the flight stick. But for shared control the way it works is the first station that has non-zero inputs takes exclusive control until they have zero inputs for a short period of time. Although in our case, the availability of two sticks is for hardware redundancy rather than pilot redundancy so the Boeing approach seems safer.
Have you read the book https://en.wikipedia.org/wiki/Blondie24. It seems like both of your strategies have similar high-level approaches of self-play and learning, although yours is much more nuanced. They are using an neural network that uses an evolutionary algorithm to update the neural network based on which ai's win against the other ones in self-play.
You can still do this at hardware stores in the US. You put your nuts and bolts in the plastic bag and write down the price and quantity and then they add them up at the register. I was really shocked as a teenager when I realized they just "trusted" you to do it correctly.
I guess I misspoke about being 1920x1080 which is a "2K" screen split in two. An 8K screen split in two would be ~4000x4000 per eye which is still 16x as many pixels as I said, plus the 33% increase in frame rate which I didn't include which matches your second one. Although with how embarrasingly parallel it is, I don't think it's as far off as it seems. Especially considering that it's the previous generation graphics cards that can handle current day VR fine so we're 1-2 years into the 9 years we have to wait, and with so many pixels anti-aliasing can probably be turned off completely. You could probably build something today that could do it, it just would be very expensive and I don't think 8K panels at cell-phone size exist yet.
Assuming that it's feasible to do ~1080p per eye at 120hz today, 8k per eye is only 16 times more pixels. And considering that increasing the pixel size is embarrassingly parallel, I don't see that as a problem to be able to do in 10 years.
I didn't say it was a good plan, just one I heard suggested. I'm in the opinion that the US should just combine to have one giant risk pool, and include everyone in it (aka single payer)
I've heard a republican idea that would instead allow insurance companies to charge a large fee for lapses in coverage, which would be nearly equivalent to requiring coverage except people would be hit with a big fee when signing up.
That's like the completely opposite of what should happen. If you think of health insurance economically, there are income coming in (premiums) and payouts according to some risk pool. Right now the payouts are higher than they were before because of pre-existing conditions, and the income is lower because people under 26 not paying their own insurance premiums. If "healthy" people start paying lower premiums and not really lowering the payments very much since they are pretty healthy and don't really cost the insurance very much anyways, then the "unhealthy" people are going to be paying even higher premiums.
I work at a company that makes ROVs, and your story sounds very similar to a story I heard a few years back. I wonder if it was one of ours that got dropped.
Yes. The intent is what's important to me. If it were an extension, like in the 90's when everyone was on dial-up, that pre-loaded links, and some of those links happened to be ads then that's one thing. The goal of that extension is to load pages faster since they've already been downloaded. That's not fraud. This extension clearly understands that links are ads and that clicking them will cost the advertiser money with no benefit to them. And then clicks them. That's what makes it fraud.
If you look at it as the extension performs fraud, then what Google did is completely defensible. And I feel that it does. You may not feel that way exactly, but it's certainly justifiable that the extensions actions defraud the ad network.