shawxe

I very regularly refer to the act of writing code as "hacking the Gibson."

But... how is this easier than the solution proposed by OP?

I'm pretty sure the page is supposed to be satirical. It's poking fun at the number of software projects that have been around for several years (or maybe even a couple of decades), have had dozens to hundreds of releases, and yet are somehow still at major version 0, which flies in the face of both semantic versioning and general common sense.

To respond to another part of this, it doesn't matter if we can look at a brain scan and predict perfectly exactly what the scanned subject is thinking. That only answers the question of "how do thoughts occur" not the question "what are thoughts?"

We have no way of even constructing the concept that gets around this. "This brain state corresponds to these thoughts." Okay, but where/what are the thoughts? In order for something to corresponds to the thoughts, they must exist in some capacity, right? So long as consciousness exists at all, which anyone who experiences it can say with certainty that it does. If I drink a beer, I feel a certain way. Neurochemically, we understand exactly why this is happening. What we don't understand is how there are "ways to feel" in the first place.

Understanding how objects interact with one another doesn't answer the question of what those objects are; they just are. Understanding the effects of electromagnetic force doesn't answer the question of what electromagnetism is; it just is. With objects, we can actually break things down into a small number of basic components (particles) that depending on their organization make all objects. But these particles are already a thing with no reason; just an axiom we've been able to use to get a mostly logically consistent view of objects.

Consciousness, we have been totally unable to break down into anything. We can see evidence of it in others, and feel it in ourselves, and we can understand how to make it seem to go away, and also what seems to bring about certain effects in it's space (red, happy, warm, salty, etc.), but our understanding is not of those effects--it's only of how a certain material arrangement seems to bring them about.

Because the web application is only an emergent phenomenon once consciousness has already entered the equation. Without an observer, the website is nothing more than the sum of its parts; only we view it as something else. The CPU, machine code, all of the I/O mechanism, eventually just create an illuminated image on a screen that is only its emergent whole when viewed by a conscious observer who sees it that way.

Far from having an even remotely non-referential understanding of consciousness, we don't even have a non-referential understanding of the referent website as it exists in our perception--it just comes back to the same questions that a lot of physicalists seem to refuse to even acknowledge. I know that when I view this screen I see what I see as red, and I know that the material of my brain and the screen are responsible for that, but that does nothing to address what the referent red is in the first place.

How can consciousness be an emergent construct when emergent constructs are only identifiable as distinct from the sum of their parts by making use of consciousness?

I've been testing out a new workflow I'm Git in some personal projects that basically works like this.

Basically, I make a single wip branch, which contains all of my messy/frequent commits, then when I feel that things are in a good state and I'm ready to cut a release off that branch, I tag that commit with "wip-vX.Y.Z".

Separately, there is a "release" branch (which is basically master/main/trunk) that only ever gets code that was first committed into wip. When there's a new release tag in the wip branch, I run the following command on the release branch: "git cherry-pick -X theirs -n wip-vA.B.C..wip-vX.Y.Z", where A.B.C is the tag of the previous wip version and X.Y.Z is the tag of the current new wip version. This has the effect of taking all of those changes from the wip branch and staging them to be committed on the release branch. I then commit them with a descriptive commit message and tag that commit "release-vX.Y.Z".

What you end up with, as a result, is a "release" branch with a very clean commit history and a "wip" branch with a very detailed commit history. If you want to run a more detailed blame or bisect, all you need to do is checkout the "wip" branch. If you want to use code that's stable enough to be called a release, all you need to do is checkout the "release" branch. Rather than squashing/amending wip commit history out of existence or maintaining on a series of scattered branches, this workflow makes it all conveniently available in one place, without directly polluting the main branch.

As for the wip commits themselves, I do try to have them all be mostly atomic and to have them always build. But I feel much less concerned with having a couple of commits that try some idea then a couple more later on that undo it. Polluting a main branch with these sort of no-ops has never seemed particularly appealing to me, but not has simply deleting them, or tucking them away somewhere difficult to find. I've only been using this new workflow for a couple of weeks, but so far it seems to solve that problem and in general be working great.

My best attempt at Japanese:

その場合、彼女は監視されていたはずであろう。

> Essentially it means “it must have been the case that, at the moment we’re speaking of, someone was watching her.”

Another native English speaker here. This would be how I would parse "She had to have been being watched," but I think it's not quite the full picture in this sentence's case. It's important to note that the "would" adds the implication that this conclusion is being drawn based upon some other (possibly unspoken) observation or proposition.

I would say the meaning is probably closer to "In order for some unspoken condition to be true, it must also be true that, during the moment of time in the past about which we are speaking, someone was watching her."

You should take a look at Zig.

So first of all, I just want to echo the general sentiment here and say that all of this is beyond awesome. Cosmopolitan libc seems to have the potential to literally re-define what constitutes portable code.

With that out of the way, am I understanding correctly that the way this works on Linux/Unix is that the modifies itself (by overwriting the EXE file header with an ELF header)? This seems to have the consequence of making that specific file no longer portable. If I'm understanding things correctly, it also looks like the QEMU hack for non-x86_64 architectures will only work once per file, since after the first time running the file it will no longer run as a shell script on Unix so the QEMU invocation will be unreachable.

Have you considered adding workarounds for this?

re: でしょう, without seeing the original Japanese, my guess is that a more atural English translation for your first example would be "Your brother is supposed to be a man, right? He's supposed to be an adult, right?" or something more along those lines.

This may be a tangential, but I've recently found that it really is useful to track all/most of these pieces of personal data. I spent a long time trying to figure out the best way to go about this before ultimately just settling on plaintext files and Git. Some of my data goes into CSV files that I generally just manually edit with Vim, some (ie. notes) just goes into literal text files. Sensitive data lives in a separate repo and is encrypted using GNU pass

Since this is how I'm used to keeping track of code and configurations, the friction has been surprisingly low; I'd even go so far as to say I find it fun. I'm sure my specific setup is not what's right for everyone but it feels right for me and I think that's the whole point.