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.

There are a couple of notable examples of projects[0] and companies[1] that have got tired of it, and no longer use it.

There's considerable difficulty these days extrapolating "real" vulnerabilities from kernel CVEs, as the kernel team quite reasonably feel that basically any bug can be a vulnerability in the right situation, but the list of vulnerabilities in io_uring over the past 12 months[2] is pretty staggering to me.

0: https://github.com/containerd/containerd/pull/9320 1: https://security.googleblog.com/2023/06/learnings-from-kctf-... 3: https://nvd.nist.gov/vuln/search#/nvd/home?offset=0&rowCount...

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).

The standard is... well, it IS indeed a standard, I guess you can't really argue that, but it's a very great deal more permissive than many people might hope or expect. https://ijmacd.github.io/rfc3339-iso8601/ is a wonderful illustration of some of the deeply silly time formats permitted by ISO 8601.

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.

It's a shame the article chose to compare solely against AMD CPUs, because AMD and Intel have very different L3 architectures. AMD CPUs have their cores oranised into groups, called a CCX, each of which have their own small L3 cache. For example the Turin-based 9755 has 16 CCXs each with 32MB of L3 cache. Far less cache per core than the mainframe CPU being described. In contrast to this, Intel uses an approach that's a little closer to the Telum II CPU being described - a Granite Rapids AP chip such as 6960P has 432 MB of L3 cache shared between 72 physical cores, each with its own 2MB L2 cache. This is still considerably less cache, but it's not quite as stark a difference as the picture painted by the article.

This doesn't really detract from the overall point - stacking a huge per-core L2 cache and using cross-chip reads to emulate L3 with clever saturation metrics and management is very different to what any x86 CPU I'm aware of has ever done, and I wouldn't be surprised if it works extremely well in practice. It's just that it'd have made a stronger article IMO if it had instead compared dedicated L2 + shared L2 (IBM) against dedicated L2 + shared L3 (intel), instead of dedicated L2 + sharded L3 (amd).

Plus one on the floating thing, on desktop it'd be great to be able to move it out of my way but still have it present.

Also, while I assume/hope there are shortcut keys on desktop, I have no idea what there are and if they're documented anywhere I can't find it. If there aren't shortcut keys, it'd be super useful to add them, at least for common actions.

There's a lot of rumours flying around that HL3 might be coming soonish, and when it arrives it'll almost certainly support RTX. It's also possible that it'll be built on an evolution of the HL2 engine. If so, it might have been seen as a useful development and marketing exercise to backport the RTX changes to the older HL2 engine version.

This is from 2017, errors.Join did not exist at the time. But yes, today you'd do it differently.

> Infra/Ops and programming are two different mindsets [...]

HARD disagree on this. I've done both. Most of the really excellent programmers I've worked with have, at least a little. You can't write highly reliable networking software without a deep understanding of how networking actually works. You can't write highly performing software without a deep understanding of the infrastructure and hardware it's running on. And so on.

I'm not trying to bersmirch yours or your teams abilities here - if you're writing in a high level language and most of your challenges are implementing biz logic then not knowing very much about the underlying infrastructure and hardware is fine, you aren't trying to write a distributed RDBMS, you probably don't need to know this stuff.

But do remember that there are lots of people for whom the hardware, the infrastructure and the application they're writing are inextricably linked. It's not a different mindset, it's just people with additional skills you haven't needed to learn yet.

As long as that very description is spelled out clearly near the top of the job ad, it doesn't matter terribly much (within reason) what you call it - job searchers will try various different strings to find it. Personally, I'd call it an ops role, however.

In general, most of the issues I've seen with these sorts of roles aren't the naming of them but rather the third bullet in your list. Having an ops role that's responsible for all the problems with software they didn't build and weren't allowed to have meaningful input to the design/implementation of isn't healthy. It sucks up their time and energy fighting fires they didn't create and likely aren't really empowered to fix. This is the problem with this role (as often implemented) that Rachel talks about in her first paragraph.

If you really care about having a good and reliable product you need people involved with the design and implementation that are deeply invested in making it reliable and maintainable in the long term - which means either making your dev roles shoulder some of the oncall burden or having people that straddle the ops and dev teams. Or both. If you're having difficulty filling this role, perhaps this is the real problem?

The months of R&D to create a workaround could simply be because the subset of motherboards which trigger this issue are doing something borderline/unexpected with their voltage management, and finding a workaround for that behaviour in CPU microcode is non-trivial. Not all motherboard models appear to trigger the fault, which suggests that motherboard behaviour is at least a contributing factor to the problem.

It's definitely not working. Several of the channels I'm currently in (which are not private channels for the record) aren't listed at all, and it's not sorted by user counts at all. There are channels with hundreds of users listed, but according to the "sorting" the largest channel has 20 users.

Memory de-dup is computationally expensive, and KSM hitrate is generally much worse than people tend to expect - not to mention that it comes with its own security issues. I agree that the security tradeoffs need to be taken seriously but the realworld performance/efficiency considerations are definitely not negligeable at scale.

There are also significant operational concerns. With containers you can just have your CI/CD system spit out a new signed image every N days and do fairly seamless A/B rollouts. With VMs that's a lot harder. You may be able to emulate some of this by building some sort of static microvm, but there's a LOT of complexity you'll need to handle (e.g. networking config, OS updates, debugging access) that is going to be some combination of flaky and hard to manage.

I by no means disagree with the security points but people are overstating the case for replacing containers with VMs in these replies.

Generics in go, as they're implemented today, sadly have a fair bit of performance overhead. I haven't tried but my assumption would be that go generics are not fast enough to make an effective arena allocator. I'd be thrilled if someone could prove me wrong though!

High barriers to entry on the interview process don't mean as much as you may think. Even with the best interview process in the world, you're only going to have a small number of hours to try to evaluate a lot of complex factors about a human you know nothing about. You're going to hire people you shouldn't - and lots of them. You're also going to miss hiring people you should. It sucks, but that's life.

With that in mind I do think your conclusion's a little suspect - there really will be a good amount of underperforming people you really do want to part ways with. Maybe not 6% - I don't work in HR, so I don't see those sorts of metrics - but I definitely have encountered lots of people who got through the interview process but nevertheless had no ability to do the job adequately.

I'm sure a bunch of people will jump on this to then complain about the arduous interview process - but NO interview process is perfect. Having a tough process is a reasonable way to reduce the number of people you end up not keeping on, and expecting any process involving humans to be anything close to perfect is wildly unrealistic.

Not only is this complete and utter rubbish, it should have been obvious from context that we're not talking about desktop CPUs. 96-core desktop CPUs are not a thing, and neither of the product families I mentioned are desktop CPUs either. I neither know nor care what the difference between those desktop cpus are, and I doubt GP does either.

Your metric about clock speed is, I'm afraid to say, so horribly oversimpified as to be flat out wrong. You can't just multiply core count by clock speed like that, as you're failing to take into account all sorts of other scaling factors such as memory bandwidth, cache size, avx support and so on, which matter as much or more than simple IPS.

Clock speed isn't a particularly meaningful measurement anymore, and hasn't been for years. For example, an AMD Genoa chip, depending on SKU, may have fairly comparable base/boost clock speeds compared to an Intel Sapphire Rapids - but in practice the single-core performance of the Intel is going to be substantially better for most code.

Your cache question doesn't really have a simple answer either. E.g. an AMD CPU is split into different CCXs. To simplify somewhat, each core is broken up into several smaller compute units, with their own caches and memory controller. Intel has a completely different ring-based approach that's harder to summarise in once sentence.

Overall though, for the sort of work you're describing the limiting factor is often memory bandwidth, not raw compute. Different platforms have very different membw/core figures, and I suspect if you started measuring that then you'd find it easier to predict your codes performance.

Putting an "AI" camera on a road in Cornwall, UK has no ability to affect how many people are killed on China's roads, and so it's deeply silly to use those numbers to try to justify doing so. There's far less invasive things that could be done to dramatically improve road safety in many of the countries you list.

In the UK, where this is happening, that's simply not true. There were 1695 road fatalities in 2022 total. That's very different from "thousands a day".

I do not believe it is desirable (or practically possible) to eliminate all risk of death or injury from life, and increasingly orwellian surveillance measures to clamp down on every misdeed and ill advised risk does not, I think, make for a happier or freer society.