I have seen the similar assertion "some of the water molecules you drank today were once part of a dinosaur", which is false because water molecules do not last very long when in liquid phase (they continuously swap protons, turning into hydronium ions and back).
The O-O and N-N bonds are much stronger than H-O bonds, but there are still atmospheric processes that can break them. For instance, O2 undergoes photodissociation under ultraviolet light and recombines into O3 ozone, and N2 likely also undergoes photodissociation. And obviously, the fact that living beings breathe O2...
The atmosphere is estimated to have ~830PgC worth of CO₂, and plants are estimated to photosynthesize ~120PgC worth of CO₂ every year, so a given molecule would have 14% chance to be broken down in a year. The probability to survive for 2000 years would be around 1e-60.
Of course, CO₂ contents of the atmosphere have varied over the last 2000 years, and not all CO₂ is produced into or consumed from the atmosphere (it can be dissolved in surface water, etc).
EDIT: since there's much more O₂ than CO₂ in the atmosphere, a given O₂ molecule has a 8% chance to not be broken down by respiration over 2000 years.
Why quarks? There are untold bazillions of those inside each proton, and there's no quark conservation law (rather than conservation of (for example) isospin and strangeness, but only under electromagnetism not under weak interactions, so quark counts get furiously complex in bigger nuclei).
For a single proton, though, one always measures (with available measurement technology) a small excess of quarks: two excess up quarks and one excess down quark. That the valence quark model of hadrons works is weird. Who ordered that?
The excess quarks are not "the same" quarks every time you probe your carefully selected and isolated and cold sample proton. Indeed, today's valence quarks in your pet proton are not guaranteed to exist tomorrow, even if the proton stays trapped -- particle creation and annihilation are furious inside, and there are all sorts of other disturbances of quarks that go on in there.
Why atoms? While much calmer, there's still plenty of crazy stuff happening in atoms -- even a neutral hydrogen atom has a bunch of photons and positrons and excess electrons floating around "inside", with an energy fraction proportional to the fine structure constant and with no guarantees that they were there yesterday. Is it the "same" atom at that level? Also, for most of the hydrogen in an exhalation, it probably will be in and out of various electron-swapping configurations over the years. Water gets pretty crazy with its ions, for example.
We are using binary formats in production, also for data visualization and analysis. We went for a simple custom format: in addition to the usual JSON types (string, number, array, boolean, object), the serialized value can contain the standard JSON types, but can also contain JavaScript typed arrays (Uint8Array, Float32Array, etc). The serialized data contains the raw data of all the typed arrays, followed by a single JSON-serialized block of the original value with the typed arrays replaced by reference objects pointing to the appropriate parts of the raw data region.
For most data visualization tasks, the dataset will be composed of 5% of JSON data and 95% of a small number of large arrays (usually Float32Array) representing data table columns. The JSON takes time to parse, but it is small, and the large arrays can be created in constant time from the ArrayBuffer of the HTTP response (on big-endian machines, this will be linear time for all except Uint8Array).
For situations where hundreds of thousands of complex objects must be transferred, we will usually pack those objects as several large arrays instead. For example, using a struct-of-arrays instead of an array-of-structs, and/or by having an Uint8Array contain the result of a binary serialization of each object, with an Uint32Array containing the bounds of each object. The objective is to have the initial parsing be nearly instantaneous, and then to extract the individual objects on demand: this minimizes the total memory usage in the browser, and in the (typical) case where only a small subset of objects is being displayed or manipulate, the parsing time is reduced to only that subset instead of the entire response.
The main difficulty is that the browser developer tools "network" tab does not properly display non-JSON values, so investigating an issue requires placing a breakpoint or console.log right after the parsing of a response...
Usually for such scenarios, in the context of distributed systems, I tend to rely on general purpose monitoring tools, or a quick and dirty mini gateway if I can't reach for them.
Tree-shaking is able to remove code that will never be called. And it's not necessarily good at it: we can detect some situations where a function is never called, and remove that function, but it's mostly the obvious situations such as "this function is never referenced".
It cannot detect a case such as: if the string argument to this function contains a substring shaped like XYZ, then replace that substring with a value from the environment variables (the Log4j vulnerability), or from the file system (the XML Entity Extension vulnerability). From the point of view of tree-shaking, this is legitimate code that could be called. This is the kind of vulnerable bloat that comes with importing large libraries (large in the sense of "has many complex features", rather than of megabytes).
1. Write everything yourself, time consuming and hard, less likely to lead to these types of vulnerabilities.
2. Import others code, easy and takes no time, can lead to vulnerabilities.
3. Use others code, but only what you actually need. Maybe less time consuming than 1 but more than 2, adds a different sort of complexity, done correctly less likely to lead to these vulnerabilities.
I would say 4. grab individual code files (as opposed to entire libraries) and manually edit them, removing unnecessary features and adding new ones where needed.
The snippet you shared is consistent with the kind of output I have also been seeing out of LLMs: it looks correct overall, but contains mistakes and code quality problems, both of which would need human intervention to fix.
For example, why is the root object's entityType being passed to the recursive mergeEntities call, instead of extracting the field type from the propSchema?
Several uses of `as` (as well as repeated `result[key] === null`) tests could be eliminated by assigning `result[key]` to a named variable.
Yes, it's amazing that LLMs have reached the level where they can produce almost-correct, almost-clean code. The question remains of whether making it correct and clean takes longer than writing it by hand.
- Each service listens on a different, fixed port (as others have recommended).
- Have a single command (incrementally) build and then run each service, completely equivalent to running it from your IDE. In our case, `dotnet run` does this out of the box.
- The above step is much easier if services load their configuration from files, as opposed to environment variables. The main configuration files are in source control; they never contain secrets, instead they contain secret identifiers that are used to load secrets from a secret store. In our case, those are `appsettings.json` files and the secret store is Azure KeyVault.
- An additional optional configuration file for each application is outside source control, in a standard location that is the same on every development machine (such as /etc/companyname/). This lets us have "personal" configuration that applies regardless of whether the service is launched from the IDE or the command-line. In particular, when services need to communicate with each other, it lets us configure whether service A should use a localhost address for service B, or a testing cluster address, or a production cluster address.
- We have a simple GUI application that lists all services. For each service it has a "Run" button that launches it with the command-line script, and a checkbox that means "other local services should expect this one to be running on localhost". This makes it very simple to, say, check three boxes, run two of them from the GUI, and run the third service from the IDE (to have debugging enabled).
One of the hardest bugs I've investigated required the extreme version of debugging with printf: sprinkling the code with dump statements to produce about 500GiB of compressed binary trace, and writing a dedicated program to sift through it.
The main symptom was a non-deterministic crash in the middle of a 15-minute multi-threaded execution that should have been 100% deterministic. The debugger revealed that the contents of an array had been modified incorrectly, but stepping through the code prevented the crash, and it was not always the same array or the same position within that array. I suspected that the array writes were somehow dependent on a race, but placing a data breakpoint prevented the crash. So, I started dumping trace information. It was a rather silly game of adding more traces, running the 15-minute process 10 times to see if the overhead of producing the traces made the race disappear, and trying again.
The root cause was a "read, decompress and return a copy of data X from disk" method which was called with the 2023 assumption that a fresh copy would be returned every time, but was written with the 2018 optimization that if two threads asked for the same data "at the same time", the same copy could be returned to both to save on decompression time...
But I consider myself lucky that the issue could be reproduced on a local machine (arguably, one with 8 cores and 64GiB RAM) and not only on the 32 core, 256GiB RAM server. Having to work remotely on a server would have easily added another week of investigation.
The trouble is, darklaga.bin will not work locally because it must be fetched over an HTTP(S) connection. So, there's a darklaga.local.html provided when running locally. The build sequence is "npm run pack" then "npm run build", after which darklaga.local.html should work.
Yes, ship offset from touch point was an intentional 2024 change. In the 2004 version, touch screens used a stylus, which were thin enough that you could see whatever you were touching, so the player's ship was centered on the stylus point of contact. With a finger, it's much harder to see...
For Safari, I ended up having to investigate a crash on iOS Safari specifically, because it did not happen on Mac Safari.
I considered itch.io but I am still undecided on the whole affair.
The square pattern enemies are a bug (well, level design mistake) back from 2004, where they would move outside the range of the laser but would still be within reach of other weapons.
I must admit, since I no longer have access to the level editor, I edit the level files with HxD :-)
On other browser/platform combinations I use fullscreen mode, which gets rid of the issue entirely. But it isn't supported on iOS Safari as far as I can tell.
The O-O and N-N bonds are much stronger than H-O bonds, but there are still atmospheric processes that can break them. For instance, O2 undergoes photodissociation under ultraviolet light and recombines into O3 ozone, and N2 likely also undergoes photodissociation. And obviously, the fact that living beings breathe O2...