I don't have hard data, but I own 3 air gradients and they've been going strong for years. I don't think it's unreasonable to think they just got unlucky
then let me ask you: as an ethical person trying to write a review, how do you handle that situation? It seems like that's an angle to this that we're not exploring, and that's whether the review is epistemologically justified rather than whether it's objectively correct. The way I see it, as a reviewer I get a product that fails well sooner than I expected it to and I have three choices:
1) Don't report the failure
2) Report the failure
3) Report the failure but try to contextualize it (basically, trying to solve for sure whether they got unlucky or not)
1 is obviously unethical, and 3 seems like it's well outside the scope of a reviewer's duty (and could be seen as carrying water for a particular brand. after all, do you think the person who wrote the OP would be okay with it if his product's failure was considered typical but another product's failure was determined to be atypical, regardless of the truth?). The only ethical approach is to report what happened, and not speculate as to cause.
Do what Linus Tech Tips has done (when they're doing it right): report that they got the device, tested it for a while, and it broke, so what they currently know about it is not the full picture, and that they might revisit the product when they have confirmed that they've worked out the kinks with the device in question.
That feels like exactly what the article did. They disclosed that the thing broke and on what time frame, alongside details about the degradation of functionality. As far as say that this isn't the full picture, is it definitely not? If we owe someone the benefit of the doubt if their device breaks while being reviewed do we owe the reader the deficit of the doubt if it doesn't break? What if they just got lucky?
Definitely not. Repealing section 174 (or not extending it, as it were) helped pushed us into a new normal for the market. Adding it back doesn't in and of itself push the market into another new normal, we'd need a lot more. It might take the edge off though, hopefully.
Agreed. Consider that we're in a big tech bubble right now (AI) and have been for at least a couple years. And yet tech layoffs have been way up, and hiring way down. Part of that that could be attributable to 174, but there are other issues that contribute more. One would be that there are vanishingly few people with actual experience in this narrow part of AI (LLMs) - I know people working in AI that have been laid off in the last couple of years because they were in the wrong area of AI (vision & CNNs). Secondly, it turns out that not that many people are needed to work on this stuff (mostly concentrated in large companies like Meta, Google, Microsoft & Amazon). And thirdly, folks in the C suite became convinced that AI is going to replace software engineers so they've quite hiring them.
> And thirdly, folks in the C suite became convinced that AI is going to replace software engineers so they've quite hiring them.
I think this is the real reason for much of the layoffs.
The other reason is simply that the market isn't punishing layoffs. You get rewarded as a CEO for laying off employees and saying "It's because AI makes them obsolete"
I don't know anything about electronics design, but I'm really into backpacking so a high efficiency battery system with a solar panel is really interesting to me. I came across this project[1], and wanted to improve upon it for my usecase. I want to add the ability to have multiple 21700 cells in a lightweight charger, instead of a single cell with a builtin USB charger. I want to learn more electronics, but it definitely feels like a multiyear process, and it'd be nice to shortcut it for the projects I'm interested in.
Learning just enough for your needs is a valid approach to learning electronics design, unless you're planning on becoming an actual EE.
It provides a huge amount of self-motivation and as much as I hate to admit it (as a one-time electronics design engineer), you can skip a lot of the middle-layer concepts. Sure, you should understand Ohm's law and what basic components (resistors, capacitors, transistors) do, but you can jump from that right into understanding how a battery charger works without having to understand how the components actually work.
The hard part is finding good tutorial material that starts at the right level: most of the professionally written stuff presupposes that you're either already an EE, or have one at your disposal to translate things for you.
It's true, Gaussian Splatting is just an alternative to meshing a pointcloud for companies which currently rely on photogrammetry or lidar (Lidar works well as a basis for splatting when there's reference images taken as part of the scan). But I think that misses all the new opportunities that exist with Gaussian Splatting, which really just don't with existing techniques.
Gaussian Splats are able to handle more heterogeneous information sources, allowing more sources to help splat an environment. Devices like drones, surveillance cameras, or autonomous systems can be used to create or incrementally update a Gaussian Splat; and there's interesting work to allow them to locate themselves within the splat, not just to show themselves but also to place vision ML outputs into it (such as object detection or segmentation results).
Up till now nearly all digital representations of physical environments are either based off the original designs (by things like CAD or BIM files), or are an approximation of the environment (from photogrammetry or Lidar scans). CAD and BIM files suffer from drift, the real environment almost never perfectly matches the design files, small (and large) changes are made; and many times those files aren't even available if the structure isn't new. Photogrammetry and Lidar scans struggle because their output is a pointcloud, and it's very difficult to accurately mesh a pointcloud (Matterport only partially solved this problem and sold for $1.6B). Gaussian Splats overcome these issues; they're comparatively easy to generate for any environment, and allow for very accurate and easy viewing from any angle.
I think the Digital Twin space will be turned upside down, and they could potentially even cause huge changes in autonomous and semi-autonomous factories, warehouses, and depots. A single Gaussian Splat could be the source of truth that many autonomous vehicles update through their separate SLAM systems. Operators then would have access to this splat (and it's history) as a source of truth for the environment. Then, using techniques like iComMa[1], it may be possible to directly align XR devices into the Gaussian Splat; allowing operators direct access to location-based information generated by the environment.
That's a lot of words to say: Gaussian Splatting is a very neat new technology that could really underpin many future technologies, I'm really excited about it
I do agree that new use cases are emerging and it will probably enable tons of new businesses. I'm very gung-ho about the technology myself as well. I guess what I'm trying to say is that the new businesses that emerge because of this are not necessarily going to advertise that they use gaussian splats to do it, it's not a buzzy enough term, and many of the industries it serves just care about the results it delivers. Your average tech person is unlikely to hear much about it. Your average graphics engineer will have probably heard about it, but not know about all the use cases that are leveraging it. And your average person in the industry it is changing won't know what is causing the change (they will probably assign it to the nebulous ai bucket). I fully expect gaussian splats to be a quiet revolution.
Yeah, I see your point. I'd be surprised of Gaussian Splatting didn't make it into the advertising for Digital Twin services if/when they add it (like Bently's iTwin or Dassault's Virtual Twin). Whether that translates more broadly into the market, I don't know.
On the other hand, I'm playing with the idea of a platform which provides a Gaussian Splat based Digital Twin of an environment so other systems can utilize it to share location-based information. Even though I don't think it'll be possible to build without utilizing Gaussian Splatting; splatting may not end up in any of the pitches or advertising directly.
This is conflating splatting with more general pointcloud data.
Splatting is fundamentally about viewing pointcloud data. That's great. But it doesn't deal with all the other functions virtual twins need pointclouds for (e.g. design vs real world conformance).
Pointclouds themselves are proving hugely useful in a number of fields but vary considerably in form and application often based on how they are captured (e.g. LiDAR vs SfM photogrammetry)
Visualising pointclouds effectively has been a major problem which splatting really solves elegantly so it will be a major practical advance when splatting is added to cad software and javascript map visualisation libraries.
this is very interesting and thought-provoking; thank you
what exactly do you mean by 'digital twin'? do you mean any kind of computer model of a real-world phenomenon, including sets of differential equations, as i've sometimes seen it used? presumably you mean something narrower, but how narrow? do you mean, for example, specifically cad models of parts that are going to be manufactured?
i guess this sounds like i'm nitpicking but actually i just want to know the scope of the space that you expect to be turned upside down
