Can a recipient be a member of multiple groups, for example, if I happen to be among coworkers and family (or whatever)? If so, hopefully I would get one newsletter containing all the posts tagged as any of my groups. But this means the potential number of different newsletters grows exponentially relative to the number of groups (although in practice, it would be extremely unlikely that a huge number of combinations actually exist) which might or might not matter, depending on whether each recipient already gets a bespoke copy (greeting them by name, click tracking, etc.) or if you're relying on listserv style distribution.
The real absurdity of 2k/4k/etc is that those refer to approximate horizontal pixel counts, when "lines" (vertical pixel count) such as 480/525/1080/etc has been the typical dimension for such a long time. Why the switch? In the 16:9 world, ~2k horizontal is close enough to ~1k (1080) vertical, and ~4k horizontal is close enough to ~2k (2160) vertical, etc. so it can't be that the horizontal numbers round to the nearest k better than the vertical numbers.
"Rare" versus "common" is an interesting one. They sound like antonyms, but I don't think the typical probabilities are really symmetrical. Maybe something like 0%-10% for rare (although some sources say 5%) and something like 40%-100% for common.
I think I mentally interpret "common" as "a member of a plurality category," which is to say in the same order of magnitude of commonality as the most common group at a given level of detail.
What you're describing, I think I would call "Not uncommon." Or, to put it another way, you shouldn't be surprised for any given case to exhibit it, but you shouldn't expect it either.
Maybe it's my amount of video games played in childhood that influenced that, but common and rare are just two points on a spectrum (with at least "uncommon" in between)
For the local OS and sustained workloads like video playback, yes, battery optimization is huge. For an individual app with bursty compute, less so, plus some of that inefficient code can run in the cloud instead, which is costly, but premium subscriptions can pay for it, and power plants are now colocated with data centers so power transmission cost is negligible. The incentive to be efficient is insufficient.
The story says that the password reset link was received, which proves the vulnerability without actually denying service, causing loss, etc. As an analogy, the attacker found a key to a door but did not proceed to open the door.
It doesn't say the password reset link was used to change the password, which would deprive the account owner access and grant unauthorized access which of course would be illegal.
The trouble with that is plenty of extensions legitimately need to run on all sites all the time for the user to get the value they want. Ad blockers, coupons for all stores, etc.
The thing is... it's generally safe to truncate a leading zero [0], but it's not necessarily safe to truncate a trailing zero. For example, sometimes trailing zeros convey precision, and then you've got SEMVER [1] causing situations like Drupal 7.1 and 7.10 and 7.100 (spanning 100 minor releases).
[0] ZIP codes and phone numbers are important exceptions, but it's a non-issue if you always process these as strings, never as numbers, which is a reasonable constraint because we don't need to sort these numerically. Lexicographical sort is perfectly fine.
[1] The concept mentioned in footnote 0 does not really apply to SEMVER, because we do like to sort versions numerically. Lexicographical sort is wrong. But it's a group of dot-delimited integers, not to be conflated with floats, so while 7.100 comes before 7.2 when sorting floats, 7.100 comes after 7.2 when sorting SEMVER because the 2 and 100 are just integers.
> The given examples seem disconnected from the duty cycle radios on my browser. I mean changing them changes the sound, but it's as if the one I selected is not the one playing.
Confirmed. Author, please fix! For example, in the first set of radio buttons:
1. Leave it at the 50% default
2. Press play
3. Change it to the 12.5% option -- we continue to hear the same sound
4. Change it back to 50% -- finally we hear a different sound
This is broken. Another example:
1. Listen to 12.5% after having come directly from 25%
2. Listen to 12.5% after having come directly from 50%
The 12.5% should sound identical in either case, but it erroneously does not.
This is correct, the demo not properly handling the selection of a new duty cycle. I pushed up a correction just now. Thanks for laying out a detailed replication - made for an easy fix
> almost identical ... components would be identical
I'm having a tough time reconciling how the former could be almost identical while the latter is identical. I guess the former involves a human listening through a speaker which has asymmetric imperfections (maybe the speaker moves outward more easily than it moves inward, or a DC offset in the signal leads to compression in the high-excursion side that doesn't exist on the low-excursion side, etc.) whereas the FFT readout doesn't necessarily have a speaker in the system at all.
25% and 75% would sound identical alone, but in a mix there often are interplays where it can create a difference. An easy way to hear it is to run two synced oscillators, say a square and a saw, with sharp attack. The resulting sound should be sufficiently different, one side would dampen the attack compared to the other. Furthermore, I think in hardware synths and those that emulate them changing pulse width can cause the module to implicitly shift the signal up or down to ensure consistent average voltage, further complicating things. I am curious what you mean by compression.
Good point. If I have 2 oscillators, and no control over their phase as they mix, then an option to choose 25% vs 75% for one of them would at least offer some variation instead of none.
As for compression, this [0] is a good intro. Most commonly it is applied to a signal deliberately to achieve a desired outcome, but I'm referring to a (generally) undesired speaker nonlinearity [1] near its maximum power handling capacity.
Different linearity properties on the positive and negative side would be pretty bad for a speaker, but possible. In the case of a square wave, non-linearity would be identical to a fixed amplitude change though, possibly with a DC bias.
Based on the gameboy wiki I looked up, the phase of the 25% duty and 75% duty are such that they are inverse of each other, seemingly eliminating the possibility of combining the two for different waveforms.
I tried putting a few of GP's multilingual paragraphs into google translate on detect mode, and it got everything into English perfectly! Interestingly, it declares a single language as having been detected, which varies perhaps based on majority input language.
