if you're interested in this kind of thing, The Mexican Runner beat every NES game (over 700 of them [1]) including such gems as Miracle Piano Teaching System, which took 91 hours to beat and required him to become quite proficient at actual piano playing [2]
The point is that with EU mandating alt-browsers on iOS, it should have been a possibility to have "Installed" (home-)PWAs where the engine is the alt-browser, not safari/webview.
Those browsers could have implemented the Home-PWA functionality while maintaining your ability to install plugins such as adblockers within that PWA's context.
Apple has made this impossible by removing the OS APIs that allowed "Installed" (home-)PWAs entirely. This is just so they aren't forced to allow these under a different browser engine.
Of course, this is all done because "think of the children" (i.e.: think of the poor people ticked into using a non-privacy-respecting browser to run their PWAs).
My position is that if you open development to 3rd parties they have to be able to develop for your platform for free. You can charge for the services you provide to the developers (fees if they use your payments platform, your distribution platform, etc), but you should not be able to force them to use such services.
The win-win is that by opening your device to 3rd parties it is made more useful for your users and hence more desirable. Iphones wouldn't be so popular if you couldn't access tiktok, instagram and what not with them after all...
- If the king is in its initial position, whether the king has moved previously (that player can't castle anymore).
- For the pawns, you may need the previous position/move to allow en-passant capturing [1]
The standard specification used for this is the Forsyth–Edwards Notation (FEN). [2] It was invented way earlier than computers, so it was targeting humans / isn't optimized for digital compression, but it at least specifies _almost_ everything that you need to track.
The _almost_ is because to account for the repetition rule [2] you need to track all previous positions. At this point, the problem changes from "how to efficiently store the positions of the pieces in the board" to "how to efficiently store (partial) games", and you are probably better off listing the moves than the board state.
I love bit-bashing to squeeze something down to the smallest representation possible. There was a related discussion here on HN recently, where I came up with this:
A good representation needs to keep the full game history due to the no-repeat rule, and also because this is generally useful. There are only 32 pieces so a 5-bit number can select one uniquely. Each piece has a maximum of about 32 positions it can move to on its turn, for another 5 bits. Then the encoding is just 10 bits per ply. Typical games are 40 moves (80 ply) and hence require just 800 bits or 100 bytes for the whole game history. Some additional data is required to track promotions, but that's it.
Then you could get clever with Huffman coding or the like, since some moves are more common than others. E.g.: on the first turn, only the pawns or the knights can move. For quite a few turns, pieces either can't move or are very restricted in where they can move to. Pawns always have so few moves available that their next move could be represented with just 2 bits instead of the full 5. Etc...
In practice, it ought to be possible to get the typical standard game representation down to 8 bits per move or less, especially for short games.
To represent games starting from arbitrary configurations, there needs to also be included 32 6-bit numbers to encode where each of the unique pieces is on the 64-square board. This adds just 24 bytes for this initial "setup".
Just encoding algebraic chess notation gets you to 9 bits without much skill: 3 bits for the 6 pieces, 3 bits for rank and 3 bits for file, with the edge cases shoved in the extra encoding space given that you have 3 bits to encode 6 pieces.
On average, chess has a branching factor of 30-40, so you need a touch more than 5 bits on average even with clever Huffman coding. Just Huffman coding regular algebraic chess notation for movement would probably get you down to 6 bits on average.
Of course, the other issue is that the tighter you compress the data, the harder it is to actually manipulate that data, and it's not clear that the space saving for denser encodings is worth it.
That’s a lot of extra wasted bits! There are only 32 pieces in total, and only one of 16 can move each turn. So a mere 4 bits is sufficient to select the moved piece.
The assumption here is that this is an encoding “at rest” and isn’t used directly, except perhaps for equality comparisons. The decoder would have to track the game state and expand this into a much larger format for programmatic manipulation.
>To represent games starting from arbitrary configurations, there needs to also be included 32 6-bit numbers to encode where each of the unique pieces is
In that case, you can either omit pieces not in play or omit pieces in their standard starting position to shave off a few more bits.
I remembered current turn later but I could not think of your 2nd and 3rd point, you are right
I guess you can't just take a look at board to see current game state, I was too focused on what game looks like while there are additional off the board info
instead of encoding "moved king", encode "moved rook" on each rook. Since a pawn can never be on its home rank, overlap rook (not moved) & pawn (en passant) codes. Now you have a code for "king (to move)" and "king (not to move)".
If you use a variable length encoding you can also use different static probabilities for the different ranks, since "rook (not moved)" and "pawn (en passant)" can only appear on certain ranks and only depending on the piece color (well, pawns can't appear on ranks 1 or 8 at all)
Those batteries are glued in to their own rigid case, which makes swapping them out of the laptop trivial but also didn't leave much room for expansion inside the battery pack, and the battery pack was pretty thick compared to any recent Apple laptop.
Replacing the cells inside one of those packs would have been similarly difficult to ungluing and replacing the batteries in more recent Apple laptops, but there was a lot less reason to rebuild those battery packs.
> most sites don't care about Firefox compatibility
This is FUD. Can you please name specific sites that don't work in firefox? Even all of google's stuff works fine, particularly when seen thorugh the eyes of non-technical people.
I got endless issues opening an app the second time. Didn't happen in Chrome.
As for sites that specifically doesn't care about Firefox, that was in a private talk with another frontend developer, so I can share neither the name or a URL as proof.
Your quote is from the 2002/58/EC directive, which is amended by directive 2009/136/EC [1]. The latter says :
> (66) [...] Exceptions to the obligation to provide information and offer the right to refuse should be limited to those situations where the technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by
the subscriber or user. Where it is technically possible and effective, in accordance with the relevant provisions of Directive 95/46/EC, the user’s consent to processing may be expressed by using the appropriate settings of a browser or other application. [...]
Hence, so long as the use of cookies or similar is strictly necessary for the specific service requested by the user, a website doesn't have the obligation to obtain their permission.
He has already completed all games, but the videos are waaay behind (he's releasing one video/game a week).
[1] https://www.youtube.com/@Thabeast721/videos