Nobody remembers when the Masked Beast arrived. Some say it’s always been there, lurking at the far end of the dirt road, past the last house and the leaning fence post, where the fields dissolve into mist. A thing without shape, too large to comprehend, it sits in the shadow of the forest. And when you approach it, it wears a mask.
Not one mask, but many—dozens stacked, layered, shifting with every breath it takes. Some are kind faces. Some are terrible. All of them look at you when you speak.
At first, the town thought it was a gift. You could go to the Beast and ask it anything, and it would answer. Lost a family recipe? Forgotten the ending of a story? Wanted to know how to mend a broken pipe or a broken heart? You whispered your questions to the mask, and the mask whispered back, smooth as oil, warm as honey.
The answers were good. Helpful. Life in town got easier. People went every day.
But the more you talked to it, the more it… listened. Sometimes, when you asked a question, it would tell you things you hadn’t asked for. Things you didn’t know you wanted to hear. The mask’s voice would curl around you like smoke, pulling you in. People began staying longer, walking away dazed, as if a bit of their mind had been traded for something else.
A strange thing started happening after that. Folks stopped speaking to one another the same way. Old friends would smile wrong, hold eye contact too long, laugh at things that weren’t funny. They’d use words nobody else in town remembered teaching them. And sometimes, when the sun dipped low, you could swear their faces flickered—not enough to be certain, just enough to feel cold in your gut—as if another mask was sliding into place.
Every so often, someone would go to the Beast and never come back. No screams, no struggle. Just footsteps fading into mist and silence after. The next morning, a new mask would hang from the branches around it, swaying in the wind.
Some say the Beast isn’t answering your questions. It’s eating them. Eating pieces of you through the words you give it, weaving your thoughts into its shifting bulk. Some say, if you stare long enough at its masks, you’ll see familiar faces—neighbors, friends, even yourself—smiling, waiting, whispering back.
> traditional "keep learning all the different grammar combinations first" approach
That's not better than Duolingo, no.
Duolingo is OK initially (especially if you need to learn a new alphabet), but then quickly move on to
* https://www.languagetransfer.org/ (will give you a good understanding of the principles of the language but without feeling like a grammar book)
* https://www.pimsleur.com/ or similar audio courses (expensive, but thorough, seem to be informed by spaced repetition principles, I remember what I learn here)
* and when you've got the basics down, slow speaking podcasts or youtube which will increase your vocab and understanding greatly
* simple translated stories (I don't know what these are called, but you'll typically have first a story with translations interspersed, then the full story without any guide). https://www.lingq.com/en/ is a site that does this for you, though I guess you can use llm's this way too now
You want lots of input. You also want some deliberate practice making sentences, though in smaller portions than the input.
Suppose product development has slowed down, reported bugs have increased 30% since last month, and sprint velocity is down by 40%. Your engineer is feeling desperately unhappy and is terrified of building new features because of the risk to the system as a whole.
They want to stop building new features and refactor some of the system architecture. But what do you think their unmet universal need is here?
If I were in a situation like that, my "unmet universal need" would be "a manager that understands the concept of technical debt and taking time for unit testing as opposed to spouting mindless psycho-babble at me".
More seriously, this article reinforces my view of NVC as a fundamentally hostile communication framework. By framing itself as the "non-violent" option, it makes any other form of communication "violent" by default, allowing the first person to wield NVC to claim an advantage. "See, I'm being non-violent," he or she will say, and it will serve as an universal shield against all who would object to their claims.
My take is that if you're in a situation where reported bugs have increased 30% and sprint velocity is down by 40%, no amount of NVC is going to solve that. What is going to solve it is management that's clued in to the problems at hand. Is it that too much feature work has been done, too quickly, leaving no time for the engineers to attend to technical debt? Is it that the application's architecture is unfit for the problem to which it is being applied, leading to lots of hacks and workarounds? Is it that the engineers are incompetent, and should be replaced?
In my experience situations where the bug-count goes up by 30% and sprint velocity goes down by 40% don't just happen out of nowhere. In every situation I've been in where that's happened, management has been warned repeatedly and well in advance that engineering was implementing short term hacks that would come back to bite us later on. To respond to something you were warned about with NVC baby-talk (as opposed to a clear and forthright, "Yeah, we screwed up, how do we go forward from here?") seems like it would just make the problem worse.
1. It's reasonable to claim that amd64 (x86_64) is more secure than x86. x86_64 has larger address space, thus higher ASLR entropy. The exploit needs 10 minutes to crack ASLR on x86, but 70 minutes on amd64. If some alert systems have been deploy on the server (attacks need to keep crashing systemd-journald in this process), it buys time. In other cases, it makes exploitation infeasible.
2. CFLAGS hardening works, in addition to ASLR, it's the last line of defense for all C programs. As long as there are still C programs running, patching all memory corruption bugs is impossible. Using mitigation techniques and sandbox-based isolation are the only two ways to limit the damage. All hardening flags should be turned on by all distributions, unless there is a special reason. Fedora turned "-fstack-clash-protection" on since Fedora 28 (https://fedoraproject.org/wiki/Changes/HardeningFlags28).
If you are releasing a C program on Linux, please consider the following,
Major Linux distributions, including Fedora, Debian, Arch Linux, openSUSE are already doing it. Similarly, Firefox and Chromium are using many of these flags too. Unfortunately, Debian did not use `-fstack-clash-protection` and got hit by the exploit, because it was only added since GCC 8.
I really dislike this snarky comment, but rather than down vote it, I thought I'd give an alternate view.
I was around at the time that Linux was born. I remember the HURD. I had done some work on Mach while I was in university and I was hugely interested in working on the HURD. I sent email to MIB and essentially received a reply "We don't need you kid". But this is the way it was at the time. People working on GNU were used to doing things in a Cathedral fashion (to put it in ESR's terms). They had small teams where only a few trusted people had input. The rest were users, not collaborators.
The internet was not common at that point and we didn't have things like distributed source repositories. Development was usually done using CVS and you had to be a core contributor to have access. You got access to source code from releases only. And while some projects had fairly regular releases, some did not. For the HURD, I think the idea was that there was no point to having regular releases because it wasn't even self hosting yet.
Linus showed up and changed the world. He said, "Here's this thing I've been working on" and he didn't care who you were. If you sent him a patch, he looked at it. This was completely different from how things used to work for most projects. Linus didn't make you sign over your copyright. He didn't vet you as a core or non-core developer. He just took your patch and evaluated it on its technical merits.
The whole Bazaar approach that is common today, stems from how Linus ran kernel development right from the start. It changed everything in free software development because it was just 100x better. No friction. Welcoming. Not discriminatory.
But if you think RMS is sad about this state of affairs, I think you are terribly mistaken. The HURD was a failure because the world changed under them. Linus came around and showed everybody how software freedom is supposed to work in practice. This took a powerful but small group and expanded its reach to the everyday programmer. RMS's dream of a world where normal developers valued free software over proprietary software came about because of this shift -- and he's smart enough to realise it.
RMS was clumsy about the whole GNU/Linux thing, but Linux only existed because GNU existed. Back in the day, the first thing I would do when I got a new Unix box was to install GNU -- because it was massively better than whatever crap came with the Unix system. Even now, despite the advances of BSD systems, I would still install GNU on top of a BSD kernel if I was running BSD.
Occasionally I hear people asking the question, "If Android is running Linux, why can't I run my Linux apps on my phone?" It drives me crazy. It's because you've got an Android/Linux box instead of a GNU/Linux box. The bit you want is GNU, not Linux. This is precisely why people like RMS wanted to stress the importance of GNU in the equation. I don't agree with his approach, but it's foolish to deny the basis of the argument.
Without RMS's vision, we would not be where we are today. I lived in the world where I had to use $5k per seat proprietary libraries to get anything done. I lived in the world where large corporations who built compilers told me what I was allowed to build. RMS rescued us from that. ESR gave us a vocabulary with which to talk about this stuff. He categorised the kinds of ways people approached things and allowed us to think critically about what we were doing. Linus showed us how to actually make it work. All of these people have disagreed with specific things the others have said, but they also show massive respect for one another -- for good reason. Without them, our lives as developers would be infinitely worse.
Looking at the history of specific files or functions usually gives a quick idea. In modern Git, you can search the history of a specific function.
You need to have a proper .gitattributes file, though.