I would argue, and I'm sure many historians and librarians and archivists would agree, that "general data backups" are essential human data. Storing the data allows for later analysis, which may provide important insights. Even things that seem trivial and unimportant today can provide very important insights later.
- Posts
- 1
- Comments
- 439
- Joined
- 3 yr. ago
- Posts
- 1
- Comments
- 439
- Joined
- 3 yr. ago
Honda won't honor my 10-year powertrain warranty just because I yeeted my 2-year-old Civic off a bridge into salt water!
That's why Research in Motion (the developer of the Blackberry) had to buy the domain "rim.jobs" when the .jobs tld was launched.
I don't think it'd be that simple.
Any given website URL could go viral at any moment. In the old days, that might look like a DDoS that brings down the site (aka the slashdot effect or hug of death), but these days many small sites are hosted on infrastructure that is protected against unexpectedly high traffic.
So if someone hosts deceptive content on their server and it can be viewed by billions, there would be a disconnect between a website's reach and its accountability (to paraphrase Spider-Man's Uncle Ben).
The company describes this generator as a solid state device, but the diagrams show the reliance on fluid/flow of hydrogen between the hot side and the cold side for moving some protons around. That seems to be something in between the semiconductor-based solid state thermoelectric generators that are already commonly understood and some kind of generator with moving solid parts.
It still seems like a low maintenance solution to have a closed loop of hydrogen, but that seems like a potential maintenance/failure point, as well, to rely on the chamber to remain filled with hydrogen gas.
The inventor/founder at the center of the article, Lonnie Johnson, was on the team at JPL that designed and implemented the thermoelectric generators (heated by radioactive decay from plutonium-238 pellets) on the Galileo spacecraft sent to Jupiter. So I would expect that he's more familiar with the thermodynamic and engineering challenges than even a typical expert.
The PR fluff put out by the company mentions that the theoretical basis for this specific type of generator was worked out a while ago but needed materials science to advance to the point where this type of generator can be thermodynamically and commercially feasible.
Looking at how this generator is supposed to work, it's interesting in that it does rely on the movement of fluid, but is supposed to be a totally closed loop, to be a bit different than the pure solid state, semiconductor-based Seebeck generators that are already well known.
The other area talked about in this article is that they believe that it can be effective with lower temperature differentials than any previous technology, which might make a huge difference in whether it can be deployed to more useful places and thereby make it economically feasible more easily than prior concepts.
In the end, if these generators can output some electric voltage/current, it might just take on similar generation characteristics as photovoltaics, which could mean that hooking these up to the grid could draw on some of the lessons learned from the rise of grid scale solar.
Kinda off topic, but now I'm wondering whether Europeans think of phone size (and laptops and screens) in terms of inches rather than centimeters?
More along the lines of a "pizza finder" service that scours different menus and shows the pizza options at a bunch of places, whether those places exclusively offer pizza, specialize in pizza with some other options, or just offer pizza as one of several options. It would be perfectly reasonable for such a service to only return results related to pizza, without any implicit suggestion that each place it returns only has pizza available.
Financial analysts were sounding the alarm in October. On October 7, Bloomberg ran an influential article about the circular deals:
That built on earlier reporting where they described the deals as circular, as the deals were being announced. Each of these reports notes the financial analysts at different investment firms sounding the alarm.
From there, a robust discussion happened all over the financial press about whether these circular deals were truly unstable. By the time Gamers Nexus ran that video the financial press was already kinda getting sick of the story.
Whatever the hell these trading algorithms were doing on November 20, they definitely weren't ahead of the curve on investor knowledge and belief.
it's like AI companies went from buying 10 memories as usual to 1000000,
I mean, they basically did. OpenAI announced a few months ago that they reached deals to buy 900,000 wafers of DRAM per month, representing 40% of global production capacity. For a single company. There are several other companies competing at those scales, too.
but I don't think most are designed to control people's opinions
Yeah I'm on team chaos theory. People can plan and design shit all they want, but the complexity will lead to unexpected behavior, always. How harmful that unwanted behavior is, or how easy it is to control or contain, is often unknown in advance, but invented things tend to develop far, far outside the initial vision of the creators.
And LUKS was already widely available on Linux as alternative.
Yeah, I found LUKS and LVM to be more intuitive for creating encrypted partitions, and had that on my daily driver by around 2009 or so, so I never really felt the need to try Truecrypt.
Still a pretty limited palette, everyone wearing the same color shirts.
PNG tends to fail hard with textures. For example, my preferred theme in my chess app, which has some wood grain textures, generates huge screenshot file sizes (2MB), whereas the default might be less than 10% as large. Similarly, when I screenshot this image the file size jumps to 2MB for a 0.8 megapixel image.
Rendered textured scenes could easily overload the PNG compression algorithm to where they're huge, and if Discord is historically associated with gaming, one can imagine certain video game screenshots blasting past that 40mb limit.
I think HEIC plays friendly for how they store live photos: a container that has both a still image and a video of the surrounding time context. HEIC for the still photo and HEVC for the video probably optimizes the hardware acceleration for fast, low power processing of both parts of the data, and allows for a higher quality extraction of an alternative still photo from a different part of the video.
And maybe they want to have more third party support in place before they set JXL as a default. All the power and space savings in the world on capture might not mean as much if the phone has to do the work of exporting a JPEG or HEIC for each time that file interfaces with an app or the browser or whatever.
Being able to point a camera at something and have AI tell me "that's a red bicycle" is a cool novelty the first few times, but I already knew that information just by looking at it.
Visual search is already useful. People go through the effort of posting requests to social media or forums asking "what is this thing" or "help me ID these shoes and where I can buy them" or "what kind of spider is this" all the time. They're not searching for red bicycles, they're taking pictures of a specific Bianchi model and asking what year it was manufactured. Automating the process and improving the reliability/accuracy of that search will improve day to day life.
And I have strong reservations about the fundamental issues of inference engines being used to generate things (LLMs and diffusers and things like that), but image recognition, speech to text, and translation are areas where these tools excel today.
JPEG XL has a mode for losslessly encoding any lossy JPEG into a smaller file size without any loss of quality. Wikipedia has some description of general approaches for losslessly encoding JPEG files further.
I don't know if webp uses any of these tricks, but I don't see why it would be hard to imagine that compression artifacts from a 30-year-old format can be encoded more efficiently today.
Google didn't kill JPEG XL. It might have set browser support back some, but there's still a place for JPEG XL to take over.
All the modern video-derived formats (webp, heif/heic, avif) tend to be optimized for screen resolutions. But for print photography (including just plain old regular photography that wants to keep the option open of maybe printing some of the images eventually), the higher resolutions and higher quality stretches the limits of where those codecs actually perform well (in terms of file sizes, perceived quality, computational power of coding or decoding).
JPEG XL knocks the other modern images out of the water at those print resolutions and color spaces and quality. It's not just for photography, either: medical imaging, archiving, printing, etc., all use much higher resolutions that what is supported on any screen.
And perhaps most importantly for future support, the iPhone now supports taking images in JPEG XL. If that becomes a dominant format for photographic workflows, to replace stuff like DNG and other raw formats, browser support won't hold back the format's adoption.
And if you already have compression artifacts, what use is lossless?
To further reduce file size without further reducing quality.
There are probably billions of jpeg files out there in the world already encoded in lossy JPEG, with no corresponding higher quality version actually available (e.g., the camera that captures the image and immediately saves it as JPEG). We shouldn't simply accept that those file sizes are going to forever be stuck, and can think through codecs that further compress the file size losslessly from there.
It was the Joint Picture Experts Group that invented it, so Google had no ownership over it, unlike WebP.
No, JPEG called for submission of proposals to define the new standard, and Google submitted its own PIK format, which provided much of the basis for what would become the JXL standard (the other primary contribution being Cloudinary's FUIF).
Ultimately, I think most of the discussion around browser support thinks too small. Image formats are used for web display, sure, but they're also used for so many other things. Digital imaging is used in medicine (where TIFF dominates), print, photography, video, etc.
I'm excited about JPEG XL as a replacement for TIFF and raw photography sensor data, including for printing and medical imaging. WebP, AVIF, HEIF, etc. really are only aiming for replacing web distributed images on a screen.
Writing 360 TB at 4 MB/s will take over 1000 days, almost 3 years. Retrieving 360 TB at a rate of 30 MB/s is about 138 days. That capacity to bitrate ratio that is going to be really hard to use in a practical way, and it'll be critical to get that speed up. Their target of 500 MB/s is still more than 8 days to read or write the data from one storage platter.