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