351 karma · joined June 21, 2015
(First, a retelling of the original)
> High above the forest floor, a millipede strolled along the branch of a tree, her thousand pairs of legs swinging in an easy gait. From the tree top, song birds looked down, fascinated by the synchronization of the millipede's stride. “That's an amazing talent,” chirped the songbirds. “You have more limbs than we can count. How do you do it?” And for the first time in her life the millipede thought about this. “Yes,” she wondered, “how do I do what I do?” As she turned to look back, her bristling legs suddenly ran into one another and tangled like vines of ivy. The songbirds laughed as the millipede, in a panic of confusion, twisted herself into a knot and fell to the earth below.
(The second part)
> On the forest floor, the millipede, realizing that only her pride was hurt, slowly, carefully, limb by limb, unraveled herself. With patience and hard work, she studied and flexed and tested her appendages, until she was able to stand and walk. What was once instinct became knowledge. She realized she didn’t have to move at her old, slow, rote pace. She could amble, strut, prance, even run and jump. Then, as never before, she listened to the symphony of the songbirds and let music touch her heart. Now in perfect command of thousands of talented legs, she gathered courage and, with a style of her own, danced and danced a dazzling dance that astonished all the creatures of her world.
Your brain is not wired to remember things that you don't use. If you want to continue remembering, you have to continue engaging with the topic, and a lot of the advice in this thread is IMO just that (just, with a specific regimen / kind of engagement). It's completely natural to forget.
In fact, I'd go further and suggest embracing the forgetting and relearning cycle. If you really need to revisit the topic, you can relearn it again, and it'll be faster than the first time. And maybe you'll forget another time -- that's OK too, you can pick it up again even faster. In the end it's the discipline of relearning (the particular topic, and in general!) that actually continuously hardens. IMO there are parallels between this mindset and SRS -- though without the shame when you forget or miss a day of practice.
[1] https://en.wikipedia.org/wiki/Kevin_MacLeod [2] https://incompetech.filmmusic.io/
[1] https://battleofthebits.org/lyceum/View/bytebeat+(format) [2] https://battleofthebits.org/browser/Format/bytebeat
> This sentence has five words. Here are five more words. Five-word sentences are fine. But several together become monotonous. Listen to what is happening. The writing is getting boring. The sound of it drones. It’s like a stuck record. The ear demands some variety. Now listen. I vary the sentence length, and I create music. Music. The writing sings. It has a pleasant rhythm, a lilt, a harmony. I use short sentences. And I use sentences of medium length. And sometimes, when I am certain the reader is rested, I will engage him with a sentence of considerable length, a sentence that burns with energy and builds with all the impetus of a crescendo, the roll of the drums, the crash of the cymbals–sounds that say listen to this, it is important.
(Gary Provost)
H(1) is true
H(n) => H(n+1) (with a sleight of hand that it's only for n >= 2)
It seems to me like changing either the argument to assert H(2) is true, or the scope of the second statement to include n = 1, would be enough. It seems the fault of both statements equally to not fit with the other, so why is it weirder to say the base case is wrong?
Even if the generation itself has limitations it seems like a great springboard for manual touches like dissonance tweaking, or new sections, or fills / transitions -- arguably the cool creative part after all anyway! There's a lot of repetition in music, and when writing, it's hard to decouple it from points of interest. A workflow that enables such is very exciting.
(Taking this opportunity to share my multiplayer piano roll editor: https://yuxshao.github.io/ptcollab/ )
1. When collabing with friends it was slow for us to iterate because we (and a lot of people) just send files back and forth. It was hard to sketch things out without having some other kind of whiteboard. Of course others who can communicate musical ideas better through words probably would handle this a lot better.
2. Multiplayer editing was really fun in comparison. The magical moment is when you're working on some section and you listen to the song again and you realize someone else has added something on top of what you were doing earlier. It's like the song has taken on a life of its own.
3. Even with multiplayer it's still hard to coordinate and you can't get around planning even with rich tools. If the song was gonna be serious and not just doodles, we usually had to voice-chat to discuss what'll go in each section, then sorta divvy up parts. I guess the upshot is that even with the ability to be 'maximally' present with others, many people, myself included, work best with some amount of private creative freedom.
When I jammed in a bigger group, flows like relays or Monsquaz swap [2] that gave people that freedom, then at specific moments let them intermingle, seemed to work best for getting something out at the end. (If it was a free-for-all people usually ended up doing their own thing in some measures they staked for themselves out in the roll. Or otherwise people just spammed meme songs like Megalovania everywhere.)
[1] https://github.com/yuxshao/ptcollab [2] https://swap.monsquaz.org/
Maybe a clearer example w.r.t. the base^exponent value would be another highly structured class of long passwords, instead of short passwords. For example, those that are just a 2-character sequence repeated 20 times (e.g. abab...ab). You can still say that it'll take maybe up to 26^40 tries for an attacker to guess this, but that number should be more obviously too charitable, since less entropic classes of passwords are more likely to be guessed first.
More generally, this kind of counting analysis depends on your choice of attacker, and it's plausible for attackers to be more sophisticated than just trying all the strings in lexicographical order. A more concrete but still practical attack sketch adapted to the frequency of password schemes today could be: guess dictionary word combinations first, starting with common/short words/phrase lengths, then repeat with small perturbations, then more perturbations, and so on until you search all the remaining strings.
Then, the number of tries for such an attacker to find a 3-word passphrase with a few changes would be much closer to (some small constant) * (# dictionary words)^3 than (# characters)^(string length). Of course, you can still say that such an attacker would take at most (# characters)^(string length) tries to get it, but such an upper bound isn't as useful when the password is much more structured and easy to guess with a slightly more sophisticated attacker.
(Yet another way to put it: one shouldn't expect a password that's 'slightly out of reach' to be significantly more secure than a password that follows a scheme exactly - a more sophisticated attacker would test neighbouring passwords as it brute-forces the combinations in the scheme)
In particular, short passwords with up to 8 characters are weaker because they form a small and common subset of passwords that people often draw from, and attackers exploit that by trying short passwords first.
Passwords that are 3 dictionary words, with possibly some small perturbations like punctuation inserts or replacements (which helps but only expands the space so much), also form a relatively small subset of passwords that people increasingly draw upon, and attackers aware of this will tailor their brute-force search accordingly.
Both generals start with either 0 or 1, and the condition is that if both started with 0 (i.e., initially wanted to individually retreat), they should both output 0. Likewise for 1. The thing about Eve deciding which value the generals start with may also be confusing; a better way to think of it is that 'no matter what both generals start with, this validity condition holds'.
There are so many examples in that book where users, frustrated or inconvenienced by the (high-tech) complexity of their tools, devise their own (low-tech) way to use a tiny subset of the features that just barely gets the job done for them--though perhaps not as creatively as writing on the screen here. One is the emergence of scrappy post-it-note instruction guides for basic tasks people would tape next to overengineered phone systems in the 90s. He also presents the concept of a 'gulf of evaluation' that makes contextualizes the difference between designer expectations and actual use (or the difficulty of getting feedback that would bridge this gulf).
The book---in its latest version, intentionally---omits discussions about modern software, but it does more than enough to prove its point with simple everyday examples. I'd highly recommend giving it a read to anyone!