> You can see this in the article: "Google Docs added some kind of delay such that the typing you do into the title box right after you open the doc gets overwritten". That's a developer forming a model of the system. The lay alternative is to simply learn that sometimes when you type in a box, the text appears. Other times, it doesn't. If it doesn't, you try again.
Things like this just infuriate me. The user just learns that things are unreliable. To me that's unacceptable for something to be presenting a text box to type text, let you type it, then wipe it out. Sometimes you have to wait a second after typing something before clicking search, or it searches for your incomplete query a half second before. I don't blame users for just concluding that typing is unreliable.
True, cash is good if you lack discipline. For such a person, more flexibility leads to less because they misuse it in a way that reduces flexibility. It's a footgun for these people.
That was my first thought, that a TUI is still a GUI. Close your eyes and explain how you can use a TUI from the keyboard. The only difference is what the display can render.
It's not hard at all. Citi Custom Cash has 5% on the highest category spend each month for the first $500 (I use it on groceries). American Express Blue Cash Everyday has 3% on groceries/gas/online purchases for up to $6000 purchases each year. Chase Freedom Flex and Discover It have rotating categories every quarter, sometimes groceries, gas, Amazon, PayPal, etc. None of these required much income to be approved.
Just saying, a little clarification would have helped. The details are there, but putting it together would have laid out the base algorithm that's being optimized, which I see as a basic point of an article like this, give everyone a clear understanding of the algorithm so they can follow along.
"rd is number of days offset from 1970-01-01, positive or negative. In some languages the mod 7 can yield a negative in the range -6 to 0, so an extra +7 and mod is used in the basic implementation."
The decoy passcode feature should boot into a separate partition that looks like a normal phone setup, and during that time quietly erase the user's actual data. They would never have known if it worked like this.
Not covered in the page, but dates can be a negative number of days from the epoch, which is what the fixups (+7) and using mod 7 twice are for, as negative mod 7 will yield a negative.
From the title I was expecting this to be about them packing 700MB of data on the CD, a common thing at the time by spacing the tracks slightly closer together, as some CD-Rs did.
This actually means it will become easier to block ads on Fakebook, because they won't be trying as hard. You'll just have to find custom filters people have shared to a smaller audience.
Maybe they do. Do QR code decoder authors QA their decoders to be sure they are getting high accuracy of the raw data? You could make a poor decoder that relies on the error budget to work, while someone checked with a high-quality decoder. Tech with error correction invites corner-cutting. Hard drives, flash storage, even DDR5 RAM does this. Use crapper representation or reading devices and just add more error correction.
For some reason an XOR scheme escaped me. It's the perfect way, doesn't take any extra space over the size of the modified regions, and avoids even storing the copyrighted work of the ROM patch author. You could distribute the patch without anyone's permission (maybe)! Just include a strong checksum of the affected regions to be sure you're starting with the correct version, and checksums of the resulting data to give the same guarantee for reversing the process.
This reminds me of car safety features, how drivers have become more complacent to offset the benefits. QR codes were made to be robust in the face of errors, but over time this has been eaten into for aesthetic purposes. Businesses commonly put a logo in the center, eating up some error correction budget. This likely has a similar effect.