20k

People with the attitude you demonstrate here are consistently among the worst-behaved and hardest-to-deal-with participants on the meta site, because of a stubborn refusal to accept a core principle of the site.

Most edits I saw to answers on stack overflow were crap though, the system was regularly abused

That stubborn refusal was because it was a terrible idea, and one of the reasons why the site died

I mean yes, there's an enormous movement to diversify away from american tech currently in the EU, and a massive amount of investment to get away from the entire american tech bubble

I have no idea why you're phrasing this like this when so much money is being put into solving precisely this problem right now

The future is agents chatting to each other on tinder and automating the initial getting to know you part. I can imagine that while that's going on, we could add like a little text chat box for the humans to chit chat with each other a bit and pass the time, before they can go on a date

I was going through some answers on a stackoverflow thread, and noticed that every single one had been edited by the same guy, just.. adding his own personal opinions and 'corrections' to them, and in the process making them universally worse and less correct

The idea that answers should be editable, and the gamification of stackoverflow, was an absolutely terrible combination

Slop jacking?

I wrote a basic zachtronics style puzzler based around 0x10c, its one of my favourite concepts that's always stuck with me. I also strongly feel like it'd have a player base (at least initially, while everyone's coding) of maybe a few hundred people worldwide, which makes it a terrible decision financially

I feel like you're stuck between a rock and a hard place with that game. Do people really want to build their whole own OS just to interact with the hardware of their spaceship? Should it be a game where you have an ingame software market, for people to buy/sell software to use in your spaceship controls? Is a player REALLY going to build windows 3.1 for the DCPU for free?

I'd love to make it work, there was an open source game that was going for a while, but it went all the way down to the BIOS level which is just.. way too technical for most people. Who wants to get involved with an API/ABI for just making their spaceship move?

Oh man this was my biggest pet peeve with mechcommander as a kid, thanks for fixing it!

But the pop in system doesn't relate to this at all. Peekers advantage still exists with this system on or off in exactly the same way, and both players will see exactly what they would have seen previously without the culling system

It isn't an unsolvable problem though, there's only jitter because the implementation isn't very good

Implementing a more conservative anti wallhack cheat where player positions start streaming in slightly earlier still significantly cuts down on the efficacy of wallhacking, while entirely avoiding the jitter problem. Characters in CSGO move at a fixed speed, so you can calculate exactly how many ticks in advance you need to start sending that data in, before they will become visible to another client around a corner - and add a margin

There's also no excuse for sending player positions through a smoke for example - the server should be performing visibility culling

With the two combined you could cut the utility of wallhacks by 80%, in a way that would be completely unnoticeable. The real reason that this has never happened is that valve's investment into anticheat has always been pretty minimal compared to what's necessary for it to be effective (VAC has generally been the least effective anticheat). They're a small company which largely develops steam as a platform, not VAC or anticheat solutions for games

I'm glad someone's calling this out for what it is. These twitter influences are professional horseshit mongers that pretend to be acting in good faith, but flip what they're saying 180 degrees to fit whatever will drive maximum engagement in the moment. Its something that tends to slide by unless you stop and actually try to reconcile all the disparate things that someone has said, at which point you realise literally none of it makes any sense

Also, it seems like almost nobody here has actually read the entire article: the whole point of this is dissecting whether or not the author of odin truly believes what they are saying, which it seems like they don't

Out of interest, what (vaguely) is the amount of time you need between maintenance refreshes?

Dependencies: stolen from all code ever written without permission, including extremely illegal content

But other than that, totally dependency free!

Analysing codebases with LLMs to find security vulnerabilities is completely unrelated to committing code generated with LLMs

Sure but then it'd just be hosted somewhere else

Say what you want about EA, but they not only tolerated Open RA

They also don't have a choice though. There's nothing illegal or actionable about OpenRA. At most EA could have potentially forced them not to refer to CnC on the github, but even then its not clear that that's enforceable

LLMs can't be sued or commit crimes as they aren't legal people

In this case its likely google that would be responsible for putting up the fake information. There's been some court cases around this already

it sure sucks when people steal your hard work for free without paying for it doesn't it anthropic

AI is a terrible teacher though. It makes stuff up all the time, and for some subjects it has a remarkably low accuracy rate

The incredible laggyness of that website does not inspire confidence. Much of the text selection is also broken, and chrome consumes nearly a full core trying to render.. something?

Its remarkable that anyone thought this website was fit for release, and it gives off strong slop vibes

I also have absolutely zero trust in a product like version control being provided by a for-profit company. It seems like a terrible idea to tie your software stack to Epic Games of all people, given their track record

if 60% of the pixels within a region on a higher dpi display would be lit, then that is best approximated* by a single pixel emitting the same number of photons as those pixels would (which is 60% as many photons as there should be in the situation where all pixels on the higher dpi display would be lit).

This assumes that the output from the coverage process represents a semi transparent line with a light shining through it, which isn't what font rendering outputs. It outputs a perceptual brightness, because if a cell is 50% covered, we want it to be 50% dark. Not emitting 50% of the photons

Whatever color space you do your blending in, 40% black onto white should look the same as 60% white onto black.

What you want is 40% black onto white to have a similar difference in intensity as 40% white onto black, otherwise your darkmode font will look significantly different at the same intensity as your lightmode font. This is why it doesn't make sense to do it in a linear colourspace

Note that the wikipedia article is wrong, given that photoshop uses a nontrivial gamma exponent

When antialiasing, I think you do want to model light: a fully black object occluding 40% of a pixel should cause it to emit 40% less light. Linear intensity representations of colour should therefore be used.

The antialiasing value you get represents how much the pixel is covered by the glyph in question, and directly represents a desired change in perceptual brightness. There's no physical underlying lighting process, so it doesn't make sense to use physical light units

Blending in linear RGB models different strength lights being mixed together. This is why you do want to blend images together in linear RGB, but not fonts - because its not an underlying light based transport process

To take a direct example: Imagine two cases

1. We blend a white font on a black background

2. We blend a black font on a white background

Using perceptual blending, the antialiasing will be exactly the same efficacy in both cases. Using blending in linear space, these two test cases will look very different and render incorrectly!

This article contains some pretty major errors, which is kind of surprising to see!

The transformation used to represent the physically linear intensity data either generated synthetically via an algorithm or captured by a linear device (such as a CMOS of a digital camera or a scanner) with the discrete values of the perceptually linear scale is called gamma encoding.

This isn't super correct, and it underscores the biggest issue in this article:

sRGB (and its gamma encoding function) has absolutely nothing to do with perceptual linearity. sRGB is not perceptually linear! The original gamma encoding as far as I'm aware was made to compensate for the nonlinear transfer function of CRTs back in ye olde days. Its true that human vision is nonlinear, but sRGB is not a particularly good match to the perceptual linearity of human vision. Its a really common error to make, and leads to people wondering why we can't use sRGB to blend in if the reason why it was invented is because its perceptually linear

The article goes to compound on this mistake, which is why this is such a problematic misconception:

Interestingly, Photoshop antialiases text using γ=1.42 by default, and this indeed seems to yield the best looking results (middle image). The reason for this is that most fonts have been designed for gamma-incorrect font rasterizers, hence if you use linear space (correctly), then the fonts will look thinner than they should.

This is where the mistakes start to add up

Consider what you're trying to achieve during antialiasing: when rasterising a line, lets say we discover that a pixel is only 40% covered and want to darken it. This means that we want our pixel's brightness to decrease by 40% to a human being. We don't want to emit 40% less light, because that's not what antialiasing is trying to achieve!

Both sRGB and linear colour are the wrong colour spaces to use. You want to blend in a perceptually linear colourspace, and photoshop's 1.42 gamma exponent probably maps better to human vision than 2.2 or 1.0 while being cheaper than a LUV conversion

The standard gamma (γ) value to use in computer display systems is 2.2. The main reason for this is because a gamma of 2.2 approximately matches the power law sensitivity of human vision

The gamma transfer functions are also wrong. Its worth getting hung up on because it actually causes nontrivial errors, especially in the age of hardware accelerated sRGB conversions where doing it correctly is free

I've been programming in OpenCL for 10+ years. This article is clearly AI generated, and its also completely wrong

OpenCL did not fragment into a mess of vendor specific extensions. I don't know where that even comes from, the extensions in the 1.1/1.2 days were very minimal. The story goes like this:

1. OpenCL 1.2 turned up. This was the first really viable version of OpenCL, although 1.1 was usable. It started to gain a fair bit of traction

2. As OpenCL increasingly started to eat at Nvidia's cuda dominance, Nvidia deliberately killed OpenCL support by neglecting it. There literally did 0 technical development on it for years, with long running critical bugs remaining unfixed

3. At some point, OpenCL started to gain prominence in machine vision stuff in the embedded world, especially for cars and that space. Nvidia's poor OpenCL support became a liability, and so they heavily invested in OpenCL, fixed all the old bugs, and implemented OpenCL 3.0 support

4. Apple dropped OpenCL support because their anti competitive market strategy is vendor lock in, so a cross platform cross vendor API is bad for them. There's some kind of long running legal clusterfuck going on between Apple, and Khronos, the details of which are not public

5. AMD's OpenCL support was absolutely great. A+_best in class, would recommend. It had a fair bit of buggyness/jankyness, but it was an order of magnitude better than Nvidia's support back when Nvidia was deliberately hamstringing it. Then they started developing ROCm

6. Around this time, Vulkan was standardised. Khronos had been considering merging OpenCL into vulkan to force vendors to support it properly, but this was killed. Instead, we got the absolutely insane OpenCL-specific SPIRV format that nobody has ever used for anything

7. With the advent of ROCm, AMD abandoned OpenCL. They swapped over their good OpenCL compiler, to a new compiler that is much shitter and still has way worse performance. OpenCL is now badly implemented on top of ROCm, but some of it is so buggy its clear that nobody has ever used it. They refuse to implement 3.0 support, even though Nvidia supports it

8. The tables have turned: AMDs GPU compute support sucks donkeyballs, and Nvidia is lightyears ahead of them

OpenCL is not a story of fragmentation. Its a story of how vendors deliberately independently set out to kill it, along with AMD's incompetence, and Khronos making several boneheaded decisions during its standardisation that lead to it being cut off at the knees

Despite this, OpenCL 1.2 is still by far the best cross platform cross vendor GPU Compute API, because it is the only one that exists. Vulkan still doesn't support everything you need. Its a nightmare all around

A kid with $4k to burn on a credit card though? A lot of things would have had to go wrong for this to be a child

AMD's entire software development strategy is insane. OpenCL was doing reasonably well, and then AMD have just fully dropped support for some reason. For the - albeit not huge - but actual cross platform API that people were using to develop for their GPUs. For a while, a few cross platform tools had OpenCL backends, but nobody has been able to get AMD to fix any of the damn bugs. In my testing, bug latency for even the most trivial but important bugfixes is often 4+ years, which is utterly mad. Some parts of their compute stack is so broken its clear that nobody has ever used it. There are exploitable privilege escalation vulnerabilities caused by threaded race conditions that are wontfix

They could support OpenCL 3.0. Nvidia do. AMD just chooses not to, even though they're the ones that desperately needs to support it most

Instead, we got ROCm which has been a disaster from start to end. It barely supports windows or consumer GPUs, for some reason. Its a buggy mess, for some reason. HIP/ROCm has worse performance than OpenCL, because they downgraded their compiler and stopped extracting read/write information on variables leading to a massive loss of parallelism and utilisation on their GPUs.. for some reason. Why? What are they doing? How is this so rubbish?

Literally ALL of this is WONTFIX, and I don't have a clue why. I've filed bugs, was part of their vanguard supporter program, have tried to reach out to AMD people to (gently) explain why good support is important. Or even just figure out what technology they're even intending to support for GPU development. Is ROCm deprecated? What should we be using on windows for GPU compute on consumer hardware AMD? For the love of god amd I want to make you money

As of 2026, the best cross platform cross vendor API for doing GPU compute is.. drumroll.. OpenCL 1.2. Vulkan is getting there, but its still missing a bunch of stuff. And this is literally AMDs direct fault at this point

Distributed a compressed copy of something is still copyright infringement

Honestly? Yes. This is why its such a problem that most of the training data was not used with permission, and without the correct copyright status or license associated with it

There's a lot of arguments about humans doing the same thing, but the reality is that humans and robots don't enjoy the same legal protection. Its clearly a derivative work of all of its training data

Yes, and realistically any code that LLMs produce is a derivative work of its training data. There's going to be a huge disaster licensing wise

I have absolutely no idea how LLMs got through anyone's legal departments, I guess the hope is that if everyone breaks the law enough, it'll just be fine

Apparently I'm just a moron and have never seen it has settings in 10+ years. Thanks!

Yes, and LLMs have been shown to store and be able to output their training data, so this is at best very sketchy