virchau13

It's because of the sybil problem. If accounts are globally unique, then a bad actor can register as many accounts as they want, and can do things like e.g. reserve other people's usernames and charge real money to have them unreserved.

That is why modern spellmakers have the tlateochihualapaztli, or the Metaspell, in which other spells can be cast and isolated from the outside world, and their effects recorded and carefully combed through for problems; testing of more advanced spells may also need the iztlacatlamatini, or the Fakespell, which can emulate the weave of other spells without actually casting them, letting other spells talk to it without knowledge of its illegitimacy.

The type problem is starting to be solved by flakes; the equivalent to the type `operating-system` is the type `nixpkgs.lib.nixosSystem`.

To analyze a NixOS system configuration, I look for all modifications to the `services` attr (representing all the services of the system, e.g. `services.mpd.dir = "~/Music"`). If I want to know even more I can look for all the `.enable` keys to see if any hardware/program/etc options have been enabled, and the sources are easy to read so I can open the corresponding module file in Nixpkgs if I want to know what a particular option does. The default NixOS machine does literally nothing so I don't have to worry about that.

Guix does look really cool, and I would try it if it had more support for nonfree software (I depend on some nonfree software in my day-to-day.)

Relativity already has the inability to distinguish between past and future states built in: https://en.wikipedia.org/wiki/Relativity_of_simultaneity

I have no idea how 2D time would work, though.

The conscious part of that system is the interpretation, not the bar itself. You have skipped directly over the observer, who is actually performing the conscious computation.

Think about how you would actually write a program to achieve this. The iron bar is just a bunch of atoms with random bit states that flip at random intervals - we'll model it as a contiguous 1D array of bits. You have a 1 second consciousness mapping, which is most likely rather large in size. Our interpretation process maps the random bits in the bar to a time instant of the conscious process by interpreting some bits in the bar as themselves, and the other bits in the bar as the reverse of themselves. In other words, our interpretation of which atom-bits are telling the truth and which are lying is itself a 1D array of bits that satisfies the following property:

BAR bitxor INTERPRETATION = CONSCIOUS_INSTANT

As time progresses, BAR and CONSCIOUS_INSTANT continuously change, therefore necessitating INTERPRETATION to change as well to keep the above formula consistent. In fact, by the rules of XOR, we can compute exactly what INTERPRETATION is at any given moment:

INTERPRETATION = CONSCIOUS_INSTANT bitxor BAR

But wait! This means that to dynamically know INTERPRETATION, you _must_ know all of the information associated with both CONSCIOUS_INSTANT and BAR. But if you know all the information associated with CONSCIOUS_INSTANT, haven't you already simulated a conscious process...? So there is in fact a consciousness here, but not in the {BAR} system: it is in the {BAR,INTERPRETATION,CONSCIOUS_INSTANT} system.

(Note: If you squint at this for long enough, it starts sounding a lot like a motivation for Death of the Author.)

I like Scott Aaronson's response[1] to the argument:

> So, class, how might a strong AI proponent respond to this argument? Duh: you might not understand Chinese, but the rule book does! Or if you like, understanding Chinese is an emergent property of the system consisting of you and the rule book, in the same sense that understanding English is an emergent property of the neurons in your brain. Like many other thought experiments, the Chinese Room gets its mileage from a deceptive choice of imagery -- and more to the point, from ignoring computational complexity. We're invited to imagine someone pushing around slips of paper with zero understanding or insight -- much like the doofus freshmen who write (a+b)^2=a^2+b^2 on their math tests. But how many slips of paper are we talking about? How big would the rule book have to be, and how quickly would you have to consult it, to carry out an intelligent Chinese conversation in anything resembling real time? If each page of the rule book corresponded to one neuron of (say) Debbie's brain, then probably we'd be talking about a "rule book" at least the size of the Earth, its pages searchable by a swarm of robots traveling at close to the speed of light. When you put it that way, maybe it's not so hard to imagine that this enormous Chinese-speaking entity -- this dian nao -- that we've brought into being might have something we'd be prepared to call understanding or insight.

[1]: https://www.scottaaronson.com/democritus/lec4.html

xkcd did a What-If on this: https://what-if.xkcd.com/146/

TL;DR: It will not happen. You would need to throw on the order of a thousand Earth-masses to even get close to neutralizing Jupiter's orbit.

All processes in this world are unsustainable, but only some matter.

This sounds interesting - could you elaborate further on how rejection sampling "fails" on LuaJIT?

You don't need LD_PRELOAD; the ptrace mechanism by itself can intercept system calls and modify them on the fly.

XCodeCode? :)

27/30. You can tell the AI ones because they don't look like they were made with the same constraints as a human; they merge, distort, twist together lines, shapes, and colors, rather than have images split into the compartmentalized pieces that humans like to do. I find the best place to check for AI art is to look at the overlaps; this is how I figured out the kindergartener one, for example: there were no obvious "AI-like" patterns except for the one section where the drawn lady's legs intersected with the ground line, and you could see that DALL-E 2 didn't know what to do, putting one leg over the line and one underneath, which can't be done unless one leg was drawn, then the ground, then the other, which is not what a human does.

> they also take a lot of time and effort to produce

This is a case of bad tooling, not an intrinsic fact.

https://www.joshwcomeau.com/css/understanding-layout-algorit... is an article that could have easily been written without any interactive components. All the author did was replace traditional code blocks with an embed to a web playground (e.g. by s/Code/Playground/g in a MDX file). Ta-da, the demonstrations are immediately interactive.

> and thus will remain a minority.

Not if we put in effort to encourage them. On the other hand, if we put in effort to _discourage_ them (say, by splitting the web into documents without interaction and apps with interaction), they will disappear completely. It is not worth sacrificing these creations simply so that we can remove a few bad actors. (Mind you, there are many ways to act badly in non-interactive ways too. Image watermarks, embedded advertisements in videos, embedded advertisements in ASCII text...)

But that article is exactly what we want on the internet. It's the kind of interactive teaching demonstrations that forward looking educators have been thinking about for decades. It's not bloated or overdone; it doesn't take up significantly more processing power; it works far better than a traditional article ever could. This is what we desire the internet to be like.

It's because of articles like this one, or 3Blue1Brown videos, that I feel like the idea of "the document web" is really a step backwards: the internet is not just a glorified transmission method for paper anymore. We have computers, which are able to do so much more than paper ever could. To not exploit them for their capabilities, simply due to fear of exploitation, is far worse. How much worse do you think https://thebookofshaders.com/ would be to learn from if it couldn't include live editable demnostrations? To divide up the web into "interactive" and "non-interactive" content is to remove the ability for creators such as the author of the Mechanical Watch article to add progressive interactivity to their documents, remove the ability for learning resources to fully utilize the power of computers, to remove the ability for small fun things to be added to sites such as a Konami Code easter egg or https://bruno-simon.com/'s interactive website. And before you reply with something like "these would all go on the interactive web", my point is that dividing the web like this would not only be pointless but would also be ultimately harmful to the creation of things such as these.

Where would https://ciechanow.ski/mechanical-watch/ fall? In the document web or the application web?

Using print debugging/strace/valgrind/etc, you're looking at the evolution over time of particular components of program state. Using a debugger, you're looking at all components of program state at particular time slices. They enable different viewing angles. (https://mobile.twitter.com/ManishEarth/status/13870782220560...)

I personally find that both are good tools, but to know what you should be using, you need to think about which viewing angle you want to choose: which components of state do you want to inspect and which moments in time do you want to track? If the answer is "these specific state components/unknown" (e.g. "when is my program accessing invalid memory?"), that's where print debugging comes in, with specializations depending on which particular state components you're looking at (strace or eBPF for IO, valgrind for invalid memory accesses, etc.) If it's "unknown/these specific times" (e.g. "where is my program setting HTTP response headers when a request occurs?"), then a debugger is a good idea.

However, what you said does have truth to it. Good programming practices generally center around the management of program state* (using types, specifications, whatever). If your program is not designed well in those terms, then the more likely it is that you have no idea what state components you want to inspect, meaning you reach for a debugger first. And if it is designed well, you won't need a debugger nearly as often. But sometimes we have no choice, whether that's due to an inherently hard problem space or lots of bad code that we didn't write, so a debugger is necessary.

* I don't actually know if there are programming practices that center around managing moments in time. I can't even think how that would work, but I would be very interested to know if there are any :)

For debugging, check out nvim-dap. It uses the same protocol as VSCode for debugging.

Check out /r/subsimulatorgpt2.

> xp

I always thought the fact that Vim had automatic buffer copying and forced me to use "0p instead of p was really annoying. Looks like there is an actual reason for it after all :)

My life may not be the most important time to other people, but it is the most important time to me. Importance is relative.

Infinite loops are considered undefined behaviour in C++.

For JSON pretty printing I generally use jq (`cat foo.json | jq`). It highlights and indents the output, and it's easy to add a filter.

Who's "people"? The state? A democratic vote? The individual?

The problem with mosquito-borne diseases is that they're non-consensual. People have a right to live without mosquito-borne disease.

For Linux, look at the eBPF tools - they're really useful[0]. I've used them to troubleshoot annoying problems before, and they're far more practical to use than the usual `strace -f ./program` dance.

Troubleshooting system issues can also be done with SystemTap[1], which looks cool, but I haven't personally tried it yet.

[0]: A cool example of using them is https://www.brendangregg.com/blog/2021-08-27/slack-crashes-s....

[1]: https://www.sourceware.org/systemtap/

Could it be possible to infer optional colors from the environment?

You denote that the color is optional in the function's type signature, and inside the body of the function, you have a construct that lets you execute different code depending on the state of the function's colors. The call site could either automatically infer the colors used or the colors used could be manually specified.

Basically a type parameter with compile-time if statements.

It's not that bad in my opinion?

I just middle click to open each link in a new tab. I can read the new tab, close it, leave it open, whatever. The links I've already clicked will turn purple, meaning I can easily see which links have been visited already.

Is there something I'm missing?

To be fair, this is just dualism, but in a non-religious way :P

Well, if we're being pedantic here, raw RGB video as would be displayed on a RGB monitor does indeed take 3 bytes per pixel. Technically, YUV is either an optimization or a backwards compatibility measure, and hence the adjective "raw" does not apply to it.

Yeah, but the problem is that some doctors are not capable of doing things of this sort safely, and thus doctor regulations happen. There are definitely unnecessary regulations out there, but I imagine that most of them are simply yet another symptom of "any large enough system eventually gets ruined by abuse".

IIRC [still spoiler] they specifically chose the spacing so that the hard drives would be unscathed, and captured the hard drives before they fell into the canal, although it is still a little ridiculous.

But in any case, keep reading! I promise the rest of the book is good :)

The broken part is that it is worth it to use an inefficient rendering method (lots of JS generated by React + an interpreter and GC + a render tree (React VDOM) + an overcomplicated element tree (DOM) + a rendering system) instead of an efficient rendering system (if React-in-Rust existed, it would be native executables manipulating an in memory tree for a renderer, removing at least two layers of complications). And this seems to be simply because the React+JS model works so well for DX compared to the rest that it allows for way faster feature implementation.