jfindley

Well. On vulcanus you can't directly produce legendary plates because fluid-only recipes don't support quality. I haven't gone through the articles maths properly yet, but I'd be interested to know if it's more efficient to have a full quality pipeline from miners through to end products or if it's better to start from vulcanus 'free' normal qual plates and build from there. I suspect vulcanus probably does win, but it'd be nice to be able to simulate that.

Except that the software part of the "significantly ahead" is in the device firmware, not the slicer. And it's only the slicer that's at issue in this debate. If it were the slicer that provided all this advantage over the competition it'd have been copied years ago, so this is really nothing to do with my point at all.

Again, I'd be far happier if they followed the terms of the AGPL and provided source for their custom slicing extensions, but it wouldn't really move the needle very much for the competition.

Unfortunately this comment entirely misses the mark.

The reason this is such a big deal is precisely because it's not a sketchy product. For people who are using their FDM printers for more than just minifigs from thingiverse there's no proper alternative to Bambu. Their hardware and software is significantly ahead of the competition.

If you want to print engineering-grade plastics reliably and accurately you are going to need a Bambu device, or drop 5 figures on a commercial machine. Those are the alternatives. Very few other firms offer consistent, accurate, high temperature printing - and the few that do, don't have the software to manage vibrations, flow control and thousands of other parameters well enough to get consistent hiqh quality results.

Some examples: Prusa have the One+, and good software management. But the "heated chamber" is actually just a fan attached to the underside of the bed, which means that the chamber temperature is not consistent across the volume, leading to poor quality products. There's a few niche devices from people like Qidi, but they don't have the build and software quality to get reliable, repeatable results.

Overall if you're trying to solve actual problems with your FDM device, rather than messing around as a hobby you need a tool that just works, and that can handle materials like PA12, PET and PC. Bambu are really the only sensible choice for this. Yes, I'd be far far happier if the software was really FOSS (the encrypted non-user-readable logs enrage me!), but overall it's a tool not a hobby. I don't have a sensible alternative.

The problem is not that GIMP has a different UI to photoshop. That's not a problem. Premier and Final Cut Pro have different UIs, and while there's some friendly banter about which is better most people agree that either work.

The GIMP community has utterly failed to understand that the problem with their UI is not that it's different from one particular competitor, it's that it breaks all user expectations about how GUI software should behave. A simple copy/paste operation between layers requires googling before a new user is able to do it - and all to save utterly trivial amounts of RAM. That's not "just different", that's objectively terrible.

I tend to look at the grinder and also the choice of the beans (roast level, consistency, chips). As another commenter pointed out you do occasionally get places that will buy a super fancy machine but have no idea what to do with it. It's rarer to spend loads on a fancy grinder if you don't know what you're doing.

io_uring is in a curious place. Yes it does offer significant performance advantages, but it continues to be such a consistent source of bugs - many with serious security implications - that it's questionable if it's really worth using.

I do agree that it's a bit dated and today you'd do other things (notably SO_REUSEPORT), just feel that io_uring is a questionable example.

Is there any way to have something like a distance blur? e.g. as rays travel further you reduce the number, subsample then apply a gaussian(or algo of choice) blur across those that return, increasing in intensity as the rays angle gets coarser?

It'd be really neat to have some way of enabling really long-distance raytraced voxels so you can make planet-scale worlds look good, but as far as I'm aware noone's really nailed the technical implementation yet. A few companies and engines seem to have come up with pieces of what might end up being a final puzzle, but not seen anything close to a complete solution yet.

Do note though that AIUI these are all E-cores, have poor single-threaded performance and won't support things like AVX512. That is going to skew your performance testing a lot. Some workloads will be fine, but for many users that are actually USING the hardware they buy this is likely to be a problem.

If that's you then the GraniteRapids AP platform that launched previously to this can hit similar numbers of threads (256 for the 6980P). There are a couple of caveats to this though - firstly that there are "only" 128 physical cores and if you're using VMs you probably don't want to share a physical core across VMs, secondly that it has a 500W TDP and retails north of $17000, if you can even find one for sale.

Overall once you're really comparing like to like, especially when you start trying to have 100+GbE networking and so on, it gets a lot harder to beat cloud providers - yes they have a nice fat markup but they're also paying a lot less for the hardware than you will be.

Most of the time when I see takes like this it's because the org has all these fast, modern CPUs for applications that get barely any real load, and the machines are mostly sitting idle on networks that can never handle 1/100th of the traffic the machine is capable of delivering. Solving that is largely a non-technical problem not a "cloud is bad" problem.

All the good commercial parametric CAD apps have an API that allow you to define models programatically to avoid repitition, or do more complicated things like ensure gear ratios are exactly correct. I'm not sure I entirely understand what you're getting at with the "stays in sync" part though.

Unfortunately the index is the easy part. Transforming user input into a series of tokens which get used to rank possible matches and return the top N, based on likely relevence, is the hard part and I'm afraid this doesn't appear to do an acceptable job with any of the queries I tested.

There's a reason Google became so popular as quickly as it did. It's even harder to compete in this space nowadays, as the volume of junk and SEO spam is many orders of magnitude worse as a percentage of the corpus than it was back then.

It's not quite as simple as that though - in most places, especially California, water shortages are not a simple natural imbalance between the amount of rain that falls and how much flows out in rivers and streams.

If demand is far higher than supply due to overuse by industry that's definitely a water shortage - there isn't enough of it, and something is probably suffering as a result. I don't think that's a useful definition of drought though. If someone builds a massive factory consuming 100s of millions of gallons of water per day that's definitely going to cause a problem but I'm not sure it's reasonable to say that there's suddenly a drought.

I think the definition of drought is instead current rainfall compared to historical average - which then leads to the question of if the change is just that rainfall has now been low for so long the historical average has changed, or if rainfall has actually improved. I don't think the article addressed this, but I only skimmed it so maybe I missed it.

If you want people to take your benchmark seriously, you'd need to provide a very great deal more information on how those numbers are generated. "It's complicated, just trust me" isn't a good enough explanation.

If you want people to listen, you need to have a link where you explain what hardware you're using, what settings you're using, what apps/games you're running, what metrics you're using and how you compute your Magical Number.

My already high level of sceptism is compounded by some scarcely-believable results, such as that according to your testing the i9-14900K and i9-13900K have essentially identical performance. Other, more reputable and established sources do not agree with you (to put it mildly).

I don't seem to be able to select "hard" AI - is this just not implemented yet? It'd be nice to have a stronger AI, but I do realise that this is a lot easier said than done.