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.
> 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."
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.
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.
This isn't really true. If you're capturing by reference, you can easily say that defer can only be called on variables declared in scopes no deeper than the beginning of the defer block and you still have a very useful feature. If you're capturing by value, the "closures" are probably just getting created in the stack like normal auto variables. Either way, this doesn't really seem to be a deal breaker.
Who said anything about better? Cheaper energy = cheaper everything, but that doesn't mean that quality is necessarily constrained by current energy prices (although that also doesn't mean there aren't ways in which it could be).
> To be fair, if this was truly a big deal, it would be a political issue with bipartisan support and taken care of short order.
Are you serious? Since you're using the term bipartisan, I'm going to assume you're also from the US. Have you been following the news/current events recently (and by recently, really I mean any time at all over the course of the past forty or fifty years)? Almost nothing actually gets "bipartisan" support these days. Our government is in a constant state of gridlock and it is next to impossible to get anything done.
> In times of strife, at least there's one thing you can always count on: Democracy. It never fails. If you can just remember that one thing, you should be able to sleep soundly at night. (It works for me at least, I used to be a constant worrywart until I learned this trick from my therapist, and I've been golden ever since.)
I'm really having a hard time telling if this comment is sarcastic. I'm not trying to cause you to lose sleep or anything, and honestly, I commend your optimism if you're serious, but the fact is that democracy is an abstract concept that is almost never put into practice perfectly. Even if democracy's promise of "most people being happy" meaning 51 people are happy while 49 people are not is actually sufficient, even that idealized version is very far from our actually political system in the United States.
I think one thing most Americans actually would agree with is that the way we do things here, right now, in terms of government, doesn't work so well. I think there is a lot of disagreement about what should change, and how, but it seems like very few people are satisfied with the current state of affairs. The more I think about it, the more I think this comment just has to be sarcastic, so this reply is probably a waste of everyone's time, but in any case, wow. I wish what you were saying here were actually true. That would be a nicer world to live in than this one (although, frustrating as it might be at times, this one is also not so bad).
The irony of reading this, over two thousand years later, translated into a different language, presumably by someone who is, even after all this time, still able to read the original--it's almost like writing helps us remember, as a species, in ways that would have otherwise been almost completely impossible.
> Sure, and if you do strlen(s) without checking if there is actually a NUL first then:
>> finding the end of a string may place you into invalid memory if there are missing trailing bytes.
You're really losing me here. Either you have a NUL terminated string or you already know the length of the string or you have no way of determining the length of the string that exists in memory that it is safe for you to access and what you have is garbage.
Just because data is "valid UTF-8" doesn't make it safe to read. If the end of your string isn't marked and you don't know how long the string is already, it's over.
I think OP is talking about the fact that it is possible to represent and transmit sound via an electromagnetic medium and that therefore this limit is not a limit on sound information (which is nothing but generic information that can be transmitted at the speed of light) but rather a limit on sound as it occurs physically (in the way that you've described).
I see comments like this often and I find them deeply confusing. To me, it seems like most of the different programming/scripting languages you've listed excel at completely different things. I would be curious to hear what type of work you're doing where all of these languages have been, in some form or another, appropriate.