ylph

Once you finish it, it's actually really fun watching other people's playthroughs as well - getting to relive some of the moments vicariously through other people's eyes is almost as much fun as experiencing them yourself the first time.

It's also quite amazing just how different each playthrough can be, since the game is so non-linear, people take some crazy paths to get to the end ! It can be frustrating as well when someone just can't see what is in front of their face though :)

There are also so many subtle elements scattered around that most people miss on their first playthrough, and watching someone else play it really made me appreciate many of the details I missed on my own playthrough and even make connections I didn't before, and understand aspects of the story that I didn't fully get the first time.

YouTube video ads can't be blocked with just DNS blocking unfortunately, they are served from the same hosts as YouTube videos.

I think "popular" is stretching it here, Debian GNU/kFreeBSD is dead now, and while Hurd is interesting, it has ways to go.

Alpine is actually popular, particularly as a lightweight host OS to run docker.

You can have a Linux distro without GNU -Alpine Linux is a popular example

What is your source for this ? Recent polls show reunification support is still <2%, with about 6% open to reunification eventually but not now.

In 2018, before the crackdown in HK, the reunification support was 3%, with 13% open to it eventually - the events in HK have definitely significantly eroded support for reunification in Taiwan.

I have family in Taiwan and literally don't know a single Taiwanese person that wants reunification with the PRC.

Early computers had very limited resources, RAM, storage, etc. (first computer I worked with only had 4k of RAM for example) It often made sense to only use the last 2 digits of the year as an optimization in many common tasks that computers were used for, as both the 1800s and the 2000s were far enough away that most basic date calculations worked fine. Also, the industry was changing rapidly, and few people expected their software to be used for more than a few years - certainly not for decades, so focus was usually on solving the immediate tasks as efficiently as possible, without much consideration for the distant future.

However, it turned out that a lot of the code written in this period (70s and 80s) became "legacy code" that companies started relying on for far longer than was expected, to the point that old retired COBOL programmers were being hired for big $$ in late 90s to come and fix Y2K issues in code written decades ago. Many large systems had some critical ancient mainframe code somewhere along the dependency chains. On top of that, even stuff that was meant to handle Y2K was not always tested well, and all kinds of unexpected dependencies crept up where a small bug here, or some forgotten non-compliant library there could wreak havoc once date rolled over into the 2000s.

A lot of the Y2K work was testing all the systems and finding all the places such bugs were hiding.

Chinese is also not right - 正确的 (zhèngquè de) means "proper"

Left and Right as the sides are 左 (zuǒ) and 右 (yòu) - you can also add 邊 (biān) to each which means "side" to be more explicit, but they are also used separately in many contexts where the left/right meaning is needed.

The Chinese characters for 左 and 右 actually originated as pictograms of the left and right hand in the early forms of Chinese writing, but later forms both contain general "hand" component (𠂇) with components 工 and 口 added for differentiation

What's wrong with using a text editor to remove lines ? In vim for example :g/pattern/d or :g!/pattern/d with regular expressions is a powerful tool for removing lines in bulk if needed.

The first computer I used was a PDP-8 clone, which was a very primitive machine by today's standards - it only had 4k words of RAM (hand-made magnetic core memory !) - you could actually do simple programming tasks (such as short sequences of code to load software from paper tape) by entering machine code directly into memory by flipping mechanical switches on the front panel of the machine for individual bits (for data and memory addresses)

You could also write assembly code on paper, and then convert it into machine code by hand, and manually punch the resulting code sequence onto paper tape to then load into the machine (we had a manual paper punching device for this purpose)

Even with only 4k words of RAM, there were actually multiple assemblers and even compilers and interpreters available for the PDP-8 (FOCAL, FORTRAN, PASCAL, BASIC) - we only had a teletype interface (that printed output on paper), no monitor/terminal, so editing code on the machine itself was challenging, although there was a line editor which you could use, generally to enter programs you wrote on paper beforehand.

Writing assembly code is not actually the same as writing straight machine code - assemblers actually do provide a very useful layer of abstraction, such as function calls, symbolic addressing, variables, etc. - instead of having to always specify memory locations, you could use names to refer to jump points/loops, variables, functions, etc. - the assembler would then convert those into specific addresses as needed, so a small change of code or data structures wouldn't require huge manual process of recalculating all the memory locations as a result, it's all done automatically by the assembler.

So yeah, writing assembly code is still a lot easier than writing direct machine code - even when assembling by hand, you would generally start with assembly code, and just do the extra work that an assembler would do, but by hand.