Isn’t the screen shot of the app just below the fold good enough? Or would you like to see the finished product. The quality of that would significantly depend on the person making it (how well they can cut paper, how well they can glue) and their commitment to quality (how hard they’re trying), so I think it would either oversell the product by showing something the average user cannot produce or undersell it.
It's likely that the onboarding system for activating and linking the Kindle to an account will no longer work after a factory reset, and you will not be able to progress further.
FTA: “As a motivating example: player 1 (hereafter dubbed "Red") can win by playing in the center column on the first move and then following the weak solution's suggestions, but would not be guaranteed to win if the first disc is played elsewhere. The weak solution contains no information about what would happen in the other columns- As far as Red cares, it would be redundant to learn those branches, since they are not good.”
I don’t think that “since they are not good” is necessary for a weak solution. Even if every first move were winning, it still would be redundant to learn how to win for every possible opening move.
A weak solution gives you a guaranteed way to move from START to a win, whatever counterplay, not all ways to go from START to a win, whatever counterplay.
I think I would find it very challenging but fun. Certainly more fun than writing a date/time library (way more inconsistent cases; daylight savings time horrors; leap seconds; date jumps when moving from Julian to Gregorian) or a file system (also fun, I think, but thoroughly testing it scares me of)
FTA: “The update text is appearing on apps that have not been updated in some time, as well as apps that received recent updates, so it's not clear what the apps have in common.”
⇒ I think that’s unlikely. If some optimization got broken that produces results that bad that it has to be fixed, users would have noticed in those apps that “have not been updated in some time”.
I don’t think that’s a valid comparison. It compares two entirely different cases.
In general, if the guts of Foo are similar to those of Bar, translating Foo to Bar is fairly easy.
If Foo has additional guts, as in the C++-to-ℂ translator, translating those parts can lead to hard to read code.
In the C-to-D translator case, it’s not Foo that has additional guts, though, but Bar.
Then, a reasonable 1:1 transaction is easy. Doing it in idiomatic style can still be hard, though. For example D has garbage collection, classes and inheritance. I doubt the readily translation of C to D will replace C equivalents (e.g. a garbage collector written in C that’s part of the code) by those where possible.
It's true that D has many features that are not part of C, and a translator from C to D will not recognize constructions in C meant to exhibit inheritance. It's also true that a C to D translator will not be able to translate metaprogramming done with the C preprocessor.
It is a valid comparison, though, as there is no point to designing a language that has a 1:1 mapping to/from C.
> What has changed? Why do I need 10x the RAM to open a handful of terminals and a text editor?
It’s not a factor of ten, but a 4K monitor has about four times as many pixels. Cached font bitmaps scale with that, photos take more memory, etc.
> When Windows 2000 came out
In those times, when part of a window became uncovered, the OS would ask the application to redraw that part. Nowadays, the OS knows what’s there because it keeps the pixels around, so it can bitblit the pixels in.
Again, not a factor of ten, but it contributes.
The number of background processes likely also increased, and chances are you used to run fewer applications at the same time. Your handful of terminals may be a bit fuller now than it was back then.
Neither of those really explain why you need gigabytes of RAM nowadays, though, but they didn’t explain why Windows 2000 needed whatever it needed at its time, either.
The main real reason is “because we can afford to”.
No — web fonts bypass the Preferences mechanism entirely, which means you lose the cross-site persistence that makes Step 1 valuable. A web font attack is a different chain (CSS injection → malicious @font-face → GSUB) with a different threat model and narrower scope. P.S. Sorry I missed this earlier — thanks for the comment, really appreciated it!
reply