It's hilarious how common this is, as a TA, I had to deal with this entirity of last few semesters. My students aren't that dumb to invite me into the group chat though.
I have to say the school really let the instructor down. An instructor should not have to fill 70 forms.
I think some of the replies and likes to your reply are kinda hilarious.
You went through the entire article, misunderstood the point (aka he's talking about people who are cramming information, not people who are using it to skip filler content and contemplate over the actual information like you do), and this misinterpretation is fair, it happens to all of us. Few people corrected you in the reply.
But a lot of people instead of reading the article, took the title of the article and your comment as what the article meant, thus fulfilling the entire thing his article mentioned. Speeding through information. Kinda hilarious.
>, misunderstood the point (aka he's talking about people who are cramming information,
The author is making multiple points and it's fair to consider each claim in isolation.
One of the points is that that active learning is better passive learning. And another point is that reviewing the information multiple times is better than reading it fast once. No disagreement about those. However, the other claim that the speed of 3x is always less retention than 1x isn't true for every listener, every speaker, and every topic.
- 3x can be better for focus because some speakers talk so slowly than listeners tune out at 1x
- 3x lets you listen to 3 different presentations of a topic for reinforced learning rather than only getting 1 perspective in 1x time.
- 3x lets you get past "easy sentences" and selectively slow down to 1x for the "hard dense sentences".
- 3x increases the wpm (words-per-minute) into the normal/natural speed of the reader's "imaginary voice in their head" when reading written text
The author should have titled his essay "Against Passive Learning" because that's the stronger point rather than highlight "3x".
I don't agree at all. The author doesn't mention filler content. He seems to implicitly assume that Mike's podcasts have no filler content. And he assumes Mike's motive to be trying to learn faster - rather than skipping filler - without presenting any evidence that Mike believes this.
I'd say the author constructs what is probably a strawman, that Mike is consuming so fast because he desires to learn as fast as possible, rather than the other obvious hypothesis - Mike is probably consuming so fast because he finds the content a little boring.
I don't think saivan is misunderstanding the author by pointing out the authors (mis)assumption - I think the author is misunderstanding Mike and you are axiomizing the author's misunderstanding to criticize other commenters.
To be fair, the article is quite long so I for example gave up reading after a while. Which from my brief skimming seems like what the author advocates for -- reading less things but more deeply.
To be fair I can't blame the author. The why part probably doesn't exist because he wrote it for himself, or, he wrote it for people who he knows and would be able to seperate what advice to follow for their use-case.
This is just an assumption on my part, but I feel like he just wrote down a list of what he has followed down in the past. He didn't write down the "why" because he wrote it in context of his own experiences.
Like that systemd portion looks very icky, but when you have the disclaimer in context. You'd want to go to something with the least amount of attack surface. Systemd is a giant project, and a very useful one at that, and for context I am firm supporter of systemd, but I can see why he'd put that in the guide, since his disclaimer says the guide isn't really about usability but minimizing the attack surface.
In turn it got submitted to hackernews by someone who read their article, and unfortunately some people would treat it as gospel and turn off their brains, since as you mentioned there's no "Why?", but it makes sense to not include it if he didn't really write it for the masses but just to document something for himself and his friends/colleagues.
We need to be better at being suspicious about any information. And do our own research and experimentation. But who has the time for that in this day and era when information is expected to be received by push notification and most people can't comprehend messages longer then an SMS.
Don't see anything wrong with Gentoo in their context.
Author says in disclaimer This guide is focused purely on security and privacy, not performance, usability, or anything else. He's not wrong. Gentoo makes it easier to have compile flags while building your system. Say you want to disable pulseaudio support completely? You can get rid of it completely from anything that might link to it by setting it globally as a flag you want to avoid.
Sure the guide doesn't follow a threat model, but there's still some good advice in there. If someone follows the guide as dogmatic gospel, as a list of rules to follow at all cost, that's on them. If one is responsible for securing down their stack, maybe they should know better than following everything down to the bone as if it's some gospel.
