zanecodes

Imagine if your brand new refrigerator, by default, would leak toxic refrigerant into your kitchen unless you adjusted a valve just so. This fact is not called out prominently in the manual, but if you read the fine print in the manufacturer's assembly instructions and have a working knowledge of how a refrigerator operates, you can maybe infer that this valve must be adjusted after purchase to prevent leakage. You go on their support forum to try to figure out why your brand new refrigerator is emitting toxic refrigerant, and you're essentially called an idiot and told you don't have "basic refrigerator hygiene."

People don't want to become refrigerator mechanics. They want cold food.

Gaussian splatting represents a scene a cloud of 3d gaussian ellipsoids, with direction-dependent color components (usually represented using spherical harmonics) to deal with effects like reflections. The "Gaussian" part is important, because gaussian distributions are easy to differentiate, making it possible (and fast) to optimize the positions, sizes, orientations, and colors of a collection of Gaussian splats to minimize the difference between the input photos and the rendered scene. This optimization is usually done by starting with the same 3d point clouds and camera poses estimated using the same or similar tools as traditional photogrammetry (e.g. COLMAP), and using this point cloud to place and color your initial Gaussian splats. One of the key insights in the original Gaussian splatting paper was the use of some heuristics to determine when to split a splat into smaller ones to provide higher detail over a given area, and when to combine splats into larger ones to cover uniform/low detail areas.

The nature of Gaussian splats being essentially fancy point clouds means that they can't currently be easily integrated into existing 3d scene manipulation pipelines, although this is rapidly changing as they gain popularity, and tools to convert them into textured meshes and estimate material properties like albedo, reflectance, and so on do exist.

For what it's worth, the HTC Vive Flow and XR Elite headsets have adjustable diopter lenses, and the Bigscreen Beyond headset can be bought with first-party made-to-order prescription lenses that attach to magnets built into it.

https://github.com/containers/podman/issues/20428

https://github.com/containers/podman/issues/20462

https://github.com/containers/podman/issues/19611

Sounds like you're describing Nix.

I actually thought the article would be framed a bit differently when I saw the title: I think Docker and its ecosystem solve several adjacent but not intrinsically intertwined problems:

- Creating repeatable or ideally reproducible runtime environments for applications (via Dockerfiles) - Isolating applications' runtime environments (filesystems, networks, etc) from one another (via the Docker container runtime) - Specifying a common distribution format for applications and their runtime environments (via Docker images) - Providing a runtime to actually run applications in (via the Docker CLI and Docker Desktop)

In this context, a runtime environment consists of the application's dependencies, its configuration files, its temporary and cache files, its persistent state (usually via a volume or bind mount), its exposed ports, and so on.

I would argue that Docker is often used solely for dependency management and application distribution, and for such use cases things like network and filesystem isolation just present obstacles to be worked around, and this is why developers complain about Docker's complexity.

Having a good amount of reasonably well maintained dedicated bike lanes would have made rollerblading to work a lot easier!

I'd just like to be able to see (before I buy) objective numbers for things like SSD write lifetime, display burn-in rate, and battery capacity degradation next to information about what kind of tools I would need to replace them myself, and maybe how much it costs to have the manufacturer replace them, if they offer that service. That way I can decide that maybe I'm okay with a soldered battery, since it will probably last 10 years with my usage patterns and the manufacturer will replace it for $60.

I'm somewhat sympathetic to the idea that companies shouldn't be _forced_ to make their products repairable at the expense of other design considerations, but they should certainly be forced to be upfront about it if they don't.

It would be nice if companies were required to provide information about their products' wear parts, their expected lifetime, whether they're replaceable and what tools are necessary to do so, etc.

For those who weren't or haven't, it was a geofenced, anonymous message board app targeted to college students that became fairly popular over the first two years of its existence before gradually fading into obscurity and finally being shut down in 2017 (but as of 2021 was rebooted with pseudonymous accounts, IIRC). Users could see any messages within a certain radius (0.5 miles or so, I think) and messages could be upvoted and downvoted, and were sorted by their vote score. Messages with a score of -5 disappeared forever, and I think also eventually aged out.

Being a chaotic sophomore with some Android experience, I decided it would be fun to decompile the app and see how it worked. I discovered that each device was assigned an ID based on a timestamp, IMEI, and a few other pieces of information that could be easily spoofed, by calling a fixed HTTP endpoint to generate as many new IDs as I liked.

I generated ~500 or so IDs using some Java code, hardcoded them into a .class file, and added some hooks to intercept existing calls to set up the Android UI and add my own event listeners. From there I added a button to the app's menu bar with a radiation hazard icon that would use the generated IDs to nuke every message in range of the user, downvoting them all to -5 and causing them all to disappear instantly. I also added the ability to long-press the upvote and downvote buttons, which would bring up a dialog with a slider allowing the user to upvote or downvote any post up to 500 times, sending it to the top of the list (or downvoting it to oblivion). Finally, I rebuilt the app with my added .class file patch.

Needless to say, this was a source of great fun and mischief for my friends and I. The most entertaining event was attending a hackathon at our (much larger) rival university's campus, where we nuked every local post a few times a day for 72 hours and voted our own posts up 500 times.

It was fun to mess with for a few months or so. We never distributed the patched app, for obvious reasons, and we never used it for anything truly malicious beyond being a mild local nuisance denial-of-service.

It was an economic issue, not a political one.

The estimated maximum population of living adult Tyrannosaurs at any one time, on the other hand, is ~20,000, with a 95% confidence interval from 1,300 to 328,000, according to that article.

[1] https://www.livescience.com/number-of-tyrannosaurus-rex-on-e...

When we rename or remove a function from an API, that's a breaking change, any dependent software will no longer work unless it's modified to take that change into account.

Similarly, when we move, rename, or remove a UI element, keyboard shortcut, or visual affordance, that should be considered a "breaking change" for our dependents, the humans on the other side of the screen. And in the same way, we should avoid making such changes unless the long-term benefit of doing so outweighs the short-term cost. Plus, users will know that moving from 7.x.x of your software to 8.x.x will require them to relearn some aspect of it.

As you may be aware, all digital images are composed of a color palette applied to monochrome images, it just so happens that we usually pick a color palette of red, green, and blue, which ideally correspond as closely as possible to the three wavelengths of light to which the imaging sensors in our cameras (and also our eyes) are sensitive, thus reproducing what our eyes would see in person.

In the case of JWST, mid- and far-infrared sensors were chosen for several reasons, the first being that due to the accelerating expansion of the universe, light from further away (equivalently, light from further back in time) has been stretched out along its path of travel, causing its wavelength to be shifted further into the infrared spectrum. Another possible reason is that infrared wavelengths penetrate the interstellar dust clouds much better than visible or ultraviolet light, allowing us to see stars and galaxies that were previously hidden by dust.

Since JWST captures wavelengths of light that we can't see, we have to apply some sort of visible-light palette to the monochrome images it sends back. At the bottom of this image, you can see which wavelengths were mapped to which visible-light colors: https://stsci-opo.org/STScI-01G7N9A6934R1WRWBJY1ZXB98B.png One key aspect of this mapping is that the order of wavelengths has been preserved; shorter IR wavelengths are colored blue while longer ones are colored red. It's likely that this mapping is non-linear though, so the relative distances between IR wavelengths are not the same as the distances between the hues in the image, and this mapping was chosen to maximize the visible detail in the resulting image, as well as to highlight scientifically relevant information such as dust clouds and areas of star formation, so it's not totally arbitrary.

In addition, the dynamic range of JWST is much much larger than the pixels in any display. The raw data values probably range from 0 to some hundreds of thousands, while your display's pixel brightness can only go from 0 to 255 (or maybe 1023, if you have a 10-bit HDR display). While we could simply map the maximum pixel value to 255 and compress everything else in between, this would lose nearly all of the detail present in the darker regions of the images, compressing them to 0. Instead, a non-linear brightness mapping is applied, to best represent all the information present in darker regions without blowing out the bright stars and galaxies.

So to answer your questions, the colors shown in the images are not what you would see in person. Without any enhancements you probably wouldn't be able to see much if any of the dust clouds, and many of the redder galaxies would not be visible to you at all, while all the rest would be different hues than the ones shown (probably mostly whites, yellows, and reds).

I really wish my 49" Samsung Odyssey G9 supported DDC over DisplayPort, so I could also switch my monitor input via software, and essentially have a KVM without buying any additional hardware.

A major consideration for me is avoiding introducing any extra input latency between my input/output devices and my personal desktop, since I use it for gaming. I'm okay with trading off additional latency when controlling my work laptop in exchange for lower latency on my main desktop. That said, I may end up using my BeagleBone rather than my Photon, since it has an ethernet port, and running Linux may prove advantageous.