This has also been a common theme in recent decades with respect to privacy.
In the US, the police do not generally need a warrant to tail you as you go around town, but it is phenomenally expensive and difficult to do so. Cellphone location records, despite largely providing the same information, do require warrants because it provides extremely cheap, scalable tracking of anyone. In other words, we allow the government to acquire certain information through difficult means in hopes that it forces them to be very selective about how they use it. When the costs changed, what was allowed also had to change.
I think of this in reverse. It's legal for the government to track mail - who sent a message, and who it's going to. They have access to the "outside of the envelope". But it's not legal for them to read the message inside.
And this same principle allows them to build massive friend/connection networks of everyone electronically. The government knows every single person you've communicated with and how often you communicate with them.
Does it have the same issue with key repeat? It's a long standing iOS bug, but some apps seem to fix it (somehow). Without the fix, vim ends up being essentially unusable since I can't press and hold on the cursor movement keys. iSH, for example, hits the bug and it severely limits the usefulness of the app.
Wouldn't that apply only to a truly unlimited subscription? Last I looked all of their subs have a usage limit.
If you're on anything but their highest tier, it's not altogether unreasonable for them to optimize for the greatest number of plan upgrades (people who decide they need more tokens) while minimizing cancellations (people frustrated by the number of tokens they need). On the highest tier, this sort of falls apart but it's a problem easily solved by just adding more tiers :)
Of course, I don't think this is actually what's going on, but it's not irrational.
> You do realize there is both lossy and lossless compression, right?
This is simply wrong. There is no lossy compression for ZIP.
DEFLATE, by far the most common ZIP compression method, uses LZ77 and Huffman Coding, both of which are lossless. There are other methods compatible with ZIP containers as specified by PKWARE (e.g. BZIP2, LZMA, Zstandard, PPMd, etc), but all of them are lossless. According to both the official ZIP specification and every ZIP implementation on Earth, you cannot have a lossy ZIP unless it is corrupted.
There do exist lossy data formats (e.g. JPEG), but if you put those in a ZIP file it'll still encode and decode it losslessly.
> Did you hyperfixate on the colloquial usage of zip?
No? I am not hyperfixating on the colloquial usage of ZIP. The colloquial usage of "zip" would be "any compression container", which is not what I'm talking about. I'm talking about the technical definition of ZIP: the lossless container format specified by PKWARE. I thought that would be obvious by my reference to the PKWARE specification.
@godelski clearly indicated 8 days ago they were not referring to to formal ZIP files.
Your misunderstanding might be due to not being exposed to long standing casual usage of "zipping" something up to include many archiving formats, a number of which do include lossy compression methods.
Congrats on being a 15 year old developer, though .. some of the folk kicking about on HN wrote the books(?) you may have read.
Putting aside both my age and the latency of my initial response, all that I was trying to do was correct godelski's erroneous attempted correction of sweetjuly's lighthearted joke. The "colloquial usage of zip" that godelski was chiding sweetjuly for "hyperfixating" on is exactly the usage that godelski was using in their original reply. I did not misunderstand godelski's intended use: they were using "zip" to refer to "any compression format whatsoever, be it lossy or lossless". This is a technically incorrect usage, which would be fine if not for the snarky chiding. I think that misusing a term and then accusing people of "hyperfixating" when they lightheartedly correct you isn't a particularly nice thing to do.
\1 godelski colloquially used the term zip (Not referring to formal ZIP files)
\2 sweetjuly made reference to ZIP files not having lossy methods
\3 godelski indicated they had use zip colloquially, not with the intention of referencing the precise ZIP specification.
\4 ethmarks stepped in and doubled down on the precise ZIP specification, despite that not being what godelski initially referred to.
Here's the thing, people make casual remarks, they use imprecise non technical colloquillisms.
How would you describe the actions in \4 ? Do you believe it served a useful purpose to double down and restate something that was very likely well known to both parties over a week ago?
> Here's the thing, people make casual remarks, they use imprecise non technical colloquillisms.
I think that you're completely misunderstanding my objection here. I'm not in the least bit upset by people using "zip" casually to mean something other than formal ZIP files. I personally use "zip" as a verb to describe compressing to a tarball, for example. This is a technically incorrect usage, but it's okay for things not to be absolutely technically correct.
My objection is to \3, both to your summary of it and to the actual message content. godelski did not "indicate that they had used zip colloquially"; they accused sweetjuly (who fully understood that godelski was using the term colloquially and was simply making a humorous, playful, and lighthearted correction that didn't warrant further reply) of hyperfixating on the colloquial usage of zip. This is not only technically wrong (sweetjuly was "hyperfixated" on the technical definition, not the colloquial usage), but it's also accusatory and mean-spirited.
> Do you believe it served a useful purpose to double down and restate something that was very likely well known to both parties over a week ago?
Not in a strictly pragmatic sense, no. I intended to set the record straight by clarifying the factually accurate statement that ZIP is not a lossy format, which seemed to be contested. I didn't expect anybody to read my comment to an 8-day-old threat, nor did I expect anyone to reply to it barely 3 minutes later, nor did I expect to be drawn into a 7-reply-long debate about this.
Isn't it delightful how well we've proved godelski's original point about how fraught natural language is?
Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
Strong wording there, from you .. do you suppose that was a vicuous stabbing accusation, or a playful rejoiner questioning the zip V ZIP ambiguity? People do get a bit playful.
> nor did I expect anyone to reply to it barely 3 minutes later,
You don't have to fly in acro mode lol. The common hobbyist drone firmwares have full support for even things like autonomous GPS missions. You also don't need expensive gimbal stabilized cameras; you're not making a cinematic film, so you can just hot glue a 360 camera to the bottom and deal with the slight oscillations.
The original example is very common in ISAs at least. Both ARMv8 and RISC-V (likely others too but I don't have as much experience with them) have the idea of requiring software to treat reserved bits as if they were zero for both reading and writing. ARMv8 calls this RES0 and an hardware implementation is constrained to either being write ignore for the field (eg read is hardwired to zero) or returning the last successful write.
This is useful as it allows the ISA to remain compatible with code which is unaware of future extensions which define new functionality for these bits so long as the zero value means "keep the old behavior". For example, a system register may have an EnableNewFeature bit, and older software will end up just writing zero to that field (which preserves the old functionality). This avoids needing to define a new system register for every new feature.
Genies, maybe? They are omnipotent and (generally) sufficiently aware of your desires that they shouldn't actually get "confused". Genies are tricksters that will do their absolute best to fulfill the letter of your wish but not the meaning.
The other commentator mentioned Verilator (which is indispensable in larger designs) but you may also want to grab Icarus Verilog too. It's a FOSS simulator and, unlike Verilator, is 2-bit and so it handles X ("don't care") and Z ("high impedance") signals. It's ridiculously slow compared to Verilator but the greater fidelity can be valuable depending on what you're trying to do.
This is the kind of advertisement-blog-post that should not have been published until after disclosure. These are quite extraordinary claims and that demands extraordinary evidence.
This is fair, and we will gladly share the extraordinary evidence as soon as we can.
If you're curious, we have already released the full traces of finding a sqlite3 0day with an early version of Xint Code (submitted to the AIxCC competition and now open sourced): https://theori.io/blog/exploring-traces-63950
In the US, the police do not generally need a warrant to tail you as you go around town, but it is phenomenally expensive and difficult to do so. Cellphone location records, despite largely providing the same information, do require warrants because it provides extremely cheap, scalable tracking of anyone. In other words, we allow the government to acquire certain information through difficult means in hopes that it forces them to be very selective about how they use it. When the costs changed, what was allowed also had to change.