The nuking of Los Angeles was a combination of physical models and 3D rendered shots. This close integration between physical models and 3D as well as using procedural techniques for the detonation was quite novel at the time. It was enabled by a new feature called "Mr. Nitro" written by Mark Granger, co-founder of Electric Image. The requirements of that groundbreaking sequence very much drove the features of Mr. Nitro, which was later released as part of Electric Image. EI 3D went on to render many shots for Star Wars: Phantom Menace, Star Trek: The Next Generation, Titanic, Men In Black, etc.
More info and images of both the physical and Mac rendered 3D models of Los Angeles being nuked: https://nccasymposium.bournemouth.ac.uk/2005/mscca/DIGGINS_h... While SGI's PR teams and ability to loan pricey workstations dominated the "3D in Hollywood" narrative for much of the 90s, in reality a lot of amazing work was being done on Macs and Video Toaster-equipped Amigas throughout the 90s. ILM's "Rebel Unit" initially started using Macs for 3D pre-visualization on Star Wars, but the renderings were so good literally hundreds of Mac rendered shots were used in Phantom Menace (although a contract ensured only SGI was credited at the end of the film).
Truly, what purpose does this serve? Defining a hierarchy without using is injecting immediate debt. Just introduce it when stuff goes there! If you really insist then at least put something in the folder. It doesn't take much effort to make the change at least a tiny bit meaningful.
Better yet just do the work. If you want make a commit in a branch that's destined to be squashed or something, sure, but keep it away from the shared history and certainly remove it when it's not needed anymore.
I play around with ComfyUI on my computer to make silly images.
To manually install it, you must clone the repo. Then you have to download models into the right place. Where's the right place? Well, there's an empty directory called models. They go in there.
The simplest answer is that sometimes other existing software that I need to use treats an empty directory (or, hopefully, a directory containing just an irrelevant file like .gitkeep) differently from an absent directory, and I want that software to behave in the first way instead of the second.
A more thorough answer would be: Filesystems can represent empty directories, so a technology that supports versioned filesystems should be able to as well. And if that technology can't quite support fully versioned filesystems -- perhaps because it was never designed with that goal in mind -- but can nevertheless support them well enough to cover a huge number of use cases that people actually have, then massaging it a bit to handle those rough edges still makes sense.
Legitimately asking, please share the name of software that expects/requires an empty directory and interprets .gitkeep in this way, but chokes on a README file.
Many filesystems cannot represent empty directories. Many archive formats also do not. I don't think this a problem in practice. I find this argument extremely weak.
> please share the name of software that expects/requires an empty directory and interprets .gitkeep in this way, but chokes on a README file.
Every mail server since postfix supports Maildir, in which every email is a file in one of 3 subdirectories (tmp, new or cur) of a user directory. If there's no jbloggs/tmp dir, postfix will think user jbloggs does not exist. So if you want to take a restorable snapshot of this with git, there needs to be a file there. I don't know if jbloggs/tmp/README would cause a problem, because I don't know how postfix will treat the presence of a file with a name that violates its expected syntax (which includes a timestamp and other metadata), but what I do know is that, after running `git clone any-repo`, I can safely delete every .gitkeep file to restore the system to its original state without having to understand that repo in detail -- while I cannot safely delete every README file. That's because the commonly understood semantics of .gitkeep is "I exist solely to shoehorn this empty dir into git", which does not apply to other files.
> Many filesystems cannot represent empty directories
I think you’re correct. the reproduction isn’t very precise and the solution doesn’t seem right (I’m not seeing anything about the non-standard pages not being freed). I’d guess this was ignored because it was wrong…
DB lookups + extra index are way more expensive then hardware assisted decoding.
If your UUIDv4 is cached, your still suffering from extra storage and index. Not a issue on a million row system but imagine a billion, 10 billion.
And what if its not cached. Great, now your hitting the disk.
Computers do not suffering from lacking CPU performance, especially when you can deploy CPU instruction sets. Hell, you do not even need encryption. How about making a simple bit shift where you include a simple lookup identifier. Black box sure, and not great if leaked but you have other things to worry about if your actual shift pattern is leaked. Use extra byte or two for iding the pattern.
Obfuscating your IDs is easy. No need for full encryption.
Hardware assisted is a red herring here. As you noted the real problem is that random reads have poor data locality, which degrades your database performance in a way that is expensive to resolve.
Why would it be computationally complex? The encryption is implemented in the silicon, it is close to free for all practical purposes. The lookup table would be wildly more expensive in almost all cases due to comparatively poor memory locality.
I think 'local' in this context could also simply mean 'wall', as in wall clock time. When my friend asks me the date and time, I don't have to bother with time zones.
This type of date/time is also very useful to store in a computer.
Having had decades of this in geophysical exploration, the time is now AND (where relevant) it's the current UTC Zulu time AND it's both local times.
Any data collected is logged against a UTC sync for start of recording (and continues with lapsed time AND logging raw GPS times .. which sorts out leap second issues).
Any discussion re: start of next data collection is relative to the local time at the field end, the planes et al are often bound by daylight - so field operation local dawn and sunset are relevant.
Any discussion re: software changes | hardware support is relevant to the local time at the home office end as that'll rest on when the office staff or aircraft mechanics come in or free up.
For ease of communication many such discussions are along the lines of "we'll ring back in four hours and ...". That's a NOW relative epoch.
Additionally I've always wanted institutions to be part of the timeline of technology. Corporations, Nation-states, Universities, Guilds, International Organizations - the ways people innovatively organize make things possible that otherwise wouldn't be.
The higgs boson experiments, for example wouldn't have been possible without the complex international institutions that orchestrated it. Manhattan project, Moon landing, the internet ... the iphone ...
https://en.wikipedia.org/wiki/Softimage_(company)
https://www.fxguide.com/quicktakes/remembering-softimage/