I feel like it is on you to understand these classes first though. In game engine programming, operator overloading is often just vector algebra. If you have no idea how matrix-vector multiplication works, then you have no business doing those things anyway, overloaded operator or not. But if you do understand it, it makes your code infinitely more readable than without overloading. And everyone with a math education will also understand that aspect of your code, no matter if they are familiar with your usual paradigms.
I wonder how long software projects will even be able to ban LLM use in an age where exploits are found by LLMs. Like, if you have two forks of Debian and one uses LLMs to fix exploitable bugs and the other one doesn't, the level of security they can offer will be worlds apart. And noone in their right mind would want to use the less secure one. Similar to how noone would want to drive a car that was 100% hand built by humans when we know that machines do a much better job at precision tasks. LLMs are just another tool in the end.
> I wonder how long software projects will even be able to ban LLM use in an age where exploits are found by LLMs.
You can use an LLM to scan your human written code for exploits and patch the relevant ones yourself without any LLM code generation. An LLM is a tool, you can chose how you use it.
Don't ask me how they would know you've used a LLM to "assist" you to find the exploit... I don't even know how they would definitely know if you used a LLM for the code to fix it either.
That's quite naive. We're looking at 50 years of legacy software running Unix/Linux environments. If the attacker with an LLM finds one in minutes it might take you hours to even comprehend the finding. Guess what the attacker with the LLM will do in that time?
There are a few of these "maintainer said no AI pulls, so we forked it" in the wild already and I am really interested to see how it all pans out.
Like, okay, sure, maintainer says AI bug monitoring is cumbersome. One fork stops reading the AI bug monitoring, the other leans in. Isn't the latter more likely to find/fix critical/performance/security issues?
>Similar to how noone would want to drive a car that was 100% hand built by humans
Though, of course, this highlights that the market will fragment itself given that there are in fact many humans who will outright refuse machine driven cars despite mounting evidence that they are vastly safer and more efficient in a growing number of situations.
We'll likely see both "individual who won't use AI assisted software gets hacked" and "individual who won't get in a robo-taxi kills jay-walker in broad daylight"
I think the viability of the fork primarily depends on whether it has enough people motivated to maintain it long term. A turtle can win a distracted hare.
>given that there are in fact many humans who will outright refuse machine driven cars
Are there though? I feel a lot of this hate is concentrated on Tesla and most of that is probably just a projection of hate on Elon. These may be the most vocal people online, but I doubt they even drive that much. Everyone who's had to drive a lot for work knows that any kind of assist on the road is extremely valuable.
> And noone in their right mind would want to use the less secure one.
I mean, this is a perfect description of the prisoner's dilemma. Ins't it a shame that we keep playing that game? There's something seriously wrong if we just keep creating these new arms race scenarios. It's sickening.
I found GPT 5.3 was the last model that was sufficiently competent and still open to discuss security on my own github repos. 5.4 started refusing to even look at potential problems, albeit not consistently. I'm considering a Kimi subscription, but I know many employers will simply not be on board with this and I don't know if I get enough personal use out of this for the few things I run on servers. When those companies realize what they're currently missing out on, it will be a game-changer.
They only train on the subscription memberships. Like everyone else. They also have a metered API that is not used for training (like most others too).
Google just got hit by yet another record antitrust fine by the EU [1]. But as long as they see these fines as cost of doing business, nothing will change. Especially if it always takes almost a decade to push this through the judicial system. Their net income last year alone was $130 Billion.
You're splitting hairs in this case, while that's unquestionably true, it's irrelevant if there tariffs are only set on one party.
That's why Trump's tariffs on everything was so ... Uh ... "Interesting". If only one party gets the tariffs, you end up with other parties selling the goods instead, which does cause meaningful damage to the tariffed party
Or the tariffing party just continues buying very nearly the same amount of things at higher prices in many categories because those items don’t have perfectly elastic supply and demand.
That’s actually kind of like not a good statistic though.
For 30% of transactions with the EU it’s just the US shooting itself in the foot and passing on higher costs to average Americans.
Imagine enacting a tax where 30% of the money collected was a net negative. I can’t think of many taxes that are that poorly constructed.
For the 70% of transactions where US companies and individuals decide to buy less or use alternative sources, doesn’t that at some point harm US businesses? At the very least you’re now artificially lowering competition, which tends to drive overall prices up and quality down.
Something like, "I'm worried about impairing Google's ability to compete in AI" or some nonsense. (Paraphrasing here.)
Looks like all it takes to compete in AI is to issue stock or get a bunch of investors. I don't see how Google would struggle with that. It's completely orthogonal to antitrust enforcement.
Actually, the EU should very much crack down on any foreign company that abuses its market position to stifle local business competition. There's no good reason to allow them to break local laws and diminish the local economy just because they keep their headquarters outside the EU.
>There is a way more interesting telegram RCE that kimi k3 allegedly discovered.
Telegram server or client? The client is open source, so I expect any reasonably capable model to find things there sooner or later. But the sever is closed source. Finding an RCE there would be wild for such a model, since it would have to solve a whole bunch of adjacent problems instead of just digesting tons of code.
I mean having the client source code can show you a vast number of the API's and their fields which allows you to fuzz the server quite a bit more easily.
You could say the same about electrification of road traffic. Yes, governments slept on the electric power requirements. Yes, there are other, still unsolved issues. But that doesn't mean that electric cars are bad or not the future. The first nation to fully get rid of fossils in transportation will have a monumental advantage and dominate other countries technologically and economically. Same goes for AI. And right now China is setting itself up to be the world leader in both fields.
What is the current status of WebGPU support in browsers? I tried to get into it a while ago go, when the writing was already on the wall for WebGL. But WebGPU just wasn't there yet, so I had to stick with WebGL.
Offshore wind power costs ~3 times more per MWh than on land. You can still do it if you're really low on space, but if you have tons of empty space anyway, it may very well be cheaper to simply build longer power lines.
The main advantage of offshore power is the reliability of the wind. For example, on the North Sea the wind blows strong enough for power generation 80% of the time.
Airplane radios are generally broadcasting and receiving mono. There are modern headsets that can also play stereo, but only for onboard music or intercom purposes, if the plane supports it. But in planes with 2 radios you can usually configure their I/O individually. So you can listen (and also talk, although that makes sense less often) on two frequencies at the same time.
Yes of course, the transmitted audio would be mono. I meant one radio in one ear and another radio in the other ear, or if you mix them and they both play in both ears. But it sounds like they're mixed (talking over each other in a single audio stream).
Yes. I have never seen any system (planes or elsewhere) that splits multiple voice communication inputs so you hear different streams in different ears. How would that be different (let alone better) than having both streams in both ears? It's not like your brain can process each ear separately.
There are generally 4 ways you can deal with presenting two independent mono sources to one person using headphones:
1. Mix them together into one mono channel and send that to both ears.
2. One in each ear.
3. Make separate mixes for each ear. For each ear's mix make one of the sources louder than the other, picking a different source to make louder for each ear.
4. Like #3, but also add delay in each ear's mix to the source that is weaker in that ear.
#2 is generally better than #1. Personally I'd find it annoying because it is very unnatural, but it makes it a lot easier for the brain to separate the sources, makes it easier to focus on one and ignore the other if you need to do that, and prevents the auditory masking you can get when two sources are in same place in your perceived audio space.
#3 fixes the masking problem with #1 but #2 still because it is still easier to focus when you need to. Also, in each ear the weaker signal is unnatural and the brain expends some effort to filter it out, which is fatiguing over long periods.
#4 is by far the best. It solves the long term fatigue problem from #3 because our auditory system is built to expect a weaker version of anything one ear hears first to arrive shortly later at the other ear, and automatically filters it out instead of having to do it at a higher level. The delay shifts the perceived source of each voice to somewhere outside the head instead of somewhere inside, which is more natural, which is much less fatiguing than the "one voice" per ear approach (the brain almost always does more work when something seems unnatural).
Many military planes use #4, as do some Airbus models.
> It's not like your brain can process each ear separately.
If you've ever seen a dance music DJ (Tomorrowland is streaming on Youtube right now!) - that's exactly what many of them do.
To DJ a continuous mix as is the norm for this style - generally you'll have headphones on, but only covering one ear. You'll listen to "currently playing" though your right ear, through the venue sound system (well, it's monitors). You'll also be listening to "up next", on the other record/cd/mp3 deck, through the headphones to your other ear. And you'll work the pitch slider, trim controls etc and hopefully produce a good mix!
Not everyone does it like this, some have the headphones permanently on and mix in stereo both tracks at both ears. Or split ears, headphones only - that is an option on the usual Pioneer mixers. But it's surely the most common mental image of a club DJ to have them holding their hand to their headphones on one ear only, I'm sure!
Different voice inputs in different ears wouldn't help since our brain processes auditory input on left/right side of brain based on the type of input, not which ear it came from. Speech is processed on the left side, and non-speech (music etc) on the right side.
But of course your brain can process each ear separately. You have a holistic conscious experience, but that is like a hallucination constructed by your brain for your own benefit.
The raw signals are indeed "in stereo"
reply